I don’t know the inner workings of qvm-start, but I think it’s safe to assume that the --skip-if-running parameter makes it check before doing anything, so the cost of running it every minute should be minimal.
It stills needs to run python3, evaluate all the required libraries and check the qube is started to abort.
I don’t really have a strong opinion on this particular case, but this is a good place to elucidate my thoughts on how we should proceed in similar situations (and also to exercise my rusting writing skills).
Things that are published in the top post are always the condensed versions; the most-short version that most benefits the most. However, there are usually caveats and adaptations, so a link to the original/longer version is required–this way, those who want more details can always read them and join the discussion.
When there’s a dispute over which version gets to be the condensed version, a simple cost-benefit analysis should settle the matter. For the purposes of this thread, one tries to figure out the median Qube user and uses her as a frame of reference to minimize loss and/or maximize gain. If you want to get more specific, you can try to figure out the conditions under which that particular piece of code or advice is typically applied.
This sys-usb failsafe will serve as an example case. Here, there are two things that determine where the happy medium lies:
-
The device specifications of typical Qubes users; and
-
The damage from sustained loss of control (downtime, psychological stress, etc.)
(1) Typical device specifications
I’m not about to conduct a survey on the matter, but I feel justified in believing that many users, if not most, use Qubes on devices that can be considered powerful with regard to qvm-start. On top of that, devices that need this failsafe are, in the vast majority of cases, desktops, so they’re beefier.
Sure, there are those still using ancient ME-free Thinkpads and the like, but I have good reason to think they’re a vocal minority (and a rapidly shrinking one at that). Plus, people who go to such lengths are usually competent enough to adapt the code to their needs.
(2) Damages from loss-of-control
Running qvm-start every five minutes would minimize CPU usage, but at that point the user might benefit more by just immediately restarting and not have to sit for potentially five minutes staring at the screen and wondering whether sys-usb is about to start. I italicized ‘potentially’, because the uncertainty also adds pain points (or pleasure, for a few special people). Edit: I wrongly assumed crontab scheduling worked independent of the clock, via internal timer, but my general point still stands.
I can see this being a very unpleasant wait for someone who just wants to get on with what they were doing. Even three or four minutes can be too long since it’s just long enough to prevent the user from doing something else, so the user is kept staring at the screen of a device they cannot control–and this is assuming they remember having scheduled this task.
Conclusion
Considering that devices running Qubes are generally capable, along with the downsides of having evaluations be too far apart, one or two minutes would be best. Defaulting to the original poster’s version seems appropriate (unless he’s changed his mind).
While writing this I realized that we also need to include a way to shut off the scheduled behavior in case someone needs to keep sys-usb off. I typically assume some level of technical literacy/compentecy in order to keep the word count low, but there are many cases where the damage from not including roll-back instructions can be too high for those who are unfamiliar with the systems.
@SteveC Does removing the scheduled task from crontab reverse the changes?
You could comment it by adding a leading # on the line.Y
1 Like
Thank you
As you might be able to tell, I’m not someone who’s very familiar with Linux systems, so I need people double-checking the technical accuracy of what’s posted up there. I used to put a disclaimer to that effect below my posts, but I forgot about it after being mostly absent for a year or so.
Not technically trained; consume with salt
I added my personal favorite, which is massively convient and should be integrated into the OS by the devs
This script shuts down the VM that’s currently selected. Since dom0 responds to all key presses, I strongly suggest mapping this to an uncommon key combination. E.g. Someone who mapped this to “Ctrl + C” will shut down the qube he’s using whenever he presses the standard shortcut to copy. This also makes it a great way to prank Qubes users around you.
Also, a sleep value of 4 is just a default and not a functional necessity, so reduce this if you want to shorten the delay before shutdown (though sleep 0 might cause issues)
5 Likes
Turning “graphics hardware acceleration” off by default in all templates (we probably need a salt script to do it)
Libreoffice new window size fix
Is this a request or are you referencing existing posts?
It scattered all across the forum. and no slat scripts exist yet 
Couldn’t that be fixed with something like
xl list | grep sys-usb || qvm-start sys-usb
But I don’t know if that’s better or worse
1 Like
I missed this post since it was hidden among all the posts about notifications
Maybe someone can run time xl list | grep sys-usb || qvm-start sys-usb vs the original code a couple of times?
Also, as @bearillo mentioned, Discourse is consistently dropping reply targets and it’s forcing me to quote.
x
I added a tip discovered by @renehoj in the CPU and Boot Time Survey thread.
Debian 12 only - [TemplateVM] Enter
sudo cp /lib/systemd/system/systemd-binfmt.service /etc/systemd/system, then deleteAfter=local-fs.targetfrom/etc/systemd/system/systemd-binfmt.service
Let us know how much faster your boot time is before and after implementing by following instructions from that thread and entering your results. Note that data from VMs that have implemented this trick should have the “systemd-binfmt” modification.
If you are running your system with SMT enabled, you need to add the following lines to /etc/default/grub
GRUB_CMDLINE_XEN_DEFAULT="$GRUB_CMDLINE_XEN_DEFAULT smt=off"
GRUB_CMDLINE_XEN_DEFAULT="$GRUB_CMDLINE_XEN_DEFAULT smt=on"
It’s the only way to keep kernel updates from disabling smt, by automatically adding the smt=off line to the end of the file.
3 Likes
Is this for the systemd-binfmt tip or is it a whole new tip?
It’s not related to binfmt, it’s a tip for anyone running Xen with smt=on.
The Qubes OS update process will force disable smt if it doesn’t detect smt=off in grub, it’s just a way to trick the update process. Without it, you need to manually edit grub after each kernel update.
I’m on the fence about adding this as a tip.
-
This should be part of a tip on how to turn SMT on, otherwise it just lacks context.
-
Enabling SMT has potentially severe security implications, which is why SMT was disabled by the devs to begin with. While it’s hard to argue that increased performance is a niche desire, increased performance at the cost of security is a different matter. Tips with security implications, if allowed at all, must be marked with clear warning labels, but I fear that even when marked, just having the tip published might give the false perception that it’s less-risky.
Mods (@Deeplow @sven @gonzalo-bulnes , etc.), do you have any thoughts on the matter?
1 Like
Regarding publication of tips with clear security implications, I’ve no strong feelings either way. I think I’d default to saying that everything in the forum should be taken with caution, and that applying changes you don’t understand well is likely unwise. (
)
On whether this instamce is a tip in itself without the “how to enable SMT” context… I agree with your judgement:
Thay being said, I suspect that the trick works because the smt=off line is managed by Salt (educated guess), which has convenience functions that ensure a content is present in a file, in a way that adds it if missing and does nothing if present.
Leaving the line in the file and overriding it would work in any similar situation. So that may be a useful technique to know of.
Now, does it fit the category: “Quick Quality Improvements”? I’d say no. “Tips and tricks”? Maybe. 
2 Likes
Since the forum is almost entirely made up of
non-security researchers, non-developers and non-Xen experts I see no way to even begin assessing posts.
Also I don’t think it makes sense for the community to try to take user’s “at the hand”. Instead it should go like this:
If you have security concerns, use Qubes OS in its default congratulation without any modifications. Only follow instructions clearly published by the core team / official project. Expect each and every community post to be a malicious attempt to weaken your security.
If you are using Qubes OS as a hobby or to learn or you are sure you understand the implications of your configurations well enough to bet your security on it… by all means have at it.
4 Likes