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.
The biggest changes last month were a series of commits by waddlesplash, all related to the user_mutex API and the consumers of it. This API is the kernel portion of the implementation of basically anything related to mutexes or locks in userland, including pthread_mutex, pthread_cond, pthread_barrier, unnamed semaphores (via sem_open), rwlocks, and more. It bears some resemblance in concept to Linux’s futex API, but is very different in both design and implementation. This month’s activity report contains a detailed description of what these commits actually entail, but as OSNews regulars will know, I’m not at all qualified to tell you what it all means. Other changes this month that my limited brain can actually comprehend are work done to make Haiku partially buildable using gcc 13, more RISC-V and ARM improvements, and a whole lot more.
As a former BeOS user and fan(atic), I consider myself quite knowledgeable on the subject, but as I was watching the latest Micheal MJD video about BeOS, I learned something new I had never heard of before. It’s common knowledge that Be actively tried to court x86 OEMs to bundle BeOS alongside Windows in a dual-boot configuration. However, these efforts fell apart as soon as Microsoft caught wind of it and Redmond sent representatives to these OEMs to, shall we say, politely discourage them from doing so. I thought this is where this story ended – the OEMs ghosted Be, and no PC with BeOS preinstalled ever shipped. But in his video, Micheal MJD mentions that at least one OEM did actually ship BeOS preinstalled alongside Windows – Hitachi. However, while the company technically shipped BeOS, it still wanted to appease Microsoft’s goons representatives, and so Hitachi just… Disabled the special boot loader that would’ve allowed users to pick BeOS at boot. BeOS was technically installed and took up a part of the hard drive of every one of these machines shipped, but unless you followed a set of detailed instructions posted by Be online, using a BeOS boot floppy, you wouldn’t be able to actually boot into BeOS. Trying to find more information about this, I ended up at the article archive of Scot Hacker, author of, among other things, The BeOS Bible. In 2001, Hacker wrote the post “He who controls the boot loader“, in response to the news that Be had been acquired by Palm: In the 1998-1999 timeframe, ready to prime the pump with their desktop offering, Be offered BeOS for free to any major computer manufacturer willing to pre-install BeOS on machines alongside Windows. Although few in the Be community ever knew about the discussions, Gassée says that Be was engaged in enthusiastic discussions with Dell, Compaq, Micron, and Hitachi. Taken together, pre-installation arrangements with vendors of this magnitude could have had a major impact on the future of Be and BeOS. But of the four, only Hitachi actually shipped a machine with BeOS pre-installed. The rest apparently backed off after a closer reading of the fine print in their Microsoft Windows License agreements. Hitachi did ship a line of machines (the Flora Prius) with BeOS pre-installed, but made changes to the bootloader — rendering BeOS invisible to the consumer — before shipping. Apparently, Hitachi received a little visit from Microsoft just before shipping the Flora Prius, and were reminded of the terms of the license. Be was forced to post detailed instructions on their web site explaining to customers how to unhide their hidden BeOS partitions. It is likely that most Flora Prius owners never even saw the BeOS installations to which they were entitled. So clearly, this information has been out there since at least 2001 – I had just never heard of it. There’s countless references to Hacker’s article out there as well, so it’s not like it’s some deeply hidden secret nobody was aware of. I, of course, dove into our own archives and… For the love of KDL, we even linked to Hacker’s article. I wasn’t working for OSNews at the time – this was about 4-5 years before I came on as Managing Editor – but I find it highly entertaining this was already part of OSNews lore. In any event, I’m wondering if this makes Hitachi the only OEM to have ever shipped a computer with BeOS preinstalled. Several Mac clone makers put a BeOS installation CD in the box of their machines, but I don’t think any of them ever shipped machines with BeOS preinstalled. Even if they did, Hitachi would still be the only x86 OEM to have ever shipped BeOS preinstalled, and that, too, is incredibly noteworthy. 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. We really need to find a working example of a Hitachi Flora Prius with BeOS preinstalled. We need to image its hard drive for posterity on Archive.org, and I want to see it running – either on YouTube or in real life, I don’t care. This is a piece of computing history that needs to be preserved.
A few months after my contract with Haiku, Inc. began, I rewrote the implementation of the Haiku kernel’s condition variables (as opposed to our userspace condition variables, which are from POSIX.) As this new implementation has run in Haiku for over a year and shipped in the latest release with no sign of any remaining issues, I figured it is high time for a deep-dive on the API, its implementation history, and the design of the new implementation I wrote. I expect this article will be of broader interest than just to Haiku’s community, because Haiku’s condition variables API has some notable (and powerful) features not found in those of other operating systems, and its implementation is thus likewise unique (at least, as far as I have been able to figure out.) I’m currently working on a “state of Haiku” sort of article, and I’m incredibly impressed with just how stable, fast, full-featured, and usable Haiku has become on real hardware. I’ve always kept an eye on Haiku in virtual machines, but now I’m running it on real hard hardware – where it belongs – and it’s been an absolute joy. The fact that waddlesplash managed to pull off this switch basically without any issues and with few people noticing, is further illustration the project’s in a good place.
Java technology has been moving forward much faster in recent years with more frequent updates. Java 17 Long Term Support (LTS) was introduced in September 2021 and will be followed by Java 21 LTS in September 2023. With HaikuDepotServer (HDS) still on Java 11 introduced in September 2018, it was time to upgrade to 17 and then also make the transition from Spring 5 to SpringBoot 3 which was released in November 2022. Spring is a base technology for SpringBoot with SpringBoot providing more configuration and functionality by convention. These upgrades will bring HDS up to date with the current state of the art in backend Java and allow HDS to be maintained more easily going forward. An interesting look at the steps taken during this upgrade process. There’s also a brand new Haiku activity report with tons and tons of fixes, new features, and updates.
The way Haiku handles package management and its alternative approach to an “immutable system” is one of those ideas I find really cool. Here’s what it looks like from a desktop user’s perspective – there’s all the usual stuff like an “app store”, package updater, repositories of packages and so on. It’s all there and works well – it’s easily as smooth as any desktop Linux experience. However, it’s the implementation details behind the scenes that make it so interesting to me. Haiku takes a refreshingly new approach to package management. A deep dive into Haiku’s surprisingly robust and full-featured package management system.
The fourth beta for Haiku R1 over a year and a half of hard work to improve Haiku’s hardware support and its overall stability, and to make lots more software ports available for use. Over 400 bugs and enhancement tickets have been resolved for this release. There’s a lot here to talk about. The improved support for HiDPI looks amazing, and definitely a must-have in today’s world of 4K displays. There’s lots of new and improved drivers, including a new compatibility layer for OpenBSD WiFi drivers, a new NTFS driver, and more. The number of ports has increased by a lot thanks to X11, Gtk+, and even Wayland compatibility – Inkscape, GIMP, GNOME Web, and more. Wine has also been ported to Haiku, using a Haiku-native windowing and input backend. And much, much more. Pretty good way to start Christmas.
Tonight’s story time: the Power Macintosh that wouldn’t make any sound in BeOS R5, how I figured out the problem, and how I hacked the sound driver to fix it. OSNews bait, 100%.
This is a real 133MHz BeBox running otherwise stock BeOS R5, surfing Hacker News and Lobste.rs using a modified, bug-fixed NetPositive wired to offload encryption to an onboard copy of Crypto Ancienne (see my notes on the BeOS port). NetPositive is the only known browser on the PowerPC ports of BeOS — it’s probably possible to compile Lynx 2.8.x with BeOS CodeWarrior, but I’ve only seen it built for Intel, and Mozilla and Opera were definitely Intel/BONE-only. With hacks for self-hosted TLS bolted on, NetPositive’s not fast but it works, and supports up to TLS 1.2 currently due to BeOS stack limitations. This is a modified version of the latest official NetPositive browser from Be, updated to somewhat work on the modern web, specifically for PowerPC machines like the BeBox and BeOS-compatible PowerPC Macs. It can load various modern sites, but as the author notes, OSNews refuses to load (we used to have a complicated system of recognising individual obscure platforms and browsers so we could serve them a limited version of the site, but that became increasingly difficult and time-consuming to maintain, for effectively no benefit other than bragging rights). You can download and run it using the instructions in the post, and more improvements are being considered. Absolutely excellent work.
The latest Haiku activity report has been published, and this one is heavy on the driver work. The intel_extreme driver has received quite a bit of love, and Haiku now has an RNDIS USB ethernet driover, which Android uses to share its WiFi connection, so you can now use an Android phone’s hotspot to get Haiku online (only a few devices have been tested so far, though. Another big improvement is the overhauled MTU. waddlesplash overhauled MTU (“maximum transmission unit”) and also receive size handling in the network stack and the FreeBSD compatibility layer. Previously, we always stayed at the default ethernet MTU of 1500, which was fine but suboptimal (as ethernet can usually support jumbo frames up to size 9000 or so), but more problematic was that we could not handle receiving anything larger than this, as it would trigger errors in the ethernet handler related to scattered I/O operations. This required a number of changes: first to the stack itself and to the IPv4 & IPv6 handlers to check the correct MTU value, then to the ethernet module to use larger buffers if necessary when reading or writing data, and finally to the FreeBSD compatibility layer to activate the larger MTUs. These changes had a side effect of fixing “high packet loss” on some devices (or at least PulkoMandy’s very recent Intel ethernet device, anyway.) This is just a small selection – there’s tons more, such as further improvements to the ARM and RISC-V ports, the addition of the OpenBSD WiFi stack to further widen Haiku’s WiFi driver pool, and tons more.
The latest Haiku activity report is here – covering the month of March – and it’s a real grab bag of tons of changes, but I’m not seeing any big ticket items. This means there should be something for everybody in here, from improved support for various Intel integrated grahpics chips, to more work on the ARM port, to glibc fixes, to… Well, you get the point.
Haiku’s latest activity report is out, and right off the bat, there’s a big ticket item. That’s right, after many years of being requested, Haiku finally has support for USB WiFi devices! (Currently only Realtek controllers are supported, but Ralink and others should follow before too long; Realtek/“RTL” chips are generally the most common, however.). That’s great news. There’s way more in here than just this, of course, so head on over to find out more.
Haiku’s latest activity report is here, and while there’s a lot of stuff in there – as usual – I think the Gtk work stands out this month. After all that work, GTK3 worked “well enough” that it seemed ready for general consumption (or at least testing), so waddlesplash committed the necessary changes to HaikuPorts for Xlibe to be packaged, and then GTK3, and then finally the first GTK3 application: Inkscape. Already, GIMP has followed closely on its tail thanks to 3dEyes (with some quick fixes to Xlibe done by waddlesplash for it), and more GTK3 applications are sure to follow once the HaikuPorts team gets caught up to speed on things. You can find screenshots on the forums of both GIMP and Inkscape running on Haiku. With that, waddlesplash has deemed the “GTK3 porting adventure” complete, and has returned to development work on Haiku’s core for this coming month. That’s a lot of progress, and two great applications to have running on Haiku.
Haiku continues to be on its roll, this time making tons of progress porting Wine to run on Haiku. Rockstar Haiku developer X512 has managed to not just start porting Wine to Haiku, but also to get so far as to run actual Windows applications on the platform. The screenshots in the Haiku forum thread speak for themselves. This is amazing work, and I can’t even begin to imagine how so much progress can be made in such short time. That being said – and the reason I’m late with this story – I’m not entirely sure porting things like Qt, X.org, and Wine are the best way forward for Haiku. As an old BeOS nerd, what I want are fully native, platform-optimised Haiku applications that make use of all the unique features the operating system has to offer. I’m not interested in yet another platform to run Qt applications, LibreOffice, and a small handful of Windows applications. I really don’t like being a grumpy old man when it comes to relatively small, alternative projects whose members code for free, but none of the recent amazing news coming out of Haiku has made me more interested in Haiku – in fact, it has only made me less interested, and less enthusiastic. Haiku and BeOS occupy a special place in my heart, and the focus shift from focusing on Haiku as an API-compatible clone of BeOS to yet another platform that runs Qt, X, and a few Windows applications worse than Linux or BSD do is not something I’m particularly thrilled with. But here’s the cool thing – what I think is, and should be, entirely irrelevant, and these developers need to keep doing what they want to do, whether randos like me want them to or not. That’s the nature of open source.