KDE Linux ist ein derzeit noch im Alpha-Stadium befindliches, mit Btrfs als Dateisystem erstelltes modernes, unveränderliches Basissystem nach dem A/B-Prinzip mit doppelt redundanten Root-Dateisystemen und Wayland sowie UEFI als Voraussetzung. Die Basis bildet Arch Linux. Es wird allerdings kein Pacman-Paketmanagement und auch keinen Zugriff auf das AUR geben.
Low-Level-Tools
Als unveränderliche Distribution (für mich immer noch die falsche Kategorisierung solcher Distributionen) muss KDE Linux Wege finden, die die Nutzung von Tools auf einer tieferen Systemebene ermöglichen und Entwicklern und Enthusiasten entgegenkommen. Hierzu waren Homebrew, Distrobox und der Paketmanager Nix in der Diskussion, aber keins der Tools erwies sich als rundum geeignet.
Kapsule
Das führte zur Entwicklung eines eigenen Tools namens Kapsule, einer auf Incus aufbauenden, containerbasierten Erweiterungsschicht für KDE Linux. Der Ansatz ähnelt Distrobox, das aber auf Docker oder Podman basiert. Kapsule ist ein Tool zur Installation von Software in langlebigen Containern, das sich hervorragend in Konsole und das übrige Betriebssystem integrieren lässt. Integrationen in Kate, Systemsettings und Discover sind bereits angedacht. Kapsule wird in einigen Blogposts von Entwickler Lasath Fernando näher vorgestellt.
Schlankes Basissystem
Mit Kapsule soll die Host‑Installation schlank gehalten werden und Toolchains, Docker/Podman, Sprachen und SDKs sollen in Kapsule‑Containern leben, die sich nahtlos wie lokale Sitzungen anfühlen. Es setzt auf Incus‑Features wie privilegierte Container, Device‑Mapping und REST‑API, um langlaufende, systemähnliche Dev‑Umgebungen aufzubauen. Ein spezielles Profil, das unter anderem security nesting aktiviert, ermöglicht es, Docker oder Podman im Container zu betreiben. In der Vision des KDE‑Linux‑Teams soll Kapsule so stabil werden, dass Dinge wie ZSH, Git, Clang/GCC, Docker/Podman und Distrobox/Toolbox aus dem Basissystem verschwinden und nur noch in Kapsule‑Containern leben.
Roadmap
Weitere Entwicklungsschritte bei KDE Linux hat Nate Graham auf seinem Blog beschrieben. Was für eine Beta noch zu tun ist, wird aus der Roadmap ersichtlich. Es gibt bisher keine zeitlichen Angaben für eine Beta-Version. Nach meiner Einschätzung ist sie auf alle Fälle noch einige Monate entfernt. Eine Anleitung zum Test der Daily Builds findet sich auf der KDE-Webseite.
Ah, KDE Plasma, das einst so glänzende Beispiel der Linux Welt. Doch wie ein alter, vergessener Code ist es nun zu einer Quelle des Ärgernisses geworden. Der Doppelklick als Standard? Ein brillanter Schachzug von Nate Graham, der uns allen zeigt, wie man Effizienz und Benutzerfreundlichkeit ad acta legt. Was könnte effizienter sein, als einen zweiten, völlig unnötigen Klick zu tätigen?
Und dann die endlose Beta Phase. Es ist, als ob KDE in einem Zeitloop feststeckt, wo jeder Bug-Report in den Abgrund des Vergesse gerät. Discover, das so viele Probleme hat, ist ein Paradebeispiel dafür. “Das wird in der nächsten Version behoben” ist ihre Standardantwort, und was bedeutet das schon? Vielleicht in fünf Jahren, wenn die Technologie bereits veraltet ist. Und selbst in Debian Old Stable finden sich noch die Geisterfehler von KDE Plasma, die wie Zombies umherwandern.
Aber lassen wir mal einen Blick auf die Alternativen werfen. Cosmic zum Beispiel, ein Desktop, der mit innovativen Ideen glänzt. Er verzaubert mit seinem dynamischen Ansatz und seiner Flexibilität. Cosmic zeigt, wie ein moderner Desktop aussehen kann, der sowohl Schönheit als auch Funktionalität in sich vereint. Es ist, als ob die Entwickler dort wirklich auf die Bedürfnisse der Nutzer hören und nicht nur auf ihre eigenen Vorlieben.
Hyperland ist eine weitere Option, die sich mit Kreativität und Klarheit hervorhebt. Mit seinen anpassbaren Widgets und seinem eleganten Design ist Hyperland ein Traum für alle, die ihr System wirklich zu ihrem eigenen machen wollen. Es ist wie ein frischer Wind, der durch die Welt der Linux Desktops weht und zeigt, wie es wirklich gehen kann.
Wenn man sich diese Alternativen anschaut, fragt man sich, warum KDE Plasma es immer noch schwer hat, Schritt zu halten. Vielleicht ist es einfach Zeit für KDE, in den Schatten zu treten und Platz für neue, frischere Ideen zu machen. Denn am Ende des Tages geht es doch darum, ein System zu haben, das nicht nur gut aussieht, sondern auch wirklich funktioniert. Und da hat KDE noch einiges zu lernen.
So malt sich jeder sein Bild, so wie es ihm gefällt. Ich frage mich dann nur, wie KDE einen solchen Siegeszug hinlegt in den vergangenen zwei Jahren. Sind die Nutzer alle verblendet? Ich nutze KDE seit über 20 Jahren auf meinen Produktivsystemen und werde das auch weiter tun. Lass uns mal schaun, ob es mit Cosmic und Hyprland in 2, 3 Jahren auch noch so rosig ausschaut.
Deine Antwort ist nachvollziehbar, jedoch ersetzt sie keine fundierte, inhaltliche Auseinandersetzung mit den kritischen Punkten. Der Verweis auf einen „Siegeszug“ mag auf den ersten Blick überzeugend wirken, stellt jedoch keinen belastbaren Qualitätsindikator dar. Verbreitung resultiert oft aus Defaults, Paketierung und historischer Präsenz, was nur wenig darüber aussagt, wie konsistent, stabil oder durchdacht ein System tatsächlich im Detail ist.
Auch die längere persönliche Nutzung ist kein technisches Argument. Sie beweist Erfahrung, jedoch keine zwingende Objektivität. Wer ein System über Jahre hinweg nutzt, entwickelt Routinen und Umgehungsstrategien, die den eigenen Workflow stabilisieren, aber nichts darüber aussagen, wie gut das System für sich genommen funktioniert.
Auffällig ist, dass du auf die konkreten angesprochenen Punkte nicht eingehst. Es wäre interessant, eine Gegenposition zu den folgenden kritischen Punkten zu hören:
-Discover: Die Funktionalität und Benutzerfreundlichkeit des Software-Managers.
-Inkonsistenzen rund um Plasma 6: Probleme mit der Benutzeroberfläche und den integrierten Anwendungen.
-Der Übergang auf Wayland: Technische Herausforderungen und Stabilitätsprobleme bei der Implementierung.
Diese sind konkrete Baustellen und keine Geschmacksfragen. Gerade hier wäre eine substantielle Gegenposition wichtig gewesen.
Stattdessen verschiebst du die Diskussion in die Zukunft, indem du fragst, ob andere Projekte in zwei oder drei Jahren noch relevant sein werden. Das ist eine offene Frage, jedoch keine Antwort auf die aktuelle Kritik. Langfristige Stabilität ist sicherlich wichtig, ersetzt aber keine Bewertung des aktuellen Zustands.
Natürlich kann KDE problemlos genutzt werden, und viele Benutzer tun dies. Daraus folgt jedoch nicht automatisch, dass die angesprochenen Schwächen nicht existieren. Für eine ernsthafte Diskussion sollten wir genau dort ansetzen: bei den konkreten technischen Problemen und Schwachstellen. Alles andere bleibt eher eine Frage der Perspektive als eine der Substanz.
Und mal ehrlich, Nate Graham macht sowieso, was er für richtig hält. Die Community hat da kaum noch ein Wörtchen mitzureden. Er ist der Chef und entscheidet, wohin die Reise geht, und wir dürfen zusehen, wie er KDE in seine Vision von Perfektion transformiert ob uns das gefällt oder nicht.
Sorry, nicht böse gemeint. Ich will an dieser Stelle weder objektiv sein noch habe ich die Zeit, in eine Diskussion einzusteigen.
Interessanter Ansatz.
Manchmal muss man bestehende Lösungen hinterfragen und mutig neue Lösungen ausarbeiten.
Wir werden sehen ob es eine gute oder schlechte Umsetzung wird.
Bin echt gespannt, wie sich dass weiter entwickelt. Aber selbst wenn sich der Ansatz als falsch herausstelg, kann es einige nützliche tools und ansetzen hervorbringen.
Das neue Kde System ist das perfekte Symbol für alles, was bei Kde seit Jahren schiefläuft. Man nimmt Arch, entfernt Pacman, sperrt den Nutzer vom eigentlichen System weg, stapelt Container und Sonderlösungen drauf und verkauft das dann als Fortschritt. Das ist nicht modern. Das ist unnötig verkomplizierter Technikfetisch mit Hochglanzanstrich. Genau da passt Kapsule ins Bild. Normale Werkzeuge passen nicht mehr sauber ins eigene Konzept, also baut man wieder eine hauseigene Speziallösung und verkauft den nächsten Workaround als Vision. Erst macht man alles unnötig kompliziert, dann feiert man die eigene Krücke als Zukunft. Genau so kennt man Kde inzwischen. Dazu kommt dieser ewige Drang, alles steril, gekapselt und abstrahiert zu machen. Bloß nichts Direktes, bloß nichts Robustes, bloß nichts, was noch nach klassischem Linux aussieht. Statt Klarheit gibt es Schichten, Konzepte und Integrationsgerede. Das wirkt nicht wie ein System für Leute, die arbeiten wollen, sondern wie ein Experiment für Leute, die sich an ihrer eigenen Idee berauschen. Und Nate Graham passt da perfekt rein. Immer am Bloggen, immer am Verkaufen, immer am Erklären, warum der nächste Umweg angeblich Zukunft sein soll. Nach außen geschniegelt und offen, aber nur solange die Meinung ins Bild passt. Diese Mischung aus Selbstverliebtheit, Dünnhäutigkeit und Dauerinszenierung macht Kde inzwischen einfach nur noch abstoßend. Man muss es klar sagen… Kde ist auf vielen Distris längst nicht mehr die Krone des Linux Desktops, sondern eher ein aufgeblasener Wasserkopf mit Dauerdrang zur Selbstüberschätzung. Viel Oberfläche, viel Gerede, viel Ego. Unter dem Lack steckt oft nur Sonderlogik, die sich wichtiger nimmt, als sie ist. Dieses System treibt das alles nur auf die Spitze. Mehr Schichten, mehr Kontrolle, mehr Inszenierung, weniger Bodenhaftung. Kde wird damit nicht besser. Nur anstrengender.
Ich habe leider viel zu wenig Ahnung von den ganzen Zusammenhängen um deine Aussage für mich einzuordnen, aber sie klingt sehr überzeugend, logisch und macht mich neugierig.
Ich muss dir da fairerweise zustimmen!
Die KDE-Leute haben aktuell bereits KDE Neon, ein Ubuntu LTS mit immer aktuellem KDE (und Flatpak statt Snap). Und es funktioniert! Ohne künstliche Verrenkungen, wie es mit dem jetzt geplanten Frankenstein angedacht ist.
Welchem realistischen User Case soll das dienen? Was soll es angeblich ermöglichen, was KDE Neon nicht bereits erfüllt?
Wer sowas in der Richtung haben will, kann das mit Fedora Kinoite bereits haben. Und die Arch-Fans werden keinen Gefallen an der Verkrüppelung finden, die da zu finden ist.
Auf mich wirkt es wie ein “weil wir es können!”
KDE Neon ist mit dem Ubuntu-Unterbau und den allerneuesten KDE-Paketen für die Maintainer sehr schwer zu betreuen. Andauernd gibt es Bibliothekskonflikte. Das ist auf Dauer nicht machbar und war von Anfang an ein schlecht durchdachtes Konzept.
Da zumindest bei mir keine solchen Probleme auftreten, stellt sich mir die Frage ob es für die Entwickler leichter werden soll oder für die User. Beides scheint ja nicht zu gehen bzw. nicht gewollt zu sein.
Die Probleme treten bei dir nicht auf, weil sie vorher mühsam abgefangen werden. Die Kluft zwischen Ubuntu-LTS-Libraries und KDE direkt aus dem Git ist einfach zu groß. KDE neon war im Gegensatz zu KDE Linux auch nie als »KDE Distro« geplant, sondern sollte hauptsächlich Entwicklern verschiedene Ebenen der aktuellen KDE-Entwicklungen bereitstellen. KDE Linux soll sowohl Desktop-Anwender, Entwickler und alles dazwischen ansprechen. Schaun wir mal, ob das gelingt.
Leute echt. Ihr kennt doch Nextcloud richtig? Dank container, könnt ihr den kompletten Stack mit nur einem Befehl hochfahren und fertig ist die Cloud. So ähnlich könnt ihr euch Betriebsysteme vorstellen. Kommen 1:1 zu uns geliefert. Anmachen, funktinioniert. Programme werden mit zB Distrobox installiert und die Verknüfung in Host exportiert. Ihr würdet das nichmal merken, wenn das euch keiner erzählen würde, das die Anwendung im Container läuft… Man man man, nur am Meckern…Das ist fortschritt und ein echter Mehrwert. In der Entwicklung ist das schon zur Best-Practice geworden.
KDE geht hier für meinen Geschmack etwas zu weit und überschreitet damit seine Kernkompetenzen.
Nicht, dass es nicht auch interessant wäre, neue Ansätze für den Betrieb von Linuxsystemen zu erforschen, aber die eigentliche Aufgabe von KDE dürfte bei der Entwicklung von Qt Anwendungen und dem Plasma-Desktop liegen. Deren Stabilität testet man am Besten auf einem nativen System wo auch mal etwas schief gehen kann und nicht in abgesicherten Containern.
Insofern hätte ich KDE empfohlen, zuerst einmal für die eigene konventionelle Entwicklungsbasis zu sorgen und weitergehende Pläne für die Distribution der Zukunft auf danach zu verschieben.
So sehe ich das im Grunde auch. Ob es wohl an der guten finanziellen Situation liegt, dass man sich nicht auf die Kernkompetenzen konzentriert ?