[2260] in SIPB_Linux_Development
Re: Linux Athena questions
daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Mon Oct 19 23:31:27 1998
Date: Mon, 19 Oct 1998 23:31:10 -0400
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: amu@MIT.EDU
Cc: tb@MIT.EDU, linux-dev@MIT.EDU
In-Reply-To: Aaron M. Ucko's message of 19 Oct 1998 15:30:49 -0400,
<udlsogkuz6e.fsf@cutter-john.mit.edu>
From: amu@MIT.EDU (Aaron M. Ucko)
Date: 19 Oct 1998 15:30:49 -0400
Longer, though it's gotten worse lately. For instance, they never
bumped libc 5 past 5.3.12, even though 5.4 has been out and stable for
quite some time.
Not using libc 5.3.12 was a deliberate choice on RedHat's part. There
were real backwards compatibility and stability problems with 5.4. I
believe the stability problems may be solved by now, but 5.4 broke some
commercial applications, (including Netscape at one point), and so
RedHat quite fairly decided not to support libc 5.4.
RedHat has been applying security fixes to libc 5.3.12, though. If
RedHat isn't supporting their 4.2 release as much now, keep in mind that
5.0 and 5.1 have been out for some time now, and RedHat 5.2 is about to
be released. (I'm a beta-tester for RedHat 5.2, and I can get SIPB bits
which will be almost identical to what the final RedHat 5.2 release will
look like.)
RedHat 4.2 is almost a year and half old, and SIPB's Linux-Athena based
on RedHat 4.2 didn't get released until RedHat 5.0 shipped, if I
remember correctly. It looks like this pattern may be repeating with
Redhat 5.1; SIPB may end up shipping it after RedHat 5.2 is gets
shippped. (We have *got* to tighten up our development cycle here,
guys....)
To give a developer's perspective, my one or two interactions with
Debian have been very negative, which is one of the reasons why I
haven't chosen to use Debian. This particular story has the blame
factored many different ways. Part of the blame certainly lies with the
glibc folks, who don't know how to spell "backwards compatibility", when
they removed the function prototype for llseek(), but left the llseek()
symbol in libc. Part of the blame lies with the e2fsprogs maintainer in
Debian, who did an incompetent port to glibc, not knowing about the land
mine left by the glibc folks, and created a version of e2fsck which
destroyed filesystems greater than 2 gigabytes. (This was a mistake the
RedHat folks did not make.)
The thing which really soured me was the fact that the Debian package
maintainer funneled all of the resulting bug reports (which were *his*
fault) to me, and expected me to do something about it. Then to add
insult to injury, he started asking me to make changes to support all
sorts of changes just to satisfy the Debian coding standards, including
use of automake. I snapped at him and Bruce Parens, and they backed
down, but the whole thing still left a very bad taste in my mouth.
So one of the downsides with Debian is that the quality of the package
maintainers are very variable, and while some may be good, some may also
be bad. You get pot luck. In contrast, I know all or most of the
RedHat people, and since they are hired to work full-time on this stuff,
it's a smaller and more tight-knit group --- and they seem to only hire
top-notch staff. (For example, both Alan Cox and Stephen Tweedie work
for RedHat.) So for me personally, this gives me a much higher comfort
level for RedHat over Debian. When I did an informal poll last May at
the Linux Expo and at Usenix, a majority of the core Linux kernel
developers generally use RedHat instead of Debian, for similar reasons.
- Ted
