Bruce Thompson wrote:
> I believe (but can't say for certain) that Python is available on
> pretty much any system that Perl is, and that installation is nearly
> as easy as Perl.

That's perfectly true. I've tried python on my Solaris systems as well
as on my iMac G5 at home. The one Sysadmin here who has advocated for
python uses it on ubuntu, debian and Windows (all of the other
Sysadmins, 10 of them, who were present at his "training" session last
spring have declined to adopt it).

Aside from the 10 sysadmins who declined to adopt python (which I do
think is an issue here), the important distinction is between (1)
available and (2) already installed and dependent.

Perl is already installed and is already a dependency in most
Unix/Linux/BSD systems. It comes with the system. At least in the case
of Solaris, which I'm most familiar with, the system itself has
dependencies on Perl. Remove Perl and you're going to find a variety of
things broken.

Interesting. I just did the following on my Mac OS X system:

$ find /usr/bin -type f | xargs grep '#!/usr/bin/perl'

and it scrolled over a couple of windows. I did the same for /usr/sbin
and found some system dependencies authored by Apple for Darwin --
things like the configuration script for IPv6. So, I think things in Mac
OS X might break if you tried to remove Perl.

Python, on the other hand, is yet another add on. It's not necessary.
It's a choice. Given the choice, I put as few things as possible on my
systems. I remove as many things as I can without breaking the system or
losing necessary functionality. I only introduce new dependencies if
absolutely necessary and if there are no other options to get the
functionality I need. Otherwise it becomes one more thing that has to be
watched for updates and vulnerabilities. I never use anything like yum
that automatically downloads and installs everything it thinks it needs
for a package, or the automated CPAN process that does the same. I
review each individual CPAN item. Sometimes I'll just back out of
something that I started to do, because it generated far too many
dependencies.

Note that this is not AS true of home or personal systems. However, it
is an important point for enterprise systems, and I believe that is
where we want Amanda.

---------------

Chris Hoogendyk

-
O__ ---- Systems Administrator
c/ /'_ --- Biology & Geology Departments
(*) (*) -- 140 Morrill Science Center
~~~~~~~~~~ - University of Massachusetts, Amherst

< hoogendyk%40bio.umass.edu">hoogendykbio.umass.edu>

---------------

Erdös 4

Chris Hoogendyk wrote at 10:51 -0400 on Oct 6, 2007:
> Perl is already installed and is already a dependency in most
> Unix/Linux/BSD systems. It comes with the system. At least in the case
> of Solaris, which I'm most familiar with, the system itself has
> dependencies on Perl. Remove Perl and you're going to find a variety of
> things broken.

I wonder if "most" is true. FreeBSD pulled perl out of its base
system 5+ years ago (and was planned a few years before that as
perl dependencies were gradually whittled away).

It's now on equal footing with python in FreeBSD... i.e., it's in the
&quot;ports&quot; system and lots of other ports depend on each of them. If you
remove python, you can break lots of things, too. It all depends on
what ports you might have installed. The same is true of linux
systems that I've used - in fact, red hat-ish systems have a long-time
python-dependent installer, anaconda, and yum is python based. For
those distros, it seems that python is more basic.

The question is, what's the split of software dependent on python
vs. perl. perl may have an edge, but it's not 99% to 1% anymore.
It'd be interesting to see actual numbers, but not interesting enough
for me to bother to go out and do an audit of the some 17000+ ports in
FreeBSD's ports.

So, is this question important enough to answer for Amanda's purpose?
IMO, perl and python are quite pervasive these days, and basing a
scripting decision on the availability of either is of little use -
both are in widespread use. And guessing which platforms (of the N
platforms that amanda runs on) is more likely to have perl or python
by default is not a very satisfying way to determine which to pick for
scripting core amanda algorithms.

The most valid case for perl over python in amanda is that some of the
current ancillary amanda utilities are in perl (amoverview, amtoc,
amstatus, some chg* scripts). These are all server-side utilities I
believe. These could be done in sh/awk/sed or python or ruby or ...

But they are currently in perl, so that inertia is one check mark on
the side of perl. But, inertia is only one factor for making the
choice for a scripting choice for amanda core algos (and should only
be a consideration for short term decisions, not long term ones).

Both basic python and perl (without the extras) are of roughly equal
size, BTW (30-ish MB on my boxes; ruby is, too, for that matter). And
they both aren't all that big. Requiring both python and perl (and
glib now) on the server is not that big of a consideration for the
server. FWIW, we develop embedded products that have compact flash -
for years we had 64 MB flashes and sometimes put stripped down perl
and python along side our apps and stripped down FreeBSD. Now we use
minimum 256 MB parts and have room to spare. My point is that on a
typical backup server these days, the size requirements of perl or
python or both should be a minor consideration.

&gt; Interesting. I just did the following on my Mac OS X system:
>
> $ find /usr/bin -type f | xargs grep '#!/usr/bin/perl'
>
> and it scrolled over a couple of windows. I did the same for /usr/sbin
> and found some system dependencies authored by Apple for Darwin --
> things like the configuration script for IPv6. So, I think things in Mac
> OS X might break if you tried to remove Perl.

Maybe so with OS X. That's not true of all OS varieties.

Personally I prefer:

#!/usr/bin/env perl

Since I have systems that have perl in /usr/bin, /usr/local/bin, and
/site/bin (think of it as an nfs mounted shared /usr/local), hard
coding #!/usr/bin/perl doesn't work. This has the added bonus that I
can experiment with an alternate location of perl for testing. To
address the security concerns with doing this, you need to make sure
PATH is set appropriately when running scripts as root anyway.

> Python, on the other hand, is yet another add on. It's not necessary.

That's misleading. It's as necessary for some things as perl is for
others.

&gt; It's a choice.

Yes. But please pick the scripting language on their own merits, not
on backward-looking considerations such as whether amstatus is
currently written in perl or not or whether 30% of the other software
you happen to use has selected perl or C or python or whatever.

A bigger decision is whether to switch to using a scripting language
at all. I'm not convinced amanda shouldn't keep using good old C.
But I can't convince myself that scripting is a bad idea overall, and
it could make things more maintainable. So other than an occasional
kibitz, I'll defer to more frequent hackers.

But, on the languages' merits, I'd still vote for python over perl ;)

I won't rehash all the perl v. python arguments. The main reason
I would prefer it for amanda core stuff is maintainability.

On 10/6/07, John E Hein < jhein%40timing.com">jheintiming.com> wrote:
&gt; glib now) on the server is not that big of a consideration for the
<snip>
> typical backup server these days, the size requirements of perl or

To reiterate a point I made in the original email: we're considering
this for both client and server. The 2.5.3 client will be maintained
as a dependecy-lite client, while future clients will require the
selected scripting language and glib. The rationale is that, since
all of the filters in the application API can run on either the client
or the server, there's no sense implementing those filters twice, in
two different languages.

John, I'm not sure if that affects your opinion.

Dustin

--
Storage Software Engineer
http://www.zmanda.com