Sadly, that's not code Linus wrote. Nor one he merged. (It's from git, copied from rsync, committed by Junio)

The single best thing I like about Zed is how they unironically put up a video on their homepage where they take a perfectly fine function, and butcher it with irrelevant features using CoPilot, and in the process:

• Make the function's name not match what it is actually doing.
• Hardcode three special cases for no good reason.
• Write no tests at all.
• Update the documentation, but make the short version of it misleading, suggesting it accepts all named colors, rather than just three. (The long description clarifies that, so it's not completely bad.)
• Show how engineering the prompt to do what they want takes more time than just writing the code in the first place.

And that's supposed to be a feature. I wonder how they'd feel if someone sent them a pull request done in a similar manner, resulting in similarly bad code.

I think I'll remain firmly in the "if FPS is an important metric in your editor, you're doing something wrong" camp, and will also steer clear of anything that hypes up the plagiarism parrots as something that'd be a net win.

Yes. My Actual Intelligence lives in my head, and runs mostly on coffee.

"As if openclaw and android had a baby", and that's a recommendation, not a warning? WTF.

...and here I am, running a blog that if it gets 15k hits a second, it won't even bat an eye, and I could run it on a potato. Probably because I don't serve hundreds of megabytes of garbage to visitors. (The preview image is also controllable iirc, so just, like, set it to something reasonably sized.)

Very bad, because the usability of such a scheme would be a nightmare. If you have to unzip the files every time you need a password, that'd be a huge burden. Not to mention that unzipping it all would leave the files there, unprotected, until you delete them again (if you remember deleting them in the first place). If you do leave the plaintext files around, and only encrypt & zip for backing up, that's worse than just using the plaintext files in the backup too, because it gives you a false sense of security. You want to minimize the amount of time passwords are in the clear.

Just use a password manager like Bitwarden. Simpler, more practical, more secure.

Invent a time machine. Go back in time. Study.

Failing that, learn from your mistakes, and next time... well... study.

Most GenAI was trained on material they had no right to train on (including plenty of mine). So I'm doing my small part, and serving known AI agents an infinite maze of garbage. They can fuck right off.

Now, if we're talking about real AI, that isn't just a server park of disguised markov chains in a trenchcoat, neural networks that weren't trained on stolen data, that's a whole different story.

Steam Deck, because it is handheld, and can run a lot of my Steam games. I can also dock it to a big screen and attach a controller.

There are no bugs. Just happy little accidental features.

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.

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.

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.

Fair bias notice: I am a Forgejo contributor.

I switched from Gitea to Forgejo when Forgejo was announced, and it was as simple as changing the binary/docker image. It remains that simple today, and will remain that simple for the foreseeable future, because Forgejo cherry picks most of the changes in Gitea on a weekly basis. Until the codebases diverge, that will remain the case, and Forgejo will remain a drop-in replacement until such time comes that we decide not to pick a feature or change. If you're not reliant on said feature, it's still a drop-in replacement. (So far, we have a few things that are implemented differently in Forgejo, but still in a compatible way).

Let me offer a few reasons to switch:

• Forgejo - as of today, and for the foreseeable future - includes everything in Gitea, but with more tests, and more features on top. A few features Forgejo has that Gitea does not:
  • Forgejo makes it possible to have any signed in user edit Wikis (like GitHub), Gitea restricts it to collaborators only. (Forgejo defaults to that too, but the default can be changed). Mind you, this is not in a Forgejo release yet, it will be coming in the next release probably in April.
  • Gitea has support for showing an Action status badge. Forgejo has badges for action statuses, stars, forks, issues, pull requests.
  • ...there are numerous other features being developed for Forgejo that will not make it into Gitea unless they cherry pick it (they don't do that), or reimplement it (wasting a lot of time, and potentially introducing bugs).
• Forgejo puts a lot of effort into testing. Every feature developed for Forgejo needs to have a reasonable amount of tests. Most of the things we cherry pick for Gitea, we write tests for if they don't have any (we write plenty of tests for stuff originating from Gitea).
• Forgejo is developed in the open, using free tools: we use Forgejo to host the code, issues and releases, Forgejo Actions for CI, and Weblate for translations. Gitea uses GitHub to host the code, issues and releases, uses GitHub CI, and CrowdIn for translations (all of them proprietary platforms).
• Forgejo accepts contributions without requiring copyright assignment, Gitea does not.
• Forgejo routinely cherry picks from Gitea, Gitea does not cherry pick from Forgejo (they do tend to reimplement things we've done, though, a huge waste of time if you ask me).
• Forgejo isn't going anywhere anytime soon, see the sustainability repo. There are people committed to working on it, there are people paid to work on it, and there's a fairly healthy community around it already.

None, because they typicially open up a larger attack surface than the system would have without them. It's been like that for a while now. For references, I'd recommend this article from Ars Technica, who reference some very knowledgeable people (including Chrome's Security Chief at the time).

There was a time when AV software was useful. We're a decade past that, the world has changed, software has changed, defenses have changed, and AV software did not keep up.

Aren't all consoles like that, though? They all run mainstream operating systems, and are basically locked down PCs in a fancy box. If anything, the Steam Deck is further from a PC than an XBox/PS, due to being handheld, with an embedded screen and controller, while XBox and its friends require a display and an external controller (like a PC).

I have a social life because of the internet. That's where most of my friends are, too.

I've been daily driving NixOS for about a year now, switched from over two decades of running Debian. I'll try to answer your questions from my perspective:

How much can I grok in a week?

If you have some experience with functional programming or declarative configs (think Ansible), then it's a lot easier. You can definitely learn enough in a week to get started. One year in, my Nix knowledge is very light still, and I get by fine. On the other hand, there's a lot of Nix I simply don't use. I don't write reusable Nix modules, and my NixOS configuration isn't split into small, well manageable files. It's a single 3k lines long, 130k sized flake.nix. Mind you, it's not complete chaos: it is generated from an Org Roam document (literate programming style; my Org Roam files are 1.2mb in size, clocking in at a bit below 10k lines).

With that said, it took me about a month of playing and experimenting with NixOS in a VM casually, a couple of hours a week, to get comfortable and commit to switching. It's a lot easier once you switched, though.

How quick is it to make a derivation?

For most things, a couple of minutes tops. I found it easier to create derivations than creating Debian packages, and I was a Debian Developer for two decades, had a lot more and lot deeper understanding of Debian packaging practices. It's not trivial, but it's also not hard. The first derivation is maybe a bit intimidating, but the 10th is just routine.

Regarding make install & co, you can continue doing that. I use project-specific custom flakes and direnv to easily set up a development environment. That makes development very easy. For installing stuff... I'd still recommend derivations. A simple ./configure && make && make install is usually very easy to write a derivation for. And nixpkgs is huge, chances are, someone already wrote one.

How quick is it to install something new and random?

With a bit of self control and liberal use of direnv & flakes, near instant.

How long do you research a new package for?

https://search.nixos.org/packages, you can search for a package, and you can explore its derivation. The same page also provides search for NixOS options, so you can explore available NixOS modules to help you configure a package.

Can you set up dev environments quickly or do you need to write a ton of configs?

Very easy, with a tiny amount of practice. Liberal use of flakes & direnv, and you're good to go. I can't comment much on Python, because I don't do much Python nowadays, but JavaScript, Go, Rust, C, C++ have been very easy to build dev environments for.

What maintenance ouchies do you run into? How long to rectify?

None so far. If it builds, it usually works. I do need to read release notes for packages I upgrades, but that's also reasonably easy, because I can simply "diff" the package version between my running system, and the configuration I just built: I can see which packages were upgraded, and can look up their release notes if need be. In short, about the same effort as upgrading Debian was (where I also rarely ran into upgrade/maintenance gotchas).

Do I need to finagle on my own to have /boot encrypted?

If you use the NixOS installer, then yeah, you do have to fiddle with that a bit more than one would like. If you install via other means (eg, build your own flake and use something like nixos-anywhere to install it), then it's pretty easy and well supported and documented.

Feel free to ask further question, I'm happy to elaborate on my experience so far.

Real-time web search via Brave - no tracking, no bubbles, just truth

I wonder if they realize that the owner of Brave is everything they supposedly stand against.

Military grade encryption (aes-256)

I smell bullshit.

...and absolutely no mention of how it was trained. Does it still crawl the entire internet to steal and plunder and train on material obtained without consent?

I have an unfederated XMPP server (running Prosody), family's using Conversations (Android) & Dino (Linux) with it. We can chat, send images, do voice & video calls. Has been working fine & reliably for the past ~6 years or so. Took about 1.5 minutes for them to get used to the clients.

I'm slowly opening it up for friends too, so friends, neighbours, classmates, etc can chat with us too. It's going great so far, no complaints.