Re: it's safe to run a web hosting server with the unstable distributions ?
Typing away merrily, cfm@maine.com produced the immortal words:
> So perl is perl4. That creates problems for users typing in perl and
On one service, yes. But that service predates perl5.
Upgrading the hardware for Y2k was fun - when was the last time that you
tried finding the source for perl4?
> expecting it to work. At a certain point it is simply cheaper for you
> to bite the bullet and upgrade them for free, no? Because you are starting
> to twist everything else too. And then when you do that free upgrade
> all of a sudden you own everything else that goes wrong too, even if
> you made **less** go wrong. Been there - we start year 7 on May 1. :-)
It would be nice to be allowed to just use find/ed to change all scripts
with /bin/perl to /bin/perl4 - but first you, eg, need customer
permission for that. And to sort out who's liable if something breaks.
Eg, the find/ed isn't as simple as it might appear at first sight -
remember the perl trick of using /bin/sh and the first three lines sort
out finding the interpreter for you? I think that service is the one
where the root directory for customers logged in with a shell is the
same as the one for the web-server, so /bin/sh is available, so that
trick may very well be in use.
But yes, I don't want to be in the position of still having /bin/perl be
v4 in five years time. But, given the workload in working through 1,500
customers' scripts, you'd be looking at:
* people to co-ordinate this with the customers
* people to fix the scripts
* people to test
which leaves you with one of:
* heavier workloads for various departments, perhaps an extra employee
in various places, just for upgrading perl
* a dedicated temporary team, hired to manage this upgrade
Methinks it would be more appropriate, given out situation, to find a
way to get permission to automatically replace /bin/perl with
/bin/perl4, do so, run some scripts which try to look for monstrosities
like scripts which invoke perl interpreters, fix those, remove the
/bin/perl link and then just never ever let /bin/perl exist again.
> I think you are on right track with phase-out policy. It really is
> a business service issue and needs to be addressed that way. What
> do you provide, etc....
And this is much easier if you can manage easily which version of perl
is being used. So, when someone asks how to go about things, they can
get one of three responses from me:
* silence (I'm too busy)
* just install /bin/perl (I really don't like them)
* the advice I gave about numbered versions (I'm in a helpful mood and
trying to save them headaches later)
Relying on timely response from customers from customers does not scale.
Searching for a magic bullet is naive. Trying to design things right
first time isn't perfect, but it makes life easier in the long run, at
the expense of more work at start-up time.
--
HTML email - just say no --> Phil Pennock
"We've got a patent on the conquering of a country through the use of force.
We believe in world peace through extortionate license fees." -Bluemeat
Reply to: