[TUHS] [tuhs] The Unix shell: a 50-year view

[George Michaelson]

The emacs manual *printed, one-sided, bound to the desk with rods of
steel* which I read in the 1980s in leeds was one of the best
explanations of Virtual Memory I saw. I really struggled with the idea
of address segments, maps, the idea of address space being bigger than
physical memory (I think I drove a PhD student doing tutoring close to
tears on this in '79) but the Emacs manual said really clearly
up-front: "look, you can't address 32 bits of memory in "me" I only do
24, but this is how I do them, if you're interested"

The Vax VMS manual along side it (another 2 feet of single-sided
print) was probably as good, but more aimed at real engineers who
could think in RPN and had pocket protectors.

This was in a context where it was probably the go-to basis to try and
play with LISP because nobody really told you about any other REPL to
run in. I think even then I realised I wasn't going to ever want to
code a towers-of-hanoi, nor even really explore 24 bits of (virtual)
address space.

I hate the cult. I decided to re-learn the finger muscle memory, now I
can do bare-minimum in emacs for ORG and I think I'll go back to vi
where I belong. vi suffered from insufficient love. I had to stop
hating vim when it became the only real choice. (hate.. culty word,
that) VScode was interesting, as was Atom, and I suspect more than a
few people who code for a way of life here think this editor-wars
stuff is tedious.

I actually "think" in ed. I can't escape line-based semantic intent. I
carry my own personal koan which basically says "any algorithm which
needs more than 2 sentences or 1 screen of code to implement is
probably beyond you". Its a bit of a flaw.

On Wed, Jul 7, 2021 at 10:47 AM Theodore Ts'o <tytso at mit.edu> wrote:
>
> On Wed, Jul 07, 2021 at 01:17:00AM +0200, Tomasz Rola wrote:
> >
> > Well, when "everything" was small enough I really liked it. Nowadays
> > there seems to be a trend of making Emacs into another OS, like with
> > abomination we call the browser.
> >
> > https://www.emacswiki.org/emacs/EmacsApplicationFramework
> >
> > As long as I am able to trim it during compilation, they may put
> > whatever they want inside, but when I tried to unpack one of the
> > latest browser source code, it took more than 2.5 gigabytes (I am not
> > sure, it could have been a nightmare). I hope they will not apply this
> > crazyness to Emacs. I hope Emacs version 23 will keep compiling for a
> > while.
>
> Well, the old joke was that emacs stood for "eight megabytes and
> constantly swapping".  These days, sure, starting a fresh Emacs
> version 27 process has a SIZE of 364 megabytes with an RSS of 78
> megabytes.
>
> OTOH, starting a fresh copy of Konsole (KDE's current terminal
> emulator) has a SIZE 1383 megabytes with an RSS of 114 megabytes, and
> the single Konsole process running all of my terminal windows has a
> SIZE of 2160 megabytes (or just a touch over 2GB) with an RSS of 189
> megabytes.
>
> As a percentage of the 32 GB physical memory in my Desktop machine,
> I'm not too worried about the memory consumption of either the
> terminal windows or emacs, especially since the browser takes a lot
> more memory.  These days, I run my browser in a container to limit its
> physical memory usage to 12GB; systemd makes setting this up via a
> user unit file really easy.  :-)
>
>                                     - Ted
>
> # ~/.config/systemd/chrome.service
> [Unit]
> Description=Chrome Browser
>
> [Service]
> ExecStart=/usr/bin/google-chrome
> KillMode=process
> MemoryAccounting=true
> MemoryMax=12G
>
> P.S.  On my laptop I constrain the browser to only use 8GB, which just
> means that if I keep huge numbers of tabs open, some of them might get
> automatically killed and will have to get reloaded when I swtich back
> to that tab.  Sure, this wouldn't fly on a PDP-11, but as long as I'm
> more productive, I don't really worry about it.