Linked by Eugenia Loli on Mon 9th May 2005 18:38 UTC, submitted by Robert Burns
Slackware, Slax "I have very mixed feelings about this release of Slackware. I do not think that the underlying philosophy of Slackware is obsolete. The concept of a system that can be configured and molded to the n'th degree is still in my opinion very much a good idea. However, this release of Slackware is not without its problems in execution." Read the review here.
Permalink for comment
To read all comments associated with this story, please click here.

I'm already very familiar with this philosophy and UNIX history as a whole, so I'll skip some of the more informative parts of the reply.


The traditional power of UNIX is the fact that it is a whole bunch of very small utilities that are connectable via very simple means (mostly text streams via pipes). Using these simple building blocks, a creative mind can solve very complex problems. Though there is no clear-cut line, the fear some people have with APT or complexer configuration and package tools is that it loses the kind of flexibility that UNIX offers, and it does harm to the universality of UNIX tools.


This is the real heart of what I was trying to get at; that we must develop levels of abstraction to understand complex systems, and as time goes on we must develop new methods of abstraction or else be faced with an overly complex system with no way to abstract away any of it and thus no way to keep it all under control.

The "slackware way" is to follow the Unix way as much as possible; that this toolkit (pipes + cat,set,awk,grep,sh,ls,cp,mv) is a good level at which to provide your base system abstraction. I hugely agree for file management and for dealing in matters of text, where expertise in this toolkit can lead to the power to quickly do all sorts of complex operations. It's for this reason the console won't lose its importance any time soon; users who know this toolkit are aware that nothing better has been developed in 30 years and until its enormously apparent that something better has been developed, these users will not abandon that paradigm.

But as time goes on systems grow in scope, complexity, breadth; we now manage many types of devices, we deal with more and more data not represented (or representable) textually, and we deal with systems that have much more breadth because more and more libraries are necessary to interoperate with the rest of the world.

One place where it's specifically obvious and thus easy to bring up is package management. Its a necessity common to distributions, and thus is abstracted away in each (serious one at least); even slackware does it by creating a set of tools based on the unix toolkit. There were 245 packages in slackware 3.3, and in 10.1 there are 552. Keeping track of this is a task that will only get tougher, and as time goes on its just foolish not to take a look at the provided tools and do *serious* introspection.

The example of the word processor is an interesting one because I personally like to publish most often in either HTML or LaTeX; but to do this you need deep knowledge of markup and most importantly the semantics of presentation. I don't know if these are valid requirements to place on all users, or even that placing these requirements gets you towards a better resulting set of tools; i think eliminating requirements for deep knowledge is beneficial to productivity and if done correctly ultimately beneficial to the final result. The word processor is an example where you are *still* dealing with text, though; so using text in this case is still desireable.

But it extends beyond this; interoperability in visual environments is becoming more and more important for productivity and interoperability with other systems (by and large all exclusively visual), and this takes time and work. The GNOME community has realized to a large extent that trying to do everything in C is limited (because it's not abstract enough for the problem at hand; creating visual applications!). The growing pains that the GNOME project is experiencing now are exactly what I think Slackware *needs* but is not getting due to its BDFL structure; why else would there be so many slackware based distributions?

I think that Slackware's level of abstraction is one that is slowly becoming obsolete as almost all other distributions are finding it necessary to provide a higher one... it's an opinion and a personal preference, but I do think that there is enough evidence behind it for me to stand strongly by it. Attempts to try to graft features onto the existing framework in ways that are not destructive (Jason Woodward's proposal for some optional dependency info) are met with disapproval straight from the top and are doomed to never be included, and while conservativism in software maintainence is good there are times when it just slaps the face of better judgement (debian sticking with xfree86, to provide a nonslackware example, and there are plenty for each distribution).

In the end, I can answer one of my own "questions"; the reason I always feel compelled to write a package manager for Slackware when I use it is that it's extremely easy to visualize how to do so because the package system is so simple and built upon such strong components, but also because the omission of a richer (or at least more convenient) package management system is a *glaring* defect that I can't readily ignore.


Time has known its toolkits and languages. In the end it seems only a few things have sticked: the UNIX toolbox, C, X, Perl, LaTeX, and maybe a handful of other tools. In my experience I can do most work with these tools that have been available for ages.


I have my own biases against Perl, but I think that the much of the future successful GNU/Linux development is centered around abstractions off of this toolbox and no longer the toolbox itself: abstractions that I feel go hand in hand with the unix philosophy. We are beginning to move beyond this toolbox to developing on or with the next atomic set of abstractions. This set is not yet well defined, but it is roughly: python/ruby/mono/java/some high level language with C interoperability, gtk/qt/fltk/fox/some toolkit with convenient abstractions above Xlib (which hardly any projects that have active development use anymore), and a host of scripting languages that aim at a niche between quick kludges (which perl exceeds at beyond all others) and large scale applications.