_   _                         
| | | | __ _ _ __  _ __  _   _ 
| |_| |/ _` | '_ \| '_ \| | | |
|  _  | (_| | |_) | |_) | |_| |
|_| |_|\__,_| .__/| .__/ \__, |
 _   _      |_|   |_|    |___/ 
| \ | | _____      __
|  \| |/ _ \ \ /\ / /
| |\  |  __/\ V  V / 
|_| \_|\___| \_/\_/  
__   __              _ 
\ \ / /__  __ _ _ __| |
 \ V / _ \/ _` | '__| |
  | |  __/ (_| | |  |_|
  |_|\___|\__,_|_|  (_)

I’ve been experimenting with console-only systems since I first realized it was possible. X was usually slow or, worse, wouldn’t run at all on some of the older systems I had, so I’d just omit it in favor of svgalib applications (Links2 -g, zgv, etc). This was FreeBSD at the time, so the graphical stuff was different.

Later I received some free low-end laptops from family and friends, which were practically incapable of running X. So the console tradition continued in that sense.

These days I like to see how Linux performs on ancient systems out of curiosity, and what they can be made to do. I tend to prefer console applications anyway just because they have such a low footprint, and because they work with screen/ssh.

Still wish there were a good method of doing WWW. ELinks/etc. have never worked with my bank, for example.

Anyway, fun projects! I’ll keep you in my RSS reader.

I don’t think CLI is merely a matter of taste, as this article suggests. Reasons can be given for it. They might not be compelling reasons for some people, but they are reasons nonetheless.

Here are some of the most common reasons given for favoring the CLI:

- CLI is more sparing of resources, and as our host has so often explained, allows us to continue using older machines which might otherwise be discarded because they can’t run the latest compositing window managers or play flash videos. CLI apps typically require less memory and hard drive space, and they make minimal demands on the video system.

- CLI puts more power at the user’s fingertips. The user who has mastered the shell typically understands the system to a greater depth than a GUI user. (I don’t think it’s the case that power users first begin to use the shell after they’ve already mastered the system. It’s the other way around. The shell has pedagogic value. Using it is the best way to *become* a power user.)

- CLI is better for ad hoc tasks that involve applying the same operation to many different operands. GUI apps *have* been created to perform some of the more common of these tasks, e.g. batch file renaming. But these GUI apps are all specific to a single task. None of them, as far as I know, provides the kind of open-ended flexibility available on the commandline.

- Because they are typically smaller, CLI apps load faster than most GUI apps. They’re also more likely to fit within the available physical RAM and run without virtual memory swapping, which means they often run faster than the corresponding GUI apps.

- Most GUI apps use a number of shared libraries (aka DLLs) which must be loaded into memory at runtime. Typically, these libraries remain in memory even when the code they contain is not being used. In contrast, a shell script might launch many different programs as separate processes in order to perform various subtasks, but once those subtasks have been completed, the programs terminate and the system can recover any resources they were using. (This point is thus an elaboration of the first one.)

Finally, I want to mention the need to distinguish between the commandline interface (CLI) and a text-mode interface (TUI). Examples of the latter include many ncurses- or slang-based apps like Midnight Commander or mutt.

Not all of the benefits of the CLI accrue to TUI apps as well.

Batch operations, for example, can be as cumbersome in a TUI as they are in a GUI. But TUI apps are more likely to address this shortcoming by providing a commandline too. (You can see this solution in both Midnight Commander and mutt.)

Rest assured, though, that if I do ultimately install xorg, there will be no DE … just a spartan ratpoison WM.

And merry Christmas, K.Mandla!