thesola.io blog - os dev

The Year of the Linux Desktop won't happen, and that's fine

2021-09-03T00:00:00+02:00

Linux, and the community of hackers and users that formed around it, make for a formidable operating system product, both for software development and everyday use. Clearly it is superior, so where are all the apps?

It's a conspiracy from Microsoft!

That's an interesting point, because it used to be very much true, so it isn't unreasonable to be wary of Microsoft today. However, times have changed, and they stopped fighting their pointless war. After all, Windows is probably not even profitable to them anymore.

But that is besides the point. Linux has indeed essentially dominated most devices with a CPU and memory, so why aren't we seeing it on desktops?

A ship with no captain

But Android is the dominant mobile OS! The desktop is dying anyway.

Ah, the Canonical argument, I see.

You may not have noticed, but there was a change of tone in Ubuntu development and marketing. This is important, because Ubuntu still represents the definition of the typical Linux desktop.

Back in the good old days of 2011, Canonical's first objective was Ubuntu on personal desktop computers. Whichever way you looked at it, GNOME was not exactly pretty, and KDE was still knee-deep in Qt licensing issues. Thus, they decided to start development on the Unity desktop, which would become the trendsetter for various features we've come to expect on modern Linux. That, and Unity would eventually also drive the Ubuntu Touch project.

Fast-forward to 2016, and Canonical has given up development on Mir and Unity 8, both due to frictions with the broader Linux community, and the failure and abandonment of Ubuntu Touch. Around the same time, Windows Subsystem for Linux came out, and the first distribution available at launch was none other than Ubuntu.

The Ubuntu Desktop effort, which used to be front-and-center on Ubuntu's website, is no longer mentioned. They now focus on WSL, and the Internet of Things. And I believe that this left a void in the Linux desktop community. Because no matter how flawed it was, Ubuntu had the brand power. Ubuntu was the flagship, the one solution that we could point to as the definitive "Linux desktop". Now, it has all but fizzled out.

A labyrinth with no way out

But Fedora/Zorin/elementary/(insert distro here) will be the new standard! Why aren't people adopting those?

There are an uncountable number of Linux distributions, which aren't completely compatible with each other, and whose software offering isn't necessarily consistent. For a long time, and especially these days, we have been experiencing fragmentation.

With an open-source project, when something isn't quite right, you will usually be tempted to fork it. This is a great freedom to have, but now there are two, hardly distinguishable projects. It's only natural that, when given the option, everyone wants to "do it right".

A Linux distribution, at heart, is a set of software packages that are built and distributed together with intent to provide a ready-to-use version of Linux. The prime philosophy of GNU, Linux, and pretty much all other constituent projects, is that only source code is officially distributed. Software is shipped with a set of compile-time flags, so that the user can configure it just right for their system.

A distribution's job is to pick out the best compile-time flags for their projects, build them on the same shared libraries, and regularly keep them up to date. This not only means that some distributions may be lagging behind on updates, but also and more importantly, that important configuration options differ and are obscured.

Both of these issues make software support a lot harder for any developer, because suddenly there isn't one, but several different versions and flavors of your software floating around at one time. And whether or not your software makes it to a distribution depends on the distributor, so god forbid you keep your code proprietary.

Let's not get into details on how there are multiple ways to do basic things on Linux. As you can see, there is a certain philosophy, and it is incompatible with software distribution at scale. You can't just roll out infinite package maintainers.

A product with no market plan

But Flatpak and AppImage are solving those issues, right?

That's if the community even wants to accept those (they don't). Also, AppImages are a very bad idea, but whatever.

There is one other thing that Ubuntu had, and I cannot seem to find in other Linux distributions. A sense of identity.

The people who decide on where the Linux desktop is headed, don't seem to agree on a single identity. Some even want none at all. Sure, a bland and neutral appearance might help users customize it... but most user themes usually revolve around Windows and macOS look-alike anyway...

The Linux desktop wants to be the jack of all trades, but ends up being master of none. It doesn't have a definitive, be-all end-all appeal, and it's hard to sell users on something if we can't even show them what it's supposed to "look like".

I know it may seem superficial, but looking at Windows starting with XP, or Mac OS X, they have a strong identity. Fedora is just default GNOME, elementary is just a macOS wannabee, and Zorin's main sales pitch is literally its ability to look and feel like competitors.

And yet, it lives on

So all hope is lost? I thought you said it was "fine"?

We don't have a legendary startup tune. We don't have a distinct desktop experience. That's because we want the user to design their own.

We don't have a single packaging format. Our shared libraries are a mess. That's because package maintainers are protecting us.

We don't have a company fully devoted to the Linux desktop since Canonical. That's because profit would prevent us from making it the best it could be.

Linux has shown that people can come together to do great things, with no compensation. Before we even begin to think about sharing the Linux desktop, we need to answer one crucial question: What even is the Linux desktop?

Never give up, guys.

How much power do companies have over open source?

2021-07-06T00:00:00+02:00

The MUSE group wrote a telemetry proposal as a pull request, and it backfired. Linux users are usually safe from telemetry thanks to distro maintainers, so why are people still mad? And what does that say about the way software is distributed as a whole?

People were angry because MUSE wanted to introduce telemetry, it's as simple as that!

Is it though?

First things first, I would like to make it clear that I do not condone the actions of MUSE group in any way. All I want here is to use that situation as a case study.

I will be referring to Tantacrul's response to the telemetry proposal, as well as the MUSE group's response to the privacy policy changes. I recommend that you give them a read first.

1. The telemetry proposal

Here's a quick run-down of what I understood from the discussion around the telemetry PR of May 4th

A MUSE developer submitted the pull request, containing working telemetry code intended for Audacity, to the Audacity repository.
The community found out about the pull request, which promptly caused a backlash.
The most obvious change to Audacity's governance to people was the involvment of Tantacrul, so the community lashed out to him.
Tantacrul explained, in an official response on behalf of MUSE, that the intent was for the PR to serve as a proposal to the community.

Now that I wrote these words out, two possible lines of thought come to mind:

A: MUSE had intended for people to find out about the PR through their official forum post, as they did with MuseScore.

Maybe. Or at least, that's what they officially said. I guess pull requests aren't a very subtle way of expression, but given that their alternative would have been to work on a private fork then come out of the blue with an instantly implemented telemetry PR, I'd say it still was for the better.

Of course, the community wishes that they talked about the idea before starting work on it, but on the other hand, they may have thought that simply asking "Hey, mind if we add telemetry?" would have caused most people to refuse anyway, and that an implementation would have been more clear.

B: MUSE had intended to implement telemetry as fast as possible. The PR was too complete to just be a proposal.

Except, something just doesn't fit. In fact, looking at the commit dates, the whole "work on a private fork then come out of the blue with an instantly implemented telemetry PR" is precisely what they did. And of course, the community lashed out on them. As far as was disclosed, there was seemingly no reason to release their work ahead of the forum post they had intended to make, unless they wanted to merge the changes as fast as possible.

The truth is probably somewhere in between, but comparatively speaking, the public reaction was a lot more tame than for what happened next.

2. The privacy policy update

A privacy policy is a legally binding document which an app developer uses to clarify what personal data their application is able to obtain from its users.

Just yesterday (at the time of writing), MUSE made a public revision to Audacity's privacy policy, allowing them to collect data such as your IP address and error reports... and data intended for law enforcement.

When you think about it, Audacity is not like iOS, in that it does not explicitly encrypt or otherwise prevent external use of user data, so law enforcement data should not be in the scope of Audacity's privacy policy. That's what really worried users, so they did what they judged appropriate: they forked the project.

Again, MUSE reminded people that the new data collection code can be disabled through a compile-time option.

Compile-time options are expected to be manipulated by users, but come with the implied requirement that said user should be sufficiently proficient in computing to know how to compile their own programs in the first place. As such, it is fair to say that, regardless of intent, these options will impact the uninformed and damage the image of an app as a unified product whose behavior is identical everywhere.

Moral of the story

It is much too early for me to give a definitive opinion on the situation, but as a community, we should consider our choices in software distribution, and how they can affect our users in the long run.

Just like with installers, the ability to customize and control the build process is an important part of a sane relationship with software. When the defaults are changed, it's as if the very philosophy of the app is being taken away from the community, who then feel powerless. Such is the irony of modern open-source.

And to MUSE: Not every user of Audacity is a developer, and we are acutely aware of that, which explains the community's overprotective stance. Code is law, and proposals should first be formulated in words, before being written down to code.

Installers are evil and here's why

2021-04-25T00:00:00+02:00

There's one aspect that's always really annoyed me about Windows. Except this time, all major operating systems can be affected. Installers are one of the biggest cryptographic and social engineering security holes out there...

Okay, now what?

If you already saw my comments over on reddit and stuff, you may have figured out that I'm a proud Arch Linux User™ btw (there, I said it), with a little twist.

My particular install calls itself "Arch Linux Atomic", and for good reason. Taking inspiration from the likes of Fedora Silverblue, I am trying to build an Arch system where most system directories (namely /usr and /etc) remain read-only.

Wouldn't that be a hassle? Doesn't it break pacman?

There's the thing. To me, Arch Atomic is a little experiment on trying to distinguish user-installed programs from the system state. The logic is that as long as the system state works, nothing can possibly break from user-side tinkering, and ideally the user won't feel handcuffed by their OS.

The key to achieving this is to have the system precisely control the way software is installed. To pretty much no one's surprise, that means that I try to rely as much as possible on package managers. Because I can tell the package manager how to install things on my particular system, and retain compatibility with official Arch Linux repos.

Signing is cool

Let me guess, you're hating on installers because you prefer package managers? I knew it, you're a Linux shill!

Woah, hold that thought. There's one other thing that's really nice about package managers, and that pretty much no one cares about except when it breaks. That neat little thing is cryptographic signing. The ability to ensure, within reasonable doubt, that the random program you're downloading is in fact trustworthy.

As they say, "prevention is better than cure". When a package manager sees a signing discrepancy, it outright blocks you from installing the program. That's the best kind of safety feature -- it gets out of the way and is simple to understand, yet very hard to break without direct machine access (but that's another problem entirely).

Programs downloaded from a random place can only be trusted if the entire operating system implements that signing feature. For example, macOS does, and obviously are milking developers for it.
Still, it works.

Windows kinda does too, but only when UAC is involved, and it's not remotely enforceable, and if you think end users are going to tell the difference between a yellow and red UAC box, you're delusional.

Don't trust strangers

Yeah, but as you said, macOS installers are signed, so we're all good, right?

Not right.

Say a malicious third-party somehow got through the signing and authoring process. Let's review what they can, and cannot do:

Installer: An installer (especially the system-wide kind) is like a black box. It does some voodoo with elevated access, on the basis that you trust it to install a program. It can choose not to and there's nothing you can do about it.
Package manager: Package management is simple. Read through some info, move files to where they should be, update software index, done. We know what's going on, and at no point is the program needlessly elevated. Or run, for that matter. Package managers treat applications as inert data, meaning they cannot take advantage of elevated privileges.

The real strength of a package manager is that it makes privilege escalation requests unusual.

On Windows, for example, everything shows a boring, identical UAC dialog box. Annoying, get out of the way, done. Now your system's broken.

On macOS, the permission dialog is not only more unusual, it's also more detailed. It's worth taking a good look at, because you don't see it everyday, and instead of abstract concepts like administrator access, it gives you a down-to-earth explanation of what the app is asking for.

On the usual Linux system, there's root and there's plebs. No in-between. Virtually no app will ask you for root access, save from the package manager and the occasional system utility. That makes it look like a dangerous red button, rather than a boring formality. When you see sudo, you think twice (hopefully).

TLDR

An installer is a random program that runs as Administrator and you trust will install something. Nothing is enforcing it to follow conventions (leading to bit rot) or do what it says at all (leading to viruses).

You could enforce signing. Signing in a curated app store is kind of a given. Signing on every single program on the system is frowned upon at best.

Your best weapon is to educate users. Eliminating installers removes a reason to accept administrator access prompts, making users more thoughtful about it.