This vmalert tool is just an interface to another, even more complicated piece of software.
Not really just an interface. It is a pluggable service that connects to one or more TSDBs, performs periodic queries, and notifies another service when certain thresholds are exceeded. So with all those configuration options, why is the standalone binary expected to have defaults that may sound same on one system but insane in a different one? If the author wants out of the box configuration they could have gotten the helm chart or the operator and then that would be taken care of. But they seem to be deathly allergic to yaml, so I guess that won’t happen.
Since when do Unix tools output 3,000 word long usage info? Even GNU tools don’t even come close…
You just said that this software was much more complex than Unix tools. Also if only there were alternate documentation formats….
HTTP and REST are very strange ways to accomplish IPC or networked communication on Unix when someone would normally accomplish the same thing with signals, POSIX IPC, a simpler protocol over TCP with BSD sockets, or any other thing already in the base system.
Until you need authentication, or of the box libraries, observability instrumentation, interoperability… which can be done much more easily with a mature communication protocol like HTTP. And for those chasing the bleeding edge there’s gRPC.
I would hope the filesystems you use are “high availability” lol
They’re not, and I’m disappointed that you think they are. Any individual filesystem is a single point of failure. High availability lets me take down an entire system with zero service disruption because there’s redundancy, load balancing, disaster recovery…
the humble file metaphor can still represent these concepts
They can, and they still do… Inside the container.
It’s not a lack of skill as your comment implies but rather a rejection of this way of doing things.
Which I understand, I honestly do. I rejected containers for a (relatively) long time myself, and the argument that the author is making echoes what I would have said about containers. Which is why I believe myself to be justified in making the argument that I did, because rejecting a way of doing things based on preconception is a lack of flexibility, and in cloud ecosystems that translates to a lack of skill.
ck_@discuss.tchncs.de 1 year ago
man bash
clocks in on about 43.000 words, just FYIPaX@hexbear.net 1 year ago
True, but a man page is a different thing from a tool’s built-in usage information.
ck_@discuss.tchncs.de 1 year ago
I would disagree, or rather: it depends. You can print the --help of bash, but will that actually tell you anything about bash except a really superficial subset of flags? In the same way that the author argues that the help of his tool is too long to be useful, the help of bash is to short for the same reason. He argues that “cloud tools have a gazillion options where UNIX tools have good defaults”. Bash has a gazillion options and no good defaults. As a matter of fact, bash on defaults is fairly dangerous. Yet, it is at the heart of most Unix systems today I’d argue.
PaX@hexbear.net 1 year ago
Yeahh, you have a good point lol. Bash and the GNU ecosystem have developed their own sprawling problems.
otl@lemmy.sdf.org 1 year ago
Definitely depends, yeah.
bash
is a huge piece of software that - for me - feels a bit out of place in other systems closer to original unix. Interesting ones arerc
and even plain old/bin/sh
provided by something like busybox.zlatko@programming.dev 1 year ago