Amusingly, in French, "desed" sounds like "décéde", which means die / decease. That's quite a fitting name for a tool one would use in "I need to debug a sed script" situations!
The first link [1] in section "4. Code and test improvements" leads to a patch series with a cover letter which reads
There are a number of tests that still follow an old convention of using
four-space indentation. Update a bunch of tests to use the new convention
with tab indentation
This feels a bit ridiculous to include this in such a blog post...
Beware that the trailing slash in the string after `gitdir` is significant! This string is a globbing pattern (it is not obvious at first sight, and seldom mentioned), and the trailing slash implies `**` [1].
So if you type "gitdir:~/work" instead of "gitdir:~/work/", you will lose some time wondering why your configuration is ignored.
I am curious because I have been using LineageOS on Pixel 2 / Pixel 2 XL phones for a while (and it works very well, I might add), but I am kinda clueless when it comes to Android security.
Plus it just provides updates quicker, eg. the recent WebP CVE was first fixed in DivestOS before other aftermarket systems. https://divestos.org/pages/news
Your mouse story makes me think of the day the CI system at work turned out not to be robust to vibrations.
One day we started having flaky tests, seemingly out of nowhere. We quickly identified that the issue affected tests involving graphical X client applications, but then we struggled to make further progress. The issue was just impossible to reproduce in other conditions... Well, as it happens, the CI jobs were running on some desktop machines we had installed somewhere within our premises. It turned out that some gentleman had plugged a mouse into one of the machines, and left it lying around on the shelf. Since then, when one of the machines was under a heavy load, the fans would spin faster, causing more vibrations, in turn causing the mouse to move, ever so slightly. And for ungodly reasons, this had side effects on tests.
Fun fact: the machines were not on my site, I managed to diagnose this over SSH. I was quite proud :-)
This enables the C-r / M-c / C-t key bindings, but there's also a completion.bash file. This enables the "**" completion trigger, which can contextually complete paths, envvar names or PIDs in commands. (See "Fuzzy completion for bash and zsh" in fzf's readme [1]). Similarly, you can add to your .bashrc:
if [ -e /usr/share/doc/fzf/examples/completion.bash ]; then
source /usr/share/doc/fzf/examples/completion.bash
fi
/usr/share/doc/fzf/README.Debian explains this, as well as the setup for zsh, fish and vim.
"Reproducible environments" sounds like a strong argument to me. If you don't have a reproducible environment, you have no guarantee that your code will work at any point in time. The more complex the projet and its dependencies, the more likely breakage will happen with a new version of a dependency.
Maybe this is something that is best learnt the hard way? Something you understand once you reflect back on how many hours you have lost fighting with dependencies, instead of doing what you actually wanted to do with the code (be it running it, developping, debugging, bisecting...).
Freezing dependencies comes at a cost though, especially since dependency management in python is a PITA. So this is a trade-off. For simpler, projects or scripts, I personally don't bother with freezing dependencies, and I handle issues when they happen. (And they do happen.)
I somewhat regularly use this on Linux. I think it also works on OS X