The changes are to give the <pre> tags a grey (#EEE) background colour, and to make the posts individual white boxes on grey, rather than an all-white page.

 
avi@avi:whiteasmilk_1.8$ diff style.css style.css.original
18,35d17
< /* Added to make the code blocks pretty. Stupid CSS implementations mean this will break
<    any form of validity in order to actually make it work. Stupid browser people.
<    I can't remember where I got this from, but if you reckon I might've found it on your site
<    let me know and if I believe you I'll stick a URL here
< */
< pre {
< 	border 0
< 	padding: 0.2em 0.5em;
< 	background-color:#EEE;
< 	white-space:pre-wrap;
< 	white-space: -moz-pre-wrap;  /* Mozilla, since 1999 */
< 	white-space: -pre-wrap;      /* Opera 4-6 */
< 	white-space: -o-pre-wrap;    /* Opera 7 */
< 	word-wrap: break-word;       /* Internet Explorer 5.5+ */
< }
<
<
<
40c22
<   body {background-color:#c9c9c9;}
---
>   body {background-color:white;}
323,326c305
< border-bottom:15px solid #c9c9c9;
<   padding-left:10px;
<   padding-right:10px;
<   background-color:#fff;
---
>   border-bottom:1px solid #999;

Anyway, in your terminal emulator:

dd if=/dev/zero of=/sdcard/swap bs=1M count=100

You can call it whatever you like. The 'count' value (100 above) is how many MB of swap space you want. The above will create 100MB of swap.
This will take a few seconds (of the order of 50), so if it's 'hung' it's probably not crashed.

Then we make it into a swap file and activate it as swap space:

mkswap /sdcard/swap
swapon /sdcard/swap

Finally, we want to change the swappiness of the system. When the system memory is completely full, and more is requested, the kernel needs to work out how to create some space. It, generally, can do one of two things: drop some filesystem cache, or move some application memory to swap.
The swappiness value dictates the priority of either - a value of 0 means it will always try to drop fs cache rather than use swap, and a value of 100 means it will always try to use swap and preserve the fs cache. Only values between 0 and 100 inclusive are allowed, and neither guarantees any action - you can still find yourself swapping out at 0, for example - just the priority afforded each solution.
The default value for the Linux kernel is 60, which is generally not appropriate for something running completely from flash media (where the fs cache isn't so important). So I'm dropping it to 20, which seems to work for me. If it doesn't for you, try some other values, it's an on-the-fly change.

echo 20 > /proc/sys/vm/swappiness

On rebooting the phone, the above settings wont hold. The swap file will still be available (assuming the SD card is still inserted), but on reboot you'll need to run

swapon /sdcard/swap
echo 20 > /proc/sys/vm/swappiness

On the plus side, you'll be rebooting less.

I basically followed the instructions on the Cyanogen wiki and everything worked exactly as described, I've nothing really to add here except to say it's brilliantly easy and everyone should do it.
One small note, though, the final reboot into Cyanogen takes a long time. Mine took just shy of thirty minutes, and I've read of others taking anything above about 15.

The first obvious benefits are root access, exchange activesync support, five workspaces (as against the stock 3) and a bunch of useful apps already installed, including a nifty power control widget which replaces my collection of 5 distinct widgets. I'll write more on it when I've used it more.
In case, as I did, you've been pondering this and wondering what the end result is like, it's almost exactly as previously, but with some new features, there's some screenshots on the webpage. I've not yet found anything to have been degraded by it, and it all looks and feels the same, but a bit more polished in areas. Though it only ships with one ringtone.

~/.torrentrc is the config file for rtorrent. The one from the Debian repos puts an example in /usr/share/doc/rtorrent/examples/rtorrent.rc, and apparently so does *buntu. You probably want to edit this. Path variables can be absolute or relative, and are generally relative and inside ./ by default. I've two directories, ~/torrents/ for the torrents and ~/.rtorrent/ for rtorrent's working directories.
Some variables I found to be handy:

scgi_local="~/.rtorrent/socket/rpc.socket"

Defines the socket file for scgi communication, which you only really need if you want external stats from it. I did, but haven't yet got round to using them.

session = ~/.rtorrent/sessio

The session directory, which lets multiple instances of rtorrent remember where they left off. Cannot be shared between instances.

Scheduling
rtorrent supports command scheduling, the syntax for which is occasionally documented. The syntax is approximately:

schedule = a,b,c,d

Where
a: What you want to call this scheduled command¹.
b: How many seconds after rtorrent starts you want to first execute the command.
c: The interval for subsequent executions.
d: the command you want to execute.
This comes in most handy for auotmatically starting torrents in a directory:

schedule = watch_directory,5,5,load_start=~/torrents/*.torrent

Exactly what that does is left as an excercise to the reader (the example .rtorrent.rc explains, too).

1. I don't know where this comes in handy later on

The following script is what I use to remap this to u:/documents:

;; create some dirs:
u:
mkdir documents
mkdir outlook
 
;; Move My Documents folder:
;; delete current setting
reg.exe delete "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders" /v Personal /f
;; create new setting
reg.exe Add  "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders" /v Personal /t REG_SZ /d u:/documents

It basically allows you to have a monitor for each PC on your desk, and one keyboard and mouse with which to monitor them. Switching between PCs involves just moving the mouse pointer onto the relevant screen. It uses 'screens' rather than monitors, so you don't need to let it know if you've got a complicated multi-monitor setup on a host (or even if you add or remove monitors from one), and it allows for having screens of different sizes and for, say, the bottom half of one screen to line up with the top half of the next.

It's a server/client model - you have one server box into which you plug the keyboard and mouse. The rest connect over the network to it (in cleartext, don't do this where you don't trust the network).

I have two hosts. My work laptop is running Windows XP and has an external monitor plugged in to it. My testing PC is running Debian testing and is a PC proper. Here's my desk:

jup-linux2 is the left monitor (attached to the PC to its left, running Debian), jup-rmt07 is the laptop on the right, which is also attached to the Sony screen in the middle. Since I take the laptop home with me occasionally, jup-linux2 is configured as a server, jup-rmt07 as the client (less to unplug).

Synergy is in the debian repositories, so it's just an apt-get install synergy. This provides two binaries, /usr/bin/synergyc and /usr/bin/synergys, which are the client and the server respectively.
To install it in Windows, you'll want to grab it from their Sourceforge page

Configuring and starting the server
So, having installed, we can configure! The configuration file can be arbitrarily named, mine's cunningly called ~/.synergy.conf and appears verbatim at the bottom of this. Synergy's really rather configurable, but I've never found much need for more than the basics, so I've an incredibly simple setup.

First, we define some 'screens'. Here we can also configure optons for screens, especially as regards the transference of caps-lock and num-lock statuses. I've no special requests, so I just list the hosts whose screens I want Synergy to manage:

section: screens
	jup-rmt07:
	jup-linux2:
end

Second, we define the links. For each monitor, we state what is at any edge of it. This is used to decide where to put the mouse pointer on leaving the screen, so it needs to be done in both directions - the fact that jup-linux2 is to the left of jup-rmt07 does not imply to synergy that jup-rmt07 is to the right of jup-linux2:

section: links
jup-rmt07:
	left = jup-linux2
jup-linux2:
	right = jup-rmt07
end 

If I have two screens at different heights, I can tell synergy that the top 30% of jup-linux2 lines up with the bottom 40% of jup-rmt07, for example:

jup-linux2
	right(70-100) = jup-linux2(0-40)
jup-rmt07
	left(0-40) = jup-rmt07(70-100)

Again, you always always always need to define the screen in both directions. The file is parsed by synergy to see what to do on leaving that particular screen - when you're in jup-rmt07 and move towards the left of the screen, it's only going to do anything if there's a left defined for that screen, irrespective of how many rights point there.
If my screens are above and below each other, up and down are used. A screen can have as many other screens round it as you like, by assigning percentages of edges to different screens.

Configuring the server under Windows involves a different process to use the same principles. Essentially, you build the same text file as above, but in a clicky gui. It's a little odd, but quite simple.

To start the synergy server, we now run

synergys --config ~/.synergy.conf

Replacing '~/.synergy.conf' with the path to wherever the config file is saved.

Configuring and starting the clients

So, we have a server. Now, clients.
On Windows, synergy is only one executable, so we start that, select the 'Use another computer's shared keyboard and mouse (client)' option, stick the server's hostname or IP in the box, and click 'start'.
If you have a *nix client, the command to connect to a server at jup-rmt07 is synergyc jup-rmt07. synergyc provides a few options for changing the behaviour.

Starting Synergy automatically
Finally, I want them to start automagically on boot/login. For the linux host, this is relatively easy, add the following to your crontab:

@reboot synergys --config ~/.synergy.conf

And it'll be started on boot.
To start it under Windows, click the 'AutoStart' button. This will let you configure it to start it on login or, if you have the requisite permissions, start on boot.

.DS_Store files are apple's way of storing the finder preferences for a particular directory. They contain things like background image, sort order, window size and position, and are written when any value for the current directory deviates from that of the parent, which includes every time it is moved.
._ files are Apple's way of storing attributes supported by HFS and HFS+ on less featureful filesystems (like NTFS and FAT).

To prevent OSX writing .DS_Store files to SMB shares, run the following:

defaults write com.apple.desktopservices DSDontWriteNetworkStores true

This sets a per-profile value, so must be run as each user.
Preventing ._ files is a bit more tricky, but it can be done in/for the shell with:

export COPY_EXTENDED_ATTRIBUTES_DISABLE=true

To prevent Samba accepting these files, enter the following into smb.conf

veto files = /.DS_Store/

And read LavaLite's bit on it