fidzu : Operating Systems

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

20 Jun 2025 10:10pm GMT

The lone volunteer maintainer of libxml2, one of the open source ecosystem's most widely used XML parsing libraries, has announced a policy shift that drops support for embargoed security vulnerability reports. This change highlights growing frustration among unpaid maintainers bearing the brunt of big tech's security demands without compensation or support. Wellnhofer's blunt assessment is that coordinated disclosure mostly benefits large tech companies while leaving maintainers doing unpaid work. He criticized the OpenSSF and Linux Foundation membership costs as a financial barrier to single person maintainers gaining additional support. ↫ Sarah Gooding The problem is that, according to Wellnhofer, libxml2 was never supposed to be widely used, but now every major technology company with billions in quarterly revenue are basically expecting an unpaid maintainer to fix the security issues - many of which questionable - they throw his way. The point is that libxml2 never had the quality to be used in mainstream browsers or operating systems to begin with. It all started when Apple made libxml2 a core component of all their OSes. Then Google followed suit and now even Microsoft is using libxml2 in their OS outside of Edge. This should have never happened. Originally it was kind of a growth hack, but now these companies make billions of profits and refuse to pay back their technical debt, either by switching to better solutions, developing their own or by trying to improve libxml2. The behavior of these companies is irresponsible. Even if they claim otherwise, they don't care about the security and privacy of their users. They only try to fix symptoms. ↫ Nick Wellnhofer It's wild that a library never intended to be widely used in any critical infrastructure is now used all over the place, even though it just does not have the level of quality and security needed to perform such a role. These are the words of Wellnhofer himself - an addition to the project's readme now makes this point very clear, and I absolutely love the wording: This is open-source software written by hobbyists, maintained by a singlevolunteer, badly tested, written in a memory-unsafe language and full ofsecurity bugs. It is foolish to use this software to process untrusted data.As such, we treat security issues like any other bug. Each security reportwe receive will be made public immediately and won't be prioritized. ↫ libxml2's readme If you want libxml2 to fulfill a role it was never intended to fulfill, make it happen. With contributions. With money. Don't just throw a whole slew of security demands a sole maintainer's way and hope he will do the work for you.

20 Jun 2025 7:35pm GMT

rou2exOS is a 64-bit DOS-like operating system (OS). The system is mainly written in Rust, but some portion of x86 assembly is used as well (inline + freestanding code for the stage2 kernel loading). ↫ Blog post about rou2exOS at blog.vxn.dev It can do basic VGA operations, comes with a very barebones networking stack, realtime clock support, a FAT12 driver, and a few more tidbits. It's a rewrite of the previous iteration of the hobby operating system.

20 Jun 2025 7:15pm GMT

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

19 Jun 2025 6:20pm GMT

With the possibility that Google is going to make some big changes to the open source status of Android, the importance of smartphones that don't run either iOS or (some form of) Android is definitely increasing. Linux on smartphones is not as complete as iOS or Android, and I personally think one of the primary reasons for that is a lack of easy access to devices that don't require manual installation or other forms of hackery, only to then end up with a partially supported device because the device in question was never originally designed to run regular Linux. A few companies are trying to change this, developing Linux-first smartphones instead. One of the newcomers here is Liberux, a Spanish company who just unveiled the crowdfunding campaign for their Liberux Nexx, a Debian-powered smartphone with excellent specifications and some unique additions you won't find on any other smartphone. It's powered by an octa-core Rockchip RK3588S (four Cortex-A76 cores and four Cortex-A55 cores up to 2.4 GHz), 32 GB LPDDR4x RAM, tons of expendable storage, and a 6.34″ 2400×1080 OLED display. At the top of the device sit something you won't find on many other smartphones: dedicated hardware switches to physically cut power to the modem, Wi-Fi/Bluetooth chip, and the microhone/camera array. When all three switches are disabled, a number of other features, like GPS and sensors, are also turned off. On top of all this, various internal components are designed to be replaceable and possibly even upgradeable, with manufacturing of the device taking place in Europe - which probably refers to assembly, but still. The device is supposed to become open source, too. It will run Debian 13 with a customised version of the mobile GNOME Shell using a standard Linux kernel. Android applications will also be supported using Waydroid, which you'll most likely have to rely on for things like banking and other application categories exclusive to iOS and Android. Liberux promises that any development done on both the Linux distribution and other related applications will be done openly, which is something we can hold them to quite easily. I'm always weary of crowdfunding campaigns, and all the usual caveats, warnings, and concerns still apply here. I'm highlighting this campaign because I feel like many of the kinds of people who read OSNews are longing for a modern, capable smartphone that runs not iOS or Android, but proper Linux, even if Linux on smartphones isn't quite there yet to go toe-to-toe with the two duopolists. For more information on the device and the people involved, be sure to read LINMOB.net's excellent interview with Liberux. Liberux has told me they want to send over a review device once development has reached a point where that's possible. So, assuming the crowdfunding campaign is successful, you can look forward to a review of the Liberux Nexx on OSNews somewhere between now and mid-2026.

18 Jun 2025 9:51pm GMT

Kian Bradley was downloading something using BitTorrent, and noticed that quite a few trackers were dead. Most of the trackers were totally dead. Either the hosts were down or the domains weren't being used. That got me thinking. What if I picked up one of these dead domains? How many clients would try to connect? Kian Bradley It turns out the answer is a lot.

18 Jun 2025 7:20pm GMT

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

18 Jun 2025 7:16pm GMT

A new version of Plasma is here, and it feels even more like /home, as it becomes smoother, friendlier and more helpful. Plasma 6.4 improves on nearly every front, with progress being made in accessibility, color rendering, tablet support, window management, and more. ↫ KDE Plasma 6.4 release announcement KDE Plasma 6.4 comes with a big improvement in window and virtual desktop management, allowing you to create entirely custom tiled configurations per virtual desktop. Accessibility was another focus of this release, as we talked about a few weeks ago, bringing number pad mouse pointer navigation, improved desktop zoom, screen readers improvements, better contrast i the dark theme, tons of little legibility improvements across the desktop environment and its applications, and more. Furthermore, there's now finally a dedicated page in Settings for animations, so you no longer have to dig your way through the oddly placed and obtuse Desktop Effects page. Notifications have been improved as well, with new additions like a speed graph in file transfer notifications or Plasma notifying you when you're trying to use a muted microphone input. KRunner can now visualise colours when searching for a hex code, Spectacle has received some love, various widgets have been touched up, and much more. There's a brand new HDR wizard, support for Extended Dynamic Range, and the addition of the P010 video color format. System Monitor will now show usage information for Intel and AMD GPUs, and Info Center will show raw sensor data from the sensors in your device. There's a ton more, as this is a fairly major release. You can download and compile KDE Plasma 6.4 now, or just wait a few days until it lands in your distribution's repository.

17 Jun 2025 12:44pm GMT

I hate how these months keep going down like vodka-martinis on an Italian beach, but at least we get another progress report for Haiku every time. Aside from the usual small changes and bug fixes, the most important of which is probably allowing the EXT4 driver to read and write again, there's this little paragraph at the end which definitely stands out. This month was a bit lighter than usual, it seems most of the developers (myself included) were busy with other things… However, HaikuPorts remained quite active: most months, at this point, there are more commits to HaikuPorts than Haiku, and sometimes by a significant margin, too (for May, it was 52 in Haiku vs. 258 in HaikuPorts!). I think overall this is a sign of Haiku's growing maturity: the system seems stable enough that the porters can do their work without uncovering too many bugs in Haiku that interrupt or halt their progress. ↫ Haiku activity report for May I definitely hope that this positive read is correct, as it would be a shame for the project to run into declining activity and contributions just as it seems to be serving as a solid base for quite a wide variety of applications. I've definitely been seeing more and more people giving Haiku a try lately and coming away impressed, but of course, that's just anecdotal and I have no idea if that means Haiku has reached a certain point of maturity. One thing that definitely does indicate Haiku is a lot more stable and generally usable than most people think is the massive amount solid ports the platform can handle, from Firefox to LibreOffice, and everything in between. I think a lot of people would be surprised by just how far they can get with their day-to-day computing needs with Haiku, assuming their hardware can boot Haiku and is properly supported, of course. My opinion on Haiku has not changed, but I'm a random idiot you shouldn't be listening to. The cold and harsh truth is that old people like me who want their BeOS boomerware but in 2025, are a small minority who are impossible to please. The Haiku team's focus on getting modern software ported to Haiku, instead or trying to convince people to code brand new native Haiku applications, is objectively the correct choice to ensure the viability of the platform going forward. If Haiku wishes to fully outgrow its hobby status, looking towards the future is a far better approach than clinging to the past, and unsurprisingly, Haiku's developers are more than smart enough to realise that.

17 Jun 2025 12:21pm GMT

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

16 Jun 2025 9:34pm GMT

A new image loading machinery, called glycin, has been in the works for a while. It is already used by GNOME's default Image Viewer (Loupe), as well as by a bunch of other apps. Glycin provides many security benefits over existing solutions due to the use of the Rust programming language and sandboxing. Distributions will now be able to use the security benefits and broader format support of glycin for other GNOME apps, thumbnailers, and GNOME Shell, whithout changing any existing software. This is made possible by a new option for GNOME's legacy image-loading library, GdkPixbuf, to use glycin internally. ↫ Sophie Herold Clearly, this is an improvement over the previous image loading library, but there's a bit of a catch that is in line with GNOME's increased reliance on systemd features: glycin only works on Linux due to its sandbox mechanisms and how it communicates with its loaders. However, there's no need to fret this time, and that's why I'm posting this item - you just know this tiny little tidbit will find their way into internet discussion forums and social media as another example of GNOME not caring about non-Linux users. While some of the sandboxing and communication features in glycin can be made to work on the BSDs and perhaps macOS, it won't be perfect. As such, great care has been taken to ensure non-Linux platforms can continue to use GdkPixbuf just fine, since support for other platforms is part of the goals of this change before traditional loaders are removed. As a general solution for other platforms, I am planning a mechanism to compile the loaders into the library. This will not provide sandboxing and format extendability without recompilation. But since most loaders are written in Rust, this is still a huge step-up security wise. Contributions for support on other platforms are welcome. For GdkPixbuf users, this will not pose an immediate issue since traditional gdk-pixbuf loaders are not going away until all platforms it supported, are supported by glycin. ↫ Sophie Herold There are a few other issues, as any change like this tends to cause, like the list of supported images formats. Glycin supports AVIF, BMP, DDS, Farbfeld, QOI, GIF, HEIC, ICO, JPEG, JPEG XL, OpenEXR, PNG, PNM, SVG, TGA, TIFF, and WEBP out of the box, but some of the subformats within each of these might potentially not work entirely correctly due to incorrect implementations by, say, camera manufacturers. A special case here is the TIFF format, which apparently still has a number of issues and might end up relying on a fallback. Glycin brings a ton of benefits, such as improved colour support for things like HDR and wider colour gamut displays, better metadata support, basic image editing functions out of the box, increased performance, as well as the benefits inherent in using a memory-safe language like Rust.

16 Jun 2025 9:24pm GMT

Recently, a Reddit user discovered a rare RCA Spectra 70/35 computer control panel from 1966 in their family's old collapsed garage, posting photos of the pre-moon landing mainframe component to the "retrobattlestations" subreddit that celebrates vintage computers. After cleaning the panel and fixing most keyswitches, the original poster noted that actually running it would require "1,500lbs of mainframe"-the rest of the computer system that's missing. ↫ Benj Edwards at Ars Technica Apparently, no photos of this panel existed online, and it may be one of the few - if only - 'surviving' example of such a panel. Of course, it's effectively useless without all of the other chunks that make up the entire Spectra mainframe, but it's still an interesting find. The person who found it intends to turn it into what is essentially a piece of home decor, but maybe we'll get lucky and someone else out there who has been collecting parts and pieces to assemble a working RCA Spectra 70/35 can do something more productive with it.

16 Jun 2025 9:04pm GMT

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

15 Jun 2025 9:10pm GMT

Since Void Linux uses a rolling release model, there's not much to report on in the form of new releases and major new features, so I'm taking the release of version 0.60 of XBPS, Void Linux' package manager, to cheat my way into talking about this excellent Linux distribution. I always think of Void as the "BSD of Linux distributions", which should give you some vague hint as to what it's going for. XBPS 0.60 doesn't come packed with major new features either, and mostly fixes a ton of bugs, addresses few memory leaks, and changes the way held dependencies and directory removal/creation works when reinstalling a packages, just to name a few. There's also some performance improvements, as there were apparently some problems in that department due to the increasing number of virtual packages in the Void repository. If you're looking for a more traditional, hands-on Linux distribution, Void is an excellent choice. It's my back-up for if (let's face it: when) Fedora messes something up.

15 Jun 2025 9:01pm GMT

Disk images have been valuable tools marred by poor performance. In the wrong circumstances, an encrypted sparse image (UDSP) stored on the blazingly fast internal SSD of an Apple silicon Mac may write files no faster than 100 MB/s, typical for a cheap hard drive. One of the important new features introduced in macOS 26 Tahoe is a new disk image format that can achieve near-native speeds: ASIF, documented here. This has been detailed as a major improvement in lightweight virtualisation, where it promises to overcome the most significant performance limitation of VMs running on Apple silicon Macs. However, ASIF disk images are available for general use, and even work in macOS Sequoia. This article shows what they can do. ↫ Howard Oakley Exactly what it says on the tin.

13 Jun 2025 9:34pm GMT

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

12 Jun 2025 6:08am GMT