Slackware is the oldest linux distribution, the first one I ever used and the one I currently use day-to-day. I've used many other operating systems and spent many years only using windows, but I feel most at home with slackware.

I love slackware because it gives me a tremendous sense of freedom and although no OS can be described as "simple" it does have a simplicity that rewards any effort in understanding and configuring it. You might like to read my experience of starting out with slackware, though some of the facts are a little out of date now.

Below is a collection of notes I've made (currently in a jumbled order). Some are specific to slackware or KDE 3 or 4, but others are applicable to any linux or indeed *nix. They are mostly for the command line. A split line is indicated with a backslash.

Contents

1. 1 The find command
2. 2 Subversion and netbeans
3. 3 Working with ISOs
4. 4 Dual head
5. 5 xorg.conf
6. 6 Formatting and partitioning a USB stick
7. 7 Kernel compiling
   1. 7.1 Step 1 - obtain the source
   2. 7.2 Step 2 - prepare and configure
   3. 7.3 Step 3 - compile the kernel
   4. 7.4 Step 4 - install the kernel
   5. 7.5 Step 5 - Reboot and troubleshooting

The find command

The find command is one of the most useful commands in *nix and I'd probably say it's the most obvious example of where the command line completely trumps anything you can do via a GUI especially when you come to -exec option. Unfortunately, its syntax is rather confusing and difficult to remember, though it is ruthlessly logical. It's best to approach it via examples and then dive into the man and info pages for gritty detail.

To find a file called donkey.png somewhere under /home/fred simply do


To find all files in and below the current directory ending in png do


Notice that the search string is quoted with ". This is necessary because otherwise the command line's shell will jump in and match the wildcard characters such as * before the find command sees them (understanding why can be rather brain frying).

The find command takes on a whole new dimension with the -exec option. Instead of merely printing out the name of the file, it runs a command to do something with the file. A simple example would be:


This finds each file ending in png and performs ls -l on it. {} represents the matched filename and \; marks the end of the command to be executed.

I often use -exec to clean up a directory tree by deleting matching files. For example, to remove all png files in and below the current directory do


Obviously, this must be used with great care, especially if you need to remove directories with rm -rf.

Other options that are useful are -type for finding files or directories or -mtime for finding files by when they were last modified. There are many pages of find examples on the web, e.g. this one.

The main problem with find is that it is slow. To get round this you can use alternatives based on an indexing approach. This speeds things up by building an index of files and keeping it up to date so that the search is not on the file system itself but on some kind of efficiently constructed database. The downside of this is that you need create the database and keep it up to date and it may consume quite a bit of disk-space. For indexed search on the command line you can use slocate, under KDE you can use strigi and under gnome you can use beagle. Another option with a GUI that I've recently heard good things about is recoll. 

Subversion and netbeans

Assuming you've got subversion installed (it comes with a full install of slackware), then to create a repository do

where /some/path should be a directory that already exists and myrepo is the name of the repository to be created.The repository will contain all the files, directories and other versioning information. You will rarely have to look at the repository directly because the svn command will handle all interaction with its contents.

The next step is to configure access to the repository. There are many ways to do this, but for a simple repository on a single machine that isn't directly exposed to the internet (e.g. behind a NAT firewall) you can get started quickly by putting just one line in the file /some/path/myrepo/conf/svnserve.conf:


You can then start the svn daemon by issuing the following (I do this as root):

The netbeans IDE has excellent support for subversion and there is a good tutorial for it.If you've configured subversion as above, then the connection string you should use in netbeans (and elsewhere) is just:

svn://localhost/myrepo

Working with ISOs

To create an iso file from files on a hard disk do something like


To create an iso file from a real CD


Under KDE 3.5.x, I used k3b to burn CD, but you can also do it from the command line using something like this (/dev/hdc was the cd/dvd burner on my laptop):


To burn a DVD from the command line on my slackware 13.0 system with a USB external CD/DVD burner, I issue this command:


where /dev/dvd is the DVD device (it's a symlink to /dev/sr0 in my system) and somefile.iso is a file prepared for a DVD. The dvd-compat option ensures maxium compatability (see man page for more information).

Dual head

My experience with this was restricted to using two screens with one laptop with a single desktop spanning both the internal screen and an external one. There are several ways to do this, but I either use xorg.conf or xrandr. The first two links below refer to forum posts where I detailed how I used xorg.conf and the third link explains how to use xrandr:

xorg.conf

Recent versions of xorg do not require the existence of the file /etc/X11/xorg.conf, but it is still sometimes necessary to create one. To do so, issue the following command as root when X is not running:


and the file /root/xorg.conf.new will be created with the auto-detected options. Copy it to /etc/X11/xorg.conf and edit to suit your needs. (In my case I replaced "nv" with "nvidia" in the device section to get the proprietary nvidia driver to work.)

Formatting and partitioning a USB stick

Most of the following was gleaned from this site.

Plug in the thumb drive. It's light will blink and then stay on. To find out what device it is assigned to see what system messages were recently issued using:


It will normally be /dev/sda or sdb or sdc depending what other "scsi" devices are present. Make very sure you've correctly identified it and don't mistype it any commands below: typing sda instead of sdb in some of the commands below could wipe you main hard drive! In what follows replace x by the correct letter.

Examine its partition table using:

To repartition either do it the line-by-line way:


OR the semi-GUI way


This only writes the parition table it DOES NOT create the file system. To do this you need this command:


or for FAT32

but mkfs.vfat might not work on slackware, in which case do


To stop linux checking the file system do this


I had trouble partitioning a sandisk usb stick with fdisk or cfdisk
because it had some wierd invisible parition that could
only be seen in windows. This partition was for some
feature called U3, which I wasn't interested in. The solution
was to use a manufacturer's tool to remove the U3 stuff
and it's annoying super-hidden partition.

Kernel compiling

Compiling a kernel probably isn't as difficult as you might think (I've no idea who you are, so please excuse me if I'm wrong), but it can get rather involved, much can go wrong and it can consume a bit of time. The Linux Kernel in a Nutshell is an excellent introduction to the subject and well worth a read before you plunge in, or perhaps after you've dipped your toe in a bit. Here's my version of how to compile the kernel. My advice is to start with the source of the kernel you are currently running, tweak its configuration a little, compile, install and test. In other words, take small, careful steps from a known-good starting point.

Step 1 - obtain the source

The recommended way to do this is to obtain the source code for the linux distro that you're currently using. This usually comes in the form of a package that will be unpacked into some location on your disk. In slackware the kernel source is under /usr/src/linux and I compile in that directory even though wiser folk than me say not to do it. (I do this because I trust the wise folk behind slackware who reassure me there's no problem.) Your other alternative - and this will be much more work - is to download the kernel source from one of the mirrors listed at kernel.org, home of the linux kernel. If you do this, you'll have to create your kernel config from scratch and figure out what hardware support you'll need.

Step 2 - prepare and configure

Once you're in the kernel source directory (/usr/src/linux on my system) then you need to do a little preparation. If you've got a .config file in place that you'd like to be your starting point (use ls -a to see a file that starts with .) then copy to some other location and then issue
This will clean up your build environment, i.e. delete any remnants of a previous kernel compile. This will delete your .config, so if you copied one elsewhere, now is the time to copy it back. The you can alter the config file:
This will allow you to navigate through the myriad of kernel configuration options via a semi-GUI environment (known as curses). I find this quite a pleasant way to work, but if you prefer a proper GUI then try make xconfig. Note: if you're changing to a newer version of the linux kernel then you'll need to use make oldconfig to make sure all the new kernel config options are included. After you're done configuring the kernel, you might be interested to look at .config - it's actually quite human-readable, though don't be tempted to edit it manually.

Step 3 - compile the kernel

To compile the kernel simply issue this command:
The V=1 produces a slew of information to be printed out as it compiles (V for verbose). If this offends you then just omit V=1. This step can take some time and will depend on how many features you asked to be included in the configuration process and also on the speed of your computer. It usually takes me 15 to 45 minutes.

Once this is done, you'll need to build the modules:

Step 4 - install the kernel

This next bit can be automated and only the first line is strictly necessary, but it's worth doing all three lines for completeness:
You will probably want to replace mynewkernel with something more meaningful, like the version number of the kernel and perhaps a word to remind you why you created it e.g. 2.6.29-ext4 would remind me that I'd compiled that kernel so that the ext4 was built into it. My boot manager (I use lilo, but grub is most common these days) expects the kernel image to be a file called vmlinuz in /boot.  Rather than copying over the previous kernel image file, I usually use symlinks. This means that I'd issue the following commands
Boot loaders usually allow you to specify more than one kernel that you can boot from via some kind of simple start-up menu. I always keep one entry pointing to a known-good kernel should my new kernel turn out to cause a problem (which happens a lot). As I use lilo I have to issue the lilo command as root at this point. Also you might need to build an initrd - an initial ram disk - to hold modules that are needed early-on in the boot process. I'm not going to go into the details of this - it's best to consult documentation for your distro on this matter.

The final part of the installation is to install the kernel modules:

Step 5 - Reboot and troubleshooting

The final step is to reboot and hope that your new kernel works. If not, you have to restart the computer (hold the power button in for 5 seconds or so if all else fails) and reboot choosing a previous known-good kernel and go back through the kernel compiling process and figure out what went wrong. If you can't boot the known-good kernel then a live CD or USB stick is a handy thing to have to hand.

Certain software may refuse to work with the new kernel because it has a module that was built against the previous kernel - I've experienced this with Virtual Box and proprietary video drivers. To fix this you need to recompile and reinstall such kernel modules once your system is up and running with the new kernel. In some cases this will be as simple as re-running an installation script, but in all cases instructions will accompany the source of the afflicted module and you should notice that the process isn't too dis-similar from compiling the kernel itself.