Hacker News Reader

Comment by offtop5 | Hacker News Reader

Actually I think students need to learn to use apt. I swear, the entire reason I got comfortable with the command line is because when I was 16 I couldn't afford a Windows license, and I ordered a free Ubuntu CD.

I'm still very good with the terminal and it serves me well in my six-figure career

View on HN

I've never really understood why command lines are so intimidating for people. Especially in today's world where you can search up whatever commands you need fairly effortlessly through the power of the internet. A large majority of simple command line use cases tend to be

$Command, $options $input file/directory $output file/directory

That shouldn't be overly complicated for honestly most people with literacy who are capable of functioning in modern society.

And plus apt get install or whatever your distro is equivalent is is infinitely easier than searching the internet to try and find what you want. I reckon a kid who can install apps on Ubuntu and troubleshoot basic issues can probably get a tech support job right out of high school if they put a good effort in.

>I've never really understood why command lines are so intimidating for people.

Really? The most popular computing device of our time is the smartphone, and you don't understand why people find command lines intimidating?

Command lines are unforgiving, frequently obscure, and will let you delete files and break things without blinking. There's plenty to be intimidated by for people who have no need to learn the skills.

Just a thought: that is more related to security models than to GUI vs CLI.

In Windows you can delete and break things if you're a local admin. Warning messages got better, but using a PC also used to be intimidating.

Smartphones on the other hand lock all apps by default, which is way better to novices.

I believe CLIs might be made friendlier with the correct segregation / security model.

The lack of discovery makes it harder to learn CLIs, they need to be studied and memorized basically. There is no intuitive way to ever learn that you need to type "man bash" into the terminal to start this journey, for example. These are meaningless words to the layman, despite holding so much meaning to someone already fluent in bash.

>In Windows you can delete and break things if you're a local admin.

Yes, but deleting things with direct manipulation is more intuitive and less dangerous than doing it with rm and globbing.

There's a ton of reasons people are afraid of CLIs, here's a few:

1. Graphical UIs are inherently more discoverable. There's no way around this and "googling it" isn't a good enough answer.

2. Graphical UIs, for better and worse, hide or limit you from doing things that will break. Those guardrails reduce the fear associated with exploration. There are guardrails on CLIs as well (sudo), but we take for granted what those are and how they work.

3. You overestimate the level of skills required to function in modern society.

I just type "help" into anything that looks like a prompt. From there things are usually discoverable enough, and if not, now I have strings, that I can C/P straight into a search engine. ;)

  zsh: command not found: help

Python help: Can’t open file ‘help’: [Errno 2] No such file or directory

Python -help: Unknown option: -e

Python —-help: actual help

Stupid users, it’s so intuitive!

(PS it always bugs me that every program uses a different option for checking the version. Node is -v, python is -V, dotnet is —-version. Again, couldn’t be more intuitive, duck users, right?)

I actually didn't know about python -V! python also accepts --version, but if you give it -v, that's verbose, which will only confuse people more. I believe java used to only accept -version with one hyphen, but now it accepts --version with two as well.

OpenBSD has a help command that’s basically just an alias for man, except without arguments it opens the manpage for help(1)¹. GNU help is a bash builtin for help with bash builtins, but does redirect to more general help.

  GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu)
  These shell commands are defined internally.  Type `help' to see this list.
  Type `help name' to find out more about the function `name'.
  Use `info bash' to find out more about the shell in general.
  Use `man -k' or `info' to find out more about commands not in this list.

¹https://man.openbsd.org/help

yes, but now you know, into which shell you were dumped, and can gogle next steps! Don't you fully read the posts you reply to?

I read your post. You’re assuming a level of confidence that most non-programmers don’t have. I googled that exact message and nothing helpful came up.

I wrote ~3000 words on how to find help for commands (and discovering which commands exist) for a book. It's not a trivial task at all.

Normal computer users don't understand:

- What a filesystem is.

- How directories, files, and filesystems relate to one another.

- What a server is/does.

- How any kind of raw text whatsoever relates to what the computer "actually is" (the GUI)

- When or how or under what circumstances a program might read a file (say, re-reading a config file)

- What all that prompt noise means.

- Why some things they type on the command line work and why others don't—they don't understand that the things they're running are discrete programs and not somehow built in to the terminal or the OS, and they certainly don't understand the concept of a PATH.

- All kinds of magical bullshit you need to just know (or spend time finding out then internalizing) to use a command line (what the fuck is ".."? Why do I need to put "-" before things seemingly at random, but other times that breaks stuff? Et c., et c.)

- What they can even expect to be able to do on the command line (change permissions on files? Is that a thing you can do? Oh now you're going to need to learn how your OS permissions system works on a lower level than you've ever needed to know before, or else just blindly copy-paste from the Web and hope for the best)

And that list is far from comprehensive.

To boot:

In general, many popular unix utilities are cryptically named and they are not holistically designed. Consequently different programs take different flags for the same semantic, or some flags must be prefixed with a single dash and others with two dashes, or some flags are required to be passed in a particular order, or to view the docs for some commands it's `man command` and for others it's a `--help` flag but in all cases they're written for power users, or the fact that gnu utilities don't have the same interface as bsd utilities, etc.

And then there's the hot mess that is bash (or sh or zsh or...)...

I still occasionally stumble on the sequencing of arguments for chmod/chown and I can’t tell you off the top of my head which demands -r or -R. I’ve been doing this for years.

Oof, yeah, I hear you. Also I can never remember useradd vs adduser. That's hardly a scratch on the surface of the issues I have with unix utilities. Which isn't to say that I've seen any operating system with better utilities, but it's not hard to imagine (with the benefit of hindsight) how these might've been better designed.

In the early 1990s a friend used to help run the computer my parents bought me. When he wasn't around it was like a paperweight. Command lines old and new are intimidating because you begin with a cryptic prompt image. Microsoft Windows and MacOS classic were much more accessible. Their help hovers, tooltips, and systems were a breath of fresh air compared to DOS.

I was telling some college students how to do something and I said, "then hit return" and I had to explain that I meant the enter key. So it might take a while to be ready for the command line.

When we were dating my wife took an introductory CS course to humor me and I remember how difficult it was for her to grasp the concept that the programs you run on the command line happen in the context of a directory and you can change that directory. In her mind a directory was exactly a picture of a folder that you can double click on, not something that you run programs inside of.

Most forms of utility, including forms that come from using a CLI, have an acquisition cost. Rationally it makes sense to invest in things whose acquisition cost is lower than their utility. When a time horizon is introduced, for example, five minutes, the rational response changes. The acquisition cost becomes higher than the value generated. Once you've learned something there is no acquisition cost. So generalizing from that position produces the prediction that others are behaving irrationally. Which they would be, if their bandwidth was unlimited, but in practice they have to spend more time doing real time work because they live in a time context and only have a limited budget on which they can spend non-realtime thinking. Since there are a whole host of different things which have lower acquisition costs than expected utilities, some people end up exploring, say, genetics or rocket science, instead of computer interface usage optimizations. They weren't being irrational. They were constrained and they made the cooperative choice to let you explore one thing while they explored another. As a result, you can learn from them and they learn from you and the overall acquisitions costs for everyone are lowered.

Another way to say this is that the people who were too intimidated to use CLIs know things that you don't that are of the same character as your own knowledge of CLIs and it shouldn't have been overly complicated for you to know those in a modern society seeing as you are literate.

If you think people should really do what you are advocating: pave the roads. Lower the acquisition cost. Make it easier for people who are time constrained to do the thing you think they should be doing.

And so people did... and now we arrive at why things are the way they are.

It turns out that in the case of CLIs there is a usability problem. CLIs are constrained to text. Other mediums are a superset. They have more options for lowering the barrier. The people who are doing the paving in those cases are able to make better progress and faster! The masses flow to the GUI, not the CLI, because the GUI does a better job lowering the acquisition cost! It is a fight. On one hand we have the CLI, a hand tied behind its back. It is not allowed to go beyond text. In the other we have the other mediums. They have text, but are not limited to it. Should the CLI overcome them, they shall just put a little window wherein the CLI is present. They might do a nasty trick when they do this, stealing the fame of the CLI, by calling this a TextArea or a TextInput or even a TextBox.

Woe to the CLI, we type into the textboxes, supposing that the GUI has won.

I'd add to that: 'toy' CLI programs like fortune, cowsay, figlet, rev, etc, and some simple examples on how to wire them together using pipes, redirection, and substitutions.

think about barrier of entry.

Your anecdotal life story of overcoming early challenges with linux, that benefited your subsequent career is likely not scalable to the entire human population.

I think any reasonable person will align with the notion that low barrier of entry, coupled with an engaging curriculum to grow their level of computing expertise, will net much greater success.

But why not. The worst thing that happens is maybe a teacher needs to reflash the OS, if you tell kids that no we're not going to play Minecraft today, we're going to make Minecraft you can inspire a lifelong love of programming.

Sometimes you just got to strap yourself in and embrace the the terminal. If you're too afraid to try you'll never learn. Once around the same time I actually fried a motherboard by not mounting it properly, a nice computer repair shop owner gave me a bunch of motherboard spacers for free and told me to never Mount the motherboard directly to the case again.

I actually love programming in that it's one of the last Fields where you can teach yourself how to do amazing things for free. Sure if you need to deploy things you might need to spend two or three bucks a month on AWS, but even then you can get so much done locally.

You need a carrot at the end of the stick.

Ramp up the complexity, with appropriate award system, to help with engagement.

Your retroactive approach is saying - gosh, if I had my present day wisdom when I was I kid, then imagine all tactical things I can learn like apt or vim. I'm saying that is not a sustainable approach given a dataset that is the human population.

Actually I'm trying to say the opposite, I knew nothing when I was a kid. There was something awesome about getting your Wi-Fi driver to work after fighting it for 3 hours. It was very awesome struggle with Linux as a kid, not everything needs to be easy

But why is learning to use apt the correct layer of abstraction? Could you not just as easily say kids shouldn’t use apt—they need to learn to build from source?

It's a gateway drug, I successfully installed with apt, then with make, then moved to live in the CLI.

Apt and dnf/yum.

90% of Linux usage is rhel based (personal machine is fedora). And the other 10% is aws Ubuntu.

Id saying get good at 1 and know thr basics with tht other.

That may be regional. Over here I see ~5 Deb/Ubuntu installations for every RedHat-derivative.

Reply on news.ycombinator.com