Interview With Axel Dörfler of OpenBeOS

This interview was originally conducted by Matthias Breiter for Technoids, a German-language publication. It has been translated by Mark Patterson and this English version is being published exclusively by OSNews. Learn a little more about the OpenBeOS project from one of its primary contributors.
This interview was conducted via by e-mail by Matthias Breiter. Despite
(or even because of) its range it provides a very
interesting insight into the open source BeOS project. We thank Axel
Dörfler, one of the main programmers and spokesmen for this highly
promising project.

1. Can you introduce yourself briefly to our readers?

My name is Axel Dörfler, I was born in1976, and I’m currently
(still) studying Computational Linguistics and Artificial Intelligence
at the University of Osnabrück.

2. How and when did you get into BeOS?

I guess it was mainly through my aversion to the Windows operating
system. I had been an Amiga user for a long time (and still am) and
so I couldn’t take the pre-NT versions of Windows seriously.
Until the year 2000 I didn’t even have my own “IBM-Compatible” PC. I
had briefly seen a demo of BeOS R3 on my father’s computer when it was
on the CD of some magazine. Unfortunately it was only black and white
and
640×480, and the bundled apps actually crashed during
my cursory testing. So I didn’t follow its development at the time,
even though I had registered myself earlier as a developer with Be. But
that must have been before the BeBox, and through inactivity at some
point I was no longer getting the Be Newsletter. Things changed when,
about 3
months after I got my PC, BeOS R5 PE was published, and I just tried it
out. Until then my PC had been living very much in the shadow of the
Amiga.
It felt slower with Windows 98 than my old Amiga, despite an Athlon
600. But it wasn’t just the outstanding speed
of BeOS that changed things. BeOS simply worked well with everything
(and my hardware was in fact, by chance, completely supported).

3. What induced you to start OpenBeOS?

Well, it wasn’t me that started it. Back then, it was Michael Phipps
with a small band of fellow enthusiasts. I held off for a while
and didn’t expect the little project to create a BeOS replacement
within the next couple of years.
My reluctance finally changed when Be was officially sold and
it was clear that BeOS itself was not going to be developed any further
and Yellowtab’s Zeta didn’t look as promising as it does now (and
it’s still not out). Since all the other operating
systems (by that time I had tried a few) didn’t meet my high standards,
OpenBeOS was for me the logical way to take the future of BeOS in hand.
I joined the team along with Bruno G. Albuquerque (also known as BGA),
and have never regretted it; I am working with the smartest and nicest
programmers that I have known for a long time.

4. Are you still happy with the ways that BeOS can be programmed
(APIs,
interfaces), from you present point of view?

For the most part I am, except for the many bugs and inadequacies
in the implementation (e.g. in the Media Kit). What I miss as a
programmer is a sensible way to put GUIs together (like Marco
Nelissen’s
excellent liblayout.so), a locale kit (under construction) and a
sensible network stack.
I’m not too demanding, but still one could of course
improve a lot of the details, and integrate some of the designs from
the current class libraries. But those things are not
holding me back.

OpenBeOS is just starting out. The first step is to try to get the
implementation right, and then we’ll get to the “niceties” in the API.
Why should I care how easy the Media Kit is to use if the stupid thing
can’t play my movies in sync?

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
program¹.

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.

9. To what extent would genuine compatibility make sense,
particularly
as concerns pure software OpenGL?

That is again a matter of how it’s implemented. The present version of
MESA can be
used as a drop-in replacement for Be’s software
OpenGL (despite a couple of bugs). But no-one would
demand in this case that we artificially restrict the functionality to
rendering in software, if later on we have another option. That
kind of thing is not essential for maintaining compatibility.

To give another example: Just because BeOS is poor at handling extended
and logical partitions, that doesn’t mean that we have to preserve its
poor behaviour, since the way we implement that, as with most other
things, doesn’t affect compatibility.

10. What is your take on Bernd Kortz’s Zeta operating system, which
is
not open source?

The only thing that I can say about that is that it is not yet ready
and not yet available in the market. I hope it revives the BeOS market
a bit, which we are after all a part of. In any case I wish Bernd lots
of luck

11. Do you believe that long term it makes sense to be offering
or developing 3 open source flavours of BeOS and 1 commercial?

Definitely not, but it’s really not too bad. If the developers
can’t all unite on what route to take, they will obviously take
different paths.
None of our projects, except Zeta, is out for financial success, we
have no business plan to fulfil, and no time pressure, etc. So why
should someone freely devote himself if he doesn’t fully support it
(after all he’s not being paid for it)? Unfortunately this sort of
thing doesn’t get done just for the good of all, of course.

But, apart from the various goals of the projects, they will all
benefit, for example, from Marcus Overhagen’s implementation of the
media
kit; and we are letting them benefit from it; our licence stipulations
explicitly allow them this kind of use. That means that even if our
different goals have led us to different projects, and some parts will
inevitably be
reduplicated, we are still automatically also working together. So far
that has been limited, since we are all still more or less
at the beginning, but such co-operation is definitely going to take
off. For
example, Bill Hayden, the developer of COSMOE, even has
write-access to our repository.

To cut a long story short: Our prospective users aren’t
necessarily seeing the benefits of the current situation, but I
expect we will find ourselves back
on a common path again.

12. Doesn’t history show us that operating systems are most
successful
when developed for their “own” hardware? (Amiga, Commodore, Apple,
Microsoft + IBM-PC XT/AT)

No, actually it shows exactly the opposite. One particular operating
system achieved the widest distribution without having its own brand of
hardware,
but by being able to run everywhere. Linux is following in its
footsteps. Thus, I’m sure that whether or not we succeed will not come
down to hardware.

13. Would you say that a computer like the BeBox with greater
production would have made more sense? Or is BeOS still around because
it runs on normal PCs?

The latter. If the BeOS community only consisted of BeBox
owners, it would probably not be around today.

14. Can you tell us something about the progress of OpenBeOS? Is
there
anything already working well?

In my opinion we’re making good progress. In fact all areas already
have something to show, even if it’s just our unit tests. But our
implementation is proving more correct and stable than the
original. Even parts as complex as the Media Kit or BFS are ready for
trying out, at your own risk. Marcus only recently released the Media
Kits at Alpha 1 status, but the progress he has made since then speaks
volumes.

15. You are working on a PowerPC kernel. Will each platform need its
own executables, or will OpenBeOS software run on both?

Software has to be compiled separately for each platform, but there are
no further requirements. In fact, the same compiler will be used, which
makes this process much easier than it was in the old BeOS. The PowerPC
kernel is a port of our kernel to the Pegasos, a new and
state-of-the-art PPC system developed by Genesi. This could well be the
first machine that will boot directly from the hard disk, depending on
how buggy the version of
Open Firmware on my machine
is.

16. Will your PowerPC port support the latest CPUs? With the
original
BeOS, you were stuck at the 604.

It’s worse than that. My port will at first only support the latest
CPUs. Older models will possibly be added later, but I can only work on
OpenBeOS versions for computers that I own.

17. How happy are you with the support you’re getting from the
community? Are you getting feedback? How regularly is the work on
OpenBeOS being carried out?

That’s 2 different questions, isn’t it? Of course work on OpenBeOS is
being done regularly. Our developers are spread all over the world, so
we can say without exaggeration it is being worked on right round the
clock. I am very happy be a part of the (Open)BeOS community.

18. Do you think that BeUnited will manage to keep all the flavours
of
BeOS together?

We’ll have to see whether it’s needed. Even so I hope that’s how it all
turns out.

19. Quick question: Do you work on OpenBeOS full time or in your
free
time?

Ha ha! If only someone were to pay me, I would gladly work on it full
time. But I am still studying, and I only devote part of my limited
spare time to the project.

20. What are you hoping for from BeOS? Will it make a comeback?

I just hope that it can become a credible alternative to what’s out
there now. I don’t personally care about the numbers of people who
notice it. Small market share has its benefits. But what matters is
that it achieve enough presence in the market to allow companies
committed to developing BeOS software to be viable. That’s not what
determines my personal commitment to the OS, but I would be very
pleased to see that happen, since I would be able to earn a living from
BeOS. Besides, I have a lot of other ideas that I would like to develop.

21. Thank you for the interview.

Don’t mention it.