On Sep 18, Geoffrey wrote:

Based on my experiences with 10.1, I hope 10.2 ships REAL SOON. 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 -- __________________ /"\ Markus Gaugusch \ / ASCII Ribbon Campaign markus(at)gaugusch.at X Against HTML Mail / \

Marcus Meissner wrote:

On 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 October 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

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 -- 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. *

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 OS 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 -- 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. *

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 -- 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. *

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. Ok, I will use the packages from 10.1 now, but that should be worth to be considered! 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. *

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. *