what are the pros and cons of apt vs flatpak? : linux

[–] [email protected] 58 points 4 months ago (2 children)

Pro apt:

storage efficient
may be optimized for stuff like x86_64 v3 or v4
runs as many users and easily from terminal
needed for some low level stuff like system packages

Contra apt:

a ton of stuff comes from outside the main Ubuntu repo. Debian doesnt have that difference afaik but still many packages may be more abandoned
3rd party packaging 99% of the time, i.e. "unverified". I had a lot of strange bugs especially with Ubuntu packages
the apps ars not isolated at all

Pro Flatpak

a ton of verified apps, nearly unavailable on other repos (that still doesnt make unverified apps insecure!)
all apps have a sandbox that can be graphically hardened to be more secure, if the defaults are too broad
by defaults the sandbox is pretty good
many many apps that run everywhere

Contra Flatpak

not suited for some apps like terminal apps or system stuff
some apps are less maintained and use EOL runtimes etc
some more storage space needed
need user namespaces, nearly all distros have them enabled
a bit slower startup time but okay
a bit more RAM usage

[–] [email protected] 9 points 4 months ago* (last edited 4 months ago) (1 children)

In general I agree, though had something to add regarding these points:

by defaults the sandbox is pretty good

This is a rather major problem with Flatpak; the maintainer decides what permissions they need by default, not the user. The user needs to retroactively roll them back or specify global options and manually override them per-app, but that's not user-friendly at all. Though many Flatpaks do have good permissions because Flathub maintainers step in and offer suggestions before approving the Flatpak for publication, there are a number of Flatpaks that punch big holes in the sandbox; so much so that they might as well be unsandboxed.

But Bottles has a great sandbox, for instance, which is just what you'd want when running lots of proprietary Windows applications you maybe don't trust as much as your Linux-y software.

It's better than what we have with traditional packages but it can sometimes get in the way and not all beginners can easily figure out how to fix permissions issues with Flatseal. This will probably improve as we get more portals built.

some apps are less maintained and use EOL runtimes etc

Not much is different for distribution-maintained packages, either. See TheEvilSkeleton's post about how there are over 1200 unmaintained packages in the Debian repositories, and even over 400 in Arch's much smaller repositories that are outdated (!). At least Flathub applications are usually maintained by upstream, and so are usually as up to date as they can be.

not suited for some apps like terminal apps or system stuff

This isn't really true. It's only true when terminal applications need privileged access to something. Flathub ships Mesa userpace drivers and NVIDIA's proprietary userspace drivers just fine. You can package something like yt-dlp in Flatpak just fine with --filesystem=host. Hell, they've even got Neovim on Flathub. Sure, it's a little more cumbersome to type, but you can always create an alias.

Flatpak is not suitable for all graphical applications, either. Wireshark's full feature-set cannot be supported, for example.

I would add that:

You can easily rollback Flatpaks to a previous version (even from a long time ago) with flatpak update --commit. Much harder with traditional package systems, and you'll probably need to downgrade shared libraries too.
You get a consistent build environment with Flatpak manifests. If you want to build a newer version of a stable package you're using straight from master or with a few patches, all you really need to do is clone it from flathub/whatever, change a few lines, and it has a very high chance of building properly. No need to figure out dependencies, toolchains, or sane build options. And it's all controlled from an easy-to-read and modify file.

[–] [email protected] 2 points 4 months ago (1 children)

defaults

The default is completely sandboxed. Developers need to allowlist exactly what they want. So it is transparent.

Compare that to a random app where you need to monitor its syscalls to see what it does.

KDE Plasma now includes a GUI settings page that allows to change these.

I think GNOME needs to integrate that into their settings, I mean just include damn Flatseal as a settings page...

specify global options

This is supercool and I started doing that. All apps get the env vars to force Wayland now even though they may not use it. I have my overrides and uploaded them to my dotfiles.

But Bottles has a great sandbox

Echo that

over 1200 unmaintained packages in the Debian repositories, and even over 400 in Arch's much smaller repositories

This is crazy, same on Fedora. Distros really need to start using separate repos, and automatically filter out everything that didnt get a "I maintain this" for a while.

There are packagers maintaining a shitload of apps at once.

Flathub applications are usually maintained by upstream

Not always but having this at all, and having most big names in there, is incredible. This is like a first time this happens.

easily rollback Flatpaks

Ostree is great

consistent build environment

And having it declared centrally can help add all the security benefits of the individual ones too. Really nice

[–] [email protected] 2 points 4 months ago (1 children)

The default is completely sandboxed. Developers need to allowlist exactly what they want. So it is transparent.

The default before the developer touches it doesn't matter; compare this to Android, iOS, or macOS's permission system. An app needs to ask for permission to use the microphone or access your files. With Flatpak, all a developer needs to do is specify --filesystem=home or --socket=pulseaudio and if the user hasn't specified global options like --nofilesystem=home, then the developer gets access to it. Having a sandbox that is optional for the developer rather goes against the point of a sandbox, don't you think?

I'm not unsympathetic to Flatpak developers, though. The status quo on Linux for decades has been, "you get access to everything." If Flatpak enforced that sandbox, more than half of the apps on Flathub right now just wouldn't work because they don't support the filesystem portal.

I think GNOME and KDE need to do the work of manually restricting Flatpak apps' access to sensitive permissions like home by default, maybe in a few years when the idea of the filesystem portal has had time to gestate among developers. Kind of like how Firefox's HTTPS-only mode (which I think should be the default) prevents you from accessing the website unless you give permission.

That's something we can work on, I think. At least we have a way to get there.

KDE Plasma now includes a GUI settings page that allows to change these.

I think GNOME needs to integrate that into their settings, I mean just include damn Flatseal as a settings page…

I recall saying the exact same thing. They have a built-in area for it in the Apps section. They'll probably get around to it eventually...

There are packagers maintaining a shitload of apps at once.

It's pretty crazy. I think this is probably the craziest example: https://old.reddit.com/r/archlinux/comments/f3wrez/much_love_to_felix_yan_an_arch_maintainer_from/

Felix Yan is awesome to be maintaining thousands of packages for Arch. But man, that's a lot of work. If we could reduce the workload of our package maintainers who rarely receive any gratitude (usually only demands) and let them focus on the really important packages, I think that would also be awesome.

[–] [email protected] 2 points 4 months ago (10 children)

Yay my answer was deleted...

before the developer touches it doesn't matter

It matters as the security rating is based on that, apps like KDE Systemsettings or Flatseal show that etc.

I agree that asking for permissions is better.

Placing an override in ~/.local/share/flatpak/overrides/global would be an easy workaround.

Desktops could implement dialogs that use the currently preset permissions.

Having a sandbox that is optional for the developer rather goes against the point of a sandbox, don't you think?

No, these are defined, enumerated holes in a sandbox. Without a sandbox you need to monitor the behaviour yourself or other things.

This is the only good working GUI sandbox I know.

half of the apps on Flathub right now just wouldn't work because they don't support the filesystem portal.

Important point here:

the portal should allow static permissions too
apps that dont support portals would also not support asking for permissions, natively. A workaround could be done, using dbus, and asking for everything when the app is launched first time, BUT
Linux has a tiny marketshare
flatpaks are not the only ones
people dont care about security that much (look at my survey, I will post an evaluation soon)
permissions on Linux are more complex than on the actively restricted Android. External media, devices, filesystems etc

HTTPS-only mode (which I think should be the default)

I should open a bug about this. It cant be that this is not default, it works well and I agree on the style of implementation.

But this would also need apps to have that mechanism. A Libreoffice will just say "file doesnt exist" currently.

let them focus on the really important packages

Thats why I like Fedora Atomic. The core is as small as possible, the apps are just base stuff or upstream stuff like the Desktop. Everything else is a Flatpak.

It is so much more secure.

RHEL / CentOS has different repos for core and extras. More distros will do that

load more comments (10 replies)

[–] [email protected] 2 points 4 months ago (2 children)

I like flatpak as it helps me keep bloat down. I always find that native packages eventually pollute the system. Flatpaks do somewhat as well but I can manually delete the app storage if necessary

[–] [email protected] 8 points 4 months ago (1 children)

I like flatpak as it helps me keep bloat down

Impossible. Like flatpak itself with 5 applications was using more storage than my entire distro with the same apps as appimages on top.

[–] [email protected] 3 points 4 months ago (5 children)

I can't say I have the same experience. Flatpaks keep everything tidy and most GUI stores offer the option to delete app data on uninstall

load more comments (5 replies)

[–] [email protected] 2 points 4 months ago

True, especially the dotfiles. Having them separated in individual per-app directories is awesome

[–] [email protected] 18 points 4 months ago

Things installed by apt almost always work as expected and are easily run from the cli.

Flatpaks are sometimes more up to date.

[–] [email protected] 15 points 4 months ago* (last edited 4 months ago) (3 children)

One thing that hasn't been mentioned yet is interopability, that is, flatpak interacting with the rest of your system.

I'm not that familair with flatpak, but in my brief experience with the steam flatpak, I had trouble getting it to recognize my controllers. Steam installed through pacman (Arch's package manager) had no such issues, on the other hand. My hunch is that this has to with flatpaks being more isolated from the rest of your system.

Im pretty sure that's just some kind of permission issue, but it can be nice to not have to troubleshoot acces rights and the like. But this is obviously a double edged sword: more isolation may also mean more security, just at the cost of ease of interaction with other components.

[–] [email protected] 12 points 4 months ago

The steam flatpak can't install udev rules. It works if you install a packacke such as steam-devices on your host system. See https://github.com/flathub/com.valvesoftware.Steam/wiki#my-controller-isnt-being-detected

[–] [email protected] 4 points 4 months ago

The good news is that flatpak and XDG portals are progressing

[–] [email protected] 2 points 4 months ago* (last edited 4 months ago) (1 children)

Yeah, both have pros and cons. I have Steam installed through pacman and flatpak also. For me I have the Flatpak version because it contains its own version of glibc. This mostly doesn't matter, except I play Squad and it's doing something with it's anti-cheat that isn't supported in the most recent versions of glibc, so I use the Flatpak version for Squad only.

Flatpak is essentially a more controlled environment. It will contain everything it needs to work, which is good for ensuring it works but bad because you'll have duplicates. It mostly doesn't matter which you use, but occasionally it does.

[–] [email protected] 2 points 4 months ago

This issue with glibc should have been sorted out. But yeah, if you use arch you may have some issues from time to time cause some projects broke their ABIs sometimes, but I prefer to use the one with pacman cause I only have to update my entire system with one command, also theming is an issue with flatpak that I know there is solutions out there but AFAIK are always adhoc solutions for each app.

Also, IIRC steam folder is always in a weird place using flatpak.

[–] [email protected] 14 points 4 months ago (1 children)

flatpaks are designed for gui apps, and due to packaging dependencies, they are extra heavy in disk space. flatpaks are also most often installed on the user, not systemwide, so no root permissions needed to install.

apt installs systemwide exclusively, but can have a much smaller download size if the dependencies are already installed. Apps sharing dependencies means much less disk space. cli is supported.

[–] [email protected] 4 points 4 months ago (1 children)

they are extra heavy in disk space

While they use more disk space than most native packages, this point is often exaggerated. Flatpak uses deduplication and shared runtimes if multiple apps use the same runtime.

[–] [email protected] 2 points 4 months ago (1 children)

While they use more disk space than most native packages, this point is often exaggerated. Flatpak uses deduplication and shared runtimes if multiple apps use the same runtime.

mmmmm

4.79 GiB with deduplication.

Worth mentioning that my entire distro with those applications included, and about 30 appimages is 4.2 GIB total, and that includes the home btw.

[–] [email protected] 2 points 4 months ago* (last edited 4 months ago) (3 children)

Appimages don't use any deduplication at all and usually package everything in the app.

Sometimes they don't do that though and expect your system to have certain packages, but that can and does cause reliability and portability issues.

E: portability not probability lol

load more comments (3 replies)

[–] [email protected] 13 points 4 months ago (1 children)

What's up with all the negativity around flatpaks? I use Arch (btw) and I try to install as much as I can using flatpak. I think they are great. They are compatible, usually up to date, easy to install, easy to remove and it won't break your system. The sandbox can be edited to include more paths etc.

[–] [email protected] 2 points 4 months ago

If I developed a Linux app I would absolutely package it as a flatpak. If a package is in pacman, however, I see no reason to use the flatpak version instead.

[–] [email protected] 10 points 4 months ago (2 children)

Flatpaks won't get their libs updated all at once by just updating a library. This can be very bad in cases like bugs in openssl. Instead of just updating one library and all other software benefiting from the fix, with flatpaks, you need to deal with updating everything manually and waiting for the vendor to actually create an update package.

I'm not 100% sure about this. Flatpak has some mechanisms that would allow to manage dependencies in a common fashion.

[–] [email protected] 7 points 4 months ago (3 children)

Most Flatpaks depend on the Freedesktop Platform runtime, or GNOME/KDE runtimes, which are derived from it. This contains several hundred common dependencies and librarires programs need, like gcc and python. When you update the runtime (change it from 22.08 to 23.08 in the manifest), all the dependencies are updated too. Many simple applications don't depend on many more dependencies than are available in the runtime. Some...have more complicated dependency trees.

But counterpoint: the developer will update the dependencies when they are known to work properly with the application. Upgrading GTK3 to GTK4 in the GIMP flatpak will just break the application. Same thing with Krita and the dozens of patches to libraries it depends on. If you upgrade the application in the name of security before it's compatible, all you end up with is a broken application. Which I guess is more secure, but that's not helpful to anyone.

[–] [email protected] 2 points 4 months ago

Thanks for the interesting point! I learned something today. I guess it all depends on your use-case, whether flatpaks make sense or not.

[–] [email protected] 2 points 4 months ago (2 children)

Which means that if you have a flatpak with an uncommon library and the dev stops issuing updated flatpaks because they get hit by a bus, you could be SOL with respect to that library. Distro libs are less likely to have this happen because very few distros have a bus factor of 1—there's usually someone who can take over.

[–] bitfucker 1 points 4 months ago

TIL about bus factor

[–] [email protected] 1 points 4 months ago

if you have a flatpak with an uncommon library

In this case, you're responsible for packaging it yourself. This usually means specifying the git URL and build options in the manifest. You can see Krita doing this in their manifest because they don't depend on the KDE Platform, as they need much older dependencies. So they're responsible for over 1000 lines worth of dependencies.

The Freedesktop Platform is essentially a distribution unto itself, and I don't think there's ever been a case of dependencies in that distribution not being kept up-to-date.

Distro libs are less likely to have this happen because very few distros have a bus factor of 1—there’s usually someone who can take over.

Well...debatable. There were over 1200 orphaned packages in Debian last year, many of which had not been maintained in over 3 years.

[–] [email protected] 1 points 4 months ago (1 children)

I wonder how much work would be needed to make a "FreeDesktop Linux" complete OS, with the runtime + whatever it needs beyond that. Then when you install a flatpak, it's just like installing, uh, I didn't think this through tbh.

[–] [email protected] 3 points 4 months ago

Well, if you think about it, the Freedesktop Platform is essentially a distribution. And Flatpak used to be called "xdg-app". If you've got all your graphical applications installed via Flatpak, with GNOME, Systemd, glibc, GRUB and all the core dependencies only packaged for the base system (essentially Arch's core repository), that's pretty much a Freedesktop OS.

Hey, maybe we could use Snaps for the base system and Flatpaks for the userland? Or are these the kinds of ideas that get people stoned?

[–] [email protected] 4 points 4 months ago

Common libraries like OpenSSL are usually bundled in runtimes. So if my application uses e.g. org.gnome.Platform, I don't have to update my application if there is a fix in a library of that runtime, I just need to update the runtime.

The runtime is also shared by all applications that use this runtime.

[–] [email protected] 10 points 4 months ago

Lots, LOTS, TL;DR - flatpaks are sandboxed and work on every* distro out there, while apt packages are not and only work on debian and it's derivatives. I'd say on mint or debian, prefer using flatpaks over apt packages as you're usually gonna get newer versions of software.

[–] [email protected] 9 points 4 months ago

In addition to other people's comments, flatpaks are usually more up to date than their apt counterpart (expecially those from the debian stable repositories).
I run debian and I deliberately installed some software from flatpak (eg. Ardour and Guitarix) because the deb package is a whole version behind.

[–] [email protected] 6 points 4 months ago

Flatpak's benefits mostly exist for the developer. Apt is more tightly integrated with the distro, which is generally advantageous, but also means more work for packaging. Flatpak's benefit is that it's a compatibility layer for lots of different distros. In a perfect world, every distro would have a large library of packages in the official repo, but that's a lot of work for devs, and flatpak lets them avoid that sprawling support.

[–] [email protected] 5 points 4 months ago (2 children)

Flatpaks require more storage space as all dependencies are combined in a flatpak. For me rather 2nd choice.

[–] [email protected] 14 points 4 months ago (1 children)

FYI: Flatpaks can share some dependencies and duplicate files.

[–] [email protected] 1 points 4 months ago (1 children)

They still use way more storage.

My entire distro + home + 30 appimages (which includes the equivalent flatpak applications as appimage) is 4.2 GiB

[–] [email protected] 3 points 4 months ago (1 children)

You don't have many Flatpaks installed, but you happened to install applications that depend on three different runtimes (Freedesktop, GNOME, KDE), which is where a lot of the weight is coming from. Install 20 more Flatpaks and see what happens.

[–] [email protected] 1 points 4 months ago (1 children)

Will still be using 4.79 GiB?

I will do this later anyway, but I reallly really doubt it is going to get any better, like it is already once again using more storage than an entire distro with 30 appimages + home.

[–] [email protected] 2 points 4 months ago (3 children)

Will still be using 4.79 GiB?

It will use more, but not exponentially more if de-duplication works as well as is claimed. The problem with AppImages is that they don't include all of the dependencies, making them less reliable. At the expense of storage space, Flatpak bundles everything for reliability.

De-duplication works better the more Flatpak applications you have installed. e.g. de-duplication saves TheEvilSkeleton over 50GB of storage space here: https://tesk.page/2023/06/04/response-to-developers-are-lazy-thus-flatpak/#but-flatpaks-are-easier-for-end-users

load more comments (3 replies)

[–] [email protected] 3 points 4 months ago

It isn't bad if you have a bunch of flatapaks as they share dependencies. For install the first install might be huge but the second app that also uses the same framework will be much smaller

[–] [email protected] 3 points 4 months ago (1 children)

I'm using MX, debian based, apt package, I have 0 flatpak/snap. They are up to date on about everything, like the latest Firefox I got this morning in a simple .deb that nala (apt frontend) installed without problems.

I never ever installed a snap/flat in my Linux years.

[–] [email protected] 2 points 4 months ago

Honestly you should (flatpak that is)

Flatpaks are nice and provide isolation so installed apps do not add bloat to the core system.

Linux

Rules

Related Communities