[2250] in SIPB_Linux_Development
Re: Linux Athena questions
daemon@ATHENA.MIT.EDU (Aaron M. Ucko)
Sun Oct 18 18:58:05 1998
To: tb@MIT.EDU (Thomas Bushnell, BSG)
Cc: svalente@MIT.EDU, linux-dev@MIT.EDU
From: amu@MIT.EDU (Aaron M. Ucko)
Date: 18 Oct 1998 18:57:44 -0400
In-Reply-To: tb@MIT.EDU's message of "Sun, 18 Oct 1998 17:59:45 -0400 (EDT)"
tb@MIT.EDU (Thomas Bushnell, BSG) writes:
> Aaron, do I understand you to say that if you were making the choice
> today, you would base Linux Athena on Debian? You mention that RedHat
Yes, I probably would.
> is "starting to lag". Could you elaborate?
Here are some issues I've had with Red Hat Linux lately:
RHS has become increasingly poor about supporting 4.2; while they
generally do provide upgrades to fix holes they know about, they don't
always think through the dependencies properly. For instance, a
couple months ago they produced updated X packages that want a newer
version of some software called PAM than they've provided for 4.2,
which can't be upgraded without making other software unhappy.
More gratuitously, many of the recent updates use some RPM extension
that the version of rpm shipped with 4.2 can't deal with. RHS
partly remedied the situation by releasing an updated rpm package
installable with the older version of rpm, but failed to provide
updated versions of the X front-end (glint) or the installation
software.
Red Hat is too conservative about taking, for lack of a better term,
vendor updates. For instance, they've never shipped a libc 5 version
newer than 5.3.12 with a few patches, even though 5.4.x has been out
for quite a while and fixed quite a few bugs their patches don't
address.
On a vaguely related note, Red Hat 5.1's support for libc 5
executables is weak. It provides few libc 5 libraries and don't build
all their libc 6 libraries such that ldconfig recognizes them as
libc-6-based, and includes an old version of ldconfig that can't be
told that certain directories contain libc 5 libs and certain others
contain libc 6 libs.
Worst of all, when I complained about some of these issues to Red Hat,
they completely ignored me.
I'm not familiar enough with Debian to know how many of these it
handles better, or whether Debian has issues Red Hat doesn't, but
discussions with Debian users I trust (including Mark Eichin, who I
believe maintains some of their packages), I get the strong impression
the balance favors Debian.
In particular, Debian's development model is significantly more open
than Red Hat's and makes it easy to take packages over from lame
maintainers.
HTH.
--
Aaron M. Ucko, KB1CJC <amu@mit.edu> (finger amu@monk.mit.edu)
