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.

Apparently, Donkey Kong Country 2 has runs into a bug in the old SNES emulator ZSNES, where one of the barrels that you’re supposed to be able to precisely control the spinning direction of ends up spinning forever.

This bug is caused by ZSNES not emulating open bus behavior. I believe this was originally discovered by Anomie roughly two decades ago, who subsequently fixed the same bug in Snes9x. This original fix hardcoded the specific addresses to return the values that the game depends on rather than properly emulating open bus, but it fixed DKC2 and probably didn’t break anything else. The bug was never fixed in ZSNES, which is now a long abandoned project (last release in 2007).

Purely out of curiosity, I wanted to dig into this a little more to figure out what exactly in the game code causes these barrels to spin forever in an emulator that doesn’t emulate open bus behavior.

↫ jsgroth

Just in case you’ve always wanted to know.

With X.org being in maintenance mode, with the process of replacing it with Wayland accelerating pretty quickly now, a lot of projects using X.org are looking for ways to prepare for the future. Alpine Linux, a distribution focused on musl, BusyBox, and OpenRC, also wants to reduce its maintenance burden for X11 applications, and so Alpine Linux maintainer Ariadne Conill has come up with something interesting.

Wayback is an experimental X compatibility layer which allows for running full X desktop environments using Wayland components. It is essentially a stub compositor which provides just enough Wayland capabilities to host a rootful Xwayland server.

It is intended to eventually replace the classic X.org server in Alpine, thus reducing maintenance burden of X applications in Alpine, but a lot of work needs to be done first.

↫ Wayback GitHub page

It’s nowhere near done and most likely contains massive amounts of bugs and issues, but the seed has been planted. Wayback will make it possible to keep running X11-based desktop environments even in a full-Wayland environment. This may be necessary in case you need a specific feature not yet available in the Wayland version of your desktop environment, or if your desktop environment of choice simply isn’t going to move to Wayland at all (due to lack of maintainers or whatever).

It’ll also be a boon for retrocomputing, especially as over the coming years and decades unmaintained X11 desktop environments become become ever harder to keep running on modern Linux distributions. While X.org as it exists today certainly isn’t going anywhere any time soon, it will, eventually, stop working properly on Linux distributions who don’t ship it by default anymore, and it’s awesome to already have the beginnings of a project to address this problem.