Re: perl and linux (was Re^3: Tired of "Perl is dead" FUD ?)by mr_mischief (Monsignor)
|on Sep 19, 2007 at 19:56 UTC||Need Help??|
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.