There’s quite a few ways to mess around with home automation, with the most popular communication methods being things like ZigBee, plain Wi-Fi, and so on. One of the more promising new technologies is Thread, and Dennis Schubert decided to try and use it for a new homebrew project he was working on. After diving into the legalese of the matter, though, he discovered that Thread is a complete non-starter due to excessive mandatory membership fees without any exceptions for non-commercial use.

To summarize: if you’re a hobbyist without access to some serious throwaway money to join the Thread Group, there is no way to use Thread legally – the license does not include an exception for non-commercial uses. If you’re like me and want to write a series of blog posts about how Thread works, there’s also no legal way.

A commercial membership program for technology stacks like Thread isn’t new; it’s somewhat common in that space. Same with requiring certifications for your commercial products if you want to use a logo like the “Works with Thread” banner. And that’s fine with me. If you’re selling a commercial electronics product, you have to go through many certification processes anyway, so that seems fair. But having a blanket ban on implementations, even for non-commercial projects, is absolutely bonkers. This means that no hobbyist should ever get close to it, and that means that the next generation of electrical engineers and decision-makers don’t get to play around with the tech before they enter the industry. But of course, that doesn’t really matter to the Thread Group: their members list includes companies like Apple, Google, Amazon, Nordic, NXP, and Qualcomm – they can just force Thread into being successful by making sure it’s shipped in the most popular “home hubs”. So it’s just us that get screwed over.

Anyway, if you planned to look at Thread… well, don’t. You’re not allowed to use it.

↫ Dennis Schubert

So you can buy Thread dev kits to create your own devices at home, but even such non-commercial use is not allowed. The situation would be even more complex for anyone trying to sell a small batch of fun devices using Thread, because they’d first have to fork over the exorbitant yearly membership fee. What this means is that Thread is a complete non-starter for anyone but an established name, which is probably exactly why the big names are pushing it so hard.

They want to control our home automation just as much as everything else, and it seems like Thread is their foot in the door. Be advised.

To better support you and provide earlier, more consistent access to in-development features, we are announcing a significant evolution in our pre-release program. Moving forward, the Android platform will have a Canary release channel, which will replace the previous developer preview program. This Canary release channel will function alongside the existing beta program.

This change is designed to provide a more streamlined and continuous opportunity for you to try out new platform capabilities and provide feedback throughout the entire year, not just in the early months of a new release cycle.

↫ Dan Galpin on the Android Developers Blog

This new Canary channel is intended for developers, and you can expect a ton of bugs and breaking changes. Updates are basically streamed continuously over the air, but not all changes will make it to a final release of Android (as in, they can be pulled definitively). You can join the new channel with any supported Pixel device, but going back to a beta or final release will require a full wipe.

In Chrome, Skia is used to render paint commands from Blink and the browser UI into pixels on your screen, a process called rasterization. Skia has powered Chrome Graphics since the very beginning. Skia eventually ran into performance issues as the web evolved and became more complex, which led Chrome and Skia to invest in a GPU accelerated rasterization backend called Ganesh.

Over the years, Ganesh matured into a solid highly performant rasterization backend and GPU rasterization launched on all platforms in Chrome on top of GL (via ANGLE on Windows D3D9/11). However, Ganesh always had a GL-centric design with too many specialized code paths and the team was hitting a wall when trying to implement optimizations that took advantage of modern graphics APIs in a principled manner.

This set the stage for the team to rethink GPU rasterization from the ground up in the form of a new rasterization backend, Graphite. Graphite was developed from the start to be principled by having fewer and more comprehensible code paths. This forward looking design helps take advantage of modern graphics APIs like Metal, Vulkan and D3D12 and paradigms like compute based path rasterization, and is multithreaded by default.

↫ Michael Ludwig and Sunny Sachanandani at the Chromium Blog

The level of complexity in browsers and their rendering engines blows my mind every time I read about it. When I first got access to the internet, it consisted of static pages with text and still images, but now browser engines are almost as complex as entire operating systems. Not all of that progress has been good – boy has a lot of it not been good – but we’re stuck with it now, and thus people making browsers have to deal with stuff like this.

If you ever wonder why there really only are two browser engines in the world – Google’s Blink and Apple’s WebKit – this is your answer. Who in their right mind wants to develop something like this from scratch and compete with Google and Apple?

GlobalFoundries today announced a definitive agreement to acquire MIPS, a leading supplier of AI and processor IP. This strategic acquisition will expand GF’s portfolio of customizable IP offerings, allowing it to further differentiate its process technologies with IP and software capabilities.

↫ Press release about the acquisition

MIPS has a long and storied history, most recently as it abandoned its namesake instruction set architecture in favour of RISC-V. MIPS processors are still found in a ton of devices though, but usually not in high-profile devices like smartphones or whatever. Their new RISC-V cores haven’t yet seen a lot of uptake, but that’s a problem all across the RISC-V ecosystem.

Alpine Linux maintainer Ariadne Conill only started working on Wayback a few weeks ago, but in a blog post today they dive into a few more details about how much progress has already been achieved. To refresh your memory, Wayback allows you to run a legacy X11-based desktop environment on top of Wayland by running a stub Wayland compositor in front of Xwayland, capable of serving as a full X server. This way, the transition to Wayland and the removal of X.org from popular distributions won’t mean you can’t run X11-based desktop environments anymore.

Within just a few weeks, the project has made serious progress.

There’s a lot still left to do before we can confidently say that Wayback is ready for distributions to switch to. This work is across the stack: Wayback still needs to expose surfaces that Xwayland can use, Xwayland needs to implement a few new features such as cursor warping and some X extensions inside Xwayland itself need to be properly plumbed (such as Xinerama being able to make use of the Wayland output layout data).

Longer term goals aside, we are at most a few weeks away from the first alpha-quality release of Wayback. The main focus of this release is to get to a point where enough is working that users with basic setups and requirements can be reasonably served by Wayback in place of the X.org server, to allow for further testing. It’s already to a point where I am daily driving it.

↫ Ariadne Conill

Of course, there’s still tons of bugs to figure out and missing functionality to implement, but the fact that they’re just weeks away from a first alpha release is honestly impressive. I really hope Wayback picks up even more and gets adopted by other distributions as well, since it’s such an elegant and future-proof solution to a very real problem. It’s important that desktop environments that will not or cannot transition to Wayland remain available to Linux users regardless of their choice of Wayland or X11.

When facing the slow sunsetting of a windowing system, some people go off on deranged neofascist conspiracy rants against the woke illuminati, while others sit down and develop real forward-looking solutions. I’m glad virtually every Linux distribution that matters trusts the latter over the former.

As of today, Stat Counter reports that Windows 11 now has 50.88% of the Windows market, with Windows 10 dropping to 46.2%, giving it a comfortable lead over its predecessor. Windows 11 has been on the market since 2021 but had only amassed less than 10% of the market by 2022.

It’s been a slow but steady climb since then, growing from 18% to 28% in 2023, with similar growth to 36% in 2024. It’s this year where Windows 11 really started taking off, likely aided by the fact that Microsoft is now pushing Windows 10’s end of support hard.

↫ Zac Bowden at Windows Central

Up to 50% of all Windows users, mere months before Windows 10 is no longer supported, and it took them 4 years to get here. Windows users really don’t like Windows 11, do they?

WinUAE has released version 6.0.0 of the Windows version of the UAE Amiga emulator, packing a truly terrifying number of changes, improvements, and fixes.

Major update to custom chipset emulation. Internally almost everything in main chipset emulation has been rewritten. Fastest possible/JIT mode chipset timing/sync had major changes which can cause side-effects. Bugs are very possible, especially in very rarely used features.

↫ WinUAE website

Going through the changelog is dizzying, ranging from an almost complete rewrite of the main chipset emulation for internal cycle accuracy, to running the emulation of the Denise/Lisa chips in a separate thread for better performance, to a ton of fixes and smaller updates.

With macOS 26, Apple has announced a dramatically new look to their UI: Liquid Glass. Solid material icon elements give way to softer, shinier, glassier icons. The rounded rectangle became slightly more rounded, and Apple eliminated the ability for icon elements to extend beyond the icon rectangle (as seen in the current icons for GarageBand, Photo Booth, Dictionary, etc.).

With this release being one of the most dramatic visual overhauls of macOS’s design, I wanted to begin a collection chronicling the evolution of the system icons over the years. I’ve been rolling these out on social media over the past week and will continue to add to and update this collection slowly over the summer. Enjoy!

↫ BasicAppleGuy

Every single one of these icons is getting progressively worse with almost every design change. They go from beautifully crafted, easily readable and supremely distinguishable icons to generic, repetitive blobs of colour, void of any personality, artistry, or usability considerations. Also, Apple’s new icon design language makes the icons look fuzzy, like they’re not being rendered properly. It’s very unnerving.

The one exception is probably the generic folder icon, which looks fine in all of its incarnations. Then there’s the classic Platinum, pixelated version from Mac OS 9 and earlier, which, together with icons from Windows and BeOS from the same time period, are a whole different style that I don’t think most people would accept anymore these days, but that I absolutely adore.

Mostly I’m just sad that the craft of making exquisite icons for operating systems is dying, replaced by what almost look like “AI” generated blobs of indeterminate meaning, that rely more on preexisting knowledge of the operating system and its applications in question than on being recognisable and decipherable by anyone. I truly hope Windows and the various open source desktops don’t follow in Apple’s footsteps here.

Since the disastrous launch of the RTX 50 series, NVIDIA has been unable to escape negative headlines: scalper bots are snatching GPUs away from consumers before official sales even begin, power connectors continue to melt, with no fix in sight, marketing is becoming increasingly deceptive, GPUs are missing processing units when they leave the factory, and the drivers, for which NVIDIA has always been praised, are currently falling apart. And to top it all off, NVIDIA is becoming increasingly insistent that media push a certain narrative when reporting on their hardware.

↫ Sebin Nyshkim

Out of all the issues listed here – and there are many, and each is bad enough on their own – it’s the frame generation and related pressure campaigns on reviewers that really get on my nerves the most. Technologies like DLSS (rendering at a lower internal resolution scaling that up) and frame generation (injecting fake “AI” frames to jack up the frame rate) can be fine technologies when used at the consumer’s discretion to find a balance between improved perceived performance in exchange for blurry image quality and artefacting, but we’ve now reached a point where NVIDIA will only boast about performance figures with these technologies enabled, downsides be damned.

If that wasn’t misleading enough, the company is also pressuring reviewers who don’t enable these technologies, and focus on real frames, real resolutions, and this, real performance. If you don’t comply, you’re not getting the next crop of GPUs in early access. It’s the kind of shit Apple pulls all the time, and we need less of it, not more.

Just don’t buy NVIDIA. They’re already a terrible choice if you’re running anything other than Windows, but the company’s recent behaviour and serious missteps have made the choice for AMD or Intel only more obvious.

Redox continues to make progress, and as another month has passed us by, it’s time for another monthly update. This past month, the focus has been on UNIX domain sockets, which are needed for Redox’ goal of running Wayland.

As we continue to move forward with our plans for Wayland, a key technology for Wayland support is the ability to send file descriptors over Unix Domain Sockets. File descriptor sending is also an important part of many other OS features, including Capability-based Security.

Our Redox Summer of Code project to implement that ability has been progressing very well. Ibuki, a new member of the Redox team, has jumped right into the deep end, and implemented the sendmg and recvmsg functionality, and continues to move forward with work on UDS.

↫ Ribbon and Ron Williams

You can read more about the UNIX domain sockets progress in a detailed post on the Redox website. Redox now also supports network booting through PXE, but for now, only UEFI is supported. Of course, all of this work is topped off with the usual slew of fixes in relibc, RedoxFS, various drivers, and more, as well updated ports across the board.

A recent bug report filed against Ubuntu’s upgrading tool confirmed a major change with regards to the RISC-V requirements for the upcoming Ubuntu 25.10 release — most existing RISC-V devices will not be able to run Ubuntu 25.10.

How come?

↫ Joey Sneddon at omgubuntu.co.uk

RISC-V just isn’t delivering. That’s the cold and harsh truth more and more people are having to deal with, such as Chimera Linux dropping RISC-V support because the ecosystem is simply lacking the kind of powerful and available hardware to sustain itself (Chimera got lucky, though, and gained access to a Milk-V Pioneer through Adélie Linux). The number of systems and boards that are both powerful and available is close enough to zero that it might as well be zero, and if neither users nor developers can buy RISC-V hardware, what’s the point in supporting it?

The issue for Ubuntu specifically is that version 25.10 of the distribution intends to target only the RVA23 baseline RISC-V profile, while currently Ubuntu supports RVA20 as the baseline. This higher baseline profile requires a number of extensions to the instruction set that no existing hardware yet supports, making 25.10 effectively a clean break for all existing RISC-V hardware. In other words, if you’re running Ubuntu on RISC-V hardware today, you won’t be able to upgrade to 25.10 or higher.

RISC-V really needs vastly improved hardware availability, because right now it’s just not delivering on the years of promises.

Amiga lore is full of exciting tales. Many of them are retold to demonstrate how the incompetence of Commodore’s management destroyed a platform that, by rights, was destined for success. Coulda, shoulda, and the Amiga woulda risen as rightful ruler of all other computer platforms, forever and ever. Amen.

One of those stories is about how Sun Microsystems allegedly showed interest in the Amiga 3000 during the early 1990s. It’s a classic Amiga anecdote, usually recounted without much reflection, and one I’ve certainly helped perpetuate.

Alas, the more I think about it, the less it adds up. Fact or factoid? Let’s speculate!

↫ Carl Svensson

Great speculation with some solid reasoning and sourcing. Considering that had been some minor joint marketing between Sun and Commodore, my money is on the talks around that deal birthing rumours about more extensive Sun involvement in the Amiga 3000. At this point in time, however, decades after the fact and with several conflicting account, it’s unlikely we’ll ever get a solid answer.

With recent efforts to improve accessibility in GNOME and KDE, as well as a renewed focus on highlighting the many issues that still need fixing, the Linux desktop is making meaningful strides in becoming more accessible to those among us with disabilities. Obviously, the Linux desktop is bigger than just GNOME and KDE, so today we have elementary OS improving its accessibility features in a variety of ways.

July is Disability Pride Month, an opportunity for us to consider how we’re serving our disabled community and work on breaking down barriers to access. Last year we had the pleasure of being introduced to Florian—a fully blind cybersecurity enthusiast—and thanks to his feedback we completely rewrote navigation in Onboarding to be more keyboard and screen reader friendly, as well as took another look at Installation and Initial Setup to vastly improve our entire first run experience for blind folks. Plus, we implemented the screen reader interface in the  +  window switcher. Thanks to this feedback, elementary OS 8 can be installed and set up completely blind, an important win for maintaining your independence as a person with vision disabilities.

Since the release of OS 8 we’ve been working on things like improving contrast, support for Dark Mode screenshots and brand colors in AppCenter, turning on or snoozing Dark Mode without canceling your schedule, expanding the scope of the “Reduce Motion” setting, and adding more options to reduce distracting notification bubbles. Plus, thanks to feedback from Aaron who you may know from his blog series on Linux accessibility, Notifications and the Shortcut Overlay both got releases that add screen reader support.

↫ Danielle Foré at elementary’s blog

I’m glad we’re finally putting to rest this idea that accessibility features should be afterthoughts, relevant to only a minute percentage of people. Not only is the disabled community way bigger than we might think, many of the features they require are simply also extremely nice and beneficial to users who might not actually require them. I know tons of people who, for instance, love reduce motion features simply because it makes their operating system feel faster, or people who just don’t want to be bothered with notifications the instant they arrive.

Accessibility goes far beyond what we traditionally think of as accessibility features, like screen readers or high contrast modes. Making software more accessible for those that require it, also makes software more accessible for those that merely desire it. Even though elementary OS probably isn’t the type of distribution that appeals to the average OSNews reader, I’m incredibly happy they’re taking accessibility seriously, and I intend to continue to highlight such improvements.

I’ve used thin clients at home for quite a while – both for their intended use (remotely accessing a desktop of another system); and in the sense of “modern thin clients are x86 boxes that are wildly overpowered for what they run, so they make good mini servers.”

Recently, I saw a bulk lot of Sun Ray thin clients pop up on Trade Me (NZ’s eBay-like auction site) – and with very little idea of how many clients were actually included in this lot, I jumped on it. After a 9 hour round-trip drive (on some of the worst roads I’ve seen!), I returned home with the back of my car completely packed with Sun Rays. Time for some interesting shenanigans!

↫ catstret.ch

I was unaware you could still set up a Sun Ray environment with latest versions of OpenIndiana, and that has me quite interested in buying a few Sun Rays off eBay and follow in the author’s footsteps. It seems like it’s not too difficult, and while there’s some manual nonsense you have to do to get everything to install correctly, it’s nothing crazy.

To this day, I firmly believe that the concept of dumb thin clients connected to powerful servers is an alluring and interesting way of computing. I’m not talking about connecting up to servers owned by massive technology corporations – I’m talking about a few powerful servers down in your own basement or attic or whatever, serving applications and desktops straight to basic thin clients all around your house. These thin clients can take the shape of anything, from something like a desktop setup in your office, down to a basic display in your kitchen for showing recipes, setting timers, and other basic stuff – and everything in between.

Sun Rays could ‘hot desk’ using personal smart cards, but of course, in this day and age you’d have your smartphone. The thin clients around your house would know it was you through your smartphone, and serve up the applications, desktop, tools, and so on that you use, but everything would be running on the servers in your house. Of course, my wife would have her own account on the server, as would our children, when they are old enough.

None of this is impossible with today’s tools and computing power, but it wouldn’t be easy to set up. There are no integrated solutions out there to make this happen; you’d have to scrap it together from disparate parts and tools, and I doubt such a house of cards would end up being reliable enough not to quickly become a massive annoyance and time sink. On top of that, we live in a rental apartment, so we don’t even have a basement or attic to store loud servers in, nor are we allowed to drill holes and route Ethernet cabling for optimal performance.

Anyway, there’s no chance in hell any of the major technology companies would build such a complex ecosystem in a world where it’s much easier and more profitable to force people to subscribe to shitty services. In my ideal computing world, though – a server in every home, with cheap thin clients in every room.