Live data from Hacker News

GitHub: Git operation failures

githubstatus.com

241–250 of 335 posts

Re: GitHub: Git operation failures

#241

I'm becoming concerned with the rate at which major software systems seem to be failing as of late. For context, last year I only logged four outages that actually disrupted my work; this quarter alone I'm already on my fourth, all within the past few weeks. This is, of course, just an anecdote and not evidence of any wider trend (not to mention that I might not have even logged everything last year), but it was enou…

It's money, of course. No one wants to pay for resilience/redundancy. I've launched over a dozen projects going back to 2008, clients simply refuse to pay for it, and you can't force them. They'd rather pinch their pennies, roll the dice and pray.

Re: GitHub: Git operation failures

#242
post #234

Earlier quoted context omitted.

Uptime is much, much easier at low scale than at high scale. The reason for buying centralized cloud solutions is not uptime, it's to safe the headache of developing and maintaining the thing.

My reason for centralized cloud solutions is also uptime. Multi-AZ RDS is 100% higher availability than me managing something.

Well, just a few weeks ago we weren't able to connect to RDS for several hours. That's way more downtime than we ever had at the company I worked for 10 years ago, where the DB was just running on a computer in the basement.

Anecdotal, but ¯\_(ツ)_/¯

Re: GitHub: Git operation failures

#243

I'm becoming concerned with the rate at which major software systems seem to be failing as of late. For context, last year I only logged four outages that actually disrupted my work; this quarter alone I'm already on my fourth, all within the past few weeks. This is, of course, just an anecdote and not evidence of any wider trend (not to mention that I might not have even logged everything last year), but it was enou…

To be deliberately provocative, LLMs are being more and more widely used.

Re: GitHub: Git operation failures

#244
post #233

Earlier quoted context omitted.

You've ruined something for me. My adult side is grateful but the rest of me is throwing a tantrum right now. I hope you're happy with what you've done.

I read a book about elevators accidents; don't.

elevators accidents or escalator accidents?

Re: GitHub: Git operation failures

#245
post #182

Earlier quoted context omitted.

> Repositories are replicated across peers in a decentralized manner You lost me there

"Replicated across peers in a decentralized manner" could just as easily be written about regular Git. Radicle just seems to add a peer-to-peer protocol on top that makes it less annoying to distribute a repository. So I don't get why the project has "lost you", but I also suspect you're the kind of person any project could readily afford to lose as a user.

What this is trying to say: - "peers": participants in the network are peers, i.e. both ends of a connection run the same code, in contrast to a client-and-server architecture, where both sides often run pretty different code. To exemplify: The code GitHub's servers run is very different from the code that your IDE with Git integration runs. - "replicated across peers": the Git objects in the repository, and "social artifacts" like discussions in issues and revisions in patches, is copied to other peers. This copy is kept up to date by doing Git fetches for you in the background. - "in a decentralized manner": Every peer/node in the network gets to locally decide which repositories they intend to replicate, i.e. you can talk to your friends and replicate their cool projects. And when you first initialize a repository, you can decide to make it public (which allows everyone to replicate it), or private (which allows a select list of nodes identified by their public key to replicate). There's no centralized authority which may tell you which repositories to replicate or not.

I do realize that we're trying to pack quite a bit of information in this sentence/tagline. I think it's reasonably well phrased, but for the uninitiated might require some "unpacking" on their end.

If we "lost you" on that tagline, and my explanation or that of hungariantoast (which is correct as well) helped you understand, I would appreciate if you could criticize more constructively and suggest a better way to introduce these features in a similarly dense tagline, or say what else you would think is a meaningful but short explanation of the project. If you don't care to do that, that's okay, but Radicle won't be able to improve just based on "you lost me there".

In case you actually understood the sentence just fine and we "lost you" for some other reason, I would appreciate if you could elaborate on the reason.

Re: GitHub: Git operation failures

#246

I'm becoming concerned with the rate at which major software systems seem to be failing as of late. For context, last year I only logged four outages that actually disrupted my work; this quarter alone I'm already on my fourth, all within the past few weeks. This is, of course, just an anecdote and not evidence of any wider trend (not to mention that I might not have even logged everything last year), but it was enou…

To be deliberately provocative, LLMs are being more and more widely used.

imagine what it'll be like in 10 years time

Microsoft: the film Idiocracy was not supposed to be a manual

Re: GitHub: Git operation failures

#247
post #87

Good thing git was designed as a decentralized revision control system, so you don’t really need GitHub. It’s just a nice convenience

This escalator is temporarily stairs, sorry for the convenience.

Not really comparable at any compliance or security oriented business. You can't just zip the thing up and sftp it over to the server. All the zany supply chain security stuff needs to happen in CI and not be done by a human or we fail our dozens of audits

Re: GitHub: Git operation failures

#248

I'm becoming concerned with the rate at which major software systems seem to be failing as of late. For context, last year I only logged four outages that actually disrupted my work; this quarter alone I'm already on my fourth, all within the past few weeks. This is, of course, just an anecdote and not evidence of any wider trend (not to mention that I might not have even logged everything last year), but it was enou…

It's money, of course. No one wants to pay for resilience/redundancy. I've launched over a dozen projects going back to 2008, clients simply refuse to pay for it, and you can't force them. They'd rather pinch their pennies, roll the dice and pray.

I agree that it's all money.

That's why it's always DNS right?

> No one wants to pay for resilience/redundancy

These companies do take it seriously, on the software side, but when it comes to configurations, what are you going to do:

Either play it by ear, or literally double your cloud costs for a true, real prod-parallel to mitigate that risk. It looks like even the most critical and prestigious companies in the world are doing the former.

Re: GitHub: Git operation failures

#249

I'm becoming concerned with the rate at which major software systems seem to be failing as of late. For context, last year I only logged four outages that actually disrupted my work; this quarter alone I'm already on my fourth, all within the past few weeks. This is, of course, just an anecdote and not evidence of any wider trend (not to mention that I might not have even logged everything last year), but it was enou…

It's money, of course. No one wants to pay for resilience/redundancy. I've launched over a dozen projects going back to 2008, clients simply refuse to pay for it, and you can't force them. They'd rather pinch their pennies, roll the dice and pray.

Why should they? Honestly most of what we do simply does not matter that much. 99.9% uptime is fine in 99.999% of cases.

Re: GitHub: Git operation failures

#250

Earlier quoted context omitted.

This escalator is temporarily stairs, sorry for the convenience.

Not really comparable at any compliance or security oriented business. You can't just zip the thing up and sftp it over to the server. All the zany supply chain security stuff needs to happen in CI and not be done by a human or we fail our dozens of audits

Why is it that we trust those zany processes more than each other again? Seems like a good place to inject vulnerabilities to me...
Post reply on HN