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

An update on GitHub availability

github.blog

Post reply on HN
Print view View original

211–220 of 266 posts

Re: An update on GitHub availability

#211

Post by greatgib »

giancarlostoro wrote: post #187
embedding-shape wrote: post #31

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…

If they had not added or changed any features to GitHub for the past 5 years, nobody would be upset, and yet, they keep changing it. It's a website that doesn't need to be reworked every five minutes. I assume the main development teams maintaining GitHubs codebase are ran by managers who cannot justify their jobs unless they deliver new features for the sake of delivering new features to keep their jobs going, and /…

What they nerfed the most is the basic feature of the PR diff view.

It's only job is to display diff and review comments and it easily hide the diff for files that are a lit bit longer and hide comments when you have more than a dozen. You need to click to see. It's impossible to search in diff without going through it to expand everything.

And a ton of things are regression compared to working with pr a few years ago. Including being a lot worse in terms of latency!

Re: An update on GitHub availability

#212

Post by senderista »

OutOfHere wrote: post #144

> we accelerated parts of migrating performance or scale sensitive code out of Ruby monolith into Go. I am surprised that Microsoft is allowed to use Go. How long will it be before a bean counter forces a rewrite to a Microsoft favored language?

They used Go for the new TypeScript compiler!

Re: An update on GitHub availability

#213

Post by torben-friis »

jmbwell wrote: post #129
torben-friis wrote: post #62

Not enough attention is being put in the production/delivery mismatch. GitHub is claiming they require 30x scale due to the giant increase in repository creation, PRs, commits, etc. I have not seen a single product increase in features or quality as an end user, nor new significant products have come out in this period (other than the LLMs themselves). Where is all this code going?

I understood it to mean, GitHub is being crushed by LLM/AI/Agentic code review and submission, not GitHub’s code itself What I’m not seeing here but I am seeing with the Linux kernel is, most of the automatically submitted code is irrelevant or not useful (Maybe that’s what you were getting at, apologies)

>GitHub is being crushed by LLM/AI/Agentic code review and submission, not GitHub’s code itself

Yes, that was the intented meaning, sorry if it wasn't clear.

My point was that, if we can assume github's load is a decent proxy for global code generation, we're generating 30x without 30x results.

30x means that iOS could generate as many features as it has had since development in just a year. I don't think there is evidence of even 2x delivery in the industry.

Re: An update on GitHub availability

#214

Post by huijzer »

huijzer wrote: post #6

I’m pretty sure my Forgejo instance on a Raspberry Pi is outperforming GitHub reliability. It’s faster that’s for sure.

Why the downvotes? I’m serious. On GitHub I’ve experienced many downtimes. My Forgejo hasn’t gone down yet apart from reboots by me.

Re: An update on GitHub availability

#215

Post by steve1977 »

sgarland wrote: post #140
tankenmate wrote: post #54

Earlier quoted context omitted.

This sounds more like a belief, based on little more than "correlation is causation", than analysis that controls for macro-trends backed by evidence.

It is, but everyone is entitled to beliefs. Anecdotally, I feel the same way. Everywhere I’ve been, there has always been a legacy monolith that was stable as a rock, with dozens of new microservices scattered around it in an attempt to exit the monolith. The microservices have never once been stable. People fail to take the most basic things into consideration, like “you can’t have Consistency and Availability when…

I mean one of the selling points of microservices is, that the developer can only be concerned with their slice of the whole and does not need to understand systems. Maybe this is not so clever after all.

Or, it would require an architect who has a very good understanding of the system. Which in reality seems to be rare.

Re: An update on GitHub availability

#216

Post by dangus »

Notice how the graphs have no Y axis. That's how you know it's manipulative.

This company is owned by one of the major causes of the AI boom and is hiding behind difficulty scaling, despite its parent company also being a premier source of scaling solutions.

GitHub: don't gaslight your customers.

It is not your customers' problem that you're having trouble scaling. Nobody cares. Give us the service we are paying you for and make it reliable, or else we'll choose something else.

After the words "Both of those incidents are not acceptable" the blog post should have been over. Nobody needs to hear a sob story about how your service is too popular.

Re: An update on GitHub availability

#217

Post by dangus »

madeofpalk wrote: post #128
embedding-shape wrote: post #31

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.

Why do we need to be charitable to Microsoft?

Did we lose our ability to consider them the evil empire?

Re: An update on GitHub availability

#218

Post by tfrancisl »

beernet wrote: post #152
tfrancisl wrote: post #33

Earlier quoted context omitted.

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.

A redundant cloud that could be rug pulled from you any day if the platform decides you are in violation of their terms, or if they just dont like your project. Yes, on prem is more sovereign than that. That doesnt mean it doesn't have drawbacks, and no one said it didnt. But if sovereignty is more important than redundancy, then on prem is certainly an option.

Re: An update on GitHub availability

#219

Post by ljm »

icy wrote: post #118
ljm wrote: post #114

Earlier quoted context omitted.

I would love if it coding agents didn't default to GitHub for their deep VCS integration. If I could get the same bells and whistles by wiring up another forge, so long as it offered a decent API and/or sent events over a webhook, I'd have everything self-hosted. The agents would need to expose an interface on their own end but as long as you implemented it with a plugin, it'd take the dependency of GitHub and you co…

The neat thing about Tangled is it's built on an open protocol ( https://atproto.com )—this allows us to effectively build an API-free system since all data on Tangled can effectively be ingested via the AT Protocol firehose. Which is to say, this is perfect for agents given they don't need any bespoke SDK from us: simply write Tangled records for issues, pulls, whatever to your PDS and it'll show up on Tangled. We p…

You do realise that writing Tangled records for issues, pulls, whatever constitutes both a spec and API.

The fact that you use a protocol to define it is beside the point. You still have to define what a Tangled record is, and the interface that accepts it, and the mechanism to resolve it on the client.

How else do you define what a 'tangled' is even if the underlying structure is git.

Re: An update on GitHub availability

#220

Post by mperham »

icy wrote: post #190
PunchyHamster wrote: post #169

Earlier quoted context omitted.

It's cute idea but most people don't want to host their own stuff. And if they are using 3rd parties to host their stuff, inevitable 1-3 big players will show up offering that as a service. And even if you do host your own stuff to avoid availability problems, the big actors can still fail just like GH and you can't do shit coz your dependencies need it. So the solution is same as it is now, proxy or mirror everythin…

Yeah that's fine, we offer first-party hosting for free forever.

> we offer first-party hosting for free forever.

You should probably stop promising this.

Post reply on HN