Resistance is futile. You will be simulated. was the text printed (using a Star Trek font) on a limited number of t-shirts we had printed when I worked at Virtutech. The simulator is called Simics, and is a full-system simulator capable of simulator entire computer systems with sufficient fidelity that the simulated software is not aware that it is being simulated.
Raymond Chen recently posted an entry on his excellent The Old New Thing blog, titled If you can detect the difference between an emulator and the real thing, then the emulator has failed. This made remember a fun challenge once held at a party at Virtutech after I had left the company (I don't remember the occasion). There were two black screens displaying a Linux command prompt. One of the screens was connected to a physical PowerPC board, and the other was connected to a simulated PowerPC board. The task was then to decide, using the only the command lines of the two machines, which machine was simulated and which one was not.
Doing "cat /proc/cpuinfo" only revealed that both systems where running on PowerPC hardware (the output was different, but then only the people setting up the challenge new exactly which PowerPC hardware was being used), and the simulation was fast enough to not reveal anything performance wise. Now, I happened to have some insider info allowing me to solve the problem: Simics does not (or did not then) have any USB-support, which meant that the "lsusb" command should provide some crucial hints. Quite correctly, the simulated machine did not have any USB-devices, while the real hardware had a number of USB-related devices. I'm not sure if I won the challenge or not, but I remember a bunch of people standing around the terminal discussing different ways of beating the system.
Computers, technology, games. And other ramblings. And sometimes in Swedish.
Wednesday, May 19, 2010
Sunday, May 16, 2010
Egit
I have a hobby programming project I work on from time to time. The goal is to implement a JVM (or something resembling one). It will most certainly never be completed, but it is fun to work on it.
One thing I've used it for is to learn and experiment with git in a way were I don't risk breaking things for other people.
Git's command line interface is as impressive as they come, but since I've used Eclipse CDT for writing the code, I wanted to try Egit. Also, since git is on it's way to replace cvs at Eclipse, I thought it would good to know.
The general impression about Egit is that it is pretty solid, but a few areas needs polishing, for example, there's no easy equivalent to "git pull". The "fetch from" command gives me a big dialog with no sensible defaults. A lot of thought has been put into the command line interface, and creating a GUI with the same expressiveness is not done overnight.
- Posted using BlogPress from my iPhone
One thing I've used it for is to learn and experiment with git in a way were I don't risk breaking things for other people.
Git's command line interface is as impressive as they come, but since I've used Eclipse CDT for writing the code, I wanted to try Egit. Also, since git is on it's way to replace cvs at Eclipse, I thought it would good to know.
The general impression about Egit is that it is pretty solid, but a few areas needs polishing, for example, there's no easy equivalent to "git pull". The "fetch from" command gives me a big dialog with no sensible defaults. A lot of thought has been put into the command line interface, and creating a GUI with the same expressiveness is not done overnight.
- Posted using BlogPress from my iPhone
Subscribe to:
Posts (Atom)