KDE Plasma Desktop im Enterprisebereich denkbar?

[sandreas]

Hey @jenzen, vielen Dank für den ausführlichen Post.

das ist nicht nur ein Haufen Hobby-Contributors die alle an einem anderen Strang ziehen

Ich dachte nicht, dass das aus meinem Post hervorgeht, wäre auch falsch. Mit "viele Köche verderben den Brei" meinte ich zu viele "Interessengruppen" / "Parteien". Es wollen einfach zu viele Leute unterschiedliche Dinge und einen Kompromiss zu finden, ist da schwierig. Diese Behauptung stelle ich nach wie vor auf und deine Argumentation stützt dies sogar (Google, Valve... dazu IBM, Redhat, Microsoft und andere...).

Außerdem ist es auch nicht so, dass da ständig Legacy-Crap mit sich rumgeschleppt werden würde.

Das wiederum sehe ich anders. Legacy crap gibts überall - sofern das Projekt eine gewisse Größe hat, sogar im Kernel.

Auch wenn es prinzipiell OK ist wenn an neuen oder anderen Desktops gearbeitet wird (möge der Beste sich durchsetzen!), und auch die Rust-Basis sehr sinnvoll ist, bezweifle ich dass eine doch verhältnismäßig kleine Firma wie System76 hier etwas so Großes auf die Beine stellen kann dass es mit Gnome oder KDE Plasma Schritt halten kann.

Ja, ich auch... aber wenigstens steht hier nur EINE Interessengruppe dahinter. Wenn die Interessen mit meinen einigermaßen kongruent sind (und das sieht gerade so aus), dann ziehe ich das einem Riesenprojekt mit 1000 Features, die ich nicht brauche, wahrscheinlich vor.

Aber zumindest anfangs bin ich da noch etwas skeptisch. Es ist daher wahrscheinlicher, dass du deine Lieblingsfeatures früher in Gnome oder KDE Plasma sehen wirst.

Jepp, genau so sehe ich das auch. Aber ich vermute, ich werde wohl eher richtung dwm gehen. Das ist dann leichtgewichtig und für mich selbst auch wartbarer.
MEIN zentrales Problem mit diesen ganzen Desktop Environments ist eigentlich nur, dass eine Installation kaum automatisierbar ist - und hier ist auch das Problem im Enterprise bereich. Obwohl Microsoft katastrophal kryptisch ist, schaffen sie es mit Gruppenrichtlinien und Flags installationen einigermaßen Automatisierbar zu machen. Das wäre unter Linux EIGENTLICH einfacher, aber weder Gnome noch KDE hat Kommandozeilentools, womit man eine komplette Installation inkl. Konfiguration EINFACH automatisieren oder wahlweise eine Datei oder ein Verzeichnis sichern und wiederherstellen kann. In Teilen funktioniert das, aber eben nicht (immer) abwärtskompatibel inkl. allen Settings und Extensions.

Diese Features zumindest gibt es seit Kurzem schon bspw. in neueren Gnome-Versionen, die die neuesten Wayland-Features implementieren. Das erste Feature wurde vor kurzem in Mutter (der Wayland-Compositor von Gnome) implementiert.

Jain. Die Features sind häufig nur inkonsistent implementiert. Es mag sein, dass daran gearbeitet wird, aber das ist schon länger so. Mein klassisches Beispiel: Vernünftiges(!!) Kinetic Scrolling habe ich oben verlinkt, Gesten sind aber auch nur so halbgar umgesetzt. Ich habe ein MacBook Pro von 2015 (!) und da sind Gesten, Scrolling und Mauszeigergenauigkeit schon etwas völlig anderes (nicht zu reden von modernen Geräten). Das Argument: Liegt an der Hardware halte ich nicht, ich habe vor einiger Zeit nämlich auch ein Hackintosh-Notebook gehabt und da funktioniert die Steuerung ebensogut wie auf einem MacBook Pro oder Air.

Nochmal: Das ist keine Beschwerde. Ich bin sehr zufrieden mit meinem Fedora und Lenovo T480s (mit Glass-Touchpad-Mod). Ich versuche hier die Fakten zusammen zu tragen. Und Fakt ist: Obwohl der Linux Desktop benutzbar ist, ist er in einigen grundlegenden Dingen weit von der UX eines MacBook Pros entfernt.
Für Profis würde sich der Implementierungsaufwand sicher in Grenzen halten, die Quellen und Algorithment sind alle da, es ist nur so: Entweder hält es niemand für wichitg genug ODER man kann sich nicht einigen. Kinetic Scrolling z.B. wurde so lange hin und her geschoben, bis es beim App Entwickler gelandet ist (man muss Kinetic Scrolling in seiner APP einbauen, wenn man es haben will). Was ist das denn bitte für eine Entscheidung? Das ist z.B. eines der Dinge, die man bei Linux noch nicht richtig verstanden hat. Man muss es den App-Entwicklern so leicht wie möglich machen, coole Software zu schreiben... und ich finde nicht, dass man das macht.

 

[jenzen]

Ich dachte nicht, dass das aus meinem Post hervorgeht, wäre auch falsch. Mit "viele Köche verderben den Brei" meinte ich zu viele "Interessengruppen" / "Parteien". Es wollen einfach zu viele Leute unterschiedliche Dinge und einen Kompromiss zu finden, ist da schwierig. Diese Behauptung stelle ich nach wie vor auf und deine Argumentation stützt dies sogar (Google, Valve... dazu IBM, Redhat, Microsoft und andere...).

Manchmal muss man auch keinen Kompromiss finden. Beim Linux-Kernel ist das von dir zitierte "Problem" (ich sehe es halt nicht als ein nennenswertes Problem) auch sehr präsent: hier heuern große Firmen regelmäßig Entwickler an, die entweder bestimmte Features in den Kernel reinbringen oder an spezifischen Gebieten arbeiten um den Kernel noch besser in bestimmten Aspekten zu machen, z.B. I/O-Performance.
Auch wenn alle anderen das vielleicht nicht brauchen, profitieren am Ende doch alle davon, und wer's gar nicht braucht den braucht's halt nicht zu interessieren. Verbesserung ist trotzdem Verbesserung.

Bei Desktops ist es natürlich besonders(?) wichtig, eine allgemeine Vorgabe zu haben an die sich jeder halten muss, aber auch hier wird das einfach definiert (bei Gnome heißt das "HIG" oder so, also "Human Interface Guidelines"). Bei KDE gibt's sicherlich auch was ähnliches. Und wenn sich da alle dran halten, sowie auch an die grobe Roadmap des Projekts, dann wird das Resultat schon passen und es wird auch keinen Interessenskonflikt geben.

Ich teile deine Meinung zwar, dass bei Apple, wo wirklich ALLES aus einer Hand kommt, solche Visionen oder Guidelines besser/strikter umgesetzt werden können und somit gar kein Raum entstehen kann für etwaige Abweichungen oder Inkonsistenzen. Was sich auf dem Desktop schnell bemerkbar macht. Aber trotzdem denke ich nicht, dass es overall unbedingt so sein muss oder dass die andere Vorgehensweise nicht funktioniert. Tatsächlich sehe ich aus solchen Dingen resultierende Inkonsistenzen als generell sehr kleines Problem an, und ich denke auch nicht dass es lösbar ist AUSSER das Projekt wird komplett so gelockdowned wie es bei Apple der Fall ist, aber dann wäre es eben auch kein richtiges Open Source Projekt mehr.

Gnome zeigt hier denke ich noch mit am besten, dass strikte Guidelines und offenes, kollaboratives Arbeitsmodell zusammen funktionieren kann, ohne dass alles aus einer Hand kommen muss. Gnome wird zwar oft kritisiert wegen fehlender Features und Dickköpfigkeit, aber eines können sie quasi genauso gut wie Apple: konsistente, modern erscheinende UIs mit einheitlicher UX bauen. Und ich vermute stark, dass das strikte Halten an die eigenen UX-Guidelines hier maßgeblich für ist.

Das wiederum sehe ich anders. Legacy crap gibts überall - sofern das Projekt eine gewisse Größe hat, sogar im Kernel.

Ja, ich meinte nur, dass es nicht extrem lange rumgeschleppt wird. Das macht nur MS meines Wissens nach. Auch im Kernel fliegen regelmäßig Dinge raus die fast niemand mehr braucht. Bei einem bestimmten exotischen Ethernet-Treiber haben sie z.B. vorher kommuniziert dass der rausfliegen wird, dann haben sie keine Beschwerden bekommen, dann haben sie ihn rausgenommen aber in der Hinterhand sich die Möglichkeit offengehalten, ihn direkt wieder reinzunehmen falls Beschwerden kommen. Aber auch danach kamen keine Beschwerden. Also wird der wohl nicht mehr benötigt und bleibt draußen. Das ist eine sinnvolle Vorgehensweise, denke ich. Vorher kommunizieren + "Scream Test".

Jepp, genau so sehe ich das auch. Aber ich vermute, ich werde wohl eher richtung dwm gehen. Das ist dann leichtgewichtig und für mich selbst auch wartbarer.
MEIN zentrales Problem mit diesen ganzen Desktop Environments ist eigentlich nur, dass eine Installation kaum automatisierbar ist - und hier ist auch das Problem im Enterprise bereich. Obwohl Microsoft katastrophal kryptisch ist, schaffen sie es mit Gruppenrichtlinien und Flags installationen einigermaßen Automatisierbar zu machen. Das wäre unter Linux EIGENTLICH einfacher, aber weder Gnome noch KDE hat Kommandozeilentools, womit man eine komplette Installation inkl. Konfiguration EINFACH automatisieren oder wahlweise eine Datei oder ein Verzeichnis sichern und wiederherstellen kann. In Teilen funktioniert das, aber eben nicht (immer) abwärtskompatibel inkl. allen Settings und Extensions.

Gehen tut das schon. MS macht es Windows-Admins halt kinderleicht mit den Gruppenrichtlinien, das ist vielleicht ein UX-Vorteil, aber kein Alleinstellungsmerkmal. Auch Linux-Admins können zentral definieren oder deklarieren, wie das System gebaut werden soll und vorher Configfiles mit Defaulteinstellungen oder Zwangseinstellungen definieren die dann einfach nur deployed werden (z.B. mit Ansible). Oder man nimmt so etwas wie NixOS, was von sich aus deklarative und zentrale Konfiguration ermöglicht ohne Extra-Tools. Ja, sowas ist vielleicht nicht in Gnome oder KDE direkt integriert, oder wie im Fall der Gruppenrichtlinien direkt in Windows, aber dafür gibt es genügend Tools, mit denen man einheitliche Configs definieren und deployen kann. Das ist eigentlich kein Hexenwerk. Natürlich ist die genaue Konfiguration dann im Detail anders je nach eingesetztem Desktop Environment, hier haben wieder die "es gibt nur ein DE!"-Fraktionen einen Convenience-Vorteil, aber gehen tut das prinzipiell mit allen DEs. Und wenn man sich für seine Firma auf ein DE festgelegt hat, dann brauchen einen die Konfigurationen von allen anderen DEs auch nicht mehr zu interessieren.

Jain. Die Features sind häufig nur inkonsistent implementiert. Es mag sein, dass daran gearbeitet wird, aber das ist schon länger so. Mein klassisches Beispiel: Vernünftiges(!!) Kinetic Scrolling habe ich oben verlinkt, Gesten sind aber auch nur so halbgar umgesetzt. Ich habe ein MacBook Pro von 2015 (!) und da sind Gesten, Scrolling und Mauszeigergenauigkeit schon etwas völlig anderes (nicht zu reden von modernen Geräten). Das Argument: Liegt an der Hardware halte ich nicht, ich habe vor einiger Zeit nämlich auch ein Hackintosh-Notebook gehabt und da funktioniert die Steuerung ebensogut wie auf einem MacBook Pro oder Air.

Ok, wollte auch nur sagen, dass es da schon Verbeserungen gab in letzter Zeit. Für mich persönlich ist sowas meistens wenig relevant, ich arbeite fast nur mit Keyboard/Maus und verwende nur wenige Gesten an einem Notebook. Daher hab ich da persönlich auch kein großes Augenmerk drauf. Das Subset an Gesten, was ich verwende, geht überall. Ich wüsste auf Anhieb nicht mal was du mit "moderne Gesten" meinst. Außerdem muss es kein Nachteil sein, bestimmte Features nicht zu haben, wenn sie eh kaum jemand nutzt.

Manche der "moderneren" Features funktionieren unter Linux auch erst seit kurzem, weil es für sowas einen moderneren GUI-Stack benötigt als wir in der Vergangenheit und immer noch teilweise haben (X11). Für viele aktuelle Features ist ein möglichst gut ausgebauter Wayland-Compositor nötig, der vieles von Wayland abdeckt. Und auch Wayland selbst wird ja noch weiter erweitert um sinnvolle Features. Dadurch dass allein schon die Wayland-Transition so ein Riesen-Ding ist was sich über Jahre zieht, wird es noch dauern bis alle relevanten Distros die neuen Technologien verwenden. Aber lang wird es nicht mehr dauern. Je nach Distro und Software-Versions-Stand variiert der Zeitpunkt natürlich. Dann ist auch eine wesentlich bessere Basis da, als früher, um solche Dinge zu implementieren.

Nochmal: Das ist keine Beschwerde. Ich bin sehr zufrieden mit meinem Fedora und Lenovo T480s (mit Glass-Touchpad-Mod). Ich versuche hier die Fakten zusammen zu tragen. Und Fakt ist: Obwohl der Linux Desktop benutzbar ist, ist er in einigen grundlegenden Dingen weit von der UX eines MacBook Pros entfernt.

Kann sein. Aber die Frage ist immer, wie relevant ist das im konkreten Fall.
Ein anderes Problem dabei ist auch dass "UX" ein extrem unscharfer Begriff ist.

Für mich sind Dinge wie Zwangs-Integration in ein proprietäres Ökosystem ala Apple, oder EInschränkungen die man durch das Nutzen von proprietärer Software in Kauf nimmt, wesentlich schwerer wiegend als kleinere UI-Inkonsistenzen durch das Nutzen von freier Software mit unterschiedlichen GUI-Toolkits bspw. oder das Fehlen mancher Features die vielleicht manche als wichtig ansehen aber ich entweder gar nicht brauche oder die seeeehr situativ sind oder die ich auch anderweitig kompensieren oder workarounden kann.

Für Profis würde sich der Implementierungsaufwand sicher in Grenzen halten, die Quellen und Algorithment sind alle da, es ist nur so: Entweder hält es niemand für wichitg genug ODER man kann sich nicht einigen. Kinetic Scrolling z.B. wurde so lange hin und her geschoben, bis es beim App Entwickler gelandet ist (man muss Kinetic Scrolling in seiner APP einbauen, wenn man es haben will). Was ist das denn bitte für eine Entscheidung? Das ist z.B. eines der Dinge, die man bei Linux noch nicht richtig verstanden hat. Man muss es den App-Entwicklern so leicht wie möglich machen, coole Software zu schreiben... und ich finde nicht, dass man das macht.

Es ist im Open Source Bereich natürlich so, dass nach Relevanz bzw. User-Feedback gegangen wird. Wenn ein Feature als nicht wichtig oder nicht populär angesehen wird, dann wird es vielleicht gar nicht erst eingebaut. Das kann dann vielleicht Unmut hervorrufen bei ein paar Usern, die das vielleicht bei einnem anderen System (z.B. OSX) ständig nutzen das Feature und dann sozusagen die Erwartungshaltung aufgebaut haben, dass das auch beim anderen so funktionieren sollte.

 

[sandreas]

@jenzen Ich kenne die Argumente und die sind durchaus legitim. In vielen Bereichen steht keine echte "Vision" im Vordergrund, sondern viel verliert sich im Klein-Klein. Ich kenne die Mailinglisten und Diskussionen - genauso wie einige überlastete Maintainer und das klingt oft NICHT nach
"lass uns coole neue Features umsetzen und Spaß am Entwickeln haben"
sondern viel öfter nach
"ohje, dass kommt mir aber jetzt grade gar nicht gelegen, weil..." (hier deine Argumentation einsetzen)

Und wenn dann gar nichts mehr hilft, kommt dann das totschlag-Argument:

• Mach es doch selbst, ist ja Open Source

Es ist eher selten, dass man hört:

• "Hey, super Idee, lass uns das mal gemeinsam angehen - hättest du vielleicht sogar Interesse zu helfen? Hier, ich zeige dir, wie es geht."

Mir fehlt es oft einfach an folgendem:

• Wissenstransfer und dem Willen dazu
• Positive Einstellung

Aber damit die Diskussion nicht zu sehr ausufert: Ich gebe dir recht, es ist ok wie es ist. Ich bin zufrieden und wenn nicht, dann mach ich es inzwischen einfach selbst (sofern ich die Kapazitäten hab :-)

 

[Duha]

Es ist eher selten, dass man hört:

• "Hey, super Idee, lass uns das mal gemeinsam angehen - hättest du vielleicht sogar Interesse zu helfen? Hier, ich zeige dir, wie es geht."

Ich finde KDE gibt sich da sehr viel Mühe. Ich kann deine Erfahrung nicht teilen.

 

[Mondgesang]

einem handwerker würde man ja auch nicht den Akkuschrauber vorenthalten

Nein, aber ich als Bauleiter sähe es nicht gerne, wenn er den ganzen Tag damit verbringen würde, den Akkuschrauber mit bunten Stickern, Bändchen, Schleifchen zu bestücken oder den Edding rausholt und anfängt da eigene Logos und Figuren drauf zu malen, oder noch schlimmer, die Feile rausholt und anfängt den Haltegriff "an seine individuelle Handform" zu rechtzuschleifen. Ich würde wollen, dass er das Ding aus dem Werkzeugkasten rausholt wie es geliefert wurde und wie Gott es schuf und anfängt damit zu arbeiten.