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?