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.
With or without the unicorn horn?
Definitely with. I’ll take a pegicorn if I can get it.
Now that you mention it, ponies also smell and sometimes bite.
You might take a look at openSUSE Build Service. I don’t use it and am not especially familiar with it, but it’s purpose is for building packages for multiple versions and distributions, not just openSUSE.
I don’t think it has special tools for compiling software with different versions of a language interpreter, but there might be something feature that can be used that way.
http://build.opensuse.org
http://en.opensuse.org/Build_Service/cross_distribution_package_how_to
Kyle, yeah that doesn’t quite do that.
Fedora also has a build service, the trick is doing multi-distro builds, supporting multiple interpreters, and so forth. And getting every library developer to use that.
In other words, it is kind of impossible.
I don’t think doing away with the manual distro-specific packaging is going to work. All the cross-distro and/or automated packaging stuff I’ve seen so far sucks.
I see “enterprise” distributions as more of a problem than a solution. People should just run current software, then we can use current software’s features in our own current software. I don’t see why I should be supporting a 2004 Python (2.4) in a 2009 software. The biggest problem software has at the moment is people never upgrading it.
Yeah perhaps that’s it… by mixing current and non-current, you get a whole class of funness.
I have run into a few large Fedora clusters and the like (some doing some very impressive things), but it’s the exeception, not the rule.
Though if you go that route, you have to keep porting your app to keep up with the versions of things that have very bad API compatibility…. some apps better than others, which hitches your business/work/lab/etc to the distribution’s sometimes very short timelines… and makes you have to keep up with lots of upstream activity.
I think though, long term, and by long term I mean long term for the good of the planet (not a business), moving technological things forwards faster is a worthwhile goal. With each evolution in Technology X, it /should/ become easier to develop new and better technology. This isn’t quite always true though, but usually seems to be the case.