5. From what you may know of other operating systems, would you say
that Be has
achieved the goal of easy programmability?
Definitely. It can keep up with the other current systems as far as
programmability goes (Java, OpenStep / Mac OS X). Windows can only be
mentioned in this connection, at least in the pre-.NET era, as an
example of how not to do things.
6. To get back to your project, OpenBeOS: Do you intend to rework
the
APIs etc, or rather
to produce an independent entity based on BeOS?
The plan is to reimplement BeOS 5 with all its
APIs. The API will be essentially unchanged at first.
Changes will
be made for the most part in the later versions. Under the hood
we are doing a few things differently, which the users and developers
will benefit
from, but there are no (major) changes to the API.
The benefit in that is that we can cooperate with other BeOS
derivatives on changes to the API, and instantly see how existing work
is affected by the changes.
7. As opposed to some other free BeOS derivatives, you are not
basing
the kernel on Linux but on a "genuine" BeOS kernel. Why?
Well, there are a number of reasons for that. One of them is the GPL.
Although of course I don't fundamentally disapprove of it, I see it as
only being of limited use in the area of operating systems. E.g
if as well as the kernel, XFree was also under the GPL, many Linux
systems today would be stuck with VESA graphics mode . Even though
it's
not exactly obvious, I consider the driver situation with Linux to be
something other than optimal. Many firms shy away from developing open
drivers for Linux. Besides in my opinion the GPL generates an
impression that we don't quite want, that everything has to be free of
charge. That could send the wrong signals for a small market like
ours.
Besides, for technical reasons I would prefer a kernel from FreeBSD,
Darwin (the open source part of Apple's OS X - Ed.),
etc, rather than Linux.
But why have we chosen to develop our own kernel, the one based on
NewOS? If we had decided on FreeBSD couldn't our kernel have been
already
finished, possibly with qualities that will take us years to
achieve? Well, in fact it's not really like that: Customizing a
finished
kernel to meet all our preferences would be at present a sizable
undertaking. Implementing from scratch in many cases
is faster; and what's more, you can do it more cleanly. We are in a
position to design a completely new system and shape it according to
our requirements. It will be a harmonious, unified
whole. Anyone comparing Linux or BSD source code
will conclude without doubt that our code is far easier to read and
understand. This fact alone is very important to me. It is all
uniform and developed with modern software principles, a system that is
simple
and transparent, so that it can be readily picked up.
What really keeps me motivated to work on this
project, and motivation is in fact the key element in an open source
project. Along with time of course. Of course BlueEyedOS will
be able to
show
results quicker than us because of that difference, but anyone who
has worked on Linux soon realizes that transparency and
simplicity could not have been important design principles, regardless
of
what Linux is capable of for the power user.
8. Will OpenBeOS be 100% compatible with Be, or will recompiling be
necessary?
OpenBeOS will be 99.8% compatible, i.e. all applications based on the
published APIs will work straight off.
There are some unofficial or undocumented APIs that we will redo either
differently or
not at all. That's why for example the original DriveSetup won't run on
OpenBeOS. But of course we will provide replacements for such
applications.
But for example we're inverting the address space, which will
significantly simplify the porting of projects like Wine, but will also
have
some other changes. Luckily there's no need to check for this in a
program1.
That means that you can basically say, either it works (99.8%) or it
doesn't (0.2%). Recompiling can't change anything to affect that. The
exception is the PPC version; it will not be
binary-compatible with BeOS R5 PPC. In this case, recompiling is a
requirement.
