Flags have always been poorly standardized outside of system apps and tools. Generally, -u should equal --update (and depending on how the app was written, may warn for --up: “Did you mean --update?”) Single tick flags are generally combinable: -ua or -ls. I have seen long single tick flags somewhere, but can’t remember where. (Your -update example.) Various python libraries than handle flags have helped a ton with getting people to use the same patterns, so that is nice.
You just summed up my first experience with systemd many years ago.
systemctl != sysctl. Both somehow got wedged into the same index in my brain and took years for me to correct. On top of that, <service> <action> was reversed to <action> <service>. (Or was it the other way around?)
I was convinced from my first experience with systemd that the person who wrote it was the purest form of evil. (It’s leveled out a bit over the years, so it’s tolerable to use these days. Still not a fan though.)
Also, it depends on the problem you are trying to solve and if the good deal lets you buy plenty of spare drives.
I have a 3 server cluster running 9 k8s nodes with persistent storage in Longhorn. While it thrashes the drives a bit more and I lose performance, I opted to use hardware RAID so a drive rebuild would be much easier. (I think with Ceph, it’s a step or two more to kick a drive out of the storage pool before you can swap the drive safely. The fact that I can’t remember much about Ceph already and it’s only been a month or two since I setup a Ceph testing cluster should alone explain my decision.)
Basically, I get volume replication backed by easy to manage and affordable drive replacements. I even get mirrored boot drives too. The setup is fault tolerant to a degree and it gives me enough time to shuffle things around if a server starts to die completely.
All the drives are used and have already had a full life, but yey, the risk is ok because the parts are cheap. I’ll probably buy another refurbished server of the same type just for the spare parts, drives and memory. I could even just use the extra server as a cold standby. Whatevers.
The cluster isn’t critical, to be perfectly honest. It really just holds a massive tool suite of containers that I need at random times and now I at least have solid templates and ansible confogs for all of those containers anyway. Even the data isn’t super critical.
Parts are cheap and my setup allows for disposable drives in a setup where risk tolerance is sky-high.
My NAS is RAID 10 with brand-new drives and read/write cycles are conserved. I care about that data and will probably mirror that storage that to an additional pair of mirrored m.2’s to absorb most of the read a cycles while adding an additional redundancy layer. (The hdds would primarily only see write cycles and probably just function as an incremental backup location for specific folders off of the m.2’s.)
Those are the cliff notes, and only I attempted to explain how I thought about risk in my setup. Volume over quality for my cluster: I think about fast recovery and how I can parch around a problem during a catastrophic failure. Long term: Multiple layers of redundancy for important data with less concern about price but I have less capacity and speed.
Having spent years around lots of equipment, I view a flashy red light on an HDD as a suggestion to do something about it in a couple of days if the server is just a worker node. (I have been desensitized to most hardware faults, TBH.)