++ 07/03/05 13:19 -0600 - <Connie Sieh>:
Hi Connie,
> 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.
I'm not assuming anything. I know the XFS kernel from CERN exists as a contrib.
I didn't use that as an example. My commment here regardings RH, not SL. Since
SL takes a feed from RHEL, there are some inherited problems. For example, the
installer doesn't support any other filesystem support at install time but ext2
and ext3. You have to go back and convert. Just a bug we talked about with RH
and they aren't going to do anything.
As an aside, one problem might be that CERN does a XFS kernel, and there are a
number of other features and fixes coming in from other places. Will you have a
kernel-XFS, kernel-foo, kernel-bar? How would that work?
BTW - no need to yell. If you feel like I'm attacking SL, again, I'm not
being clear. SL is a world better, for me, as a project, than using RHEL. My
mail to Niels was meant to outline pitfalls I have encountered.
> > 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.
There was talk of this and I did send a message describing the issue. RAL is
out there doing the package themselves, last I heard. There are internal issue
here that I couldn't send the information. Sorry that it's the case, but the
example above wasn't meant as a criticism specific of SL.
> > 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.
I understand, I've modified comps.xml and the installer to do things like that.
I have a repository of packages I've written and build to do this too.
> > 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.
Thanks, we have. They are motivated not to change.
> I suggest that when a beta comes out you test and send in bugzilla
> reports.
Yes, we do. And SL gets the base from RH. We have, between SLAC and LLNL, 50+
tickets right now.
> >
> > 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.
Doesn't it describe a pitfall in adopting RHEL/SL? It's an example of how a
centralize source of development used by RH has not always worked to the
advantage of the users. This is from the experience I've had with RHEL and with
SL. Then the second part is opinion; it's suggesting an alternative to running
RHEL/SL. Yes, it's thin on why use distro foo, but I thought I'd not spend a
lot of time arguing for other distros and try to keep a little focus.
If I'm horribly wrong, sorry. My intent was to address Niels' question about
the pitfalls of running RHEL/SL. If I insulted you and your project, sorry.
These are problems I've faced while moving more and more systems to SL. I'm
doing the project myself here at SLAC because our users want it.
Thanks,
John
> >
> > 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 #
> > ############################################ #
> >
##############################################
# John Goebel <jgoebel(at)slac.stanford.edu> #
# Stanford Linear Accelerator Center #
# 2575 Sand Hill Road, Menlo Park, CA 94025 #
############################################ #
|
