In the Beginning Was the Command Line (1999)

"I embraced OS X as soon as it was available and have never looked back. So a lot of 'In the beginning was the command line' is now obsolete. I keep meaning to update it, but if I'm honest with myself, I have to say this is unlikely."

https://slashdot.org/story/04/10/20/1518217/neal-stephenson-...

But people still dredge this quarter century old apocrypha up and use it to pat themselves on the back for being Linux users. "I use a Hole Hawg! I drive a tank! I'm not like those other fellows because I'm a real hacker!"

Meanwhile Windows has become those cars with two 27" screen as dashboard, which has bad user experience and full of advertisements.

It's a close analogy, because the Comet was actually the next model of Edsel. They just changed the branding. Same with Vista to 7.

I assume if anyone associated with Microsoft compared Vista to anything other than an abject failure, it's because they are - at best - broken or defective people who were involved in the creation of Vista, and therefore not objective and not to be trusted in any way.

Dodge Viper? WTF?

Screenshots along with text, then use Microsoft Paint to mark up the screen shots. For example, circling the appropriate menu option in a thick red line. Sadly, I do not know how to graphically convey the double-click operation.

Its a time consuming and error prone process, best used if the buggy GUI application is abandonware. Otherwise, the new version will have the same bug or non-intuitive process but the GUI will be unrecognizable. Probably because some manager, somewhere, read too many HN articles and decided a user-facing refactor was the most important thing they could possibly do.

That said, the best late 90s expression of the core advantage of the GUI over the TUI/CLI is that it demands less of the user:

"recognize and click" vs

"remember and type"

That seems very fundamental to me.

I have not seen as succinct expression of tradeoffs for V(oice)UI or L(LM)UIs

   { select[i]@dropdown:states > click@button:submit }

So a 'record' feature on GUI 'a' can create action encoding that can be emailed to your peer looking at GUI 'b' and 'pasted'.

To do that in a gui-centric fashion, the only tools we actually have are textual commands that direct gui action. essentially its a middleman step: if we are already writing our applescript lets say, we might as well just abrogate the actual commands that our applescript is trying to abrogate through the gui system.

I don't think that was the intended implication. I think the analogy is more akin to: "If send us a bug report, we'll fix it and ship a new version that you can download and use for free." In the olden days, you'd have to buy a new version of commercial software if it didn't work for your machine, complementary patches were rare.

Who would want that?

"Stay away from my house, you freak!" would be the normal reaction. Unless some serious trust is developed, I would not let people into my house while I sleep.

Also the actual usual reaction would have been more like: "hey it is open source, you can fix anything on your tank yourself"

You need a new module to connect with your other devices, just build it yourself, no big deal!

Ever wonder how Red Hat became a billion-dollar company before it was bought by IBM, and now makes up a huge segment of IBM's revenue stream?

Have you noticed SuSE is still around?

Have you ever speculated on how Canonical keeps its lights on?

Paid support, my naive friend. Linux support is big business and is what keeps the popular distros alive.

We should move to the Command Table.

Yep! Windows did indeed come with machines, but the upgrades were always a big seller. I remember when Windows 3.1 hit the shelves and seemed to be everywhere. Same with Windows 95 but that one was a tougher upgrade because of the increased system requirements.

Today new OS versions aren't such a big deal, but when Windows 95 came out, and then XP, they were huge, with total interface redesigns.

On the other hand, I don't think people went out of their way as much to buy smaller upgrades like Windows 98.

Definitely. A new boxed OS version would often be the only updates anyone ever applied to their system. Even if you had Internet access, dial-up speeds and limited disk space meant downloading OS updates was often impractical. Even relatively small updates took forever to download.

There was also the relative costs of a computer. A $2,000 computer in 1995 would be about $4,000 in today dollars. Buying an OS update would be a relatively inexpensive way to upgrade the capabilities of your expensive computer without completely replacing it. Going from some Windows 3.1 release to Windows 95 would have been a nice upgrade in system stability for many people. Certainly not everyone but for many.

This is markedly different from how it was in the past when they needed people to get up, go to a store, and buy the disc containing the new version of the OS.

He returns to it rather explicitly in _Dodge in Hell,_ with the odyssee through the "Facebooked" wastelands of -- where was it, Idaho / Montana / the Dakotas? Something like that -- where the MAGAfied barely-literate natives hound the scientist / tech-type heroes.

“To make a building, you need to have a foundation, something to keep the roof up, and a way for people to move inside.”

While I share the opinion that the command line is _the one true way_ of computing, I don't think this is really all that true. Computers are alien. GUIs are alien. CLIs are alien. Everything is learned. Everything is experience. Everything is culture. Learning, experience, and culture blind us from the experience of the novice. This is "expert blindness".

Why Western Designs Fail in Developing Countries https://youtu.be/CGRtyxEpoGg

https://scholarslab.lib.virginia.edu/blog/novice-struggles-a...

I think Windows very much wanted to be something different with COM. Instead of starting a shell in the context of the program, you'd connect some external "shell" into the very object graph if your program to inspect it. It turns out to be very difficult, and Windows has largely retreated to commandline centric architecture, but I think there was some essential attempt at foundational innovation there.

I would argue that the commandline has very much proven to be the best trade-off between being useful and being simple, but there is no saying if there exists some alternative.

But CLI contexts are only obvious if the computer user is already familiar with the CLI which biases the learned mind to perceive things as obvious when they really are not.

A lot of CLI commands syntax are based on position instead of explicit argument names.

E.g. creating file system links via CLI has opposite syntax positions in Linux vs Windows:

  - Linux:  ln srcfile targetlink

  - Windows :  mklink targetlink srcfile

This gap of knowledge is also why there is copy&paste cargo-culting of inscrutable ffmpeg, git, rsync, etc commands.

E.g. using ffmpeg to covert a DVD to mp4 by manually concatenating *.VOB files has very cumbersome and error-prone syntax. It's easier to use a visual GUI like Handbrake to click and choose the specific title/chapters to convert.

CLI vs GUI superiority depends on the task and the knowledge level of the user.

You sound like someone who never tried to write a cronjob script…

Wow, that seems quite fundamental. Computing 101.

I'm not a "coder" and I spend "99%" of time on the command line. Because I prefer it. Ever since the 80s when I first used a VAX.

Outside of the syntax (which seems to live forever), you have things like non-sane defaults, obscurantist man pages ... the list goes on.

I've seen people think they have a specific Python environment active just because they were in their project's directory on the command line.

I've seen people not understand that "python -m pip" is a command and even if they are in a directory which has "python" in its name, they still have to type "python" for that command.

PS: The command line might even be an emperor. And the emperor could be naked...

There is a level of abstraction that makes sense. What level that is is dependent on your objectives.

Quick outline of the course, in case anyone wants a starting point:

  * Introduction
    Quick history of Unix

  * When you log in
    Difference between login and interactive shells
    System shell files vs user shell files
    .zshenv for environment variables like PATH, EDITOR, and PAGER
    .zprofile for login shells, we don't use it
    .zshrc for interactive shells
    Your login files are scripts, and can have anything in them

  * Moving Around

  ** Where am I?
    pwd = "print working directory"
    stored in variable $PWD
    Confusingly, also called current working directory, so you may see CWD or cwd mentioned

  ** What is here?
    ls
    ls -al
    ls -alt
    . prefix to filenames makes them hidden
    . is also the current directory!
    .. means the parent directory
    file tells you what something is
    cat displays a file
    code opens it in vscode

  ** Finding my way around
    cd
    cd -
    dirs | sed -e $'s/ /\\\n/g'

  ** Getting Help From The Man
    man 1 zshbuiltins
    manpage sections

  ** PATH
    echo $PATH | sed -e $'s/:/\\\n/g'
    zshenv PATH setting
    which tells you what will be run

  ** Environment Variables
    env | sort
    EDITOR variable

  ** History
    ctrl-r vs up arrow

  ** Permissions
    Making something executable

  ** Prompts
    zsh promptinit
    zsh prompt -l

  ** Pipes and Redirection
    Iterate to show how pipes work
    cat ~/.zshrc | grep PATH
    ls -al > ~/.tmp/ls-output.txt

  ** Commands

  *** BSD vs GNU commands
    BSD are supplied by Apple, and Apple often uses old versions
    GNU are installed via homebrew, and match those commands available in Linux

Input maybe, although realizing that instead of typing, you can pipe, is a major conceptual breakthrough when new users are learning to work the command line.

But output? The existence of stdout and stderr as two sources of text with no visible distinction is highly nonobvious and continues to trip me up in practical situations to this very day.

  On the command line, the context is obvious

If you’re lucky, you might know what your current directory is.

More often than not, at any particular point, your command line is paused in the middle of some likely ad hoc multi-step process. A process with a bunch of state stored as opaque blobs of data scattered across the file system. More so exacerbated in my case as those files are likely cleverly named x, x1, x2.

Modern systems benefit from things like command history, scroll back buffers, and similar constructs that can be leveraged to help you, as the user, restore the current context. But for a very long time, many simply returned to a $ and a soulless, cold, blinking cursor callously expecting that you recall you know where you are and what you’re doing.

The tools are there to help you dig and perhaps restore the current context (current directory, latest files, etc.) but that’s a far cry from “obvious”. Lots of folks return, blow their internal call stack, and just start over when they come back from lunch (if practical).

Or, more likely: so that you yourself can remember what you did the next time the problem arises. Or your colleague, who is senior, but does not know this part of the codebase or infra well. Heck, you can even write a shell script, automate things and have your productivity increased!

These things will be just as true and useful in some communist FOSS context as they are in a capitalist system.

If the solution to a problem is as simple as “copy and paste this command”, I want to hand that off to a junior employee so I can go do other things that require more creativity.

Just in userspace you have;

   dmesg -w

   tail -f /var/log/messages

Because it gets annoying to have a process splurge notification stuff to a term you are working in, that's why you have info-bars which many terminal emulators support.

This just seems like an odd non sequitur.

<https://en.wikipedia.org/wiki/Expect>

Much of modern operating systems is events-based and relies on polling for specific actions, devices connecting / disconnecting, etc. Linux device management is based on this, for example. There are numerous scripts which fire as a service is enabled or disabled (networking "ifup" and "ifdown" scripts, for example), or services are started / stopped. Systemd extends these capabilities markedly.

And of course there's a whole slew of conditional processing, beginning with init scripts, [], test, &&, ||, and specific conditional logic within shells, scripting, and programming languages.

Putting it in a browser window gives it bad odds. You can also listen to it:

https://youtu.be/KpaUg6WwdzU

Begins at 01:30, 25 minutes.

In his book The Life of the Cosmos, which everyone should read, Lee Smolin gives the best description I've ever read of how our universe emerged from an uncannily precise balancing of different fundamental constants. The mass of the proton, the strength of gravity, the range of the weak nuclear force, and a few dozen other fundamental constants completely determine what sort of universe will emerge from a Big Bang. If these values had been even slightly different, the universe would have been a vast ocean of tepid gas or a hot knot of plasma or some other basically uninteresting thing--a dud, in other words. The only way to get a universe that's not a dud--that has stars, heavy elements, planets, and life--is to get the basic numbers just right. If there were some machine, somewhere, that could spit out universes with randomly chosen values for their fundamental constants, then for every universe like ours it would produce 10^229 duds.

Though I haven't sat down and run the numbers on it, to me this seems comparable to the probability of making a Unix computer do something useful by logging into a tty and typing in command lines when you have forgotten all of the little options and keywords. Every time your right pinky slams that ENTER key, you are making another try. In some cases the operating system does nothing. In other cases it wipes out all of your files. In most cases it just gives you an error message. In other words, you get many duds. But sometimes, if you have it all just right, the computer grinds away for a while and then produces something like emacs. It actually generates complexity, which is Smolin's criterion for interestingness.

Not only that, but it's beginning to look as if, once you get below a certain size--way below the level of quarks, down into the realm of string theory--the universe can't be described very well by physics as it has been practiced since the days of Newton. If you look at a small enough scale, you see processes that look almost computational in nature.

I think that the message is very clear here: somewhere outside of and beyond our universe is an operating system, coded up over incalculable spans of time by some kind of hacker-demiurge. The cosmic operating system uses a command-line interface. It runs on something like a teletype, with lots of noise and heat; punched-out bits flutter down into its hopper like drifting stars. The demiurge sits at his teletype, pounding out one command line after another, specifying the values of fundamental constants of physics:

universe -G 6.672e-11 -e 1.602e-19 -h 6.626e-34 -protonmass 1.673e-27....

and when he's finished typing out the command line, his right pinky hesitates above the ENTER key for an aeon or two, wondering what's going to happen; then down it comes--and the WHACK you hear is another Big Bang.