I'm in a 32-unit condo. Yes, we've got an HOA, but it's just us. We've occasionally hired management companies to do stuff for us, but only when it made sense. And yeah, we've occasionally gotten into arguments, like the current one about what trees need to be cut down (the cheapskate builder who built the place in the 70s did things like planting redwoods and some fast-growing trees right next to the building, so we're having problems with roots and roofs that stay wet all the time, but they are nice for shade. And we do occasionally have people who get grumpy about the monthly fees, but the accountant is one of the residents, you can see all the numbers, and possibly we need to be putting even more into some of the maintenance funds than we do.
I live in a condo. It was built in the 1970s, with the kind of high quality building where right angles weren't really a requirement, just kind of a suggestion, cement subfloor needed to be smooth enough to cover with carpet, not actually good enough to replace with wood later, redwoods and other trees were planted too near the buildings so we're having root problems, etc. Even though some of the folks have been here since the beginning (and it's only a 32-unit complex), nobody's got a bloody clue where lots of the wiring and plumbing is. We know where a few parts of it are, but how the plumbing or electricity gets between the upstairs and downstairs units is mostly a mystery, and when the cable company wanted to replace the old analog system with digital, they just ran new cables on the outside of the building and made holes because they couldn't figure out what was going on inside (so I've got some really convenient cable jacks that aren't on the new system.)
But yeah, conduit is the way to future-proof any communication technology that does need wires. Also, heating/cooling ducts can be really useful (both for themselves, and for adding in wire later if you didn't have conduit.) I currently live in a part of California that has lots of buildings with electric heat (lowest upfront cost to the builder, and my annual heat costs are higher than when I lived somewhere with actual winter), and we don't really know how the 220V line gets from the thermostat to the heater, and don't want to rip out the ceiling and walls to trace it. (Before that I lived in a house with steam radiators, which I liked, but there wasn't a way to put in central A/C.)
Putting in more sockets along the walls than your current electrical code calls for is usually a win, as is home-running them all to the electrical box if you can. I needed more power upstairs, and we had to rip out a bunch of bathroom wall and ceiling to run the cables from the circuit breaker box. Also, you should put in a circuit breaker box that's big enough to add a bunch of random things later, instead of one that just barely has room for the initial wiring.
Some applications care about having nearly 1.5 volts, and this device will make a disposable battery last a lot longer for them; I've had a few electronic or electro-mechanical devices that got grumpy about only getting 1.2 volts from NiMH, so I asked these guys about it.
Their response was that it'll boost the voltage just fine, but may be bad for the battery's life, because they really don't like being drained too low, and the Batteriser is designed to suck every bit of power it can out of a disposable battery, not to treat a rechargeable battery nicely.
Lithium-Ion batteries are even more picky, and need special control circuitry that'll cut off the power if the battery's voltage gets too low (and also cut off charging if it gets too high.) NiMH aren't as picky about it, but you can still shorten their useful life a lot if you mistreat them; back when I was using a lot of them, I'd typically only get 5-10 full charge/discharge cycles from one if I wasn't careful. They could make a model that worked with NiMH if they wanted too, but it'd probably cost them a few cents more in circuitry, and they're trying to make a low-cost retail device.
The best solution I found to that problem was Nickel-Zinc rechargeable batteries, which have a chemistry that puts out 1.6 volts, so almost all of the devices that are picky about voltage are really happy with them, and capacity was similar to NiMH. Unfortunately, they seem to have disappeared from the market a bit after I bought the first batch of them, or at least Fry's stopped carrying them.
Somebody else mentioned Bluetooth, and yeah, I do want that, because my car radio now supports it, so it lets me have a decent speakerphone in the car instead of having a wired headset, and that probably adds $5 to the cost of the phone.
It's apparently more complicated than that. AT&T and Verizon have started offering it, on LTE phones, but it's rolling out slowly on a geography-by-geography basis, rather than being available everywhere at once.
* (Disclaimer: I work for AT&T, so I should probably know this stuff, but I do network security, not mobile phones.)
It's nice that there are cheap 2G phones in India, but I need a phone that works in the US, and wouldn't mind having a cheap phone that can also work in Europe. These days that means at least 3G, or maybe LTE, because the US carriers are phasing out 2G as fast as they can to recycle the spectrum. And it would be really nice to have a $30 spare dumb-phone to keep in the car or to use at times it's not convenient to keep my smartphone charged.
My last dumb-phone had a 2-week battery life. 90% of the time, I want a phone to make phone calls and send text, and I'd rather have something that's 1/4 as large as the pocket computer I'm carrying around. The other 10% of the time, I either want to check my email, or I want a camera, and yeah, I never bother using my camera any more, even though it takes better pictures than my phone, because it is convenient to only carry one device around.
I can read interesting material much faster than I can listen to it on video, and I can differentiate between interesting and uninteresting material much MUCH faster reading it than slogging through a video. Transcripts aren't perfect, but at least they're a start.
Search Engines try to find the most interesting pages that match queries from humans; they do this using robots running algorithms that model what humans might find interesting. "Search Engine Optimizers" try to model what search engine robots will do, and trick them into showing their customers' uninteresting web pages first instead of pages that humans will actually find interesting, because they want to sell you crap. (Doesn't matter if they're good at it, as long as their also-scum customers pay them.)
SEOs will tell you they're not doing the black-hat stuff that got them a bad name, and that they're really providing legitimate services for their customers*. Sure, they'll help you rewrite your web page so Google's robots can find the interesting parts (Google will also tell you how to do this, for free, and I agree that charging a customer money to tell them not to hide their important content in singing dancing Flash-Animated Javascript-requiring Videos is actually a non-scummy valuable service to the public - but most people who sell those services call themselves "web designers" or similar consulting titles.)
Some of them will also tell you how to write actual interesting content for your web pages - but most people who do that call themselves "editors" or "content specialists" or similar titles, and only fall back on the term "SEO" if they're appealing to dumber customers or trying to also offer scummy services.
If Google's changing their search rankings in a publicly documented way, and you're calling it a "mobilegeddon" because it breaks all your little tricks for boosting uninteresting content to higher search rankings, you deserve it. If you're a legitimate web design specialist, you don't need scare tactics like that, you just need to learn what Google wants and offer legitimate re-design services.
Bah - Yahoo's dumping their maps just about the same time that Google's been making Google Maps much less usable, at least on browsers. Not only does it take a lot longer to load the map of where it thinks you are before it's willing to listen to you type what you really want a map of, it's been getting much harder to actually display directions even after that. For instance, if you want to go from A to B, it shows you a short abstract of the directions, and lets you click on parts to expand them. But you can't just expand the area around B without losing the fat purple line display of the route. Almost all the time, when I'm looking for directions to somewhere, the part I need the most detail about is the area around the destination; I usually know where I am, and how to get to the freeway from there.
For a while I was able to use "Classic Google Maps" and avoid this "upgrade", but that seems to have gone away.
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?
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.
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.
It's designed for object-oriented use, with lots of type specification and such upfront, to push decisions into upfront design time rather than coding time, and it's not as terse as C or APL, but it's nowhere near as verbose as COBOL. I wouldn't use it today (mostly because its main uses are for military stuff I won't do, and for antique maintenance, and it doesn't have all the friendly libraries that I'm used to and probably doesn't easily link to non-Ada systems), but it's a fairly cromulent language.
You did get the bit about how this system was decades behind schedule and tens or hundreds of billions over budget, with a couple of major iterations thrown away in the process? 2MLOC sounds nice, clean, compact, and surprisingly low.
The article you're pointing to was about how one of the ERAM systems crashed trying to cope with a bizarre flight plan for a U-2 spy plane.
When I was working on AAS in the late 80s, one thing I was mildly concerned about was that the planned "upgrade" our project was trying to design wouldn't really be able to cope with super-sonic aircraft over the continental US. The requirements for how much area had to show on a controller's screen and how fast the radar sweeps were meant that anything at Concorde speeds would kind of blip onto the screen, maybe bounce once or twice more, and then be gone by the next refresh, either to somebody else's screen or another regional center. Economics and politics (sonic booms, restrictions on what nations' airlines could compete for US markets, etc.) meant that it wasn't a likely prospect anyway, but U-2 spy planes operate under different economics and politics.
Back in the 1980s, the FAA's shiny new Advanced Automation System project (AAS) was being designed to replace the 1960s-vintage En-Route system, which used IBM 360/90 and 360/50 computers that were getting to be old, unmaintainable, and unreplaceable. (It was getting hard to even get cable connectors for components - imagine coming up with new SCSI-1 terminators these days.)
As with many military aircraft system contracts, they ran a design competition, which had funneled down from 4 bidders to two by the time I was there. I worked for a subcontractor on one of the teams bidding on AAS. We were the lucky ones who lost; IBM were the poor suckers who won the deal. We learned many lessons about how not to do large software projects. The requirements weren't very well-defined, but the one thing that was certain was that if yet another airplane crash happened, the FAA would take lots of political heat, so everything had to be totally bullet-proof, and every bureaucratic ass had to be covered in triplicate. The phase we were working on was already behind schedule and over budget, and once IBM won it got much farther behind, way farther over budget, and it kind of slunk into the 90s, the 2000s, and the articles referenced above make it sound like Lockheed-Martin bought the IBM Federal division that was working on this debacle.
Originally, the requirements were for 8 9s of reliability (so 99.999999%), but what was worse was that there was no definition of what a failure event was. If a failure meant "each individual radar needed to meet 8 9s", that was hard enough, but if a failure meant "ANY radar's connection was down", that meant the system had to meet 10 9s, not just 8, since there were O(100) radars. Everything had to be triple-redundant to meet those numbers, because taking down any component of a dual-redundant system for maintenance for 5 minutes would blow your reliability for the year. We later found out that the existing 1960s-vintage system that AAS was supposed to replace was shut down for 4 hours per night, replaced by EDARC (a ~1970s upgrade to the ~1950s DARC radar controllers), to make sure that the EDARC system was available as a working backup and that personnel stayed trained in using and maintaining it. (And of course the radars only had dual access lines, with a typical reliability of 3-4 9s each, so 8 9s per radar was already overkill. Phone company equipment with the famous 5 9s of uptime got that by using lots of dual redundancy in appropriate places.)
AAS was originally required to use DOD-STD-2167 software development methodology, a 1985 standard that the DOD replaced in 1988 with 2167A because 2167 was unusable. (You're having trouble dealing with Agile? This is way way far out the other direction.) Both were cumbersome waterfall processes, 2167 requiring something like 180 documents over the predicted 3-year development period, so every week, there'd be one or more new documents, hundreds of pages long, that were all ironclad requirements for all remaining development; developers wouldn't have the time to read and analyze each document and still get their work done, and if they determined down the road that a previous decision had undesirable consequences, there was no way to go back and change it. For example, a decision about whether a given calculation should be done out at the remote radar site, or on one of several central processing computers, or on the computer that drove a given operator console, might turn out to make several hundred milliseconds difference in processing time, but any given radar signal had to get from the remote radar to the console in under 1 second. The subcontractor designing the display consoles knew they wouldn't have the horsepower to do it in time, so they bounced it to the central processors early in the requirement process; those didn't even have an architecture that met the redundancy specs yet, so we didn't know if they'd have the resources to do it in time either. (We later offered to move a bit more of thei
Sorry, you're not getting my caffeine until you pry my cold dead fingers off the coffee cup.
The other sweetener I've seen showing up in sodas lately has been stevia. I normally avoid the stuff like the plague - tastes worse to me than aspartame does, though in a rotting-organic-bad way rather than a metallic-fake way. Maybe cola flavors can mask that, though.
Slashdot Mirror
I'm in a 32-unit condo. Yes, we've got an HOA, but it's just us. We've occasionally hired management companies to do stuff for us, but only when it made sense. And yeah, we've occasionally gotten into arguments, like the current one about what trees need to be cut down (the cheapskate builder who built the place in the 70s did things like planting redwoods and some fast-growing trees right next to the building, so we're having problems with roots and roofs that stay wet all the time, but they are nice for shade. And we do occasionally have people who get grumpy about the monthly fees, but the accountant is one of the residents, you can see all the numbers, and possibly we need to be putting even more into some of the maintenance funds than we do.
I live in a condo. It was built in the 1970s, with the kind of high quality building where right angles weren't really a requirement, just kind of a suggestion, cement subfloor needed to be smooth enough to cover with carpet, not actually good enough to replace with wood later, redwoods and other trees were planted too near the buildings so we're having root problems, etc. Even though some of the folks have been here since the beginning (and it's only a 32-unit complex), nobody's got a bloody clue where lots of the wiring and plumbing is. We know where a few parts of it are, but how the plumbing or electricity gets between the upstairs and downstairs units is mostly a mystery, and when the cable company wanted to replace the old analog system with digital, they just ran new cables on the outside of the building and made holes because they couldn't figure out what was going on inside (so I've got some really convenient cable jacks that aren't on the new system.)
But yeah, conduit is the way to future-proof any communication technology that does need wires. Also, heating/cooling ducts can be really useful (both for themselves, and for adding in wire later if you didn't have conduit.) I currently live in a part of California that has lots of buildings with electric heat (lowest upfront cost to the builder, and my annual heat costs are higher than when I lived somewhere with actual winter), and we don't really know how the 220V line gets from the thermostat to the heater, and don't want to rip out the ceiling and walls to trace it. (Before that I lived in a house with steam radiators, which I liked, but there wasn't a way to put in central A/C.)
Putting in more sockets along the walls than your current electrical code calls for is usually a win, as is home-running them all to the electrical box if you can. I needed more power upstairs, and we had to rip out a bunch of bathroom wall and ceiling to run the cables from the circuit breaker box. Also, you should put in a circuit breaker box that's big enough to add a bunch of random things later, instead of one that just barely has room for the initial wiring.
Some applications care about having nearly 1.5 volts, and this device will make a disposable battery last a lot longer for them; I've had a few electronic or electro-mechanical devices that got grumpy about only getting 1.2 volts from NiMH, so I asked these guys about it.
Their response was that it'll boost the voltage just fine, but may be bad for the battery's life, because they really don't like being drained too low, and the Batteriser is designed to suck every bit of power it can out of a disposable battery, not to treat a rechargeable battery nicely.
Lithium-Ion batteries are even more picky, and need special control circuitry that'll cut off the power if the battery's voltage gets too low (and also cut off charging if it gets too high.) NiMH aren't as picky about it, but you can still shorten their useful life a lot if you mistreat them; back when I was using a lot of them, I'd typically only get 5-10 full charge/discharge cycles from one if I wasn't careful. They could make a model that worked with NiMH if they wanted too, but it'd probably cost them a few cents more in circuitry, and they're trying to make a low-cost retail device.
The best solution I found to that problem was Nickel-Zinc rechargeable batteries, which have a chemistry that puts out 1.6 volts, so almost all of the devices that are picky about voltage are really happy with them, and capacity was similar to NiMH. Unfortunately, they seem to have disappeared from the market a bit after I bought the first batch of them, or at least Fry's stopped carrying them.
Somebody else mentioned Bluetooth, and yeah, I do want that, because my car radio now supports it, so it lets me have a decent speakerphone in the car instead of having a wired headset, and that probably adds $5 to the cost of the phone.
It's apparently more complicated than that. AT&T and Verizon have started offering it, on LTE phones, but it's rolling out slowly on a geography-by-geography basis, rather than being available everywhere at once.
* (Disclaimer: I work for AT&T, so I should probably know this stuff, but I do network security, not mobile phones.)
It's nice that there are cheap 2G phones in India, but I need a phone that works in the US, and wouldn't mind having a cheap phone that can also work in Europe. These days that means at least 3G, or maybe LTE, because the US carriers are phasing out 2G as fast as they can to recycle the spectrum. And it would be really nice to have a $30 spare dumb-phone to keep in the car or to use at times it's not convenient to keep my smartphone charged.
My last dumb-phone had a 2-week battery life. 90% of the time, I want a phone to make phone calls and send text, and I'd rather have something that's 1/4 as large as the pocket computer I'm carrying around. The other 10% of the time, I either want to check my email, or I want a camera, and yeah, I never bother using my camera any more, even though it takes better pictures than my phone, because it is convenient to only carry one device around.
I can read interesting material much faster than I can listen to it on video, and I can differentiate between interesting and uninteresting material much MUCH faster reading it than slogging through a video. Transcripts aren't perfect, but at least they're a start.
Search Engines try to find the most interesting pages that match queries from humans; they do this using robots running algorithms that model what humans might find interesting. "Search Engine Optimizers" try to model what search engine robots will do, and trick them into showing their customers' uninteresting web pages first instead of pages that humans will actually find interesting, because they want to sell you crap. (Doesn't matter if they're good at it, as long as their also-scum customers pay them.)
SEOs will tell you they're not doing the black-hat stuff that got them a bad name, and that they're really providing legitimate services for their customers*. Sure, they'll help you rewrite your web page so Google's robots can find the interesting parts (Google will also tell you how to do this, for free, and I agree that charging a customer money to tell them not to hide their important content in singing dancing Flash-Animated Javascript-requiring Videos is actually a non-scummy valuable service to the public - but most people who sell those services call themselves "web designers" or similar consulting titles.)
Some of them will also tell you how to write actual interesting content for your web pages - but most people who do that call themselves "editors" or "content specialists" or similar titles, and only fall back on the term "SEO" if they're appealing to dumber customers or trying to also offer scummy services.
If Google's changing their search rankings in a publicly documented way, and you're calling it a "mobilegeddon" because it breaks all your little tricks for boosting uninteresting content to higher search rankings, you deserve it. If you're a legitimate web design specialist, you don't need scare tactics like that, you just need to learn what Google wants and offer legitimate re-design services.
And yes, I did RTFA, but I didn't WTFV.
Bah - Yahoo's dumping their maps just about the same time that Google's been making Google Maps much less usable, at least on browsers. Not only does it take a lot longer to load the map of where it thinks you are before it's willing to listen to you type what you really want a map of, it's been getting much harder to actually display directions even after that. For instance, if you want to go from A to B, it shows you a short abstract of the directions, and lets you click on parts to expand them. But you can't just expand the area around B without losing the fat purple line display of the route. Almost all the time, when I'm looking for directions to somewhere, the part I need the most detail about is the area around the destination; I usually know where I am, and how to get to the freeway from there.
For a while I was able to use "Classic Google Maps" and avoid this "upgrade", but that seems to have gone away.
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?
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.
It's designed for object-oriented use, with lots of type specification and such upfront, to push decisions into upfront design time rather than coding time, and it's not as terse as C or APL, but it's nowhere near as verbose as COBOL. I wouldn't use it today (mostly because its main uses are for military stuff I won't do, and for antique maintenance, and it doesn't have all the friendly libraries that I'm used to and probably doesn't easily link to non-Ada systems), but it's a fairly cromulent language.
You did get the bit about how this system was decades behind schedule and tens or hundreds of billions over budget, with a couple of major iterations thrown away in the process? 2MLOC sounds nice, clean, compact, and surprisingly low.
The article you're pointing to was about how one of the ERAM systems crashed trying to cope with a bizarre flight plan for a U-2 spy plane.
When I was working on AAS in the late 80s, one thing I was mildly concerned about was that the planned "upgrade" our project was trying to design wouldn't really be able to cope with super-sonic aircraft over the continental US. The requirements for how much area had to show on a controller's screen and how fast the radar sweeps were meant that anything at Concorde speeds would kind of blip onto the screen, maybe bounce once or twice more, and then be gone by the next refresh, either to somebody else's screen or another regional center. Economics and politics (sonic booms, restrictions on what nations' airlines could compete for US markets, etc.) meant that it wasn't a likely prospect anyway, but U-2 spy planes operate under different economics and politics.
Back in the 1980s, the FAA's shiny new Advanced Automation System project (AAS) was being designed to replace the 1960s-vintage En-Route system, which used IBM 360/90 and 360/50 computers that were getting to be old, unmaintainable, and unreplaceable. (It was getting hard to even get cable connectors for components - imagine coming up with new SCSI-1 terminators these days.)
As with many military aircraft system contracts, they ran a design competition, which had funneled down from 4 bidders to two by the time I was there. I worked for a subcontractor on one of the teams bidding on AAS. We were the lucky ones who lost; IBM were the poor suckers who won the deal. We learned many lessons about how not to do large software projects. The requirements weren't very well-defined, but the one thing that was certain was that if yet another airplane crash happened, the FAA would take lots of political heat, so everything had to be totally bullet-proof, and every bureaucratic ass had to be covered in triplicate. The phase we were working on was already behind schedule and over budget, and once IBM won it got much farther behind, way farther over budget, and it kind of slunk into the 90s, the 2000s, and the articles referenced above make it sound like Lockheed-Martin bought the IBM Federal division that was working on this debacle.
Originally, the requirements were for 8 9s of reliability (so 99.999999%), but what was worse was that there was no definition of what a failure event was. If a failure meant "each individual radar needed to meet 8 9s", that was hard enough, but if a failure meant "ANY radar's connection was down", that meant the system had to meet 10 9s, not just 8, since there were O(100) radars. Everything had to be triple-redundant to meet those numbers, because taking down any component of a dual-redundant system for maintenance for 5 minutes would blow your reliability for the year. We later found out that the existing 1960s-vintage system that AAS was supposed to replace was shut down for 4 hours per night, replaced by EDARC (a ~1970s upgrade to the ~1950s DARC radar controllers), to make sure that the EDARC system was available as a working backup and that personnel stayed trained in using and maintaining it. (And of course the radars only had dual access lines, with a typical reliability of 3-4 9s each, so 8 9s per radar was already overkill. Phone company equipment with the famous 5 9s of uptime got that by using lots of dual redundancy in appropriate places.)
AAS was originally required to use DOD-STD-2167 software development methodology, a 1985 standard that the DOD replaced in 1988 with 2167A because 2167 was unusable. (You're having trouble dealing with Agile? This is way way far out the other direction.) Both were cumbersome waterfall processes, 2167 requiring something like 180 documents over the predicted 3-year development period, so every week, there'd be one or more new documents, hundreds of pages long, that were all ironclad requirements for all remaining development; developers wouldn't have the time to read and analyze each document and still get their work done, and if they determined down the road that a previous decision had undesirable consequences, there was no way to go back and change it. For example, a decision about whether a given calculation should be done out at the remote radar site, or on one of several central processing computers, or on the computer that drove a given operator console, might turn out to make several hundred milliseconds difference in processing time, but any given radar signal had to get from the remote radar to the console in under 1 second. The subcontractor designing the display consoles knew they wouldn't have the horsepower to do it in time, so they bounced it to the central processors early in the requirement process; those didn't even have an architecture that met the redundancy specs yet, so we didn't know if they'd have the resources to do it in time either. (We later offered to move a bit more of thei
Sorry, you're not getting my caffeine until you pry my cold dead fingers off the coffee cup.
The other sweetener I've seen showing up in sodas lately has been stevia. I normally avoid the stuff like the plague - tastes worse to me than aspartame does, though in a rotting-organic-bad way rather than a metallic-fake way. Maybe cola flavors can mask that, though.