[openbeos] Re: binary compatibility
- From: Fred McCann <booleanman@xxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Sun, 26 Aug 2001 22:06:02 -0400
On Sunday, August 26, 2001, at 09:40 PM, Daniel Reinhold wrote:
>
> Here's a snippet by Eugenia from OSNews:
> ------------------------------------------------------------------
> Our Take: I am sorry if I sound negative, but after discussing details
> about the Open BeOS project with several ex and Be engineers the last
> few days, they all came to (an easy for them) conclusion that this
> project is going nowhere. Exactly because there are shortcomings in the
> BeOS design, and because not all bugs or features of BeOS are known
> from outsiders, it will be impossible to replicate the technology
> without having the original BeOS source code. But what the team CAN do,
> is to aim for source compatibility, not binary. While the threading,
> bugs(!), locking and other details will behave differently between the
> BeOS and OpenBeOS, it is already times easier to port BeOS applications
> to OpenBeOS than trying to run them unmodified. This way, if the team
> become really dedicated, we may see some good progress in less than a
> year, othewise it will take years to come even into an alpha state
> ------------------------------------------------------------------
>
> What do you think about this?
>
> She may be right. At least as far as what is worth aiming for. I mean,
> technically, you can't say that its *impossible* to implement binary
> compatibility -- nothing's impossible in programming given enough time
> and resources -- but it might well not be worth it. Besides, what
> progammer wants to bust his ass month after month carefully trying to
> recreate some else's bugs?!
>
> Still, it's a deviation from the original charter. Should we re-think
> this?
>
Well, it does seem that shooting for binary compatibility is pretty
bold; but probably not impossible. I think what's really important is
what Be stood for, and I don't mean Internet appliances ;)
The original Be philosophy was that legacy code and old paradigms come
at the cost of either stability, performance, or both. That's why they
made a new OS from the ground up drawing from modern OS design concepts,
built with an object oriented API. From a developer standpoint, I can't
tell you how appealing this was. Have you ever written code on Unix
systems? In order to understand a lot of the layers and API's in the OS,
you need a history lesson to comprehend why certain trade-offs were made
and you have to accept that they are there for backward compatibility.
The beauty of Be was that there were no ties to the past, no old hacks;
just a clean design. This was also manifest in the original Be hardware.
The BeBox was built on a multiprocessor RISC architecture. The design
was far ahead of it's single processor x86 peers of the time. Even
though Be Inc was a financial failure, the system they made was a
success. It was a rock solid, high performance, elegant system. Be was
willing to forsake existing code bases to strike out in a better
direction. There was some backward compatibility (take POSIX
compatibility for example), but only in as much as it didn't compromise
the design.
At this point, we are at total ground zero. We have no BeOS code, and we
may never have it. We do know the general design concepts of the BeOS,
and we have their API reference. In essence we have a blueprint and no
bricks. I say that if we stay true to the spirit of the original BeOS,
we will succeed. We must make it our goal to reimplement the blueprint
to the best of our ability. It is my hope that we can meet our goal of
binary compatibility. As pointed out on this list, keeping the remaining
Be community afloat depends on creating some sort of viable distribution
as soon as we can. If this were to run existing applications unmodified,
this would be a great boon to the community.
In the event that we cannot achieve this goal, I would be just as
satisfied if we had source compatibility. In the tradition of the BeOS,
some things may need to be left behind to create a better system. At
this stage of the game, I think we should aim for the stars. If binary
compatibility is an unreasonable goal, I'm sure that will be evident as
we progress.
- Fred
Other related posts:
