The Linux kernel is approaching a staggering 2,000 CVEs fixed per release, up from roughly 500 through much of the Linux 6.x era, as AI and large language models increasingly scour the operating system’s enormous codebase for vulnerabilities. According to an August 28 Phoronix report, Linux stable maintainer Greg Kroah-Hartman revealed the trend in a slide teasing an upcoming presentation at Kernel Recipes 2026, showing CVE counts jumping above 1,000 with Linux 7.0 and exceeding 1,500 with Linux 7.2. If the current trajectory continues, Linux 7.3 could push the figure beyond 2,000.

Rather than a change in Linux’s security or a rise in vulnerabilities, the spike is mainly due to “detectives” using AI tools to scour the Linux kernel source tree, which has grown to over 40 million lines over 35 years of Linux’s existence. These tools can examine countless obscure sections humans may rarely revisit, occasionally finding genuine defects; Linux CVE records this year already explicitly credit AI-assisted static analysis with finding vulnerabilities subsequently confirmed by Intel Product Security. However, many of the findings have been low-priority vulnerabilities — often within obscure driver code — questionable patches, and outright hallucinations, leaving human maintainers to separate useful work from noise.

This problem already constitutes a nuisance for kernel teams that have to fix these issues. In the Linux 7.3 networking pull request, maintainer Jakub Kicinski estimated that between one-third and one-half of the 648 net-next patches handled during the cycle appeared to be low-priority fixes, clean-ups, or clarifications driven by AI. "We are completely overwhelmed,” Kicinski wrote.

The issue has also led Linux maintainers to question whether decades-old drivers are worth keeping alive. In April, developer Andrew Lunn proposed removing nearly 28,000 lines of legacy networking code covering old ISA and PCMCIA-era hardware. While these drivers historically required little attention because they barely had any users, the AI and fuzzing tools started finding defects that maintainers were obligated to investigate and fix, regardless of whether anyone actually runs the hardware.

Linux 7.3 is removing old SGI and IBM driver code, while other ancient components have also been retired as maintainers reassess whether their compatibility value justifies their new maintenance cost. The FreeVxFS filesystem driver, for example, was removed after its maintainer said the decades-old compatibility code now largely served as fodder for automated bug checkers.

Now, the kernel community is not simply rejecting AI; Kroah-Hartman himself has successfully used locally-running AI-assisted fuzzing tools to uncover kernel bugs. The bone of contention is unverified AI output dumped onto humans for validation. Kroah-Hartman recently barred LLM-generated patches from the kernel’s staging subsystem except for legitimate security fixes, while updated kernel guidance warns that AI-generated reports submitted without human verification can waste maintainer time.

The team has also increasingly had to fight AI with AI. It has now secured access to multiple frontier models to help review patches and filter out hallucinated results, and is considering pushing more routine administrative work onto LLMs in subsequent development cycles. Kroah-Hartman is expected to discuss the trend further at Kernel Recipes, which is slated to run from September 21 to 23 in Paris. Linux 7.3 itself has already entered testing, with Linus Torvalds releasing Linux 7.3-rc1 on August 30 after closing its two-week merge window.

California’s legislature has passed Assembly Bill 1856, exempting open-source operating systems from the State’s Digital Age Assurance Act months before the law is due to take effect on January 1, 2027. The Senate amended the Bill on August 21 before passing it on the 26th in a 39-0 vote, with the Assembly then accepting these changes in a concurrence vote the following day. The amendment ends almost a year of uncertainty surrounding whether Linux distributions and SteamOS would be forced to collect user age data during account setup alongside Windows, macOS, iOS, and Android. AB 1856 has now been sent to Governor Gavin Newsom, who signed the original act into law last October.

These amendments redefine the term “operating system provider” to exclude any person or entity that distributes an OS or application “under license terms that permit a recipient to copy, redistribute, and modify the software.” Any software distributed under the GPL, MIT, BSD, and Apache licenses satisfies that test, which removes the likes of Debian, Fedora, Ubuntu, Arch, and the BSD family from AB 1856’s scope.

A second exclusion removes software components that aren’t “offered to consumers as a stand-alone executable application through a covered application store” from the law’s definition of an application, covering libraries and dependencies distributed through package managers like apt and pacman. AB 1856 doesn’t explicitly say that repos aren’t app stores, but a store’s main obligation under the law is to request an age signal from the user’s OS provider and pass it to developers; an exempt open-source OS produces no signal. A third carve-out excludes storefronts distributing extensions or add-ons that run exclusively inside a host application, which takes browser extension stores out of scope.

The amendments to AB 1856 also remove the original definition of “user,” which read, “a child that is the primary user of a device,” and technically classified every device owner in California as a child. The law’s signaling framework depends on adults declaring their age on account setup, so their devices get flagged as 18 and over, but under that definition nobody could ever be flagged as an adult.

In addition, lawmakers inserted a new provision prohibiting anyone from requesting an age signal from an OS provider or app store unless required by law. That closes off potential abuse of the age API that could have led to it being used as a general-purpose data collection channel even when age verification wasn’t required. Platforms and developers also gain a good-faith safe harbor against erroneous signals, protecting them from liability when age-gating signals are inaccurate.

Windows, macOS, iOS, and Android remain fully in scope, with age collection required at account setup from January 1, 2027. A later July 1, 2027, deadline applies to devices set up before January 1. Whether SteamOS is in scope isn’t yet clear: its Arch-based system components are open source, but Valve distributes the image alongside the proprietary Steam client. GrapheneOS, which in March said it would refuse to comply with age-verification mandates, is distributed under open-source MIT and Apache licenses and now falls outside the law’s scope entirely, though Brazil’s Digital ECA still applies to it.

Assemblymember Buffy Wicks, who wrote both the Digital Age Assurance Act and the AB 1856 amendment, introduced the exemption back in February following criticism from Linux developers and the Electronic Frontier Foundation.

The development of Linux, a free ‘hobby’ operating system, was announced by Linus Torvalds 35 years ago today. On August 25, 1991, the unknown computer science student noted that the budding OS had been “brewing since April, and is starting to get ready.” The first public release of this ‘Minix-like’ OS came the following month, and in a last-minute change by the co-worker who uploaded it, was distributed with the name Linux instead of Freax. In 2026, Linux powers everything from smartphones to supercomputers and oodles of products, like the Steam Deck, in between.

The above commemorative post celebrates Torvalds’ stewardship over the Linux project. However, it is also quick to make clear that “hundreds of maintainers and thousands of contributors” have been instrumental to making this free open source OS a competitive, capable alternative to corporate/paid software, which can “move computing forward for humanity.”

Since 1991, Linux has come a long way on its journey from its humble ‘hobby’ OS beginnings. What started as a kernel with roughly 10,000 lines of code has exploded into 40 million or more lines today. Torvalds was humble about the first release yet proud of features like its multi-threaded filesystem, and the first release being clear of any borrowed Minix code. But the countless contributors over the last 35 years have helped forge an enviable OS, which boasts capabilities and features that must make it a worrying foe for commercial rivals.

There are areas, outside our PC and gaming core, where Linux is actually the biggest fish by far. Industry stats suggest that nearly 80% of web servers, and virtually all of the world’s Top500 supercomputers run a flavor of Linux. It dominates mobile too, with nearly 4 billion Android devices running Linux-derived kernels. Then there are all those embedded systems, encompassing things such as routers to automotive MCUs – so many run Linux.

I feel that Linux has made significant progress towards the fabled ‘year of Linux’ over the last couple of years. Microsoft’s Windows has been its own worst enemy in some respects, pushing people away due to a multitude of concerns. Meanwhile, consumers can see that content creation, productivity, and gaming on Linux PCs are continuously improving.

There was a recent collective sigh of relief in the Linux world, too. Earlier today, we reported on news that the decades-long Linux ownership dispute was effectively killed after Xinuos’ appeal was rejected by the U.S. Court of Appeals. That ruling means much lingering uncertainty over Linux devices facing future licensing claims, maker settlements, audits, and/or forced software rewrites has been banished.

Linux kernel 7.3 is set to bring an oddly nostalgic update for 3dfx's Voodoo 3, one of the most recognizable graphics cards of the late 1990s. Don't get too excited; the venerable PCI-and-AGP accelerator isn't suddenly getting a modern Linux graphics stack, but the kernel's existing tdfxfb framebuffer driver is being updated so that it can initialize a Voodoo 3 itself rather than relying on the system firmware to have already run the card's video BIOS. It's a small change with a surprisingly specific purpose, and one that illustrates why ancient hardware occasionally gets attention in contemporary Linux.

The problem is that the tdfxfb driver historically assumed that the Voodoo card had already been initialized by the PC's firmware. That's because, at the time it was written, that was a reasonable assumption on a conventional x86 PC. The system firmware would execute the card's video BIOS during boot, configure the hardware, and then hand Linux something that is already capable of displaying an image. That assumption breaks down on newer and unusual platforms where the firmware cannot or does not execute the VGABIOS. The creator's patch description specifically calls out non-x86 computers, systems where another graphics card is primary, and newer BIOSes that can't run the old video BIOS.

The developer behind the patches, Daniel Palmer, was using a Voodoo 3 in an Amiga 4000 equipped with a PCI bridge when the problem cropped up. Linux could detect the card, but the Voodoo was still completely uninitialized, leaving him staring at "no signal detected." The new code uses configuration information from the card's own video BIOS to perform the initialization from Linux instead, allowing the driver to bring the VGA core up and establish a working display without depending on the system firmware. For now, the new manual initialization code is specifically aimed at the Voodoo 3; he had initially noted support for the VSA-100-based Voodoo 4 and 5 cards, but their BIOS layouts are different, so that support was removed from the current patch series. The code has been tested on both a modern x86-64 system and an Amiga 4000 with a Mediator PCI bridge.

On a conventional modern-ish x86-64 PC with a Voodoo 3 installed, the practical result is fairly modest. Load tdfxfb and you can get a working Linux framebuffer device, typically exposed as /dev/fb0, with the Voodoo driving a display that can host the Linux virtual console. In other words, this is enough to turn the Voodoo from "a PCI device that Linux can identify" into an actual display adapter capable of putting pixels on the screen even when firmware didn't initialize it first. Applications that know how to use the Linux framebuffer interface can also draw to it, just as they could with other old framebuffer devices.

The thing is, that's also where the limits of this work become apparent. Linux fbdev is a legacy graphics interface and has long been superseded by Linux's DRM/KMS graphics infrastructure, so this ain't a resurrection of the Voodoo 3 as a contemporary Linux GPU. Loading tdfxfb does not give you a Mesa stack, modern OpenGL, Wayland acceleration, or the sort of 3D functionality you would expect. It is essentially a very old-fashioned "squirt pixels at the display" arrangement, but that's useful enough for a Linux console, embedded-style framebuffer applications, and, apparently, people putting exotic PCI graphics cards into even more exotic old computers, but it's not exactly a compelling reason to install a Voodoo 3 in a modern desktop.

The more interesting part is that Palmer is working on a separate 3D path for the Voodoo 3, and that effort is already much further along than the framebuffer work alone might suggest. The experimental interface exposes the Voodoo's register space to userspace through a new /dev/tdfx3d misc device, whose mmap() interface allows software to program the card's 3D hardware directly. On top of that sits smoltdfx, a tiny userspace library for driving the Voodoo 3, and smolminigl, a small OpenGL 1.x implementation built on top of it. Palmer says he has tested the project on real Voodoo 3 hardware and that it can render directly through the card's registers without X, Mesa, or Glide.

Palmer is developing that work alongside a QEMU emulation of the Voodoo 3. The developer says Claude helped build the emulator in the first place to debug the issue of getting the card working on his Amiga. Now, test programs can be run against both the emulated card and the real hardware, with differences fed back into the emulator until the behavior matches. The smoltdfx project now uses the same rendering tests against QEMU and physical Voodoo 3 hardware, comparing frame digests to catch differences. According to Palmer, the resulting MiniGL implementation can already run Quake on the real card, although performance isn't great, and some issues with the Voodoo 3's multitexturing capabilities remain to be worked out.

Obviously, that's a lot more interesting than simply putting a Linux console on a Voodoo 3. The sum total is a highly experimental 3dfx graphics stack built from the bottom up: Linux provides the framebuffer and low-level device access, userspace programs the Voodoo directly, and a lightweight OpenGL implementation sits above that to provide enough functionality for classic 3D software to command the card.

Indeed, things could get particularly fun for retro-computing and virtualization. A PCI Voodoo 3 is the sort of device that, at least conceptually, could be assigned to a virtual machine using PCI passthrough, letting a guest operating system talk directly to the real accelerator with its period-accurate 3dfx driver. In the fantasy version of that setup, you could have a modern Linux host hand an actual Voodoo 3 to a Windows 98 or DOS-era guest and then let the guest use the very same hardware that the old software expected. The engineering details are much nastier than the concept suggests (particularly around resetting and exposing such old hardware cleanly), but the new ability to initialize an otherwise-dormant Voodoo from Linux is at least a useful piece of that puzzle.

For now, though, the headline is more significant than the immediate feature set. Linux 7.3 isn't suddenly turning a 25-year-old Voodoo 3 into a usable GPU; it's making an existing framebuffer driver capable of bringing the card to life on systems where firmware cannot do the job, which is a very small but very real hole in hardware support. More remarkably, the same effort has already spilled into experimental 3D acceleration on real hardware, with a userspace Voodoo 3 library and an OpenGL implementation capable of running Quake. Voodoo 3 may be over 25 years old by now, but somebody is still teaching Linux new tricks with it in 2026.

Xbox PC games, distributed through the Xbox app, fail to run on Linux because of Microsoft's proprietary GDK runtime environment. This also breaks Game Pass even though the company supports cloud streaming Game Pass titles. A new open-source project from the developers of Heroic Launcher, called "Xodus," is aiming to fix this by reverse engineering and emulating the necessary components required for Xbox PC games on Linux.

Xodus primarily targets modern, GDK-based Xbox PC titles and their MSIXVC packages; not older, UWP-based releases like Gears of War 4 and early Forza Horizon games. The problem with those isn't the DirectX API or x86 instructions; Proton and DXVK/VKD3D can already translate those. That's also the reason why you can still run Xbox PC games on Linux if you somehow get your hands on the DRM-free executables.

The real issue is the trifecta of Microsoft's proprietary GDK (Game Development Kit), Xbox identify services, and encrypted MSIXVC packages. This framework is responsible for verifying licenses for the games you own through the Xbox app. Without it running in the background, the games will simply crash right as you try to open them, or not launch at all. This is where Xodus comes into play.

The Xodus team says the project can already log into Xbox services, download game packages and obtain game licenses. It includes its own open-source implementation of the xgameruntime.dll and custom forks of both Wine and Proton, along with xal-rs, which is an Xbox authentication library for Rust. Xodus uses proxy libraries to interface with GDK games and intercepts API calls to transmit valid Xbox Live tokens.

For now, efforts are focused on emulating the Xbox Gaming Runtime from the Xbox GDK through Wine, then the project will move on to actually launching and playing Xbox PC titles locally. Considering they've already solved the Xbox/Microsoft authentication, license check, and package decryption hurdles, it shouldn't be long before we see PC Game Pass running natively on Linux.

BedrockonLinux 2.0, another open-source project that brings Minecraft Bedrock to the platform, already relies on similar reverse-engineering tech to handle these components since Microsoft migrated the game to GDK. This allows the game to talk to Xbox Live in real-time through a secure doorway to authenticate tokens despite the game running in a sandboxed environment like SteamOS (Linux).

Microsoft itself brought four original Xbox titles to PC last month and it says more are coming, along with leaked documents suggesting Xbox 360 titles also releasing on PC next year. These games come with a baked-in Xbox 360 emulator. It's not clear if these games use the same GDK stack as native Xbox PC titles, however.

The Steam Machine helped grow the popularity of Linux gaming, including installations of Bazzite and other gaming-oriented Linux distributions. Valve seemingly doesn't want to stop its open-source development efforts anytime soon, and is now working on a port of the Mesa Radeon Vulkan driver (RADV) to Windows; It's already running Counter-Strike 2, according to developers at Collabora.

As cross-platform development is rather tricky, Valve opted to get a port of RADV to Windows going by way of sponsoring contractors at Collabora. In its blog post, Collabora explained the several hoops it had to jump through to accomplish this task.

With Windows 10 and WDDM 2.0, Microsoft improved the split between graphics drivers' userspace code (the vast majority of the driver itself) and the kernel-level portion that actually talks to the graphics card. This presented the opportunity to hook RADV to the AMD kernel card driver. That's easier said than done, however, as communication between those parts often carries non-standardized data that RADV needs to understand. And to understand the "conversation," it needs to be recorded and analyzed.

An earlier 2024 effort by Faith Ekstrand yielded a basic-but-valuable utility for logging WDDM 2.0 calls and reverse-engineering them to produce a basic RADV implementation. Out of both debugging necessity and as a development tool, Collabora built and expanded upon Ekstrand's work, improving the logger to the point where it can now fully analyze any Vulkan application that runs with AMD's official driver and dump all the data passing to the kernel.

After a lot of work getting to grips with how the AMD driver interacts with the kernel driver, including but not limited to reverse-engineering obscure data structures, the team made progress, and Windows RADV is now able to run some games, including Counter-Strike 2.

Despite the ongoing effort, Collabora explains that since user- and kernel-space driver are a matched pair, changes to those aren't guaranteed to be backwards-compatible, meaning that even a fully functional RADV could break at any point. For that reason, Collobora is requesting that AMD, Microsoft, or both provide a documented interface to the kernel driver or an intermediary compatibility layer.

AMD graphics driver development on Linux has coalesced around the Mesa Vulkan stack, with both company and community devs contributing to the RADV project. Over in the Windows world, the only option is AMD's proprietary driver, which can cause a lot of headaches when developing cross-platform games and applications.

AMD's Vulkan driver for Windows has developed a reputation for instability. Meanwhile, Linux RADV is generally praised for its stability and performance, sometimes running faster than the AMD Windows driver, especially on older cards. With a rapid development schedule, it also generally sees fixes and speed upticks often.

If at some point using RADV on Windows becomes viable, you'd be getting an arguably more stable, mature driver with active development. Games' graphical issues could become far easier to debug and patch thanks to the open nature of RADV, and studios developing with Linux in mind can target the one platform instead of two with different behaviors. Any developer or company can contribute to the project, too.

Furthermore, this lets Valve improve Windows compatibility layers, and any optimizations can be carried over to both operating systems. All told, this is likely one of the several moving parts to improve Linux — thus the Steam Deck, Steam Machine, and upcoming hardware — as a viable gaming platform. Even a future notion of gamers installing RADV on Windows to get a performance or stability boost isn't too far-fetched.

Additionally, RADV on Windows would also help keep discontinued cards usable, and given pricing right now, that certainly would be a good thing.

AI-generated slop code has been a plague for some open-source projects, namely but not only Gentoo Linux, Curl, and Ghostty, limiting or outright banning LLM-created contributions. And yet, just like both the models themselves get better and the people using them become more considerate, the landscape may be changing. Linus Torvalds, Linux's creator and kernel manager, has seemingly taken an accepting stance of AI-assisted tooling.

In a long comment on the Linux kernel mailing list, Torvalds spelled it out fairly clearly: "I realize that some people really dislike AI, but this is an area where I'm willing to absolutely put my foot down [...] Linux is not one of those anti-AI projects, and if somebody has issues with that, they can do the open-source thing and fork it. Or just walk away."

This discussion came regarding the usage of Sashiko, an opt-in (per-mailing-list) and apparently quite effective multi-stage code review tool that analyzes kernel patches. The project page says the tool can find 53.6% of bugs on proposed patches, and argues that that metric already puts it above human level, as the patches in question already supposedly went through human review. The false positive rate "is harder to measure," being pinned "within 20%." Crucially, Sashiko only comments on patches, and does not take action by itself.

Developer Laurent Pinchart suggested that Sashiko's output be triaged before comments were sent out to patch authors, basing the notion on the Software Freedom Conservancy's guidelines on AI-generated code. Google's Roman Gushchin, one of Sashiko's creators, pointed out that doing that would undermine the utility of the tool, and that Pinchart's position was quite anti-LLM — a sentiment echoed by Linus Torvalds in his reply.

Torvalds put it clearly: "AI is a tool, just like other tools we use. And it's clearly a useful one. It may not have been that 'clearly' even just a year ago, but it's no longer in question today," a statement that reflects his changing stance on the matter since he initially dismissed AI tools as overhyped back in 2024. He also noted that Linux is not a "social warrior" project, and that it's always been about improving technology.

To drive the point home, he remarked that the tool "keeps finding embarrassing bugs," adding that he "will very loudly ignore people who try to argue against other people from using it," while highlighting the software's rapid evolution.

Perhaps quite poignantly, Torvalds remarked that resistant developers could use some self-awareness, as "it's not like natural intelligence is always all that great either," underscoring the fact that while AI tools may not be perfect, they generally only need to be good enough for their respective use cases. The fact that Sashiko seemingly finds errors in code that underwent human review is quite illustrative.

The adventurous developer who recently released Linux for the Atari Jaguar (1993) has brewed up a version of the open-source OS for the Sega 32X (1994). If you can’t remember the 32X, it was Sega’s mid-gen answer to early fifth-generation challengers like the Jaguar, 3DO, and Amiga CD32. Sega’s solution added some potent processing power to a mushroom-like slot in an expansion to its popular Mega Drive/Genesis. Now cakehonolulu has got it running Linux, despite facing several major hurdles.

Compared to its Genesis host, the Sega 32X was incredibly muscular. The Genesis had relied on the capable but long-in-the-tooth Motorola 68000 (7 MHz) for years, but the 32X add-on boosted that with a pair of Hitachi SuperH SH2s (SH7604) CPUs (23 MHz). It also ramped up system RAM from the base 64KB by adding 256KB of its own. Sega’s expansion offered more than just speed; the console’s color palette was ramped up from 64 to 32,000 simultaneous colors on screen, and it was powerful enough to introduce hitherto unachievable 3D graphics elements to mainstream console gaming.

As with cakehonolulu’s tale of Linux wrangling on the old Jag, the above-linked blog talks through a long list of hurdles that needed to be leapt to get the Linux kernel booted and running BusyBox. This time around, particularly steely roadblocks included: the even more constrained RAM situation, the lack of hardware synchronization primitives, the desire to get SMP working across the pair of SH2 CPUs, no direct UART access from the 32X, and scheduler bugs, among other things.

On the positive side, smoothing the development process along were access to Chilly Willy’s 32X devkit, the linuxmd project, the Krikzz FPGA-based flash cart with ROM – RAM mapping tools, and existing SH2 documentation and sample projects. Please check through the linked blog for far more technical details from cakehonolulu.

As you can see, cakehonolulu was successful again. So, what’s the next stop for this adventurous dev – the Sega Saturn? Whatever the project may be, it was interesting to read that works like this are basically forming a portfolio for the Spanish dev, which they hope will help them with job hunting.

A set of updates for Sega Dreamcast hardware has been merged into the Linux 7.2-rc3 kernel this weekend. Dmitry Torokhov submitted updates addressing the legendary console’s input subsystem and Linus Torvalds merged them on Saturday. The updates even surprised Linux-focused site Phoronix, That’s probably due to context: the Dreamcast continues to enjoy support while admittedly older but real computing hardware like the i486, PowerPC 40x chips, DEC Alpha, and Itanium / IA‑64, have all been sidelined in recent times.

In brief, the updates should mean new versions of Linux will come with more stable mouse, keyboard, and joystick drivers for Dreamcast stalwarts. If you are one of the Dreamcast faithful, still satisfying your computing (and gaming) needs on the final original consumer gaming hardware from Sega, this is good news.

Reading the pull request we can see some details about the new drivers for the Dreamcast’s Maple‑bus peripherals (mouse, keyboard, controller). Specifically, there’s a “fix for a crash in Sega Dreamcast (Maple) mouse driver when opening the device, caused by missing driver data,” as well as “Fixes for Maple drivers (keyboard, mouse, joystick) to properly order setting driver data and device registration to avoid races.” In this context races refers to things happening in the wrong order to result in crashes: it’s a timing bug that’s now been quashed.

Dreamcast hangers-on will now be able to craft specialized Linux builds on CD-R for their machines. The maplemouse driver has had the now-fixed crash-inducing bug since 2017.

Phoronix also comments that Linux kernel fixes for the GD-ROM driver used by the Dreamcast and a proposal for the VMUFAT file-system driver were also seen this year.

The Sega Dreamcast launched at the end of 1998 (in Japan, and the following year in the U.S.). So, in some ways it isn’t that surprising that it is still getting Linux kernel updates when the Intel i486 (1989) has been retired from mainline support. But one might have expected stronger demand for supported Linux distributions among i486 desktop and laptop users.

A Spanish systems software developer has ported Linux to the Atari Jaguar console. To succeed at the task, cakehonolulu had to overcome severe memory limits, the lack of a memory management unit (MMU), and face off against a handful of unusual hardware quirks. A blog post from the dev tells us about the work to port Linux to this ill-fated 1993-launched flop, and happily ends in evidence that a working Linux kernel and BusyBox command line shell can be booted on the old Jag. Now Linux runs on both your cherished real hardware via cartridge, or in a Jaguar emulator.

Anyone wishing to port Linux to the Atari Jaguar would face numerous constraints due to the hardware. One of the first hurdles successfully leaped by cakehonolulu was the CPU used. Atari’s system designers architected the Jag using a Motorola 68000 CPU, which was already pretty old at the time, but a moderately fast 13.3 MHz version was selected. Though the gaming prowess of the console was lifted by custom co-processors dubbed Tom & Jerry, some games didn’t make much use of this graphics and DSP acceleration, as it was notoriously difficult to tap into.

For this Linux port, the general CPU capabilities of the M68000 would also be targeted to run the OS. With that in mind, and knowing that the CPU lacked an MMU, cakehonolulu was lucky to find that classic Motorola 68k processors are still supported by Linux, and also the uClinux project, which allows Linux to run on MMU‑less systems like the Jaguar.

While these prior works were helpful, it wasn’t long until the linux_jag developer needed to battle with other Atari Jaguar constraints. The console comes with just 2MB of RAM and up to 6MB of ROM, which is incredibly miserly compared to even the cheapest microcontrollers and SBCs nowadays. Much RAM and storage optimization later, cakehonolulu tripped over a few issues getting Linux to boot on the Jaguar, and ended up implementing a console driver for Tom so the OS would work on real hardware.

A brief Atari Jaguar history

Atari’s Jaguar was released with great pride by the iconic video game company in 1993. It was controversially claimed to be the world’s first 64-bit console, but it still never managed to push aside incumbent previous-gen machines from Sega (Genesis / Mega Drive) or Nintendo (Super NES).

The mass market had enough patience to largely ignore the first wave of ‘early fifth-generation consoles’ like this, the 3DO, and the Amiga CD32. They were rewarded handsomely with the launch of the true accelerated 3D gaming next-gen wave, led by the Sega Saturn (which also used an M68000 CPU, alongside co-processors), Sony’s first PlayStation, and the Nintendo 64.

History can be a little unfair to the Atari, though, as it did have some eye-popping for the time original games and ports. I owned the original console with Alien vs. Predator (1994), and it was quite a stunning, tense, and scary game. Others thought the Jag’s Tempest 2000 was a killer app. In addition, there were strong Doom and Wolfenstein 3D FPS ports from the PC.

No need to pinch yourself — it is, in fact, 2026, and there was a court hearing last June 22 about IBM allegedly using copyrighted source code in Unix-like products, yet again for the umpteenth time since 2003, a saga that's part of the Unix wars.

For historical context, Xinuos (formerly SCO) and IBM have been embroiled in legal battles for decades, as the companies cooperated between 1998 and 2001 on developing an Itanium variant of Unix. Since then, SCO has repeatedly and dramatically taken IBM to court, claiming the defendant misused SCO-owned source code from the collaborative effort in its AIX and z/OS products, as well as Linux. Many battles have been fought over who owns the "Unix" name, what code IBM put in Linux, and even FreeBSD.

The latest hearing pertains to a 2021 lawsuit by Xinuos, the company that acquired the remnants of Santa Cruz Operations, more commonly known as SCO. Xinuos' CEO reportedly once stated the group didn't purchase SCO just to acquire the right to sue IBM, but the company eventually changed its mind in 2021 and dragged IBM back to court on claims that its conduct and copyright infringement resulted in great damage to Xinuos' market position.

Xinuos picking a fight with a team of lawyers colloquially known as the Nazgûl is questionable on its own — yet, in the aforementioned 2021 lawsuit, Xinuos added bold claims, such as stating that IBM's purchase of Red Hat should be reversed under antitrust law, and that the company's strategy in said acquisition was to destroy FreeBSD — the variant underpinning Xinuos' wares.

How, exactly, an MIT-licensed operating system would be "destroyed" is an interesting matter. Xinuos stated at the time that "IBM and Red Hat have abused their control over the Unix/Linux operating system market for far too long." One wonders if Linux users with hundreds of distributions at their disposal would agree that IBM has been pulling their strings all along.

The lawsuit dragged on until 2025, when Xinuos voluntarily chose to drop the antitrust claim (presumably after finding little purchase from the court). It also found itself disabused of the merits behind the copyright complaint, as the New York judge in question framed the claim as time-barred: too long had passed for Xinuos to file a complaint, and original ownership of the code is murky at best. Darl McBride, the SCO executive who launched the original lawsuit, passed away from ALS in 2024.

Xinuos did, however, press on with the copyright issue and requested a hearing for an appeal. And on June 22, 2026, the firm argued in front of a three-judge Second Circuit panel that the previous judge miscast a copyright infringement claim as an ownership claim.

Say whaaaat? Hannah Montana Linux is back. The distro made as a tribute to the noughties Disney Channel sitcom for tweens and teens, featuring the eponymous secret pop star, was basically abandoned in 2009. Now it's back, with a modern kernel and about 18 years of patches, with the release of the Hannah Montana Linux v26.0 remaster by developer Noah Cagle.

Little is known about why the original Hannah Montana Linux was developed, released, and almost immediately abandoned. The version available via Archive.org is the only known release, identified as Hannah Montana Linux x86 basic edition 202201. It is still available if you’d like to test out a frozen-in-time HM-themed version of Kubuntu. You can grab it as a 691.7MB download via the link provided. Be warned that it is now “basically unusable,” though, according to Cagle, due to being insecure and for its poor software support.

Fast forward to the present day, and Cagle’s HML26 release solves all the issues with the old distro. Browsing the modern web is possible and safe, finding and installing software is easy, and the dev has even made the terminal look pretty.

In the video feature about the release of Hannah Montana Linux v26.0, Cagle provides some insight into how this version of the OS was customized, built, and released. After initially considering the Cubic GUI wizard for creating customized live ISO images of Ubuntu and Debian-based platforms, the developer decided to go with Live Build, an official tool for Debian-based distros.

We then get a walkthrough of using this tool to make a Pretty in Pink version of Debian Linux. Briefly, a lot of the work required to make a distro like HML26 is adding various files and references into a set folder structure, and then building the Linux ISO. Most of the custom imagery and iconography sit in an includes.chroot directory.

Key customized elements would include an icon pack, color scheme, and wallpapers, and they were largely built by cloning and then editing existing theme resources. The main wallpaper looks a lot like the original, and that’s because it uses the original PNG as a source, updated by Cagle to 16:9. The cherry on the cake, though, might be the stylized ‘H’ start button.

When Cagle was happy with his customizations, he sought out a way to transform the ISO from being a live-CD only so it could offer an install option. This final step in creating HML26 was done with a tool called Calamares. This app is strong in applying branding, so it was a great choice for a professional revival of Hannah Montana Linux.

You can download and try out Hannah Montana Linux v26.0 now, with the ISO available at the above-linked GitLab page under GPL 3.0. You’ll want a system with at least 8GB of RAM to enjoy this OS. Those with older machines might want to look at HML26 Lite, which switches KDE Plasma 6 for the lightweight LXQt.