I hope that
Part I of the Stealth Desktop series was a good start for our
series about using Slackware as a desktop. I would like to thank
our kind readers for the feedback, encouragement and
I would like to stress that this article series was in the
making long before the release of Slackware 10.0, so most of the
examples will appear as being geared to Slackware 9.1 and 9.0.
However, please bear in mind that Slackware is very consistent
among versions so you have a good chance of applying what is
shown here to the newest version. As far as myself is concerned,
I've transitioned elrohir and sombragris to
10.0 over the last weekend; and so far, so good. (On the other
hand, denethor still runs 9.0, without a flaw.)
In Part II we will focus on the hardest part: making sound and
video work. Sound is not especially difficult; but video is.
Fortunately, after this step, it is an easy ride. Now, do not
despair: I said that this part is hard, not that it is arcane,
difficult to understand, or for “Unix wizards” only. It is hard
because it differs so much from other distros which have, for the
most part, better tools to do the task. But you can certainly do
it and you have a very good chance to succeed.
The first boot leaves you with only one user in a text-only
setup. When booting, look closely at the boot messages to check
for signals of trouble (and, especially if you are using
Slackware 10.0, check whether the parallel port is recognized).
As the installer and administrator of the box, having the boot
messages printed on screen instead of being hidden by a so-called
“friendly” bootsplash is not only a bonus; it is also one less
possible point of failure —the bootsplash package requires a
specially patched kernel and I've grown to distrust such an
expensive move to achieve such a frivolous gain.
Once in the login prompt, log in as root. Once you complete
the login, you will be notified that you have mail. You can read
your mail using the mail command, which will show you
two messages. Both of them are important and it can be said that
both of them give good suggestions; but one of these, a message
from Patrick Volkerding, deserves special attention. Go and
read it carefully. And then save it for future reference. It
has a lot of useful information, and chances are you'll need some
of it one day.
One of the first tasks you should do is checking the init
system. The init system —the set of system scripts that handles
the task of starting and shutting down the machine— is located
in /etc/rc.d/, and it is one of the striking differences between
Slackware and other distros. The Slackware init system is based
on the BSD init style, instead of the more complex SysV init that
is used in distros such as Fedora or Mandrakelinux. In stark
contrast with the SysV style init, the Slackware init scripts are
much simpler and leaner, and they're actually
understandable even if you don't know a thing about shell
scripting. They are written with the clearest syntax possible,
and they're well commented, so it is unlikely that you would get
lost in these files.
Now we are going to investigate whether we should make changes
to one of these init scripts. Therefore, the one obvious
suggestion before going further is: have a backup ready.
This would save you a lot of grief in case anything goes wrong.
In order to edit the script, you might use any editor; my
personal preference lies between joe and jed,
resorting sometimes to the Midnight Commander's built-in editor
for a quick edit.
The init script you should especially check is
/etc/rc.d/rc.modules/, which loads extra drivers into
the Linux kernel. You can load each module by uncommenting the
relevant entries. (In shell scripts, comments are denoted by a
hash mark, #. Deleting the hash mark makes the
line active.) As for what should be edited, it is left to you,
and it will depend on whether you have some hardware that was not
detected by the kernel or some module you want to load because
some program requires it. A special case is when you happen to
run Slackware 10.0 and have some need to use the parallel port
(especially for printing). If this is so, I advise you to
uncomment the parallel port modules; as far as I can tell, the
kernel of Slackware 10.0 comes with parallel support disabled
(Why? I don't know.).
The portion below would be the uncommented part of
/etc/rc.d/rc.modules for my machines. I use the APM part
for sombragris, my laptop, and the rest would be
required by a Slackware 10.0 setup:
#### APM support ### # APM is a BIOS specification for saving power using several different # techniques. This is mostly useful for battery powered laptops. /sbin/modprobe apm #### PC parallel port support ### if cat /proc/ksyms | grep "[parport_pc]" 1> /dev/null 2> /dev/null ; then echo "parport0 is built-in, not loading module" > /dev/null else if [ -r /lib/modules/$RELEASE/misc/parport_pc.o -o -r /lib/modules/$RELEASE/misc/parport_pc.o.gz -o -r /lib/modules/$RELEASE/kernel/drivers/parport/parport_pc.o -o -r /lib/modules/$RELEASE/kernel/drivers/parport/parport_pc.o.gz ]; then # Generic setup example: /sbin/modprobe parport_pc # Hardware specific setup example (required for PLIP and better # performance in general): #/sbin/modprobe parport_pc io=0x378 irq=7 fi fi #### Parallel printer support ### if cat /proc/ksyms | grep "[lp]" 1> /dev/null 2> /dev/null ; then echo "lp support built-in, not loading module" > /dev/null else if [ -r /lib/modules/$RELEASE/misc/lp.o -o -r /lib/modules/$RELEASE/misc/lp.o.gz -o -r /lib/modules/$RELEASE/kernel/drivers/char/lp.o -o -r /lib/modules/$RELEASE/kernel/drivers/char/lp.o.gz ]; then /sbin/modprobe lp fi fi
Once you're finished with the editing, reboot in order to have
these changes brought into effect. Of course, you could avoid
having to reboot by loading each module manually; but rebooting
helps you to see the whole process in the context of the init
system works. I prefer to do things that way.
Second order of business after logging in as root is to check
whether the sound is working. Slackware 9.1 ships with ALSA 0.9x,
which is an excellent sound architecture (Slackware 10.0 ships
ALSA 1.0). However, ALSA has all the channels muted by default.
First unmute the sound and set appropriate values using
alsamixer, which is shown in Figure 2. Then check your
sound using aplay:
# aplay /usr/share/sounds/phone.wav
If the sound system is working, you will hear a phone ringing with the following console output:
Playing WAVE '/usr/share/sounds/phone.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
In that case, you should save the mixer settings as the default ones using the alsactl store command.
Usually, the sound system works without problem at the first
boot. If it doesn't, check the documentation, available locally
at /usr/doc/alsa-*, and online at the ALSA website, which may have
some pointers useful in solving your sound problems.
Even after unmuting the sound card, it is possible that normal
users might be unable to use the sound card. If that's the case,
then check the ownership of the sound card device (usally
/dev/dsp), and then add any relevant user to the same
group of the sound card (in my system, that's the 'audio' group).
We'll see how to add and manage users and groups in Part III of
Lastly, I would like to comment about a strange problem that
I've experienced in elrohir and its subsequent
workaround. While working as a normal user, I had no trouble
accesing the sound card in the console. However, sound was muted
in KDE. After a lot of checking, I've found that somehow KDE
manages to put a control called 'VIA DXS' to zero. The solution
is: (1) Use KMix to unmute the relevant control and to set all
the controls according to your preferences; and (2) in the KDE
Control Center, go to Sound & Multimedia > Mixer, check
“Load volumes on login” and click on “Save Current Volumes”.
Setting up the X Window System is always a tricky undertaking.
This is furthermore complicated by the fact that Slackware does
not offer good tools to perform this task. None of the X setup
tools available in Slackware is comparable to the config tools
offered by other well-known distros such as Mandrake or Fedora.
You might, however, have more than a fair chance to get a good,
working and functional X setup with a little patience.
There are at least six ways to configure X in Slackware
without having to resort to completely edit a config file from
scratch. (Note: Settings specific to X11R6.7/Slackware
10.0 are shown in parentheses.)
Now we want to set the specifications of the monitor. The two critical parameters are the vertical refresh rate, which is the rate at which the the whole screen is refreshed, and most importantly the horizontal sync rate, which is the rate at which scanlines are displayed. The valid range for horizontal sync and vertical sync should be documented in the manual of your monitor. If in doubt, check the monitor database /usr/X11R6/lib/X11/doc/Monitors to see if your monitor is there. Press enter to continue, or ctrl-c to abort.The problem here is that the file referenced
This ends the most difficult part of our setup. Here is an
area where Slackware really needs better tools; or
perhaps it is the X Window System that needs better configuration
tools so that users and administrators would not be so reliant in
distro-specific tools. However, I hope you are able to produce a
good setup with the pointers presented here; and I trust that a
little guidance and experience can go a long way.
Our next article will focus on how to add and manage users and
groups, install fonts, and how KDE can simplify those tasks
greatly. Keep going!
Eduardo SÃ¡nchez is a Contributing Editor of
Open for Business. He is married to Gloria, and lives with his
wife in AsunciÃ³n, Paraguay (South America), where he works
as pastoral assistant of Villa Morra Baptist Church. You can
reach him at firstname.lastname@example.org.