On Thu, 27 Mar 2003, Post, Mark K wrote:

> Ken Hall said:
> >The downside (I've found) of the SuSE philosophy on maintenance of the SLES
> >series is that they never (normally) release a new VERSION of a product to
> >fix a problem.  They just retrofit patches to the version supplied with the
> >distro.
> Hmm.  Sounds almost like IBM's philosophy of shipping PTFs and APARS for the
> current release.  Which would you say has more risk associated with it?
> Installing a patched version of the current release, or installing a brand
> new release?  I would (usually) prefer to install the patched version,
> myself.  A lot of things can change between releases of a package, including
> inter-product dependencies, configuration file changes, startup script
> requirements, and on, and on.  I would rather be relatively sure that the
> only thing different between what I'm running now and what I'm going to be
> installing is that a bug was squashed.


What I might do on my system, and what I'd do on yours (were I paid to
keep it running) are quite different things.

I have the latest (as at yesterday) 2.5 kernel. I _might_ put it on a
computer here, but not on yours unless I am sure you expect it to break
something important.


> >There also seem to be product features disabled or "missing", such as
> >Winbind in Samba, and quota support, sometimes because the various required
> >components aren't at the right level, or often for no apparent reason at
> >all.  When this happens, there's almost no way to fix it and stay within
> >the "official" support scheme.
> Things like this are usually options that can be selected at compile-time.
> You should have the source RPM for the package, so you should be able to
> tweak the spec file for it to turn those on, if you really want them.  You
> may find out the hard way, though, that they were left turned off for good
> reasons.  (Similar to the reasons that Red Hat didn't turn on LVM in their
> 7.2 platform.)  Linux distributors are not interested in gratuitously
> turning of functionality, since they'll usually get asked why something
> isn't available, when distribution xyz has it.  (Again, take Red Hat 7.2 and
> LVM for example.)

Be aware that if you do turn a feature on this way, your vendor might
not provide a patch for that feature if it's broken.

Don't expect LVM patches for the kernel from Red Hat (unless the patches
actually make LVM work), because RH didn't ship working LVM, and _knows_
its customers are not using it for production workloads.

I think RH did promise LVM in Psyche, when and if they actually got it
working.

Samba is up to 2.2.7 on RHL 7.x, 8.0

I just installed Samba on Woody. It's 2.2.3a-12 from security.debian.org.
Testing has an older version.

--


Cheers
John.

Join the "Linux Support by Small Businesses" list at
http://mail.computerdatasafe.com.au/mailman/listinfo/lssb

Reply via email to