Enhanced inter-vm networking:
I know, this is not the Qubes’ way to do things, but it is a task one has to handle when simulating client-server models with different VMs.
Trying this with little knowledge in Qubes’ details is much more risky than having one Qubes-supported way. It does not need to be recommended, but it should be a possibility.
Is kde scriptable? I used few times and it seems very complete but can it be orchestrated or does it rely on interactions?
I’m pointing this out becouse I find xfce4 legacy gold.
There’s only an essential choice in the ecosystem of xfce4, but well understood. I find kde very powerful but a potentially intrusive.
Btw Thanks a lot for your templates and contributions, I’m using them
Hi, I agree on the fact that privacy Can bacame the default standard if the os is simple enough for broad adoption. QubesOS position itself as the best suited solution to provide a platform for that. I don’t want to see or aim for it to be simplified because the more it goes toward broad adoption the further it gets from QubesOS users’ specialiezed uses.
What I suggest is for you to envision the safest default settings that can work for every day users in a stable way on consumers devices that support it. Pre-configrure multiple setups of vms in standby mode ready to be used and finally produce a xfce4 themed, simplified desktop experience that is intuitive enough.
What I’d like to see improved:
I’d like to see the built-in privacy in the OS, doesn’t mean default privacy, but just stuff I could tweak in the settings that would make it private without having to fight with the OS itself to make it so, like it is right now sadly.
See related issues: Thanks, but no thanks [Kudos to Qubes and Kicksecure/Whonix, but not confident enough to use them] - #34 by de_dust2
I’d like to be able to pay a license for the OS and have support from the qubes team. I’d like for them to pro-actively work on the documentation and privacy issues.
Having strong security without conducting regular, independent security assessments and openly sharing the results is like surrounding one’s self with superficial friends who only flatter you — you can’t truly know whether their praise is true or not until you hear the evaluations and critics of an unbiased outsider.
God I wish the qubes team could see my reply full of wisdom
I wish the option to install software updates using sys-whonix also applied outside of templates.
Any qube can have sys-whonix or some other Whonix Gateway qube set as its Net vm temporarily so fetches for software updates go over Tor.
Easier ability to add a video card to a desktop box. Fullscreen tends to get jerky, even with lots of ram and a fairly fast motherboard on a Debian vm based system.
…if we only had iGPU virtualization…
As a new user to Qubes OS and Linux too.
1- Documentation " feels old and not enough GUI steps included, although as of 4.3, many things can be done from GUI. " plus moving everything else to Archive section covering 4.2 and less" + Would be great to have it on forums too.
2- System to not allow you from doing things like, block yourself from using USB keyboard and mouse.
3- More Templates options to be downloaded “OS”, and other solutions ready or easier way to implement security products such Pihole, Opnsence and such.
4- Wayland would be a great to have it soon, and a light yet efficient DE as Cosmic “rather than heavier options such KDE and GNome”.
5- An easier option to manage Standalone resolutions, maybe from the Advanced tab at settings.
6- My last so import point, to have easy guides for non prof guys, some would solve your problem by telling what to do, yet you need someone else to explain to you what he/she has said :D.
Thank you
Little quality of life things, like the shorting of Qube’s menu Favorites in 4.3.
Can we have a default shorting option, or persistence of the last user selection?
Do I really need to short my Favorites every time?
Also, please fix the menu bar icon’s background.
Things like these are some, easy to fix, low hanging fruits that have an impact to a new user that is trying Qubes OS out.
For example, we have by now a solid way of isolating audio in sys-audio. Why not implement that out of the box?
If we want to expand the user base, Qubes OS has to be more accessible.
For one thing, because it doesn’t work for everyone. Make it the default and some people will simply lose their audio and we’ll see questions about how to remove it.
My audio goes through the HDMI adapter for one of my monitors. Never could get sys audio to work with that configuration, and believe me, I tried. (It possibly has been modified to handle that case since then, but I’ve essentially given up on trying to work on it.)
I only got it to work by added a USB-to-audio thingamabob to my system–and then the audio quality was noticeably worse (almost certainly the hardware’s fault, not a sys-audio issue).
There will always be this forum to discuss complicated setups, but the vast majority of users probably wouldn’t change a thing on an official solution (in this example sys-audio).
I don’t see why these new users will also have to go through the trouble to set that up on their own, on top of all the other things they deal when starting up.
It’s not to hard to make the learning curve gentler.
See also: Why is Qubes OS project team so small?
It would be cool to have a feature to automatically shutdown NetVMs when the last attached qube is shutdown
I have a little dom0 script I run for this when I want to free up memory:
#!/bin/bash
# Order matters
netvms_to_shutdown_when_unused=(
sys-pihole
sys-vpn-1
sys-vpn-2
sys-firewall-lan
sys-net-lan
)
for qube in "${netvms_to_shutdown_when_unused[@]}" ; do
if qvm-check --quiet --running "$qube" 2>/dev/null ; then
# Check to see if there are no running qube with this qube as netvm
if ! qvm-ls --no-spinner --running -O NETVM | grep --quiet --fixed-strings --line-regexp "$qube" 2>/dev/null ; then
echo "Shutting down $qube"
qvm-shutdown --wait "$qube"
fi
fi
done
Thanks for the links
I see that me and @Euwiiwueir had a very similar idea for a workaround 
.
I’m trying to build a libvirt hook that automatically stop an unused netvm when its last Qube is shutting down, except sys-firewall and sys-net.
But I get a weird behaviour, something hang in the system and the Qube is never stopping completely, I need to shutdown qubes Os and wait 3 minutes for systemd to really kill the task. I think my issue is that I’m polling the state of the Qube while it’s halting, and it creates a circular dependency. The Qube will stop after the hook finished, and the hook is waiting the Qube to close…
An official VPN guide that is used by most users so that we can all leak test it. I’ve leak tested several of the “community von guides” that are posted on the qubes forums and many of them have LEAKS! I suspect most of you don’t do packet captures on your router and check for ALL scenarios. early boot race condition leaks. Unexpected network disconnection leaks. Computer crash/sudden shutdown. THE VPN SETUPS LEAK!
on another note. WHONIX does not leak under any of these conditions.
Speaking of improvements, there is a cleaner way to filter with qvm-ls (new in 4.3?)
Instead of:
if ! qvm-ls --no-spinner --running -O NETVM | grep --quiet --fixed-strings --line-regexp "$qube" 2>/dev/null ; then
Can do:
if ! [ "$(qvm-ls --no-spinner --running --prefs=netvm="$qube" --raw-list)" ] ; then
Or:
if ! [ "$(qvm-ls --no-spinner --running --netvm-is="$qube" --raw-list)" ] ; then
Plenty of other useful filtering options in the manpage.