LDP
/
old-www
1
1
Fork 0
Code Issues Pull Requests Releases Wiki Activity
old-www/LDP/LG/issue29/tag_versions.html

509 lines
21 KiB
HTML
Raw Permalink Blame History

<!--startcut ======================================================= -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<META NAME="generator" CONTENT="lgazmail v1.1pre6">
<TITLE>The Answer Guy 29: Version-a-go-go and the Tragedy of being
"Left Behind"</TITLE>
</head>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#A000A0"
ALINK="#FF0000">
<!--endcut ========================================================= -->
<H4>"Linux Gazette...<I>making Linux just a little more fun!</I>"
</H4>
<P> <hr> <P>
<!-- =============================================================== -->
<H1 align="center"><A NAME="answer">
<img src="../gx/dennis/qbubble.gif" alt="" border="0" align="middle">
<a href="./index.html">The Answer Guy</a>
<img src="../gx/dennis/bbubble.gif" alt="" border="0" align="middle">
</A></H1> <BR>
<H4 align="center">By James T. Dennis,
<a href="mailto:linux-questions-only@ssc.com">linux-questions-only@ssc.com</a><BR>
Starshine Technical Services,
<A HREF="http://www.starshine.org/">http://www.starshine.org/</A> </H4>
<p><hr><p>
<H3><img src="../gx/dennis/qbub.gif" alt="(?)" width="50" height="28"
align="left" border="0">Version-a-go-go and the Tragedy of
being &quot;Left Behind&quot;</H3>
<p><strong>From Richard Storey on 20 May 1998
<br><br>
To a "newbie" on the edge of installing Linux some of what I read leaves me
concerned that some form of minor shakeout is building up in the Linux
versions arena. It has me confused about which direction to turn because
I'm not really interested in installing a lot of stuff, configuring it and
then finding that 6 mos. later I am out on a limb due to some standards
shift.
</strong></p>
<blockquote><img src="../gx/dennis/bbub.gif" width="50" height="28" alt="(!)"
align="left" border="0">
I can understand your concern. This is a problem that
IT managers face all the time when selecting hardware and
software for their companies. It affects the home user, too
but no one gets fired over those little disasters (well,
it <strong>might</strong> cause the occasional divorce but ....).
<br><br>
That's why the rule in MIS/IT used to be "no one ever got
fired for buying IBM" (and why we see such "devotion" to
Microsofts products today).
<br><br>
However, I can lay your fears to rest on a couple of
grounds. This is not "the market" --- it is the free
software world. (In this particular case I'm referring
to <a href="http://www.fsf.org/">GNU</a> and Linux
<strong>free software</strong> and not merely to
a broader world of "open software").
</blockquote>
<p><strong><img src="../gx/dennis/qbub.gif" width="50" height="28" alt="(?)"
align="left" border="0">
What is this issue about regarding GNU <tt>gcc</tt> libraries and some versions
shifting to a new standard? I've seen bits of info. on it and did somewhat
understand what it meant, but I'm not a programmer, therefore, I don't get
the big picture here.
</strong></p>
<blockquote><img src="../gx/dennis/bbub.gif" width="50" height="28" alt="(!)"
align="left" border="0">
The debate about <tt>glibc2</tt> (Linux libc 6) and <tt>libc5</tt>
is mostly of concern to programmers. Even as a sysadmin I'm fairly
oblivious to it. It's really a bear for package and
distribution maintainers (which is probably where the
messages you're thinking about are coming from).
<br><br>
There is probably quite a bit of traffic about the pros and
cons of each. I won't get into that, mostly because I'm
simply not technically qualified to do so. (I'm not a
programmer either).
<br><br>
The high elevation overview is that <tt>glibc</tt> and <tt>libc5</tt>
can co-exist roughly to the same degree that <tt>libc5</tt>
co-exists with <tt>libc4</tt> and <tt>a.out</tt> co-exists with
<tt>ELF</tt>. Nobody is being left "high and dry." In this respect
it is completely different than the shift from DOS and Windows 3.x
to Windows '95 and/or from either of those to NT. It's also a far cry
from the shameful way that <a href="http://www.microsoft.com/"
>Microsoft</a> and <a href="http://www.ibm.com/">IBM</a> have treated
their OS/2 adopters.
<br><br>
Zooming in a little bit I can say that the next major release
of most Linux distributions will be <tt>glibc</tt> based. Most will
probably ship with optional <tt>libc5</tt> libraries for those who
want or need to run programs that are linked against them.
<br><br>
<tt>glibc</tt> is the reference implementation of the
<a href="http://www.telly.org/86open/index.html">86Open</a>
standard. This should be supported by almost all x86 Unix
vendors within the next couple of years. (Hopefully
most of us will have moved to
<a href="http://www.mot.com/SPS/PowerPC/">PPC</a>,
<a href="http://www.digital.com/semiconductor/alpha/alpha.htm"
>Alpha</a>,
<a href="http://www.intel.com/pressroom/archive/releases/sp100997.HTM"
>Merced</a> [though its
<a href="http://www.intel.com/pressroom/archive/releases/sp052998.htm"
>release schedule</a> has been stretched], or
whatever by then -- but I'm the one with the 10 year old
server that handles all the mail into and out of my
domain --- so don't bet on it).
<br><br>
The hope is that we'll finally have true binary
compatibility across the PC Unix flavors.
<a href="http://www.sco.com/">SCO</a> and
<a href="http://www.sunsoft.com/">Sun</a> have traditionally
bolluxed this up in the interest
of their market rivalry --- but the increasing acceptance
of Linux and other GNU software makes it their only
reasonable option. Neither of them can force the market
to adopt their standards (<a href="http://www.res.kent.edu/personal/mtardiff/unix98/ibcs2.htm">iBCS</a> and the x86 ABI) and the
consumer shrink wrap software market is rapidly shifting
to Linux.
<br><br>
It should also be much easier for Linux to keep pace
with the rest of GNU development as we adopt <tt>glibc</tt>.
There should be less duplicated effort in porting
new library features from <tt>glibc</tt>/<tt>gcc</tt> to Linux
than there was under all of the previous Linux <tt>libc</tt>'s.
<br><br>
Right now we are in a transition between them, just as we
were a couple of years ago when we shifted from <tt>a.out</tt> to
<tt>ELF</tt>. '<tt>a.out</tt>' and <tt>ELF</tt> are "linking
formats" --- different ways of representing the same machine
language instructions. They require different loading methods by
the kernel, in order to execute properly. It is possible (trivial,
in fact) to support <tt>a.out</tt> and <tt>ELF</tt> on the same
system concurrently. In fact I can compile <tt>a.out</tt> as a
"loadable module" and configure my system to automatically and
transparently load that --- which saves a bit of kernel memory
when I'm not running any older apps --- but allows me to do so
without any concern.
<br><br>
Although shared libraries are completely different from
(and independent of) executable formats the similarity
is that we (as users and admins) can mostly just let
the programmers, distribution and package maintainers
take care of all that.
<br><br>
Let me try and give some background on this:
<br><br>
Most programs under Linux (and most other modern forms of
Unix) are "dynamically linked" against "shared libraries."
Windows "DLL's" (dynamically linked libraries) are an example
of Microsoft's attempt to implement similar features for their
OS. (I believe that Unix shared libraries pre-date OS/2 and
MS Windows by a considerable margin).
<br><br>
Almost all dynamically linked programs are linked against
some version of "<tt>libc</tt>" (which provides the functions that
you get when you use a <tt>#include &lt;stdio.h&gt;</tt> directive in
a C program). Obviously your distribution includes the
<tt>libc</tt> that most of its programs are linked against.
<br><br>
It can also include other versions of the shared libraries.
A binary specifies the major and minimum minor version of
the libary that it requires. So a program linked against
<tt>libc5</tt> might specify that it needs <tt>libc5</tt> or
<tt>libc5.4</tt>.
<br><br>
If you only have <tt>libc5.3</tt> and the program requires
<tt>libc5.4</tt> you'll get an error message. If you have
<tt>libc5.3</tt> <strong>and</strong> <tt>libc5.4</tt> then the
program should run fine. Any program that only requires
<tt>libc5</tt> (which fails to specify the minor version)
will get the last version in the <tt>libc5.x</tt> series (assuming
your <tt>ldconfig</tt> is correct).
<br><br>
This is not to say that the system is perfect. Occasionally
you'll find a program like <a href="http://www,netscape.com/"
>Netscape</a> Navigator or <a href="http://www.stardivision.com/"
>Star</a>Office that specifies a less specific library then it
should (or sometimes it might just have the
<strong>wrong</strong> version specified).
When this happens the bugs might be pretty subtle. This is especially
true when a program "depends upon a bug in the libraries" (so the
fix to the library breaks the programs that are linked to it).
<br><br>
In the worst cases you can just put copies of the necessary
(working) libraries into a directory and start the affected
program through a small shell script wrapper. That wrapper
just exports environment variable(s): <tt>LD_PRELOAD</tt> and/or
<tt>LD_LIBRARY_PATH</tt> to point to these libraries or this directory
(respectively). These magic environment variables will force
the dynamic linker to over-ride its normal linking conventions
according to your needs.
<br><br>
(This is obviously only a problem when the sources to the
affected application are unavailable since re-compiling
and re-linking solves the real problems).
<br><br>
In truly desperate cases you could possibly get a statically
linked binary. This would contain all the code it requires
and no dynamic linking would be necessary (or possible).
<br><br>
Note that the problem that I've just described relates
shared libraries already. This is not new with the
introduction of <tt>glibc</tt> --- since the actual cases where
I've had to use <tt>LD_PRELOAD</tt> were all with <tt>libc5</tt>.
</blockquote>
<p><strong><img src="../gx/dennis/qbub.gif" width="50" height="28" alt="(?)"
align="left" border="0">
Some defections at <a href="http://www.debian.org/">Debian</a> have me
wondering about using that version.
</strong></p>
<blockquote><img src="../gx/dennis/bbub.gif" width="50" height="28" alt="(!)"
align="left" border="0">
I'm not sure I understand this. First I'm not sure
which defections you're referring to. I presume you've
read some messages to the affect that some developers or
package maintainers refuse to make this migration (to <tt>glibc</tt>).
<br><br>
More importantly I'm not sure which 'version' you are
referring to.
<br><br>
The current version of Debian (1.3) uses <tt>libc5</tt>. The next
version (currently in
<a href="http://www.debian.org/news.html#19980522a">feature freeze</a>
--- slated to be 2.0) uses <tt>glibc</tt>.
</blockquote>
<p><strong><img src="../gx/dennis/qbub.gif" width="50" height="28" alt="(?)"
align="left" border="0">
I've read about some major problems with <a href="http://www.redhat.com/"
>RedHat</a> 5.0, but 4.x isn't compatable with the new GNU <tt>gcc</tt> libs,
(right?).
</strong></p>
<blockquote><img src="../gx/dennis/bbub.gif" width="50" height="28" alt="(!)"
align="left" border="0">
I wouldn't call the problems with Red Hat 5.0 to be "major."
When I was in tech support and QA we used a system of
bug categories ranging from "cat 1" to "cat 4." The
categories were roughly:
<br><ol>
<li> causes data loss or crashes the whole system
<li> dies and is unusable
<li> major function fails
<li> cosmetic
</ol>
... and the bugs that I've seen from RH5 have all been at
cat 3 or lower. (Granted people might argue about the
severity level of various security bugs --- but let's not
get into that).
<br><br>
However I agree that there have been many bugs in that
release --- and that many of these have been glaring and
very ugly.
<br><br>
One of the two times that I've had dinner with Erik Troan
(he's a senior developer and architect for Red Hat Inc) I
asked him why they forced out <tt>glibc</tt> support so soon and
for such a major release.
<br><br>
He gave a refreshingly forthright response by asking:
<br><br>
<font color="#333366"><em>&quot;How many <tt>glibc</tt> users were
there a month ago?&quot;</em></font>
<br><br>
(essentially none --- just a few developers)... and:
<br><br>
<font color="#333366"><em>&quot;How many are out there
now?&quot;</em></font>
<br><br>
Basically it sounds like Red Hat Inc knew that there were
going to be problems with <tt>glibc</tt> --- and made the strategic
decision to ship them out and force them to be found and
fixed. This had to hurt but was probably viewed as the
only way to move the whole Linux community forward.
<br><br>
I think they could have worked a little bit longer before
release (since I really get a bad taste in my mouth when
'<tt>vipw</tt>' segfaults right after fresh installation --
'<tt>vipw</tt>' is the "<tt>vi</tt> for your passwd file" that
sysadmins use to safely, manually, add new accounts or make
other changes). I was also hoping they'd wait until the 2.2 kernel
was ready so they could wrap both into one new release.
<br><br>
(However, I guess that would have put them about 6 to 8
months behind their own schedule. They seem to put out
a new minor version every four to six months --- or
not quite quarterly).
<br><br>
At the same time I have to recognize their approach as
a service to the community. They have fixed the bugs
quickly (and newer pressings of the same CD's contain
many of these fixes). Like all shrink wrap software
companies Red Hat Inc. is forced (by the distribution
channel) to do "silent inlining" (incorporation of bug
fixes into production runs without incrementing the version
number). This is a sad fact of the industry --- and one
that costs users and software companies millions of hours
of troubleshooting time and confusion.
<br><br>
(My suggestion was that RH cut monthly CD's of their
bug fixes and 'contrib' directory and offer subscriptions
and direct orders of those. I don't know if they've
ever taken me up on that. My concern is to save some
of that bandwidth. I occasionally burn CD's of this
sort and hand them out at users groups meetings so they
can be shared freely).
</blockquote>
<p><strong><img src="../gx/dennis/qbub.gif" width="50" height="28" alt="(?)"
align="left" border="0">
Could you explain some of these shifts on the Linux Versions field?
</strong></p>
<blockquote><img src="../gx/dennis/bbub.gif" width="50" height="28" alt="(!)"
align="left" border="0">
Well, I hope this has helped. There have been many sorts
of shifts and transitions in Linux over the years. Obviously
there were shifts from <tt>libc4</tt> to <tt>libc5</tt>, and i
shifts from <tt>a.out</tt> to <tt>ELF</tt>, and between various
kernel versions: .99 to 1.0. --&gt; 1.1 --&gt; 1.2 --&gt; 2.0
and the current effort to get 2.2 "out the door."
<br><br>
I think that all of these shifts have been progressive.
<br><br>
The worst one we suffered through was the change in the <tt>/proc</tt>
filesystem structures between 1.2 and 2.0. This was the only time
that a newly compiled kernel caused vital "user space" programs to
just keel over and <strong>die</strong> (things like the '<tt>ps</tt>'
and '<tt>top</tt>' commands would segfault).
<br><br>
That was ugly!
<br><br>
There was no easy way to switch between the kernel versions
on the same root fs. The best solution at the time seemed
to be to keep one root fs with the old "<tt>procps</tt>" suite on it
and another with the new one. You'd then have whichever of
these you were using mount all your other filesystems. For
those of us that habitually create small root filesystems
and create primary and alternate/emergency versions of that
--- it was too much of a problem.
<br><br>
(I usually use about 63Mb --- sometimes as much as 127Mb and
mount <tt>/usr</tt>, <tt>/var</tt>, and others --- or at least mount
<tt>/usr</tt> and <tt>/usr/local</tt> and make thinks like
<tt>/var</tt>, <tt>/opt</tt>, and <tt>/tmp</tt>
into appropriate symlinks. I just isolated the "bad" binaries
by moving them from under <tt>/usr</tt> to <tt>/root/.usr/</tt> and
replaced them with symlinks. Then the '<tt>ps</tt>' that I called
was automatically resolved to the one under my root fs -- which was
different depending on which kernel I boot from).
<br><br>
I see no evidence that <tt>glibc</tt> (or the 2.2 kernel) will pose
these sorts of problems. The worst problem I foresee with
<tt>glibc</tt> is that it is <strong>so</strong> big. This is a
problem for creating boot diskettes. I've heard that it compresses
down to almost the same size as <tt>libc5</tt> --- which means that
<tt>glibc</tt> based diskettes might be possible using compressed
<tt>initrd</tt> (initialization RAM disks). At the same time it
is probably unnecessary. The main features of <tt>glibc</tt> seems
to have to be in the support for NIS (network resolution
of things like user account and group information ---
things normally done by accessing local files like
<tt>/etc/passwd</tt> and <tt>/etc/group</tt>). Many of these new
features are probably unnecessary on rescue diskettes.
<br><br>
One final note about all these transitions and changes:
<br><br>
You aren't forced to go along for the ride. You can
sit back and run Red Hat 4.2 or Debian 1.3 for as long
as you like. You can install them and install <tt>glibc</tt>
with them. You aren't forced to upgrade or change
everything at once.
<br><br>
These "old" versions are never really "unsupported" ---
there was someone who just released an updated
<a href="http://rsphy1.anu.edu.au/~gpg109/linux-lite.html"
>Linux-Lite</a> (based on the 1.0.9 kernel). This is one of the
smallest, most stable kernels in the history of the OS. It has been
updated to support <tt>ELF</tt> and have a few bug fixes applied.
It can boot in about 2Mb of RAM (which is just enough
for an internal router or print server) and handy for
embedded applications that need TCP/IP.
<br><br>
Since we have the sources, and we're licensed to modify and
redistribute them in perpetuity (the heart of the GPL)
we can continue to maintain them as long as we like. Obviously
there are some people out there who still like.
</blockquote>
<p><strong><img src="../gx/dennis/qbub.gif" width="50" height="28" alt="(?)"
align="left" border="0">
Thanks.
<br>RS
</strong></p>
<!--================================================================-->
<P> <hr> <P>
<H5 align="center"><a href="http://www.linuxgazette.com/copying.html"
>Copyright &copy;</a> 1998, James T. Dennis <BR>
Published in <I>Linux Gazette</I> Issue 29 June 1998</H5>
<P> <hr>
<!--================================================================-->
<p align="center"><table width="95%"><tr align="center">
<td rowspan="4"><A HREF="lg_answer29.html"><IMG
SRC="../gx/dennis/answernew.gif"
ALT="[&nbsp;Answer&nbsp;Guy&nbsp;Index&nbsp;]"i
align="left"></A></td>
</tr><tr align="center">
<!-- begins -->
<td><A HREF="tag_versions.html">versions</A></td>
<td><A HREF="tag_lilo.html">lilo</A></td>
<td><A HREF="tag_virtdom.html">virtdom</a></td>
<td><A HREF="tag_kernel.html">kernel</A></td>
<td><A HREF="tag_winmodem.html">winmodem</a></td>
<td><A HREF="tag_basicmail.html">basicmail</a></td>
<td><A HREF="tag_betterbak.html">betterbak</a></td>
</tr><tr align="center">
<td><A HREF="tag_shadow.html">shadow</a></td>
<td><A HREF="tag_dell.html">dell</a></td>
<td><A HREF="tag_dumbterm.html">dumbterm</a></td>
<td><A HREF="tag_whylinux.html">whylinux</a></td>
<td><A HREF="tag_redhat.html">redhat</a></td>
<td><A HREF="tag_netcard.html">netcard</a></td>
<td><A HREF="tag_macrovir.html">macrovir</a></td>
</tr><tr align="center">
<td><A HREF="tag_newlook.html">newlook</a></td>
<td><A HREF="tag_tacacs.html">tacacs</a></td>
<td><A HREF="tag_sendmail.html">sendmail</a></td>
<td><A HREF="tag_dialdppp.html">dialdppp</a></td>
<td><A HREF="tag_ppp233.html">ppp233</a></td>
<td><A HREF="tag_msmail.html">msmail</a></td>
<td><A HREF="tag_procmail.html">procmail</a></td>
<!-- ends -->
</tr></table>
</P> <hr> <P>
<!--================================================================-->
<A HREF="./index.html"><IMG SRC="../gx/indexnew.gif"
ALT="[&nbsp;Table&nbsp;Of&nbsp;Contents&nbsp;]"></A>
<A HREF="../index.html"><IMG SRC="../gx/homenew.gif"
ALT="[&nbsp;Front&nbsp;Page&nbsp;]"></A>
<A HREF="lg_bytes29.html"><IMG SRC="../gx/back2.gif"
ALT="[&nbsp;Previous&nbsp;Section&nbsp;]"></A>
<A HREF="./hamilton.html"><IMG SRC="../gx/fwd.gif"
ALT="[&nbsp;Next&nbsp;Section&nbsp;]"></A>
<!--startcut ======================================================= -->
</body>
</html>
<!--endcut ========================================================= -->
Reference in New Issue View Git Blame Copy Permalink