If you've got an ATI card you might try looking at the GroovyMame build, paired with some modified ATI drivers you can have around 200 native resolutions with dynamically generated modelines for essentially 100% native refresh rates/resolutions on most games.

http://arcade.groovy.org/

The way things work on consoles is approximately similar to Windows/Linux/Mac, except for these important distinctions:
1. the hardware is a known target, as such the shader compilers and other components are carefully optimized only for this hardware, they do not produce intermediate bytecode formats or make basic assumptions of all hardware.
2. the APIs allow injecting raw command buffers, which means that you do not have to use the API to deliver geometry in any way shape or form, the overhead goes away but the burden of producing a good command buffer falls on the application when they use these direct-to-hardware API calls.
3. the APIs have much lower overhead as they are not a middle-man on the way to the hardware, but an API implemented (if not designed) specifically for the hardware. For example Microsoft had the legendary Michael Abrash working on their console drivers.
4. the hardware memory layout and access bandwidth is known to the developers, and certain optimization techniques become possible, for example rendering to a framebuffer in system memory for software processing (on Xbox 360 this is done for certain effects, on PS3 it is heavily utilized for deferred shading, motion blur and other techniques that run faster on the Cell SPE units), in some cases this has other special implications, like storage of sound effects in video memory on PS3 because the Cell SPE units have a separate memory path to video memory and thus can tap into this otherwise "unused" bandwidth for their purposes of sound mixing.
5. 3D stereo rendering is basic functionality on consoles.

The article is making the argument that we should be able to produce command buffers directly and insert them into the rendering stream (akin to OpenGL display-lists but new ones produced every frame instead of statically stored).

It is also making the argument that we should have explicit control over where our buffers are stored in memory (for instance rendering to system memory for software analysis techniques, like id Software Megatexture technology, which analyzes each frame which parts of the virtual texture need to be loaded).

There are more subtle aspects, such as knowing the exact hardware capabilities and designing for them, which are less of a "No API!" argument and more of a case of "Please optimize specifically for our cards!", which is a tough sell in the game industry.

AMD has already published much of the information that studios will need to make use of such functionality, for example the Radeon HD 6000 series shader microcode reference manual is public already.

Intel also has a track record of hardware specifications being public.

However NVIDIA is likely to require a non-disclosure agreement with each studio to unlock this kind of functionality, which prevents open discussion of techniques specific to their hardware.

Overall this may give AMD and Intel a substantial edge in the PC hardware market - because open discussion of graphics techniques is the backbone of the game industry.

On the fifth point it is worth noting that NVIDIA Geforce drivers offer stereo rendering in Direct3D but not OpenGL (despite it having a stereo rendering API from the beginning), they reserve this feature only for their Quadro series cards for purely marketing reasons, and this restriction prevents use of stereo rendering in many OpenGL-based indie games, another case of consoles besting PC in functionality for ridiculous reasons.

Not even that.

The Dalvik VM doesn't accept Java VM bytecode. The Java language is what all the tools work on currently for creating executable images for the VM, and precompiled class files are also converted. If someone were so inclined, Dalvik could use lisp or c or befunge in much the same way that other languages have been compiled to work on the Java VM.

That's just it though, Oracle wants to be able to collect a fee. There isn't one now, but if Oracle wins then they could demand a fee for use of Android.

At the risk of spoiling everyone's funhey're md5 hashes of numbers.

md5("1") -> c4ca4238a0b923820dcc509a6f75849b
md5("2") -> c81e728d9d4c2f636f067f89cc14862c
md5("3") -> eccbc87e4b5ce2fe28308fd9f2a7baf3

I'm always looking for good drone and ambient. So agreed; make a torrent, link us.

The Android OS doesn't. Your carrier usually does. AT&T only "allows" tethering on their system if you pay for it. If they catch you doing it they'll just add it to your account and backbill you for how long they think you've been doing it. Verizon is the same way (with their Blackberries, anyway).

Ah, but who trolls the fair trolls?

When I was in high school we were required to wear our id badges on lanyards around our necks. The lanyard was small plastic tubing with a break in it "for safety". My sister and I were not particularly interested in wearing it, and began just clipping the badges to our shirts. Still clearly visible, just not on the lanyard.

Instantly, a shit storm erupted. Detentions and a suspension for insubordination and for failure to follow school policy (and for destruction of school property when we told them we'd thrown the plastic lanyard away).

Our father went to see the principal; he was told that the lanyards had "a safety release" to prevent choking and that we should feel safe. My father offered to demonstrate how holding on to the lanyard's "safety release" would allow someone to successfully choke a person wearing the lanyard. The principal declined (sadly), and back pedalled on his original stance. If we wore the badges "visibly" and carried our "excuse notes" for the lanyard, we would be excluded from the policy.

Ironically, within two weeks, a student was strangled during a fight with another student using the plastic lanyard from their id badge.

Just like the Spanish Inquisition?