On Fri, 2005-05-27 at 19:13, Lamar Owen wrote:
> 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 think we've beaten these topics to death, but since it is kind of
fun if you don't take it too seriously: Which of these guys knows how
to make perl do character set conversions correctly better than the perl
team?
> > 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?'
Sigh... at this point it is "how many versions does the vendor support"?
And the issue is that the perl version (among many other things) that
does a certain operation correctly is only included with a kernel
version that has features missing and broken.
> > 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.
I don't see how you can call setting up a WAN with many CIPE nodes, then
finding it unavailable in the next release 'long term stability'.
> 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.
Can you run it through NAT routers? I have locations where the end
point is already NATed by equipment I don't control. CIPE doesn't
mind and the blowfish encryption is pretty CPU-friendly. And again, it
might be "long-term stability" if this had already been a choice in
several prior versions so you didn't have to upgrade OS revs on machines
in several countries on the same day to keep your machines connected.
> > 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.
Whatever happened to the Caos distribuion? I had some hopes that they
would combine a very stable kernel/libc combo with very up-to-date apps.
> 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).
So how is it better that when you do get Postgresql 8 in a distribution
you will likely get a largely untested kernel along with it? Or that
you compile your own version and end up with potentially unique problems
that every user has to solve individually?
> Which combinations should be supported?
>
> Now exponentiate by a factor of 1000 packages.
I used to laugh at the people running windows servers because they would
not even try to run more than one application per machine. But that was
when I compiled a lot of stuff by hand. Now that I've gotten lazy (or
smart...) and try to stick to binary distributions, I don't laugh any
more because now my Linux boxes are in exactly the same shape. I can't
count on being able to upgrade any single application without breaking
another one.
> 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.
Fedora breaks everything at once, so it isn't what I want. I want
"something like" being able to install a Centos 3.x base, then
selectively update certain apps to current-fedora level. A lot of this
would work with just a source rpm rebuild - but what I'm really after
is something that once done would still automatically pull updates
when the selected packages were fixed.
> > 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?
I think character set conversion is something where the correctness can
be determined objectively. And perl on Cento3 and Centos4 will do 2
different things. I'll take the perl team's word for it being made
correct in 5.8.3 and up.
> 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.
I have a feeling that the 2.6 kernel will become usable before that
happens this time around, but maybe by the next time RH rushes out
a largely broken release there will be viable competition in Ubuntu
and other distributions that will keep a working kernel under a
fast release schedule for the apps.
> > 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.
I don't see how the CIPE author has any reason to care one way or
another whether any particular distribution includes his package or
not. Why should he?
> 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?
Well, if I had previously included CIPE, promoted it's use, and wanted
anyone to think the distribution had long term stability...
> How important would CIPE be to you? There are
> thousands of similar things and similar decisions, and the choice sometimes
> is not easy.
Well, now we know how much value they place on maintaining
interoperability with their own older products. Don't forget that
when planning for the future.
> It is not Red Hat's job, or the kernel developers' jobs, to make it easy on
> the CIPE author.
Please explain how the CIPE author has any vested interest in this.
I would have expected Red Hat to try to provide their existing
users a way to upgrade one site at a time and remain compatible.
Now I don't expect much at all.
> > 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 made the decisions about if and when to ship it.
> 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.
CIPE doesn't have to play any game, but a version for 2.6 is available
and has been for some time. And before you say things had to be in
Fedora before shipping in RHEL, look at the Mysql version included in
RHEL4.
I think I asked before what things are measurably better in 2.6 and
didn't get any answers. Are there any?
--
Les Mikesell
lesmikesell@xxxxxxxxx
