From douglas.mcilroy at dartmouth.edu Sat Jan 1 01:47:42 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Fri, 31 Dec 2021 10:47:42 -0500 Subject: [TUHS] roff(7) Message-ID: > Did roff do all of what troff and nroff did? No way. Ossanna deserves all the praise you give him. Roff extended runoff in various ways: relative numeric operators, e.g. .in +8 tabbing (left, right and centered) underlining tripartite headers and footers arabic and roman page numbering adjustable head and foot margins automatic hyphenation, thanks to Molly Wagner footnotes merge patterns for change marks, column separators, etc. various special requests: .ne, .ti, .tr, .po, .op (odd page) But roff did NOT have conditionals, traps, special characters, environments, or arbitrary motion control. Crucially (and ironically, because I was Mr. Macro), it did not have anything like macros, strings and diversions until after Joe pioneered them in nroff. So there was a gaping disparity: nroff was Turing complete, roff wasn't. Roff merely added features to runoff; nroff leapt into a different universe. ----------------------- The features listed above are in the January 1971 manual for BCPL roff, which is probably the anonymous reference cited in the November 1971 v1 manual. The v1 manual lists Osanna, Ken and Dennis as authors of the Unix implementation. I believe Ossanna is named because he added line-numbering--and maybe more--to entice the patent department to switch to roff. BCPL roff allowed all four arithmetic operators in contexts like .ls *3. Only + and - were allowed in nroff. Eventually both BCPL roff and nroff got number registers (defined by different commands); I don't recall which came first. BCPL roff also got a weak macro facility, definitely after nroff. Doug From athornton at gmail.com Sat Jan 1 01:53:38 2022 From: athornton at gmail.com (Adam Thornton) Date: Fri, 31 Dec 2021 08:53:38 -0700 Subject: [TUHS] moving directories in svr2 In-Reply-To: <97f563fa-5a17-424b-acc6-07cf127f496d@localhost> References: <20211230034512.B9B3718C08E@mercury.lcs.mit.edu> <97f563fa-5a17-424b-acc6-07cf127f496d@localhost> Message-ID: Slightly older, but also slightly more fundamental to the system, you need look no farther than Solaris's `/bin/sh` for an illustrated example of the pros and cons of maintaining backwards compatibility. It was a pain by, say, 2007, to have to check if you were running on SunOS and use `/usr/xpg4/bin/sh` (IIRC) if you wanted a POSIX shell--by that point the other major vendors (and Linux) had something POSIX as the default shell. But Sun had an installed user base with a bunch of shell scripts that depended on pre-POSIX semantics. Of course, people don't do a particularly good job of writing POSIX shell either. Just this past week one of our refactoring projects at the Rubin Observatory had some difficulty because Debian uses dash as its non-interactive POSIX shell. Some bit of some conda package that we need claimed to work with dash (and POSIX generally) but in reality didn't. But it always worked fine on bash and zsh, so no one had gotten bitten until we did. Adam On Fri, Dec 31, 2021 at 6:40 AM Michael Kjörling wrote: > On 31 Dec 2021 16:55 +1100, from robpike at gmail.com (Rob Pike): > > And of course you're right, but we've known how to roll out breaking > > changes in software for a very long time now. And we do so often. Few > Unix > > programs from the past would compile and run today without being updated > to > > "modern" interfaces and compilers. > > > > I believe it could be done, and I believe it should be done. Rolled out > > carefully and explained well it would please far more than it offends, > and > > is arguably far closer to correct than the current situation. > > Seems to me that we have a decent, relatively current case study of > this with Python 2 vs Python 3. > > Which is probably a good bit easier actually, because maintaining the > ability to run Python 2 applications while introducing the ability to > run Python 3 applications is likely easier than introducing changes to > how something as relatively fundamental as how ".." behaves in paths > while at the same time maintaining backwards compatibility with the > old behavior, where different users and different applications on the > same system might very well expect different behavior... > > -- > Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se > “Remember when, on the Internet, nobody cared that you were a dog?” > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Sat Jan 1 02:15:06 2022 From: will.senn at gmail.com (Will Senn) Date: Fri, 31 Dec 2021 10:15:06 -0600 Subject: [TUHS] learn command in v7 Message-ID: I'm pretty sure that I asked about learn ages back, but I couldn't find any reference to it in the archives. So, I thought I would close the possibly imaginary loop on it. Cuz, I figured it out, and it may prove useful to others or with my track record, even myself in the future :). Learn works fine in v7. It just needs to be properly installed. The command is there already, so you may not need to follow all of the steps below, but it doesn't hurt: I did this as root, but it could possibly be done as another user, I'm not sure. cd /usr/src/cmd/learn make make lessons make play; make log That's it. make will complain about missing files that it tries to delete, but these can be safely ignored, since make then creates them anyway. Here's the result run as a normal user: $ learn These are the available courses -   files   editor   morefiles   macros   eqn   C If you want more information about the courses, or if you have never used 'learn' before, type 'return'; otherwise type the name of the course you want, followed by 'return'. macros If you were in the middle of this subject and want to start where you left off, type the last lesson number the computer printed. To start at the beginning, just hit return. This script deals with the use of the "-ms" macro package to produce Bell Laboratories style documents. Before trying it, you should be familiar with the editor.  To test that, please enter the file typed below, exactly as is, into file "decl".  Then type "ready". .PP When in the course of human events, it becomes necessary for one people to dissolve the political bands which have connected them with another, and to assume among the powers of the earth the separate and equal station to which the laws of Nature and of Nature's God entitle them, a decent respect to the opinions of mankind requires that they should declare the causes which impel them to the separation. $ ed decl ?decl a .PP When in the course of human events, it becomes necessary for one people to dissolve the political bands which have connected them with another, and to assume among the powers of the earth the separate and equal station to which the laws of Nature and of Nature's God entitle them, a decent respect to the opinions of mankind requires that they should declare the causes which impel them to the separation. . w 410 q $ ready Good.  Lesson 1.1a (1) When you have some document typed in "-ms" style, you run it off on your terminal by saying:   nroff -ms file where "file" is the name of the file it is on.  For example, the file "decl" in this directory is in a suitable format for running off this way.  Do so.  Then type "ready". $ Interrupt. Want to go on?  n Bye. $ Pretty slick, really, once you realize that the $ prompt isn't really your shell, it's a shell within learn. Also, there's no learn manpage although there is a document in vol2 of the programmer's manual that describes the program. I couldn't figure out the canonical way to exit, so I just CTRL-DELETE on my mac, which I figure it CTRL-BREAK (^C?). That seems to work. Oh, and according to /usr/src/cmd/learn/README, if you have any trouble: Please report problems, bad lessons, etc., to Brian Kernighan, MH 6021, 2C-518, or Mike Lesk, MH 6377, 2C-572.  Thanks. Enjoy, and happy New Year, folks! Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From krewat at kilonet.net Sat Jan 1 02:13:29 2022 From: krewat at kilonet.net (Arthur Krewat) Date: Fri, 31 Dec 2021 11:13:29 -0500 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <20211230034512.B9B3718C08E@mercury.lcs.mit.edu> <97f563fa-5a17-424b-acc6-07cf127f496d@localhost> Message-ID: On 12/31/2021 10:53 AM, Adam Thornton wrote: > Slightly older, but also slightly more fundamental to the system, you > need look no farther than Solaris's `/bin/sh` for an illustrated > example of the pros and cons of maintaining backwards compatibility.  > It was a pain by, say, 2007, to have to check if you were running on > SunOS and use `/usr/xpg4/bin/sh` (IIRC) if you wanted a POSIX > shell--by that point the other major vendors (and Linux) had something > POSIX as the default shell.  But Sun had an installed user base with a > bunch of shell scripts that depended on pre-POSIX semantics. Did some checking, at the risk of going off-topic: Solaris 11.4 (current patch level, 11.4.40.107.3, December 2021): /bin/sh looks to be Korn shell. root at mercury:~# ls -l /bin/sh -r-xr-xr-x   5 root     bin      2946936 Dec 22 10:46 /bin/sh root at mercury:~# strings /bin/sh | grep Korn | head -1 ][-author?David Korn ][-copyright?Copyright (c) 1982-2021 AT&T Intellectual Property][-license?http://www.eclipse.org/org/documents/epl-v10.html][--catalog?libshell][+NAME? root at mercury:~# sh --version   version         sh (AT&T Research) 93u+ 2012-08-01 Solaris 11.3: /bin/sh seems to be Korn shell. medusa# ls -l /bin/sh lrwxrwxrwx   1 root     root          11 Jun 11  2016 /bin/sh -> amd64/ksh93 medusa# ls -lL /bin/sh -r-xr-xr-x   8 root     bin      2601344 Jul  1  2016 /bin/sh medusa# strings !$ | grep dgk | head -1 strings /bin/sh | grep dgk | head -1 ][-author?David Korn ][-copyright?Copyright (c) 1982-2016 AT&T Intellectual Property][-license?http://www.eclipse.org/org/documents/epl-v10.html][--catalog?libshell][+NAME? medusa# sh --version   version         sh (AT&T Research) 93u+ 2012-08-01 Solaris 10: (seems /bin/sh is still Bourne at this point): zeus<@medusa.kilonet.net># ls -l /bin/sh lrwxrwxrwx   1 root     root          13 Jun  6  2014 /bin/sh -> ../../sbin/sh zeus<@medusa.kilonet.net># ls -lL /bin/sh -r-xr-xr-x   1 root     root       82456 Sep 22  2010 /bin/sh sh --version just opens a new shell. From crossd at gmail.com Sat Jan 1 04:17:18 2022 From: crossd at gmail.com (Dan Cross) Date: Fri, 31 Dec 2021 13:17:18 -0500 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <20211230034512.B9B3718C08E@mercury.lcs.mit.edu> <97f563fa-5a17-424b-acc6-07cf127f496d@localhost> Message-ID: On Fri, Dec 31, 2021, 10:54 AM Adam Thornton wrote: > Slightly older, but also slightly more fundamental to the system, you need > look no farther than Solaris's `/bin/sh` for an illustrated example of the > pros and cons of maintaining backwards compatibility. [snip] > Sun is not the exemplar here: the move from SunOS 4's BSD userland to Solaris 2's SVR4 broke tons of things. They didn't seem to mind that their customers had to pay the cost of adaptation. The Linux example is also a bit strange. The move from e.g. `ifconfig` and `netstat to `ip` and `ss` required lots of local retooling (I suppose some distros retain the older tools or let you install them as an option. I suppose one could always install `bash` on Solaris as a shell lingua franca, as well). Not to mention systemd. The point is, breaking changes are introduced all the time. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Jan 1 04:23:34 2022 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 31 Dec 2021 10:23:34 -0800 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <20211230034512.B9B3718C08E@mercury.lcs.mit.edu> <97f563fa-5a17-424b-acc6-07cf127f496d@localhost> Message-ID: <20211231182334.GO31637@mcvoy.com> On Fri, Dec 31, 2021 at 01:17:18PM -0500, Dan Cross wrote: > On Fri, Dec 31, 2021, 10:54 AM Adam Thornton wrote: > > > Slightly older, but also slightly more fundamental to the system, you need > > look no farther than Solaris's `/bin/sh` for an illustrated example of the > > pros and cons of maintaining backwards compatibility. [snip] > > > > Sun is not the exemplar here: the move from SunOS 4's BSD userland to > Solaris 2's SVR4 broke tons of things. They didn't seem to mind that their > customers had to pay the cost of adaptation. I was there for that and I minded like crazy. It was a hugely bad move in my opinion. Time has not changed that. > The Linux example is also a bit strange. The move from e.g. `ifconfig` and > `netstat to `ip` and `ss` required lots of local retooling I never understood why Linux did that. From krewat at kilonet.net Sat Jan 1 04:29:59 2022 From: krewat at kilonet.net (Arthur Krewat) Date: Fri, 31 Dec 2021 13:29:59 -0500 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <20211230034512.B9B3718C08E@mercury.lcs.mit.edu> <97f563fa-5a17-424b-acc6-07cf127f496d@localhost> Message-ID: <4d521d21-d115-faf6-ba72-b1ffdd7db03a@kilonet.net> On 12/31/2021 1:17 PM, Dan Cross wrote: > I suppose one could always install `bash` on Solaris as a shell lingua > franca, as well zeus# uname -a SunOS zeus 5.10 Generic_147441-10 i86pc i386 i86pc zeus# which bash /usr/bin/bash Twas installed by default with Solaris 10, at least later versions that I know of. I would usually change root's login shell to /bin/bash and never had an issue. art k. From crossd at gmail.com Sat Jan 1 04:37:29 2022 From: crossd at gmail.com (Dan Cross) Date: Fri, 31 Dec 2021 13:37:29 -0500 Subject: [TUHS] moving directories in svr2 In-Reply-To: <20211231182334.GO31637@mcvoy.com> References: <20211230034512.B9B3718C08E@mercury.lcs.mit.edu> <97f563fa-5a17-424b-acc6-07cf127f496d@localhost> <20211231182334.GO31637@mcvoy.com> Message-ID: On Fri, Dec 31, 2021, 1:23 PM Larry McVoy wrote: > On Fri, Dec 31, 2021 at 01:17:18PM -0500, Dan Cross wrote: > > On Fri, Dec 31, 2021, 10:54 AM Adam Thornton > wrote: > > > > > Slightly older, but also slightly more fundamental to the system, you > need > > > look no farther than Solaris's `/bin/sh` for an illustrated example of > the > > > pros and cons of maintaining backwards compatibility. [snip] > > > > > > > Sun is not the exemplar here: the move from SunOS 4's BSD userland to > > Solaris 2's SVR4 broke tons of things. They didn't seem to mind that > their > > customers had to pay the cost of adaptation. > > I was there for that and I minded like crazy. It was a hugely bad move > in my opinion. Time has not changed that. > Yeah. I work on Illumos now for Oxide, and it's...fine? But it took a long time to get there. When the SunOS->Solaris changeover happened, the thing that really tripped me up was `awk`. SunOS 4's awk was nawk, but Solaris 2's awk was 7th Ed awk and lacked functions and so forth. nawk was available as `nawk`, but it seemed like a gratuitous regression and we had to modify a lot of local shell scripts and so on. > The Linux example is also a bit strange. The move from e.g. `ifconfig` and > > `netstat to `ip` and `ss` required lots of local retooling > > I never understood why Linux did that. > I've been dealing with a couple of Linux machines over the break, and trying to do things the canonical way instead of running back to the familiar tools, but some things just aren't supported. `ss` doesn't know about some of the more exotic address families, like AX.25 and NET/ROM. I can certainly understand why (talk about a hobbyist niche...) but the irony is that I had to install `netstat` anyway. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.paulsen at firemail.de Sat Jan 1 05:01:43 2022 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Fri, 31 Dec 2021 20:01:43 +0100 Subject: [TUHS] learn command in v7 In-Reply-To: References: Message-ID: <9f1d20500d6bb61d55068a2a18f7baa7@firemail.de> An HTML attachment was scrubbed... URL: From chet.ramey at case.edu Sat Jan 1 04:56:51 2022 From: chet.ramey at case.edu (Chet Ramey) Date: Fri, 31 Dec 2021 13:56:51 -0500 Subject: [TUHS] moving directories in svr2 In-Reply-To: <99D8FDF5-7B60-43CA-AAAD-974056644668@iitbombay.org> References: <20211230034512.B9B3718C08E@mercury.lcs.mit.edu> <99D8FDF5-7B60-43CA-AAAD-974056644668@iitbombay.org> Message-ID: <702196cf-2209-5416-5505-b3a70d3a682a@case.edu> On 12/30/21 7:43 PM, Bakul Shah wrote: > Without the ".." entry you can't map a dir inode back to a path. > Note that something similar can happen even today: > > $ mkdir ~/a; cd ~/a; rm -rf ~/a; cd .. > cd: no such file or directory: .. > > $ mkdir -p ~/a/b; ln -s ~/a/b b; cd b; mv ~/a/b ~/a/c; cd ../b > ls: ../b: No such file or directory Modern POSIX shells attempt to disguise this for cd and pwd, using $PWD and a canonicalization algorithm that essentially backs up one component when it encounters `..' and removes `.' (with verification at each step and error handling of various quality). It's the default behavior; the traditional physical behavior is available with -P. It's a variant of the ksh schme that Rob's lexical names paper explores. It has the usual weaknesses: what works for cd doesn't work for, say, ls or any other utilities that don't understand this particular scheme. It produces the expected behavior for the first case above, but can be fooled by file system changes that invalidate $PWD, as in the second case. (I assume the `ls' error message was either a typo or an artifact of a function or alias for `cd'). -- ``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 will.senn at gmail.com Sat Jan 1 06:36:40 2022 From: will.senn at gmail.com (Will Senn) Date: Fri, 31 Dec 2021 14:36:40 -0600 Subject: [TUHS] v7 /etc/ttys and /usr/adm/wtmp shenanigans Message-ID: I enabled user accounting on my v7 instance and I noticed it "growing without bound" and while this is noted as a possibility in the ac(1) man page, I was pretty sure the original authors didn't mean 30k a second. I scratched my head and thought for a while and then started experimenting to see what the heck was going on. I removed /usr/adm/wtmp (which I had created to enable accounting in the first place) and the little red disk write arrow on my mac went away, but not the little green disk read arrow... hmm. Something was keeping my v7 instance very busy reading disk, that was for sure. I went through a few (dozens) more tests and experiments, reread a bunch of man pages, Ritchie's v7 install note, and thought some more and here's what I came up with... If you modify your system to add dci lines and you enable some ttys in /etc/ttys and you enable user accounting. Then, the next time you boot into a kernel that doesn't have dci support, init or some other process will try and fail to read the enabled ttys, log something in /usr/adm/wtmp, if it exists, and then loop (very quickly), over and over and over. If you aren't paying attention, this will hardly be noticeable on modern hardware running simh, but I'm guessing this would have been disastrous, back in the day. The simple solution is to boot w/dci enabled when you have ttys enabled, and only boot w/o dci enabled when you have disabled the ttys. I'm guessing that this wasn't really ever an issue, back in the day, as folks prolly didn't just yank their dci's and reboot a different kernel? But, such are the joys of simulation. Anyhow, if this doesn't sound like a very likely or reasonable analysis of what was happening, I'd appreciate your letting me know, or if you've experienced something like it before, it'd be great to know that I'm not alone in this silliness. Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggm at algebras.org Sat Jan 1 09:07:49 2022 From: ggm at algebras.org (George Michaelson) Date: Sat, 1 Jan 2022 09:07:49 +1000 Subject: [TUHS] roff(7) In-Reply-To: References: Message-ID: In 79-82 Runoff got me my undergraduate texts formatted on a dec10. Moving to work post degree on Unix and vms systems (my memory is that for some reason VMS didn't have runoff) I had the Normalised "oh this must be the same" hitting roff/nroff and got really confused by having both ms and me macros. Nobody seemed to be able to explain to me why you wanted both (the mysteries and distinctions of v vs BSD were completely lost to me at this early stage). But macros aside, anyone who had used runoff had a massively simpler path into roff than TeX. My future was set. The phd students at Leeds looked down their noses at me for using cryptic .2 letter inline magic. They were the high priests of things, I was just a computer operator. Watching them spend weeks and weeks wrangling a one em offset problem stopping perfection in print was.. entertaining. Then we somehow got ditroff at Leeds uni. That was really weird, because it was obviously "better" but again nobody could explain why the di- bit magically appeared. (We had a Benson- Varian slimey paper printer at some fantastical dpi like 120 or 150 which turned up at the same time.) wasn't this just Troff? Oh God, was it really called t/roff not troff... The entire production path to lpr had some driver logic to put "--" cut marks on the continuous paper so you knew where to guillotine from the roll, but unfortunately was wired to US legal paper sizes not A4 (presumably some macro definitions file would have fixed this) I still have a poem from the British computer society about the birth of the icl 2900 typeset in olde English, centred. That Benson-Varian must have used damn good printing because it's still readable 40 years later when parking tickets (similar print process?) Fade out in a day. It was also around the time that "tbl" had what we all thought was a bug, drawing the horizontal boxlines off by one. Nobody at the time understood this was to counteract a specific electromechanical printer issue inside AT&T. Since it was coming in BSD Unix I can imagine back inside Berkeley people binning our complaints. If you don't remember which 1200bpi tape the software came from, don't just complain at random... The "pic" tool had also just hit, and it obviously didn't share those line offset problems which made us all very suspicious: "ITS THE SAME PEOPLES CODE" we shouted at each other (it wasnt) ... G -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Jan 1 09:40:39 2022 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 31 Dec 2021 15:40:39 -0800 Subject: [TUHS] roff(7) In-Reply-To: References: Message-ID: <20211231234039.GU31637@mcvoy.com> On Sat, Jan 01, 2022 at 09:07:49AM +1000, George Michaelson wrote: > But macros aside, anyone who had used runoff had a > massively simpler path into roff than TeX. My future was set. The phd > students at Leeds looked down their noses at me for using cryptic .2 letter > inline magic. They were the high priests of things, I was just a computer > operator. Watching them spend weeks and weeks wrangling a one em offset > problem stopping perfection in print was.. entertaining. I was program committee chair for Linux Expo in 1999 (all that means is I formatted the proceedings into a book). I let people use LaTex but encouraged troff. A few people tried out troff and their reaction was "Wow, that was so easy and groff is really fast!" The only negative reaction was table of contents complaints, LaTex is 2 pass so it can do them, roff is one pass so you have to fiddle with things. A lot. I've used *roff for almost 40 years and I've never had the urge to use something else. I wrote a paper a while back where they insisted on LaTex and it just made me like *roff more. It's Betamax and VHS all over again, the crappy answer won. --lm From tytso at mit.edu Sat Jan 1 10:09:04 2022 From: tytso at mit.edu (Theodore Ts'o) Date: Fri, 31 Dec 2021 19:09:04 -0500 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <20211230034512.B9B3718C08E@mercury.lcs.mit.edu> <97f563fa-5a17-424b-acc6-07cf127f496d@localhost> Message-ID: On Fri, Dec 31, 2021 at 01:17:18PM -0500, Dan Cross wrote: > On Fri, Dec 31, 2021, 10:54 AM Adam Thornton wrote: > > > Slightly older, but also slightly more fundamental to the system, you need > > look no farther than Solaris's `/bin/sh` for an illustrated example of the > > pros and cons of maintaining backwards compatibility. [snip] > > > > Sun is not the exemplar here: the move from SunOS 4's BSD userland to > Solaris 2's SVR4 broke tons of things. They didn't seem to mind that their > customers had to pay the cost of adaptation. I'm sure that there were people at Sun who *did* care. The story I had heard was that it was a decision made at the C-suite level, and was a quid-pro-quo where to get that sweet, sweet, cash from AT&T so Sun could stay afloat, they had to switch over to System V. (No matter that Solaris 2 was a major step *backwards* in terms of performance and stability compared to Sun OS....) > The Linux example is also a bit strange. The move from e.g. `ifconfig` and > `netstat to `ip` and `ss` required lots of local retooling (I suppose some > distros retain the older tools or let you install them as an option. I > suppose one could always install `bash` on Solaris as a shell lingua > franca, as well). Not to mention systemd. The point is, breaking changes > are introduced all the time. Are there distros who are no longer supplying ifconfig/netstat/route, at least as an optional package? That's surprising if so. All of the kernel interfaces to allow the old-style net-tools packages to work, as well as the BSD-style ioctls/setsockopt, etc., are still around, and fully supported. At least on my systems, I still install net-tools because my finger macros are still used to using ifconfig, netstat, and friends. The reason why ip and ss were added was because there was a significant amount of new functionality that was added to the Linux networking stack (especially relating to routing and address aliasing) that couldn't be expressed using the older C programming interfaces as well as the ifconfig/route shell commands. There were two north star principles about the new networking interfaces: 1) The old interfaces were always supposed to continue to work, and if you didn't need the new functionality, there was no reason to use the newer interfaces. 2) The new interfaces were *supposed* to be a strict superset of the old interfaces. If in fact ip and ss don't support AX.25, or other "exotic address families" --- that's a bug, and should be reported as such. That being said, if you don't need the fancy new features, there's no reason to switch away from ifconfig. The whole *point* of the first principle was that we didn't want to force users to do a forced Python 2.7 -> Python 3 style "long march" migration. - Ted From grog at lemis.com Sat Jan 1 10:56:05 2022 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Sat, 1 Jan 2022 11:56:05 +1100 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: <20211231234039.GU31637@mcvoy.com> References: <20211231234039.GU31637@mcvoy.com> Message-ID: <20220101005605.GL75481@eureka.lemis.com> On Friday, 31 December 2021 at 15:40:39 -0800, Larry McVoy wrote: > On Sat, Jan 01, 2022 at 09:07:49AM +1000, George Michaelson wrote: >> But macros aside, anyone who had used runoff had a >> massively simpler path into roff than TeX. My future was set. The phd >> students at Leeds looked down their noses at me for using cryptic .2 letter >> inline magic. They were the high priests of things, I was just a computer >> operator. Watching them spend weeks and weeks wrangling a one em offset >> problem stopping perfection in print was.. entertaining. > > I was program committee chair for Linux Expo in 1999 (all that means is > I formatted the proceedings into a book). I let people use LaTex but > encouraged troff. A few people tried out troff and their reaction was > "Wow, that was so easy and groff is really fast!" Heh. I had a similar experience when writing "Porting Unix Software" (1995). O'Reilly insisted on using groff with their macro set, and I had only had experience with (La)TeX. I fought for quite some time, but ultimately gave in. Despite Baby Duck Syndrome, I discovered that I far preferred groff to TeX, and I've been using it ever since. From PUS: .Pe More than anywhere else in porting, it is good for your state of mind to steer clear of .TXI \& internals. The assumptions on which the syntax is based differ markedly from those of other programming languages. For example, identifiers may not contain digits, and spaces are required only when the meaning would otherwise be ambiguous (to .TXI , not to you), so the sequence \s10\f(CWfontsize300\fR\s0 is in fact the identifier \s10\f(CWfontsize\fR\s0 followed by the number \s10\f(CW300\fR\s0. On the other hand, it is almost impossible to find any good solid information in the documentation, so you could spend hours trying to solve a minor problem. I have been using .TXI \& frequently for years, and I still find it the most frustrating program I have ever seen.\** .FS When I wrote this sentence, I wondered if I wasn't overstating the case. Mike Loukides, the author of \fIProgramming with GNU Software\fR, reviewed the final draft and added a single word: \fIAmen\fR. .FE > The only negative reaction was table of contents complaints, LaTex is > 2 pass so it can do them, roff is one pass so you have to fiddle with > things. A lot. I solved that issue in later documents with two passes in the Makefile targets, frobbing things like references and contents in between. 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.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From phil at ultimate.com Sat Jan 1 11:11:20 2022 From: phil at ultimate.com (Phil Budne) Date: Fri, 31 Dec 2021 20:11:20 -0500 Subject: [TUHS] roff(7) In-Reply-To: References: Message-ID: <202201010111.2011BK62034004@ultimate.com> > In 79-82 Runoff got me my undergraduate texts formatted on a dec10. > > Moving to work post degree on Unix and vms systems (my memory is that for > some reason VMS didn't have runoff) I had the Normalised "oh this must be > the same" hitting roff/nroff and got really confused by having both ms and > me macros. I similarly moved from the DEC 36-bit RUNOFF world. I was confused why anyone would need macros, until I typed in a paper, and didn't get any page numbers!! I'm 99.44% sure the VMS world got something called DSR (Digital Standard Runoff) at some point (likely written in BLISS). DEC-10/20 RUNOFF files did not always format correctly under DSR (DEC "standards" tended to be, the VMS team implements what they want, and they adjust the standard). I wondered about the RUNOFF/roff connection until I learned about CTSS, and was perplexed by IBM SCRIPT, which clearly had shared heritage, but didn't start with the letter r, but Wikipedia just told me: The origin of IBM's SCRIPT (markup) software began in 1968 when "IBM contracted Stuart Madnick of MIT to write a simple document preparation ..."[8] to run on CP/67.[9] He modeled it on MIT's CTSS RUNOFF.[10][11] So it must be true! Look at all the footnotes! But I was MOST perplexed when I was helping bring PDP-7 UNIX back up (I cobbled a replacement shell together), and found PDP-7 roff was as (or more) feeble than nroff without using a macro package (for fun, I tried writing some man pages, tho I was pretty sure on-line documentation didn't come about until PDP-11 days)), only without a macro facility! From torek at elf.torek.net Sat Jan 1 11:17:19 2022 From: torek at elf.torek.net (Chris Torek) Date: Fri, 31 Dec 2021 17:17:19 -0800 (PST) Subject: [TUHS] roff(7) In-Reply-To: <202201010111.2011BK62034004@ultimate.com> Message-ID: <202201010117.2011HJV5007172@elf.torek.net> I actually strongly prefer TeX/LaTeX to *roff. But LaTeX does have its Knuthian and Stanfordish peculiarities. It helps if you read The TeXbook first and understand Tex's macro weirdness and \catcodes. Both systems have their blind spots. Ditroff fixes most of the big ones in nroff/troff, of course... Chris From jacob.ritorto at gmail.com Sat Jan 1 12:46:05 2022 From: jacob.ritorto at gmail.com (Jacob Ritorto) Date: Fri, 31 Dec 2021 21:46:05 -0500 Subject: [TUHS] v7 /etc/ttys and /usr/adm/wtmp shenanigans In-Reply-To: References: Message-ID: My boss 23 years ago (who was at CMU in the eighties working on systems like these) told me that on some systems, when cleaning up wtmp, it's necessary to truncate the wtmp file (i.e. cat /dev/null into it -- never to flat out remove it) because something in the system doesn't let go of the inode (or somesuch) that it thinks the file was on. I never understood why but have done what he told me since then :) I wonder if this has something to do with your phenomenon. On Fri, Dec 31, 2021 at 4:41 PM Will Senn wrote: > I enabled user accounting on my v7 instance and I noticed it "growing > without bound" and while this is noted as a possibility in the ac(1) man > page, I was pretty sure the original authors didn't mean 30k a second. I > scratched my head and thought for a while and then started experimenting to > see what the heck was going on. I removed /usr/adm/wtmp (which I had > created to enable accounting in the first place) and the little red disk > write arrow on my mac went away, but not the little green disk read > arrow... hmm. Something was keeping my v7 instance very busy reading disk, > that was for sure. I went through a few (dozens) more tests and > experiments, reread a bunch of man pages, Ritchie's v7 install note, and > thought some more and here's what I came up with... > > If you modify your system to add dci lines and you enable some ttys in > /etc/ttys and you enable user accounting. Then, the next time you boot into > a kernel that doesn't have dci support, init or some other process will try > and fail to read the enabled ttys, log something in /usr/adm/wtmp, if it > exists, and then loop (very quickly), over and over and over. If you aren't > paying attention, this will hardly be noticeable on modern hardware running > simh, but I'm guessing this would have been disastrous, back in the day. > > The simple solution is to boot w/dci enabled when you have ttys enabled, > and only boot w/o dci enabled when you have disabled the ttys. > > I'm guessing that this wasn't really ever an issue, back in the day, as > folks prolly didn't just yank their dci's and reboot a different kernel? > But, such are the joys of simulation. > > Anyhow, if this doesn't sound like a very likely or reasonable analysis of > what was happening, I'd appreciate your letting me know, or if you've > experienced something like it before, it'd be great to know that I'm not > alone in this silliness. > > Will > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Jan 1 13:06:49 2022 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 31 Dec 2021 19:06:49 -0800 Subject: [TUHS] roff(7) In-Reply-To: <202201010117.2011HJV5007172@elf.torek.net> References: <202201010111.2011BK62034004@ultimate.com> <202201010117.2011HJV5007172@elf.torek.net> Message-ID: <20220101030649.GA8135@mcvoy.com> How does groff fair? On Fri, Dec 31, 2021 at 05:17:19PM -0800, Chris Torek wrote: > I actually strongly prefer TeX/LaTeX to *roff. But LaTeX does have > its Knuthian and Stanfordish peculiarities. It helps if you read > The TeXbook first and understand Tex's macro weirdness and \catcodes. > > Both systems have their blind spots. Ditroff fixes most of the > big ones in nroff/troff, of course... > > Chris -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From lm at mcvoy.com Sat Jan 1 13:15:11 2022 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 31 Dec 2021 19:15:11 -0800 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: <20220101005605.GL75481@eureka.lemis.com> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> Message-ID: <20220101031511.GB8135@mcvoy.com> On Sat, Jan 01, 2022 at 11:56:05AM +1100, Greg 'groggy' Lehey wrote: > > The only negative reaction was table of contents complaints, LaTex is > > 2 pass so it can do them, roff is one pass so you have to fiddle with > > things. A lot. > > I solved that issue in later documents with two passes in the Makefile > targets, frobbing things like references and contents in between. I was troff friends with W Richard Stevens, he shared with me a lot of what he did in troff. He did the two pass thing. Nice guy and got as much out of roff that anyone could, all of his books were troff. From fair-tuhs at netbsd.org Sat Jan 1 13:18:30 2022 From: fair-tuhs at netbsd.org (Erik E. Fair) Date: Fri, 31 Dec 2021 19:18:30 -0800 Subject: [TUHS] v7 /etc/ttys and /usr/adm/wtmp shenanigans In-Reply-To: References: Message-ID: <28153.1641007110@cesium.clock.org> Classically, files don't get de-allocated (their blocks re-added to the filesystem free list) until the last open reference to their inode is removed, even if the file name is removed from all directories. This behavior is commonly used for temporary files: open(2) with O_CREAT and unlink(2), and file disappears when the file descriptor is finally closed or the process exits without explicitly closing the descriptor (the kernel will close all descriptors associated with an exiting process). Where process accounting is concerned, the kernel itself holds the inode reference until it is explictly told to turn off process accounting. See acct(2). Erik Fair From ggm at algebras.org Sat Jan 1 13:34:12 2022 From: ggm at algebras.org (George Michaelson) Date: Sat, 1 Jan 2022 13:34:12 +1000 Subject: [TUHS] roff(7) In-Reply-To: <202201010117.2011HJV5007172@elf.torek.net> References: <202201010111.2011BK62034004@ultimate.com> <202201010117.2011HJV5007172@elf.torek.net> Message-ID: It's probable that I'm influenced by being an autodidact for the roff family and suffered "You're doing it wrong" disease from literate TeX users. Roff may be that kind of arcane evil we probably should eschew but it's morally closer to the typesetting machine. You tell it to select a reel of monotype font, move exactly (for this pointsize) some number of units and expose the mask to light at that point. It's a machine. TeX targeted a theoretically pure model of the world, and grudgingly admits the practicality of having to approximate the perfect line by some bezier curve, but why requires a phd in theoretical maths and there's a queue of art historians out the door who are holding golden proportions curves shouting "you're doing it wrong". TeX is a machine too but it's bytecode, not machinecode. I think I hurled "when are you implementing OSI" abuse at your talks in AUUG meetings Chris, if you'd replied "never" it would have been wiser than your more temperate "later" response as I recall it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggm at algebras.org Sat Jan 1 13:36:52 2022 From: ggm at algebras.org (George Michaelson) Date: Sat, 1 Jan 2022 13:36:52 +1000 Subject: [TUHS] v7 /etc/ttys and /usr/adm/wtmp shenanigans In-Reply-To: <28153.1641007110@cesium.clock.org> References: <28153.1641007110@cesium.clock.org> Message-ID: It was bad luck if the process holding your file open was an unkillable zombie. Reboot and clri fixes all things. Okay maybe "fix" isn't the word I want... On Sat, 1 Jan 2022, 1:27 pm Erik E. Fair, wrote: > Classically, files don't get de-allocated (their blocks re-added to the > filesystem free list) until the last open reference to their inode is > removed, even if the file name is removed from all directories. > > This behavior is commonly used for temporary files: open(2) with O_CREAT > and unlink(2), and file disappears when the file descriptor is finally > closed or the process exits without explicitly closing the descriptor (the > kernel will close all descriptors associated with an exiting process). > > Where process accounting is concerned, the kernel itself holds the inode > reference until it is explictly told to turn off process accounting. See > acct(2). > > Erik Fair > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Sun Jan 2 06:00:15 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Sat, 01 Jan 2022 12:00:15 -0800 Subject: [TUHS] roff(7) [ and other related stuff ] In-Reply-To: <20211231234039.GU31637@mcvoy.com> References: <20211231234039.GU31637@mcvoy.com> Message-ID: <202201012000.201K0Fd31610896@darkstar.fourwinds.com> Larry McVoy writes: > On Sat, Jan 01, 2022 at 09:07:49AM +1000, George Michaelson wrote: > > But macros aside, anyone who had used runoff had a > > massively simpler path into roff than TeX. My future was set. The phd > > students at Leeds looked down their noses at me for using cryptic .2 letter > > inline magic. They were the high priests of things, I was just a computer > > operator. Watching them spend weeks and weeks wrangling a one em offset > > problem stopping perfection in print was.. entertaining. > > I was program committee chair for Linux Expo in 1999 (all that means is > I formatted the proceedings into a book). I let people use LaTex but > encouraged troff. A few people tried out troff and their reaction was > "Wow, that was so easy and groff is really fast!" > > The only negative reaction was table of contents complaints, LaTex is > 2 pass so it can do them, roff is one pass so you have to fiddle with > things. A lot. > > I've used *roff for almost 40 years and I've never had the urge to use > something else. I wrote a paper a while back where they insisted on > LaTex and it just made me like *roff more. > > It's Betamax and VHS all over again, the crappy answer won. Happy New Year to everybody. COVID has taken its toll if people are spending New Year's Eve thinking about text formatting :-) Warning - this is a grumpy pendantic Jon post... First of all, I love *roff. It's the thing that got me started on UNIX when I needed to write documentation for my first summer project at BTL. There was a V3 UNIX machine across the hall from my lab (2C-517?) that I used for that. Been a fan ever since. Complaints about things like tables of contents are just that - complaints. C'mon - this is UNIX, composable software tools. So what if LaTex is 2 pass and *roff is 1 pass. I have a simple script and a Makefile that adds a 2nd pass and does all that. Even with that the LaTex ecosystem is way more complex than *roff. The one thing that *roff doesn't do which I think I remember from runoff is that runoff allowed in-line formatting requests; not just special escape sequences but everything. I never got into TeX although I've tried. Probably just first language syndrome. Coming from UNIX, I just find using \ as a non-escape character ugly, just like DOS\Windows pathnames. But there are a number of things that annoy me about it leading to the pendantic part. In my opinion, the big innovation in TeX is the two-dimensional layout. I do spend a bit of time on big documents adding keeps and such to avoid orphan and widow lines. In my opinion, much of what Don did in TeX added no value. Been meaning to ask him about it but with COVID haven't seen him in a while. For example, the language parsing broke no new ground. If it were me, and I wanted to explore/demo/implement two-dimensional layout, I would have added it to *roff. To me, the rest of it was not only a waste of time, but actually made the world worse by making two incompatible ways of doing things that practitioners have to learn instead of one. Make's life harder, not easier. How much time went into the development of the TeX front end that could have been done in a few hours had Don used lex/yacc? I made a similar comment to Alan Wirfs-Brock when proofreading his big 20th anniversary article on JavaScript. I don't get the "oooo, Eich did this one-week sprint to get a demo up and running" stuff. Had Eich used lex/yacc instead of rolling his own not only would he have not had to sprint, but we likely wouldn't still be fighting with optional semicolons decades later since that's harder to do with those tools. I read it as praising him for making a bad decision. This is my biggest issue with "modern software development". Seems like every project has to begin with it's own language, build system, package manager, and so on. Were I a modern software developer I'd create all that plus a new email client just to send this message :-) None of this behavior adds value. It makes it so that practitioners have to learn many arcane incompatible systems that all do pretty much the same thing. While I haven't given it a hard look, I'd look at the netstat/ss/... stuff with the same lens. Sure, new features were needed, but was it necessary to make the old stuff work differently? In my roll as a mentor, this is the stuff that freaks out students, especially during their first internships. I have to explain that there are two types of knowledge at play: their coursework and company crap. I tell them that they should be secure in the quality of their education and never ask their boss how to copy a string or something like that. But, it's perfectly OK to ask for help on the internal undocumented crufty development environment. In some respects, it's similar to how I decide what to bill for and what not to on consulting projects. I don't bill for learning some general knowledge thing that I didn't know. I do bill for learning odd project-specific weirdness that I'll never use on anything else. Back to *roff. Might have said this before, but pic is probably my favorite little language. It's like having an artist on staff because I can tell it what to draw and it will; I'm terrible at drawing. One of its best features that unfortunately was missed by the people who wrote fig is invisible objects. I typically start a figure with a big invisible box and hang things on it. If I need to move or scale things I just change the size of the box. Sure beats hours of carpal-tunnel clicking to move a pile of objects in a drawing program. I guess it's relative addressing versus absolute all over again; relative addressing makes it easier to relocate objects. One more way to look at this. I think that a lot depends on the state of the world when one starts using stuff. I remember a friend of mine telling me how much simpler DOS was as compared to UNIX. I told him that I thought that it was because he was growing up with DOS, and learned new features as they came along which is what I did with UNIX. By the the time he got started UNIX was more complicated. Of course, DOS caught up. It's sadly amusing how this applies to markup languages. People who carped about *roff requests are happy to craft HTML. I guess what's missing from the field is Lorites from Neal Stephenson's Anathem if you haven't read it. A priesthood who's role is to inform people claiming to invent something new that it's already been done. Jon From lm at mcvoy.com Sun Jan 2 10:12:44 2022 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 1 Jan 2022 16:12:44 -0800 Subject: [TUHS] roff(7) [ and other related stuff ] In-Reply-To: <202201012000.201K0Fd31610896@darkstar.fourwinds.com> References: <20211231234039.GU31637@mcvoy.com> <202201012000.201K0Fd31610896@darkstar.fourwinds.com> Message-ID: <20220102001244.GF10078@mcvoy.com> On Sat, Jan 01, 2022 at 12:00:15PM -0800, Jon Steinhart wrote: > This is my biggest issue with "modern software development". Seems like every > project has to begin with it's own language, build system, package manager, > and so on. Were I a modern software developer I'd create all that plus a new > email client just to send this message :-) None of this behavior adds value. > It makes it so that practitioners have to learn many arcane incompatible > systems that all do pretty much the same thing. This. This is it. You and I must be the same kind of weird because when I wanted a scripting language that wasn't TCL weirdness, I had a compiler built that compiled stuff that so looked like C, I had a guy fix a bug in a patch that flew by. My big complaint with stuff like Rust, or even Go (sorry Rob), is that they picked a different syntax. Why not just use C syntax and extend it to do what you want? Why must every project redo everything. --lm who has moved to full on "Get off my lawn" From cowan at ccil.org Sun Jan 2 11:04:58 2022 From: cowan at ccil.org (John Cowan) Date: Sat, 1 Jan 2022 20:04:58 -0500 Subject: [TUHS] roff(7) [ and other related stuff ] In-Reply-To: <20220102001244.GF10078@mcvoy.com> References: <20211231234039.GU31637@mcvoy.com> <202201012000.201K0Fd31610896@darkstar.fourwinds.com> <20220102001244.GF10078@mcvoy.com> Message-ID: On Sat, Jan 1, 2022 at 7:13 PM Larry McVoy wrote: > My big complaint with stuff like Rust, or even Go (sorry Rob), is that they > picked a different syntax. Why not just use C syntax and extend it to do > what you want? Why must every project redo everything. > Why use C syntax? What was wrong with Fortran, Lisp, or Cobol syntax, extended to do what you wanted? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sun Jan 2 11:20:33 2022 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 1 Jan 2022 17:20:33 -0800 Subject: [TUHS] roff(7) [ and other related stuff ] In-Reply-To: References: <20211231234039.GU31637@mcvoy.com> <202201012000.201K0Fd31610896@darkstar.fourwinds.com> <20220102001244.GF10078@mcvoy.com> Message-ID: <20220102012033.GB7055@mcvoy.com> On Sat, Jan 01, 2022 at 08:04:58PM -0500, John Cowan wrote: > On Sat, Jan 1, 2022 at 7:13 PM Larry McVoy wrote: > > My big complaint with stuff like Rust, or even Go (sorry Rob), is that they > > picked a different syntax. Why not just use C syntax and extend it to do > > what you want? Why must every project redo everything. > > Why use C syntax? What was wrong with Fortran, Lisp, or Cobol syntax, > extended to do what you wanted? I'm almost speechless. My progression was Basic, Pascal, C (and later Fortran, Lisp, no Cobol, I did an Ada Compiler so Ada I guess). Then on to awk, perl, tcl, I tried to like C++ but couldn't, tried to like Rust, Go, D, and couldn't. If you think any of those other languages remotely approach the elegance of C, I just don't know what to say. C is beautiful, you look at the code and you can see what the hardware will be doing but it isn't assembler. It's what assembler wished it could be. It's the right mix of high enough that it works over all architectures and low enough that you see the hardware. You don't see the hardware with any of the other languages you listed. From usotsuki at buric.co Sun Jan 2 11:47:11 2022 From: usotsuki at buric.co (Steve Nickolas) Date: Sat, 1 Jan 2022 20:47:11 -0500 (EST) Subject: [TUHS] roff(7) [ and other related stuff ] In-Reply-To: <20220102012033.GB7055@mcvoy.com> References: <20211231234039.GU31637@mcvoy.com> <202201012000.201K0Fd31610896@darkstar.fourwinds.com> <20220102001244.GF10078@mcvoy.com> <20220102012033.GB7055@mcvoy.com> Message-ID: On Sat, 1 Jan 2022, Larry McVoy wrote: > On Sat, Jan 01, 2022 at 08:04:58PM -0500, John Cowan wrote: > >> Why use C syntax? What was wrong with Fortran, Lisp, or Cobol syntax, >> extended to do what you wanted? > > I'm almost speechless. My progression was Basic, Pascal, C (and later > Fortran, Lisp, no Cobol, I did an Ada Compiler so Ada I guess). Then > on to awk, perl, tcl, I tried to like C++ but couldn't, tried to like > Rust, Go, D, and couldn't. Kinda sounds like me. Classic Microsoft BASIC, then QBASIC which was a mutant freak dialect with structs, functions and stuff... started learning C++ and then moved to C. I rarely use anything these days but C and once in a blue moon QBASIC for something quick and dirty. > If you think any of those other languages remotely approach the elegance > of C, I just don't know what to say. This. I think it blends terseness, cleanness, simplicity and ease of use in just the right quantities in a way no language before or since has really been able to muster. Its only real weakness to me is that it isn't very good at string handling (the reason I sometimes kitbash stuff in BASIC still). -uso. From jon at fourwinds.com Sun Jan 2 11:48:38 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Sat, 01 Jan 2022 17:48:38 -0800 Subject: [TUHS] roff(7) [ and other related stuff ] In-Reply-To: <20220102012033.GB7055@mcvoy.com> References: <20211231234039.GU31637@mcvoy.com> <202201012000.201K0Fd31610896@darkstar.fourwinds.com> <20220102001244.GF10078@mcvoy.com> <20220102012033.GB7055@mcvoy.com> Message-ID: <202201020148.2021mcbd1620481@darkstar.fourwinds.com> Larry McVoy writes: > On Sat, Jan 01, 2022 at 08:04:58PM -0500, John Cowan wrote: > > On Sat, Jan 1, 2022 at 7:13 PM Larry McVoy wrote: > > > My big complaint with stuff like Rust, or even Go (sorry Rob), is that they > > > picked a different syntax. Why not just use C syntax and extend it to do > > > what you want? Why must every project redo everything. > > > > Why use C syntax? What was wrong with Fortran, Lisp, or Cobol syntax, > > extended to do what you wanted? > > I'm almost speechless. My progression was Basic, Pascal, C (and later > Fortran, Lisp, no Cobol, I did an Ada Compiler so Ada I guess). Then > on to awk, perl, tcl, I tried to like C++ but couldn't, tried to like > Rust, Go, D, and couldn't. > > If you think any of those other languages remotely approach the elegance > of C, I just don't know what to say. > > C is beautiful, you look at the code and you can see what the hardware > will be doing but it isn't assembler. It's what assembler wished it > could be. It's the right mix of high enough that it works over all > architectures and low enough that you see the hardware. > > You don't see the hardware with any of the other languages you listed. I look at it slightly differently as the person who opened this particular can of worms. I'm not saying that the world should be fixed in stone; for example that there should never be another language because we already have one. I have trouble imagining how the features of C could be added to Fortran, Lisp, or Cobol in a reasonably compatible manner. And I have no issue with C not being an extension of an existing language even though it uses some of the features of other languages; to me C was the first non-clunky programming language. While I find C++ ugly, at least it uses C syntax where possible making it a reasonable transition for programmers. Going back to the original *roff discussion, I would have preferred to see a ".2D" request for *roff that added two-dimensional formatting. Guess what I'm saying is that I'm against change for the sake of change; I'm not against innovation. From lm at mcvoy.com Sun Jan 2 12:12:56 2022 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 1 Jan 2022 18:12:56 -0800 Subject: [TUHS] roff(7) [ and other related stuff ] In-Reply-To: References: <20211231234039.GU31637@mcvoy.com> <202201012000.201K0Fd31610896@darkstar.fourwinds.com> <20220102001244.GF10078@mcvoy.com> <20220102012033.GB7055@mcvoy.com> Message-ID: <20220102021256.GD7055@mcvoy.com> On Sat, Jan 01, 2022 at 08:47:11PM -0500, Steve Nickolas wrote: > >If you think any of those other languages remotely approach the elegance > >of C, I just don't know what to say. > > This. > > I think it blends terseness, cleanness, simplicity and ease of use in just > the right quantities in a way no language before or since has really been > able to muster. Its only real weakness to me is that it isn't very good at > string handling (the reason I sometimes kitbash stuff in BASIC still). Function pointer decls drive me nuts. I agree with the string stuff, any scripting language handles that for you behind the scenes. C could add a String type that did all of that. We did that by hand in BitKeeper and it worked great, it is completely doable. All of the warts aside, you could take C and extend it to do a bunch of useful stuff and still have it be C. We tried with little-lang.org that is very C like but has almost all of the scripting goodness that tcl has exposed in a C like way. Check out the switch statement. Check out regexp. It's just part of the language, it is not function calls. Very pleasant and easy to use. little as a programming language is pretty dead, but as a proof of concept, it should be very much alive. If I had more money, cough, Rob, Google does, I'd fund a dialect of C that had all the C goodness and mixed in the right amount of scripting goodness. I'd come out of retirement to work on that. And I say that as this guy: http://mcvoy.com/lm/boat who is going out on the ocean tomorrow for crab. I love my retirement, I fish all the time, 60+ times per year, I'm really not interested in going back to work. But if someone threw a bunch of money at a team of people who wanted to make C as fun as Perl (or Python, I get it, Perl isn't cool any more but I loved the usefulness), I'd like to be Rob and Ken for that project, this is a giant overreach but I think I could bring taste to that project. If that ever happened, I think a lot of people on this list and elsewhere would like the result. From cowan at ccil.org Sun Jan 2 13:04:36 2022 From: cowan at ccil.org (John Cowan) Date: Sat, 1 Jan 2022 22:04:36 -0500 Subject: [TUHS] roff(7) [ and other related stuff ] In-Reply-To: <20220102012033.GB7055@mcvoy.com> References: <20211231234039.GU31637@mcvoy.com> <202201012000.201K0Fd31610896@darkstar.fourwinds.com> <20220102001244.GF10078@mcvoy.com> <20220102012033.GB7055@mcvoy.com> Message-ID: On Sat, Jan 1, 2022 at 8:20 PM Larry McVoy wrote: > I'm almost speechless. My progression was Basic, Pascal, C (and later > Fortran, Lisp, no Cobol, I did an Ada Compiler so Ada I guess). Then > on to awk, perl, tcl, I tried to like C++ but couldn't, tried to like > Rust, Go, D, and couldn't. > > If you think any of those other languages remotely approach the elegance > of C, I just don't know what to say. > Elegance? C? I think not. Lisp, _that's_ elegant. C is beautiful, you look at the code and you can see what the hardware > will be doing but it isn't assembler. Not really. You see what the hardware would be doing if it were a PDP-11. That's not the same thing at all. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sun Jan 2 13:30:05 2022 From: imp at bsdimp.com (Warner Losh) Date: Sat, 1 Jan 2022 20:30:05 -0700 Subject: [TUHS] roff(7) [ and other related stuff ] In-Reply-To: References: <20211231234039.GU31637@mcvoy.com> <202201012000.201K0Fd31610896@darkstar.fourwinds.com> <20220102001244.GF10078@mcvoy.com> <20220102012033.GB7055@mcvoy.com> Message-ID: On Sat, Jan 1, 2022, 8:05 PM John Cowan wrote: > > > On Sat, Jan 1, 2022 at 8:20 PM Larry McVoy wrote: > > >> I'm almost speechless. My progression was Basic, Pascal, C (and later >> Fortran, Lisp, no Cobol, I did an Ada Compiler so Ada I guess). Then >> on to awk, perl, tcl, I tried to like C++ but couldn't, tried to like >> Rust, Go, D, and couldn't. >> >> If you think any of those other languages remotely approach the elegance >> of C, I just don't know what to say. >> > > Elegance? C? I think not. Lisp, _that's_ elegant. > LISP is all about the syntax. It was completely opaque until that moment when prefix notation clicked and it was all clear... C is beautiful, you look at the code and you can see what the hardware >> will be doing but it isn't assembler. > > > Not really. You see what the hardware would be doing if it were a PDP-11. > That's not the same thing at all. > Read the CHERI papers to find out that C is just doing approximately what you want / think is going on... unless you've been burned by UB that you thought you knew... At least compilers are getting stricter about flagging it, much to the annoyance of anybody with a code base more than a couple years old... Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Sun Jan 2 13:56:54 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Sat, 01 Jan 2022 19:56:54 -0800 Subject: [TUHS] roff(7) [ and other related stuff ] In-Reply-To: References: <20211231234039.GU31637@mcvoy.com> <202201012000.201K0Fd31610896@darkstar.fourwinds.com> <20220102001244.GF10078@mcvoy.com> <20220102012033.GB7055@mcvoy.com> Message-ID: <202201020356.2023usVo1623501@darkstar.fourwinds.com> I'm hoping that this doesn't devolved into another language preference war. What I really wanted to discuss was the nature of adding value and maybe nail down what's meant by value. The roffians versus the texans was just a good excuse. One example to me is that while it has it's own thing, perl packages are available via dnf/apt so one doesn't have to add extra steps to keep a system up to date. Things like pear and npm are negative value to me; they're an extra step. Maybe the mentality is that someone else maintains the system and they just maintain their little corner. My classic example is make. Works pretty well, was missing a few things that Sun and Gnu added later. The negative value stuff is [a-z]make, ninja, meson and all that. Does about the same stuff but in an incompatible way. From jnc at mercury.lcs.mit.edu Sun Jan 2 14:02:17 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 1 Jan 2022 23:02:17 -0500 (EST) Subject: [TUHS] roff(7) [ and other related stuff ] Message-ID: <20220102040217.CE36D18C08E@mercury.lcs.mit.edu> > From: John Cowan > Why use C syntax? What was wrong with Fortran, Lisp, or Cobol syntax, > extended to do what you wanted? Why do all hammers look basically the same? Because there's an 'ideal hammer', and over time hammer design has asymtoted toward that 'ideal hammer' design. One can't just keep improving the design indefinitely - diminishing returns set in. So I suspect there is, to some degree, a Platonic 'ideal syntax' for a 'classic block-structured' programming language, and to me, C came pretty close to it. I except LISP from that assessment, because LISP is built around a fundamentally different model of how computations/algorithms are organized, and C and LISP aren't directly comparable. But that realization points to a deeper bug with the 'Platonic ideal language' concept above, which is that languages are fundamentally, albeit at a very deep conceptual level, tied to the basic concept of the computing hardware they are to run on. C/COBOL/FORTRAN/etc are all for von Neumann-like (in a broad sense) computing engines - a single thread of computation, which happens sequentially. But we've pushed that paradigm about as far as it can go, we're into diminishing returns territory on that one. The future, starting with the hardware, will be very different - and will need quite different languages. (Go, from what little I know of it, is a baby step in this direction - it is intended to make it easy to use multiple simultaneous loci of execution, making use of the mutiple cores that are common now.) I suspect we'll be shifting to radically different paradigms, 50 years from now - massively parallel computing meshes (think Connection Machines on steroids - or the human brain), and those will use fundamentally different computing paradigms, and programming languages for them, which in turn will need very different syntax. Noel From douglas.mcilroy at dartmouth.edu Sun Jan 2 14:10:49 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sat, 1 Jan 2022 23:10:49 -0500 Subject: [TUHS] roff(7) [ and other related stuff ] Message-ID: > Lisp, _that's_ elegant. The machine shines through Lisp even more brightly than it does through C. Lisp attains incredible power from a tiny base: car, cdr, cons, cond, T, F, null, lambda, def, exuding elegance that survives even in a raging sea of parentheses. For Lisp-friendly applications nowadays, I prefer Haskell, which is much further away from the machine. Haskell code approaches--and sometimes surpasses--the cleanliness of good mathematical notation. For string processing, I remember Snobol 3 with great fondness. But for everyday work with arrays and numbers, C is the workhorse. Still, I wish that C would evaluate comma expressions in parallel rather than in series, as in (a,b) = (b,a). Doug From meillo at marmaro.de Sun Jan 2 20:46:33 2022 From: meillo at marmaro.de (markus schnalke) Date: Sun, 02 Jan 2022 11:46:33 +0100 Subject: [TUHS] roff(7) [ and other related stuff ] In-Reply-To: <20220102040217.CE36D18C08E@mercury.lcs.mit.edu> References: <20220102040217.CE36D18C08E@mercury.lcs.mit.edu> Message-ID: <1n3yNl-7Hu-00@marmaro.de> Hoi. [2022-01-01 23:02] jnc at mercury.lcs.mit.edu (Noel Chiappa) > > > From: John Cowan > > > Why use C syntax? What was wrong with Fortran, Lisp, or Cobol syntax, > > extended to do what you wanted? > > Why do all hammers look basically the same? Because there's an 'ideal > hammer', and over time hammer design has asymtoted toward that 'ideal hammer' > design. Hammers don't look so much the same, except that each has a stick and a head. Seems this example is a too simple one. Saws for instance look quite differently, even within western culture, but even more between western and japanese culture! > So I suspect there is, to some degree, a Platonic 'ideal syntax' for a > 'classic block-structured' programming language, and to me, C came pretty > close to it. I suspect that this assumption is limited to our programming culture. We can hardly think outside of it. That's for the same reason, Europeans did not create saws in Japanese style -- they simply solved the same problems in a different way. Thus I'd rather call it one of many possible good syntaxes for a classic block-structured programming language ... and within our culture about the best one. But as well, in such views we obviously like to ignore the very suboptimal `switch' (good for compilers; bad for programmers) and the not so clean optional braces for single-statement blocks. C's syntax is by no means as perfect, as we like to see it, but nonetheless, it is very good. (And I like it a lot myself.) Btw: With the rest of your message, I agree. Good that we're not stuck with one syntax (and thus with one programming model) forever. ;-) meillo From crossd at gmail.com Mon Jan 3 23:35:24 2022 From: crossd at gmail.com (Dan Cross) Date: Mon, 3 Jan 2022 08:35:24 -0500 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <20211230034512.B9B3718C08E@mercury.lcs.mit.edu> <97f563fa-5a17-424b-acc6-07cf127f496d@localhost> Message-ID: On Fri, Dec 31, 2021 at 7:09 PM Theodore Ts'o wrote: > On Fri, Dec 31, 2021 at 01:17:18PM -0500, Dan Cross wrote: > > On Fri, Dec 31, 2021, 10:54 AM Adam Thornton wrote: > > > Slightly older, but also slightly more fundamental to the system, you need > > > look no farther than Solaris's `/bin/sh` for an illustrated example of the > > > pros and cons of maintaining backwards compatibility. [snip] > > > > Sun is not the exemplar here: the move from SunOS 4's BSD userland to > > Solaris 2's SVR4 broke tons of things. They didn't seem to mind that their > > customers had to pay the cost of adaptation. > > I'm sure that there were people at Sun who *did* care. Oh I think we know from first-hand accounts that there were _people_ there who cared. When I wrote "they" earlier I was referring to the corporation (since those are people now, you know!) which clearly didn't; or at least made a decision that indicated that they thought the cost was worth it. > The story I > had heard was that it was a decision made at the C-suite level, and > was a quid-pro-quo where to get that sweet, sweet, cash from AT&T so > Sun could stay afloat, they had to switch over to System V. I wouldn't kick AT&T's $100 million out of the house for running System V. > (No > matter that Solaris 2 was a major step *backwards* in terms of > performance and stability compared to Sun OS....) That it was, at least initially. It's actually pretty good now, but it took a _long_ time to get there, and the forced incompatibilities caused a lot of pain in the process, which was my original thesis. Even now, though, I find some things gratuitously different than other versions of Unix (network administration, for example). Managing NFS is still something of a mystery to me. > > The Linux example is also a bit strange. The move from e.g. `ifconfig` and > > `netstat to `ip` and `ss` required lots of local retooling (I suppose some > > distros retain the older tools or let you install them as an option. I > > suppose one could always install `bash` on Solaris as a shell lingua > > franca, as well). Not to mention systemd. The point is, breaking changes > > are introduced all the time. > > Are there distros who are no longer supplying ifconfig/netstat/route, > at least as an optional package? That's surprising if so. Are there _distros_ that don't supply those things? Probably; I really have no idea. Are there mainstream distros that do not? I doubt it. However, they have to be installed, which is an additional step that has to at least be accounted for. At scale, that's a pain: I imagine that if, say, Google wanted to move to `ip` in lieu of `ifconfig` et al in prod, it would be a multiyear process, including sunsetting the older tools. Just identifying every use of `ifconfig` in a shell script somewhere would be a pretty major undertaking. > All of the kernel interfaces to allow the old-style net-tools packages > to work, as well as the BSD-style ioctls/setsockopt, etc., are still > around, and fully supported. At least on my systems, I still install > net-tools because my finger macros are still used to using ifconfig, > netstat, and friends. By virtue of the existence of that additional step, however, there is an incompatibility with the "older" way of doing things. By no longer being the default, it is (in perhaps a minor way) a breaking change. > The reason why ip and ss were added was because there was a > significant amount of new functionality that was added to the Linux > networking stack (especially relating to routing and address aliasing) > that couldn't be expressed using the older C programming interfaces as > well as the ifconfig/route shell commands. Surely the programmatic interfaces are separate from their realization in a tool? I can understand the rigidity of some `ioctl` based interface that's a pain to work around; I find it harder to believe that plugging some other interface into `ifconfig` in a relatively graceful way is untractible. Surely, in the limit, one could extend ifconfig with a new verb as the first positional argument that expands to the argument set of `ip`: `ifconfig ip address ...` etc. Maybe that was considered and rejected by the maintainers. > There were two north star > principles about the new networking interfaces: > > 1) The old interfaces were always supposed to continue to work, and if > you didn't need the new functionality, there was no reason to use the > newer interfaces. > > 2) The new interfaces were *supposed* to be a strict superset of the > old interfaces. > > If in fact ip and ss don't support AX.25, or other "exotic address > families" --- that's a bug, and should be reported as such. This is an aside, but I'd suggest taking the opposite approach: rip AX.25 out. It has serious bugs (including, apparently, leaking kernel memory into transmitted packets?!) that have gone unfixed for years. My AX.25 machine panics on reboot if there are active netrom connections, and netrom packet state isn't cleaned up properly. The maintainers seem to be out to lunch and are unresponsive on linux-hams. Personally, I'd prefer to see a FUSE-like mechanism for implementing things like AX.25 in user-space: that would make it much easier to fix things like that. On plan9, I would implement AX.25 as a userspace program that exported a small filesystem and bind-mount it onto /net. On Unix, a similar thing could be done with Unix-domain sockets and daemons muxing the radio, but it wouldn't integrate nicely with the existing tools. That's a problem with doing everything in a tightly coupled, monolithic way. > That > being said, if you don't need the fancy new features, there's no > reason to switch away from ifconfig. The whole *point* of the first > principle was that we didn't want to force users to do a forced Python > 2.7 -> Python 3 style "long march" migration. Well, you kind of have. It's a small thing to install another package, sure, but still something that must be done if you want the old tools. - Dan C. From tytso at mit.edu Tue Jan 4 06:23:54 2022 From: tytso at mit.edu (Theodore Ts'o) Date: Mon, 3 Jan 2022 15:23:54 -0500 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <97f563fa-5a17-424b-acc6-07cf127f496d@localhost> Message-ID: On Mon, Jan 03, 2022 at 08:35:24AM -0500, Dan Cross wrote: > > (No > > matter that Solaris 2 was a major step *backwards* in terms of > > performance and stability compared to Sun OS....) > > That it was, at least initially. It's actually pretty good now, but it > took a _long_ time to get there, and the forced incompatibilities > caused a lot of pain in the process, which was my original thesis. > Even now, though, I find some things gratuitously different than other > versions of Unix (network administration, for example). Managing NFS > is still something of a mystery to me. Yeah, to be fair, by the time Solaris 2.3 or 2.4 came around, it was mostly up to par. (Or maybe it was because Moore's law meant that we didn't care any more. :-) > Are there _distros_ that don't supply those things? Probably; I really > have no idea. Are there mainstream distros that do not? I doubt it. > However, they have to be installed, which is an additional step that > has to at least be accounted for. At scale, that's a pain: I imagine > that if, say, Google wanted to move to `ip` in lieu of `ifconfig` et > al in prod, it would be a multiyear process, including sunsetting the > older tools. Just identifying every use of `ifconfig` in a shell > script somewhere would be a pretty major undertaking. Sure, but there's no *point* to sunset the old tools. The git tree for net-tools is still being actively developed (the last commit was dated December 12, 2021). And the kernel interfaces are not going to be disappear, because of the prime directive: Thou Shalt Not Break Userspace. > > The reason why ip and ss were added was because there was a > > significant amount of new functionality that was added to the Linux > > networking stack (especially relating to routing and address aliasing) > > that couldn't be expressed using the older C programming interfaces as > > well as the ifconfig/route shell commands. > > Surely the programmatic interfaces are separate from their realization > in a tool? I can understand the rigidity of some `ioctl` based > interface that's a pain to work around; I find it harder to believe > that plugging some other interface into `ifconfig` in a relatively > graceful way is untractible. Surely, in the limit, one could extend > ifconfig with a new verb as the first positional argument that expands > to the argument set of `ip`: `ifconfig ip address ...` etc. Maybe that > was considered and rejected by the maintainers. Well, take a look at the ip-route man page. The BSD route command assumes fundamentally there is a single routing table that you can update. In Linux, there are multiple routing tables --- to support NAT, VRF (virtual routing and forwarding), etc. I suspect the other consideration was that all of this extra functionality and complexity were done by folks who wanted the Linux networking stack to essentially have pretty much all of the functionality of a Cisco Router. So it made sense to create a new user interface interface that was inspired by the Cisco IOS configuration language. Now, if you weren't trying to do something ala a router in the default-free zone, and were just simply doing what most leaf nodes on the internet (99.99999% of the hosts), there really is no reason to need to use the ip/ss interface. For that matter, you probably don't need to use ifconfig/route --- just let the DHCP client server of your choice take care of setting up the network, and you're done. > Well, you kind of have. It's a small thing to install another package, > sure, but still something that must be done if you want the old tools. That's a distro-level choice. And for most users, their networking is automatically brought up using NetworkManager, or some such, so they probably don't care. And it's not like installing a package is that painful. I don't see users of say, mysql complaining that they have to install that package should they want to use it. I'm old school, and since I generally tend to install BIND, that will drag in net-tools as dependency, so all my systems have ifconfig installed. But I'm not going to have a lot of sympathy for someone who thinks that "sudo apt-get install net-tools" is massive inconvenience. - Ted From imp at bsdimp.com Tue Jan 4 06:45:12 2022 From: imp at bsdimp.com (Warner Losh) Date: Mon, 3 Jan 2022 13:45:12 -0700 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <97f563fa-5a17-424b-acc6-07cf127f496d@localhost> Message-ID: On Mon, Jan 3, 2022 at 1:24 PM Theodore Ts'o wrote: > On Mon, Jan 03, 2022 at 08:35:24AM -0500, Dan Cross wrote: > > > (No > > > matter that Solaris 2 was a major step *backwards* in terms of > > > performance and stability compared to Sun OS....) > > > > That it was, at least initially. It's actually pretty good now, but it > > took a _long_ time to get there, and the forced incompatibilities > > caused a lot of pain in the process, which was my original thesis. > > Even now, though, I find some things gratuitously different than other > > versions of Unix (network administration, for example). Managing NFS > > is still something of a mystery to me. > > Yeah, to be fair, by the time Solaris 2.3 or 2.4 came around, it was > mostly up to par. (Or maybe it was because Moore's law meant that we > didn't care any more. :-) > For my corner of the world, 2.3 was stable enough to run in production. 2.4 was fast enough :) > > Are there _distros_ that don't supply those things? Probably; I really > > have no idea. Are there mainstream distros that do not? I doubt it. > > However, they have to be installed, which is an additional step that > > has to at least be accounted for. At scale, that's a pain: I imagine > > that if, say, Google wanted to move to `ip` in lieu of `ifconfig` et > > al in prod, it would be a multiyear process, including sunsetting the > > older tools. Just identifying every use of `ifconfig` in a shell > > script somewhere would be a pretty major undertaking. > > Sure, but there's no *point* to sunset the old tools. The git tree > for net-tools is still being actively developed (the last commit was > dated December 12, 2021). And the kernel interfaces are not going to > be disappear, because of the prime directive: Thou Shalt Not Break > Userspace. > > > > The reason why ip and ss were added was because there was a > > > significant amount of new functionality that was added to the Linux > > > networking stack (especially relating to routing and address aliasing) > > > that couldn't be expressed using the older C programming interfaces as > > > well as the ifconfig/route shell commands. > > > > Surely the programmatic interfaces are separate from their realization > > in a tool? I can understand the rigidity of some `ioctl` based > > interface that's a pain to work around; I find it harder to believe > > that plugging some other interface into `ifconfig` in a relatively > > graceful way is untractible. Surely, in the limit, one could extend > > ifconfig with a new verb as the first positional argument that expands > > to the argument set of `ip`: `ifconfig ip address ...` etc. Maybe that > > was considered and rejected by the maintainers. > > Well, take a look at the ip-route man page. The BSD route command > assumes fundamentally there is a single routing table that you can > update. In Linux, there are multiple routing tables --- to support > NAT, VRF (virtual routing and forwarding), etc. > The 4.4BSD route command does this. The various BSDs now support multiple routing tables through an evolved interface... > I suspect the other consideration was that all of this extra > functionality and complexity were done by folks who wanted the Linux > networking stack to essentially have pretty much all of the > functionality of a Cisco Router. So it made sense to create a new > user interface interface that was inspired by the Cisco IOS > configuration language. Now, if you weren't trying to do something > ala a router in the default-free zone, and were just simply doing what > most leaf nodes on the internet (99.99999% of the hosts), there really > is no reason to need to use the ip/ss interface. For that matter, you > probably don't need to use ifconfig/route --- just let the DHCP client > server of your choice take care of setting up the network, and you're > done. > True. The vast majority of installs today are just "use DHCP and be happy" though somebody has to run the dhcp server :) > > Well, you kind of have. It's a small thing to install another package, > > sure, but still something that must be done if you want the old tools. > > That's a distro-level choice. And for most users, their networking is > automatically brought up using NetworkManager, or some such, so they > probably don't care. And it's not like installing a package is that > painful. I don't see users of say, mysql complaining that they have > to install that package should they want to use it. > > I'm old school, and since I generally tend to install BIND, that will > drag in net-tools as dependency, so all my systems have ifconfig > installed. But I'm not going to have a lot of sympathy for someone > who thinks that "sudo apt-get install net-tools" is massive > inconvenience. > For machines you manage, sure. It's easy. Try it with the linksys router you can log into and it starts to get much harder... though with those loading new firmware isn't super hard. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Tue Jan 4 07:15:08 2022 From: crossd at gmail.com (Dan Cross) Date: Mon, 3 Jan 2022 16:15:08 -0500 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <97f563fa-5a17-424b-acc6-07cf127f496d@localhost> Message-ID: On Mon, Jan 3, 2022 at 3:23 PM Theodore Ts'o wrote: > On Mon, Jan 03, 2022 at 08:35:24AM -0500, Dan Cross wrote: > > That it was, at least initially. It's actually pretty good now, but it > > took a _long_ time to get there, and the forced incompatibilities > > caused a lot of pain in the process, which was my original thesis. > > [snip] > > Yeah, to be fair, by the time Solaris 2.3 or 2.4 came around, it was > mostly up to par. (Or maybe it was because Moore's law meant that we > didn't care any more. :-) I have some vague memories that we had to do something like double the RAM in our SPARCstations to make Solaris 2 feel comfortable. At the time, that was a pretty serious outlay in an academic department. 2.5.1 felt like the first version that was _truly_ usable. > > Are there _distros_ that don't supply those things? Probably; I really > > have no idea. Are there mainstream distros that do not? I doubt it. > > However, they have to be installed, which is an additional step that > > has to at least be accounted for. At scale, that's a pain: I imagine > > that if, say, Google wanted to move to `ip` in lieu of `ifconfig` et > > al in prod, it would be a multiyear process, including sunsetting the > > older tools. Just identifying every use of `ifconfig` in a shell > > script somewhere would be a pretty major undertaking. > > Sure, but there's no *point* to sunset the old tools. The git tree > for net-tools is still being actively developed (the last commit was > dated December 12, 2021). And the kernel interfaces are not going to > be disappear, because of the prime directive: Thou Shalt Not Break > Userspace. Within a single organization, two semi-compatible ways of doing things seems suboptimal for a number of reasons. > > [snip] > > Surely the programmatic interfaces are separate from their realization > > in a tool? I can understand the rigidity of some `ioctl` based > > interface that's a pain to work around; I find it harder to believe > > that plugging some other interface into `ifconfig` in a relatively > > graceful way is untractible. Surely, in the limit, one could extend > > ifconfig with a new verb as the first positional argument that expands > > to the argument set of `ip`: `ifconfig ip address ...` etc. Maybe that > > was considered and rejected by the maintainers. Jon Steinhart reminds me that he said largely the same thing last week; credit where it's due! > Well, take a look at the ip-route man page. The BSD route command > assumes fundamentally there is a single routing table that you can > update. In Linux, there are multiple routing tables --- to support > NAT, VRF (virtual routing and forwarding), etc. As Warner mentioned, the BSDs also support multiple routing tables, with the `route` command. To bring it back to ham radio, I not-so-humbly offer up https://wiki.ampr.org/wiki/Setting_up_a_gateway_on_OpenBSD as a rather pedestrian example of their utility. > I suspect the other consideration was that all of this extra > functionality and complexity were done by folks who wanted the Linux > networking stack to essentially have pretty much all of the > functionality of a Cisco Router. So it made sense to create a new > user interface interface that was inspired by the Cisco IOS > configuration language. I would suggest that the latter does not necessarily follow from the former. But if people want to evolve things, that's ok: after all, the genesis of this discussion is that we know how to handle breaking changes. > Now, if you weren't trying to do something > ala a router in the default-free zone, and were just simply doing what > most leaf nodes on the internet (99.99999% of the hosts), there really > is no reason to need to use the ip/ss interface. Except that's what a lot of documentation tells you to do. :-) Really, `ip` and `ss` are basically fine. The overriding point is that when one says on the one hand, "we cannot change the way `..` works because people's scripts might break..." but we fundamentally change the default network commands on the other, the former seems to be self-invalidating. > For that matter, you > probably don't need to use ifconfig/route --- just let the DHCP client > server of your choice take care of setting up the network, and you're > done. That'll work on a laptop or on my home network (where I set up the DHCP server). In a large-scale datacenter environment, maybe not so much. > > Well, you kind of have. It's a small thing to install another package, > > sure, but still something that must be done if you want the old tools. > > That's a distro-level choice. And for most users, their networking is > automatically brought up using NetworkManager, or some such, so they > probably don't care. And it's not like installing a package is that > painful. I don't see users of say, mysql complaining that they have > to install that package should they want to use it. I would suggest that the number of users who want to run MySQL is much smaller than the number who want to have a functioning network. But you're right; it's not that hard to adapt. That was kind of the point; there have been cases where Linux users have adapted to one degree or another. > I'm old school, and since I generally tend to install BIND, that will > drag in net-tools as dependency, so all my systems have ifconfig > installed. But I'm not going to have a lot of sympathy for someone > who thinks that "sudo apt-get install net-tools" is massive > inconvenience. Since shells often have custom (and occasionally inconsistent) handling of `..`, I'm not sure I'd have a lot of sympathy for that one either. Why one and not the other? I suspect Clem got it right: it has to do with the perceived value of the change. The networking stuff had sufficient value that it was worth the cost incurred (which is low, but non-zero). Perhaps changing `..` just wouldn't have the benefit. I argue that it's hard to know those things beforehand. The `apt install net-tools` thing is a red-herring, though: that's explicitly why I mentioned Google prod. What works on a single system doesn't necessarily scale to O(10^6) machines supporting O(10^7) separately running instances of O(10^4) services in O(10) globally distributed datacenters, that's just a single organization. - Dan C. From tytso at mit.edu Tue Jan 4 08:26:33 2022 From: tytso at mit.edu (Theodore Ts'o) Date: Mon, 3 Jan 2022 17:26:33 -0500 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <97f563fa-5a17-424b-acc6-07cf127f496d@localhost> Message-ID: On Mon, Jan 03, 2022 at 04:15:08PM -0500, Dan Cross wrote: > > For that matter, you > > probably don't need to use ifconfig/route --- just let the DHCP client > > server of your choice take care of setting up the network, and you're > > done. > > That'll work on a laptop or on my home network (where I set up the > DHCP server). In a large-scale datacenter environment, maybe not so > much. I've seen a number of large-scale data center environments that use DHCP; and those that don't in Linux-land generally just edit a config file in /etc/network/interfaces or /etc/network/interfaces.d --- and then the init scripts would just use "ifup -a" which would bring up the network either using DHCP or the hard-coded values in /etc/network/interaces. No need to have sysadmins manually typing "route add ..." commands except in extreme debugging situations. > > That's a distro-level choice. And for most users, their networking is > > automatically brought up using NetworkManager, or some such, so they > > probably don't care. And it's not like installing a package is that > > painful. I don't see users of say, mysql complaining that they have > > to install that package should they want to use it. > > I would suggest that the number of users who want to run MySQL is much > smaller than the number who want to have a functioning network. But > you're right; it's not that hard to adapt. That was kind of the point; > there have been cases where Linux users have adapted to one degree or > another. I actually suspect the number of users who want to run MySQL is actually larger than the number of users who need to manually configure a network using /sbin/ifconfig and /sbin/route.... :-) > The `apt install net-tools` thing is a red-herring, though: that's > explicitly why I mentioned Google prod. What works on a single system > doesn't necessarily scale to O(10^6) machines supporting O(10^7) > separately running instances of O(10^4) services in O(10) globally > distributed datacenters, that's just a single organization. Google prod's easy --- Google maintains its own minimal prod distribution where a small set of packages (less than a few dozen) that were originally forked from Debian a number of years ago. So it's trivial for us, because net-tools is installed by default and there is **no** engineering upside for us to switch to ip/ss --- so we haven't. :-) Similarly, we're still using a *very* old version of bash (having stayed back across multiple major releases) because it's easier to stick with an old version of bash and keep up with the security fixes, than it would be to audit a gazillion shell scripts and shell script fragments for the various potential and subtle backwards-incomaptible changes that bash has made over the past decade. Larry has told a similar story about the advantages of using a "dead" language like Tcl for Bitkeeper, since he didn't have to deal with gratuitous version skew problems caused by backwards incomaptible changes in Perl or Python. But if you manage your own userspace, including affording to do your own FEDRAMP-compliant security updates, you can just choose *not* to upgrade to newer versions of bash or network utilities. Who *says* you have to use bash 5.1? Or switch to ip/ss? On the other hand, we did spend untold engineering hours migrating from Python 2.7 to 3.x (and *wow* was that painful) because in that case, that was considered less work and more secure than independently supporting Python 2.7 ad infinitum (also, we have fewer Python programs than we have shell script fragments in config files like Makefiles as well actual shell scripts). So the decision about whether to follow breaking interfaces/language changes is an engineering decision that's made on a case by case basis, as it should be for all organizations. In the case of bash and net-tools, one decision was made. In the case of Python, a difference decision was made --- although a lot of people really weren't happy that the Python developers didn't appreciate the cost of breaking backwards compatibility (or rather, they decided that they didn't care and prioritized their own convenience over that of their users). This is why I'm a big supporter of Linus's, "Thou Shalt Not Break Userspace" rule; backwards compatibility at the lowest levels is important! I'd draw that line higher than some people, but hey, if you don't like the instability of Python, you can do what Bitkeeper did and base your extension language/scripts on something like Tcl instead. - Ted P.S. If you want to see the horror of trying to support a Python program that has to be able to run on a wide variety of Linux distros, running different versions of Python (from RHEL 6 and Python 2.3 up to the newest bleeding edge Python 3.x), take a look at the Google's gcloud program. Alas, unlike the Google prod environment, we can't dictate what distro our Cloud customers might choose to use. The gcloud command (part of the Google Cloud SDK) has to play all sorts of portability games, and people need to continually test across a wide range of Python versions and Linux distros to provide assurance that it continues to correctly as new features are added and bugs are fixed. I *completely* understand why Larry chose to implement Bitkeeper extensions in Tcl, since it avoids this problem. Bt yeah, it's why I wouldn't want to change dot-dot, since having seen the pain the Python developers inflected on me, I wouldn't want to inflict it on others... From phil at ultimate.com Tue Jan 4 08:57:00 2022 From: phil at ultimate.com (Phil Budne) Date: Mon, 03 Jan 2022 17:57:00 -0500 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <97f563fa-5a17-424b-acc6-07cf127f496d@localhost> Message-ID: <202201032257.203Mv0UM000747@ultimate.com> Theodore Ts'o wrote: > Well, take a look at the ip-route man page. The BSD route command > assumes fundamentally there is a single routing table that you can > update. In Linux, there are multiple routing tables --- to support > NAT, VRF (virtual routing and forwarding), etc. Non-exhaustive research (didn't look at NetBSD, OpenBSD or Dragonfly): Looks like the FreeBSD route got the -fib argument in November 2012, the setfib command (execute a command with an alternate routing table) appeared in 2008. Looks like the ip command appeared in Linux 2.2 (end of 1999), so it doesn't look like there was a lead to follow. Now don't get me wrong, I have no lost love for the BSD route command, it almost always takes me at least four tries; one for a syntax error, one to add a bad route, and another to remove the bad route! BUT, as someone who has been using BSD based systems since 4.2, it's hard not to feel like GNU and Linux folks have evidenced a pride that they're better than Un*x (I remember at a Usenix (Boston in '94?) overhearing a VA Linux employee boasting how their goal was to beat out commercial Un*x vendors. Too bad they weren't aiming at the Windows desktop...) and missed the boat on "Unix philosophy", but I'm well aware that what I remember with fondness as simpler times was contemporaneously viewed by others as "beginning to smell really bad". Finally, I'm new here, but I can't help feeling that both complaining and boasting about Linux aren't within the realm of "Unix Heritage"? But discussion of lessons learned by Bell Research post 7th Edition, are of greater interest to me. Keeping ".." working is certainly a major pain in the a**, and I can understand wanting to throw it in the ditch, but I came from the DEC 36-bit world (TOPS-10/20 and ITS) which didn't present a single, uniform file name space (full paths started with "DEVICE:", and different device handlers could treat the following name space differently), and I've never been convinced that the Unix single namespace hasn't brought just as much pain as benefit. ITS in particular had device handlers that were dynamically loaded into another process and commuinicated thru a special device handler handler (the JOB device) that translated system calls to messages. Listing the directory of a spooled print device would show the queue, and there was also network file access to other ITS machines). The DEC systems had system and user defined "logical devices", which I do remember fondly as causing less pain than symlinks. ITS may have had both symlink and logical device-like things... From crossd at gmail.com Tue Jan 4 09:10:00 2022 From: crossd at gmail.com (Dan Cross) Date: Mon, 3 Jan 2022 18:10:00 -0500 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <97f563fa-5a17-424b-acc6-07cf127f496d@localhost> Message-ID: On Mon, Jan 3, 2022 at 5:26 PM Theodore Ts'o wrote: > On Mon, Jan 03, 2022 at 04:15:08PM -0500, Dan Cross wrote: > > > For that matter, you > > > probably don't need to use ifconfig/route --- just let the DHCP client > > > server of your choice take care of setting up the network, and you're > > > done. > > > > That'll work on a laptop or on my home network (where I set up the > > DHCP server). In a large-scale datacenter environment, maybe not so > > much. > > I've seen a number of large-scale data center environments that use > DHCP; and those that don't in Linux-land generally just edit a config > file in /etc/network/interfaces or /etc/network/interfaces.d --- and > then the init scripts would just use "ifup -a" which would bring up > the network either using DHCP or the hard-coded values in > /etc/network/interaces. No need to have sysadmins manually typing > "route add ..." commands except in extreme debugging situations. So, would you say that those are...supported by a bunch of shell scripts that would have to be changed if those systems migrated to the new tools for whatever reason? :-D > > I would suggest that the number of users who want to run MySQL is much > > smaller than the number who want to have a functioning network. But > > you're right; it's not that hard to adapt. That was kind of the point; > > there have been cases where Linux users have adapted to one degree or > > another. > > I actually suspect the number of users who want to run MySQL is > actually larger than the number of users who need to manually > configure a network using /sbin/ifconfig and /sbin/route.... :-) Touche. > > The `apt install net-tools` thing is a red-herring, though: that's > > explicitly why I mentioned Google prod. What works on a single system > > doesn't necessarily scale to O(10^6) machines supporting O(10^7) > > separately running instances of O(10^4) services in O(10) globally > > distributed datacenters, that's just a single organization. > > Google prod's easy --- Google maintains its own minimal prod > distribution where a small set of packages (less than a few dozen) > that were originally forked from Debian a number of years ago. So > it's trivial for us, because net-tools is installed by default and > there is **no** engineering upside for us to switch to ip/ss --- so we > haven't. :-) Recall that I was saying that the effort if Google decided, for whatever reason, that it wanted to switch, would be multiyear. Giving into the inertia of staying where Google is today is the easy part. As you yourself acknowledge, the engineering effort required to switch to the newfangled tools is non-zero. However, this creates a conundrum; if Google wanted (again for whatever reason) to avail itself of the new functionality provided by the new tools, it now has a choice: either roll the new tools out, or extend the existing tools to provide the required functionality. This is not something I would describe as "easy." Sure, rolling the new commands out to machines would be relatively straight-forward (though I've worked on those systems and getting things into the production image was non-trivial politically, if not technically), but transitioning to use them not so much. This sort of begs the question: why not default to shipping the old tools (route, netstat, ifconfig) and let people install the _new_ tools if they want their Linux machine to behave like a cisco router? Google made this choice and sure: as you say, this is a distro-level question. But it sure seems like the broad consensus around the major distros is the opposite. > Similarly, we're still using a *very* old version of bash (having > stayed back across multiple major releases) because it's easier to > stick with an old version of bash and keep up with the security fixes, > than it would be to audit a gazillion shell scripts and shell script > fragments for the various potential and subtle backwards-incomaptible > changes that bash has made over the past decade. This is an aside, but one of my continual gripes about Google was that it took monumental efforts to deprecate anything (lookin' at you, disk device names), often because no one had paid attention to trying to maintain portability between different systems, let alone different versions of the same system. But bear in mind that even Google's monorepo doesn't exist in a hermetic bubble: third party code and upstream dependencies for externally imposed requirements; in some cases, that forces upgrades of libraries, toolchains, and yes, even userspace tools. Incidentally, this was one of the big arguments for getting the Rust toolchain pulled into google3: even though Google wasn't authoring first-party Rust code for prod, we _knew_ there were third-party dependencies that would force us to have a toolchain for the same reason we have a FORTRAN toolchain. That I was one of the people who benefited from a Rust toolchain in g3 wasn't entirely coincidental, as our team finally forced language tools' hands there. > Larry has told a similar story about the advantages of using a "dead" > language like Tcl for Bitkeeper, since he didn't have to deal with > gratuitous version skew problems caused by backwards incomaptible > changes in Perl or Python. But if you manage your own userspace, > including affording to do your own FEDRAMP-compliant security updates, > you can just choose *not* to upgrade to newer versions of bash or > network utilities. Who *says* you have to use bash 5.1? Or switch to > ip/ss? The interesting thing about this is that it ignores the unseen costs of staying with the older versions of things. The kernel was a great example, actually, for reasons you know well (though perhaps not super appropriate for discussion here). This creates a negative feedback loop: we can't upgrade anything because something will break, so we stay with the old stuff until forced to move. > On the other hand, we did spend untold engineering hours migrating > from Python 2.7 to 3.x (and *wow* was that painful) because in that > case, that was considered less work and more secure than independently > supporting Python 2.7 ad infinitum (also, we have fewer Python > programs than we have shell script fragments in config files like > Makefiles as well actual shell scripts). ...and also because third-party dependencies started dropping support for Python 2. I would love to see language stats for the claim that there's more shell scripts than Python over there. I'd be mildly though perhaps not completely surprised if that were true. I suppose if "shell script fragments" includes `a && b` then I could see it. I'm not cleared for that anymore though. But I also remember when /usr/bin/python2.4 was really python2.7. :-( > So the decision about whether to follow breaking interfaces/language > changes is an engineering decision that's made on a case by case > basis, as it should be for all organizations. In the case of bash and > net-tools, one decision was made. Inertia is a hell of a drug. > In the case of Python, a difference > decision was made --- although a lot of people really weren't happy > that the Python developers didn't appreciate the cost of breaking > backwards compatibility (or rather, they decided that they didn't care > and prioritized their own convenience over that of their users). > > This is why I'm a big supporter of Linus's, "Thou Shalt Not Break > Userspace" rule; backwards compatibility at the lowest levels is > important! I'd draw that line higher than some people, but hey, if > you don't like the instability of Python, you can do what Bitkeeper > did and base your extension language/scripts on something like Tcl > instead. I guess what I'm saying is that "thou shalt not break userspace" is a bit of a misnomer; perhaps it should be rephrased as, "thou shalt not change the kernel in such a way that userspace code no longer works." He is, after all, referring specifically to the kernel interface, right? But just as sufficiently advanced technology is said to be indistinguishable from magic, a missing command like `ifconfig` _might_ be indistinguishable from an incompatible system interface as far as a user is concerned. > P.S. If you want to see the horror of trying to support a Python > program that has to be able to run on a wide variety of Linux distros, > running different versions of Python (from RHEL 6 and Python 2.3 up to > the newest bleeding edge Python 3.x), take a look at the Google's > gcloud program. Alas, unlike the Google prod environment, we can't > dictate what distro our Cloud customers might choose to use. > > The gcloud command (part of the Google Cloud SDK) has to play all > sorts of portability games, and people need to continually test across > a wide range of Python versions and Linux distros to provide assurance > that it continues to correctly as new features are added and bugs are > fixed. I *completely* understand why Larry chose to implement > Bitkeeper extensions in Tcl, since it avoids this problem. No thank you! I'm good. :-) > Bt yeah, it's why I wouldn't want to change dot-dot, since having seen > the pain the Python developers inflected on me, I wouldn't want to > inflict it on others... Hmm. I wonder if I have any 386 a.out binaries floating around. :-) - Dan C. From merlyn at geeks.org Tue Jan 4 09:21:51 2022 From: merlyn at geeks.org (Doug McIntyre) Date: Mon, 3 Jan 2022 17:21:51 -0600 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <97f563fa-5a17-424b-acc6-07cf127f496d@localhost> Message-ID: On Mon, Jan 03, 2022 at 04:15:08PM -0500, Dan Cross wrote: > On Mon, Jan 3, 2022 at 3:23 PM Theodore Ts'o wrote: > > Yeah, to be fair, by the time Solaris 2.3 or 2.4 came around, it was > > mostly up to par. (Or maybe it was because Moore's law meant that we > > didn't care any more. :-) > > I have some vague memories that we had to do something like double the > RAM in our SPARCstations to make Solaris 2 feel comfortable. At the > time, that was a pretty serious outlay in an academic department. > 2.5.1 felt like the first version that was _truly_ usable. I'd agree, 2.4 was pretty slow and chunky, 2.5 was alright, but 2.5.1 was quite usable and stable. Also by this time, the hardware was going in directions that SunOS wouldn't keep up with. From athornton at gmail.com Tue Jan 4 09:37:55 2022 From: athornton at gmail.com (Adam Thornton) Date: Mon, 3 Jan 2022 16:37:55 -0700 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <97f563fa-5a17-424b-acc6-07cf127f496d@localhost> Message-ID: 2.5.1 was the first Solaris that didn't often make me scream that I wanted SunOS 4.1 back. Adam On Mon, Jan 3, 2022 at 4:32 PM Doug McIntyre wrote: > On Mon, Jan 03, 2022 at 04:15:08PM -0500, Dan Cross wrote: > > On Mon, Jan 3, 2022 at 3:23 PM Theodore Ts'o wrote: > > > > Yeah, to be fair, by the time Solaris 2.3 or 2.4 came around, it was > > > mostly up to par. (Or maybe it was because Moore's law meant that we > > > didn't care any more. :-) > > > > I have some vague memories that we had to do something like double the > > RAM in our SPARCstations to make Solaris 2 feel comfortable. At the > > time, that was a pretty serious outlay in an academic department. > > 2.5.1 felt like the first version that was _truly_ usable. > > I'd agree, 2.4 was pretty slow and chunky, 2.5 was alright, but 2.5.1 was > quite usable and stable. > Also by this time, the hardware was going in directions that SunOS > wouldn't keep up with. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Tue Jan 4 09:44:11 2022 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 3 Jan 2022 15:44:11 -0800 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <97f563fa-5a17-424b-acc6-07cf127f496d@localhost> Message-ID: <20220103234411.GA19828@mcvoy.com> On Mon, Jan 03, 2022 at 05:21:51PM -0600, Doug McIntyre wrote: > On Mon, Jan 03, 2022 at 04:15:08PM -0500, Dan Cross wrote: > > On Mon, Jan 3, 2022 at 3:23 PM Theodore Ts'o wrote: > > > > Yeah, to be fair, by the time Solaris 2.3 or 2.4 came around, it was > > > mostly up to par. (Or maybe it was because Moore's law meant that we > > > didn't care any more. :-) > > > > I have some vague memories that we had to do something like double the > > RAM in our SPARCstations to make Solaris 2 feel comfortable. At the > > time, that was a pretty serious outlay in an academic department. > > 2.5.1 felt like the first version that was _truly_ usable. > > I'd agree, 2.4 was pretty slow and chunky, 2.5 was alright, but 2.5.1 was quite usable and stable. > Also by this time, the hardware was going in directions that SunOS wouldn't keep up with. Yeah, Doug is right, SunOS was pretty simple, it didn't really take advantage of SMP, Greg Limes tried to thread it but it was too big a job for one guy. That's not to say that SunOS couldn't have evolved into SMP, I'm 100% sure it could have. It just didn't. It's a shame. From imp at bsdimp.com Tue Jan 4 09:56:17 2022 From: imp at bsdimp.com (Warner Losh) Date: Mon, 3 Jan 2022 16:56:17 -0700 Subject: [TUHS] moving directories in svr2 In-Reply-To: <20220103234411.GA19828@mcvoy.com> References: <97f563fa-5a17-424b-acc6-07cf127f496d@localhost> <20220103234411.GA19828@mcvoy.com> Message-ID: On Mon, Jan 3, 2022, 4:44 PM Larry McVoy wrote: > On Mon, Jan 03, 2022 at 05:21:51PM -0600, Doug McIntyre wrote: > > On Mon, Jan 03, 2022 at 04:15:08PM -0500, Dan Cross wrote: > > > On Mon, Jan 3, 2022 at 3:23 PM Theodore Ts'o wrote: > > > > > > Yeah, to be fair, by the time Solaris 2.3 or 2.4 came around, it was > > > > mostly up to par. (Or maybe it was because Moore's law meant that we > > > > didn't care any more. :-) > > > > > > I have some vague memories that we had to do something like double the > > > RAM in our SPARCstations to make Solaris 2 feel comfortable. At the > > > time, that was a pretty serious outlay in an academic department. > > > 2.5.1 felt like the first version that was _truly_ usable. > > > > I'd agree, 2.4 was pretty slow and chunky, 2.5 was alright, but 2.5.1 > was quite usable and stable. > > Also by this time, the hardware was going in directions that SunOS > wouldn't keep up with. > > Yeah, Doug is right, SunOS was pretty simple, it didn't really take > advantage > of SMP, Greg Limes tried to thread it but it was too big a job for one guy. > > That's not to say that SunOS couldn't have evolved into SMP, I'm 100% > sure it could have. It just didn't. It's a shame. > Solbourne had it's OS/MP which did do SMP with a subsystem locking strategy. This worked reasonably well for the time. So it was quite possible. Solbourne died, though because it couldn't get Solaris sources soon enough to do a port that mattered... Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Tue Jan 4 09:56:00 2022 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Tue, 4 Jan 2022 10:56:00 +1100 Subject: [TUHS] SMP: BSD vs System V (once was: moving directories in svr2) In-Reply-To: <20220103234411.GA19828@mcvoy.com> References: <97f563fa-5a17-424b-acc6-07cf127f496d@localhost> <20220103234411.GA19828@mcvoy.com> Message-ID: <20220103235600.GA68567@eureka.lemis.com> On Monday, 3 January 2022 at 15:44:11 -0800, Larry McVoy wrote: > On Mon, Jan 03, 2022 at 05:21:51PM -0600, Doug McIntyre wrote: >> On Mon, Jan 03, 2022 at 04:15:08PM -0500, Dan Cross wrote: >> I'd agree, 2.4 was pretty slow and chunky, 2.5 was alright, but 2.5.1 was quite usable and stable. >> Also by this time, the hardware was going in directions that SunOS wouldn't keep up with. > > Yeah, Doug is right, SunOS was pretty simple, it didn't really take advantage > of SMP, Greg Limes tried to thread it but it was too big a job for one guy. > > That's not to say that SunOS couldn't have evolved into SMP, I'm 100% > sure it could have. It just didn't. It's a shame. An interesting question. I had always thought that SMP was (one of?) the technical reasons why Sun moved from a BSD to a System V base. Since then, of course, we've done lots of work on SMP support for at least FreeBSD. Does anybody have an overview of how good the support is compared to modern Solaris? Is there any intrinsic reason why one should be better than the other? 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.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From will.senn at gmail.com Tue Jan 4 10:42:09 2022 From: will.senn at gmail.com (Will Senn) Date: Mon, 3 Jan 2022 18:42:09 -0600 Subject: [TUHS] New Version of Installing and Using Research Unix Version 7 in the SimH PDP-11/45 and 11/70 Emulators Available Message-ID: <6c53100f-11d0-e0f9-da67-a5daeec2c87e@gmail.com> All, I've completed a new version of my "Installing and Using Research Unix Version 7 in the SimH PDP-11/45 and 11/70 Emulators" tutorial/document (wow, that's a mouthful). I'm calling it Version 2.0 - It is a completely reorganized, updated, and edited version of the document. The blog post announcement is on the blog: https://decuser.blogspot.com/ and the pdf is on google drive: https://drive.google.com/file/d/1gDBxULlpLwezH-1RO_3ou_W7trElgSgT/view?usp=sharing The new doc covers building a working v7 instance from tape files that will run on the SimH emulator. First, the reader is led through the restoration of a pristine v7 instance from tape to disk. Next, the reader is led through adding a regular user, making the system multi-user. Then, the reader is shown how to make the system multi-session cable allowing multiple simultaneous sessions. Finally, the system is put to use with hello world, DMR style, and the learn system is enabled. It also includes a hyperlinked table of contents. My hope is that the new version will be more useful than the prior version, as well as more accurate. I really appreciate the input and feedback y'all have given me over the intervening years. Regards, Will From tytso at mit.edu Tue Jan 4 12:28:02 2022 From: tytso at mit.edu (Theodore Ts'o) Date: Mon, 3 Jan 2022 21:28:02 -0500 Subject: [TUHS] moving directories in svr2 In-Reply-To: <20220103234411.GA19828@mcvoy.com> References: <97f563fa-5a17-424b-acc6-07cf127f496d@localhost> <20220103234411.GA19828@mcvoy.com> Message-ID: On Mon, Jan 03, 2022 at 03:44:11PM -0800, Larry McVoy wrote: > On Mon, Jan 03, 2022 at 05:21:51PM -0600, Doug McIntyre wrote: > > I'd agree, 2.4 was pretty slow and chunky, 2.5 was alright, but 2.5.1 was quite usable and stable. > > Also by this time, the hardware was going in directions that SunOS wouldn't keep up with. > > Yeah, Doug is right, SunOS was pretty simple, it didn't really take advantage > of SMP, Greg Limes tried to thread it but it was too big a job for one guy. > > That's not to say that SunOS couldn't have evolved into SMP, I'm 100% > sure it could have. It just didn't. It's a shame. I would have thought that if we consider the amount of engineering resources to that was invested to get from Solaris 2.0 to 2.5.1, if that had instead been invested into making SunOS a scalable SMP OS, that it would have been doable. Do you think that's fair? Of course, that's assuming that Sun could have stayed afloat without that injection of cash from AT&T.... - Ted From lm at mcvoy.com Tue Jan 4 12:42:04 2022 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 3 Jan 2022 18:42:04 -0800 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <97f563fa-5a17-424b-acc6-07cf127f496d@localhost> <20220103234411.GA19828@mcvoy.com> Message-ID: <20220104024204.GB22599@mcvoy.com> On Mon, Jan 03, 2022 at 09:28:02PM -0500, Theodore Ts'o wrote: > On Mon, Jan 03, 2022 at 03:44:11PM -0800, Larry McVoy wrote: > > On Mon, Jan 03, 2022 at 05:21:51PM -0600, Doug McIntyre wrote: > > > I'd agree, 2.4 was pretty slow and chunky, 2.5 was alright, but 2.5.1 was quite usable and stable. > > > Also by this time, the hardware was going in directions that SunOS wouldn't keep up with. > > > > Yeah, Doug is right, SunOS was pretty simple, it didn't really take advantage > > of SMP, Greg Limes tried to thread it but it was too big a job for one guy. > > > > That's not to say that SunOS couldn't have evolved into SMP, I'm 100% > > sure it could have. It just didn't. It's a shame. > > I would have thought that if we consider the amount of engineering > resources to that was invested to get from Solaris 2.0 to 2.5.1, if > that had instead been invested into making SunOS a scalable SMP OS, > that it would have been doable. Do you think that's fair? Yes, absolutely. I worked in the kernel group in building 5. That was pretty much the best group of people I have been a part of. That team could have done anything, SMP was not a problem for them. They for sure could have made SunOS scale. The people who didn't leave were the people who made Solaris work. That said, I have to give credit to the group of people I built who did BitKeeper. I'd stand them up against the Sun kernel team and they would win. Smaller group, stellar bunch of people. I'm happy that I got to be part of both teams. From gingell at computer.org Tue Jan 4 19:28:20 2022 From: gingell at computer.org (Rob Gingell) Date: Tue, 4 Jan 2022 01:28:20 -0800 Subject: [TUHS] Mythical Distress Sale (was Re: moving directories in svr2) In-Reply-To: References: <97f563fa-5a17-424b-acc6-07cf127f496d@localhost> <20220103234411.GA19828@mcvoy.com> Message-ID: <8039e060-3315-5f14-3671-00d3f93e90f9@computer.org> On 1/3/2022 6:28 PM, Theodore Ts'o wrote: > Of course, that's assuming that Sun could have stayed afloat without > that injection of cash from AT&T.... What causes you to assert that Sun was at risk of not staying afloat? Sun went from $0/yr to over $1B/yr in revenue between 1982 and 1988, the prototype for what people now call "unicorns". Between 1985 and 1989 Sun grew at a compounded rate of 145% a year, and according to Forbes was the fastest growing company in the US in those years. Doesn't sound like a company foundering to me, certainly not in 1987 and 1988. Didn't sound like it to AT&T either, who wanted in on the action and so bought a bunch of Sun stock on terms very favorable to Sun (and financially speaking of benefit to both companies when AT&T divested some years later). The injection of capital was certainly useful to Sun, not because of distress or failure, but because it was bursting at the seams from all the growth. Sun was going to get that capital without AT&T by going to the market anyway, that it was able to do so on more favorable terms with an already established partner was literally an example of the rich getting richer. The partnership to inject SunOS technologies, do SVR4, harmonize the various UNIX flavors had already been committed and launched some months before the investment occurred and wasn't contingent upon it. They're not unrelated of course, the investment occurred in the context of the already committed partnership. And if you examine the announced expectations of that partnership it included some strong dependencies on Sun products and technologies by AT&T in both the near and long term. The gestalt of the investment was that it was a consequence of "well, if we're already doing all this, then..." Certainly the later transitions in Sun's products had lots of issues. But lessons aren't gained from "well, they meant well, but, poor sods, they were barely staying alive" especially when the premise isn't even remotely accurate. It's a much more interesting examination to consider: "they had agency, they made choices, the context was , why that and not this, what was the alternative, etc." Since we can have the facts, why not premise the discussions on those? From stu at remphrey.net Wed Jan 5 00:49:39 2022 From: stu at remphrey.net (Stuart Remphrey) Date: Tue, 4 Jan 2022 22:49:39 +0800 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <97f563fa-5a17-424b-acc6-07cf127f496d@localhost> Message-ID: Oh, that reminded me of SunOS 4.0 that introduced streams. Broke So I used to pine for 3.5! Agree re 2.4/2.5.1 having gotten an O/S back to being solid and very usable -- IIRC we had customers query whether they had good distribution media, because the "patch" directory was empty. No patches were introduced during beta. On Tue, 4 Jan 2022, 07:38 Adam Thornton, wrote: > 2.5.1 was the first Solaris that didn't often make me scream that I wanted > SunOS 4.1 back. > > Adam > > > On Mon, Jan 3, 2022 at 4:32 PM Doug McIntyre wrote: > >> On Mon, Jan 03, 2022 at 04:15:08PM -0500, Dan Cross wrote: >> > On Mon, Jan 3, 2022 at 3:23 PM Theodore Ts'o wrote: >> >> > > Yeah, to be fair, by the time Solaris 2.3 or 2.4 came around, it was >> > > mostly up to par. (Or maybe it was because Moore's law meant that we >> > > didn't care any more. :-) >> > >> > I have some vague memories that we had to do something like double the >> > RAM in our SPARCstations to make Solaris 2 feel comfortable. At the >> > time, that was a pretty serious outlay in an academic department. >> > 2.5.1 felt like the first version that was _truly_ usable. >> >> I'd agree, 2.4 was pretty slow and chunky, 2.5 was alright, but 2.5.1 was >> quite usable and stable. >> Also by this time, the hardware was going in directions that SunOS >> wouldn't keep up with. >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Wed Jan 5 01:17:35 2022 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 4 Jan 2022 07:17:35 -0800 Subject: [TUHS] Mythical Distress Sale (was Re: moving directories in svr2) In-Reply-To: <8039e060-3315-5f14-3671-00d3f93e90f9@computer.org> References: <20220103234411.GA19828@mcvoy.com> <8039e060-3315-5f14-3671-00d3f93e90f9@computer.org> Message-ID: <20220104151735.GD22599@mcvoy.com> Rob, you've painted this picture before and it just doesn't match up at all with what I saw. I was there. Ken Okin paid me for 6 months to try and convince the execs to not go to SVR4. If it was all sweetness and light, why did he do that? You make it sound like it was a nice friendly deal. It was $200M of Sun stock at 35% over market rate. Who does that just to be friends? You say you could have gone to market and gotten that, well, sure, but not at 35% over market. SunOS was winning all the deals, as you point out, Sun was growing like crazy. I did lots and lots of customer presentations and not once did I hear "oh, when are you guys going to standardize on System V?" Quite the opposite in fact. I was doing a talk at the Moscone center on the first Sun cluster that I had built, Scott refused to let me ship it with SunOS, so I was being a good soldier and talking up Solaris. Over and over and over I was asked why we were forcing people to use an obviously worse OS and I finally lost it and said "I know, I have everything working in SunOS but they won't let me ship it." I was on tape. Okin listened to the tape and said "get every copy of those tapes and destroy them". Not exactly the friendly everyone agreeing picture you paint. Not remotely like that. Rob, I lived through that time. One of my close friends, John Pope, did the bring up. He felt alienated from all the other kernel people because we all loved SunOS and we hated Solaris, it made zero sense to go that far backward. And look what it got you. Sun is gone. If you could have gone to market and gotten the money, you would have. Sun was killing it, everyone wanted a Sun over every other workstation, in the SunOS days, every open source thing just built on Suns. Everyone else had to twiddle the makefiles and the source. Your story that people wanted a standard just doesn't hold up when you were the standard. It also doesn't hold up when every single customer I talked to (and I talked to them at least twice a month in formal presentations and frequently more like twice a week, the sales people loved me) never asked for SVR4. Not once did that come up. And when SVR4 was being pushed on them, 100% of them pushed back and wanted SunOS. On Tue, Jan 04, 2022 at 01:28:20AM -0800, Rob Gingell wrote: > On 1/3/2022 6:28 PM, Theodore Ts'o wrote: > >Of course, that's assuming that Sun could have stayed afloat without > >that injection of cash from AT&T.... > > What causes you to assert that Sun was at risk of not staying afloat? > > Sun went from $0/yr to over $1B/yr in revenue between 1982 and 1988, the > prototype for what people now call "unicorns". > > Between 1985 and 1989 Sun grew at a compounded rate of 145% a year, and > according to Forbes was the fastest growing company in the US in those > years. > > Doesn't sound like a company foundering to me, certainly not in 1987 and > 1988. Didn't sound like it to AT&T either, who wanted in on the action and > so bought a bunch of Sun stock on terms very favorable to Sun (and > financially speaking of benefit to both companies when AT&T divested some > years later). > > The injection of capital was certainly useful to Sun, not because of > distress or failure, but because it was bursting at the seams from all the > growth. Sun was going to get that capital without AT&T by going to the > market anyway, that it was able to do so on more favorable terms with an > already established partner was literally an example of the rich getting > richer. The partnership to inject SunOS technologies, do SVR4, harmonize the > various UNIX flavors had already been committed and launched some months > before the investment occurred and wasn't contingent upon it. > > They're not unrelated of course, the investment occurred in the context of > the already committed partnership. And if you examine the announced > expectations of that partnership it included some strong dependencies on Sun > products and technologies by AT&T in both the near and long term. The > gestalt of the investment was that it was a consequence of "well, if we're > already doing all this, then..." > > Certainly the later transitions in Sun's products had lots of issues. But > lessons aren't gained from "well, they meant well, but, poor sods, they were > barely staying alive" especially when the premise isn't even remotely > accurate. > > It's a much more interesting examination to consider: "they had agency, they > made choices, the context was , why that and not this, what > was the alternative, etc." Since we can have the facts, why not premise the > discussions on those? -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From arnold at skeeve.com Wed Jan 5 01:26:23 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 04 Jan 2022 08:26:23 -0700 Subject: [TUHS] Mythical Distress Sale (was Re: moving directories in svr2) In-Reply-To: <20220104151735.GD22599@mcvoy.com> References: <20220103234411.GA19828@mcvoy.com> <8039e060-3315-5f14-3671-00d3f93e90f9@computer.org> <20220104151735.GD22599@mcvoy.com> Message-ID: <202201041526.204FQNEb028767@freefriends.org> OK, serious question. Why did Sun "sell out" to AT&T if they could have raised capital in the market? Did the executive team just not care about what moving to System V would mean? Or did they not understand it? How desperate were they? And why were they so desparate? Were there other alternatives they could have pursued? I too lived through those times, from the outside, and it was indeed a shocker when they moved from SunOS to Solaris. Thanks, Arnold Larry McVoy wrote: > Rob, you've painted this picture before and it just doesn't match up > at all with what I saw. I was there. Ken Okin paid me for 6 months to > try and convince the execs to not go to SVR4. If it was all sweetness > and light, why did he do that? > > You make it sound like it was a nice friendly deal. It was $200M of > Sun stock at 35% over market rate. Who does that just to be friends? > You say you could have gone to market and gotten that, well, sure, > but not at 35% over market. > > SunOS was winning all the deals, as you point out, Sun was growing > like crazy. I did lots and lots of customer presentations and not once > did I hear "oh, when are you guys going to standardize on System V?" > > Quite the opposite in fact. I was doing a talk at the Moscone center > on the first Sun cluster that I had built, Scott refused to let me ship > it with SunOS, so I was being a good soldier and talking up Solaris. > Over and over and over I was asked why we were forcing people to use > an obviously worse OS and I finally lost it and said "I know, I have > everything working in SunOS but they won't let me ship it." > > I was on tape. Okin listened to the tape and said "get every copy of > those tapes and destroy them". Not exactly the friendly everyone > agreeing picture you paint. Not remotely like that. > > Rob, I lived through that time. One of my close friends, John Pope, > did the bring up. He felt alienated from all the other kernel people > because we all loved SunOS and we hated Solaris, it made zero sense to > go that far backward. And look what it got you. Sun is gone. > > If you could have gone to market and gotten the money, you would > have. Sun was killing it, everyone wanted a Sun over every other > workstation, in the SunOS days, every open source thing just built > on Suns. Everyone else had to twiddle the makefiles and the source. > Your story that people wanted a standard just doesn't hold up when > you were the standard. It also doesn't hold up when every single > customer I talked to (and I talked to them at least twice a month > in formal presentations and frequently more like twice a week, > the sales people loved me) never asked for SVR4. Not once did that > come up. And when SVR4 was being pushed on them, 100% of them > pushed back and wanted SunOS. > > On Tue, Jan 04, 2022 at 01:28:20AM -0800, Rob Gingell wrote: > > On 1/3/2022 6:28 PM, Theodore Ts'o wrote: > > >Of course, that's assuming that Sun could have stayed afloat without > > >that injection of cash from AT&T.... > > > > What causes you to assert that Sun was at risk of not staying afloat? > > > > Sun went from $0/yr to over $1B/yr in revenue between 1982 and 1988, the > > prototype for what people now call "unicorns". > > > > Between 1985 and 1989 Sun grew at a compounded rate of 145% a year, and > > according to Forbes was the fastest growing company in the US in those > > years. > > > > Doesn't sound like a company foundering to me, certainly not in 1987 and > > 1988. Didn't sound like it to AT&T either, who wanted in on the action and > > so bought a bunch of Sun stock on terms very favorable to Sun (and > > financially speaking of benefit to both companies when AT&T divested some > > years later). > > > > The injection of capital was certainly useful to Sun, not because of > > distress or failure, but because it was bursting at the seams from all the > > growth. Sun was going to get that capital without AT&T by going to the > > market anyway, that it was able to do so on more favorable terms with an > > already established partner was literally an example of the rich getting > > richer. The partnership to inject SunOS technologies, do SVR4, harmonize the > > various UNIX flavors had already been committed and launched some months > > before the investment occurred and wasn't contingent upon it. > > > > They're not unrelated of course, the investment occurred in the context of > > the already committed partnership. And if you examine the announced > > expectations of that partnership it included some strong dependencies on Sun > > products and technologies by AT&T in both the near and long term. The > > gestalt of the investment was that it was a consequence of "well, if we're > > already doing all this, then..." > > > > Certainly the later transitions in Sun's products had lots of issues. But > > lessons aren't gained from "well, they meant well, but, poor sods, they were > > barely staying alive" especially when the premise isn't even remotely > > accurate. > > > > It's a much more interesting examination to consider: "they had agency, they > > made choices, the context was , why that and not this, what > > was the alternative, etc." Since we can have the facts, why not premise the > > discussions on those? > > -- > --- > Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From lm at mcvoy.com Wed Jan 5 01:40:14 2022 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 4 Jan 2022 07:40:14 -0800 Subject: [TUHS] Mythical Distress Sale (was Re: moving directories in svr2) In-Reply-To: <202201041526.204FQNEb028767@freefriends.org> References: <20220103234411.GA19828@mcvoy.com> <8039e060-3315-5f14-3671-00d3f93e90f9@computer.org> <20220104151735.GD22599@mcvoy.com> <202201041526.204FQNEb028767@freefriends.org> Message-ID: <20220104154014.GE22599@mcvoy.com> I think the execs did not fully appreciate what they had in SunOS. I know that I, and many other engineers, put in a boat load of extra effort to polish SunOS. My first job at Sun was to do POSIX conformance (which was one hell of an education). Nobody asked me to do this, but I made lint libraries for SVr3 (or 4, whatever was current), BSD, POSIX, etc. My thinking was that you could develop on SunOS but target whatever you wanted. I had to threaten to quit to get them included in the release, Rob didn't want them in there because they added something like 40KB to the install. He was probably right, I doubt anyone ever used them, but my thinking was to help the customers. That thinking was rampant amongst the engineers, you could show up at 7pm and building 5 had piles of engineers polishing SunOS. Guy Harris quit and went to Auspex, they licensed SunOS. He'd come pound on the door after dinner, we'd let him in, get him logged in and he fixed bugs. I can still here him saying "Holy smokes, they still haven't fixed this?" and then he'd check in a fix. I don't think the execs had a clue as to how much the engineers were willing to make SunOS better. We did it because everyone wanted a Sun, it was the best of the best at the time. On Tue, Jan 04, 2022 at 08:26:23AM -0700, arnold at skeeve.com wrote: > OK, serious question. Why did Sun "sell out" to AT&T if they could > have raised capital in the market? Did the executive team just not > care about what moving to System V would mean? Or did they not understand > it? > > How desperate were they? And why were they so desparate? Were there > other alternatives they could have pursued? > > I too lived through those times, from the outside, and it was indeed > a shocker when they moved from SunOS to Solaris. > > Thanks, > > Arnold > > Larry McVoy wrote: > > > Rob, you've painted this picture before and it just doesn't match up > > at all with what I saw. I was there. Ken Okin paid me for 6 months to > > try and convince the execs to not go to SVR4. If it was all sweetness > > and light, why did he do that? > > > > You make it sound like it was a nice friendly deal. It was $200M of > > Sun stock at 35% over market rate. Who does that just to be friends? > > You say you could have gone to market and gotten that, well, sure, > > but not at 35% over market. > > > > SunOS was winning all the deals, as you point out, Sun was growing > > like crazy. I did lots and lots of customer presentations and not once > > did I hear "oh, when are you guys going to standardize on System V?" > > > > Quite the opposite in fact. I was doing a talk at the Moscone center > > on the first Sun cluster that I had built, Scott refused to let me ship > > it with SunOS, so I was being a good soldier and talking up Solaris. > > Over and over and over I was asked why we were forcing people to use > > an obviously worse OS and I finally lost it and said "I know, I have > > everything working in SunOS but they won't let me ship it." > > > > I was on tape. Okin listened to the tape and said "get every copy of > > those tapes and destroy them". Not exactly the friendly everyone > > agreeing picture you paint. Not remotely like that. > > > > Rob, I lived through that time. One of my close friends, John Pope, > > did the bring up. He felt alienated from all the other kernel people > > because we all loved SunOS and we hated Solaris, it made zero sense to > > go that far backward. And look what it got you. Sun is gone. > > > > If you could have gone to market and gotten the money, you would > > have. Sun was killing it, everyone wanted a Sun over every other > > workstation, in the SunOS days, every open source thing just built > > on Suns. Everyone else had to twiddle the makefiles and the source. > > Your story that people wanted a standard just doesn't hold up when > > you were the standard. It also doesn't hold up when every single > > customer I talked to (and I talked to them at least twice a month > > in formal presentations and frequently more like twice a week, > > the sales people loved me) never asked for SVR4. Not once did that > > come up. And when SVR4 was being pushed on them, 100% of them > > pushed back and wanted SunOS. > > > > On Tue, Jan 04, 2022 at 01:28:20AM -0800, Rob Gingell wrote: > > > On 1/3/2022 6:28 PM, Theodore Ts'o wrote: > > > >Of course, that's assuming that Sun could have stayed afloat without > > > >that injection of cash from AT&T.... > > > > > > What causes you to assert that Sun was at risk of not staying afloat? > > > > > > Sun went from $0/yr to over $1B/yr in revenue between 1982 and 1988, the > > > prototype for what people now call "unicorns". > > > > > > Between 1985 and 1989 Sun grew at a compounded rate of 145% a year, and > > > according to Forbes was the fastest growing company in the US in those > > > years. > > > > > > Doesn't sound like a company foundering to me, certainly not in 1987 and > > > 1988. Didn't sound like it to AT&T either, who wanted in on the action and > > > so bought a bunch of Sun stock on terms very favorable to Sun (and > > > financially speaking of benefit to both companies when AT&T divested some > > > years later). > > > > > > The injection of capital was certainly useful to Sun, not because of > > > distress or failure, but because it was bursting at the seams from all the > > > growth. Sun was going to get that capital without AT&T by going to the > > > market anyway, that it was able to do so on more favorable terms with an > > > already established partner was literally an example of the rich getting > > > richer. The partnership to inject SunOS technologies, do SVR4, harmonize the > > > various UNIX flavors had already been committed and launched some months > > > before the investment occurred and wasn't contingent upon it. > > > > > > They're not unrelated of course, the investment occurred in the context of > > > the already committed partnership. And if you examine the announced > > > expectations of that partnership it included some strong dependencies on Sun > > > products and technologies by AT&T in both the near and long term. The > > > gestalt of the investment was that it was a consequence of "well, if we're > > > already doing all this, then..." > > > > > > Certainly the later transitions in Sun's products had lots of issues. But > > > lessons aren't gained from "well, they meant well, but, poor sods, they were > > > barely staying alive" especially when the premise isn't even remotely > > > accurate. > > > > > > It's a much more interesting examination to consider: "they had agency, they > > > made choices, the context was , why that and not this, what > > > was the alternative, etc." Since we can have the facts, why not premise the > > > discussions on those? > > > > -- > > --- > > Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From chet.ramey at case.edu Wed Jan 5 01:45:08 2022 From: chet.ramey at case.edu (Chet Ramey) Date: Tue, 4 Jan 2022 10:45:08 -0500 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <97f563fa-5a17-424b-acc6-07cf127f496d@localhost> Message-ID: On 1/3/22 5:26 PM, Theodore Ts'o wrote: > you can just choose *not* to upgrade to newer versions of bash or > network utilities. Who *says* you have to use bash 5.1? Or switch to > ip/ss? It's always a trade-off, isn't it? If you don't use the current version of something, you assume the burden of maintenance. As we've seen, vendors vary as to the attention they give old versions of software (e.g., bash-4.2 still shipping as part of RHEL 7 a decade after bash-4.3 was released). Google can make that choice for itself, I suppose. -- ``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 Wed Jan 5 01:48:19 2022 From: rich.salz at gmail.com (Richard Salz) Date: Tue, 4 Jan 2022 10:48:19 -0500 Subject: [TUHS] Mythical Distress Sale (was Re: moving directories in svr2) In-Reply-To: <20220104154014.GE22599@mcvoy.com> References: <20220103234411.GA19828@mcvoy.com> <8039e060-3315-5f14-3671-00d3f93e90f9@computer.org> <20220104151735.GD22599@mcvoy.com> <202201041526.204FQNEb028767@freefriends.org> <20220104154014.GE22599@mcvoy.com> Message-ID: Executives at tech companies rarely understand "what they have" in my experience. The Son/ATT "merger" terrified the industry, so much so that a bunch of people got together and created the Open Software Foundation. The feeling was that ATT had superior technology, and Sun could build and sell it. Perhaps that first part was wrong, but many felt that way. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfawcus+lists-tuhs at employees.org Wed Jan 5 01:40:17 2022 From: dfawcus+lists-tuhs at employees.org (Derek Fawcus) Date: Tue, 4 Jan 2022 15:40:17 +0000 Subject: [TUHS] VRFs (was Re: moving directories in svr2) In-Reply-To: References: <97f563fa-5a17-424b-acc6-07cf127f496d@localhost> Message-ID: On Mon, Jan 03, 2022 at 03:23:54PM -0500, Theodore Ts'o wrote: > > Well, take a look at the ip-route man page. The BSD route command > assumes fundamentally there is a single routing table that you can > update. In Linux, there are multiple routing tables --- to support > NAT, VRF (virtual routing and forwarding), etc. Well, I never found the multiple-table thing to be that much like VRF stuff which one would find one cisco/juniper/etc, I found it more like a PBR scheme... In terms of doing stuff like VRFs, I generally just configure multiple network namespaces, and ignore the multiple tables. That said, there is now another explicit mechanism for VRFs in Linux, based in part off VLANs, and special interfaces. Maybe it also uses the multiple tables stuff? So is that 2.5 to 3 mechanisms for achieving VRFs, and/or other weird and wonderful networking games? DF From will.senn at gmail.com Wed Jan 5 06:37:25 2022 From: will.senn at gmail.com (Will Senn) Date: Tue, 4 Jan 2022 14:37:25 -0600 Subject: [TUHS] asm helper routines in v7 Message-ID: <10197622-30fe-7553-2f2d-edc9637ff489@gmail.com> So, in v6, it was possible to use the mesg function from the system library with: ed hello.s / hello world using external mesg routine .globl mesg mov sp,r5 jsr r5,mesg; ; .even sys exit as hello.sld -s a.out -l a.out Hello, World! This was because v6 included mesg in the library, in v7, it doesn't look like mesg is included, so doing the same thing as above requires that code to write the message out be included and in addition system call names are not predefined, so exit and write have to be looked up in /usr/include/sys.s, resulting in the v7 equivalent file: ed hello2.s / hello world using internal mesg routine         mov     sp,r5         jsr     r5,mesg; ; .even         sys     1 mesg:         mov     r0,-(sp)         mov     r5,r0         mov     r5,0f 1:         tstb    (r5)+         bne     1b         sub     r5,r0         com     r0         mov     r0,0f+2         mov     $1,r0         sys     0; 9f .data 9:         sys     4; 0:..; .. .text         inc     r5         bic     $1,r5         mov     (sp)+,r0         rts     r5 as hello2.s a.out Hello, World! My questions are: 1. Is mesg or an equivalent available in v7? 2. If not, what was the v7 way of putting strings out? 3. Why aren't the system call names defined? 4. What was the v7 way of naming system calls? Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Wed Jan 5 07:12:08 2022 From: crossd at gmail.com (Dan Cross) Date: Tue, 4 Jan 2022 16:12:08 -0500 Subject: [TUHS] asm helper routines in v7 In-Reply-To: <10197622-30fe-7553-2f2d-edc9637ff489@gmail.com> References: <10197622-30fe-7553-2f2d-edc9637ff489@gmail.com> Message-ID: On Tue, Jan 4, 2022 at 3:38 PM Will Senn wrote: > [snip] > My questions are: > > 1. Is mesg or an equivalent available in v7? Perhaps just call printf? > 2. If not, what was the v7 way of putting strings out? Here's what I did: $ rm -f h h.o $ cat h.s .globl _printf, _exit mov sp, r5 mov $hi,(sp) jsr pc,*$_printf mov $0, (sp) jsr pc,*$_exit hi: $ as -o h.o h.s $ ld -o h h.o -lc $ ./h Hello, World! $ rm h h.o > 3. Why aren't the system call names defined? If I had to hazard a guess, it would have been to de-emphasize the use of assembler for user code, particularly as 7th Edition was starting to be portable beyond the PDP-11. > 4. What was the v7 way of naming system calls? I imagine the canonical way to invoke system calls from assembler was invoking calling functions in the C library and linking against that. - Dan C. From will.senn at gmail.com Wed Jan 5 07:24:18 2022 From: will.senn at gmail.com (Will Senn) Date: Tue, 4 Jan 2022 15:24:18 -0600 Subject: [TUHS] asm helper routines in v7 In-Reply-To: References: <10197622-30fe-7553-2f2d-edc9637ff489@gmail.com> Message-ID: <54ec532a-6603-6b25-fa9f-40aa9d111687@gmail.com> On 1/4/22 3:12 PM, Dan Cross wrote: > On Tue, Jan 4, 2022 at 3:38 PM Will Senn wrote: >> [snip] >> My questions are: >> >> 1. Is mesg or an equivalent available in v7? > Perhaps just call printf? > >> 2. If not, what was the v7 way of putting strings out? > Here's what I did: > > $ rm -f h h.o > $ cat h.s > .globl _printf, _exit > > mov sp, r5 > mov $hi,(sp) > jsr pc,*$_printf > mov $0, (sp) > jsr pc,*$_exit > > hi: > $ as -o h.o h.s > $ ld -o h h.o -lc > $ ./h > Hello, World! > $ rm h h.o > >> 3. Why aren't the system call names defined? > If I had to hazard a guess, it would have been to de-emphasize the use > of assembler for user code, particularly as 7th Edition was starting > to be portable beyond the PDP-11. > >> 4. What was the v7 way of naming system calls? > I imagine the canonical way to invoke system calls from assembler was > invoking calling functions in the C library and linking against that. > > - Dan C. Yep, that worked... you make it look so easy, and your rationales are definitely believable :). Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Wed Jan 5 07:28:37 2022 From: imp at bsdimp.com (Warner Losh) Date: Tue, 4 Jan 2022 14:28:37 -0700 Subject: [TUHS] asm helper routines in v7 In-Reply-To: <54ec532a-6603-6b25-fa9f-40aa9d111687@gmail.com> References: <10197622-30fe-7553-2f2d-edc9637ff489@gmail.com> <54ec532a-6603-6b25-fa9f-40aa9d111687@gmail.com> Message-ID: On Tue, Jan 4, 2022 at 2:24 PM Will Senn wrote: > On 1/4/22 3:12 PM, Dan Cross wrote: > > On Tue, Jan 4, 2022 at 3:38 PM Will Senn wrote: > > [snip] > My questions are: > > 1. Is mesg or an equivalent available in v7? > > Perhaps just call printf? > > > 2. If not, what was the v7 way of putting strings out? > > Here's what I did: > > $ rm -f h h.o > $ cat h.s > .globl _printf, _exit > > mov sp, r5 > mov $hi,(sp) > jsr pc,*$_printf > mov $0, (sp) > jsr pc,*$_exit > > hi: > $ as -o h.o h.s > $ ld -o h h.o -lc > $ ./h > Hello, World! > $ rm h h.o > > > 3. Why aren't the system call names defined? > > If I had to hazard a guess, it would have been to de-emphasize the use > of assembler for user code, particularly as 7th Edition was starting > to be portable beyond the PDP-11. > > > 4. What was the v7 way of naming system calls? > > I imagine the canonical way to invoke system calls from assembler was > invoking calling functions in the C library and linking against that. > > - Dan C. > > Yep, that worked... you make it look so easy, and your rationales are > definitely believable :). > You can use puts too, at least in v7. The system call interface between V6 and V7 changed as well... Some internal AT&T branches (cb unix for one) could run both V6 and V7 binaries. BSD uses the v7 system call interface through 2.10.x. 2.11 moves to a new system call interface as well. There's niggles in these statements, since it isn't quite exactly the same, but for things like this it's ok. V7 also moved to stdio completely. V6 had precursor routines to stdio and mesg() was dropped in that whole process. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Jan 5 07:38:20 2022 From: clemc at ccc.com (Clem Cole) Date: Tue, 4 Jan 2022 16:38:20 -0500 Subject: [TUHS] asm helper routines in v7 In-Reply-To: <10197622-30fe-7553-2f2d-edc9637ff489@gmail.com> References: <10197622-30fe-7553-2f2d-edc9637ff489@gmail.com> Message-ID: On Tue, Jan 4, 2022 at 3:38 PM Will Senn wrote: > 1. Is mesg or an equivalent available in v7? > its not part of the C stdio library and by te > 2. If not, what was the v7 way of putting strings out? > _puts declared as an external > 3. Why aren't the system call names defined? > Ah .. you want the DEC assembler ;-) By the time of V5/V6 assembler is starting to have less importance and by V7, little if anything is left. > 4. What was the v7 way of naming system calls? > _XXX where XXX is the system call declared as a global. -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Wed Jan 5 10:32:16 2022 From: will.senn at gmail.com (Will Senn) Date: Tue, 4 Jan 2022 18:32:16 -0600 Subject: [TUHS] vi on v7 Message-ID: Well, hallelujah, after much travail (I've tried this every Christmas for at least 5 years now), I have succeeded in building vi on v7 from 2bsd. Had to patch the c compiler to enlarge the symbol table, tweak some stuff here and there, but it finally built and installed without any errors, yay. Now, I just want it to do some editing, preferably in visual mode. I can call it as ex or vi: # ex : or # vi : and q will exit, yay, again! I have at least two problems: 1. It's not going "full" screen, even with TERM=vt100 or TERM=ansi set (not that I was surprised, but it'd be nice)... 2. If I type a for append and type something, there's no way to get back to the : prompt (ESC doesn't seem to work). 3. I'd like manpages (figure they might help with the above), but they're on the tape as .u files? I'm hoping this triggers some, oh yeah I remember that, type responses. Thanks, Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Wed Jan 5 11:35:19 2022 From: imp at bsdimp.com (Warner Losh) Date: Tue, 4 Jan 2022 18:35:19 -0700 Subject: [TUHS] vi on v7 In-Reply-To: References: Message-ID: On Tue, Jan 4, 2022 at 5:33 PM Will Senn wrote: > Well, hallelujah, after much travail (I've tried this every Christmas for > at least 5 years now), I have succeeded in building vi on v7 from 2bsd. Had > to patch the c compiler to enlarge the symbol table, tweak some stuff here > and there, but it finally built and installed without any errors, yay. > > Now, I just want it to do some editing, preferably in visual mode. I can > call it as ex or vi: > > # ex > : > > or > > # vi > > : > > and q will exit, yay, again! > > I have at least two problems: > 1. It's not going "full" screen, even with TERM=vt100 or TERM=ansi set > (not that I was surprised, but it'd be nice)... > What does /etc/termcap look like? > 2. If I type a for append and type something, there's no way to get back > to the : prompt (ESC doesn't seem to work). > 3. I'd like manpages (figure they might help with the above), but they're > on the tape as .u files? > > I'm hoping this triggers some, oh yeah I remember that, type responses. > > Thanks, > > Will > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Wed Jan 5 11:36:35 2022 From: imp at bsdimp.com (Warner Losh) Date: Tue, 4 Jan 2022 18:36:35 -0700 Subject: [TUHS] vi on v7 In-Reply-To: References: Message-ID: On Tue, Jan 4, 2022 at 6:35 PM Warner Losh wrote: > > > On Tue, Jan 4, 2022 at 5:33 PM Will Senn wrote: > >> Well, hallelujah, after much travail (I've tried this every Christmas for >> at least 5 years now), I have succeeded in building vi on v7 from 2bsd. Had >> to patch the c compiler to enlarge the symbol table, tweak some stuff here >> and there, but it finally built and installed without any errors, yay. >> >> Now, I just want it to do some editing, preferably in visual mode. I can >> call it as ex or vi: >> >> # ex >> : >> >> or >> >> # vi >> >> : >> >> and q will exit, yay, again! >> >> I have at least two problems: >> 1. It's not going "full" screen, even with TERM=vt100 or TERM=ansi set >> (not that I was surprised, but it'd be nice)... >> > > What does /etc/termcap look like? > Doh! Hit send too fast > 2. If I type a for append and type something, there's no way to get back >> to the : prompt (ESC doesn't seem to work). >> > Sounds like the timeout code for the terminal input isn't working (it's what it uses to tell a ESC from a ESC [ A for example. > 3. I'd like manpages (figure they might help with the above), but they're >> on the tape as .u files? >> > No clue there. Are the .u files nroff by chance? Warner > I'm hoping this triggers some, oh yeah I remember that, type responses. >> >> Thanks, >> >> Will >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Jan 5 11:40:33 2022 From: clemc at ccc.com (Clem Cole) Date: Tue, 4 Jan 2022 20:40:33 -0500 Subject: [TUHS] vi on v7 In-Reply-To: References: Message-ID: Ah. You discovered a feature of vi fir Dialup terminals. When the baud rate is 120cps or less then it will only paint ½ the screen at a time. Reset Getty to use the 960cps interface and magically that will go away On Tue, Jan 4, 2022 at 7:33 PM Will Senn wrote: > Well, hallelujah, after much travail (I've tried this every Christmas for > at least 5 years now), I have succeeded in building vi on v7 from 2bsd. Had > to patch the c compiler to enlarge the symbol table, tweak some stuff here > and there, but it finally built and installed without any errors, yay. > > Now, I just want it to do some editing, preferably in visual mode. I can > call it as ex or vi: > > # ex > : > > or > > # vi > > : > > and q will exit, yay, again! > > I have at least two problems: > 1. It's not going "full" screen, even with TERM=vt100 or TERM=ansi set > (not that I was surprised, but it'd be nice)... > 2. If I type a for append and type something, there's no way to get back > to the : prompt (ESC doesn't seem to work). > 3. I'd like manpages (figure they might help with the above), but they're > on the tape as .u files? > > I'm hoping this triggers some, oh yeah I remember that, type responses. > > Thanks, > > Will > > > > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Thu Jan 6 01:26:50 2022 From: will.senn at gmail.com (Will Senn) Date: Wed, 5 Jan 2022 09:26:50 -0600 Subject: [TUHS] vi on v7 In-Reply-To: References: Message-ID: <102db625-b2a0-935b-7424-a183ae64fb65@gmail.com> On 1/4/22 7:35 PM, Warner Losh wrote: > > 1. It's not going "full" screen, even with TERM=vt100 or TERM=ansi set > (not that I was surprised, but it'd be nice)... > > What does /etc/termcap look like? > All right, I'm getting warmer. I tried changing ttys to various speeds, and stty 9600, per Clem, Then, I looked at termcap, and saw that there weren't any ansi or vt100 entries (duh), so then I tryed vt50 and vt52 modes: vt50: HJ   ~   ~   ~   AAAA       :q vt52: Y7 HJY- ~         ~         ~         ~         ~         ~         ~         ~         ~         ~Y, Y7 :q Here are the termcap entries. I compared with termcap in svr2, which has vt50,vt52, and vt100: v7: vh|vt50h|dec vt50h:\ :bs:cd=\EJ:ce=\EK:cl=\EH\EJ:cm=\EY%+ %+ :co#80:li#12:nd=\EC:\ :pt:sr=\EI:up=\EA: v2|vt52|dec vt52:\ :bs:cd=\EJ:ce=\EK:cl=\EH\EJ:cm=\EY%+ %+ :co#80:li#24:nd=\EC:\ :pt:sr=\EI:up=\EA: svr2: d0|vt100|vt100-am|vt100|dec vt100:\         :cr=^M:do=^J:nl=^J:bl=^G:co#80:li#24:cl=50\E[;H\E[2J:\         :le=^H:bs:am:cm=5\E[%i%d;%dH:nd=2\E[C:up=2\E[A:\ :ce=3\E[K:cd=50\E[J:so=2\E[7m:se=2\E[m:us=2\E[4m:ue=2\E[m:\         :md=2\E[1m:mr=2\E[7m:mb=2\E[5m:me=2\E[m:is=\E[1;24r\E[24;1H:\ :rs=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h:ks=\E[?1h\E=:ke=\E[?1l\E>:\ :rf=/usr/lib/tabset/vt100:ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:kb=^H:\ :ho=\E[H:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:ta=^I:pt:sr=5\EM:vt#3:xn:\         :sc=\E7:rc=\E8:cs=\E[%i%d;%dr: d1|vt100|vt100-nam|vt100 w/no am:\         :am@:xn@:tc=vt100-am: d2|gt42|dec gt42:\         :cr=^M:do=^J:bl=^G:\         :le=^H:bs:co#72:ns:li#40:os: d3|vt132|vt132:\ :al=99\E[L:dl=99\E[M:ip=7:dc=7\E[P:ei=\E[4l:im=\E[4h:xn:dN#30:tc=vt100: d4|gt40|dec gt40:\         :cr=^M:do=^J:bl=^G:\         :le=^H:bs:co#72:ns:li#30:os: d5|vt50|dec vt50:\         :cr=^M:do=^J:nl=^J:bl=^G:\ :le=^H:bs:cd=\EJ:ce=\EK:cl=\EH\EJ:co#80:li#12:nd=\EC:ta=^I:pt:up=\EA: Here's the list of available terminals culled from /etc/termcap from v7 and the buggy/untested list included in termcap: dumb, lsi adm3/adm3a/adm31/adm3a, concept100/concept100rv, hp2645, dm1520/dm2500/dm3025/3025a, dec gt40/gt42/vt50/vt50h/vt52, decwriter I/decwriter II, diablo 300s, hazeltine 1500/1510/2000, Infoton 100/400/KAS, fox 1100, owl 1200, tektronix 4014, teleray 1061, terminet 1200/300, tty33/37/43, ti silent 700/745, xitex sct-100, beehiveIIIm, tvi912/tvi920, ttyWilliams, infoton|400|infoton 400 buggy -dm2500 Untested - gt40, gt42, vt50, vt50h, dw1, dtc300s, gsi, infoton, fox, tk4014, t1061, 1200, 300, tty33, tty37, tty43 I don't suppose any of these look like reasonable approximations of something I have available in Terminal/xterm? Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Jan 6 01:44:26 2022 From: clemc at ccc.com (Clem Cole) Date: Wed, 5 Jan 2022 10:44:26 -0500 Subject: [TUHS] vi on v7 In-Reply-To: <102db625-b2a0-935b-7424-a183ae64fb65@gmail.com> References: <102db625-b2a0-935b-7424-a183ae64fb65@gmail.com> Message-ID: Just add the vt100 entry from 4.1 you might be fine. FYI:To there credit, when the VT-100 was being developed the spec was a moving target and Tom Kent and his brothers and sisters in the terminal group did an amazing job -- but .... VT-100 are not completely ANSI (DEC released before the spec was ratified smd it lacks some features that are really needed). It uses scrolling regions to do some of the painting/update -- Mary Ann undoubtedly has nightmares. The termcap code in 2BSD is very early and may not be smart enough to do some of the tricks that VT-100 demanded, so it might be wise to swipe the 4.1/4.2 version and see if you can substitute. Also remember Sys V used *terminfo* [again Maryann can explain having fought that war]. Termcap was included in later versions by demand. On Wed, Jan 5, 2022 at 10:28 AM Will Senn wrote: > On 1/4/22 7:35 PM, Warner Losh wrote: > > > 1. It's not going "full" screen, even with TERM=vt100 or TERM=ansi set > (not that I was surprised, but it'd be nice)... > > What does /etc/termcap look like? > > > All right, I'm getting warmer. I tried changing ttys to various speeds, > and stty 9600, per Clem, Then, I looked at termcap, and saw that there > weren't any ansi or vt100 entries (duh), so then I tryed vt50 and vt52 > modes: > > vt50: > > HJ > > > > > > > ~ > ~ > ~ > AAAA > > > > > :q > > vt52: > > Y7 HJY- ~ > ~ > ~ > ~ > ~ > ~ > ~ > ~ > ~ > ~Y, Y7 :q > > > Here are the termcap entries. I compared with termcap in svr2, which has > vt50,vt52, and vt100: > > v7: > > vh|vt50h|dec vt50h:\ > :bs:cd=\EJ:ce=\EK:cl=\EH\EJ:cm=\EY%+ %+ :co#80:li#12:nd=\EC:\ > :pt:sr=\EI:up=\EA: > v2|vt52|dec vt52:\ > :bs:cd=\EJ:ce=\EK:cl=\EH\EJ:cm=\EY%+ %+ :co#80:li#24:nd=\EC:\ > :pt:sr=\EI:up=\EA: > > svr2: > > d0|vt100|vt100-am|vt100|dec vt100:\ > :cr=^M:do=^J:nl=^J:bl=^G:co#80:li#24:cl=50\E[;H\E[2J:\ > :le=^H:bs:am:cm=5\E[%i%d;%dH:nd=2\E[C:up=2\E[A:\ > :ce=3\E[K:cd=50\E[J:so=2\E[7m:se=2\E[m:us=2\E[4m:ue=2\E[m:\ > :md=2\E[1m:mr=2\E[7m:mb=2\E[5m:me=2\E[m:is=\E[1;24r\E[24;1H:\ > :rs=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h:ks=\E[?1h\E=:ke=\E[?1l\E>:\ > :rf=/usr/lib/tabset/vt100:ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:kb=^H:\ > :ho=\E[H:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:ta=^I:pt:sr=5\EM:vt#3:xn:\ > :sc=\E7:rc=\E8:cs=\E[%i%d;%dr: > d1|vt100|vt100-nam|vt100 w/no am:\ > :am@:xn@:tc=vt100-am: > d2|gt42|dec gt42:\ > :cr=^M:do=^J:bl=^G:\ > :le=^H:bs:co#72:ns:li#40:os: > d3|vt132|vt132:\ > > :al=99\E[L:dl=99\E[M:ip=7:dc=7\E[P:ei=\E[4l:im=\E[4h:xn:dN#30:tc=vt100: > d4|gt40|dec gt40:\ > :cr=^M:do=^J:bl=^G:\ > :le=^H:bs:co#72:ns:li#30:os: > d5|vt50|dec vt50:\ > :cr=^M:do=^J:nl=^J:bl=^G:\ > > :le=^H:bs:cd=\EJ:ce=\EK:cl=\EH\EJ:co#80:li#12:nd=\EC:ta=^I:pt:up=\EA: > > Here's the list of available terminals culled from /etc/termcap from v7 > and the buggy/untested list included in termcap: > > dumb, lsi adm3/adm3a/adm31/adm3a, concept100/concept100rv, hp2645, > dm1520/dm2500/dm3025/3025a, dec gt40/gt42/vt50/vt50h/vt52, decwriter > I/decwriter II, diablo 300s, hazeltine 1500/1510/2000, Infoton 100/400/KAS, > fox 1100, owl 1200, tektronix 4014, teleray 1061, terminet 1200/300, > tty33/37/43, ti silent 700/745, xitex sct-100, beehiveIIIm, tvi912/tvi920, > ttyWilliams, infoton|400|infoton 400 > > buggy -dm2500 > Untested - gt40, gt42, vt50, vt50h, dw1, dtc300s, gsi, infoton, fox, > tk4014, t1061, 1200, 300, tty33, tty37, tty43 > > I don't suppose any of these look like reasonable approximations of > something I have available in Terminal/xterm? > > Will > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Jan 6 01:50:58 2022 From: clemc at ccc.com (Clem Cole) Date: Wed, 5 Jan 2022 10:50:58 -0500 Subject: [TUHS] vi on v7 In-Reply-To: References: <102db625-b2a0-935b-7424-a183ae64fb65@gmail.com> Message-ID: FWIW: Since I know you are on a Mac - there are couple of retro style terminal emulators, that may be able to be configured to be VT52 or one of the others from that time. One is call Cathode which I think cost a few $s and there is a free one called Cool-Retro-Term ( https://github.com/Swordfish90/cool-retro-term) On Wed, Jan 5, 2022 at 10:44 AM Clem Cole wrote: > Just add the vt100 entry from 4.1 you might be fine. FYI:To there credit, > when the VT-100 was being developed the spec was a moving target and Tom > Kent and his brothers and sisters in the terminal group did an amazing job > -- but .... VT-100 are not completely ANSI (DEC released before the spec > was ratified smd it lacks some features that are really needed). It uses > scrolling regions to do some of the painting/update -- Mary Ann > undoubtedly has nightmares. > > The termcap code in 2BSD is very early and may not be smart enough to do > some of the tricks that VT-100 demanded, so it might be wise to swipe the > 4.1/4.2 version and see if you can substitute. Also remember Sys V used > *terminfo* [again Maryann can explain having fought that war]. Termcap > was included in later versions by demand. > > On Wed, Jan 5, 2022 at 10:28 AM Will Senn wrote: > >> On 1/4/22 7:35 PM, Warner Losh wrote: >> >> >> 1. It's not going "full" screen, even with TERM=vt100 or TERM=ansi set >> (not that I was surprised, but it'd be nice)... >> >> What does /etc/termcap look like? >> >> >> All right, I'm getting warmer. I tried changing ttys to various speeds, >> and stty 9600, per Clem, Then, I looked at termcap, and saw that there >> weren't any ansi or vt100 entries (duh), so then I tryed vt50 and vt52 >> modes: >> >> vt50: >> >> HJ >> >> >> >> >> >> >> ~ >> ~ >> ~ >> AAAA >> >> >> >> >> :q >> >> vt52: >> >> Y7 HJY- ~ >> ~ >> ~ >> ~ >> ~ >> ~ >> ~ >> ~ >> ~ >> ~Y, Y7 :q >> >> >> Here are the termcap entries. I compared with termcap in svr2, which has >> vt50,vt52, and vt100: >> >> v7: >> >> vh|vt50h|dec vt50h:\ >> :bs:cd=\EJ:ce=\EK:cl=\EH\EJ:cm=\EY%+ %+ :co#80:li#12:nd=\EC:\ >> :pt:sr=\EI:up=\EA: >> v2|vt52|dec vt52:\ >> :bs:cd=\EJ:ce=\EK:cl=\EH\EJ:cm=\EY%+ %+ :co#80:li#24:nd=\EC:\ >> :pt:sr=\EI:up=\EA: >> >> svr2: >> >> d0|vt100|vt100-am|vt100|dec vt100:\ >> :cr=^M:do=^J:nl=^J:bl=^G:co#80:li#24:cl=50\E[;H\E[2J:\ >> :le=^H:bs:am:cm=5\E[%i%d;%dH:nd=2\E[C:up=2\E[A:\ >> :ce=3\E[K:cd=50\E[J:so=2\E[7m:se=2\E[m:us=2\E[4m:ue=2\E[m:\ >> :md=2\E[1m:mr=2\E[7m:mb=2\E[5m:me=2\E[m:is=\E[1;24r\E[24;1H:\ >> :rs=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h:ks=\E[?1h\E=:ke=\E[?1l\E>:\ >> :rf=/usr/lib/tabset/vt100:ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:kb=^H:\ >> >> :ho=\E[H:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:ta=^I:pt:sr=5\EM:vt#3:xn:\ >> :sc=\E7:rc=\E8:cs=\E[%i%d;%dr: >> d1|vt100|vt100-nam|vt100 w/no am:\ >> :am@:xn@:tc=vt100-am: >> d2|gt42|dec gt42:\ >> :cr=^M:do=^J:bl=^G:\ >> :le=^H:bs:co#72:ns:li#40:os: >> d3|vt132|vt132:\ >> >> :al=99\E[L:dl=99\E[M:ip=7:dc=7\E[P:ei=\E[4l:im=\E[4h:xn:dN#30:tc=vt100: >> d4|gt40|dec gt40:\ >> :cr=^M:do=^J:bl=^G:\ >> :le=^H:bs:co#72:ns:li#30:os: >> d5|vt50|dec vt50:\ >> :cr=^M:do=^J:nl=^J:bl=^G:\ >> >> :le=^H:bs:cd=\EJ:ce=\EK:cl=\EH\EJ:co#80:li#12:nd=\EC:ta=^I:pt:up=\EA: >> >> Here's the list of available terminals culled from /etc/termcap from v7 >> and the buggy/untested list included in termcap: >> >> dumb, lsi adm3/adm3a/adm31/adm3a, concept100/concept100rv, hp2645, >> dm1520/dm2500/dm3025/3025a, dec gt40/gt42/vt50/vt50h/vt52, decwriter >> I/decwriter II, diablo 300s, hazeltine 1500/1510/2000, Infoton 100/400/KAS, >> fox 1100, owl 1200, tektronix 4014, teleray 1061, terminet 1200/300, >> tty33/37/43, ti silent 700/745, xitex sct-100, beehiveIIIm, tvi912/tvi920, >> ttyWilliams, infoton|400|infoton 400 >> >> buggy -dm2500 >> Untested - gt40, gt42, vt50, vt50h, dw1, dtc300s, gsi, infoton, fox, >> tk4014, t1061, 1200, 300, tty33, tty37, tty43 >> >> I don't suppose any of these look like reasonable approximations of >> something I have available in Terminal/xterm? >> >> Will >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Thu Jan 6 03:12:14 2022 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 5 Jan 2022 10:12:14 -0700 Subject: [TUHS] vi on v7 In-Reply-To: References: <102db625-b2a0-935b-7424-a183ae64fb65@gmail.com> Message-ID: <0927443c-d28c-ab34-c9d2-ca55450aa032@spamtrap.tnetconsulting.net> On 1/5/22 8:50 AM, Clem Cole wrote: > One is call Cathode which I think cost a few $s Is Cathode still a thing? I just quickly searched for it in the App Store and didn't find it. I seem to recall reading that it had been discontinued O(few years) ago. I'd appreciate learning that it's simply me looking in the wrong place. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4017 bytes Desc: S/MIME Cryptographic Signature URL: From clemc at ccc.com Thu Jan 6 03:28:37 2022 From: clemc at ccc.com (Clem Cole) Date: Wed, 5 Jan 2022 12:28:37 -0500 Subject: [TUHS] vi on v7 In-Reply-To: <0927443c-d28c-ab34-c9d2-ca55450aa032@spamtrap.tnetconsulting.net> References: <102db625-b2a0-935b-7424-a183ae64fb65@gmail.com> <0927443c-d28c-ab34-c9d2-ca55450aa032@spamtrap.tnetconsulting.net> Message-ID: On Wed, Jan 5, 2022 at 12:12 PM Grant Taylor via TUHS wrote: > On 1/5/22 8:50 AM, Clem Cole wrote: > > One is call Cathode which I think cost a few $s > > Is Cathode still a thing? > Sort of... > > I just quickly searched for it in the App Store and didn't find it. > https://www.macupdate.com/app/mac/36568/cathode > > I seem to recall reading that it had been discontinued O(few years) ago. > Yes.. > > I'd appreciate learning that it's simply me looking in the wrong place. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at ultimate.com Thu Jan 6 03:34:52 2022 From: phil at ultimate.com (Phil Budne) Date: Wed, 05 Jan 2022 12:34:52 -0500 Subject: [TUHS] vi on v7 In-Reply-To: <102db625-b2a0-935b-7424-a183ae64fb65@gmail.com> References: <102db625-b2a0-935b-7424-a183ae64fb65@gmail.com> Message-ID: <202201051734.205HYqeq042817@ultimate.com> Will Senn wrote: > so then I tryed vt50 and vt52 modes... xterm should have VT52 emulation, at least the man page on my system says: > o VT52 emulation is complete. But looking at CTRL+{LEFT,MIDDLE,RIGHT}_CLICK menus didn't show a toggle. The VT100 sequence to enter VT52 mode seems to be [?2l you should be able to send it with echo. Then HJ should clear the screen. NOTE! The ANSI command prefix [ will put a real VT52 into "hold screen" mode where you need to press some (scroll?) button to allow new lines to be added at the bottom of the screen. Ask me how I know! phil From crossd at gmail.com Thu Jan 6 03:35:04 2022 From: crossd at gmail.com (Dan Cross) Date: Wed, 5 Jan 2022 12:35:04 -0500 Subject: [TUHS] asm helper routines in v7 In-Reply-To: References: <10197622-30fe-7553-2f2d-edc9637ff489@gmail.com> <54ec532a-6603-6b25-fa9f-40aa9d111687@gmail.com> Message-ID: On Tue, Jan 4, 2022 at 4:28 PM Warner Losh wrote: > On Tue, Jan 4, 2022 at 2:24 PM Will Senn wrote: >> Yep, that worked... you make it look so easy, and your rationales are definitely believable :). It would be nice to hear about the rationale from a primary source. Perhaps Ken or Doug might chime in? > You can use puts too, at least in v7. Ah right; I always forget that puts was unequivocally a function in 7th Ed. It'll even add a newline for you! - Dan C. From will.senn at gmail.com Thu Jan 6 04:22:55 2022 From: will.senn at gmail.com (Will Senn) Date: Wed, 5 Jan 2022 12:22:55 -0600 Subject: [TUHS] vi on v7 In-Reply-To: <202201051734.205HYqeq042817@ultimate.com> References: <102db625-b2a0-935b-7424-a183ae64fb65@gmail.com> <202201051734.205HYqeq042817@ultimate.com> Message-ID: On 1/5/22 11:34 AM, Phil Budne wrote: > Will Senn wrote: >> so then I tryed vt50 and vt52 modes... > xterm should have VT52 emulation, at least the man page on my system says: >> o VT52 emulation is complete. > But looking at CTRL+{LEFT,MIDDLE,RIGHT}_CLICK menus didn't show a toggle. > > The VT100 sequence to enter VT52 mode seems to be [?2l > you should be able to send it with echo. > > Then HJ should clear the screen. > > NOTE! The ANSI command prefix [ will put a real VT52 into "hold > screen" mode where you need to press some (scroll?) button to allow > new lines to be added at the bottom of the screen. Ask me how I know! > > phil Well, is there no end to fascination... That 'worked' in that I was able to do this in n xterm on my mac: printf "\033[?2l" which changed the size of the xterm window to 80 chars wide... then: printf "\033H\033J" which cleared the screen as you said it would. But, then, I telnet'd into the the v7 instance and set TERM=vt52, etc. Now vi gives this: Y7 HJY- ~         ~         ~         ~         ~         ~         ~         ~         ~         ~Y, However, I should note that v7 doesn't seem to process escape sequences, either with a pristine instance or my fully configured instance... echo '\033' \033 $ ed test ?test a J (just echoes the J) . w 3 q $ od -c test 0000000 033   J  \n  \0 0000003 -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Thu Jan 6 05:02:09 2022 From: imp at bsdimp.com (Warner Losh) Date: Wed, 5 Jan 2022 12:02:09 -0700 Subject: [TUHS] vi on v7 In-Reply-To: References: <102db625-b2a0-935b-7424-a183ae64fb65@gmail.com> <202201051734.205HYqeq042817@ultimate.com> Message-ID: On Wed, Jan 5, 2022 at 11:23 AM Will Senn wrote: > On 1/5/22 11:34 AM, Phil Budne wrote: > > Will Senn wrote: > > so then I tryed vt50 and vt52 modes... > > xterm should have VT52 emulation, at least the man page on my system says: > > o VT52 emulation is complete. > > But looking at CTRL+{LEFT,MIDDLE,RIGHT}_CLICK menus didn't show a toggle. > > The VT100 sequence to enter VT52 mode seems to be [?2l > you should be able to send it with echo. > > Then HJ should clear the screen. > > NOTE! The ANSI command prefix [ will put a real VT52 into "hold > screen" mode where you need to press some (scroll?) button to allow > new lines to be added at the bottom of the screen. Ask me how I know! > > phil > > Well, is there no end to fascination... That 'worked' in that I was able > to do this in n xterm on my mac: > > printf "\033[?2l" > > > which changed the size of the xterm window to 80 chars wide... then: > > printf "\033H\033J" > > > which cleared the screen as you said it would. > > But, then, I telnet'd into the the v7 instance and set TERM=vt52, etc. > > Now vi gives this: > > Y7 HJY- ~ > ~ > ~ > ~ > ~ > ~ > ~ > ~ > ~ > ~Y, > > > However, I should note that v7 doesn't seem to process escape sequences, > either with a pristine instance or my fully configured instance... > > echo '\033' > \033 > > This is why I suggested using printf direct in C :) $ ed test > ?test > a > J (just echoes the J) > . > w > 3 > q > $ od -c test > 0000000 033 J \n \0 > 0000003 > > There's escape problems :(. I'll see if I can spin up a V7 box and see if I have any suggestions. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Thu Jan 6 06:13:22 2022 From: will.senn at gmail.com (Will Senn) Date: Wed, 5 Jan 2022 14:13:22 -0600 Subject: [TUHS] vi on v7 In-Reply-To: References: <102db625-b2a0-935b-7424-a183ae64fb65@gmail.com> <202201051734.205HYqeq042817@ultimate.com> Message-ID: <3458bd82-0896-1570-8315-00b222d8ca1d@gmail.com> > There's escape problems :(.  I'll see if I can spin up a V7 box and > see if I have any suggestions. > > Warner OK. Here's the update. I set tto 7b in SimH (which is bad?) and ESC works. Then in vi, it only uses half the screen. Per Clem's suggestion, I ran stty 9600, and voila, it "worked" full screen. Yay! Now, it's just a matter of getting ex/vi working properly as an editor. I can confuse it pretty easy once it's up and running. Either this version of vi's got some pretty awful bugs, or I screwed up the build, but at least the screen's cooperating better now. So, is 7b bad and should I be looking for another solution? Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From dot at dotat.at Thu Jan 6 07:15:53 2022 From: dot at dotat.at (Tony Finch) Date: Wed, 5 Jan 2022 21:15:53 +0000 Subject: [TUHS] roff(7) In-Reply-To: References: Message-ID: In Cambridge there was a local roff-alike called GCAL that ran on Phoenix (the IBM mainframe). It was written by Philip Hazel, who went on to write Exim and PCRE. The Exim documentation and books were prepared using SGCAL, the Unix port of GCAL. (I don't know what the S stood for: son of? successor?) GCAL used roff-like initial-dot line commands. I found out recently that GCAL's name is also based on roff, and at the same time it followed Phoenix's bird-based naming scheme (eagle the scheduler, jackdaw the database system, pigeon the mailer). GCAL is short for geococcyx californianus, aka the roadrunner, which (after an encounter with a coyote) is known to run off. https://en.wikipedia.org/wiki/Phoenix_(computer) http://quercite.dx.am/ Tony. -- f.anthony.n.finch https://dotat.at/ East Sole, Lundy, Fastnet, Irish Sea: Variable 2 to 4 becoming southerly 6 to gale 8, perhaps severe gale 9 later in Irish Sea, veering westerly later. Slight or moderate, becoming rough or very rough in Lundy and Irish Sea, and very rough or high elsewhere. Rain or showers. Good, occasionally poor. From will.senn at gmail.com Thu Jan 6 08:48:25 2022 From: will.senn at gmail.com (Will Senn) Date: Wed, 5 Jan 2022 16:48:25 -0600 Subject: [TUHS] vi on v7 In-Reply-To: References: Message-ID: On 1/4/22 7:36 PM, Warner Losh wrote: > > 3. I'd like manpages (figure they might help with the above), > but they're on the tape as .u files? > > > No clue there. Are the .u files nroff by chance? > > I figured out the manpages. Just need to copy the tmac files from 2bsd into /usr/lib, then copy the *.u files into /usr/man/manu, then: man vi VI(UCB)             UNIX Programmer's Manual VI(UCB) NAME      vi - screen oriented (visual) display editor based on ex ... Printed 1/1/70               4/4/79 2 The .u suffix was another duh moment. .u for UCB... Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From hummsmith42 at gmail.com Thu Jan 6 11:20:36 2022 From: hummsmith42 at gmail.com (Humm) Date: Thu, 6 Jan 2022 01:20:36 +0000 Subject: [TUHS] vi on v7 In-Reply-To: <202201051734.205HYqeq042817@ultimate.com> References: <102db625-b2a0-935b-7424-a183ae64fb65@gmail.com> <202201051734.205HYqeq042817@ultimate.com> Message-ID: Quoth Phil Budne: >NOTE! The ANSI command prefix [ will put a real VT52 into "hold >screen" mode where you need to press some (scroll?) button to allow >new lines to be added at the bottom of the screen. Ask me how I know! How do you know? -- Humm From reed at reedmedia.net Thu Jan 6 12:18:16 2022 From: reed at reedmedia.net (Jeremy C. Reed) Date: Wed, 5 Jan 2022 20:18:16 -0600 (CST) Subject: [TUHS] vi on v7 In-Reply-To: References: Message-ID: I don't know if is applicable, but 2bsd's doc/vi/vi.in says the vt52 is "Dumb" Maybe try an "Intelligent" choice listed there. Also see: The editor can simulate an intelligent terminal on a dumb one. Try giving the command :se redrawESC From douglas.mcilroy at dartmouth.edu Thu Jan 6 13:26:09 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Wed, 5 Jan 2022 22:26:09 -0500 Subject: [TUHS] asm helper routines in v7 Message-ID: > It would be nice to hear about the rationale from a primary source. Assembly language was deemed a last resort, especially as portability was coming to the fore. As I wrote in A Research Unix Reader, "Assembly language and magic constants gradually declined from the status of the 'real truth' (v4) to utterly forgotten (v8)." In v7, assembler usage was demoted to the bottom of syscall man pages. It could also be found in /usr/src/libc/sys/*.s Doug From imp at bsdimp.com Thu Jan 6 13:37:58 2022 From: imp at bsdimp.com (Warner Losh) Date: Wed, 5 Jan 2022 20:37:58 -0700 Subject: [TUHS] asm helper routines in v7 In-Reply-To: References: Message-ID: On Wed, Jan 5, 2022, 8:27 PM Douglas McIlroy wrote: > > It would be nice to hear about the rationale from a primary source. > > Assembly language was deemed a last resort, especially as portability > was coming to the fore. As I wrote in A Research Unix Reader, > "Assembly language and magic constants gradually declined from the > status of the 'real truth' (v4) to utterly forgotten (v8)." In v7, > assembler usage was demoted to the bottom of syscall man pages. It > could also be found in /usr/src/libc/sys/*.s > That makes a lot of sense. I've found errors and omissions in the assembler documentation for the odd system call for V7 and System III ports. A little sloppy I thought when I noticed. I'll have to see if I can dig one up again... Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Jan 7 02:00:58 2022 From: clemc at ccc.com (Clem Cole) Date: Thu, 6 Jan 2022 11:00:58 -0500 Subject: [TUHS] asm helper routines in v7 In-Reply-To: References: Message-ID: On Wed, Jan 5, 2022 at 10:27 PM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > As I wrote in A Research Unix Reader, "Assembly language and magic > constants gradually declined from the > status of the 'real truth' (v4) to utterly forgotten (v8)." Ah ... theory and practice in alignment. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sat Jan 8 05:01:30 2022 From: imp at bsdimp.com (Warner Losh) Date: Fri, 7 Jan 2022 12:01:30 -0700 Subject: [TUHS] SMP: BSD vs System V (once was: moving directories in svr2) In-Reply-To: <20220103235600.GA68567@eureka.lemis.com> References: <97f563fa-5a17-424b-acc6-07cf127f496d@localhost> <20220103234411.GA19828@mcvoy.com> <20220103235600.GA68567@eureka.lemis.com> Message-ID: On Mon, Jan 3, 2022 at 5:03 PM Greg 'groggy' Lehey wrote: > On Monday, 3 January 2022 at 15:44:11 -0800, Larry McVoy wrote: > > On Mon, Jan 03, 2022 at 05:21:51PM -0600, Doug McIntyre wrote: > >> On Mon, Jan 03, 2022 at 04:15:08PM -0500, Dan Cross wrote: > >> I'd agree, 2.4 was pretty slow and chunky, 2.5 was alright, but 2.5.1 > was quite usable and stable. > >> Also by this time, the hardware was going in directions that SunOS > wouldn't keep up with. > > > > Yeah, Doug is right, SunOS was pretty simple, it didn't really take > advantage > > of SMP, Greg Limes tried to thread it but it was too big a job for one > guy. > > > > That's not to say that SunOS couldn't have evolved into SMP, I'm 100% > > sure it could have. It just didn't. It's a shame. > > An interesting question. I had always thought that SMP was (one of?) > the technical reasons why Sun moved from a BSD to a System V base. > Since then, of course, we've done lots of work on SMP support for at > least FreeBSD. Does anybody have an overview of how good the support > is compared to modern Solaris? Is there any intrinsic reason why one > should be better than the other? > So, there were several groups that added SMP to BSD or SunOS. Solbourne's OS/MP added MP to SunOS 4.0 as first ASMP (one CPU did all the system calls, but jobs could run on other CPUs) and later as SMP (first as any CPU could run the system calls, but there was global lock and later each subsystem had a lock that it ran with). Later versions improved locking granularity by pushing locks down and making things finer grained. SunOS was a 4.3BSD with its own VM system that was well suited for locking. There were other efforts to do this, but none of them made it back to the Berkeley mother ship, so 4.4BSD shipped w/o MP support in any real sense in 1993. System V got MP when a consortium of vendors added it to the 4.0 release (that didn't include sun). By 1992 this was rolled into the 4.2 release that AT&T did with Novell. This is what would serve as the basis for Sun's Solaris product line. FreeBSD, NetBSD, OpenBSD and Dragonfly BSD have all done MP in different ways since then, of course, and Linux has added MP as well early on. So in a very real sense, Sun was in a position where it had to re-do the work that David Barak and others did at Solbourne to lock the SunOS kernel (work which really took years to complete and stabilize), or they had to go with a solution that was already developed. AT&T had that with System V 4.x, and Berkeley didn't have an equivalent set of functionality for them to draw from. I think from a PHB perspective, the decision was easy, mostly because they vastly under-estimated the maturity of System Vr4.2's MP support (but I wasn't in the room: I was at Solbourne which would never have licensed its OS/MP to Sun due to the... competitive atmosphere at the time and likely NIH inside of Sun for adopting that). Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at zick.io Sun Jan 9 22:00:01 2022 From: brian at zick.io (Brian Zick) Date: Sun, 09 Jan 2022 06:00:01 -0600 Subject: [TUHS] Bolsky's C Programmer's Handbook In-Reply-To: References: <4bcc40d8-1ce3-97ed-744c-2e95838032c9@dotat.at> <202112271208.1BRC8UuV026638@freefriends.org> Message-ID: <50c29884-5c0c-4cca-9362-db1066e2b3e8@www.fastmail.com> I found a couple copies for less than $10 on Amazon here in the states. B On Mon, Dec 27, 2021, at 6:20 AM, Tony Finch wrote: > arnold at skeeve.com wrote: > >> The C book is probably worth hanging on to for historical value. > > That's my plan, yes :-) There is a apparently another copy in our local > computer museum so I guess it isn't super rare. > > http://www.computinghistory.org.uk/det/18788/The-C-Programmers-Handbook/ > > Tony. > -- > f.anthony.n.finch https://dotat.at/ > Fisher, German Bight: East or southeast 5 or 6, occasionally 7 in > Fisher. Moderate or rough, becoming slight or moderate in German > Bight. Rain or sleet. Good, occasionally poor. From stu at remphrey.net Mon Jan 10 03:31:03 2022 From: stu at remphrey.net (Stuart Remphrey) Date: Mon, 10 Jan 2022 01:31:03 +0800 Subject: [TUHS] SMP: BSD vs System V (once was: moving directories in svr2) In-Reply-To: <20220103235600.GA68567@eureka.lemis.com> References: <97f563fa-5a17-424b-acc6-07cf127f496d@localhost> <20220103234411.GA19828@mcvoy.com> <20220103235600.GA68567@eureka.lemis.com> Message-ID: There were others that also did Unix SMP (some on BSD). Encore offering BSD, AT&T or Mach (their storage arrays contained a core cluster of 2 SMP nodes, later bought by Sun); Sequent; and Pyramid dualPort OS/x around 1985/87. Pyramid had dual-CPU 90Mx/98x and I think a single lock (memory fades a bit). Later more fine-grained around the time of the 1-CPU 9810 up to 4-CPU 9845. Before eventually going to MIPS CPU SMPs, then adding MPP to the MIPS range. IIRC, this was on a mostly-BSD 4.2/4.3 base(?) when I worked in the Pyramid team producing their POSIX threads library & parallel debugger (late 80s). Although Pyramid did have their ATT "unverse" incorporated into the same Unix, hence dualPort. So there was a bunch of SVR3/4 support included: extra set of syscalls; u.u_universe to select which; conditional symbolic links using u.u_universe to resolve to UCB or ATT paths for lib & bin dirs; merged TTY driver with a superset of stty attributes; etc. Apollo Domain had something similar to conditional symbolic links, but expanding environment variables to determine the target path. Different flexibility/overhead tradeoff. I wonder if any dualPort or DC/OSx Pyramid source survives... or the old Australian promo poster from PTC BURP, where I got elected the PHB, standing like a dork at the console of a 9840 cabinet (I think I was the only one in a long sleeve shirt that day, and had an emergency tie at the back of my desk drawer, so...) On Tue, 4 Jan 2022, 08:04 Greg 'groggy' Lehey, wrote: > On Monday, 3 January 2022 at 15:44:11 -0800, Larry McVoy wrote: > > On Mon, Jan 03, 2022 at 05:21:51PM -0600, Doug McIntyre wrote: > >> On Mon, Jan 03, 2022 at 04:15:08PM -0500, Dan Cross wrote: > >> I'd agree, 2.4 was pretty slow and chunky, 2.5 was alright, but 2.5.1 > was quite usable and stable. > >> Also by this time, the hardware was going in directions that SunOS > wouldn't keep up with. > > > > Yeah, Doug is right, SunOS was pretty simple, it didn't really take > advantage > > of SMP, Greg Limes tried to thread it but it was too big a job for one > guy. > > > > That's not to say that SunOS couldn't have evolved into SMP, I'm 100% > > sure it could have. It just didn't. It's a shame. > > An interesting question. I had always thought that SMP was (one of?) > the technical reasons why Sun moved from a BSD to a System V base. > Since then, of course, we've done lots of work on SMP support for at > least FreeBSD. Does anybody have an overview of how good the support > is compared to modern Solaris? Is there any intrinsic reason why one > should be better than the other? > > 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.php > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stu at remphrey.net Mon Jan 10 05:04:31 2022 From: stu at remphrey.net (Stuart Remphrey) Date: Mon, 10 Jan 2022 03:04:31 +0800 Subject: [TUHS] Photos of University Computer Labs - now off topic In-Reply-To: References: <818A6F70-D117-471A-9E08-E37B34F8FAE0@mac.com> <20211223021805.GK24180@mcvoy.com> <20211223141958.GR24180@mcvoy.com> <20211223161923.GT24180@mcvoy.com> Message-ID: On Fri, 24 Dec 2021, 06:14 Steve Nickolas, wrote: > On Thu, 23 Dec 2021, Larry McVoy wrote: > > > On Thu, Dec 23, 2021 at 10:02:40AM -0600, Warner Losh wrote: > >>> I had forgotten about control-t - does anything modern still do that > >> > >> FreeBSD does. It's my biggest annoyance with Linux that it doesn't. > Mac OSX also has ^T > Seems like a patch might be nice. > > Yeah, I miss SIGINFO when I'm on Linux. > Ditto. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Mon Jan 10 05:28:08 2022 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 9 Jan 2022 11:28:08 -0800 Subject: [TUHS] moving directories in svr2 In-Reply-To: References: <97f563fa-5a17-424b-acc6-07cf127f496d@localhost> Message-ID: <20220109192808.GN3441@mcvoy.com> On Mon, Jan 03, 2022 at 05:26:33PM -0500, Theodore Ts'o wrote: > Larry has told a similar story about the advantages of using a "dead" > language like Tcl for Bitkeeper, since he didn't have to deal with > gratuitous version skew problems caused by backwards incomaptible > changes in Perl or Python. Well, we also made very substantial changes to the Tcl source tree, resulting in http://little-lang.org which tosses Tcl's tortured "can't decide if I'm lisp or not" syntax in favor of something that looks like a super pleasant superset of C. From arnold at skeeve.com Mon Jan 10 05:27:18 2022 From: arnold at skeeve.com (Arnold Robbins) Date: Sun, 09 Jan 2022 21:27:18 +0200 Subject: [TUHS] awkcc available again! Message-ID: Hello All. I am pleased to announce that, after a multi-year effort, Chris Ramming's awkcc is now once again available for download, and this time with a more permissive license. I would like to thank Brian Kernighan, Chris Ramming and Doug McIlroy for contributing letters of support to my efforts to get this program re-released. The lion's share of the thanks must go to Martin Carroll of Nokia Bell Labs, who fought the uphill battle within Bell Labs to get permission to release the code, and who uploaded it to GitHub. Me? I pushed here and there, and contributed the actual code snapshots; it seems that Bell Labs had misplaced the code in the meantime. :-) The code, both the 1988 and 2011 versions, may be found at https://github.com/nokia/awkcc. The code is primarily of historical interest; I think it would take a significant effort to build it on a more modern system, although I think it could be done. It'd also be an effort to bring it up to date with the current Unix version of awk. Again most likely doable, but not necessarily trivial. In any case, enjoy! Arnold From blake1024 at gmail.com Tue Jan 11 05:00:15 2022 From: blake1024 at gmail.com (Blake McBride) Date: Mon, 10 Jan 2022 13:00:15 -0600 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: <20220101031511.GB8135@mcvoy.com> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> Message-ID: I've used nroff/troff/TeX with many of their various macro packages over about a 35 years span. During that time, I've done many single-page documents as well as documents as long as 350 pages. I also modified a version of nroff to create business forms for Laster printers. This is still being used commercially. This is one person's opinion: 1. Perhaps owing to my limited intelligence, and in spite of the fact that I've used TeX successfully on many documents, I have never been able to fully understand TeX. Apparently, it is too much for me. Troff, on the other hand, has made full sense to me. I was able to make it do what I wanted almost always. I enjoy using troff more because I find it simpler, and therefore, more pleasant to use. 2. Looking at the output, it is my opinion that TeX produces better-looking documents. Perhaps this is just no more than one man's esthetic opinion. I do not know what it is that I find better. It's just the sense I get. On the other hand, I find troff output to be sufficiently good in nearly all cases. 3. troff is a good and reasonable tool. TeX is too big and complex an environment in most cases. Although it is true that all of the complexity of the TeX environment is successfully hidden in virtually all cases. I find the huge and complex environment offputting. Very unfortunately, I see troff disappearing. I've worked with a number of teams over the last ten years. In every case, I was the oldest engineer. Also, in each case, I was the only engineer who had even heard of troff. They understand the problems of binary formats such as Word and OpenOffice. Their solutions are things like markdown, AsciiDoc, et al. They are doing this development and making use of these tools without knowledge of troff. The same is true to a greater or lesser degree with TeX, except that I've seen TeX used at universities. I like that groff and TeX are rock solid and well supported. In fact, I wrote a report generator for a modern web development framework using troff. I use it to develop reports on a routine basis. (kissweb.org) Sadly, however, if word of their existence doesn't get out there, I see them both disappearing in not much longer than a generation. This would be sad indeed. Blake McBride On Fri, Dec 31, 2021 at 9:16 PM Larry McVoy wrote: > On Sat, Jan 01, 2022 at 11:56:05AM +1100, Greg 'groggy' Lehey wrote: > > > The only negative reaction was table of contents complaints, LaTex is > > > 2 pass so it can do them, roff is one pass so you have to fiddle with > > > things. A lot. > > > > I solved that issue in later documents with two passes in the Makefile > > targets, frobbing things like references and contents in between. > > I was troff friends with W Richard Stevens, he shared with me a lot of > what he did in troff. He did the two pass thing. Nice guy and got as > much out of roff that anyone could, all of his books were troff. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nobozo at gmail.com Tue Jan 11 06:21:38 2022 From: nobozo at gmail.com (Jon Forrest) Date: Mon, 10 Jan 2022 12:21:38 -0800 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> Message-ID: On 1/10/22 11:00 AM, Blake McBride wrote: > I like that groff and TeX are rock solid and well supported. > Sadly, however, if word of their existence doesn't get out there, I see > them both disappearing in not much longer than a generation.  This would > be sad indeed. TeX badly need an official rewrite in a modern programming language (e.g. Go, Rust, even C). The rewrite should drop support for the .dvi format, and use .pdf instead. It should also make use of modern hardware capabilities and not have any built-in limits to how much memory gets used. These issues are well recognized by the TeX community but with Knuth not willing to be the BDFL, TeX is floundering. (I don't mean any of this as criticism of TeX. It's a truly miraculous program that was created in a different time.) Jon From lm at mcvoy.com Tue Jan 11 06:33:00 2022 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 10 Jan 2022 12:33:00 -0800 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> Message-ID: <20220110203300.GY3441@mcvoy.com> On Mon, Jan 10, 2022 at 01:00:15PM -0600, Blake McBride wrote: > 2. Looking at the output, it is my opinion that TeX produces > better-looking documents. It's a double edged sword. TeX looks better but you instantly know it is TeX, it has a particular look. Troff looks just fine to me, and you don't know it is Troff, Word, or what. From rich.salz at gmail.com Tue Jan 11 06:37:01 2022 From: rich.salz at gmail.com (Richard Salz) Date: Mon, 10 Jan 2022 15:37:01 -0500 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: <20220110203300.GY3441@mcvoy.com> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220110203300.GY3441@mcvoy.com> Message-ID: > It's a double edged sword. TeX looks better but you instantly know it is > TeX, it has a particular look. Troff looks just fine to me, and you don't > know it is Troff, Word, or what. > Oh, does *roff support Comic Sans now? Less flippantly, I know it's TeX is probably mostly about the fonts. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Tue Jan 11 06:46:12 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 10 Jan 2022 21:46:12 +0100 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> Message-ID: <20220110204612.21c1y%steffen@sdaoden.eu> Blake McBride wrote in : |I've used nroff/troff/TeX with many of their various macro packages over |about a 35 years span. During that time, I've done many single-page |documents as well as documents as long as 350 pages. I also modified a |version of nroff to create business forms for Laster printers. This is |still being used commercially. This is one person's opinion: | |1. Perhaps owing to my limited intelligence, and in spite of the fact that |I've used TeX successfully on many documents, I have never been able to |fully understand TeX. Apparently, it is too much for me. Troff, on the |other hand, has made full sense to me. I was able to make it do what I |wanted almost always. I enjoy using troff more because I find it simpler, |and therefore, more pleasant to use. | |2. Looking at the output, it is my opinion that TeX produces |better-looking documents. Perhaps this is just no more than one man's |esthetic opinion. I do not know what it is that I find better. It's just |the sense I get. On the other hand, I find troff output to be sufficiently |good in nearly all cases. Note that heirloom doctools (on github) is a SysV-derived *roff codebase which has been extended to use TeX paragraph algorithm, font kerning, true type fonts, etc. You need to explicitly code your macros to use these features. |3. troff is a good and reasonable tool. TeX is too big and complex an |environment in most cases. Although it is true that all of the complexity |of the TeX environment is successfully hidden in virtually all cases. I |find the huge and complex environment offputting. That is overly not true. You can start off with nothing but what TeX loads by default, plus epsf.tex and maybe colordvi.tex for some use cases and you have everything you need. I have never used it, but there is kertex and i am tracking it since, eh, July 2012. It is maintained. It is just the bare core, but includes more than i ever needed #?0|kent:kertex.tar_bomb_git$ git loca|wc -l 20 #?0|kent:kertex.tar_bomb_git$ du -sh . 13M . |Very unfortunately, I see troff disappearing. I've worked with a number of |teams over the last ten years. In every case, I was the oldest engineer. |Also, in each case, I was the only engineer who had even heard of troff. |They understand the problems of binary formats such as Word and |OpenOffice. Their solutions are things like markdown, AsciiDoc, et al. |They are doing this development and making use of these tools without |knowledge of troff. The same is true to a greater or lesser degree with |TeX, except that I've seen TeX used at universities. | |I like that groff and TeX are rock solid and well supported. In fact, I |wrote a report generator for a modern web development framework using |troff. I use it to develop reports on a routine basis. (kissweb.org) |Sadly, however, if word of their existence doesn't get out there, I see |them both disappearing in not much longer than a generation. This would be |sad indeed. Gee, the current hip top of the pops is to not even include generated documentation in release tarballs no more! Heck, i even know a project that took a year-long-not-modified manual page and converted it into some so-called text format. It thus needs a software which happily announces itself as "ronn: the opposite of roff", yieha! I mean ruby ok, there are some such tools which require Haskell, which in turn requires a binary runtime package (or a huuuuge source ball). No no, really not. I mean really. You develop it, you decide it is time for a release, you do test the convertability do you, why not include the 10 kilobytes for your is-anyway-almost-a-stub manual?? In fact these balls nowadays include .github subirectories for github workflows, which is much larger than the manual. Sigh. --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 crossd at gmail.com Tue Jan 11 07:04:07 2022 From: crossd at gmail.com (Dan Cross) Date: Mon, 10 Jan 2022 16:04:07 -0500 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220110203300.GY3441@mcvoy.com> Message-ID: On Mon, Jan 10, 2022 at 3:37 PM Richard Salz wrote: > > It's a double edged sword. TeX looks better but you instantly know it is >> TeX, it has a particular look. Troff looks just fine to me, and you don't >> know it is Troff, Word, or what. >> > > Oh, does *roff support Comic Sans now? > This is interesting; I've always felt like I could pick out troff pretty readily; I agree that TeX has a certain "look" to it (at least by default), but I always felt the same about troff as well. Less flippantly, I know it's TeX is probably mostly about the fonts. > Agreed, I suspect the same is true of my subjective interpretation of troff as well. Well, with TeX, it's the fonts and the math. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Tue Jan 11 07:06:33 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Mon, 10 Jan 2022 13:06:33 -0800 Subject: [TUHS] TeX and groff (was: roff(7)) Message-ID: <202201102106.20AL6XGw2321487@darkstar.fourwinds.com> Steffen Nurpmeso writes: > Note that heirloom doctools (on github) is a SysV-derived *roff Wow, thanks for mentioning this. I was unaware of it. When I recently wrote that it would be nice to add TeX's 2D formatting to troff I didn't realize that it had already been done. Something new to play with. Jon From bakul at iitbombay.org Tue Jan 11 07:12:34 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Mon, 10 Jan 2022 13:12:34 -0800 Subject: [TUHS] TeX and groff (was: roff(7)) Message-ID: <3781D505-E68C-4EB1-8812-50E60BE8019B@iitbombay.org>  On Jan 10, 2022, at 12:33 PM, Larry McVoy wrote: > TeX looks better but you instantly know it is > TeX, it has a particular look. Perhaps you’re thinking of documents using Computer Modern fonts, typeset using LaTeX’s document classes. Check out the examples here: https://tex.stackexchange.com/questions/1319/showcase-of-beautiful-typography-done-in-tex-friends -------------- next part -------------- An HTML attachment was scrubbed... URL: From cym224 at gmail.com Tue Jan 11 07:48:00 2022 From: cym224 at gmail.com (Nemo Nusquam) Date: Mon, 10 Jan 2022 16:48:00 -0500 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220110203300.GY3441@mcvoy.com> Message-ID: <587150bf-17ac-1679-d6e9-87a7f89aa705@gmail.com> On 2022-01-10 16:04, Dan Cross wrote (in part): > Well, with TeX, it's the fonts and the math. Well, my preferred font with LaTeX is Palatino. N. From grog at lemis.com Tue Jan 11 11:52:50 2022 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Tue, 11 Jan 2022 12:52:50 +1100 Subject: [TUHS] Recognizing TeX (was: TeX and groff (was: roff(7))) In-Reply-To: References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220110203300.GY3441@mcvoy.com> Message-ID: <20220111015250.GD25103@eureka.lemis.com> On Monday, 10 January 2022 at 15:37:01 -0500, Richard Salz wrote: >> It's a double edged sword. TeX looks better but you instantly know it is >> TeX, it has a particular look. Troff looks just fine to me, and you don't >> know it is Troff, Word, or what. > > Less flippantly, I know it's TeX is probably mostly about the fonts. Agreed. There's also something about the default layout with overly large margins. But I know how to change fonts on groff; my attempts with TeX were complete failures. 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.php -------------- 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 Tue Jan 11 11:59:01 2022 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Tue, 11 Jan 2022 12:59:01 +1100 Subject: [TUHS] Demise of TeX and groff (was: roff(7)) In-Reply-To: References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> Message-ID: <20220111015901.GE25103@eureka.lemis.com> On Monday, 10 January 2022 at 13:00:15 -0600, Blake McBride wrote: > I like that groff and TeX are rock solid and well supported. In fact, I > wrote a report generator for a modern web development framework using > troff. I use it to develop reports on a routine basis. (kissweb.org) > Sadly, however, if word of their existence doesn't get out there, I see > them both disappearing in not much longer than a generation. This would be > sad indeed. As long as man pages are formatted with ?roff, I don't see it going away. I don't suppose many people use troff any more, but there are enough of us, and as long as man pages stay the way they are, I don't think we're in any danger. 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.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From lyndon at orthanc.ca Tue Jan 11 12:13:43 2022 From: lyndon at orthanc.ca (Lyndon Nerenberg (VE7TFX/VE6BBM)) Date: Mon, 10 Jan 2022 18:13:43 -0800 Subject: [TUHS] Demise of TeX and groff (was: roff(7)) In-Reply-To: <20220111015901.GE25103@eureka.lemis.com> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> Message-ID: <4409b91cd794867d@orthanc.ca> Greg 'groggy' Lehey writes: > As long as man pages are formatted with ?roff, I don't see it going > away. I don't suppose many people use troff any more, but there are > enough of us, and as long as man pages stay the way they are, I don't > think we're in any danger. Well there is mandoc(1). But as time goes by they just seem to be re-implementing nroff. Of course that *must* be easier than just learning n/troff in the first place :-P I really don't understand this need to throw troff overboard. The code, both GNU and AT&T implementations, has been rock solid for decades. It's not like there are portability issues moving it between platforms. Provided the kiddies don't get in there and linuxify the code, of course. --lyndon From lyndon at orthanc.ca Tue Jan 11 12:25:08 2022 From: lyndon at orthanc.ca (Lyndon Nerenberg (VE7TFX/VE6BBM)) Date: Mon, 10 Jan 2022 18:25:08 -0800 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220110203300.GY3441@mcvoy.com> Message-ID: <4409b93407ed2118@orthanc.ca> Dan Cross writes: > This is interesting; I've always felt like I could pick out troff pretty > readily; I agree that TeX has a certain "look" to it (at least by default), > but I always felt the same about troff as well. My guess this is more about how ms(7) does page layout. I can spot those documents from a mile away :-) But older versions of troff can often be spotted by how box corners don't always line up properly. A lot of people get turned off by how troff markup can often look like line noise. That's true, but if you spend the time to actually learn the syntax (and it's really not that hard), you can't help but be overwhelmed by the beauty of its self-consistency. Although after three decades I still can't wrap my head around traps and diversions :-P --lyndon From lm at mcvoy.com Tue Jan 11 12:42:18 2022 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 10 Jan 2022 18:42:18 -0800 Subject: [TUHS] Demise of TeX and groff (was: roff(7)) In-Reply-To: <4409b91cd794867d@orthanc.ca> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> Message-ID: <20220111024218.GE3441@mcvoy.com> On Mon, Jan 10, 2022 at 06:13:43PM -0800, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > Greg 'groggy' Lehey writes: > > > As long as man pages are formatted with ?roff, I don't see it going > > away. I don't suppose many people use troff any more, but there are > > enough of us, and as long as man pages stay the way they are, I don't > > think we're in any danger. > > Well there is mandoc(1). But as time goes by they just seem to be > re-implementing nroff. Of course that *must* be easier than just > learning n/troff in the first place :-P > > I really don't understand this need to throw troff overboard. It's docs. The *roff docs were locked up with the Unix license. Those docs were awesome, terse but full of info like the C book. Unlike the C book they were not readily available. My Uni had a Unix license so I still have the stack of docs, decades later, still useful. I firmly believe if those docs had been open source, freely available, whatever, we would all be using an evolved roff. I tried to get Microsoft, weakly, to make Word spit out roff. Never went anywhere and I think they would have screwed it up, there was a UI, Gremlin maybe? Don't remember, but it spit out pic. Horrible pic. The world would be a better place if Word spit out readable and modifiable roff. Imagine being in Word and going, yeah, I know what it is trying to do, let me drop down to -ms and do it. And Word took your changes. Tim O'Reilly got it, wrote a book about it but I think it was too little too late. Roff is not going to take over the world but Greg is right, man pages will keep it here. Some of us will help. From lm at mcvoy.com Tue Jan 11 12:47:04 2022 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 10 Jan 2022 18:47:04 -0800 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: <4409b93407ed2118@orthanc.ca> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220110203300.GY3441@mcvoy.com> <4409b93407ed2118@orthanc.ca> Message-ID: <20220111024704.GG3441@mcvoy.com> On Mon, Jan 10, 2022 at 06:25:08PM -0800, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > but be overwhelmed by the beauty of its self-consistency. Although > after three decades I still can't wrap my head around traps and > diversions :-P Traps are easy, end of the page. Diversions are easy, it's a bucket to put stuff in. Environments are harder. From athornton at gmail.com Tue Jan 11 13:22:49 2022 From: athornton at gmail.com (Adam Thornton) Date: Mon, 10 Jan 2022 20:22:49 -0700 Subject: [TUHS] Demise of TeX and groff (was: roff(7)) In-Reply-To: <4409b91cd794867d@orthanc.ca> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> Message-ID: <8BCC2106-67EA-40D7-9C32-523FD7D7A3C1@gmail.com> Taking this to COFF... > On Jan 10, 2022, at 7:13 PM, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > > Greg 'groggy' Lehey writes: > >> As long as man pages are formatted with ?roff, I don't see it going >> away. I don't suppose many people use troff any more, but there are >> enough of us, and as long as man pages stay the way they are, I don't >> think we're in any danger. > > Well there is mandoc(1). But as time goes by they just seem to be > re-implementing nroff. Of course that *must* be easier than just > learning n/troff in the first place :-P As someone who did a lot of a Ph.D. in the history of computing, and then went into IT because he liked eating protein sometimes: The great secret is that NO ONE EVER READS THE LITERATURE. We have now made all the mistakes at least four times: Once for each of mainframes, minis, micros, and mobile. You can be a rock star at any development or operations job, even if you are, like me, a Bear Of Little Brain, simply by having some idea of what was tried already to solve a problem like this, and why it didn't work. Which you can get by actually stopping to read up about your problem before diving headfirst into coding up a solution for it. If you happen to get stinking rich from this advice, you can buy me a bottle of whiskey sometime. Adam From will.senn at gmail.com Tue Jan 11 14:11:39 2022 From: will.senn at gmail.com (Will Senn) Date: Mon, 10 Jan 2022 22:11:39 -0600 Subject: [TUHS] v7 tape in bitsavers vs recreated tape from Keith Bostic's v7 in TUHS Message-ID: <262db701-0f20-9a7b-eb21-73f222ffd2ed@gmail.com> Today I was looking around for more v7 stuff of interest that I might find on the web and came across a tape image in the ATT bits directory: http://www.bitsavers.org/bits/ATT/ labeled X7252.2015_UNIX_V7.tap and an image of the reel with original and added markings. I downloaded it and sure enough, it's a bootable v7. I then compared it with my recreated tape image from the files in the Keith Bostic folder on tuhs. The 11.7MB tapes are nearly identical, with only a handful of bytes that differ at the very end of the tape: ATT tape: 54532000    000000  000000  024000  000000  000000  000000 000077  000000 54532020    052135  014020  010000  034113  056720  023524 072143  122062 54532040    141401  000000  000000  000000  000000  000000 000000  000000 54532060    000000  000000  000000  000000  000000  000000 000000  000000 54532100    000000  000000  000000  000000  000000  000000 000000  037400 54532120    000000 000000 54532123 Bostic recreated tape: 54532000    000000  000000  024000  000000  000000  000000 177777  177777 54532020 I'm wondering - 1) Does anyone know the provenance of the X7252.2015_UNIX_V7.tap 2) Do the bytes at the end of the tapes look familiar or particularly meaningful? My knowledge of 40+ y.o. tape formats is woefully lacking, but I'm curious. Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Tue Jan 11 15:12:47 2022 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Tue, 11 Jan 2022 16:12:47 +1100 Subject: [TUHS] Demise of TeX and groff (was: roff(7)) In-Reply-To: <20220111024218.GE3441@mcvoy.com> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> Message-ID: <20220111051247.GC61872@eureka.lemis.com> On Monday, 10 January 2022 at 18:42:18 -0800, Larry McVoy wrote: > It's docs. The *roff docs were locked up with the Unix license. > Those docs were awesome, terse but full of info like the C book. > Unlike the C book they were not readily available. My Uni had a > Unix license so I still have the stack of docs, decades later, > still useful. Are these the PSD docs that are included with FreeBSD, or something else? > Tim O'Reilly got it, wrote a book about it but I think it was too > little too late. For a time perspective, this was 1987, before O'Reilly and Associates was founded. But the macros they (also, primarily, Dale Dougherty) described there are the basis for the macros they used at ORA when I started writing for them in 1993. Some time round the turn of the millennium they then migrated to DocBook, at least for the author interface. I think that they had some magic to then convert it to groff. So I don't think it was "too late"; the DocBook conversion suggests that the authors didn't like groff, though I thought that the conversion was a retrograde step. 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.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From johnl at johnlabovitz.com Tue Jan 11 15:59:53 2022 From: johnl at johnlabovitz.com (John Labovitz) Date: Tue, 11 Jan 2022 00:59:53 -0500 Subject: [TUHS] Demise of TeX and groff (was: roff(7)) In-Reply-To: <20220111051247.GC61872@eureka.lemis.com> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> <20220111051247.GC61872@eureka.lemis.com> Message-ID: <2EEA85B6-825C-4C49-AE69-114A41038098@johnlabovitz.com> On Jan 11, 2022, at 00:12, Greg 'groggy' Lehey wrote: > For a time perspective, this was 1987, before O'Reilly and Associates > was founded. But the macros they (also, primarily, Dale Dougherty) > described there are the basis for the macros they used at ORA when I > started writing for them in 1993. Some time round the turn of the > millennium they then migrated to DocBook, at least for the author > interface. I think that they had some magic to then convert it to > groff. So I don't think it was "too late"; the DocBook conversion > suggests that the authors didn't like groff, though I thought that the > conversion was a retrograde step. I think I can help fill out this puzzle. I started working for O’Reilly (specifically, for Dale) in late 1993, around the time the *roff -> DocBook/SGML transition was happening. I was hired to help develop Global Network Navigator, the first commercial website. Initially I created the first web ads (sorry) and later I was technical director of GNN. I recall that it wasn’t so much that people ‘didn’t like’ groff and its ilk, but that Tim and Dale realized that the future of publishing was going to be something far beyond simply print books, and they needed their content to have much more inherent structure and metadata than was offered by groff markup — whose purpose was primarily as a markup language for print. So the solution (as I observed it when I was there) was to translate the raw groff into a more abstract, structural markup — namely, SGML using the DocBook schema — and then to write conversion tools that would then re-generate groff, HTML, or something else. (The web/HTML was not necessarily the only future at that time!) That workflow also allowed manuscripts to be imported from other platforms (like Word) from authors who weren’t part of the Unix world, as O’Reilly branched out from strict Unix manuals into travel, finance, and other diverse worlds of content. For example, we were able to fairly easily republish the seminal _Whole Internet Catalog_ book as a major section of the GNN website, using commercial SGML->HTML tools plus a whole lotta Perl. :) —John From arnold at skeeve.com Tue Jan 11 18:50:40 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 11 Jan 2022 01:50:40 -0700 Subject: [TUHS] Demise of TeX and groff (was: roff(7)) In-Reply-To: <20220111024218.GE3441@mcvoy.com> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> Message-ID: <202201110850.20B8oeMZ020212@freefriends.org> Larry McVoy wrote: > Tim O'Reilly got it, wrote a book about it but I think it was > too little too late. That book was open sourced ~ 2 decades ago. It was scanned, OCR'ed and converted back into troff. See https://www.oreilly.com/openbook/utp/ and in particular https://github.com/larrykollar/Unix-Text-Processing . Arnold From arnold at skeeve.com Tue Jan 11 18:57:09 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 11 Jan 2022 01:57:09 -0700 Subject: [TUHS] Demise of TeX and groff (was: roff(7)) In-Reply-To: <20220111051247.GC61872@eureka.lemis.com> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> <20220111051247.GC61872@eureka.lemis.com> Message-ID: <202201110857.20B8v9vB020861@freefriends.org> "Greg 'groggy' Lehey" wrote: > But the macros they (also, primarily, Dale Dougherty) > described there are the basis for the macros they used at ORA when I > started writing for them in 1993. Some time round the turn of the > millennium they then migrated to DocBook, at least for the author > interface. I think that they had some magic to then convert it to > groff. So I don't think it was "too late"; the DocBook conversion > suggests that the authors didn't like groff, though I thought that the > conversion was a retrograde step. The DocBook conversion make it easy for them to generate HTML so that books could be put on CD and browsed with a web browser. I believe that was the main motivation. I wrote the second edition of "sed & awk" in troff and then they "converted" it to DocBook (with said backend that went back to troff for producing print). The conversion to DocBook was a disaster, such that I threatened to cancel doing the book. A lot of manual work later, the book came out OK, but boy was it painful. That backend was still in use ~ 2004 when I did "Unix In A Nutshell" and "Classic Shell Scripting" but they have moved on since then. Arnold P.S. Eric Raymond's love of DocBook not withstanding, it's a miserable markup language to have to work in. From ralph at inputplus.co.uk Tue Jan 11 21:06:43 2022 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Tue, 11 Jan 2022 11:06:43 +0000 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: <202201102106.20AL6XGw2321487@darkstar.fourwinds.com> References: <202201102106.20AL6XGw2321487@darkstar.fourwinds.com> Message-ID: <20220111110643.CA20722016@orac.inputplus.co.uk> Hi Jon, > Steffen Nurpmeso writes: > > Note that heirloom doctools (on github) is a SysV-derived *roff > > Wow, thanks for mentioning this. I was unaware of it. When > I recently wrote that it would be nice to add TeX's 2D formatting > to troff I didn't realize that it had already been done. > > Something new to play with. There's also Neatroff by Ali Gholami Rudi. It has TeX's paragraph formatting and several other new features, taking from Plan 9, Heirloom, and Groff. IIRC, it's an implementation from scratch. https://litcave.rudi.ir links to its introductary PDF in the first paragraph, https://litcave.rudi.ir/neatroff.pdf, and a Typesetting section below the change-log. -- Cheers, Ralph. From beebe at math.utah.edu Tue Jan 11 23:37:44 2022 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Tue, 11 Jan 2022 06:37:44 -0700 Subject: [TUHS] TeX and groff (was: roff(7)) Message-ID: On the subject of documtation of [nt]roff, no one seems to have mentioned Narain Gehani's two editions of ``Document Formatting and Typesetting on the UNIX System'' (700+ pages), and a second two-author volume that covers grap, mv, ms, and troff. There is a table of contents of the second edition recorded here: http://www.math.utah.edu/pub/tex/bib/typeset.html#Gehani:1987:DFT There is an entry in that file for the first edition too http://www.math.utah.edu/pub/tex/bib/typeset.html#Gehani:1986:DF The second volume, co-authored with Steven Lally, is covered here: http://www.math.utah.edu/pub/tex/bib/typeset.html#Gehani:1988:DFT ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From lm at mcvoy.com Wed Jan 12 00:00:05 2022 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 11 Jan 2022 06:00:05 -0800 Subject: [TUHS] Demise of TeX and groff (was: roff(7)) In-Reply-To: <202201110850.20B8oeMZ020212@freefriends.org> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> <202201110850.20B8oeMZ020212@freefriends.org> Message-ID: <20220111140005.GI3441@mcvoy.com> On Tue, Jan 11, 2022 at 01:50:40AM -0700, arnold at skeeve.com wrote: > Larry McVoy wrote: > > > Tim O'Reilly got it, wrote a book about it but I think it was > > too little too late. > > That book was open sourced ~ 2 decades ago. It was scanned, OCR'ed > and converted back into troff. See https://www.oreilly.com/openbook/utp/ > and in particular https://github.com/larrykollar/Unix-Text-Processing . Yeah but it is 2022. 2 decades ago is 2002. TeX was first released in 1978. So it had 2+ decades where it was out there, the docs were out there, and Unix was doing the licensing dance. It may be ancient history but troff was not a given on every platform. nroff was there but troff was considered optional, you had to pay for it and a lot of vendors didn't see the value. So the docs and you weren't sure if you would have it at your next job, not good. I really wish it were different, I adore troff, I wrote something called webroff that took -ms input and produced our website (until we got marketing people and they replaced it with something "better", better my ass). I've written papers in TeX and while it isn't horrible, it's not great, I see nothing there that makes me want it over roff. From cowan at ccil.org Wed Jan 12 00:52:47 2022 From: cowan at ccil.org (John Cowan) Date: Tue, 11 Jan 2022 09:52:47 -0500 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: <20220111110643.CA20722016@orac.inputplus.co.uk> References: <202201102106.20AL6XGw2321487@darkstar.fourwinds.com> <20220111110643.CA20722016@orac.inputplus.co.uk> Message-ID: On Tue, Jan 11, 2022 at 6:13 AM Ralph Corderoy wrote: There's also Neatroff by Ali Gholami Rudi. It has TeX's paragraph > formatting and several other new features, taking from Plan 9, > Heirloom, and Groff. > I remember reading somewhere that some versions of `more' and/or `less' used TeX paragraphing when breaking long lines for display, but I can't track it down now. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Jan 12 01:47:36 2022 From: clemc at ccc.com (Clem Cole) Date: Tue, 11 Jan 2022 10:47:36 -0500 Subject: [TUHS] Demise of TeX and groff (was: roff(7)) In-Reply-To: <20220111024218.GE3441@mcvoy.com> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> Message-ID: On Mon, Jan 10, 2022 at 9:43 PM Larry McVoy wrote: > It's docs. The *roff docs were locked up with the Unix license. Larry point taken but ... I'm not so sure that specific statement is true. It may have >>seemed<< that way to you, but I'm fairly sure that in fact, it was not. The documents were published independently to the source and use of the binary license. I do think that some had an AT&T copyright on them, but I'm not even sure all of them had a copyright associated. The AT&T license in fact explicitly allowed replication of the documents that came with UNIX could be duplicated and distributed without violating the license. Numerous people sold copies of them. Any (student or not) could go into the MIT or Harvard Coop and buy a copy. Same in the Berkeley area, IIRC Stacy's [a famous Telgraph ave bookstore] had the BSD (as well as other systems) manuals. Beyond base duplication, numerous companies published parts of them and in particular parts if not all of the roff manual. For instance, a firm in Seattle called CSSC published a number of reference guides and use guides based on them [I just found a number of copies of some of them this weekend as I'm resetting up my basement. I have a number of duplicates that I am offering to the hive BTW]. I do believe that you are correct that both the sources (and associated binaries) to original nroff/groff and ditroff were licensed and needed and an AT&T license, but not the documents themselves. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Wed Jan 12 02:55:56 2022 From: rich.salz at gmail.com (Richard Salz) Date: Tue, 11 Jan 2022 11:55:56 -0500 Subject: [TUHS] Demise of TeX and groff (was: roff(7)) In-Reply-To: References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> Message-ID: On Tue, Jan 11, 2022 at 10:49 AM Clem Cole wrote: > > On Mon, Jan 10, 2022 at 9:43 PM Larry McVoy wrote: > >> It's docs. The *roff docs were locked up with the Unix license. > > > Larry point taken but ... I'm not so sure that specific statement is true. > I read it as s/locked up with/useless without/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Wed Jan 12 04:36:27 2022 From: crossd at gmail.com (Dan Cross) Date: Tue, 11 Jan 2022 13:36:27 -0500 Subject: [TUHS] Coastal cultures, collaboration, creativity and Sun vs DEC. Message-ID: I've been meaning to ask about this for a while.... "... The reason why is because there was tremendous antagonism between New York and L.A. L.A. was, you know, full of color, full of acid, full of hippies, and we were not like that. We dressed in black and white. We did not like free love. ..... We took amphetamine; they took LSD. They were, you know, sort of loving and happy, and we were - we weren't really evil, we were more intellectual, more about art." [Mary Woronov, in an interview with NPR's Terry Gross on "Fresh Air", talking about New York City, Warhol's Factory and shows in Los Angeles while touring with the Velvet Underground: http://www.npr.org/templates/transcript/transcript.php?storyId=241437872] Note: I am not suggesting that anyone involved with Unix ever took amphetamines, nor, despite the usual crack about LSD and BSD, that anyone on the west coast was taking acid, though Markov's "What the Dormouse Said" would indicate that many of you WERE tripping. It seems like Unix is largely a child of the coasts. Notable work in Utah, Colorado and Chicago aside, it seems the bulk of early Unix work happened in either the greater New York metro area in northern New Jersey or the greater Bay area around San Francisco. Notable work was also done in Massachusetts, but again, that's a coastal state and I think it's fair to say that most of that was inside the route 128 corridor. Of course work was done internationally, but I'm particularly curious about differences in US culture here, and how they influenced things. The question is, to what extent did differences in coastal cultures influence things like design aesthetics? I think it's is accurate to characterize early BTL Unix by it's minimalism, and others have echoed this (cf. Richard Gabriel in the "Worse is Better" papers). But similarly, BSD has always felt like a larger system -- didn't Lions go as far as to quip about the succinctness of 6th Edition being "fixed" by 4BSD? Anyway, I believe it is fair to say that early Unix has a rather distinct feel from later BSD-derived systems and the two did evolve in different geographic locations. Furthermore, the world was not as connected then as it is now. So to what extent, if any, was this a function of the larger cultural forces at play near where that work was taking place? - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Wed Jan 12 04:45:14 2022 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 11 Jan 2022 10:45:14 -0800 Subject: [TUHS] Coastal cultures, collaboration, creativity and Sun vs DEC. In-Reply-To: References: Message-ID: <20220111184514.GX3441@mcvoy.com> On Tue, Jan 11, 2022 at 01:36:27PM -0500, Dan Cross wrote: > It seems like Unix is largely a child of the coasts. Notable work in Utah, > Colorado and Chicago aside, it seems the bulk of early Unix work happened > in either the greater New York metro area in northern New Jersey or the > greater Bay area around San Francisco. There is a reason that a ton of the kernel group at Sun were from Wisconsin, well, UW-Madison grads. UW did some porting work, added NFS to BSD, they were quite active in the 1980s. From clemc at ccc.com Wed Jan 12 04:49:38 2022 From: clemc at ccc.com (Clem Cole) Date: Tue, 11 Jan 2022 13:49:38 -0500 Subject: [TUHS] Demise of TeX and groff (was: roff(7)) In-Reply-To: References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> Message-ID: Yeah, but the original Wang CAT4 version of troff was available without the extra license - its in the BSD tree. Now that was tied to the original UNIX license of course but it was available. Many (??most??) sites use the vcat program that Tom Ferrin wrote that used the Hershey Fonts to plot the output on a Versatec or later Varian plotter. The original Imagen which was forked from a Stanford project used that scheme until Adobe released Transcript. Brian's Device Independent Troff (ditroff) took another license either source or binary redistribution. DEC for instance, offered it as a layered product to Ultrix, and I think Sun did the same thing. At Masscomp I convinced management that tracking the sites that had it and which did not was too much of a PITA and if we just paid AT&T $15 and Adobe $1 a system, Engineering could just assume it was there. Of course, Tim and Dale both saw ditroff at Masscomp and took that (and Steve Talbot's modified mS macros and Janet Egan's set of book making tools) with them to ORA when they wrote the original NutShell book suite. I'm not sure Tim ever saw the original troff because as soon as I got there, I bought the ditroff and transcript licenses and rid us of the CAT4 stuff. Clem On Tue, Jan 11, 2022 at 11:56 AM Richard Salz wrote: > > > On Tue, Jan 11, 2022 at 10:49 AM Clem Cole wrote: > >> >> On Mon, Jan 10, 2022 at 9:43 PM Larry McVoy wrote: >> >>> It's docs. The *roff docs were locked up with the Unix license. >> >> >> Larry point taken but ... I'm not so sure that specific statement is true. >> > > I read it as s/locked up with/useless without/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at jfloren.net Wed Jan 12 04:50:57 2022 From: john at jfloren.net (John Floren) Date: Tue, 11 Jan 2022 18:50:57 +0000 Subject: [TUHS] Coastal cultures, collaboration, creativity and Sun vs DEC. In-Reply-To: References: Message-ID: <8VN9-0_HJaGPYYv7VrDzWnd8_gjijL83DOKWP5DLDA6Ca3YvALGGMo3shrQZSXG5zshsYdO8CjUvFhyI6QxqpQu2oGSXlWKNTO3Kr9vmCC0=@jfloren.net> On Tuesday, January 11th, 2022 at 10:36 AM, Dan Cross wrote: > The question is, to what extent did differences in coastal cultures influence things like design aesthetics? I think it's is accurate to characterize early BTL Unix by it's minimalism, and others have echoed this (cf. Richard Gabriel in the "Worse is Better" papers). But similarly, BSD has always felt like a larger system -- didn't Lions go as far as to quip about the succinctness of 6th Edition being "fixed" by 4BSD? I've usually attributed BSD's larger size to the enthusiasm of students who delight in adding nifty little toys and tools and options. Although "the Unix Philosophy" gets invoked in hushed tones today, there was presumably fewer fingers being wagged at the Berkeley kids for daring to experiment (except when they filled up the disk). john From cowan at ccil.org Wed Jan 12 05:20:33 2022 From: cowan at ccil.org (John Cowan) Date: Tue, 11 Jan 2022 14:20:33 -0500 Subject: [TUHS] Demise of TeX and groff (was: roff(7)) In-Reply-To: References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> Message-ID: On Tue, Jan 11, 2022 at 10:48 AM Clem Cole wrote: > I do believe that you are correct that both the sources (and associated > binaries) to original nroff/groff and ditroff were licensed and needed and > an AT&T license, but not the documents themselves. > I assume you mean s/groff/troff/. There must have been some public access to the documentation like this that allowed James Clark to develop groff in the 1987-91 time frame, though. It's still the *roff shipped with *BSD. dformat, a pic preprocessor by Jon Bentley that displays bits-in-a-word pictures, is now available at ; it's written in awk. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Wed Jan 12 05:34:16 2022 From: cowan at ccil.org (John Cowan) Date: Tue, 11 Jan 2022 14:34:16 -0500 Subject: [TUHS] Coastal cultures, collaboration, creativity and Sun vs DEC. In-Reply-To: References: Message-ID: On Tue, Jan 11, 2022 at 1:37 PM Dan Cross wrote: It seems like Unix is largely a child of the coasts. > > We can add the eastern coast of Australia, where the original Wollongong group made the first V6 port to the Interdata 7/32 (not to be confused with the Labs port to the 8/32). The Western U.S. company of the same name was formed to sell it, but I don't know if any of the Ozites moved to Palo Alto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Jan 12 06:06:51 2022 From: clemc at ccc.com (Clem Cole) Date: Tue, 11 Jan 2022 15:06:51 -0500 Subject: [TUHS] Demise of TeX and groff (was: roff(7)) In-Reply-To: References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> Message-ID: On Tue, Jan 11, 2022 at 2:20 PM John Cowan wrote: > I assume you mean s/groff/troff/. There must have been some public access > to the documentation like this that allowed James Clark to develop groff in > the 1987-91 time frame, though. It's still the *roff shipped with *BSD. > No, I mean troff... troff was written by Joseph Ossanna for early version of UNIX. It output was for the CAT4 typesetter [which Wang eventually was the owner, although I believe when BTL bought the typesetter, the C/A/T folk was an independent company from Wang]. The output is funky binary format. The docs describing troff can be found in some of the early distributions [for look in Warrens archives]. IIRC V6 had the nroff sources [ https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s7], and v7 has the nroff/troff source [ https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/troff]. I've forgotten which earlier version had the binary in /bin (maybe v6 but possibly v5 too) and I'm fairly certain the original source leaked to the Universities before V7. I know we had the binary at CMU, before V7, but I don't remember when we got the source - but I suspect one our OYOC students brought it. I'll Let Noah speak for MIT and some one like Mary Ann speak for UCB before I got there. After Joe died and the BTL crew got a new APS5 typesetter, Brian set out to rewrite the code base to support any typesetting by using traditional compiler technology of converting the input to an ASCII representation that is walked by a seperate program that generates the device specific output. In fact it was this work (original done on V6) that forced Dennis (and I assume Steve Johnson) to update the C language a bit - which is what is described in K&R1. Brian's code and a version of DMR's updated C compiler was released independently as a package - hence the term 'typesetter C.' This compiler and the new document system took a seperate license. I had it at both CMU in the 70s and Tektronix -- I think Steve Glaser had it at Rice also - again ask someone else for other sites, including some of the early European ones. Later Brian's work was updated after V7 and included some new tools, and became known as Writer's Workbench, which eventually was entered in the 'toolchest.' At the time of the first release Brian published a paper / TR that describes the new version of troff (a.ka. ditroff), including some level of documentation for the intermediate language. That was published and would have been officially available to James. Clark certainly had access to both the papers as well as binaries. His work would eventually be called groff. I personally saw a version of it before it was taken into the Gnu project, in the early 1980s. I do not know if he had access to Brian's actual code under license when he reimplemented it in C++ creating a new implementation, as UCB did when they started to rewrite many of the utilities and main OS itself. The AT&T case basically said that once the implementations was released, AT&T could no longer call anything a trade secret, although they *do the own the IP and copyright* [and please not start a GPL/BSD license flame here -- the horse is so dead - please go back into the TUHS archives and read all about it if you are new here]. Larry is correct, that I do not believe that AT&T ever released that IP directly -- although the sources are certainly available at: The Heirloom Documentation Tools I personally do not know the history. *But I believe* the concept is that when Sun bought out its license and was able to open source Solaris, the code base that goes back to Brian's original implementation became available at that point. Some one like Larry or Rob Gingell who lived some of that transition might be able to offer those details. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Wed Jan 12 06:15:43 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Tue, 11 Jan 2022 12:15:43 -0800 Subject: [TUHS] Demise of TeX and groff (was: roff(7)) In-Reply-To: <202201110857.20B8v9vB020861@freefriends.org> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> <20220111051247.GC61872@eureka.lemis.com> <202201110857.20B8v9vB020861@freefriends.org> Message-ID: <202201112015.20BKFhWT2355400@darkstar.fourwinds.com> arnold at skeeve.com writes: > The DocBook conversion make it easy for them to generate HTML so > that books could be put on CD and browsed with a web browser. > I believe that was the main motivation. Having been through this sort of stuff fairly recently, I wrote a short script that converted my troff macros into OpenOffice XML format because my publisher wanted Word. As I think I mentioned earlier, I also had a script that converted pic into SVG so that it could be included in Word docs. There were two difficulties. First, while I could have SVG pics, I had to insert them into the doc manually, couldn't figure how to do that in the XML. Second was that I ended up sending PDFs of the tables to one of the layout people as I couldn't come up with a decent way to convert those. An interesting aspect of this is that I grew up on the simple layout that was easy to do in tbl which is hard to do in Word as its tables are overly gaudy. The big thing missing from *roff from a publishing point of view is a good way to make comments and respond to them. Kind of a must-have when working with human (not text) editors. Jon From robpike at gmail.com Wed Jan 12 06:17:56 2022 From: robpike at gmail.com (Rob Pike) Date: Wed, 12 Jan 2022 07:17:56 +1100 Subject: [TUHS] Coastal cultures, collaboration, creativity and Sun vs DEC. In-Reply-To: References: Message-ID: I see a stylistic connection between the style of writing of the manuals and the New York journalism, especially that of the New Yorker. When I arrived at Bell Labs, I was a little taken aback by the change of culture in writing, dressing, and entertainment compared to my years as a grad student in California. I mean, I fit in - I subscribed to the New Yorker - but I felt like a bum in a room full of high society folk. That feeling never really left. -rob On Wed, Jan 12, 2022 at 6:35 AM John Cowan wrote: > > > On Tue, Jan 11, 2022 at 1:37 PM Dan Cross wrote: > > It seems like Unix is largely a child of the coasts. >> >> > We can add the eastern coast of Australia, where the original Wollongong > group made the first V6 port to the Interdata 7/32 (not to be confused with > the Labs port to the 8/32). The Western U.S. company of the same name was > formed to sell it, but I don't know if any of the Ozites moved to Palo Alto. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Wed Jan 12 06:22:41 2022 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 11 Jan 2022 12:22:41 -0800 Subject: [TUHS] Demise of TeX and groff (was: roff(7)) In-Reply-To: <202201112015.20BKFhWT2355400@darkstar.fourwinds.com> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> <20220111051247.GC61872@eureka.lemis.com> <202201110857.20B8v9vB020861@freefriends.org> <202201112015.20BKFhWT2355400@darkstar.fourwinds.com> Message-ID: <20220111202241.GZ3441@mcvoy.com> On Tue, Jan 11, 2022 at 12:15:43PM -0800, Jon Steinhart wrote: > The big thing missing from *roff from a publishing point of view is > a good way to make comments and respond to them. Kind of a must-have > when working with human (not text) editors. Source code control for the win. From ggm at algebras.org Wed Jan 12 06:25:52 2022 From: ggm at algebras.org (George Michaelson) Date: Wed, 12 Jan 2022 06:25:52 +1000 Subject: [TUHS] Coastal cultures, collaboration, creativity and Sun vs DEC. In-Reply-To: References: Message-ID: Bit of this in ietf too. Inner cohort of vint and similar background wear three piece suits. Three: vest not optional. A west coast mob wear tie-dye tees. On Wed, 12 Jan 2022, 6:18 am Rob Pike, wrote: > I see a stylistic connection between the style of writing of the manuals > and the New York journalism, especially that of the New Yorker. When I > arrived at Bell Labs, I was a little taken aback by the change of culture > in writing, dressing, and entertainment compared to my years as a grad > student in California. I mean, I fit in - I subscribed to the New Yorker - > but I felt like a bum in a room full of high society folk. > > That feeling never really left. > > -rob > > > On Wed, Jan 12, 2022 at 6:35 AM John Cowan wrote: > >> >> >> On Tue, Jan 11, 2022 at 1:37 PM Dan Cross wrote: >> >> It seems like Unix is largely a child of the coasts. >>> >>> >> We can add the eastern coast of Australia, where the original Wollongong >> group made the first V6 port to the Interdata 7/32 (not to be confused with >> the Labs port to the 8/32). The Western U.S. company of the same name was >> formed to sell it, but I don't know if any of the Ozites moved to Palo Alto. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Wed Jan 12 06:26:12 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Tue, 11 Jan 2022 12:26:12 -0800 Subject: [TUHS] Demise of TeX and groff (was: roff(7)) In-Reply-To: <20220111202241.GZ3441@mcvoy.com> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> <20220111051247.GC61872@eureka.lemis.com> <202201110857.20B8v9vB020861@freefriends.org> <202201112015.20BKFhWT2355400@darkstar.fourwinds.com> <20220111202241.GZ3441@mcvoy.com> Message-ID: <202201112026.20BKQC9r2356242@darkstar.fourwinds.com> Larry McVoy writes: > On Tue, Jan 11, 2022 at 12:15:43PM -0800, Jon Steinhart wrote: > > The big thing missing from *roff from a publishing point of view is > > a good way to make comments and respond to them. Kind of a must-have > > when working with human (not text) editors. > > Source code control for the win. Well, you're correct, but not practical with human editors. I'm not talking about revision history, I'm talking about the ability to easily highlight a portion of text and comment "did you mean foo?" and so on. That part of the production process feedback loop is missing. Of course, with *roff one could mostly produce one's own stuff without needing human editors and a production staff. From lm at mcvoy.com Wed Jan 12 06:36:18 2022 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 11 Jan 2022 12:36:18 -0800 Subject: [TUHS] Demise of TeX and groff (was: roff(7)) In-Reply-To: <202201112026.20BKQC9r2356242@darkstar.fourwinds.com> References: <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> <20220111051247.GC61872@eureka.lemis.com> <202201110857.20B8v9vB020861@freefriends.org> <202201112015.20BKFhWT2355400@darkstar.fourwinds.com> <20220111202241.GZ3441@mcvoy.com> <202201112026.20BKQC9r2356242@darkstar.fourwinds.com> Message-ID: <20220111203618.GA3441@mcvoy.com> On Tue, Jan 11, 2022 at 12:26:12PM -0800, Jon Steinhart wrote: > Larry McVoy writes: > > On Tue, Jan 11, 2022 at 12:15:43PM -0800, Jon Steinhart wrote: > > > The big thing missing from *roff from a publishing point of view is > > > a good way to make comments and respond to them. Kind of a must-have > > > when working with human (not text) editors. > > > > Source code control for the win. > > Well, you're correct, but not practical with human editors. I'm not > talking about revision history, I'm talking about the ability to easily > highlight a portion of text and comment "did you mean foo?" and so on. > That part of the production process feedback loop is missing. Of course, > with *roff one could mostly produce one's own stuff without needing human > editors and a production staff. I wrote the GUIs for BitKeeper, I could absolutely give you exactly what you want. Really, what you are describing is our code review system which could done done completely in a web browser but if you needed to hack on things, you cloned it and hacked on it and pushed. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From jon at fourwinds.com Wed Jan 12 06:41:37 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Tue, 11 Jan 2022 12:41:37 -0800 Subject: [TUHS] Demise of TeX and groff (was: roff(7)) In-Reply-To: <20220111203618.GA3441@mcvoy.com> References: <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> <20220111051247.GC61872@eureka.lemis.com> <202201110857.20B8v9vB020861@freefriends.org> <202201112015.20BKFhWT2355400@darkstar.fourwinds.com> <20220111202241.GZ3441@mcvoy.com> <202201112026.20BKQC9r2356242@darkstar.fourwinds.com> <20220111203618.GA3441@mcvoy.com> Message-ID: <202201112041.20BKfbwg2356679@darkstar.fourwinds.com> Larry McVoy writes: > I wrote the GUIs for BitKeeper, I could absolutely give you exactly > what you want. Really, what you are describing is our code review > system which could done done completely in a web browser but if you > needed to hack on things, you cloned it and hacked on it and pushed. You were looking for a retirement project if I remember correctly. While it's probably out of scope for this mailing list, I would be interested in how you would handle things like an editor proposing a change that would involve not just word changes, but formatting. A non-roffer would need to have some way to show those changes and to have them pushed back into the appropriate requests and reformatted. From robpike at gmail.com Wed Jan 12 06:44:27 2022 From: robpike at gmail.com (Rob Pike) Date: Wed, 12 Jan 2022 07:44:27 +1100 Subject: [TUHS] Coastal cultures, collaboration, creativity and Sun vs DEC. In-Reply-To: References: Message-ID: Similar. Everyone at Bell Labs was so *proper*. (Except Ken, of course. Ken is *sui generis*, and a Californian). I'm sure it wasn't really me, but it felt like I was the first person to utter a curse word in the Unix room. -rob On Wed, Jan 12, 2022 at 7:26 AM George Michaelson wrote: > Bit of this in ietf too. Inner cohort of vint and similar background wear > three piece suits. > > Three: vest not optional. > > A west coast mob wear tie-dye tees. > > On Wed, 12 Jan 2022, 6:18 am Rob Pike, wrote: > >> I see a stylistic connection between the style of writing of the manuals >> and the New York journalism, especially that of the New Yorker. When I >> arrived at Bell Labs, I was a little taken aback by the change of culture >> in writing, dressing, and entertainment compared to my years as a grad >> student in California. I mean, I fit in - I subscribed to the New Yorker - >> but I felt like a bum in a room full of high society folk. >> >> That feeling never really left. >> >> -rob >> >> >> On Wed, Jan 12, 2022 at 6:35 AM John Cowan wrote: >> >>> >>> >>> On Tue, Jan 11, 2022 at 1:37 PM Dan Cross wrote: >>> >>> It seems like Unix is largely a child of the coasts. >>>> >>>> >>> We can add the eastern coast of Australia, where the original Wollongong >>> group made the first V6 port to the Interdata 7/32 (not to be confused with >>> the Labs port to the 8/32). The Western U.S. company of the same name was >>> formed to sell it, but I don't know if any of the Ozites moved to Palo Alto. >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Wed Jan 12 06:49:41 2022 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 11 Jan 2022 12:49:41 -0800 Subject: [TUHS] Demise of TeX and groff (was: roff(7)) In-Reply-To: <202201112041.20BKfbwg2356679@darkstar.fourwinds.com> References: <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> <20220111051247.GC61872@eureka.lemis.com> <202201110857.20B8v9vB020861@freefriends.org> <202201112015.20BKFhWT2355400@darkstar.fourwinds.com> <20220111202241.GZ3441@mcvoy.com> <202201112026.20BKQC9r2356242@darkstar.fourwinds.com> <20220111203618.GA3441@mcvoy.com> <202201112041.20BKfbwg2356679@darkstar.fourwinds.com> Message-ID: <20220111204941.GB3441@mcvoy.com> On Tue, Jan 11, 2022 at 12:41:37PM -0800, Jon Steinhart wrote: > Larry McVoy writes: > > I wrote the GUIs for BitKeeper, I could absolutely give you exactly > > what you want. Really, what you are describing is our code review > > system which could done done completely in a web browser but if you > > needed to hack on things, you cloned it and hacked on it and pushed. > > You were looking for a retirement project if I remember correctly. > While it's probably out of scope for this mailing list, I would be > interested in how you would handle things like an editor proposing > a change that would involve not just word changes, but formatting. > A non-roffer would need to have some way to show those changes and > to have them pushed back into the appropriate requests and reformatted. I've done this. We wrote our own contract with the help a great lawyer at Fenwick and West. I showed him how one document was producing around 8 different licenses, from your basic nobody version all the way up to Intel or HP or whoever master license agreements. Once he saw how you could do that, he said "this is so much better than maintaining 8 different, but mostly the same, documents". Exactly. He editted the roff input directly. I gave him a copy of BitKeeper and he used that to check in. Comments were check in comments. From jon at fourwinds.com Wed Jan 12 06:57:21 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Tue, 11 Jan 2022 12:57:21 -0800 Subject: [TUHS] Coastal cultures, collaboration, creativity and Sun vs DEC. In-Reply-To: References: Message-ID: <202201112057.20BKvLtV2357171@darkstar.fourwinds.com> Rob Pike writes: > Similar. Everyone at Bell Labs was so *proper*. (Except Ken, of course. > Ken is *sui generis*, and a Californian). > > I'm sure it wasn't really me, but it felt like I was the first person to > utter a curse word in the Unix room. That might be a technicality. I discovered the Unix room late one night when blood sugar was running low so I hit the candy machines on the sixth floor of building 2. While I was getting my snack, I heard a robotic voice coming from down the hall saying "fuck fuck fuck fuck". I had to investigate. Found a small door with a frosted glass window that had an 8.5x11 piece of paper taped to in on which was spelled out the word UNIX in block letters in I believe black electrical tape. Opened the door to discover that a Votrax had been acquired and that Ken and Dennis were teaching it to swear. So they must have at least known those words. On another technicality, I bicycled to the labs every day, naturally uphill in both directions. Not possible to avoid sweating when pushing up Glenside Road. And no showers available; those were for the security guards only. Turned out that dress code was up to supervisors, and Joe Condon was fine with me wearing shorts to work. I often got glared at when walking down the hall and had to explain myself to the "proper" folks. From jon at fourwinds.com Wed Jan 12 07:03:13 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Tue, 11 Jan 2022 13:03:13 -0800 Subject: [TUHS] Demise of TeX and groff (was: roff(7)) In-Reply-To: <20220111204941.GB3441@mcvoy.com> References: <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> <20220111051247.GC61872@eureka.lemis.com> <202201110857.20B8v9vB020861@freefriends.org> <202201112015.20BKFhWT2355400@darkstar.fourwinds.com> <20220111202241.GZ3441@mcvoy.com> <202201112026.20BKQC9r2356242@darkstar.fourwinds.com> <20220111203618.GA3441@mcvoy.com> <202201112041.20BKfbwg2356679@darkstar.fourwinds.com> <20220111204941.GB3441@mcvoy.com> Message-ID: <202201112103.20BL3DdD2357489@darkstar.fourwinds.com> Larry McVoy writes: > He editted the roff input directly. I gave him a copy of BitKeeper > and he used that to check in. Comments were check in comments. Yeah, I get this. But I was dealing with a publisher whose staff was trained differently and weren't going to learn roff just for me. They (No Starch Press) do a lot of books per year, and it didn't make sense for them to retrain just for me. And, it wasn't just one editor; there were many passes with many different editors, some of whom were contract editors that Bill wasn't going to pay to learn new stuff. Bottom line is that I think that it would be awesome to have a WYSIWYG front end to the roff tools. Clearly not impossible as even Word and such as some sort of back end format which was only made possible by calling it markup instead of macros :-) From douglas.mcilroy at dartmouth.edu Wed Jan 12 08:02:39 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Tue, 11 Jan 2022 17:02:39 -0500 Subject: [TUHS] Demise of TeX and groff (was: roff(7)) Message-ID: > Later Brian's work was updated after V7 and included some new tools, and became known as Writer's Workbench, which eventually was entered in the 'toolchest.' WWB wouldn't exist if text had not routinely existed in machine-readable form, thanks to word-processing. But the impetus for WWB came from "style", not from troff. Style was a spinoff of Lorinda Cherry's "parts", which assigned parts of speech to the words of a document. Style provided a statistical profile of the text: measures such as average word length: frequency of passives, adjectives and compound sentences, reading level, etc. WWB in turn offered writing advice based on such profiles. Style was stimulated by Bill Vesterman, a professor of English at Rutgers, who brought the idea to me. I introduced him to Lorinda, who had it running in a couple of weeks. Then Nina McDonald at USG conceived and packaged WWB as a distinct product, not just a collection of entries in man 1. Wikipedia reports a surmise that WWB sank out of sight because it was not a standard part of Unix distributions. Doug From tytso at mit.edu Wed Jan 12 08:14:46 2022 From: tytso at mit.edu (Theodore Ts'o) Date: Tue, 11 Jan 2022 17:14:46 -0500 Subject: [TUHS] Coastal cultures, collaboration, creativity and Sun vs DEC. In-Reply-To: References: Message-ID: On Wed, Jan 12, 2022 at 06:25:52AM +1000, George Michaelson wrote: > Bit of this in ietf too. Inner cohort of vint and similar background wear > three piece suits. > > Three: vest not optional. > > A west coast mob wear tie-dye tees. I can remember plenty of east coast IETF'ers (including for example, Jeff Schiller, the Security Area Director, who was based out of MIT and grew up in New York) sporting hot pick "Nerds in Paradise" T-shirts commerating the 15th IETF meeting held in Honolulu. Vint was very much the exception with his three-piece suit. I can't think of anyone else who would even wear a tie. - Ted From jpl.jpl at gmail.com Wed Jan 12 08:17:17 2022 From: jpl.jpl at gmail.com (John P. Linderman) Date: Tue, 11 Jan 2022 17:17:17 -0500 Subject: [TUHS] Coastal cultures, collaboration, creativity and Sun vs DEC. In-Reply-To: References: Message-ID: On Tue, Jan 11, 2022 at 3:45 PM Rob Pike wrote: Similar. Everyone at Bell Labs was so *proper*. (Except Ken, of course. > Ken is *sui generis*, and a Californian). > Perhaps (probably maybe) I misunderstand. There was nothing "proper" about the Peter face on the water tower, or lock-picking a boot to move it to a patrol car, of Scott Knaur wandering the halls in a Darth Vader costume, or Jellicat wearing a Cats costume, or a thousand other examples. There was a lot of playfulness in the Labs (at least in the early days), and I think it was wonderful. -------------- next part -------------- An HTML attachment was scrubbed... URL: From blake1024 at gmail.com Wed Jan 12 08:48:12 2022 From: blake1024 at gmail.com (Blake McBride) Date: Tue, 11 Jan 2022 16:48:12 -0600 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> Message-ID: On Mon, Jan 10, 2022 at 2:22 PM Jon Forrest wrote: > > TeX badly need an official rewrite in a modern programming language > (e.g. Go, Rust, even C). The rewrite should drop support for the > .dvi format, and use .pdf instead. It should also make use of > modern hardware capabilities and not have any built-in limits > to how much memory gets used. > > These issues are well recognized by the TeX community but with > Knuth not willing to be the BDFL, TeX is floundering. > > (I don't mean any of this as criticism of TeX. It's a truly > miraculous program that was created in a different time.) > > Jon > > Although I'm not connected with the TeX community, I don't agree with much of what you said. 1. TeX source to C is fine - stable and works. It would be impossible to rewrite TeX in any other language without introducing bugs and incompatibilities. Leaving TeX as-is means that it can be converted to other languages too if/when C goes out of style. TeX as-is is exactly what it is. Anything else wouldn't be TeX. 2. Drop DVI? Are you kidding me? Although PDF may be popular now, that may not be the case 20 years from now. A device-independent format is what is needed, and that's what DVI is. TeX is guaranteed to produce the exact same output 100 years from now. 3. I am curious about memory limitations within TeX. 4. Knuth is getting up in age. Someone will have to take over. I suppose #4 was my whole point about both TeX and troff. They're both great tools. Perhaps people used them in the past because there weren't many other solutions. You had to learn them. These days people prefer the simpler tools such as Word, OpenOffice, etc. Although they can't produce the same quality, they can produce sufficient quality with a smaller learning curve. Don't get me wrong, I despise Word. I just don't find my feelings echoed very much. Some things TeX and troff are going to need in order to continue: 1. Continue to be maintained 2. An effort to make knowledge of them wider will have to occur if they are to continue. 3. A case for their benefit will have to be made and dispersed. Blake McBride -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Wed Jan 12 09:02:32 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Tue, 11 Jan 2022 18:02:32 -0500 Subject: [TUHS] =?utf-8?q?=28no_subject=29?= Message-ID: > Ken and Dennis were teaching [the Votrax] to swear "Speak" being a phonetics-based program, I suspect they were exploring multiple spellings. Out of context, lots of spellings were indistinguishable. For example, cheap, cheat, cheek, chief was hard to tell from cheep, cheep, cheep, cheep.. At the risk of repeating myself, the fuck, fuck, fuck, fuck example came to the fore when a "speak" kiosk was installed at Epcot. PR folks were worried that people would try it on bad words in this public setting and asked me to block them. I said I'd block whatever words they told me to. Duly, I was sent a list--on the letterhead of an AT&T vice president. (Was that dictated to a secretary?) Later I heard that girls would often try friends' names, while boys would try bad words and exclaim that the machine didn't know them. In fact, those were among the few words the machine *did* know. Fortunately nobody ever complained that I hadn't blocked misspellings. Doug From andrew at humeweb.com Wed Jan 12 08:41:57 2022 From: andrew at humeweb.com (Andrew Hume) Date: Tue, 11 Jan 2022 14:41:57 -0800 Subject: [TUHS] Coastal cultures, collaboration, creativity and Sun vs DEC. In-Reply-To: References: Message-ID: i would add the general atmosphere of the Unix room, especially the very heavy mobile hung from the ceiling for a while (until someone noticed the cable supporting it was visibly stretching). also the bowling alley (the corridor that rob, ken, denis, doug and my offices were on) — the pins were under the printer table at the end. i also recall the time the bowling ball got away from the Unix room rolling down the main corridor towards a group of visitors led by peter weinberger. luckily, dave presotto grabbed the ball before anyone got hurt (but it was close). i would also mention labscam; its not often we see a prank involving rob pike, Penn and a Noble Prize winner. > On Jan 11, 2022, at 2:17 PM, John P. Linderman wrote: > > > > On Tue, Jan 11, 2022 at 3:45 PM Rob Pike > wrote: > > Similar. Everyone at Bell Labs was so proper. (Except Ken, of course. Ken is sui generis, and a Californian). > > Perhaps (probably maybe) I misunderstand. There was nothing "proper" about the Peter face on the water tower, or lock-picking a boot to move it to a patrol car, of Scott Knaur wandering the halls in a Darth Vader costume, or Jellicat wearing a Cats costume, or a thousand other examples. There was a lot of playfulness in the Labs (at least in the early days), and I think it was wonderful. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Wed Jan 12 09:18:00 2022 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 11 Jan 2022 15:18:00 -0800 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> Message-ID: <20220111231800.GD3441@mcvoy.com> On Tue, Jan 11, 2022 at 04:48:12PM -0600, Blake McBride wrote: > Some things TeX and troff are going to need in > order to continue: > > 1. Continue to be maintained > > 2. An effort to make knowledge of them wider will have to occur if they > are to continue. > > 3. A case for their benefit will have to be made and dispersed. Well, someone could do what I tried (and failed) to do: make Word produce high quality eqn/tbl/pic/troff source as their internal format. There was such a thing for TeX, can't remember the name, but my Dad (very computer not savvy) used it to write a book. It was WYSIWYG but spit out TeX. From imp at bsdimp.com Wed Jan 12 09:57:32 2022 From: imp at bsdimp.com (Warner Losh) Date: Tue, 11 Jan 2022 16:57:32 -0700 Subject: [TUHS] Demise of TeX and groff (was: roff(7)) In-Reply-To: References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> Message-ID: On Tue, Jan 11, 2022 at 1:08 PM Clem Cole wrote: > The AT&T case basically said that once the implementations was released, > AT&T could no longer call anything a trade secret, although they *do the > own the IP and copyright* > Not entirely true. There was a preliminary ruling that said that 32V might have lost its copyright protections because it was distributed outside of AT&T without proper copyright notices, as required by the pre-1980 copyright law. This detail was what caused AT&T to settle before it could become finalized (the preliminary ruling said there was a substantial likelihood that this would be the outcome, to be pedantic). To the extent that AT&T had complied with copyright laws requirements, they would retain their copyrights though. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Wed Jan 12 10:03:03 2022 From: imp at bsdimp.com (Warner Losh) Date: Tue, 11 Jan 2022 17:03:03 -0700 Subject: [TUHS] Demise of TeX and groff (was: roff(7)) In-Reply-To: References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> Message-ID: On Tue, Jan 11, 2022 at 4:57 PM Warner Losh wrote: > > > On Tue, Jan 11, 2022 at 1:08 PM Clem Cole wrote: > >> The AT&T case basically said that once the implementations was released, >> AT&T could no longer call anything a trade secret, although they *do the >> own the IP and copyright* >> > > Not entirely true. There was a preliminary ruling that said that 32V might > have lost its copyright protections because it was distributed outside of > AT&T without proper copyright notices, as required by the pre-1980 > copyright law. This detail was what caused AT&T to settle before it could > become finalized (the preliminary ruling said there was a substantial > likelihood that this would be the outcome, to be pedantic). To the extent > that AT&T had complied with copyright laws requirements, they would retain > their copyrights though. > See https://en.wikipedia.org/wiki/UNIX_System_Laboratories,_Inc._v._Berkeley_Software_Design,_Inc. for a summary (see Pretrial section) and http://sco.tuxrocks.com/Docs/USL/Doc-92.html for the ruling itself that discusses the details). "Consequently, I find that Plaintiff has failed to demonstrate a likelihood that it can successfully defend its copyright in 32V. Plaintiff's claims of copyright violations are not a basis for injunctive relief." being the appropriate quote. Plantif == USL. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Wed Jan 12 10:06:44 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Tue, 11 Jan 2022 16:06:44 -0800 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> Message-ID: <202201120006.20C06iEA2363576@darkstar.fourwinds.com> Blake McBride writes: > I suppose #4 was my whole point about both TeX and troff. They're both > great tools. Perhaps people used them in the past because there weren't > many other solutions. You had to learn them. These days people prefer the > simpler tools such as Word, OpenOffice, etc. Although they can't produce > the same quality, they can produce sufficient quality with a smaller > learning curve. Don't get me wrong, I despise Word. I just don't find my > feelings echoed very much. Some things TeX and troff are going to need in > order to continue: I disagree with your characterization that things like Word are simpler tools. They're way more complex than troff or TeX, both in code and usability. FYI, last time I saw Don he was asked what his biggest mistake ever was. His response was making the basic unit size in TeX a power of 2 instead of a power of 10. While I'm at it, a shill also asked him what his favorite joke was. His answer: A guy goes into the county clerk and asks to legally change his name. The clerk asks "What would you like to change it to?" The guy responds "Control G". The clerk says "That rings a bell." From robpike at gmail.com Wed Jan 12 10:15:15 2022 From: robpike at gmail.com (Rob Pike) Date: Wed, 12 Jan 2022 11:15:15 +1100 Subject: [TUHS] Coastal cultures, collaboration, creativity and Sun vs DEC. In-Reply-To: References: Message-ID: Yes, but most, if not all of things were after I arrived, among the first of a brace of fresh hot blood imported to grow 127. Things definitely felt looser by the mid-80s. Look, I'm not complaining. I absolutely loved working in the CS research group. But culturally, at least upon my arrival, I felt like a fish out of water. -rob On Wed, Jan 12, 2022 at 9:42 AM Andrew Hume wrote: > i would add the general atmosphere of the Unix room, especially the very > heavy mobile hung from > the ceiling for a while (until someone noticed the cable supporting it was > visibly stretching). > > also the bowling alley (the corridor that rob, ken, denis, doug and my > offices were on) — the pins > were under the printer table at the end. i also recall the time the > bowling ball got away from the > Unix room rolling down the main corridor towards a group of visitors led > by peter weinberger. > luckily, dave presotto grabbed the ball before anyone got hurt (but it was > close). > > i would also mention labscam; its not often we see a prank involving rob > pike, Penn and a Noble Prize winner. > > On Jan 11, 2022, at 2:17 PM, John P. Linderman wrote: > > > > On Tue, Jan 11, 2022 at 3:45 PM Rob Pike wrote: > > Similar. Everyone at Bell Labs was so *proper*. (Except Ken, of course. >> Ken is *sui generis*, and a Californian). >> > > Perhaps (probably maybe) I misunderstand. There was nothing "proper" about > the Peter face on the water tower, or lock-picking a boot to move it to a > patrol car, of Scott Knaur wandering the halls in a Darth Vader costume, or > Jellicat wearing a Cats costume, or a thousand other examples. There was a > lot of playfulness in the Labs (at least in the early days), and I think it > was wonderful. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cym224 at gmail.com Wed Jan 12 10:29:44 2022 From: cym224 at gmail.com (Nemo Nusquam) Date: Tue, 11 Jan 2022 19:29:44 -0500 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> Message-ID: An HTML attachment was scrubbed... URL: From cym224 at gmail.com Wed Jan 12 10:32:30 2022 From: cym224 at gmail.com (Nemo Nusquam) Date: Tue, 11 Jan 2022 19:32:30 -0500 Subject: [TUHS] Demise of TeX and groff (was: roff(7)) In-Reply-To: <20220111015901.GE25103@eureka.lemis.com> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> Message-ID: On 2022-01-10 20:59, Greg 'groggy' Lehey wrote (in part): > As long as man pages are formatted with ?roff, I don't see it going > away. I don't suppose many people use troff any more, but there are > enough of us, and as long as man pages stay the way they are, I don't > think we're in any danger. Macos ships with *roff. N. From nobozo at gmail.com Wed Jan 12 10:44:48 2022 From: nobozo at gmail.com (Jon Forrest) Date: Tue, 11 Jan 2022 16:44:48 -0800 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: References: Message-ID: <250868b3-9e0c-5ff2-8506-e2da5c73862a@gmail.com> This is clearly getting off track of TUHS. I'll stop after this reply. > *From:* Blake McBride > *Date:* January 11, 2022 at 2:48:23 PM PST > *To:* Jon Forrest > *Cc:* TUHS main list > *Subject:* *[TUHS] TeX and groff (was: roff(7))* > Although I'm not connected with the TeX community, I don't agree with > much of what you said. > > 1. TeX source to C is fine - stable and works. It would be > impossible to rewrite TeX in any other language without introducing > bugs and incompatibilities. Leaving TeX as-is means that it can be > converted to other languages too if/when C goes out of style. TeX > as-is is exactly what it is. Anything else wouldn't be TeX. I agree that Web->C works but it's a major obstacle in doing any development work on TeX. Try making a major change in the Web source that requires debugging. Anything that can pass the TeX Trip Test can be called TeX. I know of a full C reimplementation that passes the test but the author doesn't want to make it free software. There are other rewrites out there that could be candidates but someone will enough power will have to proclaim one as the official TeX alternative. > 2. Drop DVI? Are you kidding me? Although PDF may be popular now, > that may not be the case 20 years from now. A device-independent > format is what is needed, and that's what DVI is. TeX is guaranteed > to produce the exact same output 100 years from now. And .PDF isn't? .DVI was great until .PDF matured. .DVI has almost no penetration these days, whereas .PDF is everywhere. I'm not saying that .PDF will always be the proper alternative but a properly rewritten TeX should make it much easier to replace .PDF will whatever comes next. > 3. I am curious about memory limitations within TeX. TeX has various fixed sized memory pools, and contains clever code to work around limited memory. Some of the newer TeXs, like LuaTeX, use dynamic allocation but this isn't official. Given how primitive things were when TeX was developed it's a miracle it works as well as it does. > 4. Knuth is getting up in age. Someone will have to take over. Exactly. I don't follow the TeX community so I don't know what they're doing about this. Jon Forrest From mah at mhorton.net Wed Jan 12 11:19:04 2022 From: mah at mhorton.net (Mary Ann Horton) Date: Tue, 11 Jan 2022 17:19:04 -0800 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: <20220110203300.GY3441@mcvoy.com> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220110203300.GY3441@mcvoy.com> Message-ID: <695e2970-00f2-ab55-8c1a-9fbd03add77f@mhorton.net> I recall attending a TeX lecture by Knuth around 1981. He said he wasn't satisfied with the character layout from other formatting programs, which drove him to write TeX. He illustrated in great detail the kerning and exact placement of the font characters next to each other. I couldn't tell the difference, but clearly it was very important to him. He wanted his documents to look perfect. On 1/10/22 12:33 PM, Larry McVoy wrote: > On Mon, Jan 10, 2022 at 01:00:15PM -0600, Blake McBride wrote: >> 2. Looking at the output, it is my opinion that TeX produces >> better-looking documents. > It's a double edged sword. TeX looks better but you instantly know it is > TeX, it has a particular look. Troff looks just fine to me, and you don't > know it is Troff, Word, or what. From dave at horsfall.org Wed Jan 12 11:19:36 2022 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 12 Jan 2022 12:19:36 +1100 (EST) Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: <20220111231800.GD3441@mcvoy.com> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220111231800.GD3441@mcvoy.com> Message-ID: On Tue, 11 Jan 2022, Larry McVoy wrote: > Well, someone could do what I tried (and failed) to do: make Word > produce high quality eqn/tbl/pic/troff source as their internal format. I doubt whether that will ever happen; M$ like to keep their internal format proprietary (and apparently change it with each release) to keep third-parties out. -- Dave From blake1024 at gmail.com Wed Jan 12 11:46:43 2022 From: blake1024 at gmail.com (Blake McBride) Date: Tue, 11 Jan 2022 19:46:43 -0600 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: <20220111231800.GD3441@mcvoy.com> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220111231800.GD3441@mcvoy.com> Message-ID: On Tue, Jan 11, 2022 at 5:18 PM Larry McVoy wrote: > On Tue, Jan 11, 2022 at 04:48:12PM -0600, Blake McBride wrote: > > 3. A case for their benefit will have to be made and dispersed. > > Well, someone could do what I tried (and failed) to do: make Word > produce high quality eqn/tbl/pic/troff source as their internal > format. > As I said earlier, I despise Word for many reasons. I think making Word, or any proprietary software, do anything as, in the long haul, a waste of time. > > There was such a thing for TeX, can't remember the name, but my > Dad (very computer not savvy) used it to write a book. It was > WYSIWYG but spit out TeX. > Probably LyX . I use it frequently. Blake McBride -------------- next part -------------- An HTML attachment was scrubbed... URL: From blake1024 at gmail.com Wed Jan 12 11:48:26 2022 From: blake1024 at gmail.com (Blake McBride) Date: Tue, 11 Jan 2022 19:48:26 -0600 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: <202201120006.20C06iEA2363576@darkstar.fourwinds.com> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <202201120006.20C06iEA2363576@darkstar.fourwinds.com> Message-ID: On Tue, Jan 11, 2022 at 6:07 PM Jon Steinhart wrote: > Blake McBride writes: > > I suppose #4 was my whole point about both TeX and troff. They're both > > great tools. Perhaps people used them in the past because there weren't > > many other solutions. You had to learn them. These days people prefer > the > > simpler tools such as Word, OpenOffice, etc. Although they can't produce > > the same quality, they can produce sufficient quality with a smaller > > learning curve. Don't get me wrong, I despise Word. I just don't find > my > > feelings echoed very much. Some things TeX and troff are going to need > in > > order to continue: > > I disagree with your characterization that things like Word are simpler > tools. > They're way more complex than troff or TeX, both in code and usability. > We'll have to agree to disagree. --blake -------------- next part -------------- An HTML attachment was scrubbed... URL: From blake1024 at gmail.com Wed Jan 12 11:53:00 2022 From: blake1024 at gmail.com (Blake McBride) Date: Tue, 11 Jan 2022 19:53:00 -0600 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> Message-ID: On Tue, Jan 11, 2022 at 6:30 PM Nemo Nusquam wrote: > On 2022-01-11 17:48, Blake McBride wrote (in part): > > > 4. Knuth is getting up in age. Someone will have to take over. > > > Someone has: https://www.latex-project.org/latex3/ > Although that page talks about LaTeX (a macro package) a lot, it doesn't mention support for TeX (the actual processor). Tex is like troff LaTeX is like mm or ms Blake McBride -------------- next part -------------- An HTML attachment was scrubbed... URL: From blake1024 at gmail.com Wed Jan 12 12:00:58 2022 From: blake1024 at gmail.com (Blake McBride) Date: Tue, 11 Jan 2022 20:00:58 -0600 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: <250868b3-9e0c-5ff2-8506-e2da5c73862a@gmail.com> References: <250868b3-9e0c-5ff2-8506-e2da5c73862a@gmail.com> Message-ID: On Tue, Jan 11, 2022 at 6:45 PM Jon Forrest wrote: > I know of > a full C reimplementation that passes the test but the author doesn't > want to make it free software. > Although it is possible, I find this hard to believe. I can't imagine spending as much time as would be required to duplicate something that already exists. > > There are other rewrites out there that could be candidates but someone > will enough power will have to proclaim one as the official TeX > alternative. > Again, hard to believe. > > > 2. Drop DVI? Are you kidding me? Although PDF may be popular now, > > that may not be the case 20 years from now. A device-independent > > format is what is needed, and that's what DVI is. TeX is guaranteed > > to produce the exact same output 100 years from now. > > And .PDF isn't? > No. It isn't. It is an Adobe product. > > .DVI was great until .PDF matured. .DVI has almost no penetration > these days, whereas .PDF is everywhere. DVI was never meant to have any penetration. It was always intended to be an intermediary format. > I'm not saying that .PDF > will always be the proper alternative but a properly rewritten TeX > should make it much easier to replace .PDF will whatever comes > next. > Again, given the complexity of a proper TeX, and its declining popularity, I find it ver hard to believe that someone would spend the time to duplicate, with enhancements, it. Blake McBride -------------- next part -------------- An HTML attachment was scrubbed... URL: From blake1024 at gmail.com Wed Jan 12 12:03:53 2022 From: blake1024 at gmail.com (Blake McBride) Date: Tue, 11 Jan 2022 20:03:53 -0600 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: <695e2970-00f2-ab55-8c1a-9fbd03add77f@mhorton.net> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220110203300.GY3441@mcvoy.com> <695e2970-00f2-ab55-8c1a-9fbd03add77f@mhorton.net> Message-ID: On Tue, Jan 11, 2022 at 7:20 PM Mary Ann Horton wrote: > I recall attending a TeX lecture by Knuth around 1981. He said he wasn't > satisfied with the character layout from other formatting programs, > which drove him to write TeX. He illustrated in great detail the kerning > and exact placement of the font characters next to each other. I > couldn't tell the difference, but clearly it was very important to him. > He wanted his documents to look perfect. > Yes! That goes to one of my original points. While it is true that CM fonts have a particular look that may be interpreted as "better", there is a lot more to it. Blake McBride -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Wed Jan 12 12:10:59 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Tue, 11 Jan 2022 18:10:59 -0800 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: <695e2970-00f2-ab55-8c1a-9fbd03add77f@mhorton.net> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220110203300.GY3441@mcvoy.com> <695e2970-00f2-ab55-8c1a-9fbd03add77f@mhorton.net> Message-ID: <69B0EA6A-3B99-4555-AD08-F67FAF52A818@iitbombay.org> Don Knuth talks at length about how TeX & MetaFont came about etc. in his Web of Stories interview in parts 50 through 70. In Part 56 he does say he looked at "the system developed at Bell Labs", presumably troff. In part 68 he talks about the importance of stability fot TeX and later talks about LaTeX and ConTeXt. https://www.youtube.com/watch?v=UzqhuWBClcM&list=PLVV0r6CmEsFzeNLngr1JqyQki3wdoGrCn&index=56 I must say I am a fan of TeX/LaTeX and not a fan of nroff/troff -- I don't like the troff look and I don't like the markup. The nice thing is we can choose whatever typesetting tools we want! I played with other alternatives such as lout and Sile but didn't like them all that much. I immediately liked the TeX's model of boxes and glue. I like the fact that I can typeset Indic language text beautifully. But like any complex tool, you have to take time to learn it and practice to get proficient at it. At the same time I am not a fan of the way Knuth does literate programming. What I'd like is a two view editor where I can jump from code to related documentation and vice versa. And when you're working on one, the related part in the other view highlighted. In this world I don't want to deal with files and directories -- just one virtual document, however it is stored put under version control! > On Jan 11, 2022, at 5:19 PM, Mary Ann Horton wrote: > > I recall attending a TeX lecture by Knuth around 1981. He said he wasn't satisfied with the character layout from other formatting programs, which drove him to write TeX. He illustrated in great detail the kerning and exact placement of the font characters next to each other. I couldn't tell the difference, but clearly it was very important to him. He wanted his documents to look perfect. > > On 1/10/22 12:33 PM, Larry McVoy wrote: >> On Mon, Jan 10, 2022 at 01:00:15PM -0600, Blake McBride wrote: >>> 2. Looking at the output, it is my opinion that TeX produces >>> better-looking documents. >> It's a double edged sword. TeX looks better but you instantly know it is >> TeX, it has a particular look. Troff looks just fine to me, and you don't >> know it is Troff, Word, or what. From bakul at iitbombay.org Wed Jan 12 12:12:45 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Tue, 11 Jan 2022 18:12:45 -0800 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: <20220111231800.GD3441@mcvoy.com> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220111231800.GD3441@mcvoy.com> Message-ID: <2E9F5F9E-FD83-4B9D-B2B9-E48FF293A7AC@iitbombay.org> > On Jan 11, 2022, at 3:18 PM, Larry McVoy wrote: > > On Tue, Jan 11, 2022 at 04:48:12PM -0600, Blake McBride wrote: >> Some things TeX and troff are going to need in >> order to continue: >> >> 1. Continue to be maintained >> >> 2. An effort to make knowledge of them wider will have to occur if they >> are to continue. >> >> 3. A case for their benefit will have to be made and dispersed. > > Well, someone could do what I tried (and failed) to do: make Word > produce high quality eqn/tbl/pic/troff source as their internal > format. > > There was such a thing for TeX, can't remember the name, but my > Dad (very computer not savvy) used it to write a book. It was > WYSIWYG but spit out TeX. May be Textures by Blue Sky Research? From davida at pobox.com Wed Jan 12 12:10:44 2022 From: davida at pobox.com (David Arnold) Date: Wed, 12 Jan 2022 13:10:44 +1100 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: References: Message-ID: <02982C6D-0DF6-4C45-985F-9B3060DF1125@pobox.com> <…> >> > 2. Drop DVI? Are you kidding me? Although PDF may be popular now, >> > that may not be the case 20 years from now. A device-independent >> > format is what is needed, and that's what DVI is. TeX is guaranteed >> > to produce the exact same output 100 years from now. >> >> And .PDF isn't? > > No. It isn't. It is an Adobe product. Check out ISO 32000-2:2020. I think it’s ok in 2022 to say that PDF has escaped Adobe and is an open standard, suitable for long-life documents, etc. d -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Wed Jan 12 12:26:21 2022 From: athornton at gmail.com (Adam Thornton) Date: Tue, 11 Jan 2022 19:26:21 -0700 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: <02982C6D-0DF6-4C45-985F-9B3060DF1125@pobox.com> References: <02982C6D-0DF6-4C45-985F-9B3060DF1125@pobox.com> Message-ID: Knuth made an excellent point, maybe in _Coders At Work_ about literate programming and why it didn't catch on: in general, about 1 out of 20 people can be a really good programmer. In general, one of 20 people can be a really good writer. These talents are largely uncorrelated. Sure, being competent at either is a teachable skill. But no one wants to read either a program or a narrative written by someone who's merely OK at it. Adam On Tue, Jan 11, 2022 at 7:20 PM David Arnold wrote: > <…> > > > 2. Drop DVI? Are you kidding me? Although PDF may be popular now, >> > that may not be the case 20 years from now. A device-independent >> > format is what is needed, and that's what DVI is. TeX is guaranteed >> > to produce the exact same output 100 years from now. >> >> And .PDF isn't? >> > > No. It isn't. It is an Adobe product. > > > Check out ISO 32000-2:2020. > > I think it’s ok in 2022 to say that PDF has escaped Adobe and is an open > standard, suitable for long-life documents, etc. > > > > d > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Wed Jan 12 12:49:40 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Tue, 11 Jan 2022 18:49:40 -0800 Subject: [TUHS] TeX and groff (was: roff(7)) Message-ID: <202201120249.20C2nfst2370834@darkstar.fourwinds.com> Been reading the heirloom docs. Remember one thing that I disliked about troff which maybe Doug can explain. It's the language in the docs. I never understood "interpolating a register" to have any relation to the definition of interpolate that I learned in math. Made it a bit hard to learn initially. Any memory of why that term was used? From douglas.mcilroy at dartmouth.edu Wed Jan 12 13:38:56 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Tue, 11 Jan 2022 22:38:56 -0500 Subject: [TUHS] Coastal cultures, collaboration, creativity and Sun vs DEC Message-ID: > most, if not all of these things were after I arrived. That may indicate the youth of the narrator more than a lightening of the culture. Some practical jokes and counter-culture customs from an earlier day: When I joined the Labs, everyone talked about the escapades of Claude Shannon and Dave Hagelbarger--unicycle, outguessing machines, the finger-on-the-switch box, etc. When John Kelly became a department head he refused to have his office carpeted. That would have kept him from stubbing out cigarettes on the floor. Bill Baker may have worn a coat and tie, but he kept a jalopy in his VP parking space. Another employee had a rusty vehicle with weeds growing out of the fenders. As early as 1960 BESYS began appending fortune cookies to every printout. The counter where printouts were delivered got messed up by people pawing around to see others' fortunes. One day the audio monitor on the low bit of the 7090 accumulator stopped producing white noise (with an occasional screech for an infinite loop) and intoned in aTexas drawl, "Help, I'm caught in a loop. Help. I'm caught in a loop. Help ..." A pixelated nude mural appeared in Ed David's office. (Maybe this no longer counts as a prank. It is now regarded as a foundational event in computer art.) Ed Gilbert had a four-drawer filing cabinet labeled integers, rationals, reals, and balloon. The latter held the tattered remains of lunchtime hot-air experiments. He also had a chalkboard globe with a world map on it. It sometimes took several spins before a visitor realized that you really shouldn't be able to see all the continents at once--the map appeared twice around the circumference of the globe. CS had a Gilbert-and-Sullivan duo, Mike Lesk and Peter Neumann, who produced original entertainment for department parties. Doug From crossd at gmail.com Wed Jan 12 13:44:43 2022 From: crossd at gmail.com (Dan Cross) Date: Tue, 11 Jan 2022 22:44:43 -0500 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: <69B0EA6A-3B99-4555-AD08-F67FAF52A818@iitbombay.org> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220110203300.GY3441@mcvoy.com> <695e2970-00f2-ab55-8c1a-9fbd03add77f@mhorton.net> <69B0EA6A-3B99-4555-AD08-F67FAF52A818@iitbombay.org> Message-ID: On Tue, Jan 11, 2022 at 9:11 PM Bakul Shah wrote: > Don Knuth talks at length about how TeX & MetaFont came about etc. in his Web of Stories interview in parts 50 through 70. In Part 56 he does say he looked at "the system developed at Bell Labs", presumably troff. Among the Bell Labs technical reports I read when I was younger, a trilogy by MD McIlroy on the challenges drawing ellipses stand out: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.49.3440&rep=rep1&type=pdf These stuck in my mind and some relatively short time later, I read how the analogous problem was approached in TeX. The solution there was to treat the shape as if it were drawn using a pen with a diamond-shaped nib. From the MetaFont book: Similarly, some diagonal lines of slope~1 digitize to be twice as dark as others, when a truly circular pen is considered. But the diamond-shaped nib that \MF\ uses for a pencircle of diameter~1 does not have this defect; all straight lines of the same slope will digitize to lines of uniform darkness. Moreover, curved lines drawn with the diamond nib always yield one pixel per column when they move more-or-less horizontally (with slopes between $+1$ and $-1$), and they always yield one pixel per row when they move vertically. By contrast, the outlines of curves drawn with circular pens produce occasional ``blots.'' Circles and ellipses of all diameters can profitably be replaced by polygons whose sub-pixel corrections to the ideal shape will produce better digitizations; \MF\ does this in accordance with the interesting theory developed by John~D. ^{Hobby} in his Ph.D. dissertation (Stanford University, 1985). If I can be so bold as to offer an interpretation: Doug's approximations treat ellipses as mathematical objects and algorithmically determine what pixels are closest to points on the infinitesimally-thin curves, while Knuth's (or one his students') method acknowledges that the curve has a width defined by the nib; any "pixel" the nib touches becomes part of the figure. Perhaps I'm wrong on the details, but it hardly matters; my point is that there was clearly interesting work done in the area in both places. I find it impossible that neither Knuth nor Hobby were unaware of McIlroy's work and vice-versa; of course he would have known about and examined troff just as the Bell Labs folks knew about TeX. These were hot areas of practical research! This is also a good reminder that not only was Unix itself a subject of research, but it supported a lot of other research at Bell Labs and elsewhere. On this list, we tend to focus on the tool, but that tool was put to use building many more things as well. > [snip] > I must say I am a fan of TeX/LaTeX and not a fan of nroff/troff -- I don't like the troff look and I don't like the markup. I've always admired the look of troff. I wonder if, in retrospect, that is due to me mentally tying the presentation with so many formative documents that were strong early influences. Similarly, I love the look of Tex (even the CM fonts). They are of course different, but I find each beautiful in different ways. > The nice thing is we can choose whatever typesetting tools we want! This! - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Wed Jan 12 18:48:58 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 12 Jan 2022 01:48:58 -0700 Subject: [TUHS] Demise of TeX and groff (was: roff(7)) In-Reply-To: References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> Message-ID: <202201120848.20C8mw6i013659@freefriends.org> Clem Cole wrote: > Beyond base duplication, numerous companies published parts of them and in > particular parts if not all of the roff manual. For instance, a firm in > Seattle called CSSC published a number of reference guides and use guides > based on them You mean "SSC" - Specialized Systems Consultants. I did work for them in the 90s and they started Linux Journal, for which I wrote a few articles early on. The main guy there, Phil Hughes, was an interesting person. After getting rich from LJ he dropped out and moved to Central or South America. CSSC is the GNU project's reimplimentation of SCCS, to which, I believe, Larry contributed. Arnold From arnold at skeeve.com Wed Jan 12 18:54:13 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 12 Jan 2022 01:54:13 -0700 Subject: [TUHS] Demise of TeX and groff (was: roff(7)) In-Reply-To: References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> Message-ID: <202201120854.20C8sDRR014233@freefriends.org> Clem, Once again, you have the timeline wrong on all this. The ditroff work was started in the summer of 1979, well after V6, Typesetter C and V7. Details are available at https://www.cs.princeton.edu/~bwk/202/202paper.pdf and https://www.cs.princeton.edu/~bwk/202/summer.reconstructed.pdf. Perhaps Doug can set the history straight on troff. Here is my understanding, corrections (from Doug) welcome: - Ossanna wrote the original nroff in assembly language - He rewrote it in C when the C/A/T was acquired At that time nroff/troff were built from mostly the same sources (as can be seen in the archives). Thanks, Arnold Clem Cole wrote: > After Joe died and the BTL crew got a new APS5 typesetter, Brian set out to > rewrite the code base to support any typesetting by using traditional > compiler technology of converting the input to an ASCII representation that > is walked by a seperate program that generates the device specific output. > In fact it was this work (original done on V6) that forced Dennis (and I > assume Steve Johnson) to update the C language a bit - which is what is > described in K&R1. Brian's code and a version of DMR's updated C compiler > was released independently as a package - hence the term 'typesetter C.' > This compiler and the new document system took a seperate license. I had > it at both CMU in the 70s and Tektronix -- I think Steve Glaser had it at > Rice also - again ask someone else for other sites, including some of the > early European ones. > > Later Brian's work was updated after V7 and included some new tools, and > became known as Writer's Workbench, which eventually was entered in the > 'toolchest.' > > At the time of the first release Brian published a paper / TR that > describes the new version of troff (a.ka. ditroff), including some level of > documentation for the intermediate language. That was published and would > have been officially available to James. From ralph at inputplus.co.uk Wed Jan 12 20:38:23 2022 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Wed, 12 Jan 2022 10:38:23 +0000 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: <202201120249.20C2nfst2370834@darkstar.fourwinds.com> References: <202201120249.20C2nfst2370834@darkstar.fourwinds.com> Message-ID: <20220112103823.A4DCB1F939@orac.inputplus.co.uk> Hi Jon, > I never understood "interpolating a register" to have any relation to > the definition of interpolate that I learned in math. The first definition makes sense of it: 1. (transitive, intransitive) To introduce (something) between other things; especially to insert (possibly spurious) words into a text. in verse 74, the second line is clearly interpolated 2. (mathematics) To estimate the value of a function between two tabulated points. 3. (computing) During the course of processing some data, and in response to a directive in that data, to fetch data from a different source and process it in-line along with the original data. ― https://en.wiktionary.org/wiki/interpolate -- Cheers, Ralph. From arnold at skeeve.com Wed Jan 12 22:58:25 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 12 Jan 2022 05:58:25 -0700 Subject: [TUHS] struct(1) revived! And a request for help Message-ID: <202201121258.20CCwPEF013323@freefriends.org> Hello All. We recently discussed Brenda Baker's struct program, that read Fortran and generated Ratfor. Many of us remarked as to what a really cool program it was and how much we admired it, myself included. For fun (for some definition of "fun") I decided to try to bring the code into the present. I set up a GitHub repo with the V7, V8 and V10 code, and then started work in a separate branch. (https://github.com/arnoldrobbins/struct, branch "modernize".) The program has three main parts: - structure, which reads Fortran and outputs something that is almost Ratfor on standard output. - beautify, which reads the output of structure and finishes the job, primarily making conditions readable (.not. --> !, removing double negatives, etc.) - struct.sh - a simple shell script that runs the above two components. This is what the user invokes. The code was written in 1974. As such, it is rife with "type punning" between int, int *, int **, and char *. These produce a lot of warnings from a modern day C compiler. The code also uses a, er, "unique" bracing style, making it nearly illegible to my stuck-in-a-rut programming brain. Here is what I've accomplished so far: * Converted every function definition and declaration to use modern (ANSI) C style, adding a header file with function declarations that is included everywhere. * Run all the code through the indent program, formatting it as traditional K&R bracing style, with tabs. * Fixed some macros to use modern style for getting parameter values as strings into the macros. * Fixed a few small bugs here and there. * Fixed beautify to work with modern byacc/bison (%union) and to work with flex instead of lex. This latter was a challenge. In structure, only three files still generate warnings, but they all relate to integer <--> pointer assignment / use as. However, when compiled in 32 bit mode (gcc -m32), where sizeof(int) is the same as sizeof(pointer), despite the warnings, structure works!! Beautify works, whether compiled in 32 or 64 bit mode. What I've done so far has been mostly mechanical. I hereby request help from anyone who's interested in making progress on "the hard part" --- those three files that still generate warnings. I think the right way to go is to replace int's with a union that holds and int, a char* and an int*. But I have not had the quiet time to dive into the code to see if this can be done. Anyone who has some time to devote to this and is interested, please drop me a note off-list. Thanks, Arnold Robbins From clemc at ccc.com Thu Jan 13 01:17:12 2022 From: clemc at ccc.com (Clem Cole) Date: Wed, 12 Jan 2022 10:17:12 -0500 Subject: [TUHS] Demise of TeX and groff (was: roff(7)) In-Reply-To: <202201120854.20C8sDRR014233@freefriends.org> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> <202201120854.20C8sDRR014233@freefriends.org> Message-ID: On Wed, Jan 12, 2022 at 3:54 AM wrote: > > - Ossanna wrote the original nroff in assembly language > - He rewrote it in C when the C/A/T was acquired > At that time nroff/troff were built from mostly the same sources (as > can be seen in the archives). > That is also my understanding. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Thu Jan 13 01:49:58 2022 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 12 Jan 2022 07:49:58 -0800 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: <2E9F5F9E-FD83-4B9D-B2B9-E48FF293A7AC@iitbombay.org> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220111231800.GD3441@mcvoy.com> <2E9F5F9E-FD83-4B9D-B2B9-E48FF293A7AC@iitbombay.org> Message-ID: <20220112154958.GM7175@mcvoy.com> On Tue, Jan 11, 2022 at 06:12:45PM -0800, Bakul Shah wrote: > > > > On Jan 11, 2022, at 3:18 PM, Larry McVoy wrote: > > > > On Tue, Jan 11, 2022 at 04:48:12PM -0600, Blake McBride wrote: > >> Some things TeX and troff are going to need in > >> order to continue: > >> > >> 1. Continue to be maintained > >> > >> 2. An effort to make knowledge of them wider will have to occur if they > >> are to continue. > >> > >> 3. A case for their benefit will have to be made and dispersed. > > > > Well, someone could do what I tried (and failed) to do: make Word > > produce high quality eqn/tbl/pic/troff source as their internal > > format. > > > > There was such a thing for TeX, can't remember the name, but my > > Dad (very computer not savvy) used it to write a book. It was > > WYSIWYG but spit out TeX. > > May be Textures by Blue Sky Research? That's it. From lm at mcvoy.com Thu Jan 13 01:51:41 2022 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 12 Jan 2022 07:51:41 -0800 Subject: [TUHS] Demise of TeX and groff (was: roff(7)) In-Reply-To: <202201120848.20C8mw6i013659@freefriends.org> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> <202201120848.20C8mw6i013659@freefriends.org> Message-ID: <20220112155141.GN7175@mcvoy.com> On Wed, Jan 12, 2022 at 01:48:58AM -0700, arnold at skeeve.com wrote: > CSSC is the GNU project's reimplimentation of SCCS, to which, I believe, > Larry contributed. Only in some very minor ways, the author and I chatted and I cleared up some of his thinking. With all due respect to him, I wasn't impressed with the source base, it was C++ (I think) and slow (I know). From clemc at ccc.com Thu Jan 13 01:56:15 2022 From: clemc at ccc.com (Clem Cole) Date: Wed, 12 Jan 2022 10:56:15 -0500 Subject: [TUHS] Demise of TeX and groff (was: roff(7)) In-Reply-To: <202201120848.20C8mw6i013659@freefriends.org> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> <202201120848.20C8mw6i013659@freefriends.org> Message-ID: Yes -- thank you. Dyslexia-r-me On Wed, Jan 12, 2022 at 3:49 AM wrote: > Clem Cole wrote: > > > Beyond base duplication, numerous companies published parts of them and > in > > particular parts if not all of the roff manual. For instance, a firm in > > Seattle called CSSC published a number of reference guides and use guides > > based on them > > You mean "SSC" - Specialized Systems Consultants. I did work for them > in the 90s and they started Linux Journal, for which I wrote a few articles > early on. The main guy there, Phil Hughes, was an interesting person. > After getting rich from LJ he dropped out and moved to Central or South > America. > > CSSC is the GNU project's reimplimentation of SCCS, to which, I believe, > Larry contributed. > > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Jan 13 01:57:45 2022 From: clemc at ccc.com (Clem Cole) Date: Wed, 12 Jan 2022 10:57:45 -0500 Subject: [TUHS] Demise of TeX and groff (was: roff(7)) In-Reply-To: <20220112155141.GN7175@mcvoy.com> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> <202201120848.20C8mw6i013659@freefriends.org> <20220112155141.GN7175@mcvoy.com> Message-ID: On Wed, Jan 12, 2022 at 10:51 AM Larry McVoy wrote: > On Wed, Jan 12, 2022 at 01:48:58AM -0700, arnold at skeeve.com wrote: > > CSSC is the GNU project's reimplimentation of SCCS, to which, I believe, > > Larry contributed. > > Only in some very minor ways, the author and I chatted and I cleared up > some of his thinking. With all due respect to him, I wasn't impressed > with the source base, it was C++ (I think) and slow (I know). > And IIRC, no man pages either ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Thu Jan 13 02:22:30 2022 From: athornton at gmail.com (Adam Thornton) Date: Wed, 12 Jan 2022 09:22:30 -0700 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: <20220112154958.GM7175@mcvoy.com> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220111231800.GD3441@mcvoy.com> <2E9F5F9E-FD83-4B9D-B2B9-E48FF293A7AC@iitbombay.org> <20220112154958.GM7175@mcvoy.com> Message-ID: > On Jan 12, 2022, at 8:49 AM, Larry McVoy wrote: > > On Tue, Jan 11, 2022 at 06:12:45PM -0800, Bakul Shah wrote: >> >> >>> On Jan 11, 2022, at 3:18 PM, Larry McVoy wrote: >>> >>> There was such a thing for TeX, can't remember the name, but my >>> Dad (very computer not savvy) used it to write a book. It was >>> WYSIWYG but spit out TeX. >> >> May be Textures by Blue Sky Research? > > That's it. LyX is a venerable and not entirely unsuccessful attempt to put a WYSIWYG front end on LaTeX. Every few years I try to use it and then go back to something else. From crossd at gmail.com Thu Jan 13 02:33:35 2022 From: crossd at gmail.com (Dan Cross) Date: Wed, 12 Jan 2022 11:33:35 -0500 Subject: [TUHS] Demise of TeX and groff (was: roff(7)) In-Reply-To: <202201120854.20C8sDRR014233@freefriends.org> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> <202201120854.20C8sDRR014233@freefriends.org> Message-ID: On Wed, Jan 12, 2022 at 3:55 AM wrote: > [snip] > Perhaps Doug can set the history straight on troff. Here is my > understanding, > corrections (from Doug) welcome: > > - Ossanna wrote the original nroff in assembly language > - He rewrote it in C when the C/A/T was acquired > At that time nroff/troff were built from mostly the same sources (as > can be seen in the archives). > I have some questions about the earlier history. As I understand it, in the beginning there was RUNOFF, which I believe originated on CTSS? The CTSS sources contain a RUNOFF program that's made up of ~1100 lines of MAD and ~1300 lines of assembler. There is certainly a RUNOFF in Multics, written in BCPL (there's a small "outer module transfer vector" program in ALM). This is where it gets muddy for me; I understand this was roughly ported to unix as `roff` by Ken and that at this point, formatting was fairly primitive: suitable for hardcopy terminals and line printers, and could do things like center lines and so forth, but nothing fancy (https://www.cs.dartmouth.edu/~doug/reader.pdf). Ossanna then took over and greatly expanded the capabilities of `roff`, adding macros and traps and making it Turing-complete; this was `nroff`, which grew to become `troff` once the C/A/T typesetter was acquired. Section 4.1 ("Text Processing") of Doug's "Research Unix Reader" above includes some tantalizing tidbits, particularly this, regarding `troff`: "It blew the manufacturer’s mind, and touched off a flurry of homemade documents in flamboyant layouts—good enough, however, to fool referees into suspecting that the manuscripts had been published before." Ooo, that last bit sounds like a good story! Doug, can you tell us more? - Dan C. PS: Something came up on the Multics mailing list recently that may be of local interest. Someone was looking for a set of troff macros used internally by Honeywell for the preparation of technical documentation and memoranda and it was asked whether this had been done on Multics? Apparently, `troff` never made it back to its ancestor's home, even though at some point circa the SVR2 era a C compiler was ported and it would have been, perhaps, possible. The answer to the original question was that that documentation had been prepared on a Unix machine of some kind; the macros seem lost to time. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Thu Jan 13 02:48:35 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 12 Jan 2022 17:48:35 +0100 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: <695e2970-00f2-ab55-8c1a-9fbd03add77f@mhorton.net> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220110203300.GY3441@mcvoy.com> <695e2970-00f2-ab55-8c1a-9fbd03add77f@mhorton.net> Message-ID: <20220112164835.Kj4fy%steffen@sdaoden.eu> Mary Ann Horton wrote in <695e2970-00f2-ab55-8c1a-9fbd03add77f at mhorton.net>: |I recall attending a TeX lecture by Knuth around 1981. He said he wasn't |satisfied with the character layout from other formatting programs, |which drove him to write TeX. He illustrated in great detail the kerning |and exact placement of the font characters next to each other. I |couldn't tell the difference, but clearly it was very important to him. |He wanted his documents to look perfect. I find with proof-reading roff provides very pleasant results; the german translation of K&R Programming in C (2nd Ed., ANSI C; so many credits to people on this list!!!) was produced in roff (Liangs hyphenation, Kernighans pic, Lesks tbl, Kernighan and Cherrys eqn, XENIX-adjusted d-i troff of ELAN; November 1989), it could not look better. I personally feel peeved when my documents do not look acceptable, but, other than that, from computer documents i do miss the spiritual, the contemplative and meditative side that calligraphically beautiful documents represent. Just recently for example a Thora that was saved from the flames reappeared here in Germany, it would be yet another massive loss of culture if this became binary or quantum. --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 jon at fourwinds.com Thu Jan 13 03:53:28 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Wed, 12 Jan 2022 09:53:28 -0800 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: <20220112103823.A4DCB1F939@orac.inputplus.co.uk> References: <202201120249.20C2nfst2370834@darkstar.fourwinds.com> <20220112103823.A4DCB1F939@orac.inputplus.co.uk> Message-ID: <202201121753.20CHrSDp2410765@darkstar.fourwinds.com> Ralph Corderoy writes: > Hi Jon, > > > I never understood "interpolating a register" to have any relation to > > the definition of interpolate that I learned in math. > > The first definition makes sense of it: > > 1. (transitive, intransitive) To introduce (something) between other > things; especially to insert (possibly spurious) words into a text. > > in verse 74, the second line is clearly interpolated > > 2. (mathematics) To estimate the value of a function between two > tabulated points. > > 3. (computing) During the course of processing some data, and in > response to a directive in that data, to fetch data from a different > source and process it in-line along with the original data. > > ― https://en.wiktionary.org/wiki/interpolate > > -- > Cheers, Ralph. Yeah, I looked it up too. Yes, the argument can be made that one of the definitions can be forced to sort of fit; I'm guessing that #3 didn't exist when troff was written. So I'm gonna stick to my point that using that word is awkward and makes the document a bit harder to understand. Especially in the context of programming languages, of which troff is one. To the best of my knowledge, nobody talks about "a = b;" as interpolating b. From g.branden.robinson at gmail.com Thu Jan 13 04:06:21 2022 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Thu, 13 Jan 2022 05:06:21 +1100 Subject: [TUHS] *roff history as told to GNU In-Reply-To: References: <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> <202201120854.20C8sDRR014233@freefriends.org> Message-ID: <20220112180619.mxzojchd62vpwm2f@localhost.localdomain> Hi, Dan, At 2022-01-12T11:33:35-0500, Dan Cross wrote: > I have some questions about the earlier history. I've been collecting a detailed narrative history not just of the *roff _programs_ but also of the development on the language in the roff(7) manual page. Below I'll share a current chunk of it that is planned for the next release (groff 1.23). It has been heavily revised since groff 1.22.4. Many of my revisions have been motivated by accounts from this list, from the "history of man pages" (more of a history of troff) at manpages.bsd.lv, and the minnie TUHS archive. > As I understand it, in the beginning there was RUNOFF, which I believe > originated on CTSS? The CTSS sources contain a RUNOFF program that's > made up of ~1100 lines of MAD and ~1300 lines of assembler. This is a detail I hadn't encountered before; instead I've read claims that distorted it into being a solely high-level language project. > There is certainly a RUNOFF in Multics, written in BCPL (there's a > small "outer module transfer vector" program in ALM). As I understand it, _this_ RUNOFF is undisputedly Doug McIlroy's. > This is where it gets muddy for me; I understand this was roughly > ported to unix as `roff` by Ken and that at this point, It is hard to find an account of this period that _isn't_ muddy. Claims from Murray Hill luminaries suggest that V0 and V1 Unix roffs were the collective work of Thompson, Ritchie, Ossanna, a fourth person who contributed the hyphenation algorithm (does someone have the name?), and McIlroy, because in Ritchie's words[1], this roff was "transliterated" from Doug's BCPL codebase. > formatting was fairly primitive: suitable for hardcopy terminals and > line printers, and could do things like center lines and so forth, but > nothing fancy (https://www.cs.dartmouth.edu/~doug/reader.pdf). Yes. My contributions to groff's roff(7) page attempt to shed more light on this sort of thing. Sadly, at crucial periods sources and even documentation are missing. For example, there is an nroff entry in the Unix V2 manual table of contents, but no man page is present. In other early editions the reader is asked to see Ossanna for documentation, and it seems the corresponding artifacts might be lost to time. > Ossanna then took over and greatly expanded the capabilities of > `roff`, adding macros and traps and making it Turing-complete; this > was `nroff`, which grew to become `troff` once the C/A/T typesetter > was acquired. Yes. Here's what I have, though it looks better typeset[2]. Corrections from witnesses are warmly welcomed. Name roff - concepts and history of roff typesetting Description The term roff describes a family of document formatting systems known by names like troff, nroff, ditroff, and groff. A roff system consists of an extensible text formatting language and a set of programs for printing and converting to other text formats. Unix-like operating systems often distribute a roff system as a core package. [snip] History Computer-driven document formatting dates back to the 1960s. The roff system itself is intimately connected with the Unix operating system, but its roots go back to the earlier operating systems CTSS and Multics. The predecessor--RUNOFF roff's ancestor RUNOFF was written in the MAD language by Jerry Saltzer to prepare his Ph.D. thesis using the Compatible Time Sharing System (CTSS), a project of the Massachusetts Institute of Technology (MIT). The program is generally referred to in full capitals, both to distinguish it from its many descendants, and because bits were expensive in those days; five- and six-bit character encodings were still in widespread usage, and mixed- case alphabetics seen as a luxury. RUNOFF introduced a syntax of inlining formatting directives amid document text, by beginning a line with a period (an unlikely occurrence in human-readable material) followed by a "control word". Control words with obvious meaning like ".line length n" were supported as well as an abbreviation system; the latter came to overwhelm the former in popular usage and later derivatives of the program. A sample of control words from a RUNOFF manual of December 1966 was documented as follows (with the parameter notation slightly altered). The abbreviations will be familiar to roff veterans. Abbreviation Control word .ad .adjust .bp .begin page .br .break .ce .center .in .indent n .ll .line length n .nf .nofill .pl .paper length n .sp .space [n] In 1965, MIT's Project MAC teamed with Bell Telephone Laboratories and General Electric (GE) to inaugurate the Multics project. After a few years, Bell Labs discontinued its participation in Multics, famously prompting the development of Unix. Meanwhile, Saltzer's RUNOFF proved influential, seeing many ports and derivations elsewhere. In 1969, Doug McIlroy wrote one such reimplementation of RUNOFF in the BCPL language for a GE 645 running GECOS at the Bell Labs location in Murray Hill, New Jersey. In its manual, the control commands were termed "requests", their two-letter names were canonical, and the control character was configurable with a .cc request. Other familiar requests emerged at this time; no-adjust (.na), need (.ne), page offset (.po), tab configuration (.ta, though it worked differently), temporary indent (.ti), character translation (.tr), and automatic underlining (.ul; on RUNOFF you had to backspace and underscore in the input yourself). .fi to enable filling of output lines got the name it retains to this day. Unix and roff roff was one of the first Unix programs. McIlroy's runoff was, in Dennis Ritchie's term, "transliterated" from BCPL to DEC PDP-7 assembly language for the fledgling Unix operating system. It saw its name shortened to roff (perhaps under the influence of Ken Thompson), while adding support for automatic hyphenation with .hc and .hy requests; a generalization of line spacing control with the .ls request; and what later roffs would call diversions, with "footnote" requests. This roff indirectly funded operating systems research at Murray Hill, for it was used to prepare patent applications for AT&T to the U.S. government. This arrangement enabled the group to acquire a PDP-11; roff promptly proved equal to the task of typesetting the first edition of the manual for what would later become known as "Unix Version 1", dated November 1971. Output from all of the foregoing programs was limited to line printers and paper terminals such the IBM 2471 (based on the Selectric line of typewriters) and the Teletype Corporation Model 37. Proportionally-spaced type was unknown. New roff and Typesetter roff The first years of Unix were spent in rapid evolution. The practicalities of preparing standardized documents like patent applications (and Unix manual pages), combined with McIlroy's enthusiasm for macro languages, perhaps created an irresistible pressure to make roff extensible. Joe Ossanna's nroff, literally a "new roff", was the outlet for this pressure. By the time of Unix Version 3 (February 1973)--and still in PDP-11 assembly language--it sported a swath of features now considered essential to roff systems: definition of macros (.de), diversion of text thence (.di), and removal thereof (.rm); trap planting (.wh; "when") and relocation (.ch; "change"); conditional processing (.if); and environments (.ev). Incremental improvements included assignment of the next page number (.pn); no-space mode (.ns) and restoration of vertical spacing (.rs); the saving (.sv) and output (.os) of vertical space; specification of replacement characters for tabs (.tc) and leaders (.lc); configuration of the no-break control character (.c2); shorthand to disable automatic hyphenation (.nh); a condensation of what were formerly six different requests for configuration of page "titles" (headers and footers) into one (.tl) with a length controlled separately from the line length (.lt); automatic line numbering (.nm); interactive input (.rd), which necessitated buffer-flushing (.fl), and was made convenient with early program cessation (.ex); source file inclusion in its modern form (.so; though RUNOFF had an ".append" control word for a similar purpose) and early advance to the next file argument (.nx); ignorable content (.ig); and programmable abort (.ab). Third Edition Unix also brought the pipe(2) system call, the explosive growth of a componentized system based around it, and a "filter model" that remains perceptible today. Equally importantly, the Bell Labs site in Murray Hill acquired a Graphic Systems C/A/T phototypesetter, and with it came the necessity of expanding the capabilities of a roff system to cope with proportionally-spaced type, multiple type sizes, and a variety of fonts. Ossanna wrote a parallel implementation of nroff for the C/A/T, dubbing it troff (for "typesetter roff"). Unfortunately, surviving documentation does not illustrate what requests were implemented at this time for C/A/T support; the troff(1) man page in Fourth Edition Unix (November 1973) does not feature a request list, unlike nroff(1). Apart from typesetter-driven features, Unix Version 4 roffs added string definitions (.ds); made the escape character configurable (.ec); and enabled the user to write diagnostics to the standard error stream (.tm). Around 1974, empowered with multiple type sizes, italics, and a symbol font specially commissioned by Bell Labs from Graphic Systems, Brian Kernighan and Lorinda Cherry implemented eqn for typesetting mathematics. In the same year, for Fifth Edition Unix, Ossanna combined and reimplemented the two roffs in C, using preprocessor conditions of that language to generate both from a single source tree. Ossanna documented the syntax of the input language to the nroff and troff programs in the "Troff User's Manual", first published in 1976, with further revisions as late as 1992 by Kernighan. (The original version was entitled "Nroff/Troff User's Manual", which may partially explain why roff practitioners have tended to refer to it by its AT&T document identifier, "CSTR #54".) Its final revision serves as the de facto specification of AT&T troff, and all subsequent implementors of roff systems have done so in its shadow. A small and simple set of roff macros was first used for the manual pages of Unix Version 4 and persisted for two further releases, but the first macro package to be formally described and installed was ms by Lesk in Version 6. He also wrote a manual, "Typing Documents on the Unix System", describing ms and basic nroff/troff usage, updating it as the package accrued features. Sixth Edition additionally saw the debut of the tbl preprocessor for formatting tables, also by Lesk. For Unix Version 7 (January 1979), McIlroy designed, implemented, and documented the man macro package, introducing most of the macros described in groff_man(7) today, and edited volume 1 of the Version 7 manual using it. Documents composed using ms featured in volume 2, edited by Kernighan. Ossanna had passed away unexpectedly in 1977, and after the release of Version 7, with the C/A/T typesetter becoming supplanted by alternative devices such as the Mergenthaler Linotron 202, Kernighan undertook a revision and rewrite of troff to generalize its design. To implement this revised architecture, he developed the font and device description file formats and the device-independent output format that remain in use today. He described these novelties in the article "A Typesetter-independent TROFF", last revised in 1982, and like the troff manual itself, it is widely known by a shorthand, "CSTR #97". Kernighan's innovations prepared troff well for the introduction of the Adobe PostScript language in 1982 and a vibrant market in laser printers with built-in interpreters for it. An output driver for PostScript, dpost, was swiftly developed. However, due to AT&T software licensing practices, Ossanna's troff, with its tight coupling to the capabilities of the C/A/T, remained in parallel distribution with device-independent troff throughout the 1980s, leading some developers to contrive translators for C/A/T-formatted documents to other devices. An example was vtroff for Versatec and Benson-Varian plotters. Today, however, all actively maintained troffs follow Kernighan's device- independent design. Regards, Branden [1] "The Evolution of the Unix Time-Sharing System", Ritchie, 1984 [2] Formatted with: groff -man -P-c -Tascii -rLL=72n -rHY=0 -dAD=l build/man/roff.7 (The `AD` string is new to groff 1.23 man(7).) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From g.branden.robinson at gmail.com Thu Jan 13 04:27:32 2022 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Thu, 13 Jan 2022 05:27:32 +1100 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: <202201121753.20CHrSDp2410765@darkstar.fourwinds.com> References: <202201120249.20C2nfst2370834@darkstar.fourwinds.com> <20220112103823.A4DCB1F939@orac.inputplus.co.uk> <202201121753.20CHrSDp2410765@darkstar.fourwinds.com> Message-ID: <20220112182731.xoz4fugdbpxv5lbm@localhost.localdomain> At 2022-01-12T09:53:28-0800, Jon Steinhart wrote: > Ralph Corderoy writes: > > > I never understood "interpolating a register" to have any relation > > > to the definition of interpolate that I learned in math. > > > > The first definition makes sense of it: > > > > 1. (transitive, intransitive) To introduce (something) between > > other things; especially to insert (possibly spurious) words > > into a text. > > > > in verse 74, the second line is clearly interpolated [...] > Yeah, I looked it up too. Yes, the argument can be made that one of > the definitions can be forced to sort of fit; I'm guessing that #3 > didn't exist when troff was written. So I'm gonna stick to my point > that using that word is awkward and makes the document a bit harder to > understand. Especially in the context of programming languages, of > which troff is one. To the best of my knowledge, nobody talks about > "a = b;" as interpolating b. I've found the term highly useful and have greatly increased its usage in groff documentation. (I have been a stickler for a disciplined lexicon in every software project I've been involved in.) I prefer it to a popular alternative, "expansion", which is misleading--especially to novices, who then make the reasonable assumption, given the everyday meaning of that word, that whatever results from the process will be larger in some sense than what was there before. An argument could be made for the word "replacement", but I've found it useful to reserve that plain-spoken term for discussion of things a human might do (perhaps in the course of editing a document or developing a macro). To my ear, "interpolation" sounds fancy enough to refer to something you let a machine do, without being _excessively_ technical in tone. 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 halbert at halwitz.org Thu Jan 13 04:34:45 2022 From: halbert at halwitz.org (Dan Halbert) Date: Wed, 12 Jan 2022 13:34:45 -0500 Subject: [TUHS] *roff history as told to GNU In-Reply-To: <20220112180619.mxzojchd62vpwm2f@localhost.localdomain> References: <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> <202201120854.20C8sDRR014233@freefriends.org> <20220112180619.mxzojchd62vpwm2f@localhost.localdomain> Message-ID: <8075a67e-7cf6-cf0c-b1e7-9c2b473b2892@halwitz.org> On 1/12/22 13:06, G. Branden Robinson wrote: > Hi, Dan, > > At 2022-01-12T11:33:35-0500, Dan Cross wrote: >> I have some questions about the earlier history. >> >> I've been collecting a detailed narrative history not just of the *roff >> _programs_ but also of the development on the language in the roff(7) >> manual page. Below I'll share a current chunk of it that is planned for >> the next release (groff 1.23). It has been heavily revised since >> groff 1.22.4. Many of my revisions have been motivated by accounts from >> this list, from the "history of man pages" (more of a history of troff) >> at manpages.bsd.lv, and the minnie TUHS archive. I used RUNOFF on TOPS-10 in 1971, I think, and eventually also on TENEX and TOPS-20. It probably was available earlier than that. Your history is covering the Unix side, but there is also a pretty robust DEC side. It was available on pretty much all the DEC machines. https://en.wikipedia.org/wiki/TYPSET_and_RUNOFF has some mentions. Dan H. From cowan at ccil.org Thu Jan 13 05:02:04 2022 From: cowan at ccil.org (John Cowan) Date: Wed, 12 Jan 2022 14:02:04 -0500 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: <20220112182731.xoz4fugdbpxv5lbm@localhost.localdomain> References: <202201120249.20C2nfst2370834@darkstar.fourwinds.com> <20220112103823.A4DCB1F939@orac.inputplus.co.uk> <202201121753.20CHrSDp2410765@darkstar.fourwinds.com> <20220112182731.xoz4fugdbpxv5lbm@localhost.localdomain> Message-ID: On Wed, Jan 12, 2022 at 1:27 PM G. Branden Robinson < g.branden.robinson at gmail.com> wrote: An argument could be made for the word "replacement", but I've found it > useful to reserve that plain-spoken term for discussion of things a > human might do (perhaps in the course of editing a document or > developing a macro). To my ear, "interpolation" sounds fancy enough to > refer to something you let a machine do, without being _excessively_ > technical in tone. > Strictly speaking, what is interpolated is the _contents_ of the register, not the register itself. It never hurts to be too clear. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Thu Jan 13 05:54:34 2022 From: cowan at ccil.org (John Cowan) Date: Wed, 12 Jan 2022 14:54:34 -0500 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: References: <250868b3-9e0c-5ff2-8506-e2da5c73862a@gmail.com> Message-ID: On Tue, Jan 11, 2022 at 9:01 PM Blake McBride wrote: > 2. Drop DVI? Are you kidding me? Although PDF may be popular now, >> > > that may not be the case 20 years from now. A device-independent >> > format is what is needed, and that's what DVI is. TeX is guaranteed >> > to produce the exact same output 100 years from now. >> > Well, provided there are DVI-to-whatever converters then. it's a systems problem. What we really need is gcc support for some processor that is easy to emulate (at least the userland). Historically that was MIPS; now it's probably RISC/V. Or, I suppose, MMIX; there is a very partial Verilog description at that would make it possible to create a hardware integer MMIX CPU using FPGAs. And .PDF isn't? >> > > No. It isn't. It is an Adobe product. > Up to a point, Minister. PDF/A is an ISO standard that tracks PDF 1.4 or PDF 1.7. It is meant for creating archivable PDFs, so it excludes linked fonts (as opposed to embedded ones, which are allowed), JavaScript, audio/video, encryption, external references, etc. For troff purposes, we don't need any of that, so it's just a matter of setting the metadata correctly. ISO standards can be withdrawn, but they remain available; I doubt this one will be, since libraries are depending on it. There are lots of FLOSS toolkits to generate PDFs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Thu Jan 13 06:01:40 2022 From: crossd at gmail.com (Dan Cross) Date: Wed, 12 Jan 2022 15:01:40 -0500 Subject: [TUHS] *roff history as told to GNU In-Reply-To: <20220112180619.mxzojchd62vpwm2f@localhost.localdomain> References: <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> <202201120854.20C8sDRR014233@freefriends.org> <20220112180619.mxzojchd62vpwm2f@localhost.localdomain> Message-ID: On Wed, Jan 12, 2022 at 1:07 PM G. Branden Robinson < g.branden.robinson at gmail.com> wrote: > Hi, Dan, > > At 2022-01-12T11:33:35-0500, Dan Cross wrote: > > I have some questions about the earlier history. > > I've been collecting a detailed narrative history not just of the *roff > _programs_ but also of the development on the language in the roff(7) > manual page. Below I'll share a current chunk of it that is planned for > the next release (groff 1.23). It has been heavily revised since > groff 1.22.4. Many of my revisions have been motivated by accounts from > this list, from the "history of man pages" (more of a history of troff) > at manpages.bsd.lv, and the minnie TUHS archive. > Very interesting. The email mentioning DSR from Dan Halbert linked to a wikipedia article that in turn links here: https://manpages.bsd.lv/history/saltzer_23_10_2011.txt This is an email from Jerry Saltzer that refers to a port of the _CTSS_ BCPL ROFF sources purportedly written by Doug. I wonder if that was actually a thing, or an error? > As I understand it, in the beginning there was RUNOFF, which I believe > > originated on CTSS? The CTSS sources contain a RUNOFF program that's > > made up of ~1100 lines of MAD and ~1300 lines of assembler. > > This is a detail I hadn't encountered before; instead I've read claims > that distorted it into being a solely high-level language project. > Fortunately, the source is online: https://github.com/rcornwell/ctss/tree/master/src/runoff The `.fap` files are assembly; for example https://github.com/rcornwell/ctss/blob/master/src/runoff/lmio12.fap Brief inspection shows the FAP code mostly dealing with very low-level details either interfacing with the system for IO/memory or character handling. Without further examination, I'd be willing to believe the bulk of the program's logic is in MAD. > There is certainly a RUNOFF in Multics, written in BCPL (there's a > > small "outer module transfer vector" program in ALM). > > As I understand it, _this_ RUNOFF is undisputedly Doug McIlroy's. > Indeed; one finds the following in at least one of the Multics RUNOFF source files: From https://github.com/dancrossnyc/multics/blob/main/library_dir_dir/system_library_standard/source/bound_runoff_.s.archive/runoff_mr1.bcpl : // Roff for MULTICS // // The first ROFF for Multics was written in March, 1969, by // Doug McIlroy of Bell Labs. Art Evans made extensive // modifications to it in May and June, 1969, adding many // comments and making various changes. // Footnoting added by Dennis Capps in 1970. // Maintained by Harwell Thrasher in 1971. // Many new features added and bugs fixed by R Mabee in 1971-1972. // RUNOFF and BCPL were brought over to the 6180 Multics (from 645) in May of 1973 by R F Mabee. The copyright statements on all of the runoff source files seem to be dated 1974 (I haven't looked at every one). > [snip] > Here's what I have, though it looks better typeset[2]. Corrections from > witnesses are warmly welcomed. [snip] > Thank you; that was very interesting. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Thu Jan 13 06:48:45 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 12 Jan 2022 15:48:45 -0500 (EST) Subject: [TUHS] *roff history as told to GNU Message-ID: <20220112204845.C365618C08A@mercury.lcs.mit.edu> > From: Dan Cross > a port of the _CTSS_ BCPL ROFF sources purportedly written by Doug. I > wonder if that was actually a thing, or an error? > ... > Fortunately, the source [of the original CTSS runoff] is online: > ... > Indeed; one finds the following in at least one of the Multics RUNOFF > source files: It sounds like all the steps in the chain have pretty definitive evidence - _except_ whether there was ever a CTSS RUNOFF in BCPL, from Doug. Happily, we have someone here who should be able to answer that! :-) Noel From clemc at ccc.com Thu Jan 13 08:32:32 2022 From: clemc at ccc.com (Clem Cole) Date: Wed, 12 Jan 2022 17:32:32 -0500 Subject: [TUHS] *roff history as told to GNU In-Reply-To: <20220112180619.mxzojchd62vpwm2f@localhost.localdomain> References: <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> <202201120854.20C8sDRR014233@freefriends.org> <20220112180619.mxzojchd62vpwm2f@localhost.localdomain> Message-ID: Looks excellent -- friendly edit -- ditroff had nothing to do with vcat/vpr/vtroff. Tom Ferrin wrote the original at UCSF in the mid/late 70s -- the reasons was the the CAT typesetter was expensive and actually kinda nasty run. Many of us had plotters in those days and Tom's hack was a welcomed addition to the tool set. instead of: leading some developers to contrive translators for C/A/T-formatted documents to other devices. An example was vtroff for Versatec and Benson-Varian plotters. I offer: In mid/late 70s, Tom Ferrin a graphics researcher at UCSF using the font set released in the late 1960s, from Alan Hershey [ https://en.wikipedia.org/wiki/Hershey_fonts], wrote a program to simulate the C/A/T typesetter allowing the output of the original troff program to be 'plotted'. This program originally called vcat for virtual cat typesetter, was first distributed as part of an early USENIX distribution tape, but was eventually re-released in 3BSD and later BSD distributions as the UCB vpr(1) command and associated wrapper that call it was created called vtroff. On Wed, Jan 12, 2022 at 1:07 PM G. Branden Robinson < g.branden.robinson at gmail.com> wrote: > Hi, Dan, > > At 2022-01-12T11:33:35-0500, Dan Cross wrote: > > I have some questions about the earlier history. > > I've been collecting a detailed narrative history not just of the *roff > _programs_ but also of the development on the language in the roff(7) > manual page. Below I'll share a current chunk of it that is planned for > the next release (groff 1.23). It has been heavily revised since > groff 1.22.4. Many of my revisions have been motivated by accounts from > this list, from the "history of man pages" (more of a history of troff) > at manpages.bsd.lv, and the minnie TUHS archive. > > > As I understand it, in the beginning there was RUNOFF, which I believe > > originated on CTSS? The CTSS sources contain a RUNOFF program that's > > made up of ~1100 lines of MAD and ~1300 lines of assembler. > > This is a detail I hadn't encountered before; instead I've read claims > that distorted it into being a solely high-level language project. > > > There is certainly a RUNOFF in Multics, written in BCPL (there's a > > small "outer module transfer vector" program in ALM). > > As I understand it, _this_ RUNOFF is undisputedly Doug McIlroy's. > > > This is where it gets muddy for me; I understand this was roughly > > ported to unix as `roff` by Ken and that at this point, > > It is hard to find an account of this period that _isn't_ muddy. Claims > from Murray Hill luminaries suggest that V0 and V1 Unix roffs were the > collective work of Thompson, Ritchie, Ossanna, a fourth person who > contributed the hyphenation algorithm (does someone have the name?), and > McIlroy, because in Ritchie's words[1], this roff was "transliterated" > from Doug's BCPL codebase. > > > formatting was fairly primitive: suitable for hardcopy terminals and > > line printers, and could do things like center lines and so forth, but > > nothing fancy (https://www.cs.dartmouth.edu/~doug/reader.pdf). > > Yes. My contributions to groff's roff(7) page attempt to shed more > light on this sort of thing. Sadly, at crucial periods sources and even > documentation are missing. For example, there is an nroff entry in the > Unix V2 manual table of contents, but no man page is present. In other > early editions the reader is asked to see Ossanna for documentation, and > it seems the corresponding artifacts might be lost to time. > > > Ossanna then took over and greatly expanded the capabilities of > > `roff`, adding macros and traps and making it Turing-complete; this > > was `nroff`, which grew to become `troff` once the C/A/T typesetter > > was acquired. > > Yes. > > Here's what I have, though it looks better typeset[2]. Corrections from > witnesses are warmly welcomed. > > Name > roff - concepts and history of roff typesetting > > Description > The term roff describes a family of document formatting systems > known by names like troff, nroff, ditroff, and groff. A roff > system consists of an extensible text formatting language and a > set of programs for printing and converting to other text > formats. Unix-like operating systems often distribute a roff > system as a core package. > > [snip] > > History > Computer-driven document formatting dates back to the 1960s. The > roff system itself is intimately connected with the Unix > operating system, but its roots go back to the earlier operating > systems CTSS and Multics. > > The predecessor--RUNOFF > roff's ancestor RUNOFF was written in the MAD language by Jerry > Saltzer to prepare his Ph.D. thesis using the Compatible Time > Sharing System (CTSS), a project of the Massachusetts Institute > of Technology (MIT). The program is generally referred to in > full capitals, both to distinguish it from its many descendants, > and because bits were expensive in those days; five- and six-bit > character encodings were still in widespread usage, and mixed- > case alphabetics seen as a luxury. RUNOFF introduced a syntax of > inlining formatting directives amid document text, by beginning a > line with a period (an unlikely occurrence in human-readable > material) followed by a "control word". Control words with > obvious meaning like ".line length n" were supported as well as > an abbreviation system; the latter came to overwhelm the former > in popular usage and later derivatives of the program. A sample > of control words from a RUNOFF manual of December 1966 web.mit.edu/Saltzer/www/publications/ctss/AH.9.01.html> was > documented as follows (with the parameter notation slightly > altered). The abbreviations will be familiar to roff veterans. > > Abbreviation Control word > .ad .adjust > .bp .begin page > .br .break > .ce .center > .in .indent n > .ll .line length n > .nf .nofill > .pl .paper length n > .sp .space [n] > > In 1965, MIT's Project MAC teamed with Bell Telephone > Laboratories and General Electric (GE) to inaugurate the Multics > project. After a few years, Bell > Labs discontinued its participation in Multics, famously > prompting the development of Unix. Meanwhile, Saltzer's RUNOFF > proved influential, seeing many ports and derivations elsewhere. > > In 1969, Doug McIlroy wrote one such reimplementation of RUNOFF > in the BCPL language for a GE 645 running GECOS at the Bell Labs > location in Murray Hill, New Jersey. In its manual, the control > commands were termed "requests", their two-letter names were > canonical, and the control character was configurable with a .cc > request. Other familiar requests emerged at this time; no-adjust > (.na), need (.ne), page offset (.po), tab configuration (.ta, > though it worked differently), temporary indent (.ti), character > translation (.tr), and automatic underlining (.ul; on RUNOFF you > had to backspace and underscore in the input yourself). .fi to > enable filling of output lines got the name it retains to this > day. > > Unix and roff > roff was one of the first Unix programs. McIlroy's runoff was, > in Dennis Ritchie's term, "transliterated" from BCPL to DEC PDP-7 > assembly language for the fledgling Unix operating system. It > saw its name shortened to roff (perhaps under the influence of > Ken Thompson), while adding support for automatic hyphenation > with .hc and .hy requests; a generalization of line spacing > control with the .ls request; and what later roffs would call > diversions, with "footnote" requests. This roff indirectly > funded operating systems research at Murray Hill, for it was used > to prepare patent applications for AT&T to the U.S. government. > This arrangement enabled the group to acquire a PDP-11; roff > promptly proved equal to the task of typesetting the first > edition of the manual for what would later become known as "Unix > Version 1", dated November 1971. > > Output from all of the foregoing programs was limited to line > printers and paper terminals such the IBM 2471 (based on the > Selectric line of typewriters) and the Teletype Corporation Model > 37. Proportionally-spaced type was unknown. > > New roff and Typesetter roff > The first years of Unix were spent in rapid evolution. The > practicalities of preparing standardized documents like patent > applications (and Unix manual pages), combined with McIlroy's > enthusiasm for macro languages, perhaps created an irresistible > pressure to make roff extensible. Joe Ossanna's nroff, literally > a "new roff", was the outlet for this pressure. By the time of > Unix Version 3 (February 1973)--and still in PDP-11 assembly > language--it sported a swath of features now considered essential > to roff systems: definition of macros (.de), diversion of text > thence (.di), and removal thereof (.rm); trap planting (.wh; > "when") and relocation (.ch; "change"); conditional processing > (.if); and environments (.ev). Incremental improvements included > assignment of the next page number (.pn); no-space mode (.ns) and > restoration of vertical spacing (.rs); the saving (.sv) and > output (.os) of vertical space; specification of replacement > characters for tabs (.tc) and leaders (.lc); configuration of the > no-break control character (.c2); shorthand to disable automatic > hyphenation (.nh); a condensation of what were formerly six > different requests for configuration of page "titles" (headers > and footers) into one (.tl) with a length controlled separately > from the line length (.lt); automatic line numbering (.nm); > interactive input (.rd), which necessitated buffer-flushing > (.fl), and was made convenient with early program cessation > (.ex); source file inclusion in its modern form (.so; though > RUNOFF had an ".append" control word for a similar purpose) and > early advance to the next file argument (.nx); ignorable content > (.ig); and programmable abort (.ab). > > Third Edition Unix also brought the pipe(2) system call, the > explosive growth of a componentized system based around it, and a > "filter model" that remains perceptible today. Equally > importantly, the Bell Labs site in Murray Hill acquired a Graphic > Systems C/A/T phototypesetter, and with it came the necessity of > expanding the capabilities of a roff system to cope with > proportionally-spaced type, multiple type sizes, and a variety of > fonts. Ossanna wrote a parallel implementation of nroff for the > C/A/T, dubbing it troff (for "typesetter roff"). Unfortunately, > surviving documentation does not illustrate what requests were > implemented at this time for C/A/T support; the troff(1) man page > in Fourth Edition Unix (November 1973) does not feature a request > list, unlike nroff(1). Apart from typesetter-driven features, > Unix Version 4 roffs added string definitions (.ds); made the > escape character configurable (.ec); and enabled the user to > write diagnostics to the standard error stream (.tm). Around > 1974, empowered with multiple type sizes, italics, and a symbol > font specially commissioned by Bell Labs from Graphic Systems, > Brian Kernighan and Lorinda Cherry implemented eqn for > typesetting mathematics. In the same year, for Fifth Edition > Unix, Ossanna combined and reimplemented the two roffs in C, > using preprocessor conditions of that language to generate both > from a single source tree. > > Ossanna documented the syntax of the input language to the nroff > and troff programs in the "Troff User's Manual", first published > in 1976, with further revisions as late as 1992 by Kernighan. > (The original version was entitled "Nroff/Troff User's Manual", > which may partially explain why roff practitioners have tended to > refer to it by its AT&T document identifier, "CSTR #54".) Its > final revision serves as the de facto specification of AT&T > troff, and all subsequent implementors of roff systems have done > so in its shadow. > > A small and simple set of roff macros was first used for the > manual pages of Unix Version 4 and persisted for two further > releases, but the first macro package to be formally described > and installed was ms by Lesk in Version 6. He also wrote a > manual, "Typing Documents on the Unix System", describing ms and > basic nroff/troff usage, updating it as the package accrued > features. Sixth Edition additionally saw the debut of the tbl > preprocessor for formatting tables, also by Lesk. > > For Unix Version 7 (January 1979), McIlroy designed, implemented, > and documented the man macro package, introducing most of the > macros described in groff_man(7) today, and edited volume 1 of > the Version 7 manual using it. Documents composed using ms > featured in volume 2, edited by Kernighan. > > Ossanna had passed away unexpectedly in 1977, and after the > release of Version 7, with the C/A/T typesetter becoming > supplanted by alternative devices such as the Mergenthaler > Linotron 202, Kernighan undertook a revision and rewrite of troff > to generalize its design. To implement this revised > architecture, he developed the font and device description file > formats and the device-independent output format that remain in > use today. He described these novelties in the article "A > Typesetter-independent TROFF", last revised in 1982, and like the > troff manual itself, it is widely known by a shorthand, "CSTR > #97". > > Kernighan's innovations prepared troff well for the introduction > of the Adobe PostScript language in 1982 and a vibrant market in > laser printers with built-in interpreters for it. An output > driver for PostScript, dpost, was swiftly developed. However, > due to AT&T software licensing practices, Ossanna's troff, with > its tight coupling to the capabilities of the C/A/T, remained in > parallel distribution with device-independent troff throughout > the 1980s, leading some developers to contrive translators for > C/A/T-formatted documents to other devices. An example was > vtroff for Versatec and Benson-Varian plotters. Today, however, > all actively maintained troffs follow Kernighan's device- > independent design. > > Regards, > Branden > > [1] "The Evolution of the Unix Time-Sharing System", Ritchie, 1984 > [2] Formatted with: > groff -man -P-c -Tascii -rLL=72n -rHY=0 -dAD=l build/man/roff.7 > (The `AD` string is new to groff 1.23 man(7).) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Jan 13 08:48:52 2022 From: clemc at ccc.com (Clem Cole) Date: Wed, 12 Jan 2022 17:48:52 -0500 Subject: [TUHS] *roff history as told to GNU In-Reply-To: <8075a67e-7cf6-cf0c-b1e7-9c2b473b2892@halwitz.org> References: <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> <202201120854.20C8sDRR014233@freefriends.org> <20220112180619.mxzojchd62vpwm2f@localhost.localdomain> <8075a67e-7cf6-cf0c-b1e7-9c2b473b2892@halwitz.org> Message-ID: Dan/Branden -- don't forget that IBM had a flavor of the runoff family also at least by the early 1970s when I saw it. In fact, I learned it before either the DEC ones for the PDP-10s which I saw next, and only after that the UNIX family. We ran the IBM doc tool on TSS [often of 2741 style devices], and I think it ran on MTS. Pre-laser printer days, although CS an XGP, it was only 200 dpi (and was on the PDP-10s). So CMU computer center (IBM shop) even had a very high end printer with a golf ball (serial) output device that was in a locked room that was connected the 360 that they used to print 'special' letters on a fan folded paper that was super high quality and then run through the 'burster' to remove the edges and make it single sheets [Acceptance letters and other special things got printed on it by the computer center for the administration]. I don't remember much about that part of the process, other than the input/prep was from the IBM version of a runoff like program and as an operator, we had to learn to make it go and run things out on it as needed. But I do remember it was a PITA to output to that thing, but the SW also worked on a traditional 2741. As a member of the computer staff I had access to the 2741 in my office (for APL work), but could set it up as a standard 2741 and type papers on it late at night. On Wed, Jan 12, 2022 at 1:42 PM Dan Halbert wrote: > On 1/12/22 13:06, G. Branden Robinson wrote: > > Hi, Dan, > > > > At 2022-01-12T11:33:35-0500, Dan Cross wrote: > >> I have some questions about the earlier history. > >> > >> I've been collecting a detailed narrative history not just of the *roff > >> _programs_ but also of the development on the language in the roff(7) > >> manual page. Below I'll share a current chunk of it that is planned for > >> the next release (groff 1.23). It has been heavily revised since > >> groff 1.22.4. Many of my revisions have been motivated by accounts from > >> this list, from the "history of man pages" (more of a history of troff) > >> at manpages.bsd.lv, and the minnie TUHS archive. > > I used RUNOFF on TOPS-10 in 1971, I think, and eventually also on TENEX > and TOPS-20. It probably was available earlier than that. Your history > is covering the Unix side, but there is also a pretty robust DEC side. > It was available on pretty much all the DEC machines. > https://en.wikipedia.org/wiki/TYPSET_and_RUNOFF has some mentions. > > Dan H. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Thu Jan 13 09:15:10 2022 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Thu, 13 Jan 2022 10:15:10 +1100 Subject: [TUHS] Coastal cultures, collaboration, creativity and Sun vs DEC. In-Reply-To: References: Message-ID: <20220112231509.GJ61872@eureka.lemis.com> On Tuesday, 11 January 2022 at 14:34:16 -0500, John Cowan wrote: > On Tue, Jan 11, 2022 at 1:37 PM Dan Cross wrote: >> It seems like Unix is largely a child of the coasts. > > We can add the eastern coast of Australia, where the original > Wollongong group made the first V6 port to the Interdata 7/32 (not > to be confused with the Labs port to the 8/32). To be fair, in the case of Australia almost everybody is on the east coast, though we have had our share of FreeBSD core team members from the "west coast" (which is really only Perth). 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.php -------------- 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 Thu Jan 13 09:22:58 2022 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Thu, 13 Jan 2022 10:22:58 +1100 Subject: [TUHS] troff or groff? (was: Demise of TeX and groff (was: roff(7))) In-Reply-To: <20220111140005.GI3441@mcvoy.com> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> <202201110850.20B8oeMZ020212@freefriends.org> <20220111140005.GI3441@mcvoy.com> Message-ID: <20220112232258.GK61872@eureka.lemis.com> On Tuesday, 11 January 2022 at 6:00:05 -0800, Larry McVoy wrote: > It may be ancient history but troff was not a given on every > platform. nroff was there but troff was considered optional, you > had to pay for it and a lot of vendors didn't see the value. So the > docs and you weren't sure if you would have it at your next job, not > good. I've never used real troff, just groff. But from the man pages I understood that real troff only generated output for specific typesetters, while groff generated PostScript. Not so? 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.php -------------- 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 Thu Jan 13 09:29:45 2022 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Thu, 13 Jan 2022 10:29:45 +1100 Subject: [TUHS] troff or groff? (was: Demise of TeX and groff (was: roff(7))) In-Reply-To: <20220112232258.GK61872@eureka.lemis.com> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> <202201110850.20B8oeMZ020212@freefriends.org> <20220111140005.GI3441@mcvoy.com> <20220112232258.GK61872@eureka.lemis.com> Message-ID: <20220112232945.GL61872@eureka.lemis.com> On Thursday, 13 January 2022 at 10:22:58 +1100, Greg 'groggy' Lehey wrote: > > I've never used real troff, just groff. But from the man pages I > understood that real troff only generated output for specific > typesetters, while groff generated PostScript. Not so? Never mind, I see that this has been done to death in another subthread. 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.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From lm at mcvoy.com Thu Jan 13 09:32:20 2022 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 12 Jan 2022 15:32:20 -0800 Subject: [TUHS] troff or groff? (was: Demise of TeX and groff (was: roff(7))) In-Reply-To: <20220112232258.GK61872@eureka.lemis.com> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> <202201110850.20B8oeMZ020212@freefriends.org> <20220111140005.GI3441@mcvoy.com> <20220112232258.GK61872@eureka.lemis.com> Message-ID: <20220112233220.GZ7175@mcvoy.com> On Thu, Jan 13, 2022 at 10:22:58AM +1100, Greg 'groggy' Lehey wrote: > On Tuesday, 11 January 2022 at 6:00:05 -0800, Larry McVoy wrote: > > It may be ancient history but troff was not a given on every > > platform. nroff was there but troff was considered optional, you > > had to pay for it and a lot of vendors didn't see the value. So the > > docs and you weren't sure if you would have it at your next job, not > > good. > > I've never used real troff, just groff. But from the man pages I > understood that real troff only generated output for specific > typesetters, while groff generated PostScript. Not so? Yeah, it's been hashed out in this thread. I think originally it was for a C/A/T thingy, then somebody did a DVI which a virtual thingy with "drivers" for each target thingy, and then there was a pay version for postscript and then groff. Or something like that, if you read through this thread it's been hashed out pretty hard. And over on the groff mailing list they are putting the history in a man page going all the way back to RUNOFF. Loving the interest in roff, it's my favorite for writing papers or docs. Have developed a bit of a taste for asciidoc for simple stuff for the web. --lm From sauer at technologists.com Thu Jan 13 09:27:15 2022 From: sauer at technologists.com (Charles H. Sauer) Date: Wed, 12 Jan 2022 17:27:15 -0600 Subject: [TUHS] *roff history as told to GNU In-Reply-To: References: <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> <202201120854.20C8sDRR014233@freefriends.org> <20220112180619.mxzojchd62vpwm2f@localhost.localdomain> <8075a67e-7cf6-cf0c-b1e7-9c2b473b2892@halwitz.org> Message-ID: <87382868-fabd-afdb-0d29-ec6d05bc4ada@technologists.com> I try to avoid inserting non-Unix IBM stuff into TUHS, but since Clem opened the door, ... When I was at Yorktown 1975-77 and 1979-82, using Script (IBM's runoff) on VM/370 was very pleasant from my perspective, for papers, manuals and my three performance modeling books. IIRC when I got there Script output went to Versatecs for draft output and to APS5 for camera ready. By 1979, DCF superseded Script and 6670s superseded Versatecs for draft output. https://en.wikipedia.org/wiki/SCRIPT_(markup) and https://en.wikipedia.org/wiki/IBM_Generalized_Markup_Language seem fair to me. While I'm inserting non-Unix stuff, and presuming some parallel between Yorktown and Murray Hill, the culture discussions make me point out that I intentionally avoided ties and suits my first couple of years, wearing a turtleneck for my initial interviews. Then my wife insisted I start wearing three piece wool suits, which were fine in the cold months requiring driving, but I avoided them when the weather was warm enough for me to cycle the five miles to the lab (https://technologists.com/songs/swans.html). CHS On 1/12/2022 4:48 PM, Clem Cole wrote: > Dan/Branden -- don't forget that IBM had a flavor of the runoff family > also at least by the early 1970s when I saw it.  In fact, I learned it > before either the DEC ones for the PDP-10s which I saw next, and only > after that the UNIX family.    We ran the IBM doc tool on TSS [often of > 2741 style devices], and I think it ran on MTS.  Pre-laser printer days, > although CS an XGP, it was only 200 dpi (and was on the PDP-10s).  So > CMU computer center (IBM shop) even had a very high end printer with a > golf ball (serial) output device that was in a locked room that was > connected the 360 that they used to print 'special' letters on a fan > folded paper that was super high quality and then run through the > 'burster' to remove the edges and make it single sheets [Acceptance > letters and other special things got printed on it by the computer > center for the administration].   I don't remember much about that part > of the process, other than the input/prep was from the IBM version of a > runoff like program and as an operator, we had to learn to make it go > and run things out on it as needed. But I do remember it was a PITA to > output to that thing, but the SW also worked on a traditional 2741.  As > a member of the computer staff I had access to the 2741 in my office > (for APL work), but could set it up as a standard 2741 and type papers > on it late at night. > > On Wed, Jan 12, 2022 at 1:42 PM Dan Halbert > wrote: > > On 1/12/22 13:06, G. Branden Robinson wrote: > > Hi, Dan, > > > > At 2022-01-12T11:33:35-0500, Dan Cross wrote: > >> I have some questions about the earlier history. > >> > >> I've been collecting a detailed narrative history not just of > the *roff > >> _programs_ but also of the development on the language in the > roff(7) > >> manual page.  Below I'll share a current chunk of it that is > planned for > >> the next release (groff 1.23).  It has been heavily revised since > >> groff 1.22.4.  Many of my revisions have been motivated by > accounts from > >> this list, from the "history of man pages" (more of a history of > troff) > >> at manpages.bsd.lv , and the minnie TUHS > archive. > > I used RUNOFF on TOPS-10 in 1971, I think, and eventually also on TENEX > and TOPS-20. It probably was available earlier than that. Your history > is covering the Unix side, but there is also a pretty robust DEC side. > It was available on pretty much all the DEC machines. > https://en.wikipedia.org/wiki/TYPSET_and_RUNOFF > has some mentions. > > Dan H. > -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Twitter: CharlesHSauer From athornton at gmail.com Thu Jan 13 10:35:14 2022 From: athornton at gmail.com (Adam Thornton) Date: Wed, 12 Jan 2022 17:35:14 -0700 Subject: [TUHS] *roff history as told to GNU In-Reply-To: <87382868-fabd-afdb-0d29-ec6d05bc4ada@technologists.com> References: <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> <202201120854.20C8sDRR014233@freefriends.org> <20220112180619.mxzojchd62vpwm2f@localhost.localdomain> <8075a67e-7cf6-cf0c-b1e7-9c2b473b2892@halwitz.org> <87382868-fabd-afdb-0d29-ec6d05bc4ada@technologists.com> Message-ID: <1924AC3A-BCA5-4915-B116-D7E88FA4F2FD@gmail.com> > On Jan 12, 2022, at 4:27 PM, Charles H. Sauer wrote: > > I try to avoid inserting non-Unix IBM stuff into TUHS, but since Clem opened the door, ... > > When I was at Yorktown 1975-77 and 1979-82, using Script (IBM's runoff) on VM/370 was very pleasant from my perspective, for papers, manuals and my three performance modeling books. IIRC when I got there Script output went to Versatecs for draft output and to APS5 for camera ready. By 1979, DCF superseded Script and 6670s superseded Versatecs for draft output. https://en.wikipedia.org/wiki/SCRIPT_(markup) and https://en.wikipedia.org/wiki/IBM_Generalized_Markup_Language seem fair to me. BookMaster might still be my favorite documentation-creation tool. Adam From athornton at gmail.com Thu Jan 13 11:34:09 2022 From: athornton at gmail.com (Adam Thornton) Date: Wed, 12 Jan 2022 18:34:09 -0700 Subject: [TUHS] Coastal cultures, collaboration, creativity and Sun vs DEC. In-Reply-To: <20220112231509.GJ61872@eureka.lemis.com> References: <20220112231509.GJ61872@eureka.lemis.com> Message-ID: Moving to COFF, but Brian Dear's "The Friendly Orange Glow", about Plato, talks a lot about some of the cool stuff happening in the middle of the country. https://www.amazon.com/Friendly-Orange-Glow-Untold-Cyberculture/dp/1101973633/ref=tmm_pap_swatch_0?_encoding=UTF8&qid=&sr= And later, of course, NCSA Mosaic. On Wed, Jan 12, 2022 at 4:15 PM Greg 'groggy' Lehey wrote: > On Tuesday, 11 January 2022 at 14:34:16 -0500, John Cowan wrote: > > On Tue, Jan 11, 2022 at 1:37 PM Dan Cross wrote: > >> It seems like Unix is largely a child of the coasts. > > > > We can add the eastern coast of Australia, where the original > > Wollongong group made the first V6 port to the Interdata 7/32 (not > > to be confused with the Labs port to the 8/32). > > To be fair, in the case of Australia almost everybody is on the east > coast, though we have had our share of FreeBSD core team members from > the "west coast" (which is really only Perth). > > 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.php > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.bowling at kev009.com Thu Jan 13 12:35:10 2022 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Wed, 12 Jan 2022 19:35:10 -0700 Subject: [TUHS] SMP: BSD vs System V (once was: moving directories in svr2) In-Reply-To: <20220103235600.GA68567@eureka.lemis.com> References: <97f563fa-5a17-424b-acc6-07cf127f496d@localhost> <20220103234411.GA19828@mcvoy.com> <20220103235600.GA68567@eureka.lemis.com> Message-ID: On Mon, Jan 3, 2022 at 5:03 PM Greg 'groggy' Lehey wrote: > On Monday, 3 January 2022 at 15:44:11 -0800, Larry McVoy wrote: > > On Mon, Jan 03, 2022 at 05:21:51PM -0600, Doug McIntyre wrote: > >> On Mon, Jan 03, 2022 at 04:15:08PM -0500, Dan Cross wrote: > >> I'd agree, 2.4 was pretty slow and chunky, 2.5 was alright, but 2.5.1 > was quite usable and stable. > >> Also by this time, the hardware was going in directions that SunOS > wouldn't keep up with. > > > > Yeah, Doug is right, SunOS was pretty simple, it didn't really take > advantage > > of SMP, Greg Limes tried to thread it but it was too big a job for one > guy. > > > > That's not to say that SunOS couldn't have evolved into SMP, I'm 100% > > sure it could have. It just didn't. It's a shame. > > An interesting question. I had always thought that SMP was (one of?) > the technical reasons why Sun moved from a BSD to a System V base. > Since then, of course, we've done lots of work on SMP support for at > least FreeBSD. Does anybody have an overview of how good the support > is compared to modern Solaris? Is there any intrinsic reason why one > should be better than the other? > > 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.php Relevant proceedings https://www.usenix.org/legacy/publications/library/proceedings/sa92/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnl at johnlabovitz.com Thu Jan 13 12:38:06 2022 From: johnl at johnlabovitz.com (John Labovitz) Date: Wed, 12 Jan 2022 21:38:06 -0500 Subject: [TUHS] *roff history as told to GNU In-Reply-To: <20220112180619.mxzojchd62vpwm2f@localhost.localdomain> References: <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> <202201120854.20C8sDRR014233@freefriends.org> <20220112180619.mxzojchd62vpwm2f@localhost.localdomain> Message-ID: On Jan 12, 2022, at 13:06, G. Branden Robinson wrote: > I've been collecting a detailed narrative history not just of the *roff > _programs_ but also of the development on the language in the roff(7) > manual page. Before RUNOFF was Peter Samson’s TJ-2 in 1963. It seems to have been the first program that incorporated the idea of input lines being interpreted as either control (with a prefix of a dot or other character) or text. I dug up this history when I wrote ‘The Electric Typesetter: The Origins of Computing in Typography’ for the American Printing History Association’s journal _Printing History_ (issue 21, 2017). Sadly they don’t have online archives; my PDF of the article is here: https://johnlabovitz.com/publications/The-electric-typesetter--The-origins-of-computing-in-typography.pdf It’s about more than markup languages, but here’s the relevant bit: > The earliest known text-formatting software, TJ-2, was created by MIT-trained computer scientist Peter Samson in 1963. Its design and architecture set the stage for text-formatting and typesetting programs for the next several decades. > > […] > > TJ-2 read lines of text as its input. Each line was collected and formatted to make justified paragraphs (of monospaced type). However, if a line started with a special control code (“overbar,” in the lingo of the PDP-1 system, its host computer), the program interpreted it as a command. There were only a few commands, including a primitive line-centering mode, some simplistic indentation, and a command that left a specific amount of vertical space for a figure (e.g., illustration) to be inserted later. > > […] > > Note that TJ-2 did not interface with a phototypesetter — or any typesetter. Its output was destined to be printed on what was essentially an automatic typewriter outfitted only with monospaced fonts. While this seems a limitation, perhaps it was a necessary constraint at the time. But the TJ-2 went on to inspire (directly or indirectly) a long branch of typesetting software beginning with RUNOFF (“A Right-Justifying Type Out Program”) in 1964, a program that used “control words scattered in the text [to] provide detailed control over the format” of text. RUNOFF substituted TJ-2’s proprietary “overbar” control code with a simple period, and expanded the set of commands to produce line and page breaks and folios (page numbers). Then, in a fairly confusing list of technical begats over a decade or so, RUNOFF (capitals) led to “runoff” (lowercase), then to “rf,” “roff,” “nroff,” and “troff” — all software programs that utilized the same basic idea as TJ-2. Links from the footnotes: TJ-2: http://www.dpbsmith.com/tj2.html RUNOFF: http://web.mit.edu/Saltzer/www/publications/CC-244.html Best, —John From douglas.mcilroy at dartmouth.edu Thu Jan 13 14:23:23 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Wed, 12 Jan 2022 23:23:23 -0500 Subject: [TUHS] Fwd: struct(1) revived! And a request for help In-Reply-To: <202201121258.20CCwPEF013323@freefriends.org> References: <202201121258.20CCwPEF013323@freefriends.org> Message-ID: Arnold, I'm very glad you have revived struct. It is an important historical artifact, and it's nice to have it freed from distracting obsolete usage. To my mind, struct ranks among the top accomplishments of our department at Bell Labs. It was also a lesson in humility to me. When Brenda proposed struct, it was obvious that it could be built, but I advised against doing so. I thought it would take an endless pile of special cases to generate respectable Ratfor. She demurred, saying that she thought she could do better than that. And she was right. She produced not only working Ratfor programs, but a canonical-form theorem that distinguished those programs from all the ad hoc alternatives I had imagined. The value of the theorem was attested by users' reports that the derived Ratfort was easier to understand than the Fortran they had written themselves. Doug ---------- Forwarded message --------- From: Date: Wed, Jan 12, 2022 at 7:58 AM Subject: [TUHS] struct(1) revived! And a request for help To: Hello All. We recently discussed Brenda Baker's struct program, that read Fortran and generated Ratfor. Many of us remarked as to what a really cool program it was and how much we admired it, myself included. For fun (for some definition of "fun") I decided to try to bring the code into the present. I set up a GitHub repo with the V7, V8 and V10 code, and then started work in a separate branch. (https://github.com/arnoldrobbins/struct, branch "modernize".) The program has three main parts: - structure, which reads Fortran and outputs something that is almost Ratfor on standard output. - beautify, which reads the output of structure and finishes the job, primarily making conditions readable (.not. --> !, removing double negatives, etc.) - struct.sh - a simple shell script that runs the above two components. This is what the user invokes. The code was written in 1974. As such, it is rife with "type punning" between int, int *, int **, and char *. These produce a lot of warnings from a modern day C compiler. The code also uses a, er, "unique" bracing style, making it nearly illegible to my stuck-in-a-rut programming brain. Here is what I've accomplished so far: * Converted every function definition and declaration to use modern (ANSI) C style, adding a header file with function declarations that is included everywhere. * Run all the code through the indent program, formatting it as traditional K&R bracing style, with tabs. * Fixed some macros to use modern style for getting parameter values as strings into the macros. * Fixed a few small bugs here and there. * Fixed beautify to work with modern byacc/bison (%union) and to work with flex instead of lex. This latter was a challenge. In structure, only three files still generate warnings, but they all relate to integer <--> pointer assignment / use as. However, when compiled in 32 bit mode (gcc -m32), where sizeof(int) is the same as sizeof(pointer), despite the warnings, structure works!! Beautify works, whether compiled in 32 or 64 bit mode. What I've done so far has been mostly mechanical. I hereby request help from anyone who's interested in making progress on "the hard part" --- those three files that still generate warnings. I think the right way to go is to replace int's with a union that holds and int, a char* and an int*. But I have not had the quiet time to dive into the code to see if this can be done. Anyone who has some time to devote to this and is interested, please drop me a note off-list. Thanks, Arnold Robbins From rdm at cfcl.com Thu Jan 13 16:30:56 2022 From: rdm at cfcl.com (Rich Morin) Date: Wed, 12 Jan 2022 22:30:56 -0800 Subject: [TUHS] struct(1) revived! And a request for help In-Reply-To: References: <202201121258.20CCwPEF013323@freefriends.org> Message-ID: <0C95C05B-53CA-4AF8-8E24-4C24D34ED053@cfcl.com> > On Jan 12, 2022, at 20:23, Douglas McIlroy wrote: > > ... users' reports that the derived Ratfort was easier to > understand than the Fortran they had written themselves. In the late 70's, I started working on some Fortran code for an astrophysicist. The code was written in Fortran II and I found it very difficult to read. So, I turned it into VAX VMS Fortran 77 (not Ratfor, but a lot closer to it :-). The scientist was _not_ happy, saying that he would no longer be able to read his code. I informed him that (a) Fortran 77 was the current standard and (b) he was welcome to go back to his Fortran II version, but that he'd have to do so without my assistance. He grumbled a bit, but acquiesced... -r From lars at nocrew.org Thu Jan 13 17:42:17 2022 From: lars at nocrew.org (Lars Brinkhoff) Date: Thu, 13 Jan 2022 07:42:17 +0000 Subject: [TUHS] *roff history as told to GNU In-Reply-To: (John Labovitz's message of "Wed, 12 Jan 2022 21:38:06 -0500") References: <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> <202201120854.20C8sDRR014233@freefriends.org> <20220112180619.mxzojchd62vpwm2f@localhost.localdomain> Message-ID: <7wiluo9j52.fsf@junk.nocrew.org> John Labovitz wrote: > The earliest known text-formatting software, TJ-2, was created by > MIT-trained computer scientist Peter Samson in 1963. I see claimed predecessors are JUSTIFY and TJ-1. How do you feel about those? From thomas.paulsen at firemail.de Thu Jan 13 20:13:42 2022 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Thu, 13 Jan 2022 11:13:42 +0100 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: References: <250868b3-9e0c-5ff2-8506-e2da5c73862a@gmail.com> Message-ID: nevertheless it's still an Adobe product. --- Ursprüngliche Nachricht --- Von: John Cowan Datum: 12.01.2022 20:54:34 An: Blake McBride Betreff: Re: [TUHS] TeX and groff (was: roff(7)) an Adobe product. From johnl at johnlabovitz.com Thu Jan 13 23:47:28 2022 From: johnl at johnlabovitz.com (John Labovitz) Date: Thu, 13 Jan 2022 08:47:28 -0500 Subject: [TUHS] *roff history as told to GNU In-Reply-To: <7wiluo9j52.fsf@junk.nocrew.org> References: <20220101031511.GB8135@mcvoy.com> <20220111015901.GE25103@eureka.lemis.com> <4409b91cd794867d@orthanc.ca> <20220111024218.GE3441@mcvoy.com> <202201120854.20C8sDRR014233@freefriends.org> <20220112180619.mxzojchd62vpwm2f@localhost.localdomain> <7wiluo9j52.fsf@junk.nocrew.org> Message-ID: <2DD03634-EEE7-4311-9CFB-1FCBBB3C927A@johnlabovitz.com> On Jan 13, 2022, at 02:42, Lars Brinkhoff wrote: > John Labovitz wrote: >> The earliest known text-formatting software, TJ-2, was created by >> MIT-trained computer scientist Peter Samson in 1963. > > I see claimed predecessors are JUSTIFY and TJ-1. How do you feel about > those? I’m sure I looked for TJ-1 when I did this research — an obvious question, given the ‘2’ suffix — but didn’t find anything then. I’m not familiar with JUSTIFY. Do you have links/info for those? —John From arnold at skeeve.com Fri Jan 14 01:19:05 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 13 Jan 2022 08:19:05 -0700 Subject: [TUHS] Fwd: struct(1) revived! And a request for help In-Reply-To: References: <202201121258.20CCwPEF013323@freefriends.org> Message-ID: <202201131519.20DFJ55W003349@freefriends.org> Thanks Doug. Let's hope it can be brought all the way into 64 bit mode. Dr. Baker has been brought into the loop, so I am hopeful. :-) Arnold Douglas McIlroy wrote: > Arnold, > > I'm very glad you have revived struct. It is an important historical > artifact, and it's nice to have it freed from distracting obsolete > usage. > > To my mind, struct ranks among the top accomplishments of our > department at Bell Labs. It was also a lesson in humility to me. > > When Brenda proposed struct, it was obvious that it could be built, > but I advised against doing so. I thought it would take an endless > pile of special cases to generate respectable Ratfor. She demurred, > saying that she thought she could do better than that. And she was > right. She produced not only working Ratfor programs, but a > canonical-form theorem that distinguished those programs from all the > ad hoc alternatives I had imagined. The value of the theorem was > attested by users' reports that the derived Ratfort was easier to > understand than the Fortran they had written themselves. > > Doug > > ---------- Forwarded message --------- > From: > Date: Wed, Jan 12, 2022 at 7:58 AM > Subject: [TUHS] struct(1) revived! And a request for help > To: > > > Hello All. > > We recently discussed Brenda Baker's struct program, that read Fortran > and generated Ratfor. Many of us remarked as to what a really cool > program it was and how much we admired it, myself included. > > For fun (for some definition of "fun") I decided to try to bring the code > into the present. I set up a GitHub repo with the V7, V8 and V10 code, > and then started work in a separate branch. > > (https://github.com/arnoldrobbins/struct, branch "modernize".) > > The program has three main parts: > > - structure, which reads Fortran and outputs something that is > almost Ratfor on standard output. > > - beautify, which reads the output of structure and finishes the job, > primarily making conditions readable (.not. --> !, removing double > negatives, etc.) > > - struct.sh - a simple shell script that runs the above two components. > This is what the user invokes. > > The code was written in 1974. As such, it is rife with "type punning" > between int, int *, int **, and char *. These produce a lot of warnings > from a modern day C compiler. The code also uses a, er, "unique" bracing > style, making it nearly illegible to my stuck-in-a-rut programming brain. > > Here is what I've accomplished so far: > > * Converted every function definition and declaration to use modern (ANSI) > C style, adding a header file with function declarations that is > included everywhere. > > * Run all the code through the indent program, formatting it as traditional > K&R bracing style, with tabs. > > * Fixed some macros to use modern style for getting parameter values as strings > into the macros. > > * Fixed a few small bugs here and there. > > * Fixed beautify to work with modern byacc/bison (%union) and to work with > flex instead of lex. This latter was a challenge. > > In structure, only three files still generate warnings, but they all relate > to integer <--> pointer assignment / use as. However, when compiled in > 32 bit mode (gcc -m32), where sizeof(int) is the same as sizeof(pointer), > despite the warnings, structure works!! > > Beautify works, whether compiled in 32 or 64 bit mode. > > What I've done so far has been mostly mechanical. I hereby request help from > anyone who's interested in making progress on "the hard part" --- those three > files that still generate warnings. > > I think the right way to go is to replace int's with a union that holds and > int, a char* and an int*. But I have not had the quiet time to dive into > the code to see if this can be done. > > Anyone who has some time to devote to this and is interested, please drop > me a note off-list. > > Thanks, > > Arnold Robbins From crossd at gmail.com Fri Jan 14 01:37:52 2022 From: crossd at gmail.com (Dan Cross) Date: Thu, 13 Jan 2022 10:37:52 -0500 Subject: [TUHS] Coastal cultures, collaboration, creativity and Sun vs DEC. In-Reply-To: References: Message-ID: On Tue, Jan 11, 2022 at 2:34 PM John Cowan wrote: > On Tue, Jan 11, 2022 at 1:37 PM Dan Cross wrote: > >> It seems like Unix is largely a child of the coasts. >> >> > We can add the eastern coast of Australia, where the original Wollongong > group made the first V6 port to the Interdata 7/32 (not to be confused with > the Labs port to the 8/32). The Western U.S. company of the same name was > formed to sell it, but I don't know if any of the Ozites moved to Palo Alto. > Oh certainly. I didn't mean for my list of locations other than Berkeley and Murray Hill to be exhaustive, nor to disregard the important work done elsewhere (including of course Australia). - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Fri Jan 14 01:44:40 2022 From: crossd at gmail.com (Dan Cross) Date: Thu, 13 Jan 2022 10:44:40 -0500 Subject: [TUHS] Coastal cultures, collaboration, creativity and Sun vs DEC. In-Reply-To: References: Message-ID: On Tue, Jan 11, 2022 at 3:18 PM Rob Pike wrote: > I see a stylistic connection between the style of writing of the manuals > and the New York journalism, especially that of the New Yorker. > Oh that's really interesting; as a New Yorker who subscribes to the New Yorker, this makes so much sense and is certainly more sensible than my hypothesized connection with Warhol and the Factory. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Fri Jan 14 02:32:22 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Thu, 13 Jan 2022 08:32:22 -0800 Subject: [TUHS] Coastal cultures, collaboration, creativity and Sun vs DEC. In-Reply-To: References: Message-ID: On Jan 11, 2022, at 11:34 AM, John Cowan wrote: > > > > On Tue, Jan 11, 2022 at 1:37 PM Dan Cross > wrote: > > It seems like Unix is largely a child of the coasts. > > We can add the eastern coast of Australia, where the original Wollongong group made the first V6 port to the Interdata 7/32 (not to be confused with the Labs port to the 8/32). The Western U.S. company of the same name was formed to sell it, but I don't know if any of the Ozites moved to Palo Alto. This port to Interdata 7/32 was done by Richard Miller @ the University of Wollongong. AFAIK he is a Canadian (now living in the UK). No idea if any Canadian coastal cultures were involved! Much later he also did the plan9 port to the first RaspberryPi & subsequent models. His coding style is certainly quite minimal. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Fri Jan 14 02:48:56 2022 From: rich.salz at gmail.com (Richard Salz) Date: Thu, 13 Jan 2022 11:48:56 -0500 Subject: [TUHS] Coastal cultures, collaboration, creativity and Sun vs DEC. In-Reply-To: References: Message-ID: What about Jim Culp and IIASA? Didn't he do the first BSD job control stuff? What else did they provide? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Fri Jan 14 03:20:27 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Thu, 13 Jan 2022 09:20:27 -0800 Subject: [TUHS] Coastal cultures, collaboration, creativity and Sun vs DEC. In-Reply-To: References: Message-ID: On Jan 13, 2022, at 8:48 AM, Richard Salz wrote: > > What about Jim Culp and IIASA? Didn't he do the first BSD job control stuff? What else did they provide? Indeed he did. IIASA is in landlocked Austria! I read about this a very long time ago so don't recall if there was anything else as significant. ^Z was very useful when we didn't have a graphics display and multiple windows. Even now I have a few ^Z'ed processes lying about! From douglas.mcilroy at dartmouth.edu Fri Jan 14 03:31:13 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Thu, 13 Jan 2022 12:31:13 -0500 Subject: [TUHS] TeX and groff (was: roff(7)) Message-ID: > If I can be so bold as to offer an interpretation: Doug's approximations > treat ellipses as mathematical objects and algorithmically determine what > pixels are closest to points on the infinitesimally-thin curves, while > Knuth's (or one his students') method acknowledges that the curve has a > width defined by the nib Just so. > I find it impossible that neither Knuth nor Hobby were unaware of McIlroy's > work and vice-versa; of course he would have known about and examined troff > just as the Bell Labs folks knew about TeX. We were generally aware of each other's work. My papers on drawing lines, circles, and ellipses on rasters, though, were barely connected to troff. Troff did not contain any drawing algorithms. That work was relegated to the rendering programs that interpreted ditroff output. Thus publication-quality rendering with support for thick lines was outsourced to Adobe and Mergenthaler. Various PostScript or ditroff postprocessors for screen-based terminals were written in house. These programs paid little or no attention to fonts and line widths. But the blit renderers made a tenuous connection between my ellipse algorithm and troff, since my work on the topic was stimulated by Rob's need for an ellipse generator. Doug From cowan at ccil.org Fri Jan 14 05:56:14 2022 From: cowan at ccil.org (John Cowan) Date: Thu, 13 Jan 2022 14:56:14 -0500 Subject: [TUHS] Coastal cultures, collaboration, creativity and Sun vs DEC. In-Reply-To: References: Message-ID: On Thu, Jan 13, 2022 at 12:20 PM Bakul Shah wrote: > Even now I have a few ^Z'ed processes lying about! So do I. The mysql client process is one I need occasionally and I don't want to dedicate another tab to it, but it's a pain in the ass to log in every time I do need it. So I keep it in the background of my "general purposes" tab, and fg it whenever I need it. The trick is to remember to type ^Z instead of ^D when I'm finished. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Fri Jan 14 06:00:50 2022 From: cowan at ccil.org (John Cowan) Date: Thu, 13 Jan 2022 15:00:50 -0500 Subject: [TUHS] TeX and groff (was: roff(7)) In-Reply-To: References: <250868b3-9e0c-5ff2-8506-e2da5c73862a@gmail.com> Message-ID: Only in the sense that Fortran is an IBM product. (IBM's Fortran compilers and runtimes are IBM products, but that's another matter.) On Thu, Jan 13, 2022 at 5:13 AM Thomas Paulsen wrote: > nevertheless it's still an Adobe product. > > --- Ursprüngliche Nachricht --- > Von: John Cowan > Datum: 12.01.2022 20:54:34 > An: Blake McBride > Betreff: Re: [TUHS] TeX and groff (was: roff(7)) > > an Adobe product. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fariborz.t at gmail.com Fri Jan 14 08:21:33 2022 From: fariborz.t at gmail.com (Skip Tavakkolian) Date: Thu, 13 Jan 2022 14:21:33 -0800 Subject: [TUHS] struct(1) revived! And a request for help In-Reply-To: <202201121258.20CCwPEF013323@freefriends.org> References: <202201121258.20CCwPEF013323@freefriends.org> Message-ID: On Wed, Jan 12, 2022 at 4:59 AM wrote: > > Hello All. > > We recently discussed Brenda Baker's struct program, that read Fortran > and generated Ratfor. Many of us remarked as to what a really cool > program it was and how much we admired it, myself included. > > For fun (for some definition of "fun") I decided to try to bring the code > into the present. I set up a GitHub repo with the V7, V8 and V10 code, > and then started work in a separate branch. > > (https://github.com/arnoldrobbins/struct, branch "modernize".) > > The program has three main parts: > > - structure, which reads Fortran and outputs something that is > almost Ratfor on standard output. > > - beautify, which reads the output of structure and finishes the job, > primarily making conditions readable (.not. --> !, removing double > negatives, etc.) > > - struct.sh - a simple shell script that runs the above two components. > This is what the user invokes. > > The code was written in 1974. As such, it is rife with "type punning" > between int, int *, int **, and char *. These produce a lot of warnings > from a modern day C compiler. The code also uses a, er, "unique" bracing > style, making it nearly illegible to my stuck-in-a-rut programming brain. That is the same style that P.J. Plauger/Whitesmiths used in Idris OS. The brace indentation levels also match the Ratfor code in Software Tools. > > Here is what I've accomplished so far: > > * Converted every function definition and declaration to use modern (ANSI) > C style, adding a header file with function declarations that is > included everywhere. > > * Run all the code through the indent program, formatting it as traditional > K&R bracing style, with tabs. > > * Fixed some macros to use modern style for getting parameter values as strings > into the macros. > > * Fixed a few small bugs here and there. > > * Fixed beautify to work with modern byacc/bison (%union) and to work with > flex instead of lex. This latter was a challenge. > > In structure, only three files still generate warnings, but they all relate > to integer <--> pointer assignment / use as. However, when compiled in > 32 bit mode (gcc -m32), where sizeof(int) is the same as sizeof(pointer), > despite the warnings, structure works!! > > Beautify works, whether compiled in 32 or 64 bit mode. > > What I've done so far has been mostly mechanical. I hereby request help from > anyone who's interested in making progress on "the hard part" --- those three > files that still generate warnings. > > I think the right way to go is to replace int's with a union that holds and > int, a char* and an int*. But I have not had the quiet time to dive into > the code to see if this can be done. > > Anyone who has some time to devote to this and is interested, please drop > me a note off-list. > > Thanks, > > Arnold Robbins From pugs at ieee.org Fri Jan 14 10:04:04 2022 From: pugs at ieee.org (Tom Lyon) Date: Thu, 13 Jan 2022 16:04:04 -0800 Subject: [TUHS] Brian Kernighan and very early *roff history Message-ID: Most of y'all are aware of Brian Kernighan's troff involvement. My understanding is that he pretty much took over nroff/troff after Joe Ossana died, and came out with ditroff. But Brian had much earlier involvement with non-UNIX *roff. When he was pursuing his PhD at Princeton, he spent a summer at MIT using CTSS and RUNOFF. When he came back to P'ton, he wrote a ROFF for the IBM 7094, later translated to the IBM 360. Many generations of students, myself included, use the IBM ROFF (batch, not interactive) as a much friendlier alternative to dumb typewriters. I don't know if 360 ROFF spread beyond Princeton, but I wouldn't be surprised. BTW, during my summer at Bell, nroff/troff was one of the few programs I could not port to the Interdata 8/32 - it was just a mess of essentially typeless code. I don't think Joe Ossana got around to it either before he died. -- - Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Fri Jan 14 10:10:52 2022 From: robpike at gmail.com (Rob Pike) Date: Fri, 14 Jan 2022 11:10:52 +1100 Subject: [TUHS] Brian Kernighan and very early *roff history In-Reply-To: References: Message-ID: Dennis spent quite a bit of time cleaning up the troff code in the late 1980s, if I remember right, moving it to modern C. He got annoyed by it one day. It was the "ditroff" variant although honestly I don't remember us ever calling it that. It was just the current version of troff. Not sure where the name came from. Perhaps it was us but I think of it as a foreign name. -rob On Fri, Jan 14, 2022 at 11:05 AM Tom Lyon via TUHS wrote: > Most of y'all are aware of Brian Kernighan's troff involvement. My > understanding is that he pretty much took over nroff/troff after Joe Ossana > died, and came out with ditroff. > > But Brian had much earlier involvement with non-UNIX *roff. When he was > pursuing his PhD at Princeton, he spent a summer at MIT using CTSS and > RUNOFF. When he came back to P'ton, he wrote a ROFF for the IBM 7094, > later translated to the IBM 360. Many generations of students, myself > included, use the IBM ROFF (batch, not interactive) as a much friendlier > alternative to dumb typewriters. I don't know if 360 ROFF spread beyond > Princeton, but I wouldn't be surprised. > > BTW, during my summer at Bell, nroff/troff was one of the few programs I > could not port to the Interdata 8/32 - it was just a mess of essentially > typeless code. I don't think Joe Ossana got around to it either before he > died. > > -- > - Tom > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Fri Jan 14 17:38:20 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 14 Jan 2022 00:38:20 -0700 Subject: [TUHS] Brian Kernighan and very early *roff history In-Reply-To: References: Message-ID: <202201140738.20E7cK9S007222@freefriends.org> The name 'ditroff' for Device Independent Troff was how AT&T marketed / sold / licensed it when they released it to the world. The new name was necessary to distinguish it from the original troff in V7 / System III / System V. It's understandable that inside Research no such distinction was made. Nonetheless, the V8 and V10 archives show that the C/A/T variant was still around (at least in /usr/src/cmd) under the name otroff. HTH, Arnold Rob Pike wrote: > Dennis spent quite a bit of time cleaning up the troff code in the late > 1980s, if I remember right, moving it to modern C. He got annoyed by it one > day. It was the "ditroff" variant although honestly I don't remember us > ever calling it that. It was just the current version of troff. Not sure > where the name came from. Perhaps it was us but I think of it as a foreign > name. > > -rob > > > On Fri, Jan 14, 2022 at 11:05 AM Tom Lyon via TUHS > wrote: > > > Most of y'all are aware of Brian Kernighan's troff involvement. My > > understanding is that he pretty much took over nroff/troff after Joe Ossana > > died, and came out with ditroff. > > > > But Brian had much earlier involvement with non-UNIX *roff. When he was > > pursuing his PhD at Princeton, he spent a summer at MIT using CTSS and > > RUNOFF. When he came back to P'ton, he wrote a ROFF for the IBM 7094, > > later translated to the IBM 360. Many generations of students, myself > > included, use the IBM ROFF (batch, not interactive) as a much friendlier > > alternative to dumb typewriters. I don't know if 360 ROFF spread beyond > > Princeton, but I wouldn't be surprised. > > > > BTW, during my summer at Bell, nroff/troff was one of the few programs I > > could not port to the Interdata 8/32 - it was just a mess of essentially > > typeless code. I don't think Joe Ossana got around to it either before he > > died. > > > > -- > > - Tom > > From jaapna at xs4all.nl Fri Jan 14 20:13:35 2022 From: jaapna at xs4all.nl (Jaap Akkerhuis) Date: Fri, 14 Jan 2022 11:13:35 +0100 Subject: [TUHS] Brian Kernighan and very early *roff history In-Reply-To: References: Message-ID: <3BEC16DC-5F58-4D9E-8577-7578DE696F03@xs4all.nl> > On Jan 14, 2022, at 1:10, Rob Pike wrote: > > Dennis spent quite a bit of time cleaning up the troff code in the late 1980s, if I remember right, moving it to modern C. He got annoyed by it one day. If I remember correctly, it was actually Ken. He also turned it in a single binary. (Troff -N turned it into nroff). > It was the "ditroff" variant although honestly I don't remember us ever calling it that. It was just the current version of troff. Not sure where the name came from. Perhaps it was us but I think of it as a foreign name. Originally Brian called it "Typesetter Independent Troff" in the article he wrote about it and for some reason people started to call it "Device Independent". jaap -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: Message signed with OpenPGP URL: From robpike at gmail.com Fri Jan 14 21:48:03 2022 From: robpike at gmail.com (Rob Pike) Date: Fri, 14 Jan 2022 22:48:03 +1100 Subject: [TUHS] Brian Kernighan and very early *roff history In-Reply-To: <3BEC16DC-5F58-4D9E-8577-7578DE696F03@xs4all.nl> References: <3BEC16DC-5F58-4D9E-8577-7578DE696F03@xs4all.nl> Message-ID: It was definitely Dennis, at least for the cleanup part I was referring to. -rob On Fri, Jan 14, 2022 at 9:14 PM Jaap Akkerhuis wrote: > > > > On Jan 14, 2022, at 1:10, Rob Pike wrote: > > > > Dennis spent quite a bit of time cleaning up the troff code in the late > 1980s, if I remember right, moving it to modern C. He got annoyed by it one > day. > > If I remember correctly, it was actually Ken. He also turned it > in a single binary. (Troff -N turned it into nroff). > > > It was the "ditroff" variant although honestly I don't remember us ever > calling it that. It was just the current version of troff. Not sure where > the name came from. Perhaps it was us but I think of it as a foreign name. > > Originally Brian called it "Typesetter Independent Troff" in the > article he wrote about it and for some reason people started to > call it "Device Independent". > > jaap > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aap at papnet.eu Fri Jan 14 21:59:51 2022 From: aap at papnet.eu (Angelo Papenhoff) Date: Fri, 14 Jan 2022 12:59:51 +0100 Subject: [TUHS] Brian Kernighan and very early *roff history In-Reply-To: References: Message-ID: Since the topic is on the history of troff, I'd like to mention again that to my knowledge no troff version before the C rewrite in v7 is publicly available anywhere. v6 only has nroff, v5 only has roff even though nroff/troff appeared in v4. The v6 distribution has deleted directory entries for troff source but not the files themselves. I hope it is not lost. Maybe someone here has an idea where it could be found? aap From jnc at mercury.lcs.mit.edu Fri Jan 14 23:07:52 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 14 Jan 2022 08:07:52 -0500 (EST) Subject: [TUHS] Brian Kernighan and very early *roff history Message-ID: <20220114130752.32F0218C090@mercury.lcs.mit.edu> > From: Angelo Papenhoff > to my knowledge no troff version before the C rewrite in v7 Apologies if I missed something, but between this list and COFF there's so much low S/N traffic I skip a lot of it. Having said that, was there ever a troff in assembler? I'd always had the impression that the first one was in C. > The v6 distribution has deleted directory entries for troff source but > not the files themselves. I hope it is not lost. Maybe someone here has > an idea where it could be found? The MIT 'V6+' (I think it's probably basically PWB1) system had troff - i guess it 'fell off the back of a truck', like a lot of other stuff MIT had, such as 'typesetter C', the Portable C Compiler, etc. Theirs was modified to produce output for a Varian (I forget which model, maybe the docs or driver say). nroff on that system seems to have been generated from the troff sources; the assembler nroff sources aren't present. I looked at its n1.c, and compared it to the V7 one: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/troff/n1.c and this one appears to be slightly earlier; e.g. it starts: #include "tdef.h" #include "t.h" #include "tw.h" /* troff1.c consume options, initialization, main loop, input routines, escape function calling */ extern int stdi; and in the argument processing, it has quite a lot fewer. So that one is a "troff version before the C rewrite in .. v7", but it is in C. Is that of any interest? Noel From aap at papnet.eu Fri Jan 14 23:27:59 2022 From: aap at papnet.eu (Angelo Papenhoff) Date: Fri, 14 Jan 2022 14:27:59 +0100 Subject: [TUHS] Brian Kernighan and very early *roff history In-Reply-To: <20220114130752.32F0218C090@mercury.lcs.mit.edu> References: <20220114130752.32F0218C090@mercury.lcs.mit.edu> Message-ID: On 14/01/22, Noel Chiappa wrote: > > From: Angelo Papenhoff > > > to my knowledge no troff version before the C rewrite in v7 > > Apologies if I missed something, but between this list and COFF there's so > much low S/N traffic I skip a lot of it. Having said that, was there ever a > troff in assembler? I'd always had the impression that the first one was in C. Yes, they were both originally written in assembler. v6 has assembler sources for nroff and deleted directory entries of troff (and others): 00064e00: 6d01 726f 6666 332e 7300 0000 0000 0000 m.roff3.s....... 00064e10: 6c01 726f 6666 342e 7300 0000 0000 0000 l.roff4.s....... 00064e20: 6b01 726f 6666 352e 7300 0000 0000 0000 k.roff5.s....... 00064e30: 6a01 726f 6666 372e 7300 0000 0000 0000 j.roff7.s....... 00064e40: 6901 726f 6666 382e 7300 0000 0000 0000 i.roff8.s....... 00064e50: 0000 7375 6672 6300 0000 0000 0000 0000 ..sufrc......... 00064e60: 6701 7375 6674 6162 2e73 0000 0000 0000 g.suftab.s...... 00064e70: 0000 7463 6174 7369 6d2e 7300 0000 0000 ..tcatsim.s..... 00064e80: 0000 7472 6300 0000 0000 0000 0000 0000 ..trc........... 00064e90: 0000 7472 6f66 6631 2e73 0000 0000 0000 ..troff1.s...... 00064ea0: 0000 7472 6f66 6632 2e73 0000 0000 0000 ..troff2.s...... 00064eb0: 0000 7472 6f66 6633 2e73 0000 0000 0000 ..troff3.s...... 00064ec0: 0000 7472 6f66 6634 2e73 0000 0000 0000 ..troff4.s...... 00064ed0: 0000 7472 6f66 6635 2e73 0000 0000 0000 ..troff5.s...... 00064ee0: 0000 7472 6f66 6636 2e73 0000 0000 0000 ..troff6.s...... 00064ef0: 0000 7472 6f66 6636 6100 0000 0000 0000 ..troff6a....... 00064f00: 0000 7472 6f66 6638 2e73 0000 0000 0000 ..troff8.s...... 00064f10: 0000 7878 7878 7800 0000 0000 0000 0000 ..xxxxx......... > So that one is a "troff version before the C rewrite in .. v7", but it is in > C. Is that of any interest? Without having looked into it more than you have it looks like it is just an earlier version of the C code, but what I'm after is the original assembly. aap From ralph at inputplus.co.uk Fri Jan 14 23:35:45 2022 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Fri, 14 Jan 2022 13:35:45 +0000 Subject: [TUHS] Brian Kernighan and very early *roff history In-Reply-To: References: <20220114130752.32F0218C090@mercury.lcs.mit.edu> Message-ID: <20220114133545.C83CA219E2@orac.inputplus.co.uk> Hi aap, > v6 has assembler sources for nroff and deleted directory entries of > troff (and others): > > 00064e00: 6d01 726f 6666 332e 7300 0000 0000 0000 m.roff3.s....... > 00064e10: 6c01 726f 6666 342e 7300 0000 0000 0000 l.roff4.s....... > 00064e20: 6b01 726f 6666 352e 7300 0000 0000 0000 k.roff5.s....... > 00064e30: 6a01 726f 6666 372e 7300 0000 0000 0000 j.roff7.s....... > 00064e40: 6901 726f 6666 382e 7300 0000 0000 0000 i.roff8.s....... > 00064e50: 0000 7375 6672 6300 0000 0000 0000 0000 ..sufrc......... > 00064e60: 6701 7375 6674 6162 2e73 0000 0000 0000 g.suftab.s...... > 00064e70: 0000 7463 6174 7369 6d2e 7300 0000 0000 ..tcatsim.s..... > 00064e80: 0000 7472 6300 0000 0000 0000 0000 0000 ..trc........... > 00064e90: 0000 7472 6f66 6631 2e73 0000 0000 0000 ..troff1.s...... Are inodes 0x0168, etc., re-used elsewhere? If so, it would be interesting to where. Or is there a chance they still hold useful information about blocks which may contain troff content? -- Cheers, Ralph. From will.senn at gmail.com Fri Jan 14 23:55:25 2022 From: will.senn at gmail.com (Will Senn) Date: Fri, 14 Jan 2022 07:55:25 -0600 Subject: [TUHS] Brian Kernighan and very early *roff history In-Reply-To: <20220114133545.C83CA219E2@orac.inputplus.co.uk> References: <20220114130752.32F0218C090@mercury.lcs.mit.edu> <20220114133545.C83CA219E2@orac.inputplus.co.uk> Message-ID: Hi AAP, Dunno if this is what you're after, but Dennis's v5 tape has roff assembly sources in s7 https://www.tuhs.org/Archive/Distributions/Research/Dennis_v5/v5root.tar.gz: Will On 1/14/22 7:35 AM, Ralph Corderoy wrote: > Hi aap, > >> v6 has assembler sources for nroff and deleted directory entries of >> troff (and others): >> >> 00064e00: 6d01 726f 6666 332e 7300 0000 0000 0000 m.roff3.s....... >> 00064e10: 6c01 726f 6666 342e 7300 0000 0000 0000 l.roff4.s....... >> 00064e20: 6b01 726f 6666 352e 7300 0000 0000 0000 k.roff5.s....... >> 00064e30: 6a01 726f 6666 372e 7300 0000 0000 0000 j.roff7.s....... >> 00064e40: 6901 726f 6666 382e 7300 0000 0000 0000 i.roff8.s....... >> 00064e50: 0000 7375 6672 6300 0000 0000 0000 0000 ..sufrc......... >> 00064e60: 6701 7375 6674 6162 2e73 0000 0000 0000 g.suftab.s...... >> 00064e70: 0000 7463 6174 7369 6d2e 7300 0000 0000 ..tcatsim.s..... >> 00064e80: 0000 7472 6300 0000 0000 0000 0000 0000 ..trc........... >> 00064e90: 0000 7472 6f66 6631 2e73 0000 0000 0000 ..troff1.s...... > Are inodes 0x0168, etc., re-used elsewhere? If so, it would be > interesting to where. > > Or is there a chance they still hold useful information about blocks > which may contain troff content? > From will.senn at gmail.com Fri Jan 14 23:58:14 2022 From: will.senn at gmail.com (Will Senn) Date: Fri, 14 Jan 2022 07:58:14 -0600 Subject: [TUHS] Brian Kernighan and very early *roff history In-Reply-To: References: <20220114130752.32F0218C090@mercury.lcs.mit.edu> <20220114133545.C83CA219E2@orac.inputplus.co.uk> Message-ID: <624bf677-2acd-b25d-4bdd-6f4c4e897510@gmail.com> On 1/14/22 7:55 AM, Will Senn wrote: > Hi AAP, > > Dunno if this is what you're after, but Dennis's v5 tape has roff > assembly sources in s7 > https://www.tuhs.org/Archive/Distributions/Research/Dennis_v5/v5root.tar.gz: > > > Will Oops. You're looking for troff, not roff. Sorry. Will From lm at mcvoy.com Sat Jan 15 00:08:55 2022 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 14 Jan 2022 06:08:55 -0800 Subject: [TUHS] Brian Kernighan and very early *roff history In-Reply-To: <3BEC16DC-5F58-4D9E-8577-7578DE696F03@xs4all.nl> References: <3BEC16DC-5F58-4D9E-8577-7578DE696F03@xs4all.nl> Message-ID: <20220114140855.GB11735@mcvoy.com> On Fri, Jan 14, 2022 at 11:13:35AM +0100, Jaap Akkerhuis wrote: > > > > On Jan 14, 2022, at 1:10, Rob Pike wrote: > > > > Dennis spent quite a bit of time cleaning up the troff code in the late 1980s, if I remember right, moving it to modern C. He got annoyed by it one day. > > If I remember correctly, it was actually Ken. He also turned it > in a single binary. (Troff -N turned it into nroff). > > > It was the "ditroff" variant although honestly I don't remember us ever calling it that. It was just the current version of troff. Not sure where the name came from. Perhaps it was us but I think of it as a foreign name. > > Originally Brian called it "Typesetter Independent Troff" in the > article he wrote about it and for some reason people started to > call it "Device Independent". TIT vs DIT might be why? From will.senn at gmail.com Sat Jan 15 00:25:48 2022 From: will.senn at gmail.com (Will Senn) Date: Fri, 14 Jan 2022 08:25:48 -0600 Subject: [TUHS] Brian Kernighan and very early *roff history In-Reply-To: References: <20220114130752.32F0218C090@mercury.lcs.mit.edu> Message-ID: <99de2f21-6c29-4156-efc6-98ea83d391fc@gmail.com> On 1/14/22 7:27 AM, Angelo Papenhoff wrote: > On 14/01/22, Noel Chiappa wrote: >> > From: Angelo Papenhoff >> >> > to my knowledge no troff version before the C rewrite in v7 >> >> Apologies if I missed something, but between this list and COFF there's so >> much low S/N traffic I skip a lot of it. Having said that, was there ever a >> troff in assembler? I'd always had the impression that the first one was in C. > Yes, they were both originally written in assembler. v6 has assembler > sources for nroff and deleted directory entries of troff (and others): > > 00064e00: 6d01 726f 6666 332e 7300 0000 0000 0000 m.roff3.s....... > 00064e10: 6c01 726f 6666 342e 7300 0000 0000 0000 l.roff4.s....... > 00064e20: 6b01 726f 6666 352e 7300 0000 0000 0000 k.roff5.s....... > 00064e30: 6a01 726f 6666 372e 7300 0000 0000 0000 j.roff7.s....... > 00064e40: 6901 726f 6666 382e 7300 0000 0000 0000 i.roff8.s....... > 00064e50: 0000 7375 6672 6300 0000 0000 0000 0000 ..sufrc......... > 00064e60: 6701 7375 6674 6162 2e73 0000 0000 0000 g.suftab.s...... > 00064e70: 0000 7463 6174 7369 6d2e 7300 0000 0000 ..tcatsim.s..... > 00064e80: 0000 7472 6300 0000 0000 0000 0000 0000 ..trc........... > 00064e90: 0000 7472 6f66 6631 2e73 0000 0000 0000 ..troff1.s...... > 00064ea0: 0000 7472 6f66 6632 2e73 0000 0000 0000 ..troff2.s...... > 00064eb0: 0000 7472 6f66 6633 2e73 0000 0000 0000 ..troff3.s...... > 00064ec0: 0000 7472 6f66 6634 2e73 0000 0000 0000 ..troff4.s...... > 00064ed0: 0000 7472 6f66 6635 2e73 0000 0000 0000 ..troff5.s...... > 00064ee0: 0000 7472 6f66 6636 2e73 0000 0000 0000 ..troff6.s...... > 00064ef0: 0000 7472 6f66 6636 6100 0000 0000 0000 ..troff6a....... > 00064f00: 0000 7472 6f66 6638 2e73 0000 0000 0000 ..troff8.s...... > 00064f10: 0000 7878 7878 7800 0000 0000 0000 0000 ..xxxxx......... > >> So that one is a "troff version before the C rewrite in .. v7", but it is in >> C. Is that of any interest? > Without having looked into it more than you have it looks like it is > just an earlier version of the C code, but what I'm after is the > original assembly. > > aap I don't really know how deeply you've looked into this, but it may be of interest to you that Wollongong v6 on Interdata 32 has C sources for troff in /usr/source/troff: http://www.bitsavers.org/bits/Interdata/32bit/unix/univWollongong_v6/interdata_v6.tar.gz I know you're looking for assembler, but I also saw the comment "C rewrite in .. v7" in the message. It looks like a C version was available for v6. According to Miller's note: interdata_v6.tar.gz a 'tar' format archive (with dates preserved) of all files as they would appear after installing the distribution, with source and documentation in /usr/source and /usr/doc respectively; note however that special files in /dev appear as ordinary files The troff dir has date Jun 6, 1978. According to the readme, it was untested (maybe even unported?). Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From terry at jon.es Mon Jan 17 08:58:17 2022 From: terry at jon.es (Terry Jones) Date: Sun, 16 Jan 2022 22:58:17 +0000 Subject: [TUHS] 7th and 8th edition manuals, plus PDP11 processor handbook Message-ID: Any takers for a (free) two-volume 7th Ed manual (1983), or ring-bound 8th Ed (1985), or PDP11 processor handbook (1981)? These would need to be picked up in Lindfield, Sydney, Australia. Condition is fair, but they've been in storage for 35 years so are slightly mouldy, but still perfectly usable. Images at http://jon.es/other/7th-ed.jpg and http://jon.es/other/8th-ed.jpg If you’d like them, let me know in email ASAP please. Regards, Terry Jones -------------- next part -------------- An HTML attachment was scrubbed... URL: From terry at jon.es Mon Jan 17 10:23:16 2022 From: terry at jon.es (Terry Jones) Date: Mon, 17 Jan 2022 00:23:16 +0000 Subject: [TUHS] 7th and 8th edition manuals, plus PDP11 processor handbook In-Reply-To: References: Message-ID: These are now spoken for. Terry From: Terry Jones Reply to: Terry Jones Date: Monday, 17. January 2022 at 09:58 To: Subject: 7th and 8th edition manuals, plus PDP11 processor handbook Any takers for a (free)two-volume 7th Ed manual (1983), or ring-bound 8th Ed (1985), or PDP11 processor handbook (1981)? These would need to be picked up in Lindfield, Sydney, Australia. Condition is fair, but they've been in storage for 35 years so are slightly mouldy, but still perfectly usable. Images at http://jon.es/other/7th-ed.jpg and http://jon.es/other/8th-ed.jpg If you’d like them, let me know in email ASAP please. Regards, Terry Jones -------------- next part -------------- An HTML attachment was scrubbed... URL: From beebe at math.utah.edu Tue Jan 18 07:37:21 2022 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Mon, 17 Jan 2022 14:37:21 -0700 Subject: [TUHS] BWK talk on early Unix Friday 14 January 2022 Message-ID: I've just watched an interesting presentation given last Friday via video link to the Linux Conference in Australia: Brian Kernighan The early days of Unix at Bell Labs https://www.youtube.com/watch?v=ECCr_KFl41E 48 minutes While most of the talk subjects are well known to TUHS list members, there are nice things said about various people, and about the value of TUHS. Other talks at the conference may be of interest as well: see the schedule at https://linux.conf.au/schedule/ ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From rdm at cfcl.com Tue Jan 18 10:52:58 2022 From: rdm at cfcl.com (Rich Morin) Date: Mon, 17 Jan 2022 16:52:58 -0800 Subject: [TUHS] BWK talk on early Unix Friday 14 January 2022 In-Reply-To: References: Message-ID: <4DACF634-04FF-4AEB-9894-070CA2B49F0A@cfcl.com> > On Jan 17, 2022, at 13:37, Nelson H. F. Beebe wrote: > > I've just watched an interesting presentation given last Friday via > video link to the Linux Conference in Australia: > > Brian Kernighan > The early days of Unix at Bell Labs > https://www.youtube.com/watch?v=ECCr_KFl41E I just watched the entire thing; great fun! I particularly liked the part about pipes and was reminded of dmr's comment: > ... The idea, explained one afternoon on a blackboard, intrigued us but failed to ignite any immediate action. There were several objections to the idea as put: the infix notation seemed too radical (we were too accustomed to typing ‘cp x y’ to copy x to y); and we were unable to see how to distinguish command parameters from the input or output files. Also, the one-input one-output model of command execution seemed too confining. What a failure of imagination! ... -- https://www.read.seas.harvard.edu/~kohler/class/aosref/ritchie84evolution.pdf The closing line seems quintessentially Dennis. On a vaguely related note, I've really enjoyed using pipes in Elixir (borrowed from F#, AFAIK). In their basic form, they carry only the complete output of the sending function. However, there is a stream version which works with incomplete data. Given the sparse nature of C's design, it isn't surprising that pipelines were omitted, but it rather surprises me not to see them in more of its successor languages. -r From douglas.mcilroy at dartmouth.edu Tue Jan 18 13:22:44 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Mon, 17 Jan 2022 22:22:44 -0500 Subject: [TUHS] BWK talk on early Unix Friday 14 January 2022 Message-ID: > I've just watched an interesting presentation given last Friday via > video link to the Linux Conference in Australia: > Brian Kernighan > The early days of Unix at Bell Labs > https://www.youtube.com/watch?v=ECCr_KFl41E Here's an earlier incarnation of the talk: https://www.youtube.com/watch?v=nS-0Vrmok6Y I rather enjoyed seeing it with closed captions in Spanish and speakers turned off. Aided by the slides, I was pretty well able to read the Spanish, which otherwise would have been quite mysterious. Doug From rich.salz at gmail.com Tue Jan 18 22:49:31 2022 From: rich.salz at gmail.com (Richard Salz) Date: Tue, 18 Jan 2022 07:49:31 -0500 Subject: [TUHS] Dot (graphviz) to ascii Message-ID: >From Thomas Ptacek on twitter [1], quoting something on HackerNews [2]: a person wrote a dot-file renderer for ASCII diagrams [3] It seems to be a service; source not available. 1. https://twitter.com/tqbf/status/1483181795441004544?t=DoL8RopOYKBojkmMznSlAA&s=03 2. https://news.ycombinator.com/item?id=29969770 3. https://dot-to-ascii.ggerganov.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschauma at netmeister.org Tue Jan 18 22:53:48 2022 From: jschauma at netmeister.org (Jan Schaumann) Date: Tue, 18 Jan 2022 07:53:48 -0500 Subject: [TUHS] Dot (graphviz) to ascii In-Reply-To: References: Message-ID: <20220118125348.GA6133@netmeister.org> Richard Salz wrote: > >From Thomas Ptacek on twitter [1], quoting something on HackerNews [2]: a > person wrote a dot-file renderer for ASCII diagrams [3] It seems to be a > service; source not available. The source appears to be here: https://github.com/ggerganov/dot-to-ascii -Jan From jschauma at netmeister.org Tue Jan 18 23:13:54 2022 From: jschauma at netmeister.org (Jan Schaumann) Date: Tue, 18 Jan 2022 08:13:54 -0500 Subject: [TUHS] Dot (graphviz) to ascii In-Reply-To: <20220118125348.GA6133@netmeister.org> References: <20220118125348.GA6133@netmeister.org> Message-ID: <20220118131354.GB6133@netmeister.org> Jan Schaumann via TUHS wrote: > Richard Salz wrote: > > >From Thomas Ptacek on twitter [1], quoting something on HackerNews [2]: a > > person wrote a dot-file renderer for ASCII diagrams [3] It seems to be a > > service; source not available. > > The source appears to be here: > https://github.com/ggerganov/dot-to-ascii Sorry, OT, I guess, just wanted to follow up with the link to what does the actual heavy lifting, and as so often, the answer is Perl: https://metacpan.org/pod/Graph::Easy -Jan From mochid at netside.co.jp Thu Jan 20 00:29:04 2022 From: mochid at netside.co.jp (MOCHIDA Shuji) Date: Wed, 19 Jan 2022 23:29:04 +0900 (JST) Subject: [TUHS] One more arch 4.4BSD binary set, luna68k on nono OMRON LUNA emulator Message-ID: <20220119.232904.1448404747269354902.mochid@netside.co.jp> One of architechture supported by 4.4BSD, luna68k's compiled binary is now available. http://www.netside.co.jp/~mochid/comp/bsd44-build/ luna68k is OMRON LUNA, m68k cpu workstation. This binary set works on "nono" emulator software. http://www.pastel-flower.jp/~isaki/nono/ It's author, Isaki-san have done some minor modification for 4.4BSD, binary set for luna68k run rather well. OMRON, already dropped thier workstation products. LUNA-I, LUNA-II equipped with m68k, same CPU as CSRG's main target arch hp300. So userland programs may binary compatible. -mochid From will.senn at gmail.com Fri Jan 21 06:43:42 2022 From: will.senn at gmail.com (Will Senn) Date: Thu, 20 Jan 2022 14:43:42 -0600 Subject: [TUHS] DEC Format floppy (for formatting disk prior to 4.2BSD install) Message-ID: <761dc362-14ed-c1b9-7c51-534d94bb1caa@gmail.com> Hi all, Has anybody ever seen a console floppy image anywhere on the internet labeled: /"RX11 VAX DSK LD DEV #1"/ It is referenced in BSD 4 documentation with respect to formatting disks (edited): USING DEC SOFTWARE TO FORMAT Warning: These instructions are for people with 11/780 CPU’s. You should shut down UNIX and halt the machine to do any disk formatting. Formatting an RP06. Load the console floppy labeled, "RX11 VAX DSK LD DEV #1" in the console disk drive, and type the following commands: >>>BOOT DIAGNOSTIC SUPERVISOR. ZZ-ESSAA-X5.0-119 23-JAN-1980 12:44:40.03 DS>ATTACH RH780 SBI RHO 8 5 DS>ATTACH RPO6 RHO DBA0 DS>SELECT DBAO DS>LOAD EVRAC DS>START/SEC:PACKINIT This is for drive 0 on mbaO; use 9 instead of 8 for mbal, etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.branden.robinson at gmail.com Sat Jan 22 12:34:36 2022 From: g.branden.robinson at gmail.com (Branden Robinson) Date: Sat, 22 Jan 2022 13:34:36 +1100 Subject: [TUHS] troff environments, traps, and diversions (was: TeX and groff) In-Reply-To: <4409b93407ed2118@orthanc.ca> References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220110203300.GY3441@mcvoy.com> <4409b93407ed2118@orthanc.ca> Message-ID: On Tue, Jan 11, 2022 at 1:25 PM Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > A lot of people get turned off by how troff markup can often look like > line noise. That's true, but if you spend the time to actually learn > the syntax (and it's really not that hard), you can't help but be > overwhelmed by the beauty of its self-consistency. Although after > three decades I still can't wrap my head around traps and diversions > :-P It seems like a lot of people get stuck on the dread trio of traps, diversions, and environments. Some old groff documentation did not, I think, help matters very much by characterizing them as "advanced" and particularly by comparing diversions to pointers in C. I've been rewriting a lot of groff's documentation over the past five years. Here's my attempt to introduce these 3 concepts in the groff(7) page of the forthcoming 1.23 release. Let me know how I can improve it. (I retiterate that it's just an introduction--there is much more detail about all three later in the page and in groff's Texinfo manual, much of which has parallel content to its man pages.) A further few language elements arise as page layouts become more sophisticated and demanding. Environments collect formatting parameters like line length and typeface. A diversion stores formatted output for later use. A trap is a condition on the input or output, tested automatically by the formatter, that is associated with a macro, causing it to be called when that condition is fulfilled. Footnote support often exercises all three of the foregoing features. A simple implementation might work as follows. A pair of macros is defined: one starts a footnote and the other ends it. The author calls the first macro where a footnote marker is desired. The macro establishes a diversion so that the footnote text is collected at the place in the body text where its corresponding marker appears. An environment is created for the footnote so that it is set at a smaller typeface. The footnote text is formatted in the diversion using that environment, but it does not yet appear in the output. The document author calls the footnote end macro, which returns to the previous environment and ends the diversion. Later, after much more body text in the document, a trap, set a small distance above the page bottom, is sprung. The macro called by the trap draws a line across the page and emits the stored diversion. Thus, the footnote is rendered. Regards, Branden -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From douglas.mcilroy at dartmouth.edu Sun Jan 23 02:02:10 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sat, 22 Jan 2022 11:02:10 -0500 Subject: [TUHS] troff environments, traps, and diversions (was: TeX and groff) In-Reply-To: References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220110203300.GY3441@mcvoy.com> <4409b93407ed2118@orthanc.ca> Message-ID: Branden, I like these intro paragraphs and the elision of the ominous adjective, "advanced". > An environment is created for the footnote so that it is set at a smaller typeface. To avoid implying that one must create an environment with each footnote and to illustrate that environments are collections of settings, you might say something like this > Switch to a previously created footnote environment with a smaller typeface and distinctive line length. Doug On Fri, Jan 21, 2022 at 9:34 PM Branden Robinson wrote: > > On Tue, Jan 11, 2022 at 1:25 PM Lyndon Nerenberg (VE7TFX/VE6BBM) > wrote: > > A lot of people get turned off by how troff markup can often look like > > line noise. That's true, but if you spend the time to actually learn > > the syntax (and it's really not that hard), you can't help but be > > overwhelmed by the beauty of its self-consistency. Although after > > three decades I still can't wrap my head around traps and diversions > > :-P > > It seems like a lot of people get stuck on the dread trio of traps, > diversions, and environments. Some old groff documentation did not, I > think, help matters very much by characterizing them as "advanced" and > particularly by comparing diversions to pointers in C. I've been > rewriting a lot of groff's documentation over the past five years. > > Here's my attempt to introduce these 3 concepts in the groff(7) page of > the forthcoming 1.23 release. Let me know how I can improve it. (I > retiterate that it's just an introduction--there is much more detail > about all three later in the page and in groff's Texinfo manual, much of > which has parallel content to its man pages.) > > A further few language elements arise as page layouts become more > sophisticated and demanding. Environments collect formatting > parameters like line length and typeface. A diversion stores > formatted output for later use. A trap is a condition on the > input or output, tested automatically by the formatter, that is > associated with a macro, causing it to be called when that > condition is fulfilled. > > Footnote support often exercises all three of the foregoing > features. A simple implementation might work as follows. A pair > of macros is defined: one starts a footnote and the other ends > it. The author calls the first macro where a footnote marker is > desired. The macro establishes a diversion so that the footnote > text is collected at the place in the body text where its > corresponding marker appears. An environment is created for the > footnote so that it is set at a smaller typeface. The footnote > text is formatted in the diversion using that environment, but it > does not yet appear in the output. The document author calls the > footnote end macro, which returns to the previous environment and > ends the diversion. Later, after much more body text in the > document, a trap, set a small distance above the page bottom, is > sprung. The macro called by the trap draws a line across the > page and emits the stored diversion. Thus, the footnote is > rendered. > > Regards, > Branden > Foo > > On Tue, Jan 11, 2022 at 1:25 PM Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: >> >> Dan Cross writes: >> >> > This is interesting; I've always felt like I could pick out troff pretty >> > readily; I agree that TeX has a certain "look" to it (at least by default), >> > but I always felt the same about troff as well. >> >> My guess this is more about how ms(7) does page layout. I can spot >> those documents from a mile away :-) >> >> But older versions of troff can often be spotted by how box corners >> don't always line up properly. >> >> A lot of people get turned off by how troff markup can often look >> like line noise. That's true, but if you spend the time to actually >> learn the syntax (and it's really not that hard), you can't help >> but be overwhelmed by the beauty of its self-consistency. Although >> after three decades I still can't wrap my head around traps and >> diversions :-P >> >> --lyndon From arnold at skeeve.com Mon Jan 24 03:58:20 2022 From: arnold at skeeve.com (Arnold Robbins) Date: Sun, 23 Jan 2022 19:58:20 +0200 Subject: [TUHS] struct(1) updating - progress Message-ID: Hello All. If anyone is interested in struct, I have completed updating it for modern day systems. Thanks to Jay Logue for invaluable help in completing the work and to Bakul Shah for his interest and support. See https://github.com/arnoldrobbins/struct; I have merged the modernization work into the master branch. The README.md describes what was done in more detail. Doug McIlroy - if you want me to add anything to the README.md, please send it on and I will do so, quoting you as appropriate. Jay Logue and Bakul Shah - if you want me to add anything to the README.md, please let me know (privately). Thanks, Arnold From jon at fourwinds.com Mon Jan 24 05:45:41 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Sun, 23 Jan 2022 11:45:41 -0800 Subject: [TUHS] troff environments, traps, and diversions (was: TeX and groff) In-Reply-To: References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220110203300.GY3441@mcvoy.com> <4409b93407ed2118@orthanc.ca> Message-ID: <202201231945.20NJjfab422896@darkstar.fourwinds.com> On Fri, Jan 21, 2022 at 9:34 PM Branden Robinson wrote: > > On Tue, Jan 11, 2022 at 1:25 PM Lyndon Nerenberg (VE7TFX/VE6BBM) > wrote: > > A lot of people get turned off by how troff markup can often look like > > line noise. That's true, but if you spend the time to actually learn > > the syntax (and it's really not that hard), you can't help but be > > overwhelmed by the beauty of its self-consistency. Although after > > three decades I still can't wrap my head around traps and diversions > > :-P > > It seems like a lot of people get stuck on the dread trio of traps, > diversions, and environments. Some old groff documentation did not, I > think, help matters very much by characterizing them as "advanced" and > particularly by comparing diversions to pointers in C. I've been > rewriting a lot of groff's documentation over the past five years. > > Here's my attempt to introduce these 3 concepts in the groff(7) page of > the forthcoming 1.23 release. Let me know how I can improve it. (I > retiterate that it's just an introduction--there is much more detail > about all three later in the page and in groff's Texinfo manual, much of > which has parallel content to its man pages.) > > A further few language elements arise as page layouts become more > sophisticated and demanding. Environments collect formatting > parameters like line length and typeface. A diversion stores > formatted output for later use. A trap is a condition on the > input or output, tested automatically by the formatter, that is > associated with a macro, causing it to be called when that > condition is fulfilled. > > Footnote support often exercises all three of the foregoing > features. A simple implementation might work as follows. A pair > of macros is defined: one starts a footnote and the other ends > it. The author calls the first macro where a footnote marker is > desired. The macro establishes a diversion so that the footnote > text is collected at the place in the body text where its > corresponding marker appears. An environment is created for the > footnote so that it is set at a smaller typeface. The footnote > text is formatted in the diversion using that environment, but it > does not yet appear in the output. The document author calls the > footnote end macro, which returns to the previous environment and > ends the diversion. Later, after much more body text in the > document, a trap, set a small distance above the page bottom, is > sprung. The macro called by the trap draws a line across the > page and emits the stored diversion. Thus, the footnote is > rendered. > > Regards, > Branden > Foo On Lyndon's comment - if you're trying to get a new generation of troff users keep in mind that to younger folks than us line noise is a reason to get a surge protector. And if they have seen phone line noise, I still have a stack of old modems in the basement for them. And troff is a lot less like line noise that OpenOffice XML. I like the proposed improvements in the docs but would go further. o As per an earlier thread, I would explain the string/number register stuff in programming language terms; these are variables. And number registers have things like auto-increment and all that. It may be *technically* correct to say that registers are interpolated, but would be way more accessible to talk about the value of a variable. o It would be nice to have a table mapping groff constructs into those from other programming languages. Common ones, that is, not perl. Mentioned variables above, to me macros are functions, there are a few control constructs. Explain this stuff in terms that people are familiar with, try to avoid crufty language. o I think that it would be helpful to summarize that troff was originally written for smaller computers which required compromises such as the one and two character naming scheme. And a table that shows how that scheme has been compatibly expanded since. Better than hiding this in the description of every request that uses names. o I think that an important point to make about diversions is that they're a bit like scratch paper; that one can scribble on it and take measurements on them to decide what to do. For example, dumping a paragraph into a diversion and then measuring it to see if it will fit unbroken on what's left of a page. o The description of traps could be expanded. I would say something like the original traps were a vertical location on a page, and that since then the term has been overloaded with number of additional varieties. Jon From bakul at iitbombay.org Mon Jan 24 05:51:29 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Sun, 23 Jan 2022 11:51:29 -0800 Subject: [TUHS] struct(1) updating - progress In-Reply-To: References: Message-ID: <1CFE4981-5909-46EA-90D8-5F746138A5C6@iitbombay.org> Somewhere I saw a reference to BAKER, B.S Struct, a program which structures Fortran Internal memo, Bell Labs, Murray Hdl, N J., 1975. Is this memo available? Websearch revealed nothing. Thanks! From jon at fourwinds.com Mon Jan 24 08:26:58 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Sun, 23 Jan 2022 14:26:58 -0800 Subject: [TUHS] troff environments, traps, and diversions (was: TeX and groff) In-Reply-To: References: <20211231234039.GU31637@mcvoy.com> <20220101005605.GL75481@eureka.lemis.com> <20220101031511.GB8135@mcvoy.com> <20220110203300.GY3441@mcvoy.com> <4409b93407ed2118@orthanc.ca> Message-ID: <202201232226.20NMQwsJ425599@darkstar.fourwinds.com> Thinking about it some more, I think that it would help to talk about traps as interrupts or events. That works well with thinking about macros as functions as traps essentially fire of interrupt handlers which are macros. From rob at robdiamond.com Tue Jan 25 02:13:29 2022 From: rob at robdiamond.com (Robert Diamond) Date: Mon, 24 Jan 2022 11:13:29 -0500 Subject: [TUHS] A bit of BTL Explorer Post Ephemera Message-ID: Just found this program from 1979 of an Explorer Club (aka “The Scouts”) Family Night, which included a talk from Ken Thompson on Computer Chess. There’s a few notable names in there. See PDF at https://drive.google.com/file/d/15fXhkk9KlmJNrhGlFnWuH23XQ09vLG4o/view?usp=sharing -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2473 bytes Desc: not available URL: From aaronscohen at gmail.com Tue Jan 25 05:03:37 2022 From: aaronscohen at gmail.com (aaron cohen) Date: Mon, 24 Jan 2022 14:03:37 -0500 Subject: [TUHS] Fwd: A bit of BTL Explorer Post Ephemera In-Reply-To: References: Message-ID: Wow. Brings back memories On Mon, Jan 24, 2022 at 1:32 PM Robert Diamond wrote: > Just found this program from 1979 of an Explorer Club (aka “The Scouts”) > Family Night, which included a talk from Ken Thompson on Computer Chess. > There’s a few notable names in there. > > See PDF at > https://drive.google.com/file/d/15fXhkk9KlmJNrhGlFnWuH23XQ09vLG4o/view?usp=sharing -- Aaron Cohen 908-759-9069 -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Tue Jan 25 19:24:17 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 25 Jan 2022 02:24:17 -0700 Subject: [TUHS] Doug McIlroy and Brian Kernighan talk Message-ID: <202201250924.20P9OHdD005314@freefriends.org> Found this yesterday: https://www.youtube.com/watch?v=Xe5ffO6Ouwg Not quite an hour long. Arnold From christopher.fujino at gmail.com Wed Jan 26 05:13:08 2022 From: christopher.fujino at gmail.com (christopher fujino) Date: Tue, 25 Jan 2022 11:13:08 -0800 Subject: [TUHS] Doug McIlroy and Brian Kernighan talk In-Reply-To: <202201250924.20P9OHdD005314@freefriends.org> References: <202201250924.20P9OHdD005314@freefriends.org> Message-ID: Wow, great interview! On Tue, Jan 25, 2022 at 1:25 AM wrote: > Found this yesterday: https://www.youtube.com/watch?v=Xe5ffO6Ouwg > > Not quite an hour long. > > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay-tuhs9915 at toaster.com Wed Jan 26 11:24:50 2022 From: jay-tuhs9915 at toaster.com (Jay Logue) Date: Tue, 25 Jan 2022 17:24:50 -0800 Subject: [TUHS] Latest release of retro-fuse Message-ID: <20220126012454.6D4239D68B@minnie.tuhs.org> Hi all, I've been hard at work on my retro-fuse project over the past few months, and so I thought I'd update the list with my progress. I have just released version 7 of retro-fuse on github (https://github.com/jaylogue/retro-fuse). This version adds support for initializing and mounting 2.9 and 2.11BSD filesystems on modern systems.  It also includes fixes for a number of bugs in v6 and v7 support. Beyond the work on 2.11 support, I also spent a significant amount of time building an automated test framework.  I'm a pretty big fan of automated testing.  So I'm happy to say that the project now includes a series of tests verifying basic file I/O functionality as seen from the modern system.  While not exhaustive (because filesystem testing is /hard/) the new tests give me reasonable confidence that things are behaving as they should. Additionally (in what was perhaps the most fun part of the project to date) I have also created tests to verify the integrity of the generated filesystems as seen from the historical systems. In particular, for each of the supported Unix versions I've built tests that: launch the os under simulation (simh), mount the generated filesystems, verify the filesystems using the original integrity check tools (icheck/fsck), and enumerate and compare the filesystem contents to that generated on the modern system.  As you might imagine, this involved a lot of learning--from how to build size-reduced system images from the original distribution tapes, to how to implement a modern POSIX cksum command with old dev tools. All thoroughly enjoyable. With this under my belt, I'll probably take a break from retro-fuse to concentrate on other things.  If anyone has any problems (or successes!) using it, please drop me a line. --Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdm at cfcl.com Thu Jan 27 10:36:25 2022 From: rdm at cfcl.com (Rich Morin) Date: Wed, 26 Jan 2022 16:36:25 -0800 Subject: [TUHS] FYI: Internet Old Farts Club Message-ID: <54965199-5023-4F99-AF27-8615E319E302@cfcl.com> Some of the folks here might like this FB group... Internet Old Farts Club https://www.facebook.com/groups/internetoldfarts/ > This group is for self-declared Internet Old Farts, who want to discuss any aspect of the the Internet or its history. People in this group had their bits walk up hill both ways. > Welcome to the Internet Old Farts group. The purpose of this group is both social and technical. Feel free to revisit the past, explore the future, grouse about technical problems that you or others created. Feel free to self-aggrandize, complain about your least favorite standards organization or its politics, and how those young whippersnappers are running the show today. By participating in this group you are admitting or proclaiming that you are indeed an Internet Old Fart. Perhaps we should give a prize for the youngest and oldest Old Fart. -r From jschauma at netmeister.org Thu Jan 27 11:55:05 2022 From: jschauma at netmeister.org (Jan Schaumann) Date: Wed, 26 Jan 2022 20:55:05 -0500 Subject: [TUHS] FYI: Internet Old Farts Club In-Reply-To: <54965199-5023-4F99-AF27-8615E319E302@cfcl.com> References: <54965199-5023-4F99-AF27-8615E319E302@cfcl.com> Message-ID: <20220127015505.GC10568@netmeister.org> Rich Morin wrote: > Some of the folks here might like this FB group... > > Internet Old Farts Club > https://www.facebook.com/groups/internetoldfarts/ Kinda feel like being an Old Fart and joining a Facebook group are mutually exclusive. Now if it was a newsgroup, perhaps, or a FidoNet BBS, ... -Jan From gtaylor at tnetconsulting.net Thu Jan 27 12:07:41 2022 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 26 Jan 2022 19:07:41 -0700 Subject: [TUHS] FYI: Internet Old Farts Club In-Reply-To: <54965199-5023-4F99-AF27-8615E319E302@cfcl.com> References: <54965199-5023-4F99-AF27-8615E319E302@cfcl.com> Message-ID: <56130ba3-f566-70c0-117f-fff99f7a0264@spamtrap.tnetconsulting.net> On 1/26/22 5:36 PM, Rich Morin wrote: > Some of the folks here might like this FB group... I probably would be. > Internet Old Farts Club > https://www.facebook.com/groups/internetoldfarts/ But sadly FaceBook is a walled garden that you have to be a member of to be able to partake in any capacity, even read only. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4017 bytes Desc: S/MIME Cryptographic Signature URL: From lm at mcvoy.com Thu Jan 27 12:40:07 2022 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 26 Jan 2022 18:40:07 -0800 Subject: [TUHS] FYI: Internet Old Farts Club In-Reply-To: <56130ba3-f566-70c0-117f-fff99f7a0264@spamtrap.tnetconsulting.net> References: <54965199-5023-4F99-AF27-8615E319E302@cfcl.com> <56130ba3-f566-70c0-117f-fff99f7a0264@spamtrap.tnetconsulting.net> Message-ID: <20220127024007.GV27031@mcvoy.com> On Wed, Jan 26, 2022 at 07:07:41PM -0700, Grant Taylor via TUHS wrote: > On 1/26/22 5:36 PM, Rich Morin wrote: > >Some of the folks here might like this FB group... > > I probably would be. > > >Internet Old Farts Club > >https://www.facebook.com/groups/internetoldfarts/ > > But sadly FaceBook is a walled garden that you have to be a member of to be > able to partake in any capacity, even read only. Yeah, I feel the same way, not gonna be part of facebook ever. It's toxic. From norman at oclsc.org Thu Jan 27 12:52:45 2022 From: norman at oclsc.org (Norman Wilson) Date: Wed, 26 Jan 2022 21:52:45 -0500 (EST) Subject: [TUHS] FYI: Internet Old Farts Club Message-ID: <8855E6679BB73A6A36D8FF6C5E83DED7.for-standards-violators@oclsc.org> I'm too much of an old fart to use FaceBook. a Norman Wilson Toronto ON @oclsc on twitter From rtomek at ceti.pl Fri Jan 28 07:11:23 2022 From: rtomek at ceti.pl (Tomasz Rola) Date: Thu, 27 Jan 2022 22:11:23 +0100 Subject: [TUHS] FYI: Internet Old Farts Club In-Reply-To: <54965199-5023-4F99-AF27-8615E319E302@cfcl.com> References: <54965199-5023-4F99-AF27-8615E319E302@cfcl.com> Message-ID: <20220127211123.GA17807@tau1.ceti.pl> On Wed, Jan 26, 2022 at 04:36:25PM -0800, Rich Morin wrote: > Some of the folks here might like this FB group... > > Internet Old Farts Club > https://www.facebook.com/groups/internetoldfarts/ [...] > > Welcome to the Internet Old Farts group. [...] > problems that you or others created. Feel free to self-aggrandize, > complain about your least favorite standards organization or its > politics, and how those young whippersnappers are running the show > today. [...] Oh wait, so falsebook now has a special group where folks can post a critique of... a falsebook? Do they have to monopolize even 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 cym224 at gmail.com Fri Jan 28 09:20:02 2022 From: cym224 at gmail.com (Nemo Nusquam) Date: Thu, 27 Jan 2022 18:20:02 -0500 Subject: [TUHS] FYI: Internet Old Farts Club In-Reply-To: <8855E6679BB73A6A36D8FF6C5E83DED7.for-standards-violators@oclsc.org> References: <8855E6679BB73A6A36D8FF6C5E83DED7.for-standards-violators@oclsc.org> Message-ID: <0152c06a-9c8f-78a6-f1bf-26876257e1f9@gmail.com> On 2022-01-26 21:52, Norman Wilson wrote: > I'm too much of an old fart to use FaceBook. Well, after reading Levy's book on Facebook, I am glad not to be on it. N. > a > > Norman Wilson > Toronto ON > @oclsc on twitter From will.senn at gmail.com Sat Jan 29 09:07:41 2022 From: will.senn at gmail.com (Will Senn) Date: Fri, 28 Jan 2022 17:07:41 -0600 Subject: [TUHS] Looking back to 1981 - what pascal was popular on what unix? Message-ID: <0f83f174-eeca-30fb-7b98-77fb0da80f2e@gmail.com> I'm reading in, Kernighan & Plauger's 1981 edition of Software Tools in Pascal and in the book, the author's mention Bill Joy's Pascal and Andy Tanenbaum's as being rock solid. So, a few related questions: 1. What edition of UNIX were they likely to be using? 2. What versions of "Standard Pascal" were in vogue on UNIX at the time (1981)? 3. What combinations of UNIX/Pascal were popular? Thanks, Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Sat Jan 29 09:18:34 2022 From: crossd at gmail.com (Dan Cross) Date: Fri, 28 Jan 2022 18:18:34 -0500 Subject: [TUHS] Looking back to 1981 - what pascal was popular on what unix? In-Reply-To: <0f83f174-eeca-30fb-7b98-77fb0da80f2e@gmail.com> References: <0f83f174-eeca-30fb-7b98-77fb0da80f2e@gmail.com> Message-ID: On Fri, Jan 28, 2022 at 6:09 PM Will Senn wrote: > I'm reading in, Kernighan & Plauger's 1981 edition of Software Tools in > Pascal and in the book, the author's mention Bill Joy's Pascal and Andy > Tanenbaum's as being rock solid. So, a few related questions: > > 1. What edition of UNIX were they likely to be using? > I'm afraid I can't speak to your 2nd and 3rd questions, but I can offer what I think is a reasonable guess about the first. One of the neat things about Unix and Unix-adjacent books of that era is that very often the copyright page held some information about the production of the book itself. I just so happened to have a copy of, "Software Tools in Pascal" sitting on my desk, and it says, "This books as set in Times Roman and Courier by the authors, using a Mergenthaler Linotron 202 phototypesetter driven by a PDP-11/70 running the Unix operating system." Given the PDP-11 and the date (1981) one may reasonably conclude that it was running 7th Edition. I imagine the pascal was Joy's, from Berkeley. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Sat Jan 29 09:31:50 2022 From: will.senn at gmail.com (Will Senn) Date: Fri, 28 Jan 2022 17:31:50 -0600 Subject: [TUHS] Looking back to 1981 - what pascal was popular on what unix? In-Reply-To: References: <0f83f174-eeca-30fb-7b98-77fb0da80f2e@gmail.com> Message-ID: On 1/28/22 5:18 PM, Dan Cross wrote: > On Fri, Jan 28, 2022 at 6:09 PM Will Senn wrote: > > I'm reading in, Kernighan & Plauger's 1981 edition of Software > Tools in Pascal and in the book, the author's mention Bill Joy's > Pascal and Andy Tanenbaum's as being rock solid. So, a few related > questions: > > 1. What edition of UNIX were they likely to be using? > > > I'm afraid I can't speak to your 2nd and 3rd questions, but I can > offer what I think is a reasonable guess about the first. > > One of the neat things about Unix and Unix-adjacent books of that era > is that very often the copyright page held some information about the > production of the book itself. I just so happened to have a copy of, > "Software Tools in Pascal" sitting on my desk, and it says, "This > books as set in Times Roman and Courier by the authors, using a > Mergenthaler Linotron 202 phototypesetter driven by a PDP-11/70 > running the Unix operating system." > > Given the PDP-11 and the date (1981) one may reasonably conclude that > it was running 7th Edition. I imagine the pascal was Joy's, from Berkeley. > >         - Dan C. > Great hint. 20 seconds after I hit send on the original email, I came across this: http://www.lysator.liu.se/c/bwk-on-pascal.html Where Brian Kernighan talks about the challenges they faced porting the ratfor examples into pascal. He explains that: The programs were first written in that dialect of Pascal supported by the Pascal interpreter pi provided by the University of California at Berkeley. The language is close to the nominal standard of Jensen and Wirth,(6 ) with good diagnostics and careful run-time checking. Since then, the programs have also been run, unchanged except for new libraries of primitives, on four other systems: an interpreter from the Free University of Amsterdam (hereinafter referred to as VU, for Vrije Universiteit), a VAX version of the Berkeley system (a true compiler), a compiler purveyed by Whitesmiths, Ltd., and UCSD Pascal on a Z80. All but the last of these Pascal systems are written in C. So, you were right about it being Joy's pi. Thanks, Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Sat Jan 29 10:03:43 2022 From: robpike at gmail.com (Rob Pike) Date: Sat, 29 Jan 2022 11:03:43 +1100 Subject: [TUHS] Looking back to 1981 - what pascal was popular on what unix? In-Reply-To: References: <0f83f174-eeca-30fb-7b98-77fb0da80f2e@gmail.com> Message-ID: Not really on topic for Unix, but historical and relevant to this conversation and I think not well known. In 1978 I was an exchange student working at EIR (now the Paul Scherrer Institute), using the CDC 7600 (I think that was the model) at ETH, where Wirth was a professor. EIR is about 30km from Zürich, and EIR had a remote job entry system. The computing environment was very odd, and I asked about it. Two things I learned: 1) The University had bought a CDC machine instead of an IBM one, somewhat against advice, because CDC, being a smaller company, did not have the wherewithal to translate their manuals. IBM's manuals came in German and were all but incomprehensible as they avoided the accepted terms of art known and used even by a German-speaking programmer. The CDC manuals, being in English, were easier to understand, especially when considering the nuance and precision necessary to learn the correct interpretation of the description of a computer's execution. The Swiss, being polyglots, handled English manuals just fine. 2) The operating system's I/O model was bizarre, but it was also unique. It was a version of NOS locally modified, partly (if I remember right) in support of the remote execution setup. The peculiar sequence of cards necessary to terminate the input was due to the local changes to NOS made at ETH. This was the system Pascal was created for, and a consequence of the design is the idiosyncratic way input worked in early Pascal, which made little sense to almost anyone, was seriously hard to recreate on Unix, but worked naturally if using punch cards on, and only on, the ETH 7600. -rob On Sat, Jan 29, 2022 at 10:32 AM Will Senn wrote: > On 1/28/22 5:18 PM, Dan Cross wrote: > > On Fri, Jan 28, 2022 at 6:09 PM Will Senn wrote: > >> I'm reading in, Kernighan & Plauger's 1981 edition of Software Tools in >> Pascal and in the book, the author's mention Bill Joy's Pascal and Andy >> Tanenbaum's as being rock solid. So, a few related questions: >> >> 1. What edition of UNIX were they likely to be using? >> > > I'm afraid I can't speak to your 2nd and 3rd questions, but I can offer > what I think is a reasonable guess about the first. > > One of the neat things about Unix and Unix-adjacent books of that era is > that very often the copyright page held some information about the > production of the book itself. I just so happened to have a copy of, > "Software Tools in Pascal" sitting on my desk, and it says, "This books as > set in Times Roman and Courier by the authors, using a Mergenthaler > Linotron 202 phototypesetter driven by a PDP-11/70 running the Unix > operating system." > > Given the PDP-11 and the date (1981) one may reasonably conclude that it > was running 7th Edition. I imagine the pascal was Joy's, from Berkeley. > > - Dan C. > > Great hint. 20 seconds after I hit send on the original email, I came > across this: > http://www.lysator.liu.se/c/bwk-on-pascal.html > > Where Brian Kernighan talks about the challenges they faced porting the > ratfor examples into pascal. He explains that: > > The programs were first written in that dialect of Pascal supported by the > Pascal interpreter pi provided by the University of California at Berkeley. The > language is close to the nominal standard of Jensen and Wirth,(6 > ) with good > diagnostics and careful run-time checking. Since then, the programs have > also been run, unchanged except for new libraries of primitives, on four > other systems: an interpreter from the Free University of Amsterdam > (hereinafter referred to as VU, for Vrije Universiteit), a VAX version of > the Berkeley system (a true compiler), a compiler purveyed by Whitesmiths, > Ltd., and UCSD Pascal on a Z80. All but the last of these Pascal systems > are written in C. > > So, you were right about it being Joy's pi. > > Thanks, > > Will > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Sat Jan 29 10:40:36 2022 From: will.senn at gmail.com (Will Senn) Date: Fri, 28 Jan 2022 18:40:36 -0600 Subject: [TUHS] Looking back to 1981 - what pascal was popular on what unix? In-Reply-To: References: <0f83f174-eeca-30fb-7b98-77fb0da80f2e@gmail.com> Message-ID: On 1/28/22 5:31 PM, Will Senn wrote: > On 1/28/22 5:18 PM, Dan Cross wrote: >> On Fri, Jan 28, 2022 at 6:09 PM Will Senn wrote: >> >> I'm reading in, Kernighan & Plauger's 1981 edition of Software >> Tools in Pascal and in the book, the author's mention Bill Joy's >> Pascal and Andy Tanenbaum's as being rock solid. So, a few >> related questions: >> >> 1. What edition of UNIX were they likely to be using? >> >> >> I'm afraid I can't speak to your 2nd and 3rd questions, but I can >> offer what I think is a reasonable guess about the first. >> >> One of the neat things about Unix and Unix-adjacent books of that era >> is that very often the copyright page held some information about the >> production of the book itself. I just so happened to have a copy of, >> "Software Tools in Pascal" sitting on my desk, and it says, "This >> books as set in Times Roman and Courier by the authors, using a >> Mergenthaler Linotron 202 phototypesetter driven by a PDP-11/70 >> running the Unix operating system." >> >> Given the PDP-11 and the date (1981) one may reasonably conclude that >> it was running 7th Edition. I imagine the pascal was Joy's, from >> Berkeley. >> >>         - Dan C. >> > Great hint. 20 seconds after I hit send on the original email, I came > across this: > http://www.lysator.liu.se/c/bwk-on-pascal.html > > Where Brian Kernighan talks about the challenges they faced porting > the ratfor examples into pascal. He explains that: > > The programs were first written in that dialect of Pascal > supported by the Pascal interpreter pi provided by the University > of California at Berkeley. The language is close to the nominal > standard of Jensen and Wirth,(6 > ) with good > diagnostics and careful run-time checking. Since then, the > programs have also been run, unchanged except for new libraries of > primitives, on four other systems: an interpreter from the Free > University of Amsterdam (hereinafter referred to as VU, for Vrije > Universiteit), a VAX version of the Berkeley system (a true > compiler), a compiler purveyed by Whitesmiths, Ltd., and UCSD > Pascal on a Z80. All but the last of these Pascal systems are > written in C. > > So, you were right about it being Joy's pi. > > Thanks, > > Will On the good news front, I was able to find a working pi/px environment - 4.2bsd built from tape on simulated vax780 works great (thank god vi works there, too) and will run the programs in the book without mods, out of the box. 4.3 would probably work similarly (I put it on the list). I tried compiling the pascal distributed via 2bsd on v7, but wasn't able to get it built (story of my life). This is prolly expected because the notes in the distro say "This is still set up for version 6", so I'll stick with 4.2 for the time being. Just glad to have a working environment to supplement the reading. Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From charles.unix.pro at gmail.com Sat Jan 29 11:59:52 2022 From: charles.unix.pro at gmail.com (Charles Anthony) Date: Fri, 28 Jan 2022 17:59:52 -0800 Subject: [TUHS] FYI: Internet Old Farts Club In-Reply-To: <20220127015505.GC10568@netmeister.org> References: <54965199-5023-4F99-AF27-8615E319E302@cfcl.com> <20220127015505.GC10568@netmeister.org> Message-ID: On Wed, Jan 26, 2022, 17:56 Jan Schaumann via TUHS wrote: > > Kinda feel like being an Old Fart and joining a > Facebook group are mutually exclusive. Now if it was > a newsgroup, perhaps, or a FidoNet BBS, ... > We can do 'forum' on Multics. -- Charles > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Sat Jan 29 12:24:24 2022 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Fri, 28 Jan 2022 21:24:24 -0500 Subject: [TUHS] FYI: Internet Old Farts Club In-Reply-To: References: <54965199-5023-4F99-AF27-8615E319E302@cfcl.com> <20220127015505.GC10568@netmeister.org> Message-ID: On Fri, Jan 28, 2022 at 05:59:52PM -0800, Charles Anthony wrote: > On Wed, Jan 26, 2022, 17:56 Jan Schaumann via TUHS > wrote: > > > > > Kinda feel like being an Old Fart and joining a > > Facebook group are mutually exclusive. Now if it was > > a newsgroup, perhaps, or a FidoNet BBS, ... > > > > We can do 'forum' on Multics. There's a re-implementation of 'forum' called Discuss[1] that was implemented by the MIT Student Information Board. It has a 'forum' feel, and the ss (subsystem) library provides the CLI interface which is reminiscent of Multics forum. [1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.31.8576&rep=rep1&type=pdf The ss and et (error_table) libraries that were originally written for the Discuss system are still in use today as part of Linux's ext2/3/4 userspace utilities, e2fsprogs. (The debugfs program uses the ss library, as does a few regression test drivers for some unit tests). The ss library is also used for the Kerberos v5 Administration Server. - Ted From lm at mcvoy.com Sat Jan 29 12:36:41 2022 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 28 Jan 2022 18:36:41 -0800 Subject: [TUHS] FYI: Internet Old Farts Club In-Reply-To: References: <54965199-5023-4F99-AF27-8615E319E302@cfcl.com> <20220127015505.GC10568@netmeister.org> Message-ID: <20220129023641.GL16452@mcvoy.com> On Fri, Jan 28, 2022 at 09:24:24PM -0500, Theodore Y. Ts'o wrote: > On Fri, Jan 28, 2022 at 05:59:52PM -0800, Charles Anthony wrote: > > On Wed, Jan 26, 2022, 17:56 Jan Schaumann via TUHS > > wrote: > > > > > > > > Kinda feel like being an Old Fart and joining a > > > Facebook group are mutually exclusive. Now if it was > > > a newsgroup, perhaps, or a FidoNet BBS, ... > > > > > > > We can do 'forum' on Multics. > > There's a re-implementation of 'forum' called Discuss[1] that was > implemented by the MIT Student Information Board. It has a 'forum' > feel, and the ss (subsystem) library provides the CLI interface which > is reminiscent of Multics forum. > > [1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.31.8576&rep=rep1&type=pdf > > The ss and et (error_table) libraries that were originally written for > the Discuss system are still in use today as part of Linux's ext2/3/4 > userspace utilities, e2fsprogs. (The debugfs program uses the ss > library, as does a few regression test drivers for some unit tests). > The ss library is also used for the Kerberos v5 Administration > Server. > > - Ted It's amazing how long stuff lives, very cool. Just like the runoff thread, stuff goes back to Multics and even earlier. Good ideas die hard. I also think that any idea of Facebook group for old Unix people is dead in the water. I can only speak for myself but hell will freeze over before I have a Facebook account, they have engineers that target kids, they have to pay more because people are ashamed to work there. It just makes me sad to think that technology is being used like Facebook does. It's just my opinion, but the world would be a better place if Facebook ceased to exist. If we need another place for old farts to hang out, there are many. I like groups.io, it's free for most stuff, it's super easy to be a moderator, I moderate 12 groups there and am a member of a bunch more. What they call groups, we would call an email list with a bunch of knobs that help keep things sane. --lm From akosela at andykosela.com Sat Jan 29 18:48:09 2022 From: akosela at andykosela.com (Andy Kosela) Date: Sat, 29 Jan 2022 09:48:09 +0100 Subject: [TUHS] FYI: Internet Old Farts Club In-Reply-To: <20220129023641.GL16452@mcvoy.com> References: <54965199-5023-4F99-AF27-8615E319E302@cfcl.com> <20220127015505.GC10568@netmeister.org> <20220129023641.GL16452@mcvoy.com> Message-ID: On 1/29/22, Larry McVoy wrote: > > If we need another place for old farts to hang out, there are many. > I like groups.io, it's free for most stuff, it's super easy to be > a moderator, I moderate 12 groups there and am a member of a bunch > more. What they call groups, we would call an email list with a > bunch of knobs that help keep things sane. I can speak only for myself, but I love that TUHS/COFF mailing lists are still _the real_ mailing lists managed the old school way. I hate all those modern web 2.0 technologies with extremely bloated js stacks which you can only use if you have the latest version of Chrome. I am still using old Atari DOS, Amiga Workbench, MS-DOS/Win9x/WinXP and of course Linux/FreeBSD. This is probably one of the last places on the Internet that is still preserving one of its core ideas in the 80s/90s -- plain text communication. It has been slowly dying in the last 15 years. Text based Internet of the 80s and 90s has slowly been replaced by binary protocols and image based interaction with a computer. I still just love using text based protocols and command line and read it on a real CRT monitor in full screen text mode. We lost something when the world moved on. So please do not go anywhere.... --Andy From jon at fourwinds.com Sun Jan 30 03:15:51 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Sat, 29 Jan 2022 09:15:51 -0800 Subject: [TUHS] FYI: Internet Old Farts Club In-Reply-To: References: <54965199-5023-4F99-AF27-8615E319E302@cfcl.com> <20220127015505.GC10568@netmeister.org> <20220129023641.GL16452@mcvoy.com> Message-ID: <202201291715.20THFpLW2308457@darkstar.fourwinds.com> Andy Kosela writes: > On 1/29/22, Larry McVoy wrote: > > > > If we need another place for old farts to hang out, there are many. > > I like groups.io, it's free for most stuff, it's super easy to be > > a moderator, I moderate 12 groups there and am a member of a bunch > > more. What they call groups, we would call an email list with a > > bunch of knobs that help keep things sane. > > I can speak only for myself, but I love that TUHS/COFF mailing lists > are still _the real_ mailing lists managed the old school way. I hate > all those modern web 2.0 technologies with extremely bloated js stacks > which you can only use if you have the latest version of Chrome. I am > still using old Atari DOS, Amiga Workbench, MS-DOS/Win9x/WinXP and of > course Linux/FreeBSD. > > This is probably one of the last places on the Internet that is still > preserving one of its core ideas in the 80s/90s -- plain text > communication. It has been slowly dying in the last 15 years. Text > based Internet of the 80s and 90s has slowly been replaced by binary > protocols and image based interaction with a computer. > > I still just love using text based protocols and command line and read > it on a real CRT monitor in full screen text mode. We lost something > when the world moved on. > > So please do not go anywhere.... > > --Andy I completely agree with you. Maybe one of the problems is the book-burners opposed to CRT. Don't know if any of you have ever run across this guy: http://unixsheikh.com/index.html Seems to be a younger-ish person who seems to get it. Jon From blake1024 at gmail.com Sun Jan 30 03:20:57 2022 From: blake1024 at gmail.com (Blake McBride) Date: Sat, 29 Jan 2022 11:20:57 -0600 Subject: [TUHS] FYI: Internet Old Farts Club In-Reply-To: <20220129023641.GL16452@mcvoy.com> References: <54965199-5023-4F99-AF27-8615E319E302@cfcl.com> <20220127015505.GC10568@netmeister.org> <20220129023641.GL16452@mcvoy.com> Message-ID: On Fri, Jan 28, 2022 at 8:37 PM Larry McVoy wrote: > > [...] > > If we need another place for old farts to hang out, there are many. > I like groups.io, it's free for most stuff, it's super easy to be > a moderator, I moderate 12 groups there and am a member of a bunch > more. What they call groups, we would call an email list with a > bunch of knobs that help keep things sane. > > --lm > Thanks! I just created two groups: https://groups.io/g/kiss https://groups.io/g/dynace Blake McBride -------------- next part -------------- An HTML attachment was scrubbed... URL: From web at loomcom.com Sun Jan 30 03:20:23 2022 From: web at loomcom.com (Seth J. Morabito) Date: Sat, 29 Jan 2022 09:20:23 -0800 Subject: [TUHS] FYI: Internet Old Farts Club In-Reply-To: References: <54965199-5023-4F99-AF27-8615E319E302@cfcl.com> <20220127015505.GC10568@netmeister.org> <20220129023641.GL16452@mcvoy.com> Message-ID: <87k0ei30xg.fsf@loomcom.com> Andy Kosela writes: > > I can speak only for myself, but I love that TUHS/COFF mailing lists > are still _the real_ mailing lists managed the old school way. > [...] > So please do not go anywhere.... At the risk of sounding like a luddite, you're not alone, I'm right there with you. I'm certainly not opposed to innovation, not at all! There are some modern technologies that absolutely excite me and make me giddy to play around with. Unfortunately, all too often if feels like we're just spinning our wheels by doing the same things over and over again, but this time, more bloated. Increasingly, I'm asking myself: "Does this actually innovate, or is it just performative? Have I failed to research and read about existing techniques before I try to invent something that's already been invented, but this time in a 3 GB Electron app? Does the UX help, or hurt? Can colorblind people use it? Can people with vision impairment use it? Can people without access to broadband use it?" The Internet was a much more level playing field 20-30 years ago than it is now, and I'd like to keep what's left of that level playing field level as long as I can. > --Andy -Seth From cowan at ccil.org Sun Jan 30 05:05:08 2022 From: cowan at ccil.org (John Cowan) Date: Sat, 29 Jan 2022 14:05:08 -0500 Subject: [TUHS] Looking back to 1981 - what pascal was popular on what unix? In-Reply-To: References: <0f83f174-eeca-30fb-7b98-77fb0da80f2e@gmail.com> Message-ID: It would be interesting to know if the S.T. in P. programs will run on {GNU,Free} Pascal. On Fri, Jan 28, 2022 at 7:41 PM Will Senn wrote: > On 1/28/22 5:31 PM, Will Senn wrote: > > On 1/28/22 5:18 PM, Dan Cross wrote: > > On Fri, Jan 28, 2022 at 6:09 PM Will Senn wrote: > >> I'm reading in, Kernighan & Plauger's 1981 edition of Software Tools in >> Pascal and in the book, the author's mention Bill Joy's Pascal and Andy >> Tanenbaum's as being rock solid. So, a few related questions: >> >> 1. What edition of UNIX were they likely to be using? >> > > I'm afraid I can't speak to your 2nd and 3rd questions, but I can offer > what I think is a reasonable guess about the first. > > One of the neat things about Unix and Unix-adjacent books of that era is > that very often the copyright page held some information about the > production of the book itself. I just so happened to have a copy of, > "Software Tools in Pascal" sitting on my desk, and it says, "This books as > set in Times Roman and Courier by the authors, using a Mergenthaler > Linotron 202 phototypesetter driven by a PDP-11/70 running the Unix > operating system." > > Given the PDP-11 and the date (1981) one may reasonably conclude that it > was running 7th Edition. I imagine the pascal was Joy's, from Berkeley. > > - Dan C. > > Great hint. 20 seconds after I hit send on the original email, I came > across this: > http://www.lysator.liu.se/c/bwk-on-pascal.html > > Where Brian Kernighan talks about the challenges they faced porting the > ratfor examples into pascal. He explains that: > > The programs were first written in that dialect of Pascal supported by the > Pascal interpreter pi provided by the University of California at Berkeley. The > language is close to the nominal standard of Jensen and Wirth,(6 > ) with good > diagnostics and careful run-time checking. Since then, the programs have > also been run, unchanged except for new libraries of primitives, on four > other systems: an interpreter from the Free University of Amsterdam > (hereinafter referred to as VU, for Vrije Universiteit), a VAX version of > the Berkeley system (a true compiler), a compiler purveyed by Whitesmiths, > Ltd., and UCSD Pascal on a Z80. All but the last of these Pascal systems > are written in C. > > So, you were right about it being Joy's pi. > > Thanks, > > Will > > > On the good news front, I was able to find a working pi/px environment - > 4.2bsd built from tape on simulated vax780 works great (thank god vi works > there, too) and will run the programs in the book without mods, out of the > box. 4.3 would probably work similarly (I put it on the list). I tried > compiling the pascal distributed via 2bsd on v7, but wasn't able to get it > built (story of my life). This is prolly expected because the notes in the > distro say "This is still set up for version 6", so I'll stick with 4.2 for > the time being. Just glad to have a working environment to supplement the > reading. > > Will > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Sun Jan 30 05:36:55 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sat, 29 Jan 2022 12:36:55 -0700 Subject: [TUHS] Looking back to 1981 - what pascal was popular on what unix? In-Reply-To: References: <0f83f174-eeca-30fb-7b98-77fb0da80f2e@gmail.com> Message-ID: <202201291936.20TJatB9002128@freefriends.org> The code from Software Tools in Pascal is in the TUHS archives (courtesy of yours truly, quite some time ago). See Applications/Software_Tools/swt/Pascal/* So give them a go. :-) Arnold John Cowan wrote: > It would be interesting to know if the S.T. in P. programs will run on > {GNU,Free} Pascal. > > On Fri, Jan 28, 2022 at 7:41 PM Will Senn wrote: > > > On 1/28/22 5:31 PM, Will Senn wrote: > > > > On 1/28/22 5:18 PM, Dan Cross wrote: > > > > On Fri, Jan 28, 2022 at 6:09 PM Will Senn wrote: > > > >> I'm reading in, Kernighan & Plauger's 1981 edition of Software Tools in > >> Pascal and in the book, the author's mention Bill Joy's Pascal and Andy > >> Tanenbaum's as being rock solid. So, a few related questions: > >> > >> 1. What edition of UNIX were they likely to be using? > >> > > > > I'm afraid I can't speak to your 2nd and 3rd questions, but I can offer > > what I think is a reasonable guess about the first. > > > > One of the neat things about Unix and Unix-adjacent books of that era is > > that very often the copyright page held some information about the > > production of the book itself. I just so happened to have a copy of, > > "Software Tools in Pascal" sitting on my desk, and it says, "This books as > > set in Times Roman and Courier by the authors, using a Mergenthaler > > Linotron 202 phototypesetter driven by a PDP-11/70 running the Unix > > operating system." > > > > Given the PDP-11 and the date (1981) one may reasonably conclude that it > > was running 7th Edition. I imagine the pascal was Joy's, from Berkeley. > > > > - Dan C. > > > > Great hint. 20 seconds after I hit send on the original email, I came > > across this: > > http://www.lysator.liu.se/c/bwk-on-pascal.html > > > > Where Brian Kernighan talks about the challenges they faced porting the > > ratfor examples into pascal. He explains that: > > > > The programs were first written in that dialect of Pascal supported by the > > Pascal interpreter pi provided by the University of California at Berkeley. The > > language is close to the nominal standard of Jensen and Wirth,(6 > > ) with good > > diagnostics and careful run-time checking. Since then, the programs have > > also been run, unchanged except for new libraries of primitives, on four > > other systems: an interpreter from the Free University of Amsterdam > > (hereinafter referred to as VU, for Vrije Universiteit), a VAX version of > > the Berkeley system (a true compiler), a compiler purveyed by Whitesmiths, > > Ltd., and UCSD Pascal on a Z80. All but the last of these Pascal systems > > are written in C. > > > > So, you were right about it being Joy's pi. > > > > Thanks, > > > > Will > > > > > > On the good news front, I was able to find a working pi/px environment - > > 4.2bsd built from tape on simulated vax780 works great (thank god vi works > > there, too) and will run the programs in the book without mods, out of the > > box. 4.3 would probably work similarly (I put it on the list). I tried > > compiling the pascal distributed via 2bsd on v7, but wasn't able to get it > > built (story of my life). This is prolly expected because the notes in the > > distro say "This is still set up for version 6", so I'll stick with 4.2 for > > the time being. Just glad to have a working environment to supplement the > > reading. > > > > Will > > From clemc at ccc.com Sun Jan 30 05:59:02 2022 From: clemc at ccc.com (Clem Cole) Date: Sat, 29 Jan 2022 14:59:02 -0500 Subject: [TUHS] Looking back to 1981 - what pascal was popular on what unix? In-Reply-To: <0f83f174-eeca-30fb-7b98-77fb0da80f2e@gmail.com> References: <0f83f174-eeca-30fb-7b98-77fb0da80f2e@gmail.com> Message-ID: On Fri, Jan 28, 2022 at 6:08 PM Will Senn wrote: > 1. What edition of UNIX were they likely to be using? > Already answered ... > 2. What versions of "Standard Pascal" were in vogue on UNIX at the time > (1981)? > Remember in 1981, the 'Pascal Standard' was still in flight. ISO 7185 was 1983 and Pascal really does not standardize enough that real portability was possible until the 1990 version and people actually started implementing compilers that obeyed it. > > 3. What combinations of UNIX/Pascal were popular? > Depends the implementation... there were a number of them... there were the ones I had at that time - UCB Pascal -- pi being the most popular for the PDP-11, and later pc for the Vax - VU Pascal for the 11 - The Zurich P4 compiler was around and of course eventually begat UCSD, but I don't remember that it was directly made to run on Unix[I did not have one], although it may/must have been. - The Similer2 compiler for 68000 [was one of Wirth's -- I think was the basis for the compiler that they used for Lilith - or maybe it was a fork that produced the Lilith and the Similer2 compiler -- I don't remember]. That showed up on a couple of the 68K workstations in 1981. - Andy's Amsterdam Toolkit - There was a compiler that the RTS folks had at MIT, but I don't know its origin or how complete it was. - Purdue had something that had started on the CDCs -- that went to Tektronix and was the basis for some of the stuff the Logical Analizer folks were using. It was cross compiler that ran on Unix and generated 8-bit microprocessor code for embedded systems. - Per Brinch Hansen had a Pascal that we was pushing, but I don't think he even moved it to Unix - Plus, the "Tunis" folks in Toronto had a Concurrent-Pascal and a UNIX-like system that ran on PDP-11s. And the problem was 'standard' - lots of people messed with it and every Pascal was a little different. In 1981 at one of the HP/Tektronix [Hatfield/McCoy parties - Stienhart probably remembers], Mike Zuhl, TW Cook and I counted 14 different "Tek Pascal's" and over 25 "HP Basic's" -- each was a little different. UCSD Pascal was its own system, not Unix [sort of like Smalltalk -- a walled garden within itself]. They started with the P4 compiler but they made it work on 8-bit systems, so while it was around, it was not a UNIX Pascal >>and<< it the Standard was still in flight. The OMSI Pascal compiler was popular for the PDP-11's, but it was RT-11 and RSX [maybe RSTS, but I'm not sure]. The Zurich PDP-10 Compiler was very popular in PDP-10 land. DEC released the VAX/pascal for VMS, which they eventually brought to Ultrix and Tru64. I believe that that was a scratch rewrite and did not use P4 or anything from the PDP-10s or CDC systems before it. One of the big issues with P4 based stuff is that the original P2 porting kit from Wirth assumed a 40 bit integer of the CDC system. Making it work with a 36 bit world was a tad easier than the 32 or 16 bit world, much less the 8-bit micros. Folks like DEC, UCB and Amsterdam which started over with a new front end, tended to have an easier go of it and often had better compiler tools [which were mostly C based BTW for UNIX and a combination of Pascal and BLISS at DEC]. Sun later brought the UCB PI and PC to the SunOS, but pls Rob G/Larry correct me here - I think they later did their own compiler when they did their new C and Fortran. Masscomp started with the Similer2 compiler, but eventually did a new front end that matched their C and Fortran like DEC had. As for SWTinP running with FreePascal. I looked into it and decided it was doable, but never went very fair with my investigation since the need for it, was less. Back in the days of VMS, Pr1meOS and the like, SWT was a Godsend. But Windows and like have real Unix subsystems, so I never really was motivated other than pure curiosity. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Sun Jan 30 06:02:42 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Sat, 29 Jan 2022 12:02:42 -0800 Subject: [TUHS] Looking back to 1981 - what pascal was popular on what unix? In-Reply-To: References: <0f83f174-eeca-30fb-7b98-77fb0da80f2e@gmail.com> Message-ID: <202201292002.20TK2gDr2318528@darkstar.fourwinds.com> Clem Cole writes: > > And the problem was 'standard' - lots of people messed with it and every > Pascal was a little different. In 1981 at one of the HP/Tektronix > [Hatfield/McCoy parties - Stienhart probably remembers], Mike Zuhl, TW Cook > and I counted 14 different "Tek Pascal's" and over 25 "HP Basic's" -- each > was a little different. Oh yeah. Part of this was because Pascal wasn't really up to the job. So many product groups added their own p-codes for things that they needed. From bakul at iitbombay.org Sun Jan 30 06:13:06 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Sat, 29 Jan 2022 12:13:06 -0800 Subject: [TUHS] Looking back to 1981 - what pascal was popular on what unix? In-Reply-To: References: <0f83f174-eeca-30fb-7b98-77fb0da80f2e@gmail.com> Message-ID: <8471F958-FB2C-48A3-A8BD-48F53A75C28C@iitbombay.org> On Jan 29, 2022, at 11:59 AM, Clem Cole > wrote: > > Plus, the "Tunis" folks in Toronto had a Concurrent-Pascal and a UNIX-like system that ran on PDP-11s. Tunis was implemented in Concurrent Euclid, a descendant of the Euclid programming language, designed by Ric Hort and James Cordy. They later designed Turing, which had some features from Pascal. [I bought their books during the '80s] Per Brinch Hansen designed Concurrent Pascal and implemented the Solo operating Solo operating system in it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun Jan 30 06:30:49 2022 From: clemc at ccc.com (Clem Cole) Date: Sat, 29 Jan 2022 15:30:49 -0500 Subject: [TUHS] Looking back to 1981 - what pascal was popular on what unix? In-Reply-To: <8471F958-FB2C-48A3-A8BD-48F53A75C28C@iitbombay.org> References: <0f83f174-eeca-30fb-7b98-77fb0da80f2e@gmail.com> <8471F958-FB2C-48A3-A8BD-48F53A75C28C@iitbombay.org> Message-ID: Thanks -- sorry, they all blurr together. On Sat, Jan 29, 2022 at 3:13 PM Bakul Shah wrote: > On Jan 29, 2022, at 11:59 AM, Clem Cole wrote: > > > > - Plus, the "Tunis" folks in Toronto had a Concurrent-Pascal and a > UNIX-like system that ran on PDP-11s. > > > Tunis was implemented in Concurrent Euclid, a descendant of > the Euclid programming language, designed by Ric Hort and > James Cordy. They later designed Turing, which had some > features from Pascal. [I bought their books during the '80s] > > Per Brinch Hansen designed Concurrent Pascal and implemented > the Solo operating Solo operating system in it. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sun Jan 30 06:34:34 2022 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 29 Jan 2022 12:34:34 -0800 Subject: [TUHS] Looking back to 1981 - what pascal was popular on what unix? In-Reply-To: <8471F958-FB2C-48A3-A8BD-48F53A75C28C@iitbombay.org> References: <0f83f174-eeca-30fb-7b98-77fb0da80f2e@gmail.com> <8471F958-FB2C-48A3-A8BD-48F53A75C28C@iitbombay.org> Message-ID: <20220129203434.GQ16452@mcvoy.com> On Sat, Jan 29, 2022 at 12:13:06PM -0800, Bakul Shah wrote: > On Jan 29, 2022, at 11:59 AM, Clem Cole > wrote: > > > > Plus, the "Tunis" folks in Toronto had a Concurrent-Pascal and a UNIX-like system that ran on PDP-11s. > > Tunis was implemented in Concurrent Euclid, a descendant of > the Euclid programming language, designed by Ric Hort and > James Cordy. I read the Tunis book, it seemed pretty cool from the book but I've never played with it. Has anyone? From aek at bitsavers.org Sun Jan 30 07:03:48 2022 From: aek at bitsavers.org (Al Kossow) Date: Sat, 29 Jan 2022 13:03:48 -0800 Subject: [TUHS] Looking back to 1981 - what pascal was popular on what unix? In-Reply-To: <20220129203434.GQ16452@mcvoy.com> References: <0f83f174-eeca-30fb-7b98-77fb0da80f2e@gmail.com> <8471F958-FB2C-48A3-A8BD-48F53A75C28C@iitbombay.org> <20220129203434.GQ16452@mcvoy.com> Message-ID: On 1/29/22 12:34 PM, Larry McVoy wrote: > I read the Tunis book, it seemed pretty cool from the book but I've never > played with it. Has anyone? > http://bitsavers.org/bits/UniversityOfToronto/ PC version From lm at mcvoy.com Sun Jan 30 07:38:55 2022 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 29 Jan 2022 13:38:55 -0800 Subject: [TUHS] Looking back to 1981 - what pascal was popular on what unix? In-Reply-To: References: <0f83f174-eeca-30fb-7b98-77fb0da80f2e@gmail.com> <8471F958-FB2C-48A3-A8BD-48F53A75C28C@iitbombay.org> <20220129203434.GQ16452@mcvoy.com> Message-ID: <20220129213855.GR16452@mcvoy.com> On Sat, Jan 29, 2022 at 01:03:48PM -0800, Al Kossow wrote: > On 1/29/22 12:34 PM, Larry McVoy wrote: > > >I read the Tunis book, it seemed pretty cool from the book but I've never > >played with it. Has anyone? > > > > http://bitsavers.org/bits/UniversityOfToronto/ Is Tunis preserved anywhere and has anyone run it? From will.senn at gmail.com Sun Jan 30 07:48:59 2022 From: will.senn at gmail.com (Will Senn) Date: Sat, 29 Jan 2022 15:48:59 -0600 Subject: [TUHS] 4.3 BSD network name resolution Message-ID: <0C7FF60E-D7B1-434A-87D1-35E1102D7DC6@gmail.com> I'm working through 4.3BSD setup and configuration and came across this: "There is no equivalent service for network names yet. The full host and network name databases are normally derived from a file retrieved from Internet Network Information Center at SRI... use gettable to retrieve the NIC host database and htable to convert it to the format used by the libraries." Does this mean I should expect functionality like resolv.conf and ping yahoo.com not to work in 4.3, or by some miracle is gettable still a functional system? Will Sent from my iPhone -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Sun Jan 30 07:56:28 2022 From: henry.r.bent at gmail.com (Henry Bent) Date: Sat, 29 Jan 2022 16:56:28 -0500 Subject: [TUHS] 4.3 BSD network name resolution In-Reply-To: <0C7FF60E-D7B1-434A-87D1-35E1102D7DC6@gmail.com> References: <0C7FF60E-D7B1-434A-87D1-35E1102D7DC6@gmail.com> Message-ID: On Sat, 29 Jan 2022 at 16:49, Will Senn wrote: > I'm working through 4.3BSD setup and configuration and came across this: > > > "There is no equivalent service for network names yet. The full host and > network name databases are normally derived from a file retrieved from > Internet Network Information Center at SRI... use gettable to retrieve the > NIC host database and htable to convert it to the format used by the > libraries." > > > Does this mean I should expect functionality like resolv.conf and ping > yahoo.com not to work in 4.3, or by some miracle is gettable still a > functional system? > gettable uses flat files to map names to numbers. It hasn't existed in probably 30+ years, and I can't even imagine how large the files it creates would be for the modern internet. Amusingly, for some strange reason it still exists in Solaris 11.2: https://docs.oracle.com/cd/E36784_01/html/E36871/gettable-1m.html -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Sun Jan 30 08:06:15 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Sat, 29 Jan 2022 14:06:15 -0800 Subject: [TUHS] Looking back to 1981 - what pascal was popular on what unix? In-Reply-To: <20220129203434.GQ16452@mcvoy.com> References: <0f83f174-eeca-30fb-7b98-77fb0da80f2e@gmail.com> <8471F958-FB2C-48A3-A8BD-48F53A75C28C@iitbombay.org> <20220129203434.GQ16452@mcvoy.com> Message-ID: <70367224-6523-4C36-A1BE-4AE4F5200B47@iitbombay.org> > On Jan 29, 2022, at 12:34 PM, Larry McVoy wrote: > > On Sat, Jan 29, 2022 at 12:13:06PM -0800, Bakul Shah wrote: >> On Jan 29, 2022, at 11:59 AM, Clem Cole > wrote: >>> >>> Plus, the "Tunis" folks in Toronto had a Concurrent-Pascal and a UNIX-like system that ran on PDP-11s. >> >> Tunis was implemented in Concurrent Euclid, a descendant of >> the Euclid programming language, designed by Ric Hort and >> James Cordy. > > I read the Tunis book, it seemed pretty cool from the book but I've never > played with it. Has anyone? From Tunis I borrowed signal() & wait() as synchronization primitives for the simulation library I wrote in 1983 but that was about it. From henry.r.bent at gmail.com Sun Jan 30 08:08:32 2022 From: henry.r.bent at gmail.com (Henry Bent) Date: Sat, 29 Jan 2022 17:08:32 -0500 Subject: [TUHS] 4.3 BSD network name resolution In-Reply-To: References: <0C7FF60E-D7B1-434A-87D1-35E1102D7DC6@gmail.com> Message-ID: On Sat, 29 Jan 2022 at 16:56, Henry Bent wrote: > On Sat, 29 Jan 2022 at 16:49, Will Senn wrote: > >> I'm working through 4.3BSD setup and configuration and came across this: >> >> >> "There is no equivalent service for network names yet. The full host and >> network name databases are normally derived from a file retrieved from >> Internet Network Information Center at SRI... use gettable to retrieve the >> NIC host database and htable to convert it to the format used by the >> libraries." >> >> >> Does this mean I should expect functionality like resolv.conf and ping >> yahoo.com not to work in 4.3, or by some miracle is gettable still a >> functional system? >> > > gettable uses flat files to map names to numbers. It hasn't existed in > probably 30+ years, and I can't even imagine how large the files it creates > would be for the modern internet. > > Amusingly, for some strange reason it still exists in Solaris 11.2: > https://docs.oracle.com/cd/E36784_01/html/E36871/gettable-1m.html > > A quick search found me a site with an archive of the HOSTS.TXT files that gettable and friends used: https://emaillab.jp/dns/hosts/ To give you an idea of how soon things were obsolete, the files from the '90s have 132.162.32.243 listed as Oberlin's VAX 11/780 ocvaxa, a machine that had not existed for many years at that point. The distributed nature of DNS made things much, much easier to keep current. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sun Jan 30 08:13:25 2022 From: imp at bsdimp.com (Warner Losh) Date: Sat, 29 Jan 2022 15:13:25 -0700 Subject: [TUHS] 4.3 BSD network name resolution In-Reply-To: <0C7FF60E-D7B1-434A-87D1-35E1102D7DC6@gmail.com> References: <0C7FF60E-D7B1-434A-87D1-35E1102D7DC6@gmail.com> Message-ID: On Sat, Jan 29, 2022 at 2:49 PM Will Senn wrote: > I'm working through 4.3BSD setup and configuration and came across this: > > > "There is no equivalent service for network names yet. The full host and > network name databases are normally derived from a file retrieved from > Internet Network Information Center at SRI... use gettable to retrieve the > NIC host database and htable to convert it to the format used by the > libraries." > > > Does this mean I should expect functionality like resolv.conf and ping > yahoo.com not to work in 4.3, or by some miracle is gettable still a > functional system? > DNS post-dates 4.3BSD. The first DNS RFC was published in Nov 1987. 4.3BSD was June 1986. The host table update was a thing, but my school was far enough off the beaten path that by the time we were on the internet, DNS was a thing... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggm at algebras.org Sun Jan 30 08:25:49 2022 From: ggm at algebras.org (George Michaelson) Date: Sun, 30 Jan 2022 08:25:49 +1000 Subject: [TUHS] 4.3 BSD network name resolution In-Reply-To: References: <0C7FF60E-D7B1-434A-87D1-35E1102D7DC6@gmail.com> Message-ID: If you can find source for bind 4<= I'm sure it will compile and give you a working named. Getting the client side code cleanly would mean a later release of BSD but there are client side libs in the bind code AFAIK. You can possibly link against them for rational gethostbyname(). If the link loader ordering thing works, they might supercede simply by placing -lresolv before libc. Bear in mind all the RR type richness postdated this time so you could be sent UDP > 512, and internal state you can't grok. But for A and PTR lookup it should be fine. Since it won't do TCP or DNSSEC or large packet EDNS0 signalling, I suspect a bit of dns flow inbound would be perplexing for the resolver. G On Sun, 30 Jan 2022, 8:13 am Warner Losh, wrote: > > > On Sat, Jan 29, 2022 at 2:49 PM Will Senn wrote: > >> I'm working through 4.3BSD setup and configuration and came across this: >> >> >> "There is no equivalent service for network names yet. The full host and >> network name databases are normally derived from a file retrieved from >> Internet Network Information Center at SRI... use gettable to retrieve the >> NIC host database and htable to convert it to the format used by the >> libraries." >> >> >> Does this mean I should expect functionality like resolv.conf and ping >> yahoo.com not to work in 4.3, or by some miracle is gettable still a >> functional system? >> > > DNS post-dates 4.3BSD. The first DNS RFC was published in Nov 1987. 4.3BSD > was June 1986. The host table update was a thing, but my school was far > enough off the beaten path that by the time we were on the internet, DNS > was a thing... > > Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fair-tuhs at netbsd.org Sun Jan 30 08:35:39 2022 From: fair-tuhs at netbsd.org (Erik E. Fair) Date: Sat, 29 Jan 2022 14:35:39 -0800 Subject: [TUHS] 4.3 BSD network name resolution In-Reply-To: References: Message-ID: <616.1643495739@cesium.clock.org> See RFC 1101, which I'm in part responsible for because I asked Mockapetris for preservation of the functionality. I don't think very many sites bother to maintain this info, and I don't know what (if anything) uses it - kinda like the HINFO RR. Erik Fair From markwgreen at rogers.com Sun Jan 30 08:48:39 2022 From: markwgreen at rogers.com (GREEN) Date: Sat, 29 Jan 2022 17:48:39 -0500 Subject: [TUHS] Looking back to 1981 - what pascal was popular on what unix? In-Reply-To: <70367224-6523-4C36-A1BE-4AE4F5200B47@iitbombay.org> References: <70367224-6523-4C36-A1BE-4AE4F5200B47@iitbombay.org> Message-ID: I was one of the TAs for the grad course that produced Tunis. It was heavily influenced by V6 which we were running at the time. It was designed to run on a stripped down PDP11 so it could be used in a classroom. Sent from my iPhone > On Jan 29, 2022, at 5:07 PM, Bakul Shah wrote: > >  > >> On Jan 29, 2022, at 12:34 PM, Larry McVoy wrote: >> >>> On Sat, Jan 29, 2022 at 12:13:06PM -0800, Bakul Shah wrote: >>> On Jan 29, 2022, at 11:59 AM, Clem Cole > wrote: >>>> >>>> Plus, the "Tunis" folks in Toronto had a Concurrent-Pascal and a UNIX-like system that ran on PDP-11s. >>> >>> Tunis was implemented in Concurrent Euclid, a descendant of >>> the Euclid programming language, designed by Ric Hort and >>> James Cordy. >> >> I read the Tunis book, it seemed pretty cool from the book but I've never >> played with it. Has anyone? > > From Tunis I borrowed signal() & wait() as synchronization > primitives for the simulation library I wrote in 1983 but > that was about it. From clemc at ccc.com Sun Jan 30 08:59:02 2022 From: clemc at ccc.com (Clem Cole) Date: Sat, 29 Jan 2022 17:59:02 -0500 Subject: [TUHS] 4.3 BSD network name resolution In-Reply-To: <0C7FF60E-D7B1-434A-87D1-35E1102D7DC6@gmail.com> References: <0C7FF60E-D7B1-434A-87D1-35E1102D7DC6@gmail.com> Message-ID: Isn't time wonderful ..... 4.2 and 4.3BSD predates the release of bind, which was separately sent into the wild.. The good news is that you can certainly get things working with a static host table. And frankly for a simulated system, the network is likely to be very small and you are unlikely to need more modern services like a browser with URLs et al. That said, the early bind will work on 4.2/4.3 without a lot of hassle, as that's the system that it was developed. Except ..... the problem is the >>client side<< is used all over the place AND that needs to know you a DNS. My suggestion is getting 4.3 running up with a very small (static) host table. Then take on the DNS. The resolv library (client code) is likely to have a lot of static calls to the old (non-DNS based) versions of gethostbyXXX and the like. If you bring bind over, you'r probably going to have to do a full rebuild and relink , reinstall of applications space clients use the DNS, not the static tables. Have fun. Clem On Sat, Jan 29, 2022 at 4:49 PM Will Senn wrote: > I'm working through 4.3BSD setup and configuration and came across this: > > > "There is no equivalent service for network names yet. The full host and > network name databases are normally derived from a file retrieved from > Internet Network Information Center at SRI... use gettable to retrieve the > NIC host database and htable to convert it to the format used by the > libraries." > > > Does this mean I should expect functionality like resolv.conf and ping > yahoo.com not to work in 4.3, or by some miracle is gettable still a > functional system? > > > Will > > Sent from my iPhone > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Sun Jan 30 09:02:20 2022 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Sat, 29 Jan 2022 18:02:20 -0500 Subject: [TUHS] 4.3 BSD network name resolution In-Reply-To: References: <0C7FF60E-D7B1-434A-87D1-35E1102D7DC6@gmail.com> Message-ID: On Sat, Jan 29, 2022 at 05:08:32PM -0500, Henry Bent wrote: > > gettable uses flat files to map names to numbers. It hasn't existed in > > probably 30+ years, and I can't even imagine how large the files it creates > > would be for the modern internet. This brings back memories. Way back when I was on the MIT Network Group[1], I wrote a program which translated a file in HOSTS.TXT format into a DNS zone file for BIND, since originally the HOSTS.TXT format file (stored in RCS for source control) was the source of truth for IP address assignments at MIT. Later on, the authoratative source was the Moira[2] server, which stored the information in an Oracle database, but the nightly extract from the database was still done in a HOSTS.TXT format, which then got translated into a zone file and distributed to MIT's DNS servers. It's quite possible, Moira DCM extract to the HOSTS.TXT file is still in use today; MIT is still using Moira, although there is a web front end that I suspect most of the admins are using these days, instead of the CLI or Curses interfaces. (The hard core Moira admins or developers would occasionally need to do surgery by accessing the Oracle database directly; that's how I first learned SQL. :-) [1] http://web.mit.edu/afs/net.mit.edu/admin/www/network/group.html [2] http://kb.mit.edu/confluence/pages/viewpage.action?pageId=3902604 - Ted From phil at ultimate.com Sun Jan 30 09:24:28 2022 From: phil at ultimate.com (Phil Budne) Date: Sat, 29 Jan 2022 18:24:28 -0500 Subject: [TUHS] 4.3 BSD network name resolution In-Reply-To: References: <0C7FF60E-D7B1-434A-87D1-35E1102D7DC6@gmail.com> Message-ID: <202201292324.20TNOSdf090762@ultimate.com> 4.3 BSD Quasijarus (a pre-Tahoe branch of 4.3) looks like it comes with resolver files in libc. Ready to run .dsk file for SimH: https://github.com/narukeh/4.3BSD-Quasijarus Instructions on installing from tape image: https://www.tavi.co.uk/unixhistory/quasijarus.html http://gunkies.org/wiki/Installing_4.3_BSD_Quasijarus_on_SIMH Sources repo? https://github.com/abs0/4.3BSD-Quasijarus From reed at reedmedia.net Sun Jan 30 10:09:12 2022 From: reed at reedmedia.net (Jeremy C. Reed) Date: Sat, 29 Jan 2022 18:09:12 -0600 (CST) Subject: [TUHS] 4.3 BSD network name resolution In-Reply-To: <0C7FF60E-D7B1-434A-87D1-35E1102D7DC6@gmail.com> References: <0C7FF60E-D7B1-434A-87D1-35E1102D7DC6@gmail.com> Message-ID: > "There is no equivalent service for network names yet. The full host and I see that in usr/doc/smm/01.setup/5.t Do you have usr/doc/smm/11.named ? Have a look at the resolver(3) and resolver(5) and gethostbyname(3n) and named(8) manual pages with 4.3BSD. And see /usr/src/etc/named/doc for the November 1983 RFC 883 specification. (I haven't used that old one, but I did use a 1990 BIND 4.8.3 from 4.3BSD-Reno / 386BSD using NetBSD compat and documented some of its behavior with modern DNS.) From athornton at gmail.com Sun Jan 30 11:20:25 2022 From: athornton at gmail.com (Adam Thornton) Date: Sat, 29 Jan 2022 18:20:25 -0700 Subject: [TUHS] FYI: Internet Old Farts Club In-Reply-To: <20220129023641.GL16452@mcvoy.com> References: <54965199-5023-4F99-AF27-8615E319E302@cfcl.com> <20220127015505.GC10568@netmeister.org> <20220129023641.GL16452@mcvoy.com> Message-ID: On Fri, Jan 28, 2022 at 7:37 PM Larry McVoy wrote: > I can only speak for myself but hell will freeze over > before I have a Facebook account > In this instance you're speaking for me too. -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Sun Jan 30 12:10:42 2022 From: will.senn at gmail.com (Will Senn) Date: Sat, 29 Jan 2022 20:10:42 -0600 Subject: [TUHS] FYI: Internet Old Farts Club In-Reply-To: References: <54965199-5023-4F99-AF27-8615E319E302@cfcl.com> <20220127015505.GC10568@netmeister.org> <20220129023641.GL16452@mcvoy.com> Message-ID: On 1/29/22 7:20 PM, Adam Thornton wrote: > > > On Fri, Jan 28, 2022 at 7:37 PM Larry McVoy wrote: > >  I can only speak for myself but hell will freeze over > before I have a Facebook account > > > In this instance you're speaking for me too. FB and I went round and round in 2018 when I opened an account and they disabled it that same day and demanded verification of my identity. They were never willing/able to enable the account for more than a few hours, even after I got the Better Business Bureau involved. The only single piece of content I ever posted to the account was a background image (a pic I took in Fort Collins, Colorado of a mountainside). After BBB got involved, they would enable the account (after I provided ID verification), only to disable it again after a few hours. This went on for about 5 months (I was tenancious and curious to see if it could ever be resolved). Eventually, I got bored and tired of going back and forth with BBB and the faceless monstrosity that FB is. An intelligence buddy of mine said it was all for the better anyway... I'm on the hell freezing over side of things :). -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sun Jan 30 13:27:16 2022 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 29 Jan 2022 19:27:16 -0800 Subject: [TUHS] Looking back to 1981 - what pascal was popular on what unix? In-Reply-To: References: <70367224-6523-4C36-A1BE-4AE4F5200B47@iitbombay.org> Message-ID: <20220130032716.GV16452@mcvoy.com> So what did you think of Tunis compared to V6? I really liked the book, I'm hoping it was good but reality is not always that. On Sat, Jan 29, 2022 at 05:48:39PM -0500, GREEN wrote: > I was one of the TAs for the grad course that produced Tunis. It was heavily influenced by V6 which we were running at the time. It was designed to run on a stripped down PDP11 so it could be used in a classroom. > > Sent from my iPhone > > > On Jan 29, 2022, at 5:07 PM, Bakul Shah wrote: > > > > ??? > > > >> On Jan 29, 2022, at 12:34 PM, Larry McVoy wrote: > >> > >>> On Sat, Jan 29, 2022 at 12:13:06PM -0800, Bakul Shah wrote: > >>> On Jan 29, 2022, at 11:59 AM, Clem Cole > wrote: > >>>> > >>>> Plus, the "Tunis" folks in Toronto had a Concurrent-Pascal and a UNIX-like system that ran on PDP-11s. > >>> > >>> Tunis was implemented in Concurrent Euclid, a descendant of > >>> the Euclid programming language, designed by Ric Hort and > >>> James Cordy. > >> > >> I read the Tunis book, it seemed pretty cool from the book but I've never > >> played with it. Has anyone? > > > > From Tunis I borrowed signal() & wait() as synchronization > > primitives for the simulation library I wrote in 1983 but > > that was about it. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From mochid at netside.co.jp Sun Jan 30 14:19:16 2022 From: mochid at netside.co.jp (MOCHIDA Shuji) Date: Sun, 30 Jan 2022 13:19:16 +0900 (JST) Subject: [TUHS] Yet one more arch 4.4BSD binary set, hp300 In-Reply-To: <20220119.232904.1448404747269354902.mochid@netside.co.jp> References: <20220119.232904.1448404747269354902.mochid@netside.co.jp> Message-ID: <20220130.131916.2265165052392681199.mochid@netside.co.jp> Hi., I compiled 4.4BSD for hp300, original main target architecture. That is cross compiled on NetBSD 1.1/sun3, m68k a.out environment. I have no hp300 hardware, nor emulator software, so, NOT TESTED at all. If you would try booting it, below might be useful: https://docs.freebsd.org/44doc/smm/01.setup/paper.html Subject: One more arch 4.4BSD binary set, luna68k on nono OMRON LUNA emulator Date: Wed, 19 Jan 2022 23:29:04 +0900 (JST) > > One of architechture supported by 4.4BSD, luna68k's compiled binary is > now available. > > http://www.netside.co.jp/~mochid/comp/bsd44-build/ > > luna68k is OMRON LUNA, m68k cpu workstation. This binary set works on > "nono" emulator software. > > http://www.pastel-flower.jp/~isaki/nono/ > > It's author, Isaki-san have done some minor modification for 4.4BSD, > binary set for luna68k run rather well. > > OMRON, already dropped thier workstation products. LUNA-I, LUNA-II > equipped with m68k, same CPU as CSRG's main target arch hp300. > So userland programs may binary compatible. > > -mochid From will.senn at gmail.com Mon Jan 31 02:03:07 2022 From: will.senn at gmail.com (Will Senn) Date: Sun, 30 Jan 2022 10:03:07 -0600 Subject: [TUHS] Ratfor s Message-ID: <87492671-3406-49DF-B458-5F701DDFC09B@gmail.com> Has anyone seen Fraser's original ratfor source for the s editor for unix on the PDP-11. It was a screen editor front-end built on top of Software Tools's edit. I've seen a c version, but I'm interested in the 375 line version :). Will Sent from my iPhone From arnold at skeeve.com Mon Jan 31 02:09:11 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 30 Jan 2022 09:09:11 -0700 Subject: [TUHS] Ratfor s In-Reply-To: <87492671-3406-49DF-B458-5F701DDFC09B@gmail.com> References: <87492671-3406-49DF-B458-5F701DDFC09B@gmail.com> Message-ID: <202201301609.20UG9CpQ023310@freefriends.org> Will Senn wrote: > Has anyone seen Fraser's original ratfor source for the s editor for unix on the PDP-11. It was a screen editor front-end built on top of Software Tools's edit. I've seen a c version, but I'm interested in the 375 line version :). > > Will > > Sent from my iPhone I've never heard of this. Can you give some background please? Thanks, Arnold From will.senn at gmail.com Mon Jan 31 02:12:21 2022 From: will.senn at gmail.com (Will Senn) Date: Sun, 30 Jan 2022 10:12:21 -0600 Subject: [TUHS] Ratfor s In-Reply-To: <202201301609.20UG9CpQ023310@freefriends.org> References: <87492671-3406-49DF-B458-5F701DDFC09B@gmail.com> <202201301609.20UG9CpQ023310@freefriends.org> Message-ID: <555F6961-A97C-4CCE-9AE9-20A49525AEAF@gmail.com> Hi Arnold, It was mentioned in the STinP edit discussion, so of course, I had to go looking! Here's the referenced article by Fraser: https://archive.org/details/compact-portable-crt Will Sent from my iPhone > On Jan 30, 2022, at 10:09 AM, arnold at skeeve.com wrote: > > Will Senn wrote: > >> Has anyone seen Fraser's original ratfor source for the s editor for unix on the PDP-11. It was a screen editor front-end built on top of Software Tools's edit. I've seen a c version, but I'm interested in the 375 line version :). >> >> Will >> >> Sent from my iPhone > > I've never heard of this. Can you give some background please? > > Thanks, > > Arnold -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at kdbarto.org Mon Jan 31 02:57:20 2022 From: david at kdbarto.org (David Barto) Date: Sun, 30 Jan 2022 08:57:20 -0800 Subject: [TUHS] Looking back to 1981 - what pascal was popular on what unix? In-Reply-To: References: <0f83f174-eeca-30fb-7b98-77fb0da80f2e@gmail.com> Message-ID: <9E47A62E-3AAD-491E-9164-3DCAD22EC1F7@kdbarto.org> > On Jan 29, 2022, at 11:59 AM, Clem Cole wrote: > > > > On Fri, Jan 28, 2022 at 6:08 PM Will Senn > wrote: > > 3. What combinations of UNIX/Pascal were popular? > Depends the implementation... there were a number of them... there were the ones I had at that time > The Zurich P4 compiler was around and of course eventually begat UCSD, but I don't remember that it was directly made to run on Unix[I did not have one], although it may/must have been. Yes, the UCSD P-code interpreter was ported to 4.1 BSD on the VAX and it ran natively there. I used it on sdcsvax in my senior year (1980). David -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Mon Jan 31 03:02:38 2022 From: clemc at ccc.com (Clem Cole) Date: Sun, 30 Jan 2022 12:02:38 -0500 Subject: [TUHS] Ratfor s In-Reply-To: <87492671-3406-49DF-B458-5F701DDFC09B@gmail.com> References: <87492671-3406-49DF-B458-5F701DDFC09B@gmail.com> Message-ID: On Sun, Jan 30, 2022 at 11:03 AM Will Senn wrote: > Has anyone seen Fraser's original ratfor source for the s editor for unix > on the PDP-11. It was a screen editor front-end built on top of Software > Tools's edit. I've seen a c version, but I'm interested in the 375 line > version :). I'm not sure they are the same editor. The C program called s is part of Webb Miller's Software Tools Sampler and it's a full editor, not a front end [see: Webb Miller's S Tiny VI editor ]. By design, it is mostly vi compatible. This paper from Chris Feazer seems to be a front end for SWT editor, and was original done on the PDP-10 [which makes sense] and seems to be contemporary to the vi work at UCB and in fact called back to the SWT editor (which was >>modeled<< on UNIX ed), as opposed to ex/vi which are extensions to the v6 implementation of the UNIX ed editor. -------------- next part -------------- An HTML attachment was scrubbed... URL: From drsalists at gmail.com Mon Jan 31 04:07:15 2022 From: drsalists at gmail.com (Dan Stromberg) Date: Sun, 30 Jan 2022 10:07:15 -0800 Subject: [TUHS] Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix? In-Reply-To: <9E47A62E-3AAD-491E-9164-3DCAD22EC1F7@kdbarto.org> References: <0f83f174-eeca-30fb-7b98-77fb0da80f2e@gmail.com> <9E47A62E-3AAD-491E-9164-3DCAD22EC1F7@kdbarto.org> Message-ID: On Sun, Jan 30, 2022 at 8:58 AM David Barto wrote: > Yes, the UCSD P-code interpreter was ported to 4.1 BSD on the VAX and it > ran natively there. I used it on sdcsvax in my senior year (1980). > This reminds me of a question I've had percolating in the back of my mind. Was USCD Pascal "compiled" or "interpreted" or both? And is Java? They both have a byte code interpreter. Yes, modern Java is JIT-compiled, but does that make Java a compiled language in the Oracle implementation, or is it an interpreter with a pretty good runtime? Wasn't Java referred to as "compiled" even back before the JIT compiler was added? Granted, gcj is compiled. But Oracle's implementation of Java is commonly referred to as a "Compiler". And what about back before Java's JIT compiler was added - ISTR recall Java was referred to as a compiled language before the JIT addition. And then there's the CPython implementation of Python. It too uses a byte code interpreter, but it's commonly referred to as "interpreted". But is it really? Granted, it has an implicit, cached compilation step, but is it less compiled for that? Is there consistency here? -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at kdbarto.org Mon Jan 31 06:09:12 2022 From: david at kdbarto.org (David Barto) Date: Sun, 30 Jan 2022 12:09:12 -0800 Subject: [TUHS] Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix? In-Reply-To: References: Message-ID: <075FBF35-8327-4BD1-B532-C7D7DC71375A@kdbarto.org> > On Jan 30, 2022, at 10:08 AM, Dan Stromberg wrote: > >  > >> On Sun, Jan 30, 2022 at 8:58 AM David Barto wrote: >> Yes, the UCSD P-code interpreter was ported to 4.1 BSD on the VAX and it ran natively there. I used it on sdcsvax in my senior year (1980). > > This reminds me of a question I've had percolating in the back of my mind. > > Was USCD Pascal "compiled" or "interpreted" or both? > > And is Java? They both have a byte code interpreter. Yes, modern Java is JIT-compiled, but does that make Java a compiled language in the Oracle implementation, or is it an interpreter with a pretty good runtime? Wasn't Java referred to as "compiled" even back before the JIT compiler was added? Granted, gcj is compiled. But Oracle's implementation of Java is commonly referred to as a "Compiler". And what about back before Java's JIT compiler was added - ISTR recall Java was referred to as a compiled language before the JIT addition. > > And then there's the CPython implementation of Python. It too uses a byte code interpreter, but it's commonly referred to as "interpreted". But is it really? Granted, it has an implicit, cached compilation step, but is it less compiled for that? > > Is there consistency here? > UCSD Pascal was “compiled” into the byte code of the interpreter. I wrote a P-code assembler in my senior year as part of the compiler class. Java started out doing the same thing and over time native code generation was added in gcj. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From silas8642 at hotmail.co.uk Mon Jan 31 06:09:41 2022 From: silas8642 at hotmail.co.uk (silas poulson) Date: Sun, 30 Jan 2022 20:09:41 +0000 Subject: [TUHS] Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix? References: Message-ID: Resending this as realised accidentally replied off list Silas On 30 Jan 2022, at 18:39, silas poulson > wrote: On 30 Jan 2022, at 18:07, Dan Stromberg > wrote: And is Java? They both have a byte code interpreter. My understanding is Java is both a compiled and interpreted language - with javac compiling java code to byte code and then JVM interpreting and executing the byte code. And then there's the CPython implementation of Python. Granted, it has an implicit, cached compilation step, but is it less compiled for that? I would so no - in my mind compiling analyses the entire source and then translates it whilst interpreters only explore a single line or expression. Simply because the compilation happens only Just In Time, doesn’t make it any less of a compilation step. Hope that helps, Silas -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Mon Jan 31 08:51:47 2022 From: crossd at gmail.com (Dan Cross) Date: Sun, 30 Jan 2022 17:51:47 -0500 Subject: [TUHS] Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix? In-Reply-To: References: <0f83f174-eeca-30fb-7b98-77fb0da80f2e@gmail.com> <9E47A62E-3AAD-491E-9164-3DCAD22EC1F7@kdbarto.org> Message-ID: On Sun, Jan 30, 2022 at 1:08 PM Dan Stromberg wrote: > On Sun, Jan 30, 2022 at 8:58 AM David Barto wrote: > >> Yes, the UCSD P-code interpreter was ported to 4.1 BSD on the VAX and it >> ran natively there. I used it on sdcsvax in my senior year (1980). >> > > This reminds me of a question I've had percolating in the back of my mind. > > Was USCD Pascal "compiled" or "interpreted" or both? > As others have mentioned, both. The compiler generated P-code, which was a specialized bytecode representation of the compiled Pascal source. The beauty of this is that it makes porting the system fairly easy; one need only write a P-code interpreter. Assuming the system ships with a p-code "binary" representation of the compiler in addition to the sources, one could make it self-hosting very easily. With a threaded P-code interpreter, it can also be quite small, making constrained 8-bit microcomputers (like the Apple II) reasonable targets for Pascal. This sort of representation also has some interesting properties with respect to the actual bytecode used; it could, for example, have some understanding of the semantics of types in the programming language. The Dis virtual machine for the Limbo programming language used with the Inferno virtual operating system did this; Dis understood Limbo strings, whereas this isn't true on most machine architectures. And is Java? They both have a byte code interpreter. Yes, modern Java is > JIT-compiled, but does that make Java a compiled language in the Oracle > implementation, or is it an interpreter with a pretty good runtime? > Again, both. The compiler emits java bytecodes, which the JVM interprets. Wasn't Java referred to as "compiled" even back before the JIT compiler was > added? > Yes! Granted, gcj is compiled. > Well, gcj (optionally) compiles to native machine code and comes with a library that implements the functionality usually provided by the JVM; that is, it can target a platform other than the JVM and give mostly the same functionality. But javac and gcj are both very much compilers. But Oracle's implementation of Java is commonly referred to as a > "Compiler". And what about back before Java's JIT compiler was added - > ISTR recall Java was referred to as a compiled language before the JIT > addition. > This is correct. A compiler simply transforms some representation of data into a different representation of that same data, possibly with some semantic loss; the canonical example is textual "source code" for some programming language translated into object code for some target hardware architecture, but this need not be the case. We were discussing troff and TeX the other day; both of these are compilers, in that they take some high-level source representation of a document and transform it into a typeset representation. (Note: I mean "semantic loss" in the sense that, say, we may lose details about types or the organization of data in the compiled artifact.) And then there's the CPython implementation of Python. It too uses a byte > code interpreter, but it's commonly referred to as "interpreted". But is > it really? Granted, it has an implicit, cached compilation step, but is it > less compiled for that? > I think that "interpreted" in this context means the load-and-go nature of the system and the transience of the bytecode: the text is internally compiled and then executed, but these steps are often linked and, while one can coax the Python "interpreter" to emit .pyc and/or .pyo files, usually one does not: the compiled bytecodes are lost as soon as the program is done executing. Is there consistency here? > Not really. As an interesting aside, before Java became widespread I heard folks mention "P-code" as a generic term for what most folks mean when they say "bytecode." Now we often just say "bytecode." Similarly with JIT in lieu of "load and go", though Java's JIT is a bit different (it's converting from bytecode to native machine code on the fly; it's even more elaborate when things like hot-spot are taken into account, where the runtime has a kind of built-in profiler and will optimize particularly expensive bits of the code over time). - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From drsalists at gmail.com Mon Jan 31 09:57:41 2022 From: drsalists at gmail.com (Dan Stromberg) Date: Sun, 30 Jan 2022 15:57:41 -0800 Subject: [TUHS] Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix? In-Reply-To: References: <0f83f174-eeca-30fb-7b98-77fb0da80f2e@gmail.com> <9E47A62E-3AAD-491E-9164-3DCAD22EC1F7@kdbarto.org> Message-ID: On Sun, Jan 30, 2022 at 2:52 PM Dan Cross wrote: > On Sun, Jan 30, 2022 at 1:08 PM Dan Stromberg wrote: > >> On Sun, Jan 30, 2022 at 8:58 AM David Barto wrote: >> >>> Yes, the UCSD P-code interpreter was ported to 4.1 BSD on the VAX and it >>> ran natively there. I used it on sdcsvax in my senior year (1980). >>> >> >> Wasn't Java referred to as "compiled" even back before the JIT compiler >> was added? >> > > Yes! > > And then there's the CPython implementation of Python. It too uses a byte >> code interpreter, but it's commonly referred to as "interpreted". But is >> it really? Granted, it has an implicit, cached compilation step, but is it >> less compiled for that? >> > > I think that "interpreted" in this context means the load-and-go nature of > the system and the transience of the bytecode: the text is internally > compiled and then executed, but these steps are often linked and, while one > can coax the Python "interpreter" to emit .pyc and/or .pyo files, usually > one does not: the compiled bytecodes are lost as soon as the program is > done executing. > An interesting response. I'll point out though, being a little picky, that python's "import" statement will look for a .py, compile it, and write the byte code as a .pyc - automatically. Then on subsequent invocations of the program(s) using this module it will compare timestamps on the .py and .pyc and if the .pyc is more recent than the .py, the compilation step will be skipped. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cym224 at gmail.com Mon Jan 31 10:23:24 2022 From: cym224 at gmail.com (Nemo Nusquam) Date: Sun, 30 Jan 2022 19:23:24 -0500 Subject: [TUHS] Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix? In-Reply-To: References: <0f83f174-eeca-30fb-7b98-77fb0da80f2e@gmail.com> <9E47A62E-3AAD-491E-9164-3DCAD22EC1F7@kdbarto.org> Message-ID: <71ce6652-cf15-44db-01df-62ab89a5a134@gmail.com> On 2022-01-30 17:51, Dan Cross wrote (in part): > Not really. As an interesting aside, before Java became widespread I > heard folks mention "P-code" as a generic term for what most folks > mean when they say "bytecode." Now we often just say "bytecode." Wirth called his Pascal bytecode P-code and his Modula bytecode M-code.  Why did Gosling not call his bytecode "J-code"? >         - Dan C. From usotsuki at buric.co Mon Jan 31 10:45:30 2022 From: usotsuki at buric.co (Steve Nickolas) Date: Sun, 30 Jan 2022 19:45:30 -0500 (EST) Subject: [TUHS] Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix? In-Reply-To: <71ce6652-cf15-44db-01df-62ab89a5a134@gmail.com> References: <0f83f174-eeca-30fb-7b98-77fb0da80f2e@gmail.com> <9E47A62E-3AAD-491E-9164-3DCAD22EC1F7@kdbarto.org> <71ce6652-cf15-44db-01df-62ab89a5a134@gmail.com> Message-ID: On Sun, 30 Jan 2022, Nemo Nusquam wrote: > On 2022-01-30 17:51, Dan Cross wrote (in part): >> Not really. As an interesting aside, before Java became widespread I heard >> folks mention "P-code" as a generic term for what most folks mean when they >> say "bytecode." Now we often just say "bytecode." > > Wirth called his Pascal bytecode P-code and his Modula bytecode M-code.  Why > did Gosling not call his bytecode "J-code"? And I think I've heard the Infocom compilers' bytecode called "Z-code" (I use this term too). -uso. From phil at ultimate.com Mon Jan 31 11:41:11 2022 From: phil at ultimate.com (Phil Budne) Date: Sun, 30 Jan 2022 20:41:11 -0500 Subject: [TUHS] Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix? In-Reply-To: References: <0f83f174-eeca-30fb-7b98-77fb0da80f2e@gmail.com> <9E47A62E-3AAD-491E-9164-3DCAD22EC1F7@kdbarto.org> Message-ID: <202201310141.20V1fBoE021496@ultimate.com> > Is there consistency here? There's a wide spectrum of strategies used for implementation of languages, and no perfect and universally agreed on taxonomy. (And in networking, where there is an "International Standard" taxonomy, both the original ARPAnet, and the modern Internet don't fit into the (ISO) model!) At ends of the spectrum you might get people to agree on the "pure interpreter", which intreprets source code DIRECTLY, and the "native code compiler", which generates instructions for the instruction set of a physical computer (typically the one the compiler is running on, with the term "cross compiler" used when the target architecture is different than the one the compiler is running on). I don't doubt this has been brought up many times in the "comp.compilers" group: https://compilers.iecc.com/ To bring the discussion back to "Unix Heritage": The earliest Unix shells were pure interpreters (and for all I know, most still are). Some BASIC language systems have been pure interpreters, but it gets murky fast; Some interpretive systems have converted source code to tokens in memory, or even saved to disk. Beyond pure interpreters, most interpreters perform some kind of compilation into some alternate representation of the program often starting (with and sometimes (LISP), ending) with a tree. Often, the tree is traversed to a prefix or postfix "polish" form, which might, or might not be written out (as a byte code, or other intermediate form). The earliest Unix language systems (TMG and B) on both the PDP-7 and PDP-11 are interesting in that they output "word code" that is assembled by as, and loaded with ld to produce "regular" executable files which contain interpreters. The earliest (PDP-7) Unix compilers, TMG and B both generated code for (stack-oriented, postfix) pseudo machines (which happened to have opcode fields the same size and position as the PDP-7 itself). Since PDP-11 pointers can be a full 16-bit word, PDP-11 TMG and B generate a stream of 16-bit postfix code (with pointers to interpreter and "native code" support routines). TMG contains an interpreter loop, but the B interpreter is "threaded code" using machine register r3 for the interpreter program counter, and each interpreter opcode routine ends with "jmp *(r3)+" I haven't examined Sixth Edition "bas" (written in assembler) closely enough to say what kind of internal representation (if any) it uses. "bc" generates postfix "dc" code using a yacc parser, and "sno" appears to recursively eval a tree. Seventh Edition awk looks to recursively execute a tree generated by a yacc parser. Compilers on older/smaller systems were sometimes divided into multiple passes and wrote intermediate representations to disk, and such output _could_ have been interpreted. Language processors which output source code for another language (on heritage Unix; struct, ratfor, and cfront for early C++) are usually called preprocessors. So... Interpreters and preprocessors may perform much the same work as compilers in their front ends, may or may not be identified as compilers. Java (and UCSD Pascal?) have compilers (to virtual machine code) and an interpreter (for the virtual machine code). Clear as mud? From arnold at skeeve.com Mon Jan 31 17:13:59 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 31 Jan 2022 00:13:59 -0700 Subject: [TUHS] Ratfor s In-Reply-To: <555F6961-A97C-4CCE-9AE9-20A49525AEAF@gmail.com> References: <87492671-3406-49DF-B458-5F701DDFC09B@gmail.com> <202201301609.20UG9CpQ023310@freefriends.org> <555F6961-A97C-4CCE-9AE9-20A49525AEAF@gmail.com> Message-ID: <202201310713.20V7Dxxf023410@freefriends.org> Thanks for the link. I skimmed it and will read it later. What struck me was the splitting of the editor into front and back ends that did not have to be on the same machine. Rob Pike used that design for "sam" somewhat later. I wonder if he got the idea from 's' or came up with it on his own... (Dough, thoughts?) Thanks, Arnold Will Senn wrote: > Hi Arnold, > > It was mentioned in the STinP edit discussion, so of course, I had to go looking! Here's the referenced article by Fraser: > > https://archive.org/details/compact-portable-crt > > Will > Sent from my iPhone > > > On Jan 30, 2022, at 10:09 AM, arnold at skeeve.com wrote: > > > > Will Senn wrote: > > > >> Has anyone seen Fraser's original ratfor source for the s editor for unix on the PDP-11. It was a screen editor front-end built on top of Software Tools's edit. I've seen a c version, but I'm interested in the 375 line version :). > >> > >> Will > >> > >> Sent from my iPhone > > > > I've never heard of this. Can you give some background please? > > > > Thanks, > > > > Arnold From arnold at skeeve.com Mon Jan 31 17:21:45 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 31 Jan 2022 00:21:45 -0700 Subject: [TUHS] Ratfor s In-Reply-To: <202201310713.20V7Dxxf023410@freefriends.org> References: <87492671-3406-49DF-B458-5F701DDFC09B@gmail.com> <202201301609.20UG9CpQ023310@freefriends.org> <555F6961-A97C-4CCE-9AE9-20A49525AEAF@gmail.com> <202201310713.20V7Dxxf023410@freefriends.org> Message-ID: <202201310721.20V7LjiB024836@freefriends.org> arnold at skeeve.com wrote: > Thanks for the link. I skimmed it and will read it later. > > What struck me was the splitting of the editor into front and back ends > that did not have to be on the same machine. Rob Pike used that design > for "sam" somewhat later. I wonder if he got the idea from 's' or came > up with it on his own... (Dough, thoughts?) Typo (embarassment). Should be "Doug, thoughts?". Sigh. > Thanks, > > Arnold > > Will Senn wrote: > > > Hi Arnold, > > > > It was mentioned in the STinP edit discussion, so of course, I had to go looking! Here's the referenced article by Fraser: > > > > https://archive.org/details/compact-portable-crt > > > > Will > > Sent from my iPhone > > > > > On Jan 30, 2022, at 10:09 AM, arnold at skeeve.com wrote: > > > > > > Will Senn wrote: > > > > > >> Has anyone seen Fraser's original ratfor source for the s editor for unix on the PDP-11. It was a screen editor front-end built on top of Software Tools's edit. I've seen a c version, but I'm interested in the 375 line version :). > > >> > > >> Will > > >> > > >> Sent from my iPhone > > > > > > I've never heard of this. Can you give some background please? > > > > > > Thanks, > > > > > > Arnold From hveit01 at web.de Mon Jan 31 17:59:06 2022 From: hveit01 at web.de (WEB) Date: Mon, 31 Jan 2022 08:59:06 +0100 Subject: [TUHS] Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix? In-Reply-To: <075FBF35-8327-4BD1-B532-C7D7DC71375A@kdbarto.org> References: <075FBF35-8327-4BD1-B532-C7D7DC71375A@kdbarto.org> Message-ID: <864d655d-35e3-a805-b187-b52aae6dba7d@web.de> Am 30.01.2022 um 21:09 schrieb David Barto: > >> On Jan 30, 2022, at 10:08 AM, Dan Stromberg wrote: >> On Sun, Jan 30, 2022 at 8:58 AM David Barto wrote: >> >> Yes, the UCSD P-code interpreter was ported to 4.1 BSD on the VAX >> and it ran natively there. I used it on sdcsvax in my senior year >> (1980). >> >> >> This reminds me of a question I've had percolating in the back of my >> mind. >> >> Was USCD Pascal "compiled" or "interpreted" or both? [..] > UCSD Pascal was “compiled” into the byte code of the interpreter. I > wrote a P-code assembler in my senior year as part of the compiler > class. Java started out doing the same thing and over time native code > generation was added in gcj. Just for the record: There has been the WD9000 chipset which is actually an LSI-11 with different Microms which could run the P-code (of UCSD Pascal III) natively as it was its machine code. So this makes a distinction of interpreted vs compiled even more fuzzy. Holger -------------- next part -------------- An HTML attachment was scrubbed... URL: