Auf Mastodon ansehen
Lernen empfinde ich als das größte Privileg. Die von mir über alle Maßen geschätzte Vera F. Birkenbihl formulierte das unvergleichlich treffend mit "Vom Gehirnbesitzer zum Gehirnbenutzer". Und so robbe ich mich, in letzter Zeit etwas intensiver, mühsam und langsam vom Linux-Nutzer zum Linux-Versteher. Deswegen sind die hier aufgeschriebenen Gedanken von meiner Linux-Reise nur ein Snapshot. Unvollständig in Sichtweise und Kompetenz. Ich will das trotzdem, oder gerade deshalb, mal hier zur Diskussion stellen.
Was war der Auslöser für den Artikel? Meine Tochter kam neulich auf mich zu, weil ihr geliebter Begleiter im Studium, ein Surface Go3 (mit i3 und 8GB RAM) massiv unter dem Windows-typischen Software-Rot litt, also nach Jahren total verstopft war und das Win11 zur lahmen Krücke mutierte. Da gab ich ihr leichtfertig ein Versprechen: "mit Linux rennt die Kiste besser als damals im Neuzustand, wirst begeistert sein." Nach Recherche zu Surface-kompatiblen Distros und dem Gedanken, dass das System kinderleicht zu administrieren sein muss, grenzte ich auf Fedora und Ubuntu ein.
Normalerweise hätte ich gar nicht recherchiert und Manjaro aufgespielt, aber dazu später. Zuerst spielte ich Fedora auf und startete nach der Installation Firefox. Der Browser benötigte eine gefühlte Ewigkeit bis zur Befehlsannahme! Hatte ich nicht ein Performance-Versprechen gegeben? Ich schaute dann mal in die Softwareverwaltung und sah den Feuerfuchs vor lauten Containern nicht; extrem viele Pakete waren Flatpaks. Das hat mich so geärgert, dass ich Fedora sofort gegen Ubuntu tauschte. Als Debian-Abkömmling hat man so etwas ja nicht nötig – dachte ich. Doch weit gefehlt.
Auch Ubuntu ist das reinste Container-Terminal, hier heißen die Container eben Snaps. Der Unterschied zwischen normalen Binaries und Container-Anwendungen ist auf schwächerer Hardware wie dem Surface Go3 wirklich deutlich spürbar. Snaps (Ubuntu) oder Flatpaks (Flathub) müssen sich beim Start erst einmal als komprimierte Images mounten, das kostet Zeit und RAM – beides ist auf dem kleinen Surface knapp. Gerade bei Ubuntu finde ich das total irre. Das Debian-Paket-Ökosystem ist mit über 60.000 Paketen ohnehin eines der größten überhaupt. Für den normalen Desktop-Gebrauch findet man praktisch alles direkt per apt. Snap und Flatpak lösen also ein Problem, das die Nutzer schlicht nicht haben. Wessen Probleme lösen Container also dann? Cui bono?
Und damit zum zweiten Auslöser für den Artikel: Zufällig stieß ich auf einen wahnsinnig interessanten und authentischen Blogbeitrag zu den Problemen von Entwicklern im F(L)OSS-Universum: Unbedingt lesen! Kurzfassung:
Das Burnout-Problem in der FLOSS-Community (Free/Libre Open Source Software) lässt sich nicht allein durch finanzielle Mittel lösen, da es sich um ein strukturelles Problem handelt – geprägt von belastenden Hauptberufen, toxischen Gemeinschaftsdynamiken (evtl. aktuell Manjaro) und der wachsenden Verantwortung für Projekte. Stattdessen verschärft sich der Teufelskreis aus Erschöpfung, sinkender Gemeinschaftsbereitschaft und zunehmender Kommerzialisierung, was die Freude und den Gemeinschaftsgeist der FLOSS-Entwicklung immer weiter untergräbt.
Was haben also Container mit Burnout zu tun? Sie lösen Probleme auf der Distributionsseite: mangelnde Manpower und mangelnde Schlagkräftigkeit des Teams. Die Arbeit wird elegant an die Softwareentwickler ausgelagert, welche die Pakete vermehrt auch im Container-Format zur Verfügung stellen. Das Stabilitätsversprechen ist damit mit viel geringerem Aufwand haltbar.
Denn der klassische Weg zu stabilen Systemen ist mühsam und steinig. Er hat vor allem mit funktionalen Abhängigkeiten zu tun. Beispiel: Ich gönnte mir neulich einen neuen Bürostuhl, der meinen wirklich schönen und großen Schreibtisch perfekt ergänzen sollte. Leider zeigte sich, dass die Lehnen des Stuhls so hoch und so ungünstig positioniert sind, dass ich mit dem Stuhl nicht mehr weit genug an/unter den Tisch rutschen konnte, die Lehnen stießen an. Also für sich genommen zwei perfekte Möbelstücke, im Zusammenspiel aber höchst problematisch. Und das ist der Alltag der Distributoren: Täglich bekommst du neue Software-Pakete angeliefert und musst schauen, dass diese stabil und funktional einwandfrei in deinem Universum zusammenspielen. Aus genau diesem Grund ist es auch problematisch, Fremd- und User-Repos einzubinden. Diese Pakete sind eben nicht optimal auf den Bestand der Basis-Distribution angepasst. Das Stabilitätsversprechen ist nur dann halbwegs haltbar, wenn man beim Distrubitions-Repositorium bleibt. Nur diese Pakete sind (mehr oder weniger gut) auf Abhängigkeiten der anderen Distributionspakete abgestimmt.
Das hat beispielsweise Manjaro über all die Jahre super hinbekommen. Dieser Distribution ist zu verdanken, dass ich ewig dem naiven Glauben nachhing, dass Linux ein No-Brainer ist. Aber es braucht eben Manpower und Teamgeist. Und leider sehe ich es nicht als Zufall an, dass ich nach Jahren der Sorglosigkeit ausgerechnet in den vergangenen Wochen, just in der Phase der Manjaro-Unruhe, zweimal schwerwiegende Paketkonflikte hatte, welche mich tatsächlich mit weinenden Augen zur Abwanderung bewegten. Selbstkritisch muss ich aber einräumen, dass meine Manjaro-Probleme vielleicht auch hausgemacht waren; Fremd- und User-Repos hatte ich zuletzt einige.
Das Stabilitätsversprechen hängt maßgeblich von der Pflege der Binaries ab, es ist also eine große menschliche Teamleistung (wie jede Fleißarbeit könnte das evtl. zukünftig teilweise eine KI übernehmen?). Und so beantwortet sich auch die oben gestellte Frage zu Containern. Wessen Probleme lösen diese? Sie lösen die Ressourcenprobleme der Distributoren. Damit will ich das aber gar nicht pauschal verteufeln, denn zumindest das Stabilitätsversprechen lässt sich mit dieser Strategie trotz geringer Ressourcen einlösen. Und performante Hardware gleicht den Rest aus.
Wenn man Linux sehr verkürzt als Konstrukt aus Kernel und den Paketen drumherum darstellt (kuratiert durch eine Distribution), ergibt sich die Qualität eines Linux-Betriebssystems aus zwei Säulen: Als Linux-User sind wir also (1) davon abhängig, wie gut Linus Torvalds und sein Team den Kernel pflegen – und (2) wie gut unsere Distribution gebaut und gepflegt wird. Der User steht am Ende dieser Wertschöpfungskette. Im Normalfall erledigt die Distributionspflege das zugehörige Team. Also: Augen auf bei der Bewertung des Distro-Teams, wenn man sich langfristig binden möchte.
Etablierte, große und gut regulierte Teams wie bei Debian und Arch sind Erfolg versprechende Kandidaten. Oder man schielt zu finanziell und damit personell gut ausgestatteten Distributionen mit kommerziellem Standbein (Ubuntu, RedHat, Google mit ChromiumOS etc.), aber auch da wird gespart, wie ich oben dargestellt hatte. Oder man bezieht die User in die Wertschöpfungskette mit ein; man teilt und spezialisiert die Arbeit auf Bereiche, welche die jeweilige Gruppe potenziell am besten bewältigen kann – das ist der Gentoo-Weg: Hier wird arbeitsteilig administriert. Das Distro-Team stellt die Pakete zur Verfügung und hinterlegt über den Paketmanager Portage alle Abhängigkeiten (und andere Infos). Dem User obliegt es dann, auf etwaige Portage-Meldungen kompetent und spezifisch zu reagieren; schließlich ist jedes System ein Unikat. Die Verantwortung für das Stabilitäts- und Performance-Versprechen wird also auf Distro- und User-Schultern verteilt. Eine intelligente, weil logische Lösung, aber ganz sicher nicht von jedem User darstellbar.
Ich bin immer noch begeistert von Linux, aber doch etwas desillusioniert und sehe die Entwicklungen innerhalb der F(L)OSS-Community als besorgniserregend hinsichtlich der Zukunft. Es gibt da Parallelen zur Vereinsarbeit und dem Ehrenamt insgesamt. Immer weniger Bereitschaft, sich zu engagieren, führt zu weniger und qualitativ schlechterem Angebot. Das fühlt sich auf den wenigen verbliebenen Schultern dann auch wie Container an ;)
P.S.: Auf dem Surface Go3 durfte Ubuntu bleiben, aber das Snap-Universum habe ich entfernt. Als apt-Pakete rennen die Anwendungen auch wie versprochen.
Titelbild: https://pixabay.com/photos/container-storage-trade-haulage-4203677/ (modifiziert)
Quelle: https://blogs.gentoo.org/mgorny/2026/03/07/money-isnt-going-to-solve-the-burnout-problem/
Zu "Die Arbeit wird elegant an die Softwareentwickler ausgelagert, welche die Pakete vermehrt auch im Container-Format zur Verfügung stellen" möchte ich anmerken, dass Container-Formate durchaus auch Vorteile für Softwareentwickler hat. Es lässt sich damit auf reproduzierbare Weise ein Benutzer-Erlebnis erzeugen, welches auf allen Linux-Distributionen dasselbe ist (modulo Hardware-Unterschiede) und die neuesten Bugfixes und Features enthält. Gerade für ältere Linux-Distributionen ist das ein Riesengewinn. Klar haben native Pakete auch ihre Vorteile, gerade auf leistungsschwächerer Hardware, aber die Vorteile von Container-Formaten können sie auf älteren Distributionen niemals ersetzen.
Die Geschwindigkeitsunterschiede zwischen Nativen und Containern auf schwacher Hardware erledigen sich über die Zeit von selbst. Das Container-Versprechen ist doch eine Win-Win-Win-Situation für Entwickler, Distro-Maintainer und Anwender:innen. Die Entwicklerin muss nur noch ein Format bauen (Flatpak), Die Distro-Maintainer können sich auf Distro-spezifische Pakete konzentrieren und der Anwender ist nicht durch verschiedene Formate für dieselbe Software irritiert. Ausserdem muss man nicht ausprobieren, ob die native Version oder das Flatpak besser funktioniert. Doch wenn man alles gleichzeitig haben möchte (native und Container-Pakete), führt das zu einer Situation, in der alle Beteiligten verlieren.
Ich finde "wird sich über die Zeit erledigen" aktuell eine recht kühne Aussage, bei den derzeitigen RAM und SSD-Preisen. Es geht nicht immer nur in eine Richtung. Und ich finde auch, dass Ressourcen nicht einfach zum "Verbrennen" da sind. Immer mehr Komplexität stösst irgendwann an Grenzen. Daher wäre etwas mehr KISS schon hilfreich.
Vielleicht probierst du mal Linux Mint auf dem Surface Gerät, dann hast du auch die ganzen Ubuntu Treiber aber die Snap Container nicht und Flatpak ist in Mint erstmal auch sparsam und du kannst selber entscheiden wie du was installierst.
Es geht es ja nicht nur daru ob Native App oder Container Format (Flatpak/AppImage/Snap). Oftmals sind die Container sehr viel aktueller als die Systempakete von Debian oder Ubuntu. Keine Ahnung wie es bei anderen Distros aussieht, aber da ist es so das sie zeitlich immer viele Monate hinterher sind. Die Geschwindigkeit der nativen Apps spielt heute eigentlich kaum eine Rolle, das betrifft nur Kisten die älter als 10 oder mehr Jahre sind oder sehr wenig RAM haben. Die Programme in den Container laufen zwar soweit alle reibungslos, trotzdem muss man ab und zu (so manches Mal) einige erweiterte Rechte konfigurieren damit die Anwendung wirklich alles machen kann was sie machen soll und das ist für Newbies dann ein zusätzlicher kleiner Show-Stopper.
Momentan betreibe ich zwei Geräte (darunter ein inzwischen recht Alter Desktop PC) mit Fedora Workstation. Auf keinem System wurde der Firefox standardmässig als Flatpakt installiert. Dieser wird als RPM mitgeliefert. Darüber hinaus ist es über das GNOME Software Center jederzeit möglich zwischen einer Installation als RPM oder Flatpak auszuwählen (insofern die infrage kommende Software auch als RPM existiert). Aus Performance Sicht sehe ich auch auf dem älteren Desktop keinen relevanten Unterschied zwischen Flatpakt oder RPM Anwendungen, das mag aber bei schwächerer Hardware eventuell anders sein. Bei Ubuntu wird Firefox standardmässig als Snap mitgeliefert und auch nicht als DEB angeboten. Auch das Software Center ist unter 24.04 als Snap enthalten (das gibt lustige Fehlermeldungen wenn man das Snap System aus dem Software Center heraus updaten möchte, denn eine Applikation verhindert auf jeden Fall das erfolgreiche Update in diesem Moment ;))
Unter Ubuntu muss man für Firefox und Thunderbird die original Mozilla Repositorien einbinden. Als deb gibt es die gar nicht mehr.
Wenn man es ins Extreme(!) weiter denkt, also Pakete werden grundsätzlich nur noch als Anwendungen in der Sandbox zu Verfügung gestellt, dann sind vlt. bald nicht nur unterschiedliche Distributionen obsolet, sondern auch Betriebssysteme insgesamt?!
Hallo, ich kann mich tuxfanmatze anschließen. Versuche mal Linux Mint. Und wenn dir Cinnamon immer noch zu Hardware-Hungrig ist, kannst du mal den Mate- oder sogar den Xfce-Desktop testen.
"...you could say BOTH" 😇️
Die Ankündigung des Ubuntu Container Formats vor etlichen Jahren war für mich Anlass, auf meinem schwachbrüstigen geliebten "Netbook" –und überall sonst(!)– auf das originale Debian zu wechseln. Irgendwann wurde dann -auch dort- erforderliche Firmware gleich direkt mitgeliefert.
Auf Servern und für zumindest manche Distributionen mögen Containerformate Vorteile haben, bzw. haben sie, auf dem Client will ich das bislang aber tatsächlich auch meinerseits nicht. Ich kann Dich da verstehen.
Container-Formate haben auch Vorteile für die Entwickler. Ich habe z.B. als Entwickler durch die relativ einfache Paketierung für Flatpak meine App für alle Linux Distributionen gleich recht schnell zur Verfügung gestellt. Wenn ich meine App als native Pakete veröffentlichen wollen würde, dann müsste ich für jedes Distro-Format neu lernen, wie man da Paketiert, das bei jeder Distro wieder einzeln anfragen dass es zu den Repos hinzugefügt wird, was dann bei jeden wieder eigens reviewed wird, etc. Für jemanden, der seine erste App veröffentlichen möchte ist das schon extrem viel Aufwand, mit Flatpak ist das deutlich einfacher
Flatpaks lösen mehrere Probleme:
Die Entwickler können Programme zur Verfügung stellen und sind nicht von der Gnade der (immer weniger vorhandenen) Maintainerm abhängig. Damit entfallen auch die Drittquellen, die unter bestimmten Distributionen eigentlich unabdingbar sind, aber das System massiv instabil machen.
Programme werden tatsächlich gepflegt und mit Updates versorgt, was bei den sogenannten "stable Distributionen" häufig nicht der Fall ist. Gerade bei 60.000 Paketen wird in meinen Erfahrungen mit Debian nur 1‰ aktiv gepflegt. V.a. KDE wird nicht gepflegt. 😰😭
Flatpaks laufen im Container, D.h. die Sicherheit wird massiv verbessert. 👍
Gerade auf älteren Laptops habe ich immer wieder gute Erfahrungen mit Mint gemacht. In dieser Distro müsste Snap auch erst mit erheblichem Aufwand erlaubt werden. Flatpak gibt es immer noch. Aber so ziemlich jede Applikation lässt sich aus einer .deb installieren.
Dieses Thema "zum Wochenende" treibt mich tatsächlich noch über den Samstag und Sonntag um - und es scheint, dass die Vorteile von Containerformaten überwiegen. Die Entwicklung die mir aufgefallen und zunächst aufgestoßen ist, hat längst diese Richtung genommen:
Wenn man die Entwicklung von Flatpak (und auch Snap) konsequent zu Ende denkt, landen wir bei einer Welt, in der die "Anwendung" völlig vom "Betriebssystem" entkoppelt ist. So stieß ich auf die (für mich) neue Ära der "Immutable Distributions". Diese machen genau das. Man bekommt einen unveränderbare Basis, den System-Layer (Kernel, Treiber, Desktop); das zweite Element ist der App-Layer, welchen man dann mit seinen Flatpak- oder Snap-Paketen befüllen kann. Beispiele solcher "Unveränderbarer Distributionen" sind Fedora Silverblue, openSUSE MicroOS, SteamOS auf dem Steam Deck und auch ChromiumOS.
Und da Flatpaks nicht vom Himmel fallen, sondern auch aus Source gebaut werden, behauptet meine digitale Glaskugel, dass dann Meta-Distributionen wie Gentoo diese Aufgabe übernehmen. Jetzt ist mir auch klar, warum ChromiumOS auf Gentoo basiert.
Und wenn ich es richtig verstanden habe, dann bekommt man Updates des System-Layer einfach als Snapshot des btrfs-Filsystems.
Es bleibt also spannend - oder es wird langweilig - je nach Betrachtungsweise.
> So stieß ich auf die (für mich) neue Ära der "Immutable Distributions"
Das Thema ist nicht neu, und wirklich unzerstörbar sind sie auch nicht, siehe dazu den Artikel von Ralf vom letzten Oktober.
Auch auf die Gefahr, mich zu wiederholen: Bei der ArchivistaBox bzw. AVMultimedia liegt das OS als squashfs-Datei entweder ganz im Speicher oder als Overlay so vor, dass es keine Schreibzugriffe auf die Festplatte gibt. Läuft ab Stick oder Festplatte 100% gleich, es gibt erst gar keine Installation. Einfach hochfahren und loslegen...
Ich habe das Konzept ca. 2010-2019 an mehreren Linux-Events vorgestellt. Mehr dazu findest Du in den Folien zu den damaligen Vorträgen. Erwähnen möchte ich hier einzig noch, du kannst z.B. rm -Rf /ib eingeben, ein Neustart und das System steht wieder. Das Hochfahren (Einrichten) des gesamten Linux-Systems entfällt, der Start-Prozess (für ca. 10 GByte Software) dauert ca. 10 bis 20 Sekunden. Wird das Teil auf die Festplatte gespielt, dauert es ca. 10 bis 20 Sekunden länger (abhängig vom USB-Stick bzw. der Schreibgeschwindikeit der Festplatte).
Die ArchivistaBox bzw. AVMultimedia unterstützen DEB-Pakete, AppImage, FlatPak, KVM, Docker sowie die lokale KI-Plattform Ollama (letztere beiden "nur" die neueste ArchivistaBox, siehe dazu den entsprechenden LinuxNews.de Beitrag bzw. unsere Homepage. Aktuell ist Kernel 6.18.18 und die allerneuste Firmware (1.8 GByte) vom März 2026 ist dabei, es wird folglich auf sehr sehr vielen Geräten laufen.
Du kannst beliebig das Release wechseln, einfach die entsprechende ISO-Datei nehmen und nach einem Neustart bist Du im gewünschten Release. Updateprobleme gibt es daher bei der ArchivistaBox bzw. AVMultimedia so nicht. Entweder Release X oder Y läuft, dann kannst Du es nutzen. Im anderen Fall darfst Du es gerne melden, ich sehe es dann auch an ;-)
Als ich ca. 2005 für die ArchivistaBox eine Linux-Distribution suchte, wurde schnell klar, keiner der Test-Kandidaten eignete sich dafür. Wir testeten damals Slackware, Debian und Ubuntu. Ab einem bestimmten Punkt wurde es faktisch unmöglich, es mit Standard-Linux-Distributionen zu erreichen.
Nehmen wir z.B. das Thema Scannen. Die Anzahl der unterstützten Scanner war derart "lausig", dass wir letztlich die Entwicklung zunächst für die AVision-Scanner, später für die Fujitsu-Linie (heute Ricoh) in Auftrag gaben. An sich wollten wir diese Entwicklung für alle Distributionen "erreichen", mussten aber erkennen, dass dies faktisch nicht gelingen wird.
Da war einmal das Sane-Projekt. Es ist mir aber schleierhaft, warum es neben dem PNM-Format nicht Platz für das JPEG-Format hat. Wenn ich unkomprimiert in Farbe bei 300dpi scanne, dann sind dies 2x25 MByte pro Blatt. Selbst ein Consumer-Gerät wie der Ricoh ix1600 (unter 400 Franken) schafft pro Minute 80 Bilder. Dies ergibt (80x25 MByte) 2000 MByte (pro Minute!).
Nun macht(e) das Sane-Projekt bis heute keine Anstalten, dass der JPEG-Standard per Default ins Projekt kommen würde. Woran das liegt, kann ich nicht abschliessend beurteilen. Ich denke, dass Hersteller nicht primär daraus aus sind, mehr als Windows (und allenfalls) Mac zu unterstüzen. Entwicklung ist immer teuer. Für die Avision-Geräte «zahlten» wir einen höheren fünfstelligen Betrag, bei Fujitsu/Ricoh ebenso, bei Canon gaben wir irgendwann auf. Das höchste aller Gefühle war, dass wir mal ein Testgerät von Fujitsu bekamen, aber das war es dann auch.
JPEG-Scanning kann bis heute nur durch das Patchen (es handelt sich um eine Zeile) aktiviert werden. Meines Wissens ist JPEG bis heute in keiner aktuellen Linux-Distribution (ausser AVMultimedia bzw. ArchivistaBox) aktiviert. Die einzige mir bekannte Lösung für JPEG-Scanning wäre, die Quellen neu zu übersetzen und es dann manuell aufzuspielen.
Natürlich könnte ich dabei ein Debian-Paket erstellen und dieses der Community zur Verfügung stellen. Ein DEB-Paket ist aber auch nur eine Ansammlung von Binär-Dateien mit einigen Bash-Befehlen (vereinfacht gesagt). Ein DEB-Paket das unter Ubuntu läuft, läuft nicht unter Debian und noch weniger unter Devuan. Was ich vor 30 Jahren unter Windows als DLL-Hölle kennenlernte, lässt sich aktuell gut als SO-Abgrund der System-Bilbiotheken zusammenfassen.
Das beginnt mit der GLIBC-Bibliothek, geht in die Package-Manager, wird angereichert mit Firmware-Bloats (aktuell 1.8 GByte) und endet im Versuch, die ganzen Dinger irgendwie doch wieder zusammenzuschrauben. AppImage ist dabei noch die beste Variante, weil genau eine Datei besteht. Bereits bei einer nicht identischen GLIBC-Bibliothek scheitert AppImage aber.
Bei Flatpak braucht jedes kleine Programm 1-3 GByte. Das Nutzer/innen-Erlebnis tendiert dabei mangels Themen-Angleichung gegen Null. Nehmen wir Docker. Ah, läuft nur mit sehr bestimmten Kerneln und ein zwei Images (Programme) und 10 bis 20 GByte sind weg. Ein grafisches Open Source GUI in Deutsch, Fehlanzeige. Ja, Docker lässt sich auf der Konsole managen, aber ehrlich für Anfänger/innen? Ironie ist ja, dass gute Open Source wie z.B. Immich auf «geschlossenen» NAS-Sytemen wie UNRAID läuft, nicht aber unter Linux einfach gestartet werden kann.
Das mündet in dem, was Reto beschreibt. Linux ist aktuell derart «fragmentiert», dass zwar vieles irgendwie läuft. Den Preis, den wir bezahlen ist aber, dass es am Ende nicht (mehr) passt. Die Ressourcen steigen und steigen, sodass selbst 8 GB RAM für ein Notebook mit Linux kein speditives Arbeitstempo mehr ergeben. Überdies sind die Themes (Look) der Apps in den Distributionen mangelhaft, LibreOffice in Debian erinnert mehr an Windows7 als an 2026.
Und wir sind dann noch immer dort, dass z.B die Scanner-Unterstützung nicht gelöst ist. Mag sein, Scanner-Unterstützung ist kein Top-Thema, aber wie ist das jetzt mit den modernen Grafikkarten? Ich habe diese Woche die AMD-Treiber (Rocm) in die ArchivistaBox aufgenommen. Hätte ich es in einer Standard-Distribution implementieren wollen, wir sähen uns irgendwann um 2028. Und ich hätte Monate, um dies auf meiner Seite zu erreichen. Für diese Eigenständigkeit nehme ich in Kauf, als «Kleinst-Distribution» von der Community nicht ernst genommen zu werden.
An reto: Du hättest es gerne mit AVMultimedia bzw. der ArchivistaBox machen dürfen. Du findest bei uns nämlich alles ready-to-use, was anderswo mühsam zusammeninstalliert werden muss. Und 4 GB RAM reichen bei uns nach wie vor ohne Probleme, selbst 2 GB RAM sind ok (dort einfach die Grafikkarte auf 128 MB setzen). Und in 1 bis 2 Minuten wäre der Job erledigt gewesen.
Danke für Deine Einblicke!
> Bei Flatpak braucht jedes kleine Programm 1-3 GByte.
Nur der angegebene Platzbedarf bei Flatpak trifft ja nur auf die erste App zu (und ist etwas hoch angesetzt), ggf. für KDE und Gnome separat, wenn man gemischte Apps installiert; wenn die Plattformen/Portale drauf sind, haben die einzelnen Apps doch meist eher harmlose Größen.
Ich habe heute 7 Apps über Flatpak (MakeMKV, Kodi, OpenShot etc) installiert. Die Bilanz sagt: 8.8 GByte. Aber klar, ich kriege z.T. deutlich neuere Versionen, als wenn ich versuchte, sie über die DEB-Pakete zu installieren. In diesem Sinne bin ich als Maintainer der ArcihvistaBox bzw. AVMultimedia schon dankbar, dass es FlatPak gibt. Und es ist für End-Anwender/innen sicher einfacher, als der Weg über Docker, und vielleicht sogar einfacher, als AppImage (Ausführen-Rechte setzen).
Ich glaube in nächster Zeit wir das nicht mehr so viel gebraucht werden, die Containern, ich komme z.B. sehr gut ohne aus und habe alle App die ich brauche auf Linux Mint :-) Auch bekommen fast alle Open-Source-Projekte gerade einen enormen Boost, und das ist erst der Anfang.
Bei den Contianerformaten Snap oder Flatpak ist der erste Start immer langsamer. Die Nachfolgenden Starts sollten aber schneller sein.
Für Firefox empfehle ich das snap Format, weil z.B. Keepassxc nur via snap funktioniert. Flatpak hat das Problem noch nicht gelöst.