ISO technical document outlining system requirements for Perl

[xburrows]

Please bear with me. My companys uses MS Terminal Services. I asked the sysad what it would take to get a Perl compiler on the server. Sysad replied "Perl requires a dedicated server." I'm a newbie to Perl, but his replay smacks of criminal ignorance. Will someone here supply a link to some technical information so I can knock this guy down? I have found the system requirements on ActivePerl's page, but I'm looking for something with more detail. If I'm way off base, slap me. Thanks in advance. Ray To All : Thank you very much for your input. I understand the direction I can take that will fit everyone's needs. You guys rock. Question closed. Ray

[tachyon]

You will not find an ISO tech doc a la M$ for Perl. There is this at AS but you have probably seen it.

To give you some idea. Perl will run on windows CE and palmtops. I used to run 5.6 quite happily on a Pentium I 90MHz with 64MB of RAM. Each perl process will have a memory footprint of roughly around 4MB (for the simplest things). This is a rough guide but it is a bit of a memory pig. If you have 10 MB of data in an array it will use ~ 20 MB of memory. The same 10MB of data in a hash may use ~ 40 MB.

Although it is not recommended parctice you don't absolutely *need* perl on the server. You could put perl on your workstation and then just package your scripts up into a .exe using any of the readily available tools (Par, p2exe, perlApp). They just package your code, any modules with the perl.exe and perl.dll. Hello world will be 0.5-1MB (depending on packager) but a 40kB script will only add another 40kB to that baseline.

It might be a lot easier to get it on your workstation as an app, package the syadmin some useful tools and wait for him to go "How the hell did he code that so fast!". Only you need ever know that your 1MB app is internally 10 lines of perl that give a command line wrapper to one or more the the CPAN modules ;-) It also proves the point that you can run it on low(er) grade hardware.

[BrowserUk]

Actually, there may be some logic in what your sysad says. Terminal Services servers are often utilised by many users running many shared business applications. It can be quite a juggling act to get them all to coexist. It is a fine balancing act between many happy user with good response times and many unhappy users as one app dominates.

It is much too easy to write a perl script that will either consume as much cpu as possible, or as much memory as possible, or both. Running perl on a "production box", other than for running pre-tested, approved scripts should probably be considered a no-no most places.

If you were requesting that perl be placed there for general development/scripting purposes, then what he says makes sense. Development tools don't belong on production servers.

[Abigail-II]

There's no such document, and there probably never will:

From: Larry Wall ([e-mail])
Subject: Re: Help! Management Frowns on Using Perl for Production Apps
View: Complete Thread (11 articles)
Original Format
Newsgroups: comp.lang.perl
Date: 1995-02-11 22:16:04 PST

In article <[e-mail]> [e-mail].o
+z.au (Del) writes:
: My current excuse for using Perl is that it's a freeware version of 
+a
: really good new programming language, the standard for which is just
: about to be certified by ISO (or someone else with a really importan
+t
: sounding acronym).

I think I'm likely to be certified before Perl is...  :-)

Larry

As for company politics, I think this site isn't the place to discuss. If the sysadmin is unwilling (for whatever reason), talk to your manager. That's what managers are for. If you can make a convincing case, it'll come.

Abigail

[fsn]

Now, I may be totally out of line here, but xburrows might not be searching for ISO (International Standards Organization... or something) documents, he might be ISO (In Search Of... or something) any technical documents regarding his question.

I interpreted xburrows's sysadm's response as if he thought Perl required some kind of dedicated application server, which of course it doesn't. However, Perl is used in such application servers, for example Apache servers and, I believe, IBM WebSphere servers (a broad enough term to be accurate).

[dragonchild]

Perl has been ported to at least 60 (100+?) different operating systems, including (as mentioned above) PalmOS. In every case, the same basic functionality exists. (Obviously, if forking isn't supported on the OS, then you can't have fork work in Perl, and the like.)

As for requiring a dedicated server - it all depends on what you're doing. Perl itself is very fast, compared with VB. However, because you can do some really complex things in Perl very easily, it can be very ... dominating. Most commerical uses for Perl do require their own servers. Not because it's Perl, but because the application built in Perl has requirements. (Report servers, e-commerce apps, etc)

I would recommend doing at least one of the following steps:

1. Download and install ActivePerl on your desktop. Play with it and get a feel for the requirements of what you're doing. In many cases on Windows, using WScript, JScript, and/or VBScript may be more appropriate.
2. Talk to your manager. If you're asking the question, you probably have been asked to do something by your manager.
3. Bring in a Perl consultant to discuss the issue. Sysadmins are trained to be very conservative. Remember, it might be your application that's causing the server to slowdown, but it's his job. (There are old sysadmins and bold sysadmins, but there are no old and bold sysadmins.)

Oh, it's not a Perl compiler - it's a Perl interpreter. Perl compilers are different beasts.

[Abigail-II]

Oh, it's not a Perl compiler - it's a Perl interpreter. Perl compilers are different beasts.

The beast I have in /usr/bin/perl compiles Perl, and has no idea how to interpret Perl. One could say /usr/bin/perl is interpreting the results of the compilation of Perl, but that's not what's usually understood by interpreting.

/usr/bin/bash is an interpreter. /usr/bin/perl isn't.

Abigail

[dragonchild]

/usr/bin/perl compiles Perl to opcode, then interprets those opcodes. From a black-box view, it's interpreting Perl, regardless of how many internal steps it takes to get there.

This is opposed to the black-box view of gcc, which solely compiles C into the opcodes (or ASM) for the OS it's targeted to compile to.

[BUU]

I thought /usr/bin/perl did both. First it compiled the program in to opcodes or something, then it interpreted them?

[flyingmoose]

Terminal server is a giant security hole allowing all sorts of great local user exploits (such as emailing evil.exe to yourself and executing it) -- I really can't blame your sysadmin if he is smart enough to know the fault is in Terminal Server and not Perl.

Give me a terminal server account with simple "run programs in my account space" access, and I can bring your server to it's knees (I'm talking data loss and hardware damage -- yes, I can code to the Win32 API & DDK). If you have technically competant but disgruntled employes, for instance in a Call Center / CRM situation, you want to lock down as much as you can.

Of course, the first thing I'd do would be remove Windows and switch over to a remote-login (Linux/Unix/BSD) and thin-client type environment (Windows+Exceed or Linux/Unix/BSD)...and this is what the better shops do.

If you just need to install your apps on these servers, perhaps you can compile them to EXE with PAR and that might appease your sysadmin.

[jdtoronto]

Have you checked to see if Perl isn't already installed? There is in fact a copy of Perl on the distribution disk for your operating system, oh wait, it may be on the resource kit disk.

There are in fact a number of utilities for supporting TS which use Perl.

Sorry I can't be more specific, we are down to our very last w2k-TS-Citrix server and it is at least two years since I did anything to it!

jdtoronto