Most of the issues that are expicitly mentioned are fixable bugs and not fundamental design errors. In the end it seems to come down to poor package repository maintenance, which many repositories for Linux distros suffer from. While I do not like the idea of flatpak very much myself, this criticism seems too harsh to me.
The fact that many desktop applications need access to $HOME and that $HOME also conveniently provides arbitrary code execution via .bashrc/.profile/etc is kinda fundamentally at odds with doing filesystem sandboxing of desktop apps.
Sure, flatpak isn't making things worse by not being able to fix the fact that desktop users expect to open $HOME/screenshot.png in gimp, but it's also not going to easily fix that.
This is fixable on android / chromeos by specifically having applications request access to data which is isolated from arbitrary code execution (e.g. "user files" which don't include .bashrc). I think flatpak may need to ultimately have a custom file-browser where the user can "share" subsets of files into a sandbox and then patch applications to use that file browser... or to otherwise build a new filesystem abstraction.
Until then, this issue will be tricky to fix. I, of course, agree with your main point that things like updating packages more is fixable and the post is overly harsh and critical of what's effectively "things aren't perfect" with no empathy for how complicated stuff can be.
This is fixable on android / chromeos by specifically having applications request access to data which is isolated from arbitrary code execution (e.g. "user files" which don't include .bashrc). I think flatpak may need to ultimately have a custom file-browser where the user can "share" subsets of files into a sandbox and then patch applications to use that file browser... or to otherwise build a new filesystem abstraction.
If you Flatpak a Gtk+ 3 or modern Qt application you get portals for free. E.g. I packaged a Qt application and I am not sharing the home directory - when the user opens a file it uses the Qt/KDE portal (similarly to macOS, ChromeOS, etc.).
As far as I understand the problem is that portals are only available for Gtk+ and recent Qt versions. Some of the applications that the posts mentions use toolkits that probably don't support portals (Java JDK, wxWidgets, etc.).
The situation for Linux is a bit different than e.g. macOS, where practically everything uses Cocoa and Apple could just throw the switch.
So, for applications that do not use vanilla Gtk+ or Qt they still need to make the home directory visible or they would not be Flatpack'able.
The situation is similar on Win10 (and the approach is also the same - sandbox apps have to use a certain API to invoke the file browser and get access to some files or folders).
But apps that don't do that because they're too old, just don't get access to the Store... or at least they didn't use to. Now you can ship non-sandboxed Win32 apps through the Store, and it doesn't even seem particularly obvious which ones are and which ones aren't. Windows 10 S only lets you install the sandboxed ones, but how many people use that?
So basically Windows couldn't solve that - the users ultimately decided that they care about stuff working as it did more than they did about security. I don't see why it would be any different on Linux.
I don't see why it would be any different on Linux.
There will always be legacy applications that will stay on old toolkits and they cannot fully benefit from sandboxing.
However, a lot of widely-used Linux applications that are on older toolkits are currently working on upgrades. E.g. Inkscape and The Gimp will be Gtk+3 applications. There are often other carrots, such as proper support for scaling for HiDPI screens, etc.
Forcing applications to use a separately defined and maintained file dialog is impractical in my opinion. There are lots of ways in which file access can be presented in a user interface.
The problem is rather caused by filesystem layout conventions. I think that a better solution would be to split user home directories into two classes of files: data (that is, files that the user typically wants to see and work with as part of the normal workflow) and "user profile" kind of stuff (.bashrc, configuration files, etc...) that should be "privileged" and require special access rights. These might require interactive confirmation before write access is granted (similar to the split user accounts in Windows with UAC). However, I wonder if these sets of files can be separated cleanly. Marking files as "privileged" should be doable using extended attributes, though.
A poor package repository is a consequence of too many packaging formats, and lack of volunteer maintainers, though (I, too, could have made more to help). So coming up with package formats all the time - .deb, .rpm, .apk, Alpine's pm format, pkg, .dmg, flatpack, snap, docker and whatnot - is exactly the problem (cf. https://xkcd.com/927/). Maybe Slackware got it right after all by only building from upstream .tgz source archives. We'll see in a decade or two what software is even remotely in a usable state still.
Those aren't "package formats"; they're different names for a very small set of actual container formats (e.g. tar, zip), with the names there to namespace different incompatible OS file-layout hierarchies and sandboxing technologies.
If it was just about packaging, everyone would just have a build server that creates their binary once and then slams it through https://github.com/jordansissel/fpm.
But there are more fundamental differences between OSes than how the insides of their packages look. The packages are "differently shaped" to prevent you doing something stupid and damaging your OS by installing a package that will spew files in all the wrong places, and rely on classes of protections that aren't there.
Hmm... it's almost like maybe applications shouldn't spew their files all over in the first place, then you wouldn't have to worry about putting them in the wrong places...
If you can tell me what a self-contained equivalent to, say, the libpam package would be, I’m all ears.
Oh, also, a subset of case 2 is: packages that contain servers need to register the server as a service with the OS’s init system, and every OS has its own init system that expects a service definition file in its own distinct format and location.
libpam should be part of the base system, obviously. Like the widget library, ssl, and the display server. It's only really in UNIX world that this separation between "system" and "application" doesn't exist.
OS packaging formats exist for the "base system", in your terminology. "Applications", in the UNIX world, install in /opt.
Keep in mind that the separation you're talking about is very thin, often non-existent, in any OS. Consider, say, an RDBMS daemon. Is that an application, or part of the base system?
An application? You're sure? But what if components of the base system rely on its presence?
This isn't some wacky idea, and it's not a UNIXism, either. Some components of Windows Server rely on MSSQL. So MSSQL has to be built as a Windows component, rather than a standalone application.
This example helps a lot in understanding what OS packages really are. For example, why do Linux distros package scripting languages like Perl, Python, Ruby? It's not for you to use them to write system administration scripts. It's definitely not for applications to use as their runtime. (All the major distros recommend that you vendor your own runtime into your application, if you're creating a standalone application.) No, the point of these language-runtime packages is that there are system components written in these languages, and the OS package is there to support them.
And this is why you're supposed to install your own copy of these when using them for development: the OS copy isn't maintined for you. These OS-packaged runtimes are frequently not up-to-date, and they bundle with them some of the language's package ecosystem, but not all—and frequently not even the most popular language packages.
That's because the runtime isn't there for you. It's there for the OS to use. It may as well be hidden in /usr/libexec and not even in your $PATH. (Except that $PATH is frequently how system components find one-another.)
People make a mistake when they think it's a good idea to package their applications as e.g. Ubuntu PPAs following the Debian packaging guidelines. That format, and those guidelines, exist for the authoring of system components; the guidelines are the way they are (i.e. very strict) to enable other system components to rely on your component.
If you're building an application, none of that applies.
Until recently, applications on UNIX shipped as tarballs containing ./install.sh scripts that you'd have to run as root, that would unpack things into /opt but also maybe write some service scripts into /etc/init.d. (Even now, this is how heavily-integrated applications like VMWare ship.)
More recently, Docker has replaced this format when packaging applications that don't require much of the underlying platform (e.g. network servers.)
Flatpak and Snaps are two attempts to do for GUI apps what Docker did for network servers.
Unlike OS packages, Docker, Flatpak, and Snaps are all interchangable and inter-convertable as long as you have an application that only requires their least-common-denominator subset of capabilities. A Docker "package" can be repackaged as a Flatpak or Snap losslessly. There is no reason that the Flatpak and Snap ecosystems can't proxy through to Docker Hub and let you pull any Docker image and run it under their daemon. There's no real war here.
The reason applications spew files all over the place is because that's how you hook into other systems. Want a man-page? There's a folder for that. Want to autostart? Folder for that. Want your program to be runnable without specifying the full path? Put it in path.
The reason configuration sucks is because we use filesystems, which are necessarily hierarchical, when we should use a more general database.
If we had a table where the first column was "thing to be configured" and the second column was "program" things would be much better. We could query by the first column to get e.g. all programs that want to automatically start, or all programs in path. Or we could query the second column to get all configuration for a given program.
Database people have done a lot of work on how to prevent inconsistent state, and we are stupid for not leveraging that.
> Database people have done a lot of work on how to prevent inconsistent state, and we are stupid for not leveraging that.
It's kind of amusing that on the Windows side, you have a vertical integration between the filesystem (NTFS) and the update mechanism, where any MSI package will actually be installed in a filesystem transaction, such that if you e.g. cut power in the middle of package installation, then your disk will actually have nothing of the package's installed data on it. The transaction failed, and was rolled back.
And yet, even with that fancy tech in place, uninstallers still are manually-written apps that blow away files by explicitly naming them, rather than also taking advantage of these filesystem-level transactions together with some sort of hypothetical transaction WAL log, to reverse what the install did.
Open source doesn't ensure it'll even build against new compilers, libs, language runtime, and all the other stuff we're reinventing all the time to keep the hamster wheel spinning. What open source desktop apps are you using that need sandboxing anyway all of the sudden? GIMP, Inkscape, Audacity? Come on.
Yep - all of those. GIMP has scripting capabilities and exposure to vulnerabilities via image codecs, same as Inkscape, and Audacity could be linked to ffmpeg, which is a huge attack surface.
