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.

Interesting post jonas...

The first was that the community which was always touted as mean spirited, the community which I never really found as such, *started* to become more hostile (or to simply ignore) questions about the merits of the Slackware system of organization and others.

Maybe, but it is probably caused by a cultural difference. To the outside world it may seem to be a rude community (or at least some facets of the community), but when you have an interesting problem it is a very helpful and kind community. A lot of Slackers found their own way in Linux and UNIX, and are not very interested in too obvious questions for which the answers are documented at various places. "Pointing out the obvious" (though it may be less obvious for new users) may often be felt as a waste of time, or the unwillingness of a user to try to find an answer him/herself.

Why is it easier to view text files in /etc/rc.d/ as opposed to run 'rc-update -s' and 'rc-update add _runlevel_ _service_'? Why is rsynching -current better than "apt-get dist-upgrade"? Usually the answers you get are laughable; most hinge on some paranoid delusion that distribution-common software like rsync are inherantly better and less likely to bite you than distribution-specific software like apt, disregarding the differences in their purposes and how they fit the problem at hand: that rsync is designed for the synchronization of files and apt is designed (in part) for the synchronization of packages.

I think that there is more than one reason. Some of which are captured in older (or newer) UNIX philosophies:

"There are many people who use UNIX or Linux who IMHO do not understand UNIX. UNIX is not just an operating system, it is a way of doing things, and the shell plays a key role by providing the glue that makes it work. The UNIX methodology relies heavily on reuse of a set of tools rather than on building monolithic applications. Even perl programmers often miss the point, writing the heart and soul of the application as perl script without making use of the UNIX toolkit." --David Korn

"This is the Unix philosophy. Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface." --Doug McIlroy

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.

To give one, more clear-cut example, most (traditional) UNIX users are allergic for word processors. Why? First, a word processor is a monolithic program that can't be expanded as easily as a pipeline, second, it does not use a plain text format when you add formatting. The horror of not being able to sed or awk your data is scary for this category of users.

Looking to the future, I found that more and more software is being developed using tools and libraries that I do not get (officially) running slackware. As time goes on there are two possible solutions: Slackware occupies a smaller and smaller niche meeting the needs of users who don't care for the software they can't run (or don't mind building it themselves or using 3rd party packages),

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.

Not having PyQT or other bindings can be painful if you have to develop applications for other target groups. But this can be another discussion on its own: are graphical user interaces that much better than using a shell, except for very obvious applications, like non-batch image manipulation?

Some people may find it interesting to read this article:
http://www.rap.ucar.edu/staff/tres/elements.html

It may give some insights why some people work in a completely different way, and are not so much interested in the latest desktop environments, GUI toolkits, etc.