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
