Flatpak vs RPM? Sind Flatpaks überhaupt sicher?

[Krakadil]

Abend,

ich hätte zu Flatpak's zwei Fragen.
Nachdem ich mich eingelesen habe, habe ich alles andere als ein gutes Gefühl bei Flatpak's.

Nehmen wir Spotify als Beispiel.
Hersteller: https://www.spotify.com/us/download/other/
Flatpak: https://flathub.org/apps/details/com.spotify.Client

Spotify bietet keine Flatpak an, nur .deb (Debian) und Snap. Bei Flathub wird Spotify als "Developer" angegeben, dabei wird das nicht von Spotify bereitgestellt.
Zwei weitere Beispiele:
https://flathub.org/apps/details/org.standardnotes.standardnotes
https://flathub.org/apps/details/com.simplenote.Simplenote

In keinem der Fälle vom Hersteller selbst bereitgestellt. Was mich dann noch weiter verwundert sind Beispiele wie diese:
https://mpv.io/installation/

Selbst diese stellen keine Flatpak bereit, was mich schon sehr verwundert.

Frage 1: Wie sicher bzw. unsicher sind Flatpak's? Ich kann ja im Grunde als 0815 Anwender nichts überprüfen? Ein Media-Player kann zwar kaum Schaden anrichten aber überall wo man sich anmelden muss, könnte der Account gestohlen werden?

Frage 2: Wenn ich die Wahl habe, sollte ich auf RPM setzen oder trotzdem zu Flatpak greifen?
Vor Fedora habe ich damals alles selbst getestet. So lief Spotify zum Beispiel als Flatpak perfekt und somit besser als Snap, deb und auch Arch. Auch andere Anwendungen, wie JDownloader, laufen als Flatpak so viel besser/schneller als der "native Weg".


Was habe ich hier falsch verstanden?

 

[0x8100]

Was habe ich hier falsch verstanden?

das siehst du schon richtig, in diesen fällen musst du den erstellern der flatpaks vertrauen. ist das gleiche wie mit dem aur bei arch.

du kannst dir natürlich die build-anweisungen anschauen und das flatpak zur not auch selber lokal bauen, dann weisst du, was passiert und woher das eigentliche programm kommt. im falle von spotify ist das übrigens das snap von ubuntu -> https://github.com/flathub/com.spotify.Client/blob/master/com.spotify.Client.json:

{
    "name": "spotify",
    "sources": [
        {
            "url": "https://api.snapcraft.io/api/v1/snaps/download/pOBIoZ2LrCB3rDohMxoYGnbN14EHOgD7_60.snap",
        }
    ]
}

 

[kim88]

Frage 2: Wenn ich die Wahl habe, sollte ich auf RPM setzen oder trotzdem zu Flatpak greifen?

Musst du von Fall zu Fall entscheiden. Aber ganz pauschal kann man sagen Snaps und Flatpaks sind in der Regel „sicherer“ dank Sandbox.

Frage 1: Wie sicher bzw. unsicher sind Flatpak's? Ich kann ja im Grunde als 0815 Anwender nichts überprüfen?

Jein. Du kannst grundsätzlich min. bei Flathub immer schauen wie die Pakete gebaut werden so wie es @0x8100 hier angemerkt hat.

Grundsätzlich hast du dieses Problem aber immer. Egal ob Windows, Linux oder Android, oder Mac, etc

Du musst dem vertrauen der dir die Software anbietet. In der VLC.exe die du irgendwo aus dem Internet runterlädst kann auch Schadsoftware sein.
Theoretisch kann auch ein Maintainer bei Fedora schadsoftware in die Pakete einbauen.
Bei OpenSource kannst du in der Regel entweder die Binaries selber nachbauen oder bei Fedora, Debian und Co prüfen wie die gebaut wurden.

Aber wer macht das schon für alle Pakete 🤷‍♂️


Bei Snap und Flatpak hast du aber den Vorteil der Sandbox (gilt auch für iPhone und Apps aus dem Mac App Store - ich glaube auch bei Android kenne mich auf der Platzform nur schlecht aus).

Daher die App in der Sandbox hat z.b kein Zugriff auf den komplettes Homeverzeichnis sondern nur auf ausgewählte Verzeichnisse.
Beispiel Firefox als RPM kann auf alle Dateien im Homeverzeichnis zugreifen, lesen oder versenden.
Firefox als Snap oder Flatpak in der Regel nur aufs Downloadverzeichnis, etc

Daher Flatpak kann man pauschal als sicherer bezeichnen.

 

[sedot]

Selbst diese stellen keine Flatpak bereit, was mich schon sehr verwundert.

https://flathub.org/apps/details/io.mpv.Mpv

Ich empfinde die Entwicklung hin zu flatpak grundsätzlich als positiv und nutze selbst gern diese Pakete, genauso wie appimage.
Für flatpaks gibt es auch flatseal falls du Rechte von Anwendungen selbst kontrollieren willst.
https://flathub.org/apps/details/com.github.tchx84.Flatseal

Wie sicher bzw. unsicher sind Flatpak's?

Sicher genug würde ich vermuten, openSUSE MicroOS und Fedora Silverblue bauen vollständig auf flatpak bei ihren Desktop-Varianten.

 

[Krakadil]

Flatpaks laufen sehr gut unter Fedora und ich nutze diese auch sehr gerne, bitte nicht falsch verstehen.

Grundsätzlich hast du dieses Problem aber immer. Egal ob Windows, Linux oder Android, oder Mac, etc

Das sehe ich hier nicht so.
Wenn ich die .exe beim Hersteller/Entwickler auf der Homepage herunterlade, dann sehe ich hier keine Gefahr. Auch in dem Beispiel bei Spotify nicht. Die verweisen ja auf Snap, welches ich jedoch nicht nutzen würde.

 

[netzgestaltung]

Wenn ich die .exe beim Hersteller/Entwickler auf der Homepage herunterlade, dann sehe ich hier keine Gefahr.

Naja, es gab/gibt halt schon viele unseriöse Hersteller - auch abseits von MS, Google oder Avast

Malware/Suchleisten die mitinstalliert werden - ich weis nicht wie oft ich irgendwelche Windows-PCs von der
ASK Suchleiste befreit habe. Sowas will man sich halt auch wieder nicht eintreten. Ich nutze Flatpaks eigentlich immer nur, wenn es kein RPM gibt.
Die Ordner lassen sich zwar umbiegen, bequem find ich das aber nicht. Daher vermeide ich Flatpaks vor allem dann, wenn die Programme in verschiedenen Ordnern arbeiten können sollen.

Wenn ich aber aus AUR zb den Shiginima-Launcher installiere brauch ich mir über Seriosität keine Gedanken mehr machen...

 

[kim88]

Wenn ich die .exe beim Hersteller/Entwickler auf der Homepage herunterlade, dann sehe ich hier keine Gefahr.

Theoretisch müsstest du auch da die Prüfsummen checken.
Auch da kann jemand Zugriff auf den Server erhalten und plötzlich die EXE austauschen.

Ist z.b auch mal Linux Mint passiert, wo das ISO ausgetauscht wurde Leute über die offizielle Webseite ein manipuliertes ISO heruntergeladen haben.

Oft ist es auch nicht einfach die Herstellerwebseite zu identifizieren.

Wenn jemand nach VLC Download sucht kann man schnell mal bei vlc-download.de landen - sieht auf den ersten blick seriös aus, will nicht wissen was für ein EXE man dort bekommt.

 

[Krakadil]

Naja, es gab/gibt halt schon viele unseriöse Hersteller - auch abseits von MS, Google oder Avast

Nehmen wir an du willst dir Spotify herunterladen.

A) du gehst auf Spotify.com und lädst dir die Datei
B) du suchst eine Spotify.exe Datei und meides die Homepage vom Hersteller

Wie wahrscheinlich wäre Punkt B?

. Ich nutze Flatpaks eigentlich immer nur, wenn es kein RPM gibt.

Warum?

Die Ordner lassen sich zwar umbiegen, bequem find ich das aber nicht. Daher vermeide ich Flatpaks vor allem dann, wenn die Programme in verschiedenen Ordnern arbeiten können sollen.

Mit Flatseal ist das überhaupt kein Problem. Das bekomme ich sogar als ultra Noob hin und das beim ersten Versuch oder keinst du was anderes?

Auch da kann jemand Zugriff auf den Server erhalten und plötzlich die EXE austauschen.

Das ist möglich aber wie oft ist das seit Windows XP passiert? 2 mal?

 

[netzgestaltung]

A) B)

Schau bei Android werden auch keine EXE Downloads angeboten. Erwartet sich auch keiner. Es gibt es App-Store, einige alternativ-App-Stores und einige Bastellösungen.

Bei Linux gibts halt "alles" machbar, je nachdem, sogar EXE ausführen. Ich finde es nicht so bequem für jedes Programm die Pfade festzulegen. Dafür hab ich ja den Home Ordner und alle Pfade sind klar.

Ergänzung (20. Dezember 2022)

Es gab und gibt immer viele Seiten, auch direkt von Herstellern mit Werbung zugemüllt und der größte, bunteste Downloadbutton geht zu irgendeinem Affiliate-Link. Das ist mmn genauso schlimm wie eine verseuchte exe oder mit zusatzprogrammen angereichert. Das sind Dinge von denen man abseits der Windows-Welt großteils einfach verschont bleibt.

 

[Pummeluff]

Bei Snap und Flatpak hast du aber den Vorteil der Sandbox…

Daher die App in der Sandbox hat z.b kein Zugriff auf den komplettes Homeverzeichnis sondern nur auf ausgewählte Verzeichnisse.
Beispiel Firefox als RPM kann auf alle Dateien im Homeverzeichnis zugreifen, lesen oder versenden.
Firefox als Snap oder Flatpak in der Regel nur aufs Downloadverzeichnis, etc

Und genau das ist bei Snap eine Katastrophe.

Wir nutzen bei uns Ubuntu-Server mit zentralen Homeverzeichnissen, die per NFS eingebunden werden. Die Verzeichnisse liegen dabei nicht in /home/$User sondern /home/subirgendwas/$User. Snap nutzt dabei das Sicherheitskonzept von Apparmor, selbst wenn man auf dem System kein Apparmor nutzt (wir machen alles über iptables). Und dann tritt dieses Problem auf:

Man startet Firefox. Das rödelt eine Weile und beendet sich dann von selbst wieder mit "Permission denied". Ich hab wochenlang alle Bug-Reports durchsucht, hab das abweichende Home (Subdirectory) in die AppArmor-Config eingetragen. Ich hab es nicht hinbekommen Chromium oder Firefox zum Starten zu bewegen. Snap funktioniert dann und nur dann, wenn man konsequent eine unveränderte Standardinstallation verwendet.

Die Lösung bestand dann darin, Snap vom System zu verbannen und Firefox über das Mozilla-PPA zu installieren. Seitdem läuft's. Bei Chromium haben wir kein offizielles PPA gefunden. Also stellen wir keinen Chromium zur Verfügung.

Dazu kommt noch bei Snap, dass beim Start einer über Snap installierten Anwendung ein Loopback-Device erzeugt wird. Nutzt man mehrere Snap-Anwendungen, dann wird die Dateisystemtabelle (df) arg unübersichtlich.

Das oben erwähnte Downloadverzeichnis liegt dann auch nicht im Homeverzeichnis sondern unter /snap/irgendwas/andwendung/irgendwo/im/hundertsten/unterverzeichnis/downloads.

Bisher hatten wir mit Snap nur Probleme. Vorteile konnte ich noch nicht erkennen.

Etwas positiver beurteile ich Flatpack. Das hat seine Berechtigung, wenn bestimmt Pakete noch nicht über den Paketmanager der Distribution bereitgestellt werden. Z.B. hatte ich mal Gimp10 auf Fedora ausprobiert, als das noch nicht in den offiziellen Repos enthalten war.

Nachteil: Man muss sich schon merken, was man über die normalen Quellen und was über Flatpack installiert hat. Mehrere Paketmanager auf einem System birgt potentielle Konflikte.

Wenn ich die Wahl habe, sollte ich auf RPM setzen oder trotzdem zu Flatpak greifen?

Am gesündesten betrachte ich die Reihenfolge:

• Paketmanager der Distribution: Standardrepos, d.h. bei Dir RPM
• Paketmanager der Distribution: offiziell gepflegte Hersteller-Repos, die man zur Repoliste hinzufügt.
• Flatpack, allerdings mit der Prüfung in bestimmten Zeitabständen, ob das Paket nicht bei 1 oder 2 verfügbar ist.
• Wenn es wirklich ganz nötig ist: Einbindung eines sonstigen Repos.
• Wenn es ganz weh tut: Runterladen des Deb, RPM, sonstwas.
• Wenn es noch schlimmer wird: git clone der Sourcen und Bauen des Paketes, vorrangig mit Autobuild für Deb oder RPMBuild für RPMs.

Wenn ich die .exe beim Hersteller/Entwickler auf der Homepage herunterlade

bekommst du wahrscheinlich keine Updates, was über kurz oder lang zu Sicherheitsrisiken führt. Außerdem nutzen Hersteller auch gerne Downloadportale wie Softonic, die in der Vergangenheit schon ganz uneigennützig Browsertoolbars mitinstalliert und Viren verteilt haben.

Selbst Microsoft hat mit dem Versuch, einen Appstore zu etablieren, den Exe-Wildwuchs ausmerzen wollen. Die Installationen über Exe-Dateien zählt neben den ausführbaren E-Mails in Outlook und den Office-VB-Scripten zu den größten Sicherheitsproblemen in Windows.

 

[Krakadil]

Schau bei Android werden auch keine EXE Downloads angeboten. Erwartet sich auch keiner. Es gibt es App-Store, einige alternativ-App-Stores und einige Bastellösungen.

Ich glaube du verstehst nicht, was ich hier als Problem sehe.

Ich will Spotify herunterladen, gehe auf die Homepage von Spotify und finde dort was ich suche (.exe, APK, deb, Snap) aber eben kein Flatpak. Diese hat also irgendjemand bereitsgestellt und nicht Spotify selbst.

 

[garfield121]

Ich nutze Spotify (Flatpak) schon ziemlich lange ohne Probleme.

Die Kritik geht dahin, das nicht so klar ist, wer baut das Paket und lädt es hoch nach Flathub.
Im besten Fall der Hersteller selbst, aber der kann das weiterdelegieren.
Oder Irgendjemand anderes, sozusagen inoffiziell?
Da gab es schon diverse Diskussionen, das es transparenter werden muss!

 

[kim88]

Wir nutzen bei uns Ubuntu-Server mit zentralen Homeverzeichnissen, die per NFS eingebunden werden. Die Verzeichnisse liegen dabei nicht in /home/$User sondern /home/subirgendwas/$User. Snap nutzt dabei das Sicherheitskonzept von Apparmor, selbst wenn man auf dem System kein Apparmor nutzt (wir machen alles über iptables). Und dann tritt dieses Problem auf:

Dann passt Snap eben nicht in euren Use-Case. Ist ja kein Weltuntergang, ist ja nicht so das man Software über 100 andere Wege installieren könnte.
Es ging ja hier auch eher um den Use Case: Ein Rechner und Benutzer und Installation von Software -> ich bezweifle das in Unternehmen Spotify als Client an die User ausgerollt wird

Die Lösung bestand dann darin, Snap vom System zu verbannen und Firefox über das Mozilla-PPA zu installieren. Seitdem läuft's. Bei Chromium haben wir kein offizielles PPA gefunden. Also stellen wir keinen Chromium zur Verfügung.

In einem Unternehmen könnte man ja auch die Software die man benötigt über ein eigenes Repository zur Verfügung stellen.

Dazu kommt noch bei Snap, dass beim Start einer über Snap installierten Anwendung ein Loopback-Device erzeugt wird. Nutzt man mehrere Snap-Anwendungen, dann wird die Dateisystemtabelle (df) arg unübersichtlich.

"df" hat wie so ziemlich jedes Tool Manpages mit -x kann man Dinge in der Option nicht anzeigen lassen:

df -x"squashfs"

Wenn man das permanent will baut man sich eben ein Alias:

alias df='df -x"squashfs"'

Bisher hatten wir mit Snap nur Probleme. Vorteile konnte ich noch nicht erkennen.

Wie gesagt, vielleicht sind Snaps für euren Use Case völlig falsch. Deswegen zu behaupten das es keine Vorteile gibt ist halt schwierig.

Die Sandbox ist definitiv ein objektiver Vorteil.

Das man Software nun direkt vom Hersteller bekommt und die Distributionen die nicht kaputt patchen (man denke an Linux Mint, die die Google Suche aus Firefox rausgepatcht haben 🙄) ist je nach Betrachtungsweise ein Vor- oder Nachteil.

Das man jedes Update eines Snap Pakets easy zurück rollen kann - oder man z.b. ganz bewusst eine "alte" Version installieren kann, wenn man die braucht sind alles Vorteile die du mit klassischen Paket Managern nicht hast.

Kann sein, dass du das alles nicht brauchst - und das ist auch okay - aber Vorteile sind es definitiv.

Etwas positiver beurteile ich Flatpack. Das hat seine Berechtigung, wenn bestimmt Pakete noch nicht über den Paketmanager der Distribution bereitgestellt werden.

Soll ich jetzt aufzählen was mir alles an Flatpak missfällt?

Man kann nicht einfach "gimp" ausführen wenn es als Flatpak installiert ist, sondern muss immer dieses dämliche "flatpak run" eingeben und dann den kryptischen Programmnamen googeln gehen für Gimp wäre das:

flatpak run org.gimp.GIMP

Flatpak wurde designt, das man zwingend eine Desktop Session laufen haben muss, damit die Anwendungen überhaupt laufen. Im Serverbetrieb ist es kaum nutzbar.

All diese und auch weitere Dinge werden aber 99% der Nutzer kaum interessieren, weil es für Sie eben kein Problem darstellt. Daher kann ich nun auch ich sehe in Flatpak wegen diesen Punkte keine Vorteile. Richtiger formuliert ist aber Flatpaks sind für meinen Use-Case nicht die richtige Wahl -> das bedeutet aber nicht, dass Flatpaks keine objektiven Vorteile (wie z.b. Snadbox, etc) haben.

Mehrere Paketmanager auf einem System birgt potentielle Konflikte.

Nicht bei Snaps und Flatpaks.
Sowohl Snaps wie Flatpaks sind im Grunde Container-Technologien. Alles was du brauchst liefern die mit. Sie laufen beide ausserhalb vom "bin" Verzeichnis.
Weder kenne ich Berichte darüber, das Snaps oder Flatpaks in irgendwelche Systeminternas eingegriffen und Probleme verursacht hätten.

Ganz generell kann man hier sagen, dass es absolut kein Problem darstellt sowohl Pakete vom Paketmanager seiner Distribution, Snaps und Flatpaks gleichzeitig und Parallel zu nutzen.

Im Gegensatz zu z.b. NPM, das Dinge wenn man sie global installiert, gerne mal ins "bin" Verzeichnis schreibt und bestehende Software die über APT oder DNF dort parkiert wurde überschreiben kann.

Ich will Spotify herunterladen, gehe auf die Homepage von Spotify und finde dort was ich suche (.exe, APK, deb, Snap) aber eben kein Flatpak. Diese hat also irgendjemand bereitsgestellt und nicht Spotify selbst.

Die Frage ist warum genau das ein Problem ist. Snaps und Flatpaks sind noch relativ neu in der Linux Welt. Davor war es +/- 25 Jahre völlig normal Software zu installieren die nicht vom Hersteller selbst kommt. Wenn du in Fedora mit "sudo dnf install firefox" Firefox installierst, bekommst du kein Paket von Mozilla.

Du bekommst ein Paket von Fedora. Fedora nimmt den Quellcode von Firefox, macht sogar noch eigene Patches rein, baut dan ein eigenes Programm daraus und liefert dir das. Das gleiche gilt für Gimp, Libreoffice, Slype, etc.

Daher unter Linux war und ist es eigentlich immer völlig normal, dass du nicht Software direkt vom Hersteller sondern über einen dritten beziehst.

Mit Snaps und Flatpaks haben die Hersteller nun erstmals direkt die Möglichkeit Software unkompliziert für Linux anzubieten. Sie erscheinen sogar direkt in den Software Stores der Distributionen (Gnome-Software) das ist relativ neu -> und aus meiner Sicht auch ein Vorteil.

Wenn wir uns nunmal ansehen was Flathub beim Spotify Paket genau hinschriebt:

Dann sehen wir, das alles was hier steht stimmt.
Die Entwickler (Developer) vom Spotify Paket ist "Spotify". Du bekommst wenn du das Flatpak installierst 1:1 das Snap Paket, dass von Spotify bereitgestellt wurde.

Die Publisher (das sind die, die das Flatpak auf Flathub veröffentlich haben) bei denen steht "see Details" wenn wird dort drauf klicken. Kommst du auf eine GitHub Seite von Flathub aus der ersichtlich ist, dass es sich um ein Paket handelt deren Veröffentlichung von der Flathub Community gepflegt wird.

Daher das worüber du dich beklagst wird dir hier transparent mitgeteilt...

Oder Irgendjemand anderes, sozusagen inoffiziell?

Jeder kann auf Flathub ein Paket veröffentlichen, oder eigene Flatpak Repositorys wie z.b. Flathub erstellen.

 

[gio127]

Dazu kommt noch bei Snap, dass beim Start einer über Snap installierten Anwendung ein Loopback-Device erzeugt wird. Nutzt man mehrere Snap-Anwendungen, dann wird die Dateisystemtabelle (df) arg unübersichtlich.

Ja, das war für mich der Grund bei jeder Ubuntu-Installation, als erstes alle Snaps zu ersetzen. Angefangen hatten sie damals glaube ich noch mit dem gnome-system-monitor selbst, der als snap installiert war.

Bei mir ging es nicht um "df", sondern die System-Monitor-App. Ist zwar eher eine kosmetische Sache, aber wenn ich auf "Dateisysteme" klicke, dann bin ich eine übersichtliche Auflistung meiner Dateisysteme gewohnt und will nicht zwischen den ganzen "loopbacks" suchen müssen.

Aber flatpaks nutze ich mittlerweile auch. Jetzt auf Fedora 37 funktioniert z.B. die Dropbox app nicht mehr. Darum habe ich das als flatpak installiert und bin vollauf zufrieden.

Aber ich würde auch immer eher rpm's installieren (zumindest aus den fedora und fusion repositories). Dieses System war immer so effektiv und platzsparend. Mir wär lieber die verschiedenen Distributionen hätten sich auf die wesentlichen Dinge einigen können, die auch ohne flatpak und co. mehr dafür gesorgt hätten, dass Softwarepakete leichter auch distributionsübergreifend funktionieren.

 

[Merkmal]

Nachdem ich Snap und Flatpak verwendet habe, bin ich froh, dass es auch noch die Pakete der Distribution gibt, Fedora und Debian Stable sind ebenfalls installiert.

Bei Snap kam es in Ubuntu 22.04 dazu:

Name                 Version          Revision  Tracking       Herausgeber  Hinweise
bare                 -                5         latest/stable  canonical✓   beschädigt
canonical-livepatch  -                146       latest/stable  canonical✓   beschädigt
chromium             -                2221      latest/stable  canonical✓   beschädigt
core                 -                14399     latest/stable  canonical✓   beschädigt
core20               -                1695      latest/stable  canonical✓   beschädigt
core22               -                310       latest/stable  canonical✓   beschädigt

Mit snap remove firefox:

snap remove firefox
Fehler: cannot perform the following tasks:
- Daten von Snap "firefox" (2077) entfernen (unlinkat /var/snap/firefox/common/host-hunspell/de_DE.dic: read-only file system)

Weder ein löschen der Pakete, noch entfernen von Snap half diese beschädigten Pakete zu reparieren oder loszuwerden, hier gab es einen ähnlichen Fall: Beschädigte snap pakete entfernen oder reparieren.

Was mir an Flatpak nicht so zusagt, dass Flatpak user-namespaces verwendet, welches wiederum Lücken mit sich bringen kann und sich nicht mit Kernel hardening(1) verträgt.

Es kann ja jeder für sich entscheiden, was besser zu einem passt und die Vor- und Nachteile abwägen. Große Lust dem Snap-Fehler nachzugehen hatte ich nicht, weil ich zur Zeit wieder Debian Stable verwende.

 

[netzgestaltung]

Das ist mmn genauso schlimm wie eine verseuchte exe oder mit zusatzprogrammen angereichert.

hier ein aktuelles beispiel: https://www.computerbase.de/forum/t...te-control-center-fuer-rgb-steuerung.2121046/

seriös ist anderst ;-)

 

[User 886784]

bei mir kommen nur noch flatpaks ins haus. alles läuft damit besser. sicher sind sie auch und immer up to date. da kann das system noch so veraltet sein und rumspacken. der flatpak läuft und läuft.

keine ahnung warum so viele flatpaks so verteufeln. viele linux user sind halt oft gewohnheitsmenschen, die nicht viel veränderung wollen sondern eher auf sicherheit und produktivität setzen selbst wenn die versionen schon lange outdated sind. aber auch das wird sich wandeln.

 

[Krakadil]

keine ahnung warum so viele flatpaks so verteufeln. viele linux user sind halt oft gewohnheitsmenschen, die nicht viel veränderung wollen sondern eher auf sicherheit und produktivität setzen selbst wenn die versionen schon lange outdated sind.

Flatpaks laufen mega aber du musst schon ein wenig lesen, dann stellen sich die ganzen Fragen nicht.

Sag das mal den Arch Usern 🤣

 

[gio127]

Sag das mal den Arch Usern 🤣

Gerade was Arch angeht, ist das Gesagte ja schon ein Widerspruch, denn

viele linux user sind halt oft gewohnheitsmenschen, die nicht viel veränderung wollen sondern eher auf sicherheit und produktivität setzen selbst wenn die versionen schon lange outdated sind

das trifft ja dann eher auf diejenigen zu, die flatpaks benutzen.

Die Flatpak-Version von Dropbox, die ich auf Fedora nutze, ist z.B. älter (outdated) als die Version die ich auf Artix(Arch) aus dem AUR benutze.

Darum sagt mir die obige Aussage auch absolut nichts. Das trifft auf fast jeden Menschen und jeden Bereich zu. Kommt nur auf die Perspektive an.

 

[User 886784]

Flatpaks sind so gut wie immer up to date und werden auch schneller geupdated. Warum das jetzt bei Dropbox nicht so ist weiß ich nicht. Ist aber ungewöhnlich, da Dropbox sicherlich den Flatpak für ihre eigene Software bereitstellt. Wundert mich also, dass Arch schon eine frühere Version hat. Entweder ist das eine Beta oder da ist etwas gewaltig faul!