jdcasale

Yeah unless they don't, though. They're only going to pay if they actually do business in France. Otherwise there is no legal or practical mechanism for the French government to compel them to pay.

Apologies for hijacking this comment, but if you have any interest in doing this sort of work full-time I may have a job for you. This project is awesome.

I've been thinking a lot about what it would look like to support verifiable/auditable guarantees around data exfil/capture for this class of use.

I don't think it's enough to pinky-promise that you aren't sending a dragnet of video with facial capture etc back to the mothership, I think you really end up wanting auditable proof that nothing sensitive can leave the robot or at the very least a no-logging hot-path inference loop (e.g. apple's confidential compute).

Yeah I'd written some rust ~ 10 years ago when the language was very different and that led me to believe that it was a 'great within it's niche' sort of thing for a long time, but after spending the last couple of years with it as a daily driver I think it's a pretty great general-purpose language.

The one really common gotcha with rust is that when trying to write concurrent code, newbies tend to throw Arc<RwLock<T>> goo around everywhere, and they end up with the world's shittiest garbage collector.

The barrier to entry was the point, it's what created community. There is really no such thing as a durable community without entry and exit friction.

But games that rely on community are thus generally less scalable and profitable than games that don't. WoW was an aberration (partially because it had almost no competition at the time it was building its player base). It set profoundly unrealistic standards for the genre, and the gravity of community building in a contested space kind of killed off the rest of the genre because no one else was able to do it at 'WoW-scale', which was held up as the benchmark for what good looks like.

I think that within the next year or two we'll have the ability to put a frontier-class model on our desks, and I like the idea of playing around with that today to get ahead of it. I could be wrong, I often am.

I'm not optimizing for $$$ spent today and agree that this isn't the cheapest solution to a specific capability problem, but I don't super mind paying for a cool piece of compute that I can do some fun (and educational) stuff with.

Also (in case this isn't obvious) I'm 100% a fan of the decision to _not_ tightly couple to the kafka wire protocol. Kafka's apis are full of landmines and gotchas, and you can do much better from a UX perspective if you're not married to their quirky semantics.

I had heard people talk about the operation pain involved in keeping Kafka alive (which is a thing for sure), but what I was surprised by was how many things behaved in a slightly unobvious manner that wasn't loudly-documented (e.g. if you're using transactions for RWP loops the default rebalance protocol is unsound and transaction markers take up an index in the log so you no longer have contiguous indices in your message stream etc).

I'd consider a 1tb machine at 20k, but I'm not going to pick up a 256gb one at all. 1TB fits a frontier-ish model in memory without massive quantization, which is a very interesting capability for a non-rack piece of compute.

Fwiw the only two times I've used kafka in my career have been for traffic on the order of GBs/sec. And the folks I know who have relied on streaming pipes for genuinely realtime stuff built bespoke systems with RTT on the order of 10s of micros.

There are plenty of usecases for lower scale or higher latency (my examples are somewhat unique), and owning the opinionated middle instead of claiming to cover everything is a really useful thing, but acknowledging that the system is opinionated such that it covers a specific set of things well is generally a better argument than 'this basically does everything that people need'.

The previous comment didn't say that Starbucks doesn't suck (they probably agree that it does -- I've never met anyone who really likes coffee who doesn't agree that modern at-scale Starbucks is awful), they just asserted that the badness there is not explained by faulty temperature control.

It's both.

The US has generally resorted to propaganda rather than addressing the self-inflicted structural conditions responsible for the erosion of our dominance. China also conducted a broad, sustained, large-scale campaign of IP theft across almost every industry.

Obviously there is no natural law preventing China from innovating (We have treated political liberalism as a prerequisite to innovation in a way that was always partly self-congratulatory), but it's also obviously true that the speed of the gap closure is due in significant part to theft.

That doesn't change the fact that they are now a legitimate competitor who has gotten a lot of things right (and among these, some things that we get very wrong) and probably actually leads in some areas.

Without weighing in on whether this is true, I'll point out that LLMs could both be better writers than most people and also be bad writers.

Writing is a difficult skill that many (most?) educational systems do not effectively teach. Most people are terrible writers.

The math is obvious on this one. It's super well-documented that model performance on complex tasks scales (to some asymptote) with the amount of inference-time compute allocated.

LLM providers must dynamically scale inference-time compute based on current load because they have limited compute. Thus it's impossible for traffic spikes _not_ to cause some degradations in model performance (at least until/unless they acquire enough compute to saturate that asymptotic curve for every request under all demand conditions -- it does not seem plausible that they are anywhere close to this)