Re^2: blaming perl for not using a build policy

...hat build policy options would fix this problem?

Right, who knows? Who wants to spend the time worrying about it? So what I do is create a user, build a perl in that user's home directory, and update the user's path. Because I'm a web developer, I do the same with apache. Then the application runs from that user's context instead of a system context.

Sure, I have to rely on what the distro provides for most things (networking, a sane compiler, and an easy to use update system). So I start with a distro that I trust for the things I need to trust it with. But for my application, I build the critical components myself.

I don't know how many times I've seen where people deploy thier app using the system provided stuff for critical components (like perl), and then their app busts when they do an update. If the critical core components of the app would have been bundled with the app, the problem would have been completely avoided.

trwww

Comment on Re^2: blaming perl for not using a build policy

Replies are listed 'Best First'.
Re^3: blaming perl for not using a build policy by oknow (Chaplain) on Aug 27, 2008 at 05:02 UTC
I don't know how many times I've seen where people deploy thier app using the system provided stuff for critical components (like perl), and then their app busts when they do an update. If the critical core components of the app would have been bundled with the app, the problem would have been completely avoided. It may avoid one problem, but it creates another. If I am compiling my own Apache then I am also burdening myself with deploying a new Apache (or other component) every time there is a security hole. We already have tools to do this work for us. Whether I update my components manually or let the system do it for me the burden is still on me to actually test that my code still works after the update. Compiling and deploying my own components is more work than letting the system update itself. Testing my own code takes just as much time in both cases. Blindly running 'apt-get upgrade' is just as bad as blindly installing a freshly compiled version of an important component. Either way, it should be simple enough to roll back a package to the previous working version. Oknow	[reply]

Replies are listed 'Best First'.

Re^3: blaming perl for not using a build policy
by oknow (Chaplain) on Aug 27, 2008 at 05:02 UTC

I don't know how many times I've seen where people deploy thier app using the system provided stuff for critical components (like perl), and then their app busts when they do an update. If the critical core components of the app would have been bundled with the app, the problem would have been completely avoided.

It may avoid one problem, but it creates another. If I am compiling my own Apache then I am also burdening myself with deploying a new Apache (or other component) every time there is a security hole. We already have tools to do this work for us.

Whether I update my components manually or let the system do it for me the burden is still on me to actually test that my code still works after the update. Compiling and deploying my own components is more work than letting the system update itself. Testing my own code takes just as much time in both cases.

Blindly running 'apt-get upgrade' is just as bad as blindly installing a freshly compiled version of an important component. Either way, it should be simple enough to roll back a package to the previous working version.

Oknow

[reply]