Grammerjack

A very thorough talk describing the Nintendo Wii game console security model and the bugs and weaknesses that allowed the Wii to be compromised: Console Hacking 2008: Wii Fail In a nutshell, security is provided by an embedded ARM CPU that sits between the CPU and the IO devices, and handles all the IO. The two main flaws were (a) A bug in the code that compared security keys, such that it was possible to forge security keys, and (b) secret break-once-run-everywere information was stored un-encrypted in RAM, where it could be extracted using hardware modifications. There's a nice table at the end of the presentation showing a number of recent consumer devices, what their security model was, and how long it took to break them. The PS3 is the only console that's currently unbroken. The PS3's security model seems similar to the Xbox 360, but somewhat weaker. But it remains unbroken. This seems to due to the existence of an official PS3 Linux port, which means most Linux kernel...

...as seen on the Beyond3D GPGPU forum , here are the presentations from the recent (December 12th 2008) "Beyond Programmable Shading" course: SIGGRAPH Asia 2008: Parallel Computing for Graphics: Beyond Programmable Shading There are good presentations from both GPU vendors and academics. My favorite presentations are the Intel ones on Larrabee, just because I'm so interested in that architecture: Parallel Programming on Larrabee - describes the Larrabee fiber/task programming model. Next-Generation Graphics on Larrabee - how Larrabee's standard renderer is structured, and how it can be extended / modified. IBM / Sony missed a bet by not presenting here. That's too bad, because Cell sits between the ATI / NVIDIA parts and Larrabee in terms of programmability. And Cell's been available for long enough that there should be a number of interesting results to report. Note to self: consider buying a PS3 and learning Cell programming, just to get ready for Larrabe...

This weekend I reorganize my home source code projects. I have a number of machines, and over the years each one had accumulated several small source-code projects. (Python scripts, toy games, things like that.) I wanted to put these projects under source code control. I also wanted to make sure they were backed-up. Most of these little projects are not ready to be published, so I didn't want to use one of the many web-based systems for source-code management. After some research, I decided to use replicated git repositories. I created a remote git repository on an Internet-facing machine, and then created local git repositories on each of my development machines. Now I can use git push and git pull to keep the repositories synchronized. I use git's built-in ssh transport, so the only thing I had to do on the Internet-facing-machine was make sure that the git executables were in the non-interactive-ssh-shell's path. (Which I did by adding them in my .bashrc file.) Git's...