Re: [qubes-devel] Where does Qubes-UX fit in?
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
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit
Re: [qubes-devel] Where does Qubes-UX fit in?
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. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/4ce0f585-aba1-9d18-9a3d-feab6a4d567d%40maa.bz. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Where does Qubes-UX fit in?
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 -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/35611bfc-458f-1afc-d79a-30b05db2ab6c%40gmx.at. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Where does Qubes-UX fit in?
-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- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/f922897d-5548-e66e-43e0-25323884b79e%40SvenSemmler.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Where does Qubes-UX fit in?
On 11/20/2018 02:30 PM, Doesnt Work wrote: 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? 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 -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/254ff1a0-21af-a428-962c-9d4eaf85bcb6%40posteo.net. For more options, visit https://groups.google.com/d/optout.
