A breath of fresh air

On February 1st 2022, at 5:31 pm, I became an Arch Linux user, finally putting an end to over 9 years of running Debian on my desktop machine.

In the process, I also finally replaced my desktop account name shadowm with iris, as well as officially relabeled my desktop from Hanacore to simply Hana. Of course, in order to do this in a way that wouldn’t silently break anything I had to throw away about a decade of configurations and maintenance scripts dating back to October 25 2012, when I originally installed Debian on Nanacore/Nana — the machine whose storage drives, GPU, and operating systems I bestowed upon hana. 👋 By doing this I’m ensuring that anything I’m bringing back has to work with the new name if at all. I’m kind of ridiculous, I know. 🤷‍♀️

One big bonus of doing the system setup dance all over again like this is that I am absolutely forced to start over and organize my decade-old mess of personal files and forgotten software packages. So far I’ve been enjoying coming up with a proper categorisation of files in my home directory instead of having files strewn all over.

What is Arch Linux, again?

Unlike most mainstream Linux operating systems — such as Ubuntu, Debian, Fedora, RHEL and openSUSE — Arch Linux is very much a DIY distribution. The install disc image does not provide any sort of GUI or TUI installer. You are expected to figure out and do everything yourself, although naturally there is an official wiki which provides plenty of information on pretty much all aspects of installing, configuring and housekeeping the OS. The documentation is so well maintained, I have found it particularly useful in the past when dealing with stuff that Debian’s own resources don’t cover!

Perhaps a more apt comparison for Arch would be a Lego set — you are given all the pieces and you can either follow someone else’s step-by-step guide, or improvise to your heart’s delight. If you are under a certain age you are likely to try eat the pieces and die from asphyxiation, though, so it’s probably best not to try if you have never used Linux before and instead stick to something that comes with adequate training wheels such as Ubuntu or Linux Mint. It’s starting to feel like I went too far with this analogy. 😵‍💫

Naturally, straying too far away from the instructions might yield very weird results, so I mostly just stuck to the technologies I am already familiar with from using Debian all these years. Even if I complain about it on my Twitter very often — in particular because of KDE’s and NVIDIA’s mutual dislike of each other — I decided to run KDE Plasma once again, simply because I am too used to my particular workflow and to KDE’s quirks since the 3.5 days. I have been trying out alternative desktop environments on virtual machines and I just cannot see myself using them as my daily driver.

I’m presently experimenting with using systemd-boot instead of GNU GRUB and Pipewire instead of PulseAudio, the latter not being too unfamiliar to me after a mess-up in Debian sid temporarily forced me to switch to Pipewire for a while last year. This is an ongoing story which I may comment on in my Twitter.

Why did I switch?

Of course, you may be wondering, “but what happened to you, Iris? weren’t you a Debian user 4 lyfe or something?” 🤔

It’s a mix of wanting to try something new after running the same OS install for so many years, and some frustration with Debian’s practices and how they relate to my particular use cases. This is going to be a loooong chat, so feel free to grab a seat. 🪑

Debian is too good at its job

It was back in 2008 that I decided to switch to Debian after a disappointment too many with openSUSE’s stability, the latest incident directly leading to the destruction of my personal files for reasons I can’t quite recall. Since then, I’ve run Debian on three laptops, as well as what I would personally describe as one desktop and a half (nanacore + hanacore). In addition to that, in more recent times Debian has become my go-to server distribution. The learning curve was never too steep, and the distribution’s approach to packaging generally means that it’s extremely unlikely that untested or broken software makes it to any official release. This makes Debian pretty great for when you just want/need things to work without any fuss, you know?

Basically, Debian absolutely excels at delivering a robust surprise-free system that is almost completely unchanging throughout its life cycle. That is to say, delivering the stable releases, which are the sole intended product of the Debian project with Debian unstable/sid and testing existing as mere means to an end — both devs and random people on mailing lists particularly love reminding users of this fact. 😄

Naturally, this has its downsides.

• KDE only releases a LTS version of Plasma once in a blue moon, and Debian has purposefully decided before not to restrict the stable version of Debian to any particular LTS version of Plasma, instead sticking to the latest Plasma packaged at the time of the Debian feature freeze and keeping it on life support for however long that Debian version will be supported, for years after upstream has abandoned it.

• Upstreams like KDE are not terribly fond of unsupported deployments. It is often the case that a bug downstream only exists because of an unusual combination of software — especially KDE Frameworks vs. Qt vs. Plasma version issues — and it is simply not worth the developers’ time to worry about it when the issue either has never existed or has already been fixed on properly supported configurations. KDE in particular feels as though they prioritise support for distributions that are either more likely to keep up (KDE Neon, openSUSE Tumbleweed, Arch Linux, Manjaro) or already work closely with them to develop a KDE-based operating system (Kubuntu).

• Backporting patches to fix software after the fact can only get you so far, especially when your distribution already has very strict requirements with regards to what kind of patches are allowed in stable versions. Both from closely following KDE and from being a developer for the Battle for Wesnoth myself, I can absolutely assure you that many complicated bugs exist because of nuanced interactions between multiple software components, and cannot be fixed in ways that comply with Debian policy without upgrading a few things to newer versions and breaking the “no surprises, ever” guarantee and potentially introducing new bugs. This is not a pitfall exclusive to Debian, but rather an inherent issue of a fixed-cycle release model as used by the majority of mainstream Linux distributions.

Finally, packages in Debian can lag far behind their upstreams, even in unstable. Usually when this happens it’s because the maintainers of a particular package or set of packages are inactive or busy with other things, although with widely-used packages like system libraries this can happen simply because of the huge risk of a rushed update breaking things in a massive scale.

It is particularly frustrating when key software components like KDE Plasma just sort of become abandoned and nobody picks them up. To my recollection, Debian unstable a few years ago became stuck with an unsupported version of Plasma for about a whole year, outside any pre-release feature freezes. Since this is all open source software, one could say that it’s up to its users to take up the job and work on bringing the packages up to date again. However, the reality is that most of us users don’t have the time or energy to commit to a long-term project like that.

It has been a while since KDE software in Debian unstable has been stuck in the past, but I think it’s safe to assume the possibility of this happening again always remains, because of the large amount of manual work and bureaucracy involved.

In addition to the KDE-specific issues in Debian, it is also very inconvenient at times as a software developer to test software against newer libraries that I need to build by hand because they are not in Debian sid or even experimental. (Thanks Wesnoth for deciding to make Boost an out-of-tree dependency, by the way /s)

But why Arch Linux?

“Arch user btw”. 🤣 Yeah, yeah, I know.

I am not terribly keen about the stereotypes associated with Arch Linux users in particular, but it’s not like a lot of them don’t hold true for users of Linux in general anyway. I can say with absolutely certainty I am the only person in my friend groups that uses Linux and it does confuse people a lot, especially since it’s hard to explain why Windows feels so hostile to me these days. But I still gravitate back to Linux all the time despite my intense distaste for the elitist attitude that’s always been firmly ingrained in the community at large.

Despite shifting interests, I knew for sure I wanted to keep running Linux, and that Microsoft’s cute Linux-in-a-VM trick wasn’t gonna cut it. Ever since the KDE incident in Debian, I seriously considered switching to a rolling distribution like openSUSE Tumbleweed, the only thing preventing me from doing so being my fear of constant system updates taking a toll on my monthly 4G Internet data. However, in January this year I finally got fast unlimited fibre optic installed at home, so this concern became a thing of the past. 😄

I continued to consider openSUSE Tumbleweed even minutes before booting into the Arch Linux installation ISO, and in fact had both OSes on the same bootable USB stick. Ultimately, these are the reasons why I picked a DIY distro over returning to my roots:

• Despite being more of a “I want things to just work” gal these days, I recognise that I often find myself wanting or needing things to work my way after a while, which is ultimately the main obstacle keeping me from raising the white flag and returning to Windows (ewwww).

• openSUSE still seems to love reinventing the wheel to an almost pathological degree. While I am not in the best position to make an educated judgement right now, seeing that it still uses things like linuxrc and YaST and /etc/sysconfig in this day and age makes me feel like I would have to re-learn a bunch of OS-specific knowledge I gave up on back when I originally installed Debian in 2008.

• One big issue with Debian sometimes is that it feels like even the simplest package needs to be broken up into a million optimal pieces by the distro devs, and as far as I can tell the RPM world is pretty much the same in this regard.

For a while last year I bought the stories and seriously considered Manjaro — which for some reason KDE and r/linux_gaming seem obsessed with at the moment — but during the freenode exodus I got to hear the other side of the coin. The gist of it is that while Manjaro likes to pretend to be a user-friendly Arch-based OS, in reality it’s more prone to breakage than a pure Arch install and imposes the devs’ specific preferences on its users more often than not just like the majority of distributions that aren’t Debian or Arch Linux. 🙄

So what next?

All that said, I have not entirely given up on something more traditional. I am seriously considering replacing Kubuntu on my laptop with openSUSE, although I may opt for Leap instead of Tumbleweed out of concern about update-induced breakage on a device I want to sit there ready to be used rather than serviced. The main things keeping me from making a final decision in that front are the need for NVIDIA Optimus compatibility (thanks NVIDIA 🙃) and some driver issues with its Wifi and Bluetooth adapters that turned out non-trivial to solve even on Kubuntu.

Depending on that, I may have an escape hatch for Hana as well if at any point I decide that upkeeping Arch is too much for me to handle. Which is not too unrealistic of a possibility, to be perfectly honest. Especially with some upcoming changes to my life which may result in me not having access to my desktop for extended periods of time — but that’s a story for another time.

For the time being, I intend on fully enjoying the ride now that I’ve finally got everything set up just the way I want.