Linux Archive
You might expect PDF files to only be comprised of static documents, but surprisingly, the PDF file format supports Javascript with its own separate standard library. Modern browsers (Chromium, Firefox) implement this as part of their PDF engines. However, the APIs that are available in the browser are much more limited. The full specfication for the JS in PDFs was only ever implemented by Adobe Acrobat, and it contains some ridiculous things like the ability to do 3D rendering, make HTTP requests, and detect every monitor connected to the user’s system. However, on Chromium and other browsers, only a tiny subset of this API was ever implemented, due to obvious security concerns. With this, we can do whatever computation we want, just with some very limited IO. ↫ LinuxPDF GitHub page I’m both impressed and concerned.
GNU Guix is a package manager for GNU/Linux systems. It is designed to give users more control over their general-purpose and specialized computing environments, and make these easier to reproduce over time and deploy to one or many devices. ↫ GNU Guix website Guix is basically GNU’s approach to a reproducible, functional package manager, very similar to Nix because, well, it’s based on Nix. GNU also has a Linux distribution built around Nix, the GNU Guix System, which is fully ‘libre’ as all things GNU are, and also makes use of the GNU Shepard init system. Both Shepard and Guix make use of Guile. The last release of the GNU Guix System is a few years old already, but it’s a rolling release, so that’s not much of an issue. It uses the Linux kernel, but support for GNU Hurd is also being worked on, for whatever that’s worth. There’s also a third-party distribution that is built around the same projects, called rde. It focuses on being lightweight, ready for offline use, and minimal distractions. It’s probably not suitable for most normal users, but if you’re a power user and you’re looking for something a little bit different, this could be for you. While it’s in active development, it’s considered usable and stable by its creators. I haven’t tried it yet, but I’m definitely intrigued by what it has to offer. Nix sucks up a lot of the attention in this space, so it’s interesting to see some of the alternatives that aim for similar goals.
With the Linux 6.13 kernel, Greg Kroah-Hartman described the level of Rust support as a “tipping point” for Rust drivers with more of the Rust infrastructure having been merged. Now for the Linux 6.14 kernel, Greg describes the state of the Rust driver possibilities as “almost at the “write a real driver in rust” stage now, depending on what you want to do.“ ↫ Michael Larabel Excellent news, as there’s a lot of interest in Rust, and it seems that allowing developers to write drivers for Linux in Rust will make at least some new and upcoming drivers comes with less memory safety issues than non-Rust drivers. I’m also quite sure this will anger absolutely nobody.
The Linux kernel has become such an integral, core part of pretty much all aspects of the technology world, and corporate contributions to the kernel make up such a huge chunk of the kernel’s ongoing development, it’s easy to forget that some parts of the kernel are still maintained by some lone person in Jacksonville, Nebraska, or whatever. Sadly, we were reminded of this today when the sole maintainer of a few DRM (no, not the bad kind) announced he can no longer maintain the gud, mi0283qt, panel-mipi-dbi, and repaper drivers. Remove myself as maintainer for gud, mi0283qt, panel-mipi-dbi and repaper. My fatigue illness has finally closed the door on doing development of even moderate complexity so it’s sad to let this go. ↫ Noralf Trønnes There must be quite a few obscure parts of the Linux kernel that are of no interest to the corporate world, and thus remain maintained by individuals in their free time, out of some personal need or perhaps a sense of duty. If one such person gives up their role as maintainer, for whatever reason, you better hope it’s not something your workflow relies, because if no new maintainer is found, you will eventually run into trouble. I hope Trønnes gets better soon, and if not, that someone else can take over from him to maintain these drivers. The gud driver seems like a really neat tool for homebrew projects, and it’d be sad to see it languish as the years go by.
Linux 6.13 comes with the introduction of the AMD 3D V-Cache Optimizer driver for benefiting multi-CCD Ryzen X3D processors, the new AMD EPYC 9005 “Turin” server processors will now default to AMD P-State rather than ACPI CPUFreq for better power efficiency, the start of Intel Xe3 graphics bring-up, support for many older (pre-M1) Apple devices like numerous iPads and iPhones, NVMe 2.1 specification support, and AutoFDO and Propeller optimization support when compiling the Linux kernel with the LLVM Clang compiler. Linux 6.13 also brings more Rust programming language infrastructure and more. ↫ Michael Larabel A big release, with a ton of new features. It’ll make its way to your distribution soon enough.
A change to the Linux 6.13 kernel contributed by a Microsoft engineer ended up changing Linux x86_64 code without proper authorization and in turn causing troubles for users and now set to be disabled ahead of the Linux 6.13 stable release expected next Sunday. ↫ Michael Larabel What I like about this story is that it seems to underline that the processes, checks, and balances in place in Linux kernel development seem to be working – at least, this time. A breaking change was caught during the prerelease phase, and a fix has been merged to make sure this issue will be fixed before the stable version of Linux 6.13 is released to the wider public. This all sounds great, but there is an element of this story that raises some serious questions. The change itself was related to EXECMEM_ROX, and was intended to improve performance of 64bit AMD and Intel processors, but in turn, this new code broke Control Flow Integrity on some setups, causing some devices not to wake from hibernation while also breaking other features. What makes this spicy is that the code was merged without acknowledgement from any of the x86 kernel maintainers, which made a lot of people very unhappy – and understandably so. So while the processes and checks and balances worked here, something still went horribly wrong, as such changes should not be able to be merged without acknowledgement from maintainers. This now makes me wonder how many more times this has happened without causing any instantly discoverable issues. For now, some code has been added to revert the offending changes, and Linux 6.13 will ship with Microsoft’s bad code disabled.
We’ve talked about Chimera Linux before – it’s a unique Linux distribution that combines a BSD userland with the LLVM/Clang toolchain, and musl. Its init system is dinit, and it uses apk-tools from Alpine as its package manager. None of this has anything to do with being anti-anything; the choice of BSD’s tools and userland is mostly technical in nature. Chimera Linux is available for x86-64, AArch64, RISC-V, and POWER (both little and big endian). I am unreasonably excited for Chimera Linux, for a variety of reasons – first, I love the above set of choices they made, and second, Chimera Linux’ founder and lead developer, q66, is a well-known and respected name in this space. She not only founded Chimera Linux, but also used to maintain the POWER/PowerPC ports of Void Linux, which is the port of Void Linux I used on my POWER9 hardware. She apparently also contributed quite a bit to Enlightenment, and is currently employed by Igalia, through which she can work on Chimera. With the description out of the way, here’s the news: Chimera Linux has officially entered beta. Today we have updated apk-tools to an rc tag. With this, the project is now entering beta phase, after around a year and a half. In general, this does not actually mean much, as the project is rolling release and updates will simply keep coming. It is more of an acknowledgement of current status, though new images will be released in the coming days. ↫ Chimera Linux’s website Despite my excitement, I haven’t yet tried Chimera Linux myself, as I figured its pre-beta stage wasn’t meant for an idiot like me who can’t contribute anything meaningful, and I’d rather not clutter the airwaves. Now that it’s entered beta, I feel like the time is getting riper and riper for me to dive in, and perhaps write about it here. Since the goal of Chimera Linux is to be a general-purpose distribution, I think I’m right in the proper demographic of users. It helps that I’m about to set up my dual-processor POWER9 machine again, and I think I’ll be going with Chimera Linux. As a final note, you may have noticed I consistently refer to it as “Chimera Linux”. This is very much on purpose, as there’s also something called ChimeraOS, a more standard Linux distribution aimed at gaming. To avoid confusion, I figured I’d keep the naming clear and consistent.
With more and more Linux distributions – as well as the kernel itself – dropping support for more exotic, often dead architectures, it’s a blessing T2 Linux exists. This unique, source-based Linux distribution focuses on making it as easy as possible to build a Linux installation tailored to your needs, and supports an absolutely insane amount of architectures and platforms. In fact, calling T2 a “distribution” does it a bit of a disservice, since it’s much more than that. You may have noticed the banner at the top of OSNews, and if we somehow – unlikely! -manage to reach that goal before the two remaining new-in-box HP c8000 PA-RISC workstations on eBay are sold, my plan is indeed to run HP-UX as my only operating system for a week, because I like inflicting pain on myself. However, I also intend to use that machine to see just how far T2 Linux on PA-RISC can take me, and if it can make a machine like the c8000, which is plenty powerful with its two dual-core 1.0Ghz PA-RISC processors, properly useful in 2024. T2 Linux 24.12 has just been released, and it brings with it the latest versions of the Linux kernel, gcc, LLVM/Clang, and so on. With T2 Linux, which describes itself as a System Development Environment, it’s very easy to spin up a heavily customised Linux installation fit for your purpose, targeting anything from absolutely resource-starved embedded systems to big hunks of, I don’t know, SPARC or POWER metal. If you’ve got hardware with a processor in it, you can most likely build T2 for it. The project also provides a large number of pre-built ISOs for a whole slew of supported architectures, sometimes further divided into glibc or musl, so you can quickly get started even without having to build something yourself. It’s an utterly unique project that deserves more attention than it’s getting, especially since it seems to be one of the last Linux “distributions” that takes supporting weird platforms out-of-the-box seriously. Think of it as the NetBSD of the Linux world, and I know for a fact that there’s a very particular type of person to whom that really appeals.
With its latest reales qemu added the Venus patches so that virtio-gpu now support venus encapsulation for vulkan. This is one more piece to the puzzle towards full Vulkan support. An outdated blog post on clollabora described in 2021 how to enable 3D acceleration of Vulkan applications in QEMU through the Venus experimental Vulkan driver for VirtIO-GPU with a local development environment. Following up on the outdated write up, this is how its done today. ↫ Pepper Gray A major milestone, and for the adventurous, you can get it working today. Give it a few more months, and many of the versions required will be part of your ditribution’s package repositories, making the process a bit easier. On a related note, Linux kernel developers are considering removing 32-bit x86 KVM host support for all architectures that support it – PowerPC, MIPS, RISC-V, and x86-64 – because nobody is using this functionality. This support was dropped from 32bit ARM a few years ago, and the remaining architectures mentioned above have orders of magnitude fewer users still. If nobody is using this functionality, it really makes no sense to keep it around, and as such, the calls to remove it. In other words, if your custom workflow of opening your garage door through your fridge light’s flicker frequency and the alignment of the planets and custom scripts on a Raspberry Pi 2 requires this support, let the kernel developers know, or forever hold your peace.
A month and a bit ago, I wondered if I could cope with a terminal-only computer. The only way to really find out was to give it a go. My goal was to see what it was like to use a terminal-only computer for my personal computing for two weeks, and more if I fancied it. ↫ Neil’s blog I tried to do this too, once. Once. Doing everything from the terminal just isn’t viable for me, mostly because I didn’t grow up with it. Our family’s first computer ran MS-DOS (with a Windows 3.1 installation we never used), and I’m pretty sure the experience of using MS-DOS as my first CLI ruined me for life. My mental model for computing didn’t start forming properly until Windows 95 came out, and as such, computing is inherently graphical for me, and no matter how many amazing CLI and TUI applications are out there – and there are many, many amazing ones – my brain just isn’t compatible with it. There are a few tasks I prefer doing with the command line, like updating my computers or editing system files using Nano, but for everything else I’m just faster and more comfortable with a graphical user interface. This comes down to not knowing most commands by heart, and often not even knowing the options and flags for the most basic of commands, meaning even very basic operations that people comfortable using the command line do without even thinking, take me ages. I’m glad any modern Linux distribution – I use Fedora KDE on all my computers – offers both paths for almost anything you could do on your computer, and unless I specifically opt to do so, I literally – literally literally – never have to touch the command line.
Valve, entirely going against the popular definition of Vendor, is still actively working on improving and maintaining the kernel for their Steam Deck hardware. Let’s see what they’re up to in this 6.8 cycle. ↫ Samuel Dionne-Riel Just a quick look at what, exactly, Valve does with the Steam Deck Linux kernel – nothing more, nothing less. It’s nice to have simple, straightforward posts sometimes.
Ah, the Common Hardware Reference Platform, IBM’s and Apple’s ill-fated attempt at taking on the PC market with a reference PowerPC platform anybody could build and expand upon while remaining (mostly) compatible with one another. Sadly, like so many other things Apple was trying to do before Steve Jobs returned, it never took off, and even Apple itself never implemented CHRP in any meaningful way. Only a few random IBM and Motorola computers ever fully implemented it, and Apple didn’t get any further than basic CHRP support in Mac OS 8, and some PowerPC Macs were based on CHRP, without actually being compatible with it. We’re roughly three decades down the line now, and pretty much everyone except weird nerds like us have forgotten CHRP was ever even a thing, but Linux has continued to support CHRP all this time. This support, too, though, is coming to an end, as Michael Ellerman has informed the Linux kernel community that they’re thinking of getting rid of it. Only a very small number of machines are supported by CHRP in Linux: the IBM B50, bplan/Genesi’s Pegasos/Pegasos2 boards, the Total Impact briQ, and maybe some Motorola machines, and that’s it. Ellerman notes that these machines seem to have zero active users, and anyone wanting to bring CHRP support back can always go back in the git history. CHRP is one of the many, many footnotes in computing history, and with so few machines out there that supported it, and so few machines Linux’ CHRP support could even be used for, it makes perfect sense to remove this from the kernel, while obviously keeping it in git’s history in case anyone wants to work with it on their hardware in the future. Still, it’s always fun to see references to such old, obscure hardware and platforms in 2024, even if it’s technically sad news.
Version 6.12 of the Linux kernel has been released. The main feature consists of the merger of the real-time PREEMPT_RT scheduler, most likely one of the longest-running merger sagas in Linux’ history. This means that Linux now fully supports both soft and hard real-time capabilities natively, which is a major step forward for the platform, especially when looking at embedded development. It’s now no longer needed to draw in real-time support from outside the kernel. Linux 6.12 also brings a huge number of improvements for graphics drivers, for both Intel and AMD’s graphics cards. With 6.12, Linux now supports the Intel Xe2 integrated GPU as well as Intel’s upcoming discrete “Battlemage” GPUs by default, and it contains more AMD RDNA4 support for those upcoming GPUs. DRM panics messages in 6.12 will show a QR code you can scan for more information, a feature written in Rust, and initial support for the Raspberry Pi 5 finally hit mainline too. Of course, there’s a lot more in here, like the usual LoongArch and ARM improvements, new drivers, and so on. and if you’re a regular Linux user you’ll see 6.12 make it to your distribution within a few weeks or months.
Speaking of Steam, the Linux version of Valve’s gaming platform has just received a pretty substantial set of fixes for crashes, and Timothee “TTimo” Besset, who works for Valve on Linux support, has published a blog post with more details about what kind of crashes they’ve been fixing. The Steam client update on November 5th mentions “Fixed some miscellaneous common crashes.” in the Linux notes, which I wanted to give a bit of background on. There’s more than one fix that made it in under the somewhat generic header, but the one change that made the most significant impact to Steam client stability on Linux has been a revamping of how we are approaching the setenv and getenv functions. One of my colleagues rightly dubbed setenv “the worst Linux API”. It’s such a simple, common API, available on all platforms that it was a little difficult to convince ourselves just how bad it is. I highly encourage anyone who writes software that will run on Linux at some point to read through “RachelByTheBay”‘s very engaging post on the subject. ↫ Timothee “TTimo” Besset This indeed seems to be a specific Linux problem, and due to the variability in Linux systems – different distributions, extensive user customisation, and so on – debugging information was more difficult to parse than on Windows and macOS. After a lot of work grouping the debug information to try and make sense of it all, it turned out that the two functions in question were causing issues in threads other than those that used them. They had to resort to several solutions, from reducing the reliance on setenv and refactoring it with exevpe, to reducing the reliance on getenv through caching, to introducing “an ‘environment manager’ that pre-allocates large enough value buffers at startup for fixed environment variable names, before any threading has started”. It was especially this last one that had a major impact on reducing the number of crashes with Steam on Linux. Besset does note that these functions are still used far too often, but that at this point it’s out of their control because that usage comes from the libraries of the operating system, like x11, xcb, dbus, and so on. Besset also mentions that it would be much better if this issue can be addressed in glibc, and in the comments, a user by the name of Adhemerval reports that this is indeed something the glibc team is working on.
Torvalds said that the current state of AI technology is 90 percent marketing and 10 percent factual reality. The developer, who won Finland’s Millennium Technology Prize for the creation of the Linux kernel, was interviewed during the Open Source Summit held in Vienna, where he had the chance to talk about both the open-source world and the latest technology trends. ↫ Alfonso Maruccia at Techspot Well, he’s not wrong. “AI” definitely feels like a bubble at the moment, and while there’s probably eventually going to be useful implementations people might actually want to actively use to produce quality content, most “AI” features today produce a stream of obviously fake diarrhea full of malformed hands, lies, and misinformation. Maybe we’ll eventually work out these serious kinks, but for now, it’s mostly just a gimmick providing us with an endless source of memes. Which is fun, but not exactly what we’re being sold, and not something worth destroying the planet for even faster. Meanwhile, Google is going utterly bananas with its use of “AI” inside the company, with Sundar Pichai claiming 25% of code inside Google is now “AI”-generated. ↫ Sundar Pichai We’re also using AI internally to improve our coding processes, which is boosting productivity and efficiency. Today, more than a quarter of all new code at Google is generated by AI, then reviewed and accepted by engineers. This helps our engineers do more and move faster. So much here feels wrong. First, who wants to bet those engineers care a whole lot less about the generated code than they do about code they write themselves? Second, who wants to bet that generated code is entirely undocumented? Third, who wants to bet what the additional costs will be a few years from now when the next batch of engineers tries to make sense of that undocumented generated code? Sure, Google might save a bit on engineers’ salaries now, but how much extra will they have to spend to unspaghettify that diarrhea code in the future? It will be very interesting to keep an eye on this, and check back in, say, five years, and hear from the Google engineers of the future how much of their time is spent fixing undocumented “AI”-generated code. I can’t wait.
If you love exploit mitigations, you may have heard of a new system call named mseal landing into the Linux kernel’s 6.10 release, providing a protection called “memory sealing.” Beyond notes from the authors, very little information about this mitigation exists. In this blog post, we’ll explain what this syscall is, including how it’s different from prior memory protection schemes and how it works in the kernel to protect virtual memory. We’ll also describe the particular exploit scenarios that mseal helps stop in Linux userspace, such as stopping malicious permissions tampering and preventing memory unmapping attacks. ↫ Alan Cao The goal of mseal is to, well, literally seal a part of memory and protect its contents from being tampered with. It makes regions of memory immutable so that while a program is running, its memory contents cannot be modified by malicious actors. This article goes into great detail about this new feature, explains how it works, and what it means for security in the Linux kernel. Excellent light reading for the weekend.
When Valve took its second major crack at making Steam machines happen, in the form of the Steam Deck, one of the big surprises was the company’s choice to base the Linux operating system the Steam Deck uses on Arch Linux, instead of the Debian base it was using before. It seems this choice is not only benefiting Valve, but also Arch. We are excited to announce that Arch Linux is entering into a direct collaboration with Valve. Valve is generously providing backing for two critical projects that will have a huge impact on our distribution: a build service infrastructure and a secure signing enclave. By supporting work on a freelance basis for these topics, Valve enables us to work on them without being limited solely by the free time of our volunteers. ↫ Levente Polyak This is great news for Arch, but of course, also for Linux in general. The work distributions do to improve their user experience tend to be picked up by other distributions, and it’s clear that Valve’s contributions have been vast. With these collaborations, Valve is also showing it’s in it for the long term, and not just interested in taking from the community, but also in giving, which is good news for the large number of people now using Linux for gaming. The Arch team highlights that these projects will follow the regular administrative and decision-making processes within the distribution, so we’re not looking at parallel efforts forced upon everyone else without a say.
Can you run Linux on the Intel 4004, the first commercially produced microprocessor, released to the world in 1971? Well, Dmitry Grinberg, the genius engineer who got Linux to run on all kinds of incredibly underpowered hardware, sought to answer this very important question. In short, yes, you can run Linux on the 4004, but much as with other extremely limited and barebones chips, you have to get… Creative. Very creative. Of course, Linux cannot and will not boot on a 4004 directly. There is no C compiler targeting the 4004, nor could one be created due to the limitations of the architecture. The amount of ROM and RAM that is addressable is also simply too low. So, same as before, I would have to resort to emulation. My initial goal was to fit into 4KB of code, as that is what an unmodified unassisted 4004 can address. 4KB of code is not much at all to emulate a complete system. After studying the options, it became clear that MIPS R3000 would be the winner here. Every other architecture I considered would be harder to emulate in some way. Some architectures had arbitrarily-shifted operands all the time (ARM), some have shitty addressing modes necessitating that they would be slow (RISCV), some would need more than 4KB to even decode instructions (x86), and some were just too complex to emulate in so little space (PPC). … so … MIPS again… OK! ↫ Dmitry Grinberg This is just one very small aspect of this massive undertaking, and the article and videos accompanying his success are incredibly detailed and definitely not for the faint of heart. The amount of skill, knowledge, creativity, and persistence on display here is stunning, and many of us can only dream of being able to do stuff like this. I absolutely love it. Of course, the Linux kernel had to be slimmed down considerably, as a lot of stuff currently in the kernel are of absolutely no use on such an old system. Boot time is measured in days, still, but it helped a lot. Grinberg also turned the whole setup into what is effectively an art piece you can hang on the wall, where you can have it run and, well, do things – not much, of course, but he did include a small program that draws mandelbrot set on the VFD and serial port, which is a neat trick. He plans on offering the whole thing as a kit, but a lot of it depends on getting enough of the old chips to offer a complete, ready-to-assemble kit in the first place.
Linus Torvalds just tagged the Linux 6.11 kernel as stable. There are many changes and new features in Linux 6.11 including numerous AMD CPU and GPU improvements, preparations for upcoming Intel platforms, initial block atomic write support for NVMe and SCSI drives, the DRM Panic infrastructure can now display a monochrome logo if desired, easier support for building Pacman kernel packages for Arch Linux, DeviceTree files for initial Snapdragon X1 laptops, and much more. ↫ Michael Larabel Especially the Snapdragon stuff interests me, as I really want to move to ARM for my laptop needs at some point, and I’m obviously not going to be using Windows or macOS. I hope the bringup for the Snapdragon laptop chips is smooth sailing from here and picks up pace, because I’d hate for Linux to miss out on this transition. Qualcomm talked big game about supporting Linux properly, but it feels like they’re – what a surprise – not backing those words up with actions so far.
How does Linux move from an awake machine to a hibernating one? How does it then manage to restore all state? These questions led me to read way too much C in trying to figure out how this particular hardware/software boundary is navigated. ↫ Jacob Adams So this is a lot deeper of a dive than I expected, and it blows my mind just how complex sleep, hibernating, and waking a computer really is. Instinctively you know this, but seeing it spelled out like this really drives that point home – and this only covers going into hibernation. It also highlights how hard it must be for the developers involved to keep this working at all, especially on the wide variety of machines and hardware combinations Linux runs on. It wasn’t too log ago that pretty much the only platform where sleeping and waking worked reliably was Mac OS X with its controlled, small hardware selection, so it’s kind of remarkable this works at all on Linux now. I haven’t had to worry about sleeping and waking with Linux for quite a while now, and it’s one of those things that “just works” so I never have to think about it. This definitely wasn’t always the case, though, and on both Linux and Windows I would just turn the whole feature off since it rarely worked reliably, especially on desktops. I’m sure it still breaks for people, but for me, it’s been rock solid, and reading through the linked article, I’m even more amazed about this than I already was.
