Besides what MattJ100 wrote above, by itself this is also not true. You can tell Android to not optimize Conversations and allow it to run in the background. It will work just fine with a (usually idle) TCP connection. But for the typical user, having to instruct them to do this is cumbersome, and integrating with Firebase is easier. It does come with its own concerns w.r.t. privacy, both for the payload as well as metadata exchanged.
Interesting. Most income graphs I've seen appear to be normally distributed -- could you explain what would cause them not to be, or provide any examples that demonstrate non-Gaussian distributions?
But if wages are non-Gaussian, how would trimming the top and bottom 5% off of your sample be any better than using standard deviation ranges to control for outliers? The assumption that outliers are to be found on the top and bottom of your range is one that seems to apply to Gaussian distributions, and doesn't necessarily hold for others, regardless of whether you are using fixed percentage values or standard deviation thresholds. For example, in a bimodal distribution, outliers might be found in the center.
Hence the suggestion for PagerDuty. It handles all this, because responders set their notification methods (phone, SMS, e-mail, and app) in their profiles, so that when in trouble nobody has to ask those questions and just add a person as a responder to the incident.
Yes, but Facebook is not a small company. Could PagerDuty realistically handle the scale of notifications that would be required for Facebook's operations?
PagerDuty does not solve some of the problems you would have at FB's scale, like how do you even know who to contact ? And how do they login once they know there is a problem ?
The place where I worked had failure trees for every critical app and service. The goal for incident management was to triage and have an initial escalation for the right group within 15 minutes. When I left they were like 96% on target overall and 100% for infrastructure.
Even if it can’t, it’s trivial to use it for an important subset, ie is Facebook.com down, is the ns stuff down etc. So there is an argument to be made for still using an outside service as a fallback
- not arrogant
- or complacent
- haven't inadvertently acquired the company
- know your tech peers well enough to have confidence in their identity during an emergency
- do regular drills to simulate everything going wrong at once
Lots of us know what should be happening right now, but think back to the many situations we've all experienced where fallback systems turned into a nightmarish war story, then scale it up by 1000. This is a historic day, I think it's quite likely that the scale of the outage will lead to the breakup of the company because it's the Big One that people have been warning about for years.
I guarantee you that every single person at Facebook who can do anything at all about this, already knows there's an issue. What would them receiving an extra notification help with?
We kind of got off topic, I was arguing that if you were concerned about internal systems being down (including your monitoring/alerting) something like pager duty would be fine as a backup. Even at huge scale that backup doesn’t need to watch everything.
I don’t think it’s particularly relevant to this issue with fb. I suspect they didn’t need a monitoring system to know things were going badly.
As far as I know, Facebook Messenger's XMPP support was only exposed to clients (c2s), not to other XMPP servers (s2s). Microsoft's Lync (now known as Skype for Business) supported XMPP federation until 2019. WhatsApp's client protocol was originally based on XMPP. I'm reasonably sure that both AIM and Yahoo had XMPP server-to-server support ready around 2008, but can offer no proof.
Doesn’t mean they can’t do anything about the noise, just that they can’t do it on the server.
The RNNoise link from the bottom of that post runs the noise suppression in real time in JavaScript. Zoom et al. could do this client side while still doing proper E2E. (Although Zoom already uses more cou that I think it needs to...)
Yup, and the old bridge will keep working locally, still has an open API, and there was an upgrade program when v2 was introduced, with a 33% discount. Four or so years ago.
They gave me a pretty good upgrade deal just a month ago: a new v2 router with a lightbulb for under $60 Canadian ($45 US, now). This was offered to me somewhere in the iOS app when I was checking for updates. It took a while to ship (came from Europe for some reason), but I consider it a good deal, and have no regrets about buying the v1 router when I got it. The old bulbs work with the new router, though not as smoothly as the new bulb.
