Apakah systemd "berbahaya"? [Tutup]


11

Mengunjungi beberapa forum online yang membahas tentang Debian dan Xubuntu, saya melihat beberapa pengguna yang menambahkan baris ini di bidang tanda tangan:

... Tanpa sistemd ...

Baris ini ditunjukkan dengan bangga (menurut saya).

Dari Wikipedia :

systemd adalah rangkaian daemon manajemen sistem, perpustakaan, dan utilitas yang dirancang sebagai platform manajemen dan konfigurasi pusat untuk sistem operasi komputer Linux.

Jadi systemdsepertinya bukan hal yang buruk, jadi mengapa orang menulis dengan bangga bahwa mereka tidak menggunakannya?

Bisa systemdberbahaya, atau hanya buruk untukmu?


1
Sudahkah Anda membaca bagian Adopsi dan penerimaan dari artikel Wikipedia itu? Ini memiliki referensi ke beberapa artikel tentang mengapa beberapa orang tidak menyukainya.
Leiaz

Jawaban:


8

Tidak, itu tidak berbahaya atau buruk bagi Anda. Anda telah menemukan sebuah pertempuran kecil dari perang init . Saya tidak akan membahas ini secara terperinci tetapi, singkatnya, situasinya adalah sebagai berikut.

Linux telah menggunakan sysvinit untuk sebagian besar masa hidupnya. Ini sudah tua dan tidak memiliki fitur dan satu hal yang disetujui banyak orang adalah bahwa itu perlu diubah. Namun, tidak ada yang bisa menyetujui apa yang harus diubah. Berbagai alternatif diusulkan, termasuk - tetapi tidak terbatas pada-- berikut ini:

Keduanya baik dalam caranya sendiri dan buruk pada orang lain. Seperti yang sering terjadi di dunia geek, pilihan sistem init (salah satu dari dua atau lainnya) untuk diadopsi menjadi sesuatu yang mirip dengan perang agama.

Jadi, Anda kebetulan menemukan seseorang yang tidak suka systemddan, karenanya, bangga tidak menggunakannya. Ada berbagai orang yang memiliki pendapat yang berbeda dan berpikir itu systemdindah dan yang lainnya mengerikan. Sama seperti ada pada subjek lain pada jalinan lebar dan indah.

Syukurlah, perang init mulai mereda dan sekarang telah melewati masa jayanya. Sebagian besar distribusi Linux telah memutuskan untuk beralih ke systemd. Bahkan Ubuntu Canonical, meskipun mereka menjadi kekuatan di belakang upstart. Jadi, hari ini, systemdsebenarnya adalah sistem init pilihan untuk hampir semua disrtibusi utama kecuali Gentoo ( sumber gambar ):

masukkan deskripsi gambar di sini


6

Apakah Anda membaca artikel Wikipedia yang Anda tautkan? Secara khusus, paragraf ketiga.

Desain systemd telah menghasilkan kontroversi yang signifikan dalam komunitas perangkat lunak bebas. Kritikus berpendapat bahwa systemd adalah overcomplex dan menderita creep fitur lanjutan, dan bahwa arsitekturnya melanggar prinsip-prinsip desain sistem operasi mirip Unix. Ada juga kekhawatiran bahwa ia membentuk sistem saling ketergantungan, sehingga memberikan sedikit pilihan bagi pengelola distribusi selain mengadopsi systemd karena semakin banyak perangkat lunak pengguna-ruang bergantung pada komponen-komponennya.

Ada juga sebagian besar di bawah berjudul " Sejarah dan kontroversi ".


4

Itu tergantung pada apa yang Anda anggap berbahaya. Misalnya. suckless.org menganggapnya berbahaya:

http://suckless.org/sucks/systemd

Saya pasti tidak mencoba untuk memulai perang api di sini dan pada kenyataannya saya menggunakannya sebagai pengguna Debian, tetapi terus terang saya untuk satu setuju dengan pengisap.

UPDATE: Saya merasa saya harus menjelaskan mengapa saya setuju dengan tanpa menyusui. Jadi begini: Saya pikir itu terlalu rumit dan memberikan terlalu "terpusat" kontrol atas sistem. Core dumps, logs, dll disimpan di journald db. Bagaimana jika fs saya gagal dan db rusak - tidak ada lagi log untuk dilihat. Tidak ada lagi file inti untuk dianalisis. Penyimpanan file biasa secara alami memberikan ketahanan kegagalan yang lebih baik dalam kasus seperti itu. Saya pribadi cukup setuju dengan setiap poin dalam daftar payah tetapi saya meninggalkan jawaban untuk pertanyaan utama sesuai kebijaksanaan semua orang.


4
Anda harus mengatakan mengapa
mikeserv

1
@ mikeserv: Ada banyak "karena" di halaman payah. :) dan di halaman Wikipedia (dikutip dalam jawaban oleh Sparhawk). Saya pikir itu terlalu rumit dan memberikan kontrol "terpusat" atas sistem. Core dumps, logs, dll disimpan di db. Bagaimana jika fs saya gagal dan db rusak - tidak ada lagi log untuk dilihat. Tidak ada lagi file inti untuk dianalisis. Penyimpanan file biasa secara alami memberikan ketahanan kegagalan yang lebih baik dalam kasus seperti itu. Jadi, yeah - MENGAPA?!?
Alex

coredumps dan log dapat ditulis ke jurnal dan / atau syslog, konsol, orang lain, saya tidak setuju itu bisa rumit , tetapi saya tidak berpikir itu langsung diterjemahkan menjadi berbahaya , dan saya kira jawaban ini tidak mendukung terjemahan itu.
mikeserv

1
@ mikeserv: benar. Namun itu bisa berupa jurnal db atau hambatan tambahan dalam pencatatan sistem (sekarang pencatatannya tergantung pada journald AND pada syslogd). Mengenai titik berbahaya: bahwa seperti yang saya katakan tergantung pada apa yang Anda anggap berbahaya. Jika sebuah sistem mencegah ketahanan kegagalan - itu memang berbahaya bagi saya.
Alex

1
Tidak mengatakan ini adalah kasus khusus dengan systemd, tetapi kombinasi dari subsistem independen sebenarnya dapat meningkatkan resistensi kegagalan . Bandingkan kernel monolitik dengan kernel mikroarsitektur. Mari kita abaikan kinerja dan lihat saja resistensi kegagalan. Yang lebih tahan terhadap kegagalan: kombinasi komponen (berpotensi besar), berinteraksi satu sama lain melalui antarmuka yang terdefinisi dengan baik; atau sejumlah besar kode di mana semuanya bebas untuk menyodok apa pun secara tidak sengaja? Saya pikir dapat dikatakan bahwa dilakukan dengan benar, pilihan arsitektur mikro lebih tahan terhadap kegagalan.
CVn

3

Tidak berbahaya seperti mungkin gila.

Para desainer begitu penuh dengan visi mereka sendiri sehingga mereka gagal untuk memahami hal-hal yang membuat sistem tipe POSIX hebat.

"Mereka yang tidak mengerti Unix dikutuk untuk menciptakannya kembali, buruk."

          Henry Spencer
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.