3 ms·

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 sor

by alrs 13y ago

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.

kawsper 13y ago
> 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.
joevandyk 13y ago
Building a package wouldn't fix the bug. The ruby binary in the package would contain the same problematic compile-time option.
- alrs 13y ago
  It absolutely would. You change the compile-time option and build the package with that change.
  - joevandyk 13y ago
    Right, so the ruby binary inside the package that you just built would contain the bug caused by that particular compile-time option.
    - alrs 13y ago
      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.

by alrs 13y ago

kawsper 13y ago

> 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.

joevandyk 13y ago

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

alrs 13y ago
It absolutely would. You change the compile-time option and build the package with that change.
- joevandyk 13y ago
  Right, so the ruby binary inside the package that you just built would contain the bug caused by that particular compile-time option.
  - alrs 13y ago
    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.