we're stuck in the 90s at best for Linux cli tool defaults in ways that really hamper new users who can't dedicate a hobby to learning the Linux cli until after they've already gotten comfortable in it
I understand how much labor it would take, it def is one of those things that needs a movement behind it, getting to the point where the Linux utility ecosystem isn't stuck on 1990s conceptual updates to 1970s programs for "but i like it that way" reasons.
just have less and other not-actually-discoverable commands exist as optionals, or they're even small enough to just be in some utils package or whatever.
but I'm so tired of any talk of improving the experience ending in "yeah but updating these would break scripts", so we're stuck at the earliest version some high-uptime-on-the-mailing-list person wrote their load bearing config file on.
but as more and more Linux users come from non computer backgrounds, whether it's people joining IT or software dev or security or 3d printing or scientific research or etc, we really should be thinking of this as an actual "digital divide". Not just in terms of access to computers but in terms of access to spare time you can dedicate to a thing that could otherwise get you running and you learn the rest as you go.
Because right now, you need free time to actually learn it. Because of the passage of time:
- all the in jokes of the names of various tools fade from memory (
lessis more thanmoreetc) - all of the mnemonics/abbreviations are before everyone else agreed on a de facto standard
- yank / kill as clipboard terms (represented as y, k, not even as labels except in manuals)
- write for saving
- b for page up in pagers, but sometimes shift space
- i could go on but i don't care. you know the ones.
- bindings that don't preserve the clipboard bindings even most Linux graphical applications follow outside the terminal
- I realize how hard rebinding vim would be but see above where that's holding people back as long as vi/m is the default. Emacs, Nano are just as guilty.
- very few help popups that can be used as cheat sheets
mean it starts being another programming language to learn, with inconsistent rules.
Instead of being tools on a workbench you can chain together if you want once you've learned more about them.
and I think if anyone actually believes there's a "pipeline problem" (which there is, though employer biases in hiring and management, and educator biases matter a lot more) you can't just ignore this.
I'm fine with the tools as they're there, but it took a good half decade of non-hobby-time use to get there.
especially as more and more time goes on and less and less people have exposure to the concepts, it seems like this should probably be a priority for bigcorps, because we're about to have a generation of devs and ops people who don't get how things work under the hood really, until they're awhile on the job.
as a side rant, $PAGERs for man are all terrible for new and old people, and probably a good chunk of why no one is reading the manual. (The common lack of key-idea isolation making them hard to grep or skim and actual find what you need being a larger issue) the first person that writes a good *roff to wikitext transpiler that doesn't miss features will save lives. Or even *roff -> markdown-with-wiki-style-inlinks.
