Download your favorite Linux distribution at LQ ISO.
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-12-2013, 05:20 PM   #1
Slackware Maintainer
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 890

Rep: Reputation: 1938Reputation: 1938Reputation: 1938Reputation: 1938Reputation: 1938Reputation: 1938Reputation: 1938Reputation: 1938Reputation: 1938Reputation: 1938Reputation: 1938
Backtracking to sanity

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.

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).

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.
Old 04-12-2013, 05:39 PM   #2
Didier Spaier
LQ Addict
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-{14.1,current} on a Lenovo Thinkpad W520
Posts: 5,233

Rep: Reputation: 1443Reputation: 1443Reputation: 1443Reputation: 1443Reputation: 1443Reputation: 1443Reputation: 1443Reputation: 1443Reputation: 1443Reputation: 1443
Hey Pat,

thanks for asking.

1) (Owning an old laptop) I don't feel a need for a kernel newer than 3.4, provided that you ship /testing/<newer kernel versions> as in 14.0 for those we will need it to support new hardware.
2) No opinion
3) No opinion
Old 04-12-2013, 05:46 PM   #3
Registered: Jun 2009
Location: Cascadia
Posts: 868

Rep: Reputation: 236Reputation: 236Reputation: 236
Originally Posted by volkerdi View Post
...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.
I'm sure there are many that would agree that this is one of the reasons we use Slackware: stable and mature is favored over churn it out before it's ready. Sounds good to me.
7 members found this post helpful.
Old 04-12-2013, 05:56 PM   #4
Senior Member
Registered: Oct 2008
Distribution: Slackware [64]-X.{0|1|2|37|-current} ::12<=X<=14, FreeBSD_10{.0|.1}
Posts: 2,556

Rep: Reputation: 1094Reputation: 1094Reputation: 1094Reputation: 1094Reputation: 1094Reputation: 1094Reputation: 1094Reputation: 1094
1) - I have run into this as I have multiple 6150 systems. I have never cared much about video performance in past but decided to learn all the nouveau/nvidia options with -current recently - extremely bad timing apparently! With open wounds I give a thumbs up to a return to stability!

2) - I have not encountered any problems so will defer to the wisdom of the BDFL.

3) Other than the Nvidia related problems I have no opinion.

Thanks for asking!
Old 04-12-2013, 06:02 PM   #5
Registered: May 2012
Location: Sebastopol, CA
Distribution: Slackware
Posts: 321
Blog Entries: 16

Rep: Reputation: 263Reputation: 263Reputation: 263
eyeofliberty took the words right out of my mouth. Your policy of "backtracking to sanity" is one of the distinguishing characteristics of Slackware, in my eyes, and one of the first things I mention to others when they ask me "why Slackware?". This, and having a small number of packages that all get tested together, are imo the cornerstone of Slackware's robustness.
Old 04-12-2013, 06:05 PM   #6
Registered: Apr 2006
Location: SE Texas
Distribution: Slack64-C ML
Posts: 897

Rep: Reputation: 83
There's already a popular fast & loose bleeding bloody edge distro out there that has disappointed me more than once (not naming it so as not to ruffle feathers).

I gota go with rock solid stable & current that Slackware is famous for. And let the bloody edge people worry about upstream.
2 members found this post helpful.
Old 04-12-2013, 06:09 PM   #7
Senior Member
Registered: Oct 2005
Distribution: Slackware 14.1
Posts: 3,482

Rep: Reputation: 536Reputation: 536Reputation: 536Reputation: 536Reputation: 536Reputation: 536
The general philosophy in free/libre software of "Damn the torpedoes and backwards compatibility --- full speed ahead!" has always been a proverbial Achilles' heel. I wish the pace would slow to some sort of sanity.

My primary desktop uses a 6150 nvidia chip set. I lack the time to perform serious testing with Current, but I'm already affected because I am stuck with the 304.x drivers with that machine. I'm only one person but the 6150 chip set is hardly old and that is what I'm up against already, let alone how the 304.x drivers interact with future kernels.

I've had no problems with 3.2.29 in Slackware 14 and the 304.64 drivers. I'm guessing based upon what I have read that I likely would have no problems with the 3.4 kernel. I'm just guessing, of course, because I'm haven't done any testing.

Regarding GCC 4.8.x, I've been down that road before. GCC 4.7 raised some commotion when initially released. I vote for long term stability over bleeding edge and to stay with 4.7.x.

I appreciate that folks buying new shiny hardware will be affected, but I'm guessing there are more Slackers keeping older hardware alive than those going shiny. Again, just guessing.

I like the idea of the next release being 14.1 rather than ground breaking 15.0.
Old 04-12-2013, 06:12 PM   #8
Senior Member
Registered: May 2008
Posts: 3,622

Rep: Reputation: 1105Reputation: 1105Reputation: 1105Reputation: 1105Reputation: 1105Reputation: 1105Reputation: 1105Reputation: 1105Reputation: 1105
For me, the 1.14.0 XServer, 3.8 kernel and nvidia 310.44 blob have been working together better than they have in a good while. Do what you feel you have to, but I'll be keeping a copy of the current versions for my own use as I'm loath to go back when it's all working this well.

if you do decide to revert them and you can spare the space, perhaps you could drop the current versions into testing/ to give folks the option?

I have no preference on gcc. Either is good for me.

Last edited by GazL; 04-12-2013 at 06:19 PM. Reason: spelling
5 members found this post helpful.
Old 04-12-2013, 06:13 PM   #9
LQ Newbie
Registered: Mar 2013
Location: Pacific NW USA
Distribution: moving to slackware
Posts: 1

Rep: Reputation: 0
After spending way too much of my life with Debian stable (not that it's a bad distro) and switching to slackware64-current a month or so ago, I was actually kind of relieved by the fact that things were breaking due to being too new rather than too old.

1 - Can't really say since the first thing I did after installing was upgrade from the 3.7.something that was in -current at the time to 3.8.4. The ATi drivers threw a temper tantrum at me I was able to patch a few of the files and now it's all hunky dory even on 3.8.6.

2 - No idea. I've compiled a few things for regular use (including the kernel) and have yet to run into any problems on 4.8.0 but if other people are having issues it might not be a bad idea to revert.

3 - This was yet another thing that made fglrx flip out, but after rolling back to 1.13 (Thanks Ponce!) it's all running smoothly.

Being a total noob to Slackware I may very well be speaking out of line, but aren't these the sort of things that one should be prepared for when using -current instead of a numbered release?
Old 04-12-2013, 06:23 PM   #10
Registered: May 2007
Posts: 370

Rep: Reputation: 111Reputation: 111
If you are shipping Mesa 9.1, there will be some people that will want the latest 3.8/3.9 kernel. I agree that 3.4 may be more stable choice in this release cycle, from what I see. So I think you'll want to keep the 3.8/3.9 config file as a choice in the next release, and ship the kernel that will work for most everyone.

I think the defining thing about the 13.x series was the stability it has. I think that 14.1 is a good idea too. I'm not in a hurry on GCC 4.8. I don't think the X server version is a big deal. Lets get lots of testing done
Old 04-12-2013, 06:31 PM   #11
Senior Member
Registered: Oct 2005
Distribution: Slackware 14.1
Posts: 3,482

Rep: Reputation: 536Reputation: 536Reputation: 536Reputation: 536Reputation: 536Reputation: 536
You have done this in the past: how about 3.4 for the release and 3.8 in /extra?
Old 04-12-2013, 06:45 PM   #12
Registered: Apr 2011
Location: Canada
Distribution: Slackware
Posts: 98

Rep: Reputation: 23
Sounds great to me. Keeping this close to the edge is always fun (that's why we run current!), but I wouldn't put linux 3.8, gcc 4.8 or xorg 1.14 on something like a server yet.
Old 04-12-2013, 07:22 PM   #13
Senior Member
Registered: Mar 2004
Location: Prince Rupert, B.C., Canada
Distribution: Slackware
Posts: 4,514

Rep: Reputation: 685Reputation: 685Reputation: 685Reputation: 685Reputation: 685Reputation: 685
The current kernel set-up and xorg is working very nicely for my old acer netbook, I had trouble with 3.7x. I'm okay with 3.4x (hoping it works).
Old 04-12-2013, 07:46 PM   #14
Registered: Aug 2006
Location: Greece
Distribution: Slackware.12.2
Posts: 96
Blog Entries: 2

Rep: Reputation: 6
I have no opinion on the particulars, but in my book any kind of system needs to be stable (and working) first before anything else.
So, yes, I vote for stability.
Old 04-12-2013, 08:25 PM   #15
Registered: Sep 2005
Location: Boynton Beach, FL
Distribution: Slackware
Posts: 801

Rep: Reputation: 247Reputation: 247Reputation: 247
There are plenty of places to get bleeding edge versions of Linux software. I agree with what's already been said. Stability is what makes Slackware such a unique and valuable distro.

I also suggest looking at KDE versions to choose the one that is stable and works with the X Server version being used. The KDE 4.9.5 version may be a good choice.

It is pretty much expected that "current" will sometimes have bugs and less stable versions, but there is no reason why "current" has to reflect every release version of every package. There is also no reason why a release candidate or release has to use versions close to "current". The most important thing is to get a stable combination of versions to release.
4 members found this post helpful.


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

All times are GMT -5. The time now is 05:38 AM.

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