Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Wednesday November 24 2021, @11:34PM   Printer-friendly
from the bloat dept.

Flatpak Is Not the Future:

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.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Interesting) by boltronics on Thursday November 25 2021, @08:57AM (2 children)

    by boltronics (580) on Thursday November 25 2021, @08:57AM (#1199492) Homepage Journal

    I wonder what the author thinks about Guix?

    The OS allows multiple versions of libraries to be installed simultaneously, but you generally won't have to (or want to). Host OS libraries can also be linked into containers built using the OS tooling. As such, the libraries a container and host uses are usually the same, eliminating efficiency concerns, while still achieving the desired level of application isolation where required. Often, containers can be built in an instant since the creation process simply creates symlinks to the host OS libraries. Symlinks don't take up much space.

    Since libraries are all managed via the OS package manager, you can in theory run auditing tools to determine what libraries are outdated, covering the OS as well as any containers you might be running.

    When security updates are available, it is possible to use grafts to apply patches, which basically overlay the original binary, and by default will be used for anything that is linking to it. In other words, you don't need to recompile everything depending on it, you don't need to rebuild containers, etc.

    On the downside, Guix has a steep learning curve (especially if you're not familiar with Lisp). There's no container store as such, but all this is really just a matter of improving the tooling to be more user friendly and useful.

    --
    It's GNU/Linux dammit!
    Starting Score:    1  point
    Moderation   +1  
       Interesting=1, Total=1
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3  
  • (Score: 2) by wisnoskij on Thursday November 25 2021, @07:29PM (1 child)

    by wisnoskij (5149) <reversethis-{moc ... ksonsiwnohtanoj}> on Thursday November 25 2021, @07:29PM (#1199617)

    Isnt that one of the Os's that you can install in a VM but supports basically zero real world hardware?

    • (Score: 2) by boltronics on Thursday November 25 2021, @11:19PM

      by boltronics (580) on Thursday November 25 2021, @11:19PM (#1199664) Homepage Journal

      It works on real hardware just fine, but it doesn't support proprietary software, including firmware and microcodes. This is similar to Debian. There are other repositories that aren't part of the official project that you need to obtain such things from, if your hardware requires them to function correctly.

      --
      It's GNU/Linux dammit!