[openbeos] Re: openbeos Digest V2 #2
- From: "Michael Phipps" <mphipps1@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Wed, 02 Jan 2002 19:20:41 -0500
>This is my first post so try to be gentle.
Welcome and thanks for posting! :-)
>This is going to raise a few hackles, but I also believe that trying to
>provide binary compatibility with R5 is a mistake. If it happens, well
>that's great, but why strive for it? Eugenia has pointed out some of the
The concept is that we have little to lose. As others have pointed out,
(and this is especially true in kernel land - the calling conventions are
different,
plus it is in C, not C++) replicating the API != replicating every bug. To
*some*
degree, I am not too concerned with replicating bugs. If there is a *bug*, not
a
design decision issue, I would have to be convinced to replicate it. AFA design
decisions, each really has to be weighed on a cost/benefit basis. Let's pick
something
outlandish - rewriting all of the class/method names in Esperanto. :-) There is
high
cost and no benefit. But many things are free or very cheap (say, adding a C++
class for Audio CD playback...). In those cases, why not go for it?
>pitfalls in the BeOS kernel, why would we want to build on that? At some
>point a new kernel will have to arrive from somewhere, so why not bite the
>bullet in the early stages? You could spend a lot of time getting the
>various kits to work with the Be kernel, only to have to change it all again
>to get them working with the new kernel. Lets not forget, Be were not afraid
>to break binary compatibility in order to improve the OS, and if they were
>still around today they would have to do so again to move to gcc3.
I haven't forgotten. But 2002 != 1999. There aren't a host of healthy companies
and individuals who are slavering to write BeOS apps.
>What's wrong with starting afresh, with a new kernel, along with Be's
>original goals and APIs as your blueprint? You could argue that you want the
>current apps availble for BeOS to run on it, but by the time OBOS comes out
>with R1, most of the apps will be so old you won't want to use them. Hands
>up those who can swear they will still be using GoBe Productive 2 on
>BeOS/OBOS in a years time as their main work platform? If GoBe decide to
Most BeOS users.
>update the package they would have to recompile it anyway so where is the
>harm? A 100% source compatible platform is a lot more useful.
And that is our fallback position. That is guarenteed. But I look at it this
way - I implemented
a whole kit's API and successfully ran it in place of Be's. I showed that it is
POSSIBLE.
That is why I did it. Unless we shoot for BC, no one will even try. If we make
it a strong
goal, people will be more careful with their headers and use the official
compiler.
If those measures prove to be not enough, we will do what we have to do. :-)
>As I said at the top I'm no kernel hacker, and you could view this as just
>the rantings of the lunatic fringe, so feel free to shoot it down in flames.
Never. I *require* that people on here are polite. This is spare time
activities for us.
No one wants to get yelled at in their spare time. Polite explanations are more
than suitable.
:-)
Other related posts:
