Linux Archive

Ah, the Common Hardware Reference Platform, IBM’s and Apple’s ill-fated attempt at taking on the PC market with a reference PowerPC platform anybody could build and expand upon while remaining (mostly) compatible with one another. Sadly, like so many other things Apple was trying to do before Steve Jobs returned, it never took off, and even Apple itself never implemented CHRP in any meaningful way. Only a few random IBM and Motorola computers ever fully implemented it, and Apple didn’t get any further than basic CHRP support in Mac OS 8, and some PowerPC Macs were based on CHRP, without actually being compatible with it. We’re roughly three decades down the line now, and pretty much everyone except weird nerds like us have forgotten CHRP was ever even a thing, but Linux has continued to support CHRP all this time. This support, too, though, is coming to an end, as Michael Ellerman has informed the Linux kernel community that they’re thinking of getting rid of it. Only a very small number of machines are supported by CHRP in Linux: the IBM B50, bplan/Genesi’s Pegasos/Pegasos2 boards, the Total Impact briQ, and maybe some Motorola machines, and that’s it. Ellerman notes that these machines seem to have zero active users, and anyone wanting to bring CHRP support back can always go back in the git history. CHRP is one of the many, many footnotes in computing history, and with so few machines out there that supported it, and so few machines Linux’ CHRP support could even be used for, it makes perfect sense to remove this from the kernel, while obviously keeping it in git’s history in case anyone wants to work with it on their hardware in the future. Still, it’s always fun to see references to such old, obscure hardware and platforms in 2024, even if it’s technically sad news.

Version 6.12 of the Linux kernel has been released. The main feature consists of the merger of the real-time PREEMPT_RT scheduler, most likely one of the longest-running merger sagas in Linux’ history. This means that Linux now fully supports both soft and hard real-time capabilities natively, which is a major step forward for the platform, especially when looking at embedded development. It’s now no longer needed to draw in real-time support from outside the kernel. Linux 6.12 also brings a huge number of improvements for graphics drivers, for both Intel and AMD’s graphics cards. With 6.12, Linux now supports the Intel Xe2 integrated GPU as well as Intel’s upcoming discrete “Battlemage” GPUs by default, and it contains more AMD RDNA4 support for those upcoming GPUs. DRM panics messages in 6.12 will show a QR code you can scan for more information, a feature written in Rust, and initial support for the Raspberry Pi 5 finally hit mainline too. Of course, there’s a lot more in here, like the usual LoongArch and ARM improvements, new drivers, and so on. and if you’re a regular Linux user you’ll see 6.12 make it to your distribution within a few weeks or months.

Torvalds said that the current state of AI technology is 90 percent marketing and 10 percent factual reality. The developer, who won Finland’s Millennium Technology Prize for the creation of the Linux kernel, was interviewed during the Open Source Summit held in Vienna, where he had the chance to talk about both the open-source world and the latest technology trends. ↫ Alfonso Maruccia at Techspot Well, he’s not wrong. “AI” definitely feels like a bubble at the moment, and while there’s probably eventually going to be useful implementations people might actually want to actively use to produce quality content, most “AI” features today produce a stream of obviously fake diarrhea full of malformed hands, lies, and misinformation. Maybe we’ll eventually work out these serious kinks, but for now, it’s mostly just a gimmick providing us with an endless source of memes. Which is fun, but not exactly what we’re being sold, and not something worth destroying the planet for even faster. Meanwhile, Google is going utterly bananas with its use of “AI” inside the company, with Sundar Pichai claiming 25% of code inside Google is now “AI”-generated. ↫ Sundar Pichai We’re also using AI internally to improve our coding processes, which is boosting productivity and efficiency. Today, more than a quarter of all new code at Google is generated by AI, then reviewed and accepted by engineers. This helps our engineers do more and move faster. So much here feels wrong. First, who wants to bet those engineers care a whole lot less about the generated code than they do about code they write themselves? Second, who wants to bet that generated code is entirely undocumented? Third, who wants to bet what the additional costs will be a few years from now when the next batch of engineers tries to make sense of that undocumented generated code? Sure, Google might save a bit on engineers’ salaries now, but how much extra will they have to spend to unspaghettify that diarrhea code in the future? It will be very interesting to keep an eye on this, and check back in, say, five years, and hear from the Google engineers of the future how much of their time is spent fixing undocumented “AI”-generated code. I can’t wait.

If you love exploit mitigations, you may have heard of a new system call named mseal landing into the Linux kernel’s 6.10 release, providing a protection called “memory sealing.” Beyond notes from the authors, very little information about this mitigation exists. In this blog post, we’ll explain what this syscall is, including how it’s different from prior memory protection schemes and how it works in the kernel to protect virtual memory. We’ll also describe the particular exploit scenarios that mseal helps stop in Linux userspace, such as stopping malicious permissions tampering and preventing memory unmapping attacks. ↫ Alan Cao The goal of mseal is to, well, literally seal a part of memory and protect its contents from being tampered with. It makes regions of memory immutable so that while a program is running, its memory contents cannot be modified by malicious actors. This article goes into great detail about this new feature, explains how it works, and what it means for security in the Linux kernel. Excellent light reading for the weekend.

Can you run Linux on the Intel 4004, the first commercially produced microprocessor, released to the world in 1971? Well, Dmitry Grinberg, the genius engineer who got Linux to run on all kinds of incredibly underpowered hardware, sought to answer this very important question. In short, yes, you can run Linux on the 4004, but much as with other extremely limited and barebones chips, you have to get… Creative. Very creative. Of course, Linux cannot and will not boot on a 4004 directly. There is no C compiler targeting the 4004, nor could one be created due to the limitations of the architecture. The amount of ROM and RAM that is addressable is also simply too low. So, same as before, I would have to resort to emulation. My initial goal was to fit into 4KB of code, as that is what an unmodified unassisted 4004 can address. 4KB of code is not much at all to emulate a complete system. After studying the options, it became clear that MIPS R3000 would be the winner here. Every other architecture I considered would be harder to emulate in some way. Some architectures had arbitrarily-shifted operands all the time (ARM), some have shitty addressing modes necessitating that they would be slow (RISCV), some would need more than 4KB to even decode instructions (x86), and some were just too complex to emulate in so little space (PPC). … so … MIPS again… OK! ↫ Dmitry Grinberg This is just one very small aspect of this massive undertaking, and the article and videos accompanying his success are incredibly detailed and definitely not for the faint of heart. The amount of skill, knowledge, creativity, and persistence on display here is stunning, and many of us can only dream of being able to do stuff like this. I absolutely love it. Of course, the Linux kernel had to be slimmed down considerably, as a lot of stuff currently in the kernel are of absolutely no use on such an old system. Boot time is measured in days, still, but it helped a lot. Grinberg also turned the whole setup into what is effectively an art piece you can hang on the wall, where you can have it run and, well, do things – not much, of course, but he did include a small program that draws mandelbrot set on the VFD and serial port, which is a neat trick. He plans on offering the whole thing as a kit, but a lot of it depends on getting enough of the old chips to offer a complete, ready-to-assemble kit in the first place.

Linus Torvalds just tagged the Linux 6.11 kernel as stable. There are many changes and new features in Linux 6.11 including numerous AMD CPU and GPU improvements, preparations for upcoming Intel platforms, initial block atomic write support for NVMe and SCSI drives, the DRM Panic infrastructure can now display a monochrome logo if desired, easier support for building Pacman kernel packages for Arch Linux, DeviceTree files for initial Snapdragon X1 laptops, and much more. ↫ Michael Larabel Especially the Snapdragon stuff interests me, as I really want to move to ARM for my laptop needs at some point, and I’m obviously not going to be using Windows or macOS. I hope the bringup for the Snapdragon laptop chips is smooth sailing from here and picks up pace, because I’d hate for Linux to miss out on this transition. Qualcomm talked big game about supporting Linux properly, but it feels like they’re – what a surprise – not backing those words up with actions so far.

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.

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.

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, 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.

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.

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.

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…

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.