updating Whonix from jessie to stretch / Migration to Gnome-Shell / port to GNOME-ish applications


3 versions of Whonix

Whonix KDE
Whonix XFCE
Whonix Gnome

And the problem is solved.


Good day,

You only said:

However, that is simply not true. Stating something doesn’t make it true. The facts speak a different language, the developement is actually very efficient and constant for what they do: http://lxqt.org/releases/

You seem to either, not understand how big changes on a desktop enviroment are being developed, or you have some other real reason you didn’t tell us about.

3 Versions = 3*The work

Not viable.

If you don’t like whichever UI we use in the end, you may INSTALL whatever you prefer YOURSELF. No harm done.

Have a nice day,



After 4 years of development LXQT still unusable.
LXQT virtually indistinguishable from LXDE. LXQT is LXDE ported from GTK to QT. What’s the point of this in our time? When this project was born, people just do not like new GTK 3. And today, even XFCE gradually switches to GTK3. https://blog.xfce.org/
LXQT not always work after installation and there are quite a few bugs.


App uniformity… The history behind that is that @bnvk used to lead for Qubes usability. Generally to improve usability, once has to reduce the mental load for the user. Makes sense. His view was, that users who used the Fedora template who learned how to use applications there, be it NetworkManager or kate text editor, would benefit if they must switch to a Debian template for some reason, if they were presented with the same default applications.

(“Just install it.” doesn’t cut it from usability view. Mental load. Knowing the names of applications used beforehand, how to install them with Qubes difficult installation in TemplateVM and required AppVM reboot…)

The same reasoning then would apply for switching around Debian, Fedora and Whonix templates. I am pretty sure that lead to https://github.com/QubesOS/qubes-issues/issues/1781 being created. Now, since that does not seem like a Qubes goal anymore, no need to port Whonix from KDEish to GNOMEish applications just for app uniformness sake.

Similarity to between Non-Qubes-Whonix and Qubes-Whonix, similar package dependencies (includes app uniformity between Non-Qubes-Whonix and Qubes-Whonix) makes it a lot simpler for me to maintain both, Non-Qubes-Whonix and Qubes-Whonix. Any fix/change on the one will likely work for the other also.


It’s questionable how much of these workarounds broke after jessie -> stretch version upgrade.

xfce4 on the other hand does not seem to require any workarounds since it is modular by design. In its minimal installation (–no-install-recommends xfce4) for example it seems like it does not even come with powersaving. The only workaround that apparently is required is disabling that default bottom toolbar.

I am still investigating which path seems more feasible.


I learned desktop gnome its functionality .I was pleasantly surprised!
I for whonix to use the desktop gnome it’ll be cool!


Yipee! another non-fact based opinion.


IF using XFCE. If not lightdm… What is the most XFCEish login manager? It doesn’t have its own login manager? The login manager required for Whonix apparently does not really matter. Only feature so far that seems required:

  • a config file that can be dropped into a .d folder to enable auto login for user user (good usability feature for Whonix in VMs)

So perhaps xdm or lxdm? Don’t know yet if they support that feature. TODO: research

Lana's Linux Security Education

Good day,

Well, Arch has a quite extensive list of all the Display Managers we could use: https://wiki.archlinux.org/index.php/Display_manager#List_of_display_managers

According to it, both XDM and LXDM offer a form of passwordless/auto login.

Sorry, might have missed something but why was using LightDM with XFCE discarded?

Have a nice day,


Lana's Linux Security Education

Another option might be using no login manager at all. Perhaps using startxfce4 (IF using xfce, similar otherwise) / startx. But:

  • probably better to avoid editing /home/user/.xinitrc. (Always problematic to write into the home folder as well as always problematic to use something other than .d config snippets.)
  • probably better to avoid virtual console auto login.

Still doable? Good idea?

Just for to be more future proof. There was not much discussion. Just this.

updating Whonix from jessie to stretch / Migration to Gnome-Shell / port to GNOME-ish applications

Therefore I thought it is a good idea to use a display manager that does not get removed from Debian in stretch + 1 to avoid double work and migration issues.


Another topic we should look at is wayland support. GNOME and KDE are forerunners in that respect. XFCE is still on the way to porting to GTK3 which it needs for any basic wayland support. GTK4 is being planned right now. So they are way behind.

Wayland means getting rid of a huge security hole that is X. At least in Stretch X doesn’t run as root anymore but still.

Lana's Linux Security Education

4 posts were split to a new topic: Lana’s Linux Security Education

Lana's Linux Security Education

The version in sid works.


Lana's Linux Security Education

kdm was removes from Debian. So a new display manager has to be found so or so.

I haven’t found a great replacement yet. Ideal candidate needs just two requirements:

  • supports drop-in .d folder (so no config file owned by a package has to be modified)
  • supports auto login






During the upgrade to stretch. virtualbox-guest-x11 is removed. This is because of…

Virtualbox might not be suitable for Stretch

So VirtualBox might not make it into stretch. And thereby VirtualBox Guest Additions neither.

virtualbox-guest-x11 is still installable from unstable (sid) though, which is more convenient during development than manually installing it.