It’s been a little while. Here’s what’s been going on:
Spectrum has community infrastructure
This was what I was working on at the time of my last status update. I wanted to take the time to do this right, and I’m quite pleased with the result.
I could have had everything set up in a day if I’d used GitHub or SourceHut, but it was important to me not to do that. I think it’s important for Spectrum especially that community infrastructure can be independent and self-hosted. It would not be acceptable for people to unable to be equal participants because of the whims of the United States, as we have seen to be the case with those options.
Improving self-hosted community infrastructure in NixOS
I also think that people should be able to self-host easily using NixOS, and doing this was a good way to see what the status of that was, and put some work into improving it. As it turns out, rather a lot of work was required.
I will make this configuration public for other people to build on, but I can’t do that yet because of the issues I had with secrets in Mailman. Once that’s resolved (and I am still actively working on it), I will make the Spectrum community infrastructure modules public, and submit Nixpkgs pull requests for my public-inbox, Postfix and Mailman work. I might try to get pull requests together for public-inbox and Postfix first, but I’m not sure — I’m torn between doing that and just prioritising getting the mailman issues sorted so it can all be public in some way for people who really want it. I need to be careful about trying to do too many things at once.
This was already packaged, and easy enough to set up with nginx. I’d also done this before, so we were off to a good start.
This was not packaged, and I wanted to create a NixOS module for it as well. Getting the software to work optimally in NixOS required a lot of collaboration with upstream. Thanks to Eric Wong for being so patient with me, and hearing me out on some of the peculiarities of NixOS.
Overall, the Postfix module was very good. It was just slightly inflexible in a couple of places — I would like to append to default values rather than replacing the defaults, and it was possible to do this with a hack, but not in an intuitive way. I think it would be possible to make this a little better for Postfix (make a separate option for whether defaults should be included), but ultimately this is a problem with the NixOS module system in general.
A nice side effect of this was that I learned how cool Postfix is! I replaced msmtp on my laptop with Postfix. Far from being overkill, running a full local mail server means that I can “send” mail while I’m offline, and in the background Postfix will deliver it at some point once it manages to connect. Great for unreliable train wi-fi, which is how I’m connected to the internet for a sizeable proportion of my life.
This was already packaged, and already had a module, but the module left a lot to be desired. It suffered from not just secrets in the world-readable Nix store, but secrets that were hardcoded and would be the same for every user. The eventual PR I make to improve the Mailman module will be dozens of commits.
I understand why it is the way it is – it’s complex software and not that easy to map to the NixOS module system. But it wasn’t something I felt comfortable using, and most of the time I had to spend trying to set up infrastructure for Spectrum was spent learning how Mailman worked and trying to improve this module.
Adding crosvm to Nixpkgs
crosvm (the Chrome OS virtual machine monitor) is the hypervisor we plan to use for Spectrum. If you haven’t heard of crosvm, you might still have heard of Firecracker, a fork of crosvm by Amazon used for virtualization in AWS. It seems to have attracted a lot more attention because Amazon have been promoting it for wider use, whereas Google don’t seem to care much about usage of crosvm outside of Chrome OS. People keep asking me if I’ve looked at or will be using Firecracker in Spectrum, and seem not to realise that there’s this wider ecosystem of crosvm-derived hypervisors (Oracle has one too).
Anyway, crosvm has a lot of advantages over qemu, which would have been the obvious choice:
It’s much smaller — only supports the bare minimum feature set required to run a Linux kernel.
It’s written in a memory-safe language, Rust.
virtio-wayland — this is the big draw for me, and it also sets crosvm apart from Firecracker, which, being intended for servers, lacks any graphics support whatsoever. virtio-wayland allows guest VMs to interact with a Wayland server over the virtio interface. Wayland is nice here because what a single client can do can be very tightly controlled, unlike X11 where it has free rein to do just about anything it wants. Allowing arbitrary clients access to the same Wayland server makes me a little nervous still, because as nice as the security model is, we still need to trust that it’s been implemented correctly. I don’t see a way around this while still allowing integrated windowing at the moment, though.
Interestingly, crosvm comes with seccomp rules for x86_64 and aarch64. I have so little faith in seccomp as a security mechanism that I’m not going to actually count this as an advantage, but it can’t hurt I suppose.
I was pleased to discover that hyperfekt had already made a start with adding crosvm to Nixpkgs, so I’ve been collaborating with it to get crosvm in Nixpkgs to the point where it can actually boot a VM, with sandboxing, which is where were are now. I expect crosvm to land in Nixpkgs master next week, short of any unforeseen delays.
One disadvantage of crosvm compared to Firecracker is that because it’s primarily intended to be used in Chrome OS, documentation is extremely lacking. Figuring out how to actually use it for more than a trivial case will likely take some effort on my part. If you know anything about crosvm, please get involved! Share your expertise in #spectrum on Freenode or on the development mailing list.
I went to NixCon
It was great! It’s nice to meet so many people I spend the rest of my life working online with. Brno was nice too. In the four days we were there, we managed to eat at two different extremely anarchist vegan places. One we were only able to find because of the huge “DEFEND ROJAVA” sign they’d put out on the street. I’d love to go back.
By popular demand, I hastily arranged a Spectrum meetup, which consisted of eight or so interested people around a single table at the NixCon after-party. We had some great conversation, and I made some contacts that could be very useful further into Spectrum’s development.
My favourite talk was Peering into the Land of Parentheses — Guix from the Nix Perspective by Daniel Schaefer. It’s awesome to have another implementation of the same ideas as Nix around to draw inspiration from, and I think we’d be a lot better off with more Guix knowledge in our community. I think that this talk could have a really big impact for that reason.
The Flakes RFC continues to be discussed
I’m on the Shepherd Team for the Nix Flakes RFC. We’ve had a few meetings now, and progress is slowly being made. I’ll probably have more to say about the Flakes RFC on this blog soon, but for now, all I’ll say is that I don’t think it’s going particularly well.
Whatever happens, there’s a long way to go, and this will continue to take up large chunks of my time for the foreseeable future. As much of a slog as it is, I’m glad to be part of such a substantial potential change to the ecosystem. If you have any concerns, etc., that you would like to make sure are discussed in shepherd meetings, get in touch.
You can give me money now
I was accepted into the GitHub Sponsors beta recently. And I was shocked that, shortly after setting it up, I already had a sponsor! The timing was good because I’ve been thinking about this a lot recently. While I have funding to work on Spectrum, it depends on me reaching my milestones, which can sometimes take much longer than expected — the work with Mailman delayed the first one to the point that I was quite close to running out of money entirely by the time I managed to hit the milestone and get paid. This is very stressful, resulting in less output overall, and it makes it difficult to prioritise all the non-Spectrum work I want to do in Nixpkgs and the wider free software ecosystem.
So, I’m experimenting with community funding. I have profiles on GitHub Sponsors and Liberapay now. GitHub Sponsors will match donations to me for my first year. If you’d like to give me money to help support the kind of work I’ve talked about here, you can now do so. Let’s see how this goes.