ff317

> Imagine if those F35 mounting pylons were used to drop field-portable water-purification systems directly where they are needed most.

Except we can (and do!) accomplish that with much simpler airplanes. The staggering costs and complexities of an F35 (the thrust:weight, maneuverability, and stealth) don't make sense for any "peaceful" application.

I think of the distinction here is about the domains we're coding within. If your software projects are product-y CRUD apps/sites... well, LLMs will tend to perform decently at that, because it's fundamentally pretty trivial work anyways, and there are so many examples to draw from. All CRUD apps are essentially isomorphic, with just some rules to plug in about data validation, business logic, etc. On the other hand, if your software projects involve more-difficult subject matter, you're going to find it struggles a lot more.

LLMs seem good at things you are not good at... primarily because you lack the skill to actually judge the goodness of their work, and they present their work confidently with an air of authority.

When I apply LLMs to domains where I'm already an expert, I find it particularly lacking when I want it to do deep, difficult, novel work that requires precision. On the surface, the output looks pretty amazing at first. But when I turn a critical eye to every detail, I end up finding a lot of flawed "thinking", and the lengthy process of fully understanding what it generated and cleaning it up to my standards makes me question the entire value proposition. However, I find it does a great job being a low-level automaton sort of assistant.

For instance, in the domain of software engineering: I would not trust it to implement a major architectural change, or a groundbreaking, complex new feature. I would trust it more (but not completely) on something like a refactoring that may touch thousands of lines in a fairly mechanistic way, but that was a little too-complicated for simpler tools likes regexes. While that's kind of a nifty use, I think it's fair to say that non-LLM software purpose-built for such tasks can probably do the same thing more effectively for less real cost (meaning the currently-subsidized real cost of all the training and inference power burn, etc)

It's not quite that simple though. A lot of these edge cases are necessary for everyone to live their cushy little city lives. It's not a matter of outmoded things. We will still need ambulances, and we will still need livestock trailers, and everything else on my list, for all of the foreseeable future. Unless batteries and charging gets a lot better, we'll still be manufacturing and improving ICE engines for many applications. Just not simple passenger cars.

From the content hosting side (getting reamed by scrapers overloading infrastructure), the problem is that we have to be able to set "reasonable" ratelimits to share finite network uplink and server cpu resources between all of our real users and these scrapers.

When you can identify the nature of the traffic (quickly in realtime, based on simple deterministic rules), you can protect the resources: you can rate/concurrency -limit the AI scrapers in the name of saving resources for the real humans, effectively putting the scrapers in a lower priority band (which is how it generally worked for search engine scrapers before!).

The problem is they're using resiproxies to disperse and whitewash their traffic, making it extremely difficult to tell their requests apart from the legitimate human requests. They're basically lying to us about the origin, and thus denying us the ability to put them in a lower priority band than humans.

They may scrape us at, say, 25K reqs/second, but it's coming from 50K random residential eyeball IPs at an average rate of only 0.5 reqs/second/IP, and then they're intentionally lying with the UA and headers and other fingerprint details as best they can to "blend in" with the humans so that we can't differentiate.

Let's do an analogy: Imagine if there was a neighborhood grocery store you and all your neighbors rely on for food. It's cheap because they keep their margins low, and more importantly the next store down the road is like 50 miles further away. That store 50 miles down the road also charges double the price. Now they've decided to play arbitrage: they load up 100 employees in the back of an air conditioned semi, clothe them to look like local shoppers, park it 3 blocks from your neighborhood store hidden inside a fenced property, and have them all go in and buy out all the inventory in the store over the course of a couple hours. The store just looks like it's having a great sales day at first. All these customers waiting in line, each getting just a few things at a time. But two hours later, the store shelves are empty, the semi is loaded up, and they're headed 50 miles back to double the price and sell it to someone else. You go in to buy some veggies to cook dinner and there's nothing to buy.

We've been playing this game with AI scrapers and resiproxies for way too long, and someone needs to hold them accountable for their fraud.

I agree with you, for the mass consumer car market (individual/family transport) as a whole. It's coming fast. However, the current EV technology (mostly batteries + charging) is not a good fit for a whole lot of edge cases, and in the aggregate they matter, too, and thus the ICE engine industry won't really go away anytime soon:

* General-purpose Semis for commercial hauling. Yes, there's some EV Semis on the road today - pilot projects, or specific routes on specific schedules. But there's a lot of general purpose semi-hauling that happens every day on odd/long routes without sufficient chargers in the right places, and they need much bigger chargers. And then there's the specialty semis that carry large/wide loads. I see them almost every day in my area, carrying large chunks of power substations, heavy manufacturing equipment, blades for wind turbines, etc.

* Fire trucks, Ambulances, Tow trucks, Police cars - For various similar reasons, it's tricky with some of these, although in well-constrained cases and with extra vehicles on tap as backup (when the other one is low on charge in an emergency), maybe can kinda work, eventually.

* "Personal" trucks that see heavy towing/hauling use (think: hauling a livestock trailer or farm equipment or heavy materials (or maybe an EV race car!), possibly long distances on a regular basis). The battery range really suffers when you put all the extra weight and drag on by towing, and people aren't willing to turn what was a 5 hour diesel trip into a 9 hour trip with supercharger stops (more time in the heat with animals, more time on the road in general, and do you have to disconnect the trailer just to reach the charge cable?)

* Backup generator ICE engines - home, datacenter, industrial use, etc. The problem here is mostly runtime and peak watts of output vs cost. You can use a battery-based solution for most of these cases, but it currently costs prohibitively more for the same performance specs. When they're being used in austere environments, sometimes there's no electric grid to even charge from, so slap on a massive solar array cost, too.

* All military use of ICE engines in general (transport, generators, etc) - Not insignificant in scope and scale, and obviously they're not going to run EVs or find chargers on battlefields.

These cases will diminish over time, especially as we continue to make advances in charging and especially battery technology, but it will probably take a few decades because there's science challenges, not just engineering ones. The military case might never go away.

Quite a bit indeed. Forbes ran an article a few months ago claiming that a family of four with two incomes needs to be earning a combined $400K to be able to reasonably afford the paid child care needed for both parents to be working.

> Many workloads don't need something like Galera [etc...]

This continues the faulty line of thinking that open source is just for hobby-level projects or early startup throwaway infrastructure. So many open-core models rely on this falsehood to rationalize their decisions. It should be possible to run large-scale important Internet things on Open Source code, too, for a variety of reasons.

I think this also speaks to the heart of the non-political spectrum between "conservative" and "progressive" societal evolution. It's progressive to enact these kinds of changes in the name of supposed convenience, efficiency, and modernity (whatever that means), and to do it quickly without sufficient thought as to all the unintended consequences. It's conservative to fear such changes and try to slow them down for the same reasons. Rapid societal changes are always risky, even if we suspect they may be net positives.

When we want to maintain a reliable, stable "product" in traditional software development (a binary executable artifact that ships out to users, or the binary engine of some SaaS the company sells to users), we don't just check in (to the source of truth repo) the actual application-layer source code. We also check in build instructions (think autoconf/cmake/etc) and have some concept of compiler compatibilities / versions, build environments, and papering over their runtime differences. And then our official executable output is not just defined by "Tag v1.23.45 of the application source code repo" - it's additionally defined by the build environment (including, critically, the compiler version, among many others).

It's tempting to move out a layer and try making prompts and plan.md the "source code", and then the generated actual-source-code becomes just another ephemeral form of "intermediate representation" in the toolchain while building the final executable product. But then how are you versioning the toolchain and maintaining any reasonable sense of "stability" (in terms of features/bugs/etc) in the final output?

Example: last week, someone ran our "LLM inputs" source code through AgentCo SuperModel-7-39b, and produced a product output that users loved and it seemed to work well. Next week, management asks for a new feature. The "developer" adds the new feature to the prompting with a few trial iterations, but the resulting new product now has 339 new subtle bugs in areas that were working fine in last week's build owing the fact that, in the meantime, AgentCo has tweaked some weights in SuperModel-7-39b under the hood because of some concern about CSAM results or whatever and this had subtle unrelated effects. Or better yet: next month, management has learned that OtherCo MegaModel-42.7c seems to be the new hotness and tells everyone to switch models. Re-building from our "source" with the new model fixes 72 known bugs filed by users, fixes another 337 bugs nobody had even noticed yet, and causes 111 new bugs to be created that are yet-unknown.

If you treat the output source code as a write-only messy artifact, and you don't have stable, repeatable models, and don't treat model updates/changes as carefully as switching compiler vendors and build environments, this kind of methodology can only lead to chaos.

And don't even get me started on the parallel excuses of "Your specifications should be more-perfect" (perfection is impossible), or "An expansive testsuite should catch and correct all new bugs" (also impossible. testing is only as good as the imperfect specification, and then layers in its own finite capabilities to boot).

Random related data point: for HTTP requests to Wikipedia (and related) for the past 7d, the IP protocol split is roughly 35% IPv6 / 65% IPv4. (this is counting by-request, so heavy usage from a small number of IPv4s can skew it).

The reason speed limits make such a great example for these arguments is because they're a preemptive law. Technically, nobody is directly harmed by speeding. We outlaw speeding on the belief that it statistically leads to and/or is correlated with other harms. Contrast this to a law against assault or theft: in those kinds of cases, the law makes the direct harm itself illegal.

Increasing the precision of enforcement makes a lot more sense for direct-harm laws. You won't find anyone seriously arguing that full 100% enforcement of murder laws is a bad idea. It's the preemptive laws, which were often lazily enforced, especially when no real harm resulted from the action, where this all gets complicated. Maybe this is the distinction to focus on.

It might be interesting for "opportunistic" DoTLS towards authdns servers, which might listen on the DoTLS port with a cert containing a SAN that matches the public IP of the authdns server. (You can do this now with authdns server hostnames, but there could be many varied names for one public authdns IP, and this kinda ties things together more-clearly and directly).