2 ms·

> And it does make sense for Open Source code because the resources are limited hence other features and/or bug fixes might be more important than pushing data

> And it does make sense for Open Source code because the resources are limited hence other features and/or bug fixes might be more important than pushing data at full speed That's not how open source works, though. There's not a group of people obligated to work on the GNU utilities. There's not a central project manager ordering people around telling them what changes to make. Declaring that 'yes' is generally fast enough already doesn't imply that it was fast enough for the person who spent their time optimizing it. Somebody needed (or just wanted) 'yes' to be really fast, so they did the work and submitted the changes back.

raverbashing 9y ago
> There's not a central project manager ordering people around telling them what changes to make. No, but there is review and approval of patches (also the most frequent contributors know where the project is going and there is bug tracking) If one just makes it faster without major benefits that patch is likely to be rejected
- jlarocco 9y ago
  > If one just makes it faster without major benefits that patch is likely to be rejected IF the project were overwhelmed with incoming patches, then I would agree that there's probably higher priority changes than optimizing 'yes'. But I'm almost certain the GNU project is not being overwhelmed with changes to the core utilities. Everything else being equal (code quality, readability, test coverage, etc.) there's really no reason to reject a patch that demonstrably improves the project, even in some silly way like making 'yes' really fast.