Ich würde die Diskussion gerne in einem eigenen Thread haben.
(War: https://forum.archlinux.de/viewtopic.php?id=21915, letzte Posts)
piet schrieb
open-source greg schriebDas Problem ist ja das Lennart es schafft sein Zeug als Standart durchzusetzen.
  1. Standard. ;-)
  2. Er macht keine Standards, die Distributoren nehmen es und werden ihren Grund haben.
  3. Er arbeitet bei Red Hat, da kann nicht jeder anfangen und die bei Red Hat wissen einfach wie es geht und haben auch eine gewisse Macht im Linux-Bereich.
  4. Ansich sind die Einführungen nur nach hinten losgegangen. Wer meckert heute noch über Pulseaudio? Keiner, die Distributoren haben Pulseaudio nur einfach zu früh eingebaut. An avahi Probleme kann ich mich nicht erinnern. systemd wurde bei den Kernel-Entwicklern auch nicht niedergemacht.
Zu systemd kann ich allerdings nicht viel sagen, da es hier noch nicht läuft und ich es mir noch nicht wirklich angeschaut habe. Es wird aber schon nicht ganz ohne Grund von Red Hat forciert werden. Es wird halt Vorzüge gegenüber den bestehenden Alternativen haben.

Die Einführung seiner Projekte ist aber grausam. Jedesmal werden die Nutzer überrannt, wie Elefanten im Porzellan-Laden. Grundsätzlich sieht man hier aber auch wenig die Angst (Lustlosigkeit) der Nutzer auf Neues, anscheinend bringt systemd aber auch nur Unternehmen etwas. Linux kommt halt langsam in den Unternehmen an und die wollen halt teilweise auch Eigenschaften die systemd mitbringt.
Ich kann nicht alle Vorzüge nachvollziehen (schneller booten), aber andere Dinge (signierte Logfiles) sind zumindest im Unternehmensbereich nicht verkehrt.

cu

P.S.: Nein, ich bin weder Lennart noch arbeite ich bei Red Hat.
Finde ich eigentlich einen guten Beitrag. ich schreibe nachher auch nochwas dazu…
Das ist doch das eigentliche Problem mit L. P.: Was er sich da ausdenkt, ist grundsätzlich nicht schlecht, mit welcher Vehemenz er das aber versucht, durchzudrücken, obwohl der Mist nicht mal viertelfertig ist, grault ne Sau. Und klar stehen da Unternehmensinteressen dahinter, wenn es dann läuft auch Userinteressen. Ansonsten hat man in den Fans halt ein riesiges Testerpotential. Nur der Mann lässt es immer so ausschauen, als sei das alles fertig und $user sei nur zu träge oder ignorant. Dabei sind viele Sachen, von denen er schwafelt, allenfalls in seinem Kopf - und auch da noch nicht - fertig.

Ich habe auch nichts gegen Innovation. Ich habe nur etwas dagegen, Opfer und Versuchskaninchen eines übergroßen Egos zu werden. Und ich will überzeugt werden, nicht aber überrollt. Momentan habe ich für viele "Innovationen" eine ganz einfache und klare Linie gefunden: Ich baue sie nicht ein, ich supporte sie nicht, ich promote sie nicht. Wer will, soll sie probieren und mich und andere dann mit seinen Erfahrungen dazu bringen, den Sachen eine Chance zu geben.

Das reduziert die Hintergrundgeräusche gar mächtig. Die Leute, die am lautesten nach Neuerungen schreien, sind meistens die, die sie auf keinen Fall implementieren, testen oder stabil machen wollen. Da ich aber als Entwickler mehr als genug zu tun habe - auch mit Sachen, die mir keinerlei Spass oder Vergnügen bereiten - habe ich keinerlei Gründe, diesen Anteil meiner Arbeit auch noch künstlich zu erhöhen. Ich weiss, dass das sehr egoistisch ist. Thats FOSS. 😛
Pulseaudio – muss man nicht nutzen. Ich habe es z. B. auf meinem Desktop hier unter Arch nicht laufen. Und selbst wenn es mit Sound Probleme gäbe – davon geht die Welt nicht unter.

Genauso Avahi. Für manche Sachen ganz praktisch, aber nicht essentiell.

Systemd – ganz andere Baustelle. Wenn das mal zwingend vorausgesetzt wird und es keinen zweiten Weg gibt, viel Spaß. Genauso mit der Überarbeitung des Systemloggings. Das sind alles essentielle Funktionen eines Systems, da sollte es verdammt triftige Gründe geben, daran herum zu fummeln und diese "verbessern" zu wollen. Speziell zu Systemd haben schon Linux-Veteranen kritisch zu Wort gemeldet, z. B. Theodore Ts'o auf Google Plus
And this, by the way, is why I don't like systemd and the philosophy behind it. It's adding more complexity which is going to impact userspace, and to date, all of this increased complexity is something which most Desktop developers can't keep up with…
Mit Avahi gabs durchaus seine Problemchen – die fünf User, die das Ding auch tatsächlich benutzen, hatten vor kurzem afaik mit nem lustigen Root-Exploit zu kämpfen. Pulse war die ersten Jahre einfach nur ein riesiger, unnötiger Schmerz. Angeblich wirds bald mit den V-Patches den Endsieg geben und das Ding wird endlich zu irgendwas nützlich sein. Naja, mal schauen.

Systemd… schön bunt, aber sonst bringts netto herzlich wenig. Wie schonmal gesagt, das einzige, wo es imo theoretisch was bringen könnte, wäre eine Vereinheitlichung der Init-Systeme, wenn Lennart es schafft, es allen aufzudrücken. Ob das die ganze Umstellerei wert is?
Ich sehe vor allem auch das Problem, dass systemd laut Herrn Pöttering die eierlegende Wollmilchsau werden soll, die nicht nur den Bootprozess übernimmt, sondern gleich auch das Session-Management und das Kaffee kochen, also quasi immer drunter sitzt. Ich glaube, der Fachterminus ist da Single Point of Failure. Normalerweise kann man, wenn ein Session-Manager nicht funktioniert, einen anderen nehmen, aber ist das unter systemd überhaupt noch vorgesehen?
Ganz ehrlich: Modularität hat schon ihren Sinn. Wenn mir eine Komponente abschmiert und gleich das ganze System mit in den Abgrund reißt, weil es sowieso alles eins ist, was habe ich da gewonnen?
Deswegen bin ich bei Init-Systemen der Meinung, dass sie auch nur Initsystem sein sollten und das gut machen sollten. GnuPG packt ja auch nicht die überkrassesten GUIs mit ein, weil sie sicherstellen wollen, dass die essenziellen Funktionen funktionieren und genug Zeit und hinreichend wenig Code haben wollen, um sich genau darum zu kümmern.
Gab's da nicht mal in geraumer Vorzeit so eine Philosophie "ein Tool für eine Aufgabe"? Ich wiederhole mich gerne: Modularität hat ihren Sinn, gerne standartisiert, aber vorzugsweise modular.
Ich habe mich ja auch oft genug recht "flapsig"(oder überheblich,ablehnend) über L.P. und v.a. systemd geäußert, beiläufig meistens. Der Mensch ist mir eigentlich recht "wurscht", ich kenne ihn nicht und werde das wohl auch nicht. Genausowenig wie ich Linus Torwalds oder R.Stallmann kenne, aber die aufgrund ihrer Arbeit bei mir einen Respekt haben.
Fakt ist: L.P. kann programmieren, ich nicht. Zu L.P. gibt es auf wikipedia einen Eintrag, zu mir z.B. nicht. Trotzdem habe ich das Recht (nicht zuletzt da ich schon vieles gesehen habe, was andere einfach aufgrund ihres Alters eben nicht kennen) Dinge zu bewerten. Deshalb finde ich Piets Beitrag auch als einen Guten.

Grundsätzlich finde ich es erstmal was Gutes, wenn die verschiedenen Distributionen Dinge vereinheitlichen. Natürlich hätte ich lieber viel mehr "Archlinux-Prinzip" z.B. bei RedHat oder SuSe als umgekehrt, aber an der "world domination" arbeiten wir ja noch;-)

Mir persönlich wird die letzten paar jahre einfach zu viel "Prinzip" verletzt, von dem was "Linux" eigentlich zu dem gemacht hat was es heute ist:
a) Es werden Dinge vornehmlich nur anders gemacht als vorher, was nachher "hinten raus kommt" ist oftmals eben nicht besser, sondern nur anders. ("Baah, 30 jahre altes Konzept, Zeit für was Neues…). Als zwei "Klöpse" dazu zähle ich z.B. Gnome und KDE.

b) Bei dem Bestreben, dem Desktop-User sein Linux "einfach" zu machen bleiben IMHO immer mehr Sicherheitskonzepte auf der Strecke. Es muß IMHO einen Mittelweg geben zwischen "Früher konnte der User nichtmal eine CD per Auswurfknopf rausholen" und massenhaften, mit Root-Rechten laufende "Über-Daemons" wie udev, polkit/consolekit (und sudo <g>). Ich persönlich fühle mich eigentlich immer "unwohler, unsicherer" da Vorgänge eben nicht mehr auf die Devices oder die Programme/Kernel zugreifen, sondern eben über die Über-Tools mehr und mehr abstrakt. Ich bin da Retro-verseucht, gebe ich gerne zu, aber vom Augenschein erscheint mir ein per udev/polkit gesteuerter Shutdown/reboot per Kommandozeile um einiges komplizierter als die "old-scool" Methodik.

c) "One job, one tool". Das ist etwas, was mich gerade bei systemd abschreckt. Das ist - laut Werbung - sowas die eierlegende Wollmilchsau das es mir graust. Ich persönlich möchte schon mit einem Tool für den Systemstart nicht auch noch gleichzeitig - quasi per Zwangsabo! - eine komplette System*VERWALTUNG* hinzubuchen müssen.
Statisches /dev waren wir "los" durch udev. Ok, auf Desktops will wohl keiner zu rein statsichem /dev zurück. Aber plötzlich heißt es: "Ja, du hast ja udev gekauft, deswegen bekommst du nun auch systemd - wir haben das zusammengeführt".

Ich persönlich komme auf allen Systemen weiter mit dem bsiherigen Arch-Sysinit aus - mich scheren keine Bootzeiten (Statt 25s nur noch 15s - was für eine tägliche/monatliche/jährliche Ersparniss!), die Dienste kann ich zumindest über das DAEMON-Array wunderbar regeln (ich weiß ja was ich tue) und für abgestürzte, amoklaufende Prozesse bin immer noch ich gefragt - bzw. habe schon über Monitoring etc. Prozeduren für sowas.
Ich bin mir also sicher, daß ein Wechsel am Ende für mich nichts wesentlich anderes hätte ("unterm Strich"), aber der Weg wäre IMHO wesentlich komplizierter - zumindest für mich unter Archlinux.

Ich sehe aber auch die Problematik des Wildwuchses bei den Distributonen, und das "unser" System (z.B. laut dem was Tom G. oft schreibt) zunehmend "unhandhabbarer" wird und auch die Bash an ihre Grenzen stößt. Trotzdem halte ich initscripts immer noch für ein sehr nachvollziehbares Konzept.
Und ich sehe die Gefahr, daß Archlinux seine Philosophie "KISS" zunehmend (zwangsweise?) verliert, aufgibt zugunsten eines "Mittelweges der Einheitlichkeit". Ich würde es sehr begrüßen wenn es seitens der DEVs hieße:

"Systemd ist sicher für viele Distributionen mit kompliziertem init-System ein Fortschritt, wir haben aber schon seit langem mit rc.sysinit und der rc.conf ein sehr einfaches, robustes Init-System - bei dem wir bleiben. Andere Initsysteme wie systemd oder OpenRC wird wenn nötig über extra/community bereitgestellt - die Implementation hat sich aber der Distribution unterzuordnen"

Das würde ich gerne sehen. Aber wir haben ja die DEV-"Diktatur", habe ich auch absolut kein Problem damit - solange ich die Möglichkeit habe im Rahmen meines "Wissens" Dinge in einem vernünftigen Verhältniss des Aufwand eben auch anders zu machen. Also muß ich Toms Aussagen erstmal so akzeptieren.

Nur mal so nebenbei, was ich an Archlinux so schätze (und das sind eben nicht die jeweils neuesten Versionen der Programme):
* Zu Beginn meiner Linux-Zeit war ein Yast von Suse (4.3 wenn ich mich richtig erinnere) rückblickend eine große Hilfe. Zur Last wurde er für mich dann, als ich tiefer "ins /etc" eingstiegen bin und mich ärgerte wenn Einstellungen, die ich in einem Buch gelesen hatte, eben durch den Yast ungefragt wieder rückgängig gemacht wurden. Damals (und eine lange Zeit danach) hatte Yast nämlich eine Datenbank mit der Einstellungen die üebr das "GUI" getroffen wurden. Die richtigen Konfigs in /etc wurden durch dieses "Über-Tool" dann erst generiert (Die /etc/hosts z.B.). Da merkte ich zum ersten mal das mich diese Art Werkzeug mehr behindern würde als es mich vorwärts bringt.
* Zu Debian gewechselt, um Längen besser angefühlt und auch am meisten "gelernt". Ich hätte wohl heute noch mein Debian Stable wenn ich Vollhonk es damals geschafft hätte, auf meinem Thinpad T22 Debian (Sarge oder Lenny?) zu installeren. Aber es war mir (außer SuSe und Ubuntu -> No Go!) nur mit Archlinux möglich.
* Und erst da merkte ich, was mich eigentlich an Debian "gestört" hat (unbewußt): Das "dpkg-reconfigure"! Das war dann rückblickend so was wie "der kleine Yast" ;-) Unter Archlinux ging es auch ohne sowas; einfach, simpel. Die rc.conf ist eine Zentrale, aber ohne Anspruch aus den Werten darin das halbe System(/etc) zu (ver)konfigurieren.
Das Paketsystem/Buildtools war/ist sowas von simpel im Gegensatz zu dem was ich bis dahin gesehen hatte. Diese Einfachheit, Schlichheit hieß ja nicht: Mußt Du nicht mehr denken, eher das Gegenteil ist der Fall. Aber Denken ist Lernen.

Also - abschließend, was für ein Roman!- ich würde es gerne sehen wenn bei "Keep it simple" die Betonung/Auslegung von "Keep" etwas mehr in Richtung "Bewahre" ausgelegt werden würde.
Wie ist eigentlich der Tonus bei den Devs? Lese selbst kaum im englischen Teil mit und bin somit überhaupt nicht auf dem Laufenden, daher mal meine Frage hier - finden die systemd alle hammermäßig genial oder stört sich da auch jemand am fehlenden "one job, one tool" oder ein Zwischending?
Ovion schriebWie ist eigentlich der Tonus bei den Devs?
Kann ich zumindest allgemein nicht zu sagen (ich lese zwar die MLs, erfasse aber mit meinem alten Schulenglisch gerade mal das "Grobe")

Am "verbindlichsten" laut Tom G. ist wohl immer noch:
https://mailman.archlinux.org/pipermail/arch-dev-public/2012-April/022803.html
Und im Thread auf arch-general zum (ebenfalls schon toten) consolekit:
https://mailman.archlinux.org/pipermail/arch-general/2012-July/028047.html
Ah, danke, sieht etwas düster aus.
Was ich an systemd auch nicht so berauschend finde, ist, dass alles hinter irgendwelchen Tools wegabstrahiert werden soll. Statt dass ich ein Daemons-Array in der rc.conf habe, in dem ich alle Daemons, die starten, sehen und bearbeiten kann, soll ich jetzt ein Programm benutzen, dass Symlinks oder *.socket-Dateien in irgendwelchen der systemd-Verzeichnisse für mich setzt.
Finde ich insbesondere hinsichtlich KISS, zumindest bisher, ich habe es selbst noch nicht getestet, nicht besonders schön, selbst wenn wir bei systemd mal als Initsystem bleiben.
Ein Erfahrungsbericht von jemandem, der systemd bereits nutzt, wäre nicht schlecht. Er oder sie hat dann eine Meinung, die aus der Nutzung heraus entstanden ist.
Ich benutze systemd selber auf meinen beiden Notebooks.

• Was die Bootperformance angeht, sehe ich keine Vorteile. Selbst mit herkömmlicher HDD gehen drei Viertel der Bootzeit für Firmware, Bootloader, Initrd und Entschlüsselung drauf. Mit Systemd sinds dann halt eine Sekunde weniger, wow. SSD bringt deutlich mehr.
• Was den Logging-Daemon angeht, der ist einfach lächerlich. Desktop-Usern ists scheißegal, was läuft (Nachteile habe ich keine gesehen), und im Enterprise-Bereich ists witzlos, weils featuremäßig weit hinter rsyslog und Co. hinterherhinkt. Embedded sind die 3.7 MiB RAM-Einsparung mittlerweile auch witzlos, nachdem selbst billigste 2W-CPUs mit mehreren hundert MiB RAM um sich werfen.
• Der acpid-Ersatz ist ganz okay. Soweit ich weiß, bilden mittlerweile alle Treiber Hardwaretasten auch als X-Tastenevents ab, und nicht mehr als ACPI-Events, da reicht die eingebaute systemd-Lösung eigentlich. Spart einem den Aufwand, acpid einzurichten.
• Socketaktivierung ist… genauso unnötig wie inetd. Ich sehs nur bei VTs im Einsatz, und da ist es einfach nur lästig – du weißt nie, auf welchem Terminal dein X-Server jetzt landet und darfst einmal durchschauen (wobei du unfreiwillig die restlichen VTs auch noch aktivierst). Die 3.5 MiB RAM, die man dafür maximal einspart, sind geschenkt. Ich habs mittlerweile deaktiviert.
• Daemon-Einrichtung… naja, ich bin von Debian schlimmeres gewöhnt. Vorteil ist, dass man keine Race Conditions hat, ohne beim Login auf langsame Daemons warten zu müssen. Dass die Konfiguration ordner- statt dateibasiert ist, macht von der Übersichtlichkeit her imo keinen Unterschied. Schlimm ist nur, dass die Konfiguration – so wie bei udev – auf /usr/lib und /etc verteilt ist. Wenn alles in /etc wäre, hätte ich kein Problem damit.
• Dass Daemons nicht mehr einfach über Shellscripte eingerichtet werden können, ist zwar einerseits lästig, aber andererseits auch ein Segen. Wenn man sich mal so manche Initscripte anschaut, vergeht einem die Lust aufs Essen, weil da das halbe Programm ins Initscript gerotzt wurde – das macht das Debuggen deutlich schwerer. Von meiner persönlichen Bilanz (In zwei Jahren 2x eigene Init-Scripte geschrieben; und mindestens ein Dutzend, wenn nicht mehr, debuggt) überwiegen hier eindeutig die Vorteile.
• Die systemctl-Syntax ist recht sauber und nicht so viel anders als Archs eigene rc.d-Syntax. Wenn es schon eine skriptbare Daemon-Konfiguration geben muss (im Enterprise-Bereich durchaus sinnvoll), habe ich lieber systemctl als den Rotz von Debian oder Redhat. Meiner bisherigen Erfahrung nach schränkt es den Nutzer nicht ein und versucht nicht, schlauer zu sein. Großer Pluspunkt.


Fazit: Es ist nicht der Weltuntergang, aber für die minimalen Vorteile einfach zu viel Bloat.
Nutze ebenfalls systemd, muss aber gestehen, dass ich es großteils in einer "Fire and Forget"-Situation angepasst habe. Sprich: Ich habe es soweit konfiguriert bis es läuft, danach habe ich es links liegengelassen^^:
Creshal schrieb• Was die Bootperformance angeht, sehe ich keine Vorteile. Selbst mit herkömmlicher HDD gehen drei Viertel der Bootzeit für Firmware, Bootloader, Initrd und Entschlüsselung drauf. Mit Systemd sinds dann halt eine Sekunde weniger, wow. SSD bringt deutlich mehr.
Dem muss ich teilweise widersprechen; auf älteren PCs / Laptops bringt systemd die Kiste spürbar schneller nach oben. Sobald aber ein DualCore bzw. 2 GHz oder besser im Spiel ist, merkt man kaum einen Unterschied mehr, das stimmt...

Was mir bei systemd auffällt: Die Zeit beim Herunterfahren (und auch Neustarten) ist extrem kurz. Kaum geklickt od. Befehl eingegeben, zwei Sekunden später ist der Rechner aus.
• Was den Logging-Daemon angeht, der ist einfach lächerlich. Desktop-Usern ists scheißegal, was läuft (Nachteile habe ich keine gesehen), und im Enterprise-Bereich ists witzlos, weils featuremäßig weit hinter rsyslog und Co. hinterherhinkt. Embedded sind die 3.7 MiB RAM-Einsparung mittlerweile auch witzlos, nachdem selbst billigste 2W-CPUs mit mehreren hundert MiB RAM um sich werfen.
Ich für meinen Teil habe systemd gleich gemäß dem englischsprachigen Wiki so konfiguriert, dass standardmäßig syslog-ng verwendet wird und alles dahin durchgereicht wird (das berühmte "Magic"-Zeugs: alles wird intern gespeichert, bis syslog-ng gestartet ist, und dann alles bis dahin Geschriebene durchgereicht).
• Daemon-Einrichtung… naja, ich bin von Debian schlimmeres gewöhnt. Vorteil ist, dass man keine Race Conditions hat, ohne beim Login auf langsame Daemons warten zu müssen. Dass die Konfiguration ordner- statt dateibasiert ist, macht von der Übersichtlichkeit her imo keinen Unterschied. Schlimm ist nur, dass die Konfiguration – so wie bei udev – auf /usr/lib und /etc verteilt ist. Wenn alles in /etc wäre, hätte ich kein Problem damit.
Die Debian-Anspielung kann ich so unterschreiben *g* . Mir pers. ist die ordnerbasierte Konfiguration lieber (kann ich einfach besser im Kopf nachverfolgen), aber das wird wohl Geschmackssache sein... Ebenfalls Dito bei der Konfiguration: Dass diese sowohl in /etc als auch in /usr/lib stattfindet, ist ziemlich unnötig. Insbesondere die Erstellung eigener z.B. *.service-Dateien empfinde ich als ziemlich inkonsistent. Das hätte man deutlich schöner und nachvollziehbarer machen können...

Was ich recht schön finde, ist die Konfiguration eigener targets (Runlevels), die man selbst konfigurieren und benennen kann. In einigen Situationen könnte ich mir das durchaus praktisch vorstellen...
• Dass Daemons nicht mehr einfach über Shellscripte eingerichtet werden können, ist zwar einerseits lästig, aber andererseits auch ein Segen. Wenn man sich mal so manche Initscripte anschaut, vergeht einem die Lust aufs Essen, weil da das halbe Programm ins Initscript gerotzt wurde – das macht das Debuggen deutlich schwerer. Von meiner persönlichen Bilanz (In zwei Jahren 2x eigene Init-Scripte geschrieben; und mindestens ein Dutzend, wenn nicht mehr, debuggt) überwiegen hier eindeutig die Vorteile.
Auch hier: Dito. Wer dennoch seine eigene Suppe kochen will, erstellt eine *.service-Datei, in der eine Shell eine Skriptdatei parst (auch wenn das natürlich alles andere als im Sinne des Erfinders ist).
• Die systemctl-Syntax ist recht sauber und nicht so viel anders als Archs eigene rc.d-Syntax. Wenn es schon eine skriptbare Daemon-Konfiguration geben muss (im Enterprise-Bereich durchaus sinnvoll), habe ich lieber systemctl als den Rotz von Debian oder Redhat. Meiner bisherigen Erfahrung nach schränkt es den Nutzer nicht ein und versucht nicht, schlauer zu sein. Großer Pluspunkt.
Dem möchte ich noch hinzufügen, dass insbesondere die Auflistung der einzelnen Daemons und ggf. deren Startprobleme das Debuggen erheblich erleichtert, wenn man nicht erst die Logdateien durch-"grep"-en und "sed"-en möchte...


Was ich als Nachteil allerdings auch noch hinzufügen mag: Speziell auf einem Rechner konnte ich systemd nicht zum Laufen bringen. Da gibts irgendein Skript, dass die /etc/fstab so parst, dass systemd damit umgehen und die Devices mounten kann. Das Skript scheint stellenweise fehlerbehaftet zu sein; auf einem Rechner will ums Verrecken das Mounten der Root-Partition während des Bootens nicht mounten, obwohl ich keine Fehler in der fstab entdecken konnte und auch sysvinit einwandfrei durchläuft...
@systemd-(teil-)Benutzer hier (also namentlich Creshal und Astorek):
Wenn ihr die Wahl hättet (neues System und so, wasauchimmer): Würdet du das (arch-)klassische SysVinit oder systemd nehmen?

@all
Angenommen, systemd setzt sich durch, was müsste man dann als Linux-Admin distributionsspezifisch eig. noch wissen? Den Packagemanager (bzw. dessen Syntax und Eigenheiten) und wo die Pakete ihre configs hinlegen und ggf. noch die Philosophie/Paktestruktur der Distribution, sonst noch? Ab Softwareebene ist's dann ja im Prinzip gleich (bei gleicher/gleich paketierter Software, natürlich). Ich nehme mal an, dass ich das jetzt zu einfach sehe, oder?
Ich hab seit Ewigkeiten nicht mehr mit SysVinit gebootet, da nicht mehr installiert, und auch meinen Neuinstallationen bekommen ausschließlich Systemd.
@Astorek:
>Was mir bei systemd auffällt: Die Zeit beim Herunterfahren (und auch Neustarten) ist extrem kurz. Kaum geklickt od. Befehl eingegeben, zwei Sekunden später ist der Rechner aus.
Jo. Was mir auch auffällt, ist eine Fehlermeldung kurz vor dem Runterfahren, die für eine Viertelsekunde aufflackert, bevor er sich ausschaltet. #fail

@Ovion:
@Wahl: Derzeit nehm ich systemd – Da wir es anscheinend von Upstream früher oder später eh aufgedrückt bekommen, mache ich mich lieber jetzt schon damit vertraut.
@Distributionsspezifika: Ja, so in etwa.
@Creshal:
Wenn du die freie Wahl hättest (sicher sein könntest, dass beides hinreichend lange unterstützt wird)?
Hälst du die Vorteile von systemd für hinreichend, um den (das?) "Bloat" aufzuwiegen?
Creshal schriebWas mir auch auffällt, ist eine Fehlermeldung kurz vor dem Runterfahren, die für eine Viertelsekunde aufflackert, bevor er sich ausschaltet. #fail
Made my day!^^

Was'n das für eine Fehlermeldung? Oder kann systemd so spät nichts mehr an den Logger durchreichen?
Dann nimm halt nicht poweroff sondern halt, dann kannste die Meldungen stundenlang anschauen.
Ich sehe hinter der ganzen Lennyware keinen Sinn. Ich brauche sie einfach nicht und es stört mich das sie einem doch aufgedrückt wird (Wie schon von GeBra am Beispiel von Udev beschrieben) .
Wenn ich mir das hier so durchlese, werde ich mich wohl mit dem Thema systemd irgendwann mal beschäftigen werden. Momentan bin ich an so vielen Fronten am Kämpfen und Lernen, dass ich auf ein neues Initsystem dankend verzichten kann. Was ich allerdings hochspannend finde sind die positiven Stimmen zu Race-Conditions und Daemons.

Wenn also die Stimmen über systemd immer begeisterter werden, werde ich den Selbstversuch starten. Bis dahin fülle ich andere weisse Flecken in der Landkarte meines Wissens über Systemverwaltung und Linux im Allgemeinen. Damit habe ich genug zu tun.
@ fs4000
halt schaltet den Computer doch auch aus, oder haendelt systemd das anders?