Hacker News Reader

Comment by gigatexal | Hacker News Reader

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

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

[1]: https://svnweb.freebsd.org/base/head/usr.bin/yes/yes.c?view=...

Amusingly, the OpenBSD one remains completely naïve, but still uses pledge for privilege dropping.

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.

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?

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.

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.

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.

I would be very surprised. An 8k buffer is hardly a large imposition, and less syscalls has always been hugely beneficial.

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?

Not exactly an answer but OpenBSD sometimes has different portable versions of their software. e.g. https://www.openssh.com/portable.html

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.

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.

>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.

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

- cat: http://9front.org/img/longcat.png

When does the speed of yes matter?

There's a whole best-selling book about it:

https://en.wikipedia.org/wiki/Getting_to_Yes

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!

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.)

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.

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?

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.

yes | not

When you’re really impatient with prompts.

Reply on news.ycombinator.com