Spectrum OS management daemon?

Spectrum OS management daemon?

[Demi Marie Obenour]

[-- Attachment #1.1.1: Type: text/plain, Size: 547 bytes --]

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

- 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.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Spectrum OS management daemon?

[Alyssa Ross]

[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]

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.

> - 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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Spectrum OS management daemon?

[Demi Marie Obenour]

[-- Attachment #1.1.1: Type: text/plain, Size: 3686 bytes --]

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)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Spectrum OS management daemon?

[Alyssa Ross]

[-- Attachment #1: Type: text/plain, Size: 1676 bytes --]

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. :)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]