Hier zeigt sich die Tragweite dieses Wahnsinns mit den "unveränderbaren" Distributionen. Nach dem SystemD-Irrsinn und den Containerpaketen, ist dies nun die nächste Sau, die alles auf den Kopf stellt. Denn es geht hier um weitaus mehr als nur die Frage, was das "richtige" Dateisystem, die "beste" Desktopumgebung, der "richtige" Init-Daemon oder der "einzig wahre" Texteditor ist. Aber es wird auch klar, welchen unschlagbaren Vorteil klassische Distributionen haben.

Im übrigen vermisse ich die Chat-GPT-Api in SystemD.  Bis die kommt, spiele ich 'ne Runde GRUB Invaders !

Tja, nix anderes war zu erwarten nachdem sich Snap oder Flatpack einmal etabliert und die Anbieter damit fertig gespielt haben. Ich schreib von jetzt an Flatpack, meine aber beides - Snap und Flatpack.

Ich sehe den Vorteil hier, das man das Grundsystem einfacher warten können wird - vom Distributor her. Es sind nicht mehr so viele Fälle zu berücksichtigen. Es gibt genau eine Zusammenstellung, deren Upgrade man testen muss und garantieren muss das es funktioniert. Bei Debian z.B. ist das nicht vorhersagbar, weshalb es so lange Testzeiträume gibt und doch kann man bei einem Upgrade auf einen Cornercase stoßen, den noch nie zuvor jemand gesehen oder getestet hat.
Weshalb es in der Debian Doku so viele Klauseln, Reperaturansätze und Konjunktive zum Erfolg der Installation gibt.
In gewisser weise lagert man damit das Problem des Zusammenspiels der NICHT zur Unveränderlichen gehörenden Software komplett auf den Kunden ab. Flatpack X kann nicht mit Flatpack Y? Tja, leider Pech gehabt.
Und ich sehe da auch komplizierten Spaß kommen zu entscheiden was geht wohin. Also ist dann Kde ein Flatpack? Und haben dann alle immer die KDE Games, ob sie wollen oder nicht? Was mach ich mit OpenOffice, das auf KDE läuft? Und wie spielt da der XServer/Wayland mit?
Was wenn ich lieber Gnome hätte? Muss ich da neu installieren? Und wie spielen die Flatpacks überhaupt zusammen? Jedes Flatpack läuft in einem eigenen Container. Ich stelle es mir kompliziert vor zwischen diesen Daten auszutauschen, da per Definition der Container ein abgeschlossenes Dateisystem hat.

Wenn man mit dem Browser sich Datei X runter geladen hat, wie kann man dann das zugehörige Anzeigeprogramm aufrufen? Was sagt dann der Dateimanager aus dem KDE oder Gnome dazu? Wie tauscht man generell Dateien zwischen den Containern?

Und Flatpacks erhöhen nicht unwesentlich die Komplexität mit nur geringem Mehrwert für den Endanwender. Wenn man vorher nur einmal OpenSSL für seine ganze Installation updaten musste, kann man nun nie sicher sein, ob ein altes OpenSSL noch in irgendeinem ranzigen Flatpack werkelt. Und schwupps... hat man sich was eingefangen.
Oder OpenSSL austauschen führt zu 15GB+ Downloads, weil man jedes beteiligte Flatpack einzeln aktualisieren muss.
Oder - und das wäre der Worstcase - die machen so einen verschwurbelten Mist, wie in Docker, das die Dateisysteme aus verschiedenen Quellen für einen Container zusammengebastelt werden.

Das versteht dann am Ende keiner mehr, auch nicht der Experte. Gibts da ein Problem ist die einzige Lösung: Neu installieren.

Fragen über Fragen. Ich glaube das Konzept hört sich schön an.

Es macht den kommerziellen Distris weniger Arbeit und damit gibt es ihnen einen Kostenvorteil. Das könnte dazu führen das über die Zeit alle kommerziellen Distris in diese Richtung gehen könnten.

Wenn, ja wenn Cannonical das irgendwie ans Laufen bekommt bevor ihnen die Kunden weggelaufen sind...

Aber ich kann mir von meiner gegenwärtigen Position nicht vorstellen, das das ein Erfolg werden wird. Aber es gab andere Leute vor mir, die auch den kommerziellen Erfolg des IBM PC nicht erkennen wollten. Also bin ich mal vorsichtig.. schauen wir mal was draus wird.

Ich persönlich werde die Finger von diesem komplexen Krams lassen, soviel ist sicher. Aus dem Grund kann ich Euch an der Stelle auch nicht weiterhelfen, sollte euer Flatpack Schluckauf haben. Wenn ich aus dem Ubuntu Server Snap nicht raus extrahiert bekomme ist das der Tag wo ich zu Debian wechsele.

Liebe Grüße,  
    Klaren

Jaaaa, da sprichst du tiefgreifende und im Detail unkalkulierbare Auswirkungen an. Darüber hinaus wirft das aber noch weitergehende, vielleicht sogar juristische Fragen auf: Wenn ein Container (der ja idealerweise auf "allen" Distributionen lauffähig ist) ein Problem hat (funktional, Datenschutz): Wer ist dann dafür verantwortlich und ggfs, haftbar? Im anderen Threat sprachst du ja die Verantwortung von Firmendistributoren an, die im Kontext des professionellen Supports eben auch eine juristische Verantwortung ist. Wer ist aber verantwortlich, wenn es hier knirscht? Der Distributor? Der Bauer des Containers? Das erinnert ein wenig an die Frage, wer im Falle eines Unfalls beim "autonomen Fahren" verantwortlich sein könnte? Der Fahrer? Der Bauer des Autos? Der Softwarehersteller? Wenn ich dies durchdenke, kann ja eigentlich eine solche Infrastruktur im Enterprise-Bereich kein wirkliches Thema sein!

Vielleicht wäre ja eine praktikale Lösung eine solche, wie jene, die bei der Slackware-basierten Distribution Slax verfolgt wird, mit ihrem eigenen Konzept der Module ?

Im Grunde genommen sehe ich als einzige Anwendung hier nur die komfortable Möglichkeit, recht schnell einzelne Programme ausprobieren und diese ggs. wieder wegwerfen zu können. Sollten diese Anwendungen Gefallen finden, kann ich sie dann regulär über die Paketverwaltung installieren (soweit es sie dann hoffentlich und hinreichend aktuell gibt). Neben dem (fehleranfälligen) Gebastel mit externen Repositories sei an die bei Debian verfügbaren Backports ( HP , Debian Wiki , Debian Forum , WP ) erinnert, die einzelne Anwendungen in neueren Versionen auf die Platte zaubern (mit halbwegs kalkulierbaren Risiken, wie die notwendige Aktualisierung von Systembibliotheken, die ungewollte Folgeprobleme produzieren könnten). Wer (in der Konsole) mit Downgrade ( WP ) und Paket-Pinning ( ubuntuusers , linux.magazin ) zurecht kommt, kann dies ausprobieren, ohne sich gleich das ganze System zu zerlegen. Von einer umfangreichen Systemaktualisierung über die Backports würde ich aber abraten - zumal der Support bzgl. Fehlerkorrekturen hier wohl auch nicht gewährleistet wird. Da ist man dann (irritierenderweise) bei "Unstable" besser aufgehoben (mit allen Vor- und Nachteilen)!

Puh,
das ist jetzt ein ganzer Blumenstrauß an Dingen.
Regresspflicht, Haftung
Bezüglich Haftbarkeit, Regresspflicht und ein Kundendient (neudeutsch Support) -  Dies ist genau die eigentliche Leistung eines kommerziellen Distributionsanbieters.
Er tritt an die Stelle der Community und des Softwareentwicklers, der seine Software als "As-is" und "not ready for any purpose" anbietet und sorgt mit eigenen Leuten dafür, das gefundene Fehler gemeldet und im Bedarfsfall vielleicht sogar durch den Distributor selbst (durch das Einbringen von Patches) geschlossen werden. Hier gibt es eine Überlappung mit den nicht kommerziellen Distributionen, die natürlich auch von sich aus ein Bugfixing durchführen. Im idealfall macht dann Ubuntu nur bei Debian ein Bug Ticket auf. Aber oft genug sieht man auch das z.B. Ubuntu auch eigene Patches einbringt. So haben die Ubuntu Kernels immer auch einen Releaseanteil, der von Ubuntu kommt. Arch macht es genau so.
Nehmen wir das aktuelle Kernel Image von Ubuntu Server 22.04.2:
linux-image-5.15.0-76-generic
Das ist der 5.15.0'er Linux Kernel, wie ihn Linus und sein Team released. Aber die "76" kommt von Ubuntu und beschreibt den von Ubuntu Patchlevel. Dieser Patchlevel referenziert auf eine Voreinstellung und Patches im Sourcecode, die durch Ubuntu vorgenommen wurden und die in der Regel gefundene Fehler des Kernels beheben, die im nativen Kernel noch enthalten sind.

Das ist für einen Endkunden alles nicht entscheidend und 100% transparent, aber im professionellen Einsatz, wie geschrieben, ist diese Art der Verlässlichkeit essentiell.
Dabei ist es egal, ob es sich um einen Container oder ein Softwarepaket handelt. Der kommerzielle Anbieter ist zunächst in der Pflicht dieses Stück Software fehlerfrei anzubieten und bei erkennen eines solchen für Abhilfe zu sorgen.
Ein weiterer Punkt sind die LTS Releases. Auch das sichert im Kommerziellen Umfeld, das man für eine fest definierten Zeitraum sich darauf verlassen kann, das das Betriebssystem nicht plötzlich völlig anders funktioniert als zuvor. So kann man darauf eigene Lösungen setzen und hat auch einen definierte Zyklen um von LTS 1 nach 2 zu kommen.
In der Zwischenzeit kann man aber seine Lösung stabil auf LTS 1 ausrollen.
Und nun bringen wir in dieses Modell ein "unveränderlichen" Kern ein. Der Kern ist dann im LTS 1 eine feste Gruppe von Paketen. Eigentlich kann man dann sogar das Paketieren komplett dran geben und nur noch ein Image mit dem Kern Betriebsystem einspielen. Das war (ist?) der Weg z.B. bei Fedora. Da macht es Kabumm, der Rechner bootet durch, es dauert und dauert und am Ende hast du ein neues Fedora auf der Büchse. Man fühlt sich da an M$ Windows erinnert.

Ausprobieren ohne Folgen
Du erwähnst dann im unteren Block, wenn ich das richtig verstehe, das der Vorteil von Snaps das Ausprobieren von Software ist. Ja, da gebe ich dir teilweise recht. Mit entfernen des Snaps sind dann auch alle zugehörigen Libraries und sonstige Helferlein wieder verschwunden. Auch haben die keine Abängigkeiten zum eigentlichen Betriebsystem.
Aber in Debian und anderen Distributionen ist das Ausprobieren auch ohne diesen Overhead möglich. Einziger Punkt ist, das ein Debian halt für ca. 2 Jahre eingefrohren wird und am Ende der 2 Jahre die wirkliche Softwarelandschaft eine andere ist. Sprich Debian Stable altert schnell.
Zum Ausprobieren sollte man sich ein Testing zulegen oder wie von dir Vorgeschlagen prüfen, ob es einen Backport gibt. Im Fall von Testing mit dem Preis da pro Woche eine GiBytes an Updates reinpumpen zu müssen. Im Fall von Backport: es gibt die gewünscht SW nicht als Backport - pech.
Beideshätte man mit einem Snap nicht - vorrausgesetzt da gibt es ein tagesaktuelles SNAP von der Software, die ich möchte. Wenn nicht -> siehe Backport.
Rolling Distributions wie Tumbleweed oder andere sind immer auf dem aktuellen Stand der Zeit. Da altert weder dein Betriebsystem noch hast du alte Applikationsversionen von vorgestern. Ich persönlich halte diesen Weg für den besseren. Aber das muss jeder selbst entscheiden.

Aber da komm dann alles aus einem Guß, also alles aktuell. Wenn man das entkoppelt, läuft die aktuelle Software auf einem Metusalem Kernbetriebsystem von übervorgestern. Welche Probleme das trotz Containerisierung und einem eigenen Satz an Libraries darin aufwirft fangen wir glaube ich erst an zu verstehen. Wenn die Applikation z.B. bestimmte Kernelinterfaces einer späteren Kernelrelease benötigt kann da sehr schnell doch ein Problem auftreten. Und alles was mehr Performance vom Rechner verlangt als "wir laden mal ein paar Dateien runter" wird auf solche Schnittstellen angewiesen sein.

Und beim Dateisystem - wie man die Dateisystem aus unterschiedlichen Containern konsistent zusammen bekommt, so das der Dateipfad aus Container 1, 2 und 3 gleich ist? Wie man die Zugriffsrechte zwischen den Containern regelt usw. usw.. ich glaube an der Stelle wird es ebenfalls sehr kompliziert.

Und die Snaps aktualisieren? Dazu hatte ich ja schon was geschrieben. Auch da denke ich kann es nur einfach aber mit viel Durchsatz oder höchst kompliziert und damit Fehleranfällig enden.

WIe auch immer. Ich bin da kein Freund von, wie geschrieben.

Liebe Grüße,
    Klaren