It’s been two years since the release of ArcaOS 5.1, which was a hugely important release because it brought UEFI support to this continuation of IBM’s OS/2, ensuring longevity for the project for years to come. Since I don’t think much is known about what, exactly, Arca Noae, and eComStation before it, has access to within the licensing agreement with IBM, it’s difficult to ascertain just how much room they actually have to make changes to the code at the core of the old OS/2. Regardless, I tested ArcaOS 5.1 before and during its release, and the support for UEFI and GPT partition layouts was excellent on my machines.

Almost 18 months later comes the next release in the 5.1 branch, ArcaOS 5.1.1, and as the version number implies, this isn’t another major release on the scale of 5.1. Looking at the list of changes, it mostly contains a ton of upgraded versions of various programs and tools included in ArcaOS. After some digging into some of those upgraded versions, I think I can safely say we’re looking at a ton of small bugfixes, but there are also a few other things that stand out to me as welcome changes.

For instance, the changelog mentions various improvements to the installer and related tools, such as an improved method of determining the right screen resolution and font scaling during the installation. Considering I had to deal with some issues there – I think the installer UI elements were grossly oversized – this is a welcome fix. There are also “refreshed” Firefox and Thunderbird builds, although I don’t know if that means an update to the latest ESR releases, or just a rebuild of what was already shipping with ArcaOS 5.1.

I never found the time around the 5.1 release to do a proper review – I was knee-deep in baby and toddler care overload at the time – but if Arca Noae is willing to provide me with a 5.1.1 copy, I should be able to actually review it now that I’m only ankle-deep in baby and toddler care overload.

What might be somewhat more surprising though considering its research origins is that Unix almost since the very beginning had a comprehensive set of online reference documentation for all its commands, system calls, file formats, etc. These are the the manual- or man-pages. On Unix systems used interactively, the man-pages have historically always been installed, space permitting.

[…]

The way the manual pages have evolved and how they are used has changed over the decades. This set of posts is intended to give people unfamiliar with them an overview, as well as offer a review to seasoned users.

↫ Alex Bochannek

Right in this first article in the series there’s an interesting observation I never stopped and thought about: because the original creators of UNIX were writing the content of man pages with the very tools they were creating for UNIX, it led to a virtuous cycle. “Unix tools were used to document Unix, improving the documentation tools themselves as well.” I tend to use the internet now to learn how specific tools and commands work, but having such detailed man pages built right into the operating system was a huge deal pre-internet.

JotaleaOS is an open source, minimalistic, experimental operating system made by Jotalea, designed for extreme low-resource environments. It does not support external programs or games, as it lacks a standard application execution environment. The system is entirely self-contained, running only its built-in commands.

↫ JotaleaOS website

Exactly what is says on the tin: a tiny operating system created entirely as a learning experience. That’s it.

Unlike most (all?) other distributions with built-in Flatpak support, Fedora maintains its own repository of Flatpak applications. Everyone else defaults to using Flathub, where developers of applications themselves tend to publish their Flatpaks. Fedora’s ‘shadow Flathub’ sometimes leads to problems, with Fedora-made Flatpaks containing bugs and brokenness, while presenting themselves as official, developer-made Flatpaks. In turn, users complain to the developers, while the issues they experience are actually caused by Fedora making its own Flatpaks.

One of the applications this happened to is OBS, and over three weeks ago the OBS project requested that either the broken, unofficial Fedora Flatpak be removed, or that it be made clear that the Flatpak was third-party. This request seems entirely reasonable to me, and it would be fairly trivial for Fedora to do this. In fact, I think respecting this request is merely common decency. Sadly, the Fedora project thought differently, and just… Ignored the request.

And so the OBS project escalated the issue.

This is a formal request to remove all of our branding, including but not limited to, our name, our logo, any additional IP belonging to the OBS Project, from your distribution.

Failure to comply may result in further legal action taken. We expect a response within the next 7 business days (By Friday, February 21st, 2025).

↫ Joel Bethke

It seems this caught the attention of the Fedora project, as within less than 24 hours, a formal request was made by the maintainer of Fedora’s OBS RPM package to have the broken OBS Flatpak removed. It seems there’s no official process to follow for making such a request, but I hope it gets through and honoured, if only because, like I said above, it would be common decency to do so.

I do wish to go back to the original OBS complaint, though, as it poses the question most of you are asking yourselves at this point.

I would also like some sort of explanation on why someone thought it was a good idea to take a Flatpak that was working perfectly fine, break it, and publish it at a higher priority to our official builds. We spend an enormous amount of effort on our official Flatpak published to Flathub to ensure everything is working as well as it can be.

↫ Joel Bethke

Why does Fedora maintain its own shadow-Flathub, set at a higher priority than the real Flathub? There’s a few reasons, as detailed in this Fedora Magazine article from 2022. There’s the obvious stuff like Fedora only allowing free and open source software, whereas Flathub also allows proprietary software, meaning that if Fedora ships with the Flathub repository enabled and prioritised, it would violate Fedora’s policies. You can argue back and forth about this, but Fedora’s policy being what it is, I can see where they’re coming from. The article mentions Flathub will split proprietary applications from free and open source ones, but I can’t find any word on if this has happened already.

A second big difference are the sources where the Flatpaks are drawn from. While Flathub allows and all sources, with their packages reusing Debian packages, Ubuntu Snaps, tarballs, AppImages, and more, Fedora exclusively reuses its own RPM packages when creating its Flatpak packages. Furthermore, Fedora Flatpaks use the Docker-like OCI format to publish applications (which ties into the Fedora Registry), while Flathub uses OSTree. Lastly, Fedora Flatpaks use one, single, big underlying runtime, while Flathub has a number of different, smaller runtimes.

The issue here seems to be that the motivations for maintaining a Flatpak repository differ greatly between Flathub and Fedora, but one has to wonder how much of that actually matters to users. Maintaining your own, separate Flatpak repository that effectively duplicates the work developers do when publishing to Flathub is not only wasteful, but also prone to cause bugs, issues, and outdated Flatpaks – which in turn causes strife with the original developers of the applications who have to deal with problems causes not by their own work, but by Fedora – problems that they can’t even fix.

I don’t think this situation makes any sense to perpetuate, and it’s high time Fedora defaults to Flathub for Flatpak applications. It will reduce the workload on package maintainers, prevent needless packaging bugs, improve the experience for users, and make developers happier. It’s a no-brainer at this point.

One of the major issues with KDE’s styling system is the fact that over the year, it has accumulated four ways of styling applications – which makes themeing and changing aspects of the default theme far more cumbersome than it should be. In fact, with the current version of KDE, it’s effectively impossible to consistently theme the entire KDE desktop, as several parts of it, like Kirigami applications, only inherit parts of the theme you’re applying. It’s a bit of a mess, and KDE is well aware of this.

This problem is not new; we already identified it several years ago. Unfortunately, it also is not easy to solve. Some of the reasons it got to this state are simply inertia. Some things like Plasma’s SVG styling were developed as a way to improve styling in an era where a lot of the technologies we currently use did not exist yet. The solutions developed in those days have now existed for a pretty long time so we cannot suddenly drop them. Other reasons are more technical in nature, such as completely different rendering stacks.

↫ Arjen Hiemstra

These different rendering stacks form the core of the problem, as they can’t use the same rendering code for everything. Currently, KDE tries to address the problem through a compatibility layer to tie everything together, but it’s not perfect, it has to be maintained, and it means they’re not utilising their rendering stacks to their fullest potential. The solution KDE is working on is called Union.

However, there is another option, which is to take a step back and realise that we actually may not even want to share the rendering code, given that they are quite different. Instead, we need a description of what the element should look like, and then we can have specific rendering code that implements how to render that in the best way for a certain technology stack.

↫ Arjen Hiemstra

Basically, an input layer will interpret file formats with style descrpitions, while an intermediate layer consists of a library that converts that interpretation into a more abstract description of what needs to be rendered. The final output layer then uses the data from the intermediate layer to tell the rendering stacks what to do. By standardising on the input format, say CSS, it’ll be much easier to impement themes or make changes.

This effort is still far from done, but they’re making good progress. It ties into the Plasma Next initiative, which is, as the name implies, an effort to make changes to Plasma’s default look and feel.

You might think the world of Linux distributions is a rather boring, settled affair, but there’s actually a ton of interesting experimentation going on in the Linux world. From things like NixOS with its unique packaging framework, to the various immutable distributions out there like the Fedora Atomic editions, there’s enough uniqueness to go around to find a lid for every pot. Oasis Linux surely falls into this category. One of its main unique characteristics is that it’s entirely statically linked.

All software in the base system is linked statically, including the display server (velox) and web browser (netsurf). Compared to dynamic linking, this is a simpler mechanism which eliminates problems with upgrading libraries, and results in completely self-contained binaries that can easily be copied to other systems.

↫ Oasis GitHub page

That’s not all it has to offer, though. It also offers fast and 100% reproducible builds, it’s mostly ISO C conformant, and it has minimal bootstrap dependencies – all you need is a “POSIX system with git, lua, curl, a sha256 utility, standard compression utilities, and an x86_64-linux-musl cross compiler”. The ISO C-comformance is a crucial part of one of Oasis’ goals: to be buildable with cproc, a small, very strict C11 compiler. It has no package manager, but any software outside of Oasis itself can be installed and managed with pkgsrc or Nix.

Another important goal of the project is to be extremely easy to understand, and its /etc directory is honestly a sight to behold, and as the project proudly claims, the most complex file in there is rc.init at a mere 16 lines. The configuration files are indeed incredibly easy to understand, which is a breath of fresh air compared to the archaic stuff in commercial UNIX or the complex stuff in modern Linux distributions that I normally deal with.

I’m not sure is Oasis would make for a good, usable day-to-day operating system, but I definitely like what they’re putting down.

During a weekend of tidying up – you know, the kind of chore where you’re knee-deep in old boxes before you realize it. Digging through the dusty cables and old, outdated user manuals, I found something that I had long forgotten: an old Plan 9 distribution. Judging by the faded ink and slight warping of the disk sleeve, it had to be from around 1994 or 1995.

I couldn’t help but wonder: why had I kept this? Back then, I was curious about Plan 9. It was a forward-thinking OS that never quite reached full potential. Holding that disk, however, it felt more like a time capsule, a real reminder of computing’s advancements and adventurous spirit in the 1990s.

↫ Bill Dyer at It’s FOSS

As the article notes, 9front is the way to go if you want to try Plan 9 today. Plan 9/9front appeals to a very specific type of person, but when you dive into the excellent – and incredibly entertaining – documentation, it really seems quite easy to grasp and get started with. There’s definitely things you’ll need to unlearn and some compromises you’ll need to make, but I think you’ll be able to get a lot more work done than you might think.

Also, if you start adding software to 9front, you get to use the best GitHub alternative of all time: shithub. That alone makes it worth it to try 9front.

A complete guide to configuring FreeBSD as an audiophile audio server: setting up system and audio subsystem parameters, real-time operation, bit-perfect signal processing, and the best methods for enabling and parameterising the system graphic equalizer (equalizer) and high-quality audio equalization with FFmpeg filters. Linux users will also find useful information, especially in the context of configuring and personalising the MPD player and filters.

↫ Marcin Szewczyk-Wilgan

FreeBSD is a much more capable desktop and workstation operating system than it gets credit for, especially with the Linux world sucking all the air out of the room, but you do often need to do a little more and dive a little deeper into the operating system to get it to do what you want. In the case of audio, Szewczyk-Wilgan explains that he thinks it’s even ahead of Linux, due to being able to “precisely track the parameters of the audio device along with the system kernel parameters and modify them”, as well as FreeBSD having better support for real-time operation.

This guide is an incredibly detailed explanation of which options and configurations you should use in FreeBSD to turn it into an audio server. This clearly isn’t for everyone, and I assume most audio experts won’t be considering FreeBSD, but what this article demonstrates is that it’s very, very much possible to do so.

Cassette is a GUI application framework written in C11, with a UI inspired by the cassette-futurism aesthetic. Built for modern POSIX systems, it’s made out of three libraries: CGUI, CCFG and COBJ. Cassette is free and open-source software, licensed under the LGPL-3.0.

↫ Cassette GitHub page

Upon first reading this description, you might wonder what a “cassette-futurism aesthetic” really is, but once you take a look at the screenshots of what Cassette can do, you immediately understand what it means. It’s still in the alpha stage and there’s lot still to do, but what it has now is already something quite unique I don’t think the major toolkits really cater to or can even pull off.

There’s an example application that’s focused on showing some system stats, and that’s exactly the kind of stuff this seems a great fit for: good-looking, small widget-like applications showing glanceable information.

It kind of goes by under the radar, but aside from HP-UX, Solaris, and AIX, there’s another traditional classic UNIX still in active development today: UnixWare (and its sibling, OpenServer). Owned and developed by Xinuos, UnixWare and other related code and IP was acquired by them when the much-hated SCO crashed and burned about 15 years ago or so, and they’ve been maintaining it ever since. About a year ago, Xinuos released Update Pack 1 and Maintenance Pack 1 for UnixWare 7 Definitive 2018, followed by similar update packs for OpenServer 6 later in 2024.

These update packs bring a bunch of bugfixes and performance improvements, as well as a slew of updated open source components, like new versions of SAMBA, sendmail, GCC and tons of other GNU components, OpenSSH and OpenSSL, and so, so much more, enabling a relatively modern and up-to-date build and porting environment. They can be installed through the patchck update utility, and while the Maintenance Pack is free for existing registered users, the Update Pack requires a separate license. UnixWare, while fully capable as a classic UNIX for workstations, isn’t really aimed at individuals or hobbyists (sadly), and instead focuses on existing enterprise deployments, where such licensing costs are par for the course.

UnixWare runs on x86, and can be installed both on real hardware as well as in various virtualised environments. I contacted Xinuos a few days ago for a review license, and they supplied me with one so I can experiment with and write about UnixWare. I’ve currently got it installed in a Linux kvm, where it runs quite well, including the full X11R6 CDE desktop environment and graphical administration tools. Installing updates is a breeze thanks to patchck automating the process of finding, downloading, and installing the correct ones. I intend to ask Xinuos about an optimal configuration for running UnixWare on real hardware, too.

Upstart was an event-based replacement for the traditional System V init (sysvinit) system on Ubuntu, introduced to bring a modern and more flexible way of handling system startup and service management. It emerged in the mid-2000s, during a period when sysvinit’s age and limitations were becoming more apparent, especially with regard to concurrency and dependency handling. Upstart was developed by Canonical, the company behind Ubuntu, with the aim of reducing boot times, improving reliability, and making the system initialization process more dynamic. Though at first it seemed likely to become a standard across many distributions, Upstart eventually lost mindshare to systemd and ceased to be Ubuntu’s default init system.

↫ André Machado

I think it’s safe to say systemd won the competition to become the definitive successor to sysvinit on Linux, but Canonical’s Upstart made a valiant effort, too. However, with a troublesome license, it was doomed from the start, and it didn’t help that virtually every other major distribution eventually adopted systemd. These days, systemd is the Linux init system, and I personally quite like it (and the crowd turns violent). I find it easy to use and it’s never given me any issues, but I’m not a system administrator dealing with complex setups, so my experience with systemd is probably rather limited. It just does its thing in the background on my machines.

None of this means there aren’t any other init systems still being actively developed. There’s GNU Shepard we talked about recently, runit, OpenRC, and many more. If you don’t like systemd, there’s enough alternatives out there.

After doing more digging than I feel like I should have needed to, I found my answer: it appears that due to concerns about the fact that acknowledging the existence of certain countries can be perceived as a nominally political stance, Microsoft has opted to just avoid the issue altogether by not including country flag emojis in Windows’ system font.

Problem solved! Can you imagine if, *gasp*, your computer could render a Taiwanese or Palestinian flag? The horror!

↫ Ryan Geyer

Silicon Valley corporations are nothing if not massive cowards, and this is just another one of the many, many examples that underline this. Firefox solves this by including the flags on its own, but Google refuses to do the same with Chrome, because, you guessed it, Google is also a cowardly organisation. There are some ways around it, as the linked article details, but they’re all clumsy and cumbersome compared to Microsoft just not being a coward and including proper flag emoji, even if it offends some sensibilities in pro-China or western far-right circles.

Your best bet to avoid such corporate cowardice is to switch to better operating systems, like any desktop Linux distribution. Fedora KDE includes both the Taiwanese and Palestinian flags, because the KDE project isn’t made up of cowards, and I’m sure the same applies to any GNOME distribution. If your delicate snowflake sensibilities can’t handle a Palestinian or Taiwanese flag emoji, just don’t type them.

Bitter sidenote: it turns out WordPress, what OSNews uses, doesn’t like emoji, either. Adding any emoji in this story, from basic ones to the Taiwanese or Palestinian flag, makes it impossible to save or publish the story. I have no idea if this is a WordPress issue, or an issue on our end, since WordPress does mention they have emoji support.

Since a number of GTK developer came together at FOSDEM, the project figured now was as good a time as any to give an update on what’s coming in GTK. First, GTK is implementing some hard cut-offs for old platforms – Windows 10 and macOS 10.15 are now the oldest supported versions, which will make development quite a bit easier and will simplify several parts of the codebase. Windows 10 was released in 2015 and macOS 10.15 in 2019, which are fair cut-off points, in my book.

GTK 4.18 will also bring major accessibility improvements with the AccessKit backend, giving GTK accessibility features on Windows and macOS for the first time, which is great news. Another major new feature is the new Android backend, which, while not yet complete, will allow you to run GTK applications on Android. Do note that this is experimental, so don’t expect everything to work without any issues quite yet.

Lastly, the news that everyone was freaking out about over the weekend: the X11 backend has been deprecated, and will be removed in GTK 5. This freaked a lot of people out, but note that this doesn’t mean you magically can’t use GTK 4 applications on X11 anymore – it merely means that X11 support will be removed in GTK 5, which doesn’t even exist yet, and with GTK 4 being supported until GTK 6 is released, people using legacy windowing systems like Xorg will be fine for a long time to come.

As the GTK project notes on Fedi:

The X11 backend being deprecated mainly means that we’re not going to spend time implementing new features, like dmabuf, graphics offloading, or Vulkan support. X11 support will still exist until GTK4 is EOL, which will happen once GTK *6* is released. We’re talking about a 20 years horizon, at this point…

[…]

Of course, somebody could show up tomorrow, and implement everything that the Wayland backend does, but for X11. We can always undeprecate things. We are not holding our breath, though…

↫ The GTK project on Fedi

This is the right move, and I’m glad the GTK project is doing this, and is giving everyone ample time to prepare. A lot of people will still freak out, get mad, and scream bloody murder at certain individuals in the wider Linux community, and those people are, of course, free to start working on Xorg. Like the GTK developers, though, I’m not holding my breath, because despite years of excessive Wayland hate, not a single person has stood up to do the work required to keep Xorg going.

You might expect PDF files to only be comprised of static documents, but surprisingly, the PDF file format supports Javascript with its own separate standard library. Modern browsers (Chromium, Firefox) implement this as part of their PDF engines. However, the APIs that are available in the browser are much more limited.

The full specfication for the JS in PDFs was only ever implemented by Adobe Acrobat, and it contains some ridiculous things like the ability to do 3D rendering, make HTTP requests, and detect every monitor connected to the user’s system. However, on Chromium and other browsers, only a tiny subset of this API was ever implemented, due to obvious security concerns. With this, we can do whatever computation we want, just with some very limited IO.

↫ LinuxPDF GitHub page

I’m both impressed and concerned.