Yes, I also agree. We could have every two years (1 release on three) a LTS release. 2009/9/8 Per Jessen

Magnus Boman wrote:

...

For openSUSE 11.1, we will have updates ('support') for 18 months. Those who wants to provide long term support for 11.1, can simply create their own updates. It wouldn't be difficult to create a common repo where people can contribute to patches for this purpose and keep doing that for some 7 years or whatever the plan is. Heck, since we're not talking massive changes and updates, anyone can help out with this, as well as working on openSUSE Factory etc.

One issue with this, is that we normally clean up OBS by removing old, unsupported distro versions, but that is surely a decision that can be changed if there are such noble goals as to create a long term support cycle.

By creating an entirely new distribution, some folks that previously contributed to openSUSE will no longer have time for that, and put their efforts into the new distro instead. In my opinion, we are already short of people contributing and this split will obviously make that number even smaller.

So, please enlighten me what I'm not getting here...

You seem to make be making a lot of sense.

/Per Jessen, Zürich

-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Tue, 2009-09-08 at 09:06 +0200, Martin Schlander wrote:

Haven't followed this closely either, but the following advantages of "openSLES" over "openSUSE LTS" spring to mind.

* rebuilding SLES updates seems easier than creating your own from scratch * I guess SLES is supposed to be more stable and polished than openSUSE * A lot of stuff is certified and tested against SLES

Same reasons why CentOS has out-lived the Fedora Legacy project I guess :-)

But if you're talking about SLES, it has 7 year support cycle for each release. So again, for some of us, it's not clear. Are we talking about a free version of SLES? Or are we talking about a more stable long-term version of openSUSE? Two very different things. And two very different projects. -- Bryen Yunashko openSUSE Board Member GNOME-A11y Team Member www.bryen.com (Personal Blog) www.planet-a11y.net (Feed aggregator of the Accessibility Community) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Having a free version of SLES makes a lot of sense actually. Look at the CentOS project and how it compliments RH. I am no coder but will love to help. Eric On Tue, Sep 8, 2009 at 3:21 PM, Per Jessen wrote:

Bryen M Yunashko wrote:

...

But if you're talking about SLES, it has 7 year support cycle for each release.  So again, for some of us, it's not clear.  Are we talking about a free version of SLES?

You can follow this discussion on Boyds list:

http://lists.zenez.com/mailman/listinfo/opensle

...

Or are we talking about a more stable long-term version of openSUSE? Two very different things.  And two very different projects.

They have both been proposed, but I think the emphasis has turned towards a free SLES a la CentOS.

/Per Jessen, Zürich

-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Thu, Sep 17, 2009 at 23:35, Cristian Rodríguez wrote:

On 08/09/09 03:15, Bryen M Yunashko wrote:

...

Or are we talking about a more stable long-term version of openSUSE?

Stability and long-term support are completely different things.

+1 Agree here :) -- ------------------ Karl Fischer SFD 2009 : http://is.gd/2zsH7 www : http://floss.pro jid : kmf@floss.pro -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Lars Marowsky-Bree wrote:

On 2009-09-08T09:06:21, Martin Schlander wrote:

...

* A lot of stuff is certified and tested against SLES

You're aware that none of the certifications would hold for "openSLE" (or whatever the name is going to be), right? Certifications aren't tied to the source code, they're almost always tied to a specific, well-defined compilation _plus_ an active support/maintenance subscription.

I'm working in a big company and out of experience I can tell you that most third-party software vendors will give support if you run their software which is probably only certified for RHEL on the binary-compatible CentOS of the same version number. This might not meet your definition (and those vendors will probably not state the official support of CentOS on their web site), but that's how it works in practice. Of course, you need an active support subscription for that specific third-party software under consideration - why would you expect to get support without it. Cheers, Th. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Hi Lars, Lars Marowsky-Bree wrote:

[...] This only works as long as you take _exactly_ the same sources, and recompile them with _exactly_ the same options, resulting in _exactly_ the same package versions. Basically, you restrict the differences to the branding bits.

If even that - surely, /etc/SuSE-release will differ, zypper products etc too, which some apps (mistakenly) check for, so for example an Oracle installer will be unhappy.

Basically, if that is what you're striving for, there's very little differentiation except the price.

I admit that I'm not exactly thrilled by a distribution like that. It reminds me of Oracle's attempt to undermine Red Hat with UBL.

Well, what do you think CentOS really is at the end of the day?

[...] If you're going down that path, you might directly argue that the certification is worthless. (A position that is not without merit ;-)

Perhaps. It really depends on why a certification seems to be required in the first place. In other words, I think this needs to be looked at on a case by case basis.

[...] I wonder how you'd expect to resolve a bug that turns out to be in the OS, then. Pressure the app vendor to report it via their technology partnership, so that the base OS gets fixed/backported, and the fix gets re-published for free, while there's absolutely no contributing community? Nice stunt.

Frankly, I and my bank have opinions on that ;-)

Frankly speaking, I think you've missed the point and it looks like you didn't follow the email discussion over the last two weeks which becomes obvious from what you wrote here. Nobody said important servers should run an OS as proposed in Boyd's project. If you need support, install an Enterprise OS like RHEL or SLES. However, if you are running clusters with thousands of nodes, not all of them will require such a support level but may still have to run third-party software. Similar considerations hold of course for smaller businesses. At the end of the day, it's of course partly about money. Why do you think CentOS is relatively successful? Certainly not because of its first-class Enterprise support ;) As somebody pointed out recently, the business model currently used by RedHat and Novell may no longer work in the future.

If you're heading down that path, I would be more happy if you chose a real community distribution and became a contributor. But that may be a minority position.

Well, I have a position and an opinion as a private individual, and one position (which is more business related) and an opinion as somebody working for a large company where I have influence on OS, hardware, and software decisions. These opinions/positions do not necessarily agree with each other ;) I certainly observe that the more commercial opinions and positions are usually not very welcome in the community. I've certainly seen and observed what has gone on in our line of business over the last, say, two years and frankly speaking, I wouldn't be surprised if openSUSE/SLES loses more users/customers of a certain type described in some email threads here because the Fedora/CentOS/RHEL and the Ubuntu/Ubuntu LTS solutions become more attractive. You don't have to agree with me on that one, it's however my opinion based on recent experience. Only time will probably show what and who is right or wrong. Cheers, Thomas -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Tuesday 15 September 2009 22:07:34 Jason Perlow wrote:

That SUSE seems to have ceded the market for appliance server OS to Redhat/CentOS where an "OpenSLES" could provide some differentiation and superiority in the build system and various other aspects may be something that has been overlooked.

You do know that you can create a custom appliance OS from a choice of openSUSE 11.1, SLED 10 or 11 and also SLES 10 or 11 using the rather groovy susestudio.com? As far as I'm aware there's a Novell support channel available for those organisations that need it. Given that *nobody* else in the appliance server sphere has _anything_ like susestudio.com I'd hardly say this is a case of ceding the market ;) Cheers the noo Graham -- “Experience is the name everyone gives to their mistakes.” ☘ Oscar Wilde -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Tuesday 15 September 2009 21:39:09 Thomas Hertweck wrote:

If you need support, install an Enterprise OS like RHEL or SLES. However, if you are running clusters with thousands of nodes, not all of them will require such a support level but may still have to run third-party software.

Just FYI: There's a special SLES pricing for clusters - you don't pay the normal price as you do for a single machine. Andreas -- Andreas Jaeger, Program Manager openSUSE, aj@{novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126