What about having it actually correlated to progress?
Any part of a process which has variable time or is at all out of your control is going to fuck it up.
More often we use progress bars to represent progress through a multi-step process, each one of indeterminate duration. This IMHO is a mis-use of the progress bar.
A far better way to do it is to show the user the steps you are moving through, and have an individual progress bar for each (if performance is expected to be linear), or simply an activity indicator. Check/grey items out as they become completed.
[edit] Another note: A lot of times progress bars are not backed up by correct code. For example, if you are, say, compressing a bunch of files - the progress bar should not represent how many files you have finished, but rather the size of those files. Too often progress bars are used to signify a quantity that is not closely correlated with TIME.
Another example of this is online checkout paths. Obviously the fewer pages and fewer form fields a user has to fill out, the better, but even if its just a single page and a confirmation page, I /always/ prefer checkout paths which list the number of steps and number of pages at the top, and indicate how far along in the process I am. It's always so exasperating when online shopping when you think you're about to make a purchase, only to be taken to an unexpected "confirm everything you just did" page, followed by two order confirmation pages. Its not the same as an installer or other crunching process, but granulated progress bars get you a surprising amount of mileage in many linear processes you can put your users through.