[CentOS] Re: Demonizing generic Linux issues as Fedora Core-only issues -- WAS: Hi, Bryan

Lamar Owen lowen at pari.edu
Sat May 28 00:13:54 UTC 2005


On Thursday 26 May 2005 14:17, Les Mikesell wrote:
> If you believe that, you have to believe that Red Hat's programmers
> are always better than the original upstream program author.

For the most part, the Red Hat crew is the best in the business.  Or have you 
never heard of Jakub Jelinek, Alan Cox, Rick van Riel, and many many other of 
the top upstream developers that are employed in some capacity by Red Hat?

> I'll 
> agree that they are good and on the average do a good job, but
> that stops far short of saying that they know better than the
> perl (etc.) teams what version you should be running.

The perl team has no business telling me what version I should be running, 
either.  What version I run is dependent upon many things; one of which is 
'what version does my vendor support?'

> So, you want a working application, take an incomplete kernel. I
> understand that's the way things are. I don't understand why
> you like it.

Long term version stability.  There has to be a freeze point; Red Hat has 
chosen the very documented 2-2-2 6-6-6 scheme, and sticks to its schedule, 
for the most part.  Or, to put it very bluntly, just exactly which of the 
over a thousand packages are worth waiting on?  And who decides which package 
holds up progress?  CIPE, the example used here, is relatively insecure to 
begin with and interoperates with nobody.  Better to use IPsec (which 
virtually everybody supports to a degree) than a relatively nonstandard VPN 
like CIPE (I'd go as far as to say that most of the other VPN solutions are 
in the same boat; what's needed on the server side is typically 
Microsoft-compatible PPP over L2TP over IPsec, which is so easy to set up on 
the Windows client side it isn't even funny).  That's why for-purpose 
firewall/VPN appliance Linux dists (SmoothWall and Astaro, for instance) are 
not using anything but IPsec.  I have a SmoothWall box myself, and it Just 
Works.

> Is there a reason that a Centos or third-party repository
> could not be arranged such that an explicit upgrade could be
> requested to a current version which would then be tracked like
> your kernel-xxx-version is when you select smp/hugemem/unsupported?

Yes, a couple: 1.)	Lack of manpower to do the tracking;  2.) Doesn't fit the 
purpose for which CentOS was targeted.  CentOS is supposed to be 'I Can't 
Believe it's not Red Hat' enterprise Linux.  That 'explicit upgrade' might 
break many many things.  

For instance, suppose you want PostgreSQL 8 instead of the supplied 7.4.  Ok, 
now you have a maintenance nightmare, as all kinds of packages link to libpq, 
and the current 8.0.x release has a bumped libpq soversion.  So how do you 
deal with this without making it virtually impossible for the maintainers to 
maintain? (I know the answer to that, but it creates its own problems, and 
that is a compat-postgresql-libs RPM to supply the older libpq, but that 
doesn't tackle all the problems).  

Perl is another good example; upgrade perl and you could break all kinds of 
things.  Or Python; upgrade python and break all kinds of things, including 
most of the system-config-* utilities.  Or gcc.  Or the kernel.  Or glibc for 
a real humdinger.  No package in CentOS is in a vacuum; so how many 
combinations need to be supported?  Ok, suppose you have two choices of PHP 
version and three choices of PostgreSQL version (PHP4 and 5, PostgreSQL 7.4, 
8.0, and the upcoming 8.1).  Now, how many combinations of those will you 
support?  You going to built six different sets of RPM's (since PostgreSQL 
can be built with a 'pl/PHP' stored procedure language, PostgreSQL and PHP 
depend upon each other.  The other PL's, PL/Python and PL/Perl (yes, you can 
use Perl and Python to create stored procedures in PostgreSQL; addons are 
available to use Java, R, and even Bash in the backend) have even more 
dependencies.

Which combinations should be supported?

Now exponentiate by a factor of 1000 packages.  

Not reasonable to do given the resources.  Why not just use Fedora, since it 
tracks more or less what you want?  Or, use gentoo.  Or get really ambitious 
and do Linux From Scratch and make it just exactly how you want it.

> There are times when you want predictable behavior, and times when
> you want correct behavior.   When an upstream app makes changes
> that provide correct behavior but you are ensured of the old
> buggy behavior as a matter of policy, something is wrong.

What is 'correct' behavior?  Doesn't correctness depend upon the customer?  Is 
it possible that CentOS (and RHEL by extension) is Not For Everybody, but 
targeted to a particular set of customers?

> > In reality, what you're looking for is Fedora Core, not RHEL.

> Well, FC1 seems like the only way to get the specific mix
> of working kernel and apps for certain things right now, but
> it is by definition a dead end - and not really up to date
> on the app side either.

If you want your custom versions of apps, then you can either do the legwork 
yourself (that is, backport your own security fixes) or pay someone to do it.  
If no one else wants it, then you will pay lots of money.  But a volunteer 
project is under no obligation to fill the needs of every person who wants it 
'their way' unless said person can afford to either do some legwork or pay 
someone to do some legwork or convince the Powers That Be that It Is Such A 
Good Idea that the project cannot do without it.  

> > developments.  Red Hat used to actively include CIPE in the kernel, and
> > test it as their standard VPN solution.

> Hence my surprise at their change of direction.

CIPE is not an industrial strength VPN and gives a false sense of security.  
Thus it needed to be removed since a false sense of security is worse than no 
security at all.  Further, with the 2.6 kernel you get in-kernel IPsec, which 
is quite a bit more secure and is an actual standard.

> It's something a decision to change kernels runs into.  The CIPE
> author didn't make that decision.

No, like all others the CIPE author chose to pull an ostrich and hope to not 
be run over by the 2.6 Linux train.  That, IMHO, was not wise on the part of 
the CIPE author.  So Red Hat can either 1.) wait on CIPE; or 2.) wait on 
deploying 2.6 with all its much-more-critical-than-CIPE-features while the 
CIPE author gets his act together, or pay someone to fix CIPE, which, even 
according to you, would be very difficult.  Which would you choose if you 
were in Red Hat's shoes?  How important would CIPE be to you?  There are 
thousands of similar things and similar decisions, and the choice sometimes 
is not easy.

> I just don't remember seeing any discussion of this on the CIPE
> mailing list which is the only place it might have been resolved.

It is not Red Hat's job, or the kernel developers' jobs, to make it easy on 
the CIPE author.

> I don't see how anyone but Olaf Titz could have made the necessary
> changes, and I don't see why he would have done so with appropriate
> timing for the FC2 release unless someone involved in the release
> made him aware of the planned changes.

If you want your software to coexist with others' software, it is your 
responsibility to be informed of the issues for your software; the other 
parties have no obligation to make it easy on you.  There is no excuse for 
the CIPE community to not know what was happening, and it isn't the 
responsibility of the kernel developers or Red Hat to go hand-hold every 
author of every impacted module of all of the over 1000 packages shipped in 
Red Hat/ Fedora Core Linux.

> An interface is supposed to be a form of contract among programmers
> that is not changed.  Linus has consistently refused to freeze his
> interfaces, hence the lack of binary driver support from device
> vendors, and frankly I'm surprised at the the number of open
> source developers that have continued to track the moving target.

Linus != Red Hat.  This is a Linus issue; not a Red Hat issue.  Thus the 
subject line.  You can't blame Red Hat for something Linus caused.

Red Hat needed the features from 2.6 for other things; Red Hat needed to get 
on the 2.6 bandwagon for marketing purposes, too; CIPE's author was reticent 
to make his software work with a kernel version that had been out for a long 
time;  Red Hat had no choice but to drop CIPE.  If CIPE wants in, CIPE has to 
play the game, too.
-- 
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu



More information about the CentOS mailing list