hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
넷부트
넷부트(NetBoot)는 애플의 기술로, 유능한 펌웨어(즉, 뉴 월드 롬)를 갖춘 맥이 로컬 하드 디스크나 광학 디스크 드라이브 대신 네트워크에서 부팅할 수 있도록 했다. 넷부트는 부트스트랩 프로토콜(BOOTP)에서 파생된 작업이며, 사전 부팅 실행 환경과 개념이 유사하다. 이 기술은 1999년 1월 5일 맥월드 엑스포에서 맥 OS X 서버의 원래 버전의 일부로 발표되었다. 넷부트는 애플의 핵심 시스템 관리 기술로 계속 사용되어 왔으며, 최신 Mac Intel 시스템을 지원하도록 적용되었다. 넷부트, USB, 파이어와이어는 운영체제 재설치를 위한 외부 볼륨 옵션 중 일부이다. 넷부트는 T2 보안 칩이 탑재된 최신 Mac 또는 애플 실리콘에서는 지원되지 않는다.
넷부트 과정
macOS, macOS 서버, 맥 OS 9, 또는 맥 OS 8 사본이 포함된 디스크 이미지는 시스템 이미지 유틸리티를 사용하여 생성되며 일반적으로 macOS 서버인 서버에 저장된다. 클라이언트는 HTTPS, AFP, TFTP, NFS, 및 멀티캐스트 애플 소프트웨어 리스토어(ASR)를 포함한 많은 인기 프로토콜을 사용하여 네트워크를 통해 이 이미지를 수신한다. 서버 측 넷부트 이미지는 전체 시스템을 부팅할 수 있지만, 넷부트는 노턴 고스트와 다소 유사하게 운영체제 및 소프트웨어 전개에 더 일반적으로 사용된다.
클라이언트 시스템은 먼저 DHCP를 통해 네트워크 구성 정보를 요청한 다음, BSDP를 사용하여 부팅 이미지 및 서버 목록을 요청하고 위에 언급된 프로토콜을 사용하여 이미지를 다운로드한다.
인텔 및 파워PC 기반 서버 모두 인텔 및 파워PC 기반 클라이언트를 위한 이미지를 제공할 수 있다.
넷부트 넷인스톨
넷인스톨은 macOS 서버의 유사한 기능으로, 넷부트와 ASR을 활용하여 네트워크 클라이언트(일반적으로 첫 부팅 시)에 설치 이미지를 전달한다. 넷부트와 마찬가지로 넷인스톨 이미지는 시스템 이미지 유틸리티를 사용하여 생성할 수 있다. 넷인스톨은 사전 부팅 실행 환경(Preboot Execution Environment)에 의존하는 마이크로소프트 클라이언트를 위한 윈도우 디플로이먼트 서비스(Windows Deployment Services)와 유사한 기능을 macOS에 제공한다.
넷부트 레거시
맥 OS 8.5 및 맥 OS 9는 IP 정보를 얻기 위해 BOOTP/DHCP만을 사용하고, 이어서 맥 OS 롬 파일의 TFTP 전송을 수행한다. 다음으로, 클라이언트 디스크 이미지가 있는 두 볼륨이 TCP를 통한 애플토크로 마운트된다. 대체로 클래식 맥 OS는 세 가지 이미지를 사용한다. 운영체제와 응용 프로그램을 포함할 수 있는 시스템 이미지. 다음으로, 읽기 전용 시스템 이미지 위에 오버레이로 프라이빗 이미지(또는 스크래치 디스크)가 마운트된다. 마지막으로 응용 프로그램 이미지가 마운트된다. 그러나 이 이미지는 비어 있을 수 있다.
페스터 파워
페스터 파워(영어: Pester Power)는 아동이 부모나 보호자에게 특정 제품의 구매를 끈질기게 요구하거나 졸라서 소비 결정에 영향을 미치는 능력을 일컫는 마케팅 및 사회학 용어이다. 이를 마케팅 업계에서는 잔소리 효과(영어: The Nag Factor)라고도 부르며, 기업이 구매력이 없는 아동을 대상으로 마케팅을 펼쳐 최종적으로 구매력을 가진 부모의 지갑을 열게 만드는 간접적인 판매 전략을 설명할 때 주로 사용된다. 이는 현대 자본주의 사회에서 아동이 단순히 보호의 대상을 넘어 가정 내 소비의 강력한 인플루언서이자 주체적인 경제 행위자로 부상했음을 보여주는 대표적인 현상이다.
페스터 파워 개요
전통적인 가부장적 가정 구조에서는 경제권을 가진 부모가 독단적으로 소비를 결정하는 것이 일반적이었다. 그러나 20세기 후반 들어 핵가족화가 가속화되고 맞벌이 부부가 증가하면서 부모가 자녀와 함께 보내는 시간이 줄어들었고, 이에 대한 보상 심리로 물질적 요구를 들어주는 경향이 강해졌다. 동시에 사회 전반적으로 아동 중심의 양육 문화가 확산됨에 따라 가정 내 의사결정 과정에서 자녀의 발언권이 비약적으로 상승했다. 마케터들은 이러한 사회적 변화를 포착하여 부모를 직접 설득하는 것보다, 브랜드에 대한 충성도가 쉽게 형성되고 욕구 표현이 즉각적인 아동을 공략하는 것이 훨씬 효율적이라는 사실을 발견했다. 이로 인해 아동용 장난감이나 제과류뿐만 아니라 외식 메뉴, 휴가지 선정, 전자제품, 심지어 자동차 구매에 이르기까지 가족 소비 전반에 걸쳐 아동의 영향력이 확대되는 결과가 나타났다. 텍사스 A&M 대학교의 마케팅 교수였던 제임스 맥닐은 아동이 세 가지 시장(직접 구매자, 부모 구매의 영향력 행사자, 미래의 잠재 고객)으로서 기능한다고 분석하며 이들의 영향력을 강조하였다.
페스터 파워 심리학적 기제와 유형
페스터 파워가 작동하는 심리학적 원리는 부모의 죄책감과 피로감, 그리고 자녀의 사회적 소속감 욕구와 맞물려 있다. 마케팅 전문가 제임스 맥닐은 아이들의 조르기를 크게 두 가지 유형으로 구분하여 설명한다. 첫째는 끈질긴 조르기이다. 이는 주로 연령이 낮은 아동에게서 나타나며, 원하는 것을 얻을 때까지 떼를 쓰거나 울거나 같은 요구를 무한히 반복하는 형태를 띤다. 부모는 아이의 이러한 행동을 멈추게 하기 위해, 혹은 공공장소에서의 소란을 피하기 위해 항복하듯 제품을 구매하게 된다. 둘째는 중요성 강조 조르기이다. 이는 인지 능력이 다소 발달한 아동이 사용하는 방식으로, 특정 제품이 자신의 학교생활이나 교우 관계 유지에 필수적이라는 논리를 내세우는 것이다. 부모는 자녀가 또래 집단에서 소외되거나 뒤처질 것을 우려하여, 교육적 혹은 사회적 적응을 돕는다는 명분으로 구매를 합리화하게 된다.
페스터 파워 디지털 환경과 변화
과거의 페스터 파워가 주로 텔레비전 광고나 만화 영화 중간의 광고 시간을 통해 형성되었다면, 21세기에 들어서는 유튜브, 소셜 미디어, 모바일 게임 등 디지털 플랫폼으로 그 무대가 확장되었다. 특히 키즈 인플루언서의 등장은 페스터 파워를 더욱 강력하고 정교하게 만들었다. 아이들은 유튜브에서 또래의 유튜버가 장난감을 개봉하고 즐겁게 노는 영상을 시청하며, 광고라고 인식하지 못한 채 자연스럽게 해당 제품에 대한 강한 소유욕을 가지게 된다. 알고리즘에 기반한 맞춤형 콘텐츠 추천 시스템은 아이들이 관심 있어 할 만한 상업적 콘텐츠를 끊임없이 노출시킴으로써 구매 욕구를 지속적으로 자극한다. 이는 부모가 통제하기 어려운 수준으로 아이들의 소비 욕구를 부추기며, 전통적인 미디어 환경보다 훨씬 더 직접적이고 강력한 구매 압력을 행사하게 만든다.
페스터 파워 사회적 영향 및 비판
페스터 파워에 의존한 마케팅 전략은 다양한 사회적, 윤리적 비판에 직면해 있다. 가장 큰 문제는 아동의 미성숙한 판단력을 상업적으로 악용한다는 점이다. 미국 심리학회는 아동이 광고의 설득적 의도를 파악하는 인지 능력이 부족하기 때문에 광고에 취약하며, 이는 공정한 거래가 아니라고 지적한 바 있다. 또한 이러한 현상은 아동 비만 문제와도 밀접하게 연관되어 있다. 고열량, 저영양 식품 업체들이 페스터 파워를 적극 활용하여 아이들이 부모에게 패스트푸드나 가공식품을 사달라고 조르게 만듦으로써 식습관을 저해한다는 비판이 제기된다. 경제적으로는 부모와 자녀 간의 갈등을 유발하는 주된 원인이 되기도 한다. 경제적 여건이 넉넉하지 않은 가정의 부모는 자녀의 요구를 들어주지 못한다는 죄책감과 스트레스를 겪게 되며, 이는 상대적 박탈감과 가정 불화로 이어질 수 있다.
페스터 파워 규제 현황
세계 각국 정부와 규제 기관은 페스터 파워의 부작용을 최소화하고 아동을 상업적 착취로부터 보호하기 위해 다양한 법적 장치를 마련하고 있다. 스웨덴과 노르웨이는 12세 미만 아동을 대상으로 하는 텔레비전 상업 광고를 원천적으로 금지하는 강력한 법안을 시행 중이며, 이는 아동 마케팅 규제의 대표적인 모범 사례로 꼽힌다. 캐나다 퀘벡주 역시 소비자 보호법을 통해 13세 미만 아동을 겨냥한 모든 형태의 상업 광고를 불법으로 규정하고 있다. 영국과 미국 등지에서는 아동 프로그램 전후에 고지방, 고당분 식품 광고를 제한하는 등의 가이드라인을 두고 있으며, 최근에는 유럽연합 등을 중심으로 디지털 미디어 환경 변화에 맞춰 유튜브나 게임 내 타겟팅 광고에 대한 규제 논의도 활발히 진행되고 있다.
ARC (시방서)
ARC(Advanced RISC Computing)는 더 이상 존재하지 않는 컴퓨터 제조업체 컨소시엄(Advanced Computing Environment 프로젝트)이 만든 시방서로, 표준 MIPS RISC 기반 컴퓨터 하드웨어 및 펌웨어 환경을 정의한다. ARC와 호환되는 알파 머신의 펌웨어는 알파바이오스(AlphaBIOS)로 알려져 있으며, 알파의 비 ARC 펌웨어는 SRM으로 알려져 있다.
ARC (시방서) 역사
ACE는 사라졌고 ARC 표준을 완전히 준수하는 컴퓨터는 제조되지 않았지만, ARC 시스템은 윈도우 NT 계열의 모든 운영 체제가 부팅 장치 명명에 ARC 규칙을 사용한다는 점에서 광범위한 유산을 가지고 있다. SGI의 수정된 ARC 펌웨어 버전은 ARCS라고 명명되었다. IRIX 6.1 이상을 실행하는 인디 및 옥테인과 같은 모든 SGI 컴퓨터는 윈도우와 동일한 드라이브 명명 규칙을 사용하는 ARCS 콘솔에서 부팅된다. 윈도우 NT를 실행하도록 설계된 다양한 RISC 기반 컴퓨터의 대부분은 NT를 부팅하기 위한 ARC 부팅 콘솔 버전을 가지고 있다. 여기에는 다음이 포함된다.
인텔 IA-32 기반 컴퓨터가 ARC 콘솔을 채택할 것으로 예측되었지만, SGI만이 1999년에 출시된 SGI 비주얼 워크스테이션 시리즈와 같은 ARC 펌웨어 기반 머신을 시장에 내놓았다.
ARC (시방서) UEFI와의 비교
UEFI와 비교할 때, ARC 펌웨어는 FAT, 부팅 변수, C-호출 인터페이스를 지원했다. 하지만 UEFI와 같은 수준의 확장성과 UEFI 포럼과 같은 수준의 거버넌스를 포함하지 않았다.
ARC (시방서) 부분적으로 ARC 호환되는 컴퓨터 목록
ARC 표준을 (어느 정도) 준수하는 제품은 다음과 같다.
MIPS
에이서 PICA
카레라 컴퓨터스 코브라 R4000 및 VIPER
디지털 DEC스테이션 5000
데스크스테이션 타인
마이크로소프트 재즈
MIPS 매그넘
올리베티 M700
NEC RISC스테이션
네트파워 패스트시리즈 MP
SGI 인디고², 인디, 챌린지, 오닉스, 오리진 등 빅 엔디언 ARCS
지멘스-닉스도르프 RM200, RM300, RM400
리눅스부트
리눅스부트(LinuxBoot)는 자유 소프트웨어 프로젝트로, 통일 확장 펌웨어 인터페이스(UEFI) 펌웨어의 대부분의 드라이버 실행 환경(DXE) 모듈을 리눅스 커널로 대체하는 것을 목표로 한다. 리눅스부트는 시작하기 위해 하드웨어 초기화 소프트웨어 위에서 실행되어야 한다. 이는 UEFI의 Pre-EFI 초기화(PEI) 부분, 코어부트, 또는 U-부트가 될 수 있다. kexec syscall을 통해 리눅스를 부팅할 수 있지만, 다른 방법으로 윈도우도 부팅할 수 있다.
리눅스부트 역사
원래 이 프로젝트는 구글이 NERF라는 이름으로 시작했다. NERF는 리눅스 커널과 사용자 영역 애플리케이션을 포함하는 간소화된 EFI 버전이었다. 이 프로젝트는 부트블록과 커널을 포함하는 리눅스부트와 사용자 영역 애플리케이션을 포함하는 u-root로 분할되었다.
리눅스부트는 2018년에 리눅스 재단의 공식 프로젝트가 되었다.
리눅스부트 하드웨어 지원
현재 리눅스부트의 EFI 지원은 몇몇 서버에만 국한되어 있다.
리눅스부트는 이론적으로 코어부트 프로젝트에서 지원하는 모든 메인보드에서도 지원되는데, 여기에는 OCP 모놀레이크도 포함된다. 실제로는 플래시 크기 제약으로 인해 지원이 제한된다.
아크로니스
아크로니스 인터내셔널 GmbH(Acronis International GmbH)는 사이버 보안 및 데이터 보호 소프트웨어를 전문으로 하는 스위스의 글로벌 기술 기업이다. 스위스 샤프하우젠에 본사를 두고 있으며, 관리 서비스 제공업체(MSP), 중소기업(SMB), 기업 IT 환경을 위한 백업, 재해 복구, 엔드포인트 관리 및 사이버 보안 솔루션을 개발한다. 2025년, 스웨덴 사모펀드 EQT가 아크로니스의 대다수 지분을 인수했다.
아크로니스 제품은 Microsoft 365, Google Workspace, AWS, Azure와 같은 플랫폼을 지원한다.
아크로니스 역사
아크로니스는 2003년 싱가포르에서 서지 벨, 스타니슬라프 프로타소프, 일리야 주바레프가 SWsoft (이후 Parallels로 알려짐)에서 분사하여 설립되었다. 초기에는 주력 제품인 아크로니스 트루 이미지를 통해 디스크 이미징 및 백업에 중점을 두었다. 2008년 스위스에서 법인화되었다.
이 회사는 2012년 GroupLogic, 2014년 BackupAgent 및 nScaled를 인수하며 확장을 이어갔다. 회사에 따르면, 아크로니스 트루 이미지 2017 뉴 제너레이션은 "아크로니스 액티브 프로텍션" 기능을 통해 행동 기반 랜섬웨어 방지 기능을 포함하고, "아크로니스 공증"을 통해 블록체인 기반 파일 공증 기능을 포함한 최초의 개인 백업 소프트웨어였다.
추가 인수로는 2019년 5nine Software와 2020년 DeviceLock 및 CyberLynx가 있었다. 같은 해, 아크로니스는 백업과 사이버 보안을 통합한 사이버 프로텍트 플랫폼을 출시했다. 이 회사는 ConnectWise 및 Microsoft Azure와 같은 플랫폼과의 통합을 지원한다.
아크로니스 재무
2019년, 아크로니스는 골드만삭스로부터 1억 4,700만 달러를 유치하여 10억 달러 이상의 기업 가치를 달성했다. 2021년 CVC 캐피탈 파트너스가 주도한 2억 5,000만 달러의 투자 유치로 기업 가치는 25억 달러 이상으로 증가했다.
2025년, 아크로니스는 스톡홀름에 본사를 둔 스웨덴 사모펀드 EQT가 대다수 지분을 소유하게 되었다.
 Ezequiel Steiner CEO에 따르면, EQT의 투자는 아크로니스에 추가적인 경영 "두뇌"와 함께 더 넓은 시장, 모범 사례 및 벤치마킹에 대한 향상된 이해를 가져다준다. 이 인수는 2025년에 예상되는 연방 규제 승인 절차를 거쳐야 한다.
아크로니스 운영
아크로니스는 북미, 유럽, 아시아, 중동에 사무실을 두고 있으며, 불가리아, 미국, 이스라엘, 싱가포르에 R&D 센터를 운영한다. 전 세계 클라우드 데이터 센터 네트워크를 운영하고 있으며, 약 750,000개의 전 세계 기업을 보호하는 20,000개 이상의 서비스 제공업체를 지원한다.
2025년 9월 15일, 미국 국가정보국장은 정보기관에서 모든 아크로니스 제품 및 서비스를 배제하고 제거하도록 명령했다. 이 명령은 FAR Subpart 4.23에 따라 정보기관 및 민감한 분할 정보 시스템에만 적용된다. DNI 명령은 연방 조달 보안 협의회(FASC)의 권고에 기반한다. 그러나 FASC나 DNI 모두 아크로니스 제품 또는 프로세스 내에서 어떠한 취약점도 확인하지 못했다. 이 명령은 아크로니스나 그 파트너가 미국 정보기관 외의 다른 고객에게 서비스를 제공하는 것을 막지 않는다.
아크로니스 리더십
2025년 현재, 아크로니스의 경영진에는 Ezequiel Steiner의 뒤를 이은 CEO 얀-야프 야거와 회장 워렌 애들먼이 포함된다. EQT의 대다수 지분 인수 후, EQT 파트너 요하네스 라이헬은 전략 이사회 대표로 활동한다.
아크로니스 거버넌스
2025년 여름 현재, 다음 개인들이 아크로니스 이사회에서 활동하고 있다:
Limine
Limine은 휴대용 부트로더이자 Limine 부팅 프로토콜의 참조 구현이다. Multiboot2, 체인로딩, 그리고 리눅스 부팅 프로토콜도 지원된다. Limine은 ISO-9660 및 FAT 파일 시스템을 지원한다.
Limine은 GNU GRUB과 같은 부트로더에 대한 더 강력한 대안을 제공하는 것을 목표로 하며, 또한 부팅 후 커널 개발자가 작동 가능한 64비트 환경을 만드는 데 필요한 작업량을 줄이는 것을 목표로 멀티부트 사양의 대안으로 자체 부팅 프로토콜을 제공한다.
Limine은 여러 리눅스 배포판에 포함되어 있으며, 아치 리눅스에서는 archinstall의 옵션으로 제공된다. EasyOS (퍼피 리눅스의 파생), CachyOS, 그리고 Chimera Linux에도 포함되어 있다. Limine은 또한 Cosmos에서 사용되며 SerenityOS에서 지원된다.
인스턴트 온
컴퓨팅에서 인스턴트 온(instant-on)은 거의 즉시 부팅하여 PC의 기존 운영체제가 시작될 때까지 기다릴 필요 없이 온라인에 접속하거나 특정 애플리케이션을 사용할 수 있는 기능을 말한다. 인스턴트 온 기술은 오늘날 대부분 노트북, 넷북, 넷톱에 사용된다. 왜냐하면 사용자가 PC의 운영체제가 부팅될 때까지 기다리는 대신 하나의 프로그램을 부팅할 수 있기 때문이다. 이를 통해 사용자는 전체 운영체제가 필요 없이 영화 재생 프로그램이나 웹 브라우저와 같은 단일 프로그램을 실행할 수 있다. 부팅 문서에 설명된 것처럼 아타리 ST와 같이 여전히 몇몇 진정한 인스턴트 온 기기가 남아 있다. 이 기기들은 현재 컴퓨터 아키텍처에서 BIOS 기능이 일반적으로 제공되는 방식과 유사하게 완전한 운영체제가 ROM에 상주했다. 여기서 사용되는 "인스턴트 온" 개념은 작은 하드 드라이브 공간을 가진 레거시 시스템 DOS와 같은 OS를 로드하는 데서 비롯된다. 기계식 드라이브 성능에 내재된 대기 시간은 라이브 USB 또는 라이브 SD 플래시 메모리를 사용하여 시스템을 몇 배 더 빠른 전자 속도로 로드함으로써 제거할 수도 있다.
인스턴트 온 타임라인
델은 2008년 8월 13일 자사의 Latitude 노트북 라인에 "인스턴트 온"을 지원할 것이라고 발표했다. 이는 "전용 저전압 서브 프로세서와 OS를 활용하여 며칠 동안 지속되는 배터리 수명을 가능하게 하며, 시스템의 주 운영체제(OS)로 부팅할 필요 없이 이메일, 캘린더, 첨부 파일, 연락처 및 웹에 거의 즉시 접근할 수 있게 해준다..." 이 OS는 리눅스 변형을 실행할 것이다.
인스턴트 온 소비자 가전제품
과거 소비자 가전제품 제조업체들은 라디오와 텔레비전에 "인스턴트 온" 또는 "인스턴트 플레이" 데칼을 붙이곤 했다. 직렬 필라멘트 장치에서는 전원 스위치에 실리콘 다이오드를 추가하여 진공관 필라멘트를 50% 전력으로 유지함으로써 인스턴트 온이 달성되었다. 다이오드는 당시의 일반적인 반파 정류기가 역방향 바이어스되도록 배치되었다. 인스턴트 온의 장점으로는 텔레비전이나 라디오의 거의 즉각적인 작동과 잠재적으로 더 긴 진공관 수명이 포함되었다. 단점으로는 에너지 소비와 화재 위험이 있었다. 대부분의 고체 소비자 가전제품은 본질적으로 인스턴트 온이므로, 이 명칭은 초기 고체 시대까지 살아남아 진공관 기반 제품(특히 CRT)과 차별화되었다.
안드로이드 장치 부팅 프로세스
안드로이드 장치의 부팅 프로세스는 SoC(시스템 온 칩) 전원 인가 시 시작되어 홈 화면이 보이거나 삼성 장치의 경우 복구, 패스트부트, 또는 오딘 모드와 같은 특수 모드에서 종료된다. 안드로이드를 실행하는 장치의 부팅 프로세스는 SoC 제조업체의 펌웨어 설계에 영향을 받는다.
안드로이드 장치 부팅 프로세스 배경
2018년 기준으로 안드로이드 시장의 SoC 90%는 퀄컴, 삼성 또는 미디어텍 중 한 곳에서 공급한다. 다른 공급업체로는 UNISOC, 록칩, 마벨, 엔비디아가 있으며, 이전에는 텍사스 인스트루먼트가 있었다.
안드로이드 장치 부팅 프로세스 역사
부팅 보안 조치인 검증된 부팅은 안드로이드 킷캣과 함께 도입되었다.
안드로이드 장치 부팅 프로세스 단계
부트 ROM에 저장된 주 부트로더(PBL)는 부팅 프로세스의 첫 번째 단계이다. 이 코드는 칩셋 제조업체가 작성한다.
PBL은 다음 단계의 진위를 확인한다.
삼성 스마트폰에서는 부트 ROM이 삼성 보안 부트 키(SSBK)를 사용하여 다음 단계들을 확인한다.
퀄컴의 SoC에서는 주 부트로더에서 퀄컴 긴급 다운로드 모드에 진입할 수 있다.
보조 부트로더 검증에 실패하면 EDL에 진입한다.
부트 ROM의 공간이 제한적이므로 eMMC 또는 eUFS에 보조 부트로더가 사용된다. 보조 부트로더는 트러스트존을 초기화한다.
예를 들어, 퀄컴 MSM8960에서는 보조 부트로더 1이 보조 부트로더 2를 로드한다. 보조 부트로더 2는 트러스트존과 보조 부트로더 3을 로드한다.
퀄컴은 이제 SBL을 UEFI 구현체인 XBL이라고 부른다.
안드로이드 장치 부팅 프로세스 단계
퀄컴은 LK(Little Kernel) + Aboot 또는 XBL(eXtensible Bootloader) + ABL을 사용하고, 삼성 엑시노스는 S-Boot를 사용하며, 미디어텍은 Das U-Boot를 사용한다. 리틀 커널은 임베디드 시스템을 위한 마이크로커널로, 퀄컴이 부트로더로 사용하기 위해 수정했다. 안드로이드 부트로더(Aboot 또는 ABL)는 패스트부트 인터페이스를 구현한다. 이 인터페이스는 부트 및 복구 파티션의 진위를 확인한다. 특정 키 조합을 누르면 장치는 복구 모드로도 부팅할 수 있다. 그런 다음 안드로이드 부트로더는 제어권을 리눅스 커널로 넘긴다.
initramfs는 작은 루트 파일 시스템을 포함하는 gzip 압축된 cpio 아카이브이다. 여기에는 실행되는 init이 포함되어 있다. 안드로이드 커널은 리눅스 커널의 수정된 버전이다. Init은 파티션을 마운트한다. dm-verity는 fstab 파일에 지정된 파티션의 무결성을 확인한다. dm-verity는 안드로이드 버전 4.4부터 구글이 도입한 리눅스 커널 모듈이다. 기본 구현은 블록 기반 검증만 지원하지만, 삼성은 파일 지원을 추가했다.
안드로이드 장치 부팅 프로세스 단계
자이고트는 init 프로세스에 의해 생성되며, 안드로이드 애플리케이션 및 서비스 프로세스를 시작하는 역할을 한다. 이 프로세스는 매우 자주 사용될 것으로 예상되는 클래스를 힙에 로드하고 초기화한다. 예를 들어, 라이브러리의 덱스(dex) 데이터 구조가 있다. 자이고트가 시작되면 소켓에서 명령을 수신 대기한다. 새 애플리케이션이 시작될 때 자이고트에게 명령이 전송되며, 자이고트는 fork() 시스템 호출을 실행한다.
안드로이드 장치 부팅 프로세스 파티션 레이아웃
안드로이드 시스템은 여러 파티션으로 나뉘어 있다.
퀄컴 플랫폼은 GUID 파티션 테이블을 사용한다. 이 사양은 UEFI 사양의 일부이지만 UEFI 펌웨어에 의존하지 않는다.
리브레부트
리브레부트(Libreboot, 짧게 GNU 리브레부트)는 지원되는 X86-64 및 AArch64 컴퓨터에서 일부 독점 바이오스 또는 통일 확장 펌웨어 인터페이스 펌웨어를 대체하는 것을 목표로 하는 코어부트 기반의 자유-오픈 소스 소프트웨어 프로젝트이다. 리브레부트는 리눅스 또는 FreeBSD와 같은 32비트 또는 64비트 운영체제를 로드하고 실행하는 데 필요한 CPU 초기화 또는 메모리 컨트롤러 초기화와 같은 기본적인 기계 설정을 수행한다.
리브레부트 특징
리브레부트는 코어부트의 배포판으로 설립되었지만, 코어부트에서 일부 독점 바이너리 블롭이 제거되었다. 리브레부트는 빌드 및 설치 프로세스를 자동화하여 코어부트를 쉽게 사용할 수 있도록 한다.
일부 장치에서 리브레부트 개발자들은 인텔의 펌웨어를 리버스 엔지니어링하여 인텔 사양을 충족하는 자유 펌웨어를 생성하는 유틸리티를 만들었다. 하드웨어 지원에는 ASUS KGPE-D16, 씽크패드 T400, X60 및 X200이 포함되지만 이에 국한되지는 않는다. 리브레부트는 상위 코어부트 프로젝트로부터 공식적으로 승인되었다.
리브레부트 역사
리브레부트 프로젝트는 비자유 바이너리 블롭을 제외하는 코어부트의 배포판으로 2013년 12월에 시작되었다. 코어부트는 1999년 로스앨러모스 국립연구소 (LANL)에서 리눅스바이오스(LinuxBIOS)로 시작되었으며, 2008년에 "코어부트"로 이름이 변경되었다.
리브레부트는 자유 소프트웨어 재단의 승인을 받았으며, 2016년 5월부터 GNU 프로젝트의 공식적인 일부가 되었다. 2017년 1월, 프로젝트 관리자 레아 로우는 GNU를 감독하는 자유 소프트웨어 재단과의 수개월간의 분쟁 끝에 GNU 프로젝트에서 리브레부트를 철회했다.
리브레부트 평가
2015년에 카일 랭킨은 리눅스 저널에서 리브레부트가 "몇 가지 주의사항"과 함께 플래싱 프로세스를 "크게 단순화하고 자동화"했다고 밝혔다. 2016년 브라이언 콕필드는 Hackaday에서 리브레부트 설치가 "끔찍했으며" "생각만큼 쉽지 않았다"고 밝혔다.
퀄컴 EDL 모드
퀄컴 긴급 다운로드 모드(Qualcomm Emergency Download mode) 또는 퀄컴 EDL 모드(Qualcomm EDL mode), 공식적으로는 퀄컴 HS-USB QD-로더 9008는 퀄컴의 시스템 온 칩 부트 롬에 구현된 기능으로, 벽돌이 된 스마트폰을 복구하는 데 사용될 수 있다. 구글의 픽셀 3에서는 이 기능이 휴대폰이 벽돌이 된 후 사용자에게 우연히 노출되었다.
퀄컴 EDL 모드 장치 지원
장치가 EDL을 지원하려면 퀄컴 하드웨어를 사용해야 한다. 스냅드래곤 제품군은 매우 널리 사용된다.
퀄컴 EDL 모드 접근
안드로이드 디버그 브리지는 adb reboot edl 명령어를 사용하여 EDL 모드에 접근할 수 있다.
퀄컴 제품 지원 도구(QPST)는 일반적으로 서비스 센터 직원들이 하드-브릭된 안드로이드 장치를 되살리거나 영구적인 소프트웨어 문제를 해결하기 위해 저수준 펌웨어 플래싱에 내부적으로 사용된다. 펌웨어를 플래싱하기 위해 이 도구는 EDL을 통해 지원되는 장치와 통신한다. QPST는 퀄컴에서 공식적으로 출시되지 않았다.
퀄컴 다운로드(QDL)는 퀄컴 시스템 온 칩 부트롬과 통신하여 코드를 설치하거나 실행하는 도구이다. 소스 코드는 안데르손으로도 알려진 비외른 안데르손이 관리한다.
퀄컴이 구현한 마더보드에는 항상 테스트 포인트가 포함되어 있다. 이는 휴대폰 모델마다 다를 수 있다. 일반적으로 테스트 포인트는 한 쌍의 접점이며, 서로 떨어져 있을 수 있다. EDL은 휴대폰 뒷면을 열고, 모델에 따라 달라지는 테스트 포인트의 위치를 찾아, 금속 핀셋으로 커넥터를 단락시킨 후 휴대폰을 EDL로 부팅하여 접근할 수 있다. EDL 모드에서 작업을 수행하려면 추가 소프트웨어 도구가 필요하다.
퀄컴 EDL 모드 접근
퀄컴은 EDL이 있는 마더보드에 EDL 딥 플래시 케이블을 통해 EDL로 부팅할 수 있는 기능을 구현했다. 이 특정 케이블에는 D+와 GND USB 라인을 단락시켜 누르면 휴대폰을 EDL 모드로 부팅할 수 있는 버튼이 있다. 이 케이블을 사용하면 대부분의 장치 및 경우에서 테스트 포인트를 사용할 필요가 없다. 이 케이블은 하드-브릭된 장치도 EDL 모드로 부팅하는 데 작동하며, 이 방법은 SBL1/XBL(보조 부트로더 1/확장 부트로더)이 손상되지 않은 경우에만 작동한다.
WIN.INI
WIN.INI는 Windows 3.11까지의 마이크로소프트 윈도우 운영 환경 버전에서 부팅 시 기본 설정을 저장하는 데 사용되었던 기본 INI 파일이다. 기본적으로 모든 글꼴, 통신 드라이버, 바탕 화면, 화면 보호기 및 언어 설정은 Windows 3.x에서 WIN.INI에 저장되었다. 이 설정 중 상당수는 윈도우 레지스트리를 선호하여 파일이 점차 사라지기 시작했음에도 불구하고 Windows 9x에서 계속 사용되었다. Windows XP는 이전 16비트 응용 프로그램과의 하위 호환성을 제공하기 위해 WIN.INI 파일의 일부 항목을 여전히 인식했다. 그러나 XP를 새로 설치하면 생성되는 WIN.INI 파일은 처음에는 비어 있으며, Windows Vista 및 윈도우 7에서는 WIN.INI 파일이 완전히 제거되었다.
WIN.INI
윈도우 3.0 이전에는 응용 프로그램이 WIN.INI 내부에 구성 설정을 저장하는 것이 흔했다(GetProfileString을 통해). 1990년 윈도우 3.0 출시와 함께 마이크로소프트는 "개인" INI 파일(GetPrivateProfileString 등)의 개념과 일부 새로운 응용 프로그래밍 인터페이스 호출을 도입하여 응용 프로그램이 자체 파일에 설정을 저장할 수 있도록 했다.
1992년에 Windows 3.1은 설정을 저장하기 위한 윈도우 레지스트리를 도입했다.
WIN.INI 편집
마이크로소프트는 운영 체제에 핵심 구성 파일(WIN.INI, SYSTEM.INI, CONFIG.SYS, AUTOEXEC.BAT 등)을 위한 두 가지 특수 편집기를 포함하고 있다. Sysedit는 Windows 3.x부터 윈도우 7까지 모든 버전의 윈도우에서 사용할 수 있는 MDI 문서 편집기로, 이 모든 파일을 동시에 연다. MSConfig는 Windows 98 이상(Windows 2000 제외)에 포함된 더 간단한 응용 프로그램으로, 사용자가 위에서 언급한 파일과 Run, RunEx, RunOnce 레지스트리 키에 의해 시작 시 로드되는 드라이버 및 응용 프로그램을 활성화 및 비활성화할 수 있도록 한다.
WIN.INI와 SYSTEM.INI는 16비트 응용 프로그램 지원을 위해 최신 버전의 윈도우에 포함되어 있다. 16비트 응용 프로그램은 이 두 파일이 C:\Windows에 없으면 오류를 표시할 수 있다.
SYSTEM.INI
SYSTEM.INI는 초기 마이크로소프트 윈도우 버전(1.01부터 Me까지)에서 장치 드라이버 및 기본 윈도우 셸(프로그램 관리자 또는 윈도우 탐색기)과 같은 시스템 설정을 로드하는 데 사용되는 초기화 파일(INI 파일)이다. 이 설정 중 상당수는 윈도우 9x(95, 98, Me)에서도 유지되었지만, INI 파일은 윈도우 레지스트리를 선호하여 점차 폐지되기 시작했다. NT 4.0, 2000, XP, 서버 2003도 이전 16비트 애플리케이션과의 하위 호환성을 제공하기 위해 일부 SYSTEM.INI 항목을 여전히 인식한다. 비스타 이후 버전에도 SYSTEM.INI가 있다. 그러나 XP/서버 2003을 새로 설치하면 생성되는 SYSTEM.INI 파일에는 기본적으로 다음 줄만 포함되어 있다.
SYSTEM.INI 편집
마이크로소프트는 운영 체제와 함께 핵심 구성 파일(예: PROTOCOL.INI, WIN.INI, SYSTEM.INI, CONFIG.SYS, AUTOEXEC.BAT)을 위한 두 가지 특수 문서 편집기를 제공한다. Sysedit은 윈도우 3.0부터 Me 및 윈도우 7 이후를 제외한 모든 윈도우 버전에서 사용할 수 있는 MDI 문서 편집기로, 이 모든 파일을 동시에 연다. MSConfig는 사용자가 드라이버, 윈도우 셸 및 애플리케이션을 위의 파일과 Run, RunEx 및 RunOnce 윈도우 레지스트리 키에서 시작 시 로드되지 않도록 활성화 및 비활성화할 수 있는 프런트 엔드 인터페이스 애플리케이션이다.
INF 파일
INF 파일(설정 정보 파일, Setup Information file)은 마이크로소프트 윈도우 기반 운영 체제에서 소프트웨어 및 장치 드라이버 설치에 사용되는 INI 평문 파일이다. INF 파일은 일반적으로 하드웨어 구성 요소의 장치 드라이버를 설치하는 데 사용된다. 윈도우에는 INF 기반 설치를 생성하기 위한 IExpress 도구가 포함되어 있다. INF 파일은 윈도우 Setup API와 그 후속인 윈도우 인스톨러의 일부를 구성한다.
\windows\inf 디렉토리에는 여러 .inf 파일이 포함되어 있다.
미리 컴파일된 설정 정보 파일(*.pnf)은 운영 체제에 의해 컴파일된 INF 파일의 이진 표현이다.
INF 파일 구조
INF 파일의 구조는 INI 파일의 구조와 매우 유사하며, 복사할 파일, 레지스트리 변경 사항 등을 지정하는 다양한 섹션을 포함한다. 모든 INF 파일에는 INF 파일이 대상으로 하는 윈도우 버전을 지정하는 Signature 키-값 쌍을 가진 [Version] 섹션이 포함되어 있다. 서명은 일반적으로 $CHICAGO$ (윈도우 9x용) 또는 $WINDOWS NT$ (윈도우 NT/2K/XP용)이다. 나머지 대부분의 섹션은 사용자 정의되며 설치될 구성 요소에 특정한 정보를 포함한다.
INF 파일의 예시는 다음과 같을 수 있다.
이것은 파일이 포함된 미디어가 (루트 디렉토리에) 컴퓨터에 연결될 때마다 example.exe 파일을 자동으로 열게 된다. 미디어를 삽입하기 전에 그러한 파일이 존재하는지 알 수 있는 방법이 없으므로 이것은 위험할 수 있다. 그러나 윈도우 XP부터 이 기능은 사용자에게 어떤 작업을 수행할지 선택하도록 강제하는 메뉴로 대체되었다.
INF 파일 구조
INF 파일은 윈도우 2000에서 때때로 위험할 수 있는데, 이는 컴퓨터 바이러스가 프롬프트 없이 자동으로 실행되도록 허용할 수 있기 때문이다.
이들은 윈도우 7에서 차단되지만, 해결할 수 있다.
icon=*.ico 명령은 이전 또는 기본 드라이브 아이콘을 지정된 아이콘으로 대체한다.
[autorun]은 [AutoRun] 또는 [Autorun]으로 대체될 수 있다.
INF 파일은 윈도우 레지스트리 항목의 값을 지정할 수 있다. 드라이버 공급업체와 사용자는 예를 들어 이 기능을 사용하여 ROM 메모리가 손상된 디스플레이의 디스플레이 확장된 디스플레이 식별 데이터(EDID) 메타데이터를 재정의할 수 있다.
Resolv.conf
resolv.conf는 다양한 운영체제에서 시스템의 도메인 네임 시스템(DNS) 리졸버를 구성하는 데 사용되는 컴퓨터 파일이다. 이 파일은 일반적으로 네트워크 관리자나 시스템의 구성 작업을 관리하는 애플리케이션에 의해 생성되는 플레인 텍스트 파일이다. resolvconf 프로그램은 FreeBSD 또는 기타 유닉스 시스템에서 resolv.conf 파일을 관리하는 프로그램 중 하나이다.
Resolv.conf 목적
대부분의 유닉스 계열 운영체제와 BIND 도메인 네임 시스템(DNS) 리졸버 라이브러리를 구현하는 기타 운영체제에서 resolv.conf 구성 파일은 DNS 리졸버의 작동 매개변수를 결정하는 정보를 포함한다. DNS 리졸버는 운영체제에서 실행되는 애플리케이션이 사람이 알아보기 쉬운 도메인 네임을 근거리 통신망 또는 인터넷의 리소스에 액세스하는 데 필요한 숫자 IP 주소로 변환할 수 있도록 한다. 도메인 네임에서 IP 주소를 결정하는 과정을 주소 확인이라고 한다.
Resolv.conf 내용 및 위치
resolv.conf 파일에는 일반적으로 도메인 접미사가 제공되지 않을 때 지정된 쿼리 이름을 전체 주소 도메인 네임으로 완성하는 데 사용되는 기본 검색 도메인을 지정하는 검색 지시어가 포함된다. 예를 들어, search example.com local.test는 리졸버가 추가적으로 somehost.example.com 및 somehost.local.test를 시도하도록 구성한다.
또한 확인을 위한 네임서버의 IP 주소 목록도 포함되어 있다. 예를 들어, nameserver 1.1.1.1은 리졸버가 IP 1.1.1.1을 가진 네임서버를 쿼리하도록 구성한다. 첫 번째 네임서버 지시어 이후의 추가 네임서버 지시어는 첫 번째 또는 마지막으로 사용된 서버를 사용할 수 없을 때만 사용된다. 예제 파일은 다음과 같다.
Resolv.conf 내용 및 위치
resolv.conf는 일반적으로 파일 시스템의 /etc 디렉터리에 위치한다. 이 파일은 수동으로 유지 관리되거나, DHCP가 사용될 때 일반적으로 유틸리티 resolvconf로 업데이트된다.
Systemd 기반 리눅스 배포판에서 systemd-resolved.service를 사용하는 경우, /etc/resolv.conf는 /run/systemd/resolve/stub-resolv.conf에 대한 심볼릭 링크이다.
Sqlnet.ora
데이터베이스 컴퓨팅에서 sqlnet.ora는 오라클 서버와 오라클 클라이언트 모두 네트워크 데이터베이스 액세스를 위해 오라클 넷(이전 Net8 또는 SQL*Net) 기능을 어떻게 사용해야 하는지에 대한 정보(추적 옵션, 암호화, 연결 경로, 외부 명명 매개변수 등)를 포함하는 일반 텍스트 구성 파일이다.
Sqlnet.ora 위치
sqlnet.ora 파일은 일반적으로 유닉스 플랫폼의 $ORACLE_HOME/network/admin 및 윈도우 운영 체제의 %ORACLE_HOME%\NETWORK\ADMIN에 위치한다.
Sqlnet.ora 프로필 매개변수
이 섹션은 몇 가지 sqlnet.ora 파일 매개변수를 나열하고 설명한다.
Fstab
fstab(파일 시스템 테이블의 약자)은 유닉스 및 유닉스 계열 컴퓨터 시스템의 /etc 디렉터리에서 일반적으로 발견되는 시스템 파일이다. /etc/fstab 파일은 util-linux 패키지의 유틸리티(예: mount 및 findmnt)에서 사용되지만, 이에 국한되지 않고 systemd에서 systemd-fstab-generator를 통해 부팅 시 자동 마운트를 위해 처리되기도 한다. fstab 파일은 일반적으로 사용 가능한 모든 디스크 파티션과 기타 디스크 기반이 아닐 수도 있는 파일 시스템 및 데이터 소스 유형을 나열하고, 이들이 어떻게 초기화되거나 더 큰 파일 시스템 구조에 통합될지를 나타낸다.
Fstab
fstab 파일은 mount 명령에 의해 읽히는데, 이 명령은 부팅 시 자동으로 실행되어 전체 파일 시스템 구조를 결정하고, 이후 사용자가 mount 명령을 실행하여 해당 구조를 수정할 때 다시 읽힌다. fstab 파일을 적절하게 생성하고 유지하는 것은 시스템 관리자의 의무이다.
fstab은 기본적인 시스템 구성에 사용되지만, 다른 용도로는 자동 마운트 메커니즘으로 대체되었다.
이 파일은 일부 유닉스 버전에서 다른 이름을 갖는다. 예를 들어, 솔라리스 시스템에서는 /etc/vfstab에 있다.
Fstab 현대적 사용
fstab 파일은 디스크 파티션 및 기타 파일 시스템과 작동하는 프로그램에 의해 읽히며 자동으로 유지 관리되지 않는다. 대신 시스템 관리자 또는 때로는 운영 체제 설치 프로그램에 의해 작성된다. 그러나 일부 관리 도구는 fstab을 자동으로 구축하고 편집하거나, 그래픽 편집기 역할을 할 수 있다.
현대 리눅스 시스템은 fstab에 의존하는 대신 udev를 자동 마운터로 사용하여 장치(핫 스와핑과 같은 MP3 플레이어나 디지털 카메라)의 핫 스와핑을 처리한다. pmount와 같은 프로그램은 일반 사용자가 해당 fstab 항목 없이 파일 시스템을 마운트 및 언마운트할 수 있도록 허용한다. 전통적인 유닉스는 항상 특권 사용자(루트 사용자 및 wheel 그룹의 사용자)가 해당 fstab 항목 없이 장치를 마운트하거나 언마운트할 수 있도록 허용했다.
Fstab 예시
다음은 일반적인 리눅스 시스템의 fstab 파일 예시이다.
fstab에 있는 레코드의 순서는 fsck(8), mount(8), umount(8)가 fstab을 순차적으로 반복하고 정의된 순서로 마운트하기 때문에 중요하다.
빈 줄과 "#"으로 시작하는 주석 줄은 무시된다.
각 행 내의 공백 또는 탭으로 구분된 필드는 특정 순서로 나타나야 한다:
0 - 확인 안 함1 - 부팅 중 즉시 확인2 - 부팅 후 확인
마지막 두 필드에 값이 없으면 0으로 해석된다. 필요한 경우 첫 번째, 두 번째 및 네 번째 필드의 공백 문자는 40으로 표시된다.
Fstab 모든 파일 시스템에 공통적인 옵션
auto / noauto
auto 옵션을 사용하면 장치는 부팅 시 또는 mount -a 명령이 실행될 때 자동으로 마운트된다. auto는 기본 옵션이다. 장치가 자동으로 마운트되지 않으려면 /etc/fstab에서 noauto 옵션을 사용한다. noauto를 사용하면 장치는 명시적으로만 마운트할 수 있다.
dev / nodev
파일 시스템에서 블록 특수 장치의 해석 동작을 제어한다.
exec / noexec
exec는 파티션에 있는 바이너리가 실행되도록 허용하고, noexec는 그 반대이다. noexec는 /var처럼 바이너리가 없는 파티션에 유용하거나, 사용자가 시스템에서 실행하고 싶지 않은 바이너리가 포함된 파티션, 또는 윈도우 파티션의 경우처럼 시스템에서 실행될 수 없는 바이너리가 포함된 파티션에 유용할 수 있다.
rw / ro
파일 시스템을 읽기/쓰기 또는 읽기 전용 모드로 마운트한다. 파일 시스템을 명시적으로 rw로 정의하면 플로피 디스크나 NTFS 파티션과 같이 기본적으로 읽기 전용으로 설정되는 파일 시스템의 일부 문제를 완화할 수 있다.
sync / async
Fstab 모든 파일 시스템에 공통적인 옵션
파일 시스템에 대한 입력 및 출력이 수행되는 방식. sync는 동기적으로 수행됨을 의미한다. fstab 예시를 보면 플로피 디스크에 사용된 옵션이다. 이는 예를 들어 파일이 플로피 디스크에 복사될 때, 복사 명령이 실행되는 동시에 변경 사항이 물리적으로 플로피 디스크에 기록됨을 의미한다.
suid / nosuid
suid 및 sgid 비트의 작동 동작을 제어한다.
user / users / nouser
user는 모든 사용자가 파일 시스템을 마운트할 수 있도록 허용한다. 이는 명시적으로 재정의되지 않는 한 noexec, nosuid, nodev를 자동으로 의미한다. nouser가 지정되면 루트만 파일 시스템을 마운트할 수 있다. users가 지정되면 users 그룹의 모든 사용자가 볼륨을 언마운트할 수 있다.
defaults
Fstab 모든 파일 시스템에 공통적인 옵션
기본 설정을 사용한다. 기본 설정은 파일 시스템 수준에서 파일 시스템별로 정의된다. ext3 파일 시스템의 경우 tune2fs 명령으로 설정할 수 있다. ext3 파일 시스템의 일반적인 기본값은 rw,suid,dev,exec,auto,nouser,async와 동일하다. 최신 Red Hat 기반 시스템은 루트 파일 시스템에서 ACL 지원을 기본으로 설정하지만, 사용자가 생성한 ext3 파일 시스템에서는 설정하지 않는다. XFS와 같은 일부 파일 시스템은 기본적으로 ACL을 활성화한다. 기본 파일 시스템 마운트 속성은 /etc/fstab에서 재정의할 수 있다.
owner (리눅스 전용)
장치 소유자가 마운트할 수 있도록 허용한다.
nofail
디스크 마운트에 실패해도 시스템 부팅을 중지하지 않는다.
atime / noatime / relatime / strictatime (리눅스 전용)
유닉스 stat 구조는 파일이 마지막으로 접근된 시간(atime), 수정된 시간(mtime), 변경된 시간(ctime)을 기록한다. 한 가지 결과는 파일이 읽힐 때마다 atime이 기록되어 성능 저하와 마모 증가를 야기한다는 비판을 많이 받았다. 그러나 atime은 일부 응용 프로그램에서 사용되고 일부 사용자가 원하므로 atime(접근 시 업데이트), noatime(업데이트 안 함) 또는 (리눅스에서) relatime(mtime보다 오래된 경우 atime 업데이트)으로 구성할 수 있다. 리눅스 2.6.29까지는 atime이 기본이었고, 2.6.30부터는 relatime이 기본이다.
Fstab 파일 시스템별 옵션
mount가 지원하는 특정 파일 시스템에 대한 많은 옵션이 있다. 아래에는 일반적으로 사용되는 일부가 나열되어 있다. 전체 목록은 mount 설명서에서 찾을 수 있다. 이들은 리눅스용이며, 전통적인 유닉스 계열 시스템은 일반적으로 유사한 기능을 제공했지만 약간 다른 구문이나 형식을 가졌다.
check=[none, normal, strict]
fsck 검사 수준을 설정한다.
debug
재마운트 시마다 디버깅 정보를 출력한다.
sb=n
n은 파일 시스템의 슈퍼블록으로 사용되어야 하는 블록이다.
check=[r(elaxed), n(ormal), s(trict)]
허용되는 파일명에 대한 정책. mount(8)을 참조하라.
conv=[b(inary), t(ext), a(uto)]
DOS <=> UNIX 텍스트 파일 변환을 자동으로 수행한다. mount(8)을 참조하라.
windows_names
Fstab 파일 시스템별 옵션
리눅스 파일 시스템은 파일명에 허용되는 문자의 집합이 더 크다. windows_names는 볼륨에 허용되는 문자 집합을 Windows에서 허용하는 문자만으로 제한한다. FAT/NTFS가 가장 일반적인 사용 사례이지만, 이 기능은 특정 파일 시스템 유형에만 국한되지 않는다.
uid=n, gid=n
파일 시스템의 모든 파일에 대한 사용자 식별자(uid) 및 그룹 식별자(gid)를 설정한다.
umask=nnn, dmask=nnn, fmask=nnn
파일 시스템 노드의 마스킹을 제어한다.
umask - 사용자 파일 생성dmask - 디렉터리 생성fmask - 파일에만 해당
fstab 파일에 대한 더 자세한 정보는 리눅스 fstab의 맨 페이지에서 찾을 수 있으며, 다른 시스템의 경우 아래를 참조하라.
addr=ip
ip는 유효한 IP 주소이다.
.htpasswd
.htpasswd는 아파치 HTTP 서버의 기본 인증을 위한 사용자 이름과 암호를 저장하는 데 사용되는 플랫 파일 데이터베이스이다. 파일 이름은 .htaccess 구성에 지정되며, ".htpasswd"가 표준 이름이지만 어떤 이름이든 될 수 있다. 대부분의 유닉스 계열 운영 체제가 점으로 시작하는 모든 파일을 숨김 파일로 간주하기 때문에 파일 이름은 점으로 시작한다. htpasswd 명령어는 .htpasswd 파일 항목을 관리하는 데 사용된다.
.htpasswd 역사
htpasswd는 아파치의 전신인 NCSA HTTPd 서버에 처음 추가되었다. 역사적으로 사용된 해시는 MD5 또는 SHA1이 일반적인 대안인 "UNIX crypt" 스타일이었다. 아파치 2.4에서는 bcrypt 알고리즘이 추가되었다.
.htpasswd 사용법
이 파일은 각 줄에 사용자 이름과 콜론, 그리고 선택적으로 알고리즘 지정자("$2y$", "$apr1$" 또는 "{SHA}") 및 솔트가 선행되는 해시된 암호 문자열이 포함된 줄로 구성된다.
아파치 HTTP 서버에서 사용 가능한 리소스는 htpasswd로 생성된 파일에 나열된 사용자로만 제한될 수 있다. .htpasswd 파일은 파일이 위치한 전체 디렉터리뿐만 아니라 특정 파일도 보호하는 데 사용할 수 있다.
.htpasswd 보안 문제
htpasswd가 받아들이는 알고리즘 중 오늘날의 기준으로 여전히 안전하다고 간주되는 유일한 알고리즘은 bcrypt이며, 많은 형식은 솔팅을 사용하지 않아 사전 공격에 취약하다. crypt() 알고리즘은 주어진 암호의 처음 8자만 사용하고 그 이후는 버린다.
ABU 로보콘
ABU 아시아-태평양 로봇 경진대회(ABU Asia-Pacific Robot Contest) 또는 ABU 로보콘(ABU Robocon)은 아시아-태평양 방송 연합이 2002년에 창설한 아시아-오세아니아 대학 로봇 경진대회이다. 이 대회에서 로봇들은 정해진 시간 내에 과제를 완수하기 위해 경쟁한다. 이 대회의 목표는 21세기에 각국을 이끌어갈 비슷한 관심사를 가진 젊은이들 사이의 우정을 쌓고, 이 지역의 공학 및 방송 기술 발전에 기여하는 것이다. 이 행사는 ABU 회원 방송사들을 통해 여러 나라에 방송된다.
ABU 로보콘 역사 및 형식
ABU 로보콘은 1991년에 시작되어 일본 팀만 참가할 수 있었던 NHK 로보콘의 개념을 확장했다.
매년 대회는 다른 주제를 가지지만, 일반적으로 두 개 이상의 로봇을 사용하여 과제를 완수해야 한다. 로봇 중 하나는 수동으로 제어되며, 다른 로봇은 자동으로 작동한다. 최고의 로봇은 대개 10 kg 이상이며 1제곱미터의 면적을 차지한다. 로봇을 제작하기 위해 학부생으로 제한된 참가자들은 컴퓨터 프로그래밍, 기계 설계 및 전자 회로 설계에 대한 풍부한 지식을 갖춰야 한다.
매년의 주제와 규칙은 개최국이 정한다. 각국은 개최국에서 열리는 최종 대회에 참가할 대표팀을 결정하기 위해 자체 예선전을 치른다. 개최국에는 최종 대회에 두 팀이 참가할 수 있는 특별한 권한이 주어진다.
각 경기는 종종 빨강과 파랑으로 명명된 두 팀 사이에 진행된다. 경기장은 대칭이며 양 팀의 로봇은 동일한 조건에서 시작한다 (배드민턴 기반의 턴제 게임을 채택한 로보콘 2015와 농구를 기반으로 한 로보콘 2025 제외).
ABU 로보콘 역사 및 형식
일반적인 게임(로보콘 2015 및 로보콘 2025 제외)은 3분 동안 진행되지만, 한 팀이 경기를 즉시 종료시키는 K.O. 승리를 달성하면 더 일찍 끝날 수 있다. 어떤 팀도 K.O. 조건을 달성하지 못하는 경우, 3분 후 더 높은 점수를 얻은 팀이 승자로 선언된다.
초기 로보콘 대회는 게임의 경쟁적인 측면을 강조하는 경향이 있었는데, 승자들은 로봇을 배치하는 전략적인 접근 방식을 사용하고 상대방이 목표에 도달하는 것을 방지함으로써 승리했다. ABU 로보콘 2004와 2006에서 베트남의 승리 그리고 ABU 로보콘 2008에서 중화인민공화국의 승리가 이러한 전략을 보여주었다. 이러한 문제를 완화하기 위해 후기 대회에서는 전투적인 성격을 줄이고 기술, 로봇 설계 및 복잡한 maneuvers 수행에 더 중점을 두어, 팀들이 로봇 설계에 더욱 창의적이어야 했다.