Let's do it again. The last set of CFLs I bought cost 50p each (the ones before that were 30p, but that was a special offer). According to my electricity bill, I pay a tiny fraction of a penny under 15p/kWh. That means that the bulb costs slightly more than 3kWh of electricity. It's a 15W bulb replacing a 60W one, so that's a 45W saving. Assuming that the incandescent is free, then it takes 75 hours of operation for it to save money. At 3 hours a day, that's 25 days. When I first did the arithmetic, the CFLs were 3-4 times more expensive, so it worked out at 3 months.

This is why I find the resistance to CFLs so hard to understand. It's saved me quite a bit of money over the last decade.

When I did the arithmetic quite a few years ago, the break even point for CFLs was about 3 months. The bulbs I bought back then all lasted 6+ years. The cost of a CFL is around the cost of 3-10kWh, depending on the brand, so even if they incandescents were free you don't need the CFLs to last very long to break even.

Sounds like something's wrong with your wiring. I switched to using CFLs over a decade ago and the shortest lifetime I've had on one is 6 years (I think - one might have gone after 4). The first time I moved house, I brought a load with me, but they'd become so cheap that I didn't bother the last time. The only incandescents I've had last longer than a year are ones that are rarely used. I worked out that - back when they were expensive - that after 3 months of operation they'd saved me more in electricity than the cost of an equivalent incandescent, so they've been a pretty good investment.

I don't know why that's a surprise for you. Incandescents are also limited in terms of lifetime by being turned on and off. The thermal shock of taking a very thin wire filament from room temperature up to white hot in a fraction of a second is not very good for its lifetime. That's why lightbulbs are most likely to break when you turn them on.

Listening to users isn't necessarily a good thing. Henry Ford said that if he'd asked his customers what they wanted, they'd have asked for a faster horse. This is especially true of UI design, because most people (even power users) really don't measure what they're spending time doing and get into unproductive patterns. The problem with GNOME was that they also didn't listen to usability experts. Or even vaguely competent people who had read an HCI book. They went down a path of doing things that an uninformed user and a usability expert could both agree were stupid. Apparently they've improved recently, but it cost them a lot of users.

XP also tweaked the VM subsystem in a way that was quite noticeable if you had more than about 256MB of RAM (better performance), but the main feature it added was remote desktop (although only in the Pro version). I was quite tempted to upgrade from 2K for the remote desktop stuff.

I'm not a huge fan. The goal of D was to produce a better C++, but if you're designing a new language then C++ really isn't where I'd choose to start. It's not as bad as Ruby (I can't imagine the kind of person who would look at Smalltalk and say 'what this language really needs is Perl-like syntax'. Actually, I can't imagine the kind of person who'd say that about any language. Including Perl). Rust is probably the modern language that I like the most.

Not really. They've increased a bit above inflation, but the amount I'm spending on electricity has remained pretty constant, increasingly slightly below inflation (increases in device efficiency offsetting increase in costs). The amount I'm paying for gas has gone up a bit more.

I switched to DuckDuckGo and haven't looked back. They used to be noticeably worse in results quality, but Google has gone a long way downhill. Occasionally I don't find things with DDG and try Google. When I do, I have to wade through pages of totally irrelevant stuff to find that there are no matches, whereas at least DDG tells me straight away that it can only find half a dozen possibly-relevant things. I especially like the way DDG integrates with a number of domain-specific search engines.

It isn't. It runs natively via the NDK.

I maintain the GNUstep / Clang Objective-C stack. Most people who use it now do so in Android applications. A lot of popular apps have a core in Objective-C with the Foundation framework (sometimes they use GNUstep's on Android, more often they'll use one of the proprietary versions that includes code from libFoundation, GNUstep and Cocotron, but they almost all use clang and the GNUstep Objective-C runtime). Amusingly, there are actually more devices deployed with my Objective-C stack than Apple's. The advantage for developers is that their core logic is portable everywhere, but the GUIs can be in Objective-C with UIKit on iOS or Java on Android (or, commonly for games, GLES with a little tiny bit of platform-specific setup code). I suspect that one of the big reasons why the app situation on Windows Phone sucks is that you can't do this with a Windows port.

It would be great for these people to have an open source Swift that integrated cleanly with open source Objective-C stacks. Let's not forget that that's exactly what Swift is: a higher-level language designed for dealing with Objective-C libraries (not specifically Apple libraries).

Objective-C is a good language for mid-1990s development. Swift looks like a nice language for early 2000s development. Hopefully someone will come up with a good language for late 2010s development soon...

I find it pretty easy to remember - I go to Google today.

The UI was what made me switch both to Google originally and from it some years later. When I started using Google - and when Google started gaining significant market share - most users were on 56Kb/s or slower modem connections. AltaVista was the market leader and they'd put so much crap in their front page that it took 30 seconds to load (and then another 20 or so to show the results). Google loaded in 2-3 seconds. The AltaVista search results had to be a lot better to be faster. I switched away when they made the up and down arrow keys in their search box behave differently to every other text field in the system.

My 'precious electronic toys' use about a tenth of the power that the ones I was using a decade ago for the same purpose did. Even lighting power consumption has dropped. My fridge, freezer and washing machine are the big electricity consumers in my home - efficiency has improved there, but nowhere near as fast as for gadgets.

There's a lot more to government than military intelligence gathering and law enforcement (although it would be a good idea for someone to remind most current governments that those are two things, not one). And most government projects end up spending insane budgets. This isn't limited to the US. It amazes me how often government projects to build databases to store a few million records with a few tens to thousands of queries per second (i.e. the kind of workload that you could run with off-the-shelf software on a relatively low-spec server) end up costing millions. Even with someone designing a pretty web-based GUI, people paid to manually enter all of the data from existing paper records, and 10 years of off-site redundancy, I often can't see where the money could have gone. Large companies often manage to do the same sort of thing.

The one thing that the US does well in terms of tech spending is mandate that the big company that wins the project should subcontract a certain percentage to small businesses. A lot of tech startups have got their big breaks from this rule.

Add to that, about 10-20% of the population get motion sick using the kind of VR in Oculus Rift (myself included - I can use it for 2-5 minutes, depending on the mode). It's ludicrous to imagine building a school that would exclude 20% of the potential pupils on some random criterion. You might as well make schools that didn't let in gingers...