Thanks for the info John.
I was thinking more along the lines of the sysadmin incompatibility
issue: I vaguely recall xinetd being basically an improved replacement
for inetd+tcp_wrappers. If you just have 1 linux machine it is not such
a big deal to tweak it into working again after an upgrade, but if you
have, say >10 of them, or more importantly you or your fellow employees
*depend* on the boxes critically, having a bunch of such
imcompatibilities inflicted on one in an upgrade is a real PITA, and
sometimes even impossible to absorb.
Perhaps too early now for linux with its rapid growth, but some year
the linux community will get this...
On Tue, 1 Aug 2000, John Abreau <[EMAIL PROTECTED]> wrote:
> ...
> The way I heard it explained, the 7.x indicates changes in the compiler
> that are not backward compatible. Throughout the 6.x series they stuck
> with an old egcs and didn't keep up with glibc updates, in order to
> enable, for example, binaries built on 6.2 to run on older 6.x systems.
> With 7.0, they're upgrading to the current gcc and current glibc, and
> binaries built with these won't run on 6.x systems.
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).
If it hasn't happened already, I predict in a couple years there will be a
good market for companies to provide "space-time" Linux compatibility services.
By this I mean: space="different distros" and time="different releases of
a given distro".
# oh well,
undef $soapbox;
Karl Runge
**********************************************************
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
**********************************************************
