Alyssa Ross wrote:
- "GUI applications are buggy, command linetools 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.
Maybe eventually, but the flexibility that comes with being a new project still gives us a significant opportunity to advance the state of the art before that happens. At that point, maybe something else will come along to innovate free of all the technical debt Spectrum has acquired by then, and then the state of the art will advance even further. Such is the nature of software development.
More generally, I'm wondering whether thisprojects' 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?
This was the last I heard of it:
https://hackmd.shackspace.de/qubes-nixos
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
I think you maybe don't appreciate just how huge an undertaking this would be. There is so much that would have to change about how Qubes works that I think you'd end up having to reimplement most of it anyway, but you'd be doing it bit by bit, never having the opportunity to consider the system as a whole.
At the end of the day I just don't believe that trying to shoehorn these changes into Qubes is the best way to make progress. It might well be valuable to try that, but even so it would make much more sense for somebody who believes in that approach to dedicate the huge amount of effort required to attempt it, rather than me. This could be another effort that could be pursued in parallel to my work on Spectrum.
The goal is not necessarily doing this work, but to better understand what it would require, which can guide the work on Spectrum, even if it won't share much with Qubes (since you are likely to run into some of the design decisions that Qubes had to make). Well, maybe you already figured this out. I know how Qubes works only superficially, so it may be obvious to more knowledgeable people. In any event, I personally would like to understand this better, as I'm interested in exploring the integration of Qubes and Nix. If you have any insights to share, it would be great, and I may also ask the Qubes devs.