I tried it for a few minutes, and the Prius never suddenly accelerated. Clearly the simulation is flawed.

My take as a "young developer" isn't that the kernel is too complex or that I don't like developing for the kernel (although it certainly does have its issues) as that the drawbacks outweigh the benefits. I've written device drivers for some stuff I've got laying around as well as done some board support and bringup and the experience isn't any worse than one could expect from such a task. However, working on the *mainline* Linux kernel:

a) Doesn't get me paid.
b) Isn't "hip" - you don't see kernel developers speaking at media conferences or hanging out with celebrities, like you do "web 2.0 kids." The no-e-fame aspect is actually appealing for me but not for many of the people I've met.
c) Involves dealing with a lot of douchebags.
d) Involves wasting my time convincing an old-hands crowd self-assured of their relative place in the development world that my ideas have merit (also see c).

I "develop for the kernel" just fine, but I have no interest or desire in getting my patches to mainline - they benefit few people, Git makes it easy to track trunk while keeping my own code around, and I don't want to waste my time dealing with the douchebaggery and politics involved in reaching the mainline kernel.

This just doesn't make any sense. People who are using a social network are using a social network because they want to be found - because they want an easy way to keep in touch with a lot of people. Changing to a darknet model completely eliminates all these benefits. The only people who would buy such a device are people who shouldn't using online social networks anyway (making the import aspect odd).

Not only that, but there are actually two entirely different TI-Nspire models (Nspire and Nspire-CAS) that differ only in software (and cost).

So if it were to become possible to flash one firmware to the other, TI would both lose money and anger standardized testing organizations (most allow only the NSpire and not the CAS, and rely on the different labelling on the hardware to ensure students are using the approved unit).

DirectX is a forward-looking standard - Microsoft sits down (or stands up and yells) with developers and graphics manufacturers, and hammers out a spec which a "DirectX X.XX" card must support. Then vendors go and make a card and drivers that support those features. In this way every DirectX 10 or DirectX 11 card can be assumed to support the same things using the same APIs, and if they don't, it's the vendor's fault and they have recourse.

OpenGL, at this point, looks back - Graphics card manufacturers make a graphics card and then shoehorn its features into OpenGL. This way every single card has different supported OpenGL features implemented in different ways.

So sure, "OpenGL" gets some features first via extensions (it's debatable whether or not it's even OpenGL at that point, since the OpenGL standard doesn't even really play into it) - good luck using them, though.

The choice for game developers is pretty easy: support a lot of people (Windows and Xbox 360) using one consistent API, or support a few more people (Linux mostly, with some additional work required for PS3 or Wii) at a huge cost (debugging across vendors, platforms, and consoles).

It took the US government to end enforced landline phone rentals and open up the analog telephone network in 13 F.C.C.2d 420.

With today's moves towards "deregulation" I don't think we'll see the cell industry being forced to do anything similar in the near future.

Another funny point is if you were to disassemble PhysX's "GPU acceleration," you'd find that it runs very few kernels on the GPU, and that they're quite simple. What you'd also find is that there are two CPU codepaths: a non-optimized CPU codepath, and an optimized CPU codepath. The optimized CPU codepath is only taken when using the nVidia "GPU" code (which really hardly uses the GPU) - the performance improvement gained from "using the GPU" is really gained from using a non-gimped codepath!

"Standard HTML" is sort of an oxymoron.

Yes, you can do a lot of what's done on the web in "standard" HTML - but then you have to wrangle it into every "standard" browser, which turns out to be subtly different and full of bugs compared to the next.

It's not even possible to point the finger straight at Microsoft any more - Firefox has its fair share of bugs and an awful lot of non-standard DOM extensions, and every browser disables and enables a certain feature which the next supports. Support is even added and removed in certain browser sub-patchlevels and revisions - for example Safari suddenly started supporting certain DOM load events in a random security patch due to a merge of upstream WebKit.

Flash provides a common platform on which layout, interpretation, and feature support is similar (nearly identical) across all browsers on most platforms, something no other web programming solution can do.

Unfortunately that common platform isn't very good, but the homogeneity it allows is the continuing, and probably lasting appeal.

Many old datacenters have a pond and a fountain out front - and the pond isn't just to be pretty. They run the water into the fountain, and its trip thru the air cools it as it heads back into the pond.

Throwing in a shameless plug for a game I worked on - Powder Toy ( http://powder.unaligned.org/ ) - it may not be physically accurate (at all) but it's a lot of fun and would introduce them to pressure and velocity in a fun way.

Uhh... that's assuming the feds can't reverse-engineer worth a crap when they want to get a conviction. Seeing as how I know feds who can, this is wrong.

Once they've siezed the laptop (which I guess they've decided they can do now), they can do whatever they want with the drive image, including disassembling whatever boot code you had "hiding" your "hidden" partition. You need something that only -you- know, that's in your head, somewhere they can't yet reverse-engineer legally - we generally call this thing a password.