PART I: General questions about Slackware Linux

PART II: Installing Slackware

PART III: Slackware Linux system administration:

PART IV: not Slackware, but Slackware-related

PART V: about the FAQ

Of course you should! :-)

Slackware is a Linux distribution suitable for almost any user. It’s very stable and reliable, actively maintained, and has a very good track record for prompt security updates. Whether your intention is to setup a dedicated web server in a remote co-location facility, or a desktop workstation based on the popular KDE desktop environment, or any number of options in between, Slackware Linux is an excellent choice.

Slackware is generally considered the best choice for older hardware, such as i486-compatibles and early Pentium-based PCs. In fact a good option for many users wanting to learn GNU/Linux, who are not ready to do without their existing OS, is to install Slackware on an older machine. That way they can still have the operating system they’re already used to on a newer computer, while they learn their way around Slackware Linux on the console or lightweight windowing environment (or via network connection, telnet or ssh.)

However, if you’re not into reading documentation at all, you may wish to try another distribution. All Linux distributions have a learning curve, and if you won’t read the documentation, you probably won’t get Slackware Linux working to your satisfaction.

In choosing a Slackware version, it’s best to select the most current stable version that will run on the hardware you wish to install it on. Even the most current versions of Slackware Linux will run on very modest, or aging, systems, if you can do without a windowing environment (or can work with a lightweight window manager).

The exception is when installing on a very small hard drive: in such cases Slackware 4.0 or earlier is likely preferable, as you will be able to get more software installed per megabyte used. A very useful console-only Slackware 4.0 system can comfortably fit on a 100MB hard drive.

(quoted from http://www.slackware.com/book/)

The official guide to Slackware Linux, the Slackware Linux
Essentials, has been recently revised. If you want to be
able to read it online, you may want to visit the slackbook
website.  http://www.slackbook.org/ You may also want to buy
a printed copy, in that case please visit the Slackware Store!
http://store.slackware.com/

Pay special attention to the files in the root directory of the first installation disk. Some of the files of particular interest are listed here, but there are others that contain useful information.

A full installation of Slackware includes quite a bit of documentation:

There’s also the kernel configuration help. When configuring your kernel, you can get help on each configuration item. Not all items have help, but most do. The 2.6 series kernels add make help and offer a search function within make menuconfig: /<search_term>.

The scripts in /etc/rc.d are generally well commented and can explain a lot about what goes on when the system starts up, and the /etc/rc.d/rc.modules script briefly describes almost every kernel module that is listed in it.

There is, of course, the alt.os.linux.slackware newsgroup, populated by a variety of Slackware Linux users, with varying backgrounds and levels of expertise with most aspects of running a Slackware Linux system. No matter what problem you might encounter with Slackware Linux, there’s very likely someone who frequents this newsgroup with sufficient knowledge to try and help, or at least to help point you in the right direction to better help.

It’s probably worth your while to search the newsgroup using google, for older messages that may have expired from the news server you use. If someone else has had the same problem and resolved it already, you might be able to learn from the experience gained in that thread of discussion. http://groups.google.com/group/alt.os.linux.slackware

Slackware’s own Documentation http://www.slackware.com/ ftp://ftp.slackware.com/pub/slackware/ (.txt files in per-version directories) The Official Slackware Book http://www.slackware.com/book/

The Revised Slackware Book Project http://www.slackbook.org/

A Slackware Wiki http://www.slackwiki.org/

Wikipedia has an entry http://en.wikipedia.org/wiki/Slackware

Other FAQs about Slackware http://www.slackware.com/faq/ http://wiki.linuxquestions.org/wiki/Slackware-FAQ http://linuxtipps.sourceforge.net/index.php

How to Install and Run Slackware (written for Slackware-13, but not particularly version-specific; note reader comments and responses suggest that some of the author’s information and Slackware experience are dated, but the comments themselves help the article be more up to date; by itself, this article should at least help someone get running on a Slackware system pretty easily) http://www.maketecheasier.com/install-and-run-slackware-13/

An online book intended for new Slackware users, but complete enough to be useful to experienced users as well: http://www.slackbasics.org/

The Slack World has a list of Slackware-related links which may be useful: http://slackworld.berlios.de/links.html

Some general linux help sites http://www.linuxguruz.com/ http://www.justlinux.com/nhf/

The Linux Documentation Project http://www.tldp.org/

The kernel http://www.kernel.org/ http://www.digitalhermit.com/linux/Kernel-Build-HOWTO.html http://www.kernelnewbies.org/

Firewalls http://iptables-tutorial.frozentux.net/iptables-tutorial.html http://www.linuxguruz.org/iptables/ http://slackwiki.org/Category:Iptables_Scripts

X Window System http://www.x.org/

Software-specific documentation: most software packages have master web sites with documentation for current versions of their packages. These can usually be found by searching for the package name on http://sourceforge.net/ or http://freshmeat.net/

If all else fails … http://www.google.com/

Aside from the alt.os.linux.slackware newsgroup, there are many other places to discuss Slackware. A web search engine will provide links to many, but here are a few for your convenience:

LinuxQuestions.org - Slackware: "where Linux newbies come for help" http://www.linuxquestions.org/questions/slackware-14/

SlackwareHelp.org - "Slackers helping Slackers" http://slackwarehelp.org/

The old Slackware forums have now been incorporated as part of the userlocal.com forums. These can be found at http://www.userlocal.com/phorum/

The linuxiso.org Slackware forum http://forums.linuxiso.org/viewforum.php?f=25

The dropline.net Slackware forum http://forums.droplinegnome.org/viewforum.php?f=8

A public Slackware mailing list http://mailman.lug.org.uk/mailman/listinfo/slackware

IRC #slackware on irc.freenode.net.

Slackware’s own FAQ has the following to say on the matter: (http://www.slackware.com/faq/do_faq.php?faq=general#5)

It's usually our policy not to speculate on release dates, since
that's what it is -- pure speculation.  It's not always possible
to know how long it will take to make the upgrades needed and
tie up all the related loose ends.  As things are built for the
upcoming release, they'll be uploaded into the -current tree.
If the -current does not exist, it probably means we have just
released a new version of Slackware.  A new -current tree will be
formed shortly after the new release is made.

If you watch store.slackware.com, you may find an expected date of release for the next version of Slackware, especially if the release is getting close.

One hint that an official release is impending is that the HOWTOs, FAQs, and boot images are being prepared. Track the CHANGELOG of -current to get another rough idea for when a release might be forthcoming.

There is an official Slackware64 port, now available with the Slackware DVD at http://store.slackware.com/ (also available for download, as with the regular 32-bit Slackware).

In addition, to satisfy those that wanted 64-bit Slackware when it wasn’t officially available from Slackware, Fred Emmott produced an unofficial port, available from http://www.slamd64.com/.

There is an official Slackware port to the S/390 architecture, that appears to be actively developed and maintained. See http://www.slack390.org/ for details.

Over the years, there have been ports to the SPARC and Alpha platforms, but neither were kept up to date and were eventually dropped. Unofficial ports to the Alpha platform (and others?) have since appeared and disappeared, but none yet have been released as a complete Linux distribution ported from Slackware.

If you want to, you’re more than welcome to port Slackware to other architectures, but you can’t call it Slackware without explicit permission from Patrick Volkerding.

Contact information for Slackware is listed at: http://www.slackware.com/contact/

The /sbin/setup script in older Slackware versions allowed quick access to various system configuration scripts. The configuration scripts are still there, but "setup" is gone. You can run each of these independently:

package tools:
   pkgtool         install/remove/view packages, re-run setup scripts
   explodepkg      explode a Slackware compatible software package
   installpkg      install a Slackware compatible .tgz package
   makepkg         make a Slackware compatible .tgz package
   removepkg       remove an installed package
   upgradepkg      upgrades a Slackware .tgz package

system tools:
   adduser         easy way to add user accounts
   makebootdisk    create a SYSLINUX bootdisk
   mkrescue        create a rescue CDROM or floppy

configuration tools:
   fontconfig      select fonts for X
   make-bootdisk   create a bootdisk
   modem-device    select your modem device
   hotplug         enable hotplug on boot
   liloconfig      create the lilo.conf file
   mouse           select mouse and enable gpm
   netconfig       setup networking
   services        select which services to run on boot
   setconsolefont  select special console fonts
   timeconfig      select your timezone
   xorgsetup       setup X to suit your system
   xwmconfig       set your default desktop / window manager

Pkgtool can also run many of the setup scripts for you. Pick the last option before "quit" which says "choose installation scripts to run again." You pick the scripts to run with the space bar and arrow keys.

Also, note that xorgsetup and xwmconfig are both in /usr/X11R6/bin, which may not be in your path.

See the manual pages for each of these tools for additional details about running them, available options, etc.

Slackware doesn’t use or include PAM, though of course you’re free to install and use it on your own systems. You can get Patrick Volkerding’s own explanation for omitting PAM from the distribution in the slackware 9.1 Changelog, quoted here:

If you see a security problem reported which depends on PAM,
you can be glad you run Slackware.  I think a better name for PAM
might be SCAM, for Swiss Cheese Authentication Modules, and have
never felt that the small amount of convenience it provides is
worth the great loss of system security.  We miss out on half a
dozen security problems a year by not using PAM, but you can always
install it yourself if you feel that you're missing out on the fun.
(No, don't do that)

If you’ve read above, you know that Slackware doesn’t support PAM, but the most common way of configuring a linux client to authenticate against an LDAP server is to use PAM. What to do?

Well, one method is to use the nss_ldap software provided by PADL (http://www.padl.com). You’ll need to obtain and install the software yourself, but it’s a lot easier than installing PAM. The basic procedure follows:

[FIX ME: some LDAP directories can be configured to permit anonymous
         binding for the purpose of authenticating users.  The
         following steps should not be necessary in those cases]
- Obtain from your LDAP server admin an LDAP account that has the
  ability to read (at least, write is helpful) all of the appropriate
  login information.  In particular, this account must have at least
  read access to the userPassword attribute of all accounts to be used
  on the Slackware client.
- Configure this DN in ldap.conf as rootbinddn.
- Create a file, /etc/ldap.secret, and add the rootbinddn's password
  (cleartext!) to the first line of the file.  Add a trailing newline
  to the password.

That’s all you should need to do - no restarting of daemons should be needed.

[FIX ME: does this entry still apply?                          ]

The OpenSSL packages provided with Slackware (versions 8.0 through
9.0's -current dated December 2, 2002) don't work with Jabberd.
Jabberd reports the error:
mio_ssl.c:93 Could not create SSL Context: error:140A90A1:SSL
routines:SSL_CTX_new:library has no ciphers
When it loads up and attempts to use your SSL key.
The fix is to download the OpenSSL source and compile it yourself,
with a standard ./configure && make && make install.  It will go in
to /usr/local/ssl, not interfering with the Slackware SSL packages at
all.
make clean in your Jabberd source directory then

./configure --enable-ssl && make

and Jabberd should work properly with OpenSSL now.

Unlike almost all other distributions, Slackware doesn’t ship with a default .bashrc, so no such file appears by default in your home directory. There is nothing special or magical about this or any dotfile (hidden configuration file). Simply create a .bashrc file with the editor of your choice. The contents generally boil down to setting variables and shell options, and defining aliases and/or functions, as well as executing whatever commands you’d like. See the bash manual page for details.

Because it isn’t. One person controls that which is called "Slackware", and that one person 1.) didn’t want to include it, or 2.) didn’t think about it. In either case you can possibly get an authoritative answer by contacting Slackware directly (see http://www.slackware.com/contact/ for details). The people on the alt.os.linux.slackware newsgroup do not have a say in which software gets included with Slackware.

Yes. You need to load the loop.o module in your kernel or compile it into the kernel itself. insmod loop.o should do it. This will allow you to mount the ISO image as a pseudo disk and perform file management on it. I recommend mounting as read only just to protect the file.

To mount an ISO file, as root type: mount -t iso9660 -o ro,loop filename mountpoint

where filename is the link to or full filename and extension of the ISO image, and mountpoint must be an existing directory onto which to mount the image.

Then, you can cd to mountpoint and read the contents of the file directly!

The reasons for changing to X11R6 (X.org) from XFree86 are given in the Slackware 10 ChangeLog:

+--------------------------+
Sun May 30 01:06:39 PDT 2004
[...]
x/: Switched to X11R6.7.0 from X.Org.  Thanks to those who sent
    comments to x[at]slackware.com.  Seems the community has spoken,
    because the opinions were more than 4 to 1 in favor of using the
    X.Org release as the default version of X.  I think I've heard
    just about every side to this issue now, and it was only after
    careful consideration and testing that this decision was made.
    It's primarily (as is usual around here) a technical decision.
    Nearly everyone else is going with X.Org and it seems to me
    that sticking with XFree86 it spite of this would be asking for
    compatibility trouble (indeed, we saw some issues between X.Org
    and XFree86 4.4.0 until a few things in XFree86 were patched).
    I also noticed that the ATI Radeon binary drivers designed for
    XFree86 4.3.0 do not work with XFree86 4.4.0, but do work with the
    X.Org release.  Something I'm *not* in favor of is dragging around
    two nearly identical projects, so XFree86 4.4.0 has been moved
    to the /pub/slackware/unsupported/ directory on the FTP site.

For these partitions to be writable by an unprivileged user, you need to pass options to mount (via the command-line or fstab). There are several combinations of options you can give. Some examples follow, but the mount manual page gives more complete details, lists additional available options, and provides examples of its own.

Any of these methods can be combined (e.g using uid, gid & umask together to let the whole group write to the drive). As mentioned above, see the mount manual page for additional details.

See also http://slackwiki.org/Windows_Partitions for more information.

NTFS is a moving target and while read support for it is mature, write support isn’t. If you enable write support on your NTFS partition there is a high probability that you will corrupt the partition and make all or part of your data there inaccessible in either Linux or Windows. However, if you’re feeling brave, you can do this by enabling write support in the kernel module. In the 2.6 kernel you’ll find this option here:

Symbol: NTFS_RW [=n]
  Prompt: NTFS write support
    Defined at fs/Kconfig:733
    Depends on: NTFS_FS
    Location:
      -> File systems
        -> DOS/FAT/NT Filesystems
          -> NTFS file system support (NTFS_FS [=m])

[FIX ME: Someone please confirm this part ...]
You'll also need to explicitely mount the drive read-write.  The
following works for me.  Just change your mount points and partition.

mount -t ntfs /dev/hda1 /mnt/ntfs -o rw

Slackware automatically adds a user authenticated via the console to certain groups such as audio and cdrom. However, the graphical login managers shipped with Slackware don’t support this feature. You’ll need to manually add those users to those groups, or change permissions on certain /dev files.

Although there may be someone on the alt.os.linux.slackware newsgroup who knows enough about the derivative distribution you’re using, please keep in mind that readers of the newsgroup are likely not as familiar with the derivative ditribution as they are with Slackware. There’s a very good chance that the distribution you’re using has its own support channels, and its own user community that may be able to provide better help with that distribution than the folks who frequent alt.os.linux.slackware can.

That said, if you believe that a post to alt.os.linux.slackware is likely to get the help you’re looking for, or you’re unable to get sufficient help from the derivative distribution’s own user community, you’ll find that the more clearly you describe the problem, without forgetting to mention which Linux distribution you’re using, the easier it will be for others to try and help.

Slackware is one of the few major linux distributions that can still install fairly easily on many older computers including Pentiums and 486s. (is this still true with Slackware-13.x?) While bz2 might offer slightly better compression of packages, the amount of time these older machines take to decompress bz2 files is far greater than that required for gz. Thus, Slackware has traditionally used gzip for compression of its packages. With the release of Slackware-13.0, the distribution now ships packages compressed with "xz" instead, in an effort to find a true compromise between compression ratio and decompression performance.

KDE-4.2, as distributed with Slackware-13.0, includes a file indexing daemon that runs by default. Strigi is designed to provide full file indexing in KDE that’s supposed to perform better than alternatives. However, the Strigi File indexer included with KDE-4.2 consumes excessive amounts of resources, and does so almost constantly. This causes the system to appear to bog down. If you are experiencing performance problems, such as the hard drive constantly in use, or the CPU always active, you may try disabling Strigi by going into the System Settings, going to the Advanced tab, and Desktop Search. From there, you can disable the file indexer. This should speed things up considerably.

Find the Slackware mirror nearest you from the list on Slackware’s web site, at http://www.slackware.com/getslack/

The following sites also provide lists of Slackware mirror sites: http://www.abnormalpenguin.com/slackware-mirrors.php http://alphageek.dyndns.org/linux/slackware-mirrors.shtml

This link shows a history of Slackware versions: http://slackware.cs.utah.edu/

Installation instructions are included with each Slackware CD set, in the form of a small booklet, and as text files on the installation CD.

The Slackware web site also has helpful documentation at http://www.slackware.com/install/

Newer versions of Slackware (since Slackware-8.1) include an installation HOWTO document, in the root directory of the first installation disk, and also available at the following URL:

ftp://ftp.slackware.com/pub/slackware/slackware/Slackware-HOWTO

The HOWTO should also be available at the various mirrors. See the "getslack" URL above for more details on mirrors.

Slackware has never given the option to install via FTP. The only network-based installation option is NFS. You could configure NFS on an already running system, and download the installation files there, to install onto your target system. Unless you already use NFS for other reasons, or you have no other option (for example no CD drive on the target system), this approach may not be worth the effort.

This question will normally receive as many different answers as there are people answering it, and any of them might be right for your target system. Still, what’s presented here is a generally accepted approach to partitioning a single hard disk for a Linux installation.

The easiest way to partition your system is of course to not partition at all. Or rather, to create a swap partition at the beginning of the disk, and leave the rest as one large partition for /. Note, however, that the BIOSes on most older systems were unable to boot from a partition that occupied space beyond some number of cylinders on the disk. On such systems, the first disk partition should be created so that it is no larger than that limit, and this partition should be the one containing the operating system kernel, (many people mount this as /boot, while others move the system kernels out to the "/" root directory and use this smaller first partition as "/")

It is usually necessary to have at least a swap partition, and there are various reasons why you might decide to divide various other parts of the system onto separate disk partitions.

For example, it can be a good idea to put /home and /usr/local on separate partitions. That way, you can upgrade to a newer version of Slackware without having to overwrite your personal data and the programs you installed from source. It’s still advisable to take complete backups of any information you consider important, but having these directory trees as separate filesystems will help ensure that upgrades and new installations won’t cause you to lose your data.

Instead of creating two partitions for /home and /usr/local, you can also create only one. Create a directory /usr/local/home on this partition, and then make a sym-link from /home to /usr/local/home. This way, /home and /usr/local make use of the same partition, which means you don’t have to decide which partition you want to make the largest.

The next question is usually how big the various other partitions should be. This of course greatly depends on what you want to install and how you want to use your system. A full install of Slackware 10.x (with KDE) takes some 4-5GB, to which you will have to add some free space. So for a full install, you will need to give / at least 4GB (5GB would be better). You can of course use less if you don’t do a full install. The rest of the hard disk can be split up between /home and /usr/local.

It might help you gain additional insight to read A Quick Guide to Linux Partition Schemes, at http://www.maketecheasier.com/quick-guide-to-linux-partition-schemes/

The trick is to know two numbers.

First determine how much memory the system will use under its expected peak loads. Most often this number will be an educated guess under the best circumstances, so it’s worth being generous here.

Second, determine how much physical memory you can afford to put into the computer system, or that the system will be able to recognize and use. This may be already determined by the memory that is presently installed in the target system.

Swap space should be at least as large as the difference between the above two numbers.

There have been various "rules-of-thumb" over the years that swap space for a Unix or Linux system should be equal to an even multiple of the amount of physical RAM on the system (with, in some cases, an extra amount large enough to hold a copy of the system kernel). On operating systems that produce a kernel+core file when recovering from a system crash, such a rule of thumb is reasonably applicable, but Linux isn’t such a system, so the only real requirement for swap space is determined by the difference between how much memory the system will need to use, and how much physical memory can be installed into it.

Note that the Linux kernel’s suspend option uses the swap partition to store the memory image. If you plan to use this feature, be sure to setup an appropriately-sized swap partition.

Well, there is a logical reason for the rule of thumb that swap should be 2 times the amount of RAM, it just doesn’t apply to Linux that’s all.

On systems derived from older versions of BSD (I’m not sure exactly which version of BSD, but Ultrix and SunOS 4 are examples of commercial UNIXen for which this is true) the swapping algorithm allocates swap space immediately for all memory allocated by the kernel. Which means when a program is loaded, swap space is encumbered. Also when a program calls brk() or sbrk() for more memory, swap space is immediately allocated.

Hence at an absolute minimum, for the system to even use its RAM, there must be a 1:1 relationship between RAM and swap space. If the system is to have virtual memory beyond the limits of physical RAM, swap must be increased beyond 1:1. The size of virtual memory is exactly the size of swap.

Hence the "Rule of Thumb: Swap should be twice the size of RAM", which allows just about exactly twice as much memory for loaded programs as there is physical RAM. (And that was about the maximum load it was reasonable to put on a Sparc Station 1 used for general purposes…)

However, Linux has never used that algorithm for swapping/paging of memory. Linux doesn’t allocate memory at all when brk() or sbrk() are called! It waits until that memory is actually used. Hence, no matter how much RAM or swap a system has, you can call malloc() (which calls sbrk() to get more memory) and get 2.1Gb of memory! (One way of looking at this, is that it is faster. Another way is that BSD is safer.) Each individual page of that memory will only be actually allocated if it is used. And the way Linux does that allocates either RAM or swap. Hence while the total virtual memory for BSD is the size of swap, for Linux it is the sum of RAM and swap.

The immediately obvious result of that difference is that a BSD system with swap space twice the size of RAM has virtual memory twice the size of RAM, but a Linux system with swap space twice the size of RAM has virtual memory three times the size of RAM.

OK, how do we calculate swap space for Linux?
=============================================

(See "How much swap space should I use?" above)

With the old BSD swap algorithm, swap space would be the amount of virtual memory desired, and that is actually unrelated to RAM size other than it must be greater than RAM. However, in a practical sense with typical systems and typical use patterns, it made little sense to have more programs swapped out than were running due to the slowness involved. And of course that "rule of thumb" was developed when disk space was relatively more expensive than it is now. (But RAM was more expensive too, and I’ve heard of Sun workstations that had 16Mb of RAM and 300Mb of swapping which were running modeling programs that took a month to finish. Today, I can do that on my home machine in what, an hour?)

What happens if that rule is applied to Linux?
==============================================

On todays systems a home work station might have 256-512Mb of RAM, and probably never goes into swapping! Why would I want 1500Mb of virtual memory on my box with 512Mb of RAM? The reason I bought 512Mb of RAM is because I’ve never ever used that much VM that I know of!

On the other hand there are servers which might have hundreds of processes that are always running, but are inactive 99% of the time. Why put in 2Gb of RAM, when only 256Mb of those programs are actively being used? In that case it makes sense to use 256Mb of RAM and have 1800Mb of swap!

Instructions, caveats, and notes for performing an upgrade between Slackware versions are provided in the file UPGRADE.TXT on the first disk of the Slackware distribution. This file should be your first source of information, followed closely by CHANGES_AND_HINTS.TXT on the same disk, but also check on the same disk for other .TXT files that may be relevant to your situation.

Upgrades between major version releases, however, usually represent significant changes, and may prove to be more work than they’re worth. You may be better off installing the new version from scratch, on the same disk as the previous version you have been using. This may mean needing to take backups of certain directories, such as /home, /usr/local, /var/spool/mail, /var/spool/cron/crontabs, and others, and reloading them after the new OS has been installed.

If it does, plan for the same situation to occur the next time you want/need to upgrade Slackware on your system, and adjust your partition layout accordingly. One suggestion would be to keep /home and /usr/local, and perhaps /var/spool/mail if you have many users or lots of email stored there, on separate partitions that are not involved when you perform the OS installation, but instead added to /etc/fstab later. You would still need to backup then restore files from /var/spool/cron/crontabs, (for example) and perhaps other directories.

Whichever method you use, your best bet would be to have a well thought out plan before you start, and a complete backup of all files you consider important on your system, taken right at the moment before you start the upgrade. Even if you’re keeping important files on separate disk partitions that won’t be overwritten during the installation, having a backup will ensure that if you need to, you’ll be able to recover from any mistakes. More importantly, not having a backup ensures that you’ll wish you had taken one before starting.

If the package you’re looking for is one that ships with Slackware, see the mirror nearest you from the list at http://www.slackware.com/getslack/

Software compiled and pre-packaged for Slackware, but not by Slackware can often be found at http://pkgs.org/

Remember, you need to do your own checks to make sure you have the right libraries installed for packages you install, whether you obtained them from a Slackware mirror or from the Linux Packages site. installpkg won’t do that for you.

There are also build-script repositories where you can find scripts that will help you build Slackware-compatible packages on your own system for software that isn’t included with Slackware. These enable you to audit the build process used to create the package and to avoid broken packages built on other systems with different libraries installed. They’re also an easy way to install software that may not be available in pre-packaged form on your Slackware system. For a popular example, see the SlackBuilds.org project at http://slackbuilds.org/. There’s also a really convenient front-end for the SlackBuilds.Org collection of scripts available at http://sbopkg.org/.

Yes. There are a number of options for doing this. Slackware ships an rpm package with recent versions of the distribution, and also includes a tool, "rpm2tgz" to convert RPM packages into a format that can be installed with Slackware’s own installpkg tool.

There is also a package called Alien (http://www.kitenet.net/~joey/code/alien.html) which will convert files between many package formats.

It’s worth considering, however, that you will have more control over what goes onto your system, how it’s compiled, and where it’s installed if you download and compile software from the original source code, or install it (if available) from the main Slackware archives.

[FIX ME: is this still necessary, with Slackware's rpm package?]
If you *insist* on using RPMs with rpm, and are having troubles,
here are some tips:

Create the directory /var/lib/rpm
Initialize RPM with rpm --initdb
Install packages with the --nodeps switch

Slackware’s pkgtools package provides the tools for package management. The following is quoted from its description file:

Included are the command line utilities "installpkg", "removepkg",
"makepkg", "explodepkg", and "upgradepkg" that install, remove,
build, examine, and upgrade software packages.  Also included are
"pkgtool", a menu based program for installing packages, removing
packages, or viewing the packages that are installed on the system,
documentation (man pages), and a few other system admin scripts.

pkgtool is a front end to most of the other scripts, but those that are used most often are:

installpkg: installs a Slackware package
removepkg:  removes an installed package
upgradepkg: upgrades an installed package to a newer version

Most of these scripts are in action when you first install your system, and are installed along with the rest of Slackware’s packages. They are very easy to use: to install a Slackware package called "package.tgz", type "installpkg package.tgz". To remove it, type "removepkg package".

Much more documentation is available in the manual pages for these scripts.

There are also third-party package-management tools for Slackware, such as slackpkg, slapt-get, swaret, and others. Used carefully, any of these have been very helpful to some, but others have found that as much as they can help, they also can damage a Slackware installation if the user is not careful about certain details. As with most software, careful study of the included documentation will be required to get the most out of any of these package management tools.

If you installed the software as a standard Slackware package, you can use removepkg to remove the files in the package. Remember that removepkg doesn’t do any dependency checking, so if you remove a package that your system depends on (such as glibc, but there are others) you will run into difficulties.

If you installed the software from source, there are a few options. Sometimes there is an uninstall target, in which case you should issue a "make uninstall" command from within the package’s source tree.

If you haven’t already installed software to help you manage software installations, any of the following might be worth your while to investigate. Look in Slackware’s /extra packages on the installation CD for these or any other similar packages.

CheckInstall: http://checkinstall.izto.org/

protopkg: ftp://ftp.slackware.com/pub/slackware/unsupported/packages/utils/

slacktrack: http://www.armedslack.org/projects/downloads/slacktrack-1.29_1-source.tar.gz

No. Slackware doesn’t come with any auto-updating tool like apt-get or up2date. There are some third-party updating tools like swaret, but most people download and update packages by hand or through a custom script. (A search of the alt.os.linux.slackware archives on Google Groups will bring up a lot of scripts that you could utilize for your own uses).

It’s worth noting that patches and updates to Slackware are announced in the Changelog and/or the slackware-security mailing list, so it would be a good idea to keep an eye on both of these to find out about new updates.

The slackware-security list can be found here: http://www.slackware.com/lists/

The changelog for the stable version of Slackware can be found here: http://www.slackware.com/changelog/stable.php?cpu=i386

The changelog for the "-current" development version of Slackware can be found here: http://www.slackware.com/changelog/current.php?cpu=i386

It’s commonly considered the best way to find this information is through searching Slackware’s MANIFEST.bz2 file. You can find this file on the Slackware CD in the slackware directory or on a Slackware mirror. (Note that in older distributions, the file is called MANIFEST.gz, and is found in the slakware directory).

One way to search MANIFEST.bz2 is to type the following:

less -p filename MANIFEST.bz2 (press n for next match found. Press q to exit. If you’re not using Slackware to run this command, you may have to decompress the bz2 file with bunzip2 or "bzcat MANIFEST.bz2 |less".)

Sometimes a file won’t be listed in MANIFEST.bz2, (usually because it’s created by a package’s doinst.sh). In this case, see if it’s installed on your system already, using the following command:

grep -rl filename /var/log/packages

Most of the time, if you are searching for a program, the following should produce more relevant results:

grep -rl filename$ /var/log/packages

In all distributions of Linux, hardware support is provided by the kernel or user-land software. If a hardware device doesn’t work, then either

a) the software that uses the device is misconfigured,
b) hardware support for that device hasn't been built into your
   kernel (the driver might be experimental, so check for this
   if you need to build a new kernel),
c) linux doesn't support your hardware at all, or
d) the thing (or the connector) is broken.

Examine these possibilities in the above order to diagnose the problem. If the device works with another distribution, items c) (probably) and d) (certainly) can immediately be ruled out. Various "Linux-on-CD" distributions can be useful for troubleshooting hardware problems. Most common hardware devices that have support in Linux are usually detected and configured by such distributions, and you might be able to learn how to make your Slackware Linux installation work with your hardware by reviewing relevant configurations from CD-based Linux distributions.

There are various hardware-compatibility lists for the different components of a Linux system, (ALSA and X have their own hardware-compatibility lists, for example). There is a general (though perhaps outdated) hardware-compatibility list in the Linux Documentation Project web site:

http://www.tldp.org/HOWTO/Hardware-HOWTO/

The directory /var/log contains the subdirectories packages, scripts, removed_packages, and removed_scripts. The *scripts dirs contain the doinst.sh scripts that were run on install/uninstall. The *packages dirs contain the package lists from installed and uninstalled packages. These last files contain the package name, size, location it was installed from, description, and file list. These are plain text files, so using basic tools like grep, awk, and less will get you the information you need.

If you install a kernel from "extras" or "testing" on the Slackware distribution CD, you will need to manually install the matching kernel modules from the same directory. Installpkg will install the package containing the kernel modules if you take this route.

You might want to harden your system, setup hardware, etc…

The following URLs provide useful tips for fine-tuning and administering a Slackware Linux system:

[FIX ME: let's put more links to tips & tricks pages here.
         the URL at www.therockgarden.ca isn't even Linux-specific,
         and could be replaced with one more specific to Slackware
         systems.                                              ]
http://members.cox.net/laitcg/slack.htm
http://www.therockgarden.ca/security/securing_unix.html
http://www.cochiselinux.org/files/system-hardening-10.2.txt

There is the slackware-security mailing list, http://www.slackware.com/lists/

The slackware-security mailing list also has a corresponding web page: http://www.slackware.com/security/

The changelog for the stable version of Slackware can be found here: http://www.slackware.com/changelog/stable.php?cpu=i386

Users testing Slackware-current can monitor the ChangeLog file at http://www.slackware.com/changelog/current.php?cpu=i386

Users of the S/390 port will likely want to monitor its changelog instead, at http://www.slackware.com/changelog/current.php?cpu=s390

Slackware’s startup sequence is pretty clearly described at the following URLs:

http://www-128.ibm.com/developerworks/linux/library/l-slack.html http://openskills.info/infobox.php?IDbox=1042 http://www.bilbos-stekkie.com/slack_init/en/index.html

What follows may also help:

Unlike most other Linux distributions, which use System-V style init scripts, Slackware’s boot-time startup scripts are largely (though not entirely) based on the BSD-style rc.* scripts. At the same time, Slackware uses a System-V style init program, with numbered run-levels. It’s an unusual combination, but it works well, and once understood, is very easy to manage.

Both SysV scripts and BSD scripts are human-readable, in that they are shell scripts, not compiled programs. The main difference is in how the scripts are designed.

System-V style scripts tend to be designed to start or stop a single service or system function per script, and take arguments like start, stop, restart, and others, depending on the service it’s controlling. So you could say something like /etc/init.d/bind start to start BIND, and /etc/init.d/bind stop to stop BIND.

SysV-style init scripts also tend to use symlinks in per-run-level directories to organize the boot sequence: in /etc/rc.d/rc.4/, there might be various symlinks to actual scripts in another directory. The symlinks are named like S10network, S25xdm, and so on, where the S is used to mean the service is started when the system enters that run level, and K means it is stopped ("killed"). The sorting order of the link names define the order that the scripts run. The example scripts mentioned here would have "S10network" run before "S25xdm".

BSD-style scripts tend to place the startup commands for multiple related system functions and services into relatively few scripts. This makes it easy to setup the network interfaces and start network daemons, for example, from one or two scripts.

In the BSD-style, processes are killed (with SIGKILL, which usually causes a graceful shutdown) when the system shuts down, without explicitly calling a series of scripts in any particular order to shut services down.

Since Slackware uses a SystemV-like init program, however, a system shutdown is synonymous with switching to run-level 0 (or run-level 6 for a reboot, but from the point of view of the shutdown stage of a reboot, these are identical, and indeed Slackware’s "rc.0" script is a symbolic link to "rc.6"), and there is an init script (/etc/rc.d/rc.0 for a shutdown, and /etc/rc.d/rc.6 for a reboot, but note that these are the exact same script in a stock Slackware installation) that runs when that run level is entered. This script takes care of gracefully shutting down any services that were started when the system booted.

If a system administrator needs to change the order of the startup or shutdown sequence, on a BSD style system, the appropriate sections of a small number of scripts need to be modified, moved, added to, etc. On a SystemV-like system (including most Linux distributions), this change is done simply by renaming symbolic links in per-run-level directories, pointing to the init scripts. Disabling a service can easily be done by removing execute permissions on the appropriate init script, or renaming it so that the symbolic links in the per-run-level directories no longer point to it.

Slackware’s approach here is much closer to the BSD style, though in recent years, several individual per-service scripts have crept in, making it easier to disable the starting of a service by removing execute permission from the appropriate script, or renaming it, but changing the startup or shutdown sequence (which isn’t likely to be done in most installations) still involves modifying the larger rc.* scripts.

As of Slackware 10, /etc/X11/XF86Config has been replaced with /etc/X11/xorg.conf. This is because Slackware 10 and later uses the X11 (X.org) system as opposed to XFree86. The syntax and layout for both files is virtually identical.

It appears every 20 minutes (by default) as a way for the system to confirm that syslogd is running. This has some value on systems used as servers, but you may wish to turn it off (or change the time interval) on a desktop workstation. To do so, use the -m option to syslogd in /etc/rc.d/rc.syslog: -m 0 will turn off the message entirely, and -m 60 will change the interval to 60 minutes, for example. Check out man syslogd for more details.

As of Slackware 9.2, sound devices belong to the audio group. Users are automagically part of this group (through /etc/login.defs), so all users should (hopefully) have access to the sound device by default.

On older Slackware versions, simply adding users to the same group that owns the sound device(s) resolves this problem.

See also the above answer to "Why am I unable to get sound after setting up a graphical login program". Graphical display managers do not apply settings in /etc/login.defs (they may have their own settings). Again, the simplest fix is to add users with physical access to the system to the same group that owns audio devices (group "audio" on a stock modern Slackware system).

As with most things Linux, there’s more than one way to accomplish this, and either method may seem more appropriate for some systems than for others.

The most common method is to edit /etc/inittab. This file configures init which runs programs that use the virtual terminals (among other things).

Change the line that says id:3:initdefault: to id:4:initdefault:

Then cause init to re-read the file by signalling it with either of the following commands (run as root):

kill -HUP 1 telinit -q

It’s also possible to use LILO to boot straight to an X login. (i.e Boot to runlevel 4).

Create a stanza in /etc/lilo.conf that uses the "append" command to tell the system to boot into runlevel 4 (which Slackware uses for launching X at boot-time):

image = /boot/vmlinuz root = /dev/hda1 label = Linux-GUI append = "4" read-only

You can also tell LILO which runlevel to use at boot time. Assuming you have lilo configured to prompt and wait for a boot command, you can type <label> <runlevel>. The label is whatever you set "label" to in /etc/lilo.conf. For example, if you have set your kernel’s label to "linux", you would type "linux 4" to boot into the X system (or "linux 1" to boot into single-user mode, though that should really be described in a separate FAQ entry).

Because /etc/rc.d/rc.S overwrites this file at boot time. Comment out the following lines in that file to change this behaviour:

# Setup the /etc/motd to reflect the current kernel level:
# THIS WIPES ANY CHANGES YOU MAKE TO /ETC/MOTD WITH EACH BOOT.
# COMMENT THIS OUT IF YOU WANT TO MAKE A CUSTOM VERSION.
echo "$(/bin/uname -sr)." > /etc/motd

There are many guides on compiling a new kernel. Here are some links to a few:

http://www.digitalhermit.com/linux/Kernel-Build-HOWTO.html http://www.slackbook.org/html/system-configuration-kernel.html http://www.sysdesign.ca/guides/linux_kernel.html http://www.cmm.uklinux.net/steve/kernelhow.html

Also read /usr/src/linux/README

It’s possible that you didn’t select the framebuffer options in the kernel, which give you the nice high-resolution in the console. To fix this, go back in to "make menuconfig" or "make xconfig", and under "code maturity level options", select the "Prompt for development and/or incomplete code/drivers". Then under "Console drivers", go in to "Frame-buffer support" and then select "VESA VGA graphics console". Then recompile and boot.

2.6 Kernel users may also want to take note of the following, which can be found in more detail at http://www.linux.org.uk/~davej/docs/post-halloween-2.6.txt

[FIX ME: Include the "menuconfig" text that the user sees      ]
  Make sure your .config has
   CONFIG_INPUT=y
   CONFIG_VT=y
   CONFIG_VGA_CONSOLE=y
   CONFIG_VT_CONSOLE=y

A lot of people have discovered that taking their .config from 2.4
and running make oldconfig to pick up new options leads to problems,
notably with CONFIG_VT not being set.

echo $DRIVER_OLD >> /etc/hotplug/blacklist

Slackware uses the hotplug feature of recent 2.4.x kernels to automatically load drivers for detected hardware. If you want to use a different driver for your hardware, such as an ALSA sound card driver, you can disable the hotplug system from using the previous driver in this way.

As an alternative you can disable the hotplug feature. As root, type:

chmod -x /etc/rc.d/rc.hotplug

or remove the entire package with:

removepkg hotplug

Hotplug is especially useful for PCMCIA and USB devices. For more information see the Linux-hotplug Web site: http://linux-hotplug.sourceforge.net/

In Slackware 11.0 and later versions, the hotplug subsystem has been replaced by udev when using 2.6.15 and newer kernels. Documentation on udev is relatively scarce, but this site should be of assistance:

[FIX ME: We need more links for udev hints and such            ]
  http://www.reactivated.net/writing_udev_rules.html

It’s also prudent to note that module loadtime options and blacklisting is now handled in /etc/modprobe.d/* files instead of the old /etc/modules.conf (for 2.4.x kernels) or /etc/modprobe.conf (2.6.x). A reasonable set of default values should be present in a normal installation of Slackware 11.0, but blacklisting of modules that you don’t want to load is done in /etc/modprobe.d/blacklist, and any load-time options you wish to specify makes the most sense in /etc/modprobe.d/options (this file does not exist by default - you must create it).

Slackware now uses the ALSA sound drivers by default. The ALSA drivers are not native to the 2.4 kernel, so they need to be recompiled, reinstalled separately from a Slackware package, or be moved before kernel compilation. If you have installed and are using a 2.6 kernel, then this issue shouldn’t effect you, as long as you’ve enabled ALSA support within the new kernel configuration.

There are several ways in which you can restore the ALSA drivers on a newly compiled 2.4 kernel. Note that only one of these methods should be necessary.

If you have (re)installed a 2.4.x kernel of the same version number that shipped with your Slackware distribution, the following options are available to you:

If you have upgraded to a newer kernel than shipped with the Slackware version you’re using, then re-installing the ALSA sound driver (and possibly library and utilities) from source is your only option. The good news is that it isn’t difficult to do.

It has been noted that if you enable module version support in the kernel, (CONFIG_MODVERSIONS=y), and recompile the alsa drivers, you’ll be able to use the drivers with different kernel versions without the need to recompile again.

Did you just rebuild the system kernel?

If your rebuilt kernel doesn’t include the same drivers built as modules as the kernel it replaces, you need to remove the modules directory from the kernel it replaces, and replace it with modules built specifically for this new kernel. The easiest way to do this, while still ensuring that you can back out of the change and return to the previous working kernel (and its modules) should things go wrong, is to rename the relevant modules directory prior to calling "make modules-install" during the kernel building process:

cd /usr/src/linux
make -s modules
mv /lib/modules/`uname -r` /lib/modules/`uname -r`.`date +%Y%m%d`
make -s modules_install

This problem can be avoided altogether by setting the "EXTRAVERSION" variable for your custom kernel. In 2.4, edit the top-level Makefile, in 2.6 change the kernelrelease name from "make menuconfig".

The easiest way is to type

xwmconfig

But note that if you have made changes to the files in /etc/X11/xinit, these changes will be lost because xwmconfig replaces files in that directory, rather than edits them. If you did make changes to such files, make a point to create a backup copy of the files you editted. You can then use these to merge your changes into the files created by xwmconfig.

If the window manager you want is installed but not listed by xwmconfig, you can usually add its name to the last line of ~/.xinitrc like so:

echo "exec windowmanager" >> ~/.xinitrc

Alternatively, to get a window manager listed on the xwmconfig screen, look in /etc/X11/xinit/ and create a similar xinitrc file for your window manager in that directory.

The command is being run out of /etc/profile (or /etc/csh.profile), which call additional scripts like so:

for file in /etc/profile.d/*.sh ; do if [ -x $file ] . $file fi done

This translates to "Run every file in the /etc/profile.d directory if the filename ends in .sh and it’s executable." There’s a file called bsd-games-login-fortune.sh which has a call to the program fortune. fortune is the actual program that prints out the weird saying or quote when users login.

If you don’t like the message, disable it by Removing execute permission on the script permission (this needs to be done as root): chmod a-x /etc/profile.d/bsd-games-login-fortune.sh

You’ll need to do the same with bsd-games-login-fortune.csh, so that users on your system that use csh or tcsh as their login shell will not see these fortune messages either.

This is because X does not know how many buttons your mouse has, and what to do with the extra buttons. There are two buttons (up and down) per wheel. If the scroll wheel can also be pressed, or you’re emulating three buttons (pressing left and right mouse buttons at the same time to create a middle mouse button), then you have 5 buttons, for most basic scoll mice. To configure X to use your mouse correctly, ensure the following is in your /etc/X11/xorg.conf

Section "InputDevice"
        Identifier      "Mouse0"
        Driver          "mouse"
        Option          "Protocol"      "IMPS/2"
        Option          "Device"        "/dev/psaux"
        #Option         "Buttons"       "3"
        #Option         "Emulate3Buttons"
        Option          "Buttons"       "5"
        Option          "ZAxisMapping"  "4 5"
EndSection

You may need to edit Device and Protocol to suit your mouse. If its a PS/2, then use IMPS/2. Should you be using a Logitech device, either mouse or trackball, use MouseManPlusPS/2 as your protocol. More information can be found in /usr/X11R6/lib/X11/doc/README.mouse

Please note that this is not a Slackware-specific issue. This problem has been encountered with other Linux distributions, and is discussed on the various Linux forums.

Console users are automatically added to the cdrom and plugdev groups at login via /etc/login.defs. The intention was that HAL and auto-mounting of removable devices would just work without the need for admins to manually add users to the plugdev and cdrom groups, but due to the way dbus functions, this turns out not to be the case.

When the messagebus service is started, it reads the content of /etc/group and then determines whether users have rights to mount removable devices based on that. This is why the reload option was added to /etc/rc.d/rc.messagebus, as you need to make it aware of any changes to /etc/group if you happen to edit that file to add users to plugdev, cdrom, power, or video groups while dbus is running.

The solution is to manually add users to the necessary groups (cdrom and plugdev) - do not rely on the output of groups(1) to determine whether a user is in the appropriate group as it pertains to dbus and HAL.

Every so often you’re going to run across something strange and unusual, perhaps so strange and unforeseen that you immediately think someone else must have done it, and that can only mean that your computer must have been compromised.

The first thing you should always remember is to remain calm. Very often people suspect a system compromise when there is some other more likely explanation for the observed behaviour. You may have created the behaviour yourself without knowing it, or you may have stumbled across something slackware has been doing all along without your knowledge.

Of course your system might indeed have been compromised. But how can you be sure? The following checklist can guide you through some simple checks that will help you confirm whether the behaviour you’re seeing from your system is expected, something you created, or the result of a system compromise (or some other event):

[FIX ME: are any commonly modified tools being forgotten?]
- Copy over known good versions of commonly trojaned tools you'll
  need including bash, find, fuser, id, last, lastlog, ls, lsmod,
  lsof, netstat, ps, tcsh, top, and w.  These files are often
  trojaned to hide a hacker's activities.  In fact, it would be
  wise to create a CD (or use other write-once media) containing
  known good versions of these programs, so that if you ever need to
  investigate a suspected compromised system, you can proceed using
  the copies of these tools that you saved earlier.  If the system
  has indeed been compromised, it isn't at all unlikely that some
  or all of these will have been replaced with modified versions.

Note that the Slackware installation CD (especially disk 2 in
some older versions of a full Slackware distribution) can make an
excellent emergency investigation/rescue disk in the event that
your system has been compromised and you suspect some important
binaries may have been over-written.

After all the above have been checked, if you still haven’t found any indication of compromise, you can be pretty confident that either a) your system wasn’t actually compromised, or b) it was compromised by an intruder who is very skilled at covering up his or her tracks!

Have a look at the following web page for a guide:

http://www.cs.ucr.edu/~jbyrne/vmware.htm

Yes, with a little work.

1) Read the Cryptoloop-HOWTO in the Linux-HOWTOs dir, or from http://www.tldp.org/. You MUST patch and modify source code, so be careful.

2) Get the source for the util-linux module, and unpack it. BE SURE TO USE THE SLACKWARE SOURCE which has a config file already setup. DO NOT UNINSTALL any packages since util-linux is part of a larger group of packages.

3) Get the two patches mentioned in the HOWTO and apply. Current versions of Slackware ship util-linux-2.12a and the patches are for 2.12, but they work.

4) compile using ./configure make and su -c "make install"

4a) You may also need to add modules to your kernel and recompile it as well as modifying startup scripts (I use rc.local for loading the crypto modules).

5) follow the directions for formatting your encrypted disk. One nice thing about Cryptoloop is that you can create a virtual disk (i.e. a fixed size file that you can mount as a filesystem) to keep sensitive data in your home directory or any other place, without having to waste a whole partition.

Good Luck!

6) As of 2005, there is a very easy to set up kernel module for encrypting filesystems. It is based on FUSE and it is called EncFS. It can be compiled and installed without recompiling your kernel.

No. DO NOT MIX PACKAGES FROM -CURRENT INTO A STABLE RELEASE!

There are a few notable exceptions to this that will work fine, but for the most part, the above applies. Either upgrade your system completely to Slackware -current, or stick with the stable release packages (plus applicable patches).

If you decide to upgrade to -current, you have a lot of reading to do. Start with UPGRADE.TXT in the -current tree, and also have a look at http://slackwiki.org/Release_Changes

The following URLS are good references:

The SlackBuilds.Org maintainers cite, as their rationale for this configuration:

Software installed by a means other than packages needs to go to /usr/local so that it’s easier to track. Ideally, you build it in /usr/local/src (and leave the source directory there) so that if you ever need/want to uninstall it, you can go back to the source dir and call "make uninstall" (assuming the uninstall target is present in the software’s Makefile).

On the other hand, when you build a package of some software and then install that package, the whole maintenance issue is, well, not an issue. The package can be managed just like the remainder of the packages installed on the distribution.

This FAQ currently resides at: http://www.therockgarden.ca/aolsfaq.txt

An HTML-converted version can be found at: http://l0k1.free.fr/aolsfaq.html

It is based on and hopefully will ultimately replace the FAQ-O-Matic version at: http://wombat.san-francisco.ca.us/cgi-bin/fom

Sure, but if you make any changes to the copy you’re mirroring, please make a point to give proper credit for the source you started from.

Contributions are encouraged, though no promise is made that they will be accepted verbatim. Any contributions that are accepted, will of course result in due credit given. To contribute to the FAQ, send your suggested updates or new entries either to the FAQ maintainer directly (, as of this writing), or to the alt.os.linux.slackware newsgroup.

This is a list of people who have contributed to the answers in this FAQ, in no particular order, other than the order in which their contributions were found when looking to compile this list. Wherever possible, listed here are contribitors' full names or best-known aliases. Otherwise, the email address used when the contribution was made is listed. Anyone who is listed by email address but would prefer to be listed by full name, or whose name is misspelled should contact to submit the correction.

Patrick Volkerding (quoted without permission)
Keith Keller
[apropos@linuxmail.org]
[rob0@gmx.net]
[pete4abw@comcast.net]
[simon@no-dns-yet.org.uk]
[signup@users.pc9.org]
[ronmon@bellsouth.net]
[myrow@eskimo.com]
Jack S. Lai
[gerall@chromebob.com]
Faux Pseudo
Alan Hicks
Cameron Kerr
Athlon Rob
Floyd Davidson
Francesco G
Alan_C
Sylvain Robitaille
Mikhail Zotov
Dave Jones
Two Ravens
Grant Coady
slakmagik
Robby Workman
Lew Pitcher
notbob
Aaron W. Hsu
Hans de Bruin