← go back 'blog'
No, you do NOT want [anyone] to use desktop Linux
Heeeyyy everybody, welcome back to another episode of Hard To Swallow Pills. As you can probably tell, I can hardly contain myself right now, because today is the day we get to bully Linux.
~ certainly no one, certainly never
...ok, that isn't very fair. But alas, let's start from the beginning, shall we?
Recently, I saw this YouTube video by one of the most popular (if not the most popular) content creators on the platform. It made me think, honestly. About all the issues that I had to face as a computer user back in 2018. Then in 2019. Then in 2020. Then in 2021, and so on, you get the point.
Linux is great for servers, virtualization, storage, whatever homelab needs you have. That much is true and I will not try to gaslight you into thinking otherwise. The ecosystem really is good at it.
100%. Not 90%, not 95%, not 99%, 100% of my work is done on Linux, natively, without
the need for Windows or macOS. To some, this might sound like a blissful thing;
oh, you don't have to withstand Microsoft or Apple!
Sure, I don't. I merely have to deal with the beautiful consequences of being
a second-class citizen to every single company I source my hardware from, but that's not
so bad, is i-
ON WIFI
In 2018, when I first installed Linux on my main PC, I had random kernel freezes due to something (that had never occurred on Windows). That something later turned out to be a dumbass Asus Wi-Fi PCIe card that I only figured out was the issue because I associated weird audio glitches with sporadic connection problems / signal loss. After switching to Ethernet, no such issues took place anymore (but of course I was very eager to just blame Nvidia, because noob Linux user mad and can't even use dmesg since they don't know what it is). Good luck to those who aren't too observant or savvy when it comes to these things. This card probably works now, in 2025, but who knows, I don't need Wi-Fi in my PC anymore.
In 2019, I bought a laptop that contains a Realtek 8821CE Wi-Fi card. I then realized it's completely inoperative, and that I had to use a custom kernel driver for it to get properly detected by NetworkManager. So fun, amirite? Around Linux 4.19 / 4.20, zypper could randomly break it with DKMS on OpenSUSE for no reason sometimes, which was even more fun! The upstream driver now works by the way. (Kudos to Tomás Pinho for working on that out-of-tree driver though, really good work!)
ON ETHERNET
A friend of mine bought a rather expensive X870 PC mainboard, only to figure out his 5Gbit Ethernet port did not work at all, and he had to use an external USB-C network controller. This is fixed now.
ON BLUETOOTH
I bought a laptop that contains a MediaTek MT7922 USB Bluetooth adapter. I then realized it has a chance of randomly freezing kernel and user space due to this bad boy. I then proceeded with blacklisting the btusb kernel module. Simple, right? All you have to know is:
- that such a driver exists,
- blacklisting kernel modules also exists,
- how to figure out you have to do it in the first place when you see an issue like this,
- that you can kiss Bluetooth goodbye until it's fixed.
Yeah, good fucking luck with that. Maybe a random forum will kindly help you, maybe not. Especially when some of them are so toxic you're more likely to just ragequit than get anything solved (I'll save this for a different post though). This is NOT how any of it is supposed to work. At all. But to give MediaTek credit, despite the NEW status, the issue in question has been solved since 6.12.x (I forgot which patch level it was and I do not care to check).
This was in late 2024, mind you, long after the Steam Deck's launch, long after many evangelists started their preaching, long after we were supposed to get 'The Year Of The Linux Desktop'. ah, right, desktop, not laptop :rofl:, how funny
Don't get me wrong, I ain't a saint here, certainly not. I used to preach too. I was so good at it I managed to brick my friend's hard drive by recommending BTRFS to him (he still insists that was only the fault of his distro, when in reality it was the shitty state of that filesystem driver around that time).
Ok, but how did you know what to do when you were also getting
started with Linux? Surely anybody can do this! You're just a hater!
I was 'myself' when I was learning about this. By 'myself', I mean 'an unemployed high school student with no financial problems and too little to do'. I was bored, basically. Extremely into computers at the time as well. Some people (like PewDiePie who I mentioned at the beginning) who just want something to tinker with might find this awesome and all. I know I did. But plenty of adults don't care because they have families to feed, bills to pay and work to do. Linux is suicide in that case.
Ok, sorry for the tangent, let's continue.
ON GRAPHICS PROCESSING UNITS
Take a look at the following issue trackers:
- https://gitlab.freedesktop.org/drm/xe/kernel/-/issues
- https://gitlab.freedesktop.org/drm/amd/-/issues
- https://gitlab.freedesktop.org/mesa/mesa/-/issues
- https://forums.developer.nvidia.com/c/gpu-graphics/linux/148
I'd understand certain sporadic issues with display malfunctions, soft freezes or stutter. This happens, modern software isn't perfect. But here's the thing: modern Linux GPU drivers are an even hotter mess. They're so unstable they can sometimes cause your entire desktop session to become toast, poof, like that.
That's great for work, isn't it? You just wrote a banger paragraph and were so into it you forgot to Ctrl+S that one time before amdgpu decided to ring gfx_0.0.0 timeout, signaled seq, emitted seq Process information kwin_wayland pid and then assert-trip at map_dc_state_into_dml_display_cfg causing your HUBPs with indices > 0 to reinitialize improperly, completely destroying your display outputs BLAH BLAH BLAH (I remember all these stupid names by heart at this point, it's really not good...).
Combine this with the fact that the only practically usable desktop with enough common sense to even care about a scenario like this and implement proper GPU recovery mechanisms is Plasma. And nobody likes Plasma, right? Everybody knows that the only great and usable desktop session is GNOME PAPERWM HYPRLAND SWAYBG SWAYWM SWAYOS GNOMEOS. NNGH OOOHHHHH I love tribalism (I'll save that for yet another blog post, don't worry :wink:).
And even with that, most Linux applications (let's say 90%) don't like it when you suddenly decide to pull your GPU from the system for a while, because nobody realistically cares about GPU robustness on this platform! I can't blame them actually, Linux was never meant for client usage...
Now, you might rightfully ask:
why, of all things, would GPUs be so fragile they are expected to crash?
The answer is quite simple. They are serial job executors with dependency lists.
Even though they execute parallelizable tasks, they do so one by one
(first 64x64x64 workgroup, then another 32x64x16 workgroup, etc.).
Picture your desktop session and GPU acceleration at the same time.
You first need your apps to render content to their windows (with the GPU), then
your compositor to render those windows on your screen (with the GPU),
and all that needs to happen in sync with vblank events (from the monitor through the GPU).
Not to go too deep here (it's unnecessary anyway), but GPUs are just very complicated chips. When they hang, every dependency (compositor, another app, whatever) stalls as well, because the GPU's ring buffer cannot progress, and all the graphics jobs are on it, executed one after another. GPUs are not like CPUs that you can never really 'hang' with user-space software because it can be ignored — it doesn't constitute a dependency for the rest of the session, it's just another asynchronously handled app after all.
This applies to every graphics / compute / video / memory transfer queue. No scheduler can ever fix this, that is the inherent fault of GPU design. Even with perfectly functioning task pre-emption (like what Nvidia does), you may still run into a situation where a full GPU reset is required.
With proper usermode queue support on AMD's GFX11+ chips, as well as per-queue resets finally working as intended, this will no longer be such a huge problem (only on RDNA3+ though lol), but here's the other thing: this has never been an issue on Windows, even on old GPU hardware. Not with video engine timeouts, not with graphics or compute ones either. Windows seems to just work no matter how crazy shaders you come up with inside of Unity / Unreal / Godot / your custom game engine.
Sure, some of that is on these programs to stop using X11, switch to Wayland and handle device loss (GPU resets) properly on Linux, but still: Microsoft did a very good job of protecting against faulty GPUs and drivers within their driver model and also... good graphics scheduling.
Speaking of, on the Linux side there isn't proper support for high priority contexts most of the time, meaning that if you want your compositor to never lag during window motion when FurMark is eating 100% of your GPU, you're mostly out of luck if you don't create an async compute queue with Vulkan, which is just... not every GPU supports multi-queue like that, but ok. Also, forget about dynamic GPU priority switching for foreground and background apps. There is work happening in that direction, but so far this hasn't really materialized.
I'm not here to undermine anyone's effort; there are plenty of hard-working devs trying to make the ecosystem better (KDE devs, people like Wim Taymans, Valve devs, AMD devs even, all of them are very helpful when it comes to bug reports, trust me). Some of that crashing stuff is due to insufficient testing (see this post), sure, but that's mostly because nobody truly cares about this platform for end users, again, and I can't blame them.
ON USERSPACE
This reminds me — even if we solve backend issues, even if we create The Perfect Desktop Linux OS, we still need apps that can run on it. After all, just like game consoles, an OS without downstream app support is worthless to an average computer user and is pretty much just a toy, right?
Yeah, about that. Need I say anything? You know what it is. You know what doesn't function. The games, the apps, the tools that you need for, I don't know... work? Play? Anything?!
I'm lucky enough I don't have to care about that, but I sympathize with everybody who does. Fine, you can try to run some of them, but they're probably gonna be borked one way or another, mostly by the developer, sometimes by Wine. You can also try an alternative or two, however we all know what they are and how out-of-touch people are to recommend them in the first place. There's nothing you can realistically do about any part of it, which sucks, I agree.
ON [the basis of] COMMON SENSE
In Conclusion
Alright, that was a lot of useless trivia for you. If, despite all this, you'd still like to try Linux, that's fine! Go try it. Maybe you'll like it, maybe it won't mess with you. I listed a few important areas for this platform to improve. Hopefully it does, but maybe it never will. No matter what you do, just please, for the love of the god / whatever you believe in (or don't),
do NOT give it undeserving praise.
Thank for read and sorry for mad.
I improve in future promise.
2025-04-27