Quick Quality-of-Life Improvements

[fiftyfourthparallel]

@Deeplow
I just remembered from my CPU survey that there’s a limit to how many user mentions a single post can contain. This post should reach that limit quickly, but I want to see if there’s a way to get around that limit before I start removing them (i.e. “Does mod fairy dust fix this?”)

[fiftyfourthparallel]

Thanks for updating the wiki
I reformatted your entries; please check for technical accuracy

[deeplow]

@fiftyfourthparallel

i.e. “Does mod fairy dust fix this?”

It does. One can now mention up to 100 people. Thanks for bringing it up!

[SteveC]

Thanks for book-bossing this. I added just a bit more. If it’s too much feel free to cut.

And I’ve added one about how to protect against the rather obnoxious consequences of accidentally shutting down sys-usb.

[ludovic]

I added the Cursor / Manual hide the mouse cursor procedure.

[fiftyfourthparallel]

@fiftyfourthparallel

sys-usb: how to protect yourself against accidentally shutting it down

(I’ve suggested this in other places but can’t find them right now, so no link). If you’ve ever found yourself in the situation where you accidentally shut down sys-usb AND you happen to be using a USB keyboard or mouse, you’re basically hosed. Your machine will be a brick until you reboot it, because dom0 doesn’t take things like your keyboard and mouse back after they’ve been assigned to sys-usb. (This is not a bug, it’s a deliberate design decision taken for security reasons.)On the other hand, it’s safe to restart sys-usb from the qui-domains tool, and that fact is going to help us here.How to solve this? Create a cron job that starts sys-usb if it isn’t already running, and set that job to run every minute. (For those new to unix/linux, cron jobs are tasks that are prescheduled and run in the background. In the old days of stone knives-and-bearskins computing, these were often called “batch” jobs.) Here’s how to do that: Open a terminal in dom0 and type crontab -e. This opens the vi editor which will show you a file that contains existing user crontabs (as opposed to ones run by root). The file may well be empty. Insert a line that reads:

* * * * * qvm-start --skip-if-running sys-usb > /dev/null 2>&1

The five stars denote every minute of every hour of every day of every year. The middle part of the command should be self explanatory. The stuff after the > redirects the output of the command to /dev/null, which is basically “nowhere” rather than the screen or some log file.The result should be that if you shut sys-usb down for whatever reason, sometime within the next minute it should start back up again and you have your keyboard and mouse back.This edit only needs to be done once; it will still be there after restarting your system.The bad news is that in order to work with this, you have to know how to use vi…which is actually a tool adapted from those stone-knives-and-bearskin days. You can (if the file is empty) type i to get into “insert mode”, type the line above (including the return/enter at the end of the line), then press the escape key and type :wq to write and exit. @SteveC

Posting the original to serve as a thread-splitting header before I summarize it.

[fiftyfourthparallel]

Is there a Discourse/Markdown/HTML guru here? I need a way to indent the details tab/expander so that it’s flush or deeper than a level 1 bullet, making it clear that it’s part of the preceeding entry.

Subheader

• Level 1 bullet

Uncooperative details tab

Please help me tame this rebellious tab (with code block)

• Level 1 bullet

The challenge is to keep a code block inside the tab while indenting it. This would hugely improve the flow of the document. I’m this close to issuing a bounty for this since it’s driving me mad.

Edit: Forgot to include the code block condition
Edit 2: The solution: use two spaces, not four–Two extra spaces is the difference between breezing through life and looking like a dunce

[apparatus]

@fiftyfourthparallel

Subheader

• Level 1 bullet

  Uncooperative details tab

  • Please help me tame this rebellious tab*

• Level 1 bullet

This?

[fiftyfourthparallel]

Er, I meant can you do it with a code block inside?

[apparatus]

Like this?

@fiftyfourthparallel

Subheader

• Level 1 bullet

  Uncooperative details tab

  Please help me tame this rebellious tab
  test
  

• Level 1 bullet

[fiftyfourthparallel]

Wow. Why does it fail so horribly when I try to do the exact same thing?
I’m saying this while looking at your reply’s source code since I have quasi-mod privileges and I’m just confused. Does Markdown have something against me?

Edit: The solution: use two spaces, not four–Two extra spaces is the difference between breezing through life and looking like a dunce

Anyways a big thank you!

[fiftyfourthparallel]

Moved posts for “Send files directly to external storage mounted in other qube” to its own thread

Send files directly to external storage mounted in other qube

Split from original thread: Quick Quality-of-Life Improvements Thread If you need to move/copy a LARGE file from one qube to another, and you’re going to put that large file onto some sort of external storage at the destination, you might be concerned about the useless write to your SSD involved in copying to the destination’s QubesIncoming directory. Or the file might be too large to fit! Simple solution: on the destination, replace QubesIncoming (or QubesIncoming/) with a soft link to some…

[solene]

@fiftyfourthparallel

Prevent loss of control from sys-usb shutdown - [dom0] crontab -e, then enter * * * * * qvm-start --skip-if-running sys-usb > /dev/null 2>&1 and save @SteveC

May I suggest using */2 * * * * or even */5 * * * * to reduce the number of useless call by a factor 2 or 5?

I mean, this would save you when you accidentally stop sys-usb, I don’t think this is very common but very annoying when it happens. I think waiting 2 or 5 minutes instead of less than 60 seconds seems reasonable when it happens, so it wastes less CPU cycles trying every 60 seconds

That’s not really wasting that much, but still, the frequency is very high here and I don’t know how complex qvm-start code is behind that, it must call a lot of python code which is extremely CPU inefficient.

[fiftyfourthparallel]

@solene

That’s not really wasting that much, but still, the frequency is very high here and I don’t know how complex qvm-start code is behind that, it must call a lot of python code which is extremely CPU inefficient.

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.

[solene]

It stills needs to run python3, evaluate all the required libraries and check the qube is started to abort.

[fiftyfourthparallel]

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:

1. The device specifications of typical Qubes users; and

2. 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?

[solene]

@fiftyfourthparallel

@SteveC Does removing the scheduled task from crontab reverse the changes?

You could comment it by adding a leading # on the line.Y

[fiftyfourthparallel]

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}

[fiftyfourthparallel]

I added my personal favorite, which is massively convient and should be integrated into the OS by the devs

tasket/Qubes-scripts/blob/master/halt-vm-by-window

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)

[arkenoi]

Turning “graphics hardware acceleration” off by default in all templates (we probably need a salt script to do it)
Libreoffice new window size fix