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.

The entire debate in the Linux and open source world these days is if AI generated code should be used or not.

As Linus told AI critics to fork the project or walk away, GKH took a more surgical approach. AI patches are fine elsewhere in the kernel, but drivers/staging is off limits.

The GNOME extensions review queue is still flooded with AI slop months after the no-AI rule went in. The latest attempt to slow it down is a guide written directly for the bots doing the generating, covering the bad patterns that keep showing up.

Keychron's doing for mice what QMK did for keyboards. ZGM is a GPL-3.0 open source firmware built on Zephyr RTOS, coming first to the G6 HE in Q1 2027. If it takes off, Linux users are the ones who gain most since practically no gaming mice ship with official Linux configuration support.

Another Ubuntu deb is becoming a Snap. hwctl, the CLI tool behind Ubuntu Pro and hardware certification checks, is going Snap-only for better sandboxing and tighter GNOME Control Center integration.

Nine months since the last release and nearly a decade in the 3.4 series, Rhythmbox 3.5.0 has finally arrived. Podcasts have seen the most work, where played episodes are now marked, notifications are better, and there's a new gPodder.net plugin for syncing feeds.

Following up on the LVFS sponsorship story from earlier. NVIDIA has now joined as a premier sponsor, bringing the total to four OEM sponsors and hitting the funding target the project set for itself.

🧠 What We’re Thinking About

GNOME Boxes hasn't looked modern in a long time. The rewrite, in beta now on GNOME Nightly, fixes that, moving to GTK4 and Libadwaita while opting for a Flatpak-only approach.

🧮 Linux Tips, Tutorials, and Learnings

If you use Kitty and haven't touched its Kittens yet, then you are missing out! These are small built-in programs that extend the terminal without needing external tools, covering everything from an interactive theme switcher and font picker to a drop-down terminal, a fuzzy file chooser

If your Linux Mint desktop feels a bit plain, Cinnamon's extension manager provides a set of visual effects worth trying. Effects like burn my windows, wobbly windows, magic lamp, and a desktop cube for workspace switching are available.

A free nine-chapter bash scripting course for beginners, covering variables, arguments, user input, arithmetic, arrays, strings, conditionals, loops, and functions.

👷 AI, Homelab and Hardware Corner

Want to take back control of what you read without an algorithm deciding for you? We have covered ten self-hosted RSS readers, with notes on which ones are actually built for self-hosting and which ones technically work but their own developers don't recommend it.

The list is for self-hosting. For normal desktop usage, we have a separate list of RSS feed readers for Linux. It's a bit old, but most of the apps are still in active development.

✨ Apps and Projects Highlights

While it is yet to arrive on Linux, the terminal-browser is worth a look. It is a real browser that runs inside a terminal.

📽️ Videos for You

You can master AppImage installation by following a few simple steps.

💡 Quick Handy Tip

Transform Dash to Panel into a dynamic, Plank-style dock with ripple hover animations by tweaking a few key extension settings.

First, navigate to the "Position" tab in the Dash to Panel settings. Disable every item on the panel except for the "Taskbar", and change the panel size or length mode to "Dynamic" so it shrinks to fit your active app icons.

Next, open the "Fine-Tune" tab and enable "Keep original gnome-shell top panel." This restores the standard GNOME top bar for your clock, system status icons, and menus while leaving your new dock at the bottom or side.

Finally, switch to the "Style" tab and enable "Animate hovering app icons." Click the settings gear next to this option to choose and adjust your preferred hover effect.

🎋 Fun in the FOSSverse

Do you know what kind of Linux user you are?

Well, it's obvious which one is the winner here. 😉

🗓️ Tech Trivia: IBM launched the System/23 Datamaster on July 28, 1981, just two weeks before the IBM PC. The same engineers built both, and what they learned on the Datamaster helped shape the desktop computer as we know it.

🧑‍🤝‍🧑 From the Community: Pro FOSSer Neville has shared his experiment running Lumina desktop on antiX-26.

For years I thought I had strong opinions on Linux distros. Ubuntu was too heavy or it felt. Arch was too fiddly. Kali was surprisingly practical (don't judge me).

Looking back at nearly a decade of distro hopping, I realize I had the whole thing wrong.

It was never really about the distro. It was about what desktop environment sat on top of it.

My Linux story starts with Mint

The first Linux distribution I ever installed was Linux Mint Cinnamon, around 2017. Linux Mint is what made me think Linux was actually livable. The desktop made sense. Things were where I expected them to be. It was Ubuntu underneath, sure, but that's almost beside the point; what mattered was that the experience felt considered.

I didn't move to Ubuntu until 2019. I ran it for about six months. Then I left.

The reason I told myself at the time was that Ubuntu felt slow on my hardware. I had an i3 first-gen Intel machine. Ubuntu felt sluggish in ways that bothered me. I blamed Ubuntu.

Here's what I discovered later: the culprit wasn't Ubuntu. It was GNOME.

GNOME is a beautiful desktop. I'll give it that. But on modest hardware, it feels less responsive, and even at times, it completely freezes. It shows up in the half-second delays, the slightly-too-late window redraws, and the sense that the machine is working harder than it should be.

XFCE saved my Linux life

The thing that actually kept me on Linux, the desktop environment I kept coming back to, is XFCE.

XFCE doesn't win "most beautiful desktop" polls. But I ran it on that i3 first-gen machine, and it ran smoothly out of the box. I ran it on a Core 2 Duo at some point.

Internet browsing, YouTube, writing articles, Django, and Python development, all of it, without considerable delay. XFCE in that sweet spot between functional and fast is something I haven't found matched elsewhere for low-resource machines.

I did try KDE. More than once, actually, I wanted to like it. I kept going back, hoping something had changed. What I found, every single time, was that a single click could take three to four seconds to get a response. It felt like the desktop was thinking about whether it wanted to comply with my input.

Even recently, a few weeks ago, I tried both CachyOS and EndeavourOS as live USB sessions in a VM, and both now default to KDE. I still felt it. That sluggishness hasn't gone away for me, and I've stopped trying to convince myself otherwise. XFCE remains my benchmark for a desktop that gets out of your way.

My Kali Linux Journey

After six months on Ubuntu, I switched to Kali Linux. And not for the reason you might think.

I had not suddenly become a penetration tester. I didn't have a burning interest in cybersecurity. I switched because Kali ran better on my hardware than Ubuntu did and because I was already comfortable with APT commands from my Mint and Ubuntu days, so the transition cost was essentially zero. I had access to the same package manager, familiar commands, and a lighter desktop.

I chose a distribution built for security professionals over the supposed beginner-friendly option. I chose not because of anything Kali offered that I needed, but because Ubuntu had made itself too heavy for the machine I owned.

The Arch Linux rabbit hole

By mid-2021, I'd been reading about Arch Linux mainly through all the BTW memes. The idea of an "expert's distro" appealed to me.

So I stayed up one night and tried to install plain Arch. I did not finish the installation.

What struck me was running commands to create partition tables and configure Wi-Fi. It was baffling. Not "this is hard, but I'll figure it out." More like: why has someone decided that an operating system installer should work like this?

I tried Fedora after. Then I tried Debian. In both cases, on my ageing hardware, boot times were bad enough that I found myself questioning whether the whole exercise was worth it. With Debian, I faced an internet connectivity issue as well.

The thing that drew me to Arch was Pacman and leanness. I kept asking myself: why can't the installation be as simple as Ubuntu's, but give me the system I actually want?

That's when I found EndeavourOS. It required no manual commands to connect to Wi-Fi. No writing partition tables by hand. Just select a disk, set your timezone, keyboard layout, and hostname, and you're done.

And when I booted in for the first time, I found the default looks fascinating. The default terminal: black background, blue accents, immediately distinctive. The default wallpaper was something I actually liked enough not to replace it, which almost never happens.

I used EndeavourOS for four-five years, I think.

What those "Arch" years looked like

I want to be honest about this stretch, because people who recommend Arch-based systems sometimes skip over the rough parts.

I hit the initramfs wall three or four times. That's the experience of booting your machine and being dropped into a minimal emergency shell with no desktop, no obvious path forward, just a blinking cursor.

The first time it happened, I didn't know recovery was possible. I reinstalled the entire system. Only later did I learn to boot from a live EndeavourOS USB, use arch-chroot to get inside the broken system, and rebuild the kernel from there. The culprit was usually a problematic package upgrade.

I also ran into keyring mismatches more than once, that particular class of Arch-ecosystem errors where package signatures don't line up, and installations fail with cryptic messages. The fix I settled on:

sudo pacman -Syu archlinux-keyring endeavouros-keyring

I'm sharing them because this is the actual texture of running an Arch-based system. It's manageable. I managed it. But a beginner who hits the initramfs wall on their third week of Linux use is probably not going to calmly research arch-chroot. They're going to conclude that Linux is unstable, and they were right not to trust it.

AntiX chapter and the limits of anti-systemd

Around mid-2024, I discovered AntiX Linux and ran it alongside EndeavourOS for roughly two years. It taught me a lot about IceWM as a window manager. For someone with a potato-tier hardware, old machines that most distributions have quietly given up on, AntiX is remarkable.

But I hit the systemd wall eventually. AntiX deliberately avoids systemd, which is philosophically interesting but practically limiting. A growing range of applications that assume systemd exists simply don't work cleanly. And I'll be honest: the AntiX GUI is not appealing. It's functional, and it works. But there's a visual coarseness to it.

After two years, I started thinking about moving on.

Returning to Kali for real this time

Now I'm back on Kali, but the circumstances are completely different. I really have an interest in cybersecurity, particularly bug bounty work. I'm running a Dell laptop with an i5 8th gen and 12GB of RAM now.

Two months in, I've had one issue worth documenting. Kali ships Firefox ESR, and if you want to remove it, the system objects, because Firefox ESR is part of the kali-xfce4 metapackage, and removing it wants to take other things with it.

The workaround I found: install the equivs package, use it to create a dummy Debian package with the same name as the dependency you want to satisfy, install that dummy, and the system believes the dependency is met. It's inelegant, but functional.

Where I am now: leaving XFCE for window managers

A lot is happening in the Linux desktop world around Wayland, Hyprland, and tiling window managers. The thing that excites me about this space, and I've come to believe this more firmly the longer I've used Linux, is the plain-text configuration model.

Your entire environment lives in text files you can read, version-control, back up, and restore. That's a kind of ownership over your system that no GUI settings panel can replicate.

I spent this past couple of months trying several options: Niri, Sway, and Scroll WM. I eventually settled on Mango WM as my main environment. I know, calling it a desktop environment feels technically wrong, but it's what I live in. The configuration philosophy suits how I think about my system.

That means I'm saying goodbye to XFCE after years of loyalty. Not because XFCE failed me, but because I've moved somewhere new.

Desktop environment, not distro

Looking back at all of it, I did not like Mint just because it's Mint. I felt comfortable with Cinnamon. I did not dislike Ubuntu because it's Ubuntu. It's because GNOME demanded more of my old hardware than the hardware could give.

Every distro-hop I've listed here, from Kali to Arch to AntiX to Mango WM, was really a hop between desktop environments and window managers wearing a different distro's name. The package manager changed. The installation experience changed.

What actually decided whether I stayed or left was always what sat on top: how fast it responded, how much RAM it wanted, whether I could read its configuration in a text file, how it felt to use.

The desktop environment mattered more than the distro.

If you're picking your first Linux setup, this is the question worth asking before you pick a distro: what desktop environment does it ship, and does that match your hardware and your preference?

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

I have argued this in the past as well. RSS feeds are the simplest way to get out of the algorithm's web.

Every platform wants to decide what they think you should read. RSS feed is the resistance. You have a list of your own favorite websites that you trust (like It's FOSS), you add these sources in the feed reader and you get to see all the newly published articles from the sources you want.

There are several feed readers for Linux desktop. Even email clients allow you to read from RSS feeds.

But they are confined with a single machine. Since self-hosting is increasingly (and rightly) being popular these days, you can try self-hosting feed readers in your homelab. This should allow you to access your feeds on all the compatible devices on the home network.

And if you want to go the self hosting way, I have a bunch of suggestions for you to explore.

For this list, I looked at how easy each tool is to actually self-host with Docker, whether it can be used with mobile apps (through the Fever or Google Reader API), whether it can generate a feed for a site that doesn't provide an RSS feed on its own, and whether there's a real hosted option if you'd rather not run the server yourself and yet pay for an open source software service.

1. Yarr

Yarr (short for "yet another rss reader") is a single Go binary with an embedded SQLite database. No separate database server, no multi-container setup, just one file you run.

You can run it as a desktop app with a system tray icon on Linux (and Windows and macOS), or point the same binary at a server and use it headlessly over the browser. It picked up Fever API support a while back, so it now works with Fever-compatible mobile clients like Reeder and Unread, something it didn't have for most of its life.

It's built for single person use. There's no multi-user support and OPML handling is basic compared to FreshRSS or Miniflux, so double check your import works before you commit to it.

Yarr is open source under the MIT license and self-hosted only. There's no official paid hosting.

2. Fusion

Fusion is a newer, lightweight reader built with Go and TypeScript. It's pretty much like Yarr.

It ships as a single binary with SQLite, has a proper PWA you can add to your phone's home screen, and supports the Fever API for third-party clients like Reeder, Unread, and FeedMe.

The official Docker image is here, and there's a docker-compose example in the README if you want to get it running fast. It deliberately skips AI features, which the project states outright as a design choice rather than an oversight.

There's no official first-party hosted version yet, though the community has put together one-click templates for Fly.io and Railway if you don't want to manage a server yourself. It is also available on PikaPods.

3. CommaFeed

CommaFeed is a Java and React reader built to feel like the old Google Reader. I am not sure if that's a positive thing or not.

It supports the Fever API and push notifications for new articles, plus a browser extension for quick access. The official Docker image is on Docker Hub, and native binaries are also published if you'd rather skip containers. OPML import and export both work as expected.

If you don't want to host it yourself, there's a free public instance at commafeed.com funded by donations, or you can use PikaPods for one-click hosting starting around $1 a month with a $5 welcome credit. PikaPods shares 20% of that revenue back to the CommaFeed project.

4. Stringer

Stringer bills itself as a self-hosted, "anti-social" RSS reader, meaning no sharing features, no social layer, just a clean list of articles.

It implements a Fever API clone, so it does work with Fever-compatible mobile apps, even though its client ecosystem is smaller and less talked about than Miniflux's or FreshRSS's.

Docker is the common way to deploy it, going back to the original mdswanson/stringer image and continuing under the current stringer-rss organization on GitHub. Feed import has historically been a little clunky, closer to adding one URL at a time than a smooth bulk OPML migration, so test that step before you commit your existing subscriptions.

Stringer is open source under the MIT license and self-hosted only, with no official paid hosting.

5. Miniflux

Miniflux is the reader for people who just want to read their feeds and nothing else. It's deliberately opinionated about staying small, and plain looking. You can understand why there is a 'mini' in its name.

It's a single Go binary that only works with PostgreSQL, no MySQL or SQLite option here. It supports both the Fever and Google Reader APIs, so it plugs into most mobile RSS clients without a dedicated app of its own.

Docker images are published to Docker Hub, GHCR, and Quay with ARM and RISC-V support, alongside Debian and RPM packages if you'd rather skip containers entirely. OPML import and export both work, including URL-based imports.

For saving articles, Miniflux integrates with more than 25 third-party services including Wallabag, Pinboard, Instapaper, and Linkding, and it can auto-send bookmarked entries to whichever one you use.

If you don't want to run it yourself, the official hosted version costs $15 a year with a 15-day free trial, and it runs the exact same open-source code as the self-hosted version.

6. FreshRSS

FreshRSS is the other half of the decision everyone ends up making. Where Miniflux stays deliberately small, FreshRSS goes the other way: multi-user, extension-friendly, and closer to a full Feedly replacement.

It supports SQLite, MySQL, and PostgreSQL, so you can start tiny and grow into a bigger database later without switching tools.

It's multi-user, with an anonymous read-only mode if you want to share a public instance. Thanks to WebSub, it can receive instant push updates from compatible sources instead of waiting on a polling interval.

It also has built-in web scraping, so it can generate feeds for sites that don't publish RSS at all, no separate bridge tool required for basic cases.

Official Docker image is available for easy deployment. Extensions and themes fill in most of the gaps in the default interface.

7. Tiny Tiny RSS

Tiny Tiny RSS has been around since 2005. In 2025, the original developer quit the project and a long-time contributor forked the project to GitHub the same month and has kept development going since.

Its plugin system exposes Fever, FreshRSS, and Google Reader compatible APIs for other mobile clients. Docker is the recommended install path, though it seems a bit heavier, more multi-container setup than Miniflux or FreshRSS.

OPML import and export both work, and its plugin ecosystem covers full-content scraping similar to a built-in readability tool.

8. NewsBlur

NewsBlur is both a hosted SaaS product and a fully self-hostable open-source reader.

It has native apps for iPhone, iPad, Android, and Mac, and it syncs with third-party clients like Reeder and NetNewsWire too. OPML import pulls in feeds and folders from Google Reader, Feedly, or Inoreader exports.

Its standout feature is "Web Feeds," which can follow a website for updates even if it has no RSS feed at all, by watching the page for changes instead of relying on a bridge tool (mentioned later).

It also supports saved stories with an "intelligence" training system that learns what you want to see more or less of. There are a few more AI features here to explore.

Self-hosting is the heaviest lift on this list. The stack includes PostgreSQL, MongoDB, Redis, and Elasticsearch, run through make nb with Docker Compose. All this realistically needs a few gigs of RAM to run comfortably.

The hosted version has a free tier limited to 64 sites, with Premium at $36 a year (a 30-day free trial) unlocking unlimited feeds, full-text search, and notifications.

9. Feedbin

Feedbin has one of the more polished reading experiences on this list but you should know that the maintainer doesn't recommend self-hosting it, even though you can.

Feedbin's own documentation says its goal is to be a great web-based service, and that this is "at odds with being a great self-hosted RSS reader."

It doesn't recommend running it in production unless you have real time to configure it, and instead points people toward community Docker projects like feedbin-docker if they want to try anyway.

That's a starkly different stance from Miniflux or FreshRSS, which are built with self-hosting as the primary use case.

If you do use it, the syncing story is strong. It works with Reeder, NetNewsWire, Unread, and ReadKit through its API, and it turns newsletters into feeds by giving you a unique subscription email address. It also does full-content extraction for partial feeds and supports podcast playback with resume.

The hosted version costs $7 a month or $70 a year, with a 30-day free trial.

10. Glance

Glance is the odd one out to close on. It's not an RSS reader, it's a self-hosted dashboard that happens to fetch RSS feed from websites alongside Reddit, YouTube, weather, and server stats. Remember Google homepage from twenty years ago?

If you've ever wanted your feeds sitting on the same page as your homelab status and the weather instead of in their own dedicated app, this is that.

Configuration is a single YAML file rather than anything OPML-based, so backing it up is just copying that file. There is an official docker image and it also ships as a single binary under 20MB for Linux, macOS, Windows, FreeBSD, and OpenBSD.

It's picked up a lot of attention fast, with more than 36,000 GitHub stars and still climbing. It's not going to replace a dedicated reader if you follow hundreds of feeds seriously, but as a "everything I check every morning" page, it's difficult to be ignored.

Bonus: RSS-feed generator apps

What I discussed so far are the self-hostable RSS feed readers. There are a couple of additional tools that help you generate or find RSS feeds.

For example, RSS-Bridge is a companion tool that generates RSS and Atom feeds for sites that don't publish one, and it's meant to sit in front of whichever reader from this list you actually pick.

Similarly, RSSHub is the bigger sibling to RSS-Bridge, another feed generator rather than a reader, built on Node and TypeScript with a much larger route library.

Easily Start Your Homelab with ZimaBoard 2

If you want to start your own homelab but not sure if you can manage all the technical things, try ZimaBoard. Zima devices come with ZimaOS, a very friendly operating system that easily allow deploying containerized self-hostable apps. This is how I started my homelab journey.

Explore ZimaBoard 2

So, which self-hosted RSS reader should you actually use?

I have not included some older, once-popular tools like Winds, Leed, FeedHQ etc in this list because they're no longer actively maintained.

As for what to actually run: if you want the smallest possible footprint, go with Miniflux. If you want more features and don't mind a bit more setup, FreshRSS is the safer multi-user pick. If your want all things at a glance, go with Glance. NewsBlur is a good option if you don't mind paying.

But at the end, the decision is totally yours. You can go through individual projects, see their features, try deploying them on your own and make a decision accordingly.

What are you using to read your feeds these days? Let me know in the comments, and if you've found something newer than what's on this list, I'd love to hear about it.

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.

Kitty is a popular terminal emulator that supports many modern features. Focused on power users, it offers a wide range of customization that other terminals often lack.

For example, it includes a functional image display protocol and smooth cursor animations.

I have shown Kitty tweaking in the past, and in the regards, I would like to discuss Kittens today.

Kittens are functional units that extend the features of the Kitty terminal or work as standalone programs. They have direct access to the running Kitty instance.

Kitty comes bundled with several of these kittens, written in Go, which we will explore in detail later. You even have the option to create your own custom Kittens in Python, if you find a specific need that hasn't been solved yet.

Some Cool Default Kittens

Themes

Let's start with the most popular tool first. If you use Kitty daily, you have likely come across this utility at some point.

Themes is a kitten that allows you to change your terminal color scheme interactively without editing any configuration files. Kitty includes a wide variety of preset themes that you can access by running a simple command:

kitten themes

In the overlay window, you can easily scroll through both dark and light themes to see a live preview. Once you find one you like, just press Enter and follow the prompts to set it as your preferred theme.

In my opinion, this is a feature I really miss when using Ghostty. While Ghostty has a similar interface, you still have to manually edit your configuration file to apply the theme name after you pick one.

Fonts

If you have found a new font and want to set it as your terminal choice, this kitten has you covered. You can launch the interactive interface directly in your terminal using a simple command:

kitten choose-fonts

This tool allows you to perform several actions within a single interface. You can select new fonts, preview how they look, and even fine-tune specific font faces.

The utility makes it much easier to manage your typography without guessing how a font will appear in your workspace. It handles the complex parts of the setup so you can focus on finding the perfect look.

Choose files

Choose files is a comprehensive file picker designed for Kitty and other GUI applications on your system. It functions similarly to fzf but is specifically optimized for finding and managing files.

This tool offers several powerful features, including the ability to select multiple files at once. It intelligently respects .gitignore rules in your git directories to keep your workflow clean.

To use it, run:

kitten choose-files

You can also select non-existent files to trigger a "save file" option or choose entire directories. In my opinion, this file picker will completely change the way you interact with files in your terminal.

Quick access terminal

If you remember Yakuake in KDE, you are already familiar with the concept of a drop down terminal for quick tasks. Kitty offers similar functionality through the Quick Access Terminal Kitten.

You can launch this feature at any time using a simple command in your terminal:

kitten quick-access-terminal

If you want to personalize the experience, you can customize the tool using a specific configuration file. Simply create or edit quick-access-terminal.conf inside your ~/.config/kitty/ directory to adjust its behavior.

GPU accelerated dock panel

The Panel kitten is something truly special. It creates a desktop panel for you that functions much like i3bar.

While some might feel this is a bit overpowered for a terminal application, the panel is quite interesting for minimal use cases. It even allows you to set tools like btop as your actual desktop wallpaper.

In my opinion, this is an incredible feature for anyone who loves a unique workspace. You heard that right, and here is a great example of how it looks in action.

A diff tool

The diff kitten is an excellent tool available directly within Kitty. It offers several advanced features like side-by-side comparisons, syntax highlighting, and even image diffs or recursive directory comparisons.

To use it, you simply pass the file names as shown in the command below:

kitten diff file1 file2

Other interesting Kittens

I use the terminal daily for standard update tasks and editing text files. If you are deeply involved in terminal usage, there are many kittens available for very niche use cases.

For example, the Broadcast kitten allows you to type text simultaneously across multiple Kitty windows. There are also SSH related kittens designed for editing files and even a specialized SSH supported clipboard.

In my opinion, these specific tools are essential for power users who manage remote servers regularly. Feel free to experiment with these options to make your terminal life significantly more productive.

Assign keybindings/alias for quick access

All these kittens can be bound to keyboard shortcuts or aliases so you don't have to manually run the command every time. This makes your workflow much faster by giving you instant access to your favorite actions.

I will show you how I mapped the kittens in my own configuration file. It is a straightforward process that keeps everything organized and easy to access.

The most important step is to make sure your chosen keys are uniquely assigned. You want to avoid any conflicts with existing terminal options or system-wide shortcuts.

In the below code, I mapped the F1 key to get the file chooser kitten in multiple file select mode.

map f1 kitten choose-files --mode=files

Adding the following line to your shell configuration file (~/.bashrc) to add an alias to the diff tool:

alias d="kitten diff"

Now, you can run:

d file1 file2

To get the difference between them.

Another example, let's map the F2 key to get a quick access terminal:

map f2 kitten quick-access-terminal

Wrapping up

So, we have seen how kittens can improve your terminal productivity. While most of these have separate alternatives like fzf for file selection or difftastic for diffs, integrating them directly into your terminal with a clean UI is commendable.

Kitty also offers a desktop-ui kitten that lets you integrate the file picker into all your GUI apps. Since this can cause issues with some applications and is something I use rarely, it remains out of scope for this guide.

In my opinion, the seamless integration of these tools makes Kitty feel much more cohesive than a standard terminal emulator.

Did you find any of these kittens useful enough to replace your existing tools?

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.

Let's see what's happening in the Linux and open source world this week.

Ubuntu 26.04 quietly stopped notifying users about available updates, and it turns out that was intentional. The tray icon was switched off by design, and without it, the notifier never fired. Security patches kept installing themselves in the background, but non-security updates just sat there waiting.

Collabora Online turns 10 with the 26.04 release, pulling in the same AI, Calc, Writer, and Impress improvements from CODE 26.04. The AI component is off by default and points to whatever model your organization already runs, not theirs.

Codeberg members voted to ban projects mostly built from AI-generated code and to formally commit the platform to never using user code or data for AI training. They were unhappy with how AI crawlers hit their servers, and maintainers found themselves drowning in low-effort AI contributions to review.

And they are not alone in it. GCC compiler is also taking a stand against AI-slop coding but they have taken a little more moderate approach to it.

OpenUK is calling on the UK government to build its own foundation along the lines of the Linux Foundation after watching British-born open source work repeatedly end up under US governance.

FireDragon, Garuda Linux's default browser, got a full rewrite with the v13 release, dropping the Floorp base for a new codebase. Its Welcome dialog now handles common privacy toggles like ResistFingerprinting and prefetching without needing about:config, TLS 0-RTT is on by default, and the pre-installed extension list is trimmed to just uBlock Origin and Flagfox.

I know we are quite early, but Ubuntu 26.10 "Stonking Stingray" is shaping up to be a busy interim release. Worth bookmarking if you want to stay updated on what's coming.

🧠 What We’re Thinking About

An Atlanta man is facing a federal indictment for evidence destruction after CBP agents at the airport demanded his phone passcode, entered it, and watched the device wipe itself. GrapheneOS is in the news for this reason.

🧮 Linux Tips, Tutorials, and Learnings

Seeing that we are on the topic, our Markdown beginner's guide covers all the basics you'd need: headings, links, images, lists, bold and italics, block quotes, and line breaks, with a downloadable cheat sheet to keep handy.

Dark mode fans, this one's for you. 15 GTK themes covering most tastes, from Dracula and Catppuccin to Gruvbox, Graphite, and Fluent Dark for anyone coming from Windows 11.

If you use Ubuntu, you should know about these keyboard shortcuts. Makes the desktop usage a bit more efficient, or at least that's what I feel when there are keyboard shortcuts in my muscle memory and I don't have to reach for the mouse.

Getting constant buzz noise from your desk speakers in Linux? You don't have to live with it. Try this fix here.

👷 AI, Homelab and Hardware Corner

My hands-on review of SunFounder's flagship Pi 5 case, the Pironman 5 Pro Max, complete with two small local AI projects built to test it.

Hopefully, next week I'll share how I have set up my homelab on ZimaBoard 2 with AdGuard, Nginx Proxy Manager and Tailscale to have all the services on a .internal domain and accessible from outside the home network.

By the way, I tried out a Markdown editor built specifically for developers who work on documentation in Git repos. Ferrite has a built-in terminal, folder view, Git status, split pane, and diagram support. It seemed too good to be true until I saw that it is "100% AI coded". Now I am not sure if I should be using it.

✨ Apps and Projects Highlights

I knew this day would come. And it is finally here. Someone has 'vibe coded' a Linux distro. Not recommending to use it, of course.

But something you should know about because I have a feeling that, like AI-developed software, we may soon start seeing lots of AI-coded distros. The problem is that it is easy to launch projects, but maintaining them is a different story altogether.

Not everyone wants their music player rearranging their carefully organized folders into an artist-album grid. SonicTree just shows you your files as they are on disk.

📽️ Videos for You

Last time we talked about GNOME shell extensions that can help you be more productive. But did you know that you can use Extension Manager to manage those?

💡 Quick Handy Tip

If you are an Xfce user with a multi-monitor setup, then you can span the Xfce panel across monitors.

First, right-click on the panel you want to span, and then go to Panel → Panel Preferences.

Here, in the Display tab, set Output as Automatic and enable the “Span monitors” checkbox.

🎋 Fun in the FOSSverse

Can you spin the wheel and uncover the command?

Peace over chaos, always. 💪

🗓️ Tech Trivia: On July 23, 1985, Commodore unveiled the Amiga 1000 at New York’s Lincoln Center, stunning audiences with 4,096-color graphics, 4-channel stereo sound, and true preemptive multitasking.

Designed around a custom coprocessor chipset and a Motorola 68000 CPU, it debuted at a price of $1,285.

🧑‍🤝‍🧑 From the Community: The deluge of Flock cameras plaguing streets in the U.S. has FOSSers talking about a Big Brother situation.

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.