Linux Archive

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.

As part of updates to the older file-system drivers for Linux 6.6, the ReiserFS file-system is no longer marked as “Supported” but is officially treated as “Obsolete” within the Linux kernel. The linux-fs merge for the Linux 6.6 cycle now treats ReiserFS as obsolete, the file-system long ago used by default on the likes of SUSE Linux. Last year with Linux 5.18 ReiserFS was deprecated and now with it being obsolete, it will likely be dropped from the mainline Linux kernel within the next two to three years. Last year openSUSE Tumbleweed also ended ReiserFS support as one of the few distributions supporting it as an option. The story of ReiserFS is a sad one – its creator, Hans Reiser, was charged with and convicted of the murder of his wife. The successor to ReiserFS, Reiser5, is still seeing sporadic development, but most likely won’t be mainlined any time soon.

The Linux 6.6 modules infrastructure is changing to better protect against the illicit behavior of NVIDIA’s proprietary kernel driver. Luis Chamberlain sent out the modules changes today for the Linux 6.6 merge window. Most notable with the modules update is a change that better builds up the defenses against NVIDIA’s proprietary kernel driver from using GPL-only symbols. Or in other words, bits that only true open-source drivers should be utilizing and not proprietary kernel drivers like NVIDIA’s default Linux driver in respecting the original kernel code author’s intent. Here’s a wild idea, NVIDIA: just release your driver code as open source.