John,
On Mon, 7 Mar 2005, John A. Goebel wrote:
> ++ 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
Yes that is true but it DOES NOT mean that other kernels that have "other
features" are NOT provided. The kernel with XFS is an example. Do NOT
assume until you have asked. Never have we said to not give us a patched
kernel for something.
> 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.
This is only a pitfall if there is a failure to commnicate. If the patch
from LLNL was given to us then a kernel could have been made that all
could use. Yes it might not have been the default install kernel but it
could easily be a contrib kernel. You never sent a patch for this issue.
You never even mentioned that it existed.
>
> 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.
>
Does not have to be radically different. There are other ways of doing
things that replacing RH rpms. There are the "fixup SL rpms" and contrib
rpms.
> 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?
SLAC buys RHEL. And since you are from SLAC go tell your RedHat
TAM(Technical Account Manager) these issues.
I suggest that when a beta comes out you test and send in bugzilla
reports.
>
> 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.
What does this have to do with the original question.
>
> Thanks,
> John
>
>
-Connie Sieh
> > --
> > 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 #
> ############################################ #
>
|
