Anyone who has spent any time recently using non-GNOME GTK desktop environments, like Cinnamon, MATE, or Xfce, has had to deal with the unfortunate reality of a lot of GTK applications becoming GNOME applications instead, using GNOME’s own libadwaita. These applications are hard to theme, and do not integrate at all with the proper GTK applications non-GNOME desktop environments ship with. With how popular GNOME is, this has meant that the number of non-GNOME GTK applications has been dwindling.

Linux Mint, the popular Linux distribution that also develops the Cinnamon desktop environment, has long made a bundle of GTK applications called XApps – basically forks of various core GNOME 3.x applications to ensure they would have access to non-GNOME GTK applications. With GNOME effectively forking GTK into its own, unique, GNOME-specific style (like libaidwaita), other GTK environments have suffered, and XApps were intended to close that gap.

That hasn’t really happened though, as XApps remained mostly a Mint-only thing, managed by Mint, as part of the Mint/Cinnamon GitHub projects. Other distributions and GTK desktop environments, such as Xfce, MATE, Budgie, and so on, didn’t really pick them up. The Linux Mint project intends to change that, and will ‘spin off’ the XApps into its own, dedicated, independent project to facilitate cross-distribution and cross-DE collaboration, decision-making and development, all in an effort to ensure the long-term viability of non-GNOME GTK desktop environments.

They also intend to fork a lot more of the GNOME 3 applications, for the same reason I mentioned earlier: GNOME applications are no longer GTK applications, but GNOME applications – they look and feel horribly out of place in environments that don’t use the GNOME-specific libadwaita. As such, Celluloid, GNOME Calculator, Simple Scan, Baobab, System Monitor, GNOME Calendar, File Roller, and Zenity were recently downgraded in Linux Mint to their last GTK 3 versions, and will most likely be forked in the near future.

In addition, the Adwaita theme, the default GNOME/GTK theme, will be removed from the list of available themes in Cinnamon 6.2. Adwaita, too, has become increasingly GNOME-only, and thus, increasingly broken on non-GNOME desktop environments. Flat-our removing Adwaita altogether is not possible, since it’s a GTK dependency, but hiding it from the theme selector is not an issue, of course.

As project lead Clément Lefèbvre writes:

libAdwaita is for GNOME and GNOME only. We can’t blame GNOME for this, they’ve been very clear about it from the start. It was made specifically for GNOME to have more freedom and build its own ecosystem without impacting GTK.

We want to send a strong signal upstream and towards other projects. We cannot and will not support applications which do not support our users and environments.

We can’t promote applications to our users which don’t support our users. The software manager will be vigilant towards that going forward and list compatible software by default.

↫ Clément Lefèbvre

All of this is great news to hear. I’ve been making extensive use of Xfce on OpenBSD lately, and on the Fedora Xfce spin in the weeks before that, and the situation has become almost comical. If you install any GNOME application on Xfce, theming just breaks down completely, as most themes are either not made to support the massive headerbars GNOME uses, or they do support it but still look horribly out of place compared to the more sane titlebar plus menubar plus toolbar layout of traditional desktop environments like Xfce.

I’ve long been saying that the non-GNOME GTK desktop environments need to work together to formulate an answer to the onslaught of libadwaita and the GNOME-ification of GTK, because each of them risks becoming entirely tied to whatever GNOME and libadwaita decides to do, for better or worse. It seems the Linux Mint team has finally realised this as well, and I really hope – and strongly suggest – Xfce, MATE, and others join them as well.

If they don’t, there won’t be an Xfce in a few years. What’s the point in developing Xfce if you’re at the mercy of whatever choices GNOME makes?

Another month, another detailed report about the progress made in Redox, the Rust-based operating system. A major improvements this month is support for USB HID, allowing USB keyboards and mice to work on Redox, but the project does note USB hubs are still problematic and might not work properly. Thanks to these USB improvements, Redox’ desktop environment Orbital now also ran on ARM64 in Qemu for the first time, which is a great step towards running it on real ARM64 hardware.

A massive documentation pass has also taken place, fixing various errors and improving and simplifying the writing. More programs have been ported, of course, and various lower-level improvements and fixes, along with a number of other fixes and changes across the operating system.

Over 35 years ago, these problems with software portability led to the emergence of the first POSIX standard in 1988. The acronym was coined by Richard Stallman, who added “X” to the end of Portable Operating System Interface. It’s meant to provide a specification of the interface that different Unix operating systems should have in common, including programming languages and tools. It’s important to note that the interface is portable, and not the implementation.

↫ vorakl

While POSIX certainly isn’t perfect, and support for it in various operating systems claiming to support POSIX even less so, there’s no denying its success. Even if the dream of 100% source code portability isn’t possible under POSIX for applications that are a little more complex than basic CLI tools, there’s enough portability that platforms like Linux, the various BSDs, macOS, and others, can share quite a bit of code.

One of my favourite things about POSIX is that it shows up in the most unexpected of places. Windows, for instance, has had various options for POSIX compatibility, some of which straight from Microsoft itself, like the currently well-known Windows Subsystem for Linux, but also mostly forgotten options like the Microsoft POSIX subsystem that shipped with Windows NT until Windows 2000, or the very rudimentary POSIX compatibility in the Windows C Runtime Library and Windows Sockets API.

OS/2 had POSIX compatibility as well, through EMX (Eberhard Mattes eXtender). It gave OS/2 – and MS-DOS – a POSIX API, and even provided access to native OS/2 APIs as well, and could run 32bit applications. You’d be surprised by how many more operating systems offered forms of POSIX compatibility, either out of the box or through first or third party add-ons.

Although Google has shown significant progress in recent weeks in improving RISC-V support in Android, it seems that we’re still quite a bit away from seeing RISC-V hardware running certified builds of Android. Earlier today, a Senior Staff Software Engineer at Google who, according to their LinkedIn, leads the Android Systems Team and works on Android’s Linux kernel fork, submitted a series of patches to AOSP that “remove ACK’s support for riscv64.” The description of these patches states that “support for risc64 GKI kernels is discontinued.”

↫ Mishaal Rahman

Google provided Android Authority with a statement, claiming that Android will continue to support RISC-V. What these patches do, however, is remove support for the architecture from the Generic Kernel Image, which is the only type of kernel Google certifies for Android, which means that it is now no longer possible to ship a certified Android device that uses RISC-V. Any OEM shipping a RISC-V Android device will have to create and maintain its own kernel fork with the required patches. This doesn’t seem to align with Google’s statement.

So, unless Google intends to add RISC-V support back into GKI, there won’t be any officially certified Android devices running on RISC-V. Definitely an odd chain of events here.

There’s a new 9front release! So, what exactly is 9front, you may ask? Well, after it became clear that Bell Labs wasn’t doing much with plan9, a group of developers took matters into their own hands and created 9front, a fork of plan9. Their latest release is called DO NOT INSTALL, and brings things like more USB audio support, DNS over TLS, WiFi support for the Raspberry Pi, I2C support, and much more.

I’m not particularly well-versed in the world of plan9, and more often than not it feels like a form of high-level programming performance art that I’m just not smart enough to understand. The whole community and its associated web sites have a very unique feel to it, and I always feel like I’m just not cool enough to be part of it. That’s not a dig at the plan9 community – it’s more of an indictment of my lack of coolness.

Which really shouldn’t come as a surprise.

Lennart Poettering, main developer of systemd, has announced run0, a systemd-based replacement for the well-known sudo command that fixes many of he inherent issues with the widely used tool to gain temporary elevated privileges. There are various problems with sudo, which basically come down to that it’s a large SUID binary, meaning it consists of privileged code that unprivileged users can run from their own context. This makes sudo a fairly large attack surface, and why OpenBSD uses doas instead; while doas suffers from the same main problem, it’s much smaller and reduces the attack surface considerably.

SUID processes are weird concepts: they are invoked by unprivileged code and inherit the execution context intended and controlled by unprivileged code. By execution context I mean the myriad of properties that a process has on Linux these days, from environment variables, process scheduling properties, cgroup assignments, security contexts, file descriptors passed, and so on and so on. A few of these settings the kernel is nice enough to clean up automatically when a SUID binary is invoked, but much of it has to be cleaned up by the invoked suid binary. This has to be done very very carefully, and history has shown that SUID binaries are generally pretty shit at that.

↫ Lennart Poettering

Poettering wants to address this problem, and has come up with run0, which behaves like sudo, but works entirely differently and is not SUID. Run0 asks the services manager to create a shell or command under the target user’s ID, creating a new PTY, sending data back and forth from the originating TTY and the new PTY.

Or in other words: the target command is invoked in an isolated exec context, freshly forked off PID 1, without inheriting any context from the client (well, admittedly, we *do* propagate $TERM, but that’s an explicit exception, i.e. allowlist rather than denylist).

One could say, “run0” is closer to behaviour of “ssh” than to “sudo”, in many ways. Except that it doesn’t bother with encryption or cryptographic authentication, key management and stuff, but instead relies on the kernel’s local identification mechanisms.

run0 doesn’t implement a configuration language of its own btw (i.e. no equivalent of /etc/sudoers). Instead, it just uses polkit for that, i.e. how we these days usually let unpriv local clients authenticate against priv servers.

↫ Lennart Poettering

This approach addresses a whole slew of attack vectors on sudo, and it comes with fun additional features like being able to give your terminal a different background tint when using it, or displaying a little red dot in the terminal window title to further indicate you’re using elevated privileges. It will ship as part of the upcoming release of systemd 256.

This is a virtual DEC PDP-1 (emulated in HTML5/JavaScript) running the original code of “Spacewar!”, the earliest known digital video game. If available, use gamepads or joysticks for authentic gameplay — the game was originally played using custom “control boxes”.

Spacewar! was conceived in 1961 by Martin Graetz, Stephen Russell, and Wayne Wiitanen. It was first realized on the PDP-1 in 1962 by Stephen Russell, Peter Samson, Dan Edwards, and Martin Graetz, together with Alan Kotok, Steve Piner, and Robert A Saunders.

↫ Norbert Landsteiner

It’s wild to me that even for the very first video game, they already made what are effectively controllers anyone today could pick up and use. Note that this emulator can run more than just Spacewar!.

Back when I was working on my article about PA-RISC, HP-UX, and UNIX workstations in general, I made extensive use of OpenPA, Paul Weissmann’s invaluable and incredibly detailed resource about HP’s workstation efforts, HP-UX, and tons of related projects and products. Weissmann’s been doing some serious digging, and has unearthed details about a number of essentially forgotten operating system efforts.

First, it turns out HP was porting Windows NT to PA-RISC in the early ’90s.

Several magazine sources and USEnet posts around 1993 point to HP pursuing a PA-RISC port to NT, modified the PA-RISC architecture for bi-endianess and even conducted a back-room presention at the ’94 Comdex conference of a (modified HP 712?) PA-7100LC workstation running Windows NT. Mentions of NT on PA-RISC continued in 1994 with some customer interest but ended around 1995.

↫ Paul Weissmann at OpenPA

The port eventually fizzled out due to a lack of interest from both customers and application developers, and HP realised its time was better spent on the future of x86, Intel’s Itanium, instead. HP also planned to work together with Novell to port NetWare to PA-RISC, but the work took longer than expected and it, too, was cancelled.

The most recent secretive effort was the port of HP-UX to x86, an endeavour that took place during the final days of the UNIX workstation market.

Parts of the conversation in these documents mention a successful boot of HP-UX on x86 in December of 2009, with porting efforts projected to cost 100M+ between 2010 and 2016. The plan was for mission-critical x86 systems (ProLiant DL980 and Superdome with x86) and first releases projected in 2011 (developer) and 2012 (Superdome and Linux ABI).

↫ Paul Weissmann at OpenPA

I’m especially curious about that last one, as porting HP-UX to x86 seems like a massive effort during a time where it was already obvious Linux had completely obliterated the traditional UNIX market. It really feels like the last death saving throws of a platform everybody already knew wasn’t going to make it.

In February last year I wrote about running a FreeBSD desktop, and concluded that sometimes you need to give yourself permission to tinker.

Well recently I’ve started tinkering with Alpine Linux! It’s been recommended to me for years, so I’m finally getting around to checking it out. There’s a lot to like if you come from BSD, which we’ll dig into here.

↫ Ruben Schade

Just a quick look at this unexpectedly popular Linux distribution that really has its own identity.

The Genode project has released Sculpt OS 24.04, the general purpose desktop operating system based on the Genode OS Framework. This release is absolutely jam-packed with new features, improvements, and changes, and it’s hard to know where to begin. One of the biggest new features is support for suspend/resume, an experimental feature for now, for which the developers also made starting and stopping drivers and related components easier straight from the user interface. In addition, NVMe, AHCI, and Intel GPU drivers will resume automatically after a resume.

Sculpt OS 24.04 also ships with a brand new audio framework, which brings support for “pluggable drivers, arbitrary sample rates, and the flexible routing and mixing of audio signals”, but the audio driver does need to be manually restarted after a resume. This release also adds support for 4K displays and I2C touchpads, underlining that yes, Sculpt and Genode developers dogfood their operating system on real hardware. Do note that at least for now, the I2C touchpad driver needs to be started manually, so an external mouse will initially be needed.

Various images are available for download from the download page.

Regarding the release of the MS-DOS 4.00 source code, Michal Necasek makes an excellent point about how just dumping the code in git is a terrible and destructive way to release older source code.

It’s terrific that the source code for DOS 4.00/4.01 was released! But don’t expect to build the source code mutilated by git without problems.

Historic source code should be released simply as an archive of files, ZIP or tar or 7z or whatever, with all timestamps preserved and every single byte kept the way it was. Git is simply not a suitable tool for this.

↫ Michal Necasek at OS/2 Museum

The problems caused by dumping the code in git are quite real. Timestamps are not preserved, and the conversion to UTF-8 is deeply destructive, turning some parts of the code to literal gibberish. It’s a bit of a mess, and the people responsible for these release should be more careful and considerate.

Today, in partnership with IBM and in the spirit of open innovation, we’re releasing the source code to MS-DOS 4.00 under the MIT license. There’s a somewhat complex and fascinating history behind the 4.0 versions of DOS, as Microsoft partnered with IBM for portions of the code but also created a branch of DOS called Multitasking DOS that did not see a wide release.

↫ Scott Hanselman

Not only did they release the source code to MS-DOS 4.00, they also released disk images of a very early version of Multitasking DOS, which did not see a wide release, as the article states. I’ve only vaguely heard of MT-DOS over the decades, so I had to do some minor reading and research to untangle what, exactly, MT-DOS really is. Much of this information is probably table stakes for the many older readers we have, but bear with me.

MT-DOS, which has the official name MS-DOS 4.0 (often further specified by adding “multitasking” in brackets after the version number) was a version of MS-DOS developed by Microsoft based on MS-DOS 2.0, whose headlining feature was pre-emptive multitasking, which allowed specifically written applications to continue to run in a special background mode. Interestingly enough, it had to perform this multitasking with the same 640k memory limitation as other versions of DOS. Very few OEMs ended up licensing it, and most notably IBM wasn’t interested, so after one or two more OEM-specific versions, it was quickly abandoned by Microsoft.

MS-DOS 4.0 (multitasking) is entirely unrelated to the “real” versions 4 of MS-DOS that followed later. The actual version 4 was called MS-DOS 4.00, and it’s the source code to this specific version that’s being released as open source today. MS-DOS 4.00 was quickly followed by 4.01 and 4.01a, but apparently OEMs would confusingly still label 4.01 disks as “MS-DOS 4.0”. The whole MS-DOS 4 saga is quite convoluted and messy, and I’m probably oversimplifying a great deal.

Regardless, this code joins the open source releases of MS-DOS 1.25 and 2.0 that Microsoft released years ago.

Gentoo, the venerable Linux distribution which in my headcanon I describe as ‘classy’, has banned any use of “AI”. A proposal by Gentoo Council member Michał Górny from February of this year banning its use has been unanimously accepted by the Gentoo Council. The new policy reads:

It is expressly forbidden to contribute to Gentoo any content that has been created with the assistance of Natural Language Processing artificial intelligence tools. This motion can be revisited, should a case been made over such a tool that does not pose copyright, ethical and quality concerns.

↫ Michał Górny

We’ll have to see how this policy will be implemented, but I like that Gentoo is willing to take a stand.

It wasn’t too long ago that new Ubuntu releases were major happenings in the Linux world, as it was the default Linux distribution for many, both old and newcomers, in the desktop Linux space. These days, Ubuntu release hit a little different, with Canonical’s focus having shifted much more to the enterprise, and several aspects of the distribution being decidedly unpopular, like the snap package management system.

Still, Ubuntu is probably still one of the most popular, if not the most popular, distributions out there, so any new release, like today’s Ubuntu 24.0 LTS, is still a big deal.

Ubuntu Desktop brings the Subiquity installer to an LTS for the first time. In addition to a refreshed user experience and a minimal install by default, the installer now includes experimental support for ZFS and TPM-based full disk encryption and the ability to import auto-install configurations. Post install, users will be greeted with the latest GNOME 46 alongside a new App Center and firmware-updater. Netplan is now the default for networking configuration and supports bidirectionality with NetworkManager.

↫ Utkarsh Gupta on ubuntu-announce

Of course, all the various other Ubuntu editions have also seen new releases: Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity, and Xubuntu. Yes, that’s a long list. They all mostly share the same improvements as Ubuntu’s main course, but paired with the latest versions of the respective desktop environments instead.

Except for Kubuntu. Unlike just about any other major distribution released over the last few months, such as Fedora 40 only a few days ago, Kubuntu does not ship with the new KDE Plasma 6, opting for Plasma 5.27.11 instead. There simply wasn’t enough time between the release of Plasma 6 and the Ubuntu feature freeze, so they made the – in my opinion – understandable call to stick to Plasma 5 for now, moving Plasma 6 to the next release later this year.