A recent bug report filed against Ubuntu’s upgrading tool confirmed a major change with regards to the RISC-V requirements for the upcoming Ubuntu 25.10 release — most existing RISC-V devices will not be able to run Ubuntu 25.10.

How come?

↫ Joey Sneddon at omgubuntu.co.uk

RISC-V just isn’t delivering. That’s the cold and harsh truth more and more people are having to deal with, such as Chimera Linux dropping RISC-V support because the ecosystem is simply lacking the kind of powerful and available hardware to sustain itself (Chimera got lucky, though, and gained access to a Milk-V Pioneer through Adélie Linux). The number of systems and boards that are both powerful and available is close enough to zero that it might as well be zero, and if neither users nor developers can buy RISC-V hardware, what’s the point in supporting it?

The issue for Ubuntu specifically is that version 25.10 of the distribution intends to target only the RVA23 baseline RISC-V profile, while currently Ubuntu supports RVA20 as the baseline. This higher baseline profile requires a number of extensions to the instruction set that no existing hardware yet supports, making 25.10 effectively a clean break for all existing RISC-V hardware. In other words, if you’re running Ubuntu on RISC-V hardware today, you won’t be able to upgrade to 25.10 or higher.

RISC-V really needs vastly improved hardware availability, because right now it’s just not delivering on the years of promises.

Clifton Sellers attended a Zoom meeting last month where robots outnumbered humans.

He counted six people on the call including himself, Sellers recounted in an interview. The 10 others attending were note-taking apps powered by artificial intelligence that had joined to record, transcribe and summarize the meeting.

↫ Lisa Bonos and Danielle Abril at The Bezos Post

Management strongly encourages – mandates – that everyone use “AI” to improve productivity, but then gets all uppity when people actually do.

Welcome to “finding out”.

Once you build a surveillance system, you can’t control who will use it:

A hacker working for the Sinaloa drug cartel was able to obtain an FBI official’s phone records and use Mexico City’s surveillance cameras to help track and kill the agency’s informants in 2018, according to a new US justice department report.

The incident was disclosed in a justice department inspector general’s audit of the FBI’s efforts to mitigate the effects of “ubiquitous technical surveillance,” a term used to describe the global proliferation of cameras and the thriving trade in vast stores of communications, travel, and location data.

[…]

The report said the hacker identified an FBI assistant legal attaché at the US embassy in Mexico City and was able to use the attaché’s phone number “to obtain calls made and received, as well as geolocation data.” The report said the hacker also “used Mexico City’s camera system to follow the [FBI official] through the city and identify people the [official] met with.”

FBI report.

Some time ago, Linus Torvalds made a throwaway comment that sent ripples through the Linux world. Was it perhaps time to abandon support for the now-ancient Intel 486? Developers had already abandoned the 386 in 2012, and Torvalds openly mused if the time was right to make further cuts for the benefit of modernity.

It would take three long years, but that eventuality finally came to pass. As of version 6.15, the Linux kernel will no longer support chips running the 80486 architecture, along with a gaggle of early “586” chips as well. It’s all down to some housekeeping and precise technical changes that will make the new code inoperable with the machines of the past.

Why Won’t It Work Anymore?

The big change is coming about thanks to a patch submitted by Ingo Molnar, a long time developer on the Linux kernel. The patch slashes support for older pre-Pentium CPUs, including the Intel 486 and a wide swathe of third-party chips that fell in between the 486 and Pentium generations when it came to low-level feature support.

Going forward, Molnar’s patch reconfigures the kernel to require CPUs have hardware support for the Time Stamp Counter (RDTSC) and CMPXCHG8B instructions. These became part of x86 when Intel introduced the very first Pentium processors to the market in the early 1990s. The Time Stamp Counter is relatively easy to understand—a simple 64-bit register that stores the number of cycles executed by the CPU since last reset. As for CMPXCHG8B, it’s used for comparing and exchanging eight bytes of data at a time. Earlier Intel CPUs got by with only the single-byte CMPXCHG instruction. The Linux kernel used to feature a piece of code to emulate CMPXCHG8B in order to ease interoperability with older chips that lacked the feature in hardware.

The changes remove around 15,000 lines of code. Deletions include code to emulate the CMPXCHG8B instruction for older processors that lacked the instruction, various emulated math routines, along with configuration code that configured the kernel properly for older lower-feature CPUs.

Basically, if you try to run Linux kernel 6.15 on a 486 going forward, it’s just not going to work. The kernel will make calls to instructions that the chip has never heard of, and everything will fall over. The same will be true for machines running various non-Pentium “586” chips, like the AMD 5×86 and Cyrix 5×86, as well as the AMD Elan. It’s likely even some later chips, like the Cyrix 6×86, might not work, given their questionable or non-existent support of the CMPXCHG8B instruction.

Why Now?

Molnar’s reasoning for the move was straightforward, as explained in the patch notes:

In the x86 architecture we have various complicated hardware emulation
facilities on x86-32 to support ancient 32-bit CPUs that very very few
people are using with modern kernels. This compatibility glue is sometimes
even causing problems that people spend time to resolve, which time could
be spent on other things.

Indeed, it follows on from earlier comments by Torvalds, who had noted how development was being held back by support for the ancient members of Intel’s x86 architecture. In particular, the Linux creator questioned whether modern kernels were even widely compatible with older 486 CPUs, given that various low-level features of the kernel had already begun to implement the use of instructions like RDTSC that weren’t present on pre-Pentium processors. “Our non-Pentium support is ACTIVELY BUGGY AND BROKEN right now,” Torvalds exclaimed in 2022. “This is not some theoretical issue, but very much a ‘look, ma, this has never been tested, and cannot actually work’ issue, that nobody has ever noticed because nobody really cares.”

Basically, the user base for modern kernels on old 486 and early “586” hardware was so small that Torvalds no longer believed anyone was even checking whether up-to-date Linux even worked on those platforms anymore. Thus, any further development effort to quash bugs and keep these platforms supported was unjustified.

It’s worth acknowledging that Intel made its last shipments of i486 chips on September 28, 2007. That’s perhaps more recent than you might think for a chip that was launched in 1989. However, these chips weren’t for mainstream use. Beyond the early 1990s, the 486 was dead for desktop users, with an IBM spokesperson calling the 486 an “ancient chip” and a “dinosaur” in 1996. Intel’s production continued on beyond that point almost solely for the benefit of military, medical, industrial and other embedded users.

If there was a large and vocal community calling for ongoing support for these older processors, the kernel development team might have seen things differently. However, in the month or so that the kernel patch has been public, no such furore has erupted. Indeed, there’s nothing stopping these older machines still running Linux—they just won’t be able to run the most up-to-date kernels. That’s not such a big deal.

While there are usually security implications around running outdated operating systems, the simple fact is that few to no important 486 systems should really be connected to the Internet anyway. They lack the performance to even load things like modern websites, and have little spare overhead to run antiviral software or firewalls on top of whatever software is required for their main duties. Operators of such machines won’t be missing much by being stuck on earlier revisions of the kernel.

Ultimately, it’s good to see Linux developers continuing to prune the chaff and improve the kernel for the future. It’s perhaps sad to say goodbye to the 486 and the gaggle of weird almost-Pentiums from other manufacturers, but if we’re honest, few to none were running the most recent Linux kernel anyway. Onwards and upwards!

Apparently, Donkey Kong Country 2 has runs into a bug in the old SNES emulator ZSNES, where one of the barrels that you’re supposed to be able to precisely control the spinning direction of ends up spinning forever.

This bug is caused by ZSNES not emulating open bus behavior. I believe this was originally discovered by Anomie roughly two decades ago, who subsequently fixed the same bug in Snes9x. This original fix hardcoded the specific addresses to return the values that the game depends on rather than properly emulating open bus, but it fixed DKC2 and probably didn’t break anything else. The bug was never fixed in ZSNES, which is now a long abandoned project (last release in 2007).

Purely out of curiosity, I wanted to dig into this a little more to figure out what exactly in the game code causes these barrels to spin forever in an emulator that doesn’t emulate open bus behavior.

↫ jsgroth

Just in case you’ve always wanted to know.

With X.org being in maintenance mode, with the process of replacing it with Wayland accelerating pretty quickly now, a lot of projects using X.org are looking for ways to prepare for the future. Alpine Linux, a distribution focused on musl, BusyBox, and OpenRC, also wants to reduce its maintenance burden for X11 applications, and so Alpine Linux maintainer Ariadne Conill has come up with something interesting.

Wayback is an experimental X compatibility layer which allows for running full X desktop environments using Wayland components. It is essentially a stub compositor which provides just enough Wayland capabilities to host a rootful Xwayland server.

It is intended to eventually replace the classic X.org server in Alpine, thus reducing maintenance burden of X applications in Alpine, but a lot of work needs to be done first.

↫ Wayback GitHub page

It’s nowhere near done and most likely contains massive amounts of bugs and issues, but the seed has been planted. Wayback will make it possible to keep running X11-based desktop environments even in a full-Wayland environment. This may be necessary in case you need a specific feature not yet available in the Wayland version of your desktop environment, or if your desktop environment of choice simply isn’t going to move to Wayland at all (due to lack of maintainers or whatever).

It’ll also be a boon for retrocomputing, especially as over the coming years and decades unmaintained X11 desktop environments become become ever harder to keep running on modern Linux distributions. While X.org as it exists today certainly isn’t going anywhere any time soon, it will, eventually, stop working properly on Linux distributions who don’t ship it by default anymore, and it’s awesome to already have the beginnings of a project to address this problem.

The GPU in your computer is about 10 to 100 times more powerful than the CPU, depending on workload. For real-time graphics rendering and machine learning, you are enjoying that power, and doing those workloads on a CPU is not viable. Why aren’t we exploiting that power for other workloads? What prevents a GPU from being a more general purpose computer?

↫ Raph Levien

Fascinating thoughts on parallel computation, including some mentions of earlier projects like Intel’s Larabee or the Connection Machine with 64k processors the ’80s, as well as a defense of the PlayStation 3’s Cell architecture.

Lori Emerson is one of the few people really prominently writing seriously in a media studies/anthropological sort of way about the history of technology, and I constantly assert that there isn’t enough of that, so I’m excited to see a win.

I found her via the press for her first book, Reading Writing Interfaces, which is fabulous and thought provoking (and I only have a handful of quibbles with it, mostly around promulgating some of Apple’s dubious self-centering history that they seeded to writers and journalists in the 90s, even where she clearly knows better) and have followed her online posts as she prepared this one – We even interacted online once or twice in those; I’m acknowledged in her piece The Net Has Never Been Neutral that didn’t end up in the book because of a conversation we had online about how different parts of the audience would understand the world “Neutral” in subtly and problematically different ways when she posted an earlier version.

At a skim, Other Networks is much less densely academic and analytical than Reading Writing Interfaces; it really is a sourcebook of curated examples of technologies and instances of those technologies, with the necessary breadcrumbs to set up the interesting properties and comparisons with others. I’m a little disappointed that some of the deep musings about other ways the thing that is the Internet could have been largely didn’t make it in to the book, but, from an editorial view, they are different content for a different audience than what it ended up being.

It is also beautiful; the binding and the typesetting and the illustrations, right down to this lovely little foiled glyph on the back cover. My copy is sitting next to Marcin Wichary’s Shift Happens, which is a benchmark for beautiful books, and it looks good.