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

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

On Sat, 2005-05-28 at 05:30, Bryan J. Smith wrote:
> 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?
No, I am looking for a solution that provides what a typical user needs,
not what a particular vendor feels like supporting this week.  I didn't
really want this to be about motives for vendor's business decisions but
I think Johnny Hughes nailed it in saying the push for 2.6 was because
SLES 9 had it.  Their decision wasn't stupid, but my point is that it
wasn't the best thing for some number of their old users.

I do understand that the particular bundles that RH arranges fit some
needs, and that in the big picture, most of this stuff lands on server
farms where one machine runs one program so if the next-version
distro runs on that machine, you take whatever else comes and it
doesn't matter.  I have a fair number of machines in that world,
including some that go all the way back to when VALinux was in the
hardware business and shipped with a paid copy of RH installed.

However, I also support a number of general-purpose servers and some
desktops where a larger mix of applications need to be integrated
along with a variety of oddball hardware that has, over the years
been connected and supported one way or another.  In this scenario
you are very likely to want to upgrade a single application and
find that you can't do it RedHat's-way(tm) because the bundled
upgrade will break something else that you need to keep running.

Explaining the reason the vendor made the decision that doesn't
work in my case isn't particularly helpful.  You might as well
try to explain to me why upgrading or installing certain MS
products require moving the whole enterprise to Active Directory
first. I'm not really interested in playing a 'vendor lock-in'
game.  I started using Linux in the first place to avoid that and
have a system where different components from different sources
could interoperate independently.  A system as bundled by Red Hat
is going back to the DLL-hell that windows users used to experience.
I can support this argument with details from my own experience but
I'd only expect anyone to care in the context of what a large number
of people need.  For that, I'd suggest browsing the k12ltsp project's
archives at http://www.redhat.com/mailman/listinfo/k12osn.

This project combines a fedora install with the ability to network-boot
thin clients so they run their desktop and apps from the server.  As
such they present the worst of all possible worlds in terms of needing
server-stability and up-to-date apps on the same distribution and it
has to run on an odd assortment of hardware.  Judging from the list
postings and my own testing, I'd guess that on the switch from the
FC1 to FC2 or FC3 based distros, people had about a 1 in 4 chance that
something would go drastically wrong in terms of hardware support
ranging from random crashes to lack of disk controller support and
perhaps a 50/50 chance that the ethernet interfaces would be dectected
with different names.  Maybe 10% would have serious enough problems
that they had to re-install the FC1 based version.

Now, is there a better solution?  I don't really want to hear another
rendition of why RH chooses not to provide current apps in a
distribution with a proven kernel, or why what's good for RH is good
for the whole world.  What I want is for this discussion to be about how
to get the product that I think a lot of people need, not about
brand loyalty to something that doesn't provide it. In the early
days of freshrpms.net, I thought that 3rd party update repositories
had a lot of promise but they ran into their own conflicts and in the
consolidation effort seem to have focused on adding apps not included
in the core product rather than updates to versions beyond stock.
Centosplus seems headed the same direction - and perhaps that's the best
anyone can do if they intend to offer any kind of testing and support.
What's missing is something that fills the gap between a user having
to rebuild from source himself and subsequently support the updates
the same way forever and the downrev repository versions.  Finding
firefox backed into the FC1 legacy update repository is the sort of
exception to the rule that I'd like to see expanded although it isn't
precisely the same change as going to (say) evolution 2.x.

For a simple example, let's say someone can run Centos 3.x but not 4.x
for any number of reasons, and they want current application features.
Can we, without degenerating into vendor bashing again, discuss how
such a thing would be possible in a way that every person who wants
this does not have to repeat every possible thing that could go wrong
in a local custom install, and repeat it again for every bugfix update?

Maybe Xen is the right direction to head to avoid this in the future.
If the apps really will only work right when bundled into a massive
distribution, then we should start planning for an emulated hardware
environment so the other parts of the next bundle can't break our
existing infrastructure.  I'd guess that currently the best real-world
solution is to keep running certain apps on the old box and install new
hardware for the ones you want to upgrade.  In practice the price might
even be right going that way, but it just doesn't appeal to my
engineering sense.

-- 
  Les Mikesell
    lesmikesell at gmail.com

On Sat, 28 May 2005, Bryan J. Smith wrote:
> 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?
I have a real problem with this thread. It seems as if, according to some, 
someone can only be with or against Red Hat.

I'm sure Red Hat has made stupid decisions, has adopted buggy software and 
are responsible for some of the headaches people have had. And I'm sure 
even Red Hat employees (like with any other distributor) would recognize 
this.

But just pointing things out does not put you on one or the other side, I 
may hope.

I always have a sour taste in my mouth if you have to pick sides, because 
that kills healthy rationalizing/critizing and often this has a hidden 
agenda attached to it.

--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]