이 상황에는 어느 정도 공감함. 내 Raptor Talos II에서는 IBM이 PowerNV를 계속 깨뜨리고 있음
처음엔 amdgpu였고, 이제는 SATA 카드가 문제임. IBM이 비베어메탈 시스템용 PCIe를 계속 만지작거리는 바람에 6.14 커널에 묶여 있음

어떤 Linux 배포판을 쓰는지 궁금함. 회사 서버는 Ubuntu 26.04에 7.0 커널을 올려 쓰고 있는데 지원이 잘 되고 있음
출시 때부터 하나 갖고 싶었지만 이제는 꽤 오래됐고, 어쩌면 Power 11 버전이 나올 수도 있겠다는 생각이 듦

나도 비슷했음. Thinkpad X13S에서 NixOS를 돌려보려 했고, 어느 정도는 동작했지만 설치부터 Ubuntu ISO를 써야 했음
제대로 부팅되는 aarch64 UEFI NixOS 이미지를 찾지 못했기 때문임. 최신 커널 업그레이드 이후 부팅이 깨졌고, 이제는 시스템을 그냥 동작하게 만드는 데 쓸 기력이 바닥남
Ubuntu도 X13S 지원이 어느 정도 들어 있지만, 전통적인 x86_64 머신이라면 당연히 되는 것들이 꽤 많이 안 됨. 절전은 아예 안 되고, TPM 지원은 제한적이며, 그래픽도 특이하게 굴고, 테스트하지 못한 문제도 더 많을 것 같음
여기에 Anbernic 같은 회사의 에뮬레이션 핸드헬드처럼 오래된 이미지만 제공되는 ARM 장치나, Clockwork uConsole처럼 하드웨어를 영리하게 쓰거나 남용해서 비표준 커널 패치가 필요한 장치들은 제외하고도 그렇다. 결국 그런 소프트웨어는 업스트림에 들어가지 못하고, 업데이트할 수 없는 운영체제를 단 하드웨어로 남게 됨
Linux에서 ARM이 잘 동작하길 바라며 여러 컴퓨터에서 꽤 시간을 썼지만 막혀 있음. Raspberry Pi를 제외하면 그냥 되는 것이 없었고, 하드웨어/커널 쪽을 충분히 몰라서 의미 있는 개선을 만들기도 어려움

나도 X13S를 샀음. 크기와 무게가 완벽해 보였기 때문임
같은 방식으로 NixOS 설치에 몇 시간을 썼고, Ubuntu에서 설치해 대충 동작하게 만들었지만 너무 취약해서 사실상 제대로 쓰기 어려웠음
정말 잘 되길 바랐지만 Linux 쪽에서는 버려진 느낌이었고, 결국 포기하고 Apple MacBook Air에서 NixOS를 가상 머신으로 돌리게 됨

나도 X13s가 있는데, 시도한 배포판은 Fedora뿐이고 설치 프로그램을 시작하면 입출력 멈춤이 생김. 좋지 않음
Ubuntu에 큰 애정이 있는 것도 아니라 다른 배포판은 굳이 시도하지 않았고, Windows는 그래도 충분히 괜찮게 동작함
더 최신 SoC들은 특이점이 훨씬 적음. 예를 들어 커널 명령행을 한 문단 길이로 입력할 필요가 없음. 하지만 X13s의 X Elite 2 버전은 나오지 않음

새 Nvidia RTX Spark 노트북들이 공식 Linux 지원을 받을지 궁금함
결국 Ubuntu 파생 배포판을 돌리는 DGX Spark와 거의 같은 플랫폼인데, 지금까지의 조짐은 그다지 좋아 보이지 않음

반대 경험을 이야기하자면, Radxa Rock5bPlus를 4개월 정도 쓰고 있음. 16GB 메모리와 NVMe 구성이고, 메인라인 u-boot와 Fedora Rawhide의 EFI 버전, 메인라인 커널을 사용함
Collabora가 rk3588 지원을 메인라인에 올리기 위해 한 작업은 사실상 놀라울 정도임
아직 기다리는 부분은 있음. HDMI 2.0 이상, 즉 4k@60, 그리고 USB-C DP 같은 것들임. 그래도 하드웨어 측면에서는 내 XPS 13 9370보다 오히려 특이점이 적은 것 같음. 그 노트북은 5.14쯤부터 오디오 출력이 그냥 멈췄음 https://dell.com/community/en/… https://gitlab.collabora.com/hardware-enablement/rockchip-3588/…

OrangePi 5 Plus를 쓰고 있는데, HDMI 캡처가 이제 병합된 것을 봤음
아직 HDCP 지원은 없지만, 예전에 해봤던 저지연 1080p HDMI OSD 실험으로 돌아갈 때가 된 듯함
3프레임 지연으로 동작했었고, 이론상 최소는 2프레임. HDMI 신호 위에 Chromium Embedded를 오버레이해서 홈 미디어 구성에서 OSD 능력을 크게 확장할 수 있었음
가장 큰 문제는 불안정성이었고, 전체 구성이 OrangePi 커널을 정기적으로 크래시시켰음

이건 현재 Linux의 하드웨어 지원 상태를 더 잘 보여주는 것 같음. 인기가 있고 수익성이 있는 하드웨어만 커널 지원을 받고, 바이너리 드라이버의 상태는 예전부터 지금까지 계속 지옥임
사람들이 자기 하드웨어에서 뭔가를 동작시키려고 Linux를 쫓아다니다가 결국 오래된 커널에 묶이거나, 패치를 직접 유지하고 리베이스해야 하는 모습이 흥미로움. 이런 일을 하지 않아도 오래된 하드웨어를 지원하는 운영체제를 쓰는 대신 말임

내게는 이 결함 있는 하드웨어를 AMD GPU와 잘 동작하게 만들 방법을 아직 찾는 중처럼 들림
“Altra 제품군 정오표에 따르면 PCIE_65는 PCIe MMIO 쓰기에서 잘못된 주소를 생성할 수 있고, 특정 장치 유형, 특히 AMD GPU에 영향을 주므로 Altra 제품군은 일반적으로 그런 장치 유형과 호환되지 않는다. 실험 및 개발 작업을 진행할 수 있도록 GPL v2로 개념 증명 소프트웨어 패치를 제공했다”는 내용임
운영체제가 단순한 개념 증명 패치를 받아들이고 싶어 하지 않을 이유는 이해됨
특정 하드웨어 조각을 지원하는 Linux 커널 포크가 아주 많고, 이건 안타까운 일임. 이런 포크에는 메인라인 Linux 커널에 받아들여지려면 더 많은 작업이 필요한 침습적이거나 실험적인 커밋이 들어 있는 경우가 많음
다른 운영체제들은 여기서 다른 길을 가고 있는지 궁금함. 업스트림 기여를 쉽게 만들면서도 아키텍처, SoC, 보드 유지보수를 감당 가능하게 하려면 무엇을 하고 있을까

그렇다면 시도해보려던 수고는 덜었음. 그래도 고통 지점을 파악하는 일이 장기적으로는 도움이 되길 바람

나만 고생하는 줄 알았음. 개발 서버로 비슷한 사양을 썼는데, 대부분의 문제는 네이티브 코드가 있는 Python 의존성에서 나왔음
몇몇 최적화 패키지와 Matplotlib도 기억남. 일반 pip와 uv를 다 시도했지만 결국 소스에서 컴파일해야 했음. 결국 x86으로 완전히 돌아갔고, 솔직히 코어가 그렇게 많아도 성능이 그리 대단하지 않았음

“pip와 uv를 다 시도했지만 결국 소스에서 컴파일해야 했다”는 게, pip 바깥으로 나가 패키지를 직접 빌드해야 했다는 뜻인지 궁금함

게임용으로 실제로 동작하는 Linux 데스크톱을 원한다면 Nvidia 카드와 바이너리 드라이버가 필요하고, 거기에 잘 맞춰 동작하지 못하는 Flatpak 같은 것은 피해야 함
이건 어떤 아키텍처에서든 수십 년 동안 그랬고, 상식에 가깝다고 봄

나는 AMD GPU를 쓰는데 Linux에서 게임이 아주 잘 됨. 게다가 예전 Nvidia와 그 멍청한 폐쇄형 드라이버 덩어리보다 전반적인 자잘한 문제도 적음

다른 용도로 Cuda 같은 Nvidia가 꼭 필요한 게 아니라면, Linux 게임에서는 몇 년 전부터 AMD가 선호되는 GPU였음

무슨 소리인지 모르겠음. AMD GPU는 게임에 잘 동작하고, 예를 들어 Flatpak 안의 Steam도 잘 됨
Steam의 경우 Flatpak에서는 Steam 컨트롤러 접근이 안 되긴 하지만, 그 외에는 문제없이 동작함
그런 주장을 하려면 “나를 믿어” 말고 뒷받침할 데이터라도 가져와야 함

최근 몇 년 동안 같은 기간을 놓고 보면, AMD 기반 Steam Deck, AMD APU인 5750GE 기반 미니 PC, Intel Arc B580이 NVIDIA 3090보다 실제로 더 나은 경험을 줬음

이렇게 커널 패치에 민감한 구성이라면 배포판의 커널 패키지는 아예 쓰지 않을 것 같음
패키지 시스템 밖에서 직접 커널을 빌드하고 부팅한 뒤, 내 속도에 맞춰 업데이트하겠음

이 글 흐름을 조금 따라보고 있었는데, 그렇게 오래 동작했다는 게 오히려 놀라웠음
항상 “어떻게든 되게 만들기”에 가까워 보였고, 그래도 이런 결말을 읽으니 아쉬움