> Wick started his talk by saying that it looks like everything is great with the Flatpak project, but if one looks deeper, ""you will notice that it's not being actively developed anymore"". There are people who maintain the code base and fix security issues, for example, but ""bigger changes are not really happening anymore"". He said that there are a bunch of merge requests for new features, but no one feels responsible for reviewing them, and that is kind of problematic.
I think Red Hat should really be stepping up more here, especially since with RHEL 10 they stopped maintaining a ton of desktop packages with the advice for users of those packages being "get the package from Flathub instead of from us" (see https://docs.redhat.com/en/documentation/red_hat_enterprise_... , search for Flathub). If that's Red Hat's attitude towards desktop software, they should be providing the resources to make Flatpak a viable alternative.
> A user's Linux distribution may still be providing an older version of Flatpak that does not have support for --device=input, or whatever new feature that a Flatpak developer may wish to use. Wick said there needs to be a way for applications to use the new permissions by default, but fall back to the older permission models if used on a system with an older version of Flatpak.
I'm glad he brought that up as a problem. I maintain a game on Flathub that has audio and controller support. Because of the limited permissions granularity, that means that the game is displayed as requiring arbitrary device access (--device=input is too new, so the Flathub maintainers don't allow it in packages yet) and being able to listen to your device's microphone (the audio permission doesn't allow only accessing speakers but not microphones). I hope that Flatpak adds backwards compatibility for permissions so newer Flatpak versions can start having more granular permissions.
Red Hat has since walked some of this back. Firefox and Thunderbird were supposed to go Flatpak only for RHEL 10, but they eventually shipped rpms for GA.
Seems there were a myriad of causes for this including lack of Native Messaging, no ability to deploy policies centrally, and broken integrations with various other parts of the desktop ecosystem.
They walked back Firefox and Thunderbird, but Evolution, LibreOffice, GIMP, Inkscape, and Totem have all been dropped. Red Hat no longer packages an office suite, a raster image editor, a vector image editor, or a media player for RHEL. This means that even people using RHEL as a development workstation or something will have to download software from Flathub if they don't want to use a second computer for all their general office tasks.
Desktop is not a large market for Red Hat. Even their employees mostly use Fedora.
The only place I really see RHEL workstations is in special purpose applications, and in most of those the users either have a separate Windows box, or they Citrix/RDP into the corporate Windows environment to do normal office productivity things anyway.
Ubuntu basically ate their lunch for the desktop case. It used to be that commercial software required SuSE or RedHat on the desktop to get support. But especially RedHat always suffered from the curse of being ancient compared to other desktop distros. When Ubuntu became big enough for commercial software to target, people chose that because Ubuntu was just more recent.
Also, several releases ago, RedHat already started to wind down their desktop efforts, just leaving server/container/cloud as the primary use case for RHEL, with desktops just as "this could also work". That latest decision to drop a lot of desktop related stuff is just a logical continuation of this policy.
Given the target of RHEL, I can’t say that I disagree with their decision to not package those applications for RHEL 10. RHEL isn’t really designed to be a user desktop. Ever since RH split out workstation and server versions of the OS, RHEL has always been targeted for servers. I don’t think the lack of an office suite will really be that impactful towards users.
This is just made all the more true if there is an alternative source for these tools, like Flathub.
> This is just made all the more true if there is an alternative source for these tools, like Flathub.
The point I was trying to make is that Red Hat is deprecating graphical desktop programs on RHEL and telling their customers to switch to getting them from Flathub, while a Red Hat employee giving a talk about the future of Flatpak is saying that it's not actively developed anymore and that there's nobody responsible for reviewing MRs for new features. I'm not saying that it's necessarily a bad thing that Red Hat stopped packaging graphical programs. I'm saying that since they've endorsed Flatpak as their alternative to packaged graphical programs, I wish Red Hat would put some of the development resources they've saved from no longer packaging/supporting those graphical programs into helping to improve Flatpak.
> I wish Red Hat would put some of the development resources they've saved from no longer packaging/supporting those graphical programs into helping to improve Flatpak.
I very much agree with this. It would be nice to see some better coordination and support, especially for those who are able to leverage Flatpaks to reduce their own overhead.
You're right. And that's something I still don't quite understand.
I'd really like to know how many workstation licenses Redhat really sells. It's been so long, I didn't even realize that they still had a separate workstation license available for purchase. When you have the same distribution setup for Servers and Workstations, it seems to me that one of those flavors is going to dominate and the other will be eventually be neglected. Who are the users that are buying and using Workstation licenses?
But, when it comes down to it, I still don't see why they would want to package an Office Suite for RHEL. Or, more importantly, why a user would want to use it. RHEL is designed for stability. It's a great server OS that's well supported. Because of this, it's also known to have older versions of libraries and programs. This is okay, because many new features and fixes get backported, but it's still usually an older (stable) version of software that's included. Why would you want to have an older version of an Office Suite? Why would they want to package a newer (and riskier) version that can be installed on a server? It just doesn't make that much sense to me... it's a fundamental dichotomy between what makes a good server OS vs a good workstation OS.
Note: this give and take has been going on with Linux on the server vs Linux on the Desktop for decades. It's probably going to keep going on for decades. The things that one wants for one use case isn't what makes sense for other use cases. This is why we have different distributions, which is a good thing. The part I don't get is why RH would want to merge the two back together. Which is why I see the idea of deprecating workstation applications (as packaged by RHEL) in favor of Flatpak versions of them as a good thing from the RHEL point of view.
>Who are the users that are buying and using Workstation licenses?
Sometimes institutes and businesses that insist on support contracts, and ones from the vendor publishing the software itself. Sometimes there is actual legal red tape requiring them of such, usually its just management doing management things.
That requirement immediately cuts down the majority of their options, even if what I would describe as more sensible options exist under such a criteria.
Flatpak is probably the best way to distribute desktop apps on Linux. I say this as an app dev, a packager, and a user. At one point I maintained close to a dozen packages.
I eagerly waited for months to see what they would do next - what magical features they would introduce. I was active on the forums helping other users package apps, helped review Flathub submissions (since it was always the same problems each time), and started checking out what PRs were happening. Silence.
The months turned into years, and as more years came, I slowly fell away from engaging with Flatpak. I'm back to using the AUR for most things (Arch, btw), but I'm quite sad to hear the situation get spelt out. Flatpak really was revolutionary; bringing modern apps and painless distribution to all desktops - LTS or rolling release. But it hasn't really changed at all since it first took off years ago.
I have almost never had a good experience with Flatpaks as a user, outside of ease of installation. They almost never integrate with the system properly. Wrong theme, wrong cursors, wrong file picker, permission issues, drag-and-drop issues. You often need extra tools that broaden the permissions of apps post-install because some feature won't work (global push-to-talk in Discord is always fun, especially with Wayland).
I couldn't care less about sandboxing if the UX sucks as a result.
If binary portability wasn't such a complete joke on Linux we wouldn't need Flatpak, but here we are.
I find Appimage to be better alternative to Flatpak: no install, persistent through linux installations, no issues with themes, icons, Xorg config; in practice - take fraction of flatpak storage size, optional sandboxing with external tools like firejail, easier to run from terminal / dmenu / rofi, very easy to tinker with and fix.
There's just one problem: they don't integrate with desktop without an additional application. We need a feature where dropping an AppImage into "~/.local/share/applications" would automatically detect it as a ".desktop" file and make it appear in the DE menus.
> There's just one problem: they don't integrate with desktop without an additional application
Their biggest problem is that they're not actually truly portable between distributions. They're a gamble of what they're compiled and bundled against, and it's possible for two distributions to not have binary compatibility with each other due to user space differences (different versions, compile flags etc). The kernel developers may not break userspace between updates, but userspace developers certainly have no qualms about breaking userspace.
When you head out of Ubuntu/Debian where developers often build AppImages on (because Linux is a neglected platform and when they think Linux they think Ubuntu), they often fail to run or have errors (e.g. on Fedora). There's more problems such as the terrible practice of encouraging people to set the execute flag on binaries they download off the web.
Flatpak avoids the dependency problem entirely because it's uses runtimes and namespace to ensure reproducible and stable runtime environments.
* The RISC OS desktop treats folders whose names begin with a pling (`!`, an exclamation mark) specially. It expects a structure inside with an icon, a launcher script, etc.
* RISC OS also had an "icon bar", a forerunner of the Windows taskbar
* One of the Acorn engineers who worked on RISC OS was head-hunted to NeXT Computer in California. He took his Archimedes with him.
I think the makers of Flatpak, Nix, Guix, and Spack -- https://spack.io/ -- all really ought to take a deep look at ROX, AppImage, and GoboLinux.
What all of these do can be done better, in a more human-readable way, if you throw away ancient UNIX assumptions about filesystem directory hierarchies.
This was mostly not designed and was in historical fact accidental anyway:
This is both a pro and a con. For example, one big downside of this approach is that it can make installing third party plugins and scripts much harder than it should be.
Flatpak does have answers for this stuff but it's more the programs inside them aren't utilizing the right APIs, they are meant to use the portals api for filepickers which would use the system filepicker and securely portal stuff through the sandboxing. But many apps just don't.
Theme is also an odd one. GUI design in general has shifted away from an OS theme and more towards an app/product theme which stays consistent between the product on different platforms. Discord for example looks largely the same on Linux, Windows, iOS, and web.
Even for apps that don't use one of the native toolkits like GTK or Qt, where this has been a solved problem for decades, they should at least respond to a dark/light mode flag if they can. Flatpaks mostly don't.
They don't even have the same cursor as the system a lot of the time. It's especially cool when running display scaling when some apps shrink the cursor to a minuscule size too because of poor system integration.
STEAM on Fedora requires a bunch of incantations on the CLI to get controller support working after Flatpak installation. This pretty much solidifies its flaws as a format. "Table stakes" apps should just work.
To make the best out of flatpak, it's best to think of it as a new sandboxed distribution that lives on your host system. E.g You could check if a specific theme is installable as a flatpak application.
Flatpaks are not perfect and I have my gripes with flatpak but the only alternative is Ubuntu's snaps.
Why do these things not work properly when apps are flatpaks? e.g. if an app tries to query the environment and ask "what's the theme", how would it get a different answer when run from a flatpak?
Different answers for different problems, but basically two reasons.
First, library/software/data versions inside the flatpak can and will be different from the ones outside. So a flatpak might as "what is the current Qt5 theme", and get the answer "don't know about Qt5, but the Qt6 theme is cute-cats-qt6" which it cannot interpret. Things like themes might not even be available inside the flatpak, so even if the answer were parseable, cute-cats-qt6 might just not be available on the inside.
Second, flatpaks are sandboxed, so things will be filtered. This means that a query might not get through, an answer might not get through, both might be altered. Or maybe an answer might be useless because "you can get the theme at /usr/share/themes/cute-cats-qt6" points to a path that the flatpak is not allowed to access.
Maybe a contrived example but shouldn't Qt6 be answering with a compatible answer if a Qt5 app asks it what the theme is? And shouldn't the app be asking what the "theme" is, rather than what the Qt5-theme is? It seems like a fundamental issue with compat between apps built for different versions of Qt more than a problem with flatpak?
And is the sandboxing perhaps going a step too far if apps can't access the things they need from the environment?
You don't need Flatpak at all to have these kind of usability issues, it is deeper than that: For example,
if you mount a samba share in the Linux Mint Cinnamon file explorer it is just good to use it from there. Accessing files from the mounted share from "external" apps is a pita (shares are mounted to some obscure path(permission issues), the apps filepickers never have the information that a share was mounted, etc.).
If you want usesful access to a samba share you have to mount it via terminal; This way at least the path to the share is short.
Most desktop environments / window managers support that portal and stuff like Electron does too, so for example with Slack (installed over Flatpak) in can now toggle mute even If i dont focus Slack.
I feel the same. Like a few years ago Fedora + GNOME + Flatpak was the magic sauce. Not so much anymore. I’m back to Arch as well, which seems as if its package repositories have only grown. The AUR is there but I’m shocked how little I need from it.
In case anyone ever seriously contemplates a new design, here's an anecdote:
Quite a few years ago, when Flatpak was a brand new project, I met some of the original developers. I tried, and failed, to convince them to change one particular fundamental part of the design. In the original design, and today, an installed Flatpak has a name, the permissions are bound to that name, you run that Flatpak and it has its assigned permissions, and, if anything else talks to it, it talks to it by that name. If I install a VSCode Flatpak as my UID and grant it access to my Documents directory, then VSCode, running as me, has access to Documents.
I argued that this was the wrong design. If I install VSCode as me, then there should be an installed copy, and that should have approximately no significance. If I run VSCode, then the running instance should have some id (possibly ephemeral), and that instance should have a set of permissions. If I want to run VSCode with access to ~/project_a and another instance with access to ~/project_b, it should just work and the instances should not be able to access each other's data, even if they're running at the same time. If I want to run two Tailscales, it should work. If I want to fire up an ephemeral instance of Firefox, that should work, too.
However many years later, I still think I was right. Flatpak gets this wrong, MS and Apple's App Stores get this wrong, Mac OS gets this (very very) wrong, etc. There's plenty of opportunity to do better.
(This is important from a bug-mitigation perspective: a LibreOffice document that achieves RCE should not be able to access my other documents. It's also important frmo a vendor-doesn't-care-at-all perspective: VScode has basically no security to begin with, and VSCode inside Flatpak ought to have a degree of real security courtesy of Flatpak.)
You are right, but actually I think you would want to go beyond that and build a hybrid of your approach and their approach:
For your documents, you will usually want your approach. Maybe with some optinal allowance for useful things like a "recently used documents" menu or something.
But for more enviromental things, I would want at least the option of allowing all instances the same access without a lot of permission prompts later on. E.g. my git config, my fonts folder, my code snippets library, stuff like that.
I do think this would be good for power users who want strict isolation between different instances of apps (and I'd also love to see better QubesOS type approaches, using a hypervisor), but perhaps most of this kind of work should be prioritized inside the application itself, using nested sandboxing. That way, the barriers are exactly where the user expects them to be based on the normal behavior of the application. Assuming vulnerabilities in the code that glues it all together don't get explosive, of course.
Web browsers do already use a variety of sandboxing techniques to achieve separation between tabs. Some of these techniques work inside Flatpak, but some of them are broken by Flatpak:
> Ideally, Flatpak would simply support nested namespacing and nested sandboxes, but currently it does not. Flatpak uses seccomp to prevent applications in a sandbox from having direct access to user namespaces.
Some of them are replaced by Flatpak, for application developers that wish to use the APIs:
> What Flatpak does instead, currently, is to have a kind of side sandbox that applications can call to and spawn another Flatpak instance that can be restricted even further
Fortunately, it seems Wick is optimistic about UID namespacing, the main thing stopping Firefox and Chrome from fixing this:
> Wick feels that user namespaces are, nowadays, a well-tested and a much-used interface. He does not think that there is much of a good argument against user namespaces anymore.
Back to the topic of instanced Flatpaks, as I understand one snag is that there is a long-term desire (by app stores/platforms in general) for a full boot-to-userspace code-signing setup to be tied into the sandboxing. The identity of each application should remain the same (unless specifically overridden by a power user) so that a fake version of an application can't adopt an existing application's confidential encrypted files if it doesn't meet the codesigning requirements. I guess one solution here would be for the segregated instances to be nested inside the application's identity, but that's getting quite complex. And we don't even have encryption nor any functioning secure boot + confidential computing implementation yet -- all we really have so far on this front is the reverse domain name notation being verified by Flathub, with filesystem access sandboxing to keep these folders separate.
Yes, that would be better, for specific instances of the running program to have a set of permissions instead. However, I think this is not the only issue.
It is what I had wanted too, not only you.
I think that the entire operating system should need to be redesigned for many reasons (I mentioned before how to design a better one), and it would have that effect, that specific instances of a running program would be given capabilities as arguments (or through other capabilities, but the first ones must be given as arguments), and these capabilities can have restricted permissions, as well as more versatile things e.g. to log access, or to go through a proxy, or to set a disk quota, etc.
Mildly OT but I have longed for this kind of app portability in Android too. Some OEMs like Xiaomi apparently took note a few years back, offering inbuilt app "duplication" features in their OS's but only for a few popular apps like WhatsApp.
Nice breakdown. I'm new to Linux and didn't know about this:
> Flatpak still uses PulseAudio even if a host system uses PipeWire. The problem with that is that PulseAudio bundles together access to speakers and microphones—you can have access to both, or neither, but not just one. So if an application has access to play sound, it also has access to capture audio
I sometimes see Linux users sneering at Windows and Mac design mistakes or lack of “freedom”… but then there’s stuff like this.
Of course, Linux is then conveniently redefined in a way that nobody can be responsible, with finger pointing on every issue, rather than admit design flaws like this plague Linux as a whole.
I get that you already preempted this, but: Flatpack is a weird extra layer on top of Linux. Most distros have package managers that work just fine. These package managers predate Flatpack and basically are the main thing that the distro provides (other than the community, of course).
But those are even worse from this point of view, I have no control over which apps can access my camera, or microphone.
I'm personally disappointed that sandboxing isn't easier in Linux. I hoped it would move past Windows and Mac, imagine a world where the majority of libraries are sandboxed too, we only let compression and decompression libraries read one stream and write to another, this would improve security. This has been done by both Google (in Android) and Apple (in iOS and Mac OS X), but hasn't seen general acceptance in Linux (as far as I can tell).
Because on Linux, everything is based around trusted security since you have access to the sources whereas on iOS and Android, every single app you install could be a malware so those systems are based on untrusted security.
That assumes that there are never zero days or other unpatched vulnerabilities. You should not trust applications because you have access to the source. Nobody is actively auditing the vast majority of open source code, well except of malicious actors who probably have a handful of remotes in a lot of RSS readers, chat apps, microblogging clients, etc., which they can use to compromise activists and journalist naive enough to trust desktop Linux.
A lot of Android vulnerabilities are bugs in open source parsers of untrusted data (open source as in AOSP or more widely used open source libraries). But the impact is smaller because Android has proper security boundaries. If desktop Linux was as popular as Android -- we would have a security disaster of epic proportions.
But in the mean time, I still trust a Linux distribution more than my phone when it comes to my private data.
My Linux distribution doesn't have a built-in advertising id, unknown manufacturer modifications I can't even look at or shady processes which have more power than I do.
I think it's time for the tech community to move beyond just the tech side and understand that security is also a social contract.
In today's world, attacks on your data are much more common than targeted exploits on the kernel so I would put it in opposite order. If there's no privacy then there's no security.
> Irony being that Mac OS X is the best at privacy out of the commercial OS out there.
The bar is very low and OSX is still way below a Linux distribution
Hahaha, oh that is a hilarious attitude, you really believe that F/OSS means that implicit trust can be granted all across the supply chain. That I have access to the source makes a lick of difference in terms of vulnerabilities or exploits that can be found.
Once in college I cited Linus's Law in an impassioned apologia for Open Source. And I was duly corrected. Because Linus's Law really has no basis in reality.
The reason Linux has such a model of blind trust in system services and applications is because it was based on Unix, which had an even more naïve model, because mostly, it was administrators and authorized users installing that stuff, there was more top-down monitoring and control, and just a smaller incidence of naked malice.
It's the same thing we see in earlier versions of Windows, or macOS, or the Internet. Look at the Internet in the mid-90s. Was it secure, with all the open source running on it? Hell naw. Every OS and protocol is vulnerable and attacked, and every OS and protocol revises security models based on modern-day threats. F/OSS saves nobody and mitigates virtually nothing.
To answer the GP, sandboxing has to be bolted-in to Linux after the fact. Linux's POSIX model is so old and needs to be so compatible. The only sandboxing in SVR3 Unix was chroot(2), you know? The Docker support and cgroups and virtualization are all new layers, and need careful integration. Nobody says that F/OSS doesn't need sandboxing. Nobody says that F/OSS is so secure that it can deviate from better-secured models. Quite the opposite.
Android and iOS are clean starts, mostly; didn't need to be backwards compatible, so they're tuned to the latest threat models of adversarial computing as you describe. But every single app you install on Linux could be a malware, too. I have no idea what "trusted security" or "untrusted security" are, but they aren't real terms of art in Cybersecurity, and they do nothing to describe the provenance or evolution of Linux security (which often has a lot of unused mitigations such as AppArmor or SELinux that get turned off right quick.)
This is kind of a sophism, of course it's not perfect (nothing is) but I'll still trust this model over Android or iOS which have a built-in advertising id, manufacturer modifications I can't even look at and shady processes which have more power than I do.
I'm on Ubuntu and mostly use debs (apt), I'll use Snaps if that's the easiest way to get an update. I use Appimages for some ephemeral stuff or when that's the only way developers release it (some 3d printing stuff). I haven't installed Flatpaks at all because it doesn't jibe with the distro overall.
You, kind of, don't have much of a choice. There's thousands of packages and it's a ton of work. In addition, as Linux continues to get more popular, more vendors are releasing software that doesn't care to work with newer libraries, so Flatpack handles this nicely.
I only use Linux on servers, so the kind of stuff I need is always traditional apt-get, but yeah I always assumed using it on a PC would involve tons of snap or flatpak apps where they don't want to deal with the complexities of dependencies.
Ok, I do have one spare Linux laptop in my garage that I barely use, and I'm pretty sure how ever I installed Chromium used snap.
My brother in christ, systemd, x11 and even GNU are weird extra layers on top of Linux. Linux is just the kernel. This is exactly what "redefining Linux so it's never responsible for 99% you need to put on top of Linux to have a functional modern OS" is about.
I explicitly acknowledged that in the other half of the sentence you partially quoted.
I also explained why I thought it was not really right to focus on the deficiencies of Flatpack… so, I’m not sure what the point in repeating that would be. In conclusion,
There sort of is, but you can't do anything with it, because you essentially have no user space utilities?
For all of the crap that people gave the term "GNU/Linux" it's even more true today considering there are Linux-based operating systems that don't use GNU utilities.
gjsman-1000 talks about "design flaws" in Linux above, but Linux is just the kernel. There is no "Linux" operating system, despite everyone, and even Linus probably? using that term.
If you call booting init and getting a black screen "an operating system," well... that's cool I guess.
I doubt Linus ever talks to the GTK people in any meaningful way, or any other desktop environment authors. So, what design flaws?
Do you call a ladder a badly designed scaffold because it doesn't have a horizontal platform? No, it's just something entirely different all together.
"GNU/Linux" can still mean too many different things. Even ChromeOS qualifies as that. You want GNU/Linux help, you need to specify what DE and everything. Or as the other comment said, what Bluetooth stack. You can say you're using Manjaro Cinnamon and either that's not specific enough, or someone says it's your fault for not using KDE.
I'm comparing to Windows or Mac. There's only one Bluetooth audio stack in Windows. If you want help with it, whatever you find online will apply to you, unless of course you've gone out of your way to swap it for another. Unlike Windows, Linux is open and people can build their own flavors, but those can have their own names.
Don't even get me started with how Ubuntu changed its entire GUI like 3 times so that it's unrecognizable each time. Feel bad for whatever IT departments had to keep taking new screenshots of how to do stuff.
…it’s just too bad that Bluetooth stack is one of the worst ever conceived, you have zero options for an alternative, and you still have to get all your help from a volunteer support team.
Bluetooth is hard. But it'd at least be easier if the Linux community weren't maxing out on complexity before even reaching the hardware. Even Windows struggled with drivers for a while.
Yep, and there are (were? It's been a while since I checked) even "distros" of FreeBSD that are specialized for desktop use. The main downside of FreeBSD is that it doesn't dumb itself down to appeal to the masses, so while it's great for experienced users it's a bit painful for newbies.
Last time I used FreeBSD, I found it more inherently user-friendly than Linux distros, mainly because it has a very nice handbook (linked in a sibling comment) with realistic examples. Also seems to have more things built in.
What made FreeBSD harder in the end was just that fewer people use it, so tons of third-party software supports Linux better, and it's easier to find online answers.
Basically, he argues that application distribution outside of the distro (a la flatpak, snap, appimage) is just a bad model. The right model is the one distros have been using for years: You get software through the distro's package manager, and that software is packaged by people working on behalf of the distro. As he says: "Software distributions are often volunteer-run and represent the interests of the users; in a sense they are a kind of union of users."
The other issue, of course, is that in practice flatpaks/snaps/appimages never seem to 100% work as well as distro packages do.
I disagree with that. IMHO the best possible people to create a package for an application are the original developers of that software. If that software is proprietary, that also happens to be the only party that can legally do that anyway. Because it typically requires access to the source code and software redistribution requires permission.
So, the model you mention only works for open source packages. And I would argue that even in the case an app is 100% open source it's a bad idea for somebody not affiliated with the core development team to be second guessing a lot of things about that application.
It results in a lot of issues that aren't necessary. Like needless lag between developers releasing new software and some third party doing whatever uninvited tweaks they think are necessary, or adding their own bugs and new issues.
It's why I always install Firefox in tar ball form straight from Mozilla for example. It updates itself as soon as developers OK some patch. This happens a lot and mostly for security and stability reasons. I want those patches when they release them. The things external distribution maintainers do are redundant. I trust Mozilla to do the right thing and be the most clued in about any issues regarding their own software. With proprietary stuff, I just want stuff to run with a minimum of hassle.
Flatpak is trying to do too many things. It's trying to emulate an appstore. I don't necessarily like app stores. They are gate keepers. What do developers on Windows and Apple do? They put binaries on their own website. You download them. You install them. And then they run. Downloaded apps have the same rights as apps provided via app stores. The app stores don't repackage the app, they merely distribute them. It's an add on service. An optional extra. All the essentials that provide security are baked into the OS and the application package. There are a few mechanisms that windows and mac provide to make things secure. Binaries are signed, the OS has a permission model for things that need that (screen sharing, directory access to certain things, using the webcam, etc). That's the right model. That could work for Linux as well. It shouldn't require taking control of distribution or packaging by some third party.
Flatpak is more of a set of tools and framework. I wouldn't consider it as a store but a distribution system. Flathub is a repository, Fedora has its own repository and anybody can creates its own repo (I wouldn't call it store as there is no concept of monetisation).
I wouldn't consider flatpak as a gatekeeper as there is no "team" going through some arbitrary process to allow/disallow an app.
I also disagree with the fact that macos and windows did the right thing, what I found in my experience managing laptops in a company that is roughly 1/3 windows, 1/3 linux, 1/3 macos is that:
- What windows is teaching users is to download random stuff and bypass the warning screens if something is not signed. Unless there is a company policy and a third party software to update what is installed, by default things installed are a mix of up to date and not update to date software.
- Macos user do not install operating system and software updates unless a third party software is installed and force them too
- Linux users have things up to date, only distribution version updates (e.g. fedora 41 to fedora 42) are inconsistent.
So my take is that, even if things on not perfect with flatpak, rpm/dnf, fwupdmgr and package manager, this is much better than having to pay for third party tools in macos and windows because of the lack of a good way to distribute and maintain apps at the operating system level.
I think that you are right about not depending on one open source OS to provide the proper depencencies, customizaion, and training wheels for every app. I have been running linux on my desktop for about 20 years, about one decade of Mint followed by the same of Fedora so far. Being a curious but fussy guy who installs lots of software to see what works, I find that I need to install a fresh OS about every 18 to 24 months.
There are, I suppose, always a few programs that don't get upated by 'sudo dnf update' but do get bothered by updates to the shared libraries via the same. Perhaps there are some config files that get damaged by software bugs or power outages or system crashes or my own mistakes and carelessness. I also found out that if one loses the dnf program, one will discover just how impossible it is to pull oneself up by oneself's bootstraps.
Mint was a very similar situation. Maybe not so bad for one who follows all the rules, but in those bygone days there were people suggesting that updating Mint programs with newer versions fron the ubuntu or debian repos was a good idea. And because Mint was slow to get updates, I would attempt to update some apps by downloading source and building and installing here.
Last year, when I upgraded Fedora from 39 to 41, was the first time I got any OS upgrade to work instead of wiping the disk, doing a fresh install of the new OS version, and then spending a week or month trying to get my data for the installed apps (eg web browser and email) from backups. But the upgrade took much longer than it should have, because once I started running the upgrade process, I did not know that the computer sitting there dead silent with no action on the screen for about 30 hours was a sign that all was going well. Computers are evil.
The problem is that now you have to package for N distros. And the people who run the distro may not want to spend time on it, so you have to do it yourself.
It doesn't have to be gated by "the people who run the distro". I started packaging a few pieces of software for a distro I use because I wanted to use that software, and I don't "run" the distros in any capacity. Package maintainers aren't born that way, they become that way by volunteering, just like most everything in Linux.
If you don't have even one user willing to do that for the distro they use, you probably weren't going to have users on that distro anyway.
You're saying the exact opposite of the original point, which is: you should not package for distros, distros should package for themselves. You just distribute your sources.
You are a good candidate to package for your distro, so there's that. And then for a random distro, if nobody feels like packaging for it, then it's just not there. Either there is not enough interest in your project, or there is not enough interest in the distro itself.
> distros should package for themselves. You just distribute your sources.
That's how you ended up with Erlang being split into 20+ packages on Ubuntu/Debian in the past. Because it was packaged by people who know little about erlang, and had too much time on their hands probably.
And that is the main issue: you want distro maintainers to compile and package every single pieces of software under the sun, but they can't possibly know every piece of software, how it works, or how it's supposed to work. Times that by the number of distros.
Application developer should be able to package and distribute the app. See how easy it is for casual user to download and install any application on windows. Maintainers cannot scale and depending on them will just hold back Desktop Linux
Flathub is not unvetted. Every submission goes through human review. If a piece of software requires an unnecessary permission (i.e. if someone submits an alarm clock program that requires home folder access and internet access), it will get rejected. If a developer updates their software and changes the required permissions, the update won't get pushed to users until it goes through human review.
Besides this, for open source packages, the code gets built on Flathub's build servers without internet access. The source code associated with a given Flathub package version must be either a specific Git commit (verified with a commit hash) or a release tarball (verified with a sha256 hash). This means that it's always possible to verify that the code a developer publishes corresponds to the binaries being shipped to users. Closed source packages get a big warning on their Flathub pages saying that the program's code is proprietary and not auditable.
With the traditional distro packaging model, the requirements to become a maintainer are stringent and there's human review when a package is added, but there's typically no review after that point. If you'd like a recent example of the drawbacks of this system, see here: https://security.opensuse.org/2025/05/07/deepin-desktop-remo... . After the OpenSUSE security team rejected certain components of the Deepin DE for containing major security problems (including multiple root privilege escalation vulnerabilities), the Deepin maintainer smuggled them in anyway through an innocuous looking package called "deepin-feature-enable" and nobody in the security team noticed for several years. I'm not trying to call out the OpenSUSE security team here, I'm sure they don't have the resources to vet random packages. I'm saying that expecting maintainers to never ship malicious code because they went through the process to become a maintainer is a weakness of the traditional distro packaging model.
They do to some extent in the larger distros, but for proprietary/binary packages they don't have much chance anyway unless they are willing to do some pretty time-consuming forensics.
Plus the app developers at least have some level of accountability. Like when JWZ got into it with Debian (can't link here). You might think you are running XScreensaver from the great Zawinski, but no you are actually running some weird fork from godknowswho, hopefully not Jia Tan.
I'm glad flaptaks are getting more adoption. Application distribution needs to move from distributions because they suck at it. Due to no fault of their own. Developers should have the option to distribute their apps without middlemen.
In fact I’d say they are perfect for distributions to be more stable. E.g. : my issue with Debian have always been that you couldn’t (easily, I know backports existed) have stable system AND fresh software. With Flatpack, you can.
Now I can run my latest user softwares on a stable distribution. That’s pretty cool.
There are still issues of UX. Especially when the app you are using doesn’t have enough permissions to do the job, you have no information about it and when you guess it by yourself, changing this is hard.
I’d expect that Flatpack should allow apps to specifically ask for permissions in real time or when they try to access external resources like in macOS : just expose the APIs but make them wait for user approval.
I've installed flatpak to install VSCode/Codium to have an usable debugger for a Python project I'm working on. After some time tweaking VSCode/Codium trying to get the debbuger to work, just realized flatpak could be the problem. After another considerable amount of time trying different flatpak permissions, realized this is not a good use of my time. Installed the same packages from snap, and everything worked OK.
I've switched to a flatpak-based immutable distro lately. It's great when it works. But so many niceties don't work, and then it feels like my computer is not really the fantastic tool it should be. For example:
- I had to run around with a distrobox running WINE and a bunch of permissions and kludges to run an external tool for Godot
- I gave up on the flatpak for Firefox because it can't talk to my KeepassDX flatpak
- The Godot and Krita flatpaks are oddly unstable and crash more than they did on Windows (may just be Gnome or something)
- non-flatpak tools like AppImages and .rpms feel pretty dang grungy
I want to see more cool stuff with Flatpak so seeing the state it's in is kind of a bummer.
Years ago, I wrote an on-screen display (OSD) in Java for showing keypresses and mouse clicks[1]. Someone thought a flatpack would be useful[2]. I didn't see the point. It meant: (a) maintaining two installation processes; (b) collating download stats from two sources; (c) trusting a third-party system to maintain package indexes over time[3]; (d) adding yet another package manager to a system that already has a package manager; and (e) bloating the repo with another repo.
- Easy use on immutable distros
- The user doesn't have to make sure they have the right version of Java installed
- Auto-updates even if there is no repo for your specific distro
And also you can find it through searching on Flathub I guess
> And also you can find it through searching on Flathub I guess
Did you click the third link I posted, which searches Flathub for KmCaster only to come up dry? This was point (c): You have to trust that their search engine is correct, maintained, and updated. That doesn't come for free, it takes effort, and things go wrong.
It still isn't possible to package Tailscale or anything that creates a virtual interface as a Flatpak because there is no permission for that. macOS has an API to ask for permissions to add an interface/change routes.
Thanks to said API, Tailscale on MacOS is even distributed as a sandboxed app through the Mac App Store [1]. Flatpak's restrictions make certain classes of software difficult to use on "atomic" Linux distros like Silverblue or Bluefin that provide a read-only base system and expect users to get their software through Flatpak.
I daily drive an immutable Fedora spin and if I wanted to install Tailscale I would most likely add it to the base image via `rpm-ostree` instead of trying to reach for Flatpak - not because i'm aware of the issues but because it makes more sense to me to add a more system-wide networking layer to the base image.
That being said there are many apps that are not packaged as Flatpaks that I end up adding to the base layer out of necessity which I would have liked to use as Flatpaks.
> It still isn't possible to package Tailscale or anything that creates a virtual interface as a Flatpak because there is no permission for that.
It's possible but not ideal. The application could use flatpak-spawn (to get out the sandbox) and then polkit-exec (to ask user for root perms for arbitrary use) to get root privileges on the host, but you're removing nearly all sandboxing.
I'm not sure I'd install tailscale as a flatpak even if it were possible. I've always seen flatpak as a way to install large, potentially crappy desktop applications without polluting your system. OBS studio is a perfect example - it's a great app but it's the only one I use that uses QT, thanks to flatpak I don't even have the QT libraries installed on my system.
Tailscale is more like a system service that I'd prefer a distro package for (Arch Linux repos contain Tailscale, btw).
You don't have QT libraries installed on your system. You just have then in some archive somewhere along with a bunch of copies of stuff you do already have installed on your system.
Im not really much of a flatpak user but to me it seems like permission system on top of Linux is an incredible undertaking. Solving both packaging and retrofitting permissions at the same time seems too big of a cookie to swallow. I don’t know whether the permission system is what killed the momentum and caused this seeming burnout. But it seems incredibly complex.
To me, Linux doesn’t have a granular modern permission system, and I don’t expect my package manager to solve it for me. I still run proprietary software on it, because I kind of have to. Is that an ideal situation? No. But I rather have a distribution system and vet vendors (which I’m doing anyway) than wait another decade for permissions to be perfect. Distribution, packaging and updates is the pressing need imo.
I'm not an open source maintainer or even a dev, but it seems bonkers to me that with all the numerous distributions out there, all facing the same problem of package management, that they couldn't just refocus their combined efforts toward improving Flatpak and guiding it toward universal adoption.
I'm currently using Slackware current. I use an approach of compiling from source or using AppImage. Things like Flatpak and Snaps are an opaque black box to me.
I have AppImages for things like Zoom, KeePass and LibreOffice. I don't need to keep updating them. They do what I want them to do. I have them on a separate partition. If I reinstall my system they're all ready to go out of the gate.
It's ridiculously simple.
I did try out Fedora awhile ago, but decided it wasn't for me. Why is everything a Flatpak? Just use the repo mechanism.
Same system with me. Running gentoo without systemd or pulseaudio makes Flatpak and Snap totally nonstarters. I compile most of my stuff from gentoo's official repos and supplement things with select AppImages that work out of the box, curiously well.
Never understood the point of flatpak, snap and the like. Can't you just distribute static binaries? They are not that hard to compile.
(I mean, from the distributing point of view. The sandboxing and resource management is a OS-thing that should be an orthogonal issue. Users must be able to sandbox programs that they don't trust, regardless to how they are packaged and distributed.)
I did not find packaging up an AppImage that is actually compatible across distro's and version all that straightforward, and we were not even using Qt or GTK/libadwaita. How is this easy, in your experience?
Both flatpak and snap have been a bane with inconsistent behaviors, permissions bugs, and a bunch of stuff I never figured out. I got so frustrated with them that I wiped, put Debian on and just the old package systems.
I'd largely agree. Snap was what drove me away from Ubuntu, after the calculator app started taking ages to load. The calculator! It was instant before snapification.
I have played with using FlatPak, and while it seems snappier than snap, I always ended up with something not quite working, because of permissions or sandboxing. The answer to a lot of problems seemed to be "don't use the FlatPak version".
The set of software I use complex enough to need something like FlatPak while also not needing to interact with other things is basically very, very small.
I've been using Fedora 41 about half a year, and flatpak has not made it better.
Fedora 41 started with a bunch of apps distributed as rpm, but some of them have since been updated as flatpaks when I run 'sudo dnf update'. Splendid, except that the rpm apps, now a little out-of-date, are not deleted, which may be good or bad, but that explains why I have duplicate icons for the same app all over my desktop, and its pretty confusing trying to tell which is which, which is better, or how to manage the all the differences and conflicts, which Fedora 41 makes anything but scrutable.
The thing about the microphones and speakers getting tangled up, as explained in TFA, also was somethig of and for which I was unaware and unprepared respectively when I had some problem with the old-fashioned way and decided to install musescore as a flatpak.
I've been thinking about upgrading to Fedora 42, but this article is giving me considerable premonitions of additional inconvenience and incidental despair. Anyone
have this stuff under control?
I use NixOS and Flatpak I found is the easiest way to install and update applications. The Nix model is great for system software, but not an ideal way of updating and installing desktop apps.
The only problem I've had is fonts installed system wide not being available in the sandbox, but this is due to how NixOS exports fonts and can be solved by telling NixOS to publish fonts in /usr/share/fonts.
Linux has the worst software distribution model towards the general public of all OS. The one of windows (and probably MacOS but I don't know much) is also full of issues, but is still infinitely better than linux. When you compound the number of distributions, the number of their versions, the number of software, and their versions, you realize that having the distribution managed by the distribution or the software authors is unsustainable. In comparison, windows and mac only require at most 2 versions of the software each to reach at list 90% of the users.
I don't know if flatpak or appimage or whatever are a solution, and I cannot propose one myself. But I really think that at one point the linux model will completely fail if it doesn't improve
BTW I'm not saying that the linux model is always inferior. Actually it is often superior: in the server world were professionals take care of things, in the embedded world where the resources are scarce, the possibilities to configure and select everything to the smallest detail make it great.
Flatpak’s biggest bug isn’t in the code, it’s the bus factor.
> Tons of features are stuck in merge-request limbo because there just aren’t enough reviewers, and if we don’t swap some “+1”s for actual PR reviews (or funding), we’ll be shipping apps in 2030 with a sandbox frozen in 2024 while everything else rides OCI.
It's too complex. An application format shouldn't need to rely on 5 different APIs to be secure. And the apps aren't portable. I think something like WebAssembly is going to be the way forward.
I hope you're right. But how is WASM going to answer questions like "how does the application play sound?" or "how does the application request a password from the system keychain?"
WASM solves a lot of problems, but I don't think its chances of providing a uniform API to things like that are any better than Snap/Flatpak's, because those problems are fundamentally not about the runtime/packaging system. They're caused by OS functionality being a fragmented and moving target. Directly executable applications have to deal with those complexities themselves. Containerized applications in WASM/Docker/Snap/Flatpak/whatever rely on the container layer to do it. But someone's software has to chase that moving target, and it moves very fast.
Biggest problem with flatpak for me is that it's not suitable for server-side software, which is well supported in Snap. Is that even planned at some point?
Is there an active Flatpack community that is actually interested in it, in the same way communities form around distros and their repos? It seems like probably no…
I dunno. So far my experience with these third party store things (or whatever) is that occasionally Firefox gets switched to a Snap, requiring active intervention and possibly nuking my profile is I do it wrong. It is… pretty annoying.
If a packaging mechanism, respecting virtualisation had been capable of existing 30 years ago we'd have one. Now, given how the fracture lines run, we're fated to have three or more.
It's pythons virtual environment and pip-is-weak problem, magnified. It's homebrew or Mac ports or fink or pkgsrc.
Mechanisms designed after fork, are never fork neutral.
I see the real utility these tools are providing to many folks, but ...
It just feels so ugly. Square peg meets round hole.
We built all these tools for defining security boundaries for user-installed applications, and it turned out that the Linux packaging/distribution landscape was such a wasteland that people spent a lot of time duct taping software distribution artifact reproducibility onto the security-boundary tools.
So now we're in this weird worst-of-all-worlds spot:
The simplicity, performance, and decades of work we spent to make it easy to develop powerful applications that run directly on userland is now bifurcated/trifurcated and a mess. The legibility of "I want to run an application that dynamically links a cryptography library; that library is provided by the distro and I know it is both patched and compatible with the rest of the distro" or "my application can access files/devices at /path/to/whatever and use those resources if it has permission to do so" is buried under tons of container indirection.
Meanwhile, as TFA explains in detail, the actual security/encapsuation boundaries that these tools were originally built for proved to be a fast-moving target for which tons of support is still missing years later.
We can see the possibilities of what could have been in other systems. Take BSD's pledge(2) for example: its approach is so aggressively oriented towards only solving the security problem that I can't really imagine a world where the pledge/capability system "grew" a packaging/distribution ecosystem the way Snap and Flatpak did. Or take plan9's approach: perhaps if we had modeled the entirety of the OS in such a way that the basic SysV permissions model (users, groups, files, permissions) covered as much as possible of applications' security sandboxing needs, then things like SElinux/snap/flatpak wouldn't have ended up being necessary.
The biggest thing that got us into this state wasn't the tools, though--it was the human stuff: the tensions between "distro/package repo maintainers are burnt out and want to support a relatively small number of dependency targets and ways to add things to the package graph on a given OS"; "app developers want to make complex software available to users as quickly as possible"; and "users are very willing to do insecure things to get new applications to run, but are generally unwilling to do complex things (configure/make, customize AUR sources, know what nix is) in order to install stuff".
Fast forward a few years, add a lot of false starts and other bullshit due to dueling desktop environments/compositors/audio systems, and where we ended up is not good.
The current situation is basically:
"Come on down to DLL hell but way worse, we have: tons of brittleness when apps want to talk to the rest of the OS (sucks for users--but only when apps need rare and advanced functionality like ... uuuh basic audio playback), all baked into highly complex container systems (sucks for application authors) aimed at delivering apps that each package their own look/feel/OS integrations (sucks for distro maintainers and consistency of UX) in massive "it's not actually static linking, I promise" images, each of which contains 75% of an OS, running on leaky isolates (sucks for the security patchers) with an update story of "just download the universe again" (sucks for bandwidth/CDN costs)."
Like, I understand how we got here. I get that it's better than the bad old days of "but which autoconf?"/"I just wanted to update my browser but then glibc-2.11-compat-compat-compat-but-for-real-this-time-FINAL updated and broke my bootloader". And I get that some of those areas might improve over time (e.g. OCI images help with redownload-the-world; eventually Wayland will percolate around and the container runtime X compositor geometric complexity explosion will die down; someday someone will finally fix universal D-Bus discoverability and security for the eighteenth time...).
But overall it is and will remain a mess at a fundamental, philosophical level. Seems like the Linux ecosystem did this in a maximally slow and fragmented way, which is nothing new. But it sucks to see such an "everyone loses" end state as the result.
I think D-bus has many problems and isn't very good. I also think the sandboxing (of Flatpak and other systems) has problems, e.g. lack of some kinds of permissions (e.g. permissions that depend on command-line switches, permissions to execute user-specified external programs by popen (without the restrictions affecting them too), and more), inability to properly use character encodings, etc. There are other issues as well, even though I think that the sandboxed execution is not a bad idea in general.
Great, after bringing Pulse (+ Limewire to fix it), systemd, wayland, dbus, flatpak to dilute and overcomplicate everything, RHEL is now abandoning the desktop alltogether. Meanwhile, zero new desktop apps have been created for Linux in like two decades. Today even Firefox on Ubuntu and Fedora can't access a webcam for teams/gmeet because of permission problems of layered container frameworks that are there just to protect fictional, as in non-existant, apps from accessing your damn files. Seriously, the only way out and where progress has been made seems to be embracing win32 apps using wine/proton, but maybe using SteamOS/Arch instead since bazzite is based on fedora.
If not Flatpak, what is the future for portable sandboxed applications on Linux? I would love a solution where I can run semi-trusted or untrusted applications (e.g. vscode+extensions) confident that it doesn't have uncontrolled access to whatever my userid privileges permit.
it was really for cross-distro GUI desktop applications. I saw it's used in embedded linux projects that has no GUI, for its portability at a heavy price(flatpak is quite fat, it needs to install a full sandbox)
I chose flatpak some time ago over snaps for gui apps and I don't remember why. I think there are benefits to packaging software this way (especially for immutable OS images) but at the same time there are so many negatives too. I hope they make it more of a priority. Or something better comes out on top.
I'd be more worried about Fedora Silverblue and Kinoite, its variants which rely on Flatpak more, as their point is to experiment with a minimal immutable base OS with every user facing app installed as a Flatpak on top.
As long as Red Hat wants to stay in business selling RHEL, Fedora as a distribution is probably not going away nor losing development focus.
Interesting read. While Flatpak does work nicely for a lot of things, the downsides are real and have me almost preferring Snap for the most part. Flatpak terminal apps are annoying, the permissions thing is annoying, sound, etc...
Interesting that the creator is thinking about the next thing already.
They could have been good, but they chose not to go down this route. This is one area Snap shines. Flathub rejects terminal only apps for this reason as well
Yet, there are a select few non-gui flatpaks.
One I use frequently is Zola [0], a static site generator that I use because it's significantly faster in building my site with 'zola serve' than the native Alpine Linux package. All I had to do to make it convenient was aliasing flatpak run org.getzola.zola to zola.
Over here in Windows land I can’t fathom why you need something like Flatpak just so users can reliably launch and run a program. I mean trust me I understand that Linux is so broken it needs something like flatpak. But imagine saying you’re disappointed the Windows executable format isn’t evolving! Running an exe shouldn’t require decades of maintenance. It shouldn’t be that complicated. It doesn’t have to be.
> Running an exe shouldn’t require decades of maintenance. It shouldn’t be that complicated. It doesn’t have to be.
What do you think is all that stuff in C:\Program Files, C:\Program Files (x86), c:\Windows\System, C:\Windows\System32, C:\Windows\SysWOW64, %USERPROFILES%\%APPDATA%\Local and %USERPROFILE%\%APPDATA%\LocalLow or the seven versions of the C/C++ VS Redistributable you have installed?
in reality a bunch of stuff no user ever has to look at. On Windows literally anyone can click on a 20 year old executable and in all likelihood it just works because the good people at Microsoft care about giving the user a decent supply of libraries and stable ABIs and an actual operating system people can build against.
The Linux world is just in complete shambles in this regard. You build something on one LTS release, you don't know if it executes on the next. As the joke goes (it isn't even really a joke), it's so bad that Win32 is the only stable ABI on Linux
Thing is, .exe on windows is broken on so many levels.
You don't have sandboxing, apps don't always follow standards as to where to store their data, there's no dependency management but if you don't have the correct version of e.g. java installed your app won't work. Etc.
Honestly, you have a point. At one point there was a proposal for a "Linux Standard Base", but none of the distros really cared (they had their special sauce), so it withered. If Linux app devs could target "LSB-2020" or something, it could be similar to Windows devs targeting a particular Windows version. Flatpak is basically a work-around to the distributions.
(Note that Windows also does vitalization for compatibility reasons.)
On another level, maybe it's just "in the name". Windows lets you run your GUI windowing programs, and that all keeps working. GNU/Linux lets you run 1990 base industry standard API programs, all that keeps working, but for anything else, all bets are off.
It still irks me that AppImages (the unambiguously superior choice) are not more successful than Flatpak or Snap solely because Linux users (in their characteristic laziness) are only used to getting their software from monolith stores and repositories.
For a long time, there was a pax debiana in my world. I used Ubuntu mostly (swapped to Debian and added Fedora towards the end) and the package management was really good. APT was a great tool and I got quite chummy with its ways. It was straightforward to keep my system updated and resolve dependencies. It was way smoother than any other updater system had been, even across major system upgrades.
I sort of lost it when snap started usurping stuff. I knew it was coming, because docker was already making inroads. Then we had flatpak and company. As an admin, as a system architect, I felt that's the point when I lost control of my system. It wasn't possible to know its update state anymore. It wasn't possible to centrally manage or monitor those updates. It became a free-for-all of self-updates and shadow updates. Ubuntu was also introducing livepatch and kernel updates that went outside the apt model.
I think that perhaps it became too great a burden for the major distros to be packaging all of their own downstream packages. Perhaps they saw the opportunity to offload some of that packaging burden on a really pro service that could just package everything, and make pan-distro packages available. If Debian and RHEL packagers are doing less downstream packaging, then perhaps they could focus on their core competencies. I noticed that nearly every Ubuntu package needed to include Ubuntu-specific tweaks, and basically when Ubuntu was already downstream from Debian, why should Canonical be maintaining every damn package themselves as well?
So what's the endgame for all this? Would apt or dnf/rpm eventually get abandoned and have them go all-in on a new system? Or does the proliferation and splintering continue? Many of us said that the beauty of Linux is our freedom of choice. Well there's too much choice. Look at Distrowatch and be paralyzed by not knowing what to choose. Windows or macOS on your desktop is easy to choose because there's... one of each.
When I visited Catalonia my friend took me to Carrefour. We strolled the aisles and I spotted pig-legs (jamon serrano) on every counter. A huge selection of eggs. Everything my stomach could desire. She led me into the olives aisle and gestured around to all the olives there. She said pick whichever I want. There were so many. They were all in fancy jars. I knew nothing of olives. I left without choosing any.
Linux will die a death of a thousand cuts, until some consolidation and unification can happen that's beyond the kernel.
>APT was a great tool
you had me up until this bit lol
apt's spaghetti of software and state assumptions is horrendous. the software itself functions mostly fine for those who havent used more modern package managers, but the user experience itself is a nightmare as soon as you start needing anything outside the distro's default repos
Look, no illusions or exaggerations here; APT is an imperfect tool and it's intricate, complex and unwieldy sometimes. But please consider the status quo ante. I've run Minix-286, OpenBSD, NetBSD, SunOS, HP/UX, and Linux, and in the years between 1990-2003, there were zero package managers in use.
Like literally APT did not exist, no predecessor existed, there was absolutely no package management for those systems. Or if there was, it was by script or some bespoke framework that came with the app you downloaded. There was 100% no system-wide management of what was installed on my computers.
I've been in states of recompiling the kernel from source. I've run those "./configure" scripts that came with GNU. I've fiddled with custom kernel configuration files and Tripwire databases that tried to keep track of everything there. I've applied patches issued by Sun Microsystems.
Absolutely none of that above jumble can hold a candle to the way we use APT today. I'm sorry you suffered nightmares and needed 3rd-party stuff. But it was a dream come true to type out a one-liner and have the system upgrade itself, accounting for all dependencies, replacing all necessary files, being aware of all config updates, leaving audit trails and versioned files. Simply like falling off a log at this point.
Who would ever go back? What can be simpler? It was simply the degrading of this unified control and the loss of a singular point of management that has begun to dismay us.
> Wick started his talk by saying that it looks like everything is great with the Flatpak project, but if one looks deeper, ""you will notice that it's not being actively developed anymore"". There are people who maintain the code base and fix security issues, for example, but ""bigger changes are not really happening anymore"". He said that there are a bunch of merge requests for new features, but no one feels responsible for reviewing them, and that is kind of problematic.
I think Red Hat should really be stepping up more here, especially since with RHEL 10 they stopped maintaining a ton of desktop packages with the advice for users of those packages being "get the package from Flathub instead of from us" (see https://docs.redhat.com/en/documentation/red_hat_enterprise_... , search for Flathub). If that's Red Hat's attitude towards desktop software, they should be providing the resources to make Flatpak a viable alternative.
> A user's Linux distribution may still be providing an older version of Flatpak that does not have support for --device=input, or whatever new feature that a Flatpak developer may wish to use. Wick said there needs to be a way for applications to use the new permissions by default, but fall back to the older permission models if used on a system with an older version of Flatpak.
I'm glad he brought that up as a problem. I maintain a game on Flathub that has audio and controller support. Because of the limited permissions granularity, that means that the game is displayed as requiring arbitrary device access (--device=input is too new, so the Flathub maintainers don't allow it in packages yet) and being able to listen to your device's microphone (the audio permission doesn't allow only accessing speakers but not microphones). I hope that Flatpak adds backwards compatibility for permissions so newer Flatpak versions can start having more granular permissions.
Red Hat has since walked some of this back. Firefox and Thunderbird were supposed to go Flatpak only for RHEL 10, but they eventually shipped rpms for GA.
Seems there were a myriad of causes for this including lack of Native Messaging, no ability to deploy policies centrally, and broken integrations with various other parts of the desktop ecosystem.
They walked back Firefox and Thunderbird, but Evolution, LibreOffice, GIMP, Inkscape, and Totem have all been dropped. Red Hat no longer packages an office suite, a raster image editor, a vector image editor, or a media player for RHEL. This means that even people using RHEL as a development workstation or something will have to download software from Flathub if they don't want to use a second computer for all their general office tasks.
Desktop is not a large market for Red Hat. Even their employees mostly use Fedora.
The only place I really see RHEL workstations is in special purpose applications, and in most of those the users either have a separate Windows box, or they Citrix/RDP into the corporate Windows environment to do normal office productivity things anyway.
About ten years ago I worked in a bioinformatics lab. All the work machines were centrally managed RHEL machines. I guess it's different now?
Ubuntu basically ate their lunch for the desktop case. It used to be that commercial software required SuSE or RedHat on the desktop to get support. But especially RedHat always suffered from the curse of being ancient compared to other desktop distros. When Ubuntu became big enough for commercial software to target, people chose that because Ubuntu was just more recent.
Also, several releases ago, RedHat already started to wind down their desktop efforts, just leaving server/container/cloud as the primary use case for RHEL, with desktops just as "this could also work". That latest decision to drop a lot of desktop related stuff is just a logical continuation of this policy.
Given the target of RHEL, I can’t say that I disagree with their decision to not package those applications for RHEL 10. RHEL isn’t really designed to be a user desktop. Ever since RH split out workstation and server versions of the OS, RHEL has always been targeted for servers. I don’t think the lack of an office suite will really be that impactful towards users.
This is just made all the more true if there is an alternative source for these tools, like Flathub.
> This is just made all the more true if there is an alternative source for these tools, like Flathub.
The point I was trying to make is that Red Hat is deprecating graphical desktop programs on RHEL and telling their customers to switch to getting them from Flathub, while a Red Hat employee giving a talk about the future of Flatpak is saying that it's not actively developed anymore and that there's nobody responsible for reviewing MRs for new features. I'm not saying that it's necessarily a bad thing that Red Hat stopped packaging graphical programs. I'm saying that since they've endorsed Flatpak as their alternative to packaged graphical programs, I wish Red Hat would put some of the development resources they've saved from no longer packaging/supporting those graphical programs into helping to improve Flatpak.
> I wish Red Hat would put some of the development resources they've saved from no longer packaging/supporting those graphical programs into helping to improve Flatpak.
I very much agree with this. It would be nice to see some better coordination and support, especially for those who are able to leverage Flatpaks to reduce their own overhead.
> Ever since RH split out workstation and server versions of the OS
Didn't that get undone with RHEL 8?
You're right. And that's something I still don't quite understand.
I'd really like to know how many workstation licenses Redhat really sells. It's been so long, I didn't even realize that they still had a separate workstation license available for purchase. When you have the same distribution setup for Servers and Workstations, it seems to me that one of those flavors is going to dominate and the other will be eventually be neglected. Who are the users that are buying and using Workstation licenses?
But, when it comes down to it, I still don't see why they would want to package an Office Suite for RHEL. Or, more importantly, why a user would want to use it. RHEL is designed for stability. It's a great server OS that's well supported. Because of this, it's also known to have older versions of libraries and programs. This is okay, because many new features and fixes get backported, but it's still usually an older (stable) version of software that's included. Why would you want to have an older version of an Office Suite? Why would they want to package a newer (and riskier) version that can be installed on a server? It just doesn't make that much sense to me... it's a fundamental dichotomy between what makes a good server OS vs a good workstation OS.
Note: this give and take has been going on with Linux on the server vs Linux on the Desktop for decades. It's probably going to keep going on for decades. The things that one wants for one use case isn't what makes sense for other use cases. This is why we have different distributions, which is a good thing. The part I don't get is why RH would want to merge the two back together. Which is why I see the idea of deprecating workstation applications (as packaged by RHEL) in favor of Flatpak versions of them as a good thing from the RHEL point of view.
>Who are the users that are buying and using Workstation licenses?
Sometimes institutes and businesses that insist on support contracts, and ones from the vendor publishing the software itself. Sometimes there is actual legal red tape requiring them of such, usually its just management doing management things. That requirement immediately cuts down the majority of their options, even if what I would describe as more sensible options exist under such a criteria.
This one hits close for me.
Flatpak is probably the best way to distribute desktop apps on Linux. I say this as an app dev, a packager, and a user. At one point I maintained close to a dozen packages.
I eagerly waited for months to see what they would do next - what magical features they would introduce. I was active on the forums helping other users package apps, helped review Flathub submissions (since it was always the same problems each time), and started checking out what PRs were happening. Silence.
The months turned into years, and as more years came, I slowly fell away from engaging with Flatpak. I'm back to using the AUR for most things (Arch, btw), but I'm quite sad to hear the situation get spelt out. Flatpak really was revolutionary; bringing modern apps and painless distribution to all desktops - LTS or rolling release. But it hasn't really changed at all since it first took off years ago.
I have almost never had a good experience with Flatpaks as a user, outside of ease of installation. They almost never integrate with the system properly. Wrong theme, wrong cursors, wrong file picker, permission issues, drag-and-drop issues. You often need extra tools that broaden the permissions of apps post-install because some feature won't work (global push-to-talk in Discord is always fun, especially with Wayland).
I couldn't care less about sandboxing if the UX sucks as a result.
If binary portability wasn't such a complete joke on Linux we wouldn't need Flatpak, but here we are.
I find Appimage to be better alternative to Flatpak: no install, persistent through linux installations, no issues with themes, icons, Xorg config; in practice - take fraction of flatpak storage size, optional sandboxing with external tools like firejail, easier to run from terminal / dmenu / rofi, very easy to tinker with and fix.
There's just one problem: they don't integrate with desktop without an additional application. We need a feature where dropping an AppImage into "~/.local/share/applications" would automatically detect it as a ".desktop" file and make it appear in the DE menus.
> There's just one problem: they don't integrate with desktop without an additional application
Their biggest problem is that they're not actually truly portable between distributions. They're a gamble of what they're compiled and bundled against, and it's possible for two distributions to not have binary compatibility with each other due to user space differences (different versions, compile flags etc). The kernel developers may not break userspace between updates, but userspace developers certainly have no qualms about breaking userspace.
When you head out of Ubuntu/Debian where developers often build AppImages on (because Linux is a neglected platform and when they think Linux they think Ubuntu), they often fail to run or have errors (e.g. on Fedora). There's more problems such as the terrible practice of encouraging people to set the execute flag on binaries they download off the web.
Flatpak avoids the dependency problem entirely because it's uses runtimes and namespace to ensure reproducible and stable runtime environments.
For desktop integration you can use Gear Lever https://github.com/mijorus/gearlever. It can also update AppImages with some configuration changes.
> I find Appimage to be better alternative to Flatpak
Me too.
But there is a "bigger picture" view of this which I think is important and relevant:
* AppImage encapsulates apps' requirements using the app bundle format from the ROX desktop: https://rox.sourceforge.net/desktop/
* ROX borrowed the idea of app bundles from Acorn's RISC OS, which is still aroiund and is FOSS now: https://www.riscosopen.org/content/
* The RISC OS desktop treats folders whose names begin with a pling (`!`, an exclamation mark) specially. It expects a structure inside with an icon, a launcher script, etc.
* RISC OS also had an "icon bar", a forerunner of the Windows taskbar
* One of the Acorn engineers who worked on RISC OS was head-hunted to NeXT Computer in California. He took his Archimedes with him.
Source: an interview I arranged: https://www.theregister.com/2022/06/23/how_risc_os_happened/
* About a year later, Steve Jobs demonstrated NeXTstep 0.8 with a Dock
* NeXTstep also has app bundles, demarked by a folder called $NAME.app instead of !$NAME
This is a pervasive and influential idea. It's how macOS apps work and that can be traced to RISC OS.
NeXT style bundles are available and work on Linux if you have GNUstep. There are 2 extant GNUstep desktops:
https://onflapp.github.io/gs-desktop/index.html
https://github.com/trunkmaster/nextspace
But there is a distro which takes this idea much further and packages the _entire Linux OS_ in app-bundle directories:
https://gobolinux.org/
I think the makers of Flatpak, Nix, Guix, and Spack -- https://spack.io/ -- all really ought to take a deep look at ROX, AppImage, and GoboLinux.
What all of these do can be done better, in a more human-readable way, if you throw away ancient UNIX assumptions about filesystem directory hierarchies.
This was mostly not designed and was in historical fact accidental anyway:
https://lists.busybox.net/pipermail/busybox/2010-December/07...
I disagree. Flatpak pros:
- installing: easy to locate, install and has centralized management for updates.
- flatpaks are also persistent. User-installs are in the home dir.
- sandboxing built-in.
Can't comment on other stuff. Haven't had issues.
sandboxing built-in
This is both a pro and a con. For example, one big downside of this approach is that it can make installing third party plugins and scripts much harder than it should be.
on Ubuntu you can integrate Appimages with AppImageLauncher.
https://www.omgubuntu.co.uk/2022/10/appimagelauncher-install...
Flatpak does have answers for this stuff but it's more the programs inside them aren't utilizing the right APIs, they are meant to use the portals api for filepickers which would use the system filepicker and securely portal stuff through the sandboxing. But many apps just don't.
Theme is also an odd one. GUI design in general has shifted away from an OS theme and more towards an app/product theme which stays consistent between the product on different platforms. Discord for example looks largely the same on Linux, Windows, iOS, and web.
Even for apps that don't use one of the native toolkits like GTK or Qt, where this has been a solved problem for decades, they should at least respond to a dark/light mode flag if they can. Flatpaks mostly don't.
They don't even have the same cursor as the system a lot of the time. It's especially cool when running display scaling when some apps shrink the cursor to a minuscule size too because of poor system integration.
I don't think there was ever a standardised way to publish whether the system was in light or dark mode until the last few years.
If the apps inside need to be specifically coded for it, then why is it "marketed" as a way to sandbox currently existing apps?
STEAM on Fedora requires a bunch of incantations on the CLI to get controller support working after Flatpak installation. This pretty much solidifies its flaws as a format. "Table stakes" apps should just work.
To make the best out of flatpak, it's best to think of it as a new sandboxed distribution that lives on your host system. E.g You could check if a specific theme is installable as a flatpak application.
Flatpaks are not perfect and I have my gripes with flatpak but the only alternative is Ubuntu's snaps.
Why do these things not work properly when apps are flatpaks? e.g. if an app tries to query the environment and ask "what's the theme", how would it get a different answer when run from a flatpak?
I don't actually know but I guess the issue is that the theme/gui libraries are sandboxed too
Different answers for different problems, but basically two reasons.
First, library/software/data versions inside the flatpak can and will be different from the ones outside. So a flatpak might as "what is the current Qt5 theme", and get the answer "don't know about Qt5, but the Qt6 theme is cute-cats-qt6" which it cannot interpret. Things like themes might not even be available inside the flatpak, so even if the answer were parseable, cute-cats-qt6 might just not be available on the inside.
Second, flatpaks are sandboxed, so things will be filtered. This means that a query might not get through, an answer might not get through, both might be altered. Or maybe an answer might be useless because "you can get the theme at /usr/share/themes/cute-cats-qt6" points to a path that the flatpak is not allowed to access.
Maybe a contrived example but shouldn't Qt6 be answering with a compatible answer if a Qt5 app asks it what the theme is? And shouldn't the app be asking what the "theme" is, rather than what the Qt5-theme is? It seems like a fundamental issue with compat between apps built for different versions of Qt more than a problem with flatpak?
And is the sandboxing perhaps going a step too far if apps can't access the things they need from the environment?
You don't need Flatpak at all to have these kind of usability issues, it is deeper than that: For example, if you mount a samba share in the Linux Mint Cinnamon file explorer it is just good to use it from there. Accessing files from the mounted share from "external" apps is a pita (shares are mounted to some obscure path(permission issues), the apps filepickers never have the information that a share was mounted, etc.). If you want usesful access to a samba share you have to mount it via terminal; This way at least the path to the share is short.
Many of the problems you mentioned are already resolved though.
For example "global push-to-talk in Discord is always fun, especially with Wayland" was solved by using the [Global Shortcuts Portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.fr...).
Most desktop environments / window managers support that portal and stuff like Electron does too, so for example with Slack (installed over Flatpak) in can now toggle mute even If i dont focus Slack.
That's not UX though, it's more theming. If themes affect your UX then there is no pleasing you.
True enough I'm happy with flatpak but I never stray from the default GTK themes.
I was unhappy with flatpak until I found Flatseal, now I include it on all my workstation setups.
But I can't help you with the theming unfortunately, I think that's a sore point for a lot of users that like customizing their Linux DE.
I feel the same. Like a few years ago Fedora + GNOME + Flatpak was the magic sauce. Not so much anymore. I’m back to Arch as well, which seems as if its package repositories have only grown. The AUR is there but I’m shocked how little I need from it.
In case anyone ever seriously contemplates a new design, here's an anecdote:
Quite a few years ago, when Flatpak was a brand new project, I met some of the original developers. I tried, and failed, to convince them to change one particular fundamental part of the design. In the original design, and today, an installed Flatpak has a name, the permissions are bound to that name, you run that Flatpak and it has its assigned permissions, and, if anything else talks to it, it talks to it by that name. If I install a VSCode Flatpak as my UID and grant it access to my Documents directory, then VSCode, running as me, has access to Documents.
I argued that this was the wrong design. If I install VSCode as me, then there should be an installed copy, and that should have approximately no significance. If I run VSCode, then the running instance should have some id (possibly ephemeral), and that instance should have a set of permissions. If I want to run VSCode with access to ~/project_a and another instance with access to ~/project_b, it should just work and the instances should not be able to access each other's data, even if they're running at the same time. If I want to run two Tailscales, it should work. If I want to fire up an ephemeral instance of Firefox, that should work, too.
However many years later, I still think I was right. Flatpak gets this wrong, MS and Apple's App Stores get this wrong, Mac OS gets this (very very) wrong, etc. There's plenty of opportunity to do better.
(This is important from a bug-mitigation perspective: a LibreOffice document that achieves RCE should not be able to access my other documents. It's also important frmo a vendor-doesn't-care-at-all perspective: VScode has basically no security to begin with, and VSCode inside Flatpak ought to have a degree of real security courtesy of Flatpak.)
You are right, but actually I think you would want to go beyond that and build a hybrid of your approach and their approach:
For your documents, you will usually want your approach. Maybe with some optinal allowance for useful things like a "recently used documents" menu or something.
But for more enviromental things, I would want at least the option of allowing all instances the same access without a lot of permission prompts later on. E.g. my git config, my fonts folder, my code snippets library, stuff like that.
I do think this would be good for power users who want strict isolation between different instances of apps (and I'd also love to see better QubesOS type approaches, using a hypervisor), but perhaps most of this kind of work should be prioritized inside the application itself, using nested sandboxing. That way, the barriers are exactly where the user expects them to be based on the normal behavior of the application. Assuming vulnerabilities in the code that glues it all together don't get explosive, of course.
Web browsers do already use a variety of sandboxing techniques to achieve separation between tabs. Some of these techniques work inside Flatpak, but some of them are broken by Flatpak:
> Ideally, Flatpak would simply support nested namespacing and nested sandboxes, but currently it does not. Flatpak uses seccomp to prevent applications in a sandbox from having direct access to user namespaces.
Some of them are replaced by Flatpak, for application developers that wish to use the APIs:
> What Flatpak does instead, currently, is to have a kind of side sandbox that applications can call to and spawn another Flatpak instance that can be restricted even further
Fortunately, it seems Wick is optimistic about UID namespacing, the main thing stopping Firefox and Chrome from fixing this:
> Wick feels that user namespaces are, nowadays, a well-tested and a much-used interface. He does not think that there is much of a good argument against user namespaces anymore.
Back to the topic of instanced Flatpaks, as I understand one snag is that there is a long-term desire (by app stores/platforms in general) for a full boot-to-userspace code-signing setup to be tied into the sandboxing. The identity of each application should remain the same (unless specifically overridden by a power user) so that a fake version of an application can't adopt an existing application's confidential encrypted files if it doesn't meet the codesigning requirements. I guess one solution here would be for the segregated instances to be nested inside the application's identity, but that's getting quite complex. And we don't even have encryption nor any functioning secure boot + confidential computing implementation yet -- all we really have so far on this front is the reverse domain name notation being verified by Flathub, with filesystem access sandboxing to keep these folders separate.
Yes, that would be better, for specific instances of the running program to have a set of permissions instead. However, I think this is not the only issue.
It is what I had wanted too, not only you.
I think that the entire operating system should need to be redesigned for many reasons (I mentioned before how to design a better one), and it would have that effect, that specific instances of a running program would be given capabilities as arguments (or through other capabilities, but the first ones must be given as arguments), and these capabilities can have restricted permissions, as well as more versatile things e.g. to log access, or to go through a proxy, or to set a disk quota, etc.
I might have misunderstood this part, isn't that the role of the xdg-portal which gives ephemeral access to whatever gives access to to the instance?
Like VirtualBox snapshots? Then you will want to branch, merge and rollback these snapshots.
This is like Qubes TemplateVM vs AppVM.
Mildly OT but I have longed for this kind of app portability in Android too. Some OEMs like Xiaomi apparently took note a few years back, offering inbuilt app "duplication" features in their OS's but only for a few popular apps like WhatsApp.
Nice breakdown. I'm new to Linux and didn't know about this:
> Flatpak still uses PulseAudio even if a host system uses PipeWire. The problem with that is that PulseAudio bundles together access to speakers and microphones—you can have access to both, or neither, but not just one. So if an application has access to play sound, it also has access to capture audio
That's a pretty decent sized hole.
I sometimes see Linux users sneering at Windows and Mac design mistakes or lack of “freedom”… but then there’s stuff like this.
Of course, Linux is then conveniently redefined in a way that nobody can be responsible, with finger pointing on every issue, rather than admit design flaws like this plague Linux as a whole.
I get that you already preempted this, but: Flatpack is a weird extra layer on top of Linux. Most distros have package managers that work just fine. These package managers predate Flatpack and basically are the main thing that the distro provides (other than the community, of course).
if they were working fine there would be not need for flatpak
Arguably they are working fine, and there is no need for flatpak. That’s been my personal experience anyway.
But those are even worse from this point of view, I have no control over which apps can access my camera, or microphone.
I'm personally disappointed that sandboxing isn't easier in Linux. I hoped it would move past Windows and Mac, imagine a world where the majority of libraries are sandboxed too, we only let compression and decompression libraries read one stream and write to another, this would improve security. This has been done by both Google (in Android) and Apple (in iOS and Mac OS X), but hasn't seen general acceptance in Linux (as far as I can tell).
Because on Linux, everything is based around trusted security since you have access to the sources whereas on iOS and Android, every single app you install could be a malware so those systems are based on untrusted security.
That assumes that there are never zero days or other unpatched vulnerabilities. You should not trust applications because you have access to the source. Nobody is actively auditing the vast majority of open source code, well except of malicious actors who probably have a handful of remotes in a lot of RSS readers, chat apps, microblogging clients, etc., which they can use to compromise activists and journalist naive enough to trust desktop Linux.
A lot of Android vulnerabilities are bugs in open source parsers of untrusted data (open source as in AOSP or more widely used open source libraries). But the impact is smaller because Android has proper security boundaries. If desktop Linux was as popular as Android -- we would have a security disaster of epic proportions.
But in the mean time, I still trust a Linux distribution more than my phone when it comes to my private data.
My Linux distribution doesn't have a built-in advertising id, unknown manufacturer modifications I can't even look at or shady processes which have more power than I do.
I think it's time for the tech community to move beyond just the tech side and understand that security is also a social contract.
This is just a pivot though, if you don't have good security then your privacy is worth nothing.
Irony being that Mac OS X is the best at privacy out of the commercial OS out there.
In today's world, attacks on your data are much more common than targeted exploits on the kernel so I would put it in opposite order. If there's no privacy then there's no security.
> Irony being that Mac OS X is the best at privacy out of the commercial OS out there.
The bar is very low and OSX is still way below a Linux distribution
IMO flatpak should assume untrusted too, unless it's a distro specific repository of strictly reviewed/controlled code (like Fedora Flatpak repo, etc).
Hahaha, oh that is a hilarious attitude, you really believe that F/OSS means that implicit trust can be granted all across the supply chain. That I have access to the source makes a lick of difference in terms of vulnerabilities or exploits that can be found.
Once in college I cited Linus's Law in an impassioned apologia for Open Source. And I was duly corrected. Because Linus's Law really has no basis in reality.
https://en.wikipedia.org/wiki/Linus%27s_law
The reason Linux has such a model of blind trust in system services and applications is because it was based on Unix, which had an even more naïve model, because mostly, it was administrators and authorized users installing that stuff, there was more top-down monitoring and control, and just a smaller incidence of naked malice.
It's the same thing we see in earlier versions of Windows, or macOS, or the Internet. Look at the Internet in the mid-90s. Was it secure, with all the open source running on it? Hell naw. Every OS and protocol is vulnerable and attacked, and every OS and protocol revises security models based on modern-day threats. F/OSS saves nobody and mitigates virtually nothing.
To answer the GP, sandboxing has to be bolted-in to Linux after the fact. Linux's POSIX model is so old and needs to be so compatible. The only sandboxing in SVR3 Unix was chroot(2), you know? The Docker support and cgroups and virtualization are all new layers, and need careful integration. Nobody says that F/OSS doesn't need sandboxing. Nobody says that F/OSS is so secure that it can deviate from better-secured models. Quite the opposite.
Android and iOS are clean starts, mostly; didn't need to be backwards compatible, so they're tuned to the latest threat models of adversarial computing as you describe. But every single app you install on Linux could be a malware, too. I have no idea what "trusted security" or "untrusted security" are, but they aren't real terms of art in Cybersecurity, and they do nothing to describe the provenance or evolution of Linux security (which often has a lot of unused mitigations such as AppArmor or SELinux that get turned off right quick.)
This is kind of a sophism, of course it's not perfect (nothing is) but I'll still trust this model over Android or iOS which have a built-in advertising id, manufacturer modifications I can't even look at and shady processes which have more power than I do.
Security is also a social contract.
Many Ubuntu or Debian users still use Flatpak, don't they? Even though there's already apt-get.
I don't think so.
I'm on Ubuntu and mostly use debs (apt), I'll use Snaps if that's the easiest way to get an update. I use Appimages for some ephemeral stuff or when that's the only way developers release it (some 3d printing stuff). I haven't installed Flatpaks at all because it doesn't jibe with the distro overall.
You, kind of, don't have much of a choice. There's thousands of packages and it's a ton of work. In addition, as Linux continues to get more popular, more vendors are releasing software that doesn't care to work with newer libraries, so Flatpack handles this nicely.
I only use Linux on servers, so the kind of stuff I need is always traditional apt-get, but yeah I always assumed using it on a PC would involve tons of snap or flatpak apps where they don't want to deal with the complexities of dependencies.
Ok, I do have one spare Linux laptop in my garage that I barely use, and I'm pretty sure how ever I installed Chromium used snap.
In my experience, most of the apps, even the desktop ones, are still packaged by the distribution.
Flatpack is useful for the few ones that aren’t or for actively developed apps that get new useful features frequently.
I don't know anyone who uses it.
>Flatpack is a weird extra layer on top of Linux
My brother in christ, systemd, x11 and even GNU are weird extra layers on top of Linux. Linux is just the kernel. This is exactly what "redefining Linux so it's never responsible for 99% you need to put on top of Linux to have a functional modern OS" is about.
See, that's why calling it "linux" instead of "gnu/linux" confuses people and generates confused comments such as yours :)
I explicitly acknowledged that in the other half of the sentence you partially quoted.
I also explained why I thought it was not really right to focus on the deficiencies of Flatpack… so, I’m not sure what the point in repeating that would be. In conclusion,
> Linux is […] exactly what […] you need
I agree!
How would you do this on Windows?
I wish there were such thing as just "installing Linux" on a computer, and it shows the penguin when you boot up.
There sort of is, but you can't do anything with it, because you essentially have no user space utilities?
For all of the crap that people gave the term "GNU/Linux" it's even more true today considering there are Linux-based operating systems that don't use GNU utilities.
gjsman-1000 talks about "design flaws" in Linux above, but Linux is just the kernel. There is no "Linux" operating system, despite everyone, and even Linus probably? using that term.
If you call booting init and getting a black screen "an operating system," well... that's cool I guess.
I doubt Linus ever talks to the GTK people in any meaningful way, or any other desktop environment authors. So, what design flaws?
Do you call a ladder a badly designed scaffold because it doesn't have a horizontal platform? No, it's just something entirely different all together.
"GNU/Linux" can still mean too many different things. Even ChromeOS qualifies as that. You want GNU/Linux help, you need to specify what DE and everything. Or as the other comment said, what Bluetooth stack. You can say you're using Manjaro Cinnamon and either that's not specific enough, or someone says it's your fault for not using KDE.
I'm comparing to Windows or Mac. There's only one Bluetooth audio stack in Windows. If you want help with it, whatever you find online will apply to you, unless of course you've gone out of your way to swap it for another. Unlike Windows, Linux is open and people can build their own flavors, but those can have their own names.
Don't even get me started with how Ubuntu changed its entire GUI like 3 times so that it's unrecognizable each time. Feel bad for whatever IT departments had to keep taking new screenshots of how to do stuff.
…it’s just too bad that Bluetooth stack is one of the worst ever conceived, you have zero options for an alternative, and you still have to get all your help from a volunteer support team.
Bluetooth is hard. But it'd at least be easier if the Linux community weren't maxing out on complexity before even reaching the hardware. Even Windows struggled with drivers for a while.
If you don't like the above there are several BSD systems that give you a useable OS. You probably want a deskto though which none give.
FreeBSD has a desktop, doesn't it?
Several:
https://docs.freebsd.org/en/books/handbook/desktop/
Yep, and there are (were? It's been a while since I checked) even "distros" of FreeBSD that are specialized for desktop use. The main downside of FreeBSD is that it doesn't dumb itself down to appeal to the masses, so while it's great for experienced users it's a bit painful for newbies.
Last time I used FreeBSD, I found it more inherently user-friendly than Linux distros, mainly because it has a very nice handbook (linked in a sibling comment) with realistic examples. Also seems to have more things built in.
What made FreeBSD harder in the end was just that fewer people use it, so tons of third-party software supports Linux better, and it's easier to find online answers.
The *BSDs have all the same issues that Flatpak is trying to solve. (ports aint it.)
I don't agree with him 100%, but I always find Drew DeVault to be thoughtful on this topic:
https://news.ycombinator.com/item?id=32936114
https://drewdevault.com/2021/09/27/Let-distros-do-their-job....
Basically, he argues that application distribution outside of the distro (a la flatpak, snap, appimage) is just a bad model. The right model is the one distros have been using for years: You get software through the distro's package manager, and that software is packaged by people working on behalf of the distro. As he says: "Software distributions are often volunteer-run and represent the interests of the users; in a sense they are a kind of union of users."
The other issue, of course, is that in practice flatpaks/snaps/appimages never seem to 100% work as well as distro packages do.
I disagree with that. IMHO the best possible people to create a package for an application are the original developers of that software. If that software is proprietary, that also happens to be the only party that can legally do that anyway. Because it typically requires access to the source code and software redistribution requires permission.
So, the model you mention only works for open source packages. And I would argue that even in the case an app is 100% open source it's a bad idea for somebody not affiliated with the core development team to be second guessing a lot of things about that application.
It results in a lot of issues that aren't necessary. Like needless lag between developers releasing new software and some third party doing whatever uninvited tweaks they think are necessary, or adding their own bugs and new issues.
It's why I always install Firefox in tar ball form straight from Mozilla for example. It updates itself as soon as developers OK some patch. This happens a lot and mostly for security and stability reasons. I want those patches when they release them. The things external distribution maintainers do are redundant. I trust Mozilla to do the right thing and be the most clued in about any issues regarding their own software. With proprietary stuff, I just want stuff to run with a minimum of hassle.
Flatpak is trying to do too many things. It's trying to emulate an appstore. I don't necessarily like app stores. They are gate keepers. What do developers on Windows and Apple do? They put binaries on their own website. You download them. You install them. And then they run. Downloaded apps have the same rights as apps provided via app stores. The app stores don't repackage the app, they merely distribute them. It's an add on service. An optional extra. All the essentials that provide security are baked into the OS and the application package. There are a few mechanisms that windows and mac provide to make things secure. Binaries are signed, the OS has a permission model for things that need that (screen sharing, directory access to certain things, using the webcam, etc). That's the right model. That could work for Linux as well. It shouldn't require taking control of distribution or packaging by some third party.
Flatpak is more of a set of tools and framework. I wouldn't consider it as a store but a distribution system. Flathub is a repository, Fedora has its own repository and anybody can creates its own repo (I wouldn't call it store as there is no concept of monetisation).
I wouldn't consider flatpak as a gatekeeper as there is no "team" going through some arbitrary process to allow/disallow an app.
I also disagree with the fact that macos and windows did the right thing, what I found in my experience managing laptops in a company that is roughly 1/3 windows, 1/3 linux, 1/3 macos is that: - What windows is teaching users is to download random stuff and bypass the warning screens if something is not signed. Unless there is a company policy and a third party software to update what is installed, by default things installed are a mix of up to date and not update to date software. - Macos user do not install operating system and software updates unless a third party software is installed and force them too - Linux users have things up to date, only distribution version updates (e.g. fedora 41 to fedora 42) are inconsistent.
So my take is that, even if things on not perfect with flatpak, rpm/dnf, fwupdmgr and package manager, this is much better than having to pay for third party tools in macos and windows because of the lack of a good way to distribute and maintain apps at the operating system level.
I think that you are right about not depending on one open source OS to provide the proper depencencies, customizaion, and training wheels for every app. I have been running linux on my desktop for about 20 years, about one decade of Mint followed by the same of Fedora so far. Being a curious but fussy guy who installs lots of software to see what works, I find that I need to install a fresh OS about every 18 to 24 months.
There are, I suppose, always a few programs that don't get upated by 'sudo dnf update' but do get bothered by updates to the shared libraries via the same. Perhaps there are some config files that get damaged by software bugs or power outages or system crashes or my own mistakes and carelessness. I also found out that if one loses the dnf program, one will discover just how impossible it is to pull oneself up by oneself's bootstraps.
Mint was a very similar situation. Maybe not so bad for one who follows all the rules, but in those bygone days there were people suggesting that updating Mint programs with newer versions fron the ubuntu or debian repos was a good idea. And because Mint was slow to get updates, I would attempt to update some apps by downloading source and building and installing here.
Last year, when I upgraded Fedora from 39 to 41, was the first time I got any OS upgrade to work instead of wiping the disk, doing a fresh install of the new OS version, and then spending a week or month trying to get my data for the installed apps (eg web browser and email) from backups. But the upgrade took much longer than it should have, because once I started running the upgrade process, I did not know that the computer sitting there dead silent with no action on the screen for about 30 hours was a sign that all was going well. Computers are evil.
The problem is that now you have to package for N distros. And the people who run the distro may not want to spend time on it, so you have to do it yourself.
It doesn't have to be gated by "the people who run the distro". I started packaging a few pieces of software for a distro I use because I wanted to use that software, and I don't "run" the distros in any capacity. Package maintainers aren't born that way, they become that way by volunteering, just like most everything in Linux.
If you don't have even one user willing to do that for the distro they use, you probably weren't going to have users on that distro anyway.
You're saying the exact opposite of the original point, which is: you should not package for distros, distros should package for themselves. You just distribute your sources.
You are a good candidate to package for your distro, so there's that. And then for a random distro, if nobody feels like packaging for it, then it's just not there. Either there is not enough interest in your project, or there is not enough interest in the distro itself.
> distros should package for themselves. You just distribute your sources.
That's how you ended up with Erlang being split into 20+ packages on Ubuntu/Debian in the past. Because it was packaged by people who know little about erlang, and had too much time on their hands probably.
And that is the main issue: you want distro maintainers to compile and package every single pieces of software under the sun, but they can't possibly know every piece of software, how it works, or how it's supposed to work. Times that by the number of distros.
Application developer should be able to package and distribute the app. See how easy it is for casual user to download and install any application on windows. Maintainers cannot scale and depending on them will just hold back Desktop Linux
The best thing about unvetted app stores is that anyone can publish software!
The worst thing about unvetted app stores it that anyone can publish software!
Flathub is not unvetted. Every submission goes through human review. If a piece of software requires an unnecessary permission (i.e. if someone submits an alarm clock program that requires home folder access and internet access), it will get rejected. If a developer updates their software and changes the required permissions, the update won't get pushed to users until it goes through human review.
Besides this, for open source packages, the code gets built on Flathub's build servers without internet access. The source code associated with a given Flathub package version must be either a specific Git commit (verified with a commit hash) or a release tarball (verified with a sha256 hash). This means that it's always possible to verify that the code a developer publishes corresponds to the binaries being shipped to users. Closed source packages get a big warning on their Flathub pages saying that the program's code is proprietary and not auditable.
With the traditional distro packaging model, the requirements to become a maintainer are stringent and there's human review when a package is added, but there's typically no review after that point. If you'd like a recent example of the drawbacks of this system, see here: https://security.opensuse.org/2025/05/07/deepin-desktop-remo... . After the OpenSUSE security team rejected certain components of the Deepin DE for containing major security problems (including multiple root privilege escalation vulnerabilities), the Deepin maintainer smuggled them in anyway through an innocuous looking package called "deepin-feature-enable" and nobody in the security team noticed for several years. I'm not trying to call out the OpenSUSE security team here, I'm sure they don't have the resources to vet random packages. I'm saying that expecting maintainers to never ship malicious code because they went through the process to become a maintainer is a weakness of the traditional distro packaging model.
Distro package maintainers are not security researchers, they don't audit the code they maintain.
They do to some extent in the larger distros, but for proprietary/binary packages they don't have much chance anyway unless they are willing to do some pretty time-consuming forensics.
This is false.
Plus the app developers at least have some level of accountability. Like when JWZ got into it with Debian (can't link here). You might think you are running XScreensaver from the great Zawinski, but no you are actually running some weird fork from godknowswho, hopefully not Jia Tan.
XScreensaver is supposed to hide your desktop and Jia Tan is an expert at hiding things, so I think they'd be a perfect match.
> that software is packaged by people working on behalf of the distro.
It is totally unreasonable to expect distros to be able to package every software in the world
I'm glad flaptaks are getting more adoption. Application distribution needs to move from distributions because they suck at it. Due to no fault of their own. Developers should have the option to distribute their apps without middlemen.
In fact I’d say they are perfect for distributions to be more stable. E.g. : my issue with Debian have always been that you couldn’t (easily, I know backports existed) have stable system AND fresh software. With Flatpack, you can.
Now I can run my latest user softwares on a stable distribution. That’s pretty cool.
There are still issues of UX. Especially when the app you are using doesn’t have enough permissions to do the job, you have no information about it and when you guess it by yourself, changing this is hard.
I’d expect that Flatpack should allow apps to specifically ask for permissions in real time or when they try to access external resources like in macOS : just expose the APIs but make them wait for user approval.
I've installed flatpak to install VSCode/Codium to have an usable debugger for a Python project I'm working on. After some time tweaking VSCode/Codium trying to get the debbuger to work, just realized flatpak could be the problem. After another considerable amount of time trying different flatpak permissions, realized this is not a good use of my time. Installed the same packages from snap, and everything worked OK.
The emacs flatpak is just a long and painful road leading nowhere.
I've switched to a flatpak-based immutable distro lately. It's great when it works. But so many niceties don't work, and then it feels like my computer is not really the fantastic tool it should be. For example:
- I had to run around with a distrobox running WINE and a bunch of permissions and kludges to run an external tool for Godot
- I gave up on the flatpak for Firefox because it can't talk to my KeepassDX flatpak
- The Godot and Krita flatpaks are oddly unstable and crash more than they did on Windows (may just be Gnome or something)
- non-flatpak tools like AppImages and .rpms feel pretty dang grungy
I want to see more cool stuff with Flatpak so seeing the state it's in is kind of a bummer.
Years ago, I wrote an on-screen display (OSD) in Java for showing keypresses and mouse clicks[1]. Someone thought a flatpack would be useful[2]. I didn't see the point. It meant: (a) maintaining two installation processes; (b) collating download stats from two sources; (c) trusting a third-party system to maintain package indexes over time[3]; (d) adding yet another package manager to a system that already has a package manager; and (e) bloating the repo with another repo.
Years later, I still only see drawbacks.
[1]: https://gitlab.com/DaveJarvis/KmCaster
[2]: https://github.com/flathub/com.whitemagicsoftware.kmcaster
[3]: https://flathub.org/apps/search?q=kmcaster - whoops!
The upsides would be
- Easy use on immutable distros - The user doesn't have to make sure they have the right version of Java installed - Auto-updates even if there is no repo for your specific distro
And also you can find it through searching on Flathub I guess
> And also you can find it through searching on Flathub I guess
Did you click the third link I posted, which searches Flathub for KmCaster only to come up dry? This was point (c): You have to trust that their search engine is correct, maintained, and updated. That doesn't come for free, it takes effort, and things go wrong.
This isn't a bug. Kmcaster is unmaintained and has been removed from flathub.
[0] https://flathub.org/apps/com.whitemagicsoftware.kmcaster
It comes up as dry because the package is marked as unmaintained
https://flathub.org/apps/com.whitemagicsoftware.kmcaster
https://github.com/flathub/com.whitemagicsoftware.kmcaster/p...
The permissions issues are real.
It still isn't possible to package Tailscale or anything that creates a virtual interface as a Flatpak because there is no permission for that. macOS has an API to ask for permissions to add an interface/change routes.
Thanks to said API, Tailscale on MacOS is even distributed as a sandboxed app through the Mac App Store [1]. Flatpak's restrictions make certain classes of software difficult to use on "atomic" Linux distros like Silverblue or Bluefin that provide a read-only base system and expect users to get their software through Flatpak.
[1] https://tailscale.com/kb/1016/install-mac
I daily drive an immutable Fedora spin and if I wanted to install Tailscale I would most likely add it to the base image via `rpm-ostree` instead of trying to reach for Flatpak - not because i'm aware of the issues but because it makes more sense to me to add a more system-wide networking layer to the base image. That being said there are many apps that are not packaged as Flatpaks that I end up adding to the base layer out of necessity which I would have liked to use as Flatpaks.
> It still isn't possible to package Tailscale or anything that creates a virtual interface as a Flatpak because there is no permission for that.
It's possible but not ideal. The application could use flatpak-spawn (to get out the sandbox) and then polkit-exec (to ask user for root perms for arbitrary use) to get root privileges on the host, but you're removing nearly all sandboxing.
I'm not sure I'd install tailscale as a flatpak even if it were possible. I've always seen flatpak as a way to install large, potentially crappy desktop applications without polluting your system. OBS studio is a perfect example - it's a great app but it's the only one I use that uses QT, thanks to flatpak I don't even have the QT libraries installed on my system.
Tailscale is more like a system service that I'd prefer a distro package for (Arch Linux repos contain Tailscale, btw).
You don't have QT libraries installed on your system. You just have then in some archive somewhere along with a bunch of copies of stuff you do already have installed on your system.
Im not really much of a flatpak user but to me it seems like permission system on top of Linux is an incredible undertaking. Solving both packaging and retrofitting permissions at the same time seems too big of a cookie to swallow. I don’t know whether the permission system is what killed the momentum and caused this seeming burnout. But it seems incredibly complex.
To me, Linux doesn’t have a granular modern permission system, and I don’t expect my package manager to solve it for me. I still run proprietary software on it, because I kind of have to. Is that an ideal situation? No. But I rather have a distribution system and vet vendors (which I’m doing anyway) than wait another decade for permissions to be perfect. Distribution, packaging and updates is the pressing need imo.
Maybe Tailscale should be a sysext not a Flatpak.
I'm not an open source maintainer or even a dev, but it seems bonkers to me that with all the numerous distributions out there, all facing the same problem of package management, that they couldn't just refocus their combined efforts toward improving Flatpak and guiding it toward universal adoption.
Maybe one reason why many "distributions" exist is that they don't feel like "distributing" the same way :-).
Diversity is good. I don't want "one distribution" that chooses the init system, distribution, compositor, window manager, etc. I want to have choice.
When it comes to distributing packages, I personally like system package managers. Not such a big fan of flatpak.
Many people disagree on the idea that flatpack is useful at all.
For example it's completely useless to me. Why do you expect me to help on something I don't use?
I'm currently using Slackware current. I use an approach of compiling from source or using AppImage. Things like Flatpak and Snaps are an opaque black box to me.
I have AppImages for things like Zoom, KeePass and LibreOffice. I don't need to keep updating them. They do what I want them to do. I have them on a separate partition. If I reinstall my system they're all ready to go out of the gate.
It's ridiculously simple.
I did try out Fedora awhile ago, but decided it wasn't for me. Why is everything a Flatpak? Just use the repo mechanism.
Same system with me. Running gentoo without systemd or pulseaudio makes Flatpak and Snap totally nonstarters. I compile most of my stuff from gentoo's official repos and supplement things with select AppImages that work out of the box, curiously well.
Never understood the point of flatpak, snap and the like. Can't you just distribute static binaries? They are not that hard to compile.
(I mean, from the distributing point of view. The sandboxing and resource management is a OS-thing that should be an orthogonal issue. Users must be able to sandbox programs that they don't trust, regardless to how they are packaged and distributed.)
> Can't you just distribute static binaries? They are not that hard to compile.
You absolutely can't, since you need to link to the system libGL.so and friends for gpu acceleration, libva.so for video acceleration, and so on.
They're not at all trivial on anything big and complex.
And the code I work on has loadable plugins, too.
Any complex software is going to be a collection of files, not a single static binary.
I did not find packaging up an AppImage that is actually compatible across distro's and version all that straightforward, and we were not even using Qt or GTK/libadwaita. How is this easy, in your experience?
> How is this easy, in your experience?
add -static to your link flags? Sometimes you need to fiddle a bit with the order of the libraries, but that's it.
In the ideal case, for maximum portability, i'd like to use the αpε format!
Have you actually tried to make a fully statically linked GUI app on Linux?
Both flatpak and snap have been a bane with inconsistent behaviors, permissions bugs, and a bunch of stuff I never figured out. I got so frustrated with them that I wiped, put Debian on and just the old package systems.
I'd largely agree. Snap was what drove me away from Ubuntu, after the calculator app started taking ages to load. The calculator! It was instant before snapification.
I have played with using FlatPak, and while it seems snappier than snap, I always ended up with something not quite working, because of permissions or sandboxing. The answer to a lot of problems seemed to be "don't use the FlatPak version".
The set of software I use complex enough to need something like FlatPak while also not needing to interact with other things is basically very, very small.
I've been using Fedora 41 about half a year, and flatpak has not made it better.
Fedora 41 started with a bunch of apps distributed as rpm, but some of them have since been updated as flatpaks when I run 'sudo dnf update'. Splendid, except that the rpm apps, now a little out-of-date, are not deleted, which may be good or bad, but that explains why I have duplicate icons for the same app all over my desktop, and its pretty confusing trying to tell which is which, which is better, or how to manage the all the differences and conflicts, which Fedora 41 makes anything but scrutable.
The thing about the microphones and speakers getting tangled up, as explained in TFA, also was somethig of and for which I was unaware and unprepared respectively when I had some problem with the old-fashioned way and decided to install musescore as a flatpak.
I've been thinking about upgrading to Fedora 42, but this article is giving me considerable premonitions of additional inconvenience and incidental despair. Anyone have this stuff under control?
I'd choose a single appimage binary any day over flatpak, snap, or containers. It's just so portable and user friendly!
I use NixOS and Flatpak I found is the easiest way to install and update applications. The Nix model is great for system software, but not an ideal way of updating and installing desktop apps.
The only problem I've had is fonts installed system wide not being available in the sandbox, but this is due to how NixOS exports fonts and can be solved by telling NixOS to publish fonts in /usr/share/fonts.
Linux has the worst software distribution model towards the general public of all OS. The one of windows (and probably MacOS but I don't know much) is also full of issues, but is still infinitely better than linux. When you compound the number of distributions, the number of their versions, the number of software, and their versions, you realize that having the distribution managed by the distribution or the software authors is unsustainable. In comparison, windows and mac only require at most 2 versions of the software each to reach at list 90% of the users.
I don't know if flatpak or appimage or whatever are a solution, and I cannot propose one myself. But I really think that at one point the linux model will completely fail if it doesn't improve
BTW I'm not saying that the linux model is always inferior. Actually it is often superior: in the server world were professionals take care of things, in the embedded world where the resources are scarce, the possibilities to configure and select everything to the smallest detail make it great.
I think flatpaks are all about bringing android's limitations to mainstream linux.
Flatpak’s biggest bug isn’t in the code, it’s the bus factor.
> Tons of features are stuck in merge-request limbo because there just aren’t enough reviewers, and if we don’t swap some “+1”s for actual PR reviews (or funding), we’ll be shipping apps in 2030 with a sandbox frozen in 2024 while everything else rides OCI.
It's too complex. An application format shouldn't need to rely on 5 different APIs to be secure. And the apps aren't portable. I think something like WebAssembly is going to be the way forward.
I hope you're right. But how is WASM going to answer questions like "how does the application play sound?" or "how does the application request a password from the system keychain?"
WASM solves a lot of problems, but I don't think its chances of providing a uniform API to things like that are any better than Snap/Flatpak's, because those problems are fundamentally not about the runtime/packaging system. They're caused by OS functionality being a fragmented and moving target. Directly executable applications have to deal with those complexities themselves. Containerized applications in WASM/Docker/Snap/Flatpak/whatever rely on the container layer to do it. But someone's software has to chase that moving target, and it moves very fast.
Biggest problem with flatpak for me is that it's not suitable for server-side software, which is well supported in Snap. Is that even planned at some point?
Is there an active Flatpack community that is actually interested in it, in the same way communities form around distros and their repos? It seems like probably no…
I dunno. So far my experience with these third party store things (or whatever) is that occasionally Firefox gets switched to a Snap, requiring active intervention and possibly nuking my profile is I do it wrong. It is… pretty annoying.
There's a Flathub Discourse[0], but it's died down a lot
[0] https://discourse.flathub.org/
If a packaging mechanism, respecting virtualisation had been capable of existing 30 years ago we'd have one. Now, given how the fracture lines run, we're fated to have three or more.
It's pythons virtual environment and pip-is-weak problem, magnified. It's homebrew or Mac ports or fink or pkgsrc.
Mechanisms designed after fork, are never fork neutral.
I see the real utility these tools are providing to many folks, but ...
It just feels so ugly. Square peg meets round hole.
We built all these tools for defining security boundaries for user-installed applications, and it turned out that the Linux packaging/distribution landscape was such a wasteland that people spent a lot of time duct taping software distribution artifact reproducibility onto the security-boundary tools.
So now we're in this weird worst-of-all-worlds spot:
The simplicity, performance, and decades of work we spent to make it easy to develop powerful applications that run directly on userland is now bifurcated/trifurcated and a mess. The legibility of "I want to run an application that dynamically links a cryptography library; that library is provided by the distro and I know it is both patched and compatible with the rest of the distro" or "my application can access files/devices at /path/to/whatever and use those resources if it has permission to do so" is buried under tons of container indirection.
Meanwhile, as TFA explains in detail, the actual security/encapsuation boundaries that these tools were originally built for proved to be a fast-moving target for which tons of support is still missing years later.
We can see the possibilities of what could have been in other systems. Take BSD's pledge(2) for example: its approach is so aggressively oriented towards only solving the security problem that I can't really imagine a world where the pledge/capability system "grew" a packaging/distribution ecosystem the way Snap and Flatpak did. Or take plan9's approach: perhaps if we had modeled the entirety of the OS in such a way that the basic SysV permissions model (users, groups, files, permissions) covered as much as possible of applications' security sandboxing needs, then things like SElinux/snap/flatpak wouldn't have ended up being necessary.
The biggest thing that got us into this state wasn't the tools, though--it was the human stuff: the tensions between "distro/package repo maintainers are burnt out and want to support a relatively small number of dependency targets and ways to add things to the package graph on a given OS"; "app developers want to make complex software available to users as quickly as possible"; and "users are very willing to do insecure things to get new applications to run, but are generally unwilling to do complex things (configure/make, customize AUR sources, know what nix is) in order to install stuff".
Fast forward a few years, add a lot of false starts and other bullshit due to dueling desktop environments/compositors/audio systems, and where we ended up is not good.
The current situation is basically:
"Come on down to DLL hell but way worse, we have: tons of brittleness when apps want to talk to the rest of the OS (sucks for users--but only when apps need rare and advanced functionality like ... uuuh basic audio playback), all baked into highly complex container systems (sucks for application authors) aimed at delivering apps that each package their own look/feel/OS integrations (sucks for distro maintainers and consistency of UX) in massive "it's not actually static linking, I promise" images, each of which contains 75% of an OS, running on leaky isolates (sucks for the security patchers) with an update story of "just download the universe again" (sucks for bandwidth/CDN costs)."
Like, I understand how we got here. I get that it's better than the bad old days of "but which autoconf?"/"I just wanted to update my browser but then glibc-2.11-compat-compat-compat-but-for-real-this-time-FINAL updated and broke my bootloader". And I get that some of those areas might improve over time (e.g. OCI images help with redownload-the-world; eventually Wayland will percolate around and the container runtime X compositor geometric complexity explosion will die down; someday someone will finally fix universal D-Bus discoverability and security for the eighteenth time...).
But overall it is and will remain a mess at a fundamental, philosophical level. Seems like the Linux ecosystem did this in a maximally slow and fragmented way, which is nothing new. But it sucks to see such an "everyone loses" end state as the result.
I think D-bus has many problems and isn't very good. I also think the sandboxing (of Flatpak and other systems) has problems, e.g. lack of some kinds of permissions (e.g. permissions that depend on command-line switches, permissions to execute user-specified external programs by popen (without the restrictions affecting them too), and more), inability to properly use character encodings, etc. There are other issues as well, even though I think that the sandboxed execution is not a bad idea in general.
> Flatpak now has --device=input to allow an application to access input devices without having access to all devices.
Oh, hey... I made that feature. Nice to see that other people want narrower permissions, too.
Great, after bringing Pulse (+ Limewire to fix it), systemd, wayland, dbus, flatpak to dilute and overcomplicate everything, RHEL is now abandoning the desktop alltogether. Meanwhile, zero new desktop apps have been created for Linux in like two decades. Today even Firefox on Ubuntu and Fedora can't access a webcam for teams/gmeet because of permission problems of layered container frameworks that are there just to protect fictional, as in non-existant, apps from accessing your damn files. Seriously, the only way out and where progress has been made seems to be embracing win32 apps using wine/proton, but maybe using SteamOS/Arch instead since bazzite is based on fedora.
If not Flatpak, what is the future for portable sandboxed applications on Linux? I would love a solution where I can run semi-trusted or untrusted applications (e.g. vscode+extensions) confident that it doesn't have uncontrolled access to whatever my userid privileges permit.
The solution for untrusted code is to not run it.
it was really for cross-distro GUI desktop applications. I saw it's used in embedded linux projects that has no GUI, for its portability at a heavy price(flatpak is quite fat, it needs to install a full sandbox)
I chose flatpak some time ago over snaps for gui apps and I don't remember why. I think there are benefits to packaging software this way (especially for immutable OS images) but at the same time there are so many negatives too. I hope they make it more of a priority. Or something better comes out on top.
Drat. Does this mean Fedora is hosed? I don't really follow metastories on Linux...
I'd be more worried about Fedora Silverblue and Kinoite, its variants which rely on Flatpak more, as their point is to experiment with a minimal immutable base OS with every user facing app installed as a Flatpak on top.
As long as Red Hat wants to stay in business selling RHEL, Fedora as a distribution is probably not going away nor losing development focus.
Does flatpak support qemu emulation? Can I use it on arm to run x64 images?
No it does not. The metadata file includes the available architectures, and Flathub exposes it in the UI[0]
[0] An example https://flathub.org/apps/vet.rsc.OpenRSC.Launcher
Hopefully the money from selling apps can fund development like other app stores work.
Flathub introduced donations a few years ago and nothing really came of it
Edit: I could be misremembering, but there was an attempt to add donations. Maybe it was rejected
Interesting read. While Flatpak does work nicely for a lot of things, the downsides are real and have me almost preferring Snap for the most part. Flatpak terminal apps are annoying, the permissions thing is annoying, sound, etc...
Interesting that the creator is thinking about the next thing already.
> Flatpak terminal apps are annoying,
They could have been good, but they chose not to go down this route. This is one area Snap shines. Flathub rejects terminal only apps for this reason as well
Yet, there are a select few non-gui flatpaks. One I use frequently is Zola [0], a static site generator that I use because it's significantly faster in building my site with 'zola serve' than the native Alpine Linux package. All I had to do to make it convenient was aliasing flatpak run org.getzola.zola to zola.
[0]: https://flathub.org/apps/org.getzola.zola
Its more likely that its not a priority for RedHat and its harder to work on non priority projects in the era of mass layoffs or perfoffs.
Over here in Windows land I can’t fathom why you need something like Flatpak just so users can reliably launch and run a program. I mean trust me I understand that Linux is so broken it needs something like flatpak. But imagine saying you’re disappointed the Windows executable format isn’t evolving! Running an exe shouldn’t require decades of maintenance. It shouldn’t be that complicated. It doesn’t have to be.
> Running an exe shouldn’t require decades of maintenance. It shouldn’t be that complicated. It doesn’t have to be.
What do you think is all that stuff in C:\Program Files, C:\Program Files (x86), c:\Windows\System, C:\Windows\System32, C:\Windows\SysWOW64, %USERPROFILES%\%APPDATA%\Local and %USERPROFILE%\%APPDATA%\LocalLow or the seven versions of the C/C++ VS Redistributable you have installed?
EDIT: typos
in reality a bunch of stuff no user ever has to look at. On Windows literally anyone can click on a 20 year old executable and in all likelihood it just works because the good people at Microsoft care about giving the user a decent supply of libraries and stable ABIs and an actual operating system people can build against.
The Linux world is just in complete shambles in this regard. You build something on one LTS release, you don't know if it executes on the next. As the joke goes (it isn't even really a joke), it's so bad that Win32 is the only stable ABI on Linux
Thing is, .exe on windows is broken on so many levels. You don't have sandboxing, apps don't always follow standards as to where to store their data, there's no dependency management but if you don't have the correct version of e.g. java installed your app won't work. Etc.
Honestly, you have a point. At one point there was a proposal for a "Linux Standard Base", but none of the distros really cared (they had their special sauce), so it withered. If Linux app devs could target "LSB-2020" or something, it could be similar to Windows devs targeting a particular Windows version. Flatpak is basically a work-around to the distributions.
(Note that Windows also does vitalization for compatibility reasons.)
On another level, maybe it's just "in the name". Windows lets you run your GUI windowing programs, and that all keeps working. GNU/Linux lets you run 1990 base industry standard API programs, all that keeps working, but for anything else, all bets are off.
> Running an exe shouldn’t require decades of maintenance.
That's why windows is so full of malware and viruses.
It still irks me that AppImages (the unambiguously superior choice) are not more successful than Flatpak or Snap solely because Linux users (in their characteristic laziness) are only used to getting their software from monolith stores and repositories.
At least in the case of Snap, I felt that Canonical itself played a role in making it dominant in Ubuntu so that they could control the ecosystem.
Personally I use AppImage whenever it's an option. It's the closest we get to Windows and MacOS executable applications
Nice breakdown.
20 years ago: "Oh no, the distros are struggling over packaging! We've got apt, yum, dnf, rpm, nix, docker..."
https://m.xkcd.com/927/
For a long time, there was a pax debiana in my world. I used Ubuntu mostly (swapped to Debian and added Fedora towards the end) and the package management was really good. APT was a great tool and I got quite chummy with its ways. It was straightforward to keep my system updated and resolve dependencies. It was way smoother than any other updater system had been, even across major system upgrades.
I sort of lost it when snap started usurping stuff. I knew it was coming, because docker was already making inroads. Then we had flatpak and company. As an admin, as a system architect, I felt that's the point when I lost control of my system. It wasn't possible to know its update state anymore. It wasn't possible to centrally manage or monitor those updates. It became a free-for-all of self-updates and shadow updates. Ubuntu was also introducing livepatch and kernel updates that went outside the apt model.
I think that perhaps it became too great a burden for the major distros to be packaging all of their own downstream packages. Perhaps they saw the opportunity to offload some of that packaging burden on a really pro service that could just package everything, and make pan-distro packages available. If Debian and RHEL packagers are doing less downstream packaging, then perhaps they could focus on their core competencies. I noticed that nearly every Ubuntu package needed to include Ubuntu-specific tweaks, and basically when Ubuntu was already downstream from Debian, why should Canonical be maintaining every damn package themselves as well?
So what's the endgame for all this? Would apt or dnf/rpm eventually get abandoned and have them go all-in on a new system? Or does the proliferation and splintering continue? Many of us said that the beauty of Linux is our freedom of choice. Well there's too much choice. Look at Distrowatch and be paralyzed by not knowing what to choose. Windows or macOS on your desktop is easy to choose because there's... one of each.
When I visited Catalonia my friend took me to Carrefour. We strolled the aisles and I spotted pig-legs (jamon serrano) on every counter. A huge selection of eggs. Everything my stomach could desire. She led me into the olives aisle and gestured around to all the olives there. She said pick whichever I want. There were so many. They were all in fancy jars. I knew nothing of olives. I left without choosing any.
Linux will die a death of a thousand cuts, until some consolidation and unification can happen that's beyond the kernel.
>APT was a great tool you had me up until this bit lol apt's spaghetti of software and state assumptions is horrendous. the software itself functions mostly fine for those who havent used more modern package managers, but the user experience itself is a nightmare as soon as you start needing anything outside the distro's default repos
Look, no illusions or exaggerations here; APT is an imperfect tool and it's intricate, complex and unwieldy sometimes. But please consider the status quo ante. I've run Minix-286, OpenBSD, NetBSD, SunOS, HP/UX, and Linux, and in the years between 1990-2003, there were zero package managers in use.
Like literally APT did not exist, no predecessor existed, there was absolutely no package management for those systems. Or if there was, it was by script or some bespoke framework that came with the app you downloaded. There was 100% no system-wide management of what was installed on my computers.
I've been in states of recompiling the kernel from source. I've run those "./configure" scripts that came with GNU. I've fiddled with custom kernel configuration files and Tripwire databases that tried to keep track of everything there. I've applied patches issued by Sun Microsystems.
Absolutely none of that above jumble can hold a candle to the way we use APT today. I'm sorry you suffered nightmares and needed 3rd-party stuff. But it was a dream come true to type out a one-liner and have the system upgrade itself, accounting for all dependencies, replacing all necessary files, being aware of all config updates, leaving audit trails and versioned files. Simply like falling off a log at this point.
Who would ever go back? What can be simpler? It was simply the degrading of this unified control and the loss of a singular point of management that has begun to dismay us.
> until some consolidation and unification can happen that's beyond the kernel.
That's underway, it's called systemd.
Soon, something like Modal Systemd Installers: `systemd-msid`