AppEngine and Extensions

I was able to basically leave the site alone on AppEngine for several months--through about September 2009. In that time, I came up with a Firefox extension to make its use more convenient.

The extension allows you to quickly get a shortened URL for the page you're currently looking at, and a couple of context menu items let you get a short URL for things like specific images on a page. Also included in the extension is a preview for 2ze.us links. The preview can tell you the title and domain of the link's target. It can tell you how much smaller the 2ze.us URL is compared to the full URL. Finally, it displays how many times that particular 2ze.us link has been clicked.

That as all fine and dandy. It was the second Firefox extension I had ever written, and it's still running strong. In June or July of 2009, I started working on a little program to make it easier for me to interact with Twitter the way I wanted to. This was a great opportunity for me to incorporate 2ze.us into the application so any URL I wanted to post to Twitter would automatically be shortened for me, using my own shortener.

Porting to WebFaction And PHP

Anyway, around the end of September 2009, I noticed that there were a lot of problems with 2ze.us. It was slow and sometimes completely unresponsive. Certain URLs would redirect to their full URLs, while others wouldn't. The Firefox extension stopped working nicely. Oh yeah, and AppEngine rolled back to a previous revision of the code without me telling it to. That's when everything just died. It didn't take long for me to decide to migrate my project from AppEngine onto my awesome WebFaction hosting.

At this point, I was faced with a small dilemma: keep the code in Python, or port it to PHP. I opted to port it over to PHP, because I didn't want all of the overhead of a full Django instance for a site that needed to be very zippy. And I was unacquainted with other Python options.

By early October 2009, I had managed to turn the project into a PHP beast, running on Apache. It was a lot more responsive than AppEngine ever let 2ze.us be. There were a few bumps along the road, what with the extension and Twitter client relying on various parts of the site. Eventually it got to a point where I could just let it sit and work.

Chromium Extension

Sometime around the end of December, I decided to write another extension for 2ze.us, only for Google Chrome and Chromium this time. This extension isn't quite as feature-packed as its Firefox brother, but it gets the job done.

Clip2Zeus

Shortly after "completing" the Chromium extension, I had what seemed like a pretty original idea. Who knows if it really is, but I still haven't seen another tool quite like the one that I made as a result of this idea. I thought, "Now, why should I need to install an extension in each Web browser I use on each computer I use? Is there a better way?"

The answer came quickly: a standalone, desktop application. Write one program that handles shortening URLs for you. My laziness told me to make a program that monitors your system clipboard for URLs. If a URL is detected, try to shorten it, and update the clipboard contents in place. Boom. Done. All extensions become useless beyond things like the URL preview (which is very useful, imo).

The next question I asked was, "Do I make it platform-dependent? Should I stick it to the majority of computer users and write my tool for Linux only? For OSX only? For, uh... Windows only?" Again, an easy question to answer. Support them all or don't even bother writing the application.

A week's worth of midnight hacking saw the birth of Clip2Zeus 1.0a. It's a cross-platform compatible desktop application that does exactly what I just mentioned. When it's running and detects a URL on your system clipboard, it will try to shorten it and update it in your clipboard. If you copy a block of text, the application will only modify the URLs in that block of text--meaning the block of text will still be in your clipboard, but it will have shorter URLs.

I use the program every day at work (on OSX). It's been very fun for me to see a short URL any time I copy a nasty URL to my clipboard. Imagine that; I'm a big fan of my own work...

Tornado

Lately, I've noticed that the site was getting kind of slow again. Sometimes it would take several seconds for Clip2Zeus to shorten URLs in my clipboard, when it was normally instantaneous. Every once in a while, Clip2Zeus would completely fail to connect to the website.

One of my friends has asked me a lot of questions about the Tornado framework in the past months. I had read a few things about Tornado when it was open-sourced last year, but I didn't really feel the need to dabble with it. These questions prompted me to tinker a little.

Last night I re-ported 2ze.us to Python, using the Tornado framework this time. So far I'm very impressed with its responsiveness. The framework offers a lot of neat little utilities, and it is very fast (as reported by dozens of other reputable sources).

On top of the speed increase that came with the transition to Tornado, my RAM usage on WebFaction has come down by nearly 100MB. Just by turning off the one Apache-backed website. Now I'm nowhere near my RAM cap! Wahoo!!

Enough rambling. Like I said at the beginning of this article, a lot has been happening with this project in the past year. I didn't even think about all of the time I put into projects related to my simple little side project. Looking back, I'm quite satisfied with how things have unfolded.

Statistics

Here are some simple statistics for 2ze.us. Since March 2009...

• 5,252 URLs have been shortened using 2ze.us
• 2ze.us links have been clicked 198,267 times
• 315,951 URL characters have been turned into 11,532 characters

In April 2009...

• 217 URLs were shortened
• 2ze.us links were clicked 617 times

In February 2010...

• 1,182 URLs were shortened
• 2ze.us links were clicked 32,830 times

Not too shabby for a side project.

Getting Started

One of the first things I would encourage you to do is follow along. It will make the concept sink in much faster, and you will probably see other applications very quickly. Please note, however, that if you're following along exactly, it could be a very time-consuming process. I will be using 3 virtual machines as I write this, but you could just as easily use 5, 10, or 100,000. Likewise, you could eliminate the virtual machines altogether if you're in an environment with several physical computers.

One virtual machine will act as the "master" server, or the one that will be configured first. The other virtual machines will act as "slave" servers, which will simply receive configuration updates that happen on the master server. We will also modify this behavior to be a bit more interesting toward the end of the article.

Virtual Machines Galore!

First off, I will create some basic virtual machines using the net install version of Debian 5.0.3. I really only need to create 1 VM and then clone it a couple of times. I am willing to furnish my virtual machines to those who are interested in using them. I will install some additional software in the VM to make sure the demo works smoothly. Among the packages that I will install are:

• Python
• Mercurial
• OpenSSH server

Initialize a Repository

Once I have all of that set up in my virtual machines, I will initialize a Mercurial repository on the master server to maintain the configuration files that I am interested in. Let's just use the /etc directory for the time being. There's a pretty good chance that most of our system-wide configuration will all be contained somewhere beneath /etc.

cd /etc
hg init

Now let's have a gander at the files that we can have Mercurial manage for us:

hg st

Wow! That is quite a set of files, isn't it? Thankfully, they should mostly be plain text files. Mercurial is very efficient at managing text files. Let's now add all of the files in /etc to our repository, so they can be tracked and easily pushed out to other systems.

hg add

That command will happily add everything that hg st printed. Obviously, we can get a little more picky about what we do and do not add to our repository, but that's not the goal of this article. Now, this step merely tells Mercurial that it needs to pay attention to changes in these files. The files have not yet been committed to the repo. Let's do that, so we have a backup of our configuration files in their pristine state:

hg ci -m "Initial import"

The -m "Initial import" is just a comment, to describe what happened to warrant a commit to the repository. It is for your use and the use of anyone who has access to your repo.

Clone The Configuration

Now let's try to push the configuration we just committed on the master server to one of the slave servers. Since my virtual machines are all essentially in the same state, there should be no conflicts, right? Try running the following command on the master server:

hg push ssh://root@slave1//etc
root@slave1's password:
remote: abort: There is no Mercurial repository here (.hg not found)!
abort: no suitable response from remote hg!

Blast! We can't simply push the configuration files out to another computer. For that to work, we'd first have to have the repository itself exist on the slave server. Let's try this another way. One the slave server, run this command:

hg clone ssh://root@master//etc /etc
root@master's password:
abort: destination '/etc/' is not empty

Doh! Mercurial won't let us clone the repository from the master server! That's because Mercurial wants to clone to a new directory, with nothing already in it. One way to get around this hairball of a show-stopper is to just copy the repo using conventional UNIX utilities. Execute this command on one of your slave servers:

scp -r root@master:/etc/.hg /etc/

The .hg directory contains all of the repository information, and it's really all we need to snag in order to clone the repository. This might not be the most elegant solution in the world, but it will suffice for the time being. Once the scp command completes, we should have a full copy of the configuration file repository. Run this command to verify:

hg st

If your setup is anything like mine, you'll probably have a few files that are listed as being modified. Chances are that these files will vary from host to host anyway, and they are probably not worth keeping in a version control system. That would just be begging for conflicts.

I wrote an extension for Mercurial that should make this part of my tutorial a little less hacky. On your other slave server, run the following commands:

hg clone http://bitbucket.org/codekoala/hgext /root/hgext
echo "[extensions]" >> /root/.hgrc
echo "neclone = /root/hgext/neclone.py" >> /root/.hgrc

This extension gives you a new Mercurial command called neclone (N. E. Clone, or "not empty clone"). As we saw earlier, Mercurial doesn't let us clone a repository into a directory that is not empty. This extension allows us to do that. It works almost identically to the regular clone command... takes the same options and everything.

Still on your second slave server, run these additional commands:

hg neclone ssh://root@master//etc /etc
cd /etc
hg up -C

The last step is optional, and soon to be included as part of the extension. It will update your working copy to the latest revision in the repository. Beware that it overwrites any uncommitted changes you may have made to files that are tracked by Mercurial.

So now both slave servers should have a clone of the configuration repository from the master server.

Being Picky

Let's start to be a little picky about the files we are tracking in our repository. Some of the files appears as being modified on my slave server after copying the .hg directory from the master server are:

• adjtime
• alternatives/pager
• alternatives/pager.1.gz
• mailcap
• network/run/ifstate
• udev/rules.d/70-persistent-net.rules

I think it's safe to remove these from the repository, to avoid conflicts with other systems. To tell Mercurial to stop tracking files it is tracking, without actually deleting the file from the filesystem, you can use the following command:

hg forget adjtime
hg forget mailcap

And so on. Go ahead and do that for each of the files that appeared to be modified on your slave server immediately after copying the .hg directory. I'm going to add /etc/hostname to the list of files to forget too.

After doing that, each of those files should appear as being marked for removal when you run hg st. Don't worry, this is normal. The files will not be deleted from the filesystem, but they will be deleted from the repository. Go ahead and commit those changes to the repository on your slave server.

hg ci -Am "Removed some files from version control"

Now let's push those changes out to the master server:

hg push
abort: repository default-push not found!

Since we copied the .hg directory directly using scp, our slave won't know where the changes need to go when we run the push command with no explicit destination repository. To fix that, let's create a file in /etc/.hg/ called hgrc on the slave server. In that file, put the following text:

[paths]
default = ssh://root@master//etc

The hg push command should now push directly to the master server. Yay! The problem we face now is that every other slave server in the group is out of date. How can we fix that? We'll use Mercurial hooks.

Automating Config Replication

Mercurial offers some very useful hooks that we can use to automatically push configuration changes out to each of our slave servers. We will use the commit and changegroup hooks to do the magic. Let's create a script that will live on the master server to take care of pushing our changes out to each slave server. Create a new file in /etc/ on the master server called propagate.sh:

#!/bin/bash
hg up
for node in 'slave1' 'slave2'
do
    ssh root@$node "cd /etc; hg pull -u"
done

Let's also make sure this script is executable:

chmod +x /etc/propagate.sh

This script assumes that your /etc/hosts file or your nameserver are configured appropriately to allow slave1 and slave2 to be resolved to IP addresses. The reason we're SSH'ing into each slave server and using hg pull instead of simply using hg push ssh://root@$node//etc is because you can't force an update on a remote server using push. You can, however, request an update when you're using pull.

Obviously, this script is not the most sophisticated of scripts. It might work well for my demonstration, with only a few servers, but once you get beyond that it would be a nightmare to maintain the list of servers the script has to connect to. You can use whatever means you'd like to keep track of the servers you want to replicate your configuration to. I don't want to bother with all of the crap I'd get for suggesting one thing over another, so it's now your call.

Now it's time to configure the Mercurial hook to execute that script when the master server sees a changeset get into its repository. Open up /etc/.hg/hgrc on the master server, or create it if it doesn't exist. Make sure it has at least the following in it:

[hooks]
commit.propagate = /etc/propagate.sh
changegroup.propagate = /etc/propagate.sh

Let's try it out! Run these commands on your master server:

echo "" >> /etc/hosts
hg ci -m "Added a blank line to the hosts file"
root@slave1's password:
remote: Permission denied, please try again.
remote: Permission denied, please try again.
remote: Permission denied (publickey,password).
abort: no suitable response from remote hg!
Connection closed by slave2
warning: commit.propagate hook exited with status 255

Blast! The script failed because it wanted us to type in a password, but it was not in interactive mode. Let's fix that with a little preshared key magic. I won't go into the details about how this works, but the following commands on your master server should get us rolling:

ssh-keygen
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys2
scp -r ~/.ssh root@slave1:~
scp -r ~/.ssh root@slave2:~

For simplicity's sake, just accept all of the details and don't set a passphrase. These commands enable us to SSH into our slave servers without using a password. If you get an error such as:

remote: Host key verification failed.
abort: no suitable response from remote hg!

...it just means you need to manually log into your master server from the slave machine that threw that error. When doing so, you will have to answer "yes" to a question about the authenticity of the host you're logging into.

Testing It Out

It is now time to see if we can make a configuration change on one slave server and have it show up on the other slave server. Let's update the hosts file a little bit. Let's add the following line on the second slave server:

10.0.0.5        nonexistanthost

Now let's commit the change and push it off to the master server:

hg ci -m "Added a dumb line to the hosts file"
hg push

My system actually told me that that it had copied the change out to another host. I know because I saw these lines:

remote: pulling from ssh://root@master//etc
remote: searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files

Now when I look at the first slave server, I should see that new line in my /etc/hosts file. Also, the log on each server should have the same entry that I just made about adding "a dumb line to the hosts file."

Seem Like A Lot of Work?

A lot of what we just did probably seemed like more work that it is worth, right? Well, being a nerd typically comes with a few qualities. One quality which I have observed many a time in my most geeky of friends is that they will spend hours and hours up front on a program or script just so they can save 2 minutes in the future. They work hard to be lazy.

There is a lot of boilerplate configuration that takes place in this particular scenario. I realize that. What I haven't shared with you, though, is how I automated the boilerplate configuration as well as the propagation of configuration. I'm tired of putting this article off, so I will have to leave those details for another article. Sorry!

Why?! There's a Better Way (tm)

There is always a better way. Always. Go ahead and use whatever you feel is the most efficient method for keeping configuration files in sync across several computers. This is just one more option to add to your toolkit. Don't worry, I won't be offended if you don't like it or don't use it. It works perfect for me and it's free, and I just wanted to share!

The Installation

The first step when the installation program starts is to choose what language to use, after which you choose the type of installation you're going to be doing. Your choices are:

• New Installation
• Update
• Repair Installed System

You also have the option of installing "Add-On Products" from another media. At this step, I chose to do a new installation.

Next, you get to choose your time zone. The interface is very intuitive. You get a map of the world, and you click on the region you want to zoom in on. Once you're zoomed in, you can select a city that is near you to specify your time zone. Alternatively, you can choose your region and time zone from a couple of drop down lists.

After setting your time zone, you get to choose which desktop environment you want to install. Your choices are:

• GNOME 2.24.1
• KDE 4.1.3
• KDE 3.5.10
• XFCE 4.4
• Minimal X Window
• Minimal Server Selection (Text Mode)

I will choose to install GNOME because it seems to be the desktop of the future, especially with the hideous beast that KDE has become in the 4.x series...

Now you get to play with the partitioning. Usually the installer's first guess is pretty good, but I've got a different arrangement for my partitions, so I'm going to customize things a bit.

The next step is to create a regular, unprivileged user account for your day-to-day computing needs. This screen is pretty self-explanatory if you've ever registered for an e-mail address or installed any other operating system.

One thing that seems to have been added to OpenSUSE 11.1 is the option to use your regular user password as the root password. This is probably a nice addition for a lot of people, but I'd rather feel like my computer is a little more secure by having a different password for administrative tasks.

You're also give a few other options, such as being able to receive system mail, logging in automatically, and modifying your authentication settings. Other than the administrative password option, I left everything the same. If you're like me, and choose to have a different administrative password, you will be prompted to enter the new password at the next step.

Finally, you're shown a summary of the installation tasks that will take place. I'm going to customize my software selection just a bit so I don't have to do it manually after the installation is complete. For example, while I do like GNOME to a degree, I prefer to use KDE 3.5.x, so I will choose to install that environment as well just in case I need the comfort of KDE programs. Also, since I like to use the command line interface for a lot of things, I will choose to install the "Console Tools" package, just because it sounds useful. Lastly, I will choose to install a few development packages, such as C/C++, Java, Python, and Tcl/Tk. These changes bumped up my installation size from about 2.8GB to just over 4GB.

After reviewing the remaining tasks, all you need to do is hit the "Install" button. You will be prompted to verify your desire to install OpenSUSE, after which the package installation will begin. While the installation is taking place, you have the option of watching a brain-washing slideshow, viewing the installation details as it progresses, or reading the release notes.

The actual installation took nearly 40 minutes on my laptop. While this isn't necessarily a great improvement over past releases, I'm sure the story would have been much different had I not customized the software I wanted to have installed. The introduction of installation images a few releases ago drastically improved installation times. If you don't customize your package selection, you'll probably notice the speed difference.

When all of the packages have been installed, the installation program begins to configure your newly installed OpenSUSE for your computer, with a "reboot" in between. This is when all of your hardware, such as your network adapters, graphics adapter, sound card, printers, etc are probed and configured. Strangely enough, this step seems to take a lot longer than it does in Windows, which is usually not the case with Linux. What is OpenSUSE up to I wonder?

When all is said and done, the installation program finishes on its own and loads up your desktop.

Your Desktop

I thought it was interesting that I chose to install GNOME, but since I chose to install KDE 3.5.10 alongside it that's what it booted me into after the installation was completed. No real complaints, though, since I prefer KDE anyway. Nonetheless, I switched back to GNOME to stretch my limits all the more. At least the desktop took up the full resolution that my screen can handle, unlike the installation program and boot screen.

Things seem fairly responsive... nothing like Slackware though. I just received a little popup notification with an excuse for the lag I might be experiencing: the daily indexing has commenced and should be finished soon. Whatever it's up to, it's taking up a consistent 100% of my CPU. How nice. I hope whatever it's indexing ends up being useful.

Sound worked right from the get-go, which is nice. Hardware acceleration for my Radeon Xpress 200M doesn't work, nor does my Broadcom wireless card. These will be fixed soon.

/usr/sbin/install_bcm43xx_firmware
modprobe b43

wget https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/\
linux/ati-driver-installer-8-12-x86.x86_64.run

zypper in kernel-source gcc make patch

sh ati-driver-installer-8-12-x86.x86_64.run

rm /usr/lib/dri/fglrx_dri.so && ln -s /usr/lib64/dri/fglrx_dri.so \
/usr/lib/dri/fglrx_dri.so

cp /etc/X11/xorg.conf /etc/X11/xorg.conf.orig
aticonfig --initial -f

sax2 -r -m 0=fglrx

display: :0.0  screen: 0
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI Radeon Xpress Series
OpenGL version string: 2.1.8304 Release

Other Thoughts

After having played with OpenSUSE 11.1 for a couple hours, I think I might be able to keep it around for a little while. Despite the lack of speed exhibited by other Linux distributions, the "stability" that OpenSUSE seems to offer is attractive to me. It will likely take some time to get used to RPMs over DEBs for package management.

How bad can it be? I mean, it comes with OpenOffice 3.0.0, which is nice. It can handle dual-head mode on my laptop thanks to Xinerama, which no other distro to date has been able to do. This gives me a little more screen real estate to work with, which helps out a lot when I'm developing a Web site or working in an IDE. The package managers are slow, but how often do you really install software anyway?

Again, we'll just have to see how things pan out. Let's hope it turns out to be a positive experience.

Getting Slackware

The first, and most obvious step, is to get a copy of Slackware. Simply head on over to http://www.slackware.com/getslack/ and retrieve the appropriate ISO(s) using whichever method you prefer. I downloaded the DVD version of Slackware. If you download the CD ISOs, you really only need the first 3 ISOs. The remaining 3 are source packages for the binary packages you install from the first three discs. Rarely do you need the source code for these packages.

After retrieving the Slackware ISO(s), you must burn them to a disc of some sort: ISOs that are ~650MB should be burned to CDs and anything larger should (obviously) be burned to a DVD. Be sure you burn each ISO using the "burn disc image" functionality in your disc writing software--simply burning the ISO file onto the disc in a regular data session will not do what we need.

Booting The Install Disc

After you have a good copy of the installation disc (the DVD or the first of the CDs), put the disc into your CD/DVD ROM drive and reboot your computer. To ensure that your computer boots from the disc rather than the hard drive, hit F2 when you see the initial boot screen. Then go to the "Boot" tab and verify that your external CD/DVD drive takes precedence over the internal SSD. While we're in the BIOS, let's hop over to the "Advanced" tab and set "OS Installation" to "Start". This will increase the chances that your external drive will be recognized or something.... mine didn't work until I made that change. When you're all done with that, exit your BIOS, saving your changes.

The computer will reboot, and it should access your installation disc immediately after the initial boot screen disappears. Once you boot from the installation disc, you should be presented with a screen which allows you to pass some settings to the installation kernel.

To make the installation go faster, use the following boot string:

hugesmp.s hdc=noprobe

This makes it so the installation will see the internal SSD as /dev/sda instead of /dev/hdc, which also boosts the read/write times by about 13 times.

During the boot process you will be asked to specify your keyboard map. Unless you want something special here, just hit the enter key to proceed.

Partition Your SSD

Next you will need to login as root and partition your SSD. You can do this using one of the following two commands:

fdisk /dev/sda
cfdisk /dev/sda

Here are some steps in case you're not familiar with these utilities:

1. Remove all partitions (unless you know what you're doing)
   1. fdisk: d to delete (you may have to select multiple partitions to delete if you have more than one for some reason)
   2. cfdisk: Select all partitions individually with up/down arrow keys and use the left/right arrow keys to select delete from the menu at the bottom. Hit enter to run the delete command when it's highlighted.
2. Create one partition that takes the whole SSD (again, unless you know what you're doing)
   1. fdisk: n (for new); enter; p (for primary); enter; 1 (for the first primary partition); enter; enter (to start at the beginning of the drive); enter (to select the end of the drive)
   2. cfdisk: Select the new command with the left/right arrow keys and hit enter when it's selected. Make it a primary partition, and have it take the whole SSD (3997.49MB in my case).
3. Set the type of the new partition to be Linux
   1. fdisk: t (for type); enter; 83 (for Linux); enter
   2. cfdisk: Use the left/right arrow keys to select the type command at the bottom and hit enter when it's selected. Choose 83.
4. Set the new partition (or the first, if you decided to make more than one) to be bootable
   1. fdisk: a (for bootable); enter; 1 (for primary partition 1); enter
   2. cfdisk: Select the bootable command from the bottom using the left/right arrow keys. Hit enter when it's selected.
5. Write the changes to the partition table and quit
   1. fdisk: w
   2. cfdisk: Use the left/right arrow keys to select the write command from the bottom. Hit enter when it's selected. Type 'yes' to verify your intent, acknowledging that your previous data will be "gone". Then select the quit command.

Installing Slackware

As soon as your partitioning has finished, go ahead and run setup to begin the actual installation program.

Since we don't have a swap partition, can jump straight to the TARGET option. Use the arrow keys to highlight this option and hit enter. Select /dev/sda1 from the list, and format it with ext2. On the EeePC, most people prefer this format since it is a non-journaling filesystem. That means fewer writes to the SSD, which supposedly translates to a longer lifetime.

After the SSD is formatted, you will be asked to select the installation source. Again, I'm assuming that you want to use your fresh Slackware 12.2 disc, but you are free to choose what you want if you know what you're doing.

I went with the default "Install from a Slackware CD or DVD" and told it to auto scan for my disc drive. It was found at /dev/sr0.

Choosing Your Packages

Next, you are given the opportunity to tweak the package series which will be installed on your EeePC. I chose the following series: A, AP, K, L, N, TCL, X, and XAP. I planned on using XFCE instead of KDE on my EeePC simply because it is much more light-weight and still capable of what I need. If you want KDE, be sure to check the appropriate series.

Once you mark each of the package series you wish to install, hit the "OK" button. You'll then have to choose which prompting mode to use. I chose menu, simply to be a little more picky about which packages I wanted installed. Installation took approximately 28 minutes with my package selection and setup.

First Boot

You should now go back into your BIOS and set "OS Installation" back to "Finished", exit and save changes, and reboot again.

You should then see the Slackware boot screen. By default, it has a 2-minute timeout, which seems absolutely absurd to me, so we'll change that later. Just hit enter for now and watch your new Slackware boot. The first boot will usually take a bit longer than subsequent reboots because all sorts of things need to generate their first configuration file.

When your system is ready, you'll be presented with a login prompt. Just login as root, using the password you specified in the last step of the installation process.

Tweaking Your Slackware

Here are some of the first things I do when I install a new copy of Slackware:

id:3:initdefault:

id:4:initdefault:

Section "ServerLayout"
    Identifier     "X.org Configured"
    Screen      0  "Screen0" 0 0
    InputDevice    "Mouse0" "CorePointer"
    InputDevice    "SynapticMouse" "AlwaysCore"
    InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Section "Files"
    RgbPath      "/usr/share/X11/rgb"
    ModulePath   "/usr/lib/xorg/modules"
    FontPath     "/usr/share/fonts/TTF"
    FontPath     "/usr/share/fonts/OTF"
    FontPath     "/usr/share/fonts/Type1"
    FontPath     "/usr/share/fonts/misc"
    FontPath     "/usr/share/fonts/75dpi/:unscaled"
EndSection

Section "Module"
    Load  "xtrap"
    Load  "GLcore"
    Load  "record"
    Load  "dri"
    Load  "dbe"
    Load  "extmod"
    Load  "glx"
    Load  "freetype"
    Load  "type1"
    Load  "synaptics"
EndSection

Section "InputDevice"
    Identifier  "Keyboard0"
    Driver      "kbd"
    Option       "XkbModel"  "pc104"
    Option       "XkbLayout"  "us"
EndSection

Section "InputDevice"
    Identifier  "Mouse0"
    Driver "mouse"
    Option "Device" "/dev/input/mice"
    Option "Protocol" "IMPS/2"
    Option "Buttons" "5"
    Option "zAxisMapping" "4 5"
    Option "SHMConfig" "on"
EndSection

Section "InputDevice"
    Identifier "SynapticMouse"
    Driver "synaptics"
    Option "Device" "/dev/input/mice"
    Option "Protocol" "auto-dev"
    Option "SHMConfig" "on"
EndSection

Section "Monitor"
    Identifier   "Monitor0"
    VendorName   "Monitor Vendor"
    ModelName    "Monitor Model"
EndSection

Section "Device"
        ### Available Driver options are:-
        ### Values: <i>: integer, <f>: float, <bool>: "True"/"False",
        ### <string>: "String", <freq>: "<f> Hz/kHz/MHz"
        ### [arg]: arg optional
        #Option     "NoAccel"               # [<bool>]
        #Option     "SWcursor"              # [<bool>]
        #Option     "ColorKey"              # <i>
        #Option     "CacheLines"            # <i>
        #Option     "Dac6Bit"               # [<bool>]
        #Option     "DRI"                   # [<bool>]
        #Option     "NoDDC"                 # [<bool>]
        #Option     "ShowCache"             # [<bool>]
        #Option     "XvMCSurfaces"          # <i>
        #Option     "PageFlip"              # [<bool>]
    Identifier  "Card0"
    Driver      "intel"
    VendorName  "Intel Corporation"
    BoardName   "Mobile 915GM/GMS/910GML Express Graphics Controller"
    BusID       "PCI:0:2:0"
EndSection

Section "Screen"
    Identifier "Screen0"
    Device     "Card0"
    Monitor    "Monitor0"
    DefaultDepth 24
    SubSection "Display"
        Viewport   0 0
        Depth     1
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     4
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     8
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     15
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     16
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     24
    EndSubSection
EndSection

options psmouse proto=imps

options psmouse proto=any

# LILO configuration file
# generated by 'liloconfig'
#
# Start LILO global section
# Append any additional kernel parameters:
append="hdc=noprobe vt.default_utf8=8"
boot = /dev/sda
compact

lilo -v

# LILO configuration file
# generated by 'liloconfig'
#
# Start LILO global section
# Append any additional kernel parameters:
append="hdc=noprobe vt.default_utf8=0"
boot = /dev/sda
compact

# Boot BMP Image.
# Bitmap in BMP format: 640x480x8
bitmap = /boot/slack.bmp
bmp-colors = 255,0,255,0,255,0
bmp-table = 60,6,1,16
bmp-timer = 65,27,0,255

prompt
timeout = 50
change-rules
reset
vga = normal
# End LILO global section
# Linux bootable partition config begins
image = /boot/vmlinuz
root = /dev/sda1
label = Linux
read-only
# Linux bootable partition config ends

wget http://people.redhat.com/csnook/atl2/atl2-2.0.4.tar.bz2
tar jxf atl2-2.0.4.tar.bz2
cd atl2-2.0.4
make
cp atl2.ko /lib/modules/`uname -r`/kernel/drivers/net/
depmod -a
modprobe atl2
ifconfig

DHCP_TIMEOUT[0]="5"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

#!/bin/sh
#
# /etc/rc.d/rc.local:  Local system initialization script.
#
# Put any local startup commands in here.  Also, if you have
# anything that needs to be run at shutdown time you can
# make an /etc/rc.d/rc.local_shutdown script and put those
# commands in there.

modprobe p4-clockmod
modprobe cpufreq_ondemand
modprobe cpufreq_conservative
modprobe cpufreq_powersave
modprobe cpufreq_performance

cpufreq-set -g ondemand -d 450Mhz -u 900Mhz

mkdir /mnt/sd

ls /dev/disk/by-uuid

UUID=[your SD card's UUID] /mnt/sd ext2 defaults,noatime 1 1

/dev/sda1        /                ext2        defaults,noatime         1   1
UUID=30293ff4-5bee-457a-8528-ec296f099e9a /mnt/sd ext2 defaults,noatime 1 1
#/dev/cdrom      /mnt/cdrom       auto        noauto,owner,ro  0   0
/dev/fd0         /mnt/floppy      auto        noauto,owner     0   0
devpts           /dev/pts         devpts      gid=5,mode=620   0   0
proc             /proc            proc        defaults         0   0
tmpfs            /dev/shm         tmpfs       defaults         0   0

modprobe -r snd_hda_intel

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

#!/bin/sh

IFS=${IFS}/
set $@

#logger "ACPI Event $1, $2, $3, $4, $5"

case "$1" in
    button)
        case "$2" in
            power) /sbin/init 0;;
            sleep) /etc/acpi/actions/lid.sh;;
            lid)
                if grep -q closed /proc/acpi/button/lid/LID/state
                then
                    /etc/acpi/actions/lid.sh
                fi
                ;;
            *) logger "ACPI action $2 is not defined";;
        esac
        ;;
    hotkey)
        case "$3" in
            # Fn+F2 Wireless/Bluetooth button
            # Fn+F7 Mute button
            00000013) amixer set Master toggle;;
            # Fn+F8 Volume down
            00000014) amixer set Master 10%-;;
            # Fn+F9 Volume up
            00000015) amixer set Master 10%+;;
        esac
        ;;
    *) logger "ACPI group $1 / action $2 is not defined";;
esac

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

#!/bin/sh
# script by Fluxx from linuxquestions slackware forum
# discover video card's ID
ID=`/sbin/lspci | grep VGA | awk '{ print $1 }' | sed -e 's@:@/@'`

# securely create a temporary file
TMP_FILE=`mktemp /tmp/video_state.XXXXXX`
trap 'rm -f $TMP_FILE' 0 1 15

# switch to virtual terminal 1 to avoid graphics
# corruption in X
chvt 1

/sbin/hwclock --systohc

# remove the webcam module
rmmod uvcvideo

# write all unwritten data (just in case)
sync

# dump current data from the video card to the
# temporary file
cat /proc/bus/pci/$ID > $TMP_FILE

# suspend-to-ram
# (samwise) not using this it stuffs up the screen brightness
echo -n mem > /sys/power/state

# suspend-to-disk
#echo -n disk > /sys/power/state

# standby
#echo -n standby > /sys/power/state

# force on for now...
xset dpms force on

/sbin/hwclock --hctosys

# restore the webcam module
modprobe uvcvideo

# restore video card data from the temporary file
# on resume
cat $TMP_FILE > /proc/bus/pci/$ID

# switch back to virtual terminal 2 (running X)
chvt 6; sleep 2
chvt 2

# remove temporary file
rm -f $TMP_FILE

chmod +x /etc/acpi/actions/lid.sh

installpkg wicd-1.5.6-noarch-2.tgz

Using Slackware 12.2

I have to give the Linux kernel hackers props--the 2.6.27.7 kernel is amazingly fast! I'm sure the fact that I'm running a fairly stock Slackware installation (as opposed to something like Ubuntu) helps the speed quite a bit too. This past semester I had Linux Mint 5 (XFCE edition) installed on my EeePC, and that seemed fairly responsive. Slackware blew me away though, and I can still do everything I want to do!

The webcam and sound card work out of the box, just like the wireless. I rarely use the webcam, but it's fun to play with, and my mom appreciates seeing me on Skype occasionally. The wireless connection quality exceeds what it was with the madwifi driver I was using with Slackware 12.1 and other distros like Linux Mint. Programs are ultra speedy and responsive, even with the processor clocked at 450Mhz. I love it!!!

Boot times could be better, but I'm not too concerned with it. My setup takes approximately 50 seconds from boot to a useable desktop interface. Not horrible by any means, but perhaps not the best for a netbook when all you want to do is check your e-mail.

I would like to see the Network Manager that so many other distributions offer in Slackware some day. The wicd application is nice, but it's not nearly as intuitive as Network Manager, and it seems to be relatively limited in its capabilities in comparison. I know I'm not alone in my desire to see Network Manager included, or at least available, for Slackware. It would be tremendously beneficial in a world where wireless networking and laptops are more and more pervasive. Using the command line to adjust your wireless connection settings each time you have to hop to a new access point is just annoying.

In the end, I'm excited to have Slackware on my EeePC once again. I think it will be around for quite a while this time.

Please comment with any advice or problems that you have in regards to installing Slackware 12.2 on an EeePC.