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.

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.

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.

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.

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.

Do what you need to do to compete, Pat! Here's my opinion on it...

1) Good decision! Besides, it's easy to install a later kernel on Slackware. I'm stuck on 3.8 now, will probably be forced to 3.9 by the EOL tag, and hoping that the "follow the money" angle will kick in to "encourage" sane release management.

2) OK decision. I disagree on the kernel bugs part because I haven't hit a new one yet that I wouldn't have hit with 4.7.2. However, in my lame attempts to program in C, it seems like the new GCC libbacktrace feature needs more work, seeming to point to parts of a bad function that lead me away from the answer, not to it. The Clang Error Caret ^ it is not...but those GCC guys are pretty smart...they'll catch up...

Maybe a timetable for GCC 4.8.1/2/3 versus the timetable for Slackware 14.1/15 would be helpful.

3) My need for a newer X is driven solely by the work of Chris Wilson and the Intel Open Source Technology Center. Otherwise, I don't need a new xorg-server. The first really good editions (for me) of xf86-video-intel were tested against 1.13, so that's OK. No earlier, though.

This year of trying to follow the latest changes--pretending like it was 1999 and a two-week old kernel and six-month-old GCC wasn't new enough to compile the latest KDE--that has taken a slight toll on my sanity as a sysadmin. If you take your foot off the gas a little bit, I'll be the first to understand.

I'm just going to agree with Erik_FL. He put into words what I was thinking.

+1
Currently everything is working better with the "current" -current :) than it has in quite a while.

I found that everything works much better in kernel 3.8 than any previous release so I would be very disappointed if Pat decided to move down to 3.4.

I am okay with moving to 3.4 provided we have a config for 3.8 and/or 3.9. I must add I haven't seen any issues with 3.8 though.

For gcc, I am no programmer but I am running -current right now and compiled quite a bit of SBo packages and I don't see any issues. I don't see why we should move back to 4.7.x.

No opinion on the Xorg-server.

Thanks,

My x86_64 Slackware 14.0 system was freezing on my Ivy Bridge laptop with kernel 3.2.29 so I upgraded it to 3.8.4 and the freezing went away. So as long as Ivy Bridge graphics are working on a 3.4 kernel, then I'm okay with going back to that. As for the other bits, I say whatever Pat decides is fine with me. Stability over bleeding edge any day.

Well-said. As long as my Acer netbook successfully down-grades to 3.4 I am fine with the move. Slackware = stability. :)

1) I've asked Greg about what will be the next LTS kernel when 3.8 came out, because I was interested in the user namespaces additions (BTW, things still has to go in with 3.10.x), and he told me that he's already got a lot of work maintaining two stable branches (3.0.x and 3.4.x) so unless someone else step in (like Ben has done for 3.2.x) for what he knew at the time there was no plan for another LTS kernel yet;

2) I was starting to like the 4.8.0 errors spam :) , but I also read about Stuart's problems in the arm changelog, so I suppose consistence comes first;

3) 1.14.0 is still giving me some problems with nx and virt-manager with qemu hosts using spice, two things that I use a lot: I was planning to try x2go and I'm using a workaround for the spice thingie (spicec works), but I suppose upstream still needs some time to fix this.

So, no prob at all for the downgrades here, but as GazL said, should be nice to have the stuff in testing/ to keep playing with them (besides the problems above, the rest here seems to work pretty fine) :)

I share the experience reported by GazL and cwizardone.
On:
1) A stable release can remain on a server setup for a long time (heck, my server at work is still running 13.37), so it makes sense to have a LTS kernel as the base for a stable release. The option for a later kernel to support recent release hardware is highly desirable.
2) No informed opinion. My only comment is that a trusted compiler is preferred.
3) Upgrades of third party software packages may expect the new ABI.

I agree with him too.

This! I have a ThinkPad S430 and experienced a lot of freezing with the 3.2.29 kernel. I later upgraded to kernel 3.7.7 and it has been working really well so far. Even if I need to upgrade the kernel again with the next release it is not such a big deal. :)

Actually, disabling compositing almost fixed the problem in KDE (almost), but it was absolutely horrible in XFCE. I really don't know why...

I'm running three (two laptops and a desktop) machines on -current with no problems I'd rather not go back. If that is what happens, then so be it. I'll survive. Since it was mentioned (post 15), I would definitely not want to backtrack on KDE. Version 4.10.2 is working just fine on all three of my machines.

I don't see any issues - if someone needs a newer kernel than 3.4 they can build one.

I really like -current.Don't have any problems compiling kernel or any other package.My system feel more responsive under -current.

Hiya. Generally my observation is that -current works well with the machines I administer, which is not to say that they wouldn't with an older set of releases. Another general statement is that I do not necessarily see the correlation between "old" and "stable", and those who think there is are welcome to use Debian stable. It is, however, true that the existing experience with older releases makes it easier to choose the "highlights" if there are any.

Detailed response:

(1) I don't care about the shipped kernel as I always compile my own. I usually run pretty recent kernels, with improved cpu and i/o schedulers patched in.

Having said that I don't care, I don't want kernel headers that are too old.

(2) I'm undecided on GCC. Does 4.8.0 produce better code? If not, I see no reason for not going back.

(3) Particularly the intel drivers (from i915 kernel driver to xf86 modules and mesa) are a moving target that are continually fixed, even for older chipsets. The quarterly recommendation by intel usually contains the latest releases. Before I kicked out intel graphics on my main workstation I event went to the crazyness of building new xorg version just to get a grip on the rare crashes that always came at the wrong time. In closing I would advise to go with the latest releases for the graphics subsystem.

1) I agree. I have been using 3.4.x for a while and it is very stable. It is LTS and probably will be for a while.

2) I also agree. gcc-4.8 is the first release for the move to C++, it's performance has dropped and it may have bugs.

3) I don't use proprietary drivers, so I cannot comment.

Just do what thou wilt, as Crowley once said. As long as you yourself don't go insane, a cautious -current/14.1 would be much better than a borked 15.0. The rest of us can throw caution to the wind when we foolishly desire to.

At risk of being the odd one out, I'd rather opt waiting for another good long time for a super stable Slackware 15.0.

- I had compiled kernel 3.4.6 and 3.7.10 on my test install on this old trusted laptop with Intel i915 chipset and honestly I didn't see any drastic changes in performance except for a couple udevd errors at startup(must be my fault).
- Can't comment on the other two.

Regards.

I like the 3.8.4 kernel...
 

1.) I've been personally quite happy with the 3.8.4 kernel, and decided to use that snapshot of -current as a point of embarkation for deploying new machinery.

I expect a few chugholes here and there along the -current road, but hey, the Slackware suspension in my hotrods are pretty tough, and for situations where I don't want take out the blown 454 or 429 Cobra Jet I stick with the latest Slackware -stable release, moving forward with slackpkg for maintenance.

That, and I'm so content with deciding upon either using Slackware 14.0 for my own enterprise *LTS* Slackware installs or -current for that extra edge in the last few yards of the quarter mile, I would just as soon not concern myself when a 14.1 or 15.0 is due or ready anyway.

It's not like there's any pressing need for a release cycle for -stable to adhere to any schedules anyway.

I tend to lament backtracking a bit in similar fashion to what Chess has related above, and would hope at least that the 3.8.x and/or 3.9.x kernels are included in -current's /extra if we do rollback the kernel in -current.

I certainly do not share the sentiment of my (more able) contemporaries here when they mention "stability" as a hallmark of Slackware (inclusive) - I reserve that distinction for -stable, and not -current, choosing to run -current when I do knowing full well that I may have to do some rollbacks myself or wait to roll forward.

2.) This is where "stability" really makes the difference for me with Slackware, and I defer to the BDFL's wisdom on this point ;) I want (and do expect) my stuff to compile without a hitch.

I like, and prefer running later kernels, and expect that no matter what Patrick chooses as the default I'm going to run something a little more advanced - but if GCC 4.8 is going to sling about errors like a helicopter when I maintain my kernels then that's a potential dealbreaker for me.

3.) I'm in the same boat as Patrick on this one, with respect to running proprietary drivers, since I typically just don't usually use them, so I have to take into serious consideration Ponce's observations on this point and note that rolling back Xorg isn't going to change much for me nor is it likely to negatively impact anyone else on this point of stability.

So to sum things up from my perspective:

• Kernel - Generally speaking, I like taking advantage of and running the newer kernels. I don't install Linux on brand spankin' new workstation hardware anyway, opting instead for well supported laptops, mostly G5 or G6 Proliant servers, and VMs under ESXi 5.10b, Xen, and KVM - so I see no reason to roll back the kernel (why not put the 3.4 kernel in /extra?)
  
  
• GCC - This is a big deal - I want my kernels to compile w/o a hitch. If GCC 4.7 ensures I don't have to wonder about, or fret over this, then by all means let's roll back.
  
  
• Xorg-server - Most of my bare metal consists of Proliant servers, and most of them are running as hosts for VMware, Xen, or KVM anyway. I have no issues with the latest Xorg but would expect fewer issues for others with the 1.13.x series. On my workstations I do want to know that I can take advantage of the latest in DE offerings, like KDE, Xfce, and I'm liking the latest efforts by Chess and Willy in bringing Gnome back to Slackware once more... er.... Mate, rather ;)

Oh, there is one more point. In my offerings, I have only the latest stable versions of Slackware and Slackware64 available for customers, but also make available a Slackware64 -current iso for them to install. I've received zero complaints about the latest -current iso images I have available for customers at this time (the 2013Apr10-20h52-PDT release), and I must say that the 3.8.4 kernel and KDE 4.10.2 seem to be very a popular choice with folks at this time - more than usual for -current, actually).

Therefore, depending on what Pat decides, I may end up making two different versions of Slackware64-current available to my customers - the iso we have up now, and then moving forward with the ones that have earlier kernel and GCC versions.

If we rollback, maybe we can start w/GCC and then the other parts a couple of days later? I know that's a bit selfish, but it sure would be nice to snatch that version and make it available for my VPS customers.

Well anyway, that's my :twocents:

:hattip:

Kindest regards,

.

1) I use 3.8.*, hp laptop keys are back to work (no work with 3.3/3.6) but in "stable" better LTS for me
2) no opition, I have found no problems to compile various programs
3) No problem with nvidia or intel, I haven't amd/ati card. I prefer xorg 1.14

OK, I am getting along very well with insanity (my wife would say that is my normal state), so I have no intention of rolling back anything until I see problems with what I've got. So far, no problems.
Regards,
Bill

Stable should be the goal, Centos kind of follows this model of stable & older instead of bleeding edge as you put it. I like having the latest but at what cost? I'm running Slackware 14 release not -current, there are times I feel the need to try -current, so I have a box setup to do just that, but my laptop (production machine) runs the 14 release from September 28th 2012, kernel 3.2.29 - although I'm still tempted to install newer KDE : )

Having said all that, I'm grateful for your wisdom and willingness to ask the community, that takes courage IMHO.

Thank you for all you do, and to this community!

Do what you think is best for the stability. I'd rather have very stable 14.1 than not as stable 15.0. We're even with the possible roll-back pretty bleeding edge anyway.

Pat,
Thanks for all the work. Stability is much appreciated since I don't have as much time to "fiddle" as I used to. I really don't need for my main box to go all wiggy. When I can, I experiment in a VM, but even that is getting rare. So my 2 cents of feedback:

1. Agree. Stability is paramount.
2. See above. I only maintain a few SBo scripts, and rarely need to compile anything newer than the packages Slackware provides, and I do not have the time to track down odd compiler bugs. That's a game for the young!
3. Sadly, I have this wicked PC video game addiction: so the Nvidia blob is required. They've been usually good at updating for new Xorg releases but there is a lag. So if Nvidia blob doesn't work, then I get all twitchy.... I have various systems with older Intel, ATI, etc so those MUST work OOTB!

Speaking of older systems, I have a post on LQ about getting Slackware32-14.0 running on an old Compaq Armada E500. My game server (mumble, Firefox Sync, Minecraft, Urban Terror, sauerbraten...) is an old HPO/Compaq D530C dating back to 2000, I think. The boy just also brought up Slackware64+XBMC on an old Gateway E-4610S from about 2006 (thinking about cable TV cord cutting...). Except for the Geforce GT430 and VeiwSonic 24" LCD, 500GB HDs, my main desktop is not much newer!

Thanks to the community and to you especially for all the good work!

-Ed

I'll have to second that. My machine has been working so well with Slackware 14.0 that I haven't had the need to change anything at all, besides the security updates and a few SBo packages.

As others have stated, I defer to Mr. Volkerding wisdom in these matters. Praise Bob. :D

I agree with you entirely, Pat. However, I must say that -current is working exceptionally well for me, but I understand you have to look at the big picture. On the points:

1) I was happy to see you upgrade to 3.8.4, because it has built in drivers for my RealTek PCI card reader. I don't have to go building my own driver from RealTek's website. Also, sound works right out of the box (No having to use PulseAudio, thank God!) I downloaded the -current ISO image the day it came out, and burned it to DVD. Now, looks like it was a good decision. Even then, there were some rumblings about going back to the 3.4.x kernel series.

2) This point is well-made. gcc-4.8.0 does not compile some of my packages at all, whereas 4.7.2 has no problem with it at all. If you decide to go with 4.7.3, I'll upgrade to that (at least Eric's multilib version of it).

3) When I installed off of the -current DVD I burned and then tried to install the proprietary AMD drivers, KDE would not start. I tried several different ways to get around this, but I gave up after I realized the situation was not going to change. I regressed to the 1.13.x series, and have had no problem since.

I realize AMD is lethargic in its development of Linux drivers, but I happen to like this laptop (HP Pavilion dv7-7227cl), and plan on keeping it for a good long while. Hence the regression to 1.13.x.

1. I would be fine with kernel 3.4, after all we are Slackers and if one needs a newer kernel it shouldn't be a problem to just compile a new one.
2. Not enough knowledge to comment on this one.
3. I would appreciate the step back to 1.13, I am a gamer and (sadly, should have known better) owner of AMD video hardware. The step to the older version would mean that I can use the proprietary driver again.

+1

But, assuming it will be a .1 release, for sanity and to calm down BOFH sysadmins:

1 - 3.4 (LTS) kernel and 3.8.x > "/extra" (folks with new toys wanna have some fun),
2 - GCC 4.7.3 (With a good 4.7.x enthusiasts can build the 4.8 series),
3 - I gave a middle finger to proprietary AMD/ATI some time ago.

Current is working very nice here right now. No problems with GCC 4.8, no problems with Xorg. I'm using Kernel 3.8.7, but nowadays it is more curiosity than necessity (past problems with AMD/ATI, Atheros wireless,acer-wmi...).

Just a warning here on LQ with some directions and people using (and liking) Kernel 3.8.4 can keep it with little effort.

Whatever the decision, I'm on.

deleted.

I'm not sure. I think that use stable versions of {kernel gcc xorg} for stable release is good idea. For advanced users always is current tree,
but my video card ATI HD7750 working without troubles only with fresh kernel 3.8.
I compiled with gcc-4.8.0 all my packages(95 pieces) without problem(I'm patched only Inkscape and VirtualBox).

May be fresh software + updates, patches later?

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.