7 ms·

Next Generation Ruby packages for Ubuntu

47 points by comice 15y ago

perlpimp 15y ago
Thought 1.9.3 is not very favorable for Rails deployment or am I wrong?
- judofyr 15y ago
  1.9.3 is stable and fine for deployment.
- InfernalH 15y ago
  Already in production for months, no particular problems
- bradleyland 15y ago
  1.8.7 remains popular, but is declining, and for good reason. While there are some areas where 1.9 branches gave up ground (I'm looking at you `require` [1]), there are other areas where it absolutely smokes older versions; like date formatting functions [2]. Fortunately, Rails processes run for a long time under most app servers, so the performance regression of `require` isn't a huge deal. It is, however, very common to format dates as part of output, which may happen on hundres or thousands of records. There are also some nice features of 1.9 branches that are useful in a practical sense. For example, hash order is presered in Hash under 1.9, so you can get the extra features of a hash, and avoid superfulous sorting (can result in big compute savings). [1] https://github.com/bradland/require-benchmarks https://github.com/bradland/require-benchmarks [2] https://gist.github.com/1352997 https://gist.github.com/1352997
- cheald 15y ago
  1.9.3 is great for production. You give up a bit of memory savings compared to REE (since Ruby proper won't be COW-friendly until 2.0), but 1.9.3 in general is faster, has a lot more features, and is widely supported by gems and libraries now. 1.8.7 has been EOL'd, which is as good a reason as any to upgrade.
- getsat 15y ago
  You are not even remotely close to being correct.
- ef4 15y ago
  I just switched from 1.9.2 to 1.9.3 specifically because it cuts Rails startup time in half.
fingerprinter 15y ago
Color me intrigued. Would love to see someone step up and maintain Ruby again. RVM is great, but a native package is always preferable.
omarqureshi 15y ago
This looks pretty good - it's always painful installing packages from source (RVM included in that) mainly as a time + another thing I have to maintain thing. I'm not that familiar with Debian package management but would it be much work to also have these packages working on squeeze too? In which case I would most likely start using Debian a lot more.
- comice 15y ago
  They should build without much modification - it just needs a bit of effort to setup a repository and do the builds. If there is demand for it, we could look at doing it.
- obtu 15y ago
  Rebuilding the source packages should be easy enough, just loop over the .dsc urls and run dget -x; sudo mk-build-deps -i; debuild; sudo debi. pbuilder and sbuild also work for cross-builds, but I didn't get the hang of cross-building entire package graphs.
- beza1e1 15y ago
  A "backport" in Debian speak. I use this script for such things: https://gitorious.org/qznc/backporter/blobs/master/backport.sh https://gitorious.org/qznc/backporter/blobs/master/backport....
KTamas 15y ago
I'd love to see RVM/rbenv support a version of 1.9.3 with the mentioned patches.
- ryanf 15y ago
  They do. Check out https://gist.github.com/1688857 https://gist.github.com/1688857
sciurus 15y ago
Added Sokolov Yura‘s performance patches for 1.9.3 Added Narihiro Nakamura’s Lazy Sweep garbage collector (backported by Sakolov Yura) Why isn't this work a part of an official ruby release? Patched Ruby 1.9.3 to export the right symbols to work with ruby-debug Built Ruby 1.9.3 with Google’s high performance memory alloactor, tcmalloc Why aren't Debian and Ubuntu doing this already?
- comice 15y ago
  imo, I don't think Debian and Ubuntu should do this - it's not really their job. Distros should, for the most part, just be packaging upstream code and not maintaining an unofficial fork. Though counter to this, RedHat basically maintain their own fork of the Linux kernel but it's a bit of a special case, and they do employ full time kernel developers to do it!
  - sciurus 15y ago
    I was assuming use of tcmalloc was a supported option when configuring and building Ruby. If it's not, then yeah, probably not the right thing for a distro to do. If a ruby release didn't have a working debugger but this could be easily patched, then I would expect distros to do that. However, I'm not familiar enough with the ruby ecosystem to know the context of "patched Ruby 1.9.3 to export the right symbols to work with ruby-debug"
- judofyr 15y ago
  > Why isn't this work a part of an official ruby release? nobu's lazy sweep collector is in trunk. Sokolov Yura's patches have been submitted; some of the merged, others introduce slight incompatibility issues.
- bratsche 15y ago
  Debian and Ubuntu shouldn't be in the business of trying to second-guess upstreams. They should be packaging things up as they're released.
deleted 15y ago
[deleted]

47 points by comice 15y ago

perlpimp 15y ago

Thought 1.9.3 is not very favorable for Rails deployment or am I wrong?

judofyr 15y ago
1.9.3 is stable and fine for deployment.
InfernalH 15y ago
Already in production for months, no particular problems
bradleyland 15y ago
1.8.7 remains popular, but is declining, and for good reason. While there are some areas where 1.9 branches gave up ground (I'm looking at you `require` [1]), there are other areas where it absolutely smokes older versions; like date formatting functions [2]. Fortunately, Rails processes run for a long time under most app servers, so the performance regression of `require` isn't a huge deal. It is, however, very common to format dates as part of output, which may happen on hundres or thousands of records. There are also some nice features of 1.9 branches that are useful in a practical sense. For example, hash order is presered in Hash under 1.9, so you can get the extra features of a hash, and avoid superfulous sorting (can result in big compute savings). [1] https://github.com/bradland/require-benchmarks https://github.com/bradland/require-benchmarks [2] https://gist.github.com/1352997 https://gist.github.com/1352997
cheald 15y ago
1.9.3 is great for production. You give up a bit of memory savings compared to REE (since Ruby proper won't be COW-friendly until 2.0), but 1.9.3 in general is faster, has a lot more features, and is widely supported by gems and libraries now. 1.8.7 has been EOL'd, which is as good a reason as any to upgrade.
getsat 15y ago
You are not even remotely close to being correct.
ef4 15y ago
I just switched from 1.9.2 to 1.9.3 specifically because it cuts Rails startup time in half.

fingerprinter 15y ago

Color me intrigued. Would love to see someone step up and maintain Ruby again. RVM is great, but a native package is always preferable.

omarqureshi 15y ago

This looks pretty good - it's always painful installing packages from source (RVM included in that) mainly as a time + another thing I have to maintain thing. I'm not that familiar with Debian package management but would it be much work to also have these packages working on squeeze too? In which case I would most likely start using Debian a lot more.

comice 15y ago
They should build without much modification - it just needs a bit of effort to setup a repository and do the builds. If there is demand for it, we could look at doing it.
obtu 15y ago
Rebuilding the source packages should be easy enough, just loop over the .dsc urls and run dget -x; sudo mk-build-deps -i; debuild; sudo debi. pbuilder and sbuild also work for cross-builds, but I didn't get the hang of cross-building entire package graphs.
beza1e1 15y ago
A "backport" in Debian speak. I use this script for such things: https://gitorious.org/qznc/backporter/blobs/master/backport.sh https://gitorious.org/qznc/backporter/blobs/master/backport....

KTamas 15y ago

I'd love to see RVM/rbenv support a version of 1.9.3 with the mentioned patches.

ryanf 15y ago
They do. Check out https://gist.github.com/1688857 https://gist.github.com/1688857

sciurus 15y ago

Added Sokolov Yura‘s performance patches for 1.9.3 Added Narihiro Nakamura’s Lazy Sweep garbage collector (backported by Sakolov Yura) Why isn't this work a part of an official ruby release? Patched Ruby 1.9.3 to export the right symbols to work with ruby-debug Built Ruby 1.9.3 with Google’s high performance memory alloactor, tcmalloc Why aren't Debian and Ubuntu doing this already?

comice 15y ago
imo, I don't think Debian and Ubuntu should do this - it's not really their job. Distros should, for the most part, just be packaging upstream code and not maintaining an unofficial fork. Though counter to this, RedHat basically maintain their own fork of the Linux kernel but it's a bit of a special case, and they do employ full time kernel developers to do it!
- sciurus 15y ago
  I was assuming use of tcmalloc was a supported option when configuring and building Ruby. If it's not, then yeah, probably not the right thing for a distro to do. If a ruby release didn't have a working debugger but this could be easily patched, then I would expect distros to do that. However, I'm not familiar enough with the ruby ecosystem to know the context of "patched Ruby 1.9.3 to export the right symbols to work with ruby-debug"
judofyr 15y ago
> Why isn't this work a part of an official ruby release? nobu's lazy sweep collector is in trunk. Sokolov Yura's patches have been submitted; some of the merged, others introduce slight incompatibility issues.
bratsche 15y ago
Debian and Ubuntu shouldn't be in the business of trying to second-guess upstreams. They should be packaging things up as they're released.

deleted 15y ago

[deleted]