The Distroless Linux Future May Be Coming

Over the decades the number of Linux distributions has effectively exploded, from a handful in the late β90s to quite literally hundreds today, not counting minor variations. There lately seems to be a counter-movement brewing in response to this fragmentation, with Project Bluefinβs Distroless project being the latest addition here. Also notable are KDEβs efforts, with KDE Linux as its own top-down KDE-based distro, but now with a switch to BuildStream from Arch likely as a distroless move.
It should be clear that there is no obvious course here yet, and that opinions are very much divided. The idea of βLinuxβ becoming a more singular OS appeals to some, while to others itβs the antithesis of what βLinuxβ is about. This much becomes clear in [Brodie Robertson]βs exploration of this topic as well.
The way to think about βdistrolessβ is that there is a common base using the Freedesktop SDK on which the customization layer is applied, such as Bluefin, KDE or Gnomeβs environments. You could think of this base as the common runtime, using the Freedesktop standards for interoperability for a user-selected layer thatβs installed on top. This way the idea of basing a distro on a specific distro is tossed out in favor of something thatβs vaguely reminiscent of the Linux Standard Base attempt at standardization.
Itβll be fascinating to see how things will move from here, as there are definite arguments to be made in favor of less fragmentation and resultingly less duplicated effort. In many ways this would bring Linux closer to for example FreeBSD, which avoids the Linux Chaos Vortex problem by having a singular codebase. FreeBSD βdistrosβ like GhostBSD and NomadBSD are therefore essentially just specialized customizations that target a sub-group of FreeBSD users.
Of course, when we start talking about package managers and other base-distro specific features, we may very well risk igniting the same problems that tore apart the LSB so many years ago. Will we also standardize on RPM over DEB package files and kin, or something else?