Does anyone know of a repository that's *trustworthy* (gotta worry 'bout malware) with newer ruby rpm's than RHEL has?
OT: the more I deal with ruby, the less I like it. Someone here was ready to move to a newer version, and from the ruby.org website, they're apparently actively hostile to all RH-related distros, even though we're the most common in North America. They've got a how to do it from debian and arch, how to use their own installer, and, oh, yes, they say a lot of their community feels you should build from source.
Sorry, that's not my idea of a stable language that I'd ever recommend to someone....
mark
On 02/04/2013 03:21 PM, m.roth@5-cent.us wrote:
Does anyone know of a repository that's *trustworthy* (gotta worry 'bout malware) with newer ruby rpm's than RHEL has?
OT: the more I deal with ruby, the less I like it. Someone here was ready to move to a newer version, and from the ruby.org website, they're apparently actively hostile to all RH-related distros, even though we're the most common in North America. They've got a how to do it from debian and arch, how to use their own installer, and, oh, yes, they say a lot of their community feels you should build from source.
Sorry, that's not my idea of a stable language that I'd ever recommend to someone....
I've used the Ruby Version Manager https://rvm.io/ for all things Ruby for a few years now & can highly recommend it.
Stable, under constant development, very active community & Michal Papis, who monitors & co-authors the project, is very quick to reply to any problems/questions.
Several different ways to install & run Ruby are on offer & it's works very well on CentOS.
Hope this helps,
Cheers,
Phil...
On 02/04/2013 03:37 PM, Phil Dobbin wrote:
I've used the Ruby Version Manager https://rvm.io/ for all things Ruby for a few years now & can highly recommend it.
Rvm is good for developer instances, but dont ever put rvm into a production or testing node. Many reasons for that, the biggest and killer 'feature' of rvm that makes it totally unsuiteable for production is that it builds on the fly, therefore links into and delivers a ruby stack that has random and totally unpredictable abi's and functions.
Regards
Karanbir Singh wrote:
On 02/04/2013 03:37 PM, Phil Dobbin wrote:
I've used the Ruby Version Manager https://rvm.io/ for all things Ruby for a few years now & can highly recommend it.
Rvm is good for developer instances, but dont ever put rvm into a production or testing node. Many reasons for that, the biggest and killer 'feature' of rvm that makes it totally unsuiteable for production is that it builds on the fly, therefore links into and delivers a ruby stack that has random and totally unpredictable abi's and functions.
Karanbir, thank you *very* much for this info.
mark
On 02/05/2013 04:26 PM, Karanbir Singh wrote:
On 02/04/2013 03:37 PM, Phil Dobbin wrote:
I've used the Ruby Version Manager https://rvm.io/ for all things Ruby for a few years now & can highly recommend it.
Rvm is good for developer instances, but dont ever put rvm into a production or testing node. Many reasons for that, the biggest and killer 'feature' of rvm that makes it totally unsuiteable for production is that it builds on the fly, therefore links into and delivers a ruby stack that has random and totally unpredictable abi's and functions.
Karanbir,
Would you mind if I passed on this information to Michal Papis who's one of the lead developers of RVM? He's always on the lookout for feedback & I know he has no access to a CentOS machine to test against (I sometimes help him out in this respect).
He'd be very grateful, I'm sure.
Cheers,
Phil...
On 02/05/2013 05:38 PM, Phil Dobbin wrote:
Would you mind if I passed on this information to Michal Papis who's one of the lead developers of RVM? He's always on the lookout for feedback &
absolutely.
Its not rvm thats at fault, its the build-from-source in changing environs that breaks down any level of trust you can have in that binary build.
ofcourse, that isnt a problem in dev environments or when one dev is looking at testing multiple ruby versions etc.
- KB
On 02/05/2013 05:49 PM, Karanbir Singh wrote:
On 02/05/2013 05:38 PM, Phil Dobbin wrote:
Would you mind if I passed on this information to Michal Papis who's one of the lead developers of RVM? He's always on the lookout for feedback &
absolutely.
Its not rvm thats at fault, its the build-from-source in changing environs that breaks down any level of trust you can have in that binary build.
ofcourse, that isnt a problem in dev environments or when one dev is looking at testing multiple ruby versions etc.
OK. That's great. I will make him aware of the misgivings concerning production deployment.
Thanks.
Cheers,
Phil...
Phil Dobbin wrote:
On 02/05/2013 05:49 PM, Karanbir Singh wrote:
On 02/05/2013 05:38 PM, Phil Dobbin wrote:
Would you mind if I passed on this information to Michal Papis who's one of the lead developers of RVM? He's always on the lookout for
feedback
&
absolutely.
Its not rvm thats at fault, its the build-from-source in changing environs that breaks down any level of trust you can have in that binary build.
ofcourse, that isnt a problem in dev environments or when one dev is looking at testing multiple ruby versions etc.
OK. That's great. I will make him aware of the misgivings concerning production deployment.
Phil, let me add this: I don't know you, or what environment you work in, but I've worked in a lot of environments, and in a large organization that has a really professional environment, developers *NEVER* get to touch production. They provide the software to testing, and testing provides it to whoever the gatekeeper is for production, usually the production admins. They move the package(s) into the right place. In addition, the package(s) should be 100% reproducable... and back outable at a moment's notice, should a show-stopping problem suddenly appear.
Under no circumstances should it be "we'll have to rebuild the environment". Building in production means that every minute it takes, that's another minute that the organization is offline, and you can imagine management's reaction.
mark
On 2/4/2013 7:21 AM, m.roth@5-cent.us wrote:
Does anyone know of a repository that's*trustworthy* (gotta worry 'bout malware) with newer ruby rpm's than RHEL has?
OT: the more I deal with ruby, the less I like it. Someone here was ready to move to a newer version, and from the ruby.org website, they're apparently actively hostile to all RH-related distros, even though we're the most common in North America. They've got a how to do it from debian and arch, how to use their own installer, and, oh, yes, they say a lot of their community feels you should build from source.
Sorry, that's not my idea of a stable language that I'd ever recommend to someone....
IMNSHO, Ruby is only suitable for prototyping and low volume uses. it doesn't scale well, and ruby/rails websites perform abysmally under heavy workloads.
that said, the 'correct' way of dealing with something like this in the RHEL world is to build whatever version you need for your purposes, test it, and package it as your OWN rpm's for production deployment.
John R Pierce wrote:
On 2/4/2013 7:21 AM, m.roth@5-cent.us wrote:
Does anyone know of a repository that's*trustworthy* (gotta worry 'bout malware) with newer ruby rpm's than RHEL has?
OT: the more I deal with ruby, the less I like it. Someone here was ready to move to a newer version, and from the ruby.org website, they're apparently actively hostile to all RH-related distros, even though we're the most common in North America. They've got a how to do it from debian and arch, how to use their own installer, and, oh, yes, they say a lot of their community feels you should build from source.
Sorry, that's not my idea of a stable language that I'd ever recommend to someone....
IMNSHO, Ruby is only suitable for prototyping and low volume uses. it doesn't scale well, and ruby/rails websites perform abysmally under heavy workloads.
ROTFLMAO! A few years ago, a friend who's a professor (was that math, or CS; think it was the latter) up in Minnesota was real hot on ruby, and commented on the growning number of books on it in the school bookstore.
A year or two ago, I'd seen an article or two about it not scaling, and sent it to him, which he thanked me for, and hadn't known about. This isn't a heavily used website, AFAIK, even if it is from the US gov. Certainly, they were building it in ruby before I started; dunno as I'd have had any influence on the guy who was good, but enTHUsed about ruby... and rails. And passenger. <snip>
mark "or was that passenger pigeons, which are extinct?"
On Feb 4, 2013, at 12:36 PM, John R Pierce wrote:
On 2/4/2013 7:21 AM, m.roth@5-cent.us wrote:
Does anyone know of a repository that's*trustworthy* (gotta worry 'bout malware) with newer ruby rpm's than RHEL has?
OT: the more I deal with ruby, the less I like it. Someone here was ready to move to a newer version, and from the ruby.org website, they're apparently actively hostile to all RH-related distros, even though we're the most common in North America. They've got a how to do it from debian and arch, how to use their own installer, and, oh, yes, they say a lot of their community feels you should build from source.
Sorry, that's not my idea of a stable language that I'd ever recommend to someone....
IMNSHO, Ruby is only suitable for prototyping and low volume uses. it doesn't scale well, and ruby/rails websites perform abysmally under heavy workloads.
that said, the 'correct' way of dealing with something like this in the RHEL world is to build whatever version you need for your purposes, test it, and package it as your OWN rpm's for production deployment.
---- I don't normally quibble with your opinions but clearly you are dealing with anecdotal evidence (rather than first hand experience) of older versions.
Yes, twitter has moved some of the server engine to another platform but it's code base is still almost entirely RoR.
There are millions of popular, high trafficked web sites running RoR.
By the time you reach a point where scalability is a bottleneck (and all successful web sites do), you are already the next biggest thing and the options likely involve people whose technical skills that far exceed the original developer.
To the OP - If we are talking about CentOS 5.x and you are determined to use RPM packages, Google 'enterprise ruby' and install it (it's Ruby 1.8.7) It's not likely to get any more updates though. If you get off the need to have RPM packages, both rbenv & rvm install an alternate that downloads ruby source and compiles it for you and gives you sufficient shell modifications to make it appear somewhat seamless (I'm not promising the world here but it's not that difficult and my work has some CentOS 5.x still running enterprise-ruby-1.8.7 and everything newer has been Ubuntu 10.04 and either uses enterprise-ruby for 1.8.7 (becoming rare these days) and all new setups are rbenv and ruby 1.9.3-pXXX
Craig
Craig White wrote:
On Feb 4, 2013, at 12:36 PM, John R Pierce wrote:
On 2/4/2013 7:21 AM, m.roth@5-cent.us wrote:
Does anyone know of a repository that's*trustworthy* (gotta worry 'bout malware) with newer ruby rpm's than RHEL has?
OT: the more I deal with ruby, the less I like it. Someone here was ready to move to a newer version, and from the ruby.org website, they're apparently actively hostile to all RH-related distros, even though we're the most common in North America. They've got a how to do it from debian and arch, how to use their own installer, and, oh, yes, they
say a lot
of their community feels you should build from source.
<snip>
IMNSHO, Ruby is only suitable for prototyping and low volume uses. it doesn't scale well, and ruby/rails websites perform abysmally under heavy workloads.
<snip>
There are millions of popular, high trafficked web sites running RoR.
Yeah, and there are even more running Java, and tomcat.... Btw, the wikipedia website only mentions a quarter of a million or so. <snip>
To the OP - If we are talking about CentOS 5.x and you are determined to
No, 6.3.
use RPM packages, Google 'enterprise ruby' and install it (it's Ruby 1.8.7) It's not likely to get any more updates though. If you get off the
Sorry, can't do that. As I believe I mentioned, they formerly required the 1.8.7 enterprise version, not the packaged version.
need to have RPM packages, both rbenv & rvm install an alternate that downloads ruby source and compiles it for you and gives you sufficient shell modifications to make it appear somewhat seamless (I'm not promising the world here but it's not that difficult and my work has some CentOS 5.x still running enterprise-ruby-1.8.7 and everything newer has been Ubuntu 10.04 and either uses enterprise-ruby for 1.8.7 (becoming rare these days) and all new setups are rbenv and ruby 1.9.3-pXXX
Could you tell me what other, widely-used languages that don't have their most recent stable versions in packages for the most-used distros? I'm not aware of any. Why is it that they don't package it?
I see, with a little googling, that it seems to be mostly ruby promoters arguing it can scale, and a lot of everyone else being aware of issues. And *I* have issues with it - it reminds me of python, 10-12 years ago, when each subrelease would break code that was working fine. IIRC, when I went to get a newer python required by one package I wanted to use, it broke yum on RH 7.3 or 9, something like that, and ruby seems to be like that.
AND I can't just rsync our internal repo with the latest volume, it looks like I'll have to build it separately on each machine - I mean, if it needs compiling....
mark
On Feb 4, 2013, at 1:40 PM, m.roth@5-cent.us wrote:
use RPM packages, Google 'enterprise ruby' and install it (it's Ruby 1.8.7) It's not likely to get any more updates though. If you get off the
Sorry, can't do that. As I believe I mentioned, they formerly required the 1.8.7 enterprise version, not the packaged version.
---- enterprise ruby - clearly the best version of ruby 1.8.7 available anywhere and is available in RPM form.
http://www.rubyenterpriseedition.com/ ----
need to have RPM packages, both rbenv & rvm install an alternate that downloads ruby source and compiles it for you and gives you sufficient shell modifications to make it appear somewhat seamless (I'm not promising the world here but it's not that difficult and my work has some CentOS 5.x still running enterprise-ruby-1.8.7 and everything newer has been Ubuntu 10.04 and either uses enterprise-ruby for 1.8.7 (becoming rare these days) and all new setups are rbenv and ruby 1.9.3-pXXX
Could you tell me what other, widely-used languages that don't have their most recent stable versions in packages for the most-used distros? I'm not aware of any. Why is it that they don't package it?
---- shouldn't you be asking this of upstream? They're the ones who choose which versions to include. ----
I see, with a little googling, that it seems to be mostly ruby promoters arguing it can scale, and a lot of everyone else being aware of issues. And *I* have issues with it - it reminds me of python, 10-12 years ago, when each subrelease would break code that was working fine. IIRC, when I went to get a newer python required by one package I wanted to use, it broke yum on RH 7.3 or 9, something like that, and ruby seems to be like that.
AND I can't just rsync our internal repo with the latest volume, it looks like I'll have to build it separately on each machine - I mean, if it needs compiling....
---- rbenv and rvm have wonderful mechanisms for downloading & building ruby and even allow you multiple versions on the same computer running at the same time. The simplification of the process is quite complete.
Of course you wouldn't understand these things because you made up your mind a long time ago.
Craig
Craig White wrote:
On Feb 4, 2013, at 1:40 PM, m.roth@5-cent.us wrote:
use RPM packages, Google 'enterprise ruby' and install it (it's Ruby 1.8.7) It's not likely to get any more updates though. If you get off the
Sorry, can't do that. As I believe I mentioned, they formerly required the 1.8.7 enterprise version, not the packaged version.
enterprise ruby - clearly the best version of ruby 1.8.7 available anywhere and is available in RPM form.
Except we had it installed not from rpm.
need to have RPM packages, both rbenv & rvm install an alternate that downloads ruby source and compiles it for you and gives you sufficient shell modifications to make it appear somewhat seamless (I'm not promising the world here but it's not that difficult and my work has some CentOS 5.x still running enterprise-ruby-1.8.7 and everything newer has been Ubuntu 10.04 and either uses enterprise-ruby for 1.8.7 (becoming rare these days) and all new setups are rbenv and ruby
1.9.3-pXXX
Could you tell me what other, widely-used languages that don't have their most recent stable versions in packages for the most-used
distros? I'm
not aware of any.
Why is it that they don't package it?
shouldn't you be asking this of upstream? They're the ones who choose which versions to include.
No. If I cared enough, I'd ask on the RUBY list. It's ruby.org that appears to ignore CentOS and all other RH-derived distros.
Btw, you might notice we're on the CentOS, not ubuntu, or some other distro list.
I see, with a little googling, that it seems to be mostly ruby promoters arguing it can scale, and a lot of everyone else being aware of issues. And *I* have issues with it - it reminds me of python, 10-12 years ago, when each subrelease would break code that was working fine. IIRC, when I went to get a newer python required by one package I wanted to use, it broke yum on RH 7.3 or 9, something like that, and ruby seems to be like that.
AND I can't just rsync our internal repo with the latest volume, it looks like I'll have to build it separately on each machine - I mean,
if it
needs compiling....
rbenv and rvm have wonderful mechanisms for downloading & building ruby and even allow you multiple versions on the same computer running at the same time. The simplification of the process is quite complete.
I notice that you are ignoring my issues, and go on about how wonderful the unique ruby package manager is, and say nothing of installing on a number of machines at once.
Of course you wouldn't understand these things because you made up your mind a long time ago.
I've only slowly made up my mind, but the more I have to deal with ruby, as I said, the less I like it.
You, on the other hand, have already come here with the attitude of "my way or the highway"; this is *NOT* the way to encourage folks to change their minds.* Nor is it helpful to me.
mark
* "You can catch more flies with honey than vinegar"
On Feb 4, 2013, at 3:12 PM, m.roth@5-cent.us wrote:
Craig White wrote:
Why is it that they don't package it?
shouldn't you be asking this of upstream? They're the ones who choose which versions to include.
No. If I cared enough, I'd ask on the RUBY list. It's ruby.org that appears to ignore CentOS and all other RH-derived distros.
Btw, you might notice we're on the CentOS, not ubuntu, or some other distro list.
---- and you'd get no answer from the ruby list. The decisions about which versions are packaged are made by Red Hat and obviously CentOS gets from upstream. Just the same as perl, python, etc. ----
rbenv and rvm have wonderful mechanisms for downloading & building ruby and even allow you multiple versions on the same computer running at the same time. The simplification of the process is quite complete.
I notice that you are ignoring my issues, and go on about how wonderful the unique ruby package manager is, and say nothing of installing on a number of machines at once.
---- ignoring your issue because it doesn't apply to my workflow. All new deploys are done via ruby so it's the first and almost only thing installed on a fresh 'base' installation. At the point that ruby is installed, I install the puppet gem and then invoke the first puppet run. At that point, all software installations are done via puppet.
As for which version of ruby, we decide that prior to installation of a server since we have virtual servers and some hardware servers that we deploy applications for specific versions of ruby.
On say my development machine, I can merely type 'sudo rbenv install 1.9.3-p194' and it will be downloaded and installed automatically. ----
Of course you wouldn't understand these things because you made up your mind a long time ago.
I've only slowly made up my mind, but the more I have to deal with ruby, as I said, the less I like it.
---- sorry but whether Mark likes it or not is not meaningful to me. I've been developing on RoR since like 0.0.7 version. It's become much of my livelihood. ----
You, on the other hand, have already come here with the attitude of "my way or the highway"; this is *NOT* the way to encourage folks to change their minds.* Nor is it helpful to me.
---- not really - it's that you don't have much first hand experience so since you can't merely type 'yum install rails' and be done with it, it confuses you.
Craig
On Mon, Feb 4, 2013 at 4:41 PM, Craig White craig.white@ttiltd.com wrote:
You, on the other hand, have already come here with the attitude of "my way or the highway"; this is *NOT* the way to encourage folks to change their minds.* Nor is it helpful to me.
not really - it's that you don't have much first hand experience so since you can't merely type 'yum install rails' and be done with it, it confuses you.
The confusing thing is that for almost everything else that is useful, stable, and publicly available, someone will maintain packages. If they aren't accepted in the distribution or in EPEL, the projects generally have their own repo for them. So why did you have to roll your own installer, and why do you thing that is a good thing?
On Feb 4, 2013, at 3:54 PM, Les Mikesell wrote:
On Mon, Feb 4, 2013 at 4:41 PM, Craig White craig.white@ttiltd.com wrote:
You, on the other hand, have already come here with the attitude of "my way or the highway"; this is *NOT* the way to encourage folks to change their minds.* Nor is it helpful to me.
not really - it's that you don't have much first hand experience so since you can't merely type 'yum install rails' and be done with it, it confuses you.
The confusing thing is that for almost everything else that is useful, stable, and publicly available, someone will maintain packages. If they aren't accepted in the distribution or in EPEL, the projects generally have their own repo for them. So why did you have to roll your own installer, and why do you thing that is a good thing?
---- there may very well be ruby versions in EPEL, I don't know and never looked.
I also never 'rolled my own installer' - the 2 'ruby managers' (rbenv and rvm) have that functionality.
When you are developing, it became necessary to maintain applications undoubtedly on ruby 1.8.7 and work on new applications (1.9.3x) and so have a version manager for ruby was essential - that's why they were created.
FTR… rbenv & rvm are cross platform and recommended not only for Linux but also for Macintosh (as opposed to using Apple's supplied ruby). Windows is less than optimal for ruby/ruby on rails.
What we are discussing here is more likely deployment servers and CentOS-5.x is stuck on ruby-1.8.5 which is pretty much useless and CentOS-6.x is as I understand it, stuck on ruby-1.8.7. Even still, the enterprise ruby package (1.8.7) is vastly superior to RH's build and if you are running an application that you care about, you would want to use that or better yet, ruby 1.9.3x has vastly improved performance of all 1.8.7 builds.
By the way, I am pretty certain that PuppetLabs (puppet) maintains ruby packages for CentOS, Ubuntu, Debian, Windows too.
And lastly, Ruby is an ecosystem far beyond the base language. It has a 'gem' package management system which again is cross platform and even when you try to package ruby in rpm's, there's no way an RH or EPEL will keep up with updates.
Craig
On Mon, Feb 4, 2013 at 5:36 PM, Craig White craig.white@ttiltd.com wrote:
And lastly, Ruby is an ecosystem far beyond the base language. It has a 'gem' package management system which again is cross platform and even when you try to package ruby in rpm's, there's no way an RH or EPEL will keep up with updates.
I guess I still don't understand why you think that is a good thing. If the developers didn't get it right the first dozen times, why do you think the next update will be better? That is, if EPEL can't keep up, why would anyone want to? If you don't have the QA that a packager does it means you have to do it yourself.
On Mon, 2013-02-04 at 18:01 -0600, Les Mikesell wrote:
On Mon, Feb 4, 2013 at 5:36 PM, Craig White craig.white@ttiltd.com wrote:
And lastly, Ruby is an ecosystem far beyond the base language. It has a 'gem' package management system which again is cross platform and even when you try to package ruby in rpm's, there's no way an RH or EPEL will keep up with updates.
I guess I still don't understand why you think that is a good thing. If the developers didn't get it right the first dozen times, why do you think the next update will be better? That is, if EPEL can't keep up, why would anyone want to? If you don't have the QA that a packager does it means you have to do it yourself.
---- Once installed, I rarely have to update ruby on a server.
Gems however are another matter altogether and a typical ruby application (Rails or otherwise) is likely to require many ruby gems (think Perl CPAN).
When I first started deploying RoR applications on CentOS or RHEL, all of the gem RPM's lagged way behind and it was a pain. So you discover that even if the base ruby install was RPM, you pretty much abandoned RPM's for gems. The gem package management system is self contained and excellent, even compiling gems that require 'native extensions' on the fly. There are thousands of gems (again, think CPAN). No packager is going to take on the commitment of building rpm's for all of them so they might build RPM's for the most popular gems and they will fall behind quickly.
So the history is - ruby RPM's from RH and Debian tended to be generic, featureless and updated only when security issues arose (hardly ever). Enterprise Ruby developers (the same that write/maintain passenger) came up with a far superior ruby build, required far less memory to run, didn't leak and was substantially faster. Why look back? Even so, the ruby packages on say CentOS are minimal (ruby, ruby-doc, ruby-ri, ruby-irb, ruby-dev). The rest is all gems and RPM's are not useful there.
Craig
On 02/04/13 22:27, Craig White wrote:
On Mon, 2013-02-04 at 18:01 -0600, Les Mikesell wrote:
On Mon, Feb 4, 2013 at 5:36 PM, Craig Whitecraig.white@ttiltd.com wrote:
<snip>
Gems however are another matter altogether and a typical ruby application (Rails or otherwise) is likely to require many ruby gems (think Perl CPAN).
<snip> Hint: most perl modules are available as rpms.
mark
On 02/04/2013 11:36 PM, Craig White wrote:
On Feb 4, 2013, at 3:54 PM, Les Mikesell wrote:
On Mon, Feb 4, 2013 at 4:41 PM, Craig White craig.white@ttiltd.com wrote:
You, on the other hand, have already come here with the attitude of "my way or the highway"; this is *NOT* the way to encourage folks to change their minds.* Nor is it helpful to me.
not really - it's that you don't have much first hand experience so since you can't merely type 'yum install rails' and be done with it, it confuses you.
The confusing thing is that for almost everything else that is useful, stable, and publicly available, someone will maintain packages. If they aren't accepted in the distribution or in EPEL, the projects generally have their own repo for them. So why did you have to roll your own installer, and why do you thing that is a good thing?
there may very well be ruby versions in EPEL, I don't know and never looked.
I also never 'rolled my own installer' - the 2 'ruby managers' (rbenv and rvm) have that functionality.
When you are developing, it became necessary to maintain applications undoubtedly on ruby 1.8.7 and work on new applications (1.9.3x) and so have a version manager for ruby was essential - that's why they were created.
FTR… rbenv & rvm are cross platform and recommended not only for Linux but also for Macintosh (as opposed to using Apple's supplied ruby). Windows is less than optimal for ruby/ruby on rails.
What we are discussing here is more likely deployment servers and CentOS-5.x is stuck on ruby-1.8.5 which is pretty much useless and CentOS-6.x is as I understand it, stuck on ruby-1.8.7. Even still, the enterprise ruby package (1.8.7) is vastly superior to RH's build and if you are running an application that you care about, you would want to use that or better yet, ruby 1.9.3x has vastly improved performance of all 1.8.7 builds.
By the way, I am pretty certain that PuppetLabs (puppet) maintains ruby packages for CentOS, Ubuntu, Debian, Windows too.
And lastly, Ruby is an ecosystem far beyond the base language. It has a 'gem' package management system which again is cross platform and even when you try to package ruby in rpm's, there's no way an RH or EPEL will keep up with updates.
Puppet is available via EPEL & as a separate rpm for Fedora. It "works" on basically any distro.
Fedora's Ruby is 'ruby 1.9.3p362 (2012-12-25 revision 38607) [x86_64-linux]' which is the latest stable version & can be installed via yum.
As I mentioned before, rvm is invaluable (to me at any rate) for managing Rubies & their associated gemsets & was written with large scale deployments in mind.
I find it unfortunate that the myth is still being perpetuated about its so called shortcomings albeit generally by people who have never used it to any great extent.
They also tend to imply that Ruby equals Rails & vice versa (which is kind of like saying Python equals Django).
Cheers,
Phil...
Maybe we should think about writing the kernel in java/python/ruby/php etc? Wonder why this hasn't happened before? ------------------
-----Original Message----- From: Phil Dobbin bukowskiscat@gmail.com Sender: centos-bounces@centos.org Date: Tue, 05 Feb 2013 07:30:59 To: CentOS mailing listcentos@centos.org Reply-To: CentOS mailing list centos@centos.org Subject: Re: [CentOS] recent ruby packages?
On 02/04/2013 11:36 PM, Craig White wrote:
On Feb 4, 2013, at 3:54 PM, Les Mikesell wrote:
On Mon, Feb 4, 2013 at 4:41 PM, Craig White craig.white@ttiltd.com wrote:
You, on the other hand, have already come here with the attitude of "my way or the highway"; this is *NOT* the way to encourage folks to change their minds.* Nor is it helpful to me.
not really - it's that you don't have much first hand experience so since you can't merely type 'yum install rails' and be done with it, it confuses you.
The confusing thing is that for almost everything else that is useful, stable, and publicly available, someone will maintain packages. If they aren't accepted in the distribution or in EPEL, the projects generally have their own repo for them. So why did you have to roll your own installer, and why do you thing that is a good thing?
there may very well be ruby versions in EPEL, I don't know and never looked.
I also never 'rolled my own installer' - the 2 'ruby managers' (rbenv and rvm) have that functionality.
When you are developing, it became necessary to maintain applications undoubtedly on ruby 1.8.7 and work on new applications (1.9.3x) and so have a version manager for ruby was essential - that's why they were created.
FTR… rbenv & rvm are cross platform and recommended not only for Linux but also for Macintosh (as opposed to using Apple's supplied ruby). Windows is less than optimal for ruby/ruby on rails.
What we are discussing here is more likely deployment servers and CentOS-5.x is stuck on ruby-1.8.5 which is pretty much useless and CentOS-6.x is as I understand it, stuck on ruby-1.8.7. Even still, the enterprise ruby package (1.8.7) is vastly superior to RH's build and if you are running an application that you care about, you would want to use that or better yet, ruby 1.9.3x has vastly improved performance of all 1.8.7 builds.
By the way, I am pretty certain that PuppetLabs (puppet) maintains ruby packages for CentOS, Ubuntu, Debian, Windows too.
And lastly, Ruby is an ecosystem far beyond the base language. It has a 'gem' package management system which again is cross platform and even when you try to package ruby in rpm's, there's no way an RH or EPEL will keep up with updates.
Puppet is available via EPEL & as a separate rpm for Fedora. It "works" on basically any distro.
Fedora's Ruby is 'ruby 1.9.3p362 (2012-12-25 revision 38607) [x86_64-linux]' which is the latest stable version & can be installed via yum.
As I mentioned before, rvm is invaluable (to me at any rate) for managing Rubies & their associated gemsets & was written with large scale deployments in mind.
I find it unfortunate that the myth is still being perpetuated about its so called shortcomings albeit generally by people who have never used it to any great extent.
They also tend to imply that Ruby equals Rails & vice versa (which is kind of like saying Python equals Django).
Cheers,
Phil...
On 02/05/2013 07:55 AM, pnorton3.14@gmail.com wrote:
Maybe we should think about writing the kernel in java/python/ruby/php etc? Wonder why this hasn't happened before?
Linus is on Google +. I'm sure he'd be more than happy to answer that one for you :-)
Cheers,
Phil...
On 02/05/13 02:30, Phil Dobbin wrote:
On 02/04/2013 11:36 PM, Craig White wrote:
On Feb 4, 2013, at 3:54 PM, Les Mikesell wrote:
On Mon, Feb 4, 2013 at 4:41 PM, Craig Whitecraig.white@ttiltd.com wrote:
---- there may very well be ruby versions in EPEL, I don't know and never looked.
<snip the rest of Craig's attitude problem>
Fedora's Ruby is 'ruby 1.9.3p362 (2012-12-25 revision 38607) [x86_64-linux]' which is the latest stable version& can be installed via yum.
<snip> Dunno if it'll work on CentOS, but thanks, Phil - this the first actually useful response to *my* issue from ruby people.
mark
On Tue, Feb 5, 2013 at 7:10 AM, mark m.roth@5-cent.us wrote:
Fedora's Ruby is 'ruby 1.9.3p362 (2012-12-25 revision 38607) [x86_64-linux]' which is the latest stable version& can be installed via yum.
<snip> Dunno if it'll work on CentOS, but thanks, Phil - this the first actually useful response to *my* issue from ruby people.
But still leaves the question of why a usable version isn't maintained for RHEL or CentOS, either in the distro or by the project.
Les Mikesell wrote:
On Tue, Feb 5, 2013 at 7:10 AM, mark m.roth@5-cent.us wrote:
Fedora's Ruby is 'ruby 1.9.3p362 (2012-12-25 revision 38607) [x86_64-linux]' which is the latest stable version& can be installed via yum.
<snip> Dunno if it'll work on CentOS, but thanks, Phil - this the first actually useful response to *my* issue from ruby people.
But still leaves the question of why a usable version isn't maintained for RHEL or CentOS, either in the distro or by the project.
I agree... but if Craig's the maintainer, or representative of the team doing that, if that's their attitude - we're so great, you should forget everything else and do it our way - seems as though that would explain it.
Jeez, the first time I was trying out Linux, back in the mid-nineties, and I'd "only" been programming for about 15 years, mainframes, workstations and pc's, gcc and most other languages were slackware's idea of a package. Certainly, when I went back to Linux again, around '98 or '99, with RH 5? 5.2? any language I needed was a package (though, as I recall, COBOL, should I have wanted it, was a bit more problematical).
Around then, and a few years later, as I've mentioned, every python sub-release broke a previous one... but they *wanted* their language used, and easily accessible. This attitude of "we're *so* wonderful, that either our Brilliance Alone (tm) will force you to do it our way, or you're an ignorant idiot....
mark, who uses scripting languages cheerfully, but for *real* production work prefers a real (compiled) language)
On 02/04/2013 07:36 PM, John R Pierce wrote:
On 2/4/2013 7:21 AM, m.roth@5-cent.us wrote:
Does anyone know of a repository that's*trustworthy* (gotta worry 'bout malware) with newer ruby rpm's than RHEL has?
OT: the more I deal with ruby, the less I like it. Someone here was ready to move to a newer version, and from the ruby.org website, they're apparently actively hostile to all RH-related distros, even though we're the most common in North America. They've got a how to do it from debian and arch, how to use their own installer, and, oh, yes, they say a lot of their community feels you should build from source.
Sorry, that's not my idea of a stable language that I'd ever recommend to someone....
IMNSHO, Ruby is only suitable for prototyping and low volume uses. it doesn't scale well, and ruby/rails websites perform abysmally under heavy workloads.
that said, the 'correct' way of dealing with something like this in the RHEL world is to build whatever version you need for your purposes, test it, and package it as your OWN rpm's for production deployment.
The doesn't scale well argument hasn't been the case for at least a few years now. Twitter is just one example. Some of the busiest sites on teh Interwebs are still using it.
There are also projects, for example, like Puppet that are written in Ruby that are used by a lot of fairly large organisations.
It may be worth your while reappraising Ruby.
Cheers,
Phil...
Phil Dobbin wrote:
On 02/04/2013 07:36 PM, John R Pierce wrote:
On 2/4/2013 7:21 AM, m.roth@5-cent.us wrote:
Does anyone know of a repository that's*trustworthy* (gotta worry 'bout malware) with newer ruby rpm's than RHEL has?
OT: the more I deal with ruby, the less I like it. Someone here was ready to move to a newer version, and from the ruby.org website, they're apparently actively hostile to all RH-related distros, even though we're the most common in North America. They've got a how to do it from debian and arch, how to use their own installer, and, oh, yes, they
say a lot
of their community feels you should build from source.
Sorry, that's not my idea of a stable language that I'd ever recommend to someone....
IMNSHO, Ruby is only suitable for prototyping and low volume uses. it doesn't scale well, and ruby/rails websites perform abysmally under heavy workloads.
<snip>
The doesn't scale well argument hasn't been the case for at least a few years now. Twitter is just one example. Some of the busiest sites on teh Interwebs are still using it.
Um, according to wikipedia, twitter went to scala, and uses ror for the user interface.
There are also projects, for example, like Puppet that are written in Ruby that are used by a lot of fairly large organisations.
It may be worth your while reappraising Ruby.
I'm an admin these days, and don't get to argue this. However, when it's packageable, and pushed out that way, so that someone can update a ton of machines, and not hand-craft it, *AND* subreleases don't break working code, I'll reconsider my attitude.
And as I think I said, I find the RoR website rather obnoxious in its refusal to pay any attention to the biggest market in North America, RH and RH-derived repos.
mark
On Feb 4, 2013, at 1:46 PM, m.roth@5-cent.us wrote:
Phil Dobbin wrote:
The doesn't scale well argument hasn't been the case for at least a few years now. Twitter is just one example. Some of the busiest sites on teh Interwebs are still using it.
Um, according to wikipedia, twitter went to scala, and uses ror for the user interface.
---- What's wrong with that. They became the next biggest thing - so big that they had to make scaling adjustments. Successful sites do that. ----
There are also projects, for example, like Puppet that are written in Ruby that are used by a lot of fairly large organisations.
It may be worth your while reappraising Ruby.
I'm an admin these days, and don't get to argue this. However, when it's packageable, and pushed out that way, so that someone can update a ton of machines, and not hand-craft it, *AND* subreleases don't break working code, I'll reconsider my attitude.
And as I think I said, I find the RoR website rather obnoxious in its refusal to pay any attention to the biggest market in North America, RH and RH-derived repos.
---- It's packaged and pushed out in a way that someone can update a ton of machines.
Trust me, I'm a DevOPS person… that's my job.
Even if Red Hat actually tried to keep up with ruby releases, I wouldn't use them and haven't used them for quite some time. The Enterprise Ruby versions were far superior to any version ever packaged by RH (garbage collection, performance, etc.). The reality is that if you are supporting Ruby/Ruby on Rails apps in any meaningful way, RH's ruby packaging is meaningless.
Craig
Thanks for this discussion. I also had (and was about to ask) similar question(s). I've already tried to get/use Latest+Stable ruby compiled & used on other RHEL based repo, but something conflicted, as i'm new to these, so beyond my understanding what was it at this point. But need to look-into/try-out what you've discussed/suggested here, may be useful for my case, (solutions which use very low memory footprint, and large vswap or swap or database use is/are ok). -- Bright Star.
Received from Craig White, on 2013-02-04 9:52 PM:
On Feb 4, 2013, at 1:46 PM, m.roth@5-cent.us wrote:
Phil Dobbin wrote:
The doesn't scale well argument hasn't been the case for at least a few years now. Twitter is just one example. Some of the busiest sites on teh Interwebs are still using it.
Um, according to wikipedia, twitter went to scala, and uses ror for the user interface.
---- What's wrong with that. They became the next biggest thing - so big that they had to make scaling adjustments. Successful sites do that. ----
There are also projects, for example, like Puppet that are written in Ruby that are used by a lot of fairly large organisations.
It may be worth your while reappraising Ruby.
I'm an admin these days, and don't get to argue this. However, when it's packageable, and pushed out that way, so that someone can update a ton of machines, and not hand-craft it, *AND* subreleases don't break working code, I'll reconsider my attitude.
And as I think I said, I find the RoR website rather obnoxious in its refusal to pay any attention to the biggest market in North America, RH and RH-derived repos.
---- It's packaged and pushed out in a way that someone can update a ton of machines.
Trust me, I'm a DevOPS person… that's my job.
Even if Red Hat actually tried to keep up with ruby releases, I wouldn't use them and haven't used them for quite some time. The Enterprise Ruby versions were far superior to any version ever packaged by RH (garbage collection, performance, etc.). The reality is that if you are supporting Ruby/Ruby on Rails apps in any meaningful way, RH's ruby packaging is meaningless.
Craig
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 02/04/2013 03:21 PM, m.roth@5-cent.us wrote:
Does anyone know of a repository that's *trustworthy* (gotta worry 'bout malware) with newer ruby rpm's than RHEL has?
This thread is so full of fail and FUD.
Long story short, http://people.redhat.com/bkabrda/ruby193-rhel-6/
a longer story, go readup about collections
an even longer story : I have been working on a ruby193 stack that replaces the system ruby, and another one that goes into /opt/; time and other issues prevent that project from getting 'there'. All forms of help appreciated.
Regards,
-
Bry8 Star -
Craig White -
Craig White -
John R Pierce -
Karanbir Singh -
Les Mikesell -
m.roth＠5-cent.us -
mark
-
Phil Dobbin -
pnorton3.14＠gmail.com