Yikes. https://www.qubes-os.org/news/2017/04/04/qsb-29/

Xen is looking more and more as a liability. Subgraph OS which takes a completely different approach (sandboxing + hardened kernel) has a much better track record with the only vulnerability being dirtycow. Qubes has been affected multiple times due to Xen bugs in recent years: https://www.qubes-os.org/security/xsa/

@femme How does the comparison go when you account for the fact that Subgraph has a much shorter track record?
@covalent The first subgraph os alpha was released in march of 2015 and has managed to not be affected by most public linux vulnerabilities (in fact all except dirtycow) as they either require unprivileged namespaces or are thwarted by grsecurity/PaX. Since march of 2015 according to the Qubes Security Bulletins there have been 17 separate issues affecting Qubes and that's not including the issues in the VMs people are running. So it looks really good for the two year old operating system.
@femme @covalent how many users does subgraph have? i find that is often more useful as a measure of "how well-audited is this thing" than the age of the project
@bcrypt @covalent subgraph os specifically I don't know but grsec has a lot of deployments (I think millions)
@femme @bcrypt Subgraph has a lot thicker layers on top of grsec than Qubes does on top of Xen, because grsec itself doesn't provide isolation. You have to build a sandbox yourself (in SG's case, Oz). So I don't think that grsec bugs are a proxy for SG bugs in the same way Xen bugs are a proxy for Qubes bugs.
@covalent @bcrypt Turns out it wasn't affected by dirty cow after all due to the sandbox policies in place is what xmux (one of the subgraph devs) just told me, after talking to spender who''s one of the main grsecurity devs. So all public linux vulnerabilities were mitigated by either using grsecurity/PaX or disabling the features (such as user namespaces) in the kernel configuration.