OSnews

A couple of days ago, Microsoft announced9,000 layoffs across its global workforce, impacting its engineering, Xbox, sales, and management teams. This move also affected various initiatives, resulting in thecancellation of at least three Xbox games, job cuts across various studios, and even the shuttering of one game studio, The Initiative. In the wake of this dark day in the the tech industry, a tone-deaf Microsoft executive urged laid off workers to turn to AI tools for emotional support. Usama Jawad at Neowin These corporations are raking in massive amounts of profit, they're doing better than ever, the cup of money runneth over, and yet, they keep laying off thousands and thousands of people almost every few months. The incentives in modern-day capitalism clearly aren't working out for the vast majority of people, and then to give that final kick when you're already down, some asshat manager tells you to talk to" sparkly autocomplete for emotional support. Fuck this guy.

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 thesendmgandrecvmsgfunctionality, 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.

All of this to say: value is complicated. The Pi 5 ismuchmore compact and slightly more power efficient (especially at idle) compared to the cheapest N1XX Intel systems. The Intel systems are better suited for a desktop use case. The Pi 5 can be run off PoE power, for easier one-cable networking + power. The Intel systems are more compatible with a wider range of software (not the least of which isanything requiring Windows). Jeff Geerling Intel's N100 and N150 are vastly underappreciated. The mini laptop I reviewed over a year ago is built around the N100, and I still use it every day for watching YouTube, writing OSNews posts, and so on. I never run into performance issues, battery life is excellent, and I don't have to deal with the annoyances of using ARM. The catch is that you're going to want to use Linux - I use Fedora KDE - because Windows' performance on the N100 is dreadful. I don't think the jump from the N100 to the N150 is worthwhile enough to buy the new version of my mini laptop, so I'll stick with what I have. I do hope Intel continues the Nxxx line or processors, because it offers something no other x86 chip offers: more than reasonable performance at low power usage for an incredibly low price.

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 willnotbe 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 Adelie 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 Amigawouldarisen 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 oneI'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.

Clifton Sellers attended a Zoom meeting last month where robots outnumbered humans. He counted six people on the call including himself, Sellers recounted in an interview. The 10 others attending were note-taking apps powered by artificial intelligence that had joined to record, transcribe and summarize the meeting. Lisa Bonos and Danielle Abril at The Bezos Post Management strongly encourages - mandates - that everyone use AI" to improve productivity, but then gets all uppity when people actually do. Welcome to finding out".

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 toFlorian-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 fromAaronwho you may know fromhis blog series on Linux accessibility, Notifications and the Shortcut Overlay both got releases that add screen reader support. Danielle Fore 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 theirintendeduse (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.

We need a new framework for how to defend against trolls". The feeding metaphor ran its course many years ago. It is done and will not be coming back. New online risks demand that we adapt and become proactive in protecting our spaces. We have to loudly and proudly set the terms of what is permissible. Those holding social or institutional power in communities should be willing to drop a few loudfuck offsto anyone trying to work their way in by weaponizing optics, concern trolling, or the well knowntolerance paradox". Conceding through silence, or self-censorship, only emboldens those who benefit from attacking a community. diegoebe Een volk dat voor tirannen zwicht, zal meer dan lijf en goed verliezen, dan dooft het licht.

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.

This blog post is intended to notify all Windows Hardware program partners that Microsoft has taken a strategic initiative to clean up legacy drivers published on Windows Update to reduce security and compatibility risks. The rationale behind this initiative is to ensure that we have the optimal set of drivers on Windows Update that cater to a variety of hardware devices across the windows ecosystem, while making sure that Microsoft Windows security posture is not compromised. This initiative involves periodic cleanup of drivers from Windows Update, thereby resulting in some drivers not being offered to any systems in the ecosystem. Microsoft's Hardware Dev Center The general gist is that Microsoft is going to remove all drivers from Windows Update for which newer versions exist - or, to put it in a different way, only the latest versions of a driver are going to remain available on Windows Update. It's effectively a clean-up of Windows Update, and the only way older versions of drivers will remain available on Windows Update is if the manufacturer in question can make a business justification" to keep them around. Some of this may sound surprising, since many people assume Windows Update only offers the latest versions of drivers - annoyingly so, sometimes - but this isn't the case. Corporations with fleets of devices can actually determine exactly which drivers get sent to their devices, including opting for older versions in case newer versions have regressions or otherwise cause issues. Sometimes you just don't have a choice. According to Adam Demasi, the creator and maintainer of the amazing Legacy Update service, Microsoft hasn't deleted a single driver or update from Windows Update since 2001 (save for problematic updates). This results in a truly massive collection of updates and drivers, and that's causing real problems for Microsoft. Windows Update has a pretty cool system of describing whether an update is necessary to be installed on the current system, or if it is already installed. It also builds a relationship graph between updates, to indicate when they have been replaced by a newer update that includes all changes from the previous update. That system is also its downfall, causing the Windows Update service to beincredibly slowin checking for updates, possibly never completing the check at all. This issue also applies to WSUS, which despite being based on the very robustSQL Server, struggles with the number of drivers Microsoft hosts on Windows Update.As of April, we know that Windows Update hosts 1,799,339 drivers, and this creates a 138 GB database that requires almost 16 days to synchronise down from the main servers. The WSUS server is brought to its knees, with frequent timeouts while it furiously tries to complete database queries. (The PC used is a Ryzen 5700G with 32 GB of 3600 MHz RAM and 500 GB of NVMe, running Windows Server 2025 and SQL Server 2022.) Adam Demasi From this, it's easy to understand why Microsoft would want to perform some housekeeping, followed by a new set of rules around only keeping the latest versions of drivers around in Windows Update. Demasi also notes that these plans by Microsoft won't affect drivers for old devices, since they will still be served their newest" driver version, and it won't affect Legacy Update either.

The GPU in your computer is about 10 to 100 times more powerful than the CPU, depending on workload. For real-time graphics rendering and machine learning, you are enjoying that power, and doing those workloads on a CPU is not viable. Why aren't we exploiting that power for other workloads? What prevents a GPU from being a more general purpose computer? Raph Levien Fascinating thoughts on parallel computation, including some mentions of earlier projects like Intel's Larabee or the Connection Machine with 64k processors the '80s, as well as a defense of the PlayStation 3's Cell architecture.

The blue screen of death has been such a core part of Windows that's it's become part of humanity's collective consciousness. They're not nearly as common anymore as they used to be back in the Windows 9x and early Windows XP days, but they do still occasionally when dealing with broken hardware, shoddy drivers, or other such faults. Well, the blue screen of death is losing its eponymous blue colour, and will now clearly mention the stop code and where - in which driver - the kernel panic occurred. The Windows 11 24H2 release included improvements to crash dump collection which reduced downtime during an unexpected restart to about two seconds for most users. We're introducing a simplified user interface (UI) that pairs with the shortened experience. The updated UI improves readability and aligns better with Windows 11 design principles, while preserving the technical information on the screen for when it is needed. David Weston at the Windows Blogs This is part of a new feature in Windows 11 called quick machine recovery, or QMR. If a Windows PC gets stuck in a boot loop, ending up in the Windows Recovery Environment, Microsoft can now deploy fixes and remediations through WinRE. This feature will become available later this year by default on Windows 11 Home, while on Windows 11 Pro and Enterprise, administrators can control how this feature works. So far, it seems QMR is only intended to be used for widespread outages, but I wonder if it would be possible to eventually use QMR locally. It would be pretty neat if Microsoft released the server-side component of QMR so individuals can run and (ab)use it locally for their own machines.

The world isn't short of classic Macintosh emulators, but one more certainly cannot hurt. Snow emulates classic (Motorola 680*0-based) Macintosh computers. It features a graphical user interface to operate the emulated machine and provides extensive debugging capabilities. The aim of this project is to emulate the Macintosh on a hardware-level as much as possible, as opposed to emulators that patch the ROM or intercept system calls. It currently emulates the Macintosh 128K, Macintosh 512K, Macintosh Plus, Macintosh SE, Macintosh Classic and Macintosh II. Snow's homepage Snow is written in Rust and open source under the MIT license.

It's been nearly a year since a faulty CrowdStrike update took down 8.5 million Windows-based machines around the world, and Microsoft wants to ensure such a problem never happens again. After holding a summit with security vendors last year, Microsoft is poised to release a private preview of Windows changes that will move antivirus (AV) and endpoint detection and response (EDR) apps out of the Windows kernel. Tom Warren at The Verge After the CrowdStrike incident, one of the first things Microsoft hinted as was moving antivirus and EDR applications out of the kernel, building an entirely new framework for these applications instead. The company has been working together with several large security vendors on these new frameworks and APIs, and it's now finally ready to show off this new work to the outside world. Instead of designing the new frameworks and APIs in-house and just dumping them on the security vendors, Microsoft requested the security vendors send them detailed documentation on how they want the new frameworks and APIs to work. This first preview of the new implementation will be private, and will allow security vendors to request changes and additional features. Microsoft states it will take a few iterations before it's ready for general availability, and on top of that, security software is only the first focus of this new effort. It turns out Microsoft wants to move more stuff out of the kernel, with anti-cheat software - more accurately described as rootkits, like Riot's Vanguard - being an obvious next target. Perhaps this effort could have some beneficial side effects for gaming on Linux, which you should be doing anyway if you want better performance, because Windows games seem to perform better on Linux than they do on Windows.

Jokes aside, this is exciting news. PNG is back to its former glory after its progress stalled for over two decades. Did you know the U.S. Library of Congress, Library and Archives Canada, and the National Archives of Australia recommend PNG? It is important that we keep PNG current and competitive. After 20 years of stagnation, PNG is back with renewed vigor! With these titans behind it, the image format is back with full momentum. Work has already begun on the nexttwo PNG spec updates. Chris Blume The new PNG specification update adds proper HDR support, which is probably its most important new features. Chris Lilly, one of the original creators of PNG and actively involved in these new updates as well, has a detailed blog post diving into how HDR in PNG works. Other changes include officially adding Mozilla's animated PNG implementation to PNG, support for EXIF data, and a ton of smaller changes and cleanups.

For a while now I've been wondering if Microsoft would blink when it comes to Windows 10's rapidly approaching end of support date. Only a few weeks ago, Microsoft at the very least twitched by extending support for Microsoft Office on Windows 10, which should've been an indication of what was to come. Today, Microsoft actually blinked: regular consumers wishing to keep using Windows 10 after support ends in October will now be able to sign up for an additional year of security updates. Microsoft is making this possible by allowing Windows 10 users to sign up for the Windows 10 Extended Security Update program for one year of extended updates, for free. This program is normally only available to paying enterprise customers, and this marks the first time the company is letting regular consumers make use of it. The for free" requires some serious caveats, though, as depending on how you look at it, it's not free at all. You options are to either pay around $30, pay 1000 Microsoft points, or to sign up for the Windows Backup application to synchronise your settings to Microsoft's computers (the cloud"). This last option is technically free, but not only does the free tier include just 5GB of online storage, it also makes use of OneDrive, so if you're using OneDrive to store your documents and other files you may need to pay for additional storage. On top of that, anything that requires the use of OneDrive is simply not free", and only allows Microsoft to further get its claws in you. If Sartre was alive today, Huis clos would've declared L'enfer, c'est OneDrive" instead. Regardless, it's the stay of execution many Windows 10 users have been waiting for, even if it isn't entirely perfect. Sure, choosing between an unmaintained Windows 10, Windows 11, and using OneDrive is about as pleasant as shoving shards of glass underneath your fingernails, and I have a feeling quite a few people are about to find out.

IceWM, the venerable X11 window manager, has released version 3.8.0, with some small tweaks, bug fixes, and changes. The theme menu now loads faster, the processor and memory graphs use less processor cycles, among other small tidbits.

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.

For a while, X terminals were a reasonably popular way to give people comparatively inexpensive X desktops. These X terminals relied on X's network transparency so that only the X server had to run on the X terminal itself, with all of your terminal windows and other programs running on a server somewhere and just displaying on the X terminal. For a long time, using a big server and a lab full of X terminals was significantly cheaper than setting up a lab full of actual workstations (until inexpensive and capable PCs showed up). Given that X started with network transparency and X terminals are so obvious, you might be surprised to find out that X didn't start with them. Chris Siebenmann I did indeed assume X terminals were part of the ecosystem from day one, but it makes sense that it took a while, and that they didn't enter the scene until X had established itself as the standard windowing system in the UNIX world. I've been trying to get my hands on specifically the last HP X terminal, but they're hard to find and often very expensive. I'd love to get a taste of a proper networked X environment on real UNIX, in the way people actually used to use it professionally. As a sidenote, Siebenmann is doing such an excellent job with these stories about UNIX, X11, and related matters. He's like the Raymond Chen of the UNIX world.

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.

It's 2025, and we're going to talk about BeOS, AtheOS, Cosmoe, and OpenBeOS, all in one news item, right here, right now, on OSNews. In the very early 2000s, Cosmoe was a unique project that started out as a merger of the AtheOS userland with the Linux kernel. AtheOS, in turn, was one of the quintessential hobby operating systems of the golden age of the advanced hobby operating systems, the early 2000s. AtheOS would eventually be abandoned in 2002, but would be forked into Syllable and continue development until it, too, was eventually abandoned in 2012. Cosmoe was the brainchild of Bill Hayden, and originally consisted of the AtheOS userland running on top of the Linux kernel, in order to address the lack of supported hardware a custom operating system kernel inevitably has to deal with. Not long after the start of Cosmoe, AtheOS was abandoned, as mentioned above, but a new project had entered the scene: OpenBeOS, now known as Haiku. Hayden switched gears, and instead started porting the parts that made up OpenBeOS to run on the Linux kernel. This project progressed nicely, but in 2007 Cosmoe came to a halt (ironically, our last item about Cosmoe is Cosmoe is back) as Hayden had no more free time left to work on it, being a father of five, and so he decided to put the project on hold indefinitely. That is, until last year, when everything changed. In mid-2024, my 3rd son Joshua, not even born when I started this project but who is now in college studying to be a programmer himself, had some questions about operating systems. I decided to dust off Cosmoe and see if I could get it running again, to show him what I had worked on. At first it would only compile and run on extremely old 32-bit versions of Mandrake Linux from 2007. But I had caught the bug again. Not only had I forgotten how fun Cosmoe was to program, but the intervening 17 years of progress made by OpenBeOS (now Haiku) made the certain aspects of this revival come at lightning speed. Day by day, week by week, I got it running on newer versions of Linux, and re-synchronized it with ever-more-recent releases of Haiku. After about 2 months of late-night effort, I had a version of Cosmoe that was 64-bit compatible, ran on multiple modern Linux releases, and was almost completely up-to-date with the latest Haiku source changes. Cosmoe's history page We're halfway through 2025 now, and Cosmoe now exists as two separate, but related projects. There's Cosmoe Classic, which is the updated and modernised incarnation of Cosmoe's original concept: Haiku's userland running on top of the Linux kernel. In its current form, it runs inside an SDL window on your Linux desktop, as there's no native video driver. Cosmoe Classic, however, is not what Hayden is focusing on. Instead, Hayden is focusing on the new Cosmoe, which takes the same idea - the Haiku userland running on a Linux kernel - but implements it in a completely different way: Cosmoe is a C++ class library that allows developers to build rich, native Linux apps with the easy-to-use BeOS API. This library is a light-weight, serverless version of Cosmoe Classic which targets the Wayland compositor on Linux. Cosmoe's GitLab page What Cosmoe on Wayland (to differentiate it from Cosmoe Classic) allows you to do is run BeOS/Haiku applications on Linux, provided you are running Wayland. The project is in an alpha state, but once compiled, it comes with a few BeOS/Haiku sample applications you can run right on your Wayland-based Linux desktop. Hayden states that about 95% of the BeOS API is implemented in Cosmoe, with the TODO file giving an idea of what tasks need to be done to improve compatibility and implement other improvements. The return of Cosmoe is certainly not something I saw coming, but I'm incredibly excited. I'm not entirely sure about the usefulness of running Haiku applications on Wayland on Linux, but who the hell cares - this is an awesome project, with a ton of cherished history behind it that gives me butterflies in my stomach. It's absolutely beautiful to see a project like this come back to life in 2025. Cosmoe is back. Again.

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 singlevolunteer, badly tested, written in a memory-unsafe language and full ofsecurity bugs. It is foolish to use this software to process untrusted data.As such, we treat security issues like any other bug. Each security reportwe 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.

Welcome news coming out of Jolla, the company that develops Sailfish OS. Up until now, if you bought their Jolla C2 smartphone, you had to pay a yearly subscription fee in order to get updates (with the first year included in the purchase price). Today they've announced their dropping this construction, and they now guarantee five years of free updates. We're happy to announce that from now onwards long-term Sailfish OS updates are included free-of-charge to all Jolla C2 devices for a minimum of 5 years. This applies also to everybody who have already purchased the Jolla C2. Announcement at the Jolla forums People don't like subscriptions, and I wouldn't be surprised if Jolla was simply running into a lot of resistance to this subscription model from potential customers. Nobody likes subscriptions, and I think that counts doubly so for the kinds of people interested in buying a phone like the C2 with Sailfish OS.

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.4GHz), 32GB 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.

Accessibility is something that doesn't get nearly enough attention, especially considering because not only will we need accessibility features eventually as we grow older, but also because a lot of accessibility features are just helpful even if you don't technically need them. Given these facts, it's a shame that accessibility is usually an afterthought, doubly so on open source desktops, a problem we recently talked about. But what if you don't just need to use a few applications as, say, a blind person, but also actually program as a blind person? Acidic Light, accessibility engineer at KDE e.V., has published a blog post about how screen readers actually work, and what it's like to program while blind, and the conclusions are not exactly great. I truly feel that, based on my experience with KDE and my experience actually delving into the weeds with AccessKit in a custom UI system, that accessibility programming just isn't accessible. Unless you happen to already understand the way each platform works, trying to find resources on how to actually let a screen reader know your UI exists is just painful. It's going to involve reading code other people have already written. It's going to involve hours, if not days, if not weeks of research and painful debugging. You likely won't be able to ask many people for help, because they'll know as much as you do. Acidic Light If the people who know most what is needed to make a program accessible have so many problems actually making programs accessible, because the tooling, documentation, and institutional knowledge just isn't there, what hope do other programmers have to make their code accessible? If a blind programmer can't scratch their own itch, so to speak, we're never going to reach a point where accessibility becomes a given. I'm very happy awareness of accessibility is growing, but I feel like this isn't the first time we've seen an increase in accessibility awareness only for it to eventually fizzle out without meaningful improvements for those that need it the most. I really hope it sticks this time.

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.

Wayland this, Liquid Glass that - but what if you just want a nice, comforting text-based environment? Sure, you can just boot straight into a terminal, or perhaps get fancy about it with Screen or whatever, but what if you want a text-based environment, but don't want to give up windows, menus, your mouse? How about a graphical user interface made up entirely of text? It looks exactly like what you'd think this would look like, and I find it absolutely fascinating. I'm not entirely sure how usable it is or who or what use case it's optimised for, but I adore the dedication to the cause. It works on both Linux and FreeBSD, and most likely other systems as well.

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.

Are you still using Windows 7, 8, 8.1, or a 32 bit version of Windows, relying on LibreOffice for your sexy office tasks of writing TPS reports and calculating and tabulating juicy, plump numbers? Bad news: the next version of LibreOffice will remove support for these platforms. Buried deep in the release notes of the second beta for LibreOffice 25.8, it reads: Support for Windows 7 and 8/8.1 was removed. Support for x86 (32-bit) Windows builds is deprecated. LibreOffice 25.8 beta 2 release notes I honestly doubt many people actually still rely on LibreOffice on these platforms, and even if for some unfathomable reason you do, you are probably also okay with sticking with an older version of LibreOffice to keep your weird setup going a few years longer. You do you.

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.

With the release of Android 16, Google changed how it developed Android. Development is now taking place behind closed doors, with the code dropped after the corresponding version has been released to Pixel devices. Well, it turns out this wasn't the only thing Google has changed about Android development. As the developers of CalyxOS, a popular de-Googled Android ROM, dove into the Android 16 AOSP source code, they realised something very important was missing: the device-specific source code for modern Pixel devices. Android 16 was released to AOSP yesterday but with a one big difference than typical releases: Google did not publish any device-specific source code for supported, modern Pixel devices. In previous years, Google released full device trees alongside new Android versions. This allowed developers to build and boot AOSP on Pixel hardware relatively easily. With Android 16, only the platform/framework code has been released. The device trees are missing, at least for now. This means AOSP 16 cannot currently be built or run on any recent Pixel device easily just using official source. It's unclear whether this is a delay or a policy change. Either way, it seriously disrupts custom ROM development and our porting efforts. CalyxOS on Reddit If this is truly a policy change, it's a big one that affects custom ROM developers considerably. Pixel devices were special" among custom ROM developers because support for them was part of AOSP releases, so they were well-supported by projects like CalyxOS, GrapheneOS, and LineageOS, including all the hardware components, and with quick updates. Without access to the Pixel-specific source code for the Pixel 6 to Pixel 9a, these devices will now have to be treated like any other Android phone as far as ROM developers go, meaning it'll take a lot more work and time to get them to work properly with new major Android releases. Google did not announce this potential policy change, and this has some in the custom Android ROM community on edge. I've been talking to people in the custom ROM community, and the story goes that a few months ago, at least one of these communities was approached by a journalist who wanted to talk to them. This journalist claimed that Google intends to discontinue the Android Open Source Project, with the first step Google would take being no longer releasing the device-specific Pixel source code (something nobody knew would happen until yesterday). The fact that this first step has now become a reality lends some credence to the journalist's claim that Google is discontinuing AOSP. However, since such tips are not uncommon, and since there was no way to verify, the custom ROM developers in question didn't really know what to do with it. During the writing of this article over the past 12 hours, Google itself has also responded to what is apparently a growing, now public concern in the wider Android community. Seang Chau, Google VP and GM of Android Platform, published a Tweet, disclaiming Google has any intentions to close up shop for AOSP. We're seeing some speculation that AOSP is being discontinued. To be clear, AOSP is NOT going away. AOSP was built on the foundation of being an open platform for device implementations, SoC vendors, and instruction set architectures. AOSP needs a reference target that is flexible, configurable, and affordable - independent of any particular hardware, including those from Google. For years, developers have been building Cuttlefish (available on GitHub as the reference device for AOSP) and GSI targets from source. We continue to make those available for testing and development purposes. Seang Chau This seems like a solid denial from Google, but it leaves a lot of room for Google to make a wide variety of changes to Android's development and open source status without actually killing off AOSP entirely. Since Android is licensed under the Apache 2.0 license, Google is free to make Pixel Android" - its own Android variant - closed source, leaving AOSP up until that point available under the Apache 2.0 license. This is reminiscent of what Oracle did with Solaris. Of course, any modifications to the Linux kernel upon which Android is built will remain open source, since the Linux kernel is licensed under the GPLv2. If Google were indeed intending to do this, what could happen is that Google takes Android closed source from here on out, spinning off whatever remains of AOSP up until that point into a separate company or project, as potentially ordered during the antitrust case against Google in the United States. This would leave Google free to continue developing its own Pixel Android" entirely as proprietary software - save for the Linux kernel - while leaving AOSP in the state it's in right now outside of Google. This technically means AOSP is not going away", as Chau claims. Of course, other parties would then be free to continue working on and contributing to AOSP, but AOSP itself would no longer benefit from the work done by Google. Again, this feels very similar to how illumos and OpenIndiana are built atop the last open source release of Solaris from 2010, without any of the additional work Oracle has done on Solaris since then. As you can tell, there's a lot of speculation here, because even if all of this is true, it seems the ongoing court case and any rulings that come of it will play a major role in Google's decision-making process. The Android Open Source Project has been gutted over the years, with Google leaving more and more parts of it to languish, while moving a lot of code and functionality into proprietary components like Google Mobile Services and Google Play Services. Taking Pixel Android" closed source almost feels like the natural next step in the process of gutting AOSP that's been ongoing for well over a decade. As it stands today, a default AOSP installation requires a lot of additional components and applications before it can be considered a complete mobile

GNOME has announced it'll be increasing its dependency on systemd, the popular init system used by most (popular) Linux distributions. While GNOME already had a few relatively inconsequential dependencies on systemd, it was effectively not a huge problem to run GNOME on operating systems that don't have systemd, which most notably includes the various flavours of BSD. That's going to change. There's going to be two changes, one of which is relatively minor, and one of which will pose much bigger problems. The minor change involves GDM becoming dependent on systemd's userdb infrastructure in order to clean up a lot of GDM's code involved in multi-seat setups and remote login. Currently, this works through a series of hacks that the GDM developers are going to clean up, switching to using systemd-userdb to dynamically allocate user accounts, and then runs each login screen as a unique user". To aid non-systemd environments during this transition, GDM will get a temporary alternate code path that enables you to run GDM without systemd-userdb. So if you compile GDM against elogind, GDM will use an alternative trick to enable multiple graphical sessions under the same user. This trick will remain in place at least until GNOME 50, but its future after that is uncertain. The second change is much more involved. Next, the bigger change. Since GNOME 3.34, gnome-session uses the systemd user instance to start and manage the various GNOME session services. When systemd is unavailable, gnome-session falls back to a builtin service manager. This builtin service manager uses .desktop files to start up the various GNOME session services, and then monitors them for failure. This code was initially implemented for GNOME 2.24, and is starting to show its age. It has received very minimal attention in the 17 years since it was first written. Really, there's no reason to keep maintaining a bespoke and somewhat primitive service manager when we have systemd at our disposal. The only reason this code hasn't completely bit rotted is the fact that GDM's aforementioned hacks break systemd and so we rely on the builtin service manager to launch the login screen. Well, that has now changed. The hacks in GDM are gone, and the login screen's session is managed by systemd. This means that the builtin service manager will now be completely unused and untested. Moreover: we'd like to implement a session save/restore feature, but the builtin service manager interferes with that. For this reason, the code is being removed. Adrian Vovk Mitigating this change will be a lot more involved for operating systems that don't use systemd, and the blog post goes into detail into what, exactly, needs to be done in systemd-less environments. There's quite a few systemd components and other little tidbits that you will need to find or create alternatives for, and considering you'll need to have all of it in place roughly by GNOME 50, roughly a year from now, I can imagine this causing quite a few headaches for platforms like the BSDs and Linux distributions using init systems other than systemd. With these changes, GNOME further solidifies itself as a Linux desktop only - and lest anyone forget, that's entirely within their right to do. Systemd haters can jump up and down all they want, but in the end, they have no right to demand that GNOME developers spend precious time and resources testing GNOME on and developing it for platforms that they themselves do not use. They're clearly targeting the trifecta of Linux, system, and Wayland, and that's their choice to make, not anyone else's. Still, if operating systems like OpenBSD and FreeBSD, or Linux distributions without systemd intend to continue offering a fully functional GNOME desktop, they're going to have some work to do.

And I've got another custom hobby operating system for you today: Munal OS. An experimental operating system fully written in Rust, with a unikernel design, cooperative scheduling and a security model based on WASM sandboxing. Munal OS GitHub page Munal OS has no bootloader, but is instead compiled into a single EFI binary that contains all it needs to function, including a few applications. Since Munal OS relies on a PCI driver that communicates with QEMU via the VirtIO 1.1 specification for things like input and graphics, it can't yet run on real hardware. It has its own UI toolkit, and comes with applications like a basic web browser, a text editor, and a Python terminal.

Xeneva is an operating system for both x86_64 and ARM64 architectures, built from the ground up. The Kernel is known as Aurora' with hybrid kernel design and the entire operating system is known as Xeneva'. XenevaOS GitHub page It's remarkably complete, with driver loading and linking, up to SSE 3 support, USB3 and Intel HD audio support, networking, and a whole lot more of the basics that make up a modern complete operating system. On top of all this, it also has a compositing window manager, a desktop environment, a terminal with VT100 support, Freetype2 font rendering, and much more. It also comes with a few basic applications like a file manager, calculator, audio player, and so on. It's written in C (and some C++), and uniquely, can only be built in a Windows environment, something you don't see very often. It definitely looks quite impressive.

Today, we're bringing you Android 16, rolling out first to supported Pixel devices with more phone brands to come later this year. This is the earliest Android has launched a major release in the last few years, which ensures you get the latest updates as soon as possible on your devices. Android 16 lays the foundation for our new Material 3 Expressive design, with features that make Android more accessible and easy to use. Seang Chau at the Google blog Android 16 doesn't seem like a very big release, and that's because for most users, it really isn't. There's some neat features in here, like improved notification grouping, live notifications, a slew of protection features for people who run increased risk (think journalists or victims of abuse), and proper desktop-style windowing on tablets, which seems like the tentpole feature for now. The Material 3 Expressive design is not really here yet, though as that will come in subsequent Android 16 updates. The release for devices coincides with the release of the source code, which is no longer released as part of the development process, but dumped across the fence at release time. This means that those of us using a de-Googled Android ROM - I use GrapheneOS - will have to wait a bit longer than we're used to before getting the new version.

As part of its WWDC announcements, Apple has unveiled Containerization, which uses macOS' virtualisation framework to run Linux containers on Apple Silicon Macs. Containerization executes each Linux container inside of its own lightweight virtual machine. Clients can create dedicated IP addresses for every container to remove the need for individual port forwarding. Containers achieve sub-second start times using an optimized Linux kernel configuration and a minimal root filesystem with a lightweight init system. vminitd is a small init system, which is a subproject within Containerization. vminitd is spawned as the initial process inside of the virtual machine and provides a GRPC API over vsock. The API allows the runtime environment to be configured and containerized processes to be launched. vminitd provides I/O, signals, and events to the calling process when a process is ran. Containerization GitHub page Alongside this new tool, Apple also released container, which creates and runs OCI-compliant container images. Yes, both of these names are horribly generic and are definitely going to lead to confusion in online discussions and writing, but the tools themselves seem quite nice. People stuck on macOS who need to do Linux work can now easily get their work done on macOS - if you're okay with using Electron for developers, of course, which is what containers really are. Clearly, nobody can ignore Linux, not even Apple or Microsoft.

macOS Tahoe is the final software update that Intel-based Macs will get, as Apple works to phase them out following its transition to Apple silicon. During its Platforms State of the Union event, Apple said that Intel Macs won't get macOS 27, coming next year, though there could still be updates that add security fixes. Juli Clover at MacRumors Not particularly surprising, but definitely not great for someone who bought one of those ungodly expensive Intel Mac Pro only a few years ago - it wasn't taken off the shelves until 2023. That's a hard pill to swallow, and definitely something I do not think should be legal.

For years now - it feels more like decades, honestly - Apple has been trying a variety of approaches to make the iPad more friendly to power users, most notably by introducing, and subsequently abandoning, various multitasking models. After its most recent attempts - Stage Manager - fell on deaf ears, the company has thrown its hands up in the air and just implemented what we all wanted on the iPad anyway: a normal windowing environment. Apple today revealed an overhaul of iPad multitasking, introducing a completely new windowing system, a macOS-style Menu Bar, a pointer, and more. The centerpiece of the multitasking improvements is a new macOS-style windowing system. Apps still launch in full-screen by default, preserving the familiar iPad experience, but users can now resize apps into windows using a new grab handle. If an app was previously used in a windowed state, it will remember that layout and reopen the same way next time. Hartley Charlton at MacRumors The new window manager includes tiling features, Expose, support for multiple displays, and swiping twice on the home button will minimise all open windows. It's literally the macOS way of managing windows transplanted onto the iPad, with some small affordances for touch input. This is excellent news, and should make the multitasking features of the iPad, which, at this point, is as powerful as a MacBook, much more accessible and effortless than all those hidden gesture-based features from before. The amount of RAM in your iPad seems to determine how many active windows you can have open before the older ones get put to sleep, from four on the oldest iPad Pro models, to many more on the most recent models. Any windows above that limit will still be visible, but will just be a screenshot of their most recent state until you interact with them again. Any windows above a limit of twelve will be pushed to the recents screen instead. In addition, and almost just as important, iPadOS 26 also introduces proper background processes, allowing applications to actually keep running in the background instead of being put to sleep. Anyone who has ever done any serious work on an iPad that involves long processes like exporting a video will consider this a godsend. Now all we need is a proper terminal and Xcode and the iPad can be a real computer.

FreeBSD 14.3 has been released, an important point release for those of us using the FreeBSD 14.x branch. This release brings 802.11ac (Wi-Fi 5) support to many modern laptop wireless chips, OCI container images are now available in Docker and GitHub repositories, and a number of cornerstone packages have been updated to their latest versions.

If you ever wanted to know what it was like to be an engineer at Google during the early to late 2000s, here you go. Now even though Google is fundamentally a spyware advertising company (some 80% of its revenue is advertising; the proportion was even higher back then), we Engineers were kept carefully away from that reality, as much as meat eaters are kept away from videos of the meat industry: don't think about it, just enjoy your steak. If you think about it it will stop being enjoyable, so we just churned along, pretending to work for an engineering company rather than for a giant machine with the sole goal of manipulating people into buying cruft. The ads and business teams were on different floors, and we never talked to them. Elilla Even back then, Google knew full well that what they were doing and working towards was deeply problematic and ethically dubious, at best, and reading about how young, impressionable Google engineers at the time figured that out by themselves is kind of heartbreaking. In those days, Google tried really hard to cultivate an image of being different than Apple or Microsoft, a place where employees were treated better and had more freedom, working for a company trying to make the web a better place. Of course, none of that was actually true, but for a short while back then, a lot of people fell for it - yes, including you, even if you now say you didn't - and reading about the experiences from people on the inside at the time, it was never actually true.