Forum: Ruby Best OS packages for Ruby?

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

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

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 ;-)

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

On Monday 29 June 2009 12:11:38 pm Fabian Streitel 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?

>
> 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
;-)
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

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

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.

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

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.

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

> 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 :)
=r
http://programming-gone-awry.blogspot.com/2009/06/how-to-save-much-ram-when-running-rails.html

>
> 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 ;-)

Greetz,
k

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.

> 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

2009/7/2 Fabian Streitel <karottenreibe@googlemail.com>:
>> 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

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

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.

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 <mjijackson@gmail.com>

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

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! ;)

> 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 ;-)
After all, when you've set up an Arch system, you have a pretty good 
insight
already...

On Wednesday 01 July 2009 02:47:29 pm Fabian Streitel 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.

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

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.

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