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
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!
Thanks everyone! The call will be at 14:00 UTC on Wednesday 8 July. I'll send a link closer to the time.
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!
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.
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!
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.
# 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@alyss... [Discussion of initial use cases]: https://inbox.spectrum-os.org/spectrum-devel/CALi2N8TtTTyoK90DAm24jBTpJQBmNq... - 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.ht... [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=... [note on Reddit mentioning virgl]: https://www.reddit.com/r/chromeos/comments/1mzim3e/is_it_technically_possibl... [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.
participants (2)
-
Alyssa Ross -
Valentin Gagarin