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.
Wonder why link that’s supposed to send one to “Cosmoe is back” article sends one to “A $100,000 Bet on Windows” article instead…
> link that’s supposed to send one to “Cosmoe is back” article
I agree. This is the correct one, I think:
https://www.osnews.com/story/17201/cosmoe-is-back/
It’s always nice to see BeOS content here! Thanks for sharing.
> I’m not entirely sure about the usefulness of running Haiku applications on Wayland on Linux,
Adding the haiku library to linux will ensure linux won’t become irrelevant due to a lack of applications.
Seriously, though: I image that it could lower the threshold for devs to have a gander at creating native haiku software.
I agree. I would think it would help. I would be curious to know if the pervasive threading using in BeOS software would translate to a different kernel. From what I’ve heard, software ported to Haiku is slow because it doesn’t take advantage of the multi-threading.
Flatland_Spider,
I don’t know much about BeOS specificly, but I know that differences between operating systems can complicate 1:1 porting. For example the overlapped IO in windows doesn’t really translate that well on linux. Even POSIX AIO doesn’t translate well on linux without a lot of very heavy lifting by libraries to bridge mismatched APIs. And conversely things like fork don’t translate well on windows.
https://stackoverflow.com/questions/985281/what-is-the-closest-thing-windows-has-to-fork
If you need portable code, your best bet is probably to target a portable framework and let the libraries create common abstractions. But this has the impact of demoting the more unique features an operating system can offer, which seems rather unfortunate for innovation.
The dominance of linux makes it hard for 3rd party innovation to be viable since most devs are compelled to overlook alternative in favor of linux. I guess this gives credence to Mote’s point; supporting Haiku software on linux might mean more devs are willing to target it, although I’m not sure how many.
The threading that Haiku does is no different from threading that Linux kernel or every other modern operating system on the planet uses (Haiku uses “Team”s, which are collections of “Thread”s, but linux kernel uses just “task_struct”). Linux kernel has kernel level threads for 30 years or so? The software is not going to be faster magically. It will work exactly at the same speed. It may appear faster if you use additional threads for redrawing GUI, but in the end you are going to be limited by the algorithm of the main “processing loop”, so a 3D game is not going to work faster because extra threads are there – it may as well be slower, depending on the architecture.
I guess it`s not 3d, but Diablo 2 worked faster on Wine than on native Windows for me. Places that were laggy on XP worked smooth on Wine.
Alfman,
Yes, there will always be subtle differences, and in the long run this might be counter-productive.
But it is always a trade-off.
They can, and will need to spend effort to build a “Haiku on Linux” API layer. (Just like Windows on Linux, or in other words “WINE”). Yet, if there are more changes in the future, they will have to continue playing catch up (due to Kernel, libc, systemd, and/or Wayland incompatibilities).
Yet… this might be interesting. There is a real return. Some Haiku only apps will get more exposure, and might get community support. This might in turn make them better and more up to date instead of playing catch up there.
And of course, this might even help with Haiku design. As in, while implementing these layers, they might find better solutions to their own versions of the same design challenges.
Mote
+1
haha, I love this comment 🙂
You jest, but it’s kinda right.
There’ a lot of debate around QT ports in Haiku, as it’s essentially just porting non-native programs to another OS running the same toolkit.
What Cosmoe is, is the other way round. It essentially turns the Haiku API into a toolkit itself, allowing non-native Haiku apps to run on Linux (and maybe other OSes in the future as well). This is a good thing, as it’ll allow devs to more widely support the BeOS API (due to a larger compatible install base), which itself will fuel Haiku interest and development.
one question though: is it a good GUI toolkit? does it have a chance compared to qt/gtk ? maybe it uses lighter ressources for embedded use. If so it might attract some linux or embedded devs ?
Could there be a haikux distro which would be haiku but with more hardware and software ?
do they intend to port the whole desktop and tracker ?
interesting project !
Nice. Have anyone precompiled binaries of the demo program for Linux? On the main page is a screenshot of the demo-program “Guido – Test the Cosmoe GUI”. Would be nice, if it would existing in precompiled form.
And because Cosmoe will be based on Linux/Wayland it will be possible also run on Windows with WSL2/wslg.
Cool, now we can run a Qt application on top of Cosmoe on top of Wayland on top of WSL2 on top of Windows.
Next updating also BlueEyedOS
http://www.blueeyedos.com/index-old.html
It is hard to see, how fast time is gone.
https://www.osnews.com/story/2106/updates-for-blueeyedos-and-cosmoe/
And with the reactivated BeOS clones, there can also be BeUnited reactivated.
https://beunited.org/
This is very, very cool. I cannot wait to check it out.
If this works well, it could be very good for Haiku as I would be a lot more likely to choose the Haiku API if it allowed me to target the much larger universe of Linux desktop users. I can hear the jokes coming but there are tens of millions of Linux desktop users and popular Linux apps have lots of users. There are not many widely used BeOS or Haiku apps at this point.
I did not get a chance to comment on the recent Hauki article but the Linux kernel is a pretty good base these days for the kind of software that BeOS was built for.
Well, it turns out it was not just Chimera.
I tried to compile on Arch (not Distrobox, and actual Arch host) and it complained that the compiler was not supported (GCC 15.1).
So, I did what I normally do immediately and used a Distrobox of whatever system is preferred. In this case, it says it has been tested on Ubuntu 24.04 ARM. So, I created an Ubuntu 24.04 Distrobox (x86-64). First, many libraries not specified were missing and had to be added. But I got it to build without the code changes required on Chimera. Except, I get the same behaviour as I saw on Chimera–a call to BApplication:::InitData and then abort.
I guess it is possible that it does work on Ubuntu 24.04 ARM. I may try that at some point. For now, I have no more time.
It is an interesting project with lots of commits. I will check-in on it a few months from now. Hopefully it will go better.
AtheOS — now there’s a name I haven’t heard in a long time!
Now that things with X11 are kinda wobbly, I’d like to have the Haiku display
manager and GUI running atop the Linux kernel. Just in case we lose X11 and Wayland becomes shit.