How bout limiting the bandwidth between residentially leased subnets, and only offering full bandwidth to legitimate commercially owned networks? That would go a long way toward preventing piracy the way it is implemented these days (e.g. Bit Torrent, and other p2p protocols).

I was all excited to see what a VoIP program that distinguishes itself as being "free of GNU" really meant. Come to find out, it is just a GNU project with a terrible name.

What CS students need an education in more than anything is Discrete math (graph theory, set theory, number theory, etc...). Calculus is the complete opposite end of the spectrum. While Calculus can be useful, it should take a backseat to discrete math.

I do not know how you got all that from the article... he clearly states that he has no intention of switching APIs.

More or less, all he stated was that Direct3D has been driving the evolution of commodity real-time computer graphics hardware for the better part of a decade now. It is a very attractive API if you can limit yourself to a single platform, and deserves respect. This contrasts his (and virtually everyone elses) views on Direct3D from 15 years ago, when the API was a horrible mess. Direct3D was playing catch-up back then, but the situation has been reversed for a very long time.

The last truly amazing thing I saw (for its time) come out of the OpenGL development pipeline, that could have driven the development of the next generation of GPUs, was ATI's proposal for Uber/superbuffers. Said extension was shot down, and by now the functionality is easily accomplished using a myriad of other extensions. The fact is, Direct3D is the driving force behind what features a new class of hardware will support, and to claim otherwise would be truly foolish. This in no way implies that OpenGL cannot or will not utilize the new functionality, only that Direct3D evolves more quickly.

I completely agree with Carmack, but as Tim Sweeney has stated we are gradually moving to a point where the graphics API is irrelevant. As time goes on, more and more of the GPU is exposed to programability and with each release of DirectX and OpenGL (to a lesser extent), the fixed-function pipeline is shrinking. If the trend continues, we will eventually get to the point where everything is abstracted into programs that run on a GPU and buffers... even state management will become a task managed completely by the engine.

If you work on cross-platform console engines, chances are you already wrap the state machine into irrelevance to make up for differences between APIs. Multi-threading is simpler in DirectX, but that is to be expected from an API whose design only requires it to work on a single platform. If you code close to the metal, of course you will see benefits for a specific combination of API / hardware.

OpenGL has traditionally been a monolithic API that tries to maintain legacy support, while accommodating new hardware through extensions. It has a lot of baggage that DirectX does not have, since DirectX routinely drops legacy portions of its API with each major release. Even so, OpenGL comes in multiple flavors now, with the embedded API being much closer to the feature-set modern commodity hardware offers.

Performance wise, Direct3D has held the crown for many years. Portability wise, OpenGL has always been the king. I do not see this changing anytime soon, the two APIs tackle real-time computer graphics from two very different angles. I, like many engine developers, do not have the luxury of committing to a single API, so it is very difficult to effectively exploit the theoretical advantages of either API.

Would it not make more sense to use a form of ROM, rather than block-erasable EPROM (Flash)? Honestly, how often do you need to rewrite the contents of an entire game?

The real question is how will they be distributing games to the system? If it is, as some have speculated, download-only, I will skip this platform altogether.

If it uses optical storage exclusively, the battery life and load times will likely be even worse than the PSP. What would be nice is if they actually made use of "Magic Gate" to allow optical games to be installed to compliant MemoryStick for better load times and battery life (given of course that the optical disc is present); probably will not happen, but would be nice.

The paper refers to none of these parts of an Operating System, however. You can safely assume that anytime the paper mentions "Operating System," it is talking about the kernel. User-land components have almost nothing to do with _how_ the kernel deals with resource allocation, aside from requesting a subset of the resources.

And there are plenty of Linux-based Operating Systems that do not use GNU, for your information. Embedded devices being the king.