Yesterday, Benjamin Scott gleaned this insight:
>
> Interesting. Although I'm familiar with Linus's stance on the issue of
> binary compatibility in the kernel, I was thinking more of the problems Linux
> has had with compatibility between different versions of GCC and GNU libc.
> Perhaps they use the same excuse the kernel developers do; I don't know.
Yup, and it makes just as much sense, and for exactly the same reasons.
> Even so, compatibility between different revs of libraries should be a much
> easier ball-game then the kernel. (You can keep multiple revs of the same
> library around, but it is hard to run more then one rev of the kernel on the
> same machine. ;)
True enough.
>
> I agree with Linus & Co. in general. But, from a support point-of-view, I,
> personally, think at least *some* effort should be made towards binary
> compatibility.
<SNIP-SNIPPETY>
> - Keep track of 42 different versions of each binary, one for each
> subtle variation in kernel, compiler, libc, version, options, etc.
<SNIP>
I'm reasonably certain that Linus et. al. would tell you that the code is
updated for a reason (i.e. it was broken before, and it's much fixed now)
so you should upgrade all of your systems at the shortest reasonable
interval you can manage. And you have the source, so it's "easy" for you
to do that.
Now, we all know that a system administrator's time is not infinite
(except maybe for their bosses...) but you have to admit that the argument
makes a certain amount of sense. And...
> I'm sure the problem is only magnified for the likes of Red Hat, IBM, or
> <insert potential big Linux-using company here>. I agree that binary
> compatibility shouldn't get in the way of progress, but there have been
> occasions where the incompatibilities have seemed to be easily avoidable or
> even gratuitous.
Perhaps so, but the business of open source software is at its very heart
extremely idealistic, where the ideal is to "get it right" and the
consequences be damned. Binary compatibility isn't even the tiniest of
considerations; code cleanliness and efficiency are (with varying degrees
of success, but the goal is admirable).
> <laughter> I've seen kernel modules from the *same release* refuse to load
> because of unresolved symbols. And not just for things like the SMP flag
> being set. This "binary compatibilities within major releases" is an
> unrealized goal, IMNSHO.
In general, I've seen these only because the module requires some feature
that was previously set by default (i.e. it was not optional) or did not
exist at all, but subsequently became optional and off by default. Or
some similar reason. But there may well be exceptions and in any case your
point is well taken. But it's already stated that binary compatibility is
not a goal, so there's no point in worrying about it.
I should point out that I don't completely disagree with you; binary
compatibility is desireable for obvious reasons, many of which you've
stated. As a system administrator, it makes my job easier. But I also see
Linus's point. The problem, as I see it, is that the two ideals, being
code perfection and complete binary compatibility between releases, are
mutually exclusive. Completely. You must trade off one for the other, and
Linus et. al. have already made the decision that good code is much more
important than compatible code, and they will NOT sacrifice code quality
for compatibility under any circumstances, and therefore that the issue of
binary compatibility will be completely ignored, in order to allow people
to concentrate on perfecting the code.
Linus is very idealistic, and I think it's a good thing that he is, or
else you'd have YASMP (yet another shoddy Microsoft product) on your
hands, rather than this cool thing we call "Linux" on your desktop. You
either accept the lack of binary compatibility, or you run broken
software, like Windows. There is NO other choice. Commercial vendors
(including Unix and others too) have proven it time after time, after
time, ad nauseum.
--
You know that everytime I try to go where I really want to be,
It's already where I am, cuz I'm already there...
---------------------------------------------------------------
Derek D. Martin | Unix/Linux Geek
[EMAIL PROTECTED] | [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
**********************************************************
