I like you, developed deployment for a mac based network (600 or so macs) back when command line ASR and netrestore were the best options. However, we also upgraded our deployment methods as Apple incorporated some of the technologies we used (cloning and automatic install options) into their server software. Today that particular piece of software is very well polished and does the job extremely well. The last time we did an installation (a few years ago) we used custom netboot images with automatic install options for different types of computers (lab, classroom, etc.) based on mac address. At the time we used a third party unix package manager or OS X called Radmind, but it proved to be more trouble than it was worth. However, Apple Remote desktop's package management and monitoring work very well and lets your do most of the upgrade install tasks you need to. In the end, the only per-machine work was setting up the machine to boot from the network by default.

Also, if you have the bandwidth, you can centralize your OS installs as server based images that are never installed on the thin clients. If you get it to work, it makes upgrades and deployment very easy.

If you want to discuss some of the problems we faced and our solutions, please feel free to contact me.

Its a bit misleading to say that Pidgin now implements video and voice for XMPP networks. They have implemented video and voice for the protocols that Google Talk uses which are unique to Google Talk. Other services (such as iChat) use different video and voice protocols on XMPP (possible on the Google Talk network). Since there is no unified protocol for video and voice on XMPP each service uses their own "proprietary" protocols piggy backed on an XMPP network. I guess us snobby iChat users will just continue to talk to each other.

They were smart enough to place the machine in one of the few spots in the hotel where there was no security camera to catch them, Priest said. "It was literally right next to the hotel security entrance." So even the security officials don't like to be spied on.

Which would quickly be overturned by said judge.

It seems a little odd to me that they picked an image hosting site (especially one a few steps above rapidshare in usefulness) to attack first. One of their stated goals from their website:
http://romeo.copyandpaste.info/

I understand that imageshack might get people's attention and spread your message, but if you stated goal is to attack sites that host tools and disclose exploits, wouldn't something like Sectools.org be more appropriate? Or maybe they couldn't handle something legitimate... Also, it seems likely that they would use tools distributed from just such a site to exploit an OpenSSH vulnerability.

If you don't like the idea of sending your information to google to have it indexed, you can look into some server side applications (with associated client apps) that do the indexing and searching for you. I'm not familiar with Windows ones (although I'm sure there are some) but there are quite a few for Linux and primarily Spotlight for the Mac. The option have the actual indexing done server side would save on your bandwidth tremendously. You may also want to consider using a different filesystem, one that has indexing capabilities built in.

From the attached article I can gather that since FFMpeg uses the LGPL 2.1 (not 3.0) that their obtaining a third party license for something else that prohibits them from granting similar rights for that bit of code does not affect their ability to grant rights for use the FFMpeg libraries. As they put it:

The fact that Party B may have a patent license with an unrelated third-party is irrelevant as long as it doesn't prevent Party B from granting people the rights LGPL 2.1 requires they grant them (namely, only those rights it in fact received from Party A).

Again this all seems rather moot anyway. A lot of operating systems these days include FFMpeg libraries as well as the H.264 and AAC libraries (which is really what this is all about). I know people feel like the idea of linking native libraries from the OS (which may or may not be there) goes against the universality of the HTML5 video/audio spec (and I can't say I disagree), but it would seem that for something as ubiquitous and freely licensable as the FFMpeg libraries, this argument is a bit overblown.

Technically its for the physics community, but its free and everything you're looking for.

Try http://evo.caltech.edu./

Is written in Java Web Start so its about as cross platform as you can find. It seems to work with most video cameras and microphones. It also features the following:

-Group Chats
-Screen Sharing
-Whiteboard
-Hard line call in to call from a phone line

Its for the physics community, so try not to abuse it. It should be fine if you just use it to chat.