ealexhudson
Joined 15 years ago
Joined 15 years ago
The seed for P-224 uses a timestamp from 1998, and they also said the four binary curve seeds were timestamps from 1984 that were doubled - someone did srand48(time / 2) not srand48(time).
Did the P-224 seed get updated later / was not provided in 1997, or is there some other reason for this? Otherwise, it looks like one third of these values need additional excuses to get them to map to the time range in question...
It's interesting work for sure, but the end goal of separating out AI versus human consumers is tough. Indeed, if there was a lasting solution, that would be a substantial discovery that would quickly become very famous...
You could imagine that there are things to change around LLM architecture that will improve its ability to reject prompt "injection", but I think it's fundamentally true that from an information theory perspective there's no bright line between "instruction" and "input data" possible.
The reality is free software office apps require significant professional development input. Apache Open Office is the obvious example.
It’s a classic version of the tragedy of the commons. If Collabora goes off to its own thing, I struggle to believe they will maintain the development rate with new devs, and without development the TDF sponsorship will fall off.
I hope we are not looking back in two years time regretting this.
As well as being an ethical approach - I think it's wrong to try to impersonate humans and/or not announce AI output as AI - it would also be handy for new filter options: all bot posts are OK, hide bot leaf comments, or hide all threads with bot comments. etc.
[edited as my robot unicode/emoji char didn't come through]
If the requirement is, "Show the balance _as it was_ at that point in time", this system doesn't fulfil it. They even say so in the article: if something is wrong, throw away the state and re-run the events. That's necessarily different behaviour. To do this requirement, you actually have to audit every enquiry and say what you thought the result was, including the various errors/miscalculations.
If the requirement is, "Show the balance as it should have been at that point in time", then it's fine.
I think your point about write-ahead logging etc is a good one. If you need a decent transactional system, you're probably using a system with some kind of WAL. If you're event sourcing and putting events into something which already implements a WAL, you need to give your head a wobble - why is the same thing being implemented twice? There can be great reasons, but I've seen (a few times) people using a perfectly fine transactional DB of some kind to implement an event store, effectively throwing away all the guarantees of the system underneath.
2018 isn't "the start of the decline", it's just another data point on a line that leads from, y'know, Elite 8-bit on a single tape in a few Kb through to MS Flight Simulator 2020 on a suite of several DVDs. If you plot the line it's probably still curving up and I'm not clear at which point (if ever) it would start bending the other way.
The issue wasn't that crypto markets in general were down at that point; the issue was they were doing frauds.
Where the lockfile doesn't exist, it creates it from whatever current is, and the lockfile then gets thrown away later. So it's equivalent to what you're saying, it just avoids having two completely separate install paths. I think it's the correct approach.