There’s really a Linux distribution for everyone, it seems. EasyOS sounds like it’s going to be some Debian derivative with a theme or something, but it’s truly something different – in fact, it has such a unique philosophy and approach to everything I barely know where to even start.

Everything in EasyOS runs in containers, in the distribution’s own custom container format, even entire desktop environments, and containers are configured entirely graphically. EasyOS runs every application in RAM, making it insanely fast, and you can save the contents of RAM to disk whenever you want. You can also choose a special boot option where the entire session is only loaded in RAM, with disk access entirely disabled, for maximum security.

Now things are going to get weird. In EasyOS, you always run as root, which may seem like a stupid thing to do, and I’m sure some people will find this offputting. The idea, however, is you run every application as its own user (e.g. Firefox runs as the “firefox” user), entirely isolated from every other user, or in containers with further constraints applied. I honestly kind of like this approach.

If these first few details of what EasyOS is going for tickles your fancy, I really urge you to read the rest of their detailed explanation of what, exactly, EasyOS is going for. It’s an opinionated distribution, for sure, but it’s opinionated in a way where they’re clearly putting a lot of thought into the decisions they make. I’m definitely feeling the pull to give it a try and see if it’s something for me.

Sometimes you come across a story that’s equally weird and delightful, and this is definitely one of them. Oleksandr Natalenko posted a link on Mastodon to a curious email sent to the Linux Kernel Mailing List, which apparently gets sent to the LKML every single year. The message is very straightforward.

Is it possible to write a kernel module which, when loaded, will blow the PC speaker?

↫ R.F. Burns on the LKML

Since this gets sent every year, it’s most likely some automated thing that’s more of a joke than a real request at this point. However, originally, there was a real historical reason behind the inquiry, as Schlemihl Schalmeier on Mastodon points out. They link to the original rationale behind the request, posted to the LKML after the request was first made, all the way back in 2007.

At the time, the author was helping a small school system manage a number of Linux workstations, and the students there were abusing the sound cards on those workstations for shenanigans. They addressed this by only allowing users with root privileges access to the sound devices. However, kids are smart, and they started abusing the PC speaker instead, and even unloading the PC speaker kernel module didn’t help because the kids found ways to abuse the PC speaker outside of the operating system (the BIOS maybe? I have no idea).

And so, the author notes, the school system wanted them to remove the PC speakers entirely, but this would be a very fiddly and time-consuming effort, since there were a lot of PCs, and of course, this would all have to be done on-site – unlike the earlier solutions which could all be done remotely.

So, the idea was raised about seeing if there was a way to blow the PC speaker by loading a kernel module.  If so, a mass-deployment of a kernel module overnight would take care of the PC speaker problem once and for all.

↫ R.F. Burns on the LKML

So, that’s the original story behind the request. It’s honestly kind of ingenious, and it made me wonder if the author got a useful reply on the LKML, and if such a kernel module was ever created. The original thread didn’t seem particularly conclusive to me, and the later yearly instances of the request don’t seem to yield much either. It seems unlikely to me this is possible at all.

Regardless, this is a very weird bit of Linux kernel lore, and I’d love to know if there’s more going on. Various parts of the original rationale seem dubious to me, such as the handwavy thing about abusing the PC speaker outside of the operating system, and what does “abusing” the PC speaker even mean in the first place?

As Natalenko notes, it seems there’s more to this story, and I’d love to find out what it is.

The extensible scheduler “sched_ext” code has proven quite versatile for opening up better Linux gaming performance, more quickly prototyping new scheduler changes, Ubuntu/Canonical has been evaluating it for pursuing a more micro-kernel like design, and many other interesting approaches with it. Yet it’s remained out of tree but that is now changing with the upcoming Linux 6.11 cycle.

Linus Torvalds as the benevolent dictator for life “BDFL” of the Linux kernel announced he intends to merge the sched_ext patches for Linux 6.11 even though there has been some objections by other kernel developers. Torvalds feels the sched_ext code is ready enough and provides real value to the mainline Linux kernel. It’s not worth dragging out sched_ext continuing to be out-of-tree.

↫ Michael Larabel at Phoronix

I haven’t felt the need to mess around with the Linux scheduler in a long, long time – I have some vague memories of perhaps well over a decade ago where opting for a different scheduler could lead to better desktop-focused performance characteristics, but the details in my brain are so fuzzy that it may just be a fabricated or confabulated memory.

Last night, I ran through the ZFSBootMenu documentation guide for Void and followed it both on a VM and then on an external SATA HDD plugged through a USB case, taking some notes and getting a general idea of the process.

The Void installer does not support ZFS out of the box, so the Void Handbook itself recommends the ZFSBootMenu documentation before its own (a manual chroot installation) when it comes to doing a ZFS-on-root install. This guide from ZFSBootMenu is what we’ll be following throughout this post.

↫ Juno Takano

There’s a ton of good stuff in this lengthy, detailed, and helpful blog post. First, it covers Void Linux, which is one of the best signifiers of good taste, classy style, and generally being a good person. Void is not necessarily underappreciated – it gets a lot of mentions in the right places – but I do feel there are a lot more people for whom Void Linux would be a perfect fit but who don’t yet know about it. So, time for a very short introduction.

Void Linux is distribution with its own unique and very user-friendly package manager that’s an absolute joy to use. Unlike many other custom, more obscure package formats, the Void repositories are vast, generally some of the most up-to-date, and you’ll be hard-pressed to be asking for some piece of software that isn’t packaged. Void eschews systemd in favour of runit, and while I personally have no issues with systemd, diversity is always welcome and runit is, in line with everything else Void, easy to grasp and use. Lastly, while Void also comes in a GNU libc flavour, it feels like the “real” Void Linux is the one using musl.

Second is a tool I had never heard of: ZFSBootMenu. The name is rather self-explanatory, but in slightly more detail: it’s a self-contained small Linux-based bootloader that detects any Linux kernels and initramfs images on ZFS file systems, which can then be launched using kexec. It makes running Linux on ZFS quite a bit easier, especially for systems that don’t over ZFS as an option during installation, like, in this case, Void Linux.

And that’s what the linked post is actually about: setting up a root-on-ZFS Void EFI installation. It’s a great companion article for anyone trying something similar.

I’ve barely scratched the surface, but there’s enough here for me to seriously consider a switch to it as my primary Linux distro for testing and servers. I love that htop(1) and lsof(1) only shows a small list of recognisable processes, that it uses OpenRC, that package management seems straight forward, and that it’s so simple to configure. I’ve wondered what a modern, functional “Occam’s Linux” would look like. This is it.

↫ Ruben Schade

Alpine is very popular among people inclined towards BSD, but who still want to run Linux as well – and it’s easy to see why when you try it out or read about it. This article is a good jumping-off point for those of you curious about Alpine.

systemd uses DBus as the mechanism to interact with it. This article introduces just enough DBus concepts and the usage of busctl to communicate with systemd. These concepts should be useful when using DBus libraries.

↫ Beartama

Exactly what it says on the tin.

It’s a compelling story and on the surface makes a lot of sense. Carefully curated software patches applied to a known Linux kernel, frozen at a specific release, would obviously seem to be preferable to the random walk of an upstream open source Linux project. But is it true? Is there data to support this ?

After a lot of hard work and data analysis by my CIQ kernel engineering colleagues Ronnie Sahlberg and Jonathan Maple, we finally have an answer to this question. It’s no. The data shows that “frozen” vendor Linux kernels, created by branching off a release point and then using a team of engineers to select specific patches to back-port to that branch, are buggier than the upstream “stable” Linux kernel created by Greg Kroah-Hartman.

↫ Jeremy Allison at CIQ

I mean, it kind of makes sense. The full whitepaper is available, too.

With Qualcomm and Microsoft about to flood the market with devices using the new Snapdragon X Elite, those of us who don’t want to use Windows felt a bit uneasy – what’s Linux support going to look like for this new generation of ARM devices? Well, it seems Qualcomm’s been busy, and they’ve published a blog post detailing their work on Linux support for the X Elite.

It’s been our priority not only to support Linux on our premium-tier SoCs, but to support it pronto. In fact, within one or two days of publicly announcing each generation of Snapdragon 8, we’ve posted the initial patchset for Linux kernel support. Snapdragon X Elite was no exception: we announced on October 23 of last year and posted the patchset the next day. That was the result of a lot of pre-announcement work to get everything up and running on Linux and Debian.

↫ Qualcomm’s developer blog

In the blog post, the company details exactly which X Elite features have already been merged into mainline with Linux 6.8 and 6.9, as well as which features will be merged into mainline in Linux 6.10 and 6.11, and to be quite frank – it’s looking really solid, especially considering this is Qualcomm we’re talking about. Over the coming six months, they’re going to focus on getting end-to-end hardware video decoding working, including in Firefox and Chrome, as well as various CPU and GPU optimisations, adding the required firmware to the linux-firmware package, and providing access to easy installers.

All in all, it’s looking like the X Elite will be exceptionally well supported by Linux before the year’s over.

The blog post also details the boot path for Linux on the X Elite, and that, too, is looking good. It’s using a standard UEFI boot process, and supports GRUB and systemd-boot out of the box. Linux boots up using devicetrees, though, and apparently, there’s a known problem with using those that Qualcomm and the community are working on.

We’re working closely with upstream communities on an open problem with the UEFI-based BIOS while booting with devicetrees. The problem is that, when you have more than one devicetree blob (DTB) packed into the firmware package flashed on the device, there is no standard way of selecting a devicetree to pass on to the kernel. OEMs commonly put multiple DTBs into the firmware package so it will support devices with slightly different SKUs, so we’re keen to solve this problem.

↫ Qualcomm’s developer blog

I am pleasantly surprised by the openness and straightforwardness Qualcomm is showing the Linux community here, and I really hope this is a sign of how the company will keep supporting its laptop and possibly desktop-oriented SoCs from here on out. It seems like next year we will finally be getting competitive ARM laptops that can run Linux in a fully supported fashion.

In addition to Linux 6.10 expected to drop support for very old DEC Alpha processors (EV5 and earlier), it looks like the PowerPC 40x (early PowerPC 400 series) processor and platform support will be retired too.

Back in 2020 was a proposal for dropping PowerPC 40x support from the Linux kernel given that the code was orphaned for a long time with no apparent users. The PowerPC 40x processors were found in thin clients, set-top boxes, and other devices during the 90’s. Finally now it looks like that the PowerPC 40x removal is set to happen.

↫ Michael Larabel

Spring cleaning in the hardware support department. I wonder what has more users – Windows on ARM, or Linux on PowerPC 40x.

Lennart Poettering, main developer of systemd, has announced run0, a systemd-based replacement for the well-known sudo command that fixes many of he inherent issues with the widely used tool to gain temporary elevated privileges. There are various problems with sudo, which basically come down to that it’s a large SUID binary, meaning it consists of privileged code that unprivileged users can run from their own context. This makes sudo a fairly large attack surface, and why OpenBSD uses doas instead; while doas suffers from the same main problem, it’s much smaller and reduces the attack surface considerably.

SUID processes are weird concepts: they are invoked by unprivileged code and inherit the execution context intended and controlled by unprivileged code. By execution context I mean the myriad of properties that a process has on Linux these days, from environment variables, process scheduling properties, cgroup assignments, security contexts, file descriptors passed, and so on and so on. A few of these settings the kernel is nice enough to clean up automatically when a SUID binary is invoked, but much of it has to be cleaned up by the invoked suid binary. This has to be done very very carefully, and history has shown that SUID binaries are generally pretty shit at that.

↫ Lennart Poettering

Poettering wants to address this problem, and has come up with run0, which behaves like sudo, but works entirely differently and is not SUID. Run0 asks the services manager to create a shell or command under the target user’s ID, creating a new PTY, sending data back and forth from the originating TTY and the new PTY.

Or in other words: the target command is invoked in an isolated exec context, freshly forked off PID 1, without inheriting any context from the client (well, admittedly, we *do* propagate $TERM, but that’s an explicit exception, i.e. allowlist rather than denylist).

One could say, “run0” is closer to behaviour of “ssh” than to “sudo”, in many ways. Except that it doesn’t bother with encryption or cryptographic authentication, key management and stuff, but instead relies on the kernel’s local identification mechanisms.

run0 doesn’t implement a configuration language of its own btw (i.e. no equivalent of /etc/sudoers). Instead, it just uses polkit for that, i.e. how we these days usually let unpriv local clients authenticate against priv servers.

↫ Lennart Poettering

This approach addresses a whole slew of attack vectors on sudo, and it comes with fun additional features like being able to give your terminal a different background tint when using it, or displaying a little red dot in the terminal window title to further indicate you’re using elevated privileges. It will ship as part of the upcoming release of systemd 256.

In February last year I wrote about running a FreeBSD desktop, and concluded that sometimes you need to give yourself permission to tinker.

Well recently I’ve started tinkering with Alpine Linux! It’s been recommended to me for years, so I’m finally getting around to checking it out. There’s a lot to like if you come from BSD, which we’ll dig into here.

↫ Ruben Schade

Just a quick look at this unexpectedly popular Linux distribution that really has its own identity.