this post was submitted on 10 Oct 2023
42 points (76.9% liked)
Programming
17446 readers
188 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Running grep without parameters is also pretty fucking useless.
Claims to have a Unix background, doesn't RTFM.
Translation: Author does not understand APIs.
Ok. Now give me high availability, atomic writes to sets of keys, caching, access control...
This reads as "I applied to the jobs and got rejected. There's nothing wrong with me, so the jobs must be broken".
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.
Since when do Unix tools output 3,000 word long usage info? Even GNU tools don't even come close...
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.
I would hope the filesystems you use are "high availability" lol
You're right, that would be nice. Someone should put together a Plan 9 fileserver that can do that or something.
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 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.
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 probably did go a bit ad hominem in my last paragraph. By the time I was done with the article I was very frustrated by what seemed to be some very bad faith arguments (straw man, false dilemma) that were presented.