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
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
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
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.
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.
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.
Some things for features come to mind that may already be possible but I haven’t found the methods for them yet.
Screensharing - I’ve got people I socialize with that want to see what Qubes is like without going through the hassle of configuring a system themselves. Additionally, when teaching others about offensive security previously I would screenshare the VM in use so they can see the commands ran, and the behavior. This will be an increasingly valuable capability as I build out a lab with a simulated active directory environment as well as non-windows systems.
Screenshots - something more like flameshot or spectacle that can be trusted in dom0, the current screenshot functionality leaves a lot to be desired. One area that could be improved upon if you consider the flameshot or spectacle approach is to also have the ability to obsfuscate selected areas of a screenshot prior to writing to disk.
Syntax completion was mentioned previously, I’m currently using fish for this because I haven’t looked up how to copy and paste into dom0.
UX wise I’m not personally a fan of XFCE but this makes sense, reminds me of Trusted Solaris. It works well enough that I don’t necessarily feel like going out of my way to try to go try the KDE configurations listed in some threads I have seen. However some options that preserve the security of the platform would be nice. KDE was mentioned, dunno if the switch away from KDE was because of Plasma going all in on Wayland and if Wayland has some risks I’ve yet to learn about, but if wayland is an option then KDE isn’t a bad option, but I would probably opt for something like sway+hyprland for window management while still maintaining the ability to use a mouse and have a non-TUI file manager.
Official Arch support would be nice, really just interested so I can slap some services into a template and have another template with blackarch for pen testing.
Just as a short aside couldn’t get it working with 4.2 with those directions (Got it working in the past with 4.1 but didn’t like what a hassle it was to restart on any update on sys-firewall or sys-net and having to restart both every time). Never could get the OpenBSD sys-net to route packets from sys-firewall to outside world even though got OpenBSD sys-net internet access. The hacky forwarding script would complete successfully and I could ssh into sys-net as a test but it wasn’t forwarding packets. Messed with pf from router directions and setting net.inet.ip.forwarding to 1 but no dice. Just decided to stay with a Fedora 37 minimal disposable as sys-net. Less heart ache. Especially once I realized that the OpenBSD hvm console was freezing up after suspend/resume anyway. Bad enough I had to literally patch the OpenBSD realtek re0 driver to work with qemu as it was to avoid watchdog errors. Sign it wasn’t meant to be. Still have an OpenBSD standalone console for sshing around my network.
FYI, you can make it considerably faster and less CPU-intensive by turning off compression (if you haven’t already done so), but the resultant backup file may or may not be larger, depending on the compressibility of the data you’re backing up. (Trying to compress incompressible data just wastes time and CPU cycles while sometimes making the output file larger.)
In general, only competitive online multiplayer games use anti-cheat. There’s a whole universe of games out there that don’t fall under that category.
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).