Live data from Hacker News

"Major service outage"

status.github.com

51–60 of 60 posts

Re: "Major service outage"

#51
post #25
post #21

Earlier quoted context omitted.

The beauty of decentralized version control is a node going down doesn't kill your workflow. In a pinch, you could use git bundle to exchange commits with other developers: http://git-scm.com/2010/03/10/bundles.html

Unless you need to run a bundle install (or npm install, or whatever) and have github urls in your Gemfile.

Yeah, don't do that. As a scala/maven guy it kills me to see all these package managers making the same mistakes we already solved, over and over again.

Re: "Major service outage"

#52
post #51
post #25

Earlier quoted context omitted.

Unless you need to run a bundle install (or npm install, or whatever) and have github urls in your Gemfile.

Yeah, don't do that. As a scala/maven guy it kills me to see all these package managers making the same mistakes we already solved, over and over again.

Why not?

Re: "Major service outage"

#53
post #52
post #51

Earlier quoted context omitted.

Yeah, don't do that. As a scala/maven guy it kills me to see all these package managers making the same mistakes we already solved, over and over again.

Why not?

Because it's tying you to an unreliable third-party service, and there's no way to mitigate it. Artifact dependencies really shouldn't be in the same place as source, they fulfil different roles.

What you want is a dedicated repository format. Libraries can still be hosted by whoever maintains them on their own repository (which can be their own piece of software as long as it follows the standards), or in the community central repository. But either way, if you depend on those libraries and want to lower your risks, it's trivial to set up a local mirror and make sure all your third party dependencies come in via this mirror. That way if their repository goes down temporarily or permanently it's no problem, and you ensure your builds remain reproducible.

The most infuriating part is, the software to do this already exists. If you want to start a new language, great. But please, use maven; otherwise you are doomed to re-invent it, poorly.

Re: "Major service outage"

#54
post #41

Earlier quoted context omitted.

Incorrect: https://github.com/blog/493-github-is-moving-to-rackspace

My favourite line from that linked blog post from 2009 is this: "We're aware of the current stability and performance issues, and we want to let you know what we're doing about it." - issues they were having nearly 4 years ago are still happening unless the problems they've faced lately are completely different.

I understand when my non-technical clients ask questions like, "I thought we fixed X?" or "shouldn't Y have been fixed by now?", but I would have hoped that fellow developers would cut each other some more slack, you know?

There are an infinite number of reasons an app could fail at any given moment. Just because we see the same "something went wrong" page 4 years later doesn't mean we're seeing the same problem, or even the same class of problem. It just means that the sun still rose in the east this morning, my stupid car will probably have something new wrong with it when I leave my apartment in a few hours, and software is still really, really complex.

The GitHub team is a smart bunch. I highly doubt they're still dealing with the same class of issues that plagued them four years ago, and it just seems kinda strange to even bring it up.

Re: "Major service outage"

#56
post #53
post #52

Earlier quoted context omitted.

Why not?

Because it's tying you to an unreliable third-party service, and there's no way to mitigate it. Artifact dependencies really shouldn't be in the same place as source, they fulfil different roles. What you want is a dedicated repository format. Libraries can still be hosted by whoever maintains them on their own repository (which can be their own piece of software as long as it follows the standards), or in the commun…

[deleted]

Re: "Major service outage"

#57
post #53
post #52

Earlier quoted context omitted.

Why not?

Because it's tying you to an unreliable third-party service, and there's no way to mitigate it. Artifact dependencies really shouldn't be in the same place as source, they fulfil different roles. What you want is a dedicated repository format. Libraries can still be hosted by whoever maintains them on their own repository (which can be their own piece of software as long as it follows the standards), or in the commun…

I disagree completely and vehemently.

Because it's tying you to an unreliable third-party service, and there's no way to mitigate it.

> Sure GitHub has been having some problems recently, but they are all-in-all massively reliable.

> Artifact dependencies really shouldn't be in the same place as source, they fulfil different roles.

Seems like a dogmatic point - why is this advantageous?

More importantly, there is a reason people do this - they want a zero-effort way to use certain branches, tags, etc. They want source.

>What you want is a dedicated repository format.

Again, seems dogmatic. What advantage does one format have over the other.

> in the community central repository

and now we have single point of failure again, but I also have to wait for someone to either upload, or set up an automated solution to upload, the version I want. There's a reason people use the source for this.

> it's trivial to set up a local mirror and make sure all your third party dependencies come in via this mirror

Nightmare. We actually do do this - we maintain a nexus instance on EC2. Its a fairly awful experience. We wouldn't use it if there was a way in leiningen to use git, and if maven wasn't so slow at getting dependencies.

> That way if their repository goes down temporarily or permanently it's no problem, and you ensure your builds remain reproducible.

Definitely a real problem. But there are real tradeoffs here.

> The most infuriating part is, the software to do this already exists. If you want to start a new language, great. But please, use maven; otherwise you are doomed to re-invent it, poorly.

I use maven on a daily basis. Its not great to be honest, and comes with a massive amount of baggage, including the SNAPSHOT stuff which is awful, and a lot of things tied to java. Rubygems are a significantly better experience, are a lot more usable, and have some really good features like being able to use Github links :)

Re: "Major service outage"

#58
post #57
post #53

Earlier quoted context omitted.

Because it's tying you to an unreliable third-party service, and there's no way to mitigate it. Artifact dependencies really shouldn't be in the same place as source, they fulfil different roles. What you want is a dedicated repository format. Libraries can still be hosted by whoever maintains them on their own repository (which can be their own piece of software as long as it follows the standards), or in the commun…

I disagree completely and vehemently. Because it's tying you to an unreliable third-party service, and there's no way to mitigate it. > Sure GitHub has been having some problems recently, but they are all-in-all massively reliable. > Artifact dependencies really shouldn't be in the same place as source, they fulfil different roles. Seems like a dogmatic point - why is this advantageous? More importantly, there is a r…

> Sure GitHub has been having some problems recently, but they are all-in-all massively reliable.

Meh. They've been down more often and for longer than my local nexus. Sometimes it's worth depending on a third-party service, if the benefits outweigh the cost - but there certainly is a cost.

>I also have to wait for someone to either upload, or set up an automated solution to upload, the version I want.

This should be cheap and easy; I think a lot of people misunderstand the point of maven releases - they're not meant to correspond 1:1 to your public "releases", they're for any case where you need a stable, reproducible build.

And do you really want to depend on some random development revision of a given library? Maybe there's a different community norm for Ruby, but if you tried that on one of my projects odds are it wouldn't even compile.

>Nightmare. We actually do do this - we maintain a nexus instance on EC2. Its a fairly awful experience.

Really? My experience is that Nexus is one of the simplest things to run that there is - just run the jar and... yeah, that's pretty much it. What problems have you had? (It's not that I don't believe you, I'm just surprised, and maybe they're things I should be watching out for myself).

>the SNAPSHOT stuff which is awful, and a lot of things tied to java.

It is quite tied to Java (I use it with pure scala but I guess that's similar). What's wrong with the approach to SNAPSHOTs?

Re: "Major service outage"

#59
post #58
post #57

Earlier quoted context omitted.

I disagree completely and vehemently. Because it's tying you to an unreliable third-party service, and there's no way to mitigate it. > Sure GitHub has been having some problems recently, but they are all-in-all massively reliable. > Artifact dependencies really shouldn't be in the same place as source, they fulfil different roles. Seems like a dogmatic point - why is this advantageous? More importantly, there is a r…

> Sure GitHub has been having some problems recently, but they are all-in-all massively reliable. Meh. They've been down more often and for longer than my local nexus. Sometimes it's worth depending on a third-party service, if the benefits outweigh the cost - but there certainly is a cost. >I also have to wait for someone to either upload, or set up an automated solution to upload, the version I want. This should be…

> but there certainly is a cost.

Agreed, but don't pretend there isn't a cost to maven. You need to maintain your own nexus server. You rely on others to do things which - though "cheap and easy" - are not going to be done by 99% of people out there.

> do you really want to depend on some random development revision of a given library

You can also depend on a particular branch or tag, which people already do. Now adding a tag in git is equivalent to publishing a versioned library! Magic!

> My experience is that Nexus is one of the simplest things to run that there is

I find the software complex and difficult to use. All I want to do is use my own jar with my own project, and I have to wade through an unintuitive, difficult to use, edge-case ridden web app that I have to maintain myself? Honestly, this has been the worse part of my clojure experience (learning emacs was less painful and more rewarding).

> What's wrong with the approach to SNAPSHOTs

Maven - if I understand this correctly and I would not be surprised if there was some arcana which prevents me from doing so - expects each version to immutable. So when SNAPSHOTs change, I end up deleting my .m2 directory to figure it out.

But even if this were somehow good, why would people use maven for Ruby? They're different languages, ecosystems, etc. It doesn't even make any sense.

Re: "Major service outage"

#60
post #59
post #58

Earlier quoted context omitted.

> Sure GitHub has been having some problems recently, but they are all-in-all massively reliable. Meh. They've been down more often and for longer than my local nexus. Sometimes it's worth depending on a third-party service, if the benefits outweigh the cost - but there certainly is a cost. >I also have to wait for someone to either upload, or set up an automated solution to upload, the version I want. This should be…

> but there certainly is a cost. Agreed, but don't pretend there isn't a cost to maven. You need to maintain your own nexus server. You rely on others to do things which - though "cheap and easy" - are not going to be done by 99% of people out there. > do you really want to depend on some random development revision of a given library You can also depend on a particular branch or tag, which people already do. Now add…

>You need to maintain your own nexus server.

You don't need to maintain your own if you don't want to; you can fetch from remote repositories (and unless you're using something esoteric you only need to use one, all major libraries are in central).

>You rely on others to do things which - though "cheap and easy" - are not going to be done by 99% of people out there.

It takes the whole community committing to it, but 99% of Java people will make maven releases for any build they intend for public consumption.

>You can also depend on a particular branch or tag, which people already do. Now adding a tag in git is equivalent to publishing a versioned library! Magic!

Few things in software are worse than magic. I guess I'm advocating a little friction here, just for the sake of safety; it works better if people take make an easy but explicit choice that some builds are for others to use and some builds are not. Again I guess that's a matter of community norms.

>I find the software complex and difficult to use. All I want to do is use my own jar with my own project, and I have to wade through an unintuitive, difficult to use, edge-case ridden web app that I have to maintain myself?

Like with hosting or version control or anything, you will probably want to host your own sooner or later, but you can start off by using someone else's. And FWIW I have an opposite view on the UI, though without concrete examples there's probably no point talking further.

>Maven - if I understand this correctly and I would not be surprised if there was some arcana which prevents me from doing so - expects each version to immutable. So when SNAPSHOTs change, I end up deleting my .m2 directory to figure it out.

I don't know what you were doing wrong, but that's not a normal problem. When you build something that depends on a snapshot maven will by default refetch it if it hasn't for a certain time; if you use -U it will always refetch it, if you're using offline mode it will always use your local copy.

>But even if this were somehow good, why would people use maven for Ruby? They're different languages, ecosystems, etc. It doesn't even make any sense.

Maven is very flexible and plugin-based, and a lot of things e.g. the repository, the release process, various plugins could work the same. Obviously it would only work if a whole language ecosystem adopted it, it's probably too late for Ruby.

Post reply on HN