21–30 of 120 posts
I'm skeptical, and I think systemd gets way more hate than it deserves, but it's interesting to see an alternative from someone outside of the "Make Init Shell Again" crowd.
systemd is like chicken tendies -- its always been there for me.
Earlier quoted context omitted.
systemd is like chicken tendies -- its always been there for me.
that line is in your article as well, can you explain what it means? I am missing the reference
I feel the same way about systemd, its safe, reliable, and always a good choice for "dinner".
Basically I am saying that systemd has withstood the test of time and has never disappointed me.
Lack of Unix philosophy [...] Missing rest/gRPC/json API OK ...
Yeah, right.
I 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!'
The author did a great job explaining the motivation for Aurae. I fully agree that there should be tighter integration between k8s and the init system on each node. But thinking of the desktop, having a gRPC server on PID 1 seems unnecessary. dbus is the RPC used by systemd. Is there a reason why gRPC instead of dbus[0]? Or is the goal of Aurae to replace systemd in the cloud/server Linux space? [0]: dbus normally is…
If there is a network "gRPC server" as well, I suspect it would be somewhere in the 20+ department.
I don't anticipate exposes the actual pid 1 over a network. I'm not a monster. I suspect there will be be an init/jailer mechanism that manages bringing some of the basics online such a system logger and any kernel services (EG: ZFS) right away. One of the first "services" would be a d-bus alternative that is written in Rust and leverages gRPC.
The main motivation behind gRPC is cloud, mTLS, and the support in rust. It comes with the ability to implement load balancing and connection error management/retry capabilities. I have week opinions on the technical detail as I don't suspect the network traffic will be very large. gRPC is more familiar for folks in cloud, as well as supports a large number of client languages for generating clients.
The author did a great job explaining the motivation for Aurae. I fully agree that there should be tighter integration between k8s and the init system on each node. But thinking of the desktop, having a gRPC server on PID 1 seems unnecessary. dbus is the RPC used by systemd. Is there a reason why gRPC instead of dbus[0]? Or is the goal of Aurae to replace systemd in the cloud/server Linux space? [0]: dbus normally is…
To be clear I see the "gRPC server" that listens over a unix domain socket being something more like pid 10-20. If there is a network "gRPC server" as well, I suspect it would be somewhere in the 20+ department. I don't anticipate exposes the actual pid 1 over a network. I'm not a monster. I suspect there will be be an init/jailer mechanism that manages bringing some of the basics online such a system logger and any…
I 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!'
"Problems with Systemd"
Seems pretty unserious. Vague reference to Erik Raymond the Unix Philosophy (actually very debatable and not a useful way to think about Linux or Unix).
Links to pretty useless and unserious anti systemd posts (skimming them was a waste of time).
"""I personally don’t have a deep seeded loathing for systemd like many of my peers."""
Author should definitely get out of their local slack channel more, it not the result of a plot by Redhat and Sekrit powers that systemd is everywhere.
If the author is going to replace systemd they'd be wise to understand why it works the way it does and the epic amount of problems it solved first.
The cognitive dissonance of systemd concerns expressed and then somehow merging with some odd mutant kubernetes speaks for itself....