Ruby dissonance with Debian, again
Lucas has written two long, insightful posts on the frustration about the social aspects of integrating Ruby stuff Debian – The first one, on September 12 and the second one, on September 29.
I cannot really blame (thoroughly) the Ruby guys for their position. After all, they have a vibrant community, and they are advancing great pieces of work. And they know who that code is meant for — Fellow programmers. And yes, although it is a pain to follow their API changes (and several of the Gems I regularly use do often get refactorings and functionality enhancements which break compatibility but introduce very nice new features), they say that’s solved with one of Gems’ main features being the simultaneous installability of different versions.
The key difference in Debian’s worldview with Ruby’s is they cater to Fellow programmers. Even leaving aside heaps of different positions and worldview/mindset, we have a fundamental difference: Debian cares about its users, whatever that means. So, our users should not even care what language a given application is implemented in – They should only care that it works. We, as packagers, should take care of all the infrastructural stuff.
And yes, that’s where we find the conflicting spot: We don’t want to ship many versions of a system library (that in this case would be a Gem). Specially if later versions fix known bugs in earlier versions and backports are not available or supported. Specially if upstream authors’ only response to a bug in an older release will be “upgrade and rewrite whatever breaks in your application”.
As an example of this, I am not currently updating the gems I maintain, as Debian is on a freeze to get out the next stable release. Or if at all, I am targetting those uploads to our Experimental branch, in order not to create a huge backlog for me when the freeze is over (just a series of rebuilds targetted at unstable). And yes, I will have to be responsible for any bugs that will most likely not be supported by most of my upstreams during the next ~2 years.
That’s the role of a Linux distribution. And yes, as Lucas writes in the comments he got as responses to the first post – This dissonance comes in no small part because the Ruby developer community is mostly made from non-linuxers. People coming from a background where (mostly propietary) applications bundle up everything they need, where static linking is more popular than dynamic libraries, where there is no coordination between parts of the system are much less likely to understand our work.
And yes, the Perl community is a joy to work with in this regard. And that’s the same I understand from the Python one. Because of their origins and where their main strength was grown and remains.
PS - And yes, I will join the flock of people saying that… The specific person that attacked your work is a great programmer, but well known as intolerant and obnoxious. Fortunately, even if our respective cultures fail to mix so much, most of our interactions just end with a “sigh” of lack of understanding, and not with the flames you got targetted with :-/
Comments
Anonymous 2010-09-29 12:02:46
they don’t cater to Fellow programmers
The key difference in Debian's worldview with Ruby's is they cater to Fellow programmers.
No, they don’t. It’s not that they cater to fellow programmers but that simply they don’t matter and/or don’t know any better.
I hate being harsh here (after all, it’s mostly volonteer effort, so it’s up to them to see how they spend their time), but that’s the way it is, so let’s “render unto Caesar the things which are Caesar’s”.
So I say that they don’t care because it’s of no benefit for any fellow programmer having to spend his time rewriting an already working functionality just because the component developer (the gem, in this case) didn’t care about backwards compatibility, instead of allowing for his fellow programmer to use that time providing new and exciting functionality (multiplied by the number of programmers all around the world that will have to expend their time in such a “broken window fallacy” type of activity).
And I say that they don’t know any better because if they did, they would know what are the problems with no backwards compatibility, with the “static linking-like” approach to systems architecture, the horrors that come with the rising of glass walls between development and operations, and on top of all that, they would know how to cope with that, since all of them are things old by about 30 years by now.
David 2010-09-30 08:11:57
Ruby dissonance with Debian, again
I retired from Debian a while ago, but Zed’s rant really pissed me off. What a load of horse shit… “debian business plan” indeed.
Enrico 2010-09-30 08:09:40
Catering for programmers
I disagree with this bit: “The key difference in Debian’s worldview with Ruby’s is they cater to Fellow programmers.”
As a fellow programmer, I am infuriated by libraries that do not maintain a stable API. I avoid them like plague, as I know that if I base my work on them I’ll pay with blood every caprice of their developers. If a library developer does not care that the software written by me, his user, keeps working, that library developer does not deserve my respect or admiration.
I posted along these lines here: http://www.enricozini.org/2010/cazzeggio/when-a-framework-is-worth-of-any-attention/ after untold frustration from the behaviour of the python community, so when you say “And that’s the same I understand from the Python one”, I’m not sure it matches my experience.
gwolf 2010-09-30 08:18:02
Re:
Yes, Zed Shaw is well known for pissing people off. And many Rubyists are very, very vocal and obnoxious. Still, many are a joy to work with - As everywhere, I guess…
gwolf 2010-09-30 08:22:26
Re: Catering for programmers
Yes, I understand and agree with your point – I tried to see things from their point of view when I wrote my post. FWIW, I have spent way too much time updating Rails 1.x applications to 2.x – And that does not mean that upgrading from 2.0.x to 2.1 to 2.3.x is painles, not by a long shot… It’s only not half as traumatic as a major update. And I still don’t dare get anywhere near 3.x.
But that’s the Rails culture for you. And yes, they say it upfront: This is opinionated software. And in their opinion, I guess, once an application has reached production, you should just freeze its gems, its Rails, and stick to whatever it was developed in. Oh, do you want to continue supporting it? Well, good luck.
Sucky ways, to say the least.
Marcelo 2010-10-02 06:58:46
No, they don’t
The key difference in Debian's worldview with Ruby's is they cater to Fellow programmers.
No, they don’t.
I have wasted enough time trying to get multiple Ruby libraries to work together because of this lack of API design. Rubygems might sound like a good idea, but it does not scale. It’s enough to have two frameworks that use different, incompatible, versions of the same library to get into a big ugly mess. Rails “solution” to this is to build monolithic applications without truly interchangeable parts.
I have encountered this problem with Perl, but never to the extent it happens with Ruby.
What they do care about is getting things working quickly. That’s a very different goal.
Marius Gedminas 2010-09-29 13:53:30
Python community and Debian
The Python community has this problem too, or a less severe version of it. Some people go all the way to declaring that system Pythons are unsupported, and you should therefore always build your own from sources.