Leserartikel Linux Mint und die Probleme mit Anwendungen und Toolkits

Die meisten die mich schon länger lesen, wissen dass ich kein grosser Freund von Linux Mint, Cinnamon oder dem Entwickler Clement Lefebvre bin. Dennoch lese ich gerne seine Blogbeiträge rund um die Linux Mint Entwicklung - man will ja auf dem laufenden bleiben. Sein aktuellster Beitrag spricht dabei ein paar Probleme an, die ich schon länger am Horizont von Linux Mint sehe.

Apps, Apps und Apps​

Unabhängig davon, welche Distribution wir nutzen oder welchen Desktop wir bevorzugen am Ende arbeiten wir alle mit Anwendungen. Dies gilt auch für Linux Mint Nutzer. Die meisten Anwendungen die Linux Mint vorinstalliert sind Gnome Anwendungen und dies wird nun zunehmend ein Problem.

Da Gnome seine Umstellung auf "libadwaita" bei allen Core-Apps inzwischen vollzogen hat und Linux Mint diese so nicht verwenden will. Kurzer Abriss hierzu "libadwaita" ist ein Gnome-Framework das auf GTK4 aufbaut. Damit können Entwickler sehr schnell GUIs für Ihre Apps bauen die sich nahtlos in den Gnome Desktop einfügen. Dieses Framework hat aber für alternative GTK-Desktops (wie Cinnamon, Mate und XFCE) den Nachteil das sie sich nicht ins System einfügen. Das beginnt damit, dass libadwaita Apps nicht das Design (Theme) der Desktops übernehmen und geht weiter damit das sie keine klassische Ansicht bestehend aus Titel und Menüleiste mehr gibt sondern nur noch einen grossen Header mit Buttons haben.

Ich habe mich schon öfter gefragt wie Linux Mint damit umgehen möchte, dass immer mehr Standard-Apps dieses libadwaita Design übernehmen. Bisher hat das Linux Mint Team um Clement Lefebvre viele Apps in der jeweils letzten Version ohne libadwaita geforkt und eine "X-App" daraus gemacht. Und die selber weitergepflegt.

Die miesere mit den X-Apps​

Die eben angesprochenen X-Apps haben aber eigene Probleme. Ursprünglich war die Vision, dass die X-Apps neue "Standard" Apps für alle möglichen GTK-Desktops und Distributionen werden können die nicht auf Gnome basieren. Das ist nicht passiert. Viele Distributionen z.b. auch Debian (die wohl das grösste Paketarchiv von allen Distributionen haben) liefern die X-Apps nicht mal in ihren Repositories aus.

Und bei den Distributionen die die X-Apps in ihren Repositories anbieten (btw. ich bin überrascht, das Fedora das tut) sind die Apps aber nicht standardmässig installiert. Für Clement Lefebvre und sein Team bedeutet das aber auch, dass sie die Arbeit rund um die Pflege der X-Apps selber machen müssen und beinahe keine Hilfe von aussen bekommen. Diese Pflege wird nun auch zunehmend erschwert. Als Beispiel die X-App "xviewer" das ist der Bildbetrachter in Linux Mint und ist ein Fork von dem Gnome Bildbetrachter "Eye-of-Gnome". Bisher konnte das Team Sicherheits- und Bugfix Updates vom Eye-of-Gnome Projekt relativ leicht auf ihren Xviewer adaptieren da es sich ja um die selbe Codebasis handelt.
Inzwischen hat aber das Gnome-Projekt die Entwicklung von Eye-of-Gnome zugunsten einer komplett neuen App (Loupe) mit neuer Codebasis aufgegeben. Bedeutet die Betreuung von Xviewer wird nun anstrengend und zeitintensiver.

In seinem aktuellen Blogbeitrag äussert Clement Lefebvre auch seinen Unmut darüber, dass z.b. die Xubuntu Community die Ubuntu mit dem XFCE Desktop herausbringen nicht auf die X-Apps zurückgreifen sondern ein inkonsistentes Desktop-Design ausliefern indem immer mehr Apps in Xubuntu libadwaita Apps sind.

Bildschirmfoto von Xubuntu mit zwei Apps. Links einer libadwaita App und rechts einer normalen App. Anhand diesem Bildschirmfoto sieht man sehr gut das Xubuntu out-of.the-box ein sehr inkonsistentes Design ausliefert:

Was passiert nun mit Linux Mint 22?​

Linux Mint 22 wird wohl diesen Sommer herauskommen und auf Ubuntu 24.04 basieren. Im Grunde sieht Clement Lefebvre nur drei Möglichkeiten. Entweder das selbe zu tun was Ubuntu mit dem Yaru-Theme macht. Ein globales Theme entwickeln, dass die libadwaita Apps zumindest optisch an das Linux Mint Theme anpasst. Diese Möglichkeit zeigt er im Blogbeitrag zwar auf aber verwirft sie auch gleich wieder.
Diese Entscheidung würde bedeuten, dass Nutzer keine Custom-Themes mehr installieren könnten - und man das Theming für Linux Mint komplett über Board werfen müsste. Gleichzeitg löst man damit aber das grundlegende Problem nicht. Die Apps funktionieren dennoch anders. Headerbar statt Menüliste. Und man ist weiterhin abhängig von Entscheidungen von Gnome - falls z.b. libadwaita irgendwann die Möglichkeit zum minimieren von Fenstern verliert (standardmässig gibt es die Funktion in Gnome nicht, da das Bedienprinzip von Gnome kein minimieren vorsieht) müsste Linux Mint das dann auch übernehmen. Daher diese Option ist nicht der Weg.

Eine andere Option wäre, bei allen betroffenen Apps die letzte "Nicht-libadwaita" Version zu forken und dem X-App Projekt hinzuzufügen. Da dort Entwicklung aber sehr stockt, zunehmend kompliziert wird und auch nicht absehbar ist da das Hilfe aus anderen Projekten oder Distributionen kommt verwirft Clement Lefebvre auch diese Option.

Daher Linux Mint 22, wird nun einfach die veralteten Apps (bevor sie zu libadwaita migriert sind) nutzen. Betroffen sind folgende Anwendungen:

• Celluloid
• GNOME Calculator
• Simple Scan
• Baobab
• System Monitor
• GNOME Calendar
• File Roller
• Zenity

Für Linux Mint User ist diese Situation schade. Gerade wenn man an den Gnome Kalender denkt, der in den letzten 4-5 Versionen extrem viele Verbesserungen und neue Funktionen bekommen hat und inzwischen eine wirklich gute Kalender-Anwendung ist. Linux Mint Nutzer werden mit Linux Mint 22 diese Verbesserung nicht bekommen und weiterhin mit einem sehr veraltetem und rudimentären Kalender leben müssen.

Meine eigene Meinung zur App-Problematik in Linux Mint:​

Ich verstehe das Problem und den Lösungs-Ansatz von Clement Lefebvre. Bin aber der Meinung das diese Lösung nicht wirklich durchdacht ist und denke den Weg der Ubuntu mit Yaru eingeschlagen hat für Linux Mint auch der bessere Weg wäre. Einfach aus dem Grund, das die Anwender von Linux Mint ja nicht nur die "Standard-Apps" die bei der Installation installiert werden verwenden.

So gut wie alle Leute die Linux Mint installieren werden das App-Center öffnen und dort nach weiteren Apps suchen. Wenn man bedenkt, dass Linux Mint standardmässig Flathub in das App-Center einbindet macht der Entwickler hier dem Anwender keine grosse Freude.

Flathub ist randvoll mit libadwaita Apps und gefühlt täglich kommen da neue hinzu. Und wenn eine App nicht libadwaita ist, ist sie mit grosser Wahrscheinlichkeit eine QT App, die sich ebenfalls nicht optimal in das Standard-Layout einpasst. Somit haben Linux Mint Nutzer einen konsistenten und einheitlichen Desktop bis sie das erste mal eine andere Anwendung installieren - das kann keine gute und durchdachte Lösung sein.

Clement Lefebvre ist sich dieses Problems auch bewusst. Er macht in seinem Blog-Beitrag einen leicht verzweifelten Aufruf an die Upstream-Entwickler möglichst libadwaita für das Entwickeln ihrer Apps nicht zu benutzen.

Langfristige Zukunft von Linux Mint App und Toolkit Situation​

Im Blogbeitrag selbst geht Clement Lefebvre nicht auf diese Frage ein. Aber er beantwortet viele Kommentare in seinem Blogbeitrag und gibt dort ein paar weitere spannende Gedankengänge an.

So sagt er, dass er zurzeit nicht plant Cinnamon von GTK3 auf GTK4 zu portieren. Hauptsächlich aus dem Grund, dass er nicht sicher ist ob GTK in Zukunft noch das richtige Toolkit für den Cinnamon Desktop sein kann. Zurzeit finden bereits die ersten Diskussionen zu GTK5 statt - und dort werden Dinge diskutiert wie die "Theming-Optionen" komplett aus dem Toolkit zu entfernen was gar nicht im Interesse von Cinnamon sein wird.

Gleichzeitig sagt er aber auch, dass QT eine Alternative sein könnte er aber auch nicht der grösste Fan davon ist. Es sei zurzeit sehr schwierig vorauszusagen wo Linux Mint in 5 oder 10 Jahren stehen wird. Ob er und sein Team es alleine fertig bringen einen GTK3 Fork langfristig selber zu pflegen halte ich persönlich für fragwürdig - daher die Entwicklung von Linux Mint in den nächsten Jahren dürfte durchaus spannend werden.

 

[s1ave77]

Die miesere mit den ...

Misere .

 

[tipmyredhat]

Mints Festhalten an Cinnamon, der ja als Alternative zu Gnome 3 gebaut wurde, ist einerseits verständlich, da Cinnamon ja mehr oder weniger das Alleinstellungsmerkmal von Mint ist - Andererseits ist das genau der Grund, warum Mint imho auf lange Sicht scheitern wird.

Das stimmt nicht (mehr) ganz. Ein weiteres Merkmal ist die Abkehr von Snaps im Vergleich zur Ubuntu Basis. Nicht ganz unwichtig mittlerweile für viele User.

Was Gnome angeht: Meine Hoffnungen ruhen hier auf der neuen Version vom Cosmic Desktop. Wenn sie die richtigen Schlüsse aus der Litanei an Gnome fails ziehen (und die positiven Designkonzeptem zur Inspriration dienen), könnte hier etwas wirklich großes entstehen.
In dem Fall würde Gnome langfristig irrelevant.

 

[lutzpime]

Also ich komme mit Mint + Cinnamon immer noch am besten zurecht und hoffe, dass das Projekt noch lange weiter geht.

 

[@mo]

einerseits verständlich, da Cinnamon ja mehr oder weniger das Alleinstellungsmerkmal von Mint ist

Eigentlich auch nicht. Mittlerweile gibt es ja eine offizielle Ubuntu-Cinnamon Version. Nachdem das lange eine Einbahnstraße von Ubuntu zu Mint war, hat man die Fahrtrichtung nun halt mal umgedreht.

Weswegen ich auch nicht so ganz nachvollziehen kann, warum Mint immer noch von vielen als "die" Ein- und Umsteiger-Distro empfohlen wird.

Self fulfilling prophecy!

 

[kim88]

Ob Cinnamon nun unter Ubuntu, Linux Mint, Fedora Arch oder sonst was läuft - die Problematik von Frankenstein-App aussehen hat man ja überall.

 

[andy_m4]

Man könnte auch mal über libadwaita diskutieren.
Der Ansatz, das man eine einheitliche Oberfläche hat die von Phone bis Desktop quasi gleich aussieht ist zwar auf der einen Seite interessant, weil man dann sein(e) Programm(e) ohne Umgewöhnung überall gleich benutzt.
Auf der anderen Seite hat es aber auch den Nachteil, das man auf die verschiedenen Gegebenheiten kaum Rücksicht nimmt. Auf nem kleinen Display eines Smartphones macht es natürlich Sinn, Elemente platzsparend anzuordnen und Buttons etc. so zu designen, das sie auch von Grobmotorikern mit dicken Fingern zu bedienen sind.
Auf nem Desktop-Rechner mit großen Bildschirm habe ich aber den Platz. Also will ich ihn auch ausnutzen, indem halt bestimmte Bedienelemente direkt verfügbar sind usw.
bzw. Dinge nicht unnötig im Weg sind, nur damit sie gut "touchable" sind.

Ideal wäre es natürlich, wenn framework-Supported unterschiedliche Modes zur Verfügung stehen würden. Damit man bei nem Small-Touch-Display das Programm anders aussiehen kann, als auf nem großen Computerbildschirm.
Das würde zwar den Entwicklungsaufwand erhöhen. Aber ich denke mal, an vielen Stellen ließe sich das zumindest halbautomatisieren.
Und da sich was zu überlegen wäre auf jeden Fall innovativer, als einfach nur ein an Mobil angepasstes Design zur Vorgabe zu machen.

Was Cinnamon angeht: Deren Vorgehensweise kann ich ein stückweit verstehen. Ob das zukunftsfähig ist, weiß ich auch nicht. Ist aber letztlich auch gar so wichtig. Ich finde es trotzdem gut, weil es gelebte Diversität ist und die Linux-Community ist doch sonst immer so stolz darauf, unterschiedliche Desktop-Varianten bieten zu können. Und selbst wenn das mit Cinnamon schief geht und dann in ein paar Jahren eingestampft wird, ist das nicht dramatisch. Nur weil ich mich evtl. heute für Cinnamon entscheide, heißt das ja nicht, das ich meine Entscheidung bis ans Lebensende so durchziehen muss. Sprich: Wenn Cinnamon auzfgrund fehlender Pflege, Bugs etc. irgendwann keine Option mehr ist, dann steige ich halt auf etwas Anderes um.

Was das Problem angeht, das ich mit Programmen mit unterschiedlichem Look auf meinem Desktop konfrontiert bin: Mag zwar nicht schön sein, aber damit kann ich leben. Außerdem war man damit bei Linux schon irgendwie immer konfrontiert. Diskussion a-la KDE/QT-Programme unter GNOME/GTK (und umgekehrt) gibts schon seit Jahrzehnten.

 

[jenzen]

Das stimmt leider schon, dass bei Gnome "Interface-Nazis" manche Entscheidungen treffen. Es ist zwar wichtig bei GUIs, eine einheitliche Oberfläche möglichst zu "forcieren", aus Konsistenzgründen. Aber bei Gnome sträuben sie sich ja manchmal auch gegen Kompatibilitätsfeataures, die alle anderen DEs berücksichtigen oder supporten, aber Gnome dann teilweise nicht oder es kocht ein eigenes Süppchen. Ich mag Gnome vom UI und Bedienung her, nur die Politik der Gnomeentwickler ist an manchen Stellen wirklich unverständlich. Das kann man auch als Gnome-User kritisieren. Es ist denke ich sicher nicht schlecht, wenn Cosmic bald released und die Welt der "Gnome-ähnlichen DEs" noch mal etwas aufwirbelt.

 

[kim88]

Auf nem kleinen Display eines Smartphones macht es natürlich Sinn, Elemente platzsparend anzuordnen und Buttons etc. so zu designen, das sie auch von Grobmotorikern mit dicken Fingern zu bedienen sind.
Auf nem Desktop-Rechner mit großen Bildschirm habe ich aber den Platz.

Ich glaube klassische "stationäre Rechner mit irgendeinem 27 oder 32 Display" stehen absolut nicht im Fokus von Gnome. Gnome fokussiert sich auf Notebooks (abgesehen von Smartphones und Tablets die meist verkaufsten Computer).

Das ganze Bedienkonzept - gerade mit den Touchpad Gesten um in die Übersicht zu kommen, oder Apps bzw Workspaces zu wechseln ist komplett darauf ausgelegt. Mit einer klassischen Maus würde ich persönlich kein Gnome benutzen wollen.

Mein letzter Desktop Rechner den ich hatte stammt aber auch von 2011.

Ideal wäre es natürlich, wenn framework-Supported unterschiedliche Modes zur Verfügung stehen würden. Damit man bei nem Small-Touch-Display das Programm anders aussiehen kann, als auf nem großen Computerbildschirm.
Das würde zwar den Entwicklungsaufwand erhöhen. Aber ich denke mal, an vielen Stellen ließe sich das zumindest halbautomatisieren.

Naja im Grunde macht das libadwaita ja. Nennt sich "Responsive" wie bei Webseiten.

Als Beispiel hier die Fahrplan-App "Railway" (https://flathub.org/apps/de.schmidhuberj.DieBahn)
Auf kleinen Bildschirmen wie Smartphones sieht sie so aus:

Auf grossen Bildschirmen so:

Sprich auf kleinen Bildschirmen navigierst du dich quasi durch die 3 Screens, auf einem grossen Bildschirm siehst du sie direkt übersichtlich beieinander.

Das ist am Ende ja einer der grossen Vorteile der Entwickler wenn sie libadwaita nutzen. Egal ob jemand das Ding nachher auf nem Smartphone oder grossen Bildschirm nutzt die App passt sich automatisch an ohne das der Entwickler da noch gross selber was anpassen oder Coden muss - er kann sich komplett auf die Funktionalität konzentrieren und muss sich nicht um die GUI kümmern - und hat danach trotzdem eine GUI die auf allen Geräteklassen funktioniert, im Light & Dark Mode ohne Bugs auskommt und (sofern Gnome da mal vorwärts macht) auch Akzentfarben unterstützt.

Ergänzung (10. Mai 2024)

Es ist denke ich sicher nicht schlecht, wenn Cosmic bald released und die Welt der "Gnome-ähnlichen DEs" noch mal etwas aufwirbelt.

Ich bin auch auf Cosmic gespannt - obwohl es bisher im Grunde wie ein "Gnome Nachbau wirkt" und ich mir da wieder ein bisschen die Sinn Frage stelle. Aber erst mal das finale Produkt abwarten. Aber ich hab teilweise schon meine Zweifel, wenn ich die Blogbeiträge von System76 durchlesen und dann so Dinge wir "Frosting Glass Effect" als Feature sehe habe ich teilweise meine Bedenken.

Gespannt bin ich ob sich das Framework "Iced" durchsetzen wird. Zurzeit hat Iced ja nur eine Anbindung an Rast - was viele Drittentwickler wohl eher vor einer Hürde stellt. Aber wie gesagt wir werden sehen.

 

[andy_m4]

Ich glaube klassische "stationäre Rechner mit irgendeinem 27 oder 32 Display" stehen absolut nicht im Fokus von Gnome. Gnome fokussiert sich auf Notebooks

Naja. Das ist jetzt schon ein bisschen Haarspalterei. Selbst auf nem Laptop ist der Bildschirm immer noch größer als auf nem Phone.

Das ganze Bedienkonzept - gerade mit den Touchpad Gesten um in die Übersicht zu kommen, oder Apps bzw Workspaces zu wechseln ist komplett darauf ausgelegt. Mit einer klassischen Maus würde ich persönlich kein Gnome benutzen wollen.

Ja logisch wirst Du es so nicht benutzen wollen, weils darauf nicht ausgelegt ist.
Genau das war doch mein Punkt.

Sprich auf kleinen Bildschirmen navigierst du dich quasi durch die 3 Screens, auf einem grossen Bildschirm siehst du sie direkt übersichtlich beieinander.

Ja. Responsive ist schon nett, aber natürlich immer noch weit von dem Weg, was ich meinte.

Das ist am Ende ja einer der grossen Vorteile der Entwickler wenn sie libadwaita nutzen. Egal ob jemand das Ding nachher auf nem Smartphone oder grossen Bildschirm nutzt die App passt sich automatisch an ohne das der Entwickler da noch gross selber was anpassen oder Coden muss

Ja. Aber die Anpassbarkeit ist halt doch ziemlich begrenzt.
Bei kleinen Programmen wie diese Bahn-App fällt das natürlich nicht auf, weil die nicht viel können muss. Das lässt sich mit Responsive natürlich besser erschlagen, als wenn Du jetzt ein komplexes Programm wie beispielsweise eine Bildbearbeitung oder ein Textverarbeitungsprogramm hast.

 

[gimmix]

Ein weiteres Merkmal ist die Abkehr von Snaps im Vergleich zur Ubuntu Basis. Nicht ganz unwichtig mittlerweile für viele User.

Blockieren von Snaps ist kein Alleinstellungsmerkmal von Mint.

 

[andy_m4]

Oh nein. Nicht schon wieder. :-)

 

[Spock37]

Ich habe das Gnome-Projekt nie verstanden. Statt wirklich brauchbare, featurereiche Programme zu entwickeln, die ordentlich miteinander kommunizieren, haben sie sich darauf beschränkt, einmal pro Jahrzehnt das Toolkit zu wechseln und das Rad neu zu erfinden.

Das letzte Gnome, das ich halbwegs gerne benutzt habe, war Version 1.4. Mit "Mono" flog es bei mir auch aus Prinzip endgültig raus. Zum Glück war das einfach: "Mono" in Synaptic abwählen und weg war der ganze Zirkus.

Das "neue Gnome" hat ja nicht einmal mehr ein vernünftiges Fenstermanagement. Ich bin deswegen vor vielen Jahren auf XFCE als Default ungestiegen, betrachte aber KDE mit Plasma und der Programmsammlung als eigentlichen Haupt-Produktionsdesktop, der auf modernen CPU ab Skylake oder Ryzen inzwischen auch in virtuellen Maschinen annehmbar flott läuft.

Ich kann nicht verstehen, warum so endlos viele Ressourcen in Gnome versenkt werden. Ich finde es ästhetisch nicht grundsätzlich schlecht, denn es sieht endlich mal etwas anders aus, als der Rest. Aber ich finde es eben funktional schlecht. Mit Snap geht es mir genauso. Ich kann zwar nachvollziehen, dass das Konzept statischer, exklusiver Libraries wiederkommt, aber bei weitem lieber wäre es mir, es würden wir z.B. bei Apple vernünftige Grundbibliotheken entwickelt und standardisiert. Wohin dieses Kreuz-und-quer-Gelinke samt zahlloser unnützer Compileroptionen hinführt, haben wir ja gerade gesehen.

 

[andy_m4]

Aber ich finde es eben funktional schlecht.

Das ist ja vielleicht auch Geschmackssache.

Ich kann nicht verstehen, warum so endlos viele Ressourcen in Gnome versenkt werden.

Naja. Ist ja deren Entscheidung was die mit ihrer Zeit und ihren Ressourcen machen.

 

[jenzen]

Das sind ja voneinander komplett unabhängige Projekte, wo niemand obendrüber sitzt und irgendwas befehlen kann. Und das ist auch gut so, denn ansonsten wäre es ja keine offene und neutrale Sache mehr wo verschiedenartige Projekte miteinander "konkurrieren" wer das beste macht, sondern alles würde aus einer Hand stammen. Und wenn die Hand dann mal Mist baut, hat man keine Alternativen mehr.

 

[Spock37]

Ich fand, es war immer ein riesiger Vorteil von X-Windows, dass ein separater Fenstermanager ein Fenster anordnen, minimieren oder notfalls auch schließen konnte, auch wenn das darin ablaufende Programm abgestürzt war. Dazu die Netzwerktransparenz.

Warum ausgerechnet Red Hat davon abgekehrt ist und zudem noch einen übermächtigen binären Dämon wie Systemd entwickelt hat, erschließt sich mir nicht.

Mir scheint da strategisch etwas falsch gelaufen zu sein. Die Kunden zahlen ein Heidengeld für Red Hat, und nun müssen sie lernen, dass der zentrale Initialisierungsdämon ohne Not und viel zu früh einzelne, sicherheitskritische Komponenten einbindet, die von einzelnen Hobbymaintainern gepflegt werden. Im Prinzip erinnert mich jener Vorfall aber genau das an die damalige Diskussion um den Systemd, die zu mehreren Forks geführt hat: überkomplex, undurchsichtig, widerspricht der Unix-Philosophie, inkompatibel zu Nicht-Linux-Unixen.

Man könnte sich wohl kaum weiter von einer Sicherheitsphilosophie z.B. eines OpenBSD entfernt haben. Letztlich ist es mir aber egal, soll IBM halt die Kohle steuerlich abschreiben.

Das hat jetzt nicht direkt etwas mit Gnome zu tun, weist aber meiner Meinung nach darauf hin, dass Ressourcen im kommerziellen GNU/Linux-Bereich seit langer Zeit nicht unbedingt sinnvoll verteilt werden. Mir hat noch niemand erklären können, welche Vorteile Gnome oder Unity z.B. gegenüber KDE, XFCE oder Mate haben.

 

[jenzen]

Ich glaube im Businessumfeld sind Argumente bzgl. Qualität, Modernheit etc. nicht so wichtig wie Argumente bzgl. Tradition ("haben wir schon immer so benutzt") und Stabilität/Konservativität ("das funktioniert schon seit Jahren so, sollten wir bei bleiben").
Gnome war halt im Laufe der letzten 25 Jahre oder so immer relativ stabil und solide (mal von dem UI-Paradigmen-Change von Gnome 2 auf Gnome 3 abgesehen) während KDE bspw. etwas holpriger war bei den Releases. KDE 4 kam auch überhaupt gar nicht gut an damals. Noch dazu gab es früher Lizenzbedenken wegen dem Qt-Toolkit, glaube das ist auch ein großer Faktor - Qt war zwar immer Open Source, aber irgendwie nur für personal use lizenzfrei, im kommerziellen Umfeld nicht. Das hat sich irgendwann geändert. Aber ich glaube, wenn das erst mal am Anfang in eine bestimmte Richtung geht, dann ändert sich da im Businessumfeld nicht mehr viel. Da wird bei dem geblieben was man halt hat und kennt, was vielleicht vor Annodazumal die beste Lösung war, das muss jetzt schon längst nicht mehr die beste Lösung sein, aber das ist halt historisch so gewachsen, und solange es nicht kaputt geht oder von heut auf morgen viel zu teuer wird, bleibt man halt dabei.
Ist glaube ich sogar allgemein bei vielem so... Facebook und X sind auch nicht tot zu kriegen, sie waren halt am Anfang die populärsten und die User kriegste einfach nicht mehr weg davon, wenn die sich da einmal breit gemacht haben. Deshalb können sich die Firmen ja auch so viel rausnehmen bei der Enshittification von Services/Apps. Die User bleiben größtenteils trotzdem erhalten.

 

[andy_m4]

Vorteil von X-Windows

Ich benutze X11 ja auch nach wie vor, aber man muss schon sagen, das es auch ganz klar seine Schwächen hat. Das man da einen Nachfolger an den Start bringt, wundert mich jetzt nicht.
Und man kann natürlich über Wayland viel diskutieren und auch das hat seine Schwächen. Aber es ist auch nicht wirklich schlimm.

Systemd

Also das man einen Ersatz für das altehrwürdige System-IV-Init brauchte, war klar. Und auch hier: Ich bin kein Fan von systemd, aber es macht trotzdem Vieles richtig.
Das man da viel dazu packt, darüber kann man sicher diskutieren. Aber Du hast ja trotzdem eine gewisse Modularität.
Außerdem trägt es auch ein bisschen zur Vereinheitlichung von Linux bei. Man hat ja immer das Problem, das die Distributionen etwas unterschiedlich in dem sind wo Dateien liegen etc.
Und systemd hat zur Vereinheitlichung fast mehr beigtragen, als alle Standardisierungsbemühung die es gab (LSB usw.).

Hätte man Dinge bei systemd besser machen können? Absolut. Aber egal, welchen Weg Du gehst, so wird es immer Leute geben die etwas (und durchaus auch zu Recht) zu kritisieren haben.

binären Dämon

Was an dem Binär so schlimm sein soll, weiß ich jetzt nicht. Ist ja nicht so als hätten die Leute ständig an System-IV-Init herumgehackt und wären da ständig im Quellcode gewesen.
Und selbst wenn man das Argument bringt: "Das Init-System ist eine wichtige Komponente. Das sollte zugänglich sein."
Ja und? Der Kernel ist auch eine wichtige Komponente und der ist auch binär.

ohne Not und viel zu früh einzelne, sicherheitskritische Komponenten einbindet, die von einzelnen Hobbymaintainern gepflegt werden.

Welche meinst Du da jetzt konkret?

überkomplex, undurchsichtig

systemd ist komplex. Aber ist ja nun nicht so, das ein Sys-IV-Init-System total simpel war. Klar. Das Init-Programm als solches war simpel. Bei den Diensten sah das aber anders aus. Das waren Shell-Skripte, was nicht nur langsam war, sondern auch dazu geführt hat, das viel Code doppelt vorkam.
Ein Abhängigkeitsmanagment gab es quasi nicht, so das man sich (als Distributor) selbst um alles kümmern musste. In der Gesamtheit war das auch recht komplex.

inkompatibel zu Nicht-Linux-Unixen

Das ist nicht wirklich von Belang. Beispielsweise die BSDs haben schon zuvor kein Sys-IV-Init benutzt, sondern haben gefühlt schon ewig ihr jeweiliges rc-System.

Sicherheitsphilosophie z.B. eines OpenBSD entfernt haben

Naja. Auch darüber kann man streiten. systemd bietet auch einige Features, womit Du Daemons limitieren kannst ohne darauf angewiesen zu sein, das sich da der Programmauthor selbst drum kümmert.

Auch sowas wie Logging mit journald hat durchaus seine Vorzüge.

Schon allein, das man so was wie trusted fields hat. Bei syslog läuft das mehr oder weniger so, das der Prozess der das Log schreibt sagt: "Ich bin ABC und schreibe die Message XYZ". Und an der Stelle "Ich bin ABC" kann der halt lügen. Bei systemd-journald sagt der Log-Daemon aus, welcher Prozess den Logeintrag schreibt. So lassen sich viel schwerer Log-Messeges 'unter falscher Flagge' ins Log einschleusen. Oder auch der Umstand, das systemd-journald Vorkehrungen trifft, damit man Log-Messages nicht im nachhinein manipulieren kann (kann man beim klassischen syslog-Daemon auch, indem man das Apppend-Only-Fileflag setzt, aber das fällt einem dann bei Log-Rotation wieder auf die Füße).

Klar hat auch das seine Nachteile. Aber trotzdem sollte man differenziert drauf gucken und nicht nur sagen "Alles doof".

war bei den Releases. KDE 4 kam auch überhaupt gar nicht gut an damals.

Die Nuller-Versionen bei KDE sind mit Vorsichtig zu genießen. :-)
Das ist aber auch nix Neues. eine X.0-Version bedeutet in erster Linie, das die API fest stehen und damit wird quasi der offizielle Startschuss für die weitere Entwicklung gegeben.
Der Fehler liegt hier eher bei den Distributoren, die das dann aufgenommen haben als wenn es eine komplett fertige, stabile Version ist. Und von einem Distributor kann ich erwarten, das der das auch fachmännisch einschätzen kann. Da würde ich also eher den betreffenden Distributionen einen Vorwurf machen, als KDE.

Das hat sich irgendwann geändert.

Irgendwann ist gut.
Im Jahre 2000. Seitdem gibts Qt auch unter GPL.
Seit 2009 sogar unter LGPL

 

[jenzen]

It's been a while...
Ja, wobei sich bei KDE 4 der Unmut generell auf alle 4er-Versionen bezogen hat, nicht nur auf die Dot Zero.

 

[andy_m4]

wobei sich bei KDE 4 der Unmut generell auf alle 4er-Versionen bezogen hat, nicht nur auf die Dot Zero.

Ja. Weil KDE4 auch einige Sachen anders gemacht hat.
Als Reaktion entstand ja auch der Trinity Desktop, der auf der Vorgängergeneration aufsetzte.