Comment on My struggle from a UNIX background in the modern "cloud" world

boblin@infosec.pub ⁨11⁩ ⁨months⁩ ago

• JWBananas@startrek.website ⁨11⁩ ⁨months⁩ ago

  Nobody really uses Kubernetes for day-to-day work, and it shows.

  Wat.

  source

  • boblin@infosec.pub ⁨11⁩ ⁨months⁩ ago

    Literally copied and pasted that from the article.

    source

    • JWBananas@startrek.website ⁨11⁩ ⁨months⁩ ago

      I know. I’m responding to the absurdity of it.

      source
• PaX@hexbear.net ⁨11⁩ ⁨months⁩ ago

  Running grep without parameters is also pretty fucking useless.

  The difference is grep is a simple tool that takes in text, transforms it, and outputs 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.

  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.

  source

  • ck_@discuss.tchncs.de ⁨11⁩ ⁨months⁩ ago

    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

    source

    • PaX@hexbear.net ⁨11⁩ ⁨months⁩ ago

      True, but a man page is a different thing from a tool’s built-in usage information.

      source

      • ck_@discuss.tchncs.de ⁨11⁩ ⁨months⁩ 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.

        source

        • -> View More Comments
    • zlatko@programming.dev ⁨11⁩ ⁨months⁩ ago

      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]$ 
      

      source
  • boblin@infosec.pub ⁨11⁩ ⁨months⁩ ago

    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.

    source

    • otl@lemmy.sdf.org ⁨11⁩ ⁨months⁩ ago

      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 www.olowe.co/about.html Thanks :)

      source

      • boblin@infosec.pub ⁨11⁩ ⁨months⁩ ago

        Probably need to keep in mind incidental versus essential complexity here.

        Go on…

        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.

        In the case of vmalert, the binary makes no assumptions as to default behaviour because it was not meant to be run standalone. It comes as part of a container with specific environment variables, which in turn is packaged as a Helm chart which has sane configurations. Taking the vmalert binary by itself is like taking a kerberos server binary without its libraries and config files in /etc files and complaining that it’s not working.

        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.

        I am very well versed in jails, chroot, openvz, LXC, etc. OCI containers are in a different class - don’t think of them as an OS-like environment, think of them as a self-contained, packaged service. Docker is then one example of a runtime runtime on which those services run, and Kubernetes is an orchestrator that managed containers in runtimes. And yes, there are some tradeoffs and compromises, but those are well within the bounds of the Pareto principle - remove the 10% long tail of features on the host, reduce user-facing complexity by 90%.

        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.

        Are you arguing that Kubernetes doesn’t do that for you? Because with Kubernetes I can say “run the service in this container with these settings and so many replicas”, attach some conditions like “stop sending traffic to any one container that takes longer than N seconds to respond” and “restart the container if a certain command returns an error”, and just let it run. I can do a rolling upgrade of the nodes and Kubernetes will reschedule the containers on any other available node, it can load balance traffic, I can update the spec of a deployment and Kubernetes will do a zero-downtime upgrade for me. Try implementing the same on a Unix system. You’d need a way to push configs (Ansible, Puppet, etc?). You need load balancing and leader election (Keepalived?). You need error detection. You need DNS. You need to run the services. You need to ensure there’s no library conflict. There’s a LOT of complexity that a Kubernetes user does not need to worry about any more. Tell me that’s not serious smarts and technology at its best.

        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.

        You seem to be conflating Kubernetes and cloud services. Being a cloud native technology does not mean it has to run on a managed cloud service. It just means that it has certain expectations as to how workloads run on it, and if those expectations are met then it makes certain promises about how it will behave.

        Have you ever written this kind of software before?

        I have contributed to several similar open source projects, yes. What about it?

        It sounds like you are comfortable with the status quo of this part of the software industry, and I’m truly jealous!

        I am comfortable with my knowledge of this part of the software industry. There is no status quo - there’s currently an equilibrium, yes, but it is a tenuous one. I know the tools I use today will likely not be the same tools I will be using a decade from now. But I also know that the concepts and architectures I learn from managing these tools will still be applicable then, and I can stay agile enough to adapt and become comfortable in a new ecosystem. I would urge you to consider the same approach for yourself.

        source
  • otl@lemmy.sdf.org ⁨11⁩ ⁨months⁩ ago

    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.

    source

    • PaX@hexbear.net ⁨11⁩ ⁨months⁩ ago

      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.

      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: doc.cat-v.org/bell_labs/utah2000/

      source

      • otl@lemmy.sdf.org ⁨11⁩ ⁨months⁩ ago

        We can’t go back to the old way of doing things but we can’t keep maintaining these fundamentally flawed systems either.

        That’s a great way of putting it, thanks. I’m actually only 30 years old (lol). Sometimes I feel there’s so few people who’ve ever used or written software at this level in the part of the industry I find myself in. It seems more common to throw money at Amazon, Microsoft, and more staff.

        I’ve replaced big Java systems with small Go programs and rescued stalled projects trying to adopt Kubernetes. My fave was a failed attempt to adopt k8s for fault tolerance when all that was going on was an inability to code around TCP resets (concurrent programming helped here). That team wasn’t “unskilled”; they were just normal people being crushed by complexity. I could help because they just weren’t familiar with the kind of problem solving I was, nor what tooling is available without installing extra stuff and dependencies.

        Thanks for your understanding :)

        source

        • -> View More Comments
      • fsniper@kbin.social ⁨11⁩ ⁨months⁩ ago

        I see that the problem arises from the "visionary, but lower experienced newer developers (compared to the past generation) " trying to fix a world where "don't touch it if it works crowd who has seen all old timers" built, by putting each layer over the older one. It has all the capabilities, but there is no "single vision", no "well defined api".

        Old established paradigms are being broken. Some conventions are forgotten, new tooling and perspectives are being built.

        Sure this means there is an unfortunate clash is happening.

        I can't say if this is a better, or wiser world or not, however I can only say this is the way now. You can adapt, try to embrace and push forward things or you can try to stay away and become one of the legendary Cobol developer crowd. We know they are there in the wild, but we can't find them.

        source
    • boblin@infosec.pub ⁨11⁩ ⁨months⁩ ago

      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.

      source