What would you like to see improved in Qubes OS?

  • Move back to KDE as default.

  • Tap the full speed of external drives. Rework sys-usb, removing speed bottleneck.

  • Rework sys-usb to play well with external peripherals like drawing tablets.

Productivity boosters:

  • Make an API such that 3rd party runners like Krunner, Ulauncher can make plugins that access appvms.

  • A more robust native runner that runs in Dom0, and streamlines tasks in appvms.

  • Streamlined attached/detach USB devices. Make it easier to script:

  • Direct calls to get drive data:

  • Direct calls to get drive description and UUID of attached devices.

  • Direct calls for sys-usb device ID.

  • Integrated Appimage, Snap, Flatpak support. Make it easy to install these containers and keep them updated in appvms thru the updater.

And last but not least…

Peace of mind when crossing boarders in the modern dystopia the world is spiraling into.


I’m still pretty new to Xen, but couldn’t spice channels provide better USB speed than the current USB/IP method? Perhabs an IVSHMEM device could provide better drawing tablet functionality.

Solene, thank you for what you are doing.

My use of the term Tabs is a bit like Favorites in a browser. With a quick click or two, one creates Tab for a specific webpages. But a Tab for quick access to a program.

I wanted to work up some examples with exact description, but I have been hampered by storms which have made power - intermittently available, internet less available, my need to do errands for other people. I am both old and lazy.

Thank you, Solene for your efforts.


Could we move the backup thread into a separate thread?

  • Easier handling of HiDPI displays (and multi-screen multi-DPI setups).
  • Easy switching for light and dark mode
  • Gnome as DE
1 Like

Done @solene, the thread was fairly long and the topics sometimes entagled, I did the best I could for both threads to still make sense.


Better hardware compatibility. I have 3 laptops, all made between 2019-now, from different manufacturers, and I have only been able to get one to work with Qubes (although with no external monitors). Too bad it’s the only laptop I have that is powerful enough to play games on… I could dual boot or get a new system, but I’d either need to buy more storage or buy a new laptop.
That being said - I also understand the incompatibilities are a result of the very specialized requirements. I just really like the idea of Qubes and would love to try and use it as my main OS.

It’s not the question with Qubes if it wouldn’t want it. It’s just that isn’t about like “there’s no drivers yet for these devices”. It is about device features by design that doesn’t fit Qubes security philosophy/findings.
You don’t buy hardware first then discover Qubes. it has to be the opposite.

1 Like

sys-usb speed, huh? I tested USB block devices and they seem to run on full 3.2 speed. Did not have a chance to try 4.0 however.

What’s your CPU model, and what’s the load for sys-usb? I suspect it to use a lot of CPU, and maybe slower CPUs are bottleneck for sys-usb speed.

Template-wise I would love to see:

1 Like

A couple of minor things:

  1. yes this has to do with backup but it belongs here. When you back up one qube, the dang thing insists on printing a list of qubes you AREN’T backing up. I’d like a flag that suppresses that. I’m using backup as a means of moving qubes between machines, and this message is really distracting (with the number of qubes I have the meaningful info flies off the top of my screen).

  2. Many of the qvm utilities will print a message instructing you on how to use the command if you type a non-existent vm as the VMNAME parameter. How about just printing “no such vm” instead of assuming the user doesn’t know the basic command syntax? In one case, I’m looking for the status and I may be checking to see if the qube even exists from inside a script; an error message there telling me I don’t know how to use the command is completely inappropriate in this case.

1 Like

I would like to have a video training course and a book available. The help provided in this forum is not always easy to follow for everyone.


I’ll throw out a variant. A qvm-type command to test for the existence of a qube, that won’t throw an error if it doesn’t exist. qvm-check throws an error and writes out “you idiot you got the command syntax wrong” error message.

The lack of such a thing is really messing up my salt scripts. I want to do something ONLY IF a qube exists and it’s NOT in fact an error if the qube does not exist…but salt pukes up an error anyway. (There are “only if” qualifiers in some salt states, but as far as I know there’s no way to check the existence of qube in them…again, without erroring out.)

It seems to exist already

[solene@dom0 ~]$ qvm-check backup
qvm-check: backup: exists
[solene@dom0 ~]$ echo $?

[solene@dom0 ~]$ qvm-check backu
usage: qvm-check [--verbose] [--quiet] [--help] [--all] [--exclude EXCLUDE]
                 [--running] [--paused] [--template] [--networked]
                 [VMNAME [VMNAME ...]]
qvm-check: error: no such domain: 'backu'
[solene@dom0 ~]$ echo $?

edit: I didn’t read completely, but qvm-check errors with 2 if a qube doesn’t exist, so you can discard its output and just look the exit error code :slight_smile:


That’s basically what I was doing.

I was trying simply qvm-check other-qube 2> /dev/null && run-some-command but salt was still detecting the 2 error status.

I just now hit on the answer, which was to write the command as if qvm-check other-qube 2> /dev/null; then run-some-command; fi which hides that return status successfully. (This is a cmd.run state in salt.)

Still, I’d like a simple test for qube existence and/or non-existence that doesn’t write a long error message if it doesn’t exist. Just write “does not exist” instead of “exists”. I’m constantly having to wrestle with gratuitous error output doing various things (this is only one among many), and --quiet options don’t shut it off as one might expect.

1 Like

qvm-check xxx >> /dev/null 2>&1

1 Like

Without knowing what the something you want to do is, it’s difficult
to help.
In the simplest case using requires and qvm.exists is fine.
For example, exists.sls has:

    - name: QUBE

create.sls has:

  - exists

    - name: test
    - label: purple
    - require:
        - sls: exists

This will create the qube test only if QUBE exists.


unman, thank you for your response!

I did not realize you could make an entire sls a “requires” (and that you could link such a thing with include); thus far I had only used “requires” for other states in the same sls.

Given my knowledge level, I did try something similar to this…basically I put the “exist” state in the same sls file as the command (which was to make Qube A the default dispvm of Qube B…i want to do this both where Qube A is created, and where Qube B is created, to ensure it gets done regardless of the order in which the two are created, but of course each sls must check for the existence of the qube created by the other sls before making the attempt).

The problem, at least with the single-file solution, is that when the state to run the command executes, it returns false because the prerequisite is missing, and I have an apparent failure of the entire sls file to run propertly. It’s not a failure, though; I simply want to run the command “onlyif” the other qube is already present.

And since your suggestion uses “requires” I suspect it would behave similarly…though I haven’t tried it yet.

I like to use “exists” to check preconditions for even starting to run the states in an sls file. For example, if I am going to delete sys-net (and its dvm template, and the dvm template’s template) then rebuild it, I damn well want to make sure the clone I made to temporarily handle sys-net duties actually exists! In that case, yes, I do want my sls file to report an error to me; using exists as a “requires” for the first actual command in the sls file is perfect for that.

But in my current case, both outcomes are correct; it’s not an error I must stop and “correct” if the other qube doesn’t exist (yet). A similar thing to what I am looking for is cmd.run having the onlyif qualifier, which I have seen used to check for the existence of a file before editing it. That allows the check to be made in the same state as the command, so either outcome is “valid” [provided there isn’t some other bona fide error that is] and not a reason to throw red messages on my screen and report error 20 at the end.

In fact if there were a way to check qube existence in an onlyif it would be nearly ideal; I can run qvm prefs on a command lilne. (In fact that’s what I did do, for some reason.) If the qvm.prefs state had onlyif, that would be even better–I could even get rid of a lot of ugly jinja in some places if that existed. However it doesn’t appear to be an option, according the the full list of qubes salt states on github.

In any case I did solve this…by running qvm prefs as a command line, inside an if block. So the command itself becomes my atomic “do this only if the qube exists” operation. As I reported elsewhere here, I ended up doing a cmd.run on qvm-check other-qube 2> /dev/null; then qvm-prefs ....; fi I did have a bit of trouble hitting on that exact command–other things I tried had mysterious syntax errors but only in the salt file, or would leak the qvm-check error to the state which would report False, but it’s past me now.

It’s clunky but it seems to be working.

Thanks again for your response. I hope I’ve given some food for thought for improvements to some of the “qvm” states in salt.

Now it exists: GitHub - jamke/qubes-completion: Bash completion for Qubes OS

1 Like