I have been doing this for decades. My files are in a sub-directory of $HOME. It also makes it very obvious when a piece of software does not treat your $HOME with respect.
On Windows this was always easier because, for some reason, most everyone respected %appdata% compared to XDG_CONFIG_HOME, but also because hidden files wasn’t just a naming convention but an actual separate metadata flag.
Always... Except for the decades before this became common. Never a bloated C: root directory. Microsoft even had games store stuff in My Documents\Games at one point. My Documents was a user dir that saw a lot of abuse over the years.
> Jeff once simultaneously reduced all binary sizes by 3% and raised the severity of a previously known low-priority Python bug to critical-priority in a single change that contained no Python code.
This sounds really plausible. A change to the C toolchain/library (for example, specialized/inlined memcpy) may affect binary sizes significantly, and may change the behavior of something the C standard leaves undefined (for example, memcpy with overlapping arguments).
I have such a Python bug right now because of something that fork()s in a way that can't posix_spawn(). One of those is a lot easier to make performant than the other.
I had the same reaction. Haven't they been selling DGX boxes for almost 10 years now? And they've been selling the rack-scale NVL72 beast for probably a few years.[1]
When nVIDIA sells DGX directly they usually still partner with SuperMicro, etc. for deployment and support. It sounds like they're going to be offering those services in-house now, competing with their resellers on that front.
Back when my job involved using Kubernetes and Helm, the solution I found was to use `| toJson` instead: it generates one line that happens to be valid YAML as well.
where podman-wrapper passes `--user=1000:1000 --userns=auto:uidmapping=1000:$SERVICE_UID:1,gidmapping=1000:$SERVICE_GID:1` (where the UID/GID are set based on the $USER environment variable). Each container runs as 1000:1000 inside the container, which is mapped to the correct user on the host.
I wonder when quantum computers will be able to target post-quantum RSA [1]. Normal RSA operations (key generation, encryption, decryption) have an asymptotic advantage over Shor's algorithm, so it is not unreasonable to just use large enough keys. The advantage is similar to Merkle's puzzles [2], with the added bonus that the attacker also needs to run their attack on a quantum computer.
A while ago I generated a gigabit RSA public key. It is available at [3]. From what I remember, the format is: 4-byte little-endian key size in bytes, then little-endian key, then little-endian inverse of key mod 256**bytes. The public exponent is 3.
Post-Quantum RSA is clearly a joke from djb, to have a solid reply when people ask "can't we just use bigger keys"?. It has a 1-terabyte RSA key taking 100 hours to perform a single encryption. And by design it should be beyond the reach of quantum computers.
