Laut GitHub ist systemd erst bei Version 241 angekommen. Bis zu Version 291 sollte noch einige Zeit vergehen :) Tatsächlich wurde elogind von systemd-219 geforkt.
Vielen Dank für diesen Artikel. Es ist schön Gentoo endlich mal wieder in den nachrichten zu finden
Es ist natürlich völlig in Ordnung, systemd anzubieten und zu nutzen.
Nicht in Ordnung ist es imo, seitens Gnome hier eine fixe Abhängigkeit zu schaffen, die offenbar nur mit größter Mühe wieder aufzulösen ist.
So lobenswert der Einsatz der Gentoo-Entwickler auch ist: Es wäre wohl die bessere Botschaft an Gnome, diesen Desktop bis zur Beseitigung der systemd-Abhängigkeit zu ignorieren.
Systemd und Gnome werden von RedHat und Canonical förmlich in den Markt gedrückt (wenn ich mal bei anderen Leuten ein Linux sehe, ist es meist Ubuntu mit dem Original-(Gnome3)-Dektop.
Von Fantastilliarden am Sa, 30. März 2019 um 09:29 #
[q]Milliarden Fliegen können sich nicht irren...[/q] Mehr ein paar tausend. Das rennen um den Linux Desktop hat Android gewonnen. GNOME ist auch weitrrhin eine irrelevante Randerscheinung.
Warum ist es nicht in Ordnung, eine fixe Abhängigkeit zu schaffen? Das ist doch bei fast jeder Software so. Wenn sich die Entwickler einer Anwendung dazu entscheiden, bspw. auf PostgreSQL zu setzen, dann musst du halt PostgreSQL betreiben, auch wenn du lieber DB2 möchtest. Die Anwendung auf ein anderes DBMS zu portieren ist ebenfalls sehr aufwendig, macht man eigentlich nur wenn es nicht anders geht.
Natürlich könnte man strikt nach dem SQL-Standard entwickeln und portabel bleiben, dann kann man halt nicht alle Features des DBMS benutzen. Wenn du deine Software strikt nach dem C-Standard entwickelst, dann bist du auch extrem portabel, hast aber viel mehr Arbeit, weil du alles selbst machen musst. Wenn du Bibliotheken verwendet, dann bist du wiederum von diesen abhängig.
Die GNOME-Entwickler haben hier eine pragmatische Entscheidung getroffen: >95% unserer Anwender benutzen ein Linux mit systemd. Wir brauchen einen Login-Manager, lass uns logind nehmen, das hat ein schönes D-Bus-API, und funktioniert auf fast allen Distributionen!
Wer kann es ihnen verübeln? Das machen alle so. Testest du deine Software z.B unter BSD, Solaris oder AIX, wenn du selbst und deine Anwender nur Linux verwenden? Oder ist es dir einfach egal / du hast keine Zeit dafür?
Ich finde das in diesem Fall nicht in Ordnung, weil damit bei einem der größeren DEs unnötigerweise die Wahlfreiheit der User aufgehoben wird.
Wahlfreiheit ist aber ein Kernelement von OpenSource und sollte im Zweifel Vorrang haben. Ein großes Projekt wie Gnome trägt da auch eine gewisse Verantwortung.
Dass Gnome seine User zu systemd zwingt, ist daher sehr bedauerlich.
"Wahlfreiheit" ist kein Kernelement von Open Source, die beiden Konzepte sind orthogonal. Es gibt Projekte, wie eben Gentoo, die dieses Ziel verfolgen, in diesem Fall durch Kompilieren aller Pakete aus dem Quelltext, sodass man durch Build-Optionen und Patches maximalen Einfluss nehmen kann, was bei binären Distributionen nicht möglich ist (oder viel aufwändiger).
systemd und GNOME sind beides Projekte, die eher von kommerziellen Distributionen gefördert werden, hauptsächlich Red Hat, Suse und inzwischen auch Ubuntu. Wahlfreiheit, oder maximale Konfigurierbarkeit, bedeutet höhere Kosten für den Support und schmälert daher entweder die Gewinne aus den Support-Verträgen oder man muss die Preise erhöhen.
Deshalb gibt es bei Red Hat und Suse nur einen einzigen Desktop, den man installieren kann (GNOME), andere Desktops muss man sich aus inoffiziellen Paketquellen besorgen (z.B von EPEL), und bei Ubuntu ist der Standard-Desktop auch GNOME und andere Desktops laufen über Spinoffs wie Kubuntu, Xubuntu usw., die auch weniger lang mit Updates versorgt werden (bei der LTS-Version).
Es gibt auch Community-Distributionen, die nur einen Desktop anbieten, Chakra und KaOS etwa haben nur KDE, und das Ziel der Projekte ist auch, einen guten KDE-Linux-Desktop anzubieten, die haben kein Interesse an GNOME, Xfce usw. Diese Projekte zwingen auch niemanden zu KDE, weil niemand verpflichtet ist, sich so eine Distribution zu installieren.
Und niemand ist verpflichtet, eine Distribution mit systemd zu benutzen, oder eine Desktop-Umgebung, die systemd vorraussetzt. Jedermann hat aber das Recht, den vorhanden Quelltext zu benutzen, diesen abzuändern oder eigene Software zu schreiben, wie es die Gentoo-Leute getan haben. Das bedeutet Open Source. Freiheit in dem Sinne, dass du einfach dein eigenes Projekt/Fork starten kannst.
Deswegen ist "Open Source" auch nicht wirklich freie Software. Sicherlich besteht kein Zwang, aber wenn sich immer mehr Distributionen nur singulären Elementen und Vorgaben zuwenden wird es immer schwieriger alternative Wege zu beschreiten, also einen Fork zu erstellen.
Insofern ist der Unterschied auch relevant: Freie Software per Definition setzt auch die Wahlmöglichkeiten voraus, Open-Source ist halt "nur" quelloffen aber nicht mehr. Wie man sich dann für welche Stufe entscheidet ist dann auch eine individuelle Entscheidung!
Dann ist deine Definition von freier Software viel radikaler als die der FSF. Die fordern nur, dass die Lizenz erlauben muss, dass Programm zu jedem Zweck einzusetzen, es zu untersuchen und anzupassen, es an andere weiterzugeben, und auch veränderte Formen davon weiterzugeben.
Die meiste heutige freie Software wäre nach deiner Definition dann unfrei. Firefox zwingt einen dazu, Gecko als Rendering-Engine zu benutzen, Webkit ist nicht möglich. Arch Linux ist unfrei, weil die nur x86_64 als Rechnerarchitektur unterstützen. GIMP ist unfrei, weil es GTK für die Benutzeroberfläche verwendet und kein Qt anbietet.
Konfigurierbarkeit oder Portabilität sind nicht zwingend Eigenschaften freier Software, das hat ja auch überhaupt nichts mit der Lizenz zu tun. Es gibt auch proprietäre Software, die portabel und hoch konfigurierbar ist.
Wo ich dir aber zustimmen würde: Wenn eine Software absichtlich den Benutzer bevormundet - etwa wenn ein Programm per if-Abfrage prüfen würde, ob PID 1 systemd ist und andernfalls den Dienst verweigert - dann wäre das in meinen Augen keine echte freie Software mehr. Gleiches gilt, wenn der Benutzer ausspioniert wird. Also generell, wenn die Software sich gegen den Benutzer wendet. Passiert eigentlich fast nie, weil dann macht jemand einen Fork und patcht das schädliche Verhalten raus.
Hmm, dann habe ich den Punkt insofern nicht verdeutlichen können: Entschuldige bitte. Nein natürlich muss man sich mit die Abhängigkeiten anschauen und für sich validieren, ob das passt. Das passiert bisweilen aber meist vor der Installation. Alternativ kann man auch die komplett freien Distributionen setzen, Parabola oder Hyperbola als Beispiel, respektive nur freie Repositories einbinden. Das meine ich mit "Wahlfreiheit" und genau das hast du im letzten Absatz ja auch beschrieben.
So wie es Parabola beispielsweise macht finde ich das sehr angenehm: Man kann zwischen verschiedenen Init-Varianten wählen während man ja bei Anderen wie Devuan oder Hyperbola direkt ebenso mit einer Vorgabe lebt. Aber ich suche mir genau das ja auch zuvor aus. Genau deswegen verstehe ich auch nicht warum hier so teils feindselig von einem Teilnehmer beispielsweise reagiert werden muss: Es geht nicht darum gleichermaßen systemd zu verunglimpfen oder die Wahl zu hinterfragen. Hauptsache ist doch, dass das Spektrum bunt bleibt.
Addendum: Pihole ist solch ein Beispiel und tatsächlich nicht einfach. Einige Nutzer von Gentoo hatten meines Wissens zuletzt auch angefragt, ob man nicht auch eine OpenRC-Variante anbieten könnte und sogar Code-Änderungen beigetragen. Diese wurden aber leider abgelehnt mit dem Hinweis, dass systemd eben der Standard sei und sein soll, man für eine kleine Nutzerschaft das nicht ändern wird. Das ist solch ein konkretes Beispiel: Klar, die Entwickler entscheiden darüber und technisch will ich ihnen da nicht hinein reden. Aber das ist von den Abhängigkeiten zu hinterfragen, da es technisch zu kompilieren geht nur eben nicht zu starten aufgrund der starren Abhängigkeiten.
Die Schwierigkeit bei solchen Sachen ist immer: Wer wartet + testet den Code? Ich kenne OpenRC nicht, und weiß daher nicht, wie viel Aufwand es machen würde. Wenn ich aber systemd mit SysVInit vergleiche: Da würde ich auch jeden Patch ablehnen, der SysVInit-Support hinzufügt. Einfach, weil der Code dann hässlich wird, weil man jede Menge Boilerplate schreiben muss, um all den Kram zu machen, den systemd für dich automatisch macht. Siehe hier: https://www.freedesktop.org/software/systemd/man/daemon.html
Vielleicht ist es mit OpenRC nicht so schlimm, das kann ja schon deutlich mehr Dinge wie SysVInit, wie PID files automatisch handeln, und anscheinend muss man auch nicht mehr selbst forken, wenn ich das richtig sehe, sondern das macht start-stop-daemon (die Dokumentation, die ich gefunden habe, richtig sich leider hauptsächlich an Admins und nicht an Entwickler). cgroups scheinen auch möglich zu sein, wenn auch nicht so extensiv wie bei systemd. Keine Socket-Aktivierung, hier muss man wohl inetd oder sowas nutzen. Leider immer noch eklige Shell-Skripts, wegen Kompatibilität mit SysV. Naja, Ansichtssache
Am Ende kommt es darauf an, ob es im Entwickler-Team jemanden gibt, der zufällig Gentoo und OpenRC nutzt und die nötige Arbeit erledigt - und zwar dauerhaft und nicht nur einmalig, sonst geht die Funktionalität nach ein paar Versionen wieder kaputt, weil niemand auf Regressionen testet. Ich stimme mit dir darin überein, dass man Alternativen am Leben erhalten sollte, damit keine Monokultur entsteht. Die Arbeit muss halt jemand machen, so wie es die Gentoo-Leute mit elogind gemacht haben.
Das ist Haarspalterei und geht am Kern der Sache vorbei.
Nochmal: der Punkt ist, dass das neben KDE größte Desktop-Projekt im GNU/Linux-Ökosystem eine Nutzung *ohne* systemd von vornherein und ohne Not ausschließt und damit die Wahlmöglichkeiten der User einschränkt. Damit wird auch die schon dominante Position einer immerhin umstrittenen Systemkomponente weiter zementiert: Wer Gnome will *muss* auch systemd nehmen.
Dass niemand "verpflichtet" ist, Gnome oder systemd zu verwenden oder dass man den Sourcecode ändern kann, ist banal und in diesem Zusammenhang völlig unerheblich.
Wie kommst du auf "von vornherein" und "ohne Not"? GNOME hängt auch gar nicht von systemd ab, sondern benutzt das D-Bus-API org.freedesktop.login, das von systemd-logind implementiert wird, und nun, dank den Gentoo-Entwicklern, auch von elogind.
Das ist doch auch nichts anderes, als wenn du einen Syscall verwendest, der nur unter Linux zur Verfügung steht, nicht aber unter FreeBSD. Dann geht deine Software unter FreeBSD nicht, solange niemand einen Wrapper schreibt oder FreeBSD irgendwann den gleichen Syscall implementiert.
KDE Plasma 5 hat auch einige Jahre gebraucht, bis es unter FreeBSD zur Verfügung stand. Das war sicherlich keine Bosheit, die meisten Entwickler arbeiten eben nur mit Linux und achten nicht auf Portabilität. Das ist bei GNOME auch nicht anders, die meisten Entwickler dürften da mit systemd arbeiten und nutzen daher ganz selbstverständlich die angebotenen APIs.
Generell bin ich zwar auch der Meinung, das Portabilität eine wichtige Eigenschaft ist (man weiß nie, wann man sie braucht...) aber es macht halt Arbeit, die jemand leisten muss.
> Das ist bei GNOME auch nicht anders, die meisten Entwickler dürften da mit systemd arbeiten und nutzen daher ganz selbstverständlich die angebotenen APIs.
Aber das muss doch nicht notwendigerweise dazu führen, dass sie Gnome mit systemd zwangsverheiraten.
Bei KDE und xfce beispielsweise werden auch viele Devs mit systemd arbeiten. Trotzdem haben diese Desktops mit init kein Problem. Und das dürfte bei Cinnamon, LXQt und MATE auch nicht anders sein. Nur Gnome zwingt seine User zu systemd.
Aber um hier vielleicht zu einem Abschluss zu kommen: Von mir aus kann Gnome gerne so weiter machen und bewußt auf einen Teil der User verzichten. Letztlich schneiden sie sich damit in's eigene Fleisch.
KDE verwendet ebenfalls logind und auch andere Daemonen aus dem systemd-Projekt wie timedated, hostnamed usw. Der Unterschied ist, dass es einen Fallback für Systeme ohne systemd gibt. Den hatte GNOME auch eine Zeit lang, bis er irgendwann rausflog.
Beide Projekte haben eben unterschiedliche Philosophien: GNOME möchte möglichst einfach sein und sich auf einen Weg festlegen, der dann aber gut funktioniert (ok, Ansichtssache), während KDE möglichst konfigurierbar sein möchte und dem Benutzer die meisten Entscheidungen überlässt.
Aus diesem Grund hat GNOME auch die leichter zu wartende Code-Basis, weswegen es inzwischen in allen Enterprise-Distributionen der einzig verfügbare Desktop ist. KDE will wohl niemand 10 Jahre lang warten.
Ob GNOME durch die Bindung an systemd nennenswert User verliert, bezweifle ich. Die großen Distributionen wie Debian, Ubuntu, Fedora, CentOS, Suse, Mageia, Arch Linux usw. benutzen ja alle systemd, seit vielen Jahren. Und unter Gentoo funktioniert GNOME jetzt ja auch. Was fehlt denn noch, Slackware vielleicht? Das sollte ja mit elogind genauso gehen.
Laut GitHub ist systemd erst bei Version 241 angekommen. Bis zu Version 291 sollte noch einige Zeit vergehen :)
Tatsächlich wurde elogind von systemd-219 geforkt.
Vielen Dank für diesen Artikel. Es ist schön Gentoo endlich mal wieder in den nachrichten zu finden
Es ist natürlich völlig in Ordnung, systemd anzubieten und zu nutzen.
Nicht in Ordnung ist es imo, seitens Gnome hier eine fixe Abhängigkeit zu schaffen, die offenbar nur mit größter Mühe wieder aufzulösen ist.
So lobenswert der Einsatz der Gentoo-Entwickler auch ist: Es wäre wohl die bessere Botschaft an Gnome, diesen Desktop bis zur Beseitigung der systemd-Abhängigkeit zu ignorieren.
Sehe ich auch so, wird aber nicht klappen.
Systemd und Gnome werden von RedHat und Canonical förmlich in den Markt gedrückt (wenn ich mal bei anderen Leuten ein Linux sehe, ist es meist Ubuntu mit dem Original-(Gnome3)-Dektop.
Milliarden Fliegen können sich nicht irren...
[q]Milliarden Fliegen können sich nicht irren...[/q]
Mehr ein paar tausend. Das rennen um den Linux Desktop hat Android gewonnen. GNOME ist auch weitrrhin eine irrelevante Randerscheinung.
Warum ist es nicht in Ordnung, eine fixe Abhängigkeit zu schaffen? Das ist doch bei fast jeder Software so. Wenn sich die Entwickler einer Anwendung dazu entscheiden, bspw. auf PostgreSQL zu setzen, dann musst du halt PostgreSQL betreiben, auch wenn du lieber DB2 möchtest. Die Anwendung auf ein anderes DBMS zu portieren ist ebenfalls sehr aufwendig, macht man eigentlich nur wenn es nicht anders geht.
Natürlich könnte man strikt nach dem SQL-Standard entwickeln und portabel bleiben, dann kann man halt nicht alle Features des DBMS benutzen. Wenn du deine Software strikt nach dem C-Standard entwickelst, dann bist du auch extrem portabel, hast aber viel mehr Arbeit, weil du alles selbst machen musst. Wenn du Bibliotheken verwendet, dann bist du wiederum von diesen abhängig.
Die GNOME-Entwickler haben hier eine pragmatische Entscheidung getroffen: >95% unserer Anwender benutzen ein Linux mit systemd. Wir brauchen einen Login-Manager, lass uns logind nehmen, das hat ein schönes D-Bus-API, und funktioniert auf fast allen Distributionen!
Wer kann es ihnen verübeln? Das machen alle so. Testest du deine Software z.B unter BSD, Solaris oder AIX, wenn du selbst und deine Anwender nur Linux verwenden? Oder ist es dir einfach egal / du hast keine Zeit dafür?
Ich finde das in diesem Fall nicht in Ordnung, weil damit bei einem der größeren DEs unnötigerweise die Wahlfreiheit der User aufgehoben wird.
Wahlfreiheit ist aber ein Kernelement von OpenSource und sollte im Zweifel Vorrang haben. Ein großes Projekt wie Gnome trägt da auch eine gewisse Verantwortung.
Dass Gnome seine User zu systemd zwingt, ist daher sehr bedauerlich.
"Wahlfreiheit" ist kein Kernelement von Open Source, die beiden Konzepte sind orthogonal. Es gibt Projekte, wie eben Gentoo, die dieses Ziel verfolgen, in diesem Fall durch Kompilieren aller Pakete aus dem Quelltext, sodass man durch Build-Optionen und Patches maximalen Einfluss nehmen kann, was bei binären Distributionen nicht möglich ist (oder viel aufwändiger).
systemd und GNOME sind beides Projekte, die eher von kommerziellen Distributionen gefördert werden, hauptsächlich Red Hat, Suse und inzwischen auch Ubuntu. Wahlfreiheit, oder maximale Konfigurierbarkeit, bedeutet höhere Kosten für den Support und schmälert daher entweder die Gewinne aus den Support-Verträgen oder man muss die Preise erhöhen.
Deshalb gibt es bei Red Hat und Suse nur einen einzigen Desktop, den man installieren kann (GNOME), andere Desktops muss man sich aus inoffiziellen Paketquellen besorgen (z.B von EPEL), und bei Ubuntu ist der Standard-Desktop auch GNOME und andere Desktops laufen über Spinoffs wie Kubuntu, Xubuntu usw., die auch weniger lang mit Updates versorgt werden (bei der LTS-Version).
Es gibt auch Community-Distributionen, die nur einen Desktop anbieten, Chakra und KaOS etwa haben nur KDE, und das Ziel der Projekte ist auch, einen guten KDE-Linux-Desktop anzubieten, die haben kein Interesse an GNOME, Xfce usw. Diese Projekte zwingen auch niemanden zu KDE, weil niemand verpflichtet ist, sich so eine Distribution zu installieren.
Und niemand ist verpflichtet, eine Distribution mit systemd zu benutzen, oder eine Desktop-Umgebung, die systemd vorraussetzt. Jedermann hat aber das Recht, den vorhanden Quelltext zu benutzen, diesen abzuändern oder eigene Software zu schreiben, wie es die Gentoo-Leute getan haben. Das bedeutet Open Source. Freiheit in dem Sinne, dass du einfach dein eigenes Projekt/Fork starten kannst.
Deswegen ist "Open Source" auch nicht wirklich freie Software. Sicherlich besteht kein Zwang, aber wenn sich immer mehr Distributionen nur singulären Elementen und Vorgaben zuwenden wird es immer schwieriger alternative Wege zu beschreiten, also einen Fork zu erstellen.
Insofern ist der Unterschied auch relevant: Freie Software per Definition setzt auch die Wahlmöglichkeiten voraus, Open-Source ist halt "nur" quelloffen aber nicht mehr. Wie man sich dann für welche Stufe entscheidet ist dann auch eine individuelle Entscheidung!
Dann ist deine Definition von freier Software viel radikaler als die der FSF. Die fordern nur, dass die Lizenz erlauben muss, dass Programm zu jedem Zweck einzusetzen, es zu untersuchen und anzupassen, es an andere weiterzugeben, und auch veränderte Formen davon weiterzugeben.
Die meiste heutige freie Software wäre nach deiner Definition dann unfrei. Firefox zwingt einen dazu, Gecko als Rendering-Engine zu benutzen, Webkit ist nicht möglich. Arch Linux ist unfrei, weil die nur x86_64 als Rechnerarchitektur unterstützen. GIMP ist unfrei, weil es GTK für die Benutzeroberfläche verwendet und kein Qt anbietet.
Konfigurierbarkeit oder Portabilität sind nicht zwingend Eigenschaften freier Software, das hat ja auch überhaupt nichts mit der Lizenz zu tun. Es gibt auch proprietäre Software, die portabel und hoch konfigurierbar ist.
Wo ich dir aber zustimmen würde: Wenn eine Software absichtlich den Benutzer bevormundet - etwa wenn ein Programm per if-Abfrage prüfen würde, ob PID 1 systemd ist und andernfalls den Dienst verweigert - dann wäre das in meinen Augen keine echte freie Software mehr. Gleiches gilt, wenn der Benutzer ausspioniert wird. Also generell, wenn die Software sich gegen den Benutzer wendet. Passiert eigentlich fast nie, weil dann macht jemand einen Fork und patcht das schädliche Verhalten raus.
Hmm, dann habe ich den Punkt insofern nicht verdeutlichen können: Entschuldige bitte. Nein natürlich muss man sich mit die Abhängigkeiten anschauen und für sich validieren, ob das passt. Das passiert bisweilen aber meist vor der Installation. Alternativ kann man auch die komplett freien Distributionen setzen, Parabola oder Hyperbola als Beispiel, respektive nur freie Repositories einbinden. Das meine ich mit "Wahlfreiheit" und genau das hast du im letzten Absatz ja auch beschrieben.
So wie es Parabola beispielsweise macht finde ich das sehr angenehm: Man kann zwischen verschiedenen Init-Varianten wählen während man ja bei Anderen wie Devuan oder Hyperbola direkt ebenso mit einer Vorgabe lebt. Aber ich suche mir genau das ja auch zuvor aus. Genau deswegen verstehe ich auch nicht warum hier so teils feindselig von einem Teilnehmer beispielsweise reagiert werden muss: Es geht nicht darum gleichermaßen systemd zu verunglimpfen oder die Wahl zu hinterfragen. Hauptsache ist doch, dass das Spektrum bunt bleibt.
Addendum: Pihole ist solch ein Beispiel und tatsächlich nicht einfach. Einige Nutzer von Gentoo hatten meines Wissens zuletzt auch angefragt, ob man nicht auch eine OpenRC-Variante anbieten könnte und sogar Code-Änderungen beigetragen. Diese wurden aber leider abgelehnt mit dem Hinweis, dass systemd eben der Standard sei und sein soll, man für eine kleine Nutzerschaft das nicht ändern wird. Das ist solch ein konkretes Beispiel: Klar, die Entwickler entscheiden darüber und technisch will ich ihnen da nicht hinein reden. Aber das ist von den Abhängigkeiten zu hinterfragen, da es technisch zu kompilieren geht nur eben nicht zu starten aufgrund der starren Abhängigkeiten.
Die Schwierigkeit bei solchen Sachen ist immer: Wer wartet + testet den Code? Ich kenne OpenRC nicht, und weiß daher nicht, wie viel Aufwand es machen würde. Wenn ich aber systemd mit SysVInit vergleiche: Da würde ich auch jeden Patch ablehnen, der SysVInit-Support hinzufügt. Einfach, weil der Code dann hässlich wird, weil man jede Menge Boilerplate schreiben muss, um all den Kram zu machen, den systemd für dich automatisch macht. Siehe hier: https://www.freedesktop.org/software/systemd/man/daemon.html
Vielleicht ist es mit OpenRC nicht so schlimm, das kann ja schon deutlich mehr Dinge wie SysVInit, wie PID files automatisch handeln, und anscheinend muss man auch nicht mehr selbst forken, wenn ich das richtig sehe, sondern das macht start-stop-daemon (die Dokumentation, die ich gefunden habe, richtig sich leider hauptsächlich an Admins und nicht an Entwickler). cgroups scheinen auch möglich zu sein, wenn auch nicht so extensiv wie bei systemd. Keine Socket-Aktivierung, hier muss man wohl inetd oder sowas nutzen. Leider immer noch eklige Shell-Skripts, wegen Kompatibilität mit SysV. Naja, Ansichtssache
Am Ende kommt es darauf an, ob es im Entwickler-Team jemanden gibt, der zufällig Gentoo und OpenRC nutzt und die nötige Arbeit erledigt - und zwar dauerhaft und nicht nur einmalig, sonst geht die Funktionalität nach ein paar Versionen wieder kaputt, weil niemand auf Regressionen testet. Ich stimme mit dir darin überein, dass man Alternativen am Leben erhalten sollte, damit keine Monokultur entsteht. Die Arbeit muss halt jemand machen, so wie es die Gentoo-Leute mit elogind gemacht haben.
Das ist Haarspalterei und geht am Kern der Sache vorbei.
Nochmal: der Punkt ist, dass das neben KDE größte Desktop-Projekt im GNU/Linux-Ökosystem eine Nutzung *ohne* systemd von vornherein und ohne Not ausschließt und damit die Wahlmöglichkeiten der User einschränkt. Damit wird auch die schon dominante Position einer immerhin umstrittenen Systemkomponente weiter zementiert: Wer Gnome will *muss* auch systemd nehmen.
Dass niemand "verpflichtet" ist, Gnome oder systemd zu verwenden oder dass man den Sourcecode ändern kann, ist banal und in diesem Zusammenhang völlig unerheblich.
Wie kommst du auf "von vornherein" und "ohne Not"? GNOME hängt auch gar nicht von systemd ab, sondern benutzt das D-Bus-API org.freedesktop.login, das von systemd-logind implementiert wird, und nun, dank den Gentoo-Entwicklern, auch von elogind.
Das ist doch auch nichts anderes, als wenn du einen Syscall verwendest, der nur unter Linux zur Verfügung steht, nicht aber unter FreeBSD. Dann geht deine Software unter FreeBSD nicht, solange niemand einen Wrapper schreibt oder FreeBSD irgendwann den gleichen Syscall implementiert.
KDE Plasma 5 hat auch einige Jahre gebraucht, bis es unter FreeBSD zur Verfügung stand. Das war sicherlich keine Bosheit, die meisten Entwickler arbeiten eben nur mit Linux und achten nicht auf Portabilität. Das ist bei GNOME auch nicht anders, die meisten Entwickler dürften da mit systemd arbeiten und nutzen daher ganz selbstverständlich die angebotenen APIs.
Generell bin ich zwar auch der Meinung, das Portabilität eine wichtige Eigenschaft ist (man weiß nie, wann man sie braucht...) aber es macht halt Arbeit, die jemand leisten muss.
> Das ist bei GNOME auch nicht anders, die meisten Entwickler dürften da mit systemd arbeiten und nutzen daher ganz selbstverständlich die angebotenen APIs.
Aber das muss doch nicht notwendigerweise dazu führen, dass sie Gnome mit systemd zwangsverheiraten.
Bei KDE und xfce beispielsweise werden auch viele Devs mit systemd arbeiten. Trotzdem haben diese Desktops mit init kein Problem. Und das dürfte bei Cinnamon, LXQt und MATE auch nicht anders sein. Nur Gnome zwingt seine User zu systemd.
Aber um hier vielleicht zu einem Abschluss zu kommen: Von mir aus kann Gnome gerne so weiter machen und bewußt auf einen Teil der User verzichten. Letztlich schneiden sie sich damit in's eigene Fleisch.
KDE verwendet ebenfalls logind und auch andere Daemonen aus dem systemd-Projekt wie timedated, hostnamed usw. Der Unterschied ist, dass es einen Fallback für Systeme ohne systemd gibt. Den hatte GNOME auch eine Zeit lang, bis er irgendwann rausflog.
Beide Projekte haben eben unterschiedliche Philosophien: GNOME möchte möglichst einfach sein und sich auf einen Weg festlegen, der dann aber gut funktioniert (ok, Ansichtssache), während KDE möglichst konfigurierbar sein möchte und dem Benutzer die meisten Entscheidungen überlässt.
Aus diesem Grund hat GNOME auch die leichter zu wartende Code-Basis, weswegen es inzwischen in allen Enterprise-Distributionen der einzig verfügbare Desktop ist. KDE will wohl niemand 10 Jahre lang warten.
Ob GNOME durch die Bindung an systemd nennenswert User verliert, bezweifle ich. Die großen Distributionen wie Debian, Ubuntu, Fedora, CentOS, Suse, Mageia, Arch Linux usw. benutzen ja alle systemd, seit vielen Jahren. Und unter Gentoo funktioniert GNOME jetzt ja auch. Was fehlt denn noch, Slackware vielleicht? Das sollte ja mit elogind genauso gehen.