Haiku Archive
Haiku also survived another month of development, so it’s time for another roundup of what they’ve been doing. Considering it’s the height of Summer, it’s no surprise the list of changes is a bit shorter, consisting mostly of smaller bugfixes and minor improvements. A few standout changes are that cursors can now be properly scaled in HiDPI, the iprowifi3945 driver from FreeBSD has been replaced by the OpenBSD one because it performs better, and several improvements to how colour schemes work. waddlesplash refactored how control edge (borders, etc.) colors are computed inside HaikuControlLook (the class that renders UI controls under the default appearance), cleaning up a lot of convoluted computations. He also fixed some color handling in the progress bar control, and then along with nephele, refactored how control colors are used and computed across the system. The “Control background” color in Appearance preferences now has a new default and is much more properly used across the Interface Kit; under the default colors, renderings should be basically the same as before, but for users on “dark mode” or other custom color schemes, it will now be much easier to pick control colors. ↫ waddlesplash on the Haiku website There’s more, of course, so be sure to read the whole thing.
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.
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.
Nvidia releasing its Linux graphics driver as open source is already bearing fruit for alternative operating systems. As many people already knows, Nvidia published their kernel driver under MIT license: GitHub – NVIDIA/open-gpu-kernel-modules: NVIDIA Linux open GPU kernel module source (I will call it NVRM). This driver is very portable and its platform-independent part can be compiled for Haiku with minor effort (but it need to implement OS-specific binding code to be actually useful). This is very valuable for Haiku because Linux kernel GPU drivers are very hard to port and it heavily depends on Linux kernel internals. Unfortunately userland OpenGL/Vulkan driver source code is not published. But as part of Mesa 3D project, new Vulkan driver “NVK” is being developed and is functional already. Mesa NVK driver is using Nouveau as kernel driver, so it can’t be directly used with NVRM kernel driver. NVK source code provides platform abstraction that allows to implement support of other kernel drivers such as NVRM. I finally managed to make initial port NVRM kernel driver to Haiku and added initial NVRM API support to Mesa NVK Vulkan driver, so NVRM and NVK can work together. Some simple Vulkan tests are working. ↫ X512 on the Haiku forums Incredibly impressive, and a huge milestone for the Haiku operating system. It supports any Nvidia GPU from the Turing architecture, which I think means Nvidia RTX 20xx and newer, since they have a required microcontroller older GPUs do not have. Of course, this is an early port and a lot of work remains to be done, but it could lead to huge things for Haiku.
We’ve got the Haiku activity report covering February, and aside from the usual slew of bug fixes and minor improvements, there’s one massive improvement that deserves attention. waddlesplash continued his ongoing memory management improvements, fixes, and cleanups, implementing more cases of resizing (expanding/shrinking) memory areas when there’s a virtual memory reservation adjacent to them (and writing tests for these cases) in the kernel. These changes were the last remaining piece needed before the new malloc implementation for userland (mostly based on OpenBSD’s malloc, but with a few additional optimizations and a Haiku-specific process-global cache added) could be merged and turned on by default. There were a number of followup fixes to the kernel and the new allocator’s “glue” and global caching logic since, but the allocator has been in use in the nightlies for a few weeks with no serious issues. It provides modest performance improvements over the old allocator in most cases, and in some cases that were pathological for the old allocator (GCC LTO appears to have been one), provides order-of-magnitude (or mode) performance improvements. ↫ waddlesplash on the Haiku website Haiku also continues replacing implementations of standard C functions with those from musl, Haiku can now be built on FreeBSD and Linux distributions that use musl, C5/C6 C-states were disabled for Intel Skylake to fix boot problems on that platform, and many, many more changes. There’s also bad news for fans of Gopher: support for the protocol was removed from WebPositive, Haiku’s native web browser.
Haiku is already awash with browsers to choose from, with Falkon (yes, the same one) being the primary choice for most Haiku users, since it offers the best overall experience. We’ve got a new addition to the team, however, as Firefox – in the form of Iceweasel, because trademark stuff and so on – has been ported to Haiku. Jules Enriquez provides some more background in a post on Mastodon: An experimental port of Firefox Iceweasel is now available on HaikuDepot! So far, most sites are working fine. YouTube video playback is fine and Discord just works, however the web browser does occasionally take itself down. Still rather usable, though! If @ActionRetro thought that Haiku was ready for daily driving with Falkon (see first screenshot), then rebranded Firefox surely has to make it even more viable by those standards! It should be noted though that just like with Falkon, some crash dialogs can be ignored (drag them to another workspace) and the web browser can still be used. ↫ Jules Enriquez It’s not actually called Firefox at the moment because of the various trademark restrictions Mozilla places on the Firefox branding, which I think is fair just to make sure not every half-assed barely-working port can slap the Firefox logo and name on itself and call it a day. As noted, this port is experimental and needs more work to bring it up to snuff and eligible for using the name Firefox, but this is still an awesome achievement and a great addition to the pool of applications that are already making Haiku quite daily-drivable for some people. Speaking of which, are there any people in our audience who use Haiku as their main operating system? There’s a lot of chatter out there about just how realistic of an option this has become, but I’m curious if any of you have made the jump and are leading the way for the rest of us. Action Retro‘s videos about Haiku have done a lot to spread the word, and I’m noticing more and more people from far outside the usual operating system circles talking about Haiku. Which is great, and hopefully leads to more people also picking up Haiku development, because I’m sure the team can always use fresh blood.
There’s many ways to judge if an operating system has made it to the big leagues, and one of the more unpleasant ones is the availability of malware. Haiku, the increasingly capable and daily-driveable successor to BeOS, is now officially a mainstream operating system, as it just had its first piece of malware. HaikuRansomware is an experimental ransomware project designed for educational and investigative purposes. Inspired by the art of poetry and the challenge of cryptography, this malware encrypts files with a custom extension and provides a ransom note with a poetic touch. This is a proof of concept aimed to push the boundaries of how creative ransomware can be designed. ↫ HaikuRansomware’s GitHub page Now this is obviously a bit of a tongue-in-cheek, experimental kind of thing, but it’s still something quite unique to happen to Haiku. I’m not entirely sure how the ransomware is supposed to spread, but my guess would be through social engineering. With Haiku being a relatively small project, and one wherein every user runs as root – baron, in BeOS parlance – I’m sure anything run through social engineering can do some serious damage without many guardrails in place. Don’t quote me on that, though, as Haiku may have more advanced guardrails and mitigations in place than classic BeOS did. This proof-of-concept has no ill intent, and is more intended as an art project to highlight what you can do with encryption and ransomware on Haiku today, and I definitely like the art-focused approach of the author.
It’s always a lovely day when it’s a Haiku release day – and sadly, those don’t come very often. Of course, Haiku’s nightlies tend to be rather solid so an official release isn’t really a must if you want to use Haiku, but if you were holding out for something more stable: Haiku has just released its fifth beta, Haiku R1/beta5. We’ve covered most of the new features and changes as they were developed, but since it’s been so long since the previous beta, we should cover some of the highlights. One of the collection of improvements that’s impossible to put in a screenshot is the performance improvements the successor to BeOS has received since the release of R1/beta4, and there are many. There’s a ton of general performance improvements, of course, covering everything from the kernel to applications, including much better throughput in TCP, the network stack, which should lift Haiku’s network performance much closer to that of other, more mature operating systems. There’s also an overhaul of the user_mutex system, and much more. A great many performance optimizations were done to the kernel and drivers, including batching many more I/O operations, avoiding unnecessary locks on application startup, improved pre-mapping of memory mapped files, reduced lock contention in page mapping, batched modification of the global memory areas table (and a different implementation of its underlying data structure), changes to keep page lists in-order to ease allocations, temporary buffer allocation performance improvements in hot I/O paths, support for DT_GNU_HASH in the ELF loader, and more. ↫ Haiku R1/beta5 release notes Looking at the end user side of things, the Appearance dialog has been simplified without removing any features or capabilities, and Haiku now also comes with a dark mode. The little power/battery widget in Deskbar has also been overhauled to provide more accurate battery information, and it’ll load automatically if a battery is detected in the system. Tracker (the file manager) and Icon-O-Matic have seen improvements, there’s a rewritten FAT driver, a brand new UFS2 driver, and much more. There’s also a ton of new application ports from the Qt and GTK world, especially if the last time you’ve tried Haiku was one of the previous betas. Thanks to all of these ports, it’s much more realistic now to use Haiku as a daily driver. Haiku now also offers experimental support for .NET and FLTK, which provides further avenues for ports. This is just a small selection, as there is so much more contained in this new beta release. If you’ve been running the nightlies this new beta won’t mean much to you, but if you’ve been out of the running for a while, Haiku R1/beta5 is a great place to start to see what the platform has to offer.
There’s a new Haiku activity report, and it’s a big one. A lot of bottlenecks and performance issues were addressed recently, and the list is too long and detailed for me to cover everything. Haiku developer Waddlesplash does a great job in this report detailing the various things he worked on to solve some of these bottlenecks and performance issues, and they cover everything from speeding up the readv and writev I/O calls, fixing an issue with the kernel’s device_manager lock, improving ELF symbol lookup by implementing the DT_GNU_HASH hash table, and much more. As part of working on these performance issues, Waddlesplash also fixed up Haiku’s CPU time profiler. Haiku has a built-in CPU time profiler (just called profile.) Unfortunately, it’s been rather broken for years, regularly outputting data that was either empty or just didn’t make any sense. In order to use it to try and track down some of the other bottlenecks, I spent a bunch of time fixing various bugs in it, as well as the debugger support code that it relies on to function, including to stack trace collection, buffer flushing, symbol lookup, scheduler callbacks, image load reporting, and more. I also implemented userspace-only profiling (ignoring kernel stack frames entirely), fixed some output buffer sizing issues, and fixed a race condition in thread resumption that also affected strace. While it isn’t perfect, it’s much better than before, and can now be used to profile applications and the kernel to see where CPU time is being spent; and notably it now checks the thread’s CPU time counters to detect if it “missed” profiling ticks, and if so how many. ↫ Haiku’s website Beyond these performance fixes, there’s a ton of other improvements and fixes, from better handling of HiDPI displays in HaikuDepot, improvements to CharacterMap, fixing subtitles in MediaPlayer, and tons more. Of course, there’s the bevy of driver fixes, including a major overhaul of the FAT driver, which was still largely based on old, original BeOS code because Be used the FAT driver as sample code. Haiku’s FAT driver is now based on FreeBSD’s FAT driver, which addressed a whole slew of issues. This isn’t even all of it – there’s so much more in this month’s activity report, so definitely head on over and give it a read.
Haiku, the platform grossing in ported browsers while its native WebPositive browser languishes, has added another notch to its belt – and this time, it’s a big one. Firefox has been tentatively ported to Haiku, but it’s early days and there’s no package ready to download – you’ll have to compile it yourself if you want to get it running. It’s version 128, so it’s the latest version, too. Without the ability to easily test and run it, there’s not much more to add at this point, but it’s still a major achievement. I hope there’ll be a nice Haiku package soon.
So I got accepted into GSoC again! I’m going to be working on WebKit2. But what is WebKit2, or even WebKit, for that matter? Well, WebPositive uses WebKit to render its web pages. Currently, we use the WebKitLegacy API to communicate with WebKit. It would be nice to switch to the newer version: WebKit2. However, our port of WebKit2 still needs work. At present, it has lost its ability to even render any webpage at all! So, getting WebKit2 to work will be the primary goal of my GSoC project. If there’s time left, I might be able to integrate it into WebPositive. The advantages WebKit2 has for WebPositive will be mostly invisible to end-users. The code will hopefully be more maintainable than the deprecated WebKitLegacy and we’ll get access to several newer APIs such as the ad-blocking API. Perhaps the most visible change: problems in one part of the code should be less likely to crash the whole browser. ↫ Zardshard on the Haiku website The current state of WebPositive, the only native Haiku web browser, is emblematic of why I have personally lost all interest in the successor to what is still my favourite operating system of all time. Haiku OS supports several browsers, and if you read any forum post about which browser to use, or watch any of the enthusiastic Haiku videos by the insanely awesome Action Retro, they’ll all advise you to use any of the non-native Qt or GTK browsers instead – because WebPositive just can’t compete with the ported, non-native browsers. Since everybody using Haiku is opting to use the better ported browsers, WebPositive has fallen even more by the wayside; now it has to play catch-up, and by the time WebKit2 has been properly ported and bug-tested, and has been integrated into WebPositive, which then has to be bug-tested as well, we’re going to be months, if not years, down the line. In the meantime, the ported browsers will have been regularly updated with newer, better versions. Unless the focus for the single most important application of any general purpose desktop operating system is placed solely on WebPositive, it simply won’t be able to keep up with the ported browsers. Why even work on WebPositive at all at that point? It’s not like anyone is using it, so why bother? And this highlights a problem for people like me, who prefer to have native Haiku applications instead of ports of software I can already run elsewhere. As a former BeOS user, I am not interested in a vessel for running Qt applications that I can, in all likelihood, run better on Linux. Why would I go through the trouble of assembling a machine with hardware Haiku supports, only to then run the same applications I’m already running on Fedora or OpenBSD, but worse? If you browse through Haiku Depot today, it feels like the vast majority of modern, maintained, and working software are ports of Qt (and GTK) software we already know and love from other, more mature, more stable, more usable, and more feature-rich platforms. Haiku has chosen to pour a lot of energy and manpower into becoming an operating system designed to run ported, often Qt, applications, but the downside to that is that new and maintained native Haiku applications, that play to the strengths of the platform, are few and far between. A Haiku developer once told me that real people use Haiku every day, and they need real applications, and ported applications make it possible for not only Haiku developers themselves, but also normal users, to run and use Haiku every day. This is a valid argument that I fully understand and agree with – it just means Haiku isn’t for me. And while that’s sad for me, it’s entirely fine. Haiku’s developers have chosen to focus on building a daily-drivable operating system with tons of ported applications, instead of an ideologically pure operating system you can’t really use because it only has like 4 native applications and nothing else. And that’s a valid, smart, and practical choice that I fully respect and understand, even if it means Haiku isn’t really a BeOS successor anymore.
Genio, the Haiku OS integrated development environment (IDE), is receiving another exciting update in preparation for the upcoming summer release. The update focuses primarily on improving the Language Server Protocol (LSP) stack and introduces a cool new feature: Symbol Outline. Symbol Outline allows Genio to retrieve the list of symbols defined in a source file from the language server. This list can be sorted, nodes can be expanded or collapsed, and now a symbol can be renamed directly from there. Being part of the standard LSP specification, Symbol Outline should be supported by all language servers. The development team has tested it with clangd and OmniSharp. ↫ Andrea at Desktop on fire! Improvements to tools to develop truly native Haiku applications are exceptionally welcome, if only to prevent Haiku from becoming a worse way than Linux to run Qt applications.
Haiku published its latest monthly activity report, and this one is a veritable grab bag of a whole bunch of small fixes, improvements, and changes – there’s really no tent pole features or major improvements this month. Going through the list, the items that jump out at me are updated ping and traceroute applications and work on improving FFmpeg, but there’s so much more in there, so be sure to read the whole thing. At the end of the report, the Haiku project states about a possible fifth beta release: A few more tickets in the milestone were fixed, including the “ICU upgrade” one, but a few were also added (some migrated from HaikuPorts that turned out to be regressions in Haiku or its buildtools, etc.). ↫ Haiku Activity and Contract Report, February 2024 So, beta 5 is not quite ready for prime time just yet, but it feels like it’s getting closer.
Haiku developer and community member Waddlesplash shares his insights on the project’s current state, challenges ahead, and hopes for the future. Waddlesplash discusses Haiku’s transition from a niche project to a potential daily driver OS, emphasizing the importance of maintaining momentum and addressing data corruption bugs. ↫ Andrea at Desktop On Fire! Haiku is definitely in a good place at the moment, and there’s some real momentum from outside the project. Yes, it’s even possible to daily-drive Haiku – with caveats, of course – and I hope they can keep this going.
Does anyone here remember Cosmoe? Cosmoe was an attempt to combine Haiku’s API with the Linux kernel and related tools, started in the early 2000s. The project eventually fizzled out, now only an obscure footnote for BeOS diehards such as myself. It seems, though, that the idea of combining the Haiku API with a mature UNIX-like operating system refuses to die, and a few days ago, on the NetBSD Users’s Discussion List, a developer by the name of Stephan picked up the baton. Some years ago I already started to work on a compatibility layer for NetBSD and resumed working on it recently. I think a compatibility layer would mostly consist of kernel components and a custom libroot.so. I have created a libroot that provides functionality missing in libc and it should behave like the original one. It makes use of libc and libpthread at the moment as well as syscalls of the kernel components. The source can be found on Github. This is clearly an experimental project, but Stephan does note he has had success running the Haiku IPC test programs, so it’s definitely more than scribbles on a napkin. The attraction of this idea is clear, too – Haiku API, but on a stable kernel with vastly superior hardware and device support. I’m not entirely sure if it’s got life in it, but even if it doesn’t – it’s amazing work, and that in an of itself makes it a success.
A few months ago, I talked about the only PC ever shipped with BeOS preinstalled, the Flora Prius from Hitachi. However, due to illegal pressure from Microsoft, Hitachi disabled the special bootloader required to boot into BeOS, so while the best operating system ever made was right there on the hard drive, buyers couldn’t actually use it without manually restoring the bootloader and BeOS partitions. Of course, I now have to try and find a working example of this Hitachi Flora Prius computer line. They were apparently only sold in Japan, so the odds of finding one anywhere seem slim, at best. It doesn’t help that most people who bought one of these had no idea BeOS was installed or what BeOS even was, so the historical significance was lost on them. I also think these weren’t particularly noteworthy computers otherwise – most likely one of the many dime-a-dozen beige boxes sold all over the world. Searches on eBay and Japanese auction sites yield no results. I got an e-mail today from an OSNews reader, informing me of something quite rare. On the Japanese auction site mercari.com, someone is selling a BeBox, which in and of itself is already a very rare occurrence, as few BeBoxen were ever sold (1800 in total). To further add to the rarity, it’s the dual 133 MHz model, which is the rarer of the two configurations (800 pieces sold). These machines don’t come up for sale very often, and I’m pretty sure the seller is going to net a good price for this museum piece, which seems to be in almost pristine condition, without scratches of scuffs. The price is set at ¥950000 (€5821) excl. shipping (shipping costs to e.g. Europe or the US would be substantial), but I’m pretty sure the seller could ask for more. Seeing a BeBox for sale is already quite exciting, but browsing through the accompanying pictures, there’s something even rarer: documentation and software CD-ROMs for the Hitachi Floria Plus 330j and BeOS. The machine itself is not part of the auction, but even seeing the documentation and CD-ROMs for it is entirely unique, and most likely something we won’t be seeing anywhere else anytime soon. Since the Floria Plus was sold as a generic, uninteresting PC, probably long forgotten and scrapped by most people, I doubt one will ever be found. The documentation and software in this auction might be one of the last surviving tangible relics of the only PC ever sold with BeOS preinstalled.
The latest Haiku activity report is here, covering the month of August, and it’s a massive laundry list of fixes and improvements, but I couldn’t find any major big ticket features or fixes. August also happens to bring the first two final Google Summer of Code reports – porting .NET to Haiku, and improving various parts of Icon-O-Matic, a vector drawing program designed specifically for working with Haiku’s vector icon format. Also of note is that the main Haiku CO is down at the moment, but should be back up soon.
Haiku developer PulkoMandy has released a new version of the BFS Windows driver, fixing some problems. In case you need to access your BFS (and possibly SkyFS, but I can’t test that) partitions from Windows, I just fixed some problems in and made a binary available. With Haiku becoming increasingly useable on a day-to-day basis, tools like these to make the cross-platform life just a bit easier are essential, so I’m glad the Haiku developers are dedicating some time to things like this as well.
A necessary correction to an earlier post: support for Haiku has not been upstreamed into GCC. From the Haiku development mailing list: It is definitely our goal to get Haiku’s GCC toolchain upstream, and that commit does indeed nudge us a little in that direction… However it’s a small portion of a larger commit adding architecture support. Good to have this cleared up.
Developers of the BeOS-inspired Haiku operating system have long been carrying patches for supporting the GNU Compiler Collection (GCC) on their platform while this week the code was upstreamed for GCC 14. This commit to mainline GCC git adds support for the Haiku operating system. Excellent news, and well-deserved.