Progress Bars - Why are they never "useful"?

I'm sure many people have noticed this before and I can't be the only one to be annoyed by this, but progress bars (I'm referring typically to those that display the progress of the execution of multiple tasks rather than single tasks - i.e not an image upload) rarely offer a true representation of the progress and time taken.

Progress bars are able (or should be able) to tell us two things.

1. 
   

   How far through executing a certain procedure the computer is.

   
   


2. 
   
   

   Approximately what pace it is progressing (the speed it fills up - a visual indication).

   
   

However, the nature of most progress bars is somewhat 'stuttery' and I gather the reason why is something like my diagram below:

For some reason progress bars seem to be divided into equal sections for the number of tasks to be completed, so in my example, 33% will be given to a task that takes roughly 6 times as long as the other 66%, giving a false representation of the progress made.

What I think progress bars (continuing my example) should be like is as follows:

Why don't the majority of progress bars seem to follow this example? And furthermore, why can't progress bars fill up at an even pace, rather than halting on one particular task for 10 minutes, leaving the user clueless as to whether the installer has crashed or if its processing a lot of information. If it's the latter, why is that process not broken down further to be represented on the progress bar?

Answer

You think that's bad? In some cases, progress bars aren't even tied to anything in the first place! They just display a scrolling animation to try and soothe the user.

Why is this? Well, I don't know installer tools well, but from what I've seen, most off-the-peg progress indicators rely purely on the number of commands in an install script, and don't let developers attach extra 'time' or 'weight' to anything particularly time-consuming.

What's more, estimating installation time isn't trivial. Traditionally, installers just used to copy files, and could therefore just set the progress bar to reflect the proportion of bytes shifted, but modern installers are more complicated. An installer might have to check if certain libraries are present on the client machine, or connect to the internet to check for updates. These sorts of things make building a truly useful progress bar all the harder, and without the will to address the problem, it's unlikely anyone will address the challenge.

That's not to excuse badly implemented progress indicators, though. One of the biggest problems with these 'non-linear' progress bars is that they make it very hard to tell when an installer has crashed, or merely chugging through a large task very slowly. This could prompt the user to close an apparently 'crashed' installer prematurely, which risks damaging the operating system or complicating future installs. In today's applications, that's just not acceptable.