Linux Archive

What do Linux kernel version numbers mean?

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-ing Linux

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.

Tuxedo cancels Snapdragon X Elite Linux laptop project

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.

The Linux boot process: from power button to kernel

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.

Installing Linux on a PC-98 machine

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.

Multikernel architecture proposed for Linux

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.

The GNU Guix System’s lack of manpower problems

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.

Apparently, Windows antivirus marking Linux ISOs as malware is a common issue

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.

The first computer Linux was ever installed on

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.

Guix gets a new Rust packaging model

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.

Why is my device a touchpad and a mouse and a keyboard?

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.

Various desktop Linux tips for newcomers

We removed ads from OSNews. Donate to our fundraiser to ensure our future! It’s weekend, you might be visiting friends or relatives, and perhaps some of them are curious about switching away from Windows or macOS to Linux. There’s countless guides out there about this very topic, but to help you along a bit and cut through the avalanche of “AI” and SEO slop, here’s a true beginners’ guide to desktop Linux written by KDE developer Akseli Lahtinen, second most famous developer out of Finland after Linus Torvalds. There has been quite a surge in interest towards desktop Linux lately. The userbase, atleast according to some metrics, seems to be climbing. I realised today that it’s been 4 years for me since I did the switch. I have gathered some know-how that maybe a complete newbie could find useful. I also try to untangle some jargon I’ve learned: It may not be exactly technically correct, but this is meant for a more regular user anyway. ↫ Akseli Lahtinen This won’t be particularly interesting for most people who read a site like OSNews, but it’s a great roundup for newcomers in your circle.

Writing a Rust GPU kernel driver: a brief introduction on how GPU drivers work

As promised in the first iteration, we will now explore how GPU drivers work in more detail by exploring an application known as VkCube. As the program name implies, this application uses the Vulkan API to render a rotating cube on the screen. Its simplicity makes it a prime candidate to be used as a learning aid in our journey through GPU drivers. This article will first introduce the concept of User Mode Drivers (UMDs) and Kernel Mode Drivers (KMDs), breaking down the steps needed to actually describe VkCube‘s workload to the GPU. This will be done in a more compact way for brevity as it’s a rather extensive topic that has been detailed in several books. We will wrap up with an overview of the actual API offered by Tyr. As previously stated, this is the same API offered by Panthor, which is the C driver for the same hardware. ↫ Daniel Almeida There isn’t much to add here, except maybe this kitten.

Introduction to Qubes OS when you do not know what it is

Solène Rapenne, who writes a lot about and contributes to operating systems like OpenBSD and Qubes OS, has published a primer about what, exactly, Qubes OS is. I like to call Qubes OS a meta operating system, because it is not a Linux / BSD / Windows based OS: its core is Xen (some kind of virtualization enabled kernel). Not only it’s Xen based, but by design it is meant to run virtual machines, hence the name “meta operating system” which is an OS meant to run many OSes make sense to me. ↫ Solène Rapenne Rapenne explains the various ways in which isolated virtual machines are used in Qubes OS, and it’s easy to see just how secure Qubes OS’ way of doing things is. At the same time, it seems quite cumbersome to me as a regular user, and I don’t think I’m up for dealing with all of that. If you do security research, handle private or classified data, are a whistleblower or an investigative journalist, thoug, Qubes seems like a natural choice. Interesting to note is that Rapenne used to use OpenBSD for her security work, but moved to Qubes OS because its virtual machine infrastructure is far more robust, and hardware support is better, as well.

Why RISC-V Linux needs everyone upstream

RISC-V has been supported in the upstream Linux kernel since 2017. But without a common hardware baseline, ensuring compatibility across builds and distros hasn’t been easy. The ecosystem was in need of a compelling, clearly defined hardware target – something both software and hardware teams could rally around to produce silicon capable of running stable, enterprise-grade software. This target arrived in October 2024 with the ratification of the application-class RVA23 Profile – RISC-V-speak for a baseline configuration, similar to microarchitecture feature levels in x86. The culmination of years of progress, RVA23 brings together the work done to shape the ISA and standardize key extensions such as vector, bit manipulation and hypervisor. ↫ James De Vile at RISC-V International’s blog Such a standard, stable baseline is incredibly welcome, and RISC-V working to have everything part of the upstream Linux kernel is crucial. Having to deal with out-of-tree patches and drivers and specific builds for specific boards is a nightmare – look at Linux on ARM – and hinders adoption of RISC-V.

Linux 6.16 released

This release includes some Ext4 performance improvements; XFS support for large atomic writes; support for USB audio offload; support for zero-copy send TCP payloads from DMABUF memory; various futex improvements; initial support for Intel Trusted Domain Extensions; automatic weighted interleaved memory allocation policy; support for sending coredumps over an AF_UNIX socket, and make easier to build your kernel optimized for your local CPU. As always, there are many other features, new drivers, improvements and fixes. ↫ KernelNewbies: Linux 6.16 You’ll get it eventually, usually when the first few point releases iron out any troubling issues.

Systemd has been a complete, utter, unmitigated success

The year is 2013 and I am hopping mad. systemd is replacing my plaintext logs with a binary format and pumping steroids into init and it is laughing at me. The unix philosophy cries out: is this the end of Linux (or, as many are calling it, GNU plus Linux)? The year is 2025 and I’m here to repent. Not only is systemd a worthy successor to traditional init, but I think that it deserves a defense for what it’s done for the landscape – especially given the hostile reception it initially received (and somehow continues to receive? for some reason?). No software is perfect – except for TempleOS – but I think that systemd has largely been a success story and proven many dire forecasts wrong (including my own). I was wrong! ↫ Tyler Langlois The article goes into detail on a number of awesome features, niceties, and clever things systemd has, and they’re legion. Even as a mere user, I like systemd, as every time I have had to or wanted to interact with it, it’s been a joy to use, with excellent documentation making it remarkably easy even for someone like me to get into it without doing any damage or breaking anything. Every time I read up on system’d more advanced features, I’m surprised by how well thought out and implemented it all seems to be. I’ve experienced several major leaps forward in the Linux world that made using Linux on my computers easier and more reliable, and the adoption of systemd stands among them as one of the biggest leaps forward desktop Linux has ever made. The idea of going back to a random piles of non-standardized init scripts with nebulous dependencies from varying sources and wildly different levels of quality seems like a complete nightmare to me. There’s a lot of charm in doing things ‘the old way’, and I’m not saying you’re wrong for wanting an init system that tries to do less, or that’s easier to read and parse for you, or whatever, but that doesn’t mean systemd is bad, evil, or part of a Red Hat conspiracy to kill Linux.

Elementary OS makes meaningful accessibility improvements

With recent efforts to improve accessibility in GNOME and KDE, as well as a renewed focus on highlighting the many issues that still need fixing, the Linux desktop is making meaningful strides in becoming more accessible to those among us with disabilities. Obviously, the Linux desktop is bigger than just GNOME and KDE, so today we have elementary OS improving its accessibility features in a variety of ways. July is Disability Pride Month, an opportunity for us to consider how we’re serving our disabled community and work on breaking down barriers to access. Last year we had the pleasure of being introduced to Florian—a fully blind cybersecurity enthusiast—and thanks to his feedback we completely rewrote navigation in Onboarding to be more keyboard and screen reader friendly, as well as took another look at Installation and Initial Setup to vastly improve our entire first run experience for blind folks. Plus, we implemented the screen reader interface in the  +  window switcher. Thanks to this feedback, elementary OS 8 can be installed and set up completely blind, an important win for maintaining your independence as a person with vision disabilities. Since the release of OS 8 we’ve been working on things like improving contrast, support for Dark Mode screenshots and brand colors in AppCenter, turning on or snoozing Dark Mode without canceling your schedule, expanding the scope of the “Reduce Motion” setting, and adding more options to reduce distracting notification bubbles. Plus, thanks to feedback from Aaron who you may know from his blog series on Linux accessibility, Notifications and the Shortcut Overlay both got releases that add screen reader support. ↫ Danielle Foré at elementary’s blog I’m glad we’re finally putting to rest this idea that accessibility features should be afterthoughts, relevant to only a minute percentage of people. Not only is the disabled community way bigger than we might think, many of the features they require are simply also extremely nice and beneficial to users who might not actually require them. I know tons of people who, for instance, love reduce motion features simply because it makes their operating system feel faster, or people who just don’t want to be bothered with notifications the instant they arrive. Accessibility goes far beyond what we traditionally think of as accessibility features, like screen readers or high contrast modes. Making software more accessible for those that require it, also makes software more accessible for those that merely desire it. Even though elementary OS probably isn’t the type of distribution that appeals to the average OSNews reader, I’m incredibly happy they’re taking accessibility seriously, and I intend to continue to highlight such improvements.

An excuse to mention Void Linux: XBPS 0.60 released

Since Void Linux uses a rolling release model, there’s not much to report on in the form of new releases and major new features, so I’m taking the release of version 0.60 of XBPS, Void Linux’ package manager, to cheat my way into talking about this excellent Linux distribution. I always think of Void as the “BSD of Linux distributions”, which should give you some vague hint as to what it’s going for. XBPS 0.60 doesn’t come packed with major new features either, and mostly fixes a ton of bugs, addresses few memory leaks, and changes the way held dependencies and directory removal/creation works when reinstalling a packages, just to name a few. There’s also some performance improvements, as there were apparently some problems in that department due to the increasing number of virtual packages in the Void repository. If you’re looking for a more traditional, hands-on Linux distribution, Void is an excellent choice. It’s my back-up for if (let’s face it: when) Fedora messes something up.

Flatpak “not being actively developed anymore”

At the Linux Application Summit (LAS) in April, Sebastian Wick said that, by many metrics, Flatpak is doing great. The Flatpak application-packaging format is popular with upstream developers, and with many users. More and more applications are being published in the Flathub application store, and the format is even being adopted by Linux distributions like Fedora. However, he worried that work on the Flatpak project itself had stagnated, and that there were too few developers able to review and merge code beyond basic maintenance. ↫ Joe Brockmeier at LWN After reading this article and the long list of problems the Flatpak project is facing, I can’t really agree that “Flatpak is doing great”. Apparently, Flatpak is in maintenance mode, while major problems remain untouched, because nobody is working on the big-ticket items anymore. This seems like a big problem for a project that’s still facing a myriad of major issues. For instance, Flatpak still uses PulseAudio instead of Pipewire, which means that if a Flatpak applications needs permission to play audio, it also automatically gets permission to use the microphone. NVIDIA drivers also pose a big problem, network namespacing in Flatpak is “kind of ugly”, you can’t specify backwards-compatible permissions, and tons more problems. There’s a lot of ideas and proposed solutions, but nobody to implement them, leaving Flatpak stagnated. Now that Flatpak is adopted by quite a few popular desktop Linux distributions, it doesn’t seem particularly great that it’s having such issues with finding enough manpower to keep improving it. There’s a clear push, especially among developers of end-user focused applications, for everyone to use Flatpak, but is that push really a wise idea if the project has stagnated? Go into any thread where people discuss the use of Flatpaks, and there’s bound to be people experiencing problems, inevitably followed by suggested fixes to use third-party tools to break the already rather porous sandbox. Flatpak feels like a project that’s far from done or feature-complete, causing normal, every-day users to experience countless problems and issues. Reading straight fromt he horse’s mouth that the project has stagnated and isn’t being actively developed anymore is incredibly worrying.