shakedown.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
A community for live music fans with roots in the jam scene. Shakedown Social is run by a team of volunteers (led by @clifff and @sethadam1) and funded by donations.

Administered by:

Server stats:

261
active users

#reliability

0 posts0 participants0 posts today

I really liked this informal community poll and thematic analysis on SLO usage. It does a better job at highlighting the hurdles to adopting them at a Company Who Is Not Google than a lot of "Here's how to do SLOs" pieces that just don't cover it.

If there is ever a "Seeking SLOs" book, this should be the first chapter.

ericmustin.substack.com/p/note

A Small, Good Thing · Notes on Service Level ObjectivesBy Eric Mustin
Continued thread

Update. From @hildabast: "What if We Can’t Rely on PubMed?"
absolutelymaybe.plos.org/2025/

"#PubMed is incredibly reliable…That said, between the risks of an exodus of key personnel, understaffing, or goodness-knows-what vandalism when a goon squad arrives at NIH, it’s not paranoid any more to think ahead to the once-unthinkable. What would PubMed enshittification look like? Could PubMed go down more often, and for longer? Might services no longer be free? How else could the #quality and #reliability of its services be degraded?"

Absolutely Maybe · What if We Can't Rely on PubMed? - Absolutely MaybePubMed is incredibly reliable. And a lot depends on it. It’s an ecosystem built around MEDLINE, the steady feed of new publications…

Having a little discussion about our passionate view of things in the DevEx team I'm on and I offered this:

"studying Resilience Engineering saved my life, there's no doubt about it. there is so much good to be had from RE that i want to share with the world. i hope that we can get closer to RE practices here. not because i want to show i've done it, i don't care about resume filling. but to show people there's a better way. it takes care of humans and is more curious about the system. fix errors, but also discover insight."

I need to rant. Maybe I have a few Resilience friends out there who can sympathize.

It's not OK to cut people off from complexity.

First of all, it's insulting. The action infuses itself with distrust. It is some sort of disgusting us-vs-them holdover from like 2005.

Second of all, the dogma of "the developer sits and works on their little piece and knows nothing about what goes on around them" doesn't work anymore. Interactions matter, sharing knowledge matters, working together to understand each other's limitations and where we can find adaptive capacity, that all matters. It's not stuff you can put on a pre-flight checklist or a runbook, it's relationship building.

When we build relationships across the boundaries of the technologies we're building, we learn how to see the interactions between them. If we are only on one side of the equation, we're missing the interaction. And that's where the learning happens, witnessing how the system interacts and updating our mental models.

When we share this activity, we form a more complete picture of the system between a more broadly trained set of people. We discover new ways of doing things because new perspectives are added. Diversity makes these interactions come alive.

So when leaders pull out their managerspeak dialectic and say to me "devs don't need to know anything about the orchestration system" ... that isn't what I'm hearing.

I'm hearing: "Control and simplification is more important than learning."

Replied in thread

@sodiboo I have similar motivations, abeit more practical:

sodiboo's shitposting sanctuarysodiboo :pride_heart: (@sodiboo)@kkarhan@infosec.space Yes, I get that they aren't literally designed to be black boxes whose inner workings are fully opaque, and I agree with you that it sure would be simpler to use such a solution for the practical purpose of having a working networking setup. But for the purpose of *understanding what that networking setup is doing under the hood*, such an "applianced solution" only serves to abstract away the very thing I'm trying to understand. It's like trying to understand, really understand and "get" manual memory management and CPUs and such when all you've worked with is C# and the .NET runtime. That was me at one point. You know what that led to? I learned CIL, know a *hell of a lot* about .NET, but I'm also now using Rust for new projects because it's just *more comfortable for me* and doesn't hide these details from me. In this analogy, the .NET runtime is the Tailscale or pfSense, which actively does obscure these details from me as a user. That's like half the point. You shouldn't need to understand the things they abstract in order to use them. But this isn't about practicality. I don't want my network setup to "just work". I want to understand how it works, why it works. Then I can maybe do more exotic things I couldn't before (in the .NET analogy, the exotic purposes are a lot of runtime fuckery with Mono.Cecil and HarmonyX), and I might even decide that I just *prefer not using the managed option*. Manually configuring stuff isn't practical to the end of making my network work at all. But believe it or not, I use NixOS. I actually find that stuff *fun*. If I didn't, I'd just use Windows. The same core concept is why I switched from Windows to begin with. RE: @sodiboo@gaysex.cloud they ain't black-boxes per-se: You can just look into the config.files generated and modify them at will. Tho if you really want to learn how #Networking works you gotta build yourself a <i>"#HomeLab"</i> or somethibg where you can <i>"fuck around and find out"</i> in a Sandbox trying out stuff... All these solutions, regardless if #Linux #Kernel or #pfSense have extensive documentation: So feel free to look into those... Manually configuring stuff is always an option, I just discourage those out of simplicity and because that may result in configuration conflicts.which most <i>"applianced"</i> solutions will just flat-out prevent you from setting up as they tend to check if a config can eben work at all... Bit if you want to dive very deep: The [documentation for the Linux Kernel](https://docs.kernel.org) is the way to go! RE: ...