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

Update on 1/28 service outage

github.com

Post reply on HN
Print view View original

91–100 of 193 posts

Re: Update on 1/28 service outage

#91

Post by kbenson »

nickpsecurity wrote: post #72
debaserab2 wrote: post #65

Earlier quoted context omitted.

git != github

Hence Git/Github in my comment. I already know there's a difference. I just don't know much more than that until I learn the two.

Github is to git as Sourceforge is (used to be) to subversion, but with a better UI.

And yes, there have been concerns raised about what would happen if Github took a turn like Sourceforge, which usually get brought up when information about new shady practices at Sourceforge come up (or they get rehashed here).

Re: Update on 1/28 service outage

#92

Post by seiji »

hguant wrote: post #86
seiji wrote: post #75

Earlier quoted context omitted.

if you dig far enough, you can find some dependency of a dependency of dependency that relies on GitHub. Brew/npm/build script/whatever But really, why? Is it just institutional laziness on the part of all developers? We had reliable rsync CPAN mirrors in 1995. In the early days of the Internet, companies would mutually host secondary DNS for each other to be more reliable. For some reason, we've forgotten all about…

I think a large part of this is that cloud hosting has allowed us to abstract those problems - reliability, disaster recovery, geographical distribution - away, and we don't really think of computers as computers anymore. It's a service or a platform or what have you, and the expectation is that it will always be there. I wouldn't say this is laziness, just a byproduct of changing how we view Internet architecture. W…

Exactly right, but over the past six years there's been a strong (and accelerating) trend among developers of "lalala we don't want to know how anything works! give us an API and go away."

Most developers I've seen reject even learning about networks or DNS or operating systems or databases. Such willful ignorance boggles the mind, but they are praised because their goals are shipping half-broken things as rapidly as possible to flip upwards for those oh-so-tasty acquihire payouts.

We even saw this week how overconsumption of convenience APIs can put entire companies in danger when those privately controlled convenience APIs just decide to shut down one day. Convenience of immediacy always seems to trump connivence of long term stability.

Re: Update on 1/28 service outage

#93

Post by ajkjk »

nickpsecurity wrote: post #76
ajkjk wrote: post #69

Earlier quoted context omitted.

I'm sorry to be rude, but, it sounds like you should go learn Git and come back to this conversation. The decentralized design does avoid single points of failures, and everyone does have a copy. So - check, check, great. Unfortunately (maybe..) everyone has put their master repos in the same place, which somewhat counteracts the decentralization. But there is certainly no immediate coupling between the Git repositor…

"I'm sorry to be rude, but, it sounds like you should go learn Git and come back to this conversation." It looks like it. "The decentralized design does avoid single points of failures, and everyone does have a copy. " So, like many decentralized systems I've used, a master node gets worked around by other nodes who communicate in another way? Or would some retarded situation be possible where... "Unfortunately (mayb…

No, it's not the same as a distributed system with master/slave nodes. The child nodes can function entirely in isolation from the parent. If you wanted to, you could treat another coworker's node as your master and download/upload to that. It's usually easier to have a tree structure where the root is your master repo, its children are your build servers or whatever, and the leaves are development machines. But that's entirely reconfigurable.

It's not surprising at all that if you make a master repo at the root of the tree, and it goes down, then you can't communicate it. But it doesn't prohibit any communication between other nodes, or re-wiring the tree, and it definitely doesn't inherently block development work on any of the other nodes.

It just so happens, though, that people's build scripts and package managers like to refresh packages from the root and don't handle failures modes of that operation very well. That's the only place problems emerge - besides the obvious fact that if your public releases of software go through the root, and the root is down, then you can't release until it's up. But you could easily make a new root if you wanted to.

Re: Update on 1/28 service outage

#94

Post by Zelmor »

hguant wrote: post #86
seiji wrote: post #75

Earlier quoted context omitted.

if you dig far enough, you can find some dependency of a dependency of dependency that relies on GitHub. Brew/npm/build script/whatever But really, why? Is it just institutional laziness on the part of all developers? We had reliable rsync CPAN mirrors in 1995. In the early days of the Internet, companies would mutually host secondary DNS for each other to be more reliable. For some reason, we've forgotten all about…

I think a large part of this is that cloud hosting has allowed us to abstract those problems - reliability, disaster recovery, geographical distribution - away, and we don't really think of computers as computers anymore. It's a service or a platform or what have you, and the expectation is that it will always be there. I wouldn't say this is laziness, just a byproduct of changing how we view Internet architecture. W…

One has to keep in mind that there is no cloud. It's just someone else's computer.

Re: Update on 1/28 service outage

#95

Post by kbenson »

seiji wrote: post #66
raverbashing wrote: post #28

Earlier quoted context omitted.

Have a local repos that mirrors the master one on GitHub periodically Should that fail, start working on the local repos until github is back, then sync back to it

Why is the master on GitHub anyway? If a company can't maintain their own internal tools and self-hosting servers, why does the same company think it can run reliable services for users? Not putting the core of your business on a remote platform is disaster mitigation 101.

Why use AWS, GCE or any other virtualization provider? I suspect for some subset of companies the answer is the same.

Relying on Github is not the problem, relying on Github to be available 24/7 is. Github provides a free master node for your eventually consistent database needs, where the database is git. The eventual portion is key here.

Re: Update on 1/28 service outage

#96

Post by nickpsecurity »

jakobegger wrote: post #85
jacquesm wrote: post #64

Earlier quoted context omitted.

I doubt it matters to anybody but was it really necessary to kill the fish?

Watch it until the end :)

Haha nice catch. I missed it originally thinking it would just be more marketing crap. So, they probably just moved it before detonating. Not sadistic bastards after all.

Re: Update on 1/28 service outage

#97

Post by jacquesm »

jakobegger wrote: post #85
jacquesm wrote: post #64

Earlier quoted context omitted.

I doubt it matters to anybody but was it really necessary to kill the fish?

Watch it until the end :)

I did, but unless the whole video was a fake it doesn't really matter does it? And if it is then that does not reflect well on HP either...

Re: Update on 1/28 service outage

#98

Post by nickpsecurity »

ajkjk wrote: post #93
nickpsecurity wrote: post #76

Earlier quoted context omitted.

"I'm sorry to be rude, but, it sounds like you should go learn Git and come back to this conversation." It looks like it. "The decentralized design does avoid single points of failures, and everyone does have a copy. " So, like many decentralized systems I've used, a master node gets worked around by other nodes who communicate in another way? Or would some retarded situation be possible where... "Unfortunately (mayb…

No, it's not the same as a distributed system with master/slave nodes. The child nodes can function entirely in isolation from the parent. If you wanted to, you could treat another coworker's node as your master and download/upload to that. It's usually easier to have a tree structure where the root is your master repo, its children are your build servers or whatever, and the leaves are development machines. But that…

"It just so happens, though, that people's build scripts and package managers like to refresh packages from the root and don't handle failures modes of that operation very well. "

That's the critical part. So, countering this risk is apparently a manual thing if one uses off-the-shelf tooling for Git. I'll just have to remember to look at that if I do a deployment. Put it on a checklist or something.

Re: Update on 1/28 service outage

#99

Post by jacquesm »

nickpsecurity wrote: post #96
jakobegger wrote: post #85

Earlier quoted context omitted.

Watch it until the end :)

Haha nice catch. I missed it originally thinking it would just be more marketing crap. So, they probably just moved it before detonating. Not sadistic bastards after all.

Watch 'The Prestige'.

Re: Update on 1/28 service outage

#100

Post by tatterdemalion »

rms_returns wrote: post #70
viperscape wrote: post #50

Earlier quoted context omitted.

The package system for the rust language actually relies on github, as many found out during outage. I don't know if that will change, probably will with a read copy in a different git service.. but I thought it was interesting because I use github for everything save a few private projects, as I imagine most do. I'm not sure what to think of this, it seems backwards and grossly incompetent, yet here we are using it…

Not just rust language, to the best of my knowledge, even packagist, the php package manager relies heavily on github for sourcing its packages. But I think they have other resources too, apart from github.

Rust's package manager doesn't source packages from GitHub (though it will pull packages from a git repo if you ask it to), the source for its index of packages is a git repository on GitHub. https://github.com/rust-lang/crates.io-index
Post reply on HN