rcm VS dotfiles

Are your per-machine branches mostly distinct, or do they share a lot?

I use https://github.com/thoughtbot/rcm and I find my dotfiles share _quite a bit_ in some respects (e.g. neovim config) but are drastically different in others (SSH config as one example) -- keeping things synced _across_ branches sounds very difficult. rcm handles this well, without branches, IMO.

I use https://github.com/thoughtbot/rcm, which works smoothly and includes support for host-specific files

I use thoughtbot/rcm to handle my github dotfiles. Super short version after installing, mkdir ~/.dotfiles Then go through your home directory (ie. ~/ ) and mkrc .bashrc and then do the same for any other files you plan on tweaking or have custom settings for. Most of these with be in ~/.config/ but some will be in ~/ . (ie. mkrc ~/.bashrc for your bash settings and aliases)

Prior to catching the Nix brainworms and switching to home-manager, I mostly used thoughtbot/rcm.

Personally I like (and use) rcm. Everything is still in a git repository, but has more features that work well for sharing across multiple machines.

Check out https://github.com/thoughtbot/rcm

I use rcm. It assumes you keep a separate (potentially version-controlled) folder at ~/.dotfiles or similar, and it provides a suite of tools for managing the symlinks.

https://github.com/thoughtbot/rcm

currently I am managing my dotfiles with rcm (ran by ansible). This approach served me well over the years but recently I stumpled over chezmoi.

Setup a Github/Gitlab account and find a dotfile manager you like (I'm using RCM - it can do more than I actually use it for).

From a technological point of view, TOR still has a couple of flaws which make it vulnerable to the metadata logging systems of ISPs:

- it needs a trailing non-zero buffer, randomized by the size of the payload, so that stream sizes and durations don't match

- it needs a request scattering feature, so that the requests for a specific website don't get proxied through the same nodes/paths

- it needs a failsafe browser engine, which doesn't give a flying damn about WebRTC and decides to actively drop features.

- it needs to stop monkey-patching out ("stubbing") the APIs that are compromising user privacy, and start removing those features.

I myself started a WebKit fork a while ago but eventually had to give up due to the sheer amount of work required to maintain such an engine project. I called it RetroKit [1], and I documented what kind of features in WebKit were already usable for tracking and had to be removed.

I'm sorry to be blunt here, but all that user privacy valueing electron bullshit that uses embedded chrome in the background doesn't cut it anymore. And neither does Firefox that literally goes rogue in an endless loop of requests when you block their tracking domains. The config settings in Firefox don't change shit anymore, and it will keep requesting the tracking domains. It does it also in Librefox and all the *wolf profile variants, just use a local eBPF firewall to verify. I added my non-complete opensnitch ruleset to my dotfiles for others to try out. [3]

If I would rewrite a browser engine today, I'd probably go for golang. But golang probably makes handling arbitrary network data a huge pain, so it's kinda useless for failsafe html5 parsing.

[1] https://github.com/tholian-network/retrokit

[2] (the browser using retrokit) https://github.com/tholian-network/stealth

[3] https://github.com/cookiengineer/dotfiles/tree/master/softwa...

Added lots of other helper methods, mostly for the shitty kind of CLI tools like yt-dlp, wget, tar, etc. My PS1 is a little more complex because I'm using emojis in the Terminal to represent states of repositories and to shorten the base paths. My complete bashrc is here if you're curious.

Personally I decided to have my dotfiles being not a git repo of the actual dotfiles, but more like a quick bootstrapping framework with the idea that the install process can be run repeatedly and incrementally without fucking already "patched" config files up.