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

[Ara.T.Howard]

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
===============================================================================

 

[Ara.T.Howard]

How unfortunate for you.


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.


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
--
===============================================================================
| 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
===============================================================================

 

[Ara.T.Howard]

How unfortunate for you.


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.


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

fyi.

i posted this bug

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170540

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

-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
===============================================================================

 

[snacktime]

------=_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.

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

------=_Part_4660_7456692.1129141281438--

 

[Rob Rypka]

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 o= ur
boxen. it ships with 1.6.8. this is a sorry state of affairs and i wond= er
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 cha= nging
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 =3D CGI::new
p cgi['k']

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

jib:~/eg/ruby > echo k=3Dv|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=

 

[Joe Van Dyk]

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 o= ur
boxen. it ships with 1.6.8. this is a sorry state of affairs and i wond= er
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 cha= nging
it?

Yeah, same problem here. It sucks.

 

[Ara.T.Howard]

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

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
--
===============================================================================
| 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]

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

I try to stay away from rpm's if I can, but I imagine that you can probab= ly
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 nee= d
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.=20
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.

 

[Ara.T.Howard]

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



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.

It is.

-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
===============================================================================

 

[Rob Rypka]

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 o= ur
boxen. it ships with 1.6.8. this is a sorry state of affairs and i wond= er
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 cha= nging
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 =3D CGI::new
p cgi['k']

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

jib:~/eg/ruby > echo k=3Dv|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=

 

[Wilson Bilkovich]

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

It looks like Akira TAGOH is the package maintainer for Ruby on RHEL:
(e-mail address removed)

All three of the Bugzilla tickets for Ruby on RHEL4 are assigned to him:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=3D161095
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=3D169575
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=3D165166

--Wilson.