|
|
|
|
|
|
by PuercoPop
1363 days ago
|
|
|
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 used over a unix socket but afaik you can use dbus over a regular tcp socket |
|
|
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.