Linux Archive

Remember when we linked to David Revoy’s story about how his drawing pen’s buttons stopped working properly due to a Linux kernel update? Well, it turns out that Linux kernel developers took this one up, and a fix is already being tested. This solution is still W.I.P. and I still have some homework to send more data about my tablets after this blog post, but in overall I’m already using a newer kernel (Linux workstation 6.5.10-200.fc38.x86_64) and I don’t have the problem with the eraser mode on the top button of my XPPen Artist 24 Pro and XPPen Artist 16 Pro Gen2 styluses. The buttons are also now perfectly customisable via xsetwacom CLI tool. Yay! That’s why I wanted to share this blog-post as soon as possible. Be sure to read the whole article for an in-depth explanation of what’s being done to fix this.

Some of the x86 microcode loading improvements in Linux 6.7 include not loading microcode on 32-bit before paging has been enabled to avoid a variety of issues, reworked late-loading of CPU microcode, late-loading microcode is now CPU hotplug safe, and the notion of a minimum microcode revision for determining when late microcode loading is deemed safe. Considering how crucial microcode loading is, it makes sense to improve it as much as possible.

In recent years the Itanium support in the Linux kernel has went downhill with not many users left testing new kernels on aging Itanium servers. There also hasn’t been any major active contributors to the Itanium code for keeping it maintained and making any serious improvements to the architecture code. On and off for months there’s been talk of retiring Itanium from the Linux kernel and now it’s finally happened. With Linux 6.6 expected to be this year’s Long-Term Support (LTS) kernel version, there was the proposal recently to drop Itanium in Linux 6.7 and indeed it’s successfully happened. This is a complete outrage, and a sign Torvalds has completely lost the plot. Itanium is the future, and dropping it from the Linux kernel will be its death knell. I’m going back to DOS.

In short, after a Linux kernel update (6.5.8-200.fc.x86_64 on Fedora KDE), I can’t use the top button of my pen on my tablet. This is really affecting my digital painting workflow! Right-clicking on the pen is an essential part of my workflow. Right-click on a layer in Krita to get the menu, right-click while using the Transform tool to get the transformation options, right-click on the canvas to get the pop-up palette! …And I’m not even talking about how difficult it is to handle files and the D.E. without right-clicking. And if that makes you smile, imagine someone hardcoding the behaviour of your main device like the right-click on your mouse or touchpad (or anything else you have been using for more than 20 years) to something completely useless, and pushing it through kernel updates. And the icing on the cake, they left you with no user tool to change it back. I now have that same feeling or rage mixed with hopelessness that you feel when dealing with pointless government bureaucracy.

The initial support was posted on October 25th 2023 on the Linux kernel mailing lists for review by the Linux developers community. With the set of patches released by Linaro engineers, it is also possible to boot an AOSP image with Graphics Software Rendering using Google’s SwiftShader. Since 2014, Linaro Engineers have been working closely with Qualcomm Engineers to enable Snapdragon platforms to work with Mainline Linux. Running a recent upstream Linux kernel immediately after the announcement of a new SoC is a significant achievement, and is a testimony to the close working partnership between Qualcomm and Linaro. Interestingly enough, during the recent announcement of the PC-focused X Elite SoC, Qualcomm also highlighted that Linux will be fully supported by the platform, and to underline that point, the company showed off X Elite laptops running both Windows and Linux. While it’ll take more to convince me that Qualcomm now actually cares about properly supporting its SoCs and the open source community, they’re at least positive signs.

The Linux Mint project has announced that they’re finally working on bringing the Cinnamon desktop environment over to Wayland. The work started on Wayland. As mentioned earlier this year, this was identified as one of the major challenges our project had to tackle in the mid to long term. Priority had been given to ISO tools and Secureboot over new features for 21.3 already, we felt it was time to invest some resources into Wayland as well. We wanted to have a clear picture of the work involved, so we wanted to start now. In terms of timing we don’t think we need Wayland support to be fully ready (i.e. to be a better Cinnamon option for most people) before 2026 (Mint 23.x). That leaves us 2 years to identify and to fix all the issues. It’s something we’ll continue to work on. Whenever it happens, assuming it does, we’ll consider switching defaults. We’ll use the best tools to do the job and provide the best experience. Today that means Xorg. Tomorrow it might mean Wayland. We’ll be ready and compatible with both. I respect this position. Linux Mint has always been just a bit more conservative than many of the other desktop-focused distributions, and this has earned it a well-deserved reputation for being stable and reliable. I use Linux Mint on my gaming PC for that very reason (albeit with the Xanmod kernel) – during the little time I have to play games, I don’t want to deal with issues arising from using bleeding edge software.

Linux is an operating system, similar to Windows, but with many different versions due to the nature of being open source and fully customizable. To install Linux, you must choose an install method and choose a Linux distribution. So that’s a thing.

Debian Bookworm itself is mostly made up of incremental updates of the software that was in the previous Debian Bullseye release. There are a few small changes — have a look here for the list — but they mostly won’t affect Raspberry Pi users. So Bookworm itself really hasn’t resulted in many changes. However, for the last year or so we have been working on some major architectural changes to the Raspberry Pi Desktop, and these are launched for the first time in the Bookworm release. And this is where you might notice some differences. With this new release, Raspberry Pi OS moves to Wayland and a Wayfire desktop, but it looks and feels exactly the same as what came before with X.Org. It now also comes with Pipewire, as well as an up-to-date version of Firefox that has been modified in cooperation with Mozilla to make better use of the hardware features found in the Pi.

In this guide, we’ll build a very tiny Linux kernel, weighing in at 789 K, and requiring no MMU support. We’ll write some userspace code and this will be deployed on a virtual RISC-V 64-bit machine, without MMU, and we’ll run some tiny programs of our own. As a reminder, please go through the guide for a micro Linux distro to understand the concepts behind what we’re doing today: building the kernel, initramfs, etc. This guide is basically a continuation of that one and an exercise in making an absolutely minimal Linux deployment for (in theory) extremely cheap hardware. This follows up on the mentioned earlier article.

With today’s release of kmod 31, Linux’s modprobe utility for loading kernel modules can finally allow arbitrary paths to allow loading new kernel modules from anywhere on the file-system. Surprisingly it took until 2023 for allowing Linux’s modprobe to accept loading kernel modules from any arbitrary path. Rather than just specifying the module name and then looking up the module within the running kernel’s modules directory, modprobe can now allow passing a path to the module. Relative paths are also supported when prefixed with “./” for the path to the desired module. Finally.

In this article, we’ll talk about building up a tiny (micro) Linux “distribution” from scratch. This distribution really won’t do much, but it will be built from scratch. We will build the Linux kernel on our own, and write some software to package our micro-distro. Lastly, we are doing this example on the RISC-V architecture, specifically QEMU’s riscv64 virt machine. There’s very little in this article that is specific to this architecture, so you might as well do an almost identical exercise for other architectures like x86. We recently went through the RISC-V boot process with SBI and bare metal programming for RISC-V, so this is just a continuation up the software stack. This is great content, and a very fun exercise for an Autumn weekend.

Here’s one major change coming down the road: long-term support (LTS) for Linux kernels is being reduced from six to two years. Why? Simple, Corbet explained: “There’s really no point to maintaining it for that long because people are not using them.” I agree. While I’m sure someone out there is still running 4.14 in a production Linux system, there can’t be many of them.  Another reason, and a far bigger problem than simply maintaining LTS, according to Corbet, is that Linux code maintainers are burning out. It’s not that developers are a problem. The last few Linux releases have involved an average of more than 2,000 programmers — including about 200 new developers coming on board — working on each release. However, the maintainers — the people who check the code to see if it fits and works properly — are another matter. The longer LTS support windows were put in place mostly for embedded devices, and as Ars Technica explains, it’s Android in particular that is affected by this change.

Back in 2021 Samsung engineers posted KSMBD as an in-kernel SMB3 server alternative to the likes of the user-space Samba server. KSMBD merged into Linux 5.15 as an experimental SMB server while after two years of fixes and other improvements has now dropped its “experimental” marking. The KSMBD in-kernel SMB3 server is now formally declared stable with Linux 6.6 in removing its experimental tag. Neat.

The Linux From Scratch community is pleased to announce the release of LFS Version 12.0, LFS Version 12.0 (systemd), BLFS Version 12.0, and BLFS Version 12.0 (systemd). This release is a major update to both LFS and BLFS. The LFS release includes updates to binutils-2.41, gcc-13.2.0, and glibc-2.38. In total, 38 packages were updated since the last release. The Linux kernel has also been updated to version 6.4.12. One day, after I’m done with learning Nix and NixOS, I’ll perform a Linux from Scratch installation.