You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

By Jibril Hambel
Released under a Creative Commons (Attrib-NonCommerical-No Derivs 2.5) license.

Several months ago, some gormless weasel from somewhere stirred up a fuss when he wrote an essay on one of the Nixer sites asking whether the Slackware distro mattered any longer. Its not really worth googling to find the author and the site where it ran, since it seems to have created an inadvertent meme in the Linux community as advocates, fanboys and editorial writers picked up upon the concept of Slackware 'mattering.' Misguided and myopic as the essay was, it certainly provoked a reaction. For a number of very good reasons, the question stuck in many a craw, and triggered a defensive barrage of articles telling the clueless author just why Slack remains a vital distro and a necessary flavor option in the distro hit list, despite the fact that most other distros are moving on to DVD size releases and trying to outrace each other to be latest and greatest.

The premise of this essay is simple: the question is not whether Slackware matters, but WHY it does and WHY it will continue to do so as long as it remains in ongoing development. I suppose the 'always' part is a bit of hyperbole; should a distro become defunct and all development cease, it would be as useful as a Ygdrassil install floppy in 2006. But perhaps not. The question posed by that one article was not whether Slackware was useful or current or important, but whether it 'mattered'.

So perhaps even a defunct Slackware would continue to matter, especially in light of the fact that a number of slick and solid derivative projects seem to be taking off from the Slack launchpad.

Slackware matters for many reasons. Some quite up-to-date concerns continue to be addressed by the oldest surviving Linux distro. Before the Linus Torvald's bombshell expressing his disdain for the Gnome desktop environment, Slack had already jettisoned the desktop favorite. For different reasons perhaps, but it showed the Linux fold that some distros were not afraid to dump what no longer worked well enough, rather than cave into contemporary traditions and competitive habits.

Slack can afford to do that because it is still maintained primarily by its founder and it doesn't claim the huge number of users seen by Ubuntu, Suse or Fedora. And the fact that the distro is not overly concerned about dragging more converts into its fold is another reason why it remains an important offering. While Debian claims to be the universal operating system, the one offering the largest degree of freedoms to its users, and it's ongoing development promises to keep the users first, one can catch many of those philosophies and promises in Slackware as well, albeit in a slightly different form. As someone who used Debian daily, I can vouch that their manifestos and promises are being upheld. But I find many of the same benefits running Slackware.

For the sake of a reference point, I'll point out that I currently run Slackware 10.2 and Suse 10 on a laptop and a very dated XP (Service Pack 1) and Debian Unstable on the desktop. Between those three Linux variants, I find all I need to maneuver the GNU/Linux landscape while relying on VMWare to test stuff I don't necessarily want to install on hard drive. Why then, with a full blown Slack install, would I go through several nights of hairpulling frustration to get Slack also running virtually on the Window's VMware? Because Slack works a cut above most as a stable, simple, fast and clean production machine, and is also the most educational, and often unforgiving distro to experiment on. With a virtual Slack, I can hose it as often as needed while plumbing its depths and intricacies, but not lose the work I prefer to do on a Slackware production box.

With other distros racking up as many as 20,000 available apps for their package managers, Slack seems minuscule by comparison. The number of apps that are officially supported runs to about 600. And yet more than one of the 'big ass' distros out there claim to offer a one app for one job default installation. With Slack, whether they make that claim or not, it remains more evident. Rather than tailor their distro to run the most apps, they have designed a distro that aims at getting the job done rather than collecting more software to do the same job with different guis and developer teams.

What your basic Slackware release doesn't do is hedge on the conservative side (except perhaps in kernel matters), with Linux software releases. It aims to provide the latest release that have proven themselves to work without making undue sacrifices to overall stability. I fully expect the next release to have KDE 3.5 so long as there are no major last minute bugs in its Slack build. You could, of course, have installed it when it came out and many have, but I'm talking about Slackware supported here. The term 'supported' means a lot to Slackers. It means it will run, and run well, and won't fall down and go *boom* dragging your OS with it. You're free to run all the 'unsupported' software' you want. But when something is supported it's virtually a product guarantee from the Slack folks that it will work. A first time install of Slack will leave you, well, slack-jawed, if you equate stability with something like Debian Sarge's 3.3 KDE and OpenOffice 1.4. Simply put, Slackware offers the best of both worlds so stability doesn't always translate as extremely dated.

Things like this matter. Slack remains a flavor with very specific strong points and all those pluses have a lot to do with the distro's overall approach. To oversimplify, the approach can be broken down into a few subheadings that can further illustrate why such a development philosophy is so important as the distro field grows more and more competitive. There are the standard subcategories of stability, simplicity and speed, which tend to speak for themselves. Being developed almost single handedly by the man who invented the distro means you would be hard pressed to find someone more intimately knowledgeable about the distro in question. The fact that its the same person who began the distro in 1992-3 means that the cerebral archive of Slack wisdom is more unified and holistic than 'thousand developer' systems. The possible drawback is in terms of size and software availability, but if you're looking to load ten thousand apps on your box you're not looking for Slackware.

The simplicity of design and structure tends to provide speed to even antique machines, since the idea of cruft and bloat is a non-issue. These are standard Slack selling points and probably don't need to be explored further.

What makes it such an important distro in the first decade of the 21st century are words like non-competitive, anti-trendy, slightly arrogant and extremely hackerish. And I mean that in a good way. As the battle for the desktop continues to rage, Slackware refuses to join the rumble if it means sacrificing it's core qualities mentioned above. It doesn't follow trends to corner market shares, it simply does what works. If Slack were trendy it would have changed its installer to a slick gui and made sure it released as regularly as the rest of the top tenners. Distro testers and bleeding edge seekers are often frustrated by the lack of consistent release schedules. Slackers are quite content to wait 'till it's ready.'

The distro has gotten the rep over the past several years as being arrogant, as being as user-friendly as a coiled rattlesnake, with a user base that cuts newbs no slack at all. But, like Debian, it never claimed to be a migration tool or a newb friendly point and click world. The 'unofficial' ##slackware channel on Freenode counts as one of the most knowledgeable and helpful channels I've encountered. Therefore it attracts users who want to increase their Unix skills and competence and explore how a system works, and who want to customize to their hearts content, preferably without relying on third and fourth party control centers. Users who KNOW the first step in troubleshooting and learning is the man page. If you want to learn Slack, you will be perusing Unix manuals - not Sam's 24 Hour Linux Distro guides - more often than many other distro users. Which means the knowledge you glean while slacking tends to be applicable across a wider range of OSs. And if going into command line to edit configuration scripts still gives you a case of nerves, the hacker in you has yet to develop the bloodlust that leads to reinstalls as you learn by trial and error what it was that hosed your system this time. Or to realize it is often the fastest and most efficient way to configure your system without worrying about distro configuration tools overwriting your changes.

You do need to spend time on a system like Slack, to maintain the system itself and make it do your bidding. Because it is a relatively small distro, though, you don't need a Debian sized education to start tweaking, configuring and customizing. Debian, in spite of its size remains a pretty bare bones distro, but simply addressing package management could lead to a series of summer intensives at a local community college. Slack doesn't even offer a dependency handler in its own brand of package management. And that – according to official Slack documents – 'is how we like it'. If that's arrogance, so be it. Having tried Slack, I find I can at least say I've never spent hours in dependency hell, and I've never lost an app because a new one had issues with an old one's libs. Arrogance, in reality, is the wrong word, or an incorrect perception from non-slackers. It's more of a 'this works, and it works well and simply... so why do I need the bells and whistles and options I never needed in the first place if I'm willing to learn the Slack way of doing things?” pragmatism. Efficient pragmatism will always matter.

I have no intention of slighting the many people out there besides Patrick Volkerding (Slack's Papa) who sweat away to keep the old workhouse in tiptop shape and running smoothly. But I think its safe to say there were times when the debugging and promoting and hacking runs were endured by 'the man' himself and no one else. The singularity of vision and the commitment to excellence found in the Slackware distribution come in large part from the sometimes Herculean, sometimes Sisyphean efforts of a man who devoted himself to keeping his vision of an OS alive and kicking through both personal and industry upheavals, and it's why he's one of the few personalities mentioned on a first name (or initials) basis alongside Linus, Larry (of Perl fame), RMS and ESR. And it's one of things that makes Slack so streamlined, efficient and trustworthy; so well crafted.

For deity's sake I'll let go of commenting on the first and last paragraph as it IMNSHO doesn't do nothing but distract from the essence of your article and set a certain tone of voice.

derivative projects
So which are the ones Slack contributes to the benefit of the greater GNU/Linux community?

Before the Linus Torvald's bombshell expressing his disdain for the Gnome desktop environment, Slack had already jettisoned the desktop favorite. For different reasons perhaps, but it showed the Linux fold that some distros were not afraid to dump what no longer worked well enough, rather than cave into contemporary traditions and competitive habits.
"no longer worked well enough": as in who's (objective) criteria in the Slack-verse?

The fact that its the same person who began the distro in 1992-3 means that the cerebral archive of Slack wisdom is more unified and holistic than 'thousand developer' systems.
Quantify that in an objective way, please?

The simplicity of design and structure tends to provide speed to even antique machines, since the idea of cruft and bloat is a non-issue.
Idem dito.

What makes it such an important distro in the first decade of the 21st century are words like non-competitive, anti-trendy, slightly arrogant and extremely hackerish.
With all due respect, these are your own interpretations, not facts. If they are, please quote authoritative sources (yes, in your case that would mean you probably can only quote only one man).

Slack doesn't even offer a dependency handler in its own brand of package management.
People who are supposed to handle loads of production boxen may call it distracting or even "inefficient", and BTW, since you already stated yourself you spent time in "dependency hell", do you really think you should market that as an advantage for using Slack?

by rkelsen on Tue, 2006-06-20 20:14

Quote:

Originally Posted by unSpawn

For deity's sake I'll let go of commenting on the first and last paragraph as it IMNSHO doesn't do nothing but distract from the essence of your article and set a certain tone of voice.

You're right. It isn't the most un-biased article I've ever read. Then again, most of these things usually are. It doesn't matter what distro they focus on. They're usually pointless fanbois drivel.

Quote:

Originally Posted by unSpawn

Quote:

derivative projects

So which are the ones Slack contributes to the benefit of the greater GNU/Linux community?

What is that supposed to mean? Do you understand what is meant by the term "derivative project?"

Unlike many other commercial Linuxes, Slackware is always available for free download. The whole distribution. 24 hours a day 7 days a week. Other distros don't release a complete free (as in $) version. Some will only release a free version after their paid-for version has been on sale for several months.

Quote:

Originally Posted by unSpawn

"no longer worked well enough": as in who's (objective) criteria in the Slack-verse?

I got the impression by reading the changelogs that Pat dropped GNOME because it was becoming too large and ungainly for one man to package. In his own words:

Quote:

"it does usually need to be fixed and polished beyond the way it ships from upstream more so than, say, KDE or XFce ... GNOME is and always has been a moving target (even the "stable" releases usually aren't quite ready yet) that really does demand a team to keep up on all the changes (many of which are not always well documented)."

Quote:

Originally Posted by unSpawn

Quote:

The fact that its the same person who began the distro in 1992-3 means that the cerebral archive of Slack wisdom is more unified and holistic than 'thousand developer' systems.

Quantify that in an objective way, please?

I think he means that the Slackware of today is exactly the same as the Slackware of yesterday. The software may have been upgraded, but the underlying philosophy of the way it is assembled remains the same.

Quote:

Originally Posted by unSpawn

Quote:

The simplicity of design and structure tends to provide speed to even antique machines, since the idea of cruft and bloat is a non-issue.

Idem dito.

You want quantification? OK. A COMPLETE installation of Slackware-current is 517 packages. That figure includes almost 100 packages worth of KDE "language bloat".

Have a look around. How many Linux distributions today ship with fewer than 1500 packages? Not many. Most of them (like Suse, Fedora, Mandrake, etc) require 10 to 12 gigs of hard disk space for a complete installation. The complete Slackware takes up less than 4 gigs.

Quote:

Originally Posted by unSpawn

since you already stated yourself you spent time in "dependency hell", do you really think you should market that as an advantage for using Slack?

???

He said this:

Quote:

Having tried Slack, I find I can at least say I've never spent hours in dependency hell

(emphasis added)
And I can agree with that. After 7 years of using Linux, I've always found that automatic dependancy resolution causes more problems than it solves. That Slackware doesn't have this "functionality" should be considered a blessing.

by unSpawn on Tue, 2006-06-20 20:35

What is that supposed to mean? Do you understand what is meant by the term "derivative project?"
I was hoping for something that could be marked as giving back to the community, something that would benefit anyone outside the Slack-verse. Prolly should have phrased that qualitatively "better".

I got the impression by reading the changelogs that Pat dropped GNOME because it was becoming too large and ungainly for one man to package.
Looks like a qualitatively "good" reason to me. Of course it could also be used as an argument to point out bottlenecks, but OK.

I think he means that the Slackware of today is exactly the same as the Slackware of yesterday. The software may have been upgraded, but the underlying philosophy of the way it is assembled remains the same.
I can't see how other distro's differ at that.

You want quantification? OK. A COMPLETE installation of Slackware is 517 packages. That figure includes almost 100 packages worth of KDE "language bloat".
If those are solid figures then that's an excellent argument.

Quote:

Originally Posted by rkelsen

He said this:

Quote:

Originally Posted by mephisto786

Having tried Slack, I find I can at least say I've never spent hours in dependency hell

My bad. Misread that.

by cereal83 on Tue, 2006-06-20 20:37

My company runs basically only Slackware. Our revenue last year was over $12 million. We will never let go of Slackware. It just WORKS and it stable and I wouldn't recommend another distro to anybody.

We have over 100 servers with slackware and on most of the older machinbes, the uptime is over 1200 days. We use it for firewalls, routers, web servers, dns servers, mail servers, dhcp servers, domain controllers, sql server and everything else you can think of.

slackware > *

by unSpawn on Tue, 2006-06-20 21:20

My company (..)
That's a nice testimonial but claiming "it works" or stability as unique selling points for Slackware versus other distributions won't hold up and you know it. (Digressing a bit, and talking Linux in a commercial production environment, I would be the least impressed with uptime measured in years. Less downtime than covered in the SLA's: now that shows excellence IMHO. And that can't be claimed as distribution-specific either.)

by rkelsen on Tue, 2006-06-20 21:24

Quote:

Originally Posted by unSpawn

I was hoping for something that could be marked as giving back to the community, something that would benefit anyone outside the Slack-verse.

Out of curiosity, how many other commercial Linuxes do this?

Quote:

Originally Posted by unSpawn

Of course it could also be used as an argument to point out bottlenecks, but OK.

I can see where you're coming from, but you're forgetting that one of the main resaons Slackware exists is to put food on Pat's table. There are other distributions which are built by huge teams of people, which have better community support and have the latest of *everything*. That Slackware even competes on such a playing field is a credit to the bloke who assembles it, no?

Quote:

Originally Posted by unSpawn

I can't see how other distro's differ at that.

Fair enough. You're probably right.

by unSpawn on Wed, 2006-06-21 13:27

Out of curiosity, how many other commercial Linuxes do this?
Hmm. I wouldn't want to narrow it down to labels like "commercial" unless you really value the underdog role. Only ones come to mind are vendors where in-house developers are allowed to work on kernel/FOSS projects in the bosses time, RH did provide the community with RPM and OBSD with OpenSSH. I'm pretty sure there's more examples, but if you where to counter this doesn't have any bearing on the article discussion I wouldn't disagree.

I can see where you're coming from
Having an eye for the procedural side of things ain't good you mean?

you're forgetting that one of the main reasons Slackware exists is to put food on Pat's table. (...) That Slackware even competes on such a playing field is a testament to the bloke who assembles it, no?
Nice way of putting it, absolutely, also a honest reason (for why it would matter to mr V) as well IMHO.

by mephisto786 on Sun, 2006-06-25 08:58

Derivative projects? Count the number of live cds now trying Slax technology over Knoppix...not arguing relative merits of knoppix vs slax, there is a huge increase of late in slack based distros and modular pkg management to create your own live cds.....

As for Gnome, I think the key word in the chnanglogs is invasive...it tends to muck with kde menus, unless specially configured...which btw, i found Freerock an excellent example of....

As for the request for authoritive support and supporting the statements made in the original essay, it's listed under OPINION, not TECH or HISTORY or FAQ, and the general nature of distro reviews is primarily concerned with a users opinions and experience with the distros....i guess the response to the thread at least points up one thing....?

Slack matters

by alisonken1 on Thu, 2006-08-10 18:58

Quote:

Originally Posted by mephisto786

As for Gnome, I think the key word in the chnanglogs is invasive...it tends to muck with kde menus, unless specially configured...which btw, i found Freerock an excellent example of....

If you go back and read the changelog, GNOME was removed because it was too man-intensive to keep GNOME running under Slackware standards.

The invasive part is in relation to recommending other options for the GNOME desktop - Pat had several recommendations but could not recommend Dropline GNOME since Dropline had a habit of replacing Slackware standard packages for ones that have been recompiled for x686 only rather than compiling for i486 (with i686 optimizations).

by zborgerd on Fri, 2006-08-11 13:42

Quote:

Originally Posted by alisonken1

The invasive part is in relation to recommending other options for the GNOME desktop - Pat had several recommendations but could not recommend Dropline GNOME since Dropline had a habit of replacing Slackware standard packages for ones that have been recompiled for x686 only rather than compiling for i486 (with i686 optimizations).

This is not only completely off the subject, but it's not even close to what he said in the ChangeLog. I am, however, not surprised. People pretty much just make up whatever they want to make up when it's convenient. I tend to remember it pretty vividly because it's pretty common jibber-jabber of the troll.

I will quote it for you - right from his ChangeLog:

Quote:

gnome/*: Removed from -current, and turned over to community support and
distribution. I'm not going to rehash all the reasons behind this, but it's
been under consideration for more than four years. There are already good
projects in place to provide Slackware GNOME for those who want it, and
these are more complete than what Slackware has shipped in the past. So, if
you're looking for GNOME for Slackware -current, I would recommend looking at
these two projects for well-built packages that follow a policy of minimal
interference with the base Slackware system:

There is also Dropline, of course, which is quite popular. However, due to
their policy of adding PAM and replacing large system packages (like the
entire X11 system) with their own versions, I can't give quite the same sort
of nod to Dropline. Nevertheless, it remains another choice, and it's _your_
system, so I will also mention their project:

Please do not incorrectly interpret any of this as a slight against GNOME
itself, which (although it does usually need to be fixed and polished beyond
the way it ships from upstream more so than, say, KDE or XFce) is a decent
desktop choice. So are a lot of others, but Slackware does not need to ship
every choice. GNOME is and always has been a moving target (even the
"stable" releases usually aren't quite ready yet) that really does demand a
team to keep up on all the changes (many of which are not always well
documented). I fully expect that this move will improve the quality of both
Slackware itself, and the quality (and quantity) of the GNOME options
available for it.

Folks, this is how open source is supposed to work. Enjoy. :-)

I don't know if your intent is to deliberately misinform, but I figured that I'd just point out that there is no mention of architecture within this ChangeLog. If you were to select words such as; "PAM" and "X11", then you might actually be correct about his alleged reasoning for the "suggestions" about which GNOME desktop to use. However, I question his ability to really be the judge, seeing as he's likely never used any GNOME build on Slackware aside from his own. But I digress.

Since he seems to be improving his X11 builds with this next release, and is even progressing towards modernizing the builds by moving Freetype2 and Fontconfig out of X11 and into their own packages (one of the things we've done in Dropline for years now - Yay progress!), then there is certainly some hope that we will not have to include our own X11 builds, *provided* that there aren't any more known unpatched bugs in his X11 builds that prevent GNOME components from working correctly (this and the formerly included Freetype/Fontconfig are the big issues).

Additionally, it's likely only a matter of time before PAM becomes a requirement for many pieces of software on Slackware (it already is, and he's temporarily able to get by with patching around it). In this case, we could likely stop building it on our own PAM (it's essentially a GNOME requirement these days, and other people on Slackware are busting their balls in an attempt to make stuff work without PAM and consolehelper), and we'd all be happy. That is, of course, unless it's simply done incorrectly. I think that Piter Punk has finally whipped Udev into shape for Pat, so we can probably stop including that one as well with Dropline 2.16.0 after Slackware 11.0 is released. Maybe someone will whip PAM into shape for Pat too, so he can finally start taking it seriously. Of course, it may just be "too complicated". Hard to tell what the reasoning is these days, seeing as there hasn't been a single legit security issue for several years now (see link below).