> Persistent progress indicators are known to cause performance degradation unless implemented carefully. Are you referring to that npm progress bar thing a fe

> Persistent progress indicators are known to cause performance degradation unless implemented carefully. Are you referring to that npm progress bar thing a few months back? I'm pretty sure the reason for that can be summed up as "javascript, and web developers". Anyway, he's not proposing progress bars by default, he's proposing a method by which you can query a process to see how far it's come. I think there's even a key combination to do this on FreeBSD. Or, for example, you could write a small program that sends a USR1 signal every 5 seconds, splitting out the responsibility of managing a progress bar: % progress cp bigfile /tmp/ And then the 'progress' program would draw you a text progress bar, or even pop up an X window with a progress bar.