Re: sl6.1 and sl6x
On Monday, September 19, 2011 09:09:45 PM you wrote: On Mon, Sep 19, 2011 at 11:36 AM, Connie Sieh cs...@fnal.gov wrote: It is not unsupported. You will get security updates but will not get the new features for each of the new point releases. ... In my opeinion and experience, it's a support rathole and contributes to developers and admins having to maintain their own, personal sets of drivers and binaries and libraries and destablilizing the whole mess. It certainly occurred with the upgrade from 5.5 and 5.6, I was able to throw away entire sets of poorly integrated user-built tools and replace them with supportable and better configured system tools from the upgrade. Nico, the way Connie has described is the way SL has run for quite some time now. They have made it work as best as is possible, and that is part of the way SL has done things. This is one of the differences between CentOS and SL; SL doesn't just put the older releases back in the vault and not support security updates on them, but actively supports security updates as much as is possible on the back releases. While I remember the old RHL days, and I remember the version skew in minor versions, I also see that in the EL world things are quite a bit different, and in this case different is good. Because of the version stability and the backporting policy, upstream can roll a security-only update to a critical package without version skew that breaks things. At least most of the time upstream can do that; when upstream's upstream makes the security patch to where it is difficult in the extreme to update, then a version bump will occur (like with Firefox, just to use a very visible example). Moving through EL5.0 through 5.7 has been almost completely painless (relative to the agony of older RHL minor versions), and I'm sure there are those out there who installed SL5.0 and have only taken critical security updates to 5.0. This is the way the SL project has chosen to do things. I remember, as I was the PostgreSQL maintainer at the time, the PostgreSQL major version upgrades during multiple minor version updates of the old RHL. Major version upgrades to PostgreSQL at that time broke your database completely. Because of the EL backport efforts, long-term support of multiple PostgreSQL versions has occurred, with security fixes applied across all of the upstream supported versions (upstream here not referring to the PostgreSQL project, but to Red Hat, who employs developers to do this). You have chosen to stay with the current feature patches, and that works for you. There are users of SL for whom that will not work, but they still get security fixes thanks to the work of the SL team, who, once again, have chosen to do things this way, and for whom it makes senser given their userbase. And this is all enabled by upstream's backporting policy.
Re: sl6.1 and sl6x
On Tue, Sep 20, 2011 at 6:22 AM, Lamar Owen lo...@pari.edu wrote: On Monday, September 19, 2011 09:09:45 PM you wrote: On Mon, Sep 19, 2011 at 11:36 AM, Connie Sieh cs...@fnal.gov wrote: It is not unsupported. You will get security updates but will not get the new features for each of the new point releases. ... In my opeinion and experience, it's a support rathole and contributes to developers and admins having to maintain their own, personal sets of drivers and binaries and libraries and destablilizing the whole mess. It certainly occurred with the upgrade from 5.5 and 5.6, I was able to throw away entire sets of poorly integrated user-built tools and replace them with supportable and better configured system tools from the upgrade. Nico, the way Connie has described is the way SL has run for quite some time now. They have made it work as best as is possible, and that is part of the way SL has done things. This is one of the differences between CentOS and SL; SL doesn't just put the older releases back in the vault and not support security updates on them, but actively supports security updates as much as is possible on the back releases. (snip) You have chosen to stay with the current feature patches, and that works for you. There are users of SL for whom that will not work, but they still get security fixes thanks to the work of the SL team, who, once again, have chosen to do things this way, and for whom it makes senser given their userbase. And this is all enabled by upstream's backporting policy. According to what I heard, SL has been doing it this way since the very beginning of the SL history. And it was based on users' request. Red Hat's EUS (extended update support) serves similar purposes but it was started much later than SL. Akemi
Re: sl6.1 and sl6x
On Mon, Sep 19, 2011 at 11:08 AM, jdow j...@earthlink.net wrote:
Seriously, I'd suggest you do one thing or the other. But I am not going
to make your decision for you. On one machine (a virtual box machine)
the transition from 6.0 to 6.1 was painless. (Or let's say no more pain
than already existed with SELinux.) On the other machine I had an nVidia
related problem that went away with a kernel update that happened
automatically. The virtual machine is on 6.x so I catch the upgrades
when they come. If no serious issues crop up I plan to move the main
Linux machine up to the next release after it's had a little time
to settle. But there's just my partner and I and about 20 machines and
assorted gadgets relying on the Linux machine. The needs for a larger
production environment will be different. The needs for a single desktop
user will also be different.
Assess your needs, determine what activities must be supported, determine
which OSs best support those activities. Then jump in and be prepared to
bleed a little. In the best possible world, there will be no blood. So
you'll feel good about that. If you bleed a little, you were emotionally
prepared already and have plans to cope, one hopes. So you feel good that
you coped. If you sit around dithering you feel bad all the way around.
Thank you very much for all the suggestions and for now I will opt for
SL6.1 repo until I get more use to with the new system.
Thanks again.
{o.o}
On 2011/09/18 22:16, Tanmoy Chatterjee wrote:
On Sat, Sep 17, 2011 at 2:09 PM, Tanmoy Chatterjeebum@gmail.com
wrote:
On Sat, Sep 17, 2011 at 1:48 PM, jdowj...@earthlink.net wrote:
On 2011/09/17 01:06, Tanmoy Chatterjee wrote:
On Sat, Sep 17, 2011 at 8:19 AM, Nico Kadel-Garcianka...@gmail.com
wrote:
On Fri, Sep 16, 2011 at 1:11 PM, Tanmoy Chatterjeebum@gmail.com
wrote:
On Fri, Sep 16, 2011 at 10:36 PM, Connie Siehcs...@fnal.gov
wrote:
On Fri, 16 Sep 2011, Tanmoy Chatterjee wrote:
Is there any difference between Sl6.1 and SL6x repositories? Do I
need
to enable only of these two or both?
sl6x is a symbolic link to the current release. So at the moment
sl6x
points to sl6.1 since sl6.1 is the current release. When we release
sl6.2
then sl6x will point to sl6.2 .
So you need to pick 1 . If you pick sl6x you will updated via the
yum
cron
job to the next release when it is released.
Thanks for the elaboration - so it is a good idea to enable the SL6x
repositories instead of SL6.1.
It's a choice, and it's actually a reasonable one to select 6.1. If
you follow the model of The Upstream Vendor, the 5.0, 5.1, 5.2
releases are all supposed to upgrade in place, automatically, to get
all current packages. 6.0 and 6.1 are timestamps for media
releases, and do not represent a different software repository
maintained by them. This avoids the amazing pain some of us had to
deal with for years, back with the original releases back when their
old 7.0 and 7.2 releases were likely to be incompatible.
This way works better, by not trying to split support among so many
sub releases.
Our friendly maintainers at Scientific Linux, understandably, don't
quite follow that, but with their common 5x repository, and
rolling releases, it's pretty close. I really appreciate using that
one or two repositories, instead of having to mix and match from point
releases.
Have really got confused after going through your entire post - so I
am asking again - is it better to enable SL6X than SL6.1?
At some point you have to accept responsibility for the choice based on
your specific needs. If you need a stable system with minimal changes
use 6.1. If you can accept a little additional risk and want product
updates as they are folded in then select 6.x.
Actually using Ubuntu 10.04 - I have found automatic upgradation takes
place via update process and without any problem ( i.e from 10.04.1 -
10.04.2 - 10.04.3).
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.
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.)
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
Re: sl6.1 and sl6x
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.
Re: sl6.1 and sl6x
On 09/19/2011 05:07 AM, Nico Kadel-Garcia wrote: On Mon, Sep 19, 2011 at 1:16 AM, Tanmoy Chatterjeebum@gmail.com wrote: On Sat, Sep 17, 2011 at 2:09 PM, Tanmoy Chatterjeebum@gmail.com wrote: On Sat, Sep 17, 2011 at 1:48 PM, jdowj...@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
Re: sl6.1 and sl6x
On Mon, 19 Sep 2011, Nico Kadel-Garcia wrote: On Mon, Sep 19, 2011 at 1:16 AM, Tanmoy Chatterjee bum@gmail.com wrot= e: On Sat, Sep 17, 2011 at 2:09 PM, Tanmoy Chatterjee bum@gmail.com wr= ote: On Sat, Sep 17, 2011 at 1:48 PM, jdow j...@earthlink.net wrote: =A0 =A0 =A0 =A0 =A0 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, You will get security updates for the full period that security updates are available for the 6 release. but it will be unsupported in the relatively new feature. It is *not It is not unsupported. You will get security updates but will not get the new features for each of the new point releases. 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 partn= er. 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. Th= e next kernel update fixed the problem. (I was able to work around it sin= ce 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. -Connie Sieh
Re: sl6.1 and sl6x
On Sat, 17 Sep 2011, Tanmoy Chatterjee wrote: Have really got confused after going through your entire post - so I am asking again - is it better to enable SL6X than SL6.1? If you stick with SL6.1 (or SL6.2 or ... ) you will get security updates only. If you go with SL6X you alse get feature enhancements. (Technically SL6.1 may also give you a few essential non-security updates but that is a confusing detail.) -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge a.c.aitchi...@dpmms.cam.ac.uk http://www.dpmms.cam.ac.uk/~werdna
Re: sl6.1 and sl6x
Irrespective of that confusing detail you mention, does this convention -- SL6X also provides feature enhancements -- break with TUV convention? My understanding is that if I were to take a RHEL 6.1 install bootable DVD and install RHEL 6.1, I would get the feature enhancements unless I selected against a package/utility description, and that if I do an update via the on-line (not physical media) update mechanism, I get the same as the DVD. Does SL6 not comply with this same update mechanism? Certainly with CentOS 5.m, the automatic update seems to provide enhancements, not just security fixes. My laptop just went from CentOS 5.6 to CentOS 5.7 . I am not installing any new CentOS systems -- these so far are continuing to be SL 6 . (E.g., my wife's laptop was stolen with CentOS 5 on it; when she gets a replacement, I will install SL 6 IA-32 unless the university can afford more than 4 Gbyte of RAM on the machine, in which case 64 bit mode is needed for full address space access.) A small side question: if SL6X happens to be pointing to SL6.m for some m (currently 2), after the update/enhancement will the target now display SL6.m as the installed release? Yasha Karant On 09/18/2011 12:15 AM, Dr Andrew C Aitchison wrote: On Sat, 17 Sep 2011, Tanmoy Chatterjee wrote: Have really got confused after going through your entire post - so I am asking again - is it better to enable SL6X than SL6.1? If you stick with SL6.1 (or SL6.2 or ... ) you will get security updates only. If you go with SL6X you alse get feature enhancements. (Technically SL6.1 may also give you a few essential non-security updates but that is a confusing detail.)
Re: sl6.1 and sl6x
On 2011/09/18 10:00, Yasha Karant wrote:
A small side question: if SL6X happens to be pointing to SL6.m for some m
(currently 2), after the update/enhancement will the target now display SL6.m as
the installed release?
Yes. That is what happened here upgrading from 6.0-6.1 via Yum.
cat /etc/issue
Scientific Linux release 6.1 (Carbon)
Kernel \r on an \m
{^_^}
Re: sl6.1 and sl6x
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:
On 2011/09/17 01:06, Tanmoy Chatterjee wrote:
On Sat, Sep 17, 2011 at 8:19 AM, Nico Kadel-Garcianka...@gmail.com
wrote:
On Fri, Sep 16, 2011 at 1:11 PM, Tanmoy Chatterjeebum@gmail.com
wrote:
On Fri, Sep 16, 2011 at 10:36 PM, Connie Siehcs...@fnal.gov wrote:
On Fri, 16 Sep 2011, Tanmoy Chatterjee wrote:
Is there any difference between Sl6.1 and SL6x repositories? Do I need
to enable only of these two or both?
sl6x is a symbolic link to the current release. So at the moment
sl6x
points to sl6.1 since sl6.1 is the current release. When we release
sl6.2
then sl6x will point to sl6.2 .
So you need to pick 1 . If you pick sl6x you will updated via the yum
cron
job to the next release when it is released.
Thanks for the elaboration - so it is a good idea to enable the SL6x
repositories instead of SL6.1.
It's a choice, and it's actually a reasonable one to select 6.1. If
you follow the model of The Upstream Vendor, the 5.0, 5.1, 5.2
releases are all supposed to upgrade in place, automatically, to get
all current packages. 6.0 and 6.1 are timestamps for media
releases, and do not represent a different software repository
maintained by them. This avoids the amazing pain some of us had to
deal with for years, back with the original releases back when their
old 7.0 and 7.2 releases were likely to be incompatible.
This way works better, by not trying to split support among so many
sub releases.
Our friendly maintainers at Scientific Linux, understandably, don't
quite follow that, but with their common 5x repository, and
rolling releases, it's pretty close. I really appreciate using that
one or two repositories, instead of having to mix and match from point
releases.
Have really got confused after going through your entire post - so I
am asking again - is it better to enable SL6X than SL6.1?
At some point you have to accept responsibility for the choice based on
your specific needs. If you need a stable system with minimal changes
use 6.1. If you can accept a little additional risk and want product
updates as they are folded in then select 6.x.
Actually using Ubuntu 10.04 - I have found automatic upgradation takes
place via update process and without any problem ( i.e from 10.04.1 -
10.04.2 - 10.04.3).
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.
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.)
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.
{^_^} Joanne
Re: sl6.1 and sl6x
Seriously, I'd suggest you do one thing or the other. But I am not going
to make your decision for you. On one machine (a virtual box machine)
the transition from 6.0 to 6.1 was painless. (Or let's say no more pain
than already existed with SELinux.) On the other machine I had an nVidia
related problem that went away with a kernel update that happened
automatically. The virtual machine is on 6.x so I catch the upgrades
when they come. If no serious issues crop up I plan to move the main
Linux machine up to the next release after it's had a little time
to settle. But there's just my partner and I and about 20 machines and
assorted gadgets relying on the Linux machine. The needs for a larger
production environment will be different. The needs for a single desktop
user will also be different.
Assess your needs, determine what activities must be supported, determine
which OSs best support those activities. Then jump in and be prepared to
bleed a little. In the best possible world, there will be no blood. So
you'll feel good about that. If you bleed a little, you were emotionally
prepared already and have plans to cope, one hopes. So you feel good that
you coped. If you sit around dithering you feel bad all the way around.
{o.o}
On 2011/09/18 22:16, Tanmoy Chatterjee wrote:
On Sat, Sep 17, 2011 at 2:09 PM, Tanmoy Chatterjeebum@gmail.com wrote:
On Sat, Sep 17, 2011 at 1:48 PM, jdowj...@earthlink.net wrote:
On 2011/09/17 01:06, Tanmoy Chatterjee wrote:
On Sat, Sep 17, 2011 at 8:19 AM, Nico Kadel-Garcianka...@gmail.com
wrote:
On Fri, Sep 16, 2011 at 1:11 PM, Tanmoy Chatterjeebum@gmail.com
wrote:
On Fri, Sep 16, 2011 at 10:36 PM, Connie Siehcs...@fnal.govwrote:
On Fri, 16 Sep 2011, Tanmoy Chatterjee wrote:
Is there any difference between Sl6.1 and SL6x repositories? Do I need
to enable only of these two or both?
sl6x is a symbolic link to the current release. So at the moment
sl6x
points to sl6.1 since sl6.1 is the current release. When we release
sl6.2
then sl6x will point to sl6.2 .
So you need to pick 1 . If you pick sl6x you will updated via the yum
cron
job to the next release when it is released.
Thanks for the elaboration - so it is a good idea to enable the SL6x
repositories instead of SL6.1.
It's a choice, and it's actually a reasonable one to select 6.1. If
you follow the model of The Upstream Vendor, the 5.0, 5.1, 5.2
releases are all supposed to upgrade in place, automatically, to get
all current packages. 6.0 and 6.1 are timestamps for media
releases, and do not represent a different software repository
maintained by them. This avoids the amazing pain some of us had to
deal with for years, back with the original releases back when their
old 7.0 and 7.2 releases were likely to be incompatible.
This way works better, by not trying to split support among so many
sub releases.
Our friendly maintainers at Scientific Linux, understandably, don't
quite follow that, but with their common 5x repository, and
rolling releases, it's pretty close. I really appreciate using that
one or two repositories, instead of having to mix and match from point
releases.
Have really got confused after going through your entire post - so I
am asking again - is it better to enable SL6X than SL6.1?
At some point you have to accept responsibility for the choice based on
your specific needs. If you need a stable system with minimal changes
use 6.1. If you can accept a little additional risk and want product
updates as they are folded in then select 6.x.
Actually using Ubuntu 10.04 - I have found automatic upgradation takes
place via update process and without any problem ( i.e from 10.04.1 -
10.04.2 - 10.04.3).
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.
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.)
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
Re: sl6.1 and sl6x
On Sat, Sep 17, 2011 at 8:19 AM, Nico Kadel-Garcia nka...@gmail.com wrote: On Fri, Sep 16, 2011 at 1:11 PM, Tanmoy Chatterjee bum@gmail.com wrote: On Fri, Sep 16, 2011 at 10:36 PM, Connie Sieh cs...@fnal.gov wrote: On Fri, 16 Sep 2011, Tanmoy Chatterjee wrote: Is there any difference between Sl6.1 and SL6x repositories? Do I need to enable only of these two or both? sl6x is a symbolic link to the current release. So at the moment sl6x points to sl6.1 since sl6.1 is the current release. When we release sl6.2 then sl6x will point to sl6.2 . So you need to pick 1 . If you pick sl6x you will updated via the yum cron job to the next release when it is released. Thanks for the elaboration - so it is a good idea to enable the SL6x repositories instead of SL6.1. It's a choice, and it's actually a reasonable one to select 6.1. If you follow the model of The Upstream Vendor, the 5.0, 5.1, 5.2 releases are all supposed to upgrade in place, automatically, to get all current packages. 6.0 and 6.1 are timestamps for media releases, and do not represent a different software repository maintained by them. This avoids the amazing pain some of us had to deal with for years, back with the original releases back when their old 7.0 and 7.2 releases were likely to be incompatible. This way works better, by not trying to split support among so many sub releases. Our friendly maintainers at Scientific Linux, understandably, don't quite follow that, but with their common 5x repository, and rolling releases, it's pretty close. I really appreciate using that one or two repositories, instead of having to mix and match from point releases. Have really got confused after going through your entire post - so I am asking again - is it better to enable SL6X than SL6.1?
Re: sl6.1 and sl6x
On 2011/09/17 01:06, Tanmoy Chatterjee wrote:
On Sat, Sep 17, 2011 at 8:19 AM, Nico Kadel-Garcianka...@gmail.com wrote:
On Fri, Sep 16, 2011 at 1:11 PM, Tanmoy Chatterjeebum@gmail.com wrote:
On Fri, Sep 16, 2011 at 10:36 PM, Connie Siehcs...@fnal.gov wrote:
On Fri, 16 Sep 2011, Tanmoy Chatterjee wrote:
Is there any difference between Sl6.1 and SL6x repositories? Do I need
to enable only of these two or both?
sl6x is a symbolic link to the current release. So at the moment sl6x
points to sl6.1 since sl6.1 is the current release. When we release sl6.2
then sl6x will point to sl6.2 .
So you need to pick 1 . If you pick sl6x you will updated via the yum cron
job to the next release when it is released.
Thanks for the elaboration - so it is a good idea to enable the SL6x
repositories instead of SL6.1.
It's a choice, and it's actually a reasonable one to select 6.1. If
you follow the model of The Upstream Vendor, the 5.0, 5.1, 5.2
releases are all supposed to upgrade in place, automatically, to get
all current packages. 6.0 and 6.1 are timestamps for media
releases, and do not represent a different software repository
maintained by them. This avoids the amazing pain some of us had to
deal with for years, back with the original releases back when their
old 7.0 and 7.2 releases were likely to be incompatible.
This way works better, by not trying to split support among so many
sub releases.
Our friendly maintainers at Scientific Linux, understandably, don't
quite follow that, but with their common 5x repository, and
rolling releases, it's pretty close. I really appreciate using that
one or two repositories, instead of having to mix and match from point
releases.
Have really got confused after going through your entire post - so I
am asking again - is it better to enable SL6X than SL6.1?
At some point you have to accept responsibility for the choice based on
your specific needs. If you need a stable system with minimal changes
use 6.1. If you can accept a little additional risk and want product
updates as they are folded in then select 6.x.
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.)
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
is your call to make. You're you and I'm me. We face different demands.
{^_^}Joanne
Re: sl6.1 and sl6x
On Sat, Sep 17, 2011 at 1:48 PM, jdow j...@earthlink.net wrote:
On 2011/09/17 01:06, Tanmoy Chatterjee wrote:
On Sat, Sep 17, 2011 at 8:19 AM, Nico Kadel-Garcianka...@gmail.com
wrote:
On Fri, Sep 16, 2011 at 1:11 PM, Tanmoy Chatterjeebum@gmail.com
wrote:
On Fri, Sep 16, 2011 at 10:36 PM, Connie Siehcs...@fnal.gov wrote:
On Fri, 16 Sep 2011, Tanmoy Chatterjee wrote:
Is there any difference between Sl6.1 and SL6x repositories? Do I need
to enable only of these two or both?
sl6x is a symbolic link to the current release. So at the moment
sl6x
points to sl6.1 since sl6.1 is the current release. When we release
sl6.2
then sl6x will point to sl6.2 .
So you need to pick 1 . If you pick sl6x you will updated via the yum
cron
job to the next release when it is released.
Thanks for the elaboration - so it is a good idea to enable the SL6x
repositories instead of SL6.1.
It's a choice, and it's actually a reasonable one to select 6.1. If
you follow the model of The Upstream Vendor, the 5.0, 5.1, 5.2
releases are all supposed to upgrade in place, automatically, to get
all current packages. 6.0 and 6.1 are timestamps for media
releases, and do not represent a different software repository
maintained by them. This avoids the amazing pain some of us had to
deal with for years, back with the original releases back when their
old 7.0 and 7.2 releases were likely to be incompatible.
This way works better, by not trying to split support among so many
sub releases.
Our friendly maintainers at Scientific Linux, understandably, don't
quite follow that, but with their common 5x repository, and
rolling releases, it's pretty close. I really appreciate using that
one or two repositories, instead of having to mix and match from point
releases.
Have really got confused after going through your entire post - so I
am asking again - is it better to enable SL6X than SL6.1?
At some point you have to accept responsibility for the choice based on
your specific needs. If you need a stable system with minimal changes
use 6.1. If you can accept a little additional risk and want product
updates as they are folded in then select 6.x.
Actually using Ubuntu 10.04 - I have found automatic upgradation takes
place via update process and without any problem ( i.e from 10.04.1 -
10.04.2 - 10.04.3).
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 ?
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.)
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.
{^_^} Joanne
sl6.1 and sl6x
Is there any difference between Sl6.1 and SL6x repositories? Do I need to enable only of these two or both? Thanks for any suggetion.
Re: sl6.1 and sl6x
On Fri, 16 Sep 2011, Tanmoy Chatterjee wrote: Is there any difference between Sl6.1 and SL6x repositories? Do I need to enable only of these two or both? sl6x is a symbolic link to the current release. So at the moment sl6x points to sl6.1 since sl6.1 is the current release. When we release sl6.2 then sl6x will point to sl6.2 . So you need to pick 1 . If you pick sl6x you will updated via the yum cron job to the next release when it is released. -Connie Sieh Thanks for any suggetion.
Re: sl6.1 and sl6x
On Fri, Sep 16, 2011 at 10:36 PM, Connie Sieh cs...@fnal.gov wrote: On Fri, 16 Sep 2011, Tanmoy Chatterjee wrote: Is there any difference between Sl6.1 and SL6x repositories? Do I need to enable only of these two or both? sl6x is a symbolic link to the current release. So at the moment sl6x points to sl6.1 since sl6.1 is the current release. When we release sl6.2 then sl6x will point to sl6.2 . So you need to pick 1 . If you pick sl6x you will updated via the yum cron job to the next release when it is released. Thanks for the elaboration - so it is a good idea to enable the SL6x repositories instead of SL6.1. One more thing I want to know is fastbugs updates are safe to install? -Connie Sieh Thanks for any suggetion.
Re: sl6.1 and sl6x
On Fri, Sep 16, 2011 at 1:11 PM, Tanmoy Chatterjee bum@gmail.com wrote: On Fri, Sep 16, 2011 at 10:36 PM, Connie Sieh cs...@fnal.gov wrote: On Fri, 16 Sep 2011, Tanmoy Chatterjee wrote: Is there any difference between Sl6.1 and SL6x repositories? Do I need to enable only of these two or both? sl6x is a symbolic link to the current release. So at the moment sl6x points to sl6.1 since sl6.1 is the current release. When we release sl6.2 then sl6x will point to sl6.2 . So you need to pick 1 . If you pick sl6x you will updated via the yum cron job to the next release when it is released. Thanks for the elaboration - so it is a good idea to enable the SL6x repositories instead of SL6.1. It's a choice, and it's actually a reasonable one to select 6.1. If you follow the model of The Upstream Vendor, the 5.0, 5.1, 5.2 releases are all supposed to upgrade in place, automatically, to get all current packages. 6.0 and 6.1 are timestamps for media releases, and do not represent a different software repository maintained by them. This avoids the amazing pain some of us had to deal with for years, back with the original releases back when their old 7.0 and 7.2 releases were likely to be incompatible. This way works better, by not trying to split support among so many sub releases. Our friendly maintainers at Scientific Linux, understandably, don't quite follow that, but with their common 5x repository, and rolling releases, it's pretty close. I really appreciate using that one or two repositories, instead of having to mix and match from point releases.
