being able to replicate it in the open means that there's nothing special about frontier models.

Frontier models would have to do something extraordinary or unique, or unreplicatable, because clearly there is no moat, and US companies are sitting on huge nvidia valuations and get surprised when competitors beat them.

there already is an app for that. https://f-droid.org/packages/net.oblivion.wipe/

this reminds me of some programmers' blog where he talked about the line between when software does something helpful automatically for a user, vs the line of where it nags you to make decisions it could have made itself.

it's definitely a cool esoteric thing :) I bet some other features would make it gain traction.

codeberg's one job gets interfered with by freeloaders hammering expensive views (like git blame) inconsiderately.

You’re so right. I have a public-facing Forgejo server. Before configuring Anubis, scrapers were sending it about 600K requests per day. Copying and pasting from my blog post about it:

* For every Git commit, fetch the version of every file in the repository at that commit.

* See git blame for every file at every commit.

* Attempt to download the archive of each repo at every commit.

* Run every possible pull request search filter combination.

* Run every possible issue search filter combination.

* Fetch each of those URLs at random from some residential IP in Brazil that had not ever accessed my server before.

Afterward, it dropped to several hundred. Expect anti-attack features to keep getting stranger and more visible as scraper get still more aggressive.

This matches my experience of running a public mediawiki server. The bots (mostly Facebook/Meta) will for every single change fetch every single page again, over and over.

I can’t tell if it’s incompetence or malice.

What do you use to monitor this? I don't really keep a close enough eye on my services to know what the traffic is doing (and haven't had any issues) but maybe I should start

I just tailed the web logs for a bit and saw that it was wild. For fun, I fed 10 minutes of logs into an AI and it picked up a lot of signal I didn't catch at first glance, like clients claiming to be MSIE 7 on Android 3 and such. I added some reject rules to the webserver in front of Forgejo but that only made a dent in the traffic, alas.

That's crazy. So 600,000 someones are absolutely starved for data.

Or one someone with too much money and too little sense misplaced a decimal point in their ScraPy setup?

I think it was the latter.

And the cruel irony is that these are FOSS Git repos I'm publicly sharing. I'd've been fine with them cloning the repo and analyzing away to their heart's content. That's not the way their scraper's wired, though.

Couldn't they just rate limit them? Are they literally using a new IP for every request?

There are indeed scrapers which use tens of thousands of distinct IPs, and so rate limiting them isn't a solution.

We used to call this snow shoeing.

In my experience, yes. At the peak of a scraper flood I was dealing with, I'd say about 90% of the traffic was from a unique IP. I'd never seen anything quite like that before.

Disney and Nintendo's very litigious and successful lawyers have entered the chat

>> I think its time that we stop extracting rent from outdated copyright laws.

Do you really think either of these companies or their lawyers would say something like this?

IIRC tailscale is directly P2P, sidestepping a large part of the infra costs...

And, as far as I'm aware, they don't charge for relay bandwidth even if you do end up needing it (which most users won't).

so - sometimes systemd's build is reliable, sometimes it causes problems. Are these good additions and do they solve real problems, or are they just for cohesion of systemd itself or introduce problems?

I think he doesn't need to understand the technology to point out the books are cooked. a business can sink in either way: the technology flops or the finances flop. he's arguing the /finances/ would flop. he doesn't argue that the /technology/ would flop, only that they can't come up with the money to pay their debters.

There is a piece of this I agree with. That you do not need to be a deep technical expert to notice that a company is burning cash by overcommitting to capex, or relying on heroic revenue projections that may or may not come to pass.

But that is not the full argument he is making. If the claim is that the labs will not be able to pay their creditors because inference is structurally incapable of becoming profitable, then he absolutely needs to be right about the technical economics of inference.

One part of that is the balance-sheet argument (which already shows insanely good margins). But it also depends on how inference-time compute actually works: routing, batching, kv cache reuse, model segmentation, different latency tiers, etc. Much of those details he's just been straight up wrong about in his writing, so as a result I have to call into question the rest of his reasoning as well (in part to avoid Gell-Mann amnesia).

Doesn't this kinda imply its own smoke and mirrors though? Like if the name of the game with inference is already routing things around and caching so you can make money, why is the newest biggest model always the most important critical thing? How does this square with any of their press about it? Also wouldn't that just add more inference? Because you need to pre-judge every prompt to know where to route it?

Also, if there is significant gains from caching, then like.. what are even doing here? Inputting something and then reading cached pieces of text based on their similarity to the input? Kinda like a search engine?

I don't think its smoke and mirrors, though I do have plenty of gripes with how the labs market this product landscape generally speaking.

The newest biggest model can still matter even if you do not run every prompt through it. You'll always have some task where even small amounts of loss are unacceptable and thus you need to make sure frontier intelligence is used for it.

On the router point, yes, routing has some overhead. But the router does not need to run the biggest model to decide which model to use. We've been using tiny classifiers for recommendation engines for ages now, usually on CPU. If routing saves you from sending a large fraction of traffic to the expensive reasoning model, the routing overhead can easily be worth it.

> Also, if there is significant gains from caching, then like.. what are even doing here? Inputting something and then reading cached pieces of text based on their similarity to the input? Kinda like a search engine?

The caching I'm talking about is explicitly the attention/kv cache, so its not input similarity retrieval (that would be more like what you'd use in a RAG/IR system). Prompt caching is generally about reusing already-computed attention scores for repeated prompt prefixes. The idea being you don't recompute the same static system prompt, tool definitions, schemas, long shared context, or repeated boilerplate every time. In more sophisticated systems, you usually store multiple checkpoints so that a small prompt change doesn't result in all-or-nothing hit/miss scenario.

I think the earlier commenter is right. If a parent fails to... well... "parent" that's on them. Locking down the internet to republican-approved sites only is not the answer.