There's really only one thing to eat while reading a story like this (other than Moar Chocolate, for Research Purposes.) It's Scalzi's Schadenfreude Pie. Dark, bitter, sticky, chocolately.

Well, thank you very much, telling me that I'd get better battery life if I installed the new Android version. As far as I can tell (at least with all previous Android versions), Google's instructions for installing the new software are "What? You don't have one of these three Google-brand phones? Then wait for your carrier!".

That's bad enough for my phone (which has a carrier, and Samsung's a reasonably major brand, though my previous HTC phone never got upgraded), but my tablet's Wifi-only, so there's no carrier, just a manufacturer who sold that model 2 years ago and doesn't have that tablet easily located on their website, and as far as I can tell, if I were to dump IceCreamSandwich for Cyanogen (who at least tell you what hardware resources you need for each version), I'd lose access to the Google Play Store?

Are you counting the notes, or the intervals? Are you counting the root once or twice (1 and 8)? Got fencepost errors?

I end up dealing with this a bit more, because I play mountain dulcimer, and dulcimer tab notation starts at 0 instead of 1, counting from the open strings to N frets in a mostly-diatonic scale. (Usually the tuning on the middle string means you end up with at least one more note available, plus most dulcimers these days add the 6.5 fret (which gets you the 7th note in the melody string's scale, as opposed to a flat-7th Mixolydian), which gives you a few more choices.

Last year I was looking into getting either a Raspberry Pi or Beaglebone Black. BBB had a newer ARM rev for the CPU, so it can run more kinds of OS. But the RPi has the removable flash as its drive, so you can easily load whatever OS image you want, change OSs by switching flash chips, and if you hose it too badly you can take it out and reload, without worrying about whether you've bricked the board. Also, the specs at the time said the RPi had a better GPU, and could do 1080p at 60 Hz vs. only 30Hz for BBB, which means I can plug it into TVs and monitors without as much flicker. I chose the RPi.

BBB nominally costs a bit more, but by the time you buy cases and power supplies and flash and such, it pretty much balances out.

Nice to see somebody getting it right.

A Floppy Disk is that device you almost never bother using, but which gets added to your virtual machines by default, at least under VMware (haven't paid attention on OpenStack.) The recently-discovered VENOM vulnerability exploits bugs in the floppy drivers, which have been around for a decade, to let a process on a virtual machine break out into the hypervisor and maybe mess with other virtual machines.

So it's especially timely to have a convenient new platform for using floppies!

GSM rolled their own crypto. They depended on Obscurity to protect their algorithm. Somebody handed a copy to Ian Goldberg, then a grad student at Berkeley, and the reason it took him three whole hours to break it was that the Chinese restaurant near campus was having the good lunch special that day.

It was a weak enough algorithm (designed in electrical-engineer-math style, which is fine if you want checksums for reliability) that I'll give them credit for incompetence, though the fact that 10 bits of the already-too-short key were always set to 0 looks much more like malice (with a slight possibility that an early hardware implementation didn't have enough spare bits on some part of the chip.)

Ron Rivest can sometimes get away with rolling his own algorithms - but RC4 and MD5 are looking pretty weak these days, even if you don't count the (documented from the beginning) rules about making sure to never ever use the same RC4 key twice, which was ignored several different ways in PPTP and in a number of other protocols implemented by people who were rolling their own implementations without understanding the algorithms.

Phones and Tablets are different problems - with phones and 3G/4G/LTE tablets, you've got a carrier who can push updates to you, but if you've got a Wifi-only tablet, there's no carrier, just a manufacturer. Do they have an incentive to upgrade? Does the user have a way to tell?

Google's new product announcements always say "See all our shiny new features! If you have one of these three Google Nexus products, you can get it! Otherwise, wait for your carrier to maybe do something!", but never say (at least to consumers; I assume they tell manufacturers) "If your device has at least this generation processor and this much memory, you can upgrade, here's how." Part of that is because, for the big-vendor phones, the manufacturer and sometimes the carrier heavily customize the product, replace half the user interface and tools with custom ones and add a bunch of useful apps or bloatware, and then you can't just do the OS upgrade yourself because you'd lose the customization and probably also lose the bloatware.

My old HTC phone was heavily customized, and the upgrade from 2.1 to 2.2 wasn't actually pushed out, though you could pull it for a little while, if your phone wasn't broken when locked-to-AndroidMarket got replaced with Google Play. My noname 4.0.x tablet which has Google Play but no obvious customization is now running 4.0.4 (I think it originally had 4.0.1), so it shouldn't be a problem to upgrade it if it's got enough horsepower - and Google never tells you how much horsepower they need, just what Nexus models support it.. I ended up replacing the HTC with a Samsung, and haven't taken the time to go back and install Cyanogen on the HTC; I assume if I did that to the tablet I'd lose Google Play access, which I depend on for apps and patches.

There are two kinds of 2.x phones out there - really old phones, and cheap low-end phones that run 2.3 because they don't have the horsepower to run 4.x. Many of them are pay-as-you-go phones you can buy at 7-11 or low-end ones from carriers for customers who don't want to pay iPhone prices.

My HTC was locked to Android Market, and wasn't willing to talk to Google Play, and the carrier never pushed out the 2.1->2.2 upgrade in a way that worked for me. 3.x was mainly a tablet release that didn't affect phones, and most of those seem to have been upgradeable to 4.0.

Back in the late 80s, when I was working on that decade's failed project to replace the 360/90-based systems, my coworker and I were in DC for a meeting on some phase of the project (or one of the related projects), and we had half a day spare, so we went to the Smithsonian Air&Space Museum to do "research". They didn't have examples of the system we were working on, but they did have some other air traffic control systems (Tracon, I think), and other cool stuff like astronaut ice cream. After that we went to the National Gallery, because Van Gogh.

That's not even counting the huge amount of code that's designed to make sure all the other parts of the code are working, and to do something appropriate if they're not, and the code that's designed to make sure that code is also working. That stuff's a lot harder than the basic code, and getting it right is the difference between a system with double- or triple-redundant hardware that gets you the 8 9s of reliability the FAA naively thought was possible with 1980s hardware and a air-traffic control system that had triple-redundant hardware running an operating system that crashed weekly (that one was in Singapore, but I don't know if it was actually deployed; I assume they killed it long before it hit the field.)

The 1980s attempt at developing this was only going to be deployed at the ~25 En-Route control centers (with simpler components at the several hundred radar sites feeding each one); it's not intended to be at every airport tower, which was a bunch of different systems.

It's interesting to see how much this thing has grown into, beyond the initial "get radar signals onto the board and replace paper flight-strips and never ever ever crash" goals.

Most of it on the part of the people who started the original project, who thought it would be done in 3-4 years, made way too many incorrect decisions for the wrong reasons, specified lots of requirements without understanding how impossible they were to meet, picked multiple sets of pie from multiple sets of skies, and didn't start with the ability to get kinds of budget they would have needed to do the job right (if they'd picked a definition of "right" that could have been implemented in the 1980s, when they were trying to replace a 1960s system that had much lower ambitions when it was built, but was still a big upgrade over the 1950s predecessor), but the one thing everybody knew was that if airplanes fall out of the sky or crash into each other, the FAA gets blamed, and if the system's late, the FAA gets blamed, and if it's over budget, the FAA gets blamed, and if the budget had been bigger to start with, the FAA would have been blamed, and if the FAA's going to get blamed, then you can be the contractors trying to design the system are going to get blamed a lot, even just for asking questions when they're working on the thing.

Projects with a scope of tens of millions of dollars are much much different than projects with a scope of a few billions or a few tens of billions. A couple of years after I worked on my part of that fiasco, one of the directors for information systems for one of the National Labs was telling us that he was trying to restructure things to be done in small manageable projects, because he'd never seen the government do a billion-dollar computer project that didn't fail. And all that ancient "Mythical Man-Month" stuff said things you probably already knew about projects in the $10m range sometimes being too large; I remember one much less critical project that had 30 people working on it, so it had to grow to 150 people before it totally failed; if it had started with 5 people instead of 30 and had a budget limiting it to a max of 10, it might have worked. But projects that know they're legitimately in the billion-dollar scale are really really hard.