UK House of Lords are a buncha of Jimmy Savile pal types, if you get my drift. The same blackmail and bribery networks that exist in the US largely were learned from the Brits, who of course gave Palestine to the zionists on behalf of dragging America into a war they mostly engineered via Edward the 7ths diplomatic intrigues and the pre-war formation of the entangling alliances.
So for a long time, I traced most roads in the US back to London... (for example Star Chamber origins)...
After a while though, as I dug into the real history of banking, I realized when William of Orange was installed it was shortly after that the Bank of England was established to take them over the same way they later influenced us (Jekyll Island) to establish the Fed, the main trojan horse for a country being monetary countrol.
So I now understand just like the masons, or intel dudes, etc, many of them are just so compartmentalized they don't know what they are a part of. I now view the UK the same way.
So lets keep following the strings up the chain...
"You win battles by knowing the enemy's timing, and using a timing which the enemy does not expect." - Miyamoto Musashi
I think many of us linux admins have such a list. Mine in particular is carefully crafted around GPL-izing my stack as much as possible. I really like the format of this ikrima.dev one though! The other stuff is great too, worth a peruse.
Another reason emacs as an OS (not fully, but you know) is such a great way to get used to things you have on systems. Hence the quote: "GNU is my operating system, linux is just the current kernel".
As a greybeard linux admin, I agree with you though. This is why when someone tells me they are learning linux the first thing I tell them is to just type "info" into the terminal and read the whole thing, and that will put them ahead of 90% of admins. What I don't say is why: Because knowing what tooling is available as a built-in you can modularly script around that already has good docs is basically the linux philosophy in practice.
Of course, we remember the days where systems only had vi and not even nano was a default, but since these days we do idempotent ci/cd configs, adding a tui-editor of choice should be trivial.
Even in the US, selling to kids is illegal in most states, so the same issue applies: kid can't buy vape at store, kid goes to adult who is likely to be criminal to get them to buy for them, now kid is vulnerable to exploitation.
I recently did a deep dive on cli password management in an attempt to harden my bash scripts. (yes, I love bash, despite HN always loving to talk crap about it)
Pass is just a shell wrapper around gnupg, when you run pass some/secret/path, what actually happens is pass constructs and executes a gpg command (e.g., gpg --decrypt ~/.password-store/some/secret/path.gpg) and the output of gpg (the plaintext secret) is piped to pass's stdout.
Most people know this though. What I learned I didn't know before though was this:
Memory Zeroing: after it's used (e.g., copied to a pipe or stdout), GPG's internal memory management aims to zero out those memory regions used as soon as they are no longer needed
Memory Locking: GnuPG also uses mlock() (or equivalent OS-specific calls) to lock sensitive memory pages into RAM. This prevents the plaintext keys and decrypted data from being swapped out to disk, protecting against swap-file forensics or cold boot attacks.
I had been banging my head against bash trying to do those things manually, and ended up with the conclusion it was best to use pass/gpg with the following addendums (from my notes in my skeleton secure bash template):
1. Minimize secret lifetime: Use subshells, functions with local variables, and unset, disable bash history
2. Pipe secrets directly: Pass secrets via stdin or process substitution directly to the consuming program without intermediate variables if possible.
3. Rely on the tools: Use pass, gpg, or KMS CLIs that are themselves implemented in lower-level languages and can (and should) implement these memory protection techniques internally.
Security, including privacy, is about layers of hardening. In this case, minimization of leakage and other privacy concerns for some can still be worth the tradeoffs. For example, some apps literally refuse to work on a completely de-googled phone. (I ran one for many years with no google services). Also, the general control the user gets offers a lot more ability to harden than most android. I bricked my phone and am currently borrowing one and using stock android and there are things like facebook that are literally uninstallable... At least on lineage/graphene the user can actually control the system.
So for a long time, I traced most roads in the US back to London... (for example Star Chamber origins)...
After a while though, as I dug into the real history of banking, I realized when William of Orange was installed it was shortly after that the Bank of England was established to take them over the same way they later influenced us (Jekyll Island) to establish the Fed, the main trojan horse for a country being monetary countrol.
So I now understand just like the masons, or intel dudes, etc, many of them are just so compartmentalized they don't know what they are a part of. I now view the UK the same way.
So lets keep following the strings up the chain...
"You win battles by knowing the enemy's timing, and using a timing which the enemy does not expect." - Miyamoto Musashi