Do not some system utilities stagnate?

Again, grep change in the system base. This is a concrete proof that changed happens.
End of polemic, no ?

If you argue that the system seems fragile, I see 0 bugs in relation with the grep change... That sound like a rock solid base, no ?
And finally, the base system is a base... So there is a lot of specific usage that use base tools to build edifices. So the major release exists to prevent any breaking change for the user.

Maybe you have a better example than grep ?
 
mkru said:
I mean backward compatible improvements, not breaking changes.
Click to expand...
This is another one of those "why don't people do stuff" questions where the people in position to answer them are not here on the forum, will not come here, and everybody gets to make a strawman that looks like them and knock other people's strawmen over.

That being said:
  1. Fixing other people's stuff isn't always fun
  2. Starting over with a new tool is often "easier"
  3. Making something faster sometimes requires an architecture change that will make preventing user facing changes way more work than the programmer wants to do
  4. This whole thing is mostly a volunteer effort
  5. Installing some other program is easy. Eventually if it's super popular and mostly backward compatible, it will go into base. If it wholly replaces the other program, the old program will eventually get removed. This process takes an incredible amount of time and the removal makes a small number of noisy people who hate change, angry.
 
Hakaba said:
Maybe you have a better example than grep ?
Click to expand...
One I could suggest is the system compiler [old gcc 4.x] > [clang]. Granted it is a much more extreme example.

I am personally shocked at either how little this broke in terms of the ports or how efficient the ports collection was at supporting this large change. Many patches must have been made behind the scenes.

Clang is better than the old gcc which stagnated for a while. So it certainly shows that the FreeBSD project isn't afraid of change when it is actually a big benefit. Otherwise I think most engineers prefer to iterate rather than rewrite.

So if anyone did have any improvements to grep, I would certainly encourage them to try to implement them into our grep. However rewrite a new grep entirely doesn't seem like the correct solution. No matter how much backwards compatibility they try to go for. It will never be 100% (quirks and all).
 
mer said:
Is it worth rewriting them to make them work better with technical overload or do you create a new tool, targeted for the new load from scratch?

Go look in the hackers mailing list. There was recently something about "sysctl being slow if you have thousands of ZFS datasets". There was a bit of root cause analysis that got to a possible cause, ideas were tossed out as to how to change it for the better, but then the question was raised "Is this actually the appropriate method for me to get this data or is there a better way?".
Click to expand...
In this instance, replacing the linked list with a tree structure is actually a really good idea instead of doing it another way, pretty "easy" to do in isolation, and apparently NetBSD already does this. 1 & 4 from my list applies, however.
 
msplsh said:
In this instance, replacing the linked list with a tree structure is actually a really good idea instead of doing it another way, pretty "easy" to do in isolation, and apparently NetBSD already does this. 1 & 4 from my list applies, however.
Click to expand...
Yep sometimes the technical change is isolated and could be done without impact, but it will boil down to priorities and desire.
If one has the desire and prioritizes it, go for.

mkru you do realize that even without being a committer you could actually file a bug/enhancement with a patch, don't you? If this specific example of grep bothers you so much, why not do so?
 
You must log in or register to reply here.
Back
Top