Newest at the top
| 2026-06-28 15:11:22 +0000 | <geekosaur> | codeberg, yeh. dunno about others, but I get the impression it works until it overloads completely |
| 2026-06-28 15:09:31 +0000 | tromp | (~textual@2001:1c00:340e:2700:dd19:dfa1:d2a9:f5b7) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2026-06-28 15:05:10 +0000 | <tomsmeding> | codeberg's forgejo instance, you mean? Or something else? |
| 2026-06-28 15:04:40 +0000 | <geekosaur> | forgejo has a different version of the problem: I'm regularly hearing about it being down at times |
| 2026-06-28 15:00:46 +0000 | <tomsmeding> | is the server bandwidth-saturated or something |
| 2026-06-28 15:00:40 +0000 | <tomsmeding> | even loading the banner photo on the anubis check page takes a long time |
| 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. |