jlongino has asked for the wisdom of the Perl Monks concerning the following question:

I have been asked to create a program that runs on Windows as a process and notifies users when local software patches are available. I would like to use Perl for a number of reasons: Constraints:
Plan: Concerns: I realize that this is sketchy at best and I'm probably leaving some things out. For small projects I usually just form a mental plan and attack, which has worked fine for me in the past. I suppose hanging around the Monastery is having a positive effect on me. Putting things into "type" has helped me to define tasks more clearly and forces me to think things through (besides I hate making a fool of myself in front of such a learned audience).

Please, any feedback is welcomed, no need for code (unless it illustrates a gotcha of course). Are there alternatives I'm overlooking that might simplify the task without violating the constraints?

"All are lunatics, but he who can analyze his delusion is called a philosopher." -- Ambrose Bierce

Replies are listed 'Best First'.
Re: Small Project Definition
by CubicSpline (Friar) on Sep 30, 2001 at 02:45 UTC
    I just have a few questions about the general idea of this service.
    • How often do you expect software patches to become available? Does this process have to be run several times a day, once in the middle of the night, or once every 2 weeks?
    • It sounds like from the requirements that the users will have to take action to install any patches that become available. Is it undesirable to have your software automatically install said patches when they become available? I suppose it depends on how often a system would need updating, but I'd think it would be nice to just have your app do the installation when necessary.
    • Is there anyway you could get around having to write this code? Is it not feasible to have the Sun system send email to users when a new patch is available? Provided that they had an easy way to access the patch (via web/intranet) this would save you time.
    Just some food for thought, and maybe you've already thought these ideas through. Let us know how it comes along.

    Cheers,
    ~CS

[reply]
      Very good questions. Perhaps I over-generalized the project too much. The task is to alert employees that there are antivirus definition file updates available for Command Software Antivirus (CSAV once know as F-Prot):
      • I work for a University and we have 3 hospitals as well as the main campus to worry about. There could be daily updates, but since some people work shifts, we should check a couple of times each shift even though different shifts might use the same computer.
      • All the users have to do, once notified, is open the software and click the "Update Deffiles" button. Sounds easy enough you would think.
      • We already send out e-mail messages when the updates are ready, but then there are the limitations of e-mail: not everyone has it; if they have it they don't ask to be put on our mailing list; they receive the email and promptly delete and/or ignore it since it is an automated message. Of our roughly 5800 employees, only 2100 even have e-mail accounts.
      I imagine that the thinking is: if we tell the user there is an update available, and I suppose we could go the extra step and open the program for them. The least they could do is click one stinking button. Our department is made up of 6 full time people and two student workers. As you can imagine the SirCam and Nimda viruses pretty much ate our lunches.

      "Most people would sooner die than think; in fact, they do so." -- Bertrand Russell

[reply]
        It sounds like the goal is making sure that all your (hundreds?) of PCs have up to date virus definitions.

        This feels like longer than an 8 hour project and it feels like you won't accomplish your goal, if user's don't update with email notification, they aren't going to update with a popup box....

        You might be better off using the your vendor's shrink wrapped central console . or switching to a vender like Norton that allows PCs to be configured to reach out and pull down anti-virus definitions directly from Norton's website.

        If you are talking about hospitals and people’s lives (?!!), money shouldn't be an object. If you recently got nailed, your upper management should be open to spending some money to fix this problem. If not leak the story to your local newspaper

        In a small setup, 5-10 PCS a home brewed script can work pretty well. –I’ve done it. In a larger setup configuration management by hand can get ugly. (I’ve seen it done)

        Hope this helps



        --mandog

[reply]
Updates: Small Project Definition
by jlongino (Parson) on Sep 30, 2001 at 08:30 UTC
  • I originally intended to use  Win32::Process so that I could launch a perl program without having to keep a DOS command shell open. I found that using Perl2exe with the -gui option eliminates the module requirement.

  • jepri: I like the idea. If the Tk stuff is too hideous looking, I'll definitely look into your suggestion. For the sake of keeping things simple, I'm going to attempt it with Tk first.

  • As for Perl2exe -tiny generated executables, the only difference I could tell is that without the -tiny, there is an obvious 5-7 second drag on the system (500 MHz celeron, Win98) when it is first launched. Using Norton Utilities System Information, the memory usage numbers were identical. The -tiny option executable was 358 KB in size and generated eight dlls totaling 1413 KB, without was 1771 KB. I think that although the lag is unpleasant, distributing/updating one file as opposed to 9 is easier to maintain.

    "The significant problems we face cannot be solved at the same level of thinking we were at when we created them." -- Albert Einstein

[reply]
[d/l]
[reply]
Re: Small Project Definition
by jepri (Parson) on Sep 30, 2001 at 08:18 UTC
    The answer here is pretty clear to me: use both VB and Perl.

    VB is an unbeatable windowing system. It's got IDEs and plug ins and oh my goodness everything that looks good on windows. It's also a nightmare if you want to do anything more than display windows.

    Now Perl, on the other hand, is a fantastic glue application. Visual Basic may never get a module with the power and ease of Net::Telnet. It doesn't have to, Perl already has it. But untill someone ports Glade to windows Perl's interface will be 'clunky' at best.

    Write you saccharine-laden interface in VB, and make it look good, so you look good. Write your backend in Perl, so you don't waste time or effort, and so you know it works.

    Then shell out of your VB app to your perl app.

    ____________________
    Jeremy
    I didn't believe in evil until I dated it.

[reply]

Back to Seekers of Perl Wisdom