The unfortunate thing about downloading a whole new kernel is, it can't be done very easily, if at all, when one is on dial-up, so the 'fix' is pretty much non-existent.
This kind of screw-up should not have been allowed to go into production until it was fixed first. Now those of us who *are* stuck on dial-up with no alternative have to fret over *when* the system is going to freeze up on us (or when it will do it again....and again...ad nauseum). It's happened to me already 4 times and there's no telling when it's going to happen, it just does it. BTW, it's doing it with Seamonkey too, not just Firefox. I use Seamonkey almost exclusively on my KDE. Hard rebooting is going to tear up some hard drives eventually, and it's something I can barely afford as is. This 'problem' of freezing up in 11.3, is leaving a very bad taste and I've been using SuSE since 7.3. :(
It's not that simple. The thread I had in mind is "11.3 and very slow nvidia performance"; there were others, too. It appears that the problem can be card and user installation specific. Many if not most users have had no problem. Others' problem was resolved with an upgrade to the newer nvidia driver added to the repo, others switching to the nouveau driver (and losing compositing), others needed to download and manually install the driver from the nvidia website, others needed to upgrade to KDE 4.5, others needed a newer kernel version, others needed to add a kernel argument at boot, etc. The extent of aggravation ranged considerably, from zero to a solution relatively simple (once found) to others (such as having to download sources) obviously being prohibitive if one is on dial-up, is inexperienced, etc. IMHO, with the number of variables in the equation, and Linux distros not having the arbitrary control over 3rd-parties that Microsoft does (noting that, even so, this kind of thing periodically happens in the world of Windows, too), I'm afraid that incompatibility glitches are just going to occasionally happen and that it is impossible for distro testing to catch them all. Even when I worked in the world of large proprietary machines where we controlled *everything*, it was still standard customer practice to wait well past release before upgrading or even to wait until the upgrade thereafter was nearing release before doing the current upgrade (unless of course the new release included a needed critical feature or fix unavailable otherwise). And a production upgrade was never attempted before having done a thorough simulation. (Personally, I still follow this practice.) I don't mean to minimize the problems sometimes experienced with an upgrade, and I also realize that with personal systems there can be non-trivial issues that can make taking such precautions also difficult. But for some, waiting and/or long-term support is the best answer. Just my two cents . . . -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org