BeOS & Derivatives Archive

The BeOS file system, an OS geek retrospective

It's a bit of a slow news week in technology this week due the US celebrating Independence Day this past 4 July, so Ars decided to repost this article about BFS, and I'm nothing if not a sucker for BeOS content, so here it goes.

The Be operating system file system, known simply as BFS, is the file system for the Haiku, BeOS, and SkyOS operating systems. When it was created in the late '90s as part of the ill-fated BeOS project, BFS's ahead-of-its-time feature set immediately struck the fancy OS geeks. That feature set includes:

  • A 64-bit address space
  • Use of journaling
  • Highly multithreaded reading
  • Support of database-like extended file attributes
  • Optimization for streaming file access

A dozen years later, the legendary BFS still merits exploration - so we're diving in today, starting with some filesystem basics and moving on to a discussion of the above features. We also chatted with two people intimately familiar with the OS: the person who developed BFS for Be and the developer behind the open-source version of BFS.

A good read.

Haiku May monthly activity report

Haiku's latest monthly activity report is out, and it contains a lot of interesting points of progress. Since I can't highlight them all, here's one that I think is vital.

Korli continued his work on 32-bit applications support for x86_64. He now has most of the binary-loading, commpage, signals, and syscall system changes merged, though there are still a lot of pending changes to fix individual syscalls and then start applications in 32-bit mode.

There's also a major new port: LibreOffice has been ported to Haiku.

Rune – Haiku images on ARM

Up until recently, Haiku builds for ARM have targetted individual ARM boards. The compile process for ARM images required two things: an architecture, and a target board (such as the Raspberry Pi 2). This board setting adjusted a large number of defines throughout Haiku at compile time to set the operating system up for the target ARM device. The board selection also handled placing all the propriety bits (a lot of which have sketchy licensing) into the Haiku image during compile. Haiku would then have to distribute these files. (sketchy licensing and all)

Over the past few years, François Revol, Ithamar R. Adema, and others have worked to add Flat Device Tree (FDT) support to Haiku. FDT’s enable operating systems to obtain core knowledge of the devices they run on by simply swapping one or more compiled binary files. These files describe critical things the operating system needs to know about the hardware they run on. Really important things such as what devices exist at what memory locations. (Think video frame buffers, serial ports, etc)

In a series of cryptic commits in July 2017, I removed these board-centric build steps with grand plans of making testing (and running) Haiku on ARM devices easier.

No, this does not mean Haiku now runs on ARM, as it has been able to do that for a while now. The goal of these changes and improvements is to speed up development of Haiku's ARM build, and to simplify the distribution of ARM builds into a single, generic ARMv7 image.

Haiku starts work on allowing 32bit apps on 64bit Haiku

There's another Haiku monthly activity report, for April, and as always, there's some interesting changes, bugfixes, and improvements in there. The biggest improvement?

Let's start with the most exciting developments this month: Korli started work on a 32/64 bit hybrid. The idea is to run a 64bit system, but allow 32bit applications to run on it. While we are just at the very first steps, it is a good thing that this is being worked on, as it will allow us to move more smoothly towards 64bit support.

In addition, the first three Google Summer of Code progress reports have been posted, for the SDHCI MMC driver, the TrackGit project, and XFS support.

Haiku unveils its 2018 GSoC projects

It's that time of year again - Haiku is going to participate in Google's Summer of Code, and this means interesting projects to follow. One of the three projects has the goal to bring XFS support to Haiku, while another wants to implement "an addon for Tracker to support the Git version control system". The last of the three projects aims to develop an SDHCI MMC for Haiku, which, from the description of the project, seems like a massive undertaking to me.

Three fascinating projects to follow over the coming months.

Haiku monthly activity report, March 2018

Haiku's monthly activity report for March is out has been out for weeks now, and it contains some interesting nuggets as the team moves closer to beta, but one stood out to me:

Kalisti5 got the PowerPC build working again. It is still not possible to boot PowerPC images very far, but at least it is now possible to compile them, and our buildbots are now happily doing so.

I find it interesting that there's people at Haiku still working on PowerPC support. It'd be interesting if they ever manage to support Apple PowerPC hardware, if only to offer yet another choice besides MorphOS.

Antique BeOS Content by Scot Hacker

In late 2002, Byte.com decided to combat falling ad revenue by charging admission to its archives of computing content. I have first-hand experience tring to harvest enough revenue from the Internet to pay operating costs, and fully support Byte's decision to move to a subscription model. However, my BeView columns on Byte.com are now virtually hidden from search engines and thus from the Internet, and hundreds of incoming links (which now redirect to a subscription page) might as well be broken.

The BeOS content I provided to Byte.com over the two years I wrote for them is tailored to a very specific niche audience. BeOS itself is, for practical intents and purposes, completely dead. Even though these articles were surprisingly well-trafficked at the time, it is hard for me to imagine that anyone would pay for access to the Byte archives just to read a few old nuggets.

Scot Hacker's BeOS columns for Byte, neatly archived. What an amazing treasure trove. I don't think this archive is new by any means, but it's the first time I've seen it.

Haiku’s first beta is possibly maybe not too far off

I've now turned my attention to preparation for beta1. Already talk has resumed on the mailing list of a tentative schedule; there still remains too much to do to expect it before the new year, but with the list of blockers now reduced effectively to two (one relating to installing source packages on the actual release image, which I intend to look into solving soon; the other is about clashing mime supertype declaration and may prove trickier to solve), the actual "release branch" is hopefully not more than a month away.

I've already begun drafting release notes and making build system cleanups as part of preparation. There is finally light at the end of the tunnel - don't give up hope yet. :)

I'm just putting it out there that if all goes according to plan, I'll be spending lots of time in a nice Haiku virtual machine over the coming weeks to get a really good look at the state of the continuation of the best operating system ever made.

It's time.

Where is Haiku R1?

With all the infrastructure changes and improvements, paired with the bug fixes in our master Haiku branch, we are slowly and steadily moving towards the R1 Beta 1 release which will live in its own R1(!) branch.

R1 Beta 1 installations should slowly roll towards the final R1 release via package updates. R1 Beta 1 is going to be a big step towards our first stable release.

The exact dates are still not solid. I know we have been saying "soon" for quite a while... But soon.

...

Haiku details its GSoC projects

Haiku has been accepted into Google Summer of Code again this year, and over the past few days the project has detailed some of the areas developers will be focusing on. For instance, Vivek will be working to bring 3D hardware acceleration to Haiku:

The Mesa renderer in Haiku presently ventures into software rendering. Haiku uses software for rendering frame buffers and then writes them to the graphics hardware. The goal of my project is to port Direct Rendering Manager (DRM) Driver for i915, from the Linux kernel to Haiku with the help of DragonflyBSD's Linux Compatibility layer, so that those drivers can be later extended to add OpenGL support (Mesa3D) for hardware accelerated 3D rendering.

Other projects include bringing Harfbuzz support to Haiku, building a Haiku preferences pane (blasphemy to an old BeOS user such as myself, but entirely a 100% good idea for normal people), developing a calendar application, and adding Btrfs write support.

Haiku’s Augustin Cavalier on the Lunduke Hour

Augustin Cavalier (also known as Waddlesplash) was a guest on The Lunduke Hour, where he explains a lot about what's been going on with the Haiku project for the last couple of years, and why it's been so long from Alpha 4 to the upcoming Beta 1.

Cavalier goes into Haiku's rather unique package management system, progress on the application front, and tons of other things. Definitely worth a listen.

500 byte images: the Haiku Vector Icon Format

Haiku uses a custom vector image format to store icons. This is surprising both because most OSes consider bitmaps to be totally sufficient to represent icons and because there are plenty of vector graphics formats out this (e.g. SVG). The goal of the Haiku Vector Icon Format (HVIF) is to make vector icon files as small as possible. This allows Haiku to display icons as several sizes while still keeping the files small enough to fit into an inode (i.e., inside a file’s metadata). The goal of keeping the icons in the metadata is to reduce the disk reads needed to display a folder - it also each file to only require one disk read to display.

This blog post examines the details of the HVIF format using a hex editor and the canonical parser's source code. In the process of dissecting an example icon, I'll also show you an optimization bug in the icon image editor.

Great article.

Haiku Media Kit: new and old pieces

Hello, it has been some time since my last article, in the meantime I continued to improve things out and since I changed some important parts of the media_kit, I think it's correct to notify the community about new and 'old' features added recently. This is an article mostly written for application developers, but I tried to explain the improvements made with simple words so I hope it will be interesting to anyone.

Of all the alternative operating systems from the golden days (2000-2005 or so), Haiku is one of the very few - possibly the only one - still going strong. And by "going strong" I mean seeing a ton of development seemingly without seeing a sort of definitive release. They're trying to reach zero by endlessly dividing by 2, it seems, getting ever so much closer to zero without actually getting there.

Haiku: introducing the launch_daemon

A significant new development as Haiku continues pushing towards a stable release.

Since the switch to our package manager, there was no longer a way to influence the boot process at all. The only file you could change was the UserBootscript which is started only after Tracker and Deskbar; the whole system is already up at this point.

The launch_daemon gives the power back to you, but also allow software you install to automatically be started on system boot as well. You can also even prevent system components from being started at all if you so wish.

A summary of features:

Furthermore, it allows for event based application start, start on demand, a multi-threaded boot process, and even enables you to talk to servers before they actually started.

Read the full article for a detailed description.

Be, Inc.’s 1998 demonstration video

To this very day, this BeOS demonstration video from Be, Inc. blows my mind. I'm not entirely sure about the date of the video, but since we're looking at Pentium IIs and the Intel version of the BeOS, I'm guessing we're in 1998. This means that while Windows users were barely getting by with Windows 98, and Mac users did not look at their Macs funny because otherwise Mac OS House Of Cards Edition would come crumbling down, the BeOS was doing the awesome stuff shown in the video.

Taking chronology into account, the BeOS was and is the best operating system ever made. I'm far from impartial on this one, of course, but there has never been a piece of software that generated that same sense of wonder, excitement, and exhilaration that the BeOS did. It sure wasn't perfect, but it had so much personality, such a strong identity, and even a sense of humour - the stuff we have today just can't compare. iOS and OS X are clearly designed to lock you into buying as much Apple hardware as possible. Android and Chrome OS are designed to keep you staring at Google ads for as long as possible. Windows is Windows. Linux is the same mess it's always been (I'm sorry).

None of them are about putting the consumer and technology at the centre.

When the first Haiku alpha was released, I explained how with the demise of Be, something in this industry died with it. I once had the faint, faint hope that the mobile revolution would reignite that spark of insanity, but with Apple and Google dividing and conquering this industry almost overnight, and with ARM devices being an ungodly mess of restrictions and proprietary crap, we're farther away from those glory days than we've ever been, with fewer and fewer signs of them ever returning.

The BeOS is the best example of why our industry is so utterly broken. BeOS exemplifies that the best does not win. And if the best does not win, we are being held back.

Haiku monthly activity report – March 2015

Even though Haiku may be considered a hobby project, it's been in use professionally for a while now, by BeOS mainstay Tunetracker Systems. Recently, it also launched a Haiku distribution, which in turn also forms the base for their own products. In the most recent monthly activity report, the Haiku project mentioned that another company is planning on using Haiku in one of its products.

izcorp is another company is planning to use Haiku in a commercial product. Their line of studio recording systems is currently running BeOS and Zeta, but they are working on an update to Haiku. Ithamar is working with them to get their hardware fully supported, and the changes will be upstreamed to Haiku in the coming weeks. This includes several fixes to the USB stack, the intel_extreme driver, and there could be more to come.

The activity reports details a large number of the commits from last month, so it's definitely worth a read if you want to know what's up with Haiku.