If Your Kernel Development Is A Little Rusty

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

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

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”

My Winter Of ’99: The Year Of The Linux Desktop Is Always Next Year

Growing up as a kid in the 1990s was an almost magical time. We had the best game consoles, increasingly faster computers at a pace not seen before, the rise of the Internet and World Wide Web, as well the best fashion and styles possible between neon and pastel colors, translucent plastic and also this little thing called Windows 95 that’d take the world by storm.

Yet as great as Windows 95 and its successor Windows 98 were, you had to be one of the lucky folks who ended up with a stable Windows 9x installation. The prebuilt (Daewoo) Intel Celeron 400 rig with 64 MB SDRAM that I had splurged on with money earned from summer jobs was not one of those lucky systems, resulting in regular Windows reinstalls.

As a relatively nerdy individual, I was aware of this little community-built operating system called ‘Linux’, with the online forums and the Dutch PC magazine that I read convincing me that it would be a superior alternative to this unstable ‘M$’ Windows 98 SE mess that I was dealing with. Thus it was in the Year of the Linux Desktop (1999) that I went into a computer store and bought a boxed disc set of SuSE 6.3 with included manual.

Fast-forward to 2025, and Windows is installed on all my primary desktop systems, raising the question of what went wrong in ’99. Wasn’t Linux the future of desktop operating systems?

Continue reading “My Winter Of ’99: The Year Of The Linux Desktop Is Always Next Year”

What Does Linux Need? A Dial!

It’s fair to say that there can’t be many developers who have found the need for a rotary telephone dial as a peripheral for their Linux computer, but in case you are among them you might find [Stefan Wiehler]’s kernel driver for rotary dials to be of use.

It’s aimed at platforms such as systems-on-chip that have ready access to extra GPIOs, of which it will need a couple to service the BUSY and PULSE lines. There are full set-up instructions, and once it’s in place and configured it presents the dial as though it were a number pad.

We like this project, in fact we like it a lot. Interfacing with a dial is always something we’ve done with a microcontroller though, so it will be interesting to see whether it finds a use beyond merely curiosity. We can already see a generation of old-school dial IP phones using Linux-capable dev boards. He leaves us with a brief not as to whether Linus Torvalds would see it as worthy of mainline inclusion, and sadly however much we want things to be different, we agree that it might be wishful thinking.

If you’d like to use a dial phone, there can be simpler ways to do it.

Header: Billy Brown, CC BY 2.0 .

Terminal DAW Does It In Style

As any Linux chat room or forum will tell you, the most powerful tool to any Linux user is a terminal emulator. Just about every program under the sun has a command line alternative, be it CAD, note taking, or web browsing. Likewise, the digital audio workstation (DAW) is the single most important tool to anyone making music. Therefore, [unspeaker] decided the two should, at last, be combined with a terminal based DAW called Tek.

Tek functions similarly to other DAWs, albeit with keyboard only input. For anyone used to working in Vim or Emacs (we ask you keep the inevitable text editor comment war civil), Tek will be very intuitive. Currently, the feature set is fairly spartan, but plans exist to add keybinds for save/load, help, and more. The program features several modes including a multi-track sequencer/sampler called the “arranger.” Each track in the arranger is color coded with a gradient of colors generated randomly at start for a fresh look every time.

Modern audio workflows often span across numerous programs, and Tek was built with this in mind. It can take MIDI input and output from the JACK Audio Connection Kit, and plans also exist to create a plugin server so Tek could be used with other DAWs like Ardor or Zrythm. Moreover, being a terminal program opens possibilities for complicated shell scripting and other such Linux-fu.

Maybe a terminal DAW is not your thing, so make sure to check out this physical one instead!

Linux Fu: Stopping A Runaway

The best kind of Hackaday posts are the ones where there was some insurmountable problem with an elegant solution devised through deep analysis of the problem and creativity. This is not one of those posts. I’m sure you are familiar with bit rot. You know, something works for a long time and then, for no apparent reason, stops working. Well, that has been biting me, and lacking the time for the creative, elegant solution, I decided to attack it with a virtual chainsaw.

It all started with a 2022 Linux Fu about using autokey.

The Problem

I use autokey to give me emacs-style keystrokes in Web browsers and certain other programs. It intercepts keystrokes and translates them into other keystrokes. The problem is, the current Linux community hates autokey. Well, that’s not strictly true. They just love Wayland more. One reason I won’t switch from X11 is that I haven’t found a way to do something like I do with autokey. But since most of the powers-that-be have decided that X11 is bad and Wayland is good, X11 development is starting to show cracks.

In particular, autokey isn’t in the normal repositories for my distro anymore (KDE Neon). Of course, I’ve installed the latest version myself. I’m perfectly capable of doing that or even building from source. But lately, I’ve noticed my computer hangs, especially after sleeping for a long time. Also, after a long time, I notice that autokey just quits working. It is running but not working and I have to restart it. The memory consumption seems high when this happens. Continue reading “Linux Fu: Stopping A Runaway”