4 ms·

If the divide is ruby 1.8 and 1.9, Debian packages both, and they can be installed simultaneously. If it's more arcane than that, it sounds like kvm or lxc is

by alrs 13y ago

If the divide is ruby 1.8 and 1.9, Debian packages both, and they can be installed simultaneously. If it's more arcane than that, it sounds like kvm or lxc is the answer. If you really really need to run two pieces of software with differing ruby interpreters on the same machine, then your real problem is technical debt. One fix would be to update the ancient software so that it can use modern Ruby. Another fix would be to re-architect the solution so that the greater system could operate across multiple OS instances. The least attractive option would be to use packaged Ruby for the modern stuff, and a hand-compiled Ruby for the legacy stuff.

joevandyk 13y ago
If you really really need to run two pieces of software with differing ruby interpreters on the same machine, then your real problem is technical debt. Why? Why can't you have a stable app using Ruby 1.9 that hasn't need any updates (other than security) in three years running on the same machine that also runs another newer application which uses Ruby 2.0 and Rails 4? To me, that's not "technical debt".
- regularfry 13y ago
  Maybe "wasting asset" is a better metaphor. At some point, there'll come an OS release on which that Ruby won't even build (and this can happen sooner than you'd think - 1.8.7 needs to be patched to build on Wheezy, for instance; by the time Jessie goes stable 1.9.3 will probably have been deprecated and unsupported too). At that point, you're forced into porting to a newer Ruby just so you can keep up with security patches to the underlying OS. It might not be "technical debt" per se, but it's definitely a maintenance cost.
otterley 13y ago
kvm or lxc are interesting, but that seems like attacking a fly with a sledgehammer, and it's hardly cost-free in terms of monitoring, maintenance and resource economization. Why bother with virtualization when setting path-related environment variables is sufficient?
- joevandyk 13y ago
  What happens when app 1 has been tested against libxml 2.7 and app 2 needs libxml 2.8? I wouldn't want to worry about dynamic library loading flags.
  - irahul 13y ago
    I would actually worry about LDPATH first before trying lxc.

by alrs 13y ago

joevandyk 13y ago

If you really really need to run two pieces of software with differing ruby interpreters on the same machine, then your real problem is technical debt. Why? Why can't you have a stable app using Ruby 1.9 that hasn't need any updates (other than security) in three years running on the same machine that also runs another newer application which uses Ruby 2.0 and Rails 4? To me, that's not "technical debt".

regularfry 13y ago
Maybe "wasting asset" is a better metaphor. At some point, there'll come an OS release on which that Ruby won't even build (and this can happen sooner than you'd think - 1.8.7 needs to be patched to build on Wheezy, for instance; by the time Jessie goes stable 1.9.3 will probably have been deprecated and unsupported too). At that point, you're forced into porting to a newer Ruby just so you can keep up with security patches to the underlying OS. It might not be "technical debt" per se, but it's definitely a maintenance cost.

otterley 13y ago

kvm or lxc are interesting, but that seems like attacking a fly with a sledgehammer, and it's hardly cost-free in terms of monitoring, maintenance and resource economization. Why bother with virtualization when setting path-related environment variables is sufficient?

joevandyk 13y ago
What happens when app 1 has been tested against libxml 2.7 and app 2 needs libxml 2.8? I wouldn't want to worry about dynamic library loading flags.
- irahul 13y ago
  I would actually worry about LDPATH first before trying lxc.