Most Linux flavors start as a branch from existing ones. They only change what is most important to differentiate themselves. If they're derived from Mandrake/Mandriva, they likely use Perl very centrally. If they are derived from something that uses Python for installation and package management, they'll likely use that too. This says, I think, more about the success of a main branch of Linux distributions than about Perl or Python specifically. Only if someone rips one out in favor of the other is it very important to language popularity.

I've yet to see a distribution that doesn't offer perl. Some include it as part of their developers packages. Some offer it as its own item. Some don't allow you to deselect it, because it's considered vital to the system. Python is also being offered on lots of distros, but I'm not as certain about where it might not be since it's not on my must-have checklist for trying a distro.

I've yet to see a distribution that doesn't offer perl. Some include it as part of their developers packages. Some offer it as its own item. Some don't allow you to deselect it, because it's considered vital to the system.

I remember seeing some polite discussion on the subject of removing perl dependencies from Debian, where the conclusion was essentially "fergetabodit".

I occasionally toy with the idea of developing an intentionally perl-centric linux distro (probably Debian or Ubuntu based), tentatively named "Oyster".

The idea would be to have the ultimate perl-development linux-distro available out of the box, without hunting around for the pieces. There's also a lot of cool mod_perl-based web apps out there (Bricolage, Slash, etc) that could be glued together into a websever version of Oyster.

And for extra credit, we could look into things like re-writing that mess of init shell scripts as a monolithic perl script (I bet it would boot a lot faster for laptop use).

I've toyed with using a Perl-based init script system, Perl-based network superserver, the PPT package for lot sof command-line goodness, and more. I haven't taken the time to actually do most of it, because I figured it'd be useful primarily as a hobby time-sink for just myself.

OTOH, I have built some of these pieces in a pinch, and used some others. I used to have a mail delivery agent written in pure Perl in production for 15,000 users. I used to use a Perl shell of sorts written in pure Perl on a couple of boxes as my primary login shell. I think the source to that is on c.l.p.misc archives somewhere.

If anyone is serious about building such a beast as a team, I'd be willing to put a few hours a week toward it. I'm not sure if Debian, Ubuntu, Mandriva, PCLinuxOS, T2, Gentoo, Slackware, LFS, or what would be the best starting point without some fresh looks.

My intuition has always told me to start with a minimal Linux installation, install perl, and replace as much as possible with Perl. Then, once nice package management in Perl is written, worry about the packages. Packages that use Perl in production would be favored first, then those that use Perl for configuration or that have Perl hooks. Then, options that are Perl-friendly in that they use text/YAML/XML configurations and/or use textual methods of communication and control (sockets, pipes, etc) with textual protocols would be considered. Finally, anything left would be used as a stopgap until it could be made more Perl-friendly or replaced with something that is.

It's worth noting that if flexibility and familiarity for Perl developers is favored over performance, we could eventually go so far as ditching Apache, postfix (or other SMTP system), syslog, sshd, ssh, text editors, and more with pure-Perl solutions. Of course, and here's one more reason I've been putting off any task like this -- many of these things would be more suitably replaced by solutions written in Perl 6 than Perl 5. Having a language like Perl 6 that has so many more possible performance enhancements without dropping to C could make a huge difference in such a system.

Another reason I've been slow to do this with Perl is that I've been revisiting a romance with another language that's suitable for more than people outside its community generally credit it for: Forth. An entire OS (kernel and all) could be written in Forth, and would likely take up very little space on disk and in memory. The thought had crossed my mind to make a distro as Forth-friendly as possible instead of as Perl 5 friendly as possible. Having a language-centric OS distro can lead one to question which language to choose. Of course, with Perl 6 and Parrot, Parrot could be used as a central OS tool much like gcc is now. Many languages, including Perl, could be well-served by such an arrangement.

Am I advocating a Parrot-centric OS distro with tools written in Perl 6 and used for developing in Perl 6 given special attention? Yes, I think I am. Before Parrot and Perl 6 are at final release might be the best time to start such a project, but I'm not sure how much before. In any case, I think Parrot is a better place to focus for an OS than on Perl 5. Just as gcc has frontends for more than C, an OS based around dynamic languages should be capable of at least some work in other than the main language in question.

I remember seeing some polite discussion on the subject of removing perl dependencies from Debian, where the conclusion was essentially "fergetabodit".

I think that sort of thing is sadly to be expected. There's a substantial subculture of people who have as their primary distinguishing feature in common an unreasonable hatred of Perl. They're probably strongest in the Python and Java communities, but I'm just kinda guessing on that based on my own (anecdotal) experience. I've seen them piping up in various places advocating for rewriting everything previously done in Perl with a "real" language (most often meaning Python, occasionally actually meaning Java or even PHP). In general, people tend to dismiss such counter-advocacy as impractical, but I have seen people on occasion seriously consider replacing a bunch of system scripts in Perl with equivalents in Python.

Anyway, for the most part, I believe it's just a noisy minority that does that sort of thing, and I suspect that was the case for Debian as well (polite, as you say, but still noisy).

print substr("Just another Perl hacker", 0, -2);

- apotheon CopyWrite Chad Perrin

You're on the right track when you say "They only change what is most important to differentiate themselves." From what I've seen, Python's getting used to write software management systems and installation systems more often than Perl (Gentoo's Portage and Fedora's Anaconda, respectively, come immediately to mind). Perl's still used to maintain and improve a whole bunch of older software management and installation systems. I think things are reaching a leveling-off point, though, where Python's encroachment is slowing down.

It's only natural that Python looks like it's "taking over" for a while, because in order for Python to get any traction it has to get some "market share" from somewhere -- and Perl pretty well dominated the niches where Python would be most effective for a long time. Now that Python has been expanding a little bit into some areas where there are more people who would like Python's way of doing things than Perl's, I suspect any further conversion will slow to the point where both Perl and Python will grow faster through expansion of both languages' capabilities into other "markets" than through any contesting over already claimed territory.

Ruby is just starting to get in on the action, from what I've seen, and when Ruby 2.0 hits it will probably accelerate slightly. It will probably take ground from both Perl and Python in the sysadmin arena, as it already has in a few cases (such as its growing use in ports management software for FreeBSD, for instance). Eventually that, too, will reach a state of equilibrium with Perl and Python. So it goes.

I've yet to see a distribution that doesn't offer perl.

It would be a strange Linux distro indeed that didn't offer Perl at least through its software management system. I seem to recall that FreeBSD removed Perl from the base system a while back, but I think that's just because the FreeBSD folks are interested in minimizing the number of interpreters that are part of the base system altogether. I don't recall Lisp, Lua, Python, Ruby, or Scheme interpreters being part of the base system either. This would be why, every time I write a Perl or Ruby script (and I've even written a couple of Python scripts lately -- le shudder), I find the interpreter in /usr/local/bin/$foo rather than in /usr/bin/$foo (though there is a symlink from the latter to the former, while there are not similar symlinks for Python and Ruby, by default).

Of course, officially the problem with including Perl in the base system was related to FreeBSD discussions on whether to differentiate between the interpreter and the Perl standard distribution libraries when determining what's in the base system. The ultimate official opinion seemed to be that including all the libraries in the Perl standard distribution along with the Perl interpreter itself would be too big a wad of stuff for the FreeBSD base system, so it has been relegated to ports instead. I still think FreeBSD may have a "fewest interpreters in the base system possible" bias, however.

Interesting note: In the midst of browsing through FreeBSD ports, double-checking to make sure I wasn't misspeaking, I stumbled across an interesting port called ruby-perl. The description:

This is a Ruby extension module to use the functions of Perl from Ruby
+.

You can also call Ruby functions back from within the Perl code.

Author:    Yoshida Masato <yoshidam@yoshidam.net>
WWW:    http://www.yoshidam.net/Ruby.html#perl
[download]

For someone that likes both Ruby and Perl so much, I sure do seem to be ignorant of some stuff that would be right up my alley. I had no idea this thing existed. Unfortunately, I seem to have discovered it in time for the message on its homepage "This library is not maintained now."

print substr("Just another Perl hacker", 0, -2);

- apotheon CopyWrite Chad Perrin

I would say that that is because of the GUI toolkits. Disclaimer: I have never done anything with any of the GUI toolkits, so I may be completely off the mark. All I know is that Tk seems to be the only stable/widely used choice for Perl, and every Tk application I see looks awful, while the Python stuff looks great.

I've tried to install the Gtk modules, but just got failures. I'm assuming the Python bindings are easier to install and use, which is why we see more productivity in this area. This is sad - I've got a hankering to try my hand at a desktop based application, but (and maybe I'm just believing the hype) I feel that I should probably learn Python to do that.

Please somebody correct me.

Clint

Perhaps take a look at Wx for a Perl interface to the wxWidgets (http://wxwidgets.org/) library. (Or would you call it a framework? ;)

I've implemented a couple of GUI apps with great success using wxPerl.

Do you have any examples of work that you've done that we could look at? I'd love to see Perl in some GUI-action.

Also, if I understand it correctly, wxWidgets provide a single interface to numerous GUI platforms, rendering controls natively, so that your application would fit in with other applications in your environment. Which sounds like a great idea. Yet, I hear mixed opinions about it. Is that because the only way to support multiple platforms is to only allow controls/actions/interactions common to all platforms, thus eschewing the more interesting features of each platform? Or is there some other reason?.

Like I said, I'm ignorant about the GUI side, but interested in learning more.

thanks

Clint