Erfahrungen eines Linux unerfahrenen Gamers - Ein Tagebuchthread

[sedot]

@Photon
Wenn du weiter klickst zu Basic Concepts findest du grundlegende Erklärungen und auch eine Grafik.
https://docs.flatpak.org/en/latest/basic-concepts.html

 

[Photon]

Ah ja, das ist ja das Runtime, was ich schon entdeckt habe. Danke für die Erklärung!

Da gibt es also nur teilweise Dopplung, sicher nicht keine Dopplung. Ich kriege mithilfe der Runtime einen Set an Abhängigkeiten, der mehr oder weniger zu meiner App passt. Manche der Abhängigkeiten sind für meine konkrete App vielleicht überflüssig, ergo Speicherplatzverschwendung. Andere fehlen dort naturgemäß, die füge ich meinem Flatpak hinzu. Eine andere App braucht vielleicht auch wieder manche dieser von mir hinzugefügten Abhängigkeiten, die in der Runtime nicht enthalten sind.

In Summe habe ich zwar manche Abhängigkeiten nicht doppelt, andere habe ich hingegen durchaus doppelt (weil nicht in der Runtime und von mehreren Apps benötigt), oder schlicht ohne dass sie gebraucht werden (weil in der Runtime aber von keiner App benötigt). Ich hoffe, dass wir nicht darüber diskutieren müssen, dass das eine Lösung ist, rein von der Abhängigkeitsverwaltung her, der klassischen Paketverwaltung unterlegen ist, die schlicht für alle installierten Programme exakt die benötigten Abhängigkeiten und das ohne jede Dopplung zur Verfügung stellt, auch wenn diese Lösung abgesehen von der Abhängigkeitsverwaltung vielleicht Vorteile bringt.

 

[sedot]

@Photon
Ja, was notwendig ist legen die Entwickler der App fest. Es kann sein, dass mehrere Runtimes vorhanden sind. Also zum Beispiel QT und GTK in unterschiedlichen Versionen.

Letztlich ist es eine Frage deines Anspruchs an dein OS, wenn du möglichst minimal bleiben möchtest und du alles aus den Repos deiner Distribution beziehen kannst ist flatpak vielleicht nicht die beste Wahl. Es kommt eben auf die konkrete Situation an, die Anforderungen (und User) sind je nach Szenario sehr unterschiedlich.
Ich nutze relativ viele Flatpaks, also im mittleren zweistelligen Bereich, und der Speicherplatzbedarf der Runtimes spielt eine untergeordnete Rolle für mich. Meine SSD für OS und home ist 256GB „groß“, Platzmangel gibt es nicht. Alles was ich nicht temporär brauche ist auf größeren und anderen SSDs.

Außerdem, bedenke auch die Erleichterungen für Maintainer bzw. Entwickler von Apps oder des OS. Maintainer werden entlastet, die Entwickler von Apps erreichen leicht mehr Menschen.
Als sehr prominentes Beispiel zeigt SteamOS (Steamdeck), dass die Kombination praxistauglich funktioniert. Oder eben die Vielzahl von immutablen Distributionen, die genau so oder ähnlich aufgebaut sind.

 

[Caramon2]

Bei AppImages hab ich eine Datei, die irgendwo in der Verzeichnisstruktur liegt, es gibt keinen Starter dafür unter /usr/share/applications/, sodass die Anwendung dann nicht im Startmenü auftaucht. Außerdem gibt es keine automatischen Updates, nachdem die AppImage-Datei erst mal heruntergeladen worden ist.

Der Startmenü-Eintrag kann man sich mit Menulibre leicht erstellen: So nutze ich LibreOffice 7.4.7 (das neue GUI finde ich unpraktisch, außerdem brauche ich es kaum und es hat genervt, dass es oft häufiger aktualisiert wird, als ich es überhaupt nutze) und AVIdemux (weil der Dateirequester, den die regulär installierte Version nutzt, für mich auch unpraktisch ist).

Mit Flatpaks hatte ich bisher nicht zu tun, vermute aber ähnliche Kleinigkeiten, die die Usability trüben.

Das ist ein Feature!

Die einzigen Gründe für die Verwendung von Snap/AppImage/Flatpak, die mir einleuchten, ist die Portabilität (die bei Snaps nicht mal gegeben ist) und das Sandboxing.

Selbst das AppImage ist nur bedingt portabel, weil es seine Einstellungen wie eine reguläre Installation im Benutzerordner speichert und im Gegensatz zu Snap und Flatpak gibt es dort (afsik) kein Sandboxing.

Der Vorteil besteht darin, dass Flatpak und Co. Distributionsunabhängig funktionieren

Bedingt: Wird eine Mindestversion von Snap/Flatpak, die es z. B. für eine ältere (aber noch offiziell unzerstutzte) Version von Debian nicht gibt, kann man es nicht nutzen.

Eigentlich finde ich es krass, dass jede Applikation auf jegliche Dateien des Nutzers zugreifen kann. Das ist im Regelfall nicht notwendig und sollte nur nach Expliziter Erlaubnis möglich sein.

Wie eine Firewall für's Dateisystem.

Die Anwendung XY möchte auf die Datei ABC zugreifen:

• erlauben
• verweigern
• der ganzen Ordner freigegeben

[ ] Auswahl merken​

 

[Pummeluff]

Im Gegenteil finde ich ist das ein Feature das längst überfällig ist und nur deshalb nicht existiert, weil man es nachträglich kaum ins Betriebssystem einbauen kann. Smartphones haben das ja alle, weil das von Anfang an so gebaut wurde. Windows und Linux beide nicht, sollten es aber haben. Eigentlich finde ich es krass, dass jede Applikation auf jegliche Dateien des Nutzers zugreifen kann. Das ist im Regelfall nicht notwendig und sollte nur nach Expliziter Erlaubnis möglich sein.

In Android hat das durchaus seine Berechtigung, da sämtliche Apps aus "unbekannten Quellen" kommen und aus der Historie heraus auch mit den Nutzerdaten Geld verdienen wollen. Auch laufen Android-Apps in der Regel autark, d.h. benötigen nicht die Funktionalität einer anderen App. Und das OS ist sowieso nicht schreibbar ohne Root-Rechte bei Android. Als laufen die Apps jeweils unter unterschiedlichen Nutzern.

Linux ist aber dann doch etwas anders konzipiert, weswegen Dein Ansatz ziemlich ungünstig wäre. Anwendungen haben Abhängigkeiten. An welcher Stelle willst du unterscheiden, ob eine Anwendung am "Ende der Nahrungskette" steht oder ob das nur eine Abhängigkeit ist, die eine andere Anwendung benötigt? Soll jetzt bei jeder Abhängigkeit eine Abfrage kommen, ob das zu startende Programm auf die entsprechende Lib zugreifen darf? Beispiel:

Spoiler: Abhängigkeiten von Gimp

ldd /usr/bin/gimp

        linux-vdso.so.1 (0x00007f1fab245000)
        libgimpwidgets-2.0.so.0 => /usr/lib64/libgimpwidgets-2.0.so.0 (0x00007f1fab17b000)
        libgtk-x11-2.0.so.0 => /usr/lib64/libgtk-x11-2.0.so.0 (0x00007f1faa200000)
        libgdk-x11-2.0.so.0 => /usr/lib64/libgdk-x11-2.0.so.0 (0x00007f1faa741000)
        libgimpconfig-2.0.so.0 => /usr/lib64/libgimpconfig-2.0.so.0 (0x00007f1fab162000)
        libgimpmath-2.0.so.0 => /usr/lib64/libgimpmath-2.0.so.0 (0x00007f1fab15a000)
        libgimpthumb-2.0.so.0 => /usr/lib64/libgimpthumb-2.0.so.0 (0x00007f1fab14c000)
        libgimpcolor-2.0.so.0 => /usr/lib64/libgimpcolor-2.0.so.0 (0x00007f1fab131000)
        libgimpmodule-2.0.so.0 => /usr/lib64/libgimpmodule-2.0.so.0 (0x00007f1fab12a000)
        libgimpbase-2.0.so.0 => /usr/lib64/libgimpbase-2.0.so.0 (0x00007f1fab0fc000)
        libgdk_pixbuf-2.0.so.0 => /usr/lib64/libgdk_pixbuf-2.0.so.0 (0x00007f1faa712000)
        libpangocairo-1.0.so.0 => /usr/lib64/libpangocairo-1.0.so.0 (0x00007f1fab0ea000)
        libpangoft2-1.0.so.0 => /usr/lib64/libpangoft2-1.0.so.0 (0x00007f1fab0d0000)
        libpango-1.0.so.0 => /usr/lib64/libpango-1.0.so.0 (0x00007f1faa6a7000)
        libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007f1faa1b3000)
        libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007f1faa0eb000)
        libharfbuzz.so.0 => /usr/lib64/libharfbuzz.so.0 (0x00007f1fa9f9f000)
        libcairo.so.2 => /usr/lib64/libcairo.so.2 (0x00007f1fa9e5b000)
        libgegl-0.4.so.0 => /usr/lib64/libgegl-0.4.so.0 (0x00007f1fa9d76000)
        libgegl-npd-0.4.so => /usr/lib64/libgegl-npd-0.4.so (0x00007f1faa69b000)
        libjson-glib-1.0.so.0 => /usr/lib64/libjson-glib-1.0.so.0 (0x00007f1faa66f000)
        libbabl-0.1.so.0 => /usr/lib64/libbabl-0.1.so.0 (0x00007f1fa9c25000)
        liblcms2.so.2 => /usr/lib64/liblcms2.so.2 (0x00007f1fa9bc0000)
        libgexiv2.so.2 => /usr/lib64/libgexiv2.so.2 (0x00007f1fa9b81000)
        libgio-2.0.so.0 => /usr/lib64/libgio-2.0.so.0 (0x00007f1fa9991000)
        libgobject-2.0.so.0 => /usr/lib64/libgobject-2.0.so.0 (0x00007f1fa9930000)
        libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007f1fa97e2000)
        libz.so.1 => /usr/lib64/libz.so.1 (0x00007f1fa97c8000)
        libmypaint.so.0 => /usr/lib64/libmypaint.so.0 (0x00007f1fa97aa000)
        libm.so.6 => /usr/lib64/libm.so.6 (0x00007f1fa96fa000)
        libc.so.6 => /usr/lib64/libc.so.6 (0x00007f1fa9533000)
        libgmodule-2.0.so.0 => /usr/lib64/libgmodule-2.0.so.0 (0x00007f1faa664000)
        libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007f1fa93eb000)
        libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00007f1fa93e3000)
        libatk-1.0.so.0 => /usr/lib64/libatk-1.0.so.0 (0x00007f1fa93bc000)
        libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x00007f1fa93af000)
        libXi.so.6 => /usr/lib64/libXi.so.6 (0x00007f1fa9399000)
        libXrandr.so.2 => /usr/lib64/libXrandr.so.2 (0x00007f1fa938c000)
        libXcursor.so.1 => /usr/lib64/libXcursor.so.1 (0x00007f1fa937e000)
        libXcomposite.so.1 => /usr/lib64/libXcomposite.so.1 (0x00007f1fa9379000)
        libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x00007f1fa9374000)
        libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007f1fa935f000)
        libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007f1fa9324000)
        libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x00007f1fa9272000)
        libfribidi.so.0 => /usr/lib64/libfribidi.so.0 (0x00007f1fa9252000)
        libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007f1fa9227000)
        libbz2.so.1 => /usr/lib64/libbz2.so.1 (0x00007f1fa9211000)
        libgraphite2.so.3 => /usr/lib64/libgraphite2.so.3 (0x00007f1fa91eb000)
        libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007f1fa91c0000)
        libxcb-render.so.0 => /usr/lib64/libxcb-render.so.0 (0x00007f1fa91b1000)
        libxcb-shm.so.0 => /usr/lib64/libxcb-shm.so.0 (0x00007f1fa91ac000)
        libpixman-1.so.0 => /usr/lib64/libpixman-1.so.0 (0x00007f1fa910b000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f1fab247000)
        libexiv2.so.28 => /usr/lib64/libexiv2.so.28 (0x00007f1fa8c00000)
        libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/14/libstdc++.so.6 (0x00007f1fa8800000)
        libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/14/libgcc_s.so.1 (0x00007f1fa90db000)
        libmount.so.1 => /usr/lib64/libmount.so.1 (0x00007f1fa9068000)
        libffi.so.8 => /usr/lib64/libffi.so.8 (0x00007f1fa905b000)
        libpcre2-8.so.0 => /usr/lib64/libpcre2-8.so.0 (0x00007f1fa8faa000)
        libjson-c.so.5 => /usr/lib64/libjson-c.so.5 (0x00007f1fa8f96000)
        libgomp.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/14/libgomp.so.1 (0x00007f1fa8f3f000)
        libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007f1fa8bfa000)
        libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00007f1fa8bf2000)
        libINIReader.so.0 => /usr/lib64/../lib64/libINIReader.so.0 (0x00007f1fa8be8000)
        libblkid.so.1 => /usr/lib64/libblkid.so.1 (0x00007f1fa8b8a000)
        libinih.so.0 => /usr/lib64/libinih.so.0 (0x00007f1fa8b85000)

Viel Spaß beim Klicken der Berechtigungen.

In Linux gibt's ein anderes Konzept: SELinux (alternativ Apparmor). Da wird über Policies festgelegt, welche Verzeichnisse und welche Ports und welche Berechtigungen bestimmte Apps benötigen.

Beispiel: Das Standardverzeichnis für Webserver-Inhalte ist /var/www/html, Standardports sind 80 und 443. Willst du jetzt einen anderen Port im Webserver konfigurieren, z.B. 22, dann knallt Dir SELInux eine Fehlermeldung um die Ohren. Über eine manuelle Policy könntest du auch diesen Port dafür freischalten. Aber dass muss in den Policies manuell konfiguriert werden.

Die nächste Rechtetrennung hast du schon über die verschiedenen Nutzer bei Diensten.

ps aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
systemd+     693  0.0  0.0  15396  7040 ?        Ss   16:42   0:00 /usr/lib/systemd/systemd-networkd
message+     891  0.0  0.0   8460  3944 ?        Ss   16:42   0:00 /usr/bin/dbus-daemon --system --addre
polkitd     1030  0.0  0.0 381140  7944 ?        Ssl  16:42   0:00 /usr/lib/polkit-1/polkitd --no-debug

Systemd bietet die Möglichkeit Dienste unter virtuellen Nutzern laufen zu lassen, die nicht auf dem System existieren mit temporären Working Directories, aus denen sie nicht rauskommen. Siehe dazu Dynamic Users, was im Grunde genommen der User-Separierung analog zu Android entspricht.

Du siehst also, dass es durchaus haufenweise Möglichkeiten gibt, auch unter Linux Anwendungen voneinander zu trennen. Dass jetzt im Userkontext Libreoffice den Firefox nicht sehen darf, ist ein wenig zu kurz gedacht.

 

[Uridium]

Firejail spezialisiert sich ebenfalls auf die Isolation von Desktop Applikationen. Es bringt von Haus aus bereits viele vordefinierte App-Konfigurationen mit.

 

[Grimba]

Ich glaube ehrlich gesagt nicht, dass man in dem ganzen Kontext der Debatte von überlegen und unterlegen sprechen kann, außer vielleicht in einzelnen Aspekten.

Sachen wie snap, flatpak, AppImage und AppArmor, SELinux etc. entstehen ja nicht im luftleeren Raum. Solche Technologien schließen ja Lücken und/oder machen ganz neue Konzepte möglich, auch wenn einige von ihnen schon echt alt sind, die ein klassiches Linux mit seiner herkömmlichen Paket- und Rechteverwaltung so nicht bietet.

Dabei komme ich selber eher aus der klassischen Ecke, das bringen die Jährchen mit sich. Solche Sachen wie Fedora Silverblue, MicroOS oder Ubuntu Core triggern bei mir Skepsis und wirken auf mich auch erstmal wie neumodischer Kram und Overkill. Auch setze ich auch nicht primär auf Flatpaks, gerade als Archer neigt man ja sowieso dazu, das AUR vorzuziehen. Anderseits stelle ich dann wiederum bei meinem Steamdeck fest, wie gut sowas klappt ohne echte Reibungspunkte.

Mittlerweile sehe ich diesen Strauß an ganz neuen Möglichkeiten als Teil der natürlichen Weiterentwicklung der Plattform. Und kann mich durchaus für neue Möglichkeiten begeistern. In snap ist es z.B. möglich, ein komplettes Nextcloud Setup einfach so als snap zu installieren. Ob ich jetzt snap mag oder nicht, ist ja egal, sowas ist schon irgendwie trotzdem beeindruckend.

 

[Uridium]

Zumindest ist es eine elegante Lösung, um die Problematik der statischen Kompilierung zu umgehen. Die bis dahin wohl einzige Möglichkeit, echte zero-dependency/baremetal Portabilität zu erlangen.

Ich bin auch kein Freund von Flatpaks und Co, muss aber eingestehen, dass ich durchaus erleichtert war als Linphone (AUR), das aufgrund der massiven Abhängigkeiten ständig defekt war (compile error), endlich als (problemfreies) AppImage erschien. Das Programm war ansonsten nur als Nightly, bzw. Entwicklerversion ausschließlich in der offiziellen Distribution verfügbar.

Demnach sind Universalpakete sicherlich besser als nichts.

 

[Everlast]

Für jemanden wie mich, der sich für einen Linux-Umstieg interessiert weil bei Windows alles eher schlimmer wird (Probleme sind ja bekannt) - gibt es da eine generelle Empfehlung für Systempaket oder Flatpak ?

Mir fehlt da noch der Background - wann sollte man denn zu was greifen ? Oder gibt es keine Empfehlung Pro Systempack bzw. Flatpak ?

Ich hab nur für mich rausgefunden, dass Systempakete oft um einiges älter sind als Flatpaks und so erscheint es mir vielleicht sinnvoll zu Flatpak zu greifen, wenn dieses Neuerungen gegenüber dem Syspaket hat, die ich unbedingt brauche.

Ich weiß, jeder von euch hat da seine eigenen Präferenzen - aber eine grobe Info, wie ich mich am besten orientieren kann ? Generell zum Systempaket und nur, wenn ich mit der Version Probleme haben soll zur Flatpak greifen ?

Ich hatte auch gelesen, wenn ich ein Tool von einer Herstellerseite installiere, dass es dann nicht von der Linux-Distri automatisch upgedatet wird. Ich nehme mal an, Systempakete aus der Anwendungsverwaltung werden geupdatet - was muss man tun, falls ein Programm nicht automatisch Updates bekommt, damit es vom System aktualisiert wird ?

Herzlichen Dank !

 

[Tanzmusikus]

Ich hab nur für mich rausgefunden, dass Systempakete oft um einiges älter sind als Flatpaks

Das kommt auf die Distribution bzw. dessen Art an. Bei Rolling Release hat man i.d.R (außer z.B. Manjaro) immer die neuesten Pakete.

Flatpak lohnt sich eher dann, wenn das gewünschte Programm über den Paketmanager nicht erhältlich ist ... oder eine ältere Version explizit gewünscht ist. Gibt noch mehr Gründe.

Generell zum Systempaket und nur, wenn ich mit der Version Probleme haben soll zur Flatpak greifen ?

Ja, Probleme können auch ein möglicher Grund sein. Dies gilt aber vice versa. 😉

Ich empfehle die Systempakete zu bevorzugen. Bei o.g. oder anderen Gründen können dann Alternativen (z.B. Flatpak, AppImmage oder selbst geladene bzw. selbst kompilierte Pakete) genutzt werden.

Bei Point Releases kann es allerdings bei Upgrades auf die nächste Version zu Problemen kommen. Dann besser diese Pakete vorher deinstallieren und nach dem Upgrade erneut installieren.

was muss man tun, falls ein Programm nicht automatisch Updates bekommt, damit es vom System aktualisiert wird ?

Das Paket müsste dann eigenständig aktualisiert werden. Dabei sind auch die Abhängigkeiten zu beachten.

Meine persönliche Empfehlung: Lass dir Zeit beim Ausprobieren. Ich nutze übrigens neben Linux auch noch Windows 10.

 

[Pummeluff]

Für jemanden wie mich, der sich für einen Linux-Umstieg interessiert weil bei Windows alles eher schlimmer wird (Probleme sind ja bekannt) - gibt es da eine generelle Empfehlung für Systempaket oder Flatpak ?

Als Umsteiger solltest erst mal von Flatpak ganz die Finger lassen. Lern erstmal das System überhaupt kennen, ohne es gleich verbiegen zu wollen.

Ich hatte auch gelesen, wenn ich ein Tool von einer Herstellerseite installiere, …

Auch das ist schon wieder ungünstig. Verwende erstmal die Pakete, die Dir die Distribution mitliefert.

was muss man tun, falls ein Programm nicht automatisch Updates bekommt, damit es vom System aktualisiert wird ?

Geht nicht. Du installierst das am Paketmanager vorbei. Der Paketmanager kann nicht wissen, ob es dafür eine neue Version gibt.

 

[sedot]

Für jemanden wie mich, der sich für einen Linux-Umstieg interessiert weil bei Windows alles eher schlimmer wird (Probleme sind ja bekannt) - gibt es da eine generelle Empfehlung für Systempaket oder Flatpak ?

Gibt keine generell anwendbare Empfehlung.
Wenn die Distribution alle für dich nötige Software aus den eigenen Repositories in den aktuellsten Versionen anbietet, super. Falls nicht sind Flatpaks auch gut, die ja auch von einem Repository (flathub) kommen.
Manche Entwickler bieten auch „nur“ Flatpaks an, da ist die Auswahl entsprechend für dich ohnehin nicht gegeben. Und, es gibt Distributionen die gänzlich auf Flatpaks setzen.

Mach dich nicht verrückt, das sind Details, funktional sind die Unterschiede minimal. Ausprobieren geht hier tatsächlich über studieren.
Viel schwieriger fand ich persönlich nach der Wahl der Distribution die Entscheidung zur Desktop Umgebung (Gnome, KDE Plasma, Xfce, Cinnamon, etc.). 😅

 

[Garmor]

die ja auch von einem Repository (flathub) kommen

Oder auch von einem anderen. Fedora hat beispielsweise erst mal nur ein eigenes Flatpak-Repo vorkonfiguriert und man muss selber Flathub nachtragen. 🫣

 

[sedot]

@Garmor
Ja, Fedora ist eine Ausnahme.

 

[Grimba]

Ich weiß, jeder von euch hat da seine eigenen Präferenzen - aber eine grobe Info, wie ich mich am besten orientieren kann ? Generell zum Systempaket und nur, wenn ich mit der Version Probleme haben soll zur Flatpak greifen ?

Ich denke du hast das schon richtig erkannt. Um hier mal den Hintergrund zu liefern:

Software-Pakete aus der Distribution lösen eben auch sämtliche Abhängigkeiten, also Bibliotheken etc., in der Distribution auf. D.h. die Distribution sorgt dafür, dass dieser Zusammenhang nicht durch neue Versionen einzelner Pakete bricht und dadurch Software nicht mehr startet. Deshalb sind Pakete der Distribution oft älter als in Flatpak & Co. weil man das Gesamtgefüge nicht brechen möchte.

Wie bereits erwähnt gibt es rollende Distributionen, die sich bemühen, hier immer die neusten Pakete zu liefern und eben Point Releases, so wie z.B. Debian, die hier relativ strikt Versionen beibehalten, aber Sicherheitspatches backporten. Daraus ergeben sich relativ offensichtlich zwei Stärken und Schwächen bei beiden Varianten:

Rolling Release hat als Vorteil immer neue Software, ändert aber immer mal wieder grundlegende Systempakete, ggf. muss selbst hand angelegt werden, um den Übergang zu ermöglichen. Das kann auch schon mal ein holpriger Übergang werden.

Point Releases vermeiden genau das, du schaltest den Rechner an, du kannst arbeiten, immer. So zumindest ist das gedacht. Dafür ist die Software ggf. älter, Features fehlen bzw. man muss auf die nächste Distributionsversion für neue warten.

Flatpaks & Co. sind per Definition außerhalb dieses Gesamtgefüges und liefern ihre Abhängigkeiten distributions-agnostisch selber mit. Somit ist es auf diesem Weg einfacher, neue Software zu bekommen, als wenn man sich für z.B. sein Debian jedesmal selbst die Software neu herunterladen muss oder ein fremdes Repo zu finden, wo man darauf angewiesen ist, dass der Herausgeber hier auch gut mitarbeitet, so dass nichts bricht. Allerdings sind Flatpaks auch nicht den Sicherheitsstandards der Distribution unterworfen, d.h. es kann passieren, dass eine Sicherheitslücke in einer Software innerhalb der Distribution schnell gefixt ist, selbst wenn die Version älter ist, und das erst später im Flatpak passiert.

Natürlich ist das vermutlich selten, ich wollte damit nur darauf hinweisen, dass man auch bei Flatpaks eben, genau wie bei fremden Repositories, ein Auge auf den Herausgeber haben sollte. Innerhalb der Distribution hingegen sind solche Verantwortlichkeiten klar geregelt.

Eine einfache Faustregel hier abzuleiten, fällt insofern schwer, weil die Philosophie in Linux ja ist, dass du derjenige bist, der souverän über sein System entscheidet. Also wähle eine Herangehensweise aus, in der du dich am besten wiederfindest. Ich bin derzeit z.B. hauptsächlich mit CachyOS (Arch) unterwegs, habe gar kein Flatpak derzeit im Einsatz, und vereinzelte AUR Pakete. Was du mit der Info machst, bleibt dir überlassen.

 

[WhiteHelix]

Meine persönliche Einstellung dazu ist auch, wenn möglich, bevorzuge ich das Paket aus dem Distro-Repo. Ich will allerdings auch immer möglichst aktuelle Pakete haben, daher auch immer Rolling Release Distros bei mir. Gibt es jetzt ein Paket aus Grund XY nicht im Repo, dann schau ich auch zum Flatpak. War bei mir z.B. Obsidian unter Fedora, das gibts nicht direkt per Repo.

Gibt ja auch durchaus Apps, die gibts sogar ausschließlich als Flatpak. Bottles ist da so ein Beispiel, das gibts ausschließlich so und gar nicht anders. Hatte mit dem Ansatz auch nie wirkliche Probleme, Flatpak kann aber durchaus eigene Probleme mitbringen was Berechtigungen und Co. angeht. Gerade wenn du grade einsteigst und da nicht so den mega Einblick hast (hab ich auch heute noch nicht), dann kann das auch zu nicht nachvollziehbaren Problemen führen. Das hatte ich ganz am Anfang mit nem Sega Emulator, aus Berechtigungsgründen konnte der dann keine Save-Files ablegen. War da ein reines Flatpak-Problem, nicht von der Anwendung.

 

[Hyourinmaru]

Ich (EndeavourOS/Arch-based@KDE Plasma) handhabe das tatsächlich auch so, dass ich immer die Systempakete bevorzuge, die in den Repos meiner Distro vorhanden sind. Wenn es sie da nicht gibt, schaue ich ins AUR, ob es da was gibt. Da es sich bei den allermeisten AUR-Einträgen um Git/Gitlab/Github-Projekte handelt, stehen dort eigentlich immer Vorgehensweisen drinnen, wie man das Package installiert resp. das Repo klont. Sollten alle Stricke reißen und im AUR ist auch nichts zu finden, dann schaue ich zuletzt auf Flathub nach.
Außer das Paket gibt es aus dem AUR und auf Flathub und das AUR-Paket funktioniert aus irgendwelchen Gründen nicht, dann hole ich mir dieses von Flathub ran.

 

[Kuristina]

Ich persönlich halte mich nur an die Systempakete in den Repos und bisserl aus dem AUR. Damit kann ich alles abdecken und bin immer gut mit gefahren.

Gibt ja auch durchaus Apps, die gibts sogar ausschließlich als Flatpak. Bottles ist da so ein Beispiel, das gibts ausschließlich so und gar nicht anders.

Pauschal nicht richtig. Mit Arch braucht man auch da kein Flatpak.

 

[WhiteHelix]

Das AUR hab ich da jetzt mal explizit nicht beachtet, vom Dev gibts das nur als Flatpak. Community ist ja wieder ne andere Geschichte. Nachdem die Frage jetzt auch allgemein gestellt war, war mir das auch zu spezifisch auf Arch ehrlich gesagt.

 

[BOBderBAGGER]

Als Umsteiger solltest erst mal die Finger von Flatpak ganz die Finger lassen. Lern erstmal das System überhaupt kennen, ohne es gleich verbiegen zu wollen.

Führt oft kein leichter Weg dran vorbei. Ist auch kein Drama solange man bei flathub bleibt afaik ist Mint ohnehin von Haus aus dafür konfiguriert.

Ergänzung (27. Mai 2025)

Mit Arch braucht man auch da kein Flatpak.

Die haben theoretisch alle Pakete, die Arch Wiki sagt selbst Tldr: willst du die discord App wir weniger theater installier ein flatpack

Ergänzung (27. Mai 2025)

und man muss selber Flathub nachtragen. 🫣

Ist alles an Bord muss nur aktiviert (haken setzen) werden.