Best OS packages for Ruby?

Ruby
1

Hi all,

I know the question in the subject of this thread might seem a bit
strange, but I wanted to get the opinion of others regarding the best
operating system for Ruby hosting and development. What I’m mainly
looking for is an OS with up to date packages. Right now I’m running
CentOS 5.3, but the Ruby package is still at 1.8.5 and the upgrade
process is a bit tricky. I know that I can just compile from source,
but I’d rather spend my time writing Ruby instead of managing
packages. I’ve installed software from source before, and it can be a
pain. :wink:

I’m hosted at Slicehost, so my options are the following:

Arch 2009.02
CentOS 5.2 or 5.3
Debian 5.0
Fedora 10 or 11
Gentoo 2008.0
RHEL 5.3
Ubuntu 8.04.2 LTS, 8.10, or 9.04

I have run almost all of these operating systems at one point or
another (in college I used to experiment with them), but I’m not
familiar with the latest versions of each. Thanks in advance.

Michael

2

Hi Michael,

I’m running ArchLinux on my Laptop and I’m very, very, … , very happy
with
it g

Probably the best thing about it (and probably a major selling point in
your
case)
is that Arch is rolling release, meaning there’s no big releases where
you
have to
painfully upgrade to the newer big version, and maybe even reinstalling
the
whole
system (as you have to with e.g. Ubuntu and consorts). They just upgrade
the
packages, and if you run pacman frequently, there are almost no
compatibility problems.

I don’t know if the other distros have that… never used any of those.

Also the ArchLinux wiki is so well populated, I have yet to run into a
bug
that couldn’t
be solved by looking into it :wink:

[…] What I’m mainly
looking for is an OS with up to date packages.

Furthermore, Arch is known for it’s very up to date packages. You
usually
don’t have to
wait very long when a new version is released to see it in the package
list.
ATM it hosts ruby 1.8.7 2009-06-08 patchlevel 173 – reasonably current
I’d
say.

[…] I know that I can just compile from source,
but I’d rather spend my time writing Ruby instead of managing
packages.

Usually on arch, updating the whole system is a matter of running one
console command.

And Ruby itself as well als RubyGems come as binary packages, meaning
you
don’t have
to compile them at all.

Of course it takes a little time getting to know the system and setting
it
up (it comes without
the X server in standard mode, you have to set that up yourself if you
need
it).
But IMO it’s worth it.

Greetz
k

3

On Monday 29 June 2009 12:11:38 pm Fabian S. wrote:

Probably the best thing about it (and probably a major selling point in
your case)
is that Arch is rolling release, meaning there’s no big releases where you
have to
painfully upgrade to the newer big version, and maybe even reinstalling the
whole
system (as you have to with e.g. Ubuntu and consorts). They just upgrade
the packages, and if you run pacman frequently, there are almost no
compatibility problems.

To me, this is a major selling point of Ubuntu – if I run apt-get
frequently,
I won’t have security issues, but if a new release breaks something, I
can go
back to a previous one until the issue is resolved, and I can put off
that big
upgrade until I want to deal with that hassle.

With a system like Arch – which I last experienced with Gentoo – any
upgrade
could potentially break things, which means I have to deal with problems
as
they arise, or I have to not update a lot – which means more security
problems.

ATM it hosts ruby 1.8.7 2009-06-08 patchlevel 173 – reasonably
current I’d say.

1.8.7 is actually not a great release. It breaks things that worked in
1.8.6,
and most people either stay on 1.8.6 or upgrade straight to 1.9.1.

Full disclosure: I use Ubuntu, and it had Ruby 1.8.7. It also doesn’t
keep
Ruby 1.9 as up-to-date as I’d like, so I compile that from source.

[…] I know that I can just compile from source,
but I’d rather spend my time writing Ruby instead of managing
packages.

Keep in mind, I install all needed non-Ruby libraries through the OS
package
manager, and I install everything else Ruby-related through Rubygems. So
the
only source package I have to watch for is Ruby 1.9, and that’s really a
matter of watching ruby-talk for release announcements, then running
‘svn
switch’ and a couple of make commands.

And Ruby itself as well als RubyGems come as binary packages, meaning you
don’t have
to compile them at all.

Rubygems compiles any C extensions on install. Or are you saying Arch
packages
ALL rubygems?

4

With a system like Arch – which I last experienced with Gentoo – any
upgrade
could potentially break things, which means I have to deal with problems as
they arise, or I have to not update a lot – which means more security
problems.

With a system like Arch – which is much unlike Gentoo, I’ve tried that
before I went
to ArchLinux --, I can at any time revert by just using the cached old
package
and running pacman -U /path/to/package
And believe me, I have enough friends running Ubuntu, Kubuntu and what
not
and all
of them are afraid to upgrade each time a new big version is released…
I run my updates almost daily and the last package to break something
was…
I don’t
even remember when that was. Quite a while ago.

1.8.7 is actually not a great release. It breaks things that worked in

1.8.6,
and most people either stay on 1.8.6 or upgrade straight to 1.9.1.

I like 1.8.7, tons of new nice features I wouldn’t wanna miss for the
world
:wink:
Coding for 1.8.6 always makes me feel like I got forced to write C
again…
And it’s way better than 1.8.5 which Michael is now forced to use.

Also, Ruby 1.9.0 is available as a package, but that one needs to be
compiled.
Although the supplied packagebuilds almost always work and are fully
automated.

And there’s Ruby 1.9.1 in the testing repository as a packagebuild as
well.
AFAIK
it is still in testing as it breaks something in gvim or something like
that. They
want to fix that bug I guess before they put it out there.

And Ruby itself as well als RubyGems come as binary packages, meaning you
don’t have
to compile them at all.

Rubygems compiles any C extensions on install. Or are you saying Arch
packages
ALL rubygems?

No, of course not. RubyGems, the gem install system, of course.
I install my gems like any normal Rubyist via gem install whatever.
But it has some special gems as packages, e.g. Rake (mainly those needed
for
build processes)

Greetz,
k

5

David M. wrote:

1.8.7 is actually not a great release. It breaks things that worked in 1.8.6,
and most people either stay on 1.8.6 or upgrade straight to 1.9.1.

Not to open a can of worms, but when this statement came up last, the
ruby-talk list was asked for concrete justification of what actually
broke code going to 1.8.7, and IIRC there really wasn’t much. Maybe I’m
misremembering though.

6

Michael J. I. Jackson wrote:

I know the question in the subject of this thread might seem a bit
strange, but I wanted to get the opinion of others regarding the best
operating system for Ruby hosting and development.

You might want to take a look at this:
http://redhanded.hobix.com/cult/whyIUseDebianWithRuby.html

7

Joel VanderWerf wrote:

David M. wrote:

1.8.7 is actually not a great release. It breaks things that worked in
1.8.6, and most people either stay on 1.8.6 or upgrade straight to 1.9.1.

Not to open a can of worms, but when this statement came up last, the
ruby-talk list was asked for concrete justification of what actually
broke code going to 1.8.7, and IIRC there really wasn’t much. Maybe I’m
misremembering though.

Perhaps. But if you are running 1.8.7, and writing code for general
distribution, is there not a real chance you will end up with code that
only works with 1.8.7?

Or is that another misconception? (Perhaps there’s some shim,
grant_187-ness.rb, that will adjust any misbehavior.)

Finally, is there a thread or Web site that explains why 1.8.7 would be
preferred over 1.8.6 or 1.9?

Thanks!

–
James B.

www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff
www.neurogami.com - Smart application development

8

Hi,

On Tue, Jun 30, 2009 at 9:28 AM, Joel
VanderWerf[email protected] wrote:

David M. wrote:

1.8.7 is actually not a great release. It breaks things that worked in
1.8.6, and most people either stay on 1.8.6 or upgrade straight to 1.9.1.

Not to open a can of worms, but when this statement came up last, the
ruby-talk list was asked for concrete justification of what actually broke
code going to 1.8.7, and IIRC there really wasn’t much. Maybe I’m
misremembering though.

Nope, you’re right. I started that thread, and we really couldn’t get
anybody to post concrete examples of problems with 1.8.7.

~ j.

9

I’m hosted at Slicehost, so my options are the following:

Arch 2009.02
CentOS 5.2 or 5.3
Debian 5.0
Fedora 10 or 11
Gentoo 2008.0
RHEL 5.3
Ubuntu 8.04.2 LTS, 8.10, or 9.04

I use ubuntu 9.04 32 bit on linode and it seems to run fine. You’ll
want 32 bit to save on RAM [otherwise your rails processes will eat like
100MB each].

Also used a few tricks to save RAM.
Anyway go 32-bit :slight_smile:
=r

10

Joel VanderWerf wrote:

David M. wrote:

1.8.7 is actually not a great release. It breaks things that worked in 1.8.6,
and most people either stay on 1.8.6 or upgrade straight to 1.9.1.

Not to open a can of worms, but when this statement came up last, the
ruby-talk list was asked for concrete justification of what actually
broke code going to 1.8.7, and IIRC there really wasn’t much. Maybe I’m
misremembering though.

No, you’re right. Here’s a summary:

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/328269

11

Perhaps. But if you are running 1.8.7, and writing code for general
distribution, is there not a real chance you will end up with code that only
works with 1.8.7?

That’s exactly why the Java guys have the worst API ever conceived
(at least as far as I know).
If everyone’s always whining about “No you can’t take that feature out”
or “No don’t change that behaviour” because it’ll break some legacy
code then real progress is never gonna happen.

Like anything in IT, programming languages and their libraries have to
evolve or they’ll just become a big heap of unusable deprecations.

And what comes with this is the responsibility of the programmer to keep
his code up-to-date. Or to keep the Ruby version the same for all
eternity.
Whichever one prefers…

Also, I had the experience that the 2 or 3 features of 1.8.7 you use,
which
are not present in 1.8.6 are fairly easily emulated, e.g. Array#group_by
and fellows.

(Just my two cents :wink:

Greetz,
k

12

I think people would be asking for a deprecation period

I never said you shouldn’t do that. I just said you shouldn’t go
around complaining about how your Ruby 1.0 script isn’t gonna
work with 1.9 (warning, exaggerated statement).
Deprecation periods are of course good. But I just don’t see why
people keep nagging about how 1.8.7 is sooo bad when mostly all
it did was add new features.

and not suddenly in a swift move that can sometimes
to a large company be really cost-ineffective.

If you sell a product that’s based on Ruby, where’s the problem
of shipping it with the ruby version it was developed with? At least
if your company is large. Ruby really isn’t that
big a package? There are even tools that do this for you, if I
remember correctly (at least for Win32 I think).

Sure that statement may be true for big stuff like Java and its standard
library, but the 5 Megs of Ruby code you’d have to package up can’t
be that much a burdon, can they?

Greetz,
k

13

I think people would be asking for a deprecation period, a key part of
evolution if you ever took science. Evolution is not defined by a
“sudden”
change but a “period of change over time” which means that there is some
form of backwards compatibility in evolution for some minor period of
time,
to give people the ability to grant new features while moving old
features
to new features without suddenly breaking their entire application all
at
once. While yes, there are ways to work around the things they change,
people want the ability to bring those changes to their own API’s and
applications over time and not suddenly in a swift move that can
sometimes
to a large company be really cost-ineffective. Take a look at MySQL,
they
break features every milestone most of the time, but they still maintain
a
period of deprecation, and sometimes even full on backwards
compatibility
(AKA: OldPasswords) and PHP is a good example too, deprecated features
that
were removed piece by piece overtime and then lead to the final removal
in
the next major milestone.

14

2009/7/2 Fabian S. [email protected]:

I think people would be asking for a deprecation period

I never said you shouldn’t do that. I just said you shouldn’t go
around complaining about how your Ruby 1.0 script isn’t gonna
work with 1.9 (warning, exaggerated statement).
Deprecation periods are of course good. But I just don’t see why
people keep nagging about how 1.8.7 is sooo bad when mostly all
it did was add new features.

These features alone are a problem. If you write your shiny new script
on ruby 1.8.7 and give it to somebody with ruby 1.8.6 then it’s very
likely it won’t work unless you were very careful and did throughout
testing on earlier rubies.

1.8.7 adds a bunch of simple and useful utility functions which you ca
easily emulate (an which you have most likely written in one form or
another for your earlier code) but there is no warning in the docs or
a runtime compatibility check or something.

So instead of writing the utility functions as you did in 1.8.6 you
will have to write a check that the method you want is already
present, and only after you find out about the additions. Not exactly
an improvement.

Sure that statement may be true for big stuff like Java and its standard
library, but the 5 Megs of Ruby code you’d have to package up can’t
be that much a burdon, can they?

It may be the standard way on Windows or OS X but on Linux/UNIX you
send the script and expect it to tun on any system with reasonably
recent interpreter of your favourite language. And even on Windows it
may be handy to send a few kilobytes of script instead of a few
megabytes of interpreter+script package.

The stuff about 1.8.7 breaking old stuff probably arose from the
changelog being somewhat hard to read and ruby 1.8.7 reporting some
arcane errors related to new features in some cases that were already
broken on 1.8.6. Many people were probably misled by these errors and
thought that the code broke because of the new features while it was
already broken. Due to the dynamic nature of ruby it can easily happen
that some state that was never reached before would by chance occur
just after upgrade to 1.8.7.

It would be much nicer if the new features were released separately as
a package that could be installed on top of both 1.8.6 and 1.8.7 for
people to test and enjoy when they are interested without the need for
the stuff to be present at all times. Unfortunately it was not done
that way so you get all or nothing.

Thanks

Michal

15

Fabian,

The docs seem like a good idea though. I think if RI would list the
date of the introduction of the member functions, that would help
a lot discovering such cross-version bugs.

This is an excellent idea … one thing that I actually miss about
coding in PHP (probably the only thing I can think of at the moment).
The docs are excellent and they contain information like this.

16

well, then just write your scripts in 1.8.6, where’s your problem?
If you need it to be distributed everywhere, why bother with 1.8.7?
I don’t get your point.

These features alone are a problem. If you write your shiny new script
on ruby 1.8.7 and give it to somebody with ruby 1.8.6 then it’s very
likely it won’t work unless you were very careful and did throughout
testing on earlier rubies.

Try multiruby

1.8.7 adds a bunch of simple and useful utility functions which you ca
easily emulate (an which you have most likely written in one form or
another for your earlier code) but there is no warning in the docs or
a runtime compatibility check or something.

How should that work? Everytime you use a bit of code that changed
since the last minor release you get a warning? I’d very much doubt
that that would be practical. My code alone would be flooded with
warnings.
The docs seem like a good idea though. I think if RI would list the
date of the introduction of the member functions, that would help
a lot discovering such cross-version bugs.

Nevertheless I think you’re mistaking Ruby for Java here… If you want
something like compile-time warnings about deprecation, an interpreted
language is probably not the best way to go…

So instead of writing the utility functions as you did in 1.8.6 you

will have to write a check that the method you want is already
present, and only after you find out about the additions. Not exactly
an improvement.

I don’t see your problem?
If you already wrote the functions for 1.8.6, all you need to do is wrap
them inside

if RUBY_VERSION != "1.8.6"
endif

or something similar.

It may be the standard way on Windows or OS X but on Linux/UNIX you
send the script and expect it to tun on any system with reasonably
recent interpreter of your favourite language.

Then write for 1.8.6!

It would be much nicer if the new features were released separately as

a package that could be installed on top of both 1.8.6 and 1.8.7 for
people to test and enjoy when they are interested without the need for
the stuff to be present at all times. Unfortunately it was not done
that way so you get all or nothing.

<reductio_ad_absurdum>
So basically what you suggest is that we sticked with Ruby 1.0 and froze
that
and released ALL the features after that in thousands of tiny patches
which
everyone would have to apply manually just for the sake of never ever
breaking
a single line of code?
Doesn’t sound very promising to me.
</reductio_ad_absurdum>

Greetz
k

17

I know that I can just compile from source, but I’d rather spend
my time writing Ruby instead of managing packages. I’ve
installed software from source before, and it can be a pain. :wink:

Try an approach like GoboLinux. Basically everything goes into one dir -
ruby would reside under /Programs/Ruby/Version i.e.
/Programs/Ruby/1.9.1, Glibc would reside under /Programs/Glibc/2.10.1
and so on and so forth. For an older glibc version it would be i.e.
/Programs/Glibc/2.6 and a symlink would point at which
version is the one which should be used currently.

This model works much better because when you want to switch versions,
you just switch symlinks (if you installed that program already, else
you just download the binary via a script and have it setup to be your
main version)

Also, if you want to get rid of something, you just kill the directory.

With that being said though, GoboLinux is too small so I dont recommend
it.
Big distributions like Ubuntu have one huge advantage - NUMBERS.

Numbers of users, developers and so forth. There is too much
proliferation of distributions without any real gain.

I have run almost all of these operating systems at one point or
another (in college I used to experiment with them), but I’m not
familiar with the latest versions of each

But then you already must invest time. :>

The most obvious solution would be to use the one which gives you the
least amount of problems. Now, I believe the GoboLinux model is better
than the FHS one, but if I have to pick a distribution which I can
recommend to smart people, then I will pick Archlinux.

If you want the numbers, then use Ubuntu.

Dont do it like me though, because else you would end up with a system
that is much closer to Linux from Scratch, with an always-unfinished
package manager in ruby, which lacks features pacman (Archlinux) or
apt-get (Ubuntu) has - stick to a distribution! :wink:

18

If you want the numbers, then use Ubuntu.

Hey, Archlinux has a pretty nice userbase as well.
Ubuntu may have a billion users, but I’m guessing most of them don’t
know
a dime about their system; Archlinux has some thousand users,
most of whom know what’s going on :wink:
After all, when you’ve set up an Arch system, you have a pretty good
insight
already…

19

you should let the RDoc folks know. They probably know where to turn
with
such a request
i guess this would have to be taken over by the folks who maintain the
standard library?

2009/7/7 Michael J. I. Jackson [email protected]

20

On Wednesday 01 July 2009 02:47:29 pm Fabian S. wrote:

Perhaps. But if you are running 1.8.7, and writing code for general
distribution, is there not a real chance you will end up with code that
only works with 1.8.7?

This is a separate issue, and one you didn’t address.

That’s exactly why the Java guys have the worst API ever conceived
(at least as far as I know).
If everyone’s always whining about “No you can’t take that feature out”
or “No don’t change that behaviour” because it’ll break some legacy
code then real progress is never gonna happen.

Like anything in IT, programming languages and their libraries have to
evolve or they’ll just become a big heap of unusable deprecations.

That’s what 1.9 is about.

The problem comes when 1.8.7 breaks legacy code, and adds all these new
features, which are really all in 1.9 anyway. The only reason you’d want
to
use 1.8.7 instead of 1.8.6 is to have those features, right? But the
only
reason you’d want to use 1.8.7 instead of 1.9 is you had legacy code
that
breaks in 1.9.

So you’re basically trying to have it both ways, which really doesn’t
make
sense.

Now, in practice, 1.8.7 doesn’t seem to break much. Most of what was
broken by
1.9 seems to be C extensions, and most gems that it makes sense to fix
seem to
have been fixed.

But it seems really strange that anyone would rely on 1.8.7 for
production
when 1.8.6 is still stable, being maintained, and unlikely to break
anything.

Also, I had the experience that the 2 or 3 features of 1.8.7 you use, which
are not present in 1.8.6 are fairly easily emulated, e.g. Array#group_by
and fellows.

True. For that matter, I often add things like Object#tap and
Symbol#to_proc.
It’s fairly trivial to detect if these things exist, and add them if
they
don’t – and they’re one-liners anyway.

The problem is, I now have to test my code on 1.8.6, to make sure those
shims
work, and on 1.8.7 and 1.9.1, to make sure the real behavior is left
alone –
and that my shim is compatible with the real implementation.

Frankly, I see absolutely no point to 1.8.7. It may have made sense
while
people were waiting for 1.9 to stablize, and for gems to be ported, but
all
that happened absurdly quickly.