Re: momentarily disabling synaptic touchpad
On 09/19/2011 04:28 PM, William Shu wrote:
Hi,
I have SL 6.0 installed on a Seagate FreeAgent GoFlex USB
drive, which I use on various laptops (and desktops). The
touchpad is so sensitive on some machines and I would like to
disable it. At the same time, the attached mouse seems to be
selectively responsive, notably its left button. Looking
through the docs etc, a synaptics input driver has been
installed, but the corresponding xorg.conf file is not in
place for me to modify. (From a separate thread on nVidia,
creating this file is NOT automatic in SL 6.)
Hi William,
This is probably not exactly what you wanted. But, anyway...
I have a sweet little old lady (70+) on FC15 that the slide pad
drives
her crazy. She is constantly putting her had down on it when she
types.
She prefers to use her USB attached mouse. So I wrote the following
script for her. I don't remember where I put it though. Maybe her
rc.local.
HTH,
-T
#!/bin/bash
#Disable the [annoying] Slide Pad mouse
#DeviceStr="`xinput list | grep -i touchpad | awk '{print $6}'`"
#DeviceID="`echo $DeviceStr | sed -e 's/id=//'`"
DeviceID="`xinput list | grep -i touchpad | awk -F "id=" '{print
$2}'`"
if [ -z "$DeviceID" ]; then
echo "DeviceID failed to resolve. There is something wrong."
echo "Cowardly exiting. Bummer, dude ..."
echo ""
exit 1
fi
xinput set-prop $DeviceID "Device Enabled" 0
echo "touchpad mouse on device id $DeviceID has been disabled"
echo ""
Re: sl6.1 and sl6x
On Mon, Sep 19, 2011 at 11:36 AM, Connie Sieh wrote: > On Mon, 19 Sep 2011, Nico Kadel-Garcia wrote: > >> On Mon, Sep 19, 2011 at 1:16 AM, Tanmoy Chatterjee >> wrot= >> e: >>> >>> On Sat, Sep 17, 2011 at 2:09 PM, Tanmoy Chatterjee >>> wr= >> >> ote: On Sat, Sep 17, 2011 at 1:48 PM, jdow 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. I'm staring at what happened under RHEL 5.x with autofs updates, bind versus bind97, openldap versus openldap24, subversion updates, and samba3x updates with significant feature additions. The "security updates" are not enough to try and keep current with significant feature changes. And as long as the changes are locked off in the minor release change number by a refusal to expose the system to the "5.0 through 5.5 reales", rather than updating to 5.6, they'll be unavailable. This happens _every time_ there's a new point release, and I'm convinced from painful experience that keeping to the "5x" repositories rather than the active and current channel for upgrades introduces genuinely painful system skew. 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.
Need KVM HD settings advice
Hi All, I am confused. I am getting to the point were I am about to set up my first KVM server. My fist adventure will be to migrate an XP guest I currently have running on my old server under Virtual Box 3.2.12. What I need help with is getting the optimum performance settings while converting over my old hard (virtual) drive. This is what I have gathered from these parts as to the best settings: - controller: virtio - kvm option: cache=none - qcow2 disk format with metadata preallocation - create your disk image with: qemu-img create -f qcow2 -o \ size=400,preallocation=metadata vdisk.img So far so good. Now what I am concerned about is retaining the optimum settings from a converted hard drive. Also gathered from these parts is the best way to convert the hard drive: qemu-img convert -f vdi oldImage.vdi -O qcow2 newImage.qcow I am afraid I will loose all the optimum settings. And, I am vague how a *.qcow file/drive and a *.img file/drive relate. Many thanks, -T
Re: momentarily disabling synaptic touchpad
Hi William Shu! On 2011.09.19 at 16:28:32 -0700, William Shu wrote next: > I have SL 6.0 installed on a Seagate FreeAgent GoFlex USB drive, which > I use on various laptops (and desktops). The touchpad is so sensitive > on some machines and I would like to disable it. At the same time, the > attached mouse seems to be selectively responsive, notably its left > button. Looking through the docs etc,a synaptics input driver has been > installed, but the corresponding xorg.conf file is not in place for me > to modify. (From a separate thread on nVidia, creating this file is > NOT automatic in SL 6.) Btw, once you enable real-time configuration, you can do lots of magic with your touchpad, for example this snippet (works on modern systems but haven't checked on SL6 - but probably it should work) - tweaks touchpad so that double-finger tap works as middle button that's always missing on touchpads (of course, touchpad must supports multitouch) and also disables touchpad while you are typing text, so it won't be sending annoying commands during that. syndaemon -i 1 -d -K && xinput set-int-prop \"SynPS/2 Synaptics TouchPad\" \"Synaptics Two-Finger Pressure\" 32 10 &","0","*") It's kind of a magic so please don't ask me how it works, I have no idea :) It just does! -- Vladimir
Re: momentarily disabling synaptic touchpad
Hi William Shu! On 2011.09.19 at 16:28:32 -0700, William Shu wrote next: > I have SL 6.0 installed on a Seagate FreeAgent GoFlex USB drive, which > I use on various laptops (and desktops). The touchpad is so sensitive > on some machines and I would like to disable it. At the same time, the > attached mouse seems to be selectively responsive, notably its left > button. Looking through the docs etc,a synaptics input driver has been > installed, but the corresponding xorg.conf file is not in place for me > to modify. (From a separate thread on nVidia, creating this file is > NOT automatic in SL 6.) > > Question 1: If I create the xorg.conf file, would that later create > problems for me when I switch to other machines--legacy or recent? I > would not want some of the clashes (no/incorrect video, etc.) I > experienced with SL 52 on USB sticks. It will create problems if you switch configuration if you create full-fledged xorg.conf; for example video card ID on PCI bus creates problem, and video card driver. However good thing is, you don't have to create xorg.conf; modern xorg supports small snippets of config files in which you can tweak only some part of config, and letting everything else to be autoconfigured. Sadly, this doesn't work for some stuff like video (if you have to set gamma, you have to put all sections like video card - display - etc), but it works perfectly for input devices. So, it's best to be without xorg.conf at all, if your system can handle it (if you install nvidia binary drivers, you probably must have that file :( ) Here lies the trouble, however, as SL6 uses Xorg 7.4 which doesn't support udev-based configuration (it appeared in Xorg 8 and higher) or config snippets from /etc/X11/xorg.conf.d; it uses older method of hal-based configuration with config snippets from .fdi files. Check out this page, here you can find exact solution which should work in SL6.0: http://en.gentoo-wiki.com/wiki/Synaptics_Touchpad/Xorg_7.3 (of course, skip kernel & X11 compiling part :) So, just create .fdi and customize it with options from manpage to your liking, you can enable synclient real-time configuration, too. You won't have to touch anything else or xorg.conf and this file won't interfere with systems that don't have touchpads at all. This should answer your second question, too. > Question 3: Can the touchpad sometimes interfere with the use of the > mouse? If so, how to minimize interference. the [replacement] mouse I > use may not be the right quality? Seems unlikely, I'd suspect faulty mouse, but can never be sure.. Still, never heard or experienced any kind of interference between mouse, touchpad and touchscreen - they all seem to work in any combination. -- Vladimir
Re: [SCIENTIFIC-LINUX-USERS] System hangs on "Starting system logger" during initial boot
Thank you Pat and Bluejay for replying. Late last week, I found the culprit. It was the "cpuspeed". Not sure why (although I did find a couple of google references from users who had also had a problem with "cpuspeed"). I ended up making sure my kickstart script does not install it (basically added a "-cpuspeed" line to "%packages"), and it works much better now. I do like the idea of video-recording the screen, I have never tried that before (a lot of photographing the screen to capture items, but never tried video-recording it, will have to try that for the next problem). thanks, Paul On 09/19/2011 02:50 PM, Bluejay Adametz wrote: SCROLLLOCK should let you use PageUP to look at the text that went zooming past to see if anything interesting is afoot. Or, if all else fails, try video-recording the screen. I've actually had some luck doing that with my smartphone in cases where errors fly off the screen too fast. I was able to catch just enough to get me pointed in the right direction. - Bluejay Adametz Blore's Razor: Given a choice between two theories, take the one which is funnier. NOTICE: This message, including any attachments, is only for the use of the intended recipient(s) and may contain confidential and privileged information, or information otherwise protected from disclosure by law. If the reader of this message is not the intended recipient, you are hereby notified that any use, disclosure, copying, dissemination or distribution of this message or any of its attachments is strictly prohibited. If you received this message in error, please contact the sender immediately by reply email and destroy this message, including all attachments, and any copies thereof.
momentarily disabling synaptic touchpad
Hi, I have SL 6.0 installed on a Seagate FreeAgent GoFlex USB drive, which I use on various laptops (and desktops). The touchpad is so sensitive on some machines and I would like to disable it. At the same time, the attached mouse seems to be selectively responsive, notably its left button. Looking through the docs etc,a synaptics input driver has been installed, but the corresponding xorg.conf file is not in place for me to modify. (From a separate thread on nVidia, creating this file is NOT automatic in SL 6.) Question 1: If I create the xorg.conf file, would that later create problems for me when I switch to other machines--legacy or recent? I would not want some of the clashes (no/incorrect video, etc.) I experienced with SL 52 on USB sticks. Question 2: if synaptics driver is already installed, is it possible to have the fine control and features alluded to in the manual page (synaptics(4))? if so, how?The options in System->Preferences->Mouse->Touchpad are NOT helpful. Question 3: Can the touchpad sometimes interfere with the use of the mouse? If so, how to minimize interference. the [replacement] mouse I use may not be the right quality? Any help would be appreciated. Software details are: [root@localhost wss]# uname -a Linux localhost.localdomain 2.6.32-131.12.1.el6.i686 #1 SMP Tue Aug 23 11:12:55 CDT 2011 i686 i686 i386 GNU/Linux [root@localhost wss]# yum --disablerepo='*' whatprovides synaptics Loaded plugins: refresh-packagekit xorg-x11-drv-synaptics-1.2.1-5.el6.i686 : Xorg X11 Synaptics touchpad input : driver Repo : installed Matched from: Other : Provides-match: synaptics [root@localhost wss]# William.
Re: [SCIENTIFIC-LINUX-USERS] System hangs on "Starting system logger" during initial boot
> SCROLLLOCK should let you use PageUP to look at the text that went > zooming past to see if anything interesting is afoot. Or, if all else fails, try video-recording the screen. I've actually had some luck doing that with my smartphone in cases where errors fly off the screen too fast. I was able to catch just enough to get me pointed in the right direction. - Bluejay Adametz Blore's Razor: Given a choice between two theories, take the one which is funnier. NOTICE: This message, including any attachments, is only for the use of the intended recipient(s) and may contain confidential and privileged information, or information otherwise protected from disclosure by law. If the reader of this message is not the intended recipient, you are hereby notified that any use, disclosure, copying, dissemination or distribution of this message or any of its attachments is strictly prohibited. If you received this message in error, please contact the sender immediately by reply email and destroy this message, including all attachments, and any copies thereof.
Re: [SCIENTIFIC-LINUX-USERS] System hangs on "Starting system logger" during initial boot
On 09/13/2011 12:21 PM, Paul Jochum wrote: Hi All: On a SUN x4150 (that previously ran SL 5x fine), I have tried installing SL 6 (and 6.1 and 6.x). For each of my SL 6 installations, the system will hang during the boot at "Starting system logger[ OK ], and not accept any keyboard input (I can't do a CNTL-ALT-F2, for example, to bring up another console and see what is wrong). Scenario: New install, either through the GUI for from Kickstart. If I select option "minimal", then the system boots fine. However, if I select an option with a GUI (like "Virtualization"), then I run into this problem. Any suggestions on what to check? thanks, Paul Jochum paul.jochum @ alcatel-lucent.com Hi Paul, This one sounds tough. I'm not too sure I know how troubleshoot this one. but I have a few guesses. If I were to guess, I'd aim towards plymoth simply because, like the system logger, it starts early in the boot process, but it operates a bit differently when an X server is installed. You might try removingrhgbfrom the kernel boot line (in grub itself or /boot/grub/menu.lst) in the more massive install and see if that helps. You could also try adding vga=791 to the kernel boot line and see if that gets you anywhere. Removingquietfrom the boot line has sometimes provided hints where the system hangs at boot (though this was mostly back in the early days of Linux wireless where the kernel would hickup a bit when those modules got loaded). Sadly with it failing so early in the boot process the VTTYs wont be setup yet, so its a bit hard to diagnose the problem. I've found NUMLOCK and CAPSLOCK to be helpful in seeing if the system has locked up (these days ), and SCROLLLOCK should let you use PageUP to look at the text that went zooming past to see if anything interesting is afoot. Odds are I'm on the completely wrong track here, but this is at least some place to start. Pat -- Pat Riehecky Scientific Linux Developer
Re: Should yum-autoupdate depend on mailx?
Am Montag, 19. September 2011, 09:56:47 schrieb Pat Riehecky: > On 09/19/2011 08:52 AM, Alec T. Habig wrote: > > Dennis Schridde writes: > >> So it is indeed a bug? How should I progress from here? (I did not see > >> a > >> bugtracker on the website.) > > > > Since very few packages actually belong to SL (as opposed to TUV, who > > have their own bugzilla), we just say on the mailing list: "Hey Connie > > and Pat, here's an easily fixed bug!" > > > > Specifically, please add a mailx dependency to yum-autoupdate. > > > > Low tech but it works :) Reminds me of a "Letterman" cartoon episode, > > > > for example: > >http://www.youtube.com/watch?v=z3y_H3SaoAY&feature=results_video&p > >laynext=1&list=PLBE024B04B63BF3E8 > Adding it shouldn't be too much work, but from the distribution side we > don't want to force all our users to run a "sending only" mail server > (or more) unless they actually want to. I might instead add a check in > the script where, if sending mail doesn't look possible, it simply > doesn't try to send it. That way people don't have to worry about > surprise software installation on their next update. I know I'd freak > out if suddenly my system is running sendmail/postfix when it wasn't before. It does not seem that mailx requires sendmail/postfix (says "rpm -qR mailx"). So adding the dependency should be safe. --Dennis signature.asc Description: This is a digitally signed message part.
Re: Does SL6 support yum-plugin-security ?
As stated in other parts of this thread SL does not support yum-plugin-security because the repodata/ entries that are required to make it work are not available. Sorry for this limitation. -Connie Sieh
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 wrot= e: On Sat, Sep 17, 2011 at 2:09 PM, Tanmoy Chatterjee wr= ote: On Sat, Sep 17, 2011 at 1:48 PM, jdow 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: Should yum-autoupdate depend on mailx?
On 09/19/2011 08:52 AM, Alec T. Habig wrote: Dennis Schridde writes: So it is indeed a bug? How should I progress from here? (I did not see a bugtracker on the website.) Since very few packages actually belong to SL (as opposed to TUV, who have their own bugzilla), we just say on the mailing list: "Hey Connie and Pat, here's an easily fixed bug!" Specifically, please add a mailx dependency to yum-autoupdate. Low tech but it works :) Reminds me of a "Letterman" cartoon episode, for example: http://www.youtube.com/watch?v=z3y_H3SaoAY&feature=results_video&playnext=1&list=PLBE024B04B63BF3E8 Adding it shouldn't be too much work, but from the distribution side we don't want to force all our users to run a "sending only" mail server (or more) unless they actually want to. I might instead add a check in the script where, if sending mail doesn't look possible, it simply doesn't try to send it. That way people don't have to worry about surprise software installation on their next update. I know I'd freak out if suddenly my system is running sendmail/postfix when it wasn't before. -- Pat Riehecky Scientific Linux Developer
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 Chatterjee wrote: On Sat, Sep 17, 2011 at 2:09 PM, Tanmoy Chatterjee wrote: On Sat, Sep 17, 2011 at 1:48 PM, jdow 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 pr
Re: Should yum-autoupdate depend on mailx?
Dennis Schridde writes: > So it is indeed a bug? How should I progress from here? (I did not see a > bugtracker on the website.) Since very few packages actually belong to SL (as opposed to TUV, who have their own bugzilla), we just say on the mailing list: "Hey Connie and Pat, here's an easily fixed bug!" Specifically, please add a mailx dependency to yum-autoupdate. Low tech but it works :) Reminds me of a "Letterman" cartoon episode, for example: http://www.youtube.com/watch?v=z3y_H3SaoAY&feature=results_video&playnext=1&list=PLBE024B04B63BF3E8 -- Alec Habig, University of Minnesota Duluth Physics Dept. ha...@neutrino.d.umn.edu http://neutrino.d.umn.edu/~habig/ pgpiFpGqGEhDy.pgp Description: PGP signature
Re: sl6.1 and sl6x
On Mon, Sep 19, 2011 at 1:16 AM, Tanmoy Chatterjee wrote: > On Sat, Sep 17, 2011 at 2:09 PM, Tanmoy Chatterjee wrote: >> On Sat, Sep 17, 2011 at 1:48 PM, jdow 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.
