Success Through a Failed Attempt to Set up an Xserver Environment

When you rsh into a raspberry Pi, the splash screen includes the following line:

   Type 'startx' to launch a graphical session

I've logged into headless machines before and set up the DISPLAY variable so that I could start an Xserver and have all of the graphical output directed to a machine with a real display device.  This is pretty vanilla Unix stuff, but it led to some other mildly interesting discoveries about my particular VM-based environment.

When I did an ifconfig, it revealed that my IP address was 192.168.91.143.  I was on a different subnet than the rest of my network.  I could ping my Ubuntu guest in at this IP address from my Windows 7 base environment, but the response times were very sluggish - ranging from 500 MS to well over a second.  Nothing actually timed out, but it wasn't optimal.  I could also ping my PIs from Windows 7, and things there seemed pretty normal.

For some reason though, I couldn't reach my Ubuntu guest from the PIs.  This means that I wouldn't be able to use this guess as an X client, and have it receive graphical sessions from the PIs.  Why I could go the other direction from Ubuntu to the PIs is beyond me.  There are network details here that I don't understand, and don't really plan to find out.

It then occurred to me that these behaviors are probably the result of the default network connection that VMware and most other give you - Network Address Translation (NAT).  This maps the IP address of the guest system to the underlying IP address of the host machine so that they share an IP address as far as the external network sees them.  Presumably this means that somewhere in the stack, my 192.168.91.143 address that Ubuntu sees, gets mapped to the 192.168.1.102 address of my Windows 7 environment.  All of this address translation is probably why performance suffers when I Ping Ubuntu from Windows.

I tried switching to a bridged configuration to see what would happen.  I've had bad experiences with this in the past under KVM and VirtualBox - both of which not only didn't work properly, but they left my guest system flopping around like a fish out of water.

This time however, everything worked as I had expected.  My IP address changed to 192.168.1.118, so I was on the same subnet as everyone else.  I could reach my Guest system from the PIs, and the apparent performance issues I had between Windows and Ubuntu vanished.  VMware was solid here, and life is good - almost.

I exported my DISPLAY variable from one of the PIs to my new Ubuntu IP address, and attempted to start an Xserver via startx.  It still didn't work.  At this point, I've decided to put this effort on the shelf.  It isn't strictly needed for what I want to do right now.  This exercise was a fruitful one though, because I'm not running a bridged connection that I think will give me more of what I want in terms of performance and configuration.

I'll be back to this later though.

Back to Bramble Setup

Ok, class finished about a week ago, and it was a great experience.  I'm looking forward to taking another course in the future, but for now it's time to get back to the Pi bramble.  Once I get the setup completed, there are some interesting things that I'm going to try to drag over from my Neural Networks environment to the bramble.

Just to level-set, I've got the message passing interface (mpich2) installed and built on all of the Pi machines.  I see that there is now an mpich version 3 available as of mid-November, but I'm staying put on this version until we get things up and running.

The next step is now to configure the network of machines.  I established machine number 1 as the master, and the rest as slave machines.  Follow the directions to setup the rhosts files for the root and pi users, and /etc/hosts so that all of the machines can see each other by name (see the instructions in the west coast labs blog).  My /etc/hosts on each machine now contains these lines (among others):

192.168.1.151    RsPi1    RsPi_1    R1    r1    Master     master
192.168.1.152    RsPi2    RsPi_2    R2    r2    SlaveR2    slaver2    slave2
192.168.1.153    RsPi3    RsPi_3    R3    r3    SlaveR3    slaver3    slave3
192.168.1.154    RsPi4    RsPi_4    R4    r4    SlaveR4    slaver4    slave4
192.168.1.155    RsPi5    RsPi_5    R5    r5    SlaveR5    slaver5    slave5
192.168.1.156    RsPi6    RsPi_6    R6    r6    SlaveR6    slaver6    slave6
192.168.1.157    RsPi7    RsPi_7    R7    r7    Slaver7    slaver7    slave7
192.168.1.158    RsPi8    RsPi_8    R8    r8    Slaver8    slaver8    slave8

This is replicated on all of the Pi machines.  It's as far as I've been able to get with the setup so far.  I'm getting close to running something soon.

Been away for a while

My Neural networks class has ramped up fully, and it's been soaking up a lot of my time.  It's a great class, taught by a great professor - Geoffrey Hinton from the University of Toronto.  I've finally gotten to a lull in the course work, so it's time to get back to the Pis to complete the Bramble.

There is a greater plan, which I have mentioned before - once the neural networks class is over, I'm going to try to map this to the bramble.  This may be a fool's errand, but it just might work too.  Either way, it will be an adventure, and may lead to something useful.

Setting up the Message Passing Interface (MPI)

After configuring SSH with public/private key pairs, and setting up aliases for in /etc/hosts for each PI node, one more useful thing is to update the command prompt to make it easy to know which machine you are working with.  I altered the .bashrc profile on each machine like this:

# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

# JB - Put the machine name in the prompt to make it easier to know which
# machine we are running on.
export PI_NODE=R1

...

if [ "$color_prompt" = yes ]; then
    PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@$PI_NODE\[\033[00m\] \[\033[01;34m\]\w \$\[\033[00m\] '
else
    PS1='${debian_chroot:+($debian_chroot)}\u@$PI_NODE:\w\$ '
fi

...

Not only does this make the node name apparent in the prompt, it gives us a handle on each machine to use if we want to write tools:

pi@R1 ~ $ echo $PI_NODE
R1
pi@R1 ~ $

Now it's time to install the message passing software - MPI-2.  I'm going to build this form the source, just to get the latest version.  Thanks to Phil Leonard for the pointers to everything.

1. sudo apt-get install fort77
2. wget http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/1.4.1p1/mpich2-1.4.1p1.tar.gz
3. tar zxfv mpich2-1.4.1p1.tar.gz
4. cd mpich2-1.4.1p1
5. sudo ./configure
6. sudo make
7. sudo make install  

Step 1 was to install the Fortran compiler (fort77), which is no big deal.  Then the rest of it built and installed without any problem.  As Phil mentions in his blog (install option 3), this takes a while - at least a couple of hours, so you may want to plan accordingly.

I got this to build and install properly on my first Pi node, so now I'm off to replicate this on the other machines.  I can install of these machines in parallel of course, but it will still take some time.

My First MOOC Class - Neural Nets

Yesterday I took my first online class in the neural networks class offered by Coursera.  I took a set of machine learning classes when I was working on my masters degree at Rensselaer, and I always found neural networks interesting.  Unfortunately our course material never required us to actually create a network, so neural nets were never more than an academic interest for me.

Fortunately, I recognized the name of the instructor for this course when I read the description.  Geoffrey Hinton is a leading name in the area of neural networks, and he was referenced many times in the readings that I had for my masters classes years ago.  This is my chance to actually lay hands on a neural network, and learn from a leading thinker in the area.

My experience with Massively Open Online Courses (MOOCs) is pretty limited right now, but my first impression is positive.  The Coursera site is well constructed and easy to use.  I would recommend it to anyone thinking about taking a class.

The long term goal here is to really learn how to implement neural networks, and then move them onto the Raspberry Pi bramble I'm in the middle of creating.  These networks are inherently parallel beasts, so it should be an interesting exercise.

Making This Parallel Pi Environment Manageable

This seems like a good time to re-cap some configuration steps I've taken, because I don't think I've summarized them very completely so far.  Once the systems are all physically mounted and cabled, all of the SD cards have had the system image installed and they are inserted into each machine, attach a keyboard and monitor to one of the machines, and power it up to perform initial configuration.  You should see the main raspi-config setup screen.  These are the settings that I have completed:

1.  Expand rootfs.  This is per the recommendations, and will allow the whole SD card to be used.
2. Configure keyboard.
3. Change password.
4. Set timezone.  This will be important if there is a need to debug things.  Timestamps are useful, so having all of the machine set to the correct timezone is necessary.
5. SSH - enable.  This is very important, because this allows us to reach each of the machines without having to attach a keyboard/mouse/monitor.
6. Boot behavior - boot to desktop.
7. Update.

Once this is done, the raspi-config utility should leave you at a command prompt.  Issue a "sudo shutdown -r now" command to re-boot the machine.  When it comes up the next time, there will be a bit of a delay as the system re-blocks the root file system to take advantage of the full size of the SD card.  This should only take an extra minute or two though.  You should then see the Raspian desktop.  Initial configuration is now complete.  Shutdown the machine, move the keyboard and monitor to the next machine, and repeat the config until all of the machines are ready.

Once initial config is complete, you do need to assign fixed IP addresses as I mentioned before.  The steps to making this work really depend on the local network that you have available, so it's not much use to go into detail about how to do this.

One very helpful and common setup step is to edit /etc/hosts, and set up a name for each of your systems.  This way you don't have to use IP addresses every time you need to touch a machine:

# My Stuff
192.168.1.151    RsPi1    RsPi_1    R1    r1
192.168.1.152    RsPi2    RsPi_2    R2    r2
192.168.1.153    RsPi3    RsPi_3    R3    r3
192.168.1.154    RsPi4    RsPi_4    R4    r4
192.168.1.155    RsPi5    RsPi_5    R5    r5
192.168.1.156    RsPi6    RsPi_6    R6    r6
192.168.1.157    RsPi7    RsPi_7    R7    r7
192.168.1.158    RsPi8    RsPi_8    R8    r8

Now that there is an 8-headed monster here to deal with, the challenge becomes one of dealing all of these machines in a simple and efficient manner.  If you want, you can log into each machine via ssh or telnet, and have a console up for each one to control it.  This is very tedious though, since you'll most likely want to do the exact same thing on every machine most of the time.

Fortunately, there is some additional setup that we can perform that allows us to skip the login and password overhead for every action that we want to take.  By using ssh and identity keys, it's possible to make things a lot simpler.  Here is a good HOWTO for setting up ssh identity keys in general:

http://sshkeychain.sourceforge.net/mirrors/SSH-with-Keys-HOWTO/SSH-with-Keys-HOWTO-4.html

I pretty much followed these instructions as presented, but here are the details of my installation.  Note that I am running all of this from an Ubuntu system that is not part of the pi network.  This could be done from Windows or Mac, but there is extra work to setup the environment for things like /etc/hosts, and commands like ssh.

•   Create a public/private key pair by running ssh-keygen in my home directory. I created a type 2 DSA key:

frodo@ubuntu:~$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/frodo/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/frodo/.ssh/id_dsa.
Your public key has been saved in /home/frodo/.ssh/id_dsa.pub.
The key fingerprint is:
fa:59:71:1e:ef:a8:e7:b6:66:b0:9d:6f:54:1a:6b:14 frodo@ubuntu
The key's randomart image is:
+--[ DSA 1024]----+
|                 |
|              E  |
|               . |
|              o .|
|        S . o. = |
|       .  .+ o=  |
|      .   .+.+.  |
|       . o. Bo.  |
|        o .B++o  |
+-----------------+
I didn't use any passphrases, because this is the point to setting all of this up - avoid the prompts for passwords or phrases when logging in or issuing commands on the pi machines.

• Looking in the .ssh directory shows the public and private keys I just created:

frodo@ubuntu:~/.ssh$ ls -l
total 12
-rw------- 1 frodo frodo  672 Oct  1 09:19 id_dsa
-rw-r--r-- 1 frodo frodo  602 Oct  1 09:19 id_dsa.pub
-rw-r--r-- 1 frodo frodo 1998 Oct  1 08:58 known_hosts

• I copied these over to a a pair of files to make the names more descriptive, and create a backup.  Save these away somewhere, because you can't get them back if they are lost:

frodo@ubuntu:~/.ssh$ ls -l
total 20
-rw------- 1 frodo frodo  672 Oct  1 09:19 frodoTheBrave_dsa
-rw-r--r-- 1 frodo frodo  602 Oct  1 09:19 frodoThebrave_dsa.pub
-rw------- 1 frodo frodo  672 Oct  1 10:23 id_dsa
-rw-r--r-- 1 frodo frodo  602 Oct  1 10:23 id_dsa.pub
-rw-r--r-- 1 frodo frodo 1998 Oct  1 08:58 known_hosts

Note that it's important to keep the the original public (id_dsa.pub) and private (id_dsa) file names, since the private key is used by ssh on the originating machine to match up with the public key that we are about to copy over to the remote pi machine.  In other words, don't re-name these files, just make copies of them

• Now move the public key over to one of the target machines using scp:

frodo@ubuntu:~/.ssh$ scp frodoThebrave_dsa.pub pi@r1:./frodoThebrave_dsa.pub
pi@r1's password:
frodoThebrave_dsa.pub                                      100%  602     0.6KB/s   00:00   

I have given my target machine a name of "r1" (in /etc/hosts), and the default user name on each of the pi images is "pi", hence the "pi@r1:" address of the remote file.

• Now log onto the remote machine as user "pi" (using ssh or telnet) to put the public key in the right place.  If you look at the pi's directory, you can see the key that was just copied over:

pi@raspberrypi ~ $ ls -l
total 20
drwxr-xr-x 2 pi pi 4096 Aug 15 20:56 Desktop
drwxr-xr-x 3 pi pi 4096 Sep 18 20:55 Documents
-rw-r--r-- 1 pi pi  602 Oct  1 10:10 frodoThebrave_dsa.pub
drwxrwxr-x 2 pi pi 4096 Jul 20 14:07 python_games
drwxr-xr-x 2 pi pi 4096 Sep 18 20:55 Scratch

• Create a .ssh directory if one doesn't exist, cd into it, and create a type 2 key file.  This is what will hold the keys for all of the remote users who may want to execute commands on this machine as user pi.  Here are the necessary commands

pi@raspberrypi ~ $ mkdir .ssh
pi@raspberrypi ~ $ cd .ssh
pi@raspberrypi ~/.ssh $ touch authorized_keys2
pi@raspberrypi ~/.ssh $ chmod 600 authorized_keys2
pi@raspberrypi ~/.ssh $ ls -l
total 4
-rw------- 1 pi pi   0 Oct  1 10:13 authorized_keys2
-rw-r--r-- 1 pi pi 666 Sep 28 08:27 known_hosts

• Now put the public key into the key file, clean up the public key that we copied over, and everything should be ready on the Pi machine:

pi@raspberrypi ~/.ssh $ cat ../frodoThebrave_dsa.pub >> authorized_keys2
pi@raspberrypi ~/.ssh $ cd ..
pi@raspberrypi ~ $ ls -l
total 20
drwxr-xr-x 2 pi pi 4096 Aug 15 20:56 Desktop
drwxr-xr-x 3 pi pi 4096 Sep 18 20:55 Documents
-rw------- 1 pi pi  602 Oct  1 10:10 frodoThebrave_dsa.pub
drwxrwxr-x 2 pi pi 4096 Jul 20 14:07 python_games
drwxr-xr-x 2 pi pi 4096 Sep 18 20:55 Scratch
pi@raspberrypi ~ $ rm frodoThebrave_dsa.pub
pi@raspberrypi ~ $ ls -l .ssh
total 8
-rw------- 1 pi pi 602 Oct  1 10:14 authorized_keys2
-rw-r--r-- 1 pi pi 666 Sep 28 08:27 known_hosts

Note that the authorized_keys2 file in .ssh should now be the same size as the original public key - 602 bytes in this case.  Of course, if this key file contains multiple keys, it will be larger than the public key we just added.  The point is, the key file is a repository of keys for each remote user that will have access to this machine (r1) using this userID (pi).

• Now we are ready t execute a command from the remote machine, and have it run on the target pi machine without being prompted for a password:

frodo@ubuntu:~$ ssh -2  pi@r1 date
Mon Oct  1 11:58:51 EDT 2012

It's magic, and it's more secure than using passwords, since we're now using RSA encrypted keys to authenticate between the machines.


As with the other setup steps, repeat for all of the other machines so that the whole environment is now set up to use this kind of infrastructure.  This is what we will build our toolset upon.

Assembly complete ...

Everything is connected, and after some tweaks, it looks like this:

Even though this setup is only 8 nodes, the amount of hardware involved is pretty significant when you put it all together.  I expected that there would be at least one or two things that didn't work, and that came to be.  As it turns out, one of the power supplies (cell phone chargers) was DOA, and Pi card number 7 would never fully boot.  I tried replacing the SD card and the network cable, but the system either hangs, or goes into an infinite loop on first boot.  Sometimes I could get into the raspi-config tool, but it would never complete before a problem occurred, and it never failed at the same place every time.  I don't know why this happens, I could have damaged the card as I was mounting it, who knows.  It's just the way things go, and I'll have to replace it as I move forward.

Once the physical configuration was complete, I went to my router, and assigned fixed IP addresses for all of the nodes.  This involved finding the MAC address of each card (see the HWAddr field):

pi@raspberrypi ~ $ sudo ifconfig
eth0      Link encap:Ethernet  HWaddr b8:27:eb:1e:12:7d 
          inet addr:192.168.1.151  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1664 errors:0 dropped:0 overruns:0 frame:0
          TX packets:281 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:154134 (150.5 KiB)  TX bytes:27682 (27.0 KiB)

There should be a section of the admin interface on your router where you can choose an IP address and assign it to each of these MAC addresses.  Once the IP addresses are fixed, it's a relatively easy task to build a few tools to do housekeeping things like ping all of the nodes, or tell them all to shut down.  I've been able to reach all of these nodes using SSH, and expect that I'll build my tools around this.  There is probably someone out there who has done this before, but I'll do my own version, just to make it work the way I want.  I plan to enlist the aid of my able sidekick and son Neil to put a web interface on these tools once I have them working from the command line.

The next step is to move forward with the configuration as professor Cox describes - building the Message Passage Interface (MPI) for distributing work throughout the network.  This will be interesting to see work.

Building a Parallel Pi (physical assembly)

After laying out all of the Pi boards, I came to the conclusion that this will all comfortably fit on a single 12X18 cutting board.  I chose a nylon cutting board because of (1) weight - having 8 cables and 8 power cords attached to all of the Pi boards won't cause everything to want to fly away, (2) it won't conduct electricity and interfere with the operating of the boards, and (3) a cutting board is relatively cheap.

The next question is how to attach the boards.  Ideally, they could be clamped into place using a mechanism so that we don't have to worry about them falling out, regardless of the orientation of the cutting board.  The solution I thought of is to use plastic coax cable staples:

These can be placed under the boards to give some air space between the Pi board and the cutting board, and on top of the board to clamp things in place.  The idea here is to remove the little nails from the staples, drill some holes to run a screw through them, and attach to the cutting board.

There are a couple of points to keep in mind.  First, a nylon cutting board is remarkably hard.  Pilot holes are needed to get a screw to tap into it.  Second, the arrangement of the Pi boards on the cutting board is important.  I decided to keep the CAT5 cables in the middle, with the SD cards and the power lines running around the outside.  This gives good access to the ports and slots in the event that I need to change or update them.  It's important that the master Pi board (board 1 below) has all ports reachable.  This is the machine that the monitor will attach to, so the HDMI port also needs to be accessible.

Here is the completed assembly:

Assembled board, sans cabling

This is a big step for the hardware configuration.  There is still work to do to cable everything up.  After that, we'll be ready to build and configure the parallel code to form a bramble.

Building a Parallel Pi (2)

I've been spending a good deal of time lately thinking about an optimal physical configuration for an 8 slice Pi bramble.  Professor Cox's Lego setup is a very good one, but my concern is the way the cables tend to twist and lift the card  up in the air.  Whatever platform I mount the Pi cards to has to have enough weight to keep everything in place.

Professor Cox has 64 nodes arranged into 16 planes/blades, grouped into 2 sets of 8.  I think stacking things this high gives these configurations enough heft to stay put.  However, I'm only going to have 2 planes of 4 Pis each, and with 2 cables (CAT5, power) per card, I think a Lego board underneath will be a little too light for things to be stable.

I think I'm going to use an 18' X 12' nylon cutting board to mount each Pi, 4 to a board.  I'll then stack 2 of these, and probably put a plexiglass top over it all to make things easy to see.  I've been collecting all of the parts for this, but before I can get serious about assembling things, I need a work space.  The living room isn't a good place to do this.

Here is what things look like now:

The wire frame shelves make a good Pi rack, because it's easy to thread cables and cords between the shelves.

I went with a wireless keyboard to eliminate a USB cord, and make the configuration a little less cluttered.

The next step is to begin mounting and cabling everything up.  That is going to be an interesting challenge.

Building a Parallel Pi (1)

So far things are progressing according to plan.  The instructions that professor Cox has provided are nicely accurate, and to the point.  There is not a lot of wasted motion here.  There are a few observations about the construction process that I have:

• The Pi doesn't boot sometimes if you put the SD card in before giving it power.  Pulling the card and re-inserting with the power already on seems to make things work.
• Mounting the Pis on a board is a practical thing to do early in the process.  Right now, the one Pi that I'm working from just hangs in mid-air between the CAT5 and HDMI cables - a sub-optimal configuration.

• The stuff that you find in regular retail stores varies a lot in price and capability.  Since the total cost will be a multiple of the per-node cost in this configuration, things can add up quickly.  My full configuration will be 8 nodes, and although I ordered all 8 Pis at once, I've decided to buy the rest of the parts as-needed, until I'm sure that I'm getting the right stuff.  
• For each node you're going to need an SD card and a power cord.  So far I've chosen 16 GB cards, and this seems like a good size to give a reasonable amount of local storage at each node.  I've bought 2 cards so far - one for $14.99, and one for $19.99.  The cheaper one claims to be fast, and the more expensive one claims to be faster.  I do notice that the apparently faster one seems to allow the Pi to boot and run faster, but that's just a subjective impression.  Most common 16 GB SD cards out there seem to cost between $29.00 and $39.00, which seems pretty high.  I'm going to buy the other 6 cards that I need online, and get something that is a good balance between speed and cost.  The power cords are a similar mixed bag.  I've paid $19.99 for each of the 2 USB/micro USB cords, and $9.99 for a 2 port charger to plug them into.  The charger price seems ok, but I really think I can do better than $20 for a 3 ft. long USB cord from an online source.

From an actual configuration standpoint, I've installed the Fortran compiler, and am ready to build MPi to provide the message passing interface that we need for the parallel part of this project.  So far, so good.

Time for some Pi

I ran across a great article in Ars Technica about Professor Simon Cox at the University of Southampton, and his 6 year old son, who built a 64-node parallel machine out of Raspberry Pi devices and a rack made of Legos.  He gives step-by-step instructions on how to set things up, and this seemed like a perfect opportunity to do something cool.  If you aren't familiar with the philosophy behind Raspberry Pi, it's worth the read, and is a noble cause.

Professor Cox's 64-node configuration costs a little more than I care to spend, but I figure an 8-node environment would be a good balance between reasonable parallelism and cost.  I started with the instructions above, and here is what I found ...

I ordered 8 Raspberry PI model B boards from MCM Electronics at $35 apiece.  2 days later (today), they arrived.

We (me and my son Neil) picked up a wireless keyboard, cell phone mini-USB power supply, and 16 GB SD card for another $81, and began an installation.

I downloaded the wheezy-raspian distribution, dropped it on my new SD card, and everything worked per the instructions.  The first-boot was magical - everything came up as intended, and I got into the initial config tool.  Make the following config changes:

• Expand the root file system to use the whole SD card
• Set the user password
• Enable SSH
• Boot to the user shell
• Install updates

Being able to reach the web from this little machine and see it all on my TV in the living room was great.

After re-booting, the system came up to a point, and then did an online config of the root file system.  This took a relatively long time - several minutes, so we had to be patient.  Eventually everything came up, and we saw the desktop:

We could surf the web, or do anything that a regular machine can do.  It looks like the system takes about 1.6 GB of space, since a check of the root file system showed about 90% free.  None of this was blazing fast.  You never forget that this is a configuration with an ARM1176JZF-S 700 MHz processor, VideoCore IV GPU, and 256 Megabytes of RAM.  One thing that may be affecting the performance of this setup is the speed of the SD card.  We used a PNY card with no particular claims for speed, so who knows.

The performance of the individual nodes won't be a big deal if we can get a parallel configuration right, and apply it to some task that lends itself to parallel solutions.

This was a successful and satisfying first day.  It was fun to see one of these little machines take it's first step.  Next we'll start getting the parallel environment in place.

Hello, World

I've been thinking for some time about taking advantage of some of the Massively Open Online Courses (MOOCs) that are now available from several different sites on the web.  My goal is refresh or re-learn several of the subjects I covered when I worked on my Master's degree.  Most of these subjects had to do with machine vision, parallel programming, or AI in general.  These were great areas of study, but when I went back to work, there just wasn't much chance to apply what I had learned.

Fast forward several years (more than I care to admit), and the time has arrived for an intellectual re-boot.  This blog is intended to be journal of my adventures in assorted areas of computing.  I hope everyone finds this stuff as interesting as I do.