Where does Qubes-UX fit in?

[Doesnt Work]

I'm really not sure where to post this, but I believe Emails bother the
least amount of people.

I'm wondering what direction the QubesOS-project is taking UX-wise. I
could understand if Qubes, being highly security focused, puts usability
on the back-burner. However, I couldn't find a discussion on Qubes
usability in general.

What I'm wondering is weather recent dips in usability were a result of
the big API-overhaul when switching to Qubes 4.0, or if there was a
conscious decision to focus less on usability?
That would be perfectly understandable for a security-focused operating
system, but I myself enjoyed Qubes 3.1 for it's usability. Essentially,
I want to know weather enduring the steep learning curve of a new OS, or
waiting for a more UX-focused version 4.1?

sincerely
GammaSQ

[Chris Laprise]

Much of the story is here:

https://github.com/QubesOS/qubes-issues/issues/2132

The new API did mean some rewriting of Qubes Manager was necessary, but
this was not a big challenge IMO or an underlying reason for the 4.0 UI
changes. QM was somewhat revived after it became clear the new UI was
lacking.

Overall, it seems there was a push to make the VMs appear to the user
less like complex machines that you had to manage, and more like a pure
abstraction that just happened to have VMs running underneath -- like an
app loads and uses a runtime library.

The old Qubes Manager UI focused the users attention on Qubes being a
collection of virtual machines with critical runtime properties (memory,
CPU load, disk space, etc) and this was thought to intimidate novice
users. So aspects of QM were sliced up and stuffed into small systray
apps. At one point which mystified me, a goal was to integrate with
Gnome 3, a "post-desktop" tablet-styled UI that blurs the lines between
window manager and app.

The effort was probably premature and lacked a certain kind of UI
expertise that open source projects are often blind to. That's my
opinion as a user and bystander.

If I were you, I'd start with Qubes 4.0 now because recovering the old
3.x UI options will be a gradual process.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[Sven Semmler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 11/20/18 1:30 PM, Doesnt Work wrote:
> I want to know weather enduring the steep learning curve of a new
> OS, or waiting for a more UX-focused version 4.1?

I asked myself the same question, but then just couldn't wait to use R4.
Now I am glad to have made the switch and must say the learning curve
was not steep at all. There are only a handful of commands which will
become second nature in no time:

- -> qvm-ls ... shows your qubes and their state. The default output is
sufficient in 99% of all cases. If you are missing something you will
easily find a parameter to add it.

- -> qvm-prefs ... is how you manipulate qubes. Easy and straight forward.

- -> qvm-create, qvm-clone, qvm-remove ... are obvious.

- -> qvm-pci to assign devices to qubes (hvm only!)

- -> qvm-usb to assing usb devices

There is also a qvm-features but I use that one only by instruction when
creating named disposable qubes.

I have no idea where you stand when it comes to UX. Personally I tried
I3 on Qubes out of curiosity and didn't plan on using it at all. That
was several months ago ... I still use it.
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE18ry22WNibwI1qeq2m4We49UH7YFAlv0susACgkQ2m4We49U
H7Ysfg/+InE4GbnGljEAvvk5ZXizqdCO1FlRwxJww1XwRHFUGjPLgbrssE8U6xjw
oetNGI9U4iFlekjCri03S/t3tdJo/JrphF791EwJIDUEDEEpORiZ7gKTzzQFMYDi
XMd4SIBhCG9gFcHUefg7oDjQfjwiH1c5C7Dfn/XMblwOC1vLd8aC9Rc4UR4WBmxM
WvkEzZywtar3oErUygz2UyU+Q5yTIb3TSr+JCu/V7hHigJsCL2C+I+aJQZiIXv7E
rdgiArRSbwprC3PanDQ9AZZXoSZGii64/ru0ZuQ+Bro5cgvxNCVKuAErn+in7q5l
F91o1cYARiSLKA8ouycITGBiAus2G8Ls0gEZW6VLI5iS3ubMqldj5FMnpHyngHBL
toNZVNZcUds36auVqTiZtkwTC0jQF9h0xqjh4TQAQJdBHdsOGNVC45qBhIw5V4yf
JUUJGWvNohtP+zs54G1orRWg7r5Iok2RgZ+9Gr4203USaYWFKRaLfXg4+BYTkIwy
ZQ66Mbmswjbbm3//lfbgjQ8cEJQQ0pa0A9fqUaB/g6aUVSup9adZy8pEh6PqKafr
iPXs/54pwtf74qyS4b54GNx+JbOV6BOB6q+gOLe1v6dEtwkB6Qc9Lmi9J4zTGMhn
xKifPo2mf924t41C6R4b5jtoyVK8+p41YGSETKqaTzPYOKKUlnE=
=8aDS
-----END PGP SIGNATURE-----

[Doesnt Work]

Thank you all for the direct answers!

However, I'm not just talking about GUI-UX, but cli-UX as well.
Especially the detailed documentation of commands is usually only valid
for Qubes 3.X. Errors are rarely helpful but rather are uncaught
python-errors (qvm-run [something] + CTRL+C = "KeyboardInterrupt Error")

Additionally, tab-completion still doesn't work (which would have to be
a new feature, but since VM-name-completion works for qvm-copy &
similar, I am wondering why this wasn't implemented at the cli-level as
well.)

Let me give examples of the cli-shortcomings:
Sven Semmler:> -> qvm-ls ... shows your qubes and their state.
No memory/CPU-usage. Have to use xentop for that. Xentop shows CPU-usage
per core? I guess? Works to determine most-hungry VM, not managing
resources.

> -> qvm-create, qvm-clone, qvm-remove ... are obviousqvm-create has horrible argument-dependencies. e.g. if --template is a
dvm-template, --class has to be DispVM [everywhere else it's "dispvm"],
not to mention --property auto_cleanup=True (I don't see the usecase of
a dispvm without auto_cleanup.)

qvm-run --dispvm [dvm-template] CMD
fails too often and without obvious reasons for me to count. (Guess it's
a RAM-problem.) And dvm-template is required, default-dispvm is not used.

btw.:
qubes-global-settings can't be used from the commandline but opens
GUI-window.

qvm-copy now opens a window that needs interaction. This is awful for
copying many files, VM-name has to be typed for every file. Not to
mention I had some automated scripts that copied some files which are
now much more cumbersome as well.

> -> qvm-usb to assing usb devices

This was the big improvement (for me) in Qubes 3.2. Credit where credit
is due, this is awesome!

qvm-block on the other hand ...
- no attaching of image-files anymore (used to do my backups that way)
- detaching requires full path as well (horrible if blockdevice is in
dispvm)
- documentation of features is especially lacking (e.g. could do
qvm-block [TARGET] [SOURCE] -f xvdz, now frontend-device is a feature of
qvm-device I have to look up how to use every time I need it.)

>I tried I3
Tried KDE myself, led to horrible instabilities. (I understand and agree
with the reasoning to switch away from KDE, but still miss krunner though.)

P.S.: My point here is never something is impossible (except qvm-block
--attach-file), but rather that is has become cumbersome compared to
Qubes 3.x, especially 3.1!

sincerely
GammaSQ

[Chris Laprise]

On 11/21/2018 09:15 AM, Doesnt Work wrote:
> Thank you all for the direct answers!
>
> However, I'm not just talking about GUI-UX, but cli-UX as well.
> Especially the detailed documentation of commands is usually only valid
> for Qubes 3.X. Errors are rarely helpful but rather are uncaught
> python-errors (qvm-run [something] + CTRL+C = "KeyboardInterrupt Error")
>
> Additionally, tab-completion still doesn't work (which would have to be
> a new feature, but since VM-name-completion works for qvm-copy &
> similar, I am wondering why this wasn't implemented at the cli-level as
> well.)
>
> Let me give examples of the cli-shortcomings:
> Sven Semmler:> -> qvm-ls ... shows your qubes and their state.
> No memory/CPU-usage. Have to use xentop for that. Xentop shows CPU-usage
> per core? I guess? Works to determine most-hungry VM, not managing
> resources.

BTW I made a script to show this info in a more convenient form,
system-stats-xen:

https://github.com/tasket/Qubes-scripts

>
>> -> qvm-create, qvm-clone, qvm-remove ... are obviousqvm-create has horrible argument-dependencies. e.g. if --template is a
> dvm-template, --class has to be DispVM [everywhere else it's "dispvm"],
> not to mention --property auto_cleanup=True (I don't see the usecase of
> a dispvm without auto_cleanup.)
>
> qvm-run --dispvm [dvm-template] CMD
> fails too often and without obvious reasons for me to count. (Guess it's
> a RAM-problem.) And dvm-template is required, default-dispvm is not used.
>
> btw.:
> qubes-global-settings can't be used from the commandline but opens
> GUI-window.

Adding these 3 things as issues would be a good start to addressing your
list of concerns...

https://github.com/QubesOS/qubes-issues/

>
> qvm-copy now opens a window that needs interaction. This is awful for
> copying many files, VM-name has to be typed for every file. Not to
> mention I had some automated scripts that copied some files which are
> now much more cumbersome as well.

In dom0 you can use 'qvm-copy-to-vm' without any popup dialog window.

Otherwise, if you need to copy things in other directions without dialog
windows, it must be coordinated from dom0. You can run scripts in dom0
to handle the copying and/or set qubes-rpc permissions for guest VM
access. Setting these permissions could be more convenient though.

>
>> -> qvm-usb to assing usb devices
> This was the big improvement (for me) in Qubes 3.2. Credit where credit
> is due, this is awesome!
>
> qvm-block on the other hand ...
> - no attaching of image-files anymore (used to do my backups that way)
> - detaching requires full path as well (horrible if blockdevice is in
> dispvm)
> - documentation of features is especially lacking (e.g. could do
> qvm-block [TARGET] [SOURCE] -f xvdz, now frontend-device is a feature of
> qvm-device I have to look up how to use every time I need it.)

The documentation could be better here; I've been frustrated by it
myself. Are you aware that using 'losetup' first will allow you to
attach image files?

>
>> I tried I3
> Tried KDE myself, led to horrible instabilities. (I understand and agree
> with the reasoning to switch away from KDE, but still miss krunner though.)

KDE has been very stable for me on 4.0 using integrated Intel graphics.
I feel like the other options are inadequate... they can't do simple
things like put the monitor into power saving mode or allow you a few
seconds grace time to tap the keyboard when the lock screen appears, and
many more details. Its like going back to 1998.

>
> P.S.: My point here is never something is impossible (except qvm-block
> --attach-file), but rather that is has become cumbersome compared to
> Qubes 3.x, especially 3.1!
>
> sincerely
> GammaSQ
>

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, Nov 21, 2018 at 02:15:00PM +0000, Doesnt Work wrote:
> Thank you all for the direct answers!

Thank you for your valuable feedback!

Below I'll respond directly to the listed issues, but in general feel
free to report them in qubes-issues adding a note its an UX issue. In
many cases the fix is quite easy, especially in Qubes 4.0, but it isn't
always easy to think about all the possible use cases and how users
expect things to work (and whether we should match that expectation, or
clarify documentation and/or UI to direct them in the right direction;
or both).

As for the general direction, we've made deep architectural changes in
Qubes 4.0, which admittedly made some of UI from Qubes 3.x obsolete. But
having refreshed the core code made building UI/UX much simpler. And now
we're focusing on making use of that new base, to make it even better
than it was in 3.x. For example, there are upcoming tools to ease
keeping the system up to date:
https://github.com/QubesOS/qubes-issues/issues/2718
https://github.com/QubesOS/qubes-issues/issues/4085

> However, I'm not just talking about GUI-UX, but cli-UX as well.
> Especially the detailed documentation of commands is usually only valid
> for Qubes 3.X. Errors are rarely helpful but rather are uncaught
> python-errors (qvm-run [something] + CTRL+C = "KeyboardInterrupt Error")
>
> Additionally, tab-completion still doesn't work (which would have to be
> a new feature, but since VM-name-completion works for qvm-copy &
> similar, I am wondering why this wasn't implemented at the cli-level as
> well.)

I've seen some users written bash completion plugins for qvm-* commands.
We'd need to integrate one. For example this one:
https://groups.google.com/forum/#!msg/qubes-users/C1zUZGbVFok/l-akx0p1BQAJ
(or something based on it)

> Let me give examples of the cli-shortcomings:
> Sven Semmler:> -> qvm-ls ... shows your qubes and their state.
> No memory/CPU-usage. Have to use xentop for that. Xentop shows CPU-usage
> per core? I guess? Works to determine most-hungry VM, not managing
> resources.

Current RAM usage should be easy to add to qvm-ls, maybe even list it by
default. As for CPU usage, it is slightly more tricky, as it doesn't
exist as a single data in arbitrary point of time. It is "average CPU
usage over last X sec". As you can see after running xentop, you'll get
actual CPU usage values only after few seconds. We don't want for qvm-ls
to wait that long...
But surely there are ways around this issue. Maybe reading the values
periodically internally and caching it somewhere. Or using much smaller
time slice than xentop.

> > -> qvm-create, qvm-clone, qvm-remove ... are obviousqvm-create has horrible argument-dependencies. e.g. if --template is a
> dvm-template, --class has to be DispVM [everywhere else it's "dispvm"],
> not to mention --property auto_cleanup=True (I don't see the usecase of
> a dispvm without auto_cleanup.)

Well, actually DispVMs with auto_cleanup=False are quite useful too. For
example as sys-usb or sys-firewall:
https://www.qubes-os.org/doc/dispvm-customization/#using-static-disposable-vms-for-sys-

auto_cleanup=True means the VM will be automatically removed after
stopping it. But even with auto_cleanup=False, DispVM's _data_ is
removed when it's stopped. It's just that with auto_cleanup=False, you
can start it again (from a clean state), without having to create it again.

> qvm-run --dispvm [dvm-template] CMD
> fails too often and without obvious reasons for me to count. (Guess it's
> a RAM-problem.)

Oh, indeed after printing "Not enough memory to start domain 'disp...'"
there is a bunch of garbage messages.

> And dvm-template is required, default-dispvm is not used.

This works:
qvm-run --dispvm -- CMD

Something is wrong with arguments parser here...

> btw.:
> qubes-global-settings can't be used from the commandline but opens
> GUI-window.

Command line equivalent is qubes-prefs.

> qvm-copy now opens a window that needs interaction. This is awful for
> copying many files, VM-name has to be typed for every file. Not to
> mention I had some automated scripts that copied some files which are
> now much more cumbersome as well.

But even for old "qvm-copy-to-vm" you've got GUI window to confirm the
operation.
For automated operations, you can edit qrexec policy for qubes.Filecopy
service (/etc/qubes-rpc/policy/qubes.Filecopy) to allow it for given set
of VMs without confirmation. This way, you can use qvm-copy-to-vm and
specify the destination name on the command line.
For example add this rule:

# src # dst # action
mail-personal personal allow

> > -> qvm-usb to assing usb devices
> This was the big improvement (for me) in Qubes 3.2. Credit where credit
> is due, this is awesome!
>
> qvm-block on the other hand ...
> - no attaching of image-files anymore (used to do my backups that way)

You can, if you attach it to loop device first (losetup in that VM).
While this indeed is a useful feature, we've (hopefully temporarily)
removed it as it basically allows to access arbitrary file. This is fine
if you call qvm-block from dom0, where you have ultimate control anyway,
but not so fine when you introduce semi-trusted Management VM.
The "losetup" step is basically a way to whitelist which files can be
mounted.

> - detaching requires full path as well (horrible if blockdevice is in
> dispvm)

What do you mean?

> - documentation of features is especially lacking (e.g. could do
> qvm-block [TARGET] [SOURCE] -f xvdz, now frontend-device is a feature of
> qvm-device I have to look up how to use every time I need it.)

You mean the option is named "-o frontend-dev=xvdz" instead now of "-f xvdz"?
We can add an alias for that...

> >I tried I3
> Tried KDE myself, led to horrible instabilities. (I understand and agree
> with the reasoning to switch away from KDE, but still miss krunner though.)
>
> P.S.: My point here is never something is impossible (except qvm-block
> --attach-file), but rather that is has become cumbersome compared to
> Qubes 3.x, especially 3.1!
>
> sincerely
> GammaSQ
>

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlv192QACgkQ24/THMrX
1yyXtQf+LfHdviU59g5PKlPIR3BO00dfb+ZwKKIyVPhy12gkc9rzbiXDWWfvQApS
TYjhkUL6ma+Jns57D+JwjRaDQRkZZrA5ysSlWCV7/NhypvEOcEdmUidSGeaTJZUT
jqPRlC4X52XRJebzatWGBc2W5Jq+qYrq1sQIjIc02j2tDOyawxyL5KvpKV1X0kly
+ixUwAcxZw9Rogh4UtaLuaKNrtRml2uGpT3PKDBen/o/vx+bPiXsyU1G0haRx02W
SjIsX5A1xFITwmFzVqD5w874ypXGvVUZmzuYtT1xPLqgczulM3Vx8MbK9BN4TiTp
VMgtiBGlSCTaM1ONqJojjnpeJ5bcqQ==
=MiXD
-----END PGP SIGNATURE-----

[Ivan Mitev]

> I've seen some users written bash completion plugins for qvm-* commands.
> We'd need to integrate one. For example this one:
> https://groups.google.com/forum/#!msg/qubes-users/C1zUZGbVFok/l-akx0p1BQAJ
> (or something based on it)
>

FWIW the following has been working for me without any problem for the
past half year (R4):

https://github.com/Qubes-Community/Contents/blob/master/code/productivity/qvm-cmds-bash-completion.bash

(disclaimer - I wrote it).

The version you linked to supports more completion "cases" (eg.
qvm-backup, qvm-block) but the downside is that the syntax/options of
the qvm-* tools are duplicated in the script. Given the dev team's
workload I thought it'd be better to have a generic script and leave the
more advanced use cases up to the user.

[Doesnt Work]

Marek Marczykowski-Górecki> feelfree to report them in qubes-issues

adding a note its an UX issue.

Knowing the direction Qubes want to take, I will. Not knowing what
direction Qubes is taking, raising UX-issues in a security-project would
have felt out of place.

> I've seen some users written bash completion plugins for qvm-* commands.
> We'd need to integrate one.

Yes. I know, but I take dom0-security very serious and working through a
lot of code is tedious.

> Well, actually DispVMs with auto_cleanup=False are quite useful too. For
> example as sys-usb or sys-firewall

I stand corrected!

>> qvm-run --dispvm [dvm-template] CMD
>> fails too often and without obvious reasons for me to count. (Guess it's
>> a RAM-problem.)
> Oh, indeed after printing "Not enough memory to start domain 'disp...'"
> there is a bunch of garbage messages.

It's not even that, most commonly it starts and halts again, no reason
given. I'll write a more detailed issue.

>> qubes-global-settings can't be used from the commandline but opens
>> GUI-window.
> Command line equivalent is qubes-prefs.

Not entirely. dom0 memory boost, minimal qube memory and dom0 UpdateVM
don't exist in qube-prefs (though I guess dom0 UpdateVM maps to
updatevm? I would expect the former to be used exclusively for dom0, the
latter as update-proxy); there is "check_updates_vm" in qubes-prefs, but
"Check for dom0 updates" and "Check for qube updates by default" in
qubes-global-settings. On the other hand, there are many settings in
qubes-prefs. I would not have intuitively thought qubes-prefs to be
intended as CLI-global-settings.

>> qvm-copy now opens a window that needs interaction. This is awful for
>> copying many files, VM-name has to be typed for every file. Not to
>> mention I had some automated scripts that copied some files which are
>> now much more cumbersome as well.
>
> But even for old "qvm-copy-to-vm" you've got GUI window to confirm the
> operation.

And it was just that. I could let my script choose VMs, glance the
window and hit enter. Now I have to know what vm to type in. (I echo the
VM-name before qvm-copy)

> For automated operations, you can edit qrexec policy for qubes.Filecopy

Which would be fine for single-purpose VM-interaction. I had one VM
dedicated to ssh-ing my work-server, while also having a backup-VM and
general-purpose development-VM. So after doing some coding, I would want
to copy my work to backup and work. Since development has all sorts of
weird tools installed (node), I wouldn't want it to generally talk to
other VMs without me knowing. And since what files to transfer depends
on the project, a dom0-script makes little sense. (Yes, I could
implement a whole qrexec-service, but again, I criticise usability, not
possibility)

>
>>> -> qvm-usb to assing usb devices
>> This was the big improvement (for me) in Qubes 3.2. Credit where credit
>> is due, this is awesome!
>
>> qvm-block on the other hand ...
>> - no attaching of image-files anymore (used to do my backups that way)
>
> You can, if you attach it to loop device first (losetup in that VM).

Thanks, tried mount to create loopback devices, didn't work, gave up.
Move it from the "impossible" to the "cumbersome" bin. I'll write an issue.

>> - detaching requires full path as well (horrible if blockdevice is in
>> dispvm)
>
> What do you mean?

Qubes 3.2:
qvm-block -a work disp1:dm-1
qvm-block -d work

Qubes 4.0:
qvm-block a work disp7592:dm-0
qvm-block d work disp7592:dm-0

I need to type in the whole device-path. If the device exists in a
dispVM (which I do quite often to decrypt drives), I have to figure out
the random 4 digits of the specific dispVM that's holding the drive.

>> - documentation of features is especially lacking (e.g. could do
>> qvm-block [TARGET] [SOURCE] -f xvdz, now frontend-device is a feature of
>> qvm-device I have to look up how to use every time I need it.)
>
> You mean the option is named "-o frontend-dev=xvdz" instead now of "-f xvdz"?
> We can add an alias for that...

That would be great! But furthermore, qvm-block --help doesn't tell me
this is possible. man qvm-block opens man qvm-device instead
(confusing). The command is specified as
"qvm-device [options] DEVICE_CLASS ..."
Later on, the description of device_class "block" reads "available
options: -frontend-dev ..."
But instead of accepting "frontend-dev" as option ("qvm-device
frontend-dev xvdz block ...", I have to use the option "--option". This
is frustratingly confusing.

So much for Qubes CLI. As mentioned before, I'll write some issues.

Sincerely
GammaSQ