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.