Re: Goofy RedHat Problem

[John Klein <zarkon@law.harvard.edu>]

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 "Applications".

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.

> 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 distros.)

> 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.

Now, obviously it's /better/ if people know how to compile things from
source, but realistically that's just not always going to be the case. 
(And you can't exactly tell someone that they shouldn't be administrating 
a directory service when their job requires them to. Well, actually, you 
can, but they are unlikely to listen.)

> Nothing of what I wrote said to patch over problems in an existing 
> distribution with source.  What I said was, if you are going to run an 
> application, and you want to make sure it is up to date, then install it 
> in a separate location from what came with the distribution. You keep 
> your support for the OS, and you get to get your work done.

And, thereby, you patch over a problem in an existing distribution (e.g. 
that OpenLDAP is a creaky, ancient version) with source (specifically, the 
OpenLDAP source).

--
John Klein
Database Applications Developer
Information Technology Services - Harvard Law School
Omnia Mutantur, Nihil Interit