That’s the question I’ve been mulling over for days, because
I don’t see how this action can make any particular guarantees
about durability, at least not in any portable way.
However, CouchDB is not susceptible to the sad path.
However, CouchDB is *probably* not susceptible to the sad
path. While we can't guarantee it can't happen due to how
various I/O operations are (not) specified, we're doing as much
as we can to prevent it. Also, don't forget that your storage
device might be lying about fsync anyway.
Using OpenZFS as an example (hey, it’s what I know), fsync()
always flushes anything outstanding for the underlying object,
regardless of where the writes came from.
Uh, that is exactly what a derivative work is. You literally specify that Hamlet is an input to your work. I believe you're conflating derivative with transformative. You're certainly creating a transformative derivation of Hamlet, but you are by definition creating a derivative work by training a Markov chain on the text of Hamlet.
The obvious follow up here is whether an LLM is creating transformative derivations or not. A lot of folks argue that yes, an LLM spitting out statistically sampled code that matches existing code is not transformative and is (or might be) infringing the terms of the license it was released under. Others argue that there's not an exact copy of the original source in the LLM's weights so by definition it must be a transformative work. I think it's a pretty obvious "somewhere in the middle" that is gonna make a bunch of lawyers a whole lot of money.
Personally, I don't care one way or the other. I'm one of the folks that thinks software shouldn't be copyright-able in the first place.