3 ms·
>I've thought that dd's behavior could serve as a model for a new standard of interaction. Persistent progress indicators are known to cause performance degrada
by hueving 10y ago
>I've thought that dd's behavior could serve as a model for a new standard of interaction. Persistent progress indicators are known to cause performance degradation unless implemented carefully. And reality is, you generally don't need something to constantly report its progress even while you're not looking, anyway.
Progress bars by default are also garbage if you are scripting and want to just log results. ffmpeg is terrible for this.
- jff 10y ago> 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.
- erikbye 10y agoYes, C-t for SIGINFO, works on all BSDs (including macOS).
- hashhar 10y agoCheck this out. https://github.com/Xfennec/progress https://github.com/Xfennec/progress
- jff 10y agoThat's great! I think due to the way it's implemented it wouldn't be able to do progress reporting for e.g. "dd if=/dev/zero of=bigfile bs=1M count=2048", but that's a less common case than just cp'ing a big "regular" file.