Its not that its poorly coded, but rather an oddity that comes from playing maps that aren't designed for real-time lighting.
In the original Quake, the lighting was hardcoded (maps were put through a "light" compile phase that would determine all the shadows and put the shadowmap directly onto the level). Because it was static lighting, the designers put lights all over the place. This gave them nice, even lighting with no performance hit, except that the light phase would take longer.
This worked great in 1996, but since modern games have real-time lighting, jamming a room full of lights doesn't work as well. Since the "light" phase is run on every frame, there's a substantial lag introduced by having the number of lights they used (if you poke around the map source posted by Romero, its well into the hundreds in some levels). By comparison, Doom 3 had far fewer lights per level (typically, >100 lights) and had some serious culling going on so it wouldn't have to render every light every frame (something that the id Tech 1 engine doesn't support).
Moral of the story: a crapload of lights is slow, no matter where you put the lighting calculations.
"running Windows XP under virtualbox is a lot faster than running Windows natively"
WHAT?!?!?!? Are you crazy? By its very definition, running an OS in a VM is slower than running an OS natively, since there is still a host OS that's running the VM app.
There is a small speaker, but music doesn't play through it. iPods are designed for you to use them with a pair of headphones are earbuds, and only the use the speaker sparingly (typically as a clicker if there are no headphones attached).
That said, my 1st gen. iPod Touch doesn't have bluetooth or a mic input, so what's the point of it? Or is this limited to 2nd gen. iTouches?
We have a equal opportunity Calculus class -- it's fully integrated.