ff317 · HackerTrans

18 dagen geledendiscuss

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.

ff317

18 dagen geledendiscuss

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.

ff317

18 dagen geledendiscuss

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.

ff317

19 dagen geledendiscuss

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.

ff317

23 dagen geledendiscuss

> 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.

ff317

2 maanden geledendiscuss

> Computer interfaces had no superfluous subservient text for their entire history prior to LLMs

Clippy would like to help you correct this statement.

https://en.wikipedia.org/wiki/Office_Assistant

ff317

2 maanden geledendiscuss

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.

ff317

2 maanden geledendiscuss

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).

ff317

3 maanden geledendiscuss

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).

ff317

4 maanden geledendiscuss

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.

ff317

7 jaar geledendiscuss

Just for another voice in this sub-discussion: I'm an authdns software implementer ( https://github.com/gdnsd/gdnsd ) with no connection to Cloudflare, and I like Refuse ANY. It's maybe hard to see all the issues with traditional ANY clearly unless you're implementing this stuff, but IMHO RFC 8482 is a really good path forward that I'm supportive of and have also implemented.

comments