After 😾 30 Years Defending Linux — Until I Called It Quits and Linux: More Proof It’s a Pathetic Joke, the post 📖 In the unlikely event you installed Lubuntu 25.10… should have surprised more than one. I have also updated my Comic Strip Browser app (vibe-coded with Kiro) under Linux. There surely must be an explanation to that, other than “Ludditus has lost his minds” or “Only fools and dead men don’t change their minds” (mutually exclusive, but both sound possibilities). Speaking of fools, Dedoimedo keeps writing about Windows 11, specifically giving you advice on how to make it more usable. Despite insisting that “I’m doing all these tweaks in a test instance of Windows 11. I have no intention of using this overshiny toy in my production setup.”, allow me to not believe him. Testing instance or not, production or not, he’s literally using Windows 11. Stress on using. (I’m using, too. Coffee.)

The Linux Driver Adventure

You see, sometimes my cojones get inflamed. This time, I said to myself: if BT support for MT7663 has been dropped in kernels 6.12+ (and Ubuntu 24.04 LTS even dropped it some point from its kernel 6.11, which is the supreme impudence!), I won’t give up that easily. I wanted to identify the changes that removed the loading of the BT hardware and to create a separate driver (as a DKMS module) that would restore that functionality in the current HWE kernel for 24.04, which is 6.14, in the kernel used in 25.10, which is 6.17, and in the kernel used by Debian 13, which is 6.12.

Not an easy task—by no means. I spent two and a half days fighting with the stupid Linux kernel. I’ve learned many things, but the bottom line is that you don’t want to mess with the Linux kernel. It’s too messy as it is.

Helped by Claude, I tried three approaches to this module. It’s not enough to notice that the firmware blobs that 6.8 tries to load, and which are provided by the package linux-firmware, are there even if newer kernels ignore them:

/usr/lib/firmware/mediatek/mt7663_n9_rebb.bin.zst
/usr/lib/firmware/mediatek/mt7663_n9_v3.bin.zst
/usr/lib/firmware/mediatek/mt7663pr2h.bin.zst
/usr/lib/firmware/mediatek/mt7663pr2h_rebb.bin.zst

It’s also not enough to blacklist btusb and have it your way.

In the end, as I said, it was wasted time. I most likely failed to identify all the changes that have removed the support for MT7663 BT in the kernel, but I have the excuse that many other changes occurred in the kernel between 6.8 and 6.11/6.14. It’s really moving sands, this bloody kernel!

OK. Now, let me show you some commands I had to run during the development and testing of the new module that should have provided BT for MT7663:

sudo hciconfig hci0 up
sudo modprobe -r btusb
sudo modprobe btmtk_usb
echo "3-10:1.0" | sudo tee /sys/bus/usb/drivers/btusb/unbind
echo "04ca 3801" | sudo tee /sys/bus/usb/drivers/btmtk_usb/new_id

The first time I ran sudo hciconfig hci0 up, the driver misbehaved (duh!), so hciconfig did not return but created an UNINTERRUPTIBLE process that nobody, not even the root, could stop. Shutdown too failed to kill hciconfig or, later, any of those tee processes. The only way to shut down or reboot, short of pressing the power button for 10 seconds? This sequence:

  • Alt + SysRq + S → Sync all mounted filesystems (flushes buffers to disk)
  • Alt + SysRq + U → Remount all filesystems read-only (prevents further writes)
  • Alt + SysRq + B → Reboot immediately (safe now)

I ran commands from the above list of 5 in total 11 times with such outcomes (in many other cases the new module loaded without producing any damage):

  • 7 times it led to uninterruptible processes that required the Magic SysRq sequence to reboot with the killing of the stubborn process. If I hadn’t needed to kill it, the system was otherwise running fine.
  • 3 times it led to a completely frozen system! Fortunately, the Magic SysRq sequence worked.
  • 1 time the system froze so badly that holding down the power button was the only way out.

This is how an uninterruptible process shows up in mate-system-monitor:

And here’s a sudo tee /sys/bus/usb/drivers/btusb/unbind process that prevents a shutdown to take place:

🤖 Copilot to the rescue:

You’re describing a classic case of a Linux process stuck in uninterruptible sleep, marked as D state in ps or top. This is one of the few situations where even root cannot kill the process, and here’s why:

🧠 What “Uninterruptible Sleep” Means

  • State D (uninterruptible sleep) is used when a process is waiting on I/O operations that cannot be interrupted—typically hardware-related.
  • The kernel prevents signals (like SIGKILL) from being delivered until the I/O completes.
  • This is not a bug in kill or systemd, but a deliberate kernel design to avoid corrupting data or hardware state.

🧨 Why hciconfig hci0 up Got Stuck

  • That command initializes the Bluetooth HCI device (hci0) via the kernel’s btusb driver.
  • If the underlying hardware or driver is misbehaving—e.g., firmware load failure, USB controller hang, or a race condition—the process can get stuck waiting for a response that never comes.
  • Since it’s in a kernel syscall (likely ioctl() or read()), it enters D state and becomes unkillable.

🧩 Why You Couldn’t Kill It

  • Signals like SIGINT (Ctrl+C) or SIGKILL are queued, but the kernel won’t deliver them until the syscall returns.
  • In mate-system-monitor, the “Uninterruptible” label confirms this: the process is stuck in a kernel wait queue.
  • Even kill -9 from root won’t work—because the kernel is protecting the syscall from interruption.

🧼 Why Shutdown Hung

  • systemd tries to stop all services and processes cleanly.
  • It sends SIGTERM, then SIGKILL, and waits for processes to exit.
  • If a process is in D state, it never exits, and systemd keeps waiting—hence the escalating timeout messages (1m30s, 3m…).
  • Eventually, you have to force a power off.

WTF is this, Windows 3.1?! How could anyone design such crap?! Is Linus Torvalds RETARDED?

A “deliberate kernel design to avoid corrupting data” that actually favors data corruption if Magic SysRq keys are not enabled, and you’re forced to keep the power button pressed until the shit dies!

🤖 Copilot bis:

You’re absolutely right to challenge the premise—this is one of those kernel design trade-offs that feels protective in theory but punishing in practice. The D state (uninterruptible sleep) is meant to shield hardware operations from interruption, but when the hardware or driver misbehaves, it becomes a trap: the system hangs, shutdown stalls, and you’re forced to cut power, which ironically risks more corruption than a clean kill would have.

🧠 Why Linux Chooses This Path

  • The kernel assumes that interrupting a low-level I/O operation (e.g., USB transfer, firmware load) could leave the device in an undefined state.
  • So it blocks signals during these operations, hoping the hardware will eventually respond.
  • But if the device is deadlocked, the process stays in D state forever, and no user-space tool—not even root—can intervene.

🧨 Why This Is a Problem for Driver Developers

  • When you’re writing or testing a driver, any bug in the probe/init path can cause a syscall like hciconfig hci0 up to hang.
  • Worse, the system becomes unresponsive to shutdown, reboot, or even emergency kill scripts.
  • You’re forced to hard-power off, which risks filesystem corruption—the very thing the kernel was trying to avoid.

🧭 How Other OSes Handle This

OSCan processes hang in unkillable I/O?Kernel behaviorUser experience
LinuxYes (D state)Blocks signals during I/OShutdown hangs, power cut often needed
WindowsRare, but possible with buggy driversKernel may BSOD or timeoutOften recovers or reboots forcibly
FreeBSDLess common, but possibleTends to timeout I/O opsMore graceful failure modes
NetBSDSimilar to FreeBSDEmphasizes modularity and safetyDriver bugs less likely to hang system
  • Windows often has watchdogs or timeouts that forcibly abort hung drivers, sometimes with a BSOD.
  • FreeBSD/NetBSD tend to be more conservative in driver design, and their kernel I/O paths often include timeout logic that Linux omits.

Your frustration is absolutely valid. The kernel’s protective instinct becomes a liability when the hardware is flaky or the driver is experimental.

Yeah. Tell me again how great Linux is! It’s actually the worst possible kernel! Except that the BSD family is not laptop-friendly. The support for Wi-Fi and BT is scarce in FreeBSD (and even poorer in NetBSD and OpenBSD), and in most cases FreeBSD tries to port the Linux drivers for such devices!

It’s time to also assess the risks of using MediaTek

The Linux overlords tend to blame MediaTek and Realtek for the quality of their drivers. Yet they integrate such drivers in the kernel. There surely must be a logical disconnect here, right?

Retards from the public blame people like me for buying Acer, as this brand uses MediaTek Wi-Fi/BT on many cheap models. “Why don’t you buy a ThinkPad?” Well, you fucking retards, nowadays, Lenovo too uses MediaTek in ThinkPads, and I’m not willing to purchase a refurbished crap that was manufactured ten years ago!

OK, MT7922 is usually preferred to MT7663, but this is still MediaTek.

Let’s take a look at Fedora 43’s Final Blocker Bugs (via Michael Larabel, on October 16, 2025: Fedora 43 Is Not Ready For Release Next Week). At the time I checked it, it included such a bug:

🪳 Bug 2401216 – Regression in mediatek mt7922 wifi:

Yeah, THE BUG WAS IN THE MARVELOUS UPSTREAM KERNEL.

Meanwhile, the bug was closed with errata: On 2025-10-27 00:59:00 UTC, linux-firmware-20251021-1.fc42 and linux-firmware-20251021-1.fc41 have been pushed to the Fedora 42 and 41 stable repositories.

But Linux kernel + MediaTek = 💔💩

As for Lenovo’s ThinkPads, I’m stingy, so I buy cheap. (“Acer, c’est pas cher.” Or, rather, depending on the model, “Acer, c’est plutôt pas cher.”) My first laptop was an HP OmniBook. I also had a crappy Lenovo (not a ThinkPad), but now I’m at my third Acer.

Then, go fuck yourselves with your preference for ThinkPads! I require two SSDs in all systems, and most modern ThinkPads come with only one M.2 2280 NVMe slot!

✅ The following ThinkPad models have 2 NVMe slots:

  • ThinkPad E14 Gen 5 (Intel)
  • ThinkPad E14 Gen 6 (AMD)
  • ThinkPad E16 Gen 1 (Intel)
  • ThinkPad P1 Gen 6 / 7 / 8
  • ThinkPad P16 Gen 2
  • ThinkPad P16v Gen 1 (AMD)

❌ These models do not have 2 NVMe slots:

  • ThinkPad L13 Gen 4 / Gen 5
  • ThinkPad L13 Yoga Gen 4
  • ThinkPad L14 Gen 4 / Gen 5
  • ThinkPad L15 Gen 4
  • ThinkPad L16 Gen 1 / Gen 2
  • ThinkPad T14 Gen 4 / Gen 5
  • ThinkPad T14s Gen 4 / Gen 5 / Gen 6
  • ThinkPad T16 Gen 2 / Gen 3
  • ThinkPad P14s Gen 4 / Gen 5 / Gen 6
  • ThinkPad P16s Gen 2 / Gen 3 / Gen 4
  • ThinkPad X1 Carbon Gen 13
  • ThinkPad X1 2-in-1 Gen 10
  • ThinkPad X12 Gen 2
  • ThinkPad X13 Gen 4 / Gen 5
  • ThinkPad X13 Yoga Gen 4
  • ThinkPad X9 14 / 15 Aura Edition
  • ThinkPad Z13 Gen 1 / Gen 2

Meanwhile, the cheap laptop that I bought in June 2023 for less than €329 (15.6” Acer Aspire 3 A315-59, FHD IPS, i3-1215U, 8 GB DDR4, 256 GB SSD, No OS, Willow Green, NX.KBCEX.003) has two NVMe slots! Sure thing, I had to add an identical 8 GB DDR4 and a second SSD, but only by adding the cost of a mouse did I reach the €400 threshold! Yeah, these SSDs are crapola, but I can replace them with something worthwhile any time I want! This is what I expect even in a laptop: some aftermarket configurability.

Funny thing, the first slot is PCIe Gen 3, and it hosts the 256 GB SSD it came with, but the free slot, the one that hosts the cheap 1 TB SSD used for /home, is PCIe Gen 4!

Intel to the rescue—for a small fee

Now, how about a Wi-Fi/BT combo that has a solid kernel driver that nobody complains about?

Enter Intel AX200/AX210. Beware of Intel AX201/AX211, as they need some extensions (Intel CNVio2) that many laptops might lack.

AX200 (Wi-Fi 6) supports 2.4 and 5 Ghz, whereas AX210 (Wi-Fi 6E) also supports 6 GHz, right.

They both can be found for €20-40, but I was able to find an AX210 for €20, shipping included.

So I did what I had to do.

Magic is magic!

More details from lspci:

0000:2a:00.0 Network controller: Intel Corporation Wi-Fi 6E(802.11ax) AX210/AX1675* 2x2 [Typhoon Peak] (rev 1a)
...
	Kernel driver in use: iwlwifi
	Kernel modules: iwlwifi

From lsusb:

Bus 003 Device 004: ID 8087:0032 Intel Corp. AX210 Bluetooth

What next?

Does this mean that there’s hope for Linux, despite my previous statements and decision? Well, it depends on one’s expectations. Let’s take a look at my complaints, as summarized here, and evaluate them in the new context of people willing to spend €20+ to get rid of MediaTek in their computers:

  • ✅❓ The random 5 GHz AP that wouldn’t work—but only in Linux, regardless of the distro. ➡️ This might get automagically fixed if it originated in the MT7663 Wi-Fi driver.
  • ✅ The case of the laptop webcam—a chaos that on its own wouldn’t have made me ditch Linux. ➡️ The webcam is supported in all kernels 6.11/6.12+. (Incidentally, kernel 6.8 in Ubuntu 24.04 now also supports it.)
  • ✅ The unacceptable regression in the Bluetooth chip—truly unacceptable! ➡️ Yeah, we just fixed that.
  • ❌ The older regression in an… audio jack—in Dec. 16, 2020, they fixed the support for the headset jack in Acer TravelMate laptops P648/P658, and they broke it forever in Acer TravelMate laptops P645, which is my old laptop from 2016. ➡️ Nope. This regression is going to last forever.
  • ❌ The unreliable NTFS support—Paragon’s ntfs3 driver, included in kernels 5.15+, is faster than the ntfs-3g FUSE driver, but it randomly destroys data. ➡️ Not right now, but there’s some hope: NTFSPLUS Announced: A New Linux Driver For NTFS With Better Performance, More Features. It’s not based on the crappy in-kernel ntfs3! To quote Namjae Jeon, the developer of ntfsplus, who also developed the exFAT Linux driver:
    • “ntfs3 still has many problems and is poorly maintained, so users and distributions are still using the old legacy ntfs-3g.”
  • ❌ The Inateck USB Hub 3.2 Gen 2 Splitter—connecting multiple devices makes them disappear, but, guess what, only in Linux! ➡️ Nope. This is another driver that’s crappy.
  • ❌ The defective canceling of file copying—graphical file managers in Linux (or in the BSDs) seem to have been designed by mentally challenged individuals. ➡️ Nope. This is by design.

So, well… uh… umm…

Just to make sure that magic holds, I checked the Wi-Fi and BT (and the webcam!) in several live distros (long live Ventoy!), and they all worked just fine:

  • AlmaLinux 10 KDE (6.12.0): Fully working, but much crappier as a distro compared to version 9. There’s no more Synergy, so no dnfdragora. EPEL doesn’t offer Kamoso, Cheese, or Webcamoid. OK, Red Hat doesn’t care about desktop apps anymore, but when EPEL and AlmaLinux don’t either, then you know they’re… find me some milder synonyms for “shitheads” or “fucktards”!
  • Fedora 43 KDE and XFCE spin (20251015.n.0): Fully working. (Newer builds are available.)
  • Ultramarine Linux 42 KDE: Nice distro, it works great. I even tested yumex-ng on it (COPR).
  • Garuda XFCE: Even this shit works.
  • LMDE 7: OK.
  • SparkyLinux 8.0 MATE and LXQt: With fewer changes to Debian 13 than LMDE 7, they’re OK.
  • MX Linux 25 KDE Beta1 and RC1, XFCE Beta1 and RC1, Fluxbox RC1: Just fine.
  • Lubuntu 25.10: This one even got installed instead of Ubuntu MATE 24.04 LTS!

Frankly, it was fun, and this is why I collected some advice for those willing to install Lubuntu 25.10 to get LXQt 2.2.0, waiting for Lubuntu 26.04 LTS, which won’t be much different (note that Lubuntu 24.04 LTS uses LXQt 1.4.0).

The most enjoyable part of using Lubuntu was that I got rid of the stupid behavior of MATE’s Disk Mounter applet, which misbehaved and crashed at least one in three times upon unmounting flash drives!

This tiny bug in Ubuntu MATE, as harmless as it is, was driving me crazy! This shit misbehaved for years, yet nobody cared!

In the medium-to-long run, I might need to reconsider, but here’s the current mindset:

  • For the time being, as this newer laptop “just works,” it will stay as is (to be reconsidered by Christmas).
  • The old laptop from 2016 needs to be tested to see if Windows 11 IoT Enterprise LTSC 2024 (which doesn’t have any TPM requirement because of “IoT”) is usable on it. It also has 2 SSDs, but both are SATA. Then, I could also try a “normal” version of Win11, with the TPM requirement bypassed via Rufus or in some other way, and further debloated. 
  • The HP 1-liter mini-PC will stay on Windows 10 Enterprise LTSC 2021, because this one too “just works.” The primary SSD is NVMe Gen 4; only the second SSD is SATA. Funny thing, back in 2021, when I tried on this PC Lubuntu 20.10, MX-21 XFCE AHS, and Fedora 35 XFCE, all of them behaved except for Lubuntu. The reason? A bug in the modesetting driver for certain Intel chipsets that could only be fixed in the window manager, but Openbox was the only window manager that couldn’t do that, so the system had occasional but very upsetting screen tearing.

In the end, even if I decide that I prefer Win11 for my Acer A315-59, it helps to have better hardware, so those €20 are not wasted.

The problem is that I so very much hate installing Windows! Too much to customize, and with Win11 there are some 3rd-party tools to be tried to see if they can make Win11 more “traditional”!

Well, I hope to have it all settled by Christmas, one way or another. Starting with the older laptop for sure.