The point is that they want the simple UX of "ssh vm1.box1.tld" takes you to the same machine that browsing to vm1.box1.tld takes you to, without requiring their users to set any additional configuration.

You can have that already? It's just dns. Are you saying different vms share the same box1 ip? Well then yeah, you want a reverse proxy on some shared ip.

> Well then yeah, you want a reverse proxy on some shared ip.

At that point you run into the problem that SSH doesn't have a host header and write this blog post.

Yeah, ftp has the same issue depending on implementation.

Most host/port services have the same issue, even https used to have it and it's the reason SNI was introduced. But if by implementation you mean sftp, then of course - it uses Ssh

> the code is taken from the LLM with no preexisting license

That's not good enough to comply with (b). The code must be specifically covered by an open-source license, it's not enough for it to just not have a license.

There's a difference between "no license, all rights reserved" and "no license, public domain". Up until recently, you could assume that not having a license meant the former. But treating the latter as the same would just be silly.

As far as I'm concerned, public domain counts as "an appropriate open source license".

> As far as I'm concerned, public domain counts as "an appropriate open source license".

For material whose author is known and has explicitly placed it in the public domain, sure. For code that fell off the back of a truck, not so much.

> Not allowing AI assistance on PRs will likely decimate the project in the future, as it will not allow fast iteration speeds compared to other alternatives.

If and when there is evidence that AI is actually increasing the speed of improvement (and not just churn), it would make sense to permit it. Unless and until such evidence emerges, the risks greatly outweigh the benefits, at least for a foundational codebase like this.

> Why do you care how much effort it took the engineer to make it?

Because they're implicitly asking me to put in effort as a reviewer. Pretending that they put more effort in than they have is extremely rude, and intentionally or not, generating a large volume of code amounts to misleading your potential reviewers.

> If there was a huge amount of tedium that they used Claude Code for, then reviewed and cleaned up so that it’s indistinguishable from whatever you’d expect from a human; what’s it to you?

They never do though. These kind of imaginary good AI-based workflows are a "real communism has never been tried" thing.

> If your project is gaining useful functionality, that seems like a win.

Lines of code impose a maintenance cost, and that goes triple when the code quality is low (as is always the case for actually existing AI-generated code). The cost is probably higher than the benefit.

Yes and no. Previously when someone submitted a 14k line PR you could be assured that they'd at least put a significant amount of time and effort into it, and the result was usually a certain floor on the quality level. Now that's no longer true.

> If the PR does what it says it does, why does it actually matter if it took 2 weeks or 2 minutes to put together, given that it's the equivalent level of quality on review?

You're right that the issue isn't how many minutes it took. The issue is that it's slop. Reviewing thousands of lines of crappy code is unpleasant whether they were autogenerated or painstakingly handcrafted. (Of course, few humans have the patience and resistance to learning to generate the amount of terrible code that AIs do routinely).

If it's particulates from tires then heavier EVs are probably making that worse not better (partially offset by regenerative braking, but only partially).

EVs produce more tire dust, but much less brake dust and exhaust (even when powered by coal plants).

The net effect is a massive reduction in dust and particulates.

Some modern tire additives are incredibly toxic to fish. They’ve been banned in the EU, but for the very special corner case of driving in sensitive watersheds in the US, it’s possible EVs are worse on that one dimension.

Of course, we could just ban the recently approved additive, and completely solve that corner case problem.

If it's silly and it works, it's not silly.

Criticising our entire economic system tends to have very little effect. Criticising specific poor business practices and/or technologies that enable them has a much better chance of improving people's lives.

> Criticising our entire economic system tends to have very little effect.

I think its actively counterproductive. Criticising the entire economic system doesn't do anything. Complaining in broad strokes about stuff you can't change reduces your sense of agency over the world.

Also, if people believe that businesses must be sociopathic, they will make sociopathic choices in business. The belief reinforces the problem.

It's not that they must be, rather that they are incentivized to be. If you dangle money in front of them what were you expecting?

Sometimes, yes. E.g. if the value types stuff ever gets implemented, that will be very useful for other JVM languages. OTOH some changes are purely syntax sugar in Java itself (e.g. allowing multiline string literals) and those of course don't affect any other JVM language.

Some people did but that's actually worse. Your configuration comes magically out of nowhere and when it breaks you can't fix it.

Nobody ever wanted to wire up RPC endpoints, in the form of Enterprise JavaBeans(tm), using XML files. That is one for the history books of ridiculous technology.