Continued from Part 2:
There are two widely-used container technologies that are attempting to apply this same paradigm to ALL desktop applications - Flatpak and Snap. I'll focus on Flatpak since Canonical has made some design decisions with Snap that will severely limit its use outside of Ubuntu and its derivatives.
Basically, when you install software through Flatpak, you're installing it into a runtime (which is, like Valve's Steam runtimes, a stable userland that is regularly updated with bugfixes and security patches). The developer knows that it works against that runtime. Flatpak also manages updating both the runtimes and the applications.
What are some advantages:
1. No more distribution fragility. Everything you install through Flatpak is built against a defined userland (from Flathub, or some other source). No "new library conflicts with the old library" issues. No chance an application update to break the system and extremely unlikely for a distribution update to break a Flatpak application. Flatpak keeps older runtimes on the system if an installed application needs it. All of this is transparent to the user.
2. No root privileges needed to install software. Flatpak is merely pulling the container image. Nothing on the base system needs to be modified.
3. No need to pick a distribution based on application versions or update frequency. Your applications are always up to date (unless you pin a specific version) and you can use any of them on any distribution. For example, my install of RawTherapee on NixOS (installed through Flatpak) is identical to my daughter's install of RawTherapee on openSUSE Aeon.
4. No need to reboot after an application update. Since the only thing that was updated was the application container, you simply launch the new version. No libraries or dependencies on the system were changed, so no reboot.
5. Default Sandboxing. While any application can be run in a sandbox (preventing the program from accessing certain parts of the system), Flatpak has them by default, and, for the most part, they operate transparently. Most users never notice that this or that application doesn't have access to the root filesystem, network, or various system devices.
In essence, there are two distribution layers. There is the base distro layer with its userland and applications installed through the official repos (or however the user decides), and then there is the Flatpak container layer - applications with their own userland and update system. The two operate as independently as possible.
There are other ways to have an independent userland for applications. Perhaps there is no need to install the application, but you want the equivalent of a "portable .EXE" for Linux. Well, the best solution right now is AppImage (even though it does require a few userland dependencies to be satisfied by the base distro). Perhaps a developer needs to create multiple custom userland environments for reproducible builds. Then Nix is probably your ticket. Perhaps someone needs to run an entire distribution inside a container (for validation reasons, or to use a specific utility only available that way). Distrobox or Toolbx would be the method of choice for that.
But however it’s done, running containerized software on the Linux desktop - that's here to stay. And each user might have more than one method for their own workflow. A user may be using Firefox from Flatpak, some CLI tools in Docker, their favorite USB writer as an AppImage, and TeXstudio installed into the system from the distribution's official repos. But as more users push more of their software into containers what counts as "a good distro" starts to look different.
And - perhaps it should start to look different given the containerization of the desktop. This is the question that desktop Linux users (and maintainers) are collectively wrestling with at the moment and it is expressed with questions like these: should we consider applications like LibreOffice and Thunderbird to be part of the OS? Is that REALLY where I want to get my office software? From the official repos maintained by the same organization that makes sure, for example, that the DE splash screen transitions smoothly? Or from the same group ensuring that the video drivers correctly identify some older GPU? Do I want to have to choose between the most complete possible official repo vs a fragile system that is difficult to maintain? Do I really want to wait 6 months to get the latest version of some desktop application? Do I want my distro maintainers to have to re-package the browsers every month because of security fixes and the brutal upstream release schedule?
I think it likely that the community will say “no” to all these questions. My guess is that users (and maintainers) will probably want the advantages that are available in a highly-containerized desktop:
An “unbreakable” (sorry, Oracle) Linux experience. Nothing breaks. You never need to re-install the distro.
Expected compatibility. No need to wonder if this or that program is packaged for my distro (much less is available in the official repo). “It just works” is probably too strong (though for many cases, that’s a good description), but there will be an expectation that everything “does” work, and that it works in a way that does not promote system fragility. Use the distro that gives you the best mix of LTS and cutting-edge kernel and DE, has the best hardware support, and uses management tools that you like. All your software will work just fine.
Low-fuss updates for the OS. Since almost nothing is actually installed on the base system, even major version updates should involve minimal drama. All that needs to be updated is the kernel, the desktop environment, and the container management software.
Expectation of being able to “pin” specific versions of software used for production work. Everything else can be updated around them.
Finally - Distro maintainers and designers can be set free from being downstream from Debian, Fedora, or Arch in order to take advantage of their giant repos and ready-to-install packages.
Why should we not embrace this future?
There are a few reasons:
Cohesion - A distro could make sure that all applications had correct color schemes, window borders, and file choosers. Outsourcing these to Flatpak maintainers will reduce the visual and functional consistency of a distribution. This is getting better, but still a downside.
Resources - having independent userlands on a system will increase both disk usage and memory utilization. Flatpak minimizes this to some extent since it uses runtimes that are shared between applications that use them and does some de-duplication on their contents (making it more space-efficient than an AppImage or static binary). On a “modern desktop” this difference is not noticeable. But for resource-constrained uses (old laptops, Raspberry Pi, etc…) that would be using XFCE or a simple WM to have the smallest RAM footprint possible - this duplication of userland in memory may be a dealbreaker. This effect can be minimized, but the containerized desktop will never be able to reach RAM-use parity with a traditional distro.
3rd Party centralized control will mean less freedom. For Snap, I think this is a fair criticism. There is only one way to install Snaps, and that is using the store run by Canonical. For AppImages, there is no such centralized control, so that doesn’t really apply. Docker can use images from anywhere, as can Flatpak. While Flathub is the de facto standard for installing Flatpaks, there is no limit to using additional Flatpak repos (much like using alternate package sources for RPMs or DEBs - but without the fragility downsides). And also - the source is still available for software like Firefox and LibreOffice. Nobody is stopping a distribution from packaging whatever they want. But I think, over time, less and less will be packaged in that traditional way.
“Why make free software more like proprietary software?” And it’s true - there’s something unique about a system where EVERYTHING (from so many different contributors and foundations) is compiled using the same set of compilers against the same set of libraries. It’s something that can only happen with FOSS. I don’t want to lose this, and I don’t think it will be lost. After all, Gentoo is still going strong, even with many more binary-oriented distributions out there. Think of this as a third category - you have the source-based distros (like Gentoo and LFS), binary-based distros (like Mint and Fedora), and now container-based distros (like Aeon and Silverblue). I think this objection also might have some concern that people using container-based distros will not cultivate the kind of computer literacy needed to maintain a Linux system. If nothing breaks, how will anyone learn to keep their system running well?
This may destroy the supply/demand curve for distros. If all the user wants the distro to provide is a DE and container management (DE and Docker – “D&D” has a ring to it), then there may be a Cambrian explosion of new distros, some of which might be very different from what is on the market now. There will be low-effort stuff like someone creating an Arch installer that includes their custom themes and branding, Flatpak, and Distrobox and release it as a new distribution. Will more people be using non-mainstream distros like Void or Clear (since all their software works!) and finding themselves with less community support than they would if they used more well-known distros? Will the big distros lose their lustre because one of their primary advantages (large official repos, numerous unofficial repos, and readily available .deb or .rpm packages) no longer matter? Is fragmentation about to skyrocket? I think, if we wind up with many more distros, that it will be fine. It will be something similar to the way Android phones all run the same software from the app store even though their “distributions” are highly divergent. In other words - so what if a developer no longer has just a few big players to package for. They’re making a Docker container anyway. They don’t have to care. Same for the ones making a Flatpak. Even if we imagine a world of extreme fragmentation, developers just won’t care that the most popular distro only has 10% marketshare of the Linux desktop world. Flatpak solves this problem in advance.
We may be trading one incomplete repository for another. Many applications are not in official repos. And many applications are not on Flathub, either. Fortunately, tools like Distrobox exist that will allow the user to run an entire distribution inside a container and thereby have access to everything that the guest distribution can install and run. There will be some growing pains here, as users make this a preferred way to run software rather than an end-run around compatibility limitations. There has been some experimentation in meta-distros that expose this capability and make it more user-friendly (see VanillaOS and BlendOS for examples).
This will make distros “boring”. If distros take their job to be DE+Docker, then won’t innovation die? I think not, for reasons I’ll explain below. However, the distro maintainers will have a much smaller set of things to do. I think, in the spirit of Unix, that doing few things very well is going to be better for the overall health of the ecosystem.
Continue to Part 4...
留言