Haiku Archive

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.

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.

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.

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.

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.

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.

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.