algernon

I'm very late to the party, but: no, iocaine does not expect you to detect the bots. It used to, but it does its own detection for quite a while now (you can replace the detection mechanism, though).

Hungarian: "A nap végén kérlek pakoljátok egymásra a székeket." (Rough translation back to English: "At the end of the day, I ask you (informal) to stack the chairs on top of each other").

Same thing, but more formal: "A nap végén kérjük pakolják egymásra a székeket." (~English: "At the end of the day, we ask you (formatl) to stack the chairs on top of each other").

In an even more formal / authoritative way: "A nap végén kéretik a székeket egymásra pakolni." (back to English: "At the end of the day, chairs shall be stacked on top of each other")

Same here. We have a joint account, I'm the sole earner, apart from mortgage and utilities and whatnot, she's spending all of it, and that's great, because she does it much better than I could. I suck at managing money, she does not. I wish I could give her more money.

Most often, yes. But there are exceptions. A lot of Ubuntu developers were on Debian in the early days for example. I imagine some still are - there's a bit of overlap between Debian & Ubuntu developers here and there.

I maintained packages in various BSDs pkgsrc/ports tree, even though I never daily drove any of them, and had them in a virtual machine at best.

I... have my doubts. I do not doubt that a wider variety of poisoned data can improve training, by implementing new ways to filter out unusable training data. In itself, this would, indeed, improve the model.

But in many cases, the point of poisoning is not to poison the data, but to deny the crawlers access to the real work (and provide an opportunity to poison their URL queue, which is something I can demonstrate as working). If poison is served instead of the real content, that will hurt the model, because even if it filters out the junk, it will have access to less new data to train on.

Yup. All of the things listed there are far better than this.

(I'm also in that article, look for "iocaine", although it evolved into something a whole lot more powerful, and a lot easier to deploy since the article was written).

Your exception is for http://ha/, you're visiting http://ha:8123/. Ports matter. It probably worked yesterday because you either visited without a port, or clicked the "Continue to HTTP site" button, and LibreWolf remembered that for the rest of the session.

I had a short tootstorm about this, because oh my god, this is some terribly ineffective, useless piece of nothing.

For one, Poison Fountain tells us to join the war effort and cache responses. Okay...

❯ curl -i https://rnsaffn.com/poison2/ --compressed -s
HTTP/2 200
content-disposition: inline
content-encoding: gzip
content-type: text/plain; charset=utf-8
x-content-type-options: nosniff
content-length: 959
date: Sun, 11 Jan 2026 21:17:36 GMT

Yeaah... how am I supposed to cache this? Do I cache one response and then continue serving that for the 50+ million crawlers that visit my sites every day? And you think a single, repetitive thing will poison anything at all? Really?

Then, the Poison Fountain explanation goes on to explain that serving garbage to the crawlers will end up in the training data. I'm fairly sure the person who set this up never worked with model training, because this is not what happens. Not even the AI companies are that clueless, they do not train on anything and everything, they do filter it down.

And what this fountain provides, is trivial to filter.

It's also mighty hard to set up! It's not just a reverse_proxy https://rnsaffn.com/posion2, because then you leak all the headers you got. No, you have to make a sanitized request that doesn't leak data. Good luck!

Meanwhile, there are a gazillion of self-hostable garbage generators and tarpits that you can literally shove in a docker container and reverse proxy tarpit URLs to them, safely, locally. Much more efficient, far more effective. And, seeing as this is practically uncacheable, if I were to use it, I'd have to send all the shit that hits my servers, their way. As far as I can tell, this is a single Linode server. It probably wouldn't crumble under my 50 million requests / day, but if ten more people would join the "war effort" without caching, my well educated guess is that it would fall over and die.

Besides, we have no idea whether poisoning works. We can't measure that. What we can measure, is the load on our servers, and this helps fuck all in that regard. The bots will still come, they'll still hit everything, and I'd have additional load due to the network traffic between my server and theirs (remember: the returned response provides no sane indicators that'd allow caching while keeping the responses useful for poisoning purposes).

Not only is this ineffective in poisoning, it's not usable at all in its current state. And they call for joining the war effort. C'mon.

It's complex, because it does a lot of things, and it evolved over the past few years. The basics are very, very simple:

#+begin_src nix :tangle out/flake.nix :noweb no-export :noweb-prefix no :mkdirp t
{
  inputs = {
    <<flake-inputs>>
  };

  outputs = { self, nixpkgs, ... }@inputs: {
    <<flake-outputs>>
  };
}
#+end_src

In some other file, you can then do:

#+begin_src nix :noweb-ref flake-inputs
nixpkgs.url = "github:NixOS/nixpkgs/nixos-25.11";
#+end_src

And voila, you now have:

{
  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-25.11";
  };

  // ...rest of the flake
}

How you organize your org documents, is entirely up to you. The trick is that this lets you split it up as you see fit, and you are no longer restricted by what the language or any framework built on top of it can provide.

Here's one for my infra, and my first attempt, for my desktop. The latter will eventually merge into the former.

The way I solved this problem is that I write my flake.nix in a literate-programming style using Org Roam. I have a code block that tangles out into out/flake.nix, which has a <<flake-inputs>> placeholder. I can have any number of code blocks, in any number of Org files that all reference flake-inputs. Thus, my inputs are near other code (& documentation) that uses them, split across dozens of files.

The downside is that you no longer write Nix directly, but have to tangle it out.

A new chapter, for sure. A very sad chapter, unfortunately.