The other actress wasn't the only one involved in the production; she provided input but OpenAI building a voice model would involve a lot of data and input. They had to have a model of her ready to go when they asked her for permission immediately before launching; possibly they had one that had been built from her, and another legal-approved that they had converged to be close to the first one but that didn't include her as a direct source.
Emergency braking feels more like shoving the wheel forward than shifting oneself behind the wheel. You ignore balance for a while, get yourself into a sitting position fast, the system can right itself (or not) after you've bled enough speed.
There are two level of pointers: the environment block points to an array of pointers to C strings, this higher-level pointer can be updated and the previous one freed, which is a problem when it is being iterated on (which getenv does). The C strings themselves aren't freed by glibc, though some applications do modify them in place.
OIC, so because glibc doesn't hold the setenv lock during lookup a concurrent getenv can break, but once getenv has found an entry that entry is guaranteed to be valid (unless the application plays silly bugger) because setenv will not free the individual entries.
You may have a mutex on getenv/setenv, like the Rust stdlib does, but when libc doesn't look at that mutex, even on the read side, you run into UB.
So the next step is never calling into seemingly innocent libc functions in safe code (which you have to enforce on your dependencies as well), implementing safe alternatives to a good chunk of libc (and making sure your dependencies use those), to cordon off anything that looks at the environment. This makes a good chunk of POSIX functionality useless.
kernel developers are free to factor in common functionality, calling into it library style, without making it into an externally visible layer. IIRC fs encryption and case insensitivity are often done that way, and I think I'd count the page cache and bios as larger library-style components as well (as opposed to the VFS layer which is more in a framework style).
bcachefs format /dev/sd[ab]1 \
--foreground_target /dev/sda1 \
--promote_target /dev/sda1 \
--background_target /dev/sdb1
mount -t bcachefs /dev/sda1:/dev/sdb1 /mnt
This will configure the filesystem so that writes will be buffered to /dev/sda1 before being written back to /dev/sdb1 in the background, and that hot data will be promoted to /dev/sda1 for faster access.
bcachefs format --help
--promote_target=(target)
Device or label to promote data to on read
That is very cool. I under specified when I last spoke. I was hoping for something that would cache arbitrary files. I have a slow FUSE fs I would like cached.
But perhaps I can use bcache instead of cachefilesd to have some more controllable NFS cache.
Bcache seems to use block devices and I don't think it can stand in front of FUSE.
i used to use [0]s3ql on-top of "slow" fuse storage. it comes with its own caching layer and some strategies around handling larger blobs of data efficiently even at high latency with ease but its a non shared filesystem. you mount/lock it only once at a time. otherwise this was a perfect solution to me at the time.
there is also [1]rclone with its own caching layer and own support for various backends directly. I don't remember anymore why i did prefer s3ql though, but i usually have some reasoning with things like this..
I was thinking of that around the "stack-based interpreted language" paragraph.
Mozilla's RLBox/wasm2c approach would be good for this, for example. Postscript can still mix data and code, but it won't jump outside of the sandbox, and the rest of the program treats its output as untrusted.
