When I worked at Microsoft, I knew one or two people who had the previous generation. Most people I saw had iphones. Now I've got a friend working on the Win7 team now and he's got one, although he still has his iphone....

I think the way MS does stuff is just so weird, they buy up everything thing that looks like a good idea, try to smash it all together, and then throw 90% of it away. And there's often some really good ideas in that 90%, but all it takes is one spooked exec or manager to chuck it all out...

I just want to point out that there are 3 different topics you're talking about there:

1. C++
2. OpenGL
3. Development/building on Linux

Indeed, there are pretty deep concepts behind each of them: C++ is related to fundamental programming concepts, object orientation, and metaprogramming, OpenGL deals with framebuffer rendering/graphics, and Linux development deals with source control, Makefiles, compilers, and configuration setups.

These concepts are not orthogonal by any stretch of the imagination, but it might help to keep in mind that each of them can be studied without the other.

Speaking from personal experience as a 'graphics guy', I would suggest you look further than OpenGL if you want to learn C++. OpenGL is great, don't get me wrong, but it is just an API, and a fairly limited one at that. You won't learn much C++ trying to figure out how to set up texture contexts and binding VBOs.

I would recommend writing a raytracer or your down software-based rasterizing renderer (or both!) - you'll find youself diving right into the data structures that are important to graphics and tackling 'fundamental' problems that really test your programming abilities, versus realizing that you passed GL_LINE to glBegin() instead of GL_LINES or some stupid API issue like that.

Later, you can work on your OpenGL skills; heck, you could even play with it in Python if you're curious. You'll find that any API is easier and more satisfying to use if you say 'How does this API address the following problem in graphics?' as opposed to browsing through the API reference and saying 'Ooh, what does this function do?'.

As for the Linux part, my advice would be to read up on Makefiles and spend some time writing them for various projects. When you've really got a handle on them, you can move on to CMake or autotools or whatever - but jumping into those without knowing that basic mechanism does you a disservice. I'd also recommend experimenting with one of those fancy programming editor (I recommend The One With All of the Modifier Keys), but there are several that are very good.

Good luck!
njord

Those look like regular acoustic waves to me.

I don't doubt the the rocket can go faster than the speed of sound (which gets lower as you get further from the surface), but those waves distinctly lead the rocket's motion, which means that they are the product of acoustic perturbations moving at the speed of sound in the medium.

If the rocket were moving faster than the speed of sound in that medium, then we would see the usual 'shock cone', where those waves would appear an a fairly narrow cone around the rocket as it passed though - certainly not before.

I qualify 'medium' since it is possible that the rocket is moving faster than the speed of sound (in the air) but not faster than the medium that the sundog constitutes. Liquids, for example, have much higher speed-of-sounds and it is (conceptually, not physically) fairly simple for something to be moving faster than the speed of sound in air at sea level but not be anywhere close to the speed of sound in a liquid that it is travelling - and thus producing the regular u-c, u+c acoustic waves.

However, as I understand them, sundogs are collections of ice crystals and probably don't have a higher speed of sound than the air around them. But anyway, waves preceding the motion of a body in a medium are certainly not shockwaves - if we could visualize the waves any object makes in the air, you would see acoustic waves arising from the object's motion before and after it.

Still neat-looking, though.

I don't see the problem; it seems like you should be able to easily beat the Prof. at writing equations with a (good) text editor you know well and LaTeX.

With the AUCTeX mode for Emacs, you get lots of shortcuts (like 'electric' backslashes and quick commands for environments) plus in-buffer previews.

Add in judicious copy+paste and you should be able to run circles around most professors writing on a blackboard and have plenty of time to read slashdot comments. If they are using an overhead or powerpoint, it might be a little trickier, but hopefully they are handing out notes.