OSnews

There's cursed computing, and then there's cursed computing. It turns out that you can render GNOME's windows with the compositor from Windows 7, dwm.exe. Yes. tl;dr of how this clusterfuck works: this is effectively just x11 forwarding an x server from windows to linux. the fun part is a) making gnome run with an already existing window manager (namely dwm.exe lol), b) making gnome run over x11 forwarding (it is Not a fan, last time it tried running gnome on windows this is what broke it and made it quit trying), and c) actually ripping out parts of the gnome compositor again to make dwm instead of gnome render window decorations to achieve aero gnome -49016 at Mastodon This is already one of the most cursed things I've ever seen, but then things got so much worse. How about Windows 7's dwm.exe, but composited by GNOME? I need an adult.

Virtualisation is a lot older than you might think, with (one of?) the first implementation(s) being IBM's VM/CMS, the line of operating systems that would grow to include things like System/370, System/390, all the way up until IBM/Z, which is still being developed and sold today; only recently IBM released the IBM z17 and z/OS 3.2, after all. The VM series of operating systems is designed exclusively for mainframes, and works by giving every user their own dedicated virtual machine running on top of the Control Program, the hypervisor. Inside this virtual machine the user can run a wide variety of operating systems, from the simple, single-user classics like IBM's Conversational Monitor System, to more complex systems like Linux or AIX. Early versions of VM were released as open source and are now in the public domain, and enthusiasts have continued to build upon it and expand it, with the latest incarnations being the VM/370 Community Edition releases. They contain the Control Program and Conversational Monitor System, augmented by various fixes, improvements, and other additions. You can run VM in an emulator like Hercules, and continue on from there - but what, exactly, can you do with it? That's where Fun things to do with your VM/370 machine comes in. This article will give you an introduction to the system, and a number of first and later steps you can take while exploring this probably alien environment. If you've always dreamt of using an early IBM mainframe, this is probably the easiest way to do so, because buying one is a really, really bad idea.

ChaosBSD is a fork of FreeBSD. It exists because upstream cannot, and should not, accept broken drivers, half-working hardware, vendor trash, or speculative hacks. We can. ChaosBSD GitHub page This is an excellent approach to testing drivers that simply aren't even remotely ready to be included in FreeBSD-proper. It should be obvious that this is not, in any way, meant to be used as a production operating system, as it will contain things that are broken and incomplete on purpose. The name's also pretty great.

This is a book intended to teach someone the Java language, from scratch. You will find that the content makes heavy use of recently released and, for the moment, preview features. This is intentional as much of the topic ordering doesn't work without at least Java 21. Modern Java GitHub page Some light reading for the weekend. This sure is one hell of a detailed book.

Since Wayland is still quite new to a lot of people, it's often difficult to figure out which features the Wayland compositor you're using actually supports. While the Wayland Explorer is a great way to browse through the various protocols and their status in various compositors, there's now an easier way. The Wayland protocols table makes it very easy to see what your favourite compositor supports, which compositors support the protocol you really want supported before leaving X11 behind, and much more. Roughly speaking, there's a set of stable core Wayland protocols, as well as a slew of unstable core Wayland protocols that are still in development, but may already be supported by various compositors. On top of that, compositors themselves also have a ton of protocols they themselves introduced and support, but which aren't supported by anything else - yet, as they may be picked up by other compositors and eventually become part of Wayland's core protocols. Keeping tabs on specific protocols and their support status is mostly only interesting for developers and people with very specific needs, since mature compositors provide a complete set of features most users never have to worry about. Still, that doesn't mean there aren't really cool features cooking, nor does it mean that one specific accessibility-related protocol isn't incredibly important to keep track of. These websites provide an easy way to do so.

Excellent news for OpenBSD users who are tied to macOS: you can now run OpenBSD using Apple's Hypervisor. Following a recent series of commits by Helg Bredow and Stefan Fritsch, OpenBSD/arm64 now works as a guest operating system under the Apple Hypervisor. Peter N. M. Hansteen at the OpenBSD Journal If you have an M1 or M2 Mac and want to get rid of macOS entirely, OpenBSD can be run on those machines natively, too.

Speaking of NixOS' use of 9P, what if you want to, for whatever inexplicable reason, use macOS, but make it immutable? Immutable Linux distributions are getting a lot of attention lately, and similar concepts are used by Android and iOS, so it makes sense for people stuck on macOS to want similar functionality. Apple doesn't offer anything to make this happen, but of course, there's always Nix. And I literally do mean always. Only try out Nix if you're willing to first be sucked into a pit of despair and madness before coming out enlightened on the other end - I managed to only narrowly avoid this very thing happening to me last year, so be advised. Nix is no laughing matter. Anyway, yes, you can use Nix to make macOS immutable. But managing a good working environment on macOS has long been a game of hope for the best." We've all been there: a curl | sh here, a manual brew install there, and six months later, you're staring at a broken PATH and a Python environment that seems to have developed its own consciousness. I've spent a lot of time recently moving my entire workflow into a declarative system using nix. From my zsh setup to my odin toolchain, here is why the transition from the imperative world of Homebrew to the immutable world of nix-darwin has been both a revelation and a fight. Carette Antonin Of course it's been a fight - it's Nix, after all - but it's quite impressive and awesome that Nix can be used in this way. I would rather discover what electricity from light sockets tastes like than descend into this particular flavour of Nix madness, but if you're really sick of macOS being a pile of trash for - among a lot of other things - homebrew and similar bolted-on systems held together by duct tape and spit, this might be a solution for you.

If you're only even remotely aware of the operating system Plan 9, you'll most likely know that it takes the UNIX concept of everything is a file" to the absolute extreme. In order to make sure all these files - and thus the components of Plan 9 - can properly communicate with one another, there's 9P, or the Plan 9 Filesystem Protocol. Several Plan 9 applications are 9P file servers, for instance, and even things like windows are files. It's a lot more complicated than this, of course, but that's not relevant right now. Since Plan 9 wasn't exactly a smashing success that took the operating system world by storm, you might not be aware that 9P is actually implemented in a few odd places. My favourite is how Microsoft turned to 9P for a crucial feature of its Windows Subsystem for Linux: accessing files inside a Linux VM running on Windows. To put it briefly: a 9P protocol file server facilitates file related requests, with Windows acting as the client. We've modified the WSL init daemon to initiate a 9P server. This server contains protocols that support Linux metadata, including permissions. A Windows service and driver that act as the client and talks to the 9P server (which is running inside of a WSL instance). Client and server communicate over AF_UNIX sockets, since WSL allows interop between a Windows application and a Linux application using AF_UNIX as described in this post. Craig Loewen at Microsoft's Dev Blogs This implementation is still around today, so if you're using Windows Subsystem for Linux, you're using a little bit of Plan 9 as glue to make it all come together. Similarly, if you're using QEMU and sharing files between the host and a VM through the VirtFS driver, you're also using 9P. Both NixOS and GNU Guix use 9P when they build themselves inside a virtual machine, too, and there's probably a few other places where you can run into 9P. I don't know, I thought this was interesting.

Are you a normal person and thus sick of all the nonsensical, non-browser stuff browser makers keep adding to your browser, but for whatever reason you don't want to or cannot switch to one of the forks of your browser of choice? Just the Browser helps you remove AI features, telemetry data reporting, sponsored content, product integrations, and other annoyances from desktop web browsers. The goal is to give you just the browser" and nothing else, using hidden settings in web browsers intended for companies and other organizations. This project includes configuration files for popular web browsers, documentation for installing and modifying them, and easy installation scripts. Everything is open-source on GitHub. Just The Browser's website It comes in the form of scripts for Windows, Linux, or macOS, and can be used for Google Chrome, Microsoft Edge, and Mozilla Firefox. It's all open source so you can check the scripts for yourself, but there are also manual guides for each browser if you're not too keen on running an unknown script. The changes won't be erased by updates, unless the specific settings and configuration flags used are actually removed or altered by the browser makers. That's all there's to it - a very straightforward tool.

Despite December being the holiday month, Haiku's developers got a lot of things done. A welcome addition for those of us who regularly install Haiku on EFI systems is a tool in the installer that will copy the EFI loader to the EFI system partition, so fewer manual steps are needed on EFI systems. Support for touchpads from Elantech has also been improved, and the FreeBSD driver compatibility layer and all of its Ethernet and WiFi drivers have been updated to match the recent FreeBSD 15 release. Of course, there's also the usual long list of smaller fixes, improvements, and changes. As for a new release milestone, beta 6 seems to be on the way. Not quite. There has been some discussion on the mailing list as the ticket list gets smaller, but there's still at least some more regressions that need to be fixed. But it looks like we'll be starting the release process in the next month or two, most likely... Haiku's December 2025 activity report To be fair, though, Haiku's nightly releases are more than able to serve their duties, and waiting for a specific release if you're interested in trying out Haiku is really not needed. Just grab the latest nightly, follow the installation instructions, and you're good to go. The operating system supports updating itself, so you'll most likely won't need to reinstall nightlies all the time.

It's no secret that the Windows 95 installer uses a heavily stripped-down Windows 3.10 runtime, but what can you actually do with it? How far can you take this runtime? Can it run Photoshop? It is a long-standing tradition for Microsoft to use a runtime copy of Windows as a part of Windows Setup. But the copy is so stripped-down, it cannot run anything but the setup program (winsetup.bin). OR IS IT? A mini-challenge for myself: create a semi-working desktop only based on runtime Windows 3.10 shipped with Windows 95 installer but not using any other Microsoft products. Nina Kalinina A crucial limitation here is that Kalinina is not allowing herself to use any additional Microsoft products, so the easy route of just copying missing DLLs and other files from a Windows 95 disk or whatever is not available to her; she has to source any needed files from other sources. This may seem impossible, but during those days, tons of Windows (and even DOS) applications would ship with various Microsoft DLLs included, so there are definitely places to get Windows DLLs that aren't coming directly from Microsoft. As an example, since there's no shell of any kind included in the stripped-down Windows 3.10 runtime, Kalinina tried Calmira and WinBar, which won't work without a few DLLs. Where to get them if you can't get them straight from Microsoft? Well, it turns out programs compiled with later version of MSVC would include several of these needed DLLs, and AutoCad R12 was one of them. WinBar would now start and work, and while Calmira would install, it didn't work because it needs the Windows Multimedia Subsystem, which don't seem to be included in anything non-Microsoft. It turns out you can take this approach remarkably far. Things like Calculator and Notepad will work, but Pain or Paintbrush will not. Larger, more complex applications work too - Photoshop 2.5.1 works, as does Netscape, but without any networking stack, it's a little bit moot. Even Calmira XP eventually runs, as some needed DLLs are found inside Mom For Windows 2.0", at which point the installation starts to look and feel a lot like a regular Windows 3.x installation, minus things like settings panels and a bunch of default applications. Is this useful? Probably not, but who cares - it's an awesome trick, and that alone makes it a worthwhile effort.

They're easily overlooked between all the Chrome and Safari violence, but there are still text-based web browsers, and people still use them. How do they handle the latest HTML features? While CSS is the star of the show when it comes to new features, HTML ain't stale either. If we put the long-awaited styleable selects and Apple's take on toggle switches aside, there's a lot readily available cross-browser. But here's the thing: Whenever we say cross-browser, we usually look at the big ones, never at text-based browsers. So in this article I wanna shed some light on how they handle the following recent additions. Matthias Zochling Text-based web browsers work best with regular HTML, as things like CSS and JavaScript won't work. Despite the new features highlighted in the article being HTML, however, text-based browser have a hard time dealing with them, and it's likely that as more and more modern features get added to HTML, text-based browsers are going to have an increasingly harder time dealing with the web. At least OSNews seems to render decently usable on text-based web browsers, but ideal it is not. I don't really have the skills to fix any issues on that front, but I can note that I'm working on a extremely basic, HTML-only version of OSNews generated from our RSS feed, hosted on some very unique retro hardware. I can't guarantee it'll become available - I'm weary about hosting something from home using unique hardware and outdated software - but if it does, y'all will know about it, of course.

The PDP-10 family of computers (under different names) was manufactured by Digital Equipment Corporation between 1964 and 1983. Designed for time-sharing, batch and real-time systems, these computers were popular with universities, scientific companies and time-sharing bureaux. Several operating systems were available, some from DEC and some built by its users. It had a large influence on operating system design, artificial intelligence (especially at MIT and Stanford), programming languages (LISP, ML), applications (TeX, Emacs), online communication (ARPANET, Compuserve), games (Advent, Zork) and even helped development of Microsoft's first version of BASIC. Rupert Lane The importance, impact, and legacy of the PDP series of computers cannot be understated, running like a red thread through the early days and development of several important and crucial technologies. Lane is going to cover a number of the operating systems created for the PDP-10, so if you're interested - keep a bookmark.

Are you an author writing HTML? Just so we're clear: Not XHTML. HTML. Without the X. If you are, repeat after me, because apparently this bears repeating (after the title): You are not required to close your <p>, <li>, <img>, or <br> tags in HTML. Daniel Tan Back when I still had to write OSNews' stories in plain HTML - yes, that's what we did for a very long time - I always properly closed my tags. I did so because I thought you had to, but also because I think it looks nicer, adds a ton of clarity, and makes it easier to go back later and make any possible changes or fix errors. It definitely added to the workload, which was especially annoying when dealing with really long, detailed articles, but the end result was worth it. I haven't had to write in plain HTML for ages now, since OSNews switched to WordPress and thus uses a proper WYSIWYG editor, so I haven't thought about closing HTML tags in a long time - until I stumbled upon this article. I vaguely remember I would fix" other people's HTML in our backend by adding closing tags, and now I feel a little bit silly for doing so since apparently it wasn't technically necessary at all. Luckily, it's also not wrong to close your tags, and I stick by my readability arguments. Sometimes it's easy to forget just how old HTML has become, and how mangled it's become over the years.

We all knew this was going to happen, so let's just get it over with. Microsoft is testing a new feature that integrates Copilot into the File Explorer, but it's not going to be another Ask Copilot' button in the right-click menu. This time, Copilot will live inside File Explorer, likely in a sidebar or Details/Preview-pane-like interface, according to new references in Windows 11 preview builds. Mayank Parmar at Windows Latest What am I even supposed to say at this point? Who wants this? Why utterly destroy what little reputation and goodwill Windows has left? Has the hype bubble become this clouded and intoxicating? Even system administrators who want to turn off Copilot in their organisations or device fleets in an official, supported way are getting punched in the face by Microsoft. The company rolled out a new Group Policy to disable Copilot, but it's such a useless mess it might as well not be there at all. This essentially means that IT admins will only be able to uninstall the Copilot app for customers where their device has both Copilot apps installed by either a clean install or by the IT team itself, as long as the Copilot app has not been opened in a month. So, even if you accidentally open the Copilot app for a second because it's there in your Windows taskbar, the Copilot app won't be uninstalled. Usama Jawad at Neowin You shouldn't be using Windows.

Posh, GNOME's mobile shell, published a look back on the project's 2025. The Phosh developers focus from day one was to make devices running Phosh daily drivable without having to resort to any proprietary OSes as a fallback. This year showed improvements in some important areas people rely on like cell broadcasts and emergency calls, further improving usability and starting some ground work we'll need for some upcoming features. Phosh developers In 2025, Posh gained support for cell broadcasts - like the emergency messages regarding storms, or alerts about missing persons, that sort of stuff - which is a pretty important feature in this day and age. Posh also improved its support for per-source audio volumes and one source of audio muting another, its on-screen keyboard, its compositor, and much more. Of course, the main problem for shells like Phosh is hardware support, which is handled by the underlying operating system, like PostmarketOS. These Linux mobile operating systems are fighting an uphill battle when it comes to hardware support, and while Android application support can fill some of the application shortcomings, you're going to be making pretty significant concessions by switching to mobile Linux at the moment. When even Android ROMs not sanctioned by Google are having issues with banking applications or government ID stuff, using mobile Linux will be even more of a problem. None of this is the fault of any of the people dedicating their free time to things like Phosh or PostmarketOS, of course - it's just a sad reality of a market we once again just gave up to a few megacorporations, with our governments too cowardly to stand up and fix this issue.

Budgie has fallen a bit by the wayside in recent years, but it's still in development and making steady progress. The project's just released Budgie 10.10, the final release in the 10.x series which also marks the end of the transition to Wayland. Budgie 10.10 is a brand new release series for Budgie Desktop, marking our first release to migrate Budgie from X11 to Wayland. This release series brings to a close just over a decade of Budgie 10 development; we are formally putting Budgie 10 into maintenance mode to focus our efforts on Budgie 11. Joshua Strobl Budgie is taking a very interesting approach for its move to Wayland; instead of writing every single component of their desktop environment from scratch or porting their X11 tools, the project opted to reuse and implement a ton of established, well-tested, and popular Wayland tools like swaybg, swayidle, labwc, and so on. This obviously saves on development time, but also ensures the transition to Wayland is relatively smooth. Things like the panel, applets, the Budgie Control Center, and so on, have been updated or rewritten. There's also some new features, as well as a ton of bug fixes and smaller improvements. As noted, this release marks the end of the road for the 10.x series, with development now shifting to Budgie 11. Upcoming releases of major distributions will have Budgie 10.10 in their repositories.

OpenBSD on a Sharp Zaurus Linux-based PDA from 2005? Of course, why not? Installing OpenBSD was easy. The instructions in INSTALL.zaurus are pretty straightforward. My 5.6 install was smooth. Installing sets took ~10-15 minutes. The Microdrive is really slow. I'll replace it with a CF card soon, which should be slightly faster (and more reliable). goldfish Of course, it includes a working X desktop, which is neat and makes the device a lot more useful. I have a slightly older Zaurus PDA, and this post has made me interested in doing something similar to it.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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/M86 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.

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.

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.

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.

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.

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.

It shouldn't be surprising that the HP-UX FAQ eventually grew an entry for how can I make a 712 run headless". It was possible, and to do it you had to change the firmware console" path. The 712 firmware would not allow you to do this, to keep you locked to a keyboard and frame buffer console, but some of the HP-UX standalone tools could be used to change this without the firmware getting in the way, so the FAQ recipe was roughly abort the boot sequence, at the BOOT_ADMIN> prompt, do not start the HP-UX kernel but some diagnostic tool, and then at the tools prompt, type a magic sequence without any mistake or you'll be very, very, very sorry". There was no exaggeration in these words: the magic sequence is conspath 2/0/4.0x283, which is everything but intuitive and easy to remember. Miod Vallat What a great story.

IceWM, the venerable X11 window manager, has released a new version, bumping the version number to 4.0.0. This release brings a big update to the alt+tab feature. The Alt+Tab window switcher can now handle large numbers of application windows in both horizontal and in vertical mode. Type the first letter of an application class name in Alt+Tab, to select the next instance window of that application class. Select an application by pressing one of the number keys. Select an application by mouse in Alt+Tab in horizontal mode. Support navigating the quick switch with all navigation keys. Press the menu button on Alt+Tab to open the system menu. QuickSwitchPreview is a new mode to preview applications. These previews are updated while the quick switch is active. IceWM 4.0 release notes On top of this major set of improvements to alt+tab, there's the usual list of bug fixes and small changes, as well as a bunch if updated translations.

The new year isn't even a day old, and Haiku developer X512 dropped something major in Haiku users' laps: the first alpha version of an accelerated NVIDIA graphics drivers for Haiku. Supporting at least NVIDIA Turing and Ampere GPUs, it's very much in alpha state, but does allow for proper GPU acceleration, with the code surely making its way to Haiku builds in the near future. Don't expect a flawless experience - this is alpha software - but even then, this is a major milestone for Haiku.

It's 31 December 2025 today, the last day of the year, but it also happens to mark the end of support for the last and final version of one of my favourite operating systems: HP-UX. Today is the day HPE puts the final nail in the coffin of their long-running UNIX operating system, marking the end of another vestige of the heyday of the commercial UNIX variants, a reign ended by cheap x86 hardware and the increasing popularisation of Linux. HP-UX' versioning is a bit of a convoluted mess for those not in the know, but the versions that matter are all part of the HP-UX 11i family. HP-UX 11i v1 and v2 (also known as 11.11 and 11.23, respectively) have been out of support for exactly a decade now, while HP-UX 11i v3 (also known as 11.31) is the version whose support ends today. To further complicate matters, like 11i v2, HP-UX 11i v3 supports two hardware platforms: HP 9000 (PA-RISC) and HP Integrity (Intel Itanium). Support for the HP-UX 11i v3 variant for HP 9000 ended exactly four years ago, and today marks the end of support for HP-UX 11i v3 for HP Integrity. And that's all she wrote. I have two HP-UX 11i v1 PA-RISC workstations, one of them being my pride and joy: an HP c8000, the last and fastest PA-RISC workstation HP ever made, back in 2005. It's a behemoth of a machine with two dual-core PA-8900 processors running at 1Ghz, 8 GB of RAM, a FireGL X3 graphics card, and a few other fun upgrades like an internal LTO3 tape drive that I use for keeping a bootable recovery backup of the entire system. It runs HP-UX 11i v1, fully updated and patched as best one can do considering how many patches have either vanished from the web or have never leaked" from HPE (most patches from 2009 onwards are not available anywhere without an expensive enterprise support contract). The various versions of HP-UX 11i come with a variety operating environments" you can choose from, depending on the role your installation is supposed to fulfill. In the case of my c8000, it's running the Technical Computing Operating Environment, which is the OE intended for workstations. HP-UX 11i v1 was the last PA-RISC version of the operating system to officially support workstations, with 11i v2 only supporting Itanium workstations. There are some rumblings online that 11i v2 will still work just fine on PA-RISC workstations, but I have not yet tried this out. My c8000 also has a ton of other random software on it, of course, and only yesterday I discovered that the most recent release of sudo configures, compiles, and installs from source just fine on it. Sadly, a ton of other modern open source code does not run on it, considering the slightly outdated toolchain on HP-UX and few people willing and/or able to add special workarounds for such an obscure platform. Over the past few years, I've been trying to get into contact with HPE about the state of HP-UX' patches, software, and drivers, which are slowly but surely disappearing from the web. A decent chunk is archived on various websites, but a lot of it isn't, which is a real shame. Most patches from 2009 onwards are unavailable, various software packages and programs for HP-UX are lost to time, HP-UX installation discs and ISOs later than 2006-2009 are not available anywhere, and everything that is available is only available via non-sanctioned means, if you know what I mean. Sadly, I never managed to get into contact with anyone at HPE, and my concerns about HP-UX preservation seem to have fallen on deaf ears. With the end-of-life date now here, I'm deeply concerned even more will go missing, and the odds of making the already missing stuff available are only decreasing. I've come to accept that very few people seem to hold any love for or special attachment to HP-UX, and that very few people care as much about its preservation as I do. HP-UX doesn't carry the movie star status of IRIX, nor the benefits of being available as both open source and on commodity hardware as Solaris, so far fewer people have any experience with it or have developed a fondness for it. HP-UX didn't star in a Steven Spielberg blockbuster, it didn't leave behind influential technologies like ZFS. Despite being supported up until today, it's mostly forgotten - and not even HPE itself seems to care. And that makes me sad. When you raise your glasses tonight to mark the end of 2025 and welcome the new year, spare a thought for the UNIX everyone forgot still exists. I know I will.

I'd just like to interject for a moment. What you're refering to as Linux, is in fact, Win32/Linux, or as I've recently taken to calling it, loss32 Win32 plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning system made useful by WINE, the ReactOS userland, and other vital system components comprising a full OS as defined by Microsoft. The loss32 homepage Joking introduction aside, this is exactly what you think it is: a Linux kernel with the Windows user interface running on top through Wine. I'm sure quite a few of use mused about this very concept at some point in time, but hikari_no_yume went a step further and created this working concept. It's rough around the edges and needs a ton of work, but I do think the idea is sound and could offer real benefits for certain types of users. It's definitely a more realistic idea than ReactOS, a project that's perpetually chasing the dragon but never coming even close to catching it. Not having to recreate the entire Windows NT kernel, drivers, and subsystems, and using Linux instead, is simply a more realistic approach that could bring results within our lifetimes. The added benefit here is that this could still run Linux applications, too, of course. hikari_no_yume is looking for help with the project, and I hope they find it. This is a great idea, with an absolutely amazing name, too.

Nina Kalinina has been on an absolute roll lately, diving deep into VisiOn, uncovering Bellcore MGR, installing Linux on a PC-98 machine, and much more. This time, she's ported Windows 2 to run on a machine it was never supposed to run on. I bought my first Apricot PC about three years ago, when I realised I wanted an 8086-based computer. At the time, I knew nothing about it and simply bought it because it looked rad and the price was low. I had no idea that it was not IBM PC-compatible, and that there were very few programs available for it. I have been on a quest to get a modern-ish word processor and spreadsheet program for it ever since. Which eventually made me port" Windows 2 on it. In this post, I will tell you the story of this port. Nina Kalinina To get Windows 2 working on the Apricot, Kalinina had to create basic video, keyboard, and mouse drivers, allowing Windows 2 to boot into text mode. I wasn't aware of this, but Windows 2 in text mode is funky: it's rendering all the text you would see in a full Windows 2 user interface, just without any of the user interface elements. Further developing the video driver from scratch turned out to be too big of an undertaking for now, so she opted to extract the video driver from Windows 1 instead - which required a whole other unique approach. The keyboard and mouse drivers were extracted from Windows 1 in the same way. The end result is a fully working copy of Windows 2, including things like Word and Excel, which was the original goal in the first place. There aren't many people around doing stuff like this, and it's great to see such very peculiar, unique itches being scratched. Even if this is only relevant for exactly one person, it's still been worth it.

I knew digital cameras and phones had to do a lot of processing and other types of magic to output anything human eyes can work with, but I had no idea just how much. This is wild.

There's been endless talk online about just how bad Apple's graphical user interface design has become over the years, culminating in the introduction of Liquid Glass across all of the company's operating systems this year. Despite all the gnawing of teeth and scathing think pieces before the final rollout, it seems the average Apple user simply doesn't care as much about GUI design as Apple bloggers thought they did, as there hasn't been any uproar or stories in local media about how you should hold off on updating your iPhone. The examples of just how bad Apple's GUI design has become keep on coming, though. This time it's Howard Oakley showing once again how baffling the macOS UI is these days. If someone had told me 12 months ago what was going to happen this past year, I wouldn't have believed them. Skipping swiftly past all the political, economic and social turmoil, I come to the interface changes brought in macOS Tahoe with Liquid Glass. After three months of strong feedback during beta-testing, I was disappointed when Tahoe was released on 15 September to see how little had been addressed. When 26.1 followed on 3 November it had only regressed, and 26.2 has done nothing. Here I summarise my opinions on where Tahoe's overhaul has gone wrong. Howard Oakley at The Eclectic Light Company Apple bloggers and podcasters are hell-bent on blaming Apple's terrible GUI design over the past 10 years on one man. Their first target was Jony Ive, who was handed control over not just hardware design, but also software design in 2012. When he left Apple, GUI design at Apple would finally surely improve again, and the Apple bloggers and podcasters let out a sigh of relief. History would turn out different, though - under Ive's successor, Alan Dye, Apple's downward trajectory in this area would continue unabated, culminating in the Liquid Glass abomination. Now that Alan Dye has left Apple, history is repeating itself: the very same Apple bloggers and podcasters are repeating themselves - surely now that Alan Dye is gone, GUI design at Apple will finally surely improve again. The possibility that GUI design at Apple does not hinge on the whims of just one person, but that instead the entire company has lost all sense of taste and craftmanship in this area does not cross their minds. Everyone around Jony Ive and Alan Dye, both below, alongside, and above them, had to sign off on Apple's recent direction in GUI design, and the idea that the entire company would blindly follow whatever one person says, quality be damned, would have me far more worried as an Apple fan. At this point, it's clear that Apple's inability to design and build quality user interfaces is not the fault of just one fall guy, but an institutional problem. Anyone expecting a turnaround just because Ive Dye is gone isn't seeing the burning forest through the trees.

We're all familiar with things like marquee and blink, relics of HTML of the past, but there are far more weird and obscure HTML tags you may not be aware of. Luckily, Declan Chidlow at HTMLHell details a few of them so we can all scratch shake our heads in disbelief. But there are far more obscure tags which are perhaps less visually dazzling but equally or even more interesting. If you're younger, this might very well be your introduction to them. If you're older, this still might be an introduction, but also possibly a trip down memory lane or a flashback to the horrors of the first browser war. It depends. Declan Chidlow at HTMLHell I think my favourite is the dir tag, intended to be used to display lists of files and directories. We're supposed to use list tags now to achieve the same result, but I do kind of like the idea of having a dedicated tag to indicate files, and perhaps have browsers render these lists in the same way the file manager of the platform it's running on does. I don't know if that was possible, but it seems like the logical continuation of a hypothetical dir tag. Anyway, should we implement bgsound on OSNews?

If you're building a package manager and git-as-index seems appealing, look at Cargo, Homebrew, CocoaPods, vcpkg, Go. They all had to build workarounds as they grew, causing pain for users and maintainers. The pull request workflow is nice. The version history is nice. You will hit the same walls they did. Andrew Nesbitt It's wild to read some of these stories. I can't believe CocoaPods had 16000 directories contained in a single directory, which is absolutely bananas when you know how git actually works. Then there's the issue that git is case-sensitive, as any proper file system should be, which causes major headaches on Windows and macOS, which are dumb and are case-insensitive. Even Windows' path length limits, inherited from DOS, cause problems with git. There just so many problems with using git for a package managers' database. The basic gist is that git is not a database, and shouldn't be used as such. It's incredulous to me that seasoned developers would opt for solutions" like this.

Christmas is already behind us, but since this is an announcement from 11 December - that I missed - I'm calling this a very interesting and surprising Christmas present. The team and I are beyond excited to share what we've been cooking up over the last little while: a full desktop environment running on QNX 8.0, with support for self-hosted compilation! This environment both makes it easier for newly-minted QNX developers to get started with building for QNX, but it also vastly simplifies the process of porting Linux applications and libraries to QNX 8.0. John Hanam at the QNX Developer Blog What we have here is QNX 8.0 running the Xfce desktop environment on Wayland, a whole slew of build and development tools like clang, gcc, git, etc.), a ton of popular code editors and IDEs, a web browser (looks like GNOME Web?), access to all the ports on the QNX Open-Source Dashboard, and more. For now, it's only available as a Qemu image to run on top of Ubuntu, but the plan is to also release an x86 image in the coming months so you can run this directly on real hardware. This isn't quite the same as the QNX of old with its unique Photon microGUI, but it's been known for a while now that Photon hasn't been actively developed in a long time and is basically abandoned. Running Xfce on Wayland is obviously a much more sensible solution, and one that's quite future-proof, too. As a certified QNX desktop enthusiast of yore, I can't wait for the x86 image to arrive so I can try this out properly. There are downsides. This image, too, is encumbered by annoying non-commercial license requirements and sign-ups, and this also wouldn't be the first time QNX starts an enthusiast effort, only to abandon it shortly after. Buyer beware, then, but I'm cautiously optimistic.

We've got more X11-related news this day, the day of Xmas. Phoenix is a new X server, written from scratch in Zig (not a fork of Xorg server). This X server is designed to be a modern alternative to the Xorg server. Phoenix' readme page Phoenix will only support a modern subset of the X11 protocol, focusing on making sure modern applications from roughly the last 20 years or so work. It also takes quite a few pages out of the Wayland playbook by not having a server driver interface and by having a compositor included. On top of that, it will isolate applications from each other, and won't have a single framebuffer for all displays, instead allowing different refresh rates for individual displays. The project also intends to develop new standards to support things like per-monitor DPI, among many other features. That's a lot of features and capabilities to promise for an X server, and much like Wayland, the way they aim to get there is by effectively gutting traditional X and leaving a ton of cruft behind. The use of Zig is also interesting, as it can catch some issues before they affect any users thanks to Zig's runtime safety option. At least it's not yet another thing written in Rust like every other project competing with an established project. I think this look like an incredibly interesting project to keep an eye on, and I hope more people join the effort. Competition and fresh, new ideas are good, especially now that everything is gravitating towards Wayland - we need alternatives to promote the sharing of ideas.

Wayback, the tool that will allow you to run a legacy X11 desktop environment on top of Wayland, released a new version just before the Christmas. Wayback 0.3 overhauls its custom command line option parser to allow for more X.org options to be supported, and its manual pages have been cleaned up. Other fixes merely include fixing some small typos and similar small changes. Wayback is now also part of Alpine Linux' stable releases, and has been made available in Fedora 42 and 43. Wayback remains alpha software and is still under major development - it's not yet ready for primetime.

Can you use a cheap FPGA board as a base for a new computer inspired by the original IBM PC? Well, yes, of course, so that's what Yuri Zaporozhets has set out to do just that. Based on the GateMateA1-EVB, the project's got some of the basics worked out already - video output, keyboard support, etc. - and work is underway on a DOS-like operating system. A ton of work is still ahead, of course, but it's definitely an interesting project.

Elementary OS, the user-friendly Linux distribution with its own unique desktop environment and applications, just released elementary OS 8.1. Its minor version number belies just how big of a punch this update packs, so don't be fooled here. We released elementary OS 8 last November with a new Secure Session-powered by Wayland-that ensures applications respect your privacy and consent, a brand new Dock with productive multitasking and window management features, expanded access to cross-platform apps, a revamped updates experience, and new features and settings that empower our diverse community through Inclusive Design. Over the last year we've continued to build upon that work to deliver new features and fix issues based on your feedback, plus we've improved support for a range of devices including HiDPI and Multi-touch devices. Danielle Fore at the elementary OS blog The biggest change from a lower-level perspective is that elementary OS 8.1 changes the default session to Wayland, leaving the X11 session as a fallback in case of issues. Since the release of elementary OS 8, a ton of progress has been made in improving the Wayland session, fixing remaining issues, and so on, and the team now feels it's ready to serve as the default session. Related to this is a new security feature in the Wayland session where the rest of the screen gets dimmed when a password dialog pops up, and other windows can't steal focus. The switch to Wayland also allowed the team to bring fractional scaling to elementary OS with 8.1. Elementary OS is based on Ubuntu, and this new release brings an updated Hardware Enablement stack, which brings things like Linux 6.14 and Mesa 25. This is also the first release with support for ARM64 devices that can use UEFI, which includes quite a few popular ARM devices. Of course, the ARM64 version comes as a separate ISO. Furthermore, there's a ton of improvements to the dock - which was released with 8 as a brand-new replacement for the venerable Plank - including bringing back some features that were lost in the transition from Plank to the new dock. Animations are smoother, elementary OS' application store has seen a slew of improvements from clearer licensing information, to a controller icon for games that support them, to a label identifying applications that offer in-app purchases, and more. There's a lot more here, like the accessibility improvements we talked about a few months ago, and tons more.

Mount Amiga filesystem images on macOS/Linux using native AmigaOS filesystem handlers via FUSE. amifuse runs actual Amiga filesystem drivers (like PFS3) through m68k CPU emulation, allowing you to read Amiga hard disk images without relying on reverse-engineered implementations. Amifuse GitHub page Absolutely wild.