Newest at the top
| 2026-06-28 14:59:19 +0000 | <spew> | I use source hut |
| 2026-06-28 14:54:34 +0000 | <jaror> | Yeah, so the choices seem to be either Codeberg or GitHub. The latter seems more likely to survive better in the current landscape, but I'd hope codeberg can survive too. |
| 2026-06-28 14:53:00 +0000 | spew | (~spew@user/spew) spew |
| 2026-06-28 14:47:55 +0000 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2026-06-28 14:46:10 +0000 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
| 2026-06-28 14:46:00 +0000 | fp | (~Thunderbi@46-133-26-225.mobile.vf-ua.net) (Ping timeout: 245 seconds) |
| 2026-06-28 14:45:45 +0000 | chromoblob | (~chromoblo@user/chromob1ot1c) (Read error: Connection reset by peer) |
| 2026-06-28 14:43:43 +0000 | <tomsmeding> | so if that's the case and codeberg is still much better off than the GHC gitlab, they must be doing some clever blocking |
| 2026-06-28 14:42:29 +0000 | <tomsmeding> | jaror: it's possible that forgejo is faster than gitlab, which would alleviate some of the pressure, but if it's just 2x as fast, that just postpones the problems until scraper volume doubles |
| 2026-06-28 14:41:45 +0000 | fp | (~Thunderbi@46-133-26-225.mobile.vf-ua.net) fp |
| 2026-06-28 14:41:26 +0000 | fp | (~Thunderbi@46-133-26-225.mobile.vf-ua.net) (Quit: fp) |
| 2026-06-28 14:37:13 +0000 | <jaror> | For me it is ~10s per request but some other regularly have to wait minutes or even get errors. |
| 2026-06-28 14:37:12 +0000 | <tomsmeding> | the problem with the GHC gitlab is that you genuinely use a bunch of the features of gitlab, including and not limited to the wiki |
| 2026-06-28 14:36:42 +0000 | <tomsmeding> | but that holds for github too, perhaps even more, though github probably has micro$oft resources for blocking bad actors |
| 2026-06-28 14:36:18 +0000 | <tomsmeding> | it _is_ true that my experience with gitlab so far, also outside GHC's instance, has been "it's kinda slow" |
| 2026-06-28 14:35:43 +0000 | <jaror> | That might be the case, but in the end it is unacceptably slow. GitHub and Codeberg do seem to manage better. |
| 2026-06-28 14:35:17 +0000 | <tomsmeding> | at some point, if there are enough requests, there's not much to do except blocking based on the sender of the request, which, with the botnets, is infeasible except for big centralised companies |
| 2026-06-28 14:34:08 +0000 | <tomsmeding> | I wouldn't be surprised if the GHC gitlab is just spammed much more than git.tomsmeding.com, if only because there's more stuff on there to spam in the first place |
| 2026-06-28 14:34:03 +0000 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
| 2026-06-28 14:33:37 +0000 | <tomsmeding> | are we sure that the problem is that gitlab is slow? |
| 2026-06-28 14:33:29 +0000 | <tomsmeding> | right |
| 2026-06-28 14:33:19 +0000 | chromoblob | (~chromoblo@user/chromob1ot1c) (Ping timeout: 264 seconds) |
| 2026-06-28 14:33:14 +0000 | <jaror> | The admins (mainly mangoiv) is aware and has tried a lot, but nothing seems to work very well. |
| 2026-06-28 14:32:10 +0000 | <tomsmeding> | and by whom |
| 2026-06-28 14:32:02 +0000 | <tomsmeding> | what exactly is being spammed when the site is slow |
| 2026-06-28 14:31:49 +0000 | <jaror> | Where "slow" means >10s response times |
| 2026-06-28 14:31:43 +0000 | <tomsmeding> | I think to diagnose this you'd need info from the server admins about what's going on in the server logs |
| 2026-06-28 14:30:20 +0000 | <jaror> | It seems Anubis might be causing some of the issues, but yeah even with anubis the GitLab is slow sometimes. |
| 2026-06-28 14:28:46 +0000 | <tomsmeding> | (in the latter case, hand-rolling a portal and changing it once in a while might help, but not in the former case) |
| 2026-06-28 14:28:16 +0000 | <tomsmeding> | and if so, do we have any idea if they just have a generic browser emulator or if they have special-cased code for anubis |
| 2026-06-28 14:27:22 +0000 | <fgarcia> | i think something else people could try are hosting git and also using cloudflare or anubis |
| 2026-06-28 14:27:21 +0000 | <tomsmeding> | jaror: are they getting through anubis? |
| 2026-06-28 14:23:37 +0000 | <tomsmeding> | I don't know if they're spamming it, because I as a user of that VPS (also for other things) don't notice it :p |
| 2026-06-28 14:22:48 +0000 | <tomsmeding> | Though maybe there just isn't enough on there! |
| 2026-06-28 14:22:38 +0000 | <tomsmeding> | zero |
| 2026-06-28 14:22:16 +0000 | gmg | (~user@user/gehmehgeh) gehmehgeh |
| 2026-06-28 14:22:06 +0000 | <jaror> | I'm mainly asking because the situation with the GHC GitLab is getting critical. |
| 2026-06-28 14:21:27 +0000 | <jaror> | tomsmeding: have you taken special precautions against scrapers? |
| 2026-06-28 14:21:06 +0000 | gmg | (~user@user/gehmehgeh) (Ping timeout: 245 seconds) |
| 2026-06-28 14:20:16 +0000 | <jaror> | mauke* |
| 2026-06-28 14:19:43 +0000 | haritz | (~hrtz@user/haritz) haritz |
| 2026-06-28 14:19:43 +0000 | haritz | (~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8) (Changing host) |
| 2026-06-28 14:19:43 +0000 | haritz | (~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8) |
| 2026-06-28 14:18:41 +0000 | <jaror> | mauks: yes, I agree, but the 93% uptime makes it hard to convince others. |
| 2026-06-28 14:17:36 +0000 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 246 seconds) |
| 2026-06-28 14:17:24 +0000 | <mauke> | quite happy with codeberg so far |
| 2026-06-28 14:17:02 +0000 | <tomsmeding> | jaror: my cgit instance is doing fine, although that of course is _just_ git, no issues, PRs, etc. |
| 2026-06-28 14:17:00 +0000 | <mauke> | github is an ai scraper |
| 2026-06-28 14:11:46 +0000 | <jaror> | I guess that's a new advantage of Darcs: the bots don't know how to clone your repo :) |
| 2026-06-28 14:10:41 +0000 | <jaror> | It seems like github is the only place left that can provide some resistance to the ai scraper ddos |