QubesOS founder and I got into it on their mailing list so I haven't tried it. Joanna updated her blog and FAQ to try to counter every point without mentioning my name or allowing replies lol. Anyway, my worries were: the Dom0 code in TCB, Xen kernel's complexity plus bug count, no covert channel analysis, that she was unaware of all similar research/issues in that area before Qubes, that she didn't know why user-mode drivers improved system robustness, and that she cited Mach/Darwin as why microkernels like L4 weren't good foundations (?!). All troubling traits if I'm to trust what they produce against High-Strength Attackers. However, my friends that have tried it like it, praise the usability, and say (with backups) you could use it day-to-day. So, I recommend it along the same vein as whitelisting and anti-virus: stops low to mid-grade attackers along with background radiation of Internet.

Plan to try all three again soon. Muen is a straight separation kernel with static configuration. So, will be limited but usable for simple setups: appliances, trusted + untrusted VM's, main stuff in Linux w/ crypto stuff in OBSD or native partition, maybe embedded on decent hardware, etc. GenodeOS is getting rapid development for a small project with a clever, resource-management architecture that needs further evaluation by pro's. Unlike QubesOS, they follow academic work producing best-of-breed components (eg Nitpicker GUI, seL4) and try to integrate them. Project itself was result of work to make more secure architecture. Both of prior have tiny TCB w/ GenodeOS having microkernel's performance advantages (Muen situation unknown). Finally, QubesOS builds some nice architecture, excellent usability, and hardening on top of mature Xen code-base with its risks/rewards. So, not really apples to apples here with any of them. QubesOS is definitely ahead in usability and features, though.

"Of course DoD/Darpa have their nice little distros but they tend to be proprietary and expensive so I essential pretend they don't exist for my purposes."

That's true. You have to pay to get the really good shit. OSS/FLOSS never do [1] high-assurance security, though: almost always companies or academia releasing it OSS after the fact. So, I've been investigating models that combine open-source, proprietary licensing, and review. If that's a shock, it's because almost all online discussions talk either proprietary/closed or free/open. However, that's barely relevant for security in practice and narrow thinking that misses other options [2]. So, my idea is to make the software proprietary, optionally a non-profit, have pro's build it for money, put an upper bounds on licensing cost, keep purchases perpetual, simple contract terms that won't change, source provided, extensions allowed with re-submission requirements yet to be determined, paid review by pro's, rewards to encourage others, and contractually to be released Apache/GPL if company tanks or product to be discontinued. This should cover extreme sophistication and labor required to build high-security, let people extend, let people fix stuff, and being more trustworthy. Your thoughts?

[1] https://www.schneier.com/blog/archives/2014/04/reverse_heart...

[2] https://www.schneier.com/blog/archives/2014/05/friday_squid_...