You can’t run vmalert without flags
Running grep without parameters is also pretty fucking useless.
500 words in to the over 3,000 word dump, I gave up.
Claims to have a Unix background, doesn’t RTFM.
Nobody really uses Kubernetes for day-to-day work, and it shows. Where UNIX concepts like files and pipes exist from OS internals up to interaction by actual people, cloud-native tooling feels like it’s meant for bureaucrats in well-paid jobs.
Translation: Author does not understand APIs.
Want an asynchronous, hierarchical, recursive, key-value database? With metadata like modified times and access control built-in? Sounds pretty fancy! Files and directories.
Ok. Now give me high availability, atomic writes to sets of keys, caching, access control…
I’m ashamed enough that I can’t really apply to these jobs
This reads as “I applied to the jobs and got rejected. There’s nothing wrong with me, so the jobs must be broken”.
Running grep without parameters is also pretty fucking useless.
The difference is grep is a simple tool that can take in text, transform it, and output it to a console. It operates in a powerful and easy to understand way by default (take in text and print lines in the text containing the search parameters). This vmalert tool is just an interface to another, even more complicated piece of software.
Claims to have a Unix background, doesn’t RTFM.
Since when do Unix tools output 3,000 word long usage info? Even GNU tools don’t even come close…
Translation: Author does not understand APIs.
The point is that these abstractions do not mesh with the rest of the system. 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. It does make sense to develop things this way, though, if you’re a corpo web company trying to manage ad-hoc grids of Linux systems for your own profit rather than trying to further the development of the base system.
Ok. Now give me high availability
I would hope the filesystems you use are “high availability” lol
atomic writes to sets of keys
You’re right, that would be nice. Someone should put together a Plan 9 fileserver that can do that or something.
caching, access control
Plan 9 is capable of handling distributed access controls and caching (even of remote fileservers!). There’s probably some Linux filesystems that can do that too.
In the end, it’s not so much about specific tools that can accomplish this but that there are alternatives to the dominant way of doing things and that the humble file metaphor can still represent these concepts in a simpler and more robust way.
This reads as “I applied to the jobs and got rejected. There’s nothing wrong with me, so the jobs must be broken”.
This is the maybe the worst way of interpreting what they said. They can come and correct me if I’m wrong but I read that as: they have a particular ideological objection to this “cloud” ecosystem and the way it does things. It’s not a lack of skill as your comment implies but rather a rejection of this way of doing things.
Since when do Unix tools output 3,000 word long usage info? Even GNU tools don’t even come close…
man bash clocks in on about 43.000 words, just FYI
True, but a man page is a different thing from a tool’s built-in usage information.
Since when do Unix tools output 3,000 word long usage info? Even GNU tools don’t even come close…
[zlatko@dilj ~/Projects/galactic-bloodshed]$ man grep | wc -w
4297
[zlatko@dilj ~/Projects/galactic-bloodshed]$ man man | wc -w
4697
[zlatko@dilj ~/Projects/galactic-bloodshed]$
This is more along the lines I was thinking.
I think the parent comment went ad hominem rather than trying to understand some of the difficulties I brought up. I’m not sure whether engaging with them would be productive.
I’m glad I at least got closer to understanding your criticism than they did.
Don’t let anyone tell you you’re old or naive or “stuck in the past” for thinking these things! There is a real crisis in the operating systems world that your criticism is reflecting. It takes an army of software engineers and billions of dollars to keep this ecosystem and these systems going and they still struggle with reliability and security. The reason it’s like this is an issue of economic organization.
We can’t go back to the old way of doing things but we can’t keep maintaining these fundamentally flawed systems either. You may find something inspiring in this brief presentation by Rob Pike: http://doc.cat-v.org/bell_labs/utah2000/
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, out 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.
You just said that this software was much more complex than Unix tools.
That’s the problem. The reason Unix became so popular is because it has a highly integrated design and a few very reused abstractions. A lot of simple parts build up in predictable ways to accomplish big things. The complexity is spread out and minimized. The traditional Unix way of doing things is definitely very outdated though. A modern Unix system is like a 100 story skyscraper with the bottom 20 floors nearly abandoned.
Kubernetes and its users would probably be happier if it was used to manage a completely different operating system. In the end, Kubernetes is trying to impose a semi-distributed model of computation on a very NOT distributed operating system to the detriment of system complexity, maintainability, and security.
Until you need authentication, out of the box libraries, observability instrumentation, interoperability… which can be done much more easily with a mature communication protocol like HTTP.
I agree that universal protocols capable of handling these things are definitely useful. This is why the authors of Unix moved away from communication and protocols that only function on a single system when they were developing Plan 9 and developed the Plan 9 Filesystem Protocol as the universal system “bus” protocol capable of working over networks and on the same physical system. I don’t bring this up to be an evangelist. I just want to emphasize that there are alternative ways of doing things. 9P is much simpler and more elegant than HTTP. Also, many of the people who worked on Plan 9 ended up working for Google and having some influence over the design of things there.
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…
A filesystem does not exclusively mean an on-disk representation of a tree of files with a single physical point of origin. A filesystem can be just as “highly available” and distributed as any other way of representing resources of a system if not more so because of its abstractness. Also, you’re “disappointed” in me? Lmao
They can, and they still do… Inside the container.
And how do you manage containers? With bespoke tools and infrastructure removed from the file abstraction. Which is another way Kubernetes is removed from the Unix way of doing things. Unless I’m mistaken, it’s been a long time since I touched Kubernetes.
because rejecting a way of doing things based on preconception is a lack of flexibility
It’s not a preconception. They engaged with your way of doing things and didn’t like it.
in cloud ecosystems that translates to a lack of skill.
By what standard? The standard of you and your employer? In general, you seem to be under the impression that the conventional hegemonic corporate “cloud” way of doing things is the only correct way and that everyone else is unskilled and not flexible.
I’m not saying that this approach doesn’t have merits, just that you should be more open-minded and not judge everyone else seeking a different path to the conventional model of cloud/distributed computing as naive, unskilled people making “bad-faith arguments”.
You just said that this software was much more complex than Unix tools
Probably need to keep in mind incidental versus essential complexity here.
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?
Because this is how much of what we use already is implemented. Significant effort goes in to portability, interoperability and balancing compromises. When I’m doing software development e.g. writing HTTP APIs (of which I apparently know nothing about ;) ) - I feel like I’ve got a responsibility to carefully balance what I expose as some user-configurable thing versus something managed internally by the application. Sometimes, thankfully, the application doesn’t even have to think about it al all - like what TCP flags to set when I dial some service.
You bring up containers which is a great example of some cool features provided by the Linux kernel to solve interesting problems. If you’re interested, have a look at FreeBSD’s Jails, Plan 9 and LXC. Compare the interface to all these systems, both at the library level and userspace, and compare the applications developed using those systems. How easy is it to get going? How much do I need to keep in my head when using these features? Docker, Kubernetes, and the rest all have made different tradeoffs and compromises.
Another one I think about is SQLite. Some seriously clever smarts. Huge numbers of people don’t know anything about for-loops, C, or B-Trees but can read & write SQL. That’s technology at its best.
Consider how difficult it could be to, say, start a car in all the different operating conditions it is expected to be used in. But we never think about it.
We as tech people pride ourselves on familiarity with esoteric detail, but it doesn’t need to be like this. Nor does memorising it all have anything to do with “skill”.
What I’m struggling with are thoughts of significant vested commercial interest in exposing this kind of detail, fuelling multi-billion dollar service industries. Feelings of being an outsider despite understanding how it all fits together.
It is a pluggable service that connects to one or more TSDBs, performs periodic queries, and notifies another service when certain thresholds are exceeded.
Have you ever written this kind of software before?
It sounds like you are comfortable with the status quo of this part of the software industry, and I’m truly jealous! If you’ve got any tips on dealing with this kind of stuff you can find my email at https://www.olowe.co/about.html Thanks :)
I’ve struggled with many of the same tools. What we need is real distributed operating systems, like Plan 9, not increasingly complicated hacks and kludges to keep old-world operating systems relevant in a networked world.
hating on k8s is very in vogue currently. simpler systems like ECS exist and are really good too.
anybody bitching too hard about the tools today isn’t remembering 10 years ago correctly.
