Which actively maintained Yarn/twtxt clients are there at the moment? Client authors raise your hands! 🙋

(#jryh2ba) @prologic@twtxt.net Time to make a new internet. Maybe one that intentionally doesn’t “scale” and remains slow (on both ends) so it’s harder to overload in this manner, harder to abuse for tracking your every move, … Got any of those 56k modems left?

(I’m half-joking. “Make The Internet Expensive Again” like it was in the 1990ies and some of these problems might go away. Disclaimer: I didn’t have my coffee yet. 😅)

(#ifjh3pa) @lyse@lyse.isobeef.org Oops. 😅 But yay, it’s working. 🥳

(#kyfenpq) And regarding those broken URLs: I once speculated that these bots operate on an old dataset, because I thought that my redirect rules actually were broken once and produced loops. But a) I cannot reproduce this today, and b) I cannot find anything related to that in my Git history, either. But it’s hard to tell, because I switched operating systems and webservers since then …

But the thing is that I’m seeing new URLs constructed in this pattern. So this can’t just be an old crawling dataset.

I am now wondering if those broken URLs are bot bugs as well.

They look like this (zalgo is a new project):

https://www.uninformativ.de/projects/slinp/zalgo/scksums/bevelbar/

When you request that URL, you get redirected to /git/:

$ curl -sI https://www.uninformativ.de/projects/slinp/zalgo/scksums/bevelbar/
HTTP/1.0 301 Moved Permanently
Date: Sat, 22 Nov 2025 06:13:51 GMT
Server: OpenBSD httpd
Connection: close
Content-Type: text/html
Content-Length: 510
Location: /git/

And on /git/, there are links to my repos. So if a broken client requests https://www.uninformativ.de/projects/slinp/zalgo/scksums/bevelbar/, then sees a bunch of links and simply appends them, you’ll end up with an infinite loop.

Is that what’s going on here or are my redirects actually still broken … ?

(#sxlpyva) I just noticed this pattern:

uninformativ.de 201.218.xxx.xxx - - [22/Nov/2025:06:53:27 +0100] "GET /projects/lariza/multipass/xiate/padme/gophcatch HTTP/1.1" 301 0 "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.0.0 Safari/537.36"
www.uninformativ.de 103.10.xxx.xxx  - - [22/Nov/2025:06:53:28 +0100] "GET http://uninformativ.de/projects/lariza/multipass/xiate/padme/gophcatch HTTP/1.1" 400 0 "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.0.0 Safari/537.36"

Let me add some spaces to make it more clear:

    uninformativ.de 201.218.xxx.xxx - - [22/Nov/2025:06:53:27 +0100] "GET                       /projects/lariza/multipass/xiate/padme/gophcatch HTTP/1.1" 301 0 "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.0.0 Safari/537.36"
www.uninformativ.de 103.10.xxx.xxx  - - [22/Nov/2025:06:53:28 +0100] "GET http://uninformativ.de/projects/lariza/multipass/xiate/padme/gophcatch HTTP/1.1" 400 0 "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.0.0 Safari/537.36"

Some IP (from Brazil) requests some (non-existing, completely broken) URL from my webserver. But they use the hostname uninformativ.de, so they get redirected to www.uninformativ.de.

In the next step, just a second later, some other IP (from Nepal) issues an HTTP proxy request for the same URL.

Clearly, someone has no idea how HTTP redirects work. And clearly, they’re running their broken code on some kind of botnet all over the world.

My webserver is getting millions of hits per month at the moment.

All bots.

(#dkc24ma) @thecanine@twtxt.net That image is correct.

(#gg45s6a) @thecanine@twtxt.net Not bad. 🥳 Fingers crossed that they actually do it. 🤞

(#enujccq) Luckily, I haven’t noticed at all. 😅

Another day, another attempt at rearranging the furniture, because I am never happy with that. 😟

(#6ozbn3a) @lyse@lyse.isobeef.org That is brilliant! 🤣

(#6e546wa) FTR, I see one (two) issues with PyQt6, sadly:

1. The PyQt6 docs appear to be mostly auto-generated from the C++ docs. And they contain many errors or broken examples (due to the auto-conversion). I found this relatively unpleasent to work with.
   
2. (Until Python finally gets rid of the Global Interpreter Lock properly, it’s not really suited for GUI programs anyway – in my opinion. You can’t offload anything to a second thread, because the whole program is still single-threaded. This would have made my fractal rendering program impossible, for example.)

(#6e546wa) @prologic@twtxt.net Hm, same startup delay. (Go is not an option for me anyway.)

It’s hard to tell why all this is so slow. Maybe in this particular case it has something to do with fonts: strace shows the program loading the fontconfig configs several times, and that takes up a bulk of the startup time. 🤔 (Qt6 or Java don’t do that, but they’re still slow to start up – for other reasons, apparently.)

To be fair, it’s “just” the initial program startup (with warm I/O caches). Once it’s running, it’s fine. All toolkits I’ve tried are. But I don’t want to accept such delays, not in the year 2025. 😅 Imagine every terminal window needing half a second to appear on the screen … nah, man.

(#6e546wa) Be it Java with Swing or PyQt6, it takes ~300 ms until a basic window with a treeview and a listbox appears. That is a very noticeable delay.

Is it unrealistic to expect faster startup times these days? 🤔

Once the program is running, a new second window (in the same process) appears very quickly. So it’s all just the initialization stuff that takes so long. I could, of course, do what “fat” programs have done for ages: Pre-launch the process during boot, windowless. But I was hoping that this wasn’t needed. 😞 (And it’s a bad model anyway. When the main process crashes, all windows crash with it.)