News Devuan 3.1.0 („Beowulf“): Debian-Fork ohne Systemd mit frischen Systemabbildern

[SVΞN]

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.

Zur News: Devuan 3.1.0 („Beowulf“): Debian-Fork ohne Systemd mit frischen Systemabbildern

 

[Cool Master]

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.

 

[Diggo]

Ich nutze selbst zwar auch eine Systemd Distribution, aber umgedreht, welchen Vorteil bringt Systemd auf einem Server?

 

[Eagle-PsyX-]

Ich nutze Debian mit Systemd und ehrlich gesagt verstehe ich nicht warum es da so eine Diskussion gab.

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...

 

[Armadill0]

Ich nutze selbst zwar auch eine Systemd Distribution, aber umgedreht, welchen Vorteil bringt Systemd auf einem Server?

Einheitliche Start-Scripts bzw. eben nicht mehr sondern schöne Configs, Abhängigkeiten-Management, keine Frickel-Bashscripts und so viel mehr...

 

[up.whatever]

welchen Vorteil bringt Systemd auf einem Server?

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.

 

[Eagle-PsyX-]

Ich nutze selbst zwar auch eine Systemd Distribution, aber umgedreht, welchen Vorteil bringt Systemd auf einem Server?

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".

 

[Cool Master]

Debian erlaubt ja auch noch mit
...
die Dienste zu verwalten.

Ganz zur not geht auch noch:

/etc/init.d/dienst-name start|stop|restart

 

[AW4]

Ich nutze Debian mit Systemd und ehrlich gesagt verstehe ich nicht warum es da so eine Diskussion gab.

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.

 

[konkretor]

Also was mich halt an Systemd am meisten nervt sind die Log Dateien, die sind jetzt im Binären Format.

Früher konntest einfach rein schauen.

Das init System auch Steinalt, das war eine größere Änderung. Über Jahrzente konntest deine Skripte nutzen.


Also ich von Ubuntu 14.04 auf 16.04 umgestiegen bin, war der Horror. 16 war eine Baustelle ohne Ende.
18 war dann wieder viel besser

Außer das mit den Logs stört mich an Systemd nicht mehr viel.

 

[Armadill0]

Praktisch, da der Name jetzt am Schluss steht ist, dass man mehrere Dienste gleichzeitig ansprechen kann
systemctl restart rpcbind sshd exim4 apache2 mysql
etc.

Du kannst sogar WIldcards verwenden.

 

[Cool Master]

@AW4

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.

 

[Fallenghost90]

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.

 

[aki]

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.

 

[Schtefanz]

Was mich extrem an SystemD stört ist journalctl, wer kam auf diese geniale Idee LogFiles als Binaries zu speichern?

 

[up.whatever]

Was mich extrem an SystemD stört ist journalctl, wer kam auf diese geniale Idee LogFiles als Binaries zu speichern?

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.

 

[ModellbahnerTT]

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.

 

[andy_m4]

Groß und komplex? Ja und? Dann läuft halt das neuste Distri-Name-hier nicht auf Hardware aus 1995.

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.

Ab einem Punkt muss man halt in die Zukunft schauen und kann nicht über Jahrzehnte Altlasten mitschleppen.

Das suggeriert so ein bisschen als ob systemd die einzige Möglichkeit wäre dem Altlastproblem zu entkommen.

Ob Kernel- oder Userland juckt mich als Server-Admin und User einfach nicht.

Ja. Solange keine Probleme auftreten juckt das natürlich niemand.

Solange alles sicher ist

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.

 

[RalphS]

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.

 

[Salamimander]

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...