SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
If -current(64) goes back to 3.4 then will the dreaded samsung-laptop bricking problem be an issue again? Fixes for that (such as they were) were introduced late in the 3.7 series I believe.
Fixes for that must come from Samsung. The bricking issue is present in Window$ too.
Indeed, Samsung is the culprit, the problem was their fault. Nonetheless I believe workarounds of some kind designed to dramatically reduce the chance of the bricking were introduced into the kernel at 3.7.6 apparently:
Quote:
Originally Posted by volkerdi
The fixes went in with version 3.7.6, however the bug in the firmware remains. It's probably safe, but there are no guarantees.
So the possibility remains, but the risk is of a different order of magnitude with the fixes in, as I understand it.
Indeed, Samsung is the culprit, the problem was their fault. Nonetheless I believe workarounds of some kind designed to dramatically reduce the chance of the bricking were introduced into the kernel at 3.7.6 apparently:
The same fixes also went into the 3.2 and 3.4 series at that time.
Is it too early to put my vote in for 3.10, assuming it's stable enough to be worth included in /testing by Slackware's release time? (Like probably everyone else, I'm eyeing b/dmcache.)
i do agree with Linux Kernel 3.8.x for now
i'm using VMWare here and i think it's broken if we used a combination of Linux Kernel 3.9 and GCC 4.8 to rebuild the modules
it worked with Linux Kernel 3.9 and GCC 4.7 or Linux Kernel 3.8 and GCC 4.8
Could you share how you get VMWare to work on Slackware?
I never had to put that line on rc.local here and vwmare should works fine
I've had to use "/etc/init.d/vmware-USBArbitrator" before in order to get USB working. I don't know why under certain situations that has to be done though.
Stable kernel is vulnerable to root exploit CVE-2013-2094 (3.2.29, CONFIG_PERF_EVENTS=y).
What should we do ? Upgrade to current ? Wait for Slack patch ?
Stable kernel is vulnerable to root exploit CVE-2013-2094 (3.2.29, CONFIG_PERF_EVENTS=y).
What should we do ? Upgrade to current ? Wait for Slack patch ?
Thank you
You can probably patch that yourself if you are comfortable in building your own kernel.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
