Currently qubesd checks for vms, which shall autostart, if their set NetVM is running and awaits that state.
In my specific setup, a handful of AppVM which have a network connectivity are waiting for each layer of the network chain to boot.
sys-net → sys-firewall-ext → sys-firewall-int
Hence the boot of the AppVMs I want to use, is delayed by ~20seconds.
From my experience, I have never encountered a VM which needed to have the NetVM assigned on boot. In all cases the system behavior was the same as if the NetVM was assigned on runtime.
I would agree to the argument that there are use/edge-cases where a VM needs their NetVM to be present on boot.
But I think they are only that, edge cases. The majority of users would benefit from the change in startup behavior since everyone will have at least 1 or 2 network layers defined.
Or, you can simply set all the VM NetVM’s to None or as a default net qube to None in Global config, and assign NetVM’s manually during/upon startup through Qube Manager. Much safer conduct, if I am asked.
Support for the newest PC hardware (e.g., two PCI roots). If you look at my post history, you’ll see I had a hell of a time getting started with Qubes, because I had some PCI devices on a 0x80 bus and others on a 0x00 bus. Eventually I got help from somebody with the same issue, but it involved patching libvirt and updating it in dom0. I am still paranoid some dom0 update will break this…
Better KDE support. I am very used to pressing the Win key and searching for windows by typing – the Win key does nothing now. Also the lower left screen edge action is hard to activate.
Updated guides on running a Windows Qube. Microsoft has sadly (and predictably) made it harder to download the known working ISOs the guides were presumably written against.
I should add that Qubes OS is frikkin amazing and I owe a debt of gratitude to all the developers who made this a reality.
Or, you can simply set all the VM NetVM’s to None or as a default net
qube to None in Global config, and assign NetVM’s manually during/upon
startup through Qube Manager. Much safer conduct, if I am asked.
More open Forum, allowing open discussions.
I mean, users cannot delete their own posts or their own accounts… while GOD Mods** can delete/alter posts and threads with impunity.
I would love more boarder color options for VM windows. There are 8 colors now, but I would use more if I had access to more. One way to implement this would be to allow two colors to alternate in stripes around the boarder of a VM window (Imagine alternating between red and white, sort of like barber polls). The other way would be to let users arbitrarily choose the solid colors of window boarders. Arbitrary user selected window boarder colors creates a risk that users could choose colors that are too similar, and make mistakes (at a quick glance, users might mistake a brick red boarder for a light red boarder). But then again, users post their login credentials to github, so it’s hard to save people from themselves…
It would be nice to be able to copy more than just text between Qubes using the global copy and paste shortcuts. I would love to copy and paste images between Qubes for instance.
P.S. I should have combined my last 3 posts… Clearly I did not plan ahead… My bad.
As a new user this audio qube stuff is a nightmare. it would be nice to have the audio qube as another service qube like sys-usb, sys-net, etc. I have an external audio interface, a focusrite scarlett that is usually plug and play with linux systems, but trying to get it to work for audio in my new qubes install has been extremely frustrating.
UPDATE: I was able to setup my audio qube correctly!