기발한 원격으로 고양이님에게 밥 주는 기계 (cat feeder) 제작 영상

우연히 기발한 영상을 보게 되었는데요.

3D프린터로 기구를 만들어서 원격으로 고양이 먹이를 주는 기계입니다.

아두이노도 활용하고요.

아무튼 재미있는 영상입니다.

Data Management-as-a-service (DMaaS)이란?

DMaaS는 기업에 여러가지 다양한 데이터 소스를 위한 중앙 집중식 스토리지를 제공하는 클라우드 서비스의 일종입니다. "서비스로서의"라는 라벨은 고객이 데이터 관리를 위해 인프라를 구입하거나 관리할 필요가 없는 유료 비즈니스 모델을 언급합니다. 이 비즈니스 모델에서 고객은 DMaaS 서비스 공급자에게 데이터를 백업합니다. 이것은 일반적으로 백업되는 데이터 소스에 에이전트를 설치함으로써 수행되지만 클라우드 데이터 소스의 경우 간단한 인증 프로세스가 첫번째 단계일 수 있습니다.

DMaaS는 일반적으로 고객이 얼마나 많은 서비스를 소비하는지에 따라 오르내리는 운영비가 달라집니다. 기술적으로는 DMaaS 공급업체가 제공하는 IT 인프라나 개인 클라우드를 사용하여 DMaaS를 제공하는 것이 가능하지만, 모든 인프라는 DMaaS 공급업체가 제공하여 관리해야 서비스로 간주됩니다. 그렇다고 물류 및 비용상의 이유로 그렇게 하는 것은 바람직하지 않습니다.

이름에서 알 수 있듯이 DMaaS는 서비스로 수행되어야 합니다. 회사가 데이터 관리를 수행하기 위해 상당한 양의 인프라를 구입, 설치 및 유지해야 하는 경우 DMaaS가 아닙니다. "서비스로서의" 명칭은 Salesforce.com, Office365 및 G-Suite와 같은 개념을 만들고 정의한 서비스의 전통에 부합해야 합니다. 예를 들어, 이러한 회사중 어느 회사도 서비스를 제공하거나 소비하기 위해 고객이 가상 또는 물리적 인프라를 설치하거나 관리하도록 요구하지 않습니다. 이러한 서비스를 사용하는 회사는 단순히 벤더에게 얼마나 많은 사용자를 등록해야 하며 각 사용자가 필요로 하는 스토리지의 양과 같은 구체적인 요구를 알려줍니다. 해당 서비스를 제공하는데 필요한 인프라는 공급업체에서 자동으로 프로비저닝 및 관리합니다.

DMaaS는 클라우드 서비스를 활용하여 기업의 다양한 데이터 소스에 확장성, 통찰력 및 접근성을 제공합니다. 그런 다음 데이터의 중앙 집중을 활용하여 데이터 보호 및 추가 서비스를 제공합니다. 데이터 소스에는 가상 머신(VM) 데이터베이스를 포함한 파일 서버, 응용 프로그램 서버 및 데이터베이스 서버도 포함됩니다. 대부분의 회사는 또한 하나 이상의 클라우드 공급자와 많은 데스크톱, 노트북 및 모바일 장치에 데이터를 가지고 있습니다. 포괄적인 데이터 관리 솔루션은 단일 클라우드 기반 시스템의 모든 소스로부터 데이터를 보호하고 관리합니다. 그러나 이러한 데이터 소스의 하위 집합만 보호하고 관리하는 데이터 관리 솔루션이 있습니다.

위에서 언급한 추가 서비스에는 사전 대응 컴플라이언스, 데이터 분석, 법적 보류 및 중앙 집중식 검색이 포함됩니다. 모든 데이터 소스에 걸친 중앙 집중식 뷰는 이러한 서비스중 많은 부분에 최상의 관점을 제공합니다. 예를 들어, 검색 요청이 회사에게 주어진 직원의 업무의 모든 인스턴스를 찾고 보유하도록 요청하는 경우, 서버, 노트북 및 클라우드 인스턴스에서 단일 검색을 수행할 수 있으면 해당 요청을 훨씬 쉽게 충족시킬 수 있습니다.

다른 데이터 관리 솔루션에 비해 DMaaS 호스트에 대한 3가지 장점은 다음과 같습니다.

- 완전한 DMaaS 시스템은 회사의 모든 데이터 자산을 보호하면서 추가 가치를 도출하고 비용을 동시에 절감할 수 있습니다.
- DMaaS가 필요로 하는 데이터의 중앙 집중식 저장은 낭비 요소을 제거하고 비즈니스의 다른 부분을 용이하게 합니다.
- 데이터 관리 서비스(자신이 직접 하기 위해 인프라를 구입하고 유지하는 것과 비교하면)를 사용하면 자본 지출이 줄어들고 데이터 관리 비용이 훨씬 더 예측 가능해 집니다.

XaaS (Anything as a Service)

XaaS는 서비스로서 무엇이든 제공하는 일반적인 집합 용어입니다. 현재 벤더가 기업 내에서 로컬로 또는 현장에서 제공하지 않고 네트워크 (일반적으로 인터넷)를 통해 서비스로 사용자에게 제공하는 방대한 제품, 도구 및 기술을 말합니다.

XaaS의 예

XaaS에는 수많은 예가 있지만 가장 일반적인 3가지 일반적인 클라우드 컴퓨팅 모델은 SaaS (Software as a Service), PaaS (Platform as a Service) 및 IaaS (Infrastructure as a Service)입니다.

서비스로서의 소프트웨어(SaaS), 서비스로서의 플랫폼(PaaS), 서비스로서의 인프라(IaaS) 제공은 지난 몇년동안 급증했고, 그것들과 함께 다음에 무엇을 수익화할 것인가에 대한 새로운 아이디어가 쏟아지고 있습니다. SaaS는 새로운 용어로 뉴스를 만든 최초의 회사중 하나였지만, PaaS와 IaaS는 그후 오랫동안 더 제한된 범위에 존재해 왔으나, AWS와 Google Apps Engine과 같은 플랫폼이 스포트라이트를 받으면서 지속 성장함에 따라 그들이 제공하고 지원할 수 있는 것이 점점 더 좋아졌습니다.

SaaS는 Google Apps, Microsoft Office 365 및 Salesforce와 같은 광범위한 소프트웨어 응용 프로그램을 사용자에게 제공합니다. AWS (Amazon Web Services) Elastic Beanstalk, Heroku, Force.com, Google App Engine 및 Apache Stratos와 같은 PaaS 제공은 일반적으로 사전 구성된 가상 머신 (VM) 및 애플리케이션 개발 및 테스트를 위한 여러가지 리소스를 제공합니다. 조직은 IaaS를 사용하여 공급 업체의 데이터 센터에서 호스팅되는 가상 시스템을 배포 및 구성하고 해당 VM을 원격으로 관리할 수 있습니다. IaaS 서비스에는 Microsoft Azure, Google Compute Engine 및 AWS Elastic Compute Cloud가 포함됩니다.

XaaS의 다른 많은 예가 있습니다. SaaS (Storage as a Service)는 클라우드에서 애플리케이션, 데이터 및 백업 스토리지 시스템을 제공하고 DBaaS (Database as a Service)는 클라우드를 통해 데이터베이스 플랫폼에 대한 액세스를 제공합니다. AWS 및 Azure와 같은 퍼블릭 클라우드 공급자에는 DBaaS 제품이 있습니다.

MaaS (Malware as a Service)는 퍼블릭 클라우드를 사용하여 조직이 랜섬웨어 및 DDoS (Distributed Denial of Service)와 같은 일반적인 공격을 막을 수 있도록 합니다. VMware AppDefense는 MaaS의 새로운 예입니다.

XaaS의 다른 예로는 DRaaS (Disaster Recovery as a Service), CaaS (Communications as a Service) 및 NaaS (Network as a Service)가 있습니다.

XaaS의 장단점

서비스형 모델은 비용을 절감하고 IT 배포를 단순화할 수 있기 때문에 회사들은 종종 XaaS를 선택합니다. 모든 추가적인 클라우드 서비스를 통해 회사들은 사내 IT 인프라를 줄여서 서버, 하드 드라이브, 네트워크 스위치, 소프트웨어 배포 등을 줄일 수 있습니다.

IT 인프라가 적다는 것은 장비 공간, 전력 및 냉각과 같은 물리적 오버 헤드가 줄어든다는 의미입니다. 이는 IT 인력의 감소로 이어 지거나 IT 직원이 비즈니스를 위해 더 중요하고 부가가치가 높은 프로젝트에 집중할 수 있게 합니다. 또한 외부 서비스를 사용하면 많은 자본 비용 (Capex)이 비즈니스 운영 비용 (Opex)으로 전환됩니다.

이와같은 이점에도 불구하고, XaaS 서비스는 때때로 탄력성 및 인터넷 안정성 문제와 경쟁합니다. 일부 기업은 서비스 제공 업체의 환경 및 인프라에 대한 가시성을 높이기 위해 서비스 상태를 보다 잘 측정하고 보다 능동적인 역할을 수행할 수 있습니다. 또한, 사업을 중단하거나 인수하거나 특정 서비스를 중단하거나 기능 로드맵을 변경하는 서비스 제공 업체는 XaaS 사용자에게 심각한 영향을 줄 수 있습니다.

XaaS의 전망

클라우드 컴퓨팅과 유비쿼터스의 고대역폭 글로벌 인터넷 액세스의 조합은 XaaS 성장을 위한 유리한 환경을 제공합니다.

하지만, 모든 종류의 인프라 아웃소싱은 데이터로 신뢰하는 것을 의미하며, 항상 관련 위험이 있습니다. 특히 보안에 있어서는 더욱 그렇습니다. 결함이 있을 가능성이 높을수록 실패할 가능성이 더 높습니다.

일부 조직에서는 보안, 규정 준수 및 비즈니스 거버넌스 문제로 인해 XaaS를 채택하는데 망설일 수 있습니다. 그러나 서비스 제공 업체는 점점 더 이러한 문제를 해결하여 조직이 추가 워크로드를 클라우드로 가져올 수 있습니다.

슈노르 서명 (Schnorr Signature)의 탄생

디지털 서명은 온라인 주권(Sovereignty)의 중추입니다. 1976년에 공개키 암호가 출현하면서 글로벌 커뮤니케이션 매체, 인터넷 및 완전히 새로운 형태의 화폐인 비트코인(Bitcoin)을 탄생할 길을 열었습니다. 그 이후로 공개키 암호의 기본 속성은 많이 변경되지 않았지만 암호 작성기의 도구 상자에는 수십 개의 오픈 소스 디지털 서명 구조가 있습니다.

샤토시 나카모토(Satoshi Nakamoto)가 비트코인(Bitcoin)를 작업하기 시작했을때, 고려해야할 주요 설계 선택 사항중 하나는 개방적이고 허가 불필요한 금융 시스템에서 사용할 서명 방식이었습니다. 요구 사항은 명확했다. 샤토시(Satoshi)는 광범위하게 사용되고 잘 이해되고 안전하고 가볍고 가장 중요한 오픈소스 알고리즘을 필요로 했습니다. 당시 사용가능한 모든 옵션중에서 그는 ECDSA(Elliptic Curve Digital Signature Algorithm)과 같은 기준에 가장 적합한 옵션을 사용했습니다.

당시 ECDSA는 온라인 커뮤니케이션의 프라이버시를 향상시키기 위해 사이퍼펑크(Cypherpunk : 수신자만이 알 수 있는 암호로 정보를 보내는 사람) 베테랑들이 개발한 오픈 소스 암호화 도구인 OpenSSL에 의해 기본적으로 지원되었습니다. 다른 널리 사용되는 방식과 비교하여 ECDSA는 디지털 형태의 화폐를 위한 유용한 속성인 낮은 계산 요구 사항과 더 짧은 키 길이의 이점을 지니고 있습니다. 동시에 RSA와 같은 구조에 비슷한 수준의 보안을 제공했습니다. 예를 들어 256비트 ECDSA 키는 3,072 비트 RSA 키와 동등한 보안 기능을 갖습니다.

Pieter Wuille 및 다른 사람들이 secp256k1이라는 개선된 커브의 개발 노력 덕분에 (Elliptic Curve에서 처럼) 비트코인(Bitcoin)의 ECDSA가 보다 빠르고 효율적으로 수행되었습니다. 그러나 여전히 ECDSA에는 내재된 결함이 있습니다. 2년간의 연구와 실험끝에 비트코인(Bitcoin) 트랜잭션의 프라이버시와 효율성을 높이기 위해 슈미트 디지털 서명(Schnorr Digital Signature)인 새로운 서명 체계가 설정되었습니다.

슈노르 서명의 부상

슈노르 디지털 서명(Schnorr Digital Signature)가 ECDSA보다 많은 이점을 제공하더라도 확실히 새로운 것은 아닙니다. 그는 Claus-Peter Schnorr (독일의 암호 학자이자 학자)가 1980년대 프랑크푸르트 대학 (University of Frankfurt)의 교수이자 연구원이었을때 발명했습니다. 그의 제안된 서명 구조는 David Chaum, Taher EIgamal, Amos Fiat 및 Adi Shamir의 연구와 개발 작업이 융합된 것입니다. 그럼에도 불구하고 그것이 발표되기 전에 수년 동안 직접 사용하지 못하게 막은 새로운 발명 구조에 대한 특허를 클라우스 슈노르 (Claus Schnorr)가 가지고 있었습니다.

흥미롭게도 ECDSA의 전신인 DSA는 Claus Schnorr의 특허를 회피하기 위해 고안된 ElGamal과 Schnorr 혼합체였습니다. 실제로 Schnorr의 미국 특허가 발급된지 2개월 만에 DSA의 선구자인 미국 국립 표준 기술 연구소 (NIST)도 해결 방법에 대한 특허를 제출했습니다. 사이퍼펑크(Codypunks) 이력을 보면 Cloth Schnorr는 그의 특허에 대해 매우 방어적이었습니다.

슈노르 서명(Schnorr Signature)이 도입된지 거의 20년이 지난 2008년 Claus Schnorr의 특허가 만료되었습니다. 우연히도, 2008년은 우리가 가장 좋아하는 사이퍼펑크 샤토시 나코모토(Satoshi Nakamoto)가 비트코인(Bitcoin)을 구현한 해였습니다. 슈노르 서명(Schnorr Signature)이 당시 사용되었을지라도 표준화되거나 널리 사용되지는 않았지만 샤토시가 ECDSA 대신 사용하려는 동기였습니다. 암호 학자들과 수학자들에 의해 종종 혹평되었지만, ECDSA는 널리 사용되고 있었고 당시에는 비트코인(Bitcoin)을 위한 더 안전한 옵션을 제공했습니다.

비크코인에서의 슈노르

일부 알트코인(Altcoin)들의 인기있는 옵션이 ed25519와 같은 표준화된 구현으로 오늘날에는 덜 난해합니다. 비트코인(Bitcoin)에서 Schnorr를 구현할 가능성이 엿보인 비공식적인 회담은 2014년 BitcoinTalk 스레드로 거슬러 올라간다. 하지만 이 제안은 Pieter Wuille이 Schnorr BIP를 작성했을때 수년간의 연구와 실험을 거쳐 공식화되었다. 이 BIP 초안은 잠재적인 Schnorr 구현의 사양 및 기술을 기술하며 ECDSA에 비해 다음과 같은 이점을 제공합니다.

· 보안 증명 (Security Proof) : Schnorr 서명의 보안은 충분히 임의의 해시 함수(임의 오라클 모델)가 사용되고 서명에 사용된 ECDLP (이산 로그 문제)가 충분히 확고할때 쉽게 증명할 수 있습니다. 그러한 증명(Proof)는 ECDSA에는 존재하지 않습니다.

· 비유연성 (Non-malleability) : ECDSA 서명은 본질적으로 유연성이 있으므로 제3자가 기존의 유효한 서명을 변경하기 위해 개인 키에 액세스하지 않고도 가능하도록 할 수 있습니다. 이 문제는 BIP62에서 정식으로 논의되었습니다. 이와 대조적으로, 슈노르 서명(Schnorr Signature)는 비유연성 (Non-malleability)을 가지므로 이를 막을 수 있습니다.

· 선형성 (Linearity) : 슈노르 서명(Schnorr Signature)은 여러 당사자가 공동 키의 합계에 유효한 서명을 생성하기 위해 협업할 수있는 뛰어난 속성을 가지고 있습니다. 이것은 다중 서명 및 기타 스마트 계약과 같은 효율성 및 개인 정보 보호를 향상시키는 다양한 상위 수준의 구조을위한 구성 요소입니다.

Remote Desktop Protocol (RDP) 개요

RDP (Remote Desktop Protocol : 원격 데스크톱 프로토콜)는 Microsoft에서 개발한 프로토콜로 서버에서 실행되는 Windows 기반 응용 프로그램의 보안 네트워크 통신 프로토콜입니다.

RDP을 사용한 네트워크 연결을 통해 다른 컴퓨터에 연결할 수 있는 그래픽 인터페이스를 사용자에게 제공합니다. 사용자는 이를 사용하기 위해서 RDP 클라이언트 소프트웨어를 사용하지만 반대편 컴퓨터는 RDP 서버 소프트웨어를 실행해야 합니다.

RDP를 통해 네트워크 관리자는 개별 가입자가 겪고 있는 문제를 원격으로 진단하고 해결할 수 있습니다. RDP는 Windows 운영 체제와 Mac OS X의 대부분의 버전에서 사용할 수 있습니다. 오픈 소스 버전도 사용할 수 있습니다.

RDP는 여러 유형의 네트워크 및 여러 LAN 프로토콜을 지원하도록 설계되었습니다.

기본 아키텍처

RDP는 ITU T.120 프로토콜 패밀리를 기반으로 하며 확장됩니다. RDP는 암호화된 클라이언트 마우스 및 키보드 데이터뿐만 아니라 서버로부터 장치 통신 및 데이터를 전달하는 별도의 가상 채널을 허용하는 다중 채널 프로토콜입니다. RDP는 확장 가능한 기반을 제공하며 데이터 전송을 위한 최대 64,000개의 개별 채널과 다중 지점(Multipoint) 전송을 위한 기능을 지원합니다.

서버에서 RDP는 자체 비디오 드라이버를 사용하여 RDP 프로토콜을 사용하여 렌더링 정보를 네트워크 패킷으로 구성하고 네트워크를 통해 클라이언트로 전송함으로써 디스플레이 출력을 렌더링합니다. 클라이언트에서 RDP는 렌더링 데이터를 받고 해당 그래픽 장치 인터페이스 (GDI : Graphic Device Interface) API 호출로 패킷을 해석합니다. 입력 경로의 경우 클라이언트 마우스 및 키보드 이벤트가 클라이언트에서 서버로 전송됩니다. 서버에서 RDP는 자체 키보드 및 마우스 드라이버를 사용하여 이러한 키보드 및 마우스 이벤트를 수신합니다.

원격 데스크톱 세션에서는 RCP-Tcp 연결 설정에 따라 모든 환경 변수 (예 : 색상 깊이와 배경 화면 활성화 및 비활성화를 결정하는 변수)가 결정됩니다. 이는 원격 데스크톱 웹 연결 레퍼런스 (Remote Desktop Web Connection Reference) 및 원격 데스크톱 서비스 WMI 공급자 인터페이스(Remote Desktop Service WMI Provider Interface)에서 환경 변수를 설정하는 모든 함수 및 메서드에 적용됩니다.

A/B (Seamless) 시스템 업데이트 개요

심리스(Seamless) 업데이트라고도 하는 A/B 시스템 업데이트는 OTA (Over-The-Air) 업데이트 중에도 작동 가능한 부팅 시스템이 디스크에 남아 있도록 합니다. 이 방법은 업데이트후 장치의 비활성가능성을 줄여 주므로 수리 및 보증 센터에서 장치 교체 및 장치 리플래쉬(Reflash)가 줄어 듭니다. ChromeOS와 같은 다른 상업용 운영 체제에서도 A/B 업데이트를 성공적으로 사용됩니다.

A/B 시스템 업데이트는 다음과 같은 이점을 제공합니다.

l  OTA 업데이트는 시스템 실행중에 사용자 중단없이 발생할 수 있습니다. 사용자는 OTA도중에 장치를 계속 사용할 수 있습니다. 업데이트도중 유일한 중단 시간은 장치가 업데이트된 디스크 파티션으로 재부팅되는 경우입니다.

l  업데이트 후에는 재부팅이 일반 재부팅보다 더 소요되지 않습니다.

l  OTA가 되지 않는 경우 (예 : 불량 플래시로 인해) 사용자는 영향을 받지 않습니다. 사용자는 이전 OS를 계속 실행하며 클라이언트는 업데이트를 다시 시도할 수 있습니다.

l OTA 업데이트를 했지만 부팅에 실패하면 장치가 이전 파티션으로 재부팅되고 사용 가능한 상태로 유지됩니다. 클라이언트는 업데이트를 다시 시도할 수 있습니다.

l 오류 (예 : I/O 오류)는 사용되지 않은 파티션 세트에만 영향을 주며 재시도될 수 있습니다. 그러므로 사용자 경험을 저하시키지 않을 것입니다.

l 업데이트를 A/B 장치로 스트리밍할 수 있으므로 패키지를 설치하기 전에 다운로드할 필요가 없습니다. 스트리밍이란 사용자가 /data 또는 /cache에 업데이트 패키지를 저장할 충분한 여유 공간을 가질 필요가 없음을 의미합니다.

l 캐시 파티션은 더이상 OTA 업데이트 패키지를 저장하는데 사용되지 않으므로 캐시 파티션이 향후 업데이트를 위해 충분히 큰지 확인할 필요가 없습니다.

l dm-verity는 장치가 손상되지 않은 이미지를 부팅하도록 보장합니다. 장치가 잘못된 OTA 또는 dm-verity 문제로 인해 부팅되지 않으면 장치가 이전 이미지로 재부팅될 수 있습니다. (Android Verified Boot에는 A/B 업데이트가 필요하지 않습니다.)

A/B (Seamless) 시스템 업데이트에 대해

A/B 업데이트를 수행하려면 클라이언트와 시스템 모두를 변경해야 합니다. 그러나 OTA 패키지 서버는 변경이 필요하지 않습니다. 업데이트 패키지는 여전히 HTTPS를 통해 제공됩니다. Google의 OTA 인프라를 사용하는 기기의 경우 시스템 변경 사항이 모두 AOSP이며 클라이언트 코드는 Google Play 서비스에서 제공됩니다. Google의 OTA 인프라를 사용하지 않는 OEM은 AOSP 시스템 코드를 재사용할 수 있지만 자체 클라이언트를 제공해야 합니다.

자체 클라이언트를 제공하는 OEM의 경우 클라이언트는 다음을 수행해야 합니다.

l 업데이트를 할때를 결정합니다. A/B 업데이트가 백그라운드에서 발생하기 때문에 더이상 사용자가 시작하지 않습니다. 사용자 중단을 방지하려면 장치가 유휴 유지 관리 모드 (예 : 밤, Wi-Fi) 일때 업데이트를 예약하는 것이 좋습니다. 그러나 클라이언트는 원하는 휴리스틱(Heuristics)을 사용할 수 있습니다.

l OTA 패키지 서버에 로그린하여 업데이트를 가용한지 확인합니다. 이는 기기가 A/B를 지원한다는 신호를 보내고 싶다는 점을 제외하면 대부분 기존 클라이언트 코드와 동일해야 합니다. (Google의 고객은 사용자가 최신 업데이트를 확인하기 위해 '지금 확인' 버튼도 포함합니다.)

l 업데이트 패키지의 HTTPS URL로 update_engine을 호출합니다. update_engine은 업데이트 패키지를 스트리밍할때 현재 사용되지 않는 파티션의 블록을 업데이트합니다.

l update_engine 결과 코드에 따라 설치 성공 또는 실패를 서버에 보고합니다. 업데이트가 성공적으로 적용되면 update_engine은 다음 재부팅시 새 OS로 부팅하도록 부트 로더에 지시합니다. 새로운 OS가 부팅에 실패하면 부트 로더가 이전 OS로 대체되므로 클라이언트에서 작업할 필요가 없습니다. 업데이트가 실패하면 클라이언트는 자세한 오류 코드를 기반으로 다시 시도할 시기를 결정해야 합니다.

옵션으로 클라이언트는 다음을 수행할 수 있습니다.

l 사용자에게 재부팅하라는 알림을 표시합니다. 사용자가 정기적으로 업데이트하도록 권장하는 정책을 구현하려는 경우 이 알림을 클라이언트에 추가할 수 있습니다. 클라이언트가 사용자에게 확인 메시지를 표시하지 않으면 사용자는 다음 번에 다시 부팅할때 업데이트를 받게 됩니다.

l 사용자에게 새로운 OS 버전으로 부팅했는지 또는 이전 OS 버전으로 되돌아 갔는지 여부를 알려주는 알림을 표시합니다.

시스템 측면에서 A/B 시스템 업데이트는 다음 사항에 영향을 미칩니다.

l 파티션 선택 (슬롯), update_engine daemon 및 부트 로더 상호 작용

l 빌드 프로세스 및 OTA 업데이트 패키지 생성

JPEG XS의 개요

JPEG는 수십년 동안 이미지에 대한 압축 표준 이었지만 파일 형식은 곧 더나은 가상 현실 체험에서 더 안전한 무인 항공기 및 자가 운전 차량에 이르기까지 스트리밍하는 동안 지연 시간을 없애기 위해 설계된 JPEG XS을 곧 확보하게 될 것입니다. JPEG의 조직인 Joint Photographic Experts Group은 최근에 적은 에너지를 사용하도록 설계된 압축된 사진 및 비디오 파일 형식인 JPEG XS를 도입했습니다.

JPEG XS는 파일 크기가 실제로 JPEG보다 작지 않기 때문에 약간의 잘못된 표현입니다. 실제로 압축 파일은 더 많은 공간을 차지합니다. XS는 파일의 압축 프로세스를 나타냅니다. JPEG XS는 원본 JPEG보다 빠르고 간단하게 압축합니다. 따라서 JPEG XS는 하드 드라이브나 스마트폰에서 더 많은 공간을 차지하지만 파일은 Wi-Fi 또는 5G를 사용하여 더빨리 스트리밍됩니다. 파일이 실제로 일반 JPEG보다 크기 때문에 파일 유형은 고품질인 동시에 스트리밍 프로세스의 속도를 높입니다.

일반 조직은 JPEG를 대체하려고 하지않고 있습니다. 원본 JPEG의 작은 파일 크기는 스트리밍하지 않고 파일이 저장되는 응용프로그램에 원래의 이상적인 형태를 만듭니다. 대신 JPEG XS는 스트리밍 컨텐츠와 관련된 여러가지 문제를 완화하는 것을 목표로 합니다. 예를 들어 더 빠른 스트림을 만들어 JPEG XS는 무인 항공기 카메라가 보는 것과 무인 항공기 조종사가 실제로 같은 것을 보는 시각 사이의 지연 시간을 줄일 수 있습니다. 이와 같은 아이디어로 비슷하게 자가 운전 자동차를 더욱 안전하게 만드는데 도움이 될 수 있습니다.

그렇지만 스트림이 빨라지고 대기 시간이 짧아지는 것은 실시간 스트리밍 콘텐츠에만 국한되지 않습니다. 이 그룹은 가상 현실에서 움직임과 움직임에 대한 거의 감지할 수 없는 반응간의 지연이 일부 헤드셋 사용자가 경험에서 구역질을 느낄 수 있는 이유중 하나라고 설명합니다. 이 파일 형식을 사용하면 스마트폰에서 화면으로 (무선으로) 더 빨리 비디오를 공유할 수 있습니다.

또한 압축 속도가 빠를수록 해상도가 높아지고 8K로 스트리밍하는 것과 같이 프레임 속도가 높아질 수 있다고 합니다. 이 파일 포맷은 심지어 유럽 우주국 (European Space Agency)의 눈을 사로 잡았습니다. 이 그룹은 이 포맷이 더 적은 에너지를 사용하기 때문에 우주 프로브에서 이 포맷을 사용하는 것에 관심이 있습니다.

Touradj Ebrahimi 교수는 스위스의 기술 대학인 Ecole Polytechnique Federale De Lausanne에서 공학부의 일원으로 이 그룹의 업무를 이끌고 있습니다. "이미지 코딩의 역사에서 처음으로 우리는 품질을 더 잘 유지하기 위해 압축을 줄이고 에너지를 적게 사용하면서 프로세스를 더 빠르게 만들고 있습니다"라고 Ebrahimi는 성명서에서 말했습니다. "아이디어는 더 적은 리소스를 사용하고 더 현명하게 사용하는 것입니다. 이것은 진정한 패러다임의 변화입니다. "

원본 JPEG와 마찬가지로 JPEG XS도 오픈소스 파일 형식으로 예정되어 있습니다. 이러한 접근성은 오픈소스 때문에 보편적으로 허용되는 파일 형식이 될 수 있기 때문에 편집을 위한 형식을 고려하는 영화 및 텔레비전 학회 (Society of Motion Picture and Television Engineers)가 있습니다.

JPEG XS가 널리 채택되기 전에 국제 표준화기구 (International Organization for Standardization)는 아직 파일 형식을 승인하지 않았습니다. 일단 승인되면 Ebrahimi는 새로운 하드웨어가 이 형식을 채택할 수 있고 소프트웨어는 업데이트해야 한다고 말합니다.

"곧 JPEG XS는 영화 편집, 우주 화상 및 전문 등급 카메라와 같은 전문 응용 프로그램에 사용될 예정입니다. 자동차, 가상 현실, 증강 현실, 멀티미디어 장치와 TV 모니터 또는 프로젝터간의 무선 연결을 포함하는 가전 제품이 다음에 나올 것입니다".

"JPEG XS를 사용하려면 소비자가 차세대 장치를 보유해야 합니다. 소프트웨어 측면에서 볼때, 그들은 어쨌든 컴퓨터와 스마트폰에서 수시로 업데이트하는 것처럼 업데이트를 해야할 필요가 있습니다.".