The part the author shared about the huge overhead cost of firing up emacs, especially in a multi-user environment (I learned about emacs vs vi holy war back on a multi-user Solaris environment), our Unix professor strongly encouraged us to learn vi. He said "vi is part of every standard Unix install, so when you ssh into a box, you'll always have your editor and it won't steal all the CPU from the other users when you fire it up."
Feels monumental to see that come to an end decades later.
I think you're quite confused. Emacs always avoided a huge startup hit by loading elisp code into temacs (bare bones emacs that only exists when building it) and then dumping it with unexec to produce the emacs that is distributed. A decade ago, glibc stopped supporting unexec and emacs had to switch to a different method of incorporating the elisp code and avoiding the startup time, but the unexec code was still there. Now, a decade later, that code--which was not being used--has finally been removed.
None of that has anything to with emacs vs vi -- the point that your professor was making was that vi was distributed by default with UNIX so it was always there, whereas emacs needed to be installed (which wasn't even an option on servers).
Well, this was over 30 years ago that I was sitting in that class, and the resources the emacs required vs vi was definitely part of the discussion. We were working in a shared environment on a solaris system, and if the whole class fired up emacs for a class session, the effects were definitely experienced by all the users on the system at the time.
I'll add a little context. I mentioned that it was 30 years ago. My personal computer at the time was a 486DX-50 with 16 MB of RAM, and the mainframe we were tied to had maybe 2 GB of Ram? For 200+ users to share. It's easy to forget how far hardware has developed since then.
The part the author shared about the huge overhead cost of firing up emacs
TFA's wording on that is a bit misleading.
My Emacs with no config starts in 0.1s (110 ms). My Emacs with my huge config (between 3 000 to 4 000 lines of custom Elisp code) starts in 1.2s or so.
And then of course modern day Emacs is so stable that the thing can stay up for weeks without needing a restart.
It's been a very long time that the "cost of firing up Emacs" is smaller than the cost of firing up 99% of all the software out there (looking at you AppImage , flatpaks, browsers, any desktop app really, etc.).
That's funny, because our professor didn't tell us that and I remember doing my projects with four terminal windows logged into the server and three of them running separate instances of emacs :D. I wonder how much I bogged down that mid-90s HP-UX machine.
Comments
The part the author shared about the huge overhead cost of firing up emacs, especially in a multi-user environment (I learned about emacs vs vi holy war back on a multi-user Solaris environment), our Unix professor strongly encouraged us to learn vi. He said "vi is part of every standard Unix install, so when you ssh into a box, you'll always have your editor and it won't steal all the CPU from the other users when you fire it up."
Feels monumental to see that come to an end decades later.
I think you're quite confused. Emacs always avoided a huge startup hit by loading elisp code into temacs (bare bones emacs that only exists when building it) and then dumping it with unexec to produce the emacs that is distributed. A decade ago, glibc stopped supporting unexec and emacs had to switch to a different method of incorporating the elisp code and avoiding the startup time, but the unexec code was still there. Now, a decade later, that code--which was not being used--has finally been removed.
None of that has anything to with emacs vs vi -- the point that your professor was making was that vi was distributed by default with UNIX so it was always there, whereas emacs needed to be installed (which wasn't even an option on servers).
Well, this was over 30 years ago that I was sitting in that class, and the resources the emacs required vs vi was definitely part of the discussion. We were working in a shared environment on a solaris system, and if the whole class fired up emacs for a class session, the effects were definitely experienced by all the users on the system at the time.
I'll add a little context. I mentioned that it was 30 years ago. My personal computer at the time was a 486DX-50 with 16 MB of RAM, and the mainframe we were tied to had maybe 2 GB of Ram? For 200+ users to share. It's easy to forget how far hardware has developed since then.
Just say "oh, I see".
TFA's wording on that is a bit misleading.
My Emacs with no config starts in 0.1s (110 ms). My Emacs with my huge config (between 3 000 to 4 000 lines of custom Elisp code) starts in 1.2s or so.
And then of course modern day Emacs is so stable that the thing can stay up for weeks without needing a restart.
It's been a very long time that the "cost of firing up Emacs" is smaller than the cost of firing up 99% of all the software out there (looking at you AppImage , flatpaks, browsers, any desktop app really, etc.).
Stock Emacs: 110ms (Debian Trixie / AMD 7700X / WD-SN850X SSD).
Boom.
That's funny, because our professor didn't tell us that and I remember doing my projects with four terminal windows logged into the server and three of them running separate instances of emacs :D. I wonder how much I bogged down that mid-90s HP-UX machine.