Obvious but good to get confirmation. Anyone who's owned a dog knows that they can tell your mood in myriad ways, but this is the kind of basic research that is necessary to clear the way for more serious insights.
I am a Site Reliability Engineer (SRE), Google Style, with experience at both large and small organizations. I can help you build a Platform Engineering practice from the very beginning. I'm looking to help small dev teams increase their velocity by implementing best-practices of Devops: CI/CD, Kubernetes Deployments, and effective Monitoring frameworks.
I'm particularly selling my skills in PKI/TLS. My clients are rapidly moving to MTLS for all service-to-service authentication and even for browser-to-service authentication for internal tools.
The problem with these short pithy urls is that their lifetime is limited - there's only so many initiative names and they're going to collide and be removed and replaced.
Cool uris don't change[1]. Short, readable uris are great but they should be merely redirecs, and the mapping should be version controlled and exposed to the public as an immutable history.
The public doesn't need an immutable history of URLs, they need URLs they can freaking type. When you've got pages people actually care to go to, then you can create your museum of URLs.
The lifetime of the programs they link to is also limited. There's no earthly reason, when running a website in 2026, to care what Tim Berners-Lee thought about the aesthetics and purposes of URLs in 1998. It's a nice nostalgia session, but "cool urls don't change" is ironically short-sighted and has lead to well-meaning dolts embedding GUIDs and other such constructs into them. The entire concept was posited prior to the advent of on-screen phone keyboards, which make typing long heavily-punctuated urls a pain in the ass. There are a thousand reasons to salute this document and let it recede into the mists of time.
A municipal website should be useful to the citizens who want to use it. This is a great example of doing something useful with the web.
Ha! That is genuinely confusing for a moment. What is the solution? Wipe the account and archive it all somewhere? That destroys all the meta-commentary that exists in other Tweets. Maybe just some system that lets you mark all previous posts with something that says "This account is for a government official. This post was made under the tenure of a prior holder of this position."
Easily solved by adding an interstitial whenever a URI becomes replaced and is therefore no longer immutable, and showing the history of what it used to point to as well (in case you're coming along from an old link). By default, after 5 seconds, it could redirect to the current destination.
You've got a point, a fuck-up and a fuck-you are somewhat different in this context, though I was assuming both had malice in my original interpretation.
The alternative is Prometheus (which is freaking great) and Jaegar (which is freaking great), each alone. This is better, because Otel is trying to put two distinct things (monitoring and metrics, distributed tracing) into one package, because they know how to use neither.
Neither Prometheus metrics nor Jaeger traces are magic bullets. Neither of them are complicated, either, and in fact the fact that they're not complicated is their greatest strength. You can and should understand every facet of what they entail. You should build the (very small) shims that they need for your company's framework every time. It's not hard. It's not hard because it's not complicated. The fact that it's not complicated seems to break people's brains. They are accurate because they're simple and they're easy to work with because they're simple, and OTel is neither.
Prometheus is so easy to add and if you need more scale, there is mimir and a few other options with similar client semantics. I really can't imagine reaching for a framework APK that tries to anticipate every possible thing I would want telemtered, and is inevitably missing all the domain specific derived channels I need. Even prepackaged Prometheus exporters are usually overkill.
Hard Agree on Prometheus. And esp on the complexity - OTel is dizzyingly complex. You can get started ASAP on Prometheus whereas you get lost in analysis-paralysis when dealing with OTel.
I don't even have a problem with every cop being equipped with an automatic ALPR... So long as the data is not retained. I do believe that we need better auditing and oversight in response to the availability, but it's not a great evil that an APB can be virtually guaranteed to catch a car... So long as we're using them carefully and judiciously, in response to immediate and recent threats or a clearly understood long tail. There's supposed to be a balance of power; it's not evil to give the police new powers, but it is evil to give politicians unanswered and unlimited tracking of the movements of anyone they so desire.
The primitives of a tpm ("observations", which in practice map to ca-signing keys of various levels of boot stage) are a very poor match for the real world. In order for them to be usefully consistent, you have to have consistent inputs. That means you can't observe the kernel itself, but instead you observe a key that signs a kernel. This is awful when it's Microsoft signing a series of kernels that advance one-way but the TPM doesn't actually ratchet to prevent downgrade attacks (and would be even worse if it did, because then you'd inevitably brick machines again and again). Instead you trust a long-lived CA and God help you when you need to rotate it.
It's even worse if you're self-hosting the signing, to the point that despite a ton of work put into making it safe and understood I wouldn't do it with the current design; a bare-state unlock is more predictable and reliable but I'll make sure to regularly exercise my backup key and header.
I am a Site Reliability Engineer (SRE), Google Style, with experience at both large and small organizations. I can help you build a Platform Engineering practice from the very beginning. I'm looking to help small dev teams increase their velocity by implementing best-practices of Devops: CI/CD, Kubernetes Deployments, and effective Monitoring frameworks.
I'm particularly selling my skills in PKI/TLS. My clients are rapidly moving to MTLS for all service-to-service authentication and even for browser-to-service authentication for internal tools.
reply