I love Qubes OS and cannot imagine my life without it. Thank you to all developers for such an amazing work.
I hope I can help to prioritize tasks by discussing some UX pain points. Would anyone like to list and discuss their major pain points of Qubes OS? There was a good issue about it, but it was closed as not belonging to the issue tracker. I think it may belong here instead.
Personally, I suffer from the following issues:
Divided UI for managing qubes: Some actions are only available with Qubes Domains widget, while others are only available with Qube Manager. Sometimes they intersect. I cannot do everything automatically, without thinking, because I always have to understand, which thing I have to use. Examples of tasks: run a program (depending on what it is, it may be better to go to the widget or to the QM); start/stop/restart (widget/widget/QM, respectively) and so on. I loved Qubes Manager in Qubes 3.x, because I knew that I could find there everything I need. Related issue.
Some graphical tasks are quite slow and/or require a lot of CPU resources. I guess this is because AppVMs use a software-only (CPU-based) implementation of OpenGL. It seems one cannot do much about it, since it’s necessary for Qubes OS GUI isolation. Related issue.
If I create a new sys-net and switch off current sys-net, all updates will fail. I have to add/change the related Qubes services, but it’s quite inconvenient. Why can’t they be created automatically for every qube which “provides network”? Also, similar problem with sys-firewall and time syncronization. Also, similar issue with proxy-vm.
Clipboard (ctrl+c) is wiped when I close the window where I cut the text. ctrl+shift+c helps, but…
Icons in system tray are blacked out or disappear every now and then. Related issue.
When you have too many qubes, it becomes hard to manage them. Groups in Qube Manager and manual ordering would help me tremendously. Related issue.
Pausing can break your qube and there is no warning about it. I did loose some relatively unimportant information due to it. Related issue. Another one. I hope it can be solved without removing the feature. Could we hibernate the qubes instead?
What are your personal pain points? Perhaps we could even make an importance poll later.
While some of your points, to me, seem more of a preferred personal use case scenario, id like to touch on [3] … I found qubes one some hardware could be very sluggish from a user interface perspective. I found that optimizing for 4k made things way faster. https://www.qubes-os.org/doc/gui-configuration/
It may help to reorganize these in “domains” (not Xen domains). For example, the use of work-mail, work-documents and such. In order words, one may think of qube names as [group]-[name]. That way they will be neatly organized.
DispVMs taking too long
if you don’t mind the risk of some open documents being able to see other open documents, then we have a recent thread discussing a possible solution to this:
Divided UI for managing qubes
I actually haven’t actually experienced this. For 90% of my actions I only need the Qube Domains widget (and some i3 shortcuts)
More examples: Run terminal/file manager/custom program (widget/QM/QM); check CPU usage/RAM usage/Disk usage (widget/widget/QM). Addingeverything to the widget will make it cluttered though.
I feel that such separation is pretty arbitrary and should be reconsidered. It would be better to have sorting in Qube Manager by several fields simultaneously, e.g., State → Name. Such sorting would reproduce the Qubes Domains widget (i.e., will show the running VMs on top) and will allow to have more customizable columns.
In addition, the order of the qubes is different in the widget and QM (unless you use sorting by name. I prefer sorting by TemplateVM). It does not look like a simple problem to solve, because auto syncronization of sort order would probably be quite unexpected for users. Also, I don’t like the very fact that it is a widget. I have many important things in the system tray (instant messengers, battery etc.) and this adds unnecessary clutter.
(Offtopic: Same for disk usage; couldn’t it be an item/plugin for the xfce-panel?)
Note that those are just my preferences and I do not expect that everyone shares them. A poll would probably help, after we collect enough pain points.
Time synchronization issues. Every time after waking up from suspend, the time in all VMs is wrong (the same as it was before suspend). Manual updating it with qvm-run qube_name 'sudo qvm-sync-clock' helps, but is annoying. If I have no Internet upon wake-up, the time is wrong also in Dom0 and the above synchronization does not help. Related issue. Another clock sync issue.
(Offtopic: this issue can probably be closed.)
After every backup with GUI, I have to manually start backup-restore to verify the backup. Very time consuming, should be automatic. Related issue.
“Needs restart” icon was removed from Disposable VMs, which makes it unclear whether they are up to date or should be used with care.
I think this is more likely a task for the “applications menu”. If you’re on XFCE, replacing the default applications menu with whisker menu (which comes by default) may lead to a better experience (it even supports search!)
I describe my config here:
But these are already on the Qubes Domains widget. No?
No other commenters?
Don’t want to whinge, Qubes generally works well enough, and much better than my previous setup using multiple user accounts under one X server.
OK the first pain point is an issue that is 5 years old now and rated low priority: Allow specifying qvm-block device by UUID · Issue #2272 · QubesOS/qubes-issues · GitHub. I wrote about my problems in duplicate issue: qvm-block persistent config is too fragile · Issue #3437 · QubesOS/qubes-issues · GitHub. I avoid this problem by avoiding restarting Qubes if at all possible - now I am impressed with how solid dom0/Xen is as my last run was up 480 days without a glitch (w/o ECC mem). Every time I restart, all my external (to Qubes) disk partition device names and also USB device numbers get shuffled like a deck of cards - a real PITA to work out what persistent attaches were there before and reassign them correctly. Obviously all the developers must work on laptops.
2nd major pain point has also been outstanding for years - I did find an open issue a while back but cannot now - can’t avoid this one - after switching desktops focus stays on the previous desktop if windows in same VM are present there, and overlap those present on the new desktop, until after first input action. Get mouse over popups from previous desktop, and worse, the first mouse button push is sent to the wrong desktop, possibly resulting in you sending a partially composed email or any number of other missteps! One has to always select a window border that does not currently have focus after a desktop switch to ensure you are not caught out. Still forget sometimes - hit select somewhere, and nothing happens - #@$! - switch back to see what I did! Perhaps because I always use a keyboard shortcut to desktop switch? Don’t understand how this is regarded as low priority.
One minor point: I have about a dozen shortcuts on my desktop. As I usually have the Qube manager on the left side of the display, so I put the icons of the shortcuts along the right side of the display. Sometimes, after booting, several of these icons - mostly the same ones - are put in the default locations on the left side of the desktop, while the remaining ones stay in their intended positions on the right side. This happens for shortcuts to serveral different VMs, but curiously enough, not for all shortcuts of the same VM.
R4.1 has a new Grub boot menu. The colours of this menu have a rather low contrast, which makes it difficult to read on some monitors. Enhancing the contrast would make this boot menu more usable, in my opinion. Increasing the character size might help, too.
It seems that Qubes remembers the screen position of the icons for the program starters at the moment when these starters are called the first time, i.e. when the message is displayed that the starter is not trustworthy. The starter remains at this position after the next boot. Subsequent calls to a starter have no effect.
ditto on this one. I would go further and suggest that the Qubes Manager instead of phased out (which it was at one point?) to give it additional functionality, make it the “qubes equivalent” of the xfce “settings manager” - for those power user wannabes (such as myself) who are not as adept at digging into the innards qubes cli.
things such as:
ordering, or even organzing into a tree, the different vms.
adding the “connect device to” option back.
the ability to restart a proxy vm w/o having to ensure all appvms are disconnected
the ability to add a template, while its not that hard, for noobs esp installing an new template is not trivial either.
perhaps adding some of the xentop type info to it, like cpu/vcpu usage, mem usage, and perhaps giving proc/mem priority (like high, normal, low)
something like “patterns” in addition to colors, some of who are color blind (or partially in my case) can not see the difference in colors so well, so some sort of pattern differentiation would be useful in general, not just on the qubes manager icons.
I am not sure if the below are major UX pain points but to me they are kinda, and at the very least are major pain points.
Adding in some of the things that have to be done manually and requires some docs reading.
Things like the option to have X, Y, and Z types proxyvms (openvpn, wiregard, or even i2p [ok maybe not that last one]) but setting up proxy VMs is really quite difficult so having the option as part of the setup would be really helpful
picking windows managers and interface options (polybar, rofi, etc?) esp for 4.1 as i think there will be a gui domain? the option to add kde, i3, etc would be really helpful
the option to install community things, like the kali, gentoo (hardened!), arch, ubuntu (zfs 4 linux?) either when selecting whonix, types of app and sys vms, not to mention minimal templates for things like proxy vms, or maybe later in the install process - maybe an easy net install option?
split browsers/wallets/keys setup option during install
selecting what will be installed on what drive, this is really big for me as I would very much like to have some redundancy built in like a raid-ish 1 ssd and similar platter drive redundancy so some of my really big VMs i can put on a platter and the smaller ones i use more often on the ssd. I think its supposed to be possible when setting up LVM but its totally unclear how… and seems like an ideal time to be able to set it up to be easily… set up.
So I see that other people are also affected. In case you have a problematic (or no) Internet connection, (wrong) time in qubes will not be synchronized with (correct) time in dom0. My biggest pain so far I would say.
anyone else got firefox working for video? I followed the guide by installing the different media decoders/encoders along with firefox, but compared to Chromium, I still get all those graphical glitches when playing video I got on R4.0.4, (which I no longer get with Chromium on R4.1). Advice appreciated, I hate using chromium.
The most significant, MAJOR issue for me (R4.1) is this - I cannot attach my phone, major annoyance.
I have read snippets from github and the mailing lists of a more abstract overview of custom kernels, but it seemed conflicting, and the docs and github just refer you to mailing list users who’ve tried to hack custom kernels, instead of providing proper documentation references.
I don’t want to go off-topic, maybe this isn’t UX related as such, but given the lack of documentation and differing advice across different qubes channels, I’m no longer clear. 1) Are there security implications to custom kernels? (i.e. is there a super duper modification in dom0 that can only work with fedora kernel and I would have to manually migrate this to my custom kernel?) 2) (really what I’m lacking, which would answer the question) - What is Qubes actually doing to the kernel? What modifications are being made? What does it need to function (respective parts - xen, qubes packages/interfaces)?
Really 2), answers 1). I’ve read that some custom modifications are made to dom0 kernel which make it difficult to change dom0 distro (but apparently new&upcoming qubes APIs make this less of an issue?). I understand the abstracts of kernels, and I understand the abstracts of Qubes. What I do not understand is what Qubes needs in a Kernel (in dom0, and in a VM), for xen, interVM comms - to work with various qubes packages, etc.
If I understood this, I could then go an build a custom kernel. Idk about anyone else, but I find forraging for custom kernel building docs easier than understanding what Qubes needs kernel wise, and what the implications are.