[RE: Having to maintain multiple incompatible versions of binaries]
On Mon, 7 Aug 2000, Derek Martin wrote:
> 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.
I see several practical problems with that line of reasoning. One is that
upgrades are *never* a smooth process (Murphy's Law), and being able to do
things as gradually as possible helps. Another is that changes I am talking
about are sometimes -- not always -- frequent, many, and incremental. Still
another is latency -- if the entire world switched over at once, it wouldn't
be such a big deal, but that isn't the way things work. Just look at all the
heartache getting everyone to transition to glibc2/libc6. Lastly, neither
developer time nor admin time is infinite, and perhaps a little time spent
earlier on in the process would save much more time later on. Time that could
be spent further improving Linux/GNU/etc.
> And you have the source, so it's "easy" for you to do that.
I like Open Source/Free Software as much as the next guy (assuming the next
guy isn't Richard Stallman ;-), but I also live and work in the Real
World(TM), where I'm afraid I *don't* always have the source. :-(
Again, I want to stress that "we" most emphatically should *NOT* retain
brain damage for the crutch of backwards compatibility, but at the same time,
"we" should perhaps try more to keep the impact of our changes in mind when we
make them. (I put "we" in quotations because I don't want to presume to be a
big-time (or even small-time) OSS developer.)
As clunky as they are, compatibility layers, complete with warnings when
their crutch is used, can help this transition. Right now, the mindset of
many OSS developers seems to be, "Here's the new rev, nothing works now, have
fun fixing everything." Providing a bit of a "compatibility cushion" which
will allow us to continue to function during the transitional stage would,
perhaps, be a Good Thing.
> 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.
All things considered, I believe Linus nailed that one down pretty well.
The primary driving force behind most Open Source projects is to have fun.
(Preemptive reply: If you say "Worrying about binary compatibility isn't
fun", I will say "Listening to a million whining users is even less fun.")
> Binary compatibility isn't even the tiniest of considerations; code
> cleanliness and efficiency are (with varying degrees of success, but the
> goal is admirable).
I don't believe that binary compatibility is wholly incompatible with those
noble goals.
> 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.
Whatever the reason, the problem still exists. :-)
> The problem, as I see it, is that the two ideals, being code perfection
> and complete binary compatibility between releases, are mutually
> exclusive.
If the world were limited to those two diametric opposites, I would agree
with you. But I believe it is more of a spectrum, and perhaps we're trying to
hug to the "code perfection" side a little too much. I don't mean to sound
existentialist, but what good is software if nobody uses it? :-)
> 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 ...
*ahem*
On Thu, 27 Jul 2000, Robert H. de Vries wrote:
> If I would change the user, that would trigger an avalanche of changes,
> while my proposition is limited to just one definition.
On Thu, 27 Jul 2000, Linus Torvalds wrote:
> After having looked at that mess, you're right. Let's just change
> __SI_CODE.
Again, I'm not saying we should tie ourselves down to the same API forever,
but even Linus has been known to admit that sometimes the cost isn't worth the
benefit.
> Linus is very idealistic, and I think it's a good thing that he is ...
As do I, but I also think he balances that with a healthy dose of
pragmatism.
> You either accept the lack of binary compatibility, or you run broken
> software, like Windows. There is NO other choice.
I've never found blanket statements like that to be true. (Irony quite
intentional.)
> Commercial vendors (including Unix and others too) have proven it time
> after time, after time, ad nauseum.
Novell NetWare, of all things, had an interesting way of handling this
problem. As new APIs/ABIs were introduced, old ones were flagged as
"Outdated". When a module (i.e., a library or program) was loaded that made
use of the old ABIs/APIs, warnings and alerts were issued, sometimes including
the date(s) at which the old APIs/ABIs would be removed completely. This let
you "phase in" changes gradually, rather then severing things instantly. It
also let you know how long you had, to prioritize.
On Mon, 7 Aug 2000, Derek Martin wrote in reply to Jerry Feldman:
> If they would only get it through their heads that they can recompile the
> code for the same version of the application (same code base, updated only
> as necessary to make sure it runs on the new OS) then it would be o.k.
I just want to add that, while this thought sounds Neat In Theory(TM), the
subtle changes invariably present in a major OS or library upgrade sometimes
make things considerably harder. Especially when you lack the {time, funds,
documentation, management} to do a full regression test. I speak from
personal and unpleasant experience here. :-(
On Mon, 7 Aug 2000, Jerry Feldman wrote:
> I certainly agree with Derek on the binary compatibility. Maintaining
> binary compatibility causes the growth of libraries because of legacy
> code.
Only if you never phase out the older calls. I don't believe this is an
"all or nothing" issue. Sometimes you need to break binary compatibility
abruptly. Sometimes you want to provide a compatibility layer for awhile.
--
Ben Scott <[EMAIL PROTECTED]>
| "I've already explained this once, but repetition is the very soul of |
| the net." (from alt.config) |
**********************************************************
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
**********************************************************
