5 ms·

Being "professionally hosted" is not enough: You need a "cluefully developed" distributed git backend to be a GitHub competitor. Codeberg is already buckling de

Being "professionally hosted" is not enough: You need a "cluefully developed" distributed git backend to be a GitHub competitor. Codeberg is already buckling despite being nowhere near GitHub's scale. When Codefloe gains more users/agents, it's going to suffer from the same fate since Forgejo/Gitea/Gogs just isn't a good foundation to build on top of.

nylonstrung 23d ago
What do you think makes it a bad foundation to build on?
- Scaevolus 23d ago
  See Cursor's recent blog post on launching a Github competitor, particularly the architectural history.
  - rootnod3 23d ago
    Right...check the vibe coded slob pile for reference...
  - sa46 23d ago
    That’s a great blog post, lots of details, helpful animations, historical context, and an interspersing of war stories. https://cursor.com/blog/git-at-any-scale https://cursor.com/blog/git-at-any-scale
- oooyay 22d ago
  Their primary storage medium is block storage which is quite expensive. Codeberg cited it, although post-hoc, in their decision to ban AI projects. GitLab runs (or ran) the large block storage based Git service I know of which is Gitaly. If you want to achieve public service level traffic and cost then you pretty much need to find a way to leverage object storage.
  - inigyou 22d ago
    Note that this assumes cloud-based. A rack full of hard drives is far cheaper per GB than either, even at 50% utilisation and 2x redundancy. (It would have to be! Amazon obviously wants to make a profit)
  - jeremyjh 22d ago
    GitHub also uses block storage - its just git on NVME. The complicated part is the redundancy and ensuring consistency. Cursor introduced an S3 WAL in their new system, Continuity. https://cursor.com/blog/git-at-any-scale https://cursor.com/blog/git-at-any-scale
pat-s 20d ago
(founder of codefloe) Codeberg is buckling because of old hardware and not-so-great operational devops processes. I am stating that as a former core member with access to these and the historic goals of changing something to the better. The underlying software is not the issue. GitHub and GitLab were built on Ruby. The language behind this is much less suited to serve a platform with that many requests. The hard part is the SRE engineering behind it and the option to potentially make tweaks in the underlying codebase when needed, to fix possible bottlenecks (most often it comes down to how SQL is being processed).

nylonstrung 23d ago

What do you think makes it a bad foundation to build on?

Scaevolus 23d ago
See Cursor's recent blog post on launching a Github competitor, particularly the architectural history.
- rootnod3 23d ago
  Right...check the vibe coded slob pile for reference...
- sa46 23d ago
  That’s a great blog post, lots of details, helpful animations, historical context, and an interspersing of war stories. https://cursor.com/blog/git-at-any-scale https://cursor.com/blog/git-at-any-scale
oooyay 22d ago
Their primary storage medium is block storage which is quite expensive. Codeberg cited it, although post-hoc, in their decision to ban AI projects. GitLab runs (or ran) the large block storage based Git service I know of which is Gitaly. If you want to achieve public service level traffic and cost then you pretty much need to find a way to leverage object storage.
- inigyou 22d ago
  Note that this assumes cloud-based. A rack full of hard drives is far cheaper per GB than either, even at 50% utilisation and 2x redundancy. (It would have to be! Amazon obviously wants to make a profit)
- jeremyjh 22d ago
  GitHub also uses block storage - its just git on NVME. The complicated part is the redundancy and ensuring consistency. Cursor introduced an S3 WAL in their new system, Continuity. https://cursor.com/blog/git-at-any-scale https://cursor.com/blog/git-at-any-scale

pat-s 20d ago

(founder of codefloe) Codeberg is buckling because of old hardware and not-so-great operational devops processes. I am stating that as a former core member with access to these and the historic goals of changing something to the better. The underlying software is not the issue. GitHub and GitLab were built on Ruby. The language behind this is much less suited to serve a platform with that many requests. The hard part is the SRE engineering behind it and the option to potentially make tweaks in the underlying codebase when needed, to fix possible bottlenecks (most often it comes down to how SQL is being processed).