Slashdot Mirror
Apple's Mac OS X Update Breaks Perl
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!?)'."
"It just works"
Is this even English?
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.
-- Ed Avis ed@membled.com
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?
In Soviet Washington the swamp drains you.
My wife's Mac just recently broke her only game (Sims 2) because of an Apple update. She updated Quicktime (we think) and that completely broke Aspyr's version of the Sims 2. http://support.aspyr.com/ "We are aware of the issues arising with the latest QuickTime update in 10.4.11 and are working with Apple to get it resolved. Please bear with us as we work with Apple to find the source of and fix for this problem." Yeah, nice work there Apple. What's next?
CAPS LOCK: ITS LIKE THE CRUISE CONTROL FOR AWESOME
Umm, what about Fink?
http://www.finkproject.org/
I believe they believe Perl is dead...do they?
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?"
Real men regex in VIM!
Or MacPorts, formerly DarwinPorts: http://macports.org/
Wes
All part of Apple's plan to ensure that no one can ever use a Mac for gaming.
SJW: Someone who has run out of real oppression, and has to fake it.
Right. Let's see... Quicktime still works but the Sims 2 doesn't. Quicktime doesn't seem to break anything else, so logically, it MUST be Apple's fault. I think the rest of the Quicktime users who aren't playing the Sims 2 would disagree with your placement of blame. :)
It's the Stay-Puft Marshmallow Man.
What I meant was that there are no Apple-supplied package managers. Fink is a good add-on, but for some folks it's just got too much stuff in it. There's a good discussion here . While we're on that subject, there's also MacPorts.
Doh.
Well, what changed? Quicktime or Sims 2?
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).
Disinfect the GNU General Public Virus!
Right. Let's see... Quicktime still works but the Sims 2 doesn't. Quicktime doesn't seem to break anything else, so logically, it MUST be Apple's fault. I think the rest of the Quicktime users who aren't playing the Sims 2 would disagree with your placement of blame. :)
Brainwashed much? You're basically implying that if I hit you in the head with a hammer and you're knocked out, but the hammer, nearby mailbox, and tree are unharmed, that proves that the hammer isn't to blame - your head is.
"I zero-index my hamsters" - Willtor (147206)
It's 1996 over again..
Remmember when a game made Win95 BSOD? It was the game that made the computer crash.
Remmember when a game made MacOS 7 bomb? It was the Mac that made the computer crash. Why? Because it's a frigggin' Mac!
The Sims 2 smeans to be quite borked. You can't move the App once it's installed or it will break it.
Menzoberranzan Networks
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.
Disinfect the GNU General Public Virus!
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.
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.
my thought exactly: wtf is sims doing with quicktime?
I'm of two opinions here:
1) I agree with Stewie241. The Sims 2 was not updated, the Quicktime update broke something that was previous working.
2) That said, Aspyr sucks. They have many problems that we have never been able to resolve. Sims has a problem where the graphics kinda freak out and only shows the wire frames. Aspyr blames this on the differences in Apple drivers (ATI/Nvidia). And the expansion packs have frequently been the cause of teeth knashing (yeah I'm looking at you Bon Voyage.)
So Apple or Aspyr? I blame both. Apple isn't as great as it once was, and Aspyr just sucks.
CAPS LOCK: ITS LIKE THE CRUISE CONTROL FOR AWESOME
I would guess and say that it plays a video as you start the game. The intro screen shows something that looks like the name "Aspyr" in a flame and it says, "Aspyr." Then the intro plays that shows the Sims doing different actions (related to expansion packs.)
My guess is that they are all part of a Quicktime video.
CAPS LOCK: ITS LIKE THE CRUISE CONTROL FOR AWESOME
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.
Change is certain; progress is not obligatory.
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).
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 ... 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
2000s
*ducks*
-Chris
Did you ever consider that Sims 2 may not have implemented Quicktime to Apples standard? Since nothing else appears to have broken, then it is also possible that Sims 2 has a poor or improperly coded implementation. As a designer, I'v done this myself a few times by not following the documentation.
Same here. I don't understand why I need the X11 sources compiled from fink just to get apache 2 and php.
Developers: We can use your help.
Fink and MacPorts both have the same problems:
1) It's impossible to successfully compile anything complex with 64-bit compiler flags (i.e.: -arch x86_64 -m64) since all libraries will be built without said flags... So you have to manually figure out all the dependencies yourself or backtrack the 32-bit install piecemeal.
2) X11 is/was often broken and needed XFree86 compiled instead of Apple's X11. This might have been dealt with in all cases now.
3) They are hopelessly behind every major O/S release. It took forever to have a 10.5 compatible fink and/or macport that was officially released.
All in all, I had to build a 64-bit application chain for 10.5/Intel and it took me two days to get ~30 packages compiled and linked successfully and fink/macport couldn't be used. I often had to reverse engineer fink mac patches for the packages that it did have, it's silly that I couldn't use fink to build them in 64-bit!
The rationale for a 64-bit build was a 40% performance improvement.
"It looks like if you use CPAN to install modules, Apple's latest security update might just have broken your Perl"
...
Doesn't matter, no one in his right mind updates a live system. Especially with some third-party update package, never nada
SMAC/X is still working ok. 'Course, I had to track down a past developer of the Mac version to get a carbon version of the game engine to get it to work on an Intel Mac but no crashes in the last couple years. And it's on 24/7 on my home machine.
I drank what? -- Socrates
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.
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.
"Doubt your doubts and believe your beliefs." -- Switchfoot, Ode to Chin
I guess it's time for me to learn python.
Alex, I'll take keybindings not used by Emacs for $400....
Perl was already broken by design. Ba doom, crash. I'll be here all week ladies and gentleman.
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 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.
Disinfect the GNU General Public Virus!
The Sims 2 was not updated, the Quicktime update broke something that was previous working.
That, or Sims 2 was using an "Undocumented Feature".
Does it make you happy you're so strange?
[...] that proves that the hammer isn't to blame - your head is.
Well, actually that's not too far from the truth...
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.
For the last time, PIN Number and ATM Machine are redundancies!
That's because the hammer didn't hit your head; your head hit the hammer!
"If a nation expects to be ignorant and free in a state of civilization, it expects what never was and never will be."
If you're going to the length of building from source yourself, you might also want to try pkgsrc.org, depending on your needs.
Good points and all, man, but um...
-1: Offtopic
CAn'T CompreHend SARcaSm?
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.
Quicktime is used on the Mac for much more than just showing a video - converting sound and image files from any format to any format (the reason my program can play AIFF, wav, MP3, AAC, etc is because Quicktime converts it to a stardard format for me). Therefore if the game is multiplatform like the Sims and all the sound effects are .wav files, Quicktime will probably be used as the standard API to convert them for playback.
CAn'T CompreHend SARcaSm?
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
to
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.
blog
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 modules it needs in its own directory quite easily. That means if one project needs a newer version of something, you don't even need to update other projects using older versions. You can share easily enough, but you can keep them separate too.
Yes, any OS vendor might have such problems. Why Apple is treated specially here is because:
1. The fanbois jump up and down all the time crying out "Apple is teh best" and "it just works" so loud they they shit in their pants.
2. The same fanbois will murder Microsoft if this happened to them.
Why did the updater/installer even allow a file to be overwritten with a previous version? Does it not skip files if the one already present is newer?
Is this taking place in Soviet Russia?
"Quote me as saying I was mis-quoted." -Groucho Marx
The rationale for a 64-bit build was a 40% performance improvement.
Wow, what software was that? Most of the time, I find that 32-bit software benchmarks a bit faster than the same software compiled for 64-bit on the same machine.
Only if I'm using memory-intensive applications and have gobs of RAM in the machine have I found this to be different. Even then, I've never seen anything get near to a 40% performance boost.
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.
I can throw myself at the ground, and miss.
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 stuff. My sense is that if you *really* know what you're doing you should just avoid both of these and compile everything yourself from source but if you're like me and do most of your work in os x anyway, using dports is fine as long as you stick with the tools provided. But any unholy combination of one of these and your own installations is bound to cause trouble.
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?)
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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...
No, remember when Windows 98 DirectX updates broke certain games (the list is too long to mention), and it was the GAME's fault not Windows?
Who was brainwashed again? Never let that get in the way of a silly argument, though...
It's the Stay-Puft Marshmallow Man.
The no X11 variant isn't there because GP is wrong about apache2 wanting X11:
apache2 @2.2.10 (www)
Variants: darwin, darwin_7, darwin_9, eventmpm, no_startupitem, openbsd,
openldap, preforkmpm, universal, workermpm
Library Dependencies: apr, apr-util, expat, openssl, pcre
(and none of those are X11 either).
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.
I don't know. Have you seen DLL hell on Windows?
There, if a DLL with the same *basename* as your DLL is already loaded into memory (not loaded by YOU, mind you - but by anyone) it will give you that one when you say "Load my DLL".
On the other hand, if the other DLL happens not to be loaded into memory at the time, it will load yours fine when you say "Load my DLL". But the other app, trying to load its version of the DLL after you will now get yours. This is true no matter in which directory which DLL is.
Essentially what Windows does:
DLL_images = {} # system global
def load_DLL(environment, DLL_path):
global DLL_images
DLL_basename = os.path.basename(DLL_path)
if DLL_basename in DLL_images: # hellooooo
return DLL_images[DLL_basename]
if DLL_path is absolute:
DLL_actual_path = DLL_path
else:
DLL_actual_path = search(environment["PATH"], DLL_basename)
content = PE.load(DLL_actual_path)
DLL_images[DLL_basename] = content
return content
Dunno if that's fixed nowadays. But this was SO stupid it hurt.
The problem isn't inherent to scripting languages. Lots of systems have inherent failings that are not present in other systems. It's hard to find a more excellent simple system than that which is used for dynamic libraries on Unix systems, where you can have multiple versions of a library peacefully coexisting and even upgrade-in-place with few to no consequences. By comparison, "DLL hell" is a staple of the geek lexicon. (I am aware that Windows offers alternate technologies which mitigate these problems to varying degrees. None of them are as simple as loading a DLL, though they may be easier for the programmer.)
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I remember when games on the Amiga would use shortcuts and tricks in the architecture to squeeze out performance, but if you updated your Workbench and/or Kickstart, Commodore acknowledged some stuff would break. Them's the breaks. :)
:)
Perhaps Aspyr was using a deprecated function call that changed, was warned it would change (or Apple's more like Microsoft and just doesn't tell anyone), and forgot (or just plain didn't) fix it before the inevitable breakage would occur? If Apple changed something out from under the API and didn't tell anyone (I find that hard to believe), then yes, Apple's to blame and the Quicktime engineers should be forced to watch Steel Magnolias as a punishment. Otherwise, let's be sure we aren't flailing the blamestick all over the place because of something someone "assumes" is the cause of the Sims 2 breaking.
But never let that stop a non-Sequitur!
It's the Stay-Puft Marshmallow Man.
Is it possible to just uninstall the update, or the full Quicktime and install the older version? I seem to recall that there are certain things within OS X, like Windows, which can not be "uninstalled": once it's in, it's in for keeps. RealPlayer, Adobe Reader, and Quicktime on Windows all do this, as does any non-Office/"free" MS add-on product.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
>because they are much more brittle than a traditionally compiled application.
I'm sorry, but I found the opposite to be the case. Once a function symbol in a shared object vanishes, the traditionally compiled application will not even start up, let alone be able to do something about it (like using an emulation of the now missing function, or running without it with reduced functionality).
And that's just for the function symbol itself. I don't even want to think about what happens when a C++ class changes or a function parameter list.
I know that there are hybrid approaches like dlopen, but I meant it in black and white terms :-).
>but this type of problem is much more common with scripting languages (Perl, PHP, Python, etc), and vastly harder to debug and defend against.
I'm not sure why scripting languages keep changing their C interface either. But I think it's more of an attitude problem than a technical problem ("nobody but us is using the C interface anyway, so let's change it to improve it").
That said, in this specific case, it was the user updating a file he wasn't supposed to update (one under package management; probably updated half of PERL).
I'm not going to disagree with your initial premise, but: isn't this specific problem being caused by a binary blob module, where the perl module was compiled against a different perl binary? It's a packaging and version control issue, not a scripting language/perl problem. Though CPAN could, arguably, be partially to blame for this snafu, from the sound of it.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
Well if you keep separate vendor and site Perl directories then this is an easily amended situation. What is described in the article is one or a few broken Perl modules, with that said, Perl itself is NOT broken.
On the Linux systems I manage, there is a separate 'site' and 'vendor' directory. If a vendor supplied Perl module breaks something I delete or rename the offending module in the vendor directory. Likewise, if a CPAN module breaks something then I can delete or rename the offending module in the site directory.
If you have 'use warnings' and 'use strict' in your Perl applications you should get an error or warning complete with module name, and line number when this sort of thing happens. It sounds to me that Apple might be at fault for rolling back to a previous version of a module. However, whoever initially configured CPAN could have created a separate site directory and avoided this whole mess. So in the big picture, it is not Apple's fault so much as it is the Administrator.
/^([Ss]ame [Bb]at (time, |channel.)){2}$/
"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.
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.
"Microsoft killed my company, I hold a personal grudge. I don't use Microsoft products and neither should you."-JWZ
Isn't Perl broken anyway?
That's funny... since 2000, MS has had two releases you'd have to pay to upgrade to... How many has Apple had? more than two... As for being constrained to the release cycle most new software runs in XP still... how much new Mac software runs in less than 10.3? not much.
I actually like OSX, it has a consistent UI on a Unix core. But your arguments only show your ignorance. For the record I like different aspects of a lot of OSes. There are even parts of Vista I like (mainly the restructuring of the user paths... though would rather have an "ALL" user back, opposed to the new location for global settings. I like that Linux has a FLOSS mindset, even if the zealots can't find a balance with commercial software.
I don' like a lot of the more politically minded decisions MS and others have taken. I find it ironic that Linux fanbois will use Samba, but ignore Mono because of patent concerns. Zealots from every corner are wrong, and spread FUD, it's what they do... the truth is generally somewhere in the middle.
-- happy Windows, Linux, BSD & Mac User
Michael J. Ryan - tracker1.info
but this type of problem is much more common with scripting languages (Perl, PHP, Python, etc), and vastly harder to debug and defend against.
Any source for that? because logic says problems arising from upgrading only part of the underlying platform would be much more common with compiled languages, and judging from both DLL and dependency hell, that seems to be the case.
No problem is insoluble in all conceivable circumstances.
How the fuck does this get modded up? You can't even fucking define a 'scripting' language you ignorant fuck. Should I start bringing up C interpreters?
More to the point, the term "DLL hell" was caused ENTIRELY BY compiled C applications. This was the ORIGINAL example of this sort of dependency problems.
How the fuck is an application missing a dependency "more brittle" depending on the language its written in? If I compiled the Perl to C, would that suddenly make it less brittle? If your C application is missing dependencies, does it magically track them down and then install them?
As for "debug and defend", an error message that says "Exiting because I can't find this dependency" is pretty fucking clear no matter the language.
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.
Only because too many scripting language implementations are done by people who don't actually care about compatibility or the difficulty of deployment. Of course, it's dangerous to generalize from "all the ones I know" to "all"; some of us actually give a shit about such important stuff.
In my experience, it tends to be best to use a language like C, C++, Java or C# to write components, and to use a scripting language to stick those components together. (Yes, of course the components should be tested thoroughly.) Sticking independently-developed components using just a low-level language tends to be hard, dull, and error-prone work due to all the type-conversion gunk that you need. Using a higher-level language to hide most of the crap makes programmers more effective since it lets the real program be closer to the pseudo-code that people really work with in their heads.
Alas, it's when the people working on doing the code that connects different languages get it wrong that this whole sweet process is made much more painful. Perl isn't stellar in this regard; you can do better for yourself.
"Little does he know, but there is no 'I' in 'Idiot'!"
Right. Let's see... Quicktime still works but the Sims 2 doesn't. Quicktime doesn't seem to break anything else, so logically, it MUST be Apple's fault. I think the rest of the Quicktime users who aren't playing the Sims 2 would disagree with your placement of blame. :)
Brainwashed much? You're basically implying that if I hit you in the head with a hammer and you're knocked out, but the hammer, nearby mailbox, and tree are unharmed, that proves that the hammer isn't to blame - your head is.
If there are a dozen other people in the room at the time, and only I get hit, then yeah, my head probably is at fault. Either it didn't get me out of the way fast enough, or it said something that pissed you off.
Seriously, QT is a fundamental API on OS X. If your app breaks when it changes, and your app is the only one that breaks when it changes, then your app is the one with the problem. QED.
if Perl is broken? Seriously.
prometeus:~ brian$ port variants apache2 apache2 has the variants: darwin: Platform variant, do not select manually darwin_7: Platform variant, do not select manually darwin_9: Platform variant, do not select manually openbsd: Platform variant, do not select manually openldap preforkmpm workermpm eventmpm no_startupitem universal: Build for multiple architectures
People who start their messages "Umm" should be dragged out in the street and shot in the head repeatedly for being huge douchebags.
You pretty much have to install XQuartz to get X11 programs working nowadays. Even applications not installed via Fink or MacPorts like Gimp needs it. But it sure beats having to compile it yourself.
Ignorance, insane optimism or some single special case application?
Based upon the amount of "bail-out" spending... yes, yes it is.
I installed my own after this. I don't have to rely on the Apple version if I don't want to and Apple has given me a reason to do so.
1. The fanbois jump up and down all the time crying out "Apple is teh best" and "it just works" so loud they they shit in their pants.
And Apple foes jump up and down whenever something doesn't "just work". What I noted in reading tfa and bog post is that the software update only breaks the perl that's build into Macs, but if someone builds and installs their owe Perl won't be broken.
2. The same fanbois will murder Microsoft if this happened to them.
Does Microsoft even ship Windows with Perl installed?
Falcon
Should there be a Law?
I'm surprised, I would have thought either OpenAL or CoreAudio would be used to play them.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
Not when the breakage is due to Apple unilaterally deciding to remove some existing feature. Recently they e.g. decided to remove existing support for palettized graphics, which broke a bunch of old programs. Blizzard updated their old games so they started working again, but not many vendors will do that.
Er, the whole point of each of those package-managers dragging in a whole stack of stuff is to avoid the whole "one manager/upgrader stomped another's files" problem that got this whole thread started. Fink and MacPorts each have their own (for example) libxml2 so that neither one's nor apple's feature-enable/disable, interface-compatibility, or other changes affects anything except its own packages, which presumably know how their own lib is built. If CPAN had behaved the same way, we wouldn't be here, because apple would know exactly how its versions of things were and its upgrades would be self-consistent, and user-installed versions *somewhere else* would not be touched and would remain self-consistent with themselves. That's really the only solution that's easy to make work well (or at all) as a few-parentlevels-up notes, and that's precisely what you criticize Fink/MacPorts for doing. If you build from source yourself, you're using apple's versions of libs, which is fine as long as you trust apple not to change things like this. If you do so and keep your files in /usr/local like you're supposed to, at worst, you'll have to recompile when an OS lib changes. The problem here is when users *didn't* restrict locally-installed things to /usr/local, which is just silly.
PHP has had its share of gotchas.
Just in the core, you've had the following changes:
4.1 to 4.2: register_globals default was changed from on to off.
4.x to 5.0: $HTTP_GET_VARS and $HTTP_POST_VARS are now disabled by default. Note that 4.0 didn't even have their replacements ($_GET and $_POST); they were introduced in 4.1.
5.x to 6.0 (coming soon): Safe mode is going to be removed entirely. magic_quotes_gpc is going to be removed entirely. Both of the settings mentioned in the previous lines are going to go (they were just disabled by default before).
That's completely ignoring things like the XSLT libraries being switched around... to my knowledge the 4.x library doesn't work on 5.x and vice versa.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
That doesn't really matter as much as how Sims 2 is using Quicktime. If they are sticking to the published API and an update broke the game, then, yeah, Apple screwed up. But if they are using an undocumented macro, function, or method, then Apple isn't at fault.
FWIW, I have a few apps written against QTKit that have worked unmodified for some time now. So at least some of the API is stable. Who knows what arcane corners Aspyr is delving into, though?
Arr! The laws of physics be a harsh mistress!
Randal Schwartz uses a Mac book. He'll get a fix, work around or something soon to scratch his personal itch.
There's more to it than this.
Or for macports put something like this in /opt/local/etc/macports/variants.conf
+no_x11
-x11
And it's also easy enough to create your own local port repository and alter the Portfile to your satisfaction.
if you take what Apple gives you and don't customize it too much. Installing your own modules? Not the Apple way.
Like other's you have it backwards. Apple's update only affects Apple's implementation of Perl. If you built your own Perl implementation it wasn't affected.
Go to Linux for that kind of thing. Who would use OS X for serious Perl work anyway?
I plan to use OS X, and Linux, for Perl. Can you tell me why Perl does not work well with OS X?
Falcon
Should there be a Law?
Don't blame the package manager because you don't know how to configure options on the package. ;)
Wes
So how easy is it to install MySQL 5+ and PHP 5+?
If you have OS X server MySQL is already installed. And in Leopard PHP is as well. Substituting "OS X" for "L" OS X has everything to run LAMP.
Falcon
Should there be a Law?
After crashing gpgmail on leopard while applying updates a few weeks ago I tend to wait and see if there's any trouble doing upgrade and I'ven't applied recent updates yet.
Not installaling sec-updates might crash my computer, Installing sec updates will crash my computer (I won't be able to work with perl (at least) and some other programs using perl as well (perhaps)
Thus I prefer risky in favor of trashy ;)
Is it possible to just uninstall the update, or the full Quicktime and install the older version?
Yes: delete the installer package receipt from the Library folder and run the older installer. Alternatively, tools like Pacifist can be used to install the Quicktime components from any Quicktime, OS or combined update installer package.
I seem to recall that there are certain things within OS X, like Windows, which can not be "uninstalled": once it's in, it's in for keeps.
Significant parts of OS X and many applications rely on the Quicktime shared libraries, so if you did remove Quicktime in its entirety a lot would break, assuming it would even boot to the desktop in the first place. For this reason you can't simply uninstall the update. But delete the Quicktime Player application and it stays deleted (until the next update, anyway).
As for other software, I've never seen anything mysteriously reinstall itself the way things do on Windows. For the most part, when you delete the application package you delete everything except preferences (which is the whole point of the app. package concept), and those vendors that do use installers usually provide uninstaller scripts or instructions on manual removal of components. The exception is where vendors use anti-piracy measures (like iLok or whatever Adobe uses to scan your LAN) but they can still be deleted manually if you know where to look.
To be honest, I think any company that tried the "you can't uninstall me ever" trick with OS X would end up with so much bad publicity that they'd be forced to drop the scheme or leave the Mac market. Sometimes a whiny user base has its advantages...
Blank until
if you are going to mess with Apple's Perl, you can't do much because it will break at some point with an update. This applies to many of the *nix-y parts of OS X. Your config files get overwritten by Software Update. The extensions you configured and compiled yourself because they weren't there get disabled because all of a sudden, Apple decides to include it
I think you miss my point. You say if you do something yourself eventually an Apple update will overwrite what you did. But in this case it was Apple's own implementation that was broken. If you had built and installed Perl yourself it was not broken by the update.
I have to say Linux is better. In most distros, you get a more flexible, up-to-date distribution that is less likely to break if you play around with it too much.
I don't know how the Linux distros work, but I may find out soon. I plan on installing Ubuntu on my Mac RSN and if I do I want to setup both Leopard and Ubuntu as development platforms.
Falcon
Should there be a Law?
Same here. I don't understand why I need the X11 sources compiled from fink just to get apache 2 and php.
I don't know about Apache but PHP comes with Leopard.
Falcon
Should there be a Law?
So true. I will never use a Mac OS until they have directX, and just about anybody can guarantee that will never happen.
This is a fairly unique problem from what I can tell. I ran several perl commands on my MacBookPro running 10.5.6 and here are the results:
perl -MIO::Socket::SSL -e 'print $IO::Socket::SSL::VERSION;'
0.999
perl -MIO::Socket -le 'print $IO::Socket::INET::VERSION'
1.29
I appears that this problem unique to UTF8, adding or modifying CPAN and the Security 2009-001 update. I think that this is perl module problem that is causing this issue and they need to fix at that level.
Again perl is not broken unless you have done certain things on the Mac.
CPAN doesn't need Apple's help to break. Every third time I install a package it breaks my whole install. Then occasionally, when I try and fail to install a package manually, it fixes everything automagically and becomes self aware. Over night, while tapping into an alternate power source (like on Superman 3) it manages to screw itself up again with an upgrade Bundle::CPAN.
Wow, that information would have been incredibly useful to me before I gave up MacPorts. Too bad the documentation is abysmal.
I generally find it easier to resolve dependencies myself rather than use MacPorts.
3D MRI registration using X-correllation as objective function as implemented by DL Collins et al. It's available as part of the MINC package.
Specific special case. Basically large 3D matrices of doubles.
Okay, somebody at Apple screwed up and put an old bit in the update.
But you shouldn't be using CPAN to update your vendor perl. Period. (As is mentioned in threads below.)
Perl is easy to install your own copy of. The default install sets your own copy up in /usr/local where it is out of the way. That is what you should do with perl on _any_ OS that uses perl as a part of the OS. Why is that so hard to understand?
In fact, it's what you should do with Python, or with basically any piece of software that you want to customize.
Use CPAN to update and manage that install and let the OS tools manage the OS installs of whatever.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
Note that The Sims 2 regression testing is very popular, and there are both QA at both companies and devseeds who test a variety of combinations of recent The Sims 2 engines (Bon Voyage, OFB, Pets, etc.) and major upgrades from Apple most recently including 10.5.6 and QT. A combination of an older TS2 engine (e.g. Nightlife or the bare game) and 10.4.11 + a new QT simply might not have been regressed.
FWIW TS2 Bon Voyage + fully up to date 10.5 works on both Intel and PPC Macs.
Make sure you tell Aspyr and bugreporter.apple.com exactly what TS2 engine you are running, and provide the output of "/usr/sbin/system_profiler -xml -detailLevel full" in both reports.
Let me stress this: it is CRITICAL that the exact version of the TS2 engine is part of the report. It's helpful to also list the order of the expansion kit installations you performed, if you know that, and to supply the contents ~/Documents/EA Games/The Sims 2/Logs/ and ~/Documents/EA Games/The Sims 2/Config/. If you can test as a new user which has never before played the game, and which has no custom content whatsoever, that would be very helpful too. Otherwise, a list of your custom content would be helpful. Don't worry about being judged; TS2-using Apple-people are probably more perverted than you anyway.
"we are working with Apple to get it resolved" is useless without a radarweb URL / bugid, which you will be provided with in reply to a submission at bugreporter.apple.com. You will also be provided with the master bugid (if one exists already) if your report is really a duplicate of the report the Aspyr message you quote implies.
Finally, you might try seeking help at moreawesomethanyou.com (a small amount of intelligence & skill testing is involved; be sure to find and read the FAQ first) where there are a number of technically competent Mac-using TS2 users. Warning: generally responsive, often helpful, but almost never polite. Be technical there, and assume that there are people much more aware of the innards of the systems involved than you can imagine. It'll help.
Finally, to be preemptive, you should locate -- arrr if necessary -- an upgrade to 10.5.6 for your wife's Mac to test whether it works fine under 10.5.6 or not. Backups. Backups. Make backups. Save a bootable image backup ('man asr' on your mac) before you do the upgrade. Save two on two separate disks, even, put one in a safe, and use the other as the target of the upgrade and for testing. Even if you decide to stay in 10.4.11, knowing whether it works for your wife in 10.5.6 is useful for diagnostics.
QT is mainly used for showing video in the TV and game console objects in TS2 for Mac OS X. It is also used for some sound (notably playing custom radio channels).
Custom content that plays un-nicely with QT may cause the game to have seizures. So might anything custom in /Library/QuickTime/ (which tends to accumulate 3rd party codecs etc.)
However, QT is also used for saving movies of the game and taking snapshots, and a few other things which are unaffected by custom content, and it is possible that something weird is happening in some corner case.
The oddity here is 10.4.11 with an unknown TS2 game engine on an unknown platform, since we were not supplied that information.
Multiprocessor/multicore issues may arise (this includes cases where things break only on older uniprocessor/unicore Macs)
GL issues may arise (10.5 through to 10.5.6 have seen many revisions to OpenGL processing compared to 10.4), so it may be important to know what video system is in use on the Mac in question.
Graphics system problems may cause issues with QT projecting non-custom content onto OGL surfaces, or with animations, or with some texture handling.
The TS2 Bon Voyage game engine is a very different and newer beast than that in TS2 Nightlife, for example. I wouldn't trust the latter to play well any more (it had sick bugs to start with).
However, you hit the nail on the head: this is a weird case that was either mysteriously not regressed (or caught in regression testing) by either Aspyr or Apple (or their nontrivially shared devseed communities). Only a tiny number of problems were reported to Apple after the (long-seeded!) QT upgrade hit the software update servers, and most of them are related to issues you mention in your third sentence.
The real problem here is that there is a disconnect between what users think are helpful bug reports and what bughunters think of as an actually useful bug report (let alone one with a reduced test case that is nearly 100% reproducible).
I wish more people would know about and use pkgsrc. This is the single reason that pkgsrc is better than all of the other alternatives, security/audit-packages:
http://www.netbsd.org/docs/pkgsrc/using.html#vulnerabilities
Recently more of X11 got added into macports, but I prefer to keep an eye on http://xquartz.macosforge.org/ so I have added +system_x11 to the end of my variants.conf file.
It is not perfect yet in 1.7, but works quite well most of the time:
http://lists.macosforge.org/pipermail/macports-users/2009-January/013494.html
I keep a partition of 10.4 around solely so that my wife and oldest son can keep playing RCT3. I received a very similar "We are aware of the issues..." email from Aspyr and got tired of waiting.
I've been using Mac OS X since the Rhapsody Developer Preview days. I caught on to this fact a long time ago: They are bastardizing *NIX. They have not grasped the meaning, spirit, or intent of *NIX. Whenever some n00b touts OS X's UNIX underpinnings as a feature I just laugh and say, "Oh, you mean they're bastardizing UNIX and giving you the worst of both worlds? Yeah sign me up." Truth is they are using the open source community for their own selfish goals. Their "contributions" back to the open source movement? Puh-leeze. Tell me all about their additions to open source and for each one I can tell you why its useless to me as an open source developer and is only meant to further their proprietary agenda. They don't make improvements to open source technology, they introduce their own tech, with or without marginal additional benefit, which you may utilize only if you let them turn your open source world on its ear and adopt the philosophy that they are the greatest force in the software development world. ("They" are not just Apple, but most/all commercial companies that "embrace", "adopt", or "contribute" to open source.) I am sick of companies "adopting" open source only to push basically "lite" versions of _their_ crap and/or stubs to their over priced proprietary tie-ins.
That ranting aside I will admit that they are my primary desktop platform and their usability is far beyond that of Windows, GNOME, and KDE. I just refuse to develop for their platform (be it at the Darwin interface level or especially not at the Cocoa interface level.) I use my Mac for connecting to my Slackware and FreeBSD servers, editing text, emailing, and web browsing. Use proprietary software where it excels but beware of allowing it to infect our open source way of life. We will get there someday (to where we never need proprietary software and the world as a whole has truly embraced open source) only if we don't let them have their way of turning open source in to their marketing playground.
No matter whose fault you *think* it is:
it takes 15 minutes to fix it
follow the error trail, reinstall (i.e to build the compiled goods against the right version)
If you really think this is Apple or CPAN's fault (more the former than the latter if you get down to it) then you need to dig a hole, get in it, and never come out