Trainwreck Design

(most) Kids will likely never learn these command and attributes and output like we passionately did in 1994. LLMs be spittin' them command lines quick and correct, transpiled/translated from English/French/...Macedonian if you like. they already do, and it already helps a lot.

Perhaps one may learn to remember and , but will definitely not care to produce by heart oneliner bash abominations sprinkled with sygils and pipes and three-char cmd names.

This whole article very true, but somewhat irrelevant to 2024. Claude/Mistral/CHatGPT been parsing outputs perfectly, and there are plenty of experiments into getting the LLM to assist code writing and parsing results directly from the cmdline. And you know what, this also works in 100% console mode, you don't need GUI to talk to the new GUI called LLM.

the smaller models get, the sooner they get embedded in shells. then you'll get the real Ghost in the Shell, yeah...

From a design standpoint I like to highlight one rule: A good design is one where the most common action your users will take is priorized. If you get there alone, by basar, by comittee or whatever, doesn't change that. The problem with the latter variants is that decisions are not made on principles, they just happen.

For example if the overwhelming majority of users use df to get an overview of how much disk space they are using and how much they have left, the default option should be giving you a easily digestable output of precisely that.

I get that in terminal-land this can be a problem, as the default df command is now probably parsed by a thousand shell scripts and chaninging it breaks things. But that is also bad design: If there are hard reasons like that that could conceivable lock you into doing it a certain way, you should warn against it and offer a stable alternative (stderr: "The output of df -h is not meant to be machine readable, use df --machine instead"). Again frequency is the guide here. People will more often type df -h to manually check things than they have to write df --machine in a script.

Same goes for the default output of ip a (which in my opinion should be more like ip -br -c a).

Also - the images look strongly reminiscent of `cowsay`.

You mean footnotes? As they have been used for centuries in print?

The difference between them and a simple hyperlink is that they can and often will provide some additional context, that is out of the scope of the original text. Ideally on a website meant for computer screens you wouldn't have them on the end, but in the margins, next to the information, but for short stuff it is okay to put them at the end of the chapter – bonus points if the reference numbers can be clicked and take you to the foot note, extra bonus points if there is an arrow taking you up again.

But this is scientific literature style writing, not everything needs footnotes.

Very cool. Thanks for sharing! I added `-x overlay` too, to get rid of all the docker overlay mounts.