Linux Archive
Lunatik is a framework for scripting the Linux kernel with Lua. It is composed by the Lua interpreter modified to run in the kernel; a device driver (written in Lua =)) and a command line tool to load and run scripts and manage runtime environments from the user space; a C API to load and run scripts and manage runtime environments from the kernel; and Lua APIs for binding kernel facilities to Lua scripts. ↫ Lunatik GitHub page I’m not knowledgeable enough to understand what this might be used for, but I figured y’all would be interested in this.
Linus Torvalds really doesn’t like spaces – as in, tabs vs. spaces – and got a little annoyed that a commit removed a hidden tab because it “apparently showed breakage in some third-party kernel config parsing tool”. So, Torvalds decided to add some hidden tabs to trigger breakages like this, and is threatening to add more hidden tabs if necessary. It wasn’t clear what tool it was, but let’s make sure it gets fixed. Because if you can’t parse tabs as whitespace, you should not be parsing the kernel Kconfig files. In fact, let’s make such breakage more obvious than some esoteric ftrace record size option. If you can’t parse tabs, you can’t have page sizes. ↫ Linus Torvalds I’m not a programmer so I’m not going to wade into this debate – I have a personal Mastodon account to state it’s obviously tabs – but I did note that it seems like, at least in this commit message, Torvalds uses a double space after a period. Which is objectively the worst thing, right before Fahrenheit.
GestureX enables you to control your Linux PC using hand gestures. You can assign specific commands or functionalities to different hand gestures, allowing for hands-free interaction with your computer. ↫ GestureX GitHub page I personally see no use for any of this, but I’m sure there are some interesting accessibility uses for technology like this, which in and of itself make it a worthwhile endeavour to work on. Do note, though, that this is all beta, so there’s bound to be issues.
Going through my usual scanning of all the “-next” Git subsystem branches of new code set to be introduced for the next Linux kernel merge window, a very notable addition was just queued up… Linux 6.10 is set to merge the NTSYNC driver for emulating the Microsoft Windows NT synchronization primitives within the kernel for allowing better performance with Valve’s Steam Play (Proton) and Wine of Windows games and other apps on Linux. ↫ Michael Larabel The improvements to performance of games running under Proton this new driver will bring are legitimately insane. We’re looking at a game-changing addition to the Linux kernel here, and it’s no surprise, then, to see this effort being spearheaded by companies like Valve and CodeWeavers.
It’s the ext2 filesystem driver that will be marked as deprecated in the upcoming 6.9 Linux kernel. The main issue is that even if the filesystem is created with 256 byte inodes (mkfs.ext2 -I 256), the filesystem driver will stick to 32 bit dates. Because of this, the driver does not support inode timestamps beyond 03:14:07 UTC on 19 January 2038. ↫ Michael Opdenacker Kernel developer Ted T’so did state that if someone wants to add support for 64bit dates to ext2, it shouldn’t be too hard. I doubt many people still use ext2, but if someone is willing to step up, the deprecation can be made undone by adding this support.
Monogon OS is an open-source, secure, API-driven and minimal operating system unlike any other. It is based on Linux and Kubernetes, but with a clean userland rebuilt entirely from scratch. It is written in pure Go and eliminates decades worth of legacy code and unnecessary complexity. It runs on a fleet of bare metal or cloud machines and provides users with a hardened, production ready Kubernetes, without the overhead of traditional Linux distributions or configuration management systems. It does away with the scripting/YAML duct tape and configuration drift inherent to traditional deployments. Instead, it provides a stable API-driven platform free of vendor lock-in and with none of the drudgery. ↫ Monogon OS website This not exactly in my wheelhouse, but I’m pretty sure some of you will be all over this concept.
Highlights of Linux kernel 6.8 include LAM (Linear Address Masking) virtualization and guest-first memory support for KVM, a basic online filesystem check and repair mechanism for the Bcachefs file system introduced in Linux kernel 6.7, support for the Broadcom BCM2712 processor in Raspberry Pi 5, AMD ACPI-based Wi-Fi band RFI mitigation feature (WBRF), zswap writeback disabling, fscrypt support for CephFS, a new Intel Xe DRM driver, and a multi-size THP (Transparent Huge Pages) sysfs interface. ↫ Marius Nestor at 9to5Linux There’s way more going on in this new release, of course, such as further Rust support, for instance in the Loongson architecture, additional support for tons of newer Intel processors , specific support patches for various laptops, and so, so much more.
One of the limitations of AMD’s open-source Linux graphics driver has been the inability to implement HDMI 2.1+ functionality on the basis of legal requirements by the HDMI Forum. AMD engineers had been working to come up with a solution in conjunction with the HDMI Forum for being able to provide HDMI 2.1+ capabilities with their open-source Linux kernel driver, but it looks like those efforts for now have concluded and failed. ↫ Michael Larabel So dumb.
For the past few months we have been working hard to provide a fast, reliable and secure KVM backend for VirtualBox. VirtualBox is a multi-platform Virtual Machine Monitor (VMM) with a great feature set, support for a wide variety of guest operating systems, and a consistent user interface across different host operating systems. Cyberus Technology’s KVM backend allows VirtualBox to run virtual machines utilizing the Linux KVM hypervisor instead of the custom kernel module used by standard VirtualBox. Using KVM comes with a number of benefits. ↫ Florian Pester, Markus Partheymüller Excellent news. Dealing with the VirtualBox and VMware kernel modules can be a hassle if you’re using newer or custom kernels, and having the VirtualBox UI for kvm instead of things virt-manager is not something I’m unhappy about.
The Wine project emulates the Windows API in user space. One particular part of that API, namely the NT synchronization primitives, have historically been implemented via RPC to a dedicated “kernel” process. However, more recent applications use these APIs more strenuously, and the overhead of RPC has become a bottleneck. The NT synchronization APIs are too complex to implement on top of existing primitives without sacrificing correctness. Certain operations, such as NtPulseEvent() or the “wait-for-all” mode of NtWaitForMultipleObjects(), require direct control over the underlying wait queue, and implementing a wait queue sufficiently robust for Wine in user space is not possible. This proposed driver, therefore, implements the problematic interfaces directly in the Linux kernel. ↫ Elizabeth Figura on the lkml This proposed driver would yield some serious performance results.
What follows is a letter from Hans Reiser to myself, which he wrote some two months back, and has asked me to publish, with his thoughts on the deprecation of ReiserFS from the Linux kernel. I have transcribed it to the best of my ability. Plaintext email may not be the best way to read it, as such, I have also made available PDF and HTML versions of the letter. ↫ Fredrick R. Brennan Hans Reiser is the creator of the ReiserFS file system, which used to be a serious contender for the Linux file system you’d use in the early 2000s. In 2006, Hans Reiser murdered his wife, and is currently serving a prison sentence for this crime. Hopefully, after he completes his prison sentence, he can become a contributing member of society once again, if the professionals and specialists involved in such matters deem him capable of doing so. The long letter mentioned here was actually quite a fascinating read, and details his abrasive behaviour in the Linux world, the design of ReiserFS and its place in the ecosystem at the time, and his thoughts on the removal of ReiserFS from the Linux kernel.
Flakes also are a symptom or cause of much intra-community strife between “pro-flakes” and “anti-flakes” factions, but this situation is at some level a sign of broken consensus processes and various actors trying to sidestep them, an assumption by many people that the docs are “outdated” for not using flakes, and the bizarre proliferation of flakes everywhere in blog posts or tutorials leading to a belief that they are required for everything. This post is about how to architect Nix projects in general, with a special eye on how to do so with flakes while avoiding their limitations. It tries to dispel misconceptions that can develop in such a monoculture. ↫ Jade Every time I hear about Nix and Flakes I feel like I understand all of it a little less.
systemd, as a service manager, is not actually a bad piece of software by itself. The fact it can act as both a service manager and an inetd(8) replacement is really cool. The unit file format is very nice and expressive. Defining mechanism and leaving policy to the administrator is a good design. Of course, nothing exists in a vacuum. I don’t like the encouragement to link daemons to libsystemd for better integration – all of the useful integrations can be done with more portable measures. And I really don’t like the fact they consider glibc to be “the Linux API” when musl, Bionic, and other libcs exist. I’d like to dive into detail on the good and the bad of systemd, as seen through my eyes as all of: end user, administrator, and developer. ↫ awilfox awilfox is a maintainer of Adélie Linux, which does not use systemd, but this blog post is one of the few reasonable, well-written, and substantiated critiques of systemd – as opposed to the usual mindless screeching you usually hear about systemd. A great read.
Linux 6.7 has many exciting features including initial support for the Bcachefs file-system, Intel Meteor Lake graphics are stable as is the rest of the MTL platform support, initial NVIDIA GSP firmware support with the Nouveau driver, retiring of Intel Itanium support, and other new features with Linux 6.7. ↫ Michael Larabel The end of Itanium support is unforgivable. Itanium is the future, and Linux will miss the boat.
SteamOS 3 (“Holo”) is the Arch-based Linux distribution built for the Steam Deck, Valve Software’s portable PC gaming device. It’s a very interesting Linux distribution even when you only focus on how it updates itself: updates are performed atomically by downloading a new read-only root filesystem to an inactive partition, then rebooting into that partition. But consumers can also run steamos-devmode to unlock the root filesystem, put the pacman database in working order, and give them a working Linux distro with a normal package manager. This A/B atomic updates system is pretty standard for OSes these days, but there’s a lot going on in SteamOS that makes them work even with heavy customization by the end-user. I wanted to explore that while still being able to make changes to the root filesystem images. steamos-devmode is the easy way out; I wanted to make a proper fork. Here’s how I did it. ↫ iliana etaoin This article has sparked my interest to build a living room PC for Steam gaming for my wife and I, so we can play couch coop Steam games on an actual couch instead of behind our PC desk. Very detailed and in-depth, this article also teaches a lot about how SteamOS works under the hood.
systemd 255 has been released, and it contains one particular new feature I want to highlight. A new component “systemd-bsod” has been added to show logged error messages full-screen if they have a “LOG_EMERG” log level. This is intended as a tool for displaying emergency log messages full-screen on boot failures. Yes, BSOD in this case short for “Blue Screen of Death”. This was worked on as part of Outreachy 2023. The systemd-bsod will also display a QR code for getting more information on the error causing the boot failure. ↫ Michael Larabel at Phoronix I like this. Operating systems usually have excellent logging capabilities, but getting to these logs and making sense of them isn’t always easy, especially if you’re not elbow-deep in the weeds of how your operating system of choice works. Giving a useful error screen when things really hit a brick wall at 200 km/h is a good thing, and will make at least some troubleshooting easier.
PipeWire 1.0 now has all the features that are expected to move media streams inside a system. It takes advantage of advanced features of the Linux kernel to provide low latency, low footprint, and high performance while being secure. It is the perfect tool to build an embedded system or to securely share streams between containers. Linux audio and video has come a long way, and PipeWire is part of that. Excellent work.
Phoronix listed some of the major work happening in 6.7 for the RISC-V architecture: Merged last week was support for cbo.zero in user-space, support for CBOs on ACPI-based RISC-V systems, support for software shadow call stacks, improvements for the T-Head cache flushing operations, and other clean-ups and fixes. Meanwhile sent out today was a secondary pull request of more RISC-V changes for Linux 6.7. This latest pull has support for handling misaligned accesses in S-mode, performance improvements for TLB flushing, support for many new relocations in the module loader, and other enhancements. Momentum is definitely going for RISC-V.
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.
