Forgot your password?
typodupeerror
Perl Programming Businesses Apple

Apple's Mac OS X Update Breaks Perl 264

Posted by CmdrTaco
from the how-will-i-regex-now dept.
mir writes "It looks like if you use CPAN to install modules, Apple's latest security update might just have broken your Perl. According to Tatsuhiko Miyagawa 'The Security Update brings (old) IO.bundle with version 1.22 but your IO.pm has been updated to the latest 1.23 on CPAN shell. (But hey, 1.23 was released in 2006...Why do you bring that ancient version back, Apple!?)'."
This discussion has been archived. No new comments can be posted.

Apple's Mac OS X Update Breaks Perl

Comments Filter:
  • Apple (Score:3, Insightful)

    by Anonymous Coward on Wednesday February 18, 2009 @11:25AM (#26902163)

    "It just works"

    • Re:Apple (Score:5, Funny)

      by telchine (719345) on Wednesday February 18, 2009 @11:35AM (#26902273)

      Some would argue that Perl has been broken for a long time before Apple started meddling!

    • Re:Apple (Score:4, Informative)

      by ThePhilips (752041) on Wednesday February 18, 2009 @12:04PM (#26902653) Homepage Journal

      This is not a first Apple's blopper. Any OS vendor might have those.

      The question is how long would it take for Apple to fix that. In the blog post linked Fedora Perl issues actually took about year to deliver fix for RHEL.

      While compiling and using your own build of Perl (or using Fink) on Mac OS X is absolutely OK, under RHEL that might easily screw up your RH support contract...

      • under RHEL that might easily screw up your RH support contract

        It's unfortunate that the package was broken, though compiling your own version will not void any service contracts.

        See: http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-filesystem-fhs.html [redhat.com]
        /usr/local/, its taken from fhs, which redhat honors.

        Also, the standard redhat PATH contains /usr/local/bin before /usr/bin, or even /bin.

        • Re: (Score:3, Interesting)

          by ThePhilips (752041)

          It's unfortunate that the package was broken, though compiling your own version will not void any service contracts.

          They can't void service contract.

          Disclaimer: I never used RHEL, only talked in past on several occasions with frustrated users. (Frustration mainly coming from the fact that they expected more freedom from RHEL, yet in the end got pretty much the same deal (albeit cheaper) as from proprietary *nix vendors.)

          I was under impression that if RH support finds some custom build application, they would first ask to remove it (or restore system from backup) before they would start actually helping your with p

    • Re:Apple (Score:5, Funny)

      by Gadget_Guy (627405) on Wednesday February 18, 2009 @12:13PM (#26902777)

      Oh, I see. I was under the impression that the phrase "It just works" was a synonym for something like "It simply works". Apparently it is a synonym for "It barely works".

      OK, that was a bit unfair. Every OS gets the occasional problem when doing updates. Assuming that there is a forthcoming fix in the near future, there is no need to obsess about it.

      • Oh, I see. I was under the impression that the phrase "It just works" was a synonym for something like "It simply works". Apparently it is a synonym for "It barely works".

        I thought "It barely works" is M$ Windows. Or is there less difference between the companies than one would initially guess?

      • Re: (Score:2, Informative)

        by emm-tee (23371)

        Oh, I see. I was under the impression that the phrase "It just works" was a synonym for something like "It simply works". Apparently it is a synonym for "It barely works".

        OK, that was a bit unfair. Every OS gets the occasional problem when doing updates. Assuming that there is a forthcoming fix in the near future, there is no need to obsess about it.

        That is rather unfair -

        The problem only affects certain "knowledgeable" users who changed certain operating system files.

        An operating system update can hardly be expected to work-around all the hacks people have made to the operating system's own files.

        If different versions of the files were required by the user, they should have been installed in a separate location.

    • by leamanc (961376)
      It does just work, if you take what Apple gives you and don't customize it too much. Installing your own modules? Not the Apple way. Go to Linux for that kind of thing. Who would use OS X for serious Perl work anyway?
      • Re: (Score:3, Informative)

        by jbolden (176878)

        You can use the darwin ports version and get the latest perl. Apple supports a stable Perl in line with their mainstream users and an up to the minute Perl for their development community.

      • Re: (Score:3, Informative)

        Who would use OS X for serious Perl work anyway?

        I suppose, people who prefer OS X to Linux. In fact, the Ruby community seems to be using OS X quite a lot, lately.

    • The slogan in its fullest is actually:

      "It just works; we reserve exclusive rights to define what 'it' and 'works' mean."

  • by Ed Avis (5917) <ed@membled.com> on Wednesday February 18, 2009 @11:26AM (#26902173) Homepage

    Why are Apple's updater and Perl's CPAN shell both trying to update the same file? If the file's there as part of the Apple OS then only the OS's package manager should touch it, and Perl should leave it alone (installing its own version in /usr/local if necessary). It's exactly the same on Linux distributions: the CPAN shell doesn't try to mess with the system perl which is updated using rpm or dpkg.

    • by warren.oates (925589) on Wednesday February 18, 2009 @11:34AM (#26902253)

      We don't exactly have "package managers" in OS X. The BSD side of OS X is only barely "maintained" at all, and then in some truly obscure and incoherent bubble-headed Cupertino fashion. Anything you really want to actually work with, you have to maintain yourself: PHP, Apache, rsync, ffmpeg, Perl -- all the seriously useful stuff like that you put into /usr/local and set your $PATH accordingly. You _cannot_ trust Apple not to break things.

      • by 99BottlesOfBeerInMyF (813746) on Wednesday February 18, 2009 @11:40AM (#26902329)

        We don't exactly have "package managers" in OS X.

        Sure we do, a bunch of them. That's kind of the problem.

        Anything you really want to actually work with, you have to maintain yourself

        That's a bit of an overstatement. Anything you want a cutting edge version of you'd do well to install and maintain yourself outside of Apple's update path, but for most people just using the Apple installed versions is fine.

      • by King_TJ (85913) on Wednesday February 18, 2009 @11:40AM (#26902333) Journal

        Umm, what about Fink?

        http://www.finkproject.org/ [finkproject.org]

        • by 1stvamp (662375) on Wednesday February 18, 2009 @11:44AM (#26902389) Homepage

          Or MacPorts, formerly DarwinPorts: http://macports.org/ [macports.org]

          • Re: (Score:3, Insightful)

            by Jay Maynard (54798)

            I refuse to use both Fink and MacPorts because they insist on bringing in huge amounts of other stuff whenever I try to install anything. I'll build for myself from source first.

            • Re: (Score:3, Insightful)

              by truthsearch (249536)

              Same here. I don't understand why I need the X11 sources compiled from fink just to get apache 2 and php.

              • Re: (Score:3, Interesting)

                by SuperIceBoy (787273)

                Same here. I don't understand why I need the X11 sources compiled from fink just to get apache 2 and php.

                Not sure about on Mac, but on FreeBSD I define WITHOUT_X11 so that it doesn't do that.

              • by TJamieson (218336) on Wednesday February 18, 2009 @12:44PM (#26903185)

                With MacPorts you can provide a keyword before installing to see what options an install might have.

                So for instance, for apache2 you might type:
                port install apache2

                to install. Before doing this, try:
                port variants apache2

                This should produce a list. Hopefully X11 is in there (I can't verify right now). Anyway, find any options you want to enable or disable, and reform your install to look like this:
                port install apache2 +enable_option -disable_option

                This will usually let you strip away a goofy dep like X11 from programs that don't really need it.

                • by drinkypoo (153816)

                  I just can't help it but... this is what gentoo's USE flags are all about. Does MacPorts let you set an environment variable to do something similar, and is there even any point (i.e. do the port maintainers use the same name for options?)

                  • Re: (Score:3, Interesting)

                    by abigor (540274)

                    You've got it backwards - Gentoo's system is ports-inspired, as they freely acknowledge. MacPorts is more or less the BSD ports system running on OS X.

                    You can set environment variables like so:

                    default_variants +ssl -X11 ...and so forth.

            • Hear, hear.

              Sometimes it's a pain to get the ./configure right on a build, but it can't possibly be more painful than dealing with the fact that dports and fink have a steep learning curve and don't PUT stuff in the RIGHT PLACES. Meaning I have to reconfigure my other programs to tell them where to find supporting libraries and programs.

              If the build-savvy Apple community wanted to help distribute ports, they should just build a whole bunch of .pkg's. Until then, I'll stick with gcc-compiling from source.

              • Amen. This is why Hercules [hercules-390.org] is distributed as a .pkg for OS X. I don't want to put Hercules users through the pain of dealing with Fink or MacPorts.

        • by Ash-Fox (726320)

          Umm, what about Fink?

          Fink has a tendency to have compile issues, segfaults etc. with random packages. ...

          Then again, one gets the same problems generally under OS X when compiling the forementioned software manually, although it will generally work in more instances than Fink/Macports does.

      • You could help fix that problem by participating with projects such as Fink [finkproject.org], MacPorts [macports.org] or OSXPM.
    • by pegdhcp (1158827) on Wednesday February 18, 2009 @11:50AM (#26902471)

      Why are Apple's updater and Perl's CPAN shell both trying to update the same file?

      Probably this is the real point, as mentioned in the TFA:

      "This is another reason why you shouldn't use Perl that comes from vendors," Miyagawa says. "Apple isn't any different from Fedora on this!"

      I might add Mandriva, SuSe and most others. Distribution managers want it just run and be stable for users who do not want to know what is going on inside. If there is a need for messing with details, originally packaged software by developer is the best alternative...

      • Re: (Score:3, Insightful)

        by bcrowell (177657)

        "This is another reason why you shouldn't use Perl that comes from vendors," Miyagawa says. "Apple isn't any different from Fedora on this!"

        I might add Mandriva, SuSe and most others. Distribution managers want it just run and be stable for users who do not want to know what is going on inside. If there is a need for messing with details, originally packaged software by developer is the best alternative...

        I don't think the situations on Linux and MacOS are as similar as you're making them out to be. Ever

    • by Alrescha (50745) on Wednesday February 18, 2009 @12:16PM (#26902811)

      "Why are Apple's updater and Perl's CPAN shell both trying to update the same file? If the file's there as part of the Apple OS then only the OS's package manager should touch it, and Perl should leave it alone (installing its own version in /usr/local if necessary)."

      Why must we learn these lessons again and again? Back in the beginning of time (1983), we learned the following:

      Rule #1: Never change *anything* that [vendor] sends you

      Rule #2: Always keep your stuff separate from [vendor]

      (thank you Melinda)

      • by Ed Avis (5917) <ed@membled.com> on Wednesday February 18, 2009 @12:57PM (#26903377) Homepage

        On a modern Linux distribution, it's actually okay to modify stuff that the vendor sends you, provided you do it using the same infrastructure as the vendor. For example, on an RPM-based system, you can easily build and install your own local RPM packages, with dependencies and all that, and they integrate nicely with the vendor-supplied ones. I wanted a newer version of the Perl LWP library than was in Fedora 10, so I grabbed the source RPM, updated it and built my own RPM package which I installed. Fedora then won't overwrite this unless they push out an even newer LWP release. Exactly the same can be done with dpkg-based systems.

        If your vendor is incompetent, or you are paranoid and don't trust them, or some mixture of the two, then there may still be political reasons not to alter the vendor packages and instead put duplicate copies in a different directory. But nowadays there aren't always technical reasons why you shouldn't.

        • by Tanktalus (794810)

          Yeah, until you update a package that breaks [vendor]'s supplied system administration tools, whether that be by accident (bug injection/exposure) or on purpose (bug fixed, but the tool relied on the broken behaviour). That seems like a fairly technical reason to me...

        • Re: (Score:3, Insightful)

          by Alrescha (50745)

          "On a modern Linux distribution, it's actually okay to modify stuff that the vendor sends you"

          Let me fix that for you. "On Linux, there's an attitude that it's ok to modify stuff the vendor sends you."

          Good luck with that.

          (I'm on a Mac, and I download ported-from-linux, OS X-installer packaged stuff from time to time, and more often than not it wants to install into /usr or /usr/bin with no option to go anywhere else (asterisk comes to mind). In my world, that means it doesn't get installed. Period. Yea,

    • by cayenne8 (626475)
      "It's exactly the same on Linux distributions: the CPAN shell doesn't try to mess with the system perl which is updated using rpm or dpkg."

      Or emerge......

      :)

  • by mi (197448) <slashdot-2012@virtual-estates.net> on Wednesday February 18, 2009 @11:28AM (#26902183) Homepage

    The Security Update brings (old) IO.bundle with version 1.22 but your IO.pm has been updated to the latest 1.23 on CPAN shell. (But hey, 1.23 was released in 2006...Why do you bring that ancient version back, Apple!?)'."

    The real question is (or ought to be), why is the 1-digit difference in the minor version number break things? If the 1.22 -> 1.23 change was important (as in interface-changing or something), shouldn't the new version have been named 1.3 or even 2.0?

    • by Anonymous Coward on Wednesday February 18, 2009 @11:41AM (#26902343)

      It's an XS module: They include components that are written in a language other than Perl, and have to be compiled against perl.

      Which means that if the perl binary they are pointing to changes, they break. The code itself is fine: You just need to recompile.

      Apple helpfully recompiled all the ones they shipped, so they would work. The only problem is for people who updated the modules that Apple shipped: They now have a miss-match between the Perl code that is running (that they updated) and the code that is compiled (that Apple shipped).

      Basically, you've got a library header and the library object. If the header and the object don't match exactly, you've got problems. No interface was changed, no major important pieces were changed, but now you've got 1.23 headers and a 1.22 object. Change one or the other, and everything will be fine again.

    • Re: (Score:2, Informative)

      by ekidder (121911)

      Well, 1.3 would be going backwards. 22 > 3 after all. Perl module versions can be a bit confusing. You'll find there are a lot of modules that break older versions.

    • by compro01 (777531)

      The issue is that 1.23 is from over two years ago.

      I believe the current version of CPAN shell is 1.93.

    • Re: (Score:3, Informative)

      by fl!ptop (902193)

      shouldn't the new version have been named 1.3 or even 2.0?

      from the IO.pm changelog: [perl.org]

      IO 1.23 -- Sat Mar 25 19:28:28 CST 2006

      • Adjust the regression tests to use t/test.pl when $ENV{PERL_CORE} is defined
      • Reduce number of calls to getpeername
      • Call qualify on format name passed to format_write. Bug reported by Johan Vromans
      • Reduce calls to getprotobyname/number. Patch from Gisle Aas
      • Remove references to file TEST used in core so appropriate tests are skipped during an install from CPAN
      • Add method say to IO::Handl
  • I'm not having this problem so I can't verify but does the inability to update IO.pm still apply if you do: "$cpan -i IO" or only if you do use "perl -MCPAN?"
  • by Jay Maynard (54798) on Wednesday February 18, 2009 @11:53AM (#26902509) Homepage

    CPAN is the closest thing to DLL hell on Unix systems. Modules are updated willy-nilly. No attempt is made to preserve compatibility between versions, or between modules and their dependencies. A company I used to work for had to totally abandon a large program because it was impossible to keep it working in the face of CPAN-driven upgrades, even if they did manage to get it installed the first time (by totally bypassing CPAN).

    • Re: (Score:3, Insightful)

      by Anonymous Coward

      This is certainly a comment by someone who doesn't understand a single piece of Perl, and how Perl developers work.

      CPAN *is* Perl, if you take it out, Perl has little more value than any other modern VHLL (python, ruby etc).

      The problem is that if you're going to develop a large system, you need both a development methodology and a maintainance methodology, if you don't plan those, "You deserve to lose".

      In a modern environment, like Debian, you manage all your CPAN dependencies as debian packages, hopefully

      • Perl as modern VHLL

        Let me think about tha

        HEAD ASPLODES

      • Re: (Score:3, Interesting)

        by mabinogi (74033)

        CPAN _was_ an excellent thing - in 1997.
        Now, the GP is exactly right - it's a mess.

        You absolutely need to install the latest perl before you use it - because the perl (or the modules installed with it) installed with your OS is always too old for any particular module you want to install, and even then you have a chance that the module you want is either broken, or depends on a currently broken module.

        CPAN is the heart of perl, but that doesn't mean it's perfect. It seriously needs fixing.

        • Re: (Score:3, Informative)

          by bcrowell (177657)

          You absolutely need to install the latest perl before you use it - because the perl (or the modules installed with it) installed with your OS is always too old for any particular module you want to install

          I've been using perl for about 8 years, and I've never encountered any such problem. For example, I stayed with perl 5.8 for quite a long time before switching to 5.10, and I never had any problem getting CPAN modules to compile.

          and even then you have a chance that the module you want is either broken,

    • by Anonymous Coward on Wednesday February 18, 2009 @12:08PM (#26902707)

      Huh? The opposite is true. CPAN, if anything, is more akin to a Linux distribution's package repository.

      Would you say the same thing about, say, Debian's apt-get and friends?

      Chances are you wouldn't, but that's exactly what CPAN's like. You have to use it correctly, though, and chances are that if you had trouble with it, you weren't.

      (In particular, you should not blindly install updates all the time when there's no need, without even so much as testing them on non-production systems first. Again, consider following the trunk of any Linux distro, package-wise - would you expect things that aren't part of the distro to never break when libraries etc. are updated and new versions installed? Of course not.)

    • by The Moof (859402)

      CPAN is the closest thing to DLL hell on Unix systems

      I don't know. Shared objects make a pretty good run for that title.

      • by stevied (169) *

        In the very old days, it seems like people were quite disciplined with shared objects: if a change didn't break backward compatibility, bump the minor version or revision number; if it did, bump the major number (the one that's treated as part of the library name, e.g. libncurses4 v. libncurses5)

        Then somehow not long after glibc 2.0, things seemed to get a lot more complicated (or maybe I just got very confused). Anyone who wants to explain what goes on now would be very welcome; in the meantime I'm stickin

    • Re: (Score:3, Interesting)

      by fl!ptop (902193)

      CPAN is the closest thing to DLL hell on Unix systems

      while i prefer centos for my production systems and don't use osx, i recommend implementing a solution i've found to work well. first, disable any rpmforge repos on your production machine. second, install new cpan stuff on your development server. test, then install on the production machine (if it passes the tests).

      if you need a cpan module that's not available from the regular repositories, or from rpmforge, *never* install anything from cpan using

  • by MrData (130916) on Wednesday February 18, 2009 @11:55AM (#26902533)
    In the flamebait but true category, this is further evidence why scripting languages are not suitable for most application development ... because they are much more brittle than a traditionally compiled application. True you can site examples of traditionally compiled applications breaking due to missing dependencies, in which (like with this Perl example) the underlying deployment platform is a fault, but this type of problem is much more common with scripting languages (Perl, PHP, Python, etc), and vastly harder to debug and defend against.
    • Hmmm... I do a lot of work in PHP and haven't had *too much* trouble with this. It has been fairly simple, actually. Where things get tricky is web server environments (not getting consistent variables in $_SERVER - SELF, etc.) and various configuration restraints that some hosts seem to think they need for security's sake. I've done work on a fairly significant script that runs on most version of PHP from 4.3 to 5.2 (a few exceptions of versions in there that are notoriously buggy).

    • It's common practice in the Perl community to keep the production tools separate from the OS distro's tools. Not only can the OS break your stuff, but if you're not careful you can break parts of the distro that depend on Perl.

      Mandriva for one has many system tools that depend on a certain version. Fedora doesn't have this problem so much with Perl, but only because it does with Python.

      Don't let your environments intermingle. You can even deploy an application written in Perl with its own copies of the modu

    • by dodobh (65811) on Wednesday February 18, 2009 @02:48PM (#26904865) Homepage

      No, this is a compiled language problem. The module is an XS module, and it has components written in C. The Perl update causes a mismatch between the library referenced by the user's compile and the system supplied one.

      Just another form of DLL hell.

      If this was a Pure Perl module, this issue would never have mattered. Scripting languages have the same problems as any compiled language when you break libraries.

      And if you are upgrading your base code in production without any form of testing, your code deserves to crash.

    • by shutdown -p now (807394) on Wednesday February 18, 2009 @03:30PM (#26905629) Journal

      this type of problem is much more common with scripting languages

      I don't see how this follows in any way. Can you give some examples of why it would be more common for scripting languages? In this case, the compat problem is not with a Perl script, as I understand it - it's with a binary Perl extension that got linked against the wrong version of Perl library; so, really, it is rather an example of how brittle compiled stuff is...

  • by geekmansworld (950281) on Wednesday February 18, 2009 @11:56AM (#26902543) Homepage

    As an XServe administrator, Apple's cryptic security updates are really starting to get on my nerves.

    You would expect that, since it is based on multiple open-source projects that are freely available, Apple would push compiled updates through Software Update to its OS X Server users. Instead, they wait so long to patch things (like Amavis or the BIND patch for Dan Kaminsky's DNS bug) that I just get frustrated and apply the patch myself. Then, when a Apple Software Update does come down the pipe, I have to consider if installing it will break my configuration and land me in hot water with my boss when he can't get his e-mail anymore.

    Apple needs to decide if they're going to regularly and consistently update the open-source software that their Server OS runs. If not, leave it alone and let the users apply and configure updates. This wishy-washy, middle-ground, Jobsy-come-lately approach is just an annoyance and an inconvenience.

    • Re: (Score:2, Interesting)

      by tbuddy23 (1178415)
      If you don't look at every file or at least the general path of what you are installing then you deserve it. Fink, SuspiciousPackage and the like all are very good for this.
      If you need excessive amounts of PERL modules why aren't you using a generic *NIX server rather than OS X Server? The only compelling reasons I could use for using OS X Server is 1) Provide excellent AFP file services 2) You really love Mac OS X and want the whole barrage of services in the form of one mediocre server. I think Windows
      • To be fair to Apple, it's considered good practice to not manage the modules provided by the distro with CPAN on Unix/Linux systems in general. Let the distro manage its own updates and manage updates of stuff you got from CPAN using CPAN.

    • by ducomputergeek (595742) on Wednesday February 18, 2009 @12:14PM (#26902789)

      I love Apple laptops and desktops. Hate Xserve and I've found OSX-Server to be nothing to write home about. When I was an Apple Certified consultant, I saw a much higher than average failure rate with Xserve hardware. It got to the point to where we'd only deploy OSX-server on PowerMac/MacPro machines. I know some people love their OSX-server tools admin package. It is a pretty slick GUI. I will give them that. But really, I can do just about anything OSX-Server can on a default OSX install. And for the price, I can build reliable servers with FreeBSD a lot cheaper with the same functionality, and arugably even more functionality than OSX-Server.

      • Good points and all, man, but um...

        -1: Offtopic
      • by guruevi (827432)

        I have the exact opposite results actually. I love XServe's since they're easy to work on (hardware) and have great interfaces for monitoring and management. If you've ever used Dell's interface then you'll know what CAN be wrong about it. The only ones that come close are HP and IBM only IF you buy they're (quite expensive) management packages. Next to that, the pricing on similar 1U servers from HP, Dell and IBM is far higher than Apple's XServe unless you're assembling yourself (and having worked on Supe

    • Re: (Score:2, Insightful)

      by geekmansworld (950281)

      I use OS X server because I am a Mac-booster and because my associates and I are familiar with *nix conventions and the open-source services that generally run on them. I'd much rather deal with this than run a Windows Server platform.

      And for the love of the Gods, don't try to sell me on fink and darwinports. Some people seem to think that dports putting everything it installs in a separate directory is a good thing. It's just confusing and messy.

      I've tried fink and dports several times and they've never wo

      • by fuzzyfuzzyfungus (1223518) on Wednesday February 18, 2009 @12:44PM (#26903189) Journal
        The question isn't Apple vs. Microsoft, it is Apple vs. other Unixlikes. Why run OSX server rather than Solaris, one of the BSDs, or linux?
      • I've had mixed experiences with both of these. Ultimately gave up on fink. I had problems with ports too but I think I figured out that you just need to treat it like apt-get and only install using the ports command. If you try to install anything separately or configure things yourself outside of ports you may run into problems. I don't know enough about UNIX to understand why this caused problems but when I did things like install w3m (which at the time I couldn't get via ports) it broke some other st

    • by MisterSquid (231834) on Wednesday February 18, 2009 @01:06PM (#26903511)

      Apple seems to have a separation between its left-brain UNIX underpinnings and its right-brain Quartz GUI.

      For example, with the last several Security Updates, which contain very little information about what all's rolled in, Apple modifies /etc/postfix/main.cf

      inet_interfaces = all

      to

      inet_interfaces = localhost.

      This effectively breaks all Internet-accessible postfix installs. Now, the question is why does Apple apply this to postfix installations explicitly enabled as Internet-accessible? I can't think of any good answer for this except as part of some other bass-ackwards security measures Apple applies in a schizophrenic attitude to the server functions of its UNIX-based client OS.

      For another example, the Aiport Extreme Base Station prior to firmware 7.3.1 had a version of DMZ host (default host in Apple bizarro-world) that worked flawlessly. In April 2007 or thereabouts, Apple rolls out firmware 7.3.1, since which default host is broken for only for BIND (UDP port 53) and all mail ports (587, 110. 995, etc) but works for WoW, BitTorrent, and all other ports. WTF?! If I set my router to designate one computer as the default/universal host, why is it still blocking certain ports that have to be opened using port mapping?

      This split-mind on UNIX vs. GUI seems to pervade Apple's mentality everywhere which is especially problematic to people like me that are not full-time developers but make extensive use of UNIX-layer services.

      Really stupid stuff, Apple. I wish you'd cut it out.

  • 1990s ... Apple stops using 5 1/4" floppies in favor of 3 1/2" disks ... Apple standardizes on Firewire/USB, obsoletes parallel and RS-232 ports ... Apple stops using floppy disk drives all together
    2000s ... Apple introduces LCD iMac, no longer sells CRTs ... Apple locks the battery in the MacBook Air - replacable batteries obsolete! (ugh) ... Apple breaks Perl in OS X, the world moves away from write-only languages

    *ducks*

    -Chris

    • Re: (Score:3, Informative)

      Not to pick nits too much here, but

      1) Apple stopped using 5.25" FDDs well before the 1990s. Every Mac that came with a floppy drive from their inception in 1984 came with a 3.5" FDD.

      2) You can always buy a third-party CRT if you want a CRT on your Mac, iMac excepted (obviously). Aside from that, having used expensive color-calibrated displays and printers and so forth with high-end color management, etc., I'll let you all in on a big secret: There's no such thing as true color matching. The laws of ph

      • by ericrost (1049312)

        As to #4 its possible but not necessary where python lends itself to being readable by default. /ducks

  • by Kostya (1146) on Wednesday February 18, 2009 @12:34PM (#26903041) Homepage Journal

    The update reverted Scalar::Util, which disabled the weak reference stuff needed by a lot of Catalyst libs. I just re-installed it and it worked again.

    But on all my new machines, I just use a local lib instead of the system stuff. I don't need sudo access and then the whole lib gets backed up by Time Machine. If you just upgrade the system perl, you have to re-do it every time you restore from a Time Machine backup (it doesn't copy system stuff as near as I can tell).

    Also, as some have observed, CPAN is a bad idea. I say this as someone who got screwed when Catalyst went to 5.7100 (I was at 5.7015). When I did a restore to a new machine, CPAN got all the new Catalyst libs and all my customizations blew up spectacularly.

    If you are doing serious Perl development on your local Mac, use a local lib and do not rely on CPAN to automatically handle your dependencies. Install things by hand or create a (perl) script to handle the deps for you. That's what we had to do, as we needed to make sure the module version we used matched our production systems--where we do NOT use CPAN and where we upgrade manually and with careful thought.

  • I guess it's time for me to learn python.

  • by Trillan (597339) on Wednesday February 18, 2009 @12:53PM (#26903317) Homepage Journal

    It's easy enough to install an up-to-date Perl in another location and use it instead of updating the Apple-placed Perl files and relying on them never changing.

    Disk space is cheap. If it might change, don't rely on it not changing.

  • by Budenny (888916) on Wednesday February 18, 2009 @04:02PM (#26906183)

    "Why do you bring that ancient version back, Apple!?"

    You fail to grasp the essence of the situation. It is not your copy of OSX, it belongs to Apple. You did not buy it. You merely paid some money, and got a license to use it. Well, the same thing is true of the hardware - has to be in fact, because of course OSX and its hardware are seamlessly connected and integrated.

    So, what went wrong was that you did not get your copy of Perl from the app store. Your copy of Perl was not approved for use with the new version of OSX. This is your fault, not Apple's. You should have checked and got permission before you installed it. It is not like you were installing it on your own property, after all. If you go and plant a cabbage in someone else's garden without permission, don't be surprised if they spray it with weedkiller.

    Its exactly the same thing. Its completely weird how many people think they somehow bought a copy of the software, or bought a computer, and now they for some reason think they have the right to install whatever they want on it, and Apple has to somehow protect whatever silly thing they did to it.

    Idiots! Next thing, they will be wanting to buy retail copies of OSX and install them on hardware made by any Tom Dick or Harry.

  • by Killer Eye (3711) on Wednesday February 18, 2009 @04:18PM (#26906399)

    This problem occurred only for people who updated their system's Perl distro via CPAN.

    A vendor is free to do what it wants in the part of the system it supports. This isn't new, it's been done for decades on Unix with the distinction between the /usr/local hierarchy (a.k.a. "your crap, not ours") and the rest of /usr (i.e. "our crap, not yours").

    People need to know that it's better to install customizations in /usr/local/lib/perl5, or even their home directory, than to fiddle with the vendor setup. This not only avoids vendor clobbering, but the separation is cleaner: mistakes are easier to contain and undo, you can easily test whether a problem is with your customizations or the vendor defaults, you don't necessarily need admin privileges, etc.

A committee is a group that keeps the minutes and loses hours. -- Milton Berle

Working...