Libreboot 26.10 “Ominous Olive”가 UEFI와 Chromebook 지원을 담아 나왔습니다

Libreboot 26.10 "Ominous Olive" released with UEFI, Chromebook support

libreboot.org ▲ 252 댓글 152 iamnothere

요약

Libreboot 26.10이 UEFI를 기본으로 바꾸고 Chromebook 233종을 새로 지원합니다.

자유 소프트웨어 펌웨어 배포판 Libreboot의 레아 로가 10월 15일 새 버전을 냈습니다. 지난 26.01 이후 기능을 크게 늘린 릴리스로, 부팅 구조를 바꾸고 AI로 만든 코드를 받지 않는 정책도 넣었습니다.

왜 중요한가

  • UEFI(현대 PC의 표준 펌웨어 규격)를 갖춰 윈도 10·11도 Libreboot 기기에서 부팅됩니다.
  • 리눅스는 GRUB 없이 systemd-boot로, FreeBSD는 텍스트 모드 없이 UEFI로 띄울 수 있게 됐습니다.
  • 다른 배포판의 Chromebook 목록을 자동으로 들여오는 도구가 생겨 지원 기기가 한꺼번에 늘었습니다.

핵심 내용

  • 거의 모든 보드의 기본 페이로드(펌웨어가 마지막에 띄우는 부트 프로그램)를 EDK2로 바꿨습니다.
  • 기존 GRUB과 SeaBIOS도 함께 들어 있어 부팅 때 ESC로 연 설정 메뉴에서 고를 수 있습니다.
  • MrChromebox 배포판의 인텔·AMD Chromebook 233종을 들여왔지만 소스 빌드만 되고 시험한 기종은 하나입니다.
  • 작성자는 AGENTS.md에 담은 AI 반대 정책을 이번 릴리스에서 가장 중요한 변화로 꼽았습니다.
  • CSMWrap(구형 BIOS 호환층)이 CPU 코어 하나를 차지하고 키보드 배열이 영국식으로 고정되는 제약이 남았습니다.

HN 반응

  • 일부 이용자는 AI 논쟁에 가려졌을 뿐 UEFI와 Chromebook 지원으로 쓸 수 있는 기기가 몇 배로 늘었다고 평가했습니다.
  • GCC·GRUB의 AI 코드를 걷어내겠다는 계획에는 리눅스 커널에도 AI 코드가 많다는 반론과 법적 위험을 든 작성자의 반박이 맞섰습니다.

댓글

30개 표시 · 전체 152개
  1. iamnothere HN

    다들 AI 정책에만 주목하는데(리아가 왜인지 이게 이번 릴리스에서 가장 중요한 부분이라고 말해서일 수도 있겠네요), UEFI/EDK 통합과 Chromebook 지원이야말로 엄청난 진전입니다. 갑자기 Libreboot이 지원하는 기기가 몇 배로 늘었고, 앞으로 나올 기기도 훨씬 쉽게 추가할 수 있게 됐어요. 이건 정말 큽니다.

  2. leahlibre HN

    AI 정책을 두고 달린 댓글 중에는 봇이 쓴 것도 있을 거예요. 요즘 프로젝트마다 정치적인 논쟁판에 봇이 도배하는 일이 흔하잖아요.

  3. iamnothere HN

    맞아요. 그리고 진짜 리아 본인이시라면, 릴리스 축하드리고 그동안 이 프로젝트에 쏟아 주신 노고에 감사드립니다.

  4. leahlibre HN

    네, 제가 리아 로예요.

  5. sunaookami HN

    자기 객관화가 아예 안 되시는 건가요?

  6. Velocifyer HN

    드디어 내 낡은 Chromebook을 쓸 데가 생기겠네요.

  7. versooth HN

    혹시 모르실까 봐 알려드리는데, https://docs.mrchromebox.tech/ 도 있어요.

  8. kyrra HN

    AI를 별로 좋아하지 않는 모양이에요.

    https://codeberg.org/libreboot/lbmk/src/branch/master/AGENTS.md

  9. ImaCake HN

    별로 정도가 아니라 정말 싫어해요. "GCC와 GRUB에 AI가 들어 있으니 이것들에 의존하고 싶지 않다" 수준으로 AI를 혐오합니다. 링크된 페이지 아래쪽에 있는 이 대목을 보세요.

    문제의 포크, 즉 U-Boot 포크는 AI로 바이브 코딩한 부분이 많아서 Libreboot에는 쓸모가 없다. 이는 추측이 아니다. 앞서 언급한 U-Boot 메일링 리스트 글타래에서 작성자가 직접 그렇게 밝혔다. 우리는 어떤 식으로든 AI 사용을 권장하거나 지원하지 않을 것이다. Libreboot이 사용하는 여러 프로젝트에도 AI의 도움을 받은 커밋이 일부 있다는 점이 분명해졌다. GCC, GRUB 등이 그렇다. 이는 우리 잘못이 아니지만, 나와 다른 사람들이 앞으로 이 프로젝트들을 감사(audit)해서 슬롭을 걷어내고, 바로 그런 이유로 아예 포크까지 할 생각이다.

  10. jameshilliard HN

    U-Boot 업스트림 자체가 적어도 이번 릴리스 시점에는 AI에 강하게 반대하며, 위 내용에 관해 그쪽 메일링 리스트에서 많은 논의가 있었다.

    저도 이 대목을 봤는데, 웃기네요. 저는 AI의 도움을 받아 작성한 패치를 업스트림 U-Boot에 꽤 많이 보냈거든요. 제가 알기로 U-Boot는 대체로 커널 관례를 따르는 편이에요. 많은 U-Boot 드라이버가 (서브시스템 메인테이너들까지 포함해서) 커널의 대응하는 드라이버와 코드를 공유하니까요.

  11. cromka HN

    슬롭을 걷어내고 어쩌면 포크까지

    아니면, 잠깐 들어 보세요, 차라리 부족하다고 생각하는 코드를 개선해서 기여하면 되지 않을까요?

  12. sippingabonedry HN

    저는 "슬롭 걷어내기"를 "암호화를 직접 만들기", "다 만들어진 소프트웨어를 그냥 Rust로 다시 짜기"와 같은 부류로 봐요.

  13. tecleandor HN

    그건 당신이 뺀 문장의 앞부분에 있잖아요.

    ...나와 다른 사람들이 앞으로 이 프로젝트들을 감사해서 슬롭을 걷어내고...

  14. cromka HN

    저한테는 그런 뜻으로 읽히지 않아요. 그리고 이런 접근 방식에 이런 선언문을 내건 사람이 슬롭이 섞인 업스트림 프로젝트의 슬롭을 걷어낸 패치를 실제로 올릴 것처럼 굴지는 맙시다.

  15. leahlibre HN

    슬롭이 들어간 프로젝트에 기여하는 건 법적 책임이 따를 수 있어요. 슬롭을 git 히스토리 같은 데서까지 없애려면 사실상 하드포크를 해야 하고요.

    제가 이 작업을 하게 되면 이렇게 할 거예요. lbmk에 이미 있는 nuke.list 메커니즘(출처가 불분명한 파일, 예를 들어 U-Boot에서 라이선스가 불분명한 코드 파일을 지우는 데 이미 쓰고 있어요)을 다시 써서 슬롭이 섞인 파일을 삭제합니다. 그런 다음 같은 파일의 정리된 버전을 제공하고, 필요한 패치는 필요한 만큼 다시 작성하고, 그 파일을 쓰는 파일들은 foo.c 대신 foo.deslop.c를 포함하도록 패치해요. 그러면 tarball 안에서는 git 히스토리가 사라집니다. 프로젝트별 변경 로그도 그에 맞게 걸러내고요.

    슬롭이 아주 적은 프로젝트에서는 이게 가장 합리적인 방법이에요. 거의 전부가 슬롭이 되어 버린 프로젝트라면 하드포크가 불가피하고요.

  16. yjftsjthsd-h HN

    그럼 빌드하고 머신에서 돌리는 OS는 뭔가요? https://codeberg.org/ethical-foss/open-slopware#kernels 에는 제가 보기에 리눅스의 괜찮은 대안이라고 할 만한 게 없어 보여요. illumos나 9front가 libreboot의 선호 빌드 환경이 된다면 제 안의 너드가 기뻐하겠지만요.

  17. leahlibre HN

    지금은 Debian Linux이고, lbmk를 OpenBSD로 포팅하는 게 TODO에 있어요. 몇 가지 작은 예외(예: 최근 tmux 패치)를 빼면 거기는 대체로 AI 사용에 꽤 적대적이에요.

  18. bitwize HN

    커널은 지금 코드의 20% 정도가 AI 코드예요.

  19. jameshilliard HN

    Debian 유저스페이스도 상당한 비율이 어떤 식으로든 AI의 도움을 받아 작성됐을 가능성이 높아요.

  20. trollbridge HN

    리눅스 커널은 어떻게 쓰시나요?

  21. matheusmoreira HN

    참 안타깝네요. 저는 AI로 리버스 엔지니어링한 펌웨어를 여러 개 갖고 있는데 어떻게 해야 할지 모르겠어요. 이제 업스트림에는 절대 못 들어가겠죠. 남은 방법은 AI한테 이걸 통합해 달라고 시키는 것뿐이네요.

  22. Gigachad HN

    요즘 오픈소스에서 이런 충돌이 자주 생기는데, 결론은 그냥 자기 저장소와 공간을 따로 만들어서 누구 허락도 받지 않고 AI 결과물을 마음껏 쏟아 내라는 쪽이었어요. 유용하다고 생각하는 사용자는 쓰면 되고, 원치 않는 메인테이너와 부딪힐 일도 없으니까요.

    artcraft 같은 이런 AI 허용 프로젝트가 사람이 전부 직접 관리하는 프로젝트보다 더 인기를 끌지는 시간이 지나 봐야 알겠죠.

  23. ketzu HN

    읽다 보면 웃긴 대목이 꽤 있어요.

    그리고

    https://codeberg.org/ethical-foss/open-slopware

    이건 규탄문이라기보다 소프트웨어 탐색 목록에 가까워 보여요. 분류해 줘서 고맙네요.

  24. KAMSPioneer HN

    이 목록, 좀 이상하지 않나요? 예를 들어 리눅스 커널, Fedora, Bazzite/Bluefin 등의 관대한 AI 정책을 비판해 놓고는, 대안으로 Secureblue를 넣어 놨어요...?

    Secureblue는 멋진 프로젝트이긴 하지만, 말씀하신 것처럼 범용 탐색 목록이라고 해야 더 말이 돼요. 관대한 AI 정책을 쓰는 프로젝트를 피하고 싶다면 Secureblue가 bluebuild(Bazzite 팀 제작), Fedora, 리눅스 등등을 기반으로 한다는 점도 따져 봐야 하고요.

  25. doublepg23 HN

    소프트웨어 탐색 목록

    정말 그래요. 한동안 유행했던 awesome-X 목록 대부분보다 낫다는 생각이 들어요.

  26. dorianniemiec HN

    맞아요, 저도 이 "open-slopware" 목록을 봤는데, 검증이 충분히 된 웹 서버를 여럿 "관대한 AI 정책"으로 분류해 놨더라고요. 반면 대안으로 올려 둔 것 중 하나는(전부는 아니고, 일부는 검증된 쪽을 물려받았지만) 실전 검증이 제대로 안 됐어요. 오히려 코드베이스가 뒤엉켜 있고 코딩 관행도 썩 좋지 않은 걸 봤습니다.

  27. john_strinlai HN

    정말 그러네요!

    *"AI가 당신을 슈퍼 해커로 만들어 준다고 생각하세요? 다시 생각해 보세요: https://arxiv.org/abs/2507.09089 *"

    제가 AI를 특별히 옹호하는 건 아니지만, 사람들이 2026년 후반의 AI를 쓰고 있는데 2025년 초반 AI를 다룬 논문에 기대는 건 좀 우스워 보여요. 둘이 얼마나 다른데요.

  28. leahlibre HN

    뭐가 다른데요? 동작 원리가 되는 알고리즘이 갑자기 바뀌기라도 했나요?

  29. jameshilliard HN

    뭐가 다른데요? 동작 원리가 되는 알고리즘이 갑자기 바뀌기라도 했나요?

    다른 기술들처럼 AI 알고리즘과 도구도 시간이 지나면서 계속 다듬어지고 개선돼요.

    최근 1년 사이에 현대 AI가 특히 잘하게 된 게 리버스 엔지니어링이에요. 예전에는 Ghidra MCP 같은 특화된 연동을 붙여도 바이너리를 분석할 때 헤매고 실수가 잦았는데, 지금은 심하게 스트립된 BROM 바이너리까지 사용자가 거의 안내하지 않아도, 특별한 환경 없이도 아주 빠르고 정확하게 분석해요. 예전에는 며칠에서 몇 주씩 걸리던 바이너리를 지금의 AI는 몇 분에서 몇 시간이면 분석합니다.

    그 기간 동안 이 도구들을 계속 써 온 사람이라면 누구에게나 차이가 엄청나고 분명하게 보일 거예요.

  30. john_strinlai HN

    뭐가 다른데요?

    그 질문을 선의로 하신 것 같지 않네요.

    그리고 정책을 쓴 리아가 정말 당신이라면, 이건 아무 소득 없는 대화가 될 게 확실해요. 당신은 자기 신념에 단단히 뿌리박고 있는 게 뻔하니까요. 제가 무슨 말을 하든, 뭘 보여 주든, 뭘 증명하든 마음을 바꿀 거라는 착각은 하지 않아요.

Hacker News에서 보기 ↗