https://www.spek.cc/

Because GitHub recently disabled new downloads, the tarballs are now hosted on Google Code.

I also added a new tag for the applet in case you want to follow just x-l-a related posts.

I reviewed and committed a bunch of (mostly long overdue) patches in Banshee and taglib-sharp, and released a new version of the latter. We also discussed with Udesh his project and went through some technicalities.

I want to thank David for organising the event, GNOME Foundation for covering my plane tickets and our sponsors for making it happen:

Looking forward to finally meeting fellow Banshee developers!

I managed to solve 5 problems and to rank 145th out of 1890 contestants, spending about 12h in total during the weekend. There were a few technical quirks in the process, but all in all I really enjoyed the sprint and was pleasantly surprised by the quality and the complexity of the problems.

In this post I will explain how I solved those 5 problems; it's mostly for myself, to straighten the thoughts out, as it was a bit chaotic and stressful during the contest.

If you are interested in solutions make sure to check out the official CodeSprint website, they should have them available in a couple of days.

Picking Cards

Links: problem, solution

Sort cards by their number, then take them one by one. On step n the number of ways is multiplied by the number of cards at the beginning of the deck with c_i ≤ n. If this number is 0, it's impossible to pick up all the cards.

The brute-force approach is O(N²) and could be too slow. To speed it up, we keep track of the last m : c_m ≤ n and start from there. As m is never decreased the overall complexity is O(N).

Coin Tosses

Links: problem, solution

On each toss we either have a head or a tail, so the expected number of remaining tosses T(n, m) = 1 + ½ × [T(n, m+1) + T(n, 0)]. We could try a dynamic programming approach, but the formula is cyclic.

However, for m = 0 the expected number of tosses can be expressed analytically: T(n, 0) = 2ⁿ⁺¹ - 2 (proof). Add the boundary condition T(n, n) = 0 and memoisation, and you have a solution.

Fraud Prevention

Links: problem, solution

One of the company-sponsored problems. We want to normalise email and street addresses and to keep two hashes with the combination of the normalised values and the deal IDs as keys. For each key we keep a list of credit cards along with order IDs. Then we process orders one by one and check all possible cases (see the source code comments).

I found this problem a bit uninteresting for a contest -- it's tedious and, uhm, un-algorithmic. However it would probably make a decent interview questions with all its practicalities.

Subsequence Weighting

Links: problem, solution

Generalisation of the Longest increasing subsequence problem. The algorithm is very similar: take each value one by one and maintain values (and cumulative weights) of the last elements of subsequences of certain weight. After we process all values, the last element will have the maximal weight.

One complication is that we need a data structure with efficient insertion, deletion, search and traversal times. One possibility is to use a red-black tree (as implemented by std::set) and augment it so that all nodes form a doubly-linked list. Also, unlike with the LIS algorithm, each insertion can lead to many deletions (see lines 74-82).

With such a data structure, the running time is still at O(n log n).

That was my favourite question, and the one I spent the most time on, even though in retrospect it doesn't look all that complex.

Quora Nearby

Links: problem, solution

Another company-sponsored problem. A pity N was quite small and the brute-force approach actually worked. Higher limits would require a clever data structure, such as the k-d tree and would make the problem much harder and more interesting.

First we read all topics and questions and create a vector of all topics (ID and co-ordinates) and a map of topic IDs to the lists of question IDs.

Topic queries are straight-forward: we sort topics by distance (and IDs, in case the distance is the same) and print the first m IDs.

For queries it's a bit more involving: again, we sort topics by distance, then check all associated questions using our map. The complication is that we need to check all questions for topics with the same distance, and include those with higher IDs.

Please never mind the code for this problem, my solution was accepted literally 5 minutes before the contest ended, as you can imagine I was a bit in a hurry.

Big thanks to the Interviewstreet team for a great weekend!

Today I'm happy to announce the availability of the muspy API. The API allows you to create and modify user accounts, to manage the list of artists you want to follow and to receive their releases.

Someone is already working on an iPhone app that will use the API, expect more news on this front soon!

To make it easier to populate the list of artists you want to follow, muspy allows to import top artists from your Last.fm account. Today this function became more flexible: in addition to getting overall top artists, it can now import most frequently listened artists in the last 12, 6 and 3 months and 1 week.

I also lifted the limit on the number of artists that can be imported from 200 to 500, and increased the number selected by default from 50 to 100.

Do you have a feature that you want to see in muspy? Let me know! Alternatively, feel free to fork muspy on GitHub and to send your pull requests.

If you are a music lover and never tried muspy before, give it a go! With muspy you will not miss an album release ever again.

I wrote muspy 3 years ago to scratch a personal itch -- I was spending too much time online checking if bands I'm into have something new; but was still missing many releases.

muspy was initially developed for Google App Engine, which was the hot new thing back then. In retrospect, while working with App Engine was extremely educational and a lot of fun, it wasn't a very good fit. The recent announcement on the price increase was the last straw -- I decided to re-write it in vanilla Django and to host it myself.

I'm also releasing the source code under GNU AGPL in the hope that it will be beneficial for the service and for its users.

Major changes since the previous version:

• Track release groups instead of releases

  This was the most frequently requested feature, there were too many duplicate releases for some artists, release groups make everything much cleaner. This change was also the reason why the new version is almost a complete rewrite.

• Stars are off by default for new releases

  muspy allows to star individual releases, starred releases show up on top of the sorted list of releases. This feature wasn't used by many which resulted in all releases being starred for most users. Now stars are off for new releases, if you want to star, you have to do it manually on the website. I migrated stars only for users with S \< min(R, 40) / 2, where S is the number of starred releases and R is the total number of releases for all artists you follow.

• Speed

  It used to take more than a week to check all artists for new releases, now the checking cycle is much shorter. Things like importing from Last.fm or adding a comma-separated list of artists should also be significantly faster.

• Blog

  I will be blogging about muspy blog instead of on the website itself. Feel free to subscribe to the full feed or just to the muspy category.

Other than that, muspy remains pretty much the same. I migrated all the data but I encourage you to go the old site at muspy.appspot.com and to check if everything was migrated correctly. Please note that the old site's background processes are not running and it will be taken down in a month or two.

Now that muspy is free and open-source, don't hesitate to look at the code, tweak it and suggest improvements. Git and GitHub make it too damn easy!

And if you never used muspy before, give it a try!

I recently took over xmonad-log-applet maintainership from Adam Wick, and today I'm happy to announce the release of version 2.0.0.

Changes since the previous release:

• Migrated the GNOME 2 applet from deprecated libbonobo API to the new D-Bus based API.

• GNOME 3 panel support (in fallback mode).

• Xfce 4 panel support.

• Revamped the build system.

• Dropped GConf dependency which was used to specify the applet width; instead fill all available space (like the window list applet) and ellipsise when necessary.

• Simplified background transparency handling.

• Fixed install locations.

• Updated sample xmonad.hs.

To install get and unpack the tarball or clone the repo, then run:

% ./configure --with-panel=gnome2
% make
% sudo make install

Substitute gnome2 with gnome3 or xfce4 if that's what you use. If you cloned the git repo, use ./autogen.sh instead of ./configure. After restarting the panel you should be able to add the applet.

Use the provided sample xmonad.hs file to bind it to Xmonad. It depends on the DBus package, which currently doesn't compile with GHC 7.x, but it's easy to work around:

% cabal update
% cabal unpack DBus
% cd DBus-0.4
% $EDITOR DBus/Internal.hsc

Replace import Control.Exception with import Control.OldException, then:

% cabal configure
% cabal build
% cabal install

After this, your xmonad.hs should compile.

EDIT: With GHC 7.4, you also need to edit DBus/Message.hsc and prepend Foreign. to unsafePerformIO.

Happy Xmonading!

At the new job I will mostly be dealing with Perl and, considering it's not the language I'm most familiar with, I was looking for a small project to practice it.

Thus, updating.versia.com was born. It's a web feed that keeps track of the /usr/ports/UPDATING file. I personally find it much easier to use a news reader than manually checking the file each time I want to update my ports.

Like most Perl scripts, the one generating the feed is short, uses a lot of CPAN modules, and is a bit ugly :) You can check it on GitHub.

P.S. As requested on freebsd-ports@ I also added feeds to head/UPDATING, stable-7/UPDATING and stable-8/UPDATING. Subscribe on updating.versia.com

This post will explain how to set up a NAS server with Debian running essential services such as ssh, samba, nfs, cups, rdiff-backup and rtorrent with a web interface; and using two HDDs in RAID 1 mode with everything encrypted. It took me awhile to research all bits and pieces, hopefully it will save you time if you are going to do a similar set up.

Table of contents

• Hardware

• Partition layout

• Finalising the installation and fixing GRUB

• SSH and sudo

• Padlock modules

• NFS

• Samba

• CUPS

• rTorrent + ruTorrent

• Backup with rdiff-backup

• Performance

• Growing partitions

• A2000 tweaks

Hardware

I use a VIA ARTiGO A2000 barebone storage server. It's powered by a VIA C7-D processor, which has a built-in encryption engine called Padlock — quite useful for our scenario. If you are unsure which server to get, I can highly recommend A2000.

Some parts of this walk-through are specific to A2000 or C7, but most of it will apply to any hardware as long as it includes two HDDs and is compatible with Lenny.

Partition layout

I assume that you know how to use the Debian installer, if not — check the documentation. Because A2000 doesn't have a CD-ROM, I booted the installer from a memory stick, you might need to do the same.

The tricky part of the installation process is disk partitioning. I used the following layout, though there are many ways to do the set up.

First we create RAID 1 partitions. We need a separate partition for /boot, because it won't be encrypted; and for /tmp, because it will have encryption settings different from the root partition. This means we will have three partitions on each disk:

• Select FREE SPACE on hda and create a new partition.

• I used 512 MB for /boot, change it to what feels sane to you.

• Make it a primary partition at the beginning of the disk.

• Change "Use as" from "ext3" to "physical volume for RAID".

• Set the bootable flag.

• Create another RAID partition on hda for /tmp. I used 2 GB, again adapt it to your needs. Don't make it bootable.

• Create yet another RAID partition on hda occupying the rest of the disk space.

• Do the same for hdb.

• In the main partitioning menu select "Configure software RAID". Write changes to the partition table when it asks you to.

• Select "Create MD device" then "RAID1". Use defaults for the number of active and spare devices.

• Choose /dev/hda1 and /dev/hdb1.

• Do the same for /dev/hda2 and /dev/hdb2.

• Do the same for /dev/hda3 and /dev/hdb3.

Phew, that was quite a few steps! Now you will see three RAID1 devices in the list, let's set them up:

• Select device #0, change "Use as" to "ext2". Set mount point as /boot.

• Select device #1, change "Use as" to "physical volume for encryption". Set "Encryption key" to "Random key" ¹

• Select device #2, change "Use as" to "physical volume for encryption". Leave "Encryption key" as "Passphrase".

• Select "Configure encrypted volumes" and enter a passphrase. Make sure you use a strong one but remember that there is no way to recover any of your encrypted data if you lose it.

You should see two encrypted volumes now: md1_crypt is automatically set up to be used as swap (do it manually if it's not); md2_crypt however needs more tweaking.

• Edit it and change "Use as" to "physical volume for LVM".

• Select "Configure the Logical Volume Manager" from the main menu.

• Create a volume group, call it something (e.g. "MAIN").

• Select /dev/mapper/md2_crypt device for the created group.

• Create a logical volume for the root partition. Change its size, I used 10GB.

• Create another logical volume for the data partition. Use all remaining space.

• In the main menu, select LV root. Change "Use as" to "ext3" and "Mount point" to "/".

• Select LV data. I formatted it with XFS file system because of this benchmark, but you can select ext3 if you want.

• When mounting, select "Enter manually" and enter "/data".

That's it! With this scheme, data and root partitions sit on top of an LVM group, which sits on top of an encrypted volume, which sits on top of a multi-disk volume. Some people prefer to have separate encrypted partitions for root and for data, but then you will need to enter passphrases for each of them on start up.

Finalising the installation and fixing GRUB

The rest of the installation should be straight-forward. When you reach the "Software selection" screen, make sure you choose "Standard system" and "File server"; and unselect "Desktop environment" — you are not going to need it on a headless server. Also tick off "Print server" if you need (I do).

After everything is installed, boot your server, type your passphrase to unlock the encrypted partition, and login as root. Now, because the installer writes GRUB only to the first disk, we need to install it manually to the second. Without this, if your first disk fails you won't be able to boot:

# grub
grub> root (hd1,0)
grub> setup (hd1)
grub> quit

SSH and sudo

Let's install SSH, otherwise we will need a spare monitor and a keyboard connected to the server:

# aptitude update
# aptitude install ssh

Edit /etc/ssh/sshd_config, I suggest disabling PermitRootLogin and PasswordAuthentication and enabling PubkeyAuthentication. If you decide to use public key authentication, add your public key to ~/ssh/authorized_keys. Then restart sshd, install sudo, and edit the list of sudoers:

# /etc/init.d/ssh restart
# aptitude install sudo
# visudo

Add this line under root, <user> is your non-root login:

<user> ALL=(ALL) ALL

Padlock modules

This section is specific to VIA C7 CPU. As I mentioned, it includes the hardware encryption engine called Padlock. The engine is supported by the Linux kernel, but the support is not enabled by default.

First make sure you have it:

# modprobe padlock_aes
# modprobe padlock_sha

If the modules load fine, these steps (thanks Google Translate!) will auto-load them:

• Edit /etc/modprobe.d/aliases and add this line:

alias aes padlock_aes

• Edit /etc/initramfs-tools/modules and add these two lines:

padlock-aes  
padlock-sha

• Run update-initramfs -u, it should backup the image in /boot for you, but it never hurts to back it up manually.

These steps are needed because Padlock modules must be loaded at boot, to work with our encrypted partitions. If they are loaded at a later stage, the software encryption modules will not be replaced because they are already in use.

After rebooting, check if Padlock is used. If aes_i586 is in use instead of padlock_aes, you did something wrong:

# lsmod | grep -i aes

To enable hardware encryption for SSL, edit /etc/ssl/openssl.cnf and add this before the [new_oids] section:

openssl_conf = openssl_def

[openssl_def]
engines = openssl_engines

[openssl_engines]
padlock = padlock_engine

[padlock_engine]
default_algorithms = ALL

After the change, observe an enormous speed bump with:

# openssl speed -evp aes-128-cbc

NFS

If you selected "File server" during the installation, NFS should already be up and running. To share the entire /data partition, edit /etc/exports and add this line:

/data   *(rw,sync,no_subtree_check)

Check NFS documentation if you want something different. After changing your exports, reload them with:

# exportfs -a

On the client computers, add this line to /etc/fstab, replacing <server> with the IP of your NAS:

<server>:/data /mnt/data nfs defaults 0 0

Then mount with mount -a. Again, check the docs if you need more control over how the NFS share is mounted.

Samba

As with NFS, Samba should already be running on your server. Append this to /etc/samba/smb.conf, replacing <user> with a non-root login on your server:

[data]
    path = /data
    browseable = yes
    available = yes
    public = yes
    writable = yes
    force user = <user>
    create mask = 0644
    directory mask = 0755

Then restart Samba and you are set:

# /etc/init.d/samba restart

Check Samba docs for more options.

CUPS

The set up heavily depends on the printer model. I have a fairly common Epson colour ink printer, its driver is included in the gutenprint package which gets installed if you select "Print server" during the installation.

You will need to edit /etc/cups/cupsd.conf to make the CUPS web interface accessible from another machine, then just add your printer from http://localhost:631/. Also check /etc/samba/smb.conf, it should have these sections:

[printers]
   comment = All Printers
   browseable = yes
   path = /var/spool/samba
   printable = yes
   guest ok = yes
   read only = yes
   create mask = 0700

[print$]
   comment = Printer Drivers
   path = /var/lib/samba/printers
   browseable = yes
   read only = yes
   guest ok = no

Check CUPS docs if it doesn't work or if you want to fine-tune permissions.

rTorrent + ruTorrent

FreeNAS comes with Transmission BitTorrent client. It looks nice but the web interface is too simple to my taste, it doesn't even support labels. On the desktop I used to run Deluge, which is great but probably a bit heavy for a small server. After a bit of research I ended up using rTorrent, which is what most blogs recommend for a headless server.

There are quite a few frontends for rTorrent, the one I liked was ruTorrent, its development also seems to be the most active at the moment. It's an almost exact rip-off of a popular Windows-based μTorrent client, hence the name.

ruTorrent requires a recent version of rTorrent compiled with the XML-RPC support. The bad news is that Lenny doesn't have all packages required to build it. This can be circumvented by temporarily switching to testing (aka Squeeze), installing rTorrent's build-deps, then switching back to Lenny. Depending on your situation, switching to testing may not be the best idea, do it only if you are comfortable breaking your system.

After installing build-deps, get the latest tarball of rTorrent, ./configure it with --with-xmlrpc-c option, make and make install. Afterwards, copy an example .rtorrent.rc file to ~/ and edit it to suit your needs. Also follow the steps in the Starting rTorrent on System Startup section.

ruTorrent can work with any web server supporting PHP 5.0, I went for lighttpd. Install it from the official repo, then follow ruTorrent set up guide.

The tricky part is setting up XML-RPC, there are a few contradictions in the the rTorrent and ruTorrent docs but the following works for me™:

Add to ~/.rtorrent.rc:

scgi_port = localhost:5000
encoding_list = UTF-8

Edit /etc/lighttpd/lighttpd.conf as described here. Ignore instructions from rTorrent, they won't work. Restart rTorrent and the web server after you are done:

# /etc/init.d/rtorrent restart
# /etc/init.d/lighttpd force-reload

Backup with rdiff-backup

rdiff-backup is such a fantastic tool: it's available on all major platforms, it's ultra fast and efficient, it performs backups incrementally, it can work over SSH and also it allows to restore files at any point of time. If you don't already use it to backup your home directories — give it a try!

On the server, there's nothing special to be done to install it. Just get it from Debian repos and add your public keys to ~/ssh/authorized_keys — we are going to use SSH.

On Linux clients, invoke it like this, replacing <user> with your login and <server> with the IP of the NAS:

% rdiff-backup /home/<user> <server>::/data/Backup/<user>

On Windows clients, install Putty and follow these steps to generate a compatible key. Then invoke rdiff-backup like this:

rdiff-backup.exe --no-hard-links --remote-schema
    "plink.exe -i C:Users<WinUser>privatekey.ppk %s rdiff-backup --server"
    C:Users<WinUser> <user>@<server>::/data/Backup/<user>

Check rdiff-backup docs for more options, there are plenty!

Performance

Extremely unscientific tests, but they give an idea:

# bonnie++ -d /data/tmp
Version 1.03d       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
server           2G 10862  91 63699  27 29931  12 11483  91 83455  22 196.7   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16  2693  67 +++++ +++  3467  37  2948  47 +++++ +++  3131  38
#
# sync
# dd if=/dev/zero bs=16384 count=131072 of=/data/tmp
131072+0 records in
131072+0 records out
2147483648 bytes (2.1 GB) copied, 40.7823 s, 52.7 MB/s
#
# sync
# dd if=/data/tmp bs=16384 count=131072 of=/dev/null
131072+0 records in
131072+0 records out
2147483648 bytes (2.1 GB) copied, 23.5763 s, 91.1 MB/s

# hdparm -tT /dev/mapper/md2_crypt 

/dev/mapper/md2_crypt:
 Timing cached reads:   584 MB in  2.01 seconds = 291.10 MB/sec
 Timing buffered disk reads:  222 MB in  3.03 seconds =  73.19 MB/sec

hda is a 1TB WD Caviar Green, hdb is a 640GB Seagate Barracuda. I know, using different disk models is bad for RAID 1, but that's what I had. At some point I will get a second 1TB WD, read the next section to find out how to grow the mirror when upgrading drives.

NFS transfers are slower, but good enough for my needs: 49 MB/sec when reading from a NFS share and 23 MB/sec when writing to it.

Growing partitions

When your RAID 1 mirror is filled up you probably want to upgrade the disks with bigger ones. This can be done by replacing the first disk, syncing the mirror, then replacing the second one, and syncing again. After that you need to grow your data partition.

So, shut down your NAS, replace one of the drives, boot up and SSH to it. Check the status the mirror, notice that only one drive is used:

# watch -n 2 cat /proc/mdstat

Personalities : [raid1]
md2 : active raid1 hda3[0]
      622679296 blocks [2/1] [U_]

md1 : active raid1 hda2[0]
      1951808 blocks [2/1] [U_]

md0 : active raid1 hda1[0]
      497856 blocks [2/1] [U_]

unused devices: <none>

Here I assume that hda is used and hdb has been replaced, run fdisk -l to check which is which in your case. Now copy the partition table from hda to hdb:

# sfdisk -d /dev/hda | sfdisk /dev/hdb

Adjust the last partition on hdb: run cfdisk /dev/hdb, select hdb3 and delete it, re-create hdb3 to use the entire free space, change the partition type to "FD Linux raid autodetect", and finally write changes to disk and quit.

Add new partitions to the RAID array and wait until the sync is finished:

# mdadm --add /dev/md0 /dev/hdb1
# mdadm --add /dev/md1 /dev/hdb2
# mdadm --add /dev/md2 /dev/hdb3
# watch -n 2 cat /proc/mdstat

Add grub to hdb:

# grubgrub> root (hd1,0)
grub> setup (hd1)
grub> quit

If you replaced the drive with a bigger one, you need to grow the last partition to take advantage of all available space. Here's how to do it (the steps are borrowed from here):

# mdadm --grow /dev/md2 --size=max

Reboot, then run this:

# pvresize /dev/mapper/md2_crypt
# vgdisplay -A | grep -i free
  Free  PE / Size       X / Y GB

Note the number X, we will use it in the next command. Also replace MAIN-data with the name you used for the /data partition:

# lvextend -l +X /dev/mapper/MAIN-data

Finally, grow the filesystem:

# xfs_growfs /data

The previous command will only work for XFS, adapt it if you use ext3 or another file system.

A2000 tweaks

Inspired by this forum post I replaced stock A2000 fans with Scythe Mini Kaze SY124010L 40mm fan on the CPU and Noctua NF-R8 80mm fan on the rear exhaust. This made A2000 even more quiet. Other than that, I cannot think of any other mod I would like to do, A2000 is a very nice piece of hardware.

I'm building a small NAS for the household. It will run FreeNAS and will be used as a file, rsync, BitTorrent and printer server. I want it to be reliable and secure so it will have two HDDs in RAID 1 (AKA mirroring) and their content will be encrypted.

But what if in the future I will want to upgrade the drives with larger ones? A common scenario with RAID 1 is to replace one of the disks with the bigger one, rebuild the mirror then replace the other one and rebuild it again. In theory it sounds like an easy process that will keep all your data intact.

In practice however it's not, Mike explains how to do it under FreeNAS in his blog. Growing mirrored and encrypted drives is a bit more complicated.

Here is how, in case you might need it:

• After replacing the HDD, boot your box and log into the FreeNAS web interface

• Go to Disks/Management, edit the disk you have replaced and click "Save". This will read the new disk's size.

• Go to Disks/RAID, the status will be DEGRADED which is normal. In Tools select the new disk, "forget" and then "insert" it. Wait until the rebuild process is finished.

• Go to Disks/Encryption, attach the disk and make sure your data is fine.

• Go to Disks/Mount Point and delete the mount.

• Get to the NAS console, either directly or via SSH. Things will get more interesting now:

# geli backup /dev/mirror/raid1 bak
# geli detach /dev/mirror/raid1
# geli clear /dev/mirror/raid1

• geli is the command line tool to manage encrypted storage in FreeNAS. raid1 is the volume name I used, yours might be different. The first line saves the encrypted volume's metadata to a file called "bak", we will need it later.

• Go to Disks/RAID again, delete and re-add the RAID. Use the same volume name and tick the "Create and initialize RAID" check box.

• Now back to the terminal. This will restore the metadata from our backup and re-attach the encrypted volume

# geli restore bak /dev/mirror/raid1
# geli attach /dev/mirror/raid1

• Fix the partition table, re-create and grow the partition to fill the entire disk (note that the device name ends with ".eli" – it's our encrypted disk):

# gpt recover /dev/mirror/raid1.eli
# gpt remove -i 1 /dev/mirror/raid1.eli
# gpt add -i 1 -t ufs /dev/mirror/raid1.eli
# gpt label -i 1 -l data /dev/mirror/raid1.eli
# growfs /dev/mirror/raid1.elip1

• Finally go to Disks/Mount Point and mount the partition.

That's it, your encrypted partition should be functional now!

NOTE: always do your backups, I can make no guarantees this guide will work for you.

The good news is: xmonad plays really well with GNOME. You can keep your GNOME panels, themes, desktop backgrounds, etc – xmonad just replaces Metacity leaving everything else intact.

The bad news is: I should have tried it earlier.

A few notes about xmonad set up and usage:

• Recommended way to set up xmonad with GNOME is to export WINDOW_MANAGER=xmonad before starting gnome-session, but it didn't work for me. I tried every suggested place: ~/.gnomerc, ~/.xsession, ~/.profile, ~/.xinitrc; but none of them worked – GNOME always started with Metacity.

  What worked though is this:

• Create a file in /usr/share/applications called xmonad.desktop:

[Desktop Entry]
Type=Application
Encoding=UTF-8
Name=Xmonad
Exec=/usr/bin/xmonad
NoDisplay=true
X-GNOME-WMName=Xmonad
X-GNOME-Bugzilla-Bugzilla=XMonad
X-GNOME-Bugzilla-Product=xmonad
X-GNOME-Bugzilla-Component=general
X-GNOME-Autostart-Phase=WindowManager
X-GNOME-Provides=windowmanager
X-GNOME-Autostart-Notify=true

• Change this GConf key from 'metacity' to 'xmonad':

/desktop/gnome/session/required_components/windowmanager

• On startup, xmonad doesn't set the usual left-arrow cursor but inherits an ugly X cursor which looks like it was created in the eighties. To change it, add this line to your ~/.xinitrc file just before you start gnome-session:

xsetroot -cursor_name left_ptr

• You need to create a config file in ~/.xmonad called xmonad.hs and add this:

import XMonadimport XMonad.Config.Gnome main = xmonad gnomeConfig

• That's right, the config file is a Haskell program that starts xmonad, which means it's extremely customisable.

  All keyboard short-cuts in xmonad are in the form Mod-X or Mod-Shift-X, where Mod is by default the Alt key. Line 7 tells xmonad to use the Win key – Alt is heavily used by GNOME applications:

import XMonad
import XMonad.Config.Gnome

main = do
  xmonad $ gnomeConfig
    { terminal    = "gnome-terminal"
    , modMask     = mod4Mask
    , focusFollowsMouse = False
    , borderWidth = 2
    }

• When touch-typing, some shortcuts are painful to use, Win-Shift-6 probably being the worst. What I wanted is to replace the Mod part with another shortcut, a bit in the Emacs fashion, so that instead of Win-Shift-6 I would have for example a sequence of Ctrl-m and Shift-6.

  mauke on #xmonad was extremely helpful, he came up with this code which worked as advertised:

import XMonad
import XMonad.Config.Gnome
import XMonad.Actions.Submap

import Control.Arrow
import Data.Bits
import qualified Data.Map as M

main :: IO ()
main = do
    xmonad $ gnomeConfig
         { terminal = "gnome-terminal"
         , focusFollowsMouse = False
         , borderWidth = 2
         , keys = addPrefix (controlMask, xK_m) (keys gnomeConfig)
         }

addPrefix p ms conf =
    M.singleton p . submap $ M.mapKeys (first chopMod) (ms conf)
    where
    mod = modMask conf
    chopMod = (.&. complement mod)

• To re-load xmonad after you changed the config file just press Mod-q. It takes just a second to re-compile and leaves all open windows intact.

After using xmonad for 2 days I must say I'm a convert. The keyboard short-cuts feel very natural, it's not difficult to see the influence of vi. Moving a window to another screen or to another workspace (did I mention workspaces are per screen, which is a really neat feature), switching between workspaces, switching windows, changing layouts, etc... is just a short-cut away.

And as a bonus point, I now have a good reason to become more familiar with Haskell – it's a very nice language.

Played tracks are not removed from the queue but are shown as greyed out. You can play them again if you want, drag and drop to the back of the queue, delete, etc.

The number of played tracks to show can be changed from the preferences dialogue.

You can also ask Banshee to automatically update the queue using any shuffle mode (including the new by rating and by score modes). The number of upcoming tracks can also be changed in the preferences.

The tracks are taken from the entire library or from any play list.

If you don't like what has been added, you can refresh the upcoming tracks. Or you can add more of them (thanks Sandy!)

Tracks added manually are treated differently from those that had been added automatically. When adding, they are inserted to the front of the queue but after other manually-added tracks.

Also, they are preserved when you refresh the queue.

That's about it. If you like what you saw you can try the git master version. Otherwise just wait until 1.6 is out, it shouldn't take too long.

In the random shuffle mode (aka shuffle by song), every track has an equal probability to be selected. For example if our library contains 1,000 tracks, each of them will be chosen with probability

P_t = 1 ÷ 1,000 = 0.001

But what if we want some tracks to be played more often than others? Say we have 100 favourite tracks and want to play each of them three times as often as any other track? In probability terms this can be written as

P_s = 3 × P_t

where s are our favourite tracks and t – the other 900 tracks in the library. Because the sum of all probabilities must be equal to one, we have

100 × 3 × P_t + 900 × P_t = 1 → P_t = ¹/_1,200

To chose the next track, we can pretend that our library contains 1,200 songs and pick one at random. If the track number is ≤ 100 × 3, we randomly select one of the 100 favourite songs, otherwise we take one of the 900 remaining songs.

If the library is partitioned into n slots, each containing C_i tracks, we will have

∑_i=1,n C_i ⋅ w_i ⋅ P₁ = 1

where P₁ is the probability of selecting a track from the first partition, and w_i tells how frequently tracks from the i-th partition should be selected compared to the first one. That is P_i = w_i ⋅ P₁

Numbers w_i are called weights and by changing them we control how often the songs from different slots are played. For example, we could pick a number (lets call it β) and require that songs from the second partition are played β times as often as the songs from the first one, songs from the third β times as often as the songs from the second, and so on. That is, w_i = β^i-1

For ratings, we have 5 partitions – one for each rating. We could also put all unrated songs into the 3-rd partition (to treat them as songs with 3 stars) so that our entire library is partitioned. Now a good question is what to use for β?

If we take β=1, all songs will have an equal probability to be selected. Note that it's exactly the same as the shuffle by song mode. If we take β=2, songs rated 5 will be played twice as often as songs rated 4, and so on.

In Banshee we use β = φ ≈ 1.61803, also known as the golden ratio. This number has an interesting property:

φⁿ = φ^n-1 + φ^n-2

In terms of ratings, it means that songs with 5 stars will be played as often as songs with 4 and 3 stars combined, and so on.

In the shuffle by score mode, the songs are partitioned into 20 slots, first slot for the songs scoring 1…5, second – for 6…10, and the last – for scores 96…100. We also put songs with no score into the 10th slot (46…50).

We cannot use φ for β because this time we have much more partitions – the songs with low scores would be hardly ever played. To keep scores behaving similar to ratings we need to scale the weights:

β = φ^¼, w_i = φ^(i-1)/4

Hope that wasn't too tangled and I promise next post won't include a single formula :)

Window List: bgo#86382 has a working patch, it's not perfect (read comments 140, 141 and 145) but fixes the problem.

Notification Area: bgo#531371 also has a patch which works really well.

Quick Launch: My fix is included in version 2.12.6 of the applet.

Main Menu: The ugly arrow (bgo#562247 and bgo#564903) can be removed by setting "has-arrow" to FALSE in gnome-panel/panel-menu-button.c

Keyboard Indicator: bgo#591515 is not yet fixed. A quick and dirty hack is to comment out the entire switch statement in GSwitchitAppletUpdateAngle() function from gswitchit/gswitchit-applet.c

I'm using a GNOME desktop with all these fixes daily and I'm quite happy with it. You can get my customizepkg files for Arch Linux from GitHub; read how to use them in the previous post.

In this post I will explain how to do it, taking as an example my pet peeve – the vertical Gnome panel. Carey Underwood has recently posted a (mostly) working patch, let's get it into our box.

First thing you need is to install yaourt and customizepkg, both are available in AUR. ArchWiki has a great tutorial on how to do it. Actually you only need the tutorial to install yaourt, afterwards installing packages from AUR is as simple as running:

% yaourt -S customizepkg

customizepkg allows to tweak PKGBUILDs. You just add a file to /etc/customizepkg.d/ with the same name as the package you want to change. The file format is not well documented, but it's pretty intuitive.

In our case we need to create /etc/customizepkg.d/libwnck with the following text (in one line):

replace#global#cd "${srcdir}\/${pkgname}-${pkgver}"
#cd "${srcdir}\/${pkgname}-${pkgver}"\nwget -O vertical.patch
http:\/\/bugzilla-attachments.gnome.org\/attachment.cgi?id=140334
|| return 1\npatch -Np2 -i vertical.patch || return 1

The file will tell customizepkg to add two lines to libwnck's PKGBUILD:

 build() {
   cd "${srcdir}/${pkgname}-${pkgver}"
+wget -O vertical.patch http://bugzilla-attachments.gnome.org/attachment.cgi?id=140334 || return 1
+patch -Np2 -i vertical.patch || return 1
   ./configure --prefix=/usr --sysconfdir=/etc
               --localstatedir=/var --disable-static || return 1
   make || return 1

Then you just install the package as you always do, but using yaourt instead of pacman:

% yaourt -S libwnck

Et voilà, yaourt realises that you want to build libwnck from source, gets its PKGBUILD, changes it, and builds. When building, the patch is downloaded and applied to the source code of libwnck before it's made.

But wait, there's more to it! Next time you upgrade the system with yaourt -Syu, if there is a new version of libwnck, it will be automatically patched and built from source.

Hope you find this useful, and if you haven't tried Arch yet – do it today, you won't be disappointed ;)

I've been playing with various desktop GNU/Linux distributions last couple of months. I'm not exactly a newbie to Linux, I have been administering a VPS box for a hobby project for several years now, but I never managed to play with it on a desktop.

So I did. And I must say I'm very impressed. Last time I checked (FreeBSD 4 back in 2000), FLOSS desktop was mostly a geek toy, these days it is ready for the average user.

I will spare the overview of the distros that I tried, as well as my take on the KDE vs. GNOME flame war for another post, here I want to talk about one particular annoyance that I really want to see fixed.

You see, these days it's hard not to have a wide-screen monitor sitting on your desktop. They are great for watching films and playing games but this comes at a cost -- you end up with fewer vertical pixels.

Vertical space is much more important for most other tasks I do on the computer, be it browsing the web, coding or writing blog posts. And the only way to maximise it is to move the everlasting task bar sitting on the bottom of most operating systems to the left or right of the screen.

This is how it looks like in Vista and KDE. I know it takes some getting used to, but it's worth a few days of slight disorientation. And I'm not the only one who thinks so.

The vertical layout works great in XP, Vista and KDE, but not in GNOME. I want to list here all open issues along with the links to the GNOME bug database. I guess we have all these issues because not many GNOME developers are using the vertical layout, or even aware of the benefits it can give them. I hope this post will help it, even if only a little bit.

Window List: The list of open windows is arguably the most important piece of information sitting on the panel. And the most terribly behaving in vertical layout.

First of all, the height of the window list applet is fixed, meaning the list doesn't occupy all available vertical space.

Second, the height of the buttons that represent the open windows, stretches to fill the entire applet. The buttons should have a fixed height that depends on the font used in the buttons.

Third, after you open a few windows, the list splits to two columns and becomes irresponsible to mouse clicks. This is the most annoying bug of the three.

These issues are documented in bug 86382 that was open back in 2002! The bug has a patch, but it looks like it's not perfect either.

Notificatioin Area: In vertical layout the notification area wastes a lot of space by placing one icon in a row. It also uses different sizes for different icons, some are really huge, e.g. 128x128. It should instead use a flow layout for icons and use the same size for all of them. This is described in bug 531371.

Quick Launch: The quick-lounge applet had a bug that made it nearly impossible to use on a vertical panel (see bug 531358). It's fixed now in the trunk, hopefully it will be integrated into the next GNOME release.

There are other related annoyances (see bug 428943 and Ubuntu idea #1906) but I can live with them if the above issues are resolved.