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..."
Perl's not a base requirement in most Linux distributions or other commercial Unix implementations. I would say it's a smart move for the FreeBSD team.
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.
1. As a perl user all i can say perl removal will be for the better. It will reduce the freebsd install size and will be easier to update perl ... w/o the need of symlinks & other cruft.
2. When Perl is integrated into the base system, users can either eat what they're given, or
jump through hoops to install a separate version and keep it separate. This change will
vastly improve and simplify supporting Perl on FreeBSD.
This makes a lot of sense. It seems like base installs can be pared down quite a bit. Is there any reason to have any shells installed? A web server shouldn't need them (not saying they aren't incredibly useful, but they might not be necessary).
Karma: Good (despite my invention of the Karma: sig)
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!
It's easier to keep perl up to date and apply patches for it (maintain) if there are no critical system pieces that depend on it. Perl was never considered 'standard' and shouldn't be installed on systems that don't need or use it. Of course many people who live/breathe/eat perl are going to be surprised, but this is good for them.
-Adam
It seems that although they remove a really useful program, it does mean that the Core group and committers will have more control of everything that goes into installing and operating the system.
I suppose that some may complain because they are so used to the Windows style bloat ware where someone else makes the choices for you. Ex: Windows Media Player, I prefer Quicktime. Plus I prefer Python over Perl. But not to get into some religious war, it's nice to see that FreeBSD will leave the choice to us. After all, someone who is going to the trouble of installing FreeBSD will probably want to roll it exactly the way they want. Besides, someone can always put an ISO together will some version of Perl and other goodies.
I just installed NetBSD 1.5 last week and Perl was not included in the base distribution set. I had to install a separate port package.
cpeterso
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...
I couldn't stand the obsolete perl 5.005 which was on the base system... once you install 5.6.1, things can mess up pretty quickly if you don't take care to separate things... not to say that you have to convince sysadmins...
... one day...
The worse is that the perl5 base would install obsolete modules, like cgi.pm.... and now if you install the cgi perl port, you have to either remove the original cgi.pm (will break at the next make installword) or tweak PERL5LIB to insert the path to the new modules before the others.... thanks god all that pain in the . will be gone
Yes, you get choice. You can install whatever you want from the package collection. And when they don't have any Perl installed any more you can install precisely the version you need without breaking anything. Sure, most people would be happy with the latest and greatest and it also works for them.
Perl is great, but its not essential. Its not a part of the operating system and should NOT be a mandatory install.
social sciences can never use experience to verify their statemen
Now all my old scripts will break. It wasn't until about a year ago that I started using "#!/usr/bin/env perl" instead of "#!/usr/bin/perl". Are they expecting me to symlink, or what?
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
Yeah!
Let's all install two different versions of perl on our boxes. One for the system, and one for the user. I've dealt with this hell on HP-UX 10.20 (which ships with perl 4) and I don't like it much. I know that disk space isn't all that expensive nowadays but still, there's some of us out there who like having a semi-clean filesystem and directory structure.
I applaud FreeBSD for finally starting to do what NetBSD has done since the beginning: Install a base OS and let the user decide what else they want or need. Is it really that hard to install perl from source/pkgsrc/ports or whatever? I run several NetBSD machines, and it never was much of an issue building perl from source and installing it. This is even true for the old VAXServer 3100 that I used to run. Yeah, it took a long time (this thing took 6 hours to compile bash), but wasn't "hard."
-J
The issue here isn't installing Perl. Which I'm sure given FreeBSD's history of the ports/pkg tree will be rather painless. The issue is the thousands of perl scripts which think perl is in /usr/bin/perl. It will be located in /usr/local/bin/perl... where it should be as its soon to be a local customization.
He's right, you're wrong. He posted logged in, you posted AC... coincidence? I think not. Someone remind me again why we allow AC posts, please?
scott
There are two more, from the article:
5. Integrating perl into the BSD build system is
difficult and error-prone.
6. Related to the above, perl has cross-build problems.
Ben "You have your mind on computers, it seems."
It's funny! It really brings home the phrase "Being your own worst enemy"...
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
In the real world, most sysadmin labor hours are spent on servers and workstations running powerful, modern hardware. And what they need are transparent, diagnosable systems. When things go wrong, or when they have a complex task to accomplish on a short schedule, they need to be able to reach inside the system and extend it. Hard coding system logic into C programs is extremely counterproductive, and sh is so limited and restrictive that you have to jump through all sorts of ridiculous hoops to accomplish the simplest tasks. 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.
-- ;-)
Kuro5hin.org: where the good times never end.
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.
Hint: Perl has always been hard to incorporate into the BSD build structure and breaks easily, especially in cases like cross-compilation. Because it's so fragile, it's a lot of work to maintain and tends to fall out of date. These are the kinds of things you need to worry about when you're actually maintaining an operating system, instead of throwing a kernel and 100's of externally maintained packages together and calling it done.
The FreeBSD solution is to move everything to depend on the /bin/sh executable: it's so vile and useless that nobody sane would **ever** use it for a significant application. Since no applications use it, there can be no conflict. This is self-evidently stupid.
The right solution is to pick a good language (call it "Foo"), put together a stripped-down interpreter for it, and put that interpreter it its own files. E.g., /usr/bin/system-foo. This has lots of benefits:
-- ;-)
Kuro5hin.org: where the good times never end.
Try reading what I wrote. At that point it's too late: the core is written in nasty old sh and hardcoded C. No amount of installing packages later can fix that fact.
/bin/sh executable: it's so vile and useless that nobody sane would **ever** use it for a significant application. Since no applications use it, there can be no conflict. This is self-evidently stupid.
;-)]
I did. I still disagree with you. Core scripts being written in sh does not impact system administration. It impacts people who need to maintain the core scripts only.
In the event that an administrator needs to modify any of these scripts, the important thing is that the widest possible array of system administrators are able to. That means using sh. If I found a script I needed to alter written in perl, I'd rather wrip it out and re-write it. There'd be plenty of other people who'd say the same for Python, Ruby, or whatever high level language you pick. sh is universal.
The FreeBSD solution is to move everything to depend on the
No-one is asking you to write applications in it. All system administrators live and breath sh. It has existed, largely unchanged, on every UNIX platform since the dawn of time (epoch). If you can't hack it then I suggest you get out of the sysadmin game (and if you're not a system administrator, what the hell is this argument based on?)
If you wish to layer your own administration framework on top of the core system, then you are free to choose whatever language you like.
I recommend using Arusha which uses classless object-oriented XML source and supports methods written in Python, perl, or sh. [But I would recommend it as one of the developers.
[mailto:owner
Sent: Wednesday, May 15, 2002 9:44 AM
To: announce@freebsd.org
Subject: Perl5 is leaving the base system for 5.0 and after!
Hello folks!
It has been decided after some debate to remove Perl5 from the "Base FreeBSD" sources. This decision was not taken lightly, and was taken in consultation with (but not seeking the approval of) the perl5 developer community.
There are 2 main reasons for this:
1) Perl5 is getting larger very fast, and FreeBSD cannot afford the time and space to build and maintain it.
2) Upgrading the "base perl" is a nightmare that regularly breaks upgrades and cross-builds, to the intense annoyance of the FreeBSD developer community.
Speaking as the "Perl5 guy", keeping FreeBSD's "base perl" up to date was hellish, and folks who wish a return to that state should please consider doing this work in my place. BEWARE! This job is not trivial!
PERL IS NOT BEING OSTRACISED! FreeBSD is not taking this action because of any dispute between the FreeBSD community and the Perl community - such a dispute DOES NOT EXIST! In fact, the Perl community have been exemplary in their attempts to understand the problem, and in their proposals to deal with it. FreeBSD DOES NOT HATE PERL!
Some time in the future, perl may be split in half, such that the core language and the standard libraries may be separately installed. In such a case, FreeBSD might be in a position to better deal with the problem of the very large perl libraries. Such splitting will be done by the perl community, NOT by us, although we will be taking note.
In the meanwhile, the Perl5 Port will continue to be available, and continued discussion indicates that there is very substantial support for it to be installed by default (or near-default) by sysinstall.
This will result in a FreeBSD that has effectively the same Perl5 that is kept up-to-date in ports, rather than the one that is left to rot in STABLE.
This update will _NOT_ be MFCed. The first FreeBSD that has no perl in the default sources will be 5.0-RELEASE, when that is released at the end of this year. FreeBSD-4.n will continue with the perl that it currently has.
The ports system will continue to support Perl5.
M .sig is umop ap!sdn
--
o Mark Murray
\_
O.\_ Warning: this
This is the moderated mailing list freebsd-announce.
The list contains announcements of new FreeBSD capabilities,
important events and project milestones.
See also the FreeBSD Web pages at http://www.freebsd.org
-- ;-)
Kuro5hin.org: where the good times never end.
Regards, Jens
SIGSIG -- signature too long (core dumped)