Keep OSNews alive by becoming a Patreon, by donating through Ko-Fi, or by buying merch!

Linux Archive

Porting systemd to musl libc-powered Linux

A. Wilcox, the original creator of Adélie Linux, has ported systemd to musl, the glibc alternative. I have completed an initial new port of systemd to musl. This patch set does not share much in common with the existing OpenEmbedded patchset. I wanted to make a fully updated patch series targeting more current releases of systemd and musl, taking advantage of the latest features and updates in both. I also took a focus on writing patches that could be sent for consideration of inclusion upstream. The final result is a system that appears to be surprisingly reliable considering the newness of the port, and very fast to boot. ↫ A. Wilcox I absolutely adore Adélie Linux as a project, even if I don’t run it myself, since they have a very practical approach to software. Systemd is popular for a reason – it’s fast and capable – and it only makes sense for Adélie to offer it as a potential option, even when using musl. Choice is a core value of the open source and Linux world, and that includes the choice to use systemd, even for a distribution that has traditionally used something else. The port is already quite capable, and Wilcox managed to replace OpenRC on her system with systemd in-place, and it booted up just fine, and it also happened to boot in about a third of the time OpenRC did. It’s not ready for prime time yet, though, and most services are not yet packaged for systemd, an effort for which Adélie Linux intends to rely on upstream and cooperation with systemd experts from Gentoo and Fedora. They’re also working together with systemd, musl, and others to make any switching a user might want to do as easy as possible. A beta or anything like that is still a ways off, but it’s an impressive amount of progress already.

Linux scores a surprising gaming victory against Windows 11

The conversation around gaming on Linux has changed significantly during the last several years. It’s a success story engineered by passionate developers working on the Linux kernel and the open-source graphics stack (and certainly bolstered by the Steam Deck). Many of them are employed by Valve and Red Hat. Many are enthusiasts volunteering their time to ensure Linux gaming continues to improve. Don’t worry, this isn’t going to be a history lesson, but it’s an appropriate way to introduce yet another performance victory Linux is claiming over Windows. I recently spent some time with the Framework 13 laptop, evaluating it with the new Intel Core Ultra 7 processor and the AMD Ryzen 7 7480U. It felt like the perfect opportunity to test how a handful of games ran on Windows 11 and Fedora 40. I was genuinely surprised by the results! ↫ Jason Evangelho I’m not surprised by these results. At all. I’ve been running exclusively Linux on my gaming PC for years now, and gaming has pretty much been a solved issue on Linux for a while now. I used to check ProtonDB before buying games on Steam without a native Linux version, but I haven’t done that in a long time, since stuff usually just works. In quite a few cases, we’ve even seen Windows games perform better on Linux through Proton than they do on Windows. An example that still makes me chuckle is that when Elden Ring was just released, it had consistent stutter issues on Windows that didn’t exist on Linux, because Valve’s Proton did a better job at caching textures. And now that the Steam Deck has been out for a while, people just expect Linux support from developers, and if it’s not there on launch, Steam reviews will reflect that. It’s been years since I bought a game that I’ve had to refund on Steam because it didn’t work properly on Linux. The one exception remains games that employ Windows rootkits for their anticheat functionality, such as League of Legends, which recently stopped working on Linux because the company behind the game added a rootkit to their anticheat tool. Those are definitely an exception, though, and honestly, you shouldn’t be running a rootkit on your computer anyway, Windows or not. For my League of Legends needs, I just grabbed some random spare parts and built a dedicated, throwaway Windows box that obviously has zero of my data on it, and pretty much just runs that one stupid game I’ve sadly been playing for like 14 years. We all have our guilty pleasures. Don’t kink-shame. Anyway, if only a few years ago you had told me or anyone else that gaming on Linux would be a non-story, a solved problem, and that most PC games just work on Linux without any issues, you’d be laughed out of the room. Times sure have changed due to the dedication and hard work of both the community and various companies like Valve.

So you want to build an embedded Linux system?

This article is targeted at embedded engineers who are familiar with microcontrollers but not with microprocessors or Linux, so I wanted to put together something with a quick primer on why you’d want to run embedded Linux, a broad overview of what’s involved in designing around application processors, and then a dive into some specific parts you should check out — and others you should avoid — for entry-level embedded Linux systems. ↫ Jay Carlson Quite the detailed guide about embedded Linux.

Override xdg-open behavior with xdg-override

Most application on GNU/Linux by convention delegate to xdg-open when they need to open a file or a URL. This ensures consistent behavior between applications and desktop environments: URLs are always opened in our preferred browser, images are always opened in the same preferred viewer. However, there are situations when this consistent behavior is not desired: for example, if we need to override default browser just for one application and only temporarily. This is where xdg-override helps: it replaces xdg-open with itself to alter the behavior without changing system settings. ↫ xdg-override GitHub page I love this project ever since I came across it a few days ago. Not because I need it – I really don’t – but because of the story behind its creation. The author of the tool, Dmytro Kostiuchenko, wanted Slack, which he only uses for work, to only open his work browser – which is a different browser from his default browser. For example, imagine you normally use Firefox for everything, but for all your work-related things, you use Chrome. So, when you open a link sent to you in Slack by a colleague, you want that specific link to open in Chrome. Well, this is not easily achieved in Linux. Applications on Linux tend to use freedesktop.org’s xdg-open for this, which looks at the file mimeapps.list to learn which application opens which file type or URL. To solve Kostiuchenko’s issue, changing the variable $XDG_CONFIG_HOME just for Slack to point xdg-open to a different configuration file doesn’t work, because the setting will be inherited by everything else spwaned from Slack itself. Changing mimeapps.list doesn’t work either, of course, since that would affect all other applications, too. So, what’s the actual solution? We’d like also not to change xdg-open implementation globally in our system: ideally, the change should only affect Slack, not all other apps. But foremost, diverging from upstream is very unpractical. However, in the spirit of this solution, we can introduce a proxy implementation of xdg-open, which we’ll “inject” into Slack by adding it to PATH. ↫ Dmytro Kostiuchenko xdg-override takes this idea and runs with it: It is based on the idea described above, but the script won’t generate proxy implementation. Instead, xdg-override will copy itself to /tmp/xdg-override-$USER/xdg-open and will set a few $XDG_OVERRIDE_* variables and the $PATH. When xdg-override is invoked from this new location as xdg-open, it’ll operate in a different mode, parsing $XDG_OVERRIDE_MATCH and dispatching the call appropriately. I tested this script briefly, but automated tests are missing, so expect some rough edges and bugs. ↫ Dmytro Kostiuchenko I don’t fully understand how it works, but I get the overall gist of what it’s doing. I think it’s quite clever, and solves a very specific issue in a non-destructive way. While it’s not something most people will ever need, it feels like something that if you do need it, it will quickly become a default part of your toolbox or workflow.

Serpent OS prealpha0 released

Serpent OS, a new Linux distribution with a completely custom package management system written in Rust, has released its very very rough pre-alpha release. They’ve been working on this for four years, and they’re making some interesting choices regarding packaging that I really like, at least on paper. This will of course appear to be a very rough (crap) prealpha ISO. Underneath the surface it is using the moss package manager, our very own package management solution written in Rust. Quite simply, every single transaction in moss generates a new filesystem tree (/usr) in a staging area as a full, stateless, OS transaction. When the package installs succeed, any transaction triggers are run in a private namespace (container) before finally activating the new /usr tree. Through our enforced stateless design, usr-merge, etc, we can atomically update the running OS with a single renameat2 call. As a neat aside, all OS content is deduplicated, meaning your last system transaction is still available on disk allowing offline rollbacks. ↫ Ikey Doherty Since this is only a very rough pre-alpha release, I don’t have much more to say at this point, but I do think it’s interesting enough to let y’all know about it. Even if you’re not the kind of person to dive into pre-alphas, I think you should keep an eye on Serpent OS, because I have a feeling they’re on to something valuable here.

NVIDIA transitions fully towards open-source GPU Linux kernel modules

It’s a bit of a Linux news day today – it happens – but this one is good news we can all be happy about. After earning a bad reputation for mishandling its Linux graphics drivers for years, almost decades, NVIDIA has been turning the ship around these past two years, and today they made a major announcement: from here on out, the open source NVIDIA kernel modules will be the default for all recent NVIDIA cards. We’re now at a point where transitioning fully to the open-source GPU kernel modules is the right move, and we’re making that change in the upcoming R560 driver release. ↫ Rob Armstrong, Kevin Mittman and Fred Oh There are some caveats regarding which generations, exactly, should be using the open source modules for optimal performance. For NVIDIA’s most cutting edge generations, Grace Hopper and Blackwell, you actually must use the open source modules, since the proprietary ones are not even supported. For GPUs from the Turing, Ampere, Ada Lovelace, or Hopper architectures, NVIDIA recommends the open source modules, but the proprietary ones are compatible as well. Anything older than that is restricted to the proprietary modules, as they’re not supported by the open source modules. This is a huge milestone, and NVIDIA becoming a better team player in the Linux world is a big deal for those of us with NVIDIA GPUs – it’s already paying dividend in vastly improved Wayland support, which up until very recently was a huge problem. Do note, though, that this only covers the kernel module; the userspace parts of the NVIDIA driver are still closed-source, and there’s no indication that’s going to change.

Linux patch to disable Snapdragon X Elite GPU by default

Not too long ago it seemed like Linux support for the new ARM laptops running the Snapdragon X Pro and Elite processors was going to be pretty good – Qualcomm seemed to really be stepping up its game, and detailed in a blog post exactly what they were doing to make Linux a first-tier operating system on their new, fancy laptop chips. Now that the devices are in people’s hand, though, it seems all is not so rosy in this new Qualcomm garden. A recent Linux kernel DeviceTree patch outright disables the GPU on the Snapdragon X Elite, and the issue is, as usual, vendor nonsense, as it needs something called a ZAP shader to be useful. The ZAP shader is needed as by default the GPU will power on in a specialized “secure” mode and needs to be zapped out of it. With OEM key signing of the GPU ZAP shader it sounds like the Snapdragon X laptop GPU support will be even messier than typically encountered for laptop graphics. ↫ Michael Larabel This is exactly the kind of nonsense you don’t want to be dealing with, whether you’re a user, developer, or OEM, so I hope this gets sorted out sooner rather than later. Qualcomm’s commitments and blog posts about ensuring Linux is a first-tier platform are meaningless if the company can’t even get the GPU to work properly. These enablement problems should’ve been handled well before the devices entered circulation, so this is very disheartening to see. So, for now, hold off on X Elite laptops if you’re a Linux user.

Unified kernel image

UKIs can run on UEFI systems and simplify the distribution of small kernel images. For example, they simplify network booting with iPXE. UKIs make rootfs and kernels composable, making it possible to derive a rootfs for multiple kernel versions with one file for each pair. A Unified Kernel Image (UKI) is a combination of a UEFI boot stub program, a Linux kernel image, an initramfs, and further resources in a single UEFI PE file (device tree, cpu µcode, splash screen, secure boot sig/key, …). This file can either be directly invoked by the UEFI firmware or through a boot loader. ↫ Hugues If you’re still a bit unfamiliar with unified kernel images, this post contains a ton of detailed practical information. Unified kernel images might become a staple for forward-looking Linux distributions, and I know for a fact that my distribution of choice, Fedora, has been working on it for a while now. The goal is to eventually simplify the boot process as a whole, and make better, more optimal use of the advanced capabilities UEFI gives us over the old, limited, 1980s BIOS model. Like I said a few posts ago, I really don’t want to be using traditional bootloaders anymore. UEFI is explicitly designed to just boot operating systems on its own, and modern PCs just don’t need bootloaders anymore. They’re points of failure users shouldn’t be dealing with anymore in 2024, and I’m glad to see the Linux world is seriously moving towards negating the need for their existence.

No more boot loader: please use the kernel instead

Most people are familiar with GRUB, a powerful, flexible, fully-featured bootloader that is used on multiple architectures (x86_64, aarch64, ppc64le OpenFirmware). Although GRUB is quite versatile and capable, its features create complexity that is difficult to maintain, and that both duplicate and lag behind the Linux kernel while also creating numerous security holes. On the other hand, the Linux kernel, which has a large developer base, benefits from fast feature development, quick responses to vulnerabilities and greater overall scrutiny. We (Red Hat boot loader engineering) will present our solution to this problem, which is to use the Linux kernel as its own bootloader. Loaded by the EFI stub on UEFI, and packed into a unified kernel image (UKI), the kernel, initramfs, and kernel command line, contain everything they need to reach the final boot target. All necessary drivers, filesystem support, and networking are already built in and code duplication is avoided. ↫ Marta Lewandowska I’m not a fan of GRUB. It’s too much of a single point of failure, and since I’m not going to be dual-booting anything anyway I’d much rather use something that isn’t as complex as GRUB. Systemd-boot is an option, but switching over from GRUB to systemd-boot, while possible on my distribution of choice, Fedora, is not officially supported and there’s no guarantee it will keep working from one release to the next. The proposed solution here seems like another option, and it may even be a better option – I’ll leave that to the experts to discuss. It seems like to me that the ideal we should be striving for is to have booting the operating system become the sole responsibility of the EUFI firmware, which usually already contains the ability to load any operating system that supports UEFI without explicitly installing a bootloader. It’d be great if you could set your UEFI firmware to just always load its boot menu, instead of hiding it behind a function key or whatever. We made UEFI more capable to address the various problems and limitations inherent in BIOS. Why are we still forcing UEFI to pretend it still has the same limitations?

Booting Linux off of Google Drive

On the brink of insanity, my tattered mind unable to comprehend the twisted interplay of millennia of arcane programmer-time and the ragged screech of madness, I reached into the Mass and steeled myself to the ground lest I be pulled in, and found my magnum opus. Booting Linux off of a Google Drive root. ↫ Ersei That’s not… You shouldn’t… Why would…

If your immutable Linux desktop uses Flatpak, I’m going to have a bad time

The openSUSE project recently announced the second release candidate (RC2) of its Aeon Desktop, formerly known as MicroOS Desktop GNOME. Aside from the new coat of naming paint, Aeon breaks ground in a few other ways by dabbling with technologies not found in other openSUSE releases. The goal for Aeon is to provide automated system updates using snapshots that can be applied atomically, removing the burden of system maintenance for “lazy developers” who want to focus on their work rather than desktop administration. System-tinkerers need not apply. The idea behind Aeon, as with other immutable (or image-based) Linux distributions, is to provide the core of the distribution as a read-only image or filesystem that is updated atomically and can be rolled back if needed. Google’s ChromeOS was the first popular Linux-based desktop operating system to follow this model. Since the release of ChromeOS a number of interesting immutable implementations have cropped up, such as Fedora Silverblue, Project Bluefin (covered here in December 2023), openSUSE’s MicroOS (covered here in March 2023), and Ubuntu Core. ↫ Joe Brockmeier at LWN With the amount of attention immutable Linux desktops are getting, and how much work and experimentation that’s going into them, I’m getting the feeling that sooner or later all of the major, popular desktop Linux distributions will be going this route. Depending on implementation details, I actually like the concept of a defined base system that’s just an image that can be replaced easily using btrfs snapshots or something like that, while all the user’s files and customisations are kept elsewhere. It makes intuitive sense. Where the current crop of immutable Linux desktops fall flat for me is their reliance on (usually) Flatpak. You know how there’s people who hate systemd and/or Wayland just a little too much, to the point it gets a little weird and worrying? That’s me whenever I have to deal with Flatpaks. Every experience I have with Flatpaks is riddled with trouble for me. Even though I’m a KDE user, I’m currently testing out the latest GNOME release on my workstation (the one that I used to conclude Windows is simply not ready for the desktop), using Fedora of course, and on GNOME I use the Mastodon application Tuba. While I mostly write in English, I do occasionally write in Dutch, too, and would love for the spell check feature to work in my native tongue, too, instead of just in English. However, despite having all possible Dutch dictionaries installed – hunspell, aspell – and despite those dictionaries being picked up everywhere else in GNOME, Tuba only showed me a long list of variants of English. After digging around to find out why this was happening, it took me far longer than I care to publicly admit to realise that since the latest version of Tuba is only really available as a Flatpak on Fedora, my problem probably had something to do with that – and it turns out I was right: Flatpak applications do not use the system-wide installed spellcheck dictionaries like normal applications do. This eventually led me to this article by Daniel Aleksandersen, where he details what you need to do in order to add spellcheck dictionaries to Flatpak applications. You need to run the following commands: The list of languages uses two-letter codes only, and the first language listed will serve as the display language for Flatpak applications, while the rest will be fallback languages – which happens to include downloading and installing the Flatpak-specific copies of the spellcheck libraries. Sadly, this method is not particularly granular. Since it only accepts the two-letter codes, you can’t, say, only install “nl-nl”; you’ll be getting “nl-be” as well. In the case of a widely spoken language like English, this means a massive list of 18 different varieties of English. The resulting menus are… Not elegant. This is just an example, but using Flatpak, you’ll run into all kinds of issues like this, that then have to be solved by hacks or obscure terminal commands – not exactly the user-friendly image Flatpak is trying to convey to the world. This particular issue might not matter to the probably overwhelming English-speaking majority of Flatpak developers, but for anyone who has to deal with multiple languages on a daily basis – which is a massive number of people, probably well over 50% of computer users – having to mess around with obscure terminal commands hidden in blog posts just to be able to use the languages they use every day is terrible design on a multitude of levels, and will outright make Flatpak applications unusable for large numbers of people. Whenever I run into these Flatpak problems, it makes it clear to me that Flatpak is designed not by users, for users – but by developers, for developers. I can totally understand and see why Flatpak is appealing to developers, but as a user, they bring me nothing but grief, issues, and weird bugs that all seem to stem from being made to make developers’ lives easier, instead of users’. If immutable Linux distributions are really hellbent on using Flatpak as the the means of application installation – and it seams like they are – it will mean a massive regression in functionality, usability, and discoverability for users, and as long as Flatpak remains as broken and badly designed as it is, I really see no reason to recommend an immutable Linux desktop to anyone but the really curious among us.

EasyOS: an experimental Linux distribution

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.

Can you blow a PC speaker with a Linux kernel module?

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.

Linus Torvalds: extensible scheduler “sched_ext” in Linux 6.11

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.

Void Linux on ZFS

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.

A BSD person tries Alpine Linux

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.

Why a ‘frozen’ distribution Linux kernel isn’t the safest choice for security

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.

Qualcomm details Linux on Snapdragon X Elite, and it’s looking surprisingly good

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.

PowerPC 40x processor support to be dropped from the Linux kernel

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.