Ruby in the government - 1.6.x -> 1.8.x woes

ruby-talk
1

one of the biggest stumbling blocks to the widespread adoption of ruby in my
lab is the fact what we've standardized on redhat enterprise for all of our
boxen. it ships with 1.6.8. this is a sorry state of affairs and i wonder
why it should be so. the perl and python versions are resonable, thought not
cutting edge - any rational behind this? anyone know how to go about changing
it?

on a related note - anyone know of a compatability layer to bridge 1.6.8 to
1.8.x for cgi libs specifically? does the/a shim do this - the only one i have
doesn't seem too... the cgi interface changed enough between 1.6.x and 1.8.x
to render useless any cgi code written for the former, for example:

   jib:~/eg/ruby > cat a.rb
   require 'cgi'
   cgi = CGI::new
   p cgi['k']

   jib:~/eg/ruby > echo k=v|ruby168 a.rb
   ["v"]

   jib:~/eg/ruby > echo k=v|ruby182 a.rb
   "v"

i can bridge it myself using

   class CGI
     alias_method '__idx__', ''
     def k
       [ __idx__(k) ].flatten.first
     end
   end

but then there is multipart form uploads/tempfile madness, etc. etc. yuk.

regards.

-a

···

--

email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
Your life dwells amoung the causes of death
Like a lamp standing in a strong breeze. --Nagarjuna

===============================================================================

2

Ara.T.Howard wrote:

one of the biggest stumbling blocks to the widespread adoption of ruby in my lab is the fact what we've standardized on redhat enterprise for all

> of our boxen.

How unfortunate for you.

it ships with 1.6.8. this is a sorry state of affairs and i wonder
why it should be so.

Because RedHat Linux is... well, let's just say I wouldn't run it by choice if they gave it away for free.

SuSE Linux Enterprise Server ships with Ruby 1.8.1, so it's clearly possible for a stable enterprise-level Linux to include a reasonably up-to-date Ruby. SuSE also ships with postfix as its mailer rather than RedHat's choice of the execrable sendmail.

anyone know how to go about changing it?

Complain to RedHat. Tell them you're a dissatisfied customer considering switching to Novell's superior offering.

mathew
[ Opinions mine only, etc etc. ]

···

--
<URL:http://www.pobox.com/~meta/&gt;
          WE HAVE TACOS

3

Yeah, same problem here. It sucks.

···

On 10/12/05, Ara.T.Howard <Ara.T.Howard@noaa.gov> wrote:

one of the biggest stumbling blocks to the widespread adoption of ruby in my
lab is the fact what we've standardized on redhat enterprise for all of our
boxen. it ships with 1.6.8. this is a sorry state of affairs and i wonder
why it should be so. the perl and python versions are resonable, thought not
cutting edge - any rational behind this? anyone know how to go about changing
it?

4

one of the biggest stumbling blocks to the widespread adoption of ruby in my
lab is the fact what we've standardized on redhat enterprise for all of our
boxen. it ships with 1.6.8. this is a sorry state of affairs and i wonder
why it should be so. the perl and python versions are resonable, thought not
cutting edge - any rational behind this? anyone know how to go about changing
it?

I am also stuck with RHEL for Linux at the office, mostly because we
use ClearCase. I don't have a rationale for the Ruby shortcoming, but
I feel your pain.

on a related note - anyone know of a compatability layer to bridge 1.6.8 to
1.8.x for cgi libs specifically? does the/a shim do this - the only one i have
doesn't seem too... the cgi interface changed enough between 1.6.x and 1.8.x
to render useless any cgi code written for the former, for example:

   jib:~/eg/ruby > cat a.rb
   require 'cgi'
   cgi = CGI::new
   p cgi['k']

   jib:~/eg/ruby > echo k=v|ruby168 a.rb
   ["v"]

   jib:~/eg/ruby > echo k=v|ruby182 a.rb
   "v"

i can bridge it myself using

   class CGI
     alias_method '__idx__', ''
     def k
       [ __idx__(k) ].flatten.first
     end
   end

but then there is multipart form uploads/tempfile madness, etc. etc. yuk.

I know our sysadmins (I used to be one) can setup the install process
to grab specific RPMs. Installing new RPMs across all machines on the
network is also pretty easy, and I'm sure you can find one. Our
sysadmin folks are locally stationed and very rational, which is not
always the case.

I just keep an installation of Ruby 1.8 on an NFS mounted drive, and
point to it when needed (shebang). For certain scripts that are
ClearCase controlled, there is also an accompanying Ruby installation
inside ClearCase, so the right version is always selected, and always
available. That's probably a bit extreme, though.

Since you're using CGI stuff, will this be run on any particular
server? If so, it may not even need to be NFS mounted.

···

On 10/12/05, Ara.T.Howard <Ara.T.Howard@noaa.gov> wrote:

--
Rob

5

Ara.T.Howard wrote:

one of the biggest stumbling blocks to the widespread adoption of ruby in
my lab is the fact what we've standardized on redhat enterprise for all of
our boxen.

How unfortunate for you.

it ships with 1.6.8. this is a sorry state of affairs and i wonder
why it should be so.

Because RedHat Linux is... well, let's just say I wouldn't run it by choice
if they gave it away for free.

an of course enterprise is not...

SuSE Linux Enterprise Server ships with Ruby 1.8.1, so it's clearly possible
for a stable enterprise-level Linux to include a reasonably up-to-date Ruby.
SuSE also ships with postfix as its mailer rather than RedHat's choice of
the execrable sendmail.

anyone know how to go about changing it?

Complain to RedHat. Tell them you're a dissatisfied customer considering
switching to Novell's superior offering.

a reasonable solution. i guess i'm wondering if any rubyists out there are a
point of contact for them or what - i don't understand how they interface to
an open-source project like ruby.

cheers.

-a

···

On Thu, 13 Oct 2005, mathew wrote:
--

email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
Your life dwells amoung the causes of death
Like a lamp standing in a strong breeze. --Nagarjuna

===============================================================================

6

fyi.

i posted this bug

   170540 – ancient ruby version is shipped with enterprise (1.6.8 vs 1.8.3)

if anyone else can add support for it that'd be great.

-a

···

On Thu, 13 Oct 2005, mathew wrote:

Ara.T.Howard wrote:

one of the biggest stumbling blocks to the widespread adoption of ruby in my lab is the fact what we've standardized on redhat enterprise for all of our boxen.

How unfortunate for you.

it ships with 1.6.8. this is a sorry state of affairs and i wonder
why it should be so.

Because RedHat Linux is... well, let's just say I wouldn't run it by choice if they gave it away for free.

SuSE Linux Enterprise Server ships with Ruby 1.8.1, so it's clearly possible for a stable enterprise-level Linux to include a reasonably up-to-date Ruby. SuSE also ships with postfix as its mailer rather than RedHat's choice of the execrable sendmail.

anyone know how to go about changing it?

Complain to RedHat. Tell them you're a dissatisfied customer considering switching to Novell's superior offering.

--

email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
Your life dwells amoung the causes of death
Like a lamp standing in a strong breeze. --Nagarjuna

===============================================================================

7

My reply seems to have dropped off. Trying again...

one of the biggest stumbling blocks to the widespread adoption of ruby in my
lab is the fact what we've standardized on redhat enterprise for all of our
boxen. it ships with 1.6.8. this is a sorry state of affairs and i wonder
why it should be so. the perl and python versions are resonable, thought not
cutting edge - any rational behind this? anyone know how to go about changing
it?

I am also stuck with RHEL for Linux at the office, mostly because we
use ClearCase. I don't have a rationale for the Ruby shortcoming, but
I feel your pain.

on a related note - anyone know of a compatability layer to bridge 1.6.8 to
1.8.x for cgi libs specifically? does the/a shim do this - the only one i have
doesn't seem too... the cgi interface changed enough between 1.6.x and 1.8.x
to render useless any cgi code written for the former, for example:

   jib:~/eg/ruby > cat a.rb
   require 'cgi'
   cgi = CGI::new
   p cgi['k']

   jib:~/eg/ruby > echo k=v|ruby168 a.rb
   ["v"]

   jib:~/eg/ruby > echo k=v|ruby182 a.rb
   "v"

i can bridge it myself using

   class CGI
     alias_method '__idx__', ''
     def k
       [ __idx__(k) ].flatten.first
     end
   end

but then there is multipart form uploads/tempfile madness, etc. etc. yuk.

I know our sysadmins (I used to be one) can setup the install process
to grab specific RPMs. Installing new RPMs across all machines on the
network is also pretty easy (if it's set up properly), and I'm sure
you can find or
make one for Ruby. Our sysadmin folks are locally stationed and very rational,
which is not always the case.

I just keep an installation of Ruby 1.8 on an NFS mounted drive, and
point to it when needed (shebang). For certain scripts that are
ClearCase controlled, there is also an accompanying Ruby installation
inside ClearCase, so the right version is always selected, and always
available. That's probably a bit extreme, though.

Since you're using CGI stuff, will this be run on any particular
server? If so, it may not even need to be NFS mounted.

···

On 10/12/05, Ara.T.Howard <Ara.T.Howard@noaa.gov> wrote:

--
Rob

8

a reasonable solution. i guess i'm wondering if any rubyists out there
are a
point of contact for them or what - i don't understand how they interface
to
an open-source project like ruby.

This link (https://rhn.redhat.com/errata/RHSA-2005-543.html\) shows a
security advisory for Ruby 1.8 via Redhat Enterprise. I gave up Redhat
long ago, but it looks to me like you can upgrade your Ruby version to
1.8.x.

Caleb

9

I believe redhat uses ruby for a lot of administrative stuff, including
their installer. Might be a reason why it's not the latest version.

A solution is to just install ruby 1.8 in a non standard location like
/usr/local, and use that version whenever you need 1.8. Then you can use
gems to keep all the various modules up to date.

I try to stay away from rpm's if I can, but I imagine that you can probably
find a 1.8 rpm and then given the right command line arguments make it
install in /usr/local. Then just repeat that on the servers where you need
1.8.

I'm not sure if /usr/local is the correct location on redhat though, you
will probably want to check that.

Chris

10

It looks like Akira TAGOH is the package maintainer for Ruby on RHEL:
tagoh@redhat.com

All three of the Bugzilla tickets for Ruby on RHEL4 are assigned to him:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161095
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169575
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165166

--Wilson.

···

On 10/12/05, Ara.T.Howard <Ara.T.Howard@noaa.gov> wrote:

On Thu, 13 Oct 2005, mathew wrote:

> Complain to RedHat. Tell them you're a dissatisfied customer considering
> switching to Novell's superior offering.

a reasonable solution. i guess i'm wondering if any rubyists out there are a
point of contact for them or what - i don't understand how they interface to
an open-source project like ruby.

11

ah - nice. we're running rhe3 - guess that explains it. so now i wait ;-(

cheers.

-a

···

On Thu, 13 Oct 2005, Caleb Tennis wrote:

a reasonable solution. i guess i'm wondering if any rubyists out there
are a
point of contact for them or what - i don't understand how they interface
to
an open-source project like ruby.

This link (https://rhn.redhat.com/errata/RHSA-2005-543.html\) shows a
security advisory for Ruby 1.8 via Redhat Enterprise. I gave up Redhat long
ago, but it looks to me like you can upgrade your Ruby version to 1.8.x.

--

email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
Your life dwells amoung the causes of death
Like a lamp standing in a strong breeze. --Nagarjuna

===============================================================================

12

oh i know - i've got about 100 bits of software (seriously) installed that
way. ruby, python, perl, gcc, image-magick, ocaml, gsl, vigra, itk, vtk, idl,
and on and on. i'm just getting tired of it ;-(

-a

···

On Thu, 13 Oct 2005, snacktime wrote:

I believe redhat uses ruby for a lot of administrative stuff, including
their installer. Might be a reason why it's not the latest version.

A solution is to just install ruby 1.8 in a non standard location like
/usr/local, and use that version whenever you need 1.8. Then you can use
gems to keep all the various modules up to date.

I try to stay away from rpm's if I can, but I imagine that you can probably
find a 1.8 rpm and then given the right command line arguments make it
install in /usr/local. Then just repeat that on the servers where you need
1.8.

I'm not sure if /usr/local is the correct location on redhat though, you
will probably want to check that.

Chris

--

email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
Your life dwells amoung the causes of death
Like a lamp standing in a strong breeze. --Nagarjuna

===============================================================================

13

This may be getting slightly off topic, but anyway...

<snip>

I try to stay away from rpm's if I can, but I imagine that you can probably
find a 1.8 rpm and then given the right command line arguments make it
install in /usr/local. Then just repeat that on the servers where you need
1.8.

I've never understood why people stay away from packages (be they
RPMs, debs or whatever). Packages, properly put together, ensure
that all your machines are running the same binaries, which are built
in a reproducible manner. I'd be concerned about running into
problems where your ruby installs have differing modules (say missing
openssl) because the development files were missing when you built
ruby.

Most of my installs need to be deployed to hundreds or more machines.
I couldn't imagine doing this without making a package for the
software.

I'm not sure if /usr/local is the correct location on redhat though, you
will probably want to check that.

It is.

···

On 10/12/05, snacktime <snacktime@gmail.com> wrote:

Chris

--
Daniel Hobe <hobe@gmail.com>
After the darkness of her speech; I go bewildered in a mist of prophecies.

14

In article <1f060c4c0510121121n582805a5ja5ea91fec0f83662@mail.gmail.com>,

···

snacktime <snacktime@gmail.com> wrote:

------=_Part_4660_7456692.1129141281438
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I believe redhat uses ruby for a lot of administrative stuff, including
their installer. Might be a reason why it's not the latest version.

_ You are confusing ruby and python. Their installer anaconda is
written in python. Ruby is actually a relatively new addition to
their suite of languages and as far as I know totally optional.

_ Booker C. Bense

15

You can probably build a version that will work for you from these srpms
http://www.caliban.org/ruby/

Hopefully you have a software management system in place to distribute
said rpms to all the hosts that need to be upgraded.

···

On 10/12/05, Ara.T.Howard <Ara.T.Howard@noaa.gov> wrote:

On Thu, 13 Oct 2005, Caleb Tennis wrote:

>
>> a reasonable solution. i guess i'm wondering if any rubyists out there
>> are a
>> point of contact for them or what - i don't understand how they interface
>> to
>> an open-source project like ruby.
>
> This link (https://rhn.redhat.com/errata/RHSA-2005-543.html\) shows a
> security advisory for Ruby 1.8 via Redhat Enterprise. I gave up Redhat long
> ago, but it looks to me like you can upgrade your Ruby version to 1.8.x.

ah - nice. we're running rhe3 - guess that explains it. so now i wait ;-(

cheers.

-a
--

> email :: ara [dot] t [dot] howard [at] noaa [dot] gov
> phone :: 303.497.6469
> Your life dwells amoung the causes of death
> Like a lamp standing in a strong breeze. --Nagarjuna

--
Daniel Hobe <hobe@gmail.com>
After the darkness of her speech; I go bewildered in a mist of prophecies.

16

This may be getting slightly off topic, but anyway...

<snip>

I try to stay away from rpm's if I can, but I imagine that you can probably
find a 1.8 rpm and then given the right command line arguments make it
install in /usr/local. Then just repeat that on the servers where you need
1.8.

I've never understood why people stay away from packages (be they
RPMs, debs or whatever). Packages, properly put together, ensure
that all your machines are running the same binaries, which are built
in a reproducible manner. I'd be concerned about running into
problems where your ruby installs have differing modules (say missing
openssl) because the development files were missing when you built
ruby.

Most of my installs need to be deployed to hundreds or more machines.
I couldn't imagine doing this without making a package for the
software.

i go back an forth. here's a motivator for you though: i recently switched a
webserver from an old redhat to a new debian. i had compiled __evertything__
using

   export LD_RUN_PATH=/opt
   export LD_LIBRARY_PATH=/opt
   ./configure --prefix=/opt && make && sudo make install

the only thing i used the system for was c libraries, grep, ls - etc. this is
how i migrated to a new server

   scp -r /opt newserver:/

took about 5 minutes and i had tons of seriously dynamic web aps - gallery,
python wikis, ruby wikis, etc etc. it would have been SOOOO painful to
migrate with rpms it wouldn't have been possible i think.

i hate polluting system space. that said, i use up2date/yum on my fedora
boxes and i'ts fine.

I'm not sure if /usr/local is the correct location on redhat though, you
will probably want to check that.

It is.

Chris

--
Daniel Hobe <hobe@gmail.com>
After the darkness of her speech; I go bewildered in a mist of prophecies.

-a

···

On Thu, 13 Oct 2005, Daniel Hobe wrote:

On 10/12/05, snacktime <snacktime@gmail.com> wrote:

--

email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
Your life dwells amoung the causes of death
Like a lamp standing in a strong breeze. --Nagarjuna

===============================================================================

17

Daniel Hobe wrote:

I've never understood why people stay away from packages (be they
RPMs, debs or whatever).

Because the collection of packages is almost always incomplete.

For example, I wanted to get blosxom running, with some plugins. The plugins used standard CPAN libraries--but there were no RPMs of some of those CPAN libraries available.

Now, I can use CPAN to install the missing libraries--but CPAN doesn't know about RPM, so it also pulls in libraries for which there *are* RPMs. And now I have multiple versions of the same libraries battling it out.

So basically, RPMs and debs are counterproductive as soon as there are libraries missing from the selection available. That's why on ruby-core I suggested that the solution was to make RPM and APT use RubyGems to handle Ruby packages--bundle the .gem and appropriate other metadata into an RPM or .deb. Also, make the process of turning a gem into a package close enough to automated that I can make .debs for the missing gems I need.

mathew

···

--
<URL:http://www.pobox.com/~meta/&gt;
          WE HAVE TACOS

18

boy - you must no work for the government :wink:

there's less than zero chance that we could install non-official (rh
sanctioned for our specific platform) rpms on our nodes - security ;-(

cheers.

-a

···

On Thu, 13 Oct 2005, Daniel Hobe wrote:

You can probably build a version that will work for you from these srpms
Ruby Projects

Hopefully you have a software management system in place to distribute
said rpms to all the hosts that need to be upgraded.

--

email :: ara [dot] t [dot] howard [at] noaa [dot] gov
phone :: 303.497.6469
Your life dwells amoung the causes of death
Like a lamp standing in a strong breeze. --Nagarjuna

===============================================================================

19

How about backporting the RPMS from rhe4 to 3? Or is that still not
good enough?

boy - you must no work for the government :wink:

there's less than zero chance that we could install non-official (rh
sanctioned for our specific platform) rpms on our nodes - security ;-(

shudder. Is the reason Redhat support or the security of the packages or both?

···

On 10/12/05, Ara.T.Howard <Ara.T.Howard@noaa.gov> wrote:

cheers.

-a
--

--
Daniel Hobe <hobe@gmail.com>
After the darkness of her speech; I go bewildered in a mist of prophecies.

20

"Ara.T.Howard" <Ara.T.Howard@noaa.gov> writes:

You can probably build a version that will work for you from these srpms
Ruby Projects

Hopefully you have a software management system in place to distribute
said rpms to all the hosts that need to be upgraded.

boy - you must no work for the government :wink:

there's less than zero chance that we could install non-official (rh
sanctioned for our specific platform) rpms on our nodes - security ;-(

cheers.

-a

But... they run software written by you. But... they won't run Ruby
built by you? Wow. That's just. Wow.

We have not so far had a problem dictating a version of Ruby which the
site installs themselves. But then technically we deliver to
government contractors so I guess that's the difference.

Steve

P.S. Companies who have delivered an OS guaranteed to crash on
reaching N days of uptime: Microsoft, RedHat.

···

On Thu, 13 Oct 2005, Daniel Hobe wrote: