[haiku-development] Re: What's the status of Haiku?
- From: Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 21 Aug 2014 23:32:04 +0200
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.
Other related posts:
