LWN: Comments on "No more Flatpak (by default) in Ubuntu Flavors"

No more Flatpak (by default) in Ubuntu Flavors

Klavs — Thu, 20 Apr 2023 11:51:12 +0000

Netflix works just fine on chromium in Ubuntu.

No more Flatpak (by default) in Ubuntu Flavors

ssokolow — Wed, 08 Mar 2023 09:47:44 +0000

It's not as bad as it looks. Lines 75 through 102, 112 through 115, and 253 to 280 are just a workaround for how so many Flatpak maintainers wind up naming the launchers/wrappers inside the container differently from the commands installed by the distro packages and may even use a generic name like "wrapper.sh". If they were instructed otherwise in the packaging guide, that'd be almost a fifth of the file made unnecessary.

Lines 154 through 173 and 283 through 328 began as a line or two of shell script that I rewrote in Python so I could massively improve performance by not forking a separate flatpak info -m subprocess for each package... so another near fifth is just boilerplate for "doing it properly" in a Python script that connects up to libflatpak rather than being a quick and dirty shell hack. (And some of it is reporting detected naming collisions or misconfigurations of the PATH.)

Lines 105 through 109 are an unfinished workaround for Flatpak not providing a way to expose multiple commands in the manifest metadata and, even if they did, mednaffe's maintainer probably not bothering to expose the bundled copy of mednafen. (I still need to come up with a proper implementation to match Flatpak-installed .desktop files to packages to identify which ones need CLI wrappers created for them.

Lines 117 through 147 amd 214 through 250 are just an improved reimplementation of the code Flatpak already has for generating reverse-DNS command-line launch wrappers. (This script began as a middle finger to such a Tab-completion-hostile solution.) Lines 188 through 211 are a workaround for the manifest not saying whether the command in the command field expects paths or URLs as arguments.

No more Flatpak (by default) in Ubuntu Flavors

calumapplepie — Tue, 07 Mar 2023 11:38:31 +0000

Anything requiring DRM will not work on Debian's Chromium package, but will on the Firefox package. That includes all the subscription streaming sites (Spotify, Netflix, etc, etc).

No more Flatpak (by default) in Ubuntu Flavors

mbunkus — Mon, 06 Mar 2023 15:43:19 +0000

That's quite impressive and scary at the same time :) Thanks for sharing! Goes to show how unsuitable Flatpaks are for CLI applications.

No more Flatpak (by default) in Ubuntu Flavors

ssokolow — Mon, 06 Mar 2023 13:57:13 +0000

And, in a depressingly typical Linux move, I've hacked up a workaround.

No more Flatpak (by default) in Ubuntu Flavors

jdulaney — Fri, 03 Mar 2023 20:10:18 +0000

Well, that probably comes from Ubuntu's packaging is generally rather poor in quality.

No more Flatpak (by default) in Ubuntu Flavors

davidgerard — Thu, 02 Mar 2023 10:52:16 +0000

Sure would be nice if the Firefox and Chromium snaps hadn't forgotten how to see system fonts and my browser wasn't a sea of Unicode place holders.

No more Flatpak (by default) in Ubuntu Flavors

mrkernel — Tue, 28 Feb 2023 20:25:42 +0000

Name a single website that works in Chrome but not Chromium. Extensions or plugins don't count.

No more Flatpak (by default) in Ubuntu Flavors

ScottMinster — Tue, 28 Feb 2023 18:09:09 +0000

The vertical tabs on Edge still aren't as good as Tree Style Tabs in Firefox. But I am glad that at least one other browser vendor is giving an option for vertical tabs.

No more Flatpak (by default) in Ubuntu Flavors

jmalcolm — Sat, 25 Feb 2023 06:12:18 +0000

I have been thankful for Edge on Linux actually. My main browser is Firefox on Linux ( typing in that now ) but I use Edge on Linux fairly often. For one thing, it plays much better with a different video conferencing apps I need to use.

Personally I consider Google and Chrome a bigger issue than Microsoft these days. Other may not think that moving from Google to Microsoft product is much of an improvement but I have not used Chrome in years and want to keep it that way.

It is the same engine. I get that. As I said, my main browser is Firefox. The main reason for that though is that I use older hardware ( lowish amounts of RAM ) and I am terrible with tabs ( God knows how many I have open ) and Firefox just does better with that.

Snap refresh behaviour is really strange.

himi — Fri, 24 Feb 2023 21:27:39 +0000

Thanks for the detailed discussion of Flatpak's approach - it's pretty much what I just assumed snap would be doing, because frankly it's how I'd have done it if I was writing a container-based package delivery system . . .

The usability/user-interaction question obviously has no clearly superior answer, and arguably would have different answers for different use cases (server versus desktop, system software versus end user, developer versus regular user, etc), but I think it's pretty hard to argue with implementing support for a "minimum downtime" approach that does as much as possible of the time consuming download and update in the background before requiring the running process to go away. Snap is definitely failing at that right now, for unknown reasons.

Snap refresh behaviour is really strange.

farnz — Fri, 24 Feb 2023 16:15:05 +0000

The reason I said "in theory" is that I've not tested Flatpak's behaviour. Snap currently requires you to close the app to update it - it won't download and install a newer version in parallel to the old version, and thus you have to quit your app, apply the update, and then restart.

I'm glad to hear that Flatpak does the right thing here - as a user, I want to be able to say "sure, get all the updates and install them" while I'm on mains power and reliable fast Internet, but I may not be able to restart the app to get the new version running until I've finished a chunk of work (which I may, in turn, not be able to do until I'm on a coach or train journey). The only thing you've not cleared up for me is whether it's easy, in the Flatpak world, to determine which apps I need to restart to update - it's obviously technically possible based on your description, but whether any of the front ends tell me "hey, you have Firefox 109 running, but the currently active version is 114.3 - restart Firefox to update" is a different question,

Snap refresh behaviour is really strange.

smcv — Fri, 24 Feb 2023 16:09:31 +0000

Flatpak does work like this, and it's one of the motivations for it using libostree (which sets up hardlink-based immutable directory trees). Once an instance of a Flatpak app is running, its view of the app and runtime files in /app and /usr will never change even if the app or its runtime gets updated, ensuring that the app doesn't get broken by its resource files being swapped out underneath it (unlike system package managers like dpkg or rpm, which would traditionally just go ahead with changing the files in-place and hope the app can cope, but now often encourage doing "offline updates" during a reboot).

If you update a Flatpak app or runtime while the app is *not* running, then the old version will be cleaned up immediately (in the case of a runtime, this only happens if there is no running app that uses that runtime). If an instance of the app is running, it holds a lock which prevents that cleanup, but the "active" version swaps to the new one, so running another instance of the same app in parallel will give the new instance its updated /app and /usr. The old version will eventually be cleaned up, during the next update that takes place after the first instance has exited.

I don't know whether Snap does this. I would hope so, it's certainly in a position to use similar tricks if it wants to?

Of course, for particularly security-sensitive apps like Firefox, there's an incentive for the app to prompt you to exit and restart even if it's somewhat disruptive to do so, to make sure you're really running the updated version with its security fixes: there's a usability/security tradeoff here, and we can't realistically insert code changes into a running process, however important they might be.

No more Flatpak (by default) in Ubuntu Flavors

smcv — Fri, 24 Feb 2023 15:35:49 +0000

Indeed, certainly not ideal for Ubuntu users. I'm not an Ubuntu developer or user, so all I can do is make Flatpak as well-supported as possible in its parent distribution Debian, and let Ubuntu developers choose whether they want to benefit from that.

(Actually, that's not quite all I can do: I'm also periodically updating Flatpak's semi-official PPA for Ubuntu. But as not-an-Ubuntu-user with various other responsibilities, I'm really not the best person to be doing that, so it would be great if someone closer to Ubuntu could help.)

In Debian, GNOME Software and Plasma Discover are installed by default by their respective desktop environments, and both have optional plugins/backends for Flatpak and Snap. GNOME Software has a Suggests (weak dependency) on its Flatpak and Snap plugins, while Plasma Discover only has a Suggests on its Flatpak backend (it does have a Snap backend, but presumably its maintainers are less happy with the maturity of that one or some similar factor).

Because these "app store" apps handle both apt and Flatpak/Snap packages, they would also be well-placed to install their own Flatpak and Snap backends via apt on a just-in-time basis when asked to install a .flatpakref file or a Snap equivalent, but I don't know whether they implement that.

Ever since Debian 11 switched to enabling unprivileged user namespaces by default, Flatpak's sandboxing in Debian has been as good as it is in any other distribution. As far as I know, Snap's sandboxing partially relies on AppArmor, making it incomplete in all non-Ubuntu-derived distributions: Debian is closer than most, because Debian at least uses AppArmor by default, but Debian's kernel doesn't have various extra AppArmor features which are specific to Ubuntu kernels and were never integrated upstream, notably control over access to AF_UNIX sockets.

No more Flatpak (by default) in Ubuntu Flavors

mbunkus — Fri, 24 Feb 2023 15:18:26 +0000

This topic was raised with the flatpak developers, I think even several times. If I remember correctly they explicitly stated that flatpaks are for GUI apps and that this won't change. This is the thread/issue to read to get all your hopes dashed: https://github.com/flatpak/flatpak/issues/1188

I'm not holding my breath for anything to change here.

Which makes me very, very sad as an application developer. There are now three cross-distro packaging formats, and all have severe limitations that they simply aren't willing to overcome! It seems not one of them wants to be _the_ universal, cross-platform, secure, easy-to-use (for the end user) format out there. They simply… don't want to be that. I guess I can respect an intentionally limited scope, but they had a real chance here and didn't take it. Now we're stuck with a solution that's barely good enough for barely most UI situations (flatpak) and that's available on mostly all UI environments/distros, and therefore people will have no more incentive to work on something better. We'll be stuck with this now for the next 20 years.

No more Flatpak (by default) in Ubuntu Flavors

hei8483j — Fri, 24 Feb 2023 15:09:52 +0000

Yes, I agree that it isn't optimal. Hopefully it will improve. Maybe flatpak isn't the format that will persist in the end, but we need some kind of solution for more portable applications and it is a good attempt.

No more Flatpak (by default) in Ubuntu Flavors

mbunkus — Fri, 24 Feb 2023 15:04:03 +0000

Sure, but if your users are used to running things as "amazingprogram --foo --bar /path/to/baz" and having shell completion and you have tell them to run "flatpak --command=amazingprogram com.thesuperduperdeveloper.amazingprogram --foo --bar /path/to/baz" instead now, without shell completion, then this is not a solution. It's a workaround at best, and not a good one.

flatpak is simply not aimed at and not suitable for CLI programs. And that's a crying shame.

For AppImages the situation is slightly different, though not really better: you can symlink an AppImage file to e.g. "amazingprogram". Then have your entrypoint application inside the AppImage call different programs depending on argv[0].

That's the one thing that snap does better: it allows for more than one binary in snaps & it can add those binaries (or wrappers to the correct snap invocation) to the usual paths.

No more Flatpak (by default) in Ubuntu Flavors

callegar — Fri, 24 Feb 2023 14:08:51 +0000

I find it a bit ironic that the "way to improve the user experience" might shortly involve having each distro pick its own "universal" package format or slight variation thereof, install only that by default and trying to make it just that little bit cumbersome to use anything else. I understand that Suse, Arch and Gentoo are not in this game, but given sufficient motivation they might want to catch up ;-).

Also must say that as a kubuntu user, if I have to rely on self-contained applications, I find snap rather nasty and I tend to prefer other "fat" package formats. The fact that you cannot allow snaps to access anything that is yours but is mounted out of your home (there is no way to declare it, paths are hardwired in the code) is annoying and their suggestion that this is no issue because you can manually bind mount to your home or write a custom systemd unit for that shows a strange interpretation of user friendliness...

No more Flatpak (by default) in Ubuntu Flavors

hei8483j — Fri, 24 Feb 2023 12:59:57 +0000

It's possible to include and run command line programs in a flatpak just fine. E.g. if the command line application is named "mycommandlineapp", you can run it with "flatpak run --command=mycommandlineapp <name of flatpak>".

Snap refresh behaviour is really strange.

farnz — Fri, 24 Feb 2023 10:19:40 +0000

In theory, at least, container-based systems like Snap and Flatpak can download an update as a new container, and not remove the old version until the last instance of it has closed. This would be the best of both worlds - background update download as soon as the update is available, and only apply the update when you're ready to restart.

No more Flatpak (by default) in Ubuntu Flavors

smcv — Fri, 24 Feb 2023 10:03:59 +0000

The Chromium family aren't really WebKit-based any more: they use Blink, which has diverged from its WebKit ancestor. The big web browser engine families are now Blink (Chromium, Chrome, CEF, Electron, Edge, etc.), WebKit (Apple Safari, GNOME Web, many embedded devices) and Gecko (Firefox).

Snap refresh behaviour is really strange.

madhatter — Fri, 24 Feb 2023 09:39:45 +0000

But with the apt/yum/dnf version, apt/yum/dnf will tell you that there's an update of firefox pending, which you are free to ignore if you want. You only get the "firefox has been updated, to continue you must restart" message *after* you've installed the update. I accept that you may have automatic apt/yum/dnf updates configured on for your system, but that's under your control; if you don't config that on, you get to choose when the apt/yum/dnf firefox update gets installed. It seems unfair to blame the packaging mechanism for doing what it was configured to do.

No more Flatpak (by default) in Ubuntu Flavors

WolfWings — Thu, 23 Feb 2023 21:58:42 +0000

...and Chrome isn't? At least on Linux I can track and block anything it's doing that I don't approve on far more easily than on Windows.

A webkit-based browser is what >90% of the web is designed and tested on, for better or worse. And Chromium doesn't cut it for some sites that rely on the various 'magic sauce' components the binary browsers include.

No more Flatpak (by default) in Ubuntu Flavors

dskoll — Thu, 23 Feb 2023 21:09:49 +0000

Oh, I see. Yeah, I just download a new AppImage each time I want to update. For a handful of packages, that's fine, but it's not scalable across large numbers of packages or machines.

Snap refresh behaviour is really strange.

himi — Thu, 23 Feb 2023 20:42:53 +0000

Thanks for that - the only thing I'd note is that when moving back to a non-snap Firefox having used the snap version for a while, you'll need to migrate the snap profile dir (which seems to be under ~/snap/firefox/common/.mozilla) back to the usual location.

No more Flatpak (by default) in Ubuntu Flavors

edwargix — Thu, 23 Feb 2023 20:04:44 +0000

Thank you for the detailed answer! Seems like a non-ideal situation currently unfortunately :(

No more Flatpak (by default) in Ubuntu Flavors

zdzichu — Thu, 23 Feb 2023 19:44:39 +0000

I believe AppImage applications are very seldom set to auto-update. It is possible, but cumbersome (https://docs.appimage.org/packaging-guide/optional/update...).
There are many security vulnerabilities discovered daily, lack of auto-update makes AppImage a non starter.

No more Flatpak (by default) in Ubuntu Flavors

dskoll — Thu, 23 Feb 2023 18:55:31 +0000

Naive question... what's wrong with AppIimage? I use a couple of programs that way (kdenlive, to take one major example) and they Just Work; no special software needed on my end.

Isn't that the goal of Snap and Flatpak too?

No more Flatpak (by default) in Ubuntu Flavors

smcv — Thu, 23 Feb 2023 18:48:42 +0000

To install a Flatpak app by clicking on a web link, you need a suitable package-management app that handles the application/vnd.flatpak.ref MIME type. It will pull in the flatpak(1) CLI as a dependency, but should usually use the libflatpak shared library to do the actual installation, giving it better control over what is going on than if it was a frontend for a CLI tool.

GNOME Software and KDE's Plasma Discover each have a Flatpak plugin that makes them a suitable GUI for handling these files, and other desktop environments are welcome to develop something similar if they want to. The intention is that apps like those are the primary user-facing interface for installing and managing Flatpak apps: there is intentionally no GUI in Flatpak itself.

If you only have the flatpak(1) CLI, you can still use the URL of one of those files as a convenient command-line shorthand, but the CLI isn't an app with a .desktop file and so isn't in a position to be a reasonable MIME type handler. It's intended to be a combination of "behind the scenes implementation detail" and "advanced UI for command-line enthusiasts".

It would be fairly easy for Ubuntu developers to install a MIME handler for application/vnd.flatpak.ref that would install or run a suitable GUI on-demand, if they wanted to (but if they wanted to do this, they presumably would have done so already).

The "Ubuntu Software" package manager in Ubuntu 20.04 and older was a modified version of GNOME Software, but since 20.04 it was itself installed as a Snap app with the Flatpak plugin unavailable (and installing the Flatpak plugin via apt would result in having two very similar apps confusingly both identifying themselves as "Ubuntu Software", one Snap and one .deb, with installation of Flatpak apps only available through the .deb version, if I understand correctly). I'm not sure how this works in newer Ubuntu.

(disclosure: I'm a Flatpak upstream co-maintainer)

No more Flatpak (by default) in Ubuntu Flavors

smcv — Thu, 23 Feb 2023 18:11:44 +0000

I'm unsure why a server would have had Flatpak on it in the first place? Flatpak is designed for GUI applications (and very occasionally "leaf package" CLI/TUI applications). I would have expected a server installation to start with no GUI and no Flatpak.

I realise some OSs only have a one-size-fits-all installation containing a full GUI environment, and encourage it to be installed on servers as well as on laptop/desktop/client machines, but I'd personally consider that to be a reason to choose a different OS for server use.

(disclosure: I'm an upstream co-maintainer of Flatpak, and it's installed on all my laptop/desktop/client machines but not on any of my servers)

No more Flatpak (by default) in Ubuntu Flavors

edwargix — Thu, 23 Feb 2023 17:28:49 +0000

One thing I'm slightly unsure of is whether this means Ubuntu users won't be able to install the one-click flatpakref files: https://docs.flatpak.org/en/latest/repositories.html#flat...

You need flatpak to install those, but maybe the installing flatpak itself part can be done automatically when Ubuntu sees .flatpakref file (JIT)?

No more Flatpak (by default) in Ubuntu Flavors

wtarreau — Thu, 23 Feb 2023 17:11:19 +0000

I agree. Yesterday I tried to install chromium on an ubuntu 22 and it took something like 7 minutes doing who knows what at 100% CPU, I thought the program was bogusly spinning in a loop, and it finally completed at the moment I was about to Ctrl-C it. I confess I could have tolerated a bug better than this sluggishness-by-design. Plus it takes vast amounts of space (we've had servers in our lab running out of disk space due to tons of useless garbage installed in the snap directory, that an rm -rf /snap fortunately fixed).

That situation with snaps reminds me the days I was still having a windows dual-boot 25 years ago, where you had to install random stuff you had no idea about, that stayed hidden somewhere on your machine and that you were never certain you would be able to completely uninstall.

I predict that it will be the next place where malware will install themselves. Who will remove vulnerable programs from there ? I'm seeing this number of suid root programs that anyone can abuse as a user:

$ sudo find /snap/ -perm -4000 |wc -l
48

Why do I need to have this live in parallel of the rest of the system ? Everyone will surely find it normal that there are 4 different "sudo" binaries on my system, three of which are there:

$ sudo find /snap/ -perm -4000 -name sudo -ls
1946 146 -rwsr-xr-x 1 root root 149080 Jan 16 14:40 /snap/core18/2679/usr/bin/sudo
1946 146 -rwsr-xr-x 1 root root 149080 Jan 16 14:40 /snap/core18/2697/usr/bin/sudo
1107 163 -rwsr-xr-x 1 root root 166056 Jan 19 2021 /snap/core20/1778/usr/bin/sudo
1109 163 -rwsr-xr-x 1 root root 166056 Jan 16 13:06 /snap/core20/1822/usr/bin/sudo

$ sudo find /snap/ -perm -4000 -name sudo | xargs md5sum
06823865db45a2b00dac4da4efc9b6c0 /snap/core18/2679/usr/bin/sudo
06823865db45a2b00dac4da4efc9b6c0 /snap/core18/2697/usr/bin/sudo
eb8c10001fe28b9c4c2e42b96347f6db /snap/core20/1778/usr/bin/sudo
d08d4862398f26ed4e79a28035258450 /snap/core20/1822/usr/bin/sudo

Notice how one has been there for 2 years, not sure if it's vulnerable or not, but in any case it's easy to overlook.

If I were to install a rootkit on an Ubuntu machine, I would definitely install it into /snap so that it remains unnoticed for the longest possible time!

No more Flatpak (by default) in Ubuntu Flavors

daniels — Thu, 23 Feb 2023 15:01:25 +0000

The hosting isn't Red Hat: https://ramcq.net/2019/08/12/flathub-brought-to-you-by/

As for the packager pool, all their repositories are hosted on GitHub, so you can easily go check who is listed as a maintainer, who contributes, etc. It's a pretty diverse bunch.

No more Flatpak (by default) in Ubuntu Flavors

pawel44 — Thu, 23 Feb 2023 13:41:10 +0000

Proprietary spyware on Linux. Great, but I think nobody asked.

No more Flatpak (by default) in Ubuntu Flavors

Conan_Kudo — Thu, 23 Feb 2023 13:19:34 +0000

Even Fedora has snaps available. And you can use snaps on RHEL/CentOS if you install the software from EPEL.

No more Flatpak (by default) in Ubuntu Flavors

atnot — Thu, 23 Feb 2023 13:19:26 +0000

This is technically true in the narrow sense that you can, with some work, get snapd to run some applications on many distros. However, this is for example only possible by turning off headline features like secure confinement, as it relies heavily on AppArmor functionality which is in practice not usually going to be available on non-ubuntu systems. It is also annoying enough to package that many distros have dropped it.

So while yes, it can run, there is clearly no sincere effort from Canonical to make it a first class citizen on non-ubuntu distributions.

Snap refresh behaviour is really strange.

dvandeun — Thu, 23 Feb 2023 12:59:42 +0000

If you would want to use firefox on ubuntu without snap, here is how: https://balintreczey.hu/blog/firefox-on-ubuntu-22-04-from...

No more Flatpak (by default) in Ubuntu Flavors

gtirloni — Thu, 23 Feb 2023 11:59:53 +0000

I've been using Flatpaks for a year with Fedora, and I think they're great, especially for proprietary apps like Spotify, Slack, etc.

Snaps on the other hand are really complex and I had many issues with them, plus it requires a daemon, etc.

No more Flatpak (by default) in Ubuntu Flavors

mgedmin — Thu, 23 Feb 2023 11:23:30 +0000

Recent change? A few years back I tried to install Chrome in a Windows VM, couldn't figure out how to get around Microsoft's roadblocks, and installed Firefox instead.

(These days I use Firefox by choice, rather than as a fallback.)

No more Flatpak (by default) in Ubuntu Flavors

funderburg — Thu, 23 Feb 2023 10:53:51 +0000

Flatpak's or Snaps - both are the first I remove and disable on any server I build. Ubuntu can beat that dead horse until it turns into soil but it's never going to work.