Là systemd nội dung độc hại? [đóng cửa]


11

Truy cập một số diễn đàn trực tuyến thảo luận về Debian và Xubfox, tôi thấy một số người dùng thêm dòng này vào trường chữ ký:

... Không có hệ thống ...

Dòng này được thể hiện với niềm tự hào (dường như với tôi).

Từ Wikipedia :

systemd là một bộ trình quản lý hệ thống, thư viện và các tiện ích được thiết kế như một nền tảng quản lý và cấu hình trung tâm cho hệ điều hành máy tính Linux.

Vì vậy, systemddường như không phải là một điều xấu, vậy tại sao mọi người viết với niềm tự hào rằng họ không sử dụng nó?

systemdthể nguy hiểm, hoặc chỉ xấu cho bạn?


1
Bạn đã đọc phần Thông qua và tiếp nhận của bài viết Wikipedia đó chưa? Nó có tài liệu tham khảo cho nhiều bài viết về lý do tại sao một số người không thích nó.
Leiaz

Câu trả lời:


8

Không, nó không nguy hiểm cũng không xấu cho bạn. Bạn đã vấp phải một trận chiến nhỏ của các cuộc chiến init . Tôi sẽ không đi sâu vào chi tiết này, nhưng ngắn gọn, tình huống như sau.

Linux đã sử dụng sysvinit trong phần lớn thời gian của nó. Điều này là cũ và thiếu các tính năng và một điều khá nhiều người đồng ý là nó cần phải được thay đổi. Tuy nhiên, không ai có thể đồng ý về những gì nó nên được thay đổi thành. Nhiều lựa chọn thay thế đã được đề xuất, bao gồm - nhưng không giới hạn ở-- những điều sau đây:

Cả hai điều này đều tốt theo cách riêng của họ và xấu ở người khác. Như thường xảy ra trong thế giới đam mê, sự lựa chọn hệ thống init (một trong hai hoặc hai) để áp dụng đã trở thành một cái gì đó tương tự như một cuộc chiến tôn giáo.

Vì vậy, bạn tình cờ bắt gặp một người không thích systemdvà do đó, tự hào vì không sử dụng nó. Có nhiều người có quan điểm trái ngược và cho rằng điều đó systemdthật tuyệt vời và mọi thứ khác thật tồi tệ. Cũng giống như có bất kỳ chủ đề nào khác trên các interwebs rộng lớn và tuyệt vời.

Hạnh phúc thay, các cuộc chiến init đang sôi sục và giờ đã qua quá khứ. Hầu hết các bản phân phối Linux đã quyết định chuyển sang systemd. Ngay cả Ubuntu của Canonical, mặc dù họ là lực lượng phía sau upstart. Vì vậy, ngày nay, systemdthực sự là hệ thống init được lựa chọn cho hầu hết các trường hợp chính ngoại trừ Gentoo ( nguồn hình ảnh ):

nhập mô tả hình ảnh ở đây


6

Bạn đã đọc bài viết Wikipedia mà bạn liên kết? Cụ thể, đoạn thứ ba.

Thiết kế của systemd đã tạo ra tranh cãi đáng kể trong cộng đồng phần mềm miễn phí. Các nhà phê bình cho rằng systemd là overcomplex và tiếp tục có tính năng creep, và kiến ​​trúc của nó vi phạm các nguyên tắc thiết kế của các hệ điều hành giống Unix. Cũng có lo ngại rằng nó tạo thành một hệ thống các phụ thuộc lồng vào nhau, do đó cung cấp cho các nhà bảo trì phân phối ít sự lựa chọn ngoài việc áp dụng systemd khi nhiều phần mềm không gian người dùng phụ thuộc vào các thành phần của nó.

Ngoài ra còn có một phần lớn tiếp tục có tiêu đề " Lịch sử và tranh cãi ".


4

Nó phụ thuộc vào những gì bạn coi là độc hại. Ví dụ. cockless.org coi nó là độc hại:

http://suckless.org/sucks/systemd

Tôi chắc chắn không cố gắng để bắt đầu một cuộc chiến nảy lửa ở đây và trên thực tế tôi sử dụng nó như một người dùng Debian, nhưng thật lòng mà nói, tôi đồng ý với một người vô dụng.

CẬP NHẬT: Tôi cảm thấy tôi nên giải thích lý do tại sao tôi đồng ý với hút. Vì vậy, đây là: Tôi nghĩ rằng nó quá phức tạp và cung cấp kiểm soát quá "tập trung" trên hệ thống. Các bãi chứa lõi, nhật ký, v.v ... được lưu trữ tại db journald. Điều gì xảy ra nếu fs của tôi thất bại và db bị hỏng - không có thêm nhật ký để xem. Không có nhiều tập tin cốt lõi để phân tích. Lưu trữ tệp đơn giản tự nhiên cung cấp khả năng phục hồi thất bại tốt hơn trong các trường hợp như vậy. Cá nhân tôi đồng ý khá nhiều với mọi điểm trong danh sách không cần thiết nhưng tôi để câu trả lời cho câu hỏi chính theo ý của mọi người.


4
bạn nên nói lý do tại sao
mikeerv

1
@mikeerv: Có rất nhiều "vì" trên trang không có gì. :) và trong trang Wikipedia (được trích dẫn trong câu trả lời của Sparhawk). Tôi nghĩ rằng nó quá phức tạp và cung cấp sự kiểm soát quá "tập trung" đối với hệ thống. Các bãi chứa lõi, nhật ký, vv được lưu trữ tại db. Điều gì xảy ra nếu fs của tôi thất bại và db bị hỏng - không có thêm nhật ký để xem. Không có nhiều tập tin cốt lõi để phân tích. Lưu trữ tệp đơn giản tự nhiên cung cấp khả năng phục hồi thất bại tốt hơn trong các trường hợp như vậy. Vì vậy, yeah - TẠI SAO?!?
Alex

coredumps và log có thể được viết vào các tạp chí và / hoặc syslog, console, những thứ khác, tôi không đồng ý nó có thể phức tạp , nhưng tôi không nghĩ rằng dịch trực tiếp thành độc hại , và tôi không nghĩ câu trả lời này hỗ trợ cho bản dịch đó.
mikeerv

1
@mikeerv: đúng. Tuy nhiên, đó là nhật ký db hoặc nút cổ chai bổ sung Trong ghi nhật ký hệ thống (bây giờ việc ghi nhật ký phụ thuộc vào nhật ký VÀ trên syslogd). Về điểm độc hại: như tôi đã nói phụ thuộc vào những gì bạn cho là độc hại. Nếu một hệ thống ngăn chặn khả năng phục hồi thất bại - đó thực sự là độc hại đối với tôi.
Alex

1
Không nói đây là trường hợp cụ thể với systemd, nhưng sự kết hợp của các hệ thống con độc lập thực sự có thể làm tăng khả năng chống thất bại . So sánh một hạt nhân nguyên khối với một hạt nhân vi kiến ​​trúc. Hãy bỏ qua hiệu suất và chỉ nhìn vào khả năng chống thất bại. Cái nào có khả năng chống lại sự thất bại cao hơn: sự kết hợp của các thành phần (có khả năng lớn), tương tác với nhau thông qua các giao diện được xác định rõ; hoặc một khối mã lớn, trong đó mọi thứ có thể tự do chọc vào bất cứ thứ gì một cách tình cờ? Tôi nghĩ rằng có thể lập luận rằng được thực hiện đúng, sự lựa chọn vi kiến ​​trúc có khả năng chống thất bại cao hơn.
một CVn

3

Không nhiều độc hại như có lẽ daft.

Các nhà thiết kế đầy tầm nhìn của chính họ đến nỗi họ không thể hiểu được những điều làm cho hệ thống kiểu POSIX trở nên tuyệt vời.

"Những người không hiểu Unix bị kết án là phát minh lại nó, thật tội nghiệp."

          Henry Spencer
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.