3 versions of Whonix
Whonix KDE
Whonix XFCE
Whonix Gnome
And the problem is solved.
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.
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:
.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
Another option might be using no login manager at all. Perhaps using startxfce4 (IF using xfce, similar otherwise) / startx
. But:
/home/user/.xinitrc
. (Always problematic to write into the home folder as well as always problematic to use something other than .d
config snippets.)Still doable? Good idea?
Just for to be more future proof. There was not much discussion. Just this.
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.
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:
.d
folder (so no config file owned by a package has to be modified)https://github.com/Whonix/pkg-manager-no-autoupdate/commit/073d60f70ddfb83b88aba557eeb9bd3e74a26c34
https://github.com/Whonix/pkg-manager-no-autoupdate/commit/0aaddb5cc9ed23c4ca2c5fc6a2779371f0e9fbc0
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
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.