HN Explorer

RVM Is Down

2 points by jyaker ↗ HN
According to a WHOIS search, the domain registration for RVM.io expired yesterday.

Anyone have any tips on a fallback script that will make graceful degredation of RVM services possible with the cached site of rvm_io.global.ssl.fastly.net?

6 comments

[ 4.3 ms ] story [ 18.1 ms ] thread
dozzie
Oh, look, suddenly depending on plenty of random people's services, as usually Ruby crowd does, is a bad idea!

I normally install everything from APT or Yum repository, including things that are not prepared by distributions I use.

jyaker
That's a complete straw-man argument. Both APT and YUM can, and do, suffer from outages.

I know I've gotten plenty of "temporary failure resolving..." issues when trying to work with APT repos.

dozzie
Of course they can, but if you use official repositories and your own repositories, outages of the former don't affect you much because of mirrors, and outages of the latter you control.

It just happens that I almost never see people keeping their own replicas of RVM and gems repositories.

Edit: I only now realized I've omitted important part in my first comment: non-official Yum/APT repositories I use are my (my team's) own.

jyaker
That actually makes your point even more of a Straw-Man.

It's non-trivial for most teams to setup personally managed dependencies for their dependencies (e.g., cvs, package management, etc.).

Maybe it's just my experience, but outside of the enterprise realm, I generally don't see that sort of thing.

dozzie
I don't quite see your point here. That most of the programmers can't create Yum or APT repository? Or can't setup VCS server?

> Maybe it's just my experience, but outside of the enterprise realm, I generally don't see that sort of thing.

Most programmers are more interested in jumping into every new sexy library that just happened to appear than to make their working environment reproducible, robust, and controllable. That's why they don't think of how to package their code for installation and deployment, don't think where and how to keep their dependencies (not thinking about dependencies causes explosion of dependency fractal, which is a collateral damage), don't think how to work off-line, and so on.