1. Agree.
2. Agree.
3. Agree.

Stable 14.1 > "unstable" 1.50.

I would though like if some of new shinys could be found in extra/

Hey, glad I don't need to type this whole thing myself. Seconded.

+1

I'm not a gamer but recently started this TF2 malarky...

I'm getting a bit confused here. I run -current and understand that its effectively a beta test for the next release. If this is true then there's no real option but than to go back to whatever the next stable release will look like. I guess this would be 14.1 in the making.

I would be disappointed to go back as I have new machines that appear to be better supported by newer kernels. Optimus for example. However, I have to admit that I don't really know if moving back to 3.4 (LTS) is going to change much for me because I haven't got a clue what the difference is and I suspect that there may be a few like me who are in the same position. I use -current because I find it fun but I do have a sever that I haven't upgraded for a while because I'm concerned that I'll break it, which sounds like I would benefit from a more stable release.

Working through this - is there a possibility of having a -stable, -testing and -current release or is this just too much work?

You could rename then -stable, -sane and -insane ;)

just a thought.

Given my propensity for adhering (as strictly as possible) to Doug McIlroy's philosophy for anything I write, and my belief that Slackware appears to do the same (and that's why I've been sticking with Slackware since, oh, I don't really remember but it did come on CD-ROM's and it was in the early 1990's sometime), I hope that the opinions offered here don't tread too heavily on anybody's toes... but here goes anyway for what it's worth.

1. A lot of the problems I see in the Slackware forum at LinuxQuestions.org (LQ) seem to be with proprietary video drivers. Just seems to be a lot of 'em. I purposely do not order machines that have those cards -- gimme the stock Intel graphics and I'm a happy camper, don't play games, don't give a hoot about fancy-schmancy 3-D video or any of the rest of that stuff. Obviously, it's important that AMD, nVidia and who-know-what-else are supported and it's important that the kernel incorporate support; but, the 3.4 kernel seems to be stable and the 3.8 kernel is a little (well, maybe more than a little) glitchy, so, leave well enough alone for now? Don't know how else to say that.
2. For the life of me I cannot understand why folks have to screw with software until they break it -- especially a compiler. Sheesh. GNU's fiddling and twiddling just looks to me like somebody needs to get a real job and I'm sorely tempted to buy the Intel compiler and see how that will work (from what I hear here and there seems to be pretty solid). I have nothing whatsoever against improvements in technology, faster, better, easier is a good thing -- but I do wait for technology to settle down before I jump in (lessons learned during a wasted youth, mostly). The first Unix system I owned ran on a Motorola 68K processor with 1M (yes, MEG) of RAM and a 50M (ditto) disk drive; we've come a long way, baby. Full-blown System 3. Thing still works (and I can heat a couple of rooms with it). It just seems like we get further away from the Standard Library -- adding extensions is a horror that will always come back and byte you in the butt -- we start stumbling over our own feet. I will always -- always! -- vote for stable and reliable.
3. Xorg-server? Like you, I'm not using any proprietary drivers; I had to go look up RandR at Wikipedia: "The X Resize, Rotate and Reflect Extension (RandR)[2] is an X Window System extension, which allows clients to dynamically change X screens, so as to resize, rotate and reflect the root window of a screen." Oh.

I've been doing this for... well, too damn long. Starting in 1961 with IBM punch-card stuff, on and off through Honeywell mainframes, Z-80 microcomputers running Digital Research and Cromemco DOS, System 3, System V, Sun Solaris and, finally, Slackware. There were a couple of Microsoft things in there (couldn't help it, got paid to do it), taught a Unix course, got Slackware somewhere in there and haven't looked back (or gone astray for very long, either). My data base servers sit in a closet mumbling to themselves for months (the record is a 12.1 box that ran for 13 months before the power went off one day); I keep everything up-to-date with patches and stuff just works. Those data base servers, Dell Dimension 8400's, came with Radeon cards (royal pain in the ass, long since disabled), run headless via ssh, one runs MySQL the other runs PostgreSQL and they just keep, you know, doing their respective thing and not bothering me.

Slackware works. Slackware is stable and reliable. I vote for that and let the hairy edge wait a while.

Hope this helps some.

1. If 3.9 is released soon enough and is tagged LTS, include it, else include 3.4. But in the latter case, maybe propose in /patches the next LTS kernel when it will be released, possibly in addition to configs files in /testing?

I would rather like to see the next LTS kernel in /extra instead of patches, putting in in /patches would mean that it is an official kernel update, which usually does not happen Slackware (and shouldn't happen in a "stable" 14.1 release).

I'm just an inspired amateur who runs -current on a bunch of old laptops for the kids in my class. Surprisingly huge-3.8.4 has run flawlessly on Compaq N600C's, Dell D600's, Dell C840's, IBM R51's and huge-smp3.8.4 has been a hit on Dell D610's and a Compaq V5000 so I haven't had any issues in that respect, but this is your toy, so if you want to rollback to 3.4, then so be it.

Thanks for all your work, Pat.

I disagree as IIRC /extra's content is "frozen" in a -stable release.

And I already see some upgrades in the Stable ChangeLog for my architecture: tagged "Upgraded", but not (*Security Fix*) and with no explicit indication of a bug correction.

Only caveat would be for people blindly running "slackpkg update && slackpkg upgrade-all", but we are supposed to look at the ChangeLog before upgrading, and kernel upgrades with slackpkg can be blacklisted.

Only MHO, of course ;)

You will probably find that you can't use the Intel compiler. Some of the "fiddling and twiddling" is to add extensions to the ANSI C language. Source for some Linux software requires those extensions to the C language. Hopefully Linus has resisted the temptation to use non-ANSI language extensions in the kernel and discouraged that for other people doing kernel development.

One that has bitten me a few times is the "?" operator. Syntax like this is not ANSI C compatible.

The GNU compiler accepts the above syntax and it is equivalent to this in ANSI C.

I am always leery of language extensions designed to save typing. They generally give up error detection in favor of convenience. What if the programmer just forgot to type in the variable name that they really wanted to use and didn't want "y"?

I also notice that a lot of C programs are really C++ in disguise. The programs are intended to be C but will only compile using C++ because they have C++ syntax in some places. Compiler developers should resist the urge to "fix" C compilers to allow using C++ syntax.

Two things:

• There are still many nice improvements in what is being lined up as 14.1. Many could benefit from these now, rather than waiting for 15 at some significantly later date.
• New releases are a revenue stream for our BDFL, so waiting too long could punish him financially.

As long as the quality is good (and you can see by his thought process that this is exactly what he intends), I see no problem with having smaller but more frequent updates, like the proposed 14.1. So yeah, I am in favour of making the proposed changes.

Besides, a solid Slackware 14.1 Post-Apocalypse Edition would do much to reassure those of us who still remain undecided as to whether the Mayans were indeed right! It would be a clear sign of continuity and stability as the new cycle begins, whereas waiting for a later 15.0 release might cause some to lose their faith!

It's not even released yet. I'm not sure when the next version of Slackware is due to be released, but there may not be enough time and testing. 3.4 has had much more testing and is a better choice. Users can compile newer kernels if they feel they need them.

Agreed. I am very much in favour of the improvements as laid out by PV. Slackware is legendary for being a robust, secure, and stable distribution. I am looking forward to Slackware 14.1! If you have not done so I encourage you to consider signing up for a Slackware subscription. A subscription is a way to support PV and ensure that Slackware continues its tradition of excellence. :)