

Ruby 1.8.7 retired - dicemoose
http://www.ruby-lang.org/en/news/2013/06/30/we-retire-1-8-7/

======
pvnick
My goodness, I have very little experience with Ruby and I'm currently in the
process of trying to get a rails 3 app from github running on my osx system
(1.8.7 default ruby version). I have spent the past several hours fighting
with ruby versions and dependencies with the only glimmer of hope being
successfully getting a hello world rails 4 app running.

Seriously I thought ruby was supposed to be a beacon of simplicity? Someone
please tell me there's a light at the end of this tunnel.

Edit: Some folks have mentioned getting the RVM. I think I was unclear when I
just said I've been fighting with ruby versions - I meant that all of this was
done with RVM/gems/bundle/etc, but it's still been a p.i.t.a.

~~~
cleverjake
If you are just trying to hack something together - don't worry. 1.8.7 has
worked for a long time, and it will continue to do so for a while.

But if you are actually trying to build something to use long term - as crappy
as it is to hear it now, it is not a great idea to use the system version of
ruby. since it is likely as you get into ruby that you will have multiple
projects which amy or may not require different subversions of ruby, you
should always use rvm. it allows you to install multiple versions of ruby side
by side.

also, check out
[https://github.com/tokaido/tokaidoapp](https://github.com/tokaido/tokaidoapp)

~~~
VeejayRampay
Really waiting for Tokaido to be real-life-ready, it is extremely promising.

------
__mp
The whole ruby ecosystem is a nightmare for system administrators.
Ubuntu/Debian still ships with ruby 1.8.7 and 1.9.1p0 (which is evil I heard).
In order to install a new ruby version one has to most likely compile it from
scratch: \- Since there are no deb packages and there is no sane way to build
deb packages \- Overriding system ruby has to be avoided since we manage the
whole infrastructure with puppet (yes you can run it with 1.9x). Since we want
to keep the ruby environment sane.

It get's really interesting once you use puppet to install an RVM ruby
version. Which you then use to install $GENERIC_RUBY package (ie Gitlab) via
Puppet.

I don't want to talk about the mess called "Puppet"...

~~~
regularfry
> The whole ruby ecosystem is a nightmare for system administrators.

It's getting better.

John Leach over at Brightbox has a ppa with up-to-date binary ruby packages:
[http://blog.brightbox.co.uk/posts/next-generation-ruby-
packa...](http://blog.brightbox.co.uk/posts/next-generation-ruby-packages-for-
ubuntu) [https://launchpad.net/~brightbox/+archive/ruby-ng-
experiment...](https://launchpad.net/~brightbox/+archive/ruby-ng-experimental)

I'd suggest giving them a go, and mirroring them inside your infrastructure if
they work for you.

It's very annoying that checkinstall doesn't Just Work for recent ruby builds.
If it did, I'd suggest that every time.

> It get's really interesting once you use puppet to install an RVM ruby
> version.

Yeah, don't do that.

~~~
__mp
>> It get's really interesting once you use puppet to install an RVM ruby
version.

> Yeah, don't do that.

Why not? Puppet-RVM ([https://github.com/blt04/puppet-
rvm](https://github.com/blt04/puppet-rvm) ) works very well. And puppet is
basically a system documentation. Since it's clear what's installed on the
machine.

~~~
regularfry
First, you're introducing deployment-time dependencies on network resources
you don't control. The worst time to discover just how bad an idea that is is
when you've just had a critical server go pop while rvm.io (for instance) is
having DNS problems, and you've got clients, bosses and clients' bosses
breathing down _your_ neck to fix it.

Second, it implies you've got build tools installed on your production
machines. That's bad for security.

Third, I've seen RVM screw up too much to trust it. It's got far too many
moving parts, and so far I haven't found anything I need which it does that
isn't done better by some other simpler tool.

------
JoshGlazebrook
So is Apple finally going to update the version of ruby that comes already
installed on osx?

~~~
charliesome
Mavericks ships with 2.0.0

~~~
sergiotapia
No more RVM! Fantastic news!

~~~
sjtgraham
PSA: Do not use system Ruby -
[http://robots.thoughtbot.com/post/54109839209/psa-do-not-
use...](http://robots.thoughtbot.com/post/54109839209/psa-do-not-use-system-
ruby)

~~~
alrs
Correct.

Don't use rvm or rbenv on your production Linux boxes. Use packaged Ruby
there.

~~~
enko
Er, why not? rvm was originally made for production use!

I've used rvm in production for major sites for years with no problems
whatsoever, in fact I believe it is best practise. Do you have any reasons for
your preference for packaged ruby?

~~~
regularfry
Best practice says production boxes shouldn't have compilers installed.

~~~
judofyr
Install compilers on one machine, build Ruby, package it up as a
deb/rpm/whatever, distribute to other machines.

~~~
regularfry
Yep, that's the idea.

~~~
enko
Sounds like an awful lot of work for no good reason I can think of.

You'll need a compiler, anyway, once you start trying to use any number of
libraries requiring compiled C extensions.

"No compilers on production!" might be true elsewhere but I can't see any
reason it applies for ruby deployments.

~~~
regularfry
> Sounds like an awful lot of work for no good reason I can think of.

Perfectly reproducible deploys and shutting down attack vectors are both
_very_ good reasons.

> You'll need a compiler, anyway, once you start trying to use any number of
> libraries requiring compiled C extensions.

Only if you're doing `gem install` in production. Guess what? That's not a
particularly good idea either.

> "No compilers on production!" might be true elsewhere but I can't see any
> reason it applies for ruby deployments.

Ruby isn't special, or magic. It doesn't get a free pass "just because." If
you've got reasons it should be exempt from the best practices that have been
learnt elsewhere, let's hear them.

~~~
enko
In the real world, we don't have unlimited time, so we have to try to balance
effort required versus the outcomes we desire in order to get the best "bang
for buck" out of our time. Your suggestions are incompatible with this
imperative.

> Perfectly reproducible deploys and shutting down attack vectors are both
> very good reasons.

No they're not. Firstly, I already have good enough deploys. Secondly, the
attack vector you're talking about - having a compiler installed (!) - is
almost not worth mentioning and certainly does not justify the huge extra
effort. We're running a business here.

> Only if you're doing `gem install` in production. Guess what? That's not a
> particularly good idea either.

Says you, and pretty much only you. Anything else is a massive inconvenience.
Everyone does this. It may not be "perfect" but again, we are running
businesses here.

> If you've got reasons it should be exempt from the best practices that have
> been learnt elsewhere

No, it doesn't work like that. "Best practice" does not mean a blind adherence
to some decade-old set of irrelevant rules ahead of all practical operational
priorities. What the ruby community has is a practical balance - workable,
efficient, fast. What you suggest rings of a disconnected IT department with
no incentive to make life easy for those trying to iterate fast. It smacks of
ass-covering and excuses; I know it well.

You've not made any points I find compelling in the least. Anyway, I don't
wish to argue about it, I simply wish to point out, to any others reading
this, that your opinion on best practise for ruby deployments is
controversial, to say the least.

Anyway, I doubt you've actually done any deployments at all in accordance with
the ridiculous "best practise" you've outlined. I doubt anyone has. I, on the
other hand, have had great success with my approach, as have countless others.
As usual, the armchair quarterback has any number of wise-sounding criticisms,
but is not actually in the game.

~~~
regularfry
> Secondly, the attack vector you're talking about - having a compiler
> installed (!) - is almost not worth mentioning

I would mention "reducing the attack surface" and "privilege escalation", but
you've already decided you know best on that front. Given the choice between
"running a business" and "running a business securely"... well, you're happy
with where you are on that spectrum, clearly.

>> If you've got reasons it should be exempt from the best practices that have
been learnt elsewhere

> No, it doesn't work like that.

I'm afraid it does. Ruby may have a "practical balance", as you put it, but
unless you can demonstrate, in specific, why it's better than established
practice, the best practice stays. Otherwise you can't possibly understand the
trade-off you're making. Blind adherence has no place here, in either
direction.

I know Ruby has shiny tools for doing this stuff, but you're trading getting
it done _right_ for getting it done _now_ when you don't actually know how
much work doing it right would take. I can tell, because you seem to think
("huge extra effort"? Seriously?) packaging is hard.

> Everyone does this.

The Ruby ecosystem is the one claiming exceptionalism here, it's down to
Rubyists to demonstrate why it's better, for instance, to gem install directly
to production rather than build packages, and why it's worth risking rubygem's
failure modes in addition to those which might affect the packaging system.

I get that it's comforting to travel in a herd. It's valuable to stop and
question where that herd is going, and ask why the grass under your feet isn't
better trampled.

> your opinion on best practise for ruby deployments is controversial, to say
> the least.

As an opinion on deployments in general, it really isn't. Now, tell me again
why _ruby_ deployments are special?

> As usual, the armchair quarterback has any number of wise-sounding
> criticisms, but is not actually in the game.

Heh. Cute. Wrong, but still cute :-) We can, and do, push out several ruby app
deployments a day via apt-get, when we want to. Nothing stops us from
iterating fast. You can have your cake and eat it too.

~~~
enko
Sorry. I do not believe you deploy ruby apps of any significance. Your
opinions are way out of alignment with the rest of the community. You're
trying to paint yourself as some kind of "voice of sanity" security-wise but
it is unavailing IMO.

Convenience vs security is _always_ a tradeoff. You advocate a total lack of
convenience, for a minimal, at best, gain in security (any issues are likely
to be at a far higher level). I find your arguments unconvincing, to say the
least, and I would decline to implement your suggestions at the 4 or so
companies my opinions hold sway.

> it's down to Rubyists to demonstrate why it's better, for instance, to gem
> install directly to production rather than build packages

Great, an easy one. Ruby has its own packaging system and uses bundler to
determine dependencies. Using this system I can install the dependencies -
which may include complex custom compilations against local libraries -
immediately and conveniently. I can update it any time I want.

You can't. You have some crazy manual system of packaging these compiled
libraries then distributing them via some private repo. For what? You gain
nothing. Now all deployments are some house of cards game of trying to get the
sysadmin to package up the right X when you need it. Instead of the devs being
able to deploy directly. Why would you even bother?

> I get that it's comforting to travel in a herd.

Stop trying to paint yourself as the sole voice of reason in an insane world.
In this case, the herd is doing the right thing.

> We can, and do, push out several ruby app deployments a day via apt-get,
> when we want to

Bullshit. Sorry, but I don't believe a word you say. You have never deployed
apps for a company who cares about speed and efficiency, like a startup. If
you had, you wouldn't hold these ridiculous beliefs.

~~~
sjtgraham
> Sorry. I do not believe you deploy ruby apps of any significance. Your
> opinions are way out of alignment with the rest of the community. You're
> trying to paint yourself as some kind of "voice of sanity" security-wise but
> it is unavailing IMO.

Wow. Appeal to authority and ad hominem in the first line. Good start!

------
steveklabnik
Matz said a few days ago at the European Ruby Conference that the 1.8 -> 1.9
transition was a 'once in 20 years event' and that Ruby would not break
backwards compatibility this way again until a theoretical 3.0 release which
wouldn't come out for a very, very long time.

------
mhartl
I love how he apologizes for his "limited" English and then drops a line like
"[Ruby] 1.8.7 was the last scion of that clan." If that's "limited", then
we're all in trouble.

------
IzzyMurad
That's exactly why I went with Django/Python instead of RoR/Ruby.

I have no problem with keeping software up-to-date but I don't want to make
that a main task because some "cool" kids easily get bored and keep phasing
out stuff which break production apps and/or causes security issues.

~~~
fbuilesv
If you "have no problem with keeping software up-to-date" then don't complain
about these type of changes. As developers we either are responsible about
version policies or we're not. Let's take Ruby 1.8.7 as an example:

If you were responsible you went through several patchlevels of Ruby 1.8.7,
you're using the latest release (to fix security issues if nothing else) and
you had _five years_ to migrate to 1.9 (which most likely meant changing
nothing in your code, just testing it).

If you were not responsible and you're running on something different to the
latest patchlevel version then you're already running on faulty/unsecure
software. Killing support upstream (again, after _five years_!) is not likely
to change whatever you were [not] doing.

PS: Please don't refer to people like the ruby-core team as "cool kids who
easily get bored". We all have our biases but name-calling doesn't add
anything useful to discussions.

~~~
blablabla123
> and you had five years to migrate to 1.9

Given that you were at the project right from the start and allowed to spend
time necessary. It's funny to hear people moan on the one hand about corporate
that use Java EE or even Cobol but on the other hand refuse to accept that in
order for their software to be usable, it needs to be stable in some senses.

~~~
fbuilesv
When you joined a project is irrelevant. If you were hired two days ago and
only found out about this now: tough luck, you have some work to do [0]. Even
"stable", older platforms like Cobol have to deal with this (Micro Focus makes
money off it with products like their Cobol set of tools
([http://www.microfocus.com/mcro/cobol/index.aspx](http://www.microfocus.com/mcro/cobol/index.aspx))
[1]).

[0] Or maybe not. Your non-core [2] apps that run on 1.8.7 will still work
tomorrow. Most of these applications are internal too so the risk is even
less.

[1] There's almost always a 3rd party vendor who'll take advantage of a
situations like this. They will make it your life easier and they'll charge
you accordingly. See [http://railslts.com/](http://railslts.com/) for another
example.

[2] If the applications that are putting the food on your table are running in
an environment where no one thinks about this kind of stuff, then maybe it's
time to take the wheel and start educating your team on why this is important.

~~~
blablabla123
[0] Precisely.

[1], [2] After all management does such decisions. I have warned people face-
to-face, via E-Mail, through all possible channels. So if things go wild, it's
their problem, not mine.

