> running apps that are mandatory to participate in modern society
This right here is why I no longer consider custom ROMs. My phone is a tool critical to my daily life and I need it to function correctly nearly 100% of the time. Custom ROMs never really reach that bar in my experience.
Also, the various forms of attestation allow corporations the power to punish me for having the temerity to modify my own property. Yet another way the tech industry has metastasized into a societal cancer.
Yeah, I am always going to interpret that sort of thing as performative. There seems to be whole corporate mythology that is absolutely sure there are a bunch of cheap, low-effort things managers can do to raise morale and get more productivity out of employees, like office birthday parties. I propose a name for adherents to this philosophy: the Pizza Party Cult.
Yes. I have a family member that has had many hospital stays over the last few years, and one of the most obnoxious things is that the staff just lets everything beep. The last time we were in the emergency room the blood pressure monitor did not work and the staff didn't notice for over an hour. Even when it does work, they're constantly in an alarm state because patient has chronic high blood pressure. They either can't or won't silence the alarms, so every room is beeping, the nurse's station is beeping, their phones are beeping, and it's all being ignored. It's the very definition of alert fatigue.
I've noticed that for some reason developers really like using logs in place of actual metrics. We use Datadog, and multiple times now I have seen devs add additional logging to an application just so they can then create a monitor that counts those log events. I think it's a path of least resistance thing; emitting logs is very easy, and counting them is also very easy. Reporting actual metrics isn't really difficult either, but unless you're already familiar with the system it's more effort to determine how to do it than just emitting a log line, so yeah.
I like most of these patterns and have used them all before, but a word of caution using UUID primary keys: performance will suffer for large tables unless you take extra care. Truly random values such as UUIDv4 result in very inefficient indexing, because values don't "cluster." For databases, the best solution is to use a combination of a timestamp and a random value, and there are multiple implementations of UUID-like formats that do this. The one I'm familiar with is ULID. It's become a common enough pattern that UUIDv7 was created, which does exactly this. I don't know if it's possible to generate UUIDv7 in Postgres yet.
Maybe some people don't remember anymore, but there was a time when Ruby was HN's favorite language. I miss those days. I kind of get why everybody leaned into Python instead, but I'm never going to be happy about it.
If you manage to avoid scope creep then sure, static YAML has advantages. But that's not usually what happens, is it? The minute you allow users to execute an outside program -- which is strictly necessary for a CI/CD system -- you've already lost. But even if we ignore that, the number of features always grows over time: you add variables so certain elements can be re-used, then you add loops and conditionals because some things need to happen multiple times, and then you add the ability to do math, string manipulation is always useful, and so on. Before you know it you're trying to solve the halting problem because your "declarative markup" is a poorly specified turing-complete language that just happens to use a YAML parser as a tokenizer. This bespoke language will be strictly worse than Python in every way.
My argument is that we should acknowledge that any CI/CD system intended for wide usage will eventually arrive here, and it's better that we go into that intentionally rather than accidentally.
> The Fix: Use a full modern programming language, with its existing testing frameworks and tooling.
I was reading the article and thinking myself "a lot of this is fixed if the pipeline is just a Python script." And really, if I was to start building a new CI/CD tool today the "user facing" portion would be a Python library that contains helper functions for interfacing with with the larger CI/CD system. Not because I like Python (I'd rather Ruby) but because it is ubiquitous and completely sufficient for describing a CI/CD pipeline.
I'm firmly of the opinion that once we start implementing "the power of real code: loops, conditionals, runtime logic, standard libraries, and more" in YAML then YAML was the wrong choice. I absolutely despise Ansible for the same reason and wish I could still write Chef cookbooks.
This right here is why I no longer consider custom ROMs. My phone is a tool critical to my daily life and I need it to function correctly nearly 100% of the time. Custom ROMs never really reach that bar in my experience.
Also, the various forms of attestation allow corporations the power to punish me for having the temerity to modify my own property. Yet another way the tech industry has metastasized into a societal cancer.