Patrick J. Volkerding announced the first release candidate of Slackware 12 in the current changelog. This will be the first Slackware release with a kernel from the 2.6 tree (2.6.21.5) as default. "It's that time again, and here we have Slackware 12.0 release candidate 1! If we're lucky, we got it all right the first time. Big thanks to the crew."

There are lots of new things in Slackware -current. Pat has added HAL, KDE is built with HAL support, OpenVPN, gamin, bluez, apache2, and the list goes on and on. You can read about how to update to -current, as well as list of all the new packages, in the "Changes and Hints" text file on the mirrors. Here's a link to one:

I have just installed Slackware 12 on my 1.6 GHz Pentium IV system with 512 Mb SDRAM and legacy PCI nVIDIA Geforce4 440 video card ( legacy driver NVIDIA-Linux-x86-1.0-9639-pkg1.run ) and , O,my God, it's blazing fast.
I manage to download and burn DVD iso image from this FTP server and it took little less than 6 hours
(NOTE: it's unofficial DVD built approx. 3.7 GB in size): ftp://ftp.slackware.no/pub/linux/ISO-images/slackware/Current-ISO-...
This is my Slackware 12 uname -a output:
Linux slack12 2.6.21.3-smp #2 SMP Thu May 24 21:09:15 CDT 2007 i686 pentium4 i386 GNU/Linux
and believe it or not, once KDE is loaded it uses only
75 Mb memory.
I knew this is going to be a great KDE 3.5.7 ( there's also XFCE 4) distro since I'm already running excellent Vector Linux 5.8 and beautifull Zenwalk 4.6.1 both based on "big daddy" Slackware simply because I can enjoy all rich multimedia even on my Pentium II based machines thanks to rock solid and reliable packages.
I'll certainly keep toying with this RC1 release and
also help reporting about(hopefully not to many) bugs in case I came accross one.
Great work Patrick; I'm on your side.

I have alwas loved this distro. Most will patch the hell out of the latest binaries to get everything working, creating what often ends up being a house of cards. The slack philosophy is that if it needs to be patched to work right, it isnt ready for use. Using vanilla binaries accross the board, and living by KISS principals, slack offers a fantastically simple, solid distro with a remarkable lack of distro specific bugs.

This is the distro I learned Linux on, and is still the one I reach for any time I need to configure a standalone server.

"I have alwas loved this distro. [...] This is the distro I learned Linux on, and is still the one I reach for any time I need to configure a standalone server."

Same here, too. Slackware + LaTeX let me enter the world of academia in 1996, more than 10 years ago, with POWER!-CD LINUX in a magazine for 29,95 DM - well invested money that saved much time for me. Furthermore, with the basic stuff that I could do with Slackware without any problem, I could learn very much about how Linux systems work and what you can do if they don't work the way you expected. Using this knowledge, it was no problem to adopt to UNIX systems which I'm using today on a daily basis (BSD, Solaris, IRIX).

In my opinion, Slackware is not for KISS enthusiasts only, it's a great system for educational purposes, too.

Of course it does! Slackware packages are just tar(-1.13) files compressed with gzip. Whereas RPM obscures the creation of packages through the lack of transparent build scripts, Slackware just uses shell scripts to create packages.

Slackware has pkgtools to manage packages. There is no inherent dependency resolution, which could be seen as both a good and a bad thing. In this respect it adheres very much to the Unix philosophy to keep it simple.

In contrast with RPM and DEB which do dependency resolution in the basic package managers themselves (rpm and dpkg) the basic pkgtools only supply mechanism and no policy.

So you can install, remove and upgrade any package you want without the tools keeping you from hosing the system. This is really the best way to do it, especially for experienced users that don't want to fight the package manager.

The dependency resolution is left to third party tools such as slapt-get, slackpkg and others, which do a lot but not all of what RPM tools such as yum and DEB tools such as apt-get are supposed to do.

I'd prefer KDE in /usr, given that its packages are split up into the usual bin, share, lib subdirs. I prefer /opt for big apps or games that don't fit the usual UNIX mould (particular if they're ports of Windows programs which stick everything into one directory, libs, exes, etc.).

"I prefered kde in /opt. It was easy to upgrade that way.
Now everything gets jammed into /usr like on Windows into system32."

In BSD land, there's a strict recommendation where to put which files. While the basic OS resides in the /etc and /usr subdirs, everything that does not belong to the OS itself is located in /usr/local. Today as /usr/X11R6 is to be obsoleted, this subdir is holding everything except the OS, while it supports the basic separation that you know from the directory structures above, such as /usr/local/bin, /usr/local/include or /usr/local/lib. To delete everything except the OS (for example, if you want to reinstall all your additional applications), just delete /usr/local - your OS won't be affected in any concern.

Example: The inetd system service has its control script as /etc/rc.d/inetd { start | stop | status }, its config file as /etc/inetd.conf, and its binary in /usr/sbin/inetd. The additional DHCP server service (that does not belong to the OS) has /usr/local/etc/dhcpd.conf, /usr/local/etc/rc.d/dhcpd.sh and /usr/local/sbin/dhcpd.

Similar do the doc/ or examples/ subdirs work - /usr/share/examples or /usr/local/share/examples.

I may say that the directory structuring of Linux OS is a bit untidy sometimes, while I personally like Slackware because you tend to find everything you're searching for in a relatively obvious position.

As it has been said by someone else before, /opt (or /usr/local/opt) would be a good place to store installed applications that do not match the bin/, lib/, include/ etc. separation, so all of them get a /usr/local/opt/APPNAME dir, and maybe a symlink of the executable to /usr/local/bin because it's contained in $PATH, so you don't need to call the executable by absolute name.

If course, you're free to install apps on a per-user basis, $HOME/bin, $HOME/lib etc. are used if --prefix is set to your ~ dir.

Yes, Slackware is still using lilo and there is still the same easy-to-install grub package in the /extras directory, which has been there for a long time. The nice thing about the grub package in /extras is that it includes a "grubconfig" tool just like the "liloconfig" tool that is included by default. So, switching to grub is as easy as uninstalling the lilo package, installing the grub package, and running grubconfig. Piece of cake.

Last time I checked Grub didn't support a lot of filesystems, like XFS, so if you wanted to use one of those you had to install Lilo.
Debian 4 is same way, it'll install Grub for you by default, but if you choose XFS as your main file system then it'll install Lilo.

Last time I checked Grub didn't support a lot of filesystems, like XFS, so if you wanted to use one of those you had to install Lilo. Debian 4 is same way, it'll install Grub for you by default, but if you choose XFS as your main file system then it'll install Lilo.

I have been using both GRUB and XFS for years so it should really not be a problem. The trick is to make a separate (/boot) ext3 partition where GRUB resides. GRUB can't coexist with XFS on the same partition so you shouldn't even try.

As a matter of fact the way I install GRUB on a partition of itself it's a completely separate entity from the installed operating system(s) and it isn't mounted anywhere in any of them by default.
So I never install GRUB or LILO when installing Slackware. I don't even bother with CD/DVD installs anymore, just installing from the hard disk, which is both faster and less error-prone.

Also I hardly ever upgrade the bootloader unless there is a major advantage to doing so and just update menu.lst to point to the newer kernel on the Slackware partition, which is usually just a version number change.

Of course it helps that I have created and installed self-contained rescue images (30-90 MB) that can be run from this separate boot partition in case I misconfigure GRUB. And modern firmwares such as PMON and OpenFirmware, which combine the functionality of the BIOS and GRUB, let you directly boot kernels anyway on non-x86 architectures.

I downloaded -current last night and installed this morning. Pat has done an awesome job as usual. Now that Slackware has the new XFCE4 and a 2.6 kernel by default, I may just switch some of my non-test machines over to Slack.

Or you can just compile your own Gnome. This should be a bit easier on Slackware than on some tightly integrated distro. I remember the time when I compiled Gnome 1.x from source (sources downloaded using dial-up line of course)! But then again, I have returned back to FVWM...

There is supposed to be some kind of automatic build system (two, in fact) for Gnome (Gargnome and jhbuild) that should automate the dependency check/download/build process. However, when I tried jhbuild on RHEL4 based Scientific Linux it just didn't work... (as expected)

Slackware had always been a rock-solid distribution and I thank the project for making me learn more about Unix/Linux than anything else when I started using it in the mid-90's.

The problem I have now is that some of the projects I'd like to employ (Samba/LDAP, 802.1x for WiFi Authentication) do require, in some funny way, PAM to be available.

I understand Patrick's reasoning behind not including it - but that reasoning is now dated since all major distributions, including Gentoo, are using PAM - as do the BSD's, and the security ramifications are mostly to do with how other projects integrate with PAM, not the PAM implementation itself.

With all due respect to Patrick and the project, I think PAM is long overdue to be part of Slackware so it can begin to make itself more useful again as an extremely robust distribution with easy integration.

I may be wrong with my line of thinking, but the lack of PAM prevents me from deploying my favorite distribution of all-time to be used with all of my servers.

Right now, I have a mixture of FreeBSD, OpenSuSE and Slackware, but the Slack servers are doing menial tasks.

If you want Slack with PAM, I believe the simplest way to get it is to install Dropline Gnome. Patrick has said (I think it was the Linux Link Tech Show podcast where I heard this) that that is enough of a change to make Dropline/Slack a fork in his view; so proceed at your own risk without the blessing of the BDFL I suppose. I use Freerock myself for the Gnome apps, though I still use KDE for the desktop. Of course, I don't need LDAP and all that heavy-lifting server stuff.