Slashdot Mirror
FreeBSD: Perl to be removed
zmcgrew writes "From Daemon News:
"The decision was made to remove Perl from the FreeBSD -current base system [earlier story ]. Perl will be supported as a port that the user can install after the base installation, however it will no longer be required. Mark Murray put out a call to the -current mailing list asking for volunteers to port all Perl scripts in the base system to another language, such as sh or C. All critical programs are already being ported, with only a few minor ones left to be claimed." Wow..."
"The decision was made to remove Perl from the FreeBSD -current base system [earlier story ]. Perl will be supported as a port that the user can install after the base installation, however it will no longer be required. Mark Murray put out a call to the -current mailing list asking for volunteers to port all Perl scripts in the base system to another language, such as sh or C. All critical programs are already being ported, with only a few minor ones left to be claimed." Wow..."
It appears that having Perl in the base distro has the following problems:
1. It increases the distro image size.
2. It forces everyone to use the same version of Perl.
3. If someone tries to install over that version or just even patch it, it can break stuff in BSD which needed the old version.
4. Installing multiple copies imposes weird symlink tricks or else breaks other stuff.
Like it or not from a perl perspective, perl shouldn't be required to install the OS any more than X11, tcl, python etc should be. *nix has gotten too fat. Praised be FreeBSD for getting back to its roots! Now I can install a sane perl without having to rip the old one out by its hair.
Ever install HatRed? 240 packages later, you have a 'stripped down' *nix. Talk about losing sight of the original idea....
I can't remember if I had to install perl for NetBSD, I thought I did, but it may be just the added packages. I know on one NetBSD box I have it has perl installed as a package. I think FreeBSD is doing the right thing. I mean it is not that hard to do 'make install' in the ports to install perl.
Only 'flamers' flame!
This has been discussed on Permonks
You can also read the discussion that led to this here
tstock
Not only is it more up-to-date, more easily upgraded, and able to get as bloated as Perl demands, it also includes the excellent BSDPAN.
/usr/pkg, makes them LOCALBASE clean, \o/
BSDPAN allows you to install CPAN modules and manage them like any other package (pkg_info, pkg_delete, etc), and for weenies like me who set LOCALBASE to
/usr/ports/lang/perl5 is not just there for completeness. Even if you have Perl installed from base, chances are anyone even remotely interested in Perl will want to replace it with the port anyway.
Now, if only we can convince core to remove sendmail...
This is great! First thing I do with my nice FreeBSD installs is remake world with NO_BIND, NO_SENDMAIL and NO_PERL. The other thing I'd like is separate packaging of all ports in their own directories in, say, /app.
/app/perl (ie. current) to /app/perl-x.y.z
That way you can have more than one version installed, and symlink
I'd like to see *all* parts of FreeBSD (incl. kernel, etc.) represented as pseudo-ports/packages in the package database to ease componentized installation (eg. no 'gcc' for client machines) and simple networked FS management.
I use things like Perl all the time, but I'd like the control of which Perl, which GCC, etc.
Sorry.. didn't make it clear. I put *all* major applications/packages where I track multiple versions (eg. Apache, Perl, Sendmail/Postfix, MySQL, PHP, prc-tools, GD, etc., etc.) in /app, allowing me to build and test newer versions without overwriting the current "approved" version.
/app in a different way, I avoid /usr/local for packages that I track. Throwaway, uncustomised packages (eg. zip, word2x) which I'm unlikely to ever get round to upgrading just go in /usr/local as usual.
/opt on other Unices, but since there doesn't seem to be a consensus on the correct structure of /opt, I avoid that name to prevent confusion when new sysadmins come on board.
Because I manage
/app/pkg (package installs)
/app/src (source)
/app/etc (package configs)
/app/var (logs, etc)
I tend to also keep the configure parameters and also config files in CVS.
Sounds like a lot of work, but worth it. The number of production boxes I've used (that others have set up) where different versions of things are spread around everywhere has made me reasonably tidy and regimented when setting up a production box.
I guess it's like
The only idiotic thing here is your argument.
I'm a Tivoli administrator and run into all sorts of issues because of Tivoli's continued support of perl v4. Perl 4 doesn't support useful features like modules, and the syntax is signifigantly different in a number of areas. But because so many customers invested a fortune in man-hours and consulting time to develop Tivoli scripts and perl-based policies, everyone is going to be stuck with a very old version of perl for the indefinate future.
Perl 5 is going to be a dinosaur just like perl 4 is today. When Perl 7 is out and there's a problem with a server that is a pain in the ass to fix becuase nobody remembers Perl 5 syntax, you'll be in the same boat.
ksh and sh are standardized on all platforms and do a good job. Use them whenever you can.
Conformity is the jailer of freedom and enemy of growth. -JFK
But they haven't! They are ramming C and sh down the average sysadmin's throat, without the slightest thought about what is appropriate for that sysadmin.
Don't be an ass. What they are doing is making sure that a default install of FreeBSD doesn't require a particular version of perl to be installed.
Great. You can go and add the one you want afterwards.
What is needed is a good, full-featured scripting language that the average sysadmin can master quickly. If I was paying to have my dream OS written, it would be Python, but Perl is good enough.
This is exactly what FreeBSD offers you. After you've installed it. Go add Python. You don't need to worry that the system relies on a particular version of Python, so you can install the one you want. In contrast to RedHat Linux which is wedded inseperably to Python 1.5.2, which has been out of data for about a millennia.