Linux VNC and Mac OS X Screen Sharing

I’ve found that in order to get x11vnc to work with the Mac OS X built-in VNC client (“Screen Sharing Application”), there options are required when starting the VNC server:

$ x11vnc -display :0 -rfbauth /home/pi/.vnc/passwd -shared -rfbversion 3.3 -forever -bg

The -shared option is key here. Judging by the log on the VNC server, I think Mac OS X will attempt multiple connections.

For what it’s worth, here’s also how to auto-start the VNC server when the user logs into the LXDE desktop. Copy and paste this to ~/.config/autostart/x11vnc.desktop:

[Desktop Entry]
Exec=x11vnc -display :0 -rfbauth /home/pi/.vnc/passwd -shared -rfbversion 3.3 -forever -bg

Booting a PowerBook from a LiveCD image on an USB-Stick

I have an old Apple PowerBook G4 with a broken CD/DVD drive. For most practical purposes, the broken drive is no issue. However, if you’re going to re-install the laptop, it becomes one. Luckily, the PowerBook is able to boot from USB…

At first, I tried following the instructions on "LiveUSB on PPC" found in Gentoo’s Wiki, but that didn’t work out at first. I then found a blog entry titled "Creating a bootable USB Stick with Mac OS X in 10 easy steps&quot. Combining the two lead to success, so here’s what I did:

  • I downloaded the latest PowerPC release of Finnix, a &quot self-contained, bootable Linux CD distribution&quot from the project’s front page.

  • I re-named the ISO image from finnix-ppc-105.iso to finnix-ppc-105.dmg. Also, I displayed the file’s information in Finder by right-clicking on the file icon and selecting "Show Information&quot. I doubt that this step is required but it certainly didn’t do any harm.

  • From a shell, aka "Terminal Window&quot, I used the command diskutil list to find the device path to my USB drive. In my case, it was /dev/disk6.

  • I then unmounted the drive by running

    $ diskutil unmountDisk /dev/disk6

  • Using good, old dd(1), I wrote the disk image to the USB drive:

    $ sudo dd if=finnix-ppc-105.dmg of=/dev/disk6 bs=1m
  • Finnally, I unmounted the drive by running:

    $ diskutil eject /dev/disk6

In order to boot the PowerBook from the USB drive, I had to drop into Open Firmware. In case you didn’t know it, this is done by holding down Cmd+Option+o+f right after the computer is turned on.

The next step was to find the device node of the bootable USB drive. To do this, I browsed the device tree for any USB node that had a disk child node.

> dev /
> ls

In my case, the USB drive was at /pci@f2000000/usb@1b,1/disk@1.

The instruction found on the Gentoo wiki assign the cd alias to that node, so I did that, too, by running:

> devalias cd /pci@f2000000/usb@1b,1/disk@1

This allowed me to finally boot from the USB drive like this:

> boot cd:,\:tbxi

ImageMagick, libjpeg, etc. on Mac OS X

Here’s how I got ImageMagick with JPEG support to compile and run on Mac OS X 10.6 (Intel).

First, I got the ImageMagick Source Code via Subversion, per the instructions from Short version:

$ svn co  

Then, I pulled libjpeg from the Independent JPEG Group. I had to extract the source code to a subdirectory of the ImageMagick directory called jpeg, i.e. /path/to/ImageMagick-6.6.5/jpeg.

Before I could compile any of the source code, I had to set three environment variables per this thread on the ImageMagick forums:

$  export CFLAGS="-isysroot /Developer/SDKs/MacOSX10.6.sdk 
  -arch ppc -arch i386"
$ export CXXFLAGS="-isysroot /Developer/SDKs/MacOSX10.6.sdk 
  -arch ppc -arch i386"
$  export LDFLAGS="-Wl,-syslibroot,/Developer/SDKs/MacOSX10.6.sdk 
  -arch ppc -arch i386"

Then, I compiled libjpeg via the via the standard ./configure and make dance. I used these commands:

$ cd jpeg
$ ./configure --prefix=/opt --disable-shared 
$ make -j 16

Now, I was able to configure ImageMagick:

Be aware that the LDFLAGS path is different than the include path! If everything went well, you can now go on to build the imagemagick suite:

$ ./configure --prefix=/opt --without-x --without-perl --with-jpeg 
   --disable-shared --disable-dependency-tracking 
   --enable-delegate-build --enable-osx-universal-binary
$ make -j 16

This gave me statically linked binaries of the ImageMagick tools I was able to run on my Mac. I also tried to build dynamically linked binaries but failed. Because I don’t need the dynamically linked version, I gave up after a while.

SSH Tricks

My shell scripting skills suck. So it comes naturally that I learn a lot every time I need to write a script. The trick I’m about to describe is so neat that I want to share it.

Assume for a second that you need to execute a series of commands on a remote machine, but you can’t pass them to SSH at once. Or consider that you might need to transfer a file over to a remote host and then extract it there. Normally, you’d need to create several SSH connections for this. In the “transfer, then extract” scenario, you need one connection for scp(1) and another one to extract the file on the remote host. Unless you have your public key in the remote host’s ~/.ssh/authorized_keys file, you need to enter your password for the remote host twice. It’s probably not a big deal for most, but it’s annoying at times.

It might be obvious for some, but I recently found out that ssh(1) offers a solution for the problem described above. It allows you to open one connection in "master" mode to which other SSH processes can connect through a socket. The options for the "master" connection are:

$ ssh -M -S /path/to/socket user@rhost

Alternatively, the ControlPath and ControlMaster options can be set in the appropriate SSH configuration files. Other SSH processes that want to connect to the "master" connection only need to use the -S option. The authentication of the "master" connection will be re-used for all other connections that go through the socket. I’m not sure if SSH even opens a separate TCP connection.

Going further, this can be used in scripts to save the user a lot of password typing, especially if the execution flow switches between local and remote commands a lot. At the beginning of the script, simply create a &qout;master" connection like this:

$ ssh -M -S /path/to/socket -f user@rhost 
    "while true ; do sleep 3600 ; done"

It should be noted that the path to the socket can be made unique by using a combination of the placeholders %l, %h, %p, %r for the local host, remote host, port and remote username, respectively. The -f parameter makes SSH go into the background just before command execution. However, it requires that a command is specified, hence an endless loop of sleep(1) calls is added to the command line. Other SSH connections can be opened like this, not requiring any further user input (for authentication):

$ ssh -S /path/to/socket user@rhost

This leaves the problem of how the "master" process can be terminated when the script has finished. Some versions of SSH offer the -O parameter which can be used to check if the "master" is still running and, more importantly, to tell the "master" to exit. Note that in addition to the socket, the remote user and host need to be specified.

$ ssh -S /path/to/socket -O check user@rhost
$ ssh -S /path/to/socket -O exit user@rhost

However, there are still two problems to be solved. First, when the "master" quits, the dummy sleep loop continues to run. And second, how can the "master" be terminated if the given SSH version doesn’t offer the -O parameter (short of killing the process by its PID)?

Latest Version of KOMAscript

The Tex Live distribution Mac OS X is getting more outdated by the day. Maybe there’s a way to update it, but I didn’t bother to check.

For a reasonably good layout of letters without a footer I found that a recent version of KOMAscript is required. I’m using Version 2.98 obtained from

Installing the new version proved to be quite easy:

$ cd /usr/local/texlive/2007/texmf-dist
$ sudo unzip
$ sudo texconfig rehash

GCC 3.3 on Mac OS X

I just tried to build Qemu on an Intel Mac. Qemu needs GCC 3.x and won’t compile with GCC 4.x. The configure script for Qemu automatically detects that the GCC 3.x is installed as /usr/bin/gcc-3.3 and tries to use that. The problem is that the compiler is actually a cross-compiler for PowerPC and that it cannot produce x86 binaries. Per this post I found out that using the -arch ppc flag allows the compiler to be used on an Intel machine. Obviously the resulting binary will be a PowerPC binary, but should run under Rosetta on an Intel machine.

Note that I still don’t have a solution for building Qemu on Mac OS X. This post is just a note about one aspect of the whole problem.

What to do when Parallels brings the System to a halt

I don’t know when this started, but recently whenever I try to start Parallels (which admittedly doesn’t happen very often), my whole System comes down to a halt. Well, not completely, the system is still running, but it won’t even let me switch between applications in a responsive manner. Even the mouse movement isn’t smooth anymore.

Note that this is with Parallels 2 on Mac OS X 10.5. The system is a first generation Mac Pro w/ two 2.66 GHz Core 2 CPUs and 3 GBytes of RAM. So the system could use a little more RAM, but apart from that it shouldn’t have any issues running Parallels. And in fact, things used to work just fine.

Anyways, here’s a workaround I’ve discovered today:

$ sudo /Library/StartupItems/Parallels/Parallels stop
$ sudo /Library/StartupItems/Parallels/Parallels start