[openbeos] Re: The world as we know it

  • From: "Nathan Whitehorn" <nathan.whitehorn@xxxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Sun, 22 Sep 2002 12:47:16 EDT (-0400)

> "Nathan Whitehorn" <nathan.whitehorn@xxxxxxxxxxx> wrote:
> > The fact that we are doing it doesn't make it any less pointless. 
> > It's 
> > like Bush wanting to invade Iraq. It's idiotic, dangerous, horribly 
> By any means, comparing those two things is hopefully the direct 
> cause 
> of an insane brain...
> The only thing which is pointless is this discussion; the goal to 
> recreate R5 isn't just pointless because you don't understand why we 
> are doing it.
> If you don't want to get it, perhaps have a look at B.E.OS - AFAICT 
> they mostly share your opinion in that regard.

If my explanation of why we are doing it is incorrect, please enlighten 
me. And I must say I am much, much closer to OBOS than B.E.OS 
philosophically, for reasons that I remarked in my original e-mail.

> > > And who says we can't introduce a new API one week after R1 is 
> > > out? 
> > > :
> > There are quite a few structural issues behind an API. The API 
> > doesn't, 
> > for instance, support non-rectangular views because the app_server 
> > doesn't. And the app_server doesn't partly because the API is based 
> > on 
> > rectangles. The API isn't simply a wrapper for the internal 
> > operations 
> > of the OS, it often *is* the internal operation of the OS. And, 
> > also, 
> > the number of people here against any modifications, anywhere, at 
> > any 
> > time to the API is really quite extraordinary.
> The problem is that we don't have one person who can decide about API 
> changes - changing the API has a lot of impact on the whole BeOS. 
> It's 
> not a trivial thing.

Why do we need one?

> And and API also doesn't implicitly cause any structural issues - at 
> least that doesn't have to be a restriction. For example, the 
> OpenBeOS 
> kernel will support aliases in R1, but there might be no API to 
> access 
> this functionality.
> An API has to be well designed, because when we get to R1, we are 
> mostly stuck with it. Just have a look at our MDR - the API is still 
> poor in many regards; if we had to be binary compatible now and 
> forever, we'd have a tough time fixing all those issues.

Exactly. Which is why I'm arguing against binary compatibility for the 
time being.

Fortune Cookie Says:

Don't you feel more like you do now than you did when you came in?

Other related posts: