With the transition from X11 to Wayland in full swing, from popular distributions removing X11 sessions altogether and the two major desktop environments planning for the removal of X11 support as well, there’s a ton of questions people are dealing with. Both the KDE and GNOME project published detailed blog posts about the matter.

First, KDE’s Nathan Graham makes it very clear that KDE Plasma’s X11 sessions continues to be maintained. This means KDE Plasma will continue to work on X11, major bugs in the session (e.g. can’t log in) will be fixed, and really bad regressions in the session may eventually be fixed. That being said, minor bugs will probably not be fixed unless someone pays for it, and new features in the X11 session will not happen at all, unless someone pays for it.

KDE currently has no time frame for when X11 support will be dropped from KDE Plasma, and Graham doesn’t expect it to happen within the next two years. The KDE project maintains a list of known significant issues with KDE Plasma on Wayland, and KDE plans on addressing everything on that list before removing X11 support. Graham notes that in the end, dropping X11 support from KDE Plasma is mostly up to distributions, as it wouldn’t make any sense to drop it if distributions aren’t on board. At the moment, about 70-80% of KDE Plasma users are using Wayland, he notes.

On the GNOME side of things, Jordan Petridis also detailed GNOME’s position on Wayland and X11. GNOME will be disabling the X11 session in GNOME 49, with a full removal of the X11 code in GNOME 50. This won’t break any X11 applications (on either GNOME or KDE), since even if they don’t have a Wayland backend, they’ll run just fine using XWayland, which is an X server running on top of Wayland. XWayland isn’t going anywhere any time soon.

According to Petridis, the Wayland session is as functional as the X11 session, and “in plenty of cases a lot more capable and efficient”. He further adds that “there’s some niche workflows that are only possible on X11, but there isn’t any functionality regression”. Basically, if you’re using your spacebar as a heater, you might run into problems.

As for accessibility, Wayland is actually doing pretty great.

There has been a lot of concerned trolling and misinformation specifically around this topic sadly from people that don’t care about it and have been abusing the discourse as a straw man argument. Drowning all the people that rely on it and need to be heard. Thankfully Aaron of fireborn fame wrote recently a blogpost talking about all this in detail and clearing up misconceptions.

↫ Jordan Petridis

Finally, Petridis summarises why the Linux desktop world is moving to Wayland:

No, the Xorg Server is still very much maintained, however its development is halted. It still receives occasional bugfixes and there are timely security releases when needed.

The common sentiment, shared among Xorg, Graphics, Kernel, Platform and Application developers is that any future development is a dead-end and shortcomings can’t be addressed without breaking X11. That’s why the majority of Xorg developers moved on to make a new, separate, thing: Wayland.

↫ Jordan Petridis

This pill is so hard to swallow for some people that they go full bananas and start seeing red hats and Illuminati symbols everywhere, losing their minds and spiraling deep into ludicrous conspiracy theories. The truth of the matter is, however, blatantly banal: the people developing X.org realised long ago that meaningfully improving it would irrevocably break it, and as such they developed something new so they wouldn’t have to break X11. That’s it.

X.org will continue to exist and live on in its maintained state, and desktops relying on it will continue to function. If you want to keep using GNOME and KDE, though, you’ll have to drop X11, because the kinds of features and improvements these desktops want to deliver are not possible without breaking X11. Would you want an X11 that’s broken for everyone, or an X11 that keeps working as-is, while those that want to move on do so somewhere else?

Asterinas is a new Linux-ABI-compatible kernel project written in Rust, based on what the authors call a “framekernel architecture”. The project overlaps somewhat with the goals of the Rust for Linux project, but approaches the problem space from a different direction by trying to get the best from both monolithic and microkernel designs.

↫ Ronja Koistinen at LWN.net

Ronja Koistinen has done an outstanding job diving into this new operating system kernel and approach to kernel architecture, including its intended focus and goals. Head on over to the source and read it over there.

This is it, the one that adds systemd to postmarketOS! We have talked about the decision at length on this blog, make sure to read the initial announcement if this is the first time you are hearing about this.

↫ postmarketOS v25.06 release announcement

While adding systemd to postmarketOS is certainly the tentpole feature of this release, it also updates the various user interfaces – GNOME’s and KDE’s mobile shells and applications – and moves to Alpine Linux 3.22 as its base. The mobile user interfaces for both Firefox and Thunderbird have been updated as well, there’s a ton of improvements and additions for individual devices, and a lot more.

PostmarketOS, in case you are unaware, is a Linux distribution optimised for smartphones, focused on running mobile shells and applications. It’s not ready for prime-time quite yet, and device support will probably be the biggest hurdle for anyone wanting to try it out.

Over the past few months, YouTube has been trying another round of anti-adblock measures. Currently the anti-adblock stuff is being A/B tested, and one of my accounts is in the experimental group. I wrote a filter that partially avoids one of the anti-adblock measures, fake buffering, on uBlock Origin (and Brave browser, since it uses the same filter rules). (It’s already in the default filter lists, you don’t need to manually add the filter.)

One thing that people have ran into is “fake buffering”, where videos will take a while to load due to a lot of buffering, but only at the very start of the video (there’s no mid-video fake buffering). As I’ll explain, the fake buffering is 80% of the length of the ads you would’ve seen, so even with fake buffering you’re still saving time using an adblocker.

↫ iter.ca

The battle between YouTube on one side, and users wanting a non-shitty experience without paying for YouTube Premium on the other, is unlikely to end any time soon. Your computer, your rules, so I’m on the side of the people wanting to block ads on YouTube – the same applies to OSNews if you don’t want to pay for our ad-free version – but I’m still intrigued to find out just how far Google is willing to go.

I sometimes see YouTube with ads at other people’s homes. It’s a nightmare.

The lone volunteer maintainer of libxml2, one of the open source ecosystem’s most widely used XML parsing libraries, has announced a policy shift that drops support for embargoed security vulnerability reports. This change highlights growing frustration among unpaid maintainers bearing the brunt of big tech’s security demands without compensation or support.

[…]

Wellnhofer’s blunt assessment is that coordinated disclosure mostly benefits large tech companies while leaving maintainers doing unpaid work. He criticized the OpenSSF and Linux Foundation membership costs as a financial barrier to single person maintainers gaining additional support.

↫ Sarah Gooding

The problem is that, according to Wellnhofer, libxml2 was never supposed to be widely used, but now every major technology company with billions in quarterly revenue are basically expecting an unpaid maintainer to fix the security issues – many of which questionable – they throw his way.

The point is that libxml2 never had the quality to be used in mainstream browsers or operating systems to begin with. It all started when Apple made libxml2 a core component of all their OSes. Then Google followed suit and now even Microsoft is using libxml2 in their OS outside of Edge. This should have never happened. Originally it was kind of a growth hack, but now these companies make billions of profits and refuse to pay back their technical debt, either by switching to better solutions, developing their own or by trying to improve libxml2.

The behavior of these companies is irresponsible. Even if they claim otherwise, they don’t care about the security and privacy of their users. They only try to fix symptoms.

↫ Nick Wellnhofer

It’s wild that a library never intended to be widely used in any critical infrastructure is now used all over the place, even though it just does not have the level of quality and security needed to perform such a role. These are the words of Wellnhofer himself – an addition to the project’s readme now makes this point very clear, and I absolutely love the wording:

This is open-source software written by hobbyists, maintained by a single
volunteer, badly tested, written in a memory-unsafe language and full of
security bugs. It is foolish to use this software to process untrusted data.
As such, we treat security issues like any other bug. Each security report
we receive will be made public immediately and won’t be prioritized.

↫ libxml2’s readme

If you want libxml2 to fulfill a role it was never intended to fulfill, make it happen. With contributions. With money. Don’t just throw a whole slew of security demands a sole maintainer’s way and hope he will do the work for you.

rou2exOS is a 64-bit DOS-like operating system (OS). The system is mainly written in Rust, but some portion of x86 assembly is used as well (inline + freestanding code for the stage2 kernel loading).

↫ Blog post about rou2exOS at blog.vxn.dev

It can do basic VGA operations, comes with a very barebones networking stack, realtime clock support, a FAT12 driver, and a few more tidbits. It’s a rewrite of the previous iteration of the hobby operating system.

With the possibility that Google is going to make some big changes to the open source status of Android, the importance of smartphones that don’t run either iOS or (some form of) Android is definitely increasing. Linux on smartphones is not as complete as iOS or Android, and I personally think one of the primary reasons for that is a lack of easy access to devices that don’t require manual installation or other forms of hackery, only to then end up with a partially supported device because the device in question was never originally designed to run regular Linux.

A few companies are trying to change this, developing Linux-first smartphones instead. One of the newcomers here is Liberux, a Spanish company who just unveiled the crowdfunding campaign for their Liberux Nexx, a Debian-powered smartphone with excellent specifications and some unique additions you won’t find on any other smartphone. It’s powered by an octa-core Rockchip RK3588S (four Cortex-A76 cores and four Cortex-A55 cores up to 2.4 GHz), 32 GB LPDDR4x RAM, tons of expendable storage, and a 6.34″ 2400×1080 OLED display.

At the top of the device sit something you won’t find on many other smartphones: dedicated hardware switches to physically cut power to the modem, Wi-Fi/Bluetooth chip, and the microhone/camera array. When all three switches are disabled, a number of other features, like GPS and sensors, are also turned off. On top of all this, various internal components are designed to be replaceable and possibly even upgradeable, with manufacturing of the device taking place in Europe – which probably refers to assembly, but still. The device is supposed to become open source, too.

It will run Debian 13 with a customised version of the mobile GNOME Shell using a standard Linux kernel. Android applications will also be supported using Waydroid, which you’ll most likely have to rely on for things like banking and other application categories exclusive to iOS and Android. Liberux promises that any development done on both the Linux distribution and other related applications will be done openly, which is something we can hold them to quite easily.

I’m always weary of crowdfunding campaigns, and all the usual caveats, warnings, and concerns still apply here. I’m highlighting this campaign because I feel like many of the kinds of people who read OSNews are longing for a modern, capable smartphone that runs not iOS or Android, but proper Linux, even if Linux on smartphones isn’t quite there yet to go toe-to-toe with the two duopolists. For more information on the device and the people involved, be sure to read LINMOB.net’s excellent interview with Liberux.

Liberux has told me they want to send over a review device once development has reached a point where that’s possible. So, assuming the crowdfunding campaign is successful, you can look forward to a review of the Liberux Nexx on OSNews somewhere between now and mid-2026.

Kian Bradley was downloading something using BitTorrent, and noticed that quite a few trackers were dead.

Most of the trackers were totally dead. Either the hosts were down or the domains weren’t being used.

That got me thinking. What if I picked up one of these dead domains? How many clients would try to connect?

Kian Bradley

It turns out the answer is a lot.

A new version of Plasma is here, and it feels even more like /home, as it becomes smoother, friendlier and more helpful.

Plasma 6.4 improves on nearly every front, with progress being made in accessibility, color rendering, tablet support, window management, and more.

↫ KDE Plasma 6.4 release announcement

KDE Plasma 6.4 comes with a big improvement in window and virtual desktop management, allowing you to create entirely custom tiled configurations per virtual desktop. Accessibility was another focus of this release, as we talked about a few weeks ago, bringing number pad mouse pointer navigation, improved desktop zoom, screen readers improvements, better contrast i the dark theme, tons of little legibility improvements across the desktop environment and its applications, and more.

Furthermore, there’s now finally a dedicated page in Settings for animations, so you no longer have to dig your way through the oddly placed and obtuse Desktop Effects page. Notifications have been improved as well, with new additions like a speed graph in file transfer notifications or Plasma notifying you when you’re trying to use a muted microphone input. KRunner can now visualise colours when searching for a hex code, Spectacle has received some love, various widgets have been touched up, and much more.

There’s a brand new HDR wizard, support for Extended Dynamic Range, and the addition of the P010 video color format. System Monitor will now show usage information for Intel and AMD GPUs, and Info Center will show raw sensor data from the sensors in your device. There’s a ton more, as this is a fairly major release.

You can download and compile KDE Plasma 6.4 now, or just wait a few days until it lands in your distribution’s repository.

I hate how these months keep going down like vodka-martinis on an Italian beach, but at least we get another progress report for Haiku every time. Aside from the usual small changes and bug fixes, the most important of which is probably allowing the EXT4 driver to read and write again, there’s this little paragraph at the end which definitely stands out.

This month was a bit lighter than usual, it seems most of the developers (myself included) were busy with other things… However, HaikuPorts remained quite active: most months, at this point, there are more commits to HaikuPorts than Haiku, and sometimes by a significant margin, too (for May, it was 52 in Haiku vs. 258 in HaikuPorts!). I think overall this is a sign of Haiku’s growing maturity: the system seems stable enough that the porters can do their work without uncovering too many bugs in Haiku that interrupt or halt their progress.

↫ Haiku activity report for May

I definitely hope that this positive read is correct, as it would be a shame for the project to run into declining activity and contributions just as it seems to be serving as a solid base for quite a wide variety of applications. I’ve definitely been seeing more and more people giving Haiku a try lately and coming away impressed, but of course, that’s just anecdotal and I have no idea if that means Haiku has reached a certain point of maturity.

One thing that definitely does indicate Haiku is a lot more stable and generally usable than most people think is the massive amount solid ports the platform can handle, from Firefox to LibreOffice, and everything in between. I think a lot of people would be surprised by just how far they can get with their day-to-day computing needs with Haiku, assuming their hardware can boot Haiku and is properly supported, of course.

My opinion on Haiku has not changed, but I’m a random idiot you shouldn’t be listening to. The cold and harsh truth is that old people like me who want their BeOS boomerware but in 2025, are a small minority who are impossible to please. The Haiku team’s focus on getting modern software ported to Haiku, instead or trying to convince people to code brand new native Haiku applications, is objectively the correct choice to ensure the viability of the platform going forward.

If Haiku wishes to fully outgrow its hobby status, looking towards the future is a far better approach than clinging to the past, and unsurprisingly, Haiku’s developers are more than smart enough to realise that.

A new image loading machinery, called glycin, has been in the works for a while. It is already used by GNOME’s default Image Viewer (Loupe), as well as by a bunch of other apps. Glycin provides many security benefits over existing solutions due to the use of the Rust programming language and sandboxing. Distributions will now be able to use the security benefits and broader format support of glycin for other GNOME apps, thumbnailers, and GNOME Shell, whithout changing any existing software. This is made possible by a new option for GNOME’s legacy image-loading library, GdkPixbuf, to use glycin internally.

↫ Sophie Herold

Clearly, this is an improvement over the previous image loading library, but there’s a bit of a catch that is in line with GNOME’s increased reliance on systemd features: glycin only works on Linux due to its sandbox mechanisms and how it communicates with its loaders. However, there’s no need to fret this time, and that’s why I’m posting this item – you just know this tiny little tidbit will find their way into internet discussion forums and social media as another example of GNOME not caring about non-Linux users.

While some of the sandboxing and communication features in glycin can be made to work on the BSDs and perhaps macOS, it won’t be perfect. As such, great care has been taken to ensure non-Linux platforms can continue to use GdkPixbuf just fine, since support for other platforms is part of the goals of this change before traditional loaders are removed.

As a general solution for other platforms, I am planning a mechanism to compile the loaders into the library. This will not provide sandboxing and format extendability without recompilation. But since most loaders are written in Rust, this is still a huge step-up security wise. Contributions for support on other platforms are welcome. For GdkPixbuf users, this will not pose an immediate issue since traditional gdk-pixbuf loaders are not going away until all platforms it supported, are supported by glycin.

↫ Sophie Herold

There are a few other issues, as any change like this tends to cause, like the list of supported images formats. Glycin supports AVIF, BMP, DDS, Farbfeld, QOI, GIF, HEIC, ICO, JPEG, JPEG XL, OpenEXR, PNG, PNM, SVG, TGA, TIFF, and WEBP out of the box, but some of the subformats within each of these might potentially not work entirely correctly due to incorrect implementations by, say, camera manufacturers. A special case here is the TIFF format, which apparently still has a number of issues and might end up relying on a fallback.

Glycin brings a ton of benefits, such as improved colour support for things like HDR and wider colour gamut displays, better metadata support, basic image editing functions out of the box, increased performance, as well as the benefits inherent in using a memory-safe language like Rust.

Recently, a Reddit user discovered a rare RCA Spectra 70/35 computer control panel from 1966 in their family’s old collapsed garage, posting photos of the pre-moon landing mainframe component to the “retrobattlestations” subreddit that celebrates vintage computers. After cleaning the panel and fixing most keyswitches, the original poster noted that actually running it would require “1,500lbs of mainframe”—the rest of the computer system that’s missing.

↫ Benj Edwards at Ars Technica

Apparently, no photos of this panel existed online, and it may be one of the few – if only – ‘surviving’ example of such a panel. Of course, it’s effectively useless without all of the other chunks that make up the entire Spectra mainframe, but it’s still an interesting find. The person who found it intends to turn it into what is essentially a piece of home decor, but maybe we’ll get lucky and someone else out there who has been collecting parts and pieces to assemble a working RCA Spectra 70/35 can do something more productive with it.

Since Void Linux uses a rolling release model, there’s not much to report on in the form of new releases and major new features, so I’m taking the release of version 0.60 of XBPS, Void Linux’ package manager, to cheat my way into talking about this excellent Linux distribution. I always think of Void as the “BSD of Linux distributions”, which should give you some vague hint as to what it’s going for.

XBPS 0.60 doesn’t come packed with major new features either, and mostly fixes a ton of bugs, addresses few memory leaks, and changes the way held dependencies and directory removal/creation works when reinstalling a packages, just to name a few. There’s also some performance improvements, as there were apparently some problems in that department due to the increasing number of virtual packages in the Void repository.

If you’re looking for a more traditional, hands-on Linux distribution, Void is an excellent choice. It’s my back-up for if (let’s face it: when) Fedora messes something up.

Disk images have been valuable tools marred by poor performance. In the wrong circumstances, an encrypted sparse image (UDSP) stored on the blazingly fast internal SSD of an Apple silicon Mac may write files no faster than 100 MB/s, typical for a cheap hard drive. One of the important new features introduced in macOS 26 Tahoe is a new disk image format that can achieve near-native speeds: ASIF, documented here.

This has been detailed as a major improvement in lightweight virtualisation, where it promises to overcome the most significant performance limitation of VMs running on Apple silicon Macs. However, ASIF disk images are available for general use, and even work in macOS Sequoia. This article shows what they can do.

↫ Howard Oakley

Exactly what it says on the tin.