offlineimap allows synchronizing IMAP and/or Maildir mailboxes both ways (e.g. not just a copy). Even though the name and introduction on its website doesn't necessarily carry this very well, it can synchronize 2 IMAP mailboxes, none have to be Maildir.
It also supports incremental and two-ways sync, which means you can keep using both mailboxes and it'll do its magic.

This came in very handy in synchronizing mailboxes between providers: just set it up to use IMAP on both ends, and let it do its magic -- it's fairly long for large mailboxes because IMAP isn't the fastest. And as it's incremental, you can both interrupt the sync, and re-run it as many times as you want if the source mailbox changed (received new messages, or removed any).

It also has a lot of options, including custom folder filtering or transformation and many others. For those who care, it apparently has specialized GMail support as well.

Infos utiles sur comment passer outre les pré-requis matériel (TPM, SecureBoot, etc.) qui ne passent pas nécessairement sous VirtualBox.

Voir aussi https://www.frandroid.com/marques/microsoft/1948088_comment-installer-windows-11-sans-creer-de-compte-microsoft-en-ligne pour ne pas avoir à fournir un compte en ligne.

Et bien sûr https://www.microsoft.com/fr-fr/software-download/windows11 pour récupérer l'ISO d'installation

This is silly, but Google OAuth2 fails at the last step (after clicking "Allow") if a local web server is running (on localhost I guess). Workaround is to stop the web server during the OAuth2 process -- you can then restart it just fine.

I got bitten by this with several Google calendars I use for work, for which I guess the OAuth2 token expired recently. Subsequently I got spammed with authentication requests, and my calendars stopped working properly.

The OAuth2 flow only showed the final "Allow" part, but clicking on it redirected me to my company's homepage. This added to the confusion, because the Google account I use uses my company's email, so my first guess was that the OAuth2 flow incorrectly assumed it had to finish on the email domain's website (or using some missing DNS records from it). But actually it was just my local webserver performing the redirection, but as I had set it up recently to work on my company's website, it was quite confusing -- especially as it redirected to the actuel website, for which I had a temporary local DNS entry when I worked on it last month.
I ended up messing up with TB cookies, vainly trying to finish the OAuth2 flow using cURL (I didn't document myself on the flow, and was pessimistic I could do so without a proper OAuth2 client anyway -- but I had a set of query parameters on the incorrect redirection so I guessed that just maybe if the query was made to the right place it might give me the One cookie I needed), and even trying to re-add some calendars, but nothing helped -- obviously.

Anyway, I have no clue why TB does this, but I luckily finally found this QA post when I was about to ask out of sheer despair -- not sure why I didn't find if before, maybe my queries were a bit too specific and this one didn't show up.

J'ai failli réécrire ça, pour un énième cas où ça aurait été tellement plus pratique que de scinder en plusieurs commandes avec un fichier temporaire -- avant de faire une petite recherche et de tomber sur sponge.

Le but ? pouvoir piper un fichier en entrée et l'écraser en sortie. Le souci ? Avec une redirection shell, le fichier est ouvert en écriture avant de lancer les commandes (logique, vu qu'il faut que le shell ait un descripteur de fichier à associer à la sortie de la commande), ce qui écrase/vide le fichier avant même que la première commande ait une chance d'y lire quoi que ce soit.

Donc on peut enfin faire transform < file | sponge file (ou quelque équivalent plus complexe que ce soit).

Probablement également un équivalent potentiel à | sudo tee file >/dev/null, même si l'ajout de complexité peut potentiellement avoir des implications de sécurité (fichiers temporaires ? sur-utilisation de mémoire ?) -- même si elles sont probablement sans conséquences dans la totalité des cas.