Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
BSD Operating Systems

FreeBSD: Perl to be removed 97

Posted by Hemos from the killing-the-perl dept.
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..."
This discussion has been archived. No new comments can be posted.

FreeBSD: Perl to be removed More

FreeBSD: Perl to be removed

Comments Filter:
  • Why are they doing this? What do they have to gain by removing Perl from the base installation?
    • 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 (Score:5, Informative)

      by hawkstone ( 233083 ) on Monday May 13, 2002 @07:31PM (#3513689)
      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 (Score:4, Interesting)

      by josepha48 ( 13953 ) on Monday May 13, 2002 @07:38PM (#3513714) Journal
      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.

      • 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.
        • 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.
    • What do they have to gain by removing Perl from the base installation?

      45 megabytes for the next generation "Perl Contract". Read the article.
    • 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 [freebsd.org]

    • 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
  • 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.
    • Absolutely! the only reason why to use BSD over LInux is that perl is properly supported and such features like perlcc works
  • 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 (Score:2, Insightful)

      by Arandir ( 19206 )
      A POSIX system needs a Bourne compatible shell.

    • Re:interesting (Score:4, Informative)

      by Gid1 ( 23642 ) <[ten.neddig] [ta] [mot]> on Monday May 13, 2002 @09:19PM (#3514292)
      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.

      • /app? (Score:1)

        by tps12 ( 105590 )
        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? (Score:4, Informative)

          by Gid1 ( 23642 ) <[ten.neddig] [ta] [mot]> on Tuesday May 14, 2002 @07:38AM (#3516414)
          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.
    • 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 (Score:1)

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

  • And now, back to your regularly scheduled UNIX. (Score:4, Insightful)

    by Masque ( 20587 ) on Monday May 13, 2002 @07:37PM (#3513706)
    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....
  • 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.

    • Some choice (Score:1, Flamebait)

      by sigwinch ( 115375 )
      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 (Score:2, Informative)

        by Nickus ( 10876 )

        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 (Score:2, Insightful)

        by Spazzz ( 577014 )
        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 (Score:3, Interesting)

          by sigwinch ( 115375 )
          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 (Score:4, Insightful)

            by hoggy ( 10971 ) on Tuesday May 14, 2002 @03:59PM (#3519914) Homepage Journal
            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.
            • 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.
              • 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 [sf.net] 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. ;-)]
                • 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 (Score:1)

                    by 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 (Score:1, Insightful)

            by rsd1s1g ( 519812 )
            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 (Score:4, Insightful)

        by duffbeer703 ( 177751 ) on Tuesday May 14, 2002 @01:32PM (#3518810)
        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 (Score:3, Informative)

        by mph ( 7675 )
        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.

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

  • perlmonks (Score:4, Informative)

    by tstock ( 213857 ) on Monday May 13, 2002 @08:11PM (#3513900) Homepage
    This has been discussed on Permonks [perlmonks.org]

    You can also read the discussion that led to this here [develooper.com]

    tstock

  • Perl from ports is worth it even for -STABLE (Score:5, Insightful)

    by Fweeky ( 41046 ) on Monday May 13, 2002 @09:04PM (#3514213) Homepage
    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...

  • OpenBSD (Score:1, Interesting)

    by Anonymous Coward
    so when is perl going to ripped out of the default OpenBSD install?
  • 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...

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

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

  • Good (Score:2)

    by dh003i ( 203189 )
    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 (Score:3, Insightful)

    by Permission Denied ( 551645 ) on Tuesday May 14, 2002 @12:20AM (#3515029) Journal
    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?
    • eh, awk is still in the base.

    • Re:#!/usr/bin/perl (Score:3, Informative)

      by Z4rd0Z ( 211373 )
      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.
      • 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).

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

    • Re:#!/usr/bin/perl (Score:1, Funny)

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

  • Partly my fault ;-) (Score:1, Informative)

    by 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

    • How do you figure Perl to be a security risk?

      • Re:Partly my fault ;-) (Score:1)

        by 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.
  • 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...:))
  • 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.

Slashdot Top Deals

Do you suffer painful hallucination? -- Don Juan, cited by Carlos Casteneda

Close