Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig quits GitHub, says Microsoft's AI obsession has ruined the service

theregister.com

Post reply on HN
Print view View original

101–110 of 641 posts

Re: Zig quits GitHub, says Microsoft's AI obsession has ruined the service

#101

Post by nromiun »

Left5250 wrote: post #97
nromiun wrote: post #91

Earlier quoted context omitted.

That is surprising. It is the opposite for me. $ time curl -L 'https://codeberg.org/' real 0m3.063s user 0m0.060s sys 0m0.044s $ time curl -L 'https://github.com/' real 0m1.357s user 0m0.077s sys 0m0.096s

That depends on location and GitHub pages generally take a while to execute all the javascript for a usable page even after the html is fetched while pages on Codeberg require much less javascript to be usable and are quite usable even without javascript. Here are my results for what it's worth $ time curl -o /dev/null -s -L 'https://codeberg.org' real 0m0.907s user 0m0.027s sys 0m0.009s $ time curl -o /dev/null -s -…

Sure, it depends on your internet connection. But for Codeberg I see a blank page for 3-4 seconds until it shows something. On a big repo like Zig the delay is even worse.

On Github any page loads gradually and you don't see a blank page even initially.

Re: Zig quits GitHub, says Microsoft's AI obsession has ruined the service

#102

Post by aperture147 »

I don't get it, why did they allow GitHub bot to modify and merge pull request automatically? Yeah I agree that MS is ruining everything with AI, but this problem is avoidable, if they turn off the bot's auto merge feature, or turn it off completely. The reason they move to a lesser known Git provider sounds more like a marketing stunt.

Re: Zig quits GitHub, says Microsoft's AI obsession has ruined the service

#104

Post by gaigalas »

sevenseacat wrote: post #88
gaigalas wrote: post #82

Earlier quoted context omitted.

> So frustrating that Github doesn't support such an obvious workflow. It kind of does. I used this a lot in several jobs to work in dependent tickets in advance. Just make another branch on top of the previous (a PR to the other PR branch). People could review the child PR before the parent was merged. And it requires some less than trivial git knowledge to manage effectively, but nothing extraordinary. Any solution…

That feels like the opposite of what I think stacked PRs are? Like someone will open PR #1 for one feature, and then PR #2 into the PR #1 branch, but it doesn't make sense without knowing the context of PR #1 so that gets reviewed first - and then when that PR gets merged, the second one gets automatically closed by GitHub?

PR#1: dough PR#2: toppings

You first send PR#1, then PR#2 on top of the first one.

The diff for PR#1 will show dough stuff. The diff for PR#2 will show toppings in relation to dough.

People can review them asynchronously. If you merge PR#1, PR#2 will automatically target main (that's where dough went) now.

In this arrangement, I use to cross-mention the PRs by number (a link will exist in both). I also like to keep the second one draft, but that depends on the team practices.

I don't understand why you would close the second PR when the first gets merged. It should lose the dependency automagically, which is exactly what happens if you branch correctly.

Re: Zig quits GitHub, says Microsoft's AI obsession has ruined the service

#105

Post by literallyroy »

aperture147 wrote: post #102

I don't get it, why did they allow GitHub bot to modify and merge pull request automatically? Yeah I agree that MS is ruining everything with AI, but this problem is avoidable, if they turn off the bot's auto merge feature, or turn it off completely. The reason they move to a lesser known Git provider sounds more like a marketing stunt.

What are you referring to? I may be missing a line from the article but it seems mostly focused around a lingering GitHub Actions bug and the direction of GitHub.

Re: Zig quits GitHub, says Microsoft's AI obsession has ruined the service

#106

Post by hinkley »

messe wrote: post #18
hinkley wrote: post #13

Earlier quoted context omitted.

Oh no, our decentralized VCS will be… decentralized! Seriously though the big problem to solve will be squatters, when there are three logical places for a module to be hosted. That could create issues if you want to migrate. I would rather have this happening after a contender to git has surfaced. Something for instance with more project tracking built in so migration were simpler.

> Seriously though the big problem to solve will be squatters, when there are three logical places for a module to be hosted I suspect Codeberg, which is focused on free software, will frown on them. They already disallow mirroring.

That… makes squatting more of a problem not less.

Re: Zig quits GitHub, says Microsoft's AI obsession has ruined the service

#107

Post by karel-3d »

aperture147 wrote: post #102

I don't get it, why did they allow GitHub bot to modify and merge pull request automatically? Yeah I agree that MS is ruining everything with AI, but this problem is avoidable, if they turn off the bot's auto merge feature, or turn it off completely. The reason they move to a lesser known Git provider sounds more like a marketing stunt.

> I don't get it, why did they allow GitHub bot to modify and merge pull request automatically

They didn't, poor wording on Register part. The pull request was closed for inactivity by the bot.

Re: Zig quits GitHub, says Microsoft's AI obsession has ruined the service

#108

Post by skydhash »

nromiun wrote: post #91
reppap wrote: post #61

One thing that's really nice about codeberg is how fast the pages load. Browsing GitHub often feels very sluggish. Obviously there's a difference in scale there, but I hope codeberg can keep being fast.

That is surprising. It is the opposite for me. $ time curl -L 'https://codeberg.org/' real 0m3.063s user 0m0.060s sys 0m0.044s $ time curl -L 'https://github.com/' real 0m1.357s user 0m0.077s sys 0m0.096s

A better benchmark is done through the web browser inspector (network tab or performance tab). In the network tab I got (cache disabled)

  Github
  158 requests
  15.56 MB (11.28 MB transferred)
  Finish in 8.39s
  Dom loaded in 2.46s
  Load 6.95s

  Codeberg
  9 requests
  1.94 MB (533.85 KB transferred)
  Finish in 3.58s
  Dom loaded in 3.21s
  Load 3.31s

Re: Zig quits GitHub, says Microsoft's AI obsession has ruined the service

#109

Post by keiferski »

LLMs are useful, but AI is itself a marketing term that has begun to lose its luster. It’s rapidly becoming an annoying or trendy label, not a cutting edge one.

I guarantee that in ~24 months, most AI features will still remain in some form or another on most apps, but the marketing language of AI-first will have evaporated entirely.

Re: Zig quits GitHub, says Microsoft's AI obsession has ruined the service

#110

Post by mittermayr »

Additional note on Codeberg, which I think is great as a project, but I got curious on what infrastructure they are running on and how reliable this would be for larger corporate repos.

Nov 22, 2025 https://blog.codeberg.org/letter-from-codeberg-onwards-and-u...

Quotes from their website:

Infrastructure status [...] We are running on 3 servers, one Gigabyte and 2 Dell servers (R730 and R740).

Here's their current hardware: https://codeberg.org/Codeberg-Infrastructure/meta/src/branch...

[...] Although aged, the performance (and even energy efficiency) is often not much worse than with new hardware that we could afford. In the interest of saving embodied carbon emissions from hardware manufacturing, we believe that used hardware is the more sustainable path.

[...] We are investigating how broken Apple laptops could be repurposed into CI runners. After all, automated CI usage doesn't depend on the same factors that human beings depend on when using a computer (functioning screen, speakers, keyboard, battery, etc.). If you own a broken M1/M2 device or know someone who does, and believe that it is not worth a conventional repair, we would be happy to receive your hardware donation and give it a try!

[...] While it usually holds up nicely, we see sudden drop in performance every few days. It can usually be "fixed" with a simple restart of Forgejo to clear the backlog of queries.

Gives both early-Google as well as hackerspace vibes, which can or can not be a good thing.

Post reply on HN