From: Rick DeNatale Date: 2010-03-19T01:17:54+09:00 Subject: Re: Recommended way to install Rubygems On Thu, Mar 18, 2010 at 11:53 AM, Lucas Nussbaum wrote: >> On Mar 18, 2010, at 10:15 AM, Lucas Nussbaum wrote: >> >> > Note there are not many development communities that are proud of the >> > fact of having different, incompatible versions of the same software >> > being widely used at the same time. >> > >> > Most other communities solve that by having more stable APIs and making >> > sure that their important software supports the latest API. I find the massive and rapid open source contributions to the overall Ruby ecosystem to be a big source of pride in the Ruby community. The fact that not everything needs to be on the same version of everything is what allows fast movement. Now I realize that there's a different mindset between cutting-edge development to deployment to system administration. Clearly having less stability in the various pieces that make up various applications raises some issues, and we, the Ruby community have been dealing with those issues and getting better at it as time goes on. Allowing that 'instability' is important to a lot of us, believe it or not. As I said before packaged Ruby solutions and re-packaged gems have their place, they work for some users, but not for all. In another reply to this thread you said: > Such a minor issue" was the split of many software packages into > seperate Debian packages, not the split of Ruby. ... > Interestingly, we don't get many complaints on the Debian side about > that. The only place where I hear about it is on this list. I'm not sure what the antecedent of 'that' in the first sentence in the second paragraph is. But I guess it doesn't matter. Perhaps the reason you only hear complaints about the debian packaging of Ruby and gems here is that there's a much higher proportion of users here who are actually leveraging Ruby in such a way as to have conflicting requirements with those of the debian packagers. And as I said before, it's not really an either or. You can run both packaged ruby/gems if you need to in order to run other packages which require them, along with multiple other installations outside of the file system space clamed by debian policy within the FHS. This whole discussion reminds me of the endless static vs. dynamic typing debate. Some feel strongly that one should live within a highly constrained infrastructure, others see benefits in having more freedom of action, and are willing to deal with the consequences and use tools and techniques which do that. >> > Of course, if you want to install many different Ruby and gems versions, >> > and then try to keep them in a sensible state wrt security issues (which >> > are not that uncommon in the ruby world), that's your choice. >> > On 19/03/10 at 00:35 +0900, James Edward Gray II wrote: >> You have lost the high ground in the civility argument. > > Why? What do you disagree with? I can't speak for James but perhaps he was reacting to the remark about security issues not being uncommon in the ruby world. In fact, although there have been security patches to Ruby/Rails etc. They haven't been more frequent than most other OSS software as far as I have experienced, and certainly less than software from a certain company headquartered in the US Pacific Northwest. And such security patches are generally released quickly. In fact having the ability to apply such changes, without having to wait for them to be packaged 'downstream' is another advantage to allowing 'instability.' -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale