# 2026.10.05 / Monday

## The Horse You Rode in On

One of the worst -- or saddest -- things I can experience are
people coming to Unix[1] from other systems, who try to use the
new system the same way they used the one they left.
There's of course merit in keeping going after being thrown in
deep, unfamiliar waters. I can't blame a fresh Windows expat for
using GUI, a file manager, nano as an editor - they need to get
their stuff done, and that's how they did the things "on the other
side". I remember how it was for me, when I moved from DOS/Windows
(I'm old) environment onto Unix (Linux and the "real" one - SCO).
I relied overly on Midnight Commander (because it's basically
Norton I knew from DOS) and GUI Vim. Even if I read a lot about
Unix shell and tools long before I used the Unix terminal for the
first time.

## Dependence on known how-to's

An average "convertite" usually isn't ignorant - they did quite
well using their IDEs, File Explorer/Finder, "there was an app for
this" - whatever "this" in question was.
* I used Norton Commander, so finding, installing, and using
  Midnight Commander was a no-brainer [and that slowed me down]
* I used Turbo Pascal environment - doing everything from inside
  the IDE was a natural thing.
  I spent years in Vim, doing most from within it, and constantly
  looking for plugins that would add some missing functionality.
  My Vim skills got much better - it didn't make me a better, more
  efficient Unix user.
* "An app for everything" - loading a new program, enabling a new
  function out-of-the-box is way too easy these days; it
  quickly can become a 'leftpad' situation - instead of learning
  how to do a relatively simple task with what's already on the
  system (usually there's a _system_ tool that can do it) new
  users install yet another doohickey that will add .bak extension
  to all files in a directory, or center the output text.
* "The app for everything" - there's a different way too, the
  Emacs way - doing everything in Emacs, while completely ignoring
  the system beneath. Objectively - not the worst idea, at least
  they learn _something_.

## Working around stuff that isn't there anymore

The old Windows terminal, and the scripting language in it were
awful. People learnt to work around it, not within it.
You need to edit a line? Copy it into notepad, edit there, paste
back.
You need to repeat the last command? Oh, history isn't working,
type it again. Or paste it from the notepad.
You need to copy a bunch of files? Switch to the Explorer, copy
them with the mouse.
None of it is needed. You just don't know yet it is possible, and
you take a longer route to avoid obstacles that do not exist.
[Primeagean shared once a story about his job interview: the task
was to find files containing a given class name. He wrote a quick,
clean Java program, that traversed the directory tree, found all
.java files, scanned them for the pattern and displayed a list of
files, with line numbers etc. The interviewer looked at it and
said: "you could use grep for that".] One does not have to be an
idiot to not be efficient.

## The second site problem

So, where's the problem? Well, there might be none, if your
personal system is everything you use. A system comes seldom
alone these days, though - at some point (it might be a VPS you
run to host your webpage, it might be an online community, it
might be job) you might find yourself in an environment where the
basic system installation is all you get. No GUI, no Helix, no
Fish. They'll give you Putty and it's nothing like your Warp.
You feel like that one time you tried to write something after
watching a 2-hour tutorial on Youtube. An empty head.
"I use Arch, BTW", but somehow you're lost on a console of a
system that wasn't configured to your expectations...

## Zone of Proximal Development

That's Lev Vygotsky's theory. He saw a gap between what a person
can do independently, and what they can do with guidance and
encouragement from a "More Knowledgeable Other" [MKO].

The first step is the hardest. It's nearly impossible (and quite
impractical) to master everything, but most of the Unix tools can
be used in a "basic" way after reading the "--help" output,
sometimes with a seemingly endless learning curve behind the
"naive" usage. Begin small, and expand from there.

An example task: replace all occurrences of a string in a text file.
Well, editing files is a text editor thing, so:
1. you can scroll down, replace the found strings, repeat.
2. the same, but use '.' to repeat the last edit, instead of
  retyping the word over and over again.
3. Let vim find the string ('/string'), replace it, find next
  ('n').
4. Let vim replace the string globally (:%s/string/replacement/g)

But then:
5. Use sed instead. `sed -ie 's/string/replacement/g' file`

The shell itself makes the gradual improvement a natural thing - a
rule, not an exception. Just pipe what you already have into the
next conversion stage.

Grass doesn't grow on a busy street. Getting better happens when
we leave our comfort zones. [Also the "comfort" is questionable,
when you're spending your time on forcing one system to work like
a completely different one, only because you knew the ropes of the
latter].

--
[MKO] MKO is a person or a (digital) tool with a better
understanding of the specific task. Plenty of it:
* manual/info pages
* source code - plenty of it to look at and try out
* community, although - depending on what community it is - it
  might be either extremely helpful or extremely toxic.
* online content (my rule of thumb is: the more boring the desktop
  looks like - the better the content)


--
[1] "but akshually Linux is a Unix-like..." Sod off.