Live data from Hacker News

We are investigating reports of degraded performance

githubstatus.com

91–100 of 152 posts

Re: We are investigating reports of degraded performance

#91

Earlier quoted context omitted.

- 'one more step away from a corporate-controlled internet" Downvote me to grey-world if you like, but I think everyone's crazy to put all their code infrastructure in the hands of fucking Microsoft . Especially literal free open-source software. Who do you think Microsoft is? What do you know of Microsoft's history and their core values (they're "embrace, extinguish & exsanguinate"). It's like giving fucking Sauron…

What exactly is the risk? That they'll stop providing the services they sell today? The design of git makes switching to another primary remote very easy (granted, most users probably don't have good habits around backing up data from Issues/Wiki/Releases and risk losing that data if it's taken away suddenly -- but the repo itself is durable and portable on a whim.

> (granted, most users probably don't have good habits around backing up data from Issues/Wiki/Releases and risk losing that data if it's taken away suddenly

so it's actually very hard to switch

Re: We are investigating reports of degraded performance

#92

Earlier quoted context omitted.

- 'one more step away from a corporate-controlled internet" Downvote me to grey-world if you like, but I think everyone's crazy to put all their code infrastructure in the hands of fucking Microsoft . Especially literal free open-source software. Who do you think Microsoft is? What do you know of Microsoft's history and their core values (they're "embrace, extinguish & exsanguinate"). It's like giving fucking Sauron…

What exactly is the risk? That they'll stop providing the services they sell today? The design of git makes switching to another primary remote very easy (granted, most users probably don't have good habits around backing up data from Issues/Wiki/Releases and risk losing that data if it's taken away suddenly -- but the repo itself is durable and portable on a whim.

I think the risk is the extensions that github adds to git like CI/CD and issue tracking features.

Re: We are investigating reports of degraded performance

#93
post #76

Earlier quoted context omitted.

I think you don't want to reveal the presence of projects by name or not -- just the name of repo could be sensitive info, potentially.

It shouldn't be on github then. At all.

Why the downvotes? If you want real security, self-host your Git repo.

Re: We are investigating reports of degraded performance

#94
post #91

Earlier quoted context omitted.

What exactly is the risk? That they'll stop providing the services they sell today? The design of git makes switching to another primary remote very easy (granted, most users probably don't have good habits around backing up data from Issues/Wiki/Releases and risk losing that data if it's taken away suddenly -- but the repo itself is durable and portable on a whim.

> (granted, most users probably don't have good habits around backing up data from Issues/Wiki/Releases and risk losing that data if it's taken away suddenly so it's actually very hard to switch

Given how common defaulting on issues is, many maintainers might view this as a feature?

Only slightly kidding.

Re: We are investigating reports of degraded performance

#96
post #68
post #43

Earlier quoted context omitted.

Problem is, this is one of 50 things that can go wrong for which you should have a robust backup plan for

It's amazing how many of these issues can be obviated by taking a step back at a given SAAS, asking can I self host this, then if you can and need redundancy to just buy two desktops and stick one in your place and another in your friends apartment in another town. With a lightweight static site, a modern desktop is probably more than powerful enough to deal with most any load you might realistically see for your giv…

So how do you keep data synced between them in a manner that ensures the data is safe? Now you're playing security sysadmin, and you're playing backup administrator, and your playing hardware admin (did you use 2 SSDs bought at the same time?).

You don't ever escape the payment cost of the issues of keeping these systems running. You're paying staff to do it, you're paying a cloud provider to do this, or you're paying out of your own time.

Re: We are investigating reports of degraded performance

#97
post #5

Github is becoming too important. A routine backup system is needed, something like archive.org, that backs up important Github projects.

I know this a greybeard's fantasy and that most people working today were trained not to bother, but: important things should not have GitHub as a failure point . Hobby projects and today's work? Sure. Point straight at GitHub and hack away. And when it goes down, get yourself a coffee. But everything that's anywhere near production should have already pointed those github requests to a mirror or other tool in your o…

It's not entirely clear to me whether you're talking about using GitHub for your own production tooling, or as a source for some arbitraty third party component. If it's the latter, then I completely agree with you. Use a read-through proxying package repository. I don't care if you run it yourself or if you pay a provider, but don't pull stuff from the origin every time you build.

In the general case, adoping an external system will bring with it greater reliability than trying to run stuff oneself. The differences are that you don't get to choose your maintenance windows, and you can't do anything to fix it yourself.

Take care about who you pick, and own the depencency, because you've put a part of your own reputation in the hands of your provider.

Now, if you pick GitHub as a part of your controlled ecosystem -- which is totally reasonable, if it fits your use-case -- then you still shouldn't be pulling arbitrary stuff from places outwith your control. GitHub has package repository tooling that you can use :). Although it's not entirely clear to me that it's as suitable for third-party dependencies as tools like Artifactory or Nexus.

Re: We are investigating reports of degraded performance

#99
post #16
post #12

Earlier quoted context omitted.

In theory, the code is there, but putting a project back together in a hurry after trouble at Github is non-trivial. Especially if the build process uses proprietary stuff such as "GitHub actions". The issues and discussions are all Github-only, too.

It’s crazy that there is no common CI spec. Every single platform is completely different. Last time I tried Act it had some pretty severe limitations. Perhaps I should take it for another spin.

The business case for CI vendors is at odds with a common spec.

Otherwise any customer who gets a bill for more than a few dollars will replace them with a VM and copy of Jenkins.

Re: We are investigating reports of degraded performance

#100
post #94
post #91

Earlier quoted context omitted.

> (granted, most users probably don't have good habits around backing up data from Issues/Wiki/Releases and risk losing that data if it's taken away suddenly so it's actually very hard to switch

Given how common defaulting on issues is, many maintainers might view this as a feature? Only slightly kidding.

At one of my jobs, they used Asana when I started. It was too full of backlogged issues, so we moved over to Jira. Then Jira got too full. A month before I was laid off, one of my coworkers said, "Maybe we should try out Asana."
Post reply on HN