VS Code has been quietly appending a Co-authored-by: Copilot line to users' git commits, including ones written entirely without Copilot's involvement.
The culprit behind this, git.addAICoAuthor, is a feature that was introduced in VS Code 1.110 back in March. It is designed to tag commits with a Copilot co-author trailer when AI-generated code is involved, and it launched with off as the default.
So far good, right? 🙂
That changed in April, when Courtney Webster, a Product Manager at Microsoft, submitted a pull request that changed one thing, the default value of git.addAICoAuthorfrom off to all.
The PR was reviewed and merged by VS Code team member Dmitriy Vasyura on April 16, without a release note or any kind of user-facing notification.
The all setting is the broadest option available for git.addAICoAuthor, which added the Copilot trailer to every commit involving any AI interaction, including inline completions.
With the default flipped to all, anyone who had not manually configured the setting was suddenly getting Copilot credited in their git history.
Things got messier from there. Developers reported that the credit info (trailer) was appearing even with chat.disableAIFeatures set to true. The trailer is also appended after the commit finalizes, not appearing in VS Code's commit message editor beforehand, so there was no window to catch and remove it before it showed up in git history.
One developer replaced Copilot's generated commit message with one they wrote themselves, committed, and still found the Copilot co-author line sitting in their log.
Dmitriy, the VS Code team member who merged the original PR, came forward on Hacker News over the weekend under the username dmitriv, specifically to address the fallout.
Identifying himself as the person who approved the change, Dmitriy said that he was sorry for mistakenly turning on this feature by default without sufficient scrutiny.
Also clarifying the following before the conspiracy theories started emerging:
There was no ill intent by evil corporation, but rather a desire to support functionality that some customers expect of VS Code w.r.t. AI-generated code. As folks mentioned here - many similar tools do this as well.
The fix, now live on VS Code's GitHub repo as PR #313931, reverts git.addAICoAuthor back to off by default and corrects the detection issue that caused the trailer to appear even when Copilot was not in use.
You can expect this change to land with the upcoming VS Code 1.119 release.
OpenSource Science B.V., better known as OS-SCi, is a Netherlands-based institution that has a pretty specific focus. To train the next generation of developers exclusively on Free and Open Source Software (FOSS).
If the outfit still sounds unfamiliar, you are not alone. OS-SCi doesn't get a lot of coverage, even in FOSS circles. They are primarily education-focused, operating out of their Tilburg headquarters and working with universities to integrate open source into formal curricula.
They also run FOSSTech, a separate arm that delivers open source IT solutions to organizations. So it's not purely a school; there's a consultancy side to them too.
All that context matters, because OS-SCi is about to host something that might interest quite a few of you.
✋
OS-SCi refers to this event interchangeably as "Lomiri Tech Meeting," "Lomiri CodeFest," and "Lomiri Hackathon" across their own websites. We use "Lomiri Tech Meeting" throughout this article.
As always, independently verify event details and the organizer before attending.
Lomiri Tech Meeting
The Lomiri Tech Meeting is a two-day, free hackathon aimed at students who want to get hands-on with open source mobile development. The focus is building apps for Lomiri and Ubuntu Touch, the mobile OS maintained by UBports.
Two keynote speakers are confirmed. Mike Gabriel, the project leader behind Lomiri's user interface, will be speaking. So will Erik Mols, who will use the event to announce the Lomiri Bounty Program, a new initiative that would offer students real-world incentives to contribute to the Ubuntu Touch ecosystem.
Every student who attends will be given free copies of Lomiri App Development Level 1 and Level 2. These are from a three-volume series that covers the platform's foundational concepts along with advanced procedures.
Beyond the keynotes and books, the event is built around hands-on app development sessions guided by experts. The goal here seems to be that attendees leave having actually built something and not just sat through some presentations.
Event Details and Registration
The Lomiri Tech Meeting is open to students of all experience levels and will run from May 16 to 17, 2026, kicking off at 10:00 AM each day and wrapping up at 4:00 PM on the 17th.
The venue is OS-SCi's headquarters at Spoorlaan 400, Tilburg, Netherlands. You can find it on OpenStreetMap and Google Maps.
It sits very close to Tilburg's main train station (Station Tilburg), which makes it fairly straightforward to reach by rail. The building also appears to have some level of wheelchair accessibility, but I recommend confirming that directly with OS-SCi before making travel arrangements.
Earlier this year, the Linux Mint project announced a significant shift in how it shipped releases, hinting at a longer cycle.
Project lead Clement Lefebvre had pointed out that the existing pattern of a new release every six months, on top of maintaining LMDE, was leaving the team spending more time on testing and release management than on actual development.
By March 2026, a decision had been made, with Linux Mint 23 now targeted for a Christmas 2026 release, making it the longest gap between major releases the project has seen.
The next release will be based on Ubuntu 26.04 LTS, will drop the long-used Ubiquity installer in favor of the live installer from LMDE, and ship with a functional Wayland session.
But the thing is, a longer wait works fine for existing users on a supported install. The problem is anyone trying to install Mint on very new hardware, where Linux 6.14 in the January ISO may not have the support they need.
To tackle that, the developers have introduced a new ISO that looks to improve compatibility with newer hardware.
What's happening?
Linux Mint has published HWE ISO images for Linux Mint 22.3, where HWE stands for Hardware Enablement, and these are distinct from the regular Mint 22.3 ISOs. These ISOs ship with Linux kernel 6.17 instead of Linux 6.14 the original images came with.
Don't think that these are new releases; rather, the HWE bit ensures that you get support for newer hardware, while the underlying system remains Linux Mint 22.3 in every way, fully put through the Mint team's QA process.
The team also plans to keep this up, publishing fresh HWE ISOs each time a newer kernel lands in the package base. So the waiting period until Mint 23 in December should not leave new hardware users without a compatible release.
For context on how kernels work in the 22.x series: the LTS kernel at 6.8 is what Mint 22 and 22.1 came with, while Mint 22.2 and 22.3 moved to the HWE track, starting at 6.14 and now sitting at 6.17. Either way, both tracks get security updates and are actively looked after.
If you are already running an up-to-date Linux Mint 22.3 install, you are likely already on kernel 6.17 and do not need to touch the HWE ISO. The images are primarily useful at the installation stage, for machines where the regular ISO will not boot or install cleanly due to hardware compatibility concerns.
Who's this for?
Very new laptops and desktops with components that require a kernel newer than 6.14 will need the HWE ISOs. Of course, if the regular ISO works fine on your machine, then there is no reason to look at the HWE version.
There is also an important caveat worth flagging before you reach for one. The Linux Mint folks specifically call out NVIDIA, Broadcom, and VirtualBox users as instances where things can get complicated since proprietary and third-party modules can run into compatibility problems on newer kernels.
The HWE ISOs are listed on a dedicated page, which currently shows the Linux Mint 22.3 HWE ISO with Linux 6.17. The page includes an extensive list of mirror links across North America, Europe, Asia, Africa, and South America, so a fast download source should not be hard to find.
Choice is one of the hallmarks of Linux, to the point that both “distro fever” and “distro fatigue” are alive in equal measure. Historically, Ubuntu has also been known the same. Different stroke for the wide range of folks who make Ubuntu their Linux home. Many of us see this wide selection of choices as a plus, and with good reason: we get to pick and choose our exact experience and tailor it to our needs.
Ubuntu’s flavour ecosystem has long reflected this ethos rather well: Don't want GNOME? Use Kubuntu. Need something lighter? You can choose Xubuntu or Lubuntu. Need something more specialised? Take your pick of Edubuntu, Ubuntu Studio, and others. On paper, it’s the Linux philosophy of choice perfected.
But there comes a point where adding more official flavours stops feeling like a strength, and starts raising a more uncomfortable question: how many of these options still make sense as official Ubuntu projects? Because fewer official flavours is healthier than keeping an inflated list of under-resourced projects alive just for the sake of it. We need less scattering, and more mattering.
Choice itself isn’t the problem: clarity is
There are currently 10 official flavours listed on the "Ubuntu flavors" page
Before I continue, it’s important for me to clarify one thing: I’m not arguing against choice itself. I’m making a case for greater clarity. Choice properly *applied*, not just translated to availability. After all, choice is one of the very reasons we choose Linux over other options. We want the ecosystem within the ecosystem, and we’d be lost without this flexibility.
Ubuntu is still arguably the best-known Linux distribution outside the Linux community itself. For many people, it is the first distro they hear of, the first one they search for, and often the first one they install. That visibility matters, and it can carry almost anything to a higher echelon just by association. It also means Ubuntu has a different responsibility from smaller, newer, and more niche projects.
Without meaning, choice gets noisy
It’s important to understand that the problem isn’t that Ubuntu offers different flavours overall, but that some of these choices can be difficult to justify, maintain, and uniquely define over time. A newcomer landing on the Ubuntu Flavours page isn’t thinking about packaging work, release engineering, or maintainer burnout. They’re thinking something much simpler: Which one am I supposed to choose?
The more crowded that menu becomes, the more likely it is that the answer starts to feel murky, especially if the defining characteristics of any particular flavour are harder to distinguish from another. This doesn’t mean that Ubuntu should strip away all variety and become a one-size-fits-all distro. That would only violate the key foundation that’s made Ubuntu successful in the first place.
What it does mean, is that the official choices should “Just make sense” overall.
“Official” carries a greater set of expectations
When most users hear the word “official”, it introduces connotations and ideas that can’t (or at least shouldn’t) be easily ignored. This is where the conversation becomes less about desktop preferences and default apps, and more about polish, user experience, and sustainability.
An “official” Ubuntu flavour isn’t just a remix with its own logo and download page. Ubuntu’s own ”RecognizedFlavors” wiki page makes it clear that recognised flavours are expected to have maintainers, participate in the official release cycle, follow QA coordination and bug tracking, and must have developers with the right access and experience to help keep things working across the release cycle. That’s a lot more than building a custom ISO that some people might like.
Being blessed with “official status" is not a free ride
The same page also makes it clear that Canonical does not simply take care of everything for these official flavours. There are limits around testing, upgrades, packages outside the main Ubuntu images, along with broader support obligations. So while flavours benefit from the wider Ubuntu base, being official still comes with a real maintenance burden.
This matters because community resources aren’t infinite, no matter how large or passionate the community. There are only so many developers, packagers, testers, documenters, and maintainers actually doing the work that makes a distro possible, and some actually devote their time and investment to multiple projects at a time. Every additional official flavour draws from this limited pool of active contributors, and demands a greater collective attention.
Therefore, it’s about way more than just giving end users more options. It’s another project (or set of projects) that needs ongoing attention, another arena for upstreams to pay attention to, another release that needs to be kept healthy, and another experience that has to reflect the image of Ubuntu well. Once you look at it that way, just adding more flavours sounds way less appealing without adding the robust backing needed to make them possible.
Passion and enthusiasm don’t automatically become maintenance
Ubuntu GNOME is no more, despite providing a purer GNOME experience (image source: Wikimedia, CC0)
One of the harder realities in open source is that a passionate user base does not automatically become a strong maintainer base. That’s not an indictment against users either; most people are genuinely better positioned to be good users than contributors, maintainers, packagers, developers, testers, documenters, or advocates. Even in dedicated communities, not everyone has the skills, time, or financial stability to support a project in those ways. This remains true when we talk about Ubuntu flavours as well.
A current example is Ubuntu MATE. In March 2026, project lead Martin Wimpress said his involvement in the project was coming to a close and asked for new maintainers to step up in his stead. Ubuntu MATE still has a clear identity and a loyal community, but loyalty isn’t the same thing as leadership or maintainership. The frank reality is that if too few people are able to carry the technical and organisational burden, even a respected official flavour can start to feel the strain. That tension is visible in the current release cycle too, with the Ubuntu 26.04 LTS release notes linking nine official flavour release-note pages rather than ten. Why? Because Ubuntu MATE is missing from the list.
It’s not just Ubuntu MATE either: the Lubuntu team has openly said it has less development manpower than before, while Ubuntu Unity says 26.04 is a regular release because key milestones were missed.
All told, the broader point is clear: adding more official flavours doesn’t magically create more maintainers. It just spreads limited labour across more projects, and as Ubuntu continues to spread its wings even further, that labour is not getting any lighter.
Some flavours clearly earn their place
Ubuntu Studio has long proven itself a worthy offering
Another key point to acknowledge here is that not every flavour adds the same kind of value for users. Some have a very clear reason to exist, such as providing a streamlined experience for a popular desktop environment that would otherwise be diminished by mixing it into a standard Ubuntu desktop base. A few examples of these include Kubuntu (for KDE Plasma), Xubuntu (for XFCE), and Lubuntu (for LXDE). Edubuntu and Ubuntu Studio serve a different kind of need, but both clearly establish themselves as necessary based on their defined purposes.
Strong purpose at the core matters because maintaining a flavour isn’t getting easier. Ubuntu’s flavour teams must keep up with the parent distro’s changes and innovations, including installer changes, release engineering, and core infrastructural changes whether to the OS itself or to build systems and other “backroom” aspects of the distro. So while the loss of convenience for some users can be understandably frustrating, it’s important to remember that it’s a balance of choice versus the reality of making these choices possible.
And this is really the distinction Ubuntu as a whole is forced to care about: not whether a flavour can exist at all, but whether it still makes sense for it to become (and remain) official long term.
Ubuntu can’t be the lab for everything
Ubuntu has often served as a proving ground for the Linux desktop as a whole. To some degree, other distributions have caught up and even surpassed it in many ways (take Fedora, for instance), but this doesn’t change the fact that the historical framing still holds strong.
Ubuntu-based efforts have helped push things forward on the Linux desktop more than once, and projects like KDE Neon have shown how the Ubuntu base can be a solid foundation for showcasing where a desktop stack is heading. This history of experimentation and iteration without compromising stability and quality has been key to Ubuntu’s success, and is one of the reasons Ubuntu has been chosen as the base for projects like Mint, Zorin and others.
There must be boundaries
Ubuntu itself can’t be the long-term official home for every experiment, budding desktop environment, or project that once felt promising but no longer has the momentum or community investment to justify and sustain its titular brand. At some point, definition, focus, and purpose must take precedent over ideas and good intentions.
Ubuntu has long positioned itself around usability, polish, and accessibility, and the legacy must mean something in the long run. “Linux for human beings” only works as an ethos if official experiences carrying the Ubuntu name are a true reflection of that very concept.
A poorly maintained, lagging, or half-broken flavour isn't a sign of openness. It's a sign that the core idea may not be enough to carry the weight of its own success.
A smaller official line-up can actually be a stronger one
I don’t see Ubuntu’s shrinking official flavour list as bad news. If anything, it I see it like as a difficult, but necessary correction (just don’t call me Thanos, I don’t think he was right). A leaner, better-focused, better-supported line-up of official flavours is healthier than an extensive list held together by fatigue and goodwill. It’s better for users, because the choices are clearer and more likely to be finely polished. It’s better for maintainers, because their efforts aren’t being spread quite so thin.
Most importantly, it’s better for Ubuntu as a whole, because Ubuntu is as much a product and a brand as it is an idea. Besides, this is Linux, and there will always be remixes, spins, experiments, and community projects that blow our minds with what’s possible, even if they don’t always last as long as others. Choice isn’t going away, nor should it. But the official Ubuntu flavour list will only be better off not being the umbrella for everything.
Before Microsoft became the company that shipped Windows to corporate desks around the world, it had to start somewhere. That somewhere was a scrappy little operating system written by one guy at Seattle Computer Products.
Tim Paterson built what he initially called QDOS, short for Quick and Dirty Operating System, in 1980. Intel's 8086 chip was out, but CP/M, the dominant OS of the time, had no 8086 support. He wrote something to fill that gap, modeling the CP/M API so existing software would run on it.
Microsoft bought the rights to 86-DOS for just under $100,000, shipped it to IBM as PC DOS 1.0 in August 1981, and retained the rights to sell the same OS to other PC manufacturers as MS-DOS.
That single deal set Microsoft on the path to dominating personal computing for the next two decades.
Fast forward to now
On April 28, the 45th anniversary of 86-DOS 1.00, Microsoft published a blog post announcing that the earliest known DOS source code is now publicly available on GitHub, under the MIT license.
And the story behind it is an interesting one. Tim did not hand over a tidy source archive; instead, what he kept were physical assembler printouts and stacks of continuous-feed paper from 1981 that he had held onto over the decades.
Getting those into usable shape took effort, with historians Yufeng Gao and Rich Cini having to locate, scan, and transcribe the DOS-related portions into compilable code.
What's included are the 86-DOS 1.00 kernel, several development snapshots of the PC-DOS 1.00 kernel, utilities like CHKDSK, and the assembler Paterson used to write the OS itself.
Who's this for?
Honestly, seeing Microsoft open up old code is not that surprising anymore. 6502 BASIC went open source in September 2025. MS-DOS 4.0 in 2024. MS-DOS 1.25 and 2.0 back in 2018. There is a clear pattern at this point.
If you are into retro computing or low-level systems work, this is genuinely worth digging into. The source code is compilable, and you will need a copy of Seattle Computer Products' ASM assembler, which you can pull from any 86-DOS or early MS-DOS release.
The GitHub repository's README has the necessary steps for you to follow.
Ptyxis is a modern terminal emulator built with GTK4 and libadwaita. It provides a cohesive look for the GNOME desktop, making it feel like a natural part of the system.
The application was specifically developed to meet the needs of modern software development workflows. In my opinion, its standout feature is the seamless container support for tools like Podman, Distrobox, and Toolbox.
Ptyxis is rapidly gaining popularity across the Linux community. It has already become the default terminal for many modern distributions, including Fedora and the upcoming Ubuntu releases.
As I have been using it for some months now, let me share some of my favorite features in this new terminal. I hope you like them as much as I do.
The first thing you notice when opening Ptyxis is the tabs and overview system. While other emulators like GNOME Terminal or Kitty use a standard tab bar, Ptyxis introduces a visual tab selector that feels very similar to the GNOME Activities overview.
Tabs Overview
If you have multiple tabs open, you can simply click the Show open tabs button in the top-right of the title bar.
Click on Tab Overview (Show open tabs) button
This opens an interface where each tab displays its title alongside a small preview, making it easy to see exactly what is running before you click back into a full view.
The flexibility here is excellent because you can drag and drop tabs in the overview to rearrange them.
Rearrange tabs by drag and drop
You can also pin important tabs to keep them visible at the top of the list at all times.
Pin tabs in overview
My favorite feature, however, is the ability to easily custom name your tabs and search through them later. By right-clicking a tab in the overview and selecting "Set title," you can choose to either prepend a name to the default process or create a completely custom title.
Renaming a tab in Ptyxis
Once your tabs are named, you can use the search button in the top-left of the title bar to find exactly what you need. This is incredibly helpful when you are managing a large number of active sessions simultaneously.
Search for Tabs in overview
📋
When you have multiple terminal sessions, the tab and overview feature helps a great deal in finding the right tab in the same application interface.
Color Schemes
A standout feature of Ptyxis is the support for a wide range of preset color schemes. You can access these options by opening the preferences window through the three-dots menu in the top-right of the title bar.
Open Preferences
Once inside the Appearance tab, click on the "Show all palettes" option to see the full list. The interface provides a neat preview for each selection, and your chosen theme is applied immediately.
All color schemes in Ptyxis terminal.
In my opinion, the way these colors adapt is impressive. The scheme is applied intelligently to the tab bar as well, ensuring the entire terminal maintains a cohesive and professional look.
Among the vast list of options, I have a few specific favorites that I think look incredible. Omni, Pixiefloss, and Tomorrow Night, Ubuntu are all excellent choices that provide a very modern feel.
Themes applied in the order: Omni, Pixiefloss, Tomorrow Night, Ubuntu
📋
It's not just the dark and light mode. That's too simplistic. You have plenty of color themes to choose from.
Scrollback Search
The ability to search through what appears on your screen is a massive help during long sessions. While tools like grep are great for text files, you often need to find specific information directly within the shell scrollback.
For example, if you have displayed a massive log file using the cat command, you can quickly find what you need without re-running the command. By pressing SHIFT + CTRL + F, a search interface opens at the bottom of the terminal.
Scrollback Search Interface
The extra search filters provides better matching. You can choose to match case, match whole words, or even use regular expressions to narrow down your results.
Scrollback Search Criteria
The interface includes simple navigation buttons to move up and down through your search matches. This makes it incredibly easy to jump between different instances of a term within a long output.
Searching in the Scrollback contents
📋
This has been a struggle in standard terminals. Finding text that has been displayed on the screen earlier is a good productivity booster for me.
Container Support
This is the flagship feature of Ptyxis. The terminal works directly with container technologies like Podman, Distrobox, and Toolbox to make your development workflow much smoother.
If your system has containers using these platforms, Ptyxis detects them automatically and provides a dedicated way to access them. You can simply click the dropdown button in the top-left of the title bar and select a specific container from the list to launch it instantly.
Enter a container using Dropdown menu
The ptyxis-agent coordinates with your system to handle the discovery and management of these environments. For example, if you are using Distrobox, Ptyxis will execute the proper run commands for you behind the scenes.
📋
The lack of Docker integration is surely a letdown. While you can still run Docker CLI commands manually, the terminal will not detect them automatically or allow you to enter them through the UI like it does for Podman. No matter how good Podman is, Docker is still omnipresent. I am lowkey disappointed that it cannot detect docker containers.
Profiles
Okay. This is not new. Almost all modern terminals support the profile feature and yet I think that profiles are the most underrated feature that many people often ignore.
How do they help? Let's say you want to try a new shell like ZSH, you can create a specific profile for it instead of changing your entire system shell. You could also create a dedicated profile for a terminal multiplexer like Zellij.
Custom Profiles
Ptyxis has excellent support for profile creation and management. You can find these options in the Profile section of the Preferences window.
By default, you will only see an Untitled Profile, but you can use the Add Profile button to create something new. The profile creation dialog is vast and offers many different options.
Click on Add Profile button
You can set specific color schemes, choose a custom shell, or even assign a default container to a profile. For example, I can create a profile that automatically opens my Ubuntu Distrobox container every time I launch it.
Once your profiles are set up, you can set one as the default for all future terminals. Alternatively, you can quickly switch between your different profiles using the dropdown menu in the title bar.
💡
I suggest that you do not alter the default profile. This will be very beneficial if you ever mess up a configuration and need to restore the original behavior.
Context Awareness
Ptyxis can intelligently identify your current context, such as active root privileged windows or SSH connections. This provides immediate visual feedback about the environment you are working in.
For example, if you run a command using sudo, the title bar of the terminal turns red to notify you of the changed privilege level. If you log in as the root user, the title bar remains red until you finally log out.
0:00
/0:11
Ptyxis titlebar color change for previlieged windows.
📋
In my opinion, this is an excellent communication method for the user. it provides a clear warning about the caution needed while interacting with the terminal in a high-privilege state.
Some hidden gems
Apart from the major features I mentioned above, Ptyxis also has a few more tiny functions that deserve attention. The Shortcuts option in the Preferences window allows you to alter existing keyboard combinations or add new ones for various terminal actions.
The Shortcuts page in the Preferences window allow you to change the existing shortcuts or add new shortcuts to various terminal actions.
An advanced addition is the Terminal Inspector. This tool allows you to monitor exactly what is running in the terminal at any given moment, which is a massive advantage for developers.
Ptyxis terminal inspector
You can use the inspector to track underlying shell processes, monitor mouse pointer locations, and even peek at OSC (Operating System Command) hyperlinks. It is a specialized feature that makes debugging terminal-based applications much easier than before.
I can see why Ubuntu and Fedora made it default
Ptyxis is a good upgrade from the classic GNOME Terminal. While the container integration might not be for everyone, the app has significantly improved many day-to-day features that improve the overall experience.
What do you think about this new terminal emulator? Will you use it as your main terminal, or are you sticking with your current favorite? Share your opinions in the comments section!
Linux gaming has been on a great trajectory these past few years.
Proton turned a massive chunk of the Steam library into playable Linux titles thanks to Wine as its backbone, and purpose-built Linux gaming consoles are now a product category that actually exists.
We recently covered the Playnix Console, a $1,179 Linux gaming machine from the EmuDeck team that ships with a custom Arch-based OS and boots straight into Steam's gaming mode.
Today, we have a project that lets you run a Linux-powered operating system on Sony's PlayStation 5 console.
Running Linux on a PS5?
Sourced from Andy Nguyen.
Andy Nguyen, the developer behind this, first posted about him running Linux on the PS5 back in March, where he demonstrated playing GTA V Enhanced with Ray Tracing enabled.
More recently, he posted that his project "ps5-linux" was live on GitHub, allowing gamers to turn their PS5 (non-slim) devices into a fully functioning Linux gaming PC.
You see, the PS5 does not run a Linux kernel. Sony's operating system is built on a heavily modified version of FreeBSD, which is a separate Unix-like OS altogether. What ps5-linux delivers is a genuine Linux port, not some tweak on top of what was already there.
In terms of what you actually get, it's a full desktop Linux environment. The PS5's 8-core, 16-thread CPU can be pushed to 3.5 GHz, the GPU to 2.23 GHz, and HDMI video output goes up to 4K at 60Hz. Steam runs on it, providing you with access to PC games and settings that Sony's own OS doesn't offer.
There are some gaps though; the PS5's onboard Bluetooth and networking hardware currently have no Linux driver support. You'll need a USB Ethernet or WLAN adapter for internet access and a Bluetooth dongle if you want to use a DualSense controller wirelessly.
It's also not a persistent install as the console's internal SSD is left completely untouched, so bricking your PS5 isn't really a concern. The trade-off is having to re-run the exploit from scratch on every single reboot.
I ported Linux to the PS5 and turned it into a Steam Machine. Running GTA 5 Enhanced with Ray Tracing. 🤯 pic.twitter.com/aMbT0PQ1dS
It works on PS5 (non-slim) consoles only. Devices running firmware 3.xx (3.00, 3.10, 3.20, 3.21) are supported but without M.2 SSD support. If you are on firmware 4.xx (4.00, 4.02, 4.03, 4.50, 4.51), you get the full package, including the ability to dedicate an M.2 SSD to Linux.
And you can run the following Linux distributions:
Arch Linux (with Sway)
Ubuntu 24.04 LTS
Ubuntu 26.04 LTS
Alpine Linux 3.21
Apart from that, you will have to follow the instructions closely and make use of the PS5 Linux Image Builder to get a Linux OS installed on your PlayStation 5 device. Andy also has a Discord server set up for people who can do a kernel exploit on his project and help him hack drivers.
Some thoughts
Is it practical? Not really. Using the exploit means starting the whole process over, and Sony will almost certainly DMCA the repos or employ some other legal mechanism at some point.
But someone built a full Linux port for a console that was never meant to run it, got Steam working on it, and put it all out for free. The Linux community has always been more interested in proving something is possible than in whether it's convenient, and this project is exactly that.
