7 Jul
2021
7 Jul
'21
6:58 a.m.
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(a)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.