Wherever possible, progress bars should be determinate, even if the proportions allocated to subtasks aren’t exact. Programmers often don’t do this, because they think — incorrectly — that inaccurate progress feedback is worse than none at all. (Giving an estimate of time remaining is a whole different kettle of fish.)

Progress of a long-running task, where the user is likely to be interested in its completion, should be shown in a dedicated progress window whenever there isn’t another relevant window to show it in. And a dedicated progress window should always include a progress bar, not a spinner, even if the progress is unfixably indeterminate.

There’s plenty more advice that could be written about progress bars, none of which is in the Human Interface Guidelines yet. (For example, a common error in Gnome software is to use a progress bar as a gauge of something other than progress.)

That said, I’ve always thought pulsing was reserved for cases that should have a progress indication, but can’t. Like my browser downloading something that didn’t give a Content-Length. Or is it wrong for that, too?