general high-level discussion about spectrum
 help / color / mirror / Atom feed
From: Valentin Gagarin <valentin@gagarin.work>
To: hi@alyssa.is
Cc: discuss@spectrum-os.org, Valentin Gagarin <valentin@gagarin.work>
Subject: Re: Spectrum community call!
Date: Wed,  5 Aug 2026 16:54:40 +0200	[thread overview]
Message-ID: <20260805145440.271056-1-valentin@gagarin.work> (raw)
In-Reply-To: <87jyrdy7do.fsf@alyssa.is>

# 2026-07-12 Spectrum community call

Attendees:
- Alyssa
- Lilla
- Demi
- Valentin
- Johannes
- (3 more guests)

Notes: Valentin, edited for correctness by Alyssa

## Agenda

- Updates on what's been happening recently
- Q&A

## Updates from contributors

- Alyssa:
   - Trying to get back to publishing weekly updates, but no promises
   - Worked on updating Spectrum's Nixpkgs pin
     - Hasn't been moved in 6 months
     - This sort of delay should be exceptional, but was focused on
       project management issues in the first half of the year
     - In the future, updates should be regular and automatic
     - Caught a crash in [Mesa] (via [cosmic-files]) that wasn't covered
       by tests, submitted [first PR to fix that]
     - We had been working on integrating [COSMIC] since 2023 (with
       contributions to upstream and its dependencies), and now
       [COSMIC on Spectrum is almost ready to go]
   - Vaida has been working on UX design for Spectrum
     - We had lots of conversations how applications should interact,
       how security concepts should be communicated to users, etc.
     - [Discussion of initial use cases] should soon make it into the
       public development space

   [Mesa]:
       https://mesa3d.org/
   [cosmic-files]:
       https://github.com/pop-os/cosmic-files/
   [first PR to fix that]:
       https://github.com/rust-lang/rust/pull/159145
   [COSMIC]:
       https://github.com/pop-os/cosmic-epoch
   [COSMIC on Spectrum is almost ready to go]:
       https://inbox.spectrum-os.org/spectrum-devel/20260710195907.98981-1-hi@alyssa.is/
   [Discussion of initial use cases]:
       https://inbox.spectrum-os.org/spectrum-devel/CALi2N8TtTTyoK90DAm24jBTpJQBmNq5J8BnY935r62b-x0t+dA@mail.gmail.com/T/#u

- Johannes:
   - Started working on the installer in October/November 2025, when Alyssa and
     Demi were discussing the new update system
     - The current installer wouldn't really work with that
   - Tried options from other distros, but didn't find anything suitable Started implementing our own in Rust - Turned out there was already development at GNOME OS on [gnome-setup],
     also in Rust and also using [systemd-repart]
     - Looks promising, we can probably use that once it's there
   - In the meantime, can use the [systemd-sysinstall]
     - Have it working for the latest Spectrum pin of Nixpkgs
   - Demi: The [GNOME] project has a history of focusing on their needs
     - Alyssa: We've spoken to them about whether they're open to
       contributions not strictly related to GNOME and got positive
       feedback
       - Also it's only one or two people there, and they seem to be
         receptive to accommodating us.
     - [GTK] appeared less flexible
       - Alyssa: That is a much bigger project

   [gnome-setup]:
       https://gitlab.gnome.org/Teams/STF/setup
   [systemd-repart]:
       https://www.freedesktop.org/software/systemd/man/latest/systemd-repart.html
   [systemd-sysinstall]:
       https://www.freedesktop.org/software/systemd/man/devel/systemd-sysinstall.html
   [GNOME]:
       https://www.gnome.org/
   [GTK]:
       https://www.gtk.org/

- Demi:
  - Making device backends run on the host
    - Linux assumes that every USB device (and hardware in general) is trusted;
      it's just not considered a security issue that a USB device would
      do arbitrarily bad things, such as taking over the kernel
      - Example: https://access.redhat.com/security/cve/cve-2024-50302
      - ChromeOS and Android would like otherwise, but Google hasn't
        paid anyone to go over the Linux USB stack to find
        vulnerabilities (they could but don't)
      - So essentially you can take over the kernel with a compromised
        device
      - But we want the system to be robust against vulnerable drivers
    - Linux is important because it runs a lot of hardware, not because
      it's particularly secure or well-designed
      - The goal of Spectrum is to make it secure but also to make it
        look like a sufficiently normal system to processes
      - Qubes is secure, but isn't particularly normal
      - The ideal is a [capability-based operating system], and Spectrum
        is the minimum viable increment over the current state of
        affairs
    - One long-term goal is to expose hardware via VMs, and that
      requires a communication mechanism between these VMs in the
      first place
        - The protocol would be [virtio-vhost-user],
          see also the [issue on virtio-vhost-user support in Cloud Hypervisor]
        - Have been working to get the spec and implementation over
          the finish line
            - Updated the spec
            - Eventually this might risk becoming co-maintainer of a lot
              of virtio drivers for different device types (block
              device, microphone, camera, ...), but even with insecure
              drivers there's also a degree of protection of hardware
              against malicious apps
        - The benefit would be that the physical device never comes into
          contact with the application, and the scope of a vulnerable
          driver would be constrained to just the VM handling the device
    - Network is easier, because networking is by design able to be
      routed between multiple VMs

  - Exposing [virtio-gpu] 3D acceleration
    - People want to run graphical applications efficiently
    - Short of passing through the entire GPU (which would limit us to
      only one VM being able to access it), the best we can do is
      virtio-gpu native context
      - Context on that is worth a full talk:
        [Reasonably Secure GPU Acceleration at Xen Project Summit 2024]
    - Lilla: Heard that [ChromeOS is deprecating graphical acceleration]
      - Demi: Know that they got rid of it on Intel devices, not sure
        about ARM
      - They added a note on their website that it's still available but
        unsupported
      - Demi: That may have been specific to platforms that don't have
        native context
      - Alyssa: found this [note on Reddit mentioning virgl];
        emulated OpenGL is hard to do securely
        - Demi: A future option could be a thing called [magma-gpu], but
          that would require more upstream work on [Mesa]
    - Graphics drivers are basically their own kernels; that's the level
      of complexity we're talking about...

- [Control groups] in Spectrum
  - Main goal is to watch resource use
    - Secondary goal is shutting things down cleanly
  - Normally this is done by systemd, but Spectrum doesn't use systemd
    after evaluating it (should be in an FAQ)
  - Main remaining issues:
    - No locking for concurrent operations on a cgroup tab
      - Found a way to do it recently
    - You get a deadlock on an empty cgroup
      - You can't even kill it and the network locks up, no idea why
      - Still work in progress

  [capabililty-based operating system]:
      https://en.wikipedia.org/wiki/Capability-based_operating_system
  [virtio-host-vuser]:
      https://inbox.spectrum-os.org/spectrum-discuss/878s4i3ixs.fsf@alyssa.is/T/
  [issue on virtio-vhost-user support in Cloud Hypervisor]:
      https://github.com/cloud-hypervisor/cloud-hypervisor/issues/7045
  [virtio-gpu]:
      https://www.qemu.org/docs/master/system/devices/virtio/virtio-gpu.html
  [Reasonably Secure GPU Acceleration at Xen Project Summit 2024]:
      https://youtu.be/FrKEUVB-BYM
  [ChromeOS is deprecating graphical accelleration]:
      https://developers.google.com/chromeos/app-development/develop/news#:~:text=deprecated%2C%20are%20no%20longer%20supported
  [note on Reddit mentioning virgl]:
      https://www.reddit.com/r/chromeos/comments/1mzim3e/is_it_technically_possible_to_use_gpu_in_chromeos/?solution=c6f8bbdad1b0bf7ec6f8bbdad1b0bf7e
  [magma-gpu]:
      https://github.com/magma-gpu
  [Control groups]:
      https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/cgroups.html

- Valentin:
  - Working on Spectrum documentation
    - Recently changed the rendering to display all of the material in
      the same style
    - Updating things for readability and discoverability in small
      increments
  - What do people expect from documentation?
    - Interested in any input! What would help you get going, e.g. with
      contributing?

- Everyone is invited to introduce themselves and share work related to
  Spectrum!

## Questions

None today.

      parent reply	other threads:[~2026-08-05 14:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-02 11:10 Spectrum community call! Alyssa Ross
2026-07-05 20:52 ` Alyssa Ross
2026-07-05 21:04   ` Alyssa Ross
2026-07-12 16:53     ` Alyssa Ross
2026-08-05 14:54 ` Valentin Gagarin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260805145440.271056-1-valentin@gagarin.work \
    --to=valentin@gagarin.work \
    --cc=discuss@spectrum-os.org \
    --cc=hi@alyssa.is \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).