GoboLinux, 파일시스템을 패키지 DB로 쓰는 실험적 리눅스 배포판

 (gobolinux.org)
3P by GN⁺ | ★ favorite | 댓글 1개
  • 기존 리눅스 배포판의 디렉터리 관습을 크게 바꿔, 시스템 구성을 프로그램별 디렉터리 중심으로 이해하게 만드는 실험적 배포판임
  • 별도 패키지 데이터베이스 대신 파일시스템 자체를 데이터베이스로 삼고, 프로그램은 /Programs/Nano/8.3 같은 경로에 버전별로 배치됨
  • 최신 릴리스 017.01은 이전 ISO 릴리스 이후 약 5년 만의 버그 수정 업데이트로, 그동안의 일부 중요한 문제를 다룸
  • 창립자 Hisham Muhammad가 25년간의 운영에서 물러나고, 프로젝트는 GitHub 사용자 @fyrak1s가 이어받음
  • Live 환경으로 직접 실행하거나 하드 드라이브에 설치해, 일반 배포판과 다른 파일시스템 구조를 실제로 시험해볼 수 있음

파일시스템으로 패키지를 구성하는 방식

  • GoboLinux는 전체 파일시스템 계층을 재정의하는 실험적 리눅스 배포판임
  • 핵심은 별도 패키지 데이터베이스를 두지 않고 파일시스템을 데이터베이스로 쓰는 구조임
    • 각 프로그램은 자기 디렉터리에 들어감
    • 예시는 /Programs/Nano/8.3, /Programs/GCC/14.2.0임
  • 일반적인 리눅스 배포판과 구조가 다르기 때문에, 처음 접하는 사용자는 문서를 먼저 읽는 편이 좋음

017.01 릴리스와 운영 주체 전환

  • 현재 버전은 017.01임
    • USB 드라이브와 DVD에서 실행 가능한 Live 환경임
    • 하드 드라이브에도 설치할 수 있음
    • ISO는 Downloads에서 받을 수 있음
  • v017.01은 약 5년간의 공백 이후 나온 버그 수정 업데이트임
    • 이전 ISO 릴리스 이후 나타난 일부 중요한 문제를 다룸
    • 자세한 변경 사항은 release notes에서 확인할 수 있음
  • 프로젝트 운영도 바뀜
    • 창립자이자 25년간 GoboLinux를 이끈 Hisham Muhammad가 공식적으로 물러남
    • 프로젝트는 @fyrak1s의 운영 아래 계속됨
    • Lucas Correia Villa Real, 별칭 paranoidd는 2021년 6월까지 Hisham과 함께 GoboLinux를 유지해왔음
  • 커뮤니티 거점은 채팅, 포럼, 위키로 나뉨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • GoboLinux 설계에 강한 즉각적 거부감이 드는 사람이라면, 20년 된 “I am not clueless”¹ 문서에 배경과 논리가 꽤 많이 담겨 있음
    아직 완전히 거부감이 사라진 건 아니지만, 예전만큼 강하지는 않게 됨 ;)
    ¹ https://gobolinux.org/doc/articles/clueless.html

    • 글의 느낌이 HTMX나 Tailwind 문서와 비슷함
      “우리가 다르다는 거 안다. 아주 단순하다. 익숙하지 않을 수 있지만 이해하고 다루기 쉽다. 안 써도 된다. 우리는 이게 좋고 만족한다” 정도로 요약됨
    • 링크된 글의 make all programs relocatable 부분에서 libprefix를 써서 모든 앱을 다시 작성해야 한다고 하는데, 여기서 libprefix 가 뭘 뜻하는지 궁금함
      웹 검색으로는 쓸 만한 결과가 나오지 않음
    • 반사적 거부감의 상당 부분이 기능적 요소보다 겉보기 설계에서 오는 건 아닌지 궁금함
      예를 들어 첫 반응의 상당 부분은 대문자 표기에서 오는데, 대문자 P의 Programs는 Windows의 Program Files를 떠올리게 해서 감정적으로 거부감을 줌
      libx11 대신 LibX11을 입력해야 한다면 약간 짜증 날 것 같기도 함
      Linux 파일시스템은 보통 대소문자를 구분하지만, 패키지 이름은 대소문자만 다른 중복을 피할 테고, 사용자 친화적 계층을 지향하는 배포판이 루트에 대소문자만 다른 디렉터리를 둘 가능성도 낮아 보임
      그래도 예시가 /packages/libx11/1.6.9, /packages/gcc/9.2.0였다면 초기 반응이 훨씬 덜했을 것 같고, 그런 이름으로도 이점은 전혀 줄지 않았을 듯함

  • GoboLinux의 아이디어가 주류 Linux 커뮤니티에 자리 잡지 못한 게 정말 아쉬움
    Linux의 파일시스템 구조는 완전히 엉망임

    • 동의하지만 Nix, Guix, 그리고 내가 가장 많이 작업하는 Spack이 기본적으로 같은 방향을 취하면서 점점 힘을 얻는 걸 보니 반가움
      제대로 동작하게 만드는 건 항상 사소하지 않고, 효율적으로 만들기는 더 어려움
      최근 몇 년이 되어서야 대부분의 소프트웨어 배포에 대해 이 모델이 실제로 유지 가능한 수준에 가까워졌다고 느낌
    • Nix는 점점 인기를 얻고 있음
      GoboLinux 모델은 /Programs/Xorg/7.0 같은 버전 디렉터리를 수동으로 관리해야 하는데, Nix는 패키지의 설치 경로를 빌드 레시피의 해시로 정해 그 문제를 없앰
    • 지금 일관되게 말이 되는 건 /home과 /tmp 정도라고 봄
      나머지는 원하는 걸 아무 데나 넣는 잡동사니에 가까움
    • 그 아이디어들은 확실히 나에게 영감을 줬음
      GoboLinux는 Linux에서 정말 원하는 대로 해도 된다는 걸 처음 보여준 프로젝트였음
    • /opt와 /srv, 취향에 따라 /usr/local/opt는 GoboLinux처럼 구성 요소를 하나씩 관리하는 장점을 꽤 제공함
      배포판 관점에서는 모든 게 나름 말이 됨
      dpkg -S this-file을 치면 /usr 안의 파일이 왜 있는지 금방 알 수 있고, 배포판이 전체 그림을 그려주는 역할을 함
      어떤 부분이 가장 엉망이라고 보는지 궁금함

  • 전통적인 경로를 GoboLinux의 대응 경로로 매핑해서 Unix 유산과의 호환성을 투명하게 유지한다는 점이 흥미로움
    특별한 마법은 없고 /bin은 /System/Index/bin 링크이며, /usr/bin과 /usr/sbin도 마찬가지로 모든 “바이너리” 디렉터리가 같은 곳을 가리킴
    덕분에 어떤 표준 경로로 접근해도 파일이 동작하므로, 실제 파일이 /usr/local/bin/foo에 있는데 스크립트가 /usr/bin/foo를 참조해 깨지는 일반 배포판보다 오히려 더 호환적일 수 있음

  • 잘 모르고 묻자면, macOS가 어느 정도 이런 식으로 동작하는 건가?
    애플리케이션이 항상 드래그 앤드롭해서 관리하는 하나의 “파일”처럼 보이는 방식은 정말 좋았음
    Ubuntu에서 뭔가가 어디에 있고 어디에 설치되는지 파악하려 하면 내가 바보가 된 느낌이 듦

    • Ubuntu에서 뭐가 어디에 있고 어디로 들어가는지 알아내기 힘든 문제는, Linux 파일 관리자가 홈 폴더나 마운트된 드라이브가 아닌 파일시스템 일부를 숨기려 하면서 더 나빠짐
      왜 그러는지는 이해함
      평균적인 Linux 설치의 디렉터리 구조는 기술적인 사람에게도 헷갈리는 미로이고, 주요 배포판이 겨냥하는 일반 사용자에게는 더 심함
      하지만 결국 원인이 아니라 증상을 다루는 방식이고, 더 많은 Linux 배포판이 Gobo처럼 파일시스템 구조의 현대화를 진지하게 고민해야 한다고 봄
      직접 시도해보고 싶은 마음도 있음
      목표는 합리적으로 자기 설명적이고, 초보자를 위험한 영역에서 멀리 안내하며, 파일 관리자가 거의 아무것도 숨기지 않아도 문제없는 구조를 만드는 것
    • macOS의 번들은 좋은 아이디어였고 지금도 좋지만, 앱들은 여전히 보통 ~/Library 같은 이상한 위치에 뭔가를 흩뿌림
      Minecraft 런처처럼 번들 안에 모든 것과 월드, 저장 파일까지 들어 있는 경우가 재미있어짐
    • 원칙적으로는 애플리케이션이 하나의 “파일”처럼 보이는 점에 동의하지만, 실제로는 많은 앱이 ~/Library와 /Library에 여러 파일을 넣음
      macOS에서도 일부 앱을 지우려면 여러 단계의 수동 삭제 안내를 따라야 하는 일이 드물지 않음
      특히 로그인 항목을 추가하는 앱이면 더 중요함
      Windows의 프로그램 추가/제거는 적어도 제거를 실행하는 중앙 지점을 제공하고, 대부분의 앱이 그 방식을 제대로 따름
    • Fedora에서는 rpm 데이터베이스 조회가 간단함
      dpkg로도 같은 일을 할 수 없는 건가?
    • Mac에서 바로 그 점이 정말 싫음

  • 첫 번째 디렉터리 이름을 대문자로 시작하는 건 별로임
    경로를 탐색할 때 추가 작업처럼 느껴지고, 매번 문자나 숫자와 함께 Shift를 눌러야 하는 건 일상적인 명령줄 사용에서 꽤 귀찮음

    • 위에 링크된 글에 따르면, GoboLinux 기본 셸처럼 제대로 설정된 셸에서는 /Programs 입력이 /usr와 정확히 같은 키 입력 수라고 함
      슬래시, 소문자 p, Tab이면 됨
    • PowerShell이나 cmd.exe에서 탐색할 때는 왜 그게 전혀 거슬리지 않느냐면, 셸이 도와주기 때문임
      사용성을 희생해서 PDP-11의 귀중한 틱과 메모리를 아끼라고 강요하지 않음
      “대소문자 구분 최고!”라는 팬들이 그게 원래 시스템의 제약에서 나온 결과일 뿐이라는 걸 놓치는 게 늘 우스움
      기능이 아님
      게다가 이 부분은 명시적으로 다뤄져 있음
      set completion-ignore-case On만 해도 삶이 크게 나아짐
      GoboLinux를 쓰지 않더라도 대문자로 시작하는 파일명마다 Shift를 한 번 덜 누르게 되기 때문임
      아니면 1977년처럼 계속 살아도 됨
      본인 VT100, 본인 규칙임
      나중에 “왜 일반 탐색에 bash를 그대로 쓰지 않고 다른 셸을 설치하느냐”는 말을 봤는데, 자기 셸도 제대로 모르는 셈임
    • 한눈에 디렉터리인지 일반 파일인지 구분해 주는 관례로는 마음에 듦
      또 어떤 셸이든 대소문자 무시 자동완성을 제공할 수 있고, Fish는 기본으로 해줌
    • 대문자는 FSH/레거시 디렉터리와 충돌을 피하려는 목적임
    • 별로임
      Windows 느낌이 남

  • 이 프로젝트는 우리의 인지 부하를 꽤 줄일 잠재력이 있음
    성공했으면 좋겠음
    수정: 이제 보니 20년 된 프로젝트였음

  • 너무 합리적이라 눈물이 날 정도임
    라이브러리의 여러 사본을 중복 제거하는 일은 정말 필요하다면 파일시스템이 처리하면 됨
    결국 파일 수준의 중복이므로 그 수준에서 해결해야 함

  • 아주 나쁜 폐쇄 소스 애플리케이션들은 사용자 시스템에 너무 많은 걸 기대함
    Steam 클라이언트가 그런 예인데, sh 스크립트가 아니라 bash 스크립트를 제공하고, Linux 마운트 사용자 공간 컨테이너 요구사항 때문에 Debian/Ubuntu식 파일 배치를 강하게 전제하며, 여러 명령의 GNU 전용 특이 옵션까지 요구함
    32비트 라이브러리도 많음
    그래도 ABI는 아직 통제하고 있는 듯하고, 아마 binutils gas의 .symver 지시어를 쓰는 것 같음
    적어도 현재의 혼란은 Steam이 우리 목구멍으로 밀어 넣는 중이고, 게임을 하지 않는 배포판이 아니라면 피하기 어려움

    • 대부분의 사람은 게임을 하지 않고, Linux 사용자 중에서도 많은 사람은 애초에 독점 앱을 쓰지 않을 것 같음
      게이머 집단 안에서도 상당수는 전용 게임용 PC를 따로 갖고 있을 가능성이 큼

  • 나보다 훨씬 똑똑한 사람이 이것이 snap/Flatpak이나 NixOS 같은 배포판보다 왜 더 나은지, 혹은 더 나은 게 맞는지 설명해주면 좋겠음
    깊이 이해하지 못한 상태에서 겉으로 보기에는 이 방식이 가장 단순해 보임
    물론 내 지식 부족을 전제로 한 말임

    • 각 앱을 자기 폴더에 넣는 것만 말하는 거라면, 그것만으로는 격리에 충분하지 않고 얼마나 밀어붙이느냐에 따라 엄청나게 낭비적일 수 있음
      Flatpak과 NixOS가 더 복잡한 데는 그럴 만한 이유가 있음
      예를 들어 디스크에서 정확히 같은 버전의 의존성을 중복 저장하지 않음
    • snap과 Flatpak은 배포에 더 초점을 두고 있고 “샌드박스”되어 있음
      따옴표를 붙인 건 보안 이슈가 있기 때문임
      NixOS는 기존 프로그램과의 호환성을 깨뜨리는 반면 Gobo는 그렇지 않음
      하지만 NixOS의 패키지 저장소는 Gobo보다 압도적으로 잘 관리되고, Gobo 쪽은 불완전하고 몇 년씩 뒤처져 있음
      그래도 여기서 언급된 것들은 모두 Android가 앱을 저장하는 방식보다 뒤처져 있음
      Android에서는 각 애플리케이션을 배포하기 쉬운 단일 파일로 배포할 수 있고, 제대로 샌드박스되며, 자기 디렉터리를 가짐
      또 다른 방식들이 빠뜨린 점으로, 각 앱은 자기 상태를 저장할 앱 디렉터리 아래의 하위 디렉터리를 갖고, 사용자별로도 구분됨

  • GoboLinux 개발자들은 사람이 이해할 수 있는 파일시스템 배치를 정말 “지능적으로” 만들어냈음
    지금 쓰는 구식 UNIX 관례는 더 이상 8.3 이름 제한, 저장공간 부족, 1GB 초과 파일 문제 같은 제약이 없는 시대에는 꽤 난해하다고 봄
    예전에 버전 관리 소프트웨어를 호스팅하던 서버에서 GoboLinux 012~015를 몇 년 돌렸고, 대체로 아주 좋았음
    걸림돌은 필요한 패키지가 없으면 레시피를 만들어야 한다는 점이었음
    GoboLinux 레시피 작성 언어 자체는 이해하기 쉬웠지만, 패키지 하나가 라이브러리 열몇 개나 몇십 개에 의존하는 경우가 많아서 그걸 추적하고, 버전을 맞추고, 라이브러리와 패키지 URL을 찾고, 다시 레시피를 만드는 데 시간을 많이 썼음
    결국 Debian으로 옮겼지만 아직도 설정 파일이 /etc에 있고 바이너리가 /usr/bin이나 /usr/local/bin에 들어가는 걸 보면 움찔함
    systemd는 성가시고 문어 같다고 보는 쪽임
    관련 .service 파일을 찾으려고 find를 쓰는 일이 흔하고, 한곳에 있다고 믿을 수 없으며, 명령줄도 직관적이지 않음
    반대로 Gobo는 서비스를 관리하는 스크립트 묶음이 아주 단순했고 다루기 쉬웠음
    그래도 필요한 것을 apt get하거나 dpkg -i로 바로 설치할 수 있는 편의성이 GoboLinux의 훨씬 더 합리적인 지능적 설계를 이김
    요즘은 지원되는 Linux 배포판 수가 예전의 무수한 선택지에서 줄어, 거의 항상 Debian이나 Ubuntu가 기본으로 포함되므로 저장소 밖이라도 패키지나 프로그램을 설치하지 못할 가능성이 낮음
    macOS도 확실히 GoboLinux와 비슷한 방식을 어느 정도 쓰고, 그래서 최근의 꽤 사용자 적대적인 버전들 이전에는 명령줄에서 macOS를 다루기가 꽤 쉬웠음
    예를 들어 USB 드라이브는 /Volumes에 있고, 프로그램 설정 파일은 ~/Library 아래에 있음

    • 참고로 서비스가 로드되어 있다면 systemctl status foo만 실행해도 두 번째 줄부터 어떤 파일들이 관여하는지 정확히 알려줌
      예를 들면 systemctl status getty@tty1.service 출력에 Loaded: loaded (/lib/systemd/system/getty@.service; enabled; preset: enabled)처럼 나오므로 /lib/systemd/system/getty@.service를 바로 알 수 있음
답변달기