Welcome to Gaia! ::

It seems like a lot of mud is being thrown at Slackware from the media and fan-boys; but despite the abuse, Slackware remains an active and relevant distribution. In fact, it's the oldest surviving distribution and for the last decade I've been a proud member of that community. I run Slackware almost exclusively on my own systems. My friends have tried it and think I'm masochistic, but I would disagree. Slackware can be intimidated, even to experienced Linux users. However, once you understand the system, and the logic behind it, Slackware becomes a sys admin's dream come true. I have tried many other distributions including Ubuntu, Debian, Red Hat, Fedora, and Gentoo. I always come back to Slackware.

There is a lot of misunderstanding and misinformations surrounding Slackware. In this thread, I am prepared to defend my choice and answer questions about the Slackware distribution and philosophy.

Patrick Volkerding is one of my personal heroes and I would mark his name amongst the likes of Alan Turing. And if you don't know who Alan Turing is you ought to learn yourself a good many books!

Haha, I'm surprised you think Slackware was hard to setup compared to Gentoo. Gentoo has a HUGE install Handbook. Then again, I loved the Gentoo Handbook wink .

Gentoo's three greatest features are: the infamous Handbook, Portage, and the Wiki.

Unfortunately, Portage is a double-edged sword and I eventually reverted back to Slackware. Gentoo is still one of my favorites though, and I recommend it to anyone who wants a source-based distro that's easy to maintain.

Sadly, I think Gentoo has been losing some steam ever since the original founder was kicked off his own project. I hope Gentoo can be restored to it's former glory because it is one of the most deserving distros on the scene.

First of all, while distcc is nice (and it comes with Slackware) it's maximum theoretical speed up is only 200% (or 3 times faster) which is substantial (when attained) but still makes Gentoo one of the slowest installs among all distros. Still my 2nd favorite.

You bring up two issues:
1. Compiling from source (and dealing with package management)
2. Dependencies and linking to system libraries

1. While it's true that Slackware admins end up compiling from source quite a bit, there are a few conventions that make it a lot easier. For example, if you use buildscripts to generate packages you can still manage everything with pkgtool suite. Buildscripts is the method Volkerding and the other maintainers use to build all the official packages and you can get their buildscripts from any official mirror. You can also find tested buildscripts for a variety of unofficial packages at SlackBuilds.org. That will save you a lot of time when compiling your own software. If you want to make changes to the default compile-time options you just need to change the config flags in the build script and re-generate the package. It's possible to store common config/compile flags in an Environment Variable and call it for each build (similar to USE flags), but you're right, you won't get the same kind of convenience as Gentoo.

2. Dependencies is another area where Gentoo is more convenient at handling for you. However, Slackware isn't bad at it either, it just uses a different approach. With Gentoo, emerging a package gets you that package plus all the dependencies (including whatever system libraries the ebuild author happened to like). That system *works*, but it could be argued that it's inefficient. Especially with regard to system libraries, you should NEVER need to recompile them. Furthermore, the Gentoo approach can lead to having multiple versions of the same library on your computer. Slackware packages have relatively few external dependencies because Slackware comes with a large set of libraries already installed. In the rare cases where packages do have external dependencies it is often clearly marked in the packages short description. Also, most packages only link against the versions of the libraries that are installed by default. This both reduces the number of dependencies and eliminates redundant code (and the possibility of resolution clobbering) on your system. Obviously, if you roll your own packages, they will be linked against whatever you have on your own system.

I will also bring up the point that even if a Slackware package was compiled with options you may never use. If your system is powerful enough to run Gentoo, you're unlikely to ever notice the supposed performance loss (even through benchmarking). And Portage takes up more disk space than all the unused features of all the Slackware packages put together. While Gentoo installs only and exactly what you need, my suspicion is that when you factor in Portage and the redundant libraries you'll end up using just as much, if not more, disk space as Slackware.

This is generally true of any binary distribution. One of Slackware's design aims is to run well on both new hardware and really really old hardware (similar to Torvald's aims with the vanilla kernel). As a result, Slackware is pretty lean and fast regardless of your systems power, or lack-there-of. And speaking of Vanilla, Slackware espouses a design principal of "all vanilla packages". From the Kernel to KDE every package is as pristine and untouched as a fresh download from the official developer/maintainer's website. This means that distributions-specific problems caused by distribution-specific patches are never a problem on Slackware. A lot of projects don't like supporting their own code unless you got it directly from them. With Slackware, you basically did. Slackware's model encourages fixes to happen at the source rather than at the distribution level which means that the fix will affect (and help) everybody as opposed on only a select group.

Also, for those who like tools, there are advanced package management tools available for Slackware that will use the official (and unofficial) mirrors as a repository and some of these tools even offer dependency resolution. A few of the popular ones are:

slackpkg: Basic, but powerful enough distribution upgrades. I use it for automated security updates.
slapt-get: Similar to Debian's APT tool.
SWareT: Library dependency resolution.

The 200% number came from the website of the original developers. Their claimed theoretical maximum. In my own builds (using only 2 or 3 systems) I've gotten about 100-150% increase, which is pretty nice.



That's a good technique. I've never had more than one Gentoo box, but I'll keep that in mind.



I'm not talking about upgrading libs. Even Slackware updates individual libraries between releases (for security and bug-fixes). I'm saying in a typical situation you should never have to compile or re-compile a library because libraries shouldn't have compile-time options. Libraries should be able to be installed as binaries and upgraded as binaries. It's just good software engineering practices more than a distribution-related issue.

As for glibc, on Slackware it only changes between releases. If you upgrade glibc, you'll also need to recompile a large number of applications against the new version. Installing a new set of binary packages is quicker than recompiling all those applications (even with your 300% compile-time increase). That's what you call a trade-off. Gentoo has convenient framework for creating a highly custom solution, and it's all very well integrated, but there's the compile-time cost vs. binary packages. In many standard deployments you don't need that kind of library resolution. Especially in the case of Slackware, Pat is very conservative about choosing stable versions. A lot of people see it as a badge of quality when a package is included in the Slackware base.



Slackware doesn't have multilib. Slackware doesn't have an official 64-bit release (and if it did, Patrick would go Pure-64). Back when I was using Gentoo, I did run into the multiple versions of the same library issue more times than I would have expected. It's possible the scene has changed since it's been a few years.



Yes, that does make sense. But how often do you actually run into issue like that? And the SlackBuilds are publically available so it's easy to recompile packages when necessary. I have only twice needed to recompile official packages. (I don't use Evolution so I never noticed a problem there.) I don't even use KDE. Fluxbox on the laptops, wmii on the desktops.



Right, and it's easy to set ./configure options and apply patches from a SlackBuild. Gentoo just has a more automagical solution. Which is convenient, but IMHO, not necessary. If anything it makes the platform less standard, which is good if you want a very high degree of customization, but not as good if you consider standardization to be a key component of stability and security.



I whole-heartedly agree. Portage is a beautiful, wonderful thing, But it doesn't fit with the Slackware philosophy or way of doing things. It's un-Slackware to manage dependencies, that job is explicitly left to the administrator. It's un-Slackware to patch software unless absolutely necessary. Patches should happen at the package's source, not at the distribution. It's un-Slackware for the installation of a package to require the re-compilation of other packages (the exception being upgrading the major version of base libraries or compilers which only occur in new releases, minor version for security/bug-fixes are compatible with existing binaries).

Overall, I have found that while it takes somewhat more "work" on the part of the admin to maintain a Slackware system, it takes much less time (both real and CPU) on the system. I still end up compiling many things from source, and rolling my own packages, but with well written SlackBuild it's not difficult or time-consuming and those packages work on all my Slackware systems (I have 6).

I liked Gentoo a lot, but Portage was just too slow for me to deal with on a regular basis and I found that I really didn't need a super-customized solution (which is where Gentoo really shines) so I switched back to Slackware. It's just plain faster. It's a little more typing, but a lot less waiting. It's pkgtools follow the old UNIX UI conventions which lend themselves well to scripting and integration. Most of the tools I linked, if not all, don't replace pkgtools but work on top of them. Slackware's aim to be the most UNIX-like distro is largely successful and it's gained some notoriety among BSD and Solaris admins as well.

Gentoo is a close and I feel related distro (they both borrow some concepts from BSD). But it's pretty bleeding-edge and deviant from conventional system design/maintenance. After a while, if you're not taking advantage of it's unique advantages, it starts to feel kind of gimmicky. Sure, you *can* have a system with just the bare minimum. What you need, and only what you need. However, if you consider the average Gentoo system, is that kind of minimalism really a design concern? Is that level of customization necessary or novelty? Is it being taken advantage of? Is that processor-specific compiler flag saving you enough hard disk space or CPU time to offset the Portage tree and the slow CPU-hungry dependency tracking?

It sounds to me like you have a more complicated and specialized setup than I currently maintain. So in your case, Gentoo might be a better solution. I've never claimed Slackware was the best for all cases. However, with Gentoo there IS a trade-off that I feel is unwarranted for a majority of cases. Gentoo is my first choice for a source-based distro, but the advantages of source-based are few and far between in terms of practical implementations. I feel you can get the same level of system maintenance convenience (at the sacrifice of customization) from Debian's APT system. I wish no ill-will towards Gentoo and I hope it recovers from it's recent downward-trend. It's one of the most innovative groups on the scene. But at the same time, there is something to be said for the tried and true conventional way of doing things. The Slackware Philosophy builds on the industry practices that worked and worked well. It sticks to the well accepted, well-known standards. It gets the job done. Period. No frills. It's very parsimonious, which is its own kind of beauty.

Haha, I spent an hour and a half on my previous post and Gaia did the same thing to me, but Firefox kept it in memory so I just hit back and submit again.

Anyways, I'm sorry if I elevated your blood pressure any. I respect your point of view and I'm glad Gentoo works for you. I personally feel that the trade-offs Gentoo demands are exorbitant and unnecessary for the majority of systems. It's a nearly flawless framework for a source-based distro, but it's still a source-based distro. It has all the advantages (and then some) of the source-based philosophy, but it's still stuck with the same old price of compile-time.

Does Gentoo work? Yes. Does it fill it's role well? Absolutely! Does the average system require or even want to be that flexible? Probably not.

Everyone should try Gentoo at least once to know what it's like to have that kind of power and control made effortlessly available to you. But then they should decide for themselves whether or not it really fits what they're trying to do.

To make an analogy: it's one thing to say "I drive a gas-guzzling Hummer H2 because IF I ever decided to leave the city I could drive it off-road", but quite another to say "I drive an H2 because it's the ONLY car that can get me from where I live to where I work without getting stuck in the mud."

The same analogy applies to Slackware (but, IMHO, to a lesser degree).

I've heard some good things about Arch but I haven't had the opportunity to try it out myself yet. I'd be happy to flame about it once I have some actual first-hand experience with it.

I "tryed" Arch. Maybe I should call it an exercise installing 'couse now i have "arch" but really not anything really. Even X Window system.... löl

What i learned? Always check your modems -cards before installing ftp exc.

I've used Slackware once before, on an old P.O.S laptop I bought 4 years ago that could barely run XP, and it ran damn spiffy. I did hate the general unfriendliness that came with it, but did appreciate the lesson on Linux while figuring out how to install it. I learned quite a bit by doing so.

Unfortunately, I'm a college student, and i don't have time to be messing around with configuration too much, so for now I'll be using Ubuntu on my desktop comp (Or mint if it turns out to be good), and worry about configuring Slackware when I get a new laptop, and need a lightweight system for it.