An avid FreeBSD user, I was saddened to see the thread that lead up to this, and even sadder when Mark Murray made it official.

As I understand it, however, Perl will be turned into an optional but (possibly?) installed by default package in a fashion similar to the handling of X11 (think Solaris 8, if you're familiar with how Perl is installed on that) which (w|sh)ould satisfy all those who bellyache over the 'bloat' that Perl adds to core while still keeping the rest of us happy campers ... hardly doom and gloom.

Heck, divorced from core, us FreeBSD users might finally see a better effort of staying in sync with the current stable version of Perl, rather than waiting for the committers to import it into the FreeBSD source tree or by trying to build our own over an already existing 5.005_03 install.

Possibly a more important development out of all this brouhaha (to the Perl community, anyway) is the formation of perl-dist@perl.org to address the evergrowing size of the base Perl distribution(s)...

The Perl5 installation I have here, complete with modules, is 20MB. A more heavily loaded version I also use is 26MB. How can anyone claim in the age of 160GB hard drives that this is somehow too large?

I understand there are applications which might require a "mini-perl", such as embedded systems or extremely antiquated hardware, but can't you just pick and choose the things you need and build your own distribution? Start with perl and build your way up, as it were.

Having a more "dynamic" Perl configuration, though, would help substantially. Compile-time configuration is such a pain.

I think the discussion is centered around the "core" BSD, so I tend to agree you shouldn't need something like (blatant example) CGI.pm in it. I would be happy if I could install "core" perl and then fetch my own modules/Bundles. I also don't think you should have to require perl to have BSD, but that's another story.

I would install a "basic" perl in my laptop for example, where I have only a 2GIG drive and every M is precious. I would also expect a default server install of any distribution to include TONS of modules (but not the client install), and if CPAN was a little (lot?) "cleaner", I would expect hosting companies to include it all.

tstock

Even in the age of 160GB disk drives, very few of them are shipped from the manufacturer with BSD on them -- they have to be loaded from some media or another. The most common current choice is a CD-ROM which is fixed at ~600MB.

Having spend a small chunk of my career assembling OS distributions for dissemination: I can tell you that having an entire, working OS on the smallest whole-number of CD's possible is important. And on a 600MB CD, 26MB for a scripting language is a pretty hefty footprint.

The Perl5 installation I have here, complete with modules, is 20MB. A more heavily loaded version I also use is 26MB. How can anyone claim in the age of 160GB hard drives that this is somehow too large?

Grr. (This is one of my pet peeves.)

Many people run free Unixlikes on old hardware, as low volume mail or web servers, firewalls, and so on. On a 200MB hard drive, 20MB is too large, especially when /var/log fills rapidly (as it does on firewalls or net servers). Not everyone runs, or can afford, an even remotely new machine.

--
:wq

Mark is more worried about maitainence. Perl build system is far from perfect and it doesn't fit the FreeBSD build mechanism when, say, you want to build a complete FreeBSD release for Alpha on your i386 box. He says "bloat" and means not only bytes on the disks but also work needed by maintainer (himself) to harness the perl inside FreeBSD.

As several others have pointed out, the /usr/bin/perl in fbsd has been stuck at 5.005_03 for some time. I like using a more update version, and frequently fought to get 5.6 installed. The fight involved "fixing" the warning that came from trying to install perl as a port, and then fighting to get the modules installed in the right place everytime I went to install one. fbsd's ports system insisted quite heavily on using /usr/bin/perl and I never felt it safe to replace that binary -- it could potentially break an important system utility.

If I gave up and used /usr/bin/perl, every module I loaded would be blown away when I did the next make world. Which meant I had to take a fair amount of time to rebuild/reinstall every perl module I loaded -- and trust me, that was a large number of modules.

Now that perl will be a port again, all of these issues disappear. I can keep up-to-date with the latest version of perl, and modules will not disappear when I make world. Once again, fbsd puts *me* in the driver's seat and lets me choose what gets installed where. That is why I use fbsd.

Merely my 2 cents worth,
mikfire

-- Randal L. Schwartz, Perl hacker

Many people are not perlmonks and use perl as a tool among others. It seems that Perl is becoming so large that it needs more commitment than most people are ready to give. I think this is very very sad that Perl, Python or Ruby have not displaced the Bourne-shell as a way of scripting. But that some major Unix distro choose to go back to traditional shell is a strong message. Something is very wrong.

The perl community should probably distribute a base-perl just like Mandrake does (I think debian did it first). And a base-perl doc too.

The base perl weight is 1.7Mo including .85 for libperl.o. It includes everything to import modules, be they .pm and .so, It has the pragmatic modules, the FILE::* and IO::* so one can already do serious programming.

-- stefp -- check out TeXmacs wiki

*sigh* (double *sigh*, I had a reply done and my machine croaked). Perl is the language, the binary. Not the modules, they are but a library to save you time. Does that mean they can be removed willy-nilly? Well, that's moot, I'd say yes, but you shouldn't. anyways, you've said more interesting things I'd like to address.

Re: your whole second paragraph, Larry himself has said that one should only be required to know what is necessary to get the job done. Neither you, nor me, nor anybody else is expected to know every last detail about Perl. There wouldn't be much fun, learning, or interaction if we all knew all of it. Besides, one of the most wonderful things is coming across an as of yet undiscovered (by you) gem. Be it in man pages, the default libraries, or a module on CPAN. To quote Bill Waterson, "There's treasure everywhere".

--
perl -pew "s/\b;([mnst])/'$1/g"

I know the slogans about "baby perl" and "getting the job done". They were true when I started using perl in 1989. They are not true as far newcomers are concerned. You are confusing the slogan with the reality. One of the problem is that perl5 is now a senescent language. But that's ok. it has done its time, paved the way for the next generation, and perl6 is around the corner. And the experience we got with perl5 will give us a head start on perl6

perl5 has become a cave with a lot of twisty passages and like you said, "treasure everywhare" if you got time to spare. My point was that most people don't have that time, and don't want to put up with the junk for the sake of the jewels.

An example to support my point: suppose you are a Unix guru but a perl beginner and you want to build a server of some sort. You know this will be based on sockets and you will find the documentation about the socket() function but you won't easily find doc about the Socket module, or higher level modules to build server or even the POE module.

perl5 is dying of entropy. There are many jewels around but hidden in so much crap that has no sense but historical.

Some language like Python or Ruby are cleant up perl5 but they are only that. Hopefully, with perl6, we will be able to start again with experience without the uneeded baggage and with the vision of Larry and Damian.

If we don't have the courage to admit what perl5 is and to wait for perl6, the relevant slogan is John's ones: "We are fucked...". Don't trade on the glorious past but prepare for the future.

-- stefp -- check out TeXmacs wiki

<FLAME> If BSD people designed bicycles, would the reflectors be optional? If BSD people designed cars, would the trunk be optional? Oh, nobody will mind cutting a hole in the back of the car to store stuff if they need to. And it'll be so much easier to make cars without standard trunks. </FLAME>

I love RPM's, particularly with apt. And my OS vendor is in touch with real world.

If I understand correctly, your argument is that its going to take longer now to install a new system because people are going to have to install the core, and then install Perl in a second step.

As a person who uses BSD a great deal, I can tell you that the first thing I do after installing BSD is upgrade perl to the latest version. The reason being that the BSD distribution is stuck in the stone ages with perl 5.005_03. So, if you are happy with perl 5.0, then you have a valid point.. it will take an extra step. But, if you want to be using perl 5.6, then your point is moot because it already takes an extra step anyway.

As Kanji has already pointed out, "divorced from core, us FreeBSD users might finally see a better effort of staying in sync with the current stable version of Perl, rather than waiting for the committers to import it into the FreeBSD source tree or by trying to build our own over an already existing 5.005_03 install." I second that motion.

<Counter-Flame> BSD people are good at making bicycles because thats all they worry about. They don't worry about knowing how to make the best reflector, and they don't sell you a bike with a reflector built in (break the reflector, and you broke the bike). They do, however give you the choice of a lot of other people that are experts in making reflectors and let you choose. Once you have chosen, they'll gladly install that reflector for you (See The FreeBSD ports collection). To me, that's at least part of what Open-Source development is about. </Counter-Flame>

UPDATE Fixed grammar

I agree. In my experience, all of the RH distros install older versions of Perl. After installation, I have to undergo the arduous task of installing the modules I want and need for my server setup using the -MCPAN shell. This decides to update Perl for me, gets it, rebuilds it, and installs a new module tree under the current version number. This is a pain in that all the old installed modules (supplied under the old version number tree) are no longer normally available to the updated binary. This involves the painful ordeal of symlinking the old tree into the new one, making sure not to duplicate module branches. Grr.

Perhaps there's a simpler way of doing this, or perhaps I'm doing something wrong. Perhaps some suggestions would be helpful.

And perhaps if Perl wasn't tightly bundled / integrated with the OS (whatever your distro is), the process of installing, configuring and maintaining your Perl install would be a good bit easier.

-Shawn
(P^h) Phaysis
If idle hands are the tools of the devil, are idol tools the hands of god?

It anything is a testimony to free, open-source operating systems it's the sucky, bass-ackward way that HP-UX and Solaris handle installs. FreeBSD has nothing to worry about in that department, Perl or no Perl.

()-()
 \"/
  `