[Date Prev][Date Next]
Re: Goofy RedHat Problem
--On Tuesday, July 06, 2004 2:59 PM -0400 John Klein
On Tue, 6 Jul 2004, Quanah Gibson-Mount wrote:
We build, compile, and install hundreds of different pieces of software
on a regular basis. I've never had issues with Sun or RedHat in getting
support on those systems, even though we've added software to those
systems that didn't come with them. As long as you don't muck with
the default system installed pieces, they don't care. That's because
they understand the difference between "Operating Systems" and
I think you have different support people than we generally deal with.
Not just O/S, but application support people, for instance, who say
things like "Requires Vx.y of O/S z to run". We have had and continue to
have problems because support people do not recognize this distinction.
And, in fact, the distinction is somewhat arbitrary to begin with, since
an operating system is fundamentally a collection of applications. But
that's a much more abstract type of discussion.
Yes, we run into that issue as well (especially with anything dealing with
Oracle). However, what we do do, is run different applications on
different servers (i.e., we have dedicated directory servers, dedicated www
servers, dedicated cgi servers, etc etc). The majority of our
infrastructure applications are opensource, which provide much more
flexibility than the various vendors of our adminstrative application
systems, which are definitely more hobbled/constrained. (although that gets
a bit OT for list).
Tools like "apt" are great when the packages for an installation are
maintained, but the sad fact they seldom are. I'm not going to keep my
user base in the dark ages because distro's are unable to keep up with
the rapid changes in software that occur elsewhere.
You shouldn't. It's just going to be an extra pain for you (and for
everyone) when the distros don't keep up, which is why I'm complaining
about them not doing so. I know it can be done, because I have at least
one example of a distribution that is not far behind (Gentoo). If they
can have 2.1.26, then Debian and Redhat can as well. (Particularly
Redhat, which is actually /charging/ you for this.)
I think you may have misinterpreted my intent here. I'm not saying you
shouldn't compile things when they're out of date. I'm saying that they
should never go out of date to the extent that you have to compile them.
(And that, if they are, maybe you need to bug your vendor or switch
Perhaps, but I've yet to see a distro distribute OpenLDAP in the particular
way *I* need to compile it. That's one of the fundamental problems with
distro's even attempting to distribute applications. They are most likely
to compile for the broadest set of consumers, but if you have particular
needs (SASL/GSSAPI for example), the odds that the distro is going to
compile it with that support are quite low. Just look at the packages it
takes to build up OpenLDAP, and the variety of options *each* package has.
Some even have interdependencies (Look at Heimdal wanting OpenLDAP
libraries wanting Heimdal libraries in some cases!). Not only that, how do
*I* know that the distro is even using the proper set of libraries? There
are known issues with MIT Kerberos (actively being fixed, thankfully) that
make it unusable (without a bit of work) in a threaded environment. Unless
a distribution is willing to compile every application with every option
(bloat), it is likely that their software distribution will not meet
You are correct that some people are not comfortable compiling software
on their own. If that is the case, then they shouldn't be
administrating a directory service, since it will invariable take some
capability to download software, install patches, etc.
I'm arguing that it doesn't have to be this way. Why should the skill
"administrate service X" be eternally linked with the skill "compile the
software that runs service X from source"? The only reason that it is
right now is that packages go out of date too quickly, which is exactly
what I'm saying shouldn't happen.
See above. I'll also add that understanding how the software compiles and
works gives you a great understanding of what you are working with, which I
think is essential for the proper administration of service X.
Principal Software Developer
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html