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 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.

You raise a number of good points here... a few comments, in no particular order:

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 inclination is to go with Debian/Ubuntu as a starting point because I think it's got some serious momentum, and yet because Debian has a strong volunteer base, it's not going to disappear because of the vagaries of the marketplace. In general, Debian seems very well put together (e.g. everyone else has had to play catch-up with it's package management system).

Debian also, not incidentally, has an official Perl Policy.

Myself, I would prioritize writing a new perl-based package manager relatively low: the idea is a "perl-centric" distro, not one written solely in perl. Though on the other hand, a perl-based front-end to the existing APT tools might make some sense though... perhaps something that merges together apt-get and CPANPLUS in an intelligent way (e.g. you might want to be able to install the latest from CPAN, and create a "deb" for it automatically, so the database of installed packages stays up-to-date).

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

Well, any of those things might be looked at on a case-by-case basis, but I'm a little skeptical that it would make sense to go quite that far. The idea is to cater to perl-culture, not necessarily to re-write everything in perl. One of the features of perl culture is it's pragmatism: there's a willingness to work with other code (and to steal ideas from anything that wanders by...). Just to take one example, arguably, familiarity with Apache is already pretty strong among perl programmers: you're not going to talk many of them into trashing their web-server performance for the sake of ideological purity.

There's a reason I mentioned the init system, by the way: it's a mess of shell scripts that burn a lot of processes, and it really is noticeably slow. It's definitely ripe for replacement, and someone is going to get to it at some point. (And to tell you the truth, the main virtue of writing one in perl is likely to be inspiring competition from the kernel-hacker C-programmers).

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.

What I would suggest is start with perl5 and keep an eye on including perl6/parrot components as they become available. Myself, I wouldn't assume that either perl6 or parrot is really the wave of the future, and having a perl5 focus at the outset gives you a wider base of people who might be interested in what you're doing.

In general, if I were writing the manifesto, I'd focus on being useful to perl programmers, and accomodating to perl-culture (which includes apache, databases, and so on, as well as multiple different developer environments -- emacs, eclipse, etc). A secondary goal would be to move toward making everything customizeable in perl, if at all possible...

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.

Parrot: The Operating SyStem (Parrot TOSS). I like it! :-D
If you start working on this, I'd be willing to help in whatever fashion I'm able.

--
Nothing to see here. Move along.

I've toyed with using a Perl-based init script system

I know a guy in Florida who did that a long time ago. He subsequently went through a couple more Linux systems, ultimately losing his work on the Perl-based init system. C'est la vie.

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

- apotheon CopyWrite Chad Perrin

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."