Subject: Re: What's the status of Haiku?
Date: Thursday 21st August 2014 21:32:04 UTC (over 4 years ago)
On 08/21/2014 06:39 PM, Julian Harnath wrote: > To be honest, I'm a bit disheartened by how many core contributors are > expressing their complete willingness to replace our kernel with Linux > (given that someone tackles the difficult work of pulling off such a > switch). Just to contribute my 2 cents to the discussion: as with the eventual switch of the userland API to Qt, switching to another mature kernel is a very pragmatic thing to do. It's a compromise that sacrifices some of the key (for me, anyway) design basics of Haiku. While it's always a good thing to be open to revise past decisions, radical changes like this would change the identity of the project considerably (and therefore its complete community). I don't just work on Haiku to deliver my favorite OS to the masses. I also like working on it. Building a complete operating system from the ground up was a very educational, and, for the most part, fun experience. I'm in the process of setting up a NAS, and I would have loved to use Haiku as a basis. It doesn't support the network driver, though (FreeBSD doesn't either yet). If there was a Linux based Haiku that would give me attribute and query support, I'd use it for that immediately. If it worked really well, the Haiku kernel would probably really go the Hurd way, even though I'd personally never want to let it die (see? exactly like Hurd ;-)). A switch to Linux would give us plenty of interesting features. Proper power management is only one of them, although I don't really think it would be all that hard to achieve for most hardware (on my Haswell based NAS, Haiku, booted from USB, only needs 1W more than Ubuntu 14.04 when idling, thanks to Pawel). Anyway, I think to achieve the level of integration I (and I hope: we) would like to see from such a Wolpertinger (same for the Qt API switch, btw) we would need to maintain a *huge* patchset over the Linux kernel, that has zero chances of ever getting accepted upstream. I definitely wouldn't like to see things like procfs or udev, we would need attribute, and query support, package FS, a complete BFS, ... Writing those things would certainly be possible, but maintaining them would definitely not be something I'd like to do. Every major change in Linux might not just mean a major rewrite, but might also cause additional patchsets to maintain. If someone else does all that, I wouldn't mind all that much, of course :-) I absolutely adore Haiku's boot process, btw. That would be lost, too. C++ in the kernel is just sooo much nicer. Especially many of the Linux drivers are of poor code quality; obviously many companies don't have talented people working for them. In short: I don't mind Sia working on this at all, I might even use it when something useful comes out of it. I just wouldn't want to work on it anymore. Bye, Axel.