[TUHS] Re: End of an era: the last ATC (USENIX Annual Technical Conference)

[TUHS] Re: End of an era: the last ATC (USENIX Annual Technical Conference)

[Johan Helsingius via TUHS]

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

[TUHS] Re: End of an era: the last ATC (USENIX Annual Technical Conference)

[Luther Johnson]

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

[TUHS] Re: End of an era: the last ATC (USENIX Annual Technical Conference)

[Cameron Míċeál Tyre via TUHS]

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@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.
>  

[TUHS] Re: End of an era: the last ATC (USENIX Annual Technical Conference)

[arnold]

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@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@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.
> >  
>

[TUHS] Re: End of an era: the last ATC (USENIX Annual Technical Conference)

[Larry McVoy]

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 \x17
map! \x01 \x14
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@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@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

[TUHS] Re: End of an era: the last ATC (USENIX Annual Technical Conference)

[Bakul Shah via TUHS]

On Jul 17, 2025, at 7:52 PM, segaloco via TUHS <tuhs@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@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.

[TUHS] Re: End of an era: the last ATC (USENIX Annual Technical Conference)

[Noel Hunt]

[-- Attachment #1: Type: text/plain, Size: 352 bytes --]

>
> 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.

[-- Attachment #2: Type: text/html, Size: 664 bytes --]

[TUHS] Re: End of an era: the last ATC (USENIX Annual Technical Conference)

[Rob Pike]

[-- Attachment #1: Type: text/plain, Size: 509 bytes --]

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@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.
>

[-- Attachment #2: Type: text/html, Size: 1361 bytes --]

[TUHS] Re: End of an era: the last ATC (USENIX Annual Technical Conference)

[Larry McVoy]

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@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@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

[TUHS] Re: End of an era: the last ATC (USENIX Annual Technical Conference)

[Bakul Shah via TUHS]

On Jul 18, 2025, at 3:09 AM, Larry McVoy <lm@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.]

[TUHS] Re: End of an era: the last ATC (USENIX Annual Technical Conference)

[Larry McVoy]

On Fri, Jul 18, 2025 at 01:58:12PM -0700, Bakul Shah wrote:
> On Jul 18, 2025, at 3:09???AM, Larry McVoy <lm@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.

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.

[TUHS] Re: End of an era: the last ATC (USENIX Annual Technical Conference)

[Bakul Shah via TUHS]

On Jul 18, 2025, at 2:32 PM, Larry McVoy <lm@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 :-(]

[TUHS] Re: End of an era: the last ATC (USENIX Annual Technical Conference)

[Jeff Johnson]

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@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.

[TUHS] Re: End of an era: the last ATC (USENIX Annual Technical Conference)

[Bakul Shah via TUHS]

On Jul 18, 2025, at 4:59 PM, Larry McVoy <lm@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!]

[TUHS] Re: xvi

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 2031 bytes --]

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@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
>

[-- Attachment #2: Type: text/html, Size: 2702 bytes --]

[TUHS] Re: End of an era: the last ATC (USENIX Annual Technical Conference)

[James Cloos]

>>>>> "rs" == r stricklin <bear@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@jhcloos.com>
            OpenPGP: https://jhcloos.com/0x997A9F17ED7DAEA6.asc

[TUHS] Re: End of an era: the last ATC (USENIX Annual Technical Conference)

[Steffen Nurpmeso]

James Cloos wrote in
 <m3o6tgs1rw.fsf@lugabout.jhcloos.org>:
 |>>>>> "rs" == r stricklin <bear@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

[TUHS] Re: End of an era: the last ATC (USENIX Annual Technical Conference)

[Steffen Nurpmeso]

Jeff Johnson wrote in
 <393d865b-00db-4064-a84a-3adca8d9554f@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

[TUHS] Re: End of an era: the last ATC (USENIX Annual Technical Conference)

[Steffen Nurpmeso]

Jeff Johnson wrote in
 <4d7ab3f8-8c3e-4589-a6f1-5108fac2507a@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@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

[TUHS] Re: End of an era: the last ATC (USENIX Annual Technical Conference)

[Larry McVoy]

On Sun, Jul 20, 2025 at 02:59:08AM -0500, G. Branden Robinson wrote:
> 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.

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.

[TUHS] Re: how (not) to manage engineers (was: End of an era: the last ATC (USENIX Annual Technical Conference))

[Larry McVoy]

On Sun, Jul 20, 2025 at 08:47:54AM -0500, G. Branden Robinson wrote:
> > 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.

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.  

[TUHS] Re: how (not) to manage engineers (was: End of an era: the last ATC (USENIX Annual Technical Conference))

[Marc Rochkind]

[-- Attachment #1: Type: text/plain, Size: 11598 bytes --]

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@gmail.com> wrote:

> 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:
> > > 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.
>
> Indeed not.  :)
>
> > 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/
>


-- 
Subscribe to my Photo-of-the-Week emails at my website mrochkind.com.

[-- Attachment #2: Type: text/html, Size: 13520 bytes --]

[TUHS] Re: End of an era: the last ATC (USENIX Annual Technical Conference)

[Cameron Míċeál Tyre via TUHS]

[-- Attachment #1: Type: text/plain, Size: 147 bytes --]

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!

[-- Attachment #2: Type: text/html, Size: 214 bytes --]

[TUHS] Re: End of an era: the last ATC (USENIX Annual Technical Conference)

[Norman Wilson]

Cameron_M????e??l_Tyre_via_TUHS:

  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.

==

Of course.  ed(1) is the standard editor.

Norman Wilson
Toronto ON