SLC flash memory, which the article claims Braidwood will use, is an order of magnitude or two more durable (in terms of write cycles) than MLC flash memory, which is what is used in most consumer-level devices like Intel's X-25M SSDs.

Wear-leveling and overprovisioning should ensure a long life for the memory used in a scheme like Braidwood. Intel, generally speaking, knows what they're doing in this area. Now if only I could afford one of their drives...

You're both right.

The problem here is that "random I/O" can have at least two subtly different meanings. In the very old days they talked about random I/O as opposed to sequential (ie, tape) I/O. In that sense, yes, random I/O is often extremely cacheable, as you say. That's why virtual memory works, as system files, drivers, commonly-used applications, and so forth are accessed much more often than other daa.

"Random I/O" can also refer to I/O that does not follow any real pattern - ie, a 50GB database in which all records are accessed about equally as often. This kind of I/O is not really cacheable, practically speaking. Unless you can cache the entire thing.

What's the correct terminology for the second kind of random I/O? Random I/O with very low locality?

That was my initial reaction too. However, remember that most (not all, obviously) typical server tasks aren't particularly memory bandwidth-hungry. Email, web serving... even databases aren't usually coming anywhere close to saturating the bandwidth DDR2 can provide, even with several virtualized OSes sharing that bandwidth.

Right. There's (almost) no friction in space, so your craft isn't going to slow down just because it's no longer receiving enough power from the sun to accelerate. But after a certain point it won't receive enough solar power to power onboard navigation and communications systems. Those would likely be powered by a wee bit o' radioactive power like today's deep space probes.

How is this even remotely bizarre?

Without even getting into specific operating systems: if Operating System A and Operating System B do different things well, why would it possibly be bizarre to run them both?

When it comes to OSX and Linux, each runs a great deal of software that the other doesnt. Specifically: Cocoa, Carbon, KDE, and Gnome desktop applications.

Also, quite a few developers work with multiple operating systems. Since desktop OSX is simultaneously the most difficult OS (yes, because Apple has fought it) to virtualize and is generally regarded as providing the most pleasant desktop experience, a popular strategy among developers is to run OSX as their desktop OS and virtualize the rest.

Not very hard to understand, though it's also easy to avoid replying to trolls and that's what I just did.!

There is a real shortage of talented programmers out there. Most programmers are completely awful and write disgusting lumps of buggy spaghetti code, regardless of their age. Nobody in the market for a talented programmer -- nobody worth working for, anyway -- is going to turn a talented programmer away because they have a receding hairline.

Yes, there is mild ageism. It's not because people in the industry have some sort of innate hatred of people over 35; it's because older programmers tend to lack the geeky dedication and up-to-date skillsets of younger programmers, and tend to have higher pay requirements because of their families, mortgages, etc.

Tend. Tend.

Show yourself to be otherwise and you'll be on an even footing with the younger coders. And if you do carry those drawbacks, well, it's not really your age that's holding you back.

(Of course, there are enormous numbers of older programmers who defy that tendency and are superior programmers because of their experience, and enormous numbers of younger programmers who are absolutely total crap)

For whatever it's worth, I'll be 33 in a few months and the most talented programmer currently in my personal/professional circle is over 40.

Congratulations. You got the joke.

How is that any worse than traditional web development environments, where it's equally easy to a "select * from orders" ? It's so easy to forget a WHERE clause.

If anything, I think the presence of "all" in "Orders.all.each { |order| ... code goes here ... }" is much easier to spot than a missing SQL clause.

Not that that excuses any of Rails' other flaws that you pointed out.

I grew up on the early Sierra and Lucasarts adventure games, and even some text adventures, but even then - puzzles often felt forced and arbitrary.

"Oh, look -- another door in this dungeon is locked, but has a series of gem-shaped indentations in it! I can't wait to figure out the proper order of the gems! Hooray!"

The best puzzles were the ones integrated into the story, when Character A (whom we already care about, because of previous plot developments) needs Item B and I need to talk to Character C (whom we also already care about) and figure out that I need to use Item D with Item E at Location F to accomplish that goal.

But even then, those puzzles bordered on tedium that you simply had to endure in order to see the next bit of (often wonderfully-written) story.

It was downright schizophrenic: wonderful story, tedious puzzle, wonderful story, tedious puzzle, wonderful story, etc.