How has FlatPak failed?

> Sand-boxing and being able to fine-tune the interactions with the host system and the Internet an app is allowed to perform is a feature absurd to be lacking.

Are these features lacking? I mean I can open flatseal and go disable Geeqie access to network and filesystem, so not sure how it is lacking - maybe I'm missing something.

Of course if I disable Geeqie access to the host FS it kind of defeats the purpose of the app, but at least I guess you can technically say it failed in that for Geeqie to operate as I expect it to, it needs access to the host fs.

EDIT: Seriously though, I am not sure how most of Gimp, VSCodium, PyCharm, Octave, Inkscape, Audacity or VLC will be useful to me or anybody else without host fs access.

Where the heck do you keep your stuff if not on your fs?

If you want to go fiddle with the specific directories that option is available to you in flatseal.

And I just had a look at some other apps like Bitwarden, Teams and Spotify, and there the permissions is much more constrained, for example none of those have blanket access to the host fs or home directory. Spotify for example is limited to xdg-music and xdg-pictures.

Another EDIT:

flatpak also does support blacklisting of directories, see nofilesystem in https://docs.flatpak.org/en/latest/flatpak-command-reference...

I think support for this is lacking in flatseal currently but I'm sure it is coming.

Epistemic Status: I've been thinking about this for a while, but have not decided on any conclusions yet.

More and more, I view flatpak-style sandboxing as something kind of like wine. It's very important that it exists, as a stop-gap measure to allow people to run the programs they currently depend on. With wine, that's Windows-only programs; for flatpack it's proprietary applications, while retaining some control over their permissions. But it's not an ideal long-term solution.

Using wine in the ideal way requires creating gigabytes of duplicate files (since you want to run one program per prefix, since they may require different and incompatible tweaks). Both it and flatpak make it harder to write shell scripts and generally to hack on your operating system. More importantly, both solve problems that, while they aren't going away any time soon, could be solved just by using high-quality, trustworthy software that targets GNU/Linux natively, without the downsides of these technological solutions.

So, while I do use both of these technologies and appreciate them very much, I prefer native packages and would rather put my effort toward better supporting people who want to write software that is distributed that way.

I run inkscape from flatpak in my makefiles so it is not that bad.

> Are these features lacking?

I mean they are lacking if we don't use Flatpack or an alternative so we have to either use it or invent something better.

> Seriously though, I am not sure how most of Gimp, VSCodium, PyCharm, Octave, Inkscape, Audacity or VLC will be useful to me or anybody else without host fs access.

I don't need any of these to access anything outside a specific directory (or a small selection of such, but I don't need them to access the full home dir, let alone the full root fs, even for reading). Hopefully flatseal can do this.

> Are these features lacking?

Well, as I said I see them in flatseal so either flatseal is misleading or the features are there, and I have no reason to think flatseal is trying to deceive me so I assume they are there.

> I don't need any of these to access anything outside a specific directory (or a small selection of such, but I don't need them to access the full home dir, let alone the full root fs, even for reading).

Fire up flatseal and change the permissions to what you want it. I'm sure you can also petition for xdg-code directory or something and then keep all your code there and request the packages be changed to default only work under there but I suspect most people would not be so happy with this.

I am not sure how you expect the package maintainers to know where exactly on your FS you keep your code, I also don't keep mine in my home directory.

And maybe a blacklist would make sense, but if all that is needed is a blacklist then I would harldy say that flatpak failed because it is not really that difficult to fix that deficiency.

EDIT: Actually blacklisting is supported, see --nofilesystem in https://docs.flatpak.org/en/latest/flatpak-command-reference...

So really everything is there, maybe everything is not available in a nice neat UI, maybe the UX is not what it should be, but the core underlying system is not "lacking" these capabilities AFAICT.

You've misinterpreted me. I don't say Flatpack is failed because it is "lacking" these capabilities. Quite the contrary. I mean we need Flatpack or something alike because that's what they offer. BUT Flatpack and Snap (and some other alike, I can't remember, there were 2 more) seem failed because everybody around seem hating them. There are just so many negative comments around. Therefore we probably need something like Flatpack but way better so people wouldn't be dissatisfied.

If you must open flatseal config, it's a bad system. What should happen is that everything should be forbidden by default, and attempts to access files or dirs are individually approved (if the file is opened interactively, it's naturally part of a trusted system file picker that approves the access and gives the filename to the app when you click the selection button), and you can make large config edits if you want to.

Seems like a pretty good idea, and it would be a nice if someone added this functionality to flatpak. I am still happy that flatpak is there because it is better than nothing and for most apps I use it with the permissions is exactly as I expect them to be.

> I don't need any of these to access anything outside a specific directory

What's wrong with firejail?

No amount of inventing new formats and technologies will solve any major problem under Linux because the ecosystem is not developed by a single vendor. Any solution will not be uniformly adopted and there will be multiple competing solutions, lacking various levels of polish. Also the money under Linux is with servers, so unless that changes, the desktop landscape is never going to approach MacOS or iOS cohesiveness. Too many ideas, too many projects and efforts, too little top-level organisation and too little time or monetary interest for consumer desktop solutions, especially by the largest players who're all focused on the server and cloud and any benefit for the desktop is incidental.

That's not very useful way of thinking.

.deb packages format for example are quite uniformly established and provide a lot of interfunctionality on many different systems. Of course you are going to find other obscure systems and even big other ecosystems (RedHat obviously, and derivatives), but the format we are looking for doesn't have to be the single one either. It just has to work well enough and be somewhat universal. .Deb-level of universality would suffice just fine.

.deb is a format in the same way that .tar.gz is a format. If Fedora or Arch used .deb the problem would no better because each distro has its own package names, its own package versions, and its own downstream patches.

That's subjective. IMHO the Linux UX (including both usability and aesthetics) has been improving steadily during the last 20 years as I've observed it. And the only reason I use Linux (Manjaro with KDE Plasma) is my experience is "like Mac but better" (perhaps it's worse in some aspects I don't know).

True, as a long time Linux user, it is true that the ergonomics and state of the art has steadily improved, but its competitors on the desktop have also been steadily improving all the while, and they had a considerable head start, so Linux sadly always tends to be almost there but not quite. That is why Canonical expressly targeting user desktops when they started out was a watershed moment, but sadly, that did not sustain because of failed monetisation.

Many people seem to moan that Windows 7 is still the best Windows and that macOS has been on a downward trajectory since Snow Leopard, or whatever. Is it so obvious that other OSs are actually advancing and leaving Linux in the dust? For example I don’t find Windows new app packaging and sandboxing (Store apps) to be much of an improvement over anything.

Could you outline some of these improvements?

I mostly stopped using other operating systems a long time ago, so my impressions of them are partially ouit of date, but for my previous job I had to use a Mac for development, and lately I'm experimenting with Windows in some virtual machines in order to automate the setup of certain tools for Windows developers. In neither case have I seen some desktop environment feature and thought ‘Wow, I wish I had something like that on Linux!’.

Linux is not an operating system or a platform, it's a kernel. Ubuntu, RHEL, Suse etc are operating systems, but more importantly they are separate independent operating systems. Their interoperability pretty much starts and ends with POSIX, everything else being more of a happy coincidence. And many of those major Linux-based OSs have strong vendor behind them.

Same way you don't expect cohesiveness between macOS and Windows, I think it is bit unreasonable to expect cohesiveness between RHEL and Ubuntu or whatever.

POSIX had a patch update 3 years ago, a minor update 12 years ago, and a major update 19 years ago.

That's the problem.

The desktop distros could and should have done a lot better to coordinate on fundamentals of user experience in the age of the open/hostile Internet and frequently updated software.

POSIX does not know much about desktops really. If you want coordination in fundamentals of desktops, look at Freedesktop specs https://www.freedesktop.org/wiki/Specifications/

Thanks for the referral!

Unfortunately the website isn't loading for me. Wikipedia shows their projects seem to be focused on lower level graphics/UI issues, but not app packaging and security issues that have become very important in past 10 years.

FlatPak was freedesktop.org's app packaging and security project for a couple years, when it was still called xdg-app. It's hosted on github today.

https://blogs.gnome.org/alexl/2015/06/24/xdg-app-moving-to-f...

https://freedesktop.org/wiki/Software/Flatpak/

Another way of saying this is that flatpak and snap try to solve what's ultimately a social or policy problem by technical means. Building an abstraction layer like flatpak does necessarily entails a lot of complexity for at best a 90-percent solution; for instance, you still have to worry about what version of flatpak or xdg-desktop-portal each distribution has.

Speaking as a user, not a dev, I don't really understand what you are referring to. There are "multiple" solutions, namely 2 (two). Both of them work on all distros, so I could not care less which one you pick.

Same for desktops, again there are two: gtk-whatever and qt-whatever. All software works on both of them, so again I don't care.

Same for installing software. Installing Wolfram Mathematica is literally downloading one file, clicking on it and pressing Enter a few times.

If anything iOS and its appstore showed that the repo model is great and there is a reason why microsoft developed/copied "winget".

As a user, you're missing details, and completely misunderstand several abstractions.

For instance, gtk and qt are not desktops. They're ui toolkits. Bunches of widgets that can be composed to cobble together a UI.

That's completely separate from the topic under discussion, which is mode of application delivery. FlatPak involves using namespacing and containers to "spin up" a virtual system with only visibility into those slices of the overall host needed to run the program.

This is good because it at least keeps unfamiliar software constrained somewhere predictable, but poor because often it won't use OS host libraries, which are generally kept the most up to date, and worst of all, enforces a complexity and debuggability tax where one has to have an intimate understanding of what is going on "in the box" if something goes wrong.

Other ways mentioned are the distro model, whereby distributions maintain repository ecosystems and make decisions with regard to FHS compliance, system tooling, update pipeline, etc..., and use those to support their user base.

There is the original "compile and stage it yourself" crowd, who basically concentrate on reproducible build capabilities, but tend to lack in automatic dependency resolution.

There's the Mac way, which isn't terrible. It tracks and designates places for libraries, Frameworks, and Applications, and has a lot of automated and well integrated ui-tooling which makes the user experience of software install easy, but it's just another paradigm you have to track when trying to write portable software.

There's static linking, which delivers executables that are entirely self-contained, but tend to be bigger memory footprint-wise, each have an upgrade path separate from every other executable, and benefit not at all from dynamic linked libraries on the host system.

Then finally, there is dynamically linked executables. They're small, commonly reused code is loaded once in memory you have the additional complexity of the linker to be aware of, but you can update the entire system's audience of a particular library at the same time... Which can be a double-edged sword given how the maintainer scripts the install or sets up their system/build environment.

Personally, I just sidestep the issue myself by digging into and learning about software I use on a regular basis with disassembly tools, and treat all of my systems the way a good farmer treats their livestock. Distant reverence, but with a careful eye as to whether there is something wrong, and a hard fought for willingness to kill something and start from scratch. It's the only way I've found to be truly safe and resilient in an environment where everyone optimizes for their own particular definition of convenience.

(My definition of convenience is a minimum difficulty in troubleshooting what might be wrong, so I favor fewer abstractions as that entails less Tower of Babel to wade through).

Full disclosure: my approach generally would classify me as a bit of a curmudgeon in the industry as I still approach computers as being analogs of physical machines. There is a healthy corpus that revels in abstraction, but I'm not really one of them. I like to have a ballpark understanding of what the artfully arranged beach sand is doing. Adding more abstractions or having the computer do things itself is generally not something I strive toward as it almost always comes with an unacceptable increase in the overall complexity inherent to navigating the Gulf between how I and everyone else thinks the system works and how it actually does.

More than anything else, in my experience, keeping that Gulf small leads to better overall satisfaction from a lay User. YMMV.

> For instance, gtk and qt are not desktops. They're ui toolkits.

And I never claimed that. Again, as a user the difference between gnome, cinnamon or unity is not all that interesting, so I simply wrote "gtk-whatever" as an umbrella term and "qt-whatever" for kde plasma and lxqt.

My basic question is the following:

- If I find software that is only available as a snap, I will use snap. It works on any distro.

-If I find it only available as a flatpak, I will use that. It works on any distro.

- If I find only an app image, I will use that. It works on any distro.

- I get an installer from some big commercial software. It unpacks itself in /opt or uses a docker image or... . Again works anywhere.

Why should I, as a user, care which distribution mechanism you chose if they all work anyways? Why is "fragmentation" an issue, if whichever you choose works everywhere regardless?

As a user, you will eventually be limited by the decision that developers/maintainers decide on.

Want to run your program, but I only support something for hardware that supports full client virtualization, which your system doesn't have? Oh well.

Oh, you wanted to run that Snap, but the cache is invalidated or cleaned, and no internet connection? Oh well. Sucks to be you.

Oh crap, you need to do that one final fix real quick in that one program, but oops! I just force pushed out a functionality breaking security update! Sorry bout it!

It may not seem so important from the casual user perspective, because you may not sample different configurations or distribution channels as devs/maintainers/admins, but you'll hit it one day, and you'll be as pissy as we are. Why doesn't this shit just work?

And the answer is, because it isn't magic, and it has to get to you somehow. Again, I hedge on the side of being deliverable with the simplest set of abstractions possible, and I'm old enough to remember when complex things actually came with manuals; so I prefer that delivery and understanding the ins and outs of the tool. You don't get that with FlatPak or Snap without cracking open the container which is far beyond most average computer users, and I place value on people being able to easily learn how to program, utilize, or reason about computers better, something that no container will ever teach you; especially given that in order to understand them you need to already be pretty deeply immersed in the mechanics of computing.

On the other hand, a zipped workspace with some tooling, READMEs and documentation can make for hours of discovery and familiarization with system fundamentals.

It's an approachability thing, and we've totally lost touch with it as a modern industry in my opinion.

Is that the Mac way?

This is how you run a third party Firefox binary package downloaded from Mozilla:

   tar xJf firefox-x.tar.bz2 ; cd firefox ; ./firefox

Most third-party commercial applications (CAD software etc.) is similar.

Obviously there is room for improvement here, for some basic sandboxing (chroot, dedicated uid and so on) and desktop integration (give the user an icon to click on, links to other applications).

It's just that Snap (and probably Flatpak too) just isn't it. Much too heavyweight and gave the users other things to worry about (disk space, updates, new types of package repositories). Something more fit for Linux culture would probably be closer to a set of best practices (this is what the executable is called, this is where libraries are put, there should be an icon here in this format), and let a thin wrapper handle it all.

Not fully. MacOS applications are nothing more than _APP_NAME_.app directory with an internal structure and manifest files that denote it is an application so when double clicking on the directory Finder knows to run the actual application binary located with-in the directory. This allows for decoupling the resources from the binary. Had to place multiple 3rd party binaries here in case the end-user didn't have them installed and used them as a fallback.

Most 3rd party applications are actually an installer script that places the contents into /opt/_APP_NAME/ or where ever the end-user requests they be placed.

The closest I'm come to mimicking Mac style on Windows to create an installer that does not actual install but extracts the contents to user's temp directory and executes the application. Needed a simple solution so the end-user just had to download and double click to run the application since they might not have admin rights to install the application.

I actually prefer the MacOS style since installing and backing up applications or moving to a new computer is the same process.

> The closest I'm come to mimicking Mac style on Windows to create an installer that does not actual install but extracts the contents to user's temp directory and executes the application. Needed a simple solution so the end-user just had to download and double click to run the application since they might not have admin rights to install the application.

I create these self-extracting packages all the time too. Getting the icons and such right on the package can be a bit of a pain so I made a quick script[0] to automate the process. You may find it useful too.

[0]: https://github.com/pR0Ps/make-sfx-package

No. The Mac way is download the app file disk image, click to mount it, drag the app file from there to the Applications directory, click to unmount the image the way you unmount USB flash drives. Perhaps I would also suggest removing the disk image part to further simplify the procedure. A user should not be forced to enter any terminal commands or even understand what an archive (or an executable installer) is. We must take "stupid" users in account if we want to conquer the desktop market as they are the majority we have to conquer.

Big Sur fortunately addresses the unmount step. It prompts you to unmount/trash the .dmg file when the install finishes.

What do you mean with "the install finishes"? If you mean a .pkg install, then previous macOS version's already prompt to unmount and trash the dmg file in that case.

Parent showed the general process. The implementation can change. If you're in any recent Linux desktop, you can click on the archive and it will open in file explorer so you can copy the app anywhere. No commandline required.

That simple way is ok but it misses all the small details of the Mac os install - a canonical place to copy the installed program, a nice icon to launch it with, file associations and so on

Disagree.

flatpaks provide apps that weren't packaged before. They provide easy an easy way to install apps that are bleeding edge and may have used newer versions of system libraries.

> The Mac way of installing apps (by just putting the packages into a dedicated directory) is cool and intuitive

1) They don't need to be put in a special directory to work.

2) AppImage is the most prevalent implementation of this concept in Linux (and it is indeed great).

> They don't need to be put in a special directory to work.

I know but AFIK that's the way that's meant to be done.

> AppImage is the most prevalent implementation of this concept in Linux (and it is indeed great).

Why don't we give FlatPack and Snap up to just use AppImage then? Chances are AppImage also has some cons and is inferior to Flat pack in at least some ways.

In theory Flatpak allows for sharing of dependencies and has sandboxing built in. This comes at the cost of needing special tooling, a repo, and non-portable (portable here meaning you can put the files wherever you want) applications. In practice you're probably better off using Firejail or the like on AppImage if you want the sandboxing anyway, because of things like the issues noted in the article. Snap is like Flatpak but even worse because it is entirely controlled by canonical.

Anarchy. Steve Jobs / Tike Cook can declare one package format for Mac. No one can do that for Linux. With a single distro leadership can sometimes do it, but there isn't enough funding to solve problems within a single distro.

The awesome idea behind is Nix. Please, everyone just go use Nix.

That's easier said than done, since I think Nix has a somewhat steep learning curve.

However, what I'm missing in most comments here is that - if I'm not mistaken - Flatpak and most others are essentially tailored towards distributing binaries, which is at least my personal gripe with them.

The reason is that especially with Nix I'm used to ad-hoc `.override`/`.overrideAttrs` and patch software in ways I'd like them to behave rather than being degraded to being the sole user of a software not supposed to be modified.

Flatpak, Snap and even Docker go the opposite route, which essentially degrades FOSS to essentially proprietary software, if even upstream would just point you towards "just use the Flatpak"™.

Others here also have suggested that it would be a good way to only distribute proprietary software, but as a Nix user who's packaging and patching (well, and reverse engineering) proprietary software I'd even disagree on that, because patching the environment and the entire dependency graph is something very useful which you'll lose with Flatpak/Snap.

How has Snap failed? Snap lets you install apps like Spotify easily on linux and in a security sandbox. Also snap doesn't have the main issue listed in this article of every app needing filesystem access. Snap has the personal-file interface which you need explicit permission to upload a snap to the Snap Store that accesses this interface: https://snapcraft.io/docs/personal-files-interface .

Source: working on a open source snap applications (without the personal-file interface despite being able to install packages into the sandboxed $SNAP_USER_DATA directory): https://github.com/argosopentech/argos-translate

Flatpak has portals for the same purpose. Unfortunately, many apps don't support portals yet. The Flatpak for Spotify does not allow access to home, only to the music directory (read-only). So, it's running in a proper sandbox too.

I don't use Spotify, but have you tried using Flatseal[0], to modify the folder access of the application?

[0]: https://flathub.org/apps/details/com.github.tchx84.Flatseal

I'm thinking that good standard practices and abstractions for SELinux and, optionally, per-application users would go a long way to solve these problems.

Situation: There are 14 competing standards...

Obviously. Buе this principle should not be followed fanatically. In the real world there are cases when a new standard can be introduced for good and take over. You just have to thing twice before inventing a wheel - to make sure it's going to be sooooo much better that it's worth it.

In this actual situation we have ther isn't going to be "14 standards" because there is no standard (for packages of this kind) so far, only a number of candidates. The first one to be good enough will become the first standard.

Why do applications have to be installed from strangers?

If you're unfamiliar with computers then you should only use things sandboxed as heavily as web pages or native apps that have been carefully reviewed by operating system maintainers.

If you know enough to make a useful decision on the safety of an app than you can probably build it yourself from github.

This practice of flinging binaries around is only useful for "software markets" and almost always seems to end up distributing the most pathological garbage possible.

Holy shit I hate this opinion. The best thing about personal computing is being able to build software and just pass it around easily. Having to rely on a third party to be able to install software is awful.

I'm absolutely not suggesting you rely on a third party. It's very easy and preferable to pass around source code, and it's (by design) very easy to build GNU/Linux apps from the source.

Distributing binaries will absolutely bring about calls to lock computing down to 3rd party distributors because the kind of people that can't handle typing `./configure` are the same kind that will pull random maleware off of google.

No good can come from installing closed software anyway.

> I'm absolutely not suggesting you rely on a third party. It's very easy and preferable to pass around source code, and it's (by design) very easy to build GNU/Linux apps from the source.

Yeah, it is so easy that no one ever uses containers to ensure a consistent and working build environment for software!

Oh wait, yes they do.

If your application is that complex then yes you probably should be working with it in a container.

There are decades of very good desktop applications that are simple and easy to build. Flatpack will just encourage things like slack.