willy4711 hat geschrieben: 
22.08.2019 19:48:50
wanne hat geschrieben: 22.08.2019 16:36:34
Dein Debian hat vor allem ein kleines eigenes init vorgeschaltet, das die Arbeit macht (/usr/share/initramfs-tools/init)
[…]
"/sbin/init" wurde nach Debian Jessie
Du merkst dass es sich um zwei verschiedene Sachen handelt?
Es ist halt nicht so einfach. Im Normalfall nehmen wir an, dass ein Programm eine Datei ist. Und durch das Ausführen dessen ein Prozess entsteht. In Wahrheit ist aber ein Prozess ein ausgeführtes Programm, das im RAM liegt und sich aus verschiedensten Quellen erstellen und ändern kann. Malware nutzt das oft aus um nur harmlose Dateien auf der Platte zu haben und sich erst im laufenden betrieb wird das Programm im RAM so verändert, dass es bösartig wird. So etwas ähnliches macht Debian: Zuerst lädt es die bash in den RAM führt die aus und interpretiert damit /usr/share/initramfs-tools/init. Ist das fertig verändert sich die bash selbst und wird dann Systemd. Würdest du ganz am Anfang vom boot das Programm hinter PID 1 angucken würdest du da eine bash vorfinden. Guckst du irgend wann später findest du ein memmap von /lib/systemd/systemd. Das Programm ändert sich während es läuft.
Also: Da ist kein Oder sondern ein beides. Am Ende ist es systemd am Anfang nicht.
Man versteht nicht, woran es hapert, welche oder um was für Devices geht es überhaupt
Die
autogenerierten von Systemd. Siehe man systemd.device. Systemd nennt die nunmal so. Da kann ich nichts machen. Wenn du in systemd-analyze guckst wirst du merken, dass da am Anfang eine ganze Menge von gestartet werden, ohne dass es dazu einen passenden Unit-File gibt. Und vor die kommst du halt nicht mit irgend welchen anderen Skripten.
das ist nämlich wieder nur ne vage Umschreibung für alles und nichts. [...] Der Faktor 'reproduzierbar' fehlt
Ich habe dir mit dem YubiKey ein schönes Beispiel zum nachvollziehen gegeben. Ähnlich mit dem hibernateten 2. Linux auf der gleichen Platte (mit GPT). Das Grundsätzliche Problem dahinter bleibt halt die abstraktere hart eingebaute Autogenerierung von diversen Konfigurationen die halt massiv zur Philosophie von Systemd gehören. Wenn ich einen konkretes Probelm habe meinst du das sei jetzt aber ein ganz kleiner Spezialfall. Wenn ich abstraktere Desighnprobleme anspreche heißt es, dass es aber viel zu abstrakt ist.
Es ist eines der Probleme wo wirklich gilt, dass es eben eine vorhersagbare Regel für Probleme und kein Einzelfall ist. Immer wenn irgend was vor local-fs.target passiert ist Systemd sehr unflexibel tut aber so als ob er da auch nur Units ablaufen würde.
und für die breite Masse der Installationen das tatsächliche Problem darstellt?
Nein. Wie immer bei Systemd: Praktisch alle Probleme betreffen <<1% der Nutzer aber es gibt tausende davon. Jeder der nicht absolut Mainstream ist, stolpert irgend wann mal über so eines. Wenn ich aber absolut Mainstream bin, kann ich mir gleich ein Android holen.
Und das liegt halt meiner Meinung nach an der Art wie Systemd entwickelt wird. Pöttering ist ja eher ein ruhiger Typ mit dem man über alles reden kann. Wenn du wirklich ein konkretes Problem hast, dass sich nicht beheben lässt passt er Systemd gerne auch mal an. (Und bricht damit hundert andere Systeme.) Aber im allgemeinen nimmt Systemd nie by Design Rücksicht auf andere. Kannst du das Problem auf deiner Seite beheben, kommt kein Patch in Systemd. Und schon gar nicht wird auf irgend ein Feature verzichtet, nur weil es ein paar Systeme bricht. Für die gibt es dann meist Ausnahmen. (Schönes Beispiel ist das hibernate-Problem. Da das bei DOS-Partitionen wohl häufiger ist, wurde es dort beseitigt bei GPT hält man das für unnötig und verweist auf Flags, die das 2. Linux setzen könnte.) Aber wehe du kommst mit nem System, das die noch nicht gekannt haben. (Und selbst eventuell gar kein Systemd kennt.)
Das ist das was im Geiste der UNIX-Philosophie falsch läuft/nicht versteht: Da werden so Sachen gefordert wie: „Write programs to work together.“, „Expect the output of every program to become the input to another, as yet unknown, program.“, „Write robust programs“, „Build on potential users' expected knowledge“. Da kommt immer wir haben hier doch tolle APIs.Die muss man nur benutzen. Wir sind doch modular... Ganz viele Einzeldateien, in denen der Sourcecode steckt...
Systemd trifft sehr oft Entscheidungen die viele Sachen brechen und das ganze an den unnötigsten Stellen. Nirgends gibt es stellen wo man sich als Admin mal kurz einklinken kann, und mit ein paar Quick and dirty-Hacks reparieren kann nirgends wird Rücksicht darauf genommen, dass die ganze Welt sich halt anders verhält. Und niemand Bock hat das jetzt alles neu zu Schreiben nur weil Systemd das jetzt anders (aber oft nicht mal wirklich besser) macht. Nirgends wird darauf Rücksicht genommen, dass jemand der Software benutzt nicht alle zwei Wochen die Release notes von Systemd durchlesen kann und es deswegen verdammt wichtig wäre, dass man sich darauf verlassen kann, das das Programm morgen noch genau so funktioniert wie gestern. Nirgends wird darauf Rücksicht genommen, dass man irgend eine Komponente austauschen können will weil in einem Spezialfall halt ein anderes Tool das bessere ist.
Das schafft alles keine
unlösbaren Probleme. (Auf die du hier immer so stark bestehst.) Sondern einen riesigen Haufen Probleme, die man mit anderen Systemen halt nicht hat.
Und du siehtst das richtig schön wenn du ein jessie mit und ohne Systemd vergleichst:
Du hast da so etwa den Faktor 4 an Zeilen die zur Konfiguration notwendig sind im Systemd. Am Ende tun beide. Die Frage ist halt: Warum soll ich mir das antun?!
Nur mal so ein schönes Beispiel wie das anders geht: Jeder mir bekannte DHCP-Client unter Linux erlaubt dir per Hook ein Shell Script einzufügen, dass nachträglich die Parameter ändert. Ich habe das noch nie gebraucht. Mir fällt auch kein spezieller Fall ein, wo man sowas brauchen könnte. Aber jeder Client bietet seit Jahrzehnten die selben Hooks, falls es da drausen irgend eine Software gibt, die sich darauf verlässt. Das sind ca. 3 Zeilen Code die man dafür einfügen muss. Das tut keinem weh. Aber wenn das 0.1% er Leute nutzen dann nutzt das noch ein paar Millionen Leuten die ihre Konfiguration nicht ändern müssen.
Zum Vergleich Systemd: Kommt nicht mit numerisch beginnenden Usernamen zurecht. Es ist genau eine Zeile, die dazu angepasst werden müsste, um das zu ändern. Und die würde sogar deutlich kürzer. Die verwenden wir auf der Arbeit halt wirklich und es ist leider extremst schwer davon weg zu kommen. (Da müsste Software umgeschrieben werden, die wir selbst nur zugekauft haben.) Ich weiß nicht wie häufig das ist. Aber keine Chance das durchzusetzen, dass Systemd das zulässt. Und er wirft nicht mal eine Fehlermeldung sondern verhält sich nur falsch. Das Problem ist also auch noch schwer zu debuggen. Nachdem gezeigt wurde, dass das sicherheitsrelevant ist, weil kein Mensch damit rechnet, dass man im Jahr 2019 nicht beliebige Usernamen vergeben kann haben sie für den speziellen Fall eine wo das Sicherheitsrelevant ist, eine Warnung eingebaut. Grundsätzlich will man aber aus "Kompatibilitätsgründen" von der Idee nicht weg, dass keine Fehler geworfen werden, wenn man Usereingaben nicht versteht. Und man stellt sich auch ganz offen hin und meint es sei absolut nicht Sache von Systemd sei jeden möglichen Spezialfall abzudecken, wenn diese durch den User verhindert werden könnten.
Sorry: Wessen Ansprüche an die Software, die er entwickelt so niedrig sind, dessen Software will ich nicht verwenden.
Ich will nicht grundsätzlich weg von der Architektur von Systemd. Die ist nicht schlecht gewählt. Aber ich hätte gerne stabil einsetzbare und vor allem flexible Software.
Und dazu gehört zu aller erst mal die Idee, dass man
a) Versucht Schnittstellen zu schaffen, damit man Teile der Software austauschen kann, wenn alternativen besser geeignet sind. (Das verstehe ICH als Admin unter Modularität.)
b) die Schnittstellen in einem geeigneten Gremium (LSB oder POSIX währen da die Naheliegenden.) zu standardisieren sodass andere mit ihren Bedürftnissen auf die Weiterentwicklung einwirken können. (Denn nur so bekommt man welche die auch auf Spezialfälle, von denen man selbst noch nie was gehört hat abdecken.)
c) Versucht alte standardisierte APIs zu implementieren und wenn nötig kompatibel zu erweitern und nur im Notfall neue zu definieren und die ausreichend erweiterbar macht, damit man sich an die Zukunft halten kann. Auf keinen Fall aber dauernd neue zueinander inkompatible zu schaffen oder gar alte inkompatibel zu kürzen (wie bei fstab und crypttab). (Denn letzteres verursacht unnötigen Aufwand.)
d) Harte Qualitäts- und Robustheitsanforderungen an seine Software stellt und bereit ist für die auch wenigstens ein paar Jahre gerade zu stehen. Das heißt vor allem auch mit Fehlern von anderen Programmen/Usern umgehen zu können. Das kann auch gerne ein Beenden mit einer Fehlermeldung sein.
Nicht die Architektur an sich ist das Problem sondern die unzählige Details. Und die bekommt man nicht weg, wenn man nicht grundsätzlich auf einen, ich sage mal jetzt, Konservativern Entwicklungsstiel umsteigt. Sonst habe ich halt jeden Monat wieder mit neuen Problemen zu kämpfen, die ich zwar beheben kann, die mir aber enorme unnötige Arbeit verursachen und die ich woanders gar nicht hätte. Oder um wieder mit nem UNIX-Grundsatz zu antworten: Value developer time over machine time. Ich brauche nicht nochmal einen schnelleren Dienstestarter. Die Bash war mir schnell genug. Ich brauche einen, der MIR zeit spart.
Ernsthaft: Ein mal The Art of Unix Programming als Pflichtlektüre würde vielen der Systemd-Developer gut tun.
Ich habe ein solches Problem jedenfalls hier noch nicht feststellen können.
