What makes Haiku software special?

Warning: Rant ahead.

In the Gobe Productive 2.0 (clone) thread there came up a question of mine that I think deserves some discussion. When I looked for alternative operating systems to the ones I’d used before (AmigaOS, MorphOS, several flavors of Linux, Mac and even Windows), there are a few things that make Haiku special that I don’t think application developers will know about if we just run ports and don’t make anything new to contribute.

On AmigaOS and early Macs there was a style-guide that would make all the applications consistent and this included ways to use the underlying operating system. Invariably this lead to some problems between platforms having different style-guides and some things on the Amiga one weren’t properly written or were inconsistent with each other.

One thing that I think should be in a future or current style-guide for the Haiku operating system is to not reinvent wheels from the operating system if at all possible. Code reuse is the crux of maintaining low cache latencies and avoiding hard drive swapping thrash-fests. If the code that’s in the caches stays in the caches the whole system will run faster.

Caveats of this may include some ports may run slower than natively written code so it may breed a sort of “not invented here” syndrome. People may start to shun code from other operating systems but if that’s what it takes to maintain efficiency, it may be necessary to throw away perfectly good code in the interests of maintaining system performance.

In the instance of reinventing a wheel from another platform like the Qt framework, some people are already seeing code-bloat from other operating systems nest here. When asked about whether thinking of sin is a sin itself, Martin Luther was quoted as saying, “You can’t stop a bird from flying over your head but you can keep it from making a nest in your hair.” By that same token, we need to recognize that we cannot escape using ported software from other platforms when interoperability is necessary. Likewise, non-realtime software like office software may need to be used even though it isn’t invented according to the standards of Haiku usability. When duplication seems necessary we should consider making any new software not a duplicated effort.

My assertions when making a Haiku-specific office-package should be an open-source tutorial piece is an example of this. If we use LibreOffice as a standard we may be setting the bar too low on the tutorial usability to teach new developers to write well-performing code but on the other hand, sets the bar too high in the idea that it would require the ability to conform to an ISO standard file format for interoperability with other platforms in use. If we’re going to do something right for the Haiku platform, we need it to integrate with the OS in the way it was designed to be integrated with it. Native GUI is a start, pervasively multithreaded code is another feature we should look towards, even if it needs to be written in Rust to make it easy enough to debug that it will happen as it’s supposed to.

One thing that I noticed early in my transition to Haiku is that icons are supposed to be in a proprietary vector image format. This allows large icons to be packed into a single disk sector with ease. I like that. It makes the system more efficient that way.

I’ve probably stood on the soapbox long enough that people will recognize me as nuts or will recognize me as some sort of visionary, The fact is they are both true. I’ll step down now and see if I made my point. I’ll make myself available for some clarifications if necessary as well. I guess the only other thing that needs to be said is that I’m here because I care what happens. If Haiku doesn’t gain traction that is a sadness that I don’t want to bear.


Your help here is much appericated and needed.
Discussion is needed too and not to be avoided.
Ideas, crazy or not we need to find new ways.
Keep on discussing and choose your way you like most.

20 years ago I very much liked the lot of small sample programs on BeOs they made me try to program and test. We had also a lot of Tutorials about progaming small sample code. There was BeIde and how to use it. And now we have Paladin. Adam Fowler is not around atm, but there was great progress with Paladin to include all the sample code from BeOs over to Haiku.
There where also some nice tutorials and help from DarkWyrm and others.

So if you are going to fill this gap?! Great idea to do so if you like, I will follow your tutorials and try them. I cannot wait for someone again telling me step by step how to use the editor, Paladin, and some other GUI programs and Wonderbrush and IconOMatic again…

Just for fun and learn some specific Haiku code again.

Thanks for that idea!

1 Like

Thanks! I’ll probably start with SumIt if I can get it to work on a little-endian x64, then I’ll see if I can handle it.


I actually started an effort for this here, I’ve been able to launch and run SumIt on 64-bit, but its still a bit buggy yet:


Very well said indeed!

Hm I don’t really know what the question was, it was really long :slight_smile.

The Idea of Haiku, at least in the beginning. Was to have an os that was fast, small and easy to use, it just works and defult settings are enugth, you don’t need to know about setting up the os.

With ported software there are usually a lot of libs need. Usually a port don’t use Haiku API (our kits).

What sets BeOS/Haiku apart are.

  • It’s true c++ and not c.
  • Filesystem (BFS), the first version was a database more or less, now it’s all about the metadata on A file (copy that file to other system and the information are gone.
  • Media Kit, if you write a add-on to this all program using the media kit can read that filetype without implement it oh change there code (Gobe dig the same but with office files and close source)
  • when compared with Linux, you can’t really get out of the GUI it’s a part of the os, you get it all in one page, so there are not alon of distros that will have the Name Haiku.

Don’t know if it’s more but that’s what I can remember after using BeOS from 98 all the way up to know, comparing Haiku with BeOS we have some more trimming to-do to get it faster. :slight_smile:


The question was: “How can a style guide benefit the Haiku ecosystem?” It wasn’t really in the form of a question in the original thread though. :smile:

There is https://www.haiku-os.org/docs/HIG/index.xml , I think that checks already quite a few of the points you mentioned.

1 Like


Cache-loading optimizations don’t often seem intuitive to a generation that thought loop unrolling was an optimization. Likewise, hard-drive memory swapping is often not a feature but an act of desperation just getting software to work and should be avoided.

I think that’s all that needed to be added.


Thanks! Once I saw it was swapping to big endian byte ordering on a little-endian architecture I figured it was only debugged on PPC.