Where we went wrong – a post by Charles Stross about the decisions and strokes of luck of (recent) history that have landed us in a world where ‘computer crime costs US businesses $67 billion a year’.
Now, not all applications (or, more precisely, important operations of an application) are amenable to parallelization. True, some problems, such as compilation, are almost ideally parallelizable. But others aren’t; the usual counterexample here is that just because it takes one woman nine months to produce a baby doesn’t imply that nine women could produce one baby in one month. You’ve probably come across that analogy before. But did you notice the problem with leaving the analogy at that? Here’s the trick question to ask the next person who uses it on you: Can you conclude from this that the Human Baby Problem is inherently not amenable to parallelization? Usually people relating this analogy err in quickly concluding that it demonstrates an inherently nonparallel problem, but that’s actually not necessarily correct at all. It is indeed an inherently nonparallel problem if the goal is to produce one child. It is actually an ideally parallelizable problem if the goal is to produce many children! Knowing the real goals can make all the difference.
Richard Feynman, talking about speeding up calculations during the Manhattan Project:
A rather clever fellow by the name of Stanley Frankle realized that it could be done on IBM machines. The IBM company had machines for business purposes, adding machines that are called tabulators for listings sums and a multiplier, just a machine, a big box, you put cards in it and it would take two numbers from a card and multiple it and print it on a card. And then there were collators and sorters and so on. So he decided, he’d figured out a nice program. If we got enough of these machines in a room, we would take the cards and put them through a cycle…
We had done things like this on adding machines. Usually you go one step across yourself, doing everything. But this was different—where you go first to the adder, then we go to the multiplier, then you go to the adder, and so on. So he designed this thing and ordered a machine from the IBM company… but it was delayed, always delayed… we worked out all the numerical steps we were supposed to do, that the machines were supposed to do, multiply this, and then do this, and subtract that. And then we worked out the program, but we didn’t have any machine to test it on. So what we did, I arranged, was a room with girls in it, each one had a Marchant [a desktop mechanical calculator]. But she was the multiplier and she was the adder, and this one cubed, and so we had cards, index cards, and all she did was cube this number and send it to the next one. She was imitating the multiplier, the next one was imitating the adder; we went through our cycle, and we got all the bugs out. Well, we did it that way.
Taken from his talk, “Los Alamos from Below”, as reproduced in the book The Pleasure of Finding Things Out.
Q: How do you close applications when multitasking?
A: (Scott Forstall) You don’t have to. The user just uses things and doesn’t ever have to worry about it.
A: (Steve Jobs) It’s like we said on the iPad, if you see a stylus, they blew it. In multitasking, if you see a task manager… they blew it. Users shouldn’t ever have to think about it.
from the Q & A session after the recent iPhone OS 4 event, as reported by Engadget
So what’s this, then?
Your interface needs a ‘Home’ button.
(screenshot from MacWorld’s preview of Microsoft Office for Mac 2011)
“Seven Reasons why Fireworks Works for Screen Design” — and, in particular, why it’s better than Photoshop or (heaven help you) Illustrator for this task.
I link to this mainly because it confirms my own internal reasons for preferring Fireworks, and thus makes me feel like less of a kook when people say, “Fire-what?”