SlackwareThis Forum is for the discussion of Slackware Linux.
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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.
Distribution: Slint64-14.2beta2 on Lenovo Thinkpad W520
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
...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.
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.
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.
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.
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 07:19 PM.
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?
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
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.