[openbeos] Re: binary compat [was Re: Re: BFS and encryption.]
- From: "Michael Phipps" <mphipps1@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Wed, 31 Oct 2001 22:15:55 -0500
>whoah Marcus, calm down, stop seeing conspiracys everywhere.
>im not trying to start a flame war, and im sure neither is helmar.
We really are all on the same side here. Please, everyone, treat each
other kindly.
>there have been a few compelling reasons for breaking binary
>compatibility mentioned back when R5 was still being worked on be
>be,inc (gcc 3.0, better kernel virtual memory , performance issues,
>etc), so it might not be a bad idea to consider doing so if there are
Of these, only GCC requires a real binary compatability break. And that
is only maybe.
>compelling reasons for us to do so. yes, it would be a good thing to
>keep compatability if possible, but it should not be so sacred that we
>get into the mess of trying to keep compat with a 20 year old os. ;)
>Be,inc completly broke binary compat once, and there were minor breaks
>each release.
The only decision we have reached on this line is that R1 will *NOT* break
compatability unless it absolutely has to.
>that being said, if you can keep binary compat please do, it would make
>everyones life simpler. i will be trying to. its really the kernel/IK
>people that will make or break it.
The facts, as I see them, are this:
binary compatability means that the kernel can load an R5 app. Link it to
appropriate .so's. And execute it.
It has *nothing* to do with the internal workings of the kits. Only the
interface (i.e. things like number of virtual functions)
must remain the same. That is why GCC3 breaks bin compatability - they reworked
the whole way that the
binaries look. That is *not* to say that it would be impossible to have OBOS
read *both*. Caveat - I have not looked
in depth at GCC 3. The ELF loader is generic. The linking mechanism should also
work - the names are different, but the
methodology should work. In fact, the way I see it, we could even build
libbe.so (compatability version) and libbe.so (new version with GCC3). New
apps, that know about the new version would load it. Note that I didn't
indicate the mechanism for determining. That is alwasy flamewar fodder. :-) The
kits could, though, be built with GCC3 and the interface with 2.95 since the
.so's and the servers talk only via BMessage.
>second, helmar is on our side. OBOS and beunited both want the same
>thing. do you think linus gets this worried when the ceo of red hat
>makes a suggestion?
Hey - worrying is my job. :-) Helmar (and Deej) and I talk and understand each
other pretty well, if not agree always.
They have a very vested interest in our succeeding. Remember that even if they
license the code, they get code that is
a) unknown - 6 million or whatever lines of code that NO ONE who can work on it
knows.
b) aging - most of this stuff is > 4 years old
c) filled with false starts - BeOS rocks. No slams here. But there have been
numbers of changes of direction, false starts and so on. Our code sets out to
fulfill a known purpose from the beginning. Legacy free code.
d) a ways off - the vote is, what, this month? Next? I forget. I really doubt
that agreements can/will be made and code moved before 1/1/2002. That means
that we have a 4 month window during which to move this project to the point of
completion. Who knows? By that point, we could be far enough along that there
is obviously no point in signing a licensing agreement, since our code will be
ready soon and be free.
To recap:
1) Everyone be nice! This is supposed to be fun!
2) Unless someone can really prove vast hardship, we will be R5 binary
compatable for our first release.
Sorry if that sounds dictatorial, but a decision had to be made and was (some
time ago).
>adam
>
>
><snip>
>>You are Helmar Rudolph! Your personal take is to license
>>the BeOS source code from either Be or Palm. You are not
>>one of the OpenBeOS programmers.
>>
>>Why do you recommend us to break binary compatibility now?
>>
>>I think: Either did Be/Palm tell you that you won't get the source,
>>and you see the OpenBeOS as YOUR chance. Or you are trying to
>>confuse us, because you see us as a threat, and try to get
>>rid of us. I really think it the latter, since I don't expect that
>>you already get *any* resonse from Palm/Be.
></snip>
>
>
>In a world full of Windows, we're handing out rocks.
> -BeOSRadio
>
>HTML belongs in email the way vinyl siding belongs on gerbils. Sure
>its cute at first, but its just plain WRONG!!!
>
>It is reassuring to consider that in spite of the many historical
>expectations of end-of world scenarios, armageddon, natural disasters
>and catastrophes, and general hysteria of the gullible, that the cosmos
>rolls on, utterly indifferent, uncaring, and oblivious to any arbitrary
>and capricious enumerations counted by man. - Ross Milner
>
Other related posts:
