Can you explain this in more detail? It doesn't seem true on a first glance.
If you enable compression on ZFS that runs on top of dmcrypt volume, it will naturally happen before encryption (since dmcrypt is the lower layer). It's also unclear how it could be much faster, since dmcrypt generally is bottlenecked on AES-NI computation (https://blog.cloudflare.com/speeding-up-linux-disk-encryptio...), which ZFS has to do too.
SSH is actually really slow on high latency high bandwidth links (this is what HPN-SSH patches fix: https://www.psc.edu/hpn-ssh-home/hpn-ssh-faq). It's very apparent if you try running rsync between two datacenters on different contients.
HTTP/3 (and hopefully this project) does not have this problem.
Sounds like a complex change to fix a security protocol but, reading the page, it seems to just increase the send buffer, which indeed makes sense for high-latency links
> It is impossible for something to be a good investment and affordable. They go against one another.
Why do you think that's the case? Many companies are a good investment, while they still provide affordable products. Something can be cheap in an absolute sense, while still providing a good return on investment.
Could you have instead changed your code? It's generally best to assume that it's not possible to delete secrets once they are shared (after all, in worst case, the driver could have just remembered the code from the previous visit)
At one point during the pandemic, I lived in a different state than two doctors who I saw virtually every few months (due to moving during the pandemic to a nearby city that happened to be just across the border). The state I lived in put fairly short deadlines on how long they'd allow out of state telemedicine, and whenever it came within a few weeks, they reiterated to the doctors I saw that they would _not_ extend the deadline...only to extend it at the last minute anyhow. By the time it finally didn't actually get extended, I had moved back, so I didn't need to actually make this decision, but the sense I got is that the ones who would have gotten in trouble would be the doctors, not the patients, and considering that I knew and liked these doctors (and obviously had a vested interest in them continuing to practice), I wouldn't have risked it for their sakes, despite the inconvenience.
I regularly see an out-of-state provider via telemedicine and no, nothing stops me from lying and saying that I'm in the same state as the provider. (He knows and doesn't care.)
The telemedicine visits themselves are conducted through MyChart. It's definitely not checking my IP or it would've caught me a long time ago, especially since I have to check the "I am currently in <x state>" checkbox every single time I see him :P
You can just trust IP geo databases to be accurate down to the country* - and that's only most of them time and not even considering VPNs exist.
Sure, if something looks fishy you could then go through the appropriate legal channels to get a more exact location from the ISP, but false positives are going to happen so often, eventually everyone involved might get a bit cranky.
* Only the likes of Google have the scale and requisite information to keep more accurate and up-to-date databases, and even those are fallible.
> You can just trust IP geo databases to be accurate down to the country*
You can't trust even that. There's an ISP which shares the IP pool between its child companies (? or some similar arrangement) in Crimea and Poland. We found out when Polish subscribers got affected by sanctions on business with Crimea.
My home IPs get placed into another country by geolocation all the time (it's probably more wrong than right). My VPN IPs (for which I always use either Finland or the Netherlands) have been geolocated to: three states in the US, Dubai, and several other EU countries.
You can also share arbitrary binary data between processes by using shared memory (e.g. Python has support for this in multiprocessing.shared_memory module).
fsync is still a bit slow on BTRFS (on ZFS too, but to a smaller degree). For example, I just did a quick benchmark on Linux 5.3.0 - installing Emacs on fresh Ubuntu 18.04 chroot (dpkg calls fsync after every installed package).
ext4 - 33s,
ZFS - 50s,
btfrs - 74s
(test was ran on Vultr.com 2GB virtual machine, backing disk was allocated using "fallocate --length 10G" on ext4 filesystem, the results are very consistent)
If you enable compression on ZFS that runs on top of dmcrypt volume, it will naturally happen before encryption (since dmcrypt is the lower layer). It's also unclear how it could be much faster, since dmcrypt generally is bottlenecked on AES-NI computation (https://blog.cloudflare.com/speeding-up-linux-disk-encryptio...), which ZFS has to do too.