Comment by 3pt14159 | Hacker News Reader

Comment by 3pt14159 | Hacker News Reader

Parent Full thread

I used to agree with you. Why would you take a 20 or 30 percent performance hit when you are busy shelling out tens of thousands for hardware load balancers.

Then one day a rare instruction set on our colocated server (so not something super standard like linode) was specified during the compilation step of ruby and (due to an extremely subtle co-bug between ruby and the compiler). It took us fucking weeks to find this hisenbug that was somehow causing workers to drop, but only during times of very high load.

Probably lost $500k worth of customers, dev time, and company moral.

Now I have a different view. Keep things as simple and as "normal" as possible. That way you can always upgrade to the next version, you don't hit weird bugs when you libraries assume that Time.now is second-accurate, instead of sub-second accurate (MRI vs Enterprise Ruby).

RVM is made for production (http://stackoverflow.com/a/6282260/384700) and it saves a lot of headaches to just go with the flow. As for mac dev, I agree that it is a waste of time compared to working out of Ubuntu, but designers like photoshop and Vagrant is non-trivial for them to set up, especially for people that work on multiple projects.

Pointing to the author's declaration that "rvm was made for production" is not exactly the best evidence of such, especially in light of mine and my colleagues' endless hours trying to figure out how to fit it into a non-interactive-shell environment.

I have had similar experiences with rvm in production environments.

chruby (probably also rbenv, haven't used it) is easier to understand and trivial to set up with non-interactive shells.

I've had similar problems with RVM. Ultimately I used the system-wide RVM installation and this chunk of code:

  export PATH=$PATH:/usr/local/rvm/bin/rvm
  . /usr/local/rvm/scripts/rvm
  . $REPO/.rvmrc
  . $(rvm jruby-$JRUBY_VERSION do rvm env --path)
  cd $REPO
  bundle exec torquebox deploy

Definitely not ideal and I spent a large amount of hours figuring out how to use it non-interactively. I'm still somewhat worried that some things might go wrong if some of the code I didn't write in this repo attempts to call binaries directly. Basically with bundle exec --deployment, all gems are stored in $CODE/.vendor which is necessary to allow users to install their own gems, with the root installation. Bundle exec has to be used, I messed around with RVM wrappers, but they don't work with the --deployment bundler use.

You're doing too much. All you need to do is:

  source /usr/local/rvm/environments/$BUILD

You can put it in a wrapper script if you like. It will unset all conflicting environment variables first.

The thing is that the rvmrc has the jruby version env set. So I need to load it first. And it contains an 'rvm use' which I don't want to fail. I suppose I can slim the rvmrc down to just include the environment and then all I would need to do is source the rvmrc? Thoughts?

I don't believe you need to source the rvmrc. The line I pasted above does all the necessary things that "rvm use $BUILD" would do for a shell, without all the things that require an interactive shell.

The rvmrc is part of the repo and contains the java_opts env.

I'm confused.

Simple and normal, to me, means "use packaged Ruby." Chasing the bleeding edge and compiling the interpreter at every release is exactly the sort of practice that introduces edge-case heisenbugs.

If you need a nonstandard compile-time option you go to work on the package source, make the change, put your custom package up in your private apt/yum repo, and leave things alone until the next security update comes down the pike.

Me, I consider hosting to be entirely fungible. I'd rather change vendors than mess about with custom packaging big chunks of the stack to work around weirdness.

Wherever I have encountered Phusion's REE I have ripped it out, with good results.

> Chasing the bleeding edge and compiling the interpreter at every release is exactly the sort of practice that introduces edge-case heisenbugs.

I think most people that uses rbenv or RVM in production is only compiling new versions if the specified version isn't there already.

Building a package wouldn't fix the bug. The ruby binary in the package would contain the same problematic compile-time option.

It absolutely would. You change the compile-time option and build the package with that change.

Right, so the ruby binary inside the package that you just built would contain the bug caused by that particular compile-time option.

I want to be sure that we're on the same page.

No.

3pt14159 said that he used to use distro-packaged Ruby, but stopped because his distro used a compile-time option that didn't play well with his vendor's hardware.

3pt14159's solution was to start using rvm on production boxes.

I think that is a bad idea, and that either:

1. 3pt14159 should just pull down the package source, change the compile time option, rebuild the package, and use the mildly customized package in production.

2. 3pt14159 should not waste time working around hardware weirdness, and just switch to a vendor that doesn't have these problems.

You shouldn't necessarily be compiling ruby on your server anyways you should be using a package (rpm, deb) to install it. Especially if you are losing $500k because you decided to compile ruby on your production server.

One of the challenges of running a production application based on Ruby is the fact that relying on distro packages will fail miserably. Rubygems, in particular, does not work well with distro installed Ruby interpreters.

I was talking about creating your own packages.

Ah, I re-read your comment in an entirely different light now, and I agree that packaging your own deps is a great way to avoid surprises when you roll your infrastructure.

I use ruby-install to build precompiled MRI packages. I'd be very interested to know if that might have avoided your problem.

Reply on news.ycombinator.com