리눅스 프롬 스크래치 프로젝트

• Linux From Scratch(LFS) 는 배포판 설치가 아니라, 소스 코드에서 Linux 시스템을 직접 빌드하도록 안내하는 단계별 프로젝트임
• 중심 문서는 LFS 메인 북이며, 나머지 프로젝트들은 이 기본 시스템을 확장하거나 자동화하는 역할을 함
• BLFS는 설치 후 시스템 확장, ALFS는 빌드 자동화, MLFS는 32비트 바이너리 빌드·실행 지원을 맡음
• GLFS는 Steam이나 Wine 같은 게임 지원 소프트웨어 설치를 돕고, SLFS는 BLFS 이후의 보완 영역을 다룸
• Hints, Patches, Editor's Guide, Museum은 책에 없는 개선 방법, 패치, 개발 절차, 오래된 버전 보관을 위한 보조 자료임

---

소스에서 직접 만드는 Linux 시스템

• Linux From Scratch(LFS) 는 자신만의 맞춤형 Linux 시스템을 전부 소스 코드에서 빌드하도록 돕는 프로젝트임
• 사용자는 단계별 지침을 따라 기본 Linux 시스템을 직접 구성함

LFS를 중심으로 나뉜 하위 프로젝트

• LFS: Linux From Scratch의 메인 북이며, 다른 모든 프로젝트의 기반임
• BLFS: 완성된 LFS 설치를 더 맞춤화되고 사용 가능한 시스템으로 확장함
• ALFS: LFS와 BLFS 빌드를 자동화하고 관리하는 도구를 제공함
• MLFS: 32비트 바이너리를 빌드하고 실행할 수 있는 LFS 시스템을 설정하는 변형임
• GLFS: BLFS 기반으로, 새 LFS 또는 MLFS 시스템에 Steam이나 Wine 같은 게임 지원 소프트웨어를 설치하도록 돕는 프로젝트임
• SLFS: BLFS를 넘어 LFS 설치를 보완함

보조 문서와 자료 저장소

• Hints: LFS 또는 BLFS 책에 포함되지 않은 방식으로 LFS 시스템을 개선하는 문서 모음임
• Patches: LFS 사용자에게 유용한 패치를 모아 둔 중앙 저장소 역할을 함
• LFS Editor's Guide: LFS 개발 프로세스를 설명하는 문서임
• Museum: 오래된 LFS와 BLFS 버전의 사본을 제공함

[GN⁺]

Hacker News 의견들

• 올해 초 LFS를 해봤고, 과정에서 많이 배웠지만 꽤나 가드레일 밖으로 나갔음
  평소에는 NixOS를 쓰고 있어서 “Nix 방식”으로 LFS를 끝낼 수 있을지 궁금했는데, 당시에는 Nix 초보라 어려운 과정을 더 어렵게 만든 선택이었음
  그래도 Nix의 선언적 성격 덕분에 모든 단계가 명확한 기록으로 남았고, 문제가 생기면 되돌아가 원인을 추적할 수 있었음. 결과물은 여기 있음: https://github.com/cloudripper/NixLFS
  Linux, 부트스트래핑, 교차 컴파일, Nix에 대한 이해가 크게 늘었고 지금도 가끔 참고함. 나중에 다시 손보면 커널 설정과 빌드 후 권한 처리 같은 부분을 정리하고 싶음
  Nix의 복잡함은 별개로, 작동 원리를 이해하는 걸 좋아하고 약간의 고통을 감수할 수 있다면 LFS를 강력 추천함

  • Nix/NixOS가 RPM 의존성 지옥과 여러 버전 동시 설치 문제를 해결하긴 했지만, 자기만의 문제도 만들었음
    모든 것이 너무 격리돼 있어서 설정하거나 쓰기 어렵고, 다른 운영체제처럼 동작하지 않으니 거의 모든 게 깨지는 느낌임
    온갖 특이점과 함정을 추적하는 일이 풀타임 IT 업무가 되고, 패치와 우회책이 쌓인 깨지기 쉬운 특수 눈송이 시스템이 되면 뭔가를 하거나 신뢰하기가 비싸고 느려짐
    패키징 DSL의 문법과 성격도 너무 영리한 특수 해법처럼 보이며, 선언적 데이터나 Python, Bourne shell, JS 같은 널리 쓰이는 절차적 방식으로도 충분했을 것 같음
    Qubes처럼 특정 목표에 과도하게 최적화하면 기존 생태계와의 호환성·사용성 부족 때문에 아킬레스건이 될 수 있음
  • 훌륭함. 이 경험을 발표나 글로 정리해볼 생각은 없는지 궁금함
  • Google에서 NixOS를 검색하면 가장 먼저 보이는 문구가 “Declarative builds and deployments”인데, NixOS는 Ubuntu 같은 다른 배포판과 정확히 뭐가 다른지 궁금함
  • 왜 파일 약 2,600개마다 chmod를 해야 했는지 궁금함. man 페이지, 문서, include 파일까지 전부인데 chmod -R 같은 걸 쓰면 안 됐는지?
    https://github.com/cloudripper/NixLFS/blob/64e333f60cca4bec5...

• 2000년대 초 고등학생 때 LFS와 Gentoo Stage 1·2 설치를 해본 덕분에 컴퓨터와 Linux를 배우는 여정에서 큰 우위를 얻었음
  어린 나이에 기반을 잡고 컴퓨팅에 흥미를 갖게 해준 프로젝트 관리자들에게 아무리 감사해도 부족함
  고등학교 프린터로 LFS 책을 조금씩 출력해서 집에 가져가 가정용 컴퓨터에서 사용했음

  • 20년이 지난 지금도 그게 컴퓨터 중독의 입문 약이었고, 매일 업무에서 쓰는 풀스택 이해의 기반이 됐음
    Gentoo와, 14살 때 일하던 카페에서 첫 경험을 맛보게 해주고 대부분에게는 정신적 고문에 가까운 과정을 곁에서 도와준 친절한 괴짜에게 애정이 있음
  • Gentoo를 꾸미면서 Linux, 특히 고치는 법을 많이 배웠음. 20년 넘는 경력이 지난 지금도 여전히 고치는 법을 배우는 중임
  • Knoppix 라이브 CD로 Gentoo stages를 반복해서 설치한 횟수가 셀 수 없이 많음
  • LFS와 Gentoo가 Linux 시스템을 이해하게 해줬음
    특히 2000년대 초 LFS와 Gentoo Stage 1·2 설치, LFS 책을 나눠 출력해 쓰던 경험이 그대로 떠오름
  • 맞음. 모든 걸 USE 플래그를 바꿔가며 다시 컴파일했음

• 아이디어는 정말 마음에 들고, 과정을 여러 번 따라가 보려고 했음
  하지만 매번 어느 순간부터는 이해 안 되는 명령을 터미널에 복사해 넣는 연습처럼 변했고, 의욕을 잃었음. 비슷한 경험을 한 사람이 있는지 궁금함

  • 접근할 때 마음가짐이 조금 달랐던 것 같음. 전체 과정을 끝내는 데 너무 집중한 느낌임
    LFS에서는 여정 자체에 큰 가치를 둬야 함. 명령을 복붙하는 게 아니라 각 단계에서 무엇을, 더 중요하게는 왜 하는지 실제로 이해하려 해야 함
    기억으로는 LFS 문서가 그걸 잘 도와줬음. 아니면 진행하면서 실제 구성요소 문서를 읽어서 그랬을 수도 있고, 아마 둘 다였을 것임
    2001년이나 2002년쯤 LFS 시스템을 한 번 세팅했는데, 컴파일 시간 때문에 며칠이 걸렸고 매우 흥미로웠으며 마지막에는 mutt와 slrn 설정을 다듬고 있었던 기억이 남아 있음
    전반적으로 훌륭하고 만족스러운 학습 경험이었지만, 일상용 시스템으로 쓰지는 않을 것 같음. 시간과 배울 의지가 있을 때 좋은 방식이라고 봄
  • 약 20년 전에 LFS를 만들었음. 대부분은 지시를 따랐지만 일부 구성요소는 직접 만들었음
    직접 init 스크립트를 썼고, 아마 initramfs도 직접 만들었던 것 같음. 확실하진 않지만 그 주변을 만지작거린 기억은 분명하고 아마 LFS였을 것임
    격리된 빌드 시스템과 자체 패키지 관리자도 만들고 싶었음. 기본적으로 파일 데이터베이스가 있는 tar 래퍼로 제거 가능하게 하는 정도였고, 복잡한 의존성 처리는 없었음
    당시에는 컨테이너가 없었고 fakeroot를 제대로 활용할 실력도 부족해서 구현하지 못했지만 실험은 꽤 했음. 지금이라면 Docker로 만들 텐데, 흥미로운 시대임
  • 직접 해본 건 아니지만 교육할 때 https://github.com/MichielDerhaeg/build-linux를 썼고, 학생들이 꽤 즐거워했음
    기본적으로 커널, libc, busybox, init 등을 빌드하고 전체를 qemu 안에서 실행하게 해줌
    들인 시간이 많지 않은데도 교육적 가치가 컸음
  • 고등학생 때 방과 후 시간이 많아서 YouTube 가이드를 보고 Arch를 설치했음. 정말 많이 실패했지만, 그 과정에서 각 명령이 뭘 하는지 어느 정도 배우게 됨
    Gentoo를 설치할 때도 같은 경험을 했음. 처음에는 둘 다 명령을 복사해 붙여넣었지만, 실패를 겪으면서 명령이 하는 일을 꽤 이해하게 됨
    다른 사람이 말한 것처럼, 입력하는 내용을 스스로 이해하도록 강제로라도 노력해야 함. man 페이지를 잠깐 훑기만 해도 큰 도움이 됨
  • 매뉴얼에서 아무 페이지나 하나 골라 봤음: https://www.linuxfromscratch.org/lfs/view/stable-systemd/cha...
    모든 단계가 설명돼 있고, 쓰인 모든 매개변수도 문서화돼 있음

• 숲속을 뛰어다닌다고 나무를 배우는 건 아니라고 말할 수도 있지만, 책을 들고 가면 꽤 효과적임
  Linux From Scratch는 Linux 배포판이 어떤 부품들로 구성되는지 탐색하는 재미있는 방법임
  오래전에 Gentoo로 넘어가기 전에 몇 번 해봤고, 운영체제를 진짜 처음부터 작성하지 않고도 세부 요소를 골라 구성할 자유를 체감하는 데 도움이 됐음

• LFS가 재미있다면 Buildroot도 살펴볼 만함
  Buildroot는 커널과 마찬가지로 Kconfig와 menuconfig, config 같은 관련 도구를 사용해 임베디드 Linux 시스템을 빌드할 설정을 생성함
  이 설정은 프로젝트 저장소에 커밋하고 패치할 수 있음. 애플리케이션이나 라이브러리를 추가하면 의존성이 자동으로 따라오고, 특정 기능을 더하는 조각 설정과 병합할 수도 있음
  여러 아키텍처용 교차 컴파일 도구체인을 직접 빌드할 수 있고, 개발자가 libc와 기타 도구체인 설정을 선택할 수 있음. 시간을 아끼기 위해 미리 빌드된 도구체인 tarball을 가져오도록 설정하는 것도 가능함
  패키지는 GNU Make로 작성되며, GitHub에서 코드를 가져오고 autoconf, cmake, meson, golang, Rust, python 등으로 패키지를 빌드하는 매크로도 제공됨
  디지털 사이니지 같은 임베디드 Linux 배포판부터, 대규모 장치 자동 프로비저닝을 위한 독립형 네트워크 부팅 애플리케이션, 컨테이너에서 실행할 최소 파일시스템 tarball까지 훌륭하게 작동함

  • 멋지긴 하지만 Buildroot 방식으로 패키지를 한두 개보다 많이 추가하기 시작하면 금방 수렁에 빠졌음
    더 나은 패키지 관리 접근을 가진 포크가 아직 없다는 게 가끔 놀라움

• 이게 뭐가 재미있는지 모르겠음. 예전에 잠깐 봤을 때 예상대로 필요한 소프트웨어를 개별적으로 빌드하고 설치하는 일이 대부분이었음
  그건 지루해 보이고, 진짜 재미는 “처음부터” 실제로 쓸 만한 배포판을 만드는 데 있을 것 같음

  • 첫 번째 실행은 그다지 재미없음. 뭔가를 빌드하는 법과 실행 중인 시스템의 구성 부품을 아는 건 유용한 기술이지만, 전반적으로는 Arch를 1년 쓰는 편이 더 많이 배울 수도 있다고 봄
    하지만 이후 반복 플레이부터는 창의적으로 해볼 수 있음. FHS를 무시하고 앱을 이상한 위치에 넣어볼 수도 있고, 다른 libc나 init 시스템을 쓸 수도 있으며, 특이한 셸을 중심으로 모두 빌드하거나 최대 최적화를 노릴 수도 있음
    재플레이성이 Linux From Scratch의 재미이고, 자기 배포판이 어떤 모습일지 고민할 가치도 충분함
  • 진짜 목표와 접근 방식에 따라 달라진다고 봄. http://www.greenfly.org/mes.html와 비교해볼 만함. Arch 사용자들에게도 꽤 해당되는 내용이라고 느낌
  • LFS로 기본 시스템을 만든 다음 자체 패키지 관리자를 얹으면 “진짜” 배포판에 가까워짐
    기존 배포판을 처음부터 빌드하고 싶은 것뿐이라면, 각 배포판은 정기적으로 패키지를 다시 빌드해야 하므로 이미 그런 방법을 갖고 있음
    예를 들어 Fedora 이미지는 LFS보다 Koji/OSBuild로 처음부터 만드는 게 훨씬 단순한데, Koji/OSBuild가 사실상 LFS 과정을 자동화하기 때문임
    LFS를 재미있게 하려고 책 전체를 다 할 필요도 없음. 커널과 정적으로 링크된 busybox만으로 작은 Linux “배포판”을 처음부터 만들 수 있음
    BusyBox에는 최소 유틸리티가 들어 있으니, 직접 쓸 것과 재사용할 것을 골라가며 구성하면 됨
  • LFS는 독자적인 배포판에 실제로 도전하기 전의 훈련으로 볼 수 있음. 배포판은 복잡하고, LFS 단계를 따라도 실수할 여지가 많아 꼭 동작하는 시스템이 나오지는 않음
    또는 배포판을 만들기 위한 기반으로도 쓸 수 있음. 일부 과정을 자동화하고 그 위에 pkgsrc를 얹는 식이 가능함
    새 프로그래머에게는 훌륭한 연습임. 소프트웨어를 발견하고, 의존성을 체감하고, Linux 배포판 구성요소를 이해하고, 소스에서 빌드하고, 커널을 설정하는 법 등을 배울 수 있음
  • 내부에서 어떻게 동작하는지 배우는 건 재미있고, 일이 Linux를 중심으로 돌아간다면 해볼 만함

• Gentoo를 커스텀 커널로 일상 사용하기 시작한 뒤인 2017년쯤 LFS를 했고, 시간이 많이 들 뿐 꽤 쉬운 편이었음
  IRC 사람들이 매우 친절했음. 요즘은 인프라보다 코드를 더 많이 쓰지만 여전히 가치 있는 경험이었다고 생각함
  Linux에 대한 전반적인 관심까지 합쳐져 클라우드 비용을 수천 달러 아껴줬을 것 같음
  젊은 소프트웨어 엔지니어 사이에서 Linux는 사라져가는 기술이지만, 젊은 너드들 사이에서는 살아 있음
  인프라/DevOps 쪽 사람들도 Linux를 더 배웠다면 가장 단순한 문제를 풀려고 Kubernetes부터 꺼내지는 않았을 것임

• LFS로 빌드하는 건 “배우기 위해 언젠가는 꼭 해야 할 일” 목록에 약 20년째 들어 있음
  언젠가는 하게 될 것임. 올해는 드디어 Lisp를 배우고 있는데 정말 즐기고 있음

  • 20년 전에 했더라면 같은 페이지에 있었을 것 같음
    당시에는 Gentoo를 stage 1부터 세팅하면서 많이 배웠고, 단일 사용자 모드에서 파티션을 다루거나 modprobe로 하드웨어를 감지하는 식의 문제를 고칠 때 오래 남는 지식이 됐음
    GUI에만 의존하는 것 이상을 못 하면 금방 막힐 수 있음
  • LLM 덕분에 이런 일이 더 접근하기 쉬워지지 않았을까?

• 배포판이 아닌 방식으로 동작하는 GNU/Linux 운영체제 빌드를 자동화하려고 했고, Linux From Scratch를 읽지 않고 kernel.org 공식 문서만 보려 한 적이 있음: https://github.com/andrewmcwatters/linux-workflow
  안타깝게도 Linux 문서 상태가 너무 나빠서 그렇게는 할 수 없음. kernel.org 자체가 가끔 링크하는 여러 제3자 글을 참고해야 함
  kernel.org가 Linux From Scratch를 언급할 수도 있지만, LFS도 initramfs 직후 왜 특정 의존성이 필요한지 설명을 매우 못함
  동작하는 셸이 필요하고, 설치 결과를 실제 드라이브에 올려야 하는데, 현재 문서만으로는 그 어느 것도 충분히 설명되지 않음
  LFS는 기껏해야 “이 재료들을 넣으라”고 말하고 나머지 정보는 거의 주지 않음. man 페이지를 읽어 이어 붙일 수는 있겠지만, 적어도 fsck/mount/cp로 파일을 어디에 설치할지 하드코딩해야 할 것 같음
  또한 LFS가 고르는 “기본 시스템 소프트웨어”의 이유도 제대로 설명하지 않으며, 그중 상당수는 일반적인 GNU/Linux 시스템에 실제로 필요하지 않음

  • initramfs가 대부분 선택 사항이라는 걸 알고 충격을 받았음. 건너뛰고 바로 사용자 공간으로 부팅할 수 있음

• 이 문서가 얼마나 최신인지 궁금함
  인터넷에서 복사·붙여넣기로 배우다 보면 오래된 Linux와 최신 Linux가 명령이나 모범 사례를 다르게 써서 가끔 걸려 넘어짐. 예를 들면 ipconfig와 ifconfig, iptables와 후속 도구 같은 차이임

  • 2024년 9월에 마지막으로 업데이트됐음. Distrowatch의 패키지 목록을 보면 예상되는 버전 번호를 감 잡을 수 있음: https://distrowatch.com/table.php?distribution=lfs
    BLFS 부분에 들어가면 새 방식을 시도할지, 오래됐지만 유지보수 중인 방식을 쓸지 선택지가 더 많음
    예를 들어 Pulseaudio와 Pipewire, Xorg와 Wayland, SysVinit과 systemd에 대한 지침이 모두 있음
    작업 대부분이 더 예측 가능한 빌드 환경을 만든 뒤에 이뤄지므로, 환경이 아주 특이하지 않은 한 현대 배포판에서 지침이 완전히 틀리는 경우는 드묾
  • 최신임. 이번 주에 가이드를 따라 LFS 시스템을 성공적으로 빌드했음