On 09/19/2011 05:07 AM, Nico Kadel-Garcia wrote:
On Mon, Sep 19, 2011 at 1:16 AM, Tanmoy Chatterjee<bum....@gmail.com> wrote:
On Sat, Sep 17, 2011 at 2:09 PM, Tanmoy Chatterjee<bum....@gmail.com> wrote:
On Sat, Sep 17, 2011 at 1:48 PM, jdow<j...@earthlink.net> 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
