PinkSheep

It's the opposite. It might have driven the person to actual self-commit. Allow me to hypothesize on their behalf:

- the employee pulled off the impossible

- may be already burnt out or on the brink of emotional collapse

- the "jump out of window" would have been as much of a joke as it was a coping response

- the righteous language policewoman does not feel empathy to personally ask him, how he is doing

- instead, she goes to HR to report him

- this unexpected hostility breaks the camel's back and what might have been interpreted as a joke actually wasn't. Still emotionally drained and now backstabbed, the person commits.

In short: policing voice was more important than taking a potential signal seriously. How is it not a despicable behavior in this situation?

PS: I hereby permit the commenters to reprimand me for the stereotype-based guess.

...unless you marry it to a CoW fs that can let it travel back in time :)

It's all valid trade-offs until you require a confirmation of such a control command.

Don't let curiosity kill the cat, what's so bad about it? :) Is it Zigbee itself or the firmware quality? IoT without the S?

Yes, but it's a protocol oversight to have zero confirmation whether a control command was received (and applied).

Sounds like, in your case, this narrow temperature band is impossible to hit without a proper refrigerator.

PS: You have seen Alec's unbelievably detailed encounter with the cheap red refrigerator, right?

This brings up the question how much weight these people have, if don't even know what their solution should be based on.

I too would have kept it "free" for the LLM learning corpus and the way to nudge developers towards own cloud services and infrastructure. Github Actions is the first obvious deviation from vendor agnosticism here. If it's about "they didn't make profit maximization at all costs a priority" then I agree.

Sorry for the stress that the team had mitigating this attack. Yet I'm always excited to see signs of competence on the attacking side: a targeted application-specific and adaptive attack at L7? Wow!

Here's another guess: a DDoS to steal your attention and mask other intrusion attempts.

> Defenses need to have broader rate limits across more than just IPs (ASNs, hostnames, etc.).

The description/approach seems static and limited? Why not maintain a leaky bucket that counts each request (tickets/points) with higher cost for expensive requests (404, redirects). As the IP's reputation deteriorates (IPv4/32), it begins to spill over to a broader subnet like IPv4/31 then /30 and so on. Fight adaptivity with adaptivity. // maybe I describe something totally obvious, I'm not involved in the web ddos protection side of things.

> Attackers actively search for non-cacheable paths (e.g. dynamic redirects, search endpoints, and 404s).

To continue with my previous point. As long as individual server's resources permit (memory, socket limit) stall requests before processing them. Low reputation IPs get stalled for longer and the requests that exceed the queue get dropped. The idea is graceful degradation:

A good rep IP will not be stalled by sleep(). A poor rep IP will be stalled, but eventually receive its answer instead of some 429/403 (i.e. a user who opened many tabs at once). A bad rep IP will be slowed down by the wait times + rate-limits (queue exceeded) before getting completely banned for good. The point is to have more granularity before throwing errors at random users at the server-level.

You need to up your irony. The proles were reading Orwell's 1984 and thought "hey, I shouldn't mind being spied on by (smart) TVs!" because this is the statistically average behavior of the consumers.

You posted a Youtube link with a share ID tracker in it: ?si=oVqX6NtkxPmqh6R-

> On the fact that centralization is bad, we agree. DNS resolver centralization is not a great thing, and it seems to be trending in the wrong direction.

It seems all too similar to the degradation of peer-to-peer networks where nodes are replaced by few supernodes. You mentioned a couple reasons yourself: consolidation and legal pressure. Add to this the technical qualification aspect and time investment (Mullvad's position), and the financial cost of sustaining such a non-profit project. Suddenly there are very few people or even organizations worldwide, who can bear the burden.

Thank you for existing and your tireless work.

dear sockpuppet =) I think the above commenter meant illegal physical access. The jabber.ru MitM situation was likely carried out by a cybercrime unit of the German police forces with a court order... and this is the adversary most people forget about.

Lesson to learn: Let's Encrypt does not protect against MitM by a state-level actor, unless you take precautions. *let's assume network admins won't MitM your server for personal vengeance reasons