BeOS (the OS Haiku is a reimplemntation of) has an interesting history. It was an OS that has a fully async C++ API (very novel for it's time and even now). The fact that it was async made the OS much more responsive and had a better CPU utilization. BeOS was another company that Apple considered to purchase but they ended up buying NeXT instead. IIRC they ended up going with NeXT because BeOS didn't have networking…
The BeBox had dual cpus, too, iirc
Multiple Hobbits as a prototype, Multiple PowerPC 603s in production.
I always smile wistfully whenever Haiku/BeOS comes up... its performance and just sheer fun remains unmatched by Windows, OS X, Linux, etc (try it out in a VM). dr_dank summed it up best back in 2003 [0]: BeOS was demonstrated to me during my senior year of college. The guy giving the talk played upwards of two dozen mp3s, a dozen or so movie trailers, the GL teapot thing, etc. simultanously. None of the apps skipped…
Haiku is a clone not based on the original BeOS codebase. So while it may run the same apps and look similar, does it have the internal design and optimizations that made the original so capable for its time? Could Haiku running on equivalent hardware run that demo as well as BeOS?
Haiku is pretty damn fast. Its kernel (NewOS) was written by one of the BeOS developers and the whole system's architecture is generally pretty similar to BeOS.
Browser engines like WebKit are (with some work) portable to any platform with a C++ compiler: that's how the current Haiku browser is built.
So, now you just need to build a highly-optimizing, C++ compiler instead of a browser? That's another project that few got right over a period of a decade or so. Of course, one could use a C++ to C compiler or extend existing C++ compiler with OS-specific backend. Might still be plenty work but easier than clean-slate browser.
Both gcc and clang have flags to emit raw object files. At which point, your porting work really centers around making sure you have a good standard library in place, and that your kernel has a reasonable implementation of parsing a binary format like ELF or PE, etc.
I hope this isn't too off topic, but I recall when the BeBox was coming out, one of its cool features was the "Geekport" I am going to Google it – but I'm curious if anyone on HN had experience with it and can explain what made it awesome (or not!)
37 pins of GPIO with an external D-Sub connector, plus DAC/ADC with Libraries built in to the OS.
It's a general-purpose OS. Do whatever you normally do on it. More importantly, it's a learning tool. It's been part of many courses and many rounds of Google Summer of Code. It's an embeddable kernel + OS free of the cancerous GPL, under a permissive MIT licence. It is extremely well documented, well tested, and consistent. Writing drivers for it is very simple. This makes it interesting for education, for-profit de…
> free of the cancerous GPL, under a permissive MIT licence Is this attitude common in the Haiku community? I was interested in checking it out but seeing this sort of rhetoric is discouraging.
I can't say I speak for the “Haiku community” short of being friends with some of the developers and hanging in the IRC channel, but … no that's not a common attitude. Haiku prefers non-copyleft licenses, but doesn't avoid the GPL like cancer. Heck the default compiler is GCC (and will be for the foreseeable future) and the web browser uses WebKit.
I love Haiku -- and their inspiration in BeOS brings back my memories of deciding not to work for Be in 1996, and then later hitting jackpot at the Be Inc. bankruptcy auction.[1]
Interesting philosophy on why Haiku is not Linux-based (from the site): Linux-based distributions stack up software -- the Linux kernel, the X Window System, and various DEs with disparate toolkits such as GTK+ and Qt -- that do not necessarily share the same guidelines and/or goals. This lack of consistency and overall vision manifests itself in increased complexity, insufficient integration, and inefficient solutio…
Bah, this justification is flawed and/or obsolete: why does it matter for reusing the Linux kernel what classic GNU/Linux distribution do? It didn't prevent Google (Android) reusing the Linux kernel to build the Android OS..
For doing what Haiku and BeOS excel at, you need a huge pile of patches to the Linux kernel, to rewrite even more subsystems than Android did -- for one, the audio subsystem in Linux is an absolute disaster, and have the impedance mismatch of your kernel not being written with neither the same philosophy nor language as the rest of the OS. Haiku wants to be backward compatible with programs written for BeOS, so you'd have to write a mish-mash of compatibility drivers for that to work. At a point, it becomes easier to just write your own kernel.
So, now you just need to build a highly-optimizing, C++ compiler instead of a browser? That's another project that few got right over a period of a decade or so. Of course, one could use a C++ to C compiler or extend existing C++ compiler with OS-specific backend. Might still be plenty work but easier than clean-slate browser.
Both gcc and clang have flags to emit raw object files. At which point, your porting work really centers around making sure you have a good standard library in place, and that your kernel has a reasonable implementation of parsing a binary format like ELF or PE, etc.
> free of the cancerous GPL, under a permissive MIT licence Is this attitude common in the Haiku community? I was interested in checking it out but seeing this sort of rhetoric is discouraging.
That's just reality. In general the GPL is perceived extremely negatively. Almost every company I've worked for has had strict audits to ensure nothing we do or even previously worked on has touched anything potentially GPL. If you're writing software for fun, enjoy seeing it being used, and still want attribution you licence it under the MIT or BSD, not the GPL. Many people get polarized on the topic and there are m…