[haiku-development] Re: What's the status of Haiku?
- From: pulkomandy <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 18 Aug 2014 15:41:12 +0200
On Mon, Aug 18, 2014 at 03:03:37PM +0200, Sia Lang wrote:
> 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.
Hi,
We made a lot of progress since 2007. There were four "alpha" releases
already, and we added support for WiFi, package management, and a modern
web browser. This is quite an achievement for our small team of
developers.
>
> 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?
On my machine, it works rather well for daily use. There are some bugs,
but nothing I would qualify as critical. It is, for example, much more
stable than Windows, and many people think Windows is good enough for
real-world use.
>
> 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.
>
> 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.
That certainly is a nice project, and personally I think it would be
nice to have the BeAPI available in other systems than Haiku.
As I said, we already had 4 alpha releases. Our definition of alpha is
different from what most people expect, and these releases are good
enough for daily use. They are alphas only because of the lack of
support, upgrade path to newer versions, and some missing features when
comparing to BeOS R5. The last two items are now solved, and we should
be enotering Beta stage soon. However there's still the race of writing
drivers for new hardware so the OS can actually be used. Our next steps
in this area will probably be USB3 and 3D acceleration. I would like
those to not delay the R1 release further, but I think others disagree on
this.
>
> 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.)
The main grief we have with Linux is that everything there seems to need
manual tuning, whereas we go for a system that just works, out of the
box. The result of this, on the Linux side, is a quite fragmented
ecosystem with GNU/Linux distributions preconfigured for certain tasks,
and some non-GNU usues of Linux for example in Android. It's nice to see
that the Linux kernel is flexible enough to find uses in so many cases,
but I think there is some use in writing and finetuning our own kernel
and building our own APIs on top of it. Where would be the fun
otherwise?
>
> 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.
I don't think it was. My experience from 2001-era Linux is simple: on my
computer, which ran BeOS just fine (and that machine also runs HAiku
now), the average Linux distro wouldn't boot at all.
I must also mention the BlueEyedOS project, which was an implementation
of the BeAPI on Linux (2.4 or maybe 2.6 at the time). It didn't get as
much success as Haiku for various reasons, but mainly because most of the
developers chose to go with Haiku. I wasn't a contributor of either
projects back then, so I won't comment on why this happened.
There is more to that choice than purely technical reasons, however.
Linux is GPL licensed, and back in 2001 there was hope that someone
would buy the BeOS sources and do something useful with them. Haiku was
put under the MIT licence to allow reuse in the revived BeOS project.
Unfortunately, this never really happened. There is also the goal of
binary compatibility in Haiku: this may have been possible with a 2.2
kernel (which was the current version in 2001), but remember we are
stuck with an antique libc and compiler, which we couldn't use to
compile a newer kernel. Would our situation be better today, if we had
forked Linux 2.2 in order to preserve this binary compatibility, and
backported features from later releases? I don't think so.
--
Adrien.
Other related posts:
