int3trap
Who thinks OpenAI or any big company for that matter give a crap about them? This isn't a popular sentiment at all, it's just patently false.
It's a perfect example of people wanting to believe what they want to believe and ignoring evidence in order to do so.
Currently, there's no evidence. So saying it was stolen has no basis other than typical academic posturing and being a bad sport about "losing the race to the solution". Its happened 1000000 times before in academia and it will continue to happen.
If there's proof of OpenAI malfeasance than I'll happily curse them for it at that time. But until then I won't rely on heresay and vibes.
It's incredibly tiresome and you'd think people could put more effort into it than just following whatever vibes they agree with.
Oh well.
There are a number of plausible explanations including just someone DID have the time and wasn't all that busy. That's even more likely but I wanted to call out the perspective that it might not have been the most typical situation that led to this.
Its not everyone building crystal palaces in their mind, they're all building fortresses. And they can't be wrong in their fortress or it breaks their world view which they cannot accept.
2. The content is lower quality.
That is not really established. The Anthropic issue was specifically about DoD use and Anthropic's military use restrictions. What the Trump admin did was bad and coercive but its not proof that contract terms and law are irrelevant. For instance, why not just use eminent domain if they don't care about contracts and want whatever they want?
> either they were signing up for a supply-chain risk designation and whatever other punishments the Trump administration dreams up, or they're complying
Couldn't OpenAI have negotiated different terms, accepted a narrower scope, or drawn different red lines? Their public DoD terms still exclude things like mass domestic surveillance and autonomous weapons outside human control. Do you not believe that or believe it doesn't matter at all? Either of those is problematic to the conclusions that follow from them.
I also think the whole argument implies something about Anthropic's position that's not as clean in reality. NSA is already using Mythos despite the Pentagon dispute, and Anthropic is still talking to the administration. Trump even said they were "shaping up" recently.
Isn't it also a possibility that one company negotiated poorly and took a position of perceived moral authority that Trump et al threw a hissy fit over and over reacted to? That's happened countless times with this admin and is far more likely in my opinion given Anthropic hasn't cut all ties and continues to try and work out a contract.
I wholeheartedly agree the current administration is dangerous. I just don't think the conclusion "OpenAI must be complying with the same demands Anthropic refused" follows from what we've seen. And I think there are plenty of other far more plausible conclusions to draw from the events.
Ahh, that's interesting. I think you still run into the issue where you have a case like this:
1. You get 10 pipelined requests from a single connection with a post body to update some record in a Postgres table.
2. All 10 requests are independent and can be resolved at the same time, so you should make use of Postgres pipelining and send them all as you receive them.
3. When finishing the requests, you likely need the information provided in the request object. Lets assume it's a lot of data in the body, to the point where you've reached you per connection buffer limit. You either allocate here to unblock the read, or you block new reads, impacting response latency, until all requests are completed. The allocation is the better choice at that point but that heuristic decision engine with the goal of peak performance is definitely nuanced, if not complicated.
Its a cool problem space though, so always interested in learning how others attack it.
I recently wrote my own zero allocation HTTP server and while the above statement is possible to achieve, at some point you need to make a decision on how you handle pipelined requests that aren't resolved synchronously. Depending on your appetite for memory consumption per connection, this often leads to allocations in the general case, though custom memory pools can alleviate some of the burden.
I didn't see anything in the article about that case specifically, which would of been interesting to hear given it's one of the challenges I've faced.
It encourages good designs but it does not make them easy to write, but that's somewhat the point. Its not trivial to design a safe API that pushes performance limits.
> just write a lockless triple buffer for efficient memory sharing and wrap the unsafe usage of pointers with a safe API
This isn't practical or pragmatic.
And I say this as someone who likes rust and develops in it every day.
Would we say this is divergent? Cassandra, DynamoDB, and many others allow you to specify the consistency of reads at the request level.
> Here's where SierraDB diverges from traditional distributed databases: reads don't require quorum. Instead, each event stores a confirmation count in its metadata. When a write achieves quorum, a background process broadcasts this confirmation to all replicas, updating their local confirmation counts. This means any single node can serve consistent reads without network round-trips - a massive performance win.
I have no context outside of this blog post, but this seems actually divergent from the typical definition of consistency given its not linearizable. What systems benefit most from this low latency stale-but-ordered consistency guarantee?
RTO in combination with Amazon being last place in AI innovation have led to departures of anyone that can leave, leaving.