Das fasst die Philosophie hinter Systemd perfekt zusammen. Ich verstehe nur nicht, warum die ganzen Systemd Jünger nicht einfach zu iOS gehen. Da war das schon immer so: Du willst ne andere Fittnessapp als die von Apple nehmen? Die von Apple ist doch viel toller!!!! Du willst ne andere Renderingengiene als die von apple Nehmen? Warum. Das Ding von Apple ist doch genau so gut!!!!Und damit ist insbesondere der ganze unkontrollierte Wildwuchs gemeint, der innerhalb des Systems faktisch tun konnte was er wollte. Unter systemd kann sich nichts mehr unkontrolliert bewegen.
Und so läuft es mit Systemd. Redhat meint linux sei der einzig wahre Kernel => Alles andere tut nicht. Redhat meint, zwei parallele Linux-Installationen mit SWAP-Patitionen sind unnötig. => Fürhrt ohne Warnung zu schleichendem Dataloss indem die eine die daten der andern überschreibt. Kein Bug. War nie von Systemd vorgesehen, dass da mehr als ein Systemd läuft. Du hast dir so eine schöne Karte zum entschlüsseln von LUKS Containern gekauft. Kannst du in die Tonne treten. Redhat hat jetzt nen neuen "Standard" erfunden an den sich gefälligst alle zu haben. Was andere tut jetzt nicht mehr.
In Debian konnte man mal zwischen 3 völlig unterschiedlichen Kerneln auswählen Linux, Hurd und kFreeBSD. Uns selbstverständlich konnte man den auch weglassen, wenn man Debian in ner chroot, oder sonst irgend wo ausgeführt hat, wo man den halt nicht braucht.heinz hat geschrieben:30.10.2020 10:40:16So wie es, seit ich Linux kenne, mit fast allen Teilen ging... (O.K. Es duerfte wohl schwierig werden den Kernel wegzulassen...)
All das funktionierte wunderbar bis systemd kam. Die haben es nämlich – wie immer – nicht für nötig gehalten kompatibel zu irgend was zu sein. Nachdem Pöttering mit seinen Vorschlägen für die für systemd nötigen Änderungen am Linux Kernel einmal von Linus zusammen gestaucht wurde, konnte man dann doch kompatibel zu linux sein. Aber selbstverständlich nicht zu BSD oder Hurd. Das hätte das "moderne" Design verhindert. OpenRC kam btw. wieder je mit 3 unterschiedlichen Kerneln zurecht. – Aber ich weiß das ist ein "unmodernes" scheiß Systeme!
Warum? Weil die sich (wo es ging) an bestehend Standards gehalten haben. Dann waren noch ein paar minimalstpatches bei BSD nötig und es lief.
Lauter kann ich die Microsoftslogans aus den 90ern: Die Idee hinter Systemd ist Embrace, extend, and extinguish. Und das einzige Konzept, dass sich durch alle Komponenten durchzieht. Ich erinnere mich daran, dass jemand Pöttering gefragt hat, wie man was journalctl kompatibles nachbauen könnte. Antwort: Redhat wird die API so häufig ändern, dass kein anderer die Ressourcen haben wird da auf Dauer hinter her zu springen. Die Entwickler mit etwas mehr Durchblick (Also die die alternativen gesehen haben) hassen allesamt Systemd für seine daurenden API-Changes. Aber sie müssen Systemd-Kompatibel sein weil das dominierende System. Und mit jedem API change hat man eben nicht nur Arbeit mit systemd sondern auch mit allen anderen zu denen man kompatibel sein will. Und systemd tut alles aber auch wirklich alles das es unmöglich ist, kompatibel mit Systemd und irgend was anderem zu sein. – Allen voran halt dauernd APIs ändern.Und angesichts dessen, dass viele Entwickler Gebrauch von nützlichen Bestandteilen dieser Infrastruktur machen, die sowohl die Arbeit erleichtern als auch Sicherheit deutlich steigern, schafft nunmal indirekte Abhängigkeiten die systemd zumindest partiell oder gänzlich notwendig machen.
Software hat nie eine Abhängigkeiten auf irgend eine Software das ist Bullshit von Leuten die mehr verkaufen als Programmieren. Software hat Abhängigkeiten auf ne API. Und @systemd: Das macht den unterschied zwischen modularer und nicht modularer Software. Dass ne stabile API in der Mitte hängt. Dann kann man problemlos eine Komponente durch eine andere austauschen.
SystemV init hat n den 35 Jahren in denen es gelebt hat 3 mal Änderungen erfahren. – Ja das war super primitiv. – Schadet aber auch nicht. Aber man kann argumentieren, dass das nicht mehr geht. Aber die Bash in 30 Jahren 5 Major Versions. Und dass ist ne volle Programmiersprache. AWK lebt seit 50 Jahren ohne Änderungen. Der Apache hat nach 35 Jahren Version 2. CGI hat in 25 Jahren eine Überarbeitung gebraucht. Ist mittlerweile durch FastCGI ersetzt, dass seither weitestgehend stabil ist. Die meisten Scripte sind immer noch kompatibel mit beidem. Modernes FCGI-Script läuft üblicherweise problemlos auf nem 20 Jahre alten CGI-Server der dann mit nem modernen Browser von gestern reden kann. Und das Web gilt als einer der Bereiche, der sich am schnellsten fortentwickelt. Das ist vernünftige Abstraktion.
Sich dauernd ändernde APIs haben nichts mit schneller Entwicklung zu tun sondern schlicht und einfach mit Inkompetenz beim API Design.
Und jetzt Systemd: ~200 Major Versionen Jedes mal mit nem API Change. Jedes mal mit harten Abhängigkeiten die einen zwingen nicht nur jedes Einzelteil von Systemd auszutauschen. Und meinstens müssen dann nochmal 20 weitere Komponenten, die von Systemd abhängen auch geupdated werden. – Inklusive derer, die ich selbst geschrieben habe. Entweder die Systemdentwickler sind im Vergleich zu andern bescheuert kurzsichtig, dass sie im Schnitt alle 2 Wochen feststellen dass ihre Designentscheidungen von gestern scheiße warn. Oder sie wollen nicht.
Und am Ende merken das halt die Anwender ohne die genauen Gründe zu können. Dauernd tun irgend welche Anwendungen nicht, weil systemd die API ändert. Dauernd ist alles inkompatibel zueinander, weil Systemd es durch sein API-Änderungen unmöglich macht zu Systemd Kompatible Anwendungen zu schreiben und zu letzt dauernd darf man neu lernen weil sich dauernd auch die API für die Nutzer ändert.
Und die Systemd-Leute können noch so laut schreien. Ist das Problem der Anwendung wenn sie nicht schnell genug hinter unseren Changes her programmiert oder dass es die Schuld der Anwender die nicht schnell genug umlernen wollen. Die wahrheit ist Systemd lagert seine Probleme dauernd grundlos an andere aus. – Das heißt nicht ganz ohne Grund man hat eben einen schönen Vorteil wenn man allen anderen dauernd mehr Arbeit aufhalst und die sich dann darum statt um wirkliche Weiterentwicklung kümmern müssen.
