Die Entwickler von postmarketOS haben beschlossen, systemd in ihr mobiles Betriebssystem zu integrieren, um die Entwicklung von mobilen Distributionen mit KDE und GNOME zu erleichtern. Dabei geht es in erster Linie nicht um systemd als Pid1, sondern um die weiteren Komponenten.
postmarketOS ist ein Betriebssystem vorwiegend für Android-Geräte und basiert auf der leichtgewichtigen Distribution Alpine, die OpenRC als Init-Software verwendet. postmarketOS legt sich nicht auf eine Desktop-Oberfläche fest, sondern unterstützt das GNOME-basierte Phosh, KDE Plasma Mobile, Sxmo und Tiling-Manager wie Sway und i3.
OpenRC mit Hindernissen
Eines der Haupthindernisse bei der Zusammenarbeit mit KDE- und GNOME-Entwicklern sind laut den postmarketOS-Entwicklern Schwierigkeiten mit dem bisher OpenRC-basierten Stack. Deshalb werden schon seit Längerem sogenannte Polyfills verwendet, die in diesem Fall Funktionen der systemd API integrieren, ohne systemd als Ganzes zu benutzen. Das führte aber zunehmend zu Inkompatibilitäten und Reibungen.
musl statt glibc
Ein Problem bei der Integration von systemd in postmarketOS ist der Umstand, dass Alpine nicht die C-Standard-Bibliothek glibc verwendet, sondern mit musl eine Alternative. systemd unterstützt offiziell nur die glibc, die Entwickler sind aber überzeugt, dass sie einen Weg finden können, systemd mit musl zu betreiben.
Frühe Abbilder mit systemd zum Testen
Die Entwickler versichern zudem in der Ankündigung, dass Anwender minimaler Systeme wie etwa Sxmo, die kein KDE oder GNOME verwenden, weiterhin in pmbootstrap festlegen können, dass OpenRC verwendet wird, solange Alpine auf dieses Init-System setzt. OpenRC selbst scheint schon seit Längerem nicht im besten Zustand zu sein, wie ein Thread auf Mastodon nahelegt.
Wer vorab postmarketOS mit systemd testen möchte, findet frühe Demo-Abbilder zum Download. Die weitere Entwicklung kann auf GitLab verfolgt werden.
Ich schreibe aus reiner Anwendersicht ohne jegliche tiefere Kenntnisse.
Ich nutze Debian und damit systemd. Das funktioniert für mich als User seit dem Debian umgestellt hat, ohne nur ein einziges Problem diesbezüglich gehabt zu haben.
Ich weiß nicht ob ich repräsentativ sein kann oder genau deswegen, weil ich ein reiner Anwendersicht bin.
Ich möchte keine Wertung oder Gewichtung hinein bringen, lediglich meine Erfahrung.
Du kannst Debian auch ohne systemd nutzen.
Das nennt sich devuan. 🙂
Das weiß ich, aber da gibt es keine Notwendigkeit. Ich bin ja auch total zufrieden. Da spreche ich natürlich nur für mich.
ah, klang so als wuestes du’s nicht. alles gut. 😉
Mir fehlte von Anfang an das KnowHow um die systemd Thematik zu bewerten und hoffe daher darauf auf die Entscheidung des Debian-Projekts vertrauen zu können.
Scheiße… ich hab kein Popcorn mehr in meinem Vorratsschrank 😛
Schade, schade. Ich habe ja eine gute Zeit mit postmarketOS (PM) gearbeitet, um AVMUltiPhone zu entwickeln. Dazu zwei drei Anmerkungen zu obiger Entscheidung: Solange es nicht Pid1 ist, dürfte wenigstens der eigentliche Boot-Prozess nicht davon betroffen sein. PM beruht auf Alpine. PM erleichtert vieles gegenüber Alpine. PM läuft mit Python auf fast jedem Device, ich brauche für die Entwicklung kein Alpine.
Vorteil: Die ersten Schritte sind einfach(er), bis Alpine als Desktop läuft, im Einstig nicht so einfach. Jedoch, irgendwann kann PM mühsam werden, da so ziemlich alles gepacht wird. Auch wenn ich die Entscheidung von PM betr. SystemD nicht gut finde, ich sehe die Problematik seit längerem.
Anstelle dass saubere Schnittstellen implementiert werden, werden Dinge überall verzahnt. SystemD wird an Stelle X in Projekt Y benötigt, dann an Stelle Z und und und. Das führt dazu, dass es immer schwieriger wird, ohne SystemD Pakete (z.B einen Desktop-Manager) am Laufen zu erhalten.
Nun könnte argumentiert werden, dass damit die Software klein und handlich bleibt, nur sehe ich das Gegenteil, eine Unmenge von Code, die niemand mehr versteht. Dies wiederum führt dazu, dass alle glauben, ein kleines Team kann z.B. gar keinen WebBrowser mehr mit genügend Sicherheit entwickeln.
Ob dabei Firmen mit Absicht derartige Monster unter die Leute bringen, um bewusst Abhängigkeiten “durchzudrücken” oder ob es “nur” Faulheit im Coding ist, ich weiss es nicht (wir wollen mal letzteres annehmen).
Betr. PM und AVMultiPhone war es aber doch so, dass ich schon nicht so wahnsinnig viel “Bock” hatte, für meine paar Hundert Zeilen Code, die ich benötigte, um AVMultiPhone zusammenzustellen, ein Repository (PM) zu halten, dass schnell mal 20 oder mehr GB auf meiner Platte verbratete.
Und ich gebe zu, der native Ansatz mit Alpine ist anspruchsvoller. Trotzdem glaube ich, es hätte langfristig eher funktionieren können. Nur kam beim PinePhone dann das Pro dann die unsinnige Boot-Geschichte, und das war’s dann.
Das heisst nun nicht, dass ich auf einem Smartphone kein Endprodukt einsetzten würde, das mit PM erstellt wurde, einzig eine Entwicklung würde ich mit PM wohl heute kaum mehr starten. Und wenn ich dies auch nach anmerken darf. Ich würde PM eher empfehlen, schlanke Desktops auf den Smartphones einzusetzen (war aber damals schon nicht so gefragt).
AVMultiPhone war deshalb schnell, weil es nicht Phosh einsetzte. Jetzt neben Gnome auch noch SystemD einzusetzen, ich glaube nicht, dass daraus mehr Speed (und auch Sicherheit resultiert). Sorry für die Länge, aber ich wollte das schon lange mal loswerden.
P.S: Es geht mir hier nicht darum, ob SystemD, Gnome oder PM gut oder schlecht sind. Es geht mir darum, dass aufgrund “Softwaremonster” Entscheidungen getroffen werden, die zu noch grösseren “Monstern” führen, die immer schwieriger wartbar (und wohl nicht zu mehr Sicherheit führen) sind, siehe dazu auch:
https://gnulinux.ch/zum-wochenende-ein-plaedoyer-fuer-schlanke-software
Ja klar ist ja auch gewollt. Ist ein Angriff auf Linux , um es zu einem Einheitsbrei zu machen.
Großartig dass jemand systemd mit musl umsetzt.
@ralf stephan Was stört dich an systemd?
systemd ist ein krake, undurchsichtig und weit mehr als nur ein initsystem.
Ich bin fuer schnell, klein, effektiv und volle kontrolle ueber mein system.
Warum sollte ich da systemd nehmen?
Ich hoffe mal, das das nicht wirklich funktioniert, was die da vor haben.
bzw der Aufwand wird enorm sein.
War schon bei meinem System nicht ganz ohne.
Stimme Dir 100% zu, was meinst Du aber mit “war schon bei meinem System nicht ganz ohne”?
Ich meinte musl zu integrieren.
Sie haben festgestellt, dass es viel aufwand ist alles was systemd macht ohne systemd zu implementieren. Einer der Kritikpunkte an systemd ist das die systemd Entwickler nur glibc supporten wollen. PM implementiert jetzt systemd mit musl, das kommt allen zugute.
Also mit systemd kommt es fuer mich nicht in Frage. Systemd ist ein Krake.
Ausserdem habe ich nicht systemd gemeint sondern musl. Es ist gar kein Aufwand alles was systemd macht zu implementieren, aber wer will und macht das schon.
Es gibt nichts was systemd besser macht als init, s6 oder openrc.
Was haben eigentlich alle gegen systemd. Es ist mehr als nur ein init System, aber das ist auch Sinn der Sache. Wenn man kein systemd hat braucht man andere Programme für die Anderen Aufgaben von Systemd. Da wird es schnell unübersichtlich. Systemd ist einfach zu lernen und läuft auf fast allen Distributionen.
Es ist ein Krake, es masst sich Dinge an, die ein init-system nichts angehen.
Und genau das ist der Punkt. Man will doch ein gut strukturiertes System, von dem man jederzeit weis, was es tut und die volle Kontrolle hat. Diers ist bei systemd eben nicht so.
Es will Einheitsbrei, Abhaenigkeiten schaffen.
Unter Leuten die nicht nur Anwender sind wirst du sehr wenig Freunde von systemd finden. Schon garnicht unter den alten linuxianern.
Du kannst Systemd, aber auch nur als init System verwenden. Dann solltest du keine Probleme damit haben. Ich hatte bisher noch nie Probleme mit Systemd. Wenn ich für alle Funktionen von Systemd ein anderes Programm lernen müsste, würde ich wahnsinnig werden.
Welche Distribution nutzt du, die kein Systemd hat?
Ich habe meine eigene Distribution auf basis von crux/venom linux.
Wenn ich das nicht haette wurde ich guix, void oder lfs benutzen.
ansonsten mal bei nosystemd oder Without Systemd reinschauen.
Old man raging at clouds
Sorry aber “es ist ein Krake”, “es maßt sich Dinge an” sind keine Argumente.
Wenn du systemd nicht magst, dann sag ich mag es nicht, ist völlig ok
Als Admin der mit vielen Systemen zu tun hat erleichtert mir systemd die Arbeit.
Ich muss nicht mehr unterschiedliche Initscripte für debian und Redhat erstellen und pflegen.
Ein Service File ist viel einfacher zu schreiben als ein Initscript, ich kann Zugriffe begrenzen, systemd kann den Service automatisch neu starten.
Niemand zwingt dich es zu benutzen, aber viele Entwickler sehen offensichtlich die Vorteile.
Warum es ein krake ist und was es sich alles anmasst das kann doch jeder selbst recherchieren. Aber es sollte schon gesagt werden.
Ich war auch lange Jahre admin und ich habe meine scripte immer selbst geschrieben, weil ich genau wissen wollte was passiert und die Kontrolle haben wollte. Selbst sendmail conf habe ich selbst geschrieben.
Wenn Dir selbst (oder der heutigen Generation) das zuviel Arbeit ist, dann ist es ja legitim.
Wenn man die Einbindung von google-diensten im code als admin als nicht bedenklich findet und das es sicherheitstechnisch anfaellig ist. Ich fuer meinen Teil sehe das eher kritisch.
Aktuell liegt systemd bei 1.9 Mio Codezeilen, das letzte Mal, als ich nachsah (zugegeben ein paar Jahre her), waren es 1.2 Mio. Ist mir persönlich einfach etwas zu viel, wenn ich bedenke dass mein Installer aktuell 108 Zeilen umfasst (als ich es mit SystemD mit 1.2 Mio verglich, waren es 101 Zeilen).
Ferner finde ich den hier publizierten Artikel sehr lesenswert:
https://linuxnews.de/das-beste-oder-nichts-systemd/
Auf der anderen Seite ist SystemD in mittlerweile derart vielen Distributionen enthalten (und läuft), dass sicher nicht gesagt werden kann, es erfüllt seinen Zweck nicht. Muss halt einfach jede/r für sich entscheiden.
Ich denke, bei all den negativen Aussagen zu systemd ist es mal an der Zeit, eine Lanze für dieses Administrationstool zu brechen. Wir haben bei siduction systemd noch vor Debian eingeführt und sind damit bis heute gut gefahren. Wer’s nicht glaubt, der kann gerne in unserem Forum die Suche betätigen, was da seit 2013 so an Problemen mit systemd auf Desktop-Systemen gemeldet wurde. Das ist insgesamt über 11 Jahre sehr wenig. Das ist die Praxis, nicht Ideologie. Macht euch selbst ein Bild!
Ja klar andere haben sehr gute Erfahrung mit devuan. 😉
Das ist auch die Praxis.
Ja, es ist eine Menge Code. Zähl mal zusammen wieviele Codezeilen du bekommste wenn du alle systemd Funktionalität mit anderen Tools / Projekten abbildest
Bei openrc haben wir aktuell gute 34’000 Zeilen. Aber nochmals, es soll jeder das nehmen, was für ihn passt.
Als es mit systemd anfing, war ich auch Feuer und Flamme. Es war neu und wollte Dinge besser machen.
Aktuell nutze ich es, mir kommen jedoch hier und da Zweifel, ob es wirklich etwas besser/einfacher macht. Es gibt zwar für alles ein Werkzeug, das etwas ein bisschen kann, aber auch nichts richtig. Das Verwalten von Konfigurationen ist teilweise unnötig im System verteilt und verschachtelt.
Folgender Artikel fast in den ersten beiden Sätzen die Probleme, die man mit systemd haben kann gut zusammen:
https://www.howtogeek.com/713847/the-best-linux-distributions-without-systemd/
Meine persönlichen Bedenken habe ich beim Umgang mit Bugs und vor allem mit CVEs. Im Artikel wurde noch von 1.4 Millionen an Codezeilen geschrieben, von denen ich nicht glaube, das die jemand noch den Überblick hat.
musl begruesse ich ja absolut aber durch systemd faellt die Distro schon wieder aus.
Schade eigentlich.