Matz: I use Debian, I have no Ruby problems. | Hacker News Reader

Matz: I use Debian, I have no Ruby problems.

ruby-forum.com

63 pointssteveklabnik54 comments

It's great that manual compilation works for Matz. And his great work notwithstanding, it has little to do with the general user.

As an occasional Ruby programmer, and frequent Ruby-based utility user, I do not want to compile and install Ruby or Ruby modules myself. If we go down that road, why don't we compile everything from Python to GStreamer ourselves (since they all have modules/plugins/...)?

To the general user (as opposed to full-time Ruby programmer), Ruby and Ruby modules are just dependencies to the application they want to use, and installation should be automatic. One can only hope that the Ruby community understands this, and makes it easy for distributors to package their software.

As an occasional Ruby programmer, and frequent Ruby-based utility user, I do not want to compile and install Ruby or Ruby modules myself.

I empathize with you, I am the most non-techie programmer I know and I dislike compiling things from scratch. (deep breath) HOWEVER...

The culture of programming on star-nix platforms is built around building stuff yourself. It's great when there is some form of Ruby pre-installed by default on OSX, for example, but every serious Ruby programmer must go out and compile the latest version(s) at some point or another.

I wish there was an easier way, and I applaud the folks building package managers, rvm, and so forth. But underneath all these tools is a compiler, that's the architecture of star-nix paltforms and programming for them. Everyone needs to understand what their abstractions are hiding.

The only way you can make an informed choice about the convenience and security implications of choosing to use rvm or some such is if you understand how to compile Ruby for yourself on your platform.

If that isn't your bag, I will push back and ask why you're programming on a star-nix platform?

True and un-true. Yes, compiling software is at the heart of Unix programming. However, automation with regard to systems management is also at the heart of Unix programming. All these package management systems evolved to solve a very complex set of problems.

Compiling Ruby by hand is fine if you're running purpose-built VPSs, or cloud instances, or whatever the hip new phrase is, but for people who manage systems in the old world where 1 machine = 1 OS install and multiple, commingled services, it's an entirely different ballgame. Managers of these systems can't vet each and every interpreter on the system.

If someone in web integration walks through the door with a request for a Ruby interpreter to use a set of scripts for integrating the company's new website with the old back-end finance systems, the sysadmin's first stop is the stable package repository for their chosen distribution. Compiling by hand is yet another exception that must be tracked.

In enterprise environments were IT staff are outnumbered by a couple of orders of magnitude, exceptions are the proverbial "death of a thousand cuts". That is why failure to play ball with package management systems like apt is a poor choice. It will hurt the adoption of Ruby in many environments.

If that isn't your bag, I will push back and ask why you're programming on a star-nix platform?

I pretty much disagree with your whole point. I mostly program C, C++, and Prolog on *nix, and I rarely have to compile anything except for my own software (obviously). Debian provides nearly all libraries I'd ever use as a package.

If other people want to use my software, I can tell them to install dependencies such and such, or even provide a Debian package of my software. I don't want them to need to put the effort in reconstructing my build environment.

I dislike compiling myself because then I also have to deal with upgrading them. Sometimes building is a pain because programs have arcane build steps, or are less-secure by default. I certainly don't trust myself to compile network programs (apache etc) with the most secure options. Paradoxically, I think it's safer for me to rely on packages than to compile myself. Maybe I'm being naive. :)

Have you tried rvm?

  bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head )
  rvm install 1.9.2
  rvm use 1.9.2 --default
  which ruby

EDIT thanks telemachos, add this to either zshrc (if you're using zsh) or bash_profile or equivalent

  [[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm"

Are you seriously suggesting using a a package system that is bootstrapped by downloading and running a shell script with no security protections whatsoever?

Moreover, it's not just you giving a bad example, as the shell script then clones a git repository, again with no protections whatsover (over http by default to make it really easy to MITM attack), and runs code from it. So this was written by people who just don't care, or don't understand security. Not people I'd be trusting with package management on my system.

This kind of thing might have been acceptible, barely, before 1995. Since then, we've developed package systems with gpg signed chains of trust.

The script itself is transparent. In fact, rvm's site suggests[1] reading it before using it by running the internal curl command in a terminal.

Beyond that, if joeyh is Joey Hess[2], I would be curious to hear how you think Ruby devs and Debian might work better together to fix the current situation (assuming you don't think everything is fine from Debian's point of view and screw the Ruby devs). I'm not trolling or baiting. I am a Debian user myself (since Etch was testing), and as someone who uses Ruby regularly, this whole thing drives me nuts.

[1] http://rvm.beginrescueend.com/rvm/install/

[2] http://kitenet.net/~joey/

90% of users won't read a script if you ask them to.

9% of users will read the script but won't notice my carefully concieled exploit code -- because my exploit code is just another seemingly innocent "curl $evil | sh"

And if 99% isn't enough, you just MITM the github connection instead.

(I am he. If I had an serious opinion I'd not post it here though.)

I think you're being _just a bit_ reactionary.

Besides if you git clone, literally _every commit_ is checksummed. I'm no security expert, but I don't think MITM-ing a 'git clone' sounds 'really easy.'

No, you're clearly not a security expert. If you're doing a git clone over HTTP, you can't even be certain you're talking to the right git repository. Sure, each and every commit may be checksummed, but how exactly do you anticipate knowing what the correct checksums are?

Fair enough. Like I said, I don't know enough about this.

> how exactly do you anticipate knowing what the correct checksums are?

Well, because the repo you're cloning knows what they are... I wasn't thinking about the repo itself being owned, but git's whole job is to make sure that chunks of text get from one place to the other in an identical state, so...

The target repo itself isn't owned, but your connection is. The point is that you only think that you are talking to the correct repo, when in fact you are cloning whatever git repository the attacker would like you to.

It's obviously a focused attack as are all MITM attacks, so you can assume the attacker is familiar with the install script. So when the script then continues and performs it's next action on the contents of the repository, you will execute an arbitrary payload.

Edit: It wasn't clear to me that the problem had become apparent in the parent post. Probably just pre-coffee thinking on my part, but hopefully this will help clarify it for anyone else reading along who also missed it.

Yes, when I said 'the remote repo', what I meant was 'the one that I see.

Thanks for the extra explanation, guys! Makes a lot of sense.

If I was trying to MITM you while you called forth a git clone, I'd first make the network connection unstable. Then, while that happens, go look at what package you're getting is and then feeding you a known bad, but signed, package.

But it's signed :/

Just in case someone uses this as installation instructions, there's a (small but important) missing step. After installing via bash and before installing any rubies, add this to your shell's startup file:

    [[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm"

Then open a new shell and check the output of `type rvm | head -1`. It should return "rvm is a function".

Maybe more importantly, run `rvm notes` before installing any rubies. Many operating systems will need to install various development packages first. `rvm notes` will tell you what you are likely to need for your OS.

http://rvm.beginrescueend.com/rvm/install/

One more small note: this isn't some magic you need to learn, it spits it out when you install it.

Fair enough and a good point. I hang out in #rvm on irc though, and a reasonable number of people manage not to read the notes the installer spits out (or the docs online, which are excellent). But it's a good point, nonetheless.

Yeah, there's a reason why RTFM became a saying...

I wasn't trying to criticize, I just wanted to point it out before someone said 'good luck figuring that one out.'

Fantastic, he says he does not want to compile Ruby and modules himself and you give him a solution doing exactly that.

I mean, apt-get install will also compile from source, if you have the right repositories enabled.

The complaint about 'compiling from source' is that you have to manage the compilation yourself, the paths, where it's installed, etc. rvm addresses this problem.

I mean, apt-get install will also compile from source, if you have the right repositories enabled.

No, it doesn't. It will install binary packages that are signed. That means that if I install a package on my local desktop and a server in New York, it will exactly be the same. No matter if there are differences in the environment or configuration. Besides that I want every system file tracked by one package management system (for ease of administration), and easy security updates.

Another important benefit of using binary Debian packages is that you get the testing that preceded progressing of the package into Debian testing for free. Constrast that with a gem that happened to be updated just 30 minutes ago, with no testing in the particular configuration where it is used.

We have been burnt badly in the past by out-of-distro 'package management' before (little testing, incompatible versions, failing builds, etc.), that I stopped using non-distribution packages mostly.

Unless you are referring to kernel module packages that use DKMS (I guess not) or 'apt-get source' which retrieves the source of a package in conjunction with '--compile'. But that's not a very common use of APT.

I was thinking of apt-get source, actually. It's been two years or so since I've used Debian, since our worldviews are incompatible.

> Constrast that with a gem that happened to be updated just 30 minutes ago, with no testing in the particular configuration where it is used.

This doesn't really happen, though. Bundler makes sure that you have the exact same versions of gems that you used everywhere else, and if anyone's got the automated testing thing down, it's Rubists. You won't get the 30 minute old version unless you want to.

You won't get the 30 minute old version unless you want to.

Frankly, I do not want to care. I want the latest stable version with security fixes. With a busy work schedule, I do not have time to maintain a stable set of Ruby modules. It's a matter of economics: you could let every user find out a stable combination of modules, and everyone will end up doing a lot of duplicate work. Or the distributor could do it, saving 95% of the users who do not have specific needs many hours of work. And as a bonus, we all get the collaborative testing and bug reporting that was done in Debian Unstable and Debian Testing.

This approach works well for many interpreters and compilers in Debian (as someone else pointed out, Python is well-integrated in Ubuntu and Debian).

I think we're talking around each other, which is what this whole issue is about.

I'm coming from the perspective of a ruby application developer. I've got my server, it's all set up, I type 'cap deploy' and it takes care of everything, including my dependancies. I don't need to 'figure out what works,' because my application is developed locally, I already have all of the versions worked out, because it's what I was building the software with. This situation is a happy one. Everything's good. Yes, I'm technically using two package managers, but I don't really care: it's all been abstracted away, and everything _actually works_.

If I try to do things through apt, all of the gems simply aren't there. Or older versions of things, which break because my code was written with newer ones. It's simply a non-starter.

However, from a sysadmin standpoint, where you're keeping Ruby on a system for a certain reason, the use case is totally different.

The real problem happens when people who use Ubuntu because they're new to Linux want to start with Rails, and it has to be explained that almost nothing they read will actually work properly. They're the real people who suffer out of all of this, not you and I.

> Python is well-integrated in Ubuntu and Debian

I've heard this before, but I almost wonder if it's the exception that proves the rule. That is, the rule is: your OS is not likely to provide up-to-date development library packages (or interpreters for that matter) for your scripting language of choice. As a developer, you will need to get and build stuff by hand, you will need to manage a complex set of changing load paths, you will need lots of coffee and help. You will come to rely on and love tools outside of the normal distribution tool-chain.

I don't do Python, but this rule has proven to be true for me for Perl and Ruby, on systems including OSX, OpenBSD and Debian. I always end up having to get cpanm to install Perl modules, Perlbrew to install newer (or variant) Perl interpreters and ditto for Ruby, rvm and company. (I dabble in Haskell and Lua, and it's true there too so far as I can tell. But my experiences with those languages are too limited to really say.)

I think that Python is a special case, and I honestly don't know why. Maybe they've figured out something that Perl and Ruby haven't. Maybe it's because Gnome is built using Python very heavily, and Debian ships with a default Gnome desktop and so they care more about Python. Maybe the Python team at Debian is just better staffed. I don't know, but Python is the exception here.

That's part of the complaint. The main complaint though is that it's harder to verify the source of the source because it's nonstandard for your distribution. Ideally, if you're building on a Debian derivative, anything you install comes in through apt-get, with a signed package. If you're on Red Hat, yum. And so on. RVM is not only unsigned, it brings in considerably things to do than apt-get install.

Not a good solution if you dislike stomping on your distro's package management.

I understand the desire to stick with your distro's package management where you can (especially if you use Debian or a Debian-derived distro. APT rocks.)

However "stomping on your distro's package management" is not a fair description of what rvm does nor how it works. rvm is very well crafted to stay completely out of the way of a package manager like APT. If you use rvm normally, nothing is installed at the system level (e.g. /usr/local), much less into /usr/bin (or somewhere APT expects to manage). Everything is sandboxed in $HOME/.rvm/ nice and clean. You can remove it at simply as `rm -rf $HOME/.rvm` and a quick edit of your shell's start-up files. APT is in no way "stomped".

You can also

    rvm implode

    rvm seppuku

and it'll remove itself. Which I always found to be particularly funny.

Hm well, I do use my distro's (ubuntu) default package manager if I'm not doing rails dev (sudo apt-get install ruby rake) but I need to easily switch between ruby versions and rails versions sometimes, so rvm makes my life easier. It lets me create "gemsets" -- it's not that I don't appreciate the package being in the repos or something :) Honestly I don't see the big deal. It's possible that a person might use the repo packages sometimes, and rvm other times. From a purely practical point of view, it seems okay.

Though, if I was able to do that with the distro's packages that'd be cool too.

Additionally, manual compilation works great for your Apple Macbook that you develop on or your podunk website that runs on one machine (the commonality here is that you have one machine), but is a nightmare for any serious deployments where you're getting millions of hits a month and have a a non-trivial number of machines to manage. The last thing you want to do is configure a manual compilation via something like puppet, chef, or cfengine.

Do you know about gem2deb ? https://github.com/thwarted/gem2deb 'Takes a URL to a .gem or tar'ed gem and does the brute force work of converting it to a .deb package'

Assuming this is a response to yesterday's news about Debian's Ruby maintainer, I don't see how it's relevant. Matz is almost certainly compiling his own Ruby (as many Rubyists do) and not using the Debian packages for Ruby.

It's true. I mostly just thought that it was interesting that after reading all that hubbub over the last few days, to pop open ruby-talk and see this...

At the same time, there is a certain amount of relevance: while lots of Rubyists (including myself) talk a lot of shit on Debian, Debian is still the only Linux that is (technically) supported by Ruby. It's this way because the Hudson (or whatever, it's still early...) server is running Debian, and they don't have another box or two... but still, I guess my point is that Debian is important, no matter how frustrating their policies may seem at times.

I'm seeing a trend in the comments re RVM and other suggestions.

There are essentially two issues at hand here and we would all do well to remember the difference between the two.

1. Ruby as a good citizen in a distro 2. Ruby as a development tool for programmers

#2 is mainly achieved via RVM for sure. I program both Ruby and Python and as well as some JS and Erlang. I LOVE RVM for ruby/gem management and actually prefer it to Python's virtualenv (just a preference! Don't bite my head off ;) )

#1, however, is what we should really be talking about as it is what the original debian maintainer was complaining about. Matz is more talking about #2.

I use Ubuntu as my development and deployment platform. I could never imagine if Python was not available, stable and usable as a base package on Ubuntu without me having to do some RVM/Virtualenv incantation each time. Sure, there could be a chef/puppet/script installation approach, but why? And for those who think this is trivial, think about all the packages that are in fact written in Python that are part of the desktop or base system. Python is literally embedded in everything!

One of the greatest things about Debian/Ubuntu, and why I think it is the premier development platform, are things like: sudo aptitude install build-essential

All that being said, this is a very hard problem to generally solve. I would hope that Ruby would be more Pythonic in the distro, but I don't see it being a priority for Ruby folks anytime soon....

Side note: go look up the transition from Python2.6 to Python2.7 for upcoming Ubuntu 11.04 to see what is involved in such a transition. It is non-trivial to say the least but Debian/Ubuntu maintainers are doing a stellar job with it...it is a complex issue and much care is needed...

And as another aside...anyone remember the Ubuntu rolling releases issue? At is core with rolling releases was things like Python2.6 -> Python2.7 transition...not something you can easily achieve in true distro rolling releases and again, just an example of why this is a complex problem and things like RVM are not appropriate for discussion of #2 as it stands.

I agree with much of what you say about the two different threads and perspectives here (and elsewhere) whenever this argument comes up. However:

> And for those who think this is trivial, think about all the packages that are in fact written in Python that are part of the desktop or base system. Python is literally embedded in everything! [...then later...] All that being said, this is a very hard problem to generally solve. I would hope that Ruby would be more Pythonic in the distro, but I don't see it being a priority for Ruby folks anytime soon....

You say that Ruby should be more Pythonic and that this is not a priority for "Ruby folks", but I'm not sure that's a fair way to characterize the distro problem. In fact, from Ruby's point of view, Debian has a special pride of place: it's the only officially supported Linux distro (since testing is done on Debian machines, I believe). For more on that see the discussion and links in this thread: http://news.ycombinator.com/item?id=1614618 (tenderlove is Aaron Patterson, a Ruby core dev).

I would argue, as I say elsewhere in this thread, that the reason Python is so well handled is precisely what you mention in the first bit I quote. Because so much of the Gnome desktop is written in Python, perhaps Python gets special treatment by the distro. That suggests that the distro needs to meet the language devs at least part way, rather than that the language folks are the only ones who need to change their attitude.

Matz compiles. He doesn't use Debian's packaging.

He most certainly uses Debian's packaging for any dependencies he may need.

Or do you think he also compiles stuff like Readline, IConv, Zlib, OpenSSL? Or stuff related to Ruby gems, like postgresql-server-8.4, in case he needs ruby-pg ?

On other platforms even installing GCC is a painful process, when on Debian/Ubuntu is as easy as:

      sudo aptitude install build-essential

And why would he need to compile his own Ruby for stuff unrelated to developing the Ruby interpreter? Are you telling me that if he needs to do some quick processing on some machine he absolutely needs HEAD?

The backdrop on this topic is the recent news of Debian's Ruby package maintainer quitting, mostly due to issues he has with the Ruby core community and the maintenance/release process.

This post by Matz was supposedly submitted to debunk the myth that "Ruby's not for Debian", but it is entirely orthogonal to the issue at hand. Matz undoubtedly compiles his Ruby, as most maintainers would do with their projects, rather than install using Debian's package manager.

If you look at the topic of the thread, it's to a user. The ruby-talk mailing list is for general discussion, and the title of the thread is "Best Linux Distro for Ruby?"

This is where I make two points:

1: I just replied to your sibling, and

2: So do most Debian Rubyists. Through rvm. ;)

I just don't get why this is supposedly a Ruby problem rather than a $LANG problem, when Lucas Nussbaum's complaints about Ruby's packaging situation (sans the whining about Japanese) apply equally well to every other language you might want to install.

It's also pretty hilarious when a guy maintaining one of 50+ different distributions of the same software cries about division of manpower upstream.

A tautology, no? He wouldn't use Debian if he did have problems.

I get neck deep in large Ruby deployments and the issue is clear to me. Ruby is evolving at a breakneck speed but as a result has very poor release management.

My solution:

Use Bash and Python for systems programming. Both are stable and simple well integrated into Ubuntu and frankly much better for the task anyway. Oh no, now I can't use Chef! (sarcasm)

Use Ruby for web development, with RVM and bundler. This is a vast universe of bleeding edge web programming toys.

I struggle to see a real problem here...

" Ruby is evolving at a breakneck speed but as a result has very poor release management."

Just what is changing so fast in Ruby? Is 1.9.2 so much different from 1.9.1? Has anything changed in 1.8.7?

Out of charity to the parent post, he probably meant "the Ruby ecosystem" by Ruby. The larger Ruby world (and especially Rails, which he seems to have in mind) is a place where a tutorial released a month ago for Rails 3, ruby 1.9.2 and using rvm is already out-of-date in a handful of small but confusing-to-a-newbie ways because there's been a new release of cucumber & rspec and people now adore Haml and shun erb.

I've been using Ruby for about 2 years. Before that it was Perl (and still is Perl sometimes now). The difference in the speed of API changes to "major" libraries and tools in Ruby versus Perl seems striking to me, but maybe I'm still too new and need to absorb more. (Another quick example: try to find a book on Ruby - even one on Ruby 1.9.x that doesn't treat Test::Unit as the default test runner in Ruby. Sure, they might mention Minitest, but then they all keep using Test::Unit in all the introductory examples. Argh.)

It may be a misperception, but the pace of change in the larger Ruby ecosystem sure seems breakneck to me.

1.9.1 -> 1.9.2 changed the way threads were handled, which was pretty huge. And good for Ruby.

Ah, OK, thanks.

Still, does this count as "breakneck" change?

I'm not seeing it, but maybe I'm too close to the subject matter.

Who is matz? Everyone seems to know..

The guy who wrote Ruby - http://en.wikipedia.org/wiki/Yukihiro_Matsumoto

Ahhh, ok. Somehow the only japanese i know is the creator of Mario :p Thanks, anyway.

I can't imagine, i'm the only one, who didn't know.

Out of curiosity I've typed ruby matz into the address bar and firefox opened http://en.wikipedia.org/wiki/Yukihiro_Matsumoto (google works)

Fine if you know that ruby here is the important keyword. I thought of something to do with Debian and package management done different then elsewhere.

http://en.wikipedia.org/wiki/Yukihiro_Matsumoto

Reply on news.ycombinator.com