Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Comment on

( #3333=superdoc: print w/ replies, xml ) Need Help??
You have disqualified yourself...

I'm sorry, I don't understand that sentence, care to explain what you mean here?

..."making sure you break none of the applications" is required step...whether you upgrade in one place or multiple places

Yes, but it's much harder, because you've got dog-knows how many different versions of the module installed for the different apps (that's the whole point of this scheme after all, right, to be able to have the version of a module which the app is written against) and you now have to find out what changes between each of those versions and the newly fixed one. Much, much harder. And yeah, finding the module file is easy enough, but then you have to care enough to upgrade the gazillion instances you have strewn all over your disk, and time being a scarce resource this will often not happen. This is a prime recipe for increasing the number of out-dated Perl modules installed on production machines and giving Perl a bad security rap.

..auto-generated packages..

I'm confused, if you can auto-generate the packages you're presuming that the bundle will work with the latest version of the module. So what's the difference to installing the latest module version into a central place? The only difference I can see is a false sense of security on the part of the user who thinks "this must work because I downloaded the Bundle" and will be all the more disappointed if it breaks.

..won't suddenly lose a clue about good software practices

Anything that gets made easier will be done more often. If module authors no longer need to care about their app working with the latest version of an underlying module version they will be tempted to use deprecated features, module internals etc., because "it works if you use the distribution". Other things (like adding the latest feature) will take precedence over robustness. That is part of my point, keeping different versions of modules on the same machine should be something that requires manual intervention, it's not good practice (most of the time) and you should have to think about what you're doing.

This attitude of not caring about end users

You misunderstand, I do care about the end user, and installation of a software package is indeed an important factor in its uptake (I've more than once refrained from trying out a Java app because of the horribly horrible horror that is Java installation and package handling). But Perl isn't a one-trick pony like PHP, it has applications that go far beyond the web-hosting sector. The requirements of all of these users needs to be taken into account when trying to improve some aspect of the language, not just of a relatively small subset of the user base.

If someone wants to use PHP instead of Perl (or Ruby or Python or any other language) and has good reasons for doing so, more power to them. To me the disadvantages of PHP are numerous enough that I'll prefer Perl any day, and one of these is the area of security. I care much more about Perl getting a bad reputation for its security than I care about the convenience of amateur webmasters (just to be clear, I'm not saying all users who use shared webhosting are amateurs, but those for whom this particular issue is a problem probably are).

I do agree that dependency handling an installation from CPAN is not as end-user friendly as it could be, but this is a very hard problem to solve correctly. I don't see any merit in auto-bundling software together for the purpose of spewing multiple versions of module all over your harddisk.


A computer is a state machine. Threads are for people who can't program state machines. -- Alan Cox

In reply to Re^3: A Vision for Easy Web Application Deployment for Perl by tirwhan
in thread A Vision for Easy Web Application Deployment for Perl by markjugg

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • Outside of code tags, you may need to use entities for some characters:
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.
  • Log In?
    Username:
    Password:

    What's my password?
    Create A New User
    Chatterbox?
    and the web crawler heard nothing...

    How do I use this? | Other CB clients
    Other Users?
    Others wandering the Monastery: (11)
    As of 2014-12-27 09:42 GMT
    Sections?
    Information?
    Find Nodes?
    Leftovers?
      Voting Booth?

      Is guessing a good strategy for surviving in the IT business?





      Results (176 votes), past polls