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,

Ego

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 Meta-ticket: suggest/remove default applications in official templates ¡ Issue #1781 ¡ QubesOS/qubes-issues ¡ GitHub 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.

1 Like

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

Good day,

Well, Arch has a quite extensive list of all the Display Managers we could use: Display manager - ArchWiki

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,

Ego

1 Like

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 - #19 by HulaHoop

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.

1 Like

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.

2 Likes

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

The version in sid works.

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

https://github.com/Whonix/kde-kdm-autologin/commit/6fc21deccbd4347b7ef69437b41fe382a2db448d

https://github.com/Whonix/pkg-manager-no-autoupdate/commit/073d60f70ddfb83b88aba557eeb9bd3e74a26c34

https://github.com/Whonix/pkg-manager-no-autoupdate/commit/0aaddb5cc9ed23c4ca2c5fc6a2779371f0e9fbc0



1 Like

https://github.com/Whonix/whonix-repository/commit/01fb4752b34406dda757f1d0d924e29451075294
https://github.com/Whonix/whonix-repository/commit/bdd3e265529e43bd65d78d15938b7af60bd3cf54
https://github.com/Whonix/whonix-repository/commit/4aad275d5942bf2060c94e0e8d93023f256ac297
https://github.com/Whonix/whonix-repository/commit/4017462c186ff714e9d4bf6add0999639be2f788
https://github.com/Whonix/whonix-repository/commit/d617f1f8a38593e972cf6135d30cba3f22455283
https://github.com/Whonix/whonix-repository/commit/b35f3ee94facc3c30c8588b30b10331b21e2d98a
https://github.com/Whonix/whonix-repository/commit/0be9e499d6308167de04bf7f89bc27d1753c7417

1 Like

https://github.com/Whonix/whonix-repository/commit/93caaa8d2137eae0557d895aa1223434252c06cf

1 Like

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

Virtualbox might not be suitable for Stretch
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794466

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.

1 Like