CamouflagedKiwi

I generally like `encoding/json/v2` and I'm glad they did it.

I wish they'd left `MarshalIndent` in there though. The equivalent code is super complicated and non-obvious, so it's a pain to migrate, and it's a pain when you're banging out some quick code and want to dump some readable JSON. I suppose these days the LLMs can write the complicated version for us, of course.

This feels like it should ideally be something public in the structs package so anyone can leverage it, not just a specially blessed internal thing for the sync package.

It's absolutely not for these models. There are plenty of consumer GPUs out there with 8 or 12GB VRAM - they are comparatively very fast at inference but just aren't big enough to run lots of the models you want. Also context management is a massive pain.

Bit dubious about how some of this hangs together. One detail that stood out to me:

> They removed mounting screws, disconnected the servers and put them in laundry bags — 20 bags in all, each large enough to hold four or five servers.

That's like 100kg or more of servers in each bag? I guess that is not totally impossible but it doesn't seem like a particularly easy way to move them around. It's not like putting five laptops in a bag and walking out with it over your shoulder.

I think pretty unlikely: there is enough pub density that it's unlikely that removing that requirement nets 10 minutes of saved journey time from all the furthest destinations.

Probably because they don't want to self-host Windows or MacOS servers when they can pay someone else to do that for them (or Linux ones, I assume that is within their wheelhouse for production but CI is a bit of a different beast to model inference).

Their policy doesn't cover upstream, it's only for the Gentoo project specifically. It's clearly infeasible for them (or Debian) to try to control what their upstreams do, especially with the kernel accepting LLM contributions now.

Interesting article, seems more balanced than Andrew Kelley's one that it links to.

The thing I still think is wrong: why are Anthropic rewriting a Javascript runtime from Zig to Rust? Why not rewrite Claude Code itself in Rust (or Go or whatever, lots of options there) and drop Bun completely. That actually seems like an easier solution (rather than having to create a performant, correct Javascript runtime, just rewrite your CLI console app in something else) and the final result is better (smaller and faster) although likely not on the most critical axes for them.

They don't really "just get to say" that. Declaring yourself bankrupt is a fairly major thing that will have long-term consequences. It clearly isn't desirable to do casually, we don't see it often (at least not in the personal sense; businesses can be a bit different).

> It's one thing if you're in a crazy desperate situation and someone takes advantage of you

In that kind of situation, declaring bankruptcy is likely not going to help you so much. Those people are going to come after you anyway.

I think you sort of fundamentally misunderstand this. Bankruptcy isn't thievery - it's a solution for people who get themselves into a bad situation and don't have a way forward. Say you bought a house with a mortgage, the value of the house has now dropped for some reason so you have negative equity, and you lose your job and can't afford to make the repayments any more. What should happen? You don't have money to pay what you owe, and you can't get it because your total net worth is negative. Saying that's theft doesn't help the question of what to do - society doesn't benefit from dumping on that poor person any more.

You can't really tell people that they just can't be bankrupt though. What are they supposed to do if they have debts they can't pay but they're not allowed to declare bankruptcy because they pinky swore they wouldn't do it seven years ago?

Alpha Centauri was such a fantastic game. And even though it encourages you to move forward with technology, the tone has this unease about what you're doing. There's a lot to be learned from it.

I don't know anything about Adobe's model - I have (pretty happily) never bought anything from that company. But the two are not very similar, and I don't buy the argument that you're trying to make - I think you're trying to bring in dislike of Adobe's model as an argument against Epic's, despite the two being pretty fundamentally different.

"it's not all rainbows" - I would also not let perfect be the enemy of the good here.

> What do you even mean by "works", specifically?

It runs and accepts people's payments, which means you're not on the front page of the newspaper (not in a good way).

> ... because they're stored in terrible ancient mainframe databases, the text fields all have tiny maximum lengths. Hence they're all abbreviations. Attacker-controlled abbreviations without any authenticity assurance of any kind!

They also have to go through payment networks which are very often the limits on those things. So yeah, it sucks, but just fixing one DB isn't enough - the whole thing has to get upgraded.

> I have no idea who actually transfers money out of my accounts! There are no URLs, no metadata, nothing to actually confirm the identity of the other party. Every field in a transaction record is 100% attacker-controlled and unverified by my bank.

There is a little bit, but not much. Again, if these transfers are happening via card, it's all a terrible old fixed-length setup. Would be great if it was better, but you need Visa and Mastercard to upgrade as well. And of course there _is_ verification - most banks don't do a great job of surfacing this but they know if they've verified a PIN or CVC, or if it was contactless (in which case it _is_ unverified, but society realised we prefer the convenience there).

> Use cryptography. No, not crypto coins! I just mean a bog-standard algorithms like public-private key signing so that it is possible to confirm the source of transactions.

Obvious question then: You've made a card transaction. It is signed with the other party's private key. What does that buy you? How do you attach trust to this key? Whose is it - the payment gateway or the merchant?

> I would much rather have something generated with the assistance of a modern LLM than what we have now, which is security holes big enough to drive a panamax container ship through.

Sure, and if the LLM can rewrite enough of this system to get what you want, there's heaps of room for improvement. But this is orders of magnitude bigger in scope than rewriting your one old bit of COBOL software, it's systematic.

Sure, and then he can afford it, because he's making over $1M/year revenue on this sim, and taking a very reasonable 5% off the top of that. So it blunts the profits a bit at that point, but it hardly seems like such a terrible thing at that point.

Because you know that the current one works. If you have a bank running on COBOL (or whatever), you've had that for 30+ years now, so while it might have bugs, you know what they are. You don't know what the LLM output is. Hence back to my original point: writing the code is not the hard bit. Making yourself (and your CEO etc) comfortable to put that into production is one of the hard bits.