Linux desktop leaders unite behind Flathub app store. Here's why
zdnet.com
zdnet.com
Even worse, I could not find out which apps to delete. All the space was taken up by excess "runtimes" I don't know or care what a runtime is but I never intentionally installed them. Why are there five different Freedesktop and Gnome runtimes installed? Which app do I delete to get rid of them?
I need to be able to easily answer the questions: "Which app(s) do I delete to free up space?" and "how much space will be freed by deleting app X?"
On flatpak those questions required dark magic beyond my understanding to answer.
Keeping dependencies with applications does have a lot of advantages, especially for applications that need incompatible versions of the same libraries. But, having every application with its own full set of dependencies seems quite wasteful.
With container images you're bundling your app with exactly the libraries it needs at the exact versions you want. This means that the kernel is loading all of this auxiliary pieces for you, distinct copies, that then have to reside in their own mappings, so you get no saving there (it's actually slower in terms of program startup), and then you also are wasting tons of disk space to have all of these duplicate dependencies lying around.
Really, the idea of duplicating an entire os tree for containers is just a bad idea, and it leads to lots of super vulnerable images and destroys the whole concept of sharing a system base for performance and storage wins.
Need to run 2 separate apps that both need to use the same userid/filesystem path/network listener port? No problems.
Need to have different library versions? No worries.
Sure you can workaround all this stuff with ld preloads and other things, but that requires more skill than copying a base dockerfile from a google search and putting in a bunch of RUN commands.
Is my system is guaranteed to fill up completely if I don't run that command regularly?
It could also benefit users that have more disk space than bandwidth (I was in that situation for a while, though a mechanism for sharing runtimes with LAN peers would be nice).
Discussion: https://github.com/flatpak/flatpak/issues/2639
Related blog entry: https://blogs.gnome.org/mwleeds/2021/01/11/cleaning-up-unuse...
Remove EOL automatically: https://github.com/flatpak/flatpak/pull/3871
As for which container, it doesn't really matter, and there's been a lot of not-invented here going around creating new containers that muddied the waters. But the truth is they're all symptoms of something bad even if they mitigate a problem temporarily (while making debugging, networking, freedesktop standards, etc incomparably harder).
--
Flatpak is awful, i tried installing software from it a few times and not only it always installs a ton of unnecessary stuff (practically an entire distro!) but also the software doesn't integrate seamlessly with the rest of the system. GUI software looks wrong (themes do not apply, font rendering is wrong), command line software doesn't show up in PATH. Example in [0] for the GUI bits (Bless for theme, Notepadqq for font rendering) as well as the disk usage for two simple programs like a hex editor and a text editor.
Even worse, while there is an option to install things in the user's directory only (so i can make a separate user to try some things that i can easily delete later) not everything installs with that options and wants root access to pollute the rest of my system.
Nowadays i simply avoid anything related to flatpak. If something doesn't provide normal binaries and i really want it, i'd rather compile it from source (and if the source language is something exotic or the program needs a ton of dependencies i'd just skip it).
Command line software does show up in CLI, just not by its short name. You have to use the fully qualified app name - com.xyz.whatever. You can make an alias if you want.
> Even worse, while there is an option to install things in the user's directory only (so i can make a separate user to try some things that i can easily delete later) not everything installs with that options and wants root access to pollute the rest of my system.
Are you talking about flatpak install --user ? Yes youre right some apps might not work with it but how is that any worse than traditional packaging.
Flatpak isn't perfect and I prefer distro packaging over everything else but it isn't feasable to have distro packaging for everything - not with the strict packaging rules most distros have atleast.
But out of snap, appimage and flatpak I'd go with Flatpak.
Ultimately I want my software to be shipped by my OS's package manager like pacman, apt, nix, or flatpak etc. The fact that I can go ahead and install dependencies in pip, npm is an implementation detail while I'm working with the code. The entire linux ecosystem should have been designed in the first place like nix, AppImage or flatpak from day 0 and going to the "shared libraries" route was simply a bug. We thought it was ok, but we quickly saw it was not ok and we should have made the observation that it's not working and switched but we didn't. Like nix does, when there are common dependencies between apps you can still optimize and install them once, but each app should define its own dependency and that version alone should be allowed to use so that a library upgrade doesn't break anything.
Unfortunately, package management is an utter mess today and I no longer have any appetite to use things like `pacman` or `apt` unless absolutely necessary. And this is not even just the fault of archlinux or Debian. Case in point, MuseScore (an app I use every day to write music) published MuseScore 4 over MuseScore 3. The fact is, MS 4 is much better than MS 3, but some workflows are different and it's not in complete future parity with MS 3 (some things they decided not to implement). Now, I want to use MS 4 and I do use MS 4 for most things, but for certain things I still absolutely need MS 3. By "absolutely": I mean for some compositions MS 4 is a dealbreaker and MS 3 is the correct tool. But most other compositions MS 4 is the superior and correct tool. But when they published MS 4 pacman immediately made the package `musescore` point MS 4 with no option to install MS 3. They're two entirely different apps. Solution? Just download the .AppImage from website and call it a day. It would have been much better if `pacman` serves MS4.pacman_exe and I click on it and it opens MS4. Then, it also optionally serves MS3.pacman_exe, I click on it and that also works. If I desire I click on MS3.6.2.alpha43432.pacman_exe and use that specific version, with every library fixed. But this is currently impossible since each version can potentially need different dependencies etc so .AppImage is the only way.
Traditional distros are able to install the same apps side-by-side, such as python2 and python3, if they put their mind to it. It is just a bit clumsy. Sounds like they didn't allow for that with your app. That's a shame, I guess you could ask or cough up a donation to help?
I generally just wait for things to get packaged in the regular distro, but it is nice to have choices.
Its not an apt problem, its a problem that the application is fundamentally a new product that needs a unique name.
Flatpak feels like it took the wrong lessons from the past 30 years of software distribution and turned it into a platform. I get that it has to be simplified to be friendly to newer users, but it's also a complete turnoff when you want to fix an issue or edit a config file.
Why can't we just static link everything, and distribute binaries like we're on win32?
The big difference isn't static vs dynamic but that on Windows the DLLs that come with the OS do not break backwards compatibility so applications can rely on them whereas on Linux only a very tiny number of libraries do not break backwards compatibility (from the top of my head that'd be glibc[0], X11/Xlib/etc, curl and OpenGL). Most importantly the libraries for making a GUI application do tend to break backwards compatibility (see the breakage in Gtk1->Gtk2->Gtk3->Gtk4 and Qt1->Qt2->Qt3->Qt4->Qt5->Qt6 though with the latter being C++ they can't help it as C++ itself makes it harder with not having a stable ABI). Not all do (AFAIK Motif has been backwards compatible since the early 90s) but those that don't aren't that common (for unrelated reasons - e.g. most provide only a small fraction of the functionality Gtk/Qt provide or, in cases like Motif, the license was unpopular with FLOSS developers so no ecosystem was built around it).
[0] they do break compatibility for programs using unsupported APIs though
If you've got $$$$ of CAD software (or whatever) in binary form, which you know will work on pretty much every version of Windows but will absolutely not work on Linux or OS X - that's a good reason to stay on Windows. Microsoft is willing to do a bunch of compatibility testing etc to maintain that moat. They've got the money to pay developers to make sure Office 97 still runs on Windows 11.
Linux, on the other hand, has a lot of different stakeholders - and some of those stakeholders take the opinion that closed source software can go fuck itself. Maybe a Linux distribution wants to update from OpenSSL 1.1 to OpenSSL 3.0 and they're quite happy to patch all the software that's part of the distro. If you want to run some closed-source binary-only software from 1997 - that's between you and the software vendor, buddy.
It is sadly a very common misconception that backwards compatibility is only for close source software but in reality FLOSS benefit a ton from backwards compatibility too.
Imagine for example if glibc decided to add a third parameter to fopen (ignore if it is realistic for glibc to do that, this is for the sake of argument).
The only benefit of FLOSS[0] would be that it'd be easier for someone to update it to use the third parameter instead of waiting for the original developer to do so - but still every program, FLOSS or not, would need to be updated anyway and someone would need to spend time doing that update.
A more realistic example would be GIMP: the stable releases (last was made a few weeks ago) still rely on Gtk2 and the Gtk3 port (i.e. the effort to move from Gtk2 to Gtk3) is still in beta while the Gtk devs consider it deprecated. And this is all open source, no closed source software in sight, yet see how much time was lost (not only for GIMP but for any software that relied on Gtk2 and had to switch to Gtk3, with the story repeating for Gtk4) - time that could have spent improving the actual functionality that the GIMP users use the program for - adding functionality for manipulating images - instead of using yet another approach to draw and lay out buttons, menus and checkboxes - something that was already solved back in Gtk 1.x days.
[0] actually of any source available that doesn't have a "see but don't touch" rule
Because what happens if there's vulnerability in say zlib or openssl. As a distributor you'd need to rebuild everything (volunteer-run distros don't have sufficient cpu time to rebuild the whole archive at once), and in the process check if the update won't break anything in each and every package. Or rely on upstream (which may be unresponsive, because they're also volunteers).
This might be manageable in relatively small, single-language, corporate-backed apps, but is not viable in volunteer-run operating systems with ~50k packages written in every single programming language invented.
No one distro will risk this (imagine Phoronix article: "After 1 year, CVE-2023-123456 fixed in only 30% of packages in StaticLinux!").
I mean, you're free to try. I'll provide time-to-fixed statistics for all your CVEs.
Flatpack Runtimes do this for common dependency lists, but still allow some customization, without me having to recompile openssl- or some other annoying upstream.
Example: LibreOffice download size (source)
- AppImage ~248 MByte
- Snap 463 MByte [July 2020 update]
- Flatpak 543 MByte
Maintaining backwards and forwards compatibility will cripple you as a lib developer. If you do it, your solution will be slower to change, and probably slower overall than a solution that breaks compatibility occasionally.
So you get less contribution and small bus factor means this library is more likely to die.
In addition, even in the case the applications stop getting developed, they will keep working since their dependencies would not break and other developers can pick them up if needed, even years later. On the other hand having to pick up a project whose dependencies do not even work anymore is much harder.
In theory, yes. In practice due to Hyrum's law you'll have to reproduce bugged behavior because an application exploited a bug in your code. See for example SimCity Windows 95 compatibility story.
https://arstechnica.com/gadgets/2022/10/windows-95-went-the-...
Now Microsoft could afford to buy and test a wide combination of hardware and applications to ensure future compatiblity.
I don't have first hand experience with nix, but if I would look at this statement from Guix point of view (and I assume nix will be same/very similar), this is not really true.
Nothing prevents you from having a list of libraries (in a manifest). That list might be way to wide for any specific program and it can represent what you would normally have as "system libraries".
You can then just invoke shell as guix shell --manifest=manifest.scm and you will be given working shell with all the libraries available.
You can also just package your program using trivial copy&paste code with the same list. Sure, the dependencies will be too wide, but since you are not sending the package to upstream Guix for inclusion, no one really cares.
So, is it as friction-less as "normal" distro? No (especially the "add to /bin" part).
Is it as bad as "manually create and specify the entire "system" libraries set bit by bit every time"? Also no.
NixOS deliberately avoids having global/implicit 'system' libraries / configured state, and instead demands declarative expression of the system configuration. -- The libraries the system uses don't adhere to a global FHS structure.
Nix similarly eschews use of global/implicit libraries. Building each package requires its dependencies be declared.
However, it's incorrect to say this is "just containers". I don't see how you get "abandonment of concept of desktop distro" from "doesn't have implicit system libraries". -- NixOS allowing the whole system configuration starting from a single file is convenient, and something people might otherwise use a tool like Ansible for.
That said, NixOS obviously has many use cases which have significantly higher friction compared to more typical systems. (And a steep learning curve to overcome that friction). -- e.g. on Arch or Ubuntu, the system configuration is global and malleable.
Nix is the actual and only novel solution in this space — you can just have a single flake file in your repository to make it always reproducible. It will only build/download files that are necessary, using a minimum required space.
But for this reason it can also just point you to a binary cache and you can copy the necessary data (basically just a diff of what is required dependency for running program P and your system). Just because the source is not available doesn’t mean that the dependencies can’t be explicitly specified and use some standard deps. Chances are that proprietary app will just depend on a libc you already have downloaded.
Snaps bind in the libs, Nix sets env variables to set the available libs. The goal and end results are the same. The difference is more marketing than anything else.
On Nix there is no separation of file system or network across applications. The same installed libraries can be used by multiple apps. Apps have access to the same system services and run together, e.g. with a single systemd. How can you call what Nix is doing "containers" ? There's virtually no overlap.
Zoom overtook the local freeway as the preferred mechanism for get to meetings at my company. I guess Zoom is a road by your logic.
Or maybe you'll now say that Snaps are not containers because they do it in a Nix like way? By your logic a frontage road is not a road just because it's dedicated to a single commercial development and named differently.
In my top level post which started this big thread I claimed that the purpose of containers (Nix, Snaps, Flatpack, Docker, AppImage, etc) is to solve the future shock problem and allow running of broken applications by controlling the libs available. I stick to that claim here.
Sounds like a container to me, and it's not how Nix does things.
And it's actually pretty cool that Flatpak keep improving, even in the past few years. It's not improving as fast as I'd like (I want VPN apps, Lutris controlling emulators, and Native Host Messaging to be working already) but a lot of issues are being worked on and these days they work well enough.
I still prefer to use AUR if I could access it there, and some of the things I do are only available distro-agnostically through Nix or arch distrobox, but Flatpak is absolutely great when it's available and the sandbox isn't in the way.
The only benefit(s) I see are:
1. Sandboxed applications (via containers?) - so applications you have don't technically have access to your home directories by default. That's sort of nice - but how many applications really warrant this overhead?
2. Possibly easier to write/package? That said, in Nix you pretty much just need to package once.
I've not used Flatpak - can somebody who is maybe familiar with both technologies comment further? While I may be a big Nix evangelist, it's always confused me a bit why Flatpak exists and I'm curious if it is truly solving a problem I'm unaware of.
- Flatpak doesn't require apps to be rebuilt when the runtime changes, whereas Nix would require a rebuild. This is, of course, an intentional selling point for Nix: you don't have to worry about keeping track of ABIs and the like. This is, however, less fun when you have to update a large amount of applications for little reason. - When using flakes, it's easy to end up with a lot of extra disk usage because of a proliferation of different nixpkgs versions. Flatpak's runtimes help avoid this, since apps target a runtime version and can run under any individual commit for that version. - Flatpak has a massive amount of internal infra for sandboxing that would take a moderate effort to reproduce elsewhere. - This also means that running Flatpaks always involves new user namespaces; this can't just use environment variables like Nix does. - Flatpak's entire setup is more tuned towards GUI applications, with support for stuff like swapping out the graphics drivers. (nixOS can ofc do this, but you need nixGL otherwise.) - Flatpak has support for downloading non-redistributable files at install time and placing them in the same location as the application's main files. - Flatpak's summaries that it downloads from the server are much smaller than nixpkgs checkouts. - Flatpak dedups individual files across apps.
Really, it's just that Flatpak prefers keeping the build process and usage simpler to focus the energy on sandboxing, leading to design decisions like the more straightforward runtime/app split (easier for a user to understand / manage) and all of the built-in extras for graphical applications. Nix has a significantly more complex UX but is infinitely more flexible and also far better suited for development environments.
If your thought is "most of this isn't structural", that wouldn't be incorrect: there is no reason that:
- building flatpaks couldn't use a more nix-like model - nix couldn't add sandboxing and summary support on top
Heck, you could probably build a Flatpak from a Nix derivation, if you figured out how to separate the "runtime" and "app" parts. But at the end of the day, every tool has some limited degree of development bandwidth, and as-is, Flatpak and Nix just optimized that bandwidth for different targets.
I doubt it's intentional. Guix has solved the problem---update the runtime without rebuilding the app---while being fairly similar to Nix's concepts in general.
You have to learn a specific programming language just to use it, so the barrier is: learn to use a computer, learn to program, learn a specific language
Compare that to desktop distributions, or windows, or macOS the barrier is: learn to use a computer
I agree Nix’s biggest issue is that it’s extremely hard to consume. It took me essentially over a year before I felt… proficient in using it.
How well does Nix integrate packages into the system? Flatpak is integrating apps into the desktop environments. Probably just following standards, but is Nix doing this too?
Are Nix-Installations portable? I use Flatpak to have the same installation on different systems available, just move my SSD between them. How ell would this work with Nix?
The problem Nix solves is the one Flatpak tries working around - how do I guarantee software builds and runs on my system? The answer turns out to be "very strictly", and Nix has done a good job of writing sane rules where it can. It's not perfect (and definitely not user-friendly today) but it has a larger package repo to work with and better support for stuff Flatpak is missing like system services. If people do want to switch to an immutable root system, I'd hope the goal is to be as modular as NixOS is someday.
Optional dependencies seems to be an issue, though, as I needed to figure out what on my own I need to get thumbnails on Dolphin working correctly, but I might still be missing something that I'm supposed to do in this case.
As for portability, it seems doable with home-manager: https://julianhofer.eu/blog/01-silverblue-nix/#home-manager (itsfoss also have a pretty good NixOS guide that will cover home-manager as well).
It's not just for installing software - I have a declarative, shared configuration for each software that works deterministically on each system I share it with (NixOS or not).
> Are Nix-Installations portable? I use Flatpak to have the same installation on different systems available, just move my SSD between them. How ell would this work with Nix?
No, but the configurations are (see earlier response), so this seems to be the same benefit here.
> How well does Nix integrate packages into the system? Flatpak is integrating apps into the desktop environments. Probably just following standards, but is Nix doing this too?
I don't exactly know how to answer this - and it's probably partially because I don't use many modern desktop environments (when on NixOS I use i3, otherwise I'm on macOS, which is a bit of a specialized usecase). So I can't really comment here.
As far as installing immutable packages accessible from the system - it does a pretty exceptional job.
Flatpak is not just easier for packagers, it's miles ahead when it comes to simplicity for end users.
There you have it. Apples and oranges.
Even for well curated applications, through less so.
So I'm happy about the general direction here.
But last time I looked at flathub (and related topics), I was quite disappointed to a point that I would say they majorly failed this. Now that was quite a while ago. But just the fact that in a non well curated app store you could download applications which where not effectively sandboxed (e.g. used it only for copatibility not sandboxing) in a context which made it look for users like it's sandboxed without any huge red warning label or similar was quite shocking and made me second guess the security competence of the involved developers.
Now I hope things are much better by now and I guess I will spend some time to look into it again this weekend.
But the reason I write this here isn't because I want to dump on flathub but because I often feel that huge parts of the Linux community seem to be very out of touch when it comes to desktop OS security to a point it makes me worry for the future of desktop Linux.
(It's also not just security e.g. some design decisions and defaults of systemd make sense for many Linux use case, but not desktop systems. The Unix permission model doesn't match well to the desktop OS security concerns of today either etc. etc.)
It does take a while for toolkits to start using them, but AFAIK, as an example, both KDE and GNOME now transparently use portals for the file chooser dialog.
It will take more time for everything to move to newer, safer APIs (Wayland, screensharing portal, etc). The situation is much better than it was a few years ago, though.
And most frontends now display required permissions; KDE even recently integrated permission management in is system settings.
Some portals still need to be devised though, especially for device access (gamepads, webcams, etc).
I liked linux because I considered it to be a great development environment, but I always thought it was annoying as hell to run consumer software on. And I do have to run consumer software, whether it's web conferencing or chat or tools for some of my electronics, etc.
Sandboxing consumer applications would have allowed me to focus my package management efforts entirely on my development environment
It's not great. Sometimes it works well, but when the wiccan magic inside Flatpak breaks now you have to debug two runtimes for the price of one!
As a user I couldn’t care less.
A lot of Linux users grouse about people not wanting to use their favorite OS but they don't do it because a bunch of perfectly well built software may or may not run depending on some under-the-hood voodoo magic they don't understand and can't fix.
Flatpaks fix that. If the pack is well built, it'll work. If it's from a reputable source, it's probably well built.
Snap is much easier to publish and a joy to use with the dashboard and analytics. I hope Flathub improves their submission system and documentation because it's still a mystery to me.
A contemporary app store is a spectacularly awesome middleperson business to be in -- both in revenue, and in anti-competitive power.
From a "how things should be" perspective, both are bad IMO (see my other messages here), but from a purely practical perspective based on my experience with trying to use applications using them, AppImage tends to work slightly better and since it is local only to the application, it doesn't pollute the rest of the system.
If i had to choose, i'd choose none of them, but if i had to choose between the two then AppImage is by far the most preferable.
That doesn't take care of sandboxing, but that seems like it'd be better handled by the OS itself rather than the package management system, and it avoids the problems with overhead and integration that come with things like Flatpak and Snap.
Conceptually no, and both GNUStep and RoxFiler/RoxOS did just that.
The practical reality though was that Linux Desktop has never had a conception of which pieces are 'add-on' and which are 'base-system', and to the extent there was any collection of components that could be part of the latter they were frequently making breaking changes. Combined with no coherent standard for properly versioning libraries and every fiefdom package repo doing its own thing, and what you're left with is decidedly not a platform.
The modern version of Rox AppDirs is AppImage, and it mostly kinda works on most distros. This is sad, but there's just no way out of it as long as the Linux Desktop community continues to reject the very concept of being a platform.
Steam initially tried to solve this for games by just dragging along its own Runtime for developers to target, but there were still issues. They've since regrouped and basically just declared Win32 the one true stable runtime ABI for games on Linux.
FlatPak just decided that yet-another-package-manager was the way to go and manages a collection of explicitly defined runtimes instead. It works well enough for most use cases.
Example, I run Ubuntu and wanted to use a smartcard for authentication in certain websites. That didn't work because Firefox is in a snap, and can not communicate with the pkcs11 libraries...
To solve that I have to scrap Firefox as snap and install as debian package from PPA.
In an ideal world, the application would be Flatpak or Snapcraft aware (or there'd be a middleware to intercept these calls), and ask for access to parts of the system it needs.
And thats what distro packages are for, I guess.
On the other hand, its a security issue, so I supposed some opt in friction is prudent.
[1] https://docs.flatpak.org/en/latest/flatpak-command-reference...
this is like systemd, bunch of people enforce poorly designed product on everyone
linux is becoming a windows bis, and this piss me off
These type of workarounds seems to point to people giving up in having secure applications, so much for the move to rust. So the path is to having applications in a walled garden. But who cares if all the plants in that garden is infested with aphids, at least they can say it won't spread. Well, time will tell on that. But, I hope application developers keep an eye on portability. There is more to the world than Linux.
OpenBSD is avoiding all this complexity of Flatpack, snap, docker and all these attempts at contains. To me, pledge(2) and unveil(2) is far more secure and easier to use than what Linux is doing. And I think for containers, nothing still comes close to FreeBSD jails.