Hi John,

That's an interesting background and list of wants. I've been using Qubes for some time and can try to address a few of your issues.

On 3/15/19 10:31 PM, John Goold wrote:

* When launching a program from the Qubes menu, particularly if the
   target   appVM has to be started, the program often fails to be
   launched. This happens very frequently with the Text Editor.

   This is annoying as one waits a bit in case one is simply being
   impatient, or at least I do, so as not to launch two copies of the
   program by accident.

This well-known bug appears to center on programs based on Gtk+ and/or Gnome. The only way to consistently avoid it is to install Qt/KDE or other non-Gtk+ software in the templates. KDE works well and Debian+KDE is what the Whonix templates are based on.

The steps on Debian 9:
$ sudo apt-get remove gnome*
$ sudo apt-get install gnome-icon-theme task-kde-desktop
$ su -c "echo export XDG_CURRENT_DESKTOP=KDE >/etc/profile.d/qkde.sh"

After that, you'll need to adjust the Applications tab in the template's Settings, and possibly for some of the VMs that are based on it.

(Also switching dom0 to KDE is an option, and this has solved a raft of usability issues for me.)

* When a USB device is attached to an appVM, there is an appropriate
   notification. When it is detached, there is a notification that the
   device is being detached, but no notification to indicate that it has
   been successfully detached  so how long should one wait before
   unplugging it?

There is probably no delay required but a couple of seconds suffices for me.

* Ignoring whonix (I do not use it... yet), there are two template VMs
   in the vanilla Qubes 4.0.1 installation: Fedora and Debian. However,
   they have not been treated equally, with Debian being the loser. The
   Qubes documentation indicates that Fedora was favoured for security

IIRC there is mention that Fedora was chosen for convenience, not security. Fedora actually presents a security problem for Qubes and there is an open issue for moving Qubes off of it.

The problem with the Debian template is that its not preconfigured with an array of familiar apps, and when you do add them some of the default file/app associations remain set to unfriendly substitutes (like text files being associated to emacs, pictures set to imagemagik or gimp, etc.). Switching to KDE has set these associations to reasonable defaults.

Its also doesn't have the full set of kernel firmware packages installed but that's easy to remedy.

   Since I had been using Linux distributions based, directly or
   indirectly, on Debian, when I first set up Qubes, I created my appVMs
   based on Debian. That  was painful as I then had to install a lot of
   basic software.

   When I re-read the documentation, I realized the security reasons,
   so I switched all my appVMs (except one!) back to Fedora. It was not
   painful, but I would have rather have spent the time doing something

I would like to know where it says this about security. Most Qubes users consider Debian to be (in general) more secure. The open issue for migration away from Fedora is at:


   The kicker came when Firefox stopped playing Flash content in my
   untrusted appVM, complaining that I needed an up to date version of
   Flash. I installed the most recent version, but that did not solve
   the problem. The problem is/ was something to do with Fedora (or the
   version of Firefox for Fedora or ??).

I haven't used Flash in a long time so I can't help there. In general its best to find an alternative that doesn't rely on Flash, which is becoming a dead format. Typically Flash is replaced by HTML5 web apps (and most websites have made this switch automatic).

* Screenshot only appears to work from Qubes Tools. I can "add"
   "Screenshot" to appVMVs based on Fedora (but not on Debian). But it
   does not work -- The dialog comes up but, having chosen to select an
area, I cannot do so.
   Subsequent attempts to use Screenshot do not even present a dialog.

   Although I have not seen this documented anywhere (which does not
   mean it is not), it seems logical -- dom0 owns the screen (monitor),
   so it makes sense that it handles screenshots. However, that means
   screenshots are saved in dom0 and have to be moved (or, I suppose,
   copied) to the desired appVM. It seems a bit awkward. If one is in a
   program in an appVM and decides a screenshot would be nice, it is
   probably focussed on that window or a portion of it. Since the OS
   displaying the window "knows" what it is displaying, it seems logical
   that some kind of screenshot could be made by that OS, but restricted
   to its window.

   If not, why is it possible to "add" Screenshot to an appVM?

Qubes doesn't limit which apps can be installed in templates. So this is considered more of a "sensible defaults" issue, where screenshot apps are not preconfigured in templates, and are preconfigured in dom0.

As for saving screenshots, there is an open issue and a mostly-finished utility that attempt to address this. OTOH, I just use 'qvm-move-to-vm' from the shell when I'm done snapshotting.


* About a week ago, I started having a problem: I could not
   copy-and-paste between appVMs. Prior to that, I had been having
   problems with Firefox freezing in different appVMs. Rebooting the
   affected appVM solved (or should I say "worked around") the latter
   issue; however, it had no effect on the former problem.

The current Firefox ESR does have a tendency to freeze temporarily when memory gets low. I'm considering switching to the non-ESR 'firefox' package in Debian to see if the newer versions are better in this respect.

I think someone reported here in qubes-users that copy/paste stopped working for them. Since this is a dom0-controlled feature it may be that your preference for long uptimes is overlapping with a Qubes daemon stability issue -- sometimes a dom0 Qubes process will just exit, although I haven't experienced this with copy/paste and I reboot on average a couple times per week.

My Bottom Line:

I can live with most of the issues described above. What I cannot live
with (and worry about) are stability and reliability issues.

[Aside] I do not intend doing a daily full back-up. I do not wish to be
         hypocritical, so full-disclosure: When I was managing the
         internal hardware and software support teams at a Bell-Northern
         Research lab., I insisted on daily backups. When managing the
         "System Programming" group for a mainframe (same as the modern
         "System Administration") the scheme involved daily, weekly,
         monthly and  annual backups of data files and backups whenever
         the operating system was updated, withappropriate off-site

I'm about to release a beta for my backup utility that can perform quick incremental backups of Qubes volumes. The working title is 'sparsebak' and it works like Apple's Time Machine in a sense... you only need to do one full backup (ever) and it can quickly recover space from old backup sessions:


The idea behind sparsebak is similar to Time Machine -- that even VM backups should be so efficient that you could backup many times each day without experiencing a burden on your time or system resources. It depends solely on the amount of change your volumes incur, so that even very large files experiencing small changes are backed up in a flash.

Its pretty unique on Linux -- capable of updating a VM volume over Wifi in 1 or 2 seconds -- and I feel the 'new4' branch is already at least beta quality. The storage format is also simple enough so that regular Linux tools can recover data from an archive. Although its CLI-based, you might want to give it a try.

An alternative to this is to setup a Btrfs or ZFS storage pool for your VMs (if you didn't already install Qubes on Btrfs) and use send/receive for incremental backups. This also requires a Btrfs or ZFS volume on your backup server if you wish the snapshots to stay integrated (IIRC this is a requirement for ZFS anyway).

I need some reasonable assurance that data corruption on disk has a
very low probability. I need some reasonable assurance that the
operating system (the combination of Xen and dom0) is stable.

The best assurance is regular backups. I don't know what caused your glitch but I've had vanishingly few on Qubes myself since 2013.

However, Qubes does require the use of snapshot-capable storage for reasonable efficiency and this is not yet Linux' strength.

Between Thin LVM (Qubes default) and Btrfs storage options my experience tells me that Btrfs is actually the more reliable system, as it can survive system crashes even better than plain ext4; Storage integrity is a core goal of Btrfs so this is expected. Another option that offers high integrity is ZFS for which a Qubes guide exists.


I hope this response helps you out some. Right now Qubes appears to be in a state that's mostly suitable for "security techies"; There is certainly room for improvement and your critique has made me think that some new issues need to be opened to help address the usability issues.


Chris Laprise, tas...@posteo.net
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to