[openbeos] Re: BFS and encryption.

"Helmar Rudolph" <helmar@xxxxxxxxx> wrote:

>My personal take is that breaking binary compatibility at
>this stage is not an issue as long as it leads to
>significant improvements.

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?

This is stupid. 

As I could show with libmedia.so, it is not necessary
to break binary compatibility. You can create a library that is
binary compatibile with all the applications using it,
except the system apps like media_server and media_addon_server.
Even the Media Preferences app works with the replacement.
The server apps of cause need to be rewritten, but this is part
of replacing the whole kit, and not breaking anything.

I can even play Doom using the replacement lib, and also 
libgame.so runs fine with the replacement lib.
The only implemented parts so far are the realtime memory
allocation functions, as this game uses them. The other functions
don't do much yet, but will be implemented during the following
weeks.

>The BeOS 'as a whole' has been pretty idle, and developers
>still active won't mind making the necessary changes to
>cater for the broken compatibility - there aren't  many of
>them to begin with.
Yes, some developers might really "port" their apps to 
a non BeOS compatible platform. But many won't.
And it will create major, unnecessary confusion.

>The last thing I'd like to see is this: [x]BeOS gets revived,
>gets reported about in the press, gets sold and marketed,
>gains commercial developer support, resulting in many more
>apps than we currently have and then _POOOFFF!!!_ a break in
>binary compatibility is thrown at them. Rather do it now -
We do not need to break binary compatibility. You can always
ADD new functionality, without removing the old one.
If we decide to make all kernel semaphores into C++ objects,
we can do so, and still keep a wrapper layer that happily
export the old functionality transparent to the apps.
You could even write a loader application that can load gcc 2.95 
applications in a gcc 3.0 environment.

>while things are slow and an opportunity to adapt or weed
>out still exists - than doing it later, when you have
>a momentum going that goes way beyond what OpenBeOS is doing.
>
>What do you think?

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.

I will keep binary compatibility with the media kit replacement,
it is possible, and doesn't stop one from adding improvement.

regards
Marcus, OpenBeOS media kit team leader

Other related posts: