too much free time.

https://www.riteaid.com/custom...
http://www.cvs.com/help/email-...

Here's the message I sent. If you're lazy, feel free to use it:
Disabling Apple Pay and Google Wallet, which were previously accepted is not OK. If you want to come up with your own competing system and give people rewards to use it, that's fine, but don't break existing functionality. Google Wallet just works. Apple and Google's solutions don't cost you any more money than a credit card transaction. Your payment app isn't even available yet and relies on QR codes, which means that when it does launch it will likely be very clunky by comparison.

If you can't come up with a sane response to this, I guess I'll be switching to Walgreens.

I used to use Google Wallet / tap to pay at Rite-aid frequently as there's one across the street from my office. I liked it. The other day when I went in and tried and got a message about Apple pay not being supported, I was pretty confused. I don't use Apple pay. Why disable functionality that was previously working and that customers want to use? Google wallet does not charge merchants at all (http://www.google.com/wallet/business/faq.html). If stores want to set up their own competing wallet apps, that's fine, but disabling something that previously worked and that costs them nothing is really stupid.

To someone smarterthanme?

One way they could do this would be by making it easier to run OSX / MacOS in a VM -- they currently make this very hard. If they didn't intentionally make it hard to virtualize their OS, people would be free to upgrade their hardware and keep an old VM around for the few legacy things they need. I don't mind that Apple doesn't support everything forever -- look how that's worked out for Microsoft.

No. While it depends on your end users (end users of some products / libraries / etc are very technical, while other products draw from a much larger, less technical user base), a non-trivial number of bug reports are due to user error, or to something that you don't actually have any control over. Skipping stage 1 probably makes sense in all cases, but the rest of the stages are all valid. Sometimes you never get past stage 2 because the answer is "oh, right, because my machine isn't infected with something" or "because I didn't mis-configure the application".

Sure, I'm willing to believe that Hamas has some technology behind what they're doing, but it surely can't be anywhere near as advanced as what the IDF has. The Israel / Hamas conflict is about as mismatched as it would be if the US went to war with Bolivia. I'm sure if that happened, some people in the American press would point out that the Bolivians have rifles, while forgetting to mention that we have nuclear subs and airfraft carriers.

I'd rather keep my mechanical / automatic watch. It's durable, looks nice, keeps excellent time, never needs charging and will still be nice 20 years from now. Show me a smart watch that can do that and I might be interested.

Thanks for all of the feedback -- it's useful.

A couple clarifications: we do have redundant systems, on multiple physical machines with redundant power and network connections. If a VM (or even an entire hypervisor) dies, we're generally OK. Unfortunately, some things are very hard to make HA. If a primary database server needs to be rebooted, generally downtime is required. We do have a pretty good monitoring setup, and we also have support staff that work all shifts, so there's always someone around who could be tasked with 'call me if this breaks'. We also have a senior engineer on call at all times. Lately it's been pretty quiet because stuff mostly just works.

Basically, up to this point we haven't automated anything that will / could be done during a maintenance window that causes downtime on a public facing service, and I can understand the reasoning behind that, but we also have lab and QA environments that are getting closer to what we have in production. They're not quite there yet, but when we get there, automating something like this could be an interesting way to go. We're already starting to use Ansible, but that's not completely baked in yet and will probably take several months.

My interest in doing this is partly that sleep is nice, but really, if I'm doing maintenance at 5:30 AM for a window that has to be announced weeks ahead of time, I'm a single point of failure, and I don't really like that. Plus, considering the number of systems we have, the benefits of automating this particular scenario are significant. Proper testing is required, but proper testing (which can also be automated) can be used to ensure that our lab environments do actually match production (unit tests can be baked in). Initially it will take more time, but in the long run anything that can eliminate human error is good, particularly at odd hours.

Somewhat related, about a year ago, my cat redeployed a service. I was up for an early morning window and pre staged a few commands chained with &&'s, went downstairs to make coffee and came back to find that the work had been done. Too early. My cat was hanging out on the desk. The first key he hit was "enter" followed by a bunch of garbage, so my commands were faithfully executed. It didn't cause any serious trouble, but it could have under different circumstances. Anyway, thanks for the useful feedback :)

OP here. Yes, they are VMs in most cases. The only machines we don't virtualize are database servers.

It seems like Ikea Hackers actually adds value to the Ikea brand and probably encourages traffic to their stores. I don't think anyone who's ever visited the site could be confused about whether it's an official Ikea site or not. This was a boneheaded decision.

Of course it doesn't, and I never said that. But your chances of data corruption if you use ZFS without ECC are somewhat greater, and potentially much more catastrophic. A web search for 'ZFS without ECC' will point you to a number of horror stores. Basically, ZFS always trusts what's in memory, so if what's in memory differs from what's on disk, the contents on disk get overwritten. If this discrepancy is due to bit rot, that's great -- you've just saved your data. But if it's due to a memory error, your system proactively corrupts your data. Considering that most non ECC DIMMs have a couple errors a year, you will very likely lose data if you run ZFS on a system without ECC.

Of course, ECC doesn't fix everything, but it should halt your system if your RAM has an uncorrectable error, which is better than corrupting your files on disk.