- Flatpak từ lâu đã quảng bá ưu điểm là “xây dựng ứng dụng cho mọi bản phân phối”, nhưng ở phiên bản lớn tiếp theo, khả năng cao sẽ xuất hiện phụ thuộc vào systemd
- Flatpak Next hoặc Flatpak 2.0 gần như là một cuộc viết lại nhằm vượt qua các giới hạn của thiết kế đã tồn tại hàng chục năm trong dòng 1.x hiện nay, và vẫn đang ở giai đoạn lập kế hoạch
- Dịch vụ mới systemd-appd sẽ đảm nhận vai trò cốt lõi: lưu định danh ứng dụng và quyền hạn để các thành phần khác có thể truy vấn, đồng thời cho phép subsandboxing
- Với các bản phân phối không dùng systemd, từng có khả năng tồn tại một triển khai daemon độc lập như elogind, nhưng sau khi tranh cãi lan rộng, có vẻ như thiện chí hỗ trợ điều này từ phía các nhà phát triển đã suy giảm
- Nếu sự phụ thuộc vào systemd trở nên chặt chẽ hơn, việc dùng Flatpak trên các bản phân phối như Void, Guix, Alpine sẽ khó khăn hơn và tính trung lập giữa các bản phân phối cũng có thể suy yếu
Khả năng thay đổi tính trung lập giữa các bản phân phối của Flatpak
- Trang web Flatpak nêu ưu điểm đầu tiên là “Build for every distro: create one app and distribute it to the entire Linux desktop market.”, và trong danh sách các bản phân phối được hỗ trợ có cả Void Linux, Guix, Alpine — những bản phân phối dùng hệ thống init không phải systemd
- Hiện tại Flatpak không buộc người dùng phải quan tâm họ đang dùng init system nào, nhưng ở phiên bản lớn tiếp theo, khả năng cao sẽ phát sinh phụ thuộc vào systemd
- Nếu thay đổi này thực sự được áp dụng, vấn đề then chốt sẽ là liệu các bản phân phối không dùng systemd có thể tiếp tục cung cấp Flatpak hay không
Flatpak Next và định hướng tái thiết kế
- Arian Vovk và Sebastian Wick đã có một bài thuyết trình tại Linux App Summit về tương lai của Flatpak
- Phiên bản Flatpak hiện tại vẫn sẽ tiếp tục được cải thiện, nhưng việc lách qua các giới hạn của thiết kế đã tồn tại hàng chục năm ngày càng trở nên khó khăn hơn
- Công việc được gọi là Flatpak Next hoặc Flatpak 2.0 gần như là một cuộc viết lại thực tế, phản ánh kinh nghiệm tích lũy được sau Flatpak 1.x
- Thiết kế mới được lên kế hoạch theo hướng tận dụng các công nghệ và ý tưởng hiện đại đã định hình sau giai đoạn thiết kế ban đầu của Flatpak
- Nội dung thuyết trình hiện vẫn chỉ ở giai đoạn kế hoạch; chưa có một dòng mã nào được viết, nên trong vài năm tới khi công việc tiến triển, kết quả cuối cùng có thể thay đổi đáng kể
systemd-appd và việc chuyển quản lý quyền hạn
- Thay đổi cốt lõi trong hướng phát triển của Flatpak là chuyển quản lý quyền hạn từ bên trong Flatpak sang tầng dịch vụ
- Dịch vụ mới systemd-appd sẽ gán định danh cho ứng dụng, lưu quyền hạn và cho phép các thành phần khác của hệ thống truy vấn dữ liệu này
- Cấu trúc này mở ra nhiều khả năng, trong đó subsandboxing được xem là một tính năng đặc biệt quan trọng
- Kế hoạch hiện tại là đưa tính năng này vào phiên bản Flatpak hiện nay, và hệ quả là Flatpak sẽ phát sinh phụ thuộc vào systemd
Khoảng trống cho các bản phân phối không dùng systemd
- Theo giải thích của Vovk, ban đầu đã có ý định “rất cân nhắc” tới các bản phân phối và người dùng không dùng systemd
- Mô hình dễ hình dung là tương tự cách systemd-logind được tách thành daemon riêng elogind, cho phép các bản phân phối dùng init system khác vẫn có thể dùng môi trường desktop phụ thuộc vào systemd-logind
- Có vẻ như các nhà phát triển Flatpak cũng đã cố gắng chừa càng nhiều dư địa thực tế càng tốt để systemd-appd có thể có một triển khai daemon độc lập tương tự
- Nếu cách tiếp cận đó được duy trì, Flatpak có thể vẫn tiếp tục được cung cấp trên các bản phân phối không dùng systemd
Tranh cãi lan rộng và sự thay đổi trong phản ứng của nhà phát triển
- Người dùng các bản phân phối như Void hay Alpine bày tỏ lo ngại rằng nếu Flatpak phụ thuộc quá mạnh vào systemd thì nó có thể không còn hoạt động trên hệ thống của họ nữa
- Các câu hỏi lại dồn tới một người không trực tiếp tham gia kỹ thuật vào việc phát triển Flatpak, và các câu trả lời của người này đôi khi không hữu ích, mang tính xúc phạm hoặc kích động
- Khi ngày càng nhiều người hiểu nhầm rằng ông này có tham gia phát triển Flatpak, các câu hỏi nghiêm túc và thiện chí bị trộn lẫn với những phản ứng gay gắt mang màu sắc chống systemd, khiến tình hình xấu đi
- Kết quả là các nhà phát triển Flatpak bắt đầu thể hiện phản ứng rằng họ không muốn dành thời gian để cân nhắc tới các bản phân phối và người dùng không dùng systemd
- Nếu xu hướng này tiếp tục, phụ thuộc vào systemd sẽ trở nên chặt chẽ hơn, và việc triển khai một daemon độc lập sao chép chức năng của systemd-appd cũng có thể khó hơn rất nhiều so với dự kiến ban đầu
Kết quả dự kiến và ý nghĩa
- Trong tình hình hiện tại, khả năng cao Flatpak sẽ có phụ thuộc vào systemd trong vài năm tới
- Cũng có khả năng phần cân nhắc để các bản phân phối không dùng systemd có thể tạo daemon độc lập thay thế chức năng của systemd-appd sẽ bị loại bỏ
- Khi đó, Flatpak sẽ khó còn có thể quảng bá tính trung lập giữa các bản phân phối theo nghĩa một ứng dụng có thể phát hành cho mọi bản phân phối
- Vì Flatpak là công cụ có nhu cầu thực tế bất kể người dùng đang dùng init system nào, thay đổi này sẽ tác động trực tiếp tới phạm vi phân phối ứng dụng desktop Linux
1 bình luận
Ý kiến trên Lobste.rs
Tôi không hiểu vì sao mọi người lại ghét systemd đến vậy. Cá nhân tôi thấy nó cung cấp các tính năng hữu ích thông qua API dễ làm việc và khả năng quản lý phụ thuộc·xung đột hợp lý
Những người ghét systemd thường chỉ đưa ra các lý do mơ hồ như “không đúng chất Unix”, “quá tập trung”, hay “định dạng file của systemd-journald không phải văn bản thuần”
Nếu phản đối thì tôi muốn nghe lý do cụ thể, giải pháp, và vì sao các init system khác tốt hơn. Khi đó tôi có thể giải thích vì sao các script rc lại là một đống hack bẩn thỉu khủng khiếp
Với tôi, triết lý Linux về cơ bản luôn là chuyện quyền lựa chọn, và nếu Flatpak yêu cầu một init system cụ thể thì người dùng sẽ có ít lựa chọn hơn khi cấu hình hệ thống để đạt kết quả họ muốn
Nó cần phải dễ đưa vào container image hơn, và user systemd nên có quyền truy cập API đọc tới instance hệ thống để ít nhất có thể lên lịch unit bằng những thứ như
After,RequiresDù vậy tôi vẫn cho rằng đây là điều tuyệt nhất xảy ra với Linux kể từ sau khi bỏ HAL, và tôi thậm chí từng bắt tay cảm ơn Lennart vì dự án này
Điều mà những “người phản đối” này thực chất đang đòi hỏi gần hơn với việc bản thân giải pháp không nên tồn tại. Họ hành xử như HOA của Linux, và tôi xem đó giống kiểu chính trị phản động cản trở tiến bộ, ngăn một hệ thống thực sự vững, dùng được và có sức cạnh tranh đẩy lùi các hệ điều hành độc quyền
upstartthì chắc tôi cũng không phàn nàn gì nhiềuNhưng trên laptop thì tôi muốn thứ khác. Tôi có quan điểm riêng về cách môi trường cá nhân của mình nên vận hành, tôi còn muốn những tính năng tiện lợi mà người dùng Linux phổ thông có thể không muốn, và tôi muốn sẽ không có chuyện gì xảy ra nếu tôi không yêu cầu rõ ràng. Tôi ghét công sức để “tắt cho nó đừng làm” hơn nhiều so với công sức để “làm cho nó hoạt động”
Lý do cốt lõi khiến tôi rời NixOS vì systemd là phạm vi ngày càng phình to và các mặc định đầy tính áp đặt. Khi quản lý nguồn và đăng nhập được tích hợp, việc đóng nắp máy lại luôn đưa máy vào sleep là kiểu hành vi mà tôi phải sửa đi sửa lại; việc thay đổi phạm vi cho phép linger đã làm hỏng
nohupvàscreentheo yêu cầu của POSIX; còn việc quản lý VT chặt hơn buộc các thứ như “đăng nhập một lần rồi chạy nhiều instance Xorg” hay “chiếm VT” phải được thiết kế lại theo kiểu systemdCuối cùng tôi kết luận rằng
sinittối giản cùng với việc không có giám sát service còn tốt hơn, và tôi tự viết shell boot script để triển khai một phần tính năng hệ thống bằng shell, phần khác bằng Common Lisp. Trên laptop, những thứ như PostgreSQL một khi đã chạy thì cứ để nó chạy, nếu nó dừng thì tôi sẽ nhận ra, nếu chỉ cần khởi động lại là đủ thì mọi thứ đơn giản, còn nếu không đủ thì trình giám sát service cũng chẳng giúp được gìMột vài ví dụ làm mất niềm tin gồm: trên HDD, journald không in ra gì dù tôi đợi vài phút để xem log trong trạng thái cache lạnh; tôi từng tự gặp https://github.com/systemd/systemd/issues/2913 ; và việc họ không ngại làm hỏng
nohupTrong quá trình phát triển, những thái độ như ở https://github.com/systemd/systemd/issues/437 — kiểu “chúng tôi cung cấp mặc định tốt, nhưng nếu mặc định tệ thì distro có thể sửa” — và thái độ ngần ngại cam kết API ổn định như ở http://lists.freedesktop.org/archives/systemd-devel/… cũng làm suy giảm niềm tin
Tuy vậy đây đều là những bất mãn cũ. Sau khi thấy systemd giải quyết một số vấn đề nhưng lại tạo ra vấn đề khác, mà cả hai loại đó vốn không phải vấn đề tôi có ngay từ đầu, tôi đã chuyển sang shell script khởi động trên laptop, và giờ chi phí duy trì hiện trạng quá thấp nên không có lý do gì để thử lại systemd. Trên VPS thì tôi vẫn dùng systemd trong phạm vi quen thuộc của Debian
Điều khiến tôi bực là chuyện này được bắt đầu bởi một người không phải nhà phát triển Flatpak với thông tin sai lệch, rồi gây ra phản ứng cảm tính, sau đó trong lúc thread gốc tiếp diễn thì những cách diễn đạt còn nặng hơn được thêm vào, khiến mọi người tràn vào nhắm vào dự án Flatpak và danh tiếng của các nhà phát triển
Vì thế cũng không có gì lạ khi các nhà phát triển Flatpak thực sự bị ảnh hưởng về mặt cảm xúc và muốn giữ khoảng cách với đám đông đang giận dữ
Tôi mong mọi người bình tĩnh và đừng đẩy sự việc đi xa hơn. Nếu có nghi ngờ hay lo ngại thì hãy nói chuyện với đúng maintainer, thể hiện rằng bạn ủng hộ việc tìm điểm dung hòa, và cho thấy đây là sự việc cá biệt của một vài cá nhân chứ không đại diện cho cả cộng đồng
Cũng như ý tưởng phụ thuộc vào systemd chưa phải điều đã chốt mà chỉ mới là ý tưởng, tôi nghĩ khả năng các maintainer xem xét lại việc hỗ trợ đa dạng dự án hơn vẫn chưa hề khép lại
Tôi mong mọi người vẫn đủ ổn để tiếp tục hỗ trợ các hệ thống không chạy trên systemd. Flatpak và các cách tiếp cận kiểu container khác giúp người dùng chạy được những gói phần mềm không dễ build trên nền tảng mục tiêu, và sẽ tốt nếu có thể chạy Flatpak trên những hệ như vậy khi cần một phần mềm cụ thể
Container cũng có vai trò tương tự, nhưng trên những cấu hình đủ dị thường thì làm cho thứ như x11docker hoạt động đúng cách lại khó chịu đến mức phiền phức
Tôi dùng Void trên laptop; nó làm việc rất hiệu quả và tài liệu cũng khá tốt. Cảm ơn mọi công sức mà các nhà phát triển đã bỏ ra, và hy vọng thay đổi của Flatpak sẽ không trở thành gánh nặng quá lớn
“Đây là Linux hiện đại, và chỉ có systemd.”
Điều này gợi lại rất rõ rằng cộng đồng Linux giống WeWork hơn là một cộng đồng thực sự. Trong khi mọi người xung quanh đều đang nhận lương dựa vào sự hiện diện của Red Hat, vẫn có ai đó đang hack GNU readline miễn phí
Ở giai đoạn này, còn quá sớm để khẳng định chắc chắn rằng nó “sẽ trở thành phụ thuộc”, và có vẻ mang tính suy đoán khá nhiều
Thú vị ở chỗ tiêu đề lại khẳng định mạnh hơn nhiều so với nội dung bài viết. Rõ ràng có nhiều bình luận chỉ phản ứng với mỗi tiêu đề, và may là không phải tất cả, nhưng hiện tượng này trên Internet thì chẳng mới mẻ gì
Dạo này ngay cả trên lobste.rs tôi cũng thường thấy mọi người chỉ phản ứng với tiêu đề hoặc với một câu trong bình luận dài, điều này khá đáng lo. Họ thường gần như không chừa chỗ cho khả năng nào khác ngoài cách diễn giải đầu tiên hiện lên trong đầu, vốn không ít khi mang tính công kích
Đọc bài thì có vẻ điều tương tự cũng đã xảy ra trong cuộc thảo luận về Flatpak 2.0. Có vẻ họ từng muốn chừa chỗ cho các hệ init khác, nhưng diễn ngôn xung quanh nhanh chóng trở nên thù địch nên rốt cuộc gần như đã bỏ ý định đó
Với những người dùng init thay thế, điều này thực sự rất bực bội. Tôi đang chạy một chiếc laptop bằng Alpine Linux và đã dùng Flatpak để chạy phần mềm chỉ hoạt động với glibc. Thay đổi này sẽ khiến tôi rời bỏ môi trường đó
Tôi không ghét systemd. Các hệ thống Gentoo của tôi đều dựa trên systemd. Chỉ là tôi không thích cách systemd đang khiến phần mềm tự do và mã nguồn mở ngày càng phụ thuộc vào GNU/Linux hơn
Đây rõ ràng là một điều tốt
systemd gồm các daemon ổn định với API được xác định rõ ràng, nên bất kỳ phần nào của systemd mà Flatpak sẽ phụ thuộc vào cũng có thể được ai đó đầu tư công sức tái hiện sạch sẽ từ đầu
Đây là kết quả tốt nhất có thể. Phân mảnh giảm đi, còn những người có nhu cầu đặc biệt thì có được một mục tiêu ổn định để tái triển khai
API của systemd thường chỉ được mô tả khá mơ hồ trong các trang man, và phía systemd cũng không kỳ vọng có triển khai khác, nên nó không thực sự ổn định hay được quản lý phiên bản theo cả hai chiều
Với API socket notify thì còn ngược lại: nó chỉ ổn định theo một chiều. Việc thêm hỗ trợ vsock trên thực tế đã làm hỏng các daemon được triển khai mà không phụ thuộc vào libsystemd. Lý do chuyện này không nổi tiếng là vì vsock chủ yếu được dùng cho giao tiếp giữa các systemd qua ranh giới ảo hóa. Nếu được thiết kế tử tế, đáng ra nó phải là một phần mở rộng chỉ dùng ở chính ranh giới đó
Nói là “các daemon”, nhưng trên thực tế chủ yếu là logind và systemd, và vì chính hai thứ này phơi ra toàn bộ bề mặt API nên khả năng phối ghép bị hạn chế. Chúng làm điều đó qua vài giao diện DBus, giờ thêm varlink, và thông qua một thư viện duy nhất
Muốn thay thế systemd thì либо phải thay cả khối rồi khó nhọc điều chỉnh mô hình nội bộ để phơi ra API kiểu systemd, hoặc trước tiên phải gỡ các lựa chọn thiết kế API của systemd ra và tạo một lớp trung gian cung cấp backend có thể cắm được
Tôi đã xử lý vấn đề này nhiều năm rồi. Tôi cho rằng nhiều nguyên tắc thiết kế của systemd là hợp lý, nhưng thiết kế hiện tại đang dồn một mức độ phức tạp không cần thiết với đa số người dùng ra mặt trước. Một thiết kế mô-đun hơn và có thể thay thế được là điều hoàn toàn khả thi, và cũng khá dễ hình dung ra các giao diện đơn giản có thể tách rời hoặc tái sử dụng các giao diện sẵn có
Nhưng vấn đề nằm ở phần mềm đã chọn phụ thuộc vào API của systemd. Muốn cho nó chạy với thứ khác thì либо phải đưa upstream các bản vá để tách phần hỗ trợ tính năng đang bị bó buộc vào toàn bộ libsystemd, либо phải thêm hỗ trợ cho từng API riêng mới; cách đầu chưa từng thành công, còn cách sau thì khó được chấp nhận vì gánh nặng bảo trì của các API ít người dùng hoặc chưa phát hành
Hoặc cũng có thể chỉ triển khai đúng các API mà phần mềm sử dụng. Ví dụ như dùng một dịch vụ DBus login1 không triển khai phần lớn các API khác. Nhưng như vậy lại xung đột với các triển khai khác muốn thay thế những phần khác của API, và bạn sẽ phải triển khai ba biến thể: API gốc sạch sẽ, API DBus của logind/systemd, và API cho varlink
Về dài hạn, giải pháp có thể là một bộ định tuyến triển khai toàn bộ API của systemd hoặc logind rồi nối về các API tách rời ở phía sau. Nhưng thiết kế hiện tại cài cắm quá nhiều trùng lặp và tính đặc thù của systemd nên việc làm đúng là cực kỳ phức tạp
Tôi không biết đó có phải chủ ý hay không, nhưng qua lời của các nhà phát triển systemd thì ít nhất đây là vấn đề mà họ cố tình không quan tâm. Việc tạo một lớp trung gian phức tạp hoặc làm ra một bản thay thế systemd mà không viết lại systemd là rất khó, và ngay cả khi ứng dụng chỉ phụ thuộc vào một phần API có thể cung cấp dưới dạng các mảnh cô lập, thì trên thực tế vẫn rất khó thay thế sạch sẽ chỉ một phần của systemd
Tôi không thích cách Red Hat đang nắm quá nhiều quyền kiểm soát đối với hệ sinh thái Linux
Dù vậy, việc Red Hat chấp nhận phần mềm tự do cũng phần nào làm dịu bớt lo ngại về ảnh hưởng của họ. Nhìn vào những công nghệ mà họ đã mua lại qua nhiều năm, ngay cả với những thứ trước đó không hề có upstream, họ cũng đã tự tạo upstream tự do và mã nguồn mở. Tôi đặc biệt nhớ đến Dogtag PKI và 389 Directory Server
Nhìn chung, tôi cho rằng họ phần lớn không gây hại cho hệ sinh thái, và số trường hợp họ thúc đẩy nó tiến lên còn nhiều hơn số trường hợp họ làm tổn hại nó
Tôi không bị ảnh hưởng trực tiếp bởi cuộc tranh luận này, nhưng ở đây chẳng có gì giúp xoa dịu nỗi bất an về độ phức tạp và tầng trừu tượng không cần thiết đang không ngừng gia tăng trên các hệ thống Linux
Linux đang nhanh chóng trở thành Java của hệ điều hành. Thật sự rất buồn