Well... after my little adventure in leaving slackware for a couple of months and see how would it be with other distros for server usage, except slackware of course, it seemed that 2 (actually one linux) of everything I checked are seriously built for server usage:

-----------------
1)Debian
2)FreeBSD (ok, it is not "linux")

What disappointed me most, is Ubuntu Server edition. Whatever I did, it insisting changing the order of recognition of my 3 nics. And Only version 9.04 recognized a raid controller which is at least 3 years old.
Not to mention bad creation of iptables because of missing commands on routing and also lots of crashes upon restarts or shutdowns.

As of Debian 64, till now seems to work perfect with no problems. Since I got it working before a 64bit version of slackware came out, I will leave it that way, it's basic usage is for firewalling and routing...

Before Debian, I installed FreeBSD. I can say I was really impressed with the plethora of software,new technologies and hardware support. And of course its stability and performace. And a lot more.
But the problem here was the download speeds from different locations for each software. In almost half of them, I had speeds similar to dial up. And of course I could not search for better servers for each software and chang its configuration all the time. That was really bad, which meant: rejection. Maybe there were faster solutions on that, but didn't find anything.
------------------

Anyway, I have a second new server now, which will serve as a replacement of and old one file server and domain controller, running slackware 10. It is a very old server, which served me well. What ever I tried on this new one, no distro recognizes the raid controller, but guess what: FreeBSD and Slackware sees it and ready for partitioning on cd boot up!

Should I install slackware 64 --current? Is it stable enough at this stage? I will propably have one or two weeks for testing and then make the switch. I am thinking of installing it and update to the stable 13 version when it will be available.

It seems that slackware is the only distro (along with FreeBSD) in the world, that will recognize all the hardware parts of a server. Never had failures with slack!

What do you propose? Although slack seems the only solution now...

Wait until the stable release comes out. After all, it's a
server. And you don't need to reboot it, eh?

The reboots happen only on the beginning, where testing and some upgrades may happen. After put on usage, no reboots. For the moment, that new 2nd server is still without any os installed.

But I can't seem to find any distro to work well. Only Slackware. I may install it for checking, and wait until the 13 version.

Any advice on what to be careful on the 64 --current? Or anyone who faced problems on this version? I may have to put it on usage before the 13 release.

Using a --current for production use is not a safe choice. If you really want 64bit, then just wait a little, because RC 1 was released and we can expect final version soon. Patience usually means time gains.

OpenBSD is also a good choice as it's pretty solid and secure.

I agree that -current isn't considered "stable", but the funny thing is slackware's "testing" releases are usually more stable than other distro's "stable" release. I have -current64 running on my server at home, granted it's not in a enterprise setting it's still my mail and web server, and it runs great.

over all slackware64-current works fine
one huge problem is it dose not have a WORKING version of kde KDE4 is in such a bad state it is still pre alpha
and likes to do windows tricks like changing it's settengs to default at random locking up at random for some resion it has screwed it self so deep in to the system (I can't get the system to default to another window manager)I'm thinking about reinstalling to get rid of it

I recently went to Debian for my desktop because I wanted 64 bit support, as well as a flawless install of my ATI proprietary drivers. I tried compiling the kernel to support my 4 GB of ram, but had trouble with the ATI driver later. I've been using it for about 2 months, but am switching back to Slackware (and buying an NVIDIA card since ATI doesn't want to support newer kernels!).

The bad:
1) At first I liked aptitude, until I tried to upgrade a package with the testing repository. I wanted to upgrade libxine1 so I could play some newer dvds, but it complained about needing to upgrade 40+ libraries or so. Finally, I ended up upgrading X (which upgraded the libraries automatically) just for a newer version of libxine1. After trying to play a movie, it now crashes X and I can't downgrade because of the dependency mess.

2) the expert gui installer crashes unless you're connected to the network (seems to have some minor issues). Slackware's installer is fairly bulletproof.

3) lack of a sane build environment: you have to download tons of libxxx-devel packages just to be able to build packages, plus the gcc version they built the kernel with isn't in the package distribution list. I found this out after getting an error trying to install VMWare.

4) Easier to build a custom kernel in Slackware...you have to download a ton of packages to do this in Debian.

5) the mythtv package creates a user with a home directory in /var/lib with one file having the sticky bit set. Crazy, huh?

6) iceweasel (built on firefox, but not the same). give me firefox any day. you have to set user/agent to Firefox to get decent rendering of some web pages.

7) package maintainer for mplayer insists on no libdvdnav support, even though there are instructions on the website on how to build it. It might be recent support, but they could at least put it in the unstable repository. Don't get me wrong, I'm still glad that someone donates their time to maintain this package.

8) harder to fix broken packages if they don't build right. I had problems with msttcorefonts and it took me a while to find the package install scripts in /var/lib/dpkg... and point it to my local copy of the fonts.

9) related to 3 and 4: they take away a lot of the power from the user, so it's harder to do simple things like build your own packages, create a custom kernel, or use your own versions of software alongside the distribution's if you don't like the package maintainer's version.

10) not really a big deal, but I like the default console highlighting in Slackware. It's not a lot of work to do this in Debian, but it's the default in Slackware.

11) it is definitely true that if you learn how to do it in Slackware, you can do it anywhere. Everyone else seems to like creating their own proprietary ways of doing things. Wireless networking is a good example in Debian: you do everything in /etc/network/interfaces.


The good:
1) I can install proprietary ATI drivers with 3 commands. It'd be awesome if they had a slackbuild for this like they do for 12.1

2) very easy installation if you like the package maintainer's version of the package. the dependency resolution for installing packages can be very nice.

3) I like system V init scripts better than system III with everything packed into a few files.

4) If you stick with the stable repository, it is very stable. Slackware is very stable as well.

5) An initial KDE Debian install is fairly lightweight and boots up quickly...I only had to scrap knetworkmanager and kpowersave.

6) Debian has the root account enabled...I hate how Ubuntu has the whole sudo thing. Give me root access and don't make it a pain!

7) most of the time the standardized paths are followed: /usr is for static data, /etc is for configuration, /home is for users, etc.

I was talking to a guy at work, and he mentioned the Slackware build process sounds a lot like the ports system in BSD. I was going to try out BSD as well, but the hardware support isn't as good (TV capture cards especially).

Why do you spread your KDE rant around? You seem angry and wanting
to spew it all over others, just because you can't run Slack -current
with the new KDE4. Stick with Slackware-12.2, and you'll be okay.

If you knew anything about the OP's needs, you would have stayed
out of the discussion. It is not necessary to have X on a server,
and therefore, KDE would not be needed.