Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror

+ - Nexus 6: Who's to blame for the abysmal release process?

Submitted by grahamsaa
grahamsaa (1287732) writes "I'm sure some of you are aware of the inventory problems Google has had, as well as the frustrating pre-order process. Customers can't even pre-order unless they happen to be visiting the play store when units are available, which, from what I can tell is several minutes every Wednesday.

What has Google gained by selling the phone this way? Why can't customers just get in line, pre-order a phone and get it when inventory is availble? Why didn't Google and Motorola anticipate the demand for the Nexus 6? They had similar problems with the N4 and N5, so they're either unable to learn from the past, horrible at planning for releases, or there's some hidden agenda / benefit that they get out of releasing devices this way.

Who was responsible for this release? Why was it handled this way? Why is Google making it so hard for me to give them my money?"

Comment: Overwhelm them with complaints. Use these links (Score 4, Informative) 558

by grahamsaa (#48236215) Attached to: Rite Aid and CVS Block Apple Pay and Google Wallet
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.

Comment: There is absolutely no good reason for this. (Score 4, Insightful) 558

by grahamsaa (#48235609) Attached to: Rite Aid and CVS Block Apple Pay and Google Wallet
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.

+ - Zappos proactively resets account passwords for users

Submitted by grahamsaa
grahamsaa (1287732) writes "I received an e-mail tonight stating that my Zappos password had been reset. Since I rarely use the site and don't store credit card information there, I used a throwaway password for that account. Apparently my throwaway password made it onto the the list of passwords, so Zappos proactively changed it.

Have any other sites done this to you recently? What's your stance on using an easy to remember 'throwaway' password on sites that don't have any of your sensitive data?"

Comment: Re:Legacy Support (Score 1) 730

by grahamsaa (#47865061) Attached to: Apple Announces Smartwatch, Bigger iPhones, Mobile Payments
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.

Comment: Re:Honestly, when will people learn? (Score 3, Interesting) 98

by grahamsaa (#47761483) Attached to: Project Zero Exploits 'Unexploitable' Glibc Bug
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".

Comment: Summmary seems very one sided (Score 5, Insightful) 402

by grahamsaa (#47593407) Attached to: The High-Tech Warfare Behind the Israel - Hamas Conflict
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.

Comment: Thanks for the feedback (OP response) (Score 2) 265

by grahamsaa (#47435115) Attached to: Ask Slashdot: Unattended Maintenance Windows?
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 :)

+ - Unattended maintenance windows

Submitted by grahamsaa
grahamsaa (1287732) writes "Like many others in IT, I sometimes have to do server maintenance at unfortunate times. 6AM is the norm for us, but in some cases we're expected to do it as early as 2AM, which isn't exactly optimal. I understand that critical services can't be taken down during business hours, and most of our products are used 24 hours a day, but for some things it seems like it would be possible to automate maintenance (and downtime).

I have a maintenance window at about 5AM tomorrow. It's fairly simple — upgrade CentOS, remove a package, install a package, reboot. Downtime shouldn't be more than 5 minutes. While I don't think it would be wise to automate this window, I think with sufficient testing we might be able to automate future maintenance windows so I or someone else can sleep in. Aside from the benefit of getting a bit more sleep, automating this kind of thing means that it can be written, reviewed and tested well in advance. Of course, if something goes horribly wrong having a live body keeping watch is probably helpful. That said, we do have people on call 24/7 and they could probably respond capably in an emergency. Have any of you tried to do something like this? What's your experience been like?"

Comment: Re:ZFS, Apple! (Score 1) 396

by grahamsaa (#47236271) Attached to: One Developer's Experience With Real Life Bitrot Under HFS+
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.

Our OS who art in CPU, UNIX be thy name. Thy programs run, thy syscalls done, In kernel as it is in user!

Working...