I think this is a really bad idea unless paired with some regime that penalizes inappropiate use of alarms - and most societies don't treat noise pollution as a real problem. For example, people honk all the time even when there are no safety issues. Or have misconfigured home/car alarms. Outlawing using ANC for blocking "fake alarms" only makes the problem worse.
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.
> 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)
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)
You don't need fsync if you only care about your user process being killed. It protects only against power loss/kernel crash - the filesystem is not running as user process, so it can't be killed.
You can imagine you are converting BTC to dollars right before purchase. If you had 1 BTC worth $1000 at the beginning of the year and then 6 months later (when it was worth $1500) bought something with it - you earned $500 in capital gains. (Not saying this is the current law, but that method seems to make sense)