I posted recently in the official Slackware forum, linuxquestions.org, and in the interest of preserving what I think is the fundamental nature of Slackware, and why it has endured for so long, here is the post in full:
I was reading Eric S. Raymond’s seminal book regarding Unix, “The Art of Unix Programming”, and came across a section which bears scrutiny where Slackware is concerned. Particularly, this excerpt:
But perhaps the most enduring objections to Unix are consequences of a feature of its philosophy first made explicit by the designers of the X windowing system. X strives to provide “mechanism, not policy”, supporting an extremely general set of graphics operations and deferring decisions about toolkits and interface look-and-feel (the policy) up to application level. Unix’s other system-level services display similar tendencies; final choices about behavior are pushed as far toward the user as possible. Unix users can choose among multiple shells. Unix programs normally provide many behavior options and sport elaborate preference facilities.
This tendency reflects Unix’s heritage as an operating system designed primarily for technical users, and a consequent belief that users know better than operating-system designers what their own needs are.
Slackware still follows this philosophy; its progenitor never pretended to anticipate his users’ needs (policy) for his distro, preferring instead to concentrate on keeping the distro’s design (mechanism) as simple as possible.
This has the following effect on most users upon first encountering Slackware:
But the cost of the mechanism-not-policy approach is that when the user can set policy, the user must set policy. Nontechnical end-users frequently find Unix’s profusion of options and interface styles overwhelming and retreat to systems that at least pretend to offer them simplicity.
Most distros designed to be ‘user-friendly’ follow a policy approach; most users, when encountering Linux, come from Windows, where both policy and mechanism have been dictated to them, and they are not obligated to make those kinds of choices; Redmond has made it for them. This, I believe, is where the popularity of Windows comes from; Microsoft has put a kind of ‘user-friendly’ approach for its GUIs, but the cost is that only those tasks its engineering and marketing departments have anticipated are super-easy; anything else is impossible, or extremely inconvenient, requiring almost super-human efforts to accomplish.
Raymond makes an allusion to this phenomenon:
Many operating systems touted as more ‘modern’ or ‘user friendly’ than Unix achieve their surface glossiness by locking users and developers into one interface policy, and offer an application-programming interface that for all its elaborateness is rather narrow and rigid. On such systems, tasks the designers have anticipated are very easy — but tasks they have not anticipated are often impossible or at best extremely painful.
The downside of these kinds of distros,however, are that changes to them not anticipated by its designers are excruciatingly difficult to accomplish, because of their superficial glossiness that hides the complexity necessary to present a simple interface to the user.
Slackware, on the other hand, makes no such bold claims for itself. Rather, the most essential packages have been assembled into a very simple system, with additional packages to facilitate convenience offered by its various users for the community, in order that changes to it are as easy as possible for users who have taken the time to understand what is going on behind the scenes, and then to make the changes they see as necessary to accommodate their work flow.
Unix, on the other hand, has flexibility in depth. The many ways Unix provides to glue together programs mean that components of its basic toolkit can be combined to produce useful effects that the designers of the individual toolkit parts never anticipated…Unix’s support of multiple styles of program interface (often seen as a weakness because it increases the perceived complexity of the system to end users) also contributes to flexibility…
The reason that Slackware, in a general sense, only appeals to the technical users is because frequently, only these kinds of users are interested in how their systems work, and want to “get their hands dirty”, so to speak, in twiddling their system at a very basic level to manipulate their data the way they want it accomplished. As a consequence, these users will do whatever it takes to make that happen, including Googling and experimenting, accepting failure the first few times as a natural consequence of their bit-twiddling, because success will always come to those who persist through failure and frustration.
In the short term, Unix’s laissez-faire approach may lose it a good many nontechnical users. In the long term, however, it may turn out that this ‘mistake’ confers a critical advantage — because policy tends to have a short lifetime, mechanism a long one. Today’s fashion in interface look-and-feel too often becomes tomorrow’s evolutionary dead end (as people using obsolete X toolkits will tell you with some feeling!). So the flip side of the flip side is that the “mechanism, not policy” philosophy may enable Unix to renew its relevance long after competitors more tied to one set of policy or interface choices have faded from view.
This is the reason why Slackware has endured for so long, while its competitors have fallen by the wayside; despite its being derided by users who prefer a glossy approach to computing, other distros’ seemingly intuitive approach confers a kind of rigidity, often with the undesirable effect of making computing more difficult than it needs to be. Slackware will remain relevant for as long as users desire to implement their own policy, and use Slackware’s simple mechanism to accomplish their goals.