GNOME 3 ist zumindest nach Umfrageergebnissen die mit Abstand beliebteste Desktopumgebung bei meiner bevorzugten Distribution (Arch Linux)

Ach, wirklich? Wer sagt das? Doch nicht etwa die vielen Seiten, die die Archlinux FunStatistics zitieren? Da gibt es tatsächlich diverse, die den immer gleichen Kram des führenden Gnome Desktop 2015 bei Arch wiederholen.

Gucken wir mal, wie das zusammenkommt:
- In den ersten Tagen des Jahres 2015 wurde Gnome für das Jahr 2015 als Gewinner auserkoren
- schon jetzt, noch immer ziemlich am Anfang des Jahres, gilt das schon nicht mehr
- man muss aktiv bewusst ein Paket installieren, um überhaupt an der Statistik überhaupt teilzunehmen
- es wurde in einzelnen Forenthreads Werbung dafür gemacht, u.a. gnome-threads
- Die Datenbasis ist dennoch eher klein - keine 50.000 submissions
- Die Datenbasis wird von einzelnen Nutzern dominiert - nur 18.000 unterschiedliche IPs
- bei wie viel Millionen Arch Nutzern?
- gewertet werden installierte Pakete, nicht genutzte
- bzw. man kann überhaupt nicht sehen, woraus sich die Balken überhaupt aufbauen; 30% von was? Insgesamt gibt es rund 110% Anteil der 7 Haupt-Desktops, ohne dass "sonstige" überhaupt auftauen; %-Anteile können es also schlecht sein.

Dann gibt es da noch weitere Punkte. Zum Beispiel sind Gnome und KDE generell traditionell üblich. Ich kenne keinen, der eine Alternative nutzt und keinen dieser beiden nicht noch zusätzlich installiert hat. Wer etwas ausgefallenes nutzt, der spielt in die Statistik von Gnome+co. dann ebenso mit ein wie in die seiner eigentlichen Wahl. Dagegen ist es wohl eher unüblich, ausgefallene Dinge wie LXDE, awesome oder was auch immer parallel zu installieren, wenn man einen der bekannteren Haupt-Desktops wie Gnome oder KDE verwendet. Somit wären Gnome und KDE von der Logik her selbst dann noch führend, wenn der überwiegende Großteil der Nutzer real etwas anderes verwenden würde. Da verwundert es mich nicht, dass man so etwas auch in den Statistiken sieht.

Insbesondere Nutzer der Gnome-Forks Cinnamon und Mate fließen sowieso mit in die Gnome-Statistik mit ein (Abhängigkeiten). Wenn das nicht explizit berücksichtigt wurde und man sich überlegt, dass jemand, der Cinnamon oder MATE installiert hat auch Gnome installiert hat (in die Statistik einfließt) aber es nicht nutzt, verliert Gnome aktuell rund die Hälfte seiner Installationen.

Ich hab grad mal nachgeschaut, ich würde ebenfalls mit in die Gnome-Statistik einfließen, obwohl ich weder gnome-session noch gnome-shell verwende, nur weil's halt wie üblich installiert ist. Wenn ich denn das pkgstats-Paket installiert hätte...

Wer installiert eigentlich so ein tool? Eher der einfache Nutzer, der von Linux kürzlich das erste Mal gehört hat, es toll findet und alles installiert, was ihm so empfohlen wird (gnome, kde, pkgstats...) oder der langjährige Nutzer, der schon genau weiß, was er will? (awesome und kein pkgsstats...)

Ich würde vermuten, dass diejenigen, die pkgstats installieren, auch vermehrt zu denen gehören, die in der Ausprobierphase sind und Gnome und KDE daher sowieso installiert haben.

Ja, alles insgesamt exakt so, wie ich mir vorstelle, wie die Statistiken auch bei anderswo zusammenkommen. Man sucht sich passendes. Ich traue da lieber keiner Statistik, die ich nicht selbst gefälscht habe...

Ich hab schon mehrfach mit der systemd-Entwicklung zu tun gehabt und die "religiösen Wahrheiten" sind wahrlich nicht nur auf Seiten der Kritiker. Ich hab konkrete Punkte genannt, und das sind nicht einmal alle die ich hätte, keinen davon hast du konkret beantwortet.

Ach ja, ich hab mich übrigens nochmal mit cgroups beschäftigt. Ehm, auch die unified control group hierarchy ist weiterhin eine Hierarchie, in der vom root weg deligiert werden kann. Und so wie ich das sehe ist root (der Hierarchie) weder auf einen Prozess festgelegt, noch muss PID1 darunter sein. Kein Grund, irgend etwas bzgl. cgroup nur von einem Prozess aus erledigen zu wollen. Man kann das Management zu einem anderen Prozess deligieren (ist also nicht auf eine Instanz festgelegt) und diesem Controller sogar nur bestimmte Bereiche (subtrees) dieser Hierarchie zuordnen, so dass z.B. ein lxc-Prozess die Namespaces für seine virtuellen Maschinen verwalten kann, dennoch aber keinen Zugriff auf die Namespaces der host-Prozesse hat. Wenn systemd das alles direkt in PID1 machen möchte, muss das andere Gründe haben. Und irgendwie kann ich mir noch immer nicht vorstellen, dass die das wirklich direkt aus PID1 machen wollen. Schon sinnvoller fänd ich es, wie schon gesagt, wenn PID1 zu dem zweck forkt(+exec), womit dieser Prozess das managt (diversen Code nachladen und beliebig abstürzen kann ohne PID1 zu betreffen). Wenn dieser "Zwischenprozess" anschließend fertig ist (via fork+exec z.B. Services gestartet hat) und sich beendet, fällt der gestartete Prozess doch eh auf init zurück. Dass nur der init-Prozess (bzw. "der Prozess, der Prozesse auch startet") diese Aufgabe übernehmen muss, sehe ich noch immer nicht. Als root für das Management taugt auch ein beliebiger anderer Prozess. PID1 muss nicht einmal die Rechte haben, höhere Rechte selber weiter vererben zu können, das könnten doch auch andere cgroup-controller (speziell dafür vorgesehene Prozesse) anschließend regeln!? (könnten - dass systemd das mögl. anders vorsieht mag sein; wie gesagt, mir ist es noch nicht bewusst passiert, dass bei sysvinit PID1 abstürzt, bei systemd dagegen durchaus schon; das spricht schon irgendwie dafür, dass da mehr Komplexität direkt in diesem Kernprozess drin steckt und nicht erst in einen fork geladen wird)

Mein Fazit ist jedenfalls: Die Abhängigkeiten mit cgroups zu begründen halte ich für einen Vorwand. (Weniger von den systemd-Entwicklern, bei denen ich das so direkt nicht finde, als viel mehr von dir, als Antwort auf meinen Beitrag vom Mo, 26. Januar 2015 um 11:09 Uhr)

Dass Gnome+co. nun eine systemd-Funktion nutzen und sich daher davon abhängig machen, mag ja sein. Die Abhängigkeit entsteht aber wohl eher, weil man das bewusst so haben möchte und nicht, weil so etwas wie cgroups zwangsläufig dazu führt. Insofern hoffe ich doch mal, dass die BSD-Entwickler und andere mit ihren alternativen logind-Implementierung weiter machen. Wer weiß, vielleicht kann man sowas mal in einer alternativen Linux-Implementierung gebrauchen.