[openbeos] Writing a BeOS Replacement - By Daniel Switkin (osnews.com)
- From: "Anil Joy Varughese" <anil_joy2k@xxxxxxxxxx>
- To: <openbeos@xxxxxxxxxxxxx>
- Date: Tue, 24 Sep 2002 14:54:41 +0530
Writing a BeOS Replacement
By Daniel Switkin - Posted on 2002-09-24 00:44:27
Daniel Switkin, a long time BeOS developer and former Be Inc. employee,
has submitted an editorial on "Writing A BeOS Replacement". It aims to
bring together the various efforts out there and define a plan which has
the greatest chance of success. Click Read More to see the entire
article from Daniel.
Part I
A few words before we begin:
1. This is not a half-hour brainstorm. I read FAQs, I researched, I
thought about it, I wrote it, I put it away, and I rewrote it. Please
show me the same courtesy before clicking the Post Comment button.
2. Yes, I am a former Be employee.
3. No, that does not make me right or my opinion more important.
INTRODUCTION
I became a BeOS developer around 1997. I used to boot DR8.2 off a Zip
disk in the public labs at school, because I didn't have a BeBox or
PowerMac. By the time R3 came out and I could install it on my PC, I was
hooked. I wrote Anime, GIFTranslator, and ImageViewer, among others.
When I graduated, I applied to Be and got a job. I worked as a DTS
Engineer for about nine months. Then I moved to Tascam, where they were
making a pro audio device running BeOS on an embedded PC. I worked on
that for two and half years until it shipped recently.
All that is to say, I lament the death of BeOS as much as anyone. I've
used it every day for four years as my primary, if not my only OS, and I
don't see another platform I'd like to move to. I'm also saddened at the
demise of Be Inc., as some of my friends lost their jobs, and I'd guess
most of us lost money in Be stock. So I understand the desire to
recreate the operating system. I really get it, and I'm tempted to help.
GOALS
Just as a good engineer resists the temptation to bang out code right
away, and thinks about design first, I'd like to step back and think
about the goals of such a project before getting into the
implementation.
Some or all of these would seem to be desirable:
- a large user base (comparable to BeOS at its peak, or larger)
- a strong developer community
- a wide array of applications (perhaps commercial in the long run)
- strong hardware compatibility
- press attention/coverage
- hardware vendor support
I want to make clear that these are my assumptions for the rest of the
article. I have no interest in and no right to tell people what to do
with their time. If you're only interested in a hobby OS, for example,
please ignore what follows. If you specifically want the challenge of
writing an OS from the ground up, I wish you good luck. I'm also not
trying to support or recommend one BeOS replacement over another, as I'm
not affiliated with any of them.
MAKING IT HAPPEN
So with these goals in mind, here are my opinions (nothing more, nothing
less) on how to achieve them:
1. Depending on how you count, there are at least four different efforts
to make some kind of open-sourced BeOS replacement. As many people have
pointed out, this needlessly divides talent and manpower among parallel,
if not competing, projects. But it also does something much worse: it's
the format wars all over. Beta vs. VHS. Minidisc vs. DAT vs. DCC. Not to
mention the disaster that is the writable DVD war. In every one of these
cases, customer adoption was greatly slowed down, and enormous time,
effort, and money was wasted. In our case, users and developers will
take a wait-and-see approach until a winner emerges. We need a single
platform with a single binary format that everyone can get behind. Let's
learn a lesson from history, and build one BeOS replacement together.
2. Let's talk about hardware support, as this was one of BeOS's greatest
failings. Without full featured drivers for a large variety of current
and future hardware, this effort is doomed to the same fate. I believe
it is unrealistic, to say the least, that the relatively small number of
people working on BeOS replacements could hope to create the needed
quantity of drivers. Not only because of the manpower required, but also
due to the lack of funds it would take to purchase documentation under
NDA from some of the leading companies. Additionally, even if you could
manage binary compatibility with existing Be Inc. drivers, that only
gets you support for hardware which is already outdated today, much less
when the first BeOS replacement ships.
I think the most viable solution is to base a BeOS clone on another open
source kernel, probably Linux. Consider:
- Even if you could raise the money needed to buy NVidia documentation,
and NVidia was willing to sell it to you, you still couldn't write a
driver of the same quality and completeness in your spare time as their
own engineers who do this for a living. In addition, you'd need to
undertake this huge effort from scratch, and maintain it, whereas their
Linux drivers are available today and will be maintained for free.
- On day one, without typing a keystroke, you have a booting kernel,
filesystems, a network stack, a huge complement of drivers, a shell, a
compiler (more on this later), and tons of command line apps. And all of
that is written, maintained, and tested by other people for you. The
size of your task is enormously smaller, which means the likelihood of
finishing is much greater. And you could always reimplement any of these
components you weren't happy with in later versions.
- Unless you as a developer want the challenge of writing a kernel from
scratch, it's important to realize that users don't pick a platform
based on the kernel. Look at how many people ran MacOS 9 and earlier.
Cooperative multitasking in the 21st century - are you kidding me? I
don't want to debate whether the BeOS kernel was better than Linux, or
whether NewOS is better than both. The point is, Linux has gotten good
enough to use as a base, and lots of knowledgeable people continue to
improve it. The hardware support it brings (especially from hardware
vendors themselves) more than outweighs any disadvantages.
Part II
3. In the past I was on the fence as to binary compatibility with R5,
but I'm now firmly against it. The original argument was that many
popular BeOS applications were closed source, and would therefore be
lost without binary compatibility. That's a very good point, made by
Erik Jakowatz and others. But in recent months, many
abandoned-yet-popular apps have been donated to the community. Among
these are Gobe Productive, Postmaster, ArtPaint, and Pe, and this trend
seems to be growing. Not to mention that the most important application
a desktop platform needs, a web browser, is already open source in the
form of Mozilla. (NetPositive trails too far behind current web
standards to be usable much longer, and the code would be too hard to
rejuvinate even if it was available).
Now consider the disadvantages of binary compatibility:
- The BeOS APIs are showing their age. There are design flaws, naming
inconsistencies, outdated implementations, etc. For example, pointers
are commonly used where references would be better. You SetEnabled() but
you MakeFocus(). BFont does not derive from BArchivable. BWindow and
BApplication both have pulse functionality, so why isn't it in their
common base class, BLooper? And what exactly does BView::SetDiskMode()
do? (Hint: it's not in the Be Book) The freedom to make these changes
while retaining 99% source compatibility is well worth it, not to
mention not having to deal with maintaining virtual function ordering,
padding to maintain object size, etc. There are also BeOS classes which
do not have enough reserved space for fragile base class protection -
this is a good chance to fix them.
- Binary compatibility ties you to gcc 2.9.x, since the 3.x series tool
chain broke compatibility for C++. So first of all, you're stuck with a
compiler that will not evolve or get bug fixes. It will not generate
optimizations for the Pentium 4 or future CPUs. But worse than that,
it's buggy. As I recall, turning on -march=pentiumpro will generate
wrong floating point code in some cases. Using -O3 often produces slower
code than -O2. And the STL implementation is horrible. Bitset is broken.
Using += on a string trashes memory. Calling operator== to compare a
string to "" returns the wrong result. OpenBeOS proposes to use STLport
instead, but I don't see how this can be done and maintain binary
compatibility. The inline nature of STL means that all the header code
of the R5 STL has been compiled into existing applications, yet still
depends on libstdc++.r4.so. So you can't change the contents of this
library, and you can't remove the old STL code from the apps out there.
Would you simply ship this library in binary form only, then have a new
name for the STLport lib? If someone knows a way to make this work, I'd
be interested.
- How will you achieve binary compatibility with Be Inc. apps that use
unpublished APIs? Perhaps you can reverse engineer the magic flag which
Workspaces passes to the app_server in its constructor (the entire
contents are drawn by the server into an empty view). But what about
kernel support for bdb? What about DriveSetup? What about the dozens of
private header files that were in the BeOS source tree which could be
used anywhere? As a data point, consider that the OpenBeOS team tried to
reverse engineer the protocol between the app_server and input_server,
and gave up. All of the extra effort it takes to remain binary
compatible will be wasted when the important apps fail to run.
- Conversely, many of the Be Inc. apps that would run aren't worth it.
Take some of the preferences apps for example: Fonts, Menu, Mouse, etc.
First, they're all out of date. Second, they either save their settings
in obscure ways that would be inconvenient to use, or they interact in
private ways with the system and aren't usable (how does the Network
panel restart the net_server?). Very few of them would be hard to
rewrite. Plus apps like BeMail, CodyCam, Pulse, and Magnify are already
open source, and of course Tracker and Deskbar. The only significant app
that came with R5 that I would miss is BeIDE, which I admit I like alot.
I believe that in order to attract quality developers and to get them to
build large, full-featured applications, you must provide modern
development tools and a well-documented, clean API. Being permanently
stuck in 1999 does not get you there.
4. I think source management and licensing are important. I think any
project would greatly benefit from using Perforce, which is free for
open source projects. (I don't know anyone who switched from cvs and
wants to go back). But whichever source management tool you choose, the
source needs to be available to the public. Not necessarily with write
permissions, mind you, but at least in read-only form. I won't pretend
to have the experience managing large projects to tell you how this
should be done. But I feel that letting anyone check code in on one
extreme is just as bad as not showing the code to anyone outside your
group on the other extreme. The most successful projects out there
(Apache, the Linux kernel, etc.) seem to have a model where
contributions are encouraged, but checkins are closely scrutinized for
quality.
Licensing seems to have divided the largest two projects, OpenBeOS and
BlueEyedOS. I'm happy to see that both reject the GPL as an option, due
to its viral qualities and the fact that it discourages commercial
development and contributions. OpenBeOS has in a noble gesture gone with
MIT, also known as the "truly free" license. I admire this, and have no
problem with it personally, but as Michael Phipps points out, it
provides no protection for the authors in the form of requiring changes
to be submitted. BlueEyedOS has adopted an as-yet-unnamed license due to
concerns about code forking and commercialism. Again, I understand and
can sympathize, but I think the fact that the code isn't available to
the public feels closed to many people. What I haven't heard is a strong
objection to the LGPL license from either side, or for that matter the
Mozilla license. Both reject the viral aspect of GPL, and while LGPL
requires all changes to be submitted, Mozilla only requires changes to
existing files to be released, thus allowing proprietary extensions.
Perhaps the two sides could consider one of these as a middle ground,
where the source is available but also well managed.
As for code forking, I don't know if it is absolutely preventable if you
wish to be open source. However, many successful projects out there
don't suffer this problem. Perhaps the best defense against it is to
keep the project active and open to input, so that it neither stagnates
nor causes excess disagreement (obviously you can't please everyone all
the time). It's also possible that a project of a certain size and
complexity becomes pointless to fork, since it's just too hard to take
it in another direction without a large team. Given the dwindling number
of BeOS enthusiasts out there, this may not come up.
5. I understand that the number of people who have joined these projects
and the work they've done already is cause for optimism. But I prefer to
be more realistic about how hard this task is. Take the app_server, for
example. I worked at Be, and I've seen the code, but I am not remotely
qualified to rewrite it. I would guess that maybe ten Be employees are.
Yes, it's that hard. My advice, and I don't like to say it, is to
consider not supporting certain features of both the app_server and BeOS
in general, at least in the first version. For example, BWindowScreen
and BDirectWindow probably don't make sense. Maybe drop 15 and 16 bit
graphics mode support (code size can be seen as colorspaces ^ 2, since a
bitmap in one colorspace must be able to draw into a bitmap of any other
colorspace). I agree, it's a compromise, but v1.0 will always be just
over the horizon if it must contain everything. As interest in BeOS and
the community both shrink, time to release becomes more and more
important (many people think it is already too late).
CONCLUSION
Writing a BeOS replacement is a huge task. But it's only worth doing if
you plan a strategy that gets you to your goals. If you make the same
mistakes as Be Inc. then you've just wasted several years of effort.
There needs to be one united project that developers and users can get
behind. Hardware support is critical to making the platform succeed, and
that means leveraging all the work that has gone into Linux. Binary
compatibility sounds tempting but ultimately has too many downsides. The
source code needs to be available but well maintained. And lastly, some
pieces may need to get left out in order to succeed.
In closing, let me put my money where my mouth is. If we as a community
can work these issues out, I will donate the source of GIFTranslator and
ImageViewer to the new OS. I will also recompile Anime and my other apps
for the new platform, and encourage other developers to do the same. For
those unwilling to open source their work or recompile, we could set up
a service to rebuild their apps and make binary-only releases,
guaranteeing the privacy of their source code.
I'm eager to hear your thoughts. If you don't want to comment below, you
can write privately at software@xxxxxxxxxxxx
Other related posts:
- » [openbeos] Writing a BeOS Replacement - By Daniel Switkin (osnews.com)
