So “Linux Sucks”. Can we make a friendly Libre Desktop system?
In this year’s installment of Linux Sucks, Bryan Lunduke points out what really hinders Linux, specifically on the desktop. Here are my 2 cents on it, and a question: Can we make a friendly Libre Desktop system?
Reason #1: Linux Backwards Compatibility Sucks
Trying to run 10 year old software is like DLL hell on Windows. Only 10 times worse. — Bryan Lunduke
Linux backwards compatibility sucks because no one cares. Application developers tend to run the latest and greatest Linux distributions, and during development just care to see whether the code compiles on those systems. Contrast this to commercial systems like Android, where one of the first things a commercial developer thinks about is the percentage of users they can reach when requiring which version of the operating system. Unfortunately, the mindset of some open source developers, especially in the GNU world, has been “we just put out the source code, it’s other people’s job to make binaries”.
This has resulted in developers inadvertently pulling in dependencies on very new stuff, and distributions (the ones who make binaries) find themselves in a constant battle of having to update everything all the time, essentially forcing them to be “rolling release”, or to freeze applications in time along with the operating system. I call that “being sloppy”.
Instead of really fixing the problem by providing stable Application Binary Interfaces (ABIs) and SDKs that applications can be developed against (an approach that was once started with the Linux Standards Base Desktop but then abandoned due to apparent lack of interest), workaround is stacked over workaround nowadays. Flatpak, for example, does not use the infrastructure from the operating system at all but ships everything itself in whatever version a particular application requires, which essentially means that the user ends up running multiple redundant stacks on the same kernel. Hence developers think they can become even more “sloppy”.
GNOME, for example, does not work hard to get a major version, e.g., 4.0.0, ABI-stable throughout the entire 4.x series. Application developers, in turn, think it is OK to develop just for the latest and greatest. End users suffer because they have to download the latest and greatest GNOME all the time, if only to run the latest version of one tiny application like the calculator.
Interestingly, some of the most popular open source applications get this one right: Firefox and LibreOffice are deliberately built on distributions from a few years back, so that the resulting binaries can run on as many systems as possible.
A Desktop Linux Runtime and SDK is needed
An authority like the Linux Foundation could provide, once every one to two years, a stable Application Binary Interface (ABI) and an SDK (read: distribution to compile stuff for) that applications can be developed against. The standard would define which dependencies must be available on any compliant system, under which names at which locations, and in which versions. All applications could then be compiled against the SDK and be guaranteed to run on all compliant systems. Distributions should ship the latest runtime for this SDK plus the last n ones by default, and all earlier ones optionally. It would be important for the Desktop Linux Runtime to be defined by a nonpartisan organization which is not under undue influence from any specific operating system vendor (hint: just putting “XDG” in the name doesn’t make it so).
Workarounds
Fed up with constant incompatibilities in the Linux world, the Python world has taken initiative upon themselves to declare stable Application Binary Interfaces (ABI) every now and then (named manylinux) and and corresponding “SDKs” (named manylinux Docker containers). Interestingly, the same convention could be used not just for Python modules, but for virtually any kind of software. For example, there are projects that take the manylinux Docker containers to build Python itself as an AppImage for Linux, which can in turn be used to build AppImages for Python-based applications.
Speaking of which. As Bryan Lunduke points out, AppImages have to bundle “all of, or most of” the libraries alongside the application.
If a Desktop Linux Runtime and SDK were in place, AppImages would need to bundle only what is not covered by those. And each AppImage would have exactly one dependency, like “Desktop Linux Runtime 2010”, which would mean that this AppImage would be known to run on 2010 and later Desktop Linux systems. (Today, most developers producing AppImages go a pragmatic approach by building software on the oldest still-supported LTS release of Ubuntu, and bundling everything that cannot be assumed to be shipped with most Desktop Linux distributions, though technically it is also possible to bundle everything an application needs, effectively making the kernel and an X server the only dependencies.)
Solutions?
Split the stack into a lower and upper part. Traditional Linux distributions start by the assumption that they can cover “all software that runs on Linux”. This may have been practical when Linux was in its infancy, but is just not really feasible anymore in a world where everyone and their dog write applications today. Let the lower part (operating system including kernel, Xorg, desktop environment) be managed by the distribution vendor, and the upper part (applications) by the end user. Ensure that you can have the lower part LTS and the upper part rolling. Distributions can still be valuable for application developers to put together (and keep recent) the upper part, like the Open Build Service does (e.g., by rebuilding an AppImage automatically whenever a dependency inside it has been updated).
Don’t rely on what Lunduke calls the “Linux People”. Let application developers and end users drive this, not Linux distribution makers. The whole AppImage ecosystem is developed under the assumption that it will see little to no love from Linux distributions. And for the most part, this assumption has held true, especially for Canonical and Red Hat, which are trying to push their “partisan projects” (more on those further down below) at every occasion. This being said, there are notable exceptions, with some folks at openSUSE bringing AppImage making to the Open Build Service, with Nitrux as a desktop distribution focusing exclusively on the lower part of the stack while using AppImages for the upper part, and Deepin Linux incorporating AppImage support into their desktop, just to name a few.
Reason #2: A Operating System run by committee
We are an operating system, or if you would like to call it that, a collection of disparate operating system chunks, that is run by committee — Bryan Lunduke
I’d say it’s worse than that. Not only is there no dict… err, visionary leader (like Steve Jobs), there is not even a committee. At this point, each operating system vendor essentially does what they want. This is not how you build one reliable platform that others can trust upon. It essentially splinters the already-tiny Desktop Linux market share into a Ubuntu, Fedora, openSUSE,… you name it market share. For no good reason. Which is a shame!
Little has changed since my talk about 2018 Desktop Linux Platform Issues where I made the point that to make “Desktop Linux” a viable platform, a guaranteed minimal set of infrastructure (available in the default installation of all distributions) with guaranteed backward compatibility is required.
In the talk, I point out some of the things that are different in various Linux distributions for no good reason. My pragmatic stance on this those days is, when in doubt, go with what Ubuntu uses, because it is arguably the family of Desktop Linux operating systems with the largest collective market share. So if an application works on Ubuntu LTS but does not run on the latest Fedora, I think we should start to think about it as a bug in Fedora. Let users be the ruler, demanding that stuff works!
Solutions?
Look at Haiku OS. One stack from bottom to top with opinionated decisions made by those who do.
Reason #3: Committee that has to please multiple Mega-Corporations
Lunduke mentions that Linux has to please “a ton of mega-corporations”.
How many are really interested in Desktop Linux? Seems to me that most are not. If those corporations sponsor the Linux Foundation, we should not be all too surprised that the Linux Foundation is doing little to nothing for Desktop Linux as a platform. To the point that the Executive Director of the Linux Foundation doesn’t even run Linux on his desktop when giving presentations on stage.
Solutions?
Maybe we need a committee that consists exclusively of Desktop Linux operating system vendors, application developers, and end users. And maybe we need to name it something else than “Linux”. Branding “Desktop Linux” as “Linux” does more bad than good, since “Linux” those days is more concerned with Cloud and Hyperscale and Virtualization and Serverless and… non-desktop stuff.
Look at the Libre Graphics world. A healthy ecosystem of creative applications for design and content production has emerged that can readily compete with its commercial counterparts.
Maybe we need to build the Libre Desktop platform and ecosystem. Yes, it may use Linux as the kernel, just as Android happens to do, but that’s a mere implementation detail. Just like most Libre Graphics applications will also happily run on other systems like Windows, the Mac, and Haiku OS.
Reason #4: Kinda Corporate controlled, Kinda not
We have so many projects, so many teams, so many nonprofits and whatnot that are doing work seemingly independently of the big mega corporations but a lot of them are funded by the big mega corporations so they do control and dictate at least some level of what they do — Bryan Lunduke
One might call them “partisan projects”, projects that are not driven by a broad community with people from many different companies and volunteers which are neutral concerning other parts of the stack, but mainly by employees of one vendor that has a certain vision of the entire stack — while claiming to be neutral.
It is hard to deny that there are clusters of “partisan projects” which are personally and technicall interwoven with each other, even though the people involved (often paid by a small group of employers) sometimes claim to act as individual contributors to the individual open source projects.
The “GLib/Gtk/PulseAudio/systemd/GNOME/Fedora/Atomic/Wayland/Flatpak/Portals” cluster comes to mind. Probably IBM has no “central planning” for those, but nevertheless these projects are cross-referencing each other way more strongly than they refer to outside, real community projects. And can it be pure coincidence, that all of this stuff is showing up as the default in RHEL sooner or later?
Here is the latest recent example: freedesktop-sdk.io. From a cursory glance, you could be under the impression that here is an independent project that tries to establish an SDK for, well the free desktop.
They claim
We are a group of people who are passionate about the Linux application ecosystem — https://freedesktop-sdk.io/
But then all you read about is Flatpak. No word that Snap and AppImage even exist. In my opinion, a more honest name would be “Flatpak SDK”, not “Freedesktop SDK”. And it would not hurt to mention that the show is run by the GNOME Release Manager.
Solutions?
It would help if each element in the stack would truly embrace agnosticism as to the other parts of the stack, and not favor one over the other. It would help if open source projects would adopt policies to stay neutral when it comes to technology choice outside of the scope of their own work. For example, a window manager should not require a security system that essentially requires Flatpak that essentially runs best on Fedora.
Projects like Xfce, KDE, openSUSE seem to do better in this regard, they don’t seem to have a “favorite” this and that for everything.
Don’t get me wrong: There is nothing wrong with making opinionated choices. But then clearly label them as such, and don’t imply that a particular partisan solution has “emerged” from “the community”.
Full disclaimer: All of my work on AppImage is done by me in my free time, not sponsored by any corporation.
Reason #5: Linux people are dumb
It’s hard to develop or promote software that you refuse to use. — Bryan Lunduke
As an example, Bryan Lunduke points out the widespread use of other operating systems on notebooks at Linux conferences.
“Eating your own dogfood” is a big thing for me. Personally, I’ve been running on AppImages exclusively for the last decade or so. If you would like to see my setup, here it is.
No word on usability and design?
All too often, Desktop Linux is just plain broken out of the box. You always seem to have to install, configure, tweak or generally “fiddle around” with something. Just to do simple every-day tasks that you wouldn’t think about twice on the Mac, like playing a video, using a NTFS disk, or finding a webcam on the network with Zeroconf.
With some notable expections such as Deepin Linux (where most common things indeed just work right out of the box) usability on Desktop Linux is in a sad state.
In fact, this sad situation has triggered me to write a whole series on #LinuxUsability (part 1, part 2, part 3, part 4, part 5, part 6).
Seems like I am not the only one who has noticed. Law Zava and team have carried some daily tasks on Linux, Windows, and Mac systems, and here is the result:
Solutions?
Can we make a friendly Libre Desktop that stands in the tradition of the original Mac (I am taking “what it wants to achieve”, not “how it is done technically”), yet is built on Libre software? A Libre Desktop operating system with focus on simplicity, minimalistic elegance, and usability (think Macintosh System 1), without the complexities of Linux distributions?
Head over to the “hello” Wiki to learn more. If the ideas there resonate with you, get in touch: This project will live from YOUR involvement. I have ideas, do you have the time and motivation to implement them? Be sure to contact me.
