10 Jul
2025
10 Jul
'25
2:40 p.m.
Folks,
For those of you who were unable to attend, I took this photo
yesterday, at the end of the closing remarks for ATC'25 in Boston:
https://photos.app.goo.gl/tcaAFQgjGPn5s8Dh7
As most of you know, USENIX has sunsetted the conference, and this
was the last time ATC will be run, though of course other USENIX
conferences will continue in its place. But I wanted to be in the room
as it ended, and I snapped this as everything was winding down, and am
now sharing it with our community.
For those of you who were able to attend, it was wonderful to see
a number of familiar faces, and also meet some folks I've known of and
interacted with here and elsewhere, face-to-face. USENIX also turned
50 this year, and the organization made sure to create space for
reflection on its history; remembrances were shared by Clem Cole, Bill
Cheswick, Doug McIlroy, Andrew Hume, Peter Honeyman, Tom Lyon, and
others.
On a personal note, I found this very meaningful: I was once told,
"never meet your heroes." However, in the Unix community, by and large
my heroes are wonderfully pleasant, generous, and kind people in real
life, all of whom have either indirectly or directly had a profound
influence on the course of my career and life. Thank you for that; it
was an honor to share space with you.
While ATC is ending, it is also clear that there is a vibrant
research community flourishing, building on the legacy of work created
by the USENIX community and shared through this conference. Many of
you nurtured that community, laying its framework, shepherding and
guiding its work, cultivating new generations of researchers while
providing the basic tools we all depend on, and thus creating the
fertile ground on which it now grows. What greater professional
accomplishment could one hope for?
Perhaps it is best not to think of this as an end, but an epoch
marking the transition from one stage of the community's evolution to
the next.
- Dan C.
10 Jul
10 Jul
4:19 p.m.
Nice note, Dan.
On Thu, Jul 10, 2025 at 10:40:32AM -0400, Dan Cross wrote:
On a personal note, I found this very meaningful:
I was once told,
"never meet your heroes." However, in the Unix community, by and large
my heroes are wonderfully pleasant, generous, and kind people in real
life, all of whom have either indirectly or directly had a profound
influence on the course of my career and life. Thank you for that; it
was an honor to share space with you.
I couldn't agree more. Starting with Dennis, everyone has been willing
to share knowledge. I have a memory of Dennis having "handlers" at
Usenix so one person wouldn't eat up all of his time.
Much thanks to all those shoulders that lifted us up.
--lm
7:47 p.m.
On Thu, Jul 10, 2025 at 12:19 PM Larry McVoy <lm(a)mcvoy.com> wrote:
I couldn't agree more. Starting with Dennis, everyone has been willing
to share knowledge. I have a memory of Dennis having "handlers" at
Usenix so one person wouldn't eat up all of his time.
That was not true, as much as the community might have intervened if we
thought somebody was a little out of line.* i.e.*, we might have been
protective of him. Dennis was really too nice to have said anything.
8:04 p.m.
On 7/10/2025 2:47 PM, Clem Cole wrote:
On Thu, Jul 10, 2025 at 12:19 PM Larry McVoy <lm(a)mcvoy.com
<mailto:lm@mcvoy.com>> wrote:
I couldn't agree more. Starting with Dennis, everyone has been willing
to share knowledge. I have a memory of Dennis having "handlers" at
Usenix so one person wouldn't eat up all of his time.
That was not true, as much as the community might have intervened if we
thought somebody was a little out of line./i.e./, we might have been
protective of him. Dennis was really too nice to have said anything.
The one time I spoke to Dennis, I went up to the lectern after he spoke
somewhere, probably a USENIX Technical Conference, to shake his hand and
thank him. As I recall, neither of us said much, no one else was nearby.
--
voice: +1.512.784.7526 e-mail: sauer(a)technologists.com
fax: +1.512.346.5240 Web: https://technologists.com/sauer/
Facebook/Google/LinkedIn/mas.to: CharlesHSauer
8:12 p.m.
On Thu, Jul 10, 2025 at 03:47:38PM -0400, Clem Cole wrote:
On Thu, Jul 10, 2025 at 12:19???PM Larry McVoy
<lm(a)mcvoy.com> wrote:
Don't know what to say, Clem, we normally agree on everything. But I'm
not making it up, I was there, waiting to talk to Dennis, someone else
was talking to him and at some point someone intervened and moved the
guy on. Maybe it was a one time thing, I dunno? Seemed like it wasn't
the handler's first time doing that.
Water under the bridge though.
--
---
Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
I couldn't agree more. Starting with Dennis, everyone has been willing
to share knowledge. I have a memory of Dennis having "handlers" at
Usenix so one person wouldn't eat up all of his time.
That was not true, as much as the community might have intervened if we
thought somebody was a little out of line.* i.e.*, we might have been
protective of him. Dennis was really too nice to have said anything. 
15 Jul
15 Jul
7:10 p.m.
On 10/07/2025 21:47, Clem Cole wrote:
That was not true, as much as the community might have
intervened if we
thought somebody was a little out of line./i.e./, we might have been
protective of him. Dennis was really too nice to have said anything.
I remember one of the EUUG conferences long, long ago, where a
bunch of us stood talking. One of us was wearing a T-shirt with
the famous "You are not expected to understand this" V6 code
on it. A young (Austrian, if I remember correctly) academic guy
came up to us and said "I understand what it does - do you?".
Dennis, who was wearing the shirt, just said "Yes, I wrote it"
with a light smile and the warm, friendly tone he so often had.
Julf
11:39 p.m.
I've reached the stage of incompetency where if I can remember what a
logarithm IS, It's a good day, and if I can remember why you use them it's
a stellar day. I'd put it on a tee shirt but I have to work out which is
the skinside and which is the outside first. Used to be the seams and
fruit-of-the-loom/union-made label told you but now people wear seams as a
badge of pride and labels are outré
-G
16 Jul
16 Jul
12:01 a.m.
I just noticed that algorithm and logarithm just have a couple of
letters transposed from each other. So that's the kind of rabbit hole I
get lost in most days.
On 07/15/2025 04:39 PM, George Michaelson wrote:
I've reached the stage of incompetency where if I
can remember what a
logarithm IS, It's a good day, and if I can remember why you use them
it's a stellar day. I'd put it on a tee shirt but I have to work out
which is the skinside and which is the outside first. Used to be the
seams and fruit-of-the-loom/union-made label told you but now people
wear seams as a badge of pride and labels are outré
-G
11:13 a.m.
Ah, rabbit holes. Dangerous things. I went down the ed rabbit hole around a month ago and
no sign of me finding my way back out any time soon.
I got obsessed with getting ed running on every device I have including my phones and then
the big rabbit hole off that first one was learning how to use it properly and to the
fullest of its abilities. That'll take a while.
My library of ed related publications is getting so big its likely what's blocking
the exit to the rabbit hole. On the plus side it has sharpened my typing skills, improved
my patience and I I've learned to work out for myself what I've done to cause ed
to say ?, instead of just typing h+Enter.
As rabbit holes go, it's been stimulating so far and I could be stuck in worse
places.
Have a safe one!
Cameron
-------- Original Message --------
On 16/07/2025 01:01, Luther Johnson <luther.johnson(a)makerlisp.com> wrote:
I just noticed that algorithm and logarithm just have
a couple of
letters transposed from each other. So that's the kind of rabbit hole I
get lost in most days.
12:09 p.m.
IMHO, the best tutorials on ed are the chapters in "Software Tools"
and "Software Tools in Pascal" where Kernighan and Plauger write
a basic version of it. I recommend both books highly, despite
their age.
"Software Tools" literally changed my life. :-)
Arnold
Cameron Míċeál Tyre via TUHS <tuhs(a)tuhs.org> wrote:
Ah, rabbit holes. Dangerous things. I went down the ed
rabbit hole around
a month ago and no sign of me finding my way back out any time soon.
I got obsessed with getting ed running on every device I have including my
phones and then the big rabbit hole off that first one was learning how to
use it properly and to the fullest of its abilities. That'll take a while.
My library of ed related publications is getting so big its likely
what's blocking the exit to the rabbit hole. On the plus side it has
sharpened my typing skills, improved my patience and I I've learned to
work out for myself what I've done to cause ed to say ?, instead of just
typing h+Enter.
As rabbit holes go, it's been stimulating so far and I could be stuck
in worse places.
Have a safe one!
Cameron
-------- Original Message --------
On 16/07/2025 01:01, Luther Johnson <luther.johnson(a)makerlisp.com> wrote:
I just noticed that algorithm and logarithm just
have a couple of
letters transposed from each other. So that's the kind of rabbit hole I
get lost in most days.
12:53 p.m.
Behind the glass wall in the basement of the University of Georgia graduate studies
building, was the wide floor of the computer center and behind that was the office of one
of my mentors, Bob Stearms. As he typed PL/1 into his 3278 terminal--channel connected no
less--I spied a plain white book sitting on a shelf in his book case with an orange title
"SOFTWARE TOOLS." I picked it up and flipped through it. It was 1980, the first
year of my marriage.
"What's this?", I asked as I pick up the volume and started flipping
through it.
"It's from the Unix guys. They wrote a pre-processor for FORTRAN and called it
Ratfor. Then they wrote a bunch of the Unix programs in it."
"Can I borrow it?"
"Sure."
I changed my life. I still use what I learned from it forty-five years later. And still
very happily married to the bride of my youth.
After Bob passed away, Frieda gave me that volume. It's one of my prized possessions.
Forget Unix and C. The biggest research achievement to come out of 1127 was a clear
understanding of how to program.
Brantley
On Jul 16, 2025, at 8:09 AM, arnold(a)skeeve.com wrote:
IMHO, the best tutorials on ed are the chapters in "Software Tools"
and "Software Tools in Pascal" where Kernighan and Plauger write
a basic version of it. I recommend both books highly, despite
their age.
"Software Tools" literally changed my life. :-)
Arnold
Cameron Míċeál Tyre via TUHS <tuhs(a)tuhs.org> wrote:
> Ah, rabbit holes. Dangerous things. I went down the ed rabbit hole around
> a month ago and no sign of me finding my way back out any time soon.
>
> I got obsessed with getting ed running on every device I have including my
> phones and then the big rabbit hole off that first one was learning how to
> use it properly and to the fullest of its abilities. That'll take a while.
>
> My library of ed related publications is getting so big its likely
> what's blocking the exit to the rabbit hole. On the plus side it has
> sharpened my typing skills, improved my patience and I I've learned to
> work out for myself what I've done to cause ed to say ?, instead of just
> typing h+Enter.
>
> As rabbit holes go, it's been stimulating so far and I could be stuck
> in worse places.
>
> Have a safe one!
>
> Cameron
>
>
> -------- Original Message --------
> On 16/07/2025 01:01, Luther Johnson <luther.johnson(a)makerlisp.com> wrote:
>
>> I just noticed that algorithm and logarithm just have a couple of
>> letters transposed from each other. So that's the kind of rabbit hole I
>> get lost in most days.
>>
>
6:11 p.m.
Hello Brantley,
Really enjoyed reading your recollections, thank you!
I guess, if no-one asks me if there's anything I want for my upcoming birthday,
I will get hold of a copy of "Software Tools" myself.
I found a list of former members of 1127 which includes where many of
them went to afterward: http://spinroot.com/gerard/1127_alumni.html
It makes interesting reading, at least for a newcomer like me.
Best regards,
Cameron
On Wednesday, July 16th, 2025 at 1:53 PM, Brantley Coile <brantley(a)coraid.com>
wrote:
Behind the glass wall in the basement of the University of Georgia graduate studies
building, was the wide floor of the computer center and behind that was the office of one
of my mentors, Bob Stearms. As he typed PL/1 into his 3278 terminal--channel connected no
less--I spied a plain white book sitting on a shelf in his book case with an orange title
"SOFTWARE TOOLS." I picked it up and flipped through it. It was 1980, the first
year of my marriage.
"What's this?", I asked as I pick up the volume and started flipping
through it.
"It's from the Unix guys. They wrote a pre-processor for FORTRAN and called it
Ratfor. Then they wrote a bunch of the Unix programs in it."
"Can I borrow it?"
"Sure."
I changed my life. I still use what I learned from it forty-five years later. And still
very happily married to the bride of my youth.
After Bob passed away, Frieda gave me that volume. It's one of my prized
possessions.
Forget Unix and C. The biggest research achievement to come out of 1127 was a clear
understanding of how to program.
Brantley
9:59 p.m.
Seventh Edition Unix came with a program 'learn', written by
Brian Kernighan, which was a front-end to a group of tutorials
on 'ed', 'tbl', 'troff' etc.
The 'ed' tutorial was a wonderful introduction to the editor,
and a model of clarity, as indeed they all were, but that was
typical of everything written by researchers who were at 1127.
On Wed, 16 Jul 2025 at 22:53, Brantley Coile <brantley(a)coraid.com> wrote:
Behind the glass wall in the basement of the
University of Georgia
graduate studies building, was the wide floor of the computer center and
behind that was the office of one of my mentors, Bob Stearms. As he typed
PL/1 into his 3278 terminal--channel connected no less--I spied a plain
white book sitting on a shelf in his book case with an orange title
"SOFTWARE TOOLS." I picked it up and flipped through it. It was 1980, the
first year of my marriage.
"What's this?", I asked as I pick up the volume and started flipping
through it.
"It's from the Unix guys. They wrote a pre-processor for FORTRAN and
called it Ratfor. Then they wrote a bunch of the Unix programs in it."
"Can I borrow it?"
"Sure."
I changed my life. I still use what I learned from it forty-five years
later. And still very happily married to the bride of my youth.
After Bob passed away, Frieda gave me that volume. It's one of my prized
possessions.
Forget Unix and C. The biggest research achievement to come out of 1127
was a clear understanding of how to program.
Brantley
On Jul 16, 2025, at 8:09 AM, arnold(a)skeeve.com
wrote:
IMHO, the best tutorials on ed are the chapters in "Software Tools"
and "Software Tools in Pascal" where Kernighan and Plauger write
a basic version of it. I recommend both books highly, despite
their age.
"Software Tools" literally changed my life. :-)
Arnold
Cameron Míċeál Tyre via TUHS <tuhs(a)tuhs.org> wrote:
> Ah, rabbit holes. Dangerous things. I went down the ed rabbit hole
around
> a month ago and no sign of me finding my way
back out any time soon.
>
> I got obsessed with getting ed running on every device I have including
my
> phones and then the big rabbit hole off that
first one was learning how
to
> use it properly and to the fullest of its
abilities. That'll take a
while.
>
> My library of ed related publications is getting so big its likely
> what's blocking the exit to the rabbit hole. On the plus side it has
> sharpened my typing skills, improved my patience and I I've learned to
> work out for myself what I've done to cause ed to say ?, instead of just
> typing h+Enter.
>
> As rabbit holes go, it's been stimulating so far and I could be stuck
> in worse places.
>
> Have a safe one!
>
> Cameron
>
>
> -------- Original Message --------
> On 16/07/2025 01:01, Luther Johnson <luther.johnson(a)makerlisp.com>
wrote:
>
>> I just noticed that algorithm and logarithm just have a couple of
>> letters transposed from each other. So that's the kind of rabbit hole I
>> get lost in most days.
>>
>
11:57 p.m.
On Wed, Jul 16, 2025 at 6:00 PM Noel Hunt <noel.hunt(a)gmail.com> wrote:
Seventh Edition Unix came with a program
'learn', written by
Brian Kernighan, which was a front-end to a group of tutorials
on 'ed', 'tbl', 'troff' etc.
It's also been on bwk's web site.
https://web.archive.org/web/20080921164132/http://cm.bell-labs.com/cm/cs/wh…
Scroll down for "learn"
17 Jul
17 Jul
5:08 p.m.
Learn's great and it's "easy" to get working in SimH. I included it in
my tutorial:
https://decuser.github.io/unix/research-unix/v7/2024/05/23/research-unix-v7…
Will
On 7/16/25 16:59, Noel Hunt wrote:
Seventh Edition Unix came with a program
'learn', written by
Brian Kernighan, which was a front-end to a group of tutorials
on 'ed', 'tbl', 'troff' etc.
The 'ed' tutorial was a wonderful introduction to the editor,
and a model of clarity, as indeed they all were, but that was
typical of everything written by researchers who were at 1127.
On Wed, 16 Jul 2025 at 22:53, Brantley Coile <brantley(a)coraid.com> wrote:
Behind the glass wall in the basement of the University of Georgia
graduate studies building, was the wide floor of the computer
center and behind that was the office of one of my mentors, Bob
Stearms. As he typed PL/1 into his 3278 terminal--channel
connected no less--I spied a plain white book sitting on a shelf
in his book case with an orange title "SOFTWARE TOOLS." I picked
it up and flipped through it. It was 1980, the first year of my
marriage.
"What's this?", I asked as I pick up the volume and started
flipping through it.
"It's from the Unix guys. They wrote a pre-processor for FORTRAN
and called it Ratfor. Then they wrote a bunch of the Unix programs
in it."
"Can I borrow it?"
"Sure."
I changed my life. I still use what I learned from it forty-five
years later. And still very happily married to the bride of my youth.
After Bob passed away, Frieda gave me that volume. It's one of my
prized possessions.
Forget Unix and C. The biggest research achievement to come out of
1127 was a clear understanding of how to program.
Brantley
On Jul 16, 2025, at 8:09 AM, arnold(a)skeeve.com
wrote:
IMHO, the best tutorials on ed are the chapters in "Software Tools"
and "Software Tools in Pascal" where Kernighan and Plauger write
a basic version of it. I recommend both books highly, despite
their age.
"Software Tools" literally changed my life. :-)
Arnold
Cameron Míċeál Tyre via TUHS <tuhs(a)tuhs.org> wrote:
> Ah, rabbit holes. Dangerous things. I went down the ed rabbit
hole around
> a month ago and no sign of me finding my way
back out any time
soon.
>
> I got obsessed with getting ed running on every device I have
including my
> phones and then the big rabbit hole off that
first one was
learning how to
> use it properly and to the fullest of its
abilities. That'll
take a while.
>
> My library of ed related publications is getting so big its likely
> what's blocking the exit to the rabbit hole. On the plus side
it has
> sharpened my typing skills, improved my
patience and I I've
learned to
> work out for myself what I've done to
cause ed to say ?,
instead of just
> typing h+Enter.
>
> As rabbit holes go, it's been stimulating so far and I could be
stuck
> in worse places.
>
> Have a safe one!
>
> Cameron
>
>
> -------- Original Message --------
> On 16/07/2025 01:01, Luther Johnson
<luther.johnson(a)makerlisp.com> wrote:
>
>> I just noticed that algorithm and logarithm just have a couple of
>> letters transposed from each other. So that's the kind of
rabbit hole I
>> get lost in most days.
>>
>
16 Jul
16 Jul
5:45 p.m.
Hello Arnold,
Thank you, sir. I have "Software Tools In Pascal" and am hopeful that I will
soon get asked if I have anything I want for my upcoming birthday. "Software
Tools" will be my answer. Your commment about the age of these books is
something I concur with. I find them easier to read and understand than many
modern publications. The one modern publication that I have found to be both
fun and easy to read is Michael W. Lucas's "Ed Mastery" which has been
written
with a sense of humor not present in many software books.
Best regards,
Cameron
On Wednesday, July 16th, 2025 at 1:09 PM, arnold(a)skeeve.com <arnold(a)skeeve.com>
wrote:
IMHO, the best tutorials on ed are the chapters in "Software Tools"
and "Software Tools in Pascal" where Kernighan and Plauger write
a basic version of it. I recommend both books highly, despite
their age.
"Software Tools" literally changed my life. :-)
Arnold
6:15 p.m.
On Wed, Jul 16, 2025 at 1:45 PM Cameron Míċeál Tyre via TUHS <tuhs(a)tuhs.org>
wrote:
Hello Arnold,
Thank you, sir. I have "Software Tools In Pascal" and am hopeful that I
will
soon get asked if I have anything I want for my upcoming birthday.
"Software
Tools" will be my answer.
Note I have both editions in print, but for those that want to just read
them, PDF's of both are available in the wild:
- https://www.crystallabs.io/unix-books-papers-videos/Software-Tools.pdf
-
https://seriouscomputerist.atariverse.com/media/pdf/book/Software%20Tools%2…
Your commment about the age of these books is
something I concur with. I find them easier to read
and understand than
many
modern publications.
Indeed
6:24 p.m.
Hello Clem,
Thank you for those URLs. PDF versions are a great back-up if the printed
version goes missing or you need to refer to a book but don't have it with you.
Best regards,
Cameron
On Wednesday, July 16th, 2025 at 7:16 PM, Clem Cole <clemc(a)ccc.com> wrote, in part:
Note I have both editions in print, but for those that want to just read them, PDF's
of both are available in the wild:
- https://www.crystallabs.io/unix-books-papers-videos/Software-Tools.pdf
-
https://seriouscomputerist.atariverse.com/media/pdf/book/Software%20Tools%2…
17 Jul
17 Jul
10:01 a.m.
Technically speaking, the PDFs are bootleg, illegal copies. Bear
that in mind if you download them.
Arnold
Clem Cole <clemc(a)ccc.com> wrote:
On Wed, Jul 16, 2025 at 1:45 PM Cameron Míċeál Tyre
via TUHS <tuhs(a)tuhs.org>
wrote:
Hello Arnold,
Thank you, sir. I have "Software Tools In Pascal" and am hopeful that I
will
soon get asked if I have anything I want for my upcoming birthday.
"Software
Tools" will be my answer.
Note I have both editions in print, but for those that want to just read
them, PDF's of both are available in the wild:
- https://www.crystallabs.io/unix-books-papers-videos/Software-Tools.pdf
-
https://seriouscomputerist.atariverse.com/media/pdf/book/Software%20Tools%2…
Your commment about the age of these books is
something I concur with. I find them easier to
read and understand than
many
modern publications.
Indeed
2:03 p.m.
On Thu, Jul 17, 2025 at 6:01 AM <arnold(a)skeeve.com> wrote:
Technically speaking, the PDFs are bootleg,
Most anything you find on the internet through a search engine may often
be of hazy provenance.
That said, I am under the impression from a couple of the authors that both
books were released as PDFs, along with several other books in the PH
library from that series. I was given a number of them as PDFs by their
editors at PH, although I have never shared the ones I received, as I was
never told that I could. That said, I did an Internet search for these
URLs, and Arnold offers wise counsel.
9:58 a.m.
You're welcome. I was unaware of the Lucas book. There seem to be
two editions on Amazon.
Cameron Míċeál Tyre via TUHS <tuhs(a)tuhs.org> wrote:
Hello Arnold,
Thank you, sir. I have "Software Tools In Pascal" and am hopeful that I will
soon get asked if I have anything I want for my upcoming birthday. "Software
Tools" will be my answer. Your commment about the age of these books is
something I concur with. I find them easier to read and understand than many
modern publications. The one modern publication that I have found to be both
fun and easy to read is Michael W. Lucas's "Ed Mastery" which has been
written
with a sense of humor not present in many software books.
Best regards,
Cameron
On Wednesday, July 16th, 2025 at 1:09 PM, arnold(a)skeeve.com <arnold(a)skeeve.com>
wrote:
>
>
> IMHO, the best tutorials on ed are the chapters in "Software Tools"
> and "Software Tools in Pascal" where Kernighan and Plauger write
> a basic version of it. I recommend both books highly, despite
> their age.
>
> "Software Tools" literally changed my life. :-)
>
> Arnold
5:06 p.m.
I heart ed and it's cousin, vi. After poring through the v6 manual and
tutorial, I started loving ed. I ditched vim a while back and embraced
nvi (berkeley's modern basic vi/ex). Very simple, very basic, extremely
powerful, none of the bloat - basically heirloom with a few refinements.
Will
On 7/16/25 06:13, Cameron Míċeál Tyre via TUHS wrote:
Ah, rabbit holes. Dangerous things. I went down the ed
rabbit hole around a month ago and no sign of me finding my way back out any time soon.
I got obsessed with getting ed running on every device I have including my phones and
then the big rabbit hole off that first one was learning how to use it properly and to the
fullest of its abilities. That'll take a while.
My library of ed related publications is getting so big its likely what's blocking
the exit to the rabbit hole. On the plus side it has sharpened my typing skills, improved
my patience and I I've learned to work out for myself what I've done to cause ed
to say ?, instead of just typing h+Enter.
As rabbit holes go, it's been stimulating so far and I could be stuck in worse
places.
Have a safe one!
Cameron
-------- Original Message --------
On 16/07/2025 01:01, Luther Johnson <luther.johnson(a)makerlisp.com> wrote:
> I just noticed that algorithm and logarithm just have a couple of
> letters transposed from each other. So that's the kind of rabbit hole I
> get lost in most days.
>
8:03 p.m.
:sp[lit]
is enough to keep me in vim. That's a killer feature.
On Thu, Jul 17, 2025 at 12:06:03PM -0500, Will Senn wrote:
I heart ed and it's cousin, vi. After poring
through the v6 manual and
tutorial, I started loving ed. I ditched vim a while back and embraced nvi
(berkeley's modern basic vi/ex). Very simple, very basic, extremely
powerful, none of the bloat - basically heirloom with a few refinements.
Will
On 7/16/25 06:13, Cameron M????e??l Tyre via TUHS wrote:
>Ah, rabbit holes. Dangerous things. I went down the ed rabbit hole around a month ago
and no sign of me finding my way back out any time soon.
>
>I got obsessed with getting ed running on every device I have including my phones and
then the big rabbit hole off that first one was learning how to use it properly and to the
fullest of its abilities. That'll take a while.
>
>My library of ed related publications is getting so big its likely what's
blocking the exit to the rabbit hole. On the plus side it has sharpened my typing skills,
improved my patience and I I've learned to work out for myself what I've done to
cause ed to say ?, instead of just typing h+Enter.
>
>As rabbit holes go, it's been stimulating so far and I could be stuck in worse
places.
>
>Have a safe one!
>
>Cameron
>
>
>-------- Original Message --------
>On 16/07/2025 01:01, Luther Johnson <luther.johnson(a)makerlisp.com> wrote:
>
>> I just noticed that algorithm and logarithm just have a couple of
>> letters transposed from each other. So that's the kind of rabbit hole I
>> get lost in most days.
--
---
Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
18 Jul
18 Jul
12:33 a.m.
:E [filename] in nvi does the same (or similar; I rarely use vim).
Though IMHO the Rand Editor did a better job of multiple windows.
On Jul 17, 2025, at 1:03 PM, Larry McVoy
<lm(a)mcvoy.com> wrote:
:sp[lit]
is enough to keep me in vim. That's a killer feature.
On Thu, Jul 17, 2025 at 12:06:03PM -0500, Will Senn wrote:
I heart ed and it's cousin, vi. After poring
through the v6 manual and
tutorial, I started loving ed. I ditched vim a while back and embraced nvi
(berkeley's modern basic vi/ex). Very simple, very basic, extremely
powerful, none of the bloat - basically heirloom with a few refinements.
Will
On 7/16/25 06:13, Cameron M????e??l Tyre via TUHS wrote:
> Ah, rabbit holes. Dangerous things. I went down the ed rabbit hole around a month ago
and no sign of me finding my way back out any time soon.
>
> I got obsessed with getting ed running on every device I have including my phones and
then the big rabbit hole off that first one was learning how to use it properly and to the
fullest of its abilities. That'll take a while.
>
> My library of ed related publications is getting so big its likely what's
blocking the exit to the rabbit hole. On the plus side it has sharpened my typing skills,
improved my patience and I I've learned to work out for myself what I've done to
cause ed to say ?, instead of just typing h+Enter.
>
> As rabbit holes go, it's been stimulating so far and I could be stuck in worse
places.
>
> Have a safe one!
>
> Cameron
>
>
> -------- Original Message --------
> On 16/07/2025 01:01, Luther Johnson <luther.johnson(a)makerlisp.com> wrote:
>
>> I just noticed that algorithm and logarithm just have a couple of
>> letters transposed from each other. So that's the kind of rabbit hole I
>> get lost in most days.
--
---
Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
1:09 a.m.
Not really the same. :sp splits your window in half and puts you in
two different windows on the same file. Each window, in vim, is full
on vi, you can do :e fillename and now that window is on that file.
But that is far less useful than having two windows into the same
file where the mods to each window go to the same file. Think
looking at code that has the structs at the top of the file and you
need to wack a struck and wack the code that uses that struct.
Quite pleasant.
I'm not sure but maybe xvi is where I saw this first and I only saw
because I wacked xvi to use \0 and \n as end of line because that way
I could change it to mmap the input file and it didn't have to parse
it into internal malloced lines. Which was a huge win on 4MB Suns,
I could xvi a "huge" (for then) log file. I was a performance guy,
I've xvi-ed a lot of big log files.
But I think xvi could split. And once I could do that I never looked
back, all the emacs people were like "can you have multiple windows"
and I was "yup" and it is still simple, still vi.
Says the person who forced himself to live in emacs for a year and
still hated it. Not trying to start an editor war, more saying, my
brain works well with vi, doesn't work well with emacs, emacs is
fine for people who's brain works that way.
Same with nvi vs vim. My brain works pretty well with vim, I don't
use 90 to 99% of what it does past basic vi, but the parts I do use I
really like. I do delete the system .vimrc or whatever it is that does
color highlighting, I hate that crap.
I like the split windows, I like that I can tell my kid to do
vim file
:sp
:help
and he figures it out from there.
I also like that I've been carrying around this .exrc for close to 40 years
and it just works:
map # :.,$
map @ :1,.
map , !}fmt
map g
map!
set redraw ai aw terse
set sections=uhshSHNH
set paragraphs=PSPETSTEFSFEKSKECSCERSREDSDEIPNPLPPPTLABAIAELIB1B2HH
set ts=8 sw=4
set shell=/bin/sh
set showmode
set textwidth=1000
set vb
I think the # and @ came from the BDS C editor, "," came from watching
Udi Manber do that and I went WTF? ^A is because I set sw to 4, a lot of
the rest is troff.
40 years later, it still works, credit to vim for maintaining backwards
compat while moving the vi editor forward. No offense to Keith but nvi
didn't really move vi forward much, that I know of, it made it sort of
bug for bug compat with Joys vi. Which I never understood, was Joys
vi not open sourced? I always wondered why Keith did all that work and
then left it in the 1980s.
On Thu, Jul 17, 2025 at 05:33:35PM -0700, Bakul Shah wrote:
:E [filename] in nvi does the same (or similar; I
rarely use vim).
Though IMHO the Rand Editor did a better job of multiple windows.
> On Jul 17, 2025, at 1:03???PM, Larry McVoy <lm(a)mcvoy.com> wrote:
>
> :sp[lit]
>
> is enough to keep me in vim. That's a killer feature.
>
> On Thu, Jul 17, 2025 at 12:06:03PM -0500, Will Senn wrote:
>> I heart ed and it's cousin, vi. After poring through the v6 manual and
>> tutorial, I started loving ed. I ditched vim a while back and embraced nvi
>> (berkeley's modern basic vi/ex). Very simple, very basic, extremely
>> powerful, none of the bloat - basically heirloom with a few refinements.
>>
>>
>> Will
>>
>> On 7/16/25 06:13, Cameron M????e??l Tyre via TUHS wrote:
>>> Ah, rabbit holes. Dangerous things. I went down the ed rabbit hole around a
month ago and no sign of me finding my way back out any time soon.
>>>
>>> I got obsessed with getting ed running on every device I have including my
phones and then the big rabbit hole off that first one was learning how to use it properly
and to the fullest of its abilities. That'll take a while.
>>>
>>> My library of ed related publications is getting so big its likely
what's blocking the exit to the rabbit hole. On the plus side it has sharpened my
typing skills, improved my patience and I I've learned to work out for myself what
I've done to cause ed to say ?, instead of just typing h+Enter.
>>>
>>> As rabbit holes go, it's been stimulating so far and I could be stuck
in worse places.
>>>
>>> Have a safe one!
>>>
>>> Cameron
>>>
>>>
>>> -------- Original Message --------
>>> On 16/07/2025 01:01, Luther Johnson <luther.johnson(a)makerlisp.com>
wrote:
>>>
>>>> I just noticed that algorithm and logarithm just have a couple of
>>>> letters transposed from each other. So that's the kind of rabbit
hole I
>>>> get lost in most days.
>
> --
> ---
> Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
--
---
Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
1:19 a.m.
If you just do ":E" it will put both windows on the current file,
exactly the same as vim. But both do it wrong (IMHO) as the second
window starts at the same place (e.g top of the file). In the Rand
Editor if the split is at line N, the bottom window shows lines N+1.
Exact same behavior for vertical split (the left and right side
windows show the same portions as before).
On Jul 17, 2025, at 6:09 PM, Larry McVoy
<lm(a)mcvoy.com> wrote:
Not really the same. :sp splits your window in half and puts you in
two different windows on the same file. Each window, in vim, is full
on vi, you can do :e fillename and now that window is on that file.
2:52 a.m.
If you just do ":E" it will put both windows
on the current file,
exactly the same as vim. But both do it wrong (IMHO) as the second
window starts at the same place (e.g top of the file). In the Rand
Editor if the split is at line N, the bottom window shows lines N+1.
Exact same behavior for vertical split (the left and right side
windows show the same portions as before).
> On Jul 17, 2025, at 6:09 PM, Larry McVoy lm(a)mcvoy.com wrote:
>
> Not really the same. :sp splits your window in half and puts you in
> two different windows on the same file. Each window, in vim, is full
> on vi, you can do :e fillename and now that window is on that file.
Not historic but as of present I shunt windowing off to GNU screen and just have separate
nvi sessions in each. This may speak to ignorance on my part regarding advantages of
opening multiple files in the same session in any given vi. I keep vim around for when I
need the value adds, but nvi is linked as ex/vi/view. I suppose it is nice to keep your
window configuration tightly coupled, but I also frequently have vi in one pane and am
using the others for od output and build/test cycle for disassembly projects.
- Matt G.
3:29 a.m.
On Jul 17, 2025, at 7:52 PM, segaloco via TUHS <tuhs(a)tuhs.org> wrote:
Going via screen(1) can be more painful. If you want to copy some lines
from one file to another, you have to either create a temp file or
use the window systems's cut/paste buffer/clipboard. The latter can
actually works worse (if you have autoindent turned on for example).
Also the modal nature of vi/vim can wreak havoc (copied text can be
mistakenly interpreted as commands).
In vi you can yank lines in file1, paste in file2. And can share
options, tags etc. In the rand editor you can scroll two windows in
unison (handy if one shows column headings and the other some rows).
See acme for an example of a well designed multi window editor.
If you just do ":E" it will put both
windows on the current file,
exactly the same as vim. But both do it wrong (IMHO) as the second
window starts at the same place (e.g top of the file). In the Rand
Editor if the split is at line N, the bottom window shows lines N+1.
Exact same behavior for vertical split (the left and right side
windows show the same portions as before).
> On Jul 17, 2025, at 6:09 PM, Larry McVoy lm(a)mcvoy.com wrote:
>
> Not really the same. :sp splits your window in half and puts you in
> two different windows on the same file. Each window, in vim, is full
> on vi, you can do :e fillename and now that window is on that file.
Not historic but as of present I shunt windowing off to GNU screen and just have separate
nvi sessions in each. This may speak to ignorance on my part regarding advantages of
opening multiple files in the same session in any given vi. I keep vim around for when I
need the value adds, but nvi is linked as ex/vi/view. I suppose it is nice to keep your
window configuration tightly coupled, but I also frequently have vi in one pane and am
using the others for od output and build/test cycle for disassembly projects.
10:09 a.m.
On Thu, Jul 17, 2025 at 08:29:21PM -0700, Bakul Shah via TUHS wrote:
On Jul 17, 2025, at 7:52???PM, segaloco via TUHS
<tuhs(a)tuhs.org> wrote:
Going via screen(1) can be more painful. If you want to copy some lines
from one file to another, you have to either create a temp file or
use the window systems's cut/paste buffer/clipboard. The latter can
actually works worse (if you have autoindent turned on for example).
Also the modal nature of vi/vim can wreak havoc (copied text can be
mistakenly interpreted as commands).
In vi you can yank lines in file1, paste in file2. And can share
options, tags etc. In the rand editor you can scroll two windows in
unison (handy if one shows column headings and the other some rows).
See acme for an example of a well designed multi window editor.
I was going to respond to the screen stuff but Bakul beat me to it.
In vim, you just have a split view of the same file. Changes in
either window will show up in the other window. For example
vim foo.c # foo.c exists and has a 100 lines
:sp
now you have both windows looking at the same file
start changing something and it is done in both windows.
Screen is nowhere near that and using it to claim that nvi is fine
is missing the point by a country mile.
And I don't understand the dislike of vim. Sure, it's got a pile
of stuff that old time Unix people would dislike "cat came back
from BSD wagging it's tail" (or something that Rob said) but you
don't have to use any of that. For me, vim is a finger compat
vi clone that has some really really useful extensions, I use
:split
all the time. Saying you prefer nvi in the face of that is
something that makes no sense to me. I've used nvi, I get that
it is compat with Joys vi, but so what? vim is more useful and
it is also compat.
Time marches on, perhaps march with it?
--lm
If you just do ":E" it will put both
windows on the current file,
exactly the same as vim. But both do it wrong (IMHO) as the second
window starts at the same place (e.g top of the file). In the Rand
Editor if the split is at line N, the bottom window shows lines N+1.
Exact same behavior for vertical split (the left and right side
windows show the same portions as before).
> On Jul 17, 2025, at 6:09???PM, Larry McVoy lm(a)mcvoy.com wrote:
>
> Not really the same. :sp splits your window in half and puts you in
> two different windows on the same file. Each window, in vim, is full
> on vi, you can do :e fillename and now that window is on that file.
Not historic but as of present I shunt windowing off to GNU screen and just have separate
nvi sessions in each. This may speak to ignorance on my part regarding advantages of
opening multiple files in the same session in any given vi. I keep vim around for when I
need the value adds, but nvi is linked as ex/vi/view. I suppose it is nice to keep your
window configuration tightly coupled, but I also frequently have vi in one pane and am
using the others for od output and build/test cycle for disassembly projects.
12:24 p.m.
nvi does everything i need it to, it's help fits on a couple of screens,
and it's easy to remember it all. maybe if I hit a wall with it, I'll
reinstall vim, but for the screen stuff, don't need it. I don't live in
my editor, or even the command line, I just use it when it's convenient
- which admittedly is a lot of the time. But, it's the terminal that's
most useful, not vi. So, if I want more screen, I just open a terminal
window. My monitor has room for a dozen or so :) not including guake,
workspaces, etc... in the modern era, of course!
Will
On 7/18/25 05:09, Larry McVoy wrote:
On Thu, Jul 17, 2025 at 08:29:21PM -0700, Bakul Shah
via TUHS wrote:
On Jul 17, 2025, at 7:52???PM, segaloco via TUHS
<tuhs(a)tuhs.org> wrote:
Going via
screen(1) can be more painful. If you want to copy some lines
from one file to another, you have to either create a temp file or
use the window systems's cut/paste buffer/clipboard. The latter can
actually works worse (if you have autoindent turned on for example).
Also the modal nature of vi/vim can wreak havoc (copied text can be
mistakenly interpreted as commands).
In vi you can yank lines in file1, paste in file2. And can share
options, tags etc. In the rand editor you can scroll two windows in
unison (handy if one shows column headings and the other some rows).
See acme for an example of a well designed multi window editor.
I was going to
respond to the screen stuff but Bakul beat me to it.
In vim, you just have a split view of the same file. Changes in
either window will show up in the other window. For example
vim foo.c # foo.c exists and has a 100 lines
:sp
now you have both windows looking at the same file
start changing something and it is done in both windows.
Screen is nowhere near that and using it to claim that nvi is fine
is missing the point by a country mile.
And I don't understand the dislike of vim. Sure, it's got a pile
of stuff that old time Unix people would dislike "cat came back
from BSD wagging it's tail" (or something that Rob said) but you
don't have to use any of that. For me, vim is a finger compat
vi clone that has some really really useful extensions, I use
:split
all the time. Saying you prefer nvi in the face of that is
something that makes no sense to me. I've used nvi, I get that
it is compat with Joys vi, but so what? vim is more useful and
it is also compat.
Time marches on, perhaps march with it?
--lm If you
just do ":E" it will put both windows on the current file,
exactly the same as vim. But both do it wrong (IMHO) as the second
window starts at the same place (e.g top of the file). In the Rand
Editor if the split is at line N, the bottom window shows lines N+1.
Exact same behavior for vertical split (the left and right side
windows show the same portions as before).
> On Jul 17, 2025, at 6:09???PM, Larry McVoy lm(a)mcvoy.com wrote:
>
> Not really the same. :sp splits your window in half and puts you in
> two different windows on the same file. Each window, in vim, is full
> on vi, you can do :e fillename and now that window is on that file.
Not
historic but as of present I shunt windowing off to GNU screen and just have separate nvi
sessions in each. This may speak to ignorance on my part regarding advantages of opening
multiple files in the same session in any given vi. I keep vim around for when I need the
value adds, but nvi is linked as ex/vi/view. I suppose it is nice to keep your window
configuration tightly coupled, but I also frequently have vi in one pane and am using the
others for od output and build/test cycle for disassembly projects.
12:52 p.m.
That's fine, if it works for you it works for you. For me, vim is
compat enough (and it has a way to make it more compat if you care
I believe) and has some functionality that makes me shake my head
at the nvi people.
To me, nvi is sort of like v7. Yeah, it's like the original Unix
but would you want to live there just because it is "pure"? No
networking, no top, it's just a basic Unix. Cool because of how
small it is but pretty painful to live there.
On Fri, Jul 18, 2025 at 07:24:46AM -0500, Will Senn wrote:
nvi does everything i need it to, it's help fits
on a couple of screens, and
it's easy to remember it all. maybe if I hit a wall with it, I'll reinstall
vim, but for the screen stuff, don't need it. I don't live in my editor, or
even the command line, I just use it when it's convenient - which admittedly
is a lot of the time. But, it's the terminal that's most useful, not vi. So,
if I want more screen, I just open a terminal window. My monitor has room
for a dozen or so :) not including guake, workspaces, etc... in the modern
era, of course!
Will
On 7/18/25 05:09, Larry McVoy wrote:
>On Thu, Jul 17, 2025 at 08:29:21PM -0700, Bakul Shah via TUHS wrote:
>>On Jul 17, 2025, at 7:52???PM, segaloco via TUHS <tuhs(a)tuhs.org> wrote:
>>>>If you just do ":E" it will put both windows on the current
file,
>>>>exactly the same as vim. But both do it wrong (IMHO) as the second
>>>>window starts at the same place (e.g top of the file). In the Rand
>>>>Editor if the split is at line N, the bottom window shows lines N+1.
>>>>Exact same behavior for vertical split (the left and right side
>>>>windows show the same portions as before).
>>>>
>>>>>On Jul 17, 2025, at 6:09???PM, Larry McVoy lm(a)mcvoy.com wrote:
>>>>>
>>>>>Not really the same. :sp splits your window in half and puts you in
>>>>>two different windows on the same file. Each window, in vim, is full
>>>>>on vi, you can do :e fillename and now that window is on that file.
>>>Not historic but as of present I shunt windowing off to GNU screen and just
have separate nvi sessions in each. This may speak to ignorance on my part regarding
advantages of opening multiple files in the same session in any given vi. I keep vim
around for when I need the value adds, but nvi is linked as ex/vi/view. I suppose it is
nice to keep your window configuration tightly coupled, but I also frequently have vi in
one pane and am using the others for od output and build/test cycle for disassembly
projects.
>>Going via screen(1) can be more painful. If you want to copy some lines
>>from one file to another, you have to either create a temp file or
>>use the window systems's cut/paste buffer/clipboard. The latter can
>>actually works worse (if you have autoindent turned on for example).
>>Also the modal nature of vi/vim can wreak havoc (copied text can be
>>mistakenly interpreted as commands).
>>
>>In vi you can yank lines in file1, paste in file2. And can share
>>options, tags etc. In the rand editor you can scroll two windows in
>>unison (handy if one shows column headings and the other some rows).
>>See acme for an example of a well designed multi window editor.
>I was going to respond to the screen stuff but Bakul beat me to it.
>In vim, you just have a split view of the same file. Changes in
>either window will show up in the other window. For example
>
>vim foo.c # foo.c exists and has a 100 lines
>:sp
>
>now you have both windows looking at the same file
>
>start changing something and it is done in both windows.
>
>Screen is nowhere near that and using it to claim that nvi is fine
>is missing the point by a country mile.
>
>And I don't understand the dislike of vim. Sure, it's got a pile
>of stuff that old time Unix people would dislike "cat came back
>from BSD wagging it's tail" (or something that Rob said) but you
>don't have to use any of that. For me, vim is a finger compat
>vi clone that has some really really useful extensions, I use
>:split
>all the time. Saying you prefer nvi in the face of that is
>something that makes no sense to me. I've used nvi, I get that
>it is compat with Joys vi, but so what? vim is more useful and
>it is also compat.
>
>Time marches on, perhaps march with it?
>
>--lm
--
---
Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
6:28 p.m.
Ha Larry. I'm not hidebound, but I do like to understand the software I
use and I'm more of the if it ain't broke persuasion. The vim manual is
maybe 5000 pages now (https://nathangrigg.com/vimhelp/vimhelp.pdf) only
about 100x the nvi manual.... but yeah, different strokes for different
folks.
Seems like we're in the weeds though, almost COFF worthy.
I do wonder about vi though and when it became prevalent. In v6, it's
supposedly possible to get it working, but I've never seen it in virtual
environs (oh how I've tried). In v7, it's more possible, but again, I've
not seen it really working in SIMH (tried that too). BSD 2.11 gets the
nod, but was it delivered as part of any system prior to 2.11 or was
2.11 really the first post v7 unix with vi with wider adoption?
Later,
Will
On 7/18/25 07:52, Larry McVoy wrote:
That's fine, if it works for you it works for
you. For me, vim is
compat enough (and it has a way to make it more compat if you care
I believe) and has some functionality that makes me shake my head
at the nvi people.
To me, nvi is sort of like v7. Yeah, it's like the original Unix
but would you want to live there just because it is "pure"? No
networking, no top, it's just a basic Unix. Cool because of how
small it is but pretty painful to live there.
On Fri, Jul 18, 2025 at 07:24:46AM -0500, Will Senn wrote:
> nvi does everything i need it to, it's help fits on a couple of screens, and
> it's easy to remember it all. maybe if I hit a wall with it, I'll reinstall
> vim, but for the screen stuff, don't need it. I don't live in my editor, or
> even the command line, I just use it when it's convenient - which admittedly
> is a lot of the time. But, it's the terminal that's most useful, not vi.
So,
> if I want more screen, I just open a terminal window. My monitor has room
> for a dozen or so :) not including guake, workspaces, etc... in the modern
> era, of course!
>
> Will
>
> On 7/18/25 05:09, Larry McVoy wrote:
>> On Thu, Jul 17, 2025 at 08:29:21PM -0700, Bakul Shah via TUHS wrote:
>>> On Jul 17, 2025, at 7:52???PM, segaloco via TUHS <tuhs(a)tuhs.org> wrote:
>>>>> If you just do ":E" it will put both windows on the current
file,
>>>>> exactly the same as vim. But both do it wrong (IMHO) as the second
>>>>> window starts at the same place (e.g top of the file). In the Rand
>>>>> Editor if the split is at line N, the bottom window shows lines N+1.
>>>>> Exact same behavior for vertical split (the left and right side
>>>>> windows show the same portions as before).
>>>>>
>>>>>> On Jul 17, 2025, at 6:09???PM, Larry McVoy lm(a)mcvoy.com wrote:
>>>>>>
>>>>>> Not really the same. :sp splits your window in half and puts you
in
>>>>>> two different windows on the same file. Each window, in vim, is
full
>>>>>> on vi, you can do :e fillename and now that window is on that
file.
>>>> Not historic but as of present I shunt windowing off to GNU screen and
just have separate nvi sessions in each. This may speak to ignorance on my part regarding
advantages of opening multiple files in the same session in any given vi. I keep vim
around for when I need the value adds, but nvi is linked as ex/vi/view. I suppose it is
nice to keep your window configuration tightly coupled, but I also frequently have vi in
one pane and am using the others for od output and build/test cycle for disassembly
projects.
>>> Going via screen(1) can be more painful. If you want to copy some lines
>> >from one file to another, you have to either create a temp file or
>>> use the window systems's cut/paste buffer/clipboard. The latter can
>>> actually works worse (if you have autoindent turned on for example).
>>> Also the modal nature of vi/vim can wreak havoc (copied text can be
>>> mistakenly interpreted as commands).
>>>
>>> In vi you can yank lines in file1, paste in file2. And can share
>>> options, tags etc. In the rand editor you can scroll two windows in
>>> unison (handy if one shows column headings and the other some rows).
>>> See acme for an example of a well designed multi window editor.
>> I was going to respond to the screen stuff but Bakul beat me to it.
>> In vim, you just have a split view of the same file. Changes in
>> either window will show up in the other window. For example
>>
>> vim foo.c # foo.c exists and has a 100 lines
>> :sp
>>
>> now you have both windows looking at the same file
>>
>> start changing something and it is done in both windows.
>>
>> Screen is nowhere near that and using it to claim that nvi is fine
>> is missing the point by a country mile.
>>
>> And I don't understand the dislike of vim. Sure, it's got a pile
>> of stuff that old time Unix people would dislike "cat came back
> >from BSD wagging it's tail" (or something that Rob said) but you
>> don't have to use any of that. For me, vim is a finger compat
>> vi clone that has some really really useful extensions, I use
>> :split
>> all the time. Saying you prefer nvi in the face of that is
>> something that makes no sense to me. I've used nvi, I get that
>> it is compat with Joys vi, but so what? vim is more useful and
>> it is also compat.
>>
>> Time marches on, perhaps march with it?
>>
>> --lm
7:43 p.m.
Last post on this topic because life is too short.
Will, you can do whatever you want. If you worked for me, this would be a
much shorter conversation and you'd be using vim. Modern tools are more
complicated because they do more stuff. Taking your position to the extreme
would have you using a pipeline piped to ed, would it not? vi is a BSDism,
so it isn't "pure", nvi is a rewrite of Joys vi (why? Anyone?)
I get the desire to have simple tools, I'm that way too, but switching
from vi, nvi to vim was seamless. I've never looked at their documentation
other than :help to find how to manipulate their windows. Everything else
just worked.
Have fun with nvi.
On Fri, Jul 18, 2025 at 01:28:54PM -0500, Will Senn wrote:
Ha Larry. I'm not hidebound, but I do like to
understand the software I use
and I'm more of the if it ain't broke persuasion. The vim manual is maybe
5000 pages now (https://nathangrigg.com/vimhelp/vimhelp.pdf) only about
100x the nvi manual.... but yeah, different strokes for different folks.
Seems like we're in the weeds though, almost COFF worthy.
I do wonder about vi though and when it became prevalent. In v6, it's
supposedly possible to get it working, but I've never seen it in virtual
environs (oh how I've tried). In v7, it's more possible, but again, I've
not
seen it really working in SIMH (tried that too). BSD 2.11 gets the nod, but
was it delivered as part of any system prior to 2.11 or was 2.11 really the
first post v7 unix with vi with wider adoption?
Later,
Will
On 7/18/25 07:52, Larry McVoy wrote:
>That's fine, if it works for you it works for you. For me, vim is
>compat enough (and it has a way to make it more compat if you care
>I believe) and has some functionality that makes me shake my head
>at the nvi people.
>
>To me, nvi is sort of like v7. Yeah, it's like the original Unix
>but would you want to live there just because it is "pure"? No
>networking, no top, it's just a basic Unix. Cool because of how
>small it is but pretty painful to live there.
>
>On Fri, Jul 18, 2025 at 07:24:46AM -0500, Will Senn wrote:
>>nvi does everything i need it to, it's help fits on a couple of screens, and
>>it's easy to remember it all. maybe if I hit a wall with it, I'll
reinstall
>>vim, but for the screen stuff, don't need it. I don't live in my
editor, or
>>even the command line, I just use it when it's convenient - which admittedly
>>is a lot of the time. But, it's the terminal that's most useful, not
vi. So,
>>if I want more screen, I just open a terminal window. My monitor has room
>>for a dozen or so :) not including guake, workspaces, etc... in the modern
>>era, of course!
>>
>>Will
>>
>>On 7/18/25 05:09, Larry McVoy wrote:
>>>On Thu, Jul 17, 2025 at 08:29:21PM -0700, Bakul Shah via TUHS wrote:
>>>>On Jul 17, 2025, at 7:52???PM, segaloco via TUHS <tuhs(a)tuhs.org>
wrote:
>>>>>>If you just do ":E" it will put both windows on the
current file,
>>>>>>exactly the same as vim. But both do it wrong (IMHO) as the
second
>>>>>>window starts at the same place (e.g top of the file). In the
Rand
>>>>>>Editor if the split is at line N, the bottom window shows lines
N+1.
>>>>>>Exact same behavior for vertical split (the left and right side
>>>>>>windows show the same portions as before).
>>>>>>
>>>>>>>On Jul 17, 2025, at 6:09???PM, Larry McVoy lm(a)mcvoy.com
wrote:
>>>>>>>
>>>>>>>Not really the same. :sp splits your window in half and puts
you in
>>>>>>>two different windows on the same file. Each window, in vim,
is full
>>>>>>>on vi, you can do :e fillename and now that window is on that
file.
>>>>>Not historic but as of present I shunt windowing off to GNU screen
and just have separate nvi sessions in each. This may speak to ignorance on my part
regarding advantages of opening multiple files in the same session in any given vi. I
keep vim around for when I need the value adds, but nvi is linked as ex/vi/view. I
suppose it is nice to keep your window configuration tightly coupled, but I also
frequently have vi in one pane and am using the others for od output and build/test cycle
for disassembly projects.
>>>>Going via screen(1) can be more painful. If you want to copy some lines
>>>>from one file to another, you have to either create a temp file or
>>>>use the window systems's cut/paste buffer/clipboard. The latter can
>>>>actually works worse (if you have autoindent turned on for example).
>>>>Also the modal nature of vi/vim can wreak havoc (copied text can be
>>>>mistakenly interpreted as commands).
>>>>
>>>>In vi you can yank lines in file1, paste in file2. And can share
>>>>options, tags etc. In the rand editor you can scroll two windows in
>>>>unison (handy if one shows column headings and the other some rows).
>>>>See acme for an example of a well designed multi window editor.
>>>I was going to respond to the screen stuff but Bakul beat me to it.
>>>In vim, you just have a split view of the same file. Changes in
>>>either window will show up in the other window. For example
>>>
>>>vim foo.c # foo.c exists and has a 100 lines
>>>:sp
>>>
>>>now you have both windows looking at the same file
>>>
>>>start changing something and it is done in both windows.
>>>
>>>Screen is nowhere near that and using it to claim that nvi is fine
>>>is missing the point by a country mile.
>>>
>>>And I don't understand the dislike of vim. Sure, it's got a pile
>>>of stuff that old time Unix people would dislike "cat came back
>>>from BSD wagging it's tail" (or something that Rob said) but you
>>>don't have to use any of that. For me, vim is a finger compat
>>>vi clone that has some really really useful extensions, I use
>>>:split
>>>all the time. Saying you prefer nvi in the face of that is
>>>something that makes no sense to me. I've used nvi, I get that
>>>it is compat with Joys vi, but so what? vim is more useful and
>>>it is also compat.
>>>
>>>Time marches on, perhaps march with it?
>>>
>>>--lm
--
---
Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
7:59 p.m.
On Fri, Jul 18, 2025 at 3:43 PM Larry McVoy <lm(a)mcvoy.com> wrote:
nvi is a rewrite of Joys vi (why? Anyone?)
When Keith ensured that everything in what would lead to the NET2 release
was free of any AT&T IP, since the vi command was added to ex, which had
originated as ed on the Sixth Edition, it had to be replaced.
FWIW: Your observation about modern tools doing more stuff cuts both ways.
Sometimes that's nice. As much as I miss the simplicity of the Seventh
Edition, I'd not want to trade my Mac for it. But as Rob once observed, cat
-v is not necessary and many of the "stuff" you mention has little value.
I suspect that every feature in vim is found to be helpful>>somebody<< but
I >>suspect<< that few people need, much less use all the features, and as
importantly, as with cat -v, there are often simpler solutions for many of
these features. Just because it has them does not necessarily mean it
matters.
My take, the >>one<< feature Vim has for me is MacVIM, which is better
integrated into my Mac, but other than that, my .exrc file, like yours, is
40+ years old, and most of how I use it, nvi would work.
8:12 p.m.
On Fri, Jul 18, 2025 at 03:59:39PM -0400, Clem Cole wrote:
On Fri, Jul 18, 2025 at 3:43???PM Larry McVoy
<lm(a)mcvoy.com> wrote:
Sigh, my entire points were:
A) my 40 year old .exrc works perfectly with vim and has for more than 20 years.
B) the killer feature, not present in nvi, is :split
Beyond that, I don't care how much extra crap there is in vim, all I care
about is vi compat and :split
Why that is controversial is beyond me. Lets move on. Use whatever you like.
--
---
Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
nvi is a rewrite of Joys vi (why? Anyone?)
When Keith ensured that everything in what would lead to the NET2 release
was free of any AT&T IP, since the vi command was added to ex, which had
originated as ed on the Sixth Edition, it had to be replaced.
FWIW: Your observation about modern tools doing more stuff cuts both ways.
Sometimes that's nice. As much as I miss the simplicity of the Seventh
Edition, I'd not want to trade my Mac for it. But as Rob once observed, cat
-v is not necessary and many of the "stuff" you mention has little value.
I suspect that every feature in vim is found to be helpful>>somebody<< but
I >>suspect<< that few people need, much less use all the features, and as
importantly, as with cat -v, there are often simpler solutions for many of
these features. Just because it has them does not necessarily mean it
matters.
My take, the >>one<< feature Vim has for me is MacVIM, which is better
integrated into my Mac, but other than that, my .exrc file, like yours, is
40+ years old, and most of how I use it, nvi would work. 
8:53 p.m.
Just to make sure we are talking about the right editors in OpenVi
(https://github.com/johnsonjh/OpenVi, that I maintain) and nvi2
(https://github.com/lichray/nvi2) have many extra features, but the
split windows do derive from the original nvi which is currently
homed at https://repo.or.cz/nvi.git now.
It's just not `:split` but `:E` (capital E). ^W switches the active
window, and you can continue to split the screen as many times as
you like.
If you're married typing split, set an abbrev. like `:ab split E`.
The missing feature in the nvi series of editors here is the ability
to split windows vertically rather than horizontally (i.e. `:vsplit`).
... but I'll no longer beat the dead horse!
--
Jeffrey H. Johnson
trnsz(a)pobox.com
Sigh, my entire points were:
A) my 40 year old .exrc works perfectly with vim and has for more than 20 years.
B) the killer feature, not present in nvi, is :split
Beyond that, I don't care how much extra crap there is in vim, all I care
about is vi compat and :split
Why that is controversial is beyond me. Lets move on. Use whatever you like.
19 Jul
19 Jul
8:43 a.m.
On Jul 18, 2025, at 12:43 PM, Larry McVoy
<lm(a)mcvoy.com> wrote:
Modern tools are more
complicated because they do more stuff. Taking your position to the extreme
would have you using a pipeline piped to ed, would it not?
preface: none of this is to contradict your position. I was a little confused about the
implications of your apparently contradictory statements, that if someone worked for you
you’d force them to use vim, but also that people should be free to use what they like,
but I don’t feel like I’m owed an explanation for it, so that isn’t why I’m replying.
I never bothered to develop a complicated .exrc and I don’t do much of my programming in
vi-like editors, so for the most part I’m not super invested in the feature differences
between vi, nvi, vim, etc. I do prefer vi-alikes to other unix editors, but I can cope
with ed when I need to. I probably wouldn’t choose to use Emacs unless I had no other
choice, but I easily understand why some people do. The vast majority of my editor use is
for systems-type tasks, so I don’t imagine it’s difficult to understand why I got here.
When I do use vi for programming, it’s primarily to update existing code, but I could
reasonably live with vi alone, if that was all I had.
I am often surprised at my professional colleagues who insist they need vim in particular,
and complain loudly when a vi-like editor that isn’t vim is all that is available. Almost
without fail, these are the same guys I see get thrown when their terminal emulator isn’t
letting them use the arrow keys to position the cursor, who only ever move the cursor
around one row or column at a time, who only ever i or o, never I or O or A or c or C or $
or 10G or u or w or y or anything, who don’t know how to use any of the ex commands, read
text in from files or commands, or use any number of other features more advanced than
what you got in Windows notepad, and who insist, for some reason, that they need vim to
“copy and paste”. Their incuriousness really serves to give me a reflexive (and as this
thread reveals, admittedly sometimes also unfair) disdain toward someone who claims to
“need” vim.
That’s just an opinon, though, and as such, it’s worth a half pitcher of spit. I try not
to get too hung up about it. Everybody needs a hobby. If it’s pounding ‘k’ and ‘l’ a
hundred and seventy times in a row, then… boogie on down.
Anyway. So it also turns out there are other reasons to prefer classic vi. One of the
larger software projects I maintain (mostly using bbedit) is a network booted embedded
linux system which hosts a ruby-based configuration management system, for doing
standalone policy based configuration control of datacenter hardware resources (e.g. RAID
configuration, firmware versions, BIOS settings, defect detection and reporting, etc.)
It’s a relatively complex system solving a relatively complex problem, and the complex
problem is what I want to stay focused on. So that makes limiting the number of external
dependencies an important consideration for the project. Every external dependency becomes
something that has to be downloaded at runtime, something that takes space in the ramdisk,
and a set of binary artifacts that have to be tracked, integrated, and their lifecycle
managed.
It’s also important to be able to use the embedded linux system to investigate defects in
the configuration management system, when they crop up, and although we get nano “for
free” as a byproduct of having based the nucleus of the system around the Debian
installer, there are a long list of reasons why nano is too obnoxious to live with. It was
worth adding a vi-based editor to the system for such occasions. But the standard ‘vim’
has a relatively long list of external dependencies that we would be forced to carry along
with it, and subsequently, to maintain in perpetuity. Even ‘vim-tiny’ and ‘nvi’ had longer
lists of dependencies than I was happy with. I ended up adding ‘elvis-tiny’ to it, which
is pretty much entirely self-contained. Entirely adequate for purpose, perfect on
maintainability requirements.
This is part of the calculus when folks say they find the feature bloat distasteful. It
isn’t always about end-user experience (though sometimes… what the heck is going on with
Jira these days?!? don’t answer that.)
Which reminds me, tangentially: I often get tripped up by “helpful” vim features (I can’t
tell you how many times I have accidentally opened an unwanted Help panel), but I
categorize those as minor annoyances that I try not to get too hung up on. This time,
though, I was using 'vim' on a remote system in an xterm, and wanted to copy and
paste something into a different window. ‘vim’ took all the mouse events for itself and it
wasn’t obvious (in the moment) how to make it stop. I can’t think of a time I ever wanted
to use a mouse to directly control a vi session. That one made me rage a bit, although it
was simple enough to fix (TERM=vt220, try again). I got over it.
Obviously there is an entirely different set of tradeoffs if you’re installing an editor
on a programmer’s workstation. But I wanted to be very concrete about why I don’t favor
the idea that “vim is a 100% replacement for vi in every possible circumstance”. At least
by the Debian maintainer standards, nvi depends on Berkeley DB. vim depends on SELinux,
libacl, libsodium, gpm, and others. Why? (…he asked, rhetorically)
ok
bear.
2:17 p.m.
>>>> "rs" == r stricklin
<bear(a)typewritten.org> writes:
rs> I ended up adding ‘elvis-tiny’ to
rs> it, which is pretty much entirely self-contained. Entirely adequate
rs> for purpose, perfect on maintainability requirements.
busybox vi is also a good choice for tight systems. especially when
using bb for other applications, of course.
i often keep a `ln -s busybox /bin/vi` around when i want something
small and quick.
(and vimdiff for gentoo's etc-update.)
(but emacs for most editing. :)
-JimC
--
James Cloos <cloos(a)jhcloos.com>
OpenPGP: https://jhcloos.com/0x997A9F17ED7DAEA6.asc
6:07 p.m.
James Cloos wrote in
<m3o6tgs1rw.fsf(a)lugabout.jhcloos.org>:
|>>>>> "rs" == r stricklin <bear(a)typewritten.org> writes:
|
|rs> I ended up adding ‘elvis-tiny’ to
|rs> it, which is pretty much entirely self-contained. Entirely adequate
|rs> for purpose, perfect on maintainability requirements.
|
|busybox vi is also a good choice for tight systems. especially when
|using bb for other applications, of course.
it is (too, for me) super-tight.
|i often keep a `ln -s busybox /bin/vi` around when i want something
|small and quick.
|
|(and vimdiff for gentoo's etc-update.)
|
|(but emacs for most editing. :)
For years and years i want to go to Thomas Dickey's vile, but just
cannot get there.
"Problem with" nvi and nvi2 is they do not compile out of the box
of their repository, and nvi2 does not go at all here because it
does not include the Berkeley DBv1, and Linux does not have it,
nvi just includes the few kilobyte.
(Btw OpenBSD has the usr.bin/mg, an emacs-style thing, but pretty
small. I do not know wether someone somewhere has the small make
compatibility shim to make it a portable thing.)
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
|
|During summer's humble, here's David Leonard's grumble
|
|The black bear, The black bear,
|blithely holds his own holds himself at leisure
|beating it, up and down tossing over his ups and downs with pleasure
|
|Farewell, dear collar bear
6:21 p.m.
You should try OpenVi - which is easy to build and includes the OpenBSD’s db and regex
dependencies in the tree - https://github.com/johnsonjh/OpenVi
--
Jeffrey H. Johnson
trnsz(a)pobox.com
For years and years i want to go to Thomas
Dickey's vile, but just
cannot get there.
"Problem with" nvi and nvi2 is they do not compile out of the box
of their repository, and nvi2 does not go at all here because it
does not include the Berkeley DBv1, and Linux does not have it,
nvi just includes the few kilobyte.
(Btw OpenBSD has the usr.bin/mg, an emacs-style thing, but pretty
small. I do not know wether someone somewhere has the small make
compatibility shim to make it a portable thing.)
--steffen
6:55 p.m.
Jeff Johnson wrote in
<393d865b-00db-4064-a84a-3adca8d9554f(a)app.fastmail.com>:
|You should try OpenVi - which is easy to build and includes the OpenBSD’s \
|db and regex dependencies in the tree - https://github.com/johnsonjh/OpenVi
Compiles etc just fine and fast, but has no split/close (i do use
that), and also no UTF-8/Unicode (i am German) -- multibyte in \x
notation is .. too hard.
It is actually larger than vim (as here):
# ll /bin/vi
-rwxr-xr-x 1 root root 1763568 Jun 8 00:23 /bin/vi*
# ll /tmp/x/OpenVi/bin/vi
-rwxr-x--- 1 steffen steffen 2248288 Jul 19 20:50 /tmp/x/OpenVi/bin/vi*
# ldd /tmp/x/OpenVi/bin/vi
linux-vdso.so.1 (0x00007ffdf89e4000)
libncursesw.so.6 => /lib/libncursesw.so.6 (0x00007fd6111fb000)
libc.so.6 => /lib/libc.so.6 (0x00007fd61100b000)
/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fd6112d2000)
# ldd /bin/vi
linux-vdso.so.1 (0x00007ffe8dfa6000)
libm.so.6 => /lib/libm.so.6 (0x00007f87feab2000)
libncursesw.so.6 => /lib/libncursesw.so.6 (0x00007f87fea3b000)
libacl.so.1 => /lib/libacl.so.1 (0x00007f87fea30000)
libc.so.6 => /lib/libc.so.6 (0x00007f87fe840000)
/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f87fed4d000)
libattr.so.1 => /lib/libattr.so.1 (0x00007f87fe838000)
This is vim as CRUX-Linux builds it, out-of-the-box:
./configure \
--prefix=/usr \
--with-vim-name=vim \
--with-compiledby="$(crux | awk '{ print $1, $3 }')" \
--enable-multibyte \
--enable-cscope \
--enable-perlinterp=dynamic \
--enable-python3interp=dynamic \
--without-x \
--disable-gui \
--disable-gpm \
--disable-canberra \
--disable-nls
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
|
|During summer's humble, here's David Leonard's grumble
|
|The black bear, The black bear,
|blithely holds his own holds himself at leisure
|beating it, up and down tossing over his ups and downs with pleasure
|
|Farewell, dear collar bear
7:33 p.m.
It’s only 142KB here - did you strip the binary?
For split, use :E. The lack of multibyte is unfortunately something that can not be
resolved easily without breaking compatibility with the OpenBSD upstream - changes changes
needed would be too extensive.
There is nvi2 for that that, but it might not be as easy build on Linux.
--
Jeffrey H. Johnson
trnsz(a)pobox.com
On Sat, Jul 19, 2025, at 2:55 PM, Steffen Nurpmeso wrote:
Jeff Johnson wrote in
<393d865b-00db-4064-a84a-3adca8d9554f(a)app.fastmail.com>:
|You should try OpenVi - which is easy to build and includes the OpenBSD’s \
|db and regex dependencies in the tree - https://github.com/johnsonjh/OpenVi
Compiles etc just fine and fast, but has no split/close (i do use
that), and also no UTF-8/Unicode (i am German) -- multibyte in \x
notation is .. too hard.
It is actually larger than vim (as here):
# ll /bin/vi
-rwxr-xr-x 1 root root 1763568 Jun 8 00:23 /bin/vi*
# ll /tmp/x/OpenVi/bin/vi
-rwxr-x--- 1 steffen steffen 2248288 Jul 19 20:50
/tmp/x/OpenVi/bin/vi*
# ldd /tmp/x/OpenVi/bin/vi
linux-vdso.so.1 (0x00007ffdf89e4000)
libncursesw.so.6 => /lib/libncursesw.so.6 (0x00007fd6111fb000)
libc.so.6 => /lib/libc.so.6 (0x00007fd61100b000)
/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2
(0x00007fd6112d2000)
# ldd /bin/vi
linux-vdso.so.1 (0x00007ffe8dfa6000)
libm.so.6 => /lib/libm.so.6 (0x00007f87feab2000)
libncursesw.so.6 => /lib/libncursesw.so.6 (0x00007f87fea3b000)
libacl.so.1 => /lib/libacl.so.1 (0x00007f87fea30000)
libc.so.6 => /lib/libc.so.6 (0x00007f87fe840000)
/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2
(0x00007f87fed4d000)
libattr.so.1 => /lib/libattr.so.1 (0x00007f87fe838000)
This is vim as CRUX-Linux builds it, out-of-the-box:
./configure \
--prefix=/usr \
--with-vim-name=vim \
--with-compiledby="$(crux | awk '{ print $1, $3 }')" \
--enable-multibyte \
--enable-cscope \
--enable-perlinterp=dynamic \
--enable-python3interp=dynamic \
--without-x \
--disable-gui \
--disable-gpm \
--disable-canberra \
--disable-nls
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
|
|During summer's humble, here's David Leonard's grumble
|
|The black bear, The black bear,
|blithely holds his own holds himself at leisure
|beating it, up and down tossing over his ups and downs with pleasure
|
|Farewell, dear collar bear
7:47 p.m.
Jeff Johnson wrote in
<4d7ab3f8-8c3e-4589-a6f1-5108fac2507a(a)app.fastmail.com>:
|It’s only 142KB here - did you strip the binary?
No, did not strip; yes, vim is stripped; did not think about that,
i also only strip(1) on "make install", so.. bogus head.
|For split, use :E. The lack of multibyte is unfortunately something \
Ah, also. Ok.
|that can not be resolved easily without breaking compatibility with \
|the OpenBSD upstream - changes changes needed would be too extensive.
I see. But nice and easy compilation, out of the box!
|There is nvi2 for that that, but it might not be as easy build on Linux.
At least not from the repository checkout.
|--
|Jeffrey H. Johnson
|trnsz(a)pobox.com
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
|
|During summer's humble, here's David Leonard's grumble
|
|The black bear, The black bear,
|blithely holds his own holds himself at leisure
|beating it, up and down tossing over his ups and downs with pleasure
|
|Farewell, dear collar bear
5:53 p.m.
r.stricklin wrote in
<DD5D8D30-FDBD-4742-813C-A7F60D7253DA(a)typewritten.org>:
set mouse= " No mouse!!
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
|
|During summer's humble, here's David Leonard's grumble
|
|The black bear, The black bear,
|blithely holds his own holds himself at leisure
|beating it, up and down tossing over his ups and downs with pleasure
|
|Farewell, dear collar bear
20 Jul
20 Jul
1:16 a.m.
Hi Larry,
I've thought about the "if you worked for me", dig and it kind of stung.
As a former global tech guy, I never told my architects, engineers,
developers, qa analysts, bus analysts or even executive assistants what
to use to get their job done. I argued my position on various technical
directions, but I gave in when the argument had merit. Yes, I insisted
on some decisions, but these were high level architectural decisions
where I had budgetary responsibility as well as technical. On smaller
matters of personal productivity, I pretty much ceded that territory to
the individual. When monetary cost was involved, that brought in its own
approval threshold, but by and large, if the individual wanted to use
qedit, q, emacs (why?), ultraedit, etc. So long as it wasn't burdensome
in some way, I could care less. Probably the smartest and most
productive engineer I ever worked with was in love with Borland Brief...
I could edit circles around him with vi, but... he was a masterful
engineer... he got his brief and he seemed happy with it, we got
excellence and quality systems from him...
These days, I'm in academia and enjoy the freedom to use whatever I like
both for work, and for pleasure and I like vi... and xed... and ed...
and, and, and... anything but emacsen, heck even the editors from RTS
are more understandable than emacs, as for vi-alikes, I thought I was a
big fan of nvi (I really am), but now I've seen the clean code for
openvi, its lack of dependencies (other than a c toolchain), and I'm
over on that train now. Really, I have no loyalty.
Your argument about modernity is certainly well trod, particularly in
the halls of the c-suite. Personally, I have seen hundreds of
modernizations over my career and all of them promised improved ease of
use, reduced cost, better integration, yada, yada... Very few, less than
I can count on one hand delivered on the promise. Oh, certainly some
things improved, but overall, pretty much the same activity, but more
complicated, costlier, with more new points to integrate, etc. In my
view, and it could be just mine, vim is one of those modernization
projects. One of these days, some young genius is gonna rise up and
delve into the living system that is Bram's vim, rip its heart out, and
rebuild a spectacular compact editor... at least one can hope.
Thanks,
Will
On 7/18/25 14:43, Larry McVoy wrote:
Last post on this topic because life is too short.
Will, you can do whatever you want. If you worked for me, this would be a
much shorter conversation and you'd be using vim. Modern tools are more
complicated because they do more stuff. Taking your position to the extreme
would have you using a pipeline piped to ed, would it not? vi is a BSDism,
so it isn't "pure", nvi is a rewrite of Joys vi (why? Anyone?)
I get the desire to have simple tools, I'm that way too, but switching
from vi, nvi to vim was seamless. I've never looked at their documentation
other than :help to find how to manipulate their windows. Everything else
just worked.
Have fun with nvi.
On Fri, Jul 18, 2025 at 01:28:54PM -0500, Will Senn wrote:
> Ha Larry. I'm not hidebound, but I do like to understand the software I use
> and I'm more of the if it ain't broke persuasion. The vim manual is maybe
> 5000 pages now (https://nathangrigg.com/vimhelp/vimhelp.pdf) only about
> 100x the nvi manual.... but yeah, different strokes for different folks.
>
> Seems like we're in the weeds though, almost COFF worthy.
>
> I do wonder about vi though and when it became prevalent. In v6, it's
> supposedly possible to get it working, but I've never seen it in virtual
> environs (oh how I've tried). In v7, it's more possible, but again,
I've not
> seen it really working in SIMH (tried that too). BSD 2.11 gets the nod, but
> was it delivered as part of any system prior to 2.11 or was 2.11 really the
> first post v7 unix with vi with wider adoption?
>
> Later,
>
> Will
>
>
>
> On 7/18/25 07:52, Larry McVoy wrote:
>> That's fine, if it works for you it works for you. For me, vim is
>> compat enough (and it has a way to make it more compat if you care
>> I believe) and has some functionality that makes me shake my head
>> at the nvi people.
>>
>> To me, nvi is sort of like v7. Yeah, it's like the original Unix
>> but would you want to live there just because it is "pure"? No
>> networking, no top, it's just a basic Unix. Cool because of how
>> small it is but pretty painful to live there.
>>
>> On Fri, Jul 18, 2025 at 07:24:46AM -0500, Will Senn wrote:
>>> nvi does everything i need it to, it's help fits on a couple of screens,
and
>>> it's easy to remember it all. maybe if I hit a wall with it, I'll
reinstall
>>> vim, but for the screen stuff, don't need it. I don't live in my
editor, or
>>> even the command line, I just use it when it's convenient - which
admittedly
>>> is a lot of the time. But, it's the terminal that's most useful,
not vi. So,
>>> if I want more screen, I just open a terminal window. My monitor has room
>>> for a dozen or so :) not including guake, workspaces, etc... in the modern
>>> era, of course!
>>>
>>> Will
>>>
>>> On 7/18/25 05:09, Larry McVoy wrote:
>>>> On Thu, Jul 17, 2025 at 08:29:21PM -0700, Bakul Shah via TUHS wrote:
>>>>> On Jul 17, 2025, at 7:52???PM, segaloco via TUHS
<tuhs(a)tuhs.org> wrote:
>>>>>>> If you just do ":E" it will put both windows on the
current file,
>>>>>>> exactly the same as vim. But both do it wrong (IMHO) as the
second
>>>>>>> window starts at the same place (e.g top of the file). In the
Rand
>>>>>>> Editor if the split is at line N, the bottom window shows
lines N+1.
>>>>>>> Exact same behavior for vertical split (the left and right
side
>>>>>>> windows show the same portions as before).
>>>>>>>
>>>>>>>> On Jul 17, 2025, at 6:09???PM, Larry McVoy lm(a)mcvoy.com
wrote:
>>>>>>>>
>>>>>>>> Not really the same. :sp splits your window in half and
puts you in
>>>>>>>> two different windows on the same file. Each window, in
vim, is full
>>>>>>>> on vi, you can do :e fillename and now that window is on
that file.
>>>>>> Not historic but as of present I shunt windowing off to GNU
screen and just have separate nvi sessions in each. This may speak to ignorance on my
part regarding advantages of opening multiple files in the same session in any given vi.
I keep vim around for when I need the value adds, but nvi is linked as ex/vi/view. I
suppose it is nice to keep your window configuration tightly coupled, but I also
frequently have vi in one pane and am using the others for od output and build/test cycle
for disassembly projects.
>>>>> Going via screen(1) can be more painful. If you want to copy some
lines
>>>> >from one file to another, you have to either create a temp file or
>>>>> use the window systems's cut/paste buffer/clipboard. The latter
can
>>>>> actually works worse (if you have autoindent turned on for example).
>>>>> Also the modal nature of vi/vim can wreak havoc (copied text can be
>>>>> mistakenly interpreted as commands).
>>>>>
>>>>> In vi you can yank lines in file1, paste in file2. And can share
>>>>> options, tags etc. In the rand editor you can scroll two windows in
>>>>> unison (handy if one shows column headings and the other some rows).
>>>>> See acme for an example of a well designed multi window editor.
>>>> I was going to respond to the screen stuff but Bakul beat me to it.
>>>> In vim, you just have a split view of the same file. Changes in
>>>> either window will show up in the other window. For example
>>>>
>>>> vim foo.c # foo.c exists and has a 100 lines
>>>> :sp
>>>>
>>>> now you have both windows looking at the same file
>>>>
>>>> start changing something and it is done in both windows.
>>>>
>>>> Screen is nowhere near that and using it to claim that nvi is fine
>>>> is missing the point by a country mile.
>>>>
>>>> And I don't understand the dislike of vim. Sure, it's got a
pile
>>>> of stuff that old time Unix people would dislike "cat came back
>>> >from BSD wagging it's tail" (or something that Rob said) but
you
>>>> don't have to use any of that. For me, vim is a finger compat
>>>> vi clone that has some really really useful extensions, I use
>>>> :split
>>>> all the time. Saying you prefer nvi in the face of that is
>>>> something that makes no sense to me. I've used nvi, I get that
>>>> it is compat with Joys vi, but so what? vim is more useful and
>>>> it is also compat.
>>>>
>>>> Time marches on, perhaps march with it?
>>>>
>>>> --lm
7:59 a.m.
At 2025-07-19T20:16:33-0500, Will Senn wrote:
I've thought about the "if you worked for
me", dig and it kind of
stung.
Manure often does.
Larry came up in the soil from which grew tech bro culture.
A preoccupation with managing the preferences of others, as with Steve
Jobs's "thought leadership", is consistent with the authoritarian style
he advocates.
In contrast I think questions of engineering are more important than
those of fashion. But fashion is easier, and apparently more profitable
to write about, so people who like to see their names trafficked by
journalists follow the path of less resistance.
I admit that a lot more people have heard of Condé Nast than Isambard
Brunel or Oliver Heaviside.
As a former global tech guy, I never told my
architects, engineers,
developers, qa analysts, bus analysts or even executive assistants
what to use to get their job done. I argued my position on various
technical directions, but I gave in when the argument had merit. Yes,
I insisted on some decisions, but these were high level architectural
decisions where I had budgetary responsibility as well as technical.
On smaller matters of personal productivity, I pretty much ceded that
territory to the individual. When monetary cost was involved, that
brought in its own approval threshold, but by and large, if the
individual wanted to use qedit, q, emacs (why?), ultraedit, etc. So
long as it wasn't burdensome in some way, I could care less. Probably
the smartest and most productive engineer I ever worked with was in
love with Borland Brief... I could edit circles around him with vi,
but... he was a masterful engineer... he got his brief and he seemed
happy with it, we got excellence and quality systems from him...
I was taught "if it ain't broke, and we don't expect it to break,
don't
fix it" as a principle of sound engineering.
I'd say it applies to personnel management as well. Larry may not.
On the milder topic of editor preferences, I'm a vi(m) user but employ
Emacs bindings in readline applications and maintained my own fork of mg
(microemacs) for a while, to see how the other half lived. I discovered
that a much bigger chunk of Emacs advocacy is predicated on its
"finger-feel"[1] and some other built-in features than upon Lisp
scriptability. In other words, far more Emacs advocates trumpeted the
value of its customizability via Lisp than actually developed competence
in writing Lisp for themselves. (On the bright side, Atom/Electron and
VSCode could well have drawn away people of this mentality from younger
generations, such that anyone choosing an Emacs today is more serious
about developing Lisp expertise. Good for them.)
While Vim has also been Turing-equivalently programmable for decades
now, via peculiar extensions to the ex language,[1] but also Perl,
Python, and Tcl, its community has seemed less brash about that fact. I
think that's because unsophisticated Emacs users were attempting to ride
on Lisp's coattails as an early and innovative yet satisfyingly esoteric
development in the history of programming languages. Again, we
encounter people more concerned with superficial matters of fashion than
with overcoming problems of engineering.
I did once have loyalty to nvi, and did have a conversion experience,
and I remember exactly what it was. It was visual mode. I was
practiced at writing ed-style commands applying to address ranges to get
stuff done at the colon prompt. That frequently meant having to think
up the shortest possible regex that would capture the range I wanted, or
having to count lines on the screen--both tedious--or make a crude and
thus frequently inaccurate guess. Visual mode, where I use line mode
"V" 10 times more often than character mode "v" and character mode 10
times more often than rectangle mode "Control+V", killed off that
problem for me completely.
Nowadays, I only ever write ed/ex-style addresses when composing sed
scripts, which suits me just fine, because I only write a sed script
when I need a repeatable procedure or operation in the first place,
maybe in a Makefile. In those scenarios, the extra brain cycles given
to regex construction or perfectly reliable line-counting pays off.
Like others in this thread, but later in my personal history, I came to
find vertical splits (and vimdiff(1)) extremely useful. For composing
emails, though, but for one factor[3] I could probably be thrown into
nvi and not miss any Vim features.
Maybe I should start submitting "textwidth" patches to the various nvi
descendants and see if anyone will accept them.
For years I nursed the thought that a wonderful joke to play on RMS's
tedious Emacs partisanship would have been to add Guile to Vim's list of
extension languages.
But I guess no one enjoys schadenfreude _that_ much.
Regards,
Branden
[1] which I suspect is objectively worse than vi's by keystroke count,
but I am unwilling to write a grant proposal to research the matter
properly ;-)
[2] recently given a major overhaul with "vim9script", which seems like
a worthwhile cleanup but of which I've not reached an informed
opinion
[3] The "textwidth" option is a killer Vim feature because vi's
"wrapmargin" was ill-conceived. It arose from Teletype/punched-card
thinking, poorly anticipating varying terminal display widths. I'll
piss off Larry some more by punking on Bill Joy and claim that
"wrapmargin" solved the wrong problem. Unless you're composing for
paper, which was expressly _not_ the point of *VI*, you don't _care_
how wide the right margin is in character cells. You care about how
wide the line of text is. (You might also care about an indent.)
_nroff_ had already gotten this right in 1972, even on paper output,
with `.ll` and `.in`. There was no configuration knob for a right
margin or indent.
I'm sorry, Bill--I think you missed it.
So saith the GBR 9000, foolproof and incapable of error. ;-)
11:38 a.m.
On Sun, Jul 20, 2025 at 02:59:08AM -0500, G. Branden Robinson wrote:
At 2025-07-19T20:16:33-0500, Will Senn wrote:
Huh, you won't be surprised I have a different perspective. Allow me
to tell you how I describe managing engineers. Suppose we were artists,
there were 4 of us. Someone brought us a photograph and said "I want
a painting of that". OK, split it into quarters and go do it. What
do we get back?
Well, artist #1 likes oil paints so that's what s/he did.
Artist #2 likes charcoal so that's what they did.
Artist #3 likes pen and ink.
Artist #4 likes water color.
Is that a painting? Maybe if you like a mish mash of stuff that doesn't
go together. Most people would call it garbage and refuse to pay.
My so called "authoritarian style" is nothing more than I was the leader,
I had to pick one style. And, yes, it means if you have N people working
you usually have N-1 pissed off people because they weren't getting to do
things their way. Letting them do things their way means there is no
overall picture you are driving towards.
And I'm not above being overridden. I personally hate GNU make for all
the similar reasons you are advocating for a smaller vi. But my team
convinced me it was less work to move to that than maintain all the
scripts we were using to use a simple make.
But yeah, when people work for me, I lead. I set the tone. It wasn't
tech bro nonsense, it was about herding people towards the same picture.
I wasn't trying to tell Will he can't use whatever editor he wants, I was
trying to tell Will I wouldn't tolerate this much back and forth about his
personal preferences distracting us from shipping product. My team had
emacs people and vi people, nobody cared so long as you got your job done.
What we didn't have is editor arguments clogging up our thinking.
I've thought about the "if you worked
for me", dig and it kind of
stung.
Manure often does.
Larry came up in the soil from which grew tech bro culture.
A preoccupation with managing the preferences of others, as with Steve
Jobs's "thought leadership", is consistent with the authoritarian style
he advocates. 
12:24 p.m.
Larry McVoy <lm(a)mcvoy.com> writes:
I wasn't trying to tell Will he can't use whatever editor he wants, I was
trying to tell Will I wouldn't tolerate this much back and forth about his
personal preferences distracting us from shipping product. My team had
emacs people and vi people, nobody cared so long as you got your job done.
What we didn't have is editor arguments clogging up our thinking.
To jump in here before everyone poo poos this thread too much. I agree with this sentiment
when it's time to get work done.
That said, I've enjoyed this thread b/c I like getting other peoples perspectives,
especially from folks that I think have some clue. Sometimes I learn something new or a
new perspective and I end up adapting new tools or practices b/c of it -- even now that my
beard/hair is grey.
I find these are actually fun conversations to have occasionally -- maybe in a cafe/bar or
even on a mailing list. Maybe not everyday or all the time, but sometimes. :)
FWIW for coding/email/organizing/scheduling I now use some franken-setup project called
"spacemacs" which is emacs, but the UI of vi, launching much faster, that uses a
meta-configuration that makes it simple to enable all those features (and yes I still
write lisp when needed but that's almost never to get what I want anymore).
For quick editing I still just type `vi` and use ^Z, even though I also use tmux and long
running disconnected remote sessions.
Thanks,
Chris.
8:26 p.m.
New subject: Personal Preference vs Group Productivity (was Re: Re: End of an era: the last ATC (USENIX Annual Technical Conference))
[TUHS to Bcc; Cc'ed to COFF to redirect for follow-ups]
On Sun, Jul 20, 2025 at 8:24 AM Christian Hopps <chopps(a)chopps.org> wrote:
Larry McVoy <lm(a)mcvoy.com> writes:
I think some folks may have interpreted Larry's statements as stating
that, if you worked for him, you used the tools he mandated. But I
don't think that's what he meant (at least not about text editors),
and I think that your interpretation is correct: use whatever works
for you, but don't waste a bunch of other people's time pushing the
virtunes of your preferred tools on those who already have things that
work for them.
I think that's fair. That said, there is a qualitative difference
between the sort of banter people may bat around over lunch, and
someone seriously trying to get everyone else to use their preferred
editor (editors are just one example, though interesting in this
regard because choosing them seems to be such a deeply personal
thing). I think the discussions on these mailing lists are closer to
the former than the latter, and as long as it remains friendly, I
really don't see any harm in that.
But this got me thinking that surely there are decisions made on a
project basis, where individual preference by itself is not, and
cannot be, the deciding factor for use. Perhaps the most obvious is
code-formatting styles, but others may be choice of build tool,
revision control system, implementation language, and so on. Where
does one draw the line between the tools an individual chooses for
their own use, and those mandated by the group?
I suspect there is no one, good, universal answer. Take implementation
language as an example: "I'll write my part in C, you write yours in
FORTRAN..." sounds highly suspect at first, but _might_ make sense if
"I'm" tasked with writing the IO part and "you're" taking on
the
numerical bits and have to interface with a numerical library written
in Fortran. Indeed, I've found that when people try to define some
kind of general rule for deciding this or that, they tend to be trying
to simplify really complex things in a very superficial way that's not
reflective of actual practice.
But maybe there is some utility in thinking about this generally.
Perhaps a reasonable first-order approximation for finding a dividing
line might be taken from the answer to the question, "is this
something that really only impacts me, or is it going to have an
impact on my peers, as well?" Editors sort of make sense here; by and
large, as long as I can use the tools effectively, my peers aren't
going to be impacted if I use tool A to enter text versus tool B.
Similarly with whether I prefer light text on a darker background, or
dark text on a lighter background, what font I use, type size, what
window manager I use, and so on. But on the other hand, if I demanded
that I be able to use My preferred code formatting style regardless of
what the rest of the code used, then that _does_ have an impact on
those around me, so deserves more thought. And _that's_ the kind of
thing that people can argue about endlessly until finally someone just
makes a decision.
I've said this before, but Google's style guides were a great case in
point here. To be honest, I didn't like them and thought that the
resulting code was ugly. But after a few weeks, I just stopped
noticing that, and I had to admit that they were a great aid in being
able to approach a codebase with billions of LOC in it. When
`clang-format` came along and took out a lot of the tedium of making
your code conform to the style guide, it really freed up a lot of
mental capacity to start thinking about real problems, design, and so
on, and not just where the braces went. But that was all predicated on
someone just Making a Decision.
I wasn't trying to tell Will he can't
use whatever editor he wants, I was
trying to tell Will I wouldn't tolerate this much back and forth about his
personal preferences distracting us from shipping product. My team had
emacs people and vi people, nobody cared so long as you got your job done.
What we didn't have is editor arguments clogging up our thinking.
To jump in here before everyone poo poos this thread too much. I agree with this
sentiment when it's time to get work done.
That said, I've enjoyed this thread b/c I like getting other peoples perspectives,
especially from folks that I think have some clue. Sometimes I learn something new or a
new perspective and I end up adapting new tools or practices b/c of it -- even now that my
beard/hair is grey.
I find these are actually fun conversations to have occasionally -- maybe in a cafe/bar
or even on a mailing list. Maybe not everyday or all the time, but sometimes. :) FWIW for coding/email/organizing/scheduling I now use
some franken-setup project called "spacemacs" which is emacs, but the UI of vi,
launching much faster, that uses a meta-configuration that makes it simple to enable all
those features (and yes I still write lisp when needed but that's almost never to get
what I want anymore).
For quick editing I still just type `vi` and use ^Z, even though I also use tmux and long
running disconnected remote sessions.
Personally, I've found it very helpful to maintain some level of
proficiency in a variety of different text editors, using different
tools for different things. Part of this is the whole, "when in Rome,
do as Romans do..." sort of thing: I'm not looking for `vi` on VMS or
Multics or VM/CMS or something, but I'll also happily use emacs to
write Lisp, and on plan 9, I'll use sam or acme for C or troff or
whatever. On my Mac, Zed or VSCode work pretty well. On remote Unix
machines, a lot of the kids are hip on this "Helix" thing these days.
Speaking of plan 9.... One nice thing about a system that embraces
true resource sharing is that, when one can construct an environment
that contains the set of all the resources one needs to work with and
then one can bring one's local toolset to bear on those resources.
Plan 9, where resources are represented by files in mutable
namespaces, really exemplifies this, which is distinct from a more
"remote access" model, where I use something like ssh or mosh or
telnet to login to a remote system. In the remote access model, I'm
constrained by whatever tools are available on a remote system. So if
I'm logging into some remote server over SSH or something, it's handy
to know whatever editor may be on the distant end. It's a shame more
systems aren't like plan 9 in this way, but they aren't, and for
better or worse, I've still got to use them, and it's so much less
personally aggravating to care deeply about what tools are available
in that context.
- Dan C.
1:47 p.m.
New subject: how (not) to manage engineers (was: End of an era: the last ATC (USENIX Annual Technical Conference))
Hi Larry,
At 2025-07-20T04:38:02-0700, Larry McVoy wrote:
On Sun, Jul 20, 2025 at 02:59:08AM -0500, G. Branden
Robinson wrote:
Indeed not. :)
At 2025-07-19T20:16:33-0500, Will Senn wrote:
Huh, you won't be surprised I have a different perspective. I've thought about the "if you worked
for me", dig and it kind of
stung.
Manure often does.
Larry came up in the soil from which grew tech bro culture.
A preoccupation with managing the preferences of others, as with
Steve Jobs's "thought leadership", is consistent with the
authoritarian style he advocates. Allow me to tell you how I describe managing
engineers. Suppose we
were artists, there were 4 of us. Someone brought us a photograph and
said "I want a painting of that". OK, split it into quarters and go
do it. What do we get back?
Well, artist #1 likes oil paints so that's what s/he did. Artist #2
likes charcoal so that's what they did. Artist #3 likes pen and ink.
Artist #4 likes water color.
Is that a painting? Maybe if you like a mish mash of stuff that
doesn't go together. Most people would call it garbage and refuse to
pay.
Yeah. I think your analogy is facile and superficial and therefore
characteristic of of Silicon Valley executive culture. Here's why.
First, text editors don't leave traces of themselves in the work
product.[1]
Second, _especially_ in a leadership position (although this is more
specifically the role of "architect" if someone has it), you have to be
conscious of the boundaries of your software modules.
A software project of sufficient complexity to be worth commissioning on
a professional basis is, despite its contractual representation at the
executive level, not a unitary object like an individual painting or
photograph or 2½-minute folk song. Such things are not (formally)
complex, but "elemental": if you decompose them, they stop being what
they are.
Often, a first-order decomposition of a software system leaves you
with...a collection of other software systems, plus, ideally, some
ancillary documentation and/or an integration test suite.
My so called "authoritarian style" is
nothing more than I was the
leader, I had to pick one style.
Right. To hear you tell it, you preoccupied yourself with matters of
style and let others worry about the harder problems of architecture and
interfacing. Maybe that was the right choice given your skill set and
those of your staff.
If that characterization cuts, there is a remedy: share a leadership
anecdote where you made (or mediated) a hard decision on a non-stylistic
matter. Maybe two algorithms of the same order in big-O notation were
pitched for a certain software module, but one was preferable on some
non-obvious basis. You've spoken before of the high value of SCCS's
"weave" to BitKeeper. Was there anything the weave made hard or was bad
at? Were you ever on the verge of reconsidering it? If so, what, on an
_engineering_ basis rather than one of style or personal admiration,
mandated its retention?
If you have stories like that, those would, to me, constitute examples
of technical leadership. And, if all "stakeholders" (your client[s]
_and_ your staff) were happy with the outcome, then they could be
examples of _good_ technical leadership, too.
And, yes, it means if you have N people working you
usually have N-1
pissed off people because they weren't getting to do things their way.
I suspect you accurately perceived the presence of frustration. I also
bet you assumed its cause rather than undertaking an earnest exploration
thereof. A confounding factor here is that a project can have so many
problems that the individual contributors themselves have trouble
accurately identifying an "overall" problem or a single "worst" one
that
they have. Further, if they are experiencing deadline pressure, whether
imposed by themselves or by leadership and are asked to identify
"blockers", they're likely to name the obstacles that are easiest to
articulate[2] or that they most recently struggled with.[3] One
generally can't calendar the removal of as-yet-unarticulated problems.
If the engineers have the same blocker day after day, then management is
failing to remove them. If the engineers have NEW blockers every day or
every week, and you have confidence in your recruitment/hiring, then
the staff is not sandbagging you--the project has deep problems.
My personal experience is that underspecification and otherwise
unarticulated expectations are the root causes of nearly every problem
that cause anguish among staff. And behind that problem is the worse
one that managers climb into contractual beds with their counterparties
without having done their necessary homework first. The client never
wants to admit that they haven't really though through what it is
they're asking for. They've already made promises to a director, VP, or
someone in the C suite. So they yell at you and you yell at your staff.
The manure, as it were, rolls downhill.
Letting them do things their way means there is no
overall picture you
are driving towards.
In engineering, we do not implement an "overall picture", but to a
detailed specification.
If you lack a detailed specification to implement, what you are doing is
not (solely) engineering. That's not necessarily a bad thing; you are
engaged in design and possibly in research. Charge more. Develop your
staff by helping them get conference papers out of the work.
And I'm not above being overridden. I personally
hate GNU make for
all the similar reasons you are advocating for a smaller vi.
That wasn't me, but I'll freely admit that Vim has many features I don't
use. I have found that time spent seeking mastery of one tool is good
practice in judging the "right-sizing" of another. If nothing else, it
helps one learn which hills aren't worth dying on. ;-)
Regarding make(1), POSIX 2024 has made it _much_ better. I still think
the BSDs' snarling adherence to old-style suffix rules, which are
inflexible and ambiguous, and restrictions on $< are counterproductive,
but a lot of stuff that used to not be portable, is portable now.
But my team convinced me it was less work to move to
that than
maintain all the scripts we were using to use a simple make.
But yeah, when people work for me, I lead. I set the tone. It wasn't
tech bro nonsense, it was about herding people towards the same
picture.
I have a slender hope that I can persuade you that these things are
actually the same in every way that matters. As implied above, this
doesn't make you a tech bro yourself, necessarily, it might mean you're
emphasizing the wrong elements of your experience for an audience of
salty old engineers, contrast with venture capitalists.
In martial arts training, there are "degrees" of black belt. Only the
first few degrees have anything to do with one's own ability or
perfection of form. After that, your advancement is determined by how
many black belts you _train_. To become a master, you must train many
black belts. To become a grand master, you must train many masters.
While I'm sure there are perverse incentives in martial arts instruction
(hello, capitalism), this approach of making your own advancement beyond
a certain point dependent on the development of people no longer
accountable to you strikes me as a worthwhile corrective to the
narcissistic orientation of leadership in software development.
Being a good example is a different phenomenon than being an object of
emulation. One phenomenon is deep, the other shallow. Steve Jobs was
good at producing a lot of fawning emulators with black turtlenecks and
glib proclamations about the future of technology. Steve Wozniak has in
substantial measure dedicated himself to producing more good engineers.
I wasn't trying to tell Will he can't use
whatever editor he wants, I
was trying to tell Will I wouldn't tolerate this much back and forth
about his personal preferences distracting us from shipping product.
That's not how I read what you said, but fine. I agree that bickering
over tool choice can be a distraction from satisfying the contract and
getting the final payment. But the sword of opportunity cost cuts both
ways. You can't always be sure that the most readily available
substitute good for an editor argument is a laser-focused coding
session[4] on implementing an element of a deliverable.
If your engineers are motivated, you will find that they don't distract
themselves with nonsense _when they have a better alternative_. A good
engineering manager deeply understands the XKCD concept of "nerd
sniping" and knows how to adapt it to the benefit of the individual
contributor, their team, the client, and consequently themselves.[5]
My team had emacs people and vi people, nobody cared
so long as you
got your job done.
That's a salutary attitude. But engineers also need time and vehicles
for decompression, and one of the things they can use their downtime for
is playful practice at evaluating tradeoffs between competing designs or
systems.
If you have an engineer who's going around harassing their peers for
choosing the "wrong" editor, the problem is not their choice of editor,
which might be "correct" in your opinion. The problem is that they're
interfering unjustifiably with the work of their colleagues. Addressing
that problem "sets the tone" much better than expressing, let alone
mandating, your own preferences. It's what _I_ expect of a manager, at
any rate.
What we didn't have is editor arguments clogging
up our thinking.
Done well--and this might happen only in a minority of cases--editor
arguments can _enhance_ people's thinking; see "playful practice" above.
And even if they don't, if they're no more destructive than a dispute
over whether the coach of the local sportsball team was an idiot for
benching player X in the Big Game last weekend, or than knocking off 30
minutes early for beers together at the end of a frustrating day, then
good leadership can mean leaving some rough spots unsanded.
Regards,
Branden
[1] _Programmers_ might so do, with vi "modelines" or Emacs "local
variables" in text constitutive of a comment in the program source
code. Different matter.
[2] another instance of our old friend the "streetlight effect"
https://en.wikipedia.org/wiki/Streetlight_effect
[3] https://en.wikipedia.org/wiki/Recency_bias
[4] or automated test construction, or documentation revision--wait, why
is everybody laughing?
[5] https://xkcd.com/356/
2:38 p.m.
New subject: how (not) to manage engineers (was: End of an era: the last ATC (USENIX Annual Technical Conference))
On Sun, Jul 20, 2025 at 08:47:54AM -0500, G. Branden Robinson wrote:
I really doubt you know the first thing about how actual Silicon Valley
execs, good ones, work. Have you been one? I doubt it. Have you worked
closely with any good ones? I doubt it. You looked down your nose at
Steve Jobs, and while I agree he wasn't a nice person, he knew what people
wanted before people knew what they wanted. That's a rare talent.
I read the rest of your rant and nothing in it gave me any hope that you
understand what a good exec does. You are foccused on the fluff pieces
that talk about crappy executives. You appear to have no knowledge
about how running a company works, your comments about specifications
nicely highlight that. Classic engineer blinders.
I got paid to argue with Suns execs for 6 months. Didn't win the
argument. But I learned how they worked and it is NOTHING like how an
engineer works.
You want your specifications, everything carefully thought through,
fully researched, not a flaw to be found. You move forward when you are
sure you have the right answer, there is no way anyone will find fault
with your reasoning.
Real execs don't have that luxury. While you move forward when you are
100% sure you are correct, you've done the work to be sure, they can't
afford that.
What I learned, in my brief but long enough stint with execs, is they
have to, over and over again, make a decision with about 10% of the
info that you, Brandon, would be comfortable with. Why? Because all
of their competition is doing the same thing. Any CEO who waits long
enough to know that they have the right answer has missed their market,
someone else guessed earlier and beat them to it.
I found it pretty horrifying and a miserable way to make a living.
You, Brandon, sitting here and passing judgement on people making those
calls is insulting. You don't have that experience, you don't know how
shitty it is to be forced to guess, and guess correctly, with not enough
information.
Allow me to
tell you how I describe managing engineers. Suppose we
were artists, there were 4 of us. Someone brought us a photograph and
said "I want a painting of that". OK, split it into quarters and go
do it. What do we get back?
Well, artist #1 likes oil paints so that's what s/he did. Artist #2
likes charcoal so that's what they did. Artist #3 likes pen and ink.
Artist #4 likes water color.
Is that a painting? Maybe if you like a mish mash of stuff that
doesn't go together. Most people would call it garbage and refuse to
pay.
Yeah. I think your analogy is facile and superficial and therefore
characteristic of of Silicon Valley executive culture. Here's why.
2:42 p.m.
New subject: how (not) to manage engineers (was: End of an era: the last ATC (USENIX Annual Technical Conference))
On Sun, Jul 20, 2025 at 08:47:54AM -0500, G. Branden Robinson wrote:
My code is open source, if you read it and understand it, you'd see that
you couldn't be more wrong.
I'll let my code and accomplishments speak for themselves, I'm retired,
Brandon. I'm no longer in the business of trying to change minds, thank
god.
I'm reminded of the look of horror on the face of one of my fishing buddies,
when another buddy asked him if he didn't want to keep his finger in the
game, mentor some people, sit on some boards, etc. He replied with something
like "I managed people for decades, the last thing I want from retirement
is more of that". Indeed. Amen.
My so called
"authoritarian style" is nothing more than I was the
leader, I had to pick one style.
Right. To hear you tell it, you preoccupied yourself with matters of
style and let others worry about the harder problems of architecture and
interfacing. Maybe that was the right choice given your skill set and
those of your staff. 
3:06 p.m.
New subject: how (not) to manage engineers (was: End of an era: the last ATC (USENIX Annual Technical Conference))
Enough, already.
Doug
On Sun, Jul 20, 2025 at 10:42 AM Larry McVoy <lm(a)mcvoy.com> wrote:
On Sun, Jul 20, 2025 at 08:47:54AM -0500, G. Branden Robinson wrote:
My code is open source, if you read it and understand it, you'd see that
you couldn't be more wrong.
I'll let my code and accomplishments speak for themselves, I'm retired,
Brandon. I'm no longer in the business of trying to change minds, thank
god.
I'm reminded of the look of horror on the face of one of my fishing buddies,
when another buddy asked him if he didn't want to keep his finger in the
game, mentor some people, sit on some boards, etc. He replied with something
like "I managed people for decades, the last thing I want from retirement
is more of that". Indeed. Amen.
My so
called "authoritarian style" is nothing more than I was the
leader, I had to pick one style.
Right. To hear you tell it, you preoccupied yourself with matters of
style and let others worry about the harder problems of architecture and
interfacing. Maybe that was the right choice given your skill set and
those of your staff. 
9:18 p.m.
New subject: how (not) to manage engineers
On Sun, Jul 20, 2025 at 11:06:42AM -0400, Douglas McIlroy wrote:
Enough, already.
Doug
Thanks Doug. Yes please, I think the conversation is descending below
what I'd like to see here in TUHS/COFF and everybody has already made
their point.
Cheers, Warren
11:40 p.m.
New subject: how (not) to manage engineers (was: End of an era: the last ATC (USENIX Annual Technical Conference))
Maybe Doug's comment was too succinct.
This back-and-forth personal argument, laced with insults and disrespect,
seems wildly inappropriate for TUHS.
Marc Rochkind
On Sun, Jul 20, 2025 at 4:22 PM G. Branden Robinson <
g.branden.robinson(a)gmail.com> wrote:
Hi Larry,
At 2025-07-20T04:38:02-0700, Larry McVoy wrote:
--
Subscribe to my Photo-of-the-Week emails at my website mrochkind.com.
On Sun, Jul 20, 2025 at 02:59:08AM -0500, G.
Branden Robinson wrote:
Indeed not. :)
At 2025-07-19T20:16:33-0500, Will Senn wrote:
Huh, you won't be surprised I have a different perspective. I've thought about the "if you worked
for me", dig and it kind of
stung.
Manure often does.
Larry came up in the soil from which grew tech bro culture.
A preoccupation with managing the preferences of others, as with
Steve Jobs's "thought leadership", is consistent with the
authoritarian style he advocates. Allow me to tell you how I describe managing
engineers. Suppose we
were artists, there were 4 of us. Someone brought us a photograph and
said "I want a painting of that". OK, split it into quarters and go
do it. What do we get back?
Well, artist #1 likes oil paints so that's what s/he did. Artist #2
likes charcoal so that's what they did. Artist #3 likes pen and ink.
Artist #4 likes water color.
Is that a painting? Maybe if you like a mish mash of stuff that
doesn't go together. Most people would call it garbage and refuse to
pay.
Yeah. I think your analogy is facile and superficial and therefore
characteristic of of Silicon Valley executive culture. Here's why.
First, text editors don't leave traces of themselves in the work
product.[1]
Second, _especially_ in a leadership position (although this is more
specifically the role of "architect" if someone has it), you have to be
conscious of the boundaries of your software modules.
A software project of sufficient complexity to be worth commissioning on
a professional basis is, despite its contractual representation at the
executive level, not a unitary object like an individual painting or
photograph or 2½-minute folk song. Such things are not (formally)
complex, but "elemental": if you decompose them, they stop being what
they are.
Often, a first-order decomposition of a software system leaves you
with...a collection of other software systems, plus, ideally, some
ancillary documentation and/or an integration test suite.
My so called "authoritarian style" is
nothing more than I was the
leader, I had to pick one style.
Right. To hear you tell it, you preoccupied yourself with matters of
style and let others worry about the harder problems of architecture and
interfacing. Maybe that was the right choice given your skill set and
those of your staff.
If that characterization cuts, there is a remedy: share a leadership
anecdote where you made (or mediated) a hard decision on a non-stylistic
matter. Maybe two algorithms of the same order in big-O notation were
pitched for a certain software module, but one was preferable on some
non-obvious basis. You've spoken before of the high value of SCCS's
"weave" to BitKeeper. Was there anything the weave made hard or was bad
at? Were you ever on the verge of reconsidering it? If so, what, on an
_engineering_ basis rather than one of style or personal admiration,
mandated its retention?
If you have stories like that, those would, to me, constitute examples
of technical leadership. And, if all "stakeholders" (your client[s]
_and_ your staff) were happy with the outcome, then they could be
examples of _good_ technical leadership, too.
And, yes, it means if you have N people working
you usually have N-1
pissed off people because they weren't getting to do things their way.
I suspect you accurately perceived the presence of frustration. I also
bet you assumed its cause rather than undertaking an earnest exploration
thereof. A confounding factor here is that a project can have so many
problems that the individual contributors themselves have trouble
accurately identifying an "overall" problem or a single "worst" one
that
they have. Further, if they are experiencing deadline pressure, whether
imposed by themselves or by leadership and are asked to identify
"blockers", they're likely to name the obstacles that are easiest to
articulate[2] or that they most recently struggled with.[3] One
generally can't calendar the removal of as-yet-unarticulated problems.
If the engineers have the same blocker day after day, then management is
failing to remove them. If the engineers have NEW blockers every day or
every week, and you have confidence in your recruitment/hiring, then
the staff is not sandbagging you--the project has deep problems.
My personal experience is that underspecification and otherwise
unarticulated expectations are the root causes of nearly every problem
that cause anguish among staff. And behind that problem is the worse
one that managers climb into contractual beds with their counterparties
without having done their necessary homework first. The client never
wants to admit that they haven't really though through what it is
they're asking for. They've already made promises to a director, VP, or
someone in the C suite. So they yell at you and you yell at your staff.
The manure, as it were, rolls downhill.
Letting them do things their way means there is
no overall picture you
are driving towards.
In engineering, we do not implement an "overall picture", but to a
detailed specification.
If you lack a detailed specification to implement, what you are doing is
not (solely) engineering. That's not necessarily a bad thing; you are
engaged in design and possibly in research. Charge more. Develop your
staff by helping them get conference papers out of the work.
And I'm not above being overridden. I
personally hate GNU make for
all the similar reasons you are advocating for a smaller vi.
That wasn't me, but I'll freely admit that Vim has many features I don't
use. I have found that time spent seeking mastery of one tool is good
practice in judging the "right-sizing" of another. If nothing else, it
helps one learn which hills aren't worth dying on. ;-)
Regarding make(1), POSIX 2024 has made it _much_ better. I still think
the BSDs' snarling adherence to old-style suffix rules, which are
inflexible and ambiguous, and restrictions on $< are counterproductive,
but a lot of stuff that used to not be portable, is portable now.
But my team convinced me it was less work to move
to that than
maintain all the scripts we were using to use a simple make.
But yeah, when people work for me, I lead. I set the tone. It wasn't
tech bro nonsense, it was about herding people towards the same
picture.
I have a slender hope that I can persuade you that these things are
actually the same in every way that matters. As implied above, this
doesn't make you a tech bro yourself, necessarily, it might mean you're
emphasizing the wrong elements of your experience for an audience of
salty old engineers, contrast with venture capitalists.
In martial arts training, there are "degrees" of black belt. Only the
first few degrees have anything to do with one's own ability or
perfection of form. After that, your advancement is determined by how
many black belts you _train_. To become a master, you must train many
black belts. To become a grand master, you must train many masters.
While I'm sure there are perverse incentives in martial arts instruction
(hello, capitalism), this approach of making your own advancement beyond
a certain point dependent on the development of people no longer
accountable to you strikes me as a worthwhile corrective to the
narcissistic orientation of leadership in software development.
Being a good example is a different phenomenon than being an object of
emulation. One phenomenon is deep, the other shallow. Steve Jobs was
good at producing a lot of fawning emulators with black turtlenecks and
glib proclamations about the future of technology. Steve Wozniak has in
substantial measure dedicated himself to producing more good engineers.
I wasn't trying to tell Will he can't
use whatever editor he wants, I
was trying to tell Will I wouldn't tolerate this much back and forth
about his personal preferences distracting us from shipping product.
That's not how I read what you said, but fine. I agree that bickering
over tool choice can be a distraction from satisfying the contract and
getting the final payment. But the sword of opportunity cost cuts both
ways. You can't always be sure that the most readily available
substitute good for an editor argument is a laser-focused coding
session[4] on implementing an element of a deliverable.
If your engineers are motivated, you will find that they don't distract
themselves with nonsense _when they have a better alternative_. A good
engineering manager deeply understands the XKCD concept of "nerd
sniping" and knows how to adapt it to the benefit of the individual
contributor, their team, the client, and consequently themselves.[5]
My team had emacs people and vi people, nobody
cared so long as you
got your job done.
That's a salutary attitude. But engineers also need time and vehicles
for decompression, and one of the things they can use their downtime for
is playful practice at evaluating tradeoffs between competing designs or
systems.
If you have an engineer who's going around harassing their peers for
choosing the "wrong" editor, the problem is not their choice of editor,
which might be "correct" in your opinion. The problem is that they're
interfering unjustifiably with the work of their colleagues. Addressing
that problem "sets the tone" much better than expressing, let alone
mandating, your own preferences. It's what _I_ expect of a manager, at
any rate.
What we didn't have is editor arguments
clogging up our thinking.
Done well--and this might happen only in a minority of cases--editor
arguments can _enhance_ people's thinking; see "playful practice" above.
And even if they don't, if they're no more destructive than a dispute
over whether the coach of the local sportsball team was an idiot for
benching player X in the Big Game last weekend, or than knocking off 30
minutes early for beers together at the end of a frustrating day, then
good leadership can mean leaving some rough spots unsanded.
Regards,
Branden
[1] _Programmers_ might so do, with vi "modelines" or Emacs "local
variables" in text constitutive of a comment in the program source
code. Different matter.
[2] another instance of our old friend the "streetlight effect"
https://en.wikipedia.org/wiki/Streetlight_effect
[3] https://en.wikipedia.org/wiki/Recency_bias
[4] or automated test construction, or documentation revision--wait, why
is everybody laughing?
[5] https://xkcd.com/356/
21 Jul
21 Jul
1:20 a.m.
New subject: how (not) to manage engineers (was: End of an era: the last ATC (USENIX Annual Technical Conference))
As I said to Warren, that is partially on me. I have a bad habit of letting
myself get drawn into discussions where I should just let it go.
I apologize for the noise, added Brandon to my procmailrc so I'll not see
his emails. Not sure what I did to draw his ire but I'll not feed the
fire in the future.
For the record, I was shaken up about this exchange as well, came pretty
close to unsubscribing so I wouldn't cause problems down the line.
I'm retired, I love going down memory lane as much as the next guy, but
having a fight? At my age? Please, no.
On Sun, Jul 20, 2025 at 05:40:12PM -0600, Marc Rochkind wrote:
Maybe Doug's comment was too succinct.
This back-and-forth personal argument, laced with insults and disrespect,
seems wildly inappropriate for TUHS.
Marc Rochkind
On Sun, Jul 20, 2025 at 4:22???PM G. Branden Robinson <
g.branden.robinson(a)gmail.com> wrote:
--
---
Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
Hi Larry,
At 2025-07-20T04:38:02-0700, Larry McVoy wrote:
--
Subscribe to my Photo-of-the-Week emails at my website mrochkind.com. On Sun, Jul 20, 2025 at 02:59:08AM -0500, G.
Branden Robinson wrote:
Indeed not. :)
At 2025-07-19T20:16:33-0500, Will Senn wrote:
> I've thought about the "if you worked for me", dig and it kind of
> stung.
Manure often does.
Larry came up in the soil from which grew tech bro culture.
A preoccupation with managing the preferences of others, as with
Steve Jobs's "thought leadership", is consistent with the
authoritarian style he advocates.
Huh, you won't be surprised I have a different perspective. Allow me to tell you how I describe managing
engineers. Suppose we
were artists, there were 4 of us. Someone brought us a photograph and
said "I want a painting of that". OK, split it into quarters and go
do it. What do we get back?
Well, artist #1 likes oil paints so that's what s/he did. Artist #2
likes charcoal so that's what they did. Artist #3 likes pen and ink.
Artist #4 likes water color.
Is that a painting? Maybe if you like a mish mash of stuff that
doesn't go together. Most people would call it garbage and refuse to
pay.
Yeah. I think your analogy is facile and superficial and therefore
characteristic of of Silicon Valley executive culture. Here's why.
First, text editors don't leave traces of themselves in the work
product.[1]
Second, _especially_ in a leadership position (although this is more
specifically the role of "architect" if someone has it), you have to be
conscious of the boundaries of your software modules.
A software project of sufficient complexity to be worth commissioning on
a professional basis is, despite its contractual representation at the
executive level, not a unitary object like an individual painting or
photograph or 2??-minute folk song. Such things are not (formally)
complex, but "elemental": if you decompose them, they stop being what
they are.
Often, a first-order decomposition of a software system leaves you
with...a collection of other software systems, plus, ideally, some
ancillary documentation and/or an integration test suite.
My so called "authoritarian style" is
nothing more than I was the
leader, I had to pick one style.
Right. To hear you tell it, you preoccupied yourself with matters of
style and let others worry about the harder problems of architecture and
interfacing. Maybe that was the right choice given your skill set and
those of your staff.
If that characterization cuts, there is a remedy: share a leadership
anecdote where you made (or mediated) a hard decision on a non-stylistic
matter. Maybe two algorithms of the same order in big-O notation were
pitched for a certain software module, but one was preferable on some
non-obvious basis. You've spoken before of the high value of SCCS's
"weave" to BitKeeper. Was there anything the weave made hard or was bad
at? Were you ever on the verge of reconsidering it? If so, what, on an
_engineering_ basis rather than one of style or personal admiration,
mandated its retention?
If you have stories like that, those would, to me, constitute examples
of technical leadership. And, if all "stakeholders" (your client[s]
_and_ your staff) were happy with the outcome, then they could be
examples of _good_ technical leadership, too.
And, yes, it means if you have N people working
you usually have N-1
pissed off people because they weren't getting to do things their way.
I suspect you accurately perceived the presence of frustration. I also
bet you assumed its cause rather than undertaking an earnest exploration
thereof. A confounding factor here is that a project can have so many
problems that the individual contributors themselves have trouble
accurately identifying an "overall" problem or a single "worst" one
that
they have. Further, if they are experiencing deadline pressure, whether
imposed by themselves or by leadership and are asked to identify
"blockers", they're likely to name the obstacles that are easiest to
articulate[2] or that they most recently struggled with.[3] One
generally can't calendar the removal of as-yet-unarticulated problems.
If the engineers have the same blocker day after day, then management is
failing to remove them. If the engineers have NEW blockers every day or
every week, and you have confidence in your recruitment/hiring, then
the staff is not sandbagging you--the project has deep problems.
My personal experience is that underspecification and otherwise
unarticulated expectations are the root causes of nearly every problem
that cause anguish among staff. And behind that problem is the worse
one that managers climb into contractual beds with their counterparties
without having done their necessary homework first. The client never
wants to admit that they haven't really though through what it is
they're asking for. They've already made promises to a director, VP, or
someone in the C suite. So they yell at you and you yell at your staff.
The manure, as it were, rolls downhill.
Letting them do things their way means there is
no overall picture you
are driving towards.
In engineering, we do not implement an "overall picture", but to a
detailed specification.
If you lack a detailed specification to implement, what you are doing is
not (solely) engineering. That's not necessarily a bad thing; you are
engaged in design and possibly in research. Charge more. Develop your
staff by helping them get conference papers out of the work.
And I'm not above being overridden. I
personally hate GNU make for
all the similar reasons you are advocating for a smaller vi.
That wasn't me, but I'll freely admit that Vim has many features I don't
use. I have found that time spent seeking mastery of one tool is good
practice in judging the "right-sizing" of another. If nothing else, it
helps one learn which hills aren't worth dying on. ;-)
Regarding make(1), POSIX 2024 has made it _much_ better. I still think
the BSDs' snarling adherence to old-style suffix rules, which are
inflexible and ambiguous, and restrictions on $< are counterproductive,
but a lot of stuff that used to not be portable, is portable now.
But my team convinced me it was less work to move
to that than
maintain all the scripts we were using to use a simple make.
But yeah, when people work for me, I lead. I set the tone. It wasn't
tech bro nonsense, it was about herding people towards the same
picture.
I have a slender hope that I can persuade you that these things are
actually the same in every way that matters. As implied above, this
doesn't make you a tech bro yourself, necessarily, it might mean you're
emphasizing the wrong elements of your experience for an audience of
salty old engineers, contrast with venture capitalists.
In martial arts training, there are "degrees" of black belt. Only the
first few degrees have anything to do with one's own ability or
perfection of form. After that, your advancement is determined by how
many black belts you _train_. To become a master, you must train many
black belts. To become a grand master, you must train many masters.
While I'm sure there are perverse incentives in martial arts instruction
(hello, capitalism), this approach of making your own advancement beyond
a certain point dependent on the development of people no longer
accountable to you strikes me as a worthwhile corrective to the
narcissistic orientation of leadership in software development.
Being a good example is a different phenomenon than being an object of
emulation. One phenomenon is deep, the other shallow. Steve Jobs was
good at producing a lot of fawning emulators with black turtlenecks and
glib proclamations about the future of technology. Steve Wozniak has in
substantial measure dedicated himself to producing more good engineers.
I wasn't trying to tell Will he can't
use whatever editor he wants, I
was trying to tell Will I wouldn't tolerate this much back and forth
about his personal preferences distracting us from shipping product.
That's not how I read what you said, but fine. I agree that bickering
over tool choice can be a distraction from satisfying the contract and
getting the final payment. But the sword of opportunity cost cuts both
ways. You can't always be sure that the most readily available
substitute good for an editor argument is a laser-focused coding
session[4] on implementing an element of a deliverable.
If your engineers are motivated, you will find that they don't distract
themselves with nonsense _when they have a better alternative_. A good
engineering manager deeply understands the XKCD concept of "nerd
sniping" and knows how to adapt it to the benefit of the individual
contributor, their team, the client, and consequently themselves.[5]
My team had emacs people and vi people, nobody
cared so long as you
got your job done.
That's a salutary attitude. But engineers also need time and vehicles
for decompression, and one of the things they can use their downtime for
is playful practice at evaluating tradeoffs between competing designs or
systems.
If you have an engineer who's going around harassing their peers for
choosing the "wrong" editor, the problem is not their choice of editor,
which might be "correct" in your opinion. The problem is that they're
interfering unjustifiably with the work of their colleagues. Addressing
that problem "sets the tone" much better than expressing, let alone
mandating, your own preferences. It's what _I_ expect of a manager, at
any rate.
What we didn't have is editor arguments
clogging up our thinking.
Done well--and this might happen only in a minority of cases--editor
arguments can _enhance_ people's thinking; see "playful practice" above.
And even if they don't, if they're no more destructive than a dispute
over whether the coach of the local sportsball team was an idiot for
benching player X in the Big Game last weekend, or than knocking off 30
minutes early for beers together at the end of a frustrating day, then
good leadership can mean leaving some rough spots unsanded.
Regards,
Branden
[1] _Programmers_ might so do, with vi "modelines" or Emacs "local
variables" in text constitutive of a comment in the program source
code. Different matter.
[2] another instance of our old friend the "streetlight effect"
https://en.wikipedia.org/wiki/Streetlight_effect
[3] https://en.wikipedia.org/wiki/Recency_bias
[4] or automated test construction, or documentation revision--wait, why
is everybody laughing?
[5] https://xkcd.com/356/
20 Jul
20 Jul
12:25 p.m.
New subject: Editors (was: Re: End of an era: the last ATC (USENIX Annual Technical Conference))
I’ll throw in that Lugaru Software (which as been around forever) still maintains their
venerable Epsilon editor - which is a great product - and although it is roughly
considered to be an “Emacs” by key bindings and default behaviors, underneath it’s all in
the ELL language instead of Lisp. And EEL is essentially C.
If you prefer C to Lisp (oh, the cries and gnashing of teeth!) like many people do, it’s a
very interesting product.
--
Jeffrey H. Johnson
trnsz(a)pobox.com
On Sun, Jul 20, 2025, at 3:59 AM, G. Branden Robinson wrote:
On the milder topic of editor preferences, I'm a vi(m) user but employ
Emacs bindings in readline applications and maintained my own fork of mg
(microemacs) for a while, to see how the other half lived. I discovered
that a much bigger chunk of Emacs advocacy is predicated on its
"finger-feel"[1] and some other built-in features than upon Lisp
scriptability.
21 Jul
21 Jul
2:12 p.m.
On 7/20/25 3:59 AM, G. Branden Robinson wrote:
On the milder topic of editor preferences, I'm a
vi(m) user but employ
Emacs bindings in readline applications and maintained my own fork of mg
(microemacs) for a while, to see how the other half lived. I discovered
that a much bigger chunk of Emacs advocacy is predicated on its
"finger-feel"[1]
I think, as I said in another message, that familiarity has a lot to do
with the comfort that people feel. Muscle memory is important.
I would also note that emacs-style key bindings are pervasive -- even on
macOS, where the system's text objects (e.g., what you use in TextEdit)
all have emacs-style key bindings by default, down to things like the
browsers' address bar and search field. Even the Spotlight search bar
uses emacs key bindings. This was all inherited from NeXTOS.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/
26 Jul
26 Jul
3:34 a.m.
Muscle memory is 100% of why I continue to edit in ex.
On Mon, Jul 21, 2025, 10:12 AM Chet Ramey via TUHS <tuhs(a)tuhs.org> wrote:
On 7/20/25 3:59 AM, G. Branden Robinson wrote:
On the milder topic of editor preferences,
I'm a vi(m) user but employ
Emacs bindings in readline applications and maintained my own fork of mg
(microemacs) for a while, to see how the other half lived. I discovered
that a much bigger chunk of Emacs advocacy is predicated on its
"finger-feel"[1]
I think, as I said in another message, that familiarity has a lot to do
with the comfort that people feel. Muscle memory is important.
I would also note that emacs-style key bindings are pervasive -- even on
macOS, where the system's text objects (e.g., what you use in TextEdit)
all have emacs-style key bindings by default, down to things like the
browsers' address bar and search field. Even the Spotlight search bar
uses emacs key bindings. This was all inherited from NeXTOS.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/
10:20 a.m.
If I can just get . into my muscle memory bank, then I'd stop having...
w
q
...at the end of most of my documents!
Have a great weekend, everyone!
18 Jul
18 Jul
8:58 p.m.
On Jul 18, 2025, at 3:09 AM, Larry McVoy <lm(a)mcvoy.com> wrote:
In vim, you just have a split view of the same file.
Changes in
either window will show up in the other window. For example
vim foo.c # foo.c exists and has a 100 lines
:sp
In nvi
:E
now you have both windows looking at the same file
Ditto
start changing something and it is done in both
windows.
In nvi changes don't show up right away in the other window
but show up once you switch to it. So not as good as vim but
in practice it doesn't matter much since usually you show
*different* parts in two windows pointing at the same file.
Screen is nowhere near that and using it to claim that
nvi is fine
is missing the point by a country mile.
And I don't understand the dislike of vim.
It is more that some of us *prefer* nvi to vim. [I might've used
vim when it was first posted on Usenet but Braam refused to make
at least provide an option to make multiple undo/redo behavior
compatible to nvi. So it goes!]
I don't care what tools my team members use as long as they are
pulling their weight. Usually the best programmers already have
a set of tools they are comfortable with. I wouldn't want to mess
with that. [I have worked in teams where people were using nvi,
vim, acme, sam, emacs, ee, IDEs etc.]
9:32 p.m.
On Fri, Jul 18, 2025 at 01:58:12PM -0700, Bakul Shah wrote:
On Jul 18, 2025, at 3:09???AM, Larry McVoy
<lm(a)mcvoy.com> wrote:
Hmm, when I tried nvi I don't think it had :E or I missed it. I read
release notes so it's strange I didn't catch it. Or maybe it was added
later because Keith was pretty focussed on 100% vi compat and I never
saw :E in vi either.
Whatever, you are happy with nvi, I'm happy with vim, so be it. Though
I'm teaching my kid vim because I strongly suspect vim is much more
widely used. This is starting to feel like a BSD vs Linux argument and
we know how that turned out.
In vim, you just have a split view of the same
file. Changes in
either window will show up in the other window. For example
vim foo.c # foo.c exists and has a 100 lines
:sp
In nvi
:E
now you have both windows looking at the same
file
Ditto
start changing something and it is done in both
windows.
In nvi changes don't show up right away in the other window
but show up once you switch to it. So not as good as vim but
in practice it doesn't matter much since usually you show
*different* parts in two windows pointing at the same file.
10:39 p.m.
On Jul 18, 2025, at 2:32 PM, Larry McVoy <lm(a)mcvoy.com> wrote:
Hmm, when I tried nvi I don't think it had :E or I missed it. I read
release notes so it's strange I didn't catch it. Or maybe it was added
later because Keith was pretty focussed on 100% vi compat and I never
saw :E in vi either.
vi didn't have this feature (or multiple undo/redo). Looking at
nvi logs, split windows were added on April 5, 1993 by Bostic.
[Doesn't seem that long ago :-(]
10:53 p.m.
Yes, the editors can be very much a religious thing. There are actually
three major actively maintained versions of nvi in current use:
- Nvi1 - https://repo.or.cz/nvi.git
- Nvi2 - https://github.com/lichray/nvi2
- OpenVi - https://github.com/johnsonjh/OpenVi
Not directly related to Nvi, but Elvis (https://github.com/mbert/elvis)
and Xvi (https://github.com/martinwguy/xvi) are also still maintained
and have die-hard users.
I actually know of several people who use Andy Valencia's Vim fork known
as "Vim57" (https://sources.vsta.org:7100/vim57/tree) which forked from,
you guessed it, Vim 5.7. His fork consists of simplifying the code and
mostly removing things, for those that like Vim but prefer speed and
minimalism.
I use OpenVi quite a bit, and if you took away everything else from
me, I'd be able to get along just fine, but I'm certainly a Vim user,
and I spend most of my day driving NeoVim now.
Teach your kid Vim! You can't go wrong knowing Vim, and that knowledge
makes it easy drive the other editors in the Vi family (Vile, etc.) if
he wants to.
--
Jeffrey H. Johnson
trnsz(a)pobox.com
Though I'm teaching my kid vim because I strongly
suspect vim is much
more widely used. This is starting to feel like a BSD vs Linux argument
and we know how that turned out.
10:57 p.m.
Actually, Xvi is now maintained at https://codeberg.org/martinwguy/xvi.
I'll bow out of the editor discussion now, since I think we're pretty
far from the original topic.
--
Jeffrey H. Johnson
trnsz(a)pobox.com
11:46 p.m.
New subject: xvi
On Fri, Jul 18, 2025 at 06:57:03PM -0400, Jeff Johnson wrote:
Actually, Xvi is now maintained at
https://codeberg.org/martinwguy/xvi.
I'll bow out of the editor discussion now, since I think we're pretty
far from the original topic.
I can pull it back to something potentially useful. As I mentioned, years
and years ago, on small memory machines, I used to vi $BIG_ASS_LOGFILE
and because editors tend to malloc each line, the vi session got really
slow (started swapping) when the file was bigger than roughly 1/2 of mem.
My changes were to teach the string library, and whatever else operated
on a line of the file, to treat \n the same way you would treat \0.
Then you change the code that read in the file to just mmap() it.
I don't think I went so far as to make changes to the file work, not
sure, it may have just worked but I was looking at log files, I don't
think I modified them.
I'm pretty sure the answer is no, the laptop I'm typing on has 64GB and
I suspect everyone else is the same. But can anyone imagine a use case
where having a vi that could read really large files (and quickly, no
parsing/mallocing each line) would be useful?
I'm pretty done with programming but if someone said "here is an important
use case where that would help" I'd go find those changes and see if I can
port them forward.
--
---
Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
19 Jul
19 Jul
4:39 a.m.
New subject: xvi
I was involved in some work about five years ago where I had to keep a
small number of files (about 5) open all the time for examination as
needed. Each was 100-500 GB.
I opened them all in vim instances running in the background at login time,
and then I read email until they were all loaded. I then put the process
with the file I needed into the foreground, examined it, and returned to
the shell with :stop (which all command line editors should have) when I
was done. Worked like a charm.
On Fri, Jul 18, 2025, 7:46 PM Larry McVoy <lm(a)mcvoy.com> wrote:
On Fri, Jul 18, 2025 at 06:57:03PM -0400, Jeff Johnson
wrote:
Actually, Xvi is now maintained at
https://codeberg.org/martinwguy/xvi.
I'll bow out of the editor discussion now, since I think we're pretty
far from the original topic.
I can pull it back to something potentially useful. As I mentioned, years
and years ago, on small memory machines, I used to vi $BIG_ASS_LOGFILE
and because editors tend to malloc each line, the vi session got really
slow (started swapping) when the file was bigger than roughly 1/2 of mem.
My changes were to teach the string library, and whatever else operated
on a line of the file, to treat \n the same way you would treat \0.
Then you change the code that read in the file to just mmap() it.
I don't think I went so far as to make changes to the file work, not
sure, it may have just worked but I was looking at log files, I don't
think I modified them.
I'm pretty sure the answer is no, the laptop I'm typing on has 64GB and
I suspect everyone else is the same. But can anyone imagine a use case
where having a vi that could read really large files (and quickly, no
parsing/mallocing each line) would be useful?
I'm pretty done with programming but if someone said "here is an important
use case where that would help" I'd go find those changes and see if I can
port them forward.
--
---
Larry McVoy Retired to fishing
http://www.mcvoy.com/lm/boat
18 Jul
18 Jul
11:45 p.m.
On Jul 18, 2025, at 22:58, Bakul Shah via TUHS
<tuhs(a)tuhs.org> wrote:
Agreed! nvi `u` undo/redo with the `.` repeat cmd is what nvi got very right and vim got
wrong by comparison IMO. That feature alone had me preferring nvi forever (they both
supported split windows :)
I eventually gave up and just started using vim though b/c it was installed by default on
Linux systems, which is what the vast majority of customers/companies want to use now.
Thanks,
Chris.
P.S. Actually I had a soft spot in my heart for vim even when I preferred nvi b/c there
was a native Amiga OS version, but that’s a topic for some other mailing list. :)
And I don't understand the dislike of vim.
It is more that some of us *prefer* nvi to vim. [I might've used
vim when it was first posted on Usenet but Braam refused to make
at least provide an option to make multiple undo/redo behavior
compatible to nvi. So it goes!]
11:59 p.m.
On Sat, Jul 19, 2025 at 01:45:24AM +0200, Christian Hopps wrote:
Huh, I had to go play with how vim does it. vim, you hold down "u" to undo
everything you've done (screen flashes when there is nothing left to undo)
and you can go forward with ^R to replay your changes if you went too far.
I sort of get "." to repeat the undo but does nvi have a way to redo the
changes you originally did? I've used that to try and track down what
change I did that caused things to break, being able to go back and forth
is useful in a long debugging session.
Another thing I like about vim is when you put stuff in a buffer, I don't
know how it does this, but it remembers what you stored in a buffer across
vim sessions. I have a giant .procmailrc where I filter every sales
droid or whatever that spams me. I have yanked into a buffer an entry
that I put back and change with the latest, I like that obscure feature.
On Jul 18, 2025, at 22:58, Bakul Shah via TUHS
<tuhs(a)tuhs.org> wrote:
Agreed! nvi `u` undo/redo with the `.` repeat cmd is what nvi got very right and vim got
wrong by comparison IMO. That feature alone had me preferring nvi forever (they both
supported split windows :) And I don't understand the dislike of vim.
It is more that some of us *prefer* nvi to vim. [I might've used
vim when it was first posted on Usenet but Braam refused to make
at least provide an option to make multiple undo/redo behavior
compatible to nvi. So it goes!]
19 Jul
19 Jul
1:05 a.m.
On Jul 18, 2025, at 4:59 PM, Larry McVoy <lm(a)mcvoy.com> wrote:
I sort of get "." to repeat the undo but does nvi have a way to redo the
changes you originally did? I've used that to try and track down what
change I did that caused things to break, being able to go back and forth
is useful in a long debugging session.
Let us say you want do undo last 4 changes. You type u...
Now you want to redo 3 of them. You type u..
Basically the second u undoes the undo, and . means repeat!
IIRC, in vi you could only undo one change. To redo you
use u again. vim broke that. nvi extended it compatibly.
[This may be a Europe/USA thing. In US a "toggle" button
seems quite acceptable but perhaps the EU bought into "human
factors design" which says to *not* use the same control for
/opposite/ functions as it can likely increase confusion.
Note: I may be completely wrong here but this was my guess!]
1:13 a.m.
On Fri, Jul 18, 2025 at 06:05:37PM -0700, Bakul Shah wrote:
On Jul 18, 2025, at 4:59???PM, Larry McVoy
<lm(a)mcvoy.com> wrote:
Hmm, I might be dense but I like vims way of "u" means undo, ^R means
put it back. I do like nvi's u...., I like the . but having "u" mean
undo and redo seems weird.
You say tomato I say tomato :)
--
---
Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
I sort of get "." to repeat the undo but does nvi have a way to redo the
changes you originally did? I've used that to try and track down what
change I did that caused things to break, being able to go back and forth
is useful in a long debugging session.
Let us say you want do undo last 4 changes. You type u...
Now you want to redo 3 of them. You type u..
Basically the second u undoes the undo, and . means repeat!
1:40 a.m.
On Friday, July 18th, 2025 at 6:13 PM, Larry McVoy <lm(a)mcvoy.com> wrote:
On Fri, Jul 18, 2025 at 06:05:37PM -0700, Bakul Shah
wrote:
This undo behavior is one of the things that catches me off guard when I wind up in vim
instead of nvi. Not to say which is better or worse I'm just wired for the nvi
approach so when I hit 'u' again and it does another undo instead of undoing the
undo, it throws me for a second.
- Matt G.
On Jul 18, 2025, at 4:59???PM, Larry McVoy
lm(a)mcvoy.com wrote:
Hmm, I might be dense but I like vims way of "u" means undo, ^R means
put it back. I do like nvi's u...., I like the . but having "u" mean
undo and redo seems weird.
You say tomato I say tomato :)
--
---
Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat I sort of get "." to repeat the undo
but does nvi have a way to redo the
changes you originally did? I've used that to try and track down what
change I did that caused things to break, being able to go back and forth
is useful in a long debugging session.
Let us say you want do undo last 4 changes. You type u...
Now you want to redo 3 of them. You type u..
Basically the second u undoes the undo, and . means repeat!
18 Jul
18 Jul
5:04 a.m.
But that is far less useful than having two windows into the same
file where the mods to each window go to the same file. Think
looking at code that has the structs at the top of the file and you
need to wack a struck and wack the code that uses that struct.
Quite pleasant.
You will find that this is exactly what 'Zerox' in acme does.
5:44 a.m.
Sam had it, acme took it (and much else) from Sam.
-rob
On Fri, Jul 18, 2025 at 3:22 PM Noel Hunt <noel.hunt(a)gmail.com> wrote:
But that is far less useful than having two windows
into the same
file where the mods to each window go to the same
file. Think
looking at code that has the structs at the top of the file and you
need to wack a struck and wack the code that uses that struct.
Quite pleasant.
You will find that this is exactly what 'Zerox' in acme does.
7
days inactive
23
days old
74 comments
27 participants
participants (27)
-
arnold＠skeeve.com -
Bakul Shah -
Brantley Coile -
Cameron Míċeál Tyre -
Charles H Sauer (he/him) -
Chet Ramey -
Christian Hopps -
Clem Cole -
Dan Cross -
Douglas McIlroy -
G. Branden Robinson -
George Michaelson -
James Cloos -
Jeff Johnson -
Johan Helsingius -
John Cowan -
Larry McVoy -
Luther Johnson -
Marc Rochkind -
Noel Hunt -
r.stricklin -
Rich Salz -
Rob Pike -
segaloco -
Steffen Nurpmeso -
Warren Toomey -
Will Senn