For fluorescent light, it ends up being 120 Hz (fps). While the voltage has positive and negative peaks that make up one period, that ends up being two energy peaks as far as the bulb is concerned. (Have had to filter this out when doing light diode projects in the past.)

Folks (including me) who complain about fluorescent lights flickering are actually complaining about the ballast not keeping the bulb energized, which happens at a much lower (and irritating frequency). (That can happen for any number of reasons: cold, old bulb, ballast going bad, etc.) I greatly prefer LEDs these days (which are either DC or kHz range on the switching power supply).

Reading the articles, it's both. The constant reversals are honest (well, as honest as our banking system can be) foul-ups. Batch processes run amok, using input with errors from people at a bank (Cachet) trying to undo fraudulent transactions.

The fraudulent transactions came from MyPayrollHR, who gave Cachet instructions to move money from employer's accounts to a MyPayrollHR-controlled account instead of a Cachet holding account, then instructed them to move money from the Cachet holding account to the employees' accounts. Cachet should have caught this, but I'm hardly surprised they didn't (again, our banking system is a mess, and a reason why there will forever be laws saying transactions can be reversed for up to a zillion days on the books). I'm betting someone is going to jail for that.

There's a bit of a difference here -- automobiles don't (yet) have the ability to intrude into your personal space. If a person were to come up to you and stick a camera obtrusively in your face and insist on inject him/herself into your conversations with others (without physically touching you), most people would get agitated and eventually get physical with the interfering person. In layman's terms, the interfering person is being an asshole. Now, the law probably (IANAL) would frown on you for getting physical, but there's a fair chance you'd get off (prosecutorial discretion, etc.). Your actions might be technically illegal yet still be considered reasonable.

What happens when robots start acting like assholes? We're not quite there yet (regularly, though there are a few errant incidents). But so far I'd say we're not great at imbuing technology with social norms. While I would not advocate damaging asshole robots, I would probably condone it.

Sort of. It's more of a machine where you walk up and vote, but it only counts if you deposit enough money into the system...

This seems to yearn for the FORTRAN era-definition of simplicity, which meant "it looks like a mathematical statement" to language designers. I suppose, if you were giving a math lecture, v |> filter(fn(x) => x!= none) |> map[Int](fn(x) => x*x) could stand in for, "Let v(<X>) => <Y> map all non-nil elements to their squared integral equivalents" or somesuch. (I'm being sloppy with notation here because it's been years, I'm busy, and I kinda noped out of the Bosque README.md document after my eyes glazed over 12th or 13th TODO.)

When the entire problem-space of languages was solving numerical equations to make bomb yields more effective and estimating the gross national product from reports of steel production and wheat yields, sure... I guess this is "simple." But the reality is problems have gotten far more sophisticated. The real needs, today, are for coders to be efficient; making it easy (even for the less-skilled) to write secure code (or, at least, make it easier for the skilled to spot insecure code); run well on multi-threaded systems (e.g., make it easy to pass immutable structures around); and not be so inefficient that I have to ask the powers-that-be to double my infrastructure budget. I'm... not seeing it here.

I chatted with a few guys from the Bonneville Power Administration over in Portland. They're absolutely paranoid about this -- and with good reason.

When you start drifting from the set frequency, it's an indication that you are under or oversupplying the grid. This leads to instability, which can lead to damage on a massive scale. They don't care about setting your clock correctly; they're worried about damaging the generators at all of their plants.

I wondered how they activate plants; after all, it's likely that the generators will be out of phase and wreak havoc when attached, right? Turns out, not so much. They do try to get it roughly in line, but the phase on the line quickly steers the generators into sync.

Few do, because the number of additional parts adds a few cents to the cost (on an item that probably costs 40 cents to manufacture).

I do have a couple in my house, but they can't pick up WWVB indoors. I check after each DST switchover, grumble, put it outside for a few hours, then see that it's magically synced itself. I'm not sure if it's because they're cheap (they're ~$30 weather stations), if my house blocks signals too much, the terrain (picking up radio, TV, and cell signals is also exceedingly difficult), or my neck of the woods (Pacific Northwest).

I picked up a third one from Fry's that claims to never need to be set. Being curious about this claim, I took it apart; it just has a few coin cells in a hidden compartment. No radio.

Not a bad vision -- perhaps a touch wasteful of money and then some -- but the ISS doesn't help us here.

Just to put this in perspective, the moon is roughly 400,000 km (~ 250,000 miles) from Earth. By comparison, the ISS's altitude is 424 km (263 miles). This is like driving from San Diego to Boston and taking your first rest stop in Balboa Park. If we're talking Mars instead, that stop might be just beyond your neighbor's house (118 feet).

The ISS looks cool -- as do most multi-billion dollar construction projects -- but from a science and engineering standpoint we learned nothing by building or operating it.

I would love to see more spaceflight, but the next meaningful step has to be beyond Earth's gravity well. That means accelerating beyond the escape velocity, 11.2 km/s (40.3 km/h). We've come close, but in the wrong direction: Apollo 10's reentry speed (the fastest a human has ever gone) was 39,897 km/h. Personally, I think it would be interesting next step to put a human in the Earth's orbital path around the sun, but in the opposite direction. This gives you roughly six months to experiment and play, with recapture onto Earth almost guaranteed by gravity. This is more daunting than it sounds. You need to escape Earth's gravity (11.2 km/s), then achieve a velocity that gives you an orbit around the sun that doesn't decay (30 km/s), for a total velocity ("delta-v") of 41.2 km/s. Oh, and then you have to decelerate as you approach Earth.

Clearly, what we need to do is build a coal power plant on the ISS...

I think the "this" refers to "shipping an obviously untested product."

Part of the problem is that we (collectively) just don't get how complex software is. Sure, a good software engineer who sits down and thinks through the implications of a change will do so, but in the modern rush to market that's a rare happening. In this case, I'm guessing something like the following happened:

• "Hey, we're getting usability reports about widgets accidentally being double tapped while an app is being swapped in. What can we do to fix this?"
• "We would need to do this in the UIKit. Maybe some visual indication it's been tapped with a lockout period?"
• "Ok, great. We need this by next Friday to get it into the next iOS build."
• "That's tight, but we'll manage."
• Builds, tests... "Ok, let's see what apps use this. Calculator..." tapping deliberately "Right, looks good, results are correct. Ready to ship."

That said, much as we (software engineers) don't like it, there's something to be said for shipping quickly and, sometimes, before things are ready. Users reward this behavior, and shipping quickly can mean the difference between a product or company that succeeds vs. one that fails. The saying is "you can't shine shit," but I've seen countless examples otherwise (and the Mythbusters disproved this in, well, a literal sense). I hate it; despite it, in fact. Push back against it. But it's hard to argue when there's a throng of consumers ready to spend their money on it.

So, we're relegated to having to be judicious in what we push back against. Is it safety critical? Will someone get maimed or killed by this? If it's running on an iPhone, the answer is probably no. For Apple here, the main result is a bit of embarrassment -- a calculator that seems to give wacky results. A civil engineer using this for estimating should see this kind of issue immediately (and is unlikely to use the iOS calculator for final documents). Someone trying to split their restaurant bill, maybe not, it's an acceptable risk. The Excel 2007 multiplication bug was probably more serious because that's an application that is more likely to be used in civil engineering. If you're writing software that could lethally irradiate someone and encounter shady practices, immediately raise flags and alert everyone who will listen.

Ok, so we're not going to manually test everything on a smart phone before a new OS is released. What can we do? Push for more automation. Making aesthetic judgements automatically might still be a bit difficult, but we ought to be able to simulate key misregistrations. A quick check would be to do this in software to see the effect of a change while you're hacking away on your laptop, but a robot providing millions of taps and swipes on actual hardware would be even more insightful. This would be daunting for most startups trying to make the next Zynbookwitter on shoestring VC funding, but child's play for the likes of Apple or Google.

As mentioned previously, I work for AWS, but I'm speaking personally here.

I'm not sure where this idea of "run them for less than fifteen minutes each, terminate them after the jobs run, and not have to pay for CPU time" has come from; this is the first I've heard of it. To my knowledge, this has never been the case. Currently usage from 0-59.999... minutes is billed as 1 instance-hour; 60.0-119.999... as 2 instance-hours; etc. Starting October 2, you will be billed by the second (with a 1 minute minimum). This should be a cost savings for everyone who's currently running on-demand instances.

There is a free tier for new accounts, in which you get 750 instance-hours of t2.micro usage (on Amazon Linux, RHEL, SLES, or Windows) free. However, if you run for 14 minutes (say), that still counts today as 1 instance-hour; there's no magic 15 minute cutoff.

Disclaimer: I work for AWS, but I'm speaking personally here.

This will always be cheaper for on-demand users. Previously, you were charged a full hour for any fractional usage. As soon as you start an instance, you're being billed -- even a start and stop a second later counted as 1 hour. (There is a free tier: you get 750 hours/month of t2.micro usage on Linux, RHEL, SLES, or Windows, during the first 12 months.)

Let's say you had a batch job that ran for 12 minutes, 4x/day, on Amazon Linux on a c4.large instance in the Oregon region ($0.100/instance-hour). Before this change, you would have paid $12.20/month (4 instance-hours/day x 30.5 days/month x $0.100/instance-hour). Starting October 2, you will pay $2.44/month (0.8 instance-hours/day x 30.5 days/month x $0.100/instance-hour).

AWS believes that cloud computing is going to be a high volume, relatively low margin business, and Amazon is very comfortable with these types of businesses. AWS has had (as of this writing) 62 price reductions in the last 9 years, largely in the absence of any competitive pressure. (And, since I pay for my personal usage -- no, we don't get a free lunch here! -- that's kept me happy as a customer.) Internally, it's a relentlessly customer-obsessed culture -- you can (and I have!) stopped a VP mid-speech by saying, "Wait, I don't think that's the right thing for the customer!" (We're also a very data-driven culture, so you're expected to have data to support this, of course. :-) )

Hope this helps clear up some of the confusion. Note that there are some cases where billing will continue to be per-hour (or fraction thereof), such as marketplace usage -- Jeff Barr's blog post has all the details.

One potential flaw in this mechanism: I think a malware image can prevent rolling back to a known-good image by setting the rollback indexes to ridiculously high value, say 2147483647 (2**31-1).

This diagram shows how the workflow is supposed to proceed. If Mallory gets her verification key onto your device (either by social engineering or another flaw), then her custom malware image can be booted by the device in locked mode. The user will get a warning about this being a custom OS (good!), but then the rollback index values in Mallory's image are written to the stored rollback index values (bad!). If I then attempt to go back to Oreo 8.0, it won't let me.

A better mechanism would be to have a set of stored rollback index values per verification key, not a global set per device. Then I could roll back to the stock factory image from a Mallory's malware image.