On Sun, 06 Aug 2000, Benjamin Scott wrote:
> On Tue, 1 Aug 2000, Karl J. Runge wrote:
> > Boy this is really awful. IM(ns)HO, one should *never* change libc
> > incompatibly. It is OK to add new features to libc and other basic
> > libraries, but one should never have it break existing apps (unless,
> > say, you are bringing in a new bin format and have zero installed base:
> > e.g. a.out -> ELF circa 1995).
>
> Linux has a lot of strengths, but binary compatibility isn't one of them.
>
> Every major upgrade to libc has resulted in severe incompatibility headaches.
>
> Most kernel releases are not compatible with modules from another release.
> Heck, they are often not even compatible with modules from the *same* release.
>
> Libraries built with one release of GCC often won't work with executables
> built with another.
>
> The problem is, as I call it from my armchair, that the developers of Open
> Source/Free Software projects are naturally working in an Open Source
> environment where things are being rebuilt a lot. What's a few more rebuilds
> to make such-and-such a program work, when you're already recompiling the
> world on a weekly basis?
Linus himself has spoken to this. Some of his comments can be found in the
archives maintained for the Linux Kernel Mailing list
http://kt.linuxcare.com/kernel-traffic/index.epl
would be a good place to start. Basically Linus says that doing something
"Right" is always the right answer. If you tell people they can expect
backward compatibilty then you have have an obligation to do that even if it
means that forever you must do something "wrong". His opinion seems to be
(and boy do I feel uncomfortable speaking for Linus) that he told us there
would be no backward compatability so shame on you if you expected it.
I just tried to find the specific quotation and failed. I guess that bottom
line is that this is a different "business model" from commercial software and
that we should keep that in mind. Some of the good things that happed with
Open Source (or whatever you want to call it) is that all the old rules were
thrown out, all of the assumptions were questioned and nothing is sacred. I
think that if I choose to get the benefits of dynamic linking (for example)
then I need to know that my app is release dependent and may break later. If I
link statically then I loose one benefit in exchange for a measure of version
independence. Seems fair to me, since I'm still free to come up with something
more clever than either of these options; if I am that clever. No ones
stopping me but me.
--
Standard is better than better. If your web page cares what browser I'm using
it's broken.
[EMAIL PROTECTED]
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
