It's also worth adding that I really enjoy the AskUserQuestion feature and will regularly ask Claude to specifically use it instead of asking me questions in plain text because it's a lot easier to work with.

It's always good to learn from mistakes, and I appreciate both your work on this and you coming here to own it. Keep up the good work!

These two types of contributions have very different behavioral profiles, and it doesn't obviously follow that the historical success of getting people to collaborate socially on building software for fun and for the benefit of the community will translate in any meaningful way to the necessity of being able to raise enormous amounts of money to pay for enormous amounts of electricity.

The answer is no. What is true is that some Roman concrete structures (but far from all of them) are extremely durable because they were optimized for a different set of requirements than modern buildings usually have, notably "needs to last forever as a symbol of the emperor's power". From the 19th century on that has very rarely been a design constraint, so we optimize for other things instead.

In which case you spent a bunch more than you needed to on a building that didn't last any longer than it would have if you'd chosen a practical end date for it.

> The miracle of modern chemistry has given us a wide variety of admixtures like superplasticizers to improve the characteristics of concrete beyond a Roman engineer’s wildest dreams. So why does it seem that our concrete doesn’t last nearly as long as it should? It’s a complicated question, but one answer is economics. There’s a famous quote that says “Anyone can design a bridge that stands. It takes an engineer to build one that barely stands.” Just like the sculptors job is to chip away all the parts of the marble that don’t look like the subject, a structural engineer’s job is to take away all the extraneous parts of a structure that aren’t necessary to meet the design requirements. And lifespan is just one of the many criteria engineers must consider when designing concrete structures. Most infrastructure is paid for by taxes, and the cost of building to Roman standards is rarely impossible, but often beyond what the public would consider reasonable.

https://practical.engineering/blog/2019/3/9/was-roman-concre...

A large part of why Roman concrete lasted longer than ours tends to is that we suffer from a shortage of narcissistic emperors with the means to wield entire economies towards their own immortality.

Second: My argument doesn't hinge on Anthropic not being able to weasel their way out in court if it came to that. My argument is that neither Anthropic nor OpenAI are going to break their signed contracts or even fudge on the clearly communicated understandings of what the terms of the API pricing are because neither one wants to hand the other the obvious weapon of: "unlike {other guys} we honor our word".

It's just not happening, and comparisons upthread to the fair use story totally misunderstand the incentives at play here.

(And as an aside, this whole thread also shows clearly the classic programmer misunderstanding of the law. The peanut butter sandwich instructions analogy is for code, not for the law. The law doesn't actually work by allowing any possible interpretation to hold equal weight the way that many programmers think it does.)

* A company following suit with their entire industry in choosing a very generous definition of fair use.

* A company being the first to defect and actually break their signed contracts with enormous enterprises committing to not train on those enterprises' most valuable assets.

Training on copyrighted works signs them up to be a part of a system that is at this point too big to fail and places them in good company with all of their competition. Breaking their signed agreements would open them up to very well-founded and well-funded lawsuits for contract violation and give their competition a huge boost.

All of a sudden "we actually don't break our contracts" would be a selling point. No company in their right mind is going to let what should be table stakes become a differentiator for their competition.

* Exploiting ambiguity around fair use at a large scale before the law catches up and then jointly lobbying with your competition to make sure your interpretation of the law becomes reality.

* Explicitly signing a contract with enterprises to respect their IP and then proceeding to break that contract with your own customers.

The former is firmly in the gray area of legality and doesn't directly hurt your own customers. The latter is both an unambiguous contract violation and a flagrant attack on your own customers' most valuable asset.

But also, the difference is that Steam has as far as I can tell never yanked a game from someone's account and failed to refund them for it. Games either get delisted and you retain access to them or they're removed entirely and they refund you. The only exception is online-only games whose developer stops maintaining the server, but I think it's reasonable for steam to not claim responsibility for the developer's malfeasance.

So Steam has this model of licensing-not-ownership on paper but in practice treats purchases as much closer to ownership. Sony clearly does not.

1. There are lots of things that compilers load into their memory that aren't actually source code. A memory exploit turns non-source data into executing-in-the-compiler code.

2. Depending on the language semantics, a memory exploit can allow substantially higher privilege than just being loaded as library code. Latent malicious code that never gets called into never becomes active, but if you can exploit a weakness in the compiler you can make your code execute at any time you'd like instead of relying on the main application calling in to your malicious library.

The actual split is on which environments the dependency exists in and who can control inputs in those environments. For most private companies who aren't running CI on an open source repo, the dev/prod split is the operative one that determines what you can safely ignore.

Physical disc production ending in Jan 2028 for new games on PlayStation (797 comments) https://news.ycombinator.com/item?id=48745456

So Sony is simultaneously announcing that all purchases will be digital from now on while actively demonstrating that digital purchases aren't actually purchases. They're clearly communicating that they believe in a future where no one owns games any more.

The compiler is one of the most significant trust boundaries we have. Its decisions can intentionally or unintentionally create vulnerabilities in programs compiled by the compiler, which means that if you can compromise a compiler you can compromise everything downstream.

Unsafe memory access in a compiler can be exploited in order to hijack the compiler itself (this is reported regularly in production compilers), allowing the attacker to then insert arbitrary code into compiled binaries. Not everything that a compiler absorbs from its environment is meant to be treated as source to be compiled, and in a memory unsafe compiler any of that input can silently turn into machine code in the compiled binary if an attacker is able to exploit the memory safety bug and hijack the compiler.

> Zig has more features than Rust for making memory-unsafe code work correctly, and that was the area where we wanted the most help.

Zig definitely does not have more features for successfully emitting memory-unsafe machine code than Rust does. I can emit memory-unsafe machine code from typescript if I really want to and nothing at all in the language will get in my way. So the sentence quoted above must refer to the idea that the compiler itself needs to be unsafe, which Steve is right is simply untrue.

But notice that what you're now arguing is not that Bluesky is equally decentralized to Mastodon as a social network, you are arguing that while Bluesky the app may be in practice highly centralized that doesn't mean other apps can't exist:

> The "Bluesky index" is the index of Bluesky posts, so naturally you access that primarily through the Bluesky app.

It probably is entirely true that different apps can spin up on atproto independently, but that was never the actual point of concern. This, what you say right here, is the actual concern. This specific app (or any atproto app) appears to have significant lock-in—to the point where you identify it as "natural" that it would be so—while selling itself on decentralization.

Blacksky is an interesting case, and I'm wondering why you didn't roll it out at the beginning and why you still hedge it as "natural" that you'd access the Bluesky app data through Bluesky? I'm actually unfamiliar with the territory here, but coming from my knowledge of the fediverse that seems an odd pairing. If a fully independent implementation exists, why is it natural that you'd use the central one?

But in the 2020s, after watching what Google did to the web without being able to control the protocol from the beginning, a comparison of Bluesky to Google doesn't really assuage the concern people have about centralization.

Is this an actual shift, or is this just what happens when LLMs make it possible for anyone to build a language quickly?

This one feels less like someone thought carefully about what semantics they wanted to have and more like someone without a lot of familiarity with the design space of programming languages decided to build one that had all their favorite features from the languages that they already know:

> G# brings Go-, Kotlin-, and Swift-style ergonomics — packages, func, data class, nullable handling with if let, structured concurrency with scope — to the .NET runtime.

Nothing wrong with that at all, I love to see the increased interest in language design, but I wouldn't read a shift in preferences into this wave of PLs. It's a shift in who is writing PLs, not a shift in preferences.