LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 04-18-2013, 11:47 PM   #76
astrogeek
Senior Member
 
Registered: Oct 2008
Distribution: Slackware [64]X{.0|.1|.2|-current} ::X>=12<=14, FreeBSD_10{.0|.1}
Posts: 2,144

Rep: Reputation: 846Reputation: 846Reputation: 846Reputation: 846Reputation: 846Reputation: 846Reputation: 846

Quote:
Originally Posted by y0g1 View Post
Hello,
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, 11:56 PM   #77
ReaperX7
Senior Member
 
Registered: Jul 2011
Location: California
Distribution: LFS-7.6, Slackware 14.1, FreeBSD 10.1
Posts: 3,822
Blog Entries: 15

Rep: Reputation: 1181Reputation: 1181Reputation: 1181Reputation: 1181Reputation: 1181Reputation: 1181Reputation: 1181Reputation: 1181Reputation: 1181
Quote:
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?

Quote:
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.

Quote:
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-19-2013 at 12:18 AM.
 
Old 04-19-2013, 01:10 AM   #78
s3phir0th115
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, 07:13 PM   #79
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 876

Original Poster
Rep: Reputation: 1825Reputation: 1825Reputation: 1825Reputation: 1825Reputation: 1825Reputation: 1825Reputation: 1825Reputation: 1825Reputation: 1825Reputation: 1825Reputation: 1825
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 08:28 PM. Reason: typo
 
8 members found this post helpful.
Old 04-19-2013, 07:32 PM   #80
willysr
Senior Member
 
Registered: Jul 2004
Location: Jogja, Indonesia
Distribution: Slackware-Current
Posts: 2,617

Rep: Reputation: 444Reputation: 444Reputation: 444Reputation: 444Reputation: 444
Wise decision indeed
 
Old 04-19-2013, 11:18 PM   #81
hitest
Senior Member
 
Registered: Mar 2004
Location: Prince Rupert, B.C., Canada
Distribution: Slackware, OpenBSD
Posts: 4,273

Rep: Reputation: 586Reputation: 586Reputation: 586Reputation: 586Reputation: 586Reputation: 586
Thank you, Pat! Just finished upgrading my netbook to 3.8.8. All is well.
 
Old 04-20-2013, 02:12 AM   #82
a4z
Member
 
Registered: Feb 2009
Posts: 526

Rep: Reputation: 188Reputation: 188
glad to read that gcc-4.8 is here to stay :-)
 
Old 04-20-2013, 05:16 AM   #83
astrogeek
Senior Member
 
Registered: Oct 2008
Distribution: Slackware [64]X{.0|.1|.2|-current} ::X>=12<=14, FreeBSD_10{.0|.1}
Posts: 2,144

Rep: Reputation: 846Reputation: 846Reputation: 846Reputation: 846Reputation: 846Reputation: 846Reputation: 846
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, 06:19 AM   #84
Celyr
Member
 
Registered: Mar 2012
Location: Italy
Distribution: Slackware+Debian
Posts: 314

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

Last edited by Celyr; 04-20-2013 at 06:22 AM.
 
Old 04-20-2013, 10:13 AM   #85
cwizardone
Senior Member
 
Registered: Feb 2007
Distribution: Slackware64-current & "True Multilib." PC-BSD.
Posts: 2,269

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

Last edited by cwizardone; 04-20-2013 at 12:27 PM. Reason: Typo
 
Old 04-20-2013, 10:40 AM   #86
GazL
Senior Member
 
Registered: May 2008
Posts: 3,502

Rep: Reputation: 1024Reputation: 1024Reputation: 1024Reputation: 1024Reputation: 1024Reputation: 1024Reputation: 1024Reputation: 1024
Thanks Pat. That seems like a sound choice that should manage to please everyone.
 
Old 04-20-2013, 12:10 PM   #87
chemfire
Member
 
Registered: Sep 2012
Posts: 81

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, 08:18 AM   #88
chrisretusn
Member
 
Registered: Dec 2005
Location: Philippines
Distribution: Slackware
Posts: 508

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

Rep: Reputation: 15
Quote:
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, 06:24 PM   #90
ryanpcmcquen
Member
 
Registered: Apr 2013
Distribution: Slackware
Posts: 74

Rep: Reputation: Disabled
Wink

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.
https://lqo-thequestionsnetw.netdna-..._lq/icon12.gif
 
  


Reply


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 06:12 PM
samba sanity skywaterhulk Linux - Software 0 04-22-2004 09:13 PM
Question of sanity ch4s3r Linux - Newbie 3 02-29-2004 08:22 PM
I guess a simple backtracking problem spank Programming 15 08-27-2003 12:21 PM
in the name of a musicians sanity! leprechaun Linux - Newbie 3 02-17-2002 02:34 PM


All times are GMT -5. The time now is 10:02 AM.

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