Installation & Fist Steps
Both distros feature text-based installation that are quite equivalent in terms of features and ease of use. However, I will give Slackware a slight preference here because of all the networking/package installation that's done by the installer, while Arch requires the user to use a text editor to edit the /etc/rc.conf to its liking, as this requires some extra knowledge.
Winner: Slackware (by a slim margin)
Configuration & Usage
While the installation of Arch by editing rc.conf might baffle some, the same rc.conf makes the system configuration of Arch a breeze, after you finally get it installed. Having a single central point where you can edit daemons, modules, networking, hostname etc, it's just convenient and easy to remember. Adding/removing daemons especially, is really easy, much easier than in Slackware, (the Slack book has... forgotten to mention those).
Slackware comes with better defaults though. /dev/dvd nodes (when applicable) and Alsa sound restoration, gstreamer's plugin registration, right permissions for /proc/acpi/event (for laptop users) etc, all happen automatically, while with Arch you need to go tweak those yourself. It's convenience that makes Arch lose points here. For the sake of calling itself a "distro for advanced users", it's missing some no-brainer conveniences that should have been there by default.
Another problem with Arch is the fact that Gnome, KDE and especially Mozilla are installed in /opt/. I had a fair share of applications that just couldn't find the Mozilla SDK to compile against in /opt, even if the /etc/profile.d/ was updated. Monodevelop, Blam! was some of them. I believe that not having to dump everything on /usr is a good thing, however the Arch implementation doesn't always work as expected. Instead of basically replicating /usr on /opt/, some innovation would be welcome, just like Apple does with its /Applications folder.
Despite all this, Arch wins this configuration and usage category shootout, because despite some of its initial troubles, after you get it up and running, it is much, much easier to change and configure things in it than it is with Slackware. In my experience with both, messing around with things on /etc/ for configuration, it's just easier to get by with Arch than with Slackware overall.
Slackware's original package management system doesn't support dependencies, but the great thing is that within the Slackware community, you don't really need the feature. Just like with the Windows or Mac or Be developers, the Slack third party packagers make sure that either everything is included in the package, or that the needed extra dependencies are available to download from the same web page. That's truly zero hassle, and this was one of the reasons that I became hooked to Slackware last year.
Personally, I use Swaret with Slackware. Without it, installing new packages from Slackware-Current was just painful. Thank God for Swaret!
On the other hand, Arch's package management, Pacman, supports dependencies and it's as easy to install new packages as is with Swaret, if not even easier. Pacman works well; however, in my opinion, its main problem has to do with the creation of new packages. I found that using "CheckInstall" with Slackware (or even Ubuntu and Debian) would install and create the package automatically for me. It would be awesome if the Arch guys added Pacman support to checkinstall and made the creation of Pacman packages automatic. Both Swaret and Checkinstall ship with Slackware, but on its /extra tree.
Winner: Without Swaret/Checkinstall, Arch Linux is the big winner because it has a larger package selection & dep support. With Swaret/Checkinstall in place, Slackware is slightly ahead because of the convenience these bring.
- "Arch Linux Vs Slackware, Page 1/2"
- "Arch Linux Vs Slackware, Page 2/2"