Sorta-Seamless Virtualization

I’d seen an article before about using VMWare to run Windows programs “seamlessly”–as though they were being run from the user’s own desktop. I say sorta because you can try to make the themes and widgets match up, but it just won’t always work. Anyway, today I stumbled across another article and so, with little else to do, took the plunge. I won’t regurgitate the article. This is the link:

Though the one comment I will make is make absolutely sure that you are logged out before trying to launch your app of choice–if you don’t, you will get the whole Windows desktop.

If I won’t regurgitate, then what am I writing about? Well, after the whole thing worked I got to thinking: normally, if I am not using a VM in any way shape or form, I shut it down. I don’t have limitless resources on this Dell laptop and those CPU cycles are precious. Wouldn’t it be nice if we could boot the VM whenever it is not running but we try to run the program? Why yes, it would and we can do make it happen with VMWare Server’s command line tools. I wrote this in Python, as bash does not have a sleep function (which is needed if the VM boots up so that it will wait until the boot process is finished before trying to connect). In all its glory, with some machine-specific redactions, is the nifty little script I wrote:


import os
import time

onoffStream = os.popen('vmware-cmd /
[pathto]/Windows XP Professional.vmx getstate | cut -d " " -f 3')

onOff =

if onOff == 'off':

    os.popen('vmware-cmd /
[pathto]/Windows XP Professional.vmx start')
    time.sleep(60) # wait 1 minutes

os.system('rdesktop -A -s "c:seamlessrdpseamlessrdpshell.exe C:
[privateIP]:3389 -u iuser -p ipass')

Haskell as UNIX

I was continuing work on the tutorial I have mentioned before and one thought occurred to me: Haskell (and functional programming in general) promote a UNIX-ish way of thinking. UNIX’s mantra is “Do one thing and do it well.” Anyone who has done some functional programming knows, you are, very quickly, forced to break the task down into pieces. Then, you write a function that does one and only one piece. Scheme encourages this style, Haskell all but mandates it.

Under the UNIX style, we have a utility (awk/sed or perl, depending on who you ask) to process text files*. We have a utility that dumps a file to stdout (cat), a utility to find files (find), to search text (grep), etc. Indeed, the principle point of shell scripting is to chain multiple utilities together.

Somewhere between this similarity, language fanaticism, genius, and mania someone seems to have come up with the idea of marrying the two and the idea of the Haskell shell was born: h4sh. It looks kind of nifty on paper. I don’t know that I would write my shell scripts with it, though. The more typical ba/sh seem to work well enough and, honestly, I am having a hard time thinking of anything that you could really do with h4sh that you can’t do already. If anything, it’s more stylistic. This isn’t a criticism or a slam of the work. Interesting idea and I am all for new ideas. Maybe I am just not hardcore enough yet.

Is this pattern useful in any way, shape, or form? I am not entirely sure. I suppose one could write a shell for where the difference between user-defined function and a program is practically nil. I could create a function sort (yes, I know that there is a sort utility) and, on the mythical command line, do this:

$ cat foo | grep “bar” | sort

And get the correct result. In bash, you would have to pas the result of grep as a list to sort (barring some magic of which I am not aware). You could store the function definitions (or byte code compiled) versions in the user’s home directory and load it in on startup. Some method to handle potential conflicts between function and program names would have to be put into place. I don’t even know that there would be anything useful about this, but it does have kind of a cool, geeky feel to it. Who knows? Perhaps someday I will try to figure out what the ideal shell would look like and create it. Just not today.

* At least, that was the intention. GNU Awk now includes such functionality as network ports and perl does everything under the sun including, 3D engines, apparently, according to this gem I’d stumbled across in past travels:
. What would possess someone to even try a 3D engine in Perl, I have no idea. Still, it all goes to show that feature creep is alive and well in the UNIX world.

Chicken Package

As I was heading out for lunch today, I was thinking about my good old project Latrunculi. I wrote earlier that I was going to put it on hold until I finish Ocean. As Ocean is coming along (at the moment I am rewriting a great deal of the macro expander; the code is coming along cleaner and more elegant than before, but not as quickly as I should long), this could be a while and no wonder. While compilers are not magic, they are not done overnight, either. This leaves Latrunculi hanging. I don’t like to leave projects hanging even though I routinely do it. So I decided to do a quick code audit and see how quickly I could push a first release out the door. I went to do a quick rebuild of the source and then remembered: since switching (for how long, we’ll see) to Ubuntu, I hadn’t installed Chicken Scheme. It is included in the repositories but, like Gentoo, the package was not up to date. The solution was obvious: do what any red-blooded OSS user would do: download the source.

The compilation went down without a hitch and as gobbledy-gook scrolled across my screen, I googled the creation of Debian packages. Why? Well, the whole point of a package manager is to manage your packages. As I quickly learned as a Slackware user (my fault, not Slackware’s) if you do not do this properly, things can quickly become unmanageable, by man or machine. Towards the build’s end, I came across an article on the use of checkinstall (,
a semiautomated method of generating Debian packages. The basics of Debian packages are easy to understand: a couple of control files and tars containing the actual files for the install–that doesn’t mean that I felt like doing it by hand. Like all programmers, I am fundamentally lazy when it comes to computers. There are bigger, better things to do than haggle with control files. So I decided to give checkinstall a spin. The usage is trivially simple: after building, issue this command as root:

# checkinstall -D installcmd

Where the -D flag instructs checkinstall to make a Debian package (instead of an RPM or tgz) and installcmd is the command to run the install (make install, in most cases). I went ahead and generated the Chicken 2.6 package attached to this blog post. By default, checkinstall automatically installs the package after building it. Sure enough, it worked. The one caveat I did hit was when Chicken tried to load a module that I generated from SWIG it failed, unable to find libpcre. I am not sure of the extent to which this is a problem, but here is the fix. As root, run:

# ln -s /usr/lib/libpcre /usr/lib/

That solved the problem on my box.

Your Own Private Database Server with VMWare

As the title implies (I hope) this post is a quick guide on how to set up a database server in a virtual machine with the aid of VMWare Server. The nice thing about Server is that it runs as a service, so our virtual server can continue running even after we shut down the console. In this example, I will use FreeBSD though you can use anything you want from Linux distro du jour, to OpenBSD, to Solaris, or even to Windows. On top of this fine OS, you will need to run some database system. I can’t make an example out of nothing, so I chose PostgreSQL. If you have never heard of it, it is, featurewise, the most advanced OSS RDBMS.

What is the motivation behind this little excercise? Well, using VMWare Server in this manner can help with testing so that you can run your apps against a server and get a little closer to real-life. You can also use it to run web apps that you may want to use personally (like a personal bug tracker), but don’t want the world to see. Finally, it is an opportunity to try something new if you haven’t done it before. So, let’s get to it, then!

The first thing you will need to do, if you haven’t done it already, is install VMWare Server. It is a free download, though it will need to register (again, free) for a serial number. So, if applicable, saunter over to and let them be your guide.

Done? Okay. Next, we will need to spawn off a new virtual machine. Log into VMWare and, on the home tab, select “Create New Virtual Machine”. While your mileage may vary, I chose the following options:

OS: Other -> FreeBSD
RAM: 160 MB
Hard Drive: 8GB, Not allocated, split into 2GB (mandated by the fact that I put the VM on a FAT32 external hard drive)
Network Card: NAT (this will change later).

and defaults for the rest. The VM we just created is, obviously, completely blank. So, go to and download the disc 1 ISO (we shall not need disc 2 for this tutorial).

Once that is finished, go back to the VMWare Server Console. Select the FreeBSD machine, then click VM->Settings. Set the CD drive to point to the ISO you just downloaded. Click OK and power up the virtual machine. The machine should boot straight up to the FreeBSD installer.

From here, do a standard FreeBSD install. I will leave the explanation of that to the FreeBSD project’s quite good documentation (or, perhaps at a later date, a different tutorial). As an FYI, due to the limited use towards this VM will be put, I elected not to install ports. While useful in general, it is hard drive space wasted here. If you kept it simple, the install should finish pretty quickly. When the prompt shows up asking you if wish to reboot, switch out of the machine (Ctrl+Alt) and switch the CD back to the physical drive so that the VM will not boot to the installer again. Then choose yes. The system will reboot and bring you to a simple login prompt. Login as root with no password. Now the fun begins.

The software that we will want on this box is simple: SSH and Postgres. Postgres was the whole point in doing this and having SSH for “remote” administration is both cool and useful. While, in eventuality, we want to make this a private server, we will need to download the software off the web. Keep the networking card set to NAT (or whatever you use to connect directly to the web). Once logged in, you can determine what device equates to your “card” by looking at /var/run/dmesg.boot In the case of my VM (and therefore, probably yours as well), the card was lnc0 and to get an IP run:

# dhclient /dev/lnc0

In FreeBSD, there are two “software worlds”: ports and packages. Ports is similar to Gentoo’s portage (in fact, it is the progenitor of it) in that it is an automated build system. Packages is more similar to a basic Debian or RPM system: it downloads compressed binaries and installs them on the system. For simplicity and speed, I will use packages here. The basic way to add packages is:

# pkg_add package.tbz

In order for this to work, package.tbz must exist in the current path. Fortunately, for some packages, there is the nifty little short cut

# pkg_add -r package

Which will both download and install the specified package. Like I said, this doesn’t work, out of the box, for everything. So, let’s just use it to get what we need to do the rest. Wget is a cool utility that runs on *NIX systems. It can be used to download files from the command line. So, grab it as above:

# pkg_add -r wget

This will download and install wget in /usr/local/bin. Add this to your path by adding the following to your .cshrc:

set PATH=${PATH}”:/usr/local/bin”

Then run:

source .cshrc

Now we can use wget in all its glory. Go to FreeBSD’s website and go to ports. Search for postgresql. A quick look at the latest version tells us that, in addition to postgresql-server, we will also need gettext, gmake, libiconv, postgresql-client. Fortunately, libiconv and gettext were installed with wget. So, look at the URL for the package and, for each of the remaining, run:

# wget URL

When done, you should have TBZ’s for all of the packages you need. Install gmake, then postgresql-client, and finally postgresql-server.

Almost home free, we just need to do some more configuration on both the client side and in VMWare to finish up. First we need to initialize Postgres’s various settings. We do this with the following command:

# /usr/local/etc/rc.d/postgresql initdb

Then we start the server itself:

# /usr/local/etc/rc.d/postgresql start

We will want Postgres to start up whenever we start the machine, so, using good or not so good old vi add the following line to /etc/rc.conf:


We will also need to create a database and db users. To create a DB nice and quick, log in as pgsql (a user installed by Postgres) and run

# createdb xyz

and voila! you have a database you can log in to.

Test everything to make sure it is working right, but at this point you should have FreeBSD running PostgreSQL just fine. The next step is to put this on a private subnet and make sure that we can access it from our host system (note: to help test, installing the PostgreSQL client on the host is recommended).

Now for the host-only part. Go to VM->Removable Devices->Ethernet Card 1->Edit and change the setting from NAT to Host Only. Then return to the guest machine and rerun dhclient. If successful, the VM will have acquired an IP on the private subnet. In the prompt, enter this command:

# ifconfig

Your card should be shown on the list with a fresh IP. Next, we need to make sure that PostgreSQL will actually listen on the port. First, edit the file /usr/local/pgsql/data/postgresql.conf. Set the following lines accordingly:

listen_addresses = ‘*’

port = 5432

This tells PostgreSQL to listen on all addresses (note that this does not have to be so, it just makes life easier in this scenario) on port 5432 (which is the client’s default). Next, edit the file /usr/local/pgsql/data/pg_hba.conf (HBA = Host Based Authentication). This file acts as Postgres’s private firewall (kind of). The rules in this file are evaluated to determine whether a given incoming connection will be permitted. I added this line to mine:

host all all password

host refers to any SSL or non SSL port, the second field is the databases to be allowed (which can be set to a delimited list), the users that will be allowed (which again, can be specified) the IP address and mask (setting to allows anything; think of a zero in any given portion of the address as a wildcard), and finally the type of authentication (password sets it to the good old fashioned password-based authentication; PostgreSQL has many options). Finally, go ahead and restart the PostgreSQL server with this command:

# /usr/local/etc/rc.d/postgresql restart

That’s it! Fire up a client on the host’s side and run it, specifying the IP address of the VM.

A few parting notes. I intentionally set security quite lax. Why? This is a virtual machine, not a real one, first, and secondly the only permitted connections will be off the private host machine. Be much more conscientious if this is for something remotely related to production! Secondly, while this article goes into detail only on the installation of PostgreSQL, the same lessons and principles can be applied to just about anything else.


FreeBSD Handbook

PostgreSQL Manual

It was Time for a Change

Yesterday, for no good reason, I decided it was time for a distro change. This aught to give anyone an idea as to what kind of a guy I am. The system was in perfect working order, chugging along as it had the past year plus, but I couldn’t leave well enough alone. I decided it was time to do something new and do it for real. You can try anything out in a VM and get an idea as to what you think of it (which I love), but you’ll never be able to develop an idea of the full picture without trying it on your day-to-day work machine.

What I Like:

The control you get in Gentoo is terrific, but it comes at a price. It is really nice to be able to get the computer up and running in an hour instead of a week. Despite the fact that Ubuntu recognized my wireless card (vanilla, Dell Latitude D505 laptop), I still had to spend some time twiddling with ndiswrapper to get it working correctly.

What I don’t:

Ubuntu’s slogan is “Linux for human beings”. They do a wonderful job trying to make Linux all warm and fuzzy for the masses, but they seem to have overlooked one thing: that the overwhelming majority of the people using it will still be, initially, geeks and programmers.

By default, neither bash nor vim come with coloring turned on. With Vim, the easiest way is to turn it on globally (which is what I want anyway): simply uncomment the line “syntax on” in the file /etc/vim/vimrc.

The fact that it IS so easy to turn these things on by default begs the question as to why the are NOT on by default. It isn’t like the devs have to go through a massive amount of effort to get this to work and it is a plus for many a geeky user

All in all though, it’s just another distro. It is Debian as Debian should have been: relatively easy to get installed and relatively up to date. One of the major points for me in giving Ubuntu a spin was to see what all of the fuss was over. Well, I see it and I don’t. It’s still Debian with a shiny face, but I guess that shiny face to Linux is what a lot of people have been waiting for.

2D Mouse Picking with OpenGL & GLUT

As I may (or may not) have mentioned, I have been piecing together my own Haskell tutorial that I hope to make available soon (what time is soon? With respect to deadlines, all times are soon). I decided to write the tour de force example program with HOpenGL as I’ve used OpenGL in the past and, I admit, I was a little ticked when the Haskell School of Expression used the Haskell X11/Win32 overlay. The reason being that because I play with sundry operating systems and programming languages I appreciate lessons that are transferable. If this is coding, I appreciate being able to pick up the bindings in another language and make use of it there, rather than using some languages jerry-rigged utility that I can’t use anywhere else.

The thing is, on the other project for which I’ve used OpenGL, I did it in pure 3D, but this example is a simple 2D game. This makes most of the rendering easier (or rather, less verbose), however this combined with the conditions of the game means that I have to redo the mouse picking. I also noticed that there isn’t a lot available on this rather arcane condition: 2D mouse picking in HOpenGL with GLUT. So, post-odyssey, here is the mad computer scientist’s lab report.

OpenGL, being a forward thinking spec, was written with 3D specifically in mind. This is well and good, we like 3D, and, for the most part, it is easy to ignore depth when rendering and get something that is 2D-ish out of the system.

GLUT offers a simple event handler for passive motion (i.e. motion when there is no mouse button pressed). In Haskell, the signature is of the form:

type MotionCallback = Position -> IO ()

Position has the form Position x y, where x and y are expressed in pixels. We can set the new “target” equal to these coordinates, with one problem: OpenGL does not measure its coordinate system in pixels (come to think of it, I haven’t the foggiest notion what it IS based on; I just had to develop something of a feel for it with practice). So we need to convert from pixels to the OpenGL coordinate system. Here is the finished code that accomplishes this:

viewp <- get viewport
pm <- get (matrix $ Just Projection) :: IO (GLmatrix GLdouble)
mvm <- get (matrix $ Just $ Modelview 0) :: IO (GLmatrix GLdouble)

coords@(Vertex3 x1 y1 z1) <- unProject (Vertex3 (fromIntegral x) (fromIntegral y) 0)

Providing the Z value in Vertex3 as 0 is important for the 2D aspect of this. If we were doing 3D picking, we would either render the scene to the back-buffer with color coding and read the color of the pixel where the mouse was located (the method used in Latrunculi) or we would use unProject twice: once with Z = 0 and the other time with Z = far plane and use these values to create a pick ray. x1 and y1 are the OpenGL coordinates we will need in 2D–with one caveat. The OpenGL axis is inverted relative to X11/Win32 windowing systems.
The OpenGL FAQ gives the way to do this as taking the WindowHeight – y1. This assumes the integer form of the OpenGL commands which is not present in the current HOpenGL bindings. What I found works is to invert the y1 coordinate in the following manner:

(x1, 0.0 – y1)

Which is, admittedly, the same as multiplying y1 by -1. So we literally invert the Y-Coordinate and presto! we have the coordinates we need.

As usual, the culprits in figuring things like this are the stupid little things: getting the type signatures correct in the first two lines and finding out (or rather, remembering) that the axis needs to be inverted.

Out of Commission

I was out of commission last week, but the cause was one of the best in the world: my wife just had our firstborn, a son. I just got back to work and I hope to post more quite soon.