The research about open source developers using ai coding merits a deeper read - it is actually fascinating - they were doing worse, but felt that they have been more productive.

heh, muditą :)

manau, kad meta ne vienintelė tokia „gudri“ - kiti irgi naudojasi visomis įmanomomis spragomis, tik dar jų neaptiko/nepaviešino.

I understand your point, but I would not imply that a backdoor has to be remote. Backdoors are essentially any alternative, often undocumented ways to access or gain privileges on systems. They don’t always result from malicious intent either - many backdoors simply “happen” when developers haven’t fully considered security implications. For the average user whose device contains such unintentional backdoors, the impact remains the same regardless of how they came to exist. Consider the times when vendors had default BIOS passwords - these created a nightmare for Uni IT staff (and others as well), even though they were not accessible remotely.

From security perspective, do you think the wording changes a lot here?

tst

no, no and no, but you will have to find an answer if your decision to have or not to have kids was the right choice in any case.

Būtų įdomu paskaityt tai kas ten iš tiesų įvyko ir kaip buvo tvarkoma, bet turbūt Cloudflare lygio post-mortem analizės tikėtis neverta.

What about it? ;)

Not anymore, nowadays, I feel guilty reading non-fiction and understand Lindy effect on books much better (be it fiction or non-fiction).

They cut all such scenes and pasted into The Boys, in a Mark Twain style “Sprinkle these around as you see fit!”.

I liked the book as well. The show had some similar feeling in some ways, but also had a distinct character for itself.

A Tomb for Boris Davidovich - Danilo Kiš

no

Reread today again, with some highlights:

Lessons Learned from Twenty Years of Site Reliability Engineering

Metadata

• Author: sre.google
• Category: article
• URL: https://sre.google/resources/practices-and-processes/twenty-years-of-sre-lessons-learned/

Highlights

The riskiness of a mitigation should scale with the severity of the outage

We, here in SRE, have had some interesting experiences in choosing a mitigation with more risks than the outage it’s meant to resolve.

We learned the hard way that during an incident, we should monitor and evaluate the severity of the situation and choose a mitigation path whose riskiness is appropriate for that severity.

Recovery mechanisms should be fully tested before an emergency

An emergency fire evacuation in a tall city building is a terrible opportunity to use a ladder for the first time.

Testing recovery mechanisms has a fun side effect of reducing the risk of performing some of these actions. Since this messy outage, we’ve doubled down on testing.

We were pretty sure that it would not lead to anything bad. But pretty sure is not 100% sure.

A “Big Red Button” is a unique but highly practical safety feature: it should kick off a simple, easy-to-trigger action that reverts whatever triggered the undesirable state to (ideally) shut down whatever’s happening.

Unit tests alone are not enough - integration testing is also needed

This lesson was learned during a Calendar outage in which our testing didn’t follow the same path as real use, resulting in plenty of testing… that didn’t help us assess how a change would perform in reality.

Teams were expecting to be able to use Google Hangouts and Google Meet to manage the incident. But when 350M users were logged out of their devices and services… relying on these Google services was, in retrospect, kind of a bad call.

It’s easy to think of availability as either “fully up” or “fully down” … but being able to offer a continuous minimum functionality with a degraded performance mode helps to offer a more consistent user experience.

This next lesson is a recommendation to ensure that your last-line-of-defense system works as expected in extreme scenarios, such as natural disasters or cyber attacks, that result in loss of productivity or service availability.

A useful activity can also be sitting your team down and working through how some of these scenarios could theoretically play out—tabletop game style. This can also be a fun opportunity to explore those terrifying “What Ifs”, for example, “What if part of your network connectivity gets shut down unexpectedly?”.

In such instances, you can reduce your mean time to resolution (MTTR), by automating mitigating measures done by hand. If there’s a clear signal that a particular failure is occurring, then why can’t that mitigation be kicked off in an automated way? Sometimes it is better to use an automated mitigation first and save the root-causing for after user impact has been avoided.

Having long delays between rollouts, especially in complex, multiple component systems, makes it extremely difficult to reason out the safety of a particular change. Frequent rollouts—with the proper testing in place— lead to fewer surprises from this class of failure.

Having only one particular model of device to perform a critical function can make for simpler operations and maintenance. However, it means that if that model turns out to have a problem, that critical function is no longer being performed.

Latent bugs in critical infrastructure can lurk undetected until a seemingly innocuous event triggers them. Maintaining a diverse infrastructure, while incurring costs of its own, can mean the difference between a troublesome outage and a total one.

This is what you get when are not sleeping during biology classes.

not a bug, but a feature :))

a source code of a game ;))

i am all for normalizing raiding ambassies for [put the cause you support] as well