Systemd Vor- und Nachteile

  • Wo warst du solange? Ich hatte schon Befürchtet du siehst diesen Thread gar nicht - als grosser systemd Befürworter.

    Ich kann Dir was sagen... mir tut alles weh... ich kann kaum geradeaus laufen... die Treppen von oben nach unten hangel ich mich runter, von unten nach oben zieh ich mich rauf....<X;(


    Tja, was ist passiert... ich bin Rentner und musste mal wieder arbeiten.... :cursing:... bin dabei Wände in nem Keller eines Altbaus zu verputzen und Fenster einzubauen... und das als ehemaliger Computer-Fuzzi, der zwei linke Hände hat. :evil:... bin jetzt seit Anfang März für mich selber am malochen.... scheiss Alter, scheiss alte Knochen, scheiss Muskelkater... heute nachmittag hab ich mir dann endlich ne schmerzlindernde Tablette gegönnt... inner 0,5er Flasche, merkwürdiges Medikament mit dem Namen König Pilsener.... aber Medizin soll ja nicht schmecken, nur helfen... und diese Tablette hat meine Laune echt verbessert ^^


    Und mit guter Laune lässt sich schlecht streiten... das ist der Vorteil an solch bewusstseinsverändernden Medikamenten.. die machen gute Laune... *lacht*.. scheiss systemd.... :auslachen: ohjeohjejeh... jetzt krieg ich wieder eine von Frau Meigräfin gewischt, weil ich total unsachlich OT rumlabere..... :saint:

  • Hallo,


    Linus: gibt mal bei Google "Linus Torvalds systemd" ein, da findest du ein paar Infos. Sagen wir mal so: es gab zumindest bis jetzt keine berühmt-berüchtigte Schimpftriade ;-)


    DER Hauptkritikpunkt an systemd ist ja in der Tat der allumfassende Ansatz von systemd, sprich es kümmert sich so ziemlich um alle low-level Sachen, die oberhalb des Kernels ablaufen. Das ist in Sachen Diversifizierung sicherlich nicht so förderlich - andererseits ist es für Distributoren, die Geld mit Linux verdienen (wollen) wie RedHat, Suse, Canonical etc. Das Lennart Poettering, der führende Entwickler hinter systemd, von RedHat bezahlt wird ist wohl auch kein Zufall...
    Und: Diversifizierung ist ja auch einer DER Kernprobleme des Linux-Desktop bzw. es gibt ja diverse Stimmen, die das maßgeblich für den dauerhaft sich nicht einstellend wollenden Erfolg des Linux-Desktop verantwortlich machen. Man muss also nicht in allen Bereichen von Linux alles falsch machen... *SCNR*


    Gruß, noisefloor

  • Lennart Poettering, der führende Entwickler hinter systemd,

    Der eigentlich gern Windows nutzen will aber es sich nicht traut laut zu sagen weil er sonst keinen Rabatt mehr im Comicbuchladen kriegt :fies: Stattdessen baut er Linux zu Windows um, guter Mann. Hat ja auch mit Pulseaudio gezeigt wie man ne leicht verständliche, gut laufende Software abliefert. :shy:.

    Der Unterschied zwischen Genie und Wahnsinn definiert sich im Erfolg.

  • Also gleich mal vorneweg, mit systemd kenne ich mich nicht wirklich aus. A


    Systemd startet alles mehr oder weniger gleichzeitig, ohne darauf zu warten, dass irgendein Job fertig ist oder von irgendwas anderes abhängig ist

    das steht doch im Gegensatz zu dem hier:

    https://wiki.ubuntuusers.de/sy…nen-fuer-die-Unit-Sektion


    Oder verstehe ich da etwas falsch?


    Der Thread hat gerade bezweckt, dass ich meine erste service.unit erstellt habe...was dazu führt das ein neuer Thread ins Forum kommt:(

  • Hallo,


    die Aussage


    Quote

    Systemd startet alles mehr oder weniger gleichzeitig, ohne darauf zu warten, dass irgendein Job fertig ist oder von irgendwas anderes abhängig ist

    ist so pauschal in der Tat falsch. Richtig ist, dass systemd nicht linear arbeitet, aber natürlich trotzdem Abhängigkeiten beachtet - sonst wäre das ganze auch sinnlos. Die `After=` Direktive gibt ja z.B. an, auf welche Unit gewartet werden soll / muss.


    Upstart von Canonical hat(te) diesen Ansatz ja auch, aber systemd macht das IMHO besser.


    Gruß, noisefloor

  • Bei systemd kommt das Totschlagargument:

    Das ist vielleicht gar nicht notwendig sein sollte, das konfigurieren zu müssen wird geflissentlich ignoriert. Ist ja alles besser und bunter jetzt.

    Das ist imho eine falsche Erwartungshaltung... und was die Raspi-Config macht, hat nix damit zu tun, was in der Linux-Welt grundsätzlich von nöten ist. BTW, in der raspi-config wird mit dem Netwait imho schlichterdings nur eine Blockade in der dhcdp-conf eingebaut, was ja vom Grundsatz einer Blockade in einem parallel startenden Init-System geradezu einem Overkill entspricht.... das geht doch gar nicht....


    Sysvinit war ein sequentiell startendes Initsystem. Wenn man da den Start des Netzwerks positioniert hat, hat sysvinit erst weiter gemacht, wenn das Netz durch war, alles musst darauf warten und alle abhängigen Prozesse haben danach natürlich das fertige Netz vorgefunden. Ja, das war wohl so... aber man muss doch zugeben, dass so ein Top-Down-Prozess einfach nur überholt ist, wenn es (heute) eben auch parallel möglich ist. Und ich frage noch mal: Was hat der Start eines Netzwerks (egal ob Wlan oder Kabel) mit dem grundsätzlichen Start eines Betriebssystems zu tun? Meiner Meinung nach genau so viel wie jeder andere Prozess, egal ob Cups, Samba, Dovecot. Das Netzwerk ist nur Ein Prozess, nix mehr, nix weniger. Wenn ein System das Netzwerk für bestimmte Dinge braucht, so ist es Sache des Admins diejenigen vom Netzwerk abhängigen Jobs so zu positionieren, dass diese Jobs funktionieren UND auch damit umgehen können, wenn das Netz noch hängt oder gar nicht verfüßgbar ist. Ich muss doch auch dafür sorgen, dass meine Platten verfügbar sind, wenn ich bestimmte Dirs sharen will. Die zeitliche Abfolge "erst mounten, dann sharen" ist doch meine Verantwortung, ebenso wie ich den Share gar nicht erst versuche, wenn ich die Platte nicht mounten konnte.... dass kann doch nicht systemd's Job sein.... deshalb nicht, weil andere diese Problematik vielleicht gar nicht haben. Auch wenn gewisse Dinge in der sequentiellen Abfolge von sysvinit so waren, so bedeutet das doch nicht, dass man an diesem alten Modell festhalten muss. systemd soll imho einfach nur Dienste starten... sachliche und zeitlich Abhängigkeiten für meine Prozesse muss ICH gewährleisten, das ist nicht Aufgabe von systemd. Das das früher unter sysvinit so war, ist doch allein dem Umstand geschuldet, dass sysvinit ein total schwaches Initsystem war, was einfach nur stur von 1 nach n durchgezählt hat.Und GSD ist das heute eben nicht mehr so.


    Also... ich bin wirklich kein systemd-fan-boy.... ich bin nur erfahren genug, um die gewaltigen Vorteile zu erkennen, die mir systemd mitbringt... im Vergleich zu sysvinit.

  • Ja, Du hast mich falsch verstanden. Systemd wartet nicht von sich aus auf abhängige zu startende Jobs, entsprechend einer den vorherigen Job bewertenden Logik. Das wird immer wieder in Anlehnung an die sequentielle Abarbeitung von sysvinit verlangt, aber sysvinit hat das ja auch nicht getan. Systemd startet alles gleichzeitig, sofern nicht konkrete Direktiven gegeben wurden, wie after, before, requires usw.usw. Und alles, was eben nicht konkret festgelegt ist, wird einfach nach gutdünken gestartet, da es ja offensichtlich keine vorgegebenen Abhängigkeiten gibt... wie z.B. bei den generierten service-units, die automatisch bei init.d-Srcipte erstellt werden. Die haben Standard-Dependencies... gerade mit /etc/init.d/networking kann das also nie zuverlässig funktionieren.

  • ist so pauschal in der Tat falsch.

    Richtig... so pauschal wäre das falsch. Abver ich habe mich wiederholt auf den Zusammenhang mit den generischen service-units aus /etc/init.d bezogen, das war ja auch der Weg, auf den mich DBVs Ansichten geführt hat. Und genau für diese gibt es eben auch nur die generischen Standardabhängigkeiten, die kein spezielles oder individuelles "Warten-auf" beinhalten.

    Natürlich ist es so, dass man mit den passenden Direktiven eine absoute Reihenfolge der Abhängigkeiten vorgeben kann, bis hin zu der Möglichkeit, dass abhängige Jobs gar nicht erst gestartet werden und damit auf Fehler laufen würden, wenn ein vorheriger Prozess abgekackt ist. Aber dafür ist man eben als Systemadmin verantwortlich, das ist nicht Aufgabe von systemd.

  • Das ist imho eine falsche Erwartungshaltung

    Ich erwarte das die Kiste startet. Ohne Zauberei, ohne Konfiguriererei. Meine Erwartungshaltung an systemd ist exakt 0, genau wie an init.

    Das das früher unter sysvinit so war, ist doch allein dem Umstand geschuldet, dass sysvinit ein total schwaches Initsystem war, was einfach nur stur von 1 nach n durchgezählt hat.

    und das funktioniert auch heute noch tadellos.

    sachliche und zeitlich Abhängigkeiten für meine Prozesse muss ICH gewährleisten,

    Nö eigentlich nicht, denn wenn ich eine Erwartungshaltung hätte, dann das. Wenn ich eine Verbesserung will, dann diese. Zeug präziser in ne Textdatei schreiben ist keine Verbesserung. Der Computer weiss doch viel besser was er wann braucht.

    Der Unterschied zwischen Genie und Wahnsinn definiert sich im Erfolg.

  • BTW... was immer auch diese Hinweise auf Lennart angeht... man Leute... macht doch mal die Augen auf... unser halbes Linux ist mittlerweile ein Redhat-Linux:

    Pulseaudio

    Wayland

    systemd

    Policykit


    Ich sehe das eher so, dass Red Hat derzeit als einzige unsere Linux-Distris noch richtig weit nach vorne bringt... alles andere stagniert doch. Von Debian kommt doch imho kaum noch Innovation, von Canonical auch nicht... oder kann mich da einer mit besserem Wissen belehren? Ich sehe das so... und das, obwohl ich mit Debian wirklich mein OS gefunden habe und von dem ich total begeistert bin. Aber mittlerweile steckt da imho mehr Fedora als Debian drin.

  • Hallo,


    RedHat sind halt die mit der meisten Kohle im Linux-Umfeld. Von daher können die auch am besten bestimmen, wo es lang geht (zumindest außerhalb des Kernels)- weil die die Entwickler dafür bezahlen können.


    Gruß, noisefloor

  • Nö eigentlich nicht, denn wenn ich eine Erwartungshaltung hätte, dann das. Wenn ich eine Verbesserung will, dann diese. Zeug präziser in ne Textdatei schreiben ist keine Verbesserung. Der Computer weiss doch viel besser was er wann braucht.

    Das hattest Du früher auch nicht.... Du hattest nur einen seriellen Ablauf, ohne Logik, ohne Grips dahinter, einfach nur stur von vorne nach hinten ... und immer auch mit der Gefahr, dass das System stürzt, wenn ein Job stolpert. Ich bestreite nicht, dass es anspruchsvoller geworden ist, aber ich bestreite, dass es schlechter geworden ist. Systemd hat mit seinen Möglichkeiten die Stabilität beim System-Start imho gravierend verbessert.


    Beweise mir, das etwas schlechter ist als zuvor, konkrete Fakten... und zwar, ohne das Versäumnisse des System-Admins die eigentiche Ursache des Problems sind oder dem zugrunde liegen.

  • Das hattest Du früher auch nicht.

    Das hab ich doch auch nicht behauptet. Erwartungshaltung ist ja was zukünftiges ;).

    Beweise mir, das etwas schlechter ist als zuvor, konkrete Fakten... und zwar, ohne das Versäumnisse des System-Admins die eigentiche Ursache des Problems


    Es muss nicht schlechter sein als vorher, es muss nicht gleich gut sein, es muss deutlich besser/stabiler sein. Debian basierte auf diesem Prinzip (Quality of Implementation).

    Quote

    Once a package has not shown any important problem for a certain time period, it goes into the testing distribution.


    Dieser Punkt ist heute noch nicht erreicht, was 827 derzeitig offene bugs im tracker auch belegen.


    Da du mir auch nicht das Gegenteil beweisen kannst, ohne die "Falsche Konfiguration, It's not a bug - It's feature" Keule zu schwingen, lasse ich es lieber und zocke ne runde ;)


    Lege etwas Eis auf deine geschundenen Knochen und trink ein Bier auf mich ;)

    Der Unterschied zwischen Genie und Wahnsinn definiert sich im Erfolg.

  • Hi,

    das ist es, was ich an Linux so liebe ...

    Jeder kann das System so aufsetzen wie er will und über Änderungen/Verbesserungen lässt sich prima diskutieren.


    Im Gegensatz zu dem anderen, ziemlich weit verbreiteten OS - das kriegst Du nach dem Motto "friss oder stirb" einfach so vor die Füsse gekippt.


    btw: ich kann beide Seiten gut verstehen ... favorisiere aber, wie weiter oben schon erwähnt, mittlerweile systemd ;)


    cu,

    -ds-

  • Ich bin kein Experte betreff systemd vs initv, das sei vorab erwähnt; das initv kenne ich garnicht. Aber beim Experimentieren und Anwenden von systemd ist mir aufgefallen, dass es für mich eher leicht zu verstehen ist und dass ich recht schnell zu brauchbaren Ergebnissen gekommen bin. Ich habe mir mal zu einem sehr oberflächlichen Vergleich die Start-Skripte von smstools angeschaut, die auf dem initv aufsetzen. Tja, habe die Finger davon gelassen weil nichts durchschaut und verstanden.

    Fazit: für einen Einsteiger wie mich ist systemd eher geeignet und die Funktionsweise ist eher nachvollziehbar.


    Betreff dem Argument "wenn es nicht kaputt ist, muss es auch nicht repariert werden": Warum kauft Ihr alle 3-5 Jahre neue Computer? Weil die kaputt sind oder weil sie einfach veraltet sind den Anforderungen nicht mehr gerecht werden?

    Mein Github-Repository ist hier zu finden.

  • Warum kauft Ihr alle 3-5 Jahre neue Computer? Weil die kaputt sind oder weil sie einfach veraltet sind den Anforderungen nicht mehr gerecht werden?

    Äpfel und Birnen.


    Fazit: für einen Einsteiger wie mich ist systemd eher geeignet und die Funktionsweise ist eher nachvollziehbar.


    Wenn man das eine nicht kennt, kann das andere nicht leichter nachvollziehbar sein. systemd ist um Welten komplexer als init.

    Der Unterschied zwischen Genie und Wahnsinn definiert sich im Erfolg.

  • Servus peuler,

    Warum kauft Ihr alle 3-5 Jahre neue Computer

    das ist eine pauschale und nicht belegte Behauptung.

    Ich für meinen Teil z.B. kaufe mir einen anderen, gebrauchten Laptop, wenn der alte den Anforderungen nicht mehr entspricht (weil z.B. zu langsam) oder defekt ist.

    Den Aufrüst-Wahnsinn mache ich schon seit ca. 10 Jahren nicht mehr mit ;)


    dbv: systemd mag in Summe komplexer sein. Deswegen muss es aber nicht zwangsläufig schwieriger bzw. unverständlicher zu konfigurieren sein.

    peuler: das mit dem "leichter verständlich" sehe ich in der Tat genau so ...


    cu,

    -ds-

  • dbv: systemd mag in Summe komplexer sein. Deswegen muss es aber nicht zwangsläufig schwieriger bzw. unverständlicher zu konfigurieren sein.


    peuler: das mit dem "leichter verständlich" sehe ich in der Tat genau so ...

    Ich finde #metoo-Postings eigentlich total doof... aber diese beiden vorherigen Statements schließe ich mich voll und ganz an.