If it’s more secure to use OpenBSD for sys-net, maybe it should be the default then? Or is there some issues with it compare to the regular Fedora/Debian?
1 Like
I had a similar issue, I used vlc from rpmfusion, there is currently a conflict between live555 pulled by vlc, between the Updates repository and rpmfusion-free, so the update process always had something to report, and Qubes OS thinks there is an update pending.
I didn’t find a solution so I removed vlc.
You could check in any fedora-38 VM what’s pending using dnf check-update
– Incremental backups with the Qubes Backup tool.
Currently a backup of 100 GB of data in qubes from my system SSD to an external SSD takes an hour, and a lot of CPU power.
– Ability to change performance modes (power save, balanced…) from a GUI
– Make the Super key launch the application menu by default
– Bluetooth support, but disabled by default, with a warning message to users about the possible security risks of enabling it
I’d personally like to keep Xfce as default DE. I prefer KDE, but it gives me slightly lower total performance, especially during video playback. I’ve yet to test R4.2 to see if the newer KDE versions are lighter on CPU usage.
You could use GitHub - alols/xcape: Linux utility to configure modifier keys to act as other keys when pressed and released on their own. to use super to do something just when typing on it.
In addition, for a more gnome style “super” key, you could use xfdashboard
The solution was to wait for them to update the repositories, no user action was required. 
This is now fixed (I just updated few minutes ago).
updates
Changes:
----------
live555:
----------
new:
2023.06.20-2.fc38
old:
2023.03.30-1.fc38
vlc:
----------
new:
1:3.0.19-0.7.fc38
old:
1:3.0.19-0.3.fc38.1
vlc-core:
----------
new:
1:3.0.19-0.7.fc38
old:
1:3.0.19-0.3.fc38.1
2 Likes
I installed the whisker menu and mapped it to the windows-left super key, then I use its search field.
See also the useful @deeplow 's related post.
I created a new launcher in the XFCE toolbar with a big red icon (process-stop in Action icons) that executes the below command:
qvm-shutdown --all --wait
For help : qvm-shutdown -h or man qvm-shutdown
2 Likes
My own list:
- GPU acceleration. Gaming is a non-goal (games do a bunch of stuff, like anti-cheat, that interacts badly with Qubes), but CAD, video editing, and possibly GPU compute are in scope.
- Reduced RAM usage.
- Faster boot time.
- Lower audio latency
- Nested virtualization
- Nested IOMMU
- Qubes-in-Qubes (for testing, if nothing else)
- Wayland native, no more X11
- GUI daemon draws its own decorations
- virtiofs-based file sharing
- Secure browser that runs each origin in a dedicated microVM
- Hardened sys-usb that is secure against malicious USB devices
- Hardened sys-net
- Hardened malloc() everywhere
8 Likes
If you use kde instead of xfce4 as wm in Qubes R4.2 dom0, you’ll have this.
I think the biggest boom to qubes usability and popularity would be adding easy GPU passthrough support, and explicit instructions on how to do it. As people should be able to modify qubes to meet their security and usability needs.
Other than that I agree a send to cube option within dom0 UI specifically, and more colors lol
1 Like
also optional encryption for AppVMs when you boot them could be cool, like you can do with stand alone, but that could be difficult depending on how appVMs are handled under the hood
1 Like
Better would be to have a choice during install. Personally I choose Mate for desktop and Xfce for laptop.
I never use KDE or Gnome.
2 Likes
Free choice please. Wayland causes too much trouble for everything that needs root access. Xorg is better.
1 Like
I’ll add this to my list of wanted defaults/fixes. 
For a long time I thought it was just me imagining it, but there is a very slight delay in audio playback through headphones. (Offsetting latency in Xfce Volume Control does not have any effect within AppVMs for me).
TL;DR with new 4.2 update manager limitations I saw before when tried that solution may now be more manageable. Plus now I more fully understand how I can still make sys-net, sys-firewall and openbsd-sysnet all disposable you just gave me a Saturday project to try again. Definitely not a solution for newer qubesos users what I plan. Ton of configuration to do what I want including some command line work.
OpenBSD being more secure is very much openly debatable and my guess is the devs would very much disagree. I don’t believe at all it should be the default but an option. QubesOS in general being able to integrate the BSDs like it does linux would be what I would like to see. As it is, last I tried I couldn’t even get FreeBSD 13 hvm to have larger resolution than 1280x1024. I understand a lot of that is on the upstream QEMU and BSD devs (or me because hey open source) but shrug. Love QubeOS so a nice to have.
1 Like
X11’s design and Qubes’ use case are a perfect fit. What is currently done with X11 could be done with Wayland, but it would just be reinventing the wheel (X11) with a fresher codebase (which seems to be really what everyone wants).
I could take a look at making the ports for qubes-tools into the OpenBSD ports tree, but I have no idea what need to be ported. And if something doesn’t compile out of the box, someone would have to provide patches to make it compatible. This is maybe not be a big deal.
1 Like
It probably would be a fair amount of work is my assumption at well which is why only a wish list item on forum and not me bugging devs on mailing lists or something silly. I do believe though the QubesOS concept being able to play equally well with Linux and the BSDs pvh domU (ie qubes) and maybe even eventually dom0 would be awesome though but recognize touches a lot of different projects besides just Qubes.
Every time someone posts in this thread I am thinking about what I would like to see improved.
Turns out I am perfectly happy with Qubes OS as it is now from a feature perspective. There are however two things I would very much like to see improved:
-
#7624 is a big deal to me and in some situations limits what I can do without the need for a second (Windows) machine.
-
I am using a T430 for the ability to almost completely remove the ME and run Heads. Unless and until there is open hardware I don’t see this change. The performance with R4.1 is OK but noticeably reduced from R4.0. It might not be in the power of the Qubes OS team to do something about that, but if performance on those older machines can be brought back to R4.0 level I know I am not the only one who would appreciate it.
4 Likes