That's a large part of the answer right there! The magnetosphere acts as a shield to keep a lot of harmful particles from the solar wind away, things which would work to strip away the atmosphere. Mars is an example of what can happen to planets that lack this. (Obviously, Mars' lower gravity works against it in this regard as well)

http://science.nasa.gov/science-news/science-at-nasa/2001/ast31jan_1/

I don't understand why those things wouldn't be useful and relevant if our goal is to discuss the costs of development, and not to just cherrypick numbers here and there.

And if you don't ignore development costs, that $99 becomes trivial; less than a rounding error. It's less than the cost of a padded office chair from Staples that your developer is probably sitting on... or the sneakers she's wearing, if it's a standing desk.

That argument is not flimsy for professionals that have "a decent amount of technical knowledge" but value their time. I have assembled, tweaked, and overclocked many PCs but for the last few years I've grown to prefer Macs more and more.

The "Apple premium" is pretty affordable when you compare it to the cost of several days of downtime over the course of 3 years of computer ownership, and it shrinks even further when you consider that Macs fetch a premium price on the used market and you are able to recoup some of the "Apple premium" when it's time to sell.

Yer mum's pretty nice, mate. Winkwink nudgenudge.

I like how this guy thinks it's a conspiracy or something. You're right, man. SSDs aren't faster or anything. What were we thinking?

The major problem with Rails is that it's tied to Ruby. Historically, Ruby's interpreters have not exactly been speed demons.

Non-rhetorical question: when you write web applications, do you ever do anything performance-intensive in the framework/application layer?

I don't know about you, but in my experience with small/medium sites, the execution time of the ASP.NET/Ruby/whatever code is absolutely dwarfed by the execution time of the database calls.

Usually, all the framework/application layer is really doing for each page request is grabbing some data from the database and spitting out some markup. It's not rocket science, and no matter how slow my framework is (including like, VBscript-powered ASP "classic" ...yuck) I've never found it to be a performance bottleneck.

I am sure that there are web applications where perhaps it would come into play. Sites that do heavy manipulation of images or other media types in the application layer are obvious candidates. I am sure there are others.

That's a legitimate concern, though there are good reasons that performance of the runtime isn't the overwhelming concern when choosing a platform for a project, but the speed with which something can be developed, tested, and deployed is more critical, and the Ruby ecosystem and Rails have features that lots of people find attractive in that direction.

This is absolutely true. Developer time is in shorter supply than CPU cycles. Additionally, in most web applications, it's the data storage layer that's doing the heavy lifting anyway. In my experience with small/medium sites, about 90-95% of the time it takes to generate a response is tied up just waiting for database calls to complete. If a page takes 50ms to generate I'm usually looking at about 5ms spent in the framework and 45ms in the database.

I don't think that's accurate at all. Typically, your choice of web framework/language is never even close to being your performance bottleneck anyway - it's the data storage layer that's doing all of the heavy lifting. MySql isn't any faster or slower whether you're calling it from Ruby, C#, COBOL, or hand-tuned machine language.

When I say "typically," I realize that's a nebulous term and that there's no "average" web application. What I'm thinking of as typical is a small/medium server that's serving up to several million page views a month, several database calls per page view, with a database perhaps 50MB-10GB in size.

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.