7 ms·

Does GNU yes need such great performance, though? I'm curious to hear where it matters. Why would we need 10 billion yeses a second, and why would 10 million ye

Does GNU yes need such great performance, though? I'm curious to hear where it matters. Why would we need 10 billion yeses a second, and why would 10 million yeses a second not be good enough?

pwdisswordfish0 5y ago
I'm curious as well. On the other hand, does it need... whatever it is that GNU yes's decriers are after? The choice to focus on /usr/bin/yes as a case study is at least as bad as the GNU advocates' retort ("GNU yes is 10GiB/s fast").
- XorNot 5y ago
  When I ask for a very simple command to do something, I expect it to be the best possible implementation of that command. `grep` is pretty close to absolutely optimum (ripgrep can beat it, sometimes, maybe). I don't see why the standard for composable utilities should allow for inefficiency.
  - deleted 5y ago
    [deleted]
  - pwdisswordfish0 5y ago
    Wrong thread? How is this a response to the previous comment? Arguing that you want /usr/bin/yes to "be the best possible implementation" in terms of efficiency is a weird way of being in "violent agreement" (more like "aggressive agreement", but whatever). If writing a defensive response, you should actually defend the thing on the other side. Namely, the response here should defend the position that it's more important for yes to be simple than it needs to be efficient. That's what the previous comment challenges potential respondents to come up with.
    - XorNot 5y ago
      You don't take a position. That's my point. What is wrong with yes being capable of doing 10Gib/S? Nothing. It's optimum for a utility which has that sole function. It's not a bad retort, it's the end of the story: there is a superior utility, it's implemented.
      - pwdisswordfish0 5y ago
        You're either still misreading and believing that you're arguing against a position that is at odds with yours, or you know it's not at odds but have weird ideas about how argument works. My position is: either articulate an argument for why it's bad for /usr/bin/yes to be implemented the way GNU yes is implemented or drop the argument entirely. Your comments manage to be in disagreement with those on the other side of this, and yet still adopt an argumentative/defensive tone with respect to what I've written. I consider this to be an even bigger waste of time than the people (like OP) who are upset about GNU yes's implementation.
        XorNot 5y ago
        And I quote: > as bad as the GNU advocates' retort ("GNU yes is 10GiB/s fast"). If you don't want to defend your position, don't take it.
        pwdisswordfish0 5y ago
        I can defend my position—which is and always has been from the beginning of this (annoying) argument that anyone who says that GNU yes's implementation is bad—or that "10GiB/s" is pointless feature for something like /usr/bin/yes—needs to be able to defend the decision to scrutinize "something like /usr/bin/yes" in the first place. For whatever dumb reason, you think it's a good idea to argue about this, even while apparently believing yourself that the way GNU yes is implemented is a good thing. This makes no sense. (Are you under the impression that "X is at least as bad as Y" is the same thing as saying "Y is bad"—and that that means I need to defend the position that Y is bad? It doesn't. Maybe learn to read English better, especially before leaping so confidently into trying to argue with someone over what you're reading. Another bonus tip: not only is it important to read in complete sentences, but it's important to write in complete sentences, too, and to make sure that the sentences follow logically one after the other.)
ivanbakel 5y ago
GNU yes is elaborate and fast because Unix's yes is conceptually simple[0]: the HN link the GP shared cover how GNU programs were made to deliberately differ from Unix versions to avoid copyright issues. [0]: https://www.gnu.org/prep/standards/standards.html#Reading-Non_002dFree-Code https://www.gnu.org/prep/standards/standards.html#Reading-No...
deleted 5y ago
[deleted]
marcodiego 5y ago
I don't know. And actually I don't care. A program that fits in a single file with 120 lines of readable code is a price I'm willing to pay for close to best possible performance. But that is not why I commented. I commented because I wanted to illustrate that the author questioned something that can be easily answered with a simple google search. I'm sure the author is qualified enough to answer the question, but instead left in the post giving most readers a impression that the complexity is there out of incompetence of GNU developers. EDIT: I should not assume you asked in bad faith, but as the sibling commented. The answer to your question can be easily found in the link I posted. Making your behavior strangely similar to the author of the post: making questions that can be easily answered while giving a bad impression of others. Please, avoid that. It may work in many places but will fire back at you sometimes.
- akkartik 5y ago
  I don't find it so questionable to ask questions that the right google search (out of an infinite number; we're not all equally deeply immmersed in this stuff) can answer. But if we disagree about that I guess I'll stop talking to you. The actual question we're debating will have to wait. I've had to deal with enough ornery people in my life who had the answer like, right in their head but would still insist on putting others through pain for it. These days I try to foster a workplace where anybody struggling with a question the person next to them knows the answer to is wasting the team's time. (Skills are not the same as factual knowledge here.)
  - marcodiego 5y ago
    Sorry for giving the wrong impression. My problem with the question is not that it is easy to answer. The problem is that it is easy to answer WHILE giving a bad impression of others.
    - akkartik 5y ago
      I don't understand what you mean. Why can't we just debate the question without speculating about motivations of the people raising/answering the question?
deleted 5y ago
[deleted]
dfox 5y ago
The selling point of various GNU userland tools and libraries in the 80's was better performance, removal of obscure bugs and limitations and then maybe some useful extensions. Case in point is that most people have no idea of how POSIX defines "text file" (ie. ends with \n, no line is longer than LINE_MAX), and what happens when you inout something that technically is not text file into POSIX utility that expects text file is undefined. GNU tools do something sensible or at least produce an meaningful error message, traditional Unix userspace usually does not (lines get truncated, last line sillently ignored, some buffer somewhere overflows and in better case you get SIGSEGV...).
m463 5y ago
The root of all evil is premature optimization. Until yes performance is the bottleneck for some problem, leave it alone.
- tlamponi 5y ago
  Premature optimization is mostly an issue if I want to build a big machine and spent the first weeks on optimize and polish a tiny, not too relevant cog. But `yes` isn't such a thing, it's a standalone tool. Here the UNIX philosophy "Write programs that do one thing and do it well" comes rather at play. Further, the optimizations it makes are not really complicated nor expensive to maintain. A page aligned buffer twice the most common page size is standard for basically everything where something is written or memory moves around. One certainly can argue that it is Ok doing it more simply as it still is more than fast enough for the common use case. But arguing that a bread and butter optimization, namely one that adds just a few dozen lines of code total while increase throughput by three orders of magnitudes, should not be made, or that it even points to a complexity problem, is not holding any ground IMO.
sbierwagen 5y ago
Yes.

Does GNU yes need such great performance, though? I'm curious to hear where it matters. Why would we need 10 billion yeses a second, and why would 10 million yeses a second not be good enough?

pwdisswordfish0 5y ago

I'm curious as well. On the other hand, does it need... whatever it is that GNU yes's decriers are after? The choice to focus on /usr/bin/yes as a case study is at least as bad as the GNU advocates' retort ("GNU yes is 10GiB/s fast").

XorNot 5y ago
When I ask for a very simple command to do something, I expect it to be the best possible implementation of that command. `grep` is pretty close to absolutely optimum (ripgrep can beat it, sometimes, maybe). I don't see why the standard for composable utilities should allow for inefficiency.
- deleted 5y ago
  [deleted]
- pwdisswordfish0 5y ago
  Wrong thread? How is this a response to the previous comment? Arguing that you want /usr/bin/yes to "be the best possible implementation" in terms of efficiency is a weird way of being in "violent agreement" (more like "aggressive agreement", but whatever). If writing a defensive response, you should actually defend the thing on the other side. Namely, the response here should defend the position that it's more important for yes to be simple than it needs to be efficient. That's what the previous comment challenges potential respondents to come up with.
  - XorNot 5y ago
    You don't take a position. That's my point. What is wrong with yes being capable of doing 10Gib/S? Nothing. It's optimum for a utility which has that sole function. It's not a bad retort, it's the end of the story: there is a superior utility, it's implemented.
    - pwdisswordfish0 5y ago
      You're either still misreading and believing that you're arguing against a position that is at odds with yours, or you know it's not at odds but have weird ideas about how argument works. My position is: either articulate an argument for why it's bad for /usr/bin/yes to be implemented the way GNU yes is implemented or drop the argument entirely. Your comments manage to be in disagreement with those on the other side of this, and yet still adopt an argumentative/defensive tone with respect to what I've written. I consider this to be an even bigger waste of time than the people (like OP) who are upset about GNU yes's implementation.
      - XorNot 5y ago
        And I quote: > as bad as the GNU advocates' retort ("GNU yes is 10GiB/s fast"). If you don't want to defend your position, don't take it.
        pwdisswordfish0 5y ago
        I can defend my position—which is and always has been from the beginning of this (annoying) argument that anyone who says that GNU yes's implementation is bad—or that "10GiB/s" is pointless feature for something like /usr/bin/yes—needs to be able to defend the decision to scrutinize "something like /usr/bin/yes" in the first place. For whatever dumb reason, you think it's a good idea to argue about this, even while apparently believing yourself that the way GNU yes is implemented is a good thing. This makes no sense. (Are you under the impression that "X is at least as bad as Y" is the same thing as saying "Y is bad"—and that that means I need to defend the position that Y is bad? It doesn't. Maybe learn to read English better, especially before leaping so confidently into trying to argue with someone over what you're reading. Another bonus tip: not only is it important to read in complete sentences, but it's important to write in complete sentences, too, and to make sure that the sentences follow logically one after the other.)

ivanbakel 5y ago

GNU yes is elaborate and fast because Unix's yes is conceptually simple[0]: the HN link the GP shared cover how GNU programs were made to deliberately differ from Unix versions to avoid copyright issues. [0]: https://www.gnu.org/prep/standards/standards.html#Reading-Non_002dFree-Code https://www.gnu.org/prep/standards/standards.html#Reading-No...

deleted 5y ago

[deleted]

marcodiego 5y ago

I don't know. And actually I don't care. A program that fits in a single file with 120 lines of readable code is a price I'm willing to pay for close to best possible performance. But that is not why I commented. I commented because I wanted to illustrate that the author questioned something that can be easily answered with a simple google search. I'm sure the author is qualified enough to answer the question, but instead left in the post giving most readers a impression that the complexity is there out of incompetence of GNU developers. EDIT: I should not assume you asked in bad faith, but as the sibling commented. The answer to your question can be easily found in the link I posted. Making your behavior strangely similar to the author of the post: making questions that can be easily answered while giving a bad impression of others. Please, avoid that. It may work in many places but will fire back at you sometimes.

akkartik 5y ago
I don't find it so questionable to ask questions that the right google search (out of an infinite number; we're not all equally deeply immmersed in this stuff) can answer. But if we disagree about that I guess I'll stop talking to you. The actual question we're debating will have to wait. I've had to deal with enough ornery people in my life who had the answer like, right in their head but would still insist on putting others through pain for it. These days I try to foster a workplace where anybody struggling with a question the person next to them knows the answer to is wasting the team's time. (Skills are not the same as factual knowledge here.)
- marcodiego 5y ago
  Sorry for giving the wrong impression. My problem with the question is not that it is easy to answer. The problem is that it is easy to answer WHILE giving a bad impression of others.
  - akkartik 5y ago
    I don't understand what you mean. Why can't we just debate the question without speculating about motivations of the people raising/answering the question?

deleted 5y ago

[deleted]

dfox 5y ago

The selling point of various GNU userland tools and libraries in the 80's was better performance, removal of obscure bugs and limitations and then maybe some useful extensions. Case in point is that most people have no idea of how POSIX defines "text file" (ie. ends with \n, no line is longer than LINE_MAX), and what happens when you inout something that technically is not text file into POSIX utility that expects text file is undefined. GNU tools do something sensible or at least produce an meaningful error message, traditional Unix userspace usually does not (lines get truncated, last line sillently ignored, some buffer somewhere overflows and in better case you get SIGSEGV...).

m463 5y ago

The root of all evil is premature optimization. Until yes performance is the bottleneck for some problem, leave it alone.

tlamponi 5y ago
Premature optimization is mostly an issue if I want to build a big machine and spent the first weeks on optimize and polish a tiny, not too relevant cog. But `yes` isn't such a thing, it's a standalone tool. Here the UNIX philosophy "Write programs that do one thing and do it well" comes rather at play. Further, the optimizations it makes are not really complicated nor expensive to maintain. A page aligned buffer twice the most common page size is standard for basically everything where something is written or memory moves around. One certainly can argue that it is Ok doing it more simply as it still is more than fast enough for the common use case. But arguing that a bread and butter optimization, namely one that adds just a few dozen lines of code total while increase throughput by three orders of magnitudes, should not be made, or that it even points to a complexity problem, is not holding any ground IMO.

sbierwagen 5y ago

Yes.