The Collapse of the Unix Philosophy

^^^ Open incognito if you don't want to see jwz's NSFW salutations to HN readers...

> What would you name 'grep' instead?

Yeah, I found that one an especially weird gripe. Grepping was a new thing, so we needed a word for it. 'Grep' is short, easy to say and type, and relatively hard to confuse with similar words in the domain. Works for me.

I can unfortunately imagine a modern startup implementing it, and shudder at potential names my imagination is coming up with... Searchlr, the best way to search text! ReadMonkey, your personal pattern recognizer! I'll stop now.

yep, that's where I closed the tab

The whole document is great but the anti-forward is so good I'm going to risk downvotes by reproducing it in its (short) entirety here, emphasis mine:

From: dmr@plan9.research.att.com Date: Tue, 15 Mar 1994 00:38:07 EST Subject: anti-foreword

To the contributers to this book:

I have succumbed to the temptation you offered in your preface: I do write you off as envious malcontents and romantic keepers of memories. The systems you remember so fondly (TOPS-20, ITS, Multics, Lisp Machine, Cedar/Mesa, the Dorado) are not just out to pasture, they are fertilizing it from below.

Your judgments are not keen, they are intoxicated by metaphor. In the Preface you suffer first from heat, lice, and malnourishment, then become prisoners in a Gulag. In Chapter 1 you are in turn infected by a virus, racked by drug addiction, and addled by puffiness of the genome.

Yet your prison without coherent design continues to imprison you. How can this be, if it has no strong places? The rational prisoner exploits the weak places, creates order from chaos: instead, collectives like the FSF vindicate their jailers by building cells almost com- patible with the existing ones, albeit with more features. The journalist with three undergraduate degrees from MIT, the researcher at Microsoft, and the senior scientist at Apple might volunteer a few words about the regulations of the prisons to which they have been transferred.

Your sense of the possible is in no sense pure: sometimes you want the same thing you have, but wish you had done it yourselves; other times you want something different, but can't seem to get people to use it; sometimes one wonders why you just don't shut up and tell people to buy a PC with Windows or a Mac. No Gulag or lice, just a future whose intellectual tone and interaction style is set by Sonic the Hedgehog. You claim to seek progress, but you succeed mainly in whining.

Here is my metaphor: your book is a pudding stuffed with apposite observations, many well-conceived. Like excrement, it contains enough undigested nuggets of nutrition to sustain life for some. But it is not a tasty pie: it reeks too much of contempt and of envy. Bon appetit!

> Some people think that UNIX is great and perfect

"...great and perfect" is a strawman. Whether "some people" think that is irrelevant.

Some of this article is interesting, but the fact of the matter is 40-year-old systems have signs of being 40 years old. If "fixing" everything were easy, it'd be done. Tabs in Makefiles throw off the uninitiated for 10 minutes, then they learn, shrug and move on. These scars and stories are part of the package.

Reading further, some of this is just incorrect...

>That’s not to mention the fact that critical UNIX files (such as /etc/passwd) that are read upon every (!) call, say, ls -l, are plain text files. The system reads and parses these files again and again, after every single call!

Not on my system.

> It would be much better to use a binary format. Or a database.

On my system, it is ( running "ls -ld ."):

  kamloops$ uname -a
  NetBSD kamloops 7.99.64 NetBSD 7.99.64 (GENERIC) #26: Thu Mar  2 07:15:26 PST 2017  root@kamloops:/usr/src/sys/arch/amd64/compile/obj/GENERIC amd64

  kamloops# dtrace -x nolibs -n ':syscall::open:entry /execname == "ls" / { printf("%s -%s", execname, copyinstr(arg0));}'
  dtrace: description ':syscall::open:entry ' matched 1 probe
  CPU     ID                    FUNCTION:NAME
    0     14                       open:entry ls -/etc/ld.so.conf
    0     14                       open:entry ls -/lib/libutil.so.7
    0     14                       open:entry ls -/lib/libc.so.12
    0     14                       open:entry ls -.
    0     14                       open:entry ls -/etc/nsswitch.conf
    0     14                       open:entry ls -/lib/nss_compat.so.0
    0     14                       open:entry ls -/usr/lib/nss_compat.so.0
    0     14                       open:entry ls -/lib/nss_nis.so.0
    0     14                       open:entry ls -/usr/lib/nss_nis.so.0
    0     14                       open:entry ls -/lib/nss_files.so.0
    0     14                       open:entry ls -/usr/lib/nss_files.so.0
    0     14                       open:entry ls -/lib/nss_dns.so.0
    0     14                       open:entry ls -/usr/lib/nss_dns.so.0
    0     14                       open:entry ls -/etc/pwd.db
    0     14                       open:entry ls -/etc/group
    0     14                       open:entry ls -/etc/localtime
    0     14                       open:entry ls -/usr/share/zoneinfo/posixrules

  kamloops# file /etc/pwd.db
  /etc/pwd.db: Berkeley DB 1.85 (Hash, version 2, native byte-order)

Now, I see that /etc/group -is- a plain file. This could get the same treatment as /etc/passwd if it becomes a burden. In the meantime, if it's a performance bottleneck, make a memoizing function to lookup groups and use a '-n' switch to ls. Article is probably mostly important as the author thinking deeply about Unix, and part of the developmental process of the user.

...All the bluster (some of which is interesting), then at the end walks it back:

> So, I do not want to say that UNIX – is a bad system. I’m just drawing your attention to the fact that it has tons of drawbacks, just like other systems do. I also do not cancel the “UNIX philosophy”, just trying to say that it’s not an absolute.

Shame about the title... But maybe that's what landed it here on HN (?)

Edit: explain the "ls" command actually run.