Even if you only have the QR code, you can download the image or screenshot it and then extract the secret without ever having to use a smartphone by using zbarimg and then manually extracting the secret from the URI:
If you have some 2FA that you need to enter 10 times per day, then you can also add a global shortcut to automatically paste it. Of course, this undermines the "second device" security. Some PC password managers also support 2FA, e.g. https://github.com/paolostivanin/OTPClient ( sudo apt install otpclient )
Works great if you have xfce4-screenshooter, gxmessage, and zbarimg installed. It allows you to draw a box around a screen region, screenshots it, decodes it via zbarimg, and pipes the output into a dialog box with copyable text.
For bzip2, a list of bit offsets in the compressed stream and a corresponding byte offset in the decompressed stream suffices because each bzip2 block is independent.
For gzip, it is as you say. However, when only wanting to seek to DEFLATE block boundaries, the "state" of the decompressor is as simple as the last decompressed 32 KiB in the stream. Compared to the two offsets for bzip2, this is 2048x more data to store though. Rapidgzip does sparsity analysis to find out which of decompressed bytes are actually referenced later on and also recompresses those windows to reduce overhead. Ratarmount still uses the full 32 KiB windows though. This is one of the larger todos, i.e., to use the compressed index format, instead, and define such a format in the first place. This will definitely be necessary for LZ4, for which the window size is 64 KiB instead of 32 KiB.
For zstd and xz, this Ansatz finds its limits because the Lempel-Ziv backreference windows are not limited in size in general. However, I am hoping that the sparsity analysis should make it feasible because, in the worst case, the state cannot be longer than the next decompressed chunk. In this worst case, the decompressed block consists only of non-overlapping back-references.
Big-O notation is a famous example where = is some flavor of (asymptotic) proportionality, and it catches a lot of people out when they first learn about it.
Ratarmount also works for that. However, it, and any other tool I know of, works only well if it was compressed with pzstd because of a limitation of the zstd format. It needs separate zstd frames for fast seeking.
Even history rewrites would be visible with Github's new Activity tab, e.g., see the two force-pushes in llama.cpp https://github.com/ggerganov/llama.cpp/activity So, while, yes, git history can be rewritten, commits pushed to Github can effectively never be deleted. Personally, I find this to be a downside. Think, personal information, etc. But, in this case, it is helpful. Of course, the repository is suspended right now, so the Activity cannot be checked.
An Ansible playbook running on a relatively cheap hetzner box. In general bridges require you to self-host a homeserver. A federated homeserver will need 4GB of RAM at least and 8GB if you plan on joining large rooms. The playbook is controlled from a single config file and sets up all the bridges you need.
