Hacker News Reader

Comment by billsmithaustin | Hacker News Reader

Those performance improvements make the code more complicated too. How fast does the yes command actually need to be?

I would desire the yes command to be as slow as possible while still performing its basic function of automatically confirming questions that come up during an installation.

This is because I clusterssh into 40 machines and hey I haven't formally accepted them into my known_hosts file yet so I type "yes" to acknowledge them, but whoops I had already accepted two of them so now they are spitting out the letter 'y' as fast as they possibly can and now I have to wait for all of that output to transfer over the wire onto my machine despite pressing ctrl+c a minute ago.

Then just use yes | head -50? There's no need to artificially slow it down when there are more reasonable means of capping output than relying on SIGINT.

yes | head -50 will not accept new signatures into known_hosts.

I'm not familiar with clusterssh, but assuming that it passes flags to ssh you can add `-o StrictHostKeyChecking=no`.

Of course, the parameter does what it says, but the security implications are really the same as for blindly yessing your way through. The best is to pre-populate your hosts file using ssh-keyscan.

Oh, thank you. I was unaware of ssh-keyscan.

Ah, so, this raises an interesting question: what do people use yes for?

One answer (a bad answer) is "generating artificial load".

This makes the I/O strategy oddly relevant -- different strategies result in different numbers of syscalls and (potentially) kernel lock acquisitions.

Couple this with someone trying to benchmark something's behavior with an antagonist load, and the story gets downright painful to contemplate in terms of confusing results.

Source: in my younger years, I did this. In more recent years, I've seen other engineers do it.

In this case it's probably just for fun and exercise, but generally don't think of speedy code as extending more effort, but as making the computer waste less effort. Well, unless the program isn't blocking anything any just waiting for the network, and other such cases. But any code that actually does run, especially in a loop, doesn't run in a vacuum, so I'd rather err on the case of speed. These tools don't get rewritten every 2 years in a new framework, which probably helps. Why not hone them if they're going to be that heavily used?

The git commit that sped things up mentioned using yes to generate test data.

Yeah — probably it doesn't matter how fast the yes command is. It will be faster than the program prompting for y/n.

FreeBSD's was nice and simple until someone decided to make it faster in r319897.

The yes command will repeat whatever string you give it, so it's useful for load/traffic testing. Speed helps this particular use-case.

That's a possible secondary use, but not really what the command is for.

Why not just use /dev/zero or /dev/urandom for generating load?

yes will repeat arbitrary data (including binary).

Because the yes command will repeat whatever string you give it. If you need to parse the incoming load in a certain way, /dev/{zero,urandom} won't be suitable.

I know right. The only time I have ever used it has required just 1 y/n and a new line. In that case, these "performance improvements" might make it slower for real world use cases.

This could be applied to something like memset, another deceiving simply function

Reply on news.ycombinator.com