91–100 of 107 posts
Earlier quoted context omitted.
> as far as not getting out, any lock unable to be unlocked from inside seems like something should not be allowed to be made. ever. This would vary by jurisdiction, but locks without an unlock lever are usually prohibited by the fire code.
Yet they exist, with a whole industry built around them
https://downdetector.com/status/aws-amazon-web-services/ My Roomba isn't working!!! hahahaha!
On an unrelated note, I opened this url in a new tab, took a quick look, then came back to read the comments. A few minutes after I hear the fans on my pc start ramping up. Sure enough, I open the system monitor and see chrome going crazy on my CPU. In chrome, I open the task manager, then click sort by CPU. The entry at the top of the list reads: > subframe: facebook[dot]com I get taken to the open downdetector.com…
Earlier quoted context omitted.
Just a few notes: 1. I'm not aware of any smart lock that cannot be locked and unlocked manually from the inside. This would violate fire code for residential structures in a lot of US jurisdictions. 2. Electronic locks in general are either line-powered or battery-powered. Line-powered locks are unusual in residential environments because of the higher complexity of installation (they're more often strikeplates than…
I have the Nest/Yale lock without the key, it definitively is not reliant on the Nest cloud being up (or internet working) for access, only to remotely lock/unlock or to program new codes. Do any locks actually fail to work with an already programmed PIN code if the internet is out? That seems like a massive failure. Go to dinner and your router crashes and you can't get back inside to fix it? Wow.
Honest question and frankly scared to ask because it sounds stupid: if you have like 30 mins of downtime on AWS every year and spend 3x cost on managing their infrastructure risk by deploying it on multi-AZ and multi-region (and thereby AWS pushing reliability management back to the customer); is the value proposition of cloud just some dude to install a disk if it goes out on a rack in your office? May be there is a…
The company that I'm in right now has two engineers (including myself) who are building and maintaining a product that serves millions of streams a week. There's no fucking way we could have done this ourselves. One F5 would cost more than our entire total AWS bill for two years - and we'd have to have at least 4 F5s if we wanted to try to match AWS. Plus the media encoders would cost a fortune.
For some things it's fine to head over to lowendbox.com and pick up a cheap VPS hosting package. We could theoretically build our stack on top of a bunch of VPSs, sync everything with rsync, etc. But then we'd be spending time building infrastructure (which is pretty much valueless) instead of our product.
Earlier quoted context omitted.
i wonder if any smart locks are down, people being locked in or out of their AirBNBs would be pretty funny.
of all things to connect to a smart home, the locks to my house would be the absolute bottom of the list. i hate coming home when the power is out and cannot open the garage door. i couldn't imagine not being able to get in at all. as far as not getting out, any lock unable to be unlocked from inside seems like something should not be allowed to be made. ever.
Earlier quoted context omitted.
i wonder if any smart locks are down, people being locked in or out of their AirBNBs would be pretty funny.
of all things to connect to a smart home, the locks to my house would be the absolute bottom of the list. i hate coming home when the power is out and cannot open the garage door. i couldn't imagine not being able to get in at all. as far as not getting out, any lock unable to be unlocked from inside seems like something should not be allowed to be made. ever.
* Stores codes on the device itself and still unlocks with no internet connectivity * Is a physical deadbolt inside that works without power * If the lock itself runs out of battery power from the OUTSIDE, you can "jump" it with a 9-volt battery * Allows me to auto-lock after X period of time, or at night * Allows me to NEVER carry keys, ever. Or ever have to worry about keys. * Allows me to manage multiple, time-boxed codes for people (housekeeper can't get in at midnight)
It's pretty damn great, honestly. And I stow a 9-volt in a flower box in case of emergency. (You still need to know the code, obviously.)
It's also absolutely pick-proof/bump-proof because it has no key at all. Not even a backup key.
It's the Yale x Nest lock and is really really nice.
Honest question and frankly scared to ask because it sounds stupid: if you have like 30 mins of downtime on AWS every year and spend 3x cost on managing their infrastructure risk by deploying it on multi-AZ and multi-region (and thereby AWS pushing reliability management back to the customer); is the value proposition of cloud just some dude to install a disk if it goes out on a rack in your office? May be there is a…
Having managed a small data center in the past and having seen what it takes to manage multiple enterprise-scale data centers, the answer is "no, AWS does it better." The company that I'm in right now has two engineers (including myself) who are building and maintaining a product that serves millions of streams a week. There's no fucking way we could have done this ourselves. One F5 would cost more than our entire to…
Earlier quoted context omitted.
It's all networking issues as you're remotely access them remotely, so of course it's increased error rates or increased latency. When a piece of gear stops responding the network tries to self-heal as designed which causes those issues.
Well, yes, but, for example: Characterizing both a 5% error rate and a 100% error rate as "increased error rates" is not as helpful as it could be. I'm reasonably sure they know when a service isn't functional at all.
Earlier quoted context omitted.
I participated in many status page color discussions and we always discussed sla. Shrug
You mean on the AWS/service provider side? I've also participated in internal incident response on the service provider side and we again made SLA refund decisions based on actual customer impact not our status page. But then again we diligently update our status pages so there's that.