[openbeos] Re: The world as we know it

  • From: "Nathan Whitehorn" <nathan.whitehorn@xxxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Mon, 23 Sep 2002 20:40:50 EDT (-0400)

> >> "Nathan Whitehorn" <nathan.whitehorn@xxxxxxxxxxx> wrote:
> >> That's nice, but if you don't understand why we are aiming for 
> > > binary 
> >> compatibility (well, for you as a PPC user, we don't even do that 
> > > :-
> >> )), 
> >> please, just accept it. Be patient.
> >
> >I'm supposed to take your word for it?
> I'd wager Axel's word is at least as good as yours, and you would 
> have 
> us take it for your arguments. =P

In the rest of his mail he (and I in mine) provide arguments better 
than "trust me".

> >just need a single person. And would you seriously support keeping 
> > the 
> >seriously over-extended and generally screwed up API we have now?
> What system-wide API are you comparing BeAPI to that it comes out 
> looking so bad?  Sure, there are some limitations and decisions 
> which, 
> in retrospect, were not very well thought out.  BeAPI is at least 
> pleasant to work with, which is a far cry from "tolerable" -- the 
> best 
> that *any* other API I've ever worked with has managed.  Nobody here 
> is 
> claiming it's perfect; there wouldn't be a point to any of our work 
> if 
> it was -- we'd just use R5 and be permanently blissed that we were 
> using 
> a perfect OS!

Compared to everything else in existence, it is a joy. Compared to what 
it *could* be, it is tolerable.

> >> > Exactly. Which is why I'm arguing against binary compatibility 
> > > > for 
> >> > the 
> >> > time being.
> This argument is *over*.  Let go of it and move on already.
> >Wonderful. That's when I would add a new API too. And we would of 
> ???  This flies in the face of virtually everything else you've said, 
> which has boiled down to "all new/heavily modified API *now*!"

Except that I forgot to add that I would support making this change in 

> >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.
> Are we somehow giving people the impression that we are as dull and 
> unintelligent as this paragraph would make us seem?  I hardly think 
> we 
> would be capable of achieving our stated goals were that the case.  
> Perhaps you merely suppose we are incapable of seeing the "big 
> picture" 
> of the system-wide architecture.  Interesting that you are able to 
> draw 
> this conclusion without the benefit of being included in all of the 
> private communications that inevitably go on between team members.  
> Let 
> me set your troubled mind at ease: we are well aware of the 
> limitations 
> of the system and are, even now, plotting their demise.  All things 
> in 
> their own time, etc., etc.  Indeed, the scope of our perception 
> extends 
> well beyond the mere architecture of the system to include the 
> applications which rely upon it and further to the users who rely 
> upon 
> the applications.  Those considerations have ramifications on our 
> work 
> on the system itself; ramifications which, to one who is not looking 
> further than the system, might seem acts of self-limitation or 
> sabotage. 
>  This is an organic process and environment, and as such it will 
> never 
> be perfect, only a careful balance between all of the competing 
> influences.

I am arguing nothing of the kind. What I *am* arguning for is better 
communication. Just because my bailiwick covers some component of the 
kernel doesn't mean that that isn't relevant to part of the app_server, 
or the storage kit API. Because everybody is coding one small little 
thing means there is limited global dialog, something necessary to 
improve the system *as a whole*. Sure, it's efficient, but at what 

As for your charge that I'm not privy to "all the internal 
communications", I have had experience with the net team, which, I 
believe, is instructive here. People code things simply because it 
seems to them the best way (David Reid's proposed kernel mods are a 
case in point), don't talk to anyone else about it, except perhaps to 
say that that is going to happen, and then do it. Usually, people just 
pay attention to what they are doing and nothing else.

> If you choose to continue to ignore the wider scope, what you bring 
> to 
> the table will become increasingly irrelevant.  Already, you are 
> spending time arguing against decisions which were made nearly a year 
> ago and are effectively cast in stone.  There is no profit in this 
> course and I, for one, find it curious that you insist on pursuing 
> it.

The decisions made "nearly a year ago" were short-sighted then and are 
short-sighted now. I argued against them then; I continue to do so now. 
Just because something has been decided doesn't mean that was the best 
thing to do then or, more importantly, remains the best thing to do 

Fortune Cookie Says:

The state law of Pennsylvania prohibits singing in the bathtub.

Other related posts: