Live data from Hacker News

Why Fix Kubernetes and Systemd?

medium.com

1–10 of 120 posts

Re: Why Fix Kubernetes and Systemd?

#2
I think one of the things to call out is that this is going to take a lot of time. I don't realistically see something like this being just another "get rich quick" CNCF project that pops up and dies out in 24 months.

If we do this "right" it kind of needs to go at the pace of the Kernel, and hold very tightly onto the API scope to protect the project from scope creep.

Re: Why Fix Kubernetes and Systemd?

#3
asking "why?" is a double whammy question, the answer they are looking for is a mix of what (to do) and how to do it, whatever that 'solution' is called.

how to fix this "most-open unit of computing" will depend on "what" do you think this 'unit of compute' even means, which of course depends on who you are and what do you do with 'units of compute' (buy? sell? resell? use up? build? oversee??)

Re: Why Fix Kubernetes and Systemd?

#6
>Now where you lose me is where you start duplicating scheduling, logging, security controls, and process management a cluster level and fragment my systems yet-again.

That is sort of what we're talking about when we talk about unix philosophy. If your daemons for handling all those aren't tightly coupled then it's easier to use the same tools for different tasks.

Re: Why Fix Kubernetes and Systemd?

#10

Doesn't sound like this fixes systemd, unless your problem is that you depend on systemd + kubernetes. That is, I read this as a Redhat/Gnome/Freedesktop problem; I'd love a fix for systemd, but I don't think this one solves my problems.

Care to elaborate on your problems? Or maybe a more fundamental question would be -- would you be interested in a project like this solving whatever your particular gripes with systemd might be?
Post reply on HN