Why would you prefer a model where you pay $60 per year and you have a decide on a click-by-click basis if you want to spend the money over a model where you pay $50 per year and can read whatever you want on a whim?

On days when I visit the NYT I probably click on twenty articles. Most of them I "read" for about 5 seconds. A few merit more attention and a I read them more completely. I like this freedom to skim. A pay-per-click system would make that cost prohibitive.

I think the future model is going to be a small number of iTunes-style markets for media content that are (somewhat) independent from the media providers. You go to one place to spend your money and manage your purchases (eBooks, mp3s) and your subscriptions (NYT, Pandora, Hulu) and you get one account that lets you access multiple sources from your eReader, your browser, your phone, etc. This system has already begun and will mature quite a bit at the end of this month when Apple announces their iPad. Within a few years several such markets will spring up and then consolidate down to 3-5 major "networks". This model will be both better and worse for consumers, but publishers will get paid so it will stick around.

On the other hand, they have this rule.

Are you kidding? The man released Justin Bieber into a mall. Has a more dangerous animal ever been released into a more governmental structure?

Is that the point of Chrome OS? I had the impression that it was targeted at small, portable, communications devices--somewhere at the intersection of smart phones and netbooks. There are many kinds of applications that just won't ever run in the cloud, and we'll always need powerful desktop-ish machines with full-featured OSes

What I'm more confused about is why they need both Chrome OS and Android.

You're forgetting about an important part (my part) of the Slashdot demographic. Let's call it the "I've been out of college for a decade or two and have a had a bunch of jobs in that time because that's just how it works" demographic.

The authors at least partly agree with you. They describe the absence of exceptions here. They consider it to be an open issue.

On the other hand, they already provide an alternative to the "finally" block of an exception handler: the defer keyword. I like the looks of this, as it means you can handle all of your closing and locking kinds of issues in a direct pairing with the corresponding open or lock, regardless of whether the function terminates early due to error conditions.

For certain values of "we"...

I'm rather fond of my skull, but I do agree that it doesn't belong on clothing.

Not geeky enough. We should be arguing for an extension to the HTML standard allowing a number to be tagged as a distance and assigned a unit, thereby allowing the browser to convert automatically to the units preferred by the reader.