From: Frank Steiner (fsteiner-mail1bio.ifi.lmu.de)
Date: Fri Sep 22 2006 - 07:47:59 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Crispin Cowan wrote

> Naturally using SLES/SLED for your important boxes, and openSUSE for
> your other machines, is the intended design. We put a lot of work into
> the common code base, so that packages for SLES work on openSUSE and
> vice versa.

And we often used that in the past! Like running the SLES kernel on
a host that would for unknown reasons crash with every SuSE kernel.
Last use that really really saved us: The linuxrc of SuSE 10.1 can't
load modules specified on the pxe command line before starting the
hardware probe. Therefore we couldn't fix the detection of SCSI
controllers in an autoyast process. The solution was to used the
linuxrc from SLES 10 (that had the bug fixed already) for installing
the SuSE 10.1 hosts with autoyast.
That *really* rocks :-))

> You could solve this problem by deploying more SLES instead of openSUSE.
> But that costs money.

And not all our hosts can run SLES or SLED, for technical reasons.

> So instead, you could solve this problem by upgrading the .1 machines to
> 2 or .3, which certainly have not expired before the next SLES comes
> out. But that costs effort.

And it gives more problems: binaries compiled on the SLES hosts won't
run on the SuSE clients in many cases. If a glibc upgrade happens, the
systems are more or less incompatible. That's a real problems in our
environment, although I guess that the problem is not so big outside
universities/scientific environments...

> Saving you from forced upgrade effort is the value proposition that
> makes SLES cost money, so generically if upgrading too often is the
> problem, then buying SLES subscriptions is our proposed solution.

We have three-year subscriptions at the moment, but all the desktop
clients at the users desks have to run SuSE due to a specially designed
diskless system. Well, maybe that problem would be gone if there was a
SLESD = SLES+SLED+SDK release and if packman released for SLED (although,
due to the common code base, it should work...).

> Your schedule of using only .1 releases and rolling them just as the new
> SLES release comes out is elegant. I don't think that the company
> *deliberately* scheduled the expiring of .1 support and release of new
> SLES editions just to prevent your schedule from working; I don't think

I guess this time the problem was also caused by the delayed release of
10.1.

> we're that clever :) But now that you've pointed it out, I will ensure
> that it is at least a conscious decision.

Well, releasing the SuSE version that is the code base for the next SLES
about 3-4 months before the former code-base SuSE is dropped would be
enough. When I've extensively tested and configured the new SuSE, I'm
almos done because the SLES configuration doesn't need much more work
for a common code base. But switching from SusE 9.1 to 10.1 takes more
than a few weeks to detect and solve all problems the users could step
on in advance...
So, if the lifetime of two suceeding SLES-code-base SuSE releases
could overlap for three months (and if the next SLES is release within
that three months), that would really help :-))

BTW: have you given up the "major release is birthday of SuSE"? If 10.1
was released two years after 9.1, you have, I guess...

cu,
Frank

--
Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17 Phone: +49 89 2180-4049
80333 Muenchen, Germany Fax: +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *

--
Check the headers for your unsubscription address
For additional commands, e-mail: suse-security-helpsuse.com
Security-related bug reports go to securitysuse.de, not here

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]