Well I'll certainly be losing sleep over this! Distro perl programmer gibberish woohaa
Apple's latest Mac OS X security update has a knack for breaking Perl, according to Mac users across the web. "I've just done the update using Software update and just about everything I look at is working, except that perl seems to have gone almost AWOL," says one Mac OS X user, with a post to Apple's support forum. "I seen …
How much do you guys understand your' systems.?
@Meh no biggie - Perl is not that much older than Python, they are both probably going to be using the Parrot interpreter in the next versions. Don't think that Perl is dead, it's alive and well in most large organisations.
@Nerds - Would you care if the Apple update broke other parts of the OS that aren't originally created by apple? SSH, SSL etc? Probably not. That's because you aren't aware that these subsystems are used without you knowing it. If one of these breaks, your nice, pretty GUI with the funky animations may just stop working with not much indication of why. Perl is HUGELY important and is depended on by many 3rd party scripts and programs.
By the way, I'm not really a big fan of Perl, prefer Python, but I feel it's necessary to point out why this is a big deal.
It's always tricky to update software provided by the OS distro, and used by it.
Just look at the number of Java runtimes on any server box with a couple of databases and a few applications.
If you want to play with Perl (or Python) install another copy and leave the system copy alone.
Even if you don't break it through version incompatibilities, you might fix a a bug that the systme depends on.
This applies to any OS, not just Macs. (I exclude the hair-shirt brigade that think that BSD 4.3 was an unnecessary embellishment on an already perfect world.)
iirc, FreeBSD removed perl from the base system, to use the Perl 5.8 from ports partly because of the huge amount of grief that would be caused by a partially-successful upgrade of perl. Until FreeBSD removed perl from the base system, it was probably the only system that managed to keep from breaking perl on updates. Then again, FreeBSD has always been sysadmin-friendly (as opposed to user-friendly).
How come there's no beastie icon alongside that penguin? Speciecism!
... of the end for folks using Macs as a UNIX-like OS instead of as a Mac.
Don't get me wrong, I like OSX as a consumer OS ... but as a ~30 year UNIX[tm] hacker, OSX just doesn't cut the mustard. It's close, but because of the "ease of use" myth that is so important to Apple, I don't see it as a major player in the Un*x-wars any time soon.
Before the fanbois "correct" me, I know about the numbers on the desktop. Those Macs are NOT being used as Un*x machines. They are being used as Macs. And there is nothing wrong with that.
What is going on within the great apple are they engrossed in the next OS, not to notice this issue. obviously they regressed a file for some reason....Any Answers Apple............windy isnt it. Well i guess they are looking into it before they can tell us unworthy people.
They hate programmers; they know that any programmer could replicate Time Machine in 6 lines of Perl; they know that any entusiastic amateur programmer could replace most of iLife with a few good Hypercard stacks. Imagine if people actually could use their computers as computers! They might actually learn something useful and not have to keep running back to Apple for everything.
Jobs thinks your computer should be like a toaster and you don't program your toaster do you?
Which makes me wonder why Macs are so over-priced if the intent is for them to be Crippled Computers for Dummies(TM). If you want a toaster, buy a bleeding toaster.
I learned long ago to never depend on Perl bundled with the system - particularly with Solaris.
First thing I always do with a new SUN box is go grab the latest Perl from sunfreeware.com, which installs safely out of the way under /usr/local. Leave the system environments pointing at the bundled version and configure all user environments to point to the local copy.
This not only protects you from OS upgrade pain, but because there are countless system perl scripts lurking within Solaris, a b0rked CPAN upgrade or installation of wierd module versions on the local perl won't bring down half the system with it.
Look, venders provide pre-compiled binaries like perl and ruby using native packaging systems like apt, rpm and in the case of OS X software update bundles. You are not supposed to update those versions unless you know what you are doing. This has always been the case. Using CPAN with the vendor's binaries updates libraries without updating the databases the packaging systems use to track such updates. This is CPAN/User error, and happens just as readily on Redhat as it does on OS X. The solution is to install your own local version of perl at /usr/local and use CPAN with that version. The fact that CPAN makes it easy to update libraries that can easily be trampled by vendor updates is the real issue, it should give some sort of warning to inexperienced users.
"only occurs if you're running Leopard (Mac OS X 10.5), you're using the Perl distro baked into the OS, and you've updated the distro via CPAN"
So people who manually fiddle with the versions of Perl modules installed and maintained by the OS are surprised when updates break Perl. Colour me surprised. This has always been a problem with Perl and its atrocious package management system.
So downloading a tar file and runing make is considered to be a procedure which requires finesse? So what do they call the mysterious voodoo required to make CPAN work properly?
And it isn't so much that you can't trust software from your OS vendor, but you just don't want updates to affect code which you depend on. And you /can/ trust an OS vendor to update things from time to time, whether you want them to or not.
Basically, people go modify system internals, run an update that expects things to be in their original state, and then complain that it doesn't work right. Reminds me of the last time an Apple update broke things, where the actual cause turned out to be Unsanity's haxies.
This is why we have /usr and /usr/local, or /System and /Library. You can tinker with the latter if you know what you're doing. But don't meddle with the former unless you absolutely know what you're doing and can fix the system when you screw it up.
Biting the hand that feeds IT © 1998–2019