A number of patches worked on for Haiku OS back for Mesa 20.x were freshened up and with some extra tweaking and code cleaning those patches have now been merged for Mesa 21.0. This includes factoring out a lot of the OpenGL legacy dispatch code and a lot of cleanups around the Softpipe driver handling. With Mesa 21.0-devel as of today, it’s at least enough where Mesa Git can now be built on Haiku OS and yield working OpenGL rendering with the LLVMpipe software. Neat, and a testament to Haiku being in a far better state than many people seem to think.
BeOS & Derivatives Archive
There’s a new Haiku activity report, and there’s been a lot of activity over the past two months. My pick this time is progress on the ARM port. tqh and kallisti5 are working on the ARM port. The bootloader is now running mostly fine in UEFI mode but there is some work to be done to set up the MMU before handing control over to the kernel. There are problems related to the “hardfloat” and “softfloat” ABIs on ARM, however. Until now we had worked with the “hardfloat” ABI for Haiku, assuming floating point hardware was available (as is the case on any modern CPU we could reasonably target). However, the EFI firmware does not properly handle these registers, and this seems to result in some confusion when passing data to and from the firmware. We may need to build the bootloader in soft-float mode (not using the hardware floating point processing), but that in turn creates some difficulties with properly configuring gcc. On 64bit ARM, the floating point support is not optional, so it may be easier to move forward with the 64bit port first. The ARM port is important for the future, since desktop and laptop ARM hardware may become far more available than it is today.
For a long time I have been maintaining the build of the Rust compiler and development tools on Haiku. For this purpose, I maintain a separate tree with the Rust source, with some patches and specific build instructions. My ultimate end goal is to have Rust build on Haiku from the original source, without any specific patches or workarounds. Instead we are in the situation where we cannot build rust on Haiku itself (instead we need to cross-compile it), and we need a customization to be able to run the Rust compiler (rustc) and package manager (cargo) on Haiku. This summer my goal would be to find out the underlying issue, and fix it so that the patch will no longer be necessary in the future. Let’s go! There seems to be quite a bit of excitement around the Rust programming language, so it makes sense for Haiku to jump on the bandwagon as well.
The July activity report from the Haiku project is out, and there’s a lot of stuff in there. My favourite highlight: kallisti5 continued work on the ARM architecture, specifically the ARM64 EFI bootloader. EFI CPU code was refactored to be architecture-specific, allowing CPU init code to be properly called, further progressing the EFI bootloader, which is now building and running. I love the progress on ARM, since ARM seems to have a bright future – Haiku needs to be there.
Software on a computing platform such as Haiku is typically distributed as a package. Without a packaging system it would be hard for users to install software and because software often depends on other software, the chain of dependencies would be difficult for a user to resolve themselves. To orchestrate the distribution and management of the packages, Haiku has a packaging system which consists of applications, online tools, on-host tools and software libraries. One aspect of the packaging system is the coordination and identification of repositories. An overview of the inner workings of package management on Haiku.
Did you ever wonder what BeIA really was? A lot of people talked about BeIA back in the days Be, Inc. was still developing its OS for internet appliances, but after Be, Inc. closed its doors, BeIA vanished as well. A thread over on the Haiku discussion forums – which began as a talking point for how Haiku could recreate a BeIA style concept – turned in to a treasure trove of BeIA information, including examples of BeIA running and an overview of some of the process of building BeIA distributions. This video shows it all in action, including BeIA running under emulation. There’s also a wonderful video shot in Be, Inc’s offices where a Hungarian UG member gets a tour and shown BeIA hardware, with terrible framerate and resolution, but well worth checking out.
After the release of the second beta a few weeks ago, Haiku continues its steady pace of improvements and fixes. A few highlights from the work done since the beta release: Korli also worked on improving support for modern x86 CPUs, including the xsave instruction, and enabling use of AVX which requires saving more CPU registers during context switches. A new version of HaikuWebKit has finally been released after help from KapiX and X512 to fix the remaining bugs. It uses a lot less memory, crashes less often, and has better support for modern website. There is ongoing work for further updates and improvements. There’s a lot more in there, so if you have beta 2 running, be sure to update it.
The second beta for Haiku R1 marks twenty months of hard work to improve Haiku’s hardware support and its overall stability. Since Beta 1, there have been 101 contributors with over 2800 code commits in total. More than 900 bugs and enhancement tickets have been resolved for this release. There’s so many improvements in this new release that it’s hard to pick favourites. Since many Haiku users basically use the operating system on a rolling release basis through online updates, it’s easy to lose track of what’s new between beta and 2. I have a VM for Haiku that I regularly update and use, and it’s remarkable just how stable and fast Haiku has become over the years.
The big news first: a timeline has been set for Beta 2! If all goes well, it will be released by the end of May. Of course, this means everyone has been scrambling for last minute changes this month instead of stabilizing everything. We are now in “soft freeze”, and the branch will be created on Friday. Yes, an actual almost release date for Haiku’s second beta release.
You’re likely familiar with the old tale about how Steve Jobs was ousted from Apple and started his own company, NeXT. Apple then bought NeXT and their technologies and brought Jobs back as CEO once again. However, Jobs’ path wasn’t unique, and the history of computing since then could’ve gone a whole lot different. In 1990, Jean-Louis Gassée, who replaced Jobs in Apple as the head of Macintosh development, was also fired from the company. He then also formed his own computer company with the help of another ex-Apple employee, Steve Sakoman. They called it Be Inc, and their goal was to create a more modern operating system from scratch based on the object-oriented design of C++, using proprietary hardware that could allow for greater media capabilities unseen in personal computers at the time. Not much new information in here for the regular OSNews reader – and these articles get published about once a year – but it’s always nice to see the best operating system of all time get some love.
Paladin, a C++ development IDE for Haiku, has been updated with several new features and bug fixes. Some of the new features: • Quick Find window (Alt+F) – find files in a project by name, or abbreviation (E.g. qfw gives you QuickFindWindow.cpp) • All the Samples from the online Haiku dev book are included as Template Projects • Running applications ‘as logged’ now gives a live Monitor Window showing the streamed contents of stderr and stdout, using a new and reliable posix CommandThread wrapper (a ‘Preview Feature’ that, if popular, may end up back in Haiku proper for others to use) • Automatic switching of Haiku libraries when you open the same project from 32bit and 64bit Haiku versions • Running a build now generates compile_commands.json as used by other software • All new backend functionality now using a TDD approach to improve quality and avoid regressions • User requested modifications are prioritised, with a delivery average of 2 weeks There’s an update video available so you can get a better feel of the new features, and you can download and install Paladin through HaikuDepot. The code’s available under the MIT license at GitHub.
Another month two months have passed, so time for another monthly Haiku update. The biggest improvement this time around: PulkoMandy revisited once again the intel_extreme driver to identify the remaining regressions introduced when adding sandy Bridge support. We believe all problems have been identified and solved, so, if you have an intel graphics card, please test a recent nightly and report on what happens. There’s also a ton of non-x86 commits this time around.
Another month, another Haiku activity report – this time for September. It’s another big one, but if I had to pick one thing to highlight, it’d be this one: Some initial work for ARM64 was completed by kallisti5. This includes setting up the Haikuports package declarations, writing the early boot files, and in general getting the buildsystem going. Jaroslaw Pelczar also contributed several further patches (some of these still undergoing review), providing the initial interrupt handling support, and various stubs to let things compile kallisti5 did some work on 32bit ARM as well, cleaning up some of the code to better match other platforms and preparing the reuse of EFI for ARM and ARM64 (as u-boot now implements an EFI interface, which would make things much simpler for our ARM boot process if we manage to use it). Haiku has been working on ARM support for a while now, and while it may seem like a weird niche distraction for such a small project, it actually makes good, future-proofing sense to spend work hours in this area. ARM is definitely growing in the laptop space, and it makes sense to prepare Haiku for a future wherein ARM laptops are readily available. On top of that, adding support for architectures other than your main one aides in finding difficult to spot bugs, ensures architecture-independent code, and in general is just a fun thing to do for a specific kind of person.
Haiku’s monthly activity report for August has been published, and it’s a big one, so I urge you to read the whole report for all the details on what’s changed, fixed, and new in Haiku over the past month. There should be something for everyone in there. My personal favourite little tidbit is this one, though. Pascal Abresch got the first part of his work to handle “media” keys (play, pause, and other additional keys) recognized by Haiku. The PS/2 driver has been adjusted, but adding all these new keys to the keymap means we now have more than 128 possible keys, which the BeOS keymap format does not allow. So we will need a new one, and this will break compatibility with old apps using the keymap directly (as the API allows). I don’t know why, exactly, this fascinates me so much, but I like the mental image of one of the original BeOS developers, coding for Hobbit development boards, writing the code for keyboard handling, deciding upon the 128 key limit being enough for a long time to come. If only they knew.
Now that Haiku has entered the beta phase, and after the work over the past year or so spent fixing the majority of known kernel crashes and other general instabilities, it is high time we start paying more attention to the whole system’s performance. Despite how “snappy” Haiku seems, most of its internals are really not so well optimized. This shows when running operations of any real intensity (disk, memory, or CPU.) While the new thread scheduler a few years ago removed some of the thread-related bottlenecks, in practice this just shifted the load to other bottlenecks. So, let’s take an overview of this past month’s (and some earlier month’s) changes, to see how one optimizes an operating system. Haiku always feels very fast and snappy, but in reality, many of us have that perception because we tend to not really use Haiku as much as we use Windows or Linux. I’m really glad the Haiku team acknowledges this, and is looking to address low-level performance issues that may not look sexy in a changelog, but that are oh so crucial for the overall feel of the operating system.
Speaking of Travis Geiselbrecht – Haiku has another activity report. He also started benchmarking the uses of the allocator and found various opportunities to save memory, and use dedicated object caches instead of the generic malloc allocator, helping reduce memory fragmentation. The first patches have just started to land (in packagefs), there will likely be more. Ideally beta2 will be able to boot and install with 256MB of RAM or maybe even less thanks to this work. That’s the kind of specifications that make me very happy. It’s good to know that Haiku’s developers are attempting to keep the operating system lightweight enough to work on older hardware. Meanwhile, waddlesplash is also auditing the code and starting to work towards making APIs more restricted (allowing some things only for the root user, for example), in order to provide some more privilege separation. Haiku has so far been largely a single user system, and did not worry too much about the usual attack vectors for an UNIX system. But modern computers are often online and we should try to keep our user’s data reasonably safe. We have a long way to go, but we have to start with something. Multiuser will be one of the many big hurdles Haiku will face.
As of hrev53136, we’ve finally replaced the aging hoard2 with a shiny new mmap-based allocator – mjansson’s rpmalloc. Thanks to @pulkomandy and @mmlr for helping out with that work! The main benefit here will be on 64-bit Haiku, as applications will now (finally) be able to use more than 1.5GB of RAM each, a limitation of the old allocator. But there are some pretty nice (10-15%) performance benefits over the old allocator, too. More of the technical details can be found in the commit message 5, but essentially the only thing to be concerned about is if things start suddenly crashing more often. It’s already known to exacerbate a few pre-existing WebKit crashes (mostly around Google Maps or the like, which were already so unstable as to be unusable anyway).
Due to the awesome work by long-time developer waddlesplash, nightly images after hrev53079 have read/write NVMe support built-in. These devices now show up in /dev/disk/nvme/ and are fully useable by Haiku. I’ve personally tested my Samsung 950 Pro and seen raw read speeds up to 1.4GiB/s. Another important driver for Haiku to have, and with today’s modern laptops (and most desktops) all having NVMe support, pretty much a must-have.
Last month, I sat down and decided to at the very least attempt to fix our XHCI (USB 3 host controller) bus driver. Issues with it have been the most significant problem users have been facing, as most hardware made post-2012 has an XHCI chip as the system’s primary USB chip, and most hardware made post-2014 (or so) has exclusively an XHCI chip and no EHCI (USB 2.0) or prior chipsets (which we do support very well.) Well, just under a month (and ~40 commits) later, virtually all those issues have been resolved. There’s a good bit of work that remains to be done, but at least all (!) the kernel panics are resolved, devices (largely) don’t lock up without an explanation (there are a few exceptions, but not many), performance is greatly improved (40MB/s with random 1-2s-long stalls, to 120MB/s on some USB3 flash drives and XHCI chipsets), and XHCI-attached keyboards can even be used in KDL! This is a major step forward for Haiku. Interesting, too, that Haiku’s developers note that they hope Haiku’s driver can serve as a more useful reference to other operating system developers than the driver of Linux, FreeBSD, and OpenBSD, which are, according to them, “so badly organized that it’s often hard to tell exactly what is going on vs. what the spec says should happen”.
Haiku’s latest monthly activity report for the month of January is out. waddlesplash spent a full week doing a major overhaul of the FreeBSD compatibility layer to port iflib, FreeBSD’s new ethernet driver subsystem. (The ipro1000 driver from FreeBSD 12 uses it now, so it had to be done sooner or later.) As a side effect of this work, PCI device probing and attaching for all FreeBSD-ported drivers is significantly faster and less error-prone (this probably trimmed ~half a second, and perhaps even more, off of boot time on all machines), and paves the way for eventual USB support. After overhauling the compat layer itself, waddlesplash finished porting ethernet and then WiFi drivers from FreeBSD 12. Thanks to the refactor, he rewrote the initialization code in the WiFi layer during this effort, which seems to have resulted in all “spontaneous WiFi disconnects” or “no networks shown” tickets tested so far to be reported as fixed! So, if you were experiencing those errors and haven’t retested, please do. This is just one of the many improvements this month, but there’s a lot more in the report.