On Wed, 2003-04-02 at 10:08, T. Ribbrock wrote:
> On Wed, Apr 02, 2003 at 08:44:17AM -0800, Cliff Wells wrote:
> [...]
> > It isn't clear to me how RedHat releasing newer versions of software
> > faster is going to make much difference.  RedHat doesn't write 99% of
> > the software in RH Linux.  What's the difference between the user
> > installing the latest version of Apache or Redhat supplying it? 
> [...]
> 
> Have you ever taken a closer look at RH's (S)RPMs (or for that matter
> the packages of any distributor)? At times, the differences are huge.
> Take e.g. the RH kernel and compare it to what you find on kernel.org.
> The amount of patches RH puts in is amazing. Same goes for most other

The things you see in the RH kernel are typically backports of features
from the development kernel.  Yes, it does make the RH kernel different,
but not terribly special.  Obviously, RH has developers (Alan Cox comes
to mind), but they typically don't just develop for RH.  They develop
for the entire community.  RH doesn't fork code.

> packages. In fact, if what RH packages *was* exactly what's in the
> tarballs, the whole "Blue Curve/KDE/GNOME" discussion would never have
> taken place - nor the "gcc 2.96" discussion. Neither would they need
> to have developers on their team - which they do, fortunately.

Bluecurve is a theme+engine.  You can get it for other distros as well. 
You can choose not to use it or even uninstall it from RH with no ill
effects.  GCC 2.96 was just a bad choice of compilers on RH's part
(although they made some reasonable arguments for having chosen it).

> The upside of this is the backporting of bugfixes and the addition of
> features while keeping compatibility with older versions (which is
> exactly what the x.y releases were all about). This has been a quality
> of RH I for one learned to appreciate.

Agreed.

> The downside of this is that you need a non-trivial amount of quality
> assurance - if you change the software, it's your responsibility it
> doesn't break. Again, I refer back to all discussions around "Blue Curve"
> or "gcc 2.96", to name but two examples.

I'm still not seeing the Bluecurve example, but I'll grant the GCC 2.96
problem.  Still the GCC issue would perhaps indicate that RH would have
been better off *following* the rest of the community rather than
striking out on their own.

> RH has been quite good at this in the past, but mostly in the later
> releases of a cycle. But such Q&A takes time. Therefore, it remains to
> be seen if they can deliver the quality we've become used to in the
> x.y releases (I've used 4.2 -> 5.2 -> 6.2 -> 7.3 - all of the were
> good releases, some even excellent at the time). The fact that RH is
> keeping quiet about their intentions in this regard doesn't help,
> either - and it certainly doesn't help *them*, as they might
> potentially loose customers.

I'll agree it remains to be seen (but then what doesn't?).  However, I
still stand by my argument that the difference between x.0 with all
updates and x.1 is minimal.  Speculation about losing customers is just
that: speculation.

> [...]
> > Besides, if you want a point release, wait a few weeks after a new RH
> > release comes out, install it and apply the updates from RHN.  Tada!  A
> > point release.
> 
> Right. So I have to pay for a product to which I *have* to apply tons
> of updates to get it to the point of quality I expected from it in the
> first place? I don't think so. I'm willing to spend money on x.y
> releases, which has all patches applied and tested - but not on a "x.0"
> which I have to patch myself.

Er, you don't patch your systems?  And what was your IP address?
<wink>.  Here's a clue:  *no* system has all the patches applied and
tested until it becomes obsolete.  There are *always* new patches needed
to address bugs and security holes.  The only reason someone's RH 6.2
system no longer gets patched is because no one is making the patches.

> > What exactly is the difference between x.0 with all the updates applied
> > and x.1?  Not much.
> 
> Work and my willingness to pay for it.

Then don't pay for it.  As far as work, I don't see using RHN or apt as
especially taxing.  Anyone who finds typing 'apt-get upgrade' or
clicking the little red exclamation point to be work probably costs RH
more in support than they make from them.

I'll grant some of your arguments (regarding GCC compatibility) but
let's keep it real.

-- 
Cliff Wells, Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308  (800) 735-0555 x308



-- 
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list

Reply via email to