4 ms·

GNU yes is not doing anything crazy imo why are the BSDs not using GNU yes if it’s this much faster?

yung_steezy 4y ago
BSD devs tend to prioritise clean code over speed. I'm not certain of the implementation details here but their approach does make openbsd coreutils a more pleasant read than the GNU coreutils.
- trelane 4y ago
  Do the various BSD equivalents have to also work on other, esoteric OSen, or do they generally tend to fork a new version only to run on just on that flavour of BSD?
  - bauruine 4y ago
    Not exactly an answer but OpenBSD sometimes has different portable versions of their software. e.g. https://www.openssh.com/portable.html https://www.openssh.com/portable.html
  - pxc 4y ago
    Idk about the stuff that's normally ‘included’ in the distribution (base install of the OS), but NetBSD's package manager supports a ton of platforms. I've used it on Linux and macOS.
- rahen 4y ago
  Also clean code usually results in compact code, which used to be effectively the same as fast code for the machines BSD was initially developed for. I wouldn't be surprised if the BSD coreutils were more performant on older machines with small memory, buffers and prefetch queues (sometimes just a few bytes) than their GNU counterpart.
  - masklinn 4y ago
    I would be very surprised. An 8k buffer is hardly a large imposition, and less syscalls has always been hugely beneficial.
masklinn 4y ago
Because BSDs don't use the GNU userland? As to why they don't use similar techniques, probably because they historically didn't really care enough about the performances of yes(1) to bother with it. FreeBSD has since added output buffering to yes(1), you can see the difference between openbsd yes(1)[0] which remains utterly naïve and freebsd yes(1)[1] which uses an 8k internal buffer. [0]: https://github.com/openbsd/src/blob/master/usr.bin/yes/yes.c https://github.com/openbsd/src/blob/master/usr.bin/yes/yes.c [1]: https://svnweb.freebsd.org/base/head/usr.bin/yes/yes.c?view=markup https://svnweb.freebsd.org/base/head/usr.bin/yes/yes.c?view=...
- mtlmtlmtlmtl 4y ago
  Amusingly, the OpenBSD one remains completely naïve, but still uses pledge for privilege dropping.
  - midislack 4y ago
    It's not naive, it's correct. GNU's focus is on features, kitchen sink style, performance tuning, etc. If that's what you want, it's for you. OpenBSD is focused on correctness. It's not correct to use hacks and buffering in tools to increase performance. That should be handled at the syscall interface or in the kernel or whatever.
    - dizzant 4y ago
      Can you expand on why you think performance hacking degrades correctness? As I understand it, “yes” (with no arguments) is supposed to output “y\n” continuously until terminated. Throughout/latency are unspecified, admitting various implementations with various concerns, like GNU’s focus on throughout vs BSD’s focus on latency/simplicity. Even an implementation that took 10 seconds between each output could be desirable for some use cases! Is that version of “yes” less correct?
    - guenthert 4y ago
      The case can be made that, given that kernel code tends to be more difficult to write and debug and is inherently security critical, there ought to be less of it. If the buffering can be generalized then it ought to be in a library to be shared, otherwise the application is the right place.
kzrdude 4y ago
When does the speed of yes matter?
- liftm 4y ago
  I've misused it as a load generator before: yes '{"some":"json"}' | kafkacat -P -t bleh (Though in my case, ~100 MB/s were enough.)
- DonHopkins 4y ago
  There's a whole best-selling book about it: https://en.wikipedia.org/wiki/Getting_to_Yes https://en.wikipedia.org/wiki/Getting_to_Yes
  - gmfawcett 4y ago
    Well played. :) Interestingly, if I listed their negotiation principles here in a blind test, you might think they were about software development: - separate the people from the problem - focus on interests, not positions - invent options for mutual gain - insist on using objective criteria I'd hire that engineer!
- chongli 4y ago
  It doesn't, 99.9999% of the time. But there's probably someone, somewhere, who uses it in some crazy huge obscure script, who appreciates the work people put into optimizing it.
  - lupire 4y ago
    There is a program in the real world that consumes a line of input and processes it, faster than a naive yes can emit it?
    - Brian_K_White 4y ago
      ding ding ding But then again, maybe the purpose is to swamp the input, maybe for testing, so the more the better, so, you never know and it's wrong to decide what all users don't need.
GuB-42 4y ago
I didn't try it but I think it would be relatively straightforward to compile GNU tools on BSD. But generally GNU tends to focus on performance and features while BSD focuses on simplicity. GNU having ridiculously complex code to do trivial things is kind of a meme. And also, most people don't need a ridiculously fast "yes". Usually, when you want a fast stream of bytes, for example to fill up some space, /dev/zero is a better option.
- bauruine 4y ago
  >GNU having ridiculously complex code to do trivial things is kind of a meme. One of the reasons is that GNU had to reimlmement UNIX tools as GPL code. How do you reimplement something trivial without it looking as the original to avoid copyright claims? One of the solutions is to implement it as complicated as possible.
- rahen 4y ago
  For the trivia, GNU "true" is an abomination which even includes a cornercase that returns "false". Meanwhile, its BSD version essentially sums up to "return 1". Same for much of the GNU code: - echo: https://gist.github.com/fogus/1094067 https://gist.github.com/fogus/1094067 - cat: http://9front.org/img/longcat.png http://9front.org/img/longcat.png

BSD devs tend to prioritise clean code over speed. I'm not certain of the implementation details here but their approach does make openbsd coreutils a more pleasant read than the GNU coreutils.

trelane 4y ago
Do the various BSD equivalents have to also work on other, esoteric OSen, or do they generally tend to fork a new version only to run on just on that flavour of BSD?
- bauruine 4y ago
  Not exactly an answer but OpenBSD sometimes has different portable versions of their software. e.g. https://www.openssh.com/portable.html https://www.openssh.com/portable.html
- pxc 4y ago
  Idk about the stuff that's normally ‘included’ in the distribution (base install of the OS), but NetBSD's package manager supports a ton of platforms. I've used it on Linux and macOS.
rahen 4y ago
Also clean code usually results in compact code, which used to be effectively the same as fast code for the machines BSD was initially developed for. I wouldn't be surprised if the BSD coreutils were more performant on older machines with small memory, buffers and prefetch queues (sometimes just a few bytes) than their GNU counterpart.
- masklinn 4y ago
  I would be very surprised. An 8k buffer is hardly a large imposition, and less syscalls has always been hugely beneficial.

masklinn 4y ago

Because BSDs don't use the GNU userland? As to why they don't use similar techniques, probably because they historically didn't really care enough about the performances of yes(1) to bother with it. FreeBSD has since added output buffering to yes(1), you can see the difference between openbsd yes(1)[0] which remains utterly naïve and freebsd yes(1)[1] which uses an 8k internal buffer. [0]: https://github.com/openbsd/src/blob/master/usr.bin/yes/yes.c https://github.com/openbsd/src/blob/master/usr.bin/yes/yes.c [1]: https://svnweb.freebsd.org/base/head/usr.bin/yes/yes.c?view=markup https://svnweb.freebsd.org/base/head/usr.bin/yes/yes.c?view=...

mtlmtlmtlmtl 4y ago
Amusingly, the OpenBSD one remains completely naïve, but still uses pledge for privilege dropping.
- midislack 4y ago
  It's not naive, it's correct. GNU's focus is on features, kitchen sink style, performance tuning, etc. If that's what you want, it's for you. OpenBSD is focused on correctness. It's not correct to use hacks and buffering in tools to increase performance. That should be handled at the syscall interface or in the kernel or whatever.
  - dizzant 4y ago
    Can you expand on why you think performance hacking degrades correctness? As I understand it, “yes” (with no arguments) is supposed to output “y\n” continuously until terminated. Throughout/latency are unspecified, admitting various implementations with various concerns, like GNU’s focus on throughout vs BSD’s focus on latency/simplicity. Even an implementation that took 10 seconds between each output could be desirable for some use cases! Is that version of “yes” less correct?
  - guenthert 4y ago
    The case can be made that, given that kernel code tends to be more difficult to write and debug and is inherently security critical, there ought to be less of it. If the buffering can be generalized then it ought to be in a library to be shared, otherwise the application is the right place.

kzrdude 4y ago

When does the speed of yes matter?

liftm 4y ago
I've misused it as a load generator before: yes '{"some":"json"}' | kafkacat -P -t bleh (Though in my case, ~100 MB/s were enough.)
DonHopkins 4y ago
There's a whole best-selling book about it: https://en.wikipedia.org/wiki/Getting_to_Yes https://en.wikipedia.org/wiki/Getting_to_Yes
- gmfawcett 4y ago
  Well played. :) Interestingly, if I listed their negotiation principles here in a blind test, you might think they were about software development: - separate the people from the problem - focus on interests, not positions - invent options for mutual gain - insist on using objective criteria I'd hire that engineer!
chongli 4y ago
It doesn't, 99.9999% of the time. But there's probably someone, somewhere, who uses it in some crazy huge obscure script, who appreciates the work people put into optimizing it.
- lupire 4y ago
  There is a program in the real world that consumes a line of input and processes it, faster than a naive yes can emit it?
  - Brian_K_White 4y ago
    ding ding ding But then again, maybe the purpose is to swamp the input, maybe for testing, so the more the better, so, you never know and it's wrong to decide what all users don't need.

GuB-42 4y ago

I didn't try it but I think it would be relatively straightforward to compile GNU tools on BSD. But generally GNU tends to focus on performance and features while BSD focuses on simplicity. GNU having ridiculously complex code to do trivial things is kind of a meme. And also, most people don't need a ridiculously fast "yes". Usually, when you want a fast stream of bytes, for example to fill up some space, /dev/zero is a better option.

bauruine 4y ago
>GNU having ridiculously complex code to do trivial things is kind of a meme. One of the reasons is that GNU had to reimlmement UNIX tools as GPL code. How do you reimplement something trivial without it looking as the original to avoid copyright claims? One of the solutions is to implement it as complicated as possible.
rahen 4y ago
For the trivia, GNU "true" is an abomination which even includes a cornercase that returns "false". Meanwhile, its BSD version essentially sums up to "return 1". Same for much of the GNU code: - echo: https://gist.github.com/fogus/1094067 https://gist.github.com/fogus/1094067 - cat: http://9front.org/img/longcat.png http://9front.org/img/longcat.png