Re: Comparison to Qubes OS

[Alyssa Ross <hi@alyssa.is>]

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

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

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 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?

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.

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