Features Download

From: =?UTF-8?B?QXhlbCBEw7ZyZmxlcg==?= <axeld-Rd02jAPjeE1dgG6+X1Sd1g <at> public.gmane.org>
Subject: Re: What's the status of Haiku?
Newsgroups: gmane.os.haiku.devel
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.

CD: 3ms