[openbeos] Re: The world as we know it
- From: "Nathan Whitehorn" <nathan.whitehorn@xxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Sun, 22 Sep 2002 12:16:52 EDT (-0400)
> "Nathan Whitehorn" <nathan.whitehorn@xxxxxxxxxxx> wrote:
> > If the cruft is in the API (as it often is) or in anything
> > necessary
> > to
> > maintain binary compatibility, it will necessarily continue to be a
> > part of R1. Further, most of the cruft that is in R5 (as far as I
> > can
> > tell) is still there only for compatibility reasons. If we
> > duplicate
> > compatibility, we therefore duplicate cruft.
>
> At least for MDR, this is true, but we want to achieve binary
> compatibility, and that can't be done the way you propose.
And if it can't? Is binary compatibility really that important? I can
think of only one common, closed-source, extant BeOS application: Gobe
Productive. And this is only an issue because the developers seemed
unlikely to recompile it for us. But, if I remember correctly, even
this has changed now...
> > > And getting consensus is the hardest thing which was why R5 was a
> > > good
> > > starting point.
> > So you have a consensus to do something essentlially pointless...
>
> If you don't get it, well, I can't help you.
I understand the rationale. We can't get Be's source, so we'll make our
own. The original plan was for Be to improve their software. That
failed. So we'll improve it for them. But Palm won't give us source. So
we make our own and go from there. That, as far as I can tell, is that
basic stategy of OpenBeOS. I am arguing now, as I have in the past,
that that strategy is flawed. It was a modification of an existing plan
that no longer makes any sense. We might as well figure out where we
want to go and aim for there, instead of writing a heck of a lot of
code, figuring out where we want to be, tearing it down, and beginning
again. The more the future of the project is different from the
present, the more code has to be *rewritten*. People don't like to do
extra work. As such, developing R1 as R5 ensures conservatism in the
evolution of OpenBeOS. At, last I could tell, BeOS was about throwing
out compatibility, throwing out conservatism, and building what should
have been built all along.
> > You *can* run ideas, once they have been coded. Or you can skip the
> > ideas, and just code mindlessly.
>
> Hmm??
Ideas become software. Once they are software, they can be run. Or you
can make software without ideas. You can clone what exists. That will
run too. But, tens (or hundreds) of thousands of lines of code later,
it will just be what you always had.
> > Just to make things clear, I *am* a developer. What I'm arguing
> > against
> > is the lack of foresight of the OpenBeOS project.
>
> Well, from my POV, you are lacking of foresight, and that's why you
> want to go another route :-))
>
> OTOH how would you like to design something from scratch in a project
> as big as OpenBeOS? Should everyone get a word? Should everyone have
> to
> come up with a reference implementation to be taken serious?
> Having a fixed feature set including a reference implementation (R5)
> is
> a gift, and one that shouldn't be overseen so easily.
I suppose it is a useful thing. But a good one? I'm not so sure. By
viewing R5 with such an uncritical eye, we risk duplicating all its
mistakes along with it.
As for how I would design something like OpenBeOS from scratch, I would
simply create a general idea and aim toward it. As that is discussed/
coded, we discover smaller and smaller things that should be changed.
Essentially, I would use the coding process as examination. It's
something that has always worked for me.
Isn't R5 that process, you say? It is indeed. Starting to make R5 is a
wonderful place *to begin*. But it is a process that should never be
finished. If we succeed in coding R5, we have gained nothing, for we
will have copied blindly, without critical examination. Nobody writes
code and says: this architecture sucks! or wouldn't it be nice if I
could...? There are terrible design decisions in R5. There are places
crying out for new architecture. There are great gaps in the API. But,
in cloning, we ignore them. True, we see the errors, and correct them,
in fits, with individual routines and modules, but not on a large
scale, and, as a result, I am afraid that we may succeed in cloning R5.
And nothing worse can happen to this project that to have spent all the
time and effort we will have spent when we are done without seeing what
it is that we are making.
-Nathan
--
Fortune Cookie Says:
"I used to get high on life but lately I've built up a resistance."
Other related posts:
