On 8/21/25 06:32, Alyssa Ross wrote:

Demi Marie Obenour <demiobenour@gmail.com> writes:

...

I'm wondering if Spectrum OS should have a management daemon that is responsible for a few tasks:

I'm not saying never, but I am keen to try to avoid it, and if it has to happen, to limit its scope as much as possible. My concern is that "management daemon" would end up becoming the daemon equivalent of a god object — once there's state maintained within a daemon, it's always easier to add more stuff to that daemon than it is to implement things separately and expose that state, even if those things have no business being part of that daemon. With no monolothic daemon, we don't have that tendency towards consolidation, and can instead having single purpose components that can be understood in isolation.

I agree that it would be much better to have separate processes for each task where possible. For instance, the program that notifies the user of VM or application crashes should only run when a crash happens, and should only be responsible for crash handling.

...

- Starting VMs when requested by the UI. - Notifying the user of various situations that require their attention, such if a VM crashes. - Suspending VMs before the host suspends, and resuming them after the host resumes. I believe Qubes OS didn't do this initially, but that led to problems so they do do this now. - Acting on devices being plugged and unplugged from system VM.

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. 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. Daemons are also very good at handling state that needs to be kept consistent. For instance, one could use a shared permission store that the UI and the management code for all VMs has access to. However, this requires that both pieces of code be able to directly access the database. Indirecting through a daemon avoids needing this. One idea I just had is to make it very easy to add new daemons, by writing a Rust crate that makes them extremely easy to implement. Ideally, one should only need to write an initialization function and a request handler, and the framework should do the rest. [^1]: Theoretically it could use the existing interfaces that the VM uses to communicate with the host, but this would be a horrible hack at best. -- Sincerely, Demi Marie Obenour (she/her/hers)