Well, if you really want to call it a distribution, then we’re more of a “Xen distribution”, rather then a Linux one. But Qubes is much more than just Xen packaging -- it has its own VM management infrastructure, with support for template VMs, centralized VM updating, etc, and also its very unique GUI virtualization infrastructure.
Please see [this article](http://theinvisiblethings.blogspot.com/2012/09/how-is-qubes-os-different-from.html) for a more thorough discussion discussion.
The other two popular [approaches](http://theinvisiblethings.blogspot.com/2008/09/three-approaches-to-computer-security.html) are: “Security by Correctness”, and “Security by Obscurity”. We don’t believe any of those two can bring reasonable security today and in the foreseeable future.
In short: these are non-realistic solutions today. We discuss this more in-depth in our [Architecture Specification document](http://files.qubes-os.org/files/doc/arch-spec-0.3.pdf).
We believe that today this is the only practically viable approach to implement strong isolation, and, at the same time, provide compatibility with existing applications and drivers.
No! This would not make much sense. Qubes uses lightweight VMs to create security domains, such as e.g. ‘work’, ‘personal’, ‘banking’, etc. Typical user would likely need around 5 domains. Very paranoid users, who are high-profile targets. might use around a dozen or more domains.
In short: we believe the Xen architecture allows to create more secure systems, i.e. with much smaller TCB, which translates to smaller attack surface. We discuss this much more in-depth in our [Architecture Specification document](http://files.qubes-os.org/files/doc/arch-spec-0.3.pdf).
We have designed the GUI virtualization subsystem with two primary goals: security and performance. Our GUI infrastructure introduces only about 2,500 lines of C code (LOC) into the privileged domain (Dom0), which is very little, and thus leaves not much space for bugs and potential attacks. At the same time, due to smart use of Xen shared memory our GUI implementation is very efficient, so most virtualized applications really feel like if they were executed natively.
Those won’t fly. We do not provide OpenGL virtualization for AppVMs. This is mostly a security decision, as implementing such feature would most likely introduce lots of complexity to the GUI virtualization infrastructure. However, Qubes allows for use of accelerated graphics (OpenGL) in Dom0’s Window Manager, so all the fancy desktop effects should still work under Qubes.
No, Qubes does not pretend to be a multi-user system. Qubes assumes that the user that controls Dom0, controls the whole system. It will be very difficult to **securely** implement multi-user support -- see this message:
Every AppVM is created from a so called TemplateVM and they share the root filesystem with the template (in a read-only manner). This means each AppVM needs only disk space for its own private data. This also means that it is possible to update the software for all the AppVMs by just running the update process in the TemplateVM once (one needs to stop all the AppVMs for this, of course).
Yes. Xen doesn't use VT-x (nor AMD-v) for PV guests virtualization (it uses ring0/3 separation instead). But, of course, without VT-x, you will also not have VT-d -- see the next question.
Also, without VT-x you won't be able to use fully virtualized VMs (e.g. Windows-based AppVMs) that are to be introduced in Qubes 2.
Yes you can. You can even run a netvm but, of course, you will not benefit from DMA protection for driver domains. So, on a system without VT-d, everything should work the same, but there is no real security benefit of having a separate netvm, as the attacker can always use a simple DMA attack to go from netvm to Dom0.
**But still, all the other Qubes security mechanisms, such as AppVM separation, work as usual, and you still end up with a significantly secure OS, much more secure then Windows, Mac, or Linux, even if you don't have VT-d'''**
