Actually I believe a few ar problems with the parent poster:
"* Rearranging everything to fit their naive 'filesystem hierarchy'(this completely fucks up a decent packager like Ruby Gems)"
The FHS is a known standard which works with every language. What specifically about Ruby makes it unique amongst all other software?
Gems (like NeXT / OS X .app bundles) are self-contained, with the documentation and data resources alongside the code in a standard way. This makes it very easy to support having multiple versions of the same software installed simultaneously, with an optionally qualified import statement to disambiguate.
The FHS inspires maintainers to large amounts of useless and regressive tedium in re-separating the peas and the carrots into global piles. It's not so bad with traditional C libraries, but the brokenness is immediately obvious when dealing with the libraries of a language that has anything resembling a module system.
What's specific to Ruby is that their community somehow managed to not fuck up their packaging medium.
Yes, but native package managers already allow multiple versions to be installed simultaneously.
'What's specific to Ruby is that their community somehow managed to not fuck up their packaging medium.'
Overwriting global binaries in /usr/bin is pretty fucked to me, and I don't think I'm alone in that. Say I'm using puppet or OVirt or other Ruby based system apps - I wouldn't want Gems breaking them. If Python did this (being the basis for most Linux distros) or Perl did this on older Unix there would be hell to pay.
The FHS is a known standard which works with every language. What specifically about Ruby makes it unique amongst all other software?