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..."

Comments

The obvious question remains

[Matt0ly]

Why are they doing this? What do they have to gain by removing Perl from the base installation?

Re:The obvious question remains

[cfreeze]

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.

Re:The obvious question remains

[hawkstone]

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.

Re:The obvious question remains

[josepha48]

Is is not in most standard unix installations. If you get HP, Sun, or Linux perl is a seperate package. Linux usually installs it on the system as part of the development packages, but it is a seperate package and you can set up a Linux box without it. Sun is the same way, as is HP and AIX.

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.

Re:The obvious question remains

[Arandir]

What do they have to gain by removing Perl from the base installation?

45 megabytes for the next generation "Perl Contract". Read the article.

Re:The obvious question remains

[benedict]

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.

Re:The obvious question remains

[Anonymous Coward]

Why don't you read before posting? Your question is fscking answered in the link.

Re:The obvious question remains

[jo42]

From: owner-freebsd-announce@FreeBSD.ORG
[mailto:owner- freebsd-announce@FreeBSD.ORG] On Behalf Of Mark Murray
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
--
o Mark Murray
\_
O.\_ Warning: this .sig is umop ap!sdn

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

Re:The obvious question remains

[schweikh]

Being a committer and having read the relevant mailing lists, let me add two more reasons, that I think have so far not been mentioned. Remember what we are talking about: perl has been removed from the base system in order to make the build perl-independent. Why is this a Good Thing?

• For once it saves us on the order of 45MB repo space. The build itself didn't need more than a few in-place s/foo/bar/g which we now do with sed, awk, sh, the tools we need to build anyway. Building perl as a prerequisite for just a few variable substitutions was obviously overkill.
  
• The most compelling reason IMHO is: you just can't cross-configure perl on arch A for arch B--it will always be built for the host it is configured on (unlike e.g. the compiler tool chain). With support for alpha and sparc this has become an endless source of frustration.
  

Regards, Jens

Re:The obvious question remains

[Anonymous Coward]

One more thing: it forces the user to know Perl
just to review scripts for the base files. You
don't have to be proficient in awk, perl, m4, python, or bash
just for to do follow the flow of how the base system
works. A solid knowledge of something like csh(1), sh(1), and ash(1)
should be all that is required.

Reasons why

[Chinese Karma Whore]

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.

Re:Reasons why

[ext]

Absolutely! the only reason why to use BSD over LInux is that perl is properly supported and such features like perlcc works

interesting

[tps12]

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).

Re:interesting

[Arandir]

A POSIX system needs a Bourne compatible shell.

Re:interesting

[Gid1]

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.

That way you can have more than one version installed, and symlink /app/perl (ie. current) to /app/perl-x.y.z

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.

Re:interesting

[serial frame]

Without a POSIX-style /bin/sh present (I.e., accepts -c "commands"), any use of system() will be broken. Oh, and obviously, startup scripts, regular shell scripts, and perhaps many utilities would be impossible to implement without a shell. Basically, in that kind of situation, I would go with busybox, or just Kenneth Almquist's ash. Experiment and see what you would need.

Re:interesting

[Anonymous Coward]

Do you seriously want to write and maintain /etc/rc in C?

And now, back to your regularly scheduled UNIX.

[Masque]

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....

Re:And now, back to your regularly scheduled UNIX.

[Cuthalion]

Ever install HatRed? 240 packages later, you have a 'stripped down' *nix. Talk about losing sight of the original idea....

I had no idea that the original idea of unix was minimalism.

Re:And now, back to your regularly scheduled UNIX.

[Anonymous Coward]

Is that sarcasm?

Re:And now, back to your regularly scheduled UNIX.

[bofkentucky]

At its core, unix is a minimalist system, its kind of a Chinese buffet, small simple tools that chained together make a complete system (meal). No one tool is all knowing and all seeing, hurd and other microkernel types fit this mentality down to the kernel itself, with scheduling, I/O, lock resolution, etc seperated out into little minature daemons. As opposed to windows where it is one giant tangle of dll's and executables. Theres a lot to be said for a system that originally ran in 4K of memory scalling up to some of the monster supercomputing apps we see today with terrabytes of memory, but at its core, the same simple tools dc, sed, awk, a shell, ls, and rm being able to perform amazing tasks.

Re:And now, back to your regularly scheduled UNIX.

[Anonymous Coward]

Beg to differ. Not the run of the mill Chinese buffet with all its redundant dishes, like "General Tso's chicken" and "Sesame Chicken", etc. More like the orthogonality of a Mongolian barbecue. Larry Wall isn't wild about orthogonality. He said so in his book.

It may seem odd, but this is A Good Thing (tm)

[stienman]

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

More Control for FreeBSD

[digital_freedom]

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.

Re:More Control for FreeBSD

[Anonymous Coward]

After all, someone who is going to the trouble of installing FreeBSD will probably want to roll it exactly the way they want.

You should have said, "After all, someone who is going to the trouble of installing FreeBSD will probably want to roll it exactly the way he wants."

NetBSD 1.5 does not require Perl

[cpeterso]

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.

Re:NetBSD 1.5 does not require Perl

[mirabilos]

Now, OpenBSD 3.2 has to do this step also.
(Nice, we got new binutils - from 2.9 to 2.11.2)

I find this good because it disables more bloat
in the base system. Removing sendmail and bind,
however, I wouldn't be a friend of, because they
are audited by the team (which cannot be solved
this way by a port) and heavily used (I don't
use bind - djbdns - but many people prefer an
audited bind 4 over bind 9...)

I remember some months ago, uucp was made a port.
The r-suite will also be available as a port.

perlmonks

[tstock]

This has been discussed on Permonks

You can also read the discussion that led to this here

tstock

Re:perlmonks

[Anonymous Coward]

OK, which thread on develooper.com is the one to read? I scanned all of 'em on that page, and none had an obvious reference to FreeBSD.

Perl from ports is worth it even for -STABLE

[Fweeky]

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.

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/pkg, makes them LOCALBASE clean, \o/

/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...

Re:Perl from ports is worth it even for -STABLE

[WasterDave]

Now, if only we can convince core to remove sendmail...

Oh, dream on. You'll be wanting to get rid of BIND next.

Dave

Re:Perl from ports is worth it even for -STABLE

[someonehasmyname]

damn right. kill sendmail, kill bind. I'd much rather:

a) have a choice between a few

b) install qmail/djbdns by default. =)

Re:Perl from ports is worth it even for -STABLE

[WasterDave]

You're preaching to the choir here, man.

Dave

Re:Perl from ports is worth it even for -STABLE

[Anonymous Coward]

Actually, I think the qmail port is configured to automatically make the changes necessary to mailwrapper to replace sendmail.

Re:Perl from ports is worth it even for -STABLE

[realdpk]

Or uucp.. or even xten. Perl's more worthwhile than either one of those.

Re:Perl from ports is worth it even for -STABLE

[prog-guru]

uucp is out of 5.0 I think.

OpenBSD

[Anonymous Coward]

so when is perl going to ripped out of the default OpenBSD install?

Some choice

[sigwinch]

But not to get into some religious war, it's nice to see that FreeBSD will leave the choice to us.

Yeah, you get your choice of C or sh, which are bletcherous languages for system administration. To diagnose/repair a broken C program, you have to be a skilled programmer with a lot of time on your hands. No instant patches/changes are possible. If that little system automation utility written in C breaks in production, the typical business should expect hours of downtime.

Or there's sh, which you can fix instantly, but you have to learn yet another toy syntax, a syntax that is highly restrictive when it comes to real programming work.

And what is the justification for this? So it'll fit better on ancient, obsolete harware. Great, my sysadmins will piss away thousands of dollars in labor (and possibly millions in downtime) dealing with shitty languages, because it will save the hundreds of dollars it would cost to replace that old 486 router.

Equally idiotic are the arguments that using Perl for the core makes it difficult to upgrade Perl. That's because they should be different Perls. For core system stuff, there should be /usr/bin/system-perl, an old, stable, stripped-down Perl that rarely changes. Applications should use /usr/bin/perl, which can be upgraded as needed to make the latest apps run.

Morons. Hardware cost is almost always irrelevant. Dependency conflicts almost always mean you need to fork. But no, we have to change the admins to suit the machine...

Re:Some choice

[Nickus]

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.

Re:Some choice

[Spazzz]

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

Re:Some choice

[r00tarded]

sigwinch is right, you should use python.

Re:Some choice

[duffbeer703]

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.

Re:Some choice

[sigwinch]

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.

Maybe I didn't make that clear: the two Perls should be *completely* separate. /usr/bin/system-perl should come from its own dedicated package, a package that the core maintainers guarantee does not conflict with anything else. It should not be a standard package that has been kluged to install in an odd location. You should be able to upgrade user Perl with absolute confidence that system Perl will not break, and vice versa. The only thing they should share is a name and a syntax.

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.

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.

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.

Re:Some choice

[hoggy]

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.

Re:Some choice

[mph]

And what is the justification for this? So it'll fit better on ancient, obsolete harware.

That's not the argument against it. I guess talking out of your ass is easier than actually reading about the issues involved. Of course, I'm sure that you innately know more about this topic than the FreeBSD and Perl experts who worked on this solution, together, at length.

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.

Re:Some choice

[sigwinch]

What they are doing is making sure that a default install of FreeBSD doesn't require a particular version of perl to be installed.

Are you replying to the post I wrote? My two points were 1) that a modern operating system *should* rely on a particular version of a full-featured scripting language, and 2) the interpreter for that language should not be shared with applications (to prevent the upgrade problem).

This is exactly what FreeBSD offers you. After you've installed it. Go add Python.

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.

In contrast to RedHat Linux which is wedded inseperably to Python 1.5.2, which has been out of data for about a millennia.

Exactly. Red Hat made the same mistake as FreeBSD: they needed a good language for scripting the core OS, and they stupidly used the same package as user applications. And now, predictably, the user applications cannot be upgraded because it would break the really important stuff. The solution is to break that dependency: make the applications and the core depend on different executables.

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:

1. All the "kitchen sink" libraries have been ripped out, so it doesn't take up much space.
2. It is used for a small set of tasks that rarely change, so there is no need to track the latest upgrades, just the critical bugfixes.
3. It has completely different file names, so applications will never use it by mistake.
4. Application packages use different file names, so they can be upgraded at will. The core won't notice.
5. Sysadmins and core maintainers won't waste time and sanity dealing with the nasty syntax and limitations of sh. They'll work in Foo, a nice modern language.

Re:Some choice

[r00tarded]

dammit mods, not offtopic, this is blantant flamebait.

Re:Some choice

[hoggy]

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.

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 /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.

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. ;-)]

Re:Some choice

[Huge Pi Removal]

I have to agree: for instance, the "adduser" program is written in perl. In order to set up a load of virtual hosts, with complicated permissions, I incorporated a hacked-around version of adduser to perform some of the tasks. No way could I have done that if it was written in C. Jeez..... Perl is great for manipulating all that stuff, and is easy to maintain with a bit of easily-obtained knowledge.

Re:Some choice

[Anonymous Coward]

If it'll reliably do the job, it isn't obsolete. Putting a disused copy of Perl on every appliance on the planet just so your admins don't have to type cd /usr/ports/lang/perl5 && make install was ridiculous, and knowingly preserving a second copy whose sole purpose is to deter use of new features should be a hanging offense.

Re:Some choice

[sigwinch]

It impacts people who need to maintain the core scripts only.

All sites with more than a dozen or so users need to be able to customize the scripts, or at least easily read them to figure out what the hell is going on. That most sysadmins are novices, and work at smallish sites, dictates that the scripts should be written in a friendly language.

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.

I agree. I'm just taking the wider view that computers should be for *all* people with a modicum of skill, not just veterans of the Unix wars. So languages for common automation tasks should be chosen solely for ease of use by novices. As VB and especially Python have proven, it is possible for a language to be friendly to novices *and* a decent tool for wizards.

Re:Some choice

[rsd1s1g]

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.

Have you read anything?? Jeez! It just doesn't ship with Perl any more. Nobody said anything about not being able to HAVE it in FreeBSD. You want Python? You want Perl? Install it afterwards! Hey: you can even have the luxury of installing it from source! Quite the novelty, eh?

Re:Some choice

[Anonymous Coward]

Since when are Perl and Python easier to understand than /bin/sh?

Scripting doesn't get much simpler than /bin/sh. In the modern context of mutant nix branding, it's nice that there is a single, common scripting environment that "runs" the computer and works in single user mode.

Re:Some choice

[Anonymous Coward]

Amen.
scripting in sh or bash is straight, easy, flexible
, fun to do, compile zero.
Perl is great for strings however.
Python i do not know but Blender was written in it and i liked the program it was/is fast memory clever
and looked nice.

I guess you can install perl on FreeBSD when choosing the packages or did $they stripped it out
completly?

Re:Some choice

[Anonymous Coward]

> That most sysadmins are novices, and work at smallish sites, dictates that the scripts should be written in a friendly language.

ROTFLMAO!!!

Perl is a "friendly language" for novice SAs?!?!?!?

the really cool thing is coming

[node3667]

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...

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 ... one day...

Re:the really cool thing is coming

[MadAhab]

Yeah, that reminds me of using redhat. CPAN has become a big pain what with agressive upgrade. Asked some admin to install a perl module, he upgraded perl due to agressive prompting via CPAN, now it depends on which perl you toot and libraries are a big mess. Had to redo it myself. I never upgraded perl from ports on freebsd, and I never had those kinds of problems. Of course, freebsd also has a very broad arrays of perl modules intallable through ports packages, which is (and should continue to be) fairly painless, and on the rare occasion i need one not in port, perl Makefile.pl etc works fine.

perl is dead. Long live perl.

tally ho

[seraphim via]

It seems pretty nice. Smaller installation is good. I think most people believe this is a good choice.

Good

[dh003i]

Perl is great, but its not essential. Its not a part of the operating system and should NOT be a mandatory install.

#!/usr/bin/perl

[Permission Denied]

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?

Re:#!/usr/bin/perl

[ozzmosis]

eh, awk is still in the base.

Re:#!/usr/bin/perl

[Z4rd0Z]

There will be a small redirector program called /usr/bin/perl that looks for perl and passes your script on to it, and if it doesn't find perl, gives you an error message.

Re:#!/usr/bin/perl

[Permission Denied]

small redirector program called /usr/bin/perl

Cool. Sounds like the best solution. Not that it would be too difficult when I see 'zsh: no such file or directory: /usr/bin/perl', but this is more elegant (holding together old systems using symlinks like duct tape leads to sheer madness).

Re:#!/usr/bin/perl

[Anonymous Coward]

If you use perl for everything, surely you can write a perl script to replace all occurrences of that.

Re:#!/usr/bin/perl

[prog-guru]

Gross, kind of reminds me of that sendmail/mailwrapper mess.

Partly my fault ;-)

[Anonymous Coward]

I bitched and moaned about the size of base-install on the security mailing list; I got a lot of people with me, including, but not limited to, JKH.

The biggest reason is the fact that it breaks stuff, if you need another version of perl you have to know your system to get your box running without a hitch.

For me, the reason however was founded on security, I was tired of having to write csh-scripts to strip my system from potential security holes; including Sendmail and Perl.
It is a lot easier to secure a firewall that only has a kernel, cshell and not mcu else than the mastodont it was by default.

I run NetBSD on that box now, but anyway, good to see it as I use FreeBSD on my laptop.

Kind regards,
Da

Re:Partly my fault ;-)

[Piquan]

How do you figure Perl to be a security risk?

Re:Partly my fault ;-)

[Anonymous Coward]

In the last two decades there are a few things I've learned the hard way; Murphy's Laws summarise these.

1. If anything can go wrong, it will.
2. If there is a possibility of several things going wrong, the one that will cause the most damage will be the first one to go wrong.
3. If anything just cannot go wrong, it will anyway.
4. If you perceive that there are four possible ways in which something can go wrong, and circumvent these, then a fifth way, unprepared for, will promptly develop.
5. Left to themselves, things tend to go from bad to worse.
6. If everything seems to be going well, you have obviously overlooked something.
7. Nature always sides with the hidden flaw.
8. Mother nature is a bitch.

Over the last decade on working with security I've seen the most bizarre things, from a hunting phantom black hat that turned out to be flawed ECC memory to hunting a black hat that turned out to be _myself_ being drunk the week before.

Trust me, don't trust anything.

You, Maam, are an idiot.

[Anonymous Coward]

Yeah, you get your choice of C or sh, which are bletcherous languages for system administration.

Shows how much YOU know.

Microsoft has made C Sharp run on FreeBSD.

And you can have csh, zsh, ksh OS sh as a shell.

Odds are web based adminstration is about all you can handle. (and that too is an option on FreeBSD)

Re:You, Maam, are an idiot.

[Pauly]

This is far from "flamebait." Oh, wait, this is slashdot, where realistic appraisals of Perl are non grata.

C and sh are MUCH better for system administration once you figure out how to use the pipe along with the hundreds of useful utilities already on the system.
Perl is for people who don't get the pipe.
Perl is for people who think their scripts are portable since it runs on both of their linux systems.
Remember people, Perl modules are written in C.

/app?

[tps12]

I guess I miss the point of "/app"...

That way you can have more than one version installed, and symlink /app/perl (ie. current) to /app/perl-x.y.z

What's wrong with /usr/local/perl -> /usr/local/perl-x.y.z ?

Re:/app?

[Gid1]

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.

Because I manage /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.

/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 /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.

no they're

[Anonymous Coward]

expecting you to keep using env and to take the 4 minutes to install a package that will provide perl.
Honestly, the world is so full of the lazy and surly. Mmmm, teamsters.

Re:no they're

[essdodson]

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?

Someone mod the above up

[Sits]

It's funny! It really brings home the phrase "Being your own worst enemy"...

Ok, Now I agree with it.

[bovinewasteproduct]

When I added Perl to FreeBSD pre 2.0 (This was right after the nasty little letters from USL), Perl was at 4.036 and SMALL.

It has now gotten so bloated I can't belive it! I still use and love Perl, but do we really need all of the modules included? I thought that was what CPAN was for.

BWP
(Yes, I am the one that added Perl to FreeBSD. I also can be thanked for other things such as the "GPLed" math emulator (it is not!), sun libm, the broken mitsumi CD-ROM driver of 1.0 and the original FAQ. For those that doubt me, contact me via email...:))

for that matter

[Anonymous Coward]

Explain why they persist in allowing fools such as youself, who are so very easily trolled, to post responses. If anything, you should consider posting AC yourself, just to avoid having the humiliation of being gullible and dim witted associated with your name.

Of course, you may be so dim witted that you don't realize how foolish you look. Sigh. You're further evidence that the human race is going down the shitter.

Re:for that matter

[someonehasmyname]

no, you know what.. he's fucking right. if you knew anything about FreeBSD, you'd know that standard packages are installed in /usr/bin, where as non-standard packages (installed from ports) get installed in /usr/local/bin.

I think it is a good thing

[xutopia]

I've been trying open source OS's for a while. I would love to see the day when you have a core OS install CD and the only utility that comes with it is the "Download new Packages" program. Sincerely I find that the amount of Beta programs you get when installing a new OS really bites. We should have the choice of which stable release we want rather then the latest that a group of people choose. my 2 cents.

Re:I think it is a good thing

[Anonymous Coward]

But isn't that what Debian is for?
You have your choice: Stable, testing or unstable.

A millennia?

[Anonymous Coward]

The singular is millenium