The "triggers" seem to be the difference. The video shows it tailing strace, and only waking up the display and dumping data when it sees the poll() system call in the strace output.
Then they show a fancier example of a specific pattern of recvmsg(11,...) happening a specific amount of lines below poll(). That ends up showing the flow of data to a specific socket.
Or without triggers, it only shows you the latest when you tap the space bar or some other key.
pw has no tail -f functionality; it doesn't monitor whether a file that has reached EOF will start growing again. If you do pw < file, it will just read to the end and then exit. Or else stay running with pw -d, but without reading any more data. But it can make sense to do this:
tail -f logfile | pw
the main behavior change that pw will introduce is that during periods when the logfile is rapidly growing, it will prevent spewage to the terminal. It will only update when there is a lull in in the output exceeding the short timeout (default: 1 s), or else once every long timeout (default: 10 s). (These values were hard coded at first, then they became command line options, then dynamically adjustable too).
The development of pw was inspired by a discussion in the GNU Coreutils mailing list by a user wanting behavior along these lines from tail itself.
Then the other feature ideas came.
For instance pausing: we can suspend the display indefinitely. With tail -f, that's easy: you can just kill it. You can't kill a program that's taking input from a pipe without breaking the pipe, though. You can pause the terminal output, but not indefinitely without causing a backlog that could block the producing application, and when you resume, all the backlogged spewage will show.
I like the tool a lot. I think people are still generally a bit confused about what it is, and the beginning of the man page is quite mechanistic, describing the implementation and leaving it up to the reader to interpret why that is useful.
The reasons I like it are that it's "an interactive streaming text viewer", along the lines of a readonly text editor designed for presenting inhuman amounts of data in a way that's useful for us humans. Think of the times you want to use your favorite text editor to interactively search and inspect streaming data, but can't because the stream is continuous.
- doesn't stream characters to the screen so fast that humans can't read it
- allows for interactively searching the stream and showing context
- operates on a large ring buffer, so all of this can be done without ever attempting to read a fixed subset or the entire stream
Then they show a fancier example of a specific pattern of recvmsg(11,...) happening a specific amount of lines below poll(). That ends up showing the flow of data to a specific socket.
Or without triggers, it only shows you the latest when you tap the space bar or some other key.