Sadly another shot in the arms race that captchas started which just leads to increased inaccessibility.
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...
A lot of the solutions in the CPU space involve things like memory allocation flags, NX bits, canaries, etc. that fire deterministically. Those things are fundamentally not applicable to LLMs, and without those things modern software would be in a vastly worse place.
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.
This plausibly demonstrates why a nonprofit may not be a great vehicle for some free software projects - while the nonprofit should do whats best for the project, if the main work is done by commercial sponsors then it’s crucial those sponsors feel the relationship is beneficial.
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.
What would be great, and I don't know if @dang / the mods would take on requests like this, would be for bot participants to be allowed but the account flagged. So e.g. the user name just says "[bot] Zakodiac" or something.
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]
I think they needed to be clearer about what the actual requirement was.
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 suspect there is a bit of knee-jerk because so often this pattern is misapplied. I actually quite like the example in the article although I'm basically allergic to CQRS in general.
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.
Moore's law has kind of ended already though, and maybe has done for a few years, and even if you can make a chip which is faster there's a basic thermodynamics problem running it at full tilt for any meaningful period of time. I would have expected that to have impacted software development, and I don't think it particularly has, and there's also no obvious gain in e.g. compilers or other optimization which would have countered the effect.
I don't want to sound too dismissive, but all these arguments have been brought up time and again. The move from assembler to high level languages. The introduction of OOP. Component architecture / COM / CORBA / etc. The development of the web browser. The introduction of Java.
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.
Sure, but would we really want to tell liquidators to manage assets for best eventual return rather than just convert everything to cash? In this instance, in hindsight, sure - you'd want the other thing, you want the bitcoin not the cash. But this feels like the exception that proves the rule.
The trustee's reports on FTX's internal processes were damning. Even they had held their Anthropic on the way up, who's to say their internal FTT ledger and black holes in the Alameda books would not have eclipsed that?
The issue wasn't that crypto markets in general were down at that point; the issue was they were doing frauds.
Is it possible to design a piece of software that is identical to soup.io but runs at a fraction of the cost?
The answer is almost certainly "yes, if you're willing to rewrite it from scratch". Unfortunately the capex required to do that weighs heavily on the opex saving.
"They should have designed it from the start to be efficient" would normally be my next thought - but there by grace go us all.