Linux Archive
The team behind Tyr started 2025 with little to show in our quest to produce a Rust GPU driver for Arm Mali hardware, and by the end of the year, we were able to play SuperTuxKart (a 3D open-source racing game) at the Linux Plumbers Conference (LPC). Our prototype was a joint effort between Arm, Collabora, and Google; it ran well for the duration of the event, and the performance was more than adequate for players. Thankfully, we picked up steam at precisely the right moment: Dave Airlie just announced in the Maintainers Summit that the DRM subsystem is only “about a year away” from disallowing new drivers written in C and requiring the use of Rust. Now it is time to lay out a possible roadmap for 2026 in order to upstream all of this work. ↫ Daniel Almeida at LWN.net A very detailed look at what the team behind Tyr is trying to achieve with their Rust GPU driver for Arm Mali chips.
We talked about Nemin’s first impressions of the Guix System as someone coming from a Nix environment, but today they’ve got a follow-up article diving into the experience of creating new packages for Guix. I spent about a week packaging WezTerm and learning the ropes of being a Guix contributor along the way. During the packaging process I stumble many times, only to stand back up and figure out a solution. I also explain some of my complaints about the peculiarities of the process, but also provide plenty of praise about of how much the system tries to enable you to do your job. Finally, I also touch on how positive the experience of the code review was. ↫ Nemin’s blog These are the kinds of content a rather niche system like Guix needs. Guix isn’t exactly one of the popular picks out there, so having level-headed, honest, but well-written introductions to its core concepts and user experience, written by a third party is going to do wonders for people interested in trying it out.
But NixOS isn’t the only declarative distro out there. In fact GNU forked Nix fairly early and made their own spin called Guix, whose big innovation is that, instead of using the unwieldy Nix-language, it uses Scheme. Specifically Guile Scheme, GNU’s sanctioned configuration language. I’ve been following Guix for a bit, but it never felt quite ready to me with stuff like KDE being only barely supported and a lot of hardware not working out of the box. However, now that (after three years) Guix announced its 1.5.0 release with a lot of stuff stabilized and KDE finally a first-party citizen, I figured now is the best time to give it a fresh shot. This post captures my experiences from installation to the first 3-4 days. ↫ Nemin’s blog If you’re interested in Guix, but aren’t quite sure if you want to take the plunge, this article does a great job of showing you the ropes, listing what issues you might run into, some pitfalls to avoid, and so on.
I’ve been terribly sick for a few days so we’ve got some catching up to. Let’s first take a look at how Windows is doing. People often say Linux is “too much work.” And I agree. They’re completely justified to complain. There’s the documentation page diving, the forums, the reddit threads. And, most importantly, you have to basically rewire your brain and stop expecting it to behave like Windows used to. But I looked at the list above and realized: Windows is now also too much work. And the difference with Windows is that you’re going to do all that work while actively fighting your computer only for it to be undone when the next surprise update comes and ruins everything. You might be thinking “just disable updates, man” or “just install LTSC”, or “just run some random debloat script off of GitHub”. Why? Why would I jump through all these hoops? I’d rather put in the effort for an OS that knows what consent is and respects me as a user. ↫ Bogdan-Mihai Mosteanu You know how in most theme parks they have various different rides for all kinds of people? There’s the wild and crazy over-the-top deathcoasters for the ultimate thrill seekers, the more gentle wooden coasters for those who like a thrill, but not over-the-top. There’s the swinging ship-type things for thrill-seeking accountants who seek their thrills predictably. There’s a game of Russian roulette played in the backlot. For the kids, there’s the classic spinning tea cups. And then there’s the public transport service dressed up as an old-timey steam train that just brings you to your destination without any issue, silently doing its thing, the unsung backbone of park logistics. Commercial operating systems like Windows and macOS are the games of Russian roulette, predictably unexpectedly shooting you in the face every sixth time you pull the trigger. That’s not my vibe. I want my operating system to be that steam train, and desktop Linux is the only thing that fits that bill – and it’s very clear more and more people are discovering that too.
Your mission, should you choose to accept it, is to sneak into the earliest parts of the boot process, swap the startup config without breaking anything, and leave without a trace. Are you ready? Let’s begin. ↫ Jynn Nelson Genius.
The solution the Flatpak team is looking into is to use virtualisation for the graphics driver, as the absolute last-resort option to keep things working when nothing else will. It’s a complex and interesting solution to a complex and interesting problem.
Desktop Classic System is an operating system based on Debian and a customized version of the MATE Desktop Environment that hearkens back to, but is not a direct copy of, the classic Mac OS. DCS seeks to provide and sometimes even improve upon the conceptual simplicity offered by the old Macintosh. ↫ Desktop Classic System website I’m usually not particularly interested in reporting on random Linux distributions, but any one of them that defaults to a proper spatial file manager is one that I will highlight. I’m not entirely sure if this is just a supported feature of MATE’s file manager, or something more custom – there are some patches to Caja here, as mentioned – but spatial file managers are a dying breed and that’s a shame. They’re hard to implement and even harder to get right, which is probably why few people take on the challenge. Other than that, DCS isn’t particularly revolutionary or special, but I’d love for more Linux distributions to look back at what we’ve lost, and see if we can bring those things back.
I’d just like to interject for a moment. What you’re refering to as Linux, is in fact, Win32/Linux, or as I’ve recently taken to calling it, loss32 Win32 plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning system made useful by WINE, the ReactOS userland, and other vital system components comprising a full OS as defined by Microsoft. ↫ The loss32 homepage Joking introduction aside, this is exactly what you think it is: a Linux kernel with the Windows user interface running on top through Wine. I’m sure quite a few of use mused about this very concept at some point in time, but hikari_no_yume went a step further and created this working concept. It’s rough around the edges and needs a ton of work, but I do think the idea is sound and could offer real benefits for certain types of users. It’s definitely a more realistic idea than ReactOS, a project that’s perpetually chasing the dragon but never coming even close to catching it. Not having to recreate the entire Windows NT kernel, drivers, and subsystems, and using Linux instead, is simply a more realistic approach that could bring results within our lifetimes. The added benefit here is that this could still run Linux applications, too, of course. hikari_no_yume is looking for help with the project, and I hope they find it. This is a great idea, with an absolutely amazing name, too.
Elementary OS, the user-friendly Linux distribution with its own unique desktop environment and applications, just released elementary OS 8.1. Its minor version number belies just how big of a punch this update packs, so don’t be fooled here. We released elementary OS 8 last November with a new Secure Session—powered by Wayland—that ensures applications respect your privacy and consent, a brand new Dock with productive multitasking and window management features, expanded access to cross-platform apps, a revamped updates experience, and new features and settings that empower our diverse community through Inclusive Design. Over the last year we’ve continued to build upon that work to deliver new features and fix issues based on your feedback, plus we’ve improved support for a range of devices including HiDPI and Multi-touch devices. ↫ Danielle Foré at the elementary OS blog The biggest change from a lower-level perspective is that elementary OS 8.1 changes the default session to Wayland, leaving the X11 session as a fallback in case of issues. Since the release of elementary OS 8, a ton of progress has been made in improving the Wayland session, fixing remaining issues, and so on, and the team now feels it’s ready to serve as the default session. Related to this is a new security feature in the Wayland session where the rest of the screen gets dimmed when a password dialog pops up, and other windows can’t steal focus. The switch to Wayland also allowed the team to bring fractional scaling to elementary OS with 8.1. Elementary OS is based on Ubuntu, and this new release brings an updated Hardware Enablement stack, which brings things like Linux 6.14 and Mesa 25. This is also the first release with support for ARM64 devices that can use UEFI, which includes quite a few popular ARM devices. Of course, the ARM64 version comes as a separate ISO. Furthermore, there’s a ton of improvements to the dock – which was released with 8 as a brand-new replacement for the venerable Plank – including bringing back some features that were lost in the transition from Plank to the new dock. Animations are smoother, elementary OS’ application store has seen a slew of improvements from clearer licensing information, to a controller icon for games that support them, to a label identifying applications that offer in-app purchases, and more. There’s a lot more here, like the accessibility improvements we talked about a few months ago, and tons more.
If you’re old enough, you no doubt remember that up until the 2.6.0 release of the Linux kernel, an odd number after the first version number indicated a pre-release, development version of the kernel. Even though this scheme was abandoned with the 2.6.0 release in 2003 and since then every single release has been a stable release, it seems the ghosts of this old versioning scheme still roam the halls, because prominent Linux kernel developer Greg Kroah-Hartman just published an explainer about Linux kernel versions. Despite having a stable release model and cadence since December 2003, Linux kernel version numbers seem to baffle and confuse those that run across them, causing numerous groups to mistakenly make versioning statements that are flat out false. So let’s go into how this all works in detail. ↫ Greg Kroah-Hartman I genuinely find it difficult to imagine what could possibly be unclear about Linux kernel version numbers. The Linux kernel uses a very generic major.minor scheme, but that’s not where the problems lie – it’s the actual development process of each of these numbered release that’s a bit more complex. This is where we have to talk about things like the roughly 10-week release cycle, containing a 2-week merge window, as well as Torvalds handing off the stable branch to the stable kernel maintainers. The other oddity is when the major version number gets incremented – the first number in the version number. There’s no real method to this, as Kroah-Hartman admits Torvalds increments this number whenever the remaining numbers get too high and unwieldy to deal with. Very practical, but it does mean that going from, say, 5.x to 6.x doesn’t really imply there’s any changes in there that are any bigger or more disruptive than when going from 6.8.x to 6.9.x or whatever. There’s a few more important details in here, of course, like where LTS releases come from, but that’s really it – nothing particularly groundbreaking or confusing.
Landlock is a Linux API that lets applications explicitly declare which resources they are allowed to access. Its philosophy is similar to OpenBSD’s unveil() and (less so) pledge(): programs can make a contract with the kernel stating, “I only need these files or resources — deny me everything else if I’m compromised.” It provides a simple, developer-friendly way to add defense-in-depth to applications. Compared to traditional Linux security mechanisms, Landlock is vastly easier to understand and integrate. This post is meant to be an accessible introduction, and hopefully persuade you to give Landlock a try. ↫ prizrak.me blog I had no idea this existed, even though it seems to plug a hole in the security and sandboxing landscape on Linux by not requiring any privileges and by being relatively simple and straightforward to use. There’s even an additional “supervisor” proposal that would bring Android-like permissions not just to, say, desktop applications (see Flatpak), but to every process trying to access anything for the first time. I’m not knowledgeable enough to make any statements about Landlock compared to any other options we have for securing desktop Linux in a user-friendly, non-intrusive manner, but I definitely like its simplicity.
For the past 18 months, the Linux OEM Tuxedo Computers has been working on bringing a Snapdragon X Elite ARM laptop to market, but now they cancelled the project due to complications. Development turned out to be challenging due to the different architecture, and in the end, the first-generation X1E proved to be less suitable for Linux than expected. In particular, the long battery runtimes—usually one of the strong arguments for ARM devices—were not achieved under Linux. A viable approach for BIOS updates under Linux is also missing at this stage, as is fan control. Virtualization with KVM is not foreseeable on our model, nor are the high USB4 transfer rates. Video hardware decoding is technically possible, but most applications lack the necessary support. Given these conditions, investing several more months of development time does not seem sensible, as it is not foreseeable that all the features you can rightfully expect would be available in the end. In addition, we would be offering you a device with what would then be a more than two-year-old Snapdragon X Elite (X1E), whose successor, the Snapdragon X2 Elite (X2E), was officially introduced in September 2025 and is expected to become available in the first half of 2026. ↫ Tuxedo’s announcement Back when Qualcomm was hyping up these processors, the company made big claims about supporting Linux equally to Windows, but those promises have turned out to be absolutely worthless. Tuxedo already highlighted the problems it was dealing with half a year ago, and now it seems these problems have become impossible to overcome – at least for now. This is a shame, bu also not entirely unexpected, since there’s no way a small Linux OEM can do the work that Qualcomm promised it would do for its own chip. All this sadly means we still don’t really have proper Linux support for modern ARM laptops, which is a crying shame. The problem isn’t so much Linux itself, but the non-standardised world of ARM hardware. Large OEMs are willing to do the work to make Windows work, but despite recent successes, desktop Linux is nowhere near as popular as Windows, so there’s little incentive for OEMs (or Qualcomm) to step up their game. It is what it is.
You press the power button. A second later a wall of text scrolls by, or a logo fades in, and eventually Linux appears. What happens in between is not magic. It is a careful handshake between tiny programs and a very literal CPU. This part follows that handshake until the very first line of C code inside the Linux kernel runs. ↫ 0xkato’s blog Exactly what it says on the tin.
What if you have a PC-98 machine, and you want to run Linux on it, as you do? I mean, CP/M, OS/2, or Windows (2000 and older) might not cut it for you, after all. Well, it turns out that yes, you can run Linux on PC-98 hardware, and thanks to a bunch of work by Nina Kalinina – yes, the same person from a few days ago – there’s now more information gathered in a single place to get you started. Plamo Linux is one of the few Linux distributions to support PC-98 series. Plamo 3.x is the latest distribution that can be installed on PC-9801 and PC-9821 directly. Unfortunately, it is quite old, and is missing lots of useful stuff. This repo is to share a-ha moments and binaries for Plamo on PC-98. ↫ Plamo98 goodies The repository details “upgrading” – it’s a bit more involved than plain upgrading, but it’s not hard – Plamo Linux from 3.x to 4, which gives you access to a bunch of things you might want, like GCC 3.3 over 2.95, KDE 3.x, Python 2.3, and more. There’s also custom BusyBox config files, a newer version of make, and a few other goodies and tools you might want to have. Once it’s all set and done, you can Linux like it’s 2003 on your PC-98. The number of people to whom this is relevant must be extraorinarily small, but at some point, someone is going to want to do this, only to find this repository of existing work. We’ve all been there.
A very exciting set of kernel patches have just been proposed for the Linux kernel, adding multikernel support to Linux. This patch series introduces multikernel architecture support, enabling multiple independent kernel instances to coexist and communicate on a single physical machine. Each kernel instance can run on dedicated CPU cores while sharing the underlying hardware resources. ↫ Cong Wang on the LKML The idea is that you can run multiple instances of the Linux kernel on different CPU cores using kexec, with a dedicated IPI framework taking care of communication between these kernels. The benefits for fault isolation and security is obvious, and it supposedly uses less resources than running virtual machines through kvm and similar technologies. The main feature I’m interested in is that this would potentially allow for “kernel handover”, in which the system goes from using one kernel to the other. I wonder if this would make it possible to implement a system similar to what Android currently uses for updates, where new versions are installed alongside the one you’re running right now, with the system switching over to the new version upon reboot. If you could do something similar with this technology without even having to reboot, that would be quite amazing and a massive improvement to the update experience. It’s obviously just a proposal for now, and there will be much, much discussion to follow I’m sure, but the possibilities are definitely exciting.
As if Francesco P. Lovergine heard my prayers, he wrote an article detailing his experiences with using Guix. Considering he’s a longtime Debian developer, we’re looking at someone who knows a thing or two about Linux. In the last few months, I have installed and upgraded my second preferred GNU/Linux system, GNU Guix, on multiple boxes. Regarding that system, I have already written a few introductory posts in the recent past. This is an update about my experiences as a user and developer. I still think Guix is a giant step forward in packaging and management, in comparison with Debian and other distributions, for elegance and inner coherence. ↫ Francesco P. Lovergine Lovergine found some problems with Guix, most notably those stemming from a lack of manpower. It’s not a hugely popular package management system and associated distribution, so the team of developers behind it is relatively small, and this leads to issues like outdated packages, problems arising from updates, and possible security issues. There’s no specific security team, for instance, but at least it’s easy to roll back updates due to the nature of Guix. Another problem, partially related to the lack of manpower, stems from the fact that the GNU Guix System uses some unusual systems, most notably GNU Shepard. This init system is an alternative to the widely-used systemd, alongside other alternatives like runit (which I use through Void Linux), but due to its relative lack of popularity, it can take some time for more complex packages to be made compatible with it. Especially some packages – like GNOME – that depend more and more on systemd are going to lag behind on Guix. For anyone with decent Linux experience and a willingness to tinker, I don’t think any of these issues – and the others Lovergine mentions – are dealbreakers. Sure, you might not want to deploy the GNU Guix System on a production system or anything that requires solid, strong security, but for personal and enthusiast use it seems like an interesting and somewhat unorthodox Linux distribution.
DistroWatch’s Jesse Smith is bringing some attention to an issue I have never encountered and had never heard of, and it has to do with antivirus software on Windows. It seems it’s not uncommon for antivirus software on Windows to mark Linux ISOs as malware or otherwise dangerous, and it seems people are reporting these findings to DistroWatch, for some reason. DistroWatch makes it clear they don’t host any of the ISOs, and that close to all of these warnings from antivirus software are false positives. So why do multiple Windows virus scanners report that they find malware in Linux downloads? Putting aside the obvious conspiracy theories about anti-virus vendors not wanting to lose customers, what is probably happening is the scanners are detecting an archive file (the ISO) which contains executable code, and flagging it as suspicious. Some of the code is even able to change the disk layout, which is something that looks nasty from a security point of view. It’s entirely understandable that a malware scanner which sees an archive full of executable code that could change the way the system boots would flag it as dangerous. ↫ Jesse Smith at DistroWatch I wonder how many people curious about Linux downloaded an ISO, only to delete is after their Windows antivirus marked it as dangerous. I can’t imagine the number to be particularly high – if you’re downloading a Linux ISO, you’re probably knowledgeable enough to figure out it’s a false positive – but apparently it’s a big enough issue that DistroWatch needs to inform its readers about it, which is absolutely wild to me.
I stumbled upon an LWN.net article from 2023, in which Lars Wirzenius, a long-time Debian developer and friend of Linus Torvalds, recalls the very early days of Linux – in fact, before it was even called Linux. There’s so many fun little stories in here, like how the Linux kernel started out as a multitasking demo written in x86 assembly, which did nothing more than write As and Bs on the screen, or the fact Linux was originally called Freax before Ari Lemmke, one of the administrators of ftp.funet.fi, opted for the name “Linux” when uploading the first release. However, my favourite story is about what installing Linux was like during those early days. During this time, people were interested in trying out this new thing, so Linus needed to provide an installation method and instructions. Since he only had one PC, he came to visit to install it on mine. Since his computer had been used to develop Linux, which had simply grown on top of his Minix installation, it had never actually been installed before. Thus, mine was the first PC where Linux was ever installed. While this was happening, I was taking a nap, and I recommend this method of installing Linux: napping, while Linus does the hard work. ↫ Lars Wirzenius at LWN.net The entire article is a joy to read, and since it’s from 2023, I’m sure I’m late to the party and none of it is news to many of you. On a more topical note, Wirzenius published a short article today detailing why he still uses Debian, after all these decades.
While Nix and NixOS get all the attention when it comes to declarative package management, there are other, competing implementations of the same general idea. Guix, developed as part of the GNU Project, was originally based on Nix, but grew into its own thing. The project recently announced a major change to how it packages Rust and its countless dependencies and optional ‘crates’. We have changed to a simplified Rust packaging model that is easier to automate and allows for modification, replacement and deletion of dependencies at the same time. The new model will significantly reduce our Rust packaging time and will help us to improve both package availability and quality. ↫ Hilton Chain at the Guix blog I hear people talk about Nix and NixOS all the time – I tried it myself, too, but I felt I was using an IBM z17 mainframe to watch a YouTube video – and in fact, Nix has kind of become a meme in and of itself, but you never hear people talk about Guix. With this being OSNews, I’m assuming there’s going to be people here using it, and I’m incredibly curious about your experiences. What are the features and benefits that make you use it? If you’re curious – the best way to try Guix is probably to install the GNU Guix System, the Linux distribution built around Guix and Shepard, GNU’s alternative init system. It’s available for i686, x86_64, ARMv7, and AArch64, and can be virtualised too, of course.
If you have spent any time around HID devices under Linux (for example if you are an avid mouse, touchpad or keyboard user) then you may have noticed that your single physical device actually shows up as multiple device nodes (for free! and nothing happens for free these days!). If you haven’t noticed this, run libinput record and you may be part of the lucky roughly 50% who get free extra event nodes. ↫ Peter Hutterer I’ve honestly always wondered about this, since some of my laptops shows both a trackpad and a mouse configuration panel even when there’s no mouse plugged in. Thanks to this article, I now know why this happens.
