My Journey To Slackware

I thought I’d republish here a post I made on Slackware’s forum, so as to preserve this personal valuable content, and not have it lost to the forum’s constant rearranging of topics.

Without further ado:

I started using computers in the fall of ’84, when, as a fresh-faced student in junior high, I had my first taste of computers. The very first computer I tried was a TRS-80 Model I. By today’s standards, it was, and is, hopelessly underpowered, but for me, it was a chance to control something in my life. I knew from the moment I saw it that computers would become my life’s passion. That has not changed.

When I entered high school, I took a programming class, and they used Apple IIe computers (a computer, by the way, I have major respect for, having been imbued with the genius of one Steve Wozniak, and the last computer Apple made which I used with regularity). That whetted my appetite for programming at the time, and I wanted more.

After getting out of the military, I started building my own computers. Anyone who started in that era will remember vividly when add-on cards came with jumpers, and a manual that detailed what settings controlled what IRQ line it would take, what memory range it would occupy, etc. To have a working system then would have been a work of art, and maybe a bit of genius.

It was around ’96 when I first heard of this open-source OS called Linux. At the time, I was running FreeBSD, and liked its init system, and hoped for something similarly simple to administrate. Nevertheless, I experimented with some of the other major offerings to see if something else would be better suited to my tastes.

Alas, none of the major offerings (Red Hat, SuSE, Caldera, among others) came close to satisfying my need for tweaking my system to my heart’s content. In frustration, I googled for a distro which was similar to BSD. Among the results was a mention of something called Slackware. Curious, I checked it out. The description sounded like what I was looking for, so I downloaded it. This was in, I believe, about 2006, soon after the release of 10.2; I bought 11.0 on CD-ROM when it was released, as a measure of good faith.

I had to use Windows for some applications back then, because application support wasn’t where it is now, and so I dual-booted. But gradually, as Linux app support became better, I gradually used Windows less and less, and in about 2012, I stopped using it entirely. And I have had no reason to regret leaving it behind.

The reason I use Slackware is because it gives me the experience that those older home computers gave me: it forced me to know what my computer was doing behind the scenes. When something was broken or didn’t work right, I was forced to find my own solution. Solving problems can be simultaneously frustrating and exhilarating. For me, it is something that I can never explain to another who is not already intimately familiar with that experience. You just have to experience it for yourself.

I can’t ever imagine another distro that will give me that experience and for that reason alone, I will continue using Slackware for as long as it is maintained. Hopefully that will be for awhile!!

Advertisements

Mechanism, not policy

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.

First blog post

This is the post excerpt.

Greetings, my fellow Linux users and devotees!

I’ve dabbled in the past with a blog, but never was serious about writing on a regular basis. I’d like to change that, starting now. I’ve begun to think more deeply about a number of things, including Linux and life, and I’d like to share them with the world.

I know, I know: This is yet another “me-too” blog with yet another person who wishes to spew this thoughts onto an uncaring world. Not everyone thinks the same way, and I’m hoping that what I have to say is important to at least one person; if I’ve accomplished that, I’ve done what I set out to do.

Without further ado, let us begin the journey!!