Remove Kentucky instructions, just leaving the URL: the ones in
the handout appeared to be out of date, and the online page
contains the full set of instructions

Add a link to the flash client

Add a few URLs for more information

In two formats: a square-ish one and a wide banner. SVG source
and PNG renderings included.

Cons up when I was updating the Xen vnode support last year.

Basically, make it possible to transfer a non imagezip image.  Previously
you had to wrap a regular file as an image in order to transfer it.  The
big hang up was that the frisbee protocol could only transfer files that
were a multiple of 1MB (the chunk size).

This commit changes the frisbee protocol slightly to allow transfer of
non-1MB-multiple files.  The protocol change was to add a new JOIN message
that returns the size of the file in bytes rather than in blocks.  This
allows the client to know that the file in question is not a multiple of 1MB
and allows it to request the correct partial number of blocks for the
final chunk and to extract the correct amount of data from the final 1K block
(that block is still padded to 1K by the server).  For the server side, the
request mostly allows it to do some sanity checking.  The fact that the
server is started with a file that is not a multiple of 1MB is what triggers
it to know about partial chunks.  The sanity checking is that the server will
not acknowledge clients that attempt to join with a version 1 JOIN message,
since nothing good would come of that pairing.

On the client side, frisbee must be invoked with the -N (nodecompress) option
in order to issue a v2 JOIN.  See the comment in the code for the rationale,
but it is largely a backward compat feature.

While I was changing the JOIN message, I added a couple of other future
features.  One is that by passing back a 64-bit value for the size of the
image in bytes, we can feed bigger images.  However there is still much to
be done to realize this.  The other was to add blocksize/chunksize fields
in the message so that the server/client can negotiate the transfer parameters,
e.g., 1024 blocks of 1024 bytes vs. 256 blocks of 8192 bytes, the latter being
for "jumbo" packets on a Gb ethernet.  But there is still more to be done to
get this working too.

This was blowing up the '-N' ("just save it") option of frisbee on big
files.

Use the new event scheduler by default for any
users/groups/experiments configured for it using EmulabFeatures.

Added '-N' option to eventsys.proxy to have it use the new scheduler
(if it exists) instead of the old one.

Added test for NewEventScheduler feature to eventsys_control so that
it will pass the '-N' option to eventsys.proxy for
experiments/users/groups using the feature.

These changes will go away when the new event scheduler replaces the
old one.

Modify the event scheduler to use the BSD-licensed xmlrpc-c library
instead of the LGPL-licensed ulxmlrpcpp.

Merge in Leigh's changes to retry operations on transient errors.
Show a heartbeat when waiting for XMLRPC requests to return.

I had done this a while ago, but broke it slightly when I added MLE
stuff.

When remembering a passphrase, attempt to decrypt the private key with it.
If decryption fails, complain, and try again, and again, and again...

almost impossible to get the shared nodes to be used fairly. Revisit
later.

(busy).

See http://users.emulab.net/trac/emulab/wiki/oml.

Conflicts:
	tbsetup/ns2ir/tb_compat.tcl.in

too busy error.

The test scripts will retry when it sees this error.

wrapper, which means the server is WAY too busy. Instead of just
bailing, retry every 5 seconds. User is free to hit ^C to halt the
loop, no harm done.