[COFF] Re: [TUHS] On Bloat and the Idea of Small Specialized Tools

["Theodore Ts'o" <tytso@mit.edu>]

On Sat, May 11, 2024 at 09:12:33AM -0400, Dan Cross wrote:
> On Fri, May 10, 2024 at 7:23 PM Nevin Liber <nliber@gmail.com> wrote:
> > A lot of "bloat" comes because our systems really aren't focused on "discoverability".
> >
> > While I probably have used "pr" in the past, I've totally forgotten, the name "pr" doesn't really help me understand what it is for, and it's just one of 982 files in my /usr/bin directory alone.  How does one discover it?
> 
> This is a fantastic question. At one point, I went through every
> command in /bin and /usr/bin and figured out what it did. That was a
> tremendously useful exercise, but that was in the days when the total
> number of commands in those directories numbered in the low hundreds;
> 982 is a lot.

Yeah, I think that a lot of this goes back to scalability.  What might
work well in the simpler world of V7 Unix might be more challenging
probem space today.  One example of this is how many people got
started with Kernel programming.  When I first started working on
Linux, which was back in 1991, I could print out all of the kernel
source (heh, using "enscrpt -2rGh") and that was less than an inch
think of paper, and I could read it all.  I'm sure people had done
similar things with the Unix source code, or via the underground
photocopied of the Lyons book (AT&T copyright be d*mned :-).  But
today, that's really not a practical way for people to get started
with Unix/Linux systems programming.

Another example of this is if you want to do something with more
complex data than just plain text files with fixed data fields that
you could manipulate using sort, awk, and Unix pipes.  What if you
>need more complex structured data, stored say in JSON?  Sure, you can
do something with pipes and jq.  So sure, I can do something that is
more true to the Unix philosphy like this:

	    gcloud compute instances describe \
			--zone "$z" "$i" --format=json > "$inst_info"
	    kver=$(jq < "$inst_info" 2> /dev/null \
		'.metadata.items[] | select(.key == "kernel_version") | .value' | \
			sed -e 's/^"//' -e 's/"$//' \
			    -e 's/^Linux xfstests-[0-9A-Za-z-]* //' -e 's/ .*//')
`	    gce_status=$(jq < "$inst_info" .status | \
			    sed -e 's/^"//' -e 's/"$//')
	    status=$(jq < "$inst_info" 2> /dev/null \
		'.metadata.items[] | select(.key == "status") | .value' | \
			    sed -e 's/^"//' -e 's/"$//')
	    ip=$(jq < "$inst_info" 2> /dev/null \
		    '.networkInterfaces[] | .accessConfigs[] | select(.name == "external-nat") | .natIP' | \
			sed -e 's/^"//' -e 's/"$//')


...  but arguably, this is at the limit at what you can do using Unix
pipes as opposed to using Perl or Python.... but commands like:

	jq '.metadata.items[] | select(.key == "kernel_version") | .value'

is doing a huge amount of the heavy lifting.

I bet most of the young'uns would not be trying to do this as a shell
script, but using the Cloud SDK with perl or python or Go, which is
*way* more bloaty than using /bin/sh.

So while some of us old farts might be bemoaning the death of the Unix
philosophy, perhaps part of the reality is that the Unix philosophy
were ideal for a simpler time, but might not be as good of a fit
today.

Cheers,

     	      		       	     - Ted