I disagree. I am mostly paperless at work, and environment is not the main reason driving me to that. Paper is just *not* convenient. All the documents keep changing constantly, there's no point in printing them out. Where I work, you can't really leave all the paper lying around, either, for security reasons. Secure disposal of paper is a pain, too. One of the reference manuals is thousands of pages, who'd want to print that? You can't even search in the paper version.

Mostly I'd say it's about old habits that die hard.

Ah, I see that you're still on honeymoon with your N900. It's got its wrinkles. Try 'cat /etc/sudoers' for a start. But I do agree with most of what you say. It is an amazing device.

Tell me when you're done, and I'll run it on the TI-82 on my N900. ;)

Uh, why? My caps lock key is another ctrl, makes emacs use a bit friendlier for my left hand little finger. You could map the other keys to your liking as well. No need to break your keyboard.

Regarding TFA, it makes me wonder when they'll start removing other keys that are not useful for an average Windows/Office/Outlook user. A middle aged computer scientist using Emacs is becoming an endangered species I guess.

Really? "For years, Sony has argued that its video game consoles have 10-year lifecycles" says this interesting article, which mainly focuses on PS2's 9th birthday. Also, I don't see a big decline in sales in this console hardware sales chart (which, admittedly, might not be too accurate, but gives you a rough idea).

Frankly, I don't think we're nowhere near seeing what can be eventually squeezed out of PS3 or 360 or Wii. Remember the difference between early vs. later PS2 games?

And I don't realistically see what major upgrades in the main units would be beneficial for either the manufacturers or gamers in the near future, apart from cutting manufacturing costs and providing new kinds of controllers and accessories and online gaming modes. The current consoles will be with us for a long time, and they will sell huge numbers for years.

I'm afraid you can't really force this attitude on people by using coding standards etc. though. I think it's something every coder needs to figure out for themselves. Like Pragmatic Programmer says, "care about your craft".

On the N900 you could use Python and listen for the D-Bus messages related to phone calls.

Virtualize, but go one step further: get your virtual server hosted for you. For example Gandi is pretty sweet. I'm sure there must be similar services in the US. No more worries about that box running in the basement.

If you insist on having the hardware in your house, QNAP offers wonderful NAS boxes with Debian Lenny support.

Some heavyweight as well.

Can't be bothered to look it up in the MONDEX case, but usually only parts of the smart card operating systems are formally proven; it's too costly to cover the whole system. Often it can be (semi-)formally proven that certain security irrelevant parts do not affect the areas being evaluated. (There's a paper on the MONDEX certification for those interested.)

Also, from TFA:

Admittedly, smart card kernels can't be referred to as "smaller kernels" if what they have is 7500 lines.

A bit of snow on a cell tower. A bit more snow on trees.

Those scripts sound a lot like Gentoo Portage to me.

Another problem is that USB thumb drives present themselves as block devices, which flash is not. There's a flash translation layer, which on most devices optimizes flash usage for FAT. Due to limited erase/write cycles on flash, using file systems such as ext3 may severely limit the life time of the thumb drive, since the flash translation layer's wear leveling probably doesn't work well with non-FAT filesystems. The situation, I've let myself be told, is especially bad with journaling.

As long as the FTLs are optimized for FAT, I'd stick with it, wrinkles and all.

I don't think it's an exactly clever idea to be unnecessarily copying containers in the first place, but no matter what it makes Qt to STL migration hard if the Qt applications are filled with assumptions on copy-on-write.