Amita June is reaching a point in her life where it's time for us to start weaning her from breastfeeding. Most parents do this much earlier, if they breastfeed at all, but we've been devotees of attachment parenting for a while, and we wanted to give her as much time nursing as possible. But at 15 months, she's ready to start doing things like sleep through the night on her own, drink only cow's milk, and be a little more independent. So, this month we're starting to do some night weaning. What does this mean? First of all, Maj is no longer nursing the baby to bed. She now is doing the main pre-sleep prep work (a bath), does a short nursing period, and then hands the baby off to me for some reading, songs, and walking down to sleep. This will gradually move into fewer, shorter nursings before sleep, and ultimately to none. Once that connection has been broken, I think the main point of nursing will be occasional comfort nursing during the day. Gradually, that will fade out. And then there will be none. It's kind of exciting to be the Primary Sleep Guy for the baby. We're re-connecting in a way that we haven't in a while -- I was only putting her to bed occasionally for a quite a while. It's also been pretty successful so far, which has been good. tags: amitajune weaning sleep parenting babies

Souper Bruncher When Maj and I first moved to Montreal, we had help from some friends who we'd known from before. After we moved into our apartment, we invited them all over for dinner to say thanks. In order to get to know people in our new hometown, we also asked each person to bring someone we didn't know, so we could make new friends. The event was so successful, and we met so many new people, that we made it a regular occasion. For almost three years, every Tuesday night we invited friends over to our home for dinner (or souper in Quebecois French), with an open invitation to meet new friends and interesting people. It was a great way to meet interesting folks in Montreal, and most of our best friends here we met through these dinners. We were even profiled in Elle Quebec as a model for how to make new friends. But when the baby was born, we just couldn't manage to organize dinners any more every week. Cooking for 20+ people isn't that expensive, especially since we're pescevegetarians and that kind of food just isn't that costly. But it does take a lot of time and energy, and with a newborn baby we just didn't have either. Now, with Amita a little more than a year old, we're trying to start up our regular home parties on a more manageable scale. We're doing brunch at our house on Sunday afternoons around 3PM, with a much smaller list of invitees, requests for RSVPs, and a clear indication that the event only goes until bedtime. (Our Tuesday night dinners would occasionally stretch until dawn.) It seems to be working pretty well; we've had a lot of fun at the last couple of brunches we've had. And brunch is a much more laid-back meal than a dinner party, anyways. (Although John Usher asks incredulously, "By what stretch of the imagination is 3PM between breakfast and lunch?") I'm looking forward to our next brunch (tomorrow) a lot, and I hope to get many more friends over to our home in the next few months of Sundays. tags: brunch montreal making friends souper bruncher

I have just been installing a Xen domU on Debian Etch. I'll blog about installing dom0 later when I have a test system that I can re-install on (my production Xen machines have the dom0 set up already). The following documents a basic Xen domU (virtual machine) installation that has an IP address in the 10.0.0.0/8 private network address space and masquerades outbound network data. It is as general as possible.

lvcreate -n xen1 -L 2G /dev/vg

Firstly use the above command to create a block device for the domU, this can be a regular file but a LVM block device gives better performance. The above command is for a LV named xen1 on an LVM Volume Group named vg.

mke2fs -j /dev/vg/xen1

Then create the filesystem with the above command.

mount /dev/vg/xen1 /mnt/tmp
mount -o loop /tmp/debian-testing-i386-netinst.iso /mnt/cd
cd /mnt/tmp
debootstrap etch . file:///mnt/cd/
chroot . bin/bash
vi /etc/apt/sources.list /etc/hosts /etc/hostname
apt-get update
apt-get install libc6-xen linux-image-xen-686 openssh-server
apt-get dist-upgrade

Then perform the basic Debian install with the above commands. Make sure that you change to the correct directory before running the debootstrap command. The /etc/hosts and /etc/hostname files need to be edited to have the correct contents for the Xen image (the default is an empty /etc/hosts and /etc/hostname has the name of the parent machine). The file /etc/apt/sources.list needs to have the appropriate configuration for the version of Debian you use and for your preferred mirror. libc6-xen is needed to stop a large number of kernel warning messages on boot. It's a little bit of work before you get the virtual machine working on the network so it's best to do these commands (and other package installs) before the following steps. After the above type exit to leave the chroot and run umount /mnt/tmp.

lvcreate -n xen1-swap -L 128M /dev/vg
mkswap /dev/vg/xen1-swap

Create a swap device with the above commands.

auto xenbr0
iface xenbr0 inet static
pre-up brctl addbr xenbr0
post-down brctl delbr xenbr0
post-up iptables -t nat -F
post-up iptables -t nat -A POSTROUTING -o eth0 -s 10.1.0.0/24 -j MASQUERADE
address 10.1.0.1
netmask 255.255.255.0
bridge_fd 0
bridge_hello 0
bridge_stp off

Add the above to /etc/network/interfaces and use the command ifup xenbr0 to enable it. Note that this masquerades all outbound data from the machine that has a source address in the 10.1.0.0/24 range.

net.ipv4.conf.default.forwarding=1

Put the above in /etc/sysctl.conf, run sysctl -p and echo 1 > /proc/sys/net/ipv4/conf/all/forwarding to enable it.

cp /boot/initrd.img-2.6.18-3-xen-686 /boot/xen-initrd-18-3.gz

Set up an initial initrd (actually initramfs) for the domU with a command such as the above. Once the Xen domU is working you can create the initrd from within it which gives a smaller image.

kernel = "/boot/vmlinuz-2.6.18-3-xen-686"
ramdisk = "/boot/xen-initrd-18-3.gz"
memory = 64
name = "xen1"
vif = [ '' ]
disk = [ 'phy:/dev/vg/xen1,hda,w', 'phy:/dev/vg/xen1-swap,hdb,w' ]
root = "/dev/hda ro"
extra = "2 selinux=1 enforcing=0"

The above is a sample Xen config file that can go in /etc/xen/xen1. Note that this will discover an appropriate bridge device by default, if you only plan to have one bridge then it's quite safe, if you want multiple bridges then things will be a little more complex. Also note that there are two block devices created as /dev/hda and /dev/hdb, obviously if we wanted to have a dozen block devices then we would want to make them separate partitions with a virtual partition table. But in most cases a domU will be a simple install and won't need more than two block devices.

xm create -c xen1

Now start the Xen domU with the above command. The -c option means to take the Xen console (use ^] to detach). After that you can login as root at the Xen console with no password, now is a good time to set the password.

Run the command apt-get install udev, this could not be done in the chroot before as it might mess up the dom0 environment. Edit /etc/inittab and disable gettys on tty2 to tty6, I don't know if it's possible to use them (the default and only option for xen console commands is tty1) and in any case you would not want 6, saving a few getty processes will save some memory.

Now you should have a basically functional Xen domU. Of course a pre-requisite for this is having a machine with a working dom0 installation. But the dom0 part is easier (and I will document it in a future blog post).

Since I have been having a digital camera since a few weeks now, I've had a need for an application to manage my pictures. The two applications that people have pointed me to are f-spot and digiKam, which also seem to be the most popular applications in this category for Linux. Since I use neither KDE nor GNOME as my user interface, it doesn't matter much to me which I install; so I've tried them both. Their feature set is quite different; unfortunately, though, they both have some features which the other doesn't, which makes choosing for one or the other rather hard. Since their on-disk format is rather different, it's impossible to use them both at the same time—at least not if I don't want to enter commentary and tags each and every time; so I'll have to choose one or the other based on their features. Since that requires me to actually compare them, I thought I might as well make a blog post out of that. Note, though, that this comparison is in no way intended to be complete; it only compares those features which I really care about. Features digiKam

• Stores pictures in albums; these albums can be created hierarchically, and are created on disk as the directory lay-out in which to store pictures. One picture can be chosen as an example picture per album.
• Pictures can have tags, comments, and a score (on a scale of one to five stars) applied to them. Tags can be created hierarchically; the default tagset is empty. Tags can be made to have icons that are otherwise available to KDE attached to them, to make them more immediately visually recognizable, but selecting pictures to fulfill that function seems impossible.
• Has an interface to manage pictures in gallery and gallery 2; it can view, add, and remove pictures in that gallery.
• The selector dialog which is used to upload pictures is rather spartanic; it allows one to select pictures by filename and by album; pictures aren't even shown before upload (bug filed).
• Pictures can be filtered by tag, album, or date; I haven't been able to find an interface to filter pictures by score (it is possible to sort them by score in any view, though).
• A KDE application, so written in C++, which is a compiled language; i.e., rather fast.

F-spot

• Does not know the concept of albums
• Pictures can have tags and comments applied to them. Tags can be created hierarchically; the default tag set contains (amongst others) People, Places, and Events, suggesting that f-spot encourages the use of tags where Albums would be used in the case of digiKam. Tags can have icons which are otherwise available to gnome selected as their icon, or one can select a picture to fulfill that function (in fact, it selects the first picture which receives a tag to do that by default)
• Does not know the concept of scoring; instead, the default tagset contains a tag Favourites, suggesting a scoring system with a binary scale.
• Uploading pictures can be done by selecting them, and choosing the right option in the menu system. As a result, all filtering options otherwise available can be used to select which pictures to export (just filter the view, then select all pictures in the view).
• Uploading pictures will optionally also export comments that were applied to it.
• Since it does not know the concept of albums, pictures cannot be stored in a one-directory-per-album lay-out. Instead, pictures are stored in a one-directory-per-day layout, using a yyyy/mm/dd format. Unfortunately, this also means that no picture metadata (tags, comments) is easily available to command-line applications.
• Apart from the ability to upload pictures to gallery or gallery 2, does not interface with it in any way; gallery is a write-only storage medium to f-spot.
• Written for mono, a system that requires a runtime environment to translate instructions at runtime from some sort of virtual machine code, and which uses garbage collection all over; i.e., rather slow, especially after you've been using it for a while.

My opinion After having used f-spot for a few weeks before I tried digiKam, I have to be honest and say that I don't like the concept of albums. They do not add value; everything they allow you to express can equally well be expressed with tags. Additionally, one can categorize a picture in only one album, whereas it's possible to categorize pictures in as many tags as you would want. Just creating one album which contains all my pictures, with tagging used for categorizing, doesn't help either; that way, digiKam would store all my pictures in a single flat directory, which would become problematic when the number in the picture filenames wraps around. I do love the scoring thing in digiKam. A favourites tag just doesn't cut it; and creating five tags for scoring would make things like find all pictures that have a score of three or above rather cumbersome, and sort by score outright impossible. However, the fact that it's not possible to filter by score makes it all rather useless. The export to gallery function in digiKam is horrible. I have to select my pictures blindly; none of the metadata which I tack on them can be used to help select which pictures I want. Workaround: use whatever filtering is available to select the right pictures and add them to a temporary album from which I then upload all pictures, but that's silly (and requires disk space for no good reason). Additionally, there seems to be a bug in the interface, which means that I have to babysit an upload (with no workaround). And I can't even view my pictures to spend the time waiting. Bah. F-spot isn't without problems of its own. Due to a bug in mono, it crashes rather often on my PowerPC laptop. When that happens, it can't be restarted until the X server is restarted. Workaround: use Xnest, but that makes it impossible to view pictures in full-screen mode. Also, since f-spot is a GNOME application, its options dialog is as helpful as a pair of soccer shoes when you're out swimming. No surprises there. Conclusion Which one do I prefer? I'm not sure. The digiKam upload interface is positively annoying, especially the bug which requires me to click continue after every picture. For that alone, I might ditch it. On the other hand, it has a slew of interesting features (the scoring, to name one) that f-spot lacks, and that pull me more towards digiKam. I guess I'll have to give it a few days of thought. But hey, at least I know where I stand now.

Experiences with a Trac Server In the last few days after Xmas I set up http://trac.cs.unibo.it, a server for my CS department which will host a bunch of Trac instances, initially for academic projects only then it will be opened to student projects as well. The server set-up has been "powered-by" the following technologies:

1. Debian Etch
2. Apache 2.2 with FastCGI, SuExec, and WebDAV over TLS (for accessing SVN repositories without forcibly passing through Trac)
3. Trac instances backed by Sqlite databases and Subversion repositories
4. Some bits of Genshi templating for generating the projects index
5. Some shell scripts for automating creation and removal of projects

I'm quite happy with the result. From the overall experience I drew some observations though:

• installing Etch is more a dream than ever, in 15 minutes I re-installed the server (which previously was running Ubuntu) with a decent partitioning scheme and all that I needed to work remotely. The sysadm of the department saw me coming out from the server room and asked, unbelievingly, did you already finish?
• apache2.2 in Debian is now annoyingly missing the nice script for creating easily TLS certificates (i.e. apache2-ssl-certificate). I followed-up on #395823 attaching the same script took from Sarge and the needed configuration file. Worked for me
• SuExec is stupid. You have to put stuff under /var/www for it to work at all, the only way to change the path is rebuild apache .... or, you can mount --bind /srv/trac /var/www/trac!
• BTW I like /srv. According to the FHS it's the place where I want to put my Trac projects. Unfortunately the Debian installer neglects that path and per default you end up with a system where /srv is in the same partition as /, and hence with basically no free space. Hence I also bind-mounted /srv/trac from /home/trac
• In Etch we have no available implementation of FastCGI (which really improves Trac performances BTW). libapache2-mod-fastcgi is non-free and for some reason it was not autobuild everywhere and hence is missing from testing. I pinged aba on IRC about that, so the package should probably enter testing again in a few days. Go RMs!

Happy new year birthday trac.cs.unibo.it.

Only three things to say today:

Second anniversary

Today marks the second anniversary of the Debian Administration website. (I think that this is the first public mention of my intention to setup the site. It was the earliest I could find anyway.)

Edinburgh Trivia

Doing my own small bit for Debconf I went for a walk on Christmas Day. For two years I’ve lived in the area of Edinburgh known as Leith. (Famous for being a port, and being a port of call for hookers) During that time I’ve taken buses, and walked, up and down Leith walk hundreds of times. Almost every time I do I notice a large chimney by The Edinburgh Playhouse Theatre.. The top 20/30ft of the chimney can be seen from peeking over the top of local buildings, assuming you’re not blocked by other buildings. And now? Now I know what it sits upon. My little adventure in getting to know the city I’ve been living in; I wanted to find the bottom of the chimney and see what it was attached to. So if anybody coming to Debconf next year gets massively lost and curious about a large chimney en route to my house .. I can tell them all about it. It is the little things in life ..

Xen Shell

I’m not sure that there are many people using this, the freshmeat listing has a few subscribers but I’m never sure how well that translates. (Plus of course nobody rated the software so it might be they hate it?). Anyway there are almost certainly far fewer users of the shell than the main xen-tools package - but as of last night the shell now allows you to control more than one Xen instance. This is quite a large change, since previously it explicitly only supported one user controlling one Xen instance. Expect a new release shortly once I’ve tested it more, and updated the documentation.

Merry Christmas to everyone today!

Today, and for the next few days, I'm going to write about some of my Christmas memories from earlier years. Then I'll finish up with some photos from this year.

This post is about Christmas at home growing up.

One of the first signs of Christmas happened when my dad put up the lights on the outside of our house.



My brothers and I had (and still do) stockings that got one piece of candy per day during December, then got stuffed full when we opened our presents. The tree went up over the Thanksgiving weekend, and it was always a lot of fun to help with that.



On Christmas Eve, we'd always go to the program at church. It was the kids' Christmas play. Church would be packed. On the way out, everyone got a gift sack with fruit (apples or oranges), some peanuts, and maybe some candy. Then we'd go home. Mom or dad would read the Christmas story from the Bible, and after a prayer, it was time to open presents. In addition to the regular presents, dad would always give us a large paper gift sack. It would usually have a 12-pack of pop and some sort of nut (peanuts, pastachios, or maybe peanut brittle).

Sometimes we'd all stand still long enough for a photo.



We'd usually stay up late into the night Christmas Eve and sleep in on Christmas day.

My face is covered in egg. Antti-Juhani Kaijanaho found a security problem in EoC, both the 1.0.3 and the 1.2.3 versions. The problem is that EoC did not quote shell arguments properly. I have fixed the problem in 1.2.4, which contains no other changes relative to 1.2.3. This problem has the code CVE-2006-5875. You can find the 1.2.4 version from the EoC website: http://liw.iki.fi/liw/eoc/ and I have also uploaded it to Debian's unstable. Debian's stable contains 1.0.3, and I have prepared a patch for that. It is actually essentially the same patch as was used to create 1.2.4. The Debian security team has uploaded a fixed version of the 1.0.3 package to security.debian.org. I've attached it to this message in case anyone not running Debian wants to stay with 1.0.3, but I won't be releasing a 1.0.4 unless someone really needs it (if you do, please tell me immediately). For risk assessment: I was unable to come up with an exploit. Doing so would require getting a certain kind of construct through the SMTP level to EoC, and I wasn't able to make that happen, but I would not rely on it being impossible. Therefore, please upgrade immediately. I apologize for this problem. It was amateurish to let the problematic code into a released version of the program, I knew better than do that.

Joe Buck commented:

"It's inverse-square. The way to remember the inverse square law is to think of the outgoing signal expanding like a balloon. The surface area of the balloon, if it's a sphere, is 4*pi*r^2, so the amount of power per unit area is the reciprocal of that, proportional to 1/r^2."

Michael Maclean commented:

"A potential fun use - I once used one of those gadgets to replicate the "sorting hat" thing from the first Harry Potter film for a Brownie camp my girlfriend was helping out at. There was a radio hidden in the hat and a transmitter attached to an MP3 player for the samples. Basic, but apparently it worked out quite well."

In a watery contrast to the real Venice, The Venice Project surfaced from stealth mode recently (and I just fixed my blog, so I figured I’d get caught up). Our blog has some more official news and buzz, too.
People who know me at this point will be wondering why I’m involved in a TV project when I hardly ever watch TV, but we’re actually aiming to solve much of my irritation. Colm writes about what TVP solves for him, and I agree that the social aspect is one the fundamental points to our work. We’re seeing - via MMORPGs, blogging communities, etc - the attraction that connectedness has and the importance people are beginning to attach to sharing and aggregating data effectively.
Leo has written about some of the underlying technologies that parts of the project are using, although unfortunately he somewhat takes the reasoning behind the choices for granted.
My other major problem with TV is timing. This one is pretty obvious, but being able to build channels with content that I want to watch, and watch them when I want to is pretty compelling.
And I’m looking forward to combining these two…
So what am I doing? I’m broadly doing operations, with - unsurprisingly - a Linux bent… But more about that later.

http://faces.debian.net. A couple of HTML::Template files and a directory of images will be transformed into a series of static pages via a simple Perl script. All images are “public” ones as used upon Debian Planet - ask me and I’ll remove you. If your name / homepage is missing then edit them yourselves in the LDAP database. Opt-in picture uploading will be added when I can get a procmail recipe which validates a GPG signature and saves a single attachment to a directory. Help? The layout is stolen from mentors.debian.net - and I will fix that with a unique style once I get a few hours spare. Volunteers for CSS-fu much appreciated.

I bought a Sony DCR-HC24E for the purposes of recording my wedding ceremony. I could have borrowed my parents', but it's an ancient analogue thing and although I don't really have a use for a camcorder I talked it through with Katherine (making it clear that part of the appeal was just sheer toy value) and we went ahead with it. (I should point out the driver for recording any of the wedding came from my mother-in-law and I wasn't that fussed about the whole thing, but having experienced the "day was a blur" thing I'm glad we have it. Though I've watched it too many times as I'm about to explain.) The Sony comes with both USB and Firewire. My desktop doesn't do Firewire, but I figured USB would be fine. First issue is that Linux doesn't seem to support it in USB mode. I don't know if this is easily solved, as reading the manual I discovered that Sony claim USB isn't as good quality and Firewire is better. Huh? It's all digital. What gives? The best I could come up with is that Firewire is better at guaranteeing latency/bandwidth so you don't end up with dropped frames. Anyway. I buy a Firewire cable and dig out a Via EPIA-M board which has Firewire. Some poking about leads me to the conclusion that I want dvgrab. I fire it up, it seems to do the right thing, I end up with a huge file. Point mplayer at it and discover it's dropping frames. It appears raw DV is about 30Mb/s. The HD in the Via is an old 6GB one that only does ATA-33. So I find a newer ATA-133 capable one, double the RAM in the box (on Adam's recommendation) and try again. This goes better. So now I have a bunch of AVI files, all of them about 1G in size. avimerge is employed to combine them (I might have been able to just get dvgrab to output a big file, but I was wary of large file support). Then I did ffmpeg -i bigfile.avi -target dvd smallerfile.mpg resulting in a couple of DVD format MPEGs (one for the ceremony, one for the speeches). My first attempt at a DVD image was with DeVeDe. It seemed to work fine, but I ended up with something that the DVD player didn't like and neither did mplayer or xine. So I fell back to qdvdauthor, which I've used in the past but don't deem the most user friendly of programs. I finally end up with something that mplayer and xine seem happy with in terms of a menu and a pretty picture of us signing the register and working video. And so to burning a DVD. I used growisofs for this. Firstly with a DVD-R, which mostly worked but had annoying pauses on my real DVD player. So I tried with a DVD+R and this seems to be much better, however there are some minor pauses. This might be my ancient DVD player not coping well I guess. I'm sure DVD creation shouldn't be this painful. I bet if I ran Windows I could point and drool my way to a DVD with the software Sony supply with the camcorder. All I wanted was a basic menu with a background picture and some video attached to the menu options. I'm pondering doing a version with a picture gallery as well, but can I be bothered with the hassle?

Multiple times we’ve talked about having a Debian-Developer-Gallery. That could be something like all the pictures from various conferences and events, to just having a mugshot of each registered developer. So :

1. Is this a good idea?
2. Do you have a picture you’d like to be included?

I’m volunteering to setup a simple site which will contain one photograph of each Debian Developer (ideally which they will submit themselves, I’m not sure how to handle the case of somebody saying “This pictures is foo@debian.org” when foo didn’t authorise/expect it to become public.) This simple site will be accessed via:

• http://mugshots.debian.net/foo/

Each page will contain:

• Link to the homepage of dd-foo, as found in LDAP.
• One single image of user foo. Thumbnail if “too big” linking to the full size version.
• (Optionally links to QA.d.org, etc, but that is secondary to this purpose.)

(No ratings, no tagging, possibly a “random user” link, or an index by username. Nothing complex or too dynamic) Suggestions for a better name would be appreciated. I figure either “faces” or “mugshots” - since the obvious “gallery.d.net” is already taken. So .. comment here if you think this is a good idea. Or feel free to mail me a link/attached image. Assuming I get say 50 developers thinking this is a good idea I will setup the DNS alias and put the site live. Bandwidth will be minimal, but I think having the friendly faces (?!) visible would be a good thing. And will make identification of people prior to meetings signficantly easier. (At times like this I wish I could host a real poll .. but ignoring that for a second.)

The "high definition audio" in my laptop is rather minimal. Apart from the mic not yet working, it has a line out and a single volume control. Thats it. However, I'd like to have multiple applications use the sound card, for example my music player, eventually some video player or flash, and some system events. ALSA to the rescue. It's not easy to configure, but really powerful: Yes, that is a separate volume slider in my regular mixer for MPD, my music player. Here's how to do that: First we'll need to create a huge /etc/asound.conf:

# the real device
pcm.realdev  
        type hw
        card 0
        device 0
 
# software mixing
pcm.dmixer  
        type dmix
        ipc_key 3129397
        ipc_key_add_uid false
        ipc_perm 0666
        slave.pcm "realdev"
        slave  
                period_time 0
                period_size 1024
                buffer_size 8192
                # we're enforcing 44100, since thats what most apps use
                rate 44100
         
        bindings  
                0 0
                1 1
         
 
# software volume
pcm.softvol  
        type softvol
        slave.pcm "dmixer"
        control  
                name "Software"
                card 0
         
 
pcm.mpdvol  
        type softvol
        slave.pcm "dmixer"
        control  
                name "MPD"
                card 0
         
 
# input
pcm.input  
        type dsnoop
        ipc_key 3129398
        ipc_key_add_uid false
        ipc_perm 0660
        slave.pcm "realdev"
 
# duplex device
pcm.duplex  
        type asym
        playback.pcm "softvol"
        capture.pcm "input"
 
# default devices
pcm.!default  
        type plug
        slave.pcm "duplex"
 
pcm.dsp0  
        type plug
        slave.pcm "duplex"
 

I won't go into all the details (I don't know all of them either), but the basic idea is that I setup the dmixer plugin for software mixing, and attach two software volume controls to it. I'm keeping the permissions to 0666, since my MPD is running as a different user, and I didn't find a way to say I'd like to have the permission set to group "audio". The default device is the regular microphone jack (untested, since there are driver issues with my chipset and recording) and the "Software" volume control. If you have an ~/.asoundrc you might want to move it out of the way. Next I need to configure MPD to use its own volume control via /etc/mpd.conf:

audio_output  
        type            "alsa"
        name            "my ALSA device"
        # 'mpdvol' is the device name I used in asound.conf
        device          "mpdvol"
 

You'll probably need to restart all applications currently accessing your audio devices to have them pick up the new config. The new volume control will also only appear after you've started an application using it AFAICT. Sometimes you need to restart them twice for the new volume control to be effective. When alsa-utils restores the volume controls after reboot it should work right away. The "Software" volume control is optional, but that way I can tune down the default applications volumes below the MPD volume if ever needed. Oh, and I think you can safely keep one or all of the software volume controls to maximum without distortion happening (this doesn't hold for all sound cards, where it's often best to keep the sliders at ~75% max to avoid distortion)

1. Do not attach an RJ45 plug to a cable right above a laptop's keyboard.
2. When ignoring the above, make sure you do the cutting somewhere else, so that the little pieces of throwaway cable do not fall on top of your keyboard.
3. When ignoring the above, turn the laptop upside-down, rather than trying to push down one of the buttons in an attempt to more easily reach the little cable thing.
4. Cable bits in a keyboard can really mess it up.
5. Laptop keyboards are even worse to reassemble after removing the keys than are desktop keyboards.
6. Attaching a space bar to a laptop keyboard is a horrible puzzle, which is likely to take you about an hour to figure out if you've never done so before. Once you have, though, and understand the procedure, it takes only a few minutes to do properly.
7. Mail sucks. No, that's not related to any of the above, but it still does.

At least I didn't break any parts this time. Progress.

Have you ever had a need for a large number of "real" network interfaces on a Linux box? For security reasons, you don't just want to hook everyone up to a single switch and use virtual interfaces (because it's too easy for one of the connected devices to play silly buggers with his neighbours). Up to a certain point, you can stuff more NICs into a box, and when it fills up you can switch to those outrageously expensive 2- and 4-port NICs. But eventually you're going to run out of space[1] or money. At that point, you need something more interesting. For me, this week, that "more interesting" has been Ethernet VLANs. Linux Journal has a good intro to the technical aspects of how to setup VLANs and Linux. VLANs are some crazy stuff. They're implemented by wrapping a little number around every Ethernet frame indicating which VLAN the packet is "on", and the switch (you need a higher-end device, appropriately configured) makes sure that packets don't roam onto ports they're not meant to be on. For a single switch, this isn't very interesting, and you don't really need an IEEE standard to make it work -- just a lot of little jumpers. However, VLANs are mostly useful on larger networks, which tend to use more than one switch. So you need a way for your VLANs to roam amongst your switches -- hence the packet tagging. You stick the tag onto the packets and fling them off to another switch, and packets coming in with the tag are corraled into their VLAN. Naturally, you don't want end-user devices whacking their own VLAN tags onto packets (untrusted data, and all that), so you define most of your ports as being "untagged". Packets that come in on these ports are treated as regular ethernet frames and tagged with the appropriate VLAN ID, and packets that go out have their VLAN IDs stripped before being sent. (This implies that you can tunnel VLANs in VLANs, and I'm pretty sure that is doable in most switches, modulo some nasty problems that can, and probably will, occur). The ports that aren't designated "untagged" spit out tagged packets -- and this is where my interest lies. Like most every other computer-related standard, Linux can decipher and work with VLAN tags (the 8021q module is what you're looking for). You just load up the module, hook your NIC into the appropriate port on your very expensive switch, define your VLAN tags with vconfig, and suddenly you've got vlanN interfaces, which map to real RJ-45 ports, and you can hang network devices off these and get lots and lots of "real" network interfaces on your Linux router. It's all so simple, right? Nothing ever is, of course. The trials and tribulations I've had over the past two days have included:

• Not being able to talk to the switch via serial console (so I can configure the damned thing). Turns out the cable I had wasn't a null modem cable, and the switch needed one (the documentation was contradictory on this point, so we started off with the regular kind and a gender-bender -- which should have been my first clue). So Jaycar got ten more of the company's dollars for the proper cable. After that, all was well, and I could find out that...
• The console interface is horrendous on the switch I've got, at least for defining VLANs. I just enabled the (slightly less hideous) web interface, and used that instead. It still sucked, but it sucked less.
• Once everything was configured and the test rig all wired up, I spent about 20 minutes plugging cables into various ports on the switch and watching a distinct lack of packets flowing. It turns out that new VLAN trunks (the technical term for "a port that gets all VLANs, with tags still attached") on this switch get configured as "disabled". Yes, of course that's what I want -- it's overwhelmingly likely that I won't want to use that new trunk I just configured. Sheesh.
• The first NIC I used as the VLAN interface on the server (a Tulip-based home brand thing) didn't play nicely with the VLAN packets. As you'd expect, the extra bytes for the VLAN ID need to be a part of the packet -- and that size is normally limited to 1514 bytes (1500 bytes of payload plus a 14 byte Ethernet header). Adding the VLAN tags increases this by 4 bytes. Although some NICs comprehend the utility of supporting VLANs, and will handle these oversized 1518 byte frames, others don't. This NIC just didn't want to handle it. The symptoms were large pings just disappearing (they didn't show up in tcpdump on the destination interface). As I've had to track down MTU problems in the past, and it's always painful, I wasn't keen on introducing a known one right at the start, so this had to be rectified.
• The next NIC I tried (a Netgear FA311 -- uses the natsemi driver) had a fantastic failure mode. Packets arrived having had their VLAN tag stripped -- so the 8021q module didn't know it was a VLAN packet, and couldn't drop it into the appropriate vlanN interface. I know everything was otherwise alright, because ARP packets were tagged to the VLAN fine, but the ICMP packets that followed weren't tagged. Scratch that one off the list.
• The third NIC was an RTL8139D. The driver didn't even recognise this card, which confused the hell out of me. It turns out that this particular card (PCI ID 1904:8139) isn't a real RTL8139 (despite having RTL8139D and the RealTek crab printed on the chip) but is rather a dodgy knockoff (some might say "as opposed to the dodgy original?"). Why anyone would bother to knock-off the world's cheapest ethernet chipset, I have no idea -- if I were an electronics counterfeiter, I'd go after something expensive, like a 3Com card. Far more profit.
• The fourth NIC, a real RTL8139D, worked like a charm. I know it isn't exactly the most fantastic NIC on the market today, but I don't have any 3x59x or eepro cards around, so this'll have to do for now.

Thankfully, once all those dramas were done, the whole thing just kind of fell into place, and now I've got a machine which has up to 2048(ish) network interfaces (with huge, glaring caveats on that upper bound, of course). With a bit of luck, the live installation in a couple of days will go smoothly. You can stop sniggering now.

---

1. In this case, there wasn't a lot of space to begin with, as it's a 1RU box I'm working on, and the 4-port NIC didn't want to place nice with me for some reason anyway.

I spent a while on IRC today, rare for me, and one of the repeatable topics of conversation was showing mugshots of people in chat. I wrote a trivial /showface command for irssi which just spawned mozilla to show a hackergotchi from planet.debian.org and that was neat. However it suffers from the problem that you cannot spawn a graphical application from inside Screen easily. So I came up with a cunning alternative: using the DBUS notification deamon. So now I have face.c which uses wget to download an image, then dbus to display it. Compile it like this:

apt-get install libnotify1 notification-daemon dbus
apt-get install libgtk2.0-dev libglib2.0-dev libnotify-dev
	
gcc  pkg-config --cflags gtk+-2.0  \
     pkg-config --cflags glib-2.0  \
 face.c -lnotify -o face
	

Now copy the face script to drive it and you can run /showface skx and it will show you my image. Neat hack. (I suspect it will fail if I logout of X and restart - then reattach to screen since my DBUS identifier/session will be different. But I’m still pleased that I didn’t have to quit the currently open screen session and I can make graphics appear from within it) Update: now with caching and error detection. It will also disable itself for channels not matching ^#debian*

On big IRC channels, it'd be easier to remember people if it would be possible to attach a picture to the nick. Something like this would make a possible implementation without changing the IRC protocol: one could define a URL pattern for each network and channel, and the client would look up the picture using the pattern. So for #debian-devel, I could have a pattern http://planet.debian.org/%s.png, and then the hackergotchis would be used, if they existed. (Later, perhaps, a http://mugshots.debian.net/%s could be created, for all Debian people.) I've no idea how to present the pictures in the UI properly, without making the text lines too sparse. I'll leave that for someone else to figure out.

Back before Jacob was born, I was reading The Expectant Father: Facts, Tips, and Advice for Dads-to-Be, 2nd ed. by Armin A. Brott and Jennifer Ash. It was a good book and I recommend it.

Towards the end, there was a section that the author clearly was passionate about, and it made me mad too.

He was talking about society's attitudes towards dads. He started by looking at messages that are sent out in commercials. One study of commercials said that "100% of jerks singled out in male-female relationships were male. There were no exceptions. . ." That study also said that 100% of the ignorant and incompetant people in commercials were male as well.

He went on to cite some examples. Tons of slogans like "kid tested, mother approved", "choosy moms choose Jif", Robitussin's "recommended by Dr. Mom", etc. And one for Post Raisin Bran in which a father and daughter are impressed by their cereal. Dad says, "somebody must really love us. Who do you think it is?" The daughter answers, "Mommy!"

Of course, these were just some examples from commercials, but they seem to reflect a message that dads are, at best, incompetant. Brott mentions studies that show that men display the same decision-making skill and affection as parents as women do.

Brott went on to talk about some of his experiences. One time, while he was in a park playing with his children, a little girl started to fall off the top of a slide. He was right there and was able to catch her as she fell -- probably saving her from, at best, a broken bone. The girl's mother rushed over, ignored Brott, and said to the girl, "did he hurt you?"

I started to see this sort of thing all over the place even before Jacob was born. In stores, there would be tons of infant shirts, bibs, etc. saying things like "I love mommy," rarely even one thing that mentioned daddy. Similar patterns were there for greeting cards and pretty much everything else baby-related.

I've noticed this even more since Jacob was born. There have been times when Terah and I are somewhere together, standing right beside each other, and someone will ask Terah all about Jacob, and totally ignore me. Even if I'm the one holding him. I'm sure people are well-intentioned; some of them that have done this are people we know well and I know they mean well. Somtimes, I don't even notice when this is going on (though Terah does and when she mentions it later, I remember it).

Do they just expect that men don't care? Or do they think that since Terah is working part time, and I'm working full time, that we must be "traditional" enough that I don't care to be involved in Jacob's life? (Though I'm not sure that the "detached & uninvolved dad" stereotype ever was true, at least from the examples I can think of) It's hard to miss out on so many moments of Jacob's life during the day that Terah gets to be there for. But that doesn't mean that I'm an uninvolved or clueless dad.

Now, despite this little rant, there are quite a few people out there that have no problem including me in discussions about Jacob -- relatives, friends, people at church, co-workers, etc. In fact, probably more people include me than don't. I really appreciate that, and especially the extra effort some of them go to in order to include me. (I know how much effort it took to find baby clothes that mention dad, for instance) Terah is best at all this, making sure that I get to be part of Jacob's life as much as I possibly can be, and I really appreciate that.

But to Wyeth (makers of Robitussin): Don't think I haven't noticed that Walgreens sells "Wal-Tussin", same active ingredients as your product, and at a lower price. Dr. Dad knows how to buy generic.

Adrian von Bidder writes about retty, a tool to make processes reattach to your terminal. While useful, it seems mostly like a limited version of cryopid which seems even more insane and crackful, but quite cool nevertheless. I have not had a chance to actually try cryopid yet though, so if any of you have, please blog about your experiences with it. Oh, and please package it, somebody.