It took a lot longer than a few weeks to break even for me, but it was less than a year. Allowing different thermostat settings at different times and on different days made the house quite a lot more efficient.

I'm surprised that it's taken this long. I've thought that MS and Apple should have been incorporating aggressive anti-tracking and ad blocking capabilities into IE and Safari for a few years, because neither company makes much money from ads, both could easily spin it as a user-centric decision, and it would hurt Google a lot.

The BIOS almost certainly won't enable any of the software-controlled power management features of your CPU. If it's a pre-EFI BIOS then it's also running in real mode and even if it's EFI it's likely to be running in a polling loop rather than relying on interrupts for user input.

I use the Mac equivalent, TextEdit, quite often for jotting down quick notes and for quickly opening text files (including rich text and Word docs where I don't really care about the formatting). TextEdit is a very thin wrapper around the NSTextView class, and so is the same sort of not-quite-demo-app as WordPad, which is a thin wrapper around Microsoft's rich text editor control. I have Word, Pages, OpenOffice and LibreOffice installed, but I probably use TextEdit more than all of them combined, because for most simple things it just gets out of the way.

Mozilla derives its income from things like search placement, which are paid proportionally to the number of users, so effectively anyone who uses Firefox and doesn't change the default search engine is a paying customer.

Open source, like proprietary software, is supposed to be about what the contributors want. In the proprietary COTS model, it's easy to identify the contributors: they're the ones handing over money in exchange for the product. In the bespoke model - proprietary or open - it's usually the person paying the developers salary. In the mass-market open source model, it's much harder (and may be a mixture of volunteer devs / doc writers / bug reporters and so on, as well as some people funding the project). For Mozilla, most of the work is done by people who are paid, but their salaries come from from an income stream (money from the default search provider and so on) that makes it quite difficult to see who the contributors are. Technically, they're probably the users, since that's essentially how Moz Corp gets its money, but via a lot of layers of indirection.

Biking when it's snowy or icy isn't that dangerous, as long as your bike is in good condition and you've had a lot of practice cycling. I suspect that neither of these are entirely true for users of this scheme.

Keep burning them at current rates, and by 2100 we'll have run out. The headline really should have been 'Politicians promise their countries will do something that they'd have to do anyway, long after they'll have retired'

That's more or less the system in the UK. You get a loan that charges interest at the rate of inflation, plus some government funding if you qualify (lower income people only). The loans are guaranteed by the government and the interest and repayments are collected at the same time as taxes and assessed based on income (so you don't start paying them back until you're earning above a certain rate). The loans are issued by a not-for-profit company, effectively by the government though separate for accounting purposes. The government bets that having more people with degrees will increase tax revenues in the future. There is a fairly good market for rate-of-inflation investments (i.e. the other side of the loans), if they come with very low risk. Generally, if you have lots of money you want to have a reasonable chunk of it in something safe and have a smaller part in high-risk, high-return investments. Government-backed loans make a solid part of such a portfolio.

Tuition fees are also capped by the government (currently at £9K/year, which is a bit excessive. When I was a student the cap was £3K, which was a lot more reasonable. Unfortunately, the last government cut government funding at the same time that they put up the maximum requirement, effectively forcing most universities to raise their fees to £9K to keep the same per-student income. The Scottish and Welsh governments both pay the fees, so they really only apply to English students, which also causes a bit of friction).

Tuition may only be $10K/year, but how much are you living expenses as a student? You're likely in shared accommodation and eating cheap food, but can you do it for under $5K/year? That adds another $20K. Still not $100K, but edging in that direction.

There was a study a couple of years ago from Harvard (and covered on Slashdot) that put the optimum price for maximising profit at 5/track. At that price, people don't think about buying music - they'll happily buy an album because they heard a bit of a song and liked it or a friend recommended the artist. The increase in sales, the study claimed, would more than offset the reduction in per-sale profit.

There are three compilers for Go, one based on the Plan 9 stuff, one a GCC front end, and one an LLVM front end. True, none of them use header files, but this is really something that doesn't affect C-family languages if you use precompiled headers. The Plan 9 implementation is fast because it does a tiny subset of the optimisations that GCC or LLVM would do.

The GCC and LLVM-based compilers are have similar compile-time performance to C or Objective-C. They're only faster in comparison to C++ because they don't do any compile-time specialisation (which, by the way, something like a .NET CLR or JVM will do in the JIT, but which Go never does). In C++, you pay a price in compile time for better run time[1] if you use templates or pay it at run time if you use virtual functions, in Go you pay the price at run time and have no alternative. Unless you're the person implementing the generic Map type (though the Map can't be usefully parameterised, so you often end up paying it as a user of this type too).

Go does a lot of nice things (channels, interfaces, and so on), but it is frustrating when a new language includes problems that other languages fixed decades ago. Share via communicating is a sensible pattern, but a new language for parallelism that doesn't make it trivial to enforce shared xor mutable is embarrassing. Erlang had this right from the start and Pony does it in a very nice way.

[1] Unless you end up blowing away your i-cache. It's true that a lot of C++ programmers will overuse templates and end up sacrificing compile time for no measurable run-time benefit, but at least when you actually want to retain most of the source flexibility of dynamic dispatch without the run-time overhead then you can.

Add to that, Go and Swift are pretty small languages. Learning either is something that a moderately competent programmer ought to be able to do in a few weeks. Neither is sufficiently different to other languages that there's a big cognitive jump. The difficult thing is always learning new libraries and frameworks, not learning a new language (well, unless the new language is C++, where after a decade of daily use developers are still not surprised to come across a language feature that they've never seen before).

Right. Apple created Swift because Objective-C was a nice language for the requirements of '90s computing, but is starting to be limited by its C heritage. They needed a more modern language that interoperates very well with Objective-C (because they have a lot of legacy Objective-C code that isn't going away any time soon) and this required making a new language because there weren't any good contenders available. MacRuby is the closest, but falls short in a number of areas.

Google didn't create Go as the result of some corporate masterplan, a small team at Google created it and managed to get buy-in from some other groups at Google. It's still far from the most widely used language for new projects inside Google, but it does have some advantages (though is slightly let down by Rob Pike's refusal to accept that some people who are not Rob Pike have had good ideas in the last 30 years).

The recruiting thing can't really work. It would only really make sense if people would learn a cool language and then discover that there are very few places where they can work and use it. This is sort-of true for something like Erlang or Smalltalk, but Swift is fairly widely used by people developing for iOS and OS X (and would probably not be worth Apple's effort in developing it if it weren't). If the language is successful enough that enough people are learning it to significantly affect the pool of potential applicants for a company the size of Apple or Google, then enough other companies are likely to be using it that it isn't a significant benefit.

I'm also not in America. The BCS is our local equivalent, but the ACM has a large international membership and either runs, or co-runs with the IEEE, almost all of the top-tier computer science conferences around the world. It also publishes most of the top-tier journals in computer science. What country are you from where no one has ever heard for the ACM? I'd have guessed Australia from your username, but that can't be it as the ACM has a fairly significant presence there.