Diskussion:Systemd

Verstehbare Sätze

Jemand möge

Grundlegendes Konzept dafür ist, weitgehend alle Prozesse gleichzeitig zu starten – ohne die bei anderen zwar grundsätzlich auf Parallelisierung setzenden Systemen, die jedoch anhand der in einem Abhängigkeitsmodell erfassten wechselseitigen Abhängigkeiten der Prozesse immernoch mit teilweiser Serialisierung arbeiten.

in verstehbare Sätze zerlegen. --88.153.1.107 16:28, 25. Nov. 2010 (CET)

MacOS

Systemd ist zu großen Teilen von MacOS inspiriert --87.79.112.4 23:53, 27. Feb. 2012 (CET)

Das findet sich auch im Text:

Die Ideen und Konzepte zu systemd entstanden aus Poetterings kritischer Betrachtung aktuell gebräuchlicher init-Systeme wie Upstart und launchd, von denen es grundlegende Ideen übernimmt.

Launchd ist die von MacOS verwendete Software. --Mineo (Diskussion) 14:15, 11. Mär. 2012 (CET)

Distributionen

Weiss wer welche Distributionen derzeit systemd einsetzen? (nicht signierter Beitrag von 212.232.252.74 (Diskussion) 12:40, 12. Apr. 2012 (CEST))

Auf der Homepage gibt es eine Liste --Mineo (Diskussion) 15:42, 14. Apr. 2012 (CEST)

Kritikabschnitt

Könnte wenigstens hinzugefügt werden. Launchd zählt ähnliche Kritikpunkte auf.--95.91.62.194 21:38, 17. Mai 2012 (CEST)

Mageia

Was ist mit Mageia? --79.224.237.97 16:35, 17. Jul. 2012 (CEST)

Mit diesem Nieschenprodukt kennt sich hier niemand aus. --79.224.234.96 18:40, 31. Jul. 2012 (CEST)

Verbreitung von Upstart und Einfluss auf Systemd

"Sofern es das mittlerweile recht verbreitete Upstart nicht weitgehend ablöst, ist zumindest ein wesentlicher Einfluss der Ideen auf die Entwicklung von Upstart zu erwarten."

Wird nicht Upstart "nur" noch von Ubuntu (und basierenden Distributionen) verwendet? (Artikel auf ProLinux) Durch die Verbreitung von Ubuntu basierenden Distributionen, kann Upstart wohl als verbreitet gelten. Doch wird der Einfluss von Upstart auf Systemd wohl gesunken sein. Als nicht Entwickler kenne ich mich da jedoch schlecht aus. --Harrywiki (Diskussion) 18:04, 3. Jan. 2014 (CET)

Ich denke, der von dir zitierte Satz soll eher bedeuten, dass systemd die Entwicklung von Upstart durch neue Ideen beeinflusst, nicht umgekehrt. Inwiefern das aber zugetroffen hat bzw. noch zutrifft, kann ich nicht sagen, kann mich aber daran erinnern, dass die systemd-Entwickler mehrmals erwähnt haben, dass manche Ideen in systemd nicht auf Upstart anwendbar sind. --Mineo (Diskussion) 12:57, 4. Jan. 2014 (CET)

Die Ankündigung Mark Shuttleworths, Ubuntu mittelfristig ebenfalls Systemd nutzen zu lassen, sollte die Einstellung Upstarts in absehbarer Zeit bewirken und eine zukünftige Portierung von Funktionalität aus Systemd nach Upstart unwahrscheinlich machen. Sofern meine Einschätzung richtig sein sollte, plädiere ich für die Entfernung oder Umarbeitung des Abschnitts. Der Hinweis, in abgeänderter Form, wäre m. E. im Upstart Artikel besser aufgehoben. --Creaturo (Diskussion) 21:37, 15. Feb. 2014 (CET)

NPOV

Dieser Artikel ist eine einzige Lobhudelei, auf bestehende und z.T. durchaus berechtigte Kritik wird gar nicht eingegangen. Als Quelle für Kritik sei hier auf den englischen Artikel verwiesen und auf http://boycottsystemd.org/, wo sich sehr ausführlich mit den Problemen von systemd auseinandergesetzt wird. Grossergott (Diskussion) 21:19, 9. Okt. 2014 (CEST)

Hä-ähm! Die Boykottseite gibt's offenbar nicht mehr, und der Großteil der Kritiker bemängelt, dass systemd durch die Vielzahl an Aufgaben, die es zu erfüllen hat, die Unix-Philosophie verletzt: [1] H.i.K.: Das Fehlen dieser Informationen reicht nicht aus, um den Artikel für nicht neutral genug zu erklären. --Jacek79 (Diskussion) 15:50, 28. Feb. 2015 (CET)

Unified hierarchy cgroups - total unverständlich

Der Abschnitt "Unified hierarchy cgroups" ist total unverständlich mit zwei redlinks. Und ich verstehe Linux-Artikel noralerweise sehr gut. Entfernen, würde ich sagen, wenn ihn niemand bald verbessert. Kruemelmo (Diskussion) 21:05, 20. Okt. 2014 (CEST)

Ich war jetzt mal so frei und habe den (auch mir unverständlichen) Satz und das Bild entfernt. --Mineo (Diskussion) 11:26, 27. Apr. 2015 (CEST)

Kategorie: init-Dienst?

In der Infobox steht als Kategorie "init-Dienst". Das ist so nicht korrekt, da systemd einiges mehr umfasst als ein typisches init: Logging, Konfiguration der Netzwerkschnittstellen, Geräte-Management, Session-Management, Verwaltung von Zeit- und Lokalisierungseinstellungen uvm. Ein großer Teil der Kritik an systemd setzt genau da an, dass systemd eben nicht weiß was es sein will. Es werden Dinge eingebaut, für die ein init-Dienst nicht zuständig ist und für die es bereits frei austauschbare und ausgereifte Implementierungen gibt (z.B. Logging: metalog, syslog-ng…).

Ein alternativer Vorschlag für die Kategorie wäre vielleicht ganz allgemein "Systemsoftware", auch wenn das natürlich nicht viel aussagt – kann es aber dank der unklaren Zielsetzung von systemd auch nicht. --94.217.249.128 23:54, 17. Jan. 2015 (CET)

Der Artikel in seiner jetzigen Form beschreibt nur systemd das init-System und nicht systemd als Projekt, das Basis-funktionen für Linuxsysteme im Allgemeinen bereitstellen will (wenn man mal von dem einen Bild mit den Komponenten absieht). Der Artikel an sich müsste (imho) diesen Unterschied erstmal klarer machen, bevor man anfängt, an den Kategorien herumzuspielen. --Mineo (Diskussion)

Dazu muss wiederum zuerst geklärt werden, ob es systemd nur als init-Dienst alleine überhaupt gibt. Es gibt beispielsweise in einem init typischerweise keinen Systemlogger, (wie z.B. syslog-ng) wobei aber systemd nicht ohne seinen eigenen systemd-journald betrieben werden kann. Auch das Verwalten von Device-Nodes (was udev bzw. systemd-udev macht) ist jetzt nicht unbedingt etwas, was man üblicherweise in einem init-Dienst erwartet. Beide Aufgaben sind in einem klassischen init nicht zu finden, systemd reißt sie aber zwingend an sich. Somit kann systemd gar kein reiner init-Dienst sein. Der englische Artikel ist da erheblich präziser. --94.217.228.238 22:05, 4. Feb. 2015 (CET)

Das stimmt jetzt umso mehr, da systemd jetzt auch noch einen Bootloader mitbringen will. Die Versuchung wächst, die Kategorie einfach auf Eierlegende Wollmilchsau abzuändern. --94.217.244.243 19:45, 2. Feb. 2015 (CET)

Da ich gerade mit systemd gekämpft habe (systemctl start getty@ttyS4.service), kann ich dazu sagen, dass systemd als «Mutter aller Dämonen» deutlich mehr Features aufweist als das gute alte SysV-Init, aber keinesfalls als Eier legende Wollmilchsau durchgeht (und schon gar nicht als Bootloader, denn bevor systemd übernehmen kann, muss der Kernel aktiv sein). Womit wir bei Kapitel Kritik wären: Das Teil ist zu reich an Features. Näheres siehe das entsprechende Kapitel in Koflers Linux 2015. --Jacek79 (Diskussion) 15:42, 28. Feb. 2015 (CET)

Reich an Features, die in einem init-Dienst normalerweise nicht zu finden sind. systemd ist genausowenig ein init-Dienst wie KDE ein Terminal-Emulator oder ein Auto ein Motor ist. Vielmehr hat systemd neben vielen weiteren Komponenten halt auch einen init-Dienst – so wie KDE neben anderen Programmen eben auch einen Terminal-Emulator beinhaltet und ein Auto über einen Motor verfügt. --188.110.249.82 22:17, 20. Apr. 2015 (CEST)

Der Artikel ist insofern fehlerhaft, als dass systemd als ein reiner monolithischer blob verstanden wird, der vom UEFI geladen wird, dann eben nebenbei den Kernel hochzieht, alle Dienste initiiert, und dann so Kram wie dns und ntp erledigt. Das ist imho falsch. systemd ist tatsächlich eine Sammlung an verschiedenen tools die durchaus verzahnt sind, aber alle für sich stabil arbeiten können. Wenn dann bspw der ntp-client abstürzt, läuft das initsystem immer noch stabil und hält die anderen daemons am laufen. --Simonszu (Diskussion) 17:14, 25. Feb. 2017 (CET)

systemd!

@Nenntmichruhigip: Siehe systemd. Nur weil es im Weblink groß geschrieben wird, ist es dennoch nicht richtig! Soweit ich weiß, ist es in Wikipedia-Weblinks gar nicht möglich, den ersten Buchstaben der aufzurufenden Wikipediaseite klein zu schreiben. Aber um es zu verdeutlichen, zitiere ich die angegebene systemd-Seite:

"Spelling

Yes, it is written systemd, not system D or System D, or even SystemD. And it isn't system d either. Why? Because it's a system daemon, and under Unix/Linux those are in lower case, and get suffixed with a lower case d. And since systemd manages the system, it's called systemd. It's that simple. [...]"

Daher werde ich jetzt alle Einträge mit Systemd zu systemd ändern.

Dort wo es im Netz auch falsch steht, z. B., bei heise online, habe ich es nicht geändert. --Raumhafen (Diskussion) 01:45, 20. Jun. 2016 (CEST)

Du scheinst den Hinweis auf WP:RS#Marken (Anwendungsbeispiele: golem.de, Bada (Betriebssystem)) übersehen zu haben ;-) Ausserdem steht kurz hinter dem von dir zitierten, dass the only situation where [they] find it OK to use an uppercase letter in the name (but don't like it either) is if you start a sentence with systemd, was so exklusiv eher auf die englische Sprache bezogen sein dürfte, und es auf Deutsch dann wohl selbst danach auch als normales Substantiv grossgeschrieben sein darf. Zu "don't like it either": Der Spiegel würde bestimmt auch lieber durch Majuskelschrift auffallen, das ist also genau das, weshalb es WP:RS#Marken gibt.

Mit "Titel der Website" meinte ich nur die Titel bei den Weblinks, bei deiner letzten Änderung würde das den Golem-Link betreffen. OT: Klar kann MediaWiki kleingeschriebene Seitentitel. Auch wenn ich nicht weiss, wie du jetzt darauf kommst. --nenntmichruhigip (Diskussion) 10:09, 20. Jun. 2016 (CEST)

Ich sehe bei der Kleinschreibung keinen Widerspruch zu WP:RS#Marken: Zitat: "Ausnahmen von dieser Regel können in solchen Fällen gemacht werden, wo eine Anpassung verwirren würde oder wenn die unkonventionelle Schreibung eindeutig die üblichere ist und Wortverbindungen nicht stört (Beispiele: c’t, iTunes, LaTeX)." -- Michi 12:48, 20. Jun. 2016 (CEST)

Dass es in allen deutschsprachigen Weblinks und Einzelnachweise grossgeschrieben wird zeigt aber, dass es nicht "eindeutig die üblichere ist". Und "verwirrend" im Sinne von "schlechter lesbar" finde ich auch eher die Kleinschreibung, weil das dann beim Überfliegen wie ein nicht-Substantiv aussieht. Aber der "verwirren würde"-Teil scheint mir eh eher für Fälle gedacht zu sein, wo die Anpassung nach etwas völlig anderem wirken würde. --nenntmichruhigip (Diskussion) 15:11, 20. Jun. 2016 (CEST)

Nur weil es alle in Deutschland groß schreiben, heißt das doch nicht, dass es richtig ist, es groß zu schreiben. Der von mir zitierte Satz ist eindeutig. Gerade weil es richtig ist, es klein zu schreiben, sollten wir das hier auch zeigen. Fast im ganzen Artikel wird es korrekt geschrieben, also lasst es uns doch durchgehend korrekt schreiben. Aber ich habe schon hier gesehen, dass wir uns in einer Enzyklopädie nicht daran halten müssen. Jetzt weiß ich auch, warum der "Spiegel" hier angesprochen wird. Ich bin dennoch dafür, es einfach so zu schreiben, wie es richtig ist. Und dass es "systemd" heißt und auch so geschrieben wird, halte ich für eindeutig. --Raumhafen (Diskussion) 15:54, 20. Jun. 2016 (CEST)

Das ist eben der Unterschied zwischen Markenschreibweise und Rechtschreibung. "Richtig" ist beides auf seine Weise. Um mal den Duden zum Thema Binnenmajuskeln bei Markenschreibweise zu zitieren: In bestimmten Kontexten gebräuchlich, aber nicht Gegenstand der amtlichen Rechtschreibung […] Solche Schreibungen werden kontrovers diskutiert und für den allgemeinen Gebrauch meist abgelehnt. Ausserdem Substantive schreibt man groß. Das gilt auch für Namen. Oder anders gesagt: Richtig ist, dass es "systemd" heisst, im Text aber "Systemd" geschrieben wird. Oh, und doch: Wenn alle in Deutschland es groß schreiben wird es dadurch (zumindest in DE, ggf nicht in anderen deutschsprachigen Ländern) richtig. Auch wenn das bei manchen Schreibfehlern ziemlich doof ist… --nenntmichruhigip (Diskussion) 16:13, 20. Jun. 2016 (CEST)

Default-Nameserver

Im Oktober 2014 wurde festgestellt bzw. diskutiert, daß systemd, ohne daß ein Administrator eine solche Einstellung getroffen hatte, die Google-Nameserver als default verwendete. Diese Information wurde durch einen user aus dem Artikel gelöscht mit der Begründung, es sei nicht erwähnenswert. Es würde mich interessieren, welche Meinung dazu hier vertreten wird. Wenn FOSS per default und ohne Einstellung Daten an kommerzielle Anbieter weiterleitet - und noch dazu solche, die sich die Speicherung und kommerzielle Verwertung von Daten explizit vorbehalten - kann das wohl kaum belanglos sein. Debian Bug report logs - #761658; Please do not default to using Google nameservers --Matthiask de (Diskussion) 15:26, 23. Aug. 2016 (CEST)

Ist das überhaupt in systemd oder "nur" Debian-spezifisch? Schreint für mich letzteres zu sein. --nenntmichruhigip (Diskussion) 15:56, 23. Aug. 2016 (CEST)

ME erwähnenswert, sofern es immer noch default ist. Es gibt schließlich einen ganzen Artikel Kritik an Google Inc.. Falls das aber nur temporär default war, während der Entwicklungsphase, dann interessiert's mich nicht die Bohne. Falls es „nur“ Debian-spezifisch sei, dann kann das trotzdem hier erwähnt werden. Deb ist schließlich eine sehr häufig genutzte Distri.-- Kays (T | C) 09:02, 24. Aug. 2016 (CEST)

Imo würde es nur bei Debian erwähnt werden sollen, wenn es nur dort wäre. Ist ja nicht Systemds Fehler, wenn eine Distribution doofe Defaultwerte setzt. Die würde das bei einer Alternative zu Systemd wahrscheinlich auch machen. Aber das ist mit meinem untigen Beitrag jetzt wohl OT :-) --nenntmichruhigip (Diskussion) 10:33, 24. Aug. 2016 (CEST)

Kommt auch im Systemd-Repo vor. Hier der dortige Bugreport. Imo kann das also hier beschrieben werden, aber so, dass deutlich wird, dass es ein quasi nie verwendeter Wert ist. Und @Systemd: Wenn niemand (weder der Distributor, noch der Benutzer selbst, noch dhcpcd) einen Nameserver festlegt – was, wie ihr ja selbst sagt, quasi nie passiert –, würde ich erwarten, dass mit der daraus resultierenden Nameserverliste aufgelöst wird. Also alle Anfragen als nicht auffindbar beantwortet werden, weil's keinen Nameserver gibt. --nenntmichruhigip (Diskussion) 10:33, 24. Aug. 2016 (CEST)

Es ist demnach aktuell noch drin und auch nicht Debian-spezifisch. Dieser Fall tritt wohl dann ein, wenn eine Fehlkonfiguration vorliegt - und der Nutzer/Admin wird den Fehler wohl nicht bemerken, weil sein System ja funktioniert. Interessant wäre jetzt noch, was passiert, wenn der eigentlich konfigurierte Nameserver ausfällt. Fakt ist, diese Einrichtung bewirkt, daß vom Nutzer/Admin unbeabsichtigt Daten an Google geschickt werden, aus denen das Nutzerverhalten abgelesen werden kann. Ich setze daher den entsprechenden Passus wieder ein.--Matthiask de (Diskussion) 14:07, 24. Aug. 2016 (CEST)

Würdest du bitte einsehen, wie unwahrscheinlich es ist, dass kein DNS-Server eingestellt ist? Außerdem ist es ein Unterschied, ob Daten an Google Analytics oder an Googles DNS-Server geschickt werden, wo in den permanenten Logs keine personenbezogene Daten gespeichert werden.--kopiersperre (Diskussion) 15:02, 24. Aug. 2016 (CEST)

Es geht nicht um Wahrscheinlichkeiten, sondern darum, daß entsprechender Code vorhanden ist. Das bezieht sich auf die Arbeit der Programmierer und nicht auf die Geschäftstätigkeit von Google. Unterlasse bitte das Entfernen belegter Tatsachen.--Matthiask de (Diskussion) 15:08, 24. Aug. 2016 (CEST)

Du scheinst dich wohl ziemlich auf systemd eingeschossen zu haben. Außerdem hast du keinen Konsens herbeigeführt, sondern versuchst deine Privatmeinung durchzudrücken. Dass Google über DNS-Abfragen Daten sammelt ist ein konstruierter und unfairer Vorwurf. DNS-Protokollierung ist weit verbreitet.--kopiersperre (Diskussion) 15:24, 24. Aug. 2016 (CEST)

Keine Ahnung, woher du, ohne je mit mir kommuniziert zu haben, weisst, auf was ich mich eingeschossen habe. Meine Privatmeinung tut nichts zur Sache und wird von mir auch nicht thematisiert. Im Übrigen habe ich diese Kritikpunkte nicht er-, sondern nur ge-funden.--Matthiask de (Diskussion) 15:38, 24. Aug. 2016 (CEST)

Zu kein Problem für die Privatsphäre, da Google in den permanenten Logs keine personenbezogene Daten speichert: Das kann selbst bei einem völlig vertrauenswürdigen Standardwert ein "Problem für die Privatsphäre" sein, z.B. wenn man erwartet, dass ein Server im internen Netzwerk befragt würde und die Anfrage durch die Fehlkonfiguration (die ja nötig ist, damit dieser Standardwert wirksam wird) unerwarteterweise ins Internet gelangt. Ich hätte im Artikel die Angabe welcher DNS-Server "betroffen" ist lieber unkommentiert (und auf einen entsprechenden Artikel/Abschnitt verlinkt) stehen, aber erwähnt, dass jede Vorauswahl an dieser Stelle problematisch sein kann, und sei es, weil ein Netzwerkadmin dadurch einen Konfigurationsfehler nicht bemerkt. --nenntmichruhigip (Diskussion) 16:59, 24. Aug. 2016 (CEST)

Tatsache ist nun mal, daß zwei Nameserver hardcodiert im Code stehen, was auch immer man daraus machen will. Es wäre wohl nicht sachgerecht, daraus gleich eine Lauschattacke zu konstruieren, und das tut außer ein paar Hitzköpfen wohl auch niemand. Aber es stehen zwei IPs drin, und ich weiß wirklich nicht, welchen Anlass es gibt, sie verschweigen zu wollen. Ca. 80 Zeilen weiter oben sind vier weitere Server im Code vorgegeben, die dem gleichen Anbieter gehören. Für FOSS ist das schon eine Auffälligkeit, die auch Fachpublikationen wie Golem erwähnenswert fanden. Darüber, wie man es einschätzt, kann man diskutieren (obwohl das Resultat einer solchen Diskussion nicht in die WP gehörte, denn es wäre auch POV-belastet); aber diskussionslos samt Belegen herauslöschen ist ein schlechter Stil.--Matthiask de (Diskussion) 17:26, 24. Aug. 2016 (CEST)

Torvalds jüngster Kommentar

@Matthiask de: Ich finde man sollte Torvalds jüngsten Seitenhieb raus zu nehmen. Wer die Linux-Medien oder gar die Linux-Mailingliste verfolgt, weiß Torvalds schimpft praktisch täglich über eine Software/Projekt/Firma. Inzwischen dürfte er jeden größeren Hardware-Konzern und fast jedes größere FOSS-Projekt durch haben. Bis auf wenige male (SCO & der Nvidea-Mittelfinger) ist das sehr schnell in Vergessenheit geraten und hatte keine Bedeutung. Ich bezweifle daher die langfristige Relevanz. -- Michi 18:46, 13. Jul. 2017 (CEST)

Zu dem in diesen Kreisen üblichen Ton sage ich lieber nichts. Daher ist es z. B. auch nicht zweckmäßig, Torvalds' Äußerungen zu Sievers in epischer Breite auszuführen. Hier haben wir ein klares Statement, das über die üblichen Schimpfkanonaden hinausgeht und das auch Heise berichtenswert fand. T. bezog sich in seiner Äußerung sehr deutlich nicht auf ein konkret anliegendes Tagesproblem, das morgen vergessen ist.--Matthiask de (Diskussion) 18:57, 13. Jul. 2017 (CEST)

Patch zum Root-Exploit

@MichaelSchoenitzer: gibt es einen Beleg dafür, daß der Patch bereits umgesetzt ist? Dann bitte einfügen, ansonsten wieder auf „vorgeschlagen“ setzen, denn das ist der Informationsstand der Quelle. Hinweis: seit ein paar Tagen existiert Version 234, vielleicht wurde der Patch da schon eingebaut. Ich finde keine Release-Notes dazu.--Matthiask de (Diskussion) 19:02, 13. Jul. 2017 (CEST)

Ich hab doch bereits eine Quelle eingefügt. Diese zeigt, das der Patch gestern gemerged wurde. Hier ist noch das Commit des Merges: [2], die heute Erschienene v234 ist laut [3] dieser Commit: [4], welche wie hier zu sehen nach dem Patch um den es geht war. Sprich ja, es ist in der 234 bereits drin. für die Formulierung ist das imho aber auch egal ob es schon released wurde, da die Aussage ist, dass ein Patch eingebaut wurde, nicht das eine neue Version damit releast wurde – das ist das bei Sicherheitslücken übliche Kriterium. -- Michi 20:18, 13. Jul. 2017 (CEST)

Ah OK, jetzt gesehen. Ich kenne als übliches Verfahren bei neuen Releases eine Releasenote mit Angaben wie "fixed CVE-...". Thema somit erledigt.--Matthiask de (Diskussion) 13:13, 14. Jul. 2017 (CEST)

Github

Die Links zum Github-Source funktionieren nicht mehr. --(nicht signierter Beitrag von 93.197.231.87 (Diskussion) 17:00, 1. Aug. 2017 (CEST))

Das ist doch immer so. Habe aufgehört mich daran zu stören. Error ist der Normalfall. 93.197.138.75 00:42, 8. Apr. 2019 (CEST)

LOC

Ist es erwähnenswert, dass Systemd jetzt mehr als 1,2 Mio. Lines of Code hat? --2001:16B8:2CFD:D800:19F:A268:EF04:4199 17:18, 25. Mai 2019 (CEST)

Wäre es denn dann auch erwähnenswert, wenn es 1,25 Mio hätte, 1,3 Mio, 1,35 Mio ?

Soweit es mich angeht, kann diese Information in die Ablage Rund.

--arilou (Diskussion) 10:14, 13. Jun. 2019 (CEST)

Momentan sind es 1,9 Millionen Zeilen.

Erwähnenswert ist das deshalb, weil das init, was systemd ersetzen soll, in verschiedenen Implementationen weniger als 10 Zeilen C-Code hat. Man könnte, ohne parteiisch sein zu wollen, von einer Komplizierung des Startvorgangs sprechen. --Ghettobuoy (Diskussion) 03:55, 16. Apr. 2020 (CEST)

Komplizierung des Startvorgangs? Eigentlich macht systemd einiges besser als initd vorher. Denn obwohl das klassische init schneller fertig war, ist ein Startvorgang auf modernen Systemen mit dynamischen Bedingungen damit noch lange nicht fertig. ‣Andreas•⚖ 09:27, 16. Apr. 2020 (CEST)

Kommt darauf an, was man insgesamt mit dazurechnet. Wenn man sich auf Netzwerkgegebenheiten und Timings verlässt, kommt es jedenfalls zu einem indeterministischen Startvorgang (unter Race-Conditions), da die Komplexität nicht mehr zu beherrschen ist, bzw. außerhalb des eigenen Einflussbereichs liegt. --Ghettobuoy (Diskussion) 08:13, 18. Apr. 2020 (CEST)

Ich verstehe kein Bisschen von dem was du hier schreibst. Wer verlässt sich auf Timings und wo gibt es Race-Conditions? Und was hat das mit 'Komplexität' zu tun und von welche 'Komplexität' sprichst du überhaupt. Es gibt genügend was man an systemd kritisieren kann, aber eine irgendwie relevante 'Komplexität des Bootvorgangs' kann ich mit besten Willen nicht sehen. Heutige sysV-init Scripte sind oft mehrerer tausend Zeilen Shellcode lang und verwenden dabei dutzende weitere Programme. Eine Menge Komplexität wird also nur verschoben. Und natürlich sind heutige init Systeme komplexer und größer als init-Systeme von vor 40 Jahren – das hat nichts mit systemd zu tun sondern ist ein grundsätzliches Phänomen des IT-Zeitalters. -- Michi 15:19, 18. Apr. 2020 (CEST)

Da Vergleichst du Äpfel mit Birnen. Den erstens ist sytemd nicht nur ein init, sondern ersetzt noch viele andere Komponenten (Ob man das für sinnvoll hält oder nicht ist eine andere Frage). Da systemd modular ist, müsste man wenn schon nur die LOC-Länge des init-systems vergleichen. Und zweitens ist SysV-init deshalb so simpel, weil es all die Arbeit den Init-Scripten überlässt, während man bei systemd nur Konfigurations-Dateien hat. Damit ist das nur eine Verlagerung von Code. Und drittens verwendet man bei diesen Skripten eine shell, dutzende von unix-tools und weiter Programme, deren Funktionalität bei den ~2 Millionen LOC von systemd enthalten sind, bei älteren init Systemen aber noch oben-drauf kommen. Die Reale Länge von einem durchschnittlichem System mit init und einigen deamons ist also signifikant länger.

Und unabhängig von dem ist alles, was du – wie auch ich und andere – hier schreibst für diesen Artikel irrelevant, da es Meinungen sind und hier keine seriösen Quellen genannt sind. Der Artikel enthält bereits ein ausführliches Kapitel über Kritik. Natürlich könnte man das wie den Rest des Artikels wesentlich überarbeiten – die LOC sind dabei aber kaum von Bedeutung. -- Michi 15:19, 18. Apr. 2020 (CEST)

+1 Genau das: "…für diesen Artikel irrelevant, da es Meinungen sind…" und "…die LOC sind dabei aber kaum von Bedeutung." ‣Andreas•⚖ 18:50, 18. Apr. 2020 (CEST)

Du machst das Klasse. +1 für Dich! --Ghettobuoy (Diskussion) 10:47, 19. Apr. 2020 (CEST)

Tja, man müsste und man sollte. Tatsächlich ist systemd derzeit größer als ein typisches User-Space-Linux von 2001 insgesamt (Basisinstallation). Und das ist schlecht.

Aber man merkt ja dem genervten Tonfall schon an, dass eine sachliche Diskussion gar nicht in Reichweite ist. Stattdessen hektisches Gezappel. --Ghettobuoy (Diskussion) 09:52, 19. Apr. 2020 (CEST)

Nein. Wenn man sich den Code und die Binary-Größen von Software aller Art ansieht, merkt man, dass diese größer und umfangreicher wird. Das ist also kein Alleinstellungsmerkmal eines init-Prozesses. Allerdings vergleichst du Äpfel mit Birnen. systemd ist als ganz anderes Kaliber ins Rennen gegangen als SysVinit. Und natürlich wird systemd weiterentwickelt, das ist ja auch das Ziel dieser Neuimplementierung. Wenn man sich die Parallelisierung ansieht, gibt es bei den klassischen init-Prozessen keine Alternativen zu etwas größerem. Das zeigt sich bei SMT, launchd ebenso wie bei Upstart.

Die Frage bleibt also nur jene: was sollen die Lines of Code aussagen? Und: gibt es eine Quellenangabe zur Interpretation, was das aussagen soll? Denn, ja, wenn es in der Fachpresse diskutiert wurde, und es dazu eine relevante Quelle gibt, dann ist das schon etwas für die Wikipedia. Sonst aber nicht. ‣Andreas•⚖ 11:22, 19. Apr. 2020 (CEST)

Es gibt natürlich Annahmen über die Komplexität, aber das Thema ist schwierig. Ein Einzeiler ist weniger komplex als ein mehrere Millionen Zeilen umfassendes Software-Konglomerat. Dazu braucht man keinen Fachartikel, das ist offensichtlich erschließbare Logik. --Ghettobuoy (Diskussion) 23:30, 27. Apr. 2020 (CEST)

Korrekt, aber gleichzeitig ohne Aussagekraft. Ein analoges Beispiel aus der Biologie wäre etwas Leben: ein Virus ist weniger komplex als ein Einzeller ist wengiger komplex als ein Mehrzeller ist weniger komplex als höhere Lebensformen, die natürlich allesamt Mehrzeller sind, wie etwa Säugetiere. Oder eines aus der Technik: eine Dampfmaschine ist weniger komplex als ein Otto-Verbrennungsmotor. Beides sind Motoren, aber ich kann doch wohl nicht Äpfel mit Birnen vergleichen, oder? Wenn ich schon Lines-of-Code vergleiche, dann wohl SMT, launchd, upstart und systemd, denn die machen alle in etwa dasselbe. ‣Andreas•⚖ 00:08, 28. Apr. 2020 (CEST)

Ein Init-System, das die Initialisierung lediglich anstößt, mit einem Init-System zu vergleichen, das die Initialisierung auch tatsächlich durchführt, hat schon etwas unfreiwillig Komisches an sich. --Oliver Henning (Diskussion) 16:06, 1. Mai 2023 (CEST)