Devuan und systemd

[scientific]

Ich gehöre ja bekanntlich zur Neigungsgruppe "systemd-Superfinder"...

Sehe grad auf Distrowatch, dass das vom Beelzebub gereinigte Devuan in testing und unstable systemd in den Versionen 232 und 234 mit an Bord hat...

Find ich jetzt direkt amüsant. So amüsant, dass ich es in Smalltalk einwerfen muss...

Lg scientific

[syscrh]

Devuan hat sich als Ziel die freie Wahl zwischen Init-Systemen gesetzt. Systemd ist eines davon. Daher würde es durchaus Sinn ergeben dieses auch für den Benutzer bei Devuan anzubieten. Der Unterschied zu Debian ist allerdings, dass andere Init-Systeme weiterhin vollständig und ohne Abhängigkeiten zu Systemd unterstützt werden und die benötigten Startskripte auch nach Stretch/Ascii noch zur Verfügung gestellt werden.

Allerdings hat das hier in diesem Fall wohl eher den Grund, dass immer mehr Pakete Systemd als Abhängigkeit haben (was ich gar nicht gut finde, denn schließlich war einer der Linux-Vorteile immer die Wahlfreiheit und Modularität) und man momentan mit dem zu kleinen Team bei Devuan Probleme hat, das aus all den Paketen wieder rauszupatchen. Daher hat man das Init(+x)-System wohl vorerst in die Testing-Ausgabe gepackt, damit diese wenigstens noch benutzbar und installierbar ist.

[scientific]

Ja, wenn ich vorne die Straße asphaltiere, und hinterher den Asphalt wieder rausreiße um die Straße zu pflastern, werd ich mit der Arbeit nicht nachkommen...

Ich hab bei meiner FVWM-config auch auf systemd alleinig umgestellt. Denn allein die verschiedenen Möglichkeiten abzufragen und zu pflegen, das System runterfahren zu können, oder um alle angemeldeten User und Sessions abzufragen ohne loginctl... Ein Wildwuchs.

Mut systemd hab ich da wenige Befehle, kann mittels Abhängigkeiten andere Services starten und stoppen und bin in vielen Dingen mit weniger Codezeilen unterwegs, bei denen ich nicht mal Programmierkenntnisse benötige.

Allein die Abhängigkeit von einem eingesteckten Stromkabel oder doch Batteriebetrieb... Eine Zeile in Systemd, 30 oder 40 in Shellskripten, für alle Eventualitäten.

Ich versteh, dass viele Entwickler nur mehr auf systemd setzen, und deswegen ihre Abhängigkeiten darauf haben. Ist das nicht ebenfalls der Sinn und Zweck freier Software, dass Entwickler ihre Programme nach eigenem Gutdünken gestalten können? Das ist nicht traurig oder verwerflich... Das ist der Lauf der Dinge.

In 30 oder 40 Jahren wird dann, wenn es such bewährt hat, systemd durch etwas besseres abgelöst.

Ich halte halt das Forken nicht nur einer Distribution, sondern inklusive der dazugehörigem Upstream-Projekte auf Dauer nicht für machbar.

Gnome forken und systemd rauspatchen, KDE forken und systemd rauspatchen, Wayland firken und systemd rauspatchen... Was noch alles? Jedes kleine Projekt aus Schasklappersdorf forken und systemd rauspatchen?
Haben doch offenbar die großen Projekte selbst schon zu wenig Manpower... Wie will das Devuan bloß schaffen, die Leute aufzustellen?

Lg scientific

[syscrh]

Ja, wenn ich vorne die Straße asphaltiere, und hinterher den Asphalt wieder rausreiße um die Straße zu pflastern, werd ich mit der Arbeit nicht nachkommen...

Ich hab bei meiner FVWM-config auch auf systemd alleinig umgestellt. Denn allein die verschiedenen Möglichkeiten abzufragen und zu pflegen, das System runterfahren zu können, oder um alle angemeldeten User und Sessions abzufragen ohne loginctl... Ein Wildwuchs.

Mut systemd hab ich da wenige Befehle, kann mittels Abhängigkeiten andere Services starten und stoppen und bin in vielen Dingen mit weniger Codezeilen unterwegs, bei denen ich nicht mal Programmierkenntnisse benötige.

Allein die Abhängigkeit von einem eingesteckten Stromkabel oder doch Batteriebetrieb... Eine Zeile in Systemd, 30 oder 40 in Shellskripten, für alle Eventualitäten.

Das freut mich für Dich, dass Dir Systemd zusagt. Dennoch gibt es einiges an berechtigter Kritik und daher kann ich es sehr gut nachvollziehen, wenn andere Leute lieber ein anderes Init-System verwenden möchten. Jeder Mensch ist anders und deswegen gibt es auch nicht ein Einheitspaar Schuhe, eine Fahrzeugfirma mit einem Modell, Einheitsnahrung (z. B. Karottenpüree von Montag bis Mittwoch, Haferbrei am Donnerstag und Freitag, etc.) oder ein Einheitsbetriebssystem. Es gibt Vielfalt und das ist doch das tolle an unserer Gesellschaft?!

Ich versteh, dass viele Entwickler nur mehr auf systemd setzen, und deswegen ihre Abhängigkeiten darauf haben. Ist das nicht ebenfalls der Sinn und Zweck freier Software, dass Entwickler ihre Programme nach eigenem Gutdünken gestalten können? Das ist nicht traurig oder verwerflich... Das ist der Lauf der Dinge.

Natürlich kann jeder mit seiner Software anstellen was er möchte. Dennoch muss man das nicht gut finden. Wäre Systemd nicht so eng ineinander verzahnt und würde versuchen sich unersetzbar zu machen, indem man intern undokumentierte APIs, anstelle von bestehenden Schnittstellen (zu udev, syslog, etc.), verwendet. Wäre Systemd nur ein Init-System, logind ein davon unabhängiger Daemon (so wie syslog unabhängig vom Init-System ist), usw., dann würde sich auch niemand beklagen. Das Problem ist jedoch, dass man entweder vollständig auf Systemd setzen muss (d. h. fast das Komplettpaket installiert und im Hintergrund laufen lassen muss) oder ganz darauf verzichten kann. Logind ohne Systemd mit OpenRC ist z. B. nicht möglich.

Ich befürworte es auch, dass es nun modernere Alternativen für die Benutzeranmeldung und den Shutdown gibt und das ist ja toll, dass man das weiterentwickelt, aber ich finde es sehr kontraproduktiv, dass diese Dienste nicht mehr, wie früher, voneinander unabhängig eingesetzt werden können.

Die Softwareentwickler könnten dann Abhängigkeiten zu logind einbauen und ich kann dennoch weiterhin Syslog, OpenRC und andere für meinen Einsatzzweck besser geeignete Software einsetzen. Das war immer einer der Gründe, wieso sich Leute für Linux-Distributionen begeistert haben: Die unglaubliche Modularität und die damit verbundenen flexiblen Einsatzbereiche.

Die Realität ist heute aber, dass logind Abhängigkeiten zu Systemd und damit Journald hat und ich diese einzelnen Komponenten (also Init-System und Logging-Tool) nicht beliebig austauschen kann (und nein, eine Weiterleitung von Journald auf Syslog ist kein "austauschen"). Weiteres Problem ist, dass diese proprietäre (weil nicht dokumentierte API) Verzahnung einzelner Basiskomponenten immer schlimmer wird und einige Menschen möchten dieses "aufgeblasene Modul" deswegen nicht haben. Sie bevorzugen einfache (wenige Codezeilen, leicht durchschaubar) und den Unix-Prinzipien folgende Software.

Ich verstehe beim besten Willen nicht, wieso es Leute gut finden können, dass man sich von einem einzelnen "Blob" abhängig macht, welcher immer unverzichtbarer wird und zudem schlecht dokumentiert ist, erstaunlich viele Zeilen Code enthält, tlw. ungewünschtes Verhalten produziert und primär von Red Hat, einem gewinnorientierten Unternehmen, entwickelt wird.

In 30 oder 40 Jahren wird dann, wenn es such bewährt hat, systemd durch etwas besseres abgelöst.

Niemand verneint, dass man nicht ein moderneres Init-System brauchen könnte. Darum geht es bei der ganzen Diskussion nicht im geringsten (bzw. nur die "Systemd-Fanboys" bringen dieses Argument immer wieder hervor). Die Diskussion dreht sich eigentlich um die oben beschriebenen Probleme und nicht darum, dass Sysvinit unglaublich gut ist und keinen Nachfolger vertragen könnte.

Ein potentieller Nachfolger wäre übrigens auch OpenRC, welches nahezu alles kann, was Systemd als Init-System auch kann und zudem sowohl unter Linux-, als auch BSD-Systemen läuft und wesentlich modularer aufgebaut ist, sowie eine schlankere Codebasis besitzt.

Ich halte halt das Forken nicht nur einer Distribution, sondern inklusive der dazugehörigem Upstream-Projekte auf Dauer nicht für machbar.

Gnome forken und systemd rauspatchen, KDE forken und systemd rauspatchen, Wayland firken und systemd rauspatchen... Was noch alles? Jedes kleine Projekt aus Schasklappersdorf forken und systemd rauspatchen?

Wer forkt denn bitteschön GNOME, KDE, etc.?! Patches != Fork

Patches werden beim Kompilieren zu Upstream-Code hinzugefügt, um diesen mit eigener Funktionalität zu erweitern/verändern. Das hat überhaupt gar nichts mit "forken" zu tun, sondern ist gängige Praxis bei jeder Linux-Distribution, um ein eigenes Branding einzubauen oder die Kompatibilität mit dem restlichen System sicherzustellen.

Haben doch offenbar die großen Projekte selbst schon zu wenig Manpower... Wie will das Devuan bloß schaffen, die Leute aufzustellen?

Wenn es genug Freiwillige gibt, dann wird man auch bei Devuan in der Lage sein schneller neue Versionen rauszubringen und mehr Pakete bereitzustellen. Ein ähnliches Projekt ist übrigens Arch Linux mit OpenRC und Void Linux. Ebenso kann man bei FreeBSD, NetBSD, OpenBSD, etc. auch weiterhin GNOME, KDE, usw. ohne Systemd benutzen (daher halte ich die Abhängigkeit zu Logind auch für eher künstlich geschaffen, denn unter *BSD laufen die Programme ja schließlich auch ohne und die Code-Basis wird bis heute Upstream gewartet).


Für meinen Teil war es das jetzt zu dem Thema in diesem Thread. Ich hab aktuell alles dazu gesagt und die Köpfe dürfen sich gerne andere einschlagen. Ist eh schwachsinnig das alle 1-2 Wochen wieder erneut zu diskutieren. Wahlfreiheit und Vielfalt scheint den modernen Menschen immer mehr (/ mal wieder) zu überfordern ... Sieht man ja auch bei den Wahlergebnissen ...

[scientific]

Da pflegt Gnome selbst ihre Programme mit systemd. Und dann pflegen unzählige Leute diese Programme, dass systemd wieder rauskommt. Und alle machen das gleiche... Mehrfach.

Ja, es ist Vielfalt, aber es ist wirklich vergeudete Manpower, wenn so viele das im Prinzip gleiche tun... Nur damits "anders" ist... Ich halte das für wirklich überflüssig.

[Meillo]

Juhuu! Systemd, die Dreiundzwanzigste!


Da schon alles zu dem Thema gesagt worden ist (bloss noch nicht alles von jedem) haette ich gerne ein Vanille-Eis.

[paedubucher]

Ach, wie froh wäre ich manchmal über systemd oder ein beliebiges init-System, wenn ich beruflich mit Docker zu tun habe. Und ob ich nun sonst rc-update, systemctl enable oder etwas mit /etc/init.d eintippen muss interessiert mich in letzter Zeit kaum noch. Ähnlich geht es mir auch mit apk, apt-get, pacman, yum und Konsorten; mit Ubuntu, Debian, Arch, CentOS und Alpine. Manchmal verwende ich sogar MSSQL, und ab nächstem Monat werde ich mich auch noch mit C# befassen. Weiter werde ich auch JavaScript-Code direkt im Browser programmieren und ein Framework verwenden, das R-Code in JavaScript-GUIs umsetzt. (Da fehlt eigentlich nur noch Oracle und SAP...)
Ich bin diesen Sommer 30 geworden und habe gemerkt, dass ich meine Kräfte besser einteilen muss. Mit etwas Toleranz gegenüber verschiedenen Technologien kann ich doch einiges an Energie sparen. Am Wochenende kann ich dann immer noch auf meinem Raspi ohne GUI in reinem C herumfrickeln, wenn ich Lust dazu habe.
Das war nun etwas off-Topic, aber on-Topic ist wohl wenig Substantielles zu erwarten.

[cosmac]

Da schon alles zu dem Thema gesagt worden ist (bloss noch nicht alles von jedem) haette ich gerne ein Vanille-Eis.

Das Eis sei dir gegönnt, aber es gibt doch tatsächlich noch etwas neues (jedenfalls für mich):

Devuan hat sich als Ziel die freie Wahl zwischen Init-Systemen gesetzt. (...) Der Unterschied zu Debian ist allerdings, dass andere Init-Systeme weiterhin vollständig und ohne Abhängigkeiten zu Systemd unterstützt werden und die benötigten Startskripte auch nach Stretch/Ascii noch zur Verfügung gestellt werden.

Gibt es konkrete Pläne, die Startskripte nicht mehr zu pflegen? Und was bedeutet "/Ascii", nach Stretch kommt doch erstmal Buster?

[Radfahrer]

... und nach Buster kommt Bullseye.

[Meillo]

Und was bedeutet "/Ascii", nach Stretch kommt doch erstmal Buster?

Das ist der Releasename bei Devuan, der Stretch entspricht.

[cosmac]

dankeschön

[syscrh]

Gibt es konkrete Pläne, die Startskripte nicht mehr zu pflegen? Und was bedeutet "/Ascii", nach Stretch kommt doch erstmal Buster?

Ich meine vor einiger Zeit dazu etwas gelesen zu haben, ich bilde mir sogar ein, dass das auf einer offiziellen Mailingliste diskutiert worden war. Konkret ging es darum, dass man plant ab Buster (?) die Maintainer nicht mehr zu verpflichten SysVinit-Skripte zu pflegen. Das wäre dann sozusagen das Ende von anderen Init-Systemen unter Debian.

Hab jetzt aber nach einiger Sucherei keine Quelle mehr dazu gefunden, also würde ich das erstmal als Gerücht abstempeln und abwarten. Wobei ja bereits heute viele Programme nicht mehr ohne laufen (z. B. der NetworkManager).


Das mit Ascii war eine zweifelhafte Entscheidung des Devuan-Teams sich von Debian ausreichend zu differenzieren. Ich denke, dass das nur unnötig Verwirrung stiftet, denn aktuell ist und bleibt Devuan ein simpler Filter über den offiziellen Debian-Repositories. Das heißt, dass man ein paar Pakete am Devuan-Mirror ganz herausfiltert, andere ersetzt und den Rest einfach direkt von den Debian-Servern unverändert an den Nutzer durchreicht. Daher sind dann auch einige nicht installierbare Pakete in den Repositories enthalten (z. B. gnome-core). Nicht installierbar, da systemd auf den Devuan Jessie Mirror-Servern herausgefiltert wird.

[cosmac]

Das mit Ascii war eine zweifelhafte Entscheidung des Devuan-Teams sich von Debian ausreichend zu differenzieren. Ich denke, dass das nur unnötig Verwirrung stiftet

nur bei mir

Konkret ging es darum, dass man plant ab Buster (?) die Maintainer nicht mehr zu verpflichten SysVinit-Skripte zu pflegen. Das wäre dann sozusagen das Ende von anderen Init-Systemen unter Debian.

Naja, geredet wird darüber ja seit Jahren. Aber eine offizielle Entscheidung in der Art wäre sehr schade, von wegen Monokultur und so. Aber "das Ende" ist deshalb noch nicht in Sicht. So, wie du es formuliert hast, werden die Init-Scripte ja nicht verboten. Und in den stretch-Paketen sind funktionierende Scripte drin, die verschwinden ja nicht von selbst.

Rein technisch ist es sowieso nicht so tragisch. Erstmal brauchen die allermeisten Pakete garkein Init-Script. Dann gibt es Pakete, die müssen z.B. einen http-Server starten. Wenn es dafür kein Script mehr gibt, nimmt man eben einen anderen httpd oder startet ihn per /etc/rc.local. Wirklich wichtig sind nur sysvinit-core und initscripts und für die haben sich im Februar noch mehrere neue Maintainer gemeldet. Wenn man garnicht basteln will, braucht man noch eins von sysv-rc, file-rc oder openrc; der Rest ist Luxus.

Dieser Text wurde auf einem stretch geschrieben, das zum Starten nur /sbin/init, /etc/inittab und 126 (netto 54) Zeilen "Init-Script" braucht. Ist das jetzt "das Ende von anderen Init-Systemen" oder gerade nicht?