Everything in Australia is more expensive. Even your cheapest supermarkets charge 2-3x the prices of American supermarkets. The only thing you have going for you is a significantly higher minimum wage (for adults, anyway - you tend to screw teenagers).

Of course you didn't - nobody pays future inflation-adjusted prices 20 years in advance unless they are completely insane!

For many years now I have been very disappointed by stagnation, and down-right reversal in DPI trends. 13 years ago I was running a 19" CRT at 2048x1536, now to find a computer display with similar DPI is very difficult; to find a CRT is even more so, despite the venerable technology's superiority in virtually all image quality metrics.

TVs continue to get larger and larger, while 1080p is likely to remain the standard by which they are all measured for several years to come, and penetration of media with a native resolution > 1080 will take even longer. So there is little incentive for mass produced panels (e.g. TVs, and even computer monitors) to improve on DPI; I am glad however, that the emerging mobile device market is not shackling itself to the same philosophy.

Viva la DPI!

TiVo would be obsolete if it publicly allowed modification of its software, because Cable Labs would withdraw TiVo's permission to transfer recordings in any capacity. And this capability is one of the reasons I will never use a cable company or IPTV's inferior DVR solution. The TiVo software is outdated (granted, I do not own a TiVo premiere, because without the OLED front display, I view it as a downgrade), but it still does what it does better than anything else on the market. I do not get why people rag on TiVo for this - all of my TVs all the way back to my 30" SONY Trinitron FD (circa 2004) run a Linux kernel, and none of them are modifiable either, yet nobody ever complains about that. I am sure SONY has sold more TVs running Linux than TiVo has subscribers, and SONY is not the only manufacturer to run Linux, so.... what gives?

I should maybe make that a bit clearer... throttle the bandwidth of a residential connection connecting to another residential host. Remove the throttling when the residential connection connects to a commercial host.

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.