# Asahi Linux 7.1 진행 보고서 > Clean Markdown view of GeekNews topic #31032. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=31032](https://news.hada.io/topic?id=31032) - GeekNews Markdown: [https://news.hada.io/topic/31032.md](https://news.hada.io/topic/31032.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-07-02T10:16:42+09:00 - Updated: 2026-07-02T10:16:42+09:00 - Original source: [asahilinux.org](https://asahilinux.org/2026/06/progress-report-7-1/) - Points: 1 - Comments: 1 ## Topic Body - Linux 7.1 기준 Asahi Linux는 **M3 지원 확대**, macOS 27 베타 호환성, AVD 비디오 디코딩, m1n1 1.6.0 변화가 동시에 진행 중임 - macOS 27 Golden Gate 개발자 베타에서는 Asahi 부팅 항목이 Startup Disk와 부트 피커에서 사라졌지만, 파티션과 데이터는 남아 있었고 **APFS 부팅 플래그** 설정으로 복구 가능함 - SMC 펌웨어 변경은 배터리 관리 반환값을 바꿔 특정 조건에서 **긴급 종료**를 유발했으며, downstream 커널 7.0.12부터 두 firmware ABI를 모두 처리함 - M3 계열은 오디오, CPU 주파수 전환, big.LITTLE 스케줄링, SMC 센서, PCIe, WiFi, Bluetooth, NVMe, 키보드, 트랙패드가 Linux에서 동작하지만 아직 **Asahi Installer 지원** 단계는 아님 - AVD는 Apple 펌웨어 대신 자체 펌웨어와 V4L2 드라이버로 AVC 하드웨어 디코딩을 향해 진전됐고, m1n1 1.6.0은 stage 2 빌드에 **Rust**를 요구해 배포판 영향이 큼 --- ### macOS 27에서 사라진 Asahi 부팅 항목 - Mac에서 전원 버튼을 길게 눌러 여는 부트 피커나 Startup Disk 앱에 보이는 Asahi 항목은 실제 운영체제 파티션이 아님 - Apple 부트 도구는 APFS 컨테이너 안의 “유효한 macOS 설치”만 다루기 때문에, Asahi Installer는 **2.5GB APFS 컨테이너**를 만들고 m1n1을 커널처럼 넣은 최소 macOS 구성을 사용함 - 이 방식은 macOS 12부터 macOS 26까지 변경 없이 동작했고, Apple은 실제 XNU 커널이 아닌 raw binary를 부팅할 때만 나타나던 도구 버그도 일부 수정했음 - macOS 27 Golden Gate 개발자 베타 이후 일부 사용자는 Startup Disk와 부트 피커에서 Asahi 항목이 사라지는 문제를 겪음 - `diskutil` 확인 결과 Asahi 관련 파티션은 디스크에 남아 있었고 **데이터 손실은 없었음** - 같은 머신에서 macOS 26의 부트 도구를 사용하면 Asahi는 여전히 부팅 가능했음 - macOS Installer는 재부팅 전에 APFS 메타데이터를 설정하며, 추가 조사 결과 이 값은 볼륨을 부팅 가능으로 표시하는 플래그였음 - macOS 27 이전의 부트 도구는 이 플래그를 무시했음 - Asahi APFS 컨테이너에 플래그를 수동 설정하면 macOS 27 부트 피커에 다시 표시됨 - 새 Asahi 설치에서는 Asahi Installer가 이 플래그를 자동 설정함 - 기존 설치를 고치기 위한 설치 모드도 추가됨 - macOS 27 개발자 베타 설치 후 Asahi에 접근할 수 없으면 installer를 다시 실행하고 “Fix macOS 27 boot picker compatibility” 옵션을 사용해야 함 - Linux에서 문제를 고치는 프로그램도 만들어졌지만, 자동 배포 전 더 많은 테스트 데이터가 필요함 - 테스트하려면 macOS 27로 업그레이드하기 전에 [asahi-fix27](https://github.com/AsahiLinux/asahi-fix27) 저장소를 clone하고 Linux에서 빌드·실행함 - 이후 macOS에서 Asahi 볼륨이 부팅 대상으로 선택 가능하면 동작한 것임 - 결과와 문제는 Asahi [community channels](https://asahilinux.org/community)에서 공유하면 됨 ### SMC 펌웨어 변경과 배터리 드라이버 긴급 종료 - macOS 27은 SMC를 포함해 **global firmware**를 쓰는 모든 주변장치 펌웨어 업데이트를 포함함 - SMC는 배터리 관리를 담당하며, Linux power supply 드라이버는 SMC와 통신해 충전 상태, 전압, 방전까지 남은 시간, 배터리 상태 정보를 얻음 - 같은 드라이버는 배터리 수명 연장을 위해 SMC 펌웨어 인터페이스로 충전 시작·중지 임계값도 설정함 - macOS 27의 SMC 펌웨어는 배터리 관리 인터페이스 하나를 **32비트 정수 반환**에서 **1바이트 반환**으로 변경함 - 이 변경 때문에 Asahi 드라이버가 특정 조건에서 배터리 고장으로 판단하고 시스템 보호를 위해 긴급 종료를 시작함 - downstream 커널에는 이미 패치가 적용됐으며, 7.0.12부터 power supply 드라이버가 두 firmware ABI를 모두 처리함 ### 개발자 베타 설치에 대한 경고 - macOS 27에서 나타난 두 문제는 개발자 베타가 실제로 **개발자 베타**라는 점을 보여줌 - 개발자 베타를 프로덕션 머신에 설치하는 것은 권장되지 않음 - 지금까지 발생한 두 문제는 운 좋게도 작은 문제였지만, 앞으로의 문제가 모두 작을 것이라는 보장은 없음 - global firmware 업데이트는 사실상 영구적이며, 되돌리려면 머신을 **DFU restore**해야 함 - Asahi 쪽은 테스트용 희생 머신을 사용하므로, 사용자가 고가 하드웨어와 중요한 데이터를 위험에 놓을 필요는 없다고 봄 ### M3 계열 지원 진전 - 컴퓨터 플랫폼과 IC 설계·검증은 비용과 시간이 많이 들어, 불필요한 기존 설계 변경은 합리적이지 않음 - Asahi 프로젝트는 Apple이 플랫폼과 IC에서 계속 깨지는 변경을 만들지 않을 것이라는 가정에 기대었고, GPU처럼 세대마다 바뀌기 쉬운 큰 SoC 블록을 제외하면 대체로 맞아떨어졌음 - ## 오디오 출력 - Apple Silicon 노트북의 오디오는 여러 IC와 SoC 블록을 사용함 - 오디오 IC의 사실상 업계 표준은 오디오 데이터에 최적화된 I2C 기반 버스인 **I2S**임 - Apple의 I2S 컨트롤러와 안정적인 클록 소스인 Apple NCO는 M1 이후 바뀌지 않았음 - Apple은 거의 모든 Apple Silicon 머신에서 같은 스피커·헤드셋 증폭기 칩을 사용함 - M3 머신에 스피커와 헤드폰 잭 지원을 추가할 때 필요한 작업은 주로 사소한 Devicetree 추가와 `asahi-audio`, `speakersafetyd` 설정 파일이었음 - M3 머신은 Asahi Linux에서 **고품질 오디오 출력**을 지원함 - ## CPU 주파수와 big.LITTLE 스케줄링 - M3 머신은 CPU 주파수 전환과 적절한 **big.LITTLE 작업 스케줄링**도 지원하게 됨 - Apple은 기본 M2 이후 CPU 주파수 전환 방식을 바꾸지 않았음 - M3, M3 Pro, M3 Max, M3 Ultra SoC는 기존 `cpufreq` 드라이버에 Devicetree 변경만으로 동작함 - 작업은 요구사항에 따라 효율 코어 또는 성능 코어에 더 지능적으로 배치되고, CPU 코어는 부하에 따라 클록을 올리고 내림 - 이 변경은 에너지 절감과 성능 향상을 모두 가져옴 - ## 센서와 핵심 장치 - SMC 펌웨어는 머신 간 차이가 크지 않아, SMC 하드웨어 센서 지원도 몇 가지 Devicetree 변경만 필요했음 - M3 계열 머신에서는 PCIe, WiFi, Bluetooth, NVMe, 키보드, 트랙패드, 기타 핵심 SoC 블록 드라이버도 Linux에서 동작함 - 이 작업의 상당 부분은 M3 계열 머신으로 m1n1과 Linux를 작업해 온 [Yureka](https://fedi.yuka.dev/yuka)가 수행함 - Asahi Installer 지원을 M3 머신에 활성화하려면 아직 더 많은 작업이 필요하지만, 진행 속도는 빠름 ### AVD 비디오 디코딩과 자체 펌웨어 - Apple Silicon 플랫폼의 복잡한 하드웨어 대부분은 복잡한 펌웨어 blob을 사용함 - 많은 펌웨어는 Apple이 커널과 여러 하드웨어 블록 사이에 대체로 표준화된 인터페이스를 제공하기 위해 사용하는 RTOS 유사 프레임워크인 **RTKit** 기반임 - DCP와 AOP 같은 일부 블록은 RTKit을 기반으로 하면서 EPIC이라는 추가 추상화를 올림 - Broadcom WiFi/Bluetooth 칩셋처럼 Apple이 직접 제어하지 않는 서드파티 펌웨어를 쓰는 경우도 있음 - Apple Video Decoder, 즉 **AVD**는 RTKit도 EPIC도 아닌 별도 구조의 펌웨어를 사용함 - ## AVD 구조와 기존 방식의 문제 - AVD 하드웨어는 AVC(H.264), HEVC(H.265), VP9, 최신 SoC의 AV1 비디오 프레임을 디코딩하는 고정 기능 하드웨어 유닛들을 제어하는 ARM Cortex-M3에 가까움 - Cortex-M3는 XNU가 비디오 데이터를 가리키도록 하는 인터페이스를 제공하고, 실제 디코더 하드웨어를 설정하는 펌웨어 blob을 실행함 - Apple은 AVD 펌웨어와 설정 데이터를 **AVD kext 내부**에 함께 넣음 - 각 SoC는 조금씩 다른 AVD 변형을 사용하므로, Asahi Installer가 kext 안의 펌웨어 데이터 오프셋 변경을 계속 추적하고 업데이트해야 하는 물류 문제가 생김 - ## 자체 펌웨어 접근 - XNU가 로드하는 AVD 펌웨어는 Cortex-M3에서 검증되지 않음 - 신호를 받으면 reset vector부터 실행하기 때문에, 실제로 들어 있는 코드가 무엇이든 실행됨 - 펌웨어의 역할은 기본적으로 비디오 디코더 하드웨어를 추상화하는 것이므로, 각 하드웨어 블록의 인터럽트 핸들러만 설치하면 Linux 드라이버에서 직접 프로그래밍할 수 있음 - 표준 Cortex-M3 코드이기 때문에 AVD 펌웨어는 에뮬레이터에서 실행 가능함 - QEMU는 단일 단계 실행과 버스·레지스터 작업 검사를 지원함 - Jamie, R, Eileen은 과거 공동 작업으로 AVC와 VP9 디코더에 필요한 명령과 데이터 형식을 리버스 엔지니어링했음 - XNU kext는 AVD revision마다 고유한 tunable도 적용함 - 이 값들이 정확히 무엇을 하는지는 완전히 확실하지 않음 - 적용은 XNU의 MMIO write 재생에 가까움 - 각 AVD revision, tunable 집합, 적용 대상 revision을 추적해야 함 - upstream Linux 커널 드라이버에서 만족스럽게 유지하기 어려워, 이 부분도 펌웨어에 두는 편이 적절함 - ## V4L2 AVC 드라이버 - 새 기여자 [sofus](https://github.com/sofus13)는 인터럽트 핸들러를 설치하고 각 변형의 tunable을 적용하는 기본 **custom AVD firmware**를 만들었음 - 이를 바탕으로 AVC 하드웨어용으로 동작하는 **V4L2 드라이버**를 작성함 - 하드웨어는 10-bit AVC 인코딩 비디오를 최대 4K까지 디코딩할 수 있음 - V4L2 Request API를 구현한 소프트웨어와 잘 동작함 - 펌웨어를 단순하고 상태 없는 형태로 유지하고, userspace와 커널이 비디오 데이터 파싱과 디코더 프로그래밍을 맡게 하면 향후 VA-API나 Vulkan Video 같은 다른 비디오 가속 API 지원도 더 쉬워짐 - 사용자에게 AVD 지원을 제공하려면 아직 작업이 남아 있음 - AVD는 VP9, HEVC, 일부 SoC의 AV1도 지원하지만 아직 구현되지 않았음 - 일부 장치의 quirks도 테스트하고 드라이버에 반영해야 함 - 배포 가능한 형태는 그리 멀지 않은 시점을 목표로 함 ### m1n1 1.6.0 릴리스 - m1n1 1.6.0이 태그됐으며, 배포판 입장에서는 영향이 큰 릴리스임 - 이번 버전은 stage 2 빌드에 처음으로 **Rust**를 요구함 - 이전에는 chainloading 지원을 넣어 빌드할 때만 Rust를 사용했음 - stage 1 m1n1은 Apple 부트 도구에서 XNU 커널을 대체하며, EFI System Partition을 마운트하고 거기서 stage 2 m1n1을 chainload하는 데만 사용됨 - GPU 초기화를 m1n1로 옮기기로 하면서, 커널 드라이버가 Apple 하드웨어 초기화 데이터에 있는 부동소수점 값을 다룰 필요가 없어졌고 Devicetree binding도 크게 단순화됨 - 향후 Linux Kernel Mailing List에 제출될 GPU 드라이버 버전은 m1n1이 이 초기화를 수행한다는 전제에 의존함 - Apple Device Tree 파싱 코드도 Rust로 포팅됐으며, m1n1의 거의 모든 다른 부분에서 사용됨 - ## 빌드와 대상 - m1n1은 사실상 펌웨어이므로 `no_std` Rust를 사용하고 `aarch64-none-softfloat`을 대상으로 함 - 불필요한 의존성을 끌어오지 않으려면 `make`에 `BUILDSTD=1`을 전달해 전체 `softfloat` toolchain 설치 없이 `core`와 `alloc`을 빌드할 수 있음 - ## M3, M4, A18 Pro 준비 - 1.6.0은 M3 계열 지원을 위한 여러 개선도 포함함 - SPMI 컨트롤러 지원 - PCIe 초기화 지원 - [kisd](https://github.com/AsahiLinux/kisd)를 통한 SoC 하드웨어 UART의 DebugUSB 직접 터널링 지원 - DebugUSB UART 터널링은 Central Scrutiniser와 거의 같은 기능을 제공할 수 있음 - 이 작업 상당 부분도 Yureka의 기여임 - M4와 A18 Pro, 즉 MacBook Neo 지원을 위한 기초 작업도 진행 중임 - Apple의 non-macOS boot mode를 더 잘 처리함 - Apple Device Tree에 있는 새 power domain metadata를 지원함 ### 후원과 기여자 - Asahi Linux는 [GitHub Sponsors](https://github.com/sponsors/AsahiLinux)와 [Open Collective](https://opencollective.com/asahilinux) 후원자들에게 감사를 표함 - 후원 덕분에 미완성 M1·M2 기능, M3·M4·A18 Pro 지원, 새 기여자 지원을 계속할 수 있음 ## Comments ### Comment 61023 - Author: neo - Created: 2026-07-02T10:16:43+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48744518) - “오디오 IC의 사실상 업계 표준은 오디오 데이터에 최적화된 I²C 기반 버스인 I²S”라는 표현은 정확하지 않음. **I²S는 I²C와 무관**함 대부분의 I²S 칩에 I²C 인터페이스가 붙어 있긴 한데, I²S는 원시 오디오 데이터만 실어나르고 볼륨 제어나 클록 설정 같은 부가 신호가 없기 때문임 하지만 그건 별도 인터페이스이고 I²C 대신 SPI일 수도 있음. 실제로는 I²C보다 **SPI가 I²S에 더 가까움** - 맞음, I²S는 SPI에 훨씬 가까움 둘 다 비슷한 이름 체계를 따르는 이유는 **Philips Semiconductor**(현재 NXP)가 둘 다 만들었기 때문임 - **I²S**는 놀랄 만큼 단순한 설계임. 프로토콜 핸드셰이크가 없고 그냥 원시 PCM만 흐름 송신자와 수신자가 서로 다른 샘플 비트 깊이를 양방향으로 써도 호환성 문제가 없도록 설계된 점이 마음에 듦 [https://web.archive.org/web/20070102004400/http://www.nxp.co...]() - 동기 부여된 소수의 사람들이 이런 문제들을 풀어낸다는 게 정말 경이로움 - 많은 문제는 전혀 해결되지 않았음. 예를 들어 **Apple Silicon의 PSCI 전원 관리 인터페이스**는 여전히 미스터리임 다른 Linux 디바이스트리에는 PSCI 코드가 있지만, Apple이 이를 어떻게 구현했는지는 아무도 모름. 그래서 Asahi 사용자들은 거의 5년 동안 배터리가 계속 닳지 않게 막는 해킹에 의존해 왔고, 내가 알기로는 아직 유망한 해법도 없음 이게 역공학의 명암임. 이 기기들에 네이티브 Vulkan 1.2 드라이버가 생긴 건 멋지지만, 거기까지 몇 년이 걸렸음. Apple Silicon이 출시된 지 7년이 지난 지금도 미해결 문제가 남아 있고, 최신 하드웨어 대부분은 전반적으로 지원되지 않음. 결국 Linux 사용자들이 늘 말해 온 교훈, **독점 드라이버는 별로**라는 결론으로 돌아감 - XNU가 로드하는 펌웨어를 CM3가 검증하지 않고, 신호가 오면 실제 내용이 무엇이든 리셋 벡터에서 실행을 시작한다는 부분이 특히 걱정됨 독점적이고 계속 변하는 대상을 상대로 **커스텀 펌웨어**를 작성한 성취는 말로 다 못 할 만큼 대단하지만, Apple이 계속 서드파티 운영체제를 일부러 깨지 않기를 바라는 것과 별개로, 펌웨어 블롭이나 런타임에 하드웨어 프로그래밍에 공급하는 데이터에 **하드웨어 서명**을 도입할 가능성은 낮지 않아 보임. Apple 입장에서는 합리적인 보안 우려일 수 있음. 그래도 이 도박이 성공하길 바람 - 이게 영원히 Fedora “remix”로만 남을지 궁금함. 언젠가 **업스트림 지원**이 들어가서 Debian 기반 배포판을 돌릴 수 있게 될까? 마지막으로 RPM 기반 배포판을 쓴 게 거의 20년 전인 것 같음 - 패치를 업스트림에 올리고 있으니, 결국 **업스트림 Linux**에 필요한 드라이버가 들어갈 것임 물론 커널 포크도 오픈소스라서 Debian aarch64 루트를 가져오고 Asahi 커널을 직접 빌드하거나 Fedora 빌드를 가져와서 이 기기에 Debian을 직접 구성하는 것도 막는 건 없음. 다만 손이 좀 감 Ubuntu가 괜찮다면 Ubuntu Asahi도 있음: [https://ubuntuasahi.org/]() 검색해 보니 이 위키 문서도 있음: [https://wiki.debian.org/InstallingDebianOn/Apple/M1]() - 내 취향은 반대라서 이 댓글이 웃겼음. 나는 **RPM 기반 배포판**을 선호하고 거의 모든 곳에서 Fedora를 주로 씀. M1 Ultra Mac Studio에서도 Fedora Asahi Remix를 쓰고, 클라우드 인스턴스 일부에서만 가끔 Ubuntu와 Debian을 씀 그래서 이미 익숙한 특정 배포판을 계속 쓰고 싶은 마음은 이해함. 일이 덜하고, 구조의 미묘한 차이를 덜 기억해도 되니까. 그래도 어쩔 수 없이 새 배포판을 써야 할 때, 예컨대 Asahi가 처음 Arch Linux ARM 전용으로 나왔을 때처럼, 거기서 얻는 작은 학습은 후회한 적이 없음 - Arch도 여전히 쓸 수 있고 **Ubuntu Asahi**도 있음 모든 배포판이 더 쉽게 포팅될 수 있도록 정확히 그런 이유로 업스트림 작업을 열심히 하고 있음 [https://ubuntuasahi.org/]() - Bananas Team이 Apple Silicon에서 표준 Debian을 동작시키려는 작업을 하고 있고, 비공식 저장소를 추가해 지금 설치하는 방법도 있음: [https://wiki.debian.org/InstallingDebianOn/Apple/M1#The_Bana...]() 아직 직접 설치해 보지는 않았음 - **linux-asahi**는 Void Linux에서도 사용 가능함 [https://voidlinux.org/download/#arm%20platforms]() 배포판 안의 일반 Linux 패키지임: [https://github.com/void-linux/void-packages/tree/master/srcp...]() - **M3 지원**이 잘 진척되는 걸 보니 좋음 M3 지원 추가 작업을 시작한다고 처음 언급한 건 2월이었음 “꽤 오랫동안 m1n1에는 M3 시리즈 기기에 대한 기본 지원이 있었다. 빠져 있던 것은 각 기기별 디바이스트리와, M2와 달라진 M3 특유의 하드웨어 특성과 변경점을 지원하기 위한 Linux 커널 드라이버 패치였다. 기존 패치셋이 더 관리 가능해지면 이 작업을 구체화하려는 의도는 항상 있었다” [https://asahilinux.org/2026/02/progress-report-6-19/]() - **AVD 드라이버**를 작업하고 있다니 기대됨 - M1 이상 Mac에서 ffmpeg나 VLC를 쓰면 **AVD**를 사용하나? - Asahi는 실행 가능한 대안이 될 수 있지만, 이 정도 자금과 작은 인력 규모로는 개발 속도가 너무 느릴 수밖에 없어 보임 글에서 말한 것처럼 이미 깔린 기반 작업이 있고 그 성과도 있지만, 결국 매년 새 칩과 수많은 마이크로컨트롤러, GPU 변경을 담은 새 Mac이 나오니 따라잡기 불가능함. 그래서 Asahi 팀도 M1과 M2 모델에 더 집중하는 것임 그런데도 지금까지 둘 다 유휴 전력 관리와 Alt-DP 구현 문제가 남아 있어 많은 사람이 전환하지 못함. 이 문제가 다듬어질 때쯤이면 기기 가치도 크게 떨어져 있을 것임 소수 인원이 이만큼 해낸 건 기적이지만, 광범위한 미디어 보도에도 결국 팀의 열정과 의욕은 줄어든 듯하고 **M1 Air조차 완성되지 못할** 것처럼 보임 - “개발 속도가 너무 느릴 수밖에 없다”기보다는, 새 리더십 팀이 들어왔을 때 최신 하드웨어 지원 추가보다 **기존 작업 업스트림**을 우선하겠다고 발표했음 변경 사항을 커널에 업스트림하는 데 시간이 걸렸음 이제 2월에 M3 작업을 시작했다고 발표했고, 진척도 좋아 보임 “위 내용에 더해, M3 시리즈 기기에서 PCIe, WiFi, Bluetooth, NVMe, 키보드, 트랙패드 및 기타 핵심 SoC 블록 드라이버도 Linux에서 동작한다. 이 작업 대부분은 Yureka가 맡았고, 그녀는 한동안 M3 시리즈 기기로 m1n1과 Linux 양쪽을 매우 활발히 해킹해 왔다. Asahi Installer에서 이 기기들을 지원하기 시작하려면 아직 갈 길이 남았지만, 진전은 빠르니 지켜봐 달라!” 이건 파멸보다는 재능 있는 사람들이 **꼼꼼한 작업**을 해내는 모습에 더 가까움 - 몇 년마다 한 기종만 목표로 삼아 제대로 동작하게 만들 수 있다면, 대안이 전혀 없는 것보다 훨씬 나음 **M1 지원**은 요즘 꽤 쓸 만하고, 작업의 적어도 일부는 미래 기기에도 이어질 것 같음. 장밋빛만 있는 건 아니지만 실패가 예정된 프로젝트도 아님 - Apple이 작은 팀에 자금을 대서 문서와 드라이버 일부를 오픈소스로 공개하고 Asahi를 도와주면 정말 좋겠음 물론 그러지 않을 건 알지만, 꿈은 꿀 수 있음. Apple에게는 푼돈일 텐데, 그렇게 하면 자사 하드웨어가 Silicon Valley 엔지니어들의 사실상 표준으로 더 굳어질 것임 - Apple 자체 **Hypervisor framework**가 그 말에 꽤 가까워서, 나는 UTM 앱으로 Fedora와 Arch Linux 빌드를 돌림. 에뮬레이션이 아니라 Apple Silicon 가상화를 쓰도록 설정하고, UTM은 그 프레임워크를 감싸는 래퍼임 아주 훌륭해서 몇 년 전에 Asahi를 지우고 다시 포맷하게 만들었음 [https://developer.apple.com/documentation/hypervisor]() [https://docs.getutm.app/installation/macos/]() - 최근 Asahi에 **대규모 언어 모델**을 얼마나 활용했는지 궁금함. 역공학에는 정말 강력한 도구인데, 관련해서 글을 쓴 적이 있나? - 사용을 금지하고 있음 [https://asahilinux.org/docs/project/policies/slop/]() - 이 프로젝트의 개발/CI 과정이 어떻게 생겼는지 궁금함 결국 매번 특정 하드웨어에 빌드를 수동으로 로드하는 식일까, 아니면 어느 정도 **자동화**가 가능한 단계가 있을까? - **m1n1**이 여기서 꽤 재미있는 일을 많이 함: [https://asahilinux.org/docs/sw/tethered-boot/]() 실제 하드웨어와 커널 사이에 아주 얇은 계층을 두되 하드웨어 입출력 동작에는 영향을 주지 않으면서, 커널 로딩과 디버깅을 원격 제어하고 자동화할 수 있게 해줌