GoboLinux, bản phân phối Linux thử nghiệm dùng hệ thống tệp làm cơ sở dữ liệu gói

 (gobolinux.org)
3 điểm bởi GN⁺ 2024-03-01 | 1 bình luận | Chia sẻ qua WhatsApp
  • Đây là một bản phân phối thử nghiệm, thay đổi mạnh các quy ước thư mục của những bản phân phối Linux hiện có để giúp người dùng hiểu cấu trúc hệ thống theo các thư mục riêng cho từng chương trình
  • Thay vì dùng cơ sở dữ liệu gói riêng, hệ thống sử dụng chính hệ thống tệp làm cơ sở dữ liệu, và các chương trình được đặt theo từng phiên bản ở các đường dẫn như /Programs/Nano/8.3
  • Bản phát hành mới nhất 017.01 là bản cập nhật sửa lỗi xuất hiện sau khoảng 5 năm kể từ bản ISO trước đó, xử lý một số vấn đề quan trọng trong thời gian qua
  • Nhà sáng lập Hisham Muhammad rút lui sau 25 năm vận hành, và dự án được tiếp quản bởi người dùng GitHub @fyrak1s
  • Có thể chạy trực tiếp dưới dạng môi trường Live hoặc cài lên ổ cứng để thử nghiệm thực tế cấu trúc hệ thống tệp khác với các bản phân phối thông thường

Cách tổ chức gói bằng hệ thống tệp

  • GoboLinux là một bản phân phối Linux thử nghiệm tái định nghĩa toàn bộ hệ phân cấp hệ thống tệp
  • Điểm cốt lõi là không dùng cơ sở dữ liệu gói riêng mà sử dụng hệ thống tệp làm cơ sở dữ liệu
    • Mỗi chương trình nằm trong thư mục riêng của nó
    • Ví dụ: /Programs/Nano/8.3, /Programs/GCC/14.2.0
  • Vì cấu trúc khác với các bản phân phối Linux thông thường, người dùng lần đầu tiếp cận nên đọc tài liệu trước

Bản phát hành 017.01 và thay đổi đơn vị vận hành

  • Phiên bản hiện tại là 017.01
    • Đây là môi trường Live có thể chạy từ USB và DVD
    • Cũng có thể cài đặt lên ổ cứng
    • Có thể tải ISO tại Downloads
  • v017.01 là bản cập nhật sửa lỗi được phát hành sau khoảng 5 năm gián đoạn
    • Xử lý một số vấn đề quan trọng xuất hiện sau bản phát hành ISO trước đó
    • Có thể xem chi tiết thay đổi trong release notes
  • Cách vận hành dự án cũng đã thay đổi
    • Hisham Muhammad, nhà sáng lập và người dẫn dắt GoboLinux suốt 25 năm, đã chính thức rút lui
    • Dự án tiếp tục được duy trì dưới sự vận hành của @fyrak1s
    • Lucas Correia Villa Real, biệt danh paranoidd, đã cùng Hisham duy trì GoboLinux đến tháng 6 năm 2021
  • Các đầu mối cộng đồng được chia thành chat, forum và wiki

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-03-01
Ý kiến trên Hacker News

  • Nếu bạn có cảm giác phản đối ngay lập tức rất mạnh với thiết kế của GoboLinux, thì tài liệu 20 năm tuổi “I am not clueless”¹ có khá nhiều bối cảnh và lý do giải thích
    Tôi vẫn chưa hoàn toàn hết cảm giác phản đối, nhưng nó không còn mạnh như trước ;)
    ¹ https://gobolinux.org/doc/articles/clueless.html

    • Cảm giác của bài viết khá giống tài liệu của HTMX hay Tailwind
      Có thể tóm gọn là: “Chúng tôi biết mình khác biệt. Nó rất đơn giản. Có thể bạn chưa quen, nhưng dễ hiểu và dễ xử lý. Bạn không bắt buộc phải dùng. Chúng tôi thích nó và thấy hài lòng”
    • Ở phần make all programs relocatable của bài viết được liên kết, họ nói phải viết lại mọi ứng dụng để dùng libprefix, nên tôi thắc mắc libprefix ở đây có nghĩa là gì
      Tìm trên web không ra kết quả nào thật sự hữu ích
    • Tôi tự hỏi liệu phần lớn phản ứng bác bỏ theo bản năng có đến từ thiết kế bề ngoài hơn là yếu tố chức năng không
      Ví dụ, phần lớn phản ứng ban đầu đến từ cách viết hoa, vì chữ P viết hoa trong Programs gợi nhớ đến Program Files của Windows và tạo ra cảm giác phản cảm về mặt cảm xúc
      Nếu phải gõ LibX11 thay vì libx11 thì có lẽ tôi cũng sẽ hơi khó chịu
      Hệ thống tệp Linux thường phân biệt chữ hoa chữ thường, nhưng tên gói chắc sẽ tránh trùng lặp chỉ khác nhau ở hoa/thường, và một bản phân phối hướng đến phân cấp thân thiện với người dùng cũng khó có khả năng đặt ở thư mục gốc những thư mục chỉ khác nhau ở hoa/thường
      Dù vậy, nếu ví dụ là /packages/libx11/1.6.9, /packages/gcc/9.2.0 thì có lẽ phản ứng ban đầu đã nhẹ hơn nhiều, mà với những cái tên đó thì lợi ích cũng chẳng giảm đi chút nào

  • Thật đáng tiếc khi ý tưởng của GoboLinux không thể đứng vững trong cộng đồng Linux dòng chính
    Cấu trúc hệ thống tệp của Linux đúng là hoàn toàn lộn xộn

    • Tôi đồng ý, nhưng cũng thấy vui khi Nix, Guix, và Spack—thứ tôi làm việc với nhiều nhất—về cơ bản đang đi theo cùng một hướng và ngày càng có sức ảnh hưởng
      Làm cho nó hoạt động đúng chưa bao giờ là chuyện đơn giản, còn làm cho nó hiệu quả thì lại càng khó hơn
      Chỉ trong vài năm gần đây tôi mới cảm thấy mô hình này cuối cùng đã tiến gần đến mức thực sự có thể duy trì được cho việc phân phối phần mềm nói chung
    • Nix đang ngày càng phổ biến
      Mô hình của GoboLinux đòi hỏi phải quản lý thủ công các thư mục phiên bản như /Programs/Xorg/7.0, còn Nix thì dùng hàm băm của recipe build để xác định đường dẫn cài đặt của gói, nên loại bỏ được vấn đề đó
    • Hiện tại tôi thấy chỉ có /home và /tmp là còn có ý nghĩa một cách nhất quán
      Còn lại thì gần như là một đống hổ lốn muốn nhét gì vào đâu cũng được
    • Những ý tưởng đó chắc chắn đã truyền cảm hứng cho tôi
      GoboLinux là dự án đầu tiên cho tôi thấy rằng trên Linux bạn thực sự có thể làm theo đúng ý mình
    • /opt và /srv, và tùy gu thì cả /usr/local/opt, cũng mang lại khá nhiều lợi ích kiểu GoboLinux trong việc quản lý từng thành phần riêng lẻ
      Từ góc nhìn của bản phân phối, mọi thứ đều có lý theo cách riêng của nó
      Nếu gõ dpkg -S this-file thì có thể nhanh chóng biết vì sao một tệp nằm trong /usr, và bản phân phối đóng vai trò vẽ ra bức tranh tổng thể
      Tôi muốn biết bạn thấy phần nào là lộn xộn nhất

  • Điều thú vị là họ ánh xạ các đường dẫn truyền thống sang đường dẫn tương ứng của GoboLinux để giữ tính tương thích với di sản Unix một cách trong suốt
    Không có phép màu đặc biệt nào cả, /bin là liên kết đến /System/Index/bin, còn /usr/bin và /usr/sbin cũng tương tự, nên mọi thư mục “binary” đều trỏ về cùng một chỗ
    Nhờ vậy, dù truy cập bằng đường dẫn chuẩn nào thì tệp vẫn hoạt động, nên có khi còn tương thích hơn các bản phân phối thông thường, nơi tệp thực nằm ở /usr/local/bin/foo nhưng script lại tham chiếu /usr/bin/foo và bị lỗi

  • Hỏi thật vì tôi không rõ lắm: macOS có hoạt động phần nào theo kiểu này không?
    Cách ứng dụng luôn trông như một “tệp” duy nhất có thể quản lý bằng kéo thả thực sự rất hay
    Mỗi khi cố tìm xem cái gì nằm ở đâu và được cài vào đâu trên Ubuntu, tôi lại có cảm giác mình như kẻ ngốc

    • Vấn đề khó tìm ra cái gì ở đâu và đi vào đâu trên Ubuntu còn tệ hơn vì trình quản lý tệp trên Linux thường cố che đi một phần hệ thống tệp không phải thư mục nhà hay ổ đĩa được mount
      Tôi hiểu vì sao họ làm vậy
      Cấu trúc thư mục của một bản cài Linux trung bình là một mê cung khó hiểu ngay cả với người có kỹ thuật, và còn tệ hơn với người dùng phổ thông mà các bản phân phối lớn đang nhắm tới
      Nhưng cuối cùng đó là cách xử lý triệu chứng chứ không phải nguyên nhân, và tôi nghĩ nhiều bản phân phối Linux hơn nên nghiêm túc cân nhắc hiện đại hóa cấu trúc hệ thống tệp như Gobo
      Tôi thậm chí cũng muốn tự thử làm
      Mục tiêu là tạo ra một cấu trúc hợp lý, có tính tự mô tả, hướng người mới tránh xa các vùng nguy hiểm, và khiến trình quản lý tệp gần như không cần phải ẩn gì cả mà vẫn ổn
    • Bundle của macOS là một ý tưởng hay trước đây và đến nay vẫn vậy, nhưng các ứng dụng thường vẫn rải một đống thứ vào những chỗ kỳ quặc như ~/Library
      Trường hợp như launcher của Minecraft, nơi mọi thứ kể cả world và file lưu đều nằm trong bundle, thì lại trở nên khá thú vị
    • Về nguyên tắc, tôi đồng ý với ý tưởng ứng dụng trông như một “tệp” duy nhất, nhưng trên thực tế nhiều ứng dụng vẫn đặt nhiều tệp trong ~/Library và /Library
      Ngay cả trên macOS, việc xóa một số ứng dụng cũng không hiếm khi phải làm theo hướng dẫn xóa thủ công gồm nhiều bước
      Điều này càng quan trọng hơn với các ứng dụng thêm mục đăng nhập
      Tính năng thêm/xóa chương trình của Windows ít nhất cũng cung cấp một điểm trung tâm để chạy gỡ cài đặt, và phần lớn ứng dụng đều tuân theo cách đó một cách đàng hoàng
    • Trên Fedora thì việc tra cứu cơ sở dữ liệu rpm khá đơn giản
      Chẳng lẽ với dpkg lại không làm được việc tương tự sao?
    • Đó chính là điều tôi thực sự ghét ở Mac

  • Việc bắt đầu tên thư mục bằng chữ hoa không hấp dẫn lắm
    Khi duyệt đường dẫn, cảm giác như có thêm việc phải làm, và việc lúc nào cũng phải nhấn Shift cùng với chữ cái hay số khá phiền trong sử dụng dòng lệnh hằng ngày

    • Theo bài viết được liên kết ở trên, trong một shell được cấu hình đúng như shell mặc định của GoboLinux, việc gõ /Programs có số lần bấm phím chính xác bằng /usr
      Chỉ cần dấu gạch chéo, chữ p thường và Tab
    • Khi duyệt trong PowerShell hay cmd.exe, lý do điều đó hoàn toàn không gây khó chịu là vì shell hỗ trợ bạn
      Nó không bắt bạn hy sinh tính tiện dụng để tiết kiệm những nhịp clock và bộ nhớ quý giá của PDP-11
      Việc các fan “phân biệt hoa thường là nhất!” luôn bỏ qua rằng đó chỉ là kết quả của các ràng buộc của hệ thống ban đầu thì lúc nào cũng buồn cười
      Đó không phải tính năng
      Hơn nữa, phần này còn được xử lý rõ ràng
      Chỉ cần set completion-ignore-case On là cuộc sống đã dễ thở hơn nhiều
      Vì ngay cả khi không dùng GoboLinux, bạn cũng bớt phải nhấn Shift một lần cho mỗi tên tệp bắt đầu bằng chữ hoa
      Hoặc cứ tiếp tục sống như năm 1977 cũng được
      VT100 của bạn, luật của bạn
      Sau đó tôi còn thấy người ta hỏi “tại sao lại cài shell khác thay vì cứ dùng bash nguyên bản để duyệt thông thường”, đúng là kiểu người còn chẳng hiểu shell của chính mình
    • Tôi thích nó như một quy ước giúp nhận ra ngay đâu là thư mục và đâu là tệp thường
      Ngoài ra, bất kỳ shell nào cũng có thể cung cấp tự động hoàn tất không phân biệt hoa thường, và Fish làm điều đó theo mặc định
    • Chữ hoa nhằm tránh xung đột với các thư mục FSH/legacy
    • Không thích lắm
      Nó cho cảm giác kiểu Windows

  • Dự án này có tiềm năng giảm đáng kể gánh nặng nhận thức của chúng ta
    Mong là nó thành công
    Sửa: giờ tôi mới nhận ra đây là dự án đã 20 năm tuổi

  • Hợp lý đến mức muốn rơi nước mắt
    Việc khử trùng lặp nhiều bản sao của thư viện thật ra nên để hệ thống tệp xử lý nếu thực sự cần
    Suy cho cùng đó là trùng lặp ở cấp độ tệp, nên nên được giải quyết ở chính cấp độ đó

  • Các ứng dụng mã nguồn đóng cực tệ kỳ vọng quá nhiều vào hệ thống của người dùng
    Ứng dụng Steam là một ví dụ: nó cung cấp script bash chứ không phải script sh, mặc định rất mạnh vào cách bố trí tệp kiểu Debian/Ubuntu do các yêu cầu về container không gian người dùng gắn kết trên Linux, và còn đòi các tùy chọn kỳ quặc chỉ có ở GNU của nhiều lệnh
    Nó cũng có nhiều thư viện 32-bit
    Dù vậy có vẻ nó vẫn đang kiểm soát ABI, có lẽ bằng cách dùng chỉ thị .symver của binutils gas
    Ít nhất thì mớ hỗn loạn hiện tại đang do Steam nhét xuống cổ họng chúng ta, và nếu không phải là một bản phân phối không chơi game thì rất khó tránh

    • Phần lớn mọi người không chơi game, và ngay cả trong số người dùng Linux thì có lẽ nhiều người vốn dĩ cũng không dùng ứng dụng độc quyền
      Ngay trong cộng đồng game thủ, cũng khá nhiều người có khả năng có một PC chơi game chuyên dụng riêng

  • Tôi muốn có ai đó thông minh hơn tôi rất nhiều giải thích vì sao cách này tốt hơn, hoặc liệu có thật sự tốt hơn, so với các bản phân phối như snap/Flatpak hay NixOS
    Khi chưa hiểu sâu, nhìn bề ngoài thì cách này có vẻ đơn giản nhất
    Tất nhiên, đó là nhận xét với tiền đề là kiến thức của tôi còn hạn chế

    • Nếu chỉ nói đến chuyện đặt mỗi ứng dụng vào thư mục riêng của nó, thì riêng như vậy vẫn chưa đủ để cô lập, và tùy mức độ đẩy tới đâu mà nó có thể cực kỳ lãng phí
      Flatpak và NixOS phức tạp hơn là có lý do
      Ví dụ, chúng không lưu trùng lặp chính xác cùng một phiên bản phụ thuộc trên đĩa
    • snap và Flatpak tập trung hơn vào phân phối và được “sandbox”
      Tôi đặt trong ngoặc kép vì có các vấn đề bảo mật
      NixOS thì phá vỡ khả năng tương thích với các chương trình hiện có, còn Gobo thì không
      Nhưng kho gói của NixOS được quản lý tốt hơn Gobo áp đảo, còn phía Gobo thì thiếu hoàn chỉnh và chậm vài năm
      Dù vậy, tất cả những thứ được nhắc ở đây vẫn kém hơn cách Android lưu trữ ứng dụng
      Trên Android, mỗi ứng dụng có thể được phân phối dưới dạng một tệp đơn dễ triển khai, được sandbox đúng nghĩa và có thư mục riêng của nó
      Ngoài ra, điều mà các cách khác bỏ sót là mỗi ứng dụng có một thư mục con bên dưới thư mục ứng dụng của nó để lưu trạng thái riêng, và còn được tách biệt theo từng người dùng

  • Các nhà phát triển GoboLinux đã thực sự tạo ra một cách bố trí hệ thống tệp mà con người có thể hiểu được theo kiểu rất “thông minh”
    Tôi thấy các quy ước UNIX kiểu cũ hiện nay khá khó hiểu trong một thời đại không còn những ràng buộc như giới hạn tên 8.3, thiếu dung lượng lưu trữ, hay vấn đề tệp vượt quá 1GB
    Trước đây tôi đã chạy GoboLinux 012~015 trong vài năm trên một máy chủ dùng để lưu trữ phần mềm quản lý phiên bản, và nhìn chung là rất tốt
    Trở ngại là nếu không có gói cần thiết thì phải tự tạo recipe
    Bản thân ngôn ngữ viết recipe của GoboLinux khá dễ hiểu, nhưng một gói thường phụ thuộc vào cả chục hoặc vài chục thư viện, nên tôi đã tốn rất nhiều thời gian để lần theo chúng, khớp phiên bản, tìm URL của thư viện và gói, rồi lại tạo recipe
    Cuối cùng tôi chuyển sang Debian, nhưng đến giờ mỗi khi thấy các tệp cấu hình vẫn nằm trong /etc và các tệp nhị phân nằm trong /usr/bin hoặc /usr/local/bin thì tôi vẫn hơi rùng mình
    Tôi thuộc phe cho rằng systemd vừa phiền phức vừa như một con bạch tuộc
    Việc dùng find để tìm các tệp .service liên quan xảy ra khá thường xuyên, không thể tin rằng chúng nằm ở một chỗ duy nhất, và giao diện dòng lệnh cũng không trực quan
    Ngược lại, Gobo có một bộ script quản lý dịch vụ rất đơn giản và dễ xử lý
    Dù vậy, sự tiện lợi của việc có thể cài ngay thứ mình cần bằng apt get hoặc dpkg -i đã thắng thiết kế thông minh hợp lý hơn nhiều của GoboLinux
    Ngày nay số lượng bản phân phối Linux được hỗ trợ đã giảm từ vô số lựa chọn ngày trước, nên Debian hoặc Ubuntu gần như luôn được mặc định đưa vào, vì thế khả năng không cài được gói hay chương trình ngay cả từ bên ngoài kho phần mềm cũng là rất thấp
    macOS rõ ràng cũng dùng phần nào cách tiếp cận khá giống GoboLinux, và vì vậy trước những phiên bản gần đây vốn khá thù địch với người dùng, việc xử lý macOS trên dòng lệnh từng khá dễ dàng
    Ví dụ, ổ USB nằm trong /Volumes, còn các tệp cấu hình chương trình nằm dưới ~/Library

    • Nhân tiện, nếu dịch vụ đã được nạp thì chỉ cần chạy systemctl status foo là từ dòng thứ hai sẽ cho biết chính xác những tệp nào có liên quan
      Ví dụ, đầu ra của systemctl status getty@tty1.service sẽ hiện Loaded: loaded (/lib/systemd/system/getty@.service; enabled; preset: enabled), nên có thể biết ngay đó là /lib/systemd/system/getty@.service