My first experience with Slackware Linux came with version 9.1, after 4 years of using various versions of Red Hat and SUSE Linux. I disliked the general direction these distributions were moving in and didn’t see their increasing focus on the “big end of town” as auguring well for either myself or clients of my small one-person IT consultancy business. I quickly became a Slackware convert and have since used it exclusively for all my server deployments. Check in for more and 15 screenshots from Slackware 10.
These are typically file and intranet servers on small to medium sized networks of up to 50 or so clients, typically providing additional services such as DNS and DHCP. Above all, I am impressed by Slackware’s stability, clean layout, easy customisation, and excellent package building and management system.
Slackware 10 has now arrived after much anticipation, and my initial assessment is that the latest offering is even more appropriate as a server platform than the previous one. Generally speaking, the overall layout and inbuilt Slackware tools have not changed much, which is a good thing, while the software selections represent a balanced mix of old and new. At the time of writing, all software was also fully up to date in security terms, which is always nice.
The installation process using the standard Slackware installer was a breeze, as it was with the previous version. I honestly believe that Slackware’s reputation for being difficult to install is not just undeserved but quite wrong, particularly in the case of servers being installed by system administrators who presumably have a basic level of Linux knowledge. Overall, the process is certainly no more demanding than any other mainstream distro that requires users to make choices about their installation.
The only caveat I’d place on this statement relates to creating a RAID array during installation. Slackware doesn’t provide a simple option for doing this, though it is still possible to create an array. The task requires the use of command-line tools such as fdisk and mkraid, and some hi-jinks with swap partitions and lilo configuration files, so a reasonable level of Linux skills are necessary.
Older packages that remain in the mix include things like lilo and inetd, which for some is evidence of Slackware being an “outdated” distribution. I am of the opinion that in situations where stability and reliability are paramount, the use of such packages has more advantages than disadvantages. In terms of functionality and security, lilo and inetd perform as well as any alternatives and if something “ain’t broke”, why fix it?. In any case, such packages are hardly critical: bootloaders are irrelevant once the system is running, and I normally never run anything that inetd manages anyway, apart from the occasional FTP server. Looking instead to what could be considered “core” server software, Slackware 10 is clearly one of the most up to date distributions currently available.
One of the most significant updates in Slackware 10 is the inclusion of the 2.6.7 kernel (in /testing on CD2). It appears to be quite reliable and is very easy to install alonside the default 2.4.26 kernel. Whichever kernel you opt for, you are sure to have the latest available stable version. The 2.6.7 kernel brings with it many improvements both big and small. These include the udev dynamic device management system which greatly reduces device clutter and makes it easy to locate devices, and new CD-ROM handling that no longer requires the ide-scsi module. Nevertheless, for production server installs I’d definitely recommend sticking with the 2.4.26 kernel in the interests of stability. In particular, Slackware developer Patrick Volkerding notes concerns over the safety of hard drive partitions under the current 2.6 kernel, and believes that overall system performance is still better under 2.4.
With increasing demand for the deployment of Samba on Linux as a file server and primary domain controller (PDC) for Windows NT domains, the inclusion of the latest stable version of Samba (3.0.4) is a big plus. It is now no longer necessary to install third party packages to replace the older 2.x version that shipped with Slackware 9.1. Samba 3 now allows a Linux box to completely emulate an NT domain server, with considerable inroads being made into Active Directory integration as well. In the server market, Samba is definitely a “killer application” that makes migration to Linux an attractive proposition for many small to medium sized organisations.
A welcome new addition is the mdadm RAID management package. While the older raidtools package remains entirely adequate for the task of building software RAID arrays, mdadm offers several additional functions that make managing and monitoring arrays much easier. Only raidtools is available during system installation, however, so this remains the tool to actually build an array at that point.
Another interesting new addition is dnsmasq, a lightweight caching DNS and DHCP server that simplifies the provision of these services on a small LAN. It is certainly much easier to configure than BIND and the INC DHCP server, but I’m yet to determine just how much functionality it actually delivers. On networks where Samba is functioning as a PDC, for example, dnsmasq would need to be able to provide Windows boxes with WINS server information if it were to replace the INC DHCP server.
Yet another new package is Sun’s Java 2 Software Development Kit Standard
Edition (J2SDK 1.4.2). Personally, I have never used Java-based software, but there are many interesting Java applications out there which may now be more easily deployed on Slackware. In particular, I’m thinking of several excellent XML related projects at apache.org such as Xerxes, Xalan and FOP, but that’s another story …
On the web server front, Slackware 10 has continued with the Apache 1.3 series (1.3.31). Again, the question of “outdatedness” versus stability can be debated, but in practice I have no problem with Apache 1.3 for the time being. While many features of Apache 2.x are definite improvements, most are not directly relevant to Apache as I use it, typically as a Linux-based intranet server on a small to medium sized LAN. In any case, quality third-party Apache 2.x packages for Slackware are available for those who need them. In terms of software commonly used in conjunction with Apache, Slackware again jumps to the leading edge with latest stable versions of PHP (4.3.7) and HtDig (3.1.6).
For anyone interested in installing X Windows, Slackware 10 is again about as good as it gets with both GNOME 2.6.1 and KDE 3.2.3 included. For those who use them, this is probably good news, but as I don’t normally install them I can’t really comment further in any useful way.
So, Slackware 10 includes lots of useful new packages, but what does it lack? If I could request just one additional package it would probably be postfix, as replacing sendmail with postfix is typically one of the first tasks I always undertake on a newly installed system. Postfix’s management and security benefits aside, it also integrates easily with amavis and clamav (for email virus scanning) and spamassasin (for spam filtering).
Other less commonly deployed network servers such as Squid and OpenLDAP would also be nice, but on the other hand I’d hate to see Slackware acquire the bloat of some other distributions, so something has to give I guess. Third-party packages for most software is readily available from sources such as www.linuxpackages.net, while Slackware’s inbuilt package system makes building and managing custom packages far easier than with any other Linux distribution I am aware of.
And now for the verdict. Slackware 10 is a well-rounded distribution that will continue to make a first-class Linux server platform. Changes in the new release are incremental, not radical, and Slackware remains one of the most stable, reliable and flexible distributions available today. True to tradition, Slackware 10 is refreshingly free of the convoluted and confusing “enhancements” often added by other Linux vendors that can make straightforward system administration tasks a real pain if you don’t use their GUI tools. If you build and manage Linux server systems, I certainly recommend trying a Slackware solution!
About the Author
Michael Hall is a freelance Linux consultant and web developer based in Alice Springs in Australia’s Northern Territory. When not hacking Linux in some way, he is either outside gardening organically under the blue Central Australian sky, making noise with his trumpet, eating or sleeping.
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.
Metacity theme:
http://www.osnews.com/story.php?news_id=3496
Path Finder:
Download and install the FOX Toolkit with AA support (read the ./configure script how to enable AA). It will install PathFinder as well as 2 more fox apps.
http://www.fox-toolkit.org
Is there a linux distro out right now that supports major wireless cards right out of the bag, without having to hack the windows drivers myself?
Lindows does apparently.
“I’m talking about every distribution I’ve used with an automatic dependency resolver — RedHat, Fedora, Gentoo, Debian — sooner or later breaking my system, i.e., itself, by screwing something up.”
Also rubbish. Any solid package management utility with solid packages should work well with precompiled binaries. I know this is very true for Debian GNU/Linux Stable and Testing. The point is that instead of doing the stuff yourself, you outsource it to people who know what they’re doing. In the case they do / did not know / knew what they’re doing, you can download the source package and compile that yourself. Much more convenient than doing it yourself by default which costs time. Loads of time. Heck, even the BSD’s agree with me on that given they want to improve their Ports collection and provide binaries for it by default.
Because of this, the only reason i see why one would prefer to compile his/her own binaries is because of optimalisations (not very better performance if not less) or paranoia (which boils down to the fact you’l need to use binaries to compile from source) or when its broken (see above)
PS: there’s another Slackware article on ofb.biz
I think you missed the point here. Using Slackware does not in any way preclude the possibility of downloading and installing convenient precompiled binaries, it comes with its own excellent package management system for just that purpose. Suggesting that all software must be compiled from source on Slackware just isn’t correct … though if you DO choose to do so, making a package while you’re at it is a breeze.
I have found almost all software I ever needed (stuff not in the original Slackware distro) packaged up and ready to go in good quality Slackware TGZ packages at http://www.linuxpackages.net.
The issue is the dependency hell that other packet managers frequently get users into, and which Slackware totally avoids.