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.

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

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.

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!

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.

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.

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.

5 members found this post helpful.

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

You have done this in the past: how about 3.4 for the release and 3.8 in /extra?

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.

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

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.

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.