|
in reply to perl and linux (was Re^3: Tired of "Perl is dead" FUD ?)
in thread Tired of "Perl is dead" FUD ?
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. |
Re^2: perl and linux (was Re^3: Tired of "Perl is dead" FUD ?)
by doom (Deacon) on Sep 19, 2007 at 21:05 UTC
|
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...
| [reply] |
|
|
It's all really a matter of scope I think. Of course, the friendlier a package is to Perl and the harder it would be to replace, the more likely it'd stay around anyway. Apache, postfix, Exim (although I prefer Postfix), emacs (although I prefer vim), vim, the GIMP, and several others already are pretty Perl-friendly.
Startup and shutdown scripts would definitely be the place to start. The reason I'd like also to see many command-line tools done in Perl is threefold. It encourages more tinkering than the current BSD or GNU tools. It also, if they are licensed under Perl's terms, deals with quite a few licensing issues where BSD and GNU tools fall on opposite sides of the fence. I could take my Perl-based, Perl-licensed tools anywhere on any system where they'll work, and not get hassled by others about the license. It's also a bit easier to have portable Perl-based programs for the command line than to write similarly portable ones from scratch in C. Most of the portable C programs that exist got that way over a long period of time.
| [reply] |
|
|
| [reply]
[d/l] |
|
|
| [reply]
[d/l] |
|
|
It depends on focus, of course. A serious installation for getting real work done would probably use Apache. A tech demo to show off what one can do with Perl might include Jellybean instead.
Given the right package selection tools, I guess one could do either. It could even be a high-level choice in the installer. "Real Work Pragmatism" vs. "Even More Perl-centric". Then, individual packages could be selected and deselected.
| [reply] |
Re^2: perl and linux (was Re^3: Tired of "Perl is dead" FUD ?)
by wolfger (Deacon) on Sep 20, 2007 at 13:28 UTC
|
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.
| [reply]
[d/l] |
Re^2: perl and linux (was Re^3: Tired of "Perl is dead" FUD ?)
by apotheon (Deacon) on Oct 02, 2007 at 17:02 UTC
|
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 |
| [reply] |
|
|
