Help answer threads with 0 replies.
Go Back > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Slackware This Forum is for the discussion of Slackware Linux.


  Search this Thread
Old 04-18-2013, 10:47 PM   #76
Registered: Oct 2008
Distribution: Slackware [64]-X.{0|1|2|37|-current} ::12<=X<=14, FreeBSD_10{.0|.1|.2}
Posts: 4,664
Blog Entries: 6

Rep: Reputation: 2525Reputation: 2525Reputation: 2525Reputation: 2525Reputation: 2525Reputation: 2525Reputation: 2525Reputation: 2525Reputation: 2525Reputation: 2525Reputation: 2525

Originally Posted by y0g1 View Post
In my opinion, we should stay with most recent software version as possible when talking about slackware-current.
If there are bugs - they shoud be noticed upstream to software developers. Maybe they will fix them.
I disagree.

I would say stay with the most recent __stable__ versions as possible, but not try to become Slackware-fedora.

"Maybe they will fix them" is not good enough. Slackware is built for those who use it, not for testing the latest upstream thingies.
3 members found this post helpful.
Old 04-18-2013, 10:56 PM   #77
LQ Guru
Registered: Jul 2011
Location: California
Distribution: Slackware64-Current
Posts: 6,416
Blog Entries: 15

Rep: Reputation: 1988Reputation: 1988Reputation: 1988Reputation: 1988Reputation: 1988Reputation: 1988Reputation: 1988Reputation: 1988Reputation: 1988Reputation: 1988Reputation: 1988
Originally Posted by volkerdi View Post
Hey folks,

Given some of the problems we're experiencing lately living on the bleeding edge, I'm thinking that it makes sense to move -current to some slightly more sane versions on a few key packages. These are:

1) The kernel. I think it would be better to use a 3.4 (LTS) kernel. There's no telling when a kernel > 3.8 will be given long-term support, and there are some problems with 3.8 that could be avoided by moving to 3.4. Probably the most serious one is that the most common nVidia chipset on motherboards (6150SE) is not working with the newer kernels and the nouveau driver. Sure, lots of people will use the blob, but having a working out-of-the-box environment is important.
If 3.8 isn't supporting the 6150SE chipset then there's a good chance other chipsets aren't working wither. Keeping proper levels of driver support should be a critical factor and why the Kernel developers haven't seen this as a problem is unknown, but maybe it's being repaired, however if I were you Pat, I'd find out.

I use a GeForce Go 6150 in my laptop and a GeForce 6150SE/nForce 430 chipset is what's my my Server/Workstation. Yeah, a good solid kernel that works is what's needed. 3.8.x be damned, if it breaks stuff.

Better question, how does 3.9.x stack up?

2) GCC. It's looking as if gcc-4.8.0 isn't really the best choice yet (unless you happen to be using Go). There's been a new release in the 4.7 series (4.7.3). While 4.8.0 has mostly worked well, there's not really a pressing need to jump to it yet, and there are some reports of kernel bugs that happen only when the kernel is compiled with 4.8.0. It would probably be better to wait some time to allow those issues to be worked out before making the jump (perhaps in the next devel cycle).
Nothing I've seen uses past 4.7.x as of yet, however, you could offer 4.8.x as an alternative. I wonder if the bugs in 4.8.x you mentioned with the kernel have any relation to the GeForce 6150SE chipset and Nouveau driver support problems. Also, if it breaks the kernel, chances are it breaks other stuff too.

3) Xorg-server. There's been a 1.13.3 release. I've not tested it yet to see if the problem with randr mouse constraints has been patched, but I see that the only reason for the release was to make some randr releated change. So far 1.14.0 has worked well here, but then again I'm not using any proprietary drivers. It could be a while before the proprietary drivers are completely up to speed with the new server APIs (especially the AMD drivers... who knows how long that could take?)

I would appreciate hearing your thoughts on this idea. It's been a fun experiment to test these things earlier rather than later, but I'd rather be targeting the next release as 14.1 and a stable, evolutionary update to 14.0 rather than a 15.0 that's churned out before the components have really have a chance to mature upstream. There's enough of that happening elsewhere, and in my humble opinion it doesn't need to happen here.
As always testing things properly should be done first. It might be a good idea to do a temporary package update freeze in -Current to test Xorg-server 1.14.0 against the binary blobs through the community to ensure that all the current drivers that are supported via proprietary drivers work flawlessly. The biggest issue however will be the eventual support issues for legacy Nvidia chipsets like the GeForce Go 61x0 series now being pushed into legacy support and getting anything out of AMD is like pulling teeth to get them to fix xorg-server issues on time.

The newer Nvidia chipsets should work fairly well though, at least to my knowledge they should.

However, Patrick, remember this... The tomato must first grow and mature to a ripened state before it can be used in the pasta sauce, and that takes time, care, and some patience.

14.1 or 15.0 should not be rushed in any case, and Slackware's stability should never be sacrificed for any reason. Bleeding edge and unstable code be ye damned to Hell!

Last edited by ReaperX7; 04-18-2013 at 11:18 PM.
Old 04-19-2013, 12:10 AM   #78
LQ Newbie
Registered: Jan 2007
Distribution: Slackware
Posts: 22

Rep: Reputation: 3
Hi Pat. Having used Slackware off and on since 11.0 at least, I'll offer my thoughts.

1. I'm in agreement with you; LTS kernels are most ideal for extended use, and keeping a version with optimal hardware support, especially on common hardware, is important.

2. Given that GCC is such an important piece of any system, I'd agree with sticking to a version that's less bug free for the time being. Given you more or less build everything with this, even more so.

3. I would say stick with a reasonably new version that is ideally supported by the proprietary drivers. While I prefer open source in concept, the fact remains that proprietary ones often beat open source ones in performance for quite a while, and it's important to cater to that need to have the end system useful for gaming and other intensive work.

Thanks for asking for our thoughts, Slackware is one of the few distributions I can think of that takes the user's needs into account this much. I trust your judgement either way though.
Old 04-19-2013, 06:13 PM   #79
Slackware Maintainer
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 1,463

Original Poster
Rep: Reputation: 4235Reputation: 4235Reputation: 4235Reputation: 4235Reputation: 4235Reputation: 4235Reputation: 4235Reputation: 4235Reputation: 4235Reputation: 4235Reputation: 4235
Thanks for all the input! It was greatly appreciated and most helpful.

I decided to revert to xorg-server-1.13.4, but also put 1.14.1 in testing. Of the three things, this seemed like the one that was most likely to cause trouble for people. Plus, I have noticed no real benefit here to 1.14.x versus 1.13.x. It's more likely that recent drivers and kernels have helped X, not the new server.

Kept gcc-4.8.0, and have no plans to revert that. Other than one issue with the omitted target headers (patched), this has been a solid release. It's not gcc's fault if things are setting -Werror by default.

The kernel is still up in the air. I bumped to 3.8.8, but when that branch ends and the decision becomes 1) stick with it anyway 2) move to 3.9 and start testing all over again or 3) head to the safety of 3.4, then we'll have to consider what to do again. Of those three options, I'd tend to lead towards 1) or 3). I think we're asking for trouble trying to follow the latest (and not as well tested) kernels while attempting to head into a stable release. The issue with nVidia 6150 chipsets is still a problem and might be still be enough cause to switch over to 3.4. Either way, we'll at least have configs available in testing. I plan to update the 3.4 ones there in the near future.

I'm marking this thread as solved, but by all means feel free to continue to add your opinions.

Last edited by volkerdi; 04-19-2013 at 07:28 PM. Reason: typo
8 members found this post helpful.
Old 04-19-2013, 06:32 PM   #80
Senior Member
Registered: Jul 2004
Location: Jogja, Indonesia
Distribution: Slackware-Current
Posts: 3,790

Rep: Reputation: 1062Reputation: 1062Reputation: 1062Reputation: 1062Reputation: 1062Reputation: 1062Reputation: 1062Reputation: 1062
Wise decision indeed
Old 04-19-2013, 10:18 PM   #81
LQ Guru
Registered: Mar 2004
Location: Prince Rupert, B.C., Canada
Distribution: Slackware, OpenBSD
Posts: 5,356

Rep: Reputation: 1371Reputation: 1371Reputation: 1371Reputation: 1371Reputation: 1371Reputation: 1371Reputation: 1371Reputation: 1371Reputation: 1371Reputation: 1371
Thank you, Pat! Just finished upgrading my netbook to 3.8.8. All is well.
Old 04-20-2013, 01:12 AM   #82
Senior Member
Registered: Feb 2009
Posts: 1,548

Rep: Reputation: 635Reputation: 635Reputation: 635Reputation: 635Reputation: 635Reputation: 635
glad to read that gcc-4.8 is here to stay :-)
Old 04-20-2013, 04:16 AM   #83
Registered: Oct 2008
Distribution: Slackware [64]-X.{0|1|2|37|-current} ::12<=X<=14, FreeBSD_10{.0|.1|.2}
Posts: 4,664
Blog Entries: 6

Rep: Reputation: 2525Reputation: 2525Reputation: 2525Reputation: 2525Reputation: 2525Reputation: 2525Reputation: 2525Reputation: 2525Reputation: 2525Reputation: 2525Reputation: 2525
Thanks Pat!

I now have the Nvidia 304.88 driver running my 6150 chipset with the 3.8.8 kernel - a first for me, after much recent frustration! Reverting the X packages seemed to fix that!
Old 04-20-2013, 05:19 AM   #84
Registered: Mar 2012
Location: Italy
Distribution: Slackware+Debian
Posts: 321

Rep: Reputation: 81
huge 64bit 3.8.8 kernel is not working in hyper-v :/
(and not even generic)

Last edited by Celyr; 04-20-2013 at 05:22 AM.
Old 04-20-2013, 09:13 AM   #85
Senior Member
Registered: Feb 2007
Distribution: Slackware64-current with "True Multilib."
Posts: 3,887
Blog Entries: 1

Rep: Reputation: 1184Reputation: 1184Reputation: 1184Reputation: 1184Reputation: 1184Reputation: 1184Reputation: 1184Reputation: 1184Reputation: 1184
Upgraded to the 3.8.8 kernel and xorg 1.14.1, and all is well.

Last edited by cwizardone; 04-20-2013 at 11:27 AM. Reason: Typo
Old 04-20-2013, 09:40 AM   #86
Senior Member
Registered: May 2008
Posts: 4,678
Blog Entries: 12

Rep: Reputation: 2174Reputation: 2174Reputation: 2174Reputation: 2174Reputation: 2174Reputation: 2174Reputation: 2174Reputation: 2174Reputation: 2174Reputation: 2174Reputation: 2174
Thanks Pat. That seems like a sound choice that should manage to please everyone.
Old 04-20-2013, 11:10 AM   #87
Registered: Sep 2012
Posts: 189

Rep: Reputation: Disabled
I am going to throw my hat in the ring and lobby for option 1 stay with a 3.8.x kernel. There are lots of btrfs enhancements that did not show up until 3.6.
Old 04-21-2013, 07:18 AM   #88
Registered: Dec 2005
Location: Philippines
Distribution: Slackware
Posts: 685

Rep: Reputation: 214Reputation: 214Reputation: 214
I'm cool with this, just update all three of my installs. All is OK on the far eastern front.
Old 04-21-2013, 05:45 PM   #89
Registered: Jan 2006
Location: Missouri
Distribution: Slackware -current, Slackware64 -current, Slackware 12.2
Posts: 150

Rep: Reputation: 24
Originally Posted by volkerdi View Post
No problem here with the recently released VirtualBox 4.2.12 and gcc-4.8.0. There was an asm issue with the VirtualBox kernel modules and gcc-4.8.0-pre, but that patch went in before the final 4.8.0 was released. Might want to make sure you have the latest VirtualBox, try it, and report back.
For the record, I finally stopped being lazy and wrote a patch to bump the GCC requirement in the configure file, which let me finish compiling. Everything's running nicely here now (we'll see when I need those VMs again!)
Old 04-24-2013, 05:24 PM   #90
Registered: Apr 2013
Distribution: DistroWanderer
Posts: 379

Rep: Reputation: Disabled

Slackware -current is very stable on my Asus 1000he and my HP DV6-6135dx. That being said, I like the stability of the releases and the bleeding-edge-ness of current, Slackware is the only distro that offers both of these in my opinion.

Debian tries to, but stable is absolutely ancient and I've just had too many problems with testing and unstable.

Thanks for such an amazing distro Pat!

Slacker for life.


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
modversions.h and my sanity! stcinifeic Mandriva 1 05-28-2004 05:12 PM
samba sanity skywaterhulk Linux - Software 0 04-22-2004 08:13 PM
Question of sanity ch4s3r Linux - Newbie 3 02-29-2004 07:22 PM
I guess a simple backtracking problem spank Programming 15 08-27-2003 11:21 AM
in the name of a musicians sanity! leprechaun Linux - Newbie 3 02-17-2002 01:34 PM > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 02:20 PM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration