From clemc at ccc.com Wed Jan 1 02:40:14 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 31 Dec 2019 11:40:14 -0500 Subject: [TUHS] pic anomalies In-Reply-To: <201912310424.xBV4O2Cr016640@tahoe.cs.Dartmouth.EDU> References: <201912310424.xBV4O2Cr016640@tahoe.cs.Dartmouth.EDU> Message-ID: On Mon, Dec 30, 2019 at 11:24 PM Doug McIlroy wrote: > The use of %% to designate a literal % in printf is not > a recent convention. It was defined in K&R, first edition. > FWIW, I still have an old (fading) copy of the galley proofs for the first edition. Page 147 (*Chapter 7 - Input and Output, Section 7.3 Formatted Output - Printf*) first full paragraph on the page: If the character after the % is not a conversion character, that character is printed: thus % may be printed by %%. > > Doug > > Ralph Cordery wrote: > > Though that may seem odd to our modern C-standardised eyes, it's > understandable in that if it isn't a valid %f, etc., format specifier > then it's a literal percent sign. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Fri Jan 3 07:38:00 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Thu, 02 Jan 2020 16:38:00 -0500 Subject: [TUHS] GNUism in groff tests, was: pic anomalies Message-ID: <202001022138.002Lc0Up132858@tahoe.cs.Dartmouth.EDU> I have always marveled at folks who can maintain multiple versions of software, but Larry's dispatch from the trenches reveals hurdles I hadn't imagined. Kudos for keeping groff alive. Speaking of which, many thanks to all who pitched in on the %% nit that I reported. The instant response compares rather favorably to an open case I've been following in gcc, which was originally filed in 2002. Doug From meillo at marmaro.de Fri Jan 3 22:45:53 2020 From: meillo at marmaro.de (markus schnalke) Date: Fri, 03 Jan 2020 13:45:53 +0100 Subject: [TUHS] sh: cmd | >file Message-ID: <1inMKv-0Km-00@marmaro.de> Hoi, in a computer forum I came across a very long command line, including `xargs' and `sh -c'. Anyways, throughout the thread it was modified several times, when accidently a pipe symbol appeared between the command and the output redirection. The command line did nothing; it ran successful. I was confused, because I expected to see a syntax error in case of ``cmd|>file''. This made me wonder ... With help of Sven Mascheck, I was able to clear my understanding. The POSIX shell grammer provided the answer: pipeline : pipe_sequence ... pipe_sequence : command | pipe_sequence '|' linebreak command ; command : simple_command ... simple_command : cmd_prefix cmd_word cmd_suffix | cmd_prefix cmd_word | cmd_prefix <--- HIER! | cmd_name cmd_suffix | cmd_name ; cmd_prefix : io_redirect ... io_redirect : io_file ... io_file : '<' filename | LESSAND filename | '>' filename ... A redirection is a (full) simple_command ... and because ``simple_command | simple_command'' is allowed, so is ``io_file | io_file''. This can lead to such strange (but valid) command lines like: b >b | : Here some further fun variants: :|:>: <:|:>: They would provide nice puzzles. ;-) My understanding was helped most by detaching from the semantics and focussing on syntax. This one is obviously valid, no matter it has no effect: :|:|: From there it was easier to grasp: >a | >a | >a Which is valid, because ``>a'' is a (complete) simple_command. Thus, no bug but consistent grammer. ;-) If one would have liked to forbid such a corner case, additional special case handling would have been necessary ... which is in contrast to the Unix way. Sven checked the syntax against various shells with these results: - Syntax ok in these shells: SVR2 sh (Ultrix), SVR4 sh (Heirloom) ksh93 bash-1.05, bash-aktuell pdksh-5.2.14 ash-0.4.26, dash-0.5.6.1 posh-0.3.7, posh-0.12.3 mksh-R24, mksh-R52b yash-2.29 zsh-3.0.8, zsh-4.3.17 - Exception to the rule: 7thEd sh:     # pwd|>>file     # echo $?     141 On first sight ok, but with a silent error ... SIGPIPE (128+13). I'd be interested in any stories and information around this topic. What about 7thEd sh? meillo From steffen at sdaoden.eu Fri Jan 3 23:57:15 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 03 Jan 2020 14:57:15 +0100 Subject: [TUHS] GNUism in groff tests, was: pic anomalies In-Reply-To: <202001022138.002Lc0Up132858@tahoe.cs.Dartmouth.EDU> References: <202001022138.002Lc0Up132858@tahoe.cs.Dartmouth.EDU> Message-ID: <20200103135715.S1lyA%steffen@sdaoden.eu> Doug McIlroy wrote in <202001022138.002Lc0Up132858 at tahoe.cs.Dartmouth.EDU>: |I have always marveled at folks who can maintain multiple |versions of software, but Larry's dispatch from the |trenches reveals hurdles I hadn't imagined. Kudos for |keeping groff alive. I concur. And as everything in life is a wave, it all comes back as times go by. Some even agree to die younger than nature allows humans ("Er [Der Mensch] lebt wenn's hochkommt Hundert Jahr" [1]), because they have seen it all in the past, and are getting all too bored! [1] https://www.youtube.com/watch?v=1Ayethw-ouQ |Speaking of which, many thanks to all who pitched in |on the %% nit that I reported. The instant response |compares rather favorably to an open case I've been |following in gcc, which was originally filed in 2002. | |Doug --End of <202001022138.002Lc0Up132858 at tahoe.cs.Dartmouth.EDU> --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) From steffen at sdaoden.eu Sat Jan 4 00:00:55 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 03 Jan 2020 15:00:55 +0100 Subject: [TUHS] sh: cmd | >file In-Reply-To: <1inMKv-0Km-00@marmaro.de> References: <1inMKv-0Km-00@marmaro.de> Message-ID: <20200103140055.XB8iT%steffen@sdaoden.eu> markus schnalke wrote in <1inMKv-0Km-00 at marmaro.de>: |Hoi, Morsche. |in a computer forum I came across a very long command line, |including `xargs' and `sh -c'. Anyways, throughout the thread |it was modified several times, when accidently a pipe symbol |appeared between the command and the output redirection. The |command line did nothing; it ran successful. I was confused, |because I expected to see a syntax error in case of |``cmd|>file''. This made me wonder ... | | |With help of Sven Mascheck, I was able to clear my understanding. |The POSIX shell grammer provided the answer: ... |A redirection is a (full) simple_command ... and because |``simple_command | simple_command'' is allowed, so is |``io_file | io_file''. This can lead to such strange (but |valid) command lines like: | | b |>b | : | |Here some further fun variants: | |:|:>: | | <:|:>: | |They would provide nice puzzles. ;-) ... |- Syntax ok in these shells: | |SVR2 sh (Ultrix), SVR4 sh (Heirloom) Be aware of spurious :> errors in Heirloom shell, and maybe its origin (never had those). It is why the unit test of my little web site builder thing has been switched to "printf '' > FILE". |ksh93 |bash-1.05, bash-aktuell |pdksh-5.2.14 |ash-0.4.26, dash-0.5.6.1 |posh-0.3.7, posh-0.12.3 |mksh-R24, mksh-R52b |yash-2.29 |zsh-3.0.8, zsh-4.3.17 | |- Exception to the rule: | |7thEd sh: | |    # pwd|>>file |    # echo $? |    141 | |On first sight ok, but with a silent error ... SIGPIPE (128+13). | |I'd be interested in any stories and information around this |topic. | |What about 7thEd sh? Beware of bugs in the above code; I have only proved it correct, not tried it. |meillo --End of <1inMKv-0Km-00 at marmaro.de> --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) From brian at zick.io Sat Jan 4 03:03:07 2020 From: brian at zick.io (Brian Zick) Date: Fri, 03 Jan 2020 11:03:07 -0600 Subject: [TUHS] sh: cmd | >file In-Reply-To: <20200103140055.XB8iT%steffen@sdaoden.eu> References: <1inMKv-0Km-00@marmaro.de> <20200103140055.XB8iT%steffen@sdaoden.eu> Message-ID: <01d9e48c-2f92-48b9-b4ec-cd29fcfd1fa4@www.fastmail.com> I'm curious to know if you have a script you used to prove these correct? B On Fri, Jan 3, 2020, at 8:00 AM, Steffen Nurpmeso wrote: > markus schnalke wrote in <1inMKv-0Km-00 at marmaro.de>: > |Hoi, > > Morsche. > > |in a computer forum I came across a very long command line, > |including `xargs' and `sh -c'. Anyways, throughout the thread > |it was modified several times, when accidently a pipe symbol > |appeared between the command and the output redirection. The > |command line did nothing; it ran successful. I was confused, > |because I expected to see a syntax error in case of > |``cmd|>file''. This made me wonder ... > | > | > |With help of Sven Mascheck, I was able to clear my understanding. > |The POSIX shell grammer provided the answer: > ... > |A redirection is a (full) simple_command ... and because > |``simple_command | simple_command'' is allowed, so is > |``io_file | io_file''. This can lead to such strange (but > |valid) command lines like: > | > | b > |>b | | > |Sven liked this one: > | > |:|>: > | > |Here some further fun variants: > | > |:|:>: > | > | <:|:>: > | > |They would provide nice puzzles. ;-) > ... > |- Syntax ok in these shells: > | > |SVR2 sh (Ultrix), SVR4 sh (Heirloom) > > Be aware of spurious :> errors in Heirloom shell, and maybe its > origin (never had those). It is why the unit test of my little > web site builder thing has been switched to "printf '' > FILE". > > |ksh93 > |bash-1.05, bash-aktuell > |pdksh-5.2.14 > |ash-0.4.26, dash-0.5.6.1 > |posh-0.3.7, posh-0.12.3 > |mksh-R24, mksh-R52b > |yash-2.29 > |zsh-3.0.8, zsh-4.3.17 > | > |- Exception to the rule: > | > |7thEd sh: > | > |    # pwd|>>file > |    # echo $? > |    141 > | > |On first sight ok, but with a silent error ... SIGPIPE (128+13). > | > |I'd be interested in any stories and information around this > |topic. > | > |What about 7thEd sh? > > Beware of bugs in the above code; I have only proved it correct, > not tried it. > > |meillo > --End of <1inMKv-0Km-00 at marmaro.de> > > --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) > From meillo at marmaro.de Sat Jan 4 03:18:00 2020 From: meillo at marmaro.de (markus schnalke) Date: Fri, 03 Jan 2020 18:18:00 +0100 Subject: [TUHS] sh: cmd | >file In-Reply-To: <01d9e48c-2f92-48b9-b4ec-cd29fcfd1fa4@www.fastmail.com> References: <1inMKv-0Km-00@marmaro.de> <20200103140055.XB8iT%steffen@sdaoden.eu> <01d9e48c-2f92-48b9-b4ec-cd29fcfd1fa4@www.fastmail.com> Message-ID: <1inQaG-3N3-00@marmaro.de> Hoi. [2020-01-03 11:03] "Brian Zick" > > I'm curious to know if you have a script you used to prove these correct? We have to wait for Sven Mascheck to answer this question. He tested the different shells. meillo From meillo at marmaro.de Sat Jan 4 05:38:14 2020 From: meillo at marmaro.de (markus schnalke) Date: Fri, 03 Jan 2020 20:38:14 +0100 Subject: [TUHS] sh: cmd | >file In-Reply-To: <1inMKv-0Km-00@marmaro.de> References: <1inMKv-0Km-00@marmaro.de> Message-ID: <1inSly-4mJ-00@marmaro.de> Hoi. [2020-01-03 13:45] markus schnalke > > I'd be interested in any stories and information around this > topic. Especially I'd like to know since when and why ``>file'' is a full command? Was it clever design or by accident? meillo From imp at bsdimp.com Sat Jan 4 05:44:36 2020 From: imp at bsdimp.com (Warner Losh) Date: Fri, 3 Jan 2020 13:44:36 -0600 Subject: [TUHS] sh: cmd | >file In-Reply-To: <1inSly-4mJ-00@marmaro.de> References: <1inMKv-0Km-00@marmaro.de> <1inSly-4mJ-00@marmaro.de> Message-ID: On Fri, Jan 3, 2020, 1:39 PM markus schnalke wrote: > Hoi. > > [2020-01-03 13:45] markus schnalke > > > > I'd be interested in any stories and information around this > > topic. > > Especially I'd like to know since when and why ``>file'' is a > full command? Was it clever design or by accident? It's used to open files in shell scripts. Iirc, exec >foo 5>& and the like... Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mparson at bl.org Sat Jan 4 08:49:26 2020 From: mparson at bl.org (Michael Parson) Date: Fri, 03 Jan 2020 16:49:26 -0600 Subject: [TUHS] sh: cmd | >file In-Reply-To: References: <1inMKv-0Km-00@marmaro.de> <1inSly-4mJ-00@marmaro.de> Message-ID: On 2020-01-03 13:44, Warner Losh wrote: > On Fri, Jan 3, 2020, 1:39 PM markus schnalke wrote: > >> Hoi. >> >> [2020-01-03 13:45] markus schnalke >> > >> > I'd be interested in any stories and information around this >> > topic. >> >> Especially I'd like to know since when and why ``>file'' is a >> full command? Was it clever design or by accident? > > > It's used to open files in shell scripts. Iirc, exec >foo 5>& and the > like... I've also used it to truncate files: $ dd if=/dev/zero of=file count=10 10+0 records in 10+0 records out 5120 bytes (5.1 kB, 5.0 KiB) copied, 0.000686599 s, 7.5 MB/s $ ls -l file -rw-rw-r-- 1 mparson mparson 5120 Jan 3 16:45 file $ >file $ ls -l file -rw-rw-r-- 1 mparson mparson 0 Jan 3 16:46 file A more likely use case is to truncate a log file then HUP syslogd. -- Michael Parson Pflugerville, TX KF5LGQ From dave at horsfall.org Sat Jan 4 09:32:15 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 4 Jan 2020 10:32:15 +1100 (EST) Subject: [TUHS] sh: cmd | >file In-Reply-To: <1inSly-4mJ-00@marmaro.de> References: <1inMKv-0Km-00@marmaro.de> <1inSly-4mJ-00@marmaro.de> Message-ID: On Fri, 3 Jan 2020, markus schnalke wrote: > Especially I'd like to know since when and why ``>file'' is a full > command? Was it clever design or by accident? I/O redirection occurs before command execution (in this case, the null command). First, it creates (or truncates) the file, then runs the command; oh, it's the null command... -- Dave From mascheck at in-ulm.de Sat Jan 4 10:53:50 2020 From: mascheck at in-ulm.de (Sven Mascheck) Date: Sat, 4 Jan 2020 01:53:50 +0100 Subject: [TUHS] sh: cmd | >file In-Reply-To: <1inQaG-3N3-00@marmaro.de> References: <1inMKv-0Km-00@marmaro.de> <20200103140055.XB8iT%steffen@sdaoden.eu> <01d9e48c-2f92-48b9-b4ec-cd29fcfd1fa4@www.fastmail.com> <1inQaG-3N3-00@marmaro.de> Message-ID: <20200104005350.GA156384@lisa.in-ulm.de> On Fri, Jan 03, 2020 at 06:18:00PM +0100, markus schnalke wrote: > [2020-01-03 11:03] "Brian Zick" > > I'm curious to know if you have a script you used to prove these correct? > > We have to wait for Sven Mascheck to answer this question. He tested > the different shells. I guess Brian meant Steffen. I have no idea what Steffen meant with "proved correct". (and I believe Gunnar was not motivated to guarantee his heirloom port to compete in production environments against modern shell variants with continued maintenance, yet tried hard that time to find and fix as many bugs as possible; I tried to help him a little bit that time. Just consider how much still had been fixed by Sun even after their SVR4 sh. more corner case bugs to be expected...) BTW, I just typed ":|>file; echo $?" in a running shell and I was particularly interested in the early Bourne shell variants. Unfortunately, I was not able yet to check why the 7thEd sh yields SIGPIPE. And ":|>>" (append) was just motivated by system call tracing (resulting in less file IO), while I tried to find out what was happening at all, before you pointed me to the solution "simple command". Like you I'm interested in the possible motivations for a redirection to be a simple command. Thus Warner and Michael really have a point about using plain redirection only, or in connection with exec, respectively. Sven From doug at cs.dartmouth.edu Sat Jan 4 12:58:56 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Fri, 03 Jan 2020 21:58:56 -0500 Subject: [TUHS] sh: cmd | >file Message-ID: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> > I'm interested in the possible motivations for a redirection to be > a simple command. I use it to truncate a file to zero length. Or to create (an empty) file. Doug From athornton at gmail.com Sat Jan 4 15:12:21 2020 From: athornton at gmail.com (Adam Thornton) Date: Fri, 3 Jan 2020 22:12:21 -0700 Subject: [TUHS] Some new text adventure stuff for 2.11BSD Message-ID: I'm having a party on Saturday January 11 (and if any of you are in Tucson, or want to come to Tucson for it, you're invited; email me for the address and time). Although the party is Elvis-themed, it's really about boardgaming and classic videogaming. So I kind of wanted to put a general-purpose Z-machine interpreter on my PiDP-11, so that people could play Infocom (and community) games on a real terminal. Turns out there wasn't really one, so I ported the venerable ZIP (which I have renamed "zterp" for obvious reasons) to 2.11BSD on the PDP-11, and I also wrote a little utility I call "tmenu" to take a directory (and an optional command applying to files in the directory) and make a numbered menu, so that my guests who are not familiar with Actual Bourne Shell can play games too. These things are at: https://github.com/athornton/pdp11-zterp and https://github.com/athornton/pdp11-tmenu/ Both are K&R C, and compile with the 2.11BSD system C compiler. My biggest disappointment is that the memory map of Trinity, my favorite Infocom game, is weird and even though it's only a V5 game, I can't allocate enough memory to start it. Other than that, V5 and below seem to work mostly fine; V8 is in theory supported but no game that I've tried has little enough low memory that I can malloc() it using C on 2.11BSD. Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From meillo at marmaro.de Sat Jan 4 20:07:18 2020 From: meillo at marmaro.de (markus schnalke) Date: Sat, 04 Jan 2020 11:07:18 +0100 Subject: [TUHS] sh: cmd | >file In-Reply-To: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> Message-ID: <1ingL0-5g6-00@marmaro.de> Hoi. [2020-01-03 21:58] Doug McIlroy > > > I'm interested in the possible motivations for a redirection to be > > a simple command. > > I use it to truncate a file to zero length. > Or to create (an empty) file. Thanks for the replies. My question was not about the use cases for ``>file'' but *why* it was made a simple command. Let me explain: One creates an empty file or truncates a file with: >file why not with: :>file ? To me it looks to be the more sensible ... more regular way. IO redirections for the shell itself could be made with: exec >file 5>& no matter if ``>file'' is a simple command or not. Because of ``exec'' the line is valid syntax (although the grammer probably was retro-fitted), and the manpages (mksh, bash, heirloom sh) all document exec without a command as a separate case (and the code probably handles it as a separate case as well), thus nothing is gained here from making ``>file'' a simple command. This is what wonder about: Why make ``>file'' a simple command, when -- as far as I can currently see -- there is no reason to do so, as all uses could have been achieved in more regular ways as well? So, was it rather by accident and it settled or is there something I don't see yet? Came `:' later in development, for instance, or was it special in a way that it couldn't be used to create and truncate files? Or is there even some clever design that I haven't understood yet? Are there use cases that can only be achieved with ``>file'' but not with ``:>file''? meillo From bqt at softjar.se Sat Jan 4 19:59:44 2020 From: bqt at softjar.se (Johnny Billquist) Date: Sat, 4 Jan 2020 10:59:44 +0100 Subject: [TUHS] [PiDP-11] Some new text adventure stuff for 2.11BSD In-Reply-To: References: Message-ID: <092a1ce7-8719-8282-0363-f3da62ea02b7@softjar.se> Interesting. Trinity works fine under ZEMU. So ZIP must be rather a hog... V8 games that I've played under ZEMU: BALLERINA DREAMHOLDER HEROINE VIOLET Johnny On 2020-01-04 06:12, Adam Thornton wrote: > I'm having a party on Saturday January 11 (and if any of you are in > Tucson, or want to come to Tucson for it, you're invited; email me for > the address and time). > > Although the party is Elvis-themed, it's really about boardgaming and > classic videogaming. > > So I kind of wanted to put a general-purpose Z-machine interpreter on my > PiDP-11, so that people could play Infocom (and community) games on a > real terminal. > > Turns out there wasn't really one, so I ported the venerable ZIP (which > I have renamed "zterp" for obvious reasons) to 2.11BSD on the PDP-11, > and I also wrote a little utility I call "tmenu" to take a directory > (and an optional command applying to files in the directory) and make a > numbered menu, so that my guests who are not familiar with Actual Bourne > Shell can play games too. > > These things are at: > > https://github.com/athornton/pdp11-zterp > > and > > https://github.com/athornton/pdp11-tmenu/ > > Both are K&R C, and compile with the 2.11BSD system C compiler. > > My biggest disappointment is that the memory map of Trinity, my favorite > Infocom game, is weird and even though it's only a V5 game, I can't > allocate enough memory to start it.  Other than that, V5 and below seem > to work mostly fine; V8 is in theory supported but no game that I've > tried has little enough low memory that I can malloc() it using C on > 2.11BSD. > > Adam > > -- > You received this message because you are subscribed to the Google > Groups "[PiDP-11]" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to pidp-11+unsubscribe at googlegroups.com > . > To view this discussion on the web visit > https://groups.google.com/d/msgid/pidp-11/CAP2nic3C7OW5OKPB_a2n9jOYDA7476MDRjgxKVyW0DkMKf6OsA%40mail.gmail.com > . -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From fuz at fuz.su Sat Jan 4 21:47:50 2020 From: fuz at fuz.su (Robert Clausecker) Date: Sat, 4 Jan 2020 12:47:50 +0100 Subject: [TUHS] sh: cmd | >file In-Reply-To: <1ingL0-5g6-00@marmaro.de> References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> <1ingL0-5g6-00@marmaro.de> Message-ID: <20200104114750.GA30769@fuz.su> Good morning! On Sat, Jan 04, 2020 at 11:07:18AM +0100, markus schnalke wrote: > One creates an empty file or truncates a file with: > > >file > > why not with: > > :>file > ? > > To me it looks to be the more sensible ... more regular way. > > IO redirections for the shell itself could be made with: > > exec >file 5>& > > no matter if ``>file'' is a simple command or not. Because of > ``exec'' the line is valid syntax (although the grammer probably > was retro-fitted), and the manpages (mksh, bash, heirloom sh) all > document exec without a command as a separate case (and the code > probably handles it as a separate case as well), thus nothing is > gained here from making ``>file'' a simple command. > > This is what wonder about: Why make ``>file'' a simple command, > when -- as far as I can currently see -- there is no reason to do > so, as all uses could have been achieved in more regular ways as > well? I think the key reason is that the shell does not build an AST from the command you type, instead executing the phrases it encounters as it sees them. So when the shell sees ">file", it opens "file" for writing in preparation of the rest of the command. If no command comes, the line is handled the same way as an empty one and the redirections are discarded. The shell could print an error here, but avoiding the side effect of opening "file" for lines just consisting of redirects would be difficult. But then, why should it print an error? The behaviour is not harmful after all and I'd say that nobody really thought about this being a thing when the shell was originally written. Yours, Robert Clausecker -- () ascii ribbon campaign - for an 8-bit clean world /\ - against html email - against proprietary attachments From doug at cs.dartmouth.edu Sun Jan 5 00:23:39 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sat, 04 Jan 2020 09:23:39 -0500 Subject: [TUHS] GNUism in groff tests, was: pic anomalies Message-ID: <202001041423.004ENd7b004197@tahoe.cs.Dartmouth.EDU> > I was always sad that the development of C that became Alef never got off > the ground. It eventuated in Go, which is definitely aloft, and responds to Mike Bianchi's specific desires. Go also has a library ecosystem, which C does not. With its clean parallelism, Go may be suitable for handling the complexity of whole-paragraph typsetting in the face of unexpected traps, line-length changes, etc. Doug From steffen at sdaoden.eu Sun Jan 5 06:41:17 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sat, 04 Jan 2020 21:41:17 +0100 Subject: [TUHS] sh: cmd | >file In-Reply-To: <20200104005350.GA156384@lisa.in-ulm.de> References: <1inMKv-0Km-00@marmaro.de> <20200103140055.XB8iT%steffen@sdaoden.eu> <01d9e48c-2f92-48b9-b4ec-cd29fcfd1fa4@www.fastmail.com> <1inQaG-3N3-00@marmaro.de> <20200104005350.GA156384@lisa.in-ulm.de> Message-ID: <20200104204117.5Oo-9%steffen@sdaoden.eu> Sven Mascheck via TUHS wrote in <20200104005350.GA156384 at lisa.in-ulm.de>: |On Fri, Jan 03, 2020 at 06:18:00PM +0100, markus schnalke wrote: |> [2020-01-03 11:03] "Brian Zick" |>> I'm curious to know if you have a script you used to prove these \ |>> correct? |> |> We have to wait for Sven Mascheck to answer this question. He tested |> the different shells. | |I guess Brian meant Steffen. I have no idea what Steffen meant with "proved |correct". It was a citation, maybe too sloppy. |(and I believe Gunnar was not motivated to guarantee his heirloom port |to compete in production environments against modern shell variants with |continued maintenance, yet tried hard that time to find and fix as \ |many bugs |as possible; I tried to help him a little bit that time. Just consider how That is what "is flowing out behind me", overall. |much still had been fixed by Sun even after their SVR4 sh. more corner case |bugs to be expected...) I did not throw doubt on this. I think he achieved a lot in Heirloom tools and especially roff in only four years i think, starting in 2004. The sh has this ": > FILE" bug, which sometimes shows up. --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) From dave at horsfall.org Sun Jan 5 07:02:08 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 5 Jan 2020 08:02:08 +1100 (EST) Subject: [TUHS] sh: cmd | >file In-Reply-To: <1ingL0-5g6-00@marmaro.de> References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> <1ingL0-5g6-00@marmaro.de> Message-ID: On Sat, 4 Jan 2020, markus schnalke wrote: > My question was not about the use cases for ``>file'' but *why* it was > made a simple command. Let me explain: > > One creates an empty file or truncates a file with: > > >file > > why not with: > > :>file > ? > > To me it looks to be the more sensible ... more regular way. The Unix philosophy, perhaps i.e. keep it simple? Why have ":" (an actual internal Shell command) when "" (the null command) will do the job? I guess only the Bell Labs bods here can answer this. -- Dave From dave at horsfall.org Sun Jan 5 07:11:18 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 5 Jan 2020 08:11:18 +1100 (EST) Subject: [TUHS] sh: cmd | >file In-Reply-To: References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> <1ingL0-5g6-00@marmaro.de> Message-ID: On Sun, 5 Jan 2020, Dave Horsfall wrote: > The Unix philosophy, perhaps i.e. keep it simple? Why have ":" (an > actual internal Shell command) when "" (the null command) will do the > job? Also, remember that ":" was also used as a comment, before "#" was used. -- Dave From imp at bsdimp.com Sun Jan 5 07:39:12 2020 From: imp at bsdimp.com (Warner Losh) Date: Sat, 4 Jan 2020 15:39:12 -0600 Subject: [TUHS] sh: cmd | >file In-Reply-To: References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> <1ingL0-5g6-00@marmaro.de> Message-ID: On Sat, Jan 4, 2020, 3:11 PM Dave Horsfall wrote: > On Sun, 5 Jan 2020, Dave Horsfall wrote: > > > The Unix philosophy, perhaps i.e. keep it simple? Why have ":" (an > > actual internal Shell command) when "" (the null command) will do the > > job? > > Also, remember that ":" was also used as a comment, before "#" was used. > I thought it was a null label for a goto target... :) Warner -- Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Sun Jan 5 07:06:09 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Sat, 04 Jan 2020 13:06:09 -0800 Subject: [TUHS] sh: cmd | >file In-Reply-To: References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> <1ingL0-5g6-00@marmaro.de> Message-ID: <202001042106.004L69C1448350@darkstar.fourwinds.com> Dave Horsfall writes: > On Sat, 4 Jan 2020, markus schnalke wrote: > > > My question was not about the use cases for ``>file'' but *why* it was > > made a simple command. Let me explain: > > > > One creates an empty file or truncates a file with: > > > > >file > > > > why not with: > > > > :>file > > ? > > > > To me it looks to be the more sensible ... more regular way. > > The Unix philosophy, perhaps i.e. keep it simple? Why have ":" (an actual > internal Shell command) when "" (the null command) will do the job? > > I guess only the Bell Labs bods here can answer this. > > -- Dave Don't know if Steve Bourne is on this list, but he's been a great source of information when I've had questions about why the shell did things the way it did. Jon From terry at jon.es Sun Jan 5 08:19:07 2020 From: terry at jon.es (Terry Jones) Date: Sat, 4 Jan 2020 23:19:07 +0100 Subject: [TUHS] sh: cmd | >file In-Reply-To: References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> <1ingL0-5g6-00@marmaro.de> Message-ID: Was : actually designed for commenting? If so, at what point did it become a command that always returns zero exit status? Was it always built-in, or did it originally have a separate filesystem existence (like "[")? Python has a useful "pass" command, but : is much nicer because you can "comment" out a single command in (e.g.) an if/then and it remains syntactically valid and executable. I find it very elegant. Terry On Sat, Jan 4, 2020 at 10:40 PM Warner Losh wrote: > > > On Sat, Jan 4, 2020, 3:11 PM Dave Horsfall wrote: > >> On Sun, 5 Jan 2020, Dave Horsfall wrote: >> >> > The Unix philosophy, perhaps i.e. keep it simple? Why have ":" (an >> > actual internal Shell command) when "" (the null command) will do the >> > job? >> >> Also, remember that ":" was also used as a comment, before "#" was used. >> > > I thought it was a null label for a goto target... :) > > Warner > > -- Dave >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Sun Jan 5 08:22:40 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 5 Jan 2020 09:22:40 +1100 (EST) Subject: [TUHS] sh: cmd | >file In-Reply-To: References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> <1ingL0-5g6-00@marmaro.de> Message-ID: On Sat, 4 Jan 2020, Warner Losh wrote: > Also, remember that ":" was also used as a comment, before "#" > was used. > > I thought it was a null label for a goto target... :) Yes, I'd forgotten that... The Shell, although simple in concept, was really quite powerful if you knew how to use it. -- Dave From chet.ramey at case.edu Sun Jan 5 08:33:56 2020 From: chet.ramey at case.edu (Chet Ramey) Date: Sat, 4 Jan 2020 17:33:56 -0500 Subject: [TUHS] sh: cmd | >file In-Reply-To: References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> <1ingL0-5g6-00@marmaro.de> Message-ID: On 1/4/20 5:19 PM, Terry Jones wrote: > Was : actually designed for commenting?  If so, at what point did it become > a command that always returns zero exit status?  Was it always built-in, or > did it originally have a separate filesystem existence (like "[")? Python > has a useful "pass" command, but : is much nicer because you can "comment" > out a single command in (e.g.) an if/then and it remains syntactically > valid and executable. I find it very elegant. It's elegant until you forget that `:' continues to process redirections. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From chet.ramey at case.edu Sun Jan 5 08:31:31 2020 From: chet.ramey at case.edu (Chet Ramey) Date: Sat, 4 Jan 2020 17:31:31 -0500 Subject: [TUHS] sh: cmd | >file In-Reply-To: <20200104114750.GA30769@fuz.su> References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> <1ingL0-5g6-00@marmaro.de> <20200104114750.GA30769@fuz.su> Message-ID: On 1/4/20 6:47 AM, Robert Clausecker wrote: >> This is what wonder about: Why make ``>file'' a simple command, >> when -- as far as I can currently see -- there is no reason to do >> so, as all uses could have been achieved in more regular ways as >> well? I'm going to answer in terms of the Bourne shell and its successors. > I think the key reason is that the shell does not build an AST from > the command you type, instead executing the phrases it encounters as it > sees them. This is false. > So when the shell sees ">file", it opens "file" for writing > in preparation of the rest of the command. Also not correct, at least if you mean opening it before completing the parse. > If no command comes, the > line is handled the same way as an empty one and the redirections are > discarded. Not really. The shell parses the line into a list of words. Those words make up a simple command, since none of the words were identified as a reserved word, and so are not the first word of a compound command. It's the default case, basically. The POSIX standard gives a pretty good summary of what happens next: the redirections get separated out and the rest of the words are expanded. You already have to deal with the expansions returning nothing, since the words could all be null variable expansions, so the case where there are no words besides redirections and assignment statements isn't that much different. > The shell could print an error here, It could, but Bourne chose not to. > but avoiding the side > effect of opening "file" for lines just consisting of redirects would be > difficult. But then, why should it print an error? The behaviour is > not harmful after all This is true. There aren't any other cases where the shell makes a null expansion an error without being directly asked, so it would not have made sense to make a command consisting entirely of words that expand to null an error. There's no good reason to treat a null command differently from that case. > and I'd say that nobody really thought about this > being a thing when the shell was originally written. On the contrary, I think Bourne made a conscious choice to handle redirections `separately' from simple command expansion and execution, and a conscious choice to continue to process redirections (in a subshell, as if the shell had forked to execute a non-builtin) when word expansion resulted in no words. It's the `exec' case with redirections that I think was the special case, since Bourne's (v7) shell didn't allow redirections with builtins at all. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From meillo at marmaro.de Sun Jan 5 08:44:35 2020 From: meillo at marmaro.de (markus schnalke) Date: Sat, 04 Jan 2020 23:44:35 +0100 Subject: [TUHS] sh: cmd | >file In-Reply-To: References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> <1ingL0-5g6-00@marmaro.de> Message-ID: <1ins9r-4KA-00@marmaro.de> Hoi. [2020-01-04 23:19] Terry Jones > > Was : actually designed for commenting? Hardly, because who would want comments to have side effects: : don't do this Or this: : ignored; echo executed Or this dangerously ``outcommented'' line: : test ... && rm file ! Using : for comments is only possible as the command does nothing and ignores its arguments ... but the shell parses the arguments as for every other command ... and executes stuff in the line that are no arguments to :. In case of #, the rest of the line is truly ignored, as comments should be like. > but : is much nicer because you can "comment" out a > single command in (e.g.) an if/then and it remains syntactically valid and > executable. I find it very elegant. Can you please give an example for me to understand what you mean by that? meillo From terry at jon.es Sun Jan 5 09:01:42 2020 From: terry at jon.es (Terry Jones) Date: Sun, 5 Jan 2020 00:01:42 +0100 Subject: [TUHS] sh: cmd | >file In-Reply-To: <1ins9r-4KA-00@marmaro.de> References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> <1ingL0-5g6-00@marmaro.de> <1ins9r-4KA-00@marmaro.de> Message-ID: On Sat, Jan 4, 2020 at 11:45 PM markus schnalke wrote: > > > but : is much nicer because you can "comment" out a > > single command in (e.g.) an if/then and it remains syntactically valid > and > > executable. I find it very elegant. > > Can you please give an example for me to understand what you mean > by that? > While developing, I frequently have some code like: if test -f somefile then cmd1 cmd2 else echo somefile is missing fi I have the "else" clause because I initially want to explicitly see some output in that case. A bit later if I temporarily don't want the output (but want to keep the else and the echo line around) I can just put a colon before the echo. You can't do that with a # because you get a syntax error. And if you wanted to use # you'd then have to put in some other do-nothing line (maybe a : by itself) to keep valid syntax. In a situation like this I will eventually end up deleting the echo line and the preceding else, but during development I like being able to use : in this way. Terry > > meillo > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Sun Jan 5 09:53:47 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 5 Jan 2020 10:53:47 +1100 (EST) Subject: [TUHS] sh: cmd | >file In-Reply-To: References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> <1ingL0-5g6-00@marmaro.de> Message-ID: On Sat, 4 Jan 2020, Chet Ramey wrote: > It's elegant until you forget that `:' continues to process redirections. So just keep remembering that it's an actual command :-) Which reminds me: which Shell introduced "#" as a true comment? Hmmm, not quite true; only the C-Shell says "#: Command not found" so it only works in a script; odd... Then again, no-one in their right mind uses "csh" :-) -- Dave From andreas.kahari at abc.se Sun Jan 5 10:04:27 2020 From: andreas.kahari at abc.se (Andreas Kusalananda =?iso-8859-1?B?S+Ro5HJp?=) Date: Sun, 5 Jan 2020 01:04:27 +0100 Subject: [TUHS] sh: cmd | >file In-Reply-To: References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> <1ingL0-5g6-00@marmaro.de> Message-ID: <20200105000427.GA67963@pooh.prefix.duckdns.org> On Sun, Jan 05, 2020 at 10:53:47AM +1100, Dave Horsfall wrote: > On Sat, 4 Jan 2020, Chet Ramey wrote: > > > It's elegant until you forget that `:' continues to process redirections. > > So just keep remembering that it's an actual command :-) > > Which reminds me: which Shell introduced "#" as a true comment? > > Hmmm, not quite true; only the C-Shell says "#: Command not found" so it > only works in a script; odd... > > Then again, no-one in their right mind uses "csh" :-) > > -- Dave In bash (turning off interactive_comments): $ shopt -u interactive_comments $ echo hello # world hello # world $ # oh bash: #: command not found In zsh (by default): $ echo hello # world hello # world $ # oh zsh: command not found: # zsh is the fun one though (allows setting the comment character): $ histchars[3]='@' $ echo hello @ world hello @ world $ setopt INTERACTIVE_COMMENTS $ echo hello @ world hello $ @ oh, a comment $ -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden From tuhs at eric.allman.name Sun Jan 5 10:03:26 2020 From: tuhs at eric.allman.name (Eric Allman) Date: Sat, 4 Jan 2020 16:03:26 -0800 Subject: [TUHS] sh: cmd | >file In-Reply-To: <202001042106.004L69C1448350@darkstar.fourwinds.com> References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> <1ingL0-5g6-00@marmaro.de> <202001042106.004L69C1448350@darkstar.fourwinds.com> Message-ID: <026e2abb-fe04-4186-d3b2-0f32109d323a@neophilic.com> I contacted Steve --- he is on the list, and says he'll weigh in. eric On 2020-01-04 13:06, Jon Steinhart wrote: > Dave Horsfall writes: >> On Sat, 4 Jan 2020, markus schnalke wrote: >> >>> My question was not about the use cases for ``>file'' but *why* it was >>> made a simple command. Let me explain: >>> >>> One creates an empty file or truncates a file with: >>> >>> >file >>> >>> why not with: >>> >>> :>file >>> ? >>> >>> To me it looks to be the more sensible ... more regular way. >> >> The Unix philosophy, perhaps i.e. keep it simple? Why have ":" (an actual >> internal Shell command) when "" (the null command) will do the job? >> >> I guess only the Bell Labs bods here can answer this. >> >> -- Dave > > Don't know if Steve Bourne is on this list, but he's been a great source > of information when I've had questions about why the shell did things the > way it did. > > Jon > From athornton at gmail.com Sun Jan 5 11:49:46 2020 From: athornton at gmail.com (Adam Thornton) Date: Sat, 4 Jan 2020 18:49:46 -0700 Subject: [TUHS] sh: cmd | >file In-Reply-To: <026e2abb-fe04-4186-d3b2-0f32109d323a@neophilic.com> References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> <1ingL0-5g6-00@marmaro.de> <202001042106.004L69C1448350@darkstar.fourwinds.com> <026e2abb-fe04-4186-d3b2-0f32109d323a@neophilic.com> Message-ID: v7 Bourne shell does not appear to treat '#' as a comment. I've built termlib and curses for v7 and am now trying to find a small screen editor. I was trying se, but the version I have ships as a shell archive, and it doesn't actually unpack on v7, in part because of the comments. v7 is a target in Jove's Ovmakefile, so that's what I'm trying now. Slow-pasting uuencoded files into the terminal is gross, but efficacious.... Adam On Sat, Jan 4, 2020 at 5:48 PM Eric Allman wrote: > I contacted Steve --- he is on the list, and says he'll weigh in. > > eric > > > On 2020-01-04 13:06, Jon Steinhart wrote: > > Dave Horsfall writes: > >> On Sat, 4 Jan 2020, markus schnalke wrote: > >> > >>> My question was not about the use cases for ``>file'' but *why* it was > >>> made a simple command. Let me explain: > >>> > >>> One creates an empty file or truncates a file with: > >>> > >>> >file > >>> > >>> why not with: > >>> > >>> :>file > >>> ? > >>> > >>> To me it looks to be the more sensible ... more regular way. > >> > >> The Unix philosophy, perhaps i.e. keep it simple? Why have ":" (an > actual > >> internal Shell command) when "" (the null command) will do the job? > >> > >> I guess only the Bell Labs bods here can answer this. > >> > >> -- Dave > > > > Don't know if Steve Bourne is on this list, but he's been a great source > > of information when I've had questions about why the shell did things the > > way it did. > > > > Jon > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chet.ramey at case.edu Sun Jan 5 12:41:59 2020 From: chet.ramey at case.edu (Chet Ramey) Date: Sat, 4 Jan 2020 21:41:59 -0500 Subject: [TUHS] sh: cmd | >file In-Reply-To: References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> <1ingL0-5g6-00@marmaro.de> Message-ID: <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu> On 1/4/20 6:53 PM, Dave Horsfall wrote: > On Sat, 4 Jan 2020, Chet Ramey wrote: > >> It's elegant until you forget that `:' continues to process redirections. > > So just keep remembering that it's an actual command :-) > > Which reminds me: which Shell introduced "#" as a true comment? Define "true comment." The v7 shell had `#' as the comment character, but it only worked when in non-interactive shells. I think it was the Sys III shell that made it work when the shell was interactive. This is, incidentally, why bash has the `interactive_comments' option, which I saw in another message. BSD, which most of the GNU developers were using at the (pre-POSIX) time, used the v7 shell and didn't have interactive comments. When a sufficiently-advanced POSIX draft required them, we added it. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From chet.ramey at case.edu Sun Jan 5 12:44:48 2020 From: chet.ramey at case.edu (Chet Ramey) Date: Sat, 4 Jan 2020 21:44:48 -0500 Subject: [TUHS] sh: cmd | >file In-Reply-To: References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> <1ingL0-5g6-00@marmaro.de> <202001042106.004L69C1448350@darkstar.fourwinds.com> <026e2abb-fe04-4186-d3b2-0f32109d323a@neophilic.com> Message-ID: <52886e4e-2987-c309-053a-d229e1f33831@case.edu> On 1/4/20 8:49 PM, Adam Thornton wrote: > v7 Bourne shell does not appear to treat '#' as a comment. It does, when the shell is not interactive and reading input from a script, pipe, or input redirection. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From brantley at coraid.com Sun Jan 5 18:15:02 2020 From: brantley at coraid.com (Brantley Coile) Date: Sun, 5 Jan 2020 08:15:02 +0000 Subject: [TUHS] sh: cmd | >file In-Reply-To: <52886e4e-2987-c309-053a-d229e1f33831@case.edu> References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> <1ingL0-5g6-00@marmaro.de> <202001042106.004L69C1448350@darkstar.fourwinds.com> <026e2abb-fe04-4186-d3b2-0f32109d323a@neophilic.com> <52886e4e-2987-c309-053a-d229e1f33831@case.edu> Message-ID: <749E0F47-FEF9-4424-8A7B-F0B6805306F5@coraid.com> V7 indeed did not have "#" as a comment. Programs use the ":" command for that, and was careful of what was in the comment. The ":" command was called SYSNULL in the source. Later versions of Steve's shell had COMCHAR defined to be a "#" and tested for that symbol in word(), eating up all the characters until it got to a newline. The version of Seventh Edition I used to carry around and embed in things had that mod. My original Seventh did not. > On Jan 4, 2020, at 9:44 PM, Chet Ramey wrote: > > On 1/4/20 8:49 PM, Adam Thornton wrote: >> v7 Bourne shell does not appear to treat '#' as a comment. > > It does, when the shell is not interactive and reading input from a script, > pipe, or input redirection. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From mascheck at in-ulm.de Sun Jan 5 23:45:23 2020 From: mascheck at in-ulm.de (Sven Mascheck) Date: Sun, 5 Jan 2020 14:45:23 +0100 Subject: [TUHS] sh: cmd | >file In-Reply-To: <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu> References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> <1ingL0-5g6-00@marmaro.de> <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu> Message-ID: <20200105134523.GA417916@lisa.in-ulm.de> On Sat, Jan 04, 2020 at 09:41:59PM -0500, Chet Ramey wrote: > On 1/4/20 6:53 PM, Dave Horsfall wrote: > > Which reminds me: which Shell introduced "#" as a true comment? > > Define "true comment." The v7 shell had `#' as the comment character, but > it only worked when in non-interactive shells. I think it was the Sys III > shell that made it work when the shell was interactive. > > This is, incidentally, why bash has the `interactive_comments' option, > which I saw in another message. BSD, which most of the GNU developers were > using at the (pre-POSIX) time, used the v7 shell and didn't have > interactive comments. When a sufficiently-advanced POSIX draft required > them, we added it. concerning "interactive" I think instead of the V7 sh you rather have the BSD sh in mind here. V7 sh didn't know # at all. At ATT it came with SysIII (both modes). And keep in mind, stty erase defaulted to # on V7, even until SySV (and 3BSD), and this character wouldn't have been handy anyway. 4+BSD changed this. 4.1BSD implemented #, and 4.3 BSD changed it to "non-interactive only". (And all this is not to be confused with the # hack to exec to csh on 3+BSD, only if it's the first character in a script.) BTW, an academic yet funny example of : side effects is this : `echo output 1>&2` Sven From chet.ramey at case.edu Mon Jan 6 01:16:44 2020 From: chet.ramey at case.edu (Chet Ramey) Date: Sun, 5 Jan 2020 10:16:44 -0500 Subject: [TUHS] sh: cmd | >file In-Reply-To: <749E0F47-FEF9-4424-8A7B-F0B6805306F5@coraid.com> References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> <1ingL0-5g6-00@marmaro.de> <202001042106.004L69C1448350@darkstar.fourwinds.com> <026e2abb-fe04-4186-d3b2-0f32109d323a@neophilic.com> <52886e4e-2987-c309-053a-d229e1f33831@case.edu> <749E0F47-FEF9-4424-8A7B-F0B6805306F5@coraid.com> Message-ID: On 1/5/20 3:15 AM, Brantley Coile wrote: > V7 indeed did not have "#" as a comment. Programs use the ":" command for that, and was careful of what was in the comment. The ":" command was called SYSNULL in the source. > Later versions of Steve's shell had COMCHAR defined to be a "#" and tested for that symbol in word(), eating up all the characters until it got to a newline. The version of Seventh Edition I used to carry around and embed in things had that mod. My original Seventh did not. I think the 7th edition shell I have must have those changes, since it definitely understands `#' comments. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From chet.ramey at case.edu Mon Jan 6 01:18:17 2020 From: chet.ramey at case.edu (Chet Ramey) Date: Sun, 5 Jan 2020 10:18:17 -0500 Subject: [TUHS] sh: cmd | >file In-Reply-To: <20200105134523.GA417916@lisa.in-ulm.de> References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> <1ingL0-5g6-00@marmaro.de> <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu> <20200105134523.GA417916@lisa.in-ulm.de> Message-ID: <9cc26d26-7dfc-002e-79e3-0fc45e4d9fd6@case.edu> On 1/5/20 8:45 AM, Sven Mascheck via TUHS wrote: > 4.1BSD implemented #, and 4.3 BSD changed it to "non-interactive only". Yes, 4.3 (or SunOS) is what most of us were using at the time. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From dave at horsfall.org Mon Jan 6 07:21:11 2020 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 6 Jan 2020 08:21:11 +1100 (EST) Subject: [TUHS] sh: cmd | >file In-Reply-To: <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu> References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> <1ingL0-5g6-00@marmaro.de> <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu> Message-ID: On Sat, 4 Jan 2020, Chet Ramey wrote: >> Which reminds me: which Shell introduced "#" as a true comment? > > Define "true comment." The v7 shell had `#' as the comment character, but > it only worked when in non-interactive shells. I think it was the Sys III > shell that made it work when the shell was interactive. Yes, that's what I meant. > This is, incidentally, why bash has the `interactive_comments' option, > which I saw in another message. BSD, which most of the GNU developers were > using at the (pre-POSIX) time, used the v7 shell and didn't have > interactive comments. When a sufficiently-advanced POSIX draft required > them, we added it. I never did catch up with all the options on the various shells; I just stick with the defaults in general. Eg: aneurin% man bash | wc -l 5947 Life's too short... -- Dave From tuhs at cuzuco.com Mon Jan 6 13:24:06 2020 From: tuhs at cuzuco.com (Brian Walden) Date: Sun, 5 Jan 2020 22:24:06 -0500 (EST) Subject: [TUHS] sh: cmd | >file Message-ID: <202001060324.0063O6lt010608@cuzuco.com> More than you ever wanted to know about # The first shell to use it as a comment was csh(1), Bill Joy did this. This was also pre #! in the kernel so the shell had to exec scripts, not the kernel. This had traditionally been done after the exec() failed then shell ould run "sh argv[0]", but with two shells this was now a problem. So csh would look at the first line of the script and if it was a #\n it would exec csh on it if not it would exec sh(1) on it. This was check was also placed into to BSD's (not v7 nor att's) bourne shell so it could run csh scripts as well. However this was not the first use of # as a comment character. That award goes to Brian Kernighan's ratfor(1) (rational fortran) compiler in 1974-75. Then Feldman used in make(1) in 1976, followed by Kernighan's m4(1), learn(1) and most famously awk(1) in 1977 Bourne shell, written around 1976, eventualy picked this up later on but after the initial v7 release. And as some noted the : was kind of a comment, it was a command that did an exit(0) orginally for labels for Thompson's shell's goto command. The : command was eventually hard linked to the true(1) command Remember # was hard to type on teletypes as that was the erase character, so to enter it, you needed to type \# (# as erase and @ as line kill came from multics btw) It was so hard to type that the orignal assember based on DEC PAL-11R, that addressing syntax changed @ to * and # to $. In DEC it would be-- MOV @X, R0; In UNIX asm it became -- mov *x, r0 So this is also why C pointers use * notation. -Brian > From: Dave Horsfall dave at horsfall.org > >On Sat, 4 Jan 2020, Chet Ramey wrote: > >>> Which reminds me: which Shell introduced "#" as a true comment? >> >> Define "true comment." The v7 shell had `#' as the comment character, but >> it only worked when in non-interactive shells. I think it was the Sys III >> shell that made it work when the shell was interactive. > >Yes, that's what I meant. > >> This is, incidentally, why bash has the `interactive_comments' option, >> which I saw in another message. BSD, which most of the GNU developers were >> using at the (pre-POSIX) time, used the v7 shell and didn't have >> interactive comments. When a sufficiently-advanced POSIX draft required >> them, we added it. > >I never did catch up with all the options on the various shells; I just >stick with the defaults in general. Eg: > > aneurin% man bash | wc -l > 5947 > >Life's too short... > >-- Dave From will.senn at gmail.com Mon Jan 6 16:13:45 2020 From: will.senn at gmail.com (Will Senn) Date: Mon, 6 Jan 2020 00:13:45 -0600 Subject: [TUHS] wump.c for v6 Message-ID: <42cf63eb-d51e-d1ab-34ed-fbff94e18999@gmail.com> Hi, Does the wump.c source exist for v6? The game's in the distribution and so is the man page, but I can't find the source. I see it's in v7, but I don't know the provenance of the game source, hence the question. I find the following interesting... in the v7 source it says: /*  *      wumpus  *      stolen from PCC Vol 2 No 1  */ But it's actually from PCC Vol 2 No 2 (Nov 1973): https://archive.computerhistory.org/resources/access/text/2017/09/102661095/102661095-05-v2-n2-acc.pdf and the basic source is given in the games issue: https://archive.computerhistory.org/resources/access/text/2017/09/102661095/102661095-05-v2-games-acc.pdf The correct volume is noted in the v6 manpage: This program is based on one described  in  2  (No- vember 1973).  It will never replace Space War. and in the v7 manpage: This program is based on one described in People's Computer      Company, 2, 2 (November 1973). BUGS      It will never replace Space War. I'm curious if it was ported to c for v6, or if it was basic? Thanks, Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at cuzuco.com Mon Jan 6 16:30:07 2020 From: tuhs at cuzuco.com (Brian Walden) Date: Mon, 6 Jan 2020 01:30:07 -0500 (EST) Subject: [TUHS] # (was Re: sh: cmd | >file) Message-ID: <202001060630.0066U7U7023760@cuzuco.com> A bit more on this. csh(1) was wrtten around 1978 and yes # as a comment was only for scrtipts, think it was why would you need to comment interactively? And the # as an addition to be a comment in Bourne shell had to be around 1980 as that is when Dennis Ritchie added #! to exec(2) in the kernel. From this point on this forced all UNIX scripting languages to use # as a comment as it just exec'd the first string after the #! with the name of the current file being exec'd as the single argument. So things like perl(1) and python(1) had to use # if they wanted the #! mechanism to work for them too. So this worked great for shell scripts, it didn't work for awk(1) nor sed(1) nor s(1)(that is R(1) now) scripts (all needed a -f for input from file) nor dc(1) scripts as dc had no comment character. While Research UNIX got !# in 1980, this was after the 7th Edition release and the 8th Edition wasn't released until 1985), BSD got it around 1982-83, and System V didn't implement it until 1988. Eventully #! was extented so #!/usr/bin/awk -f would work. Also Bill Joy was the first to use # as a comment character in an /etc config file for his /etc/ttycap (which became /etc/termcap) for vi(1). Most configs did not have a comment at all at that time, while /etc/master used a * as a comment (SCCS used * as a comment too btw) Also before you say wait! ALGOL uses # as comment and is older than Kernighan' ratfor(1). This is a later addition. The original used the EBCDIC cent sign character to start and another cent sign to end the comment (i.e. programmer's two cents). If you were on an ASCII system this became "co" (for comment) as the original ASCII does not have a cent sign -Brian From chet.ramey at case.edu Mon Jan 6 23:53:29 2020 From: chet.ramey at case.edu (Chet Ramey) Date: Mon, 6 Jan 2020 08:53:29 -0500 Subject: [TUHS] sh: cmd | >file In-Reply-To: References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> <1ingL0-5g6-00@marmaro.de> <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu> Message-ID: <3958ec66-c5c0-e1bc-1476-2195907816b3@case.edu> On 1/5/20 4:21 PM, Dave Horsfall wrote: > On Sat, 4 Jan 2020, Chet Ramey wrote: > >>> Which reminds me: which Shell introduced "#" as a true comment? >> >> Define "true comment." The v7 shell had `#' as the comment character, but >> it only worked when in non-interactive shells. I think it was the Sys III >> shell that made it work when the shell was interactive. > > Yes, that's what I meant. It was the Sys III shell; I have a v7 shell that's apparently not the original. > I never did catch up with all the options on the various shells; I just > stick with the defaults in general.  Eg: > >     aneurin% man bash | wc -l >     5947 $ wc -l doc/bash.0 6206 doc/bash.0 I still get reports that things are not documented in sufficient detail. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From clemc at ccc.com Tue Jan 7 01:20:37 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 6 Jan 2020 10:20:37 -0500 Subject: [TUHS] wump.c for v6 In-Reply-To: <42cf63eb-d51e-d1ab-34ed-fbff94e18999@gmail.com> References: <42cf63eb-d51e-d1ab-34ed-fbff94e18999@gmail.com> Message-ID: On Mon, Jan 6, 2020 at 1:14 AM Will Senn wrote: > Does the wump.c source exist for v6? The game's in the distribution and so > is the man page, but I can't find the source. I see it's in v7, but I don't > know the provenance of the game source, hence the question. > Interesting question for someone like Doug, Steve or Ken. I bet it is pretty close, if not the same. I notice the V7 version used printf and getchar, but does not define stdio.h. It also has a struct in it. So by the time of that version, printf existed as did structs both of which were in the V6 C compiler (V6 did not have stdio, it had Mike Lesk's 'Portable I/O Library' (iolib in the sources). I don't have v6 handy, so I can not run a nm on /usr/games/wump but I bet if you did and compared it to an nm from V6 I bet they are darned close. .... > I'm curious if it was ported to c for v6, or if it was basic? > I would guess B or C not basic. The UNIX basic was primitive compared to Darthmouth (or HP - which would become HP-2000 basic but that's a different story). Code from PCC (or later David Ahl's "101 Basic Computer Games" ) would not work without extensive rewriting. Something that small, converting to B or C would have been similar effort so I would have expected that to have been what happened. Remember Edition X, particularly for the first few, was the status of the disks in research at the time. So there are a few cases of binaries in some of the earlier editions being found in /usr/bin or the like and the sources not there in the distribution. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Jan 7 01:24:46 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 6 Jan 2020 10:24:46 -0500 Subject: [TUHS] wump.c for v6 In-Reply-To: References: <42cf63eb-d51e-d1ab-34ed-fbff94e18999@gmail.com> Message-ID: ah dyslexia.... > > > I don't have v6 handy, so I can not run a nm on /usr/games/wump but I bet > if you did and compared it to an nm from *V7* I bet they are darned close. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brantley at coraid.com Tue Jan 7 01:42:22 2020 From: brantley at coraid.com (Brantley Coile) Date: Mon, 6 Jan 2020 15:42:22 +0000 Subject: [TUHS] sh: cmd | >file In-Reply-To: <3958ec66-c5c0-e1bc-1476-2195907816b3@case.edu> References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> <1ingL0-5g6-00@marmaro.de> <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu> <3958ec66-c5c0-e1bc-1476-2195907816b3@case.edu> Message-ID: <49E33BA0-C482-4A95-BF2B-2107C661D76B@coraid.com> Seems the man page for bash is longer than Steve's original source: ehg% pwd /sys/editions/unix/7e/usr/src/cmd/sh ehg% wc -l *.[ch] | tail -1 4111 total > On Jan 6, 2020, at 8:53 AM, Chet Ramey wrote: > > On 1/5/20 4:21 PM, Dave Horsfall wrote: >> On Sat, 4 Jan 2020, Chet Ramey wrote: >>>> Which reminds me: which Shell introduced "#" as a true comment? >>> >>> Define "true comment." The v7 shell had `#' as the comment character, but >>> it only worked when in non-interactive shells. I think it was the Sys III >>> shell that made it work when the shell was interactive. >> Yes, that's what I meant. > > It was the Sys III shell; I have a v7 shell that's apparently not the > original. > > >> I never did catch up with all the options on the various shells; I just >> stick with the defaults in general. Eg: >> aneurin% man bash | wc -l >> 5947 > > $ wc -l doc/bash.0 > 6206 doc/bash.0 > > I still get reports that things are not documented in sufficient detail. > > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From rich.salz at gmail.com Tue Jan 7 01:42:49 2020 From: rich.salz at gmail.com (Richard Salz) Date: Mon, 6 Jan 2020 10:42:49 -0500 Subject: [TUHS] sh: cmd | >file In-Reply-To: <202001060324.0063O6lt010608@cuzuco.com> References: <202001060324.0063O6lt010608@cuzuco.com> Message-ID: On Sun, Jan 5, 2020 at 10:42 PM Brian Walden wrote: > not the kernel. This had traditionally been done after the exec() failed > then shell ould run "sh argv[0]", but with two shells this was now a > problem. > It seems the kernel did that; http://man.cat-v.org/unix_7th/2/exec since argv[-1] was altered. I read somewhere, can't recall where, that Ken Thompson suggested "#!" being added to the kernel during his sabbatical there. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Tue Jan 7 01:46:06 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 06 Jan 2020 08:46:06 -0700 Subject: [TUHS] sh: cmd | >file In-Reply-To: <49E33BA0-C482-4A95-BF2B-2107C661D76B@coraid.com> References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> <1ingL0-5g6-00@marmaro.de> <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu> <3958ec66-c5c0-e1bc-1476-2195907816b3@case.edu> <49E33BA0-C482-4A95-BF2B-2107C661D76B@coraid.com> Message-ID: <202001061546.006Fk6Fb012760@freefriends.org> Brantley Coile wrote: > Seems the man page for bash is longer than Steve's original source: > > ehg% pwd > /sys/editions/unix/7e/usr/src/cmd/sh > ehg% wc -l *.[ch] | tail -1 > 4111 total And Bash (40 years later) does correspondingly more than the V7 shell did. I think these comparisons are a red herring. Would anyone who uses Bash regularly, both interactively and for scripting, really want to go back to using the V7 sh for production work? I certainly would not. Arnold From brantley at coraid.com Tue Jan 7 01:45:14 2020 From: brantley at coraid.com (Brantley Coile) Date: Mon, 6 Jan 2020 15:45:14 +0000 Subject: [TUHS] sh: cmd | >file In-Reply-To: References: <202001060324.0063O6lt010608@cuzuco.com> Message-ID: <4C62352C-A946-4ADB-BDE9-13B7C68D3493@coraid.com> I suspect so he could run the Pascal P-machine. > On Jan 6, 2020, at 10:42 AM, Richard Salz wrote: > > > > On Sun, Jan 5, 2020 at 10:42 PM Brian Walden wrote: > not the kernel. This had traditionally been done after the exec() failed > then shell ould run "sh argv[0]", but with two shells this was now a problem. > > It seems the kernel did that; http://man.cat-v.org/unix_7th/2/exec since argv[-1] was altered. > > I read somewhere, can't recall where, that Ken Thompson suggested "#!" being added to the kernel during his sabbatical there. > From tuhs at cuzuco.com Tue Jan 7 02:11:53 2020 From: tuhs at cuzuco.com (Brian Walden) Date: Mon, 6 Jan 2020 11:11:53 -0500 (EST) Subject: [TUHS] sh: cmd | >file Message-ID: <202001061612.006GBrAb018483@cuzuco.com> Richard Salz wrote: >> not the kernel. This had traditionally been done after the exec() failed >> then shell ould run "sh argv[0]", but with two shells this was now a >> problem. >> > >It seems the kernel did that; http://man.cat-v.org/unix_7th/2/exec since >argv[-1] was altered. As a user of these systems, the offical 7th Edition kernel most certainly could not execute a script, only binaries. It happend after the release 1979 and took time to make its way out, which it did via DSB before 8th Ed was finalized in 1985. The usenet announcement of this new functionality from Dennis is on Jan 10, 1980. Is listed here https://en.wikipedia.org/wiki/Shebang_(Unix) Dennis stated the idea was not his, it came up during csonverastions at a conference. -Brian From clemc at ccc.com Tue Jan 7 02:13:03 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 6 Jan 2020 11:13:03 -0500 Subject: [TUHS] sh: cmd | >file In-Reply-To: <202001061546.006Fk6Fb012760@freefriends.org> References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> <1ingL0-5g6-00@marmaro.de> <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu> <3958ec66-c5c0-e1bc-1476-2195907816b3@case.edu> <49E33BA0-C482-4A95-BF2B-2107C661D76B@coraid.com> <202001061546.006Fk6Fb012760@freefriends.org> Message-ID: On Mon, Jan 6, 2020 at 10:46 AM wrote: > > Would anyone who uses Bash regularly, both interactively and for > scripting, really want to go back to using the V7 sh > for production work? I certainly would not. > A heretic!! Believers all know '*Bourne to Program, Type with Joy' *and* 'One true bracing style' *are the two most important commandments of UNIX programmer! Seriously, I still write my scripts as v7 and use (t)csh as my login shell on all my UNIX boxes ;-) Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Tue Jan 7 02:25:05 2020 From: will.senn at gmail.com (Will Senn) Date: Mon, 6 Jan 2020 10:25:05 -0600 Subject: [TUHS] wump.c for v6 In-Reply-To: References: <42cf63eb-d51e-d1ab-34ed-fbff94e18999@gmail.com> Message-ID: <682F5EA8-A1D2-4A5A-933F-C46B3631030E@gmail.com> Sent from my iPhone > On Jan 6, 2020, at 9:20 AM, Clem Cole wrote: > > I don't have v6 handy, so I can not run a nm on /usr/games/wump but I bet if you did and compared it to an nm from V6 I bet they are darned close. > nm wump no name list Bummer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Jan 7 02:33:54 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 6 Jan 2020 11:33:54 -0500 Subject: [TUHS] sh: cmd | >file In-Reply-To: <202001061612.006GBrAb018483@cuzuco.com> References: <202001061612.006GBrAb018483@cuzuco.com> Message-ID: On Mon, Jan 6, 2020 at 11:13 AM Brian Walden wrote: > Dennis stated the idea was not his, it came up during csonverastions at a > conference. > Yeah that make sense. I'm pretty sure Joy had talked about it in the Summer '79 USENIX when 2BSD was announced. I remember his talk and a lot of people being awed (sort like what happens today when Linus comes to a conference). As I remember, one of his topics was csh and how it was different from the shell in the original BSD. He must have talked about #! and few other things for kernel (a bunch of speed ups in nami/inode look up IIRC), but that's about all I remember. The next winter was Boulder ('The Black Hole' conference) and he did a redux, and I remember being amazing how people were more interested in what he was saying than some of the folks from BTL and I remember a lot of Pascal questions at Boulder, FWIW. But to be frank, those conferences all sort of mix a little bit in my mind at this point. IIRC: Dennis was there, Bruce Borden and the Rand folks, as were other folks like Chesson and some of the U of I folks. Thanks to my friendships with Ted Kowalsji and later Phil Karn, I had visited the labs a few times and had met Dennis et al in the early mid-70s, but I think that conference was the first time I personally met some of the other university types that I had been communication via the ArpaNet. I might even have an old conference list somewhere, but there was no proceedings yet for a few years. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Jan 7 02:35:26 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 6 Jan 2020 11:35:26 -0500 Subject: [TUHS] wump.c for v6 In-Reply-To: <682F5EA8-A1D2-4A5A-933F-C46B3631030E@gmail.com> References: <42cf63eb-d51e-d1ab-34ed-fbff94e18999@gmail.com> <682F5EA8-A1D2-4A5A-933F-C46B3631030E@gmail.com> Message-ID: Ah - sadly not surprising thinking back. Binaries got stripped to save a few bytes in those days. On Mon, Jan 6, 2020 at 11:25 AM Will Senn wrote: > > > Sent from my iPhone > > On Jan 6, 2020, at 9:20 AM, Clem Cole wrote: > > > I don't have v6 handy, so I can not run a nm on /usr/games/wump but I bet > if you did and compared it to an nm from V6 I bet they are darned close. > > nm wump > no name list > > Bummer. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at quintile.net Tue Jan 7 02:33:21 2020 From: steve at quintile.net (Steve Simon) Date: Mon, 6 Jan 2020 16:33:21 +0000 Subject: [TUHS] shell comment chars Message-ID: <7D7C9DDB-1ED3-4BD3-98C1-BD81CB1BA334@quintile.net> i started on the 7th edition on a perkin elmer (ne interdata) - this was v7 with some 2.1bsd sprinkled on top. i remember the continual annoyance of unpacking shar files starting with hash comments : only on ed7. in the end i wrote a trivial sed to remove them called unshar. i haven't thought of that for decades... -Steve From imp at bsdimp.com Tue Jan 7 04:29:59 2020 From: imp at bsdimp.com (Warner Losh) Date: Mon, 6 Jan 2020 11:29:59 -0700 Subject: [TUHS] wump.c for v6 In-Reply-To: References: <42cf63eb-d51e-d1ab-34ed-fbff94e18999@gmail.com> <682F5EA8-A1D2-4A5A-933F-C46B3631030E@gmail.com> Message-ID: The good news is that disassembly will tell you right away if it was written in C or not. On Mon, Jan 6, 2020 at 9:36 AM Clem Cole wrote: > Ah - sadly not surprising thinking back. Binaries got stripped to save a > few bytes in those days. > > On Mon, Jan 6, 2020 at 11:25 AM Will Senn wrote: > >> >> >> Sent from my iPhone >> >> On Jan 6, 2020, at 9:20 AM, Clem Cole wrote: >> >> >> I don't have v6 handy, so I can not run a nm on /usr/games/wump but I bet >> if you did and compared it to an nm from V6 I bet they are darned close. >> >> nm wump >> no name list >> >> Bummer. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Tue Jan 7 04:38:25 2020 From: will.senn at gmail.com (Will Senn) Date: Mon, 6 Jan 2020 12:38:25 -0600 Subject: [TUHS] wump.c for v6 In-Reply-To: References: <42cf63eb-d51e-d1ab-34ed-fbff94e18999@gmail.com> <682F5EA8-A1D2-4A5A-933F-C46B3631030E@gmail.com> Message-ID: On 1/6/20 12:29 PM, Warner Losh wrote: > The good news is that disassembly will tell you right away if it was > written in C or not. > > OK. I give up. How? Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Tue Jan 7 04:48:02 2020 From: imp at bsdimp.com (Warner Losh) Date: Mon, 6 Jan 2020 11:48:02 -0700 Subject: [TUHS] wump.c for v6 In-Reply-To: References: <42cf63eb-d51e-d1ab-34ed-fbff94e18999@gmail.com> <682F5EA8-A1D2-4A5A-933F-C46B3631030E@gmail.com> Message-ID: On Mon, Jan 6, 2020 at 11:38 AM Will Senn wrote: > On 1/6/20 12:29 PM, Warner Losh wrote: > > The good news is that disassembly will tell you right away if it was > written in C or not. > > > OK. I give up. How? > Generally, the C compiler generates code that's quite distinctive (at least PCC does, not sure about Dennis' compiler). People writing free assembler tend to do really weird things for function entry / return. And it will likely tell you if it's some weird wrapper around another binary, though that wasn't too common at bell labs. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at bitblocks.com Tue Jan 7 05:10:26 2020 From: bakul at bitblocks.com (Bakul Shah) Date: Mon, 06 Jan 2020 11:10:26 -0800 Subject: [TUHS] wump.c for v6 In-Reply-To: Your message of "Mon, 06 Jan 2020 12:38:25 -0600." References: <42cf63eb-d51e-d1ab-34ed-fbff94e18999@gmail.com> <682F5EA8-A1D2-4A5A-933F-C46B3631030E@gmail.com> Message-ID: <20200106191033.82856156E42D@mail.bitblocks.com> On Mon, 06 Jan 2020 12:38:25 -0600 Will Senn wrote: > > On 1/6/20 12:29 PM, Warner Losh wrote: > > The good news is that disassembly will tell you right away if it was > > written in C or not. > > > > > OK. I give up. How? Running strings on the wump binary in Dennis_v6 and comparing its output with actual strings in the wump.c source n Henry_Spencerv7 reveals they are pretty much the same. From doug at cs.dartmouth.edu Tue Jan 7 05:47:56 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Mon, 06 Jan 2020 14:47:56 -0500 Subject: [TUHS] sh: cmd | >file Message-ID: <202001061947.006Jlu9X046618@tahoe.cs.Dartmouth.EDU> Brian Walden's discussion of sh #, etc, is right on. However, his etymology for unary * in C can be pushed back at least to 1959. * was used for indirect addressing in SAP, the assembler for the IBM 7090. From will.senn at gmail.com Tue Jan 7 06:29:22 2020 From: will.senn at gmail.com (Will Senn) Date: Mon, 6 Jan 2020 14:29:22 -0600 Subject: [TUHS] wump.c for v6 In-Reply-To: <20200106191033.82856156E42D@mail.bitblocks.com> References: <42cf63eb-d51e-d1ab-34ed-fbff94e18999@gmail.com> <682F5EA8-A1D2-4A5A-933F-C46B3631030E@gmail.com> <20200106191033.82856156E42D@mail.bitblocks.com> Message-ID: <46eb816b-3faa-b12a-a67c-e5aa84983158@gmail.com> On 1/6/20 1:10 PM, Bakul Shah wrote: > On Mon, 06 Jan 2020 12:38:25 -0600 Will Senn wrote: >> On 1/6/20 12:29 PM, Warner Losh wrote: >>> The good news is that disassembly will tell you right away if it was >>> written in C or not. >>> >>> >> OK. I give up. How? > Running strings on the wump binary in Dennis_v6 and comparing > its output with actual strings in the wump.c source n > Henry_Spencerv7 reveals they are pretty much the same. Oh. That's funny. I tried strings in v6, it wasn't there. It didn't occur to me to do it in MacOS... -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Tue Jan 7 06:44:18 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 06 Jan 2020 13:44:18 -0700 Subject: [TUHS] sh: cmd | >file In-Reply-To: References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> <1ingL0-5g6-00@marmaro.de> <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu> <3958ec66-c5c0-e1bc-1476-2195907816b3@case.edu> <49E33BA0-C482-4A95-BF2B-2107C661D76B@coraid.com> <202001061546.006Fk6Fb012760@freefriends.org> Message-ID: <202001062044.006KiIPY023871@freefriends.org> Clem Cole wrote: > On Mon, Jan 6, 2020 at 10:46 AM wrote: > > > Would anyone who uses Bash regularly, both interactively and for > > scripting, really want to go back to using the V7 sh > > for production work? I certainly would not. > > A heretic!! Believers all know '*Bourne to Program, Type with Joy' *and* > 'One true bracing style' *are the two most important commandments of UNIX > programmer! > > Seriously, I still write my scripts as v7 and use (t)csh as my login shell > on all my UNIX boxes ;-) Time to move into the 21st century. Tcsh has been obsolete for decades. Myself, when first exposed to the csh, I revolted (and was revolted) and stuck with the Bourne shell, even though there was no job control or history. I later ported Ron Minnich's job control from the BRL S5R2 on top of BSD shell to the plain BSD shell and also wrote my own !-style history editor for it. (Both were posted on USENET in the early 80s.) After that I got ksh86 and later ksh88, with vi-style command line editing and never looked back. Then, in the early 90s when I no longer had ksh access, I switched to bash, contributed fixes to readline's vi mode, and have been with bash since. (For a while I tried rc + readline, but that just didn't do it for me. Bash all the way. Zsh is too different in its vi mode.) And kudos to Chet for dealing with all the POSIX zigzags ("clarifications", "definitions") for the shell over the decades. I admire him, but I don't envy him. My two cents, Arnold From usotsuki at buric.co Tue Jan 7 06:51:03 2020 From: usotsuki at buric.co (Steve Nickolas) Date: Mon, 6 Jan 2020 15:51:03 -0500 (EST) Subject: [TUHS] sh: cmd | >file In-Reply-To: <202001062044.006KiIPY023871@freefriends.org> References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> <1ingL0-5g6-00@marmaro.de> <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu> <3958ec66-c5c0-e1bc-1476-2195907816b3@case.edu> <49E33BA0-C482-4A95-BF2B-2107C661D76B@coraid.com> <202001061546.006Fk6Fb012760@freefriends.org> <202001062044.006KiIPY023871@freefriends.org> Message-ID: On Mon, 6 Jan 2020, arnold at skeeve.com wrote: > After that I got ksh86 and later ksh88, with vi-style command line > editing and never looked back. Then, in the early 90s when I no longer > had ksh access, I switched to bash, contributed fixes to readline's vi > mode, and have been with bash since. I dig ksh93, because it's lighter and faster than bash, but I wish its tab completion worked like bash's. -uso. From norman at oclsc.org Tue Jan 7 07:01:04 2020 From: norman at oclsc.org (Norman Wilson) Date: Mon, 06 Jan 2020 16:01:04 -0500 Subject: [TUHS] Blit source Message-ID: <1578344467.1239.for-standards-violators@oclsc.org> Mike Haertel: That's amusing, considering that the 5620 stuff was in /usr/jerq on Research systems! Apparently the accident became institutionalized. ===== I remember the name Jerq being tossed around to mean 5620 when I was at 1127. That doesn't mean it was historically accurate, but it is consistent with the directory names, and the latter are probably where I got my mistaken idea of the history. Thanks to Rob, who certainly should know, for clearing it up. Norman Wilson Toronto ON From clemc at ccc.com Tue Jan 7 07:08:50 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 6 Jan 2020 16:08:50 -0500 Subject: [TUHS] wump.c for v6 In-Reply-To: References: <42cf63eb-d51e-d1ab-34ed-fbff94e18999@gmail.com> <682F5EA8-A1D2-4A5A-933F-C46B3631030E@gmail.com> Message-ID: You got my curiosity up and found the V5 and V6 source code (I did not have V4 easy to get, where I am today) ;-) A big clue of it being C will be having crt0.s (below) in the first few bytes of the disassembled code. We see the a.out header (i.e. start at offset 20 for the code) and look what's there. I'm going to guess that is at 046 is the address of _main, from the call instruction at address 034. The Trap 1 is a sys exit @ address 044. But .. the V6 crt0.s source has a call to _exit, which is lacking in the binary below. So it means that the binary was not created with the C runtime and probably not the v6 C compiler in the sources. So I took a peak at the V6 crt0.s and guess what -- it matches! So, I'm going to guess the binary was compiled and linked with an earlier compiler. Ao ... if I had to guess, the programs are similar, but possibly different. % more wump.das ; ; pdp11dasm version 0.0.3 ; disassembly of wump ; 000000: 000407 br 20 ; .. ; 000002: 005334 dec @(r4)+ ; \. 000004: 004524 jsr r5,(r4)+ ; T. 000006: 002312 bge 37777777634 ; J. 000010: 000000 halt ; .. 000012: 000000 halt ; .. 000014: 000000 halt ; .. ; 000016: 000001 wait ; .. 000020: 170011 setd ; .p 000022: 010600 mov r6,r0 ; .. 000024: 011046 mov (r0),-(r6) ; &. 000026: 005720 tst (r0)+ ; P. 000030: 010066 000002 mov r0,2(r6) ; 6... 000034: 004767 000006 call 46 ; w... 000040: 022626 cmp (r6)+,(r6)+ ; .% 000042: 005000 clr r0 ; .. 000044: 104401 trap 1 ; .. 000046: 004567 005174 jsr r5,5246 ; w.|. 000052: 005746 tst -(r6) ; f. 000054: 012716 011230 mov #11230,(r6) ; N... 000060: 004737 002776 call @#2776 ; _.~. 000064: 004767 002262 call 2352 ; w.2. 000070: 022700 000171 cmp #171,r0 ; @%y. 000074: 001027 bne 154 ; .. 000076: 005004 clr r4 ; .. 000100: 010400 mov r4,r0 ; .. 000102: 006300 asl r0 ; @. 000104: 005760 005334 tst 5334(r0) ; p.\. 000110: 001421 beq 154 ; .. 000112: 032704 000001 bit #1,r4 ; D5.. 000116: 001403 beq 126 ; .. 000120: 012716 000024 mov #24,(r6) ; N... 000124: 000402 br 132 ; .. ; 000126: 012716 000003 mov #3,(r6) ; N... 000132: 010400 mov r4,r0 ; .. 000134: 006300 asl r0 ; @. 000136: 016046 005334 mov 5334(r0),-(r6) ; &.\. 000142: 004737 002776 call @#2776 ; _.~. V6: s4/crt0.s: / C runtime startoff .globl savr5 .globl _exit .globl _main start: setd mov sp,r0 mov (r0),-(sp) tst (r0)+ mov r0,2(sp) jsr pc,_main mov r0,(sp) jsr pc,*$_exit sys exit .bss savr5: .=.+2 V5: s4/crt0.s: / C runtime startoff .globl savr5 .globl _main start: setd mov sp,r0 mov (r0),-(sp) tst (r0)+ mov r0,2(sp) jsr pc,_main cmp (sp)+,(sp)+ clr r0 sys exit .bss savr5: .=.+2 On Mon, Jan 6, 2020 at 1:48 PM Warner Losh wrote: > > > On Mon, Jan 6, 2020 at 11:38 AM Will Senn wrote: > >> On 1/6/20 12:29 PM, Warner Losh wrote: >> >> The good news is that disassembly will tell you right away if it was >> written in C or not. >> >> >> OK. I give up. How? >> > > Generally, the C compiler generates code that's quite distinctive (at > least PCC does, not sure about Dennis' compiler). People writing free > assembler tend to do really weird things for function entry / return. > > And it will likely tell you if it's some weird wrapper around another > binary, though that wasn't too common at bell labs. > > Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Tue Jan 7 07:29:30 2020 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 7 Jan 2020 08:29:30 +1100 (EST) Subject: [TUHS] sh: cmd | >file In-Reply-To: <202001061546.006Fk6Fb012760@freefriends.org> References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> <1ingL0-5g6-00@marmaro.de> <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu> <3958ec66-c5c0-e1bc-1476-2195907816b3@case.edu> <49E33BA0-C482-4A95-BF2B-2107C661D76B@coraid.com> <202001061546.006Fk6Fb012760@freefriends.org> Message-ID: On Mon, 6 Jan 2020, arnold at skeeve.com wrote: > Would anyone who uses Bash regularly, both interactively and > for scripting, really want to go back to using the V7 sh > for production work? I have never used all the fancy stuff in BASH such as the arithmetic functions; I still use "expr" etc for portability. My favourite shell is still ZSH (the alternative was CSH, and my views on that POS are well known) because I started using it long before BASH, and even then I use a fraction of its power. I did dabble with KSH, though (I needed command editing and history). -- Dave From clemc at ccc.com Tue Jan 7 07:32:24 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 6 Jan 2020 16:32:24 -0500 Subject: [TUHS] sh: cmd | >file In-Reply-To: <202001062044.006KiIPY023871@freefriends.org> References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> <1ingL0-5g6-00@marmaro.de> <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu> <3958ec66-c5c0-e1bc-1476-2195907816b3@case.edu> <49E33BA0-C482-4A95-BF2B-2107C661D76B@coraid.com> <202001061546.006Fk6Fb012760@freefriends.org> <202001062044.006KiIPY023871@freefriends.org> Message-ID: On Mon, Jan 6, 2020 at 3:44 PM wrote > > Time to move into the 21st century. Tcsh has been obsolete for decades. > Burned into the ROMs in my fingers :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Tue Jan 7 07:35:50 2020 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 7 Jan 2020 08:35:50 +1100 (EST) Subject: [TUHS] shell comment chars In-Reply-To: <7D7C9DDB-1ED3-4BD3-98C1-BD81CB1BA334@quintile.net> References: <7D7C9DDB-1ED3-4BD3-98C1-BD81CB1BA334@quintile.net> Message-ID: On Mon, 6 Jan 2020, Steve Simon wrote: > i remember the continual annoyance of unpacking shar files starting with > hash comments : only on ed7. in the end i wrote a trivial sed to remove > them called unshar. A "safe" version of which was posted to USENET; why would you run someone's random script? -- Dave From clemc at ccc.com Tue Jan 7 07:38:23 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 6 Jan 2020 16:38:23 -0500 Subject: [TUHS] wump.c for v6 In-Reply-To: References: <42cf63eb-d51e-d1ab-34ed-fbff94e18999@gmail.com> <682F5EA8-A1D2-4A5A-933F-C46B3631030E@gmail.com> Message-ID: Some day .... So I took a peak at the V5 crt0.s and guess what -- it matches! On Mon, Jan 6, 2020 at 4:08 PM Clem Cole wrote: > You got my curiosity up and found the V5 and V6 source code (I did not > have V4 easy to get, where I am today) ;-) > > A big clue of it being C will be having crt0.s (below) in the first few > bytes of the disassembled code. We see the a.out header (i.e. start at > offset 20 for the code) and look what's there. I'm going to guess that is > at 046 is the address of _main, from the call instruction at address 034. > The Trap 1 is a sys exit @ address 044. > But .. the V6 crt0.s source has a call to _exit, which is lacking in the > binary below. So it means that the binary was not created with the C > runtime and probably not the v6 C compiler in the sources. So I took a > peak at the V6 crt0.s and guess what -- it matches! > > So, I'm going to guess the binary was compiled and linked with an earlier > compiler. Ao ... if I had to guess, the programs are similar, but possibly > different. > > % more wump.das > ; > ; pdp11dasm version 0.0.3 > ; disassembly of wump > ; > 000000: 000407 br 20 ; .. > ; > 000002: 005334 dec @(r4)+ ; \. > 000004: 004524 jsr r5,(r4)+ ; T. > 000006: 002312 bge 37777777634 ; J. > 000010: 000000 halt ; .. > 000012: 000000 halt ; .. > 000014: 000000 halt ; .. > ; > 000016: 000001 wait ; .. > 000020: 170011 setd ; .p > 000022: 010600 mov r6,r0 ; .. > 000024: 011046 mov (r0),-(r6) ; &. > 000026: 005720 tst (r0)+ ; P. > 000030: 010066 000002 mov r0,2(r6) ; 6... > 000034: 004767 000006 call 46 ; w... > 000040: 022626 cmp (r6)+,(r6)+ ; .% > 000042: 005000 clr r0 ; .. > 000044: 104401 trap 1 ; .. > 000046: 004567 005174 jsr r5,5246 ; w.|. > 000052: 005746 tst -(r6) ; f. > 000054: 012716 011230 mov #11230,(r6) ; N... > 000060: 004737 002776 call @#2776 ; _.~. > 000064: 004767 002262 call 2352 ; w.2. > 000070: 022700 000171 cmp #171,r0 ; @%y. > 000074: 001027 bne 154 ; .. > 000076: 005004 clr r4 ; .. > 000100: 010400 mov r4,r0 ; .. > 000102: 006300 asl r0 ; @. > 000104: 005760 005334 tst 5334(r0) ; p.\. > 000110: 001421 beq 154 ; .. > 000112: 032704 000001 bit #1,r4 ; D5.. > 000116: 001403 beq 126 ; .. > 000120: 012716 000024 mov #24,(r6) ; N... > 000124: 000402 br 132 ; .. > ; > 000126: 012716 000003 mov #3,(r6) ; N... > 000132: 010400 mov r4,r0 ; .. > 000134: 006300 asl r0 ; @. > 000136: 016046 005334 mov 5334(r0),-(r6) ; &.\. > 000142: 004737 002776 call @#2776 ; _.~. > > > > > > V6: s4/crt0.s: > / C runtime startoff > > .globl savr5 > .globl _exit > > .globl _main > > start: > setd > mov sp,r0 > mov (r0),-(sp) > tst (r0)+ > mov r0,2(sp) > jsr pc,_main > mov r0,(sp) > jsr pc,*$_exit > sys exit > > .bss > savr5: .=.+2 > > V5: s4/crt0.s: > / C runtime startoff > > .globl savr5 > > .globl _main > > start: > setd > mov sp,r0 > mov (r0),-(sp) > tst (r0)+ > mov r0,2(sp) > jsr pc,_main > cmp (sp)+,(sp)+ > clr r0 > sys exit > > .bss > savr5: .=.+2 > > On Mon, Jan 6, 2020 at 1:48 PM Warner Losh wrote: > >> >> >> On Mon, Jan 6, 2020 at 11:38 AM Will Senn wrote: >> >>> On 1/6/20 12:29 PM, Warner Losh wrote: >>> >>> The good news is that disassembly will tell you right away if it was >>> written in C or not. >>> >>> >>> OK. I give up. How? >>> >> >> Generally, the C compiler generates code that's quite distinctive (at >> least PCC does, not sure about Dennis' compiler). People writing free >> assembler tend to do really weird things for function entry / return. >> >> And it will likely tell you if it's some weird wrapper around another >> binary, though that wasn't too common at bell labs. >> >> Warner >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chet.ramey at case.edu Tue Jan 7 07:55:55 2020 From: chet.ramey at case.edu (Chet Ramey) Date: Mon, 6 Jan 2020 16:55:55 -0500 Subject: [TUHS] sh: cmd | >file In-Reply-To: References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> <1ingL0-5g6-00@marmaro.de> <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu> <3958ec66-c5c0-e1bc-1476-2195907816b3@case.edu> <49E33BA0-C482-4A95-BF2B-2107C661D76B@coraid.com> <202001061546.006Fk6Fb012760@freefriends.org> Message-ID: On 1/6/20 4:29 PM, Dave Horsfall wrote: > On Mon, 6 Jan 2020, arnold at skeeve.com wrote: > >> Would anyone who uses Bash regularly, both interactively and >> for scripting, really want to go back to using the V7 sh >> for production work? > > I have never used all the fancy stuff in BASH such as the arithmetic > functions; I still use "expr" etc for portability. Portability to what? The POSIX $((...)) arithmetic expansion is widely implemented and near-universally available. Some of the other things are more esoteric, but you should be able to increase your expectation to POSIX features and still be sufficiently portable. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From brad at anduin.eldar.org Tue Jan 7 07:39:05 2020 From: brad at anduin.eldar.org (Brad Spencer) Date: Mon, 06 Jan 2020 16:39:05 -0500 Subject: [TUHS] sh: cmd | >file In-Reply-To: (message from Clem Cole on Mon, 6 Jan 2020 16:32:24 -0500) Message-ID: Clem Cole writes: > On Mon, Jan 6, 2020 at 3:44 PM wrote > >> >> Time to move into the 21st century. Tcsh has been obsolete for decades. >> > Burned into the ROMs in my fingers :-) I am glad that I am not alone ... I tend to write older style sh scripts and try to use tcsh as an interactive shell when I can. BTW - tcsh is still being updated ... -- Brad Spencer - brad at anduin.eldar.org - KC8VKS - http://anduin.eldar.org From imp at bsdimp.com Tue Jan 7 08:14:50 2020 From: imp at bsdimp.com (Warner Losh) Date: Mon, 6 Jan 2020 15:14:50 -0700 Subject: [TUHS] wump.c for v6 In-Reply-To: References: <42cf63eb-d51e-d1ab-34ed-fbff94e18999@gmail.com> <682F5EA8-A1D2-4A5A-933F-C46B3631030E@gmail.com> Message-ID: You have V4 sources? The TUHS archive doesn't have them that I've seen... Warner On Mon, Jan 6, 2020, 2:38 PM Clem Cole wrote: > Some day .... So I took a peak at the V5 crt0.s and guess what -- it > matches! > > On Mon, Jan 6, 2020 at 4:08 PM Clem Cole wrote: > >> You got my curiosity up and found the V5 and V6 source code (I did not >> have V4 easy to get, where I am today) ;-) >> >> A big clue of it being C will be having crt0.s (below) in the first few >> bytes of the disassembled code. We see the a.out header (i.e. start at >> offset 20 for the code) and look what's there. I'm going to guess that is >> at 046 is the address of _main, from the call instruction at address 034. >> The Trap 1 is a sys exit @ address 044. >> But .. the V6 crt0.s source has a call to _exit, which is lacking in the >> binary below. So it means that the binary was not created with the C >> runtime and probably not the v6 C compiler in the sources. So I took a >> peak at the V6 crt0.s and guess what -- it matches! >> >> So, I'm going to guess the binary was compiled and linked with an earlier >> compiler. Ao ... if I had to guess, the programs are similar, but possibly >> different. >> >> % more wump.das >> ; >> ; pdp11dasm version 0.0.3 >> ; disassembly of wump >> ; >> 000000: 000407 br 20 ; .. >> ; >> 000002: 005334 dec @(r4)+ ; \. >> 000004: 004524 jsr r5,(r4)+ ; T. >> 000006: 002312 bge 37777777634 ; J. >> 000010: 000000 halt ; .. >> 000012: 000000 halt ; .. >> 000014: 000000 halt ; .. >> ; >> 000016: 000001 wait ; .. >> 000020: 170011 setd ; .p >> 000022: 010600 mov r6,r0 ; .. >> 000024: 011046 mov (r0),-(r6) ; &. >> 000026: 005720 tst (r0)+ ; P. >> 000030: 010066 000002 mov r0,2(r6) ; 6... >> 000034: 004767 000006 call 46 ; w... >> 000040: 022626 cmp (r6)+,(r6)+ ; .% >> 000042: 005000 clr r0 ; .. >> 000044: 104401 trap 1 ; .. >> 000046: 004567 005174 jsr r5,5246 ; w.|. >> 000052: 005746 tst -(r6) ; f. >> 000054: 012716 011230 mov #11230,(r6) ; N... >> 000060: 004737 002776 call @#2776 ; _.~. >> 000064: 004767 002262 call 2352 ; w.2. >> 000070: 022700 000171 cmp #171,r0 ; @%y. >> 000074: 001027 bne 154 ; .. >> 000076: 005004 clr r4 ; .. >> 000100: 010400 mov r4,r0 ; .. >> 000102: 006300 asl r0 ; @. >> 000104: 005760 005334 tst 5334(r0) ; p.\. >> 000110: 001421 beq 154 ; .. >> 000112: 032704 000001 bit #1,r4 ; D5.. >> 000116: 001403 beq 126 ; .. >> 000120: 012716 000024 mov #24,(r6) ; N... >> 000124: 000402 br 132 ; .. >> ; >> 000126: 012716 000003 mov #3,(r6) ; N... >> 000132: 010400 mov r4,r0 ; .. >> 000134: 006300 asl r0 ; @. >> 000136: 016046 005334 mov 5334(r0),-(r6) ; &.\. >> 000142: 004737 002776 call @#2776 ; _.~. >> >> >> >> >> >> V6: s4/crt0.s: >> / C runtime startoff >> >> .globl savr5 >> .globl _exit >> >> .globl _main >> >> start: >> setd >> mov sp,r0 >> mov (r0),-(sp) >> tst (r0)+ >> mov r0,2(sp) >> jsr pc,_main >> mov r0,(sp) >> jsr pc,*$_exit >> sys exit >> >> .bss >> savr5: .=.+2 >> >> V5: s4/crt0.s: >> / C runtime startoff >> >> .globl savr5 >> >> .globl _main >> >> start: >> setd >> mov sp,r0 >> mov (r0),-(sp) >> tst (r0)+ >> mov r0,2(sp) >> jsr pc,_main >> cmp (sp)+,(sp)+ >> clr r0 >> sys exit >> >> .bss >> savr5: .=.+2 >> >> On Mon, Jan 6, 2020 at 1:48 PM Warner Losh wrote: >> >>> >>> >>> On Mon, Jan 6, 2020 at 11:38 AM Will Senn wrote: >>> >>>> On 1/6/20 12:29 PM, Warner Losh wrote: >>>> >>>> The good news is that disassembly will tell you right away if it was >>>> written in C or not. >>>> >>>> >>>> OK. I give up. How? >>>> >>> >>> Generally, the C compiler generates code that's quite distinctive (at >>> least PCC does, not sure about Dennis' compiler). People writing free >>> assembler tend to do really weird things for function entry / return. >>> >>> And it will likely tell you if it's some weird wrapper around another >>> binary, though that wasn't too common at bell labs. >>> >>> Warner >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at bitblocks.com Tue Jan 7 08:10:35 2020 From: bakul at bitblocks.com (Bakul Shah) Date: Mon, 06 Jan 2020 14:10:35 -0800 Subject: [TUHS] sh: cmd | >file In-Reply-To: Your message of "Tue, 07 Jan 2020 08:29:30 +1100." References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> <1ingL0-5g6-00@marmaro.de> <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu> <3958ec66-c5c0-e1bc-1476-2195907816b3@case.edu> <49E33BA0-C482-4A95-BF2B-2107C661D76B@coraid.com> <202001061546.006Fk6Fb012760@freefriends.org> Message-ID: <20200106221042.DB693156E42D@mail.bitblocks.com> On Tue, 07 Jan 2020 08:29:30 +1100 Dave Horsfall wrote: > On Mon, 6 Jan 2020, arnold at skeeve.com wrote: > > > Would anyone who uses Bash regularly, both interactively and > > for scripting, really want to go back to using the V7 sh > > for production work? > > I have never used all the fancy stuff in BASH such as the arithmetic > functions; I still use "expr" etc for portability. > > My favourite shell is still ZSH (the alternative was CSH, and my views on > that POS are well known) because I started using it long before BASH, and > even then I use a fraction of its power. I did dabble with KSH, though (I > needed command editing and history). csh was more convenient as an interactive shell but it was not good for writing scripts & I always used /bin/sh for scripts. I switched from csh to zsh almost since the time it was first posted to alt.sources - over 29 years ago! From dave at horsfall.org Tue Jan 7 08:22:24 2020 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 7 Jan 2020 09:22:24 +1100 (EST) Subject: [TUHS] sh: cmd | >file In-Reply-To: References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> <1ingL0-5g6-00@marmaro.de> <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu> <3958ec66-c5c0-e1bc-1476-2195907816b3@case.edu> <49E33BA0-C482-4A95-BF2B-2107C661D76B@coraid.com> <202001061546.006Fk6Fb012760@freefriends.org> Message-ID: On Mon, 6 Jan 2020, Chet Ramey wrote: >> I have never used all the fancy stuff in BASH such as the arithmetic >> functions; I still use "expr" etc for portability. > > Portability to what? The POSIX $((...)) arithmetic expansion is widely > implemented and near-universally available. As I said, I never bothered to learn "$((...))" because "expr" works just fine. And I might come across an old machine at some time; I come from the school of "Make it work before making it pretty" and I extend that to backwards compatibility. And "expr" is burned into my brain :-) > Some of the other things are more esoteric, but you should be able to > increase your expectation to POSIX features and still be sufficiently > portable. I might get around to it, but at 67 I may not have much time (or incentive)... Besides, programming is only a hobby for me, as I'm long retired. -- Dave From dave at horsfall.org Tue Jan 7 08:50:33 2020 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 7 Jan 2020 09:50:33 +1100 (EST) Subject: [TUHS] # (was Re: sh: cmd | >file) In-Reply-To: <202001060630.0066U7U7023760@cuzuco.com> References: <202001060630.0066U7U7023760@cuzuco.com> Message-ID: On Mon, 6 Jan 2020, Brian Walden wrote: > csh(1) was wrtten around 1978 and yes # as a comment was only for > scrtipts, think it was why would you need to comment interactively? Why would you *not* want to? You've just made "#" asymmetric in its behaviour; in the meantime the parser just sees an unescaped "#" and ignores everything after that, without regard to context. You might also be using "script" e.g. script blah blah # Now here I do something funky *really* funky stuff ^D [...] > Also before you say wait! ALGOL uses # as comment and is older than > Kernighan' ratfor(1). [...] Funny; I recall ALGOL using "comment ... ;" or was that ALGOLW (which I loved using; I wish I still had my ALGOLW book)? -- Dave From crossd at gmail.com Tue Jan 7 08:52:41 2020 From: crossd at gmail.com (Dan Cross) Date: Mon, 6 Jan 2020 17:52:41 -0500 Subject: [TUHS] sh: cmd | >file In-Reply-To: References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> <1ingL0-5g6-00@marmaro.de> <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu> <3958ec66-c5c0-e1bc-1476-2195907816b3@case.edu> <49E33BA0-C482-4A95-BF2B-2107C661D76B@coraid.com> <202001061546.006Fk6Fb012760@freefriends.org> Message-ID: On Mon, Jan 6, 2020 at 4:56 PM Chet Ramey wrote: > On 1/6/20 4:29 PM, Dave Horsfall wrote: > > On Mon, 6 Jan 2020, arnold at skeeve.com wrote: > > > >> Would anyone who uses Bash regularly, both interactively and > >> for scripting, really want to go back to using the V7 sh > >> for production work? > > > > I have never used all the fancy stuff in BASH such as the arithmetic > > functions; I still use "expr" etc for portability. > > Portability to what? The POSIX $((...)) arithmetic expansion is widely > implemented and near-universally available. > > Some of the other things are more esoteric, but you should be able to > increase your expectation to POSIX features and still be sufficiently > portable. > Huh. I've been in this "use the old stuff for portability" camp for some time, but now that you mention it....I can't think of any systems I use that require resorting to old-style shell-isms. What an interesting epiphany. It reminds me of the time when first I realized that continuing to write K&R-style C was no longer necessary, as everything that I used had an ANSI-compatible compiler and supported function prototypes. Seeing backticks in the rearview mirror is a welcome change. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Tue Jan 7 09:46:10 2020 From: will.senn at gmail.com (Will Senn) Date: Mon, 6 Jan 2020 17:46:10 -0600 Subject: [TUHS] wump.c for v6 In-Reply-To: References: <42cf63eb-d51e-d1ab-34ed-fbff94e18999@gmail.com> <682F5EA8-A1D2-4A5A-933F-C46B3631030E@gmail.com> Message-ID: Sent from my iPhone > On Jan 6, 2020, at 3:38 PM, Clem Cole wrote: > > Some day .... So I took a peak at the V5 crt0.s and guess what -- it matches! Awesome. Thanks for sharing your approach to the disasm. On another note,You said you looked in v5 and v6 source code? I looked at tuhs and didn’t see anything earlier than v7. Where did you find them? Thanks, Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Tue Jan 7 10:39:39 2020 From: imp at bsdimp.com (Warner Losh) Date: Mon, 6 Jan 2020 17:39:39 -0700 Subject: [TUHS] # (was Re: sh: cmd | >file) In-Reply-To: References: <202001060630.0066U7U7023760@cuzuco.com> Message-ID: On Mon, Jan 6, 2020 at 3:51 PM Dave Horsfall wrote: > On Mon, 6 Jan 2020, Brian Walden wrote: > > > csh(1) was wrtten around 1978 and yes # as a comment was only for > > scrtipts, think it was why would you need to comment interactively? > > Why would you *not* want to? You've just made "#" asymmetric in its > behaviour; in the meantime the parser just sees an unescaped "#" and > ignores everything after that, without regard to context. > > You might also be using "script" e.g. > > script > blah blah > # Now here I do something funky > *really* funky stuff > ^D > Or you might have cut and paste the commands from a script to test something, or to redo something by hand that failed for some reason. Warner > [...] > > > Also before you say wait! ALGOL uses # as comment and is older than > > Kernighan' ratfor(1). [...] > > Funny; I recall ALGOL using "comment ... ;" or was that ALGOLW (which I > loved using; I wish I still had my ALGOLW book)? > > -- Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Tue Jan 7 10:40:26 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 6 Jan 2020 19:40:26 -0500 (EST) Subject: [TUHS] wump.c for v6 Message-ID: <20200107004026.E7E5018C07B@mercury.lcs.mit.edu> > From: Will Senn > On another note,You said you looked in v5 and v6 source code? I looked > at tuhs and didn't see anything earlier than v7. Where did you find > them? Huh? https://www.tuhs.org/cgi-bin/utree.pl Noel From imp at bsdimp.com Tue Jan 7 10:44:20 2020 From: imp at bsdimp.com (Warner Losh) Date: Mon, 6 Jan 2020 17:44:20 -0700 Subject: [TUHS] wump.c for v6 In-Reply-To: <20200107004026.E7E5018C07B@mercury.lcs.mit.edu> References: <20200107004026.E7E5018C07B@mercury.lcs.mit.edu> Message-ID: On Mon, Jan 6, 2020 at 5:41 PM Noel Chiappa wrote: > > From: Will Senn > > > On another note,You said you looked in v5 and v6 source code? I > looked > > at tuhs and didn't see anything earlier than v7. Where did you find > > them? > > Huh? https://www.tuhs.org/cgi-bin/utree.pl There's no wupus source before V7. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Tue Jan 7 10:50:18 2020 From: athornton at gmail.com (Adam Thornton) Date: Mon, 6 Jan 2020 17:50:18 -0700 Subject: [TUHS] sh: cmd | >file In-Reply-To: References: <202001040258.0042wuic1359237@mail.cs.dartmouth.edu> <1ingL0-5g6-00@marmaro.de> <854eca1c-e5e5-5d8b-f5af-30cd1735096e@case.edu> <3958ec66-c5c0-e1bc-1476-2195907816b3@case.edu> <49E33BA0-C482-4A95-BF2B-2107C661D76B@coraid.com> <202001061546.006Fk6Fb012760@freefriends.org> Message-ID: <572C7C41-0B92-461C-88F9-5EC5436A66F5@gmail.com> > On Jan 6, 2020, at 2:55 PM, Chet Ramey wrote: > > On 1/6/20 4:29 PM, Dave Horsfall wrote: >> On Mon, 6 Jan 2020, arnold at skeeve.com wrote: >>> Would anyone who uses Bash regularly, both interactively and >>> for scripting, really want to go back to using the V7 sh >>> for production work? >> I have never used all the fancy stuff in BASH such as the arithmetic >> functions; I still use "expr" etc for portability. > > Portability to what? The POSIX $((...)) arithmetic expansion is widely > implemented and near-universally available. > > Some of the other things are more esoteric, but you should be able to > increase your expectation to POSIX features and still be sufficiently > portable. > Portability to v7, of course! I mean, I’m joking, but also not. I felt like v7 might be enough of a daily driver that I could port some fun stuff to it, but…damn, even ex/vi 3.x is huge, jove will take a lot of work, and I can’t find a minimalist screen editor in K&R C. The best I’ve managed is TE but although there is presumably a Unix port, I couldn’t find it. Porting termcap and curses was easy, but….the whole reason I want them, initially, is so that I don’t have to use ed. If anyone knows of a small screen editor that will build easily on v7 I want to know about it. This is in contrast to 2.11BSD, where, yeah, it’s just Unix, and especially with a TCP/IP stack, is completely usable. The PDP-11’s 64K address space is constraining and (as it turned out) influences the way I write programs—for my menu front end for ZIP, I started with my usual technique of making a struct with all the fields I’d want for my menu structure, and a linked list of those things, but that turned out to be a hog and a simple **char plus some utility functions to index the elements ended up being completely adequate. Adam From jnc at mercury.lcs.mit.edu Tue Jan 7 11:58:48 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 6 Jan 2020 20:58:48 -0500 (EST) Subject: [TUHS] wump.c for v6 Message-ID: <20200107015848.B269818C07B@mercury.lcs.mit.edu> > From: Warner Losh > There's no wupus source before V7. If you look at Clem's original message: >> From: Clem Cole >> Date: Mon, 6 Jan 2020 16:08:50 -0500 >> You got my curiosity up and found the V5 and V6 source code (the one Will was replying to), Clem's talking about the source to crt0.s, etc. Noel From doug at cs.dartmouth.edu Tue Jan 7 12:31:44 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Mon, 06 Jan 2020 21:31:44 -0500 Subject: [TUHS] screen editors Message-ID: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU> > but…damn, even ex/vi 3.x is huge It was so excesssive right from the start that I refused to use it. Sam was the first screen editor that I deemed worthwhile, and I still use it today. Doug From brantley at coraid.com Tue Jan 7 12:37:00 2020 From: brantley at coraid.com (Brantley Coile) Date: Tue, 7 Jan 2020 02:37:00 +0000 Subject: [TUHS] screen editors In-Reply-To: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU> References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU> Message-ID: <65E7E540-0889-4B3C-BAD3-F7A433608577@coraid.com> Well said. I do as well. > On Jan 6, 2020, at 9:31 PM, Doug McIlroy wrote: > >> but…damn, even ex/vi 3.x is huge > > It was so excesssive right from the start that I refused to use it. > Sam was the first screen editor that I deemed worthwhile, and I > still use it today. > > Doug From lm at mcvoy.com Tue Jan 7 12:38:34 2020 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 6 Jan 2020 18:38:34 -0800 Subject: [TUHS] screen editors In-Reply-To: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU> References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU> Message-ID: <20200107023834.GN20269@mcvoy.com> On Mon, Jan 06, 2020 at 09:31:44PM -0500, Doug McIlroy wrote: > > but???damn, even ex/vi 3.x is huge > > It was so excesssive right from the start that I refused to use it. > Sam was the first screen editor that I deemed worthwhile, and I > still use it today. I grew up on 4MB Suns. Emacs was "8 megs and constantly swapping". I thought vi was fine though I did do a lot with xvi (I think that was what it was called) and I hacked it to use mmap to look at the file. I had to do something about strings to make that work, don't remember, but it worked and I could vi 4MB log files and search them pretty fast. I'm a vi guy to this day. Love it. From will.senn at gmail.com Tue Jan 7 13:27:22 2020 From: will.senn at gmail.com (Will Senn) Date: Mon, 6 Jan 2020 21:27:22 -0600 Subject: [TUHS] TUHS Digest, Vol 50, Issue 8 In-Reply-To: References: Message-ID: <15CD334E-AC18-48B1-B762-39D744AB7542@gmail.com> > >> From: Warner Losh > >> There's no wupus source before V7. > > If you look at Clem's original message: > >>> From: Clem Cole >>> Date: Mon, 6 Jan 2020 16:08:50 -0500 > >>> You got my curiosity up and found the V5 and V6 source code > > (the one Will was replying to), Clem's talking about the source to crt0.s, > etc. > > Noel > Sorry. I could have been clearer. I thought Clem was saying that he found the Wumpus code in v5/v6. Now, I see that he was just talking about the crt files. When I said I couldn’t find the source prior to v7, I meant the wumpus source :). On another note, porting the v7 code to MacOS is tricky, lots of minor differences, but I’m giving it a go. Prolly easier to just figure out what it’s supposed to do and do it with modern idioms, but it’s a fun puzzle to try to replicate the same functionality with only minor adjustments. Will From tuhs at cuzuco.com Tue Jan 7 14:49:18 2020 From: tuhs at cuzuco.com (Brian Walden) Date: Mon, 6 Jan 2020 23:49:18 -0500 (EST) Subject: [TUHS] sh: cmd | >file Message-ID: <202001070449.0074nIn2017611@cuzuco.com> Doug McIlroy wrote: >Brian Walden's discussion of sh #, etc, is right on. >However, his etymology for unary * in C can be >pushed back at least to 1959. * was used for >indirect addressing in SAP, the assembler for >the IBM 7090. Thank you for both the confirmation and also that history update. -Brian From tuhs at cuzuco.com Tue Jan 7 15:03:39 2020 From: tuhs at cuzuco.com (Brian Walden) Date: Tue, 7 Jan 2020 00:03:39 -0500 (EST) Subject: [TUHS] sh: cmd | >file Message-ID: <202001070503.00753dBd029629@cuzuco.com> Clem Cole wrote: >A heretic!! Believers all know '*Bourne to Program, Type with Joy' *and* >'One true bracing style' *are the two most important commandments of UNIX >programmer! > >Seriously, I still write my scripts as v7 and use (t)csh as my login shell >on all my UNIX boxes ;-) > >Clem You know what's amazing? that Bill Joy code to launch either csh or bourne shell based on the first character of teh file is still in tcsh codebase today. It even has #! support just in case your kernel does not. However this code never gets run as who write scripts without #! anymore .. but here's a little test --- $ tcsh You have 2 mail messages. > cat x1.sh PATH=/bin echo $SHELL > ./x1.sh /bin/sh > cat x2.csh # setenv path /bin echo $shell > ./x2.csh /usr/local/bin/tcsh > exit you can see it in https://github.com/tcsh-org/tcsh/blob/master/sh.exec.c -Brian From dave at horsfall.org Tue Jan 7 16:19:27 2020 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 7 Jan 2020 17:19:27 +1100 (EST) Subject: [TUHS] screen editors In-Reply-To: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU> References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU> Message-ID: I don't recall the exact details, but there was once an editor called "em" (Editor for Mortals). I remember thinking: what sort of an idiot would call it that, with the "e" and "r" keys adjacent to each other? I wonder how many files were lost that way... -- Dave From thomas.paulsen at firemail.de Tue Jan 7 18:24:03 2020 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Tue, 07 Jan 2020 09:24:03 +0100 Subject: [TUHS] screen editors In-Reply-To: References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU> Message-ID: <5a2152e0cbaaf23fc31a51f984a5ef9d@firemail.de> >I don't recall the exact details, but there was once an editor called "em" >(Editor for Mortals). I remember thinking: what sort of an idiot would >call it that, with the "e" and "r" keys adjacent to each >other? I wonder how many files were lost that way... you can download, build and use em making immediately clear that em was much easier to use than ed. Nevertheless em was only (another) step in between ed and vi. http://pgas.freeshell.org/C/em/ http://www.tuhs.org/Archive/Applications/Em_Editor/ http://www.coulouris.net/cs_history/em_story/emsource/ From ullbeking at andrewnesbit.org Tue Jan 7 19:43:49 2020 From: ullbeking at andrewnesbit.org (ullbeking at andrewnesbit.org) Date: Tue, 7 Jan 2020 09:43:49 +0000 (UTC) Subject: [TUHS] screen editors In-Reply-To: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU> References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU> Message-ID: <17372ca2-0498-4320-a933-5ac522eabb2b@localhost> 7 Jan 2020 02:32:11 Doug McIlroy : > Sam was the first screen editor that I deemed worthwhile, and I > still use it today. I would like to experiment with Sam and run it on various *nix operating systems. There seems to be many ports. Do I need to install some kind of Plan 9 emulation layer (in user space), which Sam builds and runs on? Obviously I'm referring to Russ Cox's libraries and user space tools. Is it necessary to have a p9 environment to gain the most advantage of a tool like Sam? Or, is it possible for it still to function well as a transplant in a new environment such as *nix? In that second case, what are the well ported versions of Sam that build and run directly on the target environment? Andrew From wkt at tuhs.org Tue Jan 7 20:56:15 2020 From: wkt at tuhs.org (Warren Toomey) Date: Tue, 7 Jan 2020 20:56:15 +1000 Subject: [TUHS] Unix/World Magazines Message-ID: <20200107105615.GA16081@minnie.tuhs.org> All, I've uploaded 13 Unix/World magazines from 1984-85 to archive.org. They are at: https://archive.org/search.php?query=title%3A%28Unix%20World%29 Cheers, Warren From crossd at gmail.com Wed Jan 8 00:53:37 2020 From: crossd at gmail.com (Dan Cross) Date: Tue, 7 Jan 2020 09:53:37 -0500 Subject: [TUHS] screen editors In-Reply-To: <17372ca2-0498-4320-a933-5ac522eabb2b@localhost> References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU> <17372ca2-0498-4320-a933-5ac522eabb2b@localhost> Message-ID: On Tue, Jan 7, 2020 at 4:50 AM wrote: > 7 Jan 2020 02:32:11 Doug McIlroy : > > Sam was the first screen editor that I deemed worthwhile, and I > > still use it today. > > I would like to experiment with Sam and run it on various *nix operating > systems. There seems to be many ports. > > Do I need to install some kind of Plan 9 emulation layer (in user space), > which Sam builds and runs on? Obviously I'm referring to Russ Cox's > libraries and user space tools. > > Is it necessary to have a p9 environment to gain the most advantage of a > tool like Sam? Or, is it possible for it still to function well as a > transplant in a new environment such as *nix? > > In that second case, what are the well ported versions of Sam that build > and run directly on the target environment? > It is not necessary to have a plan 9 environment to take advantage of Sam, and there was once a port for Unix that worked outside of the usual Plan 9 world. Indeed, Sam got its start on Unix. However, I dare say that the best port to use is the one from plan9port: Sam continued to evolve on plan9, if only gaining incremental improvements after the early Unix years. By using the plan9port version, you'll pick up on those changes (though I can't really enumerate them anymore). - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Jan 8 01:03:57 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 7 Jan 2020 10:03:57 -0500 Subject: [TUHS] screen editors In-Reply-To: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU> References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU> Message-ID: On Mon, Jan 6, 2020 at 9:32 PM Doug McIlroy wrote: > > but…damn, even ex/vi 3.x is huge > > It was so excesssive right from the start that I refused to use it. > Sam was the first screen editor that I deemed worthwhile, and I > still use it today. > > Doug > Oh so true; although the early version from 2BSD was smaller. I bet my fingers are still only using much of that subset ;-) But I certainly watched it grow and grow over the years. I'm really not so sure about 'vim' -- it has become as much of a feature sink as emacs. FWIW: When I went from PDP-10 land to UNIX, I learned ed for 5th edition and somewhat pined for a screen editor. Soon after upgrading to 6th edition at CMU, we found a visual editor called Fred - the Friendly Editor, from Cornell IIRC (I think it's on the original USENIX tape but I don't remember how we got it). I had to hack in the Perkin-Elmer Fox terminal support, but it was a superset of V6 ed so a pretty trivial learning curve. However, since Fred had the terminal support compiled it and when I went to Tektronix a few years later, I had to add a whole bunch of new terminals and we quickly started running into the address issues on the 11/40 class systems. Mark Bales was working as a summer student and had brought 2BSD with him (inc. vi and csh). Poof, thanks to termcap ex/vi could run on most every terminal we already had (in some manner) which Fred could not. And because of termcap not having to keep the code for the other terminals not being used in memory, even though the editor itself was more complex, we could just squeeze that version on an 11/40 class system running Seventh Edition. That made me take notice. Again it was ed under the covers so the transition was easy. I was pretty impressed with termcap, and soon thereafter I found myself sending Mary Ann a couple of new terminal definitions for some missing Tek terminals like Tek 4025. With the VAX, and new ex/vi shows up and it would not run on the PDP-11's, I was disappointed. But the old version still worked and I had started to notice that a *version of **vi *had started to show up on most everything I used, from VMS to the Cray's and later the PCs, so really I never looked back. It became the most portable editor for my fingers as I had long ago forgotten EMACS (even when we got Vaxen and Gosling EMACS shows up on the UNIX scene, I never bother to really relearn it - I can use it if I have too, but not as well as vi these days). -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Jan 8 01:24:48 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 7 Jan 2020 10:24:48 -0500 Subject: [TUHS] # (was Re: sh: cmd | >file) In-Reply-To: References: <202001060630.0066U7U7023760@cuzuco.com> Message-ID: On Mon, Jan 6, 2020 at 5:51 PM Dave Horsfall wrote: > Funny; I recall ALGOL using "comment ... ;" or was that ALGOLW (which I > loved using; I wish I still had my ALGOLW book)? > Algol-W From, the Sites book, (Page 10, Section 1 'Terminology) [Dave, I'll send you the PDF offline]. The symbol *comment* followed by any sequence of characters not -containing semicolons, followed by a semicolon, is called a *comment*. A comment has no effect on the meaning of a program, and is ignored during execution of the program. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.paulsen at firemail.de Wed Jan 8 01:50:44 2020 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Tue, 07 Jan 2020 16:50:44 +0100 Subject: [TUHS] screen editors In-Reply-To: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU> References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU> Message-ID: >It was so excesssive right from the start that I refused to use it. >Sam was the first screen editor that I deemed worthwhile, and I >still use it today. my sam build is more than 2 times bigger than Gunnar Ritter's vi (or Steve Kirkendall's elvis) and even bigger than Bram Moolenaar's vim. From arnold at skeeve.com Wed Jan 8 02:30:53 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 07 Jan 2020 09:30:53 -0700 Subject: [TUHS] screen editors In-Reply-To: <20200107023834.GN20269@mcvoy.com> References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU> <20200107023834.GN20269@mcvoy.com> Message-ID: <202001071630.007GUrBj030452@freefriends.org> Larry McVoy wrote: > I'm a vi guy to this day. Love it. In the summer of '82 I did some contract programming at Southern Bell on a PDP-11 running USG Unix 4.0. It had a screen editor called 'se' that I only ever saw there, written somewhere in the Bell System and squeezed to run on an -11. Anyone know anything about it? Unrelated, Georgia Tech had the 'se' screen editor as part of the Software Tools Subsystem, based on the 'ed' in the Software Tools book. This was later ported to Unix. I modified that code to use curses/termlib and posted it to USENET. It's been updated and is available from https://github.com/se-editor/se and http://se-editor.org is the home page. (Thomas Cort IIRC did that work.) What's funny is that in doing the work to get 'se' running on Georgia Tech's Vax, I had to learn vi. By the time I was done, vi had become my main editor and had burned itself into my finger's ROMs. Arnold From rich.salz at gmail.com Wed Jan 8 02:38:56 2020 From: rich.salz at gmail.com (Richard Salz) Date: Tue, 7 Jan 2020 11:38:56 -0500 Subject: [TUHS] screen editors In-Reply-To: <202001071630.007GUrBj030452@freefriends.org> References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU> <20200107023834.GN20269@mcvoy.com> <202001071630.007GUrBj030452@freefriends.org> Message-ID: Any fans of the Rand Editor? https://github.com/blakemcbride/Rand-E-Editor And do folks here know of the TextEditors wiki at http://texteditors.org/cgi-bin/wiki.pl?HomePage ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Wed Jan 8 04:32:29 2020 From: crossd at gmail.com (Dan Cross) Date: Tue, 7 Jan 2020 13:32:29 -0500 Subject: [TUHS] screen editors In-Reply-To: <202001071630.007GUrBj030452@freefriends.org> References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU> <20200107023834.GN20269@mcvoy.com> <202001071630.007GUrBj030452@freefriends.org> Message-ID: On Tue, Jan 7, 2020 at 11:31 AM wrote: > Larry McVoy wrote: > > > I'm a vi guy to this day. Love it. > > In the summer of '82 I did some contract programming at Southern Bell > on a PDP-11 running USG Unix 4.0. It had a screen editor called 'se' > that I only ever saw there, written somewhere in the Bell System and > squeezed to run on an -11. Anyone know anything about it? > > Unrelated, Georgia Tech had the 'se' screen editor as part of the > Software Tools Subsystem, based on the 'ed' in the Software Tools book. > This was later ported to Unix. I modified that code to use curses/termlib > and posted it to USENET. It's been updated and is available from > https://github.com/se-editor/se and http://se-editor.org is the home > page. (Thomas Cort IIRC did that work.) > > What's funny is that in doing the work to get 'se' running on Georgia > Tech's Vax, I had to learn vi. By the time I was done, vi had become > my main editor and had burned itself into my finger's ROMs. > Ah, this reminds me of something. I assume you've read, "A Software Tools Sampler"? A few months ago, I started looking into screen update algorithms for a (frivolous) retro-computing time sink, er, I mean project. Naturally, Gosling's redisplay algorithm figured prominently, as it's famous and well-known. I looked at the Unix emacs code and it's not that hard to puzzle through, actually, despite the reputation and the (in)famous skull and crossbones comment. However, Gosling's code assumes that update commands all have uniform cost (cost here being proportional to the command's length) which, on real terminals, just isn't true. Meyers and Miller came up with several algorithms that take into account editing command cost, and produce potentially far-better solutions than Gosling's code, though limited by the inability at the time to quickly build suffix trees (this was about a decade before Ukkonen's algorithm); it's interesting that none of these algorithms take into account text attributes, which on most serial terminals are modal. Anyway, at least one of these algorithms was implemented in a modified version of `se`, as described in "A Software Tools Sampler." I guess Webb thought that was easier to work with than an existing editor? Perhaps these "se"s share a lineage? What's interesting to me is that redisplay algorithms were clearly an area of active research at one time, but interest seemed to dry up almost over night. One must presume that this evaporation of research activity had to do with the en mass migration to graphical workstations where the problems are different, and possibly with curses being "good enough" in e.g. an xterm. However, one can see some of the fruits of Miller's research in his later work in genomics. - Dan C. A few random references: Gosling, James, "A Redisplay Algorithm." https://dl.acm.org/doi/10.1145/872730.806463 Meyers, Eugene and Webb Miller, "A Simple Row Replacement Algorithm." https://dl.acm.org/doi/10.5555/52187.52188 Meyers, Eugene and Webb Miller, "Row Replacement Algorithm for Screen Editors." https://dl.acm.org/doi/10.1145/59287.59290 -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.paulsen at firemail.de Wed Jan 8 05:14:27 2020 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Tue, 07 Jan 2020 20:14:27 +0100 Subject: [TUHS] screen editors In-Reply-To: <202001071630.007GUrBj030452@freefriends.org> References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU> <20200107023834.GN20269@mcvoy.com> <202001071630.007GUrBj030452@freefriends.org> Message-ID: >What's funny is that in doing the work to get 'se' running on Georgia >Tech's Vax, I had to learn vi. By the time I was done, vi had become >my main editor and had burned itself into my finger's ROMs. I do ed/se occasionally for simple tasks, vim frequently , because it loads fast, and emacs for all bigger projects, beside liteide for golang. From rodrigosloop at gmail.com Wed Jan 8 05:35:36 2020 From: rodrigosloop at gmail.com (=?UTF-8?Q?Rodrigo_G=2E_L=C3=B3pez?=) Date: Tue, 7 Jan 2020 20:35:36 +0100 Subject: [TUHS] screen editors In-Reply-To: <17372ca2-0498-4320-a933-5ac522eabb2b@localhost> References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU> <17372ca2-0498-4320-a933-5ac522eabb2b@localhost> Message-ID: i like to use it natively as much as possible, especially the 9front edition with its usability (e.g. mouse chording) improvements. if that is not possible, i drawterm into some cpu or a local vm where i can get a little environment to work with whatever is at /mnt/term. it also has a powerful command language and structural regular expressions, and you can use your favorite unix tools on any piece of text you please. it has given me the best text editing and programming experience i've ever had. -rodri On Tue, Jan 7, 2020, 10:50 AM wrote: > > 7 Jan 2020 02:32:11 Doug McIlroy : > > Sam was the first screen editor that I deemed worthwhile, and I > > still use it today. > > I would like to experiment with Sam and run it on various *nix operating > systems. There seems to be many ports. > > Do I need to install some kind of Plan 9 emulation layer (in user space), > which Sam builds and runs on? Obviously I'm referring to Russ Cox's > libraries and user space tools. > > Is it necessary to have a p9 environment to gain the most advantage of a > tool like Sam? Or, is it possible for it still to function well as a > transplant in a new environment such as *nix? > > In that second case, what are the well ported versions of Sam that build > and run directly on the target environment? > > Andrew > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Wed Jan 8 05:57:40 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Tue, 07 Jan 2020 14:57:40 -0500 Subject: [TUHS] screen editors Message-ID: <202001071957.007JveQu169574@coolidge.cs.dartmouth.edu> McIlroy: > [vi] was so excesssive right from the start that I refused to use it. > Sam was the first screen editor that I deemed worthwhile, and I > still use it today. Paulsen: > my sam build is more than 2 times bigger than Gunnar Ritter's vi > (or Steve Kirkendall's elvis) and even bigger than Bram Moolenaar's vim. % wc -c /bin/vi bin/sam bin/samterm 1706152 /bin/vi 112208 bin/sam 153624 bin/samterm These mumbers are from Red Hat Linux. The 6:1 discrepancy is understated because vi is stripped and the sam files are not. All are 64-bit, dynamically linked. From ewe2 at ewe2.ninja Wed Jan 8 06:04:47 2020 From: ewe2 at ewe2.ninja (Sean Dwyer) Date: Tue, 7 Jan 2020 15:04:47 -0500 Subject: [TUHS] wump.c for v6 In-Reply-To: References: <42cf63eb-d51e-d1ab-34ed-fbff94e18999@gmail.com> <682F5EA8-A1D2-4A5A-933F-C46B3631030E@gmail.com> Message-ID: <20200107200447.GA3211@mail.ewe2.ninja> On Mon, Jan 06, 2020 at 11:48:02AM -0700, Warner Losh wrote: > On Mon, Jan 6, 2020 at 11:38 AM Will Senn wrote: > > > On 1/6/20 12:29 PM, Warner Losh wrote: > > > > The good news is that disassembly will tell you right away if it was > > written in C or not. > > > > > > OK. I give up. How? > > > > Generally, the C compiler generates code that's quite distinctive (at least > PCC does, not sure about Dennis' compiler). People writing free assembler > tend to do really weird things for function entry / return. > > And it will likely tell you if it's some weird wrapper around another > binary, though that wasn't too common at bell labs. > > Warner A while back I did some analysis (https://ewe2.ninja/computers/cno/) of another source-less v6 binary, cno. Fortunately, it hadn't been stripped but I still did some disasembly because of the interesting differences. v6 binaries have a different crt0 preamble and simpler subroutine setup, and I narrowed dowh the library code to an intermediate stage of iolib (which IIRC still exists in the UNSW archive on TUHS). There's a few cribs in that essay to help you figure out some basic things, pdp11 assembly isn't hard to decode. -- I love deadlines. I love the whooshing noise as they fly by. From brantley at coraid.com Wed Jan 8 06:17:22 2020 From: brantley at coraid.com (Brantley Coile) Date: Tue, 7 Jan 2020 20:17:22 +0000 Subject: [TUHS] screen editors In-Reply-To: <202001071957.007JveQu169574@coolidge.cs.dartmouth.edu> References: <202001071957.007JveQu169574@coolidge.cs.dartmouth.edu> Message-ID: <02159ABA-0114-4A30-A30B-F3A5104309DE@coraid.com> No point here, other than showing the size of sam in its native Plan 9 habitat. ehg% size /bin/sam /bin/aux/samterm 95,514t + 8,764d + 75,868b = 180,146 /bin/sam 145,093t + 28,708d + 59,508b = 233,309 /bin/aux/samterm The size gives me a better idea of the code complexity. For completeness, here's the size of vi on my Mac. bwc-downtown:~ bwc$ size /usr/bin/vi __TEXT __DATA __OBJC others dec hex 1,585,152 163,840 0 4,295,012,352 4,296,761,344 1001b6000 Good thing the Mac has shared libraries? (Commas added for clarity) Again, no point, other than a data point. Brantley > On Jan 7, 2020, at 2:57 PM, Doug McIlroy wrote: > > McIlroy: >> [vi] was so excesssive right from the start that I refused to use it. >> Sam was the first screen editor that I deemed worthwhile, and I >> still use it today. > > Paulsen: >> my sam build is more than 2 times bigger than Gunnar Ritter's vi >> (or Steve Kirkendall's elvis) and even bigger than Bram Moolenaar's vim. > > % wc -c /bin/vi bin/sam bin/samterm > 1706152 /bin/vi > 112208 bin/sam > 153624 bin/samterm > These mumbers are from Red Hat Linux. > The 6:1 discrepancy is understated because > vi is stripped and the sam files are not. > All are 64-bit, dynamically linked. From dave at horsfall.org Wed Jan 8 06:44:12 2020 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 8 Jan 2020 07:44:12 +1100 (EST) Subject: [TUHS] screen editors In-Reply-To: <5a2152e0cbaaf23fc31a51f984a5ef9d@firemail.de> References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU> <5a2152e0cbaaf23fc31a51f984a5ef9d@firemail.de> Message-ID: On Tue, 7 Jan 2020, Thomas Paulsen wrote: >> I don't recall the exact details, but there was once an editor called >> "em" (Editor for Mortals). I remember thinking: what sort of an idiot >> would call it that, with the "e" and "r" keys adjacent to each other? >> I wonder how many files were lost that way... > > you can download, build and use em making immediately clear that em was > much easier to use than ed. Nevertheless em was only (another) step in > between ed and vi. I'm sure you're right, but that wasn't the point that I was making... -- Dave From chet.ramey at case.edu Wed Jan 8 06:45:24 2020 From: chet.ramey at case.edu (Chet Ramey) Date: Tue, 7 Jan 2020 15:45:24 -0500 Subject: [TUHS] screen editors In-Reply-To: References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU> Message-ID: <8cf54833-dcc6-7958-f05f-f6606006b4d9@case.edu> On 1/7/20 10:50 AM, Thomas Paulsen wrote: >> It was so excesssive right from the start that I refused to use it. >> Sam was the first screen editor that I deemed worthwhile, and I >> still use it today. > my sam build is more than 2 times bigger than Gunnar Ritter's vi (or Steve Kirkendall's elvis) and even bigger than Bram Moolenaar's vim. If we're really doing this editor size contest thing, I'll submit my `ce' editor. (ftp://ftp.cwru.edu/pub/chet/ce-4.8.tar.gz). It's emacs-like, but not particularly configurable, and the defaults, strangely enough, are exactly what I like. On my Mac OS X machine, it's about ten times smaller than vim $ size /usr/local/bin/ce __TEXT __DATA __OBJC others dec hex 114688 339968 0 4295024640 4295479296 10007d000 $ size /usr/bin/vim __TEXT __DATA __OBJC others dec hex 1687552 176128 0 4295016448 4296880128 1001d3000 Similar numbers on RHEL 7, but due to the large bss, it's only about 45% smaller than vim. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From bakul at bitblocks.com Wed Jan 8 06:47:19 2020 From: bakul at bitblocks.com (Bakul Shah) Date: Tue, 07 Jan 2020 12:47:19 -0800 Subject: [TUHS] screen editors In-Reply-To: Your message of "Tue, 07 Jan 2020 14:57:40 -0500." <202001071957.007JveQu169574@coolidge.cs.dartmouth.edu> References: <202001071957.007JveQu169574@coolidge.cs.dartmouth.edu> Message-ID: <20200107204726.B0F91156E42E@mail.bitblocks.com> On Tue, 07 Jan 2020 14:57:40 -0500 Doug McIlroy wrote: > McIlroy: > > [vi] was so excesssive right from the start that I refused to use it. > > Sam was the first screen editor that I deemed worthwhile, and I > > still use it today. > > Paulsen: > > my sam build is more than 2 times bigger than Gunnar Ritter's vi > > (or Steve Kirkendall's elvis) and even bigger than Bram Moolenaar's vim. > > % wc -c /bin/vi bin/sam bin/samterm > 1706152 /bin/vi > 112208 bin/sam > 153624 bin/samterm > These mumbers are from Red Hat Linux. > The 6:1 discrepancy is understated because > vi is stripped and the sam files are not. > All are 64-bit, dynamically linked. A source code comparison $ cd 2bsd/src/ex # this is a snapshot of May 9, 1979 $ wc *.c | tail -1 17176 56138 331865 total $ cd $PLAN9/src/cmd/ # what works today $ wc {sam,samterm}/*.[hc] | tail -1 11366 27236 201666 total $ cd /usr/src/contrib/nvi # what works today $ wc */*.[ch] | tail -1 51978 202926 1297043 total # actual count is slightly smaller I use nvi or acme. Haven't touched sam in ages. Having taught my fingertips nvi 37 years back, I can edit the fastest in it. But some things are easier in acme + with its multiple panes and smaller antialiased fonts it makes much better use of a retina display. iterm/screen + nvi can't match that. Until about 95 I used nvi & the Rand Editor (later Dave Yost's version). The latter was the easiest to use + it did multiple editing windows much before nvi or vim. From clemc at ccc.com Wed Jan 8 07:08:08 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 7 Jan 2020 16:08:08 -0500 Subject: [TUHS] wump.c for v6 In-Reply-To: <20200107200447.GA3211@mail.ewe2.ninja> References: <42cf63eb-d51e-d1ab-34ed-fbff94e18999@gmail.com> <682F5EA8-A1D2-4A5A-933F-C46B3631030E@gmail.com> <20200107200447.GA3211@mail.ewe2.ninja> Message-ID: Nice job -- one comment: You said at the end of your document: "Both cno and phx were written at what appears to have been what I would call v6b, version 6 as the standard library was moving from libS to libc, as Dennis Ritchie formalised the library proper. This can be seen in crt0.s where the form is not of standard V6 but of the libc V6 before it became standard in V7 and changed yet again. I was able to track this using the UNSW archives which have both libraries at the critical point." I will place a bet it is not your v6b idea... (which was basically V6 plus Ken's patch tape - although as Noel and I have decoded some of PWB 1.0 - which was based on V6 too -- made it into the wild in a couple of places). Anyway, I think you are seeing code output from what was called the 'Typesetter C" compiler release which came out before V7 and was needed to compile troff *et al.* which actually what conforms with the original K&R. Indeed, that compiler used libS as the library. The other thing, many v6 implementations (like CMU's and I think MIT) had a preprocessor (it was called /lib/cpp ) before we got Typesetter C. i.e. a version of cpp that predated the Riesner cpp rewrite that was in Typesetter C and later V7. Steve Johnson probably knows the history of the preprocessor better than I. I know when we went through the V5 to V6 upgrade we somehow had a preprocessor. I remember being curious about it and then being disappointed it was not as good as the BLISS macro facility. But ... neither the binary nor the sources for that cpp are in Warner's Archives for V6 when I just looked. The Interdata 7/32 stuff Warren has is a V6 port, and has a version of cpp, but a note in the source says it is based on what looks like the Typesetter C compiler - which was sometimes called the Level 7 compiler because Dennis had told us all it was the new compiler for the next releases (TS and V7). PWB 1.0 has a copy of cpp in the sources, but a quick look its not clear how close the V7 version it is. So, unless anyone else can illuminate, I'm not sure where the first cpp that some of us using v6 had originated. On Tue, Jan 7, 2020 at 3:14 PM Sean Dwyer via TUHS wrote: > On Mon, Jan 06, 2020 at 11:48:02AM -0700, Warner Losh wrote: > > On Mon, Jan 6, 2020 at 11:38 AM Will Senn wrote: > > > > > On 1/6/20 12:29 PM, Warner Losh wrote: > > > > > > The good news is that disassembly will tell you right away if it was > > > written in C or not. > > > > > > > > > OK. I give up. How? > > > > > > > Generally, the C compiler generates code that's quite distinctive (at > least > > PCC does, not sure about Dennis' compiler). People writing free assembler > > tend to do really weird things for function entry / return. > > > > And it will likely tell you if it's some weird wrapper around another > > binary, though that wasn't too common at bell labs. > > > > Warner > > A while back I did some analysis (https://ewe2.ninja/computers/cno/) of > another source-less v6 binary, cno. Fortunately, it hadn't been stripped > but I > still did some disasembly because of the interesting differences. v6 > binaries > have a different crt0 preamble and simpler subroutine setup, and I narrowed > dowh the library code to an intermediate stage of iolib (which IIRC still > exists in the UNSW archive on TUHS). There's a few cribs in that essay to > help > you figure out some basic things, pdp11 assembly isn't hard to decode. > > -- > I love deadlines. I love the whooshing noise as they fly by. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfawcus+lists-tuhs at employees.org Wed Jan 8 07:20:13 2020 From: dfawcus+lists-tuhs at employees.org (Derek Fawcus) Date: Tue, 7 Jan 2020 21:20:13 +0000 Subject: [TUHS] screen editors In-Reply-To: <8cf54833-dcc6-7958-f05f-f6606006b4d9@case.edu> References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU> <8cf54833-dcc6-7958-f05f-f6606006b4d9@case.edu> Message-ID: <20200107212013.GA17953@clarinet.employees.org> On Tue, Jan 07, 2020 at 03:45:24PM -0500, Chet Ramey wrote: > On my Mac OS X machine, it's about ten times smaller than vim > > $ size /usr/local/bin/ce > __TEXT __DATA __OBJC others dec hex > 114688 339968 0 4295024640 4295479296 10007d000 > $ size /usr/bin/vim > __TEXT __DATA __OBJC others dec hex > 1687552 176128 0 4295016448 4296880128 1001d3000 > > Similar numbers on RHEL 7, but due to the large bss, it's only about > 45% smaller than vim. So I got curious about those large numbers on the mac, and made use of 'otool -l'. It would seem that the values for __DATA reported by size correspond to the overall size of the 'load command' for the __DATA segment, and so includes bss as well. $ ls -l /usr/bin/vim -rwxr-xr-x 1 root wheel 1530064 29 Jun 2018 /usr/bin/vim So 'size' on the mac is not so useful, but 'size -m /usr/bin/vim' gives information from which one could derive the normal 'size' output. $ size -m /usr/bin/vim Segment __PAGEZERO: 4294967296 Segment __TEXT: 1388544 Section __text: 1271745 Section __stubs: 1044 Section __stub_helper: 1756 Section __cstring: 85892 Section __const: 14672 Section __unwind_info: 8944 total 1384053 Segment __DATA: 155648 Section __got: 1056 Section __nl_symbol_ptr: 16 Section __la_symbol_ptr: 1392 Section __const: 38608 Section __data: 64432 Section __bss: 42520 Section __common: 5720 total 153744 Segment __LINKEDIT: 36864 total 4296548352 DF From dave at horsfall.org Wed Jan 8 08:13:39 2020 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 8 Jan 2020 09:13:39 +1100 (EST) Subject: [TUHS] # (was Re: sh: cmd | >file) In-Reply-To: References: <202001060630.0066U7U7023760@cuzuco.com> Message-ID: On Tue, 7 Jan 2020, Clem Cole wrote: > Algol-W   From, the Sites book, (Page 10, Section 1 'Terminology)  [Dave, > I'll send you the PDF offline].  For the record, it was received OK; thanks! > The symbol comment followed by any sequence of > characters not -containing semicolons, followed by a > semicolon, is called a comment. A comment has no > effect on the meaning of a program, and is ignored > during execution of the program.  For the benefit of the OP, here is no mention of "#" being a comment in ALGOL(W). -- Dave From bakul at bitblocks.com Wed Jan 8 08:26:52 2020 From: bakul at bitblocks.com (Bakul Shah) Date: Tue, 7 Jan 2020 14:26:52 -0800 Subject: [TUHS] # (was Re: sh: cmd | >file) In-Reply-To: References: Message-ID: <8E00CE76-B57C-4077-8768-63DF27BBE246@bitblocks.com> > On Jan 6, 2020, at 2:51 PM, Dave Horsfall wrote: > > On Mon, 6 Jan 2020, Brian Walden wrote: > >> Also before you say wait! ALGOL uses # as comment and is older than Kernighan' ratfor(1). [...] > > Funny; I recall ALGOL using "comment ... ;" or was that ALGOLW (which I loved using; I wish I still had my ALGOLW book)? In Algol68 # ... # is one of the forms for block comments! From reed at reedmedia.net Wed Jan 8 08:22:41 2020 From: reed at reedmedia.net (reed at reedmedia.net) Date: Tue, 7 Jan 2020 16:22:41 -0600 (CST) Subject: [TUHS] What happened with XENIX? (was Re: Unix/World Magazines) In-Reply-To: <20200107105615.GA16081@minnie.tuhs.org> References: <20200107105615.GA16081@minnie.tuhs.org> Message-ID: On Tue, 7 Jan 2020, Warren Toomey wrote: > All, I've uploaded 13 Unix/World magazines from 1984-85 to archive.org. Thanks! November 1985 issue has an article by Bill Gates. Gates wrote that they were optimistic to achieve 400,000 XENIX installations -- their critical mass -- within 18 months. "... IBM has announced XENIX as the multi-user operating sysytem for the IBM PC-AT." "Significantly, at the time the XENIX project was started [mid 1980], the IBM Personal Computer had not been announced." What happened with XENIX? I know it had some success (I used at least one retired system with it), but nothing near the other offerings on the PC family. From dave at horsfall.org Wed Jan 8 08:56:26 2020 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 8 Jan 2020 09:56:26 +1100 (EST) Subject: [TUHS] # (was Re: sh: cmd | >file) In-Reply-To: <8E00CE76-B57C-4077-8768-63DF27BBE246@bitblocks.com> References: <8E00CE76-B57C-4077-8768-63DF27BBE246@bitblocks.com> Message-ID: On Tue, 7 Jan 2020, Bakul Shah wrote: > In Algol68 # ... # is one of the forms for block comments! Interesting... All we had at university though was ALGOL W (as far as I know; there were several languages that mere students could not use, such as FORTRAN H). -- Dave From dave at horsfall.org Wed Jan 8 09:12:23 2020 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 8 Jan 2020 10:12:23 +1100 (EST) Subject: [TUHS] What happened with XENIX? (was Re: Unix/World Magazines) In-Reply-To: References: <20200107105615.GA16081@minnie.tuhs.org> Message-ID: On Tue, 7 Jan 2020, reed at reedmedia.net wrote: [...] > What happened with XENIX? I know it had some success (I used at least > one retired system with it), but nothing near the other offerings on the > PC family. I was forced to use Xenix for a contracting job (and hated it, as it was almost-but-not-quite-Unix, and the differences annoyed me). Wouldn't Linux have arrived at around that time? -- Dave From pete at pski.net Wed Jan 8 09:21:11 2020 From: pete at pski.net (Peter Cetinski) Date: Tue, 7 Jan 2020 18:21:11 -0500 Subject: [TUHS] What happened with XENIX? (was Re: Unix/World Magazines) In-Reply-To: References: <20200107105615.GA16081@minnie.tuhs.org> Message-ID: > On Jan 7, 2020, at 5:22 PM, reed at reedmedia.net wrote: > > What happened with XENIX? I know it had some success (I used at least > one retired system with it), but nothing near the other offerings on the > PC family. XENIX was staged for greatness until Microsoft decided they did not want to be subject to the AT&T license long term with all the potential issues that could arise by not being in complete control of their operating system. From imp at bsdimp.com Wed Jan 8 09:27:30 2020 From: imp at bsdimp.com (Warner Losh) Date: Tue, 7 Jan 2020 16:27:30 -0700 Subject: [TUHS] What happened with XENIX? (was Re: Unix/World Magazines) In-Reply-To: References: <20200107105615.GA16081@minnie.tuhs.org> Message-ID: On Tue, Jan 7, 2020 at 4:13 PM Dave Horsfall wrote: > On Tue, 7 Jan 2020, reed at reedmedia.net wrote: > > [...] > > > What happened with XENIX? I know it had some success (I used at least > > one retired system with it), but nothing near the other offerings on the > > PC family. > > I was forced to use Xenix for a contracting job (and hated it, as it was > almost-but-not-quite-Unix, and the differences annoyed me). Wouldn't > Linux have arrived at around that time? > These mags are from 84 and 85. Linux wasn't really viable until 92 or so. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Wed Jan 8 09:36:15 2020 From: athornton at gmail.com (Adam Thornton) Date: Tue, 7 Jan 2020 16:36:15 -0700 Subject: [TUHS] What happened with XENIX? (was Re: Unix/World Magazines) In-Reply-To: References: <20200107105615.GA16081@minnie.tuhs.org> Message-ID: Hell, Linux didn't exist at all till '91. I think Xenix was more just a casualty of the Unix Wars. The victors there were SunOS/Solaris, AIX, and HP-UX. There were a bunch more walking wounded that never really achieved much market share. By the time SCO filed suit in 2003, not only were the Unix Wars fairly long over (SCO had lost), but commercial Unixes had largely been supplanted by Linux (and BSD enthusiasts had three free options, and OS X was a thing if you wanted a commercial BSD, but Apple never managed to make much in the way of inroads into the server market). Linux's ascendency happened around the turn of the millennium, as I recall, although I was using AIX at my job as late as 2010-2011, and I presume the Big Several still exist in some form or other. On Tue, Jan 7, 2020 at 4:28 PM Warner Losh wrote: > > > On Tue, Jan 7, 2020 at 4:13 PM Dave Horsfall wrote: > >> On Tue, 7 Jan 2020, reed at reedmedia.net wrote: >> >> [...] >> >> > What happened with XENIX? I know it had some success (I used at least >> > one retired system with it), but nothing near the other offerings on >> the >> > PC family. >> >> I was forced to use Xenix for a contracting job (and hated it, as it was >> almost-but-not-quite-Unix, and the differences annoyed me). Wouldn't >> Linux have arrived at around that time? >> > > These mags are from 84 and 85. Linux wasn't really viable until 92 or so. > > Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Wed Jan 8 10:10:25 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Tue, 07 Jan 2020 16:10:25 -0800 Subject: [TUHS] screen editors In-Reply-To: <202001071630.007GUrBj030452@freefriends.org> References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU> <20200107023834.GN20269@mcvoy.com> <202001071630.007GUrBj030452@freefriends.org> Message-ID: <202001080010.0080APtC1678972@darkstar.fourwinds.com> arnold at skeeve.com writes: > Larry McVoy wrote: > > > I'm a vi guy to this day. Love it. I'm a vi guy these days. My first screen editor was something called DTE for Display Terminal Editor written by Dick Hause that ran on the Glance G terminals hooked our Honeywell 516 running 516-TSS. I have some vague recollection of at least one of these terminals ending up in the attic in the UNIX room, but I don't think that the editor was ever ported. It was painful to have to use ed or the 516-TSS equivalent when a terminal wasn't available. Vi was an easy transition because the ed commands could be used until the fancier stuff was learned. Also because that great vi trainer program rogue existed :-) Jon From grog at lemis.com Wed Jan 8 10:50:06 2020 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Wed, 8 Jan 2020 11:50:06 +1100 Subject: [TUHS] IBM PC and XENIX (was: What happened with XENIX? (was Re: Unix/World Magazines)) In-Reply-To: References: <20200107105615.GA16081@minnie.tuhs.org> Message-ID: <20200108005006.GL64020@eureka.lemis.com> On Tuesday, 7 January 2020 at 16:22:41 -0600, reed at reedmedia.net wrote: > On Tue, 7 Jan 2020, Warren Toomey wrote: > >> All, I've uploaded 13 Unix/World magazines from 1984-85 to archive.org. > > Thanks! > > November 1985 issue has an article by Bill Gates. > > Gates wrote that they were optimistic to achieve 400,000 XENIX > installations -- their critical mass -- within 18 months. > > "... IBM has announced XENIX as the multi-user operating sysytem for the > IBM PC-AT." XENIX was initially targeted for the PDP-11, for some reason beyond my understanding. Looking at the Wikipedia page, it seems that the first Intel ports were not aimed at the PC-AT. > "Significantly, at the time the XENIX project was started [mid 1980], > the IBM Personal Computer had not been announced." You don't say where this quote comes from. The use of pluperfect suggests that it's not from the Unix/World article. The PC was announced in August 1981, and the PC-AT was released in August 1984, so the date of the article fits well. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From grog at lemis.com Wed Jan 8 10:44:34 2020 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Wed, 8 Jan 2020 11:44:34 +1100 Subject: [TUHS] XENIX and Linux (was: What happened with XENIX? (was Re: Unix/World Magazines)) In-Reply-To: References: <20200107105615.GA16081@minnie.tuhs.org> Message-ID: <20200108004434.GK64020@eureka.lemis.com> On Wednesday, 8 January 2020 at 10:12:23 +1100, Dave Horsfall wrote: > On Tue, 7 Jan 2020, reed at reedmedia.net wrote: > > [...] > >> What happened with XENIX? I know it had some success (I used at least >> one retired system with it), but nothing near the other offerings on the >> PC family. > > I was forced to use Xenix for a contracting job (and hated it, as it > was almost-but-not-quite-Unix, and the differences annoyed me). I did so too in the early 1990s, using (IIRC) "XENIX System V", an attempt to retrofit some System V features to XENIX. It was very limited: it ran in Intel 80386 real mode, so it was limited to 16 MB of memory. The toolchain was excruciating. I think it was based on Microsoft products, and I soon replaced them with GNU software, which had its problems on the platform. The good news: it worked. > Wouldn't Linux have arrived at around that time? You don't say your time. Referring to Jeremy's original message (time frame mid-1980s), no, Linus would have been about 14 at the time. He made the first announcement of what would become Linux on 25 August 1991 (“just a hobby, won't be big and professional like gnu"). So yes, it was available when I was doing my XENIX work. So was BSD/386, which is what I was using at the time. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From woods at robohack.ca Wed Jan 8 12:44:47 2020 From: woods at robohack.ca (Greg A. Woods) Date: Tue, 07 Jan 2020 18:44:47 -0800 Subject: [TUHS] # (was Re: sh: cmd | >file) In-Reply-To: References: <202001060630.0066U7U7023760@cuzuco.com> Message-ID: At Mon, 6 Jan 2020 17:39:39 -0700, Warner Losh wrote: Subject: Re: [TUHS] # (was Re: sh: cmd | >file) > > > Or you might have cut and paste the commands from a script to test > something, or to redo something by hand that failed for some reason. Cut & Paste? Most of us couldn't do that until the very late 1980's at earliest! The poor man's cut&paste was to do something like 'sed -n 3,9p script | sh', but I don't think I ever did that with csh in the days when a '#' comment was for scripts only, so I don't know if old csh treated a pipe on stdin as a script or not. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From reed at reedmedia.net Wed Jan 8 12:58:04 2020 From: reed at reedmedia.net (reed at reedmedia.net) Date: Tue, 7 Jan 2020 20:58:04 -0600 (CST) Subject: [TUHS] IBM PC and XENIX (was: What happened with XENIX? (was Re: Unix/World Magazines)) In-Reply-To: <20200108005006.GL64020@eureka.lemis.com> References: <20200107105615.GA16081@minnie.tuhs.org> <20200108005006.GL64020@eureka.lemis.com> Message-ID: On Wed, 8 Jan 2020, Greg 'groggy' Lehey wrote: > On Tuesday, 7 January 2020 at 16:22:41 -0600, reed at reedmedia.net wrote: > > November 1985 issue has an article by Bill Gates. > > "Significantly, at the time the XENIX project was started [mid 1980], > > the IBM Personal Computer had not been announced." > > You don't say where this quote comes from. The use of pluperfect > suggests that it's not from the Unix/World article. The PC was > announced in August 1981, and the PC-AT was released in August 1984, > so the date of the article fits well. It was from the magazine. I added the brackets for the date which came from an earlier sentence in the article. From vanattenmark at gmail.com Wed Jan 8 15:13:52 2020 From: vanattenmark at gmail.com (Mark van Atten) Date: Wed, 8 Jan 2020 06:13:52 +0100 Subject: [TUHS] screen editors In-Reply-To: References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU> <17372ca2-0498-4320-a933-5ac522eabb2b@localhost> Message-ID: On Tue, 7 Jan 2020 at 20:36, Rodrigo G. López wrote: > > i like to use it natively as much as possible, especially the 9front edition with its usability (e.g. mouse chording) improvements. if that is not possible, i drawterm into some cpu or a local vm where i can get a little environment to work with whatever is at /mnt/term. In the opposite direction of your preference for a native environment: A port of 9front sam (with chording) to unix is available at https://bitbucket.org/iru/sam9f-unix/src/default/ I use it as a drop-in replacement for the plan9port version. > it has given me the best text editing and programming experience i've ever had. For most types of editing I have come to prefer it over acme. The one modification I should, perhaps, like to see is the possibility to scroll the window while selecting. Rob Pike has made some comments on the difficulty here; see the quotations and links in the discussion at https://github.com/deadpixi/sam/issues/85 (incidentally, on the github pages of another fairly recent port of sam.) A proposal for a (GSOC) project to improve sam scrolling: http://fqa.9front.org/appendixg.html Mark. From tuhs at cuzuco.com Wed Jan 8 15:20:39 2020 From: tuhs at cuzuco.com (Brian Walden) Date: Wed, 8 Jan 2020 00:20:39 -0500 (EST) Subject: [TUHS] # (was Re: sh: cmd | >file) Message-ID: <202001080520.0085KdTi008574@cuzuco.com> Dave Horsfall wrote: >On Tue, 7 Jan 2020, Bakul Shah wrote: > >> In Algol68 # ... # is one of the forms for block comments! > >Interesting... All we had at university though was ALGOL W (as far as I >know; there were several languages that mere students could not use, such >as FORTRAN H). Yes, but when was it implemented? Kernighan is first ever if it is not before 1974. So I decided to look and it took me down a rabbit hole of ALGOL taht leads back to Bourne shell and then right back to # (but in C) By reading the ALGOL 68 wiki page, the laguange seemed to have had a character set problem since day one, and it seems if you didn't have the cent-sign you were to use PR for pragmat for comments. And since it had problems it was continually extened. I just cant find when # was defined. I looked at various old implementations (none pre 1974 list #) -- - CDC's ALGOL 68 compiler from 1975 you could only use use PR .. PR (both # and CO were not defined) http://www.bitsavers.org/pdf/cdc/Tom_Hunter_Scans/Algol_68_version_1_Reference_Manual_RevB.pdf - The official revised ALGOL86 spec from 1978 lists all these ways to enter them (bottom of page 112) in this order -- brief comment symbol: cent-sign bold comment symbol: comment style 1 comment symbol: co style 2 comment symbol: # bold pragmat symbol: pragmat style 1 pragmat symbol: pr seeing # is "style 2" it looks like a later extention to me http://www.softwarepreservation.org/projects/ALGOL/report/Algol68_revised_report-AB.pdf - ALGOL68/19 from 1975 list these 4 symbols as comments: # % co pr http://www.softwarepreservation.org/projects/ALGOL/manual/Gennart_Louis-Algol_ 68_19_Reference_Manual.pdf - DECs ALGOL (1976 printing but first released was 1971) for system10 uses a ! for a comment as # means "not equal" -- http://www.bitsavers.org/www.computer.museum.uq.edu.au/pdf/DEC-10-LALMA-B-D%20 decsystem10%20ALGOL%20Programmer's%20Reference%20Manual.pdf - CMU's ALGOL68S from 1978 list all these ways -- co comment comment comment pr pragmat pragmat pragmat # (comment symbol) comment :: (pragmat symbol) pragmat (its for UNIX v6 or v7 so not surprising # is a comment) http://www.softwarepreservation.org/projects/ALGOL/manual/a68s.txt/view - Rutgers ALGOL 68 interprter from 1987 for UNIX does not implement PR nor PRAMAT and says comments are # CO or COMMENT https://www.renyi.hu/~csirmaz/algol-68/linux/manual I could not find a freely accessible manual for ALGOL68R (very 1st one) nor Cambridge's ALGOL68C. What's intresting here is Stephen Bourne was on the team that made ALGOL68C before he move to Bell Labs. It'd be pretty funny if he implemented a language that there were 7 or 8 ways to enter a comment (cent, co, comment, pr, pragmat, #, ::, %) yet there were zero ways to enter a comment in the Bourne shell. Also the style of "COMMENT put a note here COMMENT" is very un-ALGOL like (with DO .. OD, IF .. FI) shouldn't it be like this? COMMENT put a note here TNEMMOC CO put a note here OC PRAGMAT directive here TAMGARP PR directive here RP So then I remembered Bourne used the C preprocssor to make C like ALGOL when he wrote the shell. If you've never seen it, his C looks like this -- case TSW: BEGIN REG STRING r = mactrim(t->swarg); t=t->swlst; WHILE t DO ARGPTR rex=t->regptr; WHILE rex DO REG STRING s; IF gmatch(r,s=macro(rex->argval)) ORF (trim(s), eq(r,s)) THEN execute(t->regcom,0); t=0; break; ELSE rex=rex->argnxt; FI OD IF t THEN t=t->regnxt FI OD END break; ENDSW So I wanted to see if he remapped C comments /* */ I am not even sure you could even do that with the C preprocessor but took alook anywy and in https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/sh/xec.c It's first lines are this -- # /* * UNIX shell * * S. R. Bourne * Bell Telephone Laboratories * */ #include "defs.h" #include "sym.h" So nope, just regular C comments (which came from PL/I btw which was what multics was programmed in) But look! The very first line of that file! It is a single # sitting all by itself. Why? you ask. Well this is a hold over from when the C preprocessor was new. C orginally did not have it and was added later. PL/I had a %INCLUDE so Ritchie eventaully made a #include -- but pre 7th Edition the C preprocessor would not be inkoved unless the very first character of the C source file was an # Since v7 the preprocessor always run on it. The first C preprocessor was Ritchie's work with no nested includes and no macros. v7's was by John Reiser which added those parts. that 1st line with a single # sitting by itself reminds me of the csh construct as well. -Brian From bakul at bitblocks.com Wed Jan 8 16:25:39 2020 From: bakul at bitblocks.com (Bakul Shah) Date: Tue, 7 Jan 2020 22:25:39 -0800 Subject: [TUHS] # (was Re: sh: cmd | >file) In-Reply-To: <202001080520.0085KdTi008574@cuzuco.com> References: <202001080520.0085KdTi008574@cuzuco.com> Message-ID: > On Jan 7, 2020, at 9:20 PM, Brian Walden wrote: > > Dave Horsfall wrote: >> On Tue, 7 Jan 2020, Bakul Shah wrote: >> >>> In Algol68 # ... # is one of the forms for block comments! >> >> Interesting... All we had at university though was ALGOL W (as far as I >> know; there were several languages that mere students could not use, such >> as FORTRAN H). > > Yes, but when was it implemented? Kernighan is first ever if it is not > before 1974. So I decided to look and it took me down a rabbit hole of > ALGOL taht leads back to Bourne shell and then right back to # (but in C) Tanenbaum’s “A tutorial on Algol 68” published in Computing Surveys, June 1976 mentions that # is one of the (four) ways a comment may be enclosed. https://research.vu.nl/ws/portalfiles/portal/74119499/11057 An earlier paper “Algol68 with fewer tears” by C H Lindsey, 1972 also mentions # as an alternate symbol. https://academic.oup.com/comjnl/article-pdf/15/2/176/1002964/15-2-176.pdf From ewe2 at ewe2.ninja Wed Jan 8 16:35:20 2020 From: ewe2 at ewe2.ninja (Sean Dwyer) Date: Wed, 8 Jan 2020 01:35:20 -0500 Subject: [TUHS] wump.c for v6 In-Reply-To: References: <42cf63eb-d51e-d1ab-34ed-fbff94e18999@gmail.com> <682F5EA8-A1D2-4A5A-933F-C46B3631030E@gmail.com> <20200107200447.GA3211@mail.ewe2.ninja> Message-ID: <20200108063520.GA24350@mail.ewe2.ninja> On Tue, Jan 07, 2020 at 04:08:08PM -0500, Clem Cole wrote: > I will place a bet it is not your v6b idea... (which was basically V6 plus > Ken's patch tape - although as Noel and I have decoded some of PWB 1.0 - > which was based on V6 too -- made it into the wild in a couple of places). > Anyway, I think you are seeing code output from what was called the > 'Typesetter C" compiler release which came out before V7 and was needed to > compile troff *et al.* which actually what conforms with the original > K&R. Indeed, that compiler used libS as the library. Ahh, that adds an extra wrinkle to the proceedings :) I wasn't aware of this version, I was just going on what I disassembled and what I could dig up from unix sources, but neither am I too surprised that there were intermediate steps in between! > So, unless anyone else can illuminate, I'm not sure where the first cpp > that some of us using v6 had originated. > It is as you note, a very confused picture where there was a lot of activity from several different sources. It's pretty amazing to look at the UNSW and Usenet archives and see the sheer volume of device and library hacks that were going on during the v5 and v6 period alone. On a related question, do we know that sources for code such as the ching binaries was at least around at the time of the 32V port? I'm unsure when the sources were lost, was that after V7? A reason I ask is that phx basically remained untouched but the 32V version of cno was definitely changed in the early BSDs, although it may have been a binary patch. -- I love deadlines. I love the whooshing noise as they fly by. From thomas.paulsen at firemail.de Wed Jan 8 17:39:40 2020 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Wed, 08 Jan 2020 08:39:40 +0100 Subject: [TUHS] screen editors Message-ID: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> >What's funny is that in doing the work to get 'se' running on Georgia >Tech's Vax, I had to learn vi. By the time I was done, vi had become >my main editor and had burned itself into my finger's ROMs. I do ed/se occasionally for simple tasks, vim frequently , because it loads fast, and emacs for all bigger projects, beside liteide for golang. From thomas.paulsen at firemail.de Wed Jan 8 17:46:22 2020 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Wed, 08 Jan 2020 08:46:22 +0100 Subject: [TUHS] What happened with XENIX? (was Re: Unix/World Magazines) In-Reply-To: References: <20200107105615.GA16081@minnie.tuhs.org> Message-ID: <81a090b1892b04644c0357805bb75440@firemail.de> >Hell, Linux didn't exist at all till '91. >I think Xenix was more just a casualty of the Unix Wars. The victors there >were SunOS/Solaris, AIX, and HP-UX. There were a bunch more walking >wounded that never really achieved much market share. 'In the mid-to-late 1980s, XENIX was the most common UNIX variant, measured according to the number of machines on which it was installed.' https://en.wikipedia.org/wiki/Xenix From thomas.paulsen at firemail.de Wed Jan 8 17:46:41 2020 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Wed, 08 Jan 2020 08:46:41 +0100 Subject: [TUHS] What happened with XENIX? (was Re: Unix/World Magazines) In-Reply-To: References: <20200107105615.GA16081@minnie.tuhs.org> Message-ID: <5ce956d171c04ef8c249d3ab7b1ce46b@firemail.de> --- Ursprüngliche Nachricht --- Von: Adam Thornton Datum: 08.01.2020 00:36:15 An: Warner Losh , The Eunuchs Hysterical Society Betreff: Re: [TUHS] What happened with XENIX? (was Re: Unix/World Magazines) Hell, Linux didn't exist at all till '91. I think Xenix was more just a casualty of the Unix Wars. The victors there were SunOS/Solaris, AIX, and HP-UX. There were a bunch more walking wounded that never really achieved much market share. By the time SCO filed suit in 2003, not only were the Unix Wars fairly long over (SCO had lost), but commercial Unixes had largely been supplanted by Linux (and BSD enthusiasts had three free options, and OS X was a thing if you wanted a commercial BSD, but Apple never managed to make much in the way of inroads into the server market). Linux's ascendency happened around the turn of the millennium, as I recall, although I was using AIX at my job as late as 2010-2011, and I presume the Big Several still exist in some form or other. On Tue, Jan 7, 2020 at 4:28 PM Warner Losh wrote: > > > On Tue, Jan 7, 2020 at 4:13 PM Dave Horsfall wrote: > >> On Tue, 7 Jan 2020, reed at reedmedia.net wrote: >> >> [...] >> >> > What happened with XENIX? I know it had some success (I used at least >> > one retired system with it), but nothing near the other offerings on >> the >> > PC family. >> >> I was forced to use Xenix for a contracting job (and hated it, as it was >> almost-but-not-quite-Unix, and the differences annoyed me). Wouldn't >> Linux have arrived at around that time? >> > > These mags are from 84 and 85. Linux wasn't really viable until 92 or so. > > Warner > From pnr at planet.nl Wed Jan 8 19:18:13 2020 From: pnr at planet.nl (Paul Ruizendaal) Date: Wed, 8 Jan 2020 10:18:13 +0100 Subject: [TUHS] What happened with XENIX? Message-ID: <6134CA5C-C44D-49AC-A7B0-61DE542CE850@planet.nl> This web page has some details about XENIX prior to 1985: http://seefigure1.com/2014/04/15/xenixtime.html In particular this chart is intriguing: http://seefigure1.com/images/xenix/xenix-timeline.jpg I’d love to have XENIX from the 1980-1985 era in the TUHS archive, as it documents the tail end of the Unix on 16 bits era. It would have been great if MS had released that as part of the Unix-at-50 events. Paul From rudi.j.blom at gmail.com Wed Jan 8 19:46:59 2020 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Wed, 8 Jan 2020 16:46:59 +0700 Subject: [TUHS] screen editors Message-ID: >Date: Tue, 07 Jan 2020 14:57:40 -0500. >From: Doug McIlroy <> >To: tuhs at tuhs.org, thomas.paulsen at firemail.de >Subject: Re: [TUHS] screen editors >Message-ID: <202001071957.007JveQu169574 at coolidge.cs.dartmouth.edu> >Content-Type: text/plain; charset=us-ascii .. snip .. >% wc -c /bin/vi bin/sam bin/samterm >1706152 /bin/vi > 112208 bin/sam > 153624 bin/samterm >These mumbers are from Red Hat Linux. >The 6:1 discrepancy is understated because >vi is stripped and the sam files are not. >All are 64-bit, dynamically linked. That's a real big vi in RHL. Looking at a few (commercial) unixes I get SCO UNIX 3.2V4.2 132898 Aug 22 1996 /usr/bin/vi - /usr/bin/vi: iAPX 386 executable Tru64 V5.1B-5 331552 Aug 21 2010 /usr/bin/vi - /usr/bin/vi: COFF format alpha dynamically linked, demand paged sticky executable or object module stripped - version 3.13-14 HP-UX 11.31 748996 Aug 28 2009 /bin/vi -- /bin/vi: ELF-32 executable object file - IA64 From michael at kjorling.se Wed Jan 8 22:18:01 2020 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Wed, 8 Jan 2020 12:18:01 +0000 Subject: [TUHS] What happened with XENIX? In-Reply-To: References: <20200107105615.GA16081@minnie.tuhs.org> Message-ID: <7zxjn49rcpnbpgv7zbq4rxgv@localhost> On 7 Jan 2020 16:22 -0600, from reed at reedmedia.net: > "Significantly, at the time the XENIX project was started [mid 1980], > the IBM Personal Computer had not been announced." Perhaps even more significantly in this case, but possibly not publicly known at the time, IBM's Project Chess, which resulted in the IBM PC, apparently began in July 1980. (The promise was to develop an initial prototype in 30 days, and a working personal computer in a year; the initial demo was in August, the first internal demo in January 1981, and product release was in August 1981.) https://en.wikipedia.org/wiki/IBM_Personal_Computer#Project_Chess So by "mid 1980", what would eventually lead up to the IBM PC was at most _just barely_ getting started. -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” From mrudge at ubuntu.com Wed Jan 8 22:40:27 2020 From: mrudge at ubuntu.com (Matt Rudge) Date: Wed, 8 Jan 2020 12:40:27 +0000 Subject: [TUHS] What happened with XENIX? (was Re: Unix/World Magazines) In-Reply-To: <81a090b1892b04644c0357805bb75440@firemail.de> References: <20200107105615.GA16081@minnie.tuhs.org> <81a090b1892b04644c0357805bb75440@firemail.de> Message-ID: On Wed, 8 Jan 2020 at 07:48, Thomas Paulsen wrote: > > >Hell, Linux didn't exist at all till '91. > >I think Xenix was more just a casualty of the Unix Wars. The victors there > >were SunOS/Solaris, AIX, and HP-UX. There were a bunch more walking > >wounded that never really achieved much market share. > 'In the mid-to-late 1980s, XENIX was the most common UNIX variant, measured according to the number of machines on which it was installed.' > https://en.wikipedia.org/wiki/Xenix > I do remember supporting a small Xenix userbase in the mid-90's in southeast Ireland. Mostly in law offices, surprisingly. They were very resilient, usually running on a Wang PC-02 with greenscreen terminals (Wyse, I think). Although they worked fine for their intended purpose (word processing etc.), the allure of Windows was their demise. From ron at ronnatalie.com Wed Jan 8 22:46:13 2020 From: ron at ronnatalie.com (Ronald Natalie) Date: Wed, 8 Jan 2020 07:46:13 -0500 Subject: [TUHS] What happened with XENIX? In-Reply-To: <6134CA5C-C44D-49AC-A7B0-61DE542CE850@planet.nl> References: <6134CA5C-C44D-49AC-A7B0-61DE542CE850@planet.nl> Message-ID: One of my first contracts with IBM was to add (get this) a SECOND network interface to secure-XENIX, an MLS version of the software. I believe it was being used as a “downgrade” audit station to allow data to be moved form one secure network to another. I believe the original work was done by Jakob Recktor (probably butchering the spelling of his name). That contract led to a few follow ons with IBM to port AIX to i860 based machines. I still have my old IBM badge kicking around somewhere. From chet.ramey at case.edu Thu Jan 9 00:15:11 2020 From: chet.ramey at case.edu (Chet Ramey) Date: Wed, 8 Jan 2020 09:15:11 -0500 Subject: [TUHS] screen editors In-Reply-To: References: Message-ID: On 1/8/20 4:46 AM, Rudi Blom wrote: > That's a real big vi in RHL. It's vim. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From steffen at sdaoden.eu Thu Jan 9 01:15:47 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 08 Jan 2020 16:15:47 +0100 Subject: [TUHS] screen editors In-Reply-To: References: Message-ID: <20200108151547.4uumD%steffen@sdaoden.eu> Chet Ramey wrote in : |On 1/8/20 4:46 AM, Rudi Blom wrote: |> That's a real big vi in RHL. | |It's vim. It is a tremendous effort of Bram Moolenaar and the vim contributors to maintain this codebase that can be configured in uncountable ways, just looking at the pre-configured feature sets that exist lead to tiny, small, normal, big and huge. As far as i know it has real support for languages of the world, which is a different thing than being UTF-8 all through the engine. (But i think emacs is better here, i see one markable emacs developer taking care on the Unicode list, regarding real BiDi support, for example.) With all my sympathy for pico at first and for long, then mg / ee / nano / jupp etc., and with my repeated tries to switch over to vile, in the last two decades i always came back home to vim, for the one thing or the other. Two endless loops in all this time. I only use the smallest thinkable subsets of features, though. (Only lumberjack-style editing here, anyway.) --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) From cym224 at gmail.com Thu Jan 9 01:11:47 2020 From: cym224 at gmail.com (Nemo Nusquam) Date: Wed, 8 Jan 2020 10:11:47 -0500 Subject: [TUHS] screen editors In-Reply-To: References: Message-ID: On 01/08/20 04:46, Rudi Blom wrote: > That's a real big vi in RHL. Looking at a few (commercial) unixes I get > SCO UNIX 3.2V4.2 132898 Aug 22 1996 /usr/bin/vi > - /usr/bin/vi: iAPX 386 executable > Tru64 V5.1B-5 331552 Aug 21 2010 /usr/bin/vi > - /usr/bin/vi: COFF format alpha dynamically linked, demand paged > sticky executable or object module stripped - version 3.13-14 > HP-UX 11.31 748996 Aug 28 2009 /bin/vi > -- /bin/vi: ELF-32 executable object file - IA64 Solaris 10 on Ultrasparc 239828 /usr/bin/vi: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, stripped Any others? N. From steve.mynott at gmail.com Thu Jan 9 01:29:17 2020 From: steve.mynott at gmail.com (Steve Mynott) Date: Wed, 8 Jan 2020 15:29:17 +0000 Subject: [TUHS] screen editors In-Reply-To: References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU> Message-ID: On 07/01/2020, Dave Horsfall wrote: > I don't recall the exact details, but there was once an editor called "em" > (Editor for Mortals). I remember thinking: what sort of an idiot would > call it that, with the "e" and "r" keys adjacent to each other? I wonder > how many files were lost that way... It was a line editor which resembled ex, came from QMC London and was used on some VAX BSD systems in UK Universities in the early '80s. The source is online. As for "rm" typos I'm sure many discovered netnews the same way! -- Steve Mynott cv25519/ECF8B611205B447E091246AF959E3D6197190DD5 From henry.r.bent at gmail.com Thu Jan 9 01:37:19 2020 From: henry.r.bent at gmail.com (Henry Bent) Date: Wed, 8 Jan 2020 10:37:19 -0500 Subject: [TUHS] screen editors In-Reply-To: References: Message-ID: On Wed, 8 Jan 2020 at 10:20, Nemo Nusquam wrote: > On 01/08/20 04:46, Rudi Blom wrote: > > That's a real big vi in RHL. Looking at a few (commercial) unixes I get > > SCO UNIX 3.2V4.2 132898 Aug 22 1996 /usr/bin/vi > > - /usr/bin/vi: iAPX 386 executable > > Tru64 V5.1B-5 331552 Aug 21 2010 /usr/bin/vi > > - /usr/bin/vi: COFF format alpha dynamically linked, demand paged > > sticky executable or object module stripped - version 3.13-14 > > HP-UX 11.31 748996 Aug 28 2009 /bin/vi > > -- /bin/vi: ELF-32 executable object file - IA64 > > Solaris 10 on Ultrasparc 239828 > /usr/bin/vi: ELF 32-bit MSB executable SPARC Version 1, > dynamically linked, stripped > > Any others? > I was somewhat surprised by this, on IRIX 4.0.5H: /usr/bin/vi: symbolic link to ex -rwxr-xr-t 1 root sys 229376 2016-04-17 01:07 /usr/bin/ex /usr/bin/ex: mipseb demand paged stripped - version 2.10 % what /usr/bin/ex /usr/bin/ex: printf.c:2.2 6/5/79 -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve.mynott at gmail.com Thu Jan 9 01:42:07 2020 From: steve.mynott at gmail.com (Steve Mynott) Date: Wed, 8 Jan 2020 15:42:07 +0000 Subject: [TUHS] screen editors In-Reply-To: <20200108151547.4uumD%steffen@sdaoden.eu> References: <20200108151547.4uumD%steffen@sdaoden.eu> Message-ID: On 08/01/2020, Steffen Nurpmeso wrote: > It is a tremendous effort of Bram Moolenaar and the vim > contributors to maintain this codebase that can be configured in > uncountable ways, just looking at the pre-configured feature sets > that exist lead to tiny, small, normal, big and huge. Indeed. It's larger because it does a lot more! Small isn't necessarily beautiful and all those tiny old vendor vi binaries are probably full of bugs since they were never actively maintained. The last time I used Solaris vi it didn't handle long lines properly and the more recent classic Joy vi open source forks are full of bug fixes (often for quite serious problems). If you want a tiny vi compile one of those up or use nvi. If you want features use vim. -- Steve Mynott cv25519/ECF8B611205B447E091246AF959E3D6197190DD5 From usotsuki at buric.co Thu Jan 9 01:58:55 2020 From: usotsuki at buric.co (Steve Nickolas) Date: Wed, 8 Jan 2020 10:58:55 -0500 (EST) Subject: [TUHS] screen editors In-Reply-To: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> Message-ID: On Wed, 8 Jan 2020, Thomas Paulsen wrote: >> What's funny is that in doing the work to get 'se' running on Georgia >> Tech's Vax, I had to learn vi. By the time I was done, vi had become >> my main editor and had burned itself into my finger's ROMs. > I do ed/se occasionally for simple tasks, vim frequently , because it > loads fast, and emacs for all bigger projects, beside liteide for > golang. For what it's worth, I use nano. (Yeah, I know, not very unixy.) I think the first fullscreen text editor I used was FrEdWriter (by Paul Lutus and Al Rogers) for the Apple ][. After that it was IBM's E. I haven't really used vi *or* emacs much. -uso. From clemc at ccc.com Thu Jan 9 02:02:41 2020 From: clemc at ccc.com (Clem Cole) Date: Wed, 8 Jan 2020 11:02:41 -0500 Subject: [TUHS] [TUHS -> moving to COFF] # and the Preprocessor Message-ID: below... -- warning veering a little from pure UNIX history, but trying to clarify what I can and then moving to COFF for follow up. On Wed, Jan 8, 2020 at 12:23 AM Brian Walden wrote: > .... > > - CMU's ALGOL68S from 1978 list all these ways -- > co comment > comment comment > pr pragmat > pragmat pragmat > # (comment symbol) comment > :: (pragmat symbol) pragmat > (its for UNIX v6 or v7 so not surprising # is a comment) > http://www.softwarepreservation.org/projects/ALGOL/manual/a68s.txt/view Be careful of overthinking here. The comment in that note says was it was for* PDP-11's *and lists V6 and V7 was *a possible target*, but it did not say it was. Also, the Speach and Vision PDP-11/40e based systems ran a very hacked v6 (which a special C compiler that supported CMU's csv/cret instructions in the microcode), which would have been the target systems. [1] To my knowledge/memory, the CMU Algol68 compiler never ran anywhere but Hydra (and also used custom microcode). IIRC there was some talk to move it to *OS (Star OS for CM*) I've sent a note to dvk to see if he remembers it otherwise. I also ask Liebensperger what he remembers, he was hacking on *OS in those days. Again, IIRC Prof. Peter Hibbard was the mastermind behind the CMU Algol68 system. He was a Brit from Cambridge (and taught the parallel computing course which I took from him at the time). FWIW: I also don't think the CMU Algol68 compiler was ever completely self-hosting, and like BLISS, required the PDP-10 to support it. As to why it was not moved to the Vax, I was leaving/had left by that time, but I suspect the students involved graduated and by then the Perq's had become the hot machine for language types and ADA would start being what the gvt would give research $s too. > > > ... > > But look! The very first line of that file! It is a single # sitting all > by itself. Why? you ask. Well this is a hold over from when the C > preprocessor was new. C orginally did not have it and was added later. > PL/I had a %INCLUDE so Ritchie eventaully made a #include -- but pre 7th > Edition the C preprocessor would not be inkoved unless the very first > character of the C source file was an # > That was true of V7 and Typesetter C too. It was a separate program ( /lib/cpp) that the cc command called if needed. > Since v7 the preprocessor always run on it. The first C preprocessor was > Ritchie's work with no nested includes and no macros. v7's was by John > Reiser which added those parts. > Right, this is what I was referring too last night in reference to Sean comments. As I said, the /bin/cc command was a shell script and it peaked at the first character to see if it was #. I still find myself starting all C programs with a # on a line by itself ;-) Note that the Ritchie cpp was influenced by Brian's Ratfor work, so using # is not surprising. This leads to a question/thought for this group, although I think needs to move to COFF (which I have CC'ed for follow up). I have often contended, that one of the reasons why C, Fortran, and PL/1 were so popular as commercial production languages were because they could be preprocessed. For a commercial place where lots of different targets is possible, that was hugely important. Pascal, for instance, has semantics that makes writing a preprocessor like cpp or Ratfor difficult (which was one of the things Brian talks about in his "*Why Pascal is not my favorite Programming Language *" paper). [2] So, if you went to commercial ISV's and looked at what they wrote in. It was usually some sort of preprocessed language. Some used Ratfor like a number of commercial HPC apps vendors, Tektronix wrote PLOT10 in MORTRAN. I believe it was Morgan-Stanley had a front-end for PL/1, which I can not recall the name. But you get the point ... if you had to target different runtime environments, it was best for your base code to not be specific. However ... as C became the system programming language, the preprocessor was important. In fact, it even gave birth the other tools like autoconfig to help control them. Simply, the idiom: #ifdef SYSTEMX #define SOME_VAR (1) ... do something specific #endif /* SYSTEMX */ While loathsome to read, it actually worked well in practice. That fact is I hate the preprocessor in many ways but love it for what it for the freedom it actually gave us to move code. Having programmed since the 1960s, I remember how hard it was to move things, even if the language was the same. Today, modern languages try to forego the preprocessor. C++'s solution is to throw the kitchen sink into the language and have 'frameworks', none of which work together. Java's and its family tries to control it with the JVM. Go is a little too new to see if its going to work (I don't see a lot of production ISV code in it yet). Note: A difference between then and now, is 1) we have few target architectures and 2) we have fewer target operating environments, 3) ISV don't like multiple different versions of their SW, they much prefer very few for maintenance reasons so they like # 1 and #2 [i.e. Cole's law of economics in operation here]. So ... my question, particularly for those like Doug who have programmed longer and at least as long as I, what do you think? You lived the same time I did and know the difficulties we faced. Is the loss of a preprocessor good or bad? Clem [1] Historical footnote about CMU. I was the person that brought V7 into CMU and I never updated the Speach or Vision systems and I don't think anyone did after I left. We ran a CMU V7 variant mostly on the 11/34s (and later on a couple of 11/44s I believe) that had started to pop up. Although later if it was a DEC system, CS was moving to Vaxen when they could get the $s (but the Alto's and Perq's had become popular with the CMU SPICE proposal). Departments like bio-engineering, mech ee, ran the cheaper systems on-site and then networked over the Computer Center's Vaxen and PDP-20's when they needed address space). [2] Note: Knuth wrote "Web" to handle a number of the issues, Kernighan talks about - but he had to use an extended Pascal superset and his program was notable for not being portable (he wrote for it for the PDP-10 Pascal). [BTW: Ward Cunningham, TW Cook and I once counted over 8 different 'Tek Pascal' variants and 14 different 'HP Basics']. -------------- next part -------------- An HTML attachment was scrubbed... URL: From heinz at osta.com Thu Jan 9 02:56:33 2020 From: heinz at osta.com (Heinz Lycklama) Date: Wed, 8 Jan 2020 08:56:33 -0800 Subject: [TUHS] What happened with XENIX? (was Re: Unix/World Magazines) In-Reply-To: <81a090b1892b04644c0357805bb75440@firemail.de> References: <20200107105615.GA16081@minnie.tuhs.org> <81a090b1892b04644c0357805bb75440@firemail.de> Message-ID: <2808f855-7525-52b9-3d18-1e95580f2e62@osta.com> On 1/7/2020 11:46 PM, Thomas Paulsen wrote: >> Hell, Linux didn't exist at all till '91. >> I think Xenix was more just a casualty of the Unix Wars. The victors there >> were SunOS/Solaris, AIX, and HP-UX. There were a bunch more walking >> wounded that never really achieved much market share. > 'In the mid-to-late 1980s, XENIX was the most common UNIX variant, measured according to the number of machines on which it was installed.' > https://en.wikipedia.org/wiki/Xenix Two other major vendors competing with Xenix were:     1. _*INTERACTIVE Systems Corp. (ISC)*_ [founded in 1977] with PC/IX, and later IS/3, etc.     2. _*Santa Cruz Operation (SCO)*_ [founded in 1979] with SCO UNIX, etc. There were also a number of smaller players in this space. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mah at mhorton.net Thu Jan 9 04:30:43 2020 From: mah at mhorton.net (Mary Ann Horton) Date: Wed, 8 Jan 2020 10:30:43 -0800 Subject: [TUHS] screen editors In-Reply-To: <202001071630.007GUrBj030452@freefriends.org> References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU> <20200107023834.GN20269@mcvoy.com> <202001071630.007GUrBj030452@freefriends.org> Message-ID: It's interesting how much of this has  been lost to history. Curses, in particular, is sketchily documented, and se is unknown. Here's how I remember it. Bill Joy made major enhancements to previously enhanced versions of ed, creating vi. In 1979, he bumped up against the 64K boundary on the PDP-11, and handed it off to me. I made some more smaller enhancements. vi was huge by the standards of the day, especially compared to ed. There were ifdefs to take out several features, such as support for upper case only terminals, to make it fit on the PDP-11. I had to split it into version 2 (16 bit) and 3 (32 bit) to be able to enhance it and still support 2BSD on the PDP-11. Ken Arnold took the screen updating code from vi (just the "full screen update", not the parts that did insert/delete line/char) and turned it into the curses library. Rogue was the primary user of curses. Once I graduated from Berkeley went to Bell Labs, I took vi, termcap, and curses with me. I replaced termcap, which was too slow to start up (it was quadratic on the size of the entry, which was awful on the hardware of the day) with terminfo, a binary version that was faster. It included tools like tic and infocmp to translate back and forth to text and termcap. I also rewrote curses with a new algorithm that fully utilized insert/delete line/char. I had a paper to publish on the subject, but I lost it and never did publish it. I gave a talk at Usenix Boston in 1982 about the new curses and terminfo. But I couldn't release the code, because it was considered proprietary. Pavel Curtis offered to clone it, and I coached him on the algorithm and specs, and he released a good clone pcurses. Eventually that became ncurses. Nearly everyone at Bell Labs (outside area 11) was using either vi or emacs, but System III just had ed. There was a big push to add vi or emacs to UNIX 3.0 (System III), but USG instead chose to write se, the "screen editor" and put it in UNIX 4.0. Nobody would use it, so UNIX 5.0 (System V) relented and included vi.     Mary Ann On 1/7/20 8:30 AM, arnold at skeeve.com wrote: > Larry McVoy wrote: > >> I'm a vi guy to this day. Love it. > In the summer of '82 I did some contract programming at Southern Bell > on a PDP-11 running USG Unix 4.0. It had a screen editor called 'se' > that I only ever saw there, written somewhere in the Bell System and > squeezed to run on an -11. Anyone know anything about it? > > Unrelated, Georgia Tech had the 'se' screen editor as part of the > Software Tools Subsystem, based on the 'ed' in the Software Tools book. > This was later ported to Unix. I modified that code to use curses/termlib > and posted it to USENET. It's been updated and is available from > https://github.com/se-editor/se and http://se-editor.org is the home > page. (Thomas Cort IIRC did that work.) > > What's funny is that in doing the work to get 'se' running on Georgia > Tech's Vax, I had to learn vi. By the time I was done, vi had become > my main editor and had burned itself into my finger's ROMs. > > Arnold From steffen at sdaoden.eu Thu Jan 9 06:56:46 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 08 Jan 2020 21:56:46 +0100 Subject: [TUHS] screen editors In-Reply-To: <68b3d6df-94f6-625d-39bf-6149b4c177c9@andrewnesbit.org> References: <20200108151547.4uumD%steffen@sdaoden.eu> <68b3d6df-94f6-625d-39bf-6149b4c177c9@andrewnesbit.org> Message-ID: <20200108205646.A8FxA%steffen@sdaoden.eu> U'll Be King of the Stars wrote in <68b3d6df-94f6-625d-39bf-6149b4c177c9\ @andrewnesbit.org>: |On 08/01/2020 15:15, Steffen Nurpmeso wrote: |> (But i think emacs is better here, i see one markable |> emacs developer taking care on the Unicode list, regarding real |> BiDi support, for example.) | |I have been following the emacs-devel mailing list out of interest for |many years. From this, I think the person you are referring to in your |comment, is Eli Zaretskii. Is that right? Yep. Then again i have to say it was a lot of a mistake, because the OSS man who i referred to and who is known for questions deep in the material is indeed Karl Williamson of i think Perl. --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) From woods at robohack.ca Thu Jan 9 07:43:43 2020 From: woods at robohack.ca (Greg A. Woods) Date: Wed, 08 Jan 2020 13:43:43 -0800 Subject: [TUHS] screen editors (FRED) In-Reply-To: References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU> Message-ID: At Tue, 7 Jan 2020 10:03:57 -0500, Clem Cole wrote: Subject: Re: [TUHS] screen editors > > FWIW: When I went from PDP-10 land to UNIX, I learned ed for 5th edition > and somewhat pined for a screen editor. Soon after upgrading to 6th > edition at CMU, we found a visual editor called Fred - the Friendly Editor, > from Cornell IIRC (I think it's on the original USENIX tape but I don't > remember how we got it). I had to hack in the Perkin-Elmer Fox terminal > support, but it was a superset of V6 ed so a pretty trivial learning curve. Ah, yes, Fred. A name with so many editors! I used a full-screen version of an ed-like editor on V7, 32B, and 4BSD at University of Calgary which was called the "FRiendly EDitor". This may be the one you mention. The FRED I know is not to be confused with the version of QED named FRED (Friendly Editor) that was written at the University of Waterloo for Honeywell GECOS by Peter Fraser. It's also not the "FRED - A Friendly Editor" by Richard J. Botting [1]. There's also apparently an editor named FRED for VMS, and another for Amstrad PCW systems (for editing BASIC, and apparently written in BASIC itself). And then there's the one from a company called Digitool which was called "FRED: Fred Resembles Emacs Deliberately", which was written in Macintosh Common Lisp. There's also an old Windows-based "Friendly Right-to-Left Editor (FRED)" by NSRI. I also recently found this [2] reference to a "FRED", but it seems to be yet another completely different kind of editor using the same name. [1] http://www.csci.csusb.edu/dick/papers/rjb84a.FRED.mth [2] https://www.osti.gov/biblio/5141603-fred-program-development-tool Abstract: The structured, screen-based editor FRED is introduced. FRED provides incremental parsing and semantic analysis. The parsing is based on an LL(1) top-down algorithm which has been modified to provide follow-the-cursor parsing and soft templates. The languages accepted by the editor are LL(1) languages with the addition of the Unknown and preferred production non-terminal classes. The semantic analysis is based on the incremental update of attribute grammar equations. We briefly describe the interface between FRED and an automated reference librarian system that is under development. FRED User's Manual Shilling, J. Illinois University, Urbana Department of Computer Science Feb. 1984 FRED, the frinedly editor, is a screen-based structured editor. This manual is intended to serve the needs of a wide range of users of the FRED text editor. Most users will find it sufficient to read the introductory material in section 2, supplemented with the full command set description in section 3. Advanced users may wish to change the keystroke sequences which invoke editor commands. Section 4 describes how to change key bindings and how to define command macros. Some users may need to modify a language description or create an entirely new language description for use with FRED. Section 5 describes the format of the language descriptions used by the editor, and describes how to construct a language grammar. Section 6 describes known portability problems of the FRED editor and should concern only system installation personnel. The editor points out syntax errors in the file being edited and does automatic pretty printing. The version of Fred I used had a full-screen line-oriented mode as well as what was called "open" mode which presented a much more direct full-screen editing experience (though it was a bit quirky, but it reminded me a bit of "Electric Pencil II" which I had used on a Sol-20). Open mode of course generated an interrupt for every key press and so on a PDP-11/60 with 16 terminals it could cause quite a system load, and most of us avoided using open mode on the PDPs. Even the VAX 11/780 running 32V was sometimes slowed by it, but it had at least 24 terminals as I recall (at the time it was still running 32V), so a room full of students feverously typing away was quite a lot of input. I've been unable to find any other reference or mention of this version of Fred; and to the best of my searches it's not on any Usenix tape I can find a copy of. If anyone has any further info about the FRED Clem and/or I seem to remember, please do post it! I soon forgot most that I knew about Fred though once Gosling Emacs was installed on the VAX (after it had been upgraded to 4BSD). I already had a strong preference to Emacs having used it extensively on the Multics system at UofC. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From dave at horsfall.org Thu Jan 9 07:49:58 2020 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 9 Jan 2020 08:49:58 +1100 (EST) Subject: [TUHS] screen editors In-Reply-To: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> Message-ID: On Wed, 8 Jan 2020, Thomas Paulsen wrote: > I do ed/se occasionally for simple tasks, vim frequently , because it loads fast, and emacs for all bigger projects, beside liteide for golang. I had a boss once who insisted that all his staff learn "ed", because one day it might be the only editor available; he was right... -- Dave From grog at lemis.com Thu Jan 9 07:55:17 2020 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Thu, 9 Jan 2020 08:55:17 +1100 Subject: [TUHS] Dating quotes (was: What happened with XENIX?) In-Reply-To: <7zxjn49rcpnbpgv7zbq4rxgv@localhost> References: <20200107105615.GA16081@minnie.tuhs.org> <7zxjn49rcpnbpgv7zbq4rxgv@localhost> Message-ID: <20200108215517.GP64020@eureka.lemis.com> On Wednesday, 8 January 2020 at 12:18:01 +0000, Michael Kjörling wrote: > > So by "mid 1980", what would eventually lead up to the IBM PC was at > most _just barely_ getting started. Right, but my recollection is that the original quote was "mid 1980s" (i.e. round 1985), not "mid 1980". Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From clemc at ccc.com Thu Jan 9 08:01:35 2020 From: clemc at ccc.com (Clem Cole) Date: Wed, 8 Jan 2020 17:01:35 -0500 Subject: [TUHS] screen editors In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> Message-ID: On Wed, Jan 8, 2020 at 4:50 PM Dave Horsfall wrote: > I had a boss once who insisted that all his staff learn "ed", because one > day it might be the only editor available; he was right... > I always suggest it. It means you can use sed and lot of other tools pretty quick. And if you know ed, you can use almost anything close to it. I hated DOS's edlin but if I was stuck it was close enough. Although the famous ? error from the original version was annoying. Truly, I still suggest that any modern user, take Rob and Brian's book and until you can do the exercises without think about it, you really are not yet comfortable with UNIX. I even recommend at least read and looking at the chapter on nroff. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.paulsen at firemail.de Thu Jan 9 07:41:27 2020 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Wed, 08 Jan 2020 22:41:27 +0100 Subject: [TUHS] screen editors In-Reply-To: References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU> <20200107023834.GN20269@mcvoy.com> <202001071630.007GUrBj030452@freefriends.org> Message-ID: <6c0a5ba13bd49788ffa518ebe0afa6c4@firemail.de> >It's interesting how much of this has  been lost to history. Curses, in thanks for the deep insider view. I heard that Bill's ex/vi sources were incomprehensible 'read never' code. Hence it makes no wonder that everybody failed adding real support for cursor keys. beyond automatically switching from insert to visual mode on hitting any cursor key! From dave at horsfall.org Thu Jan 9 08:15:14 2020 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 9 Jan 2020 09:15:14 +1100 (EST) Subject: [TUHS] What happened with XENIX? (was Re: Unix/World Magazines) In-Reply-To: References: <20200107105615.GA16081@minnie.tuhs.org> Message-ID: On Wed, 8 Jan 2020, Dave Horsfall wrote: > I was forced to use Xenix for a contracting job (and hated it, as it was > almost-but-not-quite-Unix, and the differences annoyed me). Wouldn't > Linux have arrived at around that time? OK, I was out by a few years... That job was some time in the 70/80s, and my memory isn't the best these days. Similarly, I have a Penguin laptop at home for porting purposes, otherwise I never use it. The cycle goes something like: get it working on both FreeBSD and the Mac (fairly easy), try it on the Penguin to see what they've broken and make the appropriate changes, then back to the Mac and the FreeBSD box again; repeat as necessary. If worse comes to worst, make the code conditional upon the architecture (and I hate doing that, because it breaks the logical flow of the code). For the record, I was porting Unify (an early RDBMS, and quite a nice one) to a 386... Those damned memory models drove me crazy! I preferred the small model because it was fast, but some modules were so big I had to use the large model which meant modifying the build script in the appropriate directory (no "make" in those days), and there were dozens of them. ObTrivia: I used to use the Unify demonstration to benchmark a machine, and used to joke that sometimes I needed a calendar, not a clock :-) -- Dave From iain at csp-partnership.co.uk Thu Jan 9 08:25:13 2020 From: iain at csp-partnership.co.uk (Dr Iain Maoileoin) Date: Wed, 8 Jan 2020 22:25:13 +0000 Subject: [TUHS] [TUHS -> moving to COFF] # and the Preprocessor In-Reply-To: References: Message-ID: <5BDC3682-F79F-449F-A815-A0C3F1184A21@csp-partnership.co.uk> > On 8 Jan 2020, at 16:02, Clem Cole wrote: > > below... -- warning veering a little from pure UNIX history, but trying to clarify what I can and then moving to COFF for follow up. > > On Wed, Jan 8, 2020 at 12:23 AM Brian Walden > wrote: > .... > > - CMU's ALGOL68S from 1978 list all these ways -- > co comment > comment comment > pr pragmat > pragmat pragmat I remember that a pragma (at least in Algol68R (ICL 1900 series) and I would need to reread the formal definition to see if it was general) was not a comment. It was a note to the compiler - which could choose to use it or lose it. > # (comment symbol) comment > :: (pragmat symbol) pragmat > (its for UNIX v6 or v7 so not surprising # is a comment) > http://www.softwarepreservation.org/projects/ALGOL/manual/a68s.txt/view > -------------- next part -------------- An HTML attachment was scrubbed... URL: From corky1951 at comcast.net Thu Jan 9 08:46:08 2020 From: corky1951 at comcast.net (CHARLES KESTER) Date: Wed, 8 Jan 2020 14:46:08 -0800 (PST) Subject: [TUHS] What happened with XENIX? (was Re: Unix/World Magazines) In-Reply-To: <2808f855-7525-52b9-3d18-1e95580f2e62@osta.com> References: <20200107105615.GA16081@minnie.tuhs.org> <81a090b1892b04644c0357805bb75440@firemail.de> <2808f855-7525-52b9-3d18-1e95580f2e62@osta.com> Message-ID: <12774577.233803.1578523569116@connect.xfinity.com> > On January 8, 2020 at 8:56 AM Heinz Lycklama wrote: > > Two other major vendors competing with Xenix were: > 1. INTERACTIVE Systems Corp. (ISC) https://en.wikipedia.org/wiki/Interactive_Systems_Corporation [founded in 1977] with PC/IX, and later IS/3, etc. > 2. Santa Cruz Operation (SCO) https://en.wikipedia.org/wiki/Santa_Cruz_Operation [founded in 1979] with SCO UNIX, etc. > There were also a number of smaller players in this space. > This brings back memories. My first exposure to Unix (ca. 1985) was Interactive 386/ix. I think I still have the floppies for it around here somewhere. I don't know if they're still readable but if anyone wants them, send me a private email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Thu Jan 9 09:21:37 2020 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 9 Jan 2020 10:21:37 +1100 (EST) Subject: [TUHS] screen editors In-Reply-To: References: Message-ID: On Wed, 8 Jan 2020, Chet Ramey wrote: >> That's a real big vi in RHL. > > It's vim. It's also VIM on the Mac. -- Dave From skogtun at gmail.com Thu Jan 9 09:29:23 2020 From: skogtun at gmail.com (Harald Arnesen) Date: Thu, 9 Jan 2020 00:29:23 +0100 Subject: [TUHS] What happened with XENIX? (was Re: Unix/World Magazines) In-Reply-To: References: <20200107105615.GA16081@minnie.tuhs.org> Message-ID: <0813f7fb-dd3d-e5a1-299e-42b9c34cdcf8@gmail.com> Den 08.01.2020 23:15, skrev Dave Horsfall: > Similarly, I have a Penguin laptop at home for porting purposes, > otherwise I never use it.  The cycle goes something like: get it working > on both FreeBSD and the Mac (fairly easy), try it on the Penguin to see > what they've broken and make the appropriate changes, then back to the > Mac and the FreeBSD box again; repeat as necessary.  If worse comes to > worst, make the code conditional upon the architecture (and I hate doing > that, because it breaks the logical flow of the code). In my experience, macOS breaks more things these days. -- Hilsen Harald From dave at horsfall.org Thu Jan 9 09:31:10 2020 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 9 Jan 2020 10:31:10 +1100 (EST) Subject: [TUHS] screen editors In-Reply-To: References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU> Message-ID: On Wed, 8 Jan 2020, Steve Mynott wrote: > As for "rm" typos I'm sure many discovered netnews the same way! OK, I'll admit that I was baffled until I took a closer look at my keyboard :-) -- Dave From dave at horsfall.org Thu Jan 9 09:41:16 2020 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 9 Jan 2020 10:41:16 +1100 (EST) Subject: [TUHS] screen editors In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> Message-ID: On Wed, 8 Jan 2020, Steve Nickolas wrote: > I think the first fullscreen text editor I used was FrEdWriter (by Paul > Lutus and Al Rogers) for the Apple ][. After that it was IBM's E. I > haven't really used vi *or* emacs much. First I used was DEC's "EDT" and could never get used to the "gold" key... Fortunately I was not required to use RSX (or was it VMS?) as I was strictly a PDP Unix bod at the time; I was just curious. -- Dave From reed at reedmedia.net Thu Jan 9 09:48:55 2020 From: reed at reedmedia.net (reed at reedmedia.net) Date: Wed, 8 Jan 2020 17:48:55 -0600 (CST) Subject: [TUHS] Dating quotes (was: What happened with XENIX?) In-Reply-To: <20200108215517.GP64020@eureka.lemis.com> References: <20200107105615.GA16081@minnie.tuhs.org> <7zxjn49rcpnbpgv7zbq4rxgv@localhost> <20200108215517.GP64020@eureka.lemis.com> Message-ID: On Thu, 9 Jan 2020, Greg 'groggy' Lehey wrote: > On Wednesday, 8 January 2020 at 12:18:01 +0000, Michael Kj?rling wrote: > > > > So by "mid 1980", what would eventually lead up to the IBM PC was at > > most _just barely_ getting started. > > Right, but my recollection is that the original quote was "mid 1980s" > (i.e. round 1985), not "mid 1980". "mid-1980" (without "s") was from page 31 https://archive.org/details/Unix_World_Vol02_10.pdf/page/n29 (It is in a sidebar; I will still attribute it to Gates.) (I'd think mid-1980s with "s" wouldn't make sense for an article written probably before October 1985.) From ron at ronnatalie.com Thu Jan 9 10:01:57 2020 From: ron at ronnatalie.com (ron at ronnatalie.com) Date: Wed, 8 Jan 2020 19:01:57 -0500 Subject: [TUHS] What happened with XENIX? (was Re: Unix/World Magazines) In-Reply-To: <0813f7fb-dd3d-e5a1-299e-42b9c34cdcf8@gmail.com> References: <20200107105615.GA16081@minnie.tuhs.org> <0813f7fb-dd3d-e5a1-299e-42b9c34cdcf8@gmail.com> Message-ID: <5a9f509789bdff895fc01fb9881bbd99.squirrel@squirrelmail.tuffmail.net> We were Interactive Systems users in 1981 when I worked for Martin Marietta. Heinz, you were working there at that point, right? I remember my rep was Monica Gallegos. A few years later I got caught up with a Multibus II port which I think Interactive Systems was also involved with. I had three systems on my desk to get the experimental computer with the experimental SCSI host adapter and the experimental SCSI tape drive: A Wyse PC, a Intel Multibus I 386 system, and an Intel MultibusII system. I really did end up liking MultibusII for UNIX. From dave at horsfall.org Thu Jan 9 10:04:59 2020 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 9 Jan 2020 11:04:59 +1100 (EST) Subject: [TUHS] screen editors (FRED) In-Reply-To: References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU> Message-ID: I'm surprised that no-one has mentioned "F*cking Ripper of an EDitor" yet, or was it UNSW-only? -- Dave From imp at bsdimp.com Thu Jan 9 10:08:59 2020 From: imp at bsdimp.com (Warner Losh) Date: Wed, 8 Jan 2020 17:08:59 -0700 Subject: [TUHS] screen editors In-Reply-To: References: Message-ID: On Wed, Jan 8, 2020, 4:22 PM Dave Horsfall wrote: > On Wed, 8 Jan 2020, Chet Ramey wrote: > > >> That's a real big vi in RHL. > > > > It's vim. > > It's also VIM on the Mac. > Nvi is also interesting and 1/10th the size of vim. It's also the FreeBSD default for vi. Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From heinz at osta.com Thu Jan 9 10:19:46 2020 From: heinz at osta.com (Heinz Lycklama) Date: Wed, 8 Jan 2020 16:19:46 -0800 Subject: [TUHS] What happened with XENIX? (was Re: Unix/World Magazines) In-Reply-To: <5a9f509789bdff895fc01fb9881bbd99.squirrel@squirrelmail.tuffmail.net> References: <20200107105615.GA16081@minnie.tuhs.org> <0813f7fb-dd3d-e5a1-299e-42b9c34cdcf8@gmail.com> <5a9f509789bdff895fc01fb9881bbd99.squirrel@squirrelmail.tuffmail.net> Message-ID: <1a626615-690a-33a3-3a61-8cb6dcd4de1e@osta.com> Yes, I worked at INTERACTIVE Systems Corp. (ISC) from 1978 to the end of 1991 when Sun Microsystems acquired ISC. -- Heinz -- On 1/8/2020 4:01 PM, ron at ronnatalie.com wrote: > We were Interactive Systems users in 1981 when I worked for Martin > Marietta. Heinz, you were working there at that point, right? I > remember my rep was Monica Gallegos. > > A few years later I got caught up with a Multibus II port which I think > Interactive Systems was also involved with. I had three systems on my > desk to get the experimental computer with the experimental SCSI host > adapter and the experimental SCSI tape drive: A Wyse PC, a Intel > Multibus I 386 system, and an Intel MultibusII system. > > I really did end up liking MultibusII for UNIX. > > From dave at horsfall.org Thu Jan 9 10:19:52 2020 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 9 Jan 2020 11:19:52 +1100 (EST) Subject: [TUHS] What happened with XENIX? (was Re: Unix/World Magazines) In-Reply-To: <0813f7fb-dd3d-e5a1-299e-42b9c34cdcf8@gmail.com> References: <20200107105615.GA16081@minnie.tuhs.org> <0813f7fb-dd3d-e5a1-299e-42b9c34cdcf8@gmail.com> Message-ID: On Thu, 9 Jan 2020, Harald Arnesen wrote: > In my experience, macOS breaks more things these days. Fortunately my Mac never progressed beyond Sierra due to memory limitations or something; its other major job is as a client into my FreeBSD server. Slowly getting into COFF territory now, I think... -- Dave From lm at mcvoy.com Thu Jan 9 11:28:30 2020 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 8 Jan 2020 17:28:30 -0800 Subject: [TUHS] screen editors In-Reply-To: References: Message-ID: <20200109012830.GC16808@mcvoy.com> On Wed, Jan 08, 2020 at 05:08:59PM -0700, Warner Losh wrote: > On Wed, Jan 8, 2020, 4:22 PM Dave Horsfall wrote: > > > On Wed, 8 Jan 2020, Chet Ramey wrote: > > > > >> That's a real big vi in RHL. > > > > > > It's vim. > > > > It's also VIM on the Mac. > > > > Nvi is also interesting and 1/10th the size of vim. It's also the FreeBSD > default for vi. I was gonna stay out of this thread (it has the feel of old folks somehow) but 2 comments: Keith did nvi (I can't remember why? licensing or something) and he did a pretty faithful bug for bug compatible job. I've always wondered why. I like Keith but it seemed like a waste. There were other people taking vi forward, elvis, xvi (I hacked the crap out of that one, made it mmap the file and had a whole string library that treated \n like NULL) and I think vim was coming along. So doing a compat vi felt like a step backward for me. For all the vim haters, come on. Vim is awesome, it gave me the one thing that I wanted from emacs, multiple windows. I use that all the time. It's got piles of stuff that I don't use, probably should, but it is every bit as good of a vi as the original and then it added more. I'm super grateful that vim came along. From bakul at bitblocks.com Thu Jan 9 11:40:10 2020 From: bakul at bitblocks.com (Bakul Shah) Date: Wed, 8 Jan 2020 17:40:10 -0800 Subject: [TUHS] screen editors In-Reply-To: <20200109012830.GC16808@mcvoy.com> References: <20200109012830.GC16808@mcvoy.com> Message-ID: On Jan 8, 2020, at 5:28 PM, Larry McVoy wrote: > > On Wed, Jan 08, 2020 at 05:08:59PM -0700, Warner Losh wrote: >> On Wed, Jan 8, 2020, 4:22 PM Dave Horsfall wrote: >> >>> On Wed, 8 Jan 2020, Chet Ramey wrote: >>> >>>>> That's a real big vi in RHL. >>>> >>>> It's vim. >>> >>> It's also VIM on the Mac. >>> >> >> Nvi is also interesting and 1/10th the size of vim. It's also the FreeBSD >> default for vi. > > I was gonna stay out of this thread (it has the feel of old folks somehow) > but 2 comments: > > Keith did nvi (I can't remember why? licensing or something) and he did > a pretty faithful bug for bug compatible job. I've always wondered why. > I like Keith but it seemed like a waste. There were other people taking > vi forward, elvis, xvi (I hacked the crap out of that one, made it mmap > the file and had a whole string library that treated \n like NULL) and > I think vim was coming along. So doing a compat vi felt like a step > backward for me. > > For all the vim haters, come on. Vim is awesome, it gave me the one > thing that I wanted from emacs, multiple windows. I use that all the > time. It's got piles of stuff that I don't use, probably should, but > it is every bit as good of a vi as the original and then it added more. > I'm super grateful that vim came along. The first thing I do on a new machine is to install nvi. Very grateful to Keith Bostic for implementing it. I do use multiple windows — only horizontal splits but that is good enough for me as all my terminal windows are 80 chars wide. Not a vim hater but never saw the need. From cym224 at gmail.com Thu Jan 9 11:43:20 2020 From: cym224 at gmail.com (Nemo Nusquam) Date: Wed, 8 Jan 2020 20:43:20 -0500 Subject: [TUHS] screen editors In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> Message-ID: On 01/08/20 18:41, Dave Horsfall wrote: > [...] > First I used was DEC's "EDT" and could never get used to the "gold" > key... > > Fortunately I was not required to use RSX (or was it VMS?) as I was > strictly a PDP Unix bod at the time; I was just curious. > > -- Dave It was VMS and I had forgotten all about the Gold Key until now. N. From clemc at ccc.com Thu Jan 9 12:04:46 2020 From: clemc at ccc.com (Clem Cole) Date: Wed, 8 Jan 2020 21:04:46 -0500 Subject: [TUHS] screen editors In-Reply-To: References: <20200109012830.GC16808@mcvoy.com> Message-ID: On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah wrote: > The first thing I do on a new machine is to install nvi. Very grateful to > Keith Bostic for implementing it. I do use multiple windows — only > horizontal splits but that is good enough for me as all my terminal > windows are 80 chars wide. Not a vim hater but never saw the need. I pretty much do the same thing. I think what I hate about vim is that it's almost, vi but not the same. My fingers screw up when I use it. For instance, he 'fixed' undo. I guess I learned my lesson from my time at UCB. Henry Spencer once said, "BSD 4.2 is just like UNIX, only different." I rather see something new and completely different than changing behavior that people rely upon. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Thu Jan 9 12:07:20 2020 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 8 Jan 2020 18:07:20 -0800 Subject: [TUHS] screen editors In-Reply-To: References: <20200109012830.GC16808@mcvoy.com> Message-ID: <20200109020720.GG16808@mcvoy.com> On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote: > On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah wrote: > > > The first thing I do on a new machine is to install nvi. Very grateful to > > Keith Bostic for implementing it. I do use multiple windows ??? only > > horizontal splits but that is good enough for me as all my terminal > > windows are 80 chars wide. Not a vim hater but never saw the need. > > I pretty much do the same thing. I think what I hate about vim is that it's > almost, vi but not the same. My fingers screw up when I use it. For > instance, he 'fixed' undo. Holy crap Clem, you need to embrace that. His undo goes back forever. And you can undo the undo and go forward forever. Not liking that puts you in the "get off my lawn" old guy camp. Which is fine if that's who you want to be (sometimes I'm that guy). From clemc at ccc.com Thu Jan 9 12:12:38 2020 From: clemc at ccc.com (Clem Cole) Date: Wed, 8 Jan 2020 21:12:38 -0500 Subject: [TUHS] screen editors In-Reply-To: <20200109020720.GG16808@mcvoy.com> References: <20200109012830.GC16808@mcvoy.com> <20200109020720.GG16808@mcvoy.com> Message-ID: make a new command, don't break the old one.... maybe offer a way to map the new one over the old -- but don't make it the default. and my lawn was lush and green before the snow came ;-) On Wed, Jan 8, 2020 at 9:07 PM Larry McVoy wrote: > On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote: > > On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah wrote: > > > > > The first thing I do on a new machine is to install nvi. Very grateful > to > > > Keith Bostic for implementing it. I do use multiple windows ??? only > > > horizontal splits but that is good enough for me as all my terminal > > > windows are 80 chars wide. Not a vim hater but never saw the need. > > > > I pretty much do the same thing. I think what I hate about vim is that > it's > > almost, vi but not the same. My fingers screw up when I use it. For > > instance, he 'fixed' undo. > > Holy crap Clem, you need to embrace that. His undo goes back forever. > And you can undo the undo and go forward forever. > > Not liking that puts you in the "get off my lawn" old guy camp. Which > is fine if that's who you want to be (sometimes I'm that guy). > -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Thu Jan 9 12:14:03 2020 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Thu, 9 Jan 2020 13:14:03 +1100 Subject: [TUHS] screen editors In-Reply-To: <20200109012830.GC16808@mcvoy.com> References: <20200109012830.GC16808@mcvoy.com> Message-ID: <20200109021403.GR64020@eureka.lemis.com> On Wednesday, 8 January 2020 at 17:28:30 -0800, Larry McVoy wrote: > On Wed, Jan 08, 2020 at 05:08:59PM -0700, Warner Losh wrote: >> Nvi is also interesting and 1/10th the size of vim. It's also the FreeBSD >> default for vi. > > I was gonna stay out of this thread (it has the feel of old folks somehow) > but 2 comments: > > Keith did nvi (I can't remember why? licensing or something) My vague recollection is that Rob Kolstad paid him to do it for BSD/386. As you say, licensing, and that BSD/386 *really* needed a vi editor. Does anybody know where Rob is? Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From chet.ramey at case.edu Thu Jan 9 12:48:40 2020 From: chet.ramey at case.edu (Chet Ramey) Date: Wed, 8 Jan 2020 21:48:40 -0500 Subject: [TUHS] screen editors In-Reply-To: <20200109021403.GR64020@eureka.lemis.com> References: <20200109012830.GC16808@mcvoy.com> <20200109021403.GR64020@eureka.lemis.com> Message-ID: On 1/8/20 9:14 PM, Greg 'groggy' Lehey wrote: > My vague recollection is that Rob Kolstad paid him to do it for > BSD/386. As you say, licensing, and that BSD/386 *really* needed a vi > editor. > > Does anybody know where Rob is? Colorado Springs, according to Twitter. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: OpenPGP digital signature URL: From bakul at bitblocks.com Thu Jan 9 12:59:02 2020 From: bakul at bitblocks.com (Bakul Shah) Date: Wed, 8 Jan 2020 18:59:02 -0800 Subject: [TUHS] screen editors In-Reply-To: References: <20200109012830.GC16808@mcvoy.com> <20200109020720.GG16808@mcvoy.com> Message-ID: Early in vim’s life I had emailed Moolenaar asking him if he would be willing to add an option for nvi like behavior for undo/redo. He wasn’t interested so I lost interest. nvi’s u & . behavior is not only quite clever but also much more intuitive and you don’t have to press the ctl key! > On Jan 8, 2020, at 6:12 PM, Clem Cole wrote: > > make a new command, don't break the old one.... maybe offer a way to map the new one over the old -- but don't make it the default. > and my lawn was lush and green before the snow came ;-) > > > > On Wed, Jan 8, 2020 at 9:07 PM Larry McVoy wrote: > On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote: > > On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah wrote: > > > > > The first thing I do on a new machine is to install nvi. Very grateful to > > > Keith Bostic for implementing it. I do use multiple windows ??? only > > > horizontal splits but that is good enough for me as all my terminal > > > windows are 80 chars wide. Not a vim hater but never saw the need. > > > > I pretty much do the same thing. I think what I hate about vim is that it's > > almost, vi but not the same. My fingers screw up when I use it. For > > instance, he 'fixed' undo. > > Holy crap Clem, you need to embrace that. His undo goes back forever. > And you can undo the undo and go forward forever. > > Not liking that puts you in the "get off my lawn" old guy camp. Which > is fine if that's who you want to be (sometimes I'm that guy). From lm at mcvoy.com Thu Jan 9 13:08:53 2020 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 8 Jan 2020 19:08:53 -0800 Subject: [TUHS] screen editors In-Reply-To: References: <20200109012830.GC16808@mcvoy.com> <20200109020720.GG16808@mcvoy.com> Message-ID: <20200109030853.GH16808@mcvoy.com> I feel like there is an option to get nvi behaviour now but I dunno why you want that. Are you seriously advocating for less? Because objectively vim gives you more. And it is faithful to vi, it has all the buffers so you can put stuff back that way. Maybe I'm clueless or I drank the koolaid, but I love vim. It's vi but better. On Wed, Jan 08, 2020 at 06:59:02PM -0800, Bakul Shah wrote: > Early in vim???s life I had emailed Moolenaar asking him if he would be > willing to add an option for nvi like behavior for undo/redo. He wasn???t > interested so I lost interest. nvi???s u & . behavior is not only quite clever > but also much more intuitive and you don???t have to press the ctl key! > > > On Jan 8, 2020, at 6:12 PM, Clem Cole wrote: > > > > make a new command, don't break the old one.... maybe offer a way to map the new one over the old -- but don't make it the default. > > and my lawn was lush and green before the snow came ;-) > > > > > > > > On Wed, Jan 8, 2020 at 9:07 PM Larry McVoy wrote: > > On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote: > > > On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah wrote: > > > > > > > The first thing I do on a new machine is to install nvi. Very grateful to > > > > Keith Bostic for implementing it. I do use multiple windows ??? only > > > > horizontal splits but that is good enough for me as all my terminal > > > > windows are 80 chars wide. Not a vim hater but never saw the need. > > > > > > I pretty much do the same thing. I think what I hate about vim is that it's > > > almost, vi but not the same. My fingers screw up when I use it. For > > > instance, he 'fixed' undo. > > > > Holy crap Clem, you need to embrace that. His undo goes back forever. > > And you can undo the undo and go forward forever. > > > > Not liking that puts you in the "get off my lawn" old guy camp. Which > > is fine if that's who you want to be (sometimes I'm that guy). -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From mah at mhorton.net Thu Jan 9 13:27:13 2020 From: mah at mhorton.net (Mary Ann Horton) Date: Wed, 8 Jan 2020 19:27:13 -0800 Subject: [TUHS] screen editors In-Reply-To: References: <20200109012830.GC16808@mcvoy.com> <20200109020720.GG16808@mcvoy.com> Message-ID: <4b810af6-1880-92c2-ef22-4029643d5225@mhorton.net> vim has an option to undo the vi way. "set cpoptions=u". There is a full set of vi-compatible options if you want them. "set cp" turns on full vi compatiblity. Funny, I see vim as the vi that comes with UNIX, and never learned the enhancements, but I just tried it out and I don't have the compatibility option set. I don't seem to have noticed. I guess I don't do the "undo toggle" all that often.     Mary Ann On 1/8/20 6:12 PM, Clem Cole wrote: > make a new command, don't break the old one....  maybe offer a way to > map the new one over the old -- but don't make it the default. > and my lawn was lush and green before the snow came ;-) > > > > On Wed, Jan 8, 2020 at 9:07 PM Larry McVoy > wrote: > > On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote: > > On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah > wrote: > > > > > The first thing I do on a new machine is to install nvi. Very > grateful to > > > Keith Bostic for implementing it. I do use multiple windows > ??? only > > > horizontal splits but that is good enough for me as all my > terminal > > > windows are 80 chars wide. Not a vim hater but never saw the need. > > > > I pretty much do the same thing. I think what I hate about vim > is that it's > > almost, vi but not the same. My fingers screw up when I use it.  For > > instance, he 'fixed' undo. > > Holy crap Clem, you need to embrace that.  His undo goes back forever. > And you can undo the undo and go forward forever. > > Not liking that puts you in the "get off my lawn" old guy camp.  Which > is fine if that's who you want to be (sometimes I'm that guy). > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Thu Jan 9 13:34:18 2020 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 8 Jan 2020 19:34:18 -0800 Subject: [TUHS] screen editors In-Reply-To: <4b810af6-1880-92c2-ef22-4029643d5225@mhorton.net> References: <20200109012830.GC16808@mcvoy.com> <20200109020720.GG16808@mcvoy.com> <4b810af6-1880-92c2-ef22-4029643d5225@mhorton.net> Message-ID: <20200109033418.GI16808@mcvoy.com> +1 On Wed, Jan 08, 2020 at 07:27:13PM -0800, Mary Ann Horton wrote: > vim has an option to undo the vi way. "set cpoptions=u". There is a full set > of vi-compatible options if you want them. "set cp" turns on full vi > compatiblity. > > Funny, I see vim as the vi that comes with UNIX, and never learned the > enhancements, but I just tried it out and I don't have the compatibility > option set. I don't seem to have noticed. I guess I don't do the "undo > toggle" all that often. > > ?????? Mary Ann > > On 1/8/20 6:12 PM, Clem Cole wrote: > >make a new command, don't break the old one....?? maybe offer a way to map > >the new one over the old -- but don't make it the default. > >and my lawn was lush and green before the snow came ;-) > > > > > > > >On Wed, Jan 8, 2020 at 9:07 PM Larry McVoy >> wrote: > > > > On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote: > > > On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah > > wrote: > > > > > > > The first thing I do on a new machine is to install nvi. Very > > grateful to > > > > Keith Bostic for implementing it. I do use multiple windows > > ??? only > > > > horizontal splits but that is good enough for me as all my > > terminal > > > > windows are 80 chars wide. Not a vim hater but never saw the need. > > > > > > I pretty much do the same thing. I think what I hate about vim > > is that it's > > > almost, vi but not the same. My fingers screw up when I use it.?? For > > > instance, he 'fixed' undo. > > > > Holy crap Clem, you need to embrace that.?? His undo goes back forever. > > And you can undo the undo and go forward forever. > > > > Not liking that puts you in the "get off my lawn" old guy camp.?? Which > > is fine if that's who you want to be (sometimes I'm that guy). > > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From davida at pobox.com Thu Jan 9 13:25:18 2020 From: davida at pobox.com (David Arnold) Date: Thu, 9 Jan 2020 14:25:18 +1100 Subject: [TUHS] What happened with XENIX? (was Re: Unix/World Magazines) In-Reply-To: <0813f7fb-dd3d-e5a1-299e-42b9c34cdcf8@gmail.com> References: <20200107105615.GA16081@minnie.tuhs.org> <0813f7fb-dd3d-e5a1-299e-42b9c34cdcf8@gmail.com> Message-ID: > On 9 Jan 2020, at 10:29, Harald Arnesen wrote: > Den 08.01.2020 23:15, skrev Dave Horsfall: > >> Similarly, I have a Penguin laptop at home for porting purposes, otherwise I never use it. The cycle goes something like: get it working on both FreeBSD and the Mac (fairly easy), try it on the Penguin to see what they've broken and make the appropriate changes, then back to the Mac and the FreeBSD box again; repeat as necessary. If worse comes to worst, make the code conditional upon the architecture (and I hate doing that, because it breaks the logical flow of the code). > > In my experience, macOS breaks more things these days. When I first used “Unix” in the late 80’s, most of the available source code needed some sort of tweaking to work, unless the author happened to have the same system I was using (HP/UX, Minix, and a BSD VAX, iirc). A rummage through the GNU’s autoconf docs will (re)acquaint you with he multitude of small differences that needed to be accounted for to make most things portable. Then Sun became the dominant vendor, and most things would work out of the box on SunOS / Solaris, with different degrees of effort required depending on how different your system was. I was working for a DEC-sponsored lab at the time, and Ultrix was more in the BSD camp than Solaris, but there was usually someone had done some BSD-style tweaks that could be co-opted into mostly working for Ultrix. Then we got the fancy new DEC3000 Alphas, and to a first approximation, *nothing* worked (although that was mostly 64 bit pointers, rather than OSF/1). As Linux has become increasingly popular, things now almost universally work out of the box on Linux, with some work required to make macOS, *BSD, and the other commercial Unices work. Often now, there’s no autoconf (at least for newer projects) or it’s poorly maintained, and I find myself back to the 80s-style patching to get stuff to run on systems other than Linux. Whenever one system becomes too popular, the definition of “Unix” drifts in that direction … d From bakul at bitblocks.com Thu Jan 9 13:43:50 2020 From: bakul at bitblocks.com (Bakul Shah) Date: Wed, 8 Jan 2020 19:43:50 -0800 Subject: [TUHS] screen editors In-Reply-To: <20200109030853.GH16808@mcvoy.com> References: <20200109012830.GC16808@mcvoy.com> <20200109020720.GG16808@mcvoy.com> <20200109030853.GH16808@mcvoy.com> Message-ID: <3CF02E3C-1BA4-4982-868C-709677FE2FF1@bitblocks.com> If this option was added back then (992-94) I might have switched over. I think I was tempted as it was “programmable”. But as it didn’t have any other new features that I really wanted plus I was always messing up undo/redo, probably like Clem, there was not much point in switching. As it happens, I didn’t use the programmability feature even when it was added to nvi! No point in advocating as anyone who is used to the “more” of vim would be frustrated with nvi! > On Jan 8, 2020, at 7:08 PM, Larry McVoy wrote: > > I feel like there is an option to get nvi behaviour now but I dunno > why you want that. Are you seriously advocating for less? Because > objectively vim gives you more. > > And it is faithful to vi, it has all the buffers so you can put stuff > back that way. > > Maybe I'm clueless or I drank the koolaid, but I love vim. It's vi > but better. > > On Wed, Jan 08, 2020 at 06:59:02PM -0800, Bakul Shah wrote: >> Early in vim???s life I had emailed Moolenaar asking him if he would be >> willing to add an option for nvi like behavior for undo/redo. He wasn???t >> interested so I lost interest. nvi???s u & . behavior is not only quite clever >> but also much more intuitive and you don???t have to press the ctl key! >> >>> On Jan 8, 2020, at 6:12 PM, Clem Cole wrote: >>> >>> make a new command, don't break the old one.... maybe offer a way to map the new one over the old -- but don't make it the default. >>> and my lawn was lush and green before the snow came ;-) >>> >>> >>> >>> On Wed, Jan 8, 2020 at 9:07 PM Larry McVoy wrote: >>> On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote: >>>> On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah wrote: >>>> >>>>> The first thing I do on a new machine is to install nvi. Very grateful to >>>>> Keith Bostic for implementing it. I do use multiple windows ??? only >>>>> horizontal splits but that is good enough for me as all my terminal >>>>> windows are 80 chars wide. Not a vim hater but never saw the need. >>>> >>>> I pretty much do the same thing. I think what I hate about vim is that it's >>>> almost, vi but not the same. My fingers screw up when I use it. For >>>> instance, he 'fixed' undo. >>> >>> Holy crap Clem, you need to embrace that. His undo goes back forever. >>> And you can undo the undo and go forward forever. >>> >>> Not liking that puts you in the "get off my lawn" old guy camp. Which >>> is fine if that's who you want to be (sometimes I'm that guy). > > -- > --- > Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From bakul at bitblocks.com Thu Jan 9 13:49:49 2020 From: bakul at bitblocks.com (Bakul Shah) Date: Wed, 8 Jan 2020 19:49:49 -0800 Subject: [TUHS] screen editors In-Reply-To: <4b810af6-1880-92c2-ef22-4029643d5225@mhorton.net> References: <20200109012830.GC16808@mcvoy.com> <20200109020720.GG16808@mcvoy.com> <4b810af6-1880-92c2-ef22-4029643d5225@mhorton.net> Message-ID: <2314D256-9C93-4496-B983-28DE4880F625@bitblocks.com> It doesn’t work the same way. I just tried it (vim-8.0.something). The way it is supposed to work is this: the first u undoes the last change. Then you keep hitting . to keep undoing more. Then if you went back too far, you hit u again, to undo the undo and further . will keep redoing. You can go back and forth this way as many times as you wish. > On Jan 8, 2020, at 7:27 PM, Mary Ann Horton wrote: > > vim has an option to undo the vi way. "set cpoptions=u". There is a full set of vi-compatible options if you want them. "set cp" turns on full vi compatiblity. > Funny, I see vim as the vi that comes with UNIX, and never learned the enhancements, but I just tried it out and I don't have the compatibility option set. I don't seem to have noticed. I guess I don't do the "undo toggle" all that often. > > Mary Ann > On 1/8/20 6:12 PM, Clem Cole wrote: >> make a new command, don't break the old one.... maybe offer a way to map the new one over the old -- but don't make it the default. >> and my lawn was lush and green before the snow came ;-) >> >> >> >> On Wed, Jan 8, 2020 at 9:07 PM Larry McVoy wrote: >> On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote: >> > On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah wrote: >> > >> > > The first thing I do on a new machine is to install nvi. Very grateful to >> > > Keith Bostic for implementing it. I do use multiple windows ??? only >> > > horizontal splits but that is good enough for me as all my terminal >> > > windows are 80 chars wide. Not a vim hater but never saw the need. >> > >> > I pretty much do the same thing. I think what I hate about vim is that it's >> > almost, vi but not the same. My fingers screw up when I use it. For >> > instance, he 'fixed' undo. >> >> Holy crap Clem, you need to embrace that. His undo goes back forever. >> And you can undo the undo and go forward forever. >> >> Not liking that puts you in the "get off my lawn" old guy camp. Which >> is fine if that's who you want to be (sometimes I'm that guy). From mah at mhorton.net Thu Jan 9 13:55:59 2020 From: mah at mhorton.net (Mary Ann Horton) Date: Wed, 8 Jan 2020 19:55:59 -0800 Subject: [TUHS] screen editors In-Reply-To: <2314D256-9C93-4496-B983-28DE4880F625@bitblocks.com> References: <20200109012830.GC16808@mcvoy.com> <20200109020720.GG16808@mcvoy.com> <4b810af6-1880-92c2-ef22-4029643d5225@mhorton.net> <2314D256-9C93-4496-B983-28DE4880F625@bitblocks.com> Message-ID: <1442b5d7-12af-86ef-c7de-fa92f848d5ce@mhorton.net> Are you referring to the special case where an undo of "p" (put) will sucessively re-insert the most recent things you've deleted? I just tried that in vim and it didn't seem to support the special case the way vi did.     Mary Ann On 1/8/20 7:49 PM, Bakul Shah wrote: > It doesn’t work the same way. I just tried it (vim-8.0.something). > The way it is supposed to work is this: the first u undoes the last change. > Then you keep hitting . to keep undoing more. Then if you went back too far, > you hit u again, to undo the undo and further . will keep redoing. You can > go back and forth this way as many times as you wish. > >> On Jan 8, 2020, at 7:27 PM, Mary Ann Horton wrote: >> >> vim has an option to undo the vi way. "set cpoptions=u". There is a full set of vi-compatible options if you want them. "set cp" turns on full vi compatiblity. >> Funny, I see vim as the vi that comes with UNIX, and never learned the enhancements, but I just tried it out and I don't have the compatibility option set. I don't seem to have noticed. I guess I don't do the "undo toggle" all that often. >> >> Mary Ann >> On 1/8/20 6:12 PM, Clem Cole wrote: >>> make a new command, don't break the old one.... maybe offer a way to map the new one over the old -- but don't make it the default. >>> and my lawn was lush and green before the snow came ;-) >>> >>> >>> >>> On Wed, Jan 8, 2020 at 9:07 PM Larry McVoy wrote: >>> On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote: >>>> On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah wrote: >>>> >>>>> The first thing I do on a new machine is to install nvi. Very grateful to >>>>> Keith Bostic for implementing it. I do use multiple windows ??? only >>>>> horizontal splits but that is good enough for me as all my terminal >>>>> windows are 80 chars wide. Not a vim hater but never saw the need. >>>> I pretty much do the same thing. I think what I hate about vim is that it's >>>> almost, vi but not the same. My fingers screw up when I use it. For >>>> instance, he 'fixed' undo. >>> Holy crap Clem, you need to embrace that. His undo goes back forever. >>> And you can undo the undo and go forward forever. >>> >>> Not liking that puts you in the "get off my lawn" old guy camp. Which >>> is fine if that's who you want to be (sometimes I'm that guy). From jon at fourwinds.com Thu Jan 9 14:23:50 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Wed, 08 Jan 2020 20:23:50 -0800 Subject: [TUHS] screen editors In-Reply-To: References: <20200109012830.GC16808@mcvoy.com> <20200109020720.GG16808@mcvoy.com> Message-ID: <202001090423.0094NooZ379407@darkstar.fourwinds.com> Clem Cole writes: > > make a new command, don't break the old one.... maybe offer a way to map > the new one over the old -- but don't make it the default. > and my lawn was lush and green before the snow came ;-) Clem, this seems like an unusual position for you to take. vim is backwards compatible with vi (and also ed), so it added to an existing ecosystem. Jon From brad.harder at gmail.com Thu Jan 9 14:33:38 2020 From: brad.harder at gmail.com (bch) Date: Wed, 8 Jan 2020 20:33:38 -0800 Subject: [TUHS] screen editors (Bakul Shaw) In-Reply-To: References: Message-ID: Date: Wed, 8 Jan 2020 17:40:10 -0800 > From: Bakul Shah > To: Larry McVoy > Cc: Warner Losh , The Eunuchs Hysterical Society > > Subject: Re: [TUHS] screen editors > Message-ID: > Content-Type: text/plain; charset=utf-8 > > On Jan 8, 2020, at 5:28 PM, Larry McVoy wrote: > > > > On Wed, Jan 08, 2020 at 05:08:59PM -0700, Warner Losh wrote: > >> On Wed, Jan 8, 2020, 4:22 PM Dave Horsfall wrote: > >> > >>> On Wed, 8 Jan 2020, Chet Ramey wrote: > >>> > >>>>> That's a real big vi in RHL. > >>>> > >>>> It's vim. > >>> > >>> It's also VIM on the Mac. > >>> > >> > >> Nvi is also interesting and 1/10th the size of vim. It's also the > FreeBSD > >> default for vi. > > > > I was gonna stay out of this thread (it has the feel of old folks > somehow) > > but 2 comments: > > > > Keith did nvi (I can't remember why? licensing or something) and he did > > a pretty faithful bug for bug compatible job. I've always wondered why. > > I like Keith but it seemed like a waste. There were other people taking > > vi forward, elvis, xvi (I hacked the crap out of that one, made it mmap > > the file and had a whole string library that treated \n like NULL) and > > I think vim was coming along. So doing a compat vi felt like a step > > backward for me. > > > > For all the vim haters, come on. Vim is awesome, it gave me the one > > thing that I wanted from emacs, multiple windows. I use that all the > > time. It's got piles of stuff that I don't use, probably should, but > > it is every bit as good of a vi as the original and then it added more. > > I'm super grateful that vim came along. > > The first thing I do on a new machine is to install nvi. Very grateful to > Keith Bostic for implementing it. I do use multiple windows — only > horizontal splits but that is good enough for me as all my terminal > windows are 80 chars wide. Not a vim hater but never saw the need. > Not sure if you’re saying horizontal splits are all you need, or all you’re aware of, but nvi “:E somefile” will split to a top/bottom arrangement and “:vsplit somefile” will do a left/right arrangement, as well as being able to “:fg”, “:bg” screens. I too am a (NetBSD) nvi appreciator. -bch -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Thu Jan 9 14:56:51 2020 From: athornton at gmail.com (Adam Thornton) Date: Wed, 8 Jan 2020 21:56:51 -0700 Subject: [TUHS] What happened with XENIX? (was Re: Unix/World Magazines) In-Reply-To: References: <20200107105615.GA16081@minnie.tuhs.org> <0813f7fb-dd3d-e5a1-299e-42b9c34cdcf8@gmail.com> Message-ID: On Jan 8, 2020, at 8:25 PM, David Arnold wrote: > Whenever one system becomes too popular, the definition of “Unix” drifts in that direction … “All the world’s a VAX” became “All the world’s a Linux/x86 box” about 1996, and then in 2010 or so, “all the world’s a Linux/amd64 box.” At least ARM saved us from another total processor monoculture. Adam From jon at fourwinds.com Thu Jan 9 14:33:28 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Wed, 08 Jan 2020 20:33:28 -0800 Subject: [TUHS] new topic - some C and filesystem history Message-ID: <202001090433.0094XTO9381250@darkstar.fourwinds.com> Working on a new project that's unfortunately going to require some changes to the linux kernel. Lived a lot of my life in the embedded world, haven't touched a *NIX kernel since 4.3BSD. Am writing a travelogue as I find my way around the code. Wasn't planning another book but this might end up being one. Anyway, a few questions... Was looking at the filesystem super_block structure. A large number of the members of the structure (but not all) begin with a s_ prefix, and some of the member names are in the 20 character long range. I recall that using prefixes was necessary before structures and unions had their own independent namespaces. But I also seem to recall that that was fixed before long identifier names happened. Does anybody remember the ordering for these two events? Also, anybody know where the term superblock originated? With what filesystem? Jon From gtaylor at tnetconsulting.net Thu Jan 9 15:01:04 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 8 Jan 2020 22:01:04 -0700 Subject: [TUHS] screen editors In-Reply-To: References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU> <20200107023834.GN20269@mcvoy.com> <202001071630.007GUrBj030452@freefriends.org> Message-ID: On 1/7/20 12:14 PM, Thomas Paulsen wrote: > I do ed/se occasionally for simple tasks Was that supposed to be "sed"? Or is "se" something that I'm not familiar with? -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From bakul at bitblocks.com Thu Jan 9 15:27:02 2020 From: bakul at bitblocks.com (Bakul Shah) Date: Wed, 8 Jan 2020 21:27:02 -0800 Subject: [TUHS] screen editors In-Reply-To: <1442b5d7-12af-86ef-c7de-fa92f848d5ce@mhorton.net> References: <20200109012830.GC16808@mcvoy.com> <20200109020720.GG16808@mcvoy.com> <4b810af6-1880-92c2-ef22-4029643d5225@mhorton.net> <2314D256-9C93-4496-B983-28DE4880F625@bitblocks.com> <1442b5d7-12af-86ef-c7de-fa92f848d5ce@mhorton.net> Message-ID: <70DD8BD7-DF59-4C8D-9611-815B83A18106@bitblocks.com> Short answer: there is no special case in nvi. P or p put back the contents of the last delete. u undoes whatever was the last change (including the last undo or redo). . repeats whatever was the last modifying command. A detailed answer would merely confuse you. At least my attempt at it! Suggest you try out various combinations in nvi and compare with vim. > On Jan 8, 2020, at 7:55 PM, Mary Ann Horton wrote: > > Are you referring to the special case where an undo of "p" (put) will sucessively re-insert the most recent things you've deleted? > > I just tried that in vim and it didn't seem to support the special case the way vi did. > > Mary Ann > > On 1/8/20 7:49 PM, Bakul Shah wrote: >> It doesn’t work the same way. I just tried it (vim-8.0.something). >> The way it is supposed to work is this: the first u undoes the last change. >> Then you keep hitting . to keep undoing more. Then if you went back too far, >> you hit u again, to undo the undo and further . will keep redoing. You can >> go back and forth this way as many times as you wish. >> >>> On Jan 8, 2020, at 7:27 PM, Mary Ann Horton wrote: >>> >>> vim has an option to undo the vi way. "set cpoptions=u". There is a full set of vi-compatible options if you want them. "set cp" turns on full vi compatiblity. >>> Funny, I see vim as the vi that comes with UNIX, and never learned the enhancements, but I just tried it out and I don't have the compatibility option set. I don't seem to have noticed. I guess I don't do the "undo toggle" all that often. >>> >>> Mary Ann >>> On 1/8/20 6:12 PM, Clem Cole wrote: >>>> make a new command, don't break the old one.... maybe offer a way to map the new one over the old -- but don't make it the default. >>>> and my lawn was lush and green before the snow came ;-) >>>> >>>> >>>> >>>> On Wed, Jan 8, 2020 at 9:07 PM Larry McVoy wrote: >>>> On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote: >>>>> On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah wrote: >>>>> >>>>>> The first thing I do on a new machine is to install nvi. Very grateful to >>>>>> Keith Bostic for implementing it. I do use multiple windows ??? only >>>>>> horizontal splits but that is good enough for me as all my terminal >>>>>> windows are 80 chars wide. Not a vim hater but never saw the need. >>>>> I pretty much do the same thing. I think what I hate about vim is that it's >>>>> almost, vi but not the same. My fingers screw up when I use it. For >>>>> instance, he 'fixed' undo. >>>> Holy crap Clem, you need to embrace that. His undo goes back forever. >>>> And you can undo the undo and go forward forever. >>>> >>>> Not liking that puts you in the "get off my lawn" old guy camp. Which >>>> is fine if that's who you want to be (sometimes I'm that guy). From arnold at skeeve.com Thu Jan 9 18:30:02 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 09 Jan 2020 01:30:02 -0700 Subject: [TUHS] screen editors In-Reply-To: References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU> <20200107023834.GN20269@mcvoy.com> <202001071630.007GUrBj030452@freefriends.org> Message-ID: <202001090830.0098U2nq019546@freefriends.org> Mary Ann Horton wrote: > Nearly everyone at Bell Labs (outside area 11) was using either vi or > emacs, but System III just had ed. There was a big push to add vi or > emacs to UNIX 3.0 (System III), but USG instead chose to write se, the > "screen editor" and put it in UNIX 4.0. Nobody would use it, so UNIX 5.0 > (System V) relented and included vi. Thanks for confirming that se existed in Unix 4.0, as I remember it. I used it some; the only thing I remember about it was that the command line was at the top of the screen. I must have been disappointed with it, because I ended up doing most of my contract programming work in ed. :-) It'd be interesting to see the source for this 'se', but it's probably lost forever. Arnold From thomas.paulsen at firemail.de Thu Jan 9 19:05:48 2020 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Thu, 09 Jan 2020 10:05:48 +0100 Subject: [TUHS] screen editors In-Reply-To: References: Message-ID: <474f81dd98f8143b5875fda2bf10345d@firemail.de> > Nvi is also interesting and 1/10th the size of vim. It's also the FreeBSD default for vi. check out elvis https://github.com/mbert/elvis vi + syntax highlighting + clean help subsystem = ~ 25% of size of vim From clemc at ccc.com Fri Jan 10 01:54:44 2020 From: clemc at ccc.com (Clem Cole) Date: Thu, 9 Jan 2020 10:54:44 -0500 Subject: [TUHS] screen editors In-Reply-To: <202001090423.0094NooZ379407@darkstar.fourwinds.com> References: <20200109012830.GC16808@mcvoy.com> <20200109020720.GG16808@mcvoy.com> <202001090423.0094NooZ379407@darkstar.fourwinds.com> Message-ID: Answering, but CCing COFF if folks want to continue. This is less about UNIX and more about how we all got to where we are. On Wed, Jan 8, 2020 at 11:24 PM Jon Steinhart wrote: > Clem, this seems like an unusual position for you to take. vim is > backwards > compatible with vi (and also ed), so it added to an existing ecosystem. > No, really unusually when you think about it. vim is backward compatible except when it's not (as Bakul points out) - which is my complaint. It's *almost* compatible and those small differences are really annoying when you expect one thing and get something else (*i.e.* the least astonishment principle). The key point here is for *some people*, those few differences are not an issue and are not astonished by them. But for *some of the rest of us* (probably people like me that have used the program since PDP-11 days) that only really care about the original parts, the new stuff is of little value and so the small differences are astonishing. Which comes back to the question of good and best. It all depends on one what you value/where you put the high order bit. I'm not willing to "pay" for the it; as it gives me little value. Doug started this thread with his observation that ex/vi was huge compared to other editors. * i.e.* value: small simple easy to understand (Rob's old "*cat -v considered harmful*" argument if you will). The BSD argument had always been: "the new stuff is handy." The emacs crew tends to take a similar stand. I probably don't go quite as far as Rob, but I certainly lean in that direction. I generally would rather something small and new that solves a different (set of) problem(s), then adding yet another wart on to an older program, *particularly when you change the base functionality *- which is my vi *vs. *vim complaint*.* [i.e. 'partial credit' does not cut it]. To me, another good example is 'more', 'less' and 'pg'. Eric Schienbrood wrote the original more(ucb) to try to duplicate the ITS functionality (he wrote it for the PDP-11/70 in Cory Hall BTW - Ernie did not exist and 4.1BSD was a few years in the future - so small an simple of a huge value). It went out in the BSD tapes, people loved it and were happy. It solved a problem as we had it. Life was good. Frankly, other than NIH, I'm not sure why the folks at AT&T decided to create pg a few years later since more was already in the wild, but at least it was a different program (Mary Ann's story of vi *vs*. se if probably in the same vein). But because of that behavior, if someone like me came to an AT&T based system with only pg installed, so those of us that liked/were used to more(ucb) could install it and life was good. Note pg was/is different in functionality, it's similar, but not finger compatible. But other folks seem to have thought neither was 'good enough' -- thus later less(gnu) was created adding a ton of new functionality to Eric's program. The facts are clear, some (ney many) people >>love<< that new functionality, like going backward. I >>personally<< rarely care/need for it, Eric's program was (is) good enough for me. Like Doug's observation of ed *vs.* ex/vi; less is huge compared to the original more (or pg for that matter). But if you value the new features, I suspect you might think that's not an issue. Thanks to Moore's law, the size in this case probably does not matter too much (other than introducing new bugs). At least, when folks wrote did Gnu's less, the basic more(ucb) behavior was left along and if you set PAGER=more less(gnu) pretty much works as I expect it too. So I now don't bring Eric's program with me, the same way Bakul describes installing nvi on new systems (an activiity I also do). Back to vi *vs.* nvi *vs.* vim *et. al.* Frankly, in my own case, I do >>occaisonally<< use split screens, but frankly, I can get most of the same from having a window manager, different iterm2 windows and cut/paste. So even that extension to nvi, is of limited value to me. vim just keeps adding more and more cruft and its even bigger. I personally don't care for the new functionality, and the size of it all is worrisome. What am I buying? That said, if the new features do not hurt me, then I don't really care. I might even use some of the new functionality - hey I run mac OS not v7 or BSD 4.x for my day to day work and I do use the mac window manager, the browser *et al*, but as I type this message I have 6 other iterm2 windows open with work I am doing in other areas. Let me take a look at this issue in a different way. I have long been a 'car guy' and like many of those times in my youth spent time and money playing/racing etc. I've always thought electric was a great idea/but there has been nothing for me. Note: As many of you know my work in computers has been in HPC, and I've been lucky to spend a lot of time with my customers, in the auto and aerospace industry (*i.e.* the current Audi A6 was designed on one of my supercomputer systems). The key point is have tended to follow technology in their area and tend to "in-tune" with a lot of developments. The result, except for my wife's minivan (that she preferred in the years when our kids were small), I've always been a die-hard German-engineered/performance car person. But when Elon announced the Model 3 (like 1/2 the techie world), I put down a deposit and waited. Well why I was waiting, my techie daughter (who also loves cars), got a chance to drive one. She predicted I would hate it!!! So when my ticket finally came up, I went to drive them. She was right!!! With the Model 3, you get a cool car, but it's about the size of a Corrolla. Coming from Germans cars for the last 35 years, the concept of spending $60K US in practice for a Corrolla just did not do it for me. I ended up ordering the current Unixmobile, my beloved Tesla Model S/P100D. The truth is, I paid a lot of money for it but I *value *what I got for my money. A number of people don't think it's worth it. I get that, but I'm still happy with what I have. Will there someday be a $20K electric car like my Model S? While I think electric cars will get there (I point out the same price curve on technology such microwave ovens from the 1970so today), but I actually doubt that there will be a $20K electric vehicle like my Model S. The reason is that to sell this car because it as to be expensive for technology-based reasons, so Tesla had to add a lot of 'luxury' features like other cars in the class, other sports cars, Mercedes, *et al*. As they removed them (*i.e.* the Model 3) you still get a cool car, but it's not at all the same as the Model S. So the point is, if I wanted an electric car, I had to choose between a performance/luxury *vs*. size/functionality. I realized I valued the former (and still do), but I understand not everyone does or will. Coming back to our topic, I really don't think this is a 'get my lawn' issue as much, as asking someone what they really value/what they really need. If you place a high-value you something, you will argue that its best; if it has little value you will not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Fri Jan 10 03:21:40 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Thu, 09 Jan 2020 09:21:40 -0800 Subject: [TUHS] screen editors In-Reply-To: References: <20200109012830.GC16808@mcvoy.com> <20200109020720.GG16808@mcvoy.com> <202001090423.0094NooZ379407@darkstar.fourwinds.com> Message-ID: <202001091721.009HLf2V503811@darkstar.fourwinds.com> Clem Cole writes: > > Answering, but CCing COFF if folks want to continue. This is less about > UNIX and more about how we all got to where we are. > > On Wed, Jan 8, 2020 at 11:24 PM Jon Steinhart wrote: > > > Clem, this seems like an unusual position for you to take. vim is > > backwards > > compatible with vi (and also ed), so it added to an existing ecosystem. > > > No, really unusually when you think about it. vim is backward compatible > except when it's not (as Bakul points out) - which is my complaint. It's > *almost* compatible and those small differences are really annoying when > you expect one thing and get something else (*i.e.* the least astonishment > principle). > > ... OK, ok, the point that it's not 100% compatible wins the day. Couple more points and then it's time to move on. While I spend a lot of time railing against bad programming, the fact that vim is huge doesn't bother me too much because my machine has more memory that the machine on which I started using vi had disk. And just because it still blows my mind, my machine (on just one of the drives) has more disk than was available in the world when I started using vi. Good chance that my CPU has more cache memory than the PDP-11/70 on which I started using vi had main memory. So the size doesn't matter too much for me. One of the reasons that I chose vi over emacs was architectural. At a certain level, vi was a text editor and emacs was an operating system, and since I was running UNIX and was a UNIX philosophy person I just didn't want to be running an operating system on top of an operating system just to do text editing. It's for that reason that I hate the addition of multiple windows to vi. I already have a windowing system on my machine, and that's what I use for windows. To me, the correct thing to do is to open a new desktop window to edit a new file and start a new instance of vi, not to use vi to open another internal window. I guess that what I'm saying is that I think that rather than following the UNIX philosophy of having distinct tools and composing, much modern software tries to do too much stuff that's not unique to its domain. A strained analogy would be if every "little language" felt that it had to re-implement a big language too. Jon From imp at bsdimp.com Fri Jan 10 03:30:07 2020 From: imp at bsdimp.com (Warner Losh) Date: Thu, 9 Jan 2020 10:30:07 -0700 Subject: [TUHS] screen editors In-Reply-To: <202001091721.009HLf2V503811@darkstar.fourwinds.com> References: <20200109012830.GC16808@mcvoy.com> <20200109020720.GG16808@mcvoy.com> <202001090423.0094NooZ379407@darkstar.fourwinds.com> <202001091721.009HLf2V503811@darkstar.fourwinds.com> Message-ID: On Thu, Jan 9, 2020 at 10:22 AM Jon Steinhart wrote: > One of the reasons that I chose vi over emacs was architectural. At a > certain > level, vi was a text editor and emacs was an operating system, and since I > was > running UNIX and was a UNIX philosophy person I just didn't want to be > running > an operating system on top of an operating system just to do text editing. > I chose emacs because of muscle memory (Both the VAX and TOPS-20 machines at school had emacs as the default editor) and also because it lets me program better. I didn't let the fact it accomplished that by trying to be an OS or LISP-M or whatever get in the way of using the best tool for the job. In the 90s this meant that I had to be careful about the machines I used it on. These days, it just doesn't matter. Mostly, though, it was finger muscle memory :) Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Fri Jan 10 03:45:26 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Thu, 09 Jan 2020 09:45:26 -0800 Subject: [TUHS] screen editors and beyond In-Reply-To: References: <20200109012830.GC16808@mcvoy.com> <20200109020720.GG16808@mcvoy.com> <202001090423.0094NooZ379407@darkstar.fourwinds.com> <202001091721.009HLf2V503811@darkstar.fourwinds.com> Message-ID: <202001091745.009HjQ3L507739@darkstar.fourwinds.com> Warner Losh writes: > > I chose emacs because of muscle memory (Both the VAX and TOPS-20 machines > at school had emacs as the default editor) and also because it lets me > program better. I didn't let the fact it accomplished that by trying to be > an OS or LISP-M or whatever get in the way of using the best tool for the > job. In the 90s this meant that I had to be careful about the machines I > used it on. These days, it just doesn't matter. Mostly, though, it was > finger muscle memory :) > > Warner That's a great reason. I never did any bodybuilding with emacs so I have different muscle memory. There is another reason why I stayed away from emacs which is that I was running projects at the time - I had graduated from being an individual contributor. The multiple versions of emacs got in the way. We had too many instances where one person would ask another person for help or to review something, but people using different tools interfered with the ability of people to walk over to another terminal and get stuff done. Because of this, I made and enforced a rule that said that one could only use shell aliases if they didn't redefine any existing commands. It was important for people to be able to work together. Things were getting so flexible that it was as if everybody had their own custom power outlets at their desks preventing any other group member from coming over and plugging something in. Taking this in a different direction, one of the other rules that I enforced was "don't redefine the programming language." This is in my mind right now as I try to navigate the linux kernel. Someone obviously didn't like C and made a bunch of overly complicated constructs via macros to change it to something else generating bad code in the process. It reminded me of the first time that I ran across this, which was the Bourne shell in C redefined as Algol. I recently asked Steve about why he did this and he did give me an answer which he said I couldn't share until he refined it. He probably forgot over the holidays but since I think he's on this list maybe he'll weigh in. One amusing thing that Steve told me which I think I can share is why the symmetry of case-esac, if-fi was broken with with do-done; it was because the od command existed so do-od wouldn't work! Jon From bakul at bitblocks.com Fri Jan 10 03:56:07 2020 From: bakul at bitblocks.com (Bakul Shah) Date: Thu, 9 Jan 2020 09:56:07 -0800 Subject: [TUHS] screen editors In-Reply-To: <202001091721.009HLf2V503811@darkstar.fourwinds.com> References: <20200109012830.GC16808@mcvoy.com> <20200109020720.GG16808@mcvoy.com> <202001090423.0094NooZ379407@darkstar.fourwinds.com> <202001091721.009HLf2V503811@darkstar.fourwinds.com> Message-ID: <928BC725-0105-4B38-BC14-A8C04A3C4532@bitblocks.com> On Jan 9, 2020, at 9:21 AM, Jon Steinhart wrote: > > It's for that reason that I hate the addition of multiple windows to vi. I > already have a windowing system on my machine, and that's what I use for windows. > To me, the correct thing to do is to open a new desktop window to edit a new file > and start a new instance of vi, not to use vi to open another internal window. The Rand editor made good use of multiple windows. You could set things up so that two windows would scroll *in sync*. This is handy e.g. when you are looking at two columns or rows that far apart in the same file or in different files and too large so you need to scroll. Acme makes even better use of multiple windows. Right click on a compile error message in one window and the cursor moves the error causing line in the source file in another window etc. You can repeat as many times as you want. So I tend to think combining multiple windows and editing can be effective. > I guess that what I'm saying is that I think that rather than following the > UNIX philosophy of having distinct tools and composing, much modern software tries > to do too much stuff that's not unique to its domain. A strained analogy would be > if every "little language" felt that it had to re-implement a big language too. Finding the "right cut" of functionality is not easy. Scheme or Common Lisp? Editors and a set of tools or an all singing all dancing IDE? Can one implement something like Photoshop as a set of separate tools that can be combined any way? What old style Unix tools give you is isolation and (one way) controlled communication. Can this model be generalized to a set of Lego blocks out of which one can compose even complex tools such as Photoshop as easily is an open question. From lm at mcvoy.com Fri Jan 10 04:53:27 2020 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 9 Jan 2020 10:53:27 -0800 Subject: [TUHS] screen editors In-Reply-To: <202001091721.009HLf2V503811@darkstar.fourwinds.com> References: <20200109012830.GC16808@mcvoy.com> <20200109020720.GG16808@mcvoy.com> <202001090423.0094NooZ379407@darkstar.fourwinds.com> <202001091721.009HLf2V503811@darkstar.fourwinds.com> Message-ID: <20200109185327.GJ16808@mcvoy.com> On Thu, Jan 09, 2020 at 09:21:40AM -0800, Jon Steinhart wrote: > It's for that reason that I hate the addition of multiple windows to vi. That's just silly. I frequently open two panes on the same file. Lets compare: Your way: - click to open a new terminal - click on it because it's not where I want, move it - cd to where ever I am - vi whatever My way: :sp You are welcome to your opinion but to argue that multiple panes in vi aren't useful, fine, maybe not to you. Don't use them. Other people love that feature, that feature is why I tried emacs many years ago. From jon at fourwinds.com Fri Jan 10 05:01:28 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Thu, 09 Jan 2020 11:01:28 -0800 Subject: [TUHS] screen editors In-Reply-To: <20200109185327.GJ16808@mcvoy.com> References: <20200109012830.GC16808@mcvoy.com> <20200109020720.GG16808@mcvoy.com> <202001090423.0094NooZ379407@darkstar.fourwinds.com> <202001091721.009HLf2V503811@darkstar.fourwinds.com> <20200109185327.GJ16808@mcvoy.com> Message-ID: <202001091901.009J1StW520950@darkstar.fourwinds.com> Larry McVoy writes: > On Thu, Jan 09, 2020 at 09:21:40AM -0800, Jon Steinhart wrote: > > It's for that reason that I hate the addition of multiple windows to vi. > > That's just silly. I frequently open two panes on the same file. Lets > compare: > > Your way: > - click to open a new terminal > - click on it because it's not where I want, move it > - cd to where ever I am > - vi whatever > > My way: > :sp > > You are welcome to your opinion but to argue that multiple panes in > vi aren't useful, fine, maybe not to you. Don't use them. Other > people love that feature, that feature is why I tried emacs many > years ago. Yes, that is my opinion and clearly yours is different. Being as I have a huge hi-res screen, I often have other windows open and ready to do, so all I have to do is move the mouse. But really to me you're opening yet another can of worms, which is what I call the "string theory school of design" where every new program creates its own universe instead of functioning in the existing one. I'm working on a demonstration project to illuminate a different path, but it's gonna be a while before I have something to show. Jon From steffen at sdaoden.eu Fri Jan 10 05:02:19 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 09 Jan 2020 20:02:19 +0100 Subject: [TUHS] screen editors In-Reply-To: References: <20200109012830.GC16808@mcvoy.com> <20200109020720.GG16808@mcvoy.com> <202001090423.0094NooZ379407@darkstar.fourwinds.com> Message-ID: <20200109190219.bdHOi%steffen@sdaoden.eu> Clem Cole wrote in : |Answering, but  CCing COFF if folks want to continue.  This is less \ |about UNIX and more about how we all got to where we are. ... To me endless undo of vim is great, and i am used to it. I think i could compile a version from ~20 years ago, supposed to be much smaller, and i would be ok with it. You have other windows open, ok, but you have typed this in a browser that consumes more memory than all the programs running here altogether have (real), within a codebase that consists of millions and millions lines of code. I mean hey, even though decades of development and tens of thousands of eyes passed, i see super simple compiler errors in gcc and clang, and except for optimization maybe not that much improvement in useful diagnostics, even though the executables are 150 times and more greater than that. For example i have a netrc parser which uses a fixed size target buffer, in a 90 lines function, with comments, empty lines, and a static structure of token types to test-iterate against, and with a possibly *off++=by;*off='\0'; one, but it took a Coverity.com run to detect it. (Actually it is worse, because this code is from 2014, and it seems only the combination of gcc 8.3.0 and the current cov-analysis-linux64-2019.03 could find it; not in August, when i checked for the second to last, but only for the last check.) |Let me take a look at this issue in a different way.   I have long \ |been a 'car guy' and like many of those times in my youth spent time \ |and money playing/racing etc. I've always thought electric was a |great idea/but there has been nothing for me. Note: As many of you \ |know my work in computers has been in HPC, and I've been lucky to spend \ |a lot of time with my customers, in the auto and aerospace |industry (i.e. the current Audi A6 was designed on one of my supercomputer \ |systems).  The key point is have tended to follow technology in their \ |area and tend to "in-tune" with a lot of developments.  |The result, except for my wife's minivan (that she preferred in the \ |years when our kids were small), I've always been a die-hard German-eng\ |ineered/performance car person.  But when Elon announced |the Model 3 (like 1/2 the techie world), I put down a deposit and waited. | |Well why I was waiting, my techie daughter (who also loves cars), got \ |a chance to drive one.   She predicted I would hate it!!! So when my \ |ticket finally came up, I went to drive them.  She was right!!!  |With the Model 3, you get a cool car, but it's about the size of a \ |Corrolla.  Coming from Germans cars for the last 35 years, the concept \ |of spending $60K US in practice for a Corrolla just did not do it |for me.   I ended up ordering the current Unixmobile, my beloved Tesla \ |Model S/P100D.  Corolla is not $60K. So you want 500 horse power, maybe. |The truth is, I paid a lot of money for it but I value what I got for \ |my money. A number of people don't think it's worth it.  I get that, \ |but I'm still happy with what I have.   Will there someday be a |$20K electric car like my Model S?  While I think electric cars will \ |get there (I point out the same price curve on technology such microwave \ |ovens from the 1970so today), but I actually doubt that there |will be a $20K electric vehicle like my Model S. Well, lucky you that you can and want to spend that much money for a, hm, car. |The reason is that to sell this car because it as to be expensive for \ |technology-based reasons, so Tesla had to add a lot of 'luxury' features \ |like other cars in the class, other sports cars, Mercedes, |  et al.  As they removed them (i.e. the Model 3) you still get a cool \ |car, but it's not at all the same as the Model S.   So the point is, \ |if I wanted an electric car, I had to choose between a |performance/luxury vs. size/functionality.  I realized I valued the \ |former (and still do), but I understand not everyone does or will. So i for one _totally_ - totally! - disagree. It really drives me up the wall. You drive around with a 600 kilogramm or even heavier battery. You car is about 2000 kilogram. That is a lot of resource that needs to be digged, transported, assembled .. recycled, as far as that is possible. It increases the load on the streets, you know, trucks have a factor of an impact higher than cars. I mean, in America the difference is maybe not that big since the average car is very big on its own, i think a pick up is the most-selled car there for many years, with each instance being worth at least 2 of the German and Austrian etc. top seller. You can add to that entire Europe, including England. The entire car community did know at the end of the 80s / beginning of the 90s what is necessary for better Otto and Diesel engines, and as of today, thirty years later!, not all engines are actually using these technologies. There is nothing new at all regarding technology, nothing!, except of course materials engineering and robotics. That is a political declaration of bankruptcy. And i hate BMW top managers starting over with "the problem is not the SUV driver, the problem is the 15 year old family shooting brake". That is antisocial, ignorant, reckless and homicidal. And it was clear what the future after those combustion engines will be, and that is hydrogen. That is fuell cell and tank in sandwich floor, with wheel hub motors. The latter has always been my favourite, even though it could increase moved mass, but i do not know. So 120 years after wheel hub we choose two on-axe to reduce production cost. That is composite material. Luckily even some market-based industries have shown the fertility and will to develop further beyond what was there about 120 years ago, unfortunately we the Germans not, except for rare military developments, also decades ago. I said 26 years ago the best would be if each and every citizen would gain such a chassis, and the body would be up to each and everyone, [why not] with some "Trabant 601 based default". Even Tesla was interesting, fifteen or so years ago. Because they used the Lotus Elite chassis, which is about <800 Kilogramm. I personally am and always have been a total fan of Chapman's Philosophy, the lighter, the more beautiful. And if you want comfort and industrial mass production, take the Mazda MX-5, it is 1000 Kilogramm, and has 160 horse power. Your Tesla is still more powerful, because it has more than 320 horse power, but it is much heavier around the corners, and much much less swift. Of course, i see here in Germany in practice all men above 50 need their SUV now (thanks America for this future relevant trend), and they look relaxed, meaningful, potent. Yet they are not. See above. And they are not, beyond that. They reflect reckless degeneration. Yes, the white men's sperm production has halved, their allergies and woewoes have increased, their abuse of substances is enormous, and different to normal native human beings, entirely senseless and not embedded into any cultural surroundings. I mean, the heck. This wave has started, we now already explore digging much more of the necessary resources in the Atacama and maybe already in some Portuguese nature resource. We have interesting things which are maybe ok, like the Honda e. In the ever growing mega cities with the necessary infrastructure "i allow you to" use such city cars. It may make sense. What does not make sense is installing thousands of kilometers of copper cable to build up an infrastructure for high voltage battery filling. Really. That is copper. You know how much resources are required to produce copper? And in third countries our industry does not even give the minimum shit and uses the cheap most poisening elements to do its dirty work. No! Yes, just this week i think the German "Die Zeit" had an article on trash, trash everywhere, the trash island in the pacific is now as large as Texas they said, i know i have read about this island of trash in an early 80s book on open sea (sailing) accidents at the friend of my father, about 35 years ago, i blindly assume it was smaller by then. So only the one copper factory in Germany he was writing about produces more Trash than all European households altogether. That is just one. No! But there you go along with batteries. I mean they (Tesla) seem to have made their homework regarding crash safety, though i also disliked the crash test standards 26 years ago, and still back crashs are not tested, and they bang a solid cube regardless of the misalignment of at least the major masses that happens in practice if an Escalade hits an AMC Pacer. They seem to have created a new user experience that is also much cheaper to build (i do not like it), the cars have a tremendous power, and California has a nifty Energy Mix and infrastructure to satisfy full throttle fun. (Maybe.) I admit i was happy once a german car manager said dismissive words about Tesla (yesyesyes!), but again, just to find out they were doing and heading out for exactly the same. Except battery technology, maybe. Yes, i think the Porsche Taycan has an interesting design, i like especially the profile, i could maybe even like the interieur, for that one, but it is too heavy and uses the wrong technology. And no wood. I for one would not spend that much money for a car anyway, but if, definitely not like that. If i buy a CRV Hybrid, or a Suzuki Vitara, then i can buy a Caterham, a Lotus Elise, and almost a Morgan 3-Wheeler all in addition to end up at that price. See, the latter three are almost hand-built by human beings which perform craftsmanship, they do real jobs, and can go home prowd or at least somewhat fullfilled. Small companies. Buying and refining mass production engines (here Ford, Toyota, and S&S). And the CRV technology will at later times simply replace the combustion engine with a fuell cell. And it has some natural thing in it, a wooden strip. I personally like the Vitara, because it is only 1300 kilogramm, can tow enough for me, has a glass roof that can be opened, has LED lamps, does not contain any leather (no more), and if they will use the cylinder deactivation that i demanded almost thirty years ago, and maybe bring in the little Hybrid system they now introduce to their Ignis and Swift, i would go for it. The new Subaru Forester has a 16.7 horsepower electrical add-on. Enough for city traffic jam stop and go! Fiat has the wonderful two-cylindre engine in Panda and 500, 85 to 105 horsepower. A wonderful engine! Ford also, it has a wonderful three-cylindre engine. (I am talking Europe here, mind you.) And next year -- and here it comes! -- next year Toyota will come over with the new Mirai, real fuel-cell, refined, and not as a SUV!, and i think i will buy myself that one. |Coming back to our topic, I really don't think this is a 'get my lawn' \ |issue as much, as asking someone what they really value/what they really \ |need.   If you place a high-value you something, you will |argue that its best; if it has little value you will not.    In the end all that is industrial shit. If you are a lucky man you are science or worked at Bell Labs. The rest is all industrial shit, may it be pharmacy or medicine or whatever else. With all the little ones trying to get their place at the sun, recklessly. It is up to everyone to work on its own reflection and awareness, and to bring that work into all the many which are incapable to or uninterested in doing that. And unfortunately most do not. They are never shown, too, which makes me sad. I will now listen to the Westminster Abbey chorus singing Miserere mei Deus, just to let you know. And think how it must have been by then, with simplemost illnesses and wounds killing everyone from poor to rich, and with bad weather or other pest causing starvation and death, with regional food only, if you were lucky, not kilos of meat with cost backlog every day, when in early morning hours in a dark church the first sunlight would fall through handcrafted art- and passionful windows. --End of --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) From steffen at sdaoden.eu Fri Jan 10 05:19:02 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 09 Jan 2020 20:19:02 +0100 Subject: [TUHS] screen editors In-Reply-To: <20200109190219.bdHOi%steffen@sdaoden.eu> References: <20200109012830.GC16808@mcvoy.com> <20200109020720.GG16808@mcvoy.com> <202001090423.0094NooZ379407@darkstar.fourwinds.com> <20200109190219.bdHOi%steffen@sdaoden.eu> Message-ID: <20200109191902.kbJqz%steffen@sdaoden.eu> Steffen Nurpmeso wrote in <20200109190219.bdHOi%steffen at sdaoden.eu>: |Clem Cole wrote in : ... ||Let me take a look at this issue in a different way.   I have long \ ||been a 'car guy' and like many of those times in my youth spent time \ ||and money playing/racing etc. I've always thought electric was a ||great idea/but there has been nothing for me. Note: As many of you \ .. ||Coming back to our topic, I really don't think this is a 'get my lawn' \ ||issue as much, as asking someone what they really value/what they really \ ||need.   If you place a high-value you something, you will ||argue that its best; if it has little value you will not.    What else. All the many, many reports and expert assessments which suddenly appear and point out to the last cent that and why battery cars are better for the environment than anything else, including fuell cell driven cars. Heck, how i hate those. --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) From mah at mhorton.net Fri Jan 10 06:20:20 2020 From: mah at mhorton.net (Mary Ann Horton) Date: Thu, 9 Jan 2020 12:20:20 -0800 Subject: [TUHS] screen editors In-Reply-To: References: <20200109012830.GC16808@mcvoy.com> <20200109020720.GG16808@mcvoy.com> <202001090423.0094NooZ379407@darkstar.fourwinds.com> Message-ID: <52523c5b-ef07-65c8-86d9-2af6b6af20e4@mhorton.net> Yes, I totally agree. NIH was rampant at Bell Labs in the 1980s. Management pushed us to use the internal tools rather than external tools we liked better. 3B vs Sun comes to mind. Datakit vs TCP/IP.     Mary Ann On 1/9/20 7:54 AM, Clem Cole wrote: > Frankly, other than NIH, I'm not sure why the folks at AT&T decided to > create pg a few years later since more was already in the wild, but at > least it was a different program (Mary Ann's story of vi /vs/. se if > probably in the same vein). -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Fri Jan 10 07:46:44 2020 From: norman at oclsc.org (Norman Wilson) Date: Thu, 09 Jan 2020 16:46:44 -0500 Subject: [TUHS] screen editors Message-ID: <1578606407.15159.for-standards-violators@oclsc.org> Do we really need another boring old editor war? The topic is not specific to UNIX in the least; nor, alas, is it historic. Norman Wilson Toronto ON (typing this in qed) From norman at oclsc.org Fri Jan 10 07:53:25 2020 From: norman at oclsc.org (Norman Wilson) Date: Thu, 09 Jan 2020 16:53:25 -0500 Subject: [TUHS] screen editors and beyond Message-ID: <1578606809.15476.for-standards-violators@oclsc.org> Jon Steinhart: One amusing thing that Steve told me which I think I can share is why the symmetry of case-esac, if-fi was broken with with do-done; it was because the od command existed so do-od wouldn't work! ===== As I heard the story in the UNIX room decades ago (and at least five years after the event), Steve tried and tried to convince Ken to rename od so that he could have the symmetry he wanted. Ken was unmoved. Norman Wilson Toronto ON From rich.salz at gmail.com Fri Jan 10 07:55:51 2020 From: rich.salz at gmail.com (Richard Salz) Date: Thu, 9 Jan 2020 16:55:51 -0500 Subject: [TUHS] screen editors and beyond In-Reply-To: <1578606809.15476.for-standards-violators@oclsc.org> References: <1578606809.15476.for-standards-violators@oclsc.org> Message-ID: At first I wanted to know why having an "od" command interfered with the shell's source code of #define, but then I realized y-all meant the control structures for scripting :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Jan 10 08:01:19 2020 From: clemc at ccc.com (Clem Cole) Date: Thu, 9 Jan 2020 17:01:19 -0500 Subject: [TUHS] screen editors and beyond In-Reply-To: <1578606809.15476.for-standards-violators@oclsc.org> References: <1578606809.15476.for-standards-violators@oclsc.org> Message-ID: On Thu, Jan 9, 2020 at 4:54 PM Norman Wilson wrote: > As I heard the story in the UNIX room decades ago (and at least five > years after the event), Steve tried and tried to convince Ken to > rename od so that he could have the symmetry he wanted. Ken was > unmoved. I admit I'm not sure which solution is 'least astonishing.' Just think if DEC had used hex for years, instead of octal ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From brantley at coraid.com Fri Jan 10 08:10:39 2020 From: brantley at coraid.com (Brantley Coile) Date: Thu, 9 Jan 2020 22:10:39 +0000 Subject: [TUHS] screen editors In-Reply-To: <1578606407.15159.for-standards-violators@oclsc.org> References: <1578606407.15159.for-standards-violators@oclsc.org> Message-ID: <99522F07-91F6-4D0C-AD04-97A05817931A@coraid.com> Why not? It's kind of nostalgic. I got to watch my first editor war back in 1983 on my newly installed netnews. The reasoning seems to be the same, only the names have changed. But then again, your reasoning makes sense. And besides, it's been all down hill since qed. > On Jan 9, 2020, at 4:46 PM, Norman Wilson wrote: > > Do we really need another boring old editor war? The topic > is not specific to UNIX in the least; nor, alas, is it historic. > > Norman Wilson > Toronto ON > (typing this in qed) From wkt at tuhs.org Fri Jan 10 09:04:27 2020 From: wkt at tuhs.org (Warren Toomey) Date: Fri, 10 Jan 2020 09:04:27 +1000 Subject: [TUHS] Editors -> COFF Message-ID: <20200109230427.GB21654@minnie.tuhs.org> All, I think the editor thread needs to move to COFF now :-) Thanks, Warren From robpike at gmail.com Fri Jan 10 11:52:53 2020 From: robpike at gmail.com (Rob Pike) Date: Fri, 10 Jan 2020 12:52:53 +1100 Subject: [TUHS] screen editors and beyond In-Reply-To: References: <1578606809.15476.for-standards-violators@oclsc.org> Message-ID: I wrote xd for a reason. -rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From meillo at marmaro.de Fri Jan 10 18:13:04 2020 From: meillo at marmaro.de (markus schnalke) Date: Fri, 10 Jan 2020 09:13:04 +0100 Subject: [TUHS] screen editors In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> Message-ID: <1ippPk-8PE-00@marmaro.de> Hoi. [2020-01-09 08:49] Dave Horsfall > On Wed, 8 Jan 2020, Thomas Paulsen wrote: > > > I do ed/se occasionally for simple tasks, vim frequently , > > because it loads fast, and emacs for all bigger projects, > > beside liteide for golang. > > I had a boss once who insisted that all his staff learn "ed", > because one day it might be the only editor available; he was > right... On a modern Linux system, ed isn't even installed ... 8-O I was quite shocked when I first realized that I had to do `apt-get install ed' to have it available ... on a Unix-like system. But on the other hand, who of today's users is even capable of exiting it?! On my own systems I like to install Heirlomm ed, which I have outfactored from the Heirloom tools package. If you want to actually use it every now and then, Gunnar's ed is much more usable than GNU ed ... which seems to be more a demonstration object than actually a programmer's editor. Anyways, I'm having a great pleasure reading those historic spotlights on editors these days. :-) meillo From ricercar at lycos.com Fri Jan 10 18:16:49 2020 From: ricercar at lycos.com (ricercar at lycos.com) Date: Fri, 10 Jan 2020 08:16:49 +0000 Subject: [TUHS] screen editors In-Reply-To: References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU> <20200107023834.GN20269@mcvoy.com> <202001071630.007GUrBj030452@freefriends.org> Message-ID: On 1/9/20 5:01 AM, Grant Taylor via TUHS wrote: > On 1/7/20 12:14 PM, Thomas Paulsen wrote: >> I do ed/se occasionally for simple tasks > Was that supposed to be "sed"?  Or is "se" something that I'm not > familiar with? > I think he is referring to http://se-editor.org/, mentioned earlier in the thread. vks -------------- next part -------------- An HTML attachment was scrubbed... URL: From ullbeking at andrewnesbit.org Fri Jan 10 18:17:46 2020 From: ullbeking at andrewnesbit.org (U'll Be King of the Stars) Date: Fri, 10 Jan 2020 08:17:46 +0000 Subject: [TUHS] screen editors In-Reply-To: <1ippPk-8PE-00@marmaro.de> References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> Message-ID: On 10/01/2020 08:13, markus schnalke wrote: > GNU ed [...] seems to be more a demonstration > object than actually a programmer's editor. Hi Markus, in what way is GNU ed a "demonstration object"? Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9 From ullbeking at andrewnesbit.org Fri Jan 10 22:26:24 2020 From: ullbeking at andrewnesbit.org (Andrew Luke Nesbit) Date: Fri, 10 Jan 2020 12:26:24 +0000 Subject: [TUHS] screen editors and beyond In-Reply-To: References: <1578606809.15476.for-standards-violators@oclsc.org> Message-ID: <711e73ee-6acd-95b8-6f81-15e2af05ac7f@andrewnesbit.org> On 10/01/2020 01:52, Rob Pike wrote: > I wrote xd for a reason. What is xd? Please could you send a link to it? Thank you!! Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9 From vanattenmark at gmail.com Fri Jan 10 23:15:43 2020 From: vanattenmark at gmail.com (Mark van Atten) Date: Fri, 10 Jan 2020 14:15:43 +0100 Subject: [TUHS] screen editors and beyond In-Reply-To: <711e73ee-6acd-95b8-6f81-15e2af05ac7f@andrewnesbit.org> References: <1578606809.15476.for-standards-violators@oclsc.org> <711e73ee-6acd-95b8-6f81-15e2af05ac7f@andrewnesbit.org> Message-ID: On Fri, 10 Jan 2020 at 13:27, Andrew Luke Nesbit wrote: > > On 10/01/2020 01:52, Rob Pike wrote: > > I wrote xd for a reason. > > What is xd? Please could you send a link to it? Thank you!! I'm obviously not Rob Pike, but here is a link to the man page of (the plan9port incarnation of) xd: https://9fans.github.io/plan9port/man/man1/xd.html Mark. From mike.ab3ap at gmail.com Fri Jan 10 23:41:53 2020 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 10 Jan 2020 08:41:53 -0500 Subject: [TUHS] screen editors / machine load In-Reply-To: <1ippPk-8PE-00@marmaro.de> References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> Message-ID: [2020-01-09 08:49] Dave Horsfall > > I had a boss once who insisted that all his staff learn "ed", > > because one day it might be the only editor available; he was > > right... > I first used Unix on a pdp-11/70 in 1981, first year at university. My professor stopped by the computing center to see how his students were doing - super nice of him and a perk to pre-PC times! - and was showing me something or other regarding Unix. I had only used ed to that point and seeing him fire up vi was practically sci-fi to me. He showed me a few commands and vowed me to secrecy for fear if all students started using it, it would bring the 11/70 to its knees. Were multiple vi sessions really such a potential burden to the machine? I wouldn't think so with the slow nature of human i/o, yet there certainly were times when the pdp-11/70 crashed as project due dates loomed closer and closer! Also, I very much enjoy this list. As an EE I use Unix-like OSes as a tool rather being a builder of the tool like many here. So I don't have the deep background to contribute to the collective history, but I'm on the sidelines enjoying the show. As a brief tie-in to the editor comparisons, I do a lot of DSP work for RF systems these days. Python makes it quick and easy to try new math, but has a maddening requirement that indentation be strictly tabs or strictly spaces. Text window pasting into a tab indented python file wreaks havoc. vim yank/put between split windows retains the type of white space and lets me use my vi muscle memory. Happy 2020, Mike Markowski -------------- next part -------------- An HTML attachment was scrubbed... URL: From otto at drijf.net Fri Jan 10 23:56:45 2020 From: otto at drijf.net (Otto Moerbeek) Date: Fri, 10 Jan 2020 14:56:45 +0100 Subject: [TUHS] screen editors / machine load In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> Message-ID: <20200110135645.GA47971@clue.drijf.net> On Fri, Jan 10, 2020 at 08:41:53AM -0500, Mike Markowski wrote: > [2020-01-09 08:49] Dave Horsfall > > > I had a boss once who insisted that all his staff learn "ed", > > > because one day it might be the only editor available; he was > > > right... > > > > I first used Unix on a pdp-11/70 in 1981, first year at university. My > professor stopped by the computing center to see how his students were > doing - super nice of him and a perk to pre-PC times! - and was showing me > something or other regarding Unix. I had only used ed to that point and > seeing him fire up vi was practically sci-fi to me. He showed me a few > commands and vowed me to secrecy for fear if all students started using it, > it would bring the 11/70 to its knees. Were multiple vi sessions really > such a potential burden to the machine? I wouldn't think so with the slow > nature of human i/o, yet there certainly were times when the pdp-11/70 > crashed as project due dates loomed closer and closer! > > Also, I very much enjoy this list. As an EE I use Unix-like OSes as a tool > rather being a builder of the tool like many here. So I don't have the > deep background to contribute to the collective history, but I'm on the > sidelines enjoying the show. As a brief tie-in to the editor comparisons, > I do a lot of DSP work for RF systems these days. Python makes it quick > and easy to try new math, but has a maddening requirement that indentation > be strictly tabs or strictly spaces. Text window pasting into a tab > indented python file wreaks havoc. vim yank/put between split windows > retains the type of white space and lets me use my vi muscle memory. > > Happy 2020, > Mike Markowski In my first year at university (1984) we had a VAX-11/750 running 4.1BSD with too many students. We had to switch to ex once in a while to get any editing done. I believe it was not only vi itself that was causing the load, it was also running many terminals in raw mode that killed performance. -Otto From jnc at mercury.lcs.mit.edu Sat Jan 11 00:27:40 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 10 Jan 2020 09:27:40 -0500 (EST) Subject: [TUHS] wump.c for v6 Message-ID: <20200110142740.8642618C09C@mercury.lcs.mit.edu> > From: Clem Cole > So, unless anyone else can illuminate, I'm not sure where the first cpp > that some of us using v6 had originated. I recall a prior extensive discussion about 'cpp'. I looked, and found it (March 30, 2017) but it was a private discussion, not on TUHS (although you were part of it :-). Here are clips of what I wrote (I don't want to re-post what others wrote) from what I wrote, which tell most of the story: There were a series of changes to C before V7 came out, resulting in the so-called 'phototypsetter C compiler' (previously discussed on TUHS), and they included the preprocessor. There's that series of short notes describing changes to C (and the compiler), and they include mention of the preprocessor. [Available here: http://gunkies.org/wiki/Typesetter_C for those who want to see them.] The MIT 'V6' Unix (which was, AFAICT, an augmented version of an early version of PWB Unix) had that C compiler; and if you look at the PWB1 tree online, it does have the C with 'cpp': http://minnie.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/c/c I did a diff of that 'cpp' with the MIT one, and they are basically identical. ---- I went looking for the C manual in the V6 distro, to see if it mentioned the pre-processor. And it does: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/doc/c/c5 (Section 12, "Compiler control lines", about half way down.) So, I'm like, 'WTF? I just looked at cc.c and no mention of cpp!' So I looked a little harder, and if you look at the cc.c in the distro (URL above), you see this: insym(&defloc, "define"); insym(&incloc, "include"); insym(&eifloc, "endif"); insym(&ifdloc, "ifdef"); insym(&ifnloc, "ifndef"); insym(&unxloc, "unix"); The pre-processor is integrated into 'cc' in the initial V6. So we do have a very early version of it, after all... ---- So, 'cc' in V5 also included pre-processor support (just #define and #include, though): http://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/source/s1/cc.c Although we don't have the source to 'cc' to show it, V4 also appears to have had it, per the man page: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/man/man1/cc.1 "If the -p flag is used, only the macro prepass is run on all files whose name ends in .c"; and the V4 system source: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys also has .h files. No sign of it in the man page for cc.1 in V3, though. This all makes sense. .h files aren't any use with[out] #include, and without #include, you have to have the structure definition, etc in multiple source files. So #include would have gotten added very early on. In V3, the system was apparently still in assembler, so no need. ----- Also, there's an error in: https://ewe2.ninja/computers/cno/ when it says "V6 was a very different beast for programming to V7. No c preprocessor. The practical upshot of this is no #includes." that's clearly incorrect (see above). Also, if you look at Lions (which is pure early V6), in the source section, all the .c files have #include's. Noel From jnc at mercury.lcs.mit.edu Sat Jan 11 00:35:39 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 10 Jan 2020 09:35:39 -0500 (EST) Subject: [TUHS] screen editors / machine load Message-ID: <20200110143539.94B6218C09C@mercury.lcs.mit.edu> > From: Otto Moerbeek > I believe it was not only vi itself that was causing the load, it was > also running many terminals in raw mode that killed performance. I'm not familiar with the tty driver in late versions of Unix like 4.1 (sic), but I'm very familiar with the one in V6, and it's not the raw mode _itself_ that caused the load (the code paths in the kernel for cooked and raw aren't that different), but rather the need to wake up and run a process on every character that was the real load. When Bernie Greenberg did EMACS for Multics, he had a similar issue. I recall reading a document with an extensive discussion of how they dealt with this, especially when using the system over the ARPANET. IIRC, normal printing characters were echoed without waking up the process; remotely, when using the network. If anyone's really interested in this, and can't find it themselves, I can try looking for it. Noel From mah at mhorton.net Sat Jan 11 01:00:08 2020 From: mah at mhorton.net (Mary Ann Horton) Date: Fri, 10 Jan 2020 07:00:08 -0800 Subject: [TUHS] screen editors / machine load In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> Message-ID: <81cf0f73-2141-10c9-7352-51c0aac76959@mhorton.net> Yes, it was a real concern. Physical memory on the shared PDP-11 was limited, and if everyone had a separate copy of vi running the machine would swap itself silly. This only mattered if everyone had their own separate copy of vi installed. The fix was to put vi in a single system directory, such as /usr/ucb or /exptools. The instruction part of its memory would be shared among all the users, resulting in much less swapping. In the early days, people tended to have their own personal copy because the Berkeley tools did not come standard with UNIX, especially at Bell Labs. That was one of the main motivations for Exptools (the "experimental tools"), which were basically 2BSD's applications and some other tools like Warren Montgomery's emacs. Disk space and people's time spend installing were also good reasons.     Mary Ann On 1/10/20 5:41 AM, Mike Markowski wrote: > seeing him fire up vi was practically sci-fi to me.  He showed me a > few commands and vowed me to secrecy for fear if all students started > using it, it would bring the 11/70 to its knees.  Were multiple vi > sessions really such a potential burden to the machine?  I wouldn't > think so with the slow nature of human i/o, yet there certainly were > times when the pdp-11/70 crashed as project due dates loomed closer > and closer! From jnc at mercury.lcs.mit.edu Sat Jan 11 01:35:26 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 10 Jan 2020 10:35:26 -0500 (EST) Subject: [TUHS] screen editors / machine load Message-ID: <20200110153526.5D0CF18C09C@mercury.lcs.mit.edu> > When Bernie Greenberg did EMACS for Multics, he had a similar issue. I > recall reading a document with an extensive discussion of how they dealt > with this ... If anyone's really interested in this, and can't find it > themselves, I can try looking for it. I got a request for this; a Web search turned up: https://www.multicians.org/mepap.html which covers the points I mentioned (and more besides, such as why LISP was chosen). I don't think this is the thing I remembered (which was, IIRC, an informal note), but it does seem to be a later version of that. Noel From cym224 at gmail.com Sat Jan 11 01:31:11 2020 From: cym224 at gmail.com (Nemo Nusquam) Date: Fri, 10 Jan 2020 10:31:11 -0500 Subject: [TUHS] screen editors In-Reply-To: <1ippPk-8PE-00@marmaro.de> References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> Message-ID: On 01/10/20 03:13, markus schnalke wrote (in part): > Hoi. [...] > Anyways, I'm having a great pleasure reading those historic > spotlights on editors these days. :-) In earlier days, my wife was given email by telnetting to an SGI system and using elm. One day, I visited her office as she was composing a message. Intrigued, I asked her what the editor was. She did not know and pointed to her cheat-sheet listing editor commands. One was ^X^C to exit-and-send. She is not a programmer and I was a bit surprised at their choice. N. > > > meillo From clemc at ccc.com Sat Jan 11 01:48:09 2020 From: clemc at ccc.com (Clem Cole) Date: Fri, 10 Jan 2020 10:48:09 -0500 Subject: [TUHS] screen editors / machine load In-Reply-To: <81cf0f73-2141-10c9-7352-51c0aac76959@mhorton.net> References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <81cf0f73-2141-10c9-7352-51c0aac76959@mhorton.net> Message-ID: On Fri, Jan 10, 2020 at 10:00 AM Mary Ann Horton wrote: > Yes, it was a real concern. Physical memory on the shared PDP-11 was > limited, and if everyone had a separate copy of vi running the machine > would swap itself silly. > > This only mattered if everyone had their own separate copy of vi > installed. The fix was to put vi in a single system directory, such as > /usr/ucb or /exptools. The instruction part of its memory would be > shared among all the users, resulting in much less swapping. > Actually it was much worse than that... What Mary Ann points out was mostly true of your PDP-11 had DH11's installed; which had deeper hardware buffering and 16 character DMA on output. But these were expensive from DEC and also took up a 'full system unit' in the CPU for 16 lines. Until Able (much later) released the DMAX-11 (*a.k.a.* DH/DM) product of a DH11 clone on a single board, many university sites did not use them; but used multiple DL-11/KL-11's instead. If your system was configured with DL/KL11s or similar (CMU had it's own called 'ASLIs' - a synchronous line interfaces) each character took one interrupt for each either input or output. Moreover, the UARTS that DEC used which were made by Western Digital had 2 >>or less<< characters of input buffering, so they could drop chars[1]. The ASLI's used a later chip with a slightly better buffer IIRC but I admit I've forgotten the details (Jim Tetter probably remembers them). So if you had a single line, the interrupt load was huge on a PDP-11. For this reason, a lot of sites limited glass TTYs to speeds like 2400 or 4800 baud, not the full 9600. DEC later released the DZ-11 which worked on units of 8 ports per board. Unfortunately, it was not DMA and the buffering was still pretty shallow. Joy did a lot of work on 4.1BSD in the DZ driver to cut down the interrupts because 9600 baud DZ lines could swamp a vax and when running the BerkNet between systems (before UCB had ethernet), 9600 baud serial lines were standard. [1] Two things A) The original WD UART chip had very limited buffering. The timing was such that as high rates it could not empty accept a second character without the first being overwritten. This was a long-standing issue for many UARTs long in the 1990s. The original chip NS built and IBM used on the PC (the NS8250) was notorious for the same problem. By the time of Motorola's 6881, it had 8 characters of buffering IIRC. B) As I understand the history, Gordon developed the original idea of the UART at DEC for the PDP-1. But I'm not sure of the patent details. He does not list the UART patent on his web site although he does mention inventing it. I have been under the impression CMU was somehow mixed up in the patent and licensing of it, *i.e.* WD got the license from CMU to make them not DEC; which was part of why we had the ASLI's. Again, IIRC, we got the UART chips from WD at cost and could make the ALSI's locally much cheaper than DL-11s. >>I think<< the story was that one of Gordon's student's designed a chip, which WD fabbed and licensed. Before that DEC had built UARTs on boards from transistors and later logic gates. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Jan 11 02:04:41 2020 From: clemc at ccc.com (Clem Cole) Date: Fri, 10 Jan 2020 11:04:41 -0500 Subject: [TUHS] screen editors In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> Message-ID: On Fri, Jan 10, 2020 at 10:39 AM Nemo Nusquam wrote: > Intrigued, I asked her what the editor was. She did not know > and pointed to her cheat-sheet listing editor commands. One was ^X^C to > exit-and-send. She is not a programmer and I was a bit surprised at > their choice. > Similar fun Unix/ITS emacs story. In the mid/later 1970s, my least techie sister Cynthia was/is a concert harpist with a degree from Oberlin's conservatory. She can type extremely fast as she has super manual dexterity. But playing the harp is not something that paid a great deal or offered her 'regular' gigs, so to make the monthly rent she got a job working at MIT as Ron Rivest's admin . She typed all the RSA papers in emacs and tex on one of the MIT systems. She did not know any better, that's what they gave her/taught her. When she later would look for a job at other places and they would ask her, 'do you know how to use a Wang System' and she would say: "No, I know emacs" [for the younger set, longer before MS-Word, "Wang" was synonymous with "word processor" and many/most commercial offices had a 'Wang unit" for the folks doing the typing.]. [As a side note when she found out the elevators were hacked and controlled by the student's different computers, she stopped using them and would take the stairs in Tech Sq]. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Sat Jan 11 01:58:22 2020 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Fri, 10 Jan 2020 10:58:22 -0500 Subject: [TUHS] screen editors In-Reply-To: <1ippPk-8PE-00@marmaro.de> References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> Message-ID: <20200110155822.GA298569@mit.edu> On Fri, Jan 10, 2020 at 09:13:04AM +0100, markus schnalke wrote: > > I was quite shocked when I first realized that I had to do > `apt-get install ed' to have it available ... on a Unix-like > system. But on the other hand, who of today's users is even > capable of exiting it?! For what it's worth, I regularly edit configuration files and shell scripts using /bin/ed in environments where I can't use (due to terminal limitations) or can't fit a more sophisticated editors. These days this is typically in small appliance VM's. I've also been known to do things like this in shell scripts[1]: ed /etc/lighttpd/lighttpd.conf < > > On my own systems I like to install Heirlomm ed, which I have > outfactored from the Heirloom tools package. If you want to > actually use it every now and then, Gunnar's ed is much more > usable than GNU ed ... which seems to be more a demonstration > object than actually a programmer's editor. > > > Anyways, I'm having a great pleasure reading those historic > spotlights on editors these days. :-) > > > meillo From crossd at gmail.com Sat Jan 11 03:10:47 2020 From: crossd at gmail.com (Dan Cross) Date: Fri, 10 Jan 2020 12:10:47 -0500 Subject: [TUHS] screen editors In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> Message-ID: On Fri, Jan 10, 2020 at 10:39 AM Nemo Nusquam wrote: > In earlier days, my wife was given email by telnetting to an SGI system > and using elm. One day, I visited her office as she was composing a > message. Intrigued, I asked her what the editor was. She did not know > and pointed to her cheat-sheet listing editor commands. One was ^X^C to > exit-and-send. She is not a programmer and I was a bit surprised at > their choice. > Hmm, I'm actually kind of not. Starting users off with a modal editor (that starts in command mode, no less!) can be surprising for novices; with emacs, at least you can start typing text and, well, see text. I think that one of the smartest things Marc Crispin ever did was write `pico` to go with `pine`. A simple editor targeted at the novice was really useful for casual and/or new users, particularly as the Internet spread and an account on a Unix system was the default introduction to email etc for so many. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From usotsuki at buric.co Sat Jan 11 03:18:09 2020 From: usotsuki at buric.co (Steve Nickolas) Date: Fri, 10 Jan 2020 12:18:09 -0500 (EST) Subject: [TUHS] screen editors In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> Message-ID: On Fri, 10 Jan 2020, Dan Cross wrote: > On Fri, Jan 10, 2020 at 10:39 AM Nemo Nusquam wrote: > >> In earlier days, my wife was given email by telnetting to an SGI system >> and using elm. One day, I visited her office as she was composing a >> message. Intrigued, I asked her what the editor was. She did not know >> and pointed to her cheat-sheet listing editor commands. One was ^X^C to >> exit-and-send. She is not a programmer and I was a bit surprised at >> their choice. >> > > Hmm, I'm actually kind of not. Starting users off with a modal editor (that > starts in command mode, no less!) can be surprising for novices; with > emacs, at least you can start typing text and, well, see text. This is one of the reasons I liked E when I first used it: it was modal, but it started in edit mode. (Also you KNEW what mode you were in, which I understand isn't always the case with vi, although it usually is in the clones iirc?) > I think that one of the smartest things Marc Crispin ever did was write > `pico` to go with `pine`. A simple editor targeted at the novice was really > useful for casual and/or new users, particularly as the Internet spread and > an account on a Unix system was the default introduction to email etc for > so many. And I still use nano - which is a rewrite of pico. pico Just Works(R)(TM)(C), and it's not enormous. nano adds a few things I like, but the UI is the same. Heck...I still use PINE and am sending this message from it ;) -uso. From jnc at mercury.lcs.mit.edu Sat Jan 11 03:27:47 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 10 Jan 2020 12:27:47 -0500 (EST) Subject: [TUHS] Tech Sq elevator (Was: screen editors) Message-ID: <20200110172747.90BDE18C09E@mercury.lcs.mit.edu> > From: Clem Cole > when she found out the elevators were hacked and controlled by the > student's different computers, she stopped using them and would take > the stairs It wasn't quite as major as this makes it sound! A couple of inconspicuous wires were run from the 'TV 11' on the MIT-AI KA10 machine (the -11 that ran the Knight displays) into the elevator controller, and run onto the terminals where the wires from the 'down' call buttons on the 8th and 9th floors went. So it wasn't anything major, and there was really no need for her to take the stair (especially 8 flights up :-). The code is still extant, in 'SYSTEM; TV >'. It only worked (I think) from Knight TV keyboards; typing 'ESC E' called the elevator to the floor that keyboard was on (there's a table, 'ELETAB', which gives the physical floor for each keyboard). The machine could also open the locked 9th floor door to the machine room (with an 'ESC D'), and there some other less major things, e.g. print screen hardcopy. I'm not sure what the hardware in the TV-11 was (this was all run out of the 'keyboard multiplexor'); it may have been something the AI Lab built from scratch. Noel From lars at nocrew.org Sat Jan 11 03:45:51 2020 From: lars at nocrew.org (Lars Brinkhoff) Date: Fri, 10 Jan 2020 17:45:51 +0000 Subject: [TUHS] Tech Sq elevator In-Reply-To: <20200110172747.90BDE18C09E@mercury.lcs.mit.edu> (Noel Chiappa's message of "Fri, 10 Jan 2020 12:27:47 -0500 (EST)") References: <20200110172747.90BDE18C09E@mercury.lcs.mit.edu> Message-ID: <7wd0brmchc.fsf@junk.nocrew.org> Noel Chiappa writes: > The code is still extant, in 'SYSTEM; TV >'. It only worked (I think) > from Knight TV keyboards (This isn't TUHS material, but I can't resist. CC to COFF.) There is also a Chaosnet service to call for the elevator or open the door, so it can be used remotely. The ITS program ESCE uses this service. I suppose there must have been something for the Lisp machines too, maybe even a Super-Hyper-Cokebottle keyboard command. From crossd at gmail.com Sat Jan 11 05:07:53 2020 From: crossd at gmail.com (Dan Cross) Date: Fri, 10 Jan 2020 14:07:53 -0500 Subject: [TUHS] Question about early C behavior. Message-ID: This question comes from a colleague, who works on compilers. Given the definition `int x;` (without an initializer) in a source file the corresponding object contains `x` in a "common" section. What this means is that, at link time, if some object file explicitly allocates an 'x' (e.g., by specifying an initializer, so that 'x' appears in the data section for that object file), use that; otherwise, allocate space for it at link time, possibly in the BSS. If several source files contain such a declaration, the linker allocates exactly one 'x' (or whatever identifier) as appropriate. We've verified that this behavior was present as early as 6th edition. The question is, what is the origin of this concept and nomenclature? FORTRAN, of course, has "common blocks": was that an inspiration for the name? Where did the idea for the implicit behavior come from (FORTRAN common blocks are explicit). My colleague was particularly surprised that this seemed required: even at this early stage, the `extern` keyword was present, so why bother with this behavior? Why not, instead, make it a link-time error? Please note that if two source files have initializers for these variables, then one gets a multiple-definition link error. The 1988 ANSI standard made this an error (or at least undefined behavior) but the functionality persists; GCC is changing its default to prohibit it (my colleague works on clang). Doug? Ken? Steve? - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Sat Jan 11 06:24:30 2020 From: paul.winalski at gmail.com (Paul Winalski) Date: Fri, 10 Jan 2020 15:24:30 -0500 Subject: [TUHS] Question about early C behavior. In-Reply-To: References: Message-ID: On 1/10/20, Dan Cross wrote: > > Given the definition `int x;` (without an initializer) in a source file the > corresponding object contains `x` in a "common" section. What this means is > that, at link time, if some object file explicitly allocates an 'x' (e.g., > by specifying an initializer, so that 'x' appears in the data section for > that object file), use that; otherwise, allocate space for it at link time, > possibly in the BSS. If several source files contain such a declaration, > the linker allocates exactly one 'x' (or whatever identifier) as > appropriate. We've verified that this behavior was present as early as 6th > edition. I think the situation you describe (common sections) is how this is done in ELF. a.out and COFF, as used on Unix, don't have common sections. Instead 'int x;' (without an initializer) becomes symbol 'x' in the object file's symbol table, with both the "external" and "undefined" attribute bits set, and with the symbol's value being the size of 'x' (typically 4 bites, in your example). It is the non-zero symbol value that distinguishes common symbols from ordinary external references, e.g., 'extern int x;' (without an initializer). At link time, common symbols are handled differently from ordinary external references: [1] When the linker is searching libraries, an ordinary external reference to 'x' will cause the linker to load an object that contains an external definition for 'x'. Common symbols do not trigger the loading of an object from a library. [2] After the linker has processed all of the files and libraries on the command line, if there is an external definition for 'x', all common symbol references to 'x' are treated as ordinary external references to 'x' and resolved against the definition. If no external definition is found, the linker allocates 'x' in BSS, using the maximum allocation size seen in any common symbol references to 'x'. All common symbol references and ordinary external references to 'x' are resolved to the newly-allocated space. > The question is, what is the origin of this concept and nomenclature? > FORTRAN, of course, has "common blocks": was that an inspiration for the > name? Where did the idea for the implicit behavior come from (FORTRAN > common blocks are explicit). Yes, the concept, nomenclature, and semantics come from FORTRAN, and they were included in a.out and COFF to support FORTRAN and other languages (such as PL/I) that have COMMON block-type semantics. I don't know why 'int x;' (without an initializer) in C was implemented as a common symbol. I suspect it was done to allow C and FORTRAN object modules linked together in the same executable to share external data. -Paul W. From aap at papnet.eu Sat Jan 11 06:18:19 2020 From: aap at papnet.eu (Angelo Papenhoff) Date: Fri, 10 Jan 2020 21:18:19 +0100 Subject: [TUHS] Tech Sq elevator (Was: screen editors) In-Reply-To: <20200110172747.90BDE18C09E@mercury.lcs.mit.edu> References: <20200110172747.90BDE18C09E@mercury.lcs.mit.edu> Message-ID: <20200110201819.GA19832@indra.papnet.eu> On 10/01/20, Noel Chiappa wrote: > > From: Clem Cole > > > when she found out the elevators were hacked and controlled by the > > student's different computers, she stopped using them and would take > > the stairs > > It wasn't quite as major as this makes it sound! A couple of inconspicuous > wires were run from the 'TV 11' on the MIT-AI KA10 machine (the -11 that ran > the Knight displays) into the elevator controller, and run onto the terminals > where the wires from the 'down' call buttons on the 8th and 9th floors went. > > So it wasn't anything major, and there was really no need for her to take the > stair (especially 8 flights up :-). > > The code is still extant, in 'SYSTEM; TV >'. It only worked (I think) from > Knight TV keyboards; typing 'ESC E' called the elevator to the floor > that keyboard was on (there's a table, 'ELETAB', which gives the physical > floor for each keyboard). > > The machine could also open the locked 9th floor door to the machine room > (with an 'ESC D'), and there some other less major things, e.g. print screen > hardcopy. I'm not sure what the hardware in the TV-11 was (this was all run > out of the 'keyboard multiplexor'); it may have been something the AI Lab > built from scratch. For those not aware: we have the TV-11 running again under emulation and it is once again the preferred way to use ITS. Unfortunately I'm not quite sure how to emulate all the elevator behaviour...any ideas? :D aap From robpike at gmail.com Sat Jan 11 06:32:04 2020 From: robpike at gmail.com (Rob Pike) Date: Sat, 11 Jan 2020 07:32:04 +1100 Subject: [TUHS] screen editors and beyond In-Reply-To: <711e73ee-6acd-95b8-6f81-15e2af05ac7f@andrewnesbit.org> References: <1578606809.15476.for-standards-violators@oclsc.org> <711e73ee-6acd-95b8-6f81-15e2af05ac7f@andrewnesbit.org> Message-ID: http://man.cat-v.org/plan_9/1/xd There's a copy of the source in plan9port. -rob On Fri, Jan 10, 2020 at 11:26 PM Andrew Luke Nesbit < ullbeking at andrewnesbit.org> wrote: > On 10/01/2020 01:52, Rob Pike wrote: > > I wrote xd for a reason. > > What is xd? Please could you send a link to it? Thank you!! > > Andrew > -- > OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfawcus+lists-tuhs at employees.org Sat Jan 11 06:55:25 2020 From: dfawcus+lists-tuhs at employees.org (Derek Fawcus) Date: Fri, 10 Jan 2020 20:55:25 +0000 Subject: [TUHS] Question about early C behavior. In-Reply-To: References: Message-ID: <20200110205525.GA1766@clarinet.employees.org> On Fri, Jan 10, 2020 at 02:07:53PM -0500, Dan Cross wrote: > > My colleague was particularly surprised that this seemed required: even at > this early stage, the `extern` keyword was present, so why bother with this > behavior? Why not, instead, make it a link-time error? Please note that if > two source files have initializers for these variables, then one gets a > multiple-definition link error. The 1988 ANSI standard made this an error > (or at least undefined behavior) but the functionality persists; GCC is > changing its default to prohibit it (my colleague works on clang). This behaviour differed between platforms, unix using the common approach, and some other platforms simplying making it a (non common) symbol in the bss. Having learnt C in its pre-ANSI form on unix, I then ran in to this behaviour on DOS C compilers. None of which (that I came across) providing the 'common' behaviour. DF From imp at bsdimp.com Sat Jan 11 07:02:33 2020 From: imp at bsdimp.com (Warner Losh) Date: Fri, 10 Jan 2020 14:02:33 -0700 Subject: [TUHS] Question about early C behavior. In-Reply-To: <20200110205525.GA1766@clarinet.employees.org> References: <20200110205525.GA1766@clarinet.employees.org> Message-ID: On Fri, Jan 10, 2020, 1:55 PM Derek Fawcus wrote: > On Fri, Jan 10, 2020 at 02:07:53PM -0500, Dan Cross wrote: > > > > My colleague was particularly surprised that this seemed required: even > at > > this early stage, the `extern` keyword was present, so why bother with > this > > behavior? Why not, instead, make it a link-time error? Please note that > if > > two source files have initializers for these variables, then one gets a > > multiple-definition link error. The 1988 ANSI standard made this an error > > (or at least undefined behavior) but the functionality persists; GCC is > > changing its default to prohibit it (my colleague works on clang). > > This behaviour differed between platforms, unix using the common approach, > and some other platforms simplying making it a (non common) symbol in the > bss. > > Having learnt C in its pre-ANSI form on unix, I then ran in to this > behaviour > on DOS C compilers. None of which (that I came across) providing the > 'common' > behaviour. > Gcc offered warnings for this behavior in the early 90s, iirc. I went through a bunch of code in that time frame to remove the assumption... Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Jan 11 07:05:02 2020 From: clemc at ccc.com (Clem Cole) Date: Fri, 10 Jan 2020 16:05:02 -0500 Subject: [TUHS] Question about early C behavior. In-Reply-To: References: Message-ID: On Fri, Jan 10, 2020 at 2:09 PM Dan Cross wrote: > The 1988 ANSI standard made this an error (or at least undefined behavior) > but the functionality persists; GCC is changing its default to prohibit it > (my colleague works on clang). > Lovely - let's break code because we can. To quote our late friend and colleague dmr: “I can't recall any difficulty in making the C language definition completely open - any discussion on the matter tended to mention languages whose inventors tried to keep tight control, and consequent ill fate” “When I read commentary about suggestions for where C should go, I often think back and give thanks that it wasn't developed under the advice of a worldwide crowd.” “C is peculiar in a lot of ways, but it, like many other successful things, has a certain unity of approach that stems from development in a small group” -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Sat Jan 11 08:18:17 2020 From: athornton at gmail.com (Adam Thornton) Date: Fri, 10 Jan 2020 15:18:17 -0700 Subject: [TUHS] screen editors / machine load In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <81cf0f73-2141-10c9-7352-51c0aac76959@mhorton.net> Message-ID: A) The original WD UART chip had very limited buffering. The timing was such that as high rates it could not empty accept a second character without the first being overwritten. This was a long-standing issue for many UARTs long in the 1990s. The original chip NS built and IBM used on the PC (the NS8250) was notorious for the same problem. By the time of Motorola's 6881, it had 8 characters of buffering IIRC. Great, now I'm having flashbacks to upgrading my 4-port serial card with 16450s and then 16550s in the early 90s. On Fri, Jan 10, 2020 at 8:49 AM Clem Cole wrote: > > > On Fri, Jan 10, 2020 at 10:00 AM Mary Ann Horton wrote: > >> Yes, it was a real concern. Physical memory on the shared PDP-11 was >> limited, and if everyone had a separate copy of vi running the machine >> would swap itself silly. >> >> This only mattered if everyone had their own separate copy of vi >> installed. The fix was to put vi in a single system directory, such as >> /usr/ucb or /exptools. The instruction part of its memory would be >> shared among all the users, resulting in much less swapping. >> > Actually it was much worse than that... > > What Mary Ann points out was mostly true of your PDP-11 had DH11's > installed; which had deeper hardware buffering and 16 character DMA on > output. But these were expensive from DEC and also took up a 'full system > unit' in the CPU for 16 lines. Until Able (much later) released the > DMAX-11 (*a.k.a.* DH/DM) product of a DH11 clone on a single board, many > university sites did not use them; but used multiple DL-11/KL-11's instead. > > If your system was configured with DL/KL11s or similar (CMU had it's own > called 'ASLIs' - a synchronous line interfaces) each character took one > interrupt for each either input or output. Moreover, the UARTS that DEC > used which were made by Western Digital had 2 >>or less<< characters of > input buffering, so they could drop chars[1]. The ASLI's used a later chip > with a slightly better buffer IIRC but I admit I've forgotten the details > (Jim Tetter probably remembers them). > > So if you had a single line, the interrupt load was huge on a PDP-11. For > this reason, a lot of sites limited glass TTYs to speeds like 2400 or 4800 > baud, not the full 9600. > > DEC later released the DZ-11 which worked on units of 8 ports per board. > Unfortunately, it was not DMA and the buffering was still pretty shallow. > Joy did a lot of work on 4.1BSD in the DZ driver to cut down the > interrupts because 9600 baud DZ lines could swamp a vax and when running > the BerkNet between systems (before UCB had ethernet), 9600 baud serial > lines were standard. > > > [1] Two things > A) The original WD UART chip had very limited buffering. The timing was > such that as high rates it could not empty accept a second character > without the first being overwritten. This was a long-standing issue for > many UARTs long in the 1990s. The original chip NS built and IBM used on > the PC (the NS8250) was notorious for the same problem. By the time of > Motorola's 6881, it had 8 characters of buffering IIRC. > > B) As I understand the history, Gordon developed the original idea of the > UART at DEC for the PDP-1. But I'm not sure of the patent details. He does > not list the UART patent on his web site although he does mention inventing > it. I have been under the impression CMU was somehow mixed up in the > patent and licensing of it, *i.e.* WD got the license from CMU to make > them not DEC; which was part of why we had the ASLI's. Again, IIRC, we got > the UART chips from WD at cost and could make the ALSI's locally much > cheaper than DL-11s. >>I think<< the story was that one of Gordon's > student's designed a chip, which WD fabbed and licensed. Before that DEC > had built UARTs on boards from transistors and later logic gates. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Sat Jan 11 08:53:07 2020 From: rich.salz at gmail.com (Richard Salz) Date: Fri, 10 Jan 2020 17:53:07 -0500 Subject: [TUHS] Sun employee interviews Message-ID: Sarah Jeong is looking for Sun employees to interview for a potential book about its rise and fall. Thread here https://twitter.com/halvarflake/status/1215312568438480897?s=19 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cbbrowne at gmail.com Sat Jan 11 10:30:30 2020 From: cbbrowne at gmail.com (Christopher Browne) Date: Fri, 10 Jan 2020 19:30:30 -0500 Subject: [TUHS] screen editors / machine load In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <81cf0f73-2141-10c9-7352-51c0aac76959@mhorton.net> Message-ID: On Fri, 10 Jan 2020 at 17:19, Adam Thornton wrote: > A) The original WD UART chip had very limited buffering. The timing was > such that as high rates it could not empty accept a second character > without the first being overwritten. This was a long-standing issue for > many UARTs long in the 1990s. The original chip NS built and IBM used on > the PC (the NS8250) was notorious for the same problem. By the time of > Motorola's 6881, it had 8 characters of buffering IIRC. > > Great, now I'm having flashbacks to upgrading my 4-port serial card with > 16450s and then 16550s in the early 90s. > Yep, same sorts of memories here. I recall the 16450 upgrade being a big deal for Internet connectivity in that a PC lacking the extra bytes of buffering in the UART would find that the 80386 was having clock cycles eaten nearly completely by PPP connections. It was amazing to realize how a few bytes of memory lurking in a crucial system interface could affect performance in such dramatic ways. Tagged command queueing on SCSI controllers had a slightly less dramatic effect on I/O performance, but again, a few hundred bytes of memory in the right spot could nevertheless have dramatic effects. -------------- next part -------------- An HTML attachment was scrubbed... URL: From meillo at marmaro.de Sun Jan 12 05:58:53 2020 From: meillo at marmaro.de (markus schnalke) Date: Sat, 11 Jan 2020 20:58:53 +0100 Subject: [TUHS] screen editors In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> Message-ID: <1iqMuL-1zK-00@marmaro.de> Hoi. [2020-01-10 08:17] U'll Be King of the Stars > On 10/01/2020 08:13, markus schnalke wrote: > > > > GNU ed [...] seems to be more a demonstration > > object than actually a programmer's editor. > > Hi Markus, in what way is GNU ed a "demonstration object"? Thanks for questioning this statement! It seems as if I might have mixed different memories up. A quick look at GNU ed showed nothing to support my statement. Sorry for pretending stuff without fact checking. My look was at version 1.4, which is the newest one I could look into. I'm pretty sure I examined GNU ed 1.6 back then, because that version is in the Pkgfile of my system, but unfortunately I am unable to find it anywhere. The GNU release mirrors lack all version 1.5 through 1.10 -- why that? They must have been released, at least 1.6, because that is used on my system. Unfortunately I also was unable to access the Changelog of a newer version to check for changes, because these are lzip compressed (tar.lz) ... whatever that is, I cannot uncompress it on my system. Furthermore I neither could find an online browsable web repo view for checking out version 1.6 or at least viewing the files within the browser. There's only a cvs repo access (no cvs on my machine) and it talks about the web page repo not the ed source repo. Not sure what to think of that. That's not how things should be. Actually, I'm a bit depressed now ... meillo P.S. Wikipedia writes that `ed' would be pronounced ``ee-dee'' (like ``vee-eye''), is that what you english speakers do? To me (a native German speaker) it naturally was ``ed'' (like ``sam''). As reference some Computerphile video is given, which is now deleted. Is there a better source? And what about the pronounciations of `ex' and `qed'? What about `od'? (That I pronouce ``oh-dee''.) https://en.wikipedia.org/wiki/Ed_(text_editor) From dfawcus+lists-tuhs at employees.org Sun Jan 12 06:54:50 2020 From: dfawcus+lists-tuhs at employees.org (Derek Fawcus) Date: Sat, 11 Jan 2020 20:54:50 +0000 Subject: [TUHS] screen editors In-Reply-To: <1iqMuL-1zK-00@marmaro.de> References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> Message-ID: <20200111205450.GA84232@clarinet.employees.org> On Sat, Jan 11, 2020 at 08:58:53PM +0100, markus schnalke wrote: > > Wikipedia writes that `ed' would be pronounced ``ee-dee'' (like > ``vee-eye''), is that what you english speakers do? To me (a > native German speaker) it naturally was ``ed'' (like ``sam''). As a native english speaker... 'ed', as in the man's name. I pronounce 'vi' as you have it above, but others at work pronounce it as 'vye' (as in 'vying'), so no consistency there. We also have local inconsistencies for how JIRA is pronounced, so don't expect a canonical answer. > And what about the pronounciations of `ex' and `qed'? I can't say I've pronounced them before, but I think of former as 'ee-x', I'd be inclined to pronounce the latter as 'queue-ed'. Since Q-E-D has its own meaning. > What about `od'? (That I pronouce ``oh-dee''.) agreed; otherwise confusing with 'odd'. But who knows how the authors pronounced them. DF From henry.r.bent at gmail.com Sun Jan 12 07:27:12 2020 From: henry.r.bent at gmail.com (Henry Bent) Date: Sat, 11 Jan 2020 16:27:12 -0500 Subject: [TUHS] screen editors In-Reply-To: <1iqMuL-1zK-00@marmaro.de> References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> <1iqMuL-1zK-00@marmaro.de> Message-ID: On Sat, 11 Jan 2020 at 14:59, markus schnalke wrote: > Hoi. > > [2020-01-10 08:17] U'll Be King of the Stars > > On 10/01/2020 08:13, markus schnalke wrote: > > > > > > GNU ed [...] seems to be more a demonstration > > > object than actually a programmer's editor. > > > > Hi Markus, in what way is GNU ed a "demonstration object"? > > Thanks for questioning this statement! It seems as if I might have > mixed different memories up. A quick look at GNU ed showed nothing > to support my statement. Sorry for pretending stuff without fact > checking. > > > My look was at version 1.4, which is the newest one I could look > into. I'm pretty sure I examined GNU ed 1.6 back then, because > that version is in the Pkgfile of my system, but unfortunately I > am unable to find it anywhere. The GNU release mirrors lack all > version 1.5 through 1.10 -- why that? They must have been > released, at least 1.6, because that is used on my system. > Unfortunately I also was unable to access the Changelog of a > newer version to check for changes, because these are lzip > compressed (tar.lz) ... whatever that is, I cannot uncompress it > on my system. Furthermore I neither could find an online > browsable web repo view for checking out version 1.6 or at least > viewing the files within the browser. There's only a cvs repo > access (no cvs on my machine) and it talks about the web page > repo not the ed source repo. Not sure what to think of that. > > That's not how things should be. Actually, I'm a bit depressed > now ... > GNU ed appears to be written entirely by one person (as in, no changelog entries by anyone else since 1994), who perhaps not coincidentally is also the author of the lzip compression program. As you noted, ed source is distributed only as lzip-compressed tarballs, so you have to be able to compile and run lzip to compile and run ed. lzip is written in C++, so to have access to GNU ed you need a C++ compiler. Which is very strange, as GNU ed is a very simple C program, much as one would expect. The configure program is extremely basic, which is great - why have more than you need? - but when it detected that my $(CC) was not gcc, it hard-coded $(CC) to cc and $(CFLAGS) to -O2, ignoring what I had passed to the script. A strange choice, but one that can easily be edited later in the Makefile. The basic C source compiled with no warnings whatsoever, always a good sign. At the linking stage I noticed that I needed a library for some functions it wanted. Okay, easy enough, just add a library to the Makefile's LDFLAGS. But the Makefile had this braindamage: $(progname) : $(objs) $(CC) $(LDFLAGS) $(CFLAGS) -o $@ $(objs) so on any platform that needs libraries linked after objects, it will fail. At that point, I gave up. This is clearly one person's pet project and has "but it works on my Linux box!" written all over it. That, coupled with the fact that the GNU folks are willing to endorse something that is solely distributed in what can only be described as an extremely obscure compression format, was just too much for me to handle. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Sun Jan 12 23:43:34 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sun, 12 Jan 2020 08:43:34 -0500 Subject: [TUHS] Tech Sq elevator (Was: screen editors) Message-ID: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU> Mention of elevators at Tech Square reminds me of visiting there to see the Lisp machine. I was struck by cultural differences. At the time we were using Jerqs, where multiple windows ran like multiple time-sharing sessions. To me that behavior was a no-brainer. Surprisingly, Lisp-machine windows didn't work that way; only the user-selected active window got processor time. The biggest difference was emacs, which no one used at Bell Labs. Emacs, of course was native to the Lisp machine and provided a powerful and smoothly extensible environment. For example, its reflective ability made it easy to display a list of its commands. "Call elevator" stood out amng mundane programmering actions like cut, paste and run. After scrolling through the command list, I wondered how long it was and asked to have it counted. Easy, I thought, just pass it to a wc-like program. But "just pass it" and "wc-like" were not givens as they are in Unix culture. It took several minutes for the gurus to do it--without leaving emacs, if I remember right. Doug From imp at bsdimp.com Mon Jan 13 02:56:48 2020 From: imp at bsdimp.com (Warner Losh) Date: Sun, 12 Jan 2020 09:56:48 -0700 Subject: [TUHS] Tech Sq elevator (Was: screen editors) In-Reply-To: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU> References: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU> Message-ID: On Sun, Jan 12, 2020 at 6:44 AM Doug McIlroy wrote: > Mention of elevators at Tech Square reminds me of visiting there > to see the Lisp machine. I was struck by cultural differences. > > At the time we were using Jerqs, where multiple windows ran > like multiple time-sharing sessions. To me that behavior was a > no-brainer. Surprisingly, Lisp-machine windows didn't work that > way; only the user-selected active window got processor time. > > The biggest difference was emacs, which no one used at Bell > Labs. Emacs, of course was native to the Lisp machine and > provided a powerful and smoothly extensible environment. For > example, its reflective ability made it easy to display a > list of its commands. "Call elevator" stood out amng mundane > programmering actions like cut, paste and run. > > After scrolling through the command list, I wondered how long > it was and asked to have it counted. Easy, I thought, just > pass it to a wc-like program. But "just pass it" and "wc-like" > were not givens as they are in Unix culture. It took several > minutes for the gurus to do it--without leaving emacs, if I > remember right. > It should have been something like (list-length (command-list-fn)) but I'll bet that ? was bound to a complicated function that just displayed the results and didn't properly abstract out the UI (printing) from the data collection (getting a list), which is what made it so hard. I've had so many gnu emacs experiences like this over the years, but to the community's credit, there's fewer and fewer as time goes by. ObUnix: This shows the power of having the right abstractions and being disciplined to code to those ideal abstractions any time there might be reuse... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From meillo at marmaro.de Mon Jan 13 03:21:14 2020 From: meillo at marmaro.de (markus schnalke) Date: Sun, 12 Jan 2020 18:21:14 +0100 Subject: [TUHS] Tech Sq elevator (Was: screen editors) In-Reply-To: References: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU> Message-ID: <1iqgvK-2KJ-00@marmaro.de> Hoi. [2020-01-12 09:56] Warner Losh > > It should have been something like  (list-length (command-list-fn)) but I'll > bet that ? was bound to a complicated function that just displayed the results > and didn't properly abstract out the UI (printing) from the data collection > (getting a list), which is what made it so hard. I've had so many gnu emacs > experiences like this over the years, but to the community's credit, there's > fewer and fewer as time goes by. > > ObUnix: This shows the power of having the right abstractions and being > disciplined to code to those ideal abstractions any time there might be > reuse... True words. These concepts (what you call abstractions) is no optional geek pleasure but the most important information for everyone using the system or language. It's important to teach them, make them explicit, deal with them, substract points in exams for correct solutions that have bad style, keep the libraries and books on a high level, ... This is one of the lesser regarded aspects of what Unix did really well. meillo From kevin.bowling at kev009.com Mon Jan 13 06:25:13 2020 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Sun, 12 Jan 2020 13:25:13 -0700 Subject: [TUHS] Tech Sq elevator (Was: screen editors) In-Reply-To: References: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU> Message-ID: This is kind of illustrative of the '60s acid trip that perpetuates in programming "Everything's a string maaaaan". The output is seen as truth because the representation is for some reason too hard to get at or too hard to cascade through the system. There's a total comedy of work going on in the unix way of a wc pipeline versus calling a length function on a list. Nonetheless, the unix pipeline was and is often magnitude easier for a single user to get at. This kind of thing is amusing and endearing to me about our profession in modern day. Regards, Kevin On Sun, Jan 12, 2020 at 9:57 AM Warner Losh wrote: > > > > On Sun, Jan 12, 2020 at 6:44 AM Doug McIlroy wrote: >> >> Mention of elevators at Tech Square reminds me of visiting there >> to see the Lisp machine. I was struck by cultural differences. >> >> At the time we were using Jerqs, where multiple windows ran >> like multiple time-sharing sessions. To me that behavior was a >> no-brainer. Surprisingly, Lisp-machine windows didn't work that >> way; only the user-selected active window got processor time. >> >> The biggest difference was emacs, which no one used at Bell >> Labs. Emacs, of course was native to the Lisp machine and >> provided a powerful and smoothly extensible environment. For >> example, its reflective ability made it easy to display a >> list of its commands. "Call elevator" stood out amng mundane >> programmering actions like cut, paste and run. >> >> After scrolling through the command list, I wondered how long >> it was and asked to have it counted. Easy, I thought, just >> pass it to a wc-like program. But "just pass it" and "wc-like" >> were not givens as they are in Unix culture. It took several >> minutes for the gurus to do it--without leaving emacs, if I >> remember right. > > > It should have been something like (list-length (command-list-fn)) but I'll bet that ? was bound to a complicated function that just displayed the results and didn't properly abstract out the UI (printing) from the data collection (getting a list), which is what made it so hard. I've had so many gnu emacs experiences like this over the years, but to the community's credit, there's fewer and fewer as time goes by. > > ObUnix: This shows the power of having the right abstractions and being disciplined to code to those ideal abstractions any time there might be reuse... > > Warner From lm at mcvoy.com Mon Jan 13 06:32:41 2020 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 12 Jan 2020 12:32:41 -0800 Subject: [TUHS] Tech Sq elevator (Was: screen editors) In-Reply-To: References: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU> Message-ID: <20200112203241.GB9174@mcvoy.com> I'll counter with Linux's /proc where everything is a string. It's super pleasant and I say that coming from SysV /proc where it was all a mess. If performance is the metric, everything is a string is not so much. If performance is not the high order bit, a /proc that you can read with cat or grep is super pleasant. On Sun, Jan 12, 2020 at 01:25:13PM -0700, Kevin Bowling wrote: > This is kind of illustrative of the '60s acid trip that perpetuates in > programming "Everything's a string maaaaan". The output is seen as > truth because the representation is for some reason too hard to get at > or too hard to cascade through the system. > > There's a total comedy of work going on in the unix way of a wc > pipeline versus calling a length function on a list. Nonetheless, the > unix pipeline was and is often magnitude easier for a single user to > get at. This kind of thing is amusing and endearing to me about our > profession in modern day. > > Regards, > Kevin > > On Sun, Jan 12, 2020 at 9:57 AM Warner Losh wrote: > > > > > > > > On Sun, Jan 12, 2020 at 6:44 AM Doug McIlroy wrote: > >> > >> Mention of elevators at Tech Square reminds me of visiting there > >> to see the Lisp machine. I was struck by cultural differences. > >> > >> At the time we were using Jerqs, where multiple windows ran > >> like multiple time-sharing sessions. To me that behavior was a > >> no-brainer. Surprisingly, Lisp-machine windows didn't work that > >> way; only the user-selected active window got processor time. > >> > >> The biggest difference was emacs, which no one used at Bell > >> Labs. Emacs, of course was native to the Lisp machine and > >> provided a powerful and smoothly extensible environment. For > >> example, its reflective ability made it easy to display a > >> list of its commands. "Call elevator" stood out amng mundane > >> programmering actions like cut, paste and run. > >> > >> After scrolling through the command list, I wondered how long > >> it was and asked to have it counted. Easy, I thought, just > >> pass it to a wc-like program. But "just pass it" and "wc-like" > >> were not givens as they are in Unix culture. It took several > >> minutes for the gurus to do it--without leaving emacs, if I > >> remember right. > > > > > > It should have been something like (list-length (command-list-fn)) but I'll bet that ? was bound to a complicated function that just displayed the results and didn't properly abstract out the UI (printing) from the data collection (getting a list), which is what made it so hard. I've had so many gnu emacs experiences like this over the years, but to the community's credit, there's fewer and fewer as time goes by. > > > > ObUnix: This shows the power of having the right abstractions and being disciplined to code to those ideal abstractions any time there might be reuse... > > > > Warner -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From jon at fourwinds.com Mon Jan 13 06:34:26 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Sun, 12 Jan 2020 12:34:26 -0800 Subject: [TUHS] Tech Sq elevator (Was: screen editors) In-Reply-To: References: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU> Message-ID: <202001122034.00CKYQ39571239@darkstar.fourwinds.com> Kevin Bowling writes: > This is kind of illustrative of the '60s acid trip that perpetuates in > programming "Everything's a string maaaaan". The output is seen as > truth because the representation is for some reason too hard to get at > or too hard to cascade through the system. > > There's a total comedy of work going on in the unix way of a wc > pipeline versus calling a length function on a list. Nonetheless, the > unix pipeline was and is often magnitude easier for a single user to > get at. This kind of thing is amusing and endearing to me about our > profession in modern day. > > Regards, > Kevin Can you please elaborate? I read your post, and while I can see that it contains English words I can't make any sense out of what you said. Thanks, Jon From kevin.bowling at kev009.com Mon Jan 13 06:40:53 2020 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Sun, 12 Jan 2020 13:40:53 -0700 Subject: [TUHS] Tech Sq elevator (Was: screen editors) In-Reply-To: <202001122034.00CKYQ39571239@darkstar.fourwinds.com> References: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU> <202001122034.00CKYQ39571239@darkstar.fourwinds.com> Message-ID: I honestly can't tell if this is genius level snark :) in case you're sincere we generally go to great lengths to build up data types and structures (in C lingo) when programming only to tear those useful attributes off often at inopportune times. Basically type systems/type safety have been too expensive or too difficult to use through history. Think of sitting at an SQL prompt as a counterpoint. You can pretty easily get at the underlying representation and relationships of the data and the output is just a side effect. Not saying SQL is the ultimate answer, just that most people have a bit of experience with it and UNIX so can mentally compare the two for themselves and see the pros and cons to preserving the underlying representations. Regards, Kevin On Sun, Jan 12, 2020 at 1:34 PM Jon Steinhart wrote: > > Kevin Bowling writes: > > This is kind of illustrative of the '60s acid trip that perpetuates in > > programming "Everything's a string maaaaan". The output is seen as > > truth because the representation is for some reason too hard to get at > > or too hard to cascade through the system. > > > > There's a total comedy of work going on in the unix way of a wc > > pipeline versus calling a length function on a list. Nonetheless, the > > unix pipeline was and is often magnitude easier for a single user to > > get at. This kind of thing is amusing and endearing to me about our > > profession in modern day. > > > > Regards, > > Kevin > > Can you please elaborate? I read your post, and while I can see that it > contains English words I can't make any sense out of what you said. > > Thanks, > Jon From jon at fourwinds.com Mon Jan 13 06:44:30 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Sun, 12 Jan 2020 12:44:30 -0800 Subject: [TUHS] Tech Sq elevator (Was: screen editors) In-Reply-To: References: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU> <202001122034.00CKYQ39571239@darkstar.fourwinds.com> Message-ID: <202001122044.00CKiUNV573279@darkstar.fourwinds.com> Kevin Bowling writes: > I honestly can't tell if this is genius level snark :) in case you're > sincere we generally go to great lengths to build up data types and > structures (in C lingo) when programming only to tear those useful > attributes off often at inopportune times. Basically type > systems/type safety have been too expensive or too difficult to use > through history. > > Think of sitting at an SQL prompt as a counterpoint. You can pretty > easily get at the underlying representation and relationships of the > data and the output is just a side effect. Not saying SQL is the > ultimate answer, just that most people have a bit of experience with > it and UNIX so can mentally compare the two for themselves and see the > pros and cons to preserving the underlying representations. > > Regards, > Kevin > > On Sun, Jan 12, 2020 at 1:34 PM Jon Steinhart wrote: > > > > Kevin Bowling writes: > > > This is kind of illustrative of the '60s acid trip that perpetuates in > > > programming "Everything's a string maaaaan". The output is seen as > > > truth because the representation is for some reason too hard to get at > > > or too hard to cascade through the system. > > > > > > There's a total comedy of work going on in the unix way of a wc > > > pipeline versus calling a length function on a list. Nonetheless, the > > > unix pipeline was and is often magnitude easier for a single user to > > > get at. This kind of thing is amusing and endearing to me about our > > > profession in modern day. > > > > > > Regards, > > > Kevin > > > > Can you please elaborate? I read your post, and while I can see that it > > contains English words I can't make any sense out of what you said. > > > > Thanks, > > Jon I wasn't being snarky. You said "The output is seen as truth because the representation is for some reason too hard to get at or too hard to cascade through the system." I honestly have no idea what that means. Likewise, "There's a total comedy of work going on in the unix way of a wc pipeline versus calling a length function on a list." I just don't know what you mean. Jon From kevin.bowling at kev009.com Mon Jan 13 07:03:39 2020 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Sun, 12 Jan 2020 14:03:39 -0700 Subject: [TUHS] Tech Sq elevator (Was: screen editors) In-Reply-To: <202001122044.00CKiUNV573279@darkstar.fourwinds.com> References: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU> <202001122034.00CKYQ39571239@darkstar.fourwinds.com> <202001122044.00CKiUNV573279@darkstar.fourwinds.com> Message-ID: On Sun, Jan 12, 2020 at 1:45 PM Jon Steinhart wrote: > > Kevin Bowling writes: > > I honestly can't tell if this is genius level snark :) in case you're > > sincere we generally go to great lengths to build up data types and > > structures (in C lingo) when programming only to tear those useful > > attributes off often at inopportune times. Basically type > > systems/type safety have been too expensive or too difficult to use > > through history. > > > > Think of sitting at an SQL prompt as a counterpoint. You can pretty > > easily get at the underlying representation and relationships of the > > data and the output is just a side effect. Not saying SQL is the > > ultimate answer, just that most people have a bit of experience with > > it and UNIX so can mentally compare the two for themselves and see the > > pros and cons to preserving the underlying representations. > > > > Regards, > > Kevin > > > > On Sun, Jan 12, 2020 at 1:34 PM Jon Steinhart wrote: > > > > > > Kevin Bowling writes: > > > > This is kind of illustrative of the '60s acid trip that perpetuates in > > > > programming "Everything's a string maaaaan". The output is seen as > > > > truth because the representation is for some reason too hard to get at > > > > or too hard to cascade through the system. > > > > > > > > There's a total comedy of work going on in the unix way of a wc > > > > pipeline versus calling a length function on a list. Nonetheless, the > > > > unix pipeline was and is often magnitude easier for a single user to > > > > get at. This kind of thing is amusing and endearing to me about our > > > > profession in modern day. > > > > > > > > Regards, > > > > Kevin > > > > > > Can you please elaborate? I read your post, and while I can see that it > > > contains English words I can't make any sense out of what you said. > > > > > > Thanks, > > > Jon > > I wasn't being snarky. You said > > "The output is seen as truth because the representation is for some > reason too hard to get at or too hard to cascade through the system." > > I honestly have no idea what that means. If the SQL prompt example did not clarify you are welcome to go one on one if this is something you think is curious to you, I think I've explained the point I was making adequately for a general audience. > > Likewise, > > "There's a total comedy of work going on in the unix way of > a wc pipeline versus calling a length function on a list." > > I just don't know what you mean. > Reason through what happens in a shell pipeline, the more detail the better. A quick nudge is fork/exec, what happens in the kernel, what happens in page tables, what happens at the buffered output, tty layer etc. Very few people actually understand all these steps even at a general level in modern systems. If you had a grocery list on a piece of paper would you a) count the lines or read it directly off the last line number on the paper if it is numbered b) copy each character letter by letter to a new piece of equipment (say, a word processor), until you encounter a special character that happens to be represented as a space on the screen, increment a counter, repeat until you reach another special character, output the result and then destroy and throw away both the list and the word processor equipment. This kind of thing doesn't really matter in the small or at all for performance because computers are fast. But most programming bugs in the large eventually boil down to some kind of misunderstanding where the representation was lost and recast in a way that does not make sense. Regards, Kevin From jon at fourwinds.com Mon Jan 13 07:37:21 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Sun, 12 Jan 2020 13:37:21 -0800 Subject: [TUHS] Tech Sq elevator (Was: screen editors) [ really I think efficiency now ] In-Reply-To: References: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU> <202001122034.00CKYQ39571239@darkstar.fourwinds.com> <202001122044.00CKiUNV573279@darkstar.fourwinds.com> Message-ID: <202001122137.00CLbMrw582813@darkstar.fourwinds.com> Kevin Bowling writes: > On Sun, Jan 12, 2020 at 1:45 PM Jon Steinhart wrote: > > > > Kevin Bowling writes: > > > I honestly can't tell if this is genius level snark :) in case you're > > > sincere we generally go to great lengths to build up data types and > > > structures (in C lingo) when programming only to tear those useful > > > attributes off often at inopportune times. Basically type > > > systems/type safety have been too expensive or too difficult to use > > > through history. > > > > > > Think of sitting at an SQL prompt as a counterpoint. You can pretty > > > easily get at the underlying representation and relationships of the > > > data and the output is just a side effect. Not saying SQL is the > > > ultimate answer, just that most people have a bit of experience with > > > it and UNIX so can mentally compare the two for themselves and see the > > > pros and cons to preserving the underlying representations. > > > > > > Regards, > > > Kevin > > > > > > On Sun, Jan 12, 2020 at 1:34 PM Jon Steinhart wrote: > > > > > > > > Kevin Bowling writes: > > > > > This is kind of illustrative of the '60s acid trip that perpetuates in > > > > > programming "Everything's a string maaaaan". The output is seen as > > > > > truth because the representation is for some reason too hard to get at > > > > > or too hard to cascade through the system. > > > > > > > > > > There's a total comedy of work going on in the unix way of a wc > > > > > pipeline versus calling a length function on a list. Nonetheless, the > > > > > unix pipeline was and is often magnitude easier for a single user to > > > > > get at. This kind of thing is amusing and endearing to me about our > > > > > profession in modern day. > > > > > > > > > > Regards, > > > > > Kevin > > > > > > > > Can you please elaborate? I read your post, and while I can see that it > > > > contains English words I can't make any sense out of what you said. > > > > > > > > Thanks, > > > > Jon > > > > I wasn't being snarky. You said > > > > "The output is seen as truth because the representation is for some > > reason too hard to get at or too hard to cascade through the system." > > > > I honestly have no idea what that means. > > If the SQL prompt example did not clarify you are welcome to go one on > one if this is something you think is curious to you, I think I've > explained the point I was making adequately for a general audience. > > > > > Likewise, > > > > "There's a total comedy of work going on in the unix way of > > a wc pipeline versus calling a length function on a list." > > > > I just don't know what you mean. > > > > Reason through what happens in a shell pipeline, the more detail the > better. A quick nudge is fork/exec, what happens in the kernel, what > happens in page tables, what happens at the buffered output, tty layer > etc. Very few people actually understand all these steps even at a > general level in modern systems. > > If you had a grocery list on a piece of paper would you > a) count the lines or read it directly off the last line number on the > paper if it is numbered > > b) copy each character letter by letter to a new piece of equipment > (say, a word processor), until you encounter a special character that > happens to be represented as a space on the screen, increment a > counter, repeat until you reach another special character, output the > result and then destroy and throw away both the list and the word > processor equipment. > > This kind of thing doesn't really matter in the small or at all for > performance because computers are fast. But most programming bugs in > the large eventually boil down to some kind of misunderstanding where > the representation was lost and recast in a way that does not make > sense. > > Regards, > Kevin OK, I have trouble correlating this with your original post but I think that I understand it well enough to comment. I agree that it is a problem that very few people understand what's going on inside anything today from a toaster to a computer. On the computer end of things this concerns me a lot and improving the quality of education in this area is one of my main late-in-life missions. I'm under the illusion that I've helped some based on comments that I've received from people who have tracked me down and let me know how much the information in my book helped them. On to your example... If I had a grocery list on a piece of paper I would count the lines because I don't number my grocery lists. I'm going to guess that few people do. So, I would count the lines in my head and remember the result. This is pretty much equivalent to what happens when something is piped into wc. I don't see much difference between a and b in your example. That's because when I count up the number of lines in the list, I am making a temporary copy of the list in my head and then forgetting what was on the list (which may account for the late night trip to the grocery store a couple of days ago). So I think that the point that you're trying to make, correct me if I'm wrong, is that if lists just knew how long they were you could just ask and that it would be more efficient. While that may be true, it sort of assume that this is something so common that the extra overhead for line counting should be part of every list. And it doesn't address the issue that while maybe you want a line count I may want a character count or a count of all lines that begin with the letter A. Limiting this example to just line numbers ignores the fact that different people might want different information that can't all be predicted in advance and built into every program. It also seems to me that the root problem here is that the data in the original example was in an emacs-specific format instead of the default UNIX text file format. The beauty of UNIX is that with a common file format one can create tools that process data in different ways that then operate on all data. Yes, it's not as efficient as creating a custom tool for a particular purpose, but is much better for casual use. One can always create a special purpose tool if a particular use becomes so prevalent that the extra efficiency is worthwhile. If you're not familiar with it, find a copy of the Communications of the ACM issue where Knuth presented a clever search algorithm (if I remember correctly) and McIlroy did a critique. One of the things that Doug pointed out what that while Don's code was more efficient, by creating a new pile of special-purpose code he introduced bugs. Many people have claimed, incorrectly in my opinion, that this model fails in the modern era because it only works on text data. They change the subject when I point out that ImageMagick works on binary data. And, there are now stream processing utilities for JSON data and such that show that the UNIX model still works IF you understand it and know how to use it. I don't agree with your closing comment about "most programming bugs". Do you have any data to support this or is it just an opinion? My opinion is that most programming bugs today result from total incompetence as one can prety much get a computer science degree today without every learning that programs run on computers or what a computer is. That's something I'm trying to change, but it's probably a lost cause. A long topic, and not necessarily appropriate for this list. Jon From bakul at bitblocks.com Mon Jan 13 07:41:45 2020 From: bakul at bitblocks.com (Bakul Shah) Date: Sun, 12 Jan 2020 13:41:45 -0800 Subject: [TUHS] Tech Sq elevator (Was: screen editors) In-Reply-To: Your message of "Sun, 12 Jan 2020 12:44:30 -0800." <202001122044.00CKiUNV573279@darkstar.fourwinds.com> References: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU> <202001122034.00CKYQ39571239@darkstar.fourwinds.com> <202001122044.00CKiUNV573279@darkstar.fourwinds.com> Message-ID: <20200112214152.9824C156E42D@mail.bitblocks.com> On Sun, 12 Jan 2020 12:44:30 -0800 Jon Steinhart wrote: > > I wasn't being snarky. You said > > "The output is seen as truth because the representation is for some > reason too hard to get at or too hard to cascade through the system." > > I honestly have no idea what that means. > > Likewise, > > "There's a total comedy of work going on in the unix way of > a wc pipeline versus calling a length function on a list." > > I just don't know what you mean. May be this is not what Kevin meant but the way I interpreted his message: smushing everything down to strings for output as in unix pipelines loses any underlying structure which then may have to be rediscovered by the next program in the pipeline by parsing. This is slower, indirect and errorprone. If one can communicate a structured representation of data between components that would be better. From jon at fourwinds.com Mon Jan 13 07:47:44 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Sun, 12 Jan 2020 13:47:44 -0800 Subject: [TUHS] Tech Sq elevator (Was: screen editors) In-Reply-To: <20200112214152.9824C156E42D@mail.bitblocks.com> References: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU> <202001122034.00CKYQ39571239@darkstar.fourwinds.com> <202001122044.00CKiUNV573279@darkstar.fourwinds.com> <20200112214152.9824C156E42D@mail.bitblocks.com> Message-ID: <202001122147.00CLligX584670@darkstar.fourwinds.com> Bakul Shah writes: > On Sun, 12 Jan 2020 12:44:30 -0800 Jon Steinhart wrote: > > > > I wasn't being snarky. You said > > > > "The output is seen as truth because the representation is for some > > reason too hard to get at or too hard to cascade through the system." > > > > I honestly have no idea what that means. > > > > Likewise, > > > > "There's a total comedy of work going on in the unix way of > > a wc pipeline versus calling a length function on a list." > > > > I just don't know what you mean. > > May be this is not what Kevin meant but the way I interpreted > his message: smushing everything down to strings for output as > in unix pipelines loses any underlying structure which then > may have to be rediscovered by the next program in the > pipeline by parsing. This is slower, indirect and errorprone. > If one can communicate a structured representation of data between > components that would be better. Ah. So lines IS the structure that a lot of people want. As I just said in a post, the JSON tools are a good example of communicating structured data although I would have done them differently. Jon From doug at cs.dartmouth.edu Mon Jan 13 08:25:38 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sun, 12 Jan 2020 17:25:38 -0500 Subject: [TUHS] Tech Sq elevator (Was: screen editors) Message-ID: <202001122225.00CMPc9S085970@tahoe.cs.Dartmouth.EDU> >> After scrolling through the command list, I wondered how >> long it was and asked to have it counted. Easy, I thought, >> just pass it to a wc-like program. But "just pass it" and >> "wc-like" were not givens as they are in Unix culture. >> It took several minutes for the gurus to do it--without >> leaving emacs, if I remember right. > This is kind of illustrative of the '60s acid trip that > perpetuates in programming "Everything's a string maaaaan". > The output is seen as truth because the representation is > for some reason too hard to get at or too hard to cascade > through the system. How did strings get into the discussion? Warner showed how emacs could be expected to do the job--and more efficiently than the Unix way, at that: (list-length (command-list-fn)). The surprise was that this wasn't readily available. Back then, in fact, you couldn't ask sh for its command list. help|wc couldn't be done because help wasn't there. Emacs had a different problem. It had a universal internal interface--lists rather than strings--yet did not have a way to cause this particular list to "cascade through the system". (print(command-list-fn)) was provided, while (command-list-fn) was hidden. Doug From kevin.bowling at kev009.com Mon Jan 13 08:40:15 2020 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Sun, 12 Jan 2020 15:40:15 -0700 Subject: [TUHS] Tech Sq elevator (Was: screen editors) In-Reply-To: <202001122225.00CMPc9S085970@tahoe.cs.Dartmouth.EDU> References: <202001122225.00CMPc9S085970@tahoe.cs.Dartmouth.EDU> Message-ID: On Sun, Jan 12, 2020 at 3:26 PM Doug McIlroy wrote: > > >> After scrolling through the command list, I wondered how > >> long it was and asked to have it counted. Easy, I thought, > >> just pass it to a wc-like program. But "just pass it" and > >> "wc-like" were not givens as they are in Unix culture. > >> It took several minutes for the gurus to do it--without > >> leaving emacs, if I remember right. > > > This is kind of illustrative of the '60s acid trip that > > perpetuates in programming "Everything's a string maaaaan". > > The output is seen as truth because the representation is > > for some reason too hard to get at or too hard to cascade > > through the system. > > How did strings get into the discussion? Warner showed how > emacs could be expected to do the job--and more efficiently > than the Unix way, at that: (list-length (command-list-fn)). > The surprise was that this wasn't readily available. Bakul provided an explanation for the pipeline, the funny cue to me that I interpreted from Warner's message is just that emacs had the ability to do it in a coherent way but did not and ISTM that the way you make a mess of that is by losing the intent of the representation. I am regularly surprised by how surprising type systems are to computing professionals. The language and environment may help or dissuade you from doing that, wasn't really relevant to my original point. Larry tells me the message is somehow inflammatory, it wasn't intended that way I was just trying to make light of the situation and provide people a launch pad to think for themselves about some fundamentals because it's worthwhile to do so occasionally. > Back then, in fact, you couldn't ask sh for its command > list. help|wc couldn't be done because help wasn't there. > > Emacs had a different problem. It had a universal internal > interface--lists rather than strings--yet did not have > a way to cause this particular list to "cascade through > the system". (print(command-list-fn)) was provided, while > (command-list-fn) was hidden. The only response I can come up with to these two points eventually boils down to a philosophical riddle: does the work matter or does how the work is done matter? Both, the situation dictates. I execute innumerable shell pipelines per day and perhaps craft a dozen ephemerals ones. Regards, Kevin From jon at fourwinds.com Mon Jan 13 09:40:40 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Sun, 12 Jan 2020 15:40:40 -0800 Subject: [TUHS] Tech Sq elevator [ really type-checking ] In-Reply-To: References: <202001122225.00CMPc9S085970@tahoe.cs.Dartmouth.EDU> Message-ID: <202001122340.00CNeef0604557@darkstar.fourwinds.com> Kevin Bowling writes: > > I am regularly surprised by how surprising type systems are to > computing professionals. I am currently astonished at this. Unfortunately, I need to make a hopefully minor change to the linux kernel to support something that I want to do in my current project. But, this is my first time looking at the internals which is way different that my recollection of UNIX kernels. It's being enough of an adventure that I'm writing up a travelogue of my journey through the code. While I swore that I was done writing books this is sure looking like another one :-) So I came across this piece of what I consider to be bad programming that's all over the place... One of my programming style rules is to program in the language in which you're programming. The canonical example of not doing this is the Bourne shell which was originally written using macros to redefine C to look like Algol68. Linux contains several sets of list_for_each_entry() macros that are essentially obfuscated for loops that generate inefficient code. To make things worse, the way that they're implemented is by embedding list_head structures into other structures. In the diagram below, the labels above boxes are structure names. Names inside of boxes are structure member names. super_blocks, s_list, s_mounts, and mnt_instance are all list_head structures. (Trick question, how many lines are in this diagram :-) ) +-----------------------------------------+ | super_block | | +--------------+ +----------+ | +->| super_blocks |<->| s_list |<- ... -+ +--------------+ +----------+ | | mount mount | ... | +--------------+ +--------------+ | | | ... | | ... | +----------+ +--------------+ +--------------+ +->| s_mounts |<->| mnt_instance |<->| mnt_instance |<- ... -+ | +----------+ +--------------+ +--------------+ | | | ... | | ... | | | +--------------+ +--------------+ | +------------------------------------------------------------+ The bizarre thing to me is that the list_head structures point to other list_head structures that are embedded in other structures. When one needs to access a non list-head member of the structure one has to pass both the structure type and the list_head member name to a macro that figures out how to subtract the offset of the list_head member of the structure from the address of that list_head to get the address of the structure, and then casts that as the structure type so that members can be accessed. The reason why I think that this is bad is because one can pass anything into that macro; you just have to know what type of structures make up the list which is not at all obvious as: struct foo { int bar; struct list_head name; }; gives no information about the list, unlike this: struct foo { int bar; struct foo *next; }; It completely bypasses the compiler type-checking. In my opinion, very error prone. Not to mention completely opaque to someone reading the code. Without even the consideration of decent comments, for example: struct list_head s_list; /* Keep this first */ struct list_head s_mounts; /* list of mounts; _not_ for fs use */ struct list_head s_inodes_wb; /* writeback inodes */ say nothing about what type of structures are in the lists. In addition to generating less-efficient code than a for loop would and avoiding type-checking, this approach seems to be used without much thought in the kernel where memory is at a premium. Many of these are used to implement circular double-linked lists where neither the circularity nor the doubly-linking are needed or used. As an aside, one has to descend through 8 levels of macros calling macros and six extra header files just to track down what this stuff does and how it works. So I just don't get this at all. I have no idea why someone would code this way in C unless they just wanted to foist a construct from another language that they preferred. Somehow I expected better in the kernel. Like usual, I could be completely off-base here and if I am, please correct me. Jon From lm at mcvoy.com Mon Jan 13 09:50:51 2020 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 12 Jan 2020 15:50:51 -0800 Subject: [TUHS] Tech Sq elevator [ really type-checking ] In-Reply-To: <202001122340.00CNeef0604557@darkstar.fourwinds.com> References: <202001122225.00CMPc9S085970@tahoe.cs.Dartmouth.EDU> <202001122340.00CNeef0604557@darkstar.fourwinds.com> Message-ID: <20200112235051.GG9174@mcvoy.com> On Sun, Jan 12, 2020 at 03:40:40PM -0800, Jon Steinhart wrote: > Linux contains several sets of list_for_each_entry() macros that are essentially > obfuscated for loops that generate inefficient code. Very common idiom in any real system. BitKeeper has them as well, they are used everywhere. They are too useful to not use. The BitKeeper ones give you most of Perl's list capabilities. From jon at fourwinds.com Mon Jan 13 10:01:02 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Sun, 12 Jan 2020 16:01:02 -0800 Subject: [TUHS] Tech Sq elevator [ really type-checking ] In-Reply-To: <20200112235051.GG9174@mcvoy.com> References: <202001122225.00CMPc9S085970@tahoe.cs.Dartmouth.EDU> <202001122340.00CNeef0604557@darkstar.fourwinds.com> <20200112235051.GG9174@mcvoy.com> Message-ID: <202001130001.00D012bC608441@darkstar.fourwinds.com> Larry McVoy writes: > On Sun, Jan 12, 2020 at 03:40:40PM -0800, Jon Steinhart wrote: > > Linux contains several sets of list_for_each_entry() macros that are essentially > > obfuscated for loops that generate inefficient code. > > Very common idiom in any real system. BitKeeper has them as well, they are > used everywhere. They are too useful to not use. The BitKeeper ones give > you most of Perl's list capabilities. I don't see it. In the cases that I've seen so far in linux the only uses are inserting, deleting, and traversing lists. My opinion that anyone who can't write for (p = list; p != NULL; p = p->next) shouldn't be programming, much less in the kernel. To me, type-checking and code clarity are vastly more important. If I want to program in Perl, I do so. When I program in C that's what I do. I do want to be clear that I'm coming at this from a code maintenance angle. Code that I write for my personal use looks way different than what I write professionally. I'm willing to put in more work up front to make sure that other people can easily understand my code because I don't want to be stuck maintaining stuff. And I recognize that unless one is coding a web page with an expected lifespan of 30 seconds the cost of maintenance dwarfs the cost of development. Jon From lm at mcvoy.com Mon Jan 13 10:22:19 2020 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 12 Jan 2020 16:22:19 -0800 Subject: [TUHS] Tech Sq elevator [ really type-checking ] In-Reply-To: <202001130001.00D012bC608441@darkstar.fourwinds.com> References: <202001122225.00CMPc9S085970@tahoe.cs.Dartmouth.EDU> <202001122340.00CNeef0604557@darkstar.fourwinds.com> <20200112235051.GG9174@mcvoy.com> <202001130001.00D012bC608441@darkstar.fourwinds.com> Message-ID: <20200113002219.GJ9174@mcvoy.com> On Sun, Jan 12, 2020 at 04:01:02PM -0800, Jon Steinhart wrote: > Larry McVoy writes: > > On Sun, Jan 12, 2020 at 03:40:40PM -0800, Jon Steinhart wrote: > > > Linux contains several sets of list_for_each_entry() macros that are essentially > > > obfuscated for loops that generate inefficient code. > > > > Very common idiom in any real system. BitKeeper has them as well, they are > > used everywhere. They are too useful to not use. The BitKeeper ones give > > you most of Perl's list capabilities. > > I don't see it. In the cases that I've seen so far in linux the only uses are > inserting, deleting, and traversing lists. My opinion that anyone who can't > write > for (p = list; p != NULL; p = p->next) > > shouldn't be programming, much less in the kernel. To me, type-checking and > code clarity are vastly more important. If I want to program in Perl, I do > so. When I program in C that's what I do. > > I do want to be clear that I'm coming at this from a code maintenance angle. I'd argue that the code we wrote for BitKeeper would hold up as some of the most professionally written code ever. Every commit was peer reviewed by at least 2 other people, code that add/changed/deleted user interfaces had to have docs and tests. The philosophy is very much in line with code maintenance, I vetoed stuff that was clever, my mantra was "write once, read many so optimize for read". Some dude on twitter found our code when we open sourced it and tweeted something like "Wow, I've just spent the afternoon reading some of the best written C code I've ever seen. I didn't know C could be that nice". So it's not just my opinion, I don't know that dude. The list code that we have is super pleasant to use and has been in production use for over 2 decades. And we maintained it easily, our 24x7 *average* responsive time on a bug report was 24 minutes. The only reason it was that high was because we had to sleep (we were spread out from East to West coast). During working hours, response time was almost always under 10 minutes, usually 2-3 minutes. By "response", I don't mean some automated nonsense that says "We value your input, this is to let you know your report has been entered into our system". I mean an engineer looked at the problem, figured out what was causing the problem by looking at our source, about 90% of the time we knew what the fix was, and we sent an update to the bug report with that information. The list structure was auto resizing, it knew both how much was allocated and how much was used in the first word of the list (we resized only in powers of 2 so we could store size in log2 bits, used the rest of the bits for the length), you could have a list in as short as two words and it scaled really well to millions of entries. It was, and is, super useful. Wayne is back at Intel and he's teasing it out of our libc to use there. So you may not like it but that's you. It has worked well in an extremely professional environment. Well coding professional, personalities might have been a bit wonky :) From jon at fourwinds.com Mon Jan 13 10:31:10 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Sun, 12 Jan 2020 16:31:10 -0800 Subject: [TUHS] Tech Sq elevator [ really type-checking ] In-Reply-To: <20200113002219.GJ9174@mcvoy.com> References: <202001122225.00CMPc9S085970@tahoe.cs.Dartmouth.EDU> <202001122340.00CNeef0604557@darkstar.fourwinds.com> <20200112235051.GG9174@mcvoy.com> <202001130001.00D012bC608441@darkstar.fourwinds.com> <20200113002219.GJ9174@mcvoy.com> Message-ID: <202001130031.00D0VAuW613942@darkstar.fourwinds.com> Larry McVoy writes: > On Sun, Jan 12, 2020 at 04:01:02PM -0800, Jon Steinhart wrote: > > Larry McVoy writes: > > > On Sun, Jan 12, 2020 at 03:40:40PM -0800, Jon Steinhart wrote: > > > > Linux contains several sets of list_for_each_entry() macros that are essentially > > > > obfuscated for loops that generate inefficient code. > > > > > > Very common idiom in any real system. BitKeeper has them as well, they are > > > used everywhere. They are too useful to not use. The BitKeeper ones give > > > you most of Perl's list capabilities. > > > > I don't see it. In the cases that I've seen so far in linux the only uses are > > inserting, deleting, and traversing lists. My opinion that anyone who can't > > write > > for (p = list; p != NULL; p = p->next) > > > > shouldn't be programming, much less in the kernel. To me, type-checking and > > code clarity are vastly more important. If I want to program in Perl, I do > > so. When I program in C that's what I do. > > > > I do want to be clear that I'm coming at this from a code maintenance angle. > > I'd argue that the code we wrote for BitKeeper would hold up as some > of the most professionally written code ever. Every commit was peer > reviewed by at least 2 other people, code that add/changed/deleted user > interfaces had to have docs and tests. The philosophy is very much in > line with code maintenance, I vetoed stuff that was clever, my mantra was > "write once, read many so optimize for read". > > Some dude on twitter found our code when we open sourced it and tweeted > something like "Wow, I've just spent the afternoon reading some of the > best written C code I've ever seen. I didn't know C could be that nice". > So it's not just my opinion, I don't know that dude. > > The list code that we have is super pleasant to use and has been > in production use for over 2 decades. And we maintained it easily, > our 24x7 *average* responsive time on a bug report was 24 minutes. > The only reason it was that high was because we had to sleep (we were > spread out from East to West coast). During working hours, response time > was almost always under 10 minutes, usually 2-3 minutes. By "response", > I don't mean some automated nonsense that says "We value your input, > this is to let you know your report has been entered into our system". > I mean an engineer looked at the problem, figured out what was causing the > problem by looking at our source, about 90% of the time we knew what the > fix was, and we sent an update to the bug report with that information. > > The list structure was auto resizing, it knew both how much was allocated > and how much was used in the first word of the list (we resized only in > powers of 2 so we could store size in log2 bits, used the rest of the > bits for the length), you could have a list in as short as two words > and it scaled really well to millions of entries. > > It was, and is, super useful. Wayne is back at Intel and he's teasing > it out of our libc to use there. > > So you may not like it but that's you. It has worked well in an extremely > professional environment. Well coding professional, personalities might > have been a bit wonky :) I was commenting on what I found in the linux kernel. Your code and list interface may be better. Jon From bakul at bitblocks.com Mon Jan 13 10:35:51 2020 From: bakul at bitblocks.com (Bakul Shah) Date: Sun, 12 Jan 2020 16:35:51 -0800 Subject: [TUHS] Tech Sq elevator [ really type-checking ] In-Reply-To: <202001122340.00CNeef0604557@darkstar.fourwinds.com> References: <202001122225.00CMPc9S085970@tahoe.cs.Dartmouth.EDU> <202001122340.00CNeef0604557@darkstar.fourwinds.com> Message-ID: On Jan 12, 2020, at 3:40 PM, Jon Steinhart wrote: > > Kevin Bowling writes: >> >> I am regularly surprised by how surprising type systems are to >> computing professionals. > > I am currently astonished at this. Unfortunately, I need to make a hopefully > minor change to the linux kernel to support something that I want to do in my > current project. But, this is my first time looking at the internals which is > way different that my recollection of UNIX kernels. It's being enough of an > adventure that I'm writing up a travelogue of my journey through the code. > While I swore that I was done writing books this is sure looking like another > one :-) > > So I came across this piece of what I consider to be bad programming that's > all over the place... > > One of my programming style rules is to program in the language in which you're > programming. The canonical example of not doing this is the Bourne shell which > was originally written using macros to redefine C to look like Algol68. > > Linux contains several sets of list_for_each_entry() macros that are essentially > obfuscated for loops that generate inefficient code. To make things worse, the > way that they're implemented is by embedding list_head structures into other > structures. > > In the diagram below, the labels above boxes are structure names. Names inside > of boxes are structure member names. super_blocks, s_list, s_mounts, and > mnt_instance are all list_head structures. (Trick question, how many lines are > in this diagram :-) ) > > +-----------------------------------------+ > | super_block | > | +--------------+ +----------+ | > +->| super_blocks |<->| s_list |<- ... -+ > +--------------+ +----------+ > | | mount mount > | ... | +--------------+ +--------------+ > | | | ... | | ... | > +----------+ +--------------+ +--------------+ > +->| s_mounts |<->| mnt_instance |<->| mnt_instance |<- ... -+ > | +----------+ +--------------+ +--------------+ | > | | ... | | ... | | > | +--------------+ +--------------+ | > +------------------------------------------------------------+ > > The bizarre thing to me is that the list_head structures point to other list_head > structures that are embedded in other structures. When one needs to access a > non list-head member of the structure one has to pass both the structure type and > the list_head member name to a macro that figures out how to subtract the offset > of the list_head member of the structure from the address of that list_head to > get the address of the structure, and then casts that as the structure type so > that members can be accessed. There is similar code in FreeBSD kernel. Embedding head and next ptrs reduces memory allocation and improves cache locality somewhat. Since C doesn't have generics, they try to gain the same functionality with macros. See https://github.com/freebsd/freebsd/blob/master/sys/sys/queue.h Not that this is the same as what Linux does (which I haven't dug into) but I suspect they may have had similar motivation. From jon at fourwinds.com Mon Jan 13 10:44:47 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Sun, 12 Jan 2020 16:44:47 -0800 Subject: [TUHS] Tech Sq elevator [ really type-checking ] In-Reply-To: References: <202001122225.00CMPc9S085970@tahoe.cs.Dartmouth.EDU> <202001122340.00CNeef0604557@darkstar.fourwinds.com> Message-ID: <202001130044.00D0ilcV616661@darkstar.fourwinds.com> Bakul Shah writes: > On Jan 12, 2020, at 3:40 PM, Jon Steinhart wrote: > > > > Kevin Bowling writes: > >> > >> I am regularly surprised by how surprising type systems are to > >> computing professionals. > > > > I am currently astonished at this. Unfortunately, I need to make a hopefully > > minor change to the linux kernel to support something that I want to do in my > > current project. But, this is my first time looking at the internals which is > > way different that my recollection of UNIX kernels. It's being enough of an > > adventure that I'm writing up a travelogue of my journey through the code. > > While I swore that I was done writing books this is sure looking like another > > one :-) > > > > So I came across this piece of what I consider to be bad programming that's > > all over the place... > > > > One of my programming style rules is to program in the language in which you're > > programming. The canonical example of not doing this is the Bourne shell which > > was originally written using macros to redefine C to look like Algol68. > > > > Linux contains several sets of list_for_each_entry() macros that are essentially > > obfuscated for loops that generate inefficient code. To make things worse, the > > way that they're implemented is by embedding list_head structures into other > > structures. > > > > In the diagram below, the labels above boxes are structure names. Names inside > > of boxes are structure member names. super_blocks, s_list, s_mounts, and > > mnt_instance are all list_head structures. (Trick question, how many lines are > > in this diagram :-) ) > > > > +-----------------------------------------+ > > | super_block | > > | +--------------+ +----------+ | > > +->| super_blocks |<->| s_list |<- ... -+ > > +--------------+ +----------+ > > | | mount mount > > | ... | +--------------+ +--------------+ > > | | | ... | | ... | > > +----------+ +--------------+ +--------------+ > > +->| s_mounts |<->| mnt_instance |<->| mnt_instance |<- ... -+ > > | +----------+ +--------------+ +--------------+ | > > | | ... | | ... | | > > | +--------------+ +--------------+ | > > +------------------------------------------------------------+ > > > > The bizarre thing to me is that the list_head structures point to other list_head > > structures that are embedded in other structures. When one needs to access a > > non list-head member of the structure one has to pass both the structure type and > > the list_head member name to a macro that figures out how to subtract the offset > > of the list_head member of the structure from the address of that list_head to > > get the address of the structure, and then casts that as the structure type so > > that members can be accessed. > > There is similar code in FreeBSD kernel. Embedding head and next ptrs reduces > memory allocation and improves cache locality somewhat. Since C doesn't have > generics, they try to gain the same functionality with macros. See > > https://github.com/freebsd/freebsd/blob/master/sys/sys/queue.h > > Not that this is the same as what Linux does (which I haven't dug into) but > I suspect they may have had similar motivation. Not sure that I understand. A list_head structure takes exactly the same amount of space as a pair of pointers, so the memory allocation should be identical. I also don't see the cache locality. Both the embedded list_head and the start of the structure are accessed in either case; once the programmer has played guess-the-type the list macro returns a pointer to the start of the structure. So again, I'm just commenting on what I'm seeing in linux, and while it is possible that I may be misunderstanding something so far I don't think so. Jon From wkt at tuhs.org Mon Jan 13 10:49:12 2020 From: wkt at tuhs.org (Warren Toomey) Date: Mon, 13 Jan 2020 10:49:12 +1000 Subject: [TUHS] Tech Sq elevator [ really type-checking ] In-Reply-To: <202001130044.00D0ilcV616661@darkstar.fourwinds.com> References: <202001122225.00CMPc9S085970@tahoe.cs.Dartmouth.EDU> <202001122340.00CNeef0604557@darkstar.fourwinds.com> <202001130044.00D0ilcV616661@darkstar.fourwinds.com> Message-ID: <20200113004912.GA27610@minnie.tuhs.org> All, can we move this not-really-Unix discussion to COFF? Thanks, Warren P.S A bit more self-regulation too, please. You shouldn't need me to point out when the topic has drifted so far :-) From tytso at mit.edu Mon Jan 13 10:44:33 2020 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Sun, 12 Jan 2020 19:44:33 -0500 Subject: [TUHS] Tech Sq elevator [ really type-checking ] In-Reply-To: <202001130001.00D012bC608441@darkstar.fourwinds.com> References: <202001122225.00CMPc9S085970@tahoe.cs.Dartmouth.EDU> <202001122340.00CNeef0604557@darkstar.fourwinds.com> <20200112235051.GG9174@mcvoy.com> <202001130001.00D012bC608441@darkstar.fourwinds.com> Message-ID: <20200113004433.GA440748@mit.edu> (Not sure this is appropriate for TUHS) On Sun, Jan 12, 2020 at 04:01:02PM -0800, Jon Steinhart wrote: > Larry McVoy writes: > > On Sun, Jan 12, 2020 at 03:40:40PM -0800, Jon Steinhart wrote: > > > Linux contains several sets of list_for_each_entry() macros that are essentially > > > obfuscated for loops that generate inefficient code. > > > > Very common idiom in any real system. BitKeeper has them as well, they are > > used everywhere. They are too useful to not use. The BitKeeper ones give > > you most of Perl's list capabilities. > > I don't see it. In the cases that I've seen so far in linux the only uses are > inserting, deleting, and traversing lists. My opinion that anyone who can't > write > for (p = list; p != NULL; p = p->next) There are many places where there is a desire to (a) add an object to the end of the list (b) remove an object from a linked list where the object was not found via iterating over the linked list One or the other was true for all of the linked lists that you complained about earlier up-thread. For example, a struct super has a doubly linked list of struct mount where we might want to drop a struct mount without needing iterate over the whole linked list. So "just use an open-coded singly linked list" is really not that simple. In addition, it should be noted that there are read-copy-update variants of these functions (e.g., list_for_each_entry_rcu, list_del_rcu) that can be used with the same struct list_head structure. Sure, it would be simpler to just take a global kernel lock, and iterating over the entire singly linked list to remove an object from it, or adding an object to the end of a list. That would be *simpler*. But that would be much more, not less, inefficient. Cheers, - Ted From wkt at tuhs.org Mon Jan 13 12:13:03 2020 From: wkt at tuhs.org (Warren Toomey) Date: Mon, 13 Jan 2020 12:13:03 +1000 Subject: [TUHS] OK, keep going on type checking Message-ID: <20200113021303.GA7633@minnie.tuhs.org> All, I've had a few subscribers argue that the type checking thread was still Unix-related, so feel free to keep posting here in TUHS. But if it does drift away to non-Unix areas, please pass it over to COFF. Thanks & apologies for being too trigger-happy! Cheers, Warren From paul.winalski at gmail.com Tue Jan 14 05:58:12 2020 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 13 Jan 2020 14:58:12 -0500 Subject: [TUHS] History of symbol preemption Message-ID: The Executable and Linkable Format (ELF) is the modern standard for object files in Unix and Unix-like OSes (e.g., Linux), and even for OpenVMS. LInux, AIX and probably other implementations of ELF have a feature in the runtime loader called symbol preemption. When loading a shared library, the runtime loader examines the library's symbol table. If there is a global symbol with default visibility, and a value for that symbol has already been loaded, all references to the symbol in the library being loaded are rebound to the existing definition. The existing value thus preempts the definition in the library. I'm curious about the history of symbol preemption. It does not exist in other implementations of shared libraries, such as IBM OS/370 and its descendants, OpenVMS, and Microsoft Windows NT. ELF apparently was designed in the mid-1990s. I have found a copy of the System V Application Binary Interface from April 2001 that describes symbol preemption in the section on the ELF symbol table. When was symbol preemption when loading shared objects first implemented in Unix? Are there versions of Unix that don't do symbol preemption? -Paul W. From rp at servium.ch Tue Jan 14 06:46:52 2020 From: rp at servium.ch (Rico Pajarola) Date: Mon, 13 Jan 2020 12:46:52 -0800 Subject: [TUHS] History of symbol preemption In-Reply-To: References: Message-ID: This seems to have originated with SunOS 4. I believe a good proxy for finding anything that inherited from or was inspired by this is a linker that recognizes LD_PRELOAD. I wonder if there are other independent implementations in the Unix space. On Mon, Jan 13, 2020 at 11:59 AM Paul Winalski wrote: > The Executable and Linkable Format (ELF) is the modern standard for > object files in Unix and Unix-like OSes (e.g., Linux), and even for > OpenVMS. LInux, AIX and probably other implementations of ELF have a > feature in the runtime loader called symbol preemption. When loading > a shared library, the runtime loader examines the library's symbol > table. If there is a global symbol with default visibility, and a > value for that symbol has already been loaded, all references to the > symbol in the library being loaded are rebound to the existing > definition. The existing value thus preempts the definition in the > library. > > I'm curious about the history of symbol preemption. It does not exist > in other implementations of shared libraries, such as IBM OS/370 and > its descendants, OpenVMS, and Microsoft Windows NT. ELF apparently > was designed in the mid-1990s. I have found a copy of the System V > Application Binary Interface from April 2001 that describes symbol > preemption in the section on the ELF symbol table. > > When was symbol preemption when loading shared objects first > implemented in Unix? Are there versions of Unix that don't do symbol > preemption? > > -Paul W. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Jan 14 07:04:14 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 13 Jan 2020 16:04:14 -0500 Subject: [TUHS] History of symbol preemption In-Reply-To: References: Message-ID: @ Rico I'm failing sure ELF came from AT&T Summit, not Sun. @ Steve Johnson were you the manager when was created or were you folks still using COFF? Anyway... There were issues with COFF WRT being architecture-independent and supporting dynamic loading well. Steve Rago would also be a good person to ask if you want some of the details. At one point there was a COFF2 document, but it may have been System Vx licenses only. Also, one of the issues was that AT&T had officially tied up COFF as a proprietary format -- all part of the 'consider it standard' trying to force their lunch down all the other UNIX systems throat which was not having it. As a result, CMU's MachO was about to become the default format (OSF and Apple were already using it for that reason), and Unix International stepped in and convinced AT&T to released the ELF documents (I was on the UI technical board at that point). I'm not sure how/why OSF decided to back off, maybe because after ELF became public it got supported by GCC. Now my memory is a little hazy... I think OSF/1-386 used MachO originally, but I've forgotten. Switching the kernel to use ELF was one of the differences between OSF1 and Tru64 IIRC. On Mon, Jan 13, 2020 at 3:47 PM Rico Pajarola wrote: > This seems to have originated with SunOS 4. I believe a good proxy for > finding anything that inherited from or was inspired by this is a linker > that recognizes LD_PRELOAD. I wonder if there are other independent > implementations in the Unix space. > > > On Mon, Jan 13, 2020 at 11:59 AM Paul Winalski > wrote: > >> The Executable and Linkable Format (ELF) is the modern standard for >> object files in Unix and Unix-like OSes (e.g., Linux), and even for >> OpenVMS. LInux, AIX and probably other implementations of ELF have a >> feature in the runtime loader called symbol preemption. When loading >> a shared library, the runtime loader examines the library's symbol >> table. If there is a global symbol with default visibility, and a >> value for that symbol has already been loaded, all references to the >> symbol in the library being loaded are rebound to the existing >> definition. The existing value thus preempts the definition in the >> library. >> >> I'm curious about the history of symbol preemption. It does not exist >> in other implementations of shared libraries, such as IBM OS/370 and >> its descendants, OpenVMS, and Microsoft Windows NT. ELF apparently >> was designed in the mid-1990s. I have found a copy of the System V >> Application Binary Interface from April 2001 that describes symbol >> preemption in the section on the ELF symbol table. >> >> When was symbol preemption when loading shared objects first >> implemented in Unix? Are there versions of Unix that don't do symbol >> preemption? >> >> -Paul W. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rp at servium.ch Tue Jan 14 07:40:35 2020 From: rp at servium.ch (Rico Pajarola) Date: Mon, 13 Jan 2020 13:40:35 -0800 Subject: [TUHS] History of symbol preemption In-Reply-To: References: Message-ID: On Mon, Jan 13, 2020 at 1:04 PM Clem Cole wrote: > @ Rico I'm failing sure ELF came from AT&T Summit, not Sun. > yes, but unless my memory is playing tricks, SunOS a.out had this feature. > @ Steve Johnson were you the manager when was created or were you folks > still using COFF? > > Anyway... There were issues with COFF WRT being > architecture-independent and supporting dynamic loading well. Steve Rago > would also be a good person to ask if you want some of the details. At one > point there was a COFF2 document, but it may have been System Vx licenses > only. Also, one of the issues was that AT&T had officially tied up COFF > as a proprietary format -- all part of the 'consider it standard' trying to > force their lunch down all the other UNIX systems throat which was not > having it. As a result, CMU's MachO was about to become the default > format (OSF and Apple were already using it for that reason), and Unix > International stepped in and convinced AT&T to released the ELF documents > (I was on the UI technical board at that point). I'm not sure how/why OSF > decided to back off, maybe because after ELF became public it got supported > by GCC. > > Now my memory is a little hazy... I think OSF/1-386 used MachO originally, > but I've forgotten. Switching the kernel to use ELF was one of the > differences between OSF1 and Tru64 IIRC. > > On Mon, Jan 13, 2020 at 3:47 PM Rico Pajarola wrote: > >> This seems to have originated with SunOS 4. I believe a good proxy for >> finding anything that inherited from or was inspired by this is a linker >> that recognizes LD_PRELOAD. I wonder if there are other independent >> implementations in the Unix space. >> >> >> On Mon, Jan 13, 2020 at 11:59 AM Paul Winalski >> wrote: >> >>> The Executable and Linkable Format (ELF) is the modern standard for >>> object files in Unix and Unix-like OSes (e.g., Linux), and even for >>> OpenVMS. LInux, AIX and probably other implementations of ELF have a >>> feature in the runtime loader called symbol preemption. When loading >>> a shared library, the runtime loader examines the library's symbol >>> table. If there is a global symbol with default visibility, and a >>> value for that symbol has already been loaded, all references to the >>> symbol in the library being loaded are rebound to the existing >>> definition. The existing value thus preempts the definition in the >>> library. >>> >>> I'm curious about the history of symbol preemption. It does not exist >>> in other implementations of shared libraries, such as IBM OS/370 and >>> its descendants, OpenVMS, and Microsoft Windows NT. ELF apparently >>> was designed in the mid-1990s. I have found a copy of the System V >>> Application Binary Interface from April 2001 that describes symbol >>> preemption in the section on the ELF symbol table. >>> >>> When was symbol preemption when loading shared objects first >>> implemented in Unix? Are there versions of Unix that don't do symbol >>> preemption? >>> >>> -Paul W. >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Tue Jan 14 07:42:24 2020 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 13 Jan 2020 16:42:24 -0500 Subject: [TUHS] History of symbol preemption In-Reply-To: References: Message-ID: On 1/13/20, Clem Cole wrote: > > As a result, CMU's MachO was about to become the default > format (OSF and Apple were already using it for that reason), and Unix > International stepped in and convinced AT&T to released the ELF documents > (I was on the UI technical board at that point). I'm not sure how/why OSF > decided to back off, maybe because after ELF became public it got supported > by GCC. Mach-O was decidedly a step up from a.out in terms of flexibility and extensibility, but it is inferior to both COFF and ELF, IMO. Mach-O (at least the Apple OS X implementation) handles global symbols and relocations in a clumsy and baroque way. Of the three object/executable formats, ELF is by far the cleanest and most flexible, and that's possibly why OSF went to it once it became available. Microsoft went with COFF, sort-of, in Windows. But PECOFF (Portable and Extensible Common Object File Format) is different enough from vanilla COFF that when I implemented support for it in GEM I found to better to write an entire new module for PECOFF rather than put conditional code in the existing COFF-handling code. I think this was another of MS's "embrace and extend" gambits to keep control over their development environment. > Now my memory is a little hazy... I think OSF/1-386 used MachO originally, > but I've forgotten. Switching the kernel to use ELF was one of the > differences between OSF1 and Tru64 IIRC. GEM never had to support Mach-O on any of its target platforms. DEC's Unix on MIPS used COFF. Tru64 used ELF exclusively. I don't know what Apple used for object files before OS X. IIRC NeXT was based on the CMU MACH microkernel and hence used Mach-O. OS X is FreeBSD-based, but it uses Mach-O. Tru64 has symbol preemption. The Tru64 C/C++ compiler by default turns off symbol preemption by using PROTECTED visibility for global symbols, but it does have a --preempt_symbol option. Using that option can have disastrous effects on optimization. Was symbol visibility (default/protected/internal) part of the original ELF spec from the 1990s, or was it added later? -Paul W. From paul.winalski at gmail.com Tue Jan 14 07:44:46 2020 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 13 Jan 2020 16:44:46 -0500 Subject: [TUHS] History of symbol preemption In-Reply-To: References: Message-ID: On 1/13/20, Rico Pajarola wrote: > > yes, but unless my memory is playing tricks, SunOS a.out had this feature. Do you mean support for shared libraries, or symbol preemption? -Paul W. From rp at servium.ch Tue Jan 14 07:45:48 2020 From: rp at servium.ch (Rico Pajarola) Date: Mon, 13 Jan 2020 13:45:48 -0800 Subject: [TUHS] History of symbol preemption In-Reply-To: References: Message-ID: On Mon, Jan 13, 2020 at 1:44 PM Paul Winalski wrote: > On 1/13/20, Rico Pajarola wrote: > > > > yes, but unless my memory is playing tricks, SunOS a.out had this > feature. > > Do you mean support for shared libraries, or symbol preemption? > symbol preemption > -Paul W. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Tue Jan 14 08:20:21 2020 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 13 Jan 2020 14:20:21 -0800 Subject: [TUHS] History of symbol preemption In-Reply-To: References: Message-ID: <20200113222021.GG8511@mcvoy.com> On Mon, Jan 13, 2020 at 01:45:48PM -0800, Rico Pajarola wrote: > On Mon, Jan 13, 2020 at 1:44 PM Paul Winalski > wrote: > > > On 1/13/20, Rico Pajarola wrote: > > > > > > yes, but unless my memory is playing tricks, SunOS a.out had this > > feature. > > > > Do you mean support for shared libraries, or symbol preemption? > > > symbol preemption My memory of this is it was dns lookups that wanted something like this. SunOS really wanted the world to love YP but the world wanted Sun to support DNS. You could, and people did, make a shared lib that overloaded the default gethostbyname(3) that wanted to do YP, the lib would provide a DNS based one instead. That's where I first learned of this stuff. Gingell would know if you want to know for sure. From cbbrowne at gmail.com Tue Jan 14 08:38:03 2020 From: cbbrowne at gmail.com (Christopher Browne) Date: Mon, 13 Jan 2020 17:38:03 -0500 Subject: [TUHS] OK, keep going on type checking In-Reply-To: <20200113021303.GA7633@minnie.tuhs.org> References: <20200113021303.GA7633@minnie.tuhs.org> Message-ID: On Sun, 12 Jan 2020 at 21:13, Warren Toomey wrote: > All, I've had a few subscribers argue that the type checking > thread was still Unix-related, so feel free to keep posting > here in TUHS. But if it does drift away to non-Unix areas, > please pass it over to COFF. > > Thanks & apologies for being too trigger-happy! > Discussion is just busy enough that it's good to keep things somewhat on track :-). I have something that has been lurking on my ToDo list that's on this trail in what I'd think is a relevant way :-) ~/GitWeb> task project:shell | cat ID Active Age Project Tag Description Urg -- ------ --- ------- ---- ----------- ---- 24 2w 4w shell unix Oh Types 14 Oh is a claimant to the notion of trying to evolve shells to "better." https://github.com/michaelmacinnis/oh The name is probably not for the best, but it seems interesting. MacInnis noted several problems common to shells, and somewhat strong typing falls into the set of would-be solutions. He noticed that there have been lots of attempts to create shells that are embedded in other languages, which seems universally to lead to them falling into being curiosities. Embedding scripts in Lisp or Python or Perl never seems to turn out. The pains he points at are... - Undefined variables lead to bugs. set -e -u and such may help, but are optional... - automatically varadic functions can easily just lose parameters - splitting lists on whitespace blows up when files are allowed to have spaces in their names - return values intentionally look like process return codes, which can be good, or not... - global variables are mostly all you have, preventing having much modularity - variable expansions/rewrites have sometimes tortured syntax He built a shell that has a Scheme lying in behind (which I partly like, and partly find suspicious). Mechanisms to address the above are: - data and code have the same syntax (conses) - a richer type set (strings, symbols, return codes, a number tower of Int/Float/Rational, lists, environments) - first class environments that support modularity - Fexprs (see John N Shutt's thesis, vau: the ultimate abstraction) allow implementing your own control structures - dynamic communications patterns (Rob Pike did a paper on this, on Squeak) The early bits point at Scheme; dynamic comm points at Go channels, and the shell is written in Go. I have had this percolating in my head the last few weeks, and I watched the recent conversation about what ":" means with interest, as Oh makes interesting use of :, using it to indicate that the remaining portion of a command line is to be evaluated/expanded, thus: oh$ write: div 65536 256 2 (add 4 3) 128/7 oh$ define lc3: quote: a b c oh$ echo $lc3 a b c For a wee while, I was getting quite tortured by its interpretation (that I had not yet internalized) of : I have been unable as of yet to decide if the author's on to something, or if this is a mere curiosity. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?" -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Tue Jan 14 08:53:48 2020 From: henry.r.bent at gmail.com (Henry Bent) Date: Mon, 13 Jan 2020 17:53:48 -0500 Subject: [TUHS] History of symbol preemption In-Reply-To: References: Message-ID: On Mon, 13 Jan 2020 at 16:43, Paul Winalski wrote: > > > Now my memory is a little hazy... I think OSF/1-386 used MachO > originally, > > but I've forgotten. Switching the kernel to use ELF was one of the > > differences between OSF1 and Tru64 IIRC. > > GEM never had to support Mach-O on any of its target platforms. DEC's > Unix on MIPS used COFF. Tru64 used ELF exclusively. I don't know > what Apple used for object files before OS X. IIRC NeXT was based on > the CMU MACH microkernel and hence used Mach-O. OS X is > FreeBSD-based, but it uses Mach-O. > OSF/1 on MIPS used ECOFF by default, but at least some versions could also create and run ELF executables. That was all early to mid 1992, I believe. I don't have my DECstation up right now to check but I'm sure that the OSF/1 2.0 beta can do it, and I wouldn't be surprised if the versions of 1.0 with the v3.0 compiler could also do it. I remember trying to do ELF shared libraries but I think that support wasn't ready yet, which is a shame because the ECOFF shared libraries on that platform are not fun to deal with. Not as bad as SGI's ECOFF shared libraries on IRIX 4 though. I'm not sure if anyone outside of SGI ever bothered to put in the work required to make one. Wasn't OSF's original intent to use the OSF/ROSE object format? -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Tue Jan 14 09:46:43 2020 From: crossd at gmail.com (Dan Cross) Date: Mon, 13 Jan 2020 18:46:43 -0500 Subject: [TUHS] Tech Sq elevator (Was: screen editors) [ really I think efficiency now ] In-Reply-To: References: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU> <202001122034.00CKYQ39571239@darkstar.fourwinds.com> <202001122044.00CKiUNV573279@darkstar.fourwinds.com> <202001122137.00CLbMrw582813@darkstar.fourwinds.com> Message-ID: [Resending as this got squashed a few days ago. Jon, sorry for the duplicate. Again.] On Sun, Jan 12, 2020 at 4:38 PM Jon Steinhart wrote: > [snip] > So I think that the point that you're trying to make, correct me if I'm > wrong, > is that if lists just knew how long they were you could just ask and that > it > would be more efficient. > What I understood was that, by translating into a lowest-common-denominator format like text, one loses much of the semantic information implicit in a richer representation. In particular, much of the internal knowledge (like type information...) is lost during translation and presentation. Put another way, with text as usually used by the standard suite of Unix tools, type information is implicit, rather than explicit. I took this to be less an issue of efficiency and more of expressiveness. It is, perhaps, important to remember that Unix works so well because of heavy use of convention: to take Doug's example, the total number of commands might be easy to find with `wc` because one assumes each command is presented on a separate line, with no gaudy header or footer information or extraneous explanatory text. This sort of convention, where each logical "record" is a line by itself, is pervasive on Unix systems, but is not guaranteed. In some sense, those representations are fragile: a change in output might break something else downstream in the pipeline, whereas a representation that captures more semantic meaning is more robust in the face of change but, as in Doug's example, often harder to use. The Lisp Machine had all sorts of cool information in the image and a good Lisp hacker familiar with the machine's structures could write programs to extract and present that information. But doing so wasn't trivial in the way that '| wc -l' in response to a casual query is. While that may be true, it sort of assume that this is something so common > that > the extra overhead for line counting should be part of every list. And it > doesn't > address the issue that while maybe you want a line count I may want a > character > count or a count of all lines that begin with the letter A. Limiting this > example > to just line numbers ignores the fact that different people might want > different > information that can't all be predicted in advance and built into every > program. > This I think illustrates an important point: Unix conventions worked well enough in practice that many interesting tasks were not just tractable, but easy and in some cases trivial. Combining programs was easy via pipelines. Harder stuff involving more elaborate data formats was possible, but, well, harder and required more involved programming. By contrast, the Lisp machine could do the hard stuff, but the simple stuff also required non-trivial programming. The SQL database point was similarly interesting: having written programs to talk to relational databases, yes, one can do powerful things: but the amount of programming required is significant at a minimum and often substantial. > It also seems to me that the root problem here is that the data in the > original > example was in an emacs-specific format instead of the default UNIX text > file > format. > > The beauty of UNIX is that with a common file format one can create tools > that > process data in different ways that then operate on all data. Yes, it's > not as > efficient as creating a custom tool for a particular purpose, but is much > better > for casual use. One can always create a special purpose tool if a > particular > use becomes so prevalent that the extra efficiency is worthwhile. If > you're not > familiar with it, find a copy of the Communications of the ACM issue where > Knuth > presented a clever search algorithm (if I remember correctly) and McIlroy > did a > critique. One of the things that Doug pointed out what that while Don's > code was > more efficient, by creating a new pile of special-purpose code he > introduced bugs. > The flip side is that one often loses information in the conversion to text: yes, there are structured data formats with text serializations that can preserve the lost information, but consuming and processing those with the standard Unix tools can be messy. Seemingly trivial changes in text, like reversing the order of two fields, can break programs that consume that data. Data must be suitable for pipelining (e.g., perhaps free-form text must be free of newlines or something). These are all limitations. Where I think the argument went awry is in not recognizing that very often those problems, while real, are at least tractable. Many people have claimed, incorrectly in my opinion, that this model fails > in the > modern era because it only works on text data. They change the subject > when I > point out that ImageMagick works on binary data. And, there are now stream > processing utilities for JSON data and such that show that the UNIX model > still > works IF you understand it and know how to use it. > Certainly. I think you hit the nail on the head with the proviso that one must _understand_ the Unix model and how to use it. If one does so, it's very powerful indeed, and it really is applicable more often than not. But it is not a panacea (not that anyone suggested it is). As an example, how do I apply an unmodified `grep` to arbitrary JSON data (which may span more than one line)? Perhaps there is a way (I can imagine a 'record2line' program that consumes a single JSON object and emits it as a syntactically valid one-liner...) but I can also imagine all sorts of ways that might go wrong. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Jan 14 10:31:53 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 13 Jan 2020 19:31:53 -0500 Subject: [TUHS] History of symbol preemption In-Reply-To: References: Message-ID: On Mon, Jan 13, 2020 at 5:54 PM Henry Bent wrote: > Wasn't OSF's original intent to use the OSF/ROSE object format? > Yes and when I said OSF/1 I meant the version from OSF itself which was on the 386, MIPS and an Encore box -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Tue Jan 14 11:58:08 2020 From: rich.salz at gmail.com (Richard Salz) Date: Mon, 13 Jan 2020 20:58:08 -0500 Subject: [TUHS] OK, keep going on type checking In-Reply-To: References: <20200113021303.GA7633@minnie.tuhs.org> Message-ID: A custom struct conveys information to those applications that have the struct compiled-in (assuming C). A string version of the same struct data also works for those applications that would know the struct, but is also useful to a whole bunch of other tools. Yeah, there's round-off errors for floating point numbers I suppose, but the trade-off seems like infinite to approximately zero, no? -------------- next part -------------- An HTML attachment was scrubbed... URL: From gingell at computer.org Tue Jan 14 12:53:33 2020 From: gingell at computer.org (Rob Gingell) Date: Mon, 13 Jan 2020 18:53:33 -0800 Subject: [TUHS] History of symbol preemption In-Reply-To: References: Message-ID: <5e9784ef-155a-6982-50dc-73a863b13028@computer.org> On 1/13/2020 11:58 AM, Paul Winalski wrote: > When was symbol preemption when loading shared objects first > implemented in Unix? Are there versions of Unix that don't do symbol > preemption? The behavior described was in dynamic linking as introduced in SunOS 4.0. There had been a couple of earlier shared library implementations, notably System V Shared Libraries but I couldn't speak to whether any of them had the behavior. The reason the behavior is present is to (try to) preserve the behavior of an "ld" command line with respect to how the order of library specification impacted which definition of a given symbol was used to resolve references to it. With archive libraries the ordering could be used to effect interposition in sometimes obscure and questionable ways especially when archives were unordered. With shared objects, given that the whole object is always present, the usual intent of the ordering of libraries with respect to interposition is preserved by having the first definition be used to resolve all references. (And the reason "ld"'s behavior was relevant is that the idea was to make link editing an ongoing process as code assembled rather than a one time thing. So yes the run-time link-editor does it but that's because it's conceptually the functionality of the static link-editor continuing its work to knit together the still-assembling program.) The evolution of link editors in Solaris eventually resulted in the ability to effect more granular scoping and binding operations, including shared objects whose references to internal symbols could not be interposed upon and thus perhaps reflected the behavior of other systems mentioned in the original question. But the interposition / preemption behavior was the one which, at the time dynamic linking was introduced, best satisfied the "Principle of Least Surprise". On 1/13/2020 12:46 PM, Rico Pajarola wrote: > I believe a good proxy for > finding anything that inherited from or was inspired by this is a linker > that recognizes LD_PRELOAD. On 1/13/2020 2:20 PM, Larry McVoy wrote: > You could, and people did, make a shared lib that overloaded > the default gethostbyname(3) that wanted to do YP, the lib would provide > a DNS based one instead. Handling interposition in this way turned it into an explicit feature. Once multiple definitions for a symbol could exist in a program (or, definitions not yet referenced), devices to permit the navigation of the interposition like LD_PRELOAD, or the Name Service Switch, or Pluggable Authentication Modules became things that could be built around the functionality. On 1/13/2020 1:04 PM, Clem Cole wrote: > @ Rico I'm failing sure ELF came from AT&T Summit, not Sun. Yes, SunOS 4.0 rode the a.out object file format. ELF originated at Summit and as others have noted was a vast improvement. From lars at nocrew.org Tue Jan 14 18:54:45 2020 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 14 Jan 2020 08:54:45 +0000 Subject: [TUHS] Spacewar at Bell Labs Message-ID: <7wmuaqju3u.fsf@junk.nocrew.org> Hello, https://www.bell-labs.com/usr/dmr/www/spacetravel.html says: > Later we fixed Space Travel so it would run under (PDP-7) Unix instead > of standalone, and did also a very faithful copy of the Spacewar game I have a file with ".TITLE PDP-9/GRAPHIC II VERSION OF SPACEWAR". (I hope it will go public soon.) It seems to be a standalone program, and it's written in something close to MACRO-9 syntax. I'm guessing the Bell Labs version would have been written using the Unix assembler. Best regards, Lars Brinkhoff From jon at fourwinds.com Wed Jan 15 02:59:11 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Tue, 14 Jan 2020 08:59:11 -0800 Subject: [TUHS] Spacewar at Bell Labs In-Reply-To: <7wmuaqju3u.fsf@junk.nocrew.org> References: <7wmuaqju3u.fsf@junk.nocrew.org> Message-ID: <202001141659.00EGxBTs1036759@darkstar.fourwinds.com> Lars Brinkhoff writes: > Hello, > > https://www.bell-labs.com/usr/dmr/www/spacetravel.html says: > > > Later we fixed Space Travel so it would run under (PDP-7) Unix instead > > of standalone, and did also a very faithful copy of the Spacewar game > > I have a file with ".TITLE PDP-9/GRAPHIC II VERSION OF SPACEWAR". (I > hope it will go public soon.) It seems to be a standalone program, and > it's written in something close to MACRO-9 syntax. I'm guessing the > Bell Labs version would have been written using the Unix assembler. > > Best regards, > Lars Brinkhoff I have a copy of double-sun space war (sorry, just the binary) for the PDP-15/GRIN-2 on DEC fan-fold paper tape with the boot loader written in octal on the leader. Not sure if it's of any use but it's a nice historical artifact from the BTL explorer scout days. Jon From lars at nocrew.org Wed Jan 15 03:15:06 2020 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 14 Jan 2020 17:15:06 +0000 Subject: [TUHS] Spacewar at Bell Labs In-Reply-To: <202001141659.00EGxBTs1036759@darkstar.fourwinds.com> (Jon Steinhart's message of "Tue, 14 Jan 2020 08:59:11 -0800") References: <7wmuaqju3u.fsf@junk.nocrew.org> <202001141659.00EGxBTs1036759@darkstar.fourwinds.com> Message-ID: <7wsgkihsdh.fsf@junk.nocrew.org> Jon Steinhart wrote: > I have a copy of double-sun space war (sorry, just the binary) for the > PDP-15/GRIN-2 on DEC fan-fold paper tape with the boot loader written > in octal on the leader. Not sure if it's of any use I'm very interested in this! Is the paper tape readable somehow? From jon at fourwinds.com Wed Jan 15 03:19:17 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Tue, 14 Jan 2020 09:19:17 -0800 Subject: [TUHS] Spacewar at Bell Labs In-Reply-To: <7wsgkihsdh.fsf@junk.nocrew.org> References: <7wmuaqju3u.fsf@junk.nocrew.org> <202001141659.00EGxBTs1036759@darkstar.fourwinds.com> <7wsgkihsdh.fsf@junk.nocrew.org> Message-ID: <202001141719.00EHJHsQ1040700@darkstar.fourwinds.com> Lars Brinkhoff writes: > Jon Steinhart wrote: > > I have a copy of double-sun space war (sorry, just the binary) for the > > PDP-15/GRIN-2 on DEC fan-fold paper tape with the boot loader written > > in octal on the leader. Not sure if it's of any use > > I'm very interested in this! Is the paper tape readable somehow? Now that's an interesting question. Being paper tape, it's from the days in which you could see a bit with the naked eye. Another industrial artifact that I have somewhere is a paper tape reader, but it would take time away from skiing to get it working. Does anybody know if the Computer History Museum or equivalent has a DEC paper tape reader that works? I could probably lay it out on a scanner but that would be tedious. Might actually be best, it's over 45 years old and probably fragile. From clemc at ccc.com Wed Jan 15 03:25:44 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 14 Jan 2020 12:25:44 -0500 Subject: [TUHS] Spacewar at Bell Labs In-Reply-To: <7wsgkihsdh.fsf@junk.nocrew.org> References: <7wmuaqju3u.fsf@junk.nocrew.org> <202001141659.00EGxBTs1036759@darkstar.fourwinds.com> <7wsgkihsdh.fsf@junk.nocrew.org> Message-ID: I built a paper tape reader at one point, lord knows were it is. It's pretty easy -- Two pieces of wood to hold the paper with a mm or 2 shaved off the bottom of one of them the width of the paper tape. Then 9 parallel holes and put optical transistors connected to a 5 volt supply via a series resistor, running into a parallel port the 4th one is used as a strobe to pick of the 8 data bits and small light bulb on the other piece of wood. You then just pull it through and its self strobing. Set up a cat < /dev/parallel > /tmp/foo Your basically done, you'll need to pick reasonable values for the resistors to that match your transistors to switch on/off if the light passed through the hole. I've forgotten what I used, it something I had in the parts box. On Tue, Jan 14, 2020 at 12:16 PM Lars Brinkhoff wrote: > Jon Steinhart wrote: > > I have a copy of double-sun space war (sorry, just the binary) for the > > PDP-15/GRIN-2 on DEC fan-fold paper tape with the boot loader written > > in octal on the leader. Not sure if it's of any use > > I'm very interested in this! Is the paper tape readable somehow? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Wed Jan 15 03:26:41 2020 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 14 Jan 2020 17:26:41 +0000 Subject: [TUHS] Spacewar at Bell Labs In-Reply-To: <202001141719.00EHJHsQ1040700@darkstar.fourwinds.com> (Jon Steinhart's message of "Tue, 14 Jan 2020 09:19:17 -0800") References: <7wmuaqju3u.fsf@junk.nocrew.org> <202001141659.00EGxBTs1036759@darkstar.fourwinds.com> <7wsgkihsdh.fsf@junk.nocrew.org> <202001141719.00EHJHsQ1040700@darkstar.fourwinds.com> Message-ID: <7wk15uhru6.fsf@junk.nocrew.org> Jon Steinhart wrote: >> Is the paper tape readable somehow? > Does anybody know if the Computer History Museum or equivalent has a > DEC paper tape reader that works? I'm almost certain they do. If you can get it to them, that's probably the best option. To people closer to Seattle I would recommend Living Computers Museum. > I could probably lay it out on a scanner but that would be tedious. > Might actually be best, it's over 45 years old and probably fragile. Having recently read some Whirwind paper tapes, I'm sure the CHM people know how to handle old tapes. Paper or otherwise. From sauer at technologists.com Wed Jan 15 05:21:34 2020 From: sauer at technologists.com (Charles H Sauer) Date: Tue, 14 Jan 2020 13:21:34 -0600 Subject: [TUHS] two AIX items [was Re: History of symbol preemption In-Reply-To: References: Message-ID: On 1/13/2020 1:58 PM, Paul Winalski wrote: > ... LInux, AIX and probably other implementations of ELF have a > feature in the runtime loader called symbol preemption. When loading As far as I know, AIX has never used ELF. On the RT, AIX 1 & 2 used a.out enhanced for basic shared library support, designed by Larry Loucks with help from ISC, probably John Levine, if I recall correctly. Starting with AIX 3, AIX used an extended COFF. See Auslander et al, "Dynamic Linking and Loading in the AIX System", SA23-2619 RISC System/6000 Technology p. 151. (I don't have/know of PDF of SA23-2619.) See, also, https://en.wikipedia.org/wiki/XCOFF. It seems likely that AIX XCOFF supported symbol preemption, I haven't tried to determine one way or the other. AIX on 386 & 370 probably used a.out. Clem probably knows. An IBM retirees group on Facebook led me to IBM AIX Enhancements and Modernization at http://www.redbooks.ibm.com/abstracts/sg248453.html, just available yesterday. I tend to think of AIX as abandoned by IBM in favor of Linux, but, of course, that isn't really true. I've downloaded the PDF, but not looked inside. Charlie -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Skype/Twitter: CharlesHSauer From clemc at ccc.com Wed Jan 15 06:31:12 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 14 Jan 2020 15:31:12 -0500 Subject: [TUHS] two AIX items [was Re: History of symbol preemption In-Reply-To: References: Message-ID: On Tue, Jan 14, 2020 at 2:29 PM Charles H Sauer wrote: > AIX on 386 & 370 probably used a.out. Clem probably knows. > I don't remember for sure, but I think that's right. It might have used COFF, given the time frame but I don't think so since it was originally targetted for University/Research sites which were a.out oriented. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.bowling at kev009.com Wed Jan 15 09:17:46 2020 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Tue, 14 Jan 2020 16:17:46 -0700 Subject: [TUHS] Tech Sq elevator (Was: screen editors) [ really I think efficiency now ] In-Reply-To: References: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU> <202001122034.00CKYQ39571239@darkstar.fourwinds.com> <202001122044.00CKiUNV573279@darkstar.fourwinds.com> <202001122137.00CLbMrw582813@darkstar.fourwinds.com> Message-ID: Thanks Dan, this message is exactly what I was trying to express. To piggyback on some of your idea, one limitation on getting at the representation is the simplicity of the shell. If you look back at The Mother of All Demos, or environments like the LispM, Project Oberon, Alto, even the BLIT it seems to me like there may be ways to harmonize the underlying representation with ({use?, implementation?, mental model?} What is it that makes the unix shell and pipelines so desirable and unchanged? One thing I notice is that as my millenial peers learn, adopt, and use unix as software or doctrine, it is a fixture. It seems like older generations have some of this as well but we can make computers do whatever we want; there are no rules only conventions. I'm not trying to convince anyone of anything, there is mounting science that we basically never change our minds on anything. The conversation was useful for solidifying my own views and maybe making people who have done this for a long time to express their views on the basics for shared consideration. Regards, Kevin On Mon, Jan 13, 2020 at 4:48 PM Dan Cross wrote: > > [Resending as this got squashed a few days ago. Jon, sorry for the duplicate. Again.] > > On Sun, Jan 12, 2020 at 4:38 PM Jon Steinhart wrote: >> >> [snip] >> So I think that the point that you're trying to make, correct me if I'm wrong, >> is that if lists just knew how long they were you could just ask and that it >> would be more efficient. > > > What I understood was that, by translating into a lowest-common-denominator format like text, one loses much of the semantic information implicit in a richer representation. In particular, much of the internal knowledge (like type information...) is lost during translation and presentation. Put another way, with text as usually used by the standard suite of Unix tools, type information is implicit, rather than explicit. I took this to be less an issue of efficiency and more of expressiveness. > > It is, perhaps, important to remember that Unix works so well because of heavy use of convention: to take Doug's example, the total number of commands might be easy to find with `wc` because one assumes each command is presented on a separate line, with no gaudy header or footer information or extraneous explanatory text. > > This sort of convention, where each logical "record" is a line by itself, is pervasive on Unix systems, but is not guaranteed. In some sense, those representations are fragile: a change in output might break something else downstream in the pipeline, whereas a representation that captures more semantic meaning is more robust in the face of change but, as in Doug's example, often harder to use. The Lisp Machine had all sorts of cool information in the image and a good Lisp hacker familiar with the machine's structures could write programs to extract and present that information. But doing so wasn't trivial in the way that '| wc -l' in response to a casual query is. > >> While that may be true, it sort of assume that this is something so common that >> the extra overhead for line counting should be part of every list. And it doesn't >> address the issue that while maybe you want a line count I may want a character >> count or a count of all lines that begin with the letter A. Limiting this example >> to just line numbers ignores the fact that different people might want different >> information that can't all be predicted in advance and built into every program. > > > This I think illustrates an important point: Unix conventions worked well enough in practice that many interesting tasks were not just tractable, but easy and in some cases trivial. Combining programs was easy via pipelines. Harder stuff involving more elaborate data formats was possible, but, well, harder and required more involved programming. By contrast, the Lisp machine could do the hard stuff, but the simple stuff also required non-trivial programming. > > The SQL database point was similarly interesting: having written programs to talk to relational databases, yes, one can do powerful things: but the amount of programming required is significant at a minimum and often substantial. > >> >> It also seems to me that the root problem here is that the data in the original >> example was in an emacs-specific format instead of the default UNIX text file >> format. >> >> The beauty of UNIX is that with a common file format one can create tools that >> process data in different ways that then operate on all data. Yes, it's not as >> efficient as creating a custom tool for a particular purpose, but is much better >> for casual use. One can always create a special purpose tool if a particular >> use becomes so prevalent that the extra efficiency is worthwhile. If you're not >> familiar with it, find a copy of the Communications of the ACM issue where Knuth >> presented a clever search algorithm (if I remember correctly) and McIlroy did a >> critique. One of the things that Doug pointed out what that while Don's code was >> more efficient, by creating a new pile of special-purpose code he introduced bugs. > > > The flip side is that one often loses information in the conversion to text: yes, there are structured data formats with text serializations that can preserve the lost information, but consuming and processing those with the standard Unix tools can be messy. Seemingly trivial changes in text, like reversing the order of two fields, can break programs that consume that data. Data must be suitable for pipelining (e.g., perhaps free-form text must be free of newlines or something). These are all limitations. Where I think the argument went awry is in not recognizing that very often those problems, while real, are at least tractable. > >> Many people have claimed, incorrectly in my opinion, that this model fails in the >> modern era because it only works on text data. They change the subject when I >> point out that ImageMagick works on binary data. And, there are now stream >> processing utilities for JSON data and such that show that the UNIX model still >> works IF you understand it and know how to use it. > > > Certainly. I think you hit the nail on the head with the proviso that one must _understand_ the Unix model and how to use it. If one does so, it's very powerful indeed, and it really is applicable more often than not. But it is not a panacea (not that anyone suggested it is). As an example, how do I apply an unmodified `grep` to arbitrary JSON data (which may span more than one line)? Perhaps there is a way (I can imagine a 'record2line' program that consumes a single JSON object and emits it as a syntactically valid one-liner...) but I can also imagine all sorts of ways that might go wrong. > > - Dan C. > From kevin.bowling at kev009.com Wed Jan 15 09:22:38 2020 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Tue, 14 Jan 2020 16:22:38 -0700 Subject: [TUHS] two AIX items [was Re: History of symbol preemption In-Reply-To: References: Message-ID: I've got a bunch of paper AIX internals documentation outside the usual, most interesting from memory is one describing the 4.1 work where it gained SMP support, pthreads, and a bunch of other things. I need to get some kind of scanning setup if you are interested. On Tue, Jan 14, 2020 at 12:29 PM Charles H Sauer wrote: > > > > On 1/13/2020 1:58 PM, Paul Winalski wrote: > > > ... LInux, AIX and probably other implementations of ELF have a > > feature in the runtime loader called symbol preemption. When loading > > As far as I know, AIX has never used ELF. > > On the RT, AIX 1 & 2 used a.out enhanced for basic shared library > support, designed by Larry Loucks with help from ISC, probably John > Levine, if I recall correctly. > > Starting with AIX 3, AIX used an extended COFF. See Auslander et al, > "Dynamic Linking and Loading in the AIX System", SA23-2619 RISC > System/6000 Technology p. 151. (I don't have/know of PDF of SA23-2619.) > See, also, https://en.wikipedia.org/wiki/XCOFF. > > It seems likely that AIX XCOFF supported symbol preemption, I haven't > tried to determine one way or the other. > > AIX on 386 & 370 probably used a.out. Clem probably knows. > > An IBM retirees group on Facebook led me to IBM AIX Enhancements and > Modernization at http://www.redbooks.ibm.com/abstracts/sg248453.html, > just available yesterday. I tend to think of AIX as abandoned by IBM in > favor of Linux, but, of course, that isn't really true. I've downloaded > the PDF, but not looked inside. > > Charlie > > -- > voice: +1.512.784.7526 e-mail: sauer at technologists.com > fax: +1.512.346.5240 Web: https://technologists.com/sauer/ > Facebook/Google/Skype/Twitter: CharlesHSauer From tuhs at cuzuco.com Wed Jan 15 13:32:45 2020 From: tuhs at cuzuco.com (Brian Walden) Date: Tue, 14 Jan 2020 22:32:45 -0500 (EST) Subject: [TUHS] Spacewar at Bell Labs Message-ID: <202001150332.00F3WjAQ013229@cuzuco.com> > Papertape reader? The last Cyphercon had a paper tape reader in their badge -- https://hackaday.com/2019/04/12/cyphercon-badge-has-a-paper-tape-reader-built-in/ You can proably buy one from the con https://cyphercon.com/, or the makers http://www.tymkrs.com/ or ebay... -Brian From jon at fourwinds.com Wed Jan 15 14:01:11 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Tue, 14 Jan 2020 20:01:11 -0800 Subject: [TUHS] Spacewar at Bell Labs In-Reply-To: <202001150332.00F3WjAQ013229@cuzuco.com> References: <202001150332.00F3WjAQ013229@cuzuco.com> Message-ID: <202001150401.00F41Bpj1685249@darkstar.fourwinds.com> Brian Walden writes: > > Papertape reader? > > The last Cyphercon had a paper tape reader in their badge -- > > https://hackaday.com/2019/04/12/cyphercon-badge-has-a-paper-tape-reader-built-in/ > > You can proably buy one from the con https://cyphercon.com/, or the makers > http://www.tymkrs.com/ or ebay... > > -Brian That's cool, but I'm worried about the fragility of the tape after all this time. Maybe because I got my start in the early networking era when I had to transfer files from one machine to another by feeding the paper tape from the punch in one ASR-33 into the reader of another :-) From bakul at bitblocks.com Wed Jan 15 14:50:33 2020 From: bakul at bitblocks.com (Bakul Shah) Date: Tue, 14 Jan 2020 20:50:33 -0800 Subject: [TUHS] Spacewar at Bell Labs In-Reply-To: Your message of "Tue, 14 Jan 2020 20:01:11 -0800." <202001150401.00F41Bpj1685249@darkstar.fourwinds.com> References: <202001150332.00F3WjAQ013229@cuzuco.com> <202001150401.00F41Bpj1685249@darkstar.fourwinds.com> Message-ID: <20200115045040.A6BA0156E42D@mail.bitblocks.com> On Tue, 14 Jan 2020 20:01:11 -0800 Jon Steinhart wrote: > > That's cool, but I'm worried about the fragility of the tape after all this > time. I thought paper tape lasted much longer that magtapes.... From tuhs at cuzuco.com Wed Jan 15 14:54:15 2020 From: tuhs at cuzuco.com (Brian Walden) Date: Tue, 14 Jan 2020 23:54:15 -0500 (EST) Subject: [TUHS] A portrait of cut(1) Message-ID: <202001150454.00F4sF9H013965@cuzuco.com> Random832 writes: >markus schnalke writes: >> [2015-11-09 08:58] Doug McIlroy >>> things like "cut" and "paste", whose exact provenance >>> I can't recall. >> >> Thanks for reminding me that I wanted to share my portrait of >> cut(1) with you. (I sent some questions to this list, a few >> months ago, remember?) Now, here it is: >> >> http://marmaro.de/docs/freiesmagazin/cut/cut.en.pdf > >Did you happen to find out what GWRL stands for, in the the comments at >the top of early versions of cut.c and paste.c? > >/* cut : cut and paste columns of a table (projection of a relation) (GWRL) */ >/* Release 1.5; handles single backspaces as produced by nroff */ >/* paste: concatenate corresponding lines of each file in parallel. Release 1.4 (GWRL) */ >/* (-s option: serial concatenation like old (127's) paste command */ > >For that matter, what's the "old (127's) paste command" it refers to? I know this thread is almost 5 years old, I came across it searching for something else But as no one could answer these questions back then, I can. GWRL stands for Gottfried W. R. Luderer, the author of cut(1) and paste(1), probably around 1978. Those came either from PWB or USG, as he worked with, or for, Berkley Tague. Thus they made their way into AT&T commercial UNIX, first into System III and the into System V, and that's why they are missing from early BSD releases as they didn't get into Research UNIX until the 8th Edition. Also "127" was the internal department number for the Computer Science Research group at Bell Labs where UNIX originated Dr. Luderer co-authored this paper in the orginal 1978 BSTJ on UNIX -- https://www.tuhs.org/Archive/Documentation/Papers/BSTJ/bstj57-6-2201.pdf I knew Dr. Luderer and he was even kind enough to arrange for me stay with his relatives for a few days in Braunschweig, West Germany (correct county name for the time) on my first trip to Europe many decades ago. But haven't had contact nor even thought of him forever until I saw his initials. I also briefly worked for Berk when he was the department head for 45263 in Whippany Bell Labs before moving to Murray Hill. And doing a quick search for him, it looks like he wrote and autobiograhy, which I am now going to have to purchase http://www.lulu.com/shop/gottfried-luderer/go-west-young-german/paperback/product-23385772.html?ppn=1 -Brian From fair-tuhs at netbsd.org Wed Jan 15 15:42:55 2020 From: fair-tuhs at netbsd.org (Erik E. Fair) Date: Tue, 14 Jan 2020 21:42:55 -0800 Subject: [TUHS] Looking for Maitre'd tarball In-Reply-To: <087068da-86b5-c886-2273-81538a731a41@embarqmail.com> Message-ID: <16250.1579066975@cesium.clock.org> Are you sure you don't mean Brian Bershad? https://homes.cs.washington.edu/~bershad/CV/cv.htm Erik From lars at nocrew.org Wed Jan 15 16:17:26 2020 From: lars at nocrew.org (Lars Brinkhoff) Date: Wed, 15 Jan 2020 06:17:26 +0000 Subject: [TUHS] Spacewar at Bell Labs In-Reply-To: <202001150332.00F3WjAQ013229@cuzuco.com> (Brian Walden's message of "Tue, 14 Jan 2020 22:32:45 -0500 (EST)") References: <202001150332.00F3WjAQ013229@cuzuco.com> Message-ID: <7wsgkhgs5l.fsf@junk.nocrew.org> Brian Walden wrote: >> Papertape reader? > The last Cyphercon had a paper tape reader in their badge -- > https://hackaday.com/2019/04/12/cyphercon-badge-has-a-paper-tape-reader-built-in/ I'd be all over this if there also were a way to punch tapes. From earl.baugh at gmail.com Wed Jan 15 16:34:29 2020 From: earl.baugh at gmail.com (Earl Baugh) Date: Wed, 15 Jan 2020 01:34:29 -0500 Subject: [TUHS] Spacewar at Bell Labs In-Reply-To: <7wsgkhgs5l.fsf@junk.nocrew.org> References: <7wsgkhgs5l.fsf@junk.nocrew.org> Message-ID: Why not build a variation of this with an Arduino? https://www.instructables.com/id/DIY-Paper-TapePunch-Card-Maker-and-Reader/. You could use cardboard rather than wood if it’s just a one time job. ( or scan the tape into files and process digitally ?) Earl Sent from my iPhone > On Jan 15, 2020, at 1:18 AM, Lars Brinkhoff wrote: > > Brian Walden wrote: >>> Papertape reader? >> The last Cyphercon had a paper tape reader in their badge -- >> https://hackaday.com/2019/04/12/cyphercon-badge-has-a-paper-tape-reader-built-in/ > > I'd be all over this if there also were a way to punch tapes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Wed Jan 15 17:10:53 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Tue, 14 Jan 2020 23:10:53 -0800 Subject: [TUHS] Spacewar at Bell Labs [ really paper tape readers and tangentially related things ] In-Reply-To: References: <7wsgkhgs5l.fsf@junk.nocrew.org> Message-ID: <202001150710.00F7AsFQ1716609@darkstar.fourwinds.com> Earl Baugh writes: > Why not build a variation of this with an Arduino? > https://www.instructables.com/id/DIY-Paper-TapePunch-Card-Maker-and-Reader/. > You could use cardboard rather than wood if it’s just a one time job. ( or scan > the tape into files and process digitally ?) > > Earl I thought that I said earlier that I had a paper tape reader here but don't remember much about it or if it ever worked. If I didn't have a huge project list and it wasn't ski season I could hook it up to a pi. More likely that I'll get to a computer museum sooner. Just to keep this UNIX-related so that Warren doesn't get cranky, I believe that this reader came out of some sort of experimental telephone exchange in our group that was decommissioned. Dave Weller was very supportive of my interests and somehow arranged for me to take much of it home as surplus equipment. Kept me in 7400-series parts and Augat wire-wrap boards for a long time. While there was no way that I could have kept the thing, I wish that I had the magnetic drum memory because it was so cool from an industrial art perspective. Heinz may remember more about this than I do because he actually worked on this project, but our department developed what I believe was the first all-digital telephone exchange that used digital filtering (Hal Alles and Jim Kaiser were in the group). I think that it had a pair of PDP-11/10s in it, and a bigger PDP-11 as a supervisory machine that ran UNIX. I have vague memories of Heinz and Carl poring over huge C program listings. I also remember that there was a bug in the long-distance code where it wasn't sending out the ST tone that ended up taking all of the key pulse senders in the Berkeley Heights telephone exchange that provided the trunk line to our lab off line as they didn't have timeouts and needed to be manually reset. But hey, we were the phone company too so what could they do about it? Oh, I think that the PDP-11/10s were used because we tried to use LSI-11s but those turned out to be useless because of the way that DEC did the DRAM refresh; it wasn't interleaved, they just stopped everything every so many ms and refreshed everything. Non-starter for real-time systems. And another thought, this machine may have been why Heinz wrote MERT. I was gone before this system was completed so I have no idea how it fared and how many of the ideas were incorporated into production systems. Oh, yeah, I think that it was called the SS1 for Slave Switch 1. Jon From rly1 at embarqmail.com Wed Jan 15 17:38:30 2020 From: rly1 at embarqmail.com (Ron Young) Date: Tue, 14 Jan 2020 23:38:30 -0800 Subject: [TUHS] Looking for Maitre'd tarball In-Reply-To: <16250.1579066975@cesium.clock.org> References: <16250.1579066975@cesium.clock.org> Message-ID: On January 14, 2020 9:42:55 PM PST, "Erik E. Fair" wrote: >Are you sure you don't mean Brian Bershad? > >https://homes.cs.washington.edu/~bershad/CV/cv.htm > > Erik Thanks for this.... Gives me more research materials to try and track. Still no joy on a tarball however -ron -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From meillo at marmaro.de Wed Jan 15 18:02:15 2020 From: meillo at marmaro.de (markus schnalke) Date: Wed, 15 Jan 2020 09:02:15 +0100 Subject: [TUHS] A portrait of cut(1) In-Reply-To: <202001150454.00F4sF9H013965@cuzuco.com> References: <202001150454.00F4sF9H013965@cuzuco.com> Message-ID: <1irdd1-81R-00@marmaro.de> Hoi, thanks a lot for sharing these yet missing pieces of information and the stories. Very interesting. meillo [2020-01-14 23:54] Brian Walden > Random832 writes: > >markus schnalke writes: > >> [2015-11-09 08:58] Doug McIlroy > >>> things like "cut" and "paste", whose exact provenance > >>> I can't recall. > >> > >> Thanks for reminding me that I wanted to share my portrait of > >> cut(1) with you. (I sent some questions to this list, a few > >> months ago, remember?) Now, here it is: > >> > >> http://marmaro.de/docs/freiesmagazin/cut/cut.en.pdf > > > >Did you happen to find out what GWRL stands for, in the the comments at > >the top of early versions of cut.c and paste.c? > > > >/* cut : cut and paste columns of a table (projection of a relation) (GWRL) */ > >/* Release 1.5; handles single backspaces as produced by nroff */ > >/* paste: concatenate corresponding lines of each file in parallel. Release 1.4 (GWRL) */ > >/* (-s option: serial concatenation like old (127's) paste command */ > > > >For that matter, what's the "old (127's) paste command" it refers to? > > I know this thread is almost 5 years old, I came across it searching for > something else But as no one could answer these questions back then, I can. > > GWRL stands for Gottfried W. R. Luderer, the author of cut(1) and paste(1), > probably around 1978. Those came either from PWB or USG, as he worked with, > or for, Berkley Tague. Thus they made their way into AT&T commercial UNIX, > first into System III and the into System V, and that's why they are missing > from early BSD releases as they didn't get into Research UNIX until the > 8th Edition. Also "127" was the internal department number for the Computer > Science Research group at Bell Labs where UNIX originated > > Dr. Luderer co-authored this paper in the orginal 1978 BSTJ on UNIX -- > https://www.tuhs.org/Archive/Documentation/Papers/BSTJ/bstj57-6-2201.pdf > > I knew Dr. Luderer and he was even kind enough to arrange for me stay with his > relatives for a few days in Braunschweig, West Germany (correct county name for > the time) on my first trip to Europe many decades ago. But haven't had contact nor > even thought of him forever until I saw his initials. I also briefly worked for Berk > when he was the department head for 45263 in Whippany Bell Labs before moving to > Murray Hill. > > And doing a quick search for him, it looks like he wrote and autobiograhy, which I > am now going to have to purchase > http://www.lulu.com/shop/gottfried-luderer/go-west-young-german/paperback/product-23385772.html?ppn=1 > > -Brian > From earl.baugh at gmail.com Wed Jan 15 18:05:16 2020 From: earl.baugh at gmail.com (Earl Baugh) Date: Wed, 15 Jan 2020 03:05:16 -0500 Subject: [TUHS] Spacewar at Bell Labs [ really paper tape readers and tangentially related things ] In-Reply-To: <202001150710.00F7AsFQ1716609@darkstar.fourwinds.com> References: <202001150710.00F7AsFQ1716609@darkstar.fourwinds.com> Message-ID: I thought the concern was about the fragility of the tape and the concern about running it thru a period reader. I was just thinking these two options would be safer on the tape. That’s why I was suggesting them. Just trying to be helpful .. all to familiar with the long project list :-) Earl Sent from my iPhone > On Jan 15, 2020, at 2:12 AM, Jon Steinhart wrote: > > Earl Baugh writes: >> Why not build a variation of this with an Arduino? >> https://www.instructables.com/id/DIY-Paper-TapePunch-Card-Maker-and-Reader/. >> You could use cardboard rather than wood if it’s just a one time job. ( or scan >> the tape into files and process digitally ?) >> >> Earl > > I thought that I said earlier that I had a paper tape reader here but don't > remember much about it or if it ever worked. If I didn't have a huge project > list and it wasn't ski season I could hook it up to a pi. More likely that > I'll get to a computer museum sooner. > > Just to keep this UNIX-related so that Warren doesn't get cranky, I believe > that this reader came out of some sort of experimental telephone exchange > in our group that was decommissioned. Dave Weller was very supportive of my > interests and somehow arranged for me to take much of it home as surplus > equipment. Kept me in 7400-series parts and Augat wire-wrap boards for a > long time. While there was no way that I could have kept the thing, I wish > that I had the magnetic drum memory because it was so cool from an industrial > art perspective. > > Heinz may remember more about this than I do because he actually worked on > this project, but our department developed what I believe was the first > all-digital telephone exchange that used digital filtering (Hal Alles and > Jim Kaiser were in the group). I think that it had a pair of PDP-11/10s > in it, and a bigger PDP-11 as a supervisory machine that ran UNIX. I have > vague memories of Heinz and Carl poring over huge C program listings. I > also remember that there was a bug in the long-distance code where it wasn't > sending out the ST tone that ended up taking all of the key pulse senders in > the Berkeley Heights telephone exchange that provided the trunk line to our > lab off line as they didn't have timeouts and needed to be manually reset. > But hey, we were the phone company too so what could they do about it? > > Oh, I think that the PDP-11/10s were used because we tried to use LSI-11s > but those turned out to be useless because of the way that DEC did the DRAM > refresh; it wasn't interleaved, they just stopped everything every so many > ms and refreshed everything. Non-starter for real-time systems. > > And another thought, this machine may have been why Heinz wrote MERT. > > I was gone before this system was completed so I have no idea how it fared > and how many of the ideas were incorporated into production systems. Oh, > yeah, I think that it was called the SS1 for Slave Switch 1. > > Jon From jfoust at threedee.com Wed Jan 15 22:29:32 2020 From: jfoust at threedee.com (John Foust) Date: Wed, 15 Jan 2020 06:29:32 -0600 Subject: [TUHS] Spacewar at Bell Labs In-Reply-To: References: <7wsgkhgs5l.fsf@junk.nocrew.org> Message-ID: <20200115132428.EDF319B898@minnie.tuhs.org> At 12:34 AM 1/15/2020, Earl Baugh wrote: >Why not build a variation of this with an Arduino? > https://www.instructables.com/id/DIY-Paper-TapePunch-Card-Maker-and-Reader/. You could use cardboard rather than wood if it’s just a one time job. ( or scan the tape into files and process digitally ?) We're so close, I wish someone would figure out a way to let a contemporary office scanner like the Fujitsu ScanSnap to handle paper tapes. Reliable feed mechanism, nice scanner, just needs a little software and maybe a guide. And a way to re-spool the tape. Darn, just got complicated. Same thing for a new way to read a magtape. You'd think it could be done with a universal read head and some software. Nine years ago I visited http://www.comco-inc.com/ , perhaps one of the last sellers and refurbishers of 9-tracks. I dropped off three 9-tracks I didn't need. He seems to be surviving because oil survey companies still call and are willing to write five-figure checks for particular working hardware. - John From clemc at ccc.com Thu Jan 16 00:50:02 2020 From: clemc at ccc.com (Clem Cole) Date: Wed, 15 Jan 2020 09:50:02 -0500 Subject: [TUHS] Spacewar at Bell Labs [ really paper tape readers and tangentially related things ] In-Reply-To: <202001150710.00F7AsFQ1716609@darkstar.fourwinds.com> References: <7wsgkhgs5l.fsf@junk.nocrew.org> <202001150710.00F7AsFQ1716609@darkstar.fourwinds.com> Message-ID: On Wed, Jan 15, 2020 at 2:12 AM Jon Steinhart wrote: > we tried to use LSI-11s > but those turned out to be useless because of the way that DEC did the DRAM > refresh; it wasn't interleaved, they just stopped everything every so many > ms and refreshed everything. Non-starter for real-time systems. > Be careful as to who you denigrate, my friend. 😂 Very interesting history, IMO. Yes, DEC sold the LSI-11, but Western Digital designed it. DEC (KO specifically) had just put Ray Ball and Ken O'humundro's CalData out of business for cloning the PDP-11/45 with a Unibus on his Caldata 500 . At the time, WD had developed and started to sell to the systems manufacturers a new set of bit-slice chips the MCP-1600 , to compete with AMD's 2900 and Intel 3000 series (plus they were already a chip supplier to DEC for UARTS). So WD designs and builds a few LSI-11 as a sales demo of what you could do with their new bit-slice chip (*i.e. *as those things often go, the board, bus, and memory was a quick and cheap hack). It's important to note that the way DEC nailed CalData was the *same instruction set on the same bus*, WD did their own bus for their demo. Also, please remember that at the time, WD was in the chip business. KO's reaction this time was different. Instead of suing, DEC got the design and started to build and sell them. WD took the board design, wrote a new set of microcode based on the USCD Pascal-P machine , then sold that as a 'system' called the Pascal MicroEngine , but primarily used it is the sales demo. I remember seeing one of the WD Pascal-P systems once when we were at Tek (along with my favorite named workstation, the Modula based Lilith ). But I do not think the Pascal-P (nor Lilith) was very successful. Also, AMD ultimately won the bit-slice chip business, as most designers at manufacturers like DEC, Masscomp, FPS, *et al*. designed their new systems or at least the FP/AP coprocessors with the 2900 series. BTW: this is also why a few years later when Ken O'Humundro created another full computer board with a 68000 on it with his new Able Computer Corp, he put it on the QBUS which DEC could not lock up because they did not create it as WD had. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Thu Jan 16 02:41:06 2020 From: paul.winalski at gmail.com (Paul Winalski) Date: Wed, 15 Jan 2020 11:41:06 -0500 Subject: [TUHS] two AIX items [was Re: History of symbol preemption In-Reply-To: References: Message-ID: On 1/14/20, Charles H Sauer wrote: > > As far as I know, AIX has never used ELF. You're right. My mistake. -Paul W. From jnc at mercury.lcs.mit.edu Thu Jan 16 02:46:47 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 15 Jan 2020 11:46:47 -0500 (EST) Subject: [TUHS] Spacewar at Bell Labs [ really paper tape readers and tangentially related things ] Message-ID: <20200115164647.AA0D218C0A2@mercury.lcs.mit.edu> > From: Clem Cole > So WD designs and builds a few LSI-11 as a sales demo of what you could > do > ... > he put it on the QBUS which DEC could not lock up because they did not > create it as WD had. Wow! WD created the QBUS? Fascinating. I wonder if DEC made any changes to the QBUS between the original demo WD boards and the first DEC ones? Are there any documents about the WD original still extant, do you know? (FWIW, it seems that whoever did the QBUS interrupt cycle had heard about the metastability issues when using a flop to do the grant-passing arbitrations; see here for more: https://gunkies.org/wiki/Bus_Arbitration_on_the_Unibus_and_QBUS#QBUS_Interrupts DEC had previously bent themselves into knots trying to solve it on the UNIBUS: https://gunkies.org/wiki/M782_Interrupt_Control#Revisions so it would be interesting to know if it was WD or DEC who did the DIN thing to get rid of it on the QBUS.) Noel From clemc at ccc.com Thu Jan 16 04:35:48 2020 From: clemc at ccc.com (Clem Cole) Date: Wed, 15 Jan 2020 13:35:48 -0500 Subject: [TUHS] Spacewar at Bell Labs [ really paper tape readers and tangentially related things ] In-Reply-To: <20200115164647.AA0D218C0A2@mercury.lcs.mit.edu> References: <20200115164647.AA0D218C0A2@mercury.lcs.mit.edu> Message-ID: On Wed, Jan 15, 2020 at 11:47 AM Noel Chiappa wrote: > Wow! WD created the QBUS? Fascinating. I wonder if DEC made any changes to > the > QBUS between the original demo WD boards and the first DEC ones? I can not say I know and I would suspect they peed on it in some manner, that *was the DEC culture*. I've just sent a note to Mr. BI to see if he knows and I'll pass back anything I learn if I do. Sounds like the sort of thing they might have gotten changed before it was release. > Are there any documents about the WD original still extant, do you know? > I'm pretty sure we had some stuff from WD at CMU, because CM* was made out of a lot of them, and CMU did custom microcode so they could talk to the capabilities and K.map HW. I remember seeing some prints with WD markings on it, but I was not heavily involved other than working the new distributed front-end which we did with LSI-11s. Somebody from the CMU HW lab like Jim Teter might know, although he did the 11/40e for C.mmp, I'm not sure who was the microcode guru on CM* as that was all happening as I was leaving. I sent a couple of emails to folks like Danny Klein, Mike Liebensberger, and Tron McConnell. Danny and Mike are SW folks, Tron was a EE/HW type but mostly worked on other stuff at Mellon Institute in those days. But, IIRC, Tron was worked on a 3Mbit Xerox board for the LSIs, so he might have had something. We all did some stuff with CM* (Mike more than any of us). FWIW: Tron was (is) a bit of packrat and if he ever had anything like that, he might still have it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aek at bitsavers.org Thu Jan 16 09:32:10 2020 From: aek at bitsavers.org (Al Kossow) Date: Wed, 15 Jan 2020 15:32:10 -0800 Subject: [TUHS] Spacewar at Bell Labs In-Reply-To: <202001141719.00EHJHsQ1040700@darkstar.fourwinds.com> References: <7wmuaqju3u.fsf@junk.nocrew.org> <202001141659.00EGxBTs1036759@darkstar.fourwinds.com> <7wsgkihsdh.fsf@junk.nocrew.org> <202001141719.00EHJHsQ1040700@darkstar.fourwinds.com> Message-ID: On 1/14/20 9:19 AM, Jon Steinhart wrote: > Does anybody know if the > Computer History Museum or equivalent has a DEC paper tape reader that > works? It does in my lab at CHM Fremont. You near by? From aek at bitsavers.org Thu Jan 16 09:40:24 2020 From: aek at bitsavers.org (Al Kossow) Date: Wed, 15 Jan 2020 15:40:24 -0800 Subject: [TUHS] Spacewar at Bell Labs [ really paper tape readers and tangentially related things ] In-Reply-To: References: <7wsgkhgs5l.fsf@junk.nocrew.org> <202001150710.00F7AsFQ1716609@darkstar.fourwinds.com> Message-ID: <39a1b5b7-f256-a6fa-c1e4-4630689d9703@bitsavers.org> On 1/15/20 6:50 AM, Clem Cole wrote: > WD took the board design, wrote a > new set of microcode based on the USCD Pascal-P machine , then sold that as a > 'system' called the Pascal MicroEngine , but primarily used it is the > sales demo. And Volition Systems, took the P-System chip set and put it on the QBus, later put Modula-2 on it. From imp at bsdimp.com Thu Jan 16 10:17:00 2020 From: imp at bsdimp.com (Warner Losh) Date: Wed, 15 Jan 2020 17:17:00 -0700 Subject: [TUHS] MUNIX Sources Message-ID: Greetings, I've so far been unable to locate a copy of munix. This is John Hawley's dual PDP-11/50 version of Unix he wrote for his PHd Thesis in June 1975 at the Naval Postgraduate School in Monterey, CA. I don't suppose that any known copies of this exist? To date, my searches have turned up goose-eggs. Hawley's paper can be found here https://calhoun.nps.edu/handle/10945/20959 Warner P.S. I'm doing another early history talk at FOSDEM in a couple of weeks. So if you're in the audience, no spoilers please :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From aek at bitsavers.org Thu Jan 16 10:17:44 2020 From: aek at bitsavers.org (Al Kossow) Date: Wed, 15 Jan 2020 16:17:44 -0800 Subject: [TUHS] tape reading (was Re: Spacewar at Bell Labs) In-Reply-To: <20200115132428.EDF319B898@minnie.tuhs.org> References: <7wsgkhgs5l.fsf@junk.nocrew.org> <20200115132428.EDF319B898@minnie.tuhs.org> Message-ID: <8ba0abdf-fefe-5494-785f-c0bcd020bdc9@bitsavers.org> On 1/15/20 4:29 AM, John Foust wrote: > Same thing for a new way to read a magtape. You'd think it > could be done with a universal read head and some software. It's been done. You need a good transport that has enough torque to deal with sticky tapes and a digitizer with about 100gigs of ram if you're doing acquisition with a Saleae Logic16 USB3 analyzer. https://github.com/LenShustek/readtape The setup is a couple thousand dollars. From rdm at cfcl.com Thu Jan 16 14:27:07 2020 From: rdm at cfcl.com (Rich Morin) Date: Wed, 15 Jan 2020 20:27:07 -0800 Subject: [TUHS] free dead trees, to the best possible home Message-ID: <0C61A49E-2AEE-40EF-9472-298E528C064D@cfcl.com> TL; DR. I'm trying to find the best possible home for some dead trees. I have about a foot-high stack of manilla folders containing "early Unix papers". They have been boxed up for a few decades, but appear to be in perfect condition. I inherited this collection from Jim Joyce, who taught the first Unix course at UC Berkeley and went on to run a series of ventures in Unix-related bookselling, instruction, publishing, etc. The collection has been boxed up for a few decades, but appears to be in perfect condition. I don't think it has much financial value, but I suspect that some of the papers may have historical significance. Indeed, some of them may not be available in any other form, so they definitely should be scanned in and republished. I also have a variety of newer materials, including full sets of BSD manuals, SunExpert and Unix Review issues, along with a lot of books and course handouts and maybe a SUGtape or two. I'd like to donate these materials to an institution that will take care of them, make them available to interested parties, etc. Here are some suggested recipients: - The Computer History Museum (Mountain View, CA, USA) - The Internet Archive (San Francisco, CA, USA) - The Living Computers Museum (Seattle, WA, USA) - The UC Berkeley Library (Berkeley, CA, USA) - The Unix Heritage Association (Australia?) - The USENIX Association (Berkeley, CA, USA) According to Warren Toomey, TUHS probably isn't the best possibility. The Good News about most of the others is that I can get materials to them in the back of my car. However, I may be overlooking some better possibility, so I am following Warren's suggestion and asking here. I'm open to any suggestions that have a convincing rationale. Now, open for suggestions (ducks)... -r From rdm at cfcl.com Thu Jan 16 14:26:57 2020 From: rdm at cfcl.com (Rich Morin) Date: Wed, 15 Jan 2020 20:26:57 -0800 Subject: [TUHS] introduction and sales pitch... Message-ID: <633DAB15-0F13-425E-9600-1125308C9E6A@cfcl.com> I just found out about TUHS today; I plan to skim the archives RSN to get some context. Meanwhile, this note is a somewhat long-winded introduction, followed by a (non-monetary) sales pitch. I think some of the introduction may be interesting and/or relevant to the pitch, but YMMV... Introduction In 1970, I was introduced to programming by a cabal of social science professors at SF State College. They had set up a lab space with a few IBM 2741 (I/O Selectric) terminals, connected by dedicated lines to Stanford's Wylbur system. I managed to wangle a spot as a student assistant and never looked back. I also played a tiny bit with a PDP-12 in a bio lab and ran one (1) program on SFSC's "production system", an IBM 1620 Mark II (yep; it's a computer...). While a student, I actually got paid to work with a CDC 3150, a DEC PDP-15, and (once) on an IBM 360/30. After that, I had some Real Jobs: assembler on a Varian 620i and a PDP-11, COBOL on an IBM mainframe, Fortran on assorted CDC and assorted DEC machines, etc. By the late 80's, my personal computers were a pair of aging LSI-11's, running RT-11. At work (Naval Research Lab, in DC), I was mostly using TOPS-10 and Vax/VMS. I wanted to upgrade my home system and knew that I wanted all the cool stuff: a bit-mapped screen, multiprocessing, virtual memory, etc. There was no way I could afford to buy this sort of setup from DEC, but my friend Jim Joyce had been telling me about Unix for a few years, so I attended the Boston USENIX in 1982 (sharing a cheap hotel room with Dick Karpinski :-) and wandered around looking at the workstation offerings. I made a bet on Sun (buying stock would have been far more lucrative, but also more risky and less fun) and ended up buying Sun #285 from John Gage. At one point, John was wandering around Sun, asking for a slogan that Sun could use on a conference button to indicate how they differed from the competition. I suggested "The Joy of Unix", which he immediately adopted. This decision wasn't totally appreciated by some USENIX attendees from Murray Hill, who printed up (using troff, one presumes) and wore individualized paper badges proclaiming themselves as "The of Unix". Imitation is the sincerest form of flattery... (bows) IIRC, I received my Sun-1 late in a week (of course :-), but managed to set it up with fairly little pain. I got some help on the weekend from someone named Bill, who happened to be in the office on the weekend ... seemed quite competent ... I ran for a position on the Sun User Group board, saying that I would try to protect the interests of the "smaller" users. I think I was able to do some good in that position, not least because I was able to get John Gilmore and the Sun lawyers to agree on a legal notice, edit some SUGtapes, etc. Later on, I morphed this effort into Prime Time Freeware, which produced book/CD collections of what is now called Open Source software. Back when there were trade magazines, I also wrote a few hundred articles for Unix Review, SunExpert, etc. Of course, I continue to play (happily) with computers... Perkify If you waded through all of that introduction, you'll have figured out that I'm a big fan of making libre software more available, usable, etc. This actually leads into Perkify, one of my current projects. Perkify is (at heart) a blind-friendly virtual machine, based on Ubuntu, Vagrant, and VirtualBox. As you might expect, it has a strong emphasis on text-based programs, which Unix (and Linux) have in large quantities. However, Perkify's charter has expanded quite a bit. At some point, I realized that (within limits) there was very little point to worrying about how big the Vagrant "box" became. After all, a couple of dozen GB of storage is no longer an issue, and having a big VM on the disk (or even running) doesn't slow anything down. So, the current distro weighs in at about 10 GB and 4,000 or so APT packages (mostly brought in as dependencies or recommendations). Think of it as "a well-equipped workshop, just down the hall". For details, see: - http://pa.cfcl.com/item?key=Areas/Content/Overviews/Perkify_Intro/main.toml - http://pa.cfcl.com/item?key=Areas/Content/Overviews/Perkify_Index/main.toml Sales Pitch I note that assorted folks on this list are trying to dig up copies of Ken's Space Travel program. Amusingly, I was making the same search just the other day. However, finding software that can be made to run on Ubuntu is only part of the challenge I face; I also need to come up APT (or whatever) packages that Just Work when I add them to the distribution. So, here's the pitch. Help me (and others) to create packages for use in Perkify and other Debian-derived distros. The result will be software that has reliable repos, distribution, etc. It may also help the code to live on after you and I are no longer able (or simply interested enough) to keep it going. -r From imp at bsdimp.com Fri Jan 17 06:52:00 2020 From: imp at bsdimp.com (Warner Losh) Date: Thu, 16 Jan 2020 13:52:00 -0700 Subject: [TUHS] History of TUHS Message-ID: Is there a history of TUHS page I've missed? When was it formed? Was it an outgrowth of PUPS? etc. Again, I'm working on a talk and would like to include some of this information and it made me think that the history of the historians should be documented too. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Fri Jan 17 08:01:21 2020 From: wkt at tuhs.org (Warren Toomey) Date: Fri, 17 Jan 2020 08:01:21 +1000 Subject: [TUHS] History of TUHS In-Reply-To: References: Message-ID: <20200116220121.GA29855@minnie.tuhs.org> On Thu, Jan 16, 2020 at 01:52:00PM -0700, Warner Losh wrote: > Is there a history of TUHS page I've missed? > When was it formed? Was it an outgrowth of PUPS? etc. > Again, I'm working on a talk and would like to include some of this > information and it made me think that the history of the historians > should be documented too. > Warner Heh, I hadn't thought that TUHS itself should now be considered historical, but I guess 25 years in the IT industry is a long time. A while back I wrote an answer to this question here: https://minnie.tuhs.org/Blog/2015_12_14_why_start_tuhs.html I started the PDP-11 Unix Preservation Society mailing list around October 1995. Eventually I realised that there needed to be a forum/group with a wider remit, so I started a separate TUHS list in 2000. Some time after that, the two lists got merged to be the single TUHS list. Let me know if you have other questions. Cheers, Warren From rdm at cfcl.com Fri Jan 17 12:44:41 2020 From: rdm at cfcl.com (Rich Morin) Date: Thu, 16 Jan 2020 18:44:41 -0800 Subject: [TUHS] free dead trees, to the best possible home In-Reply-To: <0C61A49E-2AEE-40EF-9472-298E528C064D@cfcl.com> References: <0C61A49E-2AEE-40EF-9472-298E528C064D@cfcl.com> Message-ID: I received several recommendations for the Living Computers Museum, including some from folks on this list. Based on this, I contacted Stephen Jones and am now working with him to tie down the details. Thanks to all who responded; you guys rock! Because no good deed goes unpunished, I may be asking some of you for autographs on things you wrote. (I asked Stephen if this would be useful to them; no response as yet). Also, if you have some detritus that you've been meaning to give away to a good home, this might be a good way to make it happen. Let me know if you want to get involved... -r From gtaylor at tnetconsulting.net Fri Jan 17 13:48:34 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 16 Jan 2020 20:48:34 -0700 Subject: [TUHS] History of TUHS In-Reply-To: <20200116220121.GA29855@minnie.tuhs.org> References: <20200116220121.GA29855@minnie.tuhs.org> Message-ID: <7777413e-9e7d-0338-19b3-9392391ecbe9@spamtrap.tnetconsulting.net> On 1/16/20 3:01 PM, Warren Toomey wrote: > Let me know if you have other questions. Is it worth mentioning COFF anywhere in there? -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From lars at nocrew.org Fri Jan 17 15:46:18 2020 From: lars at nocrew.org (Lars Brinkhoff) Date: Fri, 17 Jan 2020 05:46:18 +0000 Subject: [TUHS] History of TUHS In-Reply-To: <20200116220121.GA29855@minnie.tuhs.org> (Warren Toomey's message of "Fri, 17 Jan 2020 08:01:21 +1000") References: <20200116220121.GA29855@minnie.tuhs.org> Message-ID: <7wzhembpp1.fsf@junk.nocrew.org> Warren Toomey wrote: > Heh, I hadn't thought that TUHS itself should now be considered > historical I often imagine future historians 100 years from now pouring over mailing list archives and bitrotted GitHub repositories, including those that contain historical research. Metahistory maybe? Hello people in the future! How's the singularity treating you? Sorry about the climate. From wkt at tuhs.org Fri Jan 17 16:51:49 2020 From: wkt at tuhs.org (Warren Toomey) Date: Fri, 17 Jan 2020 16:51:49 +1000 Subject: [TUHS] History of TUHS In-Reply-To: <7777413e-9e7d-0338-19b3-9392391ecbe9@spamtrap.tnetconsulting.net> References: <20200116220121.GA29855@minnie.tuhs.org> <7777413e-9e7d-0338-19b3-9392391ecbe9@spamtrap.tnetconsulting.net> Message-ID: <20200117065149.GA4002@minnie.tuhs.org> On Thu, Jan 16, 2020 at 08:48:34PM -0700, Grant Taylor via TUHS wrote: > Is it worth mentioning COFF anywhere in there? Hmm, I'm not sure. Based on the mailing list archive at https://minnie.tuhs.org/pipermail/coff/, I set it up in July 2018 so that us old farts can talk about old computers when the topic was not strictly Unix-related. Cheers, Warren From jsteve at superglobalmegacorp.com Fri Jan 17 20:23:22 2020 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Fri, 17 Jan 2020 10:23:22 +0000 (UTC) Subject: [TUHS] History of TUHS Message-ID: <25E62EB5E090E7CB.28844bdc-bd25-4a29-96a2-8db35ec8a453@mail.outlook.com> Of all those CSV repositories, geocities sites and yahoo groups are any indicator, it's going to be up to people to put the past onto plastic and get it out there.  If anything right now the utzoo archives along with people posting source and patches to usenet survived...  Not to mention all those shovel ware CD-ROMs from the 90s that ironically preserved so much early free software and other gems of the pre Linux/NT world.  Github will eventually be shuttered like anything else and all that will remain is dead links..  It really needs to be distributed by nature, but then you have people using Github as cloud storage of all things.  I don't think the CSRG CD's were hot sellers, and I couldn't imagine getting utzoo or TUHS pressed... Although maybe it's something to look at.  It might be interesting. From: TUHS on behalf of Lars Brinkhoff Sent: Friday, January 17, 2020, 2:47 p.m. To: Warren Toomey Cc: tuhs at tuhs.org Subject: Re: [TUHS] History of TUHS Warren Toomey wrote: > Heh, I hadn't thought that TUHS itself should now be considered > historical I often imagine future historians 100 years from now pouring over mailing list archives and bitrotted GitHub repositories, including those that contain historical research. Metahistory maybe? Hello people in the future! How's the singularity treating you? Sorry about the climate. -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Sat Jan 18 00:31:03 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Fri, 17 Jan 2020 09:31:03 -0500 Subject: [TUHS] Lions book Message-ID: <202001171431.00HEV3gF020029@tahoe.cs.Dartmouth.EDU> I learned from Marianne Lions that she's still receiving royalties from John's book. What a testimonial to both John and the system! Doug From clemc at ccc.com Sat Jan 18 00:50:24 2020 From: clemc at ccc.com (Clem Cole) Date: Fri, 17 Jan 2020 09:50:24 -0500 Subject: [TUHS] Lions book In-Reply-To: <202001171431.00HEV3gF020029@tahoe.cs.Dartmouth.EDU> References: <202001171431.00HEV3gF020029@tahoe.cs.Dartmouth.EDU> Message-ID: Indeed!! FWIW I continue recommend it young hackers to read/examine/study before they try to open something like the current Linux kernel. The MIT xv6 work to put it on an Intel Architecture just adds to the value. As the recent thread/argument on the merits/demerits of the use/abuse of the preprocessor shows - simple and straightforward is easier to understand regardless of the arguments wrt how helpful the macros can be. 6th Edition is clear and if you want to understand what it takes and how it works, John's commentary it difficult to be. On Fri, Jan 17, 2020 at 9:32 AM Doug McIlroy wrote: > I learned from Marianne Lions that she's still receiving > royalties from John's book. What a testimonial to both > John and the system! > > Doug > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Jan 18 01:23:34 2020 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 17 Jan 2020 07:23:34 -0800 Subject: [TUHS] Lions book In-Reply-To: References: <202001171431.00HEV3gF020029@tahoe.cs.Dartmouth.EDU> Message-ID: <20200117152334.GJ28686@mcvoy.com> On Fri, Jan 17, 2020 at 09:50:24AM -0500, Clem Cole wrote: > 6th Edition is clear and if you want to understand what it takes and how it > works, John's commentary it difficult to beat. It's a good starting point but it's pretty outdated. I like to go on and on about how much I love the SunOS 4.x kernel but it is outdated as well. I wish there was a v6/SunOS like kernel that was as clean but had good support for SMP and NUMA and TCP offload (and probably a long list of other useful stuff I've forgotten). Teaching kids how a single threaded kernel works is cool but it's also misleading, the world has gotten a lot more complex. And while the kernels of decades ago were clean and simple, I don't know of a kernel to point people to that has the clean code that SunOS had. Solaris isn't it, though it has some bright spots. Linux is meh, it's better than nothing by a lot but I would not point to it as "read this, kid, you'll see the architecture". It's not clear there is a good answer. From jpl.jpl at gmail.com Sat Jan 18 01:24:57 2020 From: jpl.jpl at gmail.com (John P. Linderman) Date: Fri, 17 Jan 2020 10:24:57 -0500 Subject: [TUHS] Lions book In-Reply-To: References: <202001171431.00HEV3gF020029@tahoe.cs.Dartmouth.EDU> Message-ID: I heard from her as well. So far, no immediate fire danger where she lives in Australia, but her garden (which may be Australian for lawn) is dying because of water restrictions. On Fri, Jan 17, 2020 at 9:52 AM Clem Cole wrote: > Indeed!! > > > FWIW I continue recommend it young hackers to read/examine/study before > they try to open something like the current Linux kernel. The MIT xv6 work > to put it on an Intel Architecture just adds to the value. > > As the recent thread/argument on the merits/demerits of the use/abuse of > the preprocessor shows - simple and straightforward is easier to understand > regardless of the arguments wrt how helpful the macros can be. > > 6th Edition is clear and if you want to understand what it takes and how > it works, John's commentary it difficult to be. > > On Fri, Jan 17, 2020 at 9:32 AM Doug McIlroy > wrote: > >> I learned from Marianne Lions that she's still receiving >> royalties from John's book. What a testimonial to both >> John and the system! >> >> Doug >> > -- > Sent from a handheld expect more typos than usual > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sat Jan 18 02:00:48 2020 From: imp at bsdimp.com (Warner Losh) Date: Fri, 17 Jan 2020 09:00:48 -0700 Subject: [TUHS] Lions book In-Reply-To: <20200117152334.GJ28686@mcvoy.com> References: <202001171431.00HEV3gF020029@tahoe.cs.Dartmouth.EDU> <20200117152334.GJ28686@mcvoy.com> Message-ID: On Fri, Jan 17, 2020 at 8:24 AM Larry McVoy wrote: > On Fri, Jan 17, 2020 at 09:50:24AM -0500, Clem Cole wrote: > > 6th Edition is clear and if you want to understand what it takes and how > it > > works, John's commentary it difficult to beat. > > It's a good starting point but it's pretty outdated. I like to go on and > on about how much I love the SunOS 4.x kernel but it is outdated as well. > > I wish there was a v6/SunOS like kernel that was as clean but had good > support for SMP and NUMA and TCP offload (and probably a long list of > other useful stuff I've forgotten). > > Teaching kids how a single threaded kernel works is cool but it's > also misleading, the world has gotten a lot more complex. And while > the kernels of decades ago were clean and simple, I don't know of > a kernel to point people to that has the clean code that SunOS had. > Solaris isn't it, though it has some bright spots. Linux is meh, it's > better than nothing by a lot but I would not point to it as "read this, > kid, you'll see the architecture". It's not clear there is a good > answer. > It's but the first step on the road to understanding. I'd been working on the FreeBSD kernel for years when I re-read the Lions book. The stark simplicity of the v6 kernel helped everything suddenly 'click' into place in the code I was reading in the FreeBSD kernel, even with 30ish years of changes to the v6 code base that lead to the FreeBSD kernel... Newer systems are a lot more complicated. And they need to be to get the full performance out of the system. Yet understanding the basics without the extra clutter has great value. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Jan 18 02:15:01 2020 From: clemc at ccc.com (Clem Cole) Date: Fri, 17 Jan 2020 11:15:01 -0500 Subject: [TUHS] Lions book In-Reply-To: References: <202001171431.00HEV3gF020029@tahoe.cs.Dartmouth.EDU> <20200117152334.GJ28686@mcvoy.com> Message-ID: I completely agree. Studying and >>learning<< from V6 allows you to consider the basics of what any good OS, no just a UNIX-like system, has to do provide simple but complete services. Examining V6 not most of the things you find today removes a lot of the noise, like threading, parallel execution, vm, networking, which are fine topics for later, but Warner is right - get a solid understanding first. It also helps to understand what makes 'UNIX-ness' and why it was different from anything before it came on the scene. BTW: It' why I still like Pascal (Delphi) over C or C++ as a first language (I admit, I'm leaning towards Go these days, but Go lacks a good teaching text). This is what I heard Doug saying. IMO: Lion's book and the V6, can be considered 'old' by contemporary standards, but they are still 100% appropriate and because the book and code is so simple, the teacher and the student can focus on what really matters (*i.e.* learning to walk carefully in a directed manner and get to your destination before you are forced to run with the bulls and avoid getting run over). On Fri, Jan 17, 2020 at 11:01 AM Warner Losh wrote: > > > On Fri, Jan 17, 2020 at 8:24 AM Larry McVoy wrote: > >> On Fri, Jan 17, 2020 at 09:50:24AM -0500, Clem Cole wrote: >> > 6th Edition is clear and if you want to understand what it takes and >> how it >> > works, John's commentary it difficult to beat. >> >> It's a good starting point but it's pretty outdated. I like to go on and >> on about how much I love the SunOS 4.x kernel but it is outdated as well. >> >> I wish there was a v6/SunOS like kernel that was as clean but had good >> support for SMP and NUMA and TCP offload (and probably a long list of >> other useful stuff I've forgotten). >> >> Teaching kids how a single threaded kernel works is cool but it's >> also misleading, the world has gotten a lot more complex. And while >> the kernels of decades ago were clean and simple, I don't know of >> a kernel to point people to that has the clean code that SunOS had. >> Solaris isn't it, though it has some bright spots. Linux is meh, it's >> better than nothing by a lot but I would not point to it as "read this, >> kid, you'll see the architecture". It's not clear there is a good >> answer. >> > > It's but the first step on the road to understanding. I'd been working on > the FreeBSD kernel for years when I re-read the Lions book. The stark > simplicity of the v6 kernel helped everything suddenly 'click' into place > in the code I was reading in the FreeBSD kernel, even with 30ish years of > changes to the v6 code base that lead to the FreeBSD kernel... > > Newer systems are a lot more complicated. And they need to be to get the > full performance out of the system. Yet understanding the basics without > the extra clutter has great value. > > Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arrigo at alchemistowl.org Sat Jan 18 02:01:47 2020 From: arrigo at alchemistowl.org (Arrigo Triulzi) Date: Fri, 17 Jan 2020 17:01:47 +0100 Subject: [TUHS] On the origins of Linux - "an academic question" Message-ID: [I originally asked the following on Twitter which was probably not the smartest idea] I was recently wondering about the origins of Linux, i.e. Linux Torvalds doing his MSc and deciding to write Linux (the kernel) for the i386 because Minix did not support the i386 properly. While this is perfectly understandable I was trying to understand why, as he was in academia, he did not decide to write a “free X” for a different X. The example I picked was Plan 9, simply because I always liked it but X could be any number of other operating systems which he would have been exposed to in academia. This all started in my mind because I was thinking about my friends who were CompSci university students with me at the time and they were into all sorts of esoteric stuff like Miranda-based operating systems, building a complete interface builder for X11 on SunOS including sparkly mouse pointers, etc. (I guess you could define it as “the usual frivolous MSc projects”) and comparing their choices with Linus’. The answers I got varied from “the world needed a free Unix and BSD was embroiled in the AT&T lawsuit at the time” to “Plan 9 also had a restrictive license” (to the latter my response was that “so did Unix and that’s why Linus built Linux!”) but I don’t feel any of the answers addressed my underlying question as to what was wrong in the exposure to other operating systems which made Unix the choice? Personally I feel that if we had a distributed OS now instead of Linux we’d be better off with the current architecture of the world so I am sad that "Linux is not Plan 9" which is what prompted the question. Obviously I am most grateful for being able to boot the Mathematics department’s MS-DOS i486 machines with Linux 0.12 floppy disks and not having to code Fortran 77 in Notepad followed by eventually taking over the department with X-Terminals based on Linux connected to the departmental servers (Sun, DEC Alpha, IBM RS/6000s). Without Linux they had been running eXeed (sp?) on Windows 3.11! In this respect Linux definitely filled in a huge gap. Arrigo From imp at bsdimp.com Sat Jan 18 02:53:52 2020 From: imp at bsdimp.com (Warner Losh) Date: Fri, 17 Jan 2020 09:53:52 -0700 Subject: [TUHS] On the origins of Linux - "an academic question" In-Reply-To: References: Message-ID: On Fri, Jan 17, 2020 at 9:42 AM Arrigo Triulzi wrote: > [I originally asked the following on Twitter which was probably not the > smartest idea] > > I was recently wondering about the origins of Linux, i.e. Linux Torvalds > doing his MSc and deciding to write Linux (the kernel) for the i386 because > Minix did not support the i386 properly. While this is perfectly > understandable I was trying to understand why, as he was in academia, he > did not decide to write a “free X” for a different X. The example I picked > was Plan 9, simply because I always liked it but X could be any number of > other operating systems which he would have been exposed to in academia. > This all started in my mind because I was thinking about my friends who > were CompSci university students with me at the time and they were into all > sorts of esoteric stuff like Miranda-based operating systems, building a > complete interface builder for X11 on SunOS including sparkly mouse > pointers, etc. (I guess you could define it as “the usual frivolous MSc > projects”) and comparing their choices with Linus’. > > The answers I got varied from “the world needed a free Unix and BSD was > embroiled in the AT&T lawsuit at the time” to “Plan 9 also had a > restrictive license” (to the latter my response was that “so did Unix and > that’s why Linus built Linux!”) but I don’t feel any of the answers > addressed my underlying question as to what was wrong in the exposure to > other operating systems which made Unix the choice? > The AT&T lawsuit (April 1992) post-dated Linus starting on his work (eg 0.12 released January 1992). He said in an interview once he was unaware that net/2 was out and could be leveraged to get a working system when he started. It did give a big boost to Linux at a critical time due to the huge amount of FUD that it created over BSD's future. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From arrigo at alchemistowl.org Sat Jan 18 03:08:03 2020 From: arrigo at alchemistowl.org (Arrigo Triulzi) Date: Fri, 17 Jan 2020 18:08:03 +0100 Subject: [TUHS] On the origins of Linux - "an academic question" In-Reply-To: References: Message-ID: <407987A1-5591-465B-8A77-0B0FCF98F161@alchemistowl.org> On 17 Jan 2020, at 17:53, Warner Losh wrote: > The AT&T lawsuit (April 1992) post-dated Linus starting on his work (eg 0.12 released January 1992). He said in an interview once he was unaware that net/2 was out and could be leveraged to get a working system when he started. It did give a big boost to Linux at a critical time due to the huge amount of FUD that it created over BSD's future. Well, that plainly removes the AT&T lawsuit argument from the answers list so the remaining question I had about its origins is clearer. From athornton at gmail.com Sat Jan 18 03:21:58 2020 From: athornton at gmail.com (Adam Thornton) Date: Fri, 17 Jan 2020 10:21:58 -0700 Subject: [TUHS] Lions book In-Reply-To: <20200117152334.GJ28686@mcvoy.com> References: <202001171431.00HEV3gF020029@tahoe.cs.Dartmouth.EDU> <20200117152334.GJ28686@mcvoy.com> Message-ID: <6181CC8A-EA2D-46E8-B573-04774DD739B5@gmail.com> > On Jan 17, 2020, at 8:23 AM, Larry McVoy wrote: > I don't know of > a kernel to point people to that has the clean code that SunOS had. It’s not exactly a kernel and it’s not exacly … well, anyway: selfie is pretty cool. http://selfie.cs.uni-salzburg.at/ Adam From brantley at coraid.com Sat Jan 18 03:25:15 2020 From: brantley at coraid.com (Brantley Coile) Date: Fri, 17 Jan 2020 17:25:15 +0000 Subject: [TUHS] On the origins of Linux - "an academic question" In-Reply-To: References: Message-ID: <55A1AC0C-AFAE-43E1-9A51-2992071027FC@coraid.com> Since I was a close observer and an early adopter of Plan 9, which is still my main development platform, I'll contribute my thoughts on the question. Plan 9 was still being developed in the time frame that Torvalds was working out Linux. Everyone working in the Unix field wanted a version that was not under AT&T's expensive license. The last one I bought was north of $64K. The biggest reason that Plan 9 isn't the current Linux is that the world didn't need a cloud operating system in the early 1990's. They just needed a Unix for which they could get the source. Plan 9 solves the problem of "How do I make a bunch of machines look like a single system?" If you wanted to mess around with a system in the early 1990's you didn't have a bunch of people and a bunch of systems you needed to make appear as one. You just had a single box. So, my Plan 9 remains small. In fact, I've been removing things from it, like local disks, that is contrary to the original vision. (Or set of visions. I remember getting a lot of different answers form everyone involved in 1127 about what it was that they were doing.) The general question of why Linux emerged and not others didn't is a very hard question that computer historians will be researching for a lot time. It's complex, like all economics. Brantley > On Jan 17, 2020, at 11:01 AM, Arrigo Triulzi wrote: > > [I originally asked the following on Twitter which was probably not the smartest idea] > > I was recently wondering about the origins of Linux, i.e. Linux Torvalds doing his MSc and deciding to write Linux (the kernel) for the i386 because Minix did not support the i386 properly. While this is perfectly understandable I was trying to understand why, as he was in academia, he did not decide to write a “free X” for a different X. The example I picked was Plan 9, simply because I always liked it but X could be any number of other operating systems which he would have been exposed to in academia. This all started in my mind because I was thinking about my friends who were CompSci university students with me at the time and they were into all sorts of esoteric stuff like Miranda-based operating systems, building a complete interface builder for X11 on SunOS including sparkly mouse pointers, etc. (I guess you could define it as “the usual frivolous MSc projects”) and comparing their choices with Linus’. > > The answers I got varied from “the world needed a free Unix and BSD was embroiled in the AT&T lawsuit at the time” to “Plan 9 also had a restrictive license” (to the latter my response was that “so did Unix and that’s why Linus built Linux!”) but I don’t feel any of the answers addressed my underlying question as to what was wrong in the exposure to other operating systems which made Unix the choice? > > Personally I feel that if we had a distributed OS now instead of Linux we’d be better off with the current architecture of the world so I am sad that "Linux is not Plan 9" which is what prompted the question. > > Obviously I am most grateful for being able to boot the Mathematics department’s MS-DOS i486 machines with Linux 0.12 floppy disks and not having to code Fortran 77 in Notepad followed by eventually taking over the department with X-Terminals based on Linux connected to the departmental servers (Sun, DEC Alpha, IBM RS/6000s). Without Linux they had been running eXeed (sp?) on Windows 3.11! In this respect Linux definitely filled in a huge gap. > > Arrigo > From arno.griffioen at ieee.org Sat Jan 18 05:59:08 2020 From: arno.griffioen at ieee.org (Arno Griffioen) Date: Fri, 17 Jan 2020 20:59:08 +0100 Subject: [TUHS] On the origins of Linux - "an academic question" In-Reply-To: References: Message-ID: <20200117195908.GF15253@ancienthardware.org> On Fri, Jan 17, 2020 at 05:01:47PM +0100, Arrigo Triulzi wrote: > I was recently wondering about the origins of Linux, i.e. Linux Torvalds > doing his MSc and deciding to write Linux (the kernel) for the i386 > because Minix did not support the i386 properly. If I remember correctly from those days as a student, that was not the starting point for Linux. He did not 'decide' to write Linux at the start.. He initially didn't even decide to write an OS at all.. As I recall he actually got an i386 based machine and wanted to explore the features of that CPU compared to the 286 and the like. To do that he decided to basically write (if I remember right..) an editor that ran directly on the hardware and made use of the new i386 features. But of course that meant he had to do his own filesystem code to read/write stuff, do some sort of memory management, have some sort of internal 'task' scheduler, etc. At some point, in hindsight probably crucial, he came to the conclusion that it was starting to look more like an OS kernel and looked for something that he could fairly easily run the userland binaries from. MINIX was the obvious one as a userland 'donor' here. Code AND installation media were easily available on discs to us in europe at the time, unlike many of the others out there. At the time Linus was in Finland and most European universities and colleges in those days (late 80's start 90's) were very, very wary of any legal implications even before all the lawsuits. So as a result anything with a big license text on it (even 'kinda free' ones like BSD) were classed as 'risky' and access kept to a bare minimum. Add fledgeling internet access that was also highly restricted because the telco costs in europe were usually massively higher than in the US, so learning about new stuff was harder and then getting it from 'somewhere' was often a painful process. At the time I suspect he just wanted to 'finish' the little i386 learing project with a 'look what I made!' and move on once he did that. So chasing after some other, more esoteric OS, just wasn't worth the effort at the time. However, once he did publish it the MINIX userland basically became the 'incubator' for this new little (monolithic! :P ) kernel broke out when GCC and slowly the other GNU tools became available so it could self-host. Somehow Linus at that time found so much fun from getting all these patches and code to stick into his funny little kernel and watching it grow and evolve that he stuck with it and didn't move to other projects. So all in all.. As I remember it, there was never really a decision to 'make this great new OS!'.. It kinda happened with right place, right time, right people, etc. I vaguely remeber that Linus did give such a timeline in an interview once.. Bye, Arno. From imp at bsdimp.com Sat Jan 18 06:06:49 2020 From: imp at bsdimp.com (Warner Losh) Date: Fri, 17 Jan 2020 13:06:49 -0700 Subject: [TUHS] bitsavers.org down? Message-ID: I'm trying to grab some stuff from bitsavers.org. It seems to be failing to lookup name records. I'd send mail directly to Al, but the only address I have for him at at bitsavers.org :( Anybody have a better contact or good back-channel to Al? Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From gregg.drwho8 at gmail.com Sat Jan 18 07:41:06 2020 From: gregg.drwho8 at gmail.com (Gregg Levine) Date: Fri, 17 Jan 2020 16:41:06 -0500 Subject: [TUHS] bitsavers.org down? In-Reply-To: References: Message-ID: Hello! Sadly I do not, but have you tried any of their mirrors? The one at http://www.mirrorservice.org/ which is called "The UK Mirror Service" which is based in Kent (UK) has everything. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Fri, Jan 17, 2020 at 3:11 PM Warner Losh wrote: > > I'm trying to grab some stuff from bitsavers.org. It seems to be failing to lookup name records. I'd send mail directly to Al, but the only address I have for him at at bitsavers.org :( > > Anybody have a better contact or good back-channel to Al? > > Warner From imp at bsdimp.com Sat Jan 18 08:02:06 2020 From: imp at bsdimp.com (Warner Losh) Date: Fri, 17 Jan 2020 15:02:06 -0700 Subject: [TUHS] bitsavers.org down? In-Reply-To: References: Message-ID: On Fri, Jan 17, 2020 at 2:41 PM Gregg Levine wrote: > Hello! > Sadly I do not, but have you tried any of their mirrors? The one at > http://www.mirrorservice.org/ which is called "The UK Mirror Service" > which is based in Kent (UK) has everything. > (a) Yes. Those work great. (b) I texted Al and he's on top of it. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Sat Jan 18 08:06:38 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 18 Jan 2020 09:06:38 +1100 (EST) Subject: [TUHS] screen editors In-Reply-To: <202001080010.0080APtC1678972@darkstar.fourwinds.com> References: <202001070231.0072ViZp123105@tahoe.cs.Dartmouth.EDU> <20200107023834.GN20269@mcvoy.com> <202001071630.007GUrBj030452@freefriends.org> <202001080010.0080APtC1678972@darkstar.fourwinds.com> Message-ID: On Tue, 7 Jan 2020, Jon Steinhart wrote: > Also because that great vi trainer program rogue existed :-) The story is told of some professor having to learn VI, because EMACS was not available. After a few minutes, he said "Hmmm... It's just like Rogue". FWIW, I once discovered a bug in the Curses library following an upgrade on the Mac: Rogue had stopped working :-) -- Dave From andreww591 at gmail.com Sat Jan 18 09:11:39 2020 From: andreww591 at gmail.com (Andrew Warkentin) Date: Fri, 17 Jan 2020 16:11:39 -0700 Subject: [TUHS] On the origins of Linux - "an academic question" In-Reply-To: References: Message-ID: On 1/17/20, Arrigo Triulzi wrote: > > The answers I got varied from “the world needed a free Unix and BSD was > embroiled in the AT&T lawsuit at the time” to “Plan 9 also had a restrictive > license” (to the latter my response was that “so did Unix and that’s why > Linus built Linux!”) but I don’t feel any of the answers addressed my > underlying question as to what was wrong in the exposure to other operating > systems which made Unix the choice? > Linus has always struck me as purely a pragmatist and not idealistic at all, so I'm not surprised that he wrote a conventional Unix rather than something more architecturally progressive. On 1/17/20, Brantley Coile wrote: > > Plan 9 solves the problem of "How do I make a bunch of machines look like a > single system?" If you wanted to mess around with a system in the early > 1990's you didn't have a bunch of people and a bunch of systems you needed > to make appear as one. You just had a single box. > > So, my Plan 9 remains small. In fact, I've been removing things from it, > like local disks, that is contrary to the original vision. (Or set of > visions. I remember getting a lot of different answers form everyone > involved in 1127 about what it was that they were doing.) > Wasn't the point of single-system-image clustering originally to allow building relatively inexpensive systems with more CPUs than could reasonably be fit into a single machine? Now that all current CPUs except for some low-end embedded ones are multi-core and fully programmable GPUs are ubiquitous, I don't think Plan 9/Amoeba-style SSI is really all that relevant for anything other than HPC. However, I do think distributed network-transparent sharing of devices and services along the lines of QNX or Domain/OS is more relevant than ever. From robpike at gmail.com Sat Jan 18 09:20:40 2020 From: robpike at gmail.com (Rob Pike) Date: Sat, 18 Jan 2020 10:20:40 +1100 Subject: [TUHS] On the origins of Linux - "an academic question" In-Reply-To: References: Message-ID: Plan 9 is not a "single-system-image cluster". -rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From rtomek at ceti.pl Sat Jan 18 09:24:58 2020 From: rtomek at ceti.pl (Tomasz Rola) Date: Sat, 18 Jan 2020 00:24:58 +0100 Subject: [TUHS] bitsavers.org down? In-Reply-To: References: Message-ID: <20200117232457.GA17503@tau1.ceti.pl> On Fri, Jan 17, 2020 at 01:06:49PM -0700, Warner Losh wrote: > I'm trying to grab some stuff from bitsavers.org. It seems to be failing to > lookup name records. I'd send mail directly to Al, but the only address I > have for him at at bitsavers.org :( I could grab the ip from dns (71.91.242.107, apparently) but the route (from my side of the ocean, at least) goes into the woods and gets lost there (but the woods are in States, at least). It is being hosted in same ip pool as classiccmp.org (71.91.242.75) - both by the same provider AFAICT - and the route to classicmp goes into the woods, too. At least right now, on my end of cable. So in short, it looks like somebody dropped their router on the floor? Hard fridays night, perhaps. Power glitch? -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola at bigfoot.com ** From brantley at coraid.com Sat Jan 18 09:38:05 2020 From: brantley at coraid.com (Brantley Coile) Date: Fri, 17 Jan 2020 23:38:05 +0000 Subject: [TUHS] On the origins of Linux - "an academic question" In-Reply-To: References: Message-ID: what he said. > On Jan 17, 2020, at 6:20 PM, Rob Pike wrote: > > Plan 9 is not a "single-system-image cluster". > > -rob > From dave at horsfall.org Sat Jan 18 09:38:53 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 18 Jan 2020 10:38:53 +1100 (EST) Subject: [TUHS] screen editors In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> Message-ID: On Wed, 8 Jan 2020, Clem Cole wrote: > Although the famous ? error from the original version was annoying. Was it Ken or Dennis who thought of a car with but a single alarm indicator; "the experienced driver will know what it means". -- Dave From ryan at boringtranquility.io Sat Jan 18 10:07:34 2020 From: ryan at boringtranquility.io (Ryan Casalino) Date: Fri, 17 Jan 2020 16:07:34 -0800 Subject: [TUHS] screen editors In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> Message-ID: On Fri, Jan 17, 2020, at 3:38 PM, Dave Horsfall wrote: > On Wed, 8 Jan 2020, Clem Cole wrote: > > > Although the famous ? error from the original version was annoying. > > Was it Ken or Dennis who thought of a car with but a single alarm > indicator; "the experienced driver will know what it means". > > -- Dave > I actually just started using ed for the first time last week (based on one of your earlier comments, Clem) and I couldn't disagree more. ? is refreshing in its simplicity. Anyway, back to being a fly on the wall. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From wobblygong at gmail.com Sat Jan 18 10:23:35 2020 From: wobblygong at gmail.com (Wesley Parish) Date: Sat, 18 Jan 2020 13:23:35 +1300 Subject: [TUHS] On the origins of Linux - "an academic question" In-Reply-To: References: Message-ID: There's a book called "Just For Fun: The Story of an Accidental Revolutionary" co-authored by Linus Torvalds and David Diamond that sets out how he came to write the Linux kernel. Wesley Parish On 1/18/20, Arrigo Triulzi wrote: > [I originally asked the following on Twitter which was probably not the > smartest idea] > > I was recently wondering about the origins of Linux, i.e. Linux Torvalds > doing his MSc and deciding to write Linux (the kernel) for the i386 because > Minix did not support the i386 properly. While this is perfectly > understandable I was trying to understand why, as he was in academia, he did > not decide to write a “free X” for a different X. The example I picked was > Plan 9, simply because I always liked it but X could be any number of other > operating systems which he would have been exposed to in academia. This all > started in my mind because I was thinking about my friends who were CompSci > university students with me at the time and they were into all sorts of > esoteric stuff like Miranda-based operating systems, building a complete > interface builder for X11 on SunOS including sparkly mouse pointers, etc. (I > guess you could define it as “the usual frivolous MSc projects”) and > comparing their choices with Linus’. > > The answers I got varied from “the world needed a free Unix and BSD was > embroiled in the AT&T lawsuit at the time” to “Plan 9 also had a restrictive > license” (to the latter my response was that “so did Unix and that’s why > Linus built Linux!”) but I don’t feel any of the answers addressed my > underlying question as to what was wrong in the exposure to other operating > systems which made Unix the choice? > > Personally I feel that if we had a distributed OS now instead of Linux we’d > be better off with the current architecture of the world so I am sad that > "Linux is not Plan 9" which is what prompted the question. > > Obviously I am most grateful for being able to boot the Mathematics > department’s MS-DOS i486 machines with Linux 0.12 floppy disks and not > having to code Fortran 77 in Notepad followed by eventually taking over the > department with X-Terminals based on Linux connected to the departmental > servers (Sun, DEC Alpha, IBM RS/6000s). Without Linux they had been running > eXeed (sp?) on Windows 3.11! In this respect Linux definitely filled in a > huge gap. > > Arrigo > > From pnr at planet.nl Sat Jan 18 10:32:51 2020 From: pnr at planet.nl (Paul Ruizendaal) Date: Sat, 18 Jan 2020 01:32:51 +0100 Subject: [TUHS] CSRG report TR/4 was in Jim Joyce papers Message-ID: Rich was kind enough to look through the Joyce papers to see if it contained "CSRG Tech Report 4: Proposals for Unix on the VAX”. It did. As list regulars will know I’ve been looking for that paper for years as it documents the early ideas for networking and IPC in what was to become 4.2BSD. It is an intriguing paper that discusses a network API that is imo fairly different from what ended up being in 4.1a and 4.2BSD. It confirms Kirk McKusick’s recollection that the select statement was modelled after the ADA select statement. It also confirms Clem Cole’s recollection that the initial ideas for 4.2BSB were significantly influenced by the ideas of Richard Rashid (Aleph/Accent/Mach). Besides IPC and networking, it also discusses file systems and a wide array of potential improvements in various other areas. From imp at bsdimp.com Sat Jan 18 10:36:46 2020 From: imp at bsdimp.com (Warner Losh) Date: Fri, 17 Jan 2020 17:36:46 -0700 Subject: [TUHS] CSRG report TR/4 was in Jim Joyce papers In-Reply-To: References: Message-ID: On Fri, Jan 17, 2020 at 5:33 PM Paul Ruizendaal wrote: > > Rich was kind enough to look through the Joyce papers to see if it > contained "CSRG Tech Report 4: Proposals for Unix on the VAX”. It did. > > As list regulars will know I’ve been looking for that paper for years as > it documents the early ideas for networking and IPC in what was to become > 4.2BSD. > > It is an intriguing paper that discusses a network API that is imo fairly > different from what ended up being in 4.1a and 4.2BSD. It confirms Kirk > McKusick’s recollection that the select statement was modelled after the > ADA select statement. It also confirms Clem Cole’s recollection that the > initial ideas for 4.2BSB were significantly influenced by the ideas of > Richard Rashid (Aleph/Accent/Mach). > > Besides IPC and networking, it also discusses file systems and a wide > array of potential improvements in various other areas. > Awesome! Is that something that will be scanned in so we can all see it? Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdm at cfcl.com Sat Jan 18 10:50:27 2020 From: rdm at cfcl.com (Rich Morin) Date: Fri, 17 Jan 2020 16:50:27 -0800 Subject: [TUHS] CSRG report TR/4 was in Jim Joyce papers In-Reply-To: References: Message-ID: <36A68CD7-797B-4C4A-A3F8-43C8F3D24DA7@cfcl.com> > Awesome! Is that something that will be scanned in so we can all see it? I scanned the paper and then Paul aggregated the scans into a single PDF. It should be available here: http://cfcl.com/private/CSRG_TR_4.pdf -r From clemc at ccc.com Sat Jan 18 11:14:52 2020 From: clemc at ccc.com (Clem Cole) Date: Fri, 17 Jan 2020 20:14:52 -0500 Subject: [TUHS] CSRG report TR/4 was in Jim Joyce papers In-Reply-To: <36A68CD7-797B-4C4A-A3F8-43C8F3D24DA7@cfcl.com> References: <36A68CD7-797B-4C4A-A3F8-43C8F3D24DA7@cfcl.com> Message-ID: Indeed many thanks. On Fri, Jan 17, 2020 at 7:51 PM Rich Morin wrote: > > Awesome! Is that something that will be scanned in so we can all see it? > > I scanned the paper and then Paul aggregated the scans into a single PDF. > It should be available here: > > http://cfcl.com/private/CSRG_TR_4.pdf > > -r > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mparson at bl.org Sat Jan 18 11:55:07 2020 From: mparson at bl.org (Michael Parson) Date: Fri, 17 Jan 2020 19:55:07 -0600 (CST) Subject: [TUHS] screen editors In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> <1ippPk-8PE-00@marmaro.de> Message-ID: On Fri, 10 Jan 2020, Steve Nickolas wrote: > On Fri, 10 Jan 2020, Dan Cross wrote: >> On Fri, Jan 10, 2020 at 10:39 AM Nemo Nusquam >> wrote: >> >>> In earlier days, my wife was given email by telnetting to an SGI >>> system and using elm. One day, I visited her office as she was >>> composing a message. Intrigued, I asked her what the editor >>> was. She did not know and pointed to her cheat-sheet listing editor >>> commands. One was ^X^C to exit-and-send. She is not a programmer >>> and I was a bit surprised at their choice. >> >> >> Hmm, I'm actually kind of not. Starting users off with a modal >> editor (that starts in command mode, no less!) can be surprising for >> novices; with emacs, at least you can start typing text and, well, >> see text. > > This is one of the reasons I liked E when I first used it: it was > modal, but it started in edit mode. (Also you KNEW what mode you were > in, which I understand isn't always the case with vi, although it > usually is in the clones iirc?) > >> I think that one of the smartest things Marc Crispin ever did was >> write `pico` to go with `pine`. A simple editor targeted at the >> novice was really useful for casual and/or new users, particularly as >> the Internet spread and an account on a Unix system was the default >> introduction to email etc for so many. > > And I still use nano - which is a rewrite of pico. The 'gnu' version (or maybe just gnu licensed) of pico, cuz there has to be a 'gnu' licensed of everything :-/ > pico Just Works(R)(TM)(C), and it's not enormous. nano adds a few things I > like, but the UI is the same. Heck...I still use PINE and am sending this > message from it ;) I used pine for years, now alpine, fingers are as hard wired for moving around in it as they are for doing things in vi(m). However, I also have (al)pine use vi for the message editing. :) I learned ed a long time ago because I once had some box that would boot into single-user mode, but not far enough to get any termcap/info stuff loaded, vi didn't work, ex didn't work, but ed did. Not too long ago, I used ed to fix a hosed up passwd file via salt... did something like: sudo salt some-box cmd.run 'printf "1\n/mparson\ns/foo/bar/\nw\nq\n" | ed /etc/passwd' I don't remember what exactly was wrong, but it prevented someone from being able to log in and it wasn't fixable with the 'users' state. Maybe it was a bad path to root's shell and we couldn't log in on the console or something. I've slept since then, lost the details. The guy watching over my shoulder didn't even know what 'ed' was. -- Michael Parson Pflugerville, TX KF5LGQ From mparson at bl.org Sat Jan 18 12:11:19 2020 From: mparson at bl.org (Michael Parson) Date: Fri, 17 Jan 2020 20:11:19 -0600 (CST) Subject: [TUHS] screen editors In-Reply-To: <928BC725-0105-4B38-BC14-A8C04A3C4532@bitblocks.com> References: <20200109012830.GC16808@mcvoy.com> <20200109020720.GG16808@mcvoy.com> <202001090423.0094NooZ379407@darkstar.fourwinds.com> <202001091721.009HLf2V503811@darkstar.fourwinds.com> <928BC725-0105-4B38-BC14-A8C04A3C4532@bitblocks.com> Message-ID: On Thu, 9 Jan 2020, Bakul Shah wrote: > On Jan 9, 2020, at 9:21 AM, Jon Steinhart wrote: >> >> It's for that reason that I hate the addition of multiple windows to vi. I >> already have a windowing system on my machine, and that's what I use for windows. >> To me, the correct thing to do is to open a new desktop window to edit a new file >> and start a new instance of vi, not to use vi to open another internal window. > > The Rand editor made good use of multiple windows. You could set things up so > that two windows would scroll *in sync*. This is handy e.g. when you are looking > at two columns or rows that far apart in the same file or in different files and > too large so you need to scroll. For your .vimrc: nmap =f :vsplitwincmd lexe "norm! Ljz":set scb:wincmd h:set scb Don't remember where I picked that up, but this will give you two vim windows, showing your file in both, one-screen's worth apart, with synchronized scolling. -- Michael Parson Pflugerville, TX KF5LGQ From mparson at bl.org Sat Jan 18 12:06:09 2020 From: mparson at bl.org (Michael Parson) Date: Fri, 17 Jan 2020 20:06:09 -0600 (CST) Subject: [TUHS] screen editors In-Reply-To: <202001090423.0094NooZ379407@darkstar.fourwinds.com> References: <20200109012830.GC16808@mcvoy.com> <20200109020720.GG16808@mcvoy.com> <202001090423.0094NooZ379407@darkstar.fourwinds.com> Message-ID: On Wed, 8 Jan 2020, Jon Steinhart wrote: > Clem Cole writes: >> >> make a new command, don't break the old one.... maybe offer a way to map >> the new one over the old -- but don't make it the default. >> and my lawn was lush and green before the snow came ;-) > > Clem, this seems like an unusual position for you to take. vim is backwards > compatible with vi (and also ed), so it added to an existing ecosystem. It's like 99% compatible. The undo change bothered me a lot, I still don't really 'get' vim's undo method even having mostly given up on old vi about 10 years ago. I'm sure it's better, if I ever got around to learning it, but I agree with Clem, vim's 'enhanced unlmited undo' should have moved to a different keybinding. 'vim' also moved the "increment number" command to a new key. And the one that visually bothered me is 'cw' or 'c', immediately removes the text that's going to be replaced. I liked old vi's way of leaving it there for you to type over. -- Michael Parson Pflugerville, TX KF5LGQ From clemc at ccc.com Sat Jan 18 13:13:45 2020 From: clemc at ccc.com (Clem Cole) Date: Fri, 17 Jan 2020 22:13:45 -0500 Subject: [TUHS] screen editors In-Reply-To: References: <20200109012830.GC16808@mcvoy.com> <20200109020720.GG16808@mcvoy.com> <202001090423.0094NooZ379407@darkstar.fourwinds.com> Message-ID: On Fri, Jan 17, 2020 at 9:35 PM Michael Parson wrote: > It's like 99% compatible. Exactly... As my old (non-PC) 10th-grade calculus teacher used to say, "I'll give you partial credit when you can bring be me a female that is partially pregnant." To be you are either compatible or not. I would have been ok to have had an option that you could turn on that gave you new behavior (but make the user turn it on thank you). BTW: the cX command's behavior I also find annoying visually, but it does not screw up 30-40 years of programming in my fingers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.branden.robinson at gmail.com Sat Jan 18 13:35:56 2020 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sat, 18 Jan 2020 14:35:56 +1100 Subject: [TUHS] Lions book In-Reply-To: <6181CC8A-EA2D-46E8-B573-04774DD739B5@gmail.com> References: <202001171431.00HEV3gF020029@tahoe.cs.Dartmouth.EDU> <20200117152334.GJ28686@mcvoy.com> <6181CC8A-EA2D-46E8-B573-04774DD739B5@gmail.com> Message-ID: <20200118033553.pcagcabtsebs3m33@localhost.localdomain> At 2020-01-17T10:21:58-0700, Adam Thornton wrote: > It’s not exactly a kernel and it’s not exacly … well, anyway: > > selfie is pretty cool. > > http://selfie.cs.uni-salzburg.at/ Oh, heck yeah, it is. Every bullet point makes my heart go pitter-pat. :D Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From tytso at mit.edu Sat Jan 18 13:50:51 2020 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Fri, 17 Jan 2020 22:50:51 -0500 Subject: [TUHS] On the origins of Linux - "an academic question" In-Reply-To: <20200117195908.GF15253@ancienthardware.org> References: <20200117195908.GF15253@ancienthardware.org> Message-ID: <20200118035051.GC481935@mit.edu> On Fri, Jan 17, 2020 at 08:59:08PM +0100, Arno Griffioen wrote: > If I remember correctly from those days as a student, that was not the > starting point for Linux. > > He did not 'decide' to write Linux at the start.. He initially didn't even > decide to write an OS at all.. > > As I recall he actually got an i386 based machine and wanted to explore > the features of that CPU compared to the 286 and the like. To do that he > decided to basically write (if I remember right..) an editor that ran > directly on the hardware and made use of the new i386 features. Not an editor, but rather a terminal emulator, to talk to a modem so he could connect to the university's computers. He first started by having two processes, one which would print just 'A' characters, and another that would print 'B', and had a simple scheduler so they would alternate printing to the screen: "AAAABBBB", etc., then "ABABABAB", etc. And from there he wrote the terminal emulator. What he did after that isn't well recorded; it could have been an editor, but for a long time he using Minix for editing and compiling the proto-kernel that would later become Linux. > However, once he did publish it the MINIX userland basically became the > 'incubator' for this new little (monolithic! :P ) kernel broke out when > GCC and slowly the other GNU tools became available so it could self-host. > > Somehow Linus at that time found so much fun from getting all these > patches and code to stick into his funny little kernel and watching it > grow and evolve that he stuck with it and didn't move to other projects. At the time when Linus announced his creation (not yet named) on comp.os.minix in August 1991, it was already self-hosting. And that happened pretty quickly; he first started working on the project in June or July. Around the end of 1991, I had added Job Control (implemented from POSIX.1 as a the specification), so we could put jobs in the background. In 1992 X Windows was ported to Linux. Networking support followed shortly thereafter. > So all in all.. As I remember it, there was never really a decision to 'make > this great new OS!'.. It kinda happened with right place, right time, right > people, etc. In the super-early days (late 1991, early 1992), those of us who worked on it just wanted a "something Unix-like" that we could run at home (my first computer was a 40 MHz 386 with 16 MB of memory). This was before the AT&T/BSD Lawsuit (which was in 1992) and while Jolitz may have been demonstrating 386BSD in private, I was certainly never aware of it --- and Linus was publishing new versions every few days on an ftp site. We'd send patches, and in less than a week, there'd be a new release dropped that we could download. So the argument, "Linus would have never started on Linux if itT weren't for the AT&T Lawsuit" I don't think fits with the timeline. Development was very fast paced, and so it was *fun*. And at least for me, the lacking of networking during the early days didn't bother me much, since I didn't have networking at home. (I didn't have grounded outlets, either, in my 3 people for $1050/month apartment. Each leg was 50-60V to ground, and the wiring was cloth wrapped, and was either steel or aluminum; I never did figured out which....) Using zmodem over a 2400 bps modem was way more efficient than PPP, so even once we had networking, I didn't always bring up pppd. And the most common way I would download source was using set of 1.44 MB floppies and a station wagon (literally; I was driving a Corolla wagon). During those early days, the fact that Linux was more "primitive" than BSD may have been an advantage, since it sources was small, and release engineering is simple when you only support one architecture. The other things I noticed was that because we didn't have the weight of the Unix/BSD legacy, we were more free to experiment. Bruce Evans was working on the serial driver for FreeBSD, and I was working on the serial driver for Linux, and we had a friendly competition to see who could get better throughput using the very primitive 8250 and later 16550 UART. The figure of merit we were using was the CPU overhead of a C-Kermit file transfer over two RS-232 ports connected via a loopback cable. We'd compare notes to see how we could make things better, me for Linux, and Bruce for FreeBSD, and it was *fun*. Eventually, it got to the point where I was making changes to the tty layer to further optimize things, and at that point Bruce reported that he couldn't do some of the optimizations, since it would have required changing the TTY layer that had been handed down from the Gods of Olympus^H^H^H^H^H^H^H^H BSD and so it was nixed by his colleagues in FreeBSD land. In contrast, in Linux, people felt free to rip out and replace code if it would make things better. Depending on how you count things, the networking layer in Linux was ripped out and replaced three or four times in the space of as many years. Sure, the first version was pretty crappy, and was barely good enough for simple telnet connections. But things got better fast, because people were felt free to experiment. My personal belief is that it was this development velocity and freedom to experiment starting with a super simple base is what caused Linux to become very popular amongst the those who just wanted to play with kernel development. Compare and contrast Linus's willingness to accept patches from others and his turnaround time to get those patches into new releases with Bill Jolitz's 386BSD effort --- and I don't think you need the AT&T lawsuit to explain why Linux took off in 1991-1992. FreeBSD and NetBSD was started in 1993 because of the failure of Jolitz to accept patches in a timely fashion. - Ted From khm at sciops.net Sat Jan 18 13:44:27 2020 From: khm at sciops.net (Kurt H Maier) Date: Fri, 17 Jan 2020 19:44:27 -0800 Subject: [TUHS] screen editors In-Reply-To: References: <20200109012830.GC16808@mcvoy.com> <20200109020720.GG16808@mcvoy.com> <202001090423.0094NooZ379407@darkstar.fourwinds.com> Message-ID: <20200118034427.GC70100@wopr> On Fri, Jan 17, 2020 at 10:13:45PM -0500, Clem Cole wrote: > On Fri, Jan 17, 2020 at 9:35 PM Michael Parson wrote: > > > It's like 99% compatible. > > Exactly... As my old (non-PC) 10th-grade calculus teacher used to say, > "I'll give you partial credit when you can bring be me a female that is > partially pregnant." > > To be you are either compatible or not. I would have been ok to have had > an option that you could turn on that gave you new behavior (but make the > user turn it on thank you). > > BTW: the cX command's behavior I also find annoying visually, but it does > not screw up 30-40 years of programming in my fingers. There was a time when, by default, vim started in 'compatible' mode, in which u didn't ignore u, so you got the toggle-style undo. Compatible mode also keeps the ol$ style of c representation, and so forth. You can still force this by making a ~/.vimrc file that just contains set compatible I don't remember when vim stopped launching in compatible mode by default, but that was basically when I stopped using it. I only figured out how to force it back because it's on all the linux computers I run into at work. As I recall, the 'set compatible' command is shorthand to set all the vi-compatibility flags by default; it is possible to set them individually as well. So your proposal is (was?) at least implemented, if not in a very useful manner. khm From grog at lemis.com Sat Jan 18 14:08:25 2020 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Sat, 18 Jan 2020 15:08:25 +1100 Subject: [TUHS] Bruce Evans: RIP Message-ID: <20200118040825.GA67053@eureka.lemis.com> Ted Ts'o mentioned Bruce Evans in a reply to "On the origins of Linux". I'm really sorry to have to announce that he died last month. His family is holding a "small farewell gathering" in Sydney in late February. To quote his sister Julie Saravanos: We would be pleased if you, or any other BSD/computer friend, came There's no date yet, and I don't think it's appropriate to broadcast details. If anybody is interested, please contact Warren or me. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From grog at lemis.com Sat Jan 18 14:19:13 2020 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Sat, 18 Jan 2020 15:19:13 +1100 Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") In-Reply-To: <20200118035051.GC481935@mit.edu> References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> Message-ID: <20200118041913.GB67053@eureka.lemis.com> On Friday, 17 January 2020 at 22:50:51 -0500, Theodore Y. Ts'o wrote: > > In the super-early days (late 1991, early 1992), those of us who > worked on it just wanted a "something Unix-like" that we could run at > home (my first computer was a 40 MHz 386 with 16 MB of memory). This > was before the AT&T/BSD Lawsuit (which was in 1992) and while Jolitz > may have been demonstrating 386BSD in private, I was certainly never > aware of it At the start of this time, Bill was working for BSDI, who were preparing a commercial product that (in March 1992) became BSD/386. As Rob Kolstad told me in mid-1992, he had a (to put it mildly) difference of opinion with Rob, and probably others, about the commercial nature (at the time BSD/386 cost $1000), and he resigned at the end of 1991. So 386BSD presumably didn't exist before that. On the other hand, Bill did write the articles in Dr. Dobbs Journal, which started in January 1991, so my best guess is that Linus just wasn't informed about the developments. It's easy to forget how difficult it was to get this kind of information in those days. I was informed about the articles, but more by chance than anything else. I didn't find out about BSD/386 until March 1992, when the first betas were released. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From andreww591 at gmail.com Sat Jan 18 16:15:11 2020 From: andreww591 at gmail.com (Andrew Warkentin) Date: Fri, 17 Jan 2020 23:15:11 -0700 Subject: [TUHS] Distributed systems, was: On the origins of Linux - "an academic question" Message-ID: On 1/17/20, Brantley Coile wrote: > what he said. > >> On Jan 17, 2020, at 6:20 PM, Rob Pike wrote: >> >> Plan 9 is not a "single-system-image cluster". >> >> -rob >> > > I guess SSI isn't the right term for Plan 9 clustering since not everything is shared, although I would still say it has some aspects of SSI. I was talking about systems that try to make a cluster look like a single machine in some way even if they don't share everything (I'm not sure if there's a better term for such systems besides the rather vague "distributed" which could mean anything from full SSI to systems that allow transparent access to services/devices on other machines without trying to make a cluster look like a single system). From robpike at gmail.com Sat Jan 18 16:25:14 2020 From: robpike at gmail.com (Rob Pike) Date: Sat, 18 Jan 2020 17:25:14 +1100 Subject: [TUHS] Distributed systems, was: On the origins of Linux - "an academic question" In-Reply-To: References: Message-ID: I am convinced that large-scale modern compute centers would be run very differently, with fewer or at least lesser problems, if they were treated as a single system rather than as a bunch of single-user computers ssh'ed together. But history had other ideas. -rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreww591 at gmail.com Sat Jan 18 17:30:09 2020 From: andreww591 at gmail.com (Andrew Warkentin) Date: Sat, 18 Jan 2020 00:30:09 -0700 Subject: [TUHS] [TUHS -> COFF] Distributed systems, was: On the origins of Linux - "an academic question" In-Reply-To: References: Message-ID: On 1/17/20, Rob Pike wrote: > I am convinced that large-scale modern compute centers would be run very > differently, with fewer or at least lesser problems, if they were treated > as a single system rather than as a bunch of single-user computers ssh'ed > together. > > But history had other ideas. > [moving to COFF since this isn't specific to historic Unix] For applications (or groups of related applications) that are already distributed across multiple machines I'd say "cluster as a single system" definitely makes sense, but I still stand by what I said earlier about it not being relevant for things like workstations, or for server applications that are run on a single machine. I think clustering should be an optional subsystem, rather than something that is deeply integrated into the core of an OS. With an OS that has enough extensibiity, it should be possible to have an optional clustering subsystem without making it feel like an afterthought. That is what I am planning to do in UX/RT, the OS that I am writing. The "core supervisor" (seL4 microkernel + process server + low-level system library) will lack any built-in network support and will just have support for local file servers using microkernel IPC. The network stack, 9P client filesystem, 9P server, and clustering subsystem will all be separate regular processes. The 9P server will use regular read()/write()-like APIs rather than any special hooks (there will be read()/write()-like APIs that expose the message registers and shared buffer to make this more efficient), and similarly the 9P client filesystem will use the normal API for local filesystem servers (which will also use read()/write() to send messages). The clustering subsystem will work by intercepting process API calls and forwarding them to either the local process server or to a remote instance as appropriate. Since UX/RT will go even further than Plan 9 with its file-oriented architecture and make process APIs file-oriented, this will be transparent to applications. Basically, the way that the file-oriented process API will work is that every process will have a special "process server connection" file descriptor that carries all process server API calls over a minimalist form of RPC, and it will be possible to redirect this to an intermediary at process startup (of course, this redirection will be inherited by child processes automatically). From thomas.paulsen at firemail.de Sat Jan 18 19:01:25 2020 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Sat, 18 Jan 2020 10:01:25 +0100 Subject: [TUHS] CSRG report TR/4 was in Jim Joyce papers In-Reply-To: <36A68CD7-797B-4C4A-A3F8-43C8F3D24DA7@cfcl.com> References: <36A68CD7-797B-4C4A-A3F8-43C8F3D24DA7@cfcl.com> Message-ID: <30304771245b987553fb6baccb1d992a@firemail.de> >I scanned the paper and then Paul aggregated the scans into a single PDF. >It should be available here: > http://cfcl.com/private/CSRG_TR_4.pdf thanks for the link to an really important document! From elbingmiss at gmail.com Sat Jan 18 21:55:58 2020 From: elbingmiss at gmail.com (=?UTF-8?Q?=C3=81lvaro_Jurado?=) Date: Sat, 18 Jan 2020 12:55:58 +0100 Subject: [TUHS] Distributed systems, was: On the origins of Linux - "an academic question" In-Reply-To: References: Message-ID: On Sat, 18 Jan 2020 at 07:26, Rob Pike wrote: > I am convinced that large-scale modern compute centers would be run very > differently, with fewer or at least lesser problems, if they were treated > as a single system rather than as a bunch of single-user computers ssh'ed > together. > > But history had other ideas. > > -rob > > IBM Watson is not that concept? I think history (bussiness) tends right now to a decentralized model for large systems, which is not clear if it’s an advantage for now. Rather than emulating centralized computing systems across many machines. Anyway, the main interest for researching about is still keeping the bussiness running. And for now Unix descendants do it really well. — Álvaro Jurado -- Álvaro -------------- next part -------------- An HTML attachment was scrubbed... URL: From mparson at bl.org Sun Jan 19 00:22:59 2020 From: mparson at bl.org (Michael Parson) Date: Sat, 18 Jan 2020 08:22:59 -0600 (CST) Subject: [TUHS] screen editors In-Reply-To: References: Message-ID: On Wed, 8 Jan 2020, Nemo Nusquam wrote: > On 01/08/20 04:46, Rudi Blom wrote: >> That's a real big vi in RHL. Looking at a few (commercial) unixes I get >> SCO UNIX 3.2V4.2 132898 Aug 22 1996 /usr/bin/vi >> - /usr/bin/vi: iAPX 386 executable >> Tru64 V5.1B-5 331552 Aug 21 2010 /usr/bin/vi >> - /usr/bin/vi: COFF format alpha dynamically linked, demand paged >> sticky executable or object module stripped - version 3.13-14 >> HP-UX 11.31 748996 Aug 28 2009 /bin/vi >> -- /bin/vi: ELF-32 executable object file - IA64 > > Solaris 10 on Ultrasparc 239828 > /usr/bin/vi: ELF 32-bit MSB executable SPARC Version 1, dynamically > linked, stripped > > Any others? I've been playing with this for the last few months: $ uname -a UNIX_System_V amix 4.0 2.1c 0800430 Amiga (Unlimited) m68k $ file /usr/bin/vi /usr/bin/vi: ELF 32-bit MSB executable M68000 Version 1 -- Michael Parson Pflugerville, TX KF5LGQ From lm at mcvoy.com Sun Jan 19 01:25:45 2020 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 18 Jan 2020 07:25:45 -0800 Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") In-Reply-To: <20200118041913.GB67053@eureka.lemis.com> References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> Message-ID: <20200118152545.GB28686@mcvoy.com> On Sat, Jan 18, 2020 at 03:19:13PM +1100, Greg 'groggy' Lehey wrote: > On Friday, 17 January 2020 at 22:50:51 -0500, Theodore Y. Ts'o wrote: > > > > In the super-early days (late 1991, early 1992), those of us who > > worked on it just wanted a "something Unix-like" that we could run at > > home (my first computer was a 40 MHz 386 with 16 MB of memory). This > > was before the AT&T/BSD Lawsuit (which was in 1992) and while Jolitz > > may have been demonstrating 386BSD in private, I was certainly never > > aware of it > > At the start of this time, Bill was working for BSDI, who were > preparing a commercial product that (in March 1992) became BSD/386. Wikipedia says he was working on 386BSD as early has 1989 and that clicks with me (Jolitz worked for me around 1992 or 3). I don't remember him mentioning working at BSDI, are you sure about that part? Those guys did not like each other at all. From lm at mcvoy.com Sun Jan 19 01:30:00 2020 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 18 Jan 2020 07:30:00 -0800 Subject: [TUHS] On the origins of Linux - "an academic question" In-Reply-To: <20200118035051.GC481935@mit.edu> References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> Message-ID: <20200118153000.GC28686@mcvoy.com> On Fri, Jan 17, 2020 at 10:50:51PM -0500, Theodore Y. Ts'o wrote: +1 to everything Ted said, that's how I remember it as well. I knew about both Linux and 386BSD and while 386BSD felt very familiar to a SunOS guy, there was something special about Linux. For a while I played with both, 386BSD was sort of better in that it had networking, but like Ted, my network was a modem and TCP over a modem wasn't pleasant. So Linux won out and eventually networked just fine. > At the time when Linus announced his creation (not yet named) on > comp.os.minix in August 1991, it was already self-hosting. And that > happened pretty quickly; he first started working on the project in > June or July. > > Around the end of 1991, I had added Job Control (implemented from > POSIX.1 as a the specification), so we could put jobs in the > background. In 1992 X Windows was ported to Linux. Networking > support followed shortly thereafter. > > > So all in all.. As I remember it, there was never really a decision to 'make > > this great new OS!'.. It kinda happened with right place, right time, right > > people, etc. > > In the super-early days (late 1991, early 1992), those of us who > worked on it just wanted a "something Unix-like" that we could run at > home (my first computer was a 40 MHz 386 with 16 MB of memory). This > was before the AT&T/BSD Lawsuit (which was in 1992) and while Jolitz > may have been demonstrating 386BSD in private, I was certainly never > aware of it --- and Linus was publishing new versions every few days > on an ftp site. We'd send patches, and in less than a week, there'd > be a new release dropped that we could download. > > So the argument, "Linus would have never started on Linux if itT > weren't for the AT&T Lawsuit" I don't think fits with the timeline. > Development was very fast paced, and so it was *fun*. And at least > for me, the lacking of networking during the early days didn't bother > me much, since I didn't have networking at home. (I didn't have > grounded outlets, either, in my 3 people for $1050/month apartment. > Each leg was 50-60V to ground, and the wiring was cloth wrapped, and > was either steel or aluminum; I never did figured out which....) > Using zmodem over a 2400 bps modem was way more efficient than PPP, so > even once we had networking, I didn't always bring up pppd. And the > most common way I would download source was using set of 1.44 MB > floppies and a station wagon (literally; I was driving a Corolla wagon). > > During those early days, the fact that Linux was more "primitive" than > BSD may have been an advantage, since it sources was small, and > release engineering is simple when you only support one architecture. > > The other things I noticed was that because we didn't have the weight > of the Unix/BSD legacy, we were more free to experiment. Bruce Evans > was working on the serial driver for FreeBSD, and I was working on the > serial driver for Linux, and we had a friendly competition to see who > could get better throughput using the very primitive 8250 and later > 16550 UART. The figure of merit we were using was the CPU overhead of > a C-Kermit file transfer over two RS-232 ports connected via a > loopback cable. We'd compare notes to see how we could make things > better, me for Linux, and Bruce for FreeBSD, and it was *fun*. > Eventually, it got to the point where I was making changes to the tty > layer to further optimize things, and at that point Bruce reported > that he couldn't do some of the optimizations, since it would have > required changing the TTY layer that had been handed down from the > Gods of Olympus^H^H^H^H^H^H^H^H BSD and so it was nixed by his > colleagues in FreeBSD land. > > In contrast, in Linux, people felt free to rip out and replace code if > it would make things better. Depending on how you count things, the > networking layer in Linux was ripped out and replaced three or four > times in the space of as many years. Sure, the first version was > pretty crappy, and was barely good enough for simple telnet > connections. But things got better fast, because people were felt > free to experiment. > > My personal belief is that it was this development velocity and > freedom to experiment starting with a super simple base is what caused > Linux to become very popular amongst the those who just wanted to play > with kernel development. Compare and contrast Linus's willingness to > accept patches from others and his turnaround time to get those > patches into new releases with Bill Jolitz's 386BSD effort --- and I > don't think you need the AT&T lawsuit to explain why Linux took off in > 1991-1992. FreeBSD and NetBSD was started in 1993 because of the > failure of Jolitz to accept patches in a timely fashion. > > - Ted -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From jsteve at superglobalmegacorp.com Sun Jan 19 01:35:40 2020 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Sat, 18 Jan 2020 15:35:40 +0000 (UTC) Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") Message-ID: <25E62EB5E090E7CB.0e52e059-5d83-4d31-98f4-bb2d82ede4f8@mail.outlook.com> I would imagine that the user land changes made its way into 386 Mach.  Although I haven't seen anything I can recall off the top of my head about 386 commits in user land until much later.  Maybe one day more of that Mt Xinu stuff will surface, although I'm still amazed I got the kernel to build.  Internet legend is that the rift was massive.   From: TUHS on behalf of Larry McVoy Sent: Sunday, January 19, 2020, 12:26 a.m. To: Greg 'groggy' Lehey Cc: UNIX Heritage Society Subject: Re: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") On Sat, Jan 18, 2020 at 03:19:13PM +1100, Greg 'groggy' Lehey wrote: > On Friday, 17 January 2020 at 22:50:51 -0500, Theodore Y. Ts'o wrote: > > > > In the super-early days (late 1991, early 1992), those of us who > > worked on it just wanted a "something Unix-like" that we could run at > > home (my first computer was a 40 MHz 386 with 16 MB of memory). This > > was before the AT&T/BSD Lawsuit (which was in 1992) and while Jolitz > > may have been demonstrating 386BSD in private, I was certainly never > > aware of it > > At the start of this time, Bill was working for BSDI, who were > preparing a commercial product that (in March 1992) became BSD/386. Wikipedia says he was working on 386BSD as early has 1989 and that clicks with me (Jolitz worked for me around 1992 or 3). I don't remember him mentioning working at BSDI, are you sure about that part? Those guys did not like each other at all. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sun Jan 19 01:37:25 2020 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 18 Jan 2020 07:37:25 -0800 Subject: [TUHS] screen editors In-Reply-To: References: <20200109012830.GC16808@mcvoy.com> <20200109020720.GG16808@mcvoy.com> <202001090423.0094NooZ379407@darkstar.fourwinds.com> Message-ID: <20200118153725.GD28686@mcvoy.com> On Fri, Jan 17, 2020 at 10:13:45PM -0500, Clem Cole wrote: > On Fri, Jan 17, 2020 at 9:35 PM Michael Parson wrote: > > > It's like 99% compatible. > > Exactly... As my old (non-PC) 10th-grade calculus teacher used to say, > "I'll give you partial credit when you can bring be me a female that is > partially pregnant." > > To be you are either compatible or not. I would have been ok to have had > an option that you could turn on that gave you new behavior (but make the > user turn it on thank you). It's rare event when I disagree with you, Clem (sometimes it seems like we were separated at birth :) If it was compat by default then you wouldn't learn any of the new stuff. set compatible isn't that hard but we'd have to read docs to find that. Anyhoo, cross reference to Ted's thought that Linux didn't have to deal with the Gods of BSD so they could rip stuff out and try again, his point is that worked better than the BSD way. Compat is fine but if you want progress, sometimes you break compat. For me, I've got a .exrc that I've been carrying around for decades (has maps in it for some compat bindings to an editor I used on CP/M, it's _that_ old) and vim is perfectly happy with it. I mostly use vim as a vi compat but I regularly use 2 panes, that's super useful. It's progress and you can have compat mode easily, seems like a win. From mparson at bl.org Sun Jan 19 01:45:22 2020 From: mparson at bl.org (Michael Parson) Date: Sat, 18 Jan 2020 09:45:22 -0600 (CST) Subject: [TUHS] Tech Sq elevator (Was: screen editors) [ really I think efficiency now ] In-Reply-To: References: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU> <202001122034.00CKYQ39571239@darkstar.fourwinds.com> <202001122044.00CKiUNV573279@darkstar.fourwinds.com> <202001122137.00CLbMrw582813@darkstar.fourwinds.com> Message-ID: On Mon, 13 Jan 2020, Dan Cross wrote: > > [Resending as this got squashed a few days ago. Jon, sorry for the > duplicate. Again.] > > On Sun, Jan 12, 2020 at 4:38 PM Jon Steinhart wrote: >> Many people have claimed, incorrectly in my opinion, that this model >> fails in the modern era because it only works on text data. They >> change the subject when I point out that ImageMagick works on binary >> data. And, there are now stream processing utilities for JSON data >> and such that show that the UNIX model still works IF you understand >> it and know how to use it. > > > Certainly. I think you hit the nail on the head with the proviso > that one must _understand_ the Unix model and how to use it. If one > does so, it's very powerful indeed, and it really is applicable more > often than not. But it is not a panacea (not that anyone suggested it > is). As an example, how do I apply an unmodified `grep` to arbitrary > JSON data (which may span more than one line)? Perhaps there is a way > (I can imagine a 'record2line' program that consumes a single JSON > object and emits it as a syntactically valid one-liner...) but I can > also imagine all sorts of ways that might go wrong. And here, understanding the model is important, namely, grep is the wrong tool for searching/parsing JSON output. Dealing with JSON from the shell, you should use jq. I've been dragged kicking and screaming into dealing with JSON, and about all I can say about it is, I like it about this >< much more than XML. :) -- Michael Parson Pflugerville, TX KF5LGQ From lm at mcvoy.com Sun Jan 19 01:49:48 2020 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 18 Jan 2020 07:49:48 -0800 Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") In-Reply-To: <25E62EB5E090E7CB.0e52e059-5d83-4d31-98f4-bb2d82ede4f8@mail.outlook.com> References: <25E62EB5E090E7CB.0e52e059-5d83-4d31-98f4-bb2d82ede4f8@mail.outlook.com> Message-ID: <20200118154948.GE28686@mcvoy.com> On Sat, Jan 18, 2020 at 03:35:40PM +0000, Jason Stevens wrote: > Internet legend is that the rift was massive.???? It was and Jolitz was unfairly crapped on at a Usenix, the one after the lawsuit. At the time, everyone thought it was about copyright and Jolitz told me that there was a lot of code that was unchanged from v7. He knew that I knew the file system code and he said "Go look at bmap(), it's byte for byte exactly the same". He was right and there was other stuff, it wasn't just one function. This was after both BSDI and 386BSD were a thing. At a Usenix conference, the BSDI guys pissed all over him, put down his efforts on 386BSD, it was obviously self serving because they wanted a business, but it wasn't a nice thing to do at all. Bill thought he had the goods on them for copyright infringement but he held his tongue and took the abuse because he didn't want to help the lawsuit. In his mind, he was a martyr for the cause. So, yeah, those guys didn't like each other. I know all of them and wished they had handled this better. I heard about all this, I was probably at that Usenix or maybe someone told me, I don't remember. I felt bad for Bill and was in a position where I could hire him, so I did. He didn't really do anything for me though we did have some fascinating discussions about the short comings of C++ and mused about how a language would have to work to truly layer "correctly". The context was the SCSI subsystem, it was part replicated protocol in each driver and part driver specific stuff and we were trying to imagine a programming language that would let us have the replicated stuff in one place and plumb in the specific stuff as needed. Needless to say, we didn't come up with an answer but it was a fun thought experiment. He's a sharp guy, quirky, but sharp. From reed at reedmedia.net Sun Jan 19 02:19:06 2020 From: reed at reedmedia.net (reed at reedmedia.net) Date: Sat, 18 Jan 2020 10:19:06 -0600 (CST) Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") In-Reply-To: <20200118152545.GB28686@mcvoy.com> References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> <20200118152545.GB28686@mcvoy.com> Message-ID: > I don't remember him mentioning working at BSDI, are you sure about > that part? See https://tech-insider.org/unix/research/1992/0319.html coworkers said: "Jolitz was one of the founders of Berkeley Software Design, Inc. ... was a full time employee of BSDI for 11 months of 1991 -- from January 1, 1991 through November 30, 1991 ... a founder of BSDI as well as its first full-time paid employee" And his wife wrote "Bill did work for UUNET from January to June of 1991." Jeremy C. Reed echo Ohl zl obbx uggc://errqzrqvn.arg/obbxf/csfrafr/ | \ tr "Onoqrsuvxzabcefghl" "Babdefhikmnoprstuy" From aek at bitsavers.org Sun Jan 19 04:20:05 2020 From: aek at bitsavers.org (Al Kossow) Date: Sat, 18 Jan 2020 10:20:05 -0800 Subject: [TUHS] bitsavers.org down? In-Reply-To: <20200117232457.GA17503@tau1.ceti.pl> References: <20200117232457.GA17503@tau1.ceti.pl> Message-ID: <1bda55b6-a221-3baa-2d81-cf19c93610e3@bitsavers.org> On 1/17/20 3:24 PM, Tomasz Rola wrote: > So in short, it looks like somebody dropped their router on the floor? > Hard fridays night, perhaps. Power glitch? > The entire classiccmp server was lost. The bitsavers data is safe since I maintain my own copy, and the mirrors should have the image of it before the crash, which was the whole point of having the site completely static. If Jay decides not to continue hosting bitsavers, this may be the end since I can't afford to host the site. From jon at fourwinds.com Sun Jan 19 04:45:28 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Sat, 18 Jan 2020 10:45:28 -0800 Subject: [TUHS] Tech Sq elevator (Was: screen editors) [ really I think efficiency now ] In-Reply-To: References: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU> <202001122034.00CKYQ39571239@darkstar.fourwinds.com> <202001122044.00CKiUNV573279@darkstar.fourwinds.com> <202001122137.00CLbMrw582813@darkstar.fourwinds.com> Message-ID: <202001181845.00IIjSRE2543512@darkstar.fourwinds.com> Michael Parson writes: > On Mon, 13 Jan 2020, Dan Cross wrote: > > > > [Resending as this got squashed a few days ago. Jon, sorry for the > > duplicate. Again.] > > > > On Sun, Jan 12, 2020 at 4:38 PM Jon Steinhart wrote: > > > > >> Many people have claimed, incorrectly in my opinion, that this model > >> fails in the modern era because it only works on text data. They > >> change the subject when I point out that ImageMagick works on binary > >> data. And, there are now stream processing utilities for JSON data > >> and such that show that the UNIX model still works IF you understand > >> it and know how to use it. > > > > > > Certainly. I think you hit the nail on the head with the proviso > > that one must _understand_ the Unix model and how to use it. If one > > does so, it's very powerful indeed, and it really is applicable more > > often than not. But it is not a panacea (not that anyone suggested it > > is). As an example, how do I apply an unmodified `grep` to arbitrary > > JSON data (which may span more than one line)? Perhaps there is a way > > (I can imagine a 'record2line' program that consumes a single JSON > > object and emits it as a syntactically valid one-liner...) but I can > > also imagine all sorts of ways that might go wrong. > > And here, understanding the model is important, namely, grep is the > wrong tool for searching/parsing JSON output. Dealing with JSON from the > shell, you should use jq. I've been dragged kicking and screaming into > dealing with JSON, and about all I can say about it is, I like it about > this >< much more than XML. :) > > -- > Michael Parson > Pflugerville, TX > KF5LGQ Slight disagreement here. I would say that grep is *a* a tool for JSON and that jq is *a better* one. The UNIX model part of this is that jq is another tool in a toolbox and plays well with others. What disturbs me about a lot of software (and my tractor) it when it does the equivalent of throwing a random metric bolt into something that's built from SAE hardware. Jon From mparson at bl.org Sun Jan 19 04:59:45 2020 From: mparson at bl.org (Michael Parson) Date: Sat, 18 Jan 2020 12:59:45 -0600 (CST) Subject: [TUHS] Tech Sq elevator (Was: screen editors) [ really I think efficiency now ] In-Reply-To: <202001181845.00IIjSRE2543512@darkstar.fourwinds.com> References: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU> <202001122034.00CKYQ39571239@darkstar.fourwinds.com> <202001122044.00CKiUNV573279@darkstar.fourwinds.com> <202001122137.00CLbMrw582813@darkstar.fourwinds.com> <202001181845.00IIjSRE2543512@darkstar.fourwinds.com> Message-ID: On Sat, 18 Jan 2020, Jon Steinhart wrote: > Michael Parson writes: >> On Mon, 13 Jan 2020, Dan Cross wrote: >>> >>> [Resending as this got squashed a few days ago. Jon, sorry for the >>> duplicate. Again.] >>> >>> On Sun, Jan 12, 2020 at 4:38 PM Jon Steinhart wrote: >> >> >> >>>> Many people have claimed, incorrectly in my opinion, that this model >>>> fails in the modern era because it only works on text data. They >>>> change the subject when I point out that ImageMagick works on binary >>>> data. And, there are now stream processing utilities for JSON data >>>> and such that show that the UNIX model still works IF you understand >>>> it and know how to use it. >>> >>> >>> Certainly. I think you hit the nail on the head with the proviso >>> that one must _understand_ the Unix model and how to use it. If one >>> does so, it's very powerful indeed, and it really is applicable more >>> often than not. But it is not a panacea (not that anyone suggested it >>> is). As an example, how do I apply an unmodified `grep` to arbitrary >>> JSON data (which may span more than one line)? Perhaps there is a way >>> (I can imagine a 'record2line' program that consumes a single JSON >>> object and emits it as a syntactically valid one-liner...) but I can >>> also imagine all sorts of ways that might go wrong. >> >> And here, understanding the model is important, namely, grep is the >> wrong tool for searching/parsing JSON output. Dealing with JSON from the >> shell, you should use jq. I've been dragged kicking and screaming into >> dealing with JSON, and about all I can say about it is, I like it about >> this >< much more than XML. :) >> >> -- >> Michael Parson >> Pflugerville, TX >> KF5LGQ > > Slight disagreement here. I would say that grep is *a* a tool for JSON and > that jq is *a better* one. OK, yeah, I'll use grep to find what I'm looking for in the json output, then fight with^W^Wuse jq to extract the info I'm looking for in the json output. > The UNIX model part of this is that jq is another tool in a toolbox > and plays well with others. What disturbs me about a lot of software > (and my tractor) it when it does the equivalent of throwing a random > metric bolt into something that's built from SAE hardware. > > Jon > -- Michael Parson Pflugerville, TX KF5LGQ From rdm at cfcl.com Sun Jan 19 05:25:18 2020 From: rdm at cfcl.com (Rich Morin) Date: Sat, 18 Jan 2020 11:25:18 -0800 Subject: [TUHS] CSRG report TR/4 was in Jim Joyce papers In-Reply-To: References: Message-ID: <0570C6B1-6024-400B-929F-621F8521BE42@cfcl.com> [ No good deed goes unpunished... -r ] > On Jan 18, 2020, at 01:08, Paul Ruizendaal wrote: > > At the bottom of page 6 TR/4 references TR/3: > > A more complete description of the motivation of the IPC architecture > described here, measurements of a prototype implementation, comparisons > with other work and a complete bibliography are given in CSRG TR/3: “An IPC > Architecture for UNIX”. > > I hesitate to ask, but is the TR/3 report also in Jim’s papers? > I’m not asking for a scan, just if it is there. Would this do? FYI, it's about 50 pages, including a four-page bibliography. An Architecture for Interprocess Communication in UNIX* -- DRAFT of June 22, 1981 -- William Joy and Robert Fabry Paul sez: > Before yesterday I did not know that TR/3 existed and in my (arguable) view it is even a bigger find than TR/4, as it gives great insight how design trade-offs were perceived back in 1981. Again, I scanned the paper and then Paul aggregated the scans into a single PDF. It should be available here: http://cfcl.com/private/CSRG_TR_3.pdf -r From rdm at cfcl.com Sun Jan 19 05:27:39 2020 From: rdm at cfcl.com (Rich Morin) Date: Sat, 18 Jan 2020 11:27:39 -0800 Subject: [TUHS] "What UNIX Cost Us" Message-ID: <5A5107E4-06AD-4C2B-B590-15C17B301D44@cfcl.com> FWIW, I found this talk to be quite amusing and interesting. "What UNIX Cost Us" - Benno Rice (LCA 2020) https://www.youtube.com/watch?v=9-IWMbJXoLM -r From michael at kjorling.se Sun Jan 19 06:04:39 2020 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Sat, 18 Jan 2020 20:04:39 +0000 Subject: [TUHS] bitsavers.org down? In-Reply-To: <1bda55b6-a221-3baa-2d81-cf19c93610e3@bitsavers.org> References: <20200117232457.GA17503@tau1.ceti.pl> <1bda55b6-a221-3baa-2d81-cf19c93610e3@bitsavers.org> Message-ID: On 18 Jan 2020 10:20 -0800, from aek at bitsavers.org (Al Kossow): > The bitsavers data is safe since > I maintain my own copy, and the mirrors should have the image of it before > the crash, which was the whole point of having the site completely static. > If Jay decides not to continue hosting bitsavers, this may be the end > since I can't afford to host the site. If that does turn out to be the case, might you consider transferring the data wholesale to, say, the Internet Archive? Out of curiosity, how much data are we talking about? -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” From aek at bitsavers.org Sun Jan 19 06:13:21 2020 From: aek at bitsavers.org (Al Kossow) Date: Sat, 18 Jan 2020 12:13:21 -0800 Subject: [TUHS] bitsavers.org down? In-Reply-To: References: <20200117232457.GA17503@tau1.ceti.pl> <1bda55b6-a221-3baa-2d81-cf19c93610e3@bitsavers.org> Message-ID: On 1/18/20 12:04 PM, Michael Kjörling wrote: > If that does turn out to be the case, might you consider transferring > the data wholesale to, say, the Internet Archive? Jason already takes everything. We have mutually different goals. I want the data everywhere, they only want it at the IA From arnold at skeeve.com Sun Jan 19 06:19:10 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sat, 18 Jan 2020 13:19:10 -0700 Subject: [TUHS] bitsavers.org down? In-Reply-To: References: <20200117232457.GA17503@tau1.ceti.pl> <1bda55b6-a221-3baa-2d81-cf19c93610e3@bitsavers.org> Message-ID: <202001182019.00IKJAtK021714@freefriends.org> Al Kossow wrote: > > > On 1/18/20 12:04 PM, Michael Kjörling wrote: > > > If that does turn out to be the case, might you consider transferring > > the data wholesale to, say, the Internet Archive? > > Jason already takes everything. > We have mutually different goals. I want the data everywhere, they only want it at the IA > Perhaps some sort of crowd-funding would let you continue running things? Just a thought, Arnold From athornton at gmail.com Sun Jan 19 06:24:21 2020 From: athornton at gmail.com (Adam Thornton) Date: Sat, 18 Jan 2020 13:24:21 -0700 Subject: [TUHS] Distributed systems, was: On the origins of Linux - "an academic question" In-Reply-To: References: Message-ID: > On Jan 17, 2020, at 11:25 PM, Rob Pike wrote: > > I am convinced that large-scale modern compute centers would be run very differently, with fewer or at least lesser problems, if they were treated as a single system rather than as a bunch of single-user computers ssh'ed together. > > But history had other ideas. So I’ve clearly got a dog in this fight (https://athornton.github.io/Tucson-Python-Dec-2019/ et al. (also mostly at athornton.github.io)) but I feel like Kubernetes is an interesting compromise in that space. Admittedly, I come to this not only from a Unix/Linux background but an IBM VM background, but: 1) containerization is a necessary but not sufficient first step 2) black magic to handle the internal networking and endpoint exposure through fairly simple configuration on the user’s part is essential 3) abstractions to describe resources (the current enumerated-objects quota stuff is clunky but sufficient; the CPU/Memory quota stuff is fine), and 4) an automated lifecycle manager taken together give you a really nifty platform for defining complex applications via composition, which (IMHO) is one of the fundamental wins of Unix, although in this case, it’s really _not_ very analogous to plugging pipeline stages together. Note that _running_ Kubernetes is still a pain, so unless running data centers is your job, just rent capacity from someone else’s managed Kubernetes service. Adam From aek at bitsavers.org Sun Jan 19 06:24:32 2020 From: aek at bitsavers.org (Al Kossow) Date: Sat, 18 Jan 2020 12:24:32 -0800 Subject: [TUHS] bitsavers.org down? In-Reply-To: <202001182019.00IKJAtK021714@freefriends.org> References: <20200117232457.GA17503@tau1.ceti.pl> <1bda55b6-a221-3baa-2d81-cf19c93610e3@bitsavers.org> <202001182019.00IKJAtK021714@freefriends.org> Message-ID: <742d2a1f-c794-e2d4-4e21-c07d8e5db60c@bitsavers.org> On 1/18/20 12:19 PM, arnold at skeeve.com wrote: > Perhaps some sort of crowd-funding would let you continue running things? > Let's see what happens with the server first. I have a copy of the most recent data, and the mirrors are all still there. I've asked that we disable the rsyncs until we can do a fixity check. I have no idea how much bandwith is used. The archive is about 300gb From athornton at gmail.com Sun Jan 19 06:31:46 2020 From: athornton at gmail.com (Adam Thornton) Date: Sat, 18 Jan 2020 13:31:46 -0700 Subject: [TUHS] Tech Sq elevator (Was: screen editors) [ really I think efficiency now ] In-Reply-To: References: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU> <202001122034.00CKYQ39571239@darkstar.fourwinds.com> <202001122044.00CKiUNV573279@darkstar.fourwinds.com> <202001122137.00CLbMrw582813@darkstar.fourwinds.com> <202001181845.00IIjSRE2543512@darkstar.fourwinds.com> Message-ID: <52C6CADB-C6FA-4AD5-8B21-D28DBAA9BFEE@gmail.com> On Jan 18, 2020, at 11:59 AM, Michael Parson wrote: > OK, yeah, I'll use grep to find what I'm looking for in the json output, > then fight with^W^Wuse jq to extract the info I'm looking for in the json > output. Glad to know it’s not just me that finds the jq query language…difficult to comprehend. Adam From velocityboy at gmail.com Sun Jan 19 06:33:54 2020 From: velocityboy at gmail.com (Jim Geist) Date: Sat, 18 Jan 2020 15:33:54 -0500 Subject: [TUHS] bitsavers.org down? In-Reply-To: <742d2a1f-c794-e2d4-4e21-c07d8e5db60c@bitsavers.org> References: <20200117232457.GA17503@tau1.ceti.pl> <1bda55b6-a221-3baa-2d81-cf19c93610e3@bitsavers.org> <202001182019.00IKJAtK021714@freefriends.org> <742d2a1f-c794-e2d4-4e21-c07d8e5db60c@bitsavers.org> Message-ID: I mainly lurk here but if something will help save bitsavers I'm in. I've gotten way to much use out of it over the years to not contribute if needed. On Sat, Jan 18, 2020 at 3:26 PM Al Kossow wrote: > > On 1/18/20 12:19 PM, arnold at skeeve.com wrote: > > > Perhaps some sort of crowd-funding would let you continue running things? > > > > Let's see what happens with the server first. > I have a copy of the most recent data, and the mirrors are all still there. > I've asked that we disable the rsyncs until we can do > a fixity check. > > I have no idea how much bandwith is used. The archive is about 300gb > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Sun Jan 19 06:34:22 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sat, 18 Jan 2020 21:34:22 +0100 Subject: [TUHS] "What UNIX Cost Us" In-Reply-To: <5A5107E4-06AD-4C2B-B590-15C17B301D44@cfcl.com> References: <5A5107E4-06AD-4C2B-B590-15C17B301D44@cfcl.com> Message-ID: <20200118203422.2c7o_%steffen@sdaoden.eu> Rich Morin wrote in <5A5107E4-06AD-4C2B-B590-15C17B301D44 at cfcl.com>: |FWIW, I found this talk to be quite amusing and interesting. | |"What UNIX Cost Us" - Benno Rice (LCA 2020) |https://www.youtube.com/watch?v=9-IWMbJXoLM That is the one who mutilated the FreeBSD fortune program no? (Despite it saying The potentially offensive fortunes are installed by default on FreeBSD systems. If you're absolutely, *positively*, without-a-shadow-of-a-doubt sure that your user community goes berzerk/sues your pants off/drops dead upon reading one of them, edit the Makefile in the subdirectory datfiles, and do "make all install".) Nothing but a hollow lie ever since! --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) From athornton at gmail.com Sun Jan 19 06:35:17 2020 From: athornton at gmail.com (Adam Thornton) Date: Sat, 18 Jan 2020 13:35:17 -0700 Subject: [TUHS] bitsavers.org down? In-Reply-To: <742d2a1f-c794-e2d4-4e21-c07d8e5db60c@bitsavers.org> References: <20200117232457.GA17503@tau1.ceti.pl> <1bda55b6-a221-3baa-2d81-cf19c93610e3@bitsavers.org> <202001182019.00IKJAtK021714@freefriends.org> <742d2a1f-c794-e2d4-4e21-c07d8e5db60c@bitsavers.org> Message-ID: So…that’s not a lot of archive, so I’m guessing that it’s outbound bandwidth that will be the driving cost. But even that…how popular is it _really_ ? It seems like, given the nature of the collection, it might not be hard to persuade one of the cloud providers into discounted rates for hosting, although…it’s so small that that might not work, because that little data, well, you’re not a customer big enough to have a Google or Amazon rep. I’ll put out some feelers. Rough bandwidth data, if we can figure out some way to find it, would be good to have. Adam > On Jan 18, 2020, at 1:24 PM, Al Kossow wrote: > > > On 1/18/20 12:19 PM, arnold at skeeve.com wrote: > >> Perhaps some sort of crowd-funding would let you continue running things? >> > > Let's see what happens with the server first. > I have a copy of the most recent data, and the mirrors are all still there. > I've asked that we disable the rsyncs until we can do > a fixity check. > > I have no idea how much bandwith is used. The archive is about 300gb > From toby at telegraphics.com.au Sun Jan 19 06:37:34 2020 From: toby at telegraphics.com.au (Toby Thain) Date: Sat, 18 Jan 2020 15:37:34 -0500 Subject: [TUHS] bitsavers.org down? In-Reply-To: <202001182019.00IKJAtK021714@freefriends.org> References: <20200117232457.GA17503@tau1.ceti.pl> <1bda55b6-a221-3baa-2d81-cf19c93610e3@bitsavers.org> <202001182019.00IKJAtK021714@freefriends.org> Message-ID: On 2020-01-18 3:19 PM, arnold at skeeve.com wrote: > Al Kossow wrote: > >> >> >> On 1/18/20 12:04 PM, Michael Kjörling wrote: >> >>> If that does turn out to be the case, might you consider transferring >>> the data wholesale to, say, the Internet Archive? >> >> Jason already takes everything. >> We have mutually different goals. I want the data everywhere, they only want it at the IA >> > > Perhaps some sort of crowd-funding would let you continue running things? Hm, let's see... the richest man in the world owns some kind of cloud infra... I guess he's not very interested in computing history though. > > Just a thought, > > Arnold > From toby at telegraphics.com.au Sun Jan 19 06:40:41 2020 From: toby at telegraphics.com.au (Toby Thain) Date: Sat, 18 Jan 2020 15:40:41 -0500 Subject: [TUHS] Distributed systems, was: On the origins of Linux - "an academic question" In-Reply-To: References: Message-ID: <58b728c7-2605-2418-df97-50bfea85bc46@telegraphics.com.au> On 2020-01-18 3:24 PM, Adam Thornton wrote: > > >> On Jan 17, 2020, at 11:25 PM, Rob Pike wrote: >> >> I am convinced that large-scale modern compute centers would be run very differently, with fewer or at least lesser problems, if they were treated as a single system rather than as a bunch of single-user computers ssh'ed together. >> >> But history had other ideas. > > So I’ve clearly got a dog in this fight (https://athornton.github.io/Tucson-Python-Dec-2019/ et al. (also mostly at athornton.github.io)) but I feel like Kubernetes is an interesting compromise in that space. > > Admittedly, I come to this not only from a Unix/Linux background but an IBM VM background, but: > > 1) containerization is a necessary but not sufficient first step Exactly. > 2) black magic to handle the internal networking and endpoint exposure through fairly simple configuration on the user’s part is essential > 3) abstractions to describe resources (the current enumerated-objects quota stuff is clunky but sufficient; the CPU/Memory quota stuff is fine), and > 4) an automated lifecycle manager Right, I think we use the terms "orchestration", "service discovery", etc. --T > > taken together give you a really nifty platform for defining complex applications via composition, which (IMHO) is one of the fundamental wins of Unix, although in this case, it’s really _not_ very analogous to plugging pipeline stages together. > > Note that _running_ Kubernetes is still a pain, so unless running data centers is your job, just rent capacity from someone else’s managed Kubernetes service. > > Adam > From usotsuki at buric.co Sun Jan 19 06:53:07 2020 From: usotsuki at buric.co (Steve Nickolas) Date: Sat, 18 Jan 2020 15:53:07 -0500 (EST) Subject: [TUHS] bitsavers.org down? In-Reply-To: References: <20200117232457.GA17503@tau1.ceti.pl> <1bda55b6-a221-3baa-2d81-cf19c93610e3@bitsavers.org> <202001182019.00IKJAtK021714@freefriends.org> <742d2a1f-c794-e2d4-4e21-c07d8e5db60c@bitsavers.org> Message-ID: On Sat, 18 Jan 2020, Adam Thornton wrote: > So…that’s not a lot of archive, so I’m guessing that it’s outbound > bandwidth that will be the driving cost. But even that…how popular is > it _really_ ? > > It seems like, given the nature of the collection, it might not be hard > to persuade one of the cloud providers into discounted rates for > hosting, although…it’s so small that that might not work, because that > little data, well, you’re not a customer big enough to have a Google or > Amazon rep. > > I’ll put out some feelers. Rough bandwidth data, if we can figure out > some way to find it, would be good to have. What about renting an OVH server and slapping it on that? I think the KimSufi 1 is 500 GB disk space - dunno if that's cheap enough. -uso. From athornton at gmail.com Sun Jan 19 07:04:01 2020 From: athornton at gmail.com (Adam Thornton) Date: Sat, 18 Jan 2020 14:04:01 -0700 Subject: [TUHS] bitsavers.org down? In-Reply-To: References: <20200117232457.GA17503@tau1.ceti.pl> <1bda55b6-a221-3baa-2d81-cf19c93610e3@bitsavers.org> <202001182019.00IKJAtK021714@freefriends.org> <742d2a1f-c794-e2d4-4e21-c07d8e5db60c@bitsavers.org> Message-ID: <0436FF28-56DE-4167-815A-4AE695D86C94@gmail.com> > On Jan 18, 2020, at 1:53 PM, Steve Nickolas wrote: > > On Sat, 18 Jan 2020, Adam Thornton wrote: > >> So…that’s not a lot of archive, so I’m guessing that it’s outbound bandwidth that will be the driving cost. But even that…how popular is it _really_ ? >> >> It seems like, given the nature of the collection, it might not be hard to persuade one of the cloud providers into discounted rates for hosting, although…it’s so small that that might not work, because that little data, well, you’re not a customer big enough to have a Google or Amazon rep. >> >> I’ll put out some feelers. Rough bandwidth data, if we can figure out some way to find it, would be good to have. > > What about renting an OVH server and slapping it on that? I think the KimSufi 1 is 500 GB disk space - dunno if that's cheap enough. A possibly-stopgap-but-maybe-not-idiotic solution just occurred to me. This isn’t exactly the sort of data that’s GOOD for hosting via Git, since it’s mostly-binary and mostly-read-only. But checking it into a GitHub public repo until we were told to stop…or checking in some indexes, paying for some S3 buckets, and using Git Large File Support pointing at the buckets for the binary blobs…might not be the dumbest idea in the world. I mean, GitHub is well-indexed, has a lot of incentive to maintain good backups, and probably isn’t going anywhere any time soon. Adam From toby at telegraphics.com.au Sun Jan 19 07:22:37 2020 From: toby at telegraphics.com.au (Toby Thain) Date: Sat, 18 Jan 2020 16:22:37 -0500 Subject: [TUHS] bitsavers.org down? In-Reply-To: <0436FF28-56DE-4167-815A-4AE695D86C94@gmail.com> References: <20200117232457.GA17503@tau1.ceti.pl> <1bda55b6-a221-3baa-2d81-cf19c93610e3@bitsavers.org> <202001182019.00IKJAtK021714@freefriends.org> <742d2a1f-c794-e2d4-4e21-c07d8e5db60c@bitsavers.org> <0436FF28-56DE-4167-815A-4AE695D86C94@gmail.com> Message-ID: <8ced9228-5126-681c-11d1-9af4e4dda1ed@telegraphics.com.au> On 2020-01-18 4:04 PM, Adam Thornton wrote: > > >> On Jan 18, 2020, at 1:53 PM, Steve Nickolas wrote: >> >> On Sat, 18 Jan 2020, Adam Thornton wrote: >> >>> So…that’s not a lot of archive, so I’m guessing that it’s outbound bandwidth that will be the driving cost. But even that…how popular is it _really_ ? >>> >>> It seems like, given the nature of the collection, it might not be hard to persuade one of the cloud providers into discounted rates for hosting, although…it’s so small that that might not work, because that little data, well, you’re not a customer big enough to have a Google or Amazon rep. >>> >>> I’ll put out some feelers. Rough bandwidth data, if we can figure out some way to find it, would be good to have. >> >> What about renting an OVH server and slapping it on that? I think the KimSufi 1 is 500 GB disk space - dunno if that's cheap enough. > > > A possibly-stopgap-but-maybe-not-idiotic solution just occurred to me. > > This isn’t exactly the sort of data that’s GOOD for hosting via Git, since it’s mostly-binary and mostly-read-only. > > But checking it into a GitHub public repo until we were told to stop…or checking in some indexes, paying for some S3 buckets, and using Git Large File Support pointing at the buckets for the binary blobs…might not be the dumbest idea in the world. I mean, GitHub is well-indexed, has a lot of incentive to maintain good backups, and probably isn’t going anywhere any time soon. S3 already serves static content directly. Anyone thinking about this problem should consider what you get in S3 that you'd otherwise have to replace in other ways. --T > > Adam > From michael at kjorling.se Sun Jan 19 07:31:01 2020 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Sat, 18 Jan 2020 21:31:01 +0000 Subject: [TUHS] bitsavers.org down? In-Reply-To: References: <20200117232457.GA17503@tau1.ceti.pl> <1bda55b6-a221-3baa-2d81-cf19c93610e3@bitsavers.org> <202001182019.00IKJAtK021714@freefriends.org> <742d2a1f-c794-e2d4-4e21-c07d8e5db60c@bitsavers.org> Message-ID: <4wfn9dxck39qq9trvk7tq4rt@localhost> On 18 Jan 2020 15:53 -0500, from usotsuki at buric.co (Steve Nickolas): > What about renting an OVH server and slapping it on that? I think the > KimSufi 1 is 500 GB disk space - dunno if that's cheap enough. I just checked with another ISP, just to get a data point. Hetzner (which has datacenters in Germany and Finland, but I'm not sure how they feel about customers in the US) charge €0.05/GB/month plus VAT for extra storage volumes; ignoring VAT, 300 GB comes out to €15/month. 500 GB would be €25/month. Especially for static content, their low-end VPS would almost certainly be plenty powerful enough for serving it, so add €2.50/month for that. So starting at some €20/month for VPS hosting with sufficient storage. They also include 20 TB/month outgoing traffic in all VPS plans; additional traffic is extra. ISP-side backups cost an additional 20%. Add VAT to taste. I looked at the KimSufi 1; that looks like it comes out to $3.35/month for their cheapest tier VPS, plus $42/month for 500 GB of storage (next tier down is 200 GB at $21/month, so not enough). So about $45/month. Not sure if that's inclusive or exclusive of VAT, but still, about twice the price. So if a single server is merely nice to have as opposed to critical, it definitely looks to be doable with a VPS in the 30-50 currency per month price range. -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” From rtomek at ceti.pl Sun Jan 19 07:56:49 2020 From: rtomek at ceti.pl (Tomasz Rola) Date: Sat, 18 Jan 2020 22:56:49 +0100 Subject: [TUHS] bitsavers.org down? In-Reply-To: <1bda55b6-a221-3baa-2d81-cf19c93610e3@bitsavers.org> References: <20200117232457.GA17503@tau1.ceti.pl> <1bda55b6-a221-3baa-2d81-cf19c93610e3@bitsavers.org> Message-ID: <20200118215649.GA2390@tau1.ceti.pl> On Sat, Jan 18, 2020 at 10:20:05AM -0800, Al Kossow wrote: > > > On 1/17/20 3:24 PM, Tomasz Rola wrote: > > > So in short, it looks like somebody dropped their router on the floor? > > Hard fridays night, perhaps. Power glitch? > > > > The entire classiccmp server was lost. [...] Holy crap. Does it mean the content hosted there (which includes some long gone collector's websites) is gone too? I have copied some of it for my own purposes, but it is far from being complete or anything like this. -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola at bigfoot.com ** From aek at bitsavers.org Sun Jan 19 08:04:31 2020 From: aek at bitsavers.org (Al Kossow) Date: Sat, 18 Jan 2020 14:04:31 -0800 Subject: [TUHS] bitsavers.org down? In-Reply-To: <20200118215649.GA2390@tau1.ceti.pl> References: <20200117232457.GA17503@tau1.ceti.pl> <1bda55b6-a221-3baa-2d81-cf19c93610e3@bitsavers.org> <20200118215649.GA2390@tau1.ceti.pl> Message-ID: <7a869ed9-4814-6f23-3c30-ec0e03327485@bitsavers.org> On 1/18/20 1:56 PM, Tomasz Rola wrote: >> The entire classiccmp server was lost. > [...] > > Holy crap. Does it mean the content hosted there (which includes some > long gone collector's websites) is gone too? We don't know yet. Jay is working on trying to recover it. This is also why the cctalk/cctech mailing lists are down. Fortunately, Jay created a Discord channel a few months ago, so there is a comms channel independent of his servers. From meillo at marmaro.de Sun Jan 19 08:11:14 2020 From: meillo at marmaro.de (markus schnalke) Date: Sat, 18 Jan 2020 23:11:14 +0100 Subject: [TUHS] screen editors In-Reply-To: <20200118153725.GD28686@mcvoy.com> References: <20200109012830.GC16808@mcvoy.com> <20200109020720.GG16808@mcvoy.com> <202001090423.0094NooZ379407@darkstar.fourwinds.com> <20200118153725.GD28686@mcvoy.com> Message-ID: <1iswJG-1JH-00@marmaro.de> Hoi. Not wanting to heaten this rather annoying editor discussion, but as no one yet has mentioned argv[0]: [2020-01-18 07:37] Larry McVoy > On Fri, Jan 17, 2020 at 10:13:45PM -0500, Clem Cole wrote: > > > > To be you are either compatible or not. I would have been ok to have had > > an option that you could turn on that gave you new behavior (but make the > > user turn it on thank you). > If it was compat by default then you > wouldn't learn any of the new stuff. > set compatible Shouldn't all that be solved by acting compatible if called as `vi' and being free from compatibility bounds when called as `vim'? If I say `vi' I want a vi. If I want Vim, I say so. (No matter if these are links to the same binary.) Problem solved. Everyone happy? meillo From reed at reedmedia.net Sun Jan 19 07:38:50 2020 From: reed at reedmedia.net (reed at reedmedia.net) Date: Sat, 18 Jan 2020 15:38:50 -0600 (CST) Subject: [TUHS] CSRG report TR/4 was in Jim Joyce papers In-Reply-To: <0570C6B1-6024-400B-929F-621F8521BE42@cfcl.com> References: <0570C6B1-6024-400B-929F-621F8521BE42@cfcl.com> Message-ID: On Sat, 18 Jan 2020, Rich Morin wrote: > [ No good deed goes unpunished... -r ] Thanks again! Do you have a bibliography or list of all the papers and books you have in that collection? I have a very very long list of things I am looking for, such as: - "The Conversion of U.C. Berkeley Time Sharing Systems to UNIX Version Seven" by Bob Kridle 1981; - various Unix News 1975-1976; - more 1970's Western Electric licensing examples; Univ. of California / Berkeley; Univ. of Toronto, or any other 1970's "Unix" licenses. (An example I am looking for is AT&T/USL vs. BSDI/Univ. of California June 1992 complaint Exhibit F "32V Software Agreement" dated April 1, 1979 (or Exhibit B to the DeFazio Affidavit)? (See 920724.complaint.txt and more details in 930107.amicus.txt and 930108.oppose.txt.) Or maybe the 1981 relicense? - 1970's release announcements of any Unix or any Berkeley Unix related software (like Berkeley Pascal) - "PWB/Unix overview and synopsis of facilities" 1977 by Dolotta and Haight; - M. Nielsen, "SUN Student Workstation System Overview" Computer Science Department, Stanford Univ. 1981 - Shannon and Lyon's paper "4.2BSD on the Sun Workstation (or What we Did on our Summer Vacation)(or How to Emulate a VAX on a 68000)" from Winter 1983 Usenix/Unicom? (Sure seems like I found this but don't see now.) - BBN QTR "Combined Quarterly Technical Report" 18, 21, 22, 25, 28 Maybe we should make a TUHS wiki page of documents we are looking for? (Or maybe there already is?) From imp at bsdimp.com Sun Jan 19 08:35:11 2020 From: imp at bsdimp.com (Warner Losh) Date: Sat, 18 Jan 2020 15:35:11 -0700 Subject: [TUHS] CSRG report TR/4 was in Jim Joyce papers In-Reply-To: References: <0570C6B1-6024-400B-929F-621F8521BE42@cfcl.com> Message-ID: On Sat, Jan 18, 2020 at 3:23 PM wrote: > On Sat, 18 Jan 2020, Rich Morin wrote: > > > [ No good deed goes unpunished... -r ] > > - "PWB/Unix overview and synopsis of facilities" 1977 by Dolotta and > Haight; > ACM published An introduction to the Programmer's Workbench - [image: T A Dolotta profile image]T. A. Dolotta , - [image: John Russell Mashey profile image]J. R. Mashey ICSE '76: Proceedings of the 2nd international conference on Software engineering October 1976, pp 164–168 There's about 6 or 7 PWB articles in those proceedings. Do you have copies of those? Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.m.travis at gmail.com Sun Jan 19 09:02:24 2020 From: greg.m.travis at gmail.com (greg travis) Date: Sat, 18 Jan 2020 18:02:24 -0500 Subject: [TUHS] screen editors In-Reply-To: References: <9c507ef665851fd21ecdf0e23136dc86@firemail.de> Message-ID: 'Ken Thompson has an automobile which he helped design. Unlike most automobiles, it has neither speedometer, nor gas gauge, nor any of the other numerous idiot lights which plague the modern driver. Rather, if the driver makes a mistake, a giant “?” lights up in the center of the dashboard. “The experienced driver,” says Thompson, “will usually know what’s wrong.”' On Fri, Jan 17, 2020 at 6:39 PM Dave Horsfall wrote: > On Wed, 8 Jan 2020, Clem Cole wrote: > > > Although the famous ? error from the original version was annoying. > > Was it Ken or Dennis who thought of a car with but a single alarm > indicator; "the experienced driver will know what it means". > > -- Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmhanson at eschatologist.net Sun Jan 19 08:48:45 2020 From: cmhanson at eschatologist.net (Chris Hanson) Date: Sat, 18 Jan 2020 14:48:45 -0800 Subject: [TUHS] Atari System V media and books? Message-ID: I’ve seen the archives of Atari System V Release 4 for the TT030, and the scanned user and developer manuals. Has anything else been preserved, e.g. the installation tapes and any other manuals? Is there even a full accounting of what was in the box and what shipped afterwards (patches etc.)? -- Chris From mparson at bl.org Sun Jan 19 09:19:59 2020 From: mparson at bl.org (Michael Parson) Date: Sat, 18 Jan 2020 17:19:59 -0600 (CST) Subject: [TUHS] Atari System V media and books? In-Reply-To: References: Message-ID: On Sat, 18 Jan 2020, Chris Hanson wrote: > I’ve seen the archives of Atari System V Release 4 for the TT030, > and the scanned user and developer manuals. Has anything else been > preserved, e.g. the installation tapes and any other manuals? > > Is there even a full accounting of what was in the box and what > shipped afterwards (patches etc.)? Most of I've seen is the stuff I found while playing with Amiga UNIX, which is the stuff hosted at atariunix.com. I was able to pull the Motif (v 1.1.1) bits out of the Atari UNIX disk images and get them running on Amiga UNIX. Speaking of old versions of Motif, are the sources for the pre-OpenMotif bits available anywhere? Even if under lock and key for now, I'd be happy knowing they'd been preserved for potential future availability. -- Michael Parson Pflugerville, TX KF5LGQ From rdm at cfcl.com Sun Jan 19 09:22:08 2020 From: rdm at cfcl.com (Rich Morin) Date: Sat, 18 Jan 2020 15:22:08 -0800 Subject: [TUHS] CSRG report TR/4 was in Jim Joyce papers In-Reply-To: References: <0570C6B1-6024-400B-929F-621F8521BE42@cfcl.com> Message-ID: <7411167F-9781-4520-BDD4-08D5A57F2188@cfcl.com> > On Jan 18, 2020, at 14:35, Warner Losh wrote: > > There's about 6 or 7 PWB articles in those proceedings. Do you have copies of those? The box I have from Jim Joyce only has smallish photocopies. I may have some conference proceedings, but not the ones you mention. More generally, I would be wary of scanning and publishing anything that ACM or IEEE claims to own. (sigh) -r From krewat at kilonet.net Sun Jan 19 09:27:38 2020 From: krewat at kilonet.net (Arthur Krewat) Date: Sat, 18 Jan 2020 18:27:38 -0500 Subject: [TUHS] Atari System V media and books? In-Reply-To: References: Message-ID: Wow, never knew Atari was involved in anything like UNIX. Thank you! On 1/18/2020 5:48 PM, Chris Hanson wrote: > I’ve seen the archives of Atari System V Release 4 for the TT030, and the scanned user and developer manuals. Has anything else been preserved, e.g. the installation tapes and any other manuals? > > Is there even a full accounting of what was in the box and what shipped afterwards (patches etc.)? > > -- Chris > > > From tytso at mit.edu Sun Jan 19 12:49:00 2020 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Sat, 18 Jan 2020 21:49:00 -0500 Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") In-Reply-To: <20200118041913.GB67053@eureka.lemis.com> References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> Message-ID: <20200119024900.GA15860@mit.edu> On Sat, Jan 18, 2020 at 03:19:13PM +1100, Greg 'groggy' Lehey wrote: > On the other hand, Bill did write the articles in Dr. Dobbs Journal, > which started in January 1991, so my best guess is that Linus just > wasn't informed about the developments. I don't believe that to be correct. "Porting Unix to the 386: Missing Pieces, Part 1", by William Frederick Jolitz and Lynne Greer Jolitz, was published in the May 1992 issue of Dr. Dobbs Journal. https://www.drdobbs.com/architecture-and-design/porting-unix-to-the-386-missing-pieces-p/184408764 - Ted From grog at lemis.com Sun Jan 19 13:12:25 2020 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Sun, 19 Jan 2020 14:12:25 +1100 Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") In-Reply-To: <20200119024900.GA15860@mit.edu> References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu> Message-ID: <20200119031225.GI67053@eureka.lemis.com> On Saturday, 18 January 2020 at 21:49:00 -0500, Theodore Y. Ts'o wrote: > On Sat, Jan 18, 2020 at 03:19:13PM +1100, Greg 'groggy' Lehey wrote: >> On the other hand, Bill did write the articles in Dr. Dobbs Journal, >> which started in January 1991, so my best guess is that Linus just >> wasn't informed about the developments. > > I don't believe that to be correct. "Porting Unix to the 386: Missing > Pieces, Part 1", by William Frederick Jolitz and Lynne Greer Jolitz, > was published in the May 1992 issue of Dr. Dobbs Journal. > > https://www.drdobbs.com/architecture-and-design/porting-unix-to-the-386-missing-pieces-p/184408764 That appears to be a different pair of articles. My quotation was from Wikipedia, which I believe to be correct I was working in the USA in those days, and I saw the magazine in a bookshop in Austin TX. I stopped working there in December 1991. Unfortunately I wasn't very interested at the time ("who cares about BSD?"). Check the references in the Wikipedia article. Unfortunately the Dr. Dobbs site can't find them. May 1992 was significantly after the first release of 386BSD in March 1992. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From wkt at tuhs.org Sun Jan 19 13:47:21 2020 From: wkt at tuhs.org (Warren Toomey) Date: Sun, 19 Jan 2020 13:47:21 +1000 Subject: [TUHS] Early Linux and BSD In-Reply-To: <20200119031225.GI67053@eureka.lemis.com> References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com> Message-ID: <20200119034721.GA28096@minnie.tuhs.org> On Sun, Jan 19, 2020 at 02:12:25PM +1100, Greg 'groggy' Lehey wrote: > May 1992 was significantly after the first release of 386BSD in March > 1992. https://dl.acm.org/doi/abs/10.5555/119491.121544 shows: Dr. Dobb's Journal Vol. 16, No. 8 "The basic kernel: overview and initialization" Authors: William Frederick Jolitz, Lynne Greer Jolitz Publication: Dr. Dobb's Journal June 1991 Cheers, Warren From grog at lemis.com Sun Jan 19 13:51:32 2020 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Sun, 19 Jan 2020 14:51:32 +1100 Subject: [TUHS] Early Linux and BSD In-Reply-To: <20200119034721.GA28096@minnie.tuhs.org> References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com> <20200119034721.GA28096@minnie.tuhs.org> Message-ID: <20200119035132.GJ67053@eureka.lemis.com> On Sunday, 19 January 2020 at 13:47:21 +1000, Warren Toomey wrote: > On Sun, Jan 19, 2020 at 02:12:25PM +1100, Greg 'groggy' Lehey wrote: >> May 1992 was significantly after the first release of 386BSD in March >> 1992. > > https://dl.acm.org/doi/abs/10.5555/119491.121544 shows: > > Dr. Dobb's Journal Vol. 16, No. 8 > "The basic kernel: overview and initialization" > Authors: William Frederick Jolitz, Lynne Greer Jolitz > Publication: Dr. Dobb's Journal June 1991 Yes, that's one of the articles referenced in the references on the WP page, specifically https://en.wikipedia.org/wiki/386BSD#Further_reading. This one was the 9th of 18 articles, which ran from January 1991 to July 1992. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From grog at lemis.com Sun Jan 19 13:58:08 2020 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Sun, 19 Jan 2020 14:58:08 +1100 Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") In-Reply-To: <20200119031225.GI67053@eureka.lemis.com> References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com> Message-ID: <20200119035808.GK67053@eureka.lemis.com> On Sunday, 19 January 2020 at 14:12:25 +1100, Greg 'groggy' Lehey wrote: > On Saturday, 18 January 2020 at 21:49:00 -0500, Theodore Y. Ts'o wrote: >> >> I don't believe that to be correct. "Porting Unix to the 386: Missing >> Pieces, Part 1", by William Frederick Jolitz and Lynne Greer Jolitz, >> was published in the May 1992 issue of Dr. Dobbs Journal. >> >> https://www.drdobbs.com/architecture-and-design/porting-unix-to-the-386-missing-pieces-p/184408764 > > That appears to be a different pair of articles. Sorry, I was wrong. That particular article was number 16 of the 18 part series, as shown at https://en.wikipedia.org/wiki/386BSD#Further_reading. It does raise the question why the Dr Dobb's search engine didn't find any of them. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From kevin.bowling at kev009.com Sun Jan 19 19:33:04 2020 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Sun, 19 Jan 2020 02:33:04 -0700 Subject: [TUHS] "What UNIX Cost Us" In-Reply-To: <20200118203422.2c7o_%steffen@sdaoden.eu> References: <5A5107E4-06AD-4C2B-B590-15C17B301D44@cfcl.com> <20200118203422.2c7o_%steffen@sdaoden.eu> Message-ID: Apropos of nothing, I've noticed there are a handful of systems charlatans that fast talk, relish in condencention, and make lame humor to try to appeal to the unlearned (because systems has become fairly esoteric in the expanding industry) frequenting the conference tracks. I guess everyone is supposed to be impressed. Cool. IMO not worth this list's time. On Sat, Jan 18, 2020 at 1:35 PM Steffen Nurpmeso wrote: > > Rich Morin wrote in <5A5107E4-06AD-4C2B-B590-15C17B301D44 at cfcl.com>: > |FWIW, I found this talk to be quite amusing and interesting. > | > |"What UNIX Cost Us" - Benno Rice (LCA 2020) > |https://www.youtube.com/watch?v=9-IWMbJXoLM > > That is the one who mutilated the FreeBSD fortune program no? > (Despite it saying > > The potentially offensive fortunes are installed by default on FreeBSD > systems. If you're absolutely, *positively*, without-a-shadow-of-a-doubt > sure that your user community goes berzerk/sues your pants off/drops dead > upon reading one of them, edit the Makefile in the subdirectory datfiles, > and do "make all install".) > > Nothing but a hollow lie ever since! > > --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) From katolaz at freaknet.org Sun Jan 19 20:29:37 2020 From: katolaz at freaknet.org (Vincenzo Nicosia) Date: Sun, 19 Jan 2020 11:29:37 +0100 Subject: [TUHS] "What UNIX Cost Us" In-Reply-To: <5A5107E4-06AD-4C2B-B590-15C17B301D44@cfcl.com> References: <5A5107E4-06AD-4C2B-B590-15C17B301D44@cfcl.com> Message-ID: <20200119102937.3s2hwl3ziupa7ese@unixfarts.net> On Sat, Jan 18, 2020 at 11:27:39AM -0800, Rich Morin wrote: > FWIW, I found this talk to be quite amusing and interesting. > > "What UNIX Cost Us" - Benno Rice (LCA 2020) > https://www.youtube.com/watch?v=9-IWMbJXoLM > ...which is along the same lines of the talk the same guy gave about systemd and why everybody should like it. The message is simple: we just want to run our shiny MacBooks and we don't understand Unix anyway, so we'd better get rid of it and move on. A flawed analysis that obviously leads to flawed conclusions. From coppero1237 at gmail.com Sun Jan 19 20:46:00 2020 From: coppero1237 at gmail.com (Tyler Adams) Date: Sun, 19 Jan 2020 12:46:00 +0200 Subject: [TUHS] "What UNIX Cost Us" In-Reply-To: <20200119102937.3s2hwl3ziupa7ese@unixfarts.net> References: <5A5107E4-06AD-4C2B-B590-15C17B301D44@cfcl.com> <20200119102937.3s2hwl3ziupa7ese@unixfarts.net> Message-ID: His example of the USB driver was pretty silly. The unix code even *looked* cleaner and straightforward compared to the convoluted windows/mac messes, but he's mad because he had to figure out a *filepath*. What!? Tyler On Sun, Jan 19, 2020 at 12:37 PM Vincenzo Nicosia wrote: > On Sat, Jan 18, 2020 at 11:27:39AM -0800, Rich Morin wrote: > > FWIW, I found this talk to be quite amusing and interesting. > > > > "What UNIX Cost Us" - Benno Rice (LCA 2020) > > https://www.youtube.com/watch?v=9-IWMbJXoLM > > > > ...which is along the same lines of the talk the same guy gave about > systemd and why everybody should like it. The message is simple: we > just want to run our shiny MacBooks and we don't understand Unix > anyway, so we'd better get rid of it and move on. > > A flawed analysis that obviously leads to flawed conclusions. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Sun Jan 19 23:25:51 2020 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Sun, 19 Jan 2020 08:25:51 -0500 Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") In-Reply-To: <20200119035808.GK67053@eureka.lemis.com> References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com> <20200119035808.GK67053@eureka.lemis.com> Message-ID: <20200119132551.GC15860@mit.edu> On Sun, Jan 19, 2020 at 02:58:08PM +1100, Greg 'groggy' Lehey wrote: > > Sorry, I was wrong. That particular article was number 16 of the 18 > part series, as shown at > https://en.wikipedia.org/wiki/386BSD#Further_reading. It does raise > the question why the Dr Dobb's search engine didn't find any of them. Out of curiosity, did the articles contain download information for a bootable copy of 386BSD? - Ted From clemc at ccc.com Sun Jan 19 23:48:56 2020 From: clemc at ccc.com (Clem Cole) Date: Sun, 19 Jan 2020 08:48:56 -0500 Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") In-Reply-To: <20200119132551.GC15860@mit.edu> References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com> <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu> Message-ID: I don't remember, to be honest, I don't think so. When it first was released which was before Linus's famous announcement, the ftp site was from ucbvax and any UCB licensee that asked for got sent a copy of the URL but you had to ask for it. It was not a well kept secret. When the BSDi / UCB vs ATT came later, as Larry said a lot of us who were primarily driven by wanting a 'real unix' for the 386 thought it was about copyright and that's when we looked at Linux. Then it came out that was a TS suit and many of us switched back because Linux lacked networking and X11 On Sun, Jan 19, 2020 at 8:26 AM Theodore Y. Ts'o wrote: > On Sun, Jan 19, 2020 at 02:58:08PM +1100, Greg 'groggy' Lehey wrote: > > > > Sorry, I was wrong. That particular article was number 16 of the 18 > > part series, as shown at > > https://en.wikipedia.org/wiki/386BSD#Further_reading. It does raise > > the question why the Dr Dobb's search engine didn't find any of them. > > Out of curiosity, did the articles contain download information for a > bootable copy of 386BSD? > > - Ted > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Mon Jan 20 00:17:04 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 19 Jan 2020 09:17:04 -0500 (EST) Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") Message-ID: <20200119141704.983E918C07B@mercury.lcs.mit.edu> > From: Greg 'groggy' Lehey > Unfortunately the Dr. Dobbs site can't find them. > 18 articles, which ran from January 1991 to July 1992. If you search for "Jolitz", they almost all turn up: https://www.drdobbs.com/open-source/porting-unix-to-the-386-a-practical-appr/184408470 https://www.drdobbs.com/open-source/porting-unix-to-the-386-three-initial-pc/184408496 https://www.drdobbs.com/cpp/porting-unix-to-the-386-the-standalone-s/184408513 https://www.drdobbs.com/open-source/porting-unix-to-the-386-language-tools-c/184408529 https://www.drdobbs.com/porting-unix-to-the-386-the-initial-root/184408547 https://www.drdobbs.com/porting-unix-to-the-386-research-the-co/184408566 https://www.drdobbs.com/parallel/porting-unix-to-the-386-a-stripped-down/184408583 https://www.drdobbs.com/open-source/porting-unix-to-the-386-the-basic-kernel/184408600 https://www.drdobbs.com/porting-unix-to-the-386-the-basic-kernel/184408617 https://www.drdobbs.com/porting-unix-to-the-386-the-basic-kernel/184408637 https://www.drdobbs.com/open-source/porting-unix-to-the-386-the-basic-kernel/184408655 https://www.drdobbs.com/architecture-and-design/porting-unix-to-the-386-device-drivers/184408710 https://www.drdobbs.com/embedded-systems/porting-unix-to-the-386-device-drivers/184408727 https://www.drdobbs.com/architecture-and-design/porting-unix-to-the-386-device-drivers/184408747 https://www.drdobbs.com/architecture-and-design/porting-unix-to-the-386-missing-pieces-p/184408764 https://www.drdobbs.com/architecture-and-design/porting-unix-to-the-386-missing-pieces-i/184408782 https://www.drdobbs.com/porting-unix-to-the-386-the-final-step/184408800 They're not totally open access; you have to register with DD to get all of them. However, while looking for something else (below), I did find this: https://www.386bsd.org/releases which appear to be the same as the above. One of the items listed in WP, "Copyright, Copyleft, and Competitive Advantage" (Apr/1991) wasn't in the search results (the "Editorial" at the right point in the search results wasn't it, alas). A Web search didn't turn it up either. Since it's not in the 'releases' page, it might not really be part of the series? Noel From jnc at mercury.lcs.mit.edu Mon Jan 20 02:05:51 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 19 Jan 2020 11:05:51 -0500 (EST) Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") Message-ID: <20200119160551.6A1D818C079@mercury.lcs.mit.edu> > If you search for "Jolitz" Oh, I meant in the DDJ search box, not a general Web search. > One of the items listed in WP, "Copyright, Copyleft, and Competitive > Advantage" (Apr/1991) wasn't in the search results .. Since it's not in > the 'releases' page, it might not really be part of the series? Also, the last article in the series ("The Final Step") says the series was 17 articles long, not the 18 you get if you include "Copyright". Noel From imp at bsdimp.com Mon Jan 20 02:33:23 2020 From: imp at bsdimp.com (Warner Losh) Date: Sun, 19 Jan 2020 09:33:23 -0700 Subject: [TUHS] "What UNIX Cost Us" In-Reply-To: References: <5A5107E4-06AD-4C2B-B590-15C17B301D44@cfcl.com> <20200119102937.3s2hwl3ziupa7ese@unixfarts.net> Message-ID: Benno's talks (systemd and this one) weren't wrong. Systemd *is* a dumpster fire. It has a lot of cool ideas, but is coded by someone that has poor listening skills and is more stubborn than he's technically competent. It's had a crapton of severe security bugs in it. It's given us abominations like eth4156 as a NIC name. It doesn't like it when you & a job and log out for Pete's sake. It's a total mess that breaks everything to try to push the state of the art. Beno's talk on it may have been a little over the top, but he's not wrong about much of his criticism. Systemd has swung too far from the do one thing and do it well philosophy, admittedly in ways that are ham-fisted and don't necessarily mean that it's philosophically wrong, that it shows at least some of thee wisdom of simplicity. Benno's Unix talk is similar. He's not wrong. The everything is a file paradigm has issues. On Sun, Jan 19, 2020 at 3:47 AM Tyler Adams wrote: > His example of the USB driver was pretty silly. The unix code even > *looked* cleaner and straightforward compared to the convoluted > windows/mac messes, but he's mad because he had to figure out a *filepath*. > What!? > Figure a dozen file paths out, cat the right thing to them so other files show up and then you can do the same thing again? That's not a sane interface. Everything isn't a file. We've known this since the 70's. The first NCP/TCP stacks were terrible in this way. You opened /dev/net/london. And while that sounds cool, it means you have to have some kind of name lookup in kernel which isn't a directory lookup. You either need a userland daemon to do the work and sleep, or you need to do crazy things like that in the kernel. And there was no really good way to do what we do with select, poll, kqueue or the like. And trying to do really high end, high data rate stuff with read/write is inefficient. At Netflix we use sendfile for our stuff. It's one of the least unixy things in the kernel. It reads from a file, then TLS encrypts the file and sends it out the socket. This means state has to be carefully managed with some setup in userland before the handoff. The other non-unixy thing is that it's all non blocking. sendfile asks for a set of pages from a file. When they are ready, it gets a callback to schedule encryption, and when that fires it's scheduled to the NIC for transmission and either retransmission or freeing up depending on the ACKs that come back. At ~190Gbps, this isn't something one can do with the normal Unix interfaces, which was the point of his talk. He's not wrong, but his examples could use some work. The real world is messy, and often requires complexity. Going too simple for simplicity's sake is just as bad as going too complicated for complexity's sake. A proper balance is needed. And he's not wrong to make that point. Warner P.S. complaining about Benno's involvement in cleaning up FreeBSD's fortune in response to his talk is lame and puerile. Totally off topic and typical of the stupid and ill-informed attacks that he attracted around the code of conduct stuff by jerks that had no stake in the FreeeBSD community, but instead wanted to fight for their absolute right to be self-absorbed jerks without consequences. It totally burned him out, and the FreeBSD community lost a contributing member because of the grief he got. It's unbecoming to see it on this list. > Tyler > > > On Sun, Jan 19, 2020 at 12:37 PM Vincenzo Nicosia > wrote: > >> On Sat, Jan 18, 2020 at 11:27:39AM -0800, Rich Morin wrote: >> > FWIW, I found this talk to be quite amusing and interesting. >> > >> > "What UNIX Cost Us" - Benno Rice (LCA 2020) >> > https://www.youtube.com/watch?v=9-IWMbJXoLM >> > >> >> ...which is along the same lines of the talk the same guy gave about >> systemd and why everybody should like it. The message is simple: we >> just want to run our shiny MacBooks and we don't understand Unix >> anyway, so we'd better get rid of it and move on. >> >> A flawed analysis that obviously leads to flawed conclusions. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdm at cfcl.com Mon Jan 20 03:40:35 2020 From: rdm at cfcl.com (Rich Morin) Date: Sun, 19 Jan 2020 09:40:35 -0800 Subject: [TUHS] CSRG report TR/3 (IPC Architecture) In-Reply-To: References: Message-ID: I think the following may have been missed, because folks thought it was more discussion about the CSRG TR/4. Read on... > On Jan 18, 2020, at 01:08, Paul Ruizendaal wrote: > > At the bottom of page 6 TR/4 references TR/3: > > A more complete description of the motivation of the IPC architecture > described here, measurements of a prototype implementation, comparisons > with other work and a complete bibliography are given in CSRG TR/3: “An IPC > Architecture for UNIX”. This was also in the box: about 50 pages, including a four-page bibliography. An Architecture for Interprocess Communication in UNIX* -- DRAFT of June 22, 1981 -- William Joy and Robert Fabry Paul sez: > Before yesterday I did not know that TR/3 existed and in my (arguable) view > it is even a bigger find than TR/4, as it gives great insight how design > trade-offs were perceived back in 1981. Again, I scanned the paper and then Paul aggregated the scans into a single PDF. It should be available here: http://cfcl.com/private/CSRG_TR_3.pdf -r From kevin.bowling at kev009.com Mon Jan 20 04:16:01 2020 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Sun, 19 Jan 2020 11:16:01 -0700 Subject: [TUHS] "What UNIX Cost Us" In-Reply-To: References: <5A5107E4-06AD-4C2B-B590-15C17B301D44@cfcl.com> <20200119102937.3s2hwl3ziupa7ese@unixfarts.net> Message-ID: On Sun, Jan 19, 2020 at 9:35 AM Warner Losh wrote: > > Benno's talks (systemd and this one) weren't wrong. Systemd *is* a dumpster fire. It has a lot of cool ideas, but is coded by someone that has poor listening skills and is more stubborn than he's technically competent. It's had a crapton of severe security bugs in it. It's given us abominations like eth4156 as a NIC name. It doesn't like it when you & a job and log out for Pete's sake. It's a total mess that breaks everything to try to push the state of the art. Beno's talk on it may have been a little over the top, but he's not wrong about much of his criticism. Systemd has swung too far from the do one thing and do it well philosophy, admittedly in ways that are ham-fisted and don't necessarily mean that it's philosophically wrong, that it shows at least some of thee wisdom of simplicity. > > Benno's Unix talk is similar. He's not wrong. The everything is a file paradigm has issues. The problem is this talk is just self aggrandizement at large. It would have been cute in the year 2000. It's pretty ridiculous cherry-picking hoping to target an unknowing audience in 2020. I can alt/option+space on my FreeBSD desktop, open a monitor, and kill a process in a GUI with a top right search box the exact same as OS X. Cool. Modern Linux distros don't even use X11 (except nested as OS X in case of legacy application). The crude APIs (he calls out Linux and Windows and BSD and C) are not secret. I would be surprised if Linus himself didn't agree that a lot of the Linux interfaces suck. There's just an issue of backwards compatibility, and you know, doing some work instead of fishing for social points at a conference. Android has deviated significantly from Linux. Linux from UNIX. Basically nobody at a Linux conference is blindly following the UNIX philosophy. This message makes little sense to that crowd in absolute terms. The kindest critique I can give is: fighting the last war. > On Sun, Jan 19, 2020 at 3:47 AM Tyler Adams wrote: >> >> His example of the USB driver was pretty silly. The unix code even looked cleaner and straightforward compared to the convoluted windows/mac messes, but he's mad because he had to figure out a filepath. What!? > > > Figure a dozen file paths out, cat the right thing to them so other files show up and then you can do the same thing again? That's not a sane interface. Everything isn't a file. We've known this since the 70's. The first NCP/TCP stacks were terrible in this way. You opened /dev/net/london. And while that sounds cool, it means you have to have some kind of name lookup in kernel which isn't a directory lookup. You either need a userland daemon to do the work and sleep, or you need to do crazy things like that in the kernel. And there was no really good way to do what we do with select, poll, kqueue or the like. And trying to do really high end, high data rate stuff with read/write is inefficient. > > At Netflix we use sendfile for our stuff. It's one of the least unixy things in the kernel. It reads from a file, then TLS encrypts the file and sends it out the socket. This means state has to be carefully managed with some setup in userland before the handoff. The other non-unixy thing is that it's all non blocking. sendfile asks for a set of pages from a file. When they are ready, it gets a callback to schedule encryption, and when that fires it's scheduled to the NIC for transmission and either retransmission or freeing up depending on the ACKs that come back. At ~190Gbps, this isn't something one can do with the normal Unix interfaces, which was the point of his talk. He's not wrong, but his examples could use some work. > > The real world is messy, and often requires complexity. Going too simple for simplicity's sake is just as bad as going too complicated for complexity's sake. A proper balance is needed. And he's not wrong to make that point. > > Warner > > P.S. complaining about Benno's involvement in cleaning up FreeBSD's fortune in response to his talk is lame and puerile. Totally off topic and typical of the stupid and ill-informed attacks that he attracted around the code of conduct stuff by jerks that had no stake in the FreeeBSD community, but instead wanted to fight for their absolute right to be self-absorbed jerks without consequences. It totally burned him out, and the FreeBSD community lost a contributing member because of the grief he got. It's unbecoming to see it on this list. > >> >> Tyler >> >> >> On Sun, Jan 19, 2020 at 12:37 PM Vincenzo Nicosia wrote: >>> >>> On Sat, Jan 18, 2020 at 11:27:39AM -0800, Rich Morin wrote: >>> > FWIW, I found this talk to be quite amusing and interesting. >>> > >>> > "What UNIX Cost Us" - Benno Rice (LCA 2020) >>> > https://www.youtube.com/watch?v=9-IWMbJXoLM >>> > >>> >>> ...which is along the same lines of the talk the same guy gave about >>> systemd and why everybody should like it. The message is simple: we >>> just want to run our shiny MacBooks and we don't understand Unix >>> anyway, so we'd better get rid of it and move on. >>> >>> A flawed analysis that obviously leads to flawed conclusions. >>> From athornton at gmail.com Mon Jan 20 05:45:39 2020 From: athornton at gmail.com (Adam Thornton) Date: Sun, 19 Jan 2020 12:45:39 -0700 Subject: [TUHS] "What UNIX Cost Us" In-Reply-To: References: <5A5107E4-06AD-4C2B-B590-15C17B301D44@cfcl.com> <20200119102937.3s2hwl3ziupa7ese@unixfarts.net> Message-ID: <60F817C2-3C85-42CF-8C3F-7BE8EDBA551E@gmail.com> > On Jan 19, 2020, at 9:33 AM, Warner Losh wrote: > > Benno's talks (systemd and this one) weren't wrong. Systemd *is* a dumpster fire. It has a lot of cool ideas, but is coded by someone that has poor listening skills and is more stubborn than he's technically competent. It's had a crapton of severe security bugs in it. It's given us abominations like eth4156 as a NIC name. It doesn't like it when you & a job and log out for Pete's sake. It's a total mess that breaks everything to try to push the state of the art. Hoo boy. I just had this argument on one of the Slacks I’m on. > Beno's talk on it may have been a little over the top, but he's not wrong about much of his criticism. Systemd has swung too far from the do one thing and do it well philosophy, admittedly in ways that are ham-fisted and don't necessarily mean that it's philosophically wrong, that it shows at least some of thee wisdom of simplicity. No, it’s philosophically wrong. I will grant that there is a problem there that needs solving. Let’s look at BSD rc and SysVinit; they’re both extremely difficult to automate installing and uninstalling services. SysVInit works better than rc in that regard, but they’re both kind of crappy. Let’s look at the things that suck about SysVInit: 1: no actual dependency graphs. Sure, there was a whole framework of magic comments to sorta-kinda-glue one in. Didn’t work very well. 2: tons of shell ceremony around start/stop/restart What you want in an init system is: First and foremost, a process manager, that acts as a signal handler of last resort. * It would be nice if it _can_ and _usually does_ run as PID 1, but doesn’t insist on it. * Has a firm notion of “this service depends on _that_ service” and can sequence startup and shutdown appropriately. * Has a declarative syntax that lets you configure most services with just a little declarative text, probably with an escape hatch for more complicated services Here’s what you don’t want _in your init system_: A new approach to logging that puts your logs in a human-unreadable binary format. A system-wide event bus. This is actually quite a good idea, but it doesn’t need to be part of the init system. A sound manager. You get the idea. Yeah, SysVInit needed to be superseded. Runit, Daemontools, Upstart all had reasonable approaches. But the devouring hippo of SystemD won, mostly because Lennart worked at Red Hat. And it’s a terrible idea because it tangles all these things together. It’s also a terrible idea because your init system should have goals other than time from pressing the power button to getting a login prompt on Lennart’s laptop, but I digress. > > Figure a dozen file paths out, cat the right thing to them so other files show up and then you can do the same thing again? That's not a sane interface. Everything isn't a file. […] To be fair: BSD sockets are not pretty, and they’re not elegant. They won, and SysV Streams were worse in a lot of ways, but I still suspect there was some way of doing a TCP/IP stack that seemed more Unixy, without (maybe) needing DNS (or a service locator) in a sidecar userland process…but as soon as you start thinking about it, yeah, it gets gross. > At Netflix we use sendfile for our stuff. It's one of the least unixy things in the kernel. It reads from a file, then TLS encrypts the file and sends it out the socket. This means state has to be carefully managed with some setup in userland before the handoff. The other non-unixy thing is that it's all non blocking. sendfile asks for a set of pages from a file. When they are ready, it gets a callback to schedule encryption, and when that fires it's scheduled to the NIC for transmission and either retransmission or freeing up depending on the ACKs that come back. At ~190Gbps, this isn't something one can do with the normal Unix interfaces, which was the point of his talk. He's not wrong, but his examples could use some work. And here we see Unix as a victim of its own success. It’s pretty damn weird, when you think about it, that we’re using a half-century-old typesetting system to power both the front and back ends of sending cat pictures and porn videos in real-time all over the planet all the time. This also speaks to https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf (mentioned here several months ago). The fork()/exec() model is great in a single-threaded pipeline-processing model. But, yeah, it’s totally true that it (and read()/write()) is not the best thing for writing user-facing nonblocking GUIs. > The real world is messy, and often requires complexity. Going too simple for simplicity's sake is just as bad as going too complicated for complexity's sake. A proper balance is needed. And he's not wrong to make that point. That said: Linux now has _way_ too many syscalls. I would be flabbergasted if the rarely-used ones are not crawling with exploitable bugs. I am surprised that Google hasn’t done more with fuchsia + gvisor (well, maybe they have but haven’t showed us yet). Gvisor is a fascinating experiment in worse-is-better, in that, no, it makes no attempt to replace _all_ the Linux system calls, just the ones that _the programs you really want to run_ use. Things do grow cruft over time. And things change over time. Containers are absolutely essential to what I’m doing these days. They were not ten years ago. Alpine is going there (in terms of a minimal container-focused support system (== OS layer), but clearly the more-right thing would be something like gvisor-plus-something-like-fuschia: my container only contains _code_ for the syscalls my application actually uses. Can’t exploit what isn’t there. This also hits the “People shouldn’t be using C in 2020” argument. But _that_ in turn is less about C not providing modern strong typing features and letting you play fast and loose with pointers and making you do your own memory management, and more about: your computer is really, really not a PDP-11 anymore. A language that provides the abstraction of a simple in-order execution stream is _lying_ to you. The problem with that is that thinking about something as bizarrely complex as modern CPUs and writing software to exploit the way they actually work is _really really hard_. Wow, that was a ramble. Anyway: Benno’s not wrong. But everything’s historically contingent, right? We’ve got a half-century of C and a half-century of a typesetting system that got too big for its britches, that’s now running, basically, the entire underpinnings of the 21st century…I was going to say “economy” but really, it’s “world.” Adam From ksspiers at gmail.com Mon Jan 20 06:00:27 2020 From: ksspiers at gmail.com (Kathryn Spiers) Date: Sun, 19 Jan 2020 12:00:27 -0800 Subject: [TUHS] "What UNIX Cost Us" In-Reply-To: <20200118203422.2c7o_%steffen@sdaoden.eu> References: <5A5107E4-06AD-4C2B-B590-15C17B301D44@cfcl.com> <20200118203422.2c7o_%steffen@sdaoden.eu> Message-ID: On Sat, Jan 18, 2020, 12:35 Steffen Nurpmeso wrote: > Rich Morin wrote in <5A5107E4-06AD-4C2B-B590-15C17B301D44 at cfcl.com>: > |FWIW, I found this talk to be quite amusing and interesting. > | > |"What UNIX Cost Us" - Benno Rice (LCA 2020) > |https://www.youtube.com/watch?v=9-IWMbJXoLM > > That is the one who mutilated the FreeBSD fortune program no? > (Despite it saying > > The potentially offensive fortunes are installed by default on FreeBSD > systems. If you're absolutely, *positively*, without-a-shadow-of-a-doubt > sure that your user community goes berzerk/sues your pants off/drops dead > upon reading one of them, edit the Makefile in the subdirectory datfiles, > and do "make all install".) > > Nothing but a hollow lie ever since! > > --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) > Or you could remove the offensive fortunes and make the default more friendly for everyone... Probably best not to re-litigate that change on this thread though. -K > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cym224 at gmail.com Mon Jan 20 06:49:28 2020 From: cym224 at gmail.com (Nemo Nusquam) Date: Sun, 19 Jan 2020 15:49:28 -0500 Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") In-Reply-To: <20200119141704.983E918C07B@mercury.lcs.mit.edu> References: <20200119141704.983E918C07B@mercury.lcs.mit.edu> Message-ID: On 01/19/20 09:17, Noel Chiappa wrote: > [...] > One of the items listed in WP, "Copyright, Copyleft, and Competitive > Advantage" (Apr/1991) wasn't in the search results (the "Editorial" at the right point in the search results wasn't it, alas). A Web search didn't turn it up either. Since it's not in the 'releases' page, it might not really be part of the series? > > Noel I subscribed to DDJ at the time but all my issues are in storage. If important, I could set aside some time next week to spelunk. N. From gtaylor at tnetconsulting.net Mon Jan 20 07:22:29 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Sun, 19 Jan 2020 14:22:29 -0700 Subject: [TUHS] Shell Level... Message-ID: Hi, Have you ever used shell level, $SHLVL, in your weekly ~> daily use of Unix? I had largely dismissed it until a recent conversation in a newsgroup. I learned that shelling out of programs also increments the shell level. I.e. :shell or :!/bin/sh in vim. Someone also mentioned quickly starting a new sub-shell from the current shell for quick transient tasks, i.e. dc / bc, mount / cp / unmount, {,r,s}cp, etc., in an existing terminal window to avoid cluttering that first terminals history with the transient commands. That got me to wondering if there were other uses for shell level ($SHLVL). Hence my question. This is more about using (contemporary) shells on Unix, than it is about Unix history. But I suspect that TUHS is one of the best places to find the most people that are likely to know about shell level. Feel free to reply to COFF if it would be better there. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From pnr at planet.nl Mon Jan 20 08:11:10 2020 From: pnr at planet.nl (Paul Ruizendaal) Date: Sun, 19 Jan 2020 23:11:10 +0100 Subject: [TUHS] "What Unix cost us" and Unix in 1981 Message-ID: <8573E48C-FC18-49D8-BA1A-75266EBF26CA@planet.nl> I thought Benno Rice’s argument a bit unorganized and ultimately unconvincing, but I think the underlying point that we should from time to time step back a bit and review fundamentals has some merit. Unfortunately he does not distinguish much between a poor concept and a poor implementation. For example, what does “everything is a file” mean in Unix? - Devices and files are accessed through the same small API? - All I/O is through unstructured byte streams? - I/O is accessed via a single unified name space? etc. Once that is clear, how can the concept then best be applied to USB devices? Or: is there a fundamental difference between windows-style completion ports and completion signals? Many of the underlying questions have been considered in the past, with carefully laid out arguments in various papers. In my view it is worthwhile to go back to these papers and see how the arguments pro and contra various approaches were weighed then and considering if the same still holds true today. Interestingly, several points that Benno touches upon in his talk were also the topic of debate when Unix was transitioning to a 32 bits address space and incorporating networking in the early 80’s, as the TR/4 and TR/3 papers show. Of course, the system that CSRG delivered is different from the ambitions expressed in these papers and for sure opinions on the best choices differed as much back then as they will now - and that makes for an interesting discussion. From wkt at tuhs.org Mon Jan 20 08:15:54 2020 From: wkt at tuhs.org (Warren Toomey) Date: Mon, 20 Jan 2020 08:15:54 +1000 Subject: [TUHS] Cctalk mail list is back up Message-ID: Just thought you should know. http://www.classiccmp.org/pipermail/cctalk/ Cheers, Warren -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.paulsen at firemail.de Mon Jan 20 09:21:07 2020 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Mon, 20 Jan 2020 00:21:07 +0100 Subject: [TUHS] Shell Level... In-Reply-To: References: Message-ID: >Have you ever used shell level, $SHLVL, in your weekly ~> daily use of Unix? Its part of my default $PS1 since > 30 years when I anticipated' it under SysV4/ksh because of my frequent use of sub-shells then. Luckily its a bash build-in . Thanks RMS/Chet. From woods at robohack.ca Mon Jan 20 13:32:57 2020 From: woods at robohack.ca (Greg A. Woods) Date: Sun, 19 Jan 2020 19:32:57 -0800 Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") In-Reply-To: <20200119132551.GC15860@mit.edu> References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com> <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu> Message-ID: At Sun, 19 Jan 2020 08:25:51 -0500, "Theodore Y. Ts'o" wrote: Subject: Re: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") > > On Sun, Jan 19, 2020 at 02:58:08PM +1100, Greg 'groggy' Lehey wrote: > > > > Sorry, I was wrong. That particular article was number 16 of the 18 > > part series, as shown at > > https://en.wikipedia.org/wiki/386BSD#Further_reading. It does raise > > the question why the Dr Dobb's search engine didn't find any of them. > > Out of curiosity, did the articles contain download information for a > bootable copy of 386BSD? Yes, they did: https://www.drdobbs.com/porting-unix-to-the-386-the-final-step/184408800 See also: http://gunkies.org/wiki/386BSD Also keep in mind that NetBSD started as a set of "net" (as in usenet) patch kits for 386BSD. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From ggm at algebras.org Mon Jan 20 13:51:55 2020 From: ggm at algebras.org (George Michaelson) Date: Mon, 20 Jan 2020 13:51:55 +1000 Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") In-Reply-To: References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com> <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu> Message-ID: It does me no credit, that I initially reacted very badly to 386BSD, and the initial {Net,Free,Open} situation. I found all this "fragmentation" pretty hard to understand. -BSDI felt like it had occupied the space, and I couldn't entirely understand what was going on, or why any of it mattered. I also reacted very badly to the public dirty linen spats around the Jolitz's IPR, and who-did-what to-whom in woodshed, with colonel mustard and the lead pipe. What worried me was the loss of intellectual capital. People I liked online, and respected, seemed to be running to the four winds. Why was something I worked with turning to suck? What I think I missed (didn't understand) was how draining support was for Berkeley, and in the absence of a sugar daddy (Earth Sciences? DOE? IBM?) and loss of contracts like the NSFNet support for BSD-rt (they stopped using PC-Rt as a platform for routing) It was increasingly hard for a teaching and research institution to justify what was going on. Sun spun out of Stanford. MIT was doing the Gui work. Compilers had gone really funny with Gnu and an income stream had evaporated, and a lawsuit was in the offing, and people who hadn't done full on DOTCOM boom vesting suddenly found growing old and not having a 401k at the scale they needed to maintain a wine cellar ... What I also missed is that it stopped innovating. People were innovating in other places, doing things I didn't understand. I totally did NOT get what 8th ed. and Plan9 was on. Drugs I couldn't fathom. Nothing lasts forever. Had you said to me "ha.. VMS is going to die, and Dec is going to die, and Sun is going to fold into Larry Ellisons personal empire" I'd have taken every one of those bets on what turned out to be the loosing side. From nobozo at gmail.com Mon Jan 20 13:59:06 2020 From: nobozo at gmail.com (Jon Forrest) Date: Sun, 19 Jan 2020 19:59:06 -0800 Subject: [TUHS] Early Linux and BSD In-Reply-To: References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com> <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu> Message-ID: <932dc73b-c2f9-a22c-ad20-4b41d23e929e@gmail.com> On 1/19/2020 7:51 PM, George Michaelson wrote: > What I think I missed (didn't understand) was how draining support was > for Berkeley Two of the founders of NetBSD were undergrads who were also members of the Postgres research group that I was a part of. They did NetBSD without any formal support from UC Berkeley. Whether or not this was a good thing is debatable. Jon From meillo at marmaro.de Mon Jan 20 18:15:56 2020 From: meillo at marmaro.de (markus schnalke) Date: Mon, 20 Jan 2020 09:15:56 +0100 Subject: [TUHS] Shell Level... In-Reply-To: References: Message-ID: <1itSE0-5Td-00@marmaro.de> Hoi. [2020-01-19 14:22] Grant Taylor via TUHS > > Have you ever used shell level, $SHLVL, in your weekly ~> daily use of Unix? What's the use of it? The only use of $SHLVL I can think of is the answer to the question if ^D will close the last shell or just a sub shell. I hardly ever ask myself this question. Probably that starts to become relevant when you open sub shells frequently. > Someone also mentioned quickly starting a new sub-shell from the current > shell for quick transient tasks, i.e. dc / bc, mount / cp / unmount, > {,r,s}cp, etc., in an existing terminal window to avoid cluttering that > first terminals history with the transient commands. With tmux or screen at hand, this use case is obsolete for me. (Besides, my shell doesn't know about $SHLVL.) This all pretty much depends on your working habits, of course. For instance, I never use history expansion but search the history frequently, thus additional entries in the shell history are no problem. I rather like to have all shell histories merged into one for having search access to all the commands I executed. This seems to be more of a modern shell usage concept. Job control, OTOH, I use a lot, to suspend the editor, grep for something, resume the editor, and the like. Which seems to be more of an older style usage concept. > That got me to wondering if there were other uses for shell level > ($SHLVL). Hence my question. I'm interested as well, as I've got difficulties imagine these uses. One thing to clarify: Are you looking for uses of the shell variable $SHLVL or for uses of frequent sub shells? meillo From khm at sciops.net Mon Jan 20 18:39:28 2020 From: khm at sciops.net (Kurt H Maier) Date: Mon, 20 Jan 2020 00:39:28 -0800 Subject: [TUHS] Shell Level... In-Reply-To: <1itSE0-5Td-00@marmaro.de> References: <1itSE0-5Td-00@marmaro.de> Message-ID: <20200120083928.GA68939@wopr> On Mon, Jan 20, 2020 at 09:15:56AM +0100, markus schnalke wrote: > Hoi. > > [2020-01-19 14:22] Grant Taylor via TUHS > > > > Have you ever used shell level, $SHLVL, in your weekly ~> daily use of Unix? > > What's the use of it? I have seen it used -- and I do not use it this way myself -- to construct a sort of work batch, where a control script launches many instances of itself, which then inspect $SHLVL to determine that they are subordinates, and process elements of a central work queue. The parent instance would monitor the number of copies of the script in use and launch new subordinates in the case some of them exited for whatever reason. The whole thing felt alien, but it seemed to work. The other, more common use I've seen is to e.g. clear the terminal window on logout (e.g. in .bash_logout when SHLVL=1) but not when exiting any nested shell. It's not POSIX, so I've never relied on it. khm From txomsy at yahoo.es Tue Jan 21 00:59:46 2020 From: txomsy at yahoo.es (Jose R. Valverde) Date: Mon, 20 Jan 2020 15:59:46 +0100 Subject: [TUHS] Screen editors References: <20200120155946.169b39e0.ref@sagittariusa.cnb.csic.es> Message-ID: <20200120155946.169b39e0@sagittariusa.cnb.csic.es> Talking of editors... Once I learned Wordstar in old CP/M (before that it was mostly line editing), and then soon, other editors that supported the Wordstar key combinations, I got hooked on those. Joe is, to date, one of my favorites. On ancient UNIX, my editor of choice was 's' from Software Tools, its main advantage being that it didn't require curses. Then we got VMS and 'eve' and that took over for a while (though I never took advantage of all its power), mostly until I ported 's' and 'joe'. Then came X, and when nedit was released, I was hooked on it. It has been for decades almost the only one that could do block selection 'a la' RAND editor. I have been struggling to continue using it despite it lack of support for UTF, trying various projects spun off nedit, until I recently discovered xnedit, which is an update available on GitHub and is again all I need, with support for UTF8, some minor UI improvements and support for modern fonts. Now, I still use 's' for ancient Unix emulators, 'joe' for the command line and 'xnedit' for X. j -- Scientific Computing Service Solving all your computer needs for Scientific Research. http://bioportal.cnb.csic.es From toby at telegraphics.com.au Tue Jan 21 02:07:01 2020 From: toby at telegraphics.com.au (Toby Thain) Date: Mon, 20 Jan 2020 11:07:01 -0500 Subject: [TUHS] Screen editors In-Reply-To: <20200120155946.169b39e0@sagittariusa.cnb.csic.es> References: <20200120155946.169b39e0.ref@sagittariusa.cnb.csic.es> <20200120155946.169b39e0@sagittariusa.cnb.csic.es> Message-ID: On 2020-01-20 9:59 AM, Jose R. Valverde via TUHS wrote: > Talking of editors... > > Once I learned Wordstar in old CP/M (before that it was mostly line > editing), and then soon, other editors that supported the Wordstar key > combinations, I got hooked on those. Joe is, to date, one of my > favorites. Speaking of WordStar, on CP/M there was also WordMaster, lighter weight, better as a programmer's editor. Not sure who wrote it (but istr it came from the WordStar people?) Adding here for completeness... --T > > On ancient UNIX, my editor of choice was 's' from Software Tools, ... > > Now, I still use 's' for ancient Unix emulators, 'joe' for the > command line and 'xnedit' for X. > > j > From lm at mcvoy.com Tue Jan 21 02:20:08 2020 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 20 Jan 2020 08:20:08 -0800 Subject: [TUHS] Screen editors In-Reply-To: References: <20200120155946.169b39e0.ref@sagittariusa.cnb.csic.es> <20200120155946.169b39e0@sagittariusa.cnb.csic.es> Message-ID: <20200120162008.GE28686@mcvoy.com> On Mon, Jan 20, 2020 at 11:07:01AM -0500, Toby Thain wrote: > On 2020-01-20 9:59 AM, Jose R. Valverde via TUHS wrote: > > Talking of editors... > > > > Once I learned Wordstar in old CP/M (before that it was mostly line > > editing), and then soon, other editors that supported the Wordstar key > > combinations, I got hooked on those. Joe is, to date, one of my > > favorites. > > Speaking of WordStar, on CP/M there was also WordMaster, lighter weight, > better as a programmer's editor. Not sure who wrote it (but istr it came > from the WordStar people?) Adding here for completeness... My memory fu is weak but there was a small editor for CP/M that I liked a lot. Can't remember what it was called but I stole some keybindings from it: map # :.,$ # does from here to the bottom map @ :1,. @ does from top to here Anyone remember that? From ullbeking at andrewnesbit.org Tue Jan 21 03:05:30 2020 From: ullbeking at andrewnesbit.org (U'll Be King of the Stars) Date: Mon, 20 Jan 2020 17:05:30 +0000 Subject: [TUHS] Distributed systems, was: On the origins of Linux - "an academic question" In-Reply-To: References: Message-ID: <6071258e-83f7-da7d-35a1-5f5ece216750@andrewnesbit.org> On 18/01/2020 11:55, Álvaro Jurado wrote: > IBM Watson is not that concept? I don't want to go too off topic but out of all the cloud computing providers I think that IBM Cloud is the nicest in terms of its interface and functionality. Does anybody else think the same? I'm considering investing more of my time and resources into learning about it. It certainly has the most interesting ecosystem. It doesn't make me feel bombarded with information overload in the same way that AWS does[1]. Nevertheless I think it's useful to have at least one AWS EC2 machine if you're working professionally in the field of cloud computing and to know one's way around the UI. It is, after all, the industry standard reference platform in this field. Andrew [1] https://www.lastweekinaws.com is the saving grace that makes the complicated AWS ecosystem understandable to me. -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9 From clemc at ccc.com Tue Jan 21 03:19:25 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 20 Jan 2020 12:19:25 -0500 Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") In-Reply-To: References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com> <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu> Message-ID: On Sun, Jan 19, 2020 at 10:52 PM George Michaelson wrote: > It does me no credit, that I initially reacted very badly to 386BSD, > and the initial {Net,Free,Open} situation. > First, be careful. What we sometimes call 386BSD as a 'release' started just as a port of NET2 to the 386 based 'commodity' hardware platform. The history is that in the late 1970s/early 80s Bill Jolitz was working for Nat Semi and ported BSD 4.1, to a multibus based NS16032 board that NS had built, which was similar to the Stanford University Network (SUN) terminal what had a 68000. He eventually built a 'luggable' using that and updated to the port to 4.2++. He (and Lynn I believe) started a company to sell that hardware/software solution and for whatever reason, it did not really take off. At some point, he got his hands on a 386based PC (Compaq I think) and started to move his port over to that system. A number of people helped him (for instance I did a bunch of the AT/disk controller work as I had access to the WD design documents for another consulting gig I had at the time - Bill mentioned this in the articles BTW). Bill and Lynn's NS16032 and 386 code went back to the CSRG 'masters' - although how and that happened was never completely clear to me. The SCCS deltas tell at least part of the story. Bill managed to make a bootable image that mostly installed on a PC/386 as the minicomputer versions did from the formal release. The ftp area of ucbvax had all of these bootable images available for download such as one for an HP 68K system and I think the DEC VAX and PMAX, the CCG system and a few others IIRC. As I have said in other messages if you were a UCB licensee you had the passwords to look/download from that area. Bill placed that version in the same ftp area. The 386 based port went viral at least with the UCB licensees. (In fact, if Linus had known about it, theoretically he could have used it also. His university was licensee, but as Larry McVoy likes to point, not all the schools were as free with the IP, so I will not go down that rathole). The bottom line is that many people (like me on a Wyse386) started with Bill's original port; including the BSDi founders. When Jolitz and BSDi went separate ways, Jolitiz continued to update the CSRG 386 based tarball (to an extent). One of the issues was there originally was attempt to keep the different architectural versions of BSD in sync ( to a point and NetBSD does yet exist). A number of people were unhappy and the speed, depth *etc*. of the 386 version, most notably Jordan Hubbard and FreeBSD was born. The two biggest issues Jordan wanted to fix, was easier install and a bit wider support for more hardware (again I sent Jordan the changes to FreeBSN 1x for the Wyse and a couple of NCR boxes). The NetBSD project would birth from the original ideals of CSRG and trying to keep everything the same but that's still in the future. > > I found all this "fragmentation" pretty hard to understand. -BSDI felt > like it had occupied the space, and I couldn't entirely understand > what was going on, or why any of it mattered. > See below.... > What I think I missed (didn't understand) was how draining support was > for Berkeley, and in the absence of a sugar daddy > Herein is the issue that many people on the sidelines missed. CRSG was a large project and funded a lot of work at UCB in EECS. It never funded me (I was funded by Tektronix, HP, DEC *et al*), but that project did a fund a number of students. However, at some point CSRG stopped being a research project and started being a support project for DARPA. There was also a good deal of resentment by some groups in EECS that were not getting DARPA funding. I'll not say if that was good or bad but I will say that it did cause great deal consternation at UCB within the department and many people doing more formal research were not happy. In the end, the EECS Department mothers and fathers along with the Dean *et al*, decided to stop/end the CSRG project. Many people who were directly or indirectly working on BSD, like Mary Ann and myself, had graduated and had since left. Bob Kridle had formed Mt. Xinu, Asa Romberger has formed Unisoft, Joy had left/was leaving for Sun, *etc*. So the question remained what to do with CSRG. As to what everyone would do, became every person for her/himself and as we know some of the folks, along with a few folks from the USENIX community formed BSDi. As was noted elsewhere, NetBSD would eventually be formed by volunteers to keep the different ports alive (in fact much of the efforts was from folks not at UCB), but that was still in the offing. Remember, while CSRG itself was not a research project, a lot of people around the world were using the BSD code base for their own research. The whole idea of NetBSD was to create a uniform platform that people could compare things. So, the question of how that was to come about or do any work on BSD if DARPA was not paying the bills, was still an open one. But, the idea that would eventually create FreeBSD, was supporting a pure commodity *solution for day-to-day use, not as a research platform*. [I'll leave off the later OpenBSD/NetBSD fork by Theo here as it has little to do with the question]. BSDi had a similar/same goal of producing something like SunOS/VMS *etc* but supported on commodity hardware. That solution was to sell it and using the revenues from the support contract, be able to pay people to do that work. As I said and in some other messages, it is noted that Bill Jolitz wanted something more FOSS. Truth is BSDi code was 'open source' but it took a $1K license to *get the source from them*. In the end, the real problem was not the infighting between the different BSD camps, but AT&T, who wanted the entire pie. Clearly, their executives saw anything other than their complete control of the UNIX IP as a threat. Hence the court case, the eventually AT&T/Sun relationship *etc*... Your lack of 'sugar daddy,' really comes back to that. There were few people at the time that could pay the bills. Until then DARPA had been it. I do not know if DARPA wanted out or if another group could have been formed that could take over CSRG. I did have discussions with Rob over a beer that at least the thought had crossed the BSDi folks mind, that once started; they would apply for a DARPA contract. At the time had blow up, I was a consultant and I personally was considering what I was going to do next and if they had had a real future, the talks with Rob might have gotten more serious. My wife wanted me to stop being independent if we were to start a family (I would join Locus instead). BTW: I was in an interesting position as I was friends with all of the different sides in the war/original fight. Like Jolitz, I wanted to see what we now call a 'FOSS' release of BSD. But like Rob, I knew it was going to take some revenue stream to make it happen/continue the support. In the end, the AT&T legal mess blew it all up. BSDi ended up failing and Jordan's work stayed around. BTW: what pays for Linux development these days by number of 'committers salary' is Intel (#1), IBM (#2), then a load of other firms including the different distros. But for *any* platform to be successful and actually continue to be used in the market, someone has to pay the salaries of some set of professional programmers to do the work. That said when AT&T injoined BSDi and UCB a lot of people (myself included) started to hack on Linux. But just think if AT&T had actually won the case and courts decided UNIX was allowed to be a trade secret, then Linux and all of the UNIX 'clones' would have been in violation. No matter what flavor of UNIX you like, we are all in debt to UCB and BSDi for settling the IP argument. The court was clear, the >>ideas<< behind UNIX (*a.k.a.* the intellectual property) came from Ken, Dennis and friends at AT&T and *they did own it.* But because of the 1956 consent decree that published the ideas and the moment the ideas were published, we all can now >>use<< them. The provenance of the source code does not relate to the provenance of the idea, so* the source code itself does not define what UNIX is or is not. * I bring this all up in hopes to try to close this rat hole of Linux, *vs*. *BSD. Like editors, we all have our own favorites. That's cool, we don't want one thing to be forced down our throat. Having a choice is what is good. And what I value, Larry or Jon may not necessarily like. Most of us if not all on this list probably want something that approximates Ken and Dennis's original ideas not what IBM, DEC, CDC were trying to make us use in the old days or what Microsoft calls a system today. The discussion of how we got there and what people valued at the time is useful so we can try to remember the history and learn from it; but getting into right/wrong, good/bad, or you could have had this is a tad tiresome; IMO. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Tue Jan 21 03:40:06 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 20 Jan 2020 18:40:06 +0100 Subject: [TUHS] "What UNIX Cost Us" In-Reply-To: References: <5A5107E4-06AD-4C2B-B590-15C17B301D44@cfcl.com> <20200118203422.2c7o_%steffen@sdaoden.eu> Message-ID: <20200120174006.MYvii%steffen@sdaoden.eu> Hello Kathry. Kathryn Spiers wrote in : |On Sat, Jan 18, 2020, 12:35 Steffen Nurpmeso <[1]steffen at sdaoden.eu[/1]> \ |wrote: | | [1] mailto:steffen at sdaoden.eu | ||Rich Morin wrote in <[2]5A5107E4-06AD-4C2B-B590-15C17B301D44 at cfcl.com[/2\ ||]>: || |FWIW, I found this talk to be quite amusing and interesting. || | || |"What UNIX Cost Us" - Benno Rice (LCA 2020) || |[3]https://www.youtube.com/watch?v=9-IWMbJXoLM[/3] | ||That is the one who mutilated the FreeBSD fortune program no? ||(Despite it saying | ||  The potentially offensive fortunes are installed by default on FreeBSD ||  systems.  If you're absolutely, *positively*, without-a-shadow-of-a-\ ||doubt ||  sure that your user community goes berzerk/sues your pants off/drops \ ||dead ||  upon reading one of them, edit the Makefile in the subdirectory \ ||datfiles, ||  and do "make all install".) | ||Nothing but a hollow lie ever since! ... |Or you could remove the offensive fortunes and make the default more \ |friendly for everyone... | |Probably best not to re-litigate that change on this thread though. Maybe the latter. But for the former. A citation is a citation, and whereas you can clean your house, with huge amounts of desinfection and insecticides, you could claim but i promise it is not clean, and never will be, yes, in fact you will not even stay alive without a tremendous amount of bacteria and more inside of you, and on your surface. But you do end up in a deserted and deadly place. So you remove citations of Hitler which are prominently marked as Hitler citations, because you claim that is less offensive and makes the world a smoothie place, but i do not think so. In the thread by then i think i said something like "back in the 70s people had the capability to see things in a context", you know, and if _i_ see a Hitler citation, then i, not only but also because i am German, put that in a tremendous, let me say in a monstrous context. And it is plain, dear Lady, that the demon is not gone, it is in almost each and everyone. And in _my_ opinion, the "cleaning" that has been done is nothing but a trivialisation, which goes alongside a common flattening that happens in public discourse in general. This is nothing new, and people sang about "shiny happy people" decades ago, and have by far not been the first which did. If i recall correctly, the actual argument on the removal, which if i recall happened "just like that", without discussion or that issue tracker that FreeBSD now uses, was because of a Hitler citation on women. If i recall correctly it was in turn a citation which revealed that Hitler did not understand Nietzsche correctly. Maybe i understand Nietzsche false. Nietzsche also sings and dances alongside the road that Richard Wagner claimed some decades before Nietzsches book we are talking about. Hitler also was impressed by Wagner's art and saying, yet, did he understand it, really? So we are now about enter the space of culture, philosophy and religion, the human being and its way of self-organization, about the necessity of self-reflection, as called for, and named, by the mentioned. Will you ever be able to develop self-reflection without a context, dear Lady, i am asking? Off-topic, whereas i blame Hitler, and the endless shame that comes alongside -- and today in a week is the 75th anniversary of the rescue, of the remains, of Auschwitz --, the older i get, the less i can blame my forefathers desires. I can stand this ground, and it is good that after WWII the winners acted more wise and reflected than after WWI. And i thought it was Churchill, but i think it has been John F. Kennedy who said ~"either mankind will put an end on war, or war will put an end on mankind". Citations have been placed in a Unix distribution, to come back to the topic. Decades ago. I do not think it was a giggling funny old man who put them there, but even a giggling funny old man has decades of life to look onto. I who approach my 50ies in a not too distant future (if i am lucky) have already seen dozens of dirty wars, thousands of lies, and aggressively put false contexts which are not lies yet are lies indeed, and millions and millions of terrible deaths, and maybe-death-would-have-been-better's, too. I personally do not think this gets better if the public discourse becomes even more superficial or even becomes the total farce of misinformation as opposed to slight censorship, which happens in the western world even without official propaganda, which i hate to the bottom of my heart. But i am not Mr. Clean, the falsely understood. My only concern on the MeToo that i hate, is that the Suffragettes get finally blown away because those who came up short wanted to have a whole evening on Netflix or the BBC (nice neighbours for sure), exclusively. I have not and never had problems with strong women, they always existed, and my very personal point of view is in fact that today we have a lot less of strong women with personality than when i was young. And ever and ever again i read and see stories of strong women from more than hundred years ago, when Germany indeed was a source of science, culture and beauty, too. I cannot do anything against people who read the bible as an operator's guide, nor mental hedgehoppers which do not get Nietzsche nor Wagner right, but only Might and Money. The problem seems to be that these people govern the world. No, the sticky and greasy cloud cover of misinformation and superficiality sometimes has to be torn open, and i admire that the *BSD fortune program took the opportunity to burst in the focused and selfish view that most people, me included, have on a day by day base. And how often do i myself become conscious of something that i did not understand first, take the line Wagner .. Nietzsche, .. and the incapable brain which did not get it thereafter .. and has been lifted to responsibility nonetheless! (Just a few weeks ago my eyes were opened that the "Fonty" in Günther Grass's "Ein weites Feld" was indeed Theodor Fontane. Granted that i did not really "lived" in "Ein weites Feld", but maybe ... i should read it again! But that is just bla.) And, dear Lady, whereas i like friendliness, i think it should be wholehearted and holistic. Removing some citations which, by the very heart of a citation, have a context, in which they should be contemplated, strives me as peculiar if at the same time we, western world citizens, either directly or indirectly, by means of our buying behaviour, for example, kill or suppress people, and even destroy life on earth as such. Regarding MeToo i am happy that here in Germany this overheated thing has been normalizest; crimes are crimes, and need to be punished (maybe i am an antisemit when i bring sympathy to the Public Enemy text "Jeffrey Dahmer, into the room without cuffs -- how the hell do we get stuffed???? In the back of a cell on an Isle."). But what if Jack Nicholson would have not been brought to go nuts in Shining, what if Brad Pitt would not have had to repeat the scene where he drags the dead Hector dozens of times, what if raped "bitches" (or non-bitches) would look like if they come from a gala dinner. That is just grazy. I personally do not think that removing these citations made the world a better place. And whereas i also do not think that it make the world a worse place, hah, i start hoping he could impress a nice young women, they got married and have some kids. A nice evening i wish, Miss Kathryn Spiers, --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) From imp at bsdimp.com Tue Jan 21 03:49:21 2020 From: imp at bsdimp.com (Warner Losh) Date: Mon, 20 Jan 2020 10:49:21 -0700 Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") In-Reply-To: References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com> <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu> Message-ID: Thanks Clem. One minor clarification. Jordan and the patchkit work did predate NetBSD. However, the NetBSD project formed a little before the FreeBSD project that grew out of the patchkit days. Jordan didn't get that moving until NetBSD made rumblings... it was still a time that you heard a lot of what was going on by word of mouth, not so much by postings and email... The OpenBSD split was years later... and a complicated mix of personality conflicts and technical differences. But in many ways it was a smaller split since for a long time they were almost 100% compatible at the driver level (something you could never really say about net and free). Warner On Mon, Jan 20, 2020, 10:21 AM Clem Cole wrote: > > > On Sun, Jan 19, 2020 at 10:52 PM George Michaelson > wrote: > >> It does me no credit, that I initially reacted very badly to 386BSD, >> and the initial {Net,Free,Open} situation. >> > First, be careful. What we sometimes call 386BSD as a 'release' started > just as a port of NET2 to the 386 based 'commodity' hardware platform. The > history is that in the late 1970s/early 80s Bill Jolitz was working for Nat > Semi and ported BSD 4.1, to a multibus based NS16032 board that NS had > built, which was similar to the Stanford University Network (SUN) terminal > what had a 68000. He eventually built a 'luggable' using that and > updated to the port to 4.2++. He (and Lynn I believe) started a company > to sell that hardware/software solution and for whatever reason, it did not > really take off. > > At some point, he got his hands on a 386based PC (Compaq I think) and > started to move his port over to that system. A number of people helped > him (for instance I did a bunch of the AT/disk controller work as I had > access to the WD design documents for another consulting gig I had at the > time - Bill mentioned this in the articles BTW). > > Bill and Lynn's NS16032 and 386 code went back to the CSRG 'masters' - > although how and that happened was never completely clear to me. The SCCS > deltas tell at least part of the story. Bill managed to make a bootable > image that mostly installed on a PC/386 as the minicomputer versions did > from the formal release. The ftp area of ucbvax had all of these bootable > images available for download such as one for an HP 68K system and I think > the DEC VAX and PMAX, the CCG system and a few others IIRC. As I have said > in other messages if you were a UCB licensee you had the passwords to > look/download from that area. Bill placed that version in the same ftp > area. The 386 based port went viral at least with the UCB licensees. (In > fact, if Linus had known about it, theoretically he could have used it > also. His university was licensee, but as Larry McVoy likes to point, not > all the schools were as free with the IP, so I will not go down that > rathole). > > The bottom line is that many people (like me on a Wyse386) started with > Bill's original port; including the BSDi founders. > > When Jolitz and BSDi went separate ways, Jolitiz continued to update the > CSRG 386 based tarball (to an extent). One of the issues was there > originally was attempt to keep the different architectural versions of BSD > in sync ( to a point and NetBSD does yet exist). A number of people were > unhappy and the speed, depth *etc*. of the 386 version, most > notably Jordan Hubbard and FreeBSD was born. The two biggest issues Jordan > wanted to fix, was easier install and a bit wider support for more hardware > (again I sent Jordan the changes to FreeBSN 1x for the Wyse and a couple of > NCR boxes). The NetBSD project would birth from the original ideals of > CSRG and trying to keep everything the same but that's still in the future. > > > > >> >> I found all this "fragmentation" pretty hard to understand. -BSDI felt >> like it had occupied the space, and I couldn't entirely understand >> what was going on, or why any of it mattered. >> > See below.... > > > > >> What I think I missed (didn't understand) was how draining support was >> for Berkeley, and in the absence of a sugar daddy >> > Herein is the issue that many people on the sidelines missed. > > CRSG was a large project and funded a lot of work at UCB in EECS. It never > funded me (I was funded by Tektronix, HP, DEC *et al*), but that project > did a fund a number of students. However, at some point CSRG stopped being > a research project and started being a support project for DARPA. There > was also a good deal of resentment by some groups in EECS that were not > getting DARPA funding. > I'll not say if that was good or bad but I will say that it did cause > great deal consternation at UCB within the department and many people doing > more formal research were not happy. In the end, the EECS > Department mothers and fathers along with the Dean *et al*, decided to > stop/end the CSRG project. Many people who were directly or indirectly > working on BSD, like Mary Ann and myself, had graduated and had since > left. Bob Kridle had formed Mt. Xinu, Asa Romberger has formed Unisoft, Joy > had left/was leaving for Sun, *etc*. So the question remained what to > do with CSRG. As to what everyone would do, became every person for > her/himself and as we know some of the folks, along with a few folks from > the USENIX community formed BSDi. > > As was noted elsewhere, NetBSD would eventually be formed by volunteers to > keep the different ports alive (in fact much of the efforts was from folks > not at UCB), but that was still in the offing. Remember, while CSRG > itself was not a research project, a lot of people around the world were > using the BSD code base for their own research. The whole idea of NetBSD > was to create a uniform platform that people could compare things. So, the > question of how that was to come about or do any work on BSD if DARPA was > not paying the bills, was still an open one. But, the idea that would > eventually create FreeBSD, was supporting a pure commodity *solution for > day-to-day use, not as a research platform*. [I'll leave off the later > OpenBSD/NetBSD fork by Theo here as it has little to do with the question]. > > BSDi had a similar/same goal of producing something like SunOS/VMS *etc* but > supported on commodity hardware. That solution was to sell it and using > the revenues from the support contract, be able to pay people to do that > work. As I said and in some other messages, it is noted that Bill Jolitz > wanted something more FOSS. Truth is BSDi code was 'open source' but it > took a $1K license to *get the source from them*. > > In the end, the real problem was not the infighting between the different > BSD camps, but AT&T, who wanted the entire pie. Clearly, their executives > saw anything other than their complete control of the UNIX IP as a threat. > Hence the court case, the eventually AT&T/Sun relationship *etc*... > > Your lack of 'sugar daddy,' really comes back to that. There were few > people at the time that could pay the bills. Until then DARPA had been > it. I do not know if DARPA wanted out or if another group could have been > formed that could take over CSRG. I did have discussions with Rob over a > beer that at least the thought had crossed the BSDi folks mind, that once > started; they would apply for a DARPA contract. > > At the time had blow up, I was a consultant and I personally was > considering what I was going to do next and if they had had a real future, > the talks with Rob might have gotten more serious. My wife wanted me to > stop being independent if we were to start a family (I would join Locus > instead). > > BTW: I was in an interesting position as I was friends with all of the > different sides in the war/original fight. Like Jolitz, I wanted to see > what we now call a 'FOSS' release of BSD. But like Rob, I knew it was > going to take some revenue stream to make it happen/continue the support. > In the end, the AT&T legal mess blew it all up. BSDi ended up failing > and Jordan's work stayed around. > > BTW: what pays for Linux development these days by number of 'committers > salary' is Intel (#1), IBM (#2), then a load of other firms including the > different distros. But for *any* platform to be successful and actually > continue to be used in the market, someone has to pay the salaries of some > set of professional programmers to do the work. > > That said when AT&T injoined BSDi and UCB a lot of people (myself > included) started to hack on Linux. But just think if AT&T had actually > won the case and courts decided UNIX was allowed to be a trade secret, then > Linux and all of the UNIX 'clones' would have been in violation. > > No matter what flavor of UNIX you like, we are all in debt to UCB and BSDi > for settling the IP argument. The court was clear, the >>ideas<< behind > UNIX (*a.k.a.* the intellectual property) came from Ken, Dennis and > friends at AT&T and *they did own it.* But because of the 1956 consent > decree that published the ideas and the moment the ideas were published, we > all can now >>use<< them. The provenance of the source code does not > relate to the provenance of the idea, so* the source code itself does not > define what UNIX is or is not. * > > I bring this all up in hopes to try to close this rat hole of Linux, *vs*. > *BSD. Like editors, we all have our own favorites. That's cool, we don't > want one thing to be forced down our throat. Having a choice is what is > good. And what I value, Larry or Jon may not necessarily like. Most of > us if not all on this list probably want something that approximates Ken > and Dennis's original ideas not what IBM, DEC, CDC were trying to make us > use in the old days or what Microsoft calls a system today. > > The discussion of how we got there and what people valued at the time is > useful so we can try to remember the history and learn from it; but getting > into right/wrong, good/bad, or you could have had this is a tad tiresome; > IMO. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Tue Jan 21 04:04:32 2020 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 20 Jan 2020 10:04:32 -0800 Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") In-Reply-To: References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com> <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu> Message-ID: <20200120180432.GJ28686@mcvoy.com> On Mon, Jan 20, 2020 at 12:19:25PM -0500, Clem Cole wrote: > On Sun, Jan 19, 2020 at 10:52 PM George Michaelson wrote: > > > It does me no credit, that I initially reacted very badly to 386BSD, > > and the initial {Net,Free,Open} situation. > > > First, be careful. What we sometimes call 386BSD as a 'release' started > just as a port of NET2 to the 386 based 'commodity' hardware platform. The > history is that in the late 1970s/early 80s Bill Jolitz was working for Nat > Semi and ported BSD 4.1, to a multibus based NS16032 board that NS had > built, which was similar to the Stanford University Network (SUN) terminal > what had a 68000. He eventually built a 'luggable' using that and updated > to the port to 4.2++. He (and Lynn I believe) started a company to sell > that hardware/software solution and for whatever reason, it did not really > take off. I know those Nat Semi chips very well, or did at the time. I so wanted to love those chips, the instruction set felt like whoever did the PDP-11 did the 320xx chips. But they couldn't produce chips without bugs and that killed them. It's a crying shame, I liked the instruction set WAY better than the VAX. The VAX seemed really messing compared to the PDP-11, the 320xx chips seemed clean. Might be rose colored glasses but that's my memory. From david at kdbarto.org Tue Jan 21 04:09:55 2020 From: david at kdbarto.org (David Barto) Date: Mon, 20 Jan 2020 10:09:55 -0800 Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") In-Reply-To: <20200120180432.GJ28686@mcvoy.com> References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com> <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu> <20200120180432.GJ28686@mcvoy.com> Message-ID: <7C45A7D2-1FE9-46F0-AA31-396671704214@kdbarto.org> On Jan 20, 2020, at 10:04 AM, Larry McVoy wrote: > > On Mon, Jan 20, 2020 at 12:19:25PM -0500, Clem Cole wrote: >> On Sun, Jan 19, 2020 at 10:52 PM George Michaelson wrote: >> >>> It does me no credit, that I initially reacted very badly to 386BSD, >>> and the initial {Net,Free,Open} situation. >>> >> First, be careful. What we sometimes call 386BSD as a 'release' started >> just as a port of NET2 to the 386 based 'commodity' hardware platform. The >> history is that in the late 1970s/early 80s Bill Jolitz was working for Nat >> Semi and ported BSD 4.1, to a multibus based NS16032 board that NS had >> built, which was similar to the Stanford University Network (SUN) terminal >> what had a 68000. He eventually built a 'luggable' using that and updated >> to the port to 4.2++. He (and Lynn I believe) started a company to sell >> that hardware/software solution and for whatever reason, it did not really >> take off. > > I know those Nat Semi chips very well, or did at the time. I so wanted to > love those chips, the instruction set felt like whoever did the PDP-11 > did the 320xx chips. But they couldn't produce chips without bugs and > that killed them. It's a crying shame, I liked the instruction set > WAY better than the VAX. The VAX seemed really messing compared to > the PDP-11, the 320xx chips seemed clean. Might be rose colored > glasses but that's my memory. My memory as well. A friend and I got ahold of the complete set of chips and started to build out the hardware for a Unix box. We got most of the way there too, and then the odd quirks started showing up. We tracked some of them to our layout and the others to the NS chips. Then we gave it up as a “ah, it would have been nice if only” project. David From krewat at kilonet.net Tue Jan 21 04:34:40 2020 From: krewat at kilonet.net (Arthur Krewat) Date: Mon, 20 Jan 2020 13:34:40 -0500 Subject: [TUHS] Early Linux and BSD In-Reply-To: <7C45A7D2-1FE9-46F0-AA31-396671704214@kdbarto.org> References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com> <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu> <20200120180432.GJ28686@mcvoy.com> <7C45A7D2-1FE9-46F0-AA31-396671704214@kdbarto.org> Message-ID: On 1/20/2020 1:09 PM, David Barto wrote: > My memory as well. A friend and I got ahold of the complete set of chips > and started to build out the hardware for a Unix box. We got most of the > way there too, and then the odd quirks started showing up. We tracked > some of them to our layout and the others to the NS chips. Then we gave > it up as a “ah, it would have been nice if only” project. A friend of mine and I did the same, but with 68000. I wrote the assembler and other utilities, he did the hardware design (although we both took turns critiquing each other's work), and we both (and his girlfriend) did the wire-wrapping. We were eventually consumed by other real-life happenings, and it fell by the wayside, but looking back at it now, UNIX would have been the perfect choice. I did have visions of grandeur that I would write my own OS for it - I'm sure I would have eventually learned my lesson ;) art k. PS: We cheated, and used static RAM. A few failed development projects at my (then) current place of employment, and no one knew what to do with "all these chips" that were left over. No problem, I know what to do with them... they wound up in the trunk of my Triumph TR7 From clemc at ccc.com Tue Jan 21 05:00:45 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 20 Jan 2020 14:00:45 -0500 Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") In-Reply-To: References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com> <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu> Message-ID: On Mon, Jan 20, 2020 at 12:49 PM Warner Losh wrote: > Thanks Clem. > Most welcome > > One minor clarification. Jordan and the patchkit work did predate NetBSD. > However, the NetBSD project formed a little before the FreeBSD project that > grew out of the patchkit days. Jordan didn't get that moving until NetBSD > made rumblings... > Right - if I was not clear, on that ordering, mei culpa. > it was still a time that you heard a lot of what was going on by word of > mouth, not so much by postings and email... > Exactly. > > The OpenBSD split was years later... and a complicated mix of personality > conflicts and technical differences. > A real shame IMO, but giving the personalities, I'm not sure it was not predestined, > But in many ways it was a smaller split since for a long time they were > almost 100% compatible at the driver level > Very true, I run OpenBSD on my router/main server - I just want a minimum system, that I feel it safe. I have NetBSD on a couple of boxes cause it runs and FreeBSD or Linux on others. And MacOS on my desktop. I'm sort of, whatever gets the job done and I don't have to think too much about it, but it's probably why the little incompatibilities drive me nuts. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Tue Jan 21 05:09:00 2020 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Mon, 20 Jan 2020 14:09:00 -0500 Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") In-Reply-To: References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com> <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu> Message-ID: <20200120190900.GH15860@mit.edu> On Sun, Jan 19, 2020 at 07:32:57PM -0800, Greg A. Woods wrote: > > Out of curiosity, did the articles contain download information for a > > bootable copy of 386BSD? > > Yes, they did: > > https://www.drdobbs.com/porting-unix-to-the-386-the-final-step/184408800 .... which is dated July 1992, and describes a "launch" of 386BSD Release 0.0 in March 17, 1992. This is contemporaneous with Linux 0.95a (which by coincidence was also released on March 17th, 1992.) The first "real" distribution, the Soft Landing System, was released in May 1992. (The Manchester Computer Centre distribution in November 1991 was a floppy-based distro containing command-line and development utilities, but not X Windows, so some people don't feel it counts as a full-featured distribution.) > Also keep in mind that NetBSD started as a set of "net" (as in usenet) > patch kits for 386BSD. It looks like NetBSD's source code repository was established on March 21, 1993. Patchkit 0.2.2 was apparently also released on the same date. NetBSD's first release, 0.8, was released on April 19, 1993. The FreeBSD project was named in June 19, 1993, with its first release in November 1993. So it's easy to use the lawsuit as the scapegoat for why the BSD's failed to take off, but at best it's only one of many factors. The Jolitzs' refusal to accept many patches, forcing a delay of a year before spawning two project forks, was one. The dispersal of effort as a side effect of various people trying to start companies around BSD code (SunOS, NetApp, BSDI, Wasabi Systems, etc.) was another. BSD-licensed code seems to thrive best when there are grants or non-profit institutions funding its work; but attempts to support BSD code from as part of commercial work doesn't seem to have worked out as well. As dwheeler (I think Dave Wheeler, but I'm not certain) astutely observed in 2006: I think the BSD license has been a lot of trouble to the *BSDs. Every few years, someone says, "hey, let's start a company based on this BSD code!" (BSD/OS in particular comes to mind, but SunOS and others did the same). They pull the *BSD code in, and some of the best BSD developers, and write a proprietary derivative. But as a proprietary vendor, their fork becomes expensive to self-maintain, and eventually the company founders. All that company work is lost forever, and good developers were sucked away during that period. Repeat, repeat, repeat. That's more than enough to explain why the BSDs manage to make steps forward, but just don't manage to maintain the pace of Linux kernel development. Meanwhile, the GPL has legally enforced a consortia on major commercial companies. Red Hat, Novell, IBM, and many others are all contributing, and feel safe in doing so because the others are legally required to do the same. It's basically created a "safe" zone of cooperation, without anyone having to sign complicated legal documents. A company can't feel safe contributing code to the BSDs, because its competitors might simply copy it without reciprocating. There's much more corporate cooperation in the GPL'ed kernel code than with the BSD'd kernel code. Which means that in practice, it's actually been the GPL that's most "business-friendly". So while the BSDs have lost energy every time a company gets involved, the GPL'ed programs gain almost every time a company gets involved. And that explains it all. - https://lwn.net/Articles/197875/ I'll also note that the GPL licensing means that I've been able to carry my expertise in the code base across 4 job changes (MIT, VA Linux Systems, IBM, Google). In effect, this arrangement and the business models forced by the GPL allocates more value to the community at large and to the engineers working at those companies, at the expense of value that can be extracted to the corporate shareholders --- for better or for worse. And so while I don't have a private jet like some of the early founders of Sun, NetApp, et. al., and I'm still a working stiff, I lead a comfortable life, and it seems like a good tradeoff to me. :-) In the long run, it might be interesting to see how the Illumos (Open Solaris) derivatives fare compared to Free/Net/Open/Dragon BSD's. There seem to be some interesting cooperation from the set of companies that use Illumos, which is encouraged by the CDDL's weak provisions. So if Illumos and its derivatives are able to overtake *BSD's despite the *BSD's having an earlier start, that might be an interesting confirmation of dwheeler's point above. - Ted From clemc at ccc.com Tue Jan 21 05:18:48 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 20 Jan 2020 14:18:48 -0500 Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") In-Reply-To: <20200120180432.GJ28686@mcvoy.com> References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com> <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu> <20200120180432.GJ28686@mcvoy.com> Message-ID: On Mon, Jan 20, 2020 at 1:04 PM Larry McVoy wrote: > I know those Nat Semi chips very well, or did at the time. I so wanted to > love those chips, the instruction set felt like whoever did the PDP-11 > did the 320xx chips. It was clear, the NS folks, like the Moto folk, knew the PDP-11 and VAX. It was a nice architecture and should been a win but... > But they couldn't produce chips without bugs and that killed them. I really think it was they were the third man and too late. Between Apple on the Mac and Apollo, Masscomp and eventually Sun, the 68000 and later 68010 had volume. 8086 family had volume with the PC. As Jon can tell you, Tektronix decided the use the NS chip and tossed a working 68000/68010 design (Magnolia - which would later ship at 4400) for a completely new workstation. But it meant starting from scratch. Big mistake... If they had just shipped Magnolia at the beginning, I'm not sure either Masscomp or Sun would have been birthed. Apollo and Triple-Drip were already there, but thy would have had the first UNIX workstation on the market, with a super graphics system. Sigh.... > It's a crying shame, I liked the instruction set > WAY better than the VAX. The VAX seemed really messing compared to > the PDP-11, the 320xx chips seemed clean. Might be rose colored > glasses but that's my memory. I would not say way better, but much cleaner. To DEC's credit, the idea of the VAX was to take the PDP-11 forward and keep things running. Funny, DG did that better in the end, but that was the idea at least. NS was trying to make the VAX without the rough edges, mistakes DEC had made. Prof. Yale Patt consulted on both Instructions sets BTW, which may be why they look so similar. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Tue Jan 21 05:40:57 2020 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Mon, 20 Jan 2020 14:40:57 -0500 Subject: [TUHS] Shell Level... In-Reply-To: <1itSE0-5Td-00@marmaro.de> References: <1itSE0-5Td-00@marmaro.de> Message-ID: <20200120194057.GI15860@mit.edu> On Mon, Jan 20, 2020 at 09:15:56AM +0100, markus schnalke wrote: > Hoi. > > [2020-01-19 14:22] Grant Taylor via TUHS > > > > Have you ever used shell level, $SHLVL, in your weekly ~> daily use of Unix? > > What's the use of it? The only use of $SHLVL I can think of is the > answer to the question if ^D will close the last shell or just a > sub shell. I hardly ever ask myself this question. Probably that > starts to become relevant when you open sub shells frequently. The normal reason why I'm starting subshells is because I need to control various environment variables on an ad-hoc basis. It might be PYTHONPATH, KRB5CCNAME, GPG_AGENT_INFO, LD_LIBRARY_PATH, or some combination of the above. Back when I was regularly using Kerberos root/admin bits, I had some hard-coded shell aliases to indicate explicitly I was in a shell that was using my tytso/root at ATHENA.MIT.EDU or tytso/admin at ATHENA.MIT.EDU kerberos tickets. But for ad-hoc use cases, SHLVL is great way to track whether I'm a non-standard shell environment. For me, some use case probably comes up at least week or two. > With tmux or screen at hand, this use case is obsolete for me. > (Besides, my shell doesn't know about $SHLVL.) Before I was using bash regularly, I had hard-coded something like SHLVL in my .tcshrc. - Ted From jon at fourwinds.com Tue Jan 21 05:46:05 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Mon, 20 Jan 2020 11:46:05 -0800 Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") In-Reply-To: References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com> <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu> <20200120180432.GJ28686@mcvoy.com> Message-ID: <202001201946.00KJk5er3071186@darkstar.fourwinds.com> Clem Cole writes: > > On Mon, Jan 20, 2020 at 1:04 PM Larry McVoy wrote: > > > I know those Nat Semi chips very well, or did at the time. I so wanted to > > love those chips, the instruction set felt like whoever did the PDP-11 > > did the 320xx chips. > > It was clear, the NS folks, like the Moto folk, knew the PDP-11 and VAX. > It was a nice architecture and should been a win but... > > > But they couldn't produce chips without bugs and that killed them. > > I really think it was they were the third man and too late. Between Apple > on the Mac and Apollo, Masscomp and eventually Sun, the 68000 and later > 68010 had volume. 8086 family had volume with the PC. > > As Jon can tell you, Tektronix decided the use the NS chip and tossed a > working 68000/68010 design (Magnolia - which would later ship at 4400) for > a completely new workstation. But it meant starting from scratch. Big > mistake... > > If they had just shipped Magnolia at the beginning, I'm not sure either > Masscomp or Sun would have been birthed. Apollo and Triple-Drip were > already there, but thy would have had the first UNIX workstation on the > market, with a super graphics system. Sigh.... > > > It's a crying shame, I liked the instruction set > > WAY better than the VAX. The VAX seemed really messing compared to > > the PDP-11, the 320xx chips seemed clean. Might be rose colored > > glasses but that's my memory. > > I would not say way better, but much cleaner. To DEC's credit, the idea of > the VAX was to take the PDP-11 forward and keep things running. Funny, DG > did that better in the end, but that was the idea at least. NS was trying > to make the VAX without the rough edges, mistakes DEC had made. Prof. Yale > Patt consulted on both Instructions sets BTW, which may be why they look so > similar. I remember it slightly differently than Clem, but close. The Magnolia wasn't a UNIX workstation, it was an experimental Smalltalk machine. I don't recall much about it, but I don't think that it had to address many of the problems that UNIX had at the time with the 68000 such as the lack of a MMU. I think that the Magnolia predated the 68010 and certainly predated the 68020 and awful but usable PMMU. There were also many political issues because by this time the legacy of Howard Vollum had departed Tektronix and it was starting to die the slow death of a poorly managed company being looted by top management which has become all too common since. But at least Tek lead in something! Part of the issue was that the Magnolia was developed in Tek Labs, which was the research end of things. It wasn't a product organization, the Magnolia at the time hadn't gone through any of the rigorous environmental testing required by Tek which was a company that actually provided warranty service. And there was no marketing, not that Tek was a marketing powerhouse. Given the way that things panned out I don't think that the Magnolia would have been a player once things like Suns appeared, if for no other reason that Tek had no clue as to how to do anything in volume and our stuff was way too expensive. The 32032 made sense for the workstation division based on the data sheets. But, it turned out to be extremely buggy, and unlike the 68K I don't recall the ability to look at and patch the state of the microcode. In any case, while the 32032 was a problem, the real reason that Tek failed in the workstation biz was management. What happened was that programmable instrumentation was becoming a thing. Every instrument group in the company was building their own "controller" for instrument programming. In a rare case of good decision-making it was decided that a single group would build a controller that everyone else would use; this was the workstation division. But, this took the most fun thing away from all of the other groups. They way that management structured things, instrument groups have to use the workstation unless it was missing something that they required. The result was that the workstation had to meet the union of all requirements, real or imagined. The I/O board in this thing had like 4 GPIB ports, 24 RS-232 ports, 8 RS-422 ports (I don't remember the exact number), and so on, making it more expensive than anybody else's CPU board. Of course, when the IBM PC came along all of the instrument groups said "well, we have 2 RS-232 ports and a parallel port and so we'll work with that." Had management said that the workstation group could do what was reasonable and that everyone would have to adapt and use it we could have parallel groups competing on 32K and 68K designs. Jon From clemc at ccc.com Tue Jan 21 05:51:52 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 20 Jan 2020 14:51:52 -0500 Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") In-Reply-To: <20200120190900.GH15860@mit.edu> References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com> <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu> <20200120190900.GH15860@mit.edu> Message-ID: On Mon, Jan 20, 2020 at 2:10 PM Theodore Y. Ts'o wrote: > .... which is dated July 1992, and describes a "launch" of 386BSD Ouch.... this is why people get confused. I'm probably not helping by not being precise enough. 386/Net/Free/OpenBSD as >>projects<< are different from the original 386 work that Bill and Lynn did to get it running on the first 386 and get that code back into the CRSG project. The 386 was released in 1985 by Intel. A number of firms started to use it. Wikipedia says Compaw was first (The Compaq Deskpro 386/25 was '89 according to google and we used a Wyse 32:16 at Stellar before that). Bill Jolitz did is work originally on a Multibus based 386 from Intel (using his NS system to bootstrap) and moved it to the PC (I thought a Deskpro) shortly after it started to ship. Most of us call that work '386BSD' but it was 4.X BSD that booted on a 386 based PC and not really what you are discussing. These bits are/were the 'hidden' ftp - which is not to be confused with the first BSD 'distro' for the 386 which would be much more public, BTW: The original BSD on a 386, install was very rough. Bill had created the boot floppies on his NS system. You had a use a DOS program to create them via an image copy and the boot was really funky. As I said, the original AT driver was wrong, and kept getting hosed until I fixed it when I was consulting for NCR (on their 386 system in 1989). IIRC Jolitz had created it by looking at that Minx AT driver and made some guess. I had (think I still have) the WD1003 documents, so I knew what the registers really looked like and it was not handling some error conditions IIRC. And the naming is really the root of the whole argument BTW.... BSD 4.x for a 386 based system *vs.* a real distribution. Bill Jolitz tried to make a better release for a BSD on a 386 (*a.k.a.* 386BSD) The install for a PC/386 improved. IIRC, Intel had paid CMU to do some work as part of Andrew and the Mach stuff (Bob Barron was the author of this I believe)., They wrote a version fdisk, and a bunch of things to allow dual booting and some other tools that ran on DOS. I don't remember how, but Bill Jolitz got that code and very early on the BSD 386 port used it - probably as part of the CMU/Mach to CSRG push/intermixing. And later on yet to Jordan's credit, and it was after Linux, NetBSD, *etc* was all there, that FreeBSD, completely redid the install scripts and made the system that pretty much is the model for all current PC based systems now. In fact, around that time I had started work with Linux and one of the things liked about FreeBSD 1.x was the install compared to the original Linus package (although I had an early Slackware pretty earlier in my Linux time and that improved things). I think your comment and about the healthy competition was true, each team was trying to do better. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Jan 21 06:15:55 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 20 Jan 2020 15:15:55 -0500 Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") In-Reply-To: <202001201946.00KJk5er3071186@darkstar.fourwinds.com> References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com> <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu> <20200120180432.GJ28686@mcvoy.com> <202001201946.00KJk5er3071186@darkstar.fourwinds.com> Message-ID: On Mon, Jan 20, 2020 at 2:47 PM Jon Steinhart wrote: > I remember it slightly differently than Clem, but close. Ouch -- I was 1/2 of the Magnolia development team -- I remember a lot about it!!! For the curious when bitsavers comes back: http://bitsavers.trailing-edge.com/pdf/tektronix/magnolia/ Roger Bates had just finished the Dorado at PARC. I had just left CMU. We were cubical mates in TekLabs. Motorola had an experimental chip that was not yet numbered. We were given them in the Computer Research group in Tek Labs. So, we started building a personal computer at night for ourselves. Our boss saw the notes and asked what we would do differently if Tek paid for it. I was originally using 8" floppies and immediately said 'a real disk.' We got a Tek '$10K project' and a few months to build a prototype. I already had written (well sort of hacked) a simple C compiler based on Dennis's PDP-11 compiler (when it screwed up it would sometimes include PDP-11 code - and I never supported FP). Paul Blattner wrote an assembler and linker. Using that, Steve Glaser and I ported UNIX/V7 to it. > The Magnolia wasn't a UNIX workstation, it was an experimental Smalltalk > machine. That was 2+ years later actually. Once they had the system, a couple of other folks moved Smalltalk to it. And in fact, it eventually did release it as a product called the 4404. > I don't recall > much about it, but I don't think that it had to address many of the > problems > that UNIX had at the time with the 68000 such as the lack of a MMU. Be careful... It most definitely did have an MMU, I designed it!!! The Xerox Altos and Dorado's never had MMU's. So Roger was not familiar with them. I had to teach him. Magnolia had a base/limit register MMU similar to the PDP-11/70. The original OS was V7 and swapped. It ran just fine. > I think > that the Magnolia predated the 68010 and certainly predated the 68020 and > awful but usable PMMU. The wire-wrapped prototype was originally an X-series chip and yes the first 'production' units were real 10Mhz 68000s. After I went back to grad school, Roger spliced a 68010 into and ripped out my MMU. The late Terry Laskodi put 4.1BSD on it. > Part of the issue was that the Magnolia was developed in Tek Labs, which > was > the research end of things. It wasn't a product organization, the Magnolia > at the time hadn't gone through any of the rigorous environmental testing > required by Tek which was a company that actually provided warranty > service. > And there was no marketing, not that Tek was a marketing powerhouse. Given > the way that things panned out I don't think that the Magnolia would have > been > a player once things like Suns appeared, if for no other reason that Tek > had no > clue as to how to do anything in volume and our stuff was way too > expensive. > Very possible, but they did have first mover position. In fact, folks at Harvard Business as much as said so later. There is a great HBS case study written about it called "Why Skunk Projects Don't Work" (which I have somewhere) -- I should get that scanned at added to the Magnolia archive on BitSavers. > > In any case, while the 32032 was a problem, the real reason that Tek failed > in the workstation biz was management. No doubt... but it was 3 years later. Which I think was a huge issue. > "well, we have 2 RS-232 ports and a parallel port and so we'll work with > that." Which of course was what Magnolia had been 3.5 years earlier and was what became the 4404 Smalltalk machine. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Jan 21 06:19:43 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 20 Jan 2020 15:19:43 -0500 Subject: [TUHS] Distributed systems, was: On the origins of Linux - "an academic question" In-Reply-To: References: Message-ID: On Sat, Jan 18, 2020 at 1:25 AM Rob Pike wrote: > I am convinced that large-scale modern compute centers would be run very > differently, with fewer or at least lesser problems, if they were treated > as a single system rather than as a bunch of single-user computers ssh'ed > together. > +1 > But history had other ideas. > History and 'good' (cheap) enough. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Tue Jan 21 06:28:39 2020 From: robpike at gmail.com (Rob Pike) Date: Tue, 21 Jan 2020 07:28:39 +1100 Subject: [TUHS] Unix quix Message-ID: I reposted the original Unix quiz, which disappeared when public Google Plus was turned off. Answers will reappear in a few days. https://commandcenter.blogspot.com/2020/01/unix-quiz.html -rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Tue Jan 21 07:06:45 2020 From: athornton at gmail.com (Adam Thornton) Date: Mon, 20 Jan 2020 14:06:45 -0700 Subject: [TUHS] Unix quix In-Reply-To: References: Message-ID: On Jan 20, 2020, at 1:28 PM, Rob Pike wrote: > I reposted the original Unix quiz, which disappeared when public Google Plus was turned off. Answers will reappear in a few days. > > https://commandcenter.blogspot.com/2020/01/unix-quiz.html I am slightly terrified that I can answer a non-trivial fraction (though by no means a majority!) of these without looking up answers. The TSO one in particular I knew instantly and it’s still quite true. I don’t know the story behind #23 but I certainly want to. Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From woods at robohack.ca Tue Jan 21 09:04:33 2020 From: woods at robohack.ca (Greg A. Woods) Date: Mon, 20 Jan 2020 15:04:33 -0800 Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") In-Reply-To: <20200120190900.GH15860@mit.edu> References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com> <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu> <20200120190900.GH15860@mit.edu> Message-ID: At Mon, 20 Jan 2020 14:09:00 -0500, "Theodore Y. Ts'o" wrote: Subject: Re: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") > > On Sun, Jan 19, 2020 at 07:32:57PM -0800, Greg A. Woods wrote: > > > Out of curiosity, did the articles contain download information for a > > > bootable copy of 386BSD? > > > > Yes, they did: > > > > https://www.drdobbs.com/porting-unix-to-the-386-the-final-step/184408800 > > .... which is dated July 1992, and describes a "launch" of 386BSD > Release 0.0 in March 17, 1992. This is contemporaneous with Linux > 0.95a (which by coincidence was also released on March 17th, 1992.) Yes, though as I recall all of the articles mentioned that the OS could be downloaded, but I pointed at that final article as it was the first one in which I found explicit mention of the FTP server name(s). > The first "real" distribution, the Soft Landing System, was released > in May 1992. (The Manchester Computer Centre distribution in November > 1991 was a floppy-based distro containing command-line and development > utilities, but not X Windows, so some people don't feel it counts as a > full-featured distribution.) The actual 386bsd Release 0.0 (the one done directly by Bill and Lynne Jolitz) announcement is dated "March 7, 1992" according to the first post about it on comp.unix.bsd (and according to that announcement there was a meeting at Apple in Cupertino (SVNet) on the 11'th where copies of the floppies were made available for copying (comp.unix.bsd: <2763 at tardis.Tymnet.COM>). Note that according to an article from Unigram ("Issue 396", dated August 3-7, 1992, (p)re-posted by Tom Limoncelli in comp.unix.bsd) this "386bsd 0.0" was actually a re-write of earlier work to create a "386" based release of BSD. Apparently UCB lawyers asked Jolitz to destroy all the initial work done for the release, and he complied and rewrote what became 0.0 from scratch again, starting with the plain NET2 release. (comp.unix.bsd: <1992Aug1.020513.14170 at plts.uucp>) I would argue that in one way of looking at things NetBSD (and by extension FreeBSD) really started with the 0.0 patch kit, and that's also dated March 15, 1992 by Chris Demetriou. I agree though that the creation of the first commits in the CVS repository represent a more direct reflection of the intent to create a unique thing called NetBSD. (On March 13, 1992 there was a post by Mike Stump on comp.unix.bsd asking for someone to coordinate patches for 386bsd; and Pace Willisson posted the first patch in response on March 14, 1992; and Chris replied on the same day saying he would put such patches up on agate.berkeley.edu; and the "README.PATCHES" file appeared there on March 15, 1992.) -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From woods at robohack.ca Tue Jan 21 09:43:44 2020 From: woods at robohack.ca (Greg A. Woods) Date: Mon, 20 Jan 2020 15:43:44 -0800 Subject: [TUHS] Shell Level... In-Reply-To: References: Message-ID: At Sun, 19 Jan 2020 14:22:29 -0700, Grant Taylor via TUHS wrote: Subject: [TUHS] Shell Level... > > Have you ever used shell level, $SHLVL, in your weekly ~> daily use of Unix? I invented my own variant, $LEV, for Ksh, starting before 1993, probably when I first started using DMD-5620 terminals and layers, though possibly slightly before that when I first started using Ksh (about 1989 when I bought a used ATT3B2/400 for home use). I used my own $LEV in my prompt (or the window title, if using a windowing system) just to remind me if I'd started a sub-shell for some reason, such as in order to preserve my current working directory and environment. Early Ksh didn't have $SHLVL, and it's not universal (i.e. POSIX), so I've never really used $SHLVL itself (though I have very recently added a hook to set my $LEV from it IFF it is available). See https://github.com/robohack/dotfiles :-) -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From terry at jon.es Tue Jan 21 09:51:33 2020 From: terry at jon.es (Terry Jones) Date: Tue, 21 Jan 2020 00:51:33 +0100 Subject: [TUHS] Shell Level... In-Reply-To: <20200120194057.GI15860@mit.edu> References: <1itSE0-5Td-00@marmaro.de> <20200120194057.GI15860@mit.edu> Message-ID: I also make new shells fairly regularly, about half the time because I wan to set some variables that I don't want to have to reset. Then if/when I forget which window I was in, I can check with SHLVL (at least when using bash, which I normally don't do). But I'm normally in & out of the sub-shells very quickly so don't often need to check. Terry On Mon, Jan 20, 2020 at 8:43 PM Theodore Y. Ts'o wrote: > On Mon, Jan 20, 2020 at 09:15:56AM +0100, markus schnalke wrote: > > Hoi. > > > > [2020-01-19 14:22] Grant Taylor via TUHS > > > > > > Have you ever used shell level, $SHLVL, in your weekly ~> daily use of > Unix? > > > > What's the use of it? The only use of $SHLVL I can think of is the > > answer to the question if ^D will close the last shell or just a > > sub shell. I hardly ever ask myself this question. Probably that > > starts to become relevant when you open sub shells frequently. > > > > The normal reason why I'm starting subshells is because I need to > control various environment variables on an ad-hoc basis. It might be > PYTHONPATH, KRB5CCNAME, GPG_AGENT_INFO, LD_LIBRARY_PATH, or some > combination of the above. Back when I was regularly using Kerberos > root/admin bits, I had some hard-coded shell aliases to indicate > explicitly I was in a shell that was using my > tytso/root at ATHENA.MIT.EDU or tytso/admin at ATHENA.MIT.EDU kerberos > tickets. > > But for ad-hoc use cases, SHLVL is great way to track whether I'm a > non-standard shell environment. For me, some use case probably comes > up at least week or two. > > > With tmux or screen at hand, this use case is obsolete for me. > > (Besides, my shell doesn't know about $SHLVL.) > > Before I was using bash regularly, I had hard-coded something like > SHLVL in my .tcshrc. > > - Ted > -------------- next part -------------- An HTML attachment was scrubbed... URL: From woods at robohack.ca Tue Jan 21 09:55:47 2020 From: woods at robohack.ca (Greg A. Woods) Date: Mon, 20 Jan 2020 15:55:47 -0800 Subject: [TUHS] Shell Level... In-Reply-To: <1itSE0-5Td-00@marmaro.de> References: <1itSE0-5Td-00@marmaro.de> Message-ID: At Mon, 20 Jan 2020 09:15:56 +0100, markus schnalke wrote: Subject: Re: [TUHS] Shell Level... > > What's the use of it? The only use of $SHLVL I can think of is the > answer to the question if ^D will close the last shell or just a > sub shell. I hardly ever ask myself this question. Probably that > starts to become relevant when you open sub shells frequently. I've always just used "set ignoreeof" (first in Csh and later in Ksh), but just in my initial login shell (i.e. set in ~/.login), to prevent ^D from logging me out. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From imp at bsdimp.com Tue Jan 21 10:13:48 2020 From: imp at bsdimp.com (Warner Losh) Date: Mon, 20 Jan 2020 17:13:48 -0700 Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") In-Reply-To: References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com> <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu> <20200120190900.GH15860@mit.edu> Message-ID: On Mon, Jan 20, 2020, 4:06 PM Greg A. Woods wrote: > At Mon, 20 Jan 2020 14:09:00 -0500, "Theodore Y. Ts'o" > wrote: > Subject: Re: [TUHS] Early Linux and BSD (was: On the origins of Linux - > "an academic question") > > > > On Sun, Jan 19, 2020 at 07:32:57PM -0800, Greg A. Woods wrote: > > > > Out of curiosity, did the articles contain download information for a > > > > bootable copy of 386BSD? > > > > > > Yes, they did: > > > > > > > https://www.drdobbs.com/porting-unix-to-the-386-the-final-step/184408800 > > > > .... which is dated July 1992, and describes a "launch" of 386BSD > > Release 0.0 in March 17, 1992. This is contemporaneous with Linux > > 0.95a (which by coincidence was also released on March 17th, 1992.) > > Yes, though as I recall all of the articles mentioned that the OS could > be downloaded, but I pointed at that final article as it was the first > one in which I found explicit mention of the FTP server name(s). > > > The first "real" distribution, the Soft Landing System, was released > > in May 1992. (The Manchester Computer Centre distribution in November > > 1991 was a floppy-based distro containing command-line and development > > utilities, but not X Windows, so some people don't feel it counts as a > > full-featured distribution.) > > The actual 386bsd Release 0.0 (the one done directly by Bill and Lynne > Jolitz) announcement is dated "March 7, 1992" according to the first > post about it on comp.unix.bsd (and according to that announcement there > was a meeting at Apple in Cupertino (SVNet) on the 11'th where copies of > the floppies were made available for copying (comp.unix.bsd: > <2763 at tardis.Tymnet.COM>). > > Note that according to an article from Unigram ("Issue 396", dated > August 3-7, 1992, (p)re-posted by Tom Limoncelli in comp.unix.bsd) this > "386bsd 0.0" was actually a re-write of earlier work to create a "386" > based release of BSD. Apparently UCB lawyers asked Jolitz to destroy > all the initial work done for the release, and he complied and rewrote > what became 0.0 from scratch again, starting with the plain NET2 > release. (comp.unix.bsd: <1992Aug1.020513.14170 at plts.uucp>) > > I would argue that in one way of looking at things NetBSD (and by > extension FreeBSD) really started with the 0.0 patch kit, and that's > also dated March 15, 1992 by Chris Demetriou. I agree though that the > creation of the first commits in the CVS repository represent a more > direct reflection of the intent to create a unique thing called NetBSD. > Lots of people were building CVS repos based on the patchkits... Chris wasn't trying to start a project, but more was trying to find a way of organizing everything that people were working on. At least that's what I recall from the rumors I'd heard on campus after Chris visited Boulder... Warner (On March 13, 1992 there was a post by Mike Stump on comp.unix.bsd > asking for someone to coordinate patches for 386bsd; and Pace Willisson > posted the first patch in response on March 14, 1992; and Chris replied > on the same day saying he would put such patches up on > agate.berkeley.edu; and the "README.PATCHES" file appeared there on > March 15, 1992.) > > -- > Greg A. Woods > > Kelowna, BC +1 250 762-7675 RoboHack > Planix, Inc. Avoncote Farms > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at bitblocks.com Tue Jan 21 10:44:32 2020 From: bakul at bitblocks.com (Bakul Shah) Date: Mon, 20 Jan 2020 16:44:32 -0800 Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") In-Reply-To: Your message of "Mon, 20 Jan 2020 12:19:25 -0500." References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com> <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu> Message-ID: <20200121004439.4A5AD156E448@mail.bitblocks.com> On Mon, 20 Jan 2020 12:19:25 -0500 Clem Cole wrote: > > I bring this all up in hopes to try to close this rat hole of Linux, *vs*. Ha! > *BSD. Like editors, we all have our own favorites. That's cool, we don't > want one thing to be forced down our throat. Having a choice is what is > good. And what I value, Larry or Jon may not necessarily like. Most of > us if not all on this list probably want something that approximates Ken > and Dennis's original ideas not what IBM, DEC, CDC were trying to make us > use in the old days or what Microsoft calls a system today. I want an *evolution* of their original ideas. Instead we have significantly more complicated systems which may be more efficient but certainly a lot more bloaty and less flexible (with a few exceptions). [Ties in with the single system idea] > The discussion of how we got there and what people valued at the time is > useful so we can try to remember the history and learn from it; but getting > into right/wrong, good/bad, or you could have had this is a tad tiresome; > IMO. +1 From lars at nocrew.org Tue Jan 21 16:58:12 2020 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 21 Jan 2020 06:58:12 +0000 Subject: [TUHS] Early Linux and BSD In-Reply-To: <202001201946.00KJk5er3071186@darkstar.fourwinds.com> (Jon Steinhart's message of "Mon, 20 Jan 2020 11:46:05 -0800") References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com> <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu> <20200120180432.GJ28686@mcvoy.com> <202001201946.00KJk5er3071186@darkstar.fourwinds.com> Message-ID: <7wk15l70u3.fsf@junk.nocrew.org> Jon Steinhart wrote: > The 32032 made sense for the workstation division based on the data sheets. > But, it turned out to be extremely buggy, and unlike the 68K I don't recall > the ability to look at and patch the state of the microcode. Did you have the ability to look at and patch the state of 68000 microcode? How? From clemc at ccc.com Wed Jan 22 00:30:39 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 21 Jan 2020 09:30:39 -0500 Subject: [TUHS] Early Linux and BSD In-Reply-To: <7wk15l70u3.fsf@junk.nocrew.org> References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com> <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu> <20200120180432.GJ28686@mcvoy.com> <202001201946.00KJk5er3071186@darkstar.fourwinds.com> <7wk15l70u3.fsf@junk.nocrew.org> Message-ID: It's possible they added an internal register or two to help save the fault State but I don't think so. We'd have to ask Les Crudele or Nick T. to be sure. As I understand it from my days of commuting with Les to Stellar and his talking about the project on those trips, the only real difference between the 68000 and 68010 was Nick's microcode which was in the mask. I think they may have stepped the mask in a few places for better yields but I understand the impression that was not externally electrical different in function. [Les was the 68000's main logic designer and Nick wrote the microcode]. On Tue, Jan 21, 2020 at 1:59 AM Lars Brinkhoff wrote: > Jon Steinhart wrote: > > The 32032 made sense for the workstation division based on the data > sheets. > > But, it turned out to be extremely buggy, and unlike the 68K I don't > recall > > the ability to look at and patch the state of the microcode. > > Did you have the ability to look at and patch the state of 68000 > microcode? How? > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Wed Jan 22 03:17:36 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Tue, 21 Jan 2020 09:17:36 -0800 Subject: [TUHS] Early Linux and BSD In-Reply-To: <7wk15l70u3.fsf@junk.nocrew.org> References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com> <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu> <20200120180432.GJ28686@mcvoy.com> <202001201946.00KJk5er3071186@darkstar.fourwinds.com> <7wk15l70u3.fsf@junk.nocrew.org> Message-ID: <202001211717.00LHHaxP3280983@darkstar.fourwinds.com> Lars Brinkhoff writes: > Jon Steinhart wrote: > > The 32032 made sense for the workstation division based on the data sheets. > > But, it turned out to be extremely buggy, and unlike the 68K I don't recall > > the ability to look at and patch the state of the microcode. > > Did you have the ability to look at and patch the state of 68000 > microcode? How? My memory is very very very fuzzy on this. I seem to recall that microcode state was pushed onto a stack in certain cases, and that it was possible to fix some problems there for certain weird cases relating to memory management. That's all that I remember about it as that's not the part of things that I was working on, just heard grumbles from other folks about it. Jon From imp at bsdimp.com Wed Jan 22 03:22:38 2020 From: imp at bsdimp.com (Warner Losh) Date: Tue, 21 Jan 2020 10:22:38 -0700 Subject: [TUHS] Early Linux and BSD In-Reply-To: <202001211717.00LHHaxP3280983@darkstar.fourwinds.com> References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com> <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu> <20200120180432.GJ28686@mcvoy.com> <202001201946.00KJk5er3071186@darkstar.fourwinds.com> <7wk15l70u3.fsf@junk.nocrew.org> <202001211717.00LHHaxP3280983@darkstar.fourwinds.com> Message-ID: On Tue, Jan 21, 2020, 10:18 AM Jon Steinhart wrote: > Lars Brinkhoff writes: > > Jon Steinhart wrote: > > > The 32032 made sense for the workstation division based on the data > sheets. > > > But, it turned out to be extremely buggy, and unlike the 68K I don't > recall > > > the ability to look at and patch the state of the microcode. > > > > Did you have the ability to look at and patch the state of 68000 > > microcode? How? > > My memory is very very very fuzzy on this. I seem to recall that microcode > state was pushed onto a stack in certain cases, and that it was possible to > fix some problems there for certain weird cases relating to memory > management. > That's all that I remember about it as that's not the part of things that I > was working on, just heard grumbles from other folks about it. > This isn't for the two cpu design to allow instructions to be restarted after a page fault. Warner Jon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Wed Jan 22 03:25:34 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Tue, 21 Jan 2020 09:25:34 -0800 Subject: [TUHS] Early Linux and BSD In-Reply-To: References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com> <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu> <20200120180432.GJ28686@mcvoy.com> <202001201946.00KJk5er3071186@darkstar.fourwinds.com> <7wk15l70u3.fsf@junk.nocrew.org> <202001211717.00LHHaxP3280983@darkstar.fourwinds.com> Message-ID: <202001211725.00LHPYOO3282464@darkstar.fourwinds.com> Warner Losh writes: > > On Tue, Jan 21, 2020, 10:18 AM Jon Steinhart wrote: > > > Lars Brinkhoff writes: > > > Jon Steinhart wrote: > > > > The 32032 made sense for the workstation division based on the data > > sheets. > > > > But, it turned out to be extremely buggy, and unlike the 68K I don't > > recall > > > > the ability to look at and patch the state of the microcode. > > > > > > Did you have the ability to look at and patch the state of 68000 > > > microcode? How? > > > > My memory is very very very fuzzy on this. I seem to recall that microcode > > state was pushed onto a stack in certain cases, and that it was possible to > > fix some problems there for certain weird cases relating to memory > > management. > > That's all that I remember about it as that's not the part of things that I > > was working on, just heard grumbles from other folks about it. > > > > This isn't for the two cpu design to allow instructions to be restarted > after a page fault. > > Warner > > Jon No, this was using a 68020 with the PMMU. From nobozo at gmail.com Wed Jan 22 03:52:20 2020 From: nobozo at gmail.com (Jon Forrest) Date: Tue, 21 Jan 2020 09:52:20 -0800 Subject: [TUHS] Unix on Zilog Z8000? Message-ID: There's been a lot of discussion about early Unix on Intel, National Semi, Motorola, and Sparc processors. I don't recall if Unix ran on the Z8000, and if not, why not. As I remember the Z8000 was going to be the great white hope that would continue Zilog's success with the Z80 into modern times. But, it obviously didn't happen. Why? Jon From usotsuki at buric.co Wed Jan 22 04:13:13 2020 From: usotsuki at buric.co (Steve Nickolas) Date: Tue, 21 Jan 2020 13:13:13 -0500 (EST) Subject: [TUHS] Unix on Zilog Z8000? In-Reply-To: References: Message-ID: On Tue, 21 Jan 2020, Jon Forrest wrote: > There's been a lot of discussion about early Unix on Intel, National > Semi, Motorola, and Sparc processors. I don't recall if Unix ran on > the Z8000, and if not, why not. > > As I remember the Z8000 was going to be the great white hope that > would continue Zilog's success with the Z80 into modern times. > But, it obviously didn't happen. > > Why? > > Jon > Didn't Coherent run on the Z8K? Though that's not really Unix. -uso. From henry.r.bent at gmail.com Wed Jan 22 04:15:53 2020 From: henry.r.bent at gmail.com (Henry Bent) Date: Tue, 21 Jan 2020 13:15:53 -0500 Subject: [TUHS] Unix on Zilog Z8000? In-Reply-To: References: Message-ID: On Tue, 21 Jan 2020 at 12:53, Jon Forrest wrote: > There's been a lot of discussion about early Unix on Intel, National > Semi, Motorola, and Sparc processors. I don't recall if Unix ran on > the Z8000, and if not, why not. > A tiny bit of research would have answered this question for you: https://en.wikipedia.org/wiki/Zilog_Z8000#Z8000_CPU_based_systems -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Wed Jan 22 04:20:45 2020 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 21 Jan 2020 10:20:45 -0800 Subject: [TUHS] Unix on Zilog Z8000? In-Reply-To: References: Message-ID: <20200121182045.GO26619@mcvoy.com> On Tue, Jan 21, 2020 at 01:15:53PM -0500, Henry Bent wrote: > On Tue, 21 Jan 2020 at 12:53, Jon Forrest wrote: > > > There's been a lot of discussion about early Unix on Intel, National > > Semi, Motorola, and Sparc processors. I don't recall if Unix ran on > > the Z8000, and if not, why not. > > > > A tiny bit of research would have answered this question for you: > https://en.wikipedia.org/wiki/Zilog_Z8000#Z8000_CPU_based_systems Yeah, it ran on the 16 bit one but I looked and couldn't find if they got Unix on the z80000 (which I suspect is what Jon meant). From pechter at gmail.com Wed Jan 22 04:27:22 2020 From: pechter at gmail.com (William Pechter) Date: Tue, 21 Jan 2020 13:27:22 -0500 Subject: [TUHS] Unix on Zilog Z8000? In-Reply-To: References: Message-ID: <455e1c85-8a45-4d20-8653-2274674608ef.maildroid@localhost> IIRC... Zilog had Zeus (a SYSIII version) running. Exxon Office Systems swallowed and regurgitated Zilog. They were a Vax customer in Princeton in the late '80s. I installed one of the Vax 11/780s with the first RM80 I (and my office) ever saw as a brand new Field Service grunt. The US Internal Revenue Service was looking at replacing (Z8000 systems) them with AT&T sold Pyramid boxes when I was there. Then they swallowed NCR and it all fell apart. This was around '94 or so. AT&T and Siemens were both Pyramid OEMs and were about 50% of Pyramid's business (I was told). Anyone have further info? When Exxon pulled the plug on EOS I thing things were up in the air... Bill Sent from pechter at gmail.com -----Original Message----- From: Steve Nickolas To: Jon Forrest Cc: The Unix Heritage Society mailing list Sent: Tue, 21 Jan 2020 13:14 Subject: Re: [TUHS] Unix on Zilog Z8000? On Tue, 21 Jan 2020, Jon Forrest wrote: > There's been a lot of discussion about early Unix on Intel, National > Semi, Motorola, and Sparc processors. I don't recall if Unix ran on > the Z8000, and if not, why not. > > As I remember the Z8000 was going to be the great white hope that > would continue Zilog's success with the Z80 into modern times. > But, it obviously didn't happen. > > Why? > > Jon > Didn't Coherent run on the Z8K? Though that's not really Unix. -uso. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Jan 22 04:28:14 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 21 Jan 2020 13:28:14 -0500 Subject: [TUHS] Unix on Zilog Z8000? In-Reply-To: References: Message-ID: The Onyx box redated all the 68K and later Intel or other systems. John Bass brought one to USENIX to demo in early 1980 ru a V7 port and everyone was blown away. Playing with it. It was a desktop (19" rack) system that worked like a PDP-11. I don't remember the bus, but I would guess it was either custom or Multibus-I. Besides being one of the first non-PDP-11 'ports', the original lockf(2) system call was defined for the database that they had built. John would release the specs to /usr/group later. I remember at one meeting in the early 1980s discussing if file locking needed to be in the original specification (Heinz probably remembers also as the chair of that meeting). I'm not at home, so I don't have the document to see if it was picked up. The argument was that serious computers like VMS or the like ran real databases and without file locking UNIX would never be considered a real OS that people could use. BTW: Joy would later use Bass's call as a model for the 4.2 call, but Joy made the locks advisory, Bass's version was full / mandatory locks. FWIW: I think a search will pick up a number of other Z8000 based systems, but Onyx was the first UNIX box. On Tue, Jan 21, 2020 at 12:53 PM Jon Forrest wrote: > There's been a lot of discussion about early Unix on Intel, National > Semi, Motorola, and Sparc processors. I don't recall if Unix ran on > the Z8000, and if not, why not. > > As I remember the Z8000 was going to be the great white hope that > would continue Zilog's success with the Z80 into modern times. > But, it obviously didn't happen. > > Why? > > Jon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pechter at gmail.com Wed Jan 22 04:32:17 2020 From: pechter at gmail.com (William Pechter) Date: Tue, 21 Jan 2020 13:32:17 -0500 Subject: [TUHS] Unix on Zilog Z8000? In-Reply-To: References: Message-ID: <32a4c33a-1382-4140-89cb-154b25c6d02b.maildroid@localhost> IRS Pyramid buy and 3B2-Mips on Google. https://books.google.com/books?id=a4Jp5vySB-UC&pg=PA100&lpg=PA100&dq=Irs+to+buy+pyramid+at%26t&source=bl&ots=G_oVO6qpOx&sig=ACfU3U3EckPvlhXgj1NGrwhO1lsaBp3iWQ&hl=en&sa=X&ved=2ahUKEwjF1uy2qZXnAhVxmuAKHXhCCqEQ6AEwAHoECAEQAQ#v=onepage&q=Irs%20to%20buy%20pyramid%20at%26t&f=false Sent from pechter at gmail.com -----Original Message----- From: Henry Bent To: Jon Forrest Cc: The Unix Heritage Society mailing list Sent: Tue, 21 Jan 2020 13:17 Subject: Re: [TUHS] Unix on Zilog Z8000? On Tue, 21 Jan 2020 at 12:53, Jon Forrest wrote: > There's been a lot of discussion about early Unix on Intel, National > Semi, Motorola, and Sparc processors. I don't recall if Unix ran on > the Z8000, and if not, why not. > A tiny bit of research would have answered this question for you: https://en.wikipedia.org/wiki/Zilog_Z8000#Z8000_CPU_based_systems -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Jan 22 04:43:10 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 21 Jan 2020 13:43:10 -0500 Subject: [TUHS] Early Linux and BSD In-Reply-To: <202001211717.00LHHaxP3280983@darkstar.fourwinds.com> References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com> <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu> <20200120180432.GJ28686@mcvoy.com> <202001201946.00KJk5er3071186@darkstar.fourwinds.com> <7wk15l70u3.fsf@junk.nocrew.org> <202001211717.00LHHaxP3280983@darkstar.fourwinds.com> Message-ID: On Tue, Jan 21, 2020 at 12:18 PM Jon Steinhart wrote: > My memory is very very very fuzzy on this. I seem to recall that microcode > state was pushed onto a stack in certain cases, State, not the code. In fact, Masscomp having built the first MP UNIX box, ran into this problem early on. Different processor stepping had different internal microcode state on the stack after an IRQ. If you resumed with a processor that was a different processor revision, the wrong state was returned. Will may remember this, but Masscomp issues strick orders to the FE that all CPU boards had to be the revision. You could not just swap a CPU board, they had to go as sets. It was a real bummer. Moto fixed that with the 020 and later devices as more people made MP systems. > ... just heard grumbles from other folks about it. > Probably me ... it took me, tjt and Terry Hayes about 3-4 weeks to figure out that problem. It was not originally documented, other than to state on certain faults X bytes of reserved information was pushed on the stack. BTS: I don't remember, but it may have started with the 68010. Becuase before that, the 'executor' was wait stated and the fixor handled and fixed the fault so the 68000 never actually saw fault in the original Masscomp CPU board. The "MPU" board was the same board with a couple of PAL's changed and an 68010 as the executor. It was allowed to actually fault and do something else while the fixor corrected the fault. But the key is that when the fault was repaired, another executor on a different MPU board could be the processor that 'returned' from the fault. That ended up being a no-no. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Jan 22 04:44:55 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 21 Jan 2020 13:44:55 -0500 Subject: [TUHS] Early Linux and BSD In-Reply-To: References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com> <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu> <20200120180432.GJ28686@mcvoy.com> <202001201946.00KJk5er3071186@darkstar.fourwinds.com> <7wk15l70u3.fsf@junk.nocrew.org> <202001211717.00LHHaxP3280983@darkstar.fourwinds.com> Message-ID: sorry... all *MPU* boards had to be the revision but we may have done the same with the CPU boards. On Tue, Jan 21, 2020 at 1:43 PM Clem Cole wrote: > > > On Tue, Jan 21, 2020 at 12:18 PM Jon Steinhart wrote: > >> My memory is very very very fuzzy on this. I seem to recall that >> microcode >> state was pushed onto a stack in certain cases, > > State, not the code. > > In fact, Masscomp having built the first MP UNIX box, ran into this > problem early on. Different processor stepping had different internal > microcode state on the stack after an IRQ. If you resumed with a processor > that was a different processor revision, the wrong state was returned. > > Will may remember this, but Masscomp issues strick orders to the FE that > all CPU boards had to be the revision. You could not just swap a CPU > board, they had to go as sets. It was a real bummer. > > Moto fixed that with the 020 and later devices as more people made MP > systems. > > > > > >> ... just heard grumbles from other folks about it. >> > Probably me ... it took me, tjt and Terry Hayes about 3-4 weeks to figure > out that problem. It was not originally documented, other than to state > on certain faults X bytes of reserved information was pushed on the stack. > > > BTS: I don't remember, but it may have started with the 68010. > Becuase before that, the 'executor' was wait stated and the fixor handled > and fixed the fault so the 68000 never actually saw fault in the original > Masscomp CPU board. The "MPU" board was the same board with a couple of > PAL's changed and an 68010 as the executor. It was allowed to actually > fault and do something else while the fixor corrected the fault. But the > key is that when the fault was repaired, another executor on a different > MPU board could be the processor that 'returned' from the fault. That > ended up being a no-no. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pete at nomadlogic.org Wed Jan 22 05:02:38 2020 From: pete at nomadlogic.org (Pete Wright) Date: Tue, 21 Jan 2020 11:02:38 -0800 Subject: [TUHS] Apollo Domain/OS Message-ID: <46acce0f-9ce2-958b-9c12-c6d9c7f737d9@nomadlogic.org> Apologies that this isn't specifically a Unix specific question but I was wondering if anyone had insight in running domain/OS and it's relationship to Plan 9 (assuming there is any). One of my early mentors was a former product person at Apollo in Mass. and was nice enough to tell me all sorts of war stories working there.  I had known about Plan9 at the time, and from what he described to me about domain/OS it sounded like there was lots of overlap between the two from a high level design perspective at the least.  I've always been keen to understand if domain/OS grew out of former Bell Labs folks, or how it got started. As an aside, he gifted me a whole bunch of marketing collateral from Apollo (from before the HQ acquisition) that i'd be happy to share if there is any historical value in that.  At the time I was a video/special effects engineer are was amazed at how beneficial having something like domain/OS or Plan9 would have been for us, it felt we were basically trying to accomplish a lot of the same goals by duct taping a bunch of Irix and Linux systems together. Cheers, -pete -- Pete Wright pete at nomadlogic.org @nomadlogicLA From lm at mcvoy.com Wed Jan 22 05:14:15 2020 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 21 Jan 2020 11:14:15 -0800 Subject: [TUHS] Apollo Domain/OS In-Reply-To: <46acce0f-9ce2-958b-9c12-c6d9c7f737d9@nomadlogic.org> References: <46acce0f-9ce2-958b-9c12-c6d9c7f737d9@nomadlogic.org> Message-ID: <20200121191415.GT26619@mcvoy.com> On Tue, Jan 21, 2020 at 11:02:38AM -0800, Pete Wright wrote: > Apologies that this isn't specifically a Unix specific question but I was > wondering if anyone had insight in running domain/OS and it's relationship > to Plan 9 (assuming there is any). It would be news to me if there was overlap. I used apollos at my first job and hated them. Diskless and slow as molasses. The first thing I did was port the cross compiler to the Sun file server and did all my work there. From imp at bsdimp.com Wed Jan 22 05:14:45 2020 From: imp at bsdimp.com (Warner Losh) Date: Tue, 21 Jan 2020 12:14:45 -0700 Subject: [TUHS] Early Linux and BSD In-Reply-To: References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com> <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu> <20200120180432.GJ28686@mcvoy.com> <202001201946.00KJk5er3071186@darkstar.fourwinds.com> <7wk15l70u3.fsf@junk.nocrew.org> <202001211717.00LHHaxP3280983@darkstar.fourwinds.com> Message-ID: On Tue, Jan 21, 2020, 11:46 AM Clem Cole wrote: > sorry... all *MPU* boards had to be the revision but we may have done > the same with the CPU boards. > When did Masscomp ship their first MP system? Warner On Tue, Jan 21, 2020 at 1:43 PM Clem Cole wrote: > >> >> >> On Tue, Jan 21, 2020 at 12:18 PM Jon Steinhart wrote: >> >>> My memory is very very very fuzzy on this. I seem to recall that >>> microcode >>> state was pushed onto a stack in certain cases, >> >> State, not the code. >> >> In fact, Masscomp having built the first MP UNIX box, ran into this >> problem early on. Different processor stepping had different internal >> microcode state on the stack after an IRQ. If you resumed with a processor >> that was a different processor revision, the wrong state was returned. >> >> Will may remember this, but Masscomp issues strick orders to the FE that >> all CPU boards had to be the revision. You could not just swap a CPU >> board, they had to go as sets. It was a real bummer. >> >> Moto fixed that with the 020 and later devices as more people made MP >> systems. >> >> >> >> >> >>> ... just heard grumbles from other folks about it. >>> >> Probably me ... it took me, tjt and Terry Hayes about 3-4 weeks to >> figure out that problem. It was not originally documented, other than >> to state on certain faults X bytes of reserved information was pushed on >> the stack. >> >> BTS: I don't remember, but it may have started with the 68010. >> Becuase before that, the 'executor' was wait stated and the fixor handled >> and fixed the fault so the 68000 never actually saw fault in the original >> Masscomp CPU board. The "MPU" board was the same board with a couple of >> PAL's changed and an 68010 as the executor. It was allowed to actually >> fault and do something else while the fixor corrected the fault. But the >> key is that when the fault was repaired, another executor on a different >> MPU board could be the processor that 'returned' from the fault. That >> ended up being a no-no. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Jan 22 06:27:04 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 21 Jan 2020 15:27:04 -0500 Subject: [TUHS] Early Linux and BSD In-Reply-To: References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com> <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu> <20200120180432.GJ28686@mcvoy.com> <202001201946.00KJk5er3071186@darkstar.fourwinds.com> <7wk15l70u3.fsf@junk.nocrew.org> <202001211717.00LHHaxP3280983@darkstar.fourwinds.com> Message-ID: 1982, the dual-processor MC500/DP originally with 68000s upgraded to 010's shortly after they became available[see below] 1984, the 16 Processor MC5000/700 using '020 [the 500 was renamed the MC5000/500 and a single processor MC5000/300 was also introduced. In the /700 and /300 design the fixor was unneeded and the base 020 serviced it's own faults]. FWIW: Purdue VAX predates the 500/DP, but was a one-off that George made. The Sequent MP box would be about 3 or 4 years later. Through the RTU 2.x, the OS originally ran Purdue VAX-like [*Goble/Marsh: ISCA '82: Proceedings of the 9th annual symposium on Computer Architecture: "A Dual Processor VAX 11/780", **Pages 291–298*] in all interrupts and system calls went to a 'master' and the second MPU/CPU board ran as a 'slave' ( *i.e.* user-mode code). By RTU 3.0 ~12 mons later, full locks were done and each processor could service anything. Note each CPU/MPU board had processor two chips on it, the executor and fixor but the board was really not a multiprocessor - the second chip was literally just running kernel code to service the page fault. Thus (not including the other 68000's processors in graphics or I/O boards) the 500/DP had either 4 68000's or 2 68010 & 2 68000's in it when it had two CPU or two MPU boards in the backplane. The idea was originally proposed for the Z8000 by Forest Baskett at an early Asilomar conference. The formal citation is: Forest Baskett: "*Pascal and Virtual Memory in a Z8000 or MC68000 based Design Station*," COMPCON 80, Digest of Papers, pp 456-459, IEEE Computer Society, Feb. 25, 1980. On Tue, Jan 21, 2020 at 2:14 PM Warner Losh wrote: > > > On Tue, Jan 21, 2020, 11:46 AM Clem Cole wrote: > >> sorry... all *MPU* boards had to be the revision but we may have done >> the same with the CPU boards. >> > > When did Masscomp ship their first MP system? > > Warner > > On Tue, Jan 21, 2020 at 1:43 PM Clem Cole wrote: >> >>> >>> >>> On Tue, Jan 21, 2020 at 12:18 PM Jon Steinhart >>> wrote: >>> >>>> My memory is very very very fuzzy on this. I seem to recall that >>>> microcode >>>> state was pushed onto a stack in certain cases, >>> >>> State, not the code. >>> >>> In fact, Masscomp having built the first MP UNIX box, ran into this >>> problem early on. Different processor stepping had different internal >>> microcode state on the stack after an IRQ. If you resumed with a processor >>> that was a different processor revision, the wrong state was returned. >>> >>> Will may remember this, but Masscomp issues strick orders to the FE that >>> all CPU boards had to be the revision. You could not just swap a CPU >>> board, they had to go as sets. It was a real bummer. >>> >>> Moto fixed that with the 020 and later devices as more people made MP >>> systems. >>> >>> >>> >>> >>> >>>> ... just heard grumbles from other folks about it. >>>> >>> Probably me ... it took me, tjt and Terry Hayes about 3-4 weeks to >>> figure out that problem. It was not originally documented, other than >>> to state on certain faults X bytes of reserved information was pushed on >>> the stack. >>> >>> BTS: I don't remember, but it may have started with the 68010. >>> Becuase before that, the 'executor' was wait stated and the fixor handled >>> and fixed the fault so the 68000 never actually saw fault in the original >>> Masscomp CPU board. The "MPU" board was the same board with a couple of >>> PAL's changed and an 68010 as the executor. It was allowed to actually >>> fault and do something else while the fixor corrected the fault. But the >>> key is that when the fault was repaired, another executor on a different >>> MPU board could be the processor that 'returned' from the fault. That >>> ended up being a no-no. >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Wed Jan 22 06:42:32 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Tue, 21 Jan 2020 13:42:32 -0700 Subject: [TUHS] Shell Level... In-Reply-To: <20200120083928.GA68939@wopr> References: <1itSE0-5Td-00@marmaro.de> <20200120083928.GA68939@wopr> Message-ID: <98babe9c-5599-1448-f8e0-b3cd25499b5d@spamtrap.tnetconsulting.net> On 1/20/20 1:39 AM, Kurt H Maier wrote: > The other, more common use I've seen is to e.g. clear the terminal window > on logout (e.g. in .bash_logout when SHLVL=1) but not when exiting any > nested shell. Interesting use case. Thank you for sharing Kurt. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From gtaylor at tnetconsulting.net Wed Jan 22 06:44:07 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Tue, 21 Jan 2020 13:44:07 -0700 Subject: [TUHS] Shell Level... In-Reply-To: <20200120194057.GI15860@mit.edu> References: <1itSE0-5Td-00@marmaro.de> <20200120194057.GI15860@mit.edu> Message-ID: <75e10412-9719-c950-a808-19bc0a101f5a@spamtrap.tnetconsulting.net> On 1/20/20 12:40 PM, Theodore Y. Ts'o wrote: > The normal reason why I'm starting subshells is because I need to control > various environment variables on an ad-hoc basis. It might be PYTHONPATH, > KRB5CCNAME, GPG_AGENT_INFO, LD_LIBRARY_PATH, or some combination of > the above. Back when I was regularly using Kerberos root/admin bits, I > had some hard-coded shell aliases to indicate explicitly I was in a shell > that was using my tytso/root at ATHENA.MIT.EDU or tytso/admin at ATHENA.MIT.EDU > kerberos tickets. If I'm understanding you correctly, you used a sub-shell with a modified / task / process specific environment. Correct? Thank you for sharing Theodore. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From gtaylor at tnetconsulting.net Wed Jan 22 06:46:14 2020 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Tue, 21 Jan 2020 13:46:14 -0700 Subject: [TUHS] Shell Level... In-Reply-To: References: <1itSE0-5Td-00@marmaro.de> Message-ID: <2c366d0e-b679-a856-edb3-a9962f58c50b@spamtrap.tnetconsulting.net> On 1/20/20 4:55 PM, Greg A. Woods wrote: > I've always just used "set ignoreeof" (first in Csh and later in Ksh), > but just in my initial login shell (i.e. set in ~/.login), to prevent > ^D from logging me out. It sounds like you're making your initial / login shell behave differently based on the shell level. Conceptually similar to Kurt's example, just changing a different aspect of your shell. Thank you for sharing Greg. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4013 bytes Desc: S/MIME Cryptographic Signature URL: From heinz at osta.com Wed Jan 22 07:07:07 2020 From: heinz at osta.com (Heinz Lycklama) Date: Tue, 21 Jan 2020 13:07:07 -0800 Subject: [TUHS] Unix on Zilog Z8000? In-Reply-To: References: Message-ID: <85e9f90a-8ab2-2c43-f7a8-7a34e96bd9e8@osta.com> That is correct. John Bass did contribute the lockf(2) system call to the /usr/group standard. It is in the 1984 document. Heinz On 1/21/2020 10:28 AM, Clem Cole wrote: > The Onyx box redated all the 68K and later Intel or other systems.  >  John Bass brought one to USENIX to demo in early 1980 ru a V7 port > and everyone was blown away. Playing with it. It was a desktop (19" > rack) system that worked like a PDP-11.   I don't remember the bus, > but I would guess it was either custom or Multibus-I. > > Besides being one of the first non-PDP-11 'ports', the original > lockf(2) system call was defined for the database that they had built. > John would release the specs to /usr/group later.  I remember at one > meeting in the early 1980s discussing if file locking needed to be in > the original specification (Heinz probably remembers also as the chair > of that meeting).  I'm not at home, so I don't have the document to > see if it was picked up.  The argument was that serious computers like > VMS or the like ran real databases and without file locking UNIX would > never be considered a real OS that people could use. > > BTW: Joy would later use Bass's call as a model for the 4.2 call, but > Joy made the locks advisory, Bass's version was full / mandatory locks. > > FWIW: I think a search will pick up a number of other Z8000 based > systems, but Onyx was the first UNIX box. > > On Tue, Jan 21, 2020 at 12:53 PM Jon Forrest > wrote: > > There's been a lot of discussion about early Unix on Intel, National > Semi, Motorola, and Sparc processors. I don't recall if Unix ran on > the Z8000, and if not, why not. > > As I remember the Z8000 was going to be the great white hope that > would continue Zilog's success with the Z80 into modern times. > But, it obviously didn't happen. > > Why? > > Jon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nobozo at gmail.com Wed Jan 22 07:24:00 2020 From: nobozo at gmail.com (Jon Forrest) Date: Tue, 21 Jan 2020 13:24:00 -0800 Subject: [TUHS] Unix on Zilog Z8000? In-Reply-To: References: Message-ID: <83795ac7-9ea1-82ba-d7c2-4f9705ca8935@gmail.com> On 1/21/2020 10:15 AM, Henry Bent wrote: > There's been a lot of discussion about early Unix on Intel, National > Semi, Motorola, and Sparc processors. I don't recall if Unix ran on > the Z8000, and if not, why not. > > > A tiny bit of research would have answered this question for you: > https://en.wikipedia.org/wiki/Zilog_Z8000#Z8000_CPU_based_systems True, but sometimes oldtimers like those of us who hang out here remember additional, or different, things than what Wikipedia pages say. Jon From crossd at gmail.com Wed Jan 22 07:28:16 2020 From: crossd at gmail.com (Dan Cross) Date: Tue, 21 Jan 2020 16:28:16 -0500 Subject: [TUHS] Apollo Domain/OS In-Reply-To: <46acce0f-9ce2-958b-9c12-c6d9c7f737d9@nomadlogic.org> References: <46acce0f-9ce2-958b-9c12-c6d9c7f737d9@nomadlogic.org> Message-ID: To my knowledge, there was never a link between Plan 9 and Domain/OS. As I understood it, Domain/OS was more influenced by Multics and maybe the Pr1me machines than anything else. Plan 9 came from the Unix heritage (and thus had Multics as a grandparent, in a manner of speaking). If there was any connection at all, I suspect it was tenuous and more in the form of an indirect influence, such as an idea someone got from a paper or something like that. - Dan C. On Tue, Jan 21, 2020 at 2:11 PM Pete Wright wrote: > Apologies that this isn't specifically a Unix specific question but I > was wondering if anyone had insight in running domain/OS and it's > relationship to Plan 9 (assuming there is any). > > One of my early mentors was a former product person at Apollo in Mass. > and was nice enough to tell me all sorts of war stories working there. > I had known about Plan9 at the time, and from what he described to me > about domain/OS it sounded like there was lots of overlap between the > two from a high level design perspective at the least. I've always been > keen to understand if domain/OS grew out of former Bell Labs folks, or > how it got started. > > As an aside, he gifted me a whole bunch of marketing collateral from > Apollo (from before the HQ acquisition) that i'd be happy to share if > there is any historical value in that. At the time I was a > video/special effects engineer are was amazed at how beneficial having > something like domain/OS or Plan9 would have been for us, it felt we > were basically trying to accomplish a lot of the same goals by duct > taping a bunch of Irix and Linux systems together. > > Cheers, > -pete > > -- > Pete Wright > pete at nomadlogic.org > @nomadlogicLA > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfawcus+lists-tuhs at employees.org Wed Jan 22 07:32:51 2020 From: dfawcus+lists-tuhs at employees.org (Derek Fawcus) Date: Tue, 21 Jan 2020 21:32:51 +0000 Subject: [TUHS] Onyx (was Re: Unix on Zilog Z8000?) In-Reply-To: References: Message-ID: <20200121213251.GA25322@clarinet.employees.org> On Tue, Jan 21, 2020 at 01:28:14PM -0500, Clem Cole wrote: > The Onyx box redated all the 68K and later Intel or other systems. That was a fun bit of grubbing around courtesy of a bitsavers mirror (https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/onyx/). It seems they started with a board based upon the non-segmented Z8002 and only later switched to using the segmented Z8001. In the initial board, they created their own MMU: Page 6 of: https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/onyx/c8002/Onyx_C8002_Brochure.pdf Memory Management Controller: The Memory Management Controller (MMC) enables the C8002 to perform address translation, memory block protection, and separation of instruction and data spaces. Sixteen independent map sets are implemented, with each map set consisting of an instruction map and a data map. Within each map there are 32 page registers. Each page register relocates and validates a 2K byte page. The MMC generates a 20 bit address allowing the C8002 to access up to one Mbyte of physical memory. So I'd guess the MMC was actually programed through I/O instuctions to io space, and hence preserved the necessary protection domains. Cute. I've had a background interest in the Z8000 (triggered by reading a Z80000 datasheet around 87/88), and always though about using the segmented rather than unsegmented device. The following has a bit more info about the version of System III ported to their boxes: https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/onyx/c8002/UNIX_3.0.3_Software_Release_Notice_May83.pdf DF From nw at retrocomputingtasmania.com Wed Jan 22 07:48:37 2020 From: nw at retrocomputingtasmania.com (Nigel Williams) Date: Wed, 22 Jan 2020 08:48:37 +1100 Subject: [TUHS] Unix on Zilog Z8000? In-Reply-To: <20200121182045.GO26619@mcvoy.com> References: <20200121182045.GO26619@mcvoy.com> Message-ID: On Wed, Jan 22, 2020 at 5:22 AM Larry McVoy wrote: > Yeah, it ran on the 16 bit one but I looked and couldn't find if they > got Unix on the z80000 (which I suspect is what Jon meant). I spent some time attempting to confirm whether the Z80000 (the 32-bit flat address space development of the Z8000) ever went to silicon and was not able to confirm it did. My suspicion remains that the Z80000 was only ever a paper specification and did not even get to a first spin. If anyone knows and has some evidence I would be glad to update the wikipedia page. From dfawcus+lists-tuhs at employees.org Wed Jan 22 07:57:46 2020 From: dfawcus+lists-tuhs at employees.org (Derek Fawcus) Date: Tue, 21 Jan 2020 21:57:46 +0000 Subject: [TUHS] Tech Sq elevator (Was: screen editors) [ really I think efficiency now ] In-Reply-To: References: <202001122034.00CKYQ39571239@darkstar.fourwinds.com> <202001122044.00CKiUNV573279@darkstar.fourwinds.com> <202001122137.00CLbMrw582813@darkstar.fourwinds.com> Message-ID: <20200121215746.GB25322@clarinet.employees.org> On Sat, Jan 18, 2020 at 09:45:22AM -0600, Michael Parson wrote: > > And here, understanding the model is important, namely, grep is the > wrong tool for searching/parsing JSON output. Dealing with JSON from the > shell, you should use jq. I've been dragged kicking and screaming into > dealing with JSON, and about all I can say about it is, I like it about > this >< much more than XML. :) If push comes to shove, one can always use xmlawk (xml extension for gawk) to beat the latter in to submission. DF From henry.r.bent at gmail.com Wed Jan 22 08:00:50 2020 From: henry.r.bent at gmail.com (Henry Bent) Date: Tue, 21 Jan 2020 17:00:50 -0500 Subject: [TUHS] Unix on Zilog Z8000? In-Reply-To: References: <20200121182045.GO26619@mcvoy.com> Message-ID: On Tue, 21 Jan 2020 at 16:49, Nigel Williams wrote: > On Wed, Jan 22, 2020 at 5:22 AM Larry McVoy wrote: > > Yeah, it ran on the 16 bit one but I looked and couldn't find if they > > got Unix on the z80000 (which I suspect is what Jon meant). > > I spent some time attempting to confirm whether the Z80000 (the 32-bit > flat address space development of the Z8000) ever went to silicon and > was not able to confirm it did. My suspicion remains that the Z80000 > was only ever a paper specification and did not even get to a first > spin. If anyone knows and has some evidence I would be glad to update > the wikipedia page. > This thread reminded me that I own a copy of the Zilog "1983/84 Components Data Book," which I am talking to Al Kossow about scanning. It fully details the Z80,000 on paper but does not say anything about hardware, everything is labeled preliminary. It is dated September 1983. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmhanson at eschatologist.net Wed Jan 22 07:52:59 2020 From: cmhanson at eschatologist.net (Chris Hanson) Date: Tue, 21 Jan 2020 13:52:59 -0800 Subject: [TUHS] Apollo Domain/OS In-Reply-To: References: Message-ID: My understanding is that there’s a direct line from MULTICS to Prime to Apollo, in that Apollo was founded by former Prime folks who took their philosophy with them. Apollo’s operating system (Aegis, Domain, Domain/OS) had a lot of good and interesting ideas and was quite influential despite the relatively small number of people who used it. A lot of what we take for granted today in distributed computing came via Apollo more than anywhere else, as Apollo users and alumni took what they learned to other systems. — Chris From drb at msu.edu Wed Jan 22 08:09:53 2020 From: drb at msu.edu (Dennis Boone) Date: Tue, 21 Jan 2020 17:09:53 -0500 Subject: [TUHS] Apollo Domain/OS In-Reply-To: (Your message of Tue, 21 Jan 2020 13:52:59 -0800.) References: Message-ID: <20200121220953.8B49716DBEB@yagi.h-net.msu.edu> > My understanding is that there’s a direct line from MULTICS to Prime > to Apollo, in that Apollo was founded by former Prime folks who took > their philosophy with them. Among others, and perhaps key, Bill Poduska, Prime's VP Engineering. De From jsteve at superglobalmegacorp.com Wed Jan 22 08:35:59 2020 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Tue, 21 Jan 2020 22:35:59 +0000 (UTC) Subject: [TUHS] Unix on Zilog Z8000? In-Reply-To: <20200121182045.GO26619@mcvoy.com> References: <20200121182045.GO26619@mcvoy.com> Message-ID: <25E62EB5E090E7CB.f810e0c9-fa0e-409f-880d-5f8dc51ff5e7@mail.outlook.com> The only one I know is Coherent.  Disk images recently surfaced https://www.autometer.de/unix4fun/coherent/ftp/distrib/Coherent-0.7/ This is for the Commodore B 900 prototype. http://www.floodgap.com/retrobits/ckb/secret/900.html Get Outlook for Android On Wed, Jan 22, 2020 at 2:22 AM +0800, "Larry McVoy" wrote: On Tue, Jan 21, 2020 at 01:15:53PM -0500, Henry Bent wrote: > On Tue, 21 Jan 2020 at 12:53, Jon Forrest wrote: > > > There's been a lot of discussion about early Unix on Intel, National > > Semi, Motorola, and Sparc processors. I don't recall if Unix ran on > > the Z8000, and if not, why not. > > > > A tiny bit of research would have answered this question for you: > https://en.wikipedia.org/wiki/Zilog_Z8000#Z8000_CPU_based_systems Yeah, it ran on the 16 bit one but I looked and couldn't find if they got Unix on the z80000 (which I suspect is what Jon meant). -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfawcus+lists-tuhs at employees.org Wed Jan 22 08:36:55 2020 From: dfawcus+lists-tuhs at employees.org (Derek Fawcus) Date: Tue, 21 Jan 2020 22:36:55 +0000 Subject: [TUHS] Unix on Zilog Z8000? In-Reply-To: References: <20200121182045.GO26619@mcvoy.com> Message-ID: <20200121223655.GA54133@clarinet.employees.org> On Tue, Jan 21, 2020 at 05:00:50PM -0500, Henry Bent wrote: > > This thread reminded me that I own a copy of the Zilog "1983/84 Components > Data Book," which I am talking to Al Kossow about scanning. It fully > details the Z80,000 on paper but does not say anything about hardware, > everything is labeled preliminary. It is dated September 1983. http://bitsavers.trailing-edge.com/components/zilog/_dataBooks/1983_84_Components_Data_Book.pdf DF From clemc at ccc.com Wed Jan 22 08:36:57 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 21 Jan 2020 17:36:57 -0500 Subject: [TUHS] Apollo Domain/OS In-Reply-To: References: Message-ID: On Tue, Jan 21, 2020 at 5:03 PM Chris Hanson wrote: > My understanding is that there’s a direct line from MULTICS to Prime to > Apollo, Yes in some ways... > in that Apollo was founded by former Prime folks who took their philosophy > with them. > Actually not quite. MIT/Multics to Honeywell to Pr1me to Apollo (to Belmont/Stellar) Bill P and his former TA from MIT (Mike Spourer) actually wanted to break a little when they did Apollo. The whole ideas was too risky for Honeywell, so he created Pr1me. Apollo was too risky for Pr1me so he created Apollo. Stellar was too risky for Apollo so he created Belmont - a.k.a. Stellar. [By the way, I spoke to Bill over the holidays. He's a still the same]. > > Apollo’s operating system (Aegis, Domain, Domain/OS) had a lot of good and > interesting ideas and was quite influential I absolutely agree. But a number new idea were from an influx of MIT and ex-DEC folks actually. And that that terrible sin called the registry that lives on winders came from Paul (some of us thought it was a bad idea then too BTW). IMO: The best idea was the typed file system and the ability to run user code specific with a file type. That's how IP, TCP, UDP are all implemented. Very, very cool. There is a USENIX paper that describes it I'll have to dig up the reference. It's worth reading. But I have never seen it implemented again as well. > A lot of what we take for granted today in distributed computing came via > Apollo more than anywhere else, as Apollo users and alumni took what they > learned to other systems. > Yes and no. I agree it was a wonderful intellectual playground for some very cool ideas. Some worked pretty well, but not all did. For example, as Larry said earlier today, the "twin'ed" or diskless nodes were awful (replace the S with C for what many of us think about them). But it got Sun to make them too and ended up being a great add-in disk business later. I refused at Masscomo and ended up losing war, even though the cost of a WS500 was less than a Sun2 with a disk, people bought Sun's diskless and then after they discovered they sucked, spent another 6K to buy a desk system for them (we lost for economics, but I was technically right - a.k.a. Cole's law of economics vs. sophisticated technology). Anyway, we (as a community) are better for having that system but other than the registry, I can think of little actual technology that we continue to use from Aegis. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.bowling at kev009.com Wed Jan 22 08:43:51 2020 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Tue, 21 Jan 2020 15:43:51 -0700 Subject: [TUHS] Apollo Domain/OS In-Reply-To: References: Message-ID: On Tue, Jan 21, 2020 at 3:39 PM Clem Cole wrote: > > > > On Tue, Jan 21, 2020 at 5:03 PM Chris Hanson wrote: >> >> My understanding is that there’s a direct line from MULTICS to Prime to Apollo, > > Yes in some ways... > > >> >> in that Apollo was founded by former Prime folks who took their philosophy with them. > > Actually not quite. MIT/Multics to Honeywell to Pr1me to Apollo (to Belmont/Stellar) Bill P and his former TA from MIT (Mike Spourer) actually wanted to break a little when they did Apollo. The whole ideas was too risky for Honeywell, so he created Pr1me. Apollo was too risky for Pr1me so he created Apollo. Stellar was too risky for Apollo so he created Belmont - a.k.a. Stellar. > > [By the way, I spoke to Bill over the holidays. He's a still the same]. I respect someone that is willing to put their time (and money?) where their mouth is like that. Would he be willing to write up some post-mortems on some of these? I believe at least late Apollo and Stellar can qualify as unix? >> >> >> Apollo’s operating system (Aegis, Domain, Domain/OS) had a lot of good and interesting ideas and was quite influential > > I absolutely agree. > > But a number new idea were from an influx of MIT and ex-DEC folks actually. And that that terrible sin called the registry that lives on winders came from Paul (some of us thought it was a bad idea then too BTW). > > IMO: The best idea was the typed file system and the ability to run user code specific with a file type. That's how IP, TCP, UDP are all implemented. Very, very cool. There is a USENIX paper that describes it I'll have to dig up the reference. It's worth reading. But I have never seen it implemented again as well. > > > >> >> A lot of what we take for granted today in distributed computing came via Apollo more than anywhere else, as Apollo users and alumni took what they learned to other systems. > > Yes and no. I agree it was a wonderful intellectual playground for some very cool ideas. Some worked pretty well, but not all did. For example, as Larry said earlier today, the "twin'ed" or diskless nodes were awful (replace the S with C for what many of us think about them). But it got Sun to make them too and ended up being a great add-in disk business later. I refused at Masscomo and ended up losing war, even though the cost of a WS500 was less than a Sun2 with a disk, people bought Sun's diskless and then after they discovered they sucked, spent another 6K to buy a desk system for them (we lost for economics, but I was technically right - a.k.a. Cole's law of economics vs. sophisticated technology). > > Anyway, we (as a community) are better for having that system but other than the registry, I can think of little actual technology that we continue to use from Aegis. From tytso at mit.edu Wed Jan 22 09:00:25 2020 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Tue, 21 Jan 2020 18:00:25 -0500 Subject: [TUHS] Apollo Domain/OS In-Reply-To: References: Message-ID: <20200121230025.GL15860@mit.edu> On Tue, Jan 21, 2020 at 05:36:57PM -0500, Clem Cole wrote: > > A lot of what we take for granted today in distributed computing came via > > Apollo more than anywhere else, as Apollo users and alumni took what they > > learned to other systems. > > Anyway, we (as a community) are better for having that system but other > than the registry, I can think of little actual technology that we continue > to use from Aegis. The OSF/DCE's RPC system came from Apollo, as does the predecessor for the UUID layout still in use today (RFC 4122). Paul Leach brought both to the OSF, and as the Kerberos V5 Tech Lead, I worked with Paul, and used an early Internet-Draft spec of the OSF UUID and implemented it in e2fsprogs for labelling ext2/3/4 superblocks, and from there the infection vector spread to the GNOME project. When Paul brought both of those technologies to Microsoft when he went there after OSF went belly up. - Ted From tytso at mit.edu Wed Jan 22 09:10:23 2020 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Tue, 21 Jan 2020 18:10:23 -0500 Subject: [TUHS] Shell Level... In-Reply-To: <75e10412-9719-c950-a808-19bc0a101f5a@spamtrap.tnetconsulting.net> References: <1itSE0-5Td-00@marmaro.de> <20200120194057.GI15860@mit.edu> <75e10412-9719-c950-a808-19bc0a101f5a@spamtrap.tnetconsulting.net> Message-ID: <20200121231023.GM15860@mit.edu> On Tue, Jan 21, 2020 at 01:44:07PM -0700, Grant Taylor via TUHS wrote: > On 1/20/20 12:40 PM, Theodore Y. Ts'o wrote: > > The normal reason why I'm starting subshells is because I need to > > control various environment variables on an ad-hoc basis. It might be > > PYTHONPATH, KRB5CCNAME, GPG_AGENT_INFO, LD_LIBRARY_PATH, or some > > combination of the above. Back when I was regularly using Kerberos > > root/admin bits, I had some hard-coded shell aliases to indicate > > explicitly I was in a shell that was using my tytso/root at ATHENA.MIT.EDU > > or tytso/admin at ATHENA.MIT.EDU kerberos tickets. > > If I'm understanding you correctly, you used a sub-shell with a modified / > task / process specific environment. Correct? Correct. And I would often suspend the shell when I didn't need to use the Kerberos administration credentials, and then go back to it later when I did need it, and since I was often bouncing back and forth between the sub-shell and the parent shell, having the SHLVL displayed in the prompt for non-top-level shells was useful. For similar reasons, my shell prompt will also display what git branch I happen to be one. For example: {/usr/projects/e2fsprogs/e2fsprogs-maint}, level 2 (debian/master) 1001% Says that I'm on the debian/master git branch, and "level 2" indicates that I'm in a subshell. (If I'm in a top level shell, no level will be printed at all.) The prompt also displays the hostname ("lambda" in this case") which is super-useful to identify remote logins. - Ted From woods at robohack.ca Wed Jan 22 09:39:16 2020 From: woods at robohack.ca (Greg A. Woods) Date: Tue, 21 Jan 2020 15:39:16 -0800 Subject: [TUHS] Shell Level... In-Reply-To: <2c366d0e-b679-a856-edb3-a9962f58c50b@spamtrap.tnetconsulting.net> References: <1itSE0-5Td-00@marmaro.de> <2c366d0e-b679-a856-edb3-a9962f58c50b@spamtrap.tnetconsulting.net> Message-ID: At Tue, 21 Jan 2020 13:46:14 -0700, Grant Taylor via TUHS wrote: Subject: Re: [TUHS] Shell Level... > > [1 ] > On 1/20/20 4:55 PM, Greg A. Woods wrote: > > I've always just used "set ignoreeof" (first in Csh and later in > > Ksh), but just in my initial login shell (i.e. set in ~/.login), to > > prevent ^D from logging me out. > > It sounds like you're making your initial / login shell behave > differently based on the shell level. More like the other way around -- all sub-shells behave differently based on the fact they're not login shells. Note I also considered (and still consider) all initial shells in each "window" to be a "login" shell. In the days of "layers" (e.g. on the DMD5620) I did that by inspecting the environment to look for clues that the shell was started by "layers", but ever since X11 took over my life (and my DMDs have been scrapped and/or put into storage) I've used XTerm's "-ls" option to make the shell a "real" login shell. The $LEV (or $SHLVL) value is just an indicator, one that I only ever used as a visual cue/clue. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From woods at robohack.ca Wed Jan 22 09:45:27 2020 From: woods at robohack.ca (Greg A. Woods) Date: Tue, 21 Jan 2020 15:45:27 -0800 Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") In-Reply-To: References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com> <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu> <20200120190900.GH15860@mit.edu> Message-ID: At Mon, 20 Jan 2020 17:13:48 -0700, Warner Losh wrote: Subject: Re: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") > > Lots of people were building CVS repos based on the patchkits... Chris > wasn't trying to start a project, but more was trying to find a way of > organizing everything that people were working on. At least that's what I > recall from the rumors I'd heard on campus after Chris visited Boulder... Indeed, that is no doubt a far more accurate way of stating things. I was only watching from afar, effectively. Of course it didn't take too long before he announced 0.8 and made it all official. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From ron at ronnatalie.com Wed Jan 22 09:53:00 2020 From: ron at ronnatalie.com (Ronald Natalie) Date: Tue, 21 Jan 2020 18:53:00 -0500 Subject: [TUHS] Apollo Domain/OS In-Reply-To: References: <46acce0f-9ce2-958b-9c12-c6d9c7f737d9@nomadlogic.org> Message-ID: Apollo gave us the long term use of a DN1000. I ported our image processing system to it. The amusing thing was when you fired up an X window manager on the thing, it wrapped all three segments of the little status bar at the bottom with window borders. The DN10000 docs came with a beautiful 5 volume set that described all the internals. It was quite detailed for what was there. What I really needed was the documentation on the graphics system which was in Volume 3. My set was missing this. After much digging around Apollo, it turns out that they never wrote volume 3, just assigned the volume number to some yet to be written document. I learned the hard way not to open the gull wing doors on the thing while someone was using it. When HP/Apollo merged and they formally pulled the plug on Domain, I was over at the FAA and they showed me the “latest” computer they got in that was running a system to show where all the planes in the airspace system were (think of FlightAware.COM , this was a first stab at pulling that data from the ATC computers). It was a DN4000? running domain. Always using the latest stuff at the FAA. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sauer at technologists.com Wed Jan 22 08:58:10 2020 From: sauer at technologists.com (Charles H Sauer) Date: Tue, 21 Jan 2020 16:58:10 -0600 Subject: [TUHS] Apollo Domain/OS In-Reply-To: References: Message-ID: <317a33f8-ff97-21a0-aa2c-e9821b8f3d13@technologists.com> On 1/21/2020 4:36 PM, Clem Cole wrote: > Anyway, we (as a community) are better for having that system but other > than the registry, I can think of little actual technology that we > continue to use from Aegis. don't forget UIDs/UUIDs/GUIDs -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Skype/Twitter: CharlesHSauer From woods at robohack.ca Wed Jan 22 10:14:00 2020 From: woods at robohack.ca (Greg A. Woods) Date: Tue, 21 Jan 2020 16:14:00 -0800 Subject: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") In-Reply-To: <20200120180432.GJ28686@mcvoy.com> References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com> <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu> <20200120180432.GJ28686@mcvoy.com> Message-ID: At Mon, 20 Jan 2020 10:04:32 -0800, Larry McVoy wrote: Subject: Re: [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") > > I know those Nat Semi chips very well, or did at the time. I so wanted to > love those chips, the instruction set felt like whoever did the PDP-11 > did the 320xx chips. But they couldn't produce chips without bugs and > that killed them. It's a crying shame, I liked the instruction set > WAY better than the VAX. The VAX seemed really messing compared to > the PDP-11, the 320xx chips seemed clean. Might be rose colored > glasses but that's my memory. I held a lot of anticipation for the NS chips as well, and I remember well excitedly going around to trade shows for a year or two and playing around with the very few Unix systems based on them that showed up on occasion. From what I understand it was really only the original NS32016 that was too buggy to be trusted. The NS32032 was a bug-fix release that also came a full 32-bit external bus, and the NS32532 a while later was quite a contender at the time in terms of performance (wikipedia says "about twice as performant as the competing MC68030 and i80386"). In the end though I discovered the ATT 3b2 systems and their also quite nicely orthogonal WE32000 CPUs (though in the end I never did write more than a very simple demo program in assembler, just to know I could). My copy of the WE32100 Information Manual sits right beside my VAX Instruction Reference Manual. Sadly the 3B2s I had were never as powerful as a PC532 was though -- more like the sluggish i386 and m68k systems of the day. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From clemc at ccc.com Wed Jan 22 10:20:57 2020 From: clemc at ccc.com (Clem Cole) Date: Tue, 21 Jan 2020 19:20:57 -0500 Subject: [TUHS] Apollo Domain/OS In-Reply-To: <20200121230025.GL15860@mit.edu> References: <20200121230025.GL15860@mit.edu> Message-ID: Ted point taken. As I was driving home tonight I thought about both DCE and UUIDs. The later is clearly important and we do owe the guys in Chelmsford a great thank you for that one. But the registry ... really now. On Tue, Jan 21, 2020 at 6:00 PM Theodore Y. Ts'o wrote: > On Tue, Jan 21, 2020 at 05:36:57PM -0500, Clem Cole wrote: > > > A lot of what we take for granted today in distributed computing came > via > > > Apollo more than anywhere else, as Apollo users and alumni took what > they > > > learned to other systems. > > > > Anyway, we (as a community) are better for having that system but other > > than the registry, I can think of little actual technology that we > continue > > to use from Aegis. > > The OSF/DCE's RPC system came from Apollo, as does the predecessor for > the UUID layout still in use today (RFC 4122). Paul Leach brought > both to the OSF, and as the Kerberos V5 Tech Lead, I worked with Paul, > and used an early Internet-Draft spec of the OSF UUID and implemented > it in e2fsprogs for labelling ext2/3/4 superblocks, and from there the > infection vector spread to the GNOME project. When Paul brought both > of those technologies to Microsoft when he went there after OSF went > belly up. > > - Ted > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Wed Jan 22 10:25:05 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Tue, 21 Jan 2020 16:25:05 -0800 Subject: [TUHS] Apollo Domain/OS In-Reply-To: References: Message-ID: <202001220025.00M0P5bG3369286@darkstar.fourwinds.com> Chris Hanson writes: > My understanding is that there’s a direct line from MULTICS to Prime to Apollo, > in that Apollo was founded by former Prime folks who took their philosophy with them. > > Apollo’s operating system (Aegis, Domain, Domain/OS) had a lot of good and > interesting ideas and was quite influential despite the relatively small > number of people who used it. A lot of what we take for granted today in > distributed computing came via Apollo more than anywhere else, as Apollo > users and alumni took what they learned to other systems. > > — Chris I stil have some Domain/OS books here if anyone wants 'em. From rich.salz at gmail.com Wed Jan 22 11:18:59 2020 From: rich.salz at gmail.com (Richard Salz) Date: Tue, 21 Jan 2020 20:18:59 -0500 Subject: [TUHS] Apollo Domain/OS In-Reply-To: <20200121230025.GL15860@mit.edu> References: <20200121230025.GL15860@mit.edu> Message-ID: Paul was still at Apollo at the time that OSF/DCE picked Apollo's NCA/NCS as the RPC system. I don't know when he left Apollo (or HP/Chelmsford after they bought it) for Microsoft, but it was before OSF died. That latter happened because Sun (Rob Gingell?) insisted OSF stop doing all development as the price of ending the Unix wars and joining everyone in opposing Redmond. We could no longer say OSF stood for Oppose Sun Forever. I liked that NCA could handle env vars in pathnames, which Locus also had IIRC. Domain also had "fat executables" similar to what Apple did when migrating across CPUs. And their build and source system was recreated as ClearCase. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmhanson at eschatologist.net Wed Jan 22 12:47:40 2020 From: cmhanson at eschatologist.net (Chris Hanson) Date: Tue, 21 Jan 2020 18:47:40 -0800 Subject: [TUHS] Apollo Domain/OS In-Reply-To: References: <46acce0f-9ce2-958b-9c12-c6d9c7f737d9@nomadlogic.org> Message-ID: <20686601-773C-408B-98FD-E2DC2680D5E1@eschatologist.net> On Jan 21, 2020, at 3:53 PM, Ronald Natalie wrote: > > Apollo gave us the long term use of a DN1000. I ported our image processing system to it. The amusing thing was when you fired up an X window manager on the thing, it wrapped all three segments of the little status bar at the bottom with window borders. The DN10000 docs came with a beautiful 5 volume set that described all the internals. It was quite detailed for what was there. What I really needed was the documentation on the graphics system which was in Volume 3. My set was missing this. After much digging around Apollo, it turns out that they never wrote volume 3, just assigned the volume number to some yet to be written document. Also the DN10000 is extremely heavy. Mine’s in a basement and claims are it’s never coming out… If anyone has DN10000 documentation like Roland describes above, I would love to get my hands on it and ensure it’s preserved. My DN10000 is a long term restoration project, and we could use some docs. -- Chris From lars at nocrew.org Wed Jan 22 17:11:38 2020 From: lars at nocrew.org (Lars Brinkhoff) Date: Wed, 22 Jan 2020 07:11:38 +0000 Subject: [TUHS] Apollo Domain/OS In-Reply-To: (Chris Hanson's message of "Tue, 21 Jan 2020 13:52:59 -0800") References: Message-ID: <7wpnfc55jp.fsf@junk.nocrew.org> Chris Hanson wrote: > My understanding is that there’s a direct line from MULTICS to Prime > to Apollo, in that Apollo was founded by former Prime folks who took > their philosophy with them. Other Multics inspired systems: M.A.G.I.C. / MagicSix (Interdata minis at MIT Architecture Machine) Amber (S-1 super computer) Any recollections? *COFF* *COFF* From arnold at skeeve.com Wed Jan 22 17:21:47 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 22 Jan 2020 00:21:47 -0700 Subject: [TUHS] Tech Sq elevator (Was: screen editors) [ really I think efficiency now ] In-Reply-To: <20200121215746.GB25322@clarinet.employees.org> References: <202001122034.00CKYQ39571239@darkstar.fourwinds.com> <202001122044.00CKiUNV573279@darkstar.fourwinds.com> <202001122137.00CLbMrw582813@darkstar.fourwinds.com> <20200121215746.GB25322@clarinet.employees.org> Message-ID: <202001220721.00M7Ll5D021031@freefriends.org> > On Sat, Jan 18, 2020 at 09:45:22AM -0600, Michael Parson wrote: > > > > And here, understanding the model is important, namely, grep is the > > wrong tool for searching/parsing JSON output. Dealing with JSON from the > > shell, you should use jq. I've been dragged kicking and screaming into > > dealing with JSON, and about all I can say about it is, I like it about > > this >< much more than XML. :) Derek Fawcus wrote: > If push comes to shove, one can always use xmlawk (xml extension for gawk) > to beat the latter in to submission. There is also a simple JSON extension for gawk in the gawkextlib project that can suck in a single JSON record and turn it into a gawk multidimensional array, and vice versa. (Gawk has true multidimensional arrays and isarray/typeof functions so that you can easily traverse such an array.) (Toot!) Arnold From coppero1237 at gmail.com Wed Jan 22 17:29:43 2020 From: coppero1237 at gmail.com (Tyler Adams) Date: Wed, 22 Jan 2020 09:29:43 +0200 Subject: [TUHS] Tech Sq elevator (Was: screen editors) [ really I think efficiency now ] In-Reply-To: <202001220721.00M7Ll5D021031@freefriends.org> References: <202001122034.00CKYQ39571239@darkstar.fourwinds.com> <202001122044.00CKiUNV573279@darkstar.fourwinds.com> <202001122137.00CLbMrw582813@darkstar.fourwinds.com> <20200121215746.GB25322@clarinet.employees.org> <202001220721.00M7Ll5D021031@freefriends.org> Message-ID: Also for anything where jq gets too complicated, you can use python to whip up an arbitrary json filter Theres only 5 lines of boiler plate import json import sys d = json.load(sys.stdin) # your code here print(json.dumps(d)) Tyler On Wed, Jan 22, 2020, 09:22 wrote: > > On Sat, Jan 18, 2020 at 09:45:22AM -0600, Michael Parson wrote: > > > > > > And here, understanding the model is important, namely, grep is the > > > wrong tool for searching/parsing JSON output. Dealing with JSON from > the > > > shell, you should use jq. I've been dragged kicking and screaming into > > > dealing with JSON, and about all I can say about it is, I like it about > > > this >< much more than XML. :) > > Derek Fawcus wrote: > > If push comes to shove, one can always use xmlawk (xml extension for > gawk) > > to beat the latter in to submission. > > There is also a simple JSON extension for gawk in the gawkextlib project > that can suck in a single JSON record and turn it into a gawk > multidimensional array, and vice versa. (Gawk has true multidimensional > arrays and isarray/typeof functions so that you can easily traverse > such an array.) > > (Toot!) > > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arrigo at alchemistowl.org Wed Jan 22 18:18:29 2020 From: arrigo at alchemistowl.org (Arrigo Triulzi) Date: Wed, 22 Jan 2020 09:18:29 +0100 Subject: [TUHS] Unix on Zilog Z8000? In-Reply-To: References: Message-ID: <2208089D-FF73-4F34-8F52-8EDD0E3A5AE0@alchemistowl.org> On 21 Jan 2020, at 19:30, Clem Cole wrote: > FWIW: I think a search will pick up a number of other Z8000 based systems, but Onyx was the first UNIX box. The very first “Unix at home” system for me was an Onyx 8002 “pedestal” which was connected to three serial terminals: dad, uncle, me :) It was definitely 1980 as it was delivered at home the day of my (unforgettable) 7th birthday. Previously I had only “played” with dad’s TTY into the University systems. Ended up being taught C instead of riding a bicycle… We still have the manuals somewhere but the machine was gone when the Avioon came in. No idea where it ended, sadly. Arrigo -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Wed Jan 22 19:31:15 2020 From: robpike at gmail.com (Rob Pike) Date: Wed, 22 Jan 2020 20:31:15 +1100 Subject: [TUHS] Unix quix In-Reply-To: References: Message-ID: The answers are up: https://commandcenter.blogspot.com/2020/01/unix-quiz-answers.html -rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Wed Jan 22 20:56:08 2020 From: pnr at planet.nl (Paul Ruizendaal) Date: Wed, 22 Jan 2020 11:56:08 +0100 Subject: [TUHS] Unix on Zilog Z8000? Message-ID: <3E0694EF-1742-4313-BA34-D4D386FF6942@planet.nl> A somewhat comparable machine to the Onyx was the Zilog S8000. It ran “Zeus”, which was also a Unix version: https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/zilog/s8000/ Instead of the MMU described below it used the Zilog segmented MMU chips, 3 of them. These could be used to give a plain 16 bit address space divided in 3 segments, or could be used with the segmented addresses of the Z8001. The approach used by Onyx seems much cleaner to me, and reminiscent of the MMU on a DG Eclipse. I think the original chips were the Z8000 (unsegmented) and the the Z8001 (segmented). These could not abort/restart instructions and were replaced by the Z8002 (unsegmented) and Z8003 (segmented). On these chips one could effectively assert reset during a fault and this would leave the registers in a state where a software routine could roll back the faulted instruction. If the sources to the Onyx Unix survived, it would be interesting to see if it used this capability of the Z8002 and implemented a form demand paging. Last but not least, the Xenix overview I linked earlier (http://seefigure1.com/images/xenix/xenix-timeline.jpg) shows Xenix ports to 4 other Z800 machines: Paradyne, Compucorp, Bleasedale and Kontron; maybe all of these never got to production. > Message: 7 > Date: Tue, 21 Jan 2020 21:32:51 +0000 > From: Derek Fawcus > To: The Unix Heritage Society mailing list > Subject: [TUHS] Onyx (was Re: Unix on Zilog Z8000?) > Message-ID: <20200121213251.GA25322 at clarinet.employees.org> > Content-Type: text/plain; charset=us-ascii > > On Tue, Jan 21, 2020 at 01:28:14PM -0500, Clem Cole wrote: >> The Onyx box redated all the 68K and later Intel or other systems. > > That was a fun bit of grubbing around courtesy of a bitsavers mirror > (https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/onyx/). > > It seems they started with a board based upon the non-segmented Z8002 > and only later switched to using the segmented Z8001. In the initial > board, they created their own MMU: > > Page 6 of: https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/onyx/c8002/Onyx_C8002_Brochure.pdf > > Memory Management Controller: > > The Memory Management Controller (MMC) enables the C8002 to perform > address translation, memory block protection, and separation of > instruction and data spaces. Sixteen independent map sets are > implemented, with each map set consisting of an instruction map and > a data map. Within each map there are 32 page registers. Each page > register relocates and validates a 2K byte page. The MMC generates > a 20 bit address allowing the C8002 to access up to one Mbyte of > physical memory. > > So I'd guess the MMC was actually programed through I/O instuctions > to io space, and hence preserved the necessary protection domains. > > Cute. I've had a background interest in the Z8000 (triggered by reading > a Z80000 datasheet around 87/88), and always though about using > the segmented rather than unsegmented device. > > The following has a bit more info about the version of System III > ported to their boxes: > > https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/onyx/c8002/UNIX_3.0.3_Software_Release_Notice_May83.pdf > > DF From pnr at planet.nl Wed Jan 22 23:14:26 2020 From: pnr at planet.nl (Paul Ruizendaal) Date: Wed, 22 Jan 2020 14:14:26 +0100 Subject: [TUHS] Unix on Zilog Z8000? Message-ID: <9F01CB16-2F5D-4853-AA3D-0C4E3411EEB5@planet.nl> My memory failed me: the part numbers were Z8001/Z8002 for the original and Z8003/Z8004 for the revised chips (segmented/unsegmented). Hence it is unlikely that the Onyx had any form of demand paging (other than extending the stack in PDP11-like fashion). —— A somewhat comparable machine to the Onyx was the Zilog S8000. It ran “Zeus”, which was also a Unix version: https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/zilog/s8000/ Instead of the MMU described below it used the Zilog segmented MMU chips, 3 of them. These could be used to give a plain 16 bit address space divided in 3 segments, or could be used with the segmented addresses of the Z8001. The approach used by Onyx seems much cleaner to me, and reminiscent of the MMU on a DG Eclipse. I think the original chips were the Z8000 (unsegmented) and the the Z8001 (segmented). These could not abort/restart instructions and were replaced by the Z8002 (unsegmented) and Z8003 (segmented). On these chips one could effectively assert reset during a fault and this would leave the registers in a state where a software routine could roll back the faulted instruction. If the sources to the Onyx Unix survived, it would be interesting to see if it used this capability of the Z8002 and implemented a form demand paging. Last but not least, the Xenix overview I linked earlier (http://seefigure1.com/images/xenix/xenix-timeline.jpg) shows Xenix ports to 4 other Z800 machines: Paradyne, Compucorp, Bleasedale and Kontron; maybe all of these never got to production. > Message: 7 > Date: Tue, 21 Jan 2020 21:32:51 +0000 > From: Derek Fawcus > To: The Unix Heritage Society mailing list > Subject: [TUHS] Onyx (was Re: Unix on Zilog Z8000?) > Message-ID: <20200121213251.GA25322 at clarinet.employees.org> > Content-Type: text/plain; charset=us-ascii > > On Tue, Jan 21, 2020 at 01:28:14PM -0500, Clem Cole wrote: >> The Onyx box redated all the 68K and later Intel or other systems. > > That was a fun bit of grubbing around courtesy of a bitsavers mirror > (https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/onyx/). > > It seems they started with a board based upon the non-segmented Z8002 > and only later switched to using the segmented Z8001. In the initial > board, they created their own MMU: > > Page 6 of: https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/onyx/c8002/Onyx_C8002_Brochure.pdf > > Memory Management Controller: > > The Memory Management Controller (MMC) enables the C8002 to perform > address translation, memory block protection, and separation of > instruction and data spaces. Sixteen independent map sets are > implemented, with each map set consisting of an instruction map and > a data map. Within each map there are 32 page registers. Each page > register relocates and validates a 2K byte page. The MMC generates > a 20 bit address allowing the C8002 to access up to one Mbyte of > physical memory. > > So I'd guess the MMC was actually programed through I/O instuctions > to io space, and hence preserved the necessary protection domains. > > Cute. I've had a background interest in the Z8000 (triggered by reading > a Z80000 datasheet around 87/88), and always though about using > the segmented rather than unsegmented device. > > The following has a bit more info about the version of System III > ported to their boxes: > > https://www.mirrorservice.org/sites/www.bitsavers.org/pdf/onyx/c8002/UNIX_3.0.3_Software_Release_Notice_May83.pdf > > DF From crossd at gmail.com Thu Jan 23 00:57:50 2020 From: crossd at gmail.com (Dan Cross) Date: Wed, 22 Jan 2020 09:57:50 -0500 Subject: [TUHS] Unix quix In-Reply-To: References: Message-ID: The quiz and answers were also printed in the Australian Unix User's Group Newsletter, volume 5, numbers 5 and 6, respectively. It looks like that might also have been copied from ';login:'? It's unclear to me. I appreciate the additional commentary, though. Obviously some of these are very site-specific (Chesson's phone extension, for example). The "Who wrote the Bourne shell?" question kind of reminds me of the old Bugs Bunny bit where he'd be on some radio gameshow and the host would ask, "Who's buried in Grant's Tomb?" and no one would get it right. (Except totally different because, of course, no one is buried in Grant's Tomb: Grant and his wife are entombed in sarcophagi above ground, not buried below.) Btw, the answer for #16 is `cagbef`: but `g` is not an option. I would think the answer would be `cafbde`. Apparently in the original, option '(d)' is missing; one imagines that was to trick the unwary who failed to adequately read the question. - Dan C. On Wed, Jan 22, 2020 at 4:32 AM Rob Pike wrote: > The answers are up: > > https://commandcenter.blogspot.com/2020/01/unix-quiz-answers.html > > -rob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Jan 23 01:14:25 2020 From: clemc at ccc.com (Clem Cole) Date: Wed, 22 Jan 2020 10:14:25 -0500 Subject: [TUHS] Unix on Zilog Z8000? In-Reply-To: <9F01CB16-2F5D-4853-AA3D-0C4E3411EEB5@planet.nl> References: <9F01CB16-2F5D-4853-AA3D-0C4E3411EEB5@planet.nl> Message-ID: On Wed, Jan 22, 2020 at 8:15 AM Paul Ruizendaal wrote: > Hence it is unlikely that the Onyx had any form of demand paging (other > than extending the stack in PDP11-like fashion). > Actually, more importantly, it was a pure V7 port. BSD 3.0 (Vax - first demand paging support for UNIX) was being created and had not yet released. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Thu Jan 23 02:31:22 2020 From: paul.winalski at gmail.com (Paul Winalski) Date: Wed, 22 Jan 2020 11:31:22 -0500 Subject: [TUHS] Apollo Domain/OS In-Reply-To: References: <20200121230025.GL15860@mit.edu> Message-ID: On 1/21/20, Richard Salz wrote: > >And their build and source system was recreated as > ClearCase. That was the Domain Software Engineering Environment (DSEE). One of my fellow engineers in DEC's Software Development Methods & Tools group was Dave Leblang, He had been working on CMS (Code Management System), DEC's source code versioning system for VAX/VMS. At Apollo he developed DSEE, and he was a co-founder of Atria. CMS took many ideas from SCCS on the PWB. Apollo also did some early work in the field of CGI ray-tracing. They released the very impressive 4-minute film "Quest: A Long Ray's Journey into Night" in 1986. The ray-tracing was done by a network of 100 Apollo workstations and was revolutionary for its time. -Paul W. From mah at mhorton.net Thu Jan 23 03:00:52 2020 From: mah at mhorton.net (Mary Ann Horton) Date: Wed, 22 Jan 2020 09:00:52 -0800 Subject: [TUHS] Unix on Zilog Z8000? In-Reply-To: References: Message-ID: Absolutely. When I was an impoverished grad student at Berkeley, Zilog hired me as a consultant to port vi and the other Berkeley tools to their Z8000 UNIX system. It was a treasured paying gig. As I recall, it was a 16 bit system (with some addressing enhancements ala the 11/70). By then, the VAX was popular and everybody wanted 32 bit systems. People were pinning their micro-UNIX hopes on the Motorola 68K. Even before Zilog's ZEUS, Onyx came out with a microwave oven-sized box based on the Z8000. They loaned one to Berkeley, and it was my first home computer when I took it home to port the tools. Everything had to be copied over by serial port.     Mary Ann On 1/21/20 9:52 AM, Jon Forrest wrote: > There's been a lot of discussion about early Unix on Intel, National > Semi, Motorola, and Sparc processors. I don't recall if Unix ran on > the Z8000, and if not, why not. > > As I remember the Z8000 was going to be the great white hope that > would continue Zilog's success with the Z80 into modern times. > But, it obviously didn't happen. > > Why? > > Jon From imp at bsdimp.com Thu Jan 23 03:54:08 2020 From: imp at bsdimp.com (Warner Losh) Date: Wed, 22 Jan 2020 10:54:08 -0700 Subject: [TUHS] Unix quix In-Reply-To: References: Message-ID: On Wed, Jan 22, 2020 at 7:59 AM Dan Cross wrote: > Btw, the answer for #16 is `cagbef`: but `g` is not an option. I would > think the answer would be `cafbde`. Apparently in the original, option > '(d)' is missing; one imagines that was to trick the unwary who failed to > adequately read the question. > I think this is wrong: 16. Q: Sort the following into chronological order: a) PWB 1.2, b) V7, c) Whirlwind, d) System V, e) 4.2BSD, f) MERT. A: cagbef Whirlwind is a ringer. So the MERT ACM paper is 1975. The BSTJ is July/Aug 1978 (received Feb 1978). Somewhere I read (don't have a handy reference for it) that MERT ported V4 as a supervisor process which puts it in 1974 or so. In any event, this predates everything except Whirlwind which I can't find a paper for. PWB 1.2 is based on V6 + stuff. PWB 1.0 was released 1977, but we don't have an extant 1.2 tape to verify dates with, but 1978 wouldn't be unreasonable. We know 7th Edition was released Jan 1979 (PWB 2.0 was released, 1980 sometime) System V was released January 1983 4.2BSD was released September 1983 (4.1c was released in 1982 though :) So that would make the right answer c f a b d e Even DMERT for the 3B20 was released in January 1983 (or the IEEE paper for it was released then), so it can't be last. I also have questions about this: 81. Q: What was the first Unix network? A: spider You thought it was Datakit, didn't you? But Sandy Fraser had an earlier project. When did Alexander G Fraser's spider cell network happen? For that matter, when did Datakit happen? I can't find references to either start date on line (nor anything on spider except for references to it in Dr Fraser's bio). I can find references to Datakit in 1978 or so. I thought the answer was "ARPANET" since we had a NCP on 4th edition Unix in late 1974 or early 1975 from the University of Illinois dating from that time (the code in TUHS appears to be based on V6 + a number of patches). Warner > - Dan C. > > > On Wed, Jan 22, 2020 at 4:32 AM Rob Pike wrote: > >> The answers are up: >> >> https://commandcenter.blogspot.com/2020/01/unix-quiz-answers.html >> >> -rob >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From katolaz at freaknet.org Thu Jan 23 04:01:36 2020 From: katolaz at freaknet.org (Vincenzo Nicosia) Date: Wed, 22 Jan 2020 19:01:36 +0100 Subject: [TUHS] Unix quix In-Reply-To: References: Message-ID: <20200122180136.dcahjd2mjqqcnvn3@unixfarts.net> On Wed, Jan 22, 2020 at 10:54:08AM -0700, Warner Losh wrote: > On Wed, Jan 22, 2020 at 7:59 AM Dan Cross wrote: > > > Btw, the answer for #16 is `cagbef`: but `g` is not an option. I would > > think the answer would be `cafbde`. Apparently in the original, option > > '(d)' is missing; one imagines that was to trick the unwary who failed to > > adequately read the question. > > > > I think this is wrong: > 16. Q: Sort the following into chronological order: a) PWB 1.2, b) V7, c) > Whirlwind, d) System V, e) 4.2BSD, f) MERT. > A: cagbef > Whirlwind is a ringer. > If not anything else, at least because there is no option g... :) But I might have missed a joke here? HND From pete at nomadlogic.org Thu Jan 23 04:06:02 2020 From: pete at nomadlogic.org (Pete Wright) Date: Wed, 22 Jan 2020 10:06:02 -0800 Subject: [TUHS] Apollo Domain/OS In-Reply-To: References: <20200121230025.GL15860@mit.edu> Message-ID: <25618b7a-d831-fd56-80fb-41da1f65887f@nomadlogic.org> On 2020-01-22 08:31, Paul Winalski wrote: > > Apollo also did some early work in the field of CGI ray-tracing. They > released the very impressive 4-minute film "Quest: A Long Ray's > Journey into Night" in 1986. The ray-tracing was done by a network of > 100 Apollo workstations and was revolutionary for its time. Thanks Paul, I vaguely remember being told about this effort by my mentor which is what sparked my interest.  At the time we were trying to optimally use all available CPU resources for rendering and while we did have working solutions it required lots of perl and shell.  so the idea of CPU resources being available and shared as a foundational concept on the network was really interesting to me. I also seem to remember him telling me about working on the patriot missile system, although i am not certain if i am remembering correctly that this was something he did at apollo or at another company in the boston area. -pete -- Pete Wright pete at nomadlogic.org @nomadlogicLA From clemc at ccc.com Thu Jan 23 04:21:13 2020 From: clemc at ccc.com (Clem Cole) Date: Wed, 22 Jan 2020 13:21:13 -0500 Subject: [TUHS] Unix quix In-Reply-To: References: Message-ID: On Wed, Jan 22, 2020 at 12:55 PM Warner Losh wrote: > I thought the answer was "ARPANET" since we had a NCP on 4th edition Unix > in late 1974 or early 1975 from the University of Illinois dating from that > time (the code in TUHS appears to be based on V6 + a number of patches). > Because we can't ask Greg sadly, I think the Holmgren is the last around that would know definitively and I've personally lost track of him. That said, I don't think UofI had anything earlier than 5th edition (I fairly sure that there were very few copies of 4th edition distributed outside of the Bell: i.e. Columbia, NYU and I thought Harvard; but I don't think too many more than that). Lou Katz would be a better source than I, but I was always under the impression that the number 5th editions, the count was also a smaller 2 digit integer. 6th was where Unix began to 'spread' and by 7th, 'go viral.' And to be honest, I personally thought that Steve and Greg did the ArpaNet NCP work on V6, but it might have been v5th I suppose. I did not know about it until the 6th edition work. But, they were fairly early. BTW: I thought the Rand PIPE code was also developed on 6th, but those also might have been 5th. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Thu Jan 23 04:42:44 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 22 Jan 2020 13:42:44 -0500 (EST) Subject: [TUHS] Unix quix Message-ID: <20200122184244.14CBB18C083@mercury.lcs.mit.edu> > From: Warner Losh > this predates everything except Whirlwind which I can't find a paper for. Given the 'Whirlwind is a ringer' comment, I asssume this: https://en.wikipedia.org/wiki/Whirlwind_I< is what they mean. Pretty interesting machine, if you study its instruction set, BTW; with no stack, subroutines are 'interesting'. Noel From imp at bsdimp.com Thu Jan 23 05:00:41 2020 From: imp at bsdimp.com (Warner Losh) Date: Wed, 22 Jan 2020 12:00:41 -0700 Subject: [TUHS] Unix quix In-Reply-To: References: Message-ID: On Wed, Jan 22, 2020 at 10:54 AM Warner Losh wrote: > > > On Wed, Jan 22, 2020 at 7:59 AM Dan Cross wrote: > >> Btw, the answer for #16 is `cagbef`: but `g` is not an option. I would >> think the answer would be `cafbde`. Apparently in the original, option >> '(d)' is missing; one imagines that was to trick the unwary who failed to >> adequately read the question. >> > > I think this is wrong: > 16. Q: Sort the following into chronological order: a) PWB 1.2, b) V7, c) > Whirlwind, d) System V, e) 4.2BSD, f) MERT. > A: cagbef > Whirlwind is a ringer. > > So the MERT ACM paper is 1975. The BSTJ is July/Aug 1978 (received Feb > 1978). Somewhere I read (don't have a handy reference for it) that MERT > ported V4 as a supervisor process which puts it in 1974 or so. In any > event, this predates everything except Whirlwind which I can't find a paper > for. > PWB 1.2 is based on V6 + stuff. PWB 1.0 was released 1977, but we don't > have an extant 1.2 tape to verify dates with, but 1978 wouldn't be > unreasonable. > We know 7th Edition was released Jan 1979 (PWB 2.0 was released, 1980 > sometime) > System V was released January 1983 > 4.2BSD was released September 1983 (4.1c was released in 1982 though :) > > So that would make the right answer c f a b d e > > Even DMERT for the 3B20 was released in January 1983 (or the IEEE paper > for it was released then), so it can't be last. > > I also have questions about this: > > 81. Q: What was the first Unix network? > A: spider > You thought it was Datakit, didn't you? But Sandy Fraser had an earlier > project. > > When did Alexander G Fraser's spider cell network happen? For that matter, > when did Datakit happen? I can't find references to either start date on > line (nor anything on spider except for references to it in Dr Fraser's > bio). I can find references to Datakit in 1978 or so. > Oopa, spoke one google search too soon. I found this: "Sandy (A. G.) Fraser devised the Spider local-area ring (v6) and the Datakit switch (v7) that have served in the lab for overadecade. Special services on Spider included a central network file store, nfs, and a communication package, ufs. Datakit, a ‘‘central office’’ for data communication, gav e added impetus to research in distributed computing. Fraser undertook the Unix Circuit Design System (see CDL in section 4.3) to support his hardware projects" in "A Research UNIX Reader: Annotated Excerpts from the Programmer’s Manual, 1971-1986" by Doug Mcillroy. > I thought the answer was "ARPANET" since we had a NCP on 4th edition Unix > in late 1974 or early 1975 from the University of Illinois dating from that > time (the code in TUHS appears to be based on V6 + a number of patches). > > Warner > > >> - Dan C. >> >> >> On Wed, Jan 22, 2020 at 4:32 AM Rob Pike wrote: >> >>> The answers are up: >>> >>> https://commandcenter.blogspot.com/2020/01/unix-quiz-answers.html >>> >>> -rob >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Thu Jan 23 05:42:21 2020 From: imp at bsdimp.com (Warner Losh) Date: Wed, 22 Jan 2020 12:42:21 -0700 Subject: [TUHS] Unix quix In-Reply-To: References: Message-ID: On Wed, Jan 22, 2020 at 11:21 AM Clem Cole wrote: > > > On Wed, Jan 22, 2020 at 12:55 PM Warner Losh wrote: > >> I thought the answer was "ARPANET" since we had a NCP on 4th edition >> Unix in late 1974 or early 1975 from the University of Illinois dating from >> that time (the code in TUHS appears to be based on V6 + a number of >> patches). >> > Because we can't ask Greg sadly, I think the Holmgren is the last around > that would know definitively and I've personally lost track of him. > The publication date for the ACM paper is November 1975. I think I misspoke and you are right. The 4th edition was Nov 73, and 5th Edition was June 74 (6th was June 75). In order to meet deadlines for ACM publication, it most likely was 5th Edition, but there's also earlier references to it. That said, I don't think UofI had anything earlier than 5th edition (I > fairly sure that there were very few copies of 4th edition distributed > outside of the Bell: i.e. Columbia, NYU and I thought Harvard; but I don't > think too many more than that). Lou Katz would be a better source than I, > but I was always under the impression that the number 5th editions, the > count was also a smaller 2 digit integer. 6th was where Unix began to > 'spread' and by 7th, 'go viral.' > Berkeley's license was executed in January 74, so it might be on the list, unless there was a big delay. And to be honest, I personally thought that Steve and Greg did the ArpaNet > NCP work on V6, but it might have been v5th I suppose. I did not know > about it until the 6th edition work. But, they were fairly early. BTW: I > thought the Rand PIPE code was also developed on 6th, but those also might > have been 5th. > The code we have is from the 6th edition (judging by diffs, though there's some weird quirks between it and Dennis_v6, as well as a number of local patches). In addition to the Nov 1975 CACM paper, there's CAC 155, published by the University of Illinois on 3/15/75 which pre-dates the 6th edition by a few months. You can read it here https://www.ideals.illinois.edu/bitstream/handle/2142/32547/networkunixsyste155holm.pdf?sequence=2&isAllowed=y if you'd like. There's also CAC 177, which covers the period of Jan 1, 1974 to Dec 31, 1974 which references that Unix had been enhanced to add this after the contract periopd. This this report may have been issued after CAC 155 and may not be proof of an earlier date (though the issue date in its metadata in https://www.ideals.illinois.edu/handle/2142/34150 is 31 DEC 1974, it also reports activity through the end of the year so likely was written later). There's also CAC 162 dated May 15, 1975 ( https://www.ideals.illinois.edu/handle/2142/32293) that references UNIX talking to the mulix machine via the ARPANET protocols. RFC 681, dated March 18th, 1975, is another instance of an edited CAC 155 report (it seems, I've not looked at them exactly, just a quick glance) that talks about this work. It's the earliest mention of Unix in an RFC (the next one isn't until 2 years later for an email address for Dave Crocker DCrocker at Rand-Unix in RFC 724 in May 1977 after which it explodes in references). Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Thu Jan 23 05:54:20 2020 From: pnr at planet.nl (Paul Ruizendaal) Date: Wed, 22 Jan 2020 20:54:20 +0100 Subject: [TUHS] Spider [was: Unix quix] Message-ID: <54907FF0-3700-43FC-AA46-95F43F54AEB2@planet.nl> I can answer some of the below, as I was looking into that a few years ago. > 81. Q: What was the first Unix network? > A: spider > You thought it was Datakit, didn't you? But Sandy Fraser had an earlier > project. > > When did Alexander G Fraser's spider cell network happen? For that matter, > when did Datakit happen? I can't find references to either start date on > line (nor anything on spider except for references to it in Dr Fraser's > bio). I can find references to Datakit in 1978 or so. Spider was designed between 1969 and 1974 - the final lab report (#23) dates from December 1974. It was based around a serial loop running at T1 signalling speed (~1.5Mhz). Here is a video recorded by Dr. Fraser about it: https://www.youtube.com/watch?v=ojRtJ1U6Qzw (first half is about Spider, second half about Datakit). It connected to its hosts via a (discrete TTL-based) microcontroller or “TIU” and seems to have been connected almost immediately to Unix systems: the oldest driver I have been able to locate is in the V4 tree (https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/dmr/tdir/tiu.c). It used a DMA-based parallel interface into the PDP11. As such, it seems to have been much faster than the typical Datakit connection later - but I know too little about Datakit to be sure. There is an interesting visit report from 1975 that discusses some of the stuff that was done with Spider here: https://stacks.stanford.edu/file/druid:rq704hx4375/rq704hx4375.pdf Beyond those experiments I think Spider usage was limited to file serving (’nfs’ and ‘ufs’) and printing (’npr’). It would seem logical that it was used for remote login, but I have not found any traces of such usage. Same for email usage. From what little I know, I think that Datakit became operational in a test network in 1979 and as a product in 1982. > I thought the answer was "ARPANET" since we had a NCP on 4th edition Unix > in late 1974 or early 1975 from the University of Illinois dating from that > time (the code in TUHS appears to be based on V6 + a number of patches). “Network Unix” (https://www.rfc-editor.org/rfc/rfc681.html) was written by Steve Holmgren, Gary Grossman and Steve Bunch in the last 3 months of 1974. To my best knowledge they used V5 and migrated to V6 as it came along. I think they were getting regular update tapes, and they implemented their system as a device driver (plus userland support) to be able to keep up with the steady flow of updates. Greg Chesson was also involved with this Arpanet Unix. As far as I can tell, Arpanet Unix saw fairly wide deployment within the Arpanet research community, also as a front end processor for other systems. A few years back I asked on this list why “Network Unix” was not more enthusiastically received by the core Unix development team and (conceptually) integrated into the main code base. I understood the replies as that (i) people were very satisfied with Spider; and (ii) being part of Bell they wanted a networking system that was more compatible with the Bell network, i.e. Datakit. == In my opinion both “Spider Unix” and “Arpanet Unix” threw a very long conceptual shadow. From Spider onwards, the Research systems viewed the network as a device (Spider), that could be multiplexed (V8 streams) or even mounted (Plan9). The Arpa lineage saw the network as a long distance bidirectional pipe, with the actual I/O device hidden from view; this view persists all the way to 4.2BSD and beyond. I often wonder if it was (is?) possible to come up with a design with the conceptual clarity of Plan9, but organised around the “network as a pipe” view instead. From andreas.hein at berlan.de Thu Jan 23 05:55:56 2020 From: andreas.hein at berlan.de (Andreas Hein) Date: Wed, 22 Jan 2020 20:55:56 +0100 Subject: [TUHS] Unix on Zilog Z8000? In-Reply-To: References: Message-ID: <5daec877-97d1-b5a2-5db6-f639dd4f467c@berlan.de> As far as i know, there was a U8001 (Z8001 CPU Clone) in the System P8000 which run a System III based Unix System named "Wega" It was designed and produced by Company EAW from East-Berlin GDR (German Democratic Republic) Details with Docs, Schematics and Sourcecode at: http://www.pofo.de/P8000/ KR, Andreas Am 21.01.20 um 18:52 schrieb Jon Forrest: > There's been a lot of discussion about early Unix on Intel, National > Semi, Motorola, and Sparc processors. I don't recall if Unix ran on > the Z8000, and if not, why not. > > As I remember the Z8000 was going to be the great white hope that > would continue Zilog's success with the Z80 into modern times. > But, it obviously didn't happen. > > Why? > > Jon From pnr at planet.nl Thu Jan 23 06:16:26 2020 From: pnr at planet.nl (Paul Ruizendaal) Date: Wed, 22 Jan 2020 21:16:26 +0100 Subject: [TUHS] "Network Unix" (i.e. Arpanet Unix) Message-ID: > Because we can't ask Greg sadly, I think the Holmgren is the last around that would know definitively and I've personally lost track of him. Steve Holmgren and the Arpanet Unix team are still around (at least they were 3 years ago). I just remembered that I put some of my notes & findings in a draft wiki that I wanted to develop for TUHS - but I never finished it: http://chiselapp.com/user/pnr/repository/TUHS_wiki/wiki?name=early_networking The recent find of CSRG report 3 and 4 may be the incentive I needed to complete my notes about 4.1a, 4.1c and 4.2BSD. However, still looking for the actual source tape to 4.1a - the closest I have is its derivative in 2.9BSD (https://minnie.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/net) From clemc at ccc.com Thu Jan 23 06:42:18 2020 From: clemc at ccc.com (Clem Cole) Date: Wed, 22 Jan 2020 15:42:18 -0500 Subject: [TUHS] Unix quix In-Reply-To: References: Message-ID: On Wed, Jan 22, 2020 at 2:42 PM Warner Losh wrote: > > Berkeley's license was executed in January 74, so it might be on the list, > unless there was a big delay. > That makes sense. > In addition to the Nov 1975 CACM paper, there's CAC 155, published by the > University of Illinois on 3/15/75 which pre-dates the 6th edition by a few > months. You can read it here > https://www.ideals.illinois.edu/bitstream/handle/2142/32547/networkunixsyste155holm.pdf?sequence=2&isAllowed=y if > you'd like. > Thanks, that tells us it was 5th (BTW the PDF is missing page 1 in the scan - although I suspect the missing info can be gleaned from RFC 681) BTW: There is another hint in CAC 155/RFC 681. The line on page 2 that reads: "since the user is allowed only sixteen open files." My memory is V6 allowed more than 16, over 20 is my memory; but we would have to look at the structure to see what it is defined as. > > RFC 681, dated March 18th, 1975, is another instance of an edited CAC 155 > report (it seems, I've not looked at them exactly, just a quick glance) > that talks about this work. It's the earliest mention of Unix in an RFC > (the next one isn't until 2 years later for an email address for Dave > Crocker DCrocker at Rand-Unix in RFC 724 in May 1977 after which it explodes > in references). > And that pretty much syncs with my memory of the time. -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Thu Jan 23 06:49:24 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Wed, 22 Jan 2020 15:49:24 -0500 Subject: [TUHS] Unix quix Message-ID: <202001222049.00MKnOOm082086@tahoe.cs.Dartmouth.EDU> The first edition ran on pdp-11, not pdp-7. Tukey buttered parsnips at the labs, but Brits did so several centuries before. Contrary to urban legend, patent was not invoked to justify the Unix pdp-11; word-processing was. The quiz does not make this mistake. The phototypesetter did not smell. The chemicals for (externally) devoloping photo paper did. Shahpazian is Dick Shahpazian; Maranzano is Joe Maranzano. cagbef addresses out of bounds. I appreciate Rob's discretion about the Waterloo theft. Doug From clemc at ccc.com Thu Jan 23 07:01:23 2020 From: clemc at ccc.com (Clem Cole) Date: Wed, 22 Jan 2020 16:01:23 -0500 Subject: [TUHS] "Network Unix" (i.e. Arpanet Unix) In-Reply-To: References: Message-ID: Paul - this is great. Thank you. Clem On Wed, Jan 22, 2020 at 3:16 PM Paul Ruizendaal wrote: > > Because we can't ask Greg sadly, I think the Holmgren is the last around > that would know definitively and I've personally lost track of him. > > Steve Holmgren and the Arpanet Unix team are still around (at least they > were 3 years ago). I just remembered that I put some of my notes & findings > in a draft wiki that I wanted to develop for TUHS - but I never finished it: > > http://chiselapp.com/user/pnr/repository/TUHS_wiki/wiki?name=early_networking > > The recent find of CSRG report 3 and 4 may be the incentive I needed to > complete my notes about 4.1a, 4.1c and 4.2BSD. However, still looking for > the actual source tape to 4.1a - the closest I have is its derivative in > 2.9BSD (https://minnie.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/net) > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nobozo at gmail.com Thu Jan 23 07:04:23 2020 From: nobozo at gmail.com (Jon Forrest) Date: Wed, 22 Jan 2020 13:04:23 -0800 Subject: [TUHS] Life at UC Berkeley (was Unix on Zilog Z8000?) In-Reply-To: References: Message-ID: <1f0a98ad-b7f2-fe79-79f1-441800b21b55@gmail.com> On 1/22/2020 9:00 AM, Mary Ann Horton wrote: > Even before Zilog's ZEUS, Onyx came out with a microwave oven-sized box > based on the Z8000. They loaned one to Berkeley, and it was my first > home computer when I took it home to port the tools. As someone who played a very minor role at UC Berkeley, I thought I'd amplify this a little. It was amazing how the various vendors would happily lend (or give) equipment to UC Berkeley. I don't know how things were at the other top CS schools, but at Berkeley I found that if I needed something, telling my faculty boss/mentor would often make the item appear. For example, I did an early port of Postgres to Windows NT using a DEC PC with 16MB of RAM. With such a small amount of RAM this was excruciatingly slow but I made enough progress to show Mike Stonebraker. He then talked to his friends in industry and all of a sudden a MIPS(!) box with 64MB of RAM showed up. I was then able to get the port to the point where it could run the Wisconsin benchmark. Something similar happened when the group wanted to port an early version of Postgres95 to Solaris (it had been developed on DEC Alphas running OSF/1). Mike said to write up a proposal to Sun that he'd sign and then send in, which I did. Soon after a couple of Sparcstation 10s (or 20, I don't remember) showed up and the port was done. There other systems research groups at UCB in the 90s also were the happy recipients of all kinds of great hardware. The limiting factor for such donations was usually finding space to house them. The end result was that the RAID, Risc, and Postgres groups weren't slowed down by lack of hardware. I have no idea what it's like today. Eric Allman, would you care to comment? Jon Forrest From robpike at gmail.com Thu Jan 23 09:06:46 2020 From: robpike at gmail.com (Rob Pike) Date: Thu, 23 Jan 2020 10:06:46 +1100 Subject: [TUHS] Unix quix In-Reply-To: <202001222049.00MKnOOm082086@tahoe.cs.Dartmouth.EDU> References: <202001222049.00MKnOOm082086@tahoe.cs.Dartmouth.EDU> Message-ID: The answers to the quiz are the answers to the quiz. Whether they are correct may be hard to verify, and cagbef is what my notes have so who knows? I've added a word to eliminate the castigation of CAT's hygiene. -rob On Thu, Jan 23, 2020 at 7:50 AM Doug McIlroy wrote: > The first edition ran on pdp-11, not pdp-7. > > Tukey buttered parsnips at the labs, but Brits did > so several centuries before. > > Contrary to urban legend, patent was not invoked to > justify the Unix pdp-11; word-processing was. The > quiz does not make this mistake. > > The phototypesetter did not smell. The chemicals > for (externally) devoloping photo paper did. > > Shahpazian is Dick Shahpazian; Maranzano is Joe Maranzano. > > cagbef addresses out of bounds. > > I appreciate Rob's discretion about the Waterloo theft. > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Thu Jan 23 09:10:53 2020 From: robpike at gmail.com (Rob Pike) Date: Thu, 23 Jan 2020 10:10:53 +1100 Subject: [TUHS] Unix quix In-Reply-To: References: Message-ID: I think the 'd' slipped in during some editing. I've removed it. cagbef it is. Don't confuse quiz answers with absolute truth. All history is fiction to some extent. -rob On Thu, Jan 23, 2020 at 7:43 AM Clem Cole wrote: > > > On Wed, Jan 22, 2020 at 2:42 PM Warner Losh wrote: > >> >> Berkeley's license was executed in January 74, so it might be on the >> list, unless there was a big delay. >> > That makes sense. > > >> In addition to the Nov 1975 CACM paper, there's CAC 155, published by the >> University of Illinois on 3/15/75 which pre-dates the 6th edition by a few >> months. You can read it here >> https://www.ideals.illinois.edu/bitstream/handle/2142/32547/networkunixsyste155holm.pdf?sequence=2&isAllowed=y if >> you'd like. >> > Thanks, that tells us it was 5th (BTW the PDF is missing page 1 in the > scan - although I suspect the missing info can be gleaned from RFC 681) > > BTW: There is another hint in CAC 155/RFC 681. The line on page 2 that > reads: "since the user is allowed only sixteen open files." My memory > is V6 allowed more than 16, over 20 is my memory; but we would have to look > at the structure to see what it is defined as. > > > >> >> RFC 681, dated March 18th, 1975, is another instance of an edited CAC 155 >> report (it seems, I've not looked at them exactly, just a quick glance) >> that talks about this work. It's the earliest mention of Unix in an RFC >> (the next one isn't until 2 years later for an email address for Dave >> Crocker DCrocker at Rand-Unix in RFC 724 in May 1977 after which it >> explodes in references). >> > And that pretty much syncs with my memory of the time. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Thu Jan 23 09:34:49 2020 From: imp at bsdimp.com (Warner Losh) Date: Wed, 22 Jan 2020 16:34:49 -0700 Subject: [TUHS] Unix quix In-Reply-To: References: Message-ID: On Wed, Jan 22, 2020 at 1:42 PM Clem Cole wrote: > BTW: There is another hint in CAC 155/RFC 681. The line on page 2 that > reads: "since the user is allowed only sixteen open files." My memory > is V6 allowed more than 16, over 20 is my memory; but we would have to look > at the structure to see what it is defined as. > Looking at the source in the archives for V5, we see that param.h has "#define NOFILE 15" and for V6 we see "#define NOFILE 15 /* max open files per process */". V7 has "#define NOFILE 20 /* max open files per process */" though, so maybe you are thinking of V7 bumping the limit to 20? Or maybe it was a local change for MIT, since param.h could be edited... But in any event, I think this means that the CAC 155 reference to 16 files just means V6 or earlier. However, I just noticed there's more direct evidence for it being based on V5. On page 2 of CAC 155 we see "For further information concerning the different I/O calls the reader is directed to The UNIX Programmer's Manual, fifth edition, K. Thompson and D. M. Ritchie, June 1974." BTW, CAC 155 is the PDF we have linked from the early network page. I hadn't noticed before now, but seeing the missing page refreshes my recollection. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Jan 23 09:42:34 2020 From: clemc at ccc.com (Clem Cole) Date: Wed, 22 Jan 2020 18:42:34 -0500 Subject: [TUHS] Unix quix In-Reply-To: References: Message-ID: 👍 On Wed, Jan 22, 2020 at 6:35 PM Warner Losh wrote: > > > On Wed, Jan 22, 2020 at 1:42 PM Clem Cole wrote: > >> BTW: There is another hint in CAC 155/RFC 681. The line on page 2 that >> reads: "since the user is allowed only sixteen open files." My memory >> is V6 allowed more than 16, over 20 is my memory; but we would have to look >> at the structure to see what it is defined as. >> > > Looking at the source in the archives for V5, we see that param.h has "#define > NOFILE 15" and for V6 we see "#define NOFILE 15 /* max open files per > process */". V7 has "#define NOFILE 20 /* max open files per process */" > though, so maybe you are thinking of V7 bumping the limit to 20? Or maybe > it was a local change for MIT, since param.h could be edited... But in any > event, I think this means that the CAC 155 reference to 16 files just means > V6 or earlier. > > However, I just noticed there's more direct evidence for it being based on > V5. On page 2 of CAC 155 we see > > "For further information concerning the different I/O calls the reader is > directed to The UNIX Programmer's Manual, fifth edition, K. Thompson and D. > M. Ritchie, June 1974." > > BTW, CAC 155 is the PDF we have linked from the early network page. I > hadn't noticed before now, but seeing the missing page refreshes my > recollection. > > Warner > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Thu Jan 23 11:00:35 2020 From: imp at bsdimp.com (Warner Losh) Date: Wed, 22 Jan 2020 18:00:35 -0700 Subject: [TUHS] Spider [was: Unix quix] In-Reply-To: <54907FF0-3700-43FC-AA46-95F43F54AEB2@planet.nl> References: <54907FF0-3700-43FC-AA46-95F43F54AEB2@planet.nl> Message-ID: On Wed, Jan 22, 2020 at 12:54 PM Paul Ruizendaal wrote: > I can answer some of the below, as I was looking into that a few years ago. > > > 81. Q: What was the first Unix network? > > A: spider > > You thought it was Datakit, didn't you? But Sandy Fraser had an earlier > > project. > > > > When did Alexander G Fraser's spider cell network happen? For that > matter, > > when did Datakit happen? I can't find references to either start date on > > line (nor anything on spider except for references to it in Dr Fraser's > > bio). I can find references to Datakit in 1978 or so. > > Spider was designed between 1969 and 1974 - the final lab report (#23) > dates from December 1974. It was based around a serial loop running at T1 > signalling speed (~1.5Mhz). Here is a video recorded by Dr. Fraser about > it: https://www.youtube.com/watch?v=ojRtJ1U6Qzw (first half is about > Spider, second half about Datakit). > Cool! I'll have to watch that. It connected to its hosts via a (discrete TTL-based) microcontroller or > “TIU” and seems to have been connected almost immediately to Unix systems: > the oldest driver I have been able to locate is in the V4 tree ( > https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/dmr/tdir/tiu.c). It > used a DMA-based parallel interface into the PDP11. As such, it seems to > have been much faster than the typical Datakit connection later - but I > know too little about Datakit to be sure. > Me too. I know even less about Spider. I've been looking for Bell Labs Computing Science Technical Report #23. It's referenced in the visit report below. So far, the closest I've come is https://www.computerhistory.org/collections/catalog/102773566 which says that CHM has it on paper. :/ From about 1990 or so, these reports are easy to find. > There is an interesting visit report from 1975 that discusses some of the > stuff that was done with Spider here: > https://stacks.stanford.edu/file/druid:rq704hx4375/rq704hx4375.pdf > Beyond those experiments I think Spider usage was limited to file serving > (’nfs’ and ‘ufs’) and printing (’npr’). It would seem logical that it was > used for remote login, but I have not found any traces of such usage. Same > for email usage. > Oh that's very interesting. The earliest Network Unix was all about remote login and file transfer (not file servering). The earliest version were for telnet/ftp clients. Later versions have the servers in them. > From what little I know, I think that Datakit became operational in a test > network in 1979 and as a product in 1982. > OK. That's good to know. Are there good references for this? > > I thought the answer was "ARPANET" since we had a NCP on 4th edition > Unix > > in late 1974 or early 1975 from the University of Illinois dating from > that > > time (the code in TUHS appears to be based on V6 + a number of patches). > > “Network Unix” (https://www.rfc-editor.org/rfc/rfc681.html) was written > by Steve Holmgren, Gary Grossman and Steve Bunch in the last 3 months of > 1974. To my best knowledge they used V5 and migrated to V6 as it came > along. I think they were getting regular update tapes, and they implemented > their system as a device driver (plus userland support) to be able to keep > up with the steady flow of updates. Greg Chesson was also involved with > this Arpanet Unix. > That makes sense. The version in our archive is very close to V6. > As far as I can tell, Arpanet Unix saw fairly wide deployment within the > Arpanet research community, also as a front end processor for other systems. > My research matches that. Starting in about 1976 there was an explosion of host names with -unix in their name. There's a number of ARPANET census reports, or ARPANET resource reports that have lots of Unix systems. RFCs show the explosion from 1977 onward. Google has these reports that can be downloaded as a PDF, but are otherwise kinda hard to find :(. > A few years back I asked on this list why “Network Unix” was not more > enthusiastically received by the core Unix development team and > (conceptually) integrated into the main code base. I understood the replies > as that (i) people were very satisfied with Spider; and (ii) being part of > Bell they wanted a networking system that was more compatible with the Bell > network, i.e. Datakit. > Yea. I never understood how Unix could be so leading edge in computing, yet so backward (at least so poor at picking winners) at networking. But this does make a certain amount of sense. We've also seen NIH in the children of Unix as well (Linux, NetBSD, FreeBSD, OpenBSD and MacOS have all had this issue, sometimes for good, sometimes for ill). > In my opinion both “Spider Unix” and “Arpanet Unix” threw a very long > conceptual shadow. From Spider onwards, the Research systems viewed the > network as a device (Spider), that could be multiplexed (V8 streams) or > even mounted (Plan9). The Arpa lineage saw the network as a long distance > bidirectional pipe, with the actual I/O device hidden from view; this view > persists all the way to 4.2BSD and beyond. > Yes. It's difficult to match a connected socket to a network interface... And sockets definitely take the view that it's not a device you are talking to at all, but a special kind of thing that you can do normal I/O to (and a few other special things too). > I often wonder if it was (is?) possible to come up with a design with the > conceptual clarity of Plan9, but organised around the “network as a pipe” > view instead. > We'll never know. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From fair at netbsd.org Thu Jan 23 12:08:11 2020 From: fair at netbsd.org (Erik Fair) Date: Wed, 22 Jan 2020 18:08:11 -0800 Subject: [TUHS] Unix on Zilog Z8000? In-Reply-To: References: Message-ID: … and after Mary Ann was done with it (sometime 1981?), Professor Fabry gave the UCB Onyx to a bunch of undergraduates which they used as the first computer of the Undergraduate Computing Facility (UCF, predecessor to the UCB XCF which had a pile of Suns to play with) in room B50 (basement) of Evans Hall. I was one of those undergrads. That machine became the “x” host on the UCB BerkNet, and it was where B version netnews software was written by Matt Glickman (he was a high school student at the time and while he had Mary Ann’s patronage, my memory is that none of the more official computer services in CS or the Computer Center would give him an account - but we did). At the time, every other computer had restrictions on who could use ‘em, or that you had to pay hefty fees for use (the computer center PDP-11/70s were in that class) - our policy was: if you have a current UCB student ID, we’ll give you an account. We didn’t care whether you were a CS or Engineering student, or not. I remember fixing bugs in various bits of BSD stuff we added to the userland and kernel - we had full source to play with, which was nice. Adding job control was a top priority, and one of our hacks was to change the tty line discipline to restore previous “cooked” character processing state if the program in foreground which had last changed it exited non-zero - that way, programs that modified tty state didn’t need to be recoded for job control too, which, in a system with PDP-11-like memory restrictions (64k text, 64k data maximum per process), was useful. We trained an awful lot of students in the ways of Unix, and many of them became system administrators of the explosion of Unix systems which came to UCB later: the workstation clusters, other microcomputer based Unixes, etc. Kernel hackers (systems programmers) too. Mary Ann also allowed me to photocopy a samizdat copy of the Lions Book, too. I still have that … somewhere, though I bought a copy of the Peter Salus 1996 republication, too. Erik Fair > On Jan 22, 2020, at 09:00, Mary Ann Horton wrote: > > Absolutely. When I was an impoverished grad student at Berkeley, Zilog hired me as a consultant to port vi and the other Berkeley tools to their Z8000 UNIX system. It was a treasured paying gig. > > As I recall, it was a 16 bit system (with some addressing enhancements ala the 11/70). By then, the VAX was popular and everybody wanted 32 bit systems. People were pinning their micro-UNIX hopes on the Motorola 68K. > > Even before Zilog's ZEUS, Onyx came out with a microwave oven-sized box based on the Z8000. They loaned one to Berkeley, and it was my first home computer when I took it home to port the tools. Everything had to be copied over by serial port. > > Mary Ann > > On 1/21/20 9:52 AM, Jon Forrest wrote: >> There's been a lot of discussion about early Unix on Intel, National >> Semi, Motorola, and Sparc processors. I don't recall if Unix ran on >> the Z8000, and if not, why not. >> >> As I remember the Z8000 was going to be the great white hope that >> would continue Zilog's success with the Z80 into modern times. >> But, it obviously didn't happen. >> >> Why? >> >> Jon From ggm at algebras.org Thu Jan 23 13:42:29 2020 From: ggm at algebras.org (George Michaelson) Date: Thu, 23 Jan 2020 13:42:29 +1000 Subject: [TUHS] Spider [was: Unix quix] In-Reply-To: References: <54907FF0-3700-43FC-AA46-95F43F54AEB2@planet.nl> Message-ID: Be careful talking about "spider" in UNIX contexts, thats a UK (Scottish?) UNIX consultancy, which did JANET X.25 related work. Different Spider. Spider Systems maybe. -G On Thu, Jan 23, 2020 at 11:01 AM Warner Losh wrote: > > > > On Wed, Jan 22, 2020 at 12:54 PM Paul Ruizendaal wrote: >> >> I can answer some of the below, as I was looking into that a few years ago. >> >> > 81. Q: What was the first Unix network? >> > A: spider >> > You thought it was Datakit, didn't you? But Sandy Fraser had an earlier >> > project. >> > >> > When did Alexander G Fraser's spider cell network happen? For that matter, >> > when did Datakit happen? I can't find references to either start date on >> > line (nor anything on spider except for references to it in Dr Fraser's >> > bio). I can find references to Datakit in 1978 or so. >> >> Spider was designed between 1969 and 1974 - the final lab report (#23) dates from December 1974. It was based around a serial loop running at T1 signalling speed (~1.5Mhz). Here is a video recorded by Dr. Fraser about it: https://www.youtube.com/watch?v=ojRtJ1U6Qzw (first half is about Spider, second half about Datakit). > > > Cool! I'll have to watch that. > >> It connected to its hosts via a (discrete TTL-based) microcontroller or “TIU” and seems to have been connected almost immediately to Unix systems: the oldest driver I have been able to locate is in the V4 tree (https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/dmr/tdir/tiu.c). It used a DMA-based parallel interface into the PDP11. As such, it seems to have been much faster than the typical Datakit connection later - but I know too little about Datakit to be sure. > > > Me too. I know even less about Spider. I've been looking for Bell Labs Computing Science Technical Report #23. It's referenced in the visit report below. So far, the closest I've come is https://www.computerhistory.org/collections/catalog/102773566 which says that CHM has it on paper. :/ From about 1990 or so, these reports are easy to find. > >> >> There is an interesting visit report from 1975 that discusses some of the stuff that was done with Spider here: https://stacks.stanford.edu/file/druid:rq704hx4375/rq704hx4375.pdf >> Beyond those experiments I think Spider usage was limited to file serving (’nfs’ and ‘ufs’) and printing (’npr’). It would seem logical that it was used for remote login, but I have not found any traces of such usage. Same for email usage. > > > Oh that's very interesting. The earliest Network Unix was all about remote login and file transfer (not file servering). The earliest version were for telnet/ftp clients. Later versions have the servers in them. > >> >> From what little I know, I think that Datakit became operational in a test network in 1979 and as a product in 1982. > > > OK. That's good to know. Are there good references for this? > >> >> > I thought the answer was "ARPANET" since we had a NCP on 4th edition Unix >> > in late 1974 or early 1975 from the University of Illinois dating from that >> > time (the code in TUHS appears to be based on V6 + a number of patches). >> >> “Network Unix” (https://www.rfc-editor.org/rfc/rfc681.html) was written by Steve Holmgren, Gary Grossman and Steve Bunch in the last 3 months of 1974. To my best knowledge they used V5 and migrated to V6 as it came along. I think they were getting regular update tapes, and they implemented their system as a device driver (plus userland support) to be able to keep up with the steady flow of updates. Greg Chesson was also involved with this Arpanet Unix. > > > That makes sense. The version in our archive is very close to V6. > >> >> As far as I can tell, Arpanet Unix saw fairly wide deployment within the Arpanet research community, also as a front end processor for other systems. > > > My research matches that. Starting in about 1976 there was an explosion of host names with -unix in their name. There's a number of ARPANET census reports, or ARPANET resource reports that have lots of Unix systems. RFCs show the explosion from 1977 onward. Google has these reports that can be downloaded as a PDF, but are otherwise kinda hard to find :(. > >> >> A few years back I asked on this list why “Network Unix” was not more enthusiastically received by the core Unix development team and (conceptually) integrated into the main code base. I understood the replies as that (i) people were very satisfied with Spider; and (ii) being part of Bell they wanted a networking system that was more compatible with the Bell network, i.e. Datakit. > > > Yea. I never understood how Unix could be so leading edge in computing, yet so backward (at least so poor at picking winners) at networking. But this does make a certain amount of sense. We've also seen NIH in the children of Unix as well (Linux, NetBSD, FreeBSD, OpenBSD and MacOS have all had this issue, sometimes for good, sometimes for ill). > >> >> In my opinion both “Spider Unix” and “Arpanet Unix” threw a very long conceptual shadow. From Spider onwards, the Research systems viewed the network as a device (Spider), that could be multiplexed (V8 streams) or even mounted (Plan9). The Arpa lineage saw the network as a long distance bidirectional pipe, with the actual I/O device hidden from view; this view persists all the way to 4.2BSD and beyond. > > > Yes. It's difficult to match a connected socket to a network interface... And sockets definitely take the view that it's not a device you are talking to at all, but a special kind of thing that you can do normal I/O to (and a few other special things too). > >> >> I often wonder if it was (is?) possible to come up with a design with the conceptual clarity of Plan9, but organised around the “network as a pipe” view instead. > > > We'll never know. > > Warner From jon at fourwinds.com Thu Jan 23 14:31:34 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Wed, 22 Jan 2020 20:31:34 -0800 Subject: [TUHS] Spider [was: Unix quix] In-Reply-To: References: <54907FF0-3700-43FC-AA46-95F43F54AEB2@planet.nl> Message-ID: <202001230431.00N4VYfb3655315@darkstar.fourwinds.com> It connected to its hosts via a (discrete TTL-based) microcontroller or “TIU” and seems to have been connected almost immediately to Unix systems: the oldest driver I have been able to locate is in the V4 tree (https://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/dmr/tdir/tiu.c). It used a DMA-based parallel interface into the PDP11. As such, it seems to have been much faster than the typical Datakit connection later - but I know too little about Datakit to be sure. I have vague memories here that maybe Heinz can help with if his are any better. I believe that Sandy played a part in "the loop" or "the ring" or whatever it was called that we had connecting our Honeywell 516 to peripherals. I do remember the 74S00 repeaters because of the amount of time that Dave Weller spent tuning them when the error rate got high. Also, being a loop, Joe Condon used to pull his connectors out of the wall whenever people weren't showing up to a meeting on time. I don't know whether our network was a forerunner to the spider network. Jon From pnr at planet.nl Thu Jan 23 18:38:02 2020 From: pnr at planet.nl (Paul Ruizendaal) Date: Thu, 23 Jan 2020 09:38:02 +0100 Subject: [TUHS] Spider Message-ID: > I have vague memories here that maybe Heinz can help with if his are any better. > I believe that Sandy played a part in "the loop" or "the ring" or whatever it > was called that we had connecting our Honeywell 516 to peripherals. I do > remember the 74S00 repeaters because of the amount of time that Dave Weller > spent tuning them when the error rate got high. Also, being a loop, Joe > Condon used to pull his connectors out of the wall whenever people weren't > showing up to a meeting on time. I don't know whether our network was a > forerunner to the spider network. It most likely was Spider - it became operational in 1972. The vist report that I linked to earlier also says: "The current system contains just one loop with the switching computer (TEMPO I), four PDP-11/45 computers, two Honeywell 516 computers, two DDP 224 computers, and one each of Honeywell 6070, PDP-8 and PDP-11/20. In fact many of these are connected in turn to other items of digital equipment.” It would be interesting to know more about the H516’s and Spider, any other recollections? From lehmann at ans-netz.de Thu Jan 23 22:01:20 2020 From: lehmann at ans-netz.de (Oliver Lehmann) Date: Thu, 23 Jan 2020 13:01:20 +0100 Subject: [TUHS] Unix on Zilog Z8000? In-Reply-To: <5daec877-97d1-b5a2-5db6-f639dd4f467c@berlan.de> References: <5daec877-97d1-b5a2-5db6-f639dd4f467c@berlan.de> Message-ID: <20200123130120.Horde.F4k6eI-syzp4WoxY-XjMW8L@avocado.salatschuessel.net> Hi, let me just reply to this single message :) > Details with Docs, Schematics and Sourcecode at: http://www.pofo.de/P8000/ Wow - my page gets quoted on TUHS-ML :) The 16 Bit board runs WEGA (renamed copy of ZEUS). The board is a copy of the 16 Bit Board from Zilogs System 8000. Some parts where added because the subsystem design is different (serial ports, harddisk, floppy disks instead of tape,...). WEGA only runs on a Z8001 (no Z8002) and the OS was able to execute (and compile) segmented (full memory access) and unsegmented (only 64K access iirc) binaries. The OS of the P8000 is as I said a copy of ZEUS. The name ZEUS was "replaced" with WEGA in the executables (hex editor). Some parts of the system where reverse engineered and altered. I had contact to a kernel developer after the system collapsed who told me some stories ;) While the userland ist nearly a 100% copy of ZEUS, main parts of the kernel (dev) where changed to handle the different system layout. I own a complete and running P8000 as well as a S8000 which could run if I would have a) a copy of the Zilog ZEUS Installation Tape (+ system diagnostic tape) b) a working tape drive (non-standard tape not compatible to something else) c) a SA1100 harddisk, or c) a SMD Controller + SMD disks. d) time After I designed, built and programmed a harddisk subsystem emulator for the P8000, I also planed to emulate the whole disk subsystem of the S8000. Additionally I planned to use a partial backup of a ZEUS installation I have + WEGA to generate a running ZEUS-a-like but then I became a father and time was gone ;) So right now my S8000 sits in my basement togehter with some circuit ideas and logical analysation results and waits for more time ;) Some links... Kernel Sources of WEGA I could get my hands on, or are disassembled and "make-it-C-code-again"ed by me https://github.com/OlliL/P8000/tree/master/WEGA/src/uts Beside that there is also other stuff like C compiler sources and so on - just navigate around :) Zilog S8000 pics http://pics.pofo.de/index.php?/category/129 EAW P8000 pics http://pics.pofo.de/index.php?/category/21 Some S8000 sources (mostly firmware, rebuilt with having access to the P8000 firmware) https://github.com/OlliL/S8000 Any questions are welcome.... Best regards, Oliver From leah at vuxu.org Fri Jan 24 01:56:49 2020 From: leah at vuxu.org (Leah Neukirchen) Date: Thu, 23 Jan 2020 16:56:49 +0100 Subject: [TUHS] Unix quix In-Reply-To: (Rob Pike's message of "Thu, 23 Jan 2020 10:06:46 +1100") References: <202001222049.00MKnOOm082086@tahoe.cs.Dartmouth.EDU> Message-ID: <87h80m6u9q.fsf@vuxu.org> Rob Pike writes: > The answers to the quiz are the answers to the quiz. Whether they are > correct may be hard to verify, and cagbef is what my notes have so who > knows? The question is missing a part: 16. Sort the following into chronological order: a) PWB 1.2, b) V7, c) Whirlwind, e) System V, f) 4.2BSD, g) MERT. cagbef|c a g b e f >From an file George Rosamond sent me in 2009: http://leahneukirchen.org/trivium/unixquiz-solution.txt I also collected some more sources: http://leahneukirchen.org/trivium/2009-01-18 hth, -- Leah Neukirchen https://leahneukirchen.org/ From jon at fourwinds.com Fri Jan 24 03:40:04 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Thu, 23 Jan 2020 09:40:04 -0800 Subject: [TUHS] Spider In-Reply-To: References: Message-ID: <202001231740.00NHe4nY3787935@darkstar.fourwinds.com> Paul Ruizendaal writes: > > > > I have vague memories here that maybe Heinz can help with if his are any better. > > I believe that Sandy played a part in "the loop" or "the ring" or whatever it > > was called that we had connecting our Honeywell 516 to peripherals. I do > > remember the 74S00 repeaters because of the amount of time that Dave Weller > > spent tuning them when the error rate got high. Also, being a loop, Joe > > Condon used to pull his connectors out of the wall whenever people weren't > > showing up to a meeting on time. I don't know whether our network was a > > forerunner to the spider network. > > It most likely was Spider - it became operational in 1972. The vist report that I linked to earlier also says: > > "The current system contains just one loop with the switching computer (TEMPO I), > four PDP-11/45 computers, two Honeywell 516 computers, two DDP 224 computers, > and one each of Honeywell 6070, PDP-8 and PDP-11/20. In fact many of these are > connected in turn to other items of digital equipment.” > > It would be interesting to know more about the H516’s and Spider, any other recollections? Ugh. Memory lane has a lot of potholes. This was a really long time ago. I believe that the 516 network predated your quote above and was most likely designed for the 516 as I'm pretty sure that Sandy was in our department; I have some recollection of his office being in our block of rooms and of spending some time talking to him. I am guessing that one of these was installed in the UNIX lab but I really don't know. My guess is based on a recollection that there was a GLANCE G up there, and the only interface to one of these was the network. I can't imagine them not having a cool toy like the GLANCE G up there. Maybe Doug or Ken remembers. I also recall that the network was technically a Pierce Loop, named after John Pierce of course. My best recollection is that this ran off of the DMA controller on the 516. I think that it regularly sent a big block of data around the loop. That block had "holes" in it in which any "terminal" device could say "hey, gimme some attention" or "here's some data". I'm using terminal here to mean any device other than the 516 that was moving the bits around. I have no memory of how collisions were handled or whether there was any sort of bit-per-terminal device to avoid collisions. The bits were sent around on coax. They didn't go very far, and there were repeater boards everywhere. I don't recall any separate power supplies for the repeater boards so maybe there was some DC on the coax for that. The repeater boards used 74S00s for drivers, and there was some sort of tuned circuit that had an adjustment. Every once in a while Dave Weller would make the circuit with a scope and a little green screwdriver to keep things working. A day sticks out in my memory. We were still in building 2 before buildings 6 and 7 were built and we moved to building 7. The error rate on the network went through the roof and became unusable, and I think when that happened the 516 crashed. Wasn't a repeater, wasn't Joe pulling the plugs out of the wall. Someone in a nearby lab had left a cover off of their cyclotron. Can't express how comforting that was; on par with discovering that the track on which I ran in junior high school was a radioactive toxic waste dump or coming across family photos of me in an open-pit Quebec asbestos mine as a kid. I know that there were other instances of this network around the labs. I did a project that supported integrated circuit test systems in labs driven by a single cost computer. Yes folks, there was a day in which a computer cost more than a wafer stepper :-) This system was based on 516-TSS and the network. It sticks in my mind because I was working on it during the big Western Electric debacle around the memory chip failures in the big new ESS installed in the basement of the Chicago Sears Tower. Anyway, that's all I can remember about this at the moment. Heinz should know something about it but his memory may be as bad as mine. Another person who would know is John Camlet. Don't know if he's still around; a quick search shows someone of about the right age living in Plainfield, NJ so if someone lives out there try knocking on the door. Jon From jon at fourwinds.com Fri Jan 24 04:42:35 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Thu, 23 Jan 2020 10:42:35 -0800 Subject: [TUHS] Another oldie but goodie available if anyone wants it [ DECNET ] Message-ID: <202001231842.00NIgZju3798969@darkstar.fourwinds.com> Was looking for my DomainOS manuals and came across a fat notebook containing the DECNET Phase III spec. Anyone want it? Not anything that I need to keep and low-hanging fruit on the decluttering list. Jon From jon at fourwinds.com Fri Jan 24 05:01:16 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Thu, 23 Jan 2020 11:01:16 -0800 Subject: [TUHS] More oldies but goodies available if anyone wants them Message-ID: <202001231901.00NJ1GV93802409@darkstar.fourwinds.com> Kind of scary what's in my basement. For those of you building UNIX workstations in the early days, I have a big fat notebook full of Weitek floating point chip specs, many of which are marked as preliminary. Also a set of CORBA specs. Again, low-hanging fruit that's getting recycled unless anyone has a use for them. In the not completely sure that I want to part with them yet for some strange reason, I have a set of SunOS manuals. Also, if anyone collects old hardware I have a SparcStation 20 with a slightly modified SunOS sitting around and an Ultra 60 Solaris box. Jon From kevin.bowling at kev009.com Fri Jan 24 09:01:20 2020 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Thu, 23 Jan 2020 16:01:20 -0700 Subject: [TUHS] More oldies but goodies available if anyone wants them In-Reply-To: <202001231901.00NJ1GV93802409@darkstar.fourwinds.com> References: <202001231901.00NJ1GV93802409@darkstar.fourwinds.com> Message-ID: What are the mods? I have a stack of 10s and 20s but will take it for safe keeping if nobody else will. On Thu, Jan 23, 2020 at 12:01 PM Jon Steinhart wrote: > Kind of scary what's in my basement. For those of you building UNIX > workstations in the early days, I have a big fat notebook full of > Weitek floating point chip specs, many of which are marked as preliminary. > Also a set of CORBA specs. Again, low-hanging fruit that's getting > recycled unless anyone has a use for them. > > In the not completely sure that I want to part with them yet for some > strange reason, I have a set of SunOS manuals. > > Also, if anyone collects old hardware I have a SparcStation 20 with a > slightly modified SunOS sitting around and an Ultra 60 Solaris box. > > Jon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gregg.drwho8 at gmail.com Fri Jan 24 09:08:04 2020 From: gregg.drwho8 at gmail.com (Gregg Levine) Date: Thu, 23 Jan 2020 18:08:04 -0500 Subject: [TUHS] More oldies but goodies available if anyone wants them In-Reply-To: <202001231901.00NJ1GV93802409@darkstar.fourwinds.com> References: <202001231901.00NJ1GV93802409@darkstar.fourwinds.com> Message-ID: Hello! At one point I'd be delighted to take one or the other of the Sun boxes, but I've been advised to no longer do that. Kevin do me a favor and take both. However... I'm looking for DEC Terminal Server devices, the Model 90L or Model 90L Plus devices. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Thu, Jan 23, 2020 at 2:02 PM Jon Steinhart wrote: > > Kind of scary what's in my basement. For those of you building UNIX > workstations in the early days, I have a big fat notebook full of > Weitek floating point chip specs, many of which are marked as preliminary. > Also a set of CORBA specs. Again, low-hanging fruit that's getting > recycled unless anyone has a use for them. > > In the not completely sure that I want to part with them yet for some > strange reason, I have a set of SunOS manuals. > > Also, if anyone collects old hardware I have a SparcStation 20 with a > slightly modified SunOS sitting around and an Ultra 60 Solaris box. > > Jon From jon at fourwinds.com Fri Jan 24 09:48:30 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Thu, 23 Jan 2020 15:48:30 -0800 Subject: [TUHS] More oldies but goodies available if anyone wants them In-Reply-To: References: <202001231901.00NJ1GV93802409@darkstar.fourwinds.com> Message-ID: <202001232348.00NNmUmc3853455@darkstar.fourwinds.com> Kevin Bowling writes: > > What are the mods? I have a stack of 10s and 20s but will take it for safe > keeping if nobody else will. > > On Thu, Jan 23, 2020 at 12:01 PM Jon Steinhart wrote: > > > Kind of scary what's in my basement. For those of you building UNIX > > workstations in the early days, I have a big fat notebook full of > > Weitek floating point chip specs, many of which are marked as preliminary. > > Also a set of CORBA specs. Again, low-hanging fruit that's getting > > recycled unless anyone has a use for them. > > > > In the not completely sure that I want to part with them yet for some > > strange reason, I have a set of SunOS manuals. > > > > Also, if anyone collects old hardware I have a SparcStation 20 with a > > slightly modified SunOS sitting around and an Ultra 60 Solaris box. > > > > Jon The Sparc 20 includes the double-buffered graphics board. Thanks to an unnamed employee, I got the code to do a kernel mod so that I can run SunView on the front buffer and X on the rear buffer and switch between the two by running the mouse off of the side of the screen. I probably have installation media around for both of these systems. Which means that I also have a QIC-150 drive to go with 'em. And a stack of QIC-150 and QIC-50 tapes that I've been wanting to get rid of but haven't managed to procure a good bulk eraser yet. Also may have Sun DDS-2, DDS-3, and DDS-4 DAT drives; will have to look. I also have one of the Archive Python DAT drives with the special SGI firmware that lets the DDS layer be turned off so that you can read and write audio DATs; that's currently loaned out and I'd need to check the status of it. Jon From pnr at planet.nl Fri Jan 24 11:28:19 2020 From: pnr at planet.nl (Paul Ruizendaal) Date: Fri, 24 Jan 2020 02:28:19 +0100 Subject: [TUHS] Spider Message-ID: > Ugh. Memory lane has a lot of potholes. This was a really long time ago. Many thanks for that post - really interesting! I had to look up "Pierce Network", and found it described in the Bell Journal: https://ia801903.us.archive.org/31/items/bstj51-6-1133/bstj51-6-1133_text.pdf In my reading the Spider network is a type of Pierce network. However, the network that you remember is indeed most likely different from Spider: - it was coax based, whereas the Spider line was a twisted pair - there was more than one, whereas Spider only ever had one (operational) loop Condon and Weller are acknowledged in the report about Spider as having done many of its hardware details. The report discusses learnings from the project and having to tune repeaters is not among them (but another operational issue with its 'line access modules’ is discussed). All in all, maybe these coax loops were pre-cursors to the Spider network, without a switch on the loop (“C” nodes in the Pierce paper). It makes sense to first try out the electrical and line data protocol before starting work on higher level functions. I have no idea what a GLANCE G is... From pnr at planet.nl Fri Jan 24 11:59:23 2020 From: pnr at planet.nl (Paul Ruizendaal) Date: Fri, 24 Jan 2020 02:59:23 +0100 Subject: [TUHS] Spider (and back to quiz) Message-ID: <13430143-695E-4DBD-A443-9ECCA0FB4283@planet.nl> There is more in that issue of BSTJ, and indeed it seems this was a precursor. https://ia801905.us.archive.org/25/items/bstj51-6-1147/bstj51-6-1147_text.pdf https://ia801603.us.archive.org/0/items/bstj51-6-1167/bstj51-6-1167_text.pdf The first paper makes mention of repeaters starting to self oscillate, and a redesign being underway. There is a possibility that a Unix PDP11 was connected to this earlier network prior to Spider existing, in which case the accepted quiz answer would be wrong. >> Ugh. Memory lane has a lot of potholes. This was a really long time ago. > > Many thanks for that post - really interesting! > > I had to look up "Pierce Network", and found it described in the Bell Journal: > https://ia801903.us.archive.org/31/items/bstj51-6-1133/bstj51-6-1133_text.pdf > > In my reading the Spider network is a type of Pierce network. > > However, the network that you remember is indeed most likely different from Spider: > - it was coax based, whereas the Spider line was a twisted pair > - there was more than one, whereas Spider only ever had one (operational) loop > > Condon and Weller are acknowledged in the report about Spider as having done many of its hardware details. The report discusses learnings from the project and having to tune repeaters is not among them (but another operational issue with its 'line access modules’ is discussed). > > All in all, maybe these coax loops were pre-cursors to the Spider network, without a switch on the loop (“C” nodes in the Pierce paper). It makes sense to first try out the electrical and line data protocol before starting work on higher level functions. > > I have no idea what a GLANCE G is... From jon at fourwinds.com Fri Jan 24 12:37:24 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Thu, 23 Jan 2020 18:37:24 -0800 Subject: [TUHS] Spider In-Reply-To: References: Message-ID: <202001240237.00O2bOEG3883117@darkstar.fourwinds.com> Paul Ruizendaal writes: > > Ugh. Memory lane has a lot of potholes. This was a really long time ago. > > Many thanks for that post - really interesting! > > I had to look up "Pierce Network", and found it described in the Bell Journal: > https://ia801903.us.archive.org/31/items/bstj51-6-1133/bstj51-6-1133_text.pdf > > In my reading the Spider network is a type of Pierce network. > > However, the network that you remember is indeed most likely different from Spider: > - it was coax based, whereas the Spider line was a twisted pair > - there was more than one, whereas Spider only ever had one (operational) loop > > Condon and Weller are acknowledged in the report about Spider as having done > many of its hardware details. The report discusses learnings from the project > and having to tune repeaters is not among them (but another operational issue > with its 'line access modules’ is discussed). > > All in all, maybe these coax loops were pre-cursors to the Spider network, > without a switch on the loop (“C” nodes in the Pierce paper). It makes sense > to first try out the electrical and line data protocol before starting work > on higher level functions. > > I have no idea what a GLANCE G is... Again, very fuzzy memory here but there are a few folks on the list who might remember more like Heinz. As I said earlier, I recall Sandy being in our group so our network may have been the first try. I don't know who designed it. The GLANCE G was an experimental graphics terminal developed in our group. I think that John Camlet did a bunch of the hardware design as I have a strong memory of a long afternoon with him after having weird squiggles show up in short vectors which turned out to be a microcode bug. The thing had 4K resolution in at least one axis, it may have been a square screen. It used 1K DRAMs and was built around a 74S181 bit slice machine. A lot of interesting stuff was done on it; I mentioned Dick Hause's Display Terminal Editor in an earlier post. I also remember a really nice graphical demo of how the phone network routed around outages which of course no longer works due to lack of redundancy. Oh, yeah, the real use for these comes back to me :-) A number of the folks in the group including Carl Christensen (who was one of the two people who interviewed Ken for his job at the labs) had purchased property up in Vermont for ski cabins. These lots had ancient surveys, the old "from the big tree near the large rock" sort of property descriptions. So the main use of the Glance G's for a while was to draw out the surveys and figure out what to do about closure errors. If you don't know about it, and this is the only reason why I do, a closure error is when you follow the property boundary described by the survey and the end isn't at the beginning. Anyway, these were very cool machines for their time. I don't recall any other graphical devices at the time except for glass tty terminals, Tektronix storage tubes, and the GRIN-2 on the PDP-15 that we used for space war as per earlier posts. Dave Hagelbarger designed the keyboard and to this date it's still one of the best keyboards that I ever used as far as feel goes. It had plastic cups under the keys that gave resistance and then accelerated after a certain point so you pushed on a key and then it would shoot the rest of the way. And there was a solenoid on the bottom of the circuit board so there was a little click that you felt in your fingers. Great feedback. There were some extra parts left over from building these. I remember that Joe Condon had the glass shop do some work on an extra or dead CRT, and one of the terminals in his office was actually a fish tank. When you turned it on a light would come on behind the tube and you could see the fish swimming around in it. Maybe Joe deserves credit for the original fish screen saver. Oh yeah, another thing that I remember being tried was that someone had built an array of LEDs and photodiodes surrounding the screen that could be used as an input device. It was low res but you could point at things with your fingers. One of the projects that I did was to write software for nicely plotting graphs on these. Was used a bunch by Jim Kaiser and crowd for their digital filter work. I remember a really nice graph that Jim did that showed just how carefully the touch tone frequencies were chosen to have no harmonics in common. This isn't really UNIX stuff but I suppose that it passes for prehistory. Again, I seem to recall that one of these was up in the UNIX lab but have no memory of what it was used for. If I had to guess, it would be chess. Oh yeah, I think that you can see the GLANCE G instruction set if you have a first edition copy of Newman and Sproul. I remember getting a copy of that book and having a weird sense of deja vu during their discussion of vector graphics. Then I realized that it was because it was the instruction set that was burned into my memory. Jon From imp at bsdimp.com Fri Jan 24 12:44:58 2020 From: imp at bsdimp.com (Warner Losh) Date: Thu, 23 Jan 2020 19:44:58 -0700 Subject: [TUHS] Unix quix In-Reply-To: <87h80m6u9q.fsf@vuxu.org> References: <202001222049.00MKnOOm082086@tahoe.cs.Dartmouth.EDU> <87h80m6u9q.fsf@vuxu.org> Message-ID: On Thu, Jan 23, 2020, 8:57 AM Leah Neukirchen wrote: > Rob Pike writes: > > > The answers to the quiz are the answers to the quiz. Whether they are > > correct may be hard to verify, and cagbef is what my notes have so who > > knows? > > The question is missing a part: > > 16. Sort the following into chronological order: a) PWB 1.2, b) V7, c) > Whirlwind, e) System V, f) 4.2BSD, g) > MERT. > cagbef|c a g b e f > > From an file George Rosamond sent me in 2009: > http://leahneukirchen.org/trivium/unixquiz-solution.txt > I also collected some more sources: > http://leahneukirchen.org/trivium/2009-01-18 MERT absolutely predates PWB 1.2. MERT has papers starting in 1975 while pwb 1.2 is 1978 or 1979. By the time pwb 1.2 was coming out, it had mutated to UNIX/RT... MERT was V4 while releases of PWB were V6 based. And the link for the graph (which are often horribly sourced for the early stuff) is dead. Warner > hth, > -- > Leah Neukirchen https://leahneukirchen.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gregg.drwho8 at gmail.com Fri Jan 24 13:03:02 2020 From: gregg.drwho8 at gmail.com (Gregg Levine) Date: Thu, 23 Jan 2020 22:03:02 -0500 Subject: [TUHS] Spider In-Reply-To: <202001240237.00O2bOEG3883117@darkstar.fourwinds.com> References: <202001240237.00O2bOEG3883117@darkstar.fourwinds.com> Message-ID: Hello! GACK! (Excuse me.) Hello! That description of how someone back there used a batch of LEDs and photodiodes to form an input device triggered a memory of my own. One Steve Ciarcia who wrote the Circuit Cellar column for Byte magazine described that same method. He even included a photo of the prototype using a picture frame to hold them. The code to manage it was written in BASIC of all things for one of his custom cards, and it was mounted on his equally custom system. He also described a similar method of generating graphics using two DAC devices and a scope itself switched into X-Y mode. (Code was also in BASIC for starters.) Let us now return to the wonders of UNIX and as it relates to the early networking ideas. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Thu, Jan 23, 2020 at 9:38 PM Jon Steinhart wrote: > > Paul Ruizendaal writes: > > > Ugh. Memory lane has a lot of potholes. This was a really long time ago. > > > > Many thanks for that post - really interesting! > > > > I had to look up "Pierce Network", and found it described in the Bell Journal: > > https://ia801903.us.archive.org/31/items/bstj51-6-1133/bstj51-6-1133_text.pdf > > > > In my reading the Spider network is a type of Pierce network. > > > > However, the network that you remember is indeed most likely different from Spider: > > - it was coax based, whereas the Spider line was a twisted pair > > - there was more than one, whereas Spider only ever had one (operational) loop > > > > Condon and Weller are acknowledged in the report about Spider as having done > > many of its hardware details. The report discusses learnings from the project > > and having to tune repeaters is not among them (but another operational issue > > with its 'line access modules’ is discussed). > > > > All in all, maybe these coax loops were pre-cursors to the Spider network, > > without a switch on the loop (“C” nodes in the Pierce paper). It makes sense > > to first try out the electrical and line data protocol before starting work > > on higher level functions. > > > > I have no idea what a GLANCE G is... > > Again, very fuzzy memory here but there are a few folks on the list who might > remember more like Heinz. As I said earlier, I recall Sandy being in our group > so our network may have been the first try. I don't know who designed it. > > The GLANCE G was an experimental graphics terminal developed in our group. I > think that John Camlet did a bunch of the hardware design as I have a strong > memory of a long afternoon with him after having weird squiggles show up in > short vectors which turned out to be a microcode bug. The thing had 4K > resolution in at least one axis, it may have been a square screen. It used > 1K DRAMs and was built around a 74S181 bit slice machine. A lot of interesting > stuff was done on it; I mentioned Dick Hause's Display Terminal Editor in an > earlier post. I also remember a really nice graphical demo of how the phone > network routed around outages which of course no longer works due to lack of > redundancy. > > Oh, yeah, the real use for these comes back to me :-) A number of the folks > in the group including Carl Christensen (who was one of the two people who > interviewed Ken for his job at the labs) had purchased property up in > Vermont for ski cabins. These lots had ancient surveys, the old "from the big > tree near the large rock" sort of property descriptions. So the main use of > the Glance G's for a while was to draw out the surveys and figure out what to > do about closure errors. If you don't know about it, and this is the only > reason why I do, a closure error is when you follow the property boundary > described by the survey and the end isn't at the beginning. > > Anyway, these were very cool machines for their time. I don't recall any other > graphical devices at the time except for glass tty terminals, Tektronix storage > tubes, and the GRIN-2 on the PDP-15 that we used for space war as per earlier > posts. > > Dave Hagelbarger designed the keyboard and to this date it's still one of the > best keyboards that I ever used as far as feel goes. It had plastic cups under > the keys that gave resistance and then accelerated after a certain point so you > pushed on a key and then it would shoot the rest of the way. And there was a > solenoid on the bottom of the circuit board so there was a little click that > you felt in your fingers. Great feedback. > > There were some extra parts left ove