What insight does the author have to offer with this essay? It's easy to complain about complexity, harder to offer a simpler but equally capable alternative. The author makes it sound like simple is easy. As if it's just a matter of saying no to complexity, like saying no to memcpy() whenever we have a memmove() that's good enough. This is not the case. Simple is not easy. On the contrary, simple is hard . So you th…
>The author makes it sound like simple is easy. As if it's just a matter of saying no to complexity, like saying no to memcpy() whenever we have a memmove() that's good enough. This is not the case. Simple is not easy. On the contrary, simple is hard. Simple by design might be hard, but "simplify in retrospect" is easy. It just needs you to be willing to sacrifice meaningless backwards compatibility and inflict some…
Unfortunately, although unix scripting was good by the standard of its era, it's still not particularly good. Unix as we know it hints at great ideals that are achievable but lives up to them poorly. As a result, early packagers shoveled hacks into existing layers and we live with the result.
Evidence: arguments in commands like cat and ls; the crudeness of ps to represent the process table; inability for scripts to access unix systems calls; kitchen sink shell interpreters.
Why do we look to shell interpreters for command-line history? That should be done in a separate layer closer to the terminal. Had it been, we'd have two small unbloaty layers. Instead we have tcsh, bash and zsh.
You could have your ls formatting macros live in your personal terminal emulator and you'd never need to copy .bashrc hacks to each system. The formatter code might not even live on the remote system, it might be part of the terminal.
I suspect you could lay [racket scheme] + [a transform that converts python style whitespace code into parens code] over a unix that has /proc, and use that to create the layers you needed. With that in place, you could then start taking noise out of the unix tools and work towards a smaller distribution.
Plan9 is talked of as "unix done right" but I'm not convinced. Some things it does well, but it has lots of baggage. For example, you have to buy into their desktop to access the OS. How is forcing me to use a mouse and a particular tiling window manager a necessary part of a better unix experience?
I'd like to play with a plan9 fork where the only user interface assumption was a terminal, and where you could get a secure connection into that terminal. (Too inept to do it myself so far, but keep playing with idea of running it on linux, ssh'ing to linux as the jump box, and then telnetting into the plan9 instance. Still - what a hassle)