[sles-beta] Antwort: Re: Old freeradius-server 2.1.1
Greg.Lehmann at csiro.au
Greg.Lehmann at csiro.au
Thu Feb 28 19:02:57 MST 2013
Hi Matthias,
Thanks for your explanation. To clarify my SP 6 month statement:
If we installed a server with SLES 11 SP1, on the day it came out, we would get patches for it until 6 months after SP2 came out. At that point we are forced to upgrade to SP2 to continue getting patches. We don't want to pay extra for extended support. It's nice you have it, but is not an option for us. The installation of an SP is a maintenance overhead that requires significant manual intervention and system administrator time. For a lot of our servers we want to be able to install it and leave it untouched except for monitoring for its life. We want patches to keep going onto it for its life. We want that life to be long, particularly since in the virtual world we don't have hardware refresh issues as far as the guest operating systems are concerned.
Maybe think of a Ubuntu LTS release as the SLES 11 GA release, but they keep supplying patches for it until the next LTS release (in your case SLES 12 GA.) They have 6 monthly releases in between LTS releases which might be similar to an SP update. The one other thing Ubuntu does is provide a driver update to the LTS release so you can actually install it on new hardware as it comes along.
I am not suggesting you adopt Ubuntu's model, just saying it is an example of a model that fits my requirements better than the current model you offer. I have outlined the reasons above. Because of the current model I am recommending people install Ubuntu instead of SLES in my organisation, unless there is a reason for SLES specifically. I actually personally prefer SLES but it is too labour intensive for us at present.
Regards,
Greg Lehmann
> -----Original Message-----
> From: sles-beta-bounces at lists.suse.com [mailto:sles-beta-
> bounces at lists.suse.com] On Behalf Of Matthias G. Eckermann
> Sent: Friday, 1 March 2013 11:14 AM
> To: SUSE Linux Enterprise Server Authorized Beta Program
> Subject: Re: [sles-beta] Antwort: Re: Old freeradius-server 2.1.1
>
> Hello Greg and all,
>
> On 2013-02-28 T 23:35 +0000 Greg.Lehmann at csiro.au wrote:
>
> > Customers (me for instance) are also saying they don't
> > want the effort of applying SPs within 6 months of
> > them coming out. SuSE could learn a lot from the
> > Ubuntu model which lets you have the cool features
> > options if you really must and the stability LTS
> > releases that don't need to be touched for 5 years
> > (except for patches of course.)
>
> I am afraid, I can not fully correlate the 6 months
> overlap question to your Ubuntu comparison. Anyway.
>
> SUSE offers up to 10 years support per Major Release and
> up to 5 years support per Service Pack, depending on
> customer needs.
>
> Our Service Packs deliver, and Kai detailed on that, a
> balance between stability, hardware enablement and
> innovation beyond hardware enablement.
>
> In that triangle, not breaking existing ISV certifications
> is a key requirement for Service Packs, specifically as
> SUSE Linux Enterprise is leading with respect to ISV
> certifications among Enterprise Linux distributions. In
> that context it might be interesting for you to monitor
> our Oracle certification for SUSE Linux Enterprise 11: we
> achieved the certification for SLES 11, kept it with SP1
> and also kept it for SP2, all by performing the necessary
> Oracle testsuite. In fact, we achieved the "ok" for SLES
> 11 SP2 before our biggest competitor achieved the first
> certification for his latest product major release. In my
> view, this nicely shows that we kept ABI stability on the
> ISV level, as required by our own rules for Service Packs.
>
> Second. Hardware enablement is significantly driven by our
> partners -- that's those guys, where you buy servers, or
> who produce the internals of your servers. Don't believe
> that we accept all their ideas: We don't. And I don't
> share a big secret, when I state that nevertheless about
> 60% of all implemented features for our Service Packs come
> from this one topic: hardware enablement.
>
> The third aspect is what I called "innovation beyond
> hardware enablement". Here indeed we often follow your
> direct input and requests, balanced by two parameters:
> * backward compatibility
> * general interest of a feature or functionality
> A lot of work in the area of IPv6 enablement or
> NFS improvements have been done here for example.
>
> Now let's come back to the two topics discussed here
> controversially:
>
> 1. This Thread started with an upgrade request for
> the "freeradius-server". Now, unfortunately the
> request was only for the version, and did not
> cover detailed information about concrete issues
> in a given customer environment.
> Please mind: I am not talking about long lists of
> bugfixes or features listed on the freeradius
> website. I am really talking about your concrete
> issues.
>
> I just checked our internal Feature- and Bug-Databases,
> and I could not find any feature request, nor is there
> any outstanding bug (those would be solved via a patch).
>
> Why should we trigger a version upgrade?
>
> 2. In contrast I hear voices that our Service Packs would
> not be optimized for stability, and would not guarantee
> compatibility, most often in the context of the
> Kernel version upgrade for SUSE Linux Enterprise 11 SP2.
>
> I am afraid, I disagree.
>
> About 18 months ago, Olaf Kirch explained as part of
> a Beta presentation for SUSE Linux Enterprise 11 SP2,
> why the Kernel version upgrade to Kernel 3.0 improves
> quality, stability, and how we manage to not violate
> backward compatibility. The session is available online:
>
> http://www.novell.com/huddle/event/index.php?event_id=64e761813f8
> 3dfc86fa1c6e0da5510c3
>
> That said, I am well aware that a number of you have
> run into issues -- most often those who work with
> non-open-source kernel modules. We are working with
> the respective partners (some also here in this
> community) to improve our common processes and thus
> the time to market.
>
> Summarizing, indeed, defining a Service Pack is always a
> balance -- between rules, goals and forces, which live in
> 1300+ impersonal feature requests and even more personal
> interaction. Such as this discussion. -- Thanks!
>
> so long -
> MgE
>
> > > -----Original Message-----
> > > From: sles-beta-bounces at lists.suse.com [mailto:sles-beta-
> > > bounces at lists.suse.com] On Behalf Of Kai Dupke
> > > Sent: Thursday, 28 February 2013 7:22 PM
> > > To: sles-beta at lists.suse.com
> > > Subject: Re: [sles-beta] Antwort: Re: Old freeradius-server 2.1.1
> > >
> > > On 02/28/2013 09:56 AM, martin.z.ziegler at daimler.com wrote:
> > > > So a consistent message "SPs include cool new features" or "SPs
> are
> > > > optimized for stability and are very conservative" would be very
> > > helpful.
> > >
> > > You're absolutely right, and the customers answer on what they want
> > > would be 'very cool features, not breaking anything but providing
> the
> > > newest stuff, in a conservative way', right?
> > >
> > > The generic goal is to keep stuff stable, on the other side there
> is
> > > demand for the one or the other change. In such cases we have to
> > > balance
> > > between various areas: resources, benefits, impact on existing
> > > installation, version update or backport, enterprise readiness.
> > >
> > > Some of this is not obvious at the first glance and might differ
> > > depending on the concrete scenario.
> > >
> > > Depending on the concrete package it might be any single or all of
> the
> > > above listed.
> > >
> > > On the other side we do the backports to support you and other
> > > customers. If you handle an SP like a major release then having
> less
> > > packages updated you have less packages to check dependencies on,
> but
> > > still have the option to use new features if backported.
> > >
> > > greetings
> > > Kai Dupke
> > > Senior Product Manager
> > > Server Product Line
> > > --
> > > Phone: +49-(0)5102-9310828 Mail: kai.dupke at suse.com
> > > Mobile: +49-(0)173-5876766 WWW: www.suse.com
> > >
> > > SUSE Linux Products GmbH - Maxfeldstr. 5 - 90409 Nuernberg
> (Germany)
> > > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG
> > > Nurnberg)
>
> --
> Matthias G. Eckermann Senior Product Manager SUSE® Linux
> Enterprise
> SUSE LINUX Products GmbH Maxfeldstraße 5 90409 Nürnberg
> Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG
> Nürnberg)
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta
More information about the sles-beta
mailing list