CS42L84가 macOS에서는 48/96 kHz만 쓰도록 설정돼 있었는데, CS42L42 데이터시트의 다른 샘플레이트 값을 가져와 드라이버에 넣어보니 그대로 동작했다고 함
44.1/88.2/176.4/192 kHz를 헤드폰 잭 입출력에서 지원하는 패치가 upstream에 들어갔고, 7.1에 병합됐으며 Asahi kernel 6.19.9에도 백포트돼 바로 쓸 수 있게 됨
칩 추적과 리버스 엔지니어링이 정말 인상적임
제일 놀라운 대목은 48/96 kHz만 지원하면 PipeWire가 리샘플링 때문에 CPU와 배터리를 더 쓰게 된다는 부분임
Apple은 전력 효율에 집착하는 회사인데 왜 여전히 이렇게 두는지 궁금해짐
44.1 kHz 비트 퍼펙트 CD/FLAC 재생이 가능해진 건 정말 큰 기능처럼 보임
Asahi 팀의 기술 글과 성과는 정말 대단하지만, 아직도 이게 별도 프로젝트로 남아 있고 kernel mainline이나 Ubuntu, Debian, Fedora 같은 주류 배포판 안에서 지속되는 형태가 아니라는 점은 조금 걱정됨
리버스 엔지니어링 프로젝트는 80%까지는 유용한 결과를 내기 쉬워도, 일반 사용자에게 충분히 다듬어진 95% 완성도까지 가려면 거의 같은 수준의 고되고 자잘한 작업이 더 필요함
Asahi도 바로 그 방향으로 많이 upstreaming하고 있음
최근 진전이 느려진 큰 이유도 diff 수를 줄이는 데 집중했기 때문이고, 꽤 많은 작업이 이미 mainline kernel에 들어갔음
Asahi는 새 기능을 실험하는 공간 역할도 하고 있음
ARM Mac 자체가 계속 움직이는 표적이라는 추가 난관도 있음
Apple은 Asahi Linux를 위해 안정성이나 지원을 제공할 생각이 전혀 없고, PC 업계처럼 장기 호환성을 맞출 이유도 없어서 앞으로도 Asahi를 곤란하게 만드는 변경을 해도 신경 쓰지 않을 것 같음
Linux의 좋은 점은 자유 소프트웨어라서 주주나 수익성에 얽매이지 않는다는 데 있음
M1 MacBook Air에서 Asahi를 기본 OS로 쓰고 있는데 꽤 만족스럽고, 잠자기 중 배터리가 시간당 1% 빠지는 같은 아쉬움이 있어도 100% 기능 완성이 아니라는 이유로 아예 없는 것보다는 지금 형태가 훨씬 나음
굳이 일반 대중용으로 완벽하게 다듬어져 있을 필요도 크게 못 느끼겠음
mainline kernel 개발은 원래 다들 자기 fork에서 작업한 뒤 패치를 upstream으로 보내는 식임
Asahi가 특별해 보이는 건 이상하고 전용 하드웨어가 많아 특수 드라이버가 많이 필요해서지, 누구도 Linus의 트리에서 직접 개발하진 않음
이 프로젝트가 계속 탄력을 받았으면 좋겠음 Apple 하드웨어 + Linux 조합이 최고의 하드웨어 위에서 돌아가는 가장 덜 망가진 OS처럼 느껴지고, macOS는 버그와 버전마다 뒤집히는 변화 때문에 점점 혼란스러움
Framework에 Fedora를 올려 써보면 생각이 달라질 수도 있음
경험이 아주 매끄러웠고, 곧 나올 Framework 13 Pro는 배터리와 트랙패드도 macOS급이거나 배터리는 오히려 더 나을 거라는 기대가 있음
세 주요 OS를 다 써봤는데 macOS가 가장 버그가 적고 그냥 잘 돌아가는 편이었음
Linux는 늘 오디오나 화면 호환성 때문에 이상한 패치를 하게 됐고, Windows는 배터리 문제가 심했음
Linux 튜닝 좋아하는 사람들 다수는 결국 더 많은 커스터마이징이 가능한 Mac 같은 경험을 원하는 것처럼 보이기도 함
전반적으로는 그렇지만 MLX 주변 생태계는 꽤 강하게 뭉쳤음
디스크 I/O가 별로고 OS도 버그가 있어도 적어도 최신 OS에서 ML이 컴파일되고 돌아감
반면 rocm은 거의 다 된 것 같다가도 미리 빌드된 패키지나 2년 넘은 Ubuntu가 필요해서 답답함 https://github.com/ROCm/TheRock/issues/3477
최근 업무용으로 MacBook Air를 써봤는데 하드웨어 최고 수준이라는 말에는 동의하기 어려움
5유로만 써도 더 나은 키보드를 구할 수 있을 것 같음
Apple이 왜 이 노력에 협조하지 않고 문서 공개를 안 하는지 이해가 잘 안 됨
경쟁 우위나 비밀 같은 전통적인 이유는 이제 설득력이 약해 보임
진짜 이유는 더 단순할 수도 있음
Apple은 하드웨어 마진이 높아서 Linux 사용자에게 MacBook을 파는 것만으로도 이익이 나지만, 공식적으로 Linux 지원을 인정하는 순간 그게 바로 지원 책임이 됨
kernel panic마다 Genius Bar 방문이 생기고 드라이버 버그마다 @AppleSupport가 호출될 테니, 지금처럼 비공식인 상태가 Apple 입장에선 하드웨어 판매는 챙기고 지원 부담은 피하는 가장 좋은 시나리오일 수 있음
금전적 이득은 거의 없고, 하드웨어가 바뀔 때마다 Linux용 문서화 부담이 생김
가장 시끄럽고 비판적인 사용자층이면서 규모는 작다는 점도 Apple에선 매력적이지 않을 듯함
아예 우린 이 게임 안 한다고 선을 긋는 편이, 선택적 개방이나 비공개 인터페이스 호환성 파괴로 욕먹는 것보다 훨씬 쉬울 수 있음
내부적으로도 우선순위와 무관한 논의를 계속 불러오는 걸 피할 수 있음
이건 거의 right to repair와 닿아 있다고 느낌
노트북은 여러 하드웨어 부품과 그것을 움직이는 드라이버로 이뤄져 있는데, 내가 산 게 하드웨어와 드라이버가 분리 불가능한 패키지인지, 아니면 한쪽이 망가졌을 때 다른 쪽을 직접 살릴 수 있도록 매뉴얼을 받아야 하는지 질문하게 됨
드라이버는 기어나 모터처럼 닳지 않는다고 Apple은 주장할 수 있겠지만, 그렇다고 작동 원리를 알 권리까지 사라지는 건 아니라고 봄
언젠가 /System/Trackpad.kext가 우주선에 맞아 날아가서 직접 드라이버를 써야 한다며 법정에서 문서를 요구하는 시험 사례가 나와도 이상하지 않을 듯함
맞는 말 같음
Apple이 이걸 지원하는 건 쉬운 일일 텐데, 커뮤니티에서 얻을 호의도 상당할 것 같음
Mac 같은 기본 경험에 초점을 둔 Asahi Remix 스핀이 있으면 관심이 있을지 궁금함
cmd를 주 수정키로 쓰고, Mac식 단축키와 테마, 제스처를 기본으로 맞춰주는 식임
아무 배포판이든 손보면 되지만, 잘 큐레이션된 기본값은 또 다른 가치가 있음
cmd를 “주 수정키”로 삼는 건 애매함
일반적인 X/Wayland 환경에서는 이미 DE 기능 쪽은 Cmd가 중심이고, 앱 수준에서는 Ctrl이 중심이라 그걸 바꾸면 겹치는 부분이 많이 생김
KDE에서 꽤 비슷하게 맞춰놓는 데 성공했음 Claude Code에게 구현해달라고 했더니 웹 검색해서 설정 파일까지 만들어줬음
Cmd 중심 키맵은 사실상 진 싸움에 가깝다고 봄
여러 번 시도해봤지만 결국 Ctrl 생활을 받아들였고 마지막 MacBook도 팔았음
MacBook Pro + Linux라는 꿈의 개발 머신을 먼저 현실로 만드는 쪽이 하드웨어일지 소프트웨어일지 궁금함
Asahi가 소프트웨어 측에서 먼저 도달할지, Framework가 하드웨어 측에서 먼저 도달할지 지켜보게 됨
MacBook Neo + Asahi 조합이 나오면 정말 강력할 듯함
M3 지원이 upstream 백로그를 처리하고 툴링을 개선하면서 착실히 진행되는 모습이 반가움
PCIe, MacBook 키보드와 트랙패드, SMC 기반 RTC와 reboot controller, NVMe controller 지원 패치가 Asahi kernel tree에 들어가고 있고, 이로써 M3의 Linux 지원 수준이 대략 M1용 첫 Asahi Linux alpha와 비슷한 단계까지 올라옴
이 속도라면 M6 출시 즈음에야 겨우 쓸만해질지도 모르겠음
이런 프로젝트 리포트에서 계속 돌파구가 나오고, 실제 사용자가 어디서 불편을 겪는지 정확히 짚고 있다는 건 Asahi 팀이 정말 노련하다는 뜻처럼 보임
조만간 Asahi로 다시 완전히 돌아가고 싶어짐
M3 alpha 근접 소식은 정말 훌륭하고, 앞으로 M4도 기대됨
반면 Apple이 올해나 내년에 macOS에 또 무슨 일을 벌일지는 전혀 기대되지 않음
Hacker News 의견들
CS42L84가 macOS에서는 48/96 kHz만 쓰도록 설정돼 있었는데, CS42L42 데이터시트의 다른 샘플레이트 값을 가져와 드라이버에 넣어보니 그대로 동작했다고 함
44.1/88.2/176.4/192 kHz를 헤드폰 잭 입출력에서 지원하는 패치가 upstream에 들어갔고, 7.1에 병합됐으며 Asahi kernel 6.19.9에도 백포트돼 바로 쓸 수 있게 됨
칩 추적과 리버스 엔지니어링이 정말 인상적임
Apple은 전력 효율에 집착하는 회사인데 왜 여전히 이렇게 두는지 궁금해짐
Asahi 팀의 기술 글과 성과는 정말 대단하지만, 아직도 이게 별도 프로젝트로 남아 있고 kernel mainline이나 Ubuntu, Debian, Fedora 같은 주류 배포판 안에서 지속되는 형태가 아니라는 점은 조금 걱정됨
리버스 엔지니어링 프로젝트는 80%까지는 유용한 결과를 내기 쉬워도, 일반 사용자에게 충분히 다듬어진 95% 완성도까지 가려면 거의 같은 수준의 고되고 자잘한 작업이 더 필요함
최근 진전이 느려진 큰 이유도 diff 수를 줄이는 데 집중했기 때문이고, 꽤 많은 작업이 이미 mainline kernel에 들어갔음
Asahi는 새 기능을 실험하는 공간 역할도 하고 있음
Apple은 Asahi Linux를 위해 안정성이나 지원을 제공할 생각이 전혀 없고, PC 업계처럼 장기 호환성을 맞출 이유도 없어서 앞으로도 Asahi를 곤란하게 만드는 변경을 해도 신경 쓰지 않을 것 같음
M1 MacBook Air에서 Asahi를 기본 OS로 쓰고 있는데 꽤 만족스럽고, 잠자기 중 배터리가 시간당 1% 빠지는 같은 아쉬움이 있어도 100% 기능 완성이 아니라는 이유로 아예 없는 것보다는 지금 형태가 훨씬 나음
굳이 일반 대중용으로 완벽하게 다듬어져 있을 필요도 크게 못 느끼겠음
Asahi가 특별해 보이는 건 이상하고 전용 하드웨어가 많아 특수 드라이버가 많이 필요해서지, 누구도 Linus의 트리에서 직접 개발하진 않음
결국 목표는 Linux가 Apple Silicon을 네이티브 지원하게 만드는 쪽임
이 프로젝트가 계속 탄력을 받았으면 좋겠음
Apple 하드웨어 + Linux 조합이 최고의 하드웨어 위에서 돌아가는 가장 덜 망가진 OS처럼 느껴지고, macOS는 버그와 버전마다 뒤집히는 변화 때문에 점점 혼란스러움
경험이 아주 매끄러웠고, 곧 나올 Framework 13 Pro는 배터리와 트랙패드도 macOS급이거나 배터리는 오히려 더 나을 거라는 기대가 있음
Linux는 늘 오디오나 화면 호환성 때문에 이상한 패치를 하게 됐고, Windows는 배터리 문제가 심했음
Linux 튜닝 좋아하는 사람들 다수는 결국 더 많은 커스터마이징이 가능한 Mac 같은 경험을 원하는 것처럼 보이기도 함
디스크 I/O가 별로고 OS도 버그가 있어도 적어도 최신 OS에서 ML이 컴파일되고 돌아감
반면 rocm은 거의 다 된 것 같다가도 미리 빌드된 패키지나 2년 넘은 Ubuntu가 필요해서 답답함
https://github.com/ROCm/TheRock/issues/3477
5유로만 써도 더 나은 키보드를 구할 수 있을 것 같음
Apple이 왜 이 노력에 협조하지 않고 문서 공개를 안 하는지 이해가 잘 안 됨
경쟁 우위나 비밀 같은 전통적인 이유는 이제 설득력이 약해 보임
Apple은 하드웨어 마진이 높아서 Linux 사용자에게 MacBook을 파는 것만으로도 이익이 나지만, 공식적으로 Linux 지원을 인정하는 순간 그게 바로 지원 책임이 됨
kernel panic마다 Genius Bar 방문이 생기고 드라이버 버그마다 @AppleSupport가 호출될 테니, 지금처럼 비공식인 상태가 Apple 입장에선 하드웨어 판매는 챙기고 지원 부담은 피하는 가장 좋은 시나리오일 수 있음
가장 시끄럽고 비판적인 사용자층이면서 규모는 작다는 점도 Apple에선 매력적이지 않을 듯함
내부적으로도 우선순위와 무관한 논의를 계속 불러오는 걸 피할 수 있음
노트북은 여러 하드웨어 부품과 그것을 움직이는 드라이버로 이뤄져 있는데, 내가 산 게 하드웨어와 드라이버가 분리 불가능한 패키지인지, 아니면 한쪽이 망가졌을 때 다른 쪽을 직접 살릴 수 있도록 매뉴얼을 받아야 하는지 질문하게 됨
드라이버는 기어나 모터처럼 닳지 않는다고 Apple은 주장할 수 있겠지만, 그렇다고 작동 원리를 알 권리까지 사라지는 건 아니라고 봄
언젠가 /System/Trackpad.kext가 우주선에 맞아 날아가서 직접 드라이버를 써야 한다며 법정에서 문서를 요구하는 시험 사례가 나와도 이상하지 않을 듯함
Apple이 이걸 지원하는 건 쉬운 일일 텐데, 커뮤니티에서 얻을 호의도 상당할 것 같음
Mac 같은 기본 경험에 초점을 둔 Asahi Remix 스핀이 있으면 관심이 있을지 궁금함
cmd를 주 수정키로 쓰고, Mac식 단축키와 테마, 제스처를 기본으로 맞춰주는 식임
아무 배포판이든 손보면 되지만, 잘 큐레이션된 기본값은 또 다른 가치가 있음
일반적인 X/Wayland 환경에서는 이미 DE 기능 쪽은 Cmd가 중심이고, 앱 수준에서는 Ctrl이 중심이라 그걸 바꾸면 겹치는 부분이 많이 생김
Claude Code에게 구현해달라고 했더니 웹 검색해서 설정 파일까지 만들어줬음
여러 번 시도해봤지만 결국 Ctrl 생활을 받아들였고 마지막 MacBook도 팔았음
MacBook Pro + Linux라는 꿈의 개발 머신을 먼저 현실로 만드는 쪽이 하드웨어일지 소프트웨어일지 궁금함
Asahi가 소프트웨어 측에서 먼저 도달할지, Framework가 하드웨어 측에서 먼저 도달할지 지켜보게 됨
MacBook Neo + Asahi 조합이 나오면 정말 강력할 듯함
M3 지원이 upstream 백로그를 처리하고 툴링을 개선하면서 착실히 진행되는 모습이 반가움
PCIe, MacBook 키보드와 트랙패드, SMC 기반 RTC와 reboot controller, NVMe controller 지원 패치가 Asahi kernel tree에 들어가고 있고, 이로써 M3의 Linux 지원 수준이 대략 M1용 첫 Asahi Linux alpha와 비슷한 단계까지 올라옴
이런 프로젝트 리포트에서 계속 돌파구가 나오고, 실제 사용자가 어디서 불편을 겪는지 정확히 짚고 있다는 건 Asahi 팀이 정말 노련하다는 뜻처럼 보임
조만간 Asahi로 다시 완전히 돌아가고 싶어짐
M3 alpha 근접 소식은 정말 훌륭하고, 앞으로 M4도 기대됨
반면 Apple이 올해나 내년에 macOS에 또 무슨 일을 벌일지는 전혀 기대되지 않음