The great promise and the great disaster of LLMs is that for any topic on which we are "below average", the bland, average output seems to be a great improvement.
I think the "messy ideas" was a reference to the homepage copy "Turn your messy ideas into crystal clear specs.", not continuing the previous thought about the placeholder. I'd agree that "messy" might have more negative connotations than you intended.
Learned a few things I didn't know about exception handling, like Vectored Exception Handling. If it's possible to somehow have enough permissions to install a generic vectored exception handler that has enough complexity to emulate generic instructions, not sure why the shellcode couldn't just be included there instead.
Maybe someone else will have a follow on regarding some product that does some more complicated processing in a VEH that could be used to implement something that has the same shape as this.
The disk controller may decide to write out blocks in a different order than the logical layout in the log file itself, and be interrupted before completing this work.
Just wondering how SQLite would ever work if it had zero control over this. Surely there must be some "flush" operation that guarantees that everthing so far is written to disk? Otherwise, any "old" block that contains data might have not been written. SQLite says:
> Local devices also have a characteristic which is critical for enabling database management software to be designed to ensure ACID behavior: When all process writes to the device have completed, (when POSIX fsync() or Windows FlushFileBuffers() calls return), the filesystem then either has stored the "written" data or will do so before storing any subsequently written data.
A "flush" command does indeed exist... but disk and controller vendors are like patients in Dr. House [1] - everybody lies. Especially if there are benchmarks to be "optimized". Other people here have written up that better than I ever could [2].
It’s worth noting this is also dependent on filesystem behavior; most that do copy-on-write will not suffer from this issue regardless of drive behavior, even if they don’t do their own checksumming.
NVMe drives do their own manipulation of the datastream. Wear leveling, GC, trying to avoid rewriting an entire block for your 1 bit change, etc. NVMe drives have CPUs and RAM for this purpose; they are full computers with a little bit of flash memory attached. And no, of course they're not open source even though they have full access to your system.
I ran qmail for more than a decade I think (after sendmail), and don't regret it. But eventually ended up with postfix because I got tired of chasing patches to get qmail to play ball with the evolving, modern email world. At some point, the risk/reward equation inverted.
the problem of qmail is it's author DJB. He considered it 'done' which obviously isn't true. There are quite a few patched versions around but no fork got enough traction to become a living and maintained project.
For a long time you couldn't actually fork it because qmail didn't have a license and djb refused to add one due his unconventional views on licenses and his general stubbornness. So the only thing you could do was distribute a "patch set". And all of this also meant it wasn't packages in many repos.
By the time he finally added a copyright notice it was kind of a "too little, too late" kind of affair.
This is the story with most "djb-ware": daemontools, djbdns, qmail. I think it's a real shame because all of these had great potential to be picked up by others after djb himself lost interest. I suppose daemontools is the most "successful", but only in the form of the runit re-implementation.
reply