To Perl or Not to Perl!

[Marza]

I find myself in a bit of a quandry. As I am more or less a seasoned newbie; I am still in the stage of wanting to do everything in Perl.

Awhile back we looked at McAfee's ePolicy Orchestrator to help control the virus software. It was about $13000 for 200 clients!!!! So I opted to see what I could do with Perl.

The first big thing was to find out what version and DAT levels were on each computer. Making use of the Good old TieRegistry module made this a breeze

The next was to automate the SuperDAT downloads as I viewed the DAT updates as a beta and did not like having 200 FTP calls to Network Associates to do this. Again Perl and the Net::FTP module made this really easy.

That last big project was the ability for force everybody to upgrade on an emergency situtation(ie Klez, Bugbear). This was not so easy as the command lines for McAfee upgrader need to run local. I found a module that is on SourceForge for the scheduler. However, it is not "blessed" by cpan and it has quirks(ie more like windows quirks with the diferences between W2K and NT

While debating the approach, I was asked to check something on our licensing and found we already had licenses to the ePolicy Software! Somebody in purchasing made the wrong request for pricing!

So the quandry! Do I install the software as it is already paid for? Or do I follow my whims and find a Perl Solution? I figure the time to install it on the community will take as long as figuring out how to force updates

[Tanalis]

While there's a certain amount of satisfaction involved in rolling out your own solution to a problem, I can't help but feel that perhaps you may be re-inventing the wheel here.

As you say yourself, ePolicy is not a cheap package, and, as is to be expected when you shell out large amounts of money for a software solution, it does the job it sets out to do very well.

While I'm not saying that Perl couldn't do the job as well - in fact I'm certain it could - I think the fact remains that the money has already been spent - and any saving that writing an in-house solution could offer has already vanished. Once coding, debugging, rollout problems and other coding and release issues have been worked around, I feel that any time saved doing this could well be negligable.

On the other hand, it does sound like it'd be very intersting to put this project together ... which is the most important argument for doing anything ...

Just some random thoughts ..
--Foxcub

[AcidHawk]

I often find myself in the exact same position. Should I use a tool that is currently available or do I build my own tool. Often I find that my only real argument to build my own tool is because in doing so I will be exposed to something new - ala GD, GD::Graph and GD::Graph::Map recently used on a web page found in my scratchpad.

Unfortunately though, I often have to work on these pet projects at home after work hours. I think one of the most rewarding things I have been involved in is a tool I build to "see if I could do it" which has become the standard at the outsourcing company where I am curently contracted, and is fast becomming a standard at other sites where some of my colleagues are situated.

I haven't seen anything I can't do with perl as yet, not that I am looking to find anything, but perl allows me to be creative while I am learning. For me this is why I Perl, at every opportunity!

-----
Of all the things I've lost in my life, its my mind I miss the most.

[diotalevi]

I noticed your comment 'not "blessed" by cpan'. That's hardly true - CPAN guarantees nothing. It's simply an aggregating point. See Re: Module installation can be harmful for more on that (in a variation). This isn't about your question but you're likely to be misinformed otherwise.

__SIG__
printf "You are here %08x\n", unpack "L!", unpack "P4", pack
  "L!", B::svref_2object(sub{})->OUTSIDE

[Marza]

Ah I did the crime of making an assumption and not reading anything. Sorry I am a recovering MacIntosh user ;P

I figured it was blessed in that if it was on cpan it the author would get a ton of hate mail if it didn't work. But then again there is Matt's Script arcive! ;)

Thanks for pointing that out!

[petral]

a) Use the commercial one and duck the maintainence responsibility (eg, updating for OS revisions).
b) Keep yours around (and maybe use it on one or two machines) in case, later, you gotta have some functionality that the commercial black box doesn't provide.

  p

[Popcorn Dave]

I think it's going to come down to two things for you.

1. Do you feel confident enough in your own abilities to write something that is going to be perhaps mission critical?

2. Do you want to have the responsibility of maintainance on the program you wrote? And given Tilly's problems you might not even be able to share your resulting work, but that may or may not be a problem for you.

By writing something like that for your place of employment you may be putting yourself in a position that later on down the road you wish you hadn't.

I had a friend who worked at Tandem Computers about 15 years ago picking parts. One of his duties was to do a random inventory of parts. Some of the parts needed to be counted daily, some weekly, some monthly, and some every 6 months. So he did what any normal programmer would do - he whipped up a program in Turbo Pascal to generate random numbers and make an inventory counting schedule based on that. When he switched departments, he got a phone call a while later asking him to update the program. He told them to get stuffed as it was his, and he wasn't going to do it.

Somehow I don't think it's as possible to get away with this in today's climate, but it is something to consider before you put the effort in for the company.

That said, if you wanted to do it yourself to see if you could do it FOR yourself, then hell yes, go for it!

Good luck!

There is no emoticon for what I'm feeling now.

[mojotoad]

... I am still in the stage of wanting to do everything in Perl.

Better get used to that feeling!

Matt

[perrin]

The thing about commercial software is that unless it does exactly what you want you will probably get screwed by it sooner or later. If you need something to work just a little differently, you will not be able to make that change on most commercial closed-source software and will either end up writing your own replacement or living with the inadequate solution. This is why I like using open source packagaes written by others, but don't like using closed-source commercial ones when I can avoid it.