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.
so, which direction were you attempting to move the needle?
Seems like you're putting way too much thought into something that probably won't happen, being 2022 with notifications and all. I don't justify my choices with 0.1% chances.
There's a joke about it:
Tech Enthusiasts: Everything in my house is wired to the Internet of Things! I control it all from my smartphone! My smart-house is bluetooth enabled and I can give it voice commands via alexa! I love the future!
Programmers / Engineers: The most recent piece of technology I own is a printer from 2004 and I keep a loaded gun ready to shoot it if it ever makes an unexpected noise.
But now I can see the status of the lock if I'm away from home, and I can lock it remotely if necessary. I can give out a keypad code to a house sitter. Or I can let someone in real-time from remote.
All my 'smarthome' technology at home is this way. Nothing requires the Internet to work, and if the server fails then only the automation itself stops; all of the switches, locks, and such just fail back into working like any old school switch/lock/etc.
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 actuators, although in-door actuators are available).
Battery-powered locks take one of two approaches to resolving power issues: most commonly on residential locks, there is still a key cylinder on the outside to manually lock and unlock. Less commonly on residential locks but more typical of commercial ones, there may be no key cylinder but instead an external connector that allows the programming tool (very common on commercial systems) or a 9v battery (common on residential units) to be connected to provide external power.
3. Cloud-reliant smart locks are pretty rare for practical reasons. Most are still fully functional (often minus remote control via app, but not always) without internet service. Even most commercial systems fall back to cached credentials in the door controller when the connection to the access server is lost, although annoyingly some of the newer "smarter" systems don't.
This would vary by jurisdiction, but locks without an unlock lever are usually prohibited by the fire code.
* 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.
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 tab after double clicking the entry. After closing the tab everything goes back to normal.
Does anyone know why or what downdetector/facebook would do that requires 100% of my CPU's resources?
PS. I have ublock origin installed. My cpu is an i9-12900K.
August 24th was the first time we saw exactly this issue in 7 years of heavy, multi-region, AWS use. So we put in place the ability to semi-automatically route around this more quickly, but we didn't fixate on it. Two data points is a line, however. (But maybe not yet a trend?)
So if there's any way they can spin it as not an outage they will try not to post it.
I'm reasonably sure they know when a service isn't functional at all.
Sadly this has become a monthly occurrence at this point. Monoculture, it turns out, is a really really bad idea.
-----------------------------------------------
error: No response body.
code: 30000
context:
query: 1154965
location: xen_aws_credentials_mgr.cpp:403
process: padbmaster [pid=15893]
-----------------------------------------------I'm still amazed at the number of cults that place a specific date on the return of the savior, and even more by the people that go along with the rescheduling. The fact that I'm still waiting in Dallas for JFK's return is irritating. /s
Like what's wrong with on-prem? Lack of diesel generators? We could just have that without AWS. Bare metal datacenter. Counter to most opinions, I think managing a server isn't that difficult. I am sort of a semi-professional and prosumer that has no trouble managing servers for years on end with less downtime than a whole fricking datacenter.
There is more serious discussion and new revelations around this [1], [2]. Sometimes it is hard to ask questions about layers of abstractions that have built up and no one dares to think about getting rid of them.
[1] https://www.economist.com/business/2021/07/03/do-the-costs-o...
If you're a large multinational, you basically face the same threats as Google/AWS/MSFT but there's no way you can hire, train and keep as good a production security team as them (well maybe better than Azure, but I digress).
You can't afford the upfront contractual / capital costs to maintain datacenters in every region.
And finally you can't afford the armies of lawyers and compliance engineering teams to try and reason about your data residency and things like GDPR and CCPA.
In other words, you're mostly paying for production security / privacy incident response, compliance (lawyers) and datacenters.
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.
Our first canaries fired for this at 9:43 PDT local time. The status page updated at 10:13.
[10:13 AM PDT] [10:10 AM PDT] We are investigating increased error rates for invokes in the US-WEST-2 Region.
AWS AppSync AWS Batch AWS Certificate Manager AWS Cloud9 AWS CloudShell AWS Device Farm AWS Global Accelerator AWS Greengrass AWS IoT 1-Click AWS IoT Device Management AWS Lambda AWS Proton AWS Resource Access Manager AWS RoboMaker AWS Service Catalog Amazon AppStream 2.0 Amazon CloudWatch Amazon Connect Amazon Elastic Compute Cloud Amazon Elastic Container Registry Amazon Elastic MapReduce Amazon EventBridge Amazon FinSpace Amazon Kendra Amazon Lightsail Amazon Location Service Amazon Managed Workflows for Apache Airflow Amazon Nimble Studio Amazon Pinpoint Amazon SageMaker Amazon WorkSpaces EC2 Image Builder
I was just investigating this degradation in service for some of my systems for about 1 hour before seeing this alert raised.
Database error: [Amazon](500310) Invalid operation: No response body.
Database error: [Amazon](500310) Invalid operation: curlCode: 28, Timeout was reached
in our logs during the last hour
> While we have seen improvements in error rates since 10:40 AM PDT, recovery has stalled and we do not have a clear ETA on full recovery. For customers that have dependencies on API Gateway and are experiencing error rates, we do not have any mitigations to recommend to address the issue on the customer side.
EDIT: I see now that it's an API Gateway issue, so that's why my team isn't impacted.
Usually you pick this for stuff that is CDN oriented and front a regional service with that.
Edit to add: I can't seem to access my NHL Season Tickets via Ticketmaster either...