From: George Michaelson <ggm@algebras.org>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: tuhs@minnie.tuhs.org
Subject: Re: [TUHS] [tuhs] The Unix shell: a 50-year view
Date: Wed, 7 Jul 2021 10:58:50 +1000 [thread overview]
Message-ID: <CAKr6gn2U_5uPXauFrHuwrH_1O0+Qki_PoWd0kqmJ8wkStZRePw@mail.gmail.com> (raw)
In-Reply-To: <YOT5ajNhoUqyBqvi@mit.edu>
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@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.
next prev parent reply other threads:[~2021-07-07 0:59 UTC|newest]
Thread overview: 109+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-02 21:24 Nelson H. F. Beebe
2021-07-02 21:36 ` Larry McVoy
2021-07-02 21:56 ` Henry Bent
2021-07-02 23:12 ` Steve Nickolas
2021-07-02 23:49 ` Steffen Nurpmeso
2021-07-03 13:34 ` Steffen Nurpmeso
2021-07-03 13:56 ` Richard Salz
2021-07-03 12:04 ` Thomas Paulsen
2021-07-03 13:20 ` Dan Cross
2021-07-03 17:37 ` Theodore Ts'o
2021-07-03 17:57 ` Warner Losh
2021-07-03 18:10 ` Theodore Ts'o
2021-07-03 20:02 ` Dan Cross
2021-07-04 0:47 ` Tomasz Rola
2021-07-04 4:36 ` Larry McVoy
2021-07-04 14:56 ` Dan Cross
2021-07-04 16:07 ` Theodore Ts'o
2021-07-04 20:10 ` David Barto
2021-07-05 0:25 ` Larry McVoy
2021-07-05 1:23 ` John Cowan
2021-07-04 12:48 ` Dan Cross
2021-07-05 7:14 ` Tomasz Rola
2021-07-05 16:26 ` John Cowan
2021-07-06 23:17 ` Tomasz Rola
2021-07-06 23:47 ` Steve Nickolas
2021-07-06 23:49 ` Warner Losh
2021-07-06 23:48 ` John Cowan
2021-07-07 0:46 ` Theodore Ts'o
2021-07-07 0:58 ` George Michaelson [this message]
2021-07-07 2:48 ` Larry McVoy
2021-07-07 18:32 ` Tomasz Rola
2021-07-07 20:50 ` Michael Kjörling
2021-07-08 6:46 ` [TUHS] Overgrown ffox (was: The Unix shell: a 50-year view) Tomasz Rola
2021-07-08 13:59 ` Derek Fawcus
2021-07-08 19:25 ` Steffen Nurpmeso
2021-07-08 19:37 ` Steffen Nurpmeso
2021-07-08 20:40 ` Steffen Nurpmeso
2021-07-08 22:23 ` Kevin Bowling
2021-07-08 21:47 ` [TUHS] [tuhs] The Unix shell: a 50-year view Theodore Ts'o
2021-07-09 20:14 ` Michael Kjörling
2021-07-07 13:54 ` Tony Finch
2021-07-06 16:05 ` Clem Cole
2021-07-09 22:19 ` Tomasz Rola
2021-07-04 20:10 ` Tony Finch
2021-07-05 3:59 ` Theodore Ts'o
2021-07-05 15:08 ` Steffen Nurpmeso
2021-07-05 3:52 ` Bakul Shah
2021-07-04 18:17 ` John Dow via TUHS
2021-07-04 19:46 ` Clem Cole
2021-07-05 1:33 ` Noel Hunt
2021-07-05 2:38 ` Clem Cole
2021-07-05 2:51 ` Warner Losh
2021-07-05 3:03 ` Clem Cole
2021-07-05 3:01 ` Clem Cole
2021-07-05 5:22 ` Noel Hunt
2021-07-06 5:10 ` Nevin Liber
2021-07-06 13:30 ` Clem Cole
2021-07-06 16:23 ` Theodore Ts'o
2021-07-07 1:57 ` Dan Cross
2021-07-07 2:52 ` Larry McVoy
2021-07-07 5:19 ` Andrew Warkentin
2021-07-07 18:28 ` Jon Steinhart
2021-07-10 11:51 ` [TUHS] " Ralph Corderoy
2021-07-10 13:54 ` Henry Bent
2021-07-10 14:12 ` Ralph Corderoy
2021-07-10 16:57 ` [TUHS] Death by bug [formerly The Unix shell: a 50-year view] Jon Steinhart
2021-07-11 8:53 ` [TUHS] Death by bug Ralph Corderoy
2021-07-11 9:04 ` arnold
2021-07-12 1:42 ` Theodore Y. Ts'o
2021-07-12 2:57 ` Jon Steinhart
2021-07-12 6:39 ` arnold
2021-07-12 9:56 ` Ralph Corderoy
2021-07-11 16:10 ` Jon Steinhart
2021-07-12 10:37 ` Ralph Corderoy
2021-07-06 13:40 ` [TUHS] [tuhs] The Unix shell: a 50-year view John Cowan
2021-07-06 14:12 ` Chet Ramey
2021-07-07 0:53 ` Nevin Liber
2021-07-07 13:08 ` Chet Ramey
2021-07-07 15:15 ` Richard Salz
2021-07-03 0:09 ` Andrew Warkentin
2021-07-03 15:49 ` Andy Kosela
2021-07-04 23:24 ` [TUHS] Is C obsolete? (was Re: [tuhs] The Unix shell: a 50-year view) Derek Fawcus
2021-07-04 23:50 ` Nemo Nusquam
2021-07-05 0:15 ` Dan Stromberg
2021-07-05 0:21 ` Larry McVoy
2021-07-05 2:36 ` John Cowan
2021-07-05 2:59 ` Richard Salz
2021-07-05 3:47 ` Larry McVoy
2021-07-05 4:02 ` Dan Stromberg
2021-07-05 13:45 ` Steffen Nurpmeso
2021-07-05 20:15 ` Dan Stromberg
2021-07-05 21:05 ` Larry McVoy
2021-07-05 21:29 ` Clem Cole
2021-07-05 22:22 ` Brantley Coile
2021-07-06 4:35 ` Dan Stromberg
2021-07-06 4:44 ` Warner Losh
2021-07-06 5:58 ` Rico Pajarola
2021-07-06 13:05 ` Clem Cole
2021-07-05 12:11 ` Thomas Paulsen
2021-07-05 4:08 ` Dan Stromberg
2021-07-05 4:23 ` George Michaelson
2021-07-05 14:43 ` Larry McVoy
2021-07-05 15:17 ` Steffen Nurpmeso
2021-07-05 15:36 ` Steffen Nurpmeso
2021-07-05 15:53 ` Mike Markowski
2021-07-05 16:39 ` Warner Losh
2021-07-05 19:02 ` Clem Cole
2021-07-02 22:27 ` [TUHS] [tuhs] The Unix shell: a 50-year view Chet Ramey
2021-07-02 23:09 ` Steve Nickolas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAKr6gn2U_5uPXauFrHuwrH_1O0+Qki_PoWd0kqmJ8wkStZRePw@mail.gmail.com \
--to=ggm@algebras.org \
--cc=tuhs@minnie.tuhs.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).