1

yes produces a stream of "y" chars, or other requested.

If Unixen have a pseudodevice for random numbers, why not useful streams like this too?

Improve this question
3
  • 1
    You've asked the question the wrong way around, which is no doubt partly why people are objecting to it. A perhaps slightly better way around is to ask why, if Unices and Linux have a general purpose mechanism where any "useful stream" can be obtained from whatever program one cares to write to generate it, the pipe, is /dev/random a device file and not just a program that runs the very same CSPRNG in application space and writes to standard output. Not Why isn't everything like this all in the kernel? which is obvious, but Why is this in the kernel at all? Commented Apr 21, 2018 at 17:07
  • I think even by itself this question is quite valid and I feel it deserves a good answer. As for why is this in the kernel , it kind of has an answer here. This question is about the reverse statement i.e. why isn't everything in the kernel then Commented Apr 21, 2018 at 20:59
  • I agree that the question is valid and is formulated properly. The answers to Ankur S’s question illuminate the usefulness of having such a capability in the kernel. The only note I’d make is that /dev/random is not the best comparison; /dev/zero is the same as yes except it provides nulls instead of y bytes. Commented Apr 22, 2018 at 3:36

1 Answer 1

Reset to default
3

yes produces a stream of "y" chars, or other requested.

Precisely because of that. See yes(1) (which can repeat strings, not necessarily a single character - followed by newline).

It would be unpractical to have many devices, like /dev/repeatY to repeat Y, /dev/repeatO to repeat O etc.

Indeed, if you just want to get repeated zero bytes, consider /dev/zero (see zero(4))

BTW, on Linux, you could easily write your own kernel module implementing /dev/repeatY. But it is probably not worth the effort.

(so the why is also perhaps an historical reason)

Unixen have a pseudodevice for random numbers

These are probably much more difficult to get than a flow of constant bytes, and much more useful (and requires in practice some hardware support). See random(4) and this question. Read also myths about /dev/urandom

Improve this answer
7
  • Your point that the yes program can write arbitrary strings is a valid argument why there should be a yes program; not so much that there should not be a /dev/yes. It would be trivial to make a family of /dev/zero clones that provide arbitrary byte values. Commented Apr 22, 2018 at 3:36
  • Do we really want 256 different devices /dev/repeat0x00, /dev/repeat0x01, .... /dev/repeat0xfe, /dev/repeat0xff? I feel that would be too much (especially in the previous century) Commented Apr 22, 2018 at 6:02
  • I would like the freedom to say mknod /dev/zero c 42 0 and mknod /dev/yes c 42 121 (at least as a matter of principle).  The modification to the /dev/zero driver — and I estimate that it would be a one-line change — wouldn’t require the user / administrator to instantiate all 256 nodes in /dev. Alternatively, we could make /dev/repeat/0x00 through /dev/repeat/0xFF and then link to the ones we want.  There’s lots of clutter under /dev/char and /dev/disk, and it doesn’t bother anybody. Commented Apr 22, 2018 at 15:24
  • But if you want yes helloworld to be done by a device, it could be more difficult. I really think the reason is mostly historical: in the 1980s, 256 device inodes was not unsignificant Commented Apr 22, 2018 at 16:23
  • 1
    First off, "yes" doesn't repeat one byte, it repeats two: 0x79 ('y') and 0x0a ('\n'). Second, /dev/null and /dev/zero are clearly useful (though I'd argue that the contents of /dev/zero don't matter as much as the fact that they are infinite). The use cases for other devices in that vein are less clear, and that makes it harder to justify putting this functionality in the kernel. Commented Apr 23, 2018 at 18:31

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.