1. Installing Firefox in an OpenVZ container can make you lose /dev/null
2. OpenSolaris sleep(1) needs the network to be up
3. People are injecting foreskins into their face
4. Dubai is really screwed

You might think that recording and then splitting it into separate audio files based on silences
between each track would be easy to do - sadly not.

Aside from crashing a few times and failing to recover properly, I’ve been hit by these
enormous frustrations:

• despite claims to the contrary, even 1.3.7 does not correctly alter labels when you modify the
  audio. That means there’s no way to Truncate Silence without re-doing all your labels!
• you can’t split into tracks (or, apparently, make selections) based on labels added by the silence finder, so you can’t remove inter-track silences that way either
• the labels dialog has a fun bug where it removes all your labels that don’t have names (as
  none of them do by default). This gets frustrating fast.
• there’s no way to start a recording on the current track - I have to have a new one, it seems. This was fine until I discovered that Mix and Render completely screwed up the merging of all the tracks.

Seriously, how do people actually use this thing?

After dealing with more code that gets it wrong I was reminded of the numerous reasons why openpty() is such a broken API. The prototype of this “convenience” function is this:

int openpty(int *amaster, int *aslave, char *name, struct termios *termp, struct winsize *winp);

Now, sin number one should be obvious: the interface isn’t const-correct. You’re passing in the winp values, but there’s no indication of that. Worse, you’re doing the same with termp. Why worse? Well, think about how you use this API. Typically, you want to create the master/slave pair of the pseudo-terminal, then change the terminal settings of the slave. (Let’s leave the master out of this for now - but the settings are not always symmetrical.)

But where do we get the terminal settings from? We don’t have an open slave to base them on yet! So you find code doing a cfmakeraw() on stack junk and passing that in, because the API almost insists you do the wrong thing.

Indeed, doing it right, namely with a tcgetattr()/cfmakeraw()/tcsetattr() stanza, you’d expect term to be an out parameter, that you could then use - precisely opposite to how it actually works, and what const correctness suggests to the user. You can see some other amusing examples of how people worked around the API though.

I’m sure you will have spotted by now that the name parameter is outgoing, but has no len. It’s therefore impossible to use without the risk of buffer overflow.

This API is not going to score well on the Rusty scale. What’s worst of all about openpty(), though, is that it’s non-standard, so almost every piece of code out there keeps its own private copy of this broken, pointless interface. Yay!

I was bored so played around with Review Board a little more, including installing it myself.

Things seem to have got easier to install, at least to some degree. You can use easy_install, though at least
for CentOS 5.2, you’ll need to install a newer version of setuptools first. It’s also far from automated, missing
out basic dependencies like pysqlite2, patchutils, and even patch itself. Discovering these can be, and in my case was, rather tedious work.

After that it’s pretty easy to install, for the sqlite version anyway. The documentation isn’t exactly clear on
what permissions changes you need to make: you need to chown all of db/ to the apache user as well for anything to work. Expect to set up a virtual host for the installation, like I did above.

Don’t forget to enable logging in the admin interface whilst you’re messing around.

Sadly, the Mercurial support seems some way behind. For example, it doesn’t pick up changeset comments.

The diff parser (how is this not in a library by now?) can’t handle git diffs, and the failure mode is horrible (basically, silent failure, with no debugging messages). This is because hg git diffs don’t contain the revisions being diffed, so Review Board can’t pull the files from the repo. Undoubtedly a Mercurial misfeature, but it does make Review Board near useless for my purposes unfortunately.

It can handle ssh repositories (which is all opensolaris.org provides), but there’s a horrible work around needed: you have to set up a correct known_hosts file in the apache user’s home directory. Yuck.

As for the main interface, it’s generally pretty slick. I can imagine it getting cumbersome quickly with large code reviews though. Compare and contrast Review Board’s diff viewer with webrev. The latter to me at least, is much more scalable, even though the actual diff mechanism is less smart. In particular, I can review each file with webrev in a separate tab, whereas Review Board insists on one big (very big!) screen. I’d still give my right arm for a webrev-based Review Board :)

Another thing I’d like to see is more integration with the repository, so I can click on a file and it will take me off to the repo browser for looking through history.

My favourite Wondermark for a while.

I read my work email with mutt on a Solaris 9 box. For a while it's been irritating me that when you attempt to cut and paste, it will include trailing spaces on each line instead of stopping at the last "real" character. Some Googling suggested this was because of the lack of the BCE attribute in my xterm-color terminfo definition. Rather than learn how to compile terminfo entries (I've done it before, but I don't want to learn again!), I took the lazier approach: copy /usr/share/terminfo/s/screen-256color-bce from a Fedora 8 box into /home/johnlev/.terminfo/s/, and start mutt with TERM and TERMINFO set appropriately. Now I can cut and paste sanely again.

Tags: Solaris mutt

I’ve only just read the XML-RPC spec. I knew it was simple, but I didn’t know it was stupid. Seriously, no parameter names? Only 32-bit integers? And no “NULL”? WTF?

Talk about unnecessary. JUST USE SOME NEWSPAPER. Sheesh.

UPDATE: the canonical location for this information is now here - please check there, as it will be updated as necessary, unlike this blog entry.

As a final part to my entries on OpenSolaris and Xen, let's go through the steps needed to turn OpenSolaris into a dom0. Thanks to Trevor O for documenting this for 2008.05. And as before, expect this process to get much, much, easier soon!

I'm going to do the work in a separate BE, so if we mess up, we shouldn't have broken anything. So, first we create our BE:

$ pfexec beadm create -a -d xvm xvm

First, let's install the packages. If you've updated to the development version, a simple pkg install xvm-gui will work, but let's assume you haven't:

$ pfexec beadm mount xvm /tmp/xvm-be
$ pfexec pkg -R /tmp/xvm-be install SUNWvirt-manager SUNWxvm SUNWvdisk SUNWvncviewer
$ pfexec beadm umount xvm

Now we need to actually reboot into Xen. Unfortunately beadm is not yet aware of how to do this, so we'll have to hack it up. We're going to run some awk over the menu.lst file which controls grub:

$ awk '
/^title/ { xvm=0; }
/^title.xvm$/ { xvm=1; }
/^(splashimage|foreground|background)/ {
    if (xvm == 1) next
}
/^kernel\$/ {
    if (xvm == 1) {
       print("kernel\$ /boot/\$ISADIR/xen.gz")
       sub("^kernel\\$", "module$")
       gsub("console=graphics", "console=text")
       gsub("i86pc", "i86xpv")
       $2=$2 " " $2
    }
}
{ print }' /rpool/boot/grub/menu.lst >/var/tmp/menu.lst.xvm

Let's check that the awk script (my apologies) worked properly:

$ tail /var/tmp/menu.lst.xvm 
...
#============ End of LIBBE entry =============
title xvm
findroot (pool_rpool,0,a)
bootfs rpool/ROOT/xvm
kernel$ /boot/$ISADIR/xen.gz
module$ /platform/i86xpv/kernel/$ISADIR/unix /platform/i86xpv/kernel/$ISADIR/unix -B $ZFS-BOOTFS,console=text
module$ /platform/i86pc/$ISADIR/boot_archive
#============ End of LIBBE entry =============

Looks good. We'll move it into place, and reboot:

$ pfexec cp /rpool/boot/grub/menu.lst /rpool/boot/grub/menu.lst.saved
$ pfexec mv /var/tmp/menu.lst.xvm /rpool/boot/grub/menu.lst
$ pfexec reboot

This should boot you into xVM. If everything worked OK, let's enable the services:

$ svcadm enable -r xvm/virtd ; svcadm enable -r xvm/domains

At this point, you should be able to merrily go ahead and install domains!

Update: Todd Clayton pointed out the issue I've filed here: SUNWxvm needs to depend on SUNWvdisk. I've updated the instructions above with the workaround.

Update update: Rich Burridge has fixed it. Nice!

Tags: OpenSolaris Xen xVM