Spectrum community call!

Spectrum community call!

[Alyssa Ross]

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

We haven't done one of these in a while, but I think it's overdue.  We
have new contributors who won't have had a chance to meet each other
before, and I haven't written a This Week in Spectrum for a while —
sorry!  I'll try to bring that back too — so it'd be good to give people
following the project an opportunity to find out about what's been going
on.  I hope that getting people to talk to each other directly might
also make it easier for collaboration to flow without ending up blocked
on me, as well.

I've set up a poll so we can find out when works best for everyone, so
please respond in the next couple of days if you'd like to join.  The
call will be open to everyone, and I'll post the link to the call and
the selected date once the poll closes on Sunday.

See you there!

https://beta.framadate.org/polls/b7944084ab02672d1bd3

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

Re: Spectrum community call!

[Alyssa Ross]

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

Alyssa Ross <hi@alyssa.is> writes:

> We haven't done one of these in a while, but I think it's overdue.  We
> have new contributors who won't have had a chance to meet each other
> before, and I haven't written a This Week in Spectrum for a while —
> sorry!  I'll try to bring that back too — so it'd be good to give people
> following the project an opportunity to find out about what's been going
> on.  I hope that getting people to talk to each other directly might
> also make it easier for collaboration to flow without ending up blocked
> on me, as well.
>
> I've set up a poll so we can find out when works best for everyone, so
> please respond in the next couple of days if you'd like to join.  The
> call will be open to everyone, and I'll post the link to the call and
> the selected date once the poll closes on Sunday.
>
> See you there!
>
> https://beta.framadate.org/polls/b7944084ab02672d1bd3

Thanks everyone!  The call will be at 14:00 UTC on Wednesday 8 July.
I'll send a link closer to the time.

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

Re: Spectrum community call!

[Alyssa Ross]

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

Alyssa Ross <hi@alyssa.is> writes:

> Alyssa Ross <hi@alyssa.is> writes:
>
>> We haven't done one of these in a while, but I think it's overdue.  We
>> have new contributors who won't have had a chance to meet each other
>> before, and I haven't written a This Week in Spectrum for a while —
>> sorry!  I'll try to bring that back too — so it'd be good to give people
>> following the project an opportunity to find out about what's been going
>> on.  I hope that getting people to talk to each other directly might
>> also make it easier for collaboration to flow without ending up blocked
>> on me, as well.
>>
>> I've set up a poll so we can find out when works best for everyone, so
>> please respond in the next couple of days if you'd like to join.  The
>> call will be open to everyone, and I'll post the link to the call and
>> the selected date once the poll closes on Sunday.
>>
>> See you there!
>>
>> https://beta.framadate.org/polls/b7944084ab02672d1bd3
>
> Thanks everyone!  The call will be at 14:00 UTC on Wednesday 8 July.
> I'll send a link closer to the time.

Whoops, sorry — I did this in too much of a hurry just before bed.  The
UI heavily prioritises "yes" vs. "if needed" over people not being able
to come at all, so the 14:00 Wednesday slot is good for 4 people, but
not workable at all for 2.  Despite what the computer says, that doesn't
seem better to me than 3 "yes" and 3 "if needed", which we'd get if we
did Sun 17:00 UTC.

So let's do that instead.  Sun 17:00 UTC.  Not 14:00 Wednesday.

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

Re: Spectrum community call!

[Alyssa Ross]

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

Alyssa Ross <hi@alyssa.is> writes:

> Alyssa Ross <hi@alyssa.is> writes:
>
>> Alyssa Ross <hi@alyssa.is> writes:
>>
>>> We haven't done one of these in a while, but I think it's overdue.  We
>>> have new contributors who won't have had a chance to meet each other
>>> before, and I haven't written a This Week in Spectrum for a while —
>>> sorry!  I'll try to bring that back too — so it'd be good to give people
>>> following the project an opportunity to find out about what's been going
>>> on.  I hope that getting people to talk to each other directly might
>>> also make it easier for collaboration to flow without ending up blocked
>>> on me, as well.
>>>
>>> I've set up a poll so we can find out when works best for everyone, so
>>> please respond in the next couple of days if you'd like to join.  The
>>> call will be open to everyone, and I'll post the link to the call and
>>> the selected date once the poll closes on Sunday.
>>>
>>> See you there!
>>>
>>> https://beta.framadate.org/polls/b7944084ab02672d1bd3
>>
>> Thanks everyone!  The call will be at 14:00 UTC on Wednesday 8 July.
>> I'll send a link closer to the time.
>
> Whoops, sorry — I did this in too much of a hurry just before bed.  The
> UI heavily prioritises "yes" vs. "if needed" over people not being able
> to come at all, so the 14:00 Wednesday slot is good for 4 people, but
> not workable at all for 2.  Despite what the computer says, that doesn't
> seem better to me than 3 "yes" and 3 "if needed", which we'd get if we
> did Sun 17:00 UTC.
>
> So let's do that instead.  Sun 17:00 UTC.  Not 14:00 Wednesday.

https://meet.jit.si/AgriculturalMatesTerminateDelicately

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

Re: Spectrum community call!

[Valentin Gagarin]

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