-privileged programs when they need to. It is unsuitable for this
-purpose precisely because it enforces a strong separation between the
-calling and the called program, which is undesirable in this context.
+arbitrary programs like text editors as root (or other system users)
+when they need to. It is unsuitable for this purpose precisely
+because it enforces a strong separation between the calling and the
+called program, which is undesirable in this context.
+</p>
+
+<p>
+However, its use when restricted to running particular programs in
+particular ways is very similar to many common uses of
+<code>sudo</code><a href="footnotes.html#2" name="fr2">[2]</a>. <code>userv</code> is
+generally much better than restricted <code>sudo</code>, because it protects
+the called program much more strongly from bad environmental
+conditions set up by the caller. Most programs that one might want to
+run via restricted <code>sudo</code>, have not been designed to run in a
+partially hostile environment. <code>userv</code> allows these programs to
+be run in a safer environment and should be used instead.
+</p>
+
+<hr>
+
+<h2>
+<a name="s-stdinerr">6.6 Error handling and input streams (eg stdin)</a>
+</h2>
+
+<p>
+When the service program is reading from a file descriptor connected
+to the calling side, the fd that the service program refers to a pipe
+set up by <code>userv</code> and not to the same object as was presented by
+the caller.
+</p>
+
+<p>
+Therefore if there is some kind of error it is possible for the
+service-side fd to give premature end of file. If it is important to
+tell whether all of the intended data has been received by the service
+program, the datastream must contain an explicit end-of-file
+indication of some kind.