It was the night of December 24th, 1996. I turned on the family PC, then running Win95, and found my D:\ drive corrupted. Windows had no tools nor docs how to resurrect a corrupted filesystem. I cried, and two days later installed SuSE on a spare disk.

Some 20 years later, I restored about half of the disk lost in 1996, because Linux had the tools, and the docs, and encouraged me to learn.

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.

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.

While I am not a fan of Nix the language, it is no more insane than ansible or kubernetes yaml soups.

As for packages… nixpkgs is by far the largest repo of packaged software. There are very few things I haven’t found there - and they are usually not in any other distro either.

I switched to NixOS because I wanted a declarative system that isnt’t yaml soup bolted onto a genetic distro.

By 2022, my desktop system was an unmanagable mess. It was a direct descendant of the Debian I installed in 1997. Migrated piece by piece, even switched architectures (multiple times! I386->ppc-i386->amd64), but its roots remained firmly in 1997. It was an unsalvagable mess.

My server, although much younger, also showed signs of accumulating junk, even though it was ansible-managed.

I tried documenting my systems, but it was a pain to maintain. With NixOS, due to it being declarative, I was able to write my configuration in a literate programming style. That helps immensely in keeping my system sane. It also makes debugging easy.

On top of that, with stuff like Impermanence, my backups are super simple: btrfs snapshot of /persist, exclude a few things, ship it to backup. Done. And my systems always have a freshly installed feel! Because they are! Every boot, they’re pretty much rebuilt from the booted config + persisted data.

In short, declarative NixOS + literate style config gave me superpowers.

Oh, and nixos’s packaging story is much more convenient than Debian’s (and I say that as an ex-DD, who used to be intimately familiar with debian packaging).

SuSE in 1996. Then Debian between mid-1997 and late 2023, NixOS since.

I’m not a big distrohopper…

I do, yes. I’d love to use it, because I like Scheme a whole lot more than Nix (I hate Nix, the language), but Guix suffers from a few shortcomings that make it unsuitable for my needs:

• There’s no systemd. This is a deal breaker, because I built plenty of stuff on top of systemd, and have no desire to switch to anything else, unless it supports all the things I use systemd for (Shepherd does not).
• There’s a lot less packages, and what they have, are usually more out of date than on nixpkgs.
• Being a GNU project, using non-free software is a tad awkward (I can live with this, there isn’t much non-free software I use, and the few I do, I can take care of myself).
• Last time I checked, they used an e-mail based patch workflow, and that’s not something I’m willing to deal with. Not a big deal, because I don’t need to be able to contribute - but it would be nice if I could, if I wanted to. (I don’t contribute to nixpkgs either, but due to political reasons, not technical ones - Guix would be the opposite). If they move to Codeberg, or their own forge, this will be a solved issue, though.

Before I switched from Debian to NixOS, I experimented with Guix for a good few months, and ultimately decided to go with NixOS instead, despite not liking Nix. Guix’s shortcomings were just too severe for my use cases.

NixOS, because:

• I can have my entire system be declaratively configured, and not as a yaml soup bolted onto a random distro.
• I can trivially separate the OS, and the data (thanks, impermanence)
• it has a buttload of packages and integration modules
• it is mostly reproducible

All of these combined means my backups are simple (just snapshot /persist, with a few dirs excluded, and restic them to N places) and reliable. The systems all have that newly installed feel, because there is zero cruft accumulating.

And with the declarative config being tangled out from a literate Org Roam garden, I have tremendous, and up to date documentation too. Declarative config + literate programmung work really well together, amg give me immense power.

NixOS.

It is good for everything, if you invest a little time^[1] into it.

Considering the amount of CVEs the kernel puts out, I’d argue there’s plenty there that’s broken, and could be fixed by implementing them in a language less broken than C.

TLDR: Is it normal to distro hop after being using a distro perfectly for so long?

I have used the same distribution (Debian) for over 20 years when I decided to change distributions and switch to NixOS. Debian was - and still is - a very fine distribution. I just needed something radically different.

So, to answer your question: yes, it is perfectly normal. Two years isn’t even long.

If they have no desire to maintain/sysadmin their own linux systems, then the best distro to recommend is whatever you can help them with, and possibly even maintain for them.

Case in point, my Wife is a very happy NixOS user, despite knowing absolutely nothing about Linux. Yet, she’s on a distribution that’s as far from being newbie friendly as a distro can possibly be. She’s still happy with it, because I set it up for her, and I maintain it for her, she never has to install, upgrade or configure anything, ever.

I’d say “under no circumstances”. When building for production, you want to build on a stable foundation. LFS isn’t that, it’s an educational tool. It does not result in a maintainable, robust system. It requires tremendous amounts of work to keep it secure and updated: there’s no package manager, no repository you can pull from, no nothing. You have to build an entire distribution on your own. Outside of educational purposes, I’m having trouble to imagine any situation where that might be a good idea.

No, not even embedded. There were always distros targetting embedded systems, LFS was never a good choice there either. It was much more straightforward to strip down - say - Debian for a limited device, than to build something from scratch for it. (I spent a few years building and operating embedded Linux systems at the early 2000s, we built it on a stripped down Debian.)

My Emacs needed a bootloader.

I have Emacs, and I have my NixOS configuration. That’s all the GUI system configuration I need.

Both KDE and GNOME are good DEs (and there are many other great ones, and you don’t even need to use a DE; a mismash of applications with your compositor of choice works just aswell - but I digress), you can’t really go wrong with either.

For someone new to Linux, I would likely recommend GNOME, because it is more opinionated. While KDE is a lot more configurable, that also has a huge downside: configuration fatigue. GNOME is more restrictive, yes, but that has the advantage of not overwhelming you right out of the box.

If you like and wish to tinker, though, go with KDE. If you want to gently ease into Linux, go with GNOME first, and once you’re comfortable, you can still experiment with KDE. You can install both, and switch between them simply by logging out of one and into the other.

To add some nuance to the rest of the comments posted here: GPL’d code can be made proprietary, if the copyright holders all agree. For example, given a project that requires copyright assignment, if the project owner decides to take it proprietary, they can do that, because they’re the copyright owner. GPL alone is not enough to keep a codebase FLOSS. Luckily, both the kernel and git have hundreds of copyright owners (and does not require copyright assignment), so legally changing the license of either of them is practically impossible. So, really, Linus wouldn’t be able to take anything, code wise. He could take his future work, yeah, but he hasn’t been doing much development for the past decade.

Otherwise… He let go of git pretty early on, and it’s been maintained by Junio ever since. So nothing would happen there whatsoever, Linus’ retirement (friendly or otherwise) would be inconsequential for git.

The kernel has capable maintainers who have been maintaining stable trees for a long while now (often with companies backing them), and people who have been maintaining large subtrees. There’s a considerable overlap there, too. In short, there are a fair number of people who could fill in for Linus in a pinch. There’d be a small hiccup, and that’s about it. His skills and experience would be missed, but it wouldn’t cause any lasting harm.

Again, you’re misunderstanding the problem. Keeping applications up to date is not a problem. Keeping things working the way my family got used to is an entirely different matter, and it’s actually worse on Android & iOS (thus, most phones and tablets).

The main reason the family even has desktop PCs is because we couldn’t make tablets work for them. Something as simple as reading email was a problem, because the various email apps (gmail, k9, etc) changed their UIs, confusing the heck out of my parents. It would’ve been possible to improve that situation, but the tooling to remotely manage an android phone are far more limited than on a bog standard Linux desktop.

A lot of people do use phones tablets as their main computer, yes. Ask them how happy they are about it, how much trouble updates and random UI changes cause. Just because they “can live with it” does not mean they enjoy the experience, or want to live with it. Chances are, they don’t have other options. My family does. I think more people should have those options available to them.

(Also, the blog post is about desktop, specifically, and is a critique of distros trying to aim at non-enthusiasts. When it comes to mobile, those efforts are even more futile, because those specialised distros will have absolutely no chance of working on anything but a very tiny subset of mobile devices.)

I don’t like it. I don’t hate it, but I don’t like it. It’s not flexible enough for what I - and my family - needs from an operating system.

That does not address the problem at all, though. That solves the upgrade and maintenance problem, but does nothing for users who just want things to work as they always did. It does not address change.

By maintaining a system for my family, I can address that: either by undoing things, working them around, or preparing them in advance. No amount of automation will solve that. It’s not a technical problem.