Slashdot Mirror
Ask Slashdot: Why Is It So Hard To Make An Accurate Progress Bar?
hyperorbiter writes "How come after 25 years in the tech industry, someone hasn't worked out how to make accurate progress bars? This migration I'm doing has sat on 'less than a minute' for over 30 minutes. I'm not an engineer; is it really that hard?"
Things are asyncronous. You wait for things from disk, ram, user input, over the network etc. How long it will take is non-deterministic. So a task composed of a bunch of these little pieces will be non-deterministic too.
If this is true (which it is), then logic would dictate that it is pointless to represent a progress bar in measurements of time.
Perhaps the larger question is how much longer are we going to continue acting stupid about it, rather than trying to make a clock out of it.
My favorite terrible progress bar was Internet Explorer, back in its early days of essentially being a renamed version of NCSA Mosaic. When attempting to load a site that wasn't available, the progress bar would slowly creep towards complete, despite the server being completely unresponsive. Then after a long while the browser would give up and stop the progress bar. Why on earth would the progress bar move if the server is completely unresponsive? Who programmed this? I would hope that they, like the inventor of Clippy, suffered a terrible death by fire.
We used an industrial strength version of cp in one product, which used DMA for much faster copy, and would write out status every 20 Mb that it could resume from in power loss, and would also, via shared memory variable, publish progress in bytes, all so you could have an accurate progress indicator.
Some people do know what they are doing.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.