fidzu : Operating Systems

Since we entered a new year, we also entered a new quarter, and that means a new quarterly report from the Hurd, the project that aims to, to this day, developer a kernel for the GNU operating system. Over the course of the fourth quarter of 2025, an important undertaking has been to port dhcpcd to Hurd, which will ultimately bring IPv6 support to Hurd. For now, the port only supports IPv4, only works on Ethernet, and is still generally quite limited when it comes to its functionality. It's a great start, though, and an amazing effort. Furthermore, Q4 2025 also saw improvements in symmetric multiprocessing support on x86, not exactly a small feat. There's a ton of work left to be done, but progress is being made and that's important considering today's processor landscape. There's also the usual load of fixes, smaller improvements, and changes all over the operating system, and the report makes it clear that Debian's recent announcement that APT will start requiring Rust is not a major issue for Hurd, as it already has a Rust port.

08 Jan 2026 9:15pm GMT

MenuetOS, the operating system written in x86-64 assembly, released version 1.58.00. Since the last time we talked about MenuetOS, the included X server has been improved, networking performance has been increased, there's now native versions of classic X utilities like XEyes, XCalc, and others, and more. There's also the usual smaller improvements and bug fixes.

08 Jan 2026 8:54pm GMT

There's so much shit going on in the world right now, and we can all use a breather. So, let's join Carl Svensson and look at some pretty Amiga Workbench screenshots. Combining my love for screenshots with the love for the Amiga line of computers, I've decided to present a small, curated selection of noteworthy Amiga Workbenches - Workbench being the name of the Amiga's desktop environment. ↫ Carl Svensson I love how configurable and flexible the Amiga Workbench is, and how this aspect of it has been embraced by the Amiga community. All of these screenshots demonstrate a sense of purpose, and clearly reflect the kind of things their users do with their Amigas. I think "Graphics Card Workbench #1 (1997)" speaks to me the most, striking a great balance between the blocky, pixelated "old" Amiga look, and the more modern late '90s/early '00s Amiga look. The icon set in that one also vaguely reminds me of BeOS, which is always a plus. That being said, all of them look great and are instantly recognisable as Amiga desktops, and make me wish I had a modern Amiga capable of running Amiga OS 4.

08 Jan 2026 3:43pm GMT

The solution the Flatpak team is looking into is to use virtualisation for the graphics driver, as the absolute last-resort option to keep things working when nothing else will. It's a complex and interesting solution to a complex and interesting problem.

08 Jan 2026 3:23pm GMT

Four years ago, I reviewed a truly fully open source desktop computer, from operating system down to firmware: the Raptor Blackbird, built entirely around IBM's POWER9 processor. The overall conclusion was that using was mostly an entirely boring experience, which was a very good thing - usually ideologically-fueled computers come with a ton of downsides and limitations for average users, but Raptor's POWER9 machines bucked this trend by presenting a bog-standard, run-of-the-mill desktop Linux experience, almost indistinguishable from using an x86 machine. Almost indistinguishable. The one thing that was missing from using desktop Linux on POWER9 was Firefox' JIT, which meant that many websites, especially more complex ones, would bring the browsing experience down to a crawl. One area where this affected me quite a bit was our own WordPress backend, which is effectively unusable on Firefox without its JIT. The only other option was to use Chromium, which was fully ported to POWER9 - but I don't like Chromium, and want to use Firefox to be able to share tabs, history, passwords, and so on. Since then, back in 2021, things have improved. The ongoing effort to port Firefox' JIT to POWER9, led by Cameron Kaiser, made a ton of progress, to the point where community Firefox builds with Kaiser's JIT integrated became available through a dedicated Fedora copr. Sadly, the last build is from four months ago, and covers Firefox 128.14.0-1, an old ESR release. Since I recently set up the other machine Raptor sent to me - a Talos II workstation with two POWER9 processors - I was curious what the state of the POWER9 JIT effort was, so I inquired on the related bug report for Firefox. Kaiser replied, and explained that due to a critical error with wasm against later versions of the JIT, as well as a change in his personal circumstances forcing him to work on this effort remotely - obviously not great for a client application like Firefox - there simply hasn't been much progress, until last week (what a coincidence!). Last week I took some time off work and dragged the JIT up to the current ESR. This compiles and links. However, although it passes the majority of the test suite, there are still too many serious failures to make it useable. I'm continuing work on this in whatever free time I actually have on my workstation. If I can restore test compliance in Baseline mode, this would suffice for a community third-party build like what Dan Horak generates now, since that is what is in 128. To get it in tree, however, I would also need to solve that critical wasm fault which manifested in the interim and fix the remaining gaps in the CodeGenerator to get it to a point of sufficient quality. ↫ Cameron Kaiser There are two main problems at the moment that make it harder than it needs to be to work on this effort. First, the state of debugging tools on ppc64le - to which POWER9 belongs - is apparently not great, requiring Kaiser to step through thousands of instructions manually using gdb just to fix the last bug he discovered. That's clearly deeply suboptimal, not fun, and not something somebody should spend their precious free time on. At this point in the discussion, Raptor's Timothy Pearson jumped in and noted that getting rr-debugger to work on POWER9 is something Raptor would be interested in, but it wouldn't be cheap: On the topic of the debugger (rr-debugger), while this isn't on our internal roadmap at the moment it is something that Raptor could do under a development contract. The main question is whether there is enough interest to make that viable; the work is significant so the cost would probably be in the mid to upper 5 figures range (USD), assuming no major roadblocks are discovered. When I was looking into it before I was fairly certain the PMU on POWER9 supports the overall structure of rr-debugger's methods, and that our load-store idioms are generally compatible. The former is what stops it working on most arm64 devices IIRC, and the latter is relevant mainly to non-POWER RISC architectures. ↫ Timothy Pearson Kaiser noted that while having rr-debugger available wouldn't be a magic bullet, it would make the whole process a lot easier. The second major issue is, of course, the same one as it always is for such niche efforts: a lack of manpower. According to Kaiser, there's enough interest and awareness in getting Firefox' JIT ported to POWER9, with the real problem being that there simply aren't a lot of people with enough knowledge of both Firefox' JIT and the modern ppc64le ISA. Understandably, Kaiser would like to avoid having to deal with people who are well-intentioned but don't fully grasp the complexity of the undertaking at hand. This is not exactly an easy effort, and it's honestly downright amazing how far along the project already is. Even if it's an older version, being able to run Firefox 128ESR on POWER9 with a working JIT makes such a huge difference to the overall desktop user experience, and I'm sure I speak for the entire POWER9 community when I say I'm incredibly grateful for it. Still, it would be amazing if we could find someone with just the right skillset to help Kaiser out, to be able to get the JIT stable enough again for community Firefox builds - and perhaps even look at what lies beyond: getting it upstreamed into Firefox as a whole. The odds of finding that person are slim - if you're into this sort of stuff, you're most likely already aware of the POWER9 JIT effort - but who knows, maybe shining some renewed light on this task will make a difference. If you happen to have the right skillset and appreciate the complexities involved in this effort, you might want to reach out.

07 Jan 2026 4:41pm GMT

About half a year ago, I wrote an article about persistent rumours I'd heard from Android ROM projects that Google was intending to discontinue the Android Open Source Project (AOSP). AOSP has been gutted by Google over the years, with the company moving more and more parts of the operating system into closed-source, non-AOSP components, like Google Play Services. While you can technically still run bare AOSP if you're really hardcore, it's simply unusable for 99% of smartphone users out there. Google quickly responded to these widespread rumours, stating that "AOSP is not going away", and a lot of people, clearly having learned nothing from human history, took this at face value and believed Google word-for-word. Since corporations can't be trusted and lying is their favourite activity, I drew a different conclusion at the time: 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. ↫ Thom Holwerda at OSNews Ever since the claim that "AOSP is not going away", Google has taken numerous steps to further tighten the grip it has on Android, much to the detriment of both the Android Open Source Project and the various ROM makers that depend on it. Device-specific source code for Pixel devices is no longer being released, Google dabbled with developer certification even for developers outside of Google Play, and Google significantly scaled back the release of security patches to AOSP. And now it's early 2026, and Google is about to take the next step in the slow killing of the Android Open Source Project. On the main page of the Android Open Source Project, there's now a new message: Effective in 2026, to align with our trunk stable development model and ensure platform stability for the ecosystem, we will publish source code to AOSP in Q2 and Q4. For building and contributing to AOSP, we recommend utilizing android-latest-release instead of aosp-main. The android-latest-release manifest branch will always reference the most recent release pushed to AOSP. This means that instead of four AOSP code releases every year, Google is now scaling back to just two every year. The gutting and eventual killing of AOSP has now reached the point where the open source nature of AOSP is effectively meaningless, and we're yet a few more big steps closer to what I outlined above: eventually, Google will distance itself from AOSP entirely, focusing all of its efforts on Pixel Android alone - without any code contributions to AOSP at all. If you still think "AOSP is not going away", you're delusional. OASP is already on life support, and with this latest move Google is firmly gripping the plug.

06 Jan 2026 10:39pm GMT

Since we moved to a new year, we also moved to a new month, and that means a new monthly report from Redox, the general purpose operating system written in Rust. The report obviously touches on the news we covered a few weeks ago that Redox now has the first tidbits of a modesetting driver for Intel hardware, but in addition to that, the project has also taken the first steps towards basic read-only APIs from Linux DRM, in order to use Linux graphics drivers. ARM64 now has dynamic linking support, POSIX compliance has been improved, and countless other improvements. Of course, there's also the usual massive list of bug fixes and minor changes to the kernel, relibc, drivers, and so on. I genuinely wish the Redox project another successful year. The team seems to have its head screwed on right, and is making considerable progress basically every month. I don't know what the end goal is, but the way things are looking right now, I wouldn't be surprised to see it come preinstalled on system76 laptops somewhere over the coming five years.

06 Jan 2026 9:16pm GMT

Happy New Year 2026! Once again, a lot has happened in Gentoo over the past months. New developers, more binary packages, GnuPG alternatives support, Gentoo for WSL, improved Rust bootstrap, better NGINX packaging, … As always here we're going to revisit all the exciting news from our favourite Linux distribution. ↫ Gentoo's 2025 retrospective We don't talk about Gentoo very often, and I consider that a good thing. Gentoo is just Gentoo, doing its thing, seemingly unaffected by the shifting sands of any community or world events. Gentoo will always just be Gentoo, and we're all better for it. The past year brought a ton of improvements to both Gentoo as a distribution and as a wider project and community. Because of Github's insistence to shove "AI" into everything, the project is currently moving to Codeberg instead, EAPI 9 has been approved and finalised, there are now weekly Gentoo images for WSL, the project welcomed several new developers, they've got a second build server, and so much more. Sadly, the project did have to drop the hppa and sparc architectures down a peg due to a lack of hardware, which hurts my soul a tiny bit but is entirely understandable, of course. Gentoo is doing great, and I doubt it'll ever not be doing great. Gentoo is just Gentoo.

06 Jan 2026 8:45pm GMT

The new version brings a ton of new enhancements and fixes to all 3 supported platforms, with Steam running not only on Arm64, but also on RiSC-V and on Loongarch! And this is the Linux version of Steam, not the Windows one (but the Windows one works too if you really prefer that one). While Box32 (used to run Steam) is still experimental and unstable, stability did improve. Still, expect some crashes when downloading things with steam. And it's not all, Battle.net is also getting stable, and some games are working too. Not all unfortunately, and your success might depend on your geographical region, as program versions might differ. At least, you can try it on ARM64 & Loongarch. It's still to be tested on RiSC-V. ↫ Box64 0.4.0 release announcement These are some major improvements to Box64, and impressive ones at that.

06 Jan 2026 8:36pm GMT

Ever noticed your computer acting sluggish or warning you about low storage? Temporary files could be the sneaky culprit. Windows creates these files while installing apps, loading web pages, or running updates. Left unchecked, they pile up and hog valuable space. Luckily, clearing them out is easier than cleaning your kitchen junk drawer. Let's explore Storage Sense, Disk Cleanup, manual deletion, and a few bonus performance tips to keep your PC running like new. ↫ Microsoft Windows Learning Center You may think this is one of those junk SEO articles generated by "AI" to trap Google searches, but no, this is published by Microsoft on Microsoft's website. Instead of fixing the long-standing and well-known problems around Windows being absolutely terrible at keeping itself clean and functional over longer periods of time, the company figured it'd be a better idea to just keep shoving that responsibility unto users instead. None of the tools mentioned in this article should need to be run or set up by users manually. A computer is supposed to make life less tedious, not more so, and I already have enough cleaning up and laundry to do out here in the real world, and I don't want to be bothered with it on my computer. Why on earth am I supposed to manually remove unnecessary Windows Update files? Why did Adobe installers leave about 15GB of old installers in some directory inside C:/Windows on my wife's computer that I had to remove using a third party tool? In what universe is this okay? Sometimes I wonder how much of our collective time is wasted just by dealing with Windows on a day-to-day basis in our society. Imagine the time we could reclaim and spend on our loved ones, families, and hobbies instead, if only Windows was developed by people with even a modicum of competency.

06 Jan 2026 3:39pm GMT

The way the histories of CP/M, DOS, Microsoft, and the 8086 intertwine would be worthy of an amazing film if it wasn't for the fact it would be very hard to make it interesting screen material. Few OEMs were asking for an 8086 version of CP/M. One that did was SCP - the same company that helped Microsoft design SoftCard. They needed a disk operating system for their 8086 board released in November 1979. In April 1980, after CP/M-86 was still nowhere to be seen, they lost patience and asked their young engineer Tim Paterson to develop a "quick and dirty" OS similar to CP/M that would hopefully boost the sales of their board. That little operating system, officially named 86-DOS, was eventually purchased by Microsoft and renamed MS-DOS. Paterson has stated on multiple occasions that he would never have begun developing it had CP/M‑86 been available on time. ↫ Nemanja Trifunovic There's a ton more in this article about CP/M-86 and its gestation period, but this tangled little knot of coincidences always entertains me. It really could've been CP/M, and it really could've not been Microsoft. This industry is filled to the brim with interesting what-if stories that we barely regard as a worthy footnote, but few are as fascinating as what the world would've looked like had CP/M won out over DOS. The entire world would've been drastically different, and while nobody can say with a straight face it would be a better world, we'd at least not have the spectres of MS-DOS haunting system administrators, developers, and users the world over. Of course, they'd be haunted by different spectres, but still.

05 Jan 2026 11:38pm GMT

We've talked about just how bad Apple's regular icons have become, but what about the various icons Apple now plasters all over its menus, buttons, and dialogs? They've gotten so, so much worse. In my opinion, Apple took on an impossible task: to add an icon to every menu item. There are just not enough good metaphors to do something like that. But even if there were, the premise itself is questionable: if everything has an icon, it doesn't mean users will find what they are looking for faster. And even if the premise was solid, I still wish I could say: they did the best they could, given the goal. But that's not true either: they did a poor job consistently applying the metaphors and designing the icons themselves. ↫ Nikita Prokopov The number of detailed examples in this article are heartbreaking. I just don't understand how anyone can look at even three of these and not immediately ring the alarm bells, slam the emergency brake, rush to Tim Cook's office. It further illustrates that no, the problem at Apple is not just one man, whether he be Jonathan Ive or Alan Dye or the next unfortunate bloke on the chopping block, but the institution as a whole. I have a feeling the kind of people who care about proper UI design have all left Apple by now. The institutional knowledge is gone. And that kind of knowledge is extremely difficult to get back.

05 Jan 2026 11:17pm GMT

CheriBSD is a Capability Enabled, Unix-like Operating System that extends FreeBSD to take advantage of Capability Hardware on Arm's Morello and CHERI-RISC-V platforms. CheriBSD implements memory protection and software compartmentalization features, and is developed by SRI International and the University of Cambridge. ↫ CheriBSD website This obviously raises the question - what exactly is CHERI? The FreeBSD Foundation has an article about this from 2023 providing more details. CHERI extends existing architectures (Armv8-A, MIPS64 (retired), RISC-V, and x86_64 (in development)) with a new hardware type, the CHERI capability. In CHERI systems, all access to memory is via CHERI capabilities either explicitly via new instructions or implicitly via a Default Data Capability (DDC) and Program Counter Capability (PCC) used by instructions with integer arguments. Capabilities grant access to specific ranges of (virtual, or occasionally, physical) memory via a base and length, and can further restrict access with permissions, which are compressed into a 128-bit representation (64-bits for the address and 64-bits for the metadata). In memory and in registers, capabilities are protected by tags that are cleared when the capability data is modified by a non-capability instruction or if a capability instruction would increase the access the capability grants. Tags are stored separately from data and cannot be manipulated directly. ↫ Brooks Davis CheriBSD brings this capability to anyone with compatible hardware, providing access to about 10000 pre-built memory-safe packages alongside more than 260000 pre-built memory-unsafe packages, as well as fully memory-safe versions of the KDE desktop, bhyve, and a ton of others. You can use both types of packages alongside one another, there's a nice installer, and it basically seems like you're using regular FreeBSD, just with additional complications, the biggest of which is, of course, the limited hardware support. I have a feeling that if you're the kind of person to own CHERI-enabled hardware, you're most likely already aware of CheriBSD. Still, if this is something you're looking for, be aware that you're going ot need special hardware. It's also important to note that DTrace won't work on CheriBSD, and most optional modules, like firewall systems, don't work either.

05 Jan 2026 10:53pm GMT

Up until now, it's always remained possible to activate Windows offline, by calling a phone number, going through a lengthy phase of entering digits on your phone dialpad, and carefully listening to and entering a string of numbers on the device you're trying to activate. For a while, even, this was, as far as I can tell, one of the easiest ways to fix activation issues caused by replacing one component too many, causing Windows activation to think you had a new machine. Phone activation was always remarkably more lenient and forgiving than online activation. Well, as part of Microsoft's crusade to make Windows progressively more shit, it seems phone activation is going away. However, that seems to no longer work on Windows 11 or 10 or Windows 7 either, as another user Ben Kleinberg has documented on his YouTube channel. Now when trying to activate the OS by attempting to call the phone number for Microsoft Product Activation, an automated voice response says the following: "Support for product activation has moved online. For the fastest and most convenient way to activate your product, please visit our online product activation portal at aka.ms/aoh" ↫ Sayan Sen at Neowin They're going after your local, non-online account, they're going after offline activation - what's next in line on the chopping block? Are they going to actively start blocking the various debloat tools that make Windows 11 at least slightly less of a block of concrete chained around your neck? Please switch to a real operating system.

05 Jan 2026 12:43pm GMT

Desktop Classic System is an operating system based on Debian and a customized version of the MATE Desktop Environment that hearkens back to, but is not a direct copy of, the classic Mac OS. DCS seeks to provide and sometimes even improve upon the conceptual simplicity offered by the old Macintosh. ↫ Desktop Classic System website I'm usually not particularly interested in reporting on random Linux distributions, but any one of them that defaults to a proper spatial file manager is one that I will highlight. I'm not entirely sure if this is just a supported feature of MATE's file manager, or something more custom - there are some patches to Caja here, as mentioned - but spatial file managers are a dying breed and that's a shame. They're hard to implement and even harder to get right, which is probably why few people take on the challenge. Other than that, DCS isn't particularly revolutionary or special, but I'd love for more Linux distributions to look back at what we've lost, and see if we can bring those things back.

04 Jan 2026 11:12am GMT

KDE developer Herz published a detailed look at the immense amount of work they've done cleaning up the developer onboarding documentation for KDE. All that just to say that I'm finally content with the state of beginner onboarding docs in our KDE Developer Platform. That is to say, all the beginner docs fixes I wanted to add to Develop are either already there or have merge requests ready or almost ready. ↫ Herz at rabbitictranslator.com Judging by the article, KDE's developer documentation really were in need of major work, and it's great to see that thankless task being done. One of the areas where KDE lags behind GNOME is that the latter has a more vibrant application ecosystem, with tons of great GNOME applications under active development. Now, I'm not saying it's the state of KDE's documentation is the sole reason for this, but I'm sure it wasn't helping either. Improving documentation is not a particularly glamorous task, but it's vitally important nonetheless.

04 Jan 2026 10:47am GMT