On 2012.06.27. 10:34, Doug Barton wrote: > Great, can you post the results somewhere? I understand what you're > saying below that there are situations where worse performance may need > explanation, but it would be helpful if we had the data to look at. If something is buggy than it is not comparable in terms of performance because usually those bugs are the exact problem of the better performance because of the negligence of some checks or aspects that were not well considered. > And the project cannot grow if we lose users due to gratuitous > differences in core utilities. There are more Linux users than FreeBSD users and they all use GNU sort. A great percent of FreeBSD users also manages Linux systems at work so they may also be using new GNU sort features. So in short, what people more usually expect is the behavior of the latest GNU version and POSIX-conformance, not an obsolete, buggy behavior. Losing users because something works better does not seem to be a real threat. But if this is a problem then we should stop fixing bugs and adding features at all since it may discourage someone from using FreeBSD. > In the case of grep, there were a fairly large number of people who > agreed that a BSD grep with orders of magnitude worse performance than > the previous version was not something we, as a project, were willing to > stomach. Sufficiently such that the default was switched back. These are relevant critics. But remember that it lived together with GNU grep so the switch back didn't have a great impact. It was slow but at least it worked. Recently the build is so regularly broken that it makes much more harm. With BSD sort, it is the same case, if there are problems that are hard to solve, we will switch back easily. GaborReceived on Wed Jun 27 2012 - 18:29:36 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:28 UTC