Giới thiệu về hệ thống Linux bất biến

 (dataswamp.org)
3 điểm bởi GN⁺ 2023-09-19 | 1 bình luận | Chia sẻ qua WhatsApp
  • Các bản phân phối Linux bất biến chuẩn bị nâng cấp bên ngoài hệ thống đang chạy và áp dụng ở lần khởi động tiếp theo, nhờ đó cung cấp cách vận hành có thể hoàn tác nếu thất bại
  • Trái với tên gọi “bất biến”, nhiều khu vực của hệ thống vẫn có thể thay đổi, và điểm chung thực sự gần với cập nhật giao dịch cùng khả năng rollback hơn
  • NixOS·Guix đặt cấu hình khai báo và kho lưu trữ chỉ đọc làm trung tâm, còn họ OSTree·MicroOS·Vanilla OS lần lượt tiếp cận bằng /usr, snapshot btrfs, và phân vùng root A/B
  • Ưu điểm là giữ hệ thống ổn định ngay cả khi đang thay đổi gói và có thể hoàn tác sự cố, nhưng vẫn còn các hạn chế như cần khởi động lại, xung đột với công cụ quản lý cấu hình, và khó theo dõi thay đổi
  • Điều mới mẻ không nằm ở bản thân snapshot mà ở việc áp dụng thay đổi vào môi trường không phải live, rồi tích hợp với bootloader và công cụ người dùng để dễ sử dụng hơn

Phạm vi thực sự của cái tên “bất biến”

  • Tính bất biến vốn có nghĩa là đối tượng không thay đổi, nhưng khi áp dụng vào hệ điều hành thì định nghĩa lập tức trở nên mơ hồ
  • Linux LIVE-CD trông có vẻ bất biến vì mỗi lần đều khởi động với cùng một bộ chương trình và đĩa là chỉ đọc, nhưng trong lúc chạy vẫn có thể tạo tệp và thư mục hoặc cài gói
  • Hiện nay, để thường được gọi là bản phân phối Linux bất biến thì nhìn chung cần ba điều kiện
    • Không thực hiện nâng cấp hệ thống trực tiếp trên hệ thống live
    • Áp dụng thay đổi gói ở lần khởi động tiếp theo
    • Có thể rollback về trạng thái trước đó
  • Mỗi cách triển khai có thể có thêm tính năng riêng, nhưng ba điều này là gần với điều kiện tối thiểu của các bản phân phối “bất biến” hiện nay

Khác biệt theo từng cách triển khai

  • NixOS / Guix

    • NixOS và Guix dựa trên cùng một dòng triển khai; Nix xuất hiện lần đầu vào năm 2003, còn trình quản lý gói Guix được fork từ Nix vào đầu những năm 2010 với mục tiêu phần mềm tự do 100%
    • Hai hệ thống này rất khác so với hệ Unix truyền thống và lấy tính bất biến làm nguyên lý cốt lõi
    • Mọi gói và tệp đã build được lưu dưới dạng mục riêng biệt trong một thư mục chỉ đọc đặc biệt mà chỉ trình quản lý gói mới có thể sử dụng
    • Bản thân hệ điều hành là đầu ra của trình quản lý gói, và người dùng mô tả trạng thái hệ thống mong muốn bằng cấu hình khai báo
    • Cấu hình bao gồm người dùng, shell, gói cài đặt, dịch vụ đang chạy và thiết lập của chúng, các phân vùng cần mount và tùy chọn liên quan
    • Mô-đun cung cấp giá trị mặc định nên khi tạo người dùng không cần tự chỉ định toàn bộ UID, GID, shell, thư mục home
    • Các tệp như /etc/fstab hay /bin/sh cũng là chỉ đọc và muốn thay đổi thì phải thông qua trình quản lý gói
    • Việc chuyển cấu hình gần giống như đổi symbolic link nên có thể thực hiện ngay, và có thể chọn cấu hình cũ khi khởi động để rollback
    • Ngoài thư mục kho lưu trữ đặc biệt, các khu vực như /home, /etc, /var vẫn có thể thay đổi; có thể thay symbolic link hệ thống sang mục khác nhưng không thể sửa nguồn gốc ban đầu
    • NixOS được đánh giá là một triển khai tốt, nhưng vì quá khác với các hệ thống hiện có nên dù có nhiều lợi thế, mức độ chấp nhận vẫn thấp

  • Endless OS

    • Endless OS là một trong những OS bất biến đầu tiên được phát hành cho người dùng phổ thông, hướng tới một hệ thống bền bỉ có thể dùng cả ở những quốc gia có hạ tầng Internet hoặc điện lưới yếu
    • Dựa trên Debian nhưng triển khai tính bất biến bằng OSTree
    • OSTree quản lý image hệ thống lõi, chồng thêm các lớp như gói lên trên, và có thể chuẩn bị image hệ thống mới cho lần khởi động tiếp theo
    • Thay đổi gói được áp dụng vào phiên bản hệ thống mới sẽ dùng ở lần khởi động sau, và khi boot có thể quay lại phiên bản trước
    • Các phân vùng nhìn chung có thể ghi, nhưng /usr — vùng gói do OSTree quản lý — được mount ở chế độ chỉ đọc
    • /etc không có rollback
    • Ứng dụng cho người dùng được cài bằng Flatpak để giảm nhu cầu phải khởi động lại mỗi khi cài gói mới
    • GNOME desktop đã được chỉnh sửa để trông giống menu trên smartphone, hướng tới kiểu giao diện thân thiện với người không rành kỹ thuật
    • Việc cài công cụ DevOps không thật sự thực dụng, nhưng không phải là bất khả thi

  • Fedora Silverblue

    • Fedora Silverblue nằm trong dòng kế thừa của Project Atomic, dự án từng muốn biến Fedora / CentOS / RHEL thành bất biến
    • Hệ thống dùng rpm-OSTree để áp dụng thay đổi gói RPM lên trên OSTree
    • Hệ thống gồm một image lõi duy nhất theo từng bản phát hành và các lớp gói bổ sung được chồng lên trên
    • Có thể liệt kê các lớp gói đã cài, và khi gỡ gói thì toàn bộ stack sẽ được tạo lại để không còn sót lại tàn dư sau khi xóa
    • Quá trình tái tạo này rất chậm
    • Ngay cả khi cài gói, nó cũng không được áp dụng vào hệ thống đang boot hiện tại nên về cơ bản vẫn cần khởi động lại; khi boot có thể chọn phiên bản hệ thống trước đó
    • rpm-OSTree cung cấp tính năng tạm thời hợp nhất thay đổi của lần khởi động kế tiếp vào hệ thống live bằng lớp phủ tmpfs
    • Chính sách mount là chỉ đọc ngoại trừ /etc, /root, /var; thư mục home mặc định nằm ở /var/home nên có thể trái với kỳ vọng
    • /etc không do rpm-OSTree quản lý nên không được rollback
    • /usr/local là symbolic link trỏ tới một thư mục trong /var, vì vậy khá dễ chèn thay đổi của người dùng mà không cần tệp RPM
    • Vì cài gói chậm và cần khởi động lại nên người dùng được khuyến nghị dùng Flatpak hoặc toolbox
    • toolbox tạo container Fedora không cần quyền root, cho phép dùng thư viện phát triển hoặc công cụ trong terminal

  • OpenSUSE MicroOS / Aeon

    • OpenSUSE MicroOS là biến thể bất biến của OpenSUSE Tumbleweed dạng rolling-release và dùng cách triển khai riêng
    • Toàn bộ hệ thống, trừ một số thư mục như /home, /var, nằm trên snapshot btrfs
    • Khi cần thay đổi hệ thống, snapshot hiện tại được sao chép thành snapshot mới, thay đổi được áp dụng vào snapshot mới đó và dùng cho lần khởi động tiếp theo
    • Khác với hệ thống dựa trên OSTree, /etc cũng là một phần của snapshot nên có thể rollback
    • Có thể dùng shell bên trong snapshot mới để thay đổi bất kỳ tệp nào trong hệ thống tệp, hữu ích cho các việc như chèn tệp để xử lý sự cố driver
    • Tuy nhiên, những thay đổi kiểu này không được theo dõi nên khó đảm bảo hệ thống còn ở trạng thái “thuần khiết”
    • Thay đổi được thực hiện bằng lệnh transactional-update; có thể thêm hoặc gỡ gói, hoặc mở shell trong snapshot mới để sửa theo ý muốn
    • /etc nằm trong snapshot nhưng luôn có thể đọc, nên nếu sửa /etc khi hệ thống đang live rồi tạo snapshot mới thì thay đổi đó sẽ được kế thừa ngay
    • Cách tiếp cận mặc định là lên kế hoạch khởi động lại hằng ngày sau khi cập nhật; vì là rolling-release nên mỗi ngày đều có cập nhật và trước khi reboot thì chưa được hưởng lợi từ gói mới
    • Có thể tắt tự động khởi động lại
    • Tính năng áp dụng thay đổi lên hệ thống live như Silverblue hiện vẫn ở mức thử nghiệm và chưa thể dùng
    • Thay vào đó, hệ thống khuyến nghị dùng distrobox để chạy container không cần quyền root của nhiều bản phân phối khác nhau và cài công cụ người dùng trong đó

  • Vanilla OS

    • Vanilla OS là một hệ thống bất biến thế hệ mới dựa trên Ubuntu và sắp chuyển sang nền Debian
    • Tính bất biến được triển khai bằng ABroot
    • ABroot dùng phân vùng root A, phân vùng root B, và một phân vùng cho dữ liệu bền vững như /home hoặc /var
    • Luồng khởi động và thay đổi diễn ra như sau
      • Lần khởi động đầu tiên diễn ra từ A và A được mount ở chế độ chỉ đọc
      • Các thay đổi hệ thống như gói mới hoặc sửa tệp /etc được áp dụng vào B, đồng thời cũng có thể áp dụng live qua lớp phủ tmpfs
      • Sau khi khởi động lại, hệ thống boot từ B; nếu thành công thì ABroot quét khác biệt giữa A và B rồi áp dụng thay đổi của B sang A
      • Khi không có thay đổi mới, A và B luôn giống hệt nhau
    • Điểm yếu là chỉ có thể rollback cho tới trước khi boot vào phiên bản mới
    • Khi đã boot vào phiên bản mới, thay đổi cũng được áp dụng sang phân vùng đã boot trước đó nên không thể rollback nữa
    • Cách này chủ yếu hữu ích để hoàn tác nâng cấp thất bại hoặc các thay đổi được thử nghiệm theo kiểu live
    • Vanilla OS cung cấp trình quản lý gói apx
    • apx là công cụ do tác giả distrobox tạo ra, cho phép người dùng không phải root cài gói từ nhiều bản phân phối như Arch Linux, Fedora, Ubuntu, Nix rồi tích hợp như cài đặt cục bộ
    • Vanilla OS, ABroot và apx vẫn còn non trẻ và có nhiều chỗ thô ráp

  • Alpine Linux with LBU

    • Alpine Linux có thể tạo ra cấu hình gần với bất biến bằng lệnh lbu
    • Nó dùng trình cài đặt Alpine làm hệ thống boot cơ sở, rồi tạo tarball “cấu hình đã lưu” để tự động áp dụng khi khởi động
    • Mỗi lần boot, thư mục được bung lại và gói được cài lại; mọi thứ hoàn toàn có thể ghi trong bộ nhớ live
    • Hệ thống luôn bắt đầu từ trạng thái sạch rồi áp thay đổi lên trên, và có thể hoàn tác thay đổi để khởi động lại từ đầu
    • Tuy vậy, nó không đáp ứng hoàn toàn định nghĩa bất biến nêu trên vì thay đổi được áp lên hệ thống cơ sở
    • Do toàn bộ hệ thống nằm trong bộ nhớ và người dùng phải tự quản lý cái gì cần lưu hay khôi phục, nên cần hiểu biết khá cao và archive có thể trở nên lớn
    • Tài liệu cũng còn thiếu

Ưu điểm và ràng buộc trong vận hành

  • Ưu điểm

    • Khi có sự cố, có thể rollback thay đổi
    • Cập nhật giao dịch giúp hệ thống tiếp tục chạy đúng ngay cả trong lúc đang thay đổi gói

  • Nhược điểm

    • Việc tích hợp với các công cụ quản lý cấu hình như Ansible, Salt, Puppet là rất kém
    • Ngay cả khi các công cụ đó đã được cập nhật để hiểu cách áp dụng thay đổi gói, hầu hết vẫn sẽ vấp phải giới hạn nếu cố quản trị như một hệ thống thông thường
    • Việc phải khởi động lại sau khi thay đổi gây phiền toái, dù NixOS và Guix không cần reboot cho từng thay đổi
    • Các hệ thống dựa trên OSTree không linh hoạt
      • Ví dụ, trên một netbook cần thêm tệp trong thư mục ALSA để có âm thanh, bạn không thể thêm nó nếu không tạo một gói phân phối tệp đó
    • Rollback khá gần với rollback mù, khó biết chính xác mỗi phiên bản hệ thống đã có những thay đổi gì
    • Có thể khó cài toàn hệ thống các phần mềm chưa được đóng gói, hoặc các chương trình như Nix/Guix cần có thư mục trên root filesystem

Sự thật và hiểu lầm về hệ thống bất biến

  • Nói một cách nghiêm ngặt, tính bất biến gần như là một khái niệm sai, vì nhiều phần của hệ thống vẫn có thể thay đổi
  • Bất biến không có nghĩa là stateless
  • NixOS và Guix theo dõi toàn bộ hệ thống bằng trình quản lý gói ổn định và có thể dùng hệ thống quản lý phiên bản cho mã nguồn, nên được xem là các triển khai có triết lý đúng ngay từ đầu
  • Tính bất biến thường được gắn với lợi ích bảo mật, nhưng kẻ tấn công giành được quyền root vẫn có thể thao túng hệ thống live và cả phân vùng /boot
  • Không có gì ngăn họ cài backdoor cho lần khởi động tiếp theo
  • Tính bất biến đòi hỏi kỷ luật và bảo trì
    • Cần chú ý đến quản lý phiên bản
    • Phải cập nhật riêng các chương trình bổ sung như apx, distrobox, devbox ngoài hệ thống chính
    • NixOS và Guix tích hợp phần này tốt hơn

Điều thực sự mới mẻ

  • Hệ điều hành bất biến đang thu hút sự chú ý trong cộng đồng hệ thống mã nguồn mở, nhưng dưới cùng một từ ngữ lại đang trộn lẫn nhiều cách triển khai và trường hợp sử dụng khác nhau
  • Cái tên “bất biến” tạo ra một số kỳ vọng nhất định cho người dùng, nhưng trên thực tế nó gần hơn với cập nhật giao dịch cho hệ điều hành
  • Bản thân cập nhật giao dịch không phải khái niệm mới
    • Solaris và ZFS từng cho phép chọn snapshot hệ thống khi boot
    • FreeBSD dường như cũng đã triển khai tính năng tương tự từ khoảng 10 năm trước
    • Các bản phân phối Linux thông thường cũng có thể chọn snapshot khi boot nếu dùng snapshot btrfs
  • Điểm thực sự mới là áp dụng các thay đổi giao dịch vào môi trường không phải live, tích hợp điều đó vào bootloader, và cung cấp công cụ để người dùng dễ thao tác
  • Để đọc thêm, tác giả khuyến nghị bài của Colin Walters: “Immutable” → reprovisionable, anti-hysteresis

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-09-19
Các ý kiến trên Hacker News

  • Thật vui khi thấy Silverblue có trong danh sách, nhưng hơi tiếc vì thiếu Fedora CoreOS
    FCOS là một OS phù hợp để dùng trong production, đã tiến bộ nhiều sau thương vụ mua lại CoreOS, và có vẻ là một điểm cân bằng tốt: dễ học và dễ dùng hơn Nix nhưng vẫn giữ được tính bất biến
    CoreOS Layering mà nhóm phát triển FCOS thêm vào là một tính năng mạnh mẽ: bạn định nghĩa trạng thái hệ thống bằng Dockerfile, FCOS sẽ rebase về trạng thái đó, và việc cấu hình server chỉ cần reboot là xong
    Nếu dự án tiếp theo cần VM thì rất đáng thử. Tôi cũng đã làm Bupy, một công cụ CLI dựa trên Python giúp tạo file Butane cục bộ dễ dàng trên workstation Linux, và có cả ví dụ chạy Paperless NGX bằng CoreOS Layering
    https://github.com/quickvm/bupy
    https://github.com/quickvm/fcos-layer-paperless-ngx
    https://coreos.github.io/rpm-ostree/container/
    https://github.com/coreos/enhancements/blob/main/os/coreos-l...
    https://github.com/coreos/layering-examples

    • Cũng tò mò bạn nghĩ gì về Flatcar, một dự án khác thuộc họ CoreOS
      Điều khó nhất với tôi là phải dùng những dự án kiểu này như thế nào trong môi trường bare-metal. Tạo image VM thì rất hay, nhưng trên thực tế thường có nhiều trường hợp muốn cài lên ổ đĩa hiện có, hoặc cài với một ZFS pool nằm bên dưới
    • CoreOS Layering trông thật sự hữu ích. Hiện tôi đang dùng openSUSE MicroOS trên vài máy Raspberry Pi và một server x86_64; một trong những lý do tôi chọn MicroOS là vì việc cài trên Raspberry Pi khá đơn giản
      Tôi tò mò không biết cài CoreOS lên Raspberry Pi khó đến mức nào. Một số hướng dẫn cài đặt trên Internet trông khá phức tạp

  • Một trục khác luôn bị bỏ sót trong các bài giới thiệu hệ thống bất biến kiểu này là cách tiếp cận dựa trên image
    Tôi đang làm việc cùng những người giỏi hơn tôi rất nhiều tại https://universal-blue.org/, nơi chúng tôi build các OCI container image trên bản Fedora Silverblue cơ bản và nhiều edition desktop khác nhau
    Các image này có thể được boot bằng rpm-ostree, hay chính xác hơn là rebase sang, và đây là cách mở rộng hệ thống vững chắc hơn so với layering; bất kỳ ai cũng có thể dễ dàng kế thừa hoặc tận dụng cùng các thay đổi. Việc tự tạo image cũng rất dễ
    VanillaOS và SUSE dường như cũng làm điều tương tự, nhưng chúng tôi không phải là một dự án OS mà chỉ là downstream của Fedora. Hỗ trợ chính thức từ Fedora cũng đang được triển khai, và chỉ với phạm vi đã hoạt động hiện nay, theo kinh nghiệm của tôi đây là một trong những cách vững chắc và dễ dàng nhất cho các việc như cung cấp driver Nvidia

    • Hơi lạc đề một chút, nhưng khoảng năm 2009 tôi đã rất ấn tượng khi thấy một hypervisor lớn chạy các host Windows Remote Desktop. Tôi nghĩ có lẽ đó là Citrix
      VM boot từ image, và cả image lẫn đĩa chứa phần thay đổi đều nằm trong RAM. Profile người dùng nằm trên ổ cứng, nhưng một desktop host cho 25 người có thể boot đến trạng thái sẵn sàng nhận đăng nhập từ xa chỉ trong khoảng 4 giây
      Đó là hệ thống Windows ít gây đau đầu nhất khi vá lỗi
    • Tôi hơi bối rối vì tưởng Fedora Silverblue cũng dựa trên image
      Tôi từng nghĩ bản cài mặc định không dùng layering, và layering chỉ xuất hiện khi muốn cài thêm các gói RPM
    • Có vẻ UBlue định kỳ build lại image bằng GitHub Actions để phản ánh các bản cập nhật package. Tôi tò mò không biết ai trả chi phí
      Cũng tò mò image có được cung cấp từ GitHub không, GitHub có tính phí lưu lượng truyền ra ngoài không, và điều gì xảy ra nếu nhiều người dùng cùng muốn tải xuống cùng một image

  • Tôi quan tâm đến hệ thống được cấu hình sẵn hơn là hệ thống bất biến
    Ở đây NixOS và Home Manager nổi bật, nhưng cách cấu hình thật sự kinh khủng. Tôi muốn đưa toàn bộ cấu hình vào quản lý mã nguồn, biết rằng trạng thái hệ thống hiện tại giống với cấu hình đó, và mọi thay đổi khác sẽ bị xóa khi reboot. Sẽ tốt hơn nếu các thay đổi trước khi reboot được tô nổi bật
    Với kinh nghiệm hạn chế khi thử những thứ như Silverblue, tôi có thể cấu hình hệ thống cơ bản, nhưng khi bắt đầu thêm ứng dụng như Firefox thì lại dùng Flatpak, và tôi không rõ cách khai báo toàn bộ các cài đặt Flatpak mong muốn cùng với cấu hình của chúng
    Có lẽ vẫn có cách cài hàng loạt Flatpak rồi xử lý phần còn lại bằng dotfile
    https://universal-blue.org/tinker/mindset/#resist-the-urge-t...

  • Vấn đề gặp phải với Flatpak và cách tiếp cận bất biến nói chung là không thể sửa theo cách mà nhà phát triển không hỗ trợ
    Ví dụ, tôi đồng bộ lịch bằng decsync, nhưng theo tôi biết thì không thể thêm plugin decsync vào Evolution Flatpak
    Chừng nào các hệ thống bất biến như vậy chưa hỗ trợ như một tính năng hạng nhất việc xếp chồng filesystem overlay tùy chỉnh cho các trường hợp sử dụng mà nhà phát triển không thể hoặc không muốn hỗ trợ, mọi người vẫn sẽ tiếp tục dùng hệ thống khả biến

    • NixOS cung cấp đúng kiểu quyền kiểm soát này theo nhiều cách
      Một số package trong nixpkgs và phần lớn các module NixOS và Home Manager phơi ra nhiều tùy chọn để cấu hình plugin, package bổ sung, v.v.
      Nix cũng cung cấp overlay và override để thêm package tùy chỉnh hoặc biến thể của package hiện có, thậm chí có thể thay một phần của package. Nếu như vậy vẫn chưa đủ, bạn cũng có thể patch trực tiếp vào mã hoặc build từ fork của kho upstream
      Thực tế, đây là một trong những điểm tôi thích nhất ở Nix. Vì rất dễ nói “khi build package này, hãy thay dependency này bằng phiên bản của tôi”, nên tôi đóng góp cho mã nguồn mở thường xuyên hơn
    • Những việc như “thêm plugin decsync vào Evolution Flatpak” rất phổ biến trong phần mềm GUI trên Linux
      Ngoài phạm vi này, phần lớn phần mềm được cung cấp kèm các chức năng cần thiết. Ví dụ Solidworks chưa từng yêu cầu tôi tải về dependency tùy chọn, nhưng FreeCAD thì cứ đúng nghĩa là 15 phút lại đòi thứ gì đó mỗi lần tôi chuyển sang bước tiếp theo trong luồng CAD/CAM/mô phỏng/render
      https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv... cũng đáng tham khảo
      Điểm cốt lõi là “20% mà mọi người đều dùng” không bao giờ giống nhau. Trong 10 năm qua tôi đã nghe nói về hàng chục công ty cố tung ra trình xử lý văn bản “lite” chỉ triển khai 20% tính năng, nhưng câu chuyện cũ ngang thời PC là: phóng viên đang viết bài đánh giá thì tìm tính năng đếm số từ, tính năng đó lại nằm trong “80% không ai dùng”, và cuối cùng viết rằng “chương trình nhẹ thì tốt, phình to thì xấu, nhưng cái thứ chết tiệt này không đếm được số từ nên không dùng được”
    • Nếu đã xếp chồng filesystem overlay tùy chỉnh đến mức là tính năng hạng nhất, thì tôi nghĩ cứ dùng hệ thống khả biến cho rồi
      Điều đó làm tôi nhớ đến 10 năm trước, khi mọi người lao vào NoSQL rồi ngay sau đó lại tái phát minh schema trong từng dự án
    • Cũng có thể thêm plugin vào ứng dụng Flatpak, và chỉ cần biến các plugin như vậy thành package mở rộng
      OBS là một ví dụ. Trên Flathub có nhiều plugin OBS dạng com.obsproject.Studio.Plugin.*

  • Có lẽ nên định nghĩa thế này: sau khi cài bất kỳ số lượng package nào, rồi gỡ chúng theo bất kỳ thứ tự nào tại một thời điểm nào đó trong tương lai, hệ thống phải trở về trạng thái tương đương với việc ngay từ đầu chưa từng cài chúng
    Định nghĩa này sẽ loại trừ một số distro, nhưng tôi nghĩ thuộc tính đó chính là phần quan trọng của khái niệm này

    • Điểm cốt lõi có vẻ là thuộc tính đó trên thực tế là bất khả thi với hệ thống hướng đến người dùng
      Khi gỡ trình xử lý văn bản hoặc trình soạn thảo văn bản, bạn có muốn mọi file đã viết cũng biến mất theo không? Nếu gỡ trình duyệt thì mọi file đã tải xuống cũng phải biến mất sao? Nếu không, thì không có cách nào đáng tin cậy để phân biệt file nào là do chương trình tự động tạo ra và file nào là do người dùng tạo bằng chương trình đó
      Những gì được tạo trong lúc cài đặt thì có thể gỡ bỏ dễ dàng, nhưng mọi thay đổi sau đó thì không thể
      Cũng có thể nghĩ đến trường hợp đổi triển khai DNS rồi sau đó đổi DNS server mặc định. Khi gỡ provider để quay lại triển khai cũ, cần chọn xem có quay lại server cũ hay giữ cấu hình server mới. Cá nhân tôi muốn chỉ đổi provider và giữ server mới
      Các thư mục dùng chung giữa nhiều máy cũng làm việc này khó hơn. Nếu đặt /home/${USER} là mount NFS hoặc Samba và dùng cùng các file trên nhiều workstation, rồi một chương trình tạo file trong thư mục cấu hình XDG, thì khi gỡ chương trình đó trên một workstation có nên xóa cả file trên mọi máy không? Trình quản lý package của một hệ thống đơn lẻ không có cách nào biết liệu mọi thiết bị có phải giống hệt nhau hay chỉ cần thư mục home giống nhau
    • Vấn đề là bạn muốn áp dụng thuộc tính đó sâu đến mức nào
      Nên xem qua cấu trúc dữ liệu biểu diễn duy nhất và cấu trúc dữ liệu độc lập lịch sử
      Với thiết bị khối, chẳng hạn SSD, có lẽ cần đặc biệt chú ý để việc cấp phát block không phụ thuộc vào lịch sử
    • Đó là thuộc tính gọi là tính tái lập, nghĩa là cùng một cấu hình luôn tạo ra cùng một trạng thái hệ thống
    • Tôi thích định nghĩa đó
      Cũng có thể nói rằng tập hợp package tạo thành một lattice, và dù đi theo đường nào để tới một tập con package nào đó thì trạng thái cũng chỉ có một

  • Tôi đã dùng Fedora Silverblue từ khi nó ra mắt, và đây chắc chắn là tương lai
    Tôi nghĩ mọi người nên dùng ostree

    • Tôi cảm thấy Silverblue chưa đủ linh hoạt cho máy tính cá nhân
      Có thể là do tôi dùng Linux hơi tùy hứng, nhưng việc không có quyền ghi vào các thư mục như /usr hay /bin cứ khoảng hai tuần lại làm tôi phát điên một lần
      Ví dụ, một script do người dùng Ubuntu viết đang tìm thư viện theo tên và vị trí kiểu Ubuntu, còn Fedora lại dùng tên khác cho thư viện đó. Trong trường hợp như vậy, bản năng của tôi là tạo một symlink mang tên Ubuntu trỏ đến thư viện do Fedora RPM quản lý
      Nhưng thực tế để làm cho nó chạy được, tôi phải fork script, làm cho nó build được ở máy cục bộ, sửa để nó tìm cả hai tên thư viện, chạy test cục bộ, gửi PR lên upstream, v.v. Một việc bình thường chỉ cần một dòng shell lại thành công việc 90 phút
    • Tôi dùng được 1 năm rồi và thật sự rất tốt. Tôi tự hỏi Red Hat có biết họ đang có gì trong tay không. Không chỉ Silverblue mà cả chính Fedora cũng vậy
      Tôi từng đọc trong một câu trả lời trên Quora ước tính ngân sách phát triển Windows OS theo lương là khoảng 18 tỷ đô la. Hãy tưởng tượng Red Hat đầu tư 2 tỷ đô la vào Fedora để biến nó thành Firefox của thế giới desktop OS; chỉ cần lấy được 10% thị phần trước Microsoft thôi cũng đã rất lớn
      Nó đã đi được đến đây với rất ít tài nguyên, trên nền hàng nghìn package nguồn mở. Số tiền đó có thể dùng để tiếp tục duy trì các dự án như vậy và tài trợ cho chúng trong quá trình phát triển. Nhân viên Red Hat vốn đã tham gia vào rất nhiều dự án trong số đó
    • Tôi thích ý tưởng của ostree, nhưng qua việc xem lướt thì nó không có vẻ thân thiện với người dùng phổ thông hoặc trung cấp như Docker. Docker thì người dùng cá nhân có thể học trong một buổi chiều
      Tôi không thấy rõ làm thế nào để đi đến điểm “phân phối bản phân phối Debian dưới dạng snapshot ostree”
      Tôi tự hỏi liệu thứ này chỉ được thiết kế cho sysadmin chuyên nghiệp hoặc người xây dựng hệ thống hay không
    • Nếu đã từng dùng Nix thì tôi tò mò không biết so sánh ra sao
      Tôi chưa dùng Silverblue, nhưng Nix cũng có cảm giác như tương lai
    • Hiện tôi đang dùng Ubuntu trên server và thấy có ostree trong repository, nhưng vẫn chưa thử
      Nếu có thể, tôi muốn bắt đầu quản lý phiên bản ngay trên hệ thống hiện tại. Nếu việc đó quá khó hoặc bất khả thi, một ngày nào đó tôi sẽ chuyển server sang Silverblue. Tôi thật sự thích ý tưởng của ostree

  • Mùa hè này tôi đã mê Tinycore
    Nó bổ trợ tốt cho triết lý bảo mật “một OS, một chức năng” nằm dưới Qubes, Tails, Whonix mà chúng ta đã bàn ở đây vài ngày trước
    Vì nó rất nhẹ, tôi có thể khởi động một VM cho mail server, một VM cho database, một VM cho firewall/router chỉ trong vài giây
    Bản thân Tinycore là bất biến, nên chỉ cần đặt “package” và cấu hình vào vdisk rồi đánh dấu chỉ đọc là xong. Một script Virsh xử lý việc khởi động và dừng “service”, và mỗi service là một instance Tinycore
    Nó thú vị và đến giờ vẫn vững, nhưng tôi chưa chắc có nên đưa vào production của ai đó hay không

    • TinyCore luôn bị bỏ sót trong các bài giới thiệu Linux bất biến kiểu này. Nó đã tồn tại từ lâu và thiết kế cũng rất tốt
      Phần triển khai có vài điểm đáng tiếc, và có lẽ cũng không có nhà tài trợ doanh nghiệp nào để giải thích vì sao mọi người không biết nhiều về nó
      Khác với các bản phân phối Linux bất biến khác, nó vững chắc và đơn giản

  • Tôi dùng Fedora Sericea liên tục từ khi nó xuất hiện. Về cơ bản là Fedora Silverblue nhưng dùng Sway-wm thay vì Gnome-wm
    Thực tế là khá dùng được, và cũng không cần reboot mỗi lần chạy lệnh rpm-ostree install. rpm-ostree live-apply xử lý bằng overlay dựa trên systemd

    • Hai tuần qua tôi đang dùng Fedora Workstation, và với tư cách người quay lại Linux sau 20 năm, tôi có thể nói trải nghiệm đã tốt hơn rất nhiều
      Tôi vẫn chưa cần boot lại vào Windows. Nếu tình trạng này duy trì trong 6 tháng tới, tôi sẽ chuyển hẳn sang Linux và xóa phân vùng Windows
    • Dù vậy, để thực sự áp dụng kernel mới thì vẫn cần reboot chứ? Hay tôi tò mò không biết kernel có được đổi bằng thứ gì đó như kexec không

  • Về câu “tính bất biến là lời nói dối và nhiều phần của hệ thống vẫn có thể thay đổi. Chỉ là tôi không biết nên mô tả họ này bằng từ nào khác, kiểu thứ gì đó mang tính giao dịch?”, trong trường hợp Nix nghe có vẻ tập trung nhiều hơn vào khả năng tái lập
    Có vẻ ý là nếu đặt file cấu hình Nix lên một máy khác, bạn phải nhận được cùng một hệ thống, ngoại trừ khoảng /home
    Những thứ khác trông giống việc cung cấp các chức năng snapshot và rollback mà công cụ hiện có từng cung cấp, nhưng bằng cách triển khai khác

    • Từ “bất biến” gắn vào đây thì hơi kỳ
      Nếu ý là không nâng cấp hệ thống trên live system, thay đổi package sẽ được áp dụng ở lần boot tiếp theo, và có thể rollback thay đổi, thì nó gần với giao dịch nguyên tử như database hơn. Chỉ có điều phải tắt hệ thống để commit thì hơi quá
      Microsoft đã đưa giao dịch nguyên tử vào filesystem vài năm trước, nhưng giao dịch filesystem không được dùng nhiều
      Hệ thống cài đặt sẽ tốt hơn nếu có thể commit mọi thay đổi cùng lúc, và nếu có vấn đề trong lúc cài đặt thì rollback về trạng thái trước đó mà không commit gì cả. Về lý thuyết có thể làm bằng filesystem có giao dịch, nhưng thực tế có lẽ có quá nhiều trạng thái khác ngoài filesystem bị liên quan

  • Phía server có Bottlerocket OS của Amazon
    Ý tưởng là dùng phân vùng A/B cho nâng cấp, và mọi thứ không thuộc hệ thống cơ bản đều chạy dưới dạng container
    Khi boot thì dùng boot container cho cấu hình tùy chỉnh của người dùng, còn với service chạy lâu dài thì dùng host-container, hoặc trong Kubernetes thì dùng DaemonSet
    https://github.com/bottlerocket-os/bottlerocket