Yesterday I discovered something weird about the GNOME panel's workspace switcher, which I could not find in the official documentation. It is based on the meaning given to those workspaces that the above mentioned applet is supposed to switch.

As you may know, the concept of virtual workspace may refer to two different mechanisms, which can even be present at the same time.

1. You can have multiple distinct desktops, all independent from each other. You can view only one desktop at a time. The windows can reside on each one of them, and you can send windows from one desktop to the other.
2. The size of every single desktop can be higher than the screen size. In that case you only see a portion of the desktop at a time, and that is called a viewport. If your desktop is 4 times the width of the screen, you have 4 possible viewports. The windows can appear on every viewport, and even across the border between adjacent viewports.

If you use Compiz, for example, you can have both multiple desktops (setting the gconf option number_of_desktops) and multiple viewports (setting the options hsize and vsize), but only viewports can be hosted on the faces of the famous spinning cube.

The GNOME panel has an applet that shows the content of the different workspaces and let you switch from one to another. GNOME documentation uses the term workspace without specifying if it refers to desktops or viewports.

Now, I have discovered this weird rule: if there are more than one desktop, GNOME's term workspace means desktop, but if there is only one desktop, then it immediately means viewport.

I find this undocumented "feature" very counter-intuitive, and indeed it can lead the unaware user to hours of frustration.

To use the embedded wireless card on my Compaq Presario laptop, I resorted to the Windows driver loaded with ndiswrapper.

Everything works flawlessly. The only weird thing is that, the network interface must be up before loading the driver. So I have to run:

# ifconfig wlan0 up

# iwconfig wlan0 

The last weekend I felt like experimenting a little with encrypted partitions.

Setting up everything is pretty straight forward: it's just about following one of the several tutorials available on the net. What I really wanted to understand was whether, or how much, the encryption/decryption overhead can slow down the normal I/O activity.

To do so, I prepared an admittedly over-simplified testing procedure:

1. format a partition & mount it:

# mkfs -t ext3 -O dir_indiex,sparse_super PARTITION
# mount PARTITION /mnt

2. write test:

# time dd if=/dev/zero of=/mnt/largefile bs=1M count=100

3. read test:

# time dd if=/mnt/largefile of=/dev/null bs=1M count=100

4. create a lot of small files:

# time for x in {1..9999}; do touch /mnt/test$x; done

5. stat the previously created files:

# time ls -l /mnt >/dev/null

6. unmount the partition:

# umount /mnt

I chose an empty partition on my hard disc and repeated the procedure twice: on the partition itself, and on an encrypted volume created on top of it with:

# cryptsetup luksFormat -c aes-cbc-essiv:sha256 PARTITION
# cryptsetup luksOpen PARTITION ctest

I don't want to post numeric results here, since it doesn't make sense to compare absolute figures with tests as rough as those ones. But what I found out is that the only remarkable difference is in the write test, where the encrypted partition is three times slower than the regular one. Incredibly enough, all the other tests do not show significant difference between the two setups.

I have become conscious that the two commands that I use most of the time in a shell are ls and less, and usually in that exact order. So I spend a lot of time going at the beginning of the current command line and editing the ls into a less.

Now I have added an entry to ~/.inputrc that binds the F12 key to the action "replace the first word with less".

This is the entry:

"\e[24~": "\C-aless\ed\C-e"

Of course, to test it in a shell, one should type:

$ bind '"\e[24~": "\C-aless\ed\C-e"'

At last, I have my Internet connection!

After "only" 6 months from subscription, Fastweb (second phone company in Italy) managed to activate my DSL.

To balance such delay, there is one point that I, as a Debian fan, found highly attractive: a Debian mirror inside Fastweb's subnet. This means full-bandwidth download of packages and instant upgrades.

Having been stuck to 640 kbit/s for years, I'm experiencing a new life!