They released deepseek/deepseek-chat-v3.1 shortly after I did the evals, and that's what I now use 20+ times a day for all my questions. It replaces chat-v3 and r1, depending on whether you enable reasoning or not.
I'm the author of the post. Thanks for highlighting this. It's very confusing.
I cannot use it directly in OpenAI's API, even today:
> $ llm -m gpt-5-mini Hello
> Error: Error code: 400 - {'error': {'message': 'Your organization must be verified to stream this model. Please go to: https://platform.openai.com/settings/organization/general and click on Verify Organization. If you just verified, it can take up to 15 minutes for access to propagate.', 'type': 'invalid_request_error', 'param': 'stream', 'code': 'unsupported_value'}}
Until two days ago, OpenAI on OpenRouter was Bring-Your-Own-Key (BYOK), so it didn't work there either.
Since they dropped BYOK, I can indeed use it through OpenRouter:
> $ llm -m openrouter/openai/gpt-5-mini Hello
> Hi — hello! How can I help you today?
This is for both `gpt-5` and `gpt-5-mini`. The `-nano` has always worked. I'm going to try some of my evals on gpt-5-mini, but it doesn't feel like I can depend on it.
That attitude to crypto is pervasive, annoying, and wrong. We don't tolerate the "you're too stupid to use that" attitude in any other part of software development, and we shouldn't tolerate it in cryptography.
Every developer needs to touch crypto. Encrypted communications needs to be our default. And yes, of course, we should prefer verified, standard algorithms (NSA Suite B, for example).
It's OK to get it wrong, it's OK to fail forward, even with cryptography. ROT13 will protect you very well, if your attack vector is someone glancing over your shoulder for 1 second. As long as the code is open, and you're honest about what it does, you've made people a little bit safer.
There's a fair amount of gloating around Cryptocat, but it protected people's communications from me, because I didn't know how to break it. So that's better than nothing.
There might be better performing hosting providers, and there are definitely lower cost providers than Linode, but I don't love them like I love Linode.
It's not entirely rational, but if you ask around, I'd wager most people who use Linode love it.
Maybe it's because it used to be just caker doing everything, or the free disk / memory upgrades he kept handing out. I remember him asking about LASIK surgery in the (very helpful) forums; there's a family feeling to it. It's the anti-Rackspace. It's home.
Great idea. I have a little Python wrapper around that, which also copies the password to your buffer (so you never actually see it), and password generation.
If the code on darkcoding helped you build your project (we have the exact same card issuers), could you give attribution?
It would also be very cool if you open-sourced that site. The code on darkcoding is GPL, not AGPL, so you're not required to. Would still be cool of you :-)
I've been using Ginger for ~ 6 months (I work for Lincoln Loop), and it's appeal is difficult to describe.
It doesn't really _do_ anything, there's no clever features, yet as a team we've been having these intelligent thoughtful discussions since we started using it. Somehow those discussions just didn't happen with the other tools we tried.
Yes, thank you! Adding this line to the two-writes Python version (memg-slow.py on github) makes it about as fast as the single write version (memg.py on github):
I'm the author of the original post. The difference has nothing to do with epoll, these comments are correct. Thanks particularly to codeape for his pull request which made me realise this. Sorry everyone. I will fix the post.
Reducing the number of send calls, in both the C and Python versions, makes them enormously faster. Go is already batching up the writes, hence the apparent speed advantage.
If you strace the client, you see that the "get" case was replying with two send calls, one for the "VALUE" line, another with the value and "END". All the time is consumed with the client waiting to receive that second message. Depending on the client, and I tried a bunch of ways, it's either in 'poll' (pylibmc), 'futex' (Go), or 'recv' (basic python socket). That second receive is about two orders of magnitude slower than the previous recv.
Why does reading that second line take so much longer?