All The New Stuff You Can’t Use
Do you get excited about new language features? Probably. Can you use them immediately at work? Sometimes. If you write software that you distribute though, you often can’t!
Wouldn’t it be awesome if I could get all of the Python Package and Ruby gems (and CPAN) as RPMs on EL 4 and I get to pick my interpreter version (any version I like) and be able to choose from multiple interpreter versions to run on the same system?
Part of the problem with writing software that you want to be easy to set up and install for users is that you can’t use the shiny newness. For instance, if you have to support EL 2, you won’t be excited about new features in Python 2.5, as you’ll never be able to use them. Same deal with Rails 3 or TurboGears 4000.
If you are a hosted service, you could decide to do a lot of work and become a mini-distribution (packaging these things for yourself and tracking security updates and other bugfixes), but that’s a lot of duplicated IT across the world for everyone trying similar things. Each new library you want to use becomes a discussion with IT because someone needs to package it and look after updates. Ouch!
I am not a fan of the java-style mode of deployment as it seems to imply a great chance for security vulnerabilities (due to lack of updates by packaging a sub-module with your code), retards progress, and also tends to encourages forking. However I can kind of understand why it occurs. Fear of the outside world breaking your code, or not being able to deploy what you want where you want it.
Virtual appliances are also the wrong answer to deployment, because of the same update concerns, and the fact they take a sledgehammer to the problem and waste resources.
Ideally what I think I want is a cross-distribution build server that all upstream software projects could use that would automatically build packages for different interpreter versions and distributions. By cross distribution I not only mean all of Fedora, CentOS, and RHEL, but also Debian and Ubuntu. If we are lucky, also OS X. I’m tired of OS X deployments working differently.
Then I should be able to do:
yum install python25-simplejson python24-simplejson
and run the same interpreter on the same box.
Some issues are to be had with contention over Apache, I’m assuming, though I think it would be really awesome if we could take every hosted service developer in the world out of having to maintain their own libraries when Enterprise Linuxes are too far behind and the likes of Fedora or Lefty Lemur are too fast-changing and unstable.
I don’t forsee this happening, of course… but you know… sometimes I think it would be nicer if the newness was easier to deploy on the oldness. To do this though, we really have to take the human distro-specific packagers out of the equation, and make a build service that is very very encouraging for all upstream developers to use. And it should (because of the upstream focus) ideally involve a partnership between distributions. This may also require unifying Debian and RHEL packaging in order to gain widespread adoption of software developers packaging their own content and submitting it to common build servers. If possible, do OS X as well.
Also, I want a pony.