[haiku-development] Re: What's the status of Haiku?
- From: pulkomandy <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 18 Aug 2014 17:11:09 +0200
On Mon, Aug 18, 2014 at 04:32:16PM +0200, Sia Lang wrote:
> On Mon, Aug 18, 2014 at 3:41 PM, pulkomandy <pulkomandy@xxxxxxxxxxxxx>
> wrote:
>
> >
> > 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?
> >
> >
> Besides the "fun" argument, all your points speak *for* Linux (or a BSD for
> that matter). There would be a configuration tuned for BeOS workloads, and
> you would never have to do that job again. I don't follow your logic.
>
> As for the fun argument, I totally buy that. It's an important motivational
> factor. But the truth is, end users don't care about that. They want a BeOS
> clone that works. Now :) I'm personally having a ton of fun making a
> BeOS/Linux, so I guess it's possible.
That's exactly it. Some of our developers have more fun writing our own
kernel, rather than messing with the Linux sourcecode. If your goal is
getting an API-compatible clone of BeOS, and getting it fast, then yes,
using the Linux kernel in its current state is a good choice. However,
the Haiku project is more than that. For example, our package management
system required changes to our kernel and even our bootloader. We could
have done that on a Linux kernel, but it is unlikely that these changes
would be upstreamed. There is also our choice of licence (I already
explained this in my previous mail) and programming language. We use
C++, even in the kernel. Linux has a C-only policy, which would prevent
merging our work. When we write drivers, we usually use the FreeBSD
code, rather than the Linux one, as a reference, because it tends to be
much cleaner and somewhat closer to our driver architecture.
> > 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.
> >
>
>
> It was a blue eyed effort. An attempt with the current Haiku "work force"
> would end up with something beautiful that would work right now, with
> thousands of drivers working on all kinds of devices, not just desktops.
There are two problems with that. You can't switch our "work force" to a
completely different project. We have some people who like to work on
the kernel, and these would be left with essentially nothing to do if we
use Linux. Some parts of the system would need a deep reengineering,
such as the app_server, the media kit, or the way BMessages work (the
implementation for these in Haiku relies on features that are available
in our kernel, but not in Linux). So it's moving the project forward in
some areas (hardware support, stability of the kernel) and back in some
others (all the kits need to be thrown away and rewritten).
The second problem is, we don't want to run on things other than desktop
computers. As I said, what we try to do is a system that works out of
the box for the very specific situation of a desktop computer. Not
servers, not smartphones or tablets. This is not a limitation of Haiku,
but rather a design choice. It makes things simpler for application
developers to target a single usage pattern, and for example know that
Haiku systems will have a keyboard and mouse, and they can rely on that
for their user interface. Attempts to build an unified user interface
for desktops, smartphones and tablets have limited success so far.
On the API side, things are a bit different, and another system using
the BeAPI in a different context and with different goals could work
well. But while interesting, this is out of the scope of the Haiku
project.
>
> At any rate, my initial question wasn't really about my pet project (which
> may or may not end up as something more), but an assessment of how far away
> Haiku 1.0 is.
There is no schedule set for R1, so I can't say anything more precise
than "we're almost done.". I will do my best so it doesn't take another
7 years to get R1 out. But as I already explained, at this point it is
not a matter of features anymore, only of setting up infrastructures for
user/developer support, ensuring there is a migration path from R1 to
R2, and maybe some hardware compatibility issues. So, no big feature
deveopment is planned.
--
Adrien.
Other related posts:
