Top contestant in the Hutter Prize uses a neural network for compression. So fair to say, LLMs would perform pretty well compared to gzip.

Even ignoring speed per GP, the Hutter Prize's metric includes the size of the decompressor. LLMs would be disqualified for being larger than 1GB.

Hutter prize does have speed restrictions. If it did not, LLMs would win even with counting the size of the model (which is the most reasonable choice imo) as per the main benchmark: https://www.mattmahoney.net/dc/text.html.

And the hutter prize disallows GPU's. If you allow use of a powerful GPU, you can do quite a bit better.

Official Deepseek v4.1 Flash API costs are more than GPT 5.6 Luna. Deepseek v4 Pro performed worse than Luna, so I wonder if 4.1 Flash will justify the cost.

Clearing cookies when all you want to do is read static content is not "breaking expected behaviour on websites".

What's inconsistent about their versioning?

DuckDB is still OSS btw. It didn't go proprietary like Redis or ElasticSearch.

For now..

Hint: It's not 15%. And there are many reasons, such as not having to keep up-to-date billing details in 70 providers, and not wasting money because most providers want you to prepay a balance that gets stuck in there if you switch to another provider.

It also has way better uptime than the underlying platforms, even for proprietary models like Claude. When Claude APIs are having issues, OpenRouter Claude still keeps working because they can route to AWS Bedrock instead of Anthropic etc. This effect is even bigger with open-weight models because they typically have 5-10 providers.

The Offline test ranking of Tracking AI lines up much better with my experience of using the models.

https://trackingai.org/home

Really glad open-source password managers are resisting the bullying and not implementing DRM.

For now: https://github.com/keepassxreboot/keepassxc/issues/10406

Or not: https://github.com/Kunzisoft/KeePassDX/issues/2321

They are imo clearly gearing up to lock down passkeys in practice one day so that you will only be able to use those tied to a Google or Apple account (or some new player). They're already threatening in these issues to blacklist open implementations that don't submit to their requirements, and then requiring an attested client would then become the "best practice" adopted blindly and widely. I think the only hope is for the open clients to fully submit, hoping to avoid full attestation, while not making it too hard to patch out the anti-features. Of course, anyone who can't compile is screwed though.

>Or not: https://github.com/Kunzisoft/KeePassDX/issues/2321

...and it characteristic the level of patronising arrogance in the issue thread

"This is normal. It is not recommended to copy passwords to the clipboard in any case, this mitigates this behavior and complies with new Web Authentication standards."

This does not even invite a discussion. Maybe some people run tight, safe systems and know what they are doing? Maybe some people never rely on a single password being the only thing between them an an account compromise? Nope. Some patronising guy knows it all, and will override what people want to do on their machines.

If it's designed well, your application also opens a pool of connections and re-uses them each time the code needs a DB connection.

The issue is language ecosystems that don't use client side connection pooling because they're single threaded (node, Python). So scaling up the number of web server threads means scaling the number of Postgres processes, which are expensive.

Python has threads and connection pools work fine on async workers as well.

Yes but they can’t be shared. If you size your pool to hold 10 connections (because asyncio can handle that and more), then deploy with uvicorn —-workers 4 (which should match the number of cores on your app server), and then deploy to 3 app servers (for redundancy) then you’ve now got 120 open connections to Postgres. Run anything more than a trivial query and you’re easily at gigabytes of ram.

120 connections is likely fine. If it's not, you could do only 5 connections per worker. This is more of a problem if you have uneven load on the workers though.

I’m not claiming it’s not fine, but it is a surprising consideration for a relatively small deployment. You have to start planning around Postgres’ architecture for anything larger, hence the solution in PgBouncer.

This is more app instances than 99% of deployments. Most apps and websites run a single server.

This solves the latency but not the overhead--you'll end up with a full pool of connections for each running instance of your application.

How many running instances do you need though? e.g. Scala web frameworks should be able to do thousands of RPS on a single core without the application developer really trying to optimize anything, and I always hear that even Ruby, Python, etc. are also fast enough to be IO bound so you should just need 2 copies for redundancy, right? Then give each like 8-16 connections.

If I'm implementing my own connection pool, I'll certainly make the number of connections configurable.

That's fine but doesn't address the issue that PgBouncer does. Your application connection pool can multiplex all the connections needed in one application. PgBouncer can multiplex the connections across all applications (whether different apps or many instances of the same app).

It still has an internal GraphQL API. How would the official web app and mobile apps work without an API?

Right but that doesn’t mean anything about authorisation. If you’re using a key you ripped from an official app you could easily be blocked tomorrow. Makes the effort considerably less worthwhile.

It's the #6 most popular website in the world. Chances are, someone will fix the libraries or investigate and write about any changes done to the internal API pretty quickly.

Then you rip the key again from the new version of the app. But they won't do that because it would block the app.