[openbeos] Re: One spoon at a time
- From: "Michael Phipps" <mphipps1@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Sun, 19 Aug 2001 08:14:03 -0400
>How do you eat an elephant (the saying goes)? One spoon at a time!
Agreed! :-)
>Several people have commented on how crazy an OpenBeOS project would be
>because it would be such a huge task to undertake. Well, it's
>definitely not trivial, that's for sure. But I don't think it's quite
>as bad as many make it seem. Here's my reasoning:
>
>a) the user interface is already taken care of
>b) the design is already taken care of
95%, I will agree. The "clean room" approach will require some internal design.
Fundimentally, you are correct.
>The user interface is already open sourced with OpenTracker and
>OpenDeskbar. Ok, that's not the entire user interface -- you do have
>the 'app_server' drawing windows, etc. But basically what you would
>call the user shell for the OS is already done and that's an extremely
>important and large part of any OS implementation.
Yes. App server is one of the big pieces. :-)
>The design is already done -- it's called the BeOS API. It takes years
>of thought, prototyping, hashing around ideas, tossing them out, and
>tweaking to come up with any design, let alone a good one. Be engineers
>have already done this. We just have to re-implement the design. Yes,
>implementation is a big thing, but it's a helluva lot less than having
>to design and implement together. Using the BeOS API removes man-years
>from the project time table.
>
>Of course, what I said only applies if OpenBeOS is used to create a
>source/binary compatible version of BeOS R5. If it becomes a place
>where everyone decides to test out his favorite operating system theory
>and/or try to insert his 'I-always-wanted-this-in-the-BeOS' feature,
>then the project will never finish.
I am quickly coming to the point where a decision will be made on these things.
We have (on this list) batted around ideas of:
1) Using some alternative kernel
2) Using some alternative gui system (X11, for one) with a BeOS layer.
3) Develop BeOS as it is, or something more advanced.
4) Whether or not we are even going to do this.
The way I see it is this:
We have BeOS and the BeBook and test programs. We want to get source code.
Once we have source code, people can port the pieces to any OS they want.
We have a working kernel, and working individual kits.
We can have several projects to release pieces individually. The fact that team
X
is way ahead/behind team Y doesn't effect anyone. Because for a 1.0, we are
testing
and proving against R5.
I don't want a better Linux. If I wanted that, I would go play in Linux land. I
don't want a
better X11. Same deal. I want BeOS and I want its development to continue.
OpenBeos
is, in my mind, a means to that end.
That rules out 1 and 2.
As this post points out, what we are doing is very ambitious.
I don't think we want to bite off anything extra. That rules out 3.
If (and this is my own fantasy) a small company like what Be was 3 years (pre
going public)
were to emerge from all of this with an attitude like Be had, fewer, but more
focused engineers
and a great source base to start from, then I think that there is little point
to continue with this.
If Palm blows the community off (either directly or with "we need to study this
further"), well,
then lets go for broke.
If the result is in between, well, then let's see.
I am optimistic,
Other related posts:
