Linux Hacks

552 Articles

Why The Latest Linux Kernel Won’t Run On Your 486 And 586 Anymore

July 2, 2025 by 102 Comments

Some time ago, Linus Torvalds made a throwaway comment that sent ripples through the Linux world. Was it perhaps time to abandon support for the now-ancient Intel 486? Developers had already abandoned the 386 in 2012, and Torvalds openly mused if the time was right to make further cuts for the benefit of modernity.

It would take three long years, but that eventuality finally came to pass. As of version 6.15, the Linux kernel will no longer support chips running the 80486 architecture, along with a gaggle of early “586” chips as well. It’s all down to some housekeeping and precise technical changes that will make the new code inoperable with the machines of the past.

Continue reading “Why The Latest Linux Kernel Won’t Run On Your 486 And 586 Anymore” →

Switching From Desktop Linux To FreeBSD

June 29, 2025 by 43 Comments

People have been talking about switching from Windows to Linux since the 1990s, but in the world of open-source operating systems, there is much more variety than just the hundreds of flavors of Linux-based operating systems today. Take FreeBSD, for example. In a recent [GNULectures] video, we get to see a user’s attempt to switch from desktop Linux to desktop FreeBSD.

The interesting thing here is that both are similar and yet very different, mainly owing to their very different histories, with FreeBSD being a direct derivative of the original UNIX and its BSD derivative. One of the most significant differences is probably that Linux is just a kernel, with (usually) the GNU/Hurd userland glued on top of it to create GNU/Linux. GNU and BSD userland are similar, and yet different, with varying levels of POSIX support. This effectively means that FreeBSD is a singular OS with rather nice documentation (the FreeBSD handbook).

Continue reading “Switching From Desktop Linux To FreeBSD” →

Ancient SoundBlaster Cards Just Got A Driver Update

June 28, 2025 by 11 Comments

Old hardware tends to get less support as the years go by, from both manufacturers and the open-source community alike. And yet, every now and then, we hear about fresh attention for an ancient device. Consider the ancient SoundBlaster sound card that first hit the market 31 years ago. [Mark] noticed that a recent update squashed a new bug on an old piece of gear.

Jump over to the Linux kernel archive, and you’ll find a pull request for v6.16-rc3 from [Takashi Iwai]. The update featured fixes for a number of sound devices, but one stands out amongst the rest. It’s the SoundBlaster AWE32 ISA sound card, with [Iwai] noting “we still got a bug report after 25 years.” The bug in question appears to have been reported in 2023 by a user running Fedora 39 on a 120 MHz Pentium-based machine.

The fixes themselves are not particularly interesting. They merely concern minutiae about the DMA modes used with the old hardware. The new updates ensure that DMA modes cannot be changed while the AWE32 is playing a PCM audio stream, and that DMA setups are disabled when changing modes. This helps avoid system lockups and/or ugly noises emanating from the output of the soundcard.

It’s incredibly unlikely this update will affect you, unless you’re one of a handful of users still using an ISA soundcard in 2025. Still, if you are — and good on you — you’ll be pleased someone still cares about your user experience. Meanwhile, if you’re aware of any other obscure old-school driver updates going on out there, don’t hesitate to let us know on the tips line. Want to relive your ISA card’s glory days? Plug it into USB.

Image credit: Gona.eu, CC BY-SA 3.0

[Thanks to Meek Mark for the tip!]

Rust Drives A Linux USB Device

June 26, 2025 by 13 Comments

In theory, writing a Linux device driver shouldn’t be that hard, but it is harder than it looks. However, using libusb, you can easily deal with USB devices from user space, which, for many purposes, is fine.  [Crescentrose] didn’t know anything about writing user-space USB drivers until they wrote one and documented it for us. Oh, the code is in Rust, for which there aren’t as many examples.

The device in question was a USB hub with some extra lights and gadgets. So the real issue, it seems to us, wasn’t the code, but figuring out the protocol and the USB stack. The post covers that, too, explaining configurations, interfaces, and endpoints.

There are other ancillary topics, too, like setting up udev. This lets you load things when a USB device (or something else) plugs in.

Continue reading “Rust Drives A Linux USB Device” →

If Your Kernel Development Is A Little Rusty

June 21, 2025 by 38 Comments

To paraphrase an old joke: How do you know if someone is a Rust developer? Don’t worry, they’ll tell you. There is a move to put Rust everywhere, even in the Linux kernel. Not going fast enough for you? Then check out Asterinas — an effort to create a Linux-compatible kernel totally in Rust.

The goal is to improve memory safety and, to that end, the project describes what they call a “framekernel.” Historically kernels have been either monolithic, all in one piece, or employ a microkernel architecture where only bits and pieces load.

A framekernel is similar to a microkernel, but some services are not allowed to use “unsafe” Rust. This minimizes the amount of code that — in theory — could crash memory safety. If you want to know more, there is impressive documentation. You can find the code on GitHub.

Will it work? It is certainly possible. Is it worth it? Time will tell. Our experience is that no matter how many safeguards you put on code, there’s no cure-all that prevents bad programming. Of course, to take the contrary argument, seat belts don’t stop all traffic fatalities, but you could just choose not to have accidents. So we do have seat belts. If Rust can prevent some mistakes or malicious intent, maybe it’s worth it even if it isn’t perfect.

Want to understand Rust? Got ten minutes?

StatusNotifierItem: How Standard Non-Standards Tear Linux Desktops Apart

June 17, 2025 by 65 Comments

Theoretically when you write a GUI-based application for Linux there are standards to follow, with these all neatly documented over at the Freedesktop website. However, in reality, Freedesktop is more of a loose collection of specifications, some of which are third-party specifications that have somehow become the de facto standard. One example of this is the StatusNotifierItem spec that provides a way for applications to create and manage a ‘system tray’ icon.

This feature is incredibly useful for providing a consistent way to users for quickly accessing functionality and to see application status. Unfortunately, as [Brodie Robertson] notes in a recent video, not everyone agrees with this notion. Despite that Windows since 95 as well as MacOS/OS X and others provide similar functionality, Gnome and other Linux desktop environments oppose such system tray icons (despite a popular extension), with an inevitable discussion on Reddit as a result.

Although the StatusNotifierItem specification is listed on the Freedesktop website, it’s under ‘Draft specifications’ along with another, apparently internal-but-unfinished System tray proposal. Meanwhile DEs like KDE have integrated first-party support (KStatusNotifierItem) for the specification. There’s currently an active Freedesktop Gitlab discussion on the topic, whether StatusNotifierItem should even be in the list, or become an approved specification.

With the specification mired in bureaucracy and multiple camps pushing their own idea of what ‘the Linux desktop’ should look like, it feels like a real shame that the Linux Standard Base effort died a decade ago. Users and developers just want their desktop environment to come with zero surprises, after all.

Continue reading “StatusNotifierItem: How Standard Non-Standards Tear Linux Desktops Apart” →

The Ongoing BcacheFS Filesystem Stability Controversy

June 10, 2025 by 57 Comments

In a saga that brings to mind the hype and incidents with ReiserFS, [SavvyNik] takes us through the latest data corruption bug report and developer updates regarding the BcacheFS filesystem in the Linux kernel. Based on the bcache (block cache) cache mechanism in the Linux kernel, its author [Kent Overstreet] developed it into what is now known as BcacheFS, with it being announced in 2015 and subsequently merged into the Linux kernel (6.7) in early 2024. As a modern copy-on-write (COW) filesystem along the lines of ZFS and btfs, it was supposed to compete directly with these filesystems.

Despite this, it has become clear that BcacheFS is rather unstable, with frequent and extensive patches being submitted to the point where [Linus Torvalds] in August of last year pushed back against it, as well as expressing regret for merging BcacheFS into mainline Linux. As covered in the video, [Kent] has pushed users reporting issues to upgrade to the latest Linux kernel to get critical fixes, which really reinforces the notion that BcacheFS is at best an experimental Alpha-level filesystem implementation and should probably not be used with important data or systems.

Although one can speculate on the reasons for BcacheFS spiraling out of control like this, ultimately if you want a reliable COW filesystem in Linux, you are best off using btrfs or ZFS. Of course, regardless of which filesystem you use, always make multiple backups, test them regularly and stay away from shiny new things on production systems.

Continue reading “The Ongoing BcacheFS Filesystem Stability Controversy” →