This would create a forest (several trees) of VMs that have access to the GPU connected to a particular HVM. This forest is similar to the forest (if you have more than one sys-net) of the network access in Qubes OS. But accessing the GPU does not require Ethernet.
It’s not possible to share a GPU this way, I understand the hierarchy tree to assign a GPU, but this would be separate from qubes themselves, as a qube has no known method to share a GPU, it must be attached directly to a qube, and that qube must be a HVM.
I might be saying something that makes no sense, but can’t an HVM receive a load of work to do from an AppVM, do the computing with the GPU, and return it to the AppVM?
I’m not talking about manipulating pixels on the screen, but other things like:
- LLMs
- crypto mining
- password cracking
It’s something that maybe work at the level of the framework using the GPU, like pytorch I guess. There is no protocol to offload the rendering to a remote GPU for a random workload.
1 Like
When I go to favorites on the Q, which is what shows by default when I press Q, I wish the favorite icons filled up a larger part of the screen. I use a lot of favorites and having to scroll through them is just an annoying UX experience, i wish i had at least the option of displaying them in a way more similar to how gnome shows applications
2 Likes
Ability to “petrify” running disposables into new AppVMs, and AppVMs into new templates.
I think it’s a VERY bad idea, but may improve friction sometimes, so I’ll just throw it here.
For instance, imagine someone sends you something while on a voice call and you tinker with it, and then instead of creating/cloning AppVM / TemplateVM, you just tell your system to write current changes as a new VM and pick a name.
3 Likes
When emergency pausing a qube, I really wish there were a “restart” option.
I get not being able to restart qubes when there are other qubes attached, but at least let me emergency pause and restart a qube if there are things attached.
As it is, I have to kill the qube and find the qube in service again or go to the template manager to get the restart option. It’s really slow and I run into this situation enough that it’s annoying an “emergency pause” and then “restart option” doesn’t exist. It’s an extra 40 seconds to do things, but an emergency pause restart option could be 5 seconds instead. It’s just another little annoying usability issue that could be made much easier.
1 Like
I use this for the former case - it morphs a disposable in to a running AppVM.
I have it bound to a shortcut.
#!/usr/bin/bash
if [ $# -eq 1 ];then
qvm-check --quiet $1 2>/dev/null
if [ $? -ne 0 ]; then
notify-send "No qube $1 "
exit
else
ID=`xdotool selectwindow`
if [ "$(xprop _QUBES_VMNAME -id $ID|cut -f2 -d\")" != "$1" ]; then
notify-send "Window mismatch"
exit
fi
fi
else
ID=`xdotool getwindowfocus`
fi
QUBE=$(xprop _QUBES_VMNAME -id $ID|cut -f2 -d\" )
if [[ "$QUBE" == "_QUBES_VMNAME: not found." ]]; then
notify-send "That is a dom0 window"
exit
fi
WM_CLASS=$(xprop WM_CLASS -id $ID |cut -f2 -d, |tr -d '"' )
IFS=':' read QUBE APP <<< $WM_CLASS
app=$(echo $APP | tr '[:upper:]' '[:lower:]')
case $app in
libreoffice-startcenter)
app="libreoffice --nologo"
esac
qls=$(qvm-ls -O NAME,CLASS,TEMPLATE,LABEL,NETVM $QUBE --raw-data)
IFS='|' read NAME CLASS TEMPLATE LABEL NETVM QUBE APP <<< $qls
if [ $CLASS != "DispVM" ];then
notify-send "You called a program to convert a disposable in to an AppVM.
This is not a disposable"
exit
else
dispvm=$(qvm-prefs $NAME default_dispvm )
notify-send "Pausing disposable and preparing replacement AppVM"
qvm-pause $NAME
real_template=`qvm-prefs $TEMPLATE template`
new_qube=`echo $NAME |sed s/disp/qube/ `
qvm-check --quiet $new_qube 2>/dev/null
if [ $? -eq 0 ]; then
notify-send "$new_qube already exists"
qvm-unpause $NAME
exit
fi
qvm-create $new_qube -t $real_template --property default_dispvm=$dispvm --property netvm=$NETVM -l $LABEL
cd /dev/qubes_dom0
sudo dd if=$(readlink /dev/qubes_dom0/vm-$NAME-private-snap) of=$(readlink /dev/qubes_dom0/vm-$new_qube-private) conv=sparse bs=1M
if [ $? -eq 0 ]; then
notify-send "Starting replacement AppVM"
qvm-unpause $NAME
qvm-kill $NAME
qvm-run $new_qube 'find -name .lock* -delete'
qvm-run $new_qube "$app" &
else
qvm-unpause $NAME
notify-send "Something went wrong. Rolling back"
qvm-remove -f $new_qube
fi
fi
8 Likes
A couple of minor, presumably easy GTK tweaks to the update tool.
-
The Next button should desensitize when you press it. Sometimes it can take a very long time for it to come up with the list of qubes that should be restarted/shutdown; in the meantime there’s no way to know whether you actually pressed the button or only think you did–and if you DO press it again, it will process both presses (again because it’s not desensitized) and possibly restart or shutdown something you didn’t need to and rather unexpectedly exit (since “Next” also appears on the, ahem, next screen).
-
I’ve griped about this before but the window that shows during updating should have a sash in the middle, so that one can make either the details part or the scrolled list of VMs with progress bars bigger without having to make both bigger.
And something more complicated–perhaps much too complicated: be able to go back to the list you’re presented with, instead of exiting the gui, in case for some reason you want to update your VMs in batches. (That could be handy for underpowered machines that will basically slow to a near halt during updates–update a few at a time so you can do other things in between.)
3 Likes
1 Like
Thanks for this…I thought the title a bit irrelevant-sounding but when I went and read the whole issue, my complaint about the next button is actually part of it.
Privacy, deniability and anti-forensics should be introduced as core goal of the project along with security.
4 Likes
What’s wrong with Whonix configured out of the box?
1 Like
this for example : How to hide the fact that I’m Qubes OS from Telegram
need some work on fingerprint to make its look like something more generic , would decrease risk to be targeted too , most people don’t use qubesOS without a real need…
Not to be glib, but I’d like a strong focus on usability. Moving to 4.2 was great for this, but there are still a lot of entry barriers to using Qubes.
Its more a case that “most people don’t use qubesOS.”
More users of an open source project == more strength, no? At least to some degree?
There are a lot of great scripts and workarounds in this thread. I’d like them working out-of-the-box.
EDIT: at time of writing, morePrivacy’s previous post is hidden by mods after flagging. I haven’t read it, I’m not responding to it, and I certainly do not endorse whatever it was.
1 Like
Just read morePrivacy’s earlier post, and with the flagged post, I really want to reposition myself.
Consider this:
We get hammered by scam callers in this country. There is very little authorities and companies seem able - or willing - to do to protect us from these assaults. The scammers have a bunch of personal data on us from data breaches and they use that to pretend they are ‘helping you’ with your choice of utilities, phone, etc etc.
If you play them along, they all move quickly to sending you a link by email and SMS. They become very VERY insistent that you click on on that link.
I can only assume that link is a pathway to malware.
I’ve never clicked on that link, although ironically as a Qubes user (with its isolation), I’m probably able to do that without compromising… well, without seriously f*cking up my life, actually. That makes me unique among my neighbors, friends and family.
And that’s the problem for me - not the problem with Qubes, but the problem about Qubes. Its damn hard to use for a lot of people.
I want Qubes to be accessible to as many people as possible. I think we are sorely lacking in safe, secure and private computing and there are many barriers to adoption of solutions like Qubes, GrapheneOS, etc.
There are so many clever solutions for common usability issues that are described in this thread. I’d like to see their pathway to incorporation - well, I can’t say all of them - into the mainstream Qubes to be faster. I’d like usability, especially for a non-technical user, to be a priority.
Tele-scams are just one way to get to this point. They are getting more sophisticated, its a growing threat. In this case, I’d like a Qubes in which my elderly uncle can mistakenly click the link in his email, it opens in a dispVM and he is protected from his own mistake. (At least partially, maybe). I don’t think my Uncle could use Qubes now - not without a lot of support. Its not viable. I will say that the changes we saw in 4.2 generally have been an excellent improvement, though.
There is always the argument that security is disproportionate to convenience, but that shouldn’t be used as a barrier. Prioritizing usability will be an improvement to the OS, and so an improvement in the circumstances of the Qubes project.
/rant
I must flag that I living in a country where I don’t have to fear the government, and there are generous personal freedoms so I don’t need to break laws just to simply live my life. It hasn’t always been the case and it certainly isn’t the case in some places. If that’s the place where morePrivacy is talking from, I apologize if this trivializes their problems. I’m not arguing that Qubes should neglect such use cases.
2 Likes
You could contribute to the project if you want to help. There are many ways that are not technical:
- teach users
- help people on the community places (forum, matrix, elsewhere)
- make a local user group in your city / country to help spread about Qubes OS and teach people to teach more people
- write documentation
- media coverage
- send money to the foundation so they can pay professional people to contribute, pay hardware, run more tests
4 Likes
acknowledged, Solene. However, I have limits on the outreach activities you site.
Partly its because I don’t know enough to teach, unless I’ve convinced someone to install and try it out.
That’s a problem, because with the hardware constraints, not many are willing to try. None, in fact. Could be my aftershave, of course.
There is also the real risk of sounding like a paranoid freak. However, since even my mother is starting to understand the realities of surveillance capitalism, I wonder if that is changing a little.
When I have money to spare, however, I will indeed donate. But you shouldn’t wait up for that one, unfortunately.
2 Likes
I have an idea for Qubes. In KVM virt-manager there is a little box that comes down in full screen mode to exit
I would like something similar for QUbes but I want it to be a blue Q. I want it to disappear if I don’t go to that area but I want it to show up and turn orange if certain conditions exist such as: a notification, CPU or memory in sy-net going over 50 percent, sys-firewall going over 50 percent for memory or CPU or if certain heat thresholds met. I would also like if some conditions could be programmed by user such as if pings to a certain address stop or a connection terminates.
This would allow full screen usage with less risks of being hacked.
1 Like