I do remember struggling with compiler bugs - in particular the C++ compiler we were using on OS/2 way back in the day suffered a few - but I was primarily a machine-code programmer in those days so an inspection of the compiled object code would tell me what was wrong pretty quickly; plus the compiler guys (I think it was Watford) were very responsive and would usually fix things up pretty quickly.
So no, the bugs that have most challenged me have always been concurrency-related - deadlocks, race conditions and the like. My earliest experience of this was probably on the Atari ST. I was coding a game in 68000 assembler, one of the early 3D-rendered golf games. Whilst the golfer (a sprite) was taking his swing I needed to pre-render the first 3D frame, so hooked up a hardware interrupt to run the renderer whilst the golfer animation took place (or maybe it was the other way around; doesn't matter). Anyway it all worked nicely except, just occasionally, a rogue red pixel would appear in a random part of the screen. It took me about a month to figure out that there was one variable/memory location being read and written by both bits of code, with no mutex round it.
I guess it was good to learn a hard lesson about concurrency early in my programming career.
I've only skimmed the article, but I didn't see any mention of hash salting. Is the author assuming that the password hashes haven't been salted, or the salt has been recovered along with the raw password database, or am I misunderstanding completely and salting doesn't play a part here? Salting of password hashes has to be standard practice now, surely.
I love reading this stuff. I remember, back in the days of Amigas and Atari STs where I cut my 3D-programming teeth, it was a struggle simply to render each pixel of the frame buffer once, even at a juddery 10fps. Shadow maps! Bloom effects! Even the supercomputers couldn't do this stuff in my day, or would take hours of rendering time. A little bit sad that I left this world just as computer power started to make it interesting. Mind you, I think the most impressive 3D game of all time, in terms of getting the maximum from the minimum hardware, is still Revs for the BBC Micro. How Geoff managed to get that little old machine to render solid 3D I do not know.
Slashdot Mirror
Seconded. Nothing else comes close, does it?
Brazil. The greatest dystopia ever filmed. Also - that poster!
I do remember struggling with compiler bugs - in particular the C++ compiler we were using on OS/2 way back in the day suffered a few - but I was primarily a machine-code programmer in those days so an inspection of the compiled object code would tell me what was wrong pretty quickly; plus the compiler guys (I think it was Watford) were very responsive and would usually fix things up pretty quickly. So no, the bugs that have most challenged me have always been concurrency-related - deadlocks, race conditions and the like. My earliest experience of this was probably on the Atari ST. I was coding a game in 68000 assembler, one of the early 3D-rendered golf games. Whilst the golfer (a sprite) was taking his swing I needed to pre-render the first 3D frame, so hooked up a hardware interrupt to run the renderer whilst the golfer animation took place (or maybe it was the other way around; doesn't matter). Anyway it all worked nicely except, just occasionally, a rogue red pixel would appear in a random part of the screen. It took me about a month to figure out that there was one variable/memory location being read and written by both bits of code, with no mutex round it. I guess it was good to learn a hard lesson about concurrency early in my programming career.
No, I think this attack is predicated on having already stolen the password database.
I've only skimmed the article, but I didn't see any mention of hash salting. Is the author assuming that the password hashes haven't been salted, or the salt has been recovered along with the raw password database, or am I misunderstanding completely and salting doesn't play a part here? Salting of password hashes has to be standard practice now, surely.
I love reading this stuff. I remember, back in the days of Amigas and Atari STs where I cut my 3D-programming teeth, it was a struggle simply to render each pixel of the frame buffer once, even at a juddery 10fps. Shadow maps! Bloom effects! Even the supercomputers couldn't do this stuff in my day, or would take hours of rendering time. A little bit sad that I left this world just as computer power started to make it interesting. Mind you, I think the most impressive 3D game of all time, in terms of getting the maximum from the minimum hardware, is still Revs for the BBC Micro. How Geoff managed to get that little old machine to render solid 3D I do not know.