Unpopular Opinion Penguin #6: The Blaming Games

Hello and welcome to another entry of the most popular section on this blog!, Unpopular Opinion Penguin. Today’s blog is about bugs.

Bugs?—you say—Yes, because seemingly, we’re responsible for issues caused by software that we didn’t develop, but are we? Should we be responsible for third-party software issues, or where does our responsibility end?.

So, without further ado, let’s begin.

By this point (2022), I can undoubtedly say that Nitrux is the most controversial and hated Linux distribution of this decade. Possibly, there are ten minimizing our work on every positive comment we get.

From (literally) about the default wallpaper (ignoring the fact that we include 68 images by default) to the ever-constant “Another distribution? And what do they add to the table?”.

But anyway, bugs. As I mentioned in the introduction, I’ve recently seen an increase in people trying the distribution and mentioning that they have problems, understandable—I think—That is until they mention problems with third-party software, like Latte Dock. Now, I love Latte Dock; at one point, it saved us from a very annoying bug with Plasma panels, and it’s been the default ever since.

So what’s the problem people have with Latte, then? Well, you see, I know that people looking to try the distribution will use VirtualBox and, to a lesser degree QEMU. I also use VirtualBox to test the ISO files, but I don’t use a new virtual machine with its default settings; I customize them to provide the best performance. I increase the number of CPUs, the amount of RAM, use EFI, select KVM, USB 3, enable I/O cache for the virtual drives, etc.

And what’s the problem with that?—you say—Well, 99% of people don’t do this; they use the default settings. And that means only one CPU, 1G of RAM, no EFI, USB 1.1, no I/O cache, etc. So when people boot the distribution ISO and the virtual machine boots and the Live session starts, Latte Dock doesn’t start. Strictly speaking, Latte Dock doesn’t start unless there’s more than 1.4G of RAM.

That’s a problem, and it’s a bug. Now, Nitrux Latinoamericana S.C, a.k.a, us, we don’t develop Latte Dock; we use it. But that’s not what these people think; their reaction is that Nitrux doesn’t work.

And I think that’s unfair.

It’s unfair not only because we don’t develop it, but this problem also isn’t caused by a misconfiguration on our part, like a corrupt Latte layout. So, we don’t cause this problem, but we take the blame.

Another recent problem is the Nouveau driver, the FOSS driver for Nvidia graphics cards. I think it is well established that Nvidia doesn’t provide any support to its developers, so these folks make an arduous effort to get these graphics cards to work.

Nonetheless, Nouveau has its limitations, primarily regarding hardware acceleration and adequate support for all of Nvidia’s graphics card portfolio. So owners of Nvidia hardware, including myself, install the proprietary Nvidia driver. What’s the problem then? Just add the proprietary driver to the distribution—you say—And sure, that would “solve” it, but that’s not a solution; it’s a workaround.

Besides, Nitrux is a distribution that does not include proprietary software* (the kernel includes “firmware blobs”), unlike other distributions that include Steam, Skype, WPS Office, or other software; this is fine, it’s their prerogative, but it’s not what we do. We even offer the Libre kernel from our repository.

So, the problem is that when people try the distribution because of these limitations of Nouveau, it may be that their particular graphics card doesn’t work correctly (or at all), and so once again, what these people think is not that Nouveau has problems but that Nitrux doesn’t work.

And I think that’s unfair.

And examples like this are plenty, issues with Calamares in the past, instances of KWin crashing, lack of adequate support for OpenRC from upstream, problems with SDDM forcing Wayland sessions, etc.

Undeniably, we’ve had mess-ups, like not adding wpasupplicant (so, no WiFI), ISOs not booting on Macs or Virtualbox because of a missing file or cursor images, etc.

See, that’s the question itself, are we responsible for issues caused by software that we didn’t develop? Or are we only responsible for the things we develop and modify?.

Should we be responsible for third-party software issues, or where does our responsibility end?.

I’m confident that 99.999% don’t know that there is a responsibility notice included and displayed in the distribution (in most distributions, actually). This notice is there for legal reasons, and FOSS software also needs to abide by laws.

Hundreds of FOSS projects make up a single distribution, each with its warranty limitation.

I do not think that it is reasonable to hold distribution maintainers accountable for issues caused by software that they did not create or modify. There has to be a line drawn here, or what’s next? Are CVEs in the kernel also the fault of Nitrux? Are bugs in Plasma also the fault of Nitrux? Is Nitrux also responsible for bugs in SDDM? or KWin? or Latte? or Firefox, LibreOffice, KCalc, and all the software we include by default?.

Likewise, I do not expect other distributions to be responsible for issues with MauiKit; that’s our responsibility.

However people do not have this mindset, they see the distribution as a single “thing” that, if anything fails, means that Nitrux doesn’t work.

And I think that’s unfair.

And so that’s that. We’re now responsible for every existing bug in FOSS software ever. Anything that doesn’t work is somehow magically our fault, especially if we didn’t make it.