Starcraft vs Monty Hall
If you're not familiar with the Monty Hall problem, it goes something like this:
There are three doors, and one of them has a prize. You choose one of the doors, and Monty opens one of the others that is not a winner. Now you have the option to stick with your original choice, or switch to the remaining door. It might seem counter-intuitive, but switching doubles your odds of winning.
Some people have attempted to apply the same logic to scouting as Zerg using an overlord and a drone in Starcraft. Stated similarly, the problem goes like this:
There are three starting locations, and one of them has your enemy base. You send a drone to one location, and your overlord gets to one of the other locations and discovers no enemy base. Now you have the option to stick with your original choice, or send your drone to the remaining location.
Sounds the same, but in this case, switching has no effect on your odds of winning. It is the same as the "Monty Fall" or "Ignorant Monty" variant of the Monty Hall problem, where Monty opens a door completely at random rather than one which is a non-winner.
The difference is because in the classic Monty Hall problem, you are initially choosing one door, which gives you 1/3 odds of your first choice being right. If you could choose to switch to both other doors, you'd obviously have a 2/3 chance of winning. In fact, this is exactly what you are doing when you switch, even after one of the doors has been revealed.
In the Starcraft problem, you are choosing two locations to begin with, which gives you a 2/3 chance of being right. If you choose to switch your drone to the remaining location at any point, the overlord still has a 1/3 chance and the drone still has a 1/3 chance. In the Monty Hall problem, you switch from only an unknown door (1/3), to the empty door and an unknown door (2/3). In the Starcraft problem, you switch from both an empty location and an unknown location (2/3), to the same empty location and a different unknown location (2/3).
To demonstrate this visually, I've made a simulator in Javascript.
Update (5/3):
I added a "Monty Hall mode" to the simulator, the implementation of which may help make this even clearer. Normally, I choose two random locations from the possible enemy starting points, and send the overlord to the first and the drone to the second. This leads to 3 possibilities with an equal chance of occuring: the overlord finds the base, the drone finds the base, or neither finds the base. Only in the final case, which occurs 1/3 of the time, would it be correct to switch. In "Monty Hall mode," the overlord is not allowed to find the base - so the 1/3 of the time where the overlord would normally have found the base, is now added to the 1/3 of the time when neither finds the base, making it correct to switch 2/3s of the time.
I also added a "Stupid Overlord mode" which demonstrates that the order is important. If the overlord chooses an empty base first, rather than the drone choosing first, the chances of the drone being correct are (obviously) 1/2.
Speaking at MBCSC2010
I will be speaking at the Myrtle Beach Computer Security Conference on April 15th. The title of my presentation is "Practical Web Application Security," and will partially be a rehash of my post about shared hosting but with more focus on why the little things matter and less on shared environments.
Streaming Nokia N900 Camera to VLC
I recently had need to look at the back of my own head, and using the camera on my phone seemed like the easiest way to do it. I found a guide on the Maemo wiki, but it was for the N800 and I didn't have the hantro4200 encoder it was trying to use. After learning more than I ever wanted to about gstreamer and sdp files, I came up with a way that works for me.
In my setup, my computer is 192.168.0.100 and the phone is 192.168.0.200. You will have to replace them with your own IP addresses.
Here is the command to start gstreamer on the phone. You will probably want to put it in a script:
gst-launch v4l2camsrc device=/dev/video0 ! \
dsph264enc ! \
rtph264pay ! \
udpsink host=192.168.0.100 port=5434
If gst-launch is not found, you probably need to install the gstreamer-tools package:
apt-get install gstreamer-tools
To use the camera on the front of the phone, you can change the device to /dev/video1.
Here is the minimal sdp file I was able to use with VLC to get it to play. Using the "Open Network" dialog to try and play an RTP stream did not work.
v=0 m=video 5434 RTP/AVP 96 c=IN IP4 192.168.0.200 a=rtpmap:96 H264/90000
The second line (m=) contains the port, the third (c=) contains the IP address of the phone, and the fourth (a=) specifies the codec.
To use MP4 instead of H264, you can just change h264 to mp4v everywhere. In the SDP file, it should be MP4V-ES, as in: a=rtpmap:96 MP4V-ES/90000. If you get errors in VLC like:
avcodec warning: cannot decode one frame (14922 bytes)
Then add send-config=true to the rtpmp4v part of the gstreamer pipeline, and make sure you start VLC before you start streaming:
gst-launch v4l2camsrc device=/dev/video0 ! \
dspmp4venc ! \
rtpmp4vpay send-config=true ! \
udpsink host=192.168.0.100 port=5434
For H263, you can try dsph263enc, rtph263pay and H263-1998 or H263-2000, but I couldn't get it to work.
I don't know if there's a way to control the focus, white balance, etc, but I was able to use the flashlight-applet to turn on the camera LEDs while streaming after I downgraded to 0.2-0:
apt-get install flashlight-applet=0.2-0
Hi WordPress
WordPress is way better than Blogger in pretty much every aspect, especially posting code, so I will post here instead.
edit: Except that it costs more to use a custom domain than it costs to just host the whole stupid thing myself. That's pretty stupid.