Proton has launched AI Paper Trail, a free tool that shows people what their AI chatbot conversations reveal about them. It runs on Lumo (partner link), the company's privacy-focused AI assistant, and works by digging through exported ChatGPT or Claude conversation history.

Once you upload your content, the tool starts building a personal report around four categories. There's a "Privacy Type," a personality label based on how someone approaches their own data. Then comes an "AI Exposure Score," a number built from how many personal data points got pulled out of the conversations and how revealing they are.

The report also breaks down what the AI actually knows about you, covering identity, habits, relationships, and interests. On top of that, it puts a monetary figure on what this information could be worth to an AI provider.

And none of the uploaded data sticks around on Proton's server; the company says that it gets deleted right after analysis, and the resulting report stays visible only to the person who generated it.

The reasoning behind AI Paper Trail comes down to how casually people treat individual AI prompts. A single question about travel plans or a work email draft might seem harmless on its own.

But stack up months or years of conversations covering someone's job, relationships, health concerns, and finances, and a surprisingly complete picture starts to form.

Eamonn Maguire, Director of Engineering at Proton, notes that:

People understand that AI collects data, but most don't realize how revealing their conversation history becomes over time. AI Paper Trail makes that invisible profile visible.

We want people to understand what they're sharing with AI systems so they can make informed decisions about the tools they use.

What they have done here is hit two targets with one shot, offering people a privacy-focused tool that pushes them toward more conscious decisions when interacting with AI chatbots, while steering them straight into Lumo in the process.

This is a superb way to market a chatbot that focuses on privacy instead of mining every inch of your soul, erm, personal data.

It works well

I wanted to see for myself how the tool worked, so I first ChatGPT some information about how I approach certain subjects, saved it into memory, and then got back into Proton's AI Paper Trail to see what it could make of it.

The tool first told me to export my data from ChatGPT via the "Data controls" section in the Settings menu. I had to re-verify my ChatGPT session by giving it a one-time password and got the export started, but the files never showed up on time for me to use.

Instead, I asked it to generate me a dummy one taking in data from memory. 😆

When that was done, I uploaded the dummy export, and Lumo got to work behind the scenes all while promising not to store any of it on its servers.

A minute or so later, my report was ready. It gave me a personality-style rundown, labeling me a "Technical tester exploring AI profiling and ethics," complete with a fake handle and a summary pegging me as someone running structured experiments on AI behavior, focused on data extraction limits and ethics.

My AI Exposure Score came out to 21 out of 100, along with a "Hard to read" privacy type. Interests ended up being my biggest giveaway on the breakdown, while everything else landed at medium to minimal.

The part that actually got me was the "Most revealing" note (first picture above, right-hand side). It noticed I'd asked for a structured personality profile, tried to get it to infer my identity from barely anything, and even caught me trying to force it to remember something via a direct command.

Since I'd gotten ChatGPT to build that dummy file straight from its own memory of me rather than pulling random filler, the report had real clues to chew on, and it still managed to call out the testing motif buried in there.

Scrolling further down, there's a "What we identified" section that splits everything into categories like technical proficiency, ethical and philosophical inquiry, and privacy awareness, each with its own reasoning attached.

At the end, it dropped a few privacy tips and nudged me toward trying Lumo (partner link, hehe). There's also a shareable card option if you want to showcase your exposure score for some validation or gloating.

Don't think that this move came out of the blue. Nitrux has been busy building this up since last year, when it swapped out KDE Plasma for Hyprland and told everyone that they were headed towards 'a new beginning' that was not for everyone.

The project now has a name for what it has been creating, the "Workspace Environment." It ties together four new in-house developed components as pieces of a five-layer architecture, presenting a very different desktop experience for Nitrux than we are used to.

Uri Herrera, Nitrux's founder, describes it as filling a gap, where a window manager gives you almost nothing beyond window placement and a full desktop environment like GNOME or Plasma bundles everything into one tightly coupled process tree.

The Workspace Environment sits in between as a cohesive shell built from independent, single-purpose components that don't share a process lifecycle with the compositor or with each other.

The four components

Valenz is the new workspace bar, handling media controls, tray, notifications, and indicators for network, Bluetooth, battery, and power profile, plus weather, a calendar view, and system resource widgets.

Whereas Marina is the new dock that tracks and groups open windows across workspaces on Hyprland while handling pinning, auto-hide, and horizontal scrolling. It also adds unread message badges for pinned apps that expose a launcher count.

Workspace Settings replaces KDE System Settings entirely, covering user accounts, locale, networking, and MauiKit configuration without any Plasma dependency.

Desklock completes the set as a native QML lock screen built on the QMLGreet codebase, with PAM authentication, per-output lock surfaces, and CPU, memory, and network monitors alongside MPRIS playback controls.

All four are QML-based and built with MauiKit, though only Valenz and Marina share LayerShell-Qt, so the stack still ends up with one visual language instead of stitched together toolkits.

Does it make sense?

The switches aren't just cosmetic, and alternatives were considered.

Uri writes that Waybar and SwayNC leaned on GTK and CSS styling, which clashed with the QML-first approach he had already committed to with QMLGreet.

Crystal Dock had a similar limitation, built on legacy Qt Widgets instead of QML, and its broad feature set worked against Nitrux's preference for narrowly focused tools. Hyprlock got replaced too, over a visual mismatch with MauiKit and a bug that left it in a bad state after suspend or hibernation.

The pattern across all three swaps is consistency. Uri picked first-party QML tools over external options like Quickshell specifically to avoid depending on a construction framework he doesn't control.

There's a maintenance aspect associated with the lock screen choice too. In Uri's words:

Because Desklock derives directly from the QMLGreet codebase, the two components share the same secure lifecycle and visual identity. This shared foundation minimizes maintenance overhead while strictly enforcing our unified architectural philosophy.

It provides a native QML session locker that executes its single responsibility perfectly, completing the visual and functional ecosystem of the Workspace Environment.

You'll have to wait

Nitrux Workspace Environment marks the end of Maui Shell, the project's old convergent shell concept. Nitrux has already archived its GitHub repository and is looking forward to their next developmental milestone.

One catch worth knowing before you go looking for these tools is that Valenz and Marina both list Nitrux 7.0.0 as a requirement, and the current stable release is still 6.1.0. So you will have to wait.

Whether the wait is worth it will depend on how these components hold up once regular users actually get their hands on them.

There's something satisfying about watching a Linux project everyone assumed had quietly died come back with a fresh commit. It happens more often than people expect, and it's usually worth celebrating when it does.

One of those revivals has been the return of LightDM, the display manager Canonical built more than a decade ago.

LightDM is alive

Released last week is LightDM 1.33.0, which rolls out a bunch of improvements as well as introduces the two new maintainers who are taking over. The last release, 1.32.0, came out way back in July 2022, marking a four-year gap in which the project barely went anywhere.

You see, LightDM's original maintainer, Robert Ancell, had already called the project "essentially unmaintained," and questions about its future eventually popped up on various forums over the years.

Luckily, two people willing to keep the project going stepped up, making it a community-maintained affair rather than a Canonical-maintained one.

Joshua Peisach and Neal Gompa are both known for their work across a string of open source projects. Joshua leads Ubuntu Cinnamon Remix, and Neal doesn't really need an introduction; he has spent years contributing to Fedora, openSUSE, and CentOS.

As for what 1.33.0 actually delivers, the maintainers say its purpose is mainly to tag the fixes that piled up since 1.32.0 and clear out pull requests that had been sitting for years.

There are no breaking changes and no dependency changes, so existing LightDM setups should upgrade without any surprises. The biggest addition worth flagging is Qt6 support for the client library, though that doesn't mean Qt5 is going anywhere. Greeters built on the older toolkit will keep working just fine.

There's a long list of smaller fixes too. VNC server handling has been patched, the flood of log errors from missing PAM modules is gone, and a batch of multiseat and FreeBSD-specific bugs got cleared out.

Help is needed

If you didn't know, LightDM is a lightweight, cross-desktop display manager. It's the software behind your login screen, the one that authenticates you and hands things off to your desktop session once you're in.

Canonical built LightDM to replace GDM, and it debuted back in Ubuntu 11.10 as the login screen behind Unity. Ubuntu itself moved back to GDM in 2017 when it dropped Unity for GNOME Shell, but LightDM never really went away.

Linux Mint adopted it that same year and pairs it with its own slick-greeter, and elementary OS runs it through Pantheon Greeter. Several Ubuntu flavors and Fedora spins still depend on it as well.

If you think you can help LightDM evolve into something more, then know that Joshua and Neal are looking for new contributors to join in. You can reach them directly over Matrix.

They also point out that signing the Canonical CLA is no longer required.

Though I have something more to add here.

Don't unleash your army of clankers (I believe the formal term is 'AI agents') on this project; it's already happening to many open source projects lately, and this one has just been revived. It doesn't need to be inundated with hallucinations and pointless fixes.

The maintainers also request that anyone opening a pull request for a bug fix show a way to reproduce the problem first.

The world of open source is split when it comes to AI, while a big project like Linux is seeing its leader warming up to it, telling those who object on the mailing list that Linux "is not one of those anti-AI projects."

Projects like Rust, GCC, and Codeberg are going the other way, banning AI from writing meaningful chunks of their code, though none of them draw that line in quite the same place.

Omarchy doesn't care about any of that. Its upcoming release, Quattro (4.0), is skipping the debate over whether AI should write code and is building AI agents into the desktop itself.

As a refresher, the project calls itself a "Beautiful, Modern & Opinionated Linux," and the opinionated part shows up in how the distro configures itself with minimal input from the user during installation.

Its creator, David Heinemeier Hansson (DHH), has now decided that AI agents belong in the defaults too, saying that this is how they will "truly democratize Linux," and predicting that Linux adoption among developers is going to explode.

Enter, Quattro

While Omarchy 4.0 is still in the beta stage, DHH is calling it their biggest release yet.

He is teasing all kinds of new agent-facing features, such as a crash watcher that briefs your AI agent the moment something breaks, a dedicated agents usage widget, and nine different agents to pick from.

The crash watcher is the one DHH teased on X first. Let's say a process crashes. Omarchy catches it off the systemd-coredump journal and pops up a toast. Click it, and your default agent gets briefed on the whole thing through a diagnose-crash skill built to make sense of the backtrace.

Don't worry, it still asks you for confirmation before reporting anything upstream, and it checks for duplicates too.

Quattro also lets you pick a default coding agent under Setup > Defaults > Agent, giving you nine options that include the likes of Claude, Codex, Gemini, Grok, and Copilot.

None of them come pre-selected either. During first boot, a notification nudges you to pick your default agent, and if you skip it, the agentic features stay disabled.

When I configured Gemini using an API key, I asked the agent what it could do for me, and it said that it could help with Linux configuration and window manager setup through Omarchy.

It also brought up crash diagnosis using the same diagnose-crash skill from earlier, on top of the usual code reading, writing, and command execution any coding agent handles.

There's even a model-usage widget that tracks usage against weekly limits, though it is only available for Claude Code, Codex, Pi, Oh My Pi, and OpenCode sessions.

And, if you go looking through the contributors list for the project, you will see that Claude has contributed a fair bit, further cementing where Omarchy as a project is headed.

Not everyone will be happy

Depending on where you stand on AI, this is where people start picking sides. One of them, a developer who goes by the name IroncladDev, has decided they won't be updating to 4.0.

He says that Omarchy is what got him off macOS and onto Linux in the first place, but that's not enough to keep him around for Quattro. His issue is that he isn't interested in any of the "AI/Agentic additions." He just wants a terminal, a browser, and working USB ports, nothing more.

That kind of pushback was inevitable. Move a distro this hard, this fast, and you lose the people who signed up for something simpler. Baking agents into the OS is a bigger ask than a new theme, and DHH made that call for everyone whether they wanted it or not.

Closing thoughts

I believe that DHH is making a well-timed call before the rest of the ecosystem catches up. Omarchy went with Hyprland back when tiling window managers were a niche pick. Betting Quattro on AI agents looks like the same instinct that's paid off before.

While many open source projects are left arguing whether using AI and providing AI-focused features is a good call, Omarchy looks to be on track to become something we can call an "AI Linux distro."

The world is in a messed-up state where surveillance and eroding people's rights are rewarded, and those who oppose are labeled unpatriotic, anti-national, radicals, criminal sympathizers, and what not.

Yet, that doesn't stop people from investing time and money in securing their data by opting for open source mobile operating systems like GrapheneOS and taking steps to improve their privacy in the online world.

One of those steps is to go for a private messaging app that doesn't give out your data to feed some AI or a governmental agency that asks for your data nicely. SimpleX Chat is one such option, a messaging network that doesn't ask for phone numbers, emails, or user accounts.

I tried it out myself back in 2024, and it left a strong impression. The team behind it has kept building since, and now it wants its users to also have a stake in where the project goes next.

Looking for investors

The founder of SimpleX Chat, Evgeny Poberezkin, reached out to us recently, saying that they were looking to give users "the opportunity to get a stake in SimpleX Chat and benefit from its growth."

This investment is possible under regulation crowdfunding via Wefunder, and all the terms are available on the SimpleX Chat page. People who invest $500 or more would receive public SimpleX names that SimpleX Chat is currently testing.

Until August 15, these names would be for 10 years, and for 5 years for early bird investors after that.

The company behind the app isn't quite what it used to be either. SimpleX Chat Ltd, the UK entity that built the app, is now a wholly owned subsidiary of a new US company, SimpleX Chat, Inc.

Keep that in mind if you consider where a firm is based out of before investing in it.

SimpleX Chat also recently pivoted to public channels and infrastructure payments for large channels as their core commercial strategy, publishing a whitepaper about Community Credits that would allow private payments for infrastructure via prepaid credits.

Other planned sources of revenue include public names in the network for channels and businesses and business messaging via browser.

To further explain, public names use blockchain contract on the Ethereum mainnet and are fully controlled by the users’ keys. You can test the temporary names in the mobile apps for SimpleX Chat.

Before you go ahead and invest, do understand that this comes with the usual risks of backing a company this early.

There's no guarantee of a return, and what you invest isn't something you can sell easily if you change your mind. The company's filing says that they have enough cash for the next 12 months.

A similar occurence

We already had an instance of a messaging app asking its community for help earlier this year, where Session nearly shut down after it ran out of funding, needing $1 million to keep going.

By June, the foundation confirmed development had resumed, backed by two to three developers instead of the dozen-plus it once employed. SimpleX Chat raising money through equity now, rather than an emergency donation drive, gives it a strong start.

Xbox Game Pass has never really worked on Linux beyond laggy cloud streaming, but an open source project called Xodus is trying to change that.

Earlier this week, replying to a thread on Reddit, Paweł Lidwin (imLinguin), project lead of Xodus, confirmed that the hardest parts of running those games on Linux, Xbox authentication, and game downloads are already working.

The project is attempting to reverse engineer Xbox's entire authentication, licensing, and delivery pipeline well enough to run Xbox on PC and Game Pass titles on Linux.

What's Xodus?

Xodus describes itself as "the great gaming migration to Linux," while cautioning people that it is not endorsed by Microsoft and using it comes with risks. You see, modern Xbox PC games run on Microsoft's Game Development Kit, or GDK, and ship as encrypted⁣ MSIXVC packages.

Getting a game running on Linux means handling both.

The project's GitHub page currently houses a handful of repositories that include the main xodus client written in Rust, a forked ntfs library for reading MSIXVC, and xgameruntime, an open source implementation of xgameruntime.dll built for use in Wine.

A companion repo, xgameruntime-docs, documents how that same DLL works internally.

There's also forked copies of Wine and Proton, maintained by the Xodus team, featuring custom tweaks, and xal-rs, an Xbox authentication library forked from OpenXbox.

Keep in mind that there are no binaries available for you to play around with just yet; there's still a lot of work to be done.

So yeah, a First Look at Xodus is still months away. 😆

The devs are surprised

Thanks to that Reddit reply, the project has gotten a wave of press coverage, and it has caught the developers off guard. "Quite unexpected," wrote Paweł on the project's Discord server after Digital Foundry picked it up.

Though the original coverage seems to have been from VideoCardz.com, many of the outlets out there have got a detail wrong. Describing Xodus as a project from the Heroic Games Launcher team is not right, as Paweł is the only Xodus contributor who has also worked on Heroic, not the whole team.

Another contributor, BellezaEmporium, who has been busy tracking this surprise wave of coverage, points out that one of the articles has been quite salty in talking about Xodus, while Olivia (olivi-r) shared some important developmental updates.

She says that:

Progress has been fairly rapid the last few days on the xgameruntime side, XTaskQueue is nearly implemented with a few modes and quirks to sort out.

Currently fixing XUser as it seems the signature generation is a bit messed up 😬

Still need to actually load tickets from xodus into XUser as well, I've been hardcoding mine for the testing, not sure if we're going with the stdio proxy or ipc implemented directly in wine yet.

What now?

If Xodus pulls this off, it closes one of the last major gaps between Linux and Windows gaming. Game libraries on Steam, GOG, and Epic Games already run well through Proton and Heroic, but Xbox PC and Game Pass titles have been locked to Windows or laggy cloud streaming until now.

And, if you ask me, this is the right time for Xbox to make Xodus' job easier by lending a hand, similar to say how Valve has handled the development of Proton while supporting Wine and DXVK upstream. This way, the whole ecosystem benefits, not just Steam.

If Xbox decides to help the project, then they do have many avenues to pursue…

The Linux Mint project regularly puts out monthly news that gives us a look at what the developers are working on and where the overall project is headed towards.

Their July update has shown us how the distribution intends to handle kernels going forward, moving the entire job out of the Update Manager and into a different tool altogether.

A new feature?

Yes, and no. Kernel management isn't new, as in the past, Update Manager has let users view and remove individual kernels, but that functionality was removed.

The new implementation sits inside the System Administration tool instead, and it's built to behave the same way whether you're on Linux Mint or LMDE.

Instead of tracking individual versions one at a time, the new "Kernels" page inside System Administration groups multiple kernel versions according to series. Setting up the tool is a one-time choice of you telling it which kernel series matter to you and how deep a backlog to hold onto for each one.

Everything downstream runs on its own after that. The series you're following keeps updating through Update Manager the same way they always have, while anything past your set limit gets thrown out during a scheduled pass once a week.

Manual cleanups are possible too for times when you want to quickly free up some space to accommodate other content. Individual kernels can also be marked "Protected," which keeps them off the chopping block regardless of whether their series is tracked or how old they are.

Before you go looking for this on your own system, know that it isn't live yet.

Linux Mint project lead Clement Lefebvre has said that this is a preview of what's coming to the next Mint release.

Fedora has this already

I understand that Linux Mint has had to reimplement their solution, but Fedora has had this problem solved for years. Its DNF package manager has done this by default the whole time.

The setting behind it is called installonly_limit, and it defaults to 3. Only the three most recent kernel builds stay installed at any given time. Whenever a new kernel comes in through a regular update, DNF removes whatever falls outside that limit as part of the same transaction.

There's no separate scheduled job behind it, unlike Mint's new weekly cleanup. It only runs when you actually update, so a kernel installed outside DNF's normal flow would just sit there untouched.

The two approaches end up solving a similar problem in different ways. Fedora's is a flat, always-on limit tied directly to the update transaction. Mint's new implementation, once it ships, would hand you more direct control instead.

Kernel management wasn't the only thing in Mint's July post. The team also shipped new HWE ISOs for Linux Mint 22.3, this time built on Linux 7.0, and Fcitx5 support lands in Cinnamon, running the same way across Wayland and X11.

For the full rundown, including the new environment variables page and the panel fixes, the original blog is a must-read.

Suggested Read 📖: In related news, Linux Mint now considers Wayland stable enough for inclusion in its next release, due Christmas.

Love them or hate them, rolling release distros have managed to take a slice out of the Linux desktop market share. They provide a bleeding-edge experience that stays quite stable if cared for and bites a user's a** if handled poorly.

CachyOS is one of those options that has been only getting more popular as the days go by. Offering a rebuilt Arch package stack with CPU-specific optimizations and a custom kernel tuned for responsiveness, it is a distro that delivers some good performance.

You might remember late last year, the developers had teased plans for a dedicated Server Edition aimed at NAS setups and hosting providers. Their newest release shows us where some of the work is happening, along with the typical distro-focused improvements.

What's fresh?

The graphical installer sees many new additions, such as Hyprland's Noctalia option swapping SDDM for noctalia-greeter, Cinnamon moving to lightdm-slick-greeter, GNOME gaining gvfs-dnssd, and COSMIC picking up cosmic-monitor.

For the CLI installer, other than the usual housekeeping work of addressing bugs and refactoring the code, there's experimental support for Server Edition installation profiles, marking a key milestone in the new variant's development.

Shelly became CachyOS's default GUI package manager back in April, replacing Octopi, and we found it a promising switch once we spent time with it. With this CachyOS release, Shelly has got its most significant change yet with its v3 iteration.

It has gone from being written in C# to Zig, replacing the managed runtime with native binaries that start faster and use less memory.

Coupled with that is the new onboarding screen that shows up at first run, along with list and grid views for browsing packages, and AUR PKGBUILD previews with build output.

You also get a new Utilities page for syncing the database, cleaning up the cache, and orphaned package removal. Similarly, its CLI version can now search repositories and the AUR from one place, running update checks across the repos, AUR, AppImage, and Flatpak.

Cachy-Update now runs on top of Arch-Update v4.x, with the systray applet ported to Rust. The new --check --enable flag combines two previously separate steps, turning on automated update checks and launching the tray icon together.

Then there's the handheld detection with chwd, which currently works off board name pattern matching, picking up Bulgarian localization, and no longer tripping up when the board_name DMI file is missing.

And finally, we have the Welcome app that had its DNS handling reworked, resolving an issue that kept the speed-test based ranking from actually picking the fastest server.

You can refer to the release announcement blog to know about the smaller changes that we have skipped here.

Get this now

Fresh ISOs for both editions are live now. Grab the "Desktop Edition" for the full CPU-optimized desktop experience, or the "Handheld Edition" if you're running a Steam Deck, ROG Ally, Legion Go, or Legion Go S.

Existing users don't need to reinstall anything to get this release. Just open Shelly from the app launcher and go into the "Update" page. Here, wait a bit for the sync to complete, or click on "Check Again" to pull in updates from the official repositories, AUR, and Flatpak in one go.

If you prefer the terminal, Shelly's CLI can handle the same job with a single command:

shelly

The Rust project has implemented a formal LLM policy, which pushes people to use LLMs to analyze/think through code, not write it.

With how it is written right now, the policy only covers the core code repo for Rust. It lays out many rules around what's restricted, what's allowed, and a circuit breaker that pauses AI-authored merges once they cross half of all merges in a six-week window.

Just so you know, the core repo hosts the compiler and standard library for the entire language. Every Rust program depends on code that lives here, which makes it a very important repo to moderate.

It's no surprise they banned LLM use the way they did.

An LLM can't write your comments, issues, or PR descriptions under your name. Documentation, safety comments, and compiler diagnostics are all off-limits too. And an LLM review can never substitute for a human one or for reviewing your own code before you post it.

What's allowed is private use. Asking an LLM questions about the codebase needs no disclosure, and neither does privately reviewing your own code, summarizing a PR for yourself, or building personal dev tools with one.

Apart from that, there are a few things that reside in a gray area. Machine translation, trivial fixes made with an LLM, and self-verified bug hunting all sit here, and each one needs to be disclosed.

AI-written code gets the strictest treatment of all. It has to be pre-arranged with a reviewer, unlikely to introduce a bug that breaks Rust's safety guarantees, fully tested, and understood on both sides before it earns the new ai-assisted label.

Jynn Nelson, who wrote up the original policy that the project has now adopted, concluded the announcement by stating that:

This is not the end of the story. One of the goals of the policy is to help us gather data: Are people doing interesting and useful things with LLMs? Are they learning? Are they making repeat contributions? The answers to those questions will help us determine how the policy changes in the future.

A similar move elsewhere

NetworkManager, the default network daemon on most mainstream Linux distributions, has picked up an AI coding assistants policy of its own, recently merging a new section to its CONTRIBUTING.md file.

It reads as follows:

Authors are responsible for 100% of the code they submit. Do not send a patch you cannot explain, and do not send one you have not built and tested yourself. Write your own commit messages and Merge Request descriptions.

Those explain why you are making the change, which is the part a tool cannot know. Respond to review comments yourself. If you cannot discuss your own patch with a reviewer, it will not be merged.

Everything in the Legal section applies unchanged. You are the one certifying that the contribution can be released under LGPL-2.1-or-later. A tool cannot certify that for you.

Large machine-generated Merge Requests that no human has reviewed line by line will be closed.

Josephine Pfeiffer of Red Hat wrote the change and merged it herself on August 7, after maintainer approval. If you read the above, then you can see NetworkManager's version is quite simpler than Rust's tiered system. Right now, it is closer to the human-in-the-loop approach that we have already seen in LLVM's policy.

We are constantly seeing such moves. For instance, Codeberg's members recently voted to ban projects built mostly from AI-generated code, citing server strain and climbing hardware costs.

Time and again, we're getting more evidence that AI use can quickly degrade maintenance-focused work and infrastructure if left unchecked. As usual, the open source ecosystem will continue evolving according to what the use of AI dictates.

Illinois has become the latest U.S. state to pull operating systems into the age verification pool. Governor JB Pritzker has signed HB5511, the Children's Online Social Media Safety Act, putting forward a new age verification framework for every device sold or used in the state.

The bill imposes age check on "covered manufacturers," a category that lumps device makers, operating system providers, and app stores together.

Protect the children!

By January 1, 2028, these manufacturers have to build an interface at account setup asking a parent or account holder for the child's birth date. That date is then converted into one of four age brackets: under 13, 13 to 15, 16 to 17, or 18 and up.

The law also stipulates that all transmitted digital signals have to be encrypted.

Applications can then pull that bracket through an API once a user downloads or launches them. Once they get a signal marking a user as a minor, they're legally treated as having "actual knowledge" of that.

Once flagged, apps have to turn on a set of safety settings. Feeds get restricted, profiles get hidden from adult strangers, messages from adults get blocked, precise location gets masked, and notifications go dark between 10 PM and 7 AM.

Parents can override these defaults for their kids, and minors over 16 can do it themselves too.

Apps have until July 1, 2028 to start requesting these signals, and violations can cost up to $50,000 each, enforced by the state Attorney General. Device manufacturers and apps acting in good faith aren't liable if a signal turns out wrong.

Rep. Jennifer Gong-Gershowitz led the bill through the House, with Reps. Margaret Croke and Janet Yang Rohr as chief co-sponsors, and more than a dozen others signed on. Sen. Willie Preston carried it in the Senate alongside Sens. Robert F. Martwick, Mary Edly-Allen, and Adriane Johnson.

It passed 82-27 in the House and 57-0 in the Senate before clearing final concurrence unanimously.

Open source exemption where?

Illinois isn't the first state to try this model. Colorado's SB26-051 and California's AB-1043 both rely on the same OS-level age signal setup; apps request it, and the device answers.

Both of these started off without any concessions for open source platforms (e.g., Linux).

Colorado's SB26-051 originally applied to every operating system and developer without exception. System76 founder Carl Richell worked directly with state lawmakers to change that.

The bill picked up language exempting operating systems and developers distributing software under terms that let anyone copy, redistribute, and modify it freely. It also added a clause blocking platforms from locking down modified versions.

California's AB-1043 had the same gap. Assembly Member Buffy Wicks, the same lawmaker who wrote AB-1043, introduced AB-1856 to fix it. After several rounds of edits, the amended bill redefines "operating system provider" to exclude anyone distributing software under those same open license terms.

Illinois has none of this. HB5511's definitions for "covered manufacturer" and "application store" stay just as broad as these bills were before their amendments.

My two cents

Well, folks, we sure are getting close to someone's wet dream of having a dystopian hellscape where people don't have control over their computers, food, or water.

On the one side, you have these so-called "bipartisan" bills passing through without much hindrance under the guise of protecting children, and then you have the island-class cretins who still haven't been prosecuted.

Virtualization is basically load-bearing infrastructure for any serious data center in 2026. Enterprises lean on it to run more workloads on less hardware, isolate services cleanly, and keep uptime high without buying a rack of extra servers.

Proxmox has built a name for itself in this space over the years with its range of products.

Proxmox Virtual Environment (VE) handles virtualization, Proxmox Backup Server covers data protection, and Proxmox Datacenter Manager ties it all together as a solution for managing distributed infrastructure.

All of it ships as open source software too! 🤌

Now, they have announced a major development for Proxmox VE, their flagship virtualization platform.

Proxmox VE on ARM64

Yep, that's the highlight move. Sitting alongside its existing x86-64 builds are the new ARM64 images that have brought official support for the Arm platform.

Proxmox says the new images follow the same codebase, release lifecycle, and support window as x86-64, while running on Debian 13.5 "Trixie" with Linux kernel 7.0 and additional components like QEMU 11.0, LXC 7.0, and ZFS 2.4.

Likewise, storage gets similar improvements with ZFS 2.4 and Ceph, two of Proxmox VE's core storage options, carrying full feature parity with the x86-64 build.

Though you should know that officially supported hardware is currently limited to the NVIDIA Grace and Vera platforms. Proxmox has also validated the Arm64 build jointly with NVIDIA and Supermicro, testing specifically on Grace Hopper Superchip servers.

Other UEFI-based ARMv9-A hardware gets best-effort support, and Proxmox says ARMv8-A "generally works too." What's not supported is that Raspberry Pi lying on your desk, or really any other devicetree-only single-board computer, like an Orange Pi or a Radxa ROCK board.

Don't think that ARM64 support is stopping at Proxmox VE; the developers are already running internal test builds for their other offerings, with Proxmox Backup Server being one of the examples given.

However, which one gets prioritized depends on their enterprise customers' needs.

Get started

Seeing that ARM64 as a platform has matured so well along the years, and more and more workloads have shifted to this over x86-64, this move doesn't really come as a big surprise to me.

Proxmox didn't ship this as an experiment either. It launched this with full support from day one. This, to me, is a company that saw where the market was headed and adapted accordingly.

Anyhow, Proxmox VE for ARM64 is available now as a free download, either as a bare-metal ISO image or through package repositories alongside the existing x86-64 builds.

Enterprise users get access to the pve-enterprise repository too, same as on x86-64, with Proxmox recommending it for production deployments.

You can grab the Arm64 ISO installer directly, dig into the documentation for setup details, or browse the source code repositories if you want to see what's under the hood.

Suggested Read 📖: Our informative mini-course that covers everything from installing and upgrading Proxmox to using it.

Greg Kroah-Hartman just deleted a Linux driver that hasn't mattered to anyone in years.

The reason for removal wasn't a bug report or a user complaint. It was AI agents poking around dead code and turning up findings nobody asked for.

That sounds like another "AI is reshaping open source" piece. It mostly isn't. This driver was already on its way out, Moxa said so years ago. What changed is the removal finally happening at a time when AI is scraping away at the kernel codebase.

What's happened?

On August 3, GKH sent a patch to the linux-serial mailing list removing drivers/tty/moxa.c entirely. That's the Moxa Intellio family multiport serial driver, code that's been part of the kernel since 1999.

The patch strips out 2,137 lines of driver code, plus the Kconfig and Makefile entries that reference it. In total, 2,148 lines of unused code are gone.

GKH says that:

This is a very old driver, and no known hardware is still around for it, and the company says they do not need it anymore, so let's remove it as the LLMs are starting to poke at it and find "interesting" things which will just waste everyone's time given it's not actually used.

While keeping the door open for anyone who actually still needs it, noting that the driver could return down the line, just built "in a more 'modern' way."

Some context

Moxa isn't some obscure or defunct outfit that used to be cool back in the 90s. It's a Taiwanese company that makes industrial networking gear and serial cards for factories and railway systems.

The Intellio series was an older PCI serial card lineup from their catalog, not a piece of consumer hardware you'd find lying around in people's attics.

While software support was promised through 2023, the hardware itself was discontinued way back in 2017. According to an email Moxa's Ray Chen sent Jiri Slaby back in 2021, the company had no plans to keep the Intellio line alive any longer.

Jiri, who has maintained parts of the kernel's serial driver code for years, floated marking moxa.c as broken or dropping it outright.

Nothing happened until May 2026, when a separate patchset reorganizing the tty subsystem's directory structure brought the topic back up. Crescent Hsieh from Moxa confirmed both the hardware and its software support were fully phased out and even offered to help write the removal patch himself.

That gap isn't unusual on its own; kernel patches sit in queues all the time. What's notable is what finally moved it (AI poking holes).

Where AI comes in

So saying that "AI is deleting kernel code" would be overstating what's actually happened. The Moxa folks had already signed off on removal in May. GKH didn't act until August, three months later.

What the AI did was start poking at 27-year-old code that everyone already agreed was dead, bringing up findings on hardware nobody has left to test against.

If you are used to working with AI agents, then you know that scanning old, unused code doesn't always produce genuinely new work. Sometimes it just produces enough annoyance that maintainers have to act to nip it in the bud.

This change landed minutes before GKH drew a different kind of line, rejecting LLM-generated patches for the kernel's staging tree entirely. So take note of this, while AI isn't writing much of the Linux kernel yet, it's already influencing which parts of it get tossed out.

Office suites have changed a lot since the first ones landed on desktops decades ago. What began as basic tools for typing letters and totaling numbers has turned into sprawling software loaded with templates, cloud sync, and now, AI.

It's 2026, and that last part has split the office suite market into two camps.

Microsoft has leaned into pushing AI everywhere, with Copilot showing up across Word, Excel, and PowerPoint whether you want it there or not. Others have gone the calmer route, building AI in as something you can turn on, not something forced.

GenOffice is a new offering from MainFunc.ai that strongly focuses on AI, putting it in the first camp, featuring a range of editors that one might expect from a modern office suite.

GenOffice: A quick look

Built by a single developer equipped with $10,000 worth of tokens (for AI), GenOffice bundles four editors, Docs, Sheets, Slides, and PDF, into one Electron-based desktop app.

For .docx work, Docs lets you draft a section, restyle a paragraph, or rewrite it for a different reader from a simple prompt, with the AI working directly inside the document rather than a side panel.

Sheets, for .xlsx files, runs on Univer, an open source spreadsheet engine, paired with an in-house Rust sidecar for reading and writing files.

Presentations run through Slides, which builds .pptx decks from a single prompt, picking a layout, writing the copy, and dropping in data cards as needed.

Rounding out the office suite is PDF, built on the open source pdf.js and pdf-lib libraries, letting you read long documents and ask questions about specific passages without you needing to switch between apps.

It's quite obvious that AI runs through every one of these editors. All of that is made possible via Genspark's Super Agent, which is treated as a core part of the app rather than a chat window tacked on the side.

Opening, editing, and saving files costs nothing, but AI features draw from Genspark's credit system, tying them to an account rather than a local model.

That matters, because GenOffice doesn't appear to have its own privacy policy. AI features run through Genspark's service, so anything you send them falls under Genspark's terms and privacy policy instead.

That policy states text fed to the AI features gets passed to third-party providers, including OpenAI, Anthropic, Google, xAI, and ElevenLabs, and that no API key is stored on your device.

Currently, GenOffice is available only for Windows (x64) and macOS on Apple Silicon. Intel Macs are not supported, and as you've probably guessed, neither is Linux.

Where's the Linux build?

I did find an open issue (very likely AI-generated) that mentions a native Linux build, filed by a community member. It explains how shipping GenOffice for Linux isn't as simple as it sounds.

As of writing, there was no reply from the lead developer of GenOffice, so I wouldn't hold my breath for a Linux build anytime soon.

If you still want to try GenOffice, you can grab installers for Windows and macOS from the official website or go through the source code on GitHub to see if you can get a Linux build running yourself.

Suggested Read 📖: 6 Best Open Source Alternatives to Microsoft Office for Linux

Greg Kroah-Hartman's "clanker" branch started as his own experiment, where an AI-assisted fuzzing tool turned up real bugs in the ksmbd and SMB code. These days, he isn't the only one using it, as other contributors have started sending in patches of their own, tagged the same way.

So when he posted a new AI policy a few days ago, restricting use of AI, it wasn't him turning against a tool he's comfortable with. It was a restriction that applied to one part of the kernel, the one place he doesn't want AI anywhere near the code.

A new rule

In a post to the linux-staging mailing list, GKH said he's now proactively rejecting LLM-generated patches for drivers/staging, pointing to an "onslaught" of them showing up lately.

His reasoning comes down to what staging is actually for. The subsystem exists primarily as a training ground, full of relatively simple cleanups and API changes that let newcomers learn the submission process.

The project already skips "fix all the coding style issues" patches generated by automated tools because clearing out that mess would eliminate the reason staging exists. GKH argues an LLM doing the same cleanup work defeats its purpose while calling out wannabe tricksters by saying that:

And yes, it is VERY obvious when people submit LLM-generated patches, so don't think that just not disclosing the use of them will allow you to "get away" with anything here. The goal is for people to be able to learn, not to try to "trick" a maintainer. If anyone is determined to have deliberately "tricked" us, well, consider this your warning ahead of time...

There's an exception, a strict one that too. A genuine security fix found by an LLM can still be submitted, but only if the submitter has tested it on the actual hardware the driver targets and can convincingly explain how testing was carried out.

A line drawn while Linus makes peace

This move lands right as Linus Torvalds is coming around on AI. He's spent years shifting his stance, and in a recent mailing list post he made it clear to critics that Linux "is not one of those anti-AI projects," telling them to fork the project or walk away if they disagreed.

GKH's approach to drivers/staging fits inside the AI Coding Assistants policy, where he isn't undoing what Linus signed off on but rather focusing on a narrower scope.

He is treating this subsystem as a gym, one where developers are supposed to show up and lift the weights themselves, not have an AI do the reps and hand them the result.

That's the line GKH has drawn. AI can be used to carry out work elsewhere in the kernel, but in a subsystem built for people still learning, he'd rather they build it the hard way first.

💬 What do you think of GKH's decision? Will it help newcomers?

Rhythmbox is one of those applications that you will find lurking on a GNOME-equipped desktop. If you are someone who has fully moved on to streaming music/podcasts online, then it doesn't have much purpose for you.

Even with the rise of streaming, many people do prefer hosting media locally, and that is partly why the GStreamer-powered music player refuses to die.

The GNOME project just pushed out Rhythmbox 3.5.0, the newest release in about nine months. The last one, 3.4.9, mostly patched up plugin loading and swapped in a new playback backend. This time around, the changes are more visible.

The new bits

Buried in the changelog is a fix for the year 2038 problem, the one where systems counting time as a 32-bit number run out of room and start thinking it's 1901 again. Rhythmbox has swapped the deprecated GTime type for time_t to stay ahead of it.

Then there's the podcasts page, which has gotten the most visible upgrade in this release.

Episode lists now mark which ones you have already played; notifications for updates and downloads have been reworked; and a new plugin allows you to sync your feeds and episodes through the gPodder.net API.

Lyrics support has also been expanded, where Rhythmbox can now pull lyrics from lrclib.net, read them from sidecar .lrc files sitting next to your audio, and grab lyrics embedded directly inside Ogg Vorbis, Opus, and FLAC files, using a tag that GStreamer recently added.

We round out this release with a couple of smaller fixes that are worth knowing.

The new playback backend, introduced back in 3.4.9 to replace the old crossfading system, is now switched on by default, and a bug that broke playback entirely whenever the crossfade duration was set to zero has been fixed.

The music player also dropped its old appdata.xml file in favor of metainfo.xml, bringing it in line with other GNOME projects.

Download this release

While it doesn't look like much on paper, Rhythmbox 3.5.0 manages to introduce some important quality-of-life upgrades that will go a long way in keeping the experience clean and the music player relevant.

Seeing that it just landed, most distributions haven't caught up yet. If you want to install it quickly, there's an unofficial Flatpak on Flathub.

But building it from source is the recommended way. The repo has all the required instructions and files for you to get it installed on your computer. If that's too much of an ask, then you could just wait for your distro's repositories to catch up with the new release.

Suggested Read 📖: AI Slop Keeps Flooding GNOME Extensions

The lone developer behind GNOME Boxes, Felipe Borges, has shown off a complete rewrite of the app as a Flatpak-only beta, featuring a modern interface foundation.

Balancing his day job at Red Hat and his usual GNOME Settings maintenance duties, Felipe says that he has been working on this by himself for the past two years, talking about his efforts at community events.

The first design call was going Flatpak-only. Boxes is a front end for libvirt and QEMU, so a lot of its behavior depends on what the host distro ships. Maintaining separate code paths for every distro isn't realistic for a single maintainer, so the new build bundles the entire virtualization stack itself instead of leaning on the host.

The second call is the one you will notice first. Boxes has moved to GTK4 and Libadwaita, dropping the old GTK3-based SPICE widget for a new display widget called Libmks. This is where the dated visual style finally goes away.

The third one was to fix Windows 11, where the rewritten Boxes can now successfully install it without requiring any manual workarounds or other kind of sorcery since it configures Secure Boot and a virtual TPM device on its own.

Moreover, a new VSOCK device gets around Flatpak sandboxing limits and lets you SSH straight into a guest, as long as it runs systemd v256 or newer. Early port forwarding support is also in, currently covering SSH and HTTP.

What's different?

Everywhere you see in the revamped Boxes is the result of the new interface components. Despite that, the app felt familiar right from the first look. Being a regular Boxes user, I just knew where to click.

The new virtual machine (VM) creation flow backed that up beautifully. I began installing Windows 11, and Boxes just pre-filled the memory and storage values on its own and set UEFI as the preferred boot method without me touching anything.

The installation itself went through without a hitch, but Windows then insisted on a Microsoft account before letting me anywhere near the desktop, so that's where I had to stop.

Still, the three-dot menu in the top-right of the VM window gave me plenty to work with before that point. I could take screenshots, send key combinations, and open a full Properties page.

None of it looks like what current Boxes offers today, btw. 🤓

The video above walks through that new Properties dialog. What used to be part of a single window with a header menu is now a dialog with a sidebar that houses seven sections.

General, Resources, Network, Devices, Snapshots, Logs, and Configuration.

Resources lets you adjust RAM and resize storage; Devices handles the boot order and removable media; Logs shows the actual commands Boxes is running under the hood; and Configuration hands over the raw Libvirt Domain XML to edit directly.

Similarly, the Network page lets you forward ports from the host into the VM, with toggles for SSH and HTTP. The Snapshots page lets you capture the VM's exact state at a point in time, then revert to it or delete it later.

Compare that to what current Boxes offers (shown above). The classic Properties window packs Resources, Devices & Shares, and Snapshots into just three tabs that are functional but very clunky.

Though there was a major snafu. The Windows 11 VM crashed soon after I created that snapshot. I couldn't pin down the exact cause, though me ejecting the ISO around the same time is a likely culprit.

Before all this, I had also tried installing EndeavourOS but kept running into an unsupported configuration error no matter what I tried. Switching the OS type between Generic Linux and Arch Linux and the firmware between UEFI and Legacy BIOS, none of it fixed the issue.

A couple of smaller things changed too. Getting out of a VM window now takes Super+Escape instead of the Ctrl+Alt combo current Boxes uses. There's also no dedicated fullscreen button, and F11 doesn't do anything either.

See for yourself

If you're on Ubuntu or another Debian-based distro, getting the beta running only takes a few terminal commands. You'll need to set up Flatpak first.

Our guide covers the whole process if you don't already have it installed. Once that's done, add the GNOME Nightly repo:

flatpak remote-add --if-not-exists gnome-nightly https://nightly.gnome.org/gnome-nightly.flatpakrepo

You can then check what's actually in that repo before installing anything:

flatpak remote-ls --app gnome-nightly

Once you spot org.gnome.Boxes.Devel in that list, install it with:

flatpak install gnome-nightly org.gnome.Boxes.Devel

This is still beta software, so back up any VMs you care about before testing it, and don't be surprised if you run into some of the rough edges mentioned above.

You can stay in sync with its development by keeping an eye on its code repository.

GNOME Shell Extensions are usually sourced from extensions.gnome.org, or "EGO" as the GNOME folks call it. Every submission on this portal is manually reviewed, and that review process has been under strain for months now.

We covered this back in December when GNOME added a rule to its EGO review guidelines rejecting AI-generated slop.

They did allow the use of AI for learning and code completion purposes, but generating the entire extension where the developer can't explain or debug it convincingly was explicitly forbidden.

Months later, and the deluge of AI slop hasn't slowed.

So last week, Javad Rahmatzadeh, the same developer behind that original rule, tried a different approach. Instead of just rejecting bad submissions after the fact, he wrote instructions aimed directly at the AI models generating them.

Making the clankers understand

Given that the review queue is still flooded with AI-generated extensions, and most of them repeat the exact same mistakes (bad practices, as he puts it), Javad's new approach skips the reject-and-explain method entirely.

Most of the guidance is about cleanup. Extensions need to remove timeouts, disconnect signals, and destroy widgets in a specific order inside destroy(). Javad also calls out AI models for adding boolean flags like _destroyed to guard against improper calls, when the instance should just be nulled out and never referenced again after destroy() runs.

Then there's the overengineering. AI models tend to wrap safe function calls in unnecessary error handling and add checks for methods that are guaranteed to exist. Javad traces this back to models trying to write code that works across several GNOME Shell versions at once, and his fix is simple.

Just target one version instead of covering every possible one.

The rest is about keeping code organized. Split logic across multiple files instead of one bloated entry point, keep related functions close together so cleanup is easy to check, and don't submit placeholder code with empty functions just to have something to show for it.

There's a separate rule aimed at the AI models themselves. Any AI-generated extension meant only for personal use has to ship with a comment saying so, telling the person not to upload it to EGO unless they actually understand the code well enough to maintain it. 👇

// Generated with AI for personal use.
// Do NOT upload to extensions.gnome.org (EGO) unless you understand JavaScript
// and can maintain this code.

Some thoughts

Clankers overwhelming open source contributors is not new news. We've seen more than enough by now to conclude that these bots will take the open source ecosystem down if not moderated with a strong hand.

What GNOME's Javad has done here is damage control. He and the other EGO reviewers have an important job. If they get inundated with AI slop that literally doesn't make sense, then that is a big loss for us, the GNOME users who install extensions to improve our desktop experience.

Keychron has introduced ZGM, short for Zephyr Gaming Mouse, an open source firmware project built for gaming mice.

It is built on Zephyr RTOS, the same real-time operating system that already powers ZMK for keyboards. In its announcement, Keychron portrayed the launch as a philosophy rather than a marketing angle, stating, "Open source isn't marketing for us. It's the default."

The firmware is set to debut alongside the Keychron G6 HE, with a launch window sometime between January and March 2027.

The details

ZGM isn't a mouse, and it isn't a driver or third-party tool you install after buying one either. It's firmware that runs directly on a mouse's own hardware, and only devices built with it will run it.

The G6 HE is the first confirmed device, and any wider adoption depends on whether other manufacturers choose to build around it. The project is released under the GPL-3.0 license, so anyone can inspect the code, modify it, or fork it for their own hardware.

Currently, it is in a very early stage of development, where the repository mainly holds project scaffolding and policy files right now. Keychron says firmware sources, board support, and flashing guidance are still being prepared.

The plan is for the project to grow into full Zephyr-based firmware, with configuration layers for different hardware variants and integration for sensors, buttons, scroll wheels, and lighting.

Wired support is expected to arrive first, with wireless support to follow, alongside build instructions, example hardware targets, and testing guidance for latency and reliability.

Want even more?

Keychron plans to support the chips Zephyr already works with, plus the sensors, buttons, scroll wheels, and lighting that go into a gaming mouse. Battery management for wireless builds is part of the plan too.

The roadmap starts where the project is now, then moves to building the actual firmware. After that comes getting buttons, scrolling, and sensors working, followed by basic USB support for wired mice.

Later steps cover different hardware setups, testing for lag and stability, and eventually wireless support and more customization. The peripherals manufacturer says this is just a tentative plan for now, not a fixed schedule.

Keychron already builds keyboards around QMK and is already going towards ZMK. Both firmwares have proven that open source software can deliver deep customization and long-term reliability through years of community development.

And, as mentioned earlier, ZMK already runs on the same Zephyr foundation ZGM uses, which likely shaped Keychron's choice to build on it for their new mouse instead of starting from scratch.

That said, ZGM has a long way to go before it matches either project. QMK and ZMK both carry years of contributions, documentation, and supported hardware, while ZGM's repository only has planning material.

Linux users gain from this

Gaming and productivity mice rarely ship with official Linux support. Most peripheral makers build their configuration software for Windows and macOS only, leaving buttons, DPI stages, and lighting profiles locked behind an app that never gets a Linux release.

Linux users are left relying on community projects that reverse engineer these devices instead, and even then, support only covers whatever protocols someone has bothered to document.

I personally use two Logitech mice, the G502 HERO and a wireless one that comes with the MK470 bundle, and neither has official software support on Linux. Both work fine plugged in directly, but configuring them means turning to third-party tools like Piper or Solaar.

If more manufacturers pivot towards an open solution like ZGM, us Linux users could at least get some QMK-like support (but for mice). Imagine the kind of keybinds and macros you could play around with.

Starling is a new open source Linux desktop environment. One developer built it by directing Claude for about six months, ending up with a working desktop that boots into its own session with a compositor and window manager.

Don't think of this as a themed shell bolted onto GNOME or KDE either. It brings its own X11 server, so apps like Chrome, Slack, and Zoom run on it without requiring any special modifications.

What is Starling?

Every part of it, like the shell, the compositor, the window manager, and the apps, are written in Swift, a language that has hardly been used for a Linux desktop before.

Most of the heavylifting here has been done using Claude, which was instructed to follow things like "Wayland only. Do not read, modify, or reference X11Server/ or X11 launch paths unless explicitly asked."

Under the hood, the framework running the whole desktop is a full port of Flutter's Dart framework to Swift. Starling brings a Wayland compositor written in C and its own X11 server, so older X11 apps still work.

That combination is what actually makes it a desktop rather than a demo.

For features, it has things like:

• A dock and Launchpad (app launcher).
• Floating and tiling window management.
• A shader-based glass effect on the dock and panels.
• Five first-party apps, including Terminal and an apt-powered App Store.

Taking it for a run

I tested Starling on an Ubuntu 26.04 LTS virtual machine, and its rough edges showed up almost immediately. Right after logging in, the resolution defaulted to a non-standard, letterboxed widescreen ratio of 5120x2160 at 2x scaling (according to Fastfetch).

I tried searching for an option to change this in the Settings menu, and the "Displays" page only had a slider for scaling, nothing for resolution itself. Things might be better if you install it on a computer directly, but that's a risk you are more than welcome to take. 🙂‍↔️

A few smaller things didn't work either. The search bar inside the Launchpad (app launcher) doesn't respond to typing, and none of the accent color swatches in Appearance actually apply once clicked.

The App Store itself works, technically. I installed Chrome through it without any errors, but the browser opened up oversized and ran noticeably laggy once it loaded. Not exactly the experience you'd want from one of the few apps the store puts at the top of its list.

Shutting the system down turned into its own small hunt. There's no power menu anywhere on the desktop, so I had to go into the Terminal and run sudo shutdown to turn it all off.

Early stages of abandonware?

Starling probably won't be the last project like this. If one developer directing an AI can produce a working desktop environment, compositor and all in about six months, expect a lot more attempts over the coming years.

Building something and keeping it alive are two very different jobs. Vibe coding gets you off the ground fast. Debugging what it produces is painfully slow, and that grind is usually what kills a developer's motivation before the project gets anywhere.

Installing Starling

Starling packages as a single DEB, built for Ubuntu 26.04 LTS on amd64. You will have to ensure that you have a Wayland-capable login manager (which the Desktop LTS release ships with).

From there, download and install the package:

curl -fLO https://github.com/starling-build/starling/releases/download/v0.2.1/starling_0.2.1-1_amd64.deb
sudo apt install ./starling_0.2.1-1_amd64.deb

Next, you have to either log out or reboot, then at the login screen click your name, open the session menu (a small gear icon at the bottom-right), and pick "Starling" from the list.

Mind you, it is quite early for this desktop. Currently on v0.2.1, the project itself is being handled by an anonymous human developer (or maybe AGI 😱?), so I would test it on a spare machine.