iPhoto 5.0.4 Released [Archive]

jettredmont

Jul 26, 2005, 04:08 PM

Ditto for me and my Cannon Dig. Rebel. Not every rotated photo got screwed up though - very odd. I use Portfolio for my main image management system but also use iPhoto for easy slideshows and iDVD integration.

Hmm. Interesting.

The only annoying issue I've run into with my EOS (300D, original model, not XT) is that if I import into iPhoto and then iPhoto crashes (I still haven't figured out why it does that periodically) before I've quit/restarted, then the auto-rotation info is gone. Well, not really "gone", in that the picture itself is still properly rotated, but the thumbnails are all back to portrait mode. If I go into the picture itself and make any kind of edit, the thumbnail gets rotated back right, except there's now a large white "portrait" shaped bounding box around it ... only real solution has been to export the photos back out and import them in again.

Maybe the update will fix this. OTOH, I've taken to quitting immediately after import anyways (I import about 200+ pictures at a time ... rotating them by hand is a PITA!) just to avoid this. Maybe I'll have to tempt fate and see if I can get iPhoto to crash for me again ...

FoxyKaye

Jul 26, 2005, 04:09 PM

Thought this was totally a problem with my system - never got around to checking with other folks. Thank goodness this is fixed.

Gorbag

Jul 26, 2005, 04:11 PM

Oh thank God, I hated this bug, iPhoto is now virtually bugless for me. :D :D :D
Wish i could say the same. The red-eye removal is very patchy. sometimes it works fine, sometimes it deposits dark patches on other parts of the image than where it's supposed to be.
It is still slow on both my G4 533 1 GB and my girlfriend's iMac G5 2Ghz which SURELY should be fast enough. Hell Photoshop works faster on my machine than iPhoto does on hers. Really think Apple need to work out why this app is so slow, and inaccurate.

Also noticed an odd bug the other day, concerning rotation within iPhoto, that disappeared whan i zoomed in on a shot to try and de red-eye it.

Will download the latest version and see if it helps, but i suspect from the description that it wont.

Doctor Q

Jul 26, 2005, 04:12 PM

I think download sizes reflect the version you are starting from so they can vary from one person to the next.

iDM

Jul 26, 2005, 04:14 PM

nightdweller25

Jul 26, 2005, 04:14 PM

Oh thank God, I hated this bug, iPhoto is now virtually bugless for me. :D :D :D
I take it back, there is still that one bug that if I rotate an image up to the 3rd rotation, I get a white blank, and rotate it again and it's back!:confused: So yeah, still that one bug... :mad:

autrefois

Jul 26, 2005, 04:16 PM

http://www.macrumors.com/images/macrumorsthreadlogo.gif (http://www.macrumors.com)

Now available in your Software Update:

The update is also availble for download from the Apple website (http://www.apple.com/support/downloads/iphoto504update.html).

iPhoto 5.0.3 is 176.6 MB. The 5.0.4 update in my Software update is 41.0 MB. Do you mean to tell me that nearly 25% of the program needed to be changed to fix one thing?

Are Apple already using universal binaries on iPhoto?? In any case, I'm sure modem users aren't too happy...

Dagless

Jul 26, 2005, 04:20 PM

...modem... users...??

Gorbag

Jul 26, 2005, 04:21 PM

I think download sizes reflect the version you are starting from so they can vary from one person to the next.

41 Mb for me, and i was going from 5.0.3. surely we don't have to download the that much of the app each time there is an update?????

Gorbag

Jul 26, 2005, 04:24 PM

...modem... users...??

Hmmn, i'm almost thinking of going back to a modem, given that my Bulldog ADSL line seems to drop approximately every 40 seconds in the evening, and at night. i.e. when i most want to use it.

stcanard

Jul 26, 2005, 04:28 PM

iPhoto 5.0.3 is 176.6 MB. The 5.0.4 update in my Software update is 41.0 MB. Do you mean to tell me that nearly 25% of the program needed to be changed to fix one thing?

Are Apple already using universal binaries on iPhoto?? In any case, I'm sure modem users aren't too happy...

Umm, remember they aren't patching bytecode within iPhoto.

The download would be the entirety of whatever library contains that code, plus the installer code to do the necessary checks and balances.

If that library happens to contain, say, the image editing library, then 41MB is fairly small.

Elektronkind

Jul 26, 2005, 04:29 PM

iPhoto 5.0.3 is 176.6 MB. The 5.0.4 update in my Software update is 41.0 MB. Do you mean to tell me that nearly 25% of the program needed to be changed to fix one thing?

From a coder's standpoint, you have a kind of simpleton reasoning here, so let me shed some light on why a "one little 'ol change" means a 41MB download in this case.

iPhoto, as an application package, has total installed size of around 150MB. This includes many things such as support files (international language customizations for iPhoto menus and dialogues and similar support resource files) as well as the iPhoto program itself and any support programs.

The biggest single file in the iPhoto application package is the executable binary file itself... this is the program that is iPhoto. This is what you see running in a process listing. Its size is around 40MB, and this is also where the seemingly tiny little fix is located.

Now, with these binary files, you can't (in a reasonable fashion) replace little bits and pieces of it. It's more reliable to replace the whole thing. This is why you have a 41MB file waiting for you.

Please remember last time that rarely are the changes in direct proportion to the size of the update... not on such a small scale such as this instance.

/dale

FoxyKaye

Jul 26, 2005, 04:30 PM

Does anyone else get really excited when their are iPhoto updates? I don't think this really will fix much for me but hey any fixes to iPhoto are just as exciting as Security updates and even OSX updates! Hell iPhoto updates are better then those Mac Mini or iBook updates!
Well, maybe not like Scooby-doo lunging for a Scoobie snack excited, but I really enjoy iPhoto a lot - using it has changed the way I store photos and images, and it's my favorite iLife application.

...modem... users...??
Better start now to be done before the weekend! Seriously, though... Given that the majority of the computer-using universe doesn't have broadband, a download of almost 40MB does seem a little silly. It's almost the same size as some OS revisions...

Elektronkind

Jul 26, 2005, 04:31 PM

Umm, remember they aren't patching bytecode within iPhoto.

The download would be the entirety of whatever library contains that code, plus the installer code to do the necessary checks and balances.

If that library happens to contain, say, the image editing library, then 41MB is fairly small.

Yeah, the iPhoto binary contains everything except the mechanism which converts PhotoCD-format pictures. A separate binary handles this (apparently it is lifted from the NetPBM suite of free image conversion tools)

/dale

feakbeak

Jul 26, 2005, 04:31 PM

Until last night I had never encountered an iPhoto bug. Granted I've only had my Powershot A95 for about 6 months and don't use it a ton. I just got back from a long weekend vacation on Lake Michigan near Mackinaw City and imported 124 pictures and started crashing like mad when browsing through them. I was going to downgrade to 5.0.2 but now I don't have to do that. Woohoo!

Thank you, Apple.

michaelrjohnson

Jul 26, 2005, 04:33 PM

Sounds like a welcome feature. My camera doesn't auto-rotate, so I won't be updating this time around... next version!

nagromme

Jul 26, 2005, 04:34 PM

Just when you thought Apple had no excitement in store for us today :D

feakbeak

Jul 26, 2005, 04:47 PM

Now, with these binary files, you can't (in a reasonable fashion) replace little bits and pieces of it. It's more reliable to replace the whole thing.Sorry to continue the tangent a bit here, but the topic of binary patching interests me. Does Apple (or any OS X software developers) release byte-level patching updates? It can save a ton of bandwidth and for individual applications it might not be that big of a deal but I would think Apple could save a fortune on bandwidth using byte-level patching for their updates issued via Software Update.

I'm a coder from the Windows world and previously did the install work for my company using the Windows Installer engine from Microsoft, which has byte-level patching built-in. We just released a hotfix for an 80 MB application. The file that had to be recompiled was one of the main .EXEs - about 10 MB in size. We were able to generate a patch to update the application that was less than 3 MB.

I completely agree that byte-level patching is less reliable but Windows Installer compensates for this by caching the original install information and if the binary file on the system isn't an exaxt match of the expected binary file to be patched it will request the original installation source and patch that original source file and overwrite the one on the system with the newly patched file. It's pretty cool when it all works as designed. However, Windows Installer is overly complicated in many ways and therefore does not always work well in some practical cases.

autrefois

Jul 26, 2005, 04:50 PM

The download would be the entirety of whatever library contains that code, plus the installer code to do the necessary checks and balances.

If that library happens to contain, say, the image editing library, then 41MB is fairly small.

The biggest single file in the iPhoto application package is the executable binary file itself... this is the program that is iPhoto. This is what you see running in a process listing. Its size is around 40MB, and this is also where the seemingly tiny little fix is located.

Now, with these binary files, you can't (in a reasonable fashion) replace little bits and pieces of it. It's more reliable to replace the whole thing. This is why you have a 41MB file waiting for you.

Thank you very much for the explanation, I appreciate it. I suppose given this information, the 41 MB size is not surprising.

Umm, remember they aren't patching bytecode within iPhoto.

From a coder's standpoint, you have a kind of simpleton reasoning here [...]

Flattery will get you nowhere.

You certainly would agree that most updates from Apple include more changes/fixes while taking up less room. I apparently was not the only person unaware of how this worked and/or surprised at the size of the update, so I appreciate the fact that you have cleared things up.

Trowaman

Jul 26, 2005, 04:52 PM

Just when you thought Apple had no excitement in store for us today :D

I was extremely happy with today's earlier announcements, both of them. I got exactly what I wanted, not more power but more bells and whistles.

iMeowbot

Jul 26, 2005, 04:57 PM

Sorry to continue the tangent a bit here, but the topic of binary patching interests me. Does Apple (or any OS X software developers) release byte-level patching updates? It can save a ton of bandwidth and for individual applications it might not be that big of a deal but I would think Apple could save a fortune on bandwidth using byte-level patching for their updates issued via Software Update.
I suppose it's the only way to be sure, given that people do insist on doing weird patch things out in the wild. A dual path, either patch or replace after grabbing a hash, would be nice, but perhaps it isn't worth the bother.

DillWaters

Jul 26, 2005, 05:09 PM

It seems likely that this 5.0.4 updater will work on any version from the 5.0 that is on the original iLife DVDs, through 5.0.1, 5.0.2, etc. Therefore it needs to have ALL the changes from the 5.0 version, even though it may only need 1 or 2 files to patch 5.0.3 version.

The only alternative would be to do what Apple do for the System Updates, which is to release a separate Combo updater for earlier versions.

stcanard

Jul 26, 2005, 05:15 PM

Flattery will get you nowhere.

I have a feeling there is an expectation difference here.

From a programmer's point of view, this is so obvious that asking the question is a head-banging against the wall type thing.

So we tend to give a head-bang response, then later realize that, oops, not everybody understands the intimate workings of a computer anymore than I understand embedded colour profiles...

So sorry about the sarcasm!

~Shard~

Jul 26, 2005, 05:15 PM

...modem... users...??

I assume he meant dial-up modem users, not cable modem or DSL modem users... ;)

alex_ant

Jul 26, 2005, 05:15 PM

Umm, remember they aren't patching bytecode within iPhoto.
Why not?
The download would be the entirety of whatever library contains that code, plus the installer code to do the necessary checks and balances.

If that library happens to contain, say, the image editing library, then 41MB is fairly small.
That sounds pretty primitive to me. I wonder if Apple has ever heard of modular software. Picasa must have because the entire install file is 3.2MB. That's a byte-size-to-this-software-rocks ratio more than 40 times higher than iPhotos.

alex_ant

Jul 26, 2005, 05:18 PM

So we tend to give a head-bang response, then later realize that, oops, not everybody understands the intimate workings of a computer anymore than I understand embedded colour profiles...
they should have to?

stcanard

Jul 26, 2005, 05:19 PM

I completely agree that byte-level patching is less reliable but Windows Installer compensates for this by caching the original install information and if the binary file on the system isn't an exaxt match of the expected binary file to be patched it will request the original installation source and patch that original source file and overwrite the one on the system with the newly patched file. It's pretty cool when it all works as designed. However, Windows Installer is overly complicated in many ways and therefore does not always work well in some practical cases.

My guess would be two-fold:

1) From the "it-just-works" perspective, Apple doesn't want to risk updates breaking things (I wonder how much this complication adds to the random updating issues that show up in Windows?)

2) For many moons now Apple has been existing in a multi ISA world. Prior to OSX there was a mixture of PPC and 68K code in the system, now of course we have the issue of upcoming x86 code. It wouldn't surprise me that given this, there would be a culture of avoiding byte-patching because there are too many potential issues.

stcanard

Jul 26, 2005, 05:19 PM

they should have to?

Nope, but its so obvious to me and everyone knows what I'm thinking ;)

Applespider

Jul 26, 2005, 05:27 PM

I wonder if this will break something new... :rolleyes:

5.0 gave us new features but could corrupt iPhoto 4 libraries on import
5.0.1 fixed the import from iPhoto 4 bug but made large libraries unstable
5.0.2 fixed the instability (somewhat) but gave us the colour shift bug
5.0.3 fixed the colour shift bug and gave us the weird crash/duplicate of rotated images when imported
5.0.4 fixed the rotation bug and gave us ?

Weird though how you wait 2 months for an iPhoto update and then 2 come along in a week or so...

alex_ant

Jul 26, 2005, 05:37 PM

I wonder if this will break something new... :rolleyes:
I don't think so. In order for it to do that, something would have to be working properly in the first place. Your list was informative, but you left off what I think are the more important bugs:

5.0 crashed all the time, randomly corrupted your library, was slow as hell, and used up 800MB of RAM with a 20,000-photo library
5.0.1 crashed all the time, randomly corrupted your library, was slow as hell, and used up 800MB of RAM with a 20,000-photo library
5.0.2 crashed all the time, randomly corrupted your library, was slow as hell, and used up 800MB of RAM with a 20,000-photo library
5.0.3 crashed all the time, randomly corrupted your library, was slow as hell, and used up 800MB of RAM with a 20,000-photo library
5.0.4 ? (haven't tried it yet)

recordprod

Jul 26, 2005, 05:47 PM

chibianh

Jul 26, 2005, 05:48 PM

someone has a thing against iPhoto... ;)

autrefois

Jul 26, 2005, 05:48 PM

I assume he meant dial-up modem users, not cable modem or DSL modem users... ;)

Yes I did, sorry about that. :)

If I could go back in time, I would stop myself from posting in this thread since my original post caused so much discussion and really showed my "laymanosity." It's true that on this forum we have a mixture of experts and people who are pretty much clueless when it comes to computers. I guess I'm a lot closer to the latter group than I thought I was... ;)

Back to the subject of the update: I haven't had any problems with 5.0.4 after installing it and quickly checking it out (but then again I wasn't having any problems to begin with).

~Shard~

Jul 26, 2005, 05:51 PM

Yes I did, sorry about that. :)

If I could go back in time, I would stop myself from posting in this thread since my original post caused so much discussion and really showed my "laymanosity." It's true that on this forum we have a mixture of experts and people who are pretty much clueless when it comes to computers. I guess I'm a lot closer to the latter group than I thought I was... ;)

No worries at all, I just posted that for clarification - don't be too hard on yourself. ;) :)

j-a-x

Jul 26, 2005, 05:56 PM

Wow that was quick, it took iPhoto like 4 months to fix the editing bug where everything turned red. I'm surprised to see another update so soon!

manu chao

Jul 26, 2005, 06:10 PM

[...]
It is still slow on both my G4 533 1 GB and my girlfriend's iMac G5 2Ghz which SURELY should be fast enough. Hell Photoshop works faster on my machine than iPhoto does on hers. Really think Apple need to work out why this app is so slow, and inaccurate.
[...]

I would not recommend anybody to run any Mac with less than 1GB of Ram, except if they are willing to always quit programs before starting new ones.
Actually, I would not buy a Mac myself with less than 2GB of Ram (and the option to increase this further).

Doctor Q

Jul 26, 2005, 06:55 PM

I would not recommend anybody to run any Mac with less than 1GB of Ram, except if they are willing to always quit programs before starting new ones.
Actually, I would not buy a Mac myself with less than 2GB of Ram (and the option to increase this further).I agree that the more RAM you have the better performance can be, but I disagree with the implication that you can't run many applications at once. The overhead of changing from one active application to another may make that action slower when you have large-memory apps and small RAM, and a single large app can be slow if you don't have enough for RAM for its particular needs, but you shouldn't have to quit applications as we did before Mac OS X to let other apps work, or to make them perform better. Let the memory management code in Mac OS X take care of things with memory swapping and run whichever apps you like.

Mathew Burrack

Jul 26, 2005, 07:27 PM

Not to continue the continued tangent, but...

1) From the "it-just-works" perspective, Apple doesn't want to risk updates breaking things (I wonder how much this complication adds to the random updating issues that show up in Windows?)

2) For many moons now Apple has been existing in a multi ISA world. Prior to OSX there was a mixture of PPC and 68K code in the system, now of course we have the issue of upcoming x86 code. It wouldn't surprise me that given this, there would be a culture of avoiding byte-patching because there are too many potential issues.

There are ways around both issues, though. The installer, from a high-level perspective, doesn't know or care about what the files are that it's installing, just that they're strings of bits to store on the hard drive. From that standpoint, binary-patching x86 code vs PPC vs 68K code wouldn't make a bit (haha) of difference. Also, IIRC, the fat binaries are really packages containing multiple binary files, one set for each platform, so there's no danger of patching a single file meant for multiple architectures anyway. (Don't hold me to that, I'm working off of memory here :)

As far as reliability, MD3 hashes are pretty darned reliable in this case. I implemented a system at Cyan that would run MD3 hashes before and after for a patch, and if the file to patch didn't match the initial MD3 hash, it would go and download the full version of the file for you. Ditto if, after the patch, the file's MD3 hash didn't match up. Out of literally terrabytes worth of patching that system did over its lifetime, not once did we find a case where the system failed. Plus, you get the added bonus of fixing any files that might have become corrupted previously.

Granted, it's a more complicated system, but not by much. I could easily see it being integrated in to Software Update as a pre-check to determine whether you can download the binary-patch version of the update or the full-blown version. (They already went a step in this direction anyway, so it could be that it's already in the works and just hasn't gotten to prime time yet). The only remaining chance of something going wrong would be that you had a corrupt file that somehow managed to match the original MD3 hash *and* matched the patched MD3 hash after patching. The chances of that happening are, well, practically nil, and if you happen to be the one unlucky one it happens to, well, that's what reinstalling is for :)

urm

*ahem*

*shoves thread back on track* nothing to see, move along...

:)

--mcn

jkhanson

Jul 26, 2005, 07:54 PM

This update seems to have fixed another bug: some photos would not go into "focus."

Usually, I set the slider to show pictures as big as possible, filling up the whole window. Then I use "page up" or "page down" to scan through photos. Seeminly at random, photos would remain slightly pixelated, as if iPhoto would refuse to put them in the right focus to fit my iPhoto window. I would have to go to the next photo and back again and then I could see the photo properly. So far, all photos have been displaying correctly the first time.

pubwvj

Jul 26, 2005, 08:51 PM

Does anyone else get really excited when their are iPhoto updates?

No. It is a yawn a minute. iFind iPhoto not iNteresting. I have tried it a few times but always found it to be a dog. GraphicConverter and Photoshop are my best friends. :)

jettredmont

Jul 26, 2005, 09:03 PM

After years of lurking my first post :)

I love iPhoto etc but bought the new version because of the RAW file features only to find my Canon D30 isn't supported :(

I hope that Apple adds more cameras to the list as soon as possible!

Mike
http://www.recordproduction.com

Did you actually try viewing the RAW from your D30 in iPhoto? I know it doesn't list it as supported, and that the D30 was Canon's first DSLR effort (but not their first digital camera overall, nor their first RAW camera), so it's likely that the RAW formats have changed, but seems it wouldn't hurt trying. Certainly, the more recent Canon RAW cameras are supported ...

Gorbag

Jul 27, 2005, 01:12 AM

I agree that the more RAM you have the better performance can be, but I disagree with the implication that you can't run many applications at once. The overhead of changing from one active application to another may make that action slower when you have large-memory apps and small RAM, and a single large app can be slow if you don't have enough for RAM for its particular needs, but you shouldn't have to quit applications as we did before Mac OS X to let other apps work, or to make them perform better. Let the memory management code in Mac OS X take care of things with memory swapping and run whichever apps you like.

Good point, and, as i said, Photoshop runs perfectly well on both machines. So why cant iPhoto? Not as if it does a fraction of what photoshop does!

macorama

Jul 27, 2005, 02:34 AM

Re the size of the update - you'll find that the announced list of fixes for an update doesn't cover every single thing that's changed, they've probably fixed a heap of tiny things that only happen when you have a certain size photo and do a certain sequence of things on it, but they don't list that in the release note. It's not like Apple has a public bug tracking system, Firefox style.

It's still a buggy program though for people who use it intensively - for example if you edit (e.g. rotate) 50 photos, and it crashes on the last one, then when you relaunch all 50 photos are back to normal - very frustrating! Hopefully there's a fix for that in there somewhere.

toughboy

Jul 27, 2005, 02:46 AM

Odd. It's 41MB for me updating from 5.03 in Software Update. 41MB to fix an image rotation bug is taking the biscuit slightly. They really should modularise it more.

I was about to say the same thing, 5.0.3 update was about the same size, maybe they are just replacing a newer copy of the iPhoto instead of updating it.. You know, with iTunes its the same thing, they just replace the working version with the new version, but iPhoto is sold in a pack while iTunes is totally free..

Some of the pics taken with my PowerShot S50 was weirdly and randomly rotated, and some werent, maybe they fixed it all with this update. Lets wait n see..

AmigoMac

Jul 27, 2005, 03:43 AM

Installed : No probs, it's running fine and *snappy* as usual. more than 1500 photos and 10.3.9 , I like iPhoto. Now preparing my self for Tiger...

Applespider

Jul 27, 2005, 03:50 AM

It's still a buggy program though for people who use it intensively - for example if you edit (e.g. rotate) 50 photos, and it crashes on the last one, then when you relaunch all 50 photos are back to normal - very frustrating! Hopefully there's a fix for that in there somewhere.

To be honest, I thought that had changed in 5.0.3. I'm fortunate in that, aside from the colourshift bug, my iPhoto has been remarkably stable (around 8000 images) but it has crashed a couple of times. In iPhoto 5-5.0.2, if it crashed while editing, I'd find weirdly shaped thumbnails and that many of the changes seemingly hadn't been saved. 5.0.3 crashed once last week but the picture I'd been working on beforehand had been saved and all the thumbnails were correct.

Algedeon

Jul 27, 2005, 04:38 AM

I had random crushes all the time myself... what saved the day was to
re-build the iPhoto library (by holding down command-option-shift and launching the iPhoto program). From the dialog that opens,
check the first three entries to rebuild the library and thumbnails.
This usually resolves ALL my crashes...

I don't think so. In order for it to do that, something would have to be working properly in the first place. Your list was informative, but you left off what I think are the more important bugs:

5.0 crashed all the time, randomly corrupted your library, was slow as hell, and used up 800MB of RAM with a 20,000-photo library
5.0.1 crashed all the time, randomly corrupted your library, was slow as hell, and used up 800MB of RAM with a 20,000-photo library
5.0.2 crashed all the time, randomly corrupted your library, was slow as hell, and used up 800MB of RAM with a 20,000-photo library
5.0.3 crashed all the time, randomly corrupted your library, was slow as hell, and used up 800MB of RAM with a 20,000-photo library
5.0.4 ? (haven't tried it yet)

mactim

Jul 27, 2005, 05:08 AM

I'm 'a coder' and I think it is a perfectly valid question to ask. There have not been that many iPhoto 5 releases. Apple could send only the binary delta (or 'diff') between the release you have and the latest version. This would help reduce needless load on their own site and the internet.
I find that 'coders' are more likely to make excuses for the way things are. Those with a more 'abstract' view of computers often are the ones that question strange or obsurd behaviour.

From a coder's standpoint, you have a kind of simpleton reasoning here, so let me shed some light on why a "one little 'ol change" means a 41MB download in this case.

iPhoto, as an application package, has total installed size of around 150MB. This includes many things such as support files (international language customizations for iPhoto menus and dialogues and similar support resource files) as well as the iPhoto program itself and any support programs.

The biggest single file in the iPhoto application package is the executable binary file itself... this is the program that is iPhoto. This is what you see running in a process listing. Its size is around 40MB, and this is also where the seemingly tiny little fix is located.

Now, with these binary files, you can't (in a reasonable fashion) replace little bits and pieces of it. It's more reliable to replace the whole thing. This is why you have a 41MB file waiting for you.

Please remember last time that rarely are the changes in direct proportion to the size of the update... not on such a small scale such as this instance.

/dale

Mustafa

Jul 27, 2005, 05:15 AM

If you download 5.0.4 from Apple.com it is actually 5.0.3 when you mount the DMG.

If I go to Software Update it tells me there are no updates I need. I'm still on 5.0.2.

I downloaded 5.0.4 from the Apple site, but it won't install, telling me there is no eligible software in /Applications.

Same for GarageBand 2.0.2 (not that I use it, but I like to keep things up to date).

Anyone else getting this?

Applespider

Jul 27, 2005, 05:41 AM

I downloaded 5.0.4 from the Apple site, but it won't install, telling me there is no eligible software in /Applications.

Same for GarageBand 2.0.2 (not that I use it, but I like to keep things up to date).

Have you rearranged your Applications folder into subfolders? If so, Software Update won't see your iApps. Put them back into the main Apps folder and then see what SU finds.

If you really feel the need to have your applications in subfolders, consider creating a new folder with subfolders but putting aliases of your applications in them rather than the actual apps themselves. Then put that folder into your sidebar for easy access.

Porchland

Jul 27, 2005, 08:56 AM

No. It is a yawn a minute. iFind iPhoto not iNteresting. I have tried it a few times but always found it to be a dog. GraphicConverter and Photoshop are my best friends. :)

I don't know GraphicConverter, but I think iPhoto/Photoshop work extremely well together. I bring everything into iPhoto to start and do light editing there like slight color and brightness tweaking. If it needs major levels, color, roto or other work, I open it Photoshop (which iPhoto makes very easy to do). After I save and close the image in Photoshop, it refreshes in iPhoto.

Porchland

Jul 27, 2005, 09:13 AM

I thought iPhoto 5 got an awful lot right: really easy-to-use quicky editing features, great custom books (just ordered my first!), and runs smoother on my PowerBook than iPhoto 4.

I would like to see in iPhoto 6:
* More integrated handling of MPEG-4 images. I love that my little Canon PowerShot can capture MPEG-4 clips, but iPhoto can't do much more with it than hold a place for it at the moment.

Again, I thought iPhoto 5 was a homerun and iPhoto 6 won't need to fix much.

Anything else?

Doctor Q

Jul 27, 2005, 10:11 AM

Good point, and, as i said, Photoshop runs perfectly well on both machines. So why cant iPhoto? Not as if it does a fraction of what photoshop does!I assume the difference is Photoshop's excellent internal design based on years of development experience and a lot of fine tuning.

About the "diff" issue: Since apps are written in high-level languages with high-level tools such as Xcode, I would expect that changing a single line of code (adding "if RotatingPhoto then DontCrashSoOften" to iPhoto) would change almost all of the resulting binary, because code would shift position.

On the other hand, an application consists of many files, and we'd assume an update doesn't reissue files that have not changed.

benpatient

Jul 27, 2005, 11:11 AM

40mb to fix camera rotation?

I think the entire iView media pro application had a smaller download size!

Why has OS X turned Apple into a bloatware company?

Mathew Burrack

Jul 27, 2005, 11:51 AM

About the "diff" issue: Since apps are written in high-level languages with high-level tools such as Xcode, I would expect that changing a single line of code (adding "if RotatingPhoto then DontCrashSoOften" to iPhoto) would change almost all of the resulting binary, because code would shift position.

On the other hand, an application consists of many files, and we'd assume an update doesn't reissue files that have not changed.

In this case, the 40MB is talking about the main executable (single file). Regardless, even with programs written in high-level languages, relatively little changes. Although the code might shift in position, binary patchers can handle such a case very efficiently. The only issue left is the actual changed instructions and any jump offsets that have changed due to the shift in code position, but those are relatively miniscule changes compared to the entire executable.

Now, if they fixed a *lot* of bugs that required lots of code changes, then the binary patching might not be worth it, but I'm operating on the assumption of a small set of changes compared to 40MB of code.

And yes, us coders tend to make more excuses about the way things are than not. It's something that we really should change. IMHO, every time a non-coder user uses an app of mine and goes "but why does it have to be this way?", there better be a *damned* good reason, or I've failed in my job.

But then, maybe that's just me :)

--mcn

mactim

Jul 27, 2005, 11:55 AM

I think it's debatable whether objective-C is high-level :)
Also, typical binary diff tools will understand the scenario you describe.

About the "diff" issue: Since apps are written in high-level languages with high-level tools such as Xcode, I would expect that changing a single line of code (adding "if RotatingPhoto then DontCrashSoOften" to iPhoto) would change almost all of the resulting binary, because code would shift position.

On the other hand, an application consists of many files, and we'd assume an update doesn't reissue files that have not changed.

Mathew Burrack

Jul 27, 2005, 12:01 PM

I think it's debatable whether objective-C is high-level :)

Hey, I've written some *very* high-level objective-C code in my time! Not much, granted, but some! In fact, at last check, it was almost to level 50! Just a few more baddies...

--mcn

MarkCollette

Jul 27, 2005, 01:22 PM

A few things:

1. Please use MD5 instead of MD3
2. Do you really want to spend the QA time testing every upgrade scenario when you can just drop in one single working file? I'm sure the extra QA cost would offset the bandwidth expenditure
3. If the old version causes data corruption, do you really want to delay a release to setup the extra testing specific to your patching strategy, when a simpler release sooner will save people's data?

Not to continue the continued tangent, but...

There are ways around both issues, though. The installer, from a high-level perspective, doesn't know or care about what the files are that it's installing, just that they're strings of bits to store on the hard drive. From that standpoint, binary-patching x86 code vs PPC vs 68K code wouldn't make a bit (haha) of difference. Also, IIRC, the fat binaries are really packages containing multiple binary files, one set for each platform, so there's no danger of patching a single file meant for multiple architectures anyway. (Don't hold me to that, I'm working off of memory here :)

As far as reliability, MD3 hashes are pretty darned reliable in this case. I implemented a system at Cyan that would run MD3 hashes before and after for a patch, and if the file to patch didn't match the initial MD3 hash, it would go and download the full version of the file for you. Ditto if, after the patch, the file's MD3 hash didn't match up. Out of literally terrabytes worth of patching that system did over its lifetime, not once did we find a case where the system failed. Plus, you get the added bonus of fixing any files that might have become corrupted previously.

Granted, it's a more complicated system, but not by much. I could easily see it being integrated in to Software Update as a pre-check to determine whether you can download the binary-patch version of the update or the full-blown version. (They already went a step in this direction anyway, so it could be that it's already in the works and just hasn't gotten to prime time yet). The only remaining chance of something going wrong would be that you had a corrupt file that somehow managed to match the original MD3 hash *and* matched the patched MD3 hash after patching. The chances of that happening are, well, practically nil, and if you happen to be the one unlucky one it happens to, well, that's what reinstalling is for :)

urm

*ahem*

*shoves thread back on track* nothing to see, move along...

:)

--mcn

Mathew Burrack

Jul 27, 2005, 02:52 PM

A few things:

1. Please use MD5 instead of MD3
2. Do you really want to spend the QA time testing every upgrade scenario when you can just drop in one single working file? I'm sure the extra QA cost would offset the bandwidth expenditure
3. If the old version causes data corruption, do you really want to delay a release to setup the extra testing specific to your patching strategy, when a simpler release sooner will save people's data?

1. Gah, sorry about that, my brain had a small error trying to remember that detail. It was MD5. I was wondering why MD3 looked so strange when I typed it... Thanks for the correction :~)

2. Depends on the QA cost and the bandwidth cost, naturally. And there is really only one additional scenario to consider: binary patching against the last revision (there's no point in supporting binary patches for multiple revisions back, since you have a greater chance as you go back of the binary differences being close to just replacing the entire file. Also, you acheive the greatest impact that way: those that upgrade often get small patches, which is good since they do it often, vs. those that upgrade rarely get big patches but don't care as much since they upgrade rarely :)

3. To answer your Q with a Q: do you want to create a blanket policy for all updates that might be only applicable some of the time? In your case above, I would simply generate a full patch w/o the binary diffs, since timeliness is important, and generate binary patches when we can spend the extra time for testing/release (which is hopefully the rule rather than the exception. Cyan's patcher worked this way, actually--if we didn't want to wait to generate/test binary patches, we simply didn't generate them, and the patcher utility would simply fall back to the full file option when it couldn't find the binary patch).

As for more complexity/increasing QA time, the key was to make a very robust patching utility up front--one that, if *any* problem was ever detected, would fall back on the full-file version. Thus, if for some reason the binary patches for a new release were garbled or buggy, the patcher utility would catch it when checksumming the final product (checksums were generated on the original masters). In that way, we could actually end up with buggy binary patches and never even know it, since the patcher would catch it and react appropriately to ensure the user had correct data.

They key was to deliver to the user correct data quickly, caring more about correctness than speed, but still attempting to do the fast method first if at all possible. That way, most users are happy about the speed (except the rare case that has to fall back to full file upgrades) but all users are happy about correctness. Without binary patching, all users are happy about correctness and most/none are happy about speed. Frankly, I don't see much of a contest there :)

ymmv

--mcn

MarkCollette

Jul 27, 2005, 04:31 PM

3. To answer your Q with a Q: do you want to create a blanket policy for all updates that might be only applicable some of the time? In your case above, I would simply generate a full patch w/o the binary diffs, since timeliness is important, and generate binary patches when we can spend the extra time for testing/release (which is hopefully the rule rather than the exception. Cyan's patcher worked this way, actually--if we didn't want to wait to generate/test binary patches, we simply didn't generate them, and the patcher utility would simply fall back to the full file option when it couldn't find the binary patch).

I think we both agree that given time it might be best to put the effort in, and that in this specific case there was not a lot of time.

As for more complexity/increasing QA time, the key was to make a very robust patching utility up front--one that, if *any* problem was ever detected, would fall back on the full-file version. Thus, if for some reason the binary patches for a new release were garbled or buggy, the patcher utility would catch it when checksumming the final product (checksums were generated on the original masters). In that way, we could actually end up with buggy binary patches and never even know it, since the patcher would catch it and react appropriately to ensure the user had correct data.

They key was to deliver to the user correct data quickly, caring more about correctness than speed, but still attempting to do the fast method first if at all possible. That way, most users are happy about the speed (except the rare case that has to fall back to full file upgrades) but all users are happy about correctness. Without binary patching, all users are happy about correctness and most/none are happy about speed. Frankly, I don't see much of a contest there :)

ymmv

--mcn

I don't think you can write off the QA time by having a solid patching program. With different software versions you sometime have non-code changes like config files changing, documentation errors being fixed, etc. that might be missed by just looking at code changes. And even if you catch all of those, what about files that are generated by the code only on the user's machine, like preferences, caches and indexes. Those might have changed format, or become redundant.

Plus we don't know what was causing the photo corruptions. It could have been bizarre interactions with many different subsystems. Or maybe when fixing some little issue, some coder thought "I should rename this method that's called everywhere, to have a more descriptive name" :)

Mathew Burrack

Jul 27, 2005, 04:48 PM

WARNING: continuing the off-topic-ness. Apologies to any offended parties in advance. :)

I think we both agree that given time it might be best to put the effort in, and that in this specific case there was not a lot of time.
If you're talking about this iPhoto update (see, we're on topic! :), then yes, I agree. I was more addressing the patching issue in general.

I don't think you can write off the QA time by having a solid patching program.
Write off, no. Be less cautious is more like it, especially if you make sure to put the patcher itself through the QA ringer beforehand (thus making the worst-case QA for any patch re. the patches themselves a regression test).

With different software versions you sometime have non-code changes like config files changing, documentation errors being fixed, etc. that might be missed by just looking at code changes.
All of which are just bits, and handled by the binary patching. I'm not talking about code changes, I'm talking about a system that takes a set of files that are labeled "iPhoto 5.0.3" and another set called "iPhoto 5.0.4" and figures out bit-for-bit what's different. That would catch, well, everything :)

And even if you catch all of those, what about files that are generated by the code only on the user's machine, like preferences, caches and indexes. Those might have changed format, or become redundant.
And they won't be handled by full-file patching, anyway. In those cases, it's either a) the installer's job to upgrade or erase them, or b) the app's job to gracefully handle older formats. Either way, it's a separate issue from binary patching.

Plus we don't know what was causing the photo corruptions. It could have been bizarre interactions with many different subsystems. Or maybe when fixing some little issue, some coder thought "I should rename this method that's called everywhere, to have a more descriptive name" :)
I *hope* they don't have debugging symbols included in those builds! In case they do, though, the name change would only be in one place (the symbol table) and thus only add a few dozen bytes to the binary patch :)

As far as the many-different-subsystems, as I said, if the binary diff becomes too large (approaching the size of the original file), you just fall back to the full-file method. No harm done, since that's not what the binary diff is meant to help with anyway.

Maybe it would help to think of it a different way: the binary patching would basically just be a more efficient file copy than the file copy that the installer/Software Update performs *already*. Everything else remains identical, it's just that you get a file copy without having to actually download the original file. It could literally be dropped into place without affecting the rest of the entire update utility, very easily. If it were any other way, then it *would* be a QA nightmare and not worth the risk. It's the self-contained, modular, narrow-field-of-focus approach to binary patching that makes it work so well in patching/updating/installing land and keeps the QA and risks to a minimum.

Just to keep this back on track wrt. iPhoto, in this case, yes, getting the patch out the door to fix corruption issues was paramount. With a binary patching method in place already, they could've just released the full version to Software Update, then generated the patches afterwards. The initial adopters that *had* to have the update immediately would have to suffer through the full download, but they'd get it ASAP, which is all they care about. Those that waited would still get the patch, but would get the smaller binary-diff patch (once they were done generating), which will make them happy since the time-to-download is a larger (relatively) issue for them.

...

ah, to hell with it. Just gimme access to the Software Update code and I'll show you. Easier to just demonstrate it and be done with it :)

--mcn

stcanard

Jul 27, 2005, 05:00 PM

2. Depends on the QA cost and the bandwidth cost, naturally.

Another point: Tiger assumes you have broadband. Look at Dashboard, iTunes, etc, all of these assume you have an always-on connection (Last I saw Canada had ~ 75% broadband penetration so its a fairly safe assumption here).

Once broadband is assumed, you are discussing adding a significant number of QA effort-hours to reduce a 3 minute download to a 1 minute download, which the end-user won't even notice.

So why spend the money and increase risk on a negligible gain?

Mathew Burrack

Jul 27, 2005, 05:27 PM

Once broadband is assumed, you are discussing adding a significant number of QA effort-hours to reduce a 3 minute download to a 1 minute download, which the end-user won't even notice.

So why spend the money and increase risk on a negligible gain?

In my experience (and *only* in my experience, so don't take it as gospel), "assuming" broadband as part of a design is a bad idea. In the best case world, yeah, you get upwards of 256Mb/sec download or higher. In the worst case, you can get down to as slow as 2Mbit/sec depending on the connection, server load, network traffic, router traffic, wireless interference on an Airport, etc.

Plus, here's the flipside: let's assume your comparison of 3 minutes to 1 minute to download (which is VERY pessimistic for binary patch savings, but we'll go with it). To an individual user, yes, such a small difference is meaningless. However, you've just *tripled* the number of users that the update servers can now handle. Or, if that increased capacity isn't used, you've now cut the amount of bandwidth/power/processing time/hardware wear-and-tear for distributing that updated by 2/3rds. That, to me, is far from a negligible gain. Is it worth the offset in QA time? Dunno, but it certainly doesn't seem so clear-cut in that case, and certainly worth investigating the tradeoffs at the very least. Plus, scale it up to 3 hours vs 1 hour and I guarantee that your end user will suddenly care a great deal, even though the ratio hasn't changed.

(Bandwidth savings in particular would be wonderful. It doesn't matter how many people have broadband, you can *never* have enough bandwidth. Just ask anybody trying to distribute HD video over the 'net :) The less bandwidth used for software updates, the more you have to spare for other products/services you provide to customers, which again is worth lots of $$, even indirectly.)

--mcn

stcanard

Jul 27, 2005, 05:43 PM

In my experience (and *only* in my experience, so don't take it as gospel), "assuming" broadband as part of a design is a bad idea.

But they already have! So it's a given, not a theoretical assumption.

(Bandwidth savings in particular would be wonderful. It doesn't matter how many people have broadband, you can *never* have enough bandwidth. Just ask anybody trying to distribute HD video over the 'net :) The less bandwidth used for software updates, the more you have to spare for other products/services you provide to customers, which again is worth lots of $$, even indirectly.)

--mcn

Generally I would agree, but I'm betting if you look at the daily bandwidth that goes through Apple, the 5 or 10 million iPhoto updates probably don't even register as a blip.

Again it all comes down to cost vs. benefit. And it goes on a per-fix thing too; I see my Garage Band update was 14MB, and I know that GarageBand is a lot bigger than 14.

Personally if I was release manager, assuming it has no measurable impact on my bandwidth charges, and the majority of my customer base is broadband, I would avoid binary patching and update entire libraries. Its not worth the QA and support headache.

The same argument goes with Apple's overzealous reboot policy on updates. Yes, we know that we could just HUP the appropriate processes, and they could write the installer to do it, but it's not worth the additional QA and support hours that would go into it.

Remember QA is _always_ pressed for time. They are always making up for the slips in the development schedule. QA time is a very precious commodity that needs to be used wisely.

Mathew Burrack

Jul 27, 2005, 06:05 PM

But they already have! So it's a given, not a theoretical assumption.

Fair 'nuf.

Personally if I was release manager, assuming (my emphasis) it has no measurable impact on my bandwidth charges, and the majority of my customer base is broadband, I would avoid binary patching and update entire libraries. Its not worth the QA and support headache.

Michael Abrash's Rule #1 of Programming: Assume Nothing.

To elaborate: I would rather, if I were a release manager, have the option available to me to use if the bandwidth savings are significant, and simply not use it if they are not. Yes, if the bandwidth savings are minimal, I agree, it's not worth the QA headache, but what if it *is*? I'd rather have the option in that case.

Remember QA is _always_ pressed for time. They are always making up for the slips in the development schedule. QA time is a very precious commodity that needs to be used wisely.

I agree, which is why I wouldn't go w/ binary patching if I didn't think it was worth it. Again, I'd rather have that option open to me, so that if I determined at some point it *was* worth it, I could take that option.

Here's another case-in-point, unrelated to software updating but the same principle applies. Most games nowadays assume a certain (rather high) level of graphics capability on their users' machines (a fact that the Mac community is only too aware of). Think in particular EverQuest 2, which had outstanding (to some people) graphics, requiring a correspondingly outstanding gfx card to handle it all. In comes Blizzard with WoW, which has decidedly simpler graphics in terms of capability, but they use it more wisely and manage to deliver a *better* graphics experience while requiring less gfx processing power to do it (just to keep it relevant, too, it can be argued that it takes more effort and work to do more with less resources, so Blizzard had to put more work/time/effort/money to keep the resource requirements down.)

EQ2 has roughly 400,000 subscribers. WoW just topped 3.5 *million* subscribers. Clearly they're doing *something* right, and their conservative approach to hardware resources is a significant part of it. Hell, just look at how many Macs can play WoW versus how many would be (theoretically) capable of playing EQ2. Meanwhile, ask Blizzard whether bandwidth matters :)

Wish for the best-case scenario, plan for the worst. You'll generally end up with much better products in the long run, and (sooner or later) your end users will thank you for it :)

--mcn

recordprod

Jul 27, 2005, 06:06 PM

Did you actually try viewing the RAW from your D30 in iPhoto? I know it doesn't list it as supported, and that the D30 was Canon's first DSLR effort (but not their first digital camera overall, nor their first RAW camera), so it's likely that the RAW formats have changed, but seems it wouldn't hurt trying. Certainly, the more recent Canon RAW cameras are supported ...

I've tried and can't view, get unsupported file type. Strange thing is that I do get preview thumbnails in finder of the RAW images. Photoshop Elements 3 works fine with the images.

Mike
http://www.recordproduction.com

stcanard

Jul 27, 2005, 06:19 PM

To elaborate: I would rather, if I were a release manager, have the option available to me to use if the bandwidth savings are significant, and simply not use it if they are not. Yes, if the bandwidth savings are minimal, I agree, it's not worth the QA headache, but what if it *is*? I'd rather have the option in that case.

Actually, we completely agree then :)

It all comes down to is the right tool for the right job, and keeping the options open!

alex_ant

Jul 27, 2005, 06:44 PM

MarkCollette

Jul 27, 2005, 07:42 PM

All of which are just bits, and handled by the binary patching. I'm not talking about code changes, I'm talking about a system that takes a set of files that are labeled "iPhoto 5.0.3" and another set called "iPhoto 5.0.4" and figures out bit-for-bit what's different. That would catch, well, everything :)

But in any reasonably large (or cross-platform) application there tend to be separate builds for different architectures or uses, like iPhoto bundled with the OS versus iPhoto bundled with iLife, etc. So there have to be config files somewhere saying which bits get assembled for which target. So the multiple-file-binary-diff process has to tie into that somehow. It's not just a case of diffing everything, it's diffing per target. Plus, as we said before, it's also diffing per original release. So if there are 3 targets and 4 previous releases, then that's 12 diffs. My point before was that with code it's straightforward, but with all the ancilliary config files that differentiate targets, those have to be tracked and handled, which the diff has to have the complexity of knowing about too.

And they won't be handled by full-file patching, anyway. In those cases, it's either a) the installer's job to upgrade or erase them, or b) the app's job to gracefully handle older formats. Either way, it's a separate issue from binary patching.

But they don't use installers for most things on the Mac. You drag and drop the bundle to where you want it, and just run it. If there's some special conversions that have to happen, then they're executed on the first run of the application. It's the patcher that requires an installer. Plus, for the user, it's easier for them to download version x+1 to their desktop and run that side by side with the previous version x for a while, or at least be able to fall back to version x, whereas if you patch, in place, version x to x+1, then there is no easy downgrade path.

Also what happens if there's a power failure part way through patching.

I *hope* they don't have debugging symbols included in those builds! In case they do, though, the name change would only be in one place (the symbol table) and thus only add a few dozen bytes to the binary patch :)

With Objective-C's message passing by name, if you change the name sufficiently, then its place in the table may well change, and so every referer still changes. It would be the same issue if one called a different method, like going from a shallow copy to a deep copy, etc.

Maybe it would help to think of it a different way: the binary patching would basically just be a more efficient file copy than the file copy that the installer/Software Update performs *already*. Everything else remains identical, it's just that you get a file copy without having to actually download the original file. It could literally be dropped into place without affecting the rest of the entire update utility, very easily. If it were any other way, then it *would* be a QA nightmare and not worth the risk. It's the self-contained, modular, narrow-field-of-focus approach to binary patching that makes it work so well in patching/updating/installing land and keeps the QA and risks to a minimum.

I agree, once the infrastructure is all in place, then it should just work. But QA still has to test every single scenario, whether or not it should work.

Just to keep this back on track wrt. iPhoto, in this case, yes, getting the patch out the door to fix corruption issues was paramount. With a binary patching method in place already, they could've just released the full version to Software Update, then generated the patches afterwards. The initial adopters that *had* to have the update immediately would have to suffer through the full download, but they'd get it ASAP, which is all they care about. Those that waited would still get the patch, but would get the smaller binary-diff patch (once they were done generating), which will make them happy since the time-to-download is a larger (relatively) issue for them.

Very good point.

Mathew Burrack

Jul 27, 2005, 08:18 PM

But in any reasonably large (or cross-platform) application there tend to be separate builds for different architectures or uses, like iPhoto bundled with the OS versus iPhoto bundled with iLife, etc. So there have to be config files somewhere saying which bits get assembled for which target. So the multiple-file-binary-diff process has to tie into that somehow.

I guess I'm not understanding your point, since I don't see why it would have to. The binary diff replaces a straight file copy; all of the bookkeeping you're talking about, it seems to me, happens at a higher level regardless of how the new files get to where they need to be.

Plus, as we said before, it's also diffing per original release. So if there are 3 targets and 4 previous releases, then that's 12 diffs.

Actually, as I stated before, it only makes sense to go back to one release, so by your math only 3 diffs. Further, are there really entirely separate installs of iPhoto depending on whether it came with the OS or it came with iLife? I thought Apple was better than that (although I can certainly think of some companies that aren't *cough*) If it came with your computer, it should've been just as if you had done a vanilla install of OS X and then installed iLife, which would result in an identical app.

My point before was that with code it's straightforward, but with all the ancilliary config files that differentiate targets, those have to be tracked and handled, which the diff has to have the complexity of knowing about too.

Again, I guess I'm just not understanding your point, b/c in my mind the diff *wouldn't* have to know about them, and thus the complexity doesn't exist.

But they don't use installers for most things on the Mac. You drag and drop the bundle to where you want it, and just run it.

Yes, but we were talking about the specific case of Software Update, which by nature is meant to deliver incremental upgrades to existing software and contains its own internall install routines, which is where the patcher would go.

If there's some special conversions that have to happen, then they're executed on the first run of the application.

They'd happen either way. No change here...

Plus, for the user, it's easier for them to download version x+1 to their desktop and run that side by side with the previous version x for a while, or at least be able to fall back to version x, whereas if you patch, in place, version x to x+1, then there is no easy downgrade path.

Do users have that option with iPhoto 5.0.4? If so, then it's certainly not through Software Update, and thus whatever separate download path they have now could still be made available. Binary patching doesn't preclude that.

Also what happens if there's a power failure part way through patching.

What happens when there's a power failure when running Software Update? Actually, I can answer that one--hosed install. (P.S. Never have guests over while you're running an OS X update, since they might have a tendency to close your laptop while the update is running, thus ruining the entire OS X install. arrrrrgh) My point is that the issue is separate from binary patching and thus has no bearing one way or the other as to whether binary patching should be used. (Actually, binary patching can be *safer*, since you're patching to a copy of the file typically before overwriting the original, so there's a smaller window for corruption to occur).

With Objective-C's message passing by name, if you change the name sufficiently, then its place in the table may well change, and so every referer still changes. It would be the same issue if one called a different method, like going from a shallow copy to a deep copy, etc.

Ah, I didn't realize that. I was still in a C++ mindset. Still, bits moving about in a file, as long as they are in large chunks, are easily handled by a binary diff, as are lots of tiny bits changing. The only time binary diffs start to not be efficient are either when over 75% of the file has changed or in pathological cases (every other byte in the file changed).

I agree, once the infrastructure is all in place, then it should just work. But QA still has to test every single scenario, whether or not it should work.

If we went by what QA *has* to do, they'd never finish, there simply isn't enough time in the world to test every code path and every combination ever. QA's job is to test the most plausible and likely scenarios to make sure they work, in an attempt to catch as many problems as possible. Run a binary patcher through the QA ringer (say, 100 million random files) and make sure it's near-bullet-proof, and the chance of the binary patches being a problem compared to *other* things to test become so small that it's better for QA to spend time testing other things. Will the chance of binary patching having a flaw ever be zero? Of course not, but that's true of *any* software. It's a risk you have to take--the trick is to get that risk as close to zero as possible, so QA can spend their time tracking down more worthwhile bugs.

If I seem overzealous on this topic, I apologize. It's because I'm a firm believer in the theory that if you're going to do something at all, do it *right*, and this seems to be an issue that, at least IMHO, a large portion of the industry still seems to ignore for some reason.

--mcn

stcanard

Jul 27, 2005, 10:58 PM

You two may agree now, but that doesn't stop iPhoto from sucking. I'll bet the 3 programmer interns Apple has working on iPhoto are constantly bickering between their cubicle walls about what would be the best way to do this or that, and that (in addition to their general incompetence) explains the horrible hodgepodge design.

iPhoto works great for it's target audience. An amateur like me who want to store and organize a few thousand photos.

If you're doing huge libraries then you should really get a professional program.

Whatever stability issues you have would appear to be something wrong with your setup. Its probably worth investigating to find out why.

Applespider

Jul 28, 2005, 03:44 AM

You two may agree now, but that doesn't stop iPhoto from sucking.

For you... there are many who find it fine. Incidentally, there's been a lot of recent chat on the Apple Discussions about the 'suckiness' of iPhoto being related to the size of a particular xml file in iPhoto. On a 6GB library, it should be around 40MB or less. But there are some people - those with the extreme suckiness - whose version of that file is 300MB plus on a 2GB library. Someone tied it down to particular Nikon and Pentax cameras and their EXIF data which used to be 1 KB a picture and now imports as 40KB per image thus bloating this file.

artifex

Jul 28, 2005, 05:46 AM

Does anyone else get really excited when their are iPhoto updates? I don't think this really will fix much for me but hey any fixes to iPhoto are just as exciting as Security updates and even OSX updates! Hell iPhoto updates are better then those Mac Mini or iBook updates!

I have yet to open iPhoto (or Garageband, or iChat). But I'm sure to download the updates anyway, because I never know when core components might be updated, and therefore used by someone else's apps. (Core, not Core, I mean... oh, you know what I mean.)

Stormyguy

Jul 28, 2005, 06:26 AM

I don't know GraphicConverter, but I think iPhoto/Photoshop work extremely well together. I bring everything into iPhoto to start and do light editing there like slight color and brightness tweaking. If it needs major levels, color, roto or other work, I open it Photoshop (which iPhoto makes very easy to do). After I save and close the image in Photoshop, it refreshes in iPhoto.

Sorry if I sound amateur here but how are you working the two programs together like that?? Is there some "option click" or "apple click" to open up the pic you're on in iPhoto in Photoshop?? Again, sorry, but info pls as this would be v.handy to know!

My own opinion on iPhoto?? Well mine is about as slow as you can get - it feels painfully so - and I get the odd random crash, be it on my iMac G4 or my PB. Image rotation takes an absolute age, yet I have pals with PC's with software that is instant for things like this, I wish I understood just why that is.

I've actually taken to using some of the Canon software bundled in with my 20D - it's not half as intuitive as iPhoto but it's quicker and I do get the added benefit of being able to analyse extra data like focusing points and one or two other things.

Applespider

Jul 28, 2005, 07:14 AM

Sorry if I sound amateur here but how are you working the two programs together like that?? Is there some "option click" or "apple click" to open up the pic you're on in iPhoto in Photoshop?? Again, sorry, but info pls as this would be v.handy to know!

In the iPhoto preferences, there are options for setting whether you want to edit a picture in the iPhoto edit mode, in a new window within iPhoto or to open in an external application (select your choice of app).

Set that to Photoshop and any images you click on will open in Photoshop. When you save them in PS, the amends will be saved back into iPhoto and 'Revert to Original' option remains too. If you've been working in layers in Photoshop though, you do have to make sure that you flatten them before saving back to iPhoto.

alex_ant

Jul 28, 2005, 07:30 AM

For you... there are many who find it fine. Incidentally, there's been a lot of recent chat on the Apple Discussions about the 'suckiness' of iPhoto being related to the size of a particular xml file in iPhoto. On a 6GB library, it should be around 40MB or less. But there are some people - those with the extreme suckiness - whose version of that file is 300MB plus on a 2GB library. Someone tied it down to particular Nikon and Pentax cameras and their EXIF data which used to be 1 KB a picture and now imports as 40KB per image thus bloating this file.
In other words, iPhoto sucks. That is an absolutely ridiculous problem for which there is no excuse. Do a google search for 'iphoto sucks' - I am hardly the only one of this opinion. That Picasa is FREE and MUCH faster and MUCH less problematic only adds insult to injury.

Btw I don't have a Nikon or a Pentax.

alex_ant

Jul 28, 2005, 07:33 AM

iPhoto works great for it's target audience. An amateur like me who want to store and organize a few thousand photos.
Once you accumulate a few thousand, I hope you don't take any more after that because if you do, your problems will rapidly multiply.

If you're doing huge libraries then you should really get a professional program.
I have one, it's called Picasa and it's free and a lot faster on a 550MHz AMD K6 with 100,000 photos than iPhoto is on a 550MHz G4 with 2,000.

Whatever stability issues you have would appear to be something wrong with your setup. Its probably worth investigating to find out why.
iPhoto's bugginess and instability is well-known. I don't care WHY iPhoto is so buggy, I am only interested in seeing the bugs disappear.

alex_ant

Jul 28, 2005, 07:34 AM

My own opinion on iPhoto?? Well mine is about as slow as you can get - it feels painfully so - and I get the odd random crash, be it on my iMac G4 or my PB. Image rotation takes an absolute age, yet I have pals with PC's with software that is instant for things like this, I wish I understood just why that is.
That's impossible. All Apple software is perfect. You must be doing something wrong.

(This post on behalf of the Apple apologists)

Stormyguy

Jul 28, 2005, 07:43 AM

In the iPhoto preferences, there are options for setting whether you want to edit a picture in the iPhoto edit mode, in a new window within iPhoto or to open in an external application (select your choice of app).

Set that to Photoshop and any images you click on will open in Photoshop. When you save them in PS, the amends will be saved back into iPhoto and 'Revert to Original' option remains too. If you've been working in layers in Photoshop though, you do have to make sure that you flatten them before saving back to iPhoto.

Awesome, thankyou! (Must learn to dig around in prefs a bit more)!

That's impossible. All Apple software is perfect. You must be doing something wrong.

(This post on behalf of the Apple apologists)

:)

Applespider

Jul 28, 2005, 07:47 AM

(This post on behalf of the Apple apologists)

Hang about...stop being inflammatory. You'll always find more posts on a Google search for something that 'sucks' that something that doesn't since as we all know, it's human nature to complain and only post for help/solutions when you have a problem

I wasn't being an apologist and I'm not saying Apple software is perfect. I'm pointing out that although some people have problems, others are perfectly fine even with several thousand pictures. Since some installations seem to work well while others are 'sucky', there must be something causing the bugs. I was trying to point out that some people have identified some potential causes which might help these bugs get fixed - not that those bugs are perfectly acceptable.

Picasa is impressive although I doubt they'll port it over anytime soon.

alex_ant

Jul 28, 2005, 09:21 AM

Hang about...stop being inflammatory. You'll always find more posts on a Google search for something that 'sucks' that something that doesn't since as we all know, it's human nature to complain and only post for help/solutions when you have a problem

I wasn't being an apologist and I'm not saying Apple software is perfect. I'm pointing out that although some people have problems, others are perfectly fine even with several thousand pictures. Since some installations seem to work well while others are 'sucky', there must be something causing the bugs. I was trying to point out that some people have identified some potential causes which might help these bugs get fixed - not that those bugs are perfectly acceptable.

Picasa is impressive although I doubt they'll port it over anytime soon.
I'm going to be inflammatory because Apple deserves it here. Nobody is perfectly fine with several thousand pictures in iPhoto - not one single person. They just think they are because they've never used Picasa (because they have a Mac, not a Windows machine) and don't know what they're missing. They think that 20-second startup times are normal, or that context switching should bring the entire app to a standstill while it swaps itself in and out of active memory, or whatever the hell it's doing, or that enabling live folder counts in the preferences should slow down the whole app by a factor of 10. I'm aware of the recommendation to "rebuild my library" or whatever but why should I have to sit there for an hour to let iPhoto rebuild something which it should have never broken in the first place? It's just bad design.

What I absolutely hate is when iPhoto crashes and corrupts my library and people accuse ME of doing something wrong. There is something wrong with it, something very wrong with it, and it's time that after 3 1/2 years, Apple fixed it. I love some of the other iApps, I think they're great, but iPhoto is broken and damaged and designed by idiots who think that, for example, JPEG lossy rotation is fine, it's OK to copy all your photos into some nonsense folder structure, it's OK to use a slow-as-hell XML database, it's OK to cache the ENTIRE contents of your library in RAM even if it eats up an entire GIGABYTE of memory, it's OK to release an update that fixes a bug while creating an even worse one, etc. I used to browse thumbnails in 32MB. If iPhoto isn't the #1 supreme example of software bloat and general developer incompetence, I don't know what is.

Picasa, iView, Extensis Portfolio, QPict, Cumulus, Shoebox, they're all faster and more stable than iPhoto and can handle way more photos. Half of them even cost less. iPhoto works well if you've got maybe 1500 photos and you plan to never take any more after that.

Applespider

Jul 28, 2005, 02:07 PM

I'm going to be inflammatory because Apple deserves it here. Nobody is perfectly fine with several thousand pictures in iPhoto - not one single person. They just think they are because they've never used Picasa (because they have a Mac, not a Windows machine) and don't know what they're missing. iPhoto works well if you've got maybe 1500 photos and you plan to never take any more after that.

I assure you that if my iPhoto was doing that I'd be shouting 'it sucks' too. But I have 8000 images in iPhoto which take up about 12GB of space. It takes 2 bounces in the dock and then under 5 seconds of 'loading' on a 15" 1.25 Powerbook (with 1.25GB of RAM admittedly). It closes equally quickly (tho I have read about people waiting 5-10 minutes. I've never rebuilt my library and it's been upgraded through iPhoto 2/4/5 - perhaps I'm just lucky!
I don't use that many albums but I have several slideshows and iPhoto books and it works for me.

I agree re the lossy rotation - but I tend to edit using Photoshop linked through the iPhoto prefs. Picasa wasn't out for PC when I had mine but I have used it on a friend's PC and I like it. If it was available for the Mac, I'd probably experiment between the two for a while. Pre-Tiger, the filing system used to bug me. With Spotlight and Automator actions though for finding images when I can't be bothered opening iPhoto to look for a single image to use in another app, it doesn't bother me any longer.

alex_ant

Jul 28, 2005, 03:55 PM

Applespider

Jul 28, 2005, 04:13 PM

You HAVE been lucky. Your library will get corrupted eventually, it's only a matter of time.

Yeah... after defending it all this thread, I'll probably open it tomorrow and it will go boom! Touch wood and all that!

I want to like iPhoto and the reason I kvetch so much about it all the time is because I think that it's an app that's worth kvetching over.

True... let's hope that Apple can get it fixed for everyone. It is a great app when it's working properly!

xxxray

Jul 29, 2005, 01:40 AM

I'm using Panther 10.3.9 and iPhoto 5.0.3. Can't update to iPhoto 5.0.4. Get same message as you. GarageBand 2.0.2 did update, though. Let me know if you figure it out.

If I go to Software Update it tells me there are no updates I need. I'm still on 5.0.2.

I downloaded 5.0.4 from the Apple site, but it won't install, telling me there is no eligible software in /Applications.

Same for GarageBand 2.0.2 (not that I use it, but I like to keep things up to date).

Anyone else getting this?

manu chao

Jul 31, 2005, 06:40 AM

You HAVE been lucky. Your library will get corrupted eventually, it's only a matter of time. I don't disbelieve that iPhoto works well with 8,000 images in 1.25GB w/ 1.25GHz, but that's a lot of computer just to run a photo album. The Mac laptop version of that computer still starts at around $1000. I would like to upgrade my nearly 4 year old Powerbook, but I can't justify the huge price of a new computer just to run a photo album which shouldn't even need that kind of speed. Everything else I do is tolerable on it. iPhoto could be a GREAT app if only this and that were fixed. I appreciate what it tries to do, which is put my photos in a flexible, easy-to-use database, but there's just no excuse for its problems, and I can't believe they haven't been addressed yet. I want to like iPhoto and the reason I kvetch so much about it all the time is because I think that it's an app that's worth kvetching over.

The slowest computer Apple sell's has 1.25Ghz (1.2Ghz since last October) and anybody who runs OS X with less than 1GB is a terrible cheapskate (or on a really tigtht budget), so it is not a lot of computer. If you want your Mac to last 3+ years and still run most new programs fine, you have the most high-end version, it has always been like this, I am sorry.

And to 'just run a photo album' which has to handle hundreds of MB while you scroll (thousands of photos at an uncompressed size, and yes to display them they have to be decompressed, of 100 to 200kB) you unfortunately need some processing power, memory and/or a fast harddrive.

Abstract

Jul 31, 2005, 07:42 AM

I read the 1st page of this thread, and I have now read the 4th/current page.

All I have to add is that iPhoto does suck, and is so flawed that it only takes a little misstep for your Library to be completely unrecognizable by iPhoto. "But you're not SUPPOSED to rename the files/folders, or touch any folders created by iPhoto." Says who? Using iPhoto is like walking in a glass floor --- it's all going to cave in eventually. Nothing in the electronics or computer industry should be making anything that can't withstand a certain user tolerance, because it's users have all sorts of backgrounds in computers. Besides, how many consumer-level apps have directories that can't be renamed? It's so brittle.

And what happens when iPhoto can't find your library? It loses all the titles you spent so much time giving your photos. Maybe if it stuck with the phots rather than being some titling scheme exclusive only to iPhoto, it would be more practical.

Go check the Apple Discussion and Support message board. It's full of Libraries that just don't work with iPhoto anymore, even if they rename it again and give it the same name as before.

andiwm2003

Jul 31, 2005, 08:35 AM

i didn't read all posts in this thread. sorry if this already came up.

i'm a typical home user of iphoto. i have about 1000 photos and i add about 30 photos a month. so speed and size of the library is no problem for me. i love the intuitve UI of iphoto. i haven't had any problem with iphoto yet.

there is only one thing i don't get about iphoto: why can't i drag and drop pictures from iphoto into mail, photoshop or other programs? i would expect that i drag a picture from iphotos "organize" view onto the PS icon in the dock and PS opens with this pic. same for mail. (I don't want to use ps a standard program in iphoto, so the preference settings is not the solution. it wouldn't help with mail anyway).

the other thing is: i would never put professional pics or even a seriuos hobby collection into a filesystem like iphoto. the more professional systems we use at work for files seem to be a lot more robust.
is there any tool out there that somehow consolidates a iphoto library into a standardized file system with files named like their titles and folders named like the albums? in that case you could burn your library every now and then onto a dvd including the titles and the album structure. it would also help to transfer all your file to a windows computer. i would be willing to pay a reasonable shareware fee for a tool like this.

andi

Lacero

Jul 31, 2005, 08:41 AM

All I have to add is that iPhoto does suck, and is so flawed that it only takes a little misstep for your Library to be completely unrecognizable by iPhoto.iPhoto is trying to be all things to all people, so it ends up being a lousy for photo database collection AND a lousy image editing program.

For the serious photo user, try Extensis Portfolio or Adobe Bridge. As far as photo editing, people should just learn to use Photoshop. It is like so much better.

broken_keyboard

Jul 31, 2005, 08:57 AM

I think iPhoto and Mail were both ruined by their last major version updates.

~Shard~

Jul 31, 2005, 10:39 AM

The slowest computer Apple sell's has 1.25Ghz (1.2Ghz since last October) and anybody who runs OS X with less than 1GB is a terrible cheapskate (or on a really tigtht budget), so it is not a lot of computer. If you want your Mac to last 3+ years and still run most new programs fine, you have the most high-end version, it has always been like this, I am sorry.

I know many people who would disagree with you. It has not "always been like this". A co-worker of mine runs all the latest apps he needs just fine on his 4-year old 400 MHz PowerBook - upgrading to Panther, and then Tiger, actually made his system faster. All he has ever done to his system is upgrade the memory from 256MB to 512MB. My brother is running Tiger on a G3 iBook just fine, and my sister-in-law runs Tiger on a 800 MHz G4 iMac with 512 MB. She is a graphic design artist and a power user of Adobe CS and the Macromedia suite, and her setup is more than adequate for her. I could go on and on, but I think you see the point.

As for calling people without a GB of RAM "cheapskates", that's not very fair, and there is no need to insult people in this manner. There are a variety of reasons (monetary or otherwise) why people don't have 1 GB of RAM in their machines, plain and simple. :cool:

~Shard~

Jul 31, 2005, 10:44 AM

iPhoto is trying to be all things to all people, so it ends up being a lousy for photo database collection AND a lousy image editing program.

I agree, iPhoto still needs a lot of work in my opinion. And for me, I'm one of those people who cannot justify buying iLife simply because I don't want to pay $70 CAD for iPhoto - iTunes is free, I don't use iMovie, iDVD or GarageBand. ;) So, if I get iLife '07 free with my next Mac in a couple years, great, but I can't see myself paying for it anytime in the near future.

people should just learn to use Photoshop. It is like so much better.

Like, totally better, like!!! :p ;)

alex_ant

Jul 31, 2005, 10:55 AM

The slowest computer Apple sell's has 1.25Ghz (1.2Ghz since last October) and anybody who runs OS X with less than 1GB is a terrible cheapskate (or on a really tigtht budget), so it is not a lot of computer. If you want your Mac to last 3+ years and still run most new programs fine, you have the most high-end version, it has always been like this, I am sorry.

And to 'just run a photo album' which has to handle hundreds of MB while you scroll (thousands of photos at an uncompressed size, and yes to display them they have to be decompressed, of 100 to 200kB) you unfortunately need some processing power, memory and/or a fast harddrive.
My Mac cost $2300 3 1/2 years ago and it's not expandable beyond 1GB. It has 768MB in it now. Even if it had 1GB it would still be at a huge deficiency in iPhoto. Yet iView (and others) still run perfectly acceptably on it with 10 times as many photos as I have in iPhoto (coming up on 10,000). Hell, they run just fine with 100,000 photos and half the RAM! The truth of the matter is that iPhoto is a poorly implemented resource hog.