Live data from Hacker News

An update on GitHub availability

github.blog

151–160 of 266 posts

Re: An update on GitHub availability

#152
post #29

Earlier quoted context omitted.

What is "sovereign infra" exactly?

No less than self hosted, imo. If youre on some cloud it doesnt really matter that you pay them absurd amounts of money, you arent sovereign.

So if a company self hosts their physical infrastructure which will burn down once a fire sets in, they are more "sovereign" than a company running on a redundant cloud? I definitely would not want to be "sovereign" then.

Point is: This discussion is much more multi-dimensional than some suggest.

Re: An update on GitHub availability

#153
post #26

Earlier quoted context omitted.

More numbers: https://x.com/kdaigle/status/2040164759836778878 What's the question here, you don't believe growth is currently exponential, or do you think it shouldn't be hard to scale, when 10x YoY is not enough?

As a business user, our costs have gone up while service has gone down dramatically. Meanwhile our marginal cost to GitHub has hardly changed. Where our costs to them have increased, they mostly charge us per cpu minute, so obviously aren’t making any kind of loss on our account. I’m sure they’re experiencing scaling issues across the platform, but it’s unacceptable for that to have a negative impact on us when we're…

In that case, why are you using them at all?

Re: An update on GitHub availability

#155
post #18

I'm biased (founder of tangled.org), but the future really should be federated forges. Host repositories on sovereign infra with global identity + federated "metadata" (issues, pulls, etc.). Global indices for this should be trivial to spin up so availability is never a concern (we're working towards this!).

> the future really should be federated

The internet should not be centralised, but you can't make a billion dollar company without capturing the world and selling your company to a trillion dollar company

Re: An update on GitHub availability

#156
post #4

openai, anthropic, google and a plethora of chinese models all end up pushing code into github. you can discuss whether gpt 5.5 is better than opus 4.7, but for github it doesn't matter: they'll be receiving the code no matter which llm spits it out. amazing on one hand, quite scary on the other for github and all other forges if this continues and there is no reason why it wouldn't.

Simple solution: charge all users. Charge more for higher usage.

Re: An update on GitHub availability

#157

Hah, love that now they say "Our priorities are clear: availability first, then capacity, then new features" when 6 months ago, it was seemingly exactly the same except Azure supposedly was gonna save them: > GitHub Will Prioritize Migrating to Azure Over Feature Development - GitHub is working on migrating all of its infrastructure to Azure, even though this means it'll have to delay some feature development. > In a…

This seems uncharitable. Priorities aren't exclusive, especially at scale across large engineering orgs like GitHub. It could be that these are the top level priorities, but teams or individuals who aren't able to contribute to these priorities will work on other things like new features.

Ditto. I agree though, just because the priority is reliability, doesn't mean others can't work on features, especially features that might help with reliability, which I read was the motivation behind the new single-issue view, so that's my bad, might have been a bit much.

I still think the rest of my point stands, especially the last one which is the move that has the biggest impact to the most of us developers.

Re: An update on GitHub availability

#158

I can not figure out what on Earth they've done with these graphs, it almost seems like these are an artists impression of a graph. Looking at the commit graph: Why do commits have big steps followed by slow rolloffs? Why do the steps not happen at uniform points Why do larger steps sometimes have less of a slope than smaller steps but not all the time? Then looking at the other graphs there's completely different ef…

It's because they are your standard PowerPoint graph that just shows "thing goes up" rather than actual data, or the meaning of the data.

Re: An update on GitHub availability

#159

Earlier quoted context omitted.

Really? I thought retail was. It's been almost a decade since I worked at prime video but I think everything was running on AWS. (Some things didn't use brazil etc, but I think all the servers etc. were on AWS)

It's a distinction without a difference. All new development is nAWS (native AWS) legacy is mAWS (not sure about the acronym) which is still AWS under the hood and is mostly just a pool of EC2 instances with preconfigured networks. Nothing made in the last five or six years is on maws, and amazon is a micro service shop so things are always being built new. If you joined today there's a good chance you'd join a team…

MAWS is “Move to AWS”, the name of the internal campaign to get legacy services into a somewhat-retrofitted AWS environment. It was a single VPC at one point.

Re: An update on GitHub availability

#160
post #95

Earlier quoted context omitted.

True but switching is not that easy when all your ci pipelines and integration on in GitHub.

I don't think it's 100% compatible, but Gitea's/Forgejo's (which Codeberg runs on) own Action implementation is pretty much the same as GitHub Actions, with minor differences.

Good to know might actually try it for one project 1 st before switching
Post reply on HN