gorkish

Agree in general, though with Libreboot the pedantry is more or less the point of the project. You fork a project and put 'libre' in the name, I personally see that as a statement of dedication and expect you to stick to those guns. The experiment isnt much of an experiment otherwise.

Coreboot still exists.

If your storage devices are native PCIe and your network is actually fast enough and your nics and switches have the proper hardware and driver support and your switches are properly configured and your nfs client and server configurations are tweaked just so, and you hold your face in just the right position

The perf is amazing

This is a ConnextX4 on a thunderbolt bridge. This is well trodden territory. Unless some hero of open source has come to bat recently, MacOS doesn't support RDMA with this card or over Ethernet at all for that matter. It's only supported over Thunderbolt.

His iperf3 results show that it's able to go full beans on a single 25g port. A cross platform SMB file copy is kind of a meaningless benchmark in this context.

IMO a pretty cool product would be a network switch providing native thunderbolt interfaces to multiple upstream hosts. That wouldn't magically fix this RDMA issue, though. This is just a separate thought. Seems like the kind of thing Mikrotik should make.

CRS are L3 switches; they are supposed to route and run dynamic routing protocols and do ECMP and all the good stuff so long as you dont configure features like nat and firewall that require the cpu and cant be offloaded.

The one thing that it frustratingly does not support that I wish it did is stateless bgp with ipv4 prefixes. It cant offload an ipv4 packet with an ipv6 next hop.

I think you are right and most people here are overthinking it.

If you make a bunch of identical API calls quickly, before the initial request completes its cache write, you will have cache misses.

If you make a single API call to warm the cache, then make a bunch of subsequent identical requests, you will have cache hits.

The optimization for this sort of thing is to deduplicate in-flight requests, but i've seen no evidence that is being done; the better design pattern would be an api or tool call that explicitly launches multiple agents after a shared prompt processing stage

There's no single call that can launch multiple event loops at the same time, so there really isn't a notion of serial or parallel; it's always going to be a simple question of how the first model calls made by each hit the backend. I highly doubt that a bunch of agents created within milliseconds of each other are going to get cache hits. It's more likely they will spin up in parallel. I strongly suspect if Anthropic were trying to deduplicate their inflight requests for cache efficiency, they'd at least want to tell you about it.

I'm gonna jump in here and say that the way Anthropic's KV cache works (prefix matching) doesnt guarantee this at all if the subagents are all put into flight at close to the same time. There's nothing in the agent SDK that allows you to instance more than one agent simultaneously, and the docs don't say anything special about KV cache use by agents in this scenario.

You could probably engineer your own harness or workflow to warm the cache by running a single warmup agent, but this is not at all how the tools behave out of the box. It's mostly a cost optimizaiton, so Anthropic really don't have any incentive to do it proactively, and if they did, surely they would want to tell their customers how much they were saving?

I'm betting the person who created the "artist rendering" isnt an aeronautical engineer.

There is essentially zero chemical difference whatsoever in sugar vs corn syrup coke. sucrose disassociates in the presence of an acid into glucose+fructose simple sugars. Just being carbonated will disassociate the sucrose.

Just a cynical observation here, but its funny how the author still hangs onto the notion that it is "the best" despite that it de facto cannot be "the best."

Also, maybe dont rely on a poorly maintained app for making secure connections to your systems? Just me?

It is kinda weird how all the chat type tools all spit out such cheeseball language despite that the raw models almost never generate stuff like that. It honestly just makes me feel like the people making this shit are so caught up in their own hype bubble that it doesn't even register to them as abhorrent.

woah hold on a sec. that's not how these clocks are actually used though.

It's a huge huge huge misconception that you can just plunk down an "atomic clock", discipline an NTP server with it and get perfect wallclock time out of it forever. That is just not how it works. Two hydrogen masers sitting next to each other will drift. Two globally distributed networks of hydrogen masers will drift. They cannot NOT drift. The universe just be that way.

UTC is by definition a consensus; there is no clock in the entire world that one could say is exactly tracking it.

Google probably has the gear and the global distribution that they could probably keep pretty close over 30-60 days, but they are assuredly not trying to keep their own independent time standard. Their goal is to keep events correlated on their own network, and for that they just need good internal distribution and consensus, and they are at the point where doing that internally makes sense. But this is the same problem on any size network.

Honestly for just NTP, I've never really seen evidence that anything better than a good GPS disciplined TCXO even matters. The reason they offer these oscillators in such devices is because they usually do additional duties like running PtP or distributing a local 10mhz reference where their specific performance characteristics are more useful. Rubidium, for instance, is very stable at short timescales but has awful long term stability.

Yeah I really don't understand why they went this direction as it builds considerable additional complexity directly into the application to solve a problem with an external component

I would have probably approached this by implementing a fix for the misbehaving part of k8s, though since there isnt a default LoadBalancer in k8s, I can't really can't speculate further as to the root cause of the initial problem. But most CNI or cloud providers that implement LB do have a way to take feedback from an external metric. I'd be curious why doing it this way wasn't considered, at least.

RISC is dead; long live RISC