KDE Plasma

Neue KDE-Distribution angedacht

Auf der diesjährigen KDE-Konferenz Akademy 2024 in Würzburg präsentierten die Entwickler eine große Anzahl interessanter Vorträge, die auf YouTube konserviert wurden. In diesem Beitrag geht es um den Vortrag von Harald Sitter, der mit »An Operating System of Our Own« betitelt ist. Harald Sitter hat 2016 zusammen mit Jonathan Riddell KDE neon aus der Taufe gehoben.

KDE neon mit Vor- und Nachteilen

Somit geht es in dem Vortrag zunächst um die Geschichte und die Vorteile und folgend dann um die sich über die Jahre herauskristallisierten Nachteile des Ubuntu-Unterbaus. Diese liegen hauptsächlich in der Paketierung und den sich daraus ergebenden Abhängigkeiten. Dabei tut sich ein Abgrund zwischen der an sich stabilen Basis Ubuntu LTS und den für neon unverzichtbaren aktuellen Paketen aus der KDE-Entwicklung auf. Zudem ist der Umstieg von einer LTS-Version auf die nächste immer ein kritischer Punkt, wie sich gerade wieder beim Umstieg auf 2024.04 LTS zeigt.

KDE-Distribution

Harald Sitter grübelt schon seit Längerem an einer Lösung und stellt in dem Vortrag ein mit dem vorläufigen Namen KDE Linux versehenes Konzept für eine echte KDE-Distribution vor, was KDE neon laut Selbstbeschreibung ja nicht ist. Anstelle von Ubuntu LTS schlägt Sitter Arch als Basis einer rollenden KDE-Distribution vor, die auch ansonsten sehr moderne Züge trägt. Es soll ein Image-basiertes Betriebssystem ohne herkömmliche Pakete nach dem von Android und Vanilla OS bekannten atomaren A/B-System werden, das lediglich Btrfs als Dateisystem bietet.

Viele Zutaten von systemd

Auf KDEs GitLab ist zu sehen, dass Sitter die Images mit mkosi baut, einem Build-Tool aus der systemd-Entwicklung. Auch ansonsten sind systemd-Komponenten wie systemd-boot, systemd-sysupdate, systemd-sysext und eventuell systemd-homed angedacht. Der gesamte Plasma-Stack soll mit kde-builder gebaut werden. Anwendungen sollen in Form von Flatpak und Snap bereitgestellt werden. Neben x86-64 wird auch über Architekturen wie ARM/RISC-V nachgedacht.

Anleitung zum Testen

Falls dieses Projekt weiter verfolgt wird, wird noch einige Zeit ins Land gehen, bevor wir ein benutzbares Projekt in Händen halten können. Der Vortrag auf der Akademy hat hoffentlich seinen Zweck erfüllt, das Projekt einer breiteren Masse an Entwicklern und Enthusiasten vorzustellen, die dazu beitragen möchten. Unter obigem GitLab-Link ist eine Anleitung zum Booten eines ersten Image zu finden, das sich auch bereits aktualisieren lässt.

Teilt den Beitrag, falls ihr mögt

20 Kommentare

  1. Den Ansatz finde ich sehr gut.
    Hatte in der Vergangenheit NEON schon mal angeschaut, aber das ist noch nicht das, was ich mir auch vorstelle.

    Meine Gedanken dazu sind folgende:
    Linux auf dem Desktop hat in den vergangenen Jahrzehnten versucht “alles nachzumachen” und ist in meinen Augen deshalb gescheitert. Die wenigsten suchen eine Alternative zu dem was sie haben. OpenOffice.org und LibreOffice haben (zumindest in den Anfangsjahren) bewußt MS-Office “nachgemacht” und versucht Benutzer zu migrieren. Da kann ich aus der Erfahrung aus Migrationen sagen, dass das so nicht geklappt und oft zu Frust geführt hat. Der Linuxdesktop hat gleichweise versucht, Windows Nutzer mit ähnlichen Bedienkonzepten zum wechseln zu animieren, der Marktanteil beantwortet wohl alle aufkommenden Fragen.

    Im Gegensatz dazu kann man Apple mit MacOS als Beispiel anschauen.
    Haben eine klar definierte Zielgruppe: Menschen, die optisch ansprechende Geräte haben wollen oder/und Menschen die ein einfach zu bedienendes System wollen.
    Dabei gibt es eine ganze Reihe an Parallelen:

    • Auf MacOS kann man nicht alles installieren, was man bei Windows installieren kann.
    • Das Office Paket von MacOS, die Kompatiblität zu MS-Office ist ähnlich gut/schlecht wie von LibreOffice/OpenOffice.org.
    • MacOS bringt Applikationen mit, die funktionieren (so wie Software halt funktioniert).

    Im Prinzip kann KDE genau an so eine Stelle treten und ebenfalls eine Niche bedienen.

    Wenn ich mir das so anschaue, ist genau dass was hier geplant wird. Ich bin leider kein Entwickler, aber wenn hier Hilfe gebraucht wird, bin ich gerne dabei. Vielleicht liest Harald ja mit oder jemand kennt ihn.

    1
    1. Was das “Koole Desktop Enviroment” angeht, stellt sich seit langem die Frage, ob Microsoft mehr bei KDE abgekupfert hat oder umgekehrt.
      Hat sich einmal eine Bedienweise als praktisch etabliert, dann muss man auch nicht auf Teufel komm raus den Button zum Anklicken ganz wo anders platzieren.
      GNOME traut sich da eher neue Wege zu gehen.
      Insgesamt eine gute Situation wenn jeweils immer eine große Linux GUI auf Vertrautes setzt und die andere neue Wege erkundet.

      Was die Verbreitung von Linux angeht, so hat sich Apple frühzeitig, Zeitungen, Grafiker und Musiker geschnappt und hat sich da einen Vorsprung erarbeitet den man kaum knacken kann.
      Microsoft hat sich in Verwaltung, Behörden und sogar in die Schulen fest eingenistet.
      Der Punkt ist nicht, dass Linux etwas falsch macht, der Punkt ist, dass ohne ein politischer Wille für Linux und freie Software kaum die Chance besteht den Fuß in die Tür zu bekommen.

      1
      1. Keinen fork, sondern das sich beide Partien an einen Tisch setzen und gemeinsam an einer Distro entwickeln. Beide Projekte würden voneinander profitieren und Zeit und Geld spart es sicherlich auch, letzteres ist ja knapp bei KDE.

        0
  2. Ich habe nie verstanden weshalb Jonathan Riddell nachdem er von Canonical gekündigt wurde, ausgerechnet an Ubuntu weiter so klebte, dass der Neon darauf aufgebaut hat. Das gibt auch technische Gründe, weshalb Ubuntu für KDE nicht ideal als Grundlage ist. Das Canonical daraus ein persönliches Problem daraus konstruierte ist ein anderes Thema. Schön, wenn man jetzt endlich bei KDE die Lehre daraus zieht.
    Bei KDE-mobile war die Trennung von Canonical äußerst fruchtbar und wenn man das Gleiche jetzt mit der PC Sparte vollzieht, dann wird man auch dort etliche kranke Umstände weniger haben.

    9
  3. Ich gebe den bisherigen Äußerungen meiner Mitformten bei ihren Überlegungen vom Prinzip her recht, würde jedoch auch KaOs als Grundlage für ein KDE spezifisches rollendes OS neben Arch und Siduction mit ins Spiel bringen wollen.

    Für ein KDE OS wäre es ideal, wenn es das Rollen mit dem Versionssprüngen von KDE synchronisiert, damit die KDE Entwickler zwischen den Versionen eine gemeinsame Entwicklungsbasis aller libs ect. pp. haben und nach der Herausgabe einer neuen Version auch eine gemeinsame Basis mit den Usern teilen.
    Man könnte als Grundlage Sid, Arch oder KaOs so belassen wie es ist und bräuchte für ein KDE-OS lediglich ein eigenes Repositorium das man so rollen lässt wie es für die KDE-Entwicklung günstig ist.

    Immutable und flatpack sind Quatsch für Entwickler und den upstream.
    Sinn machen solche Systeme nur für kommerzielle Anbieter die den Support günstiger gestalten wollen. Für KDE ist das Feedback mit den Usern entscheidend und von dem schneidet man sich mit flatpack und immutable eher ab als dass KDE etwas dabei gewinnen könnte.

    Unabhängig davon könnte KDE glänzen indem es eigene flatpacks von allen seinen Anwendungen schnürt. Aber hier schlage ich vor, dass man sich dabei auf die LTS-Versionen der jeweiligen Anwendung konzentriert.

    6
  4. Meine Erfahrung: ich habe vieles ausprobiert und ich bin bei KDE Plasma auf Devuan hängen geblieben. Das wäre nach meiner Ansicht perfekt. Reizvoll wäre vielleicht die selbe Kombination nach Art von Siduction, mit dem ich immer noch gute Erfahrungen mache (ich habe es auf ein paar Rechnern von Freunden und Familienmitgliedern installiert). Rolling Release wie Siduction auf Basis von Devuan mit KDE Plasma … ja, das wäre schon interessant.

    0
      1. Das ist auch mein Punkt.
        An einem weiteres mit systemd verseuchtet Linux brauche ICH nicht.
        Da bleibe ich dann lieber bei Artix.

        Dabei würde mich eine Rolling Linux das direkt von KDE kommt durchaus interessieren.
        Aber Immutable und Flakpak halte ich da für nicht Zielführend.

        Und zusätzlich systemd abhängig ist dann ein NoGo für mich.

        3
        1. Ich habe selten auf einen Post so viel Zuspruch geerntet.
          Ich hoffe wir argumentieren hier nicht ins Leere und unsere Argumente werden auch von KDE Defs. gelesen.

          (Für LinuxNews wäre es auch gut, nicht nur Nachrichten zu senden, sondern auch ab und an als Feedbackschleife für die Entwicklung zu fungieren)

          Was ich an dem hier vorgestellten Konzept eines KDE-OS schlecht finde ist, dass in einem Schritt gleich ein OS entstehen soll, dass “modernen” Konzepten gerecht werden soll die gar nicht zur Entwicklungsaufgabe von KDE gehören.

          Ein simples Rollen der Paketversionen in eigen Rythmus würde vollauf genügen um KDE voran zu bringen. Und was systemd betrifft, wäre tatsächlich zu überlegen ob es nicht viel einfacher ist gleich auf etwas wie Artix zu setzen, denn dann sollte der Kram auch automatisch mit systemd funktionieren oder ob man sich jetzt für systemd ohne Rückfahrkarte entscheiden will.

          Vielleicht spricht Ferdinand mal die entscheidenden Leute darauf an.
          (Vorausgesetzt unsre Ideen dazu sind nicht gar so dumm bei näherer Betrachtung)

          3
          1. Bei mir war der Hauptgrund (neben einigen anderen) von systemd wegzukommen, der xy Bug.
            Da war ja für die Angreifbarkeit systemd der Hauptfaktor, was halt das Problem mit solch “eierlegenden Wollmilchsäuen” zeigt.

            Ich denke einfach das hier in Linux ohne Not ein System zum Standard erklärt wird, das immer mehr versucht alles unter seine Kontrolle zu ziehen, was nicht im Sinne von FOSS und damit Linux sein kann.

            Das wird dann immer mehr zu einem Scheunentor, wie Windows, und bringt auf Dauer nur Probleme.

            2
    1. Nachdem ich auch vieles ausprobiert habe, auch Neon, such Siduction, bin ich seit längerem schon bei Manjaro mit KDE hängen geblieben. Das wird immer besser und ist für mich persönlich genau das: meine KDE-Distribution. Gibt auch kaum Probleme mit dem Paketsystem. Flatpak und Snap vermeide ich wo es geht (meistens geht es). Und ich bin kein ITler, nur versierter Nutzer. Aber eine auf Arch basierende KDE-Distribution würde ich mir wohl anschauen.

      3

Kommentar hinterlassen