What would you like to see improved in Qubes OS?

I am not anti-sudo. I am anti-sudo-by-default.

I agree.

The corresponding topic:

4 Likes

Yes, with that pull request the Domains widget would show the outdated volume status for all disposables - same as Qube Manager. IMO it’s important to pass this information to the user, e.g. consider a browsing session in a disp1234 disposable that hasn’t picked up a security patch for the browser.

Maybe there’s a better icon for something being outdated/stale/old than :repeat:? Something that doesn’t imply a restart. (Although even with the PR, the Domains widget still wouldn’t offer the Restart action for disp1234 disposables - same as Qube Manager again.)

4 Likes

It is possible to exclude unnamed dips* qubes via something like:

if vm.klass == "DispVM" and vm.auto_cleanup:
    # do not show icon code here

Overall. this is a mildly debated issue which is hard to keep everyone satisfied. Power users are usually comfortable with this since they properly understand the under-hood mechanism with or without the icon. Let’s see what decision the core team takes on this.

2 Likes

My understanding, from the Qubes Summit, is that additional templates, packages, and VMs could potentially bloat an already large ISO. That is why additions like extra templates and specific AppVMs are best provided through Salt scripts from external, trusted sources like FPF.

3 Likes

Back to KDE.

I think KDE Activities is a more convenient way to handle Qubes’s compartmentalization.

It’s a pain having to install with XFCE and then install KDE.

At least there should be the option to choose between XFCE or KDE during installation.

3 Likes

you can create in memory disk, templates and appvms.
Create a RAM drive on startup, give it a btrfs filesystem, create a sub volume on it, set up a storage pool and clone template to the ram disk and then create appvm. Everything is now on RAm for that vm. copy the file system to use in
reboot script. QubesVM manager will pick it up as son as it’s all copied back in. (sounds complex but it’s no different to adding a new drive)

I’d like to make it easier to join and leave the Qubes OS project.

It would be nice to have a simple application which is offered at boot. It scans the computer to ensure that virtualisation is properly on, that there is enough memory, and that all devices are recognised. Something like the Windows Health Check.

It would also be nice to have a way of properly deleting Qubes OS once you’re done. The Qubes OS installer writes a large number of partitions to the system drive, and sadly some installers choke on this. Why, I don’t know. I tried installing Kali Linux over Qubes OS, and the Kali installer didn’t like it. I had to write a Linux Mint Cinnamon ISO to a USB key in order to get gparted, and purge Qubes OS. OK, in the big scheme of things, making it easier for people to leave is probably not high in the scheme of things, but it would be the professional thing to do.

Once you decide to wipe out QubesOS, find your disk (usually “/dev/nvme0n1” these days) by running "lsblk" in dom0, then you can run directly in dom0:
sudo dd if=/dev/zero of=/dev/YOUR_ROOT_DISK_NAME bs=64k count=100
Then you reboot (power button for 5-10s if unresponsive) and that’s it! Even Windows will install.

Edited to correct the usual disk name: it is “nvme0n1”, not “nvme0”.

2 Likes

You already can install Qubes on a USB stick. It will be slow and you won’t have sys-usb, but you’ll be able to test the OS without touching your current setup.

Qube name autocompletion for bash by default

p.s. Does anybody know how to do this or an existing implementation?

You can use GitHub - jamke/qubes-completion: Bash completion for Qubes OS

2 Likes

When deleting templates, first you have to type the template name, then the system confirms if it’s linked to any VMs. Many times I’ve typed the VM name and then find out it’s linked to 3 things, wasting time.

I really wish this were the other way. Check if it’s linked to VMs first, THEN make me type the name.

5 Likes

I’d like to be able to reduce the Personal (and System) storage max size from inside the qube’s Settings.

It’s a hassle to have to crate a loop device, attach it to a disposable VM to resize and then resize the LVM in dom0.

Extra points for a warning when reducing the size more than the available free space to avoid data loss, so I don’t have to do the math.

If I switch to KDE instead Xfce Am I breaking the security model of QubesOS?

A dark-mode switch icon would be great.
I switched everything to dark-mode manually following the guide here.
But recently found myself going outside and needing light mode.
But when back in doors, I would like to switch back to dark-mode.
Some people have posted doing this with scripts.
But it would be great if it was built in the the OS by default.
I would feel more secure if it came from Qubes official

2 Likes
1 Like

No, not really.

  1. Incremental backups
  2. Make using the GPU as easy as using any other device; i.e. I should be able to attach the GPU to a VM in the same menu I attach the block devices, the USB devices, etc.
  3. Even better, make it possible for a VM to “provide GPU” just like it can “provide network”, so I can run an LLM VM alongside a gaming VM.
3 Likes

You can’t really provide GPU through network. I mean by that, if you already have an easy way to attach a GPU to a qube, I don’t understand what “provides GPU” mean for a Qube.

You can’t really provide GPU through network.

That’s not what I meant, but I see I didn’t explain it clearly.

I mean that ideally users would expect the GPU to be available for all VMs when running apps that require it, like the browser.

If that’s not a good idea for security reasons, then at least make it possible for more than one VM to share the GPU.

And because a computer can potentially have more than one GPU, my idea is to assign the GPU to an HVM qube, and then allow this HVM to “provide GPU” to AppVMs.

I hope this makes sense.