Just as a bit of feedback for the guys at SuSE/Novell - It would have
been nice to stretch this window a bit to wait till SuSE 10.2 ships. - I
have always found the x.2 distributions the most stable ones and will
not upgrade my 9.2 boxes till 10.2 ships.
Best regards
Hubba
Message
Subject: [suse-security-announce] Discontinued SUSE Linux Distribution: 9.2
Date: Thu, 7 Sep 2006 09:04:15 +0200
From: Marcus Meissner <meissner (AT) suse (DOT) de>
To: suse-security-announce (AT) suse (DOT) com
Dear suse-security-announce subscribers and SUSE Linux users,
SUSE Security announces that SUSE Linux 9.2 will be discontinued soon.
Having provided security-relevant fixes for more than two years,
vulnerabilities found in SUSE Linux 9.2 after 15th 2006 will
not be fixed any more for this product. We expect to release
the last updates around 31st 2006.
As a consequence, the SUSE Linux 9.2 distribution directory on our ftp
server ftp.suse.com will be moved from /pub/suse/i386/9.2/ to the
/pub/suse/discontinued/ directory tree structure to free space on our
mirror sites. The 9.2 directory in the update tree
/pub/suse/i386/update/9.2 will follow, as soon as all updates have been
published.
The discontinuation of SUSE Linux 9.2 enables us to focus on the SUSE
Linux and openSUSE distributions of a newer release dates to ensure that
our customers can continuously take advantage of the quality that they
are used to with SUSE Linux products.
This announcement holds true for SUSE Linux 9.2 only. As usual, SUSE
will continue to provide update packages for the following products:
SUSE Linux 9.3
SUSE Linux 10.0
and
SUSE Linux 10.1
for a two-year period after the release of the respective distribution.
Please note that the maintenance cycles of SUSE Linux Enterprise products
and products based on the SUSE Linux Enterprise Server operating system
are not affected by this announcement and have longer life cycles.
To learn more about SUSE Linux business products, please visit
. For a detailed list of the life cycles
of our Enterprise Products please visit
and
If you have any questions regarding this announcement, please do not
hesitate to contact SUSE Security at <security (AT) suse (DOT) de>.

Hubertus A. Haniel wrote:
Just as a bit of feedback for the guys at SuSE/Novell - It would have
been nice to stretch this window a bit to wait till SuSE 10.2 ships. - I
have always found the x.2 distributions the most stable ones and will
not upgrade my 9.2 boxes till 10.2 ships.

Based on my experiences with 10.1, I hope 10.2 ships REAL SN. I'll
not upgrade any more of my boxes to 10.1. In spite of all my attempts,
I have yet to get online update to work.

Sep 18, Geoffrey <esoteric (AT) 3times25 (DOT) netwrote:

Based on my experiences with 10.1, I hope 10.2 ships REAL SN. I'll
not upgrade any more of my boxes to 10.1. In spite of all my attempts,
I have yet to get online update to work.

Although beta (and with some small known bugs), I'm quite happy with fou4s
on 10.1 :)

But you are right, my first action on every 10.1 Installation is
rpm -e rug zmd zen-updater
;-)
(It just sucks that a process is eating cpu like crazy when I would like
to work AND it eats CPU when I want it to work!)

I'm also quite happy with the smart updater, but it doesn't offer update
descriptions, so fou4s is still good to have
For KDE, Firefox, etc smart is the tool of choice.

Markus

Mon, Sep 18, 2006 at 01:00:02PM +0100, Hubertus A. Haniel wrote:
Just as a bit of feedback for the guys at SuSE/Novell - It would have
been nice to stretch this window a bit to wait till SuSE 10.2 ships. - I
have always found the x.2 distributions the most stable ones and will
not upgrade my 9.2 boxes till 10.2 ships.

We have a 2 year rhythm ;)

9.3 and 10.0 were on the same stability level als 9.2 in my opinion,
if not more stable. I had no complains or problems with 10.0.

Ciao, Marcus

Marcus Meissner wrote:
Mon, Sep 18, 2006 at 01:00:02PM +0100, Hubertus A. Haniel wrote:
>Just as a bit of feedback for the guys at SuSE/Novell - It would have
>been nice to stretch this window a bit to wait till SuSE 10.2 ships. - I
>have always found the x.2 distributions the most stable ones and will
>not upgrade my 9.2 boxes till 10.2 ships.

We have a 2 year rhythm ;)

Which makes 10.2 late by about a month and a bit ;)

9.3 and 10.0 were on the same stability level als 9.2 in my opinion,
if not more stable. I had no complains or problems with 10.0.

I found text mode yast a bit temperamental on 9.3 but 10.0 is arguably a
very stable release - every rule has an exception ;) - It is a lot of
work to upgrade my box at home which I depend on very much and I rather
not touch it more then every two years apart from the odd security
update. I guess that means I will not have to touch it at all from the
end of till beginning of December but I may have to pray that
there are no major vulnerabilities I will end up manually patching myself.

Best regards
Hubba

Mon, Sep 18, 2006 at 05:19:45PM +0100, Hubertus A. Haniel wrote:
Marcus Meissner wrote:
Mon, Sep 18, 2006 at 01:00:02PM +0100, Hubertus A. Haniel wrote:
>>Just as a bit of feedback for the guys at SuSE/Novell - It would have
>>been nice to stretch this window a bit to wait till SuSE 10.2 ships. - I
>>have always found the x.2 distributions the most stable ones and will
>>not upgrade my 9.2 boxes till 10.2 ships.
>
>We have a 2 year rhythm ;)

Which makes 10.2 late by about a month and a bit ;)

Actually we have:

2 year life time

But the release cycle is different:

Previously:
strict 6 month release cycle
Now (with 10.1):
approximate 8 month release cycle

This is mostly to reduce stress on us, and Linux
is also not really as fast paced as it were in the last years ;)

Ciao, Marcus

Marcus Meissner wrote

Actually we have:

2 year life time

But the release cycle is different:

Previously:
strict 6 month release cycle
Now (with 10.1):
approximate 8 month release cycle

There was quite a long delay when moving to opensuse, which is understandable.
The interesting question is, if it will be possible again to run a SLES
and the SuSE version with the same codebase until the next SLES is released.
With SLES9, this was not possible, because 9.1 was dismissed before SLES 10
was released.
Since we try to run SLES on the important servers and the matching SuSE version
on all other hosts, this was a problem. We need some time (2-3 months) to
plan and perform the upgrade on all servers, so I really hope that 10.1
will be continued until SLES 11 has been out for some months.

For that to work, the SLES release cycle should not be longer than about
1 1/2 years. Can you say sth. about the planned release cycle for SLES?

cu,
Frank

Tue, Sep 19, 2006 at 09:45:19AM +0200, Frank Steiner wrote:
Marcus Meissner wrote

Actually we have:

2 year life time

But the release cycle is different:

Previously:
strict 6 month release cycle
Now (with 10.1):
approximate 8 month release cycle

There was quite a long delay when moving to opensuse, which is understandable.
The interesting question is, if it will be possible again to run a SLES
and the SuSE version with the same codebase until the next SLES is released.
With SLES9, this was not possible, because 9.1 was dismissed before SLES 10
was released.
Since we try to run SLES on the important servers and the matching SuSE version
on all other hosts, this was a problem. We need some time (2-3 months) to
plan and perform the upgrade on all servers, so I really hope that 10.1
will be continued until SLES 11 has been out for some months.

For that to work, the SLES release cycle should not be longer than about
1 1/2 years. Can you say sth. about the planned release cycle for SLES?

The SLES cycle is not in my area ;)
In general we plan to have 2 year cycles, but review them together with
ISVs and partners.

Regarding SUSE Linux with the same codebase If you find features lacking
in SLES but which are in SUSE Linux we definitely want to hear about it,
to improve upon our SLES package set.
( course for some of those we might have decided already not to include it,
but in general)

Ciao, Marcus

Marcus Meissner wrote

The SLES cycle is not in my area ;)

Too bad :-) If you like, forward my mail to those, whose area it is. Maybe
they would consider this idea in their release plans

In general we plan to have 2 year cycles, but review them together with
ISVs and partners.

So with 2 years, it will always be very very short to manage a common upgrade,
if SLES and SuSE hosts

Regarding SUSE Linux with the same codebase If you find features lacking
in SLES but which are in SUSE Linux we definitely want to hear about it,
to improve upon our SLES package set.

Ehm, except the few gigabytes of software SuSE has more than SLES? :-)
It's just that we run SuSE for our clients and some special servers
who serve the diskless clients (by exporting themselves, so they must
have the same S like the clients). And it is nice to have a common code
base for desktop clients and servers, so from time to time they can
benefit from each other (like exchanging kernels, or having xv on the
servers etc. :-))

cu,
Frank

Tue, Sep 19, 2006 at 04:55:20PM +0200, Frank Steiner wrote:
Marcus Meissner wrote

The SLES cycle is not in my area ;)

Too bad :-) If you like, forward my mail to those, whose area it is. Maybe
they would consider this idea in their release plans

In general we plan to have 2 year cycles, but review them together with
ISVs and partners.

So with 2 years, it will always be very very short to manage a common upgrade,
if SLES and SuSE hosts

The _life_ cycle of our Enterprise Products is 5 years regular
maintenance, and 2 more years of extended
maintenance.

We just release new ones every 2 years.

(as per current status)

As for common upgrade, if you really want to track both, then yes.

Regarding SUSE Linux with the same codebase If you find features lacking
in SLES but which are in SUSE Linux we definitely want to hear about it,
to improve upon our SLES package set.

Ehm, except the few gigabytes of software SuSE has more than SLES? :-)
It's just that we run SuSE for our clients and some special servers
who serve the diskless clients (by exporting themselves, so they must
have the same S like the clients). And it is nice to have a common code
base for desktop clients and servers, so from time to time they can
benefit from each other (like exchanging kernels, or having xv on the
servers etc. :-))

In the end all necessary software should be covered by SLES+SLED+SDK.
I think xv is not (as your example).

I would suggest switching to some kind of solution where you export
chrooted SUSE Linux versions Should not be that hard, right?

Ciao, Marcus

Tue, 19 Sep 2006 06:11 pm, Marcus Meissner wrote:
If you find features lacking in SLES
but which are in SUSE Linux
we definitely want to hear about it,
to improve upon our SLES package set.
( course for some of those we might have
decided already not to include it, *but in general)

Lets have a look,
find all ".rpm" files in the 9.3 suse directory = 7493
find all ".rpm" files in SLES9 including all service packs = 4099
find all ".rpm" files in SLES9 CRE and SLES9 SLES = 2384

No wonder I am forever borrowing packages from 9.3
to overcome shortcomings of SLES9.

Usually it's a missing package; dovecot, PBS,

Sometimes it's to update a package;
eg: the SLES9 GD libraries aren't adequate to install bioperl.
so I have to install GD from 9.3,
then update the perl wrappers using CPAN.

I'm so used to not finding a SLES9 version
I would be looking for a solution to providing updates
to the SuSE components within a SLES install.

michaelj

Marcus Meissner wrote

In the end all necessary software should be covered by SLES+SLED+SDK.
I think xv is not (as your example).

Well, SLED is the keyword, we don't have licenses for it. I'm not
sure about the licence modell, but I assume it could be quite expensive
for some hundred clients? Without SLED, a lot is missing of course

I would suggest switching to some kind of solution where you export
chrooted SUSE Linux versions Should not be that hard, right?

That's the way Debian used to offer their diskless solutions. Actually
it isn't very nice: You always have to maintain two systems, you need
a special client that can mount the system rw for things that can't
be done with chroot on the server etc. It's a lot easier to let the
server export its own root (you would be amazed how few file really
differ between a server and a client :-)). However, that's a different
story

Shortening the SLES release cycle would be good thing anyway, because
thinks like mysql etc. that are served by our sles servers require a
more frequent update than a two-year-cycle, so we always recompile some
stuff after about one year :-(

cu,
Frank

Marcus Meissner wrote

Regarding SUSE Linux with the same codebase If you find features lacking
in SLES but which are in SUSE Linux we definitely want to hear about it,
to improve upon our SLES package set.

Just noticed: NX is missing. That's really needed because we use one
of our servers as nxserver. , I will use the packages from 10.1 now,
but that should be worth to be considered!

cu,
Frank

Frank Steiner wrote:
There was quite a long delay when moving to opensuse, which is understandable.
The interesting question is, if it will be possible again to run a SLES
and the SuSE version with the same codebase until the next SLES is released.
With SLES9, this was not possible, because 9.1 was dismissed before SLES 10
was released.
Since we try to run SLES on the important servers and the matching SuSE version
on all other hosts, this was a problem. We need some time (2-3 months) to
plan and perform the upgrade on all servers, so I really hope that 10.1
will be continued until SLES 11 has been out for some months.

For that to work, the SLES release cycle should not be longer than about
1 1/2 years. Can you say sth. about the planned release cycle for SLES?

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.

So when a given SLES release, and corresponding openSUSE .1 release,
come out, you deploy them simultaneously. You hit a problem 2 years
later when support for the .1 release expires, but the next generation
SLES has not been released yet.

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

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.

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.

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
we're that clever :) But now that you've pointed it out, I will ensure
that it is at least a conscious decision.

Crispin

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