++ 06/03/05 12:09 +0000 - <Niels R. Walet>:
Niels,
> It looks that for the sake of peace in our department we will be
> converting our machines from centos to scientific linux. On the surface
> it looks easy, since they should be very comparable, Of course, I wonder
> about the differences...
> I amalso really interested in a comparison of scientific linux with
> other RHEL respins, such as centos, whitebox, XOS, ....
> I note for instance, that centos already has a version of RHEL4 for i386
> out. I am also interested in speed of updates, compatibility with 3rd
> party RHEL packages (I use dag's repository quite a lot). Also, has
> anyone tried the nosrc packages developped by duke for mathematica,
> matlab, acrobat, etc?
> Any information that may help me to understand potential pitfalls and
> benefits would be helpful.
> Niels
A pitfall that I've found is the manner that RH does updates, development and
distribution.
For example, there is a bug that you hit in RHEL. A good example is an NFS hang
bug that we've encountered. The fix came from Trond, the NFS maintainer, and
the identification of the problem came from LLNL (with testcase and working
patch). RH put it into a hotfix kernel for us so it's 'supported', but not in
their mainline updates. It won't make it into RHEL mainline kernel until U5;
that's months way. Since SL tracks RH kernels you won't see this fix for that
duration unless you want to carry over that patch yourself, which is what I do
for SL systems. But I honestly don't want to do this because it's more work,
and I don't want _your_ system to hang. I don't think anyone should
needlessly suffer.
It's not SL fault, it's the way RH handles what they consider development
cycles and non-critical bugs. But to have an SL that is better than RH, which I
think should be a goal, it might have to rethink how it handles situations like
these. No, I don't want SL to be radically different than RHEL, but I want
issues resolved in SL that are in RHEL.
A second issue that I have with RH is the dropping of packages,
adding features, and general documentation. Packages are dropped for "better"
packages; for example, out goes ncftp and in come lftp. Well, it would be nice
if someone told us so I didn't have to run around fixing old scripts. And if a
package works fine, is secure and the development is ongoing, why switch?
Yes, I like lftp better too for a number of reasons, but I don't want to
trackdown scripts that are >1yr old because someone made a decision to
end-of-life a package for no compelling technical reason. Now we tend to carry
packages in read-only mounted /usr/local compiled by hand, but after awhile you
have to build for how many hardware architectures and how many packages?
Feature get added, like the interface to network drivers changing from
supporting mii-tools to supporting mii-tools and ethtool. This broke a number
of systems.
And then there are packages that are half-way installed, like IPMI and ECC. The
ECC support is pretty poor at best; many of our systems don't report correctly
or in a consistent manner ecc values. RH is considering Bluesmoke, but it's
months away, maybe. IPMI kernel modules are built in RHEL but none of the
userspace tools are available. Then then we have a kernel that only supports
ext3 (slllloooowwwww). Debian, Gentoo, and Knoppix, the distros I'm most
familiar with support at least xfs, jfs and ReiserFS.
(You do you need Toshabi and Dell laptop support, sound, and a number of other
junk in your kernel?)
And most of the above isn't documented. Surprise.
So here I am complaining about packages broken, incomplete, hidden from the
mainline users, and undocumented. Why not fix all this, right, it's open
source. Well, yes, I get the source. Yes, I can fix this. Yes I can submit it
to RH and then later SL will get it. But you know, I have serious questions
that RHEL _is_ open source. Sure, I get the source, but do any fixes that I
need get back into RHEL? Not likely. Mostly it goes into the blackhole called
RH engineering. Way back when I started to work on open source (seems ages
although it isn't) it was a community of developers and users that reviewed
ideas and code, not some one-way vortex for sucking called RH engineering. Yes,
time goes on, but I think RHEL broken away from the open source model for
worse, not better.
And why support RH? I'd rather spend my time working on Debian or Gentoo or
some other distros that _are_ two-way, open source. If I'm going to steal time
away from my family and working on the house, I want others to benefit from the
effort. I don't care if some paying customer, my own workplace or some Fortune
500 company, benefits from my using my free time to work on Linux. I'd rather
keep the fix available, not at RH for a Ugazillon release that is going to
be held in limbo while some arbitary period of time goes by enabling RH to look
corperate.
And if the only reason is for support, there are companys that aren't as
braindead as LinuxCare that exist for support. And they support other distros.
This is just my opinion from my experience.
Thanks,
John
> --
> Prof. Niels R. Walet Phone: +44(0)1613063693
> School of Physics and Astronomy Fax: +44(0)1613064303
> The University of Manchester Mobile: +44(0)7905438934
> Manchester, M60 1QD, UK
> [log in to unmask]
> http://www.phy.umist.ac.uk/Theory/people/walet.html
##############################################
# John Goebel <jgoebel(at)slac.stanford.edu> #
# Stanford Linear Accelerator Center #
# 2575 Sand Hill Road, Menlo Park, CA 94025 #
############################################ #
|
