471 karma · joined December 14, 2016
Ahh, very well said!
> We see that something external and orthogonal to the program, i.e., changing the size (in bytes) of an unused environment variable, can dramatically (frequently by about 33% and once by almost 300%) change the performance of our program. This phenomenon occurs because the UNIX environment is loaded into memory before the call stack. Thus, changing the UNIX environment size changes the location of the call stack which in turn affects the alignment of local variables in various hardware structures.
From https://www.inf.usi.ch/faculty/hauswirth/publications/asplos....
Edit: Oh, I see it's been recommended in this thread already.
Not my area either, but a little surprised why a PCG-family non-CSPRNG algorithm wasn’t used: https://www.pcg-random.org/posts/a-quick-look-at-xoshiro256....
PCG XSL RR 128/64 (MCG) could be used for 64-bit values (albeit with period 2^126 compared to xoroshiro256’s 2^256 − 1) with 128 bits. Half the state size than xoshiro256, and the performance might be comparable (would need benchmarking). LCG version if you want to trade PRNG quality for even more speed.
Switched to iPhone SE a while ago because of this.
Then, go get -v will download your dependencies to GOPATH, and (re)generate go.mod, go.sum. For info on how to update dependencies, read `go help get`.
When using modules (presence of a valid go.mod file), GOPATH won't be used for resolving imports. So you don't have to actually work in GOPATH anymore, dependencies are just stored there.
I was planning on setting up my own recursive resolver one day (tm) but NextDNS really just makes everything so seamless + easy.
This is a major pain point for me - I'm trying to use both NextDNS and Tailscale on my iPhone SE 2016, and confirmed that they clash with each other. :(
Really exciting times where an A9-based quality handset can be had for ~$60 on eBay. I expect prices will fall a bit further with this new SE model. And yes, the A9 is completely viable in 2020. Planning on holding onto it for as long as reasonably possible.
If you're looking for a bit of feedback, the search doesn't seem to handle fast typing well. I tried searching for "Frank Chu" and it seems that if I type it really fast, I get either no results or Franks that aren't Frank Chu. If I type slower, Frank Chu shows up.
It's worked really well for me. Used to use stow.
It's not that people don't care; privacy is probably undervalued in the context of making privacy vs. convenience/utility decisions. (Digital) privacy's value isn't really tangible until it's actively used against you.
1: https://jrl.ninja/etc/2/strace-go-1.12.3.txt
src for above: https://jrl.ninja/etc/2/getaddrinfo.go.txt
Also have a bunch of umatrix rules, but not inclined on sharing those. Regarding gmail, keep a pinned tab open on about:memory and periodically click on GC and minimize memory, that might be a better solution than reloading.
However, here's my reasoning for the first of your questions, as a happy fd user who switched from GNU find. Maybe it can give you insight into why the UX is designed as it is.
The extension is distinguished from the filename because it's a common use case (-e jpg less keystrokes than -iname '*.jpg'), it's semantically separate from the filename (IMO) and therefore should not be treated as part of it. And unlike filenames, extensions most often do not need to be pattern matched. If you want to match multiple extensions, just repeat the -e flag e.g. -e jpg -e png.