-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2016-07-06 08:57, [email protected] wrote:
> So, I've been following Qubes since version 1.0. At that time, I
> used it as a lab demo for interns at work to show them just how far
> you can go with visualization. It was clunky back then, but I kept
> my eye on the project.
> 
> I've toyed with using 3.x as a daily driver, lately. From a 
> non-security perspective, it works great at helping me 
> compartmentalize my life, and that's the main reason that I like
> it. From a security perspective . . . I mean, it goes without
> saying. I'm way more of a Debian and VMware person, and I'm
> definitely cutting my teeth on Fedora and Xen, so please excuse my
> ignorance of them.
> 
> The thing that's keeping me from using Qubes regularly is that it
> is so resource-hungry. I understand why and that many of these
> reasons are security considerations. I have a M6800 laptop with
> 16GB of RAM, so I've got plenty of power. However, it pains me to
> see an AppVM running a single instance of Firefox eating up just
> under 4GB of RAM. Yes, much of that is the fault of the application
> developer, but some of it is also overhead needed to provide the
> high degree of isolation and security that exists in Qubes.
> 

Are you sure that's not just qmemman dynamically reallocating memory
across running VMs? If you only have a small number of VMs running,
it's not surprising that 4GB of memory would be allocated to them, but
that doesn't mean that the memory isn't available for starting other
VMs and running other programs.

> I've searched around for "performance tuning" guides for Qubes, but
> I haven't been able to find any. Does one exist, or is it possible
> to start to put something together? By "performance tuning," I even
> mean potentially changing settings that may include the sacrifice
> of some security for added performance and resource handling. I
> know, I know - that goes against everything that the project stands
> for. I used to work on the pen testing team at a Fortune 10
> company, I understand why Qubes works the way it does, so hear me
> out. Some people (like myself) have different use cases, understand
> the risks, and are willing to give a little to gain a little. Much
> like rooting a phone, enabling "unknown sources"/USB debugging on
> Android, or even typing "sudo" at the command prompt, many power
> users are willing to take the risk because they know what they are
> doing.
> 

Security is the raison d'ĂȘtre of Qubes. Without security, Qubes
wouldn't be any better (and would arguably be much worse*) than
standard monolithic OSes.

* Mainly due to hardware compatibility and user-friendliness.

> Beyond just making a list, it would be nice to eventually make
> such settings available in the GUI. Add a checkbox somewhere to
> allow full-screen playback,

I'm not sure if your point here is about having a GUI checkbox or
about having the ability to enable fullscreen mode at all. In case
it's the latter, and you're not already aware, you can enable
fullscreen mode in a config file:

https://www.qubes-os.org/doc/full-screen-mode/#tocAnchor-1-1-4

(Obviously, this is not a GUI checkbox, but I just wanted to make sure
you're aware that the option is available.)

> but give a disclaimer to the user (again, just like enabling
> unknown sources on Android gives a warning). Have options to tune
> Xen's resource management, but make the user aware of what they are
> wishing to do. I'm not saying give checkboxes to do things like
> connecting dom0 to the network, but having options to decrease
> resource isolation from VM to VM would be great for those who
> prefer a little more performance over absolute security.
> 
> Thoughts?
> 

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXfS9wAAoJENtN07w5UDAwRFkP/icCejG41Cy0H7bMj0CpAlkA
SNXJu6T4Jv8VkUXh7ovPpHu0fN3Vo4/8pZKhX7l7TCLndfguL6qrdRbFA1zdXKY2
YaIdcYinGJGgj0aG/SzzyaT8RyIEzlezKa6UboTF9qt12WVgLdPRemiy7vqAyiuw
FTyMykPuDZX1x/LYaDkiixmvUocq232GLmv8GE9UTpxCUzNrVPFCN7Et+cWoximj
1U+d7UlRiKPAV7rXJ8BF0jiLmEJfzienYrLuf7qAFBDuJGA3ekg++VOmvKn0anhl
LMxn2IMkHMtnAYx8xp2C+LoDczn/7CoOTPSvOmawdpi6t0zMSj0w3S7+Ph0T8N/A
mexry0kic4yi4qyw4IQz7BYGwqnAXN+oYI//mq4AGGsLsmlY+GPgKPquNvqAEIpq
virPGPPiPYxKrqIjYi4StcbMbWrlrAREqwYOm1xjKy+6aYOBOZiYatTBhPcFgLos
sTuiqBYPZ2+Oh+KExpDB+UUvRQdGZLXa5UzT3xhZl1g3AbvqISwLep6zqJksnifl
vRKVKEmn3ZprB2D703d3kJ6b7K7hbwSmmVXJN5RZE2M4OsGnFiqnSeSiVDehmCpe
GfFbL0cNT2URdqL/m5l1W+VaviofSlCFQjaxn6SWnf4LuW/GxcVEvK+4nbKCb1JT
4e/XZhqSbg8DK+w90Rvv
=P+vD
-----END PGP SIGNATURE-----

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e50d72cd-d2dc-371a-03ba-28fad0e62117%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Reply via email to