Thanks for your detailed and well put responses! Alyssa Ross wrote:
Hi there,
I just discovered this project and I'm really excited about it! I've long waited for an OS that combines Qubes-like compartmentalization with the reproducibility of Nix/GUIX. Hi! Thank you for getting in touch. :)
I'm trying to understand what this project aims to improve over Qubes, other than the integration of Nix (which I do think is really important!). I read the motivation page [1], but I'm not yet convinced by most of the points mentioned that relate to Qubes. Going over each usability issue mentioned in the motivation doc:
- "Hardware compatibility is extremely limited": I don't believe this is really the case for the minimum Qubes 4 requirements [4]: most modern computers people buy support these. Is there anything I'm missing? - "People are reluctant to use Xen on their computer for power management etc. reasons." Can you elaborate on these issues? - I know that Qubes considered using KVM and decided against it for security reasons [2]. My understanding is that the downside of this decision is the limited hardware support, which is one of the things that Spectrum views as an opportunity for improvement. Can you elaborate on this decision? - "VMs are heavy": How will Spectrum improve on this without sacrificing security? I already talked about Xen vs KVM elsewhere in the thread, but wanted to say that the impression I've got from talking to several Qubes developers is that they are at this point far less enthusiastic about Xen than their documentation might suggest.
Additionally, a couple of things that the Qubes Architecture Specification[1] mentions as being benefits of Xen over KVM are now, I believe, also available in KVM. Specifically, I believe it is possible to use PV drivers with KVM (although I wonder if maybe there is a terminology mismatch here?), and I believe it will be at least partially possible to have something resembling driver domains, although this is an area of active R&D within Spectrum. Other mentioned advantages of Xen, such as auditability, remain, of course.
[1]: https://www.qubes-os.org/attachment/wiki/QubesArchitecture/arch-spec-0.3.pdf
- "GUI applications are buggy, command line tools are mostly undocumented": I assume that the reason for this is the lack of resources the Qubes project has. However, I don't see how this will be be better in the case of Spectrum which is a new project with one developer. My understanding is that a lot of the instability I've encountered with Qubes's tools comes down to some severe technical debt with their inter-VM communication system. This is likely something that is very difficult to fix, but easy to learn from. Being a new project allows Spectrum to learn from Qubes' mistakes. I agree, but I'm still not convinced this will be different in the case of Spectrum, having even more limited dev resources than Qubes'. I mean, if the Qubes folks could fix these issues without a huge effort, even if it meant rewriting all the inter-VM communication tools, they probably would. If they didn't, I assume this is because this is just a huge undertaking (as is the whole project), and they're busy with other work which has higher priority. I would assume that you will end up in exactly the same situation.
More generally, I'm wondering whether this projects' goals couldn't be better achieved by trying to work with the Qubes developers to integrate Nix. It may very well be that they would reject it for some reason, but then the logical next step would be to fork Qubes. Have you reached out to the Qubes developers? I've had the pleasure of speaking with several Qubes developers on multiple occasions. I also know that there is work being done to support NixOS templates in Qubes.
Do you have any link you can share to work on Nix template being used in Qubes?
As I see it, though, the real benefit of Nix here is that it would allow defining the whole system in one single Nix configuration. Doing this in Qubes would require big fundamental changes to how Qubes works. I believe the idea has been brought up to the Qubes developers, and as I recall they were not keen. I believe there is room in this space for Qubes and Spectrum to coexist.
There's definitely a place for both efforts, but I'm just wondering if it would not be better to implement Spectrum's ideas while working more closely with Qubes. For example, creating a git branch or a fork that replaces Xen with KVM and integrates Nix. Now, that may very be not the best way to make progress on this project, because ramping up on the Qubes codebase will be an inefficient use of your time, or because you want to first experiment with some ideas in isolation, or for any other reason. However, the potential benefits of such a collaboration are, in my opinion, too big to pass on without strongly pursuing it. Just to name a few: - You will get feedback from top tier security experts - Qubes already has strong credibility which can be a huge driver of adoption, especially if your project will be endorsed by Qubes devs - You will be in a better position to integrate some of the tools of Qubes, which you likely would need to do, and it is less likely that changes in the Qubes tooling will break your project (if you will indeed integrate them) - You are less likely to be asked time and again "Why not Qubes"? :) So, why not start a public discussion in Qubes' mailing list on issue tracker to figure out what is needed to accomplish Spectrum's goals? It will probably turn out that you made the right decision by starting a separate project, but at the very least: - You'll may get attention from people who can contribute to Spectrum - The issues involved with be publicly documented and searchable for future generations