Computer Quick Tips

by Philip Guo (philip@pgbovine.net)

This page is a compilation of useful computer-related tips that I have collected both from others and from my own experiences.

UNIX command-line tools

You can accomplish quite a lot at the UNIX command line without writing a single line of code. Here are some useful commands:

find: This is one of the most useful commands for performing batch processing on lots of files. It automatically recurses into sub-directories, searches for all files which match certain criteria, and (optionally) executes a command on each file. Example usage:
- find . -type 'd' will list all sub-directories under the current directory.
- find . -name '*.htm' will find all files ending in .htm in this directory and all sub-directories and display their paths relative to the current directory, one on each line.
- find . -name '*.htm' -exec rm {} \; will delete all .htm files in this directory and all sub-directories. The -exec will execute any command between it and the \; The {} will be substituted with the full pathname of each file which it finds. This means that whatever command you specify will be executed once for each file found.
- find . -name '*.htm' | xargs grep 'string' will do a grep textual search on all .htm files. (xargs concatenates all of the output of the find on a single line and appends them to its argument - in this case, grep) This is better than find . -name '*.htm' -exec grep 'string' {} \; because the latter runs grep once for every file whereas the former runs grep only once total, which has the advantage of providing filenames next to the listings of lines which match 'string'. find and xargs make a powerful team. Here is a BASH function that encapsulates this useful combo:
```
# find and grep
function fg {
  find . -name "$1" | xargs grep "$2"
}
```
  Thus, invoking fg '*.htm' 'string' will do the trick. Remember to put quotes around everything, or else your shell will do undesired expansions.
BASH shell: I don't have much of a preference on shells since I'm not much of a shell programmer. However, BASH is what comes by default at work, so here are some useful things I do with it:
- TAB completion: The oldest trick in the book, but still super useful. Whenever you're part-way through typing something on the shell, hit TAB to have the shell try to complete the rest of the word. If there is more than one match, hit TAB again to list all of them.
- Ctrl+R command history search: Hit Ctrl+R and start typing in words from a previous command that you've executed, and the shell will try to find a match. This is a useful alternative than hitting the up and down arrows to linearly browse your command history. Hit Ctrl+R repeatedly to cycle through your matches, and TAB to accept one.
- Emacs-style commands: BASH shares many of its commands with Emacs. Here are the most useful ones:
  - Ctrl+A moves to the beginning of the line
  - Ctrl+E moves to the end of the line
  - Ctrl+K deletes everything from the cursor to the end of the line
  - Ctrl+L clears the screen
  - Alt+D deletes the entire word underneath your cursor.
  - Alt+B moves back one word
  - Alt+F moves forward one word
  The Emacs META character is usually emulated using the Alt key, but it doesn't work on some terminals.
pushd / popd: These provide the shell with the web-browser equivalents of back and forward buttons. Instead of using cd dirname to change directories, use pushd dirname and it will save your current directory on a stack. To go back to the directory you came from, use popd. You can push and pop several directories on the stack.
diff: This command is normally used to find line-by-line differences between two text files. However, one really neat way to use diff is to see differences between entire directories. If you use diff -ur dir1 dir2, it will recursively search inside of directories dir1 and dir2, tell you what files exist only in one of these directories, and find differences in files that exist in both directories.
Terminal annoyances:
- If you accidentally press Ctrl+S while you are in some terminals, that freezes it so that no more text gets sent to it (although commands you type in will still be executed). If you find your terminal frozen, try doing Ctrl+Q to un-freeze it. If that doesn't work, then try killing the program that is controlling the terminal.
at and batch: These commands allow you to run jobs when you are not logged into the computer. This is useful when you want to start a long-running job but don't want to stay logged in, either physically or remotely. They can be thought of as lightweight alternatives to cron.
write sends a message to a particular user who is logged into your machine (Use w to see who is logged in). wall sends a broadcast message to everyone who is logged in. This is like uber-nerdy instant messaging. (You can either type your message and terminate it with Ctrl+D or pipe in a message from a file.)

CVS

Here are some useful CVS commands:

cvs -q update | grep -v '^?' allows you to focus on what files have changed and ignore all the ones that aren't in your repository. This is useful when you want to run cvs update in a directory with tons of sub-directories and nobody bothered to update the .cvsignore files in all the sub-directories in order to avoid displaying the pesky '?' files which aren't in the repository.
cvs update -C files will restore the files to the most recently checked-in versions and save your working version as backup files. This is better than simply deleting your file and doing a cvs update.
cvs update -rX -p file > file-old will save version X of file into file-old. This is a useful alternative to simply doing cvs update -rX file because the latter sets a pesky 'sticky tag' (which can be gotten rid of by doing cvs update -A). If you want to clobber the file completely with the old version, just copy file-old into file.
cvs update -D2005-05-07 files will restore files to their most recent versions before 2005-05-07. You can substitute anything for the date and also put in a time if you want more detail. This will set the 'sticky date' flag for all of those files (you can confirm this by doing cvs status). To restore back to the most recent versions, do a cvs update -A. This is extremely useful when your code suddenly breaks. All you need to do is to think about when was the last day when your code worked, use this command to backtrack, and do a binary search in time among all versions between that day and today.
cvs history -c -a -l -D "2005-07-28" will produce a list of all changes that anybody has made to the ENTIRE repository (which the current directory belongs to) from a certain date (2005-07-28 in this example) until the present. This is useful for tracking the activity of your fellow developers, especially when trying to isolate the cause of a newly-surfaced system bug.
If you're tired of seeing so much noise when you run a cvs update and you simply want to see the files that have been changed/added/removed, run this function vv to get a quiet update:
```
# Clean-looking cvs update - Only shows changed files
function vv {
  cvs -q up -d | grep -v '^?'
}
```
Here is a function that allows you to see the differences between your current version of a file and the previous checked-in version. If you've checked in version 1.10 of a file and you run cvs diff, then there are obviously no diffs. However, what you probably really want is to compare version 1.10 to 1.9 to make sure you haven't checked-in any undesired changes. Here is the function:
```
# Diffs current version with PREVIOUS checked-in version
# (Might not work all the time, but oh well)
function vpl {
  CUR_VER=`cvs status "$@" | grep "Working revision:" | awk '{print $3}'`
  # It will be like "1.91" or something.  We want to decrement
  # the number AFTER the period
  CAR=`echo $CUR_VER | cut -d. -f1`
  CADR=`echo $CUR_VER | cut -d. -f2`

  CADR=$(($CADR - 1))
  PREV_VER=$CAR.$CADR

  cvs diff -r$PREV_VER "$@" | less
}
```
Invoke simply by typing vpl filename

ssh - passwordless, agents, forwarding, proxys

Here are some neat ssh tricks to help improve your productivity by allowing you to not type in a password nearly as often. When I first learned to use ssh to remotely login to computers at work, I simply typed in my password every time I logged in. This grew annoying after a while. For example, whenever I used cvs over ssh, I would have to type in my password every time I performed a cvs operation.

Then I learned to use ssh-agent to authenticate using public/private keys instead of using a password. There are many guides on the Internet for how to do this, so I'll just summarize:

On your personal computer, run ssh-keygen -t dsa to generate a public/private key pair in your ~/.ssh/ directory. Enter a passphrase (which is really just a password) to protect your key.
In your ~/.ssh/ directory, id_dsa is your private key. Never move this key anywhere off of your personal computer. Nobody except for you should have access to this key.
id_dsa.pub is your public key. You should copy this key to all the remote computers which you want to log into. Do so by logging into your home directory on each remote computer, and appending your public key (which should fit in ONE long line) to the end of the ~/.ssh/authorized_keys file (create one if it doesn't already exist) on each computer you want to log into. ssh is very picky about file permissions in order to work properly with keys, so do a chmod 644 .ssh/authorized_keys and chmod 700 .ssh on remote machines to set the proper permissions. (Better yet, use the ssh-copy-id program to handle all of this automatically!)
Now when you log into one of the remote computers on which you've installed your public key, ssh will prompt you for your passphrase (instead of your regular password). You should be able to login as usual. Now you're probably asking yourself, "uhhh okay, I still have to type in a password every time, except now it's called a passphrase instead ... hardly an improvement."
Now here comes the magic. Run:
```
  eval `ssh-agent -s`
  ssh-add
```
It will prompt you for your passphrase. Enter it once, and the ssh-agent saves it. Try logging into your remote computer now. If all works out, then you shouldn't have to type in your password! You only need to run ssh-add once for every login session, so you have to type in your password at most once per login to your personal computer instead of during every login attempt to the remote computer.

The devil's always in the details, so please search for more detailed guides to passwordless ssh login to get the kinks worked out for your particular OS. On Mac OS X, I use SSHKeychain to manage my keys so that I only need to type in my password once for every login session.

Okay, now say there are a few computers at work that I want to log into, and I want to ssh BETWEEN those computers without entering in my password. Let's say I have a home computer named home and 3 work computers, alpha.work.net, beta.work.net, and gamma.work.net. I have my public key installed in the ~/.ssh/authorized_keys files in all 3 work computers. Using ssh-agent, I can log from home to alpha.work.net, beta.work.net, and gamma.work.net with no password typing. That's fine and dandy, but what if after I log into alpha.work.net, I want to then log into beta.work.net, or to log from gamma.work.net to alpha.work.net, etc.? That is, what if I want to connect from home to one of my work computers, then seamlessly log into my other work computers without re-typing my password? I could place my private key on all those computers and setup ssh-agent, but I still need to type in my password at least once every time I log in (since it starts a brand new login session). Also, it's not safe to put your private key on a remote computer, even if you make it only readable by yourself, since the root user can always snoop on your files :0

ssh agent forwarding is a better way to achieve this goal, without the need to copy your private key off of your home computer or to re-type your password. To activate agent forwarding, put the following line in the ~/.ssh/config file on all the computers (create one if it doesn't already exist):

  ForwardAgent yes

This will allow you the ssh-agent to 'forward' your saved password through all of the computers, so that you can type in your password once on your home computer at the beginning of your session and seamlessly log into and, more importantly, BETWEEN all of your work computers without having to re-type your password.

One final trick before we part ways ... let's say that only one computer at work is publicly accessible. Let's call that alpha.work.net. Thus, it's possible login from home using:

  ssh alpha.work.net

but it's not possible to log into beta.work.net or gamma.work.net using the respective commands since they are not publicly accessible:

  ssh beta.work.net
  ssh gamma.work.net

For security reasons, many workplaces only allow you to log into a limited number of 'gateway' computers from the Internet, and the rest of the computers are only accessible from within the local network. It's annoying to always have to first log into alpha.work.net from home and then manually log into, say, beta.work.net. To overcome this problem, we will use ssh proxy commands. Add the following lines to ~/.ssh/config on your home computer:

  Host beta.work.net
    ProxyCommand ssh -q -a -x alpha.work.net nc -w 1 %h 22

  Host gamma.work.net
    ProxyCommand ssh -q -a -x alpha.work.net nc -w 1 %h 22

These lines set up alpha.work.net as an intermediate proxy to connect to beta.work.net and gamma.work.net. Now you should be able to run:

  ssh beta.work.net
  ssh gamma.work.net

and login fine ... as you might have guessed, you are actually first logging into alpha.work.net and then logging into your desired work computer, but ssh proxy commands handle this transparently. Another benefit besides convenience is that you can now use ssh-dependent tools such as scp, sftp, unison, and sshfs to directly connect your home computer to a work computer that's not ordinarily publicly accessible. Hot!

XEmacs

I use XEmacs as my main text editor for writing programs, HTML, LaTeX, and just about anything which requires text editing. I find that it's a bit more integrated with modern GUI's than traditional GNU Emacs, and it has a few keyboard shortcuts that aren't build into GNU Emacs. I use XEmacs both on Windows and UNIX. Here are some commands that I use on a regular basis:

xemacs -nw file on the command-line will start XEmacs in terminal-mode so that you can edit your documents without having an X server running. This is also faster than having a full-blown GUI, although you won't be able to use the mouse.
Alt+X flyspell-mode toggles the automatic incremental spell-checker which highlights misspelled words in real-time (like those which exist in many word processors)
Alt+X auto-fill-mode toggles automatic word-wrapping at the end of every line as you are typing
Alt+Q manually word-wraps the current paragraph where your cursor is located (auto-fill-mode automatically executes this command as you are typing).
Ctrl+A moves to the beginning of the line; Ctrl+E moves to the end of the line
Alt+Shift+< moves to the beginning of the file; Alt+Shift+> moves to the end of the file
Ctrl+K deletes everything from the cursor's position to the end of the line and copies it to the clipboard
Alt+D deletes the word underneath the cursor and copies it to the clipboard
Ctrl+Y pastes the most recent contents of the clipboard. After pressing this, press Alt+Y to cycle backwards through all of the other things that were previously saved on the clipboard
Alt+G allows you to type in a line number and then go to that line
Ctrl+X 52 pops open a new window running in the same XEmacs process. This is better than simply starting a completely new instance of XEmacs because you can share information (such as buffer and clipboard contents) between two windows in the same process.
Ctrl+G is the universal panic command. Press this a few times to get out of trouble when XEmacs is screaming at you for something weird.
Ctrl+X Ctrl+S saves the file, Ctrl+X K closes a file, and Ctrl+X Ctrl+C exits XEmacs.

Programming in general

This is where I put general programming tips which are fairly language-independent.

Don't be a programming language bigot. Don't simply do all of your programming in one language just because that's the only one you know well (or because it's the BEST LANGUAGE EVER, in your not-so-humble opinion). There is no best language, but for every type of programming task, there are languages that are better than others for that task. Before you dive into a project, take the time to learn what language other people who work on similar projects use, what free libraries and documentation are available, and see if you are interested in learning it. Remember that you want to write as little code as possible, so a language with a great free library for what you want to do may be worth using, even though you would prefer another language in terms of style or ideology.
Hard-code complex conditional breakpoints in the program itself. Let's say you have the following function (annotated with line numbers):
```
100  void foo(int a, int b, int c) {
101    ... blah ...
           ...
150    ... bleh ...
151  }
          
```
Let's say that when you're trying to debug, you only want to stop at this function when some complex condition has been met. Ordinarily, you would set a conditional breakpoint in the debugger. You probably need to set the conditions again every time you restart the debugger, which can be annoying. Instead, you should set the conditional in the program itself like so:
```
100  void foo(int a, int b, int c) {
101    ... blah ...

120    if (((a % 3) == 0) || 
121        ((b < (c * 2)) && ((c + a) < 0))) {
122      printf("BREAK!!!");
123    }

150    ... bleh ...
151  }
          
```
Now all you have to do is to set a regular breakpoint on line 122 (the line with the print statement). This line should only be executed if your condition passes. Voila! You have a conditional breakpoint which is hard-coded into your code. Feel free to comment it out when you don't need it anymore. This is a much better alternative than setting complex conditions within the debugger.
Learn to use both a debugger and print statements together to debug. Like many novices, I spent several years programming without a debugger. I thought I was so cool when I was able to set complex conditionals in my code and print out tons of debugging output to my terminal. However, often times, all of those painful print statements could be eliminated by a session in the debugger. That said, I still think that there is merit in print statements. Print statements are better for grasping an overall picture of the large-scale patterns in your program, and can often be used to quickly find a large class of bugs. I use a two-tiered approach, using print statements first to try to pinpoint the problem, and then firing up a debugger to get into the details.
This one is a cliche, but it's so true: Don't prematurely optimize! Don't try to think that you're so slick and hack up some optimization to 'help out the compiler'. Maybe you could do that 30 years ago, but modern compilers can optimize pretty well themselves. Source-level optimizations sacrifice code readability and worse, correctness, all for a potential small gain in speed (you won't really gain much speed unless you implement an asymptotically faster algorithm, and you're running on sufficiently large inputs). Often times, the part that you are trying to optimize isn't even the performance bottleneck in your system. Also, unless you're writing a performance-critical application, speed isn't your greatest concern.
My advice is to get a working version first, write a solid test suite for it, and then start optimizing if you really want to. At least you'll have a working version as backup, and more importantly, a test suite which hopefully makes sure that your program is still behaving correctly with optimizations.

Basic BASH shell programming

There are many comprehensive guides to BASH shell programming (such as this one), but they often provide too much overwhelming detail for casual script writers (like me) who just want to get some quick and dirty work done. Here are some quick tips:

Don't have whitespace on either side of the = when making a variable declaration. foo=5 is okay, but foo = 5 is NOT.
The basic for loop operates by iterating a variable over a space-delimited sequence of words. This is one of the most useful constructs:
```
for foo in a b c d e
do
  echo $foo
done
```
This prints out a, b, c, d, e on separate lines. Remember to put a $ in front of the variable name to retrieve its value. This may seem trivial, but remember that you can pass any sequence of words after the in. Check out the next tip:
Enclosing an expression in backticks ` (the key to the left of the 1 key) causes the shell to execute that expression and return its value as a space-delimited sequence of words ... A HA! You can use this sequence in the head of the for loop so that you can perform some task for every element. Backtick evaluation with for loop iteration can go a long way:
```
for foo in `find . -name '*.xml'` 
do
  echo $foo
done
```
This script executes the find to find all files with the suffix .xml in all sub-directories, then prints out their names.

Use the % character to chop off matching sub-strings at the end of a string or the # to chop off matching sub-strings at the beginning. Here is an example:

foo="my-data.xml"
echo $foo               # This prints "my-data.xml"
echo ${foo%.xml}        # This chops off the ".xml" at the end and prints "my-data"
echo ${foo#my-}         # This chops off the "my-" at the beginning and prints "data.xml"

How is this string munging useful? In a for loop, of course! Check this out:
```
for foo in `find . -name '*.xml'` 
do
  xsltproc style.xml $foo > ${foo%.xml}.html
done
```
This is kind of like a script that I actually use in my XML Photo Gallery to generate HTML files from XML files by applying an XSLT stylesheet (style.xml) with the xsltproc tool. This script finds all XML files, then passes each one into xsltproc and redirects the output to a file with the same name, except with an .html extension instead of .xml. Notice how I used the % to chop off the .xml suffix from each filename before adding the .html suffix.
The classic if / else conditional can also come in handy. Always enclose your test conditions in double-brackets (you don't need to escape certain characters this way), and remember to leave a space between the brackets and your test! if [[ -n $foo ]] is okay (tests whether $foo is not null), but if [[-n $foo]] is NOT okay. Look at the test program or this useful reference page for the extensive amount of conditions that you can test within the brackets.
```
for foo in `ls`
do
  if [[ ! -r $foo ]]
  then
    chmod u+r $foo
  elif [[ ! -w $foo ]]
  then
    chmod u+w $foo
  else
    echo You have both read and write permissions for $foo.
  fi
done
```
This script tests whether you have read and write permissions for everything listed by ls in the current directory, and gives you the permissions that you lack. (It's silly since you can just run chmod u+rw * to accomplish the same thing, but I wanted to show off the if / else construct.) elif is just shorthand for else if, so you still need a then to follow it. However, you don't need a then to follow the else. Neither the elif or else clauses are mandatory.

C programming in UNIX

gcc -c -g foo.c -Wa,-aldhs > foo.S will compile foo.c and generate an annotated listing of its assembly code along with its original C code in foo.S. The cool part is that it shows you each line of C followed by the lines of assembly corresponding to that line. This is extremely useful both for learning how C code compiles into assembly and also for debugging thorny low-level issues.
Turn on gcc warning levels as high as you feel comfortable doing (see the various -W options in the GCC manual, most notably -Wall for turning on most warnings), and then look at all the warnings and try to address them as if they were errors. The C standard doesn't provide very tight standards for what code can legally compile, so you can get away with running fairly atrocious code (such as not including a return statement in a function which returns an integer value, thus causing the program to return whatever junk value was in the EAX register ... yes, that cost me a few hours of hair-pulling). Because you are programming in C, you already lose lots of the compile-time safety checks available in safer, higher-level languages, so you must be vigilant to ensure that you don't allow code that has blatant syntatic bugs to compile and run.
Use watchpoints in a debugger like GDB to diagnose memory corruption errors, one of the nastiest and hardest-to-find types of bugs in a memory-unsafe language like C. Memory corruption can occur when some data structure in your program retains a pointer to a region of memory that is freed without its knowledge (via an aliased pointer), and then some other part of your program re-allocates that memory to be used for another purpose. You should suspect memory corruption whenever you find that there is some bug where a value is valid at a particular time but jumbled at another time, and that the time when the corruption occurs varies across different runs.

To fix these bugs, you first need to find the line of code that causes the value to be clobbered with junk. To do so, go into GDB and step to a line of the code where the program accesses the data that will later be corrupted. Set a watchpoint on the expression that you used to access the data using watch foo, where foo is the expression that you want GDB to watch. Now continue to execute your program normally, and GDB will pause it when the contents of foo first changes and give you the line of code that caused the change. Often times, this is enough information for you to realize what you need to do to fix your bug. Note that all a watchpoint does is stop the program when the value contained in the contents of the expression it is watching changes, so to prevent false alarms, you want to set the watchpoint at a time when you no longer expect that data to change ... but of course, it will change due to the memory corruption, which is precisely the change that you want the watchpoint to catch.

Converting from HTML to XHTML

XHTML is considered by many to be the desired language for the future of the web. It is quite similar to HTML except that it has much stricter standards for what is allowed to be a legal XHTML document. Think of XHTML as "proper, non-sloppy HTML" or the HTML that results after repeated nitpicking to ensure 'good form'. One great advantage of XHTML over HTML is that an XHTML document can be treated like XML, which allows a plethora of XML-based tools (such as parsers for various programming languages and especially the XSLT transform language) to operate seamlessly on it. Web browsers are usually pretty lenient when parsing HTML so that you can write fairly sloppy HTML and still have it display correctly. However, the standards for XHTML are much more strict, so if you abide by these standards, then your pages will be more likely to display correctly on current and future browsers, but more importantly for nerds, be able to be treated like XML!

My regular webpages on this site are done in plain 'ole HTML (I haven't had the motivation to convert them yet), but one day I decided to convert my People Photo Gallery site from HTML to XHTML because I wanted to try to use it with XSLT (which only works on XML documents). It was a pretty painful 3-hour ordeal to clean-up all of my HTML so that it was also legal XHTML. I mainly

followed the tips in this guide and did lots of trial & error until I got my XHTML gallery working just like how my existing HTML gallery worked.

Instead of regurgitating the contents of that guide, I will now list some useful tips that I had to learn the hard way (so hopefully you won't have to!):

Remember to always have matching opening and closing tags, because an XML document requires that (it's like having matching parentheses in a math expression). My HTML was littered with non-matching tags because web browsers really don't care that much about them. For example, you can't have a <p> hanging around by itself like you can do in HTML. You have to either put a closing </p> after it; a better idea is to put the opening and closing tags together like so: <p />.
Normally you usually don't think that things like image (img) declarations need a matching 'closing tag', but in XHTML they do (images also need to have their src and alt attributes initialized). The following is proper XHTML for an image declaration (Notice that the '/' before the closing '>' is mandatory):
<img src="blah.jpg" alt="main image" onload="SelectedImageLoaded();" />
Speaking of attributes (such as alt and onload), they all need to be lowercase and all of their values need to be quoted.
Replace certain characters that are read as markup characters in XML (such as '<' and '>') with special escape sequences ('<' for '<' and '>' for '>') so that they won't be parsed as XML, or enclose them within a CDATA block as follows: <![CDATA[ stuff to not parse as XML ]]>
Make sure to properly update any HTML which is dynamically-generated by your JavaScript code so that it conforms to XHTML standards. This caused me the most headaches, because I could not easily see the generated HTML code in order to validate or debug it. One thing which really got me for the longest time was that XHTML sometimes demands dimensions to be suffixed by 'px' to indicate pixels. Thus, instead of writing height="100", you should always write height="100px".

Backing up your data

Backups. It's something which everyone knows that they should do, but in reality, few people do it. Why don't people back up their data more often? Often times, it's because they don't know what's the best way to do so. It's unfortunate that the people who don't make regular backups are the ones who are more likely to have their computers crash (due to general inexperience), whereas the computer experts who backup neurotically rarely have to deal with crashes.

Many people fear backups because they think that they have too much stuff to back up. From my experience, the actual amount of data that you really need to back up is fairly small. Here is what I would back up: everything which you personally created yourself or cannot otherwise be easily replaced. This includes your documents, digital photographs, email, artwork, etc..., but NOT your downloaded music, movies, and programs. Think about what takes up most of the space on your computer: music, movies, games, and other stuff that can be easily replaced. Backup only those things that cannot be easily replaced, and you'll find that they actually don't take up much room at all.

Here are some common methods that I've used to back up my data, listed in order of complexity. Remember to choose a method which you are comfortable using on a regular basis, because no matter how good a backup method is, it's useless if you don't use it!

Email it to yourself (or to someone else): This is perhaps the simplest and least intrusive way to do a backup of one file or a small set of files. When you're working on that 10-page paper, occasionally take a break to simply email that paper to yourself (or to a friend). If you accidentally delete that report, you'll be glad that you sent that one quick 5-second email. This method is great for small tasks because it does not require much work, but it is not recommended for backing up larger amounts of data.
Burn to CD: This is a very simple and reliable backup method that I've used for years. A single CD can hold up to 700 MB, which is sufficient for holding all of your documents, emails, and some of your pictures. CD's are also dirt-cheap and durable if you store them in a safe place. Burn CD's periodically and keep redundant copies around in different physical locations for extra protection against disasters. Don't worry about buying expensive rewritable CD's since you won't need to re-write while backing-up. Buy write-once CD's and burn like there's no tomorrow! (The same principle applies for recordable DVD's, of course)
Removable hard drive: This will hold much more data than CD's and is fairly easy to use. Simply plug it into your computer and drag your files onto it to back them up. If you want to use a removable drive as a durable backup device, try to keep it in a secure location. Resist the temptation to carry it around with you everywhere and use it as a normal hard drive, because it will only increase the chances of it being lost or stolen.
Online backups: If you belong to a university, the IT department will usually give you a certain amount of space on their servers to place your files. Also, if you pay for a service to host your website, you will usually get more space than is necessary to hold your website. It's often a good idea to upload your files to these servers for backup. This may actually be more reliable than you backing up your data on your own computer because now it's the server administrator's job to keep their hard drives in good shape and perform nightly backups of their own. (Customers will be FURIOUS if their data is lost.) In general, when you're paying professionals to manage your data, they will usually do a better job than you doing it yourself. Some people are concerned about the possible security hazards of uploading files online for storage, but most of us don't have confidential information anyways. Plan to encrypt the files containing your most sensitive data before you upload them, or just don't upload them at all.
Unison: Unison is a free file synchronization program (for Windows, Mac, Linux, and UNIX) that allows you to keep replicas of the same sets (or subsets) of files on different machines. This backup strategy has the steepest learning curve and greatest setup time of all the methods I have mentioned, but it is also the most flexible and powerful one. Unlike the other methods in which your backed-up data is 'dead' and sitting dormant in some storage area, your data is 'alive' with Unison; you can access them at anytime from any machine you own. I have set it up so that it keeps redundant copies of my files on several different computers and keeps all of those copies constantly updated whenever I make a change to a file on any particular machine. This way, I can have access to all of my data no matter which machine I am working on, so that I am not tied down to one particular machine.
I have devoted an entire article, entitled Unison: Liberation through Data Replication, to describing the benefits of Unison and how you can utilize it.

The cheapest way to get foot pedals

Foot pedals are fairly simple devices: they are switches that you step on to function as Ctrl, Alt, or other modifier keys on your keyboard. Therefore, instead of holding down those keys on the keyboard while trying to type commands, you can simply press down with your foot. This helps to alleviate strain on your hands, especially when using programs like Emacs which rely heavily on 'chords' where you must hold down a modifier key while pressing other keys.

To my chagrin, foot pedals usually cost more than $100, which is way too expensive for such simple electro-mechanical devices. It is not too difficult to hack up your own foot pedal (Derek Rayside's web-site shows you how), but I'm not too handy with 'real-world tools', so I thought of an even easier way to get foot pedals:

Put a second keyboard on the floor and use it as a foot pedal. I am not joking; it really works!!! Windows XP and the Linux distros I've used (Ubuntu, Debian) allow you to plug in multiple keyboards into the PS/2 and USB ports and accepts input from any of them. Simply obtain a second keyboard, put it on the floor, and put your two big toes on top of modifier keys (I use my left toe for the left Alt and right toe for the right Ctrl), and gently tap down on the keys to emulate foot pedals. Of course, this isn't as comfortable as being able to mash your entire foot down on a pedal, but it's a good start. If you really want, you could hack up your secondary keyboard to remove the rest of the keys and enlarge the modifier keys to give yourself larger targets for foot mashing. (Unfortunately, this hack doesn't work on Mac OS X ... I guess they're just too 'smart' about handling inputs from multiple keyboards.)

Keeping Windows XP free of viruses and spyware

Up until Summer 2005, I used Windows XP most of the time and switched to UNIX mainly to do programming for work. Many people have complained how their Windows machines are filled with viruses and spyware, but I have found through experience that you can greatly decrease the chances of your computer getting screwed up by following a few simple rules:

Get a free firewall such as ZoneAlarm and configure it to only allow programs you trust to access the Internet. Most importantly, always have your firewall active, or else it's useless.
Get an anti-virus program (I don't know any free ones for Windows) if you are paranoid. However, if you follow the next few rules, then you shouldn't really be getting viruses in the first place.
Don't download and install any programs that you don't ABSOLUTELY need. This is because lots of the so-called 'free' programs for Windows have advertisements (called AdWare) or worse, Spyware, attached to them. If you must download and install a program, make sure that it's from a reputable source and not from some shady website that's full of cheesy banners and ads. In general, the less programs you install, the less chance there is of something going haywire. When I clean up the crap on people's computers, most of it is caused by crap that they downloaded voluntarily! Before you download and install anything, ask yourself, "why did they make this program free?" Search for the program's name on Google and see what other people thought of it. If people say that it contains Adware or Spyware, then avoid it at all costs.
If you really want to download free programs, try to look for programs which are truly free and open-source and not ones which are only financially free and then violate you via ads and spyware. The distinction may be subtle to the beginner - free is free, right? Wrong. An example of truly free software is The Mozilla suite, which includes web browser and email clients that are extremely solid and secure pieces of software. In general, any software whose source code is released under the GNU General Public License or some other license is probably a much better bet for software than something which is marketed as 'free' but doesn't give you access to the source code. The principle here is not that you would ever want to modify the source code; it's that if someone was trying to hide something malicious in their code, they probably wouldn't release it as open-source.
Perhaps the most important tip!!! Use TWO different web browsers to surf the web:
- Designate one browser as your unsafe browser. This is what you are going to normally use to browse the web. I personally use Mozilla Firefox as my unsafe browser. You should turn off all fancy schmancy features such as cache, cookies, and auto-play of any kind. (For my Firefox, I do the following: No history, no saved form information, no saved passwords, no cookies, no cache, and no Java.) You probably won't be able to view that many fancy things on websites, but then again, you'll have less of a chance of inadvertently downloading some crap that will explode your machine. The key issue here is that most crap you get is probably via your web browsing, so if you use a web browser that's more secure, such as Firefox, and increase the security even further by disabling all unnecessary features, then it will greatly reduce the chances that something goes wrong.
- Designate another browser as your safe browser. Leave all the default options on for this browser. You should only use your safe browser to access websites which you know are legitimate (e.g. ones for your school, bank, or some trusted Internet company such as Google). For casual browsing, always use your unsafe browser. I personally use Mozilla as my safe browser.
I really don't want to be a Microsoft-basher, but please avoid using Internet Explorer if at all possible (and use Mozilla and Firefox instead). I'm not saying this because I hate Microsoft, but because there is lots of evidence which shows that Internet Explorer has far more security flaws than Mozilla or Firefox. Also, the crackers who want to mess up people's Windows computers will more often target Internet Explorer.

Great free programs for Windows XP

Do your Mac friends make fun of you because you are a chump who can't run pretty iPhoto? Do your Linux haCKeRZ friends make fun of you for being a n00b who can't get the latest obscure command-line tools? Are you a Windows user who finds yourself resorting to shady pirated burned CD's that you got from a friend of a friend? Well, believe it or not, you can actually get a good deal of high-quality free software for Windows XP without resorting to software piracy. The programs listed below should handle most of your daily computing tasks, and all come totally for free, no strings (or advertisements) attached!

Mozilla Firefox - Even if you've been living in a hole, you've probably heard of this web browser. It's easy to install and use for the novice, but it has extensions to satisfy power users as well.
Mozilla Thunderbird - An email program which serves as a great free alternative to Outlook or Eudora.
OpenOffice - A complete office productivity suite, including word processor, spreadsheet, presentation maker, flowchart drawing program, and database management application.
Picasa 2 - This is the best photo organization and viewing software that I've ever used, and it's totally free (but not open-source, though, if you care about the distinction).
Cygwin - This is an amazing tool which provides a pseudo-Linux working environment on Windows systems. There are thousands of GNU/Linux programs which are compiled and packaged for Cygwin, so you can have access to all of your favorite command-line (as well as X Windows) programs from the UNIX world. I often use command-line tools such as find and shell scripts to browse and manipulate my Windows file system.
XEmacs - This is my favorite text editor, and believe it or not, there is a native version for Windows (and not just Cygwin). I use XEmacs to take notes, edit web pages, and write programs, but you can use it to do much, much more.

Created: 2005-05-11
Last modified: 2007-01-20