Der Hauptgrund, warum es bei Debian im Moment auf "systemd" hinauslief war, dass es einen Konsens gab, dass einerseits SysV nicht mehr dem aktuellen Stand entspricht sowie der Tatsache, dass keiner der Pseudo-Nachfolger das non-plus-ultra darstellte. Das zeigte sich auch in der Abstimmung. Man hatte die Wahl zwischen Pest und Cholera. - Mehr oder weniger wortwörtlich. Es gab keine klare Mehrheit für systemd. Das hat damals nur gewonnen, weil der Abstimmungsleiter eher systemd-Fan war und das Stimmgleichgewicht ihm quasi eine "zweite Stimme" gegeben hat. - Die Tatsache, was Debian für die Administratoren ausgemacht hat, wohl ignorierend.
Bis auf den Kernel ließ sich bislang so ziemlich alles recht sinnvoll direkt konfigurieren. (Auch wenn Debian da bei weitem nicht so konsistent war wie sie es gern sein würden, was die Frage angeht, WO die Configs denn nun liegen.)
Wenn mir zukünftig eine "Automount-Option" nicht mehr passt, muss ich im schlimmsten Fall in den Code.
Bei einem defekten System ein booten direkt in die Shell? "chroot" von einer anderen Maschine mit angestöpselter Platte oder Boot-CD/Stick? Sind ja nur Serveradminprobleme... Was gehen DIE Herrn Poettering an...
Regards, Bigfoot29
Nachtrag: @Wattwanderer: Ich nutze es auf meinem HTPC. Selbst MKVs laufen GPU-beschleunigt. Lediglich für POL musste ich in ein etwas aktuelleres/externes Archiv...
Was die Server-Thematik angeht, sehen wir das wohl ähnlich. Einerseits kommt es bei einem Serverstart nicht auf ein paar Sekunden an (wer noch die guten, alten Filechecks kennt, die mitunter auch mal ne Stunde oder zwei gedauert haben... "Your filesystem has been mounted 80 times without being checked..." ^^) und andererseits möchte ich nicht, dass ich irgendwelche Vorgänge mit "Magie" oder "würfeln" erklären muss sondern in einem Skript nachschauen, WARUM jetzt beispielsweise dieser blöde Netzwerk-Mountpoint schon kam, obwohl das Netzwerk noch gar nicht steht. - In dem Fall schlicht falsche Konfiguration in der fstab.