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: 2) by krishnoid on Thursday November 25 2021, @06:10AM (1 child)
I'm wondering, though, if people could keep deploying these containerized apps as they do now. In addition, maybe there could be a background mechanism could collect actual statistics on which common components could be "factored out", and feed the info back upstream to creating more common, shareable pieces. Going out on a limb, maybe they could even be refactored on the PC itself after a few runs, but that's kind of a pipe dream.
I mean, I assume Debian provides a framework for guaranteeing the availability of shareable components, through their continuous dependency grinding during the testing process, so I always recommend that. Maybe it needs to be advertised better.
(Score: 3, Insightful) by bzipitidoo on Friday November 26 2021, @02:44PM
"common components 'factored out'" is the whole point of shared libraries!
Admittedly, the system has its issues. Not least is versioning, or "DLL hell" as it has been called in Windows. The reason Windows has that problem is political, not technical. It's all about profiting off the sales of binaries rather than source, the better to "protect" their imaginary property. Also MS used to charge big $ for the compiler, which is a separate item not included in Windows.
The way, THE WAY, that shared libraries work is by compiling against them, and you can't do that without source code and a compiler. Most Linux distros, including Debian, are basically collections of binaries that have all been compiled against the same versions of the same shared libraries. It is a lot of work to keep up all those binaries, as anyone who has ever run Gentoo Linux learned.
One of the things I find most upsetting about the likes of Flatpak is that it is turning to dubious uses the enormous resources we now have available-- the terabytes of storage and gigabytes of RAM in a typical PC-- by using all that to hide the godawful inefficiency inherent in NOT using shared libraries. And why? To woo proprietary software vendors?? It sure as heck doesn't do any favors to the users. I don't want to have to buy an extra terabyte of storage just for that. I don't want my computer thrashing because containerized libraries have pigged out on all the RAM, forcing the OS to resort to constant swapping. That's EGADS, Eight Gigabytes And Debilitatingly Swapping.
Another wrinkle that should be mentioned is that if a bug or security flaw is discovered in a shared library, a single update fixes it. But if a dozen different versions of that library are each packed into separate containers, updating them all is a lot more work.