LWN: Comments on "Distributors entering Flatpakland"

Distributors entering Flatpakland

Curan — Sun, 21 Aug 2022 01:46:21 +0000

Using Flatpak for businesses is easy, that is an upside, especially if you ship some kind of Electron app. Corporate does not understand that you ship the sources alongside the basic Electron binary.

And – as a user – there are some applications (proprietary) I'd really love to lock into a very special sandbox, eg. stuff like Steam. Yes, I want to play whatever game I chose, but no, I don't want those to give access to my system.

So in summery: for everyday applications I want my distribution's (Debian's) binaries or a custom rebuild. But for proprietary stuff I do want to lock them into a tightly controlled sandbox, that Flatpak can provide.

Distributors entering Flatpakland

ras — Mon, 18 Jul 2022 09:47:49 +0000

> You don't have that web deb,

Odd. I do this often: "apt-get source xxx ; debuild xxx". In fact I do it often I have a little shell script that takes the URL of a Debian .dsc (source package), and builds it from source.

Yes, Chrome is a little different. It's near impossible to build from source. I'm struggle to understand anybody who favours the open source model could think that is a good thing, that should be facilitated by the open source movement. If your happy with that, why not just download the binary from Google directly and bypass all the inconvenience open source imposes? That's effectively what happens for google-chrome on Debian now. If you like running google-chrome on Debian it works very well.

Distributors entering Flatpakland

mathstuf — Sun, 17 Jul 2022 13:08:52 +0000

I think Zoom works. Google Meet *works*, but they say that the browser is not supported for background blurring. Which is what Jitsi belies.

Distributors entering Flatpakland

amarao — Thu, 14 Jul 2022 08:54:56 +0000

Is it so? I found no issues for zoom and meet. Meet is actually burn my laptop like hell, but it's doing the same with android phone, so I'm not sure if firefox here to blame.

Insofar I got no specific issues with FF/Linux with web applications for video. (Except for some antique Cisco solution with no linux support whatsoever).

Distributors entering Flatpakland

mathstuf — Wed, 13 Jul 2022 18:22:26 +0000

Alas, support for Firefox on Linux for the webcam-using apps seems to be "good luck". Google still says the APIs for blurring aren't supported despite Jitsi having no issue…

Distributors entering Flatpakland

muep — Wed, 13 Jul 2022 15:07:15 +0000

That "immutable core" thing does not automatically mean that it stays frozen. E.g. in Fedora Silverblue I get updates pretty much on the same schedule that I would get with the traditional rpm+dnf based Fedora Workstation. It does mean that making changes takes some more effort because the normal way to get the updated environment is to build it alongside the current one and the reboot there.

What is nice is that building the updated core environment does not require changing the current one. If the newly booted new environment shows regressions compared to the old one, I can reboot back into the previous environment.

Distributors entering Flatpakland

grove — Wed, 13 Jul 2022 13:36:20 +0000

Unfortunately flatseal is only distributed as a flatpak, causing a bootstrap issue. I.e. how to make sure that flatseal doesn't have any permissions you don't want it to have?

Distributors entering Flatpakland

amarao — Wed, 13 Jul 2022 04:36:51 +0000

I a modern world I found a perfect way to run this proprietary junk on my machine. It's called 'browser' and it is already with sandbox and a very good FS isolation. Given that half of modern apps is an Electron-based anyway, there is no substantial differences. Just pin them in tabs.

Distributors entering Flatpakland

madscientist — Tue, 12 Jul 2022 20:21:35 +0000

pro: I'm running Ubuntu 20.04 but I really need the newest Gnome Evolution version. There's no joy for me with traditional Ubuntu 20.04 repositories (and I totally understand why). But I can install the latest Evolution 3.44.3 via flatpak and it works great. Packaging FTW!

pro: Emacs 2.28.1 snap allows me to have the latest Emacs very easily (I used to use a PPA but that was not always updated to the point releases etc.) At least with Emacs it's easy to build myself, but if I don't need to then so much the better. Packaging FTW!

con: Ubuntu used to use a snap for the Gnome Calculator app: it took like 3 seconds or more to start which was ridiculous; when you hit the calculator key on your keyboard you don't want to be waiting for multiple seconds for it to appear. Packaging fail! (this was changed back again since BTW)

con: Emacs flatpak is completely useless (for me) because you can't access binaries outside the flatpak except by going through contortions with flatpak-spawn: I invoke all sorts of applications from inside Emacs such as spell checkers, LSP daemons, terminals, ssh, etc. etc. Packaging fail! (the Emacs snap installs in "classic" mode which avoids these sandbox issues).

So, there are good places to use packages like flatpak and snap, and bad ones.

Distributors entering Flatpakland

jafd — Tue, 12 Jul 2022 15:27:08 +0000

I think you mean snaps. Flatpaks don’t mount squashfs over squashfs (although the recent Ubuntu and Firefox snap kerfuffle wasn’t purely about filesystem speed; I think someone had unpacked Firefox’s snap into a directory, launched it, and it was still slow).

But you do end up with multiple shared libraries from different runtimes keeping being loaded again and again, so startup time won’t be negligible anymore.

And yeah, this is my beef too. You work hard so with PIC binaries all over the place you don’t need to play with relocations anymore, now filesystem cache and mmap() can work about as well as it gets, and then you ruin it by making all executables bring their own slightly different versions of shared libraries. There have been times that RAM and storage and electricity seemed cheap and getting even cheaper; sorry, looks like these times are over.

Distributors entering Flatpakland

civodul — Tue, 12 Jul 2022 15:24:39 +0000

As the author aptly notes, it was clear from the start that the very design of flatpak is appealing to proprietary software vendors—unlike traditional distros, which were designed for free software and make it easy to exercise user freedoms, for example with apt-get source. Flatpak’s web site has advertised proprietary apps on its front page for a while now; it should come as no surprise that distros that support it will now provide proprietary software without letting users make informed choices.

The whole “immutable core” thing also looks like poor engineering: does one really want to keep all the low-level software stack frozen in time?

I think we, free software folks, need to address the lack of flexibility of traditional distros that make opaque solutions like flatpak appear necessary. We need to let users know that their autonomy and privacy are at stake (and ours, collectively), let them make informed choices, and design distros for practical user freedom. To me this is very much the mission of Guix.

Distributors entering Flatpakland

mathstuf — Tue, 12 Jul 2022 14:24:23 +0000

> And I don't want to have to hide my address book from my image editor. It's so unsanitary!

I agree in general. However, the world is not so nice in reality. I *do* want to hide it from Zoom and Teams because my trust for these is quite low. I don't know how to do this without some kind of sandboxing.

Distributors entering Flatpakland

amarao — Tue, 12 Jul 2022 13:27:18 +0000

The main opposition to flatpacks is that they are slow. Each app start need to do bunch of mounts, and they are slow. It may be less of the issue for giant slow starting things like loffice or python app, but it's definitely an issue for smaller things. Just imagine flatpack for awk and grep.

It adds latency and makes output of mount/DF crazy long.

... And sandbox is sounds like chlorination for chickens. You keep chicks in unsanitary conditions and then wash them with chlorine. Or you ban chlorination and vendors are forced to vaccinate chicks and keep them in sanitary conditions.

Having sandbox for trusted apps sounds like 'not trusting apps'. And I don't want to have to hide my address book from my image editor. It's so unsanitary!

Distributors entering Flatpakland

khim — Tue, 12 Jul 2022 09:31:30 +0000

And only tiny minority of software ends up in GNU/Linux distros.

Of course software there would be rebuildable! It's like trying to see how many people are using Internet via an Internet-based medium.

But even the majority of deb and rpm packages (delivered by various commercial providers and/or parts of lesser-known distributions) come without source.

You just try to live in the imaginary world where these don't exist.

Distributors entering Flatpakland

eean — Mon, 11 Jul 2022 22:07:31 +0000

Flathub is like that, but that isn't what this article is about. You'd be installing and updating your packages from a distribution curated repository. Specifically that part isn't different.

Distributors entering Flatpakland

mbunkus — Mon, 11 Jul 2022 21:07:31 +0000

Yeah, you're right. The manifest documentation[1] does indeed talk about multiple desktop files per Flatpak. Looks like I assumed "single desktop file" due to the other things (application ID, AppData file, Flatpak icon) only being singular. My bad.

[1] https://docs.flatpak.org/en/latest/conventions.html#deskt...

Distributors entering Flatpakland

bartoc — Mon, 11 Jul 2022 21:01:14 +0000

Honestly windows isn't that bad on these sorts of machines if you disable windows defender (which is .... rather involved)

Distributors entering Flatpakland

bartoc — Mon, 11 Jul 2022 20:55:35 +0000

I believe there is a default for when you say "flatpak run", however you can install multiple .desktop files that point to different binaries.

Distributors entering Flatpakland

bartoc — Mon, 11 Jul 2022 20:53:34 +0000

The runtimes themselves are some container image format, usually ostree, but fedora uses OCI in some cases. The packages do tend to come from the normal packaging ecosystem of whatever distro provides it. I think the freedesktop sdk might use yocto.

Distributors entering Flatpakland

bartoc — Mon, 11 Jul 2022 20:51:25 +0000

The fact is most platforms have pretty simplistic mic and (esp) webcam handling. I'm not sure about OSX but Windows doesn't multiplex access to webcams at all, so only one app can use the webcam at a time!

I think both of these things are goals of pipewire, hopefully someone will develop simple tools to do this (every such tool I have used on other platforms has a UI modeled after like, manual switching panels that I find difficult to use).

Distributors entering Flatpakland

bartoc — Mon, 11 Jul 2022 20:45:48 +0000

it isn't like flatpak and docker are using fundamentally different technology. Flatpak sandboxes are based on either bubblewrap or (I think) unprivileged namespaces if the kernel can support all required features, this means you don't need to be (effectively) root to run a flatpak.So it's not really a "remake" as much as "yet another use of". Actually I think docker (and _esp_ LXC) are kinda the least interesting use-cases for container tech/namespaces on the planet.

As for container data format: actually, fedora's official flatpak repos _are_ based on the same OCI image format supported by docker. Flathub (and most other) images us OSTree, which theoretically should allow better de-duplication especially for apps that contain a lot of non-runtime dependencies.

The runtimes can update "under" the apps, and there is a concept of "runtime extensions" to add additional maintained bits to the runtime that can also update under apps. what doesn't update are all the higher level dependencies that don't really tend to provide API/ABI stability anyway but where on a traditional linux system all packages must share a single version. This leads to a proliferation of patching in distros that sucks for basically everyone.

For "why not a self contained binary": Yeah, stuff like Appimage can work. The thing is you actually really need some stuff to get updated underneath the app. Graphics driver userland libraries come to mind, as do platform libraries like glibc (and it's associated NSS plugins). These libraries all have really stable ABIs and are _designed_ for this. You can do this with just a dynamic binary that has most things static linked, ofc, and that can be fine, but flatpak uses containers because they can and because they want to do other stuff besides just bundling dependencies.

Distributors entering Flatpakland

bartoc — Mon, 11 Jul 2022 20:18:19 +0000

* The filtering by license should be improved, it appears how fedora was doing it was a bit hacky
* yep, and I think flathub lists SPDX identifiers too, so you can distinguish between GPL-2.0-only and GPL-2.0 or GPL-2.0 only or GPL-3.0 only and so forth.
* Yeah, many users might, but on the other hand they are using a free platform with (extremely importantly) a free "appstore" and distribution mechanism.
* Yep, and perhaps many non-technical people will want to use a free platform because they want to escape from having the platform try and sell them things, especially things sold by the platform vendor.
* I agree, and I think flathub and the gnome-software experience do a pretty decent job, the banner is a pretty simple red indicator in the "app details"

The other nice thing is that flatpak will prevent non-free apps from screwing up the system by incorrectly attempting to do applocal deployment of their runtime dependencies. It's really rather hard to do this correctly on linux (and can be nearly _impossible_ if you end up with libraries that load tightly coupled plugins and are too enthusiastic in their search for them). Let's just say if I still had to support Matlab installations I would absolutely make a flatpak and distribute it that way.

I suppose making bundling in this way easy does make it easier to distribute proprietary apps (after all, proprietary rpm/dpkg repos are .... not usually worthwhile or reliable)

Distributors entering Flatpakland

bartoc — Mon, 11 Jul 2022 19:56:30 +0000

Yes they can be "whatever blobs" but that's true of dpkg and rpm too. The enforcement is at a distro policy level, not part of the tool. Indeed Fedora's flatpak repos enforce a similar policy to their RPM repos. But flatpak is more lax.

Distributors entering Flatpakland

walters — Mon, 11 Jul 2022 18:40:07 +0000

Sure, though that doesn't help at all with the "can put a systemd unit in /etc/systemd/system with an ExecStart=/usr/bin/myapp --inject-root-shell" problem.

flatpak is scoped to install only GUI/desktop applications that should run without any host privileges; you can't use today flatpak to install a (system wide) VPN system or whatever. So by limiting its scope, it is much more secure for its target domain.

Distributors entering Flatpakland

smoogen — Mon, 11 Jul 2022 16:41:07 +0000

No, sorry I don't think we got it right.. I just didn't want to spend 600 lines going over every other tool system which has followed the same path.

I also did not come in when the tools were right, I came in when everything was unbundled and you downloaded various 'tarballs' from websites and hoped it worked on your system. I then went through most of the joys of 'oooh I get this so much faster and easier' to 'ooooh I get to rebuild all this and make it work the way I want it' to 'ooooh now I have to figure out how I made this 6 months ago because the backups ate themselves and I need to restore this site.' Each of them had their own positives and negatives. Each had their 'stop talking at me old person, just because you had problems then doesn't mean I will now'

Distributors entering Flatpakland

atnot — Mon, 11 Jul 2022 16:19:24 +0000

> As far as I can tell this is humanity having to relearn all the lessons that the 'previous generations' had to learn themselves.

This sort of bundling and unbundling cycle has been going on forever in all sorts of places. I could just as easily shift your argument by half a wavelength and then I'd be grumbling about how the young ones refuse to see the hard learned benefits of bundling instead (it might sound a bit like someone complaining about npm).

It sure is a lucky coincidence that the generation of tools you grew up with and are most used to happen to be the ones where the cycle ends, we Finally Got It Right, made the perfect tradeoffs and there is little left to improve upon (:

Distributors entering Flatpakland

IanKelling — Mon, 11 Jul 2022 16:05:20 +0000

+1 I agree

Distributors entering Flatpakland

IanKelling — Mon, 11 Jul 2022 15:45:47 +0000

It is not documented on the wiki as far as I can tell. In the main docs, there is a mention of a builder option which would create a sources package. That doesn't really help anyone know that those packages exist on flathub.

"the wiki" I assume you mean is: git clone https://github.com/flathub/flathub.wiki.git

Distributors entering Flatpakland

farnz — Mon, 11 Jul 2022 15:31:47 +0000

But the underlying shift is that because resources have become more abundant, it's easier to consume extra resources than it is to solve the social problems within the ecosystem - requiring people to have at least 3 GiB RAM has gone from "rules out most people" in 2007 to "virtually everyone meets this requirement" in 2022.

So that moves the balance point for what sub-optimal technology decisions you can accept in order to allow you to avoid dealing with people who aren't constructively helping. It would be nice if everyone involved in open source was constructive, but unfortunately, there exist people in all walks of life who consider it more important to be "right" by their own definition than to be constructive.

Distributors entering Flatpakland

farnz — Mon, 11 Jul 2022 14:41:57 +0000

The comparison is even more stark if we move down from the high end CPUs to the low end; back in 2007, if you were in the market that today buys a Celeron N4020 (4 MiB LLC) with 4 GiB RAM, you'd have been buying a Celeron 365 or equivalent, with 512 KiB (0.5 MiB) LLC, and 512 MiB or 1 GiB of RAM.

Indeed, the gap between "as cheap as possible" and "low end for rich customers" machines has been shrinking over the last 15 years; you've gone from having 1/4 the RAM and 1/4 the LLC in an "as cheap as possible" machine as compared to "low end" to 1/2 to 1/3 the LLC and 1/2 the RAM of a low end machine for a rich person. The remaining gap is in mass storage - where a "low end" machine will have an SSD nowadays, a "cheap as possible" machine will still have a HDD because of the size differential between a $30 HDD and a $30 SSD.

That said, that gap may change, too - HDDs are limited in terms of how cheap they can be because they are precision mechanical systems, where an SSD scales down in cost; it was already true 8 years ago that if 30 GiB is sufficient space, an SSD was a cheaper option than a HDD, and the space on really cheap SSDs is likely to grow over time.

Distributors entering Flatpakland

Wol — Mon, 11 Jul 2022 13:59:34 +0000

Well, gentoo won't be going down that route, but it has other problems on low-powered machines ...

Cheers,
Wol

Distributors entering Flatpakland

rbtree — Mon, 11 Jul 2022 13:45:35 +0000

> Intel's 10th Generation Core processors are still current

Oh god.

One of the of most significant advantages of Linux always was how efficient it is and how well it runs with limited computing resources. Personally I'm mostly using it on a desktop with i5-4460, and it runs as well as it did in 2014.

In my country, a lot of low-powered *new* laptops are beind sold to this day. Things with CPUs like Celeron N4020, 4 GBs of RAM, and HDDs, and people are buying them en masse because what else are you going to buy with a salary of $200-300 a month after taxes (which is what a cook or a construction worker typically makes)?

Teachers, doctors, and bureaucrats of all sorts are not doing much better.

Windows is pretty much unusable on those kinds of machines (although people are doing that and it's painful to watch). I'm sure there will be some distributions that will not go down the flatpak road and will still care about performance, but if all the popular ones do that, I'm afraid I will have nothing to recommend anymore (you're not going to recommend some student's side project that may be announced EOL a couple of days from now to a newbie).

Distributors entering Flatpakland

bojan — Mon, 11 Jul 2022 13:42:30 +0000

If things could be solved by brute force on computers, we would not need smart data structures, compression, optimised algorithms etc.

Installing another copy of, for example, mesa, on a system that already has one is simply sub-optimal. The only reason this is supposedly required in an open source ecosystem is because people refuse to come together and co-operate. And that will always be to everyone's detriment.

I understand that flatpak developers are trying to solve a real problem, which is amazing fragmentation of the open source ecosystem. The current result, unfortunately, has pretty serious side effects.

Distributors entering Flatpakland

mbunkus — Mon, 11 Jul 2022 13:37:33 +0000

Flatpak manifests contain both the download URL as well as a checksum to verify that the downloaded file matches the expected content. See the LibreOffice manifest[1] as an example.

However, you can also provide files alongside the manifest in the same git repo. See e.g. the MKVToolNix manifest[2] as an example.

[1] https://github.com/flathub/org.libreoffice.LibreOffice/bl...
[2] https://github.com/flathub/org.bunkus.mkvtoolnix-gui

Distributors entering Flatpakland

LtWorf — Mon, 11 Jul 2022 13:32:03 +0000

But can they be whatever blobs or have to be pre-approved in some way?

Distributors entering Flatpakland

mbunkus — Mon, 11 Jul 2022 12:50:05 +0000

Interesting. I'd like to know how that works, as the LibreOffice Flatpak build file[1] looks pretty standard (albeit huge): one "command" only, no mention of other desktop entries etc.

[1] https://github.com/flathub/org.libreoffice.LibreOffice/bl...

Distributors entering Flatpakland

abo — Mon, 11 Jul 2022 12:44:14 +0000

I don't know how it works, but I've got LibreOffice installed as a Flatpak (from Fedora) and it shows up as multiple applications in GNOME.

Distributors entering Flatpakland

smoogen — Mon, 11 Jul 2022 12:36:39 +0000

As far as I can tell this is humanity having to relearn all the lessons that the 'previous generations' had to learn themselves. You can tell someone about all the problems they are going to walk into, but the human brain is built to skip all that until it lives those events itself. So the game for all of these repositories goes as follows:

1. New people hate dealing with the old way of doing things and want to do something different.
2. They build a bunch of tools in a new way and pile out their repositories with all those things.
3. Older people point out that their will be problems and if they did this or that they would be better off.
4. New people usually respond with 'this time it will be different.'
5. It isn't different and then the generation afterwards comes up with a curated method to deal with the pile of software.
6. They build businesses on this and get settled into their ways.
7. Goto 1.

Having now lived through different developer generations who have practiced the following:
download someone's prebuilt tarball and install it. Cant fix the code so suffer
download someone's source code and build it
upload that code to some central place for people but then find ftp site full of crap
come up with debs and rpms to help deal with updates and see what was built with built
find that ends up with dependency hell
come up with apt/yum/etc to deal with dependency hell
find out that people are building repos willy nilly and stuff is now broken between repos
try to figure that out with modules and other tooling
decide that all that is too much work and pile up all the prebuilt code into a container.
...

I expect that we will go through various solutions until curated containers will be replaced by the next 'tarball' layer.. probably someone's uploaded datacentre.

Distributors entering Flatpakland

Wol — Mon, 11 Jul 2022 12:35:18 +0000

Whoops yes, sorry.

I make sure my machines now have more :-) But even 4GB is still tight as a Windows machine ages - it just gets horribly slow.

Cheers,
Wol

Distributors entering Flatpakland

farnz — Mon, 11 Jul 2022 12:28:53 +0000

Caches have also grown, however, so while the absolute efficiency has gone down, the proportion of the cache that's inefficiently used has not.

Intel's 10th Generation Core processors are still current (despite the 11th and 12th generation existing), and have typically 8 MiB or 12 MiB of LLC (plus higher levels that are affected more by working set size than by total size); in 2007, the Core 2 Duo was the latest hotness, with 2 MiB of LLC (plus higher levels).

All the resources have grown significantly since 2007, and thus the "ideal" tradeoff point between needing infinite human time to get minimum resource usage, and needing infinite resources to get minimum human time has moved.