Hệ thống làm sáng tỏ D

@xiep Tôi không thể đồng ý hơn với nhận xét của bạn.

@juanfgs bạn có vẻ là người duy nhất đọc, ít nhất tôi hoan nghênh bạn vì điều đó, nhưng bạn cần đọc một điều rất quan trọng trong nhận xét của tôi, không quan trọng tôi sẽ đặt nó ở đây:

»NIH Ở đâu? Có vẻ như Lennart già tốt bụng thích troll và lớn. "

Tôi không nghĩ rằng anh ấy viết nó vì một lý do vô tội, anh ấy biết thực tế rằng đó là một trò đùa khác của Lennart cho Ngày Cá tháng Tư (tâm trạng xấu), cũng như niềm đam mê của anh ấy với việc chuyển /, / etc và mọi thứ khác thành / Linux. 🙂

Tái bút: Cảm ơn nhưng tôi không cần luyện tiếng Anh, tôi đã sử dụng ngôn ngữ này từ năm 6 tuổi
aaahh và mọi thứ khác là sự thật, hãy xác minh nó 🙂

@juanfgs, tôi sẽ nói cụ thể với bạn về điều này:

«Và thực tế là hầu hết các phần mềm chống hệ thống đều không vượt qua được bài kiểm tra này, thậm chí có một số người vì lý do nào đó BIẾT HƠN những người đứng sau: Debian, Fedora, Archlinux, nhân Linux, toàn bộ dự án GNOME Có lẽ là dự án KDE vì họ đã không phàn nàn về systemd, SUSE, và một thời gian dài, v.v.

Mặc dù vậy, bài phát biểu độc địa và ác độc, điều duy nhất mà anh đạt được là tạo ra sự mất đoàn kết, các vấn đề và những người khác. Đó là điểm mà tôi không thể đợi họ cuối cùng chuyển sang BSD vì họ đã đe dọa từ Xorg, NetworkManager, PulseAudio và tôi không biết là do sự thiếu hiểu biết kỹ thuật tuyệt đối hay vì họ sẽ không phàn nàn về điều đó. "

Vì vậy, THEO bạn, tất cả chúng ta anti-systemd đều độc hại và độc hại mà điều duy nhất chúng ta đạt được là sự mất đoàn kết, các vấn đề, v.v. Hãy để tôi nói với bạn rằng đây là sự phẫn nộ lớn nhất mà tôi có thể đọc được ở đây. Tôi không biết tại sao những người ủng hộ hệ thống lại bận tâm, khi các vấn đề về cấu trúc của một hệ thống được đưa ra, mà rõ ràng là tại một số thời điểm sẽ ảnh hưởng đến họ, bởi vì bây giờ có thể không có gì xảy ra với họ, nhưng đến một lúc nào đó, họ sẽ làm được. nó sẽ xảy ra, và sau đó một số anti-systemd sẽ nhắc nhở họ về những lời họ đã nói nhiều lần và không ai ngăn họ lại, và có thể một số anti-systemd khác sẽ giúp họ một tay.

Cá nhân tôi không thích systemd nhưng không có nghĩa là tôi không sử dụng init, tôi phải làm vậy, vì chính xác trong công việc của tôi nếu phải chạm vào máy có init đó thì tôi phải có kiến ​​thức về cách xử lý. Nó. Ngoài ra, cá nhân tôi cũng đã sử dụng nó kể từ khi đến Archlinux và thậm chí cả Debian và Gentoo, vì vậy đừng nói với tôi rằng tầm nhìn của tôi bị thiên vị khi không sử dụng systemd, tôi đã sử dụng nó và tôi biết nó khập khiễng như thế nào. và nếu tôi phải giúp đỡ ai đó trong diễn đàn DesdeLinux hoặc trên IRC hoặc danh sách Debian (là bản phân phối mà tôi sử dụng lâu nhất và tôi vẫn sử dụng nó trong công việc của mình) Tôi sẽ làm điều đó một cách vui vẻ, bởi vì chính xác là nếu tôi thích điều gì đó về cộng đồng Linux, thì đó là bất chấp sự khác biệt nó luôn luôn là viện trợ.

Bây giờ để chuyển sang BSD, có thể, nhưng tôi sẽ chỉ làm điều đó nếu systemd trở nên độc hại đến mức nó không cho phép tôi sử dụng bất kỳ tùy chọn nào khác, trong thời gian chờ đợi tôi ở trên Linux, vô hiệu hóa tất cả những thứ điên rồ đó, bao gồm nhiều thứ trong nhóm Cgroups. .

Glibc có những lỗi không ai có thể che giấu được, có những lỗi Glibc rất lớn ảnh hưởng đến nhân và hàng trăm tệp thực thi. Sự khác biệt giữa Glibc và systemd là cái trước đây là cơ sở mà từ đó HÀNG NGÀN dự án phần mềm có thể được chuyển đổi thành các tệp nhị phân, trong khi systemd là một init, có mục đích là trở thành một phần mềm ổn định, đã được chứng minh và thực tế là không thể sai lầm. Không chỉ vậy, Glibc phải điều chỉnh theo hàng trăm kiến ​​trúc phần cứng (CPU) khác nhau, tới các cờ tối ưu hóa khác nhau và các đặc tính riêng của CPU, đến các hình thức tối ưu hóa phần mềm khác nhau, một công việc khó khăn và gian khổ hơn nhiều so với systemd. Tôi thực sự không thấy bất kỳ cách nào để trình bày so sánh giữa hai dự án trên cùng một quy mô.

Tương tự đối với GCC, GCC là một trình biên dịch hỗ trợ nhiều ngôn ngữ (tổng cộng 13 ngôn ngữ tính cả những ngôn ngữ không chính thức) và có các đặc điểm rất giống với Glibc, hỗ trợ nhiều kiến ​​trúc (70 kiến ​​trúc cho phiên bản 4.9), cờ tối ưu hóa nhị phân , Cờ tối ưu hóa CPU và nhiều tính năng khác. Bây giờ họ đang ở cùng một mức độ khó khăn, một trình biên dịch với một init. Câu trả lời là hiển nhiên hơn, bắt đầu với systemd là trong C, và rất nhiều mã GCC nằm trong trình hợp dịch hoặc bạn phải sử dụng trình hợp dịch để mọi thứ hoạt động trong hệ nhị phân, một điều hơi "khó làm".

Lỗ hổng GCC và Glibc là gì? Thông thoáng. Ngay cả Linus cũng đã cho họ tấn công, nhưng trong GCC và Glibc, họ có điều gì đó tích cực là trong systemd họ bị quên nhiều lần, đó là lỗi được báo cáo, lỗi được nhìn thấy, lỗi đã được sửa.

Ngoài ra, không ai quên rằng Kay Sievers không chỉ phá vỡ cmdline của hạt nhân, mà còn muốn đóng nó lại, xét cho cùng thì "chung chung là chung chung".

Tôi nghĩ bạn đã đọc và phân tích sai (phân tích là quan trọng) hoặc bạn thậm chí không cho mình cơ hội để làm điều đó. Việc hai quá trình truyền thông tin không phải là lý do khiến hệ thống bị hỏng, tuy nhiên, khi bạn có các tệp nhị phân với hành động động như kiểm soát mạng, nhật ký hoặc coredump, chuyển thông tin trực tiếp đến init, mọi thứ có thể sai và chúng sẽ sai, bởi vì nếu Một số mã nhị phân bị hỏng, cơ hội phá vỡ các mã còn lại cao hơn nhiều, và điều đó khá thực tế, và nó đã xảy ra, lỗi cmdline trong hạt nhân gần đây, các vấn đề về acpi mà nhà phát triển Nvidia gặp phải nhờ systemd-212 , tất cả đó là một ví dụ về những gì tôi nói.

@anonymous, tôi chỉ muốn xem vấn đề TTY sẽ phát triển như thế nào trong Linux. Khi mã CONFIG_VT xuất hiện, để chia VT thành hai phần được phân biệt rõ ràng (không gian nhân và không gian người dùng), chúng tôi sẽ cần một số công cụ để kiểm soát các VT từ không gian người dùng và ở đó systemd-an ủi có thể trở thành một phần phụ thuộc mạnh mẽ kéo phần còn lại của các bản phân phối đến mức cần thiết phải cài đặt các thành phần systemd, chỉ để hệ thống có thể hoạt động. Những gì tôi đang nói không phải là cường điệu, đó là một khả năng rất, rất lớn và thực sự đáng lo ngại. Có những dự án khác, như KMSCon, nhưng nếu hầu hết các máy tính để bàn và phân phối đều ủng hộ systemd, thì những thứ như KMSCon có thể chết nhanh hơn nhiều người nghĩ.

@ nặc danh câu hỏi là loại bỏ CONFIG_VT là một cái gì đó cuối cùng sẽ là toàn bộ (từ những gì tôi đã đọc), nghĩa là, trong hạt nhân chỉ còn lại các công cụ nguyên thủy, trong khi phần còn lại của các công cụ sẽ nằm trong không gian người dùng, điều này không tệ, ngược lại, nó sẽ loại bỏ rất nhiều mã cũ khỏi hạt nhân, giúp bảo trì dễ dàng hơn và cấu hình cao hơn nhiều (hỗ trợ KMS / DRM đầy đủ cho giao diện điều khiển). Chắc chắn trong thời gian đầu, sẽ có cả hai hệ thống, nhưng về lâu dài (15-20 bản phát hành), nó có thể thoát khỏi kernel, hoặc thậm chí sớm hơn, nhiều công cụ không còn hỗ trợ mã như vậy mà thay vào đó là mã mới hơn và được hỗ trợ tốt hơn.

Bây giờ, bạn nói rằng nếu systemd làm được điều đó, vì 50 ứng dụng nữa không thể làm được (tôi tưởng tượng thêm 50 ứng dụng nữa). Chà, nếu chúng ta thấy sự phụ thuộc mạnh mẽ của KMSCon (dự án lâu đời nhất theo nghĩa này) thì chúng là libudev (mã sẽ sớm được tham gia vào systemd, sẽ không được hỗ trợ và sẽ xung đột với systemd nếu nó tự hoạt động), libdrm, libxkbcommon, libtsm và bản thân systemd để xử lý nhiều chỗ ngồi, vì vậy khi bạn nhìn thấy điều này, bạn nhận ra rằng mọi thứ đang hình thành như thế nào khi mang về cho mình nhiều công cụ cần thiết để HĐH GNU / Linux hoạt động mà không gặp sự cố.

@ nặc danh chắc chắn những gì bạn nói là khả năng khác, eudev sẽ có sức mạnh lớn hơn trong vấn đề này và sẽ tiếp tục mở các tùy chọn để chọn các công cụ khác nhau.

Tái bút: Như bạn nói, sẽ rất thú vị khi xem cách các VT tận dụng lợi thế của KMS / DRM cùng với fbdev 😀

@dariem giải thích theo cách đơn giản để xem bạn có hiểu không:

Những gì bạn nói chắc chắn là hành vi luôn được mong đợi từ các chương trình và quy trình mô-đun. Mô-đun đã được thực hiện cho mục đích đó, để tách hai quá trình và chúng chiếm không gian bộ nhớ của riêng mình và chúng giao tiếp bằng một số phương tiện (IPC, v.v.), để trong trường hợp có sự cố, thì không có gì xấu xảy ra. và hệ thống có thể tiếp tục hoạt động mà không bị gián đoạn. Một lý thuyết chắc chắn đã được hỗ trợ rất nhiều do tiềm năng của nó và biên độ tin cậy lớn mà nó mang lại cho máy tính hiện tại. Bây giờ, điều này không phải lúc nào cũng đúng (cuộc sống không phải lúc nào cũng tươi đẹp), và tôi nghĩ rằng bạn chắc chắn đã từng là nạn nhân của những sự kiện này vào dịp này hay cách khác (điều này chắc chắn xảy ra với mọi người bất kể bạn sử dụng hệ điều hành nào), và tôi sẽ cho một vài ví dụ.

Quá trình đầu tiên đi với Xorg (là một quá trình mô-đun giống như systemd), đôi khi phát điên với một trình điều khiển và chỉ gặp sự cố và khiến bạn không có đồ họa, trong khi phần còn lại của hệ thống tiếp tục hoạt động như mong đợi ( 😀). Cho đến nay rất tốt, lý thuyết của chúng tôi rằng các quy trình mô-đun không cần phải phá vỡ hệ thống vẫn hoạt động tốt. Nhưng (luôn luôn có một số nhưng) đôi khi Xorg mang lại điều gì đó nhiều hơn sự điên rồ và vì một số lý do kỳ lạ (có thể từ điều khiển chuột đến trình điều khiển đồ họa) không chỉ khiến Xorg gặp sự cố mà còn mang lại cho bạn những gì đẹp nhất. về sự hoảng loạn của hạt nhân (và hình vẽ trên màn hình như Picasso) mà bạn có thể tưởng tượng, và sau đó bạn nhận ra rằng bất kể nó có mô-đun như thế nào, nếu một quy trình kết hợp và trao đổi thông tin / dữ liệu với một quy trình khác và có điều gì đó không ổn trong một trong số chúng và vì lý do nào đó, lỗi không thể được xử lý chính xác, khả năng các quá trình được đề cập bị ảnh hưởng sẽ tăng lên, vì thực tế đơn giản là dữ liệu bị sai hoặc đơn giản là bị hỏng, và sau đó nó đến thảm họa.

Nếu bạn nghĩ rằng điều này không thể xảy ra, tôi để lại cho bạn một số báo cáo lỗi (một báo cáo lỗi của tôi trong Debian và có một vài bức ảnh) về một lỗi cũ trong Xorg, mesa, nouveau và trình điều khiển drm / kms của hạt nhân, xử lý bất chấp chạy ** riêng biệt và là mô-đun **, chúng không hòa hợp với nhau cho lắm, ít nhất là không trong những trường hợp đó.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742930
https://bugzilla.redhat.com/show_bug.cgi?id=901816
https://bugzilla.redhat.com/show_bug.cgi?id=679619

Bây giờ, một ví dụ khác tôi sẽ cung cấp cho bạn với systemd. Sysvinit cũ của chúng tôi có một đặc điểm là mặc dù đã cũ nhưng nó rất đáng tin cậy, đến mức nếu / etc / fstab của bạn có mục nhập phân vùng (không quan trọng đối với hệ thống, hãy hiểu a / mnt / Disk160GB) và nó là nó không thể được gắn kết vì một số lý do, quá trình gắn kết chỉ đơn giản là bị bỏ qua, cung cấp cho bạn một thông báo cảnh báo và tiếp tục quá trình khởi động. Bây giờ, systemd là một câu chuyện khác, bất chấp tính mô-đun của nó, nếu bạn có một mục nhập trong / etc / fstab và systemd vì lý do nào đó thấy rằng không thể gắn kết nó, nó không chỉ đợi phân vùng khả dụng (hành vi được lập trình bình thường) cho lắp ráp của nó, nhưng nếu thời gian kết thúc, hệ thống của bạn bị dừng và bạn không thể làm gì khác hơn là vào chế độ khôi phục và xóa dòng đó khỏi / etc / fstab, một điều gì đó thực sự không thành công. Chi tiết nhỏ đó không còn nữa trong quá trình tự động khởi động và toàn bộ quá trình dừng lại, lúc đầu (systemd-) chi tiết nhỏ đó xấu hơn, vì kết xuất chỉ xuất hiện và bạn phải khởi động lại. Ai đó đã xem qua chi tiết cho bạn biết.

Một ví dụ khác mà tôi có thể đưa ra là coredumpd trong systemd. Theo mặc định, coredumpd sẽ chuyển tất cả thông tin của nó cho journald để sau này ghi thông tin đã ghi vào đĩa, cho đến nay rất tốt, chúng tôi đang sử dụng mô-đun của systemd để có lợi cho mình. Nhưng đôi khi nó xảy ra, khi coredumps rất lớn, lớn đến mức chúng có thể chiếm vài GB, và trong quá trình truyền thông tin từ coredump sang journald rồi đến đĩa, những điều kỳ lạ xảy ra như Xorg ngừng hoạt động và thậm chí cả nhân hoảng sợ. Tất nhiên, điều đó không chỉ xảy ra với systemd, mà cách nó được thiết kế làm tăng yếu tố hỏng hóc và tạo ra các chi tiết khó chịu khác (trong số đó là tăng mức tiêu thụ bộ nhớ, hỏng nhật ký, kết xuất không đầy đủ), bất cứ ai đã phải làm việc với một coredump KDE, chắc chắn bạn đã đã xem qua một số tập như vậy và bạn sẽ hiểu tầm quan trọng của việc có tùy chọn đồng bộ hóa trong / etc / fstab cho phân vùng kết xuất của bạn và chắc chắn bạn sẽ ghét thực tế là bạn không thể sử dụng một số tùy chọn khác để xử lý kết xuất, nếu bạn đã cài đặt systemd. Một ví dụ về những gì có thể xảy ra với systemd-coredumpd.

https://bugs.archlinux.org/task/41728

Bây giờ, để kết thúc:

Chúng không phải là các chương trình và quy trình mô-đun sao? Có, chúng là mô-đun. Kernel là thứ nguyên khối duy nhất mà tôi đã nói ở đây, nhưng nó cũng chấp nhận các mô-đun (LKM), vì vậy nó sẽ là một loại hạt nhân lai mặc dù dạng thiết kế cơ sở của nó không được thiết kế theo kiểu cấu trúc đó, và điều đó khiến nó trở thành một chút không ổn định trong những trường hợp nhất định.

Mô-đun đó sẽ không cho phép tôi giữ các quy trình và hệ thống của mình không gặp sự cố nếu có sự cố? Đúng là mô-đun là một biện pháp được thiết kế để đạt được độ ổn định và độ tin cậy cao, nhưng nó không phải là một biện pháp 100% không thể sai lầm, bởi vì nếu điều gì đó có thể xảy ra sai, nó sẽ đơn giản là sai, bất kể mô-đun như thế nào, đó là một thực tế.

Hệ thống nào có quyền kiểm soát mọi thứ để có thể sử dụng các nhóm và các tùy chọn khác được thêm vào hạt nhân? Hoàn toàn sai sự thật. Điều đó hoàn toàn không cần thiết, systemd có thể được để lại với một giao diện để kiểm soát việc khởi động và gán các nhóm cho các quy trình và daemon sẽ có trong hệ thống, mà không cần phải tiếp quản số lượng dịch vụ mà nó hiện có, và tốt nhất ví dụ về điều đó là; rằng OpenRC cũng có khả năng sử dụng các nhóm và không vì lý do đó mà xâm nhập để thực hiện nhiệm vụ đó.

Tôi thiên vị và sợ hãi điều gì khi nói về systemd? Tôi không biết anh ấy lấy điều đó từ đâu, vì như bạn thấy câu trả lời của tôi, tôi không sợ điều đó, tôi chỉ nói về những khía cạnh mà tôi không thích về systemd và đã có, mà không dựa vào ý kiến ​​của bên thứ ba.

Cuối cùng, bạn nói rằng: "Nếu lập trình viên quá tệ trong việc không bao gồm mã có thể xử lý đầu vào và đầu ra không mong muốn, đó là điều khác ..."

Chắc chắn để nói rằng lập trình viên vì không bao gồm một mã xử lý TẤT CẢ các cách có thể mà chương trình của anh ta có thể bị hỏng do một số mục nhập dữ liệu sai, là XẤU, đối với tôi có vẻ là một sự phẫn nộ. Bất kể anh ta là một lập trình viên giỏi đến đâu, một người không thể thiết kế một chương trình không thể sai lầm và không an toàn, thì LUÔN LUÔN sẽ có một thất bại, cách này hay cách khác sẽ được đưa ra ánh sáng, và khi nó xảy ra, nó sẽ là nhờ một thất bại ngẫu nhiên trong quá trình sử dụng, bởi tin tặc hoặc kẻ bẻ khóa khai thác lỗ hổng, bằng cách xem xét và kiểm tra mã hoặc bằng bất kỳ phương tiện nào khác mà lập trình viên có thể tin tưởng. Tốt hơn là nên đo lường lời nói trước khi nói một điều như vậy.

Chúc mừng.