So, you're saying I can put shit back together and not have that one, "where the hell does this go?" part left over?

Sign me up!

Allow me to translate:

  1. Screw job-creating clean energy technologies and drill, baby, drill.

  2. Gut what little worker protection we have; outsource to the lowest bidder.

  3a. Save $$ by shifting responsibility to states that we all know can't pay.

  3b. Turn education over to private companies who are only interested in
              increasing profits.

  4. Cut the programs that aid people in need but don't touch defense that
        fund megacorps and generate kick-backs.

  5. Screw clean water, clean air, safe food, safe medicine, safe work
          environments, safe vehicles, safe bridges, protection of civil rights,
          a free and open internet, private property rights* or anything else
          that might reduce profits.

The entire plan can be summarized: Maximise profits by socializing the risks
and costs. It's the Bush III plan.

* like granting unsupervised emminent domain power to a foreign corp
(TransCanada) to take land so they can move highly toxic sludge that no
one knows how to clean up (see "Enbridge") through the entire middle of our
country so they can ship it to other, foreign companies.

"Seriously? A new box that doesn't work right in XP? Like others have mentioned, how do you not look immediately at the BIOS?"

Because it's 2012 and buying a bunch of new boxes to put XP on makes about as much sense as committing the future of your business to COBOL running on CP/M?

Just because you can get something to work doesn't mean you should.

Perl (and Ruby and Python) already have mature packaging systems and they really don't need to interact with each other.

False. Say you have libFoo and Perl, ruby and/or python wrappers installed via their "mature packaging systems." Now, libFoo has a critical security vulnerability that requires an updated package with an API change. The system package management tool will happily upgrade the library and break the wrappers you use for production.

There is no, sane way to use multiple software management tools effectively.

easy_install works just like CPAN. Download and install stuff so the standard distribution software management tools are now worthless for:

  1. Knowing what is installed on which production machines (basic software inventory)
  2. Reporting packages with dependencies on a package with a newly reported security issue
  3. Automatically upgrading to new releases
  4. Easily rebuilding and deploying to multiple hosts on different architectures and different releases of distros (possibly different distros)
  5. Managing dependency conflicts between different packages

and more that escape me right now because I haven't finished my coffee yet.

CPAN, easy_install and their ilk are wonderful for the developer that needs a bunch of stuff to get their application working. They are evil incarnate for the administrator that needs that application to work reliably and consistently on more that a couple of machines.

There is a huge difference between "easily installing stuff" and managing systems. The second you add anything that "works around" the standard way of doing things, whatever standard you've adopted, you've abandoned all hope of having standard operating procedures and consistent production management.

This is why systems administrators get so edgy... Every developer, user, language community, or whatever, thinks their little exception makes life easier. Exceptions don't scale.

Ok, they do scale. They evolve into chaos.