Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsDevuan 3.1.0 („Beowulf“): Debian-Fork ohne Systemd mit frischen Systemabbildern
Das Projekt Devuan, das eine Abspaltung („Fork“) von Debian ohne Systemd darstellt, hat mit Devuan 3.1.0 („Beowulf“) frische Systemabbilder freigegeben. Anders als Devuan Unstable („Ceres“) mit Linux 5.10.13 und dem neuen Xfce 4.16 setzt das reguläre stabile Release mit Linux 4.19 und Xfce 4.12.5 auf eine eher betagte Basis.
Ich nutze Debian mit Systemd und ehrlich gesagt verstehe ich nicht warum es da so eine Diskussion gab. Da wurde meiner Meinung nach eher mit Gefühlen statt Argumenten diskutiert. Ich sehe auf jeden Fall keine Vorteile in einer Systemd freien Distribution, weil es mir ehrlich gesagt einfach egal ist was für ein init-Dienst zum Einsatz kommt.
Sehe ich ähnlich. Nach etwas Umgewöhnung lassen sich auch Systemd-Services leicht(er) schreiben und ehrlich gesagt finde ich es ganz praktisch mittlerweile.
Debian erlaubt ja auch noch mit service apache2 stop
und systemd angedachten systemctl stop apache2
die Dienste zu verwalten.
Praktisch, da der Name jetzt am Schluss steht ist, dass man mehrere Dienste gleichzeitig ansprechen kann systemctl restart rpcbind sshd exim4 apache2 mysql
etc.
Aber ja, es gibt für jede Entscheidung ein Paralleluniversum eine Linux-Distribution...
Naja, die ganzen Services auf einem Server müssen auch irgendwie gestartet und verwaltet werden. Schreib einfach mal eine systemd unit und ein klassisches init.d Script mit der gleichen Funktionalität selber, dann weißt du Systemd zu schätzen.
Du kannst asynchron mehrere Dienste, die unabhängig voneinander sind, hochfahren! Abgesehen vom besseren Konfigdesign. Hier gibt es eine Übersicht (Features of systemd).
Vermutlich wurde für init.d nie ein Multithreading Support angedacht. Ich durfte damals zur Einführung von systemd in Debian alte init.d-Skripte nach systemd portieren ;-D systemd gibt dir auf den ersten Blick weniger freie Hand dafür ist das ganze aber besser durchdesigned und nicht ganz so "willkürlich".
Ich habe damals hauptsächlich 3 Kritikpunkte vernommen/verstanden (in absteigender Lautstärke):
Systemd als Ganzes ist zu groß und komplex.
Systemd kann/macht/will zu viel und verwischt dabei aggressiv die Grenzen zwischen Kernel- und Userland-Prozessen/Aufgaben.
Da sich quasi alle Distributionen auf Systemd als einheitliches Init-System geeinigt haben, war das faktisch der Todesstoß für jedes andere Init-System, was die Diversität kaputt gemacht hat.
Praktisch, da der Name jetzt am Schluss steht ist, dass man mehrere Dienste gleichzeitig ansprechen kann systemctl restart rpcbind sshd exim4 apache2 mysql
etc.
Ja so habe ich das auch noch in Erinnerung. Die Punkte sind aber voll auf einer emotionaler Ebene. Betrachtet man es einfach mal pragmatisch spricht da nichts dagegen:
Groß und komplex? Ja und? Dann läuft halt das neuste Distri-Name-hier nicht auf Hardware aus 1995. Ab einem Punkt muss man halt in die Zukunft schauen und kann nicht über Jahrzehnte Altlasten mitschleppen. Da müssen die Entwickler halt einfach mal Ihre Software updaten. Das gab es vor Jahren auch bei MacOS als es 64 Bit only wurde. Was war das Geschrei am Anfang groß und heute? Juckt keine Sau mehr.
Ob Kernel- oder Userland juckt mich als Server-Admin und User einfach nicht. Solange alles sicher ist, ist es mir ehrlich gesagt egal wo sich etwas abspielt.
Wie gesagt, wenn man sich die Diskussion(en) heute anschaut fällt es auf, dass da viel zu viel Emotionen dabei waren und keine echte Argumente.
Den Punkt, dass Systemd zu "bloated" ist habe ich auch mitbekommen. Soweit ich weiß, stört viele, dass Systemd Funktionen einführt, die bereits andere Komponenten übernehmen (oder bisher übernommen haben). Beispielsweise timesyncd <-> ntp/chrony. Was ich auch nicht wusste, dass systemd einen eigenen Bootloader hat (den Pop_OS nutzt).
Ist jetzt nur gefährliches Halbwissen meinerseits, weil ich mit dem Thema nicht soo bewandert bin ^^. Für mich funktioniert Systemd gut.
Ist denke ich einfach eine Frage der Umgewöhnung. Ich habe bei meiner aktuellen Gentoo-Installation auch nur OpenRC genommen, weil ich es schon kannte. Startet auch sehr schnell und parallel.
Früher oder später wird man aber wohl um systemd nicht mehr herum kommen. Aktuell werden ja schon Programme wie elogind nötig, weil Oberflächen systemd-Komponenten nutzen.
Du kannst ja trotzdem noch mit rsyslog normale Textfiles schreiben lassen. Außerdem hat journalctl den Vorteil, dass du deine Logs mittels "-u" direkt auf bestimmte Units filtern kannst. Das vereinfacht die Suche nach Fehlermeldungen erheblich, wenn ein Service Ärger macht.
Alternativen wie OpenRC am leben zu halten ist sicher nicht verkehrt um die Vielfalt zu erhalten und sich nicht von immer mächtiger werdenden systemd abhängig zu sein.
Das ist doch nicht das Problem bei Komplexität das es nicht mehr auf alter Hardware läuft. Das Problem bei Komplexität ist, das Du Dir auch mehr Bugs einhandelst. Und voila. Genauso ist es. systemd hat nen recht vollen Bugtracker.
Cool Master schrieb:
Ab einem Punkt muss man halt in die Zukunft schauen und kann nicht über Jahrzehnte Altlasten mitschleppen.
Und bei systemd ist alles sicher? :-)
Da waren schon ziemlich haarstäubende Bugs drin, die dann teilweise nicht mal als Bugs anerkannt wurden.
Man kann ja darüber reden, wie schwerwiegend einzelne Kritikpunkte sind und ob die im Einzelfall wirklich gerechtfertigt sind. Aber die geäußerten Kritikpunkte pauschal als "emotional" abzutun wird der Sache dann doch nicht ganz gerecht.
Das Problem an systemD ist einfach: es unterwandert das Unixkonzept gleich mehrfach.
Ein Tool für eine Aufgabe.
Austausch findet im Textform statt.
Architektur ist hierarchisch in Ebenen.
Klar kann man sich mit arrangieren. Aber sysD ist pures Linux. Niemand außer Linux verwendet es und ich unterstelle mal, daß außer unter Linux es auch keiner will.
Für mich ist es inzwischen ein toleriertes Übel. Vorteile seh ich für mich auch keine - parallelisierter Systemstart okay, aber ich starte meine Maschinen einmal im Monat wenn’s hoch kommt. Kein Argument.
Muß halt überlegen, wenn irgendein Projekt SystemD als dependency hat, ob man diese rauswerfen kann oder ob auf die Software verzichtet werden kann.
Journalctl ärgert mich jeden Tag aufs neue... Ein Schwachsinn sondersgleichen. Ob ich nun ein grep oder -u mache... Aber Binaries, fiese Integrations (timesyncd ist die Pest) und unitfiles die unitfiles aufrufen die unitfiles aufrufen... Verwursten kann man noch immer so viel wie früher. Ich bin froh, dass journalctl unter Debian kaum eine Rolle spielt, CentOS dagegen? Ohje...
