SCIENTIFIC-LINUX-DEVEL Archives

March 2014

SCIENTIFIC-LINUX-DEVEL@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Reply To:
Date:
Wed, 26 Mar 2014 12:04:58 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (58 lines)
On Tue, 25 Mar 2014, Lamar Owen wrote:

> On 03/25/2014 08:48 AM, Andras Horvath wrote:
>
>> On Mon, 24 Mar 2014 16:55:25 -0500
>> Connie Sieh <[log in to unmask]> wrote:
>>> Point releases (7.1, etc.) might disappear. Expect them to not.
>> Would this mean that the support of the minor branches would end and only 
>> the most recent minor version would get the long term support? If so, then 
>> I strongly believe that one of the most precious advantages of SL would 
>> disappear - compared to CentOS AFAIK.
> This is one of the key distinctions between SL and CentOS, and I would 
> imagine is more than a small amount of work on the SL team, especially as the 
> number of point releases increase.  I would find it interesting to see who is 
> using this capability and specific reasons why they need (rather than want) 
> this capability (specific drivers for specialized hardware, etc).  I'm not 
> interested in debating the reasons why, just collating them.

As an LHC Tier-1 centre, albeit small, we very much like the feature
of sitting on a point release until we are ready to move to the next
point release.

We do not apply updates automatically.  We apply updates in an ordered
pattern.  Some updates are only applied after extensive testing
on pre-production systems.  For example, we are very sensitive to
storage-related issues.  Thus RPMs like device-mapper-multipath
and any associated RPMs, mt-st, mtx, kernel, etc. are applied only
after testing.

Storage is not the only sensitive area.  We also need to care about
other RPMs like java, tomcat, httpd, openssl, openldap and others
depending on which services are running on which machines.

At the juncture around a new SL point release, we see a much smaller
set of new updates than we would if we were pushed into the next
point release.  This is easy to deal with.

We also manage a handful of Red Hat systems, and as a system admin I
really hate to see the long list of RPMs that I need to sift through
whenever the point release rolls over.  We have no control over it.
It is made worse by needing to wait for maintenance windows when we
can apply patches.

By chosing the time when we move to the next point release, we keep
control.  This is important to us in managing some 530 Linux servers.

Note that we typically stay within 2 points of the latest point release.
I'm not sure why some people stay on a point release - perhaps they
will comment.

cheers, etc.
   Denice
-- 
deatrich @ triumf.ca, Science/ATLAS         PH: +1 604-222-7665
<*> This moment's fortune cookie:
Flying is the second greatest feeling you can have.  The greatest feeling?
Landing...  Landing is the greatest feeling you can have.

ATOM RSS1 RSS2