Image

Linux Kernel Drops AI Tag Requirement, Uses Meta AI For Code Reviews

Since we last covered the way that the Linux Kernel project has been dealing with the influx of code created using LLM-based coding assistants, all the way back in April, things have changed a lot, with most recently the Linux maintainers deciding to fully drop the requirement to mark LLM-assisted commits with the Assisted-by tag.

While not a fully uncontroversial decision – as also reported by Phoronix – with key maintainers already having made this decision it seems certain to proceed. This is not the only change made fairly recently, with a ‘Sashiko’ bot introduced that is supposed to handle code reviews.

In a July LKML post [Linus Torvalds] defends this decision, with a follow-up post in August by [Jakub Kicinski] it being stated that budget has been secured for using Meta’s LLMs, using said LLM-based resources for reviewing patches, as well as creating and editing commit messages. As noted by [Jakub] they’re running multiple frontier models on each patch to try and weed out confabulations.

Whether this will prove to be the right decision remains to be seen. Whereas most open source projects have firmly banished or heavily curtailed LLM-based contributions on slop, copyright as well as licensing grounds, the Linux Kernel project may be an interesting experiment in what the outcome of the exact opposite approach will be.

Image

Running Multiple Linux Kernels Without Hypervisor

In a move that’s no doubt going to trigger a lot of confusion and nostalgia, Mklinux is back, in a sense. As the announcement makes clear, this is multikernel Linux, not microkernel Linux, which is an experimental OS designed to run the Linux kernel as a user-space server running on top of OS X’s Mach kernel.

Naming overlap niggles aside, this neo-mklinux lets multiple independent Linux kernels run simultaneously on bare metal. There is still a host kernel which handles the carving up of hardware resources to the newly spawned kernels, but unlike with a hypervisor there are no abstraction or translation layers.

In theory this should mean basically perfect isolation between kernels, which is one of the main selling points along with increased performance. Compared to running KVM guests the provided benchmarks show much lower latency, at between parity to two times faster.

A website is provided with instructions to get started, along with architectural details if that’s your thing.

Image

Running Modern Linux On A 68008

Linux developers have been trimming the fluff in recent years, removing support for older processors that hardly anyone uses with a modern kernel anymore. With that said, it’s possible to run the latest kernel on some truly old metal. As a case in point, [Colin Maykish] just got it going on a Motorola 68008!

The rig in question is a Mackerel-68k—a homebrew single-board computer built around Motorola’s famous 68000 CPU line. This version in particular is running a 68008 rated at 8 MHz, though it’s overclocked to 14 MHz for a little more pep, and has just 3.5 MB of RAM. Despite these limitations, the board can run the mainline v7.1-rc6 kernel, booting into userspace and providing a very minimalistic BusyBox shell. Booting is slow, and doing much more than that is impossible without running out of RAM, but it’s an impressive feat nonetheless. [Colin] has also had the 68010 and 68030 chips running the kernel, too.

We’ve previously discussed efforts to bring Linux into the future while leaving old chips behind. Video after the break.

Continue reading “Running Modern Linux On A 68008” →

Image

Intel 486 Support Likely To Be Removed In Linux 7.1

Although everyone’s favorite Linux overlord [Linus Torvalds] has been musing on dropping Intel 486 support for a while now, it would seem that this time now has finally come. In a Linux patch submitted by [Ingo Molnar] the first concrete step is taken by removing support for i486 in the build system. With this patch now accepted into the ‘tip’ branch, this means that no i486-compatible image can be built any more as it works its way into the release branches, starting with kernel 7.1.

No mainstream Linux distribution currently supports the 486 CPU, so the impact should be minimal, and there has been plenty of warning. We covered the topic back in 2022 when [Linus] first floated the idea, as well as in 2025 when more mutterings from the side of [Linus] were heard, but no exact date was offered until now.

It remains to be seen whether 2026 is really the year when Linux says farewell to the Intel 486 after doing so for the Intel 386 back in 2012. We cannot really imagine that there’s a lot of interest in running modern Linux kernels on CPUs that are probably older than the average Hackaday reader, but we could be mistaken.

Meanwhile, we got people modding Windows XP to be able to run on the Intel 486, opening the prospect that modern Windows might make it onto these systems instead of Linux in the ultimate twist of irony.

Image

After Decades, Linux Finally Gains Stable GPIB Support

Recently, [Greg Kroah-Hartman] proclaimed the joyous news on the Linux Kernel Mailing List that stable General Purpose Interface Bus (GPIB) support has finally been merged into the 6.19 Linux kernel.

The GPIB is a short-range 8-bit, multi-master interface bus that was standardized as IEEE 488. It first saw use on HP laboratory equipment in the 1970s, but was soon after also used by microcomputers like the Commodore PET, Commodore 64 and others. Although not high-speed with just 8 MB/s, nor with galvanic isolation requirements, it’s an uncomplicated bus design that can be implemented without much of a blip on the BOM costs.

The IEEE 488 standard consists of multiple elements, with 488.1 defining the physical interface and 488.2 the electrical protocol. Over the decades a communication protocol was also developed, in the form of SCPI and its standardized way of communicating with a wide range of devices using a simple human-readable protocol.

Although the physical side of IEEE 488 has changed over the years, with Ethernet becoming a major alternative to the short GPIB cables and large connectors, the electrical protocol and SCPI alike are still very much relevant today. This latest addition to the Linux kernel should make it much easier to use both old and new equipment equipped with this bus.

Image

BCacheFS Is Now A DKMS Module After Exile From The Linux Kernel

It’s been a tense few months for users of the BCacheFS filesystem, as amidst the occasional terse arguments and flowery self-praise on the Linux Kernel mailing list the future of this filesystem within the Linux kernel hung very much in the balance. After some initial confusion about what ‘externally maintained’ means in Linux parlance, it’s now clear that this means that BCacheFS has effectively been kicked out of the kernel as [Linus] promised and will ship as a DKMS module instead. The gory details of this change are discussed in a recent video by [Brodie Robertson].

We covered the BCacheFS controversy in the Linux world a few months ago, amidst reports of data loss and filesystem corruption among its users. Its lead developer, [Kent Overstreet], came to blows with [Linus Torvalds] on the LKML after [Kent] insisted on repeatedly pushing new features into kernel release candidate branches along with rather haughty statements on why he should be able to do this.

To make a long story short, [Linus] didn’t like this and froze BCacheFS support in the current kernel release with all future in-kernel development ceased. Distributions like SuSE have initially said that will disable BCacheFS starting in kernel version 6.17, meaning that users of BCacheFS may now have to install the DKMS module themselves. Some distributions like Arch are likely to include this DKMS module by default, which is something you want to check if you use this filesystem.

Continue reading “BCacheFS Is Now A DKMS Module After Exile From The Linux Kernel” →

Image

What Does Linux Need? A Dial!

It’s fair to say that there can’t be many developers who have found the need for a rotary telephone dial as a peripheral for their Linux computer, but in case you are among them you might find [Stefan Wiehler]’s kernel driver for rotary dials to be of use.

It’s aimed at platforms such as systems-on-chip that have ready access to extra GPIOs, of which it will need a couple to service the BUSY and PULSE lines. There are full set-up instructions, and once it’s in place and configured it presents the dial as though it were a number pad.

We like this project, in fact we like it a lot. Interfacing with a dial is always something we’ve done with a microcontroller though, so it will be interesting to see whether it finds a use beyond merely curiosity. We can already see a generation of old-school dial IP phones using Linux-capable dev boards. He leaves us with a brief not as to whether Linus Torvalds would see it as worthy of mainline inclusion, and sadly however much we want things to be different, we agree that it might be wishful thinking.

If you’d like to use a dial phone, there can be simpler ways to do it.

Header: Billy Brown, CC BY 2.0 .