Well, GNU grep was last released 16 months ago, and the last change to its master branch was 4 weeks ago: http://git.savannah.gnu.org/cgit/grep.git
FreeBSD's grep was last updated back in August: https://github.com/freebsd/freebsd/tree/master/usr.bin/grep
OpenBSD's grep was last updated 11 months ago: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/grep/
Oddly, it looks like the Darwin grep was last updated in 2012: https://opensource.apple.com/source/text_cmds/text_cmds-99/g...
Strange that Apple would be shipping such an ancient grep.
A tldr of the middle would be cool. Maybe there was a pattern.
I'd like to add another OS not mentioned that will hopefully become a well-appreciated artifact soon too, from Redox OS: https://gitlab.redox-os.org/redox-os/coreutils/blob/master/s...
I can't find it quickly now, but jackpot51 also has a very answer somewhere on Reddit about how their networking stack's DNS query command departs from a commonly deployed C program for Windows and Unix, iirc. fascinating
Also I want to point readers to the commentary of some of the Unix authors:
“Old programs have become encrusted with dubious features. Newer programs are not always written with attention to proper separation of function and design for interconnection.”
http://harmful.cat-v.org/cat-v/unix_prog_design.pdf
My point being: Unix (and derivatives) encompass a set of people who disagree about what constitutes Unix philosophy.
References:
- 1971 draft (pre 1st edition) of the paper that would become the well-known 1974 CACM UNIX paper (earliest documentation on `cat` that I can find): https://www.tuhs.org/Archive/Distributions/Research/McIlroy_... (tune in on page 28)
- 6th edition cat(1) man page (1975): http://man.cat-v.org/unix-6th/1/cat
- 7th edition cat(1) man page (1979): http://man.cat-v.org/unix_7th/1/cat
* 2002: 833 LoC (http://landley.net/aboriginal/history.html)
* 2013: 36kLoC, 2/3rds of them .h files (https://news.ycombinator.com/item?id=11340510#11341175)
* 2018: 37kLoC of .c file dependencies going into libcoreutils.a and some LoC of .h files (coreutils has 60kLoC of .h files)
The methodology for counting lines likely isn't consistent across those data points. But the trend is still unmistakeable. Maybe I'll tree-shake all the dead code out and come up with an accurate line count one of these days..
* http://jdebp.eu./FGA/operating-system-books.html
One of these days I shall get around to expressing my opinions, which as you can see are still missing. Indeed, the list itself is a decade out of date. (-:
I have some SCO UNIX manuals on the other side of the room as I type this.
I created a wiki page to measure the number of lines of code* of various types of software https://softwarecrisis.miraheze.org/wiki/Linecount - LOC is a very very rough proxy for what I actually want to measure, but the results are so stunning that even a inaccurate indirect measurement tells a lot. You can see that for 2 projects that do essentially the same thing there might be a 1000x difference in LOC.
It's fascinating what can happen to such a simple program like 'cat'. The same effect is amplified further when you look at projects like gcc. I tried to ask the question on a couple sites like stackexchange and reddit why does gcc take half an hour to build instead of a fraction of a second but this question was not taken well. I got a lot of resistance to it, X-Y answers, deleted etc. I don't think that the common software engineer wants to take the idea seriously that the day to day tools we use have a million fold inefficiency built into them by accident. I also noticed that 'make' has no profiler, nobody has even really done a breakdown of what takes how long to build in the gcc tree.
There are a lot of brilliant engineers who understand this problem and want to solve it though. We see that in Alan Kay's STEPS project, aligrudi's work, musl, toybox, maybe sbase and many of the independent bootstrapping projects that have popped up. There's a lot of inertia and weight to the standard GNU toolkit to push back against but I believe these problems are all solvable and by solving them we can create programming languages and tools with leverage far beyond what currently exists. I just hope such projects can be integrated rather than be forgotten.
Amusingly, the BSD socket behavior can be disabled with the compiler macro -DNO_UDOM_SUPPORT, but as far as I can tell it is not documented nor hooked into the rest of the build system in any way since its introduction in 2001:
https://svnweb.freebsd.org/base?view=revision&revision=83482
MacOS:
* https://unix.stackexchange.com/questions/352977/
* https://unix.stackexchange.com/a/398249/5132
The very version of FreeBSD from some years ago:
% bsdgrep --version
bsdgrep (BSD grep) 2.5.1-FreeBSD
% grep --version
grep (GNU grep) 2.5.1-FreeBSD
Copyright 1988, 1992-1999, 2000, 2001 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
%
* https://unix.stackexchange.com/a/65609/5132
Kyle Evans and others on making bsdgrep into grep: