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

[Bryan J. Smith]

Even I've left this thread.
I guess we're all waiting for Lee to turn Blue.  ;->
Or is it Red (Hat)?  ;->

Okay Lee, we all agree, Red Hat makes stupid decisions, adopts buggy software - especially the kernel and Red Hat is to blame for the decisions in the kernel, and also stupidly backports fixes instead of adopting newer versions with the fixes.
And there is absolutely no need for Red Hat to do so.

Happy?

-----Original Message-----
From:  Les Mikesell 
Date:  05-5-28 0:55
To:  CentOS mailing list 
Subj:  Re: [CentOS] Re: Demonizing generic Linux issues as Fedora	Core-only	issues -- WAS: Hi, Bryan

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