Das heißt alles und nichts. Kann jeder interpretieren, wie er will. Somit als Argument ohne weitere Ausführung wertlos.
Hier mal ein Vergleich zwischen
SysVInit-Skript für cron:
#!/bin/sh # Start/stop the cron daemon. # ### BEGIN INIT INFO # Provides: cron # Required-Start: $syslog $time # Required-Stop: $syslog $time # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Regular background program processing daemon # Description: cron is a standard UNIX program that runs user-specified # programs at periodic scheduled times. vixie cron adds a # number of features to the basic UNIX cron, including better # security and more powerful configuration options. ### END INIT INFO
test -f /usr/sbin/cron || exit 0
#LSBNAMES='-l' # Uncomment for LSB name support in /etc/cron.d/
Wobei das noch nicht mal der ganze Code ist, der für SysVInit benötigt wird. Einerseits wäre das /lib/lsb/init-functions, das eingebunden wird, dann wird in cron selbst (bzw. im jeweiligen Daemon) noch viel Boilerplate benötigt.
Einwand: Ich kam bisher auf andere Zahlen, wie ich unter einschlägigen Artikeln auf Pro-Linux bereits kommentierte (je nach Zählweise ca. 500k Zeilen). Siehe als Gegenargumente etwa die Punkte 2-4 & 9 hier, sowie die darin erwähnten Verweise.
Lennart hat bestätigt (via), dass die Zahlen bzgl. systemd von Phoronix, verbreitet durch TheRegister und nixCraft, irreführend sind. Lennart kam mittels sloccount selbst auf 454k Zeilen. Der Autor von nixCraft hat in der Diskussion mit Lennart auch zugegeben, dass der die Zahlen hätte prüfen sollen, bevor er das so weiterverbreitet.
Nur zum Vergleich: Je nach Zählweise kommt ein SysVinit kommt allein mit einem minimalen Satz an Initskripten auf etwa 8,5k Zeilen Quelltext ohne Kommentare oder Leerzeilen, und die nötige bash kommt (ohne Abhängigkeiten) bereits auf etwa 22,5k, falls die Zahlen dort stimmen. Das liegt in der selben Größenordnung wie systemd mit etwa 385k Zeilen Quelltext, die ich auf Version 242 gemessen hatte (hier stehen inzwischen 522k). Und da ist eine Normalisierung auf der Grundlage des unterschiedlichen Funktionsumfang nicht einbezogen.
Lennart hat bestätigt (via), dass die Zahlen bzgl. systemd von Phoronix, verbreitet durch TheRegister und nixCraft, irreführend sind.
Und Dr. Marlboro sagt: "Rauchen ist gut für die Gesundheit". Also bitte...
Gehen wir doch spaßeshalber mal von der Mitte aus: (1200 + 500) / 2 = 850 K LOC. Erscheint mir immer noch etwas übertrieben, um ein System hoch und wieder runter zu fahren.
Aber wie viele LOC auch immer: systemd hat mit einem init-System nicht mehr viel zu tun, sondern wird immer mehr zu einer Steuerzentrale entwickelt. Für mich ist das Kompetenzüberschreitung.
Erscheint mir immer noch etwas übertrieben, um ein System hoch und wieder runter zu fahren.
systemd mach ja auch wesentlich mehr, als das System hoch und wieder runter zu fahren, wie Du selbst festgestellt hast:
systemd hat mit einem init-System nicht mehr viel zu tun, sondern wird immer mehr zu einer Steuerzentrale entwickelt.
Korrekt. Deshalb ist das Argument "systemd hat sooo viel Code, nur um das System zu starten und zu stoppen" ja auch falsch. Das Argument "systemd ist ein monolithisches Monster" aber auch - denn das ist alles fein säuberlich in verschiedene daemons und Tools aufgegliedert.
Aber ja, systemd ist eine Linux-Middleware. Man kann das gut oder schlecht finden, es sorgt halt für eine Standardisierung und wird offensichtlich von vielen Entwicklern von Userspace-Software gut angenommen.
Man kann das gut oder schlecht finden, es sorgt halt für eine Standardisierung und wird offensichtlich von vielen Entwicklern von Userspace-Software gut angenommen.
Und genau so entstehen Monopole - man entwickelt nur noch für einen Standard. Windows/MS Office lassen grüßen.
Das systemd freie Software ist und der Code sowie alle Schnittstellen komplett offen dokumentiert, lässt Du bei diesem Vergleich aber lieber elegant unter den Tisch fallen?!
Man könnte durchaus Alternativen zu systemd bereitstellen, die der Anwendungssoftware nur vortäuschen, das systemd-Services vorhanden sind. Soweit ich weiß, gibt es da auch Ansätze dazu, meine das gelesen zu haben. Systemd nutzt halt alle möglichen Features des Linux-Kernels und stellt einheitliche Services bereit. Wer kann es verdenken, das dies auch angenommen wird?
Das systemd freie Software ist und der Code sowie alle Schnittstellen komplett offen dokumentiert, lässt Du bei diesem Vergleich aber lieber elegant unter den Tisch fallen?!
Na, und? Was nutzt das, wenn ohne systemd nichts mehr geht? Und wer soll bei der ausufernden Komplexität da überhaupt noch durchblicken? Der "systemd-Beauftragte"?
Man könnte durchaus Alternativen zu systemd bereitstellen, die der Anwendungssoftware nur vortäuschen, das systemd-Services vorhanden sind.
Ja, toll! Soweit sind wir also schon: tricksen und täuschen, damit eine Anwendung ohne systemd überhaupt noch läuft. Da habe ich dann doch andere Vorstellungen von Vielfalt und Open Source.
Ja, toll! Soweit sind wir also schon: tricksen und täuschen, damit eine Anwendung ohne systemd überhaupt noch läuft.
Gentoo, diverse andere Distributionen und die BSDs machen das zum Teil so. Die Alternative wäre, die Software, die diese Schnittstellen nutzen zu patchen, Upstream zu pflegen oder zu forken. Das ist je nach Komponente auch geschehen (udev - eudev, logind - consolekit).
Da habe ich dann doch andere Vorstellungen von Vielfalt und Open Source.
Dann müssen Sie beitragen! Das ist eben Open Source.
Dazu brauche ich Ihre Aufforderung nicht. Ich *habe* beigetragen und werde das auch weiterhin tun. Und Sie? Haben *Sie* beigetragen? Und mit "Beitrag" meine ich etwas anderes als Ihre Romane hier.
Ich *habe* beigetragen und werde das auch weiterhin tun.
Ihnen schwebt ja offensichtlich ein besseres systemd bzw. eine Alternative zu systemd vor, wenn ich das recht interpretiere. Dann haben Sie offenbar an den falschen Stellen beigetragen, wenn es darum ging systemd als OSS zu verändern oder zu verhindern oder obsolet zu machen.
Und Sie? Haben *Sie* beigetragen?
Ja, aber nicht zu sysvinit oder systemd. Jedenfalls nicht direkt in obiger Hinsicht. Allerdings hatte ich bisher auch keine Absichten systemd als OSS zu ändern oder gar zu ersetzen. Ich glaube, dass das mich das in gewisser Weise von Ihnen unterscheidet. Geben Sie mir also erstmal einen Grund dazu beizutragen, bevor Sie mich das fragen.
Und mit "Beitrag" meine ich etwas anderes als Ihre Romane hier.
Besser Romane schreiben, als missverstanden werden. Ihre Beiträge, die Ihre Argumente mit falschen Zahlen unterlegen, sind auch nicht gerade zielführend.
Ihnen schwebt ja offensichtlich ein besseres systemd bzw. eine Alternative zu systemd vor,
Wenn, schwebt mir höchstens ein de-systemd vor. Und eine Alternative gibt es doch längst. Ich nutze sie. Und andere auch.
wenn ich das recht interpretiere.
Offenbar nicht.
Dann haben Sie offenbar an den falschen Stellen beigetragen, wenn es darum ging systemd als OSS zu verändern oder zu verhindern oder obsolet zu machen.
Sie haben mich ganz allgemein aufgefordert beizutragen, was ziemlich anmaßend ist. Von systemd war da nicht die Rede.
Ja, aber nicht zu sysvinit oder systemd. Jedenfalls nicht direkt in obiger Hinsicht. Allerdings hatte ich bisher auch keine Absichten systemd als OSS zu ändern oder gar zu ersetzen. Ich glaube, dass das mich das in gewisser Weise von Ihnen unterscheidet.
Und nicht nur das.
Geben Sie mir also erstmal einen Grund dazu beizutragen, bevor Sie mich das fragen.
Wie? *Ich* soll *Ihnen* einen Grund geben beizutragen? Sind Sie noch ganz bei Bewusstsein? Oder brauchen Sie wirklich jemanden, der Ihnen sagt, was Sie tun sollen? Absurd.
Besser Romane schreiben, als missverstanden werden.
Besser missverstanden werden, als *nicht* gelesen zu werden. Eventuelle Missverständnisse können ggf. ausgeräumt werden.
Ihre Beiträge, die Ihre Argumente mit falschen Zahlen unterlegen, sind auch nicht gerade zielführend.
"Beiträge" - gleich mehrere? Welche denn? Na?
Zu "falsche Zahlen": Ich habe in meinem Beitrag jedenfalls eine neutrale Quelle genannt. Das reicht normalerweise. Haben *Sie* denn einen nicht widerlegbaren Beweis aus *neutraler* Quelle für Ihre Behauptung?
Und was "zielführend" ist und was nicht, entscheiden im Übrigen nicht Sie.
zu Zitat 1: a) Wenn Ihnen kein besseres, aber dafür ein anderes, systemd, sprich ein de-systemd, vorschwebt, schwebt Ihnen der obigen Diskussion folgend ein schlechteres vor. Was "besser" und "schlechter" in diesem Kontext bedeutet, ist dabei noch nicht näher erwähnt.
b) Ich habe nicht behauptet, dass es keine Alternativen gäbe. Ich habe Ihnen nahegelegt, dass Sie anscheinend weder zu systemd noch zu einer der Alternativen maßgeblich beigetragen haben, sodass diese Ihren Vorstellungen von OSS entsprechen.
c) Dass Sie Alternativen nutzen, ist doch prima. Lassen Sie dafür bitte andere systemd nutzen oder entwickeln. Jedem das Seine...
zu Zitat 2: Ich glaube schon, dass ich das richtig interpretiert habe. Allerdings scheinen Sie meine Interpretation fehlinterpretiert zu haben.
zu Zitat 3: a) Ist eine Aufforderung anmaßend, die die einzig logische Konsequenz, die sich aus der Diskrepanz des derzeitigen Zustands und Ihrer Vorstellungen von OSS ergeben?
b) Von systemd ist in diesem Kontext sehr wohl die Rede. Die Software ist zentraler Bestandteil des Inhalts des kommentierten Artikels und der gesamten Diskussion, die Sie, ich und andere führ(t)en. Sie bezogen sich an jener Stelle doch auf eine zwei Sätze zuvor zitierte Aussage von "Nur ein Leser" über Alternativen zu systemd und Ideen zur Implementierung von Schnittstellen, die systemd simulieren/emulieren. Dass an dieser Stelle nicht auch die Rede von systemd gewesen sein soll, kann ich demnach nicht nachvollziehen.
zu Zitat 4: Ja, sehr wahrscheinlich. Aber inwiefern ist das für diese Diskussion relevant?
zu Zitat 5: a) Ja, ich hatte Sie nach einem Grund für Beiträge zu besagten Projekten gefragt, weil Sie mich nach meinen Beiträgen fragten. Ich habe im Gegensatz zu Ihnen keine Änderungswünsche oder Verbesserungsvorschläge für das systemd-Projekt oder anderen init-Projekten. Welchen Grund beizutragen, sollte ich also haben können? Wenn Sie diese Logik nicht verstehen, weiß ich auch nicht mehr weiter. Das ist auch, was ich in Zitat 4 schrieb.
b) Dass Sie suggerieren, ich bräuchte jemanden, der mir sagt, was ich zu tun hätte, grenzt an ein ad hominem. Das ist noch mehrere Größenordnungen anmaßender und absurder, als das was ich Ihrer Meinung nach verbrochen haben soll.
zu Zitat 6: Auf Pro-Linux missverstanden zu werden, zählt meiner Erfahrung nach fast schon zur Norm. Deshalb gehe ich lieber auf Nummer sicher, wenn ich es denn schon tue. Dass ich mich dafür rechtfertigen muss, ausführlicher zu schreiben, als es Ihnen nötig erscheint, ist ebenfalls absurd. Wenn Sie an meiner Form etwas auszusetzen haben, bitteschön. Das hilft Ihrer Argumentation aber auch nicht gerade weiter.
zu Zitat 7: a) Hiersind zwei Beiträge mit irreführenden Zahlen, die aus Ihrer Feder stammen.
Ersterer Kommentar ist noch zu entschuldigen, da Sie lediglich durch die mediale Clickbait-Masche verführt wurden, diese Zahlen als gegeben anzusehen. Dass das überhaupt so veröffentlicht wurde und bisher nicht korrigiert wurde, ist meiner Meinung nach eine riesige Schweinerei und sagt viel über diese Portale aus. Selbst Pro-Linux hat es nicht korrigiert. Ich hoffe, dass dies den Lesern meiner Kommentare eine Lehre ist, nicht alles ungeprüft zu glauben, was drei Mal retweetet wurde. Dass Sie die selbe Zahl im zweiten Kommentar erneut verwenden, um Ihre Thesen zu stützen, ist jedoch nicht mehr zu entschuldigen, nachdem ich Sie darauf hingewiesen habe, dass diese nicht korrekt wären.
b) Sie haben gar keine Quelle genannt, denn Ihre Quellenangabe ist kaputt. Die ursprüngliche Quelle ist meines Wissens nach Phoronix. Darauf bezogen sich alle mir bekannten Meldungen darüber. Phoronix ist für Clickbait und billige Meldungen bekannt. Die Benchmarks sind in großen Teilen auch nicht besonders aussagekräftig.
c) Falls ich nicht entscheide, was an dieser Stelle zielführend ist, und was nicht, dann entscheidet es keiner oder bestenfalls noch die Redaktion. Ich brauche tatsächlich niemanden, der mir vorschreibt, was ich für zielführend halte, oder nicht. Und wenn Sie abstreiten, dass irreführende Zahlen zur argumentativen Stützung einer These nicht für zielführend wären, können wir die Sachlichkeit dieser Diskussion und damit die gesamte Diskussion gleich ganz bleiben lassen.
a) Wenn Ihnen kein besseres, aber dafür ein anderes, systemd, sprich ein de-systemd, vorschwebt, schwebt Ihnen der obigen Diskussion folgend ein schlechteres vor.
Unzulässige Ableitung. Mir schwebt kein schlechteres systemd vor. Es ist für mich schlicht verzichtbar. Und mir aufgrund seines verdrängenden und infiltrierenden Charakters zunehmend suspekt.
b) Ich habe nicht behauptet, dass es keine Alternativen gäbe.
Und ich habe nicht behauptet, dass Sie behauptet hätten, dass es keine Alternativen gäbe.
Ich habe mich auf Ihre Aussage
"Ihnen schwebt ja offensichtlich ein besseres systemd bzw. eine Alternative zu systemd vor, wenn ich das recht interpretiere."
bezogen und zum Ausdruck gebracht, dass mir eine Alternative nicht "vorschweben" muss, da es sie bereits gibt.
Ich habe Ihnen nahegelegt, dass Sie anscheinend weder zu systemd noch zu einer der Alternativen maßgeblich beigetragen haben, sodass diese Ihren Vorstellungen von OSS entsprechen.
Sie versuchen, sich mit einer Ihrer geschmeidigen Uminterpretationen aus der Affaire zu ziehen.
Meine Aussage: "Da habe ich dann doch andere Vorstellungen von Vielfalt und Open Source."
Ihre anmaßend-belehrende Aufforderung: "Dann müssen Sie beitragen! Das ist eben Open Source."
Was Sie damit "nahelegen" wollten, ist doch wohl eindeutig.
c) Dass Sie Alternativen nutzen, ist doch prima.
Das ist weder "prima" noch nicht-prima. Es ist einfach so.
Lassen Sie dafür bitte andere systemd nutzen oder entwickeln.
Da braucht es keine Bitte, denn damit habe ich kein Problem. Ich habe hier auch keine Aussage gemacht, die das im Entferntesten nahelegen würde.
Wer hier aber ganz offensichtlich ein Problem damit hat, andere Sichtweisen und Meinungen als die eigene überhaupt zuzulassen, sind *Sie*.
Ich glaube schon, dass ich das richtig interpretiert habe. Allerdings scheinen Sie meine Interpretation fehlinterpretiert zu haben. ;)
Es dürfte Ihnen mittlerweile klar sein, dass Sie auch hiermit falsch liegen.
a) Ist eine Aufforderung anmaßend, die die einzig logische Konsequenz, die sich aus der Diskrepanz des derzeitigen Zustands und Ihrer Vorstellungen von OSS ergeben?
Selbstverständlich. Und unverschämt dazu. Wenn sie nämlich aus einer Kritik an einer spezifischen Komponente eine allgemeine Forderung ableitet, die zudem ins Leere geht, da bereits erfüllt.
Und offenbar sind Sie der irrigen Ansicht, dass man nur das kritisieren dürfe, wozu man auch beigetragen hat.
b) Von systemd ist in diesem Kontext sehr wohl die Rede. [...]
Ihre Aufforderung war eindeutig allgemeiner Art, siehe oben.
Ja, sehr wahrscheinlich. Aber inwiefern ist das für diese Diskussion relevant?
Inwiefern muss es das sein? Ich wollte nur sicherstellen, dass es da keine Missverständnisse gibt.
a) Ja, ich hatte Sie nach einem Grund für Beiträge zu besagten Projekten gefragt,[...]
Ihre Aufforderung an mich, "beizutragen", war allgemeiner Art und so habe ich dann auch Ihre Frage nach einem Grund für Sie, beizutragen, verstanden.
Dass Sie suggerieren, ich bräuchte jemanden, der mir sagt, was ich zu tun hätte, grenzt an ein ad hominem.
Ihre eigene Aussage hat das suggeriert. Nebenbei: Ihr "ad hominem!"-Gekreische wird langsam langweilig.
Auf Pro-Linux missverstanden zu werden, zählt meiner Erfahrung nach fast schon zur Norm.
Für Sie vielleicht. Ich kann da nicht für andere sprechen, aber ich fühle mich meistens *nicht* missverstanden. Ich würde auch nicht von einer Norm sprechen. Ich stelle allerdings bei Ihnen eine sehr aggressive Haltung gegenüber Forumsteilnehmern fest, die eine andere Meinung vertreten als Sie. Vielleicht kommen die Sie betreffenden Missverständnisse ja daher.
Dass ich mich dafür rechtfertigen muss, ausführlicher zu schreiben, als es Ihnen nötig erscheint, ist ebenfalls absurd.
Das müssen Sie doch gar nicht. Ich habe Sie dazu auch nicht aufgefordert.
Wenn Sie an meiner Form etwas auszusetzen haben, bitteschön. Das hilft Ihrer Argumentation aber auch nicht gerade weiter.
Meine Argumentation braucht auch keine Hilfe. Die spricht für sich.
a) Hier sind zwei Beiträge mit irreführenden Zahlen, die aus Ihrer Feder stammen.
Mein Güte! Billiger geht's wohl nicht?
b) Sie haben gar keine Quelle genannt, denn Ihre Quellenangabe ist kaputt.
Und wenn Sie abstreiten, dass irreführende Zahlen zur argumentativen Stützung einer These [...]
Bla, bla. Ich hatte Sie aufgefordert, einen nicht-widerlegbaren Beweis aus einer *neutralen* Quelle beizubringen. Denn *das* wäre "zielführend" gewesen. Statt dessen nur wieder heiße Luft und verbale Nebelschwaden. Das ist wirklich unfruchtbar.
Mit diesem Argument wäre bereits Linux selbst ein "Monopol", denn systemd ist wie Linux nur eine weitere Hardwareabstraktionsschicht für Entwickler und Anwender. Da haben sich auch alle auf einen de-facto Standard per Mitgliedschaft an der Linux Foundation beteiligt.
Warum legen Sie also diesen Maßstab an systemd an, aber nicht an den Kernel? Der beinhaltet sogar noch viel mehr Quelltextzeilen. Oder verteufeln Sie den Linux-Kernel in gleicher Weise?
Und vor systemd gab es nach diesem Argument also ein "Monopol" durch sysvinit, oder wie? Das ergibt doch hinten und vorne keinen Sinn?
Die meisten, mir bekannten Alternativen, waren Erweiterungen von SysV wie etwa openRC, die keine technisch grundlegend veränderten Konzepte in SysV ersetzt haben. Das lässt die Krücke mittelfristig länger halten, aber verhindert nicht, dass sie irgendwann doch unter der Last und Komplexität neuer Anwendungsfälle zerbricht. Diese Lücke hat systemd gefüllt. Für alle bisherigen Anwendungsfälle bleiben die Auswahlmöglichkeiten bestehen. Keiner zwingt Sie, systemd zu nutzen.
Lennart hat bestätigt (via), dass die Zahlen bzgl. systemd von Phoronix, verbreitet durch TheRegister und nixCraft, irreführend sind.
Und Dr. Marlboro sagt: "Rauchen ist gut für die Gesundheit". Also bitte...
Das soll jetzt ernsthaft Ihr Argument sein? Lennart sagt an der Stelle ja nicht, dass systemd gut wäre, sondern gibt einen Fakt wieder. Warum sollte er einen leicht prüfbaren Fakt fälschen oder schönen, wenn sich dadurch nur noch unglaubwürdiger machen würde als er aus Ihrer Sicht offenbar ohnehin schon ist? Das ergibt doch keinen Sinn. Was kommt als Nächstes? Stellen Sie die Herstellerangaben für einen Stapel DINA4-Blätter infrage?
Also bitte zählen Sie doch selbst nach, wenn Sie vier unabhängigen Quellen (OpenHub, Coverity, Lennart, ich - siehe meine Verweise und deren Verweise) schon keinen Glauben schenken. Danke Und falls Sie noch eine weitere brauchen, bitteschön.
Machen Sie sich doch nicht lächerlich!
Gehen wir doch spaßeshalber mal von der Mitte aus: (1200 + 500) / 2 = 850 K LOC.
Wieso? Spaßenshalber? Wenn Sie das zum Spaß machen, ist Ihre Argumentation nicht ernst gemeint. Daran habe ich kein Interesse. Wie wäre es mit Sachlichkeit?
Erscheint mir immer noch etwas übertrieben, um ein System hoch und wieder runter zu fahren.
Ganz korrekt, denn hätten Sie die Argumente gelesen, auf die ich verwiesen hatte, wüssten Sie, dass im Quelltextverzeichnis von systemd noch eine Menge Quelltext versteckt ist, der nicht dem Hoch- oder Herunterfahren des Systems dient. Da sind noch viele andere und je nach Einsatzzweck nützliche und weniger nützliche Features und Komponenten enthalten.
Aber wie viele LOC auch immer: systemd hat mit einem init-System nicht mehr viel zu tun, sondern wird immer mehr zu einer Steuerzentrale entwickelt
Es folgt einem anderen Entwurfskonzept und betrachtet viele Anwendungsfälle, die sich nach Entstehung von SysV in der IT-Welt entwickelt und ergeben haben, und sich teilweise einfach nicht mehr sinnvoll auf SysV abbilden lassen. Daher folgt es einem erweiterten, ganzheitlicheren Ansatz, der übrigens nicht so neu ist. Wesentliche Ideen wurden kurzerhand von launchd (MacOS) und SMF (Solaris) geklaut. Damit waren bereits wesentliche Teile von systemd schon üblicher Stand der Technik.
Meiner Meinung nach war von Beginn an klar, dass systemd mehr als nur ein klassisches Init-System sein würde. Viele Komponenten sind weiterhin rein optional. Und bezüglich des Artikelthemas: rsyslogd etc. können weiterhin wie gewohnt und ohne signifikante Einschränkungen genutzt werden.
Für mich ist das Kompetenzüberschreitung.
Nun, das kann man gerne als solche werten - allerdings nicht mit irreführenden Zahlen über systemd. Die Frage dabei wäre allerdings wessen Kompetenz hier überschritten wurde? Hieße das nicht implizt, dass anderen Teile derer Kompetenzen vereinnahmt wurden? Falls ja, wessen? In einem Kompetenzvakuum gibt es meiner Meinung nach keine Kompetenzüberschreitung. Es gibt unter Linux derzeit keine Alternativen, die alle Anwendungsfälle und Funktionen von systemd technisch sauber abbilden können. SysV schafft das entwurfsbedingt nicht. Deshalb auch openRC, runit, s6, nosh, Upstart und wie sie alle heißen. Upstart wurde vom Hauptentwickler selbst als technisch Krücke ggü. den von systemd bei lanuchd und SMF geklauten Konzepten bezeichnet.
Aber bitte - wer's mag...
... darf weiterhin frei entscheiden, was er nutzen möchte und dann nutzen. Insofern: dito
Nur zum Vergleich: Je nach Zählweise kommt ein SysVinit kommt allein mit einem minimalen Satz an Initskripten auf etwa 8,5k Zeilen Quelltext ohne Kommentare oder Leerzeilen, und die nötige bash kommt (ohne Abhängigkeiten) bereits auf etwa 22,5k, falls die Zahlen dort stimmen. Das liegt in der selben Größenordnung wie systemd mit etwa 385k Zeilen Quelltext, die ich auf Version 242 gemessen hatte (hier stehen inzwischen 522k). Und da ist eine Normalisierung auf der Grundlage des unterschiedlichen Funktionsumfang nicht einbezogen.
Na, dann finde ich, immer her mit Systemd! Bekommt man endlich ein schlankes Linux, allein schon, weil man braucht ja keine Bash mehr.
Nee, ernsthaft: Was mich wirklich stört, diese ollen Protokolle. Ich würde den Krempel auch gerne weiterhin ohne Verrenkungen lesen können.
Bezüglich Ihrer Hervorhebung der Zitierung meines obigen Textes: Ich hatte mich an dieser Stelle leider vertippt, wie der entsprechende Verweis an dieser Stelle auch vermuten ließe. Es waren 225k Zeilen Quelltext ohne Kommentare oder Leerzeilen gemeint. Mein Fehler tut mir leid.
Welche "ollen Protokolle" denn? Was wollen Sie "ohne Verrenkungen lesen können"? Und welche "Verrenkungen" meinen Sie genau? Was konnten Sie vorher, d.h. ohne oder vor systemd, "ohne Verrenkung" lesen, was Sie nun, d.h. mit oder seit systemd, nur noch mit "Verrenkungen lesen können"? Warum bleiben Sie nicht bei den Alternativen? Wer bindet Sie an systemd?
der grosse Vorteil von Shell Skripten ist aber: ich kann sie von Hand starten, modifizieren und/oder ein 'set -x' reinschreiben und sehe Zeile fuer Zeile was passiert.
Das Erste ist definitiv kürzer. Dafür ist das Zweite wesentlich lesbarer für den Menschen, da weniger kryptisch. Es werden längere Namen für Optionen und targets verwendet, die ihre Bedeutungen besser beschreiben. Eine Beschreibung des inittab-Eintrag wie die der "Unit" fehlt im ersten Beispiel. Wären die Namen kürzer und alles in einer Zeile, wäre es in etwa die gleiche Länge. Jedenfalls wäre der Unterschied nicht signifikant.
Und was passiert im ersten Beispiel, falls der Prozess forkt? (SSH forkt meines Wissens nach bei der Authentifizierung) Kann er dann sauber neugestartet werden oder hält man dann (fast) alle Einzelteile und Überbleibsel in den Händen? Was passiert beim Suspend beider Varianten?
Demnach finde ich das Beispiel nicht wirklich treffend.
Glückwunsch, du hast einen der wenigen Fälle gefunden, wo die Shellvariante tatsächlich kürzer ist, allerdings ist das auch kein klassisches Initskript, sondern eine Konfiguration in der Inittab. Die einfachsten Initskripte sind in der Regel deutlich länger als die entsprechenden Unit-Files und oft nicht sehr gut lesbar.
Systemd ist außerdem mehr als nur eine Initsystem, es überwacht die Services auch und reagiert wenn einer davon stirbt. Das ist in Sys-V-Init z.B. gar nicht vorgesehen. Man kann natürlich streiten, ob man das will oder nicht. Ich finde den Ansatz sehr gut und sinnvoll, auch wenn der nicht neu, sondern von MacOS und Windows abgeguckt ist.
Sie haben leider das Argument vergessen und direkt mit der Schlussfolgerung angefangen!
Bitte ergänzen Sie doch noch das "Weshalb". Danke.
KISS keep it simple, stupid
Das heißt alles und nichts. Kann jeder interpretieren, wie er will. Somit als Argument ohne weitere Ausführung wertlos.
Hier mal ein Vergleich zwischen
SysVInit-Skript für cron:
und
systemd-Unit für cron
Quelle
Ich würde sagen, es ist offensichtlich, das die systemd-Unit viel einfacher ist.
Somit erfüllt systemd das KISS-Prinzip besser als SysVInit.
Q.E.D.
Wobei das noch nicht mal der ganze Code ist, der für SysVInit benötigt wird. Einerseits wäre das /lib/lsb/init-functions, das eingebunden wird, dann wird in cron selbst (bzw. im jeweiligen Daemon) noch viel Boilerplate benötigt.
Was genau hat ein Init-Skript für Cron jetzt mit der Einfachheit von einem Syslog-Dienst zu tun?
Es ist ein Beispiel, wie man "KISS" interpretieren kann. Die systemd-Unit ist einfacher.
Es geht mir nicht darum, was tatsächlich besser oder einfacher ist, sondern um die defekte Argumentation meines Vorposters.
[1] systemd-mehr-als-1,2-millionen-zeilen-code
Einwand:
Ich kam bisher auf andere Zahlen, wie ich unter einschlägigen Artikeln auf Pro-Linux bereits kommentierte (je nach Zählweise ca. 500k Zeilen). Siehe als Gegenargumente etwa die Punkte 2-4 & 9 hier, sowie die darin erwähnten Verweise.
Lennart hat bestätigt (via), dass die Zahlen bzgl. systemd von Phoronix, verbreitet durch TheRegister und nixCraft, irreführend sind. Lennart kam mittels sloccount selbst auf 454k Zeilen. Der Autor von nixCraft hat in der Diskussion mit Lennart auch zugegeben, dass der die Zahlen hätte prüfen sollen, bevor er das so weiterverbreitet.
Nur zum Vergleich: Je nach Zählweise kommt ein SysVinit kommt allein mit einem minimalen Satz an Initskripten auf etwa 8,5k Zeilen Quelltext ohne Kommentare oder Leerzeilen, und die nötige bash kommt (ohne Abhängigkeiten) bereits auf etwa 22,5k, falls die Zahlen dort stimmen. Das liegt in der selben Größenordnung wie systemd mit etwa 385k Zeilen Quelltext, die ich auf Version 242 gemessen hatte (hier stehen inzwischen 522k). Und da ist eine Normalisierung auf der Grundlage des unterschiedlichen Funktionsumfang nicht einbezogen.
Und Dr. Marlboro sagt: "Rauchen ist gut für die Gesundheit". Also bitte...
Gehen wir doch spaßeshalber mal von der Mitte aus: (1200 + 500) / 2 = 850 K LOC. Erscheint mir immer noch etwas übertrieben, um ein System hoch und wieder runter zu fahren.
Aber wie viele LOC auch immer: systemd hat mit einem init-System nicht mehr viel zu tun, sondern wird immer mehr zu einer Steuerzentrale entwickelt. Für mich ist das Kompetenzüberschreitung.
Aber bitte - wer's mag...
Deshalb ist das Argument "systemd hat sooo viel Code, nur um das System zu starten und zu stoppen" ja auch falsch.
Das Argument "systemd ist ein monolithisches Monster" aber auch - denn das ist alles fein säuberlich in verschiedene daemons und Tools aufgegliedert.
Aber ja, systemd ist eine Linux-Middleware.
Man kann das gut oder schlecht finden, es sorgt halt für eine Standardisierung und wird offensichtlich von vielen Entwicklern von Userspace-Software gut angenommen.
Und genau so entstehen Monopole - man entwickelt nur noch für einen Standard. Windows/MS Office lassen grüßen.
Das systemd freie Software ist und der Code sowie alle Schnittstellen komplett offen dokumentiert, lässt Du bei diesem Vergleich aber lieber elegant unter den Tisch fallen?!
Man könnte durchaus Alternativen zu systemd bereitstellen, die der Anwendungssoftware nur vortäuschen, das systemd-Services vorhanden sind. Soweit ich weiß, gibt es da auch Ansätze dazu, meine das gelesen zu haben. Systemd nutzt halt alle möglichen Features des Linux-Kernels und stellt einheitliche Services bereit. Wer kann es verdenken, das dies auch angenommen wird?
Na, und? Was nutzt das, wenn ohne systemd nichts mehr geht? Und wer soll bei der ausufernden Komplexität da überhaupt noch durchblicken? Der "systemd-Beauftragte"?
Ja, toll! Soweit sind wir also schon: tricksen und täuschen, damit eine Anwendung ohne systemd überhaupt noch läuft. Da habe ich dann doch andere Vorstellungen von Vielfalt und Open Source.
Sie haben mich ganz allgemein aufgefordert beizutragen, was ziemlich anmaßend ist. Von systemd war da nicht die Rede.
Und nicht nur das.Wie? *Ich* soll *Ihnen* einen Grund geben beizutragen? Sind Sie noch ganz bei Bewusstsein? Oder brauchen Sie wirklich jemanden, der Ihnen sagt, was Sie tun sollen? Absurd.
Besser missverstanden werden, als *nicht* gelesen zu werden. Eventuelle Missverständnisse können ggf. ausgeräumt werden."Beiträge" - gleich mehrere? Welche denn? Na?Zu "falsche Zahlen": Ich habe in meinem Beitrag jedenfalls eine neutrale Quelle genannt. Das reicht normalerweise. Haben *Sie* denn einen nicht widerlegbaren Beweis aus *neutraler* Quelle für Ihre Behauptung?
Und was "zielführend" ist und was nicht, entscheiden im Übrigen nicht Sie.
zu Zitat 1:
a) Wenn Ihnen kein besseres, aber dafür ein anderes, systemd, sprich ein de-systemd, vorschwebt, schwebt Ihnen der obigen Diskussion folgend ein schlechteres vor. Was "besser" und "schlechter" in diesem Kontext bedeutet, ist dabei noch nicht näher erwähnt.
b) Ich habe nicht behauptet, dass es keine Alternativen gäbe. Ich habe Ihnen nahegelegt, dass Sie anscheinend weder zu systemd noch zu einer der Alternativen maßgeblich beigetragen haben, sodass diese Ihren Vorstellungen von OSS entsprechen.
c) Dass Sie Alternativen nutzen, ist doch prima. Lassen Sie dafür bitte andere systemd nutzen oder entwickeln. Jedem das Seine...
zu Zitat 2:
Ich glaube schon, dass ich das richtig interpretiert habe. Allerdings scheinen Sie meine Interpretation fehlinterpretiert zu haben.
zu Zitat 3:
a) Ist eine Aufforderung anmaßend, die die einzig logische Konsequenz, die sich aus der Diskrepanz des derzeitigen Zustands und Ihrer Vorstellungen von OSS ergeben?
b) Von systemd ist in diesem Kontext sehr wohl die Rede. Die Software ist zentraler Bestandteil des Inhalts des kommentierten Artikels und der gesamten Diskussion, die Sie, ich und andere führ(t)en. Sie bezogen sich an jener Stelle doch auf eine zwei Sätze zuvor zitierte Aussage von "Nur ein Leser" über Alternativen zu systemd und Ideen zur Implementierung von Schnittstellen, die systemd simulieren/emulieren. Dass an dieser Stelle nicht auch die Rede von systemd gewesen sein soll, kann ich demnach nicht nachvollziehen.
zu Zitat 4:
Ja, sehr wahrscheinlich. Aber inwiefern ist das für diese Diskussion relevant?
zu Zitat 5:
a) Ja, ich hatte Sie nach einem Grund für Beiträge zu besagten Projekten gefragt, weil Sie mich nach meinen Beiträgen fragten. Ich habe im Gegensatz zu Ihnen keine Änderungswünsche oder Verbesserungsvorschläge für das systemd-Projekt oder anderen init-Projekten. Welchen Grund beizutragen, sollte ich also haben können?
Wenn Sie diese Logik nicht verstehen, weiß ich auch nicht mehr weiter. Das ist auch, was ich in Zitat 4 schrieb.
b) Dass Sie suggerieren, ich bräuchte jemanden, der mir sagt, was ich zu tun hätte, grenzt an ein ad hominem. Das ist noch mehrere Größenordnungen anmaßender und absurder, als das was ich Ihrer Meinung nach verbrochen haben soll.
zu Zitat 6:
Auf Pro-Linux missverstanden zu werden, zählt meiner Erfahrung nach fast schon zur Norm. Deshalb gehe ich lieber auf Nummer sicher, wenn ich es denn schon tue. Dass ich mich dafür rechtfertigen muss, ausführlicher zu schreiben, als es Ihnen nötig erscheint, ist ebenfalls absurd. Wenn Sie an meiner Form etwas auszusetzen haben, bitteschön. Das hilft Ihrer Argumentation aber auch nicht gerade weiter.
zu Zitat 7:
a) Hier sind zwei Beiträge mit irreführenden Zahlen, die aus Ihrer Feder stammen.
Ersterer Kommentar ist noch zu entschuldigen, da Sie lediglich durch die mediale Clickbait-Masche verführt wurden, diese Zahlen als gegeben anzusehen. Dass das überhaupt so veröffentlicht wurde und bisher nicht korrigiert wurde, ist meiner Meinung nach eine riesige Schweinerei und sagt viel über diese Portale aus. Selbst Pro-Linux hat es nicht korrigiert. Ich hoffe, dass dies den Lesern meiner Kommentare eine Lehre ist, nicht alles ungeprüft zu glauben, was drei Mal retweetet wurde.
Dass Sie die selbe Zahl im zweiten Kommentar erneut verwenden, um Ihre Thesen zu stützen, ist jedoch nicht mehr zu entschuldigen, nachdem ich Sie darauf hingewiesen habe, dass diese nicht korrekt wären.
b) Sie haben gar keine Quelle genannt, denn Ihre Quellenangabe ist kaputt. Die ursprüngliche Quelle ist meines Wissens nach Phoronix. Darauf bezogen sich alle mir bekannten Meldungen darüber. Phoronix ist für Clickbait und billige Meldungen bekannt. Die Benchmarks sind in großen Teilen auch nicht besonders aussagekräftig.
c) Falls ich nicht entscheide, was an dieser Stelle zielführend ist, und was nicht, dann entscheidet es keiner oder bestenfalls noch die Redaktion. Ich brauche tatsächlich niemanden, der mir vorschreibt, was ich für zielführend halte, oder nicht.
Und wenn Sie abstreiten, dass irreführende Zahlen zur argumentativen Stützung einer These nicht für zielführend wären, können wir die Sachlichkeit dieser Diskussion und damit die gesamte Diskussion gleich ganz bleiben lassen.
Unzulässige Ableitung. Mir schwebt kein schlechteres systemd vor. Es ist für mich schlicht verzichtbar. Und mir aufgrund seines verdrängenden und infiltrierenden Charakters zunehmend suspekt.
Und ich habe nicht behauptet, dass Sie behauptet hätten, dass es keine Alternativen gäbe.
Ich habe mich auf Ihre Aussage
"Ihnen schwebt ja offensichtlich ein besseres systemd bzw. eine Alternative zu systemd vor, wenn ich das recht interpretiere."
bezogen und zum Ausdruck gebracht, dass mir eine Alternative nicht "vorschweben" muss, da es sie bereits gibt.
Sie versuchen, sich mit einer Ihrer geschmeidigen Uminterpretationen aus der Affaire zu ziehen.
Meine Aussage:
"Da habe ich dann doch andere Vorstellungen von Vielfalt und Open Source."
Ihre anmaßend-belehrende Aufforderung:
"Dann müssen Sie beitragen! Das ist eben Open Source."
Was Sie damit "nahelegen" wollten, ist doch wohl eindeutig.
Das ist weder "prima" noch nicht-prima. Es ist einfach so.Da braucht es keine Bitte, denn damit habe ich kein Problem. Ich habe hier auch keine Aussage gemacht, die das im Entferntesten nahelegen würde.Wer hier aber ganz offensichtlich ein Problem damit hat, andere Sichtweisen und Meinungen als die eigene überhaupt zuzulassen, sind *Sie*.
Es dürfte Ihnen mittlerweile klar sein, dass Sie auch hiermit falsch liegen.Und offenbar sind Sie der irrigen Ansicht, dass man nur das kritisieren dürfe, wozu man auch beigetragen hat.
Ihre Aufforderung war eindeutig allgemeiner Art, siehe oben.Inwiefern muss es das sein? Ich wollte nur sicherstellen, dass es da keine Missverständnisse gibt.Ihre Aufforderung an mich, "beizutragen", war allgemeiner Art und so habe ich dann auch Ihre Frage nach einem Grund für Sie, beizutragen, verstanden.Ihre eigene Aussage hat das suggeriert. Nebenbei: Ihr "ad hominem!"-Gekreische wird langsam langweilig.Für Sie vielleicht. Ich kann da nicht für andere sprechen, aber ich fühle mich meistens *nicht* missverstanden. Ich würde auch nicht von einer Norm sprechen. Ich stelle allerdings bei Ihnen eine sehr aggressive Haltung gegenüber Forumsteilnehmern fest, die eine andere Meinung vertreten als Sie. Vielleicht kommen die Sie betreffenden Missverständnisse ja daher.Das müssen Sie doch gar nicht. Ich habe Sie dazu auch nicht aufgefordert.Meine Argumentation braucht auch keine Hilfe. Die spricht für sich.Mein Güte! Billiger geht's wohl nicht?Tatsächlich. Ein technischer Fehler. Mea maxima culpa!Hier also noch mal: Systemd: Mehr als 1,2 Millionen Zeilen CodeBla, bla. Ich hatte Sie aufgefordert, einen nicht-widerlegbaren Beweis aus einer *neutralen* Quelle beizubringen. Denn *das* wäre "zielführend" gewesen. Statt dessen nur wieder heiße Luft und verbale Nebelschwaden. Das ist wirklich unfruchtbar.
Mit diesem Argument wäre bereits Linux selbst ein "Monopol", denn systemd ist wie Linux nur eine weitere Hardwareabstraktionsschicht für Entwickler und Anwender. Da haben sich auch alle auf einen de-facto Standard per Mitgliedschaft an der Linux Foundation beteiligt.
Warum legen Sie also diesen Maßstab an systemd an, aber nicht an den Kernel? Der beinhaltet sogar noch viel mehr Quelltextzeilen. Oder verteufeln Sie den Linux-Kernel in gleicher Weise?
Und vor systemd gab es nach diesem Argument also ein "Monopol" durch sysvinit, oder wie? Das ergibt doch hinten und vorne keinen Sinn?
Die meisten, mir bekannten Alternativen, waren Erweiterungen von SysV wie etwa openRC, die keine technisch grundlegend veränderten Konzepte in SysV ersetzt haben. Das lässt die Krücke mittelfristig länger halten, aber verhindert nicht, dass sie irgendwann doch unter der Last und Komplexität neuer Anwendungsfälle zerbricht. Diese Lücke hat systemd gefüllt.
Für alle bisherigen Anwendungsfälle bleiben die Auswahlmöglichkeiten bestehen. Keiner zwingt Sie, systemd zu nutzen.
Danke sehr. Gerade die ersten beiden Abschnitte deines Kommentares bringen es auf den Punkt.
Also bitte zählen Sie doch selbst nach, wenn Sie vier unabhängigen Quellen (OpenHub, Coverity, Lennart, ich - siehe meine Verweise und deren Verweise) schon keinen Glauben schenken. Danke
Und falls Sie noch eine weitere brauchen, bitteschön.
Machen Sie sich doch nicht lächerlich!
Wieso? Spaßenshalber? Wenn Sie das zum Spaß machen, ist Ihre Argumentation nicht ernst gemeint. Daran habe ich kein Interesse. Wie wäre es mit Sachlichkeit?Ganz korrekt, denn hätten Sie die Argumente gelesen, auf die ich verwiesen hatte, wüssten Sie, dass im Quelltextverzeichnis von systemd noch eine Menge Quelltext versteckt ist, der nicht dem Hoch- oder Herunterfahren des Systems dient. Da sind noch viele andere und je nach Einsatzzweck nützliche und weniger nützliche Features und Komponenten enthalten.Es folgt einem anderen Entwurfskonzept und betrachtet viele Anwendungsfälle, die sich nach Entstehung von SysV in der IT-Welt entwickelt und ergeben haben, und sich teilweise einfach nicht mehr sinnvoll auf SysV abbilden lassen. Daher folgt es einem erweiterten, ganzheitlicheren Ansatz, der übrigens nicht so neu ist. Wesentliche Ideen wurden kurzerhand von launchd (MacOS) und SMF (Solaris) geklaut. Damit waren bereits wesentliche Teile von systemd schon üblicher Stand der Technik.Meiner Meinung nach war von Beginn an klar, dass systemd mehr als nur ein klassisches Init-System sein würde. Viele Komponenten sind weiterhin rein optional. Und bezüglich des Artikelthemas: rsyslogd etc. können weiterhin wie gewohnt und ohne signifikante Einschränkungen genutzt werden.
Nun, das kann man gerne als solche werten - allerdings nicht mit irreführenden Zahlen über systemd.Die Frage dabei wäre allerdings wessen Kompetenz hier überschritten wurde? Hieße das nicht implizt, dass anderen Teile derer Kompetenzen vereinnahmt wurden? Falls ja, wessen? In einem Kompetenzvakuum gibt es meiner Meinung nach keine Kompetenzüberschreitung. Es gibt unter Linux derzeit keine Alternativen, die alle Anwendungsfälle und Funktionen von systemd technisch sauber abbilden können. SysV schafft das entwurfsbedingt nicht. Deshalb auch openRC, runit, s6, nosh, Upstart und wie sie alle heißen. Upstart wurde vom Hauptentwickler selbst als technisch Krücke ggü. den von systemd bei lanuchd und SMF geklauten Konzepten bezeichnet.... darf weiterhin frei entscheiden, was er nutzen möchte und dann nutzen. Insofern: dito
Na, dann finde ich, immer her mit Systemd!
Bekommt man endlich ein schlankes Linux, allein schon, weil man braucht ja keine Bash mehr.
Nee, ernsthaft: Was mich wirklich stört, diese ollen Protokolle. Ich würde den Krempel auch gerne weiterhin ohne Verrenkungen lesen können.
Bezüglich Ihrer Hervorhebung der Zitierung meines obigen Textes:
Ich hatte mich an dieser Stelle leider vertippt, wie der entsprechende Verweis an dieser Stelle auch vermuten ließe. Es waren 225k Zeilen Quelltext ohne Kommentare oder Leerzeilen gemeint. Mein Fehler tut mir leid.
Welche "ollen Protokolle" denn? Was wollen Sie "ohne Verrenkungen lesen können"? Und welche "Verrenkungen" meinen Sie genau? Was konnten Sie vorher, d.h. ohne oder vor systemd, "ohne Verrenkung" lesen, was Sie nun, d.h. mit oder seit systemd, nur noch mit "Verrenkungen lesen können"? Warum bleiben Sie nicht bei den Alternativen? Wer bindet Sie an systemd?
hier ein anderer Vergleich:
Wir bauen per ssh einen Rueckwartstunnel auf, einmal per init (inittab) :
vp:235:respawn:/usr/bin/ssh -NTR1234:127.0.0.1:22 user@host 2>/dev/null
und jetzt das Gleiche mit systemd als service :
[Unit]
Description=reverse-vpn
After=network-online.target
[Service]
ExecStart=/usr/bin/ssh -NTR1234:127.0.0.1:22 user@host >/dev/null 2>&1
Restart=always
RestartSec=1min
StartLimitAction=reboot
[Install]
WantedBy=multi-user.target
--------
na, was ist kuerzer ?
der grosse Vorteil von Shell Skripten ist aber: ich kann sie von Hand starten, modifizieren und/oder ein 'set -x' reinschreiben und sehe Zeile fuer Zeile was passiert.
Das Erste ist definitiv kürzer. Dafür ist das Zweite wesentlich lesbarer für den Menschen, da weniger kryptisch. Es werden längere Namen für Optionen und targets verwendet, die ihre Bedeutungen besser beschreiben. Eine Beschreibung des inittab-Eintrag wie die der "Unit" fehlt im ersten Beispiel. Wären die Namen kürzer und alles in einer Zeile, wäre es in etwa die gleiche Länge. Jedenfalls wäre der Unterschied nicht signifikant.
Und was passiert im ersten Beispiel, falls der Prozess forkt? (SSH forkt meines Wissens nach bei der Authentifizierung)
Kann er dann sauber neugestartet werden oder hält man dann (fast) alle Einzelteile und Überbleibsel in den Händen? Was passiert beim Suspend beider Varianten?
Demnach finde ich das Beispiel nicht wirklich treffend.
Man kann systemd-Units auch von Hand starten, modifizieren und es gibt sogar eine Debug-Shell.
Glückwunsch, du hast einen der wenigen Fälle gefunden, wo die Shellvariante tatsächlich kürzer ist, allerdings ist das auch kein klassisches Initskript, sondern eine Konfiguration in der Inittab. Die einfachsten Initskripte sind in der Regel deutlich länger als die entsprechenden Unit-Files und oft nicht sehr gut lesbar.
Systemd ist außerdem mehr als nur eine Initsystem, es überwacht die Services auch und reagiert wenn einer davon stirbt. Das ist in Sys-V-Init z.B. gar nicht vorgesehen. Man kann natürlich streiten, ob man das will oder nicht. Ich finde den Ansatz sehr gut und sinnvoll, auch wenn der nicht neu, sondern von MacOS und Windows abgeguckt ist.