SoylentNews is people
SoylentNews
Deploying apps for the Linux desktop is hard. A major problem has historically been library compatibility. Different Linux distributions, and even different versions of the same distribution, have had incompatible libraries. Unfortunately, there hasn't always been a culture of backwards compatibility on the Linux desktop.
This is finally changing. The stability of the Linux desktop has dramatically improved in recent years. Core library developers are finally seeing the benefits of maintaining compatibility. Despite this, many developers are not interested in depending on a stable base of libraries for binary software. Instead, they have decided to ignore and override almost all libraries pre-installed on the user's system.
The current solutions involve packaging entire alternate runtimes in containerized environments. Flatpak, Snap, AppImage, Docker, and Steam: these all provide an app packaging mechanism that replaces most or all of the system's runtime libraries, and they now all use containerization to accomplish this.
Flatpak calls itself "the future of application distribution". I am not a fan. I'm going to outline here some of the technical, security and usability problems with Flatpak and others. I'll try to avoid addressing "fixable" problems (like theming) and instead focus on fundamental problems inherent in their design. I aim to convince you that these are not the future of desktop Linux apps.
Suppose you want to make a simple calculator app. How big should the download be?
At the time of this writing, the latest KCalc AppImage (if you can even figure out how to download it) is 152 MB. For a calculator.
This is uncompetitive with Windows on its face. If I ship an app for Windows I don't have to include the entire Win32 or .NET runtimes with my app. I just use what's already on the user's system.
Other solutions like Flatpak or Steam download the runtime separately. Your app metadata specifies what runtime it wants to use and a service downloads it and runs your app against it.
So how big are these runtimes? On a fresh machine, install KCalc from Flathub. You're looking at a nearly 900 MB download to get your first runtime. For a calculator.
[...] Snap and Flatpak in their current incarnations have been around for at least five years. AppImage, Steam and Docker have been around even longer. None of the above is new. The problems with alternate runtimes were known from the very beginning, yet little progress has been made in fixing them. I don't believe these are growing pains of a new technology. These are fundamental problems that are mostly not fixable.
All of these technologies are essentially building an entire OS on top of another OS just to avoid the challenges of backwards compatibility. In doing so, they create far more problems than they solve. Problems of compatibility are best solved by the OS, the real one, not some containerized bastardization on top. We need to make apps that run natively, that use the system libraries as much as possible. We need to drastically simplify everything if we have any hope of attracting proprietary software to Linux.
The full article is a very interesting read.
(Score: 5, Insightful) by Subsentient on Thursday November 25 2021, @12:11AM (8 children)
I hate Snap and Flatpak and all that containerized shit. If you're that paranoid about the software you're running, you shouldn't be running it at all. If you need to distribute a proprietary program on Linux, let me tell you how I personally prefer you do it.
1. Install all required shared libraries into a folder with your executable.
2. Make a shell script launcher that does this:
3. Make it into a tarball, and give me the tarball.
4. Profit!
"It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti
(Score: 3, Informative) by bart9h on Thursday November 25 2021, @12:55AM
That is exactly what Firefox does.
I mean, if you download the binary from their page, instead of installing your distribution package.
(Score: 4, Insightful) by Anonymous Coward on Thursday November 25 2021, @02:31AM (1 child)
This has the same major issue as flatpack and snaps (also static compilation). No system-wide security updates for vulnerable libraries.
If an application just dynamically links to the libraries provided by the distribution, and say an openssl exploit comes out, you can have everything on your system that uses openssl patched with a single distribution update to the openssl libraries. Contrast this to every random application distributing its own library versions-- now you have to wait for *every* random application provider to distribute patched libraries.
Also (a general complaint about flatpack et al), one of the great things about Linux distributions is that everything you need comes from a single trusted source via the package management system. Why the hell would we want to give up that to emulate the disaster that is the windows way of distributing applications each from a separate, random site where you really have no idea if you are installing malware. I'll keep my package manager, thanks.
(Score: 2) by Subsentient on Thursday November 25 2021, @07:38AM
Yeah that's true, I would definitely prefer if vendors used dynamic linking and actual builds for recent distros, but sadly that's too much work for them to be bothered with much of the time. At least with my approach, it's portable, easy, and doesn't require a special container format.
"It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti
(Score: 2) by Unixnut on Thursday November 25 2021, @02:46AM
There was an attempt to standardise things in Linux-land, "Linux standard base" (https://en.wikipedia.org/wiki/Linux_Standard_Base) , but it turned out that the different distributions just could not agree on a standard base, which is why that fell by the wayside in (according to the wiki) 2015.
I guess realising that it was futile trying to get every Linux distro to agree to a standard userland, the second option was to just abstract the userland away. This was done with Linux containers, which allowed each process to effectively have its own userland, and only share a kernel.
This is not a new concept, having existing on IBM big iron for decades, Solaris "Zones" and BSD "jails" for years. However on those systems the technology was used more like a "VM-lite" option, when you did not need the full isolation of a VM, with the performance overhead. This is because these Unxies had few variants with little variation in the base userland. None of them had hundreds of different "distros", each with their own idea of how the userland should look.
As such, Linux containers (via Docker) became effectively a software distribution system, where instead of just installing a package, you install the package and the entire userland it has been built and tested with. It is a resource hog of bloat, but it sidesteps the "different userland problem" in a way that is easy for the software developers. They don't have to test and code for every userland. They just decide what userland they want, build and test with it in containers, and when it passes QA just ship the entire thing as a Docker image.
As long as the Docker people build a version that works with your userland, you can be pretty much assured any Docker image will run on it. Hence why (for better or for worse) it has become one of the main methods of software distribution on Linux.
(Score: 0) by Anonymous Coward on Thursday November 25 2021, @05:34AM
These were the logical result once computers got enough power to actually do this reasonably well. Distribution maintainers and library authors have been HORRIBLE with backwards and cross compatibility, particularly binary compatibility, and even though many dislike it, most people care about binary compatibility more than source code compatibility.
Furthermore, even if you only care about source code compatibility, getting a lot of packages to build and run these days is a non-trivial endeavor, often resulting in a maze of dependencies (which may need to be compiled themselves) and the various tool chain everybody's-junk-in-the-trunk baggage for every language that so much as breathes on the thing, because it's a foreign concept that anyone would use boring ol' make these days.
(Score: 2) by mth on Thursday November 25 2021, @08:15AM
If you care about security, you should always be slightly paranoid. Even if the developers have the best intentions in the world, bugs could mess up your system and supply chain attacks could compromise the build. Giving applications only the permissions they need is just sensible; it's why we don't run everything as root.
There are problems with the current application container systems for sure, but I don't think containers themselves are the problem. Servers have been running in container-like fashion (chroot, jails) for years. Sandboxing desktop applications is more difficult and less urgent, but I don't see any fundamental reason why it would be a bad idea.
(Score: 2, Insightful) by shrewdsheep on Thursday November 25 2021, @08:33AM
If you hate these solutions, why do you suggest exactly the same thing? A container image is exactly what you suggest: a file container that is extracted into a folder and run from there with the additional benefit of being more strongly isolated and often using an overlay filesystem to safe diskspace.
Unless library versions (including configuration options) are fully standardized across distros and many library versions are allowed (which most distros do not) there is no way around these solutions. I prefer the diversity of distributions and try to minimize the use of flatpak and friends. To me it should be a 99/1 solution. The dstro should package 99% of my packages. 1% I am willing to install through one of the mechanisms.
(Score: 2) by FatPhil on Friday November 26 2021, @08:10AM
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves