Demi Marie Obenour <demiobenour@gmail.com> writes:
With proposals like this, it's important to communicate why it might be an improvement over the current situation. All of these things are things we easily could do without needing a monolithic daemon.
To me, there are a couple advantages of using one or more daemons for this work:
1. It makes privilege separation easier. For instance, VMs that crash can notify Cloud Hypervisor via a pvpanic interface, but Cloud Hypervisor does not have the privileges to directly inform the user of this in any reasonable way [^1]. Instead, it should make an IPC call to a (socket-activated) service that notifies the user and logs some information to a file, which the user can choose to manually attack to a bug report if they wish.
But that socket-activated service doesn't need to be a daemon! It can run when it's activated, and then exit, and be started again next time a VM crashes, rather than taking up resources the whole time in between.
2. It avoids putting too much responsibility in the GUI. Right now, the obvious way to start an application is for the user to click on a .desktop file, which runs the needed s6 commands to start the application's VM and the services that VM relies on. Similarly, the obvious way to keep track of runtime state (like "which application has which device attached to it") is to have the GUI store all of that. To me, this seems to make the desktop environment itself a "god daemon", which I'd also prefer to avoid.
Oh yes, for sure we're not having the desktop environment do it. :)