> For the print library copies that Anthropic purchased and then converted into digital library copies, Anthropic already enjoyed entitlement to keep the copies in its library. The purpose of the copying was to keep them in its library but with more favorable storage and searchability properties. Copying the entire work was exactly what this purpose required. There was no surplus copying. The source copy was destroyed.
> The third fair use factor favors fair use for the purchased library copies converted from print to digital.
...
> This order grants summary judgment for Anthropic that the training use was a fair use. And, it grants that the print-to-digital format change was a fair use for a different reason. But it denies summary judgment for Anthropic that the pirated library copies must be treated as training copies.
Because simplicity is hard and often the result of careful thought. Anybody can keep piling pile of shit on top of pile of shit which is why that sort of code is so common in our industry.
> but it's irritating to perform a full row-to-column conversion through an inefficient, non-batched API in order to get the data through JDBC and into TMD
[...]
> In the last two years, DuckDB improved a lot. Importantly, the C interface now provides a batched system for both inserts and querying, which enables processing very large joins
That's why. Basically JDBC doesn't offer the batched APIs needed to get the same performance.
Pretty sure that is entirely an unfair comparison. You don't need a connection per thread either. It is common to have web servers handles thousands of requests per second with a connection pool size of 20. As long as the handler threads borrow a connection for only a little time and block waiting for a connection while other threads are doing their thing, it works out fine.
There is absolutely no logical reason why database pool sizing could be a reason for preferring fibers over threads.
The problem only arises when you have to worry about persistent state. As soon as you have to worry about that, you have to think about backups, replicas, disaster recovery drills and so on. It is much easier to solve for that can of worms for one system than three.
Typical production architecture would look like
- frontend only ever sees an opaque session cookie
- bff stores the access token against session and attaches it when calling backend services
Yes, storing JWTs directly in the frontend client is a bad idea but surely there is a better way of communicating that than "JWT is a scam and your app doesn't need it".
> RS256 verification is in the same order of magnitude as a Redis lookup
But the point is that the verification is CPU bound and local to the service - which means that it is horizontally scalable.
Almost every OAuth2 service out there does exactly that: access token for client/bff, refresh token in HttpOnly cookie.
It’s a lot of work to get it right in SSR environments, since both the bff and the frontend need to be able to refresh the access token (preferably transparently during an in-flight request). Even then, access tokens really should expire within a minute or two, not hours or days.
> it starts by raising this question, then argues that it’s kind of a cheap and meaningless punch-down.
The cheap and meaningless punch-down in the article is the vibecoding accusation. The question in the title is actually their main line of attack against that accusation, all the way to the end.
>> QED
So.
Where are the vibecoded Photoshops?
WHERE IS THE THREAT YOU MADE UP TO ATTACK ME?
>>I'm waiting.
I find it hilarious that so many people are finding it so difficult to grasp even the general line of argument of the article despite trying earnestly.
reply