Login
Newsletter
Werbung

Thema: Fedora-Entwickler möchte Systemd erneut aufspalten

5 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von irgendwer am Di, 27. Januar 2015 um 11:12 #

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.

[
| Versenden | Drucken ]
  • 0
    Von wander am Di, 27. Januar 2015 um 13:12 #

    Nein, ich meine nicht die Fun statistics, sondern u.A. diese Umfrage:

    https://brashear.me/blog/2014/05/18/results-of-the-2014-slash-r-slash-linux-distribution-survey/

    Und du hast auch gekonnt ignoriert, dass ich gesagt habe dass mir diese Zahlen ziemlich egal sind. Entscheidend für mich ist die Aktivität der Entwicklung und die Attraktivität für Entwickler und in dieser Hinsicht ist GNOME 3 ohne Zweifel Projekten wie Cinnamon, Mate und XFCE weit überlegen.

    Abgesehen davon verstehe ich nicht was du mit deinem Roman über cgroups sagen willst? cgroups können nur von einer Userspace-Instanz verwaltet werden. Dass die Verwaltung dabei abgegeben werden kann steht dazu doch nicht im Widerspruch, nur kann es zu keiner Zeit zwei Instanzen geben die die Verwaltung erledigen. Und warum schaust du nicht einfach in der Dokumentation oder dem Code nach wenn du Zweifel daran hast wie systemd cgroups handhabt? cgroups sind Kernbestandteil vom systemd Kern und nahezu alle Komponenten (journald, logind, ...) machen davon intensiv Gebrauch.

    Und ich weiß nicht ob du meine Aussagen absichtlich falsch deutest oder ob du sie einfach nur ignorierst: Ich hab klar gesagt, dass Komponenten von systemd nicht deshalb von KWin und Co. verwendet werden weil sie so super sind, sondern weil sie die einzige Möglichkeit sind an die gewünschten Funktionen zu gelangen. Das impliziert selbstverständich das man die Funktionen haben möchte, es impliziert aber nicht, dass man die Abhängigkeit haben möchte, sie wird nur im Zuge eines Kompromisses in Kauf genommen, einfach weil die Alternativen noch schlechter sind bzw. überhaupt nicht vorhanden sind.

    [
    | Versenden | Drucken ]
    • 0
      Von irgendwer am Di, 27. Januar 2015 um 15:07 #

      https://brashear.me/blog/2014/05/18/results-of-the-2014-slash-r-slash-linux-distribution-survey/
      Lol, ja, genau, da zauberst du eine noch kleinere und unter einer viel spezielleren Zielgruppe ausgeführte Befragung hervor.

      Die im übrigen ganz sicher nicht das zeigt, was du ursprünglich behauptet hast. Sie zeigt weder dass Gnome unter Arch beliebt ist (Arch macht ja nicht einmal die Hälfte der befragten Nutzer aus) und zweitens lange nicht mit Abstand. Man sieht sogar an dieser Umfrage, dass die Gnome-Nutzer zurückgehen. Während 2012 noch die Plätze 1 _und_ 2 an Gnome gingen, mit einem überragenden ersten Platz, beides Zusammen mehr als das Doppelte des ersten Nicht-Gnome-Kandidaten, ist 2014 Gnome deutlich knapper vor KDE. Kaum 30% mehr Nutzer als Unity, welches das verhassteste von allen sein soll (ein gutes Stück verhasster als Gnome, welches da ebenfalls den zweiten Platz belegt).

      Da wäre pkgstats schon tauglicher gewesen...

      Aber wenn die Zahlen ja eh egal sind, mir solls auch egal sein. Es war doch eh schon geklärt, dass Open Source Entwicklung nicht von den Anwendern abhängt.

      Viel interessanter find ich die Frage, wie du darauf kommst, dass cgroups nur von einer Userspace-Instanz verwaltet werden können? Das ist vielleicht geplant, das möchte systemd so (die Alleinherrschaft), darauf arbeiten systemd- und manch Kernelentwickler hin, aber das ist halt aktuell keineswegs so. Wie ich es schon sagte, man kann prima ein Systemd-System betreiben, diesem die Kontrolle über einige Prozesse und deren Ressourcen überlassen und parallel auf dem gleichen System die Ressourcen anderer Prozesse mit anderen Tools verwalten. Und wenns direkt aus der bash heraus ist. Egal welche Hierarchiemodelle man da nun aktuell verwendet. Naja, zumindest noch...

      Und zu deiner "einzigen Möglichkeit für KWin und Co.": Man hat durchaus schon Dinge wie Upstart Session Init genutzt (erlaubt auch ressourcen management via cgmanager, also cgroups) oder andere Ressourcenmanager. Man macht also jetzt mit systemd etwas, das man schon vorher gemacht hat. Es erfährt jetzt halt eine breitere Unterstützung, das ist toll. Somit wird es üblicher das zu machen, es setzt sich durch. Gut so. Wenn die Schnittstellen sauber und unabhängig definiert sind, kann ich das auch nur befürworten. Wenn die Schnittstellen aber exakt auf linux und/oder systemd zugeschnitten sind, um eine Adaption für andere Systeme möglichst zu erschweren, dann nicht. Ob sie das sind oder nicht, kann ich nicht beurteilen. Was ich aber sehen kann: die Physik (Ursache->Wirkung) liegt etwas anders als du sagst. Sie machen es nicht jetzt mit systemd, weil es erst jetzt möglich ist, sondern sie bauen auf systemd um, weil voraussehbar ist, dass es bald nur noch der einzige Weg ist. Warum da noch auf die alten Wege setzen? Ist doch nur logisch, nun die Schnittstellen zu nutzen, die systemd bietet, wenns doch "die Zukunft" ist. Seit die größten der Geldgeber (z.B. Red Hat) systemd als den zukünftigen Standard ausgelobt haben, ist es einfach nur logisch, ebenfalls darauf zu setzen.

      Beides obige, das Realität und Wahrnehmung verdreht, zeigt mir ein wenig, dass du nicht minder in einer Fantasiewelt lebst als manch systemd-Gegner, der wild drauf einschlägt, ohne so richtig zu wissen, weshalb überhaupt. Mir geht es durchaus auch nicht viel besser, aber ihr guckt beide nun wirklich nicht sonderlich über den eigenen Tellerrand hervor.

      Ich seh's schon kommen, bald kriegt man noch irgendwo vorgeführt: Ein System ohne systemd, das mit einer Fork Bomb in einem Einzeiler in die Knie gezwungen wird und ein System, das dank systemd-Ressourcenmanagement diese Attacke völlig unbeeindruckt lässt. Ein Lob auf systemd, ohne dass das ja nicht möglich wäre... Das wäre doch sicher eine klasse Demo, dass systemd tolles Neues bietet... oder etwa nicht?

      [
      | Versenden | Drucken ]
      • 0
        Von wander am Di, 27. Januar 2015 um 16:06 #

        Wenn du es sowieso schon geklärt hast, dass die Qualität von freier Software nicht von der Verbreitung abhängt, wieso stellst du dann überhaupt die Frage wie GNOME im Vergleich zu den Forks dasteht?

        cgroups und die unified hierachy die bereits vor etwa einem halben Jahr im Kernel landete sind eigentlich ziemlich gut dokumentiert und von dort habe ich auch meine Informationen, insbesondere hervorzuheben sind z.B.:

        https://www.kernel.org/doc/Documentation/cgroups/unified-hierarchy.txt
        http://lwn.net/Articles/601840/

        Kannst du mal bitte Beispiele nennen wo KDE bzw. KWin oder GNOME Funktionen von upstart genutzt haben? Und sei mir nicht böse wenn ich den Entwicklern von KWin, Gnome Session udgl. zunächst einmal mehr vertraue wenn sie ausführlich darlegen, dass logind bisher die einzige sinnvolle Lösung für sie ist. Insofern solltest du zumindest ein paar Quellen nennen.

        Aber halten wir einmal fest, für dich ist es also ausgeschlossen, dass jemand einfach mit systemd zufrieden sein kann wie es ist? Das bin ich nämlich im großen und ganzen - ich hatte in 2 Jahren Nutzung kein einziges Problem deswegen, ich habe dank dessen jetzt Funktionen die vorher nicht oder nur umständlich möglich waren (z.B. rootless X) und als Softwareentwickler der mit der Adminstration von PCs so wenig wie möglich zu tun haben möchte hat es mir unheimlich viel Arbeit abgenommen und die Administration falls ein Dienst nicht funktioniert odgl. deutlich erleichtert.

        Und selbstverständlich schaue ich über den Tellerrand hinaus, deswegen nutze ich z.B. auch sehr gerne OpenRC und hoffe das sich auch dieses Projekt weiter so toll entwickelt. Ich habe aber einfach besseres zu tun als für mich funktionierede Software zu kritisieren und zwanghaft nach irgendwelchen Fehlern zu suchen. Wenn du ein Problem mit den Zielen oder dem Konzept von systemd hast steht es dir frei zu benutzen was du möchtest, systemd ist wie jede andere Software nicht in der Lage jede Anforderung zu erfüllen, aber unterstelle anderen nicht sie würden irgendwelchen Wahrnehmungsstören unterliegen wenn sie mit systemd zufrieden sind.

        Da ich nicht erwarte, dass aus dieser Diskussion noch etwas erkenntnisreiches gewonnen werden kann verabschiede ich mich an dieser Stelle und wünsche noch einen schönen Tag.

        [
        | Versenden | Drucken ]
        • 0
          Von irgendwer am Di, 27. Januar 2015 um 17:12 #

          Nicht ich habe behauptet, Gnome stehe Top da. Ich habe nur auf deine Behauptung geantwortet. Und nicht ich habe die Qualität freier Software als unabhängig von der Verbreitung erklärt, das kam von dir. Ich antworte halt darauf und lasse nicht Teile weg. Ach ja, apropos... ja, damit meine ich, dass du in deinen Antworten auf diverse Teile von mir erst gar nicht eingehst. Selbst die scheinst du nicht zu lesen, auf die du dich direkt beziehst.

          Und auch diese Dokumentation zu cgroups unterstützt meine und nicht deine Aussage:
          "cgroup allows an arbitrary number of hierarchies and each hierarchy can host any number of controllers."
          Das ist der aktuelle Stand, der selbst wenn es heute anders möglich ist, halt noch immer Bestand hat. Und auch wenn es nun ein Single-Write-Konzept gibt, das parallel zum alten möglich ist, ist dieses unabhängig von der single Hierarchy, die sich auch ohne single-writer nutzen lässt. Man kann die neue unified hierarchy auch mit mehreren controllern nutzen. Sag ich jetzt zum x-ten Mal. Und du wirst es wohl zum x-ten mal ignorieren. Sonst wäre es Blödsinn, dafür einen Mount-Parameter zur Verfügung zu stellen, da das single-writer-Konzept ja völlig ohne Mount auskommt, da dies über eine ABI und nicht über ein virtuelles Dateisystem funktioniert, welches doch eben vielen Prozessen zur Verfügung steht.

          Und ich habe nicht gesagt, dass die Entwickler von Gnome etc. direkt in diesem Upstart nutzen. Die Entwickler haben Gnome natürlich vor systemd nicht so stark systemabhängig gemacht, das kommt erst mit systemd. Aber Distributionen haben upstart und dessen Session Init genutzt und darin unabhängig von dessen eigenen Fähigkeiten eine Ressourcenkontrolle ermöglicht (das wiederum sicher nicht unter Arch, weshalb dir das vielleicht entgangen ist). Man hat keine Abhängigkeiten herangezüchtet, sondern unabhängige Tools benutzt. Und so unterstützt upstart Session Init halt auch nicht direkt cgroups (glaube ich jedenfalls), sondern da gibt es wieder ein KISS-Tool für (eben schon genannt). Das ist ja gerade der Punkt, es geht auch ohne starke Verstrickung und Abhängigkeiten. Natürlich wurde so Gnome nicht von upstart abhängig, weil Gnome gar nicht erst darauf hin gearbeitet hat. Gnome muss diese Verflechtung nicht einmal vorsehen. Die Zukunft sieht aber wohl anders aus. Das siehst du wohl ganz richtig. Da wird Gnome möglicherweise direkt mit systemd vernetzt. Und dass du das toll findest und dir scheiß egal ist, dass Gnome-Nutzer ohne systemd damit ein Problem haben, hast du auch schon ausgedrückt. Musst du nicht wiederholen.

          Du hattest von Anfang an deine Meinung und hast alles mögliche ignoriert, was dir grad nicht in den Kram passt und siehst es sicher noch immer so, wie du es schon vorher gesehen hast, ohne überhaupt zu lesen und zu verstehen, was ich schreibe. Da ist es wirklich besser, wenn hier schluss ist. Da wird sich sicherlich nichts dran ändern.

          Ich erkläre was, das tust du als "Roman" ab und wiederholst anschließend die selben falschen Thesen, die just dieser "Roman" schon klärt. Klar... die anderen sehen das nur alles falsch. Du kannst auch weiterhin jede Neuerung, die du mit systemd neu erfährst, diesem Zuschreiben und nicht glauben, dass das gar nicht dessen Verdienst ist. Bei jedem Beitrag kommen neue Dinge hinzu, im letzten z.B. rootless X. Als ob es das vor systemd nicht geben hätte...
          Nur weil das bei Arch nach der systemd-Einführung zum Standard erklärt wurde, heißt das nicht, dass es ohne nicht ginge. Bei Ubuntu kann man da halt Upstart und ConsoleKit für nutzen und systemd gibts erst gar nicht. Wie ich eben schon sagte, ich warte schon drauf, dass noch einfachere Dinge neu entdeckt werden...

          [
          | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung