Friday, 30 March 2007

Controlling colors in gnuplot

Today my knowledgeable office mate pointed out to me that one can in fact control the colors of plots in gnuplot, which I had not managed to do before. By default, gnuplot assigns colors to your plots by the order in which you add them, the first one being red, the following green, then blue.

I had always accepted that, until I was plotting multiple data sets today, and all came out red (multiple data sets are made up of data that are in the same column, but in blocks separated by two empty lines; these blocks are accessible by index). I really needed more control here.

Now if I have
plot "datafile" index 0:1 using 1:2 with linespoints
that gives me two plots, both red. The simple trick is to append an index to the end of the command. This index refers to the standard order of addition mentioned above. So now
plot "datafile" index 0 using 1:2 with linespoints 1
plot "datafile" index 1 using 1:2 with linespoints 3
gives me a red and a blue plot. That's all! I never came across this info before.

Oh and if you wonder why block indexing starts at 0 and column indexing at 1: there is a virtual column with index 0, which holds the line numbers. Very useful. Now why the plot index starts at 1... I don't know!

Friday, 23 March 2007

Quick overview of system hardware

I was just looking to install more memory (I've come to the point where there's only at most one reason a month to start up the original WinXP install on my laptop, and now I want to play with running it inside qemu), and I wanted to know if there's a free memory bank in the laptop. The lshw program tells you such things - and lots of other stuff. Here's the part I needed:

description: System Memory
physical id: a
slot: System board or motherboard
size: 512MB
capacity: 2GB
description: SODIMM DDR Synchronous [empty]
physical id: 0
slot: DIMM #1
description: SODIMM DDR Synchronous 333 MHz (3.0 ns)
product: NT512D64SH8B0GM-6K
vendor: 7F7F7F0B00000000
physical id: 1
serial: 41663624
slot: DIMM #2
size: 512MB
width: 64 bits
clock: 333MHz (3.003ns)

What else could I wish for? It even gives me enough details of the installed memory to find compatible parts by just web-searching with the product-string. Nice.

Tuesday, 20 March 2007

Preventing auto-indent when pasting in vim

Here's a nice feature I came across this morning. Basically you just type ":set paste", go to input mode (and it will in fact show it is in paste mode now), then when you're done you do ":set nopaste", that's it!

Friday, 9 March 2007

Defining shorthand commands in the shell

For all bash users (if, like me, you didn't know this one, you'll be very happy with it): look up the alias feature, described in 'man builtins'.

...always something new to learn when you just pick a random page from 'The Debian Bible' before going to sleep...

Saturday, 3 March 2007

Backup using dump

Following up on my earlier post today about setting up my USB backup drive, here are some pointers to using dump and restore to back up my whole file system. All the information is in this how-to. While dump should be able to run with the whole system online, to make life easier for it and since I don't have anything running that has to stay up, I dropped into single user mode (init 1). Then
dump -0uf /media/usbdisk/{insert/filename} /
restore -C -f /media/usbdisk/
makes a full backup of the file system into the specified file (in this case mounted on /media/usbdisk), and tests it afterwards (that's what restore -C does). In my case, a roughly 6.5G backup took 12 minutes to complete (over USB2.0) - I didn't keep track of the test time.

Of course, for single-file or -directory backups, you need something else. I haven't completely settled on a structural solution, at the moment I'm using a mix of rsync (to save to a network drive) and bzr (to keep revisions of my work without need for a server).

With thanks to our very knowledgeable Computer Officer at work for pointing me to dump.

Drive formatting

Ok, so I've finally arranged for a backup drive of my own, rather than just relying on the network backups at work (which are not off-site!). Starting with formatting, here we go:
sudo mkfs.ext3 -c -c -T largefile -m 1 -v /dev/sda1
where the two c's mean that I wan't to check the disk by both reading and writing, the T option lets me specify the typical use (results in a certain block size and number of inodes that I don't get to worry about), and the m option lets me specify the percentage of blocks reserved for the superuser. I'm not sure about this last value, but it can be adjusted later by tune2fs.

Source of knowledge: man pages. Couldn't find anything about the reserved blocks stuff in a quick Google search, unfortunately.

Side notes: I used GNU parted to setup the partitions, which takes you through the process so gently that I don't need to blog about it, just type help for help at the prompt (and well, if you've never partitioned before, read about the general idea first...). Then there was a silly thing because the device sda1 did not exist, and this page saved me by explaining the use of mknod. I hope that was just a glitch in the way I went about things, normally I guess you don't need to manually add device names for your hot-plugged USB disks...

Just for later reference, this is the output of my formatting command:

$ sudo mkfs.ext3 -c -T largefile -m 1 -v /dev/sda1
mke2fs 1.38 (30-Jun-2005)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
57344 inodes, 14653280 blocks
146532 blocks (1.00%) reserved for the super user
First data block=0
448 block groups
32768 blocks per group, 32768 fragments per group
128 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424

Running command: badblocks -b 4096 -s /dev/sda1 14653280
Checking for bad blocks (read-only test): done 280
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 37 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.

In the end, I skipped the write tests because even the read-only test takes ages on a USB disk. It found one bad block... :( If I want to be more thorough, I can run a write test later using e2fsck with the two c switches.