A gRPC dependency is a non-starter. The rest looks so kludged and unnecessarily complicated that it's DOA.
Why Fix Kubernetes and Systemd?
61–70 of 120 posts
Re: Why Fix Kubernetes and Systemd?
#62A gRPC dependency is a non-starter. The rest looks so kludged and unnecessarily complicated that it's DOA.
Why?
Re: Why Fix Kubernetes and Systemd?
#63Earlier quoted context omitted.
But Systemd has IPC and a stable interface for clients, it's "the D-Bus interface of systemd"[1]. I would think that exposing that over http would be a little reckless, but I'm sure one can create a proxy that can do it in a "secure"-ish way. [1] https://www.freedesktop.org/software/systemd/man/org.freedes...
There is this: systemctl --host=whatever.abc status apache2 It uses ssh and UNIX domain socket forwarding behind the scenes. There's a writeup of how to do this with minimal privs here: https://sleeplessbeastie.eu/2021/03/03/how-to-manage-systemd... If you want to speak the protocol without the systemctl program then you can do the same trick. Use an SSH library, connect to the dbus socket and connect to systemd. You…
TIL. I had no idea the systemd team implemented something like this already, it's great info, thank you. :)
Re: Why Fix Kubernetes and Systemd?
#64I'm interested to hear if there are any plans for sending file descriptors over local gRPC, which afaik isn't really possible right now but is something D-Bus does easily.
Re: Why Fix Kubernetes and Systemd?
#65I find kubernetes - systemd overlap angle as a very valid point. When I first started to learn kubernetes more often than not I was thinking 'hey, we can do that with systemd as well!'
I often noticed this as well. After reading the article I wonder: Would it be feasible to write a kubernetes-shim for systemd to reduce the overlap instead of reinventing everything? This would not fix any of the valid criticism the author has of systemd but instead make it do even more things. Nevertheless I somehow find the idea very intriguing
CoreOS did pretty much this (minus k8s, but same abstraction), and I loved it. Much easier for simple deployments, harder for anything else
Re: Why Fix Kubernetes and Systemd?
#66Honestly, surprised no one built kubelet-shim for systemd yet.
Neat project.
Re: Why Fix Kubernetes and Systemd?
#67Earlier quoted context omitted.
systemd is like chicken tendies -- its always been there for me.
My first experience was with Arch Linux right when they switched to Systemd. I hated it, but I didn't really get what it was, not knowing what an init system or a process even is. But I was then quite surprised a few years later when it was just the normal thing for me when people in Debian were basically fighting a war over it.
My first experience with systemd was similar, it was in Fedora 15 and it basically was such an incredible source of frustration.
Seems to be quite serviceable on the happy path, and I quite like it for desktop linux honestly.
But I find it's usually a bit too opaque and "magic" for servers; even if it's causing less and less issues.
I liken the issue to the same one pulseaudio had: a software ecosystem that is poorly designed but foisted together into a perfectly serviceable product by incredible amounts of effort for all involved in its development and release to public.
Re: Why Fix Kubernetes and Systemd?
#68It's an interesting project. Definitely like that it defines its reasons to exist and goals / non-goals first. More big projects should do that clearly.
I'm a bit confused by the early complaints though.
> It assumes there is a user in userspace. (EG: Exposing D-Bus SSH/TCP)
What does this mean?
> Binary logs can be difficult to manage in the event the system is broken and systemd can no longer start.
What kind of managing? To read them you can use --directory to read a specific set of logs from a recovery system and systemd doesn't need to run. What else am I missing?
Re: Why Fix Kubernetes and Systemd?
#69I think I'm stupid, because for me this all seems overly complex. Why do the things get more and more complex instead of the opposite? Is it really the only way? Like said, I'm clearly stupid for not understanding it.
Simple systems are easy to replace, thus are replaced often until eventually a complex replacement comes forth.
Complex systems are hard to replace, thus stay in place.
This is the way of all things unless there is a design constraint placed on simplicity. In mechanical engineering they design things to be cheap to manufacture: this is the design constraint.
Computers do not have constraints on them, you can burn resources or be as complex as you want: more powerful hardware is around the corner, and after all: why shouldn't abstractions be abstracted ad infinitum; as long as it's easier for people?
Re: Why Fix Kubernetes and Systemd?
#70I think I'm stupid, because for me this all seems overly complex. Why do the things get more and more complex instead of the opposite? Is it really the only way? Like said, I'm clearly stupid for not understanding it.
Simple systems are easy to replace, thus are replaced often until eventually a complex replacement comes forth. Complex systems are hard to replace, thus stay in place. This is the way of all things unless there is a design constraint placed on simplicity. In mechanical engineering they design things to be cheap to manufacture: this is the design constraint. Computers do not have constraints on them, you can burn res…
"Simple systems are easy to replace, thus are replaced often until eventually a complex replacement comes forth.
Complex systems are hard to replace, thus stay in place."
Damn, this is very good and clarifying. Like Gresham's law, but for software.
> why shouldn't abstractions be abstracted ad infinitum; as long as it's easier for people?
Not pessimistic enough. Should be: Even if it's no easier on anyone