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.
