Hi!
A QubesOS user here for about a year and a half, let's see if I can help out here.
On 6/12/20 11:06 AM, joweill@icloud.com wrote:
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?
I got a shiny new Thinkpad T490 a few months ago. 3d acceleration (KDE user here, I demand my wobbly windows!) is simply not available, because the dom0 system is too old.
My other laptop, a T470, was specifically selected for QubesOS, and there were still issues (for instance, disabling Thuderbolt got me almost double the battery life).
Generally speaking, one can buy almost any laptop today and expect it to mostly work with plain GNU/Linux. However, most might not even be able to boot QubesOS.
- "People are reluctant to use Xen on their computer for power management etc. reasons." Can you elaborate on these issues?
The T470 had easily a 10-12h battery life on plain Kubuntu. On Qubes, 4-5h is maximum I can squeeze out of it, and that's *after* the Tunderbolt fix.
Running virtual machines is extremely resource-intensive, there's no way around it.
- 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?
Can't speak for the developers, but the way I see Spectrum is as a compromise between regular GNU/Linux distro (with all the related security problems) and QubesOS (with the limited hardware support and
- "VMs are heavy": How will Spectrum improve on this without sacrificing security?
I'll leave this to the developers, but will say that I expect *some* security to be sacrificed. There are always trade-offs.
I feel one needs to be an expert to use QubesOS, but a regular user (with some basic training) can use a Mint or Ubuntu-based system. And I think it makes a lot of sense to offer a middle ground.
- "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.
That's a fair point. Things to consider: 1. *probably* certain things can be easier (thus, less bug-prone) in SpectrumOS than in QubesOS (kvm easier to work with than Xen, bigger potential community of users and developers due to improved hardware support, etc); 2. perhaps some QubesOS tools could be used in SpectrumOS, thus limiting the amount of work needed
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.
My feel is that QubesOS and SpectrumOS might have a bit different threat models in mind, and thus things that make sense for SpectrumOS (like using kvm) are a no-go for Qubes. But that's just guesswork on my part.
Have you reached out to the Qubes developers?
Thanks in advance!
## References
[1] https://spectrum-os.org/motivation.html [2] https://www.qubes-os.org/faq/#why-does-qubes-use-xen-instead-of-kvm-or-some-...