target OS is debian or linux mint
You must log in or register to comment.
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
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-dlpin 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
masteror with a few patches, all you really need to do is clone it fromflathub/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.
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
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=homeor--socket=pulseaudioand 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
homeby 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.
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/globalwould 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
It matters as the security rating is based on that, apps like KDE Systemsettings or Flatseal show that etc.
That’s a good point.
Linux has a tiny marketshare people dont care about security that much permissions on Linux are more complex than on the actively restricted Android. External media, devices, filesystems etc
That’s true.
I think my issue with the Flatpak sandbox is I understand how it works and what its limitations are (and I’m mostly fine with them), but the average user doesn’t. I was reluctant to try Flatpak before understanding how it worked, but now that I know how it works, I think it’s fantastic! But it’s also a work-in-progress. What we have now is good, but I think it could be better. Not entirely sure how it gets better though.
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.
I’m still not really sure where I stand on Fedora Atomic. Lack of H.264 decoding by default is a damaging choice. They should just include openH264 in the base image, reproducibility be damned. Give it 5 more years and maybe this will be revisited…
Nova + Zink + NVK will solve some of the problem with NVIDIA (maybe even very soon), but not hardware decoding currently, which is a big one.
Gamescope doesn’t work great in a Toolbox. It works fine in Flatpak, but Bottles doesn’t let me use Gamescope options. I think Lutris does, but I haven’t tried it out yet.
And how am I supposed to install fonts without layering them on?? I’ve been copying them to
~/.local/share/fontsmanually.I think the idea is cool. But I think a few more parts of the ecosystem need to be in place first. I’ll keep using it for now.
What we have now is good, but I think it could be better.
I maintain a list of recommended Flatpak apps.
I had a damn Librewolf crash some time ago, the RPM is broken, switched back to Firefox… so I lost about 3 hours of overhaul of that list as it is currently very messy.
But if it is fixed, feel free to submit apps to be included, to have a “goodness enumerating” list of apps, rather than a huge mess of random apps.
Lack of H.264 decoding by default
They dont include that? I thought they would…
I use Fedora kinoite-main from uBlue which is very close to upstream but fixes many issues for me.
UBlue focussing on their very opinionated variants is a bit annoying, because it is now pretty hard to find a guide how to install kinoite-main. I just have a bookmark of their archived website.
Give it 5 more years
If this is actually an issue I would like to tackle that. I am currently doing a Change Proposal to make the default rpm-ostree permissions reasonably secure.
So this is an issue with reproducability? I dont think so? Cisco builds the binaries for Fedora and it gets installed. The packages are not from their repos, but the typical sync issues would not occur on Atomic.
but not hardware decoding currently, which is a big one
Yeah for sure, I think for Intel and AMD too, hardware h264 for example. AV1 in OBS will be awesome though.
But thats why I use uBlues base images, it is Fedora and I say I use Fedora and participate in their community, but their base images have a ton of stuff I dont agree with (toolbox, missing random packages, too simplistic installer…)
I maintain a list of recommended Flatpak apps.
I’m very familiar with you, haha. You keep popping up wherever I go these days. You’re everywhere. Maybe not quite as omnipresent as Neal Gompa.
I can think of a few Flatpaks that could fit on that list.
They dont include that? I thought they would…
It’s the same old story with codecs. Fedora would love to support as many codecs as possible, but H.264 is patent-encumbered so they can’t. They had hardware decoding support through Mesa a few years ago but then they…changed it.
Fedora Atomic wants to include the OpenH264 enablement package for Firefox inside the Fedora Flatpak eventually which will solve most of the problem as that is where people are playing H.264 most often.
So this is an issue with reproducability? I dont think so? Cisco builds the binaries for Fedora and it gets installed. The packages are not from their repos, but the typical sync issues would not occur on Atomic.
My understanding is OpenH264 is provided in binary-only format to Fedora because otherwise the royalty-free license cannot apply (i.e. Fedora can’t build it from source). Fedora only ships free software. OpenH264 is free software. But it’s binary-only. So they need to trust Cisco has built the binary correctly. I assume the reason they don’t include it by default is because the only way to trust it’s built from the same sources is to reproduce the build. Otherwise, I really don’t see the issue.
OpenH264 is not a part of the base system so you need to layer it on. OpenH264 doesn’t have support for High 10 Profile video which is fairly common off the web and is generally inferior to x264, I’ve found, but at least it’s something.
And the reason I mention “5 years” is because by then, most of the patents on H.264 will have expired. With the exception of the new ones from just a few years ago that no one really uses. Maybe Fedora can enable x264 in their ffmpeg build then and we can stop talking about it. I am so sick of talking about H.264.
I use Fedora kinoite-main from uBlue which is very close to upstream but fixes many issues for me.
Call it a personal challenge or whatever but I’m sticking to Fedora Silverblue for the foreseeable future. uBlue is almost certainly a better experience for most people.
Yeah for sure, I think for Intel and AMD too, hardware h264 for example.
That’s not true if you’re using Flathub packages. Flathub ships userspace Mesa drivers which enable hardware decoding for Intel and AMD GPUs even with H.264 and H.265.
but their base images have a ton of stuff I dont agree with (toolbox, missing random packages, too simplistic installer…)
uBlue does solve the two big issues with Fedora, which is codecs and proprietary NVIDIA drivers. Any other issues are tiny in comparison. I will say I prefer Toolbox to Distrobox, despite using Distrobox first. I certainly understand that’s an unpopular opinion and not one a lot of people share. It’s probably the same reason you use KDE and I use GNOME (most of the time).
I’ve always hated the Fedora installer. Does uBlue do something different?
- You can easily rollback Flatpaks to a previous version (even from a long time ago) with
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
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.
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.
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.
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.
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.
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.
4.79 GiBwith deduplication.Worth mentioning that my entire distro with those applications included, and about 30 appimages is
4.2 GIBtotal, and that includes the home btw.
Things installed by apt almost always work as expected and are easily run from the cli.
Flatpaks are sometimes more up to date.
