ff317

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.

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

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

I like this argument, but it does somewhat apply to software development as well! The only real difference is that the bulk of the "licensed work" the LLMs are consuming to learn to generate code happened to use some open source license that didn't specifically exclude use of the code as training data for an AI.

For some of the free-er licenses this might mostly be just a lack-of-attribution issue, but in the case of some stronger licenses like GPL/AGPL, I'd argue that training a commercial AI codegen tool (which is then used to generate commercial closed-source code) on licensed code is against the spirit of the license, even if it's not against the letter of the license (probably mostly because the license authors didn't predict this future we live in).

https://ziglang.org/ is a solid future C-replacement, IMHO. There's pretty much no downsides and all upsides from a C hacker's perspective. It just hasn't reached 1.0 yet!

The hole in the system, though, is fixed-rate loans over the long term, and the ability to refinance relatively-cheaply. If you buy a house when rates and inflation are low, then over the life of the loan you'll win on inflation. All you have to do is hang on to that low-interest loan. If you happen to buy when rates are high, then you refinance the next time they're low and hold that loan. It's the ability to (worst-case, "eventually") lock in a low rate for decades that lets you win from inflation in the long term. There are a lot of people that were holding onto real estate loans at ~2-4% throughout the pandemic monetary+housing inflation cycle that made out very well. They didn't have to predict it or time it, they just grabbed a low-rate loan some time back whenever they could, and then waited for the inevitable to eventually happen.

Inflation being a years-long painful problem to wrestle with was inevitable with all the stimulus pumped in to keep us afloat through the pandemic. We could have fared far worse, and many countries did. I don't know why the left didn't push on this argument harder to defend themselves.

The laws in question are ambiguously worded and untested-yet in courts. They promise severe financial penalties and prison terms for offenders. I don't blame a doctor for being scared.

Why were those "rentiers and parasites" ever involved? Why wasn't the NYT (or any other Thing) just created by the workers without their involvement? The answer in practice is that they provided value by providing the necessary capital to build the thing, and they did so in return for a cut of the future wealth earned by the thing. It's arguable that the wealth inequality that set the initial conditions for this is out of hand, but given the starting conditions, how else do you make big things?

I cook on cast iron multiple times a week. Have for years, using a very antique pan from a dead relative. My rules are fairly straightforward. I don't do any other maintenance or cleaning than this after-care routine:

* Let the pan cool (if I'm lazy or it's late, possibly this is overnight and then I do the rest in the morning).

* Scrape out any easy solid waste (burnt food bits, etc) with a wood spatula edge and throw the waste in the trash.

* Toss a healthy amount of salt into the pan and scrub the pan using the salt, with your hands/fingers. The salt is a great abrasive, like sand, but I don't want sand ground into my cookware, while salt is fine for food.

* Rinse out the dirty-salt-mess with plain water from the sink.

* Occasionally, if stuck-on things are particularly stubborn, repeat some of the above steps as necessary until the pan surface is smooth and clean.

* Wipe off most of the remaining wetness with a paper towel (the towel will probably look pretty dirty, that's ok).

* Throw the pan back on the cooktop, pour a few tbsp of cheap olive oil in the middle, and turn the burner on as high as it goes. Wait a few minutes for the oil to thin, spread, and smoke. Once it's smoking pretty well, shut off the fire and leave the pan to cool again.

* Later when it's cooled off again (possibly overnight or hours later, whatever), gently wipe off any excess liquid oil with a paper towel and store the pan back in the cabinet, ready for next use.

What if they live in a country in which genetic evidence of a disease can deny or significantly increase the cost of health coverage? Even if you're clear of those for now, a new marker may be discovered tomorrow. Apparently (according another commenter) Life Insurance /can/ legally look at this even in the US. What about employers? What if it puts them on the DNA-evidence hook for a "crime" in their jurisdiction which you and they don't think is an ethical law (evidence of homosexual activity in a country that imprisons for it, or worse).

That's kind of how I look at it, in practice. I get the mathematical reality that buying lotto tickets is a financial waste. However, if I never buy a single ticket, there is a definite 0% chance I'll ever win the big prize. Whereas if I play at all, at least there's a chance, however remote, of a quite life-changing positive event happening. So, therefore, it makes sense to put a very small amount of totally throw-away income into big-prize lotto tickets, just so you're in the game at all.

Based on this kind of thinking, my personal rules are: never spend more than 0.1% of take-home pay per time-period buying tickets, and only buy big-prize lotto tickets that have potentially-life-changing payouts.

But it does offer a reasonable hybrid solution: the software in the car doesn't have to solve all possible scenarios, it just has to be good enough to navigate the common, easy scenarios and should always be able to safely handle any situation for a short window of time, even if "handle" means "come to a quick safe stop within X seconds and turn on the hazards", all the while it's already starting the process of asking for remote assistance to take over whatever tricky situation, hopefully before the local code actually reaches the emergency-stopped case.

My favorite is American restaurant menus describing a "French Dip" as "with au jus sauce" :)

Yeah but it's not just "water", as in plain H2O. All water has different things dissolved or mixed into it. In pools there's commonly several chemicals added to that water: to correct the pH for humans, to sanitize, control corrosion of metal, avoid calcium deposits on other surfaces, etc. It's entirely possible that the additives in the water could be way off of normal and somehow affect things like viscosity or surface tension.

The problem is that software development is less like hiring an airline pilot or a structural engineer, and more like hiring an artist. Try making up a "standard exam" that will tell you whether an artist will produce several great unique works for you in the future, so you know which one to hire...

Over the long term of many years you're /lucky/ if a stable very-low-risk investment can net ~3% when accounting for inflation. Thus $250M could maybe net you roughly $7.5M/year. Exactly how many network links, servers, and engineering staff do you think that buys? It's way under what it operates on today, which is way under what it ideally should be for site like Wikipedia. And that's /just/ the operational engineering of the sites on a technical level.

You also need HR, you need Finance, you need a lot of Lawyers, you need software developers, you need a travel department, a fundraising team, PR people, community relations people, grant-making for the extended open ecosystem around the Wikimedia movement, conference planning, and the list goes on.

You're off by enough to seem troll-ish at best.

What about common spaces? Put the dwellings on the outer edges, and use the middle of each floor around the elevators as: gyms, libraries, swimming pools, saunas, indoor sports/games (pickleball? table tennis? air hockey? retro arcade machines?), meeting rooms and small-event spaces for residents? maybe a food court with 3rd party vendors? All kinds of creative things can be done!

There's two issues here still, IMHO:

1) The LLM owners really can't guarantee that it won't directly plagiarize without attribution or licensing. Your code may contain a unique algorithm or method for solving something, and when someone asks the right question, your code may simply be the only answer it knows to give.

2) While the code being used as training input was open source and visible to the public to learn from, the models being built often aren't. It seems unethical to train from public data yet keep the resulting weights private and charge for access to use the trained weights.

Yeah this is the angle I look at the most, the Humans+Internet combo.

I don't believe LLMs will really get us much of anywhere, Singularity-wise. They're just ridiculously inefficient in terms of compute (and thus power) needs to even do the basic pattern-prediction they do today. They're neat tools for human augmentation in some cases, but that's about all they contribute.

I think, even prior to the recent explosion of LLM stuff, that the aggregate of Humans and the depth of their interconnections on the Internet is already starting to form at least the beginnings of a sort of Singularity, without any AI-related topics needing to be introduced. The way memes (real memes, not silly jokes) spread around the Internet and shape thoughts across all the users, the way the users bounce ideas off each other and refine them, the way viral advocacy and information sharing works, etc. Basically the Singularity is just going to be the emergent group consciousness and capabilities of the collective Internet-connected set of Humans.

Maybe rather than focusing so much on how to detect AI-generated content, we should instead focus on our general ability to validate the truthiness of content regardless of source. I don't really care if an AI wrote it, so long as the content is meaningful and informative. I do care if it's a load of junk, even if a human did write it.

Personally (as someone who was high-school aged in the early 90s):

1. FidoNet BBSes were one early pre-Internet form ( https://en.wikipedia.org/wiki/FidoNet ). Even once the early Internet was up and running for some, some of us lived in countries/places where there was no access, and so the loosely-interconnected FidoNet BBS system was the first form of online group communications I was exposed to. There were even some gateways passing email and usenet newsgroups between FidoNet and the Internet towards the end. I had several local friends, we all ran FidoNet nodes, and we did use it for interpersonal communications at times.

2. Usenet - I used this a little bit in the mid-90s for true communication, but mostly that was highly technical in nature, e.g. IETF discussions on protocol development issues, etc. Also lots of using it to download binaries of course, but that's not really chat. I mostly didn't "know" the people I was interacting with, other than by online reputation.

3. IRC - From around 1994 onwards for me (when I finally had real access to the real Internet), on the EFNet IRC network (and a couple others, to a lesser degree). I spent many hours of every day lurking on EFNet's "#hack" channel and several others. There was a real sense of an online-first community, and then there were smaller and often private channels of people you knew from your real life (the other local hackers in your immediate community, or people you met at conferences, etc). I won't defend the culture as necessarily stellar, especially by today's standards, but at the same time, there was a sort of sense of community where it didn't seem to matter much who or what you were in real life, a sort of "if you're here, you're one of us" vibe. I think at least around 1994-1997-ish, IRC was pretty central to my social life (not all of it of course, but still!). Some of it was more anonymous in nature, but a lot of it was people I had met in real life or were even local friends of mine.