vifon

chroot doesn't nest, there is only one chroot active for a given process at a given moment. If you're inside a chrooted environment and call chroot on a subdirectory without entering it, you regain the access to the parent directories.

AFAIK it only worked with optical drives, not pendrives. I've spent hours trying to get this functionality on my pendrives back in the day, to no avail (thankfully!). It was on Windows XP, and Windows 98 needed external drivers to even use pendrives at all, so if such an attack vector existed, it must have been on Windows 2000 or Me (i.e between XP and 98), so an arguably very short time frame (if at all!).

Something akin to "uBlock Origin CNAME uncloaking now supports filtering by IP address" should be fine.

The title seems to be wrong, uBlock Origin supported it for many years at this point (only on Firefox). This seems to be a refactor of that code, not a whole new feature.

It's usually run as a local web application with the browser running on the same machine as the backend, though it's possible to bind it to non-localhost interfaces.

Sounds very similar to the paid data processing opt-out Facebook does now. That actually might be an interesting case.

One more point I'd add to (2): given its massive inertia / network effect, the tooling and the resources are leagues ahead of everything else. I'm using Darcs for a few personal projects and while the core ideas are great, the tooling is just worse. From the ways to customize the diff utilities to use, to integrations with text editors (the vc-darcs module for Emacs is pretty barebones, especially compared to Magit, but even compared to the basic vc-git).

So Wi-Fi Direct?

This works only under the assumption Github won't change the current DNS setup that happens to work this way. A trivial example would be adding a record for the specific subdomain one used directing it to some completely different IP address. Not something I'd be willing to bet on, especially considering the much cleaner solution from the original post.

A minor correction: it's usually preferable to apply commits with `git am` instead of `git apply`, as it applies the commit with all its metadata, not just the diff.

This missing piece of information would be essentially `git reflog`, except it's not something Git sends between the clones.

The only thing I don’t get is automatic synchronization between magit status buffer, and the file that’s currently open in the editor. That is, to view the current file and the diff on the side, I have to manually open the diff and scroll it to the point I am currently looking at.

Probably not a perfect solution but `scroll-all-mode` should be pretty close, at least within a single file at a time.

Yes, C-x 5 0 is safe, but I often use my window manager's keybinding for closing a window instead. Customizing confirm-kill-emacs sounds like a great idea, I'll consider it, thanks!

My relatively new stance is that sometimes having an Emacs process that doesn't share the state is a feature, not a flaw. Specifically I started using non-daemon Emacs processes alongside my main Emacs daemon to compartmentalize my work. Each non-trivial project, or "workspace", gets its own Emacs process, possibly with a persistent state with desktop-save & desktop-change-dir. The newish tab-bar-mode helps with that a lot as I cannot stand using multiple frames on a non-daemon Emacs due to it not always being obvious when I close just a frame and when I close the whole process.

Storing metadata out-of-band strikes me as key to any usable content management system within a realistically complex space.

Yes and no. I was specifically comparing it to Git Annex which is hard to categorize in these terms. It forces every file to become a symbolic link to the actual file living in `.git/annex/` and then every query temporarily mutating the hierarchy of directories storing these symbolic links. I found the latter disruptive enough (in particular for the directory mtimes) that I was actively avoiding doing any such queries. See: https://git-annex.branchable.com/tips/metadata_driven_views/

On the other hand my current setup involves TMSU queries which result in virtual Emacs directory editor (dired) views that don't affect anything else. I don't even use the FUSE functionality of TMSU.

TMSU is the only such system I found useful without being cumbersome. After years of trying to use Git Annex, it was refreshing that TMSU doesn't alter the files in any way, merely storing all the (meta)data out-of-band in a separate DB.

These days I use TMSU via my own Emacs-based UI almost every single day, so thank you for that!

The reason given was that purchases made through his links were for personal use or made by friends and family, which he denies.

Why is this even a problem? A purchase is a purchase.

Outbound links containing the word "sexy" at that!

Why are you on Twitter during work? That might be the NSFW part.

Yeah, yeah, security vs. convenience is always the issue, but so far I've just selected convenience.

In terms of the SSH and GPG keys which I use multiple times every single day for me this is convenience. I have my keys always on my person and they are tied to me, and not a particular machine. Whether it's my laptop, my desktop or my phone, I have a single pair of keys that are virtually impossible to steal even on a so-so trusted device like a proprietary phone.

When you start considering a security key as a portable credential storage to use across all your machines, it becomes actually more convenient, not less.

I don’t see any use case or security benefits by using the static password feature. Even if you enter a password manually and concatenate it with the password of the Yubikey, a keylogger still gets both parts (assumption: You don’t reuse passwords).

If keylogger is what you're defending from, yes, it doesn't help. And in this scenario you've probably already lost.

On the other hand, it makes a large portion of the password immune to video-recording you typing the password in. Yes, it's technically trivial to then steal your Yubikey, extract the static password and combine it with the recorded one, but these are still quite some extra steps.

My point is, if a particular service or application doesn't support anything more refined, using a static password as a pepper[0] is perfectly fine and still an improvement over not doing so.

[0] https://en.wikipedia.org/wiki/Pepper_(cryptography)

Their documentation seems to disagree. https://developers.cloudflare.com/cache/about/default-cache-...

my family found the noise that the Browns make annoying

That's why you start with Blue and only when they complain you switch to Brown. ;)

Yes, and they should be marked as conflicting, as OP suggested.

Let me rephrase: GPG is possible to get working, the resident keys are not, regardless of the amount of setup. Though the other comment seems to suggest it might not be the case, so maybe there is hope.

Do you have any documents on how I can use them in such case?

Not every Yubikey supports the resident keys. All my Yubikey 5 keys have too old firmware, which AFAIK cannot be updated, so this is not a viable solution for lots of people even if they own the hardware. GPG just works, and can be used for many other things while one's at it already.

I've found the sequential syncing with mbsync to be a major bottleneck. These days instead of "mbsync -a" I have a script like this, using GNU Parallel:

    parallel --bar -j0 mbsync "$@" <<EOF
    mail1
    mail2
    mail3
    EOF

If you want your email reliably encrypted, encrypt it yourself. GPG works the same regardless of the provider.

For starters it's not free (as in freedom).