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

[Th3Dan]

Bin da hin- und hergerissen: Die Idee der Vereinheitlichung finde ich gut, in den systemd Skripten gab es Redundanzen und man kann Abhängigkeiten definieren. Aber es ist zu komplex und daher voller Sicherheitslücken. Plus die Verletzung der Unix-Philosophie, die ich sinnvoll finde.
Ich habs im Einsatz weil halt auch nahezu jede Distri mittlerweile darauf setzt. Wirklich zufrieden bin ich in Summe jedoch nicht, ist eher ein Übel mit dem ich lebe.

 

[andy_m4]

Das mit den Abhängigkeiten oder deklarative Init-Skripte ist aber nicht systemd-exklusiv.
Außer dem alten Sys-IV-Init unterstützt eigentlich jedes Init-System die Definition von Abhängigkeiten.

Aber es ist zu komplex und daher voller Sicherheitslücken.

Zu der Komplexität kommt auch noch der Umstand, das das Ding in der Programmiersprache C geschrieben ist. Die ist eher suboptimal für solche Aufgaben und hat zudem über die Jahrzehnte auch unzählige Male bewiesen wie leicht man da Bugs einbauen kann.
Schon allein der Griff zu C war ne schlechte Entscheidung.

 

[Cool Master]

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.

Huch erst jetzt gesehen, dass du geantwortet hast. Klar Software wird komplexer das liegt aber auch daran weil man mit einer Software möglichst alles abdecken will. Das kann gut sein aber auch schlecht. Ich bin eher Fan von jede Software soll eine Aufgabe machen aber dafür perfekt, aber das ist mittlerweile leider Wunschdenken und in der Realität kaum (mehr) umsetzbar. Das Problem der Komplexität kommt nicht nur bei Linux vor sondern in der gesamten Software Branche.

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

War nie so gemeint, aber ich bin mir sicher, dass es ein Beitrag dazu ist. Man muss halt an einem Punkt ansetzten. Genau deswegen bin ich auch Fan von Debian. Nichts dabei wo zu alt ist und nichts dabei was zu bleeding edge ist. Wobei ich mir da teilweise schon mal den neusten Kernel wünschen würde zwecks Virtualisierung.

Und bei systemd ist alles sicher? :-)
Da waren schon ziemlich haarstäubende Bugs drin, die dann teilweise nicht mal als Bugs anerkannt wurden.

Habe ich das behauptet? Es gibt keine perfekte Sicherheit. Siehe den sudo Bug vor ein paar Wochen, der erst nach 10 Jahre entdeckt wurde. Die Frage ist halt wie man mit Bugs umgeht. Hast du Beispiele für Bugs die Bugs waren aber nicht anerkannt wurden?

Von dem was ich auf Wiki bzw. den Quellen gelesen habe sagt selbst Linus:

er komme mit einigen Entwicklern nicht zurecht, die seiner Meinung nach zu nachlässig mit Fehlern umgehen

Wo wir wieder bei subjektiven Einschätzungen sind. Was für Linus ein Fehler ist mag für andere keiner sein und wir wissen alle, dass Linus da eher kritischer ist als andere.

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.

Klar, alles wird nicht emotional gewesen sein aber es geht schon eher in die Richtung "subjektive Kritik" und nicht objektive. Selbst Linus sagt:

...I think some of the design details are insane (I dislike the binary logs, for example), but those are details, not big issues.

Viele haben das ganze halt einfach zu heiß gekocht. Jetzt nach gut 10 Jahren systemd ist es abgekühlt und man sieht das Leben geht weiter

 

[andy_m4]

Klar Software wird komplexer das liegt aber auch daran weil man mit einer Software möglichst alles abdecken will.

Ich sag immer:
So einfach wie möglich
So komplex wie nötig

Wobei ich mir da teilweise schon mal den neusten Kernel wünschen würde zwecks Virtualisierung.

Neuste Kernel über Backports funktionieren in der Regel reibungslos.
Jetzt mal so als kostenfreien Pro-Tipp ;-)

Das Problem der Komplexität kommt nicht nur bei Linux vor sondern in der gesamten Software Branche.

Das ist leider wahr.

War nie so gemeint [...]

Ok.

Siehe den sudo Bug vor ein paar Wochen, der erst nach 10 Jahre entdeckt wurde.

sudo ist auch das sendmail unter den Privilege-Elevation-Tools.
Ich hab nie verstanden, warum das noch großartig bei den Distributionen zum Einsatz kommt.
Mit doas gibts ein guten Ersatz, der noch ein Bruchteil des Code-Umfanges hat. Zudem ist die Syntax der Konfig.-Datei einfacher und so baut sich auch niemand so leicht durch die Konfiguration ein Loch rein.

Zugegebenermaßen bietet sudo mehr Funktionen. Für 95% der User ist dies aber völlig uninteressant, trotzdem macht man für nahezu 100% der User es zum Default.

Ähnlichkeiten bzw. Assoziationen zu Systemd (bloatet Software, die Probleme löst die die Leute vorher gar nicht hatten) sind natürlich rein zufällig. :-)

Hast du Beispiele für Bugs die Bugs waren aber nicht anerkannt wurden?

Da gabs ja so mehrere Sachen. Die eine die mir spontan einfällt ist die bekannte Geschichte mit dem Usernamen und der führenden Ziffer. Wenn ein Usernamen mit einer Ziffer beginnt bekamen damit gestartete Prozesse plötzlich root-Rechte oder so. Wurde damit abgetan, das das ja keine gültigen Usernamen wären. :-)

Was für Linus ein Fehler ist mag für andere keiner sein und wir wissen alle, dass Linus da eher kritischer ist als andere.

Weiß nicht ob kritischer. Linus war auch derjenige der gesagt hat, das Security-Bugs nicht anders behandelt gehören als normale Bugs.
Wenn der sich also über nachlässigen Umgang mit Bugs aufregt, dann würde mir das eher Sorgen machen. :-)

Viele haben das ganze halt einfach zu heiß gekocht.

Mag sein. Es gibt ja auch genug Leute, die nie mit Systemd in Konflikt kamen.
Auf der anderen Seite gibt es aber auch zufriedene Windows-Nutzer. Das allein als Maßgabe scheint mir daher zu wenig. :-)

Jetzt nach gut 10 Jahren systemd ist es abgekühlt und man sieht das Leben geht weiter

Ja. Irgendwie geht es weiter. Aber nicht, weil es gut ist sondern weil sich die Leute damit arrangiert haben. Die latente Unzufriedenheit scheint mir weiter hoch zu sein (ob berechtigt oder nicht will ich an der Stelle auch gar nicht bewerten).

Wir haben ja eine ähnliche Situation bei PulseAudio. Das ist ja auch sehr dominant und war auch umstritten und die Leute sich sich damit arrangiert. Trotzdem war halt immer ne latente Unzufriedenheit da und an Projekten wie PipeWire sieht man auch, wie schnell dann solche Leute abgeholt werden, wenn es eine Alternative gibt.
So eine ähnliche Situation haben wir meiner Meinung nach bei systemd auch.

 

[BieneMafia]

Systemd habe ich die Erfahrung gemacht, das es mal gerne hängt. Sei es beim Booten oder Herunterfahren. Besonders gerne mit dem Netzwerkdienst. Dann kommt immer die schöne 1:30 Wartezeit. Habe ich bei anderen init Diensten bis jetzt noch nie gesehen. Weiter bin ich fest der Überzeugung das bei den anderen init Diensten der Bootvorgang sogar wesentlich besser abläuft und das Systemd teilweise richtig schwergängig im Bezug mit älterer Hardware ist.

 

[Wölkchen]

welchen Vorteil bringt Systemd auf einem Server?

Die Vorteile sind doch gerade auf Servern. Auf Desktops verwaltet man doch nicht alle Nase lang irgendwelche Dienste, sondern lässt oft die Standards wie sie halt sind.

 

[andy_m4]

Die Vorteile sind doch gerade auf Servern.

Na jetzt hast Du mich direkt neugierig gemacht. :-)

Auf Desktops verwaltet man doch nicht alle Nase lang irgendwelche Dienste, sondern lässt oft die Standards wie sie halt sind.

Das ist bei Servern aber auch nicht großartig anders. Da installierst Du dann Dein MySQL, NGINX-Webserver oder was immer Du willst. Im Package der Distribution sind dann auch die entsprechenden Init-Skripte (oder bei Systemd die Unit-Files) mit dabei die werden dann mit installiert ohne das Du irgendwie nen Handschlag machen musst (außer halt ggf. nen systemctl enable mysql.service oder so), um dem System mitzuteilen das der Daemon beim Bootup mit gestartet werden soll.

Der Aufwand unterscheidet sich hier also nicht wirklich.

Das betrifft wenn überhaupt nur den, der Init-Skripte bzw. Unit-Files selber schreibt (der Programmautor oder der Distributor/Maintainer).

 

[Faust II]

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.

Du hast nicht wirklich eine Ahnung davon, kann das sein?

Im kurzen: Mit systemd wurde Linux als System und der Zusammehalt der Community bewusst gegen die Wand gefahren. Zudem: Google als fester Zeit und DNS-Server ins System ein zuhämmern hat wenig mit Sicherheit zu tun.

Log-files im binär-Format.. welche Deppen denken sich so etwas aus? Noch mehr Beispiele?

Ja. Irgendwie geht es weiter. Aber nicht, weil es gut ist sondern weil sich die Leute damit arrangiert haben.

Genau das ist es. Wie bei ähnlichen Themen z.B. bei Windows 10. Man sieht wunder an den Usern hier wo das Problem liegt. Ehrlich gesagt ich könnte kotzen wenn ich so etwas wie von @Cool Master lese...

Solang man keine Probleme sieht, existieren sie nicht?!
Diese Welt-Anschauung ist das Allerletzte um es mal höflich zu formulieren...

 

[andy_m4]

Wobei das klassische Syslog durchaus Probleme hat die sich journald ja auch annimmt. Ob die Umsetzung jetzt gelungen ist, darüber kann man streiten.

Ich finde so ein Binärformat auch eher unglücklich. Denn Logs braucht man ja vor allem im Fehlerfall. Und Textdateien lassen sich halt lesen ohne das man irgendein spezielles Programm dafür braucht. Auch wenn das Log selbst durch einen Fehler beschädigt ist, lässt sich noch relativ leicht der unbeschädigte Teil lesen. Bei journald ist u.U. das ganze Log nicht mehr lesbar oder großflächiger zerstört.

 

[Atalanttore]

Abgesehen von Nutzern die hauptsächlich am Betriebssystem Linux arbeiten und Linux nicht als Basis für die Arbeit mit Programmen verwenden, ist mir noch nie jemand begegnet, der sich für ein Init-System irgendwie interessiert.