I think you could make the case that tail recursion is safe in that it doesn't result in an unbounded stack. You'd really need the toolchain enforcing it though.

In embedded systems this is often the case. Not because it makes the software easier to understand, but for more practical reasons. You probably won't be stepping though the code with a debugger in real-time, but global variables are at fixed addresses and they don't disappear as soon as the function call returns, so they're just easier to look at.

I'm no networking expert, but does anyone know how this compares to SCTP?
And have they taken various security considerations into account, e.g. SYN floods?

Not exactly, according to NASA, we've found an estimated 911 out of 981 near earth asteroid in the >1km size range. 93% is pretty good, but a long way from "all".

I assume you have some lab computers that are already part of a network, can't you just install wireshark on them and use the existing network? You won't be able to teach everything, but you can probably cover a lot of it that way. Learning tends to be easier for me when I'm looking at the actual thing anyway. If you trust them with root access (or have automatic restores) they can experiment with different configurations too.

(warning, shameless plug)

I've been working on a similar program for a while called libgis. The main difference is that libgis is built as a library instead of an application and uses OpenGL for rendering, which allows it to render terrain. It also uses GTK+ instead of Qt, but that's just due to my personal preferences. Unfortunately, it's not (yet!) as complete as Marble/WorldWind/Google Earth.

Actually, you're pretty close there. Most of the projects I've checked out I only look though, or only make very small changes or bug fixes. In the past I've used cvs, svn, git, hg, and mtn. There's a bit of learning curve with each of these. Conceptually it's not too hard, but I have a hard time keeping track of whether it's `foo checkout --head' or `foo revert', `foo log --max-count' or `foo log --limit', etc. If you can keep track of all of these, then good for you, but I can't and would rather not try.

I've noticed this as well, at least using git against other repos (git-svn, git-cvsimport), but it's always seemed like a kludge to me. I haven't looked into it, but I've always assumed that git-svn/git-cvsimport/git-* were specific to git, which means they would need to be reimplemented in hg, mtn, etc. A common format for pulling changes would mean you'd only have to implement one other protocol besides the native protocol.

Most projects let you pick your editor, filesystem, distribution, etc. It would be nice to add version control to that list. That doesn't seem like it would be all that hard to do. There are already tools to migrate a repository between different version control systems and they mostly use similar concepts.

Git, mercurial, monotone, etc. are all ready nice, and do pretty much the same thing, but it's annoying to have to use the one that the project leader decides on. It would be nice (if it's possible) to be able to pick which one you want to use as a client, and have it work with whatever the project manager wants to use for the upstream repository. I'm not sure what all this would encompass, probably some common distribution (push/pull) protocol would need to be implemented by all the different SCMs..