Hacker News new | past | comments | ask | show | jobs | submit login

No code was kept from BeOS except for a few high-level components that were open-sourced while Be was still around (e.g., the Tracker). I've general found the new code to be high quality whenever I've delved into it, but I have only ever run Haiku in a VM, and then, only in short bursts. In other words, my experiences were all good, but there are few of them.

As far as development: the GNU tool chain exists, and is indeed the foundational tool chain. There's also a high level of de facto POSIX compliance (though neither BeOS nor (current version of) Haiku are multiuser), and many libraries you'd expect are available just fine. Even some large ones, like Qt. This makes porting fairly easy—and much like on OS X, it's easy to wrap a native Haiku GUI around existing tools.

The one bad part of development on Haiku is that the old-world C++ API has resulted in some compiler weirdness. Haiku aims for full binary compatibility...with C++ apps written on GCC 2.95. But developers, of course, want GCC 4. So what happens is that, much like OS X has fat PowerPC/x86 binaries, Haiku has fat GCC 2.95/GCC 4 libraries. This doesn't actually make development a pain, but it requires a bit of heads-up to navigate the linking situation




We don't have fat libraries. We do have a hybrid system, either a gcc2 based system with additional gcc4 libraries so a gcc4 application uses gcc4 libraries. Or the other way around a gcc4 system but with gcc2 libraries for old apps. gcc2 is still the default system, and changing it has been discussed.


Got it. I misunderstood how the hybrid part worked.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: