[haiku-development] Re: What's the status of Haiku?
- From: Stephan Aßmus <superstippi@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 18 Aug 2014 17:19:18 +0200
Hi Sia,
Am 18.08.2014 15:03, schrieb Sia Lang:
Back in 2007, in his goodbye letter, Phipps assessed that "we're almost
there". That's seven years ago, and I unfortunately think his assessment
today would be about the same.
Indeed. :-)
Maybe I'm wrong, as I find it hard to figure out the actual state of
Haiku. On my machine, it "kinda" works, but there's clearly also several
critical bugs. Could someone please give the audience a rough estimate
on when to expect the first release?
I can't give you an estimate. The problem is that the number of frequent
contributors is reduced so much, that there isn't really an "average"
amount of work done across the active contributors. And not everybody is
working on stuff that directly concerns the next release. There is no
basis for an estimate.
I'm asking this in no small part due to having a working prototype BeOS
API layer on top of a Linux 3.x kernel (app, interface and networking
kits already in decent shape after only a couple of months of
development - Linux has already done the hard work) and I am pondering
whether or not to pursue this project.
Hm. It sounds like you are pragmatic. You "just" want your working BeOS
clone. But I don't completely buy it. There must be a "fun" component
for you as well. :-)
If Haiku is close to release, I probably won't bother since it's still a
lot of work, but if another seven years is going to pass by, I'll
probably go ahead.
If that fun component is large enough, I would suggest you keep going.
If you make a good job, you could actually use *a lot* of components
from Haiku itself. Actually, almost everything except kernel, drivers,
and stuff that uses private system calls, no? ;-)
While there are some minor downsides to having the kits on top of Linux
(or one of the BSDs), the upsides include all the drivers in the world
(well, the gpu driver situation could be a tad better), a rock solid
kernel that works on all kinds of devices (who says BeOS can't run on a
phone, mine can), and a working BeOS clone with comparatively little
effort (as a musical engineer, my biggest worry was sound system
latencies, but it turns out many Linux schedulers can easily be tuned to
handle the loads I expect in a BeOS system.)
I fully believe that.
I think the Haiku project made a monumental mistake in not using an
existing kernel - it's simply no longer practical for a small project to
keep up with the hardware evolution, handling security requirements and
so on. Sad but true, and it was sad but true back in 2001.
You have the benefit of hindsight. First of all, there were indeed some
technical reasons -- ports, inode ids in entry_ref, ... there was more,
but I am no kernel guy. And it was believed that having to maintain a
patch set on top of the Linux kernel would be too inconvenient. There
was the argument of being in full control of everything top to bottom.
And the Linux source code itself is probably in a much better state
today than it was in 2001. It is probably still ugly and cryptic in many
places compared to Haiku. Though I don't really have a clue.
Anyway. If you keep going, you will probably stumble across some of the
reasons why Haiku went with its own kernel. Maybe all of it can be
worked around if binary compatibility is not your goal. (Personally, I
think it doesn't have to be.) Who knows, maybe the Haiku project is
prepared to switch kernels once you are further along?
Best regards,
-Stephan
Other related posts:
