bloppe

People seem to be throwing around the term "break out" pretty loosely. I wouldn't consider abiding by the rules of the sandbox a "break out".

I think a better simplistic analogy would be that humans are progeny-maximizers. Optimization problems can give rise to all sorts of interesting behaviors but the simplistic perspective is also useful and interesting in both cases

Are cigarettes banned?

Companies that ignore everything besides their legacy cash cow tend to go downhill. I'm sure there are at least a few people at Apple who's main concern is marketing the Mac mini, and those people are highly definitely trying to cook up new marketing strategies all the time

True, but also small town life sure isn't for everyone. Megacities exist because a lot of people actually like living in them.

I feel like you can have both. A big society with industry and laws and markets etc. and a circle of like 10-50 people that you consider close. That's basically how I see my own life.

This is only one aspect of "performance". glibc's allocator may be faster, but it also uses more memory.

For a much more technical discussion, see https://github.com/sharkdp/fd/issues/710

Democrats tend to pass more legislation

MIT makes all its money from research (and investing its endowment more successfully than most schools), not tuition, and the success in research comes from having such a high-achieving community of faculty and graduate students. They're pretty incentivized to keep the bar for academic achievement genuinely high.

Ask any solo founder and they will have a very different story

https://www.economist.com/business/2026/07/27/america-has-be...

More nix content

As an American with Canadian family, I salute Carney's handling of this situation

Spoken like someone who's never been to Alberta

This is the kind of thing where everyone just talks past each other because "coding" can refer to a ton of different things. I think we've all had the experience of having to write large mechanical boilerplate or refractors which was definitely highly automatable coding. I think we've also all has the experience of being utterly dismayed at how hard it is to write certain logic, especially with LLM "assistance". I've spent the last couple days marveling at how consistently fable introduces race conditions into a complex state machine I'm maintaining. Coding can be hard, or easy sometimes

In my own CLAUDE.md files, I tell it to liberally use the `gh` CLI to search for issues and error messages across the entire GitHub code index. It's insanely effective, but it feels like I'm part of the problem, and I'm sure there are a lot of other people doing the same.

Ya they're getting boned

Letting the harness inject the credentials implies not exposing them to the LLM.

Besides, the current state of MCP authentication almost always involves just hard coding secrets in .claude/settings.json so it's not like that's doing a great job keeping the creds away from the LLM anyway. All I'm saying is that MCP auth offers no advantage.

The one introduced by Gregory. I'm not sure if countries that reformed later cared enough to use a different name, but the Gregorian calendar is pretty well defined.

I guarantee you any LLM will be perfectly capable of navigating HTTP auth [1] which has been around since 1999.

You could use `curl`, or you could bake an HTTP client tool into the agent harness which operates at a more abstract level. The agent would just have a tool that looks a lot like the Fetch API [2] and the harness could simply be configured to inject credentials using the various well-established patterns that have long existed, allow / deny certain methods, etc. The thing is, everything you can do with MCP could also simply be done with REST, so neither is inherently better than the other, I just don't like the proliferation of needless standards.

[1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Aut...

[2]: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U...

The read-only QUERY method can send much bigger requests than GET.

For delayed answers, MCP offers no improvement, because remote MCP servers use an HTTP transport anyway, and local ones don't involve middleware you can't control. Besides, that's well-trodden ground. SSE, trailers, gRPC streaming, websockets, simple polling, etc. We don't need another protocol.

Yep. There's already a well-established system of `.well-known` URL paths to support things like API spec discover, auth discovery, etc. Why re-invent those wheels?

When I say REST, I basically mean HTTP/JSON. I know. Shame on me.

But there's a pretty large body of RFCs that define what makes a good REST API. For instance POST should create things, PUT should re-define them, PATCH should incrementally update them, GET must be side-effect-free, etc. And there's a ton of standard HTTP headers. Pair it with OpenAPI and the whole thing is self-documenting. You can achieve the same effect with gRPC + reflection, or GraphQL + reflection, and there's plenty of mature tooling and interoperability for each system.

By comparison, MCP actually has relatively few conventions. LLMs are very familiar with REST and OpenAPI already. Just use that.

See my point #2. There are already standards to describe APIs.

This is easy to see when you think in terms of a developer. The natural way to adapt an existing REST API into an MCP server while keeping the two synchronized is to simply write a basic translation tool that takes your OpenAPI spec and turns it into an MCP manifest, mapping each HTTP endpoint to an MCP method, and copying over all the request / response type signatures and descriptions for everything. Then, all of the sudden, it hits you: there is no need for this translation layer.

Are you trying to say that REST APIs don't have a strict wire format with shared semantics for a huge range of features?

MCP is basically just:

1. a REST-like API

2. with a spec (OpenAPI, introspection, etc.)

3. with harness-level authz (the ability to allow / deny specific methods in the harness)

The only part that's actually new is #3, but it seems like it should be fairly easy to provide similar support for REST APIs. There might already be a Pi extension that allows you to allow / deny particular method / path patterns for particular sites. Regardless, there's always service-level authz with service accounts, at least for the more sophisticated APIs.

So ya, I don't see why we need a whole new set of standards and protocols just to have harness-level fine-grained API permissions. We could have just done it all with REST.

It's kinda hard to have a truly informed conversation about the scam industry since it's so secretive, but many of the scammers in Myanmar are actually incredibly big businesses that basically enslave people who otherwise wouldn't scam anybody. In those cases, the people who are actually making the choices are incredibly wealthy.

"normal applications", no. But there are more platforms besides databases, e.g. programming languages. Any platform that works with dates will have to deal with these weird quirks. And application that works with dates probably would not, although there's always leap seconds...

> Those 10 days certainly exist, in both calendar systems.

Not in the standard Gregorian calendar. Those dates only exist in the proleptic Gregorian calendar. The standard Gregorian calendar explicitly skips them. That's because you can't feasibly go back and change all the Julian dates that had been physically written down for centuries. That's why it's called the Gregorian "shift".

Most applications don't have to worry about it, but platforms do. The SQL standard requires accurate date representation for years 0000-9999. I was surprised to learn about the Gregorian shift while testing our database system. I also learned about "war time" in WW2 and the "battle of the clocks" in colonial India. A lot of history came out of debugging those tests.

Considering it only diverges from the standard Gregorian for dates more than 400 years ago, it's not super relevant. Most people don't think about it. But it made a lot of sense to do the shift at the time. All recorded dates up to that point had been physically written down, so it would have been infeasible to migrate those all to the proleptic. If computers had been around, maybe things would have been different.

Fun fact: Greece was still using the old Julian calendar as of 1928, so it's entirely possible that you'll see dates on relatively recent Greek documents that are up to 14 days off from the calendar the rest of the world was using. Civil timekeeping is just a mess.