On 09/19/2011 05:07 AM, Nico Kadel-Garcia wrote:
> On Mon, Sep 19, 2011 at 1:16 AM, Tanmoy Chatterjee<[log in to unmask]>  wrote:
>> On Sat, Sep 17, 2011 at 2:09 PM, Tanmoy Chatterjee<[log in to unmask]>  wrote:
>>> On Sat, Sep 17, 2011 at 1:48 PM, jdow<[log in to unmask]>  wrote:
>
>>>            This method here is different! Now if I enable SL6.1
>>> repositories only - then when the SL6.2 repo gets available - will it
>>> be available through the gui "SL addons>  yum..>  " or the method is
>>> different ?
>> THANKS FOR ALL THE RESPONSES.
>> But as a novice I would again request to shed some light on this part
>> of my queries.
>
> You have to pick. If you follow the upstream vendor's model, you use
> the "6.x" repository, and the updates to 6.2 will be automatically
> available. Whether you *install* them is your choice, but they'll be
> available. I recommend doing so.
>
> If you use the "6.1" repository, you'll get some updates for a while,
> but it will be unsupported in the relatively new feature. It is *not
> feasible* to maintain independent sets of backports to all the minor
> OS updates, the testing would be nightmarish, and upgrades of one
> component for 6.2 might require other individual upgrades not in 6.0
> or 6.1. Trying to maintain the multiple subreleases was a nightmare
> back in the old "Red Hat 6.0 through Red Hat 6.2" days of the freeware
> Red Hat releases, not RHEL or Scientific Linux or CentOS. Prying old,
> dead libraries out of the clawing grips of developers or "high
> availability" experts who preferred to say "oh, it's stable, no need
> for updates" and "it's my machine, don't you worry about it" was a
> source of incredible pain when they then came to me and groused about
> our network, storage, and open source integration issues when they
> refused to allow basic upgrades.
>
> I recently went through this with Subversion, and it was *painful*.
>
>>>> On my machine here I have two very demanding customers, me and my partner.
>>>> I kept it on 6.0 until the VM version I have looked stable with 6.1 and
>>>> there were no complaints. So I moved to 6.1 on the firewall machine. It
>>>> promptly tossed its X11 cookies with either nouveau (which I had setup
>>>> and working on 6.0) and nVidia drivers which I tried in frustration. The
>>>> next kernel update fixed the problem. (I was able to work around it since
>>>> I mostly administer from command-line anyway. And "startx" worked if I
>>>> told it to use a display other than the first one.)
>
> Yeah, NVidia is an open source problem.
>
>>>> So moving from 6.1 to 6.2 MIGHT cause problems that sticking with 6.1
>>>> and security updates only might avoid. But, then, it might not. What
>>>> level of risk are you willing to take, very low or very very low? That
>>> I can go up until that point when it becomes essential to reinstall
>>> the entire system.
>>> Then the very reason of installing SL ( instead of Fedora or similar
>>> distributions with 6 month release cycle) gets diluted.
>>>> is your call to make. You're you and I'm me. We face different demands.
>>> Thanks.
>
> Heads up. The longer you wait, the larger the likelihood of problems.
> Relatively frequent updates encourage the use of the supported
> configuration options, such as using /etc/sysconfig/[servicename],
> rather than hand-editing /etc/rc.d/init.d/[servicename] scripts and
> manually installing Perl modules direct from CPAN. And don't *get* me
> started on what the proprietary NVidia drivers do to the OpenGL
> libraries, except to say that they replace them with symlinks and
> don't mention it to the RPM system.

A small matter of Nvidia/ATI, Mozilla, and OpenOffice.

For Nvidia, ATI, or other proprietary drivers available from the vendor 
for Linux, I use the proprietary X windows driver.  In all current cases 
on any machine with which I have to work (including those equipped with 
Nvidia GPUs for high performance computing, such as our current latest 
compute engine running SL 6.x *EXCEPT* for the kernel in which we use 
the latest production kernel that allows special drivers -- such as 
those needed for the Infiniband interfaces on our nodes -- to function), 
the Nvidia package from Nvidia that builds the appropriate kernel device 
drivers for X windows does work.  Moreover, this adds all (or almost 
all) control over the functionality built into the hardware by the 
vendor.  Note that on some of our machines (including my office 
workstation that has USB 3 interfaces), we deviate from SL 6x (RHEL 6) 
in terms of the kernel as I just mentioned.  Thus far, for the hardware 
we have, both the Nvidia and ATI proprietary X windows drives seem to 
work -- requiring a rebuild whenever we change kernels.

For the Mozilla suite (Firefox, Thunderbird/Lightning, SeaMonkey), I 
personally use and prefer the latest production release from Mozilla. 
This means that I do not use the stock SL (RHEL) RPMs from the install 
or update mechanisms, and, as root, I do use the internal update 
mechanism from Mozilla.  I have found that Mozilla tracks security 
issues with a faster response time than the distributions seem to do 
(this may be a matter of opinion).  I also upgrade to the latest 
production release of the Mozilla suite (e.g., the Tbird in use on this 
machine is 6.0.2) simply to avoid later "gotchas" down the road.

Otherwise, my personal experience is the same:  keep current.  On 
primary servers, we do more qualification testing, particularly when a 
new major release goes production (e.g., RHEL 5 to RHEL 6 migration), 
and as I mentioned, we often go to later production kernels than what EL 
provides, mostly to get the correct driver/functionality support that 
was not backported to the earlier production kernel used by EL.

Yasha Karant