Best OS packages for Ruby?

ruby-talk
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

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

···

--
Posted via http://www.ruby-forum.com/\.

4

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

···

--
Posted via http://www.ruby-forum.com/\.

5

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?

···

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

6

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

7

David Masover 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.

···

--
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

8

Joel VanderWerf wrote:

David Masover 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 Britt

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

9

Hi,

···

On Tue, Jun 30, 2009 at 9:28 AM, Joel VanderWerf<vjoel@path.berkeley.edu> wrote:

David Masover 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.

10

Joel VanderWerf wrote:

David Masover 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, 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.

···

-----Original Message-----
From: Fabian Streitel [mailto:karottenreibe@googlemail.com]
Sent: Wednesday, July 01, 2009 2:47 PM
To: ruby-talk ML
Subject: Re: Best OS packages for Ruby?

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

13

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

···

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

14

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

15

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

Yes I did: Write in 1.8.6 if that's gonna be an issue for you. If you want
portability and stability, write for 1.8.6. Noone's forcing you to use 1.8.7

The problem comes when 1.8.7 breaks legacy code

As Joel VanderWerf pointed out, there isn't very much code in 1.8.7 that
actually breaks things.

, 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.

Yes, sure it does. You're probably thinking big-time applications. I'm
thinking
much smaller. I'm not a corporate Ruby-writer, I'm a home-scripting
geek-guy.
I write small applications, mostly for myself and like 2 other people.

And I love 1.8.7
I don't have to worry about gems not working with it, but I still get to use
all
the nice features I wouldn't wanna miss for the world.

Again: If you want either only stability and compatibility or only the
bleeding-edge
stuff -- pick any other version. I'm not stopping you...

Also, 1.9.1 is very often not distributed as a binary package yet (at least
not on
my distro) and I personally hate to compile stuff from source, when there is
a
perfectly viable alternative available as a binary.

Greetz!

16

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.

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?

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

···

2009/7/2 Fabian Streitel <karottenreibe@googlemail.com>:

17

Fabian Streitel wrote:

Yes I did: Write in 1.8.6 if that's gonna be an issue for you. If you want
portability and stability, write for 1.8.6. Noone's forcing you to use 1.8.7

The problem comes when 1.8.7 breaks legacy code

As Joel VanderWerf pointed out, there isn't very much code in 1.8.7 that
actually breaks things.

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

The conclusion was that 1.8.7 didn't actually break _any_ legacy code except for the two minor issues (since fixed) mentioned in that post. It's always possible that somebody who wasn't in on that thread back then knows of something new. Perhaps they could post the facts here on ruby-talk.

Until we have some facts, though, I think it's better not to promote any FUD about 1.8.7. I'm not trying to promote 1.8.7 or anything, but it has its place and I don't want new folks getting the wrong impression.

···

--
MagickWand for Ruby - http://magickwand.rubyforge.org/

18

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

19

The conclusion was that 1.8.7 didn't actually break _any_ legacy code
except for the two minor issues (since fixed) mentioned in that post. It's
always possible that somebody who wasn't in on that thread back then knows
of something new. Perhaps they could post the facts here on ruby-talk.

great, thank you! I totally agree.

20

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.