Re: it's safe to run a web hosting server with the unstable distributions ?
One of the most interesting things that actually got me charmed with
debian was a copy of debian 0.99beta that I had on some old cds. I
remember that day well. There were some problems and some functionality
missing but overall it's useful. I could install almost everything in the
distribution on my entire small partition and it worked great.
If you need source that badly or ever need it in the future just get some
copies of everything and burn some CDs for permanent archival storage. You
can't go wrong there.
I think in upgrading something like perl4 you could hire say one
programmer to do a temporary job and be on call for you. Then fix
everything. I may be incorrect but isn't most of the core language of perl
pretty much constant? Kind of like C/C++ or perl/delphi
On Mon, 10 Apr 2000, Phil Pennock wrote:
> 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
>
>
> --
> To UNSUBSCRIBE, email to debian-isp-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: