I'll believe their claims when I see some test results they can back it up with.

Not exactly what you asked for but snes-sdk is a tinycc-based C compiler and SDK for the SNES. Pretty cool if you want to write your own games and don't want t write everything in assembly.

http://code.google.com/p/snes-sdk/

I don't know who got what first but as you said, Debian has this too.

Same as Debian, you have a [package-source].orig.tar.gz, [package-description].dsc and [debian-specific-patches].diff.gz.

You can do unattended installs or updates in debian with

DEBIAN_FRONTEND=noninteractive apt-get -q -y dist-upgrade

I think it's pretty safe to assume that the systems are equivalent nowadays.

The difference is that the raspberry pi is/will be immensely popular. There will be a huge community supplying software solutions and hardware modifications for it. It doesn't matter that some random china-device has twice the power and a touchscreen when you're stuck on Android 2.1, closed kernel, and no updates in sight.

It's the people that matter, not so much the hardware.

But... They tested with 10 games, 1 raytracer and 0 synthetic benchmarks. I don't know what they usually do but this article was very focused on real world performance.

I can't find any reference in the article, but from the formulation in the summary it sounds like the IT department set up new accounts to have the 12345-password as default (without expiration), and then asked the users to change the password.

If that's the case it sounds like a terrible idea to me. Better to generate default-passwords as complex random strings. Then it'll be in the users' interest to change their passwords because they're hard to remember and type. And if they don't, even better!

That's a weird point. It's not like you need to know what a single of those things mean to use an Eee Pad. Just like you don't have to know what iOS 4.3.5, Apple A5, PowerVR SGX543MP2, NEON SIMD, Objective C, jail breaking or capacities touchscreen is to use an iPad.

My experience with closed source linux drivers is that they're usually very poorly integrated with the rest of the system. The companies usually like to solve everything their own way (tm), rather than using the frameworks all the open drivers use.

When AMD dropped their support in fglrx for my radeon x1300-based GPU in my laptop (yes, they drop support for hardware whenever they feel like it) I had to start using the radeon driver on my ubuntu-machine. Everything has worked much better in the system since the switch. Suddenly I don't get some special AMD catalyst control center-thingie to change resolutions and set up external monitors etc. Instead the normal standardized gnome settings work like a charm. Also the system sets the correct resolution for my screen once, right after the kernel has been loaded (ie. before gdm/X).

If the radeon driver from TFA gets included in ubuntu 11.10 I would definitely give it a shot for my desktop machine, which has a Radeon HD 6870 card. The fglrx support for this card is just terrible. Sure, performance wise the OpenGL works well in games, but the normal X11 2D acceleration is terrible. Here are some annoyances with it:

    * Whenever gksudo is activated it throws random garbage on all my monitors for about a second before displaying the password dialog
    * Random "holes" in windows at random times, ie. squares where the desktop background suddenly becomes visible instead of the window contents. This won't go away until the window is redrawn.
    * OpenGL and XV surfaces are always on top. So if I watch a video and put some window on top of the video surface, the video will be in front of the window regardless of Z-order.

If I could get a driver that plays nice with the rest of the OS, gets regular updates with the rest of the system, and doesn't have weird bugs in its 2D rendering I would gladly sacrifice 50% OpenGL performance. It's not like I utilize the GPU that much anyway.

While I agree with you regarding application programming, need, etc. I must clarify that I was talking about graphics/game applications that require the full hardware potential.

If you compare this new architecture with an arguably over complicated architecture like the playstation 3 I'd argue that writing software that utilizes the hardware to its full potential is indeed hard. And in this context, making a more elegant, integrated GPU/CPU will make the lives of us poor indie game programmers a bit easier.

Integrating CPU, GPU and unifying the memory address space will probably make things easier for programmers. So hopefully it'll help programmers utilize the hardware better.

The "duh" in the population are those who believe that "duh" science is "duh" though. More often than not the outcome of a study is the expected results. When it's not, however, it challenges our preconceptions and we have to adjust to the new facts (or do another study ;).

Just because our intention tells us that something works a certain way it doesn't mean we can accept this as a scientific fact. This is a strength of the scientific method, rather than a weakness.

if you're building spacecraft in orbit, I guess it would be nice to mine most of the raw materials in space.

Just release what you legally can. If someone is interested they can replace the floating point parts.

In the DOS game stunts the car breaks down with the message "You forgot to disable the security system" if the copy protection check fails.

One of my favorites though is the game Operation Flashpoint where, if the copy protection fails, the game starts slowly fading to black. Eventually, when the screen is almost dark, the message "Real games don't fade" appears on the screen.

Aww, came here to say this :)