The next best decision: stepping away from the Linux desktop

In my last post, I detailed the grueling, 173-crash nightmare of simply trying to reinstall Arch Linux. That ordeal pushed me to seriously look at macOS. Today, I am taking the final step. After eleven years of relying on Linux as my daily driver, I am officially quitting it as my primary operating system.

My journey started over a decade ago with Ubuntu—or rather, a specific derivative called Vinux. For those unfamiliar, Vinux was a specialized distribution developed for the blind, meant to come pre-packaged with screen readers and accessibility tools working out of the box. I absolutely hated it. It was riddled with old bugs, largely because it was stubbornly stuck on Ubuntu 14.04 at a time when 15.04 had already been released. Coming from a dead-end Windows XP machine that I couldn't upgrade any further, trusting a so-called distro developed for the blind seemed like the most logical move to make. Not knowing much about Linux back then, it was an easy mistake to fall for.

After only a few months of that frustration, I wiped it, went to Arch Linux, and never looked back. Up until today, that was the best decision I ever made in my entire time under Linux. Suddenly, things seemed to just work. Sure, I still faced quirks. Sure, booting into silent live images was profoundly annoying. But I could still power through it all.

Today, I am making the next best decision: I am quitting.

To be clear, I am not abandoning Linux entirely. I will still use it for remote access, managing servers, and SSH sessions. But for direct, physical use as a personal computer, my time with it is done. Linux has simply become something I no longer wish to use.

A large part of this comes down to growing up, I suppose. I’ve realized that having to fight with x86_64 or ARM hardware quirks every single step of the way is just no longer something I can do. It drains entirely too much of my energy and time.

But another major factor driving me away is the ongoing removal of the VT (Virtual Terminal) subsystem. To me, this is going to be the slow death of Linux as a desktop system—not that there was a massive desktop presence to begin with. The console has always been a fundamental layer of access, and stripping it away fundamentally breaks the foundation of the system for those of us who rely on it. Removing console access and enforcing a full GUI stack just to get a working terminal isn't just an accessibility nightmare. It completely changes the baseline requirements of the OS, demanding actual hardware capable of handling that kind of graphical load just to output text.

I can already hear a few folks in the back whispering about alternatives like kmscon. To them, let me reply with one single word: inaccessibility. To those of us who need to use a screen reader, or even accessibility tools like a magnifier, kmscon is utterly impossible to use. Granted, there was never a magnifier in the VT either, but the point stands: removing the VT does not help people with disabilities. It does not make things better. It actively makes things worse by destroying the one text-based foundation we could actually rely on.

I want to make this absolutely clear right from the get-go: I am not blaming the people from the Linux kernel. The kernel folks are perfectly content to leave well enough alone; their goal is merely to make it possible to run a VT-less system. The blame rests entirely on the distributions that want to enforce this change. When distributions push to remove the underlying console infrastructure, they actively destroy the very tools we depend on when the graphical environment fails.

To understand how deep this disconnect goes, let’s look at a very recent patch submission on the Linux kernel mailing list. The patch author, Jocelyn Falempe, wanted to add a command-line boot parameter to enable or disable the VT. The kernel maintainers understandably didn't want to carry the burden of distro-level policy. But what almost everyone completely missed in that thread was the exchange that followed.

First, Greg Kroah-Hartman replied to the patch's author, reiterating that dropping the VT is a distribution's choice, not the kernel's:

It's all about the transition. Talks about VT-less system started in 2012, but since then no major desktop Linux distribution have done it. [...] Again, that's a distro's policy decision to make, don't force the kernel to support a wishy-washy distro's decision :) [...] I don't think a distribution will want to maintain VT and noVT for a long time.

Right after this, Nicolas Pitre—a prominent kernel developer—replied with a crucial perspective:

As a daily VT user for my primary Linux interface due to accessibility needs, I'm baffled by the idea of distributions removing this support. Of course this has lots of implications. For many users with disabilities, VT is not optional – it's the only fully usable interface. Consider this my official objection. Just don't do that.

And then came the response from Jocelyn Falempe, the patch submitter:

That patch is clearly for people like you, that will need more time to adapt their tools and workflow to a VT-less system. It's also less practical to develop alternative, if you need to rebuild your kernel to disable VT. Regarding accessibility, I don't see any technical reason why a VT-less system would be less efficient that what is currently available with VT.

There you have it. The absolute heart of the problem.

This response is incredibly condescending and unapologetically ableist. Of course he doesn't see the technical reasons or the implications—he is not disabled himself. He does not use or need our tools. Yet he feels entirely qualified to dictate that a VT-less system won't be “less efficient” for us, and tells a blind developer they just need “more time to adapt.”

This willful ignorance, this complete lack of care from the people architecting the future of the Linux desktop, is exactly why I am choosing to leave today. I am doing it now, while I still can, while I still have the time and energy to pivot before the floor completely falls out from under me.

Now, one could argue that since I run Arch Linux, whatever Fedora or Ubuntu chooses to do with the VT won't affect me. They would be partially right, but they are forgetting one massive dependency: systemd.

Fedora heavily drives systemd's development. If systemd eventually decides to no longer support kernels with the VT enabled, then every single distribution relying on systemd will have to follow along, one way or another. Arch Linux is usually pretty chill when it comes to keeping alternatives around—they still carry Xorg alongside Wayland, and iptables alongside nftables. But we cannot have the VT enabled and disabled at the exact same time. Expecting Arch to maintain two entirely separate kernel trees—one with the VT enabled and one without—is unrealistic at best.

And systemd absolutely dictates the underlying tooling. Look at the network stack: systemd 259 or 260 is poised to permanently remove support for iptables. If you want to use systemd-nspawn containers that rely on networking, unless you use the host's network directly, you will be forced to use nftables. When the upstream init system decides a component is dead, the distros eventually have no choice but to bury it. And I refuse to be collateral damage when they finally put the VT in the ground.

Inevitably, there are folks who will tell me, “You could just use Windows.”

Sure, I absolutely could. I could stick with Windows 10—until the Extended Security Updates (ESU) run out, which buys me a maximum of three years. Or, sure, I could jump to Windows 11 IoT LTSC instead. But ultimately, all these options do is give me a little more time. I would still be constantly running just to avoid getting caught by the next arbitrary deprecation.

On top of that, Windows is so badly built these days that, quite frankly, I am tired of dealing with it. The File Explorer eats up RAM like nobody's business. Windows will randomly decide to switch over to the wrong audio device for absolutely no good reason—exactly like Linux and ALSA do. I have had to deal with NVDA updates where, completely at random and without any underlying logic, the system decides to uncheck the box that allows it to start on the login screen at the next boot. And of course, when you try to rely on Narrator as a fallback in those moments, it decides to route its speech through the wrong audio device in the first place.

I have had more than enough. I am well and truly done.

I am not walking into the Apple ecosystem blind to reality. I know macOS will have its own set of issues and quirks. I am fully expecting terminal quirks, and I am fully prepared for things to not be 100% smooth. They simply can't be; no OS is perfect.

But here is what macOS won't be. It won't be my screen reader crashing 173 times during a basic OS installation. It won't be my screen reader entirely freezing up just because one single window in an application stopped responding, jamming the entire accessibility bus for the whole system. Nor will it be the reality that simply loading a very large document in a web browser causes the screen reader to completely die on me, yet again.

macOS will have its friction. But it will never be as fundamentally broken and hostile as things are right now on both Windows and Linux, nor as bad as they are clearly going to be in the future.

Once again, a friend of mine came through and helped where others either couldn't or wouldn't. Thanks to them, I am now officially waiting on my first ever Mac: the MacBook Neo, that I ordered in the evening of march 11. I am more than ready to dive in head first, just like I had to do all those years ago when I finally left Windows XP behind.

Let the new chapter begin.