Back then, Jon gave speech-to-text and text-to-speech as one of the examples of what an implicit feature could look like. Weeks later, one piece of that puzzle has materialized in the form of Myna.

While the tool is early in the development cycle, it is set to debut with Ubuntu 26.10, due out in October.

AI-powered accessibility begins

Jean-Baptiste Lallement, Canonical's Director of Engineering for Ubuntu Desktop, posted the announcement, saying that voice dictation has become a common feature across modern platforms.

For Ubuntu 26.10, the initial version of Myna is expected to be a desktop dictation tool built around GNOME on Wayland with a push-to-talk mechanism gatekeeping when your microphone accepts input.

Using it means holding a hotkey, speaking, and letting go. A small activity indicator shows while it is listening, and the transcribed text lands wherever the cursor was sitting when dictation started.

How will it work?

Recognition itself happens inside a sandboxed component called the Canonical Inference Snap, while a Speech Orchestrator manages the session and an Audio Adapter handles whatever the microphone picks up, denoising and chunking it before it ever reaches the model.

The snap is meant to carry speech models in three sizes, lightweight, default, and quality, along with a runtime to match whatever hardware is being used to run Myna. May it be an NVIDIA GPU, an Intel NPU, or just a CPU.

And before you yell, "my data would be sent to cloud servers!" know that speech recognition will happen locally, and an internet connection is not needed once the appropriate model is installed.

Moreover, text only appears once it is finalized, so you won't see half-formed words flicker the way some assistants show live captions. The audio data won't be sticking around either, being stored in a small in-memory buffer that gets discarded the moment the session ends.

Features like dictation into password fields, wake words, continuous listening, voice assistants, voice commands, translation, speaker identification, and automatic language detection are all off the table.

The fine print

None of this is locked in yet. The GitHub repository holds nothing more than a license, a README, and a folder for the documentation and architecture specs.

And, going by how past features have landed on interim Ubuntu releases, we could see Myna show up in the daily builds of Ubuntu 26.10 in the coming weeks.

You should also know that Canonical is looking for feedback before the specs for Myna are finalized, especially from people who already rely on dictation or assistive tools on Linux.

You see, game and film projects have a workflow where they have to mix source code with large binary files such as build inputs, big data files, and other generated content. The problem is that most existing version control tools were not built to handle that kind of combination well.

Git handles large binary files through an add-on called Git LFS, rather than treating them as a built-in part of the system. Perforce manages binaries better, but it needs a live connection to its server for routine tasks, and it is a closed, proprietary system that other companies cannot build tools on top of.

Epic Games says none of the available systems combine binary handling, offline work, and a fully open specification together, which is why it built its own.

Suggested Read 📖: GitHub Alternatives to Host Your Open Source Projects

How does it work?

Lore keeps a server running as the authority for who can access a project and how conflicts get resolved, but everyday work like saving changes, recording a commit, or switching branches happens entirely on your machine, without needing an internet connection.

Every piece of content is given a unique fingerprint and stored only once, so identical data is never duplicated across files or branches.

It also has a verification system, so the structure of every revision can be checked for tampering or corruption. Large files are broken into smaller pieces, so editing one part of a multi-gigabyte file does not require re-uploading the whole thing.

And, by default, your machine only holds the files you are actually using, since Lore pulls down a file's data only when something asks for it.

The core library, server, and CLI are all written in Rust, with official SDKs for JavaScript, Python, C#, and Go. Everything routes through the same interface, so the CLI is not a special, privileged way of using Lore.

Any tool built using the same interface can do everything the CLI does.

Get started quickly

The project has not reached a stable release yet, with the most recent release being 0.8.3, and Epic Games is warning that interfaces and storage formats could fluctuate from release to release.

You do not need to have Rust installed or set up a container to try it out. One install script does the whole process of grabbing the CLI and server binary, dropping them into your PATH, and spinning up a server on your machine.

The official guide lists the script to get it configured on Linux:

curl -fsSL https://raw.githubusercontent.com/EpicGames/lore/main/scripts/install.sh | bash -s -- --demo

Beyond that, if you have any questions or are just looking to have a conversation surrounding it, there's a Discord server you can join that has people from the development team and the Lore community.

yay, the most popular AUR helper for Arch Linux, just put out a release aimed at tackling that mess on the user level, introducing two new features that make it easier to spot a risky package before you install it and to automate the review work yourself.

Let's check it out! 🤓

New tools to spot malicious packages

Search results, the yogurt prompt, and the upgrade menu all carry a new timestamp now, showing how long it's been since a package's PKGBUILD last changed. This gives you a heads-up on which packages might be worth a closer look before installing.

Jo Guerreiro, the maintainer of yay, clarified that the number by itself doesn't accomplish anything. Something edited last week isn't automatically dangerous, and something untouched for years isn't automatically clean.

This is meant to be just one extra signal to weigh before you commit to an install.

The other major addition here is support for Lua-based hooks and configuration, letting you script how yay behaves at different points in the install and upgrade flow. You can now drop a file at $XDG_CONFIG_HOME/yay/init.lua, usually ~/.config/yay/init.lua, and yay will pull both settings and hooks straight out of it.

Leave that file out entirely and nothing Lua-related runs at all. config.json doesn't go away either, init.lua sits above it and can override what's already there, while flags you pass on the command line take priority over everything else.

One of the new hooks, UpgradeSelect, kicks in partway through yay -Syu, once yay has worked out what needs upgrading but hasn't yet put the package exclusion screen in front of you.

Two more hooks come into play before the actual install runs, just later in the sequence than UpgradeSelect.

AURPreInstall triggers right after a PKGBUILD is fetched, early enough to abort an install before you've seen any menus. By the time makepkg --verifysource finishes pulling and checking the source, AURPostDownload fires, and at that point a script can look at the PKGBUILD next to the actual files it downloaded, still ahead of the install.

Beyond those, the v13 release also adds hooks for filtering search results and for taking action once a package finishes installing. The rest of it is mostly cleanup work like restoring missing locale files, and the ALPM executor picks up a proper log callback and a new Debug method.

You can get yay running on your Arch Linux or Arch-based setup by cloning it from the AUR and building it with makepkg:

git clone https://aur.archlinux.org/yay.git
cd yay && makepkg -si

The comeback is picking up pace too, with a lineup that already includes multiple Commodore 64 Ultimate editions, a C64X PC, and a licensing program that invites outside builders to use the name.

Now, they have announced a return to the phone market, and not in the doomscrolling glass-slab avatar we are all used to, but in a retro, very equippable flip phone format.

Making Flip Phones Great Again

The Commodore Callback 8020 is what comes out when a flip phone skips Android and goes toward a privacy-respecting Linux-based mobile operating system instead. In this case, Jolla's Sailfish OS, known for having great Android app compatibility without Google's surveillance baked in.

Jolla's CEO, Sami Pienimäki, says that it was chosen after Commodore evaluated competing platforms, citing Sailfish OS' design language and stance on privacy as the deciding factors.

As for what else it offers in terms of software, browsers and social media apps are blocked at the system level, with no toggle to turn the restrictions off. WhatsApp comes preinstalled, and Signal, Telegram, and WeChat are all supported, with iMessage possible through a third-party bridge.

Additionally, the official material points out that over 99% of Android apps are supported. Users can even control a Commodore 64 Ultimate's LEDs from the Callback 8020, as long as both are on the same Wi-Fi network.

The Specs

The polycarbonate-bodied phone is powered by a MediaTek Helio G81 chip with passive cooling, paired with 4GB of RAM and 64GB of storage (expandable via microSD), which should be enough for a phone built around doing less rather than more.

Flip it up, and you will see a 3.25-inch IPS display featuring a 480x640 resolution inside and a 1.77-inch VFD-style screen on the outside. Below the main screen sits a tactile T9 keypad, with dedicated Fn keys flanking the big Commodore key.

Camera duties fall to a 48MP Sony sensor on the back, with autofocus on both the front and rear lenses for video calls. A removable 1550mAh battery keeps things running as you use the device and receive notifications on the Dome-LED system (look at the light bar below the keypad).

For connectivity, you get dual-SIM 4G support with Wi-Fi, Bluetooth, hotspot, and GPS capabilities.

Get Yours

The Callback 8020 is being offered in five colorways: ProtoPET White, SX Silver, BASIC Beige, Starlight Edition, and Founders Edition. Swappable back covers and a protective case are sold separately for anyone who wants to change the look of their device later.

Pricing starts at $499 for ProtoPET White, SX Silver, and BASIC Beige. Starlight Edition runs $549.99, and the Founders Edition tops out at $640. These are discounted prices, and signing up for the waitlist unlocks an extra $50 off that will apply on June 30 when pre-orders open.

Units are set to ship this winter, though Commodore hasn't given a specific date, and the window could easily run into early 2027.

The X11-free Plasma 6.8 is also due around the same time, barring any delays, of course.

But, yeah, that's looking somewhat further into the future. For now, let's focus on the Plasma 6.7 release, which has arrived with those themes as well as a number of upgrades that make the desktop experience more refined than before.

🆕 KDE Plasma 6.7: What's New?

Before we get into the highlights of this release, let's talk about the various usability and quality-of-life upgrades that ship with Plasma 6.7.

If you use Plasma's virtual keyboard, holding down a key now brings up the special characters tied to it instead of you having to dig through a separate symbols screen.

The Discover software center also gets some attention, where the "Install" button has been redone to make it clearer and harder to miss, and app listings carry more useful descriptions on each card.

Similarly, the printing workflow has been improved with a new print queue management tool, the system tray icon for printers now showing the number of print jobs in a queue, and quick connections to shared printers on Windows networks.

Plasma's calendar options grow too, with the Vietnamese lunar calendar joining the other non-Gregorian calendars already on offer.

And if you've already set up custom Global Themes for day and night, you can now flip between light and dark instantly via a toggle inside the "Brightness & Color" quick settings.

Now, for the rest of the changes. 👇

Two Classics Make a Comeback

If you remember, Oxygen and Air both go back to the KDE 4 days, when Oxygen was the default theme starting with KDE 4.0, and Air took over that role once KDE 4.3 arrived.

Ahead of their anniversary, a restoration effort led by community contributors looked to bring them back into proper shape.

We covered that restoration effort in detail back in April, and a good chunk of it has now landed in Plasma 6.7, including reworked panels, a minimized window indicator, new switch designs, and adaptive opacity for both themes.

These now ship as full Global Themes too, with light, dark, and twilight variants. The two wallpapers that shipped with KDE 4 (Air and Horos) are part of the package as well.

Per-Screen Virtual Desktops

Next in line is one of the most sought-after features that has arrived after 21 years of requests. Plasma has had virtual desktops for ages, but they were always tied globally across every monitor you had connected.

That changes now. You can finally set up separate virtual desktops for each screen, so your laptop display and your external monitor no longer have to share the same set. It might sound like a small change, but anyone running a multi-monitor setup knows how essential this is.

Apart from that, switching between virtual desktops got faster too; now you can pull up the Overview screen with Super+W and with a simple scroll or a tap of Page Up / Page Down move between desktops.

Suggested Read 📖: This New Project Gives You Plasma With X11

Arrival of Union

Plasma's theming has been a fragmented affair behind the scenes, with different toolkits needing different styling approaches.

With this release, a new theming system, Union, is being introduced that wants to assimilate all of that into one CSS-based system. So Plasma, QtQuick software, and QtWidgets software can pull their looks from the same set of style files instead of three separate ones.

In its current state, it is disabled by default and only touches the QtQuick side of the stack, arriving here as a tech preview rather than a finished feature.

📥 Get KDE Plasma 6.7?

Users of Plasma on rolling release distros like Arch Linux or EndeavourOS will be getting this the earliest. If you can't wait or are on a non-Arch distro, then you can build from source.

On the other hand, if you just want to see how this release performs before committing to it on your main setup, then you could always go for the User Edition of KDE Neon.

💬 Have you been on KDE Plasma for a long time? How has it been for you?

Meta's partnerships with Ray-Ban and Oakley have put AI-powered glasses on faces across global markets, pitching voice-activated AI assistants, integrated cameras, and phone notifications as the selling points.

The privacy record of those products, however, is extremely disturbing. Meta's AI features push footage from the glasses to their servers for processing, and an investigation earlier this year confirmed that human contractors had reviewed people's most intimate moments.

Then there's the more recent fiasco, where Meta was caught sneaking face recognition code for its smart glasses onto millions of phones. This quietly laid the groundwork for a system that could match any face the glasses saw against stored biometric signatures.

All of that doesn't instill much confidence, but these devices can be useful if the company behind them actually cares about its users rather than harvesting their soul… err, data.

There's a new one being launched by a San Francisco-based startup that has some impressive specs, is powered by Linux, and isn't looking to sell user data.

Raven Prism: Is This For You?

Founded by Thomas Suarez, Raven Resonance is a wearable computing startup with a diverse team of engineers who have experience building wearables, spatial computing, and other electronic gadgets.

The Raven Prism is what they call the world's first ambient computer rather than a smart glass. I know, I implied that this was a smart glass at the start, because to me it looks like one.

It is a standalone Linux computer that can be your everyday prescription (−4.5 to +4.5 diopters) or non-prescription eyewear that does not depend upon a smartphone to function.

The ambient computing concept, as the company describes it, is technology that is present when you need it and stays out of the way when you don't.

In this implementation, a full-color display on the right lens puts information in the wearer's field of view without cutting them off from the world around them. Eye control is the primary input, supplemented by voice and wireless HID peripherals.

Some use cases the company points to include hands-free coding agents, reading board schematics mid-build, following a recipe in the kitchen, and keeping sheet music in view while playing an instrument.

Powering it is RavenOS, the company's own Linux-based OS built around gaze-first, hands-free interaction. So yeah, it does not run Android or AOSP, and Raven is already building apps with future spatial environments in mind.

The device supports SSH out of the box, can be rooted, and system images are planned for release soon. Moreover, as a native ARM64 Linux platform, it can run anything built for that environment, including Unity, web apps, local AI models, and agents.

At launch, the Raven Prism is set to ship with more than 25 apps, and if you want to build for it, the SDK is live on GitHub, with a development kit also in the works.

The Hardware Bits

The Raven Resonance team is being tight-lipped about the full specifications of the device but have shared some basic information that gives us an idea of what will be offered.

Under the hood is a quad-core 64-bit ARM processor running at roughly 1 GHz, with the device available in 2 GB and 4 GB RAM configurations. It weighs under 70 grams, with the weight distribution tailored for all-day wear.

The display is a full-color LCoS waveguide positioned on the right eye with a 30-degree diagonal field of view. Raven describes the viewing experience as comparable to a 16-inch laptop at arm's length.

There's also a camera on the left, multiple microphones, and Raven Wings (shown above) as the hot-swappable modular batteries that keep the Prism running throughout the day, with these doubling up as an expansion platform.

The Privacy-Focused Bits

Before you get worried, Raven Prism will ship with a physical cover for the camera that you remove when you want to use it and put back when you don't. There's also "Beakon" lights that illuminate when the camera is active, making it visible to both the wearer and anyone nearby.

Similarly, eye tracking uses a combination of in-house models and technology from Pupil Labs, but all processing happens on the device.

This way, no user data leaves the device without explicit consent from the wearer, and Prism itself doesn't collect any telemetry by default, with an opt-in path for people who want to contribute anonymized data.

Want One?

The Raven Resonance team has shared a tentative base price of $1,499. Full pricing and availability details will be confirmed at launch, and the device won't require a wallet-draining subscription to function.

The device is designed and built at the company's California facility and assembled in the United States, with them being fully committed to the right to repair.

If you can't wait to check it out, there's currently a public preview happening at Augmented World Expo 2026 from June 16 to 18, at Booth 1028 in Long Beach, California.

The commercial launch is planned for later in 2026, and their Discord server is where the team will be sharing access details and launch news.

The AUR is where Arch users look in for software that has not made it into the official repositories yet. It is community-run and unsupported, meaning packages are user-submitted with no safety guarantee from the Arch team.

Over 1,500 packages were hit in the first wave alone, and two more waves followed shortly after developers thought they had it cleaned up.

What happened?

On June 11, Arch developer Jonathan Grotelüschen opened a dedicated thread on aur-general asking the community to report compromised packages. A formal news post from Campbell Jones followed the next day, acknowledging "a high volume of malicious package adoptions and updates" in the AUR.

Community member a821 traced the initial packages to a malicious npm package called js-digest, which was embedded in post-install scripts. Shortly after, koraynilay ran a broader search against GitHub's AUR mirror using js-digest as the marker and found around 850+ packages that were affected, noting the count was already dropping as devs removed them.

By the end of the day, Jonathan posted that they had deleted all known malicious commits, linking to a document that listed over 1,500 packages.

That was not the end of it. On June 13, a821 flagged a new batch using a different technique. This time, the word "bun" was split across string literals as 'b''u''n' to slip past detection.

Around 50 packages were caught in this wave, spanning browser packages, a cluster of nodejs-* entries, plasma6-applets-fancytasks, a NeoVim plugin, and LibreWolf extensions.

A day later, Nicolas Boichat spotted another batch, this one more heavily obfuscated. He caught it using a locally-run Gemma E2B model, with htbrowser-bin among the packages he flagged.

What can you do?

Fast-forward to now, Leonidas Spyropoulos of the Arch Linux team announced on June 15 that new AUR account registrations had been disabled as they are busy cleaning up the AUR.

Another thing to keep in mind is that the core Arch Linux repositories remain unaffected, with the malicious commits limited to the AUR.

If you suspect malicious packages might've made it onto your system or you just want to be cautious, then the Arch team suggests reviewing every PKGBUILD and install script change before updating, particularly right now.

And if anything suspicious does show up, they encourage users to flag it via the aur-general mailing list by replying to the AUR REPORT THREAD (also linked earlier).

In its recent updates, CachyOS has changed the default package management system to the Shelly from Octopi, so obviously, I was bound to check it out.

What does Shelly offer?

To start with, Shelly is a one stop solution to manage packages not only from CachyOS's own repositories, but also AUR, AppImage and Flathub, all at the same place. It also provides quite a nifty clean look that just makes sense, both of which give it a clear edge over Octopi already, which can manage the default repositories and AUR only, and looks a little dated.

Interface

The home page shows recent activity, a package dashboard which displays the number of packages installed through AUR and Flatpak, and the absolute total number of packages on the system. It also shows the percentage of packages which are totally updated, with the available updates on the right side.

There's a search bar on top which will search through the distribution's repositories, AUR and Flathub all at the same time. If a package is available from multiple sources, Shelly lists them in order of preference, first the distribution's repositories, then AUR and finally Flathub.

All the different possible sources are tabbed on the left of the window, which means you can manage the packages from all different sources separately and seamlessly.

Settings

The settings keep things to a minimal. There are toggle switches for AUR, Flatpak and AppImage management, as well as for the tray icon. These settings are confirmed on the first start of the application.

You can move around the left menu to the top, again with a toggle switch. In the advanced settings, you can enable the "No Confirm" button to slide through the confirmation for the installation, uninstallation or updating of any package. You can also limit the number of parallel downloads, with the default being 10. There's an interesting option called "Purify Packages" which gets rid of any corrupt packages on the system.

How well does it work?

In most aspects, Shelly works really well. Package management from the distribution's repositories, AUR and Flathub are virtually error-free. Search works really, and so does the installation and uninstallation.

AppImage is a little patchy, though. I tried to install balenaEtcher's AppImage and Raspberry Pi's Imager, the former was not installed and embedded into the system menu, but the latter was.

How does it compare to Pamac and Octopi?

With the first look itself, the interface, Shelly looks like it is several steps ahead from both Pamac and Octopi. It looks like it belongs on a modern system, is sleek and intuitively accessible unlike the other two.

As for the functionality, Pamac and Octopi work reliably well at what they do. Shelly works fairly well, too, while providing more options at the same time, with some aspects being a little troubling, perhaps.

Final Thoughts

The change to Shelly as the default package manager is very promising, it seems to suit CachyOS much better than Octopi in my opinion. It offers a lot of new, interesting features, and delivers on them fairly well. Let us know what you think about this change in the comments. Cheers!

A project like Flipper One, which is intended to be a device that features the full mainline Linux kernel in a small package with a full range of connectivity, not to be used as a full-fledged computer (not all the time, at least) but rather a cyberdeck that can be used for development, experimentation and last but not the least, pentesting, is such a dream come true.

With its radical philosophy of complete openness, both in terms of hardware and software, and the ability to do whatever is possible with the hardware on board, it is a project that would have sent my 14 year-old self into a hyperventilating fit. So what exactly can it do? And how do you fit into the picture? That's exactly what we will tell you today.

Flipper One at a glance

Flipper One hasn't been released yet, but there are some ambitious features that have been planned for it. While Flipper Zero was more of an offline access tool, with emphasis on NFC, RFID infrared, UART and so on, Flipper One is intended to be a network connected Linux system. So obviously, we start with:

Connectivity

Flipper One self proclaims as a "Swiss Army knife for IP networks across all OSI layers", which include:

• 5G modem
• Wi-Fi 6E
• Two Gigabit Ethernet ports
• Upto 5 Gbps wired connectivity over USB-C Ethernet

All this results in Flipper One being usable as anything from a multi-hotspot bridge, an inline Ethernet sniffer, a VPN gateway, or a USB Wi-Fi/Ethernet adapter for another device.

Hardware

The hardware is a particularly interesting aspect of Flipper One, as it is has a completely custom, unique build. We will describe the technical aspects later, focusing first on the build of the device. It has a small monochrome 256x144px display, designed to show all necessary information from the custom software onboard, a touchpad, a 5-button D-pad, a back button, an app-switching button, and 5 buttons used for further navigation to power, edit, run or escape programs, and to view other options. Oh, there's a push-to-talk button as well for a pre-installed offline AI assistant. Fancy, eh?

As for the ports, it has the following:

• Two USB-C, one multipurpose, one only for power
• USB-A
• HDMI
• Two Ethernet
• 3.5mm audio jack
• MicroSD card slot
• Nano SIM card slot
• M.2 expansion module

Now finally onto the hardware on board:

• A main Rockchip RK3576 chip
• A secondary low-powered Raspberry Pi RP2350B MCU
• 8 GB RAM
• 64 GB internal storage
• 7000 mAh battery (tentatively)

As an ARM based device, the processing is comparable to the power offered by a Raspberry Pi 5, handling basic operations rather well.

Software

Here's where things get really interesting. The Flipper team intends Flipper One to be able to support the mainline Linux kernel, and has gone to the massive undertaking of having absolutely no proprietary binary blobs in any of their software. This includes the operating systems as well as the firmware. They're building FlipperOS, a layer on top of Debian, which you can do anything to.

There's also FlipperCTL, which has been created as a response to full-fledged Linux operating systems being awkward and uncomfortable on small screens. It is, therefore, a UI designed for a screen as small as that, controlled by a D-pad and a few buttons. The idea then, is to wrap utilities like ping, nmap and traceroute into this FlipperCTL interface.

Abilities

Apart from the use cases already mentioned, like as a pentesting tool or a networking agent, it can also be used as a survival desktop or a thin client, using the USB-C port to connect to a monitor. The exact details of the OS haven't been decided yet, but something slick like KDE Plasma with something resourceful like Kali Linux to suit all pentesting needs is the way Flipper is planning to go. It is also being planned as a hacker's TV media box, to be used as a media platform using Kodi or something similar. This would turn any HDMI input taking monitor into your personal media box, a luxury that is quite underrated in situations like a strange hotel room.

Not to forget, the presence of both a CPU and an MCU is by design, as the intention is to have the device functioning at low power, with the LCD and buttons, even without the main CPU running. Even when Linux is off, the device can run simple programs off of the MCU.

So what can you do?

But where do you come in? Well, the entire device is still under development and needs contributions from anyone who can provide it to be completed. Flipper has made a Developer Portal for Flipper One, where the entire development process is to be made open. That means half-baked task tracking, documentation, internal discussions, debates and everything.

You don't need to be a software developer, strictly, you could be a designer, just work on documentation, 3D models, so on and so forth. So, what all can you contribute to?

• Hardware: PCBs, antennae, chips, processors, connectors and everything in between (literally).
• Mechanics: Designing, enclosure, plastic/metal parts, mounting parts and so on.
• Linux: Firmware for the RP2350 microcontroller, relating to practically every component that the software will interact with.
• Interface: UI/UX design, visuals and graphics.
• Docs: Documentation, wikis, guides, progress made on the portal itself.
• Testing: This one you can find out for yourself.

Conclusion

Flipper's team has taken up a humongous task, trying to make this entire project totally open, the hardware design plans, the software blobs barring no small proprietary bits, and has shown courage admitting the need for help finishing the project. The Developer Portal is a great approach, inviting all the people from across the globe to contribute in any way that they possibly can. And with a beautiful passion project such as this? I'm expecting they absolutely will want to. I urge the readers to do that as well, if you have some skill and time to contribute.

This kind of project instills hope in user-level innovation after long bouts of polished, corporate products and we're all here for it. Let us know what you think of the device in the comments. Cheers!

One such case is of a group of developers who took the code that KDE itself is walking away from and started building an X11-first desktop around it. That project is SonicDE.

Their goal is to maintain and actively develop the parts of KDE Plasma's X11 stack that are being left behind, while cutting out Wayland dependencies and pushing X11 support forward rather than just holding the line.

The work can be traced back to a KWin/X11 patchset called kwin-x11-improved, which was later merged with the full KWin/X11 source by Joseph Crowell in September 2025 under the name "KDE-Lite," and rebranded as SonicDE by December.

SonicDE: X11 Plasma Restored

It is a collection of KDE Plasma and KDE Frameworks component forks, each rebuilt with X11 as the focus. The project now spans 40 repositories on GitHub, with the team working through the KDE stack and stripping out what's not needed.

The most prominent of those is sonic-win, a fork of KWin/X11 that handles window management and compositing. It's the most active repository in the project and the one where most of the foundational work is happening.

Alongside it are sonic-workspace, derived from plasma-workspace, and sonic-desktop-interface, forked from plasma-desktop. The former provides the core environment components, while the latter handles the desktop shell. Together with sonic-win, these three form the backbone of what SonicDE actually is as a desktop.

The project covers a lot of ground beyond the core trio of components.

For networking, sonic-network-manager is there; sonic-audio-applet-pulse covers PulseAudio volume management; sonic-screenlocker takes care of screen locking; sonic-screen manages display configuration; and login sessions are handled by sonic-login-manager.

SonicDE also ships a Silver theme, forked from the Klassy theming utility for Plasma, alongside a matching silver-sddm login screen. Together, they give the desktop a consistent look rather than just resembling a stripped-down Plasma install.

What users actually get is an X11 desktop that behaves the way longtime KDE users expect, while still inheriting improvements from the upstream Plasma components it forks from.

And since SonicDE is being built to be init system agnostic from the start, it isn't locked to systemd. BSD support is one of the stated goals too, so the project is thinking well beyond Linux users.

Availability of this?

It is already packaged for Arch Linux-based distributions, with additional builds available for Debian, Devuan, Artix Linux, and Vendefoul Wolf. The official website has the links for the packages for those distros.

Also good to know is that the developers are already packaging SonicDE for Gentoo, NixOS, OpenMandriva, and FreeBSD, so keep an eye out on their socials and GitHub page for updates.

Adam had been combing through Nathan's Bugzilla history and found what he described as the work of "some kind of agentic AI system," operating unsupervised across both Fedora's bug tracker and several upstream projects.

Soon after, Nathan replied, saying his credentials had been compromised and that he had nothing to do with any of it.

Skynet, is that you?

The agent had been mass-reassigning Bugzilla reports to Nathan's account, despite him not being the maintainer for any of the affected packages. In Fedora's Bugzilla instance, the assignee is supposed to be whoever can actually resolve the bug downstream, typically the package maintainer.

It had also been prematurely closing bugs, where the correct protocol was to mark a bug as POST when a fix was proposed upstream but wasn't pushed downstream. The agent was just closing them outright after submitting or merging an upstream patch.

Then there were the NOTABUG closures. The agent had been shutting bugs in components it had no ownership over, with comments Adam identified as clearly LLM-generated. Some of those comments just restated what the original reporter had already written. Others sounded plausible but were wrong.

The fourth problem was the most serious. The agent submitted an incorrect fix to the Anaconda installer project, and when a maintainer pushed back, it kept firing back LLM-generated responses until the maintainer gave in and merged it.

The Anaconda team reverted the PR, but two related pull requests had already shipped in Anaconda 45.5.

A supply chain problem?

This is not a particularly sophisticated attack.

A contributor account gets compromised, an AI agent runs through it, and bad code ends up in a release before anyone notices. The damage in this case was caught and cleaned up, but the scenario itself is not hard to replicate.

Fedora approved a policy on AI-assisted contributions last year, placing full accountability on the human contributor and requiring transparency when AI tools are involved. Submitting unreviewed, low-quality machine-generated content is explicitly called out as unacceptable.

What played out here was the policy's failure conditions, except it was routed through a stolen account rather than a contributor acting in bad faith, so the policy had no way to apply.

Open source software sits underneath nearly all modern enterprise infrastructure, which is what makes the supply chain angle worth taking very seriously.

IBM and Red Hat announced Project Lightwell in late May as a $5 billion effort to secure open source supply chains using AI tooling and a team of over 20,000 engineers. It targets vulnerability remediation across upstream and enterprise environments, from language ecosystems to AI frameworks.

However, it does not address the specific problem of agentic AI operating through hijacked contributor accounts, but it reflects where the industry is moving towards as AI keeps accelerating both the discovery and exploitation of vulnerabilities.

Fedora's 2FA problem isn't going away

The incident kicked off a debate on the devel list that has apparently been sitting unresolved since the XZ backdoor in 2024.

Daniel Berrangé, a Red Hat engineer and long-time Fedora contributor, pointed out that mandatory 2FA had come up after that incident; the only outcome was a soft recommendation that provenpackagers should have it enabled, and nothing has moved since.

Fabio Valentini raised a separate issue saying that a lot of this activity happened on Bugzilla, which uses its own account system and may not support 2FA at all. Daniel acknowledged that but said it was not a reason to avoid mandating it for the Fedora Accounts (FAS), and noted Bugzilla may become less relevant if Fedora eventually moves to the issue tracker on Fedora Forge.

Michael Catanzaro, a GNOME developer, said he uses 2FA everywhere except Fedora, even though his Fedora account is among his most sensitive. The sticking point in his case is that Kerberos ticket renewal isn't working properly with 2FA in GNOME Online Accounts.

In the end, seeing that a compromised account got bad code into their repos, the Fedora folks ought to step up their efforts when it comes to mandating 2FA for contributors whose work affects many users.

So naturally, someone went ahead and built a brand new X11 server from scratch. Developer Jos Dehaes recently went public with yserver, a new MIT-licensed X11 display server written entirely in Rust.

Now, this will either impress you or make you shout "Clanker!" but this project was built with significant help from Claude Code, Anthropic's AI coding agent. The repo has both a CLAUDE.md and an AGENTS.md file in plain sight, making this a proper vibe-coded project.

What is it?

Well, yserver isn't aiming to clone X.Org, rather it is meant to be a practical X11 server for modern Linux that focuses on what real desktop environments and applications actually need today.

Everything that has accumulated over decades and serves no purpose in today's computing environment has been dropped. That includes the DDX driver ABI, multiple X11 screen support, non-TrueColor legacy visuals, indirect GLX, and endian-swapped clients.

Under the hood, yserver drives hardware directly through DRM/KMS and Vulkan, skipping the usual middleware layers that sit between the display server and the GPU. This means a more direct path to the hardware with fewer moving parts sitting in the middle.

According to the project's documentation, yserver uses libseat for seat management, which ensures it can run without root and the core is deliberately single-threaded, resulting in predictable protocol behavior.

What can it do?

Currently, yserver can already boot into MATE, Xfce, and Cinnamon sessions, and it has also been tested with window managers like FVWM3, e16, and Window Maker. FreeBSD support is on the roadmap, but work on it has not started yet.

Hardware coverage is wider than you might expect. In testing, Jos has covered AMD Ryzen and Radeon setups, Intel Kaby Lake iGPU, NVIDIA with the proprietary driver, Snapdragon X1, and Apple M1 and M2 on Asahi Linux.

These were all tested on MATE, Xfce, and Cinnamon configurations, btw.

The obvious question

Major players in the Linux space like Ubuntu dropped the X11 session in 25.10, Fedora has done away with X11 on its flagship Workstation desktop edition, and KDE has already announced Plasma 6.8 will drop X11 support entirely.

So who is yserver for, exactly? Well, there is still a distinct group of users stuck on X11, whether because of legacy desktop environments, specific hardware setups, or workflows that just have not made the jump yet.

And the project itself is very early. There is one primary contributor, and the security model is incomplete, with the design documentation clearly stating that clients can currently read other clients' windows and global input.

Heck, even the name is a placeholder. 😅

So, yserver won't be replacing Wayland or X11 on your computer anytime soon, but it is a nice project to know about, and it also shows us how prevalent vibe coding has become, whether you like it or not.

Via: Phoronix