From tuhs at tuhs.org Tue Aug 1 08:57:45 2023 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Mon, 31 Jul 2023 17:57:45 -0500 Subject: [TUHS] Cool talk on Unix and Sendmail history, by Eric Allman In-Reply-To: References: <8246.1690761540@cesium.clock.org> Message-ID: <1b4e69b9-ec44-ef71-253a-9ca6c3976061@tnetconsulting.net> On 7/30/23 7:26 PM, Warner Losh wrote: > Write once, run everywhere. Wasn't that "Java" proper and not "JavaScript"? Grant. . . . From imp at bsdimp.com Tue Aug 1 09:05:56 2023 From: imp at bsdimp.com (Warner Losh) Date: Mon, 31 Jul 2023 17:05:56 -0600 Subject: [TUHS] Cool talk on Unix and Sendmail history, by Eric Allman In-Reply-To: <1b4e69b9-ec44-ef71-253a-9ca6c3976061@tnetconsulting.net> References: <8246.1690761540@cesium.clock.org> <1b4e69b9-ec44-ef71-253a-9ca6c3976061@tnetconsulting.net> Message-ID: On Mon, Jul 31, 2023, 4:58 PM Grant Taylor via TUHS wrote: > On 7/30/23 7:26 PM, Warner Losh wrote: > > Write once, run everywhere. > > Wasn't that "Java" proper and not "JavaScript"? > It was.. but since Javascript has the name Java in it... I thought I'd make that joke... Warner > > Grant. . . . > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikke.karlsson at gmail.com Tue Aug 1 11:51:28 2023 From: nikke.karlsson at gmail.com (Niklas Karlsson) Date: Tue, 1 Aug 2023 03:51:28 +0200 Subject: [TUHS] Cool talk on Unix and Sendmail history, by Eric Allman In-Reply-To: References: <8246.1690761540@cesium.clock.org> Message-ID: Den mån 31 juli 2023 kl 02:27 skrev Warner Losh : > > > On Sun, Jul 30, 2023, 5:59 PM Erik E. Fair wrote: > >> >> Date: Mon, 31 Jul 2023 09:34:56 +1000 >> From: George Michaelson >> >> [...] >> >> Execute on read is just awful. But, now we have HTML to track >> "they >> read it" through URL fetch. >> >> And then the utterly disastrous: JavaScript. It should be *eliminated* >> from the WWW as the gross security violation it is. >> >> "don't run software from strangers", >> > > > Write once, run everywhere. > I've seen some cynical people render it as "write once, run away". Niklas -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Tue Aug 1 12:45:43 2023 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Mon, 31 Jul 2023 21:45:43 -0500 Subject: [TUHS] Cool talk on Unix and Sendmail history, by Eric Allman In-Reply-To: References: <8246.1690761540@cesium.clock.org> <1b4e69b9-ec44-ef71-253a-9ca6c3976061@tnetconsulting.net> Message-ID: On 7/31/23 6:05 PM, Warner Losh wrote: > It was.. but since Javascript has the name Java in it... I thought I'd > make that joke... Fair enough. I thought perhaps I was misremembering things and more caught up in trying to correct my mental understanding and failed to see the humor. -- Grant. . . . From tuhs at tuhs.org Tue Aug 1 12:47:26 2023 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Mon, 31 Jul 2023 21:47:26 -0500 Subject: [TUHS] Cool talk on Unix and Sendmail history, by Eric Allman In-Reply-To: References: <8246.1690761540@cesium.clock.org> Message-ID: On 7/31/23 8:51 PM, Niklas Karlsson wrote: > I've seen some cynical people render it as "write once, run away". I've heard: - Write once and crash everywhere. - Just another vulnerability announcement. -- Grant. . . . From tytso at mit.edu Tue Aug 1 13:20:22 2023 From: tytso at mit.edu (Theodore Ts'o) Date: Mon, 31 Jul 2023 23:20:22 -0400 Subject: [TUHS] Cool talk on Unix and Sendmail history, by Eric Allman In-Reply-To: References: <8246.1690761540@cesium.clock.org> Message-ID: <20230801032022.GB358316@mit.edu> On Tue, Aug 01, 2023 at 03:51:28AM +0200, Niklas Karlsson wrote: > > > > Write once, run everywhere. > > I've seen some cynical people render it as "write once, run away". I've always preferred, "Write once, run screaming". :-) - Ted From rminnich at gmail.com Tue Aug 1 15:47:54 2023 From: rminnich at gmail.com (ron minnich) Date: Mon, 31 Jul 2023 22:47:54 -0700 Subject: [TUHS] shell escapes in utilities Message-ID: I got to wondering, based on the sendmail discussions, how many shell escapes have appeared over the years? uucp sendmail xdvi : "The "allowShell" option enables the shell escape in PostScript specials" There must be a lot of them, however. From marc.donner at gmail.com Tue Aug 1 19:22:17 2023 From: marc.donner at gmail.com (Marc Donner) Date: Tue, 1 Aug 2023 05:22:17 -0400 Subject: [TUHS] Cool talk on Unix and Sendmail history, by Eric Allman In-Reply-To: <8246.1690761540@cesium.clock.org> References: <8246.1690761540@cesium.clock.org> Message-ID: Nathaniel (Mr Mime) Borenstein came up with something (atomicmail?) that was intended to be more functional than raw text but safer than free execution of unknown code. I disremember the details. I don’t think it ever got traction. On Sun, Jul 30, 2023 at 7:59 PM Erik E. Fair wrote: > > Date: Mon, 31 Jul 2023 09:34:56 +1000 > From: George Michaelson > > [...] > > Execute on read is just awful. But, now we have HTML to track "they > read it" through URL fetch. > > And then the utterly disastrous: JavaScript. It should be *eliminated* > from the WWW as the gross security violation it is. > > "don't run software from strangers", > > Erik Fair > -- ===== nygeek.net mindthegapdialogs.com/home -------------- next part -------------- An HTML attachment was scrubbed... URL: From fair-tuhs at netbsd.org Tue Aug 1 20:58:44 2023 From: fair-tuhs at netbsd.org (Erik E. Fair) Date: Tue, 01 Aug 2023 03:58:44 -0700 Subject: [TUHS] Cool talk on Unix and Sendmail history, by Eric Allman In-Reply-To: References: <8246.1690761540@cesium.clock.org> Message-ID: <29602.1690887524@cesium.clock.org> Date: Tue, 1 Aug 2023 05:22:17 -0400 From: Marc Donner Nathaniel (Mr Mime) Borenstein came up with something (atomicmail?) that was intended to be more functional than raw text but safer than free execution of unknown code. I disremember the details. I don't think it ever got traction. You remember correctly. It got stomped by those of us in the IETF MIME working group with approximately the same forceful negative reaction as you've seen here to Mike Lesk's idea of instantly executed Unix commands in e-mail. I'm hardly innocent of this - while writing & operating the AppleLink/Internet e-mail gateway at Apple in the 1990s, I discovered that I could download the entire user directory from AppleLink (over 50k users: all Apple employees, Apple 3rd-party developers, Apple retail dealers - the whole "Apple Federation" at that time was on AppleLink), which included both usernames and "full name" fields, which could provide the basis for an AppleLink directory lookup service on the Internet. I figured it'd be easy to use FINGER & WHOIS as the protocol ports since the outputs of those are basically unstructured (unspecified) ASCII text, e.g. "finger fair at applelink.apple.com" would return a list of all usernames and full names matching "fair". I was writing in Perl because e-mail gatewaying is primarily about string handling, and it sucks to write in C for that. The best performing way to implement the text search was to use its eval() function with a regex constructed from the network protocol input. I tested it, and it worked great, but I bet you can guess where this is going - how to perfectly sanitize the search term inputs taken directly from the net so they don't become arbitrary Perl code? I never deployed it, partly because I couldn't convince myself I'd made the service completely secure, and partly as a privacy matter: finger (especially after the 1989 Morris Worm & the increasing amounts of e-mail spam) was not a service that sites were offering any longer because there were too many bad actors on the Internet, and it just wasn't a good idea to be as open & trusting as the ARPANET had been. I lament the passing of that culture from time to time. I think anyone with a modicum of experience in computer & systems security can instantly recognize the dangers in executable code transmitted unsolicited to unwary recipients and automatically executed without prior, explicit permission, and works to stop anything along those lines from becoming standard practice because, despite all the protestations that "it's run in a sandbox, it's safe!", the proponents can never prove their case beyond reasonable doubt. How many bugs were discovered in the "restricted shell" (rsh) over the years? Sometimes we fail to prevent such bad ideas from being implemented: JavaScript in HTML/HTTP is one such. What concerns me these days is how often JavaScript is showing up in text/html e-mail. At least visiting a website (URL) with a web browser is, to some degree, an act of volition. Particularly with MIME, Internet e-mail has to be parsed and presented (and which HTML parsers these days do not also include a JavaScript interpreter?), not merely spewed to a presumed-ASCII (OK, UTF-8) terminal. Even simple spew could be dangerous: who remembers "intelligent terminal" transmit-back codes and the mischief those caused? IIRC, the question we posed to Nathaniel was: "do we really want to enable letter bombs?" Some of us also remembered (and possibly referenced) the UNAbomber. Erik From leah at vuxu.org Tue Aug 1 21:38:55 2023 From: leah at vuxu.org (Leah Neukirchen) Date: Tue, 01 Aug 2023 13:38:55 +0200 Subject: [TUHS] shell escapes in utilities In-Reply-To: (ron minnich's message of "Mon, 31 Jul 2023 22:47:54 -0700") References: Message-ID: <87zg3b3sc0.fsf@vuxu.org> ron minnich writes: > I got to wondering, based on the sendmail discussions, how many shell > escapes have appeared over the years? > > uucp > sendmail > xdvi : "The "allowShell" option enables the shell escape in PostScript specials" >From the top of my head, where it can be disabled: ghostscript (see above) tex (write18) ed/ex/vi nethack -- Leah Neukirchen https://leahneukirchen.org/ From g.branden.robinson at gmail.com Tue Aug 1 22:31:39 2023 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Tue, 1 Aug 2023 07:31:39 -0500 Subject: [TUHS] shell escapes in utilities In-Reply-To: <87zg3b3sc0.fsf@vuxu.org> References: <87zg3b3sc0.fsf@vuxu.org> Message-ID: <20230801123139.6splbkt4n7c75wu7@illithid> At 2023-08-01T13:38:55+0200, Leah Neukirchen wrote: > > I got to wondering, based on the sendmail discussions, how many > > shell escapes have appeared over the years? > > > > uucp > > sendmail > > xdvi : "The "allowShell" option enables the shell escape in PostScript specials" > > From the top of my head, where it can be disabled: > > ghostscript (see above) > tex (write18) > ed/ex/vi > nethack And the *roffs of course. nroff/troff/groff, with the `sy` (system(3)) and `pi` (popen(3)) requests. pic(1) as well ("sh"). groff has, since version 1.12 in 1999, disabled these features by default; the '-U' ("unsafe") command-line option reënables them. It added some additional unsafe requests for arbitrary stream I/O, `open`, `opena` (open with append), and `pso` (`so` for pipeline output). I recently learned of a limitation in the way AT&T and GNU *roffs, at least, construct the string `sy` passes passes to system(3), which makes certain things impossible. Unfortunately it forecloses useful applications, not any particularly malicious ones. There is a problem with trying to embed true newlines into the arguments of a `sy` request. The C++ function that GNU troff uses to assemble the command string (character by character) _does not recognize C/C++ string literal escape sequences_. This means that you _cannot_ embed "\n" in `sy`'s arguments and have it survive, as a newline character, into the command string passed to the standard C library's system(3) function. ("A\nB" gets encoded as 'A', '\\', 'n', 'B', not 'A', '\n', 'B'.) Unfortunately, this appears to be AT&T troff-compatible behavior. But it means that you _cannot_ portably construct multi-line replacement text for sed's 's' command. (Other sed commands like 'a', 'c', and 'i' will be similarly affected.) See Savannah #64071. AT&T troff obviously wasn't written in C++, so this would appear to be an instance of independent oversight. (Where James Clark had gripes about AT&T troff behavior, he left them in source code comments.) I aim to fix this. If I can write an arbitrary shell command, then I darn well ought to be able to embed an arbitrary sed script in that shell command (without needing a GNU sed extension to embed newlines). 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 fariborz.t at gmail.com Wed Aug 2 00:29:12 2023 From: fariborz.t at gmail.com (Skip Tavakkolian) Date: Tue, 1 Aug 2023 07:29:12 -0700 Subject: [TUHS] shell escapes in utilities In-Reply-To: References: Message-ID: Looking at sources on TUHS, it looks like ed had it as early as V5: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/source/s1/ed1.s On Mon, Jul 31, 2023, 10:48 PM ron minnich wrote: > I got to wondering, based on the sendmail discussions, how many shell > escapes have appeared over the years? > > uucp > sendmail > xdvi : "The "allowShell" option enables the shell escape in PostScript > specials" > > There must be a lot of them, however. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Wed Aug 2 01:30:41 2023 From: rminnich at gmail.com (ron minnich) Date: Tue, 1 Aug 2023 08:30:41 -0700 Subject: [TUHS] shell escapes in utilities In-Reply-To: References: Message-ID: I'm ok with things like ed, I'm more thinking of situations where people would (e.g.) use xdvi to view a file, and Bad Things Happened. I don't think ed counts, unless we're that worried about scripts. at least for me, the xdvi thing was a real shock. On Tue, Aug 1, 2023 at 7:29 AM Skip Tavakkolian wrote: > > Looking at sources on TUHS, it looks like ed had it as early as V5: > https://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/source/s1/ed1.s > > On Mon, Jul 31, 2023, 10:48 PM ron minnich wrote: >> >> I got to wondering, based on the sendmail discussions, how many shell >> escapes have appeared over the years? >> >> uucp >> sendmail >> xdvi : "The "allowShell" option enables the shell escape in PostScript specials" >> >> There must be a lot of them, however. From phil at ultimate.com Wed Aug 2 01:36:05 2023 From: phil at ultimate.com (Phil Budne) Date: Tue, 01 Aug 2023 11:36:05 -0400 Subject: [TUHS] shell escapes in utilities In-Reply-To: References: Message-ID: <202308011536.371Fa5mA057553@ultimate.com> Both more and less! From tuhs at tuhs.org Wed Aug 2 01:37:55 2023 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Tue, 1 Aug 2023 10:37:55 -0500 Subject: [TUHS] shell escapes in utilities In-Reply-To: References: Message-ID: On 8/1/23 12:47 AM, ron minnich wrote: > I got to wondering, based on the sendmail discussions, how many shell > escapes have appeared over the years? Please clarify what you mean by "shell escape". I think that there are a LOT of programs that can shell out and run arbitrary commands while in the program. Sudo also uses this phrasing for references to things like this. Then there are abuses of shell escapes used as vulnerability / vectors to attack things. Grant. . . . From clemc at ccc.com Wed Aug 2 01:37:41 2023 From: clemc at ccc.com (Clem Cole) Date: Tue, 1 Aug 2023 11:37:41 -0400 Subject: [TUHS] shell escapes in utilities In-Reply-To: References: Message-ID: Ron I never understood why sendmail needed it. [Actually I never really understand sendmail's need but that's another discussion and discussion I've had with Ertc over the years]. But shell escape were pretty typical, until Kulp's ^Z job control stuff and/or real window managers - it would have sucked not to have had them. Off the top of my head: - any editor (text or graphical) - things that controlled the screen like more(1) would have wanted to support something like this - programs that produced graphical output -- from *roff/tex and the like, to many/most of the CAD programs, or even Ghostscript I think. You might want to dump out and suck back in something processed from another program, and the 'pipeline' was not always the easy/right way to do that. Classic example of calling on the PS/EPS tools from inside of troff. This is why tools like xdvi and the like supported it. - long-running games where you did not want to lose your session - many things that supported remote job entry/execution - which was really common in the old days [hence UUCP, the PWB RJE tools, rsh and the like]. IICR there was a couple of versions of telnet/supdup that could do it. Clem ᐧ ᐧ On Tue, Aug 1, 2023 at 1:48 AM ron minnich wrote: > I got to wondering, based on the sendmail discussions, how many shell > escapes have appeared over the years? > > uucp > sendmail > xdvi : "The "allowShell" option enables the shell escape in PostScript > specials" > > There must be a lot of them, however. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Wed Aug 2 04:43:07 2023 From: ron at ronnatalie.com (Ron Natalie) Date: Tue, 01 Aug 2023 18:43:07 +0000 Subject: [TUHS] shell escapes in utilities In-Reply-To: References: Message-ID: The Sendmail WIZ bug was but one of the security disasters from shell escapes. I remember IBM sending me an early RS/6000. Booted the thing up but had no clue what root or any other password was. So, I set to work hacking on it. Now this thing had a physical key on the front. Off, On, and a Wrench symbol. OK, let’s try the wrench. Boots up some sort of maintenance program. After playing around with it a bit I find a help option. This starts up a paginator (more or pg or something). Sure enough you can shell escape otu of that. Instant root shell. Now it’s trivial to change the root password and reboot in normal mode. Yep, the need for shell escapes largely went away with windowing and job control. From nikke.karlsson at gmail.com Wed Aug 2 04:55:41 2023 From: nikke.karlsson at gmail.com (Niklas Karlsson) Date: Tue, 1 Aug 2023 20:55:41 +0200 Subject: [TUHS] shell escapes in utilities In-Reply-To: References: Message-ID: Den tis 1 aug. 2023 kl 20:43 skrev Ron Natalie : > > I remember IBM sending me an early RS/6000. Booted the > thing up but had no clue what root or any other password was. > So, I set to work hacking on it. Now this thing had a physical key on > the front. Off, On, and a Wrench symbol. OK, let’s try the wrench. > Boots up some sort of maintenance program. After playing around with > it a bit I find a help option. This starts up a paginator (more or pg > or something). Sure enough you can shell escape otu of that. > Instant root shell. Now it’s trivial to change the root password and > reboot in normal mode. > To be fair, local root exploits are a bit of a different animal from remote ones. Even now, if you have physical access to your average *nix box, you can likely gain root. Sure, there are ways and means of preventing that, but IME it's really only people doing really secret spook stuff that bother with those. Even engineering outfits with big secrets to protect usually don't bother. What you did with that RS/6000 sounds roughly equivalent to booting a modern Linux box in single-user mode, where you can also set the root password to anything you like. Niklas -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Wed Aug 2 06:33:09 2023 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 2 Aug 2023 06:33:09 +1000 (EST) Subject: [TUHS] shell escapes in utilities In-Reply-To: <87zg3b3sc0.fsf@vuxu.org> References: <87zg3b3sc0.fsf@vuxu.org> Message-ID: Not quite a Shell escape but possibly just as dangerous: EX/VI had/has the ability to embed EX commands within a file to be run when opened e.g. "se ts=4 sw=4" etc; no doubt EMACS has the same "feature". It would also recognise the EXINIT environment variable. -- Dave From arnold at skeeve.com Wed Aug 2 06:40:06 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 01 Aug 2023 14:40:06 -0600 Subject: [TUHS] shell escapes in utilities In-Reply-To: References: <87zg3b3sc0.fsf@vuxu.org> Message-ID: <202308012040.371Ke6To027489@freefriends.org> Dave Horsfall wrote: > Not quite a Shell escape but possibly just as dangerous: EX/VI had/has the > ability to embed EX commands within a file to be run when opened e.g. "se > ts=4 sw=4" etc; no doubt EMACS has the same "feature". > > It would also recognise the EXINIT environment variable. > > -- Dave These are called "modelines". In modern vim they have to be in the first 4 or last 4 lines of a file (or so) and vim is careful about what it will run from a modeline. I *think* other vi versions have an option to enable modelines in the .exrc file, which is off by default, but I no longer remember the details. Arnold From steffen at sdaoden.eu Wed Aug 2 06:48:00 2023 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 01 Aug 2023 22:48:00 +0200 Subject: [TUHS] shell escapes in utilities In-Reply-To: References: Message-ID: <20230801204800.wvlfp%steffen@sdaoden.eu> Niklas Karlsson wrote in : |Den tis 1 aug. 2023 kl 20:43 skrev Ron Natalie : |> I remember IBM sending me an early RS/6000. Booted the |> thing up but had no clue what root or any other password was. |> So, I set to work hacking on it. Now this thing had a physical key on |> the front. Off, On, and a Wrench symbol. OK, let’s try the wrench. |> Boots up some sort of maintenance program. After playing around with |> it a bit I find a help option. This starts up a paginator (more or pg |> or something). Sure enough you can shell escape otu of that. |> Instant root shell. Now it’s trivial to change the root password and |> reboot in normal mode. | |To be fair, local root exploits are a bit of a different animal from |remote ones. Even now, if you have physical access to your average *nix |box, you can likely gain root. Sure, there are ways and means of I find this a provocative statement even in the silly saison. I would assume that despite EFI firmware snooping key presses when entering the disk key on cold boot, or other sort of nifty spying (the famous USB sticks that "turn into keyboards and send key presses" (as root?) cross my mind), i would think that you have a hard time as a normal user to become root. On this box; even though you are not further separated via "ip netns exec .. unshare .." etc.; some SETUID programs exist $ find /sbin /bin /usr/sbin /usr/bin -perm /4000 /sbin/unix_chkpwd /bin/ping /bin/umount /bin/mount /bin/ksu /usr/bin/fusermount /usr/bin/crontab /usr/bin/doas /usr/bin/slock /usr/bin/traceroute /usr/bin/newuidmap /usr/bin/newgidmap /usr/bin/passwd /usr/bin/newgrp /usr/bin/expiry /usr/bin/chsh /usr/bin/chfn /usr/bin/chage /usr/bin/su |preventing that, but IME it's really only people doing really secret |spook stuff that bother with those. Even engineering outfits with big |secrets to protect usually don't bother. | |What you did with that RS/6000 sounds roughly equivalent to booting a |modern Linux box in single-user mode, where you can also set the root |password to anything you like. Not here. |Niklas --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 ron at ronnatalie.com Wed Aug 2 07:11:24 2023 From: ron at ronnatalie.com (Ron Natalie) Date: Tue, 01 Aug 2023 21:11:24 +0000 Subject: [TUHS] shell escapes in utilities In-Reply-To: <20230801204800.wvlfp%steffen@sdaoden.eu> References: <20230801204800.wvlfp%steffen@sdaoden.eu> Message-ID: Even without shell escapes there are fun and cames with abusing setuid (but accessible) programs. Things like opening all the available file descriptors, closing stdin/out/err before invocation, doing things to overrun buffers, etc… From nikke.karlsson at gmail.com Wed Aug 2 07:13:09 2023 From: nikke.karlsson at gmail.com (Niklas Karlsson) Date: Tue, 1 Aug 2023 23:13:09 +0200 Subject: [TUHS] shell escapes in utilities In-Reply-To: <20230801204800.wvlfp%steffen@sdaoden.eu> References: <20230801204800.wvlfp%steffen@sdaoden.eu> Message-ID: Den tis 1 aug. 2023 kl 22:48 skrev Steffen Nurpmeso : > Niklas Karlsson wrote in > | > |To be fair, local root exploits are a bit of a different animal from > |remote ones. Even now, if you have physical access to your average *nix > |box, you can likely gain root. Sure, there are ways and means of > > I find this a provocative statement even in the silly saison. > I would assume that despite EFI firmware snooping key presses when > entering the disk key on cold boot, or other sort of nifty spying > (the famous USB sticks that "turn into keyboards and send key > presses" (as root?) cross my mind), i would think that you have > a hard time as a normal user to become root. On this box; even > though you are not further separated via "ip netns exec .. unshare > .." etc.; some SETUID programs exist > > [...] I'm sorry, I'm having trouble parsing what you're saying here, other than that a physically present user would have difficulty becoming root. But yes, obviously an encrypted disk would present a major obstacle. > > |preventing that, but IME it's really only people doing really secret > |spook stuff that bother with those. Even engineering outfits with big > |secrets to protect usually don't bother. > | > |What you did with that RS/6000 sounds roughly equivalent to booting a > |modern Linux box in single-user mode, where you can also set the root > |password to anything you like. > > Not here. > Very well, then your installation is a lot more ambitious than most I've come across. Niklas -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Wed Aug 2 07:19:52 2023 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 2 Aug 2023 07:19:52 +1000 (EST) Subject: [TUHS] shell escapes in utilities In-Reply-To: References: Message-ID: On Tue, 1 Aug 2023, Niklas Karlsson wrote: > What you did with that RS/6000 sounds roughly equivalent to booting a > modern Linux box in single-user mode, where you can also set the root > password to anything you like. Not just Penguin boxes... -- Dave From steffen at sdaoden.eu Wed Aug 2 07:52:44 2023 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 01 Aug 2023 23:52:44 +0200 Subject: [TUHS] shell escapes in utilities In-Reply-To: References: <20230801204800.wvlfp%steffen@sdaoden.eu> Message-ID: <20230801215244.WTv6e%steffen@sdaoden.eu> Ron Natalie wrote in : |Even without shell escapes there are fun and cames with abusing setuid |(but accessible) programs. |Things like opening all the available file descriptors, closing |stdin/out/err before invocation, doing things to overrun buffers, etc… Of course. Even experienced programmers still make errors, or kernel bugs introduce problems which even such a programmer did not take into account. (Like that isatty(3) uses "a" IOCTL, and a Linux bug caused local root exploit of any SETUID program that uses C stdio's stdout (testing ISO C's "whether output shall be line or fully buffered"), as seen earlier this year i think.) This is for my convenience, one could "overlayfs them away". ..And my user account has a number of capabilities, starting X, accessing audio and video, starting QEMU instances, changing files under /x/{src,iso,os,doc} etc. $ groups audio video cdrom input kvm _icmp users steffen ports doc backups shared media vm code And brute forcing/attacking the encfs ~/.sic where keys are stored to access more one could. At least, via the ACPI that Linux thankfully supports on this box, all (other) encfs are unloaded, and (all) X displays are locked (via slock, requiring password to unlock) when the display is closed. And all keys are removed from all SSH agents, even though this is hard because even root cannot simply signal this as would be possible with gnupg based agents. Ie. act 'pkill -HUP gpg-agent >/dev/null 2>&1 &' inc vs for a in /tmp/ssh-*/agent.*; do [ -e "$a" ] || continue act "SSH_AUTH_SOCK=\"$a\" ssh-add -D /dev/null 2>&1 &" inc 1 2 done which prevents personal /tmp directories (or requires work). (Asynchronousity of signals hopefully no attack vector / problem.) No healing in sight for this. On the server there is only # find /sbin /bin /usr/sbin /usr/bin -perm /4000 /bin/bbsuid but most daemons will not even be able to find that, or much in their /dev/ etc. Like my local web browser, which is, except for armed perpetrators, the far biggest attack surface here. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From dave at horsfall.org Wed Aug 2 10:37:20 2023 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 2 Aug 2023 10:37:20 +1000 (EST) Subject: [TUHS] Cool talk on Unix and Sendmail history, by Eric Allman In-Reply-To: <29602.1690887524@cesium.clock.org> References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> Message-ID: On Tue, 1 Aug 2023, Erik E. Fair wrote: > Even simple spew could be dangerous: who remembers "intelligent > terminal" transmit-back codes and the mischief those caused? ASCII bombs were fairly popular in the old MS-DOS BBS days (format the disk, anyone?), and it was possible over packet radio too (sort of a BBS via Amateur i.e. "ham" radio). -- Dave (vk2kfu) From tuhs at tuhs.org Wed Aug 2 12:59:06 2023 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Tue, 1 Aug 2023 21:59:06 -0500 Subject: [TUHS] shell escapes in utilities In-Reply-To: References: Message-ID: On 8/1/23 1:43 PM, Ron Natalie wrote: > Yep, the need for shell escapes largely went away with windowing and job > control. Eh ... I don't know about that. I routinely use :'<,'>!sort or some similar external filter program on lines in the file that I'm working with. :'a,'b!base64 -d Maybe I'm in the minority in doing such things. My understanding is that those require shell escapes to function. Grant. . . . From tuhs at tuhs.org Wed Aug 2 13:01:05 2023 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Tue, 1 Aug 2023 22:01:05 -0500 Subject: [TUHS] shell escapes in utilities In-Reply-To: References: Message-ID: <3132b52a-d490-4a8e-1c53-9f504209a54f@tnetconsulting.net> On 8/1/23 1:55 PM, Niklas Karlsson wrote: > What you did with that RS/6000 sounds roughly equivalent to booting > a modern Linux box in single-user mode, where you can also set the > root password to anything you like. I think that's *HIGHLY* dependent on the distribution. Some systems make it harder than others to get into single user mode. I feel like "sulogin" comes into play here. The thing that I used to do is append "init=/bin/sh" to the GRUB boot line via the transient editor. Drops you at a shell and bypasses almost all of the startup scripts. Obviously there are ways to secure against this. But, again, it depends on the distro. Grant. . . . From nikke.karlsson at gmail.com Wed Aug 2 13:42:49 2023 From: nikke.karlsson at gmail.com (Niklas Karlsson) Date: Wed, 2 Aug 2023 05:42:49 +0200 Subject: [TUHS] shell escapes in utilities In-Reply-To: <3132b52a-d490-4a8e-1c53-9f504209a54f@tnetconsulting.net> References: <3132b52a-d490-4a8e-1c53-9f504209a54f@tnetconsulting.net> Message-ID: Den ons 2 aug. 2023 kl 05:01 skrev Grant Taylor via TUHS : > On 8/1/23 1:55 PM, Niklas Karlsson wrote: > > What you did with that RS/6000 sounds roughly equivalent to booting > > a modern Linux box in single-user mode, where you can also set the > > root password to anything you like. > > I think that's *HIGHLY* dependent on the distribution. Some systems > make it harder than others to get into single user mode. I feel like > "sulogin" comes into play here. > > The thing that I used to do is append "init=/bin/sh" to the GRUB boot > line via the transient editor. Drops you at a shell and bypasses almost > all of the startup scripts. Obviously there are ways to secure against > this. But, again, it depends on the distro. > Sure. Like I said, there are ways and means to avoid this. Not going to argue against that. Niklas -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Wed Aug 2 20:49:29 2023 From: rich.salz at gmail.com (Rich Salz) Date: Wed, 2 Aug 2023 06:49:29 -0400 Subject: [TUHS] shell escapes in utilities In-Reply-To: References: Message-ID: > I routinely use :'<,'>!sort or some similar external filter program on > lines in the file that I'm working with. > I don't think of that as a shell escape the way we seem to be using it. Piping to a sub process is not the same as spawning and interactive subshell. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Aug 3 00:20:54 2023 From: clemc at ccc.com (Clem Cole) Date: Wed, 2 Aug 2023 10:20:54 -0400 Subject: [TUHS] shell escapes in utilities In-Reply-To: References: Message-ID: On Tue, Aug 1, 2023 at 10:59 PM Grant Taylor via TUHS wrote: > I routinely use :'<,'>!sort or some similar external filter program on > lines in the file that I'm working with. > No doubt. Pretty much the intended use. I've been doing that since I first learned ed(1) and discovered I could do the same. It always seemed natural and handy [sort(1), tr(1), and fmt(1) are probably the filters I use the most over the years -- as I pretty much have the switches for the same burned into the ROMs in my fingers]. If I had grown up with GUI's, I suspect I might have used cut/paste in some manner to do the same thing (for me, a less natural sequence). As Ron points out, in using more(1) on the RS/6000 in maintenance mode, shell escape on a multi-tasking system opens up some interesting security paths/unintended side effects. Security is thought to get right. So many places where good ideas can bite you when abused. It does not make it a bad idea. But you need to consider other uses that might not behave the way you planned. This brings us back to Roz's warning to Mike: "*Always Watching.*" [image: AlwaysWatching.png] ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: AlwaysWatching.png Type: image/png Size: 409883 bytes Desc: not available URL: From tuhs at tuhs.org Thu Aug 3 00:49:08 2023 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Wed, 2 Aug 2023 09:49:08 -0500 Subject: [TUHS] shell escapes in utilities In-Reply-To: References: Message-ID: On 8/2/23 5:49 AM, Rich Salz wrote: > I don't think of that as a shell escape the way we seem to be using it. > Piping to a sub process is not the same as spawning and interactive > subshell. That's why I asked for clarification of what "shell escape" is in the context of this discussion. I can tell you from a sudo point of view, having vim et al. use :'<,'>!sort is considered a shell escape in that the authorized program (/path/to/)vim is executing a sub-process. It is possible to allow use of vim while preventing it from calling external processes via sudo. I agree that :'<,'>!sort isn't something like breaking out of something intended to contain you. -- Grant. . . . From ron at ronnatalie.com Thu Aug 3 00:52:27 2023 From: ron at ronnatalie.com (Ron Natalie) Date: Wed, 02 Aug 2023 14:52:27 +0000 Subject: [TUHS] Cool talk on Unix and Sendmail history, by Eric Allman In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> Message-ID: ASCII Bombs? Like my Letter Bomb Transport Protocol (LBTP)? https://groups.google.com/g/net.followup/c/OJBALbzTq4w/m/LoxMnbz0bwMJ It seems to have lost something in the formatting (the leading spaces were all removed). ------ Original Message ------ >From "Dave Horsfall" To "The Eunuchs Hysterical Society" Date 8/1/23, 8:37:20 PM Subject [TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman >On Tue, 1 Aug 2023, Erik E. Fair wrote: > >> Even simple spew could be dangerous: who remembers "intelligent >> terminal" transmit-back codes and the mischief those caused? > >ASCII bombs were fairly popular in the old MS-DOS BBS days (format the >disk, anyone?), and it was possible over packet radio too (sort of a BBS >via Amateur i.e. "ham" radio). > >-- Dave (vk2kfu) From tuhs at tuhs.org Thu Aug 3 07:14:41 2023 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Wed, 2 Aug 2023 16:14:41 -0500 Subject: [TUHS] Cool talk on Unix and Sendmail history, by Eric Allman In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> Message-ID: On 8/2/23 9:52 AM, Ron Natalie wrote: > ASCII Bombs?   Like my Letter Bomb Transport Protocol (LBTP)? > > https://groups.google.com/g/net.followup/c/OJBALbzTq4w/m/LoxMnbz0bwMJ ~chuckle~ > It seems to have lost something in the formatting (the leading spaces > were all removed). Ya.... People think I'm weird for not liking languages that use white space as structural definition. Frequently those people have not experienced such a failure as what has happened to your ASCII Bomb. Grant. . . . From tuhs at tuhs.org Thu Aug 3 08:20:09 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 02 Aug 2023 22:20:09 +0000 Subject: [TUHS] Cool talk on Unix and Sendmail history, by Eric Allman In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> Message-ID: > People think I'm weird for not liking languages that use white space as > structural definition. > > Grant. . . . This is my chief gripe with Python, although on the flip side Python isn't the right language anyway for most scenarios where I use whitespace/indentation to imply structure the language itself can't articulate. It's meant for mainly functional programming as I understand it so the structure does enforce some stylistic practices conducive to good functional programming. Still a shame to force a particular style approach by default rather than just strongly suggest it. What strikes me particularly odd about the Python case is that its not like that space-sensitivity evolved out of the same line of reasoning as the compulsory spacing in FORTRAN, COBOL, etc. It seems mainly to be a way to operate without code blocks, with the "blocks" being implied by indentation rather than braces, parens, or some other delimiter. In UNIX of course we have our own little variation on this problem with make(1) and the need to tab out the rule definition. I seem to recall reading somewhere (perhaps Doug's McIlroy's UPM excerpts) that that Stu Feldman considered undoing that but there were already users who that would've caused trouble for, so make's early, entrenched adoption stymied attempts at the time to rectify this. Anyone with better details feel free to correct me. - Matt G. P.S. This answer can be off list or spin off a separate thread for make junkies, but did any AT&T or BSD revision of make(1) support rule names coming from variables rather than explicitly entered? For instance: $(BIN): $(OBJS) $(CC) $(LDFLAGS) -o $(BIN) $(OBJS) $(LIBS) I used to use this in makefiles but at some point, I think with one of the BSDs, it balked at the idea of a variable rule name and so it fell out of my practice in trying to avoid GNUisms. It's been a while but I feel like I ran through and tried this on V7, System III, and PDP-11 System V and all of them were unhappy about that construct. I can try and get on the LCMs 3B400 later to see what SVR3 does. I don't remember which of the BSDs (if not multiple) I ran into that issue on initially, but I can't imagine one of the major streams would work that in without the other two wanting to copy their notes. Maybe an alternative question is if folks are aware of make implementations besides GNU that *do* support that sort of thing. From imp at bsdimp.com Thu Aug 3 08:37:50 2023 From: imp at bsdimp.com (Warner Losh) Date: Wed, 2 Aug 2023 16:37:50 -0600 Subject: [TUHS] Cool talk on Unix and Sendmail history, by Eric Allman In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> Message-ID: On Wed, Aug 2, 2023 at 4:20 PM segaloco via TUHS wrote: > > People think I'm weird for not liking languages that use white space as > > structural definition. > > > > Grant. . . . > > This is my chief gripe with Python, although on the flip side Python isn't > the right language anyway for most scenarios where I use > whitespace/indentation to imply structure the language itself can't > articulate. It's meant for mainly functional programming as I understand > it so the structure does enforce some stylistic practices conducive to good > functional programming. Still a shame to force a particular style approach > by default rather than just strongly suggest it. > > What strikes me particularly odd about the Python case is that its not > like that space-sensitivity evolved out of the same line of reasoning as > the compulsory spacing in FORTRAN, COBOL, etc. It seems mainly to be a way > to operate without code blocks, with the "blocks" being implied by > indentation rather than braces, parens, or some other delimiter. > > In UNIX of course we have our own little variation on this problem with > make(1) and the need to tab out the rule definition. I seem to recall > reading somewhere (perhaps Doug's McIlroy's UPM excerpts) that that Stu > Feldman considered undoing that but there were already users who that > would've caused trouble for, so make's early, entrenched adoption stymied > attempts at the time to rectify this. Anyone with better details feel free > to correct me. > > - Matt G. > > P.S. This answer can be off list or spin off a separate thread for make > junkies, but did any AT&T or BSD revision of make(1) support rule names > coming from variables rather than explicitly entered? > > For instance: > > $(BIN): $(OBJS) > $(CC) $(LDFLAGS) -o $(BIN) $(OBJS) $(LIBS) > > I used to use this in makefiles but at some point, I think with one of the > BSDs, it balked at the idea of a variable rule name and so it fell out of > my practice in trying to avoid GNUisms. > BSD has long supported PROG=cat .include to have it deal with all the details. Of course, FreeBSD's is more complex than that, because nothing is ever simple. And I think even V7 make supported what you described, as well as implicit rules for compiling .c into a .o or into a binary. > It's been a while but I feel like I ran through and tried this on V7, > System III, and PDP-11 System V and all of them were unhappy about that > construct. I can try and get on the LCMs 3B400 later to see what SVR3 > does. I don't remember which of the BSDs (if not multiple) I ran into that > issue on initially, but I can't imagine one of the major streams would work > that in without the other two wanting to copy their notes. > They'd likely be happier if you used {} instead of () for variable expansion. > Maybe an alternative question is if folks are aware of make > implementations besides GNU that *do* support that sort of thing. > The NetBSD/FreeBSD pmake does, and has since before NetBSD/FreeBSD were a thing (at least to 4.2BSD, and I think even further back since I'm nearly positive V7 supported it, though I've not cranked up a V7 VM to chek). Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Thu Aug 3 09:33:22 2023 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 3 Aug 2023 09:33:22 +1000 (EST) Subject: [TUHS] Cool talk on Unix and Sendmail history, by Eric Allman In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> Message-ID: On Wed, 2 Aug 2023, Ron Natalie wrote: > ASCII Bombs? Like my Letter Bomb Transport Protocol (LBTP)? Some "smart" terminals could have their function keys programmed by escape characters, then subsequently invoked... > https://groups.google.com/g/net.followup/c/OJBALbzTq4w/m/LoxMnbz0bwMJ > > It seems to have lost something in the formatting (the leading spaces > were all removed). Aha... Much better with a bit of imagination :-) Which reminds me: the reason why I refuse to use Python is that white space is part of the syntax; the last language I used with that property was FORTRAN (and I also had to learn COBOL as part of my CS degree, but fortunately never had to use it). -- Dave From rich.salz at gmail.com Thu Aug 3 09:49:18 2023 From: rich.salz at gmail.com (Rich Salz) Date: Wed, 2 Aug 2023 19:49:18 -0400 Subject: [TUHS] Cool talk on Unix and Sendmail history, by Eric Allman In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> Message-ID: > [Python is] meant for mainly functional programming as I understand it Not true. It has some neat functional features (list comprehensions) but that's not really its intent. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Thu Aug 3 10:01:16 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 03 Aug 2023 00:01:16 +0000 Subject: [TUHS] Make(1) Historical Behavior (was Cool talk on Unix and Sendmail history, by Eric Allman) Message-ID: <_KiSAucAzsj36hyLVdRHwFxz29dzdQpEBVnubkrKkP8_dMy0gmD2VQ3Bi9c8W5zq1v91VouPvLz-6t0yBJtNGYNUw2mGV7crtEAZwtBthus=@protonmail.com> > And I think even V7 make supported what you described, as well as implicit rules for compiling .c into a .o or into a binary. > > Warner Losh You're right, I just tried it out. Been avoiding that pattern for years because I swear some make implementation I used at one point was very unhappy with that, but if V7 does it, then whatever implementation that was is probably not what I want to be using anyway. Also shows how little I've used specifics of BSD, I've never made a Makefile using bsd.prog.mk, although I have this desire for a write-once-build-everywhere Makefile that the preponderance of build systems that generate them imply is an exercise in futility... On that note, one quirk I've found with the implicit .c.o rule on older UNIX, just tested on V7 and System III, is that they render: cc -c $< rather than cc -c -o $@ $< If you have an object list with objects in several different directories, it spits them all out in the CWD, causing problems if you have similarly named files in multiple directories, and then outright failing on the final compilation if it's something like $(CC) -o $(BIN) $(OBJS) because $(OBJS) is a string of object pathnames with the full nested path, not just the resulting *.o files. Granted, I could be anti-patterning here for all I know, I haven't worked closely with a whole lot of Make-based projects that aren't my own. Maybe I just haven't read these darn papers I'm always hunting down enough. - Matt G. From lm at mcvoy.com Thu Aug 3 10:51:06 2023 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 2 Aug 2023 17:51:06 -0700 Subject: [TUHS] python In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> Message-ID: <20230803005106.GA12652@mcvoy.com> On Wed, Aug 02, 2023 at 07:49:18PM -0400, Rich Salz wrote: > > [Python is] meant for mainly functional programming as I understand it > > Not true. It has some neat functional features (list comprehensions) but > that's not really its intent. I've really tried to like python but any language that doesn't has printf as builtin is not for me. Yes, I know about their library printf but it is weird. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From lm at mcvoy.com Thu Aug 3 10:55:46 2023 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 2 Aug 2023 17:55:46 -0700 Subject: [TUHS] Make(1) Historical Behavior (was Cool talk on Unix and Sendmail history, by Eric Allman) In-Reply-To: <_KiSAucAzsj36hyLVdRHwFxz29dzdQpEBVnubkrKkP8_dMy0gmD2VQ3Bi9c8W5zq1v91VouPvLz-6t0yBJtNGYNUw2mGV7crtEAZwtBthus=@protonmail.com> References: <_KiSAucAzsj36hyLVdRHwFxz29dzdQpEBVnubkrKkP8_dMy0gmD2VQ3Bi9c8W5zq1v91VouPvLz-6t0yBJtNGYNUw2mGV7crtEAZwtBthus=@protonmail.com> Message-ID: <20230803005546.GB12652@mcvoy.com> On Thu, Aug 03, 2023 at 12:01:16AM +0000, segaloco via TUHS wrote: > > And I think even V7 make supported what you described, as well as implicit rules for compiling .c into a .o or into a binary. > > > > Warner Losh > > You're right, I just tried it out. Been avoiding that pattern for years because I swear some make implementation I used at one point was very unhappy with that, but if V7 does it, then whatever implementation that was is probably not what I want to be using anyway. For years, I carried around some early version of make source. Maybe Sys III make? It wasn't fancy but it behaved how I understood it should behave and all the other makes, ESPECIALLY gnu make, were adding features like crazy and, while cool, they were not portable. I really like stuff that Just Works (tm) and really early make felt like that. I'm a dinosaur, there was a saying at my company "Oh, that was invented after 1980, Larry won't let you use that" which was mostly correct but I let you use stuff like mmap(). Also not that portable but oh so useful when it worked. --lm From ggm at algebras.org Thu Aug 3 11:20:53 2023 From: ggm at algebras.org (George Michaelson) Date: Thu, 3 Aug 2023 11:20:53 +1000 Subject: [TUHS] python In-Reply-To: <20230803005106.GA12652@mcvoy.com> References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> Message-ID: Python has limited support for map/reduce patterns, and cannot implement lazy eval. It's functional support is no different to any classical language with an ability to apply a function over data and you can curry to your hearts content if you can define functions over functions (as arguments) Guido is on record as saying he didn't aim it as an FP language. I wouldn't cast him an FP hater, I think thats a silly concept anyway. I tried to learn a real FP language. It's hard to think in new ways. I wish I'd started sooner because I do believe the stories about the upside of investing in strong types (which are not unique to FP but are a mainstay of most of the FP which have succeeded in breaking through) The resurgence of chatter about Common LISP says something to me. I'm not sure what, possibly "all those LISP-like turn out not to be as good as they said" but there's also a resurgence in OCAML in the same places. I think the fusion of UNIX and FP was sort of a road not taken. Yes, there's lots of LISP and GHC. No, it's really an ecosystem "on top" and there are some grumpy edges to coding in FP to deploy on UNIX. Maybe it's no worse a fit than "containers" and after all, we're in Kubernetes because of Plan9, right? G From clemc at ccc.com Thu Aug 3 12:07:00 2023 From: clemc at ccc.com (Clem Cole) Date: Wed, 2 Aug 2023 22:07:00 -0400 Subject: [TUHS] python In-Reply-To: <20230803005106.GA12652@mcvoy.com> References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> Message-ID: IMO (Like Larry) no printf stinks. But the real killer for my sustain for Python is the use white space and being typeless. My daughter loves it for her cloud development and we argue a bit. But it was the first language she really mastered in college and she never took a competitive languages course so I’m not so sure really had experienced much beyond it for real programs. Maybe I’m just an old fart but between C, Go and Rust I’m pretty good. I do write scripts in Bourne shell and or awk truth be known. On Wed, Aug 2, 2023 at 8:51 PM Larry McVoy wrote: > On Wed, Aug 02, 2023 at 07:49:18PM -0400, Rich Salz wrote: > > > [Python is] meant for mainly functional programming as I understand it > > > > Not true. It has some neat functional features (list comprehensions) but > > that's not really its intent. > > I've really tried to like python but any language that doesn't has printf > as builtin is not for me. Yes, I know about their library printf but it > is weird. > -- > --- > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Thu Aug 3 12:21:31 2023 From: tuhs at tuhs.org (Pete Wright via TUHS) Date: Wed, 2 Aug 2023 19:21:31 -0700 Subject: [TUHS] python In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> Message-ID: <2f77b26f-206c-6a80-90b3-b769a9f0f32d@nomadlogic.org> On 8/2/23 19:07, Clem Cole wrote: > IMO (Like Larry) no printf stinks.  But the real killer for my sustain > for Python is the use white space and being typeless.   My daughter > loves it for her cloud development and we argue a bit.  But it was the > first language she really mastered in college and she never took a > competitive languages course so I’m not so sure really had experienced > much beyond it for real programs.   Maybe I’m just an old fart but > between C, Go and Rust I’m pretty good.  I do write scripts in Bourne > shell and or awk truth be known. > as one of those "new kids" who finds python to be a decent enough language for my cloud development tasks - my main observation is that having the python REPL was an eye opener. after fighting the learning curve of C and Java the interactivity of the whole thing was a revelation. being able to open a unix shell, run python and have a basic webserver running in a few lines of code was fantastic for my young hacker mind. this also probably helps explain the popularity of javascript too. this isn't to say i think python is the end-all of programming, far from it, but it certainly took a lot of the novice programmer anxiety out of programming for me. if only i'd encountered erlang during those formative years... -pete -- Pete Wright pete at nomadlogic.org @nomadlogicLA From bakul at iitbombay.org Thu Aug 3 12:53:51 2023 From: bakul at iitbombay.org (Bakul Shah) Date: Wed, 2 Aug 2023 19:53:51 -0700 Subject: [TUHS] python In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> Message-ID: <433AC8D1-8AF9-4718-A58A-7ABB83DF99BE@iitbombay.org> On Aug 2, 2023, at 6:20 PM, George Michaelson wrote: > > Maybe it's no worse a fit than "containers" and after all, we're in > Kubernetes because of Plan9, right? Wait, what? How did Plan9 beget Kubernetes? plan9 namespaces are wonderful, while kubernetes.... But this made me do some googling and I found "K9P: Kubernetes as 9P files" YT video. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Thu Aug 3 12:55:45 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 03 Aug 2023 02:55:45 +0000 Subject: [TUHS] python In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> Message-ID: <-p9KOIYYXcr9HBb88Zv8Nxfz0gkwFux3pDNEVC3jbtIKPJfXC_6eHvj8nAXnnu9TMiJdF_Vj69BPbDRVLSRkDj-h_FRPVH6wEO6Rhmw42Lg=@protonmail.com> > The resurgence of chatter about Common LISP says something to me. > > G LISP is one of those things I always say I'm going to go study more, try and understand the implications of, but it continues to be so far afield from the typical realms I work in that I just haven't found that catch point to get me more interested in it. That said, there is a little voice in that same part of my brain whispering about exploring FP for creating software polygon rendering stuff, which right now I only really work with through the OpenGL and video game console lenses. Probably the closest I got to something LISPy was futzing with some Guile stuff pertaining to GDB. Also pardon the whole "Python's a functional language I am very smart about things", that's based on plenty of commentary I've heard and read, not any sort of formal analysis or research. Feel free to call me out anywhere you think I might be parroting (inaccurate) common sentiment about things I have tangential understanding of, I try not to but sometimes it just still crops up in casual chit chat :P To attempt a tie-back to TUHS, has anyone here ever tried to bring up bits of Python on a historic UNIX implementation? - Matt G. From imp at bsdimp.com Thu Aug 3 12:56:41 2023 From: imp at bsdimp.com (Warner Losh) Date: Wed, 2 Aug 2023 20:56:41 -0600 Subject: [TUHS] python In-Reply-To: <2f77b26f-206c-6a80-90b3-b769a9f0f32d@nomadlogic.org> References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <2f77b26f-206c-6a80-90b3-b769a9f0f32d@nomadlogic.org> Message-ID: On Wed, Aug 2, 2023 at 8:21 PM Pete Wright via TUHS wrote: > this isn't to say i think python is the end-all of programming, far from > it, but it certainly took a lot of the novice programmer anxiety out of > programming for be. > python doesn't suck because batteries are included and what's not included is pretty easy to just drag in and get craptops of useful stuff done in a hurry. Would I write a kernel in? Hell no. But would I knock together a bit of data visualization after massaging data in an almost throw-a-way manner? You betcha. It's stunningly adequate... A latter day awk for junk I need to do from time to time... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggm at algebras.org Thu Aug 3 13:24:19 2023 From: ggm at algebras.org (George Michaelson) Date: Thu, 3 Aug 2023 13:24:19 +1000 Subject: [TUHS] python In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> Message-ID: Tail recursion not lazy eval. I wish words meant what I meant "inside" when I think them, not "outside" what they mean when I write them. From imp at bsdimp.com Thu Aug 3 13:32:08 2023 From: imp at bsdimp.com (Warner Losh) Date: Wed, 2 Aug 2023 21:32:08 -0600 Subject: [TUHS] python In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> Message-ID: On Wed, Aug 2, 2023, 9:24 PM George Michaelson wrote: > Tail recursion not lazy eval. > > I wish words meant what I meant "inside" when I think them, not > "outside" what they mean when I write them. > Python is an ugly ass language to be sure. It's a useful tool. I have this rather ugly axe. I've split a lot of wood with it. Chopped down nasty weeds. Pounded in nails, spikes, landscaping staples, and the odd screw or two. I've cut impromptu joints to make lean too structures that I threw painter's tarps over to save the tomatoes from frost. And maybe a dozen other things. But to do framing or naked furniture, I use different tools more suited for those specific tasks... but the axe still has its uses... much like python... Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Thu Aug 3 13:55:50 2023 From: bakul at iitbombay.org (Bakul Shah) Date: Wed, 2 Aug 2023 20:55:50 -0700 Subject: [TUHS] python In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> Message-ID: python can certainly implement tail call optimization (TCO). Pretty much any language can implement TCO but for some reason people think such programs are harder to debug (and yet they don't similarly complain about loops!). The beauty of Scheme was that it *mandated* tail recursion. > On Aug 2, 2023, at 8:24 PM, George Michaelson wrote: > > Tail recursion not lazy eval. > > I wish words meant what I meant "inside" when I think them, not > "outside" what they mean when I write them. From robpike at gmail.com Thu Aug 3 18:32:27 2023 From: robpike at gmail.com (Rob Pike) Date: Thu, 3 Aug 2023 18:32:27 +1000 Subject: [TUHS] python In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> Message-ID: I once inherited maintenance of a critical piece of infrastructure written in exquisitely well written, tested, and documented Python. I mean it, it was really really good. It crashed about once a week and I had to fix it over and over because in those exponentially vast combinations of paths through the code would arise yet another way to turn a string into a list, or something analogous. It was hell. Critical code needs static typing. -rob On Thu, Aug 3, 2023 at 1:56 PM Bakul Shah wrote: > python can certainly implement tail call optimization (TCO). Pretty much > any language can implement TCO but for some reason people think such > programs are harder to debug (and yet they don't similarly complain about > loops!). The beauty of Scheme was that it *mandated* tail recursion. > > > On Aug 2, 2023, at 8:24 PM, George Michaelson wrote: > > > > Tail recursion not lazy eval. > > > > I wish words meant what I meant "inside" when I think them, not > > "outside" what they mean when I write them. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.ab3ap at gmail.com Thu Aug 3 22:36:02 2023 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Thu, 3 Aug 2023 08:36:02 -0400 Subject: [TUHS] python In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> Message-ID: Clem and all, I find python string format syntax to be close enough to printf. E.g.,   print('%.4f ns, (%.4f, %.4fj)' % (tap[0], tap[1].real, tap[1].imag)) However, the example highlights a shortcoming.  While complex numbers are supported by the language, there is no formatting support like '%.5j' ('j' is my made up format char) to directly format a complex number. I work in an RF lab focused on work with hardware and lab gear. Some points in favor of python are (1) lab gear is controlled by SCPI, (2) DSP relies on complex math, and (3) RF propagation modeling is computationally intense. Item (1) is easily performed with python, (2) with python or Matlab/octave, and (3) is 'it depends.'  An engineer's friend went from slide rule, to calculator, fortran/c (fortran for numbers, c for hardware), and now python. A laptop with python or matlab is the new 'calculator.'  As to (3), if you will use the program for large scenarios, use c or fortran. For small runs or to dovetail results with control of lab gear python fills the bill.  (I even went to the slightly insane length of converting a classic prop model from fortran to python for that reason: https://udel.edu/~mm/itm/ ) I agree 110% that python white space formatting is horrible.  I can't say many times I took someone else's program, made a quick change, to discover one of us used tabs and the other spaces. Mike Markowski On 8/2/23 10:07 PM, Clem Cole wrote: > IMO (Like Larry) no printf stinks.  But the real killer for my sustain > for Python is the use white space and being typeless.   My daughter > loves it for her cloud development and we argue a bit.  But it was the > first language she really mastered in college and she never took a > competitive languages course so I’m not so sure really had experienced > much beyond it for real programs.   Maybe I’m just an old fart but > between C, Go and Rust I’m pretty good.  I do write scripts in Bourne > shell and or awk truth be known. > From robpike at gmail.com Thu Aug 3 23:29:18 2023 From: robpike at gmail.com (Rob Pike) Date: Thu, 3 Aug 2023 23:29:18 +1000 Subject: [TUHS] python In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> Message-ID: The idea of indentation defining structure seemed really cool when it arose. I first saw it in a toy language called Henry, back in the early 1980s. But over time the notion that invisible characters define program execution created so many problems that in retrospect it is ill advised despite its prevalence. In fact its prevalence makes it even less advisable, as it creates yet more areas for trouble. -rob On Thu, Aug 3, 2023 at 10:36 PM Mike Markowski wrote: > Clem and all, > > I find python string format syntax to be close enough to printf. E.g., > > print('%.4f ns, (%.4f, %.4fj)' % (tap[0], tap[1].real, tap[1].imag)) > > However, the example highlights a shortcoming. While complex numbers > are supported by the language, there is no formatting support like > '%.5j' ('j' is my made up format char) to directly format a complex number. > > I work in an RF lab focused on work with hardware and lab gear. Some > points in favor of python are (1) lab gear is controlled by SCPI, (2) > DSP relies on complex math, and (3) RF propagation modeling is > computationally intense. > > Item (1) is easily performed with python, (2) with python or > Matlab/octave, and (3) is 'it depends.' An engineer's friend went from > slide rule, to calculator, fortran/c (fortran for numbers, c for > hardware), and now python. A laptop with python or matlab is the new > 'calculator.' As to (3), if you will use the program for large > scenarios, use c or fortran. For small runs or to dovetail results with > control of lab gear python fills the bill. (I even went to the slightly > insane length of converting a classic prop model from fortran to python > for that reason: https://udel.edu/~mm/itm/ ) > > I agree 110% that python white space formatting is horrible. I can't > say many times I took someone else's program, made a quick change, to > discover one of us used tabs and the other spaces. > > Mike Markowski > > On 8/2/23 10:07 PM, Clem Cole wrote: > > IMO (Like Larry) no printf stinks. But the real killer for my sustain > > for Python is the use white space and being typeless. My daughter > > loves it for her cloud development and we argue a bit. But it was the > > first language she really mastered in college and she never took a > > competitive languages course so I’m not so sure really had experienced > > much beyond it for real programs. Maybe I’m just an old fart but > > between C, Go and Rust I’m pretty good. I do write scripts in Bourne > > shell and or awk truth be known. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Fri Aug 4 00:19:58 2023 From: bakul at iitbombay.org (Bakul Shah) Date: Thu, 3 Aug 2023 07:19:58 -0700 Subject: [TUHS] python In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> Message-ID: I have not heard such horror stories about Common Lisp (or may be I have forgotten them!). My impression is that python doesn't quite have the kind of {meta,}programming tools Common Lisp has. CL has been used for large critical programs. Perhaps Von Rossum had more experience with statically typed languages than Lisp (because -- pure speculation here -- if he had used CL enough, he would never have designed python :-) > On Aug 3, 2023, at 1:32 AM, Rob Pike wrote: > > I once inherited maintenance of a critical piece of infrastructure written in exquisitely well written, tested, and documented Python. I mean it, it was really really good. > > It crashed about once a week and I had to fix it over and over because in those exponentially vast combinations of paths through the code would arise yet another way to turn a string into a list, or something analogous. It was hell. > > Critical code needs static typing. > > -rob > > > On Thu, Aug 3, 2023 at 1:56 PM Bakul Shah > wrote: >> python can certainly implement tail call optimization (TCO). Pretty much any language can implement TCO but for some reason people think such programs are harder to debug (and yet they don't similarly complain about loops!). The beauty of Scheme was that it *mandated* tail recursion. >> >> > On Aug 2, 2023, at 8:24 PM, George Michaelson > wrote: >> > >> > Tail recursion not lazy eval. >> > >> > I wish words meant what I meant "inside" when I think them, not >> > "outside" what they mean when I write them. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From halbert at halwitz.org Fri Aug 4 00:56:22 2023 From: halbert at halwitz.org (Dan Halbert) Date: Thu, 3 Aug 2023 10:56:22 -0400 Subject: [TUHS] python In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> Message-ID: <1f043101-4dbb-34ff-b037-85e7cc707a6e@halwitz.org> Python has optional type annotations. There are batch tools (e.g., MyPy) to do type analysis and IDE's also provide help. Example: def greeting(name: str) -> str:     return 'Hello ' + name I found Python to be an enormous improvement over Perl for writing the kinds of things I used to write in Perl, with the Perl book at my side. I currently make my living working on Python for microcontrollers. Neverthless, I am fond of type checking too, and if I were writing a large Python system, I would use type annotations. I have used BCPL too, in the 70's, and we achieved some measure of type safety by careful naming. Dan H. On 8/3/23 10:19, Bakul Shah wrote: > I have not heard such horror stories about Common Lisp (or may be I > have forgotten them!). My impression is that python doesn't quite have > the kind of {meta,}programming tools Common Lisp has. CL has been used > for large critical programs. Perhaps Von Rossum had more experience > with statically typed languages than Lisp (because -- pure speculation > here -- if he had used CL enough, he would never have designed python :-) > >> On Aug 3, 2023, at 1:32 AM, Rob Pike wrote: >> >> I once inherited maintenance of a critical piece of infrastructure >> written in exquisitely well written, tested, and documented Python. I >> mean it, it was really really good. >> >> It crashed about once a week and I had to fix it over and over >> because in those exponentially vast combinations of paths through the >> code would arise yet another way to turn a string into a list, or >> something analogous. It was hell. >> >> Critical code needs static typing. >> >> -rob >> >> >> On Thu, Aug 3, 2023 at 1:56 PM Bakul Shah wrote: >> >> python can certainly implement tail call optimization (TCO). >> Pretty much any language can implement TCO but for some reason >> people think such programs are harder to debug (and yet they >> don't similarly complain about loops!). The beauty of Scheme was >> that it *mandated* tail recursion. >> >> > On Aug 2, 2023, at 8:24 PM, George Michaelson >> wrote: >> > >> > Tail recursion not lazy eval. >> > >> > I wish words meant what I meant "inside" when I think them, not >> > "outside" what they mean when I write them. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Fri Aug 4 01:20:53 2023 From: will.senn at gmail.com (will.senn at gmail.com) Date: Thu, 03 Aug 2023 10:20:53 -0500 Subject: [TUHS] python In-Reply-To: <1f043101-4dbb-34ff-b037-85e7cc707a6e@halwitz.org> References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <1f043101-4dbb-34ff-b037-85e7cc707a6e@halwitz.org> Message-ID: <2BF7ADB4-4851-4CF5-A6AC-0F1079D4AF78@gmail.com> Nice. I've never appreciated type checking at 'compile' time, but I understand why others might (ocd). C was my first exposure to blending types, then Perl was fuzzier, then Python was even better at pretending types didn't matter. Now, with Lisp, I am freed from type concerns... until I'm not. Thankfully, it's my choice. Will On August 3, 2023 9:56:22 AM CDT, Dan Halbert wrote: >Python has optional type annotations. There are batch tools (e.g., MyPy) to do type analysis and IDE's also provide help. Example: > >def greeting(name: str) -> str: >    return 'Hello ' + name > >I found Python to be an enormous improvement over Perl for writing the kinds of things I used to write in Perl, with the Perl book at my side. I currently make my living working on Python for microcontrollers. Neverthless, I am fond of type checking too, and if I were writing a large Python system, I would use type annotations. > >I have used BCPL too, in the 70's, and we achieved some measure of type safety by careful naming. > >Dan H. > >On 8/3/23 10:19, Bakul Shah wrote: >> I have not heard such horror stories about Common Lisp (or may be I have forgotten them!). My impression is that python doesn't quite have the kind of {meta,}programming tools Common Lisp has. CL has been used for large critical programs. Perhaps Von Rossum had more experience with statically typed languages than Lisp (because -- pure speculation here -- if he had used CL enough, he would never have designed python :-) >> >>> On Aug 3, 2023, at 1:32 AM, Rob Pike wrote: >>> >>> I once inherited maintenance of a critical piece of infrastructure written in exquisitely well written, tested, and documented Python. I mean it, it was really really good. >>> >>> It crashed about once a week and I had to fix it over and over because in those exponentially vast combinations of paths through the code would arise yet another way to turn a string into a list, or something analogous. It was hell. >>> >>> Critical code needs static typing. >>> >>> -rob >>> >>> >>> On Thu, Aug 3, 2023 at 1:56 PM Bakul Shah wrote: >>> >>> python can certainly implement tail call optimization (TCO). >>> Pretty much any language can implement TCO but for some reason >>> people think such programs are harder to debug (and yet they >>> don't similarly complain about loops!). The beauty of Scheme was >>> that it *mandated* tail recursion. >>> >>> > On Aug 2, 2023, at 8:24 PM, George Michaelson >>> wrote: >>> > >>> > Tail recursion not lazy eval. >>> > >>> > I wish words meant what I meant "inside" when I think them, not >>> > "outside" what they mean when I write them. >>> >> -- Sent from /e/OS Mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From emu at e-bbes.com Fri Aug 4 01:24:00 2023 From: emu at e-bbes.com (emanuel stiebler) Date: Thu, 3 Aug 2023 11:24:00 -0400 Subject: [TUHS] python In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> Message-ID: <99511256-1c0a-732b-4b78-a879a67a2291@e-bbes.com> On 2023-08-03 09:29, Rob Pike wrote: > The idea of indentation defining structure seemed really cool when it > arose. I first saw it in a toy language called Henry, back in the early > 1980s. > > But over time the notion that invisible characters define program > execution created so many problems that in retrospect it is ill advised > despite its prevalence. In fact its prevalence makes it even less > advisable, as it creates yet more areas for trouble. Most editors have some "beautify modes" which can fix indentation, so the programmer sees what he is doing in deep nested stuff. Counting "white spaces" in 21st century? From steffen at sdaoden.eu Fri Aug 4 01:39:50 2023 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 03 Aug 2023 17:39:50 +0200 Subject: [TUHS] python In-Reply-To: <99511256-1c0a-732b-4b78-a879a67a2291@e-bbes.com> References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <99511256-1c0a-732b-4b78-a879a67a2291@e-bbes.com> Message-ID: <20230803153950.DzynA%steffen@sdaoden.eu> emanuel stiebler wrote in <99511256-1c0a-732b-4b78-a879a67a2291 at e-bbes.com>: |On 2023-08-03 09:29, Rob Pike wrote: |> The idea of indentation defining structure seemed really cool when it |> arose. I first saw it in a toy language called Henry, back in the early |> 1980s. |> |> But over time the notion that invisible characters define program |> execution created so many problems that in retrospect it is ill advised |> despite its prevalence. In fact its prevalence makes it even less |> advisable, as it creates yet more areas for trouble. | |Most editors have some "beautify modes" which can fix indentation, |so the programmer sees what he is doing in deep nested stuff. | |Counting "white spaces" in 21st century? Normally a newer C compiler beats unto you if your indentation does not satisfy him? (Or was that clang only? That one maybe learns to cook your favorite hot beverage if its size exceeds the second gigabyte.) --End of <99511256-1c0a-732b-4b78-a879a67a2291 at e-bbes.com> Ciao. P.S.: unfair + without any insider knowledge: it must be like that. $ ll /usr/ports/built/tcc#20230731-1.pkg.tar.xz -rw-rw---- 1 ports ports 250632 Jul 31 21:14 /usr/ports/built/tcc#20230731-1.pkg.tar.xz $ xz -l /usr/ports/built/tcc#20230731-1.pkg.tar.xz Strms Blocks Compressed Uncompressed Ratio Check Filename 1 1 244.8 KiB 1180.5 KiB 0.207 CRC64 /usr/ports/built/tcc#20230731-1.pkg.tar.xz No pcc here at the moment :( $ ll /usr/ports/built/gcc#12.3.0-2.pkg.tar.xz -rw-rw---- 1 ports ports 50662716 May 27 20:45 /usr/ports/built/gcc#12.3.0-2.pkg.tar.xz $ xz -l /usr/ports/built/gcc#12.3.0-2.pkg.tar.xz Strms Blocks Compressed Uncompressed Ratio Check Filename 1 9 48.3 MiB 206.5 MiB 0.234 CRC64 /usr/ports/built/gcc#12.3.0-2.pkg.tar.xz $ prt-get info gcc|grep Depend Dependencies: libmpc,zlib,zstd $ ll /usr/ports/built/clang#16.0.6-1.pkg.tar.xz -rw-rw---- 1 ports ports 103260340 Jun 23 22:19 /usr/ports/built/clang#16.0.6-1.pkg.tar.xz $ xz -l /usr/ports/built/clang#16.0.6-1.pkg.tar.xz Strms Blocks Compressed Uncompressed Ratio Check Filename 1 42 98.5 MiB 991.7 MiB 0.099 CRC64 /usr/ports/built/clang#16.0.6-1.pkg.tar.xz $ prt-get info clang|grep Depend Dependencies: compiler-rt $ ll /usr/ports/built/compiler-rt#16.0.6-1.pkg.tar.xz -rw-rw---- 1 ports ports 3633680 Jun 23 21:04 /usr/ports/built/compiler-rt#16.0.6-1.pkg.tar.xz $ xz -l /usr/ports/built/compiler-rt#16.0.6-1.pkg.tar.xz Strms Blocks Compressed Uncompressed Ratio Check Filename 1 2 3548.5 KiB 36.3 MiB 0.096 CRC64 /usr/ports/built/compiler-rt#16.0.6-1.pkg.tar.xz $ prt-get info compiler-rt|grep Depend Dependencies: llvm $ ll /usr/ports/built/llvm#16.0.6-1.pkg.tar.xz -rw-rw---- 1 ports ports 115485456 Jun 23 21:00 /usr/ports/built/llvm#16.0.6-1.pkg.tar.xz $ xz -l /usr/ports/built/llvm#16.0.6-1.pkg.tar.xz Strms Blocks Compressed Uncompressed Ratio Check Filename 1 29 110.1 MiB 678.9 MiB 0.162 CRC64 /usr/ports/built/llvm#16.0.6-1.pkg.tar.xz $ prt-get info llvm|grep Depend Dependencies: cmake,libffi,libxml2,ninja,python3-setuptools --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 cowan at ccil.org Fri Aug 4 01:41:28 2023 From: cowan at ccil.org (John Cowan) Date: Thu, 3 Aug 2023 11:41:28 -0400 Subject: [TUHS] python In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> Message-ID: On Thu, Aug 3, 2023 at 10:20 AM Bakul Shah wrote: I have not heard such horror stories about Common Lisp (or may be I have > forgotten them!). > Both Common Lisp and Python have optional static typing that is as rigorous as you might want. In the case of Python it is an outboard tool that you put into your build file; Python itself ignores declarations. (That means that the declarations are not used to optimize runtime performance.) The mypy tool does extensive type inference; you can get a long way without ever writing a declaration. For CL, type checking is part of the compiler; the interpreter generally ignores type declarations, although Steel Bank CL, the fastest existing implementation, uses the compiler even in the REPL. -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at ultimate.com Fri Aug 4 02:57:31 2023 From: phil at ultimate.com (Phil Budne) Date: Thu, 03 Aug 2023 12:57:31 -0400 Subject: [TUHS] [TULSA] Re: python In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> Message-ID: <202308031657.373GvVvW008640@ultimate.com> I come not to praise Python... I picked up Python (v1) in the early 'aughts as a more readable alternative to Perl and Ruby (non-alphanumerical variable names are a non-starter for me). I agree that using indentation alone to determine block structure was an interesting thought experiment, but TERRIBLE in practice (you might as well throw away any editing buffer where the phone rang after you cut and paste, but before re-indenting code), BUT it does prevent (in a rather fascist way) formatting abominations like the C code in procmail and SimH. Python continues to evolve, so it's a moving target, and the argument that there is ONE RIGHT WAY(TM) to do anything is not only long dead, but now deeply putrid (much as with the multiple doublings in the size of C++ and later C++ + STL books). I used to regard the Python2/Python3 world breakage as a fiasco, but considering how quickly the language is mutating, perhaps is was a good fiasco if it lowered the mutation rate for number of years. On the subject of "no printf", there is not one, not two, but THREE ways to format strings, easily compounded with print: print("%s %s" % ("hello", "world")) print("{1} {two}".format("hello", two="world")) print(f"{greeting} {populace}") I'm pretty sure the last method (which initially made me vomit, due to violating my hardwired ideas about complicating the lexer, as if it can even be thought of as a separate layer), BUT I Seem To Recall that it allows a class to implement a formatting method, which may (or may not) work for complex numbers. Type "hinting" has been mentioned: again, it's almost like a whole new version of the language. You need to pick a type checker, and likely turn up the knobs to achieve any actual safety, and then deal with the fact that not all packages supply hints out of the box. It kind of offers the desert-topping/floor-wax dichotomy: You can easily/quickly write small programs with dynamic typing for quick one-offs, AND write better armored code for libraries & production code. On tabs vs spaces: Python3 forbids mixing them. Again, fascist, but "it's for your own good". So yes, Python sucks, but I continue using it, and unlike sendmail (which I continue to run, as I have a 200+ line .mc file it would take me at LEAST a week to replicate the effects of in another MTA), I don't tell people Python is unsuitable at any speed. I'd probably happily write Go or Rust, given a situation (existing project/program) where its use was inevitable, and I DO have a program I think is a good candidate for rewriting in Go, but on the whole, it's a useful tool for many kinds of programmers, and in many situations, which I think is somewhat remarkable. From rich.salz at gmail.com Fri Aug 4 03:00:48 2023 From: rich.salz at gmail.com (Rich Salz) Date: Thu, 3 Aug 2023 13:00:48 -0400 Subject: [TUHS] [TULSA] Re: python In-Reply-To: <202308031657.373GvVvW008640@ultimate.com> References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <202308031657.373GvVvW008640@ultimate.com> Message-ID: What, we all need something to kick now that we've beaten sendmail? How about something unix, ideally a decade old? -------------- next part -------------- An HTML attachment was scrubbed... URL: From alx.manpages at gmail.com Fri Aug 4 03:29:00 2023 From: alx.manpages at gmail.com (Alejandro Colomar) Date: Thu, 3 Aug 2023 19:29:00 +0200 Subject: [TUHS] [TULSA] Re: python In-Reply-To: <202308031657.373GvVvW008640@ultimate.com> References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <202308031657.373GvVvW008640@ultimate.com> Message-ID: <8e45b8b1-cf3c-e47c-bd15-d19a2ae5cc1d@gmail.org> On 2023-08-03 18:57, Phil Budne wrote: > On the subject of "no printf", there is not one, not two, but THREE > ways to format strings, easily compounded with print: > > print("%s %s" % ("hello", "world")) > print("{1} {two}".format("hello", two="world")) > print(f"{greeting} {populace}") > > I'm pretty sure the last method (which initially made me vomit, due to > violating my hardwired ideas about complicating the lexer, as if it > can even be thought of as a separate layer), BUT I Seem To Recall that > it allows a class to implement a formatting method, which may (or may > not) work for complex numbers. Actually, there's no need to move away from printf(3) for customization. glibc provides register_printf_specifier(3), register_printf_modifier(3), and register_printf_modifier(3), with which you can register %S for printing your very nice struct. You can even register modifiers, such as %vS for printing your structure in a different manner. Of course, those APIs are not portable, but that's a matter of porting them; you don't need to invent a completely new formatted print variant just to do that. How does one even specify the equivalent of "%+'0#8.5f" in the new {} formats?? Of course, there may be reasons to move away from printf(3): C++ seems to have a faster thing with std:format (or so they claim; I didn't try it). But if speed is not a problem, I'd keep the good ol' syntax that everybody knows. No need to make everybody learn a "cool" new print function, that probably won't be as tunable as printf(3) is. Another thing is type safety. printf(3) is actually type-safe. At least as long as you use powerful compilers that can diagnose misuses of printf-like APIs. GCC provides [[gnu::format()]] for a reason. And if you customize printf with your own formats, Clang has tools for checking those too. > > Type "hinting" has been mentioned: again, it's almost like a whole new > version of the language. You need to pick a type checker, and likely > turn up the knobs to achieve any actual safety, and then deal with the > fact that not all packages supply hints out of the box. It kind of > offers the desert-topping/floor-wax dichotomy: You can easily/quickly > write small programs with dynamic typing for quick one-offs, AND write > better armored code for libraries & production code. > > On tabs vs spaces: Python3 forbids mixing them. Again, fascist, but > "it's for your own good". > > So yes, Python sucks, but I continue using it, and unlike sendmail > (which I continue to run, as I have a 200+ line .mc file it would take > me at LEAST a week to replicate the effects of in another MTA), I > don't tell people Python is unsuitable at any speed. > > I'd probably happily write Go or Rust, given a situation (existing > project/program) where its use was inevitable, and I DO have a program > I think is a good candidate for rewriting in Go, but on the whole, > it's a useful tool for many kinds of programmers, and in many > situations, which I think is somewhat remarkable. I'll go a little step further, and claim that newlines being significant is another bad decission. It's one of the things I dislike from languages, including sh(1). My scripts end up having a lot of escaped newlines, because I find the pipe to be more readable and pleasant as foo \ | bar rather than foo | bar While I can forgive that in the shell, because interactive mode is as important as scripts, I can't do the same with Go. Go is a programming language, and having newlines be significant is nonsense. Saving from typing ;s is a similar excuse that the one python used for saving typing {}s. And the consequence is that due to that fascist rule of go, I can't put the opening brace of a function declaration in a new line; it must be sticked to the same line as the function declarator. I never enjoyed Go, and that was the main reason. In any case, I never found a need for it. Most (all?) of what I do can be done with sh(1) or C. Alex From cowan at ccil.org Fri Aug 4 03:51:46 2023 From: cowan at ccil.org (John Cowan) Date: Thu, 3 Aug 2023 13:51:46 -0400 Subject: [TUHS] [TULSA] Re: python In-Reply-To: <8e45b8b1-cf3c-e47c-bd15-d19a2ae5cc1d@gmail.org> References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <202308031657.373GvVvW008640@ultimate.com> <8e45b8b1-cf3c-e47c-bd15-d19a2ae5cc1d@gmail.org> Message-ID: On Thu, Aug 3, 2023 at 1:29 PM Alejandro Colomar wrote: But if speed is not a problem, I'd keep the good ol' syntax that everybody knows. No need to make everybody learn a "cool" new print > function, that probably won't be as tunable as printf(3) is. > > By that argument, there would be no C, only Algol 68 and PL/I, or subsets of them. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alx.manpages at gmail.com Fri Aug 4 04:05:43 2023 From: alx.manpages at gmail.com (Alejandro Colomar) Date: Thu, 3 Aug 2023 20:05:43 +0200 Subject: [TUHS] [TULSA] Re: python In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <202308031657.373GvVvW008640@ultimate.com> <8e45b8b1-cf3c-e47c-bd15-d19a2ae5cc1d@gmail.org> Message-ID: On 2023-08-03 19:51, John Cowan wrote: > On Thu, Aug 3, 2023 at 1:29 PM Alejandro Colomar > wrote: > > But if speed is not a problem, I'd keep the good ol' syntax that > > everybody knows. No need to make everybody learn a "cool" new print >> function, that probably won't be as tunable as printf(3) is. >> >> > By that argument, there would be no C, only Algol 68 and PL/I, or subsets > of them. > I didn't claim that there's never a reason to invent new syntax. My claim was rather that in this case, there isn't. - printf(3) is more powerful than any other existing formatting function that I know of any language --I'm still curious of what's the equivalent of "%+'0#8.5f" in other formatting functions--. - It is also reasonably fast (at least for such a highly-customizable formatting function), and I'd like to see any system beat that while keeping the customizability. - It is type-safe, with the right tools. I can understand the need for less-customizable faster formatting functions for very-high-performance programs, and std::format may fit well there. But other than that, I don't see a reason to invent so many different formatting functions. Of course, one may do that just for fun, in which case I applaud that. But printf(3) is superior to them, IMO. Alex From will.senn at gmail.com Fri Aug 4 06:35:09 2023 From: will.senn at gmail.com (Will Senn) Date: Thu, 3 Aug 2023 15:35:09 -0500 Subject: [TUHS] Split addressing (I/D) space (inspired by the death of the python... thread) In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <202308031657.373GvVvW008640@ultimate.com> Message-ID: Does unix (v7) know about the PDP-11 45's split I/D space through configuration or is it convention and programmer's responsibility to know and manage what's actually available? Will On 8/3/23 12:00, Rich Salz wrote: > What, we all need something to kick now that we've beaten sendmail?  > How about something unix, ideally a decade old? From steffen at sdaoden.eu Fri Aug 4 07:02:21 2023 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 03 Aug 2023 23:02:21 +0200 Subject: [TUHS] [TULSA] Re: python In-Reply-To: <202308031657.373GvVvW008640@ultimate.com> References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <202308031657.373GvVvW008640@ultimate.com> Message-ID: <20230803210221.uMBpw%steffen@sdaoden.eu> Phil Budne wrote in <202308031657.373GvVvW008640 at ultimate.com>: |I come not to praise Python... | |I picked up Python (v1) in the early 'aughts as a more readable |alternative to Perl and Ruby (non-alphanumerical variable names are a |non-starter for me). That thrilled me! empty? instead of is_empty(), d! instead of log_this_string_if_debug_is_enabled() (which could be LogThisStringIfDebugIsEnabled() even, or another damage)! It (i did not know anything about Plan9 and people who use greek letters and other math symbols as variable or function names) inspired me sustainably: au Filetype c,cpp :iab $! /*! \_*/ au Filetype c :iab $!W su_log_write(su_LOG_WARN, "");=__gobble() au Filetype cpp :iab $!W log::write(log::warn, "");=__gobble() (Not a vim master.) Their yaml help files were a pain (for me; especially since the structure was there, yet the content was missing). .. --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 kennethgoodwin56 at gmail.com Fri Aug 4 07:05:31 2023 From: kennethgoodwin56 at gmail.com (Kenneth Goodwin) Date: Thu, 3 Aug 2023 17:05:31 -0400 Subject: [TUHS] Split addressing (I/D) space (inspired by the death of the python... thread) In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <202308031657.373GvVvW008640@ultimate.com> Message-ID: At the risk of exposing my ignorance and thus being events long long ago in history.... And my mind now old and feeble... 😆 🤣 1. I don't think the 11/45 had split I & d. But I could be wrong. That did not appear until the 11/70 And was in the later generation 11/44 several years later. 2. The kernel determined it by MMU type and managed it solely. The assembler and loader always built the binary object file as the three sections - instructions, data and bss spaces so loading an object file could be done on any platform. Programmers generally did not worry about the underlying hardware 3. I don't recall if a systype style system call was available in v7 to give you a machine type to switch off of. With something like that you could determine memory availability hard limits on the DATA/bss side if you needed to. But that was also easily determined by a allocation failure in malloc/sbrk with an out of memory error. If you really needed to know availability, you could have a start up subroutine that would loop trying to malloc ever decreasing memory sizes until success and until out of available memory error. Then release it all back via free(). Or manage it internally. As I recall however vaguely, there was an attempt to split the kernel into two pieces. One running in kernel mode and one running in supervisor mode in order to double the amount of available instruction and data spaces for the operating system. I recall playing around with what was there trying to get it to work right. I was trying to support over 200 users on a pdp 11/70 at the time running a massive insurance database system. On Thu, Aug 3, 2023, 4:35 PM Will Senn wrote: > Does unix (v7) know about the PDP-11 45's split I/D space through > configuration or is it convention and programmer's responsibility to > know and manage what's actually available? > > Will > > On 8/3/23 12:00, Rich Salz wrote: > > What, we all need something to kick now that we've beaten sendmail? > > How about something unix, ideally a decade old? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Fri Aug 4 07:05:58 2023 From: ron at ronnatalie.com (Ronald Natalie) Date: Thu, 03 Aug 2023 21:05:58 +0000 Subject: [TUHS] Split addressing (I/D) space (inspired by the death of the python... thread) In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <202308031657.373GvVvW008640@ultimate.com> Message-ID: Both V6 and V7 used split I/D on the 45 and 70 where it as available. You had to specify that you wanted it in your build, the choices were the 407 flagged. a.out, which had a single text/data/bss space (unspilt). 410 which still ran in one address space, but put the text in read only segments so they could be shared. 411 ran the executable in split I and D space. The original use of the “sticky” bit in the inode mode indicated that a 410 or 411 program text would be held in swap. -Ron ------ Original Message ------ >From "Will Senn" To tuhs at tuhs.org Date 8/3/23, 4:35:09 PM Subject [TUHS] Split addressing (I/D) space (inspired by the death of the python... thread) >Does unix (v7) know about the PDP-11 45's split I/D space through configuration or is it convention and programmer's responsibility to know and manage what's actually available? > >Will > >On 8/3/23 12:00, Rich Salz wrote: >>What, we all need something to kick now that we've beaten sendmail? How about something unix, ideally a decade old? > From ron at ronnatalie.com Fri Aug 4 07:10:14 2023 From: ron at ronnatalie.com (Ronald Natalie) Date: Thu, 03 Aug 2023 21:10:14 +0000 Subject: [TUHS] Split addressing (I/D) space (inspired by the death of the python... thread) In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <202308031657.373GvVvW008640@ultimate.com> Message-ID: Having cut my UNIX teeth on the JHU 11/45, I can tell you very much that it did have split I/D. V6 supported split I/D for user mode programs. The kernel originally wasn’t split I/D. Version 7, if I’m recalling properly, did run the kernel split I/D on the 45 and 70. ------ Original Message ------ >From "Kenneth Goodwin" To "Will Senn" Cc "The Eunuchs Hysterical Society" Date 8/3/23, 5:05:31 PM Subject [TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread) >At the risk of exposing my ignorance and thus being events long long >ago in history.... >And my mind now old and feeble... > >😆 🤣 > >1. I don't think the 11/45 had split I & d. >But I could be wrong. >That did not appear until the 11/70 >And was in the later generation 11/44 several years later. > >2. The kernel determined it by MMU type and managed it solely. The >assembler and loader always built the binary object file as the three >sections - instructions, data and bss spaces so loading an object file >could be done on any platform. >Programmers generally did not worry about the underlying hardware > >3. I don't recall if a systype style system call was available in v7 to >give you a machine type to switch off of. > >With something like that you could determine memory availability hard >limits on the DATA/bss side if you needed to. > >But that was also easily determined by a allocation failure in >malloc/sbrk with an out of memory error. > >If you really needed to know availability, you could have a start up >subroutine that would loop trying to malloc ever decreasing memory >sizes until success and until out of available memory error. >Then release it all back via free(). Or manage it internally. > >As I recall however vaguely, there was an attempt to split the kernel >into two pieces. One running in kernel mode and one running in >supervisor mode in order to double the amount of available instruction >and data spaces for the operating system. I recall playing around with >what was there trying to get it to work right. >I was trying to support over 200 users on a pdp 11/70 at the time >running a massive insurance database system. > >On Thu, Aug 3, 2023, 4:35 PM Will Senn wrote: >>Does unix (v7) know about the PDP-11 45's split I/D space through >>configuration or is it convention and programmer's responsibility to >>know and manage what's actually available? >> >>Will >> >>On 8/3/23 12:00, Rich Salz wrote: >> > What, we all need something to kick now that we've beaten sendmail? >> > How about something unix, ideally a decade old? >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Fri Aug 4 07:16:25 2023 From: imp at bsdimp.com (Warner Losh) Date: Thu, 3 Aug 2023 15:16:25 -0600 Subject: [TUHS] Split addressing (I/D) space (inspired by the death of the python... thread) In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <202308031657.373GvVvW008640@ultimate.com> Message-ID: 2BSD also did split I&D in the kernel (as well as run TCP in supervisor mode to get another I/D space). A lot of the overlays was done in the linker, but it wasn't completely automated. I had to tweak the overlay tables a little as I did the 2.11pl0 work since the early stuff wasn't exactly careful about distributing the hacks to the makefile to make it happen... Warner On Thu, Aug 3, 2023 at 3:10 PM Ronald Natalie wrote: > Having cut my UNIX teeth on the JHU 11/45, I can tell you very much that > it did have split I/D. V6 supported split I/D for user mode programs. > The kernel originally wasn’t split I/D. Version 7, if I’m recalling > properly, did run the kernel split I/D on the 45 and 70. > > > > ------ Original Message ------ > From "Kenneth Goodwin" > To "Will Senn" > Cc "The Eunuchs Hysterical Society" > Date 8/3/23, 5:05:31 PM > Subject [TUHS] Re: Split addressing (I/D) space (inspired by the death of > the python... thread) > > At the risk of exposing my ignorance and thus being events long long ago > in history.... > And my mind now old and feeble... > > 😆 🤣 > > 1. I don't think the 11/45 had split I & d. > But I could be wrong. > That did not appear until the 11/70 > And was in the later generation 11/44 several years later. > > 2. The kernel determined it by MMU type and managed it solely. The > assembler and loader always built the binary object file as the three > sections - instructions, data and bss spaces so loading an object file > could be done on any platform. > Programmers generally did not worry about the underlying hardware > > 3. I don't recall if a systype style system call was available in v7 to > give you a machine type to switch off of. > > With something like that you could determine memory availability hard > limits on the DATA/bss side if you needed to. > > But that was also easily determined by a allocation failure in malloc/sbrk > with an out of memory error. > > If you really needed to know availability, you could have a start up > subroutine that would loop trying to malloc ever decreasing memory sizes > until success and until out of available memory error. > Then release it all back via free(). Or manage it internally. > > As I recall however vaguely, there was an attempt to split the kernel > into two pieces. One running in kernel mode and one running in supervisor > mode in order to double the amount of available instruction and data > spaces for the operating system. I recall playing around with what was > there trying to get it to work right. > I was trying to support over 200 users on a pdp 11/70 at the time running > a massive insurance database system. > > On Thu, Aug 3, 2023, 4:35 PM Will Senn wrote: > >> Does unix (v7) know about the PDP-11 45's split I/D space through >> configuration or is it convention and programmer's responsibility to >> know and manage what's actually available? >> >> Will >> >> On 8/3/23 12:00, Rich Salz wrote: >> > What, we all need something to kick now that we've beaten sendmail? >> > How about something unix, ideally a decade old? >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Fri Aug 4 07:24:32 2023 From: ron at ronnatalie.com (Ronald Natalie) Date: Thu, 03 Aug 2023 21:24:32 +0000 Subject: [TUHS] Split addressing (I/D) space (inspired by the death of the python... thread) In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <202308031657.373GvVvW008640@ultimate.com> Message-ID: In fact, it was TCP (mbuf windowing) that killed the non split-I/D systems in our installation. We were already using kernel overlays, but with only 8 segment registers combined for code, data, and stack, we just ran out of registers. By then the VAXEN were coming along. I recycled the 11/34’s etc… into LOS/C Internet routers. The 55 (just a tweaked 45) and later the 44 also had it. In addition the 23/24/J-11 and those derived processors did. ------ Original Message ------ >From "Warner Losh" To "Ronald Natalie" Cc "Kenneth Goodwin" ; "Will Senn" ; "The Eunuchs Hysterical Society" Date 8/3/23, 5:16:25 PM Subject Re: [TUHS] Re: Split addressing (I/D) space (inspired by the death of the python... thread) >2BSD also did split I&D in the kernel (as well as run TCP in supervisor >mode to get another I/D space). A lot of the overlays was done in the >linker, but it wasn't completely automated. >I had to tweak the overlay tables a little as I did the 2.11pl0 work >since the early stuff wasn't exactly careful about distributing the >hacks to the makefile to make it happen... > >Warner > >On Thu, Aug 3, 2023 at 3:10 PM Ronald Natalie >wrote: >>Having cut my UNIX teeth on the JHU 11/45, I can tell you very much >>that it did have split I/D. V6 supported split I/D for user mode >>programs. The kernel originally wasn’t split I/D. Version 7, if >>I’m recalling properly, did run the kernel split I/D on the 45 and 70. >> >> >> >>------ Original Message ------ >>From "Kenneth Goodwin" >>To "Will Senn" >>Cc "The Eunuchs Hysterical Society" >>Date 8/3/23, 5:05:31 PM >>Subject [TUHS] Re: Split addressing (I/D) space (inspired by the death >>of the python... thread) >> >>>At the risk of exposing my ignorance and thus being events long long >>>ago in history.... >>>And my mind now old and feeble... >>> >>>😆 🤣 >>> >>>1. I don't think the 11/45 had split I & d. >>>But I could be wrong. >>>That did not appear until the 11/70 >>>And was in the later generation 11/44 several years later. >>> >>>2. The kernel determined it by MMU type and managed it solely. The >>>assembler and loader always built the binary object file as the three >>>sections - instructions, data and bss spaces so loading an object >>>file could be done on any platform. >>>Programmers generally did not worry about the underlying hardware >>> >>>3. I don't recall if a systype style system call was available in v7 >>>to give you a machine type to switch off of. >>> >>>With something like that you could determine memory availability hard >>>limits on the DATA/bss side if you needed to. >>> >>>But that was also easily determined by a allocation failure in >>>malloc/sbrk with an out of memory error. >>> >>>If you really needed to know availability, you could have a start up >>>subroutine that would loop trying to malloc ever decreasing memory >>>sizes until success and until out of available memory error. >>>Then release it all back via free(). Or manage it internally. >>> >>>As I recall however vaguely, there was an attempt to split the >>>kernel into two pieces. One running in kernel mode and one running in >>>supervisor mode in order to double the amount of available >>>instruction and data spaces for the operating system. I recall >>>playing around with what was there trying to get it to work right. >>>I was trying to support over 200 users on a pdp 11/70 at the time >>>running a massive insurance database system. >>> >>>On Thu, Aug 3, 2023, 4:35 PM Will Senn wrote: >>>>Does unix (v7) know about the PDP-11 45's split I/D space through >>>>configuration or is it convention and programmer's responsibility to >>>>know and manage what's actually available? >>>> >>>>Will >>>> >>>>On 8/3/23 12:00, Rich Salz wrote: >>>> > What, we all need something to kick now that we've beaten >>>>sendmail? >>>> > How about something unix, ideally a decade old? >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Fri Aug 4 07:29:53 2023 From: crossd at gmail.com (Dan Cross) Date: Thu, 3 Aug 2023 17:29:53 -0400 Subject: [TUHS] [TULSA] Re: python In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <202308031657.373GvVvW008640@ultimate.com> <8e45b8b1-cf3c-e47c-bd15-d19a2ae5cc1d@gmail.org> Message-ID: On Thu, Aug 3, 2023 at 2:05 PM Alejandro Colomar wrote: > On 2023-08-03 19:51, John Cowan wrote: > > On Thu, Aug 3, 2023 at 1:29 PM Alejandro Colomar > > wrote: > > > > But if speed is not a problem, I'd keep the good ol' syntax that > > > > everybody knows. No need to make everybody learn a "cool" new print > >> function, that probably won't be as tunable as printf(3) is. > >> > >> > > By that argument, there would be no C, only Algol 68 and PL/I, or subsets > > of them. > > > > I didn't claim that there's never a reason to invent new syntax. My claim > was rather that in this case, there isn't. > > - printf(3) is more powerful than any other existing formatting function > that I know of any language --I'm still curious of what's the equivalent > of "%+'0#8.5f" in other formatting functions--. One issue is that this isn't standard C: the `'` verb for grouping by thousands is an SUSv2 extension. I just checked the latest C23 draft, and unless I missed it, it doesn't appear to have made it in. But things like that are fairly straight-forward in many other languages. For example, in Go, the format string is nearly identical, modulo the `'`: : prithvi; cat print.go package main import "fmt" func main() { fmt.Printf("%+0#8.5f\n", 3.1415) } : prithvi; go run print.go +3.14150 : prithvi; Type safety is achieved through reflection. In Rust, which has a very pleasant formatted print facility, type safety is handled by implementing `print` and `println` as macros. I don't miss `printf` there. > - It is also reasonably fast (at least for such a highly-customizable > formatting function), and I'd like to see any system beat that while > keeping the customizability. At Google, a group of exceptionally talented engineers wrote a replacement in C++ for both type safety and because, bluntly, `printf` (actually `snprintf`) was too slow. I believe the overall mechanism made it into ABSL. > - It is type-safe, with the right tools. No it's not, and it really can't be. True, there are linters that can try to match up types _if_ the format string is a constant and all the arguments are known at e.g. compile time, but C permits one to construct the format string at run time (or just select between a bunch of variants); the language gives you no tools to enforce type safety in a meaningful way once you do that. > I can understand the need for less-customizable faster formatting functions > for very-high-performance programs, and std::format may fit well there. But > other than that, I don't see a reason to invent so many different formatting > functions. Of course, one may do that just for fun, in which case I applaud > that. But printf(3) is superior to them, IMO. That sort of relative value judgement can be difficult to justify without specifying the criteria that goes into one's judgement. As you said, it is an opinion and that's fine, but opinions vary. :-) - Dan C. From clemc at ccc.com Fri Aug 4 07:44:24 2023 From: clemc at ccc.com (Clem Cole) Date: Thu, 3 Aug 2023 17:44:24 -0400 Subject: [TUHS] Split addressing (I/D) space (inspired by the death of the python... thread) In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <202308031657.373GvVvW008640@ultimate.com> Message-ID: Will its a C Compiler switch (-i) and create 411 files instead of 407. I like to refer to it as the 17th address bit. I was first brought out with the 11/45 (which was SSI/MSI TTL), and the biggest differences between it and the 11/40. They were both early 1970s and both of these processors were multiple boards. By 1976, the 780 has started and that sucked off most of the HW folks. A new hire in 1976, Jeff Mitchell supposedly had a bet with Bill Strecker that he could implement an 11 on a single"hex high" CPU board if he got rid of the lights and switches. He ran out of room to implement seperate I/D, so it became an 11/40 class [and it has an 8008-1 that runs the front panel]. The 11/70 came out between the 11/45 and the 34 and had a number of the STAR folks on it it original but it was also multiple boards. It was not until 11/44 that DEC was able to make a hex height implementation of the 11 that managed to cram a full 11/70 into that system. The later J-11 chip set took things beyond the 11/70. If you look at the conf directory in the sys sources for V6, you see m40.s and m45.s - but if you look at the link line of sys/run the 45 does not have -i; but if you look in sys/sys1.c you'll see the in the routine getxfile the support for 0407/0411/0405/0410 files for user mode. If you look at the conf directory in the sys sources for V7, you see mch.s and m45.s its common and the makefile adds -i ᐧ On Thu, Aug 3, 2023 at 4:35 PM Will Senn wrote: > Does unix (v7) know about the PDP-11 45's split I/D space through > configuration or is it convention and programmer's responsibility to > know and manage what's actually available? > > Will > > On 8/3/23 12:00, Rich Salz wrote: > > What, we all need something to kick now that we've beaten sendmail? > > How about something unix, ideally a decade old? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Fri Aug 4 07:48:21 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 3 Aug 2023 17:48:21 -0400 (EDT) Subject: [TUHS] Split addressing (I/D) space (inspired by the death of the python... thread) Message-ID: <20230803214821.CEE3F18C07E@mercury.lcs.mit.edu> > From: Will Senn > Does unix (v7) know about the PDP-11 45's split I/D space through > configuration or is it convention and programmer's responsibility to > know and manage what's actually available? There are two different cases: i) support of split I+D in the kernel, and ii) support of split I+D in user processes. Both arrived with V6; the V5 source: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/sys/conf/mch.s https://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/sys/ken/main.c (former for kernel; later for users) shows no sign of it. > From: Kenneth Goodwin > 1. I don't think the 11/45 had split I & d. > But I could be wrong. > That did not appear until the 11/70 You are wrong. The chief differences between the KB11-A&-D of the -11/45 and the -B&-C of the -11/70 were i) the latter had a cache, and ii) the latter used the 32-bit wide Main Memory Bus, which also allowed up to 4 Mbytes of main memory. Detail here: https://gunkies.org/wiki/PDP-11/70 along with a couple of lesser differences. > From: "Ronald Natalie" > with only 8 segment registers combined for code, data, and stack I think you meant for code, data, and user block. > The 55 (just a tweaked 45) The /50 and /55 had the identical KB11-A&-D of the /45; the difference was that they came pre-configured with Fastbus memory. > In addition the 23/24/J-11 and those derived processors did. No; the F-11 processors did not support I&D, the J-11 did. Noel From crossd at gmail.com Fri Aug 4 08:05:46 2023 From: crossd at gmail.com (Dan Cross) Date: Thu, 3 Aug 2023 18:05:46 -0400 Subject: [TUHS] python In-Reply-To: <2BF7ADB4-4851-4CF5-A6AC-0F1079D4AF78@gmail.com> References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <1f043101-4dbb-34ff-b037-85e7cc707a6e@halwitz.org> <2BF7ADB4-4851-4CF5-A6AC-0F1079D4AF78@gmail.com> Message-ID: On Thu, Aug 3, 2023 at 11:21 AM will.senn at gmail.com wrote: > Nice. I've never appreciated type checking at 'compile' time, but I understand why others might (ocd). C was my first exposure to blending types, then Perl was fuzzier, then Python was even better at pretending types didn't matter. Now, with Lisp, I am freed from type concerns... until I'm not. Thankfully, it's my choice. Types in programming languages vary across two axes: strong versus weak, and static versus dynamic. Common Lisp is strongly typed: for example, you cannot add an integer to a list, or `cons` something onto a vector (Common Lisp vectors are not lists). Indeed, exactly the former caused a production outage in a large Lisp system I worked on for about a year: someone had needed to store a pair of integers, so they used a CONS cell; after a while, the pair needed to be expanded to a triple, so someone converted the single CONS cell into a (proper) list. Consequently, the function for accessing the second value went from being CDR to CADR (or `SECOND`), but the programmer missed one place: the value of `(cdr foo)`, now a list, was passed to some function that expected a fixnum and tried to add something to it: this, of course, ran afoul of the type system and raised a condition, which resulted as an ISE in prod. The fix was trivial (change CDR to SECOND in the right place) but it really struck me that if the system were statically typed, this would have been trivially discovered at compile-time. On the other axis, Lisps are usually dynamically typed, which in this context, means that the type of a value associated with a symbol may change over time and one matters when the value is actually used. Common Lisp does allow you to declare types in some limited regards; these are usually hints to the compiler for code generation. Conversely, in statically typed languages, the type of every value is known at all times (particularly at compile time). Incidentally, this episode --- along with something similar in a Python program --- really soured me on dynamically-typed languages. The python failure was particularly maddening: it was heavily unit tested (100% coverage) but as soon as we put it out, we immediately got an error report: a type error with processing the arguments to `main` (Google had some non-standard internal libraries for that that were challenging to test). This was highly frustrating: like Rob, I greatly prefer strong, static typing. Incidentally, C is weakly (you can add a pointer to an integer: the result is another pointer), but statically typed. - Dan C. > On August 3, 2023 9:56:22 AM CDT, Dan Halbert wrote: >> >> Python has optional type annotations. There are batch tools (e.g., MyPy) to do type analysis and IDE's also provide help. Example: >> >> def greeting(name: str) -> str: >> return 'Hello ' + name >> >> I found Python to be an enormous improvement over Perl for writing the kinds of things I used to write in Perl, with the Perl book at my side. I currently make my living working on Python for microcontrollers. Neverthless, I am fond of type checking too, and if I were writing a large Python system, I would use type annotations. >> >> I have used BCPL too, in the 70's, and we achieved some measure of type safety by careful naming. >> >> Dan H. >> >> On 8/3/23 10:19, Bakul Shah wrote: >> >> I have not heard such horror stories about Common Lisp (or may be I have forgotten them!). My impression is that python doesn't quite have the kind of {meta,}programming tools Common Lisp has. CL has been used for large critical programs. Perhaps Von Rossum had more experience with statically typed languages than Lisp (because -- pure speculation here -- if he had used CL enough, he would never have designed python :-) >> >> On Aug 3, 2023, at 1:32 AM, Rob Pike wrote: >> >> I once inherited maintenance of a critical piece of infrastructure written in exquisitely well written, tested, and documented Python. I mean it, it was really really good. >> >> It crashed about once a week and I had to fix it over and over because in those exponentially vast combinations of paths through the code would arise yet another way to turn a string into a list, or something analogous. It was hell. >> >> Critical code needs static typing. >> >> -rob >> >> >> On Thu, Aug 3, 2023 at 1:56 PM Bakul Shah wrote: >>> >>> python can certainly implement tail call optimization (TCO). Pretty much any language can implement TCO but for some reason people think such programs are harder to debug (and yet they don't similarly complain about loops!). The beauty of Scheme was that it *mandated* tail recursion. >>> >>> > On Aug 2, 2023, at 8:24 PM, George Michaelson wrote: >>> > >>> > Tail recursion not lazy eval. >>> > >>> > I wish words meant what I meant "inside" when I think them, not >>> > "outside" what they mean when I write them. >>> >> >> > -- Sent from /e/OS Mail. From will.senn at gmail.com Fri Aug 4 08:08:58 2023 From: will.senn at gmail.com (Will Senn) Date: Thu, 3 Aug 2023 17:08:58 -0500 Subject: [TUHS] Split addressing (I/D) space (inspired by the death of the python... thread) In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <202308031657.373GvVvW008640@ultimate.com> Message-ID: Clem, Oh, so... Without I/D, you're stuck with 64k max per process, with I/D, you can use 64k for I and 64k for D. Was that it, or were there other tricks to get even more allocated (didn't the 11 max out at 256k)? The kernel could be compiled either with, or without separate I/D. The only reason not to is if you didn't have more then 64k or were there other reasons? So, besides the kernel what apps tended to be split? If I remember correctly, vi was one, pascal another? Thanks! Will On 8/3/23 16:44, Clem Cole wrote: > Will its a C Compiler switch (-i) and create 411 files instead of 407. > I like to refer to it as the 17th address bit. > > I was first brought out with the 11/45 (which was SSI/MSI TTL), and > the biggest differences between it and the 11/40.  They were both > early 1970s and both of these processors were multiple boards. By > 1976, the 780 has started and that sucked off most of the HW folks.  >  A new hire in 1976, Jeff Mitchell supposedly had a bet with Bill > Strecker that he could implement an 11 on a single"hex high" CPU board > if he got rid of the lights and switches.  He ran out of room to > implement seperate I/D, so it became an 11/40 class [and it has an > 8008-1 that runs the front panel]. > > The 11/70 came out between the 11/45 and the 34 and had a number of > the STAR folks on it it original but it was also multiple boards.   It > was not until 11/44 that DEC was able to make a hex height > implementation of the 11 that managed to cram a full 11/70 into that > system.   The later J-11 chip set took things beyond the 11/70. > > If you look at the conf directory in the sys sources for V6, you see > m40.s and m45.s - but if you look at the link line of sys/run the 45 > does not have -i; but if you look in sys/sys1.c you'll see the in the > routine getxfile the support for 0407/0411/0405/0410 files for user mode. > > If you look at the conf directory in the sys sources for V7, you see > mch.s and m45.s  its common and the makefile adds -i > > ᐧ > > On Thu, Aug 3, 2023 at 4:35 PM Will Senn wrote: > > Does unix (v7) know about the PDP-11 45's split I/D space through > configuration or is it convention and programmer's responsibility to > know and manage what's actually available? > > Will > > On 8/3/23 12:00, Rich Salz wrote: > > What, we all need something to kick now that we've beaten sendmail? > > How about something unix, ideally a decade old? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennethgoodwin56 at gmail.com Fri Aug 4 08:34:23 2023 From: kennethgoodwin56 at gmail.com (Kenneth Goodwin) Date: Thu, 3 Aug 2023 18:34:23 -0400 Subject: [TUHS] Split addressing (I/D) space (inspired by the death of the python... thread) In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <202308031657.373GvVvW008640@ultimate.com> Message-ID: Having worked on the v6 kernel on the 11/70 it was split on that version on that hardware. On Thu, Aug 3, 2023, 5:10 PM Ronald Natalie wrote: > Having cut my UNIX teeth on the JHU 11/45, I can tell you very much that > it did have split I/D. V6 supported split I/D for user mode programs. > The kernel originally wasn’t split I/D. Version 7, if I’m recalling > properly, did run the kernel split I/D on the 45 and 70. > > > > ------ Original Message ------ > From "Kenneth Goodwin" > To "Will Senn" > Cc "The Eunuchs Hysterical Society" > Date 8/3/23, 5:05:31 PM > Subject [TUHS] Re: Split addressing (I/D) space (inspired by the death of > the python... thread) > > At the risk of exposing my ignorance and thus being events long long ago > in history.... > And my mind now old and feeble... > > 😆 🤣 > > 1. I don't think the 11/45 had split I & d. > But I could be wrong. > That did not appear until the 11/70 > And was in the later generation 11/44 several years later. > > 2. The kernel determined it by MMU type and managed it solely. The > assembler and loader always built the binary object file as the three > sections - instructions, data and bss spaces so loading an object file > could be done on any platform. > Programmers generally did not worry about the underlying hardware > > 3. I don't recall if a systype style system call was available in v7 to > give you a machine type to switch off of. > > With something like that you could determine memory availability hard > limits on the DATA/bss side if you needed to. > > But that was also easily determined by a allocation failure in malloc/sbrk > with an out of memory error. > > If you really needed to know availability, you could have a start up > subroutine that would loop trying to malloc ever decreasing memory sizes > until success and until out of available memory error. > Then release it all back via free(). Or manage it internally. > > As I recall however vaguely, there was an attempt to split the kernel > into two pieces. One running in kernel mode and one running in supervisor > mode in order to double the amount of available instruction and data > spaces for the operating system. I recall playing around with what was > there trying to get it to work right. > I was trying to support over 200 users on a pdp 11/70 at the time running > a massive insurance database system. > > On Thu, Aug 3, 2023, 4:35 PM Will Senn wrote: > >> Does unix (v7) know about the PDP-11 45's split I/D space through >> configuration or is it convention and programmer's responsibility to >> know and manage what's actually available? >> >> Will >> >> On 8/3/23 12:00, Rich Salz wrote: >> > What, we all need something to kick now that we've beaten sendmail? >> > How about something unix, ideally a decade old? >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Aug 4 08:54:02 2023 From: clemc at ccc.com (Clem Cole) Date: Thu, 3 Aug 2023 18:54:02 -0400 Subject: [TUHS] Split addressing (I/D) space (inspired by the death of the python... thread) In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <202308031657.373GvVvW008640@ultimate.com> Message-ID: ᐧ below... [and I meant to answer the second ½ of your question before] On Thu, Aug 3, 2023 at 6:09 PM Will Senn wrote: > Clem, > > Oh, so... Without I/D, you're stuck with 64k max per process, with I/D, > you can use 64k for I and 64k for D. > Exactly but ... more in a minute. > Was that it, or were there other tricks to get even more allocated (didn't > the 11 max out at 256k)? > Different issues... the MMU on the 40 class and the 45/55 allows 256K [18 bits], the MMU for the 70 class is 4M [22 bits], Unibus I/O controllers had 18 bits of address and RH70 controllers could support 22 bits of extended addresses - see the processor and peripheral handbooks for details [or I can explain offline]. What the PDP-11 books calls 'pages' are 64-byte segments. So the MMU is set up to allow the processor to address 64K or 64KI/64KD at the time, depending on if you have the I/D hardware, and the MMU is set up as to which 'pages' are being addressed. But you could overlay things ... [0405 files] with 'thunks'. So to allow a process (or the kernel) to have more than 64K, overlays can be loaded into memory and since the total physical space memory space is either 18 or 22 bits, if the kernel supports overlays - processes could get bigger [which is part of your first question]. V7 was when 0405 [text only] overlays were added. With DEC's release of v7m - Fred Cantor rewrote the overlay code and they became more general [and that would go into 2.9BSD]. So the programmer needs to decide what you wanted to put into what overlay. For processes, the kernel can swap out segments and replace them as needed. The key is that link needs to generate near/far style calls and it can be a PITA. If you want to access a routine that is not currently mapped into memory, the 'thunk' needs to ask the OS to switch it. Great thought of what was going to be stored where. > > The kernel could be compiled either with, or without separate I/D. The > only reason not to is if you didn't have more then 64k or were there other > reasons? > Well by V6, UNIX needed at least 64K of physical memory and it was really slow with anything less than 256K. For the kernel, using I/D allowed the kernel to grow more easily. By the time of trying to cram networking into it, running on anything less than an 11/44 was pretty hard. That said, Able made an alternate MMU called the ENABLE that allow 4M of memory on a Unibus system. It worked at a cache/bus repeater. So you set the internal MMU to point to it and then use its MMU. Very cool and a soft spot for me. I ran an 11/60 [which is 40 class] with 2M of memory in Teklabs with the first Enable board. For whatever its worth, even with 4M the kernel had started to become a problem for V7 on an 11/70. Data buffers eat a lot of memory. > > So, besides the kernel what apps tended to be split? If I remember > correctly, vi was one, pascal another? > Anything that started to get big ;-) Ppeople ran out of data space and text space from 64K fairly fast. With the 32-bit Vax, the UNIX Small is Beautiful thinking started to fall away. Rob has an excellent paper -> "cat -v considered harmful" BSD UNIX, and the Vaxen greatly fueled that. Adding features and thinking less about what functionality was really needed started to get lost [so now we have Gnu - but I digress]. Werner and the BSD 2.9 folks are to be commended for what they did with so few resources. They moved things back from the Vax by using the overlays, but if you were to have any semblance of performance, you need the overlays to stay resident so you need that full 4M of memory. As for this specific question first two subsystems for the 11 that ran out of text space were indeed vi and Pascal subsystems (Joy having had his hand in both, BTW). But they were hardly the only ones once the genie was out of the bottle. Data space quickly became the real issue. People really wanted larger heaps in particular. In fact, by the 1990s, I knew of few programs that run out of 32-bit worth of text space, but many that started to run out of 32-bits of data space -> hence Alpha. But BTW: DEC took a performance hit originally, and there was a huge discussion at the time if 64-bits was really needed. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Fri Aug 4 09:08:55 2023 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 4 Aug 2023 09:08:55 +1000 (EST) Subject: [TUHS] Split addressing (I/D) space (inspired by the death of the python... thread) In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <202308031657.373GvVvW008640@ultimate.com> Message-ID: On Thu, 3 Aug 2023, Clem Cole wrote: > For whatever its worth, even with 4M the kernel had started to become a > problem for V7 on an 11/70.  Data buffers eat a lot of memory. We at UNSW had a kludge for that; the global symbol "b" (similar to "u") was mapped by KISA5 into the current buffer header. Having dozens of buffers on a 40-class machine was really something... -- Dave From jnc at mercury.lcs.mit.edu Fri Aug 4 09:10:44 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 3 Aug 2023 19:10:44 -0400 (EDT) Subject: [TUHS] Split addressing (I/D) space (inspired by the death of the python... thread) Message-ID: <20230803231044.2B4AB18C080@mercury.lcs.mit.edu> > From: Clem Cole > A new hire in 1976, Jeff Mitchell supposedly had a bet with Bill > Strecker that he could implement an 11 on a single"hex high" CPU board > if he got rid of the lights and switches. He ran out of room to > implement seperate I/D, so it became an 11/40 class [and it has an > 8008-1 that runs the front panel]. I don't know about the Strecker story, but the first PDP-11 CPU on a single card (a hex card) was the KD11-D: https://gunkies.org/wiki/KD11-D_CPU of the -11/04. It didn't have _any_ memory management, though (or a front panel; to get that, you had to use the KY"11-LB: https://gunkies.org/wiki/KY11-LB_Programmer%27s_Console which added another quad card). The first -11 CPU i) on a single card and ii) with memory management was the FDF11-A: https://gunkies.org/wiki/KDF11-A_CPU The first -11 CPU i) on a single card and ii) with split I+D memory management was the KDJ11-A. > It was not until 11/44 that DEC was able to make a hex height > implementation of the 11 that managed to cram a full 11/70 into that > system. I'm not sure what your point is here? The KD11-Z CPU of the -11/44: https://gunkies.org/wiki/KD11-Z_CPU was a _minimum_ of five hex boards; a little smaller than a KB11-B (15 hex cards). Floating point was an extra card; CIS was 2 more. > if you look at the link line of sys/run the 45 does not have -i Split I+D for the kernel was not supported by the linker in V6; a combination of 'sysfix' (a special post-processor, which took as input a relocatable linked image) and code in m45.s was needed. https://gunkies.org/wiki/Upgrading_UNIX_Sixth_Edition https://gunkies.org/wiki/UNIX_V6_memory_layout The code in m45.s to handle split I+D in the kernel: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/conf/m45.s starts at 'start:' and is adequately commented to tell you what it's doing when it plays around with kernel memory. > From: Will Senn > with I/D, you can use 64k for I and 64k for D. Was that it, or were > there other tricks to get even more allocated I have this vague memory that someone (Berkeley, I think?) added support for automatic code overlays in user processes. The programmer had to decide which modules went in which overlays, but after that it was all automagic. There was a 4xx code allocated to them. I think the support for that (in e.g. the linker) was somehow involved with the use of overlays in the kernel, but I don't know the details (nothing after V6 is at all interesting to me). > didn't the 11 max out at 256k)? You need to distinguish between i) the amount of memory the machine could handle, and ii) the amount of memory that running code could 'see' at any instant. The latter was always either 64KB, or 64KB+64KB (with split I+D turned on, on CPUs which supported it). The former, it's complicated. Mostly, on UNIBUS only machines, it was 256KB. (Although there was the Able ENABLE: https://gunkies.org/wiki/Able_ENABLE which added an Extended UNIBUS, and could take them up to 4MB.) The -11/70, as mentioned, had a Main Memory Bus, and could handle up to 4MB. The -11/44 had an Extended UNIBUS, and could also handle up to 4MB (but only after the MS11-P became available; there were only 4 main memory slots in the backplane, and MS11-M cards were only 256KB.) On QBUS achines, after the KB11-A (Revision A), which only suppported 256 KB, all later revisions and CPUs could also handle up to 4MB. Noel From steve at quintile.net Fri Aug 4 09:14:35 2023 From: steve at quintile.net (Steve Simon) Date: Fri, 4 Aug 2023 00:14:35 +0100 Subject: [TUHS] Split addressing (I/D) space (inspired by the death of the python... thread) Message-ID: <1746F115-5095-497A-A477-2C69ECDB881D@quintile.net> not quite split i and d but i do have a memory of some code which could run in three parts as overlays. this could have been through exec’ing the next overlay with an appropriate argv and a pipe or file of data, or, perhaps there was some kernel support for overlays in early unix. anyone seen evidence of this? sadly i cannot remember where i saw it, i want to say it was a versatex printer driver but i am pretty sure that is rubbish. -Steve From clemc at ccc.com Fri Aug 4 09:15:16 2023 From: clemc at ccc.com (Clem Cole) Date: Thu, 3 Aug 2023 19:15:16 -0400 Subject: [TUHS] Split addressing (I/D) space (inspired by the death of the python... thread) In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <202308031657.373GvVvW008640@ultimate.com> Message-ID: I probably should add one more thing... RT11 and RSX, and in particular the DEC FTN compiler, supported thunks and overlays - i.e. larger-sized programs before UNIX did. IIRC, they needed them because by then the FTN subsystem needed overlays to run itself. So .. assuming my memory is correct, this was the reason why Fred rewrote the V7 code, and DEC pushed it out as part of the v7m release. Ken's original overlay support code was not sufficient for the DEC language tools. I don't remember if Ultrix-11 or v7m for that matter, ultimately got the FTN compiler. That said, Paul W might remember as he did the linker work for Ultrix moving the VMS linker to Ultrix to support the 'Technical Languages Group' (TLG ). Utrix-32 certainly did get FTN I think a couple of other of the RSX and RSTS languages, but my memory of Fred's work was to support overlays in V7 so it could support it. This was all during the Unix wars inside of DEC. Fred was part of the 'Telephone Industries Group' (TIG) in MRK. ᐧ On Thu, Aug 3, 2023 at 6:54 PM Clem Cole wrote: > > ᐧ > below... [and I meant to answer the second ½ of your question before] > > On Thu, Aug 3, 2023 at 6:09 PM Will Senn wrote: > >> Clem, >> >> Oh, so... Without I/D, you're stuck with 64k max per process, with I/D, >> you can use 64k for I and 64k for D. >> > Exactly but ... more in a minute. > > > > >> Was that it, or were there other tricks to get even more allocated >> (didn't the 11 max out at 256k)? >> > Different issues... the MMU on the 40 class and the 45/55 allows 256K [18 > bits], the MMU for the 70 class is 4M [22 bits], Unibus I/O controllers > had 18 bits of address and RH70 controllers could support 22 bits of > extended addresses - see the processor and peripheral handbooks for details > [or I can explain offline]. > > What the PDP-11 books calls 'pages' are 64-byte segments. So the MMU is > set up to allow the processor to address 64K or 64KI/64KD at the time, > depending on if you have the I/D hardware, and the MMU is set up as to > which 'pages' are being addressed. > > But you could overlay things ... [0405 files] with 'thunks'. > > So to allow a process (or the kernel) to have more than 64K, overlays can > be loaded into memory and since the total physical space memory space is > either 18 or 22 bits, if the kernel supports overlays - processes could get > bigger [which is part of your first question]. > V7 was when 0405 [text only] overlays were added. With DEC's release of > v7m - Fred Cantor rewrote the overlay code and they became more general > [and that would go into 2.9BSD]. > > So the programmer needs to decide what you wanted to put into what > overlay. For processes, the kernel can swap out segments and replace them > as needed. The key is that link needs to generate near/far style calls > and it can be a PITA. If you want to access a routine that is not > currently mapped into memory, the 'thunk' needs to ask the OS to switch it. > Great thought of what was going to be stored where. > > > > >> >> The kernel could be compiled either with, or without separate I/D. The >> only reason not to is if you didn't have more then 64k or were there other >> reasons? >> > Well by V6, UNIX needed at least 64K of physical memory and it was really > slow with anything less than 256K. For the kernel, using I/D allowed the > kernel to grow more easily. By the time of trying to cram networking into > it, running on anything less than an 11/44 was pretty hard. > > That said, Able made an alternate MMU called the ENABLE that allow 4M of > memory on a Unibus system. It worked at a cache/bus repeater. So you set > the internal MMU to point to it and then use its MMU. Very cool and a > soft spot for me. I ran an 11/60 [which is 40 class] with 2M of memory in > Teklabs with the first Enable board. > > For whatever its worth, even with 4M the kernel had started to become a > problem for V7 on an 11/70. Data buffers eat a lot of memory. > >> >> So, besides the kernel what apps tended to be split? If I remember >> correctly, vi was one, pascal another? >> > Anything that started to get big ;-) > > Ppeople ran out of data space and text space from 64K fairly fast. With > the 32-bit Vax, the UNIX Small is Beautiful thinking started to fall away. > Rob has an excellent paper -> "cat -v considered harmful" BSD UNIX, and > the Vaxen greatly fueled that. Adding features and thinking less about > what functionality was really needed started to get lost [so now we have > Gnu - but I digress]. Werner and the BSD 2.9 folks are to be commended for > what they did with so few resources. They moved things back from the Vax > by using the overlays, but if you were to have any semblance of > performance, you need the overlays to stay resident so you need that full > 4M of memory. > > As for this specific question first two subsystems for the 11 that ran out > of text space were indeed vi and Pascal subsystems (Joy having had his hand > in both, BTW). But they were hardly the only ones once the genie was out > of the bottle. Data space quickly became the real issue. People really > wanted larger heaps in particular. In fact, by the 1990s, I knew of few > programs that run out of 32-bit worth of text space, but many that > started to run out of 32-bits of data space -> hence Alpha. But BTW: > DEC took a performance hit originally, and there was a huge discussion at > the time if 64-bits was really needed. > ᐧ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Fri Aug 4 09:42:09 2023 From: imp at bsdimp.com (Warner Losh) Date: Thu, 3 Aug 2023 17:42:09 -0600 Subject: [TUHS] Split addressing (I/D) space (inspired by the death of the python... thread) In-Reply-To: <20230803231044.2B4AB18C080@mercury.lcs.mit.edu> References: <20230803231044.2B4AB18C080@mercury.lcs.mit.edu> Message-ID: On Thu, Aug 3, 2023, 5:10 PM Noel Chiappa wrote: > > From: Clem Cole > > > A new hire in 1976, Jeff Mitchell supposedly had a bet with Bill > > Strecker that he could implement an 11 on a single"hex high" CPU > board > > if he got rid of the lights and switches. He ran out of room to > > implement seperate I/D, so it became an 11/40 class [and it has an > > 8008-1 that runs the front panel]. > > I don't know about the Strecker story, but the first PDP-11 CPU on a single > card (a hex card) was the KD11-D: > > https://gunkies.org/wiki/KD11-D_CPU > > of the -11/04. It didn't have _any_ memory management, though (or a front > panel; to get that, you had to use the KY"11-LB: > > https://gunkies.org/wiki/KY11-LB_Programmer%27s_Console > > which added another quad card). The first -11 CPU i) on a single card and > ii) with memory management was the FDF11-A: > > https://gunkies.org/wiki/KDF11-A_CPU > > The first -11 CPU i) on a single card and ii) with split I+D memory > management was the KDJ11-A. > > > > It was not until 11/44 that DEC was able to make a hex height > > implementation of the 11 that managed to cram a full 11/70 into that > > system. > > I'm not sure what your point is here? The KD11-Z CPU of the -11/44: > > https://gunkies.org/wiki/KD11-Z_CPU > > was a _minimum_ of five hex boards; a little smaller than a KB11-B (15 hex > cards). Floating point was an extra card; CIS was 2 more. > > > > if you look at the link line of sys/run the 45 does not have -i > > Split I+D for the kernel was not supported by the linker in V6; a > combination > of 'sysfix' (a special post-processor, which took as input a relocatable > linked image) and code in m45.s was needed. > > https://gunkies.org/wiki/Upgrading_UNIX_Sixth_Edition > https://gunkies.org/wiki/UNIX_V6_memory_layout > > The code in m45.s to handle split I+D in the kernel: > > https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/conf/m45.s > > starts at 'start:' and is adequately commented to tell you what it's doing > when it plays around with kernel memory. > > > > > From: Will Senn > > > with I/D, you can use 64k for I and 64k for D. Was that it, or were > > there other tricks to get even more allocated > > I have this vague memory that someone (Berkeley, I think?) added support > for > automatic code overlays in user processes. The programmer had to decide > which > modules went in which overlays, but after that it was all automagic. There > was a 4xx code allocated to them. > > I think the support for that (in e.g. the linker) was somehow involved with > the use of overlays in the kernel, but I don't know the details (nothing > after V6 is at all interesting to me). > V7 had a number of patches for MENLO_LINKER or MENLO_OVERLAY that Berkeley integrated into the tree, but I'm not sure they wrote it. Their hacks were usually UCB_something... Warner > didn't the 11 max out at 256k)? > > You need to distinguish between i) the amount of memory the machine could > handle, and ii) the amount of memory that running code could 'see' at any > instant. The latter was always either 64KB, or 64KB+64KB (with split I+D > turned on, on CPUs which supported it). > > The former, it's complicated. Mostly, on UNIBUS only machines, it was > 256KB. > (Although there was the Able ENABLE: > > https://gunkies.org/wiki/Able_ENABLE > > which added an Extended UNIBUS, and could take them up to 4MB.) The -11/70, > as mentioned, had a Main Memory Bus, and could handle up to 4MB. The -11/44 > had an Extended UNIBUS, and could also handle up to 4MB (but only after the > MS11-P became available; there were only 4 main memory slots in the > backplane, and MS11-M cards were only 256KB.) On QBUS achines, after the > KB11-A (Revision A), which only suppported 256 KB, all later revisions and > CPUs could also handle up to 4MB. > > Noel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Fri Aug 4 09:47:02 2023 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 3 Aug 2023 16:47:02 -0700 Subject: [TUHS] [TULSA] Re: python In-Reply-To: <202308031657.373GvVvW008640@ultimate.com> References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <202308031657.373GvVvW008640@ultimate.com> Message-ID: <20230803234702.GC11023@mcvoy.com> On Thu, Aug 03, 2023 at 12:57:31PM -0400, Phil Budne wrote: > On the subject of "no printf", there is not one, not two, but THREE > ways to format strings, easily compounded with print: > > print("%s %s" % ("hello", "world")) > print("{1} {two}".format("hello", two="world")) > print(f"{greeting} {populace}") > > I'm pretty sure the last method (which initially made me vomit, due to All of those make me vomit. Pretty much every sane language has printf. From will.senn at gmail.com Fri Aug 4 09:54:33 2023 From: will.senn at gmail.com (Will Senn) Date: Thu, 3 Aug 2023 18:54:33 -0500 Subject: [TUHS] [TULSA] Re: python In-Reply-To: <20230803234702.GC11023@mcvoy.com> References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <202308031657.373GvVvW008640@ultimate.com> <20230803234702.GC11023@mcvoy.com> Message-ID: On 8/3/23 18:47, Larry McVoy wrote: > On Thu, Aug 03, 2023 at 12:57:31PM -0400, Phil Budne wrote: >> On the subject of "no printf", there is not one, not two, but THREE >> ways to format strings, easily compounded with print: >> >> print("%s %s" % ("hello", "world")) >> print("{1} {two}".format("hello", two="world")) >> print(f"{greeting} {populace}") >> >> I'm pretty sure the last method (which initially made me vomit, due to > All of those make me vomit. Pretty much every sane language has printf. Tell us how you really feel :). But, I couldn't agree more. I worked really hard to get printf and sprintf down and then folks started doing it "right" and "better" or renaming it but watering it down - ugh! I say, we picket. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alx.manpages at gmail.com Fri Aug 4 09:55:22 2023 From: alx.manpages at gmail.com (Alejandro Colomar) Date: Fri, 4 Aug 2023 01:55:22 +0200 Subject: [TUHS] printf (was: python) In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <202308031657.373GvVvW008640@ultimate.com> <8e45b8b1-cf3c-e47c-bd15-d19a2ae5cc1d@gmail.org> Message-ID: <5dd50d2c-0049-31bf-8975-08ed899a9387@gmail.org> Hi Dan, On 2023-08-03 23:29, Dan Cross wrote: > On Thu, Aug 3, 2023 at 2:05 PM Alejandro Colomar wrote: >> On 2023-08-03 19:51, John Cowan wrote: >>> On Thu, Aug 3, 2023 at 1:29 PM Alejandro Colomar >>> wrote: >>> >>> But if speed is not a problem, I'd keep the good ol' syntax that >>> >>> everybody knows. No need to make everybody learn a "cool" new print >>>> function, that probably won't be as tunable as printf(3) is. >>>> >>>> >>> By that argument, there would be no C, only Algol 68 and PL/I, or subsets >>> of them. >>> >> >> I didn't claim that there's never a reason to invent new syntax. My claim >> was rather that in this case, there isn't. >> >> - printf(3) is more powerful than any other existing formatting function >> that I know of any language --I'm still curious of what's the equivalent >> of "%+'0#8.5f" in other formatting functions--. > > One issue is that this isn't standard C: the `'` verb for grouping by > thousands is an SUSv2 extension. I just checked the latest C23 draft, > and unless I missed it, it doesn't appear to have made it in. Being in POSIX.1 it's portable to most (all?) current systems. ISO C is a baseline for an implementation. A quality implementation will go beyond that standard (or will be rather useless). POSIX.1 is more of a useful thing. But yeah, we can remove that "'" to get the idea. > > But things like that are fairly straight-forward in many other > languages. For example, in Go, the format string is nearly identical, > modulo the `'`: Yup; I like go in that sense. [...] > >> - It is also reasonably fast (at least for such a highly-customizable >> formatting function), and I'd like to see any system beat that while >> keeping the customizability. > > At Google, a group of exceptionally talented engineers wrote a > replacement in C++ for both type safety and because, bluntly, `printf` > (actually `snprintf`) was too slow. I believe the overall mechanism > made it into ABSL. I think you mean absl::StrFormat(). It has printf(3)-like syntax, so I can't say say much against it. I don't know the details of how they achieved the claimed 2x ~ 3x performance compared to snprintf(3). I'm curious to know if it's an inherent limitation of snprintf(3), or if it's just that glibc is very unoptimized --which is true anyway, because no-one has really maintained the printf(3) code in a long time--. It's interesting, because then std::format() is not that miraculous compared to snprintf(3). > >> - It is type-safe, with the right tools. > > No it's not, and it really can't be. True, there are linters that can > try to match up types _if_ the format string is a constant and all the > arguments are known at e.g. compile time, but C permits one to > construct the format string at run time (or just select between a > bunch of variants); the language gives you no tools to enforce type > safety in a meaningful way once you do that. Isn't a variable format string a security vulnerability? Where do you need it? Thanks, Alex From will.senn at gmail.com Fri Aug 4 10:04:44 2023 From: will.senn at gmail.com (Will Senn) Date: Thu, 3 Aug 2023 19:04:44 -0500 Subject: [TUHS] emacs Message-ID: As a longtime user and lover of ed/ex/vi, I don't know much about emacs, but lately I've been using it more (as it seems like any self-respecting lisper, has to at least have a passing acquaintance with it). I recently went off and got MACLISP running in ITS. As part of that exploration, I used EMACS, but not just any old emacs, emacs in it's first incarnation as a set of TECO macros. To me, it just seemed like EMACS. I won't bore you with the details - imagine lots of control and escape sequences, many of which are the same today as then. This was late 70's stuff. My question for the group is - when did emacs arrive in unix and was it a full fledged text editor when it came or was it sitting on top of some other subssystem in unix? Was TECO ever on unix? Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Fri Aug 4 10:13:28 2023 From: will.senn at gmail.com (Will Senn) Date: Thu, 3 Aug 2023 19:13:28 -0500 Subject: [TUHS] 3bsd tape image Message-ID: Hi All, Is this the only bootable 3bsd distribution tape we have? http://sourceforge.net/projects/bsd42/files/Install%20tapes/3%20BSD/3bsd.tap.bz2/download I don't like the idea that sourceforge is the only source, the provenance is unclear and I'm just not a big fan of how sourceforge handles downloads generally. I've found tarballs, but not tapes on TUHS. Thanks, Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Fri Aug 4 10:19:10 2023 From: athornton at gmail.com (Adam Thornton) Date: Thu, 3 Aug 2023 17:19:10 -0700 Subject: [TUHS] emacs In-Reply-To: References: Message-ID: There are certainly teco implementations for Unix, although I don't know if it was ever anyone's default editor anywhere. Indeed, there are multiple implementations: I switched from a C teco implementation to pyteco in the Rubin Science Platform JupyterLab implementation (its utility is of course dubious, but this is part of both my nefarious plan to make Jupyter not merely mean "Julia, Python, and R", but to use that "e" -- and reassociate it with the "t" -- by making it mean "Julia, Python, Teco, and R", and also to include an easter egg for a fellow project member who is a teco fan). The first Emacs I used was GNU emacs at already version...16 or something? In 1989, on ... I don't remember what the main system I used at the UT Austin Chaos Lab was, actually; we had an SGI Iris, but that wasn't the machine I did my editing on. But by 1989 it was certainly well-available and established. On Thu, Aug 3, 2023 at 5:04 PM Will Senn wrote: > As a longtime user and lover of ed/ex/vi, I don't know much about emacs, > but lately I've been using it more (as it seems like any self-respecting > lisper, has to at least have a passing acquaintance with it). I recently > went off and got MACLISP running in ITS. As part of that exploration, I > used EMACS, but not just any old emacs, emacs in it's first incarnation as > a set of TECO macros. To me, it just seemed like EMACS. I won't bore you > with the details - imagine lots of control and escape sequences, many of > which are the same today as then. This was late 70's stuff. > > My question for the group is - when did emacs arrive in unix and was it a > full fledged text editor when it came or was it sitting on top of some > other subssystem in unix? Was TECO ever on unix? > > Will > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Fri Aug 4 10:24:01 2023 From: cowan at ccil.org (John Cowan) Date: Thu, 3 Aug 2023 20:24:01 -0400 Subject: [TUHS] python In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <1f043101-4dbb-34ff-b037-85e7cc707a6e@halwitz.org> <2BF7ADB4-4851-4CF5-A6AC-0F1079D4AF78@gmail.com> Message-ID: On Thu, Aug 3, 2023 at 6:06 PM Dan Cross wrote: > On Thu, Aug 3, 2023 at 11:21 AM will.senn at gmail.com > wrote: > > someone had needed to store a > pair of integers, so they used a CONS cell; Of course, that was a bad idea. The pair of integers should have been a struct or a class named after whatever its application-level purpose was: a point, for example. after a while, the pair > needed to be expanded to a triple, so someone converted the single > CONS cell into a (proper) list. In that case, a derived struct or class should have been created. The two classes would use the same accessor methods, just as in C++. this, of course, ran afoul of the type system and > raised a condition, which resulted as an ISE in prod. The fix was > trivial (change CDR to SECOND in the right place) but it really struck > me that if the system were statically typed, this would have been > trivially discovered at compile-time. > Absolutely, and if the failure was intolerable, CL's static type declarations would have caught the use of the wrong type. But you don't have to declare *everything*. For that matter, there is nothing in a fully statically typed system that requires every variable, function, argument, etc. to be *declared*: type inference is powerful. Common Lisp does allow you to declare types in some limited regards; > these are usually hints to the compiler for code generation. > They may or may not be, depending on how you set the OPTIMIZE declaration. > like Rob, I > greatly prefer strong, static typing. > Then why weren't you using mypy? > Incidentally, C is weakly (you can add a pointer to an integer: the > result is another pointer), but statically typed. > That's not weak typing, it's operator overloading, just as when you add an int to a double. C will not let you, e.g., add an int to a function. Weak typing is quite rare in high-level languages: PL/I pointer variables are weakly typed (that is, when you allocate an object you specify the type of the object and then assign it to the pointer variable), but the rest of the language is strongly typed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Fri Aug 4 10:27:52 2023 From: robpike at gmail.com (Rob Pike) Date: Fri, 4 Aug 2023 10:27:52 +1000 Subject: [TUHS] emacs In-Reply-To: References: Message-ID: There was a guy in production at Google using Unix TECO as his main editor when I joined in 2002. He was astonished that I recognized it, but I had used TECO in the early 1970s and, although I had no desire to return to it, I did know it well enough to exclaim its presence when watching over his shoulder. So yes, apologies for not remembering his name, but it was at least one person's default editor. -rob On Fri, Aug 4, 2023 at 10:19 AM Adam Thornton wrote: > There are certainly teco implementations for Unix, although I don't know > if it was ever anyone's default editor anywhere. Indeed, there are > multiple implementations: I switched from a C teco implementation to pyteco > in the Rubin Science Platform JupyterLab implementation (its utility is of > course dubious, but this is part of both my nefarious plan to make Jupyter > not merely mean "Julia, Python, and R", but to use that "e" -- and > reassociate it with the "t" -- by making it mean "Julia, Python, Teco, and > R", and also to include an easter egg for a fellow project member who is a > teco fan). > > The first Emacs I used was GNU emacs at already version...16 or > something? In 1989, on ... I don't remember what the main system I used at > the UT Austin Chaos Lab was, actually; we had an SGI Iris, but that wasn't > the machine I did my editing on. But by 1989 it was certainly > well-available and established. > > On Thu, Aug 3, 2023 at 5:04 PM Will Senn wrote: > >> As a longtime user and lover of ed/ex/vi, I don't know much about emacs, >> but lately I've been using it more (as it seems like any self-respecting >> lisper, has to at least have a passing acquaintance with it). I recently >> went off and got MACLISP running in ITS. As part of that exploration, I >> used EMACS, but not just any old emacs, emacs in it's first incarnation as >> a set of TECO macros. To me, it just seemed like EMACS. I won't bore you >> with the details - imagine lots of control and escape sequences, many of >> which are the same today as then. This was late 70's stuff. >> >> My question for the group is - when did emacs arrive in unix and was it a >> full fledged text editor when it came or was it sitting on top of some >> other subssystem in unix? Was TECO ever on unix? >> >> Will >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Fri Aug 4 10:32:26 2023 From: imp at bsdimp.com (Warner Losh) Date: Thu, 3 Aug 2023 18:32:26 -0600 Subject: [TUHS] emacs In-Reply-To: References: Message-ID: On Thu, Aug 3, 2023, 6:19 PM Adam Thornton wrote: > There are certainly teco implementations for Unix, although I don't know > if it was ever anyone's default editor anywhere. Indeed, there are > multiple implementations: I switched from a C teco implementation to pyteco > in the Rubin Science Platform JupyterLab implementation (its utility is of > course dubious, but this is part of both my nefarious plan to make Jupyter > not merely mean "Julia, Python, and R", but to use that "e" -- and > reassociate it with the "t" -- by making it mean "Julia, Python, Teco, and > R", and also to include an easter egg for a fellow project member who is a > teco fan). > > The first Emacs I used was GNU emacs at already version...16 or > something? In 1989, on ... I don't remember what the main system I used at > the UT Austin Chaos Lab was, actually; we had an SGI Iris, but that wasn't > the machine I did my editing on. But by 1989 it was certainly > well-available and established. > We used some stripped down emacs in 1985 on the vax 11/750 running 4.2bsd. I built micro emacs for my DEC Rainbow under MS-DOS in the same time period... Warner On Thu, Aug 3, 2023 at 5:04 PM Will Senn wrote: > >> As a longtime user and lover of ed/ex/vi, I don't know much about emacs, >> but lately I've been using it more (as it seems like any self-respecting >> lisper, has to at least have a passing acquaintance with it). I recently >> went off and got MACLISP running in ITS. As part of that exploration, I >> used EMACS, but not just any old emacs, emacs in it's first incarnation as >> a set of TECO macros. To me, it just seemed like EMACS. I won't bore you >> with the details - imagine lots of control and escape sequences, many of >> which are the same today as then. This was late 70's stuff. >> >> My question for the group is - when did emacs arrive in unix and was it a >> full fledged text editor when it came or was it sitting on top of some >> other subssystem in unix? Was TECO ever on unix? >> >> Will >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Fri Aug 4 10:38:37 2023 From: cowan at ccil.org (John Cowan) Date: Thu, 3 Aug 2023 20:38:37 -0400 Subject: [TUHS] Split addressing (I/D) space (inspired by the death of the python... thread) In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <202308031657.373GvVvW008640@ultimate.com> Message-ID: On Thu, Aug 3, 2023 at 6:54 PM Clem Cole wrote: > > ᐧ > Adding features and thinking less about what functionality was really > needed started to get lost [so now we have Gnu - but I digress]. > And a Good Thing Too. I hate to think how many thousands of times in the last few decades I have written "awk '{if (m < length) m = length} END {print m}'" (and wondering for a moment if it's "length" or "len") until someone mentioned "wc -L" to me just the other day. Arrgh. -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Fri Aug 4 10:39:43 2023 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Fri, 4 Aug 2023 10:39:43 +1000 Subject: [TUHS] emacs In-Reply-To: References: Message-ID: <20230804003943.GD64035@eureka.lemis.com> On Thursday, 3 August 2023 at 17:19:10 -0700, Adam Thornton wrote: > > The first Emacs I used was GNU emacs at already version...16 or something? > In 1989, Coincidentally that's when I first used GNU Emacs on a Unix-like system (SCO Xenix, also coincidentally in Austin). The version was 18.51. But as Warner says, there were plenty of Emacs-lookalikes on other platforms, notably MINCE (MINCE Is Not Complete Emacs) on the Z-80, which I used from 1980, and others, including the micro Emacs that Warner used. The Emacs lineage (TECO → GNU Emacs) isn't as straight as it might appear. There was also a Gosling Emacs in the interim time, and I gather that rms used some of the concepts (screen refresh?) for GNU Emacs. Also I recall that the version numbering was a little defective, something like skipping a number of major version numbers because it seemed that enough time had passed. But I'm hazy on the details, and maybe somebody else can fill in. 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 clemc at ccc.com Fri Aug 4 10:44:22 2023 From: clemc at ccc.com (Clem Cole) Date: Thu, 3 Aug 2023 20:44:22 -0400 Subject: [TUHS] emacs In-Reply-To: References: Message-ID: http://wiki.c2.com/?TecoEditor Cantrell’s teco was pretty fast and used a lot less resources than any of the Unix EMACS invocations. Gosling / CMU EMACS showed up in 81 on the Vax and is where mocklisp came from. Zimmerman EMACS may have been earlier at MIT but Steve sold it to CCA so it was not nearly as widespread. Noel may know more. We got a license from CCA in ‘84 and shipped it on the Masscomp systems. Rms did like a number things gosling did and start to rewrite it. (The defaults were different from ITS was one of his issues). He released his version around 85. FWIW: There is still some bad blood wrt to that whole path best I can tell. I think there were a couple of others. On Thu, Aug 3, 2023 at 8:04 PM Will Senn wrote: > As a longtime user and lover of ed/ex/vi, I don't know much about emacs, > but lately I've been using it more (as it seems like any self-respecting > lisper, has to at least have a passing acquaintance with it). I recently > went off and got MACLISP running in ITS. As part of that exploration, I > used EMACS, but not just any old emacs, emacs in it's first incarnation as > a set of TECO macros. To me, it just seemed like EMACS. I won't bore you > with the details - imagine lots of control and escape sequences, many of > which are the same today as then. This was late 70's stuff. > > My question for the group is - when did emacs arrive in unix and was it a > full fledged text editor when it came or was it sitting on top of some > other subssystem in unix? Was TECO ever on unix? > > > Will > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Aug 4 10:47:09 2023 From: clemc at ccc.com (Clem Cole) Date: Thu, 3 Aug 2023 20:47:09 -0400 Subject: [TUHS] emacs In-Reply-To: References: Message-ID: Rms did Not like. Sigh On Thu, Aug 3, 2023 at 8:44 PM Clem Cole wrote: > http://wiki.c2.com/?TecoEditor > > Cantrell’s teco was pretty fast and used a lot less resources than any of > the Unix EMACS invocations. Gosling / CMU EMACS showed up in 81 on the Vax > and is where mocklisp came from. Zimmerman EMACS may have been earlier at > MIT but Steve sold it to CCA so it was not nearly as widespread. Noel may > know more. We got a license from CCA in ‘84 and shipped it on the Masscomp > systems. > > Rms did like a number things gosling did and start to rewrite it. (The > defaults were different from ITS was one of his issues). He released his > version around 85. FWIW: There is still some bad blood wrt to that whole > path best I can tell. > > I think there were a couple of others. > > > On Thu, Aug 3, 2023 at 8:04 PM Will Senn wrote: > >> As a longtime user and lover of ed/ex/vi, I don't know much about emacs, >> but lately I've been using it more (as it seems like any self-respecting >> lisper, has to at least have a passing acquaintance with it). I recently >> went off and got MACLISP running in ITS. As part of that exploration, I >> used EMACS, but not just any old emacs, emacs in it's first incarnation as >> a set of TECO macros. To me, it just seemed like EMACS. I won't bore you >> with the details - imagine lots of control and escape sequences, many of >> which are the same today as then. This was late 70's stuff. >> >> My question for the group is - when did emacs arrive in unix and was it a >> full fledged text editor when it came or was it sitting on top of some >> other subssystem in unix? Was TECO ever on unix? >> >> >> Will >> > -- > Sent from a handheld expect more typos than usual > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Fri Aug 4 10:49:35 2023 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 3 Aug 2023 17:49:35 -0700 Subject: [TUHS] emacs In-Reply-To: References: Message-ID: <20230804004935.GF11023@mcvoy.com> I have yet to see someone see the stuff I use from BDS C's editor, here is vi's version: map # :.,$ map @ :1,. And from Udi Manber, I watched him do this and said how the heck did you make that paragraph reformat? map , !}fmt^M Sory, not TECO, but editor stuff. I'll bow out. On Fri, Aug 04, 2023 at 10:27:52AM +1000, Rob Pike wrote: > There was a guy in production at Google using Unix TECO as his main editor > when I joined in 2002. He was astonished that I recognized it, but I had > used TECO in the early 1970s and, although I had no desire to return to it, > I did know it well enough to exclaim its presence when watching over his > shoulder. > > So yes, apologies for not remembering his name, but it was at least one > person's default editor. > > -rob > > > On Fri, Aug 4, 2023 at 10:19???AM Adam Thornton wrote: > > > There are certainly teco implementations for Unix, although I don't know > > if it was ever anyone's default editor anywhere. Indeed, there are > > multiple implementations: I switched from a C teco implementation to pyteco > > in the Rubin Science Platform JupyterLab implementation (its utility is of > > course dubious, but this is part of both my nefarious plan to make Jupyter > > not merely mean "Julia, Python, and R", but to use that "e" -- and > > reassociate it with the "t" -- by making it mean "Julia, Python, Teco, and > > R", and also to include an easter egg for a fellow project member who is a > > teco fan). > > > > The first Emacs I used was GNU emacs at already version...16 or > > something? In 1989, on ... I don't remember what the main system I used at > > the UT Austin Chaos Lab was, actually; we had an SGI Iris, but that wasn't > > the machine I did my editing on. But by 1989 it was certainly > > well-available and established. > > > > On Thu, Aug 3, 2023 at 5:04???PM Will Senn wrote: > > > >> As a longtime user and lover of ed/ex/vi, I don't know much about emacs, > >> but lately I've been using it more (as it seems like any self-respecting > >> lisper, has to at least have a passing acquaintance with it). I recently > >> went off and got MACLISP running in ITS. As part of that exploration, I > >> used EMACS, but not just any old emacs, emacs in it's first incarnation as > >> a set of TECO macros. To me, it just seemed like EMACS. I won't bore you > >> with the details - imagine lots of control and escape sequences, many of > >> which are the same today as then. This was late 70's stuff. > >> > >> My question for the group is - when did emacs arrive in unix and was it a > >> full fledged text editor when it came or was it sitting on top of some > >> other subssystem in unix? Was TECO ever on unix? > >> > >> Will > >> > > -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From imp at bsdimp.com Fri Aug 4 10:53:46 2023 From: imp at bsdimp.com (Warner Losh) Date: Thu, 3 Aug 2023 18:53:46 -0600 Subject: [TUHS] emacs In-Reply-To: References: Message-ID: On Thu, Aug 3, 2023, 6:44 PM Clem Cole wrote: > http://wiki.c2.com/?TecoEditor > > Cantrell’s teco was pretty fast and used a lot less resources than any of > the Unix EMACS invocations. Gosling / CMU EMACS showed up in 81 on the Vax > and is where mocklisp came from. Zimmerman EMACS may have been earlier at > MIT but Steve sold it to CCA so it was not nearly as widespread. Noel may > know more. We got a license from CCA in ‘84 and shipped it on the Masscomp > systems. > > Rms did like a number things gosling did and start to rewrite it. (The > defaults were different from ITS was one of his issues). He released his > version around 85. FWIW: There is still some bad blood wrt to that whole > path best I can tell. > RMS started with Gosling's emacs, did a half-hearted rewrite by evolving that code and claimed it all as his. Gosling was understandably upset by this and made him stop. The release notes from the early teens of releases document some of the drama. The last thing was the screen code and was still a sticking point even after the rewrite... a lot happened on mailing lists too, but I've not found those archives.. The ill will was well earned... Warner I think there were a couple of others. > > > On Thu, Aug 3, 2023 at 8:04 PM Will Senn wrote: > >> As a longtime user and lover of ed/ex/vi, I don't know much about emacs, >> but lately I've been using it more (as it seems like any self-respecting >> lisper, has to at least have a passing acquaintance with it). I recently >> went off and got MACLISP running in ITS. As part of that exploration, I >> used EMACS, but not just any old emacs, emacs in it's first incarnation as >> a set of TECO macros. To me, it just seemed like EMACS. I won't bore you >> with the details - imagine lots of control and escape sequences, many of >> which are the same today as then. This was late 70's stuff. >> >> My question for the group is - when did emacs arrive in unix and was it a >> full fledged text editor when it came or was it sitting on top of some >> other subssystem in unix? Was TECO ever on unix? >> >> >> Will >> > -- > Sent from a handheld expect more typos than usual > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Fri Aug 4 11:00:27 2023 From: rich.salz at gmail.com (Rich Salz) Date: Thu, 3 Aug 2023 21:00:27 -0400 Subject: [TUHS] emacs In-Reply-To: <20230804004935.GF11023@mcvoy.com> References: <20230804004935.GF11023@mcvoy.com> Message-ID: The Wikipedia articles give a good overview https://en.wikipedia.org/wiki/Computer_Corporation_of_America https://en.wikipedia.org/wiki/Gosling_Emacs We had one of the first Pyramid minicomputers, so we got lots of stuff to port. RMS claimed he modified the earlier, freely redistributable, version of Gosling Emacs, not the one Unipress sold. The skull and crossbones referenced above is at https://donhopkins.com/home/archive/emacs/skull-and-crossbones.txt Years later, Lucid forked it (now at xemacs.org) and the personalities involved caused the "great Emacs schism" A pox on both their houses, I say :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Fri Aug 4 11:01:42 2023 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 3 Aug 2023 18:01:42 -0700 Subject: [TUHS] python In-Reply-To: References: <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> Message-ID: <20230804010142.GH11023@mcvoy.com> I agree with Rob. I get why Guido did it, he wanted some sane style. Any of us who were kernel engineers and saw a sane C style, then you see GNU C style and you recoil in horror. I don't know if that was his path but I get that you would like some sanity in the formatting. That said, as a person who thinks of himself as a professional, when I go in to someone else's code, I adopt their style. It's really rude to not do so. I've written code in GNU C style. On Thu, Aug 03, 2023 at 11:29:18PM +1000, Rob Pike wrote: > The idea of indentation defining structure seemed really cool when it > arose. I first saw it in a toy language called Henry, back in the early > 1980s. > > But over time the notion that invisible characters define program execution > created so many problems that in retrospect it is ill advised despite its > prevalence. In fact its prevalence makes it even less advisable, as it > creates yet more areas for trouble. > > -rob > > > On Thu, Aug 3, 2023 at 10:36???PM Mike Markowski wrote: > > > Clem and all, > > > > I find python string format syntax to be close enough to printf. E.g., > > > > print('%.4f ns, (%.4f, %.4fj)' % (tap[0], tap[1].real, tap[1].imag)) > > > > However, the example highlights a shortcoming. While complex numbers > > are supported by the language, there is no formatting support like > > '%.5j' ('j' is my made up format char) to directly format a complex number. > > > > I work in an RF lab focused on work with hardware and lab gear. Some > > points in favor of python are (1) lab gear is controlled by SCPI, (2) > > DSP relies on complex math, and (3) RF propagation modeling is > > computationally intense. > > > > Item (1) is easily performed with python, (2) with python or > > Matlab/octave, and (3) is 'it depends.' An engineer's friend went from > > slide rule, to calculator, fortran/c (fortran for numbers, c for > > hardware), and now python. A laptop with python or matlab is the new > > 'calculator.' As to (3), if you will use the program for large > > scenarios, use c or fortran. For small runs or to dovetail results with > > control of lab gear python fills the bill. (I even went to the slightly > > insane length of converting a classic prop model from fortran to python > > for that reason: https://udel.edu/~mm/itm/ ) > > > > I agree 110% that python white space formatting is horrible. I can't > > say many times I took someone else's program, made a quick change, to > > discover one of us used tabs and the other spaces. > > > > Mike Markowski > > > > On 8/2/23 10:07 PM, Clem Cole wrote: > > > IMO (Like Larry) no printf stinks. But the real killer for my sustain > > > for Python is the use white space and being typeless. My daughter > > > loves it for her cloud development and we argue a bit. But it was the > > > first language she really mastered in college and she never took a > > > competitive languages course so I???m not so sure really had experienced > > > much beyond it for real programs. Maybe I???m just an old fart but > > > between C, Go and Rust I???m pretty good. I do write scripts in Bourne > > > shell and or awk truth be known. > > > > > -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From stewart at serissa.com Fri Aug 4 11:23:59 2023 From: stewart at serissa.com (Larry Stewart) Date: Thu, 3 Aug 2023 21:23:59 -0400 Subject: [TUHS] emacs In-Reply-To: References: Message-ID: <8AA44C9A-806D-4115-8A76-9A73412185F4@serissa.com> An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri Aug 4 11:28:30 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 04 Aug 2023 01:28:30 +0000 Subject: [TUHS] python In-Reply-To: <20230804010142.GH11023@mcvoy.com> References: <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <20230804010142.GH11023@mcvoy.com> Message-ID: > That said, as a person who thinks of himself as a professional, when I go > in to someone else's code, I adopt their style. It's really rude to not > do so. I've written code in GNU C style. > > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat I've adopted a variation on this in that I try and write additions to existing code stylistically similar to what is there, anything presenting glue logic to some sort of external vendor library in a way resembling their style, and then anything else is mine. That middle one I've found particularly helpful even for myself over the years as there are plenty of places in the dayjob codebases I can drop in and tell almost immediately "Oh this is a wrapper over so and so based on the variable names" or "Yeah this is an interface to library based on the way the operations are named." Generally the only thing I have a hard time sticking to is casing, I'm a fervent snake caser in my assembly and C code, but then fervent pascal caser in my JavaScript and C#. Then again, that may also tie into my middle practice in that those are the common cases seen in model examples of those languages. One of the weirder side effects of that stylistic practice is the rare occasion where I blindly copy something between languages with relatively similar syntax (C to C# or JavaScript for instance) I can tell going back later because there's a hunk of code with snake case smack in the middle of a bunch of pascal case. I usually go and clean that up though because otherwise the codebase starts to look like a copypaste job from StackOverflow after a while, that stuff drives me up the wall. - Matt G. P.S. For TUHS subject appropriateness, I have TUHS to thank for my C style practices. I learned from KnR 2nd Edition back when I was a kid, but diverged a bit from the typical KnR way of things for a while, when I caught wind of TUHS and started pouring over all the code, unbeknownst to my own consciousness I started absorbing stylistic patterns from UNIX sources. I'm thankful to Warren and all the others who have facilitated this community, I think TUHS should be in any programmer's bookmark list :) From athornton at gmail.com Fri Aug 4 11:58:01 2023 From: athornton at gmail.com (Adam Thornton) Date: Thu, 3 Aug 2023 18:58:01 -0700 Subject: [TUHS] python In-Reply-To: References: <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <20230804010142.GH11023@mcvoy.com> Message-ID: What we've done on my current project is pretty much equivalent to the route Go chose. Go has go fmt; doesn't matter what you personally believe, just run that pre-commit, and you get a consistent style. For Python we use black. Same idea. It's not what everyone would have chosen--in fact, precisely what it does is not what *anyone* on the project, probably, would have chosen--but the fact is, it does something sane and pretty readable, and then there's no fighting over style. Adam On Thu, Aug 3, 2023 at 6:28 PM segaloco via TUHS wrote: > > That said, as a person who thinks of himself as a professional, when I go > > in to someone else's code, I adopt their style. It's really rude to not > > do so. I've written code in GNU C style. > > > > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat > > I've adopted a variation on this in that I try and write additions to > existing code stylistically similar to what is there, anything presenting > glue logic to some sort of external vendor library in a way resembling > their style, and then anything else is mine. > > That middle one I've found particularly helpful even for myself over the > years as there are plenty of places in the dayjob codebases I can drop in > and tell almost immediately "Oh this is a wrapper over so and so based on > the variable names" or "Yeah this is an interface to library based on > the way the operations are named." > > Generally the only thing I have a hard time sticking to is casing, I'm a > fervent snake caser in my assembly and C code, but then fervent pascal > caser in my JavaScript and C#. Then again, that may also tie into my > middle practice in that those are the common cases seen in model examples > of those languages. One of the weirder side effects of that stylistic > practice is the rare occasion where I blindly copy something between > languages with relatively similar syntax (C to C# or JavaScript for > instance) I can tell going back later because there's a hunk of code with > snake case smack in the middle of a bunch of pascal case. I usually go and > clean that up though because otherwise the codebase starts to look like a > copypaste job from StackOverflow after a while, that stuff drives me up the > wall. > > - Matt G. > > P.S. For TUHS subject appropriateness, I have TUHS to thank for my C style > practices. I learned from KnR 2nd Edition back when I was a kid, but > diverged a bit from the typical KnR way of things for a while, when I > caught wind of TUHS and started pouring over all the code, unbeknownst to > my own consciousness I started absorbing stylistic patterns from UNIX > sources. I'm thankful to Warren and all the others who have facilitated > this community, I think TUHS should be in any programmer's bookmark list :) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Fri Aug 4 11:59:45 2023 From: will.senn at gmail.com (Will Senn) Date: Thu, 3 Aug 2023 20:59:45 -0500 Subject: [TUHS] emacs In-Reply-To: References: Message-ID: Nice. the Rainbow was my first working PC. I loved it. It had a math coprocessor (that  I upgraded), z80 and 8088, with 1MB ram (that I upgraded it to, from 128k), ran Autocad! MSDOS 3.10b, CP/M and it was the machine I used with a 300baud modem to download the pre 1.0 slackware - kermit/xmodem through a VMS gateway to the internet - 1993/1994. I didn't have emacs though! I think I remember Ultrix or something like that, but I didn't run it. On 8/3/23 19:32, Warner Losh wrote: > > > On Thu, Aug 3, 2023, 6:19 PM Adam Thornton wrote: > > There are certainly teco implementations for Unix, although I > don't know if it was ever anyone's default editor aInywhere.  > Indeed, there are multiple implementations: I switched from a C > teco implementation to pyteco in the Rubin Science Platform > JupyterLab implementation (its utility is of course dubious, but > this is part of both my nefarious plan to make Jupyter not merely > mean "Julia, Python, and R", but to use that "e" -- and > reassociate it with the "t" -- by making it mean "Julia, Python, > Teco, and R", and also to include an easter egg for a fellow > project member who is a teco fan). > > The first Emacs I used was GNU emacs at already version...16 or > something?  In 1989, on ... I don't remember what the main system > I used at the UT Austin Chaos Lab was, actually; we had an SGI > Iris, but that wasn't the machine I did my editing on.  But by > 1989 it was certainly well-available and established. > > > We used some stripped down emacs in 1985 on the vax 11/750 running > 4.2bsd.   I built micro emacs for my DEC Rainbow under MS-DOS in the > same time period... > > Warner > > On Thu, Aug 3, 2023 at 5:04 PM Will Senn wrote: > > As a longtime user and lover of ed/ex/vi, I don't know much > about emacs, but lately I've been using it more (as it seems > like any self-respecting lisper, has to at least have a > passing acquaintance with it). I recently went off and got > MACLISP running in ITS. As part of that exploration, I used > EMACS, but not just any old emacs, emacs in it's first > incarnation as a set of TECO macros. To me, it just seemed > like EMACS. I won't bore you with the details - imagine lots > of control and escape sequences, many of which are the same > today as then. This was late 70's stuff. > > My question for the group is - when did emacs arrive in unix > and was it a full fledged text editor when it came or was it > sitting on top of some other subssystem in unix? Was TECO ever > on unix? > > Will > -------------- next part -------------- An HTML attachment was scrubbed... URL: From halbert at halwitz.org Fri Aug 4 12:14:35 2023 From: halbert at halwitz.org (Dan Halbert) Date: Thu, 3 Aug 2023 22:14:35 -0400 Subject: [TUHS] emacs In-Reply-To: References: Message-ID: <4fb37122-bb5c-5989-a1d1-a0c96ca6d38d@halwitz.org> On 8/3/23 20:44, Clem Cole wrote: > Gosling / CMU EMACS showed up in 81 on the Vax and is where mocklisp > came from. Do not forget Multics EMACS (1978), https://en.wikipedia.org/wiki/Multics_Emacs, written in Lisp by Bernie Greenberg, and the Lisp Machine emacsen, https://en.wikipedia.org/wiki/EINE_and_ZWEI, by the late Dan Weinreb. I knew the authors of both of these well. Dan H From jnc at mercury.lcs.mit.edu Fri Aug 4 12:17:28 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 3 Aug 2023 22:17:28 -0400 (EDT) Subject: [TUHS] emacs Message-ID: <20230804021728.14AD318C080@mercury.lcs.mit.edu> > From: Will Senn > when did emacs arrive in unix and was it a full fledged text editor > when it came or was it sitting on top of some other subssystem Montgomery Emacs was the first I knew of; it started on PDP-11 UNIX. According to: https://github.com/larsbrinkhoff/emacs-history/blob/sources/docs/Montgomery%20Emacs%20History.txt Montgomery Emacs started in 1980 or so; here: http://ana-3.lcs.mit.edu/~jnc/tech/unix/emacs/emacs.doc is a manual from May, 1981. It had pretty full EMACS functionality, but the editor was not written in an implementation language of any kind (like the original, and like much later GNU Emacs); it was written in C. It did have macros for extensions, but they were written in Emacs commands, so, like the TECO that the original was written in, their source looks kind of like line noise. (Does anyone young even know what line noise looks like any more? I feel so old - and I'm a youngster compared to McIlroy!) > Was TECO ever on unix? I don't think it was widespread, but there was a TECO on the PDP-11 UNIXes at MIT; until Montgomery Emacs arrived, it was the primary editor used on those machines. Not that most people used TECO commands for editing; early on, they added '^R mode' to the UNIX TECO, similar to the one on ITS TECO, and a macro package was written for it (in TECO - so again, the source looks like line noise); the command set was like a stripped down EMACS - about a dozen command characters total; see the table about a page down here: http://ana-3.lcs.mit.edu/~jnc/tech/unix/teco/help All the source, and documentation, such as it is, it available, here: http://ana-3.lcs.mit.edu/~jnc/tech/unix/teco/ but don't even think about running it. It's written in MACRO-11, and it used a version of that hacked at MIT to run on UNIX. To build new versions of that, you need a special linker - written in BCPL. So you also need the UNIX BCPL compiler. Noel From bakul at iitbombay.org Fri Aug 4 12:18:58 2023 From: bakul at iitbombay.org (Bakul Shah) Date: Thu, 3 Aug 2023 19:18:58 -0700 Subject: [TUHS] emacs In-Reply-To: References: Message-ID: I had ported Gosling Emacs to Fortune System in 1981 or 82. It was painfully slow. I vaguely remember that was due to bitfields use, for which our C compiler (pcc based IIRC) did not generate good code. I gave up at that point as it was a side project & vi was more than good enough. Earlier I had used TECO (logged in to ITS from an IMP @ USC) but not emacs. > On Aug 3, 2023, at 5:04 PM, Will Senn wrote: > > As a longtime user and lover of ed/ex/vi, I don't know much about emacs, but lately I've been using it more (as it seems like any self-respecting lisper, has to at least have a passing acquaintance with it). I recently went off and got MACLISP running in ITS. As part of that exploration, I used EMACS, but not just any old emacs, emacs in it's first incarnation as a set of TECO macros. To me, it just seemed like EMACS. I won't bore you with the details - imagine lots of control and escape sequences, many of which are the same today as then. This was late 70's stuff. > > My question for the group is - when did emacs arrive in unix and was it a full fledged text editor when it came or was it sitting on top of some other subssystem in unix? Was TECO ever on unix? > > Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From fair-tuhs at netbsd.org Fri Aug 4 12:26:52 2023 From: fair-tuhs at netbsd.org (Erik E. Fair) Date: Thu, 03 Aug 2023 19:26:52 -0700 Subject: [TUHS] emacs In-Reply-To: References: Message-ID: <15156.1691116012@cesium.clock.org> I first learned original TECO-based EMACS on the Stanford CERAS DECsystem-20/60 running TOPS-20 during the summer of 1978 - I'd been using line-editors before that, and EMACS was a revelation. Heck, "intelligent" (CRT) terminals were a terrific replacement for teletypes, DECwriters, and "glass" TTYs. When I got to UCB in the fall of 1980, it took until Winter quarter (1981) to get an account on the Cory Hall (EECS) PDP-11/70 running 2.8 BSD Unix, through the Berkeley Computer Club. The Warren Montgomery emacs was available, and since I already knew emacs keystrokes, that was my editor of choice ... initially. I converted to vi because I really hated having one finger on the CTRL key all day long. It was also nice that the BSD tty line discpline displays what you type along the same lines as TOPS-20 did, including word-erase, though trying to use ^W that way in most emacs absolutely violates the Principle of Least Astonishment ... which if you've ever interacted with rms, should not really surprise given what he did with ^S, ^Q, and ^H. Emacs has been available (in one form or another) on Unix for a very long time. Erik From jnc at mercury.lcs.mit.edu Fri Aug 4 12:36:39 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 3 Aug 2023 22:36:39 -0400 (EDT) Subject: [TUHS] emacs Message-ID: <20230804023639.A620218C080@mercury.lcs.mit.edu> > From: Rob Pike > There was a guy in production at Google using Unix TECO as his main > editor when I joined in 2002. Do you happen to know which version it was, or what it was written in? It must have been _somebody_'s re-implementation, but I wonder who or where (or why :-). Noel From robpike at gmail.com Fri Aug 4 12:42:26 2023 From: robpike at gmail.com (Rob Pike) Date: Fri, 4 Aug 2023 12:42:26 +1000 Subject: [TUHS] emacs In-Reply-To: <20230804023639.A620218C080@mercury.lcs.mit.edu> References: <20230804023639.A620218C080@mercury.lcs.mit.edu> Message-ID: Sorry, no, I don't. -rob On Fri, Aug 4, 2023 at 12:36 PM Noel Chiappa wrote: > > From: Rob Pike > > > There was a guy in production at Google using Unix TECO as his main > > editor when I joined in 2002. > > Do you happen to know which version it was, or what it was written in? > > It must have been _somebody_'s re-implementation, but I wonder who or where > (or why :-). > > Noel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Fri Aug 4 14:41:28 2023 From: imp at bsdimp.com (Warner Losh) Date: Thu, 3 Aug 2023 22:41:28 -0600 Subject: [TUHS] 3bsd tape image In-Reply-To: References: Message-ID: On Thu, Aug 3, 2023 at 6:13 PM Will Senn wrote: > Hi All, > > Is this the only bootable 3bsd distribution tape we have? > > > http://sourceforge.net/projects/bsd42/files/Install%20tapes/3%20BSD/3bsd.tap.bz2/download > > I don't like the idea that sourceforge is the only source, the provenance > is unclear and I'm just not a big fan of how sourceforge handles downloads > generally. > > I've found tarballs, but not tapes on TUHS. > The TUHS stuff matches what we have on Kirk's CDs. And it looks like one could build a boot tape from what's in sys in the tarball. It has the usual standalone files that look like V7 files. There's usr/man/man8/sysgen.8 sysgen \- UNIX system generation from the distribution tape I've not tried to grab that tape to see if it has the same bits as in the archive. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsg at jsg.id.au Fri Aug 4 15:03:02 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Fri, 4 Aug 2023 15:03:02 +1000 Subject: [TUHS] emacs In-Reply-To: <20230804021728.14AD318C080@mercury.lcs.mit.edu> References: <20230804021728.14AD318C080@mercury.lcs.mit.edu> Message-ID: On Thu, Aug 03, 2023 at 10:17:28PM -0400, Noel Chiappa wrote: > > From: Will Senn > > Was TECO ever on unix? > > I don't think it was widespread, but there was a TECO on the PDP-11 UNIXes at > MIT; until Montgomery Emacs arrived, it was the primary editor used on those > machines. > > Not that most people used TECO commands for editing; early on, they added '^R > mode' to the UNIX TECO, similar to the one on ITS TECO, and a macro package > was written for it (in TECO - so again, the source looks like line noise); > the command set was like a stripped down EMACS - about a dozen command > characters total; see the table about a page down here: > > http://ana-3.lcs.mit.edu/~jnc/tech/unix/teco/help > > All the source, and documentation, such as it is, it available, here: > > http://ana-3.lcs.mit.edu/~jnc/tech/unix/teco/ > > but don't even think about running it. It's written in MACRO-11, and it used > a version of that hacked at MIT to run on UNIX. To build new versions of > that, you need a special linker - written in BCPL. So you also need the UNIX > BCPL compiler. > > Noel The HRSTS version of it can be found in the UNSW tapes. The usenix 77 tape has h/help/teco and a 0-sized h/teco/cont.a Matt Fichtenbaum's TECO for Ultrix appears in tuhs/Applications/Shoppa_Tapes/usenix878889.tar.gz usenix87/Editors/Teco/ "Harvard UNIX TECO runs under the UNIX operating system on a PDP-11. It was written by Bob Case, Peter Langston, Bruce Borden, Brent Byer, and Tucker Taft using the Harvard-Radcliffe Student Timesharing System (HRSTS)." "Harvard UNIX TECO is based on a 1973 version of MIT TECO and is written in MACRO-11. There is a possibility that this TECO will be expanded and recoded into C in the near future." https://bitsavers.org/pdf/dec/teco/MobyMunger_%233part2_Nov79.pdf "HRSTS (new)Teco V_3p" https://www.tuhs.org/Archive/Distributions/UNSW/88/ hp14/source/L/teco/ https://www.tuhs.org/Archive/Distributions/UNSW/90/ L/teco/ "BBN has a TECO for Unix." tuhs/Documentation/AUUGN/AUUGN-V01.5.pdf pg 57 SOFTWARE TOOLS and UNIX Users Group Conference Report by David M. Phillips, 26 June 1979 From tuhs at tuhs.org Fri Aug 4 16:14:09 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 04 Aug 2023 06:14:09 +0000 Subject: [TUHS] SVR2 on the PDP-11? SVR3? Message-ID: Does anyone know if there are any surviving examples of SVR2 for the PDP-11? Various SVR2 manuals still make mention of the assembler, linker, etc. and the pdp11 variable is present in machid(1)*. And on the note of the later years of the PDP-11, was there any hope for SVR3 on the PDP? I presume the introduction of demand paging was the end of things but I would be curious for anyone's recollections on the final years of System V on the PDP-11. - Matt G. P.S. *interesting little 3B5 side note, found as I was checking references that machid(1) in the "System V" branded manual from the initial System V commercial release mentions the pdp11, vax, and u3b machines, the latter being the 3B20S. However, the "Release 5.0" branded manuals also make mention of the u3b5 machine, the 3B5. The System V manuals are from January 1983 and the Release 5.0 manuals are June 1982. There isn't an earlier reference to cite as machid(1) was introduced in Release 5.0, at least from the literature I have available. The 4.x series ran on at least the PDP-11, VAX, and 3B20S computers at least, matching those listed in the System V manual. From what I have available initial 3B5 literature was distributed in the form of small binders a little different from the grey-on-black 1984 DEC Processor SVR2 binders, possibly right on the cusp of the split of p_man from u_man as this 3B5 User's Manual that I have contains sections 1-6 rather than just 1 and 6. They're dark grey with a large orange square in the middle (I believe I've sent a photograph of the manual before). -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Fri Aug 4 23:25:48 2023 From: lars at nocrew.org (Lars Brinkhoff) Date: Fri, 04 Aug 2023 13:25:48 +0000 Subject: [TUHS] emacs In-Reply-To: (Rich Salz's message of "Thu, 3 Aug 2023 21:00:27 -0400") References: <20230804004935.GF11023@mcvoy.com> Message-ID: <7wedkjgcrn.fsf@junk.nocrew.org> Rich Salz wrote: > RMS claimed he modified the earlier, freely redistributable, version > of Gosling Emacs, not the one Unipress sold. The skull and crossbones > referenced above is at > https://donhopkins.com/home/archive/emacs/skull-and-crossbones.txt It's still there in GNU Emacs 13: https://github.com/larsbrinkhoff/emacs-history/blob/sources/decuslib.com/decus/vax85b/gnuemax/emacs/src/display.c#L29-L67 From ron at ronnatalie.com Fri Aug 4 23:38:49 2023 From: ron at ronnatalie.com (Ronald Natalie) Date: Fri, 04 Aug 2023 13:38:49 +0000 Subject: [TUHS] emacs In-Reply-To: <8AA44C9A-806D-4115-8A76-9A73412185F4@serissa.com> References: <8AA44C9A-806D-4115-8A76-9A73412185F4@serissa.com> Message-ID: I started with Warren Montgomery’s EMACS. Prior to that, my entire screen oriented experience was with INed (a variant of the Rand editor). BRL largely switched to the free Gosling’s emacs and then later to Unipress. I ended up working for Unipress for a few months. Oddly, I ended up using JOVE (Johnathon’s Own Version of Emacs) because it is a small lightweight thing to move around. Consequently, I never used leaned vi. If there was no emacs variant on the machine, I used ed. My employees were quite impressed by my ability to do complex editing with ed and regular expressions there. -Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Sat Aug 5 01:04:16 2023 From: crossd at gmail.com (Dan Cross) Date: Fri, 4 Aug 2023 11:04:16 -0400 Subject: [TUHS] python In-Reply-To: References: <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <20230804010142.GH11023@mcvoy.com> Message-ID: On Thu, Aug 3, 2023 at 9:58 PM Adam Thornton wrote: > What we've done on my current project is pretty much equivalent to the route Go chose. > > Go has go fmt; doesn't matter what you personally believe, just run that pre-commit, and you get a consistent style. For Python we use black. Same idea. It's not what everyone would have chosen--in fact, precisely what it does is not what *anyone* on the project, probably, would have chosen--but the fact is, it does something sane and pretty readable, and then there's no fighting over style. This. I despised Google's C++ style standards, but I respected them because they allowed Google to scale to hundreds of millions of lines of C++ code that was at least intelligible to more or less anyone who worked there. After a couple of months, people stop noticing the sharp edges and differences from their personal styles. The decades spent arguing over where to put the braces seem wasted, in retrospect. - Dan C. From lm at mcvoy.com Sat Aug 5 01:10:55 2023 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 4 Aug 2023 08:10:55 -0700 Subject: [TUHS] python In-Reply-To: References: <20230803005106.GA12652@mcvoy.com> <20230804010142.GH11023@mcvoy.com> Message-ID: <20230804151055.GB24315@mcvoy.com> On Fri, Aug 04, 2023 at 11:04:16AM -0400, Dan Cross wrote: > On Thu, Aug 3, 2023 at 9:58???PM Adam Thornton wrote: > > What we've done on my current project is pretty much equivalent to the route Go chose. > > > > Go has go fmt; doesn't matter what you personally believe, just run that pre-commit, and you get a consistent style. For Python we use black. Same idea. It's not what everyone would have chosen--in fact, precisely what it does is not what *anyone* on the project, probably, would have chosen--but the fact is, it does something sane and pretty readable, and then there's no fighting over style. > > This. > > I despised Google's C++ style standards, but I respected them because > they allowed Google to scale to hundreds of millions of lines of C++ > code that was at least intelligible to more or less anyone who worked > there. After a couple of months, people stop noticing the sharp edges > and differences from their personal styles. > > The decades spent arguing over where to put the braces seem wasted, in > retrospect. I can get used to anything, no argument there. I'm teaching my kid some programming and he is eating up my style because I tell him why it is like that. For example, int some_func(int some_arg) { } not int some_func(int some_arg) { } because I can do grep '^some_func(' *.c and find the declaration. I "won" the braces argument by starting my own company and people were pretty happy with the resulting code. --lm From crossd at gmail.com Sat Aug 5 01:17:48 2023 From: crossd at gmail.com (Dan Cross) Date: Fri, 4 Aug 2023 11:17:48 -0400 Subject: [TUHS] python In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <1f043101-4dbb-34ff-b037-85e7cc707a6e@halwitz.org> <2BF7ADB4-4851-4CF5-A6AC-0F1079D4AF78@gmail.com> Message-ID: On Thu, Aug 3, 2023 at 8:24 PM John Cowan wrote: > On Thu, Aug 3, 2023 at 6:06 PM Dan Cross wrote: >> someone had needed to store a >> pair of integers, so they used a CONS cell; > > Of course, that was a bad idea. The pair of integers should have been a struct or a class named after whatever its application-level purpose was: a point, for example. Probably, but I didn't write the original code, or even make the change; I did submit the fix, however. :-) An issue with CLs aggregation primitives is that they can be expensive, however. QPX was weird; despite things that have been said about it publicly (http://www.paulgraham.com/carl.html) QPX was not a "typical" Lisp program: it is more like FORTRAN written in S-expressions (many thousand-line Lisp functions with jumps between various points inside of them are common; those functions like, say, setq [not setf] a boolean on line 1387, and then reference it on 3298...kind of a mess, but that's what you need to make Lisp fast). >> after a while, the pair >> needed to be expanded to a triple, so someone converted the single >> CONS cell into a (proper) list. > > In that case, a derived struct or class should have been created. The two classes would use the same accessor methods, just as in C++. Of course, we all knew this. But when you've got an O(10^6) line codebase that's extremely fragile, technology and business limitations demand tradeoffs that are not always what the engineers would choose. >> this, of course, ran afoul of the type system and >> raised a condition, which resulted as an ISE in prod. The fix was >> trivial (change CDR to SECOND in the right place) but it really struck >> me that if the system were statically typed, this would have been >> trivially discovered at compile-time. > > Absolutely, and if the failure was intolerable, CL's static type declarations would have caught the use of the wrong type. But you don't have to declare *everything*. For that matter, there is nothing in a fully statically typed system that requires every variable, function, argument, etc. to be *declared*: type inference is powerful. Not really, unless they were used consistently across the entire codebase (and sadly, they were not). >> Common Lisp does allow you to declare types in some limited regards; >> these are usually hints to the compiler for code generation. > > They may or may not be, depending on how you set the OPTIMIZE declaration. > >> like Rob, I >> greatly prefer strong, static typing. > > Then why weren't you using mypy? Because it didn't exist at the time (the early 2010s), or if it did, it was in a very nascent state. >> Incidentally, C is weakly (you can add a pointer to an integer: the >> result is another pointer), but statically typed. > > That's not weak typing, it's operator overloading, just as when you add an int to a double. C will not let you, e.g., add an int to a function. I think there's a bit of a debate as to whether C is weakly or strongly typed (and certainly, these exist on a spectrum), and some good judges say it's "moderately typed". I've never heard anyone refer to implicit type conversions as "operator overloading", however. > Weak typing is quite rare in high-level languages: PL/I pointer variables are weakly typed (that is, when you allocate an object you specify the type of the object and then assign it to the pointer variable), but the rest of the language is strongly typed. Once `memcpy` and `void *` are in the mix, all bets are off in C. - Dan C. From crossd at gmail.com Sat Aug 5 02:06:14 2023 From: crossd at gmail.com (Dan Cross) Date: Fri, 4 Aug 2023 12:06:14 -0400 Subject: [TUHS] printf (was: python) In-Reply-To: <5dd50d2c-0049-31bf-8975-08ed899a9387@gmail.org> References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <202308031657.373GvVvW008640@ultimate.com> <8e45b8b1-cf3c-e47c-bd15-d19a2ae5cc1d@gmail.org> <5dd50d2c-0049-31bf-8975-08ed899a9387@gmail.org> Message-ID: On Thu, Aug 3, 2023 at 7:55 PM Alejandro Colomar wrote: > On 2023-08-03 23:29, Dan Cross wrote: > > On Thu, Aug 3, 2023 at 2:05 PM Alejandro Colomar wrote: > >> On 2023-08-03 19:51, John Cowan wrote: > >>> On Thu, Aug 3, 2023 at 1:29 PM Alejandro Colomar > >>> wrote: > >>> > >>> But if speed is not a problem, I'd keep the good ol' syntax that > >>> > >>> everybody knows. No need to make everybody learn a "cool" new print > >>>> function, that probably won't be as tunable as printf(3) is. > >>>> > >>>> > >>> By that argument, there would be no C, only Algol 68 and PL/I, or subsets > >>> of them. > >>> > >> > >> I didn't claim that there's never a reason to invent new syntax. My claim > >> was rather that in this case, there isn't. > >> > >> - printf(3) is more powerful than any other existing formatting function > >> that I know of any language --I'm still curious of what's the equivalent > >> of "%+'0#8.5f" in other formatting functions--. > > > > One issue is that this isn't standard C: the `'` verb for grouping by > > thousands is an SUSv2 extension. I just checked the latest C23 draft, > > and unless I missed it, it doesn't appear to have made it in. > > Being in POSIX.1 it's portable to most (all?) current systems. ISO C > is a baseline for an implementation. A quality implementation will > go beyond that standard (or will be rather useless). POSIX.1 is more > of a useful thing. I don't know that that's true, but I can see how one could get into a "no true Scotsman" fallacy pretty quickly arguing over it. > But yeah, we can remove that "'" to get the idea. > > > But things like that are fairly straight-forward in many other > > languages. For example, in Go, the format string is nearly identical, > > modulo the `'`: > > Yup; I like go in that sense. > > [...] > > > > >> - It is also reasonably fast (at least for such a highly-customizable > >> formatting function), and I'd like to see any system beat that while > >> keeping the customizability. > > > > At Google, a group of exceptionally talented engineers wrote a > > replacement in C++ for both type safety and because, bluntly, `printf` > > (actually `snprintf`) was too slow. I believe the overall mechanism > > made it into ABSL. > > I think you mean absl::StrFormat(). It has printf(3)-like syntax, so > I can't say say much against it. I don't know the details of how they > achieved the claimed 2x ~ 3x performance compared to snprintf(3). I'm > curious to know if it's an inherent limitation of snprintf(3), or if > it's just that glibc is very unoptimized --which is true anyway, because > no-one has really maintained the printf(3) code in a long time--. I don't recall the details now, but I seem to remember that much of it was moving the burden of parsing the formatting directives to compile time (though I may be misremembering). > It's interesting, because then std::format() is not that miraculous > compared to snprintf(3). > > > > >> - It is type-safe, with the right tools. > > > > No it's not, and it really can't be. True, there are linters that can > > try to match up types _if_ the format string is a constant and all the > > arguments are known at e.g. compile time, but C permits one to > > construct the format string at run time (or just select between a > > bunch of variants); the language gives you no tools to enforce type > > safety in a meaningful way once you do that. > > Isn't a variable format string a security vulnerability? Where do you > need it? It _can_ be a security vulnerability, but it doesn't necessarily _need_ to be. If one is careful in how one constructs it, such things can be very safe indeed. As to where one needs it, there are examples like `vsyslog()`, but that's almost besides the point, which is that given that you _can_ do things like that, the language can't really save you by type-checking the arguments to printf; and once varargs are in the mix? Forget about it. - Dan C. From clemc at ccc.com Sat Aug 5 02:19:00 2023 From: clemc at ccc.com (Clem Cole) Date: Fri, 4 Aug 2023 12:19:00 -0400 Subject: [TUHS] emacs In-Reply-To: <20230804023639.A620218C080@mercury.lcs.mit.edu> References: <20230804023639.A620218C080@mercury.lcs.mit.edu> Message-ID: I offered Ward Cunningham's TECO page in my earlier message - which has one of my favorite quotes: *"TECO Madness -- a moment of convenience, a lifetime of regret".* I also mention Cantrell's C/UNIX version: Video teco If this was someone using teco recently, Paul's version is possible/likely as it was in C and became the teco many of used for UNIX. For a while, I could never quite decide if I liked it more than vi, but since ed and vi were >>everywhere<< from the Cray-1 to a PC, I stopped using TECO as it sometimes took a little effort to make it work (although Paul was pretty careful) - but particularly on non-UNIX boxes (other than VMS) it might not be so easy. Since Oscar's PiDP-10 and Angelo's PDP-1 work, I'll need an editor again, so I may have to relearn it -- be interesting to see how fast it comes back. 🤔 For systems with a C compiler, Ward Miller's s (which is a subset of vi - https://github.com/udo-munk/s) has been my go-to. I was playing with getting it running on V7 since it full video for a VT-100. ᐧ On Thu, Aug 3, 2023 at 10:36 PM Noel Chiappa wrote: > > From: Rob Pike > > > There was a guy in production at Google using Unix TECO as his main > > editor when I joined in 2002. > > Do you happen to know which version it was, or what it was written in? > > It must have been _somebody_'s re-implementation, but I wonder who or where > (or why :-). > > Noel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alx.manpages at gmail.com Sat Aug 5 02:57:50 2023 From: alx.manpages at gmail.com (Alejandro Colomar) Date: Fri, 4 Aug 2023 18:57:50 +0200 Subject: [TUHS] printf (was: python) In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <202308031657.373GvVvW008640@ultimate.com> <8e45b8b1-cf3c-e47c-bd15-d19a2ae5cc1d@gmail.org> <5dd50d2c-0049-31bf-8975-08ed899a9387@gmail.org> Message-ID: Hello Dan, On 2023-08-04 18:06, Dan Cross wrote: > On Thu, Aug 3, 2023 at 7:55 PM Alejandro Colomar wrote: >> On 2023-08-03 23:29, Dan Cross wrote: >>> On Thu, Aug 3, 2023 at 2:05 PM Alejandro Colomar wrote: >>>> - It is type-safe, with the right tools. >>> >>> No it's not, and it really can't be. True, there are linters that can >>> try to match up types _if_ the format string is a constant and all the >>> arguments are known at e.g. compile time, but C permits one to >>> construct the format string at run time (or just select between a >>> bunch of variants); the language gives you no tools to enforce type >>> safety in a meaningful way once you do that. >> >> Isn't a variable format string a security vulnerability? Where do you >> need it? > > It _can_ be a security vulnerability, but it doesn't necessarily > _need_ to be. If one is careful in how one constructs it, such things > can be very safe indeed. > > As to where one needs it, there are examples like `vsyslog()`, I guessed you'd mention v*() formatting functions, as that's the only case where a variable format string is indeed necessary (or kind of). I'll simplify your example to vwarnx(3), from the BSDs, which does less job, but has a similar API regarding our discussion. I'm not sure if you meant vsyslog() uses or its implementation, but I'll cover both (but for vwarnx(3)). Uses: This function (and all v*() functions) will be used to implement a wrapper variadic function, like for example warnx(3). It's there, in the variadic function, where the string /must be/ a literal, and where the arguments are checked. There's never a good reason to use a non-literal there (AFAIK), and there are compiler warnings and linters to enforce that. Since those args have been previously checked, you should just pass the va_list pristine to other formatting functions. Then, as long as libc doesn't have bugs, you're fine. In the implementation of a v*() function: Do /not/ touch the va_list. Just pass it to the next function. Of course, in the end, libc will have to iterate over it and do the job, but that's not the typical programmer's problem. Here's the libbsd implementation of vwarnx(3), which does exactly that: no messing with the va_list. $ grepc vwarnx ./include/bsd/err.h:63: void vwarnx(const char *format, va_list ap) __printflike(1, 0); ./src/err.c:97: void vwarnx(const char *format, va_list ap) { fprintf(stderr, "%s: ", getprogname()); if (format) vfprintf(stderr, format, ap); fprintf(stderr, "\n"); } Just put a [[gnu::format(printf)]] in the outermost wrapper, which should be using a string literal, and you'll be fine. > but > that's almost besides the point, which is that given that you _can_ do > things like that, the language can't really save you by type-checking > the arguments to printf; and once varargs are in the mix? Forget about > it. Not really. You can do that _only_ if you really want. If you want to not be able, you can "drop privileges" by adding a few flags to your compiler, such as -Werror=format-security -Werror=format-nonliteral, and add a bunch of linters to your build system for more redundancy, and voila, your project is now safe. Alex > > - Dan C. From will.senn at gmail.com Sat Aug 5 03:17:46 2023 From: will.senn at gmail.com (Will Senn) Date: Fri, 4 Aug 2023 12:17:46 -0500 Subject: [TUHS] 3bsd tape image In-Reply-To: References: Message-ID: On 8/3/23 23:41, Warner Losh wrote: > > > The TUHS stuff matches what we have on Kirk's CDs. > > And it looks like one could build a boot tape from what's in sys in > the tarball.  It has the usual standalone files that look like V7 files. > > There's usr/man/man8/sysgen.8 > > sysgen \- UNIX system generation from the distribution tape > > I've not tried to grab that tape to see if it has the same bits as in > the archive. > > Warner Hi Warner, I would love to be able to recreate the bootable tape(s) from what we have available (the tarball) and document that process along the way. In the setup manual, it says: The tape contains binary images of the system and all the user level programs, along with source and manual sections for them. There are about 4200 UNIX† files altogether. The first tape file contains boot- strapping programs. The second tape file is to be put on one filesystem called the ‘root filesystem’, and contains essential binaries and enough other files to allow the system to run. The third tape file has all of the source and documentation. Altogether the files provided on the tape occupy approximately 40000 512 byte blocks Taking this apart, it seems like: The tape contains binary images of the system and all the user level programs, along with source and manual sections for them. There are about 4200 UNIX† files altogether. Refers to everything in 3bsd.tar.gz  - 4130 files. And this: The first tape file contains boot-strapping programs. Refers to the files in sys: boot  mkfs  restor  rp6fmt  rpread And this: The second tape file is to be put on one filesystem called the ‘root filesystem’, and contains essential binaries and enough other files to allow the system to run. Refers to everything except /usr/src and /usr/doc. While this: The third tape file has all of the source and documentation. Refers to /usr/src and /usr doc. If I'm understanding things, this means I would create three tape images - one with just the 5 files in sys and that's it, the second with everything except for /usr/src/ and /usr/doc, and the third with just /usr/src and /usr/doc. The first tape would have blocksize 512, the other two, 10240. I could then use any of the plethora of maketape scripts around to put the tape together. In looking at what was done previously, it looks like the root fs was on the tape as a dump, whereas the usr files were on the tape as a .tar. Why not just have root and usr as .tar on the tape? Thanks, Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From egbegb2 at gmail.com Sat Aug 5 05:20:06 2023 From: egbegb2 at gmail.com (Ed Bradford) Date: Fri, 4 Aug 2023 14:20:06 -0500 Subject: [TUHS] python In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> Message-ID: To all: Python 3's fstrings https://realpython.com/python-f-strings/ seem to me to be a huge improvement over printf and its close relatives. What are people's views about the pro's and con's and how do print and strings compare in usability? Ed On Wed, Aug 2, 2023 at 9:07 PM Clem Cole wrote: > IMO (Like Larry) no printf stinks. But the real killer for my sustain for > Python is the use white space and being typeless. My daughter loves it > for her cloud development and we argue a bit. But it was the first > language she really mastered in college and she never took a competitive > languages course so I’m not so sure really had experienced much beyond it > for real programs. Maybe I’m just an old fart but between C, Go and Rust > I’m pretty good. I do write scripts in Bourne shell and or awk truth be > known. > > On Wed, Aug 2, 2023 at 8:51 PM Larry McVoy wrote: > >> On Wed, Aug 02, 2023 at 07:49:18PM -0400, Rich Salz wrote: >> > > [Python is] meant for mainly functional programming as I understand it >> > >> > Not true. It has some neat functional features (list comprehensions) but >> > that's not really its intent. >> >> I've really tried to like python but any language that doesn't has printf >> as builtin is not for me. Yes, I know about their library printf but it >> is weird. >> -- >> --- >> Larry McVoy Retired to fishing >> http://www.mcvoy.com/lm/boat >> > -- > Sent from a handheld expect more typos than usual > -- Advice is judged by results, not by intentions. Cicero -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Aug 5 05:47:06 2023 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 4 Aug 2023 12:47:06 -0700 Subject: [TUHS] python In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> Message-ID: <20230804194706.GJ24315@mcvoy.com> We did something sort of like that in Little, all double quoted strings look for ${anything} in the string and evaluates it and prints. Like fstrings, you can do puts("Print 5 + 7 = ${5 + 7}"); We used single quoted strings as pure strings. It's handy and sometimes more readable than printf. http://www.little-lang.org/little.html#String_interpolation On Fri, Aug 04, 2023 at 02:20:06PM -0500, Ed Bradford wrote: > To all: > > Python 3's fstrings > https://realpython.com/python-f-strings/ > seem to me to be a huge improvement over printf > and its close relatives. > > What are people's views about the pro's and con's and > how do print and strings compare in usability? > > Ed > > > On Wed, Aug 2, 2023 at 9:07???PM Clem Cole wrote: > > > IMO (Like Larry) no printf stinks. But the real killer for my sustain for > > Python is the use white space and being typeless. My daughter loves it > > for her cloud development and we argue a bit. But it was the first > > language she really mastered in college and she never took a competitive > > languages course so I???m not so sure really had experienced much beyond it > > for real programs. Maybe I???m just an old fart but between C, Go and Rust > > I???m pretty good. I do write scripts in Bourne shell and or awk truth be > > known. > > > > On Wed, Aug 2, 2023 at 8:51 PM Larry McVoy wrote: > > > >> On Wed, Aug 02, 2023 at 07:49:18PM -0400, Rich Salz wrote: > >> > > [Python is] meant for mainly functional programming as I understand it > >> > > >> > Not true. It has some neat functional features (list comprehensions) but > >> > that's not really its intent. > >> > >> I've really tried to like python but any language that doesn't has printf > >> as builtin is not for me. Yes, I know about their library printf but it > >> is weird. > >> -- > >> --- > >> Larry McVoy Retired to fishing > >> http://www.mcvoy.com/lm/boat > >> > > -- > > Sent from a handheld expect more typos than usual > > > > > -- > Advice is judged by results, not by intentions. > Cicero -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From clemc at ccc.com Sat Aug 5 05:50:54 2023 From: clemc at ccc.com (Clem Cole) Date: Fri, 4 Aug 2023 15:50:54 -0400 Subject: [TUHS] 3bsd tape image In-Reply-To: References: Message-ID: below... On Fri, Aug 4, 2023 at 1:17 PM Will Senn wrote: > On 8/3/23 23:41, Warner Losh wrote: > > > > The TUHS stuff matches what we have on Kirk's CDs. > > And it looks like one could build a boot tape from what's in sys in the > tarball. It has the usual standalone files that look like V7 files. > > There's usr/man/man8/sysgen.8 > > sysgen \- UNIX system generation from the distribution tape > > I've not tried to grab that tape to see if it has the same bits as in the > archive. > > Warner > > > Hi Warner, > > I would love to be able to recreate the bootable tape(s) from what we have > available (the tarball) and document that process along the way. In the > setup manual, it says: > > The tape contains binary images of the system and all the user level > programs, along with source and > manual sections for them. There are about 4200 UNIX† files altogether. The > first tape file contains boot- > strapping programs. The second tape file is to be put on one filesystem > called the ‘root filesystem’, and > contains essential binaries and enough other files to allow the system to > run. The third tape file has all of > the source and documentation. Altogether the files provided on the tape > occupy approximately 40000 512 > byte blocks > > Taking this apart, it seems like: > > The tape contains binary images of the system and all the user level > programs, along with source and > manual sections for them. There are about 4200 UNIX† files altogether. > > Refers to everything in 3bsd.tar.gz - 4130 files. > > And this: > > The first tape file contains boot-strapping programs. > > Refers to the files in sys: > I think not sys but /stand > boot mkfs restor rp6fmt rpread > > And should have a boot block on it - with the standalone system -- this is right from V7 and I thought 32V but I have forgotten - BTW - this tape file will have a block size of 512 bytes because of how it is used and boot roms will read 512 bytes at time. > And this: > > The second tape file is to be put on one filesystem called the ‘root > filesystem’, and > contains essential binaries and enough other files to allow the system to > run. > > Right - the standalone system is used to create the root FS and the standalone restore to recreate the root [it's 20B or 10240 byte blocked] because by now you have a read device driver in either the standalone system or UNIX itself do blocking factors can be handled. > Refers to everything except /usr/src and /usr/doc. > What worries me a little is V7 had a dump format of /usr at this point - the rootfs did not have enough space for the everything in /usr such as /usr/{bin,lib,share...} and much less doc and src. > While this: > > The third tape file has all of the source and documentation. > > Refers to /usr/src and /usr doc. > That makes sense in that it allows everyone some one to read these two without having to ferret it from a restore/dump format. > > If I'm understanding things, this means I would create three tape images - > one with just the 5 files in sys and that's it, the second with everything > except for /usr/src/ and /usr/doc, and the third with just /usr/src and > /usr/doc. The first tape would have blocksize 512, the other two, 10240. I > could then use any of the plethora of maketape scripts around to put the > tape together. > > In looking at what was done previously, it looks like the root fs was on > the tape as a dump, whereas the usr files were on the tape as a .tar. Why > not just have root and usr as .tar on the tape? > Tar is easier when trying in read mode, particularly if you only one want a couple of files/directors. Dump/restore is fine for a complete FS at a time. Given just the src and doc directories, wanting to read the doc and source from that tape on another system -- say 32V or V7, tar makes it easier. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Sat Aug 5 06:11:02 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 4 Aug 2023 16:11:02 -0400 (EDT) Subject: [TUHS] python Message-ID: <20230804201102.753C218C077@mercury.lcs.mit.edu> How is discussing Python's output options related to the history of Unix? Noel From clemc at ccc.com Sat Aug 5 06:13:24 2023 From: clemc at ccc.com (Clem Cole) Date: Fri, 4 Aug 2023 16:13:24 -0400 Subject: [TUHS] SVR2 on the PDP-11? SVR3? In-Reply-To: References: Message-ID: On Fri, Aug 4, 2023 at 2:14 AM segaloco via TUHS wrote: > Does anyone know if there are any surviving examples of SVR2 for the > PDP-11? Various SVR2 manuals still make mention of the assembler, linker, > etc. and the pdp11 variable is present in machid(1)*. And on the note of > the later years of the PDP-11, was there any hope for SVR3 on the PDP? I > presume the introduction of demand paging was the end of things but I would > be curious for anyone's recollections on the final years of System V on the > PDP-11. > > - Matt G. > BTW Sometime around this time, Summit starts to stop full support for the 11. I want to say that by then, getting anything for the 11 out of the Bell system was difficult. I do remember that by SVR3 time, the only thing you could get officially from Summit was the 3B/WE32000-based tape as the 3B5 was the official reference for UNIX. IIRC SVR1 and SVR2 the Vax was the reference implementation, and with R1, you could still order a PDP-11 tape; but frankly, I've forgotten exactly when they stopped but I seem to remember not for SVR2. I personally had lost interest in the PDP-11 from AT&T by then. And if I could have obtained a SVR3 tape for VAX, most of the workstation folks like me would have ordered it, because we almost all had an 11/750 [usually running a flavor of BSD] around. The running joke was that you knew you own UNIX port was solid wen you could run UUCP and sendmail for you companies external gateway. IIRC as a for instance, Eric Fair was running a Vax at Apple since Apple's own UNIX product could not do it. BTW: With SVR4 the Intel 386 family was the reference. AT&T had bought NCR by then, and NCR had flipped to it's 'Seven Layer Stragety' which was Intel ISA across each level and had kill off all their Motorola-based products. After the purchase with the NCR folks running AT&T's computer division, the 3B series began its demise even for AT&T and the RBOC. I was an external consultant for them at that point, and I may even have a memo from the Chief Architect (Lee Hovel - my boss/client in those days) that killed it [I actually the analysis for him that killed off the 88000 machines - which made my name mud in Columbia, SC where there had developed it - but I was not part of the 3B stuff]. > P.S. *interesting little 3B5 side note, found as I was checking references > that machid(1) in the "System V" branded manual from the initial System V > commercial release mentions the pdp11, vax, and u3b machines, the latter > being the 3B20S. However, the "Release 5.0" branded manuals also make > mention of the u3b5 machine, the 3B5. > The 20S was a bit larger than a Vax 11/780 - just half of the 20D [duplex], which was developed to control the ESS#5 and was logic -- I don't remember what family, but likely 74S series. So it was traditional 19" racks and 48v telco-style power. While the 3B5 used a WE32000 chip as a 'desktop' system and plugged into a standard NEMA 110v jack. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Aug 5 06:15:51 2023 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 4 Aug 2023 13:15:51 -0700 Subject: [TUHS] python In-Reply-To: <20230804201102.753C218C077@mercury.lcs.mit.edu> References: <20230804201102.753C218C077@mercury.lcs.mit.edu> Message-ID: <20230804201551.GL24315@mcvoy.com> Perhaps it is a stretch, but I'd say that printf() is a good example of the type of thinking done by the original Unix folks. Seeing how other people didn't learn that lesson kind of underscores the good engineering done at Bell Labs. On Fri, Aug 04, 2023 at 04:11:02PM -0400, Noel Chiappa wrote: > How is discussing Python's output options related to the history of Unix? > > Noel -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From athornton at gmail.com Sat Aug 5 06:45:41 2023 From: athornton at gmail.com (Adam Thornton) Date: Fri, 4 Aug 2023 13:45:41 -0700 Subject: [TUHS] python In-Reply-To: <20230804201551.GL24315@mcvoy.com> References: <20230804201102.753C218C077@mercury.lcs.mit.edu> <20230804201551.GL24315@mcvoy.com> Message-ID: I think it's again helpful to consider golang as "roughly as modern as Python, but definitely more C-inspired". The thing that Python f-strings do (other than allow interpolation of arbitrary code to be executed, which can be very handy) is that they generally provide a sane default representation of the value you want. For instance, you can say: print(f"Value of foo == {foo}") and you get either something sane if foo is a primitive type, or you get whatever foo's __str__() method gives you if it's an instance of a class; the default class general does something not-terrible with that, but you can add __str__() and __repr__() if you have opinions about how you want to represent your class when printed for humans or for machine consumption (effectively, __repr__() should let you reconstruct the object, while __str__() is for display to humans). This overcomes something C doesn't easily let you do. Most of the time I'd rather not have to care whether the thing I'm printing is a string, or a pointer, or an integer, or whatever: I just want to see its value. Go has %v for exactly this. It's very nice for debugging. On Fri, Aug 4, 2023 at 1:15 PM Larry McVoy wrote: > Perhaps it is a stretch, but I'd say that printf() is a good example of > the type of thinking done by the original Unix folks. Seeing how other > people didn't learn that lesson kind of underscores the good engineering > done at Bell Labs. > > On Fri, Aug 04, 2023 at 04:11:02PM -0400, Noel Chiappa wrote: > > How is discussing Python's output options related to the history of Unix? > > > > Noel > > -- > --- > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Sat Aug 5 07:16:56 2023 From: crossd at gmail.com (Dan Cross) Date: Fri, 4 Aug 2023 17:16:56 -0400 Subject: [TUHS] printf (was: python) In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <202308031657.373GvVvW008640@ultimate.com> <8e45b8b1-cf3c-e47c-bd15-d19a2ae5cc1d@gmail.org> <5dd50d2c-0049-31bf-8975-08ed899a9387@gmail.org> Message-ID: On Fri, Aug 4, 2023 at 12:57 PM Alejandro Colomar wrote: > On 2023-08-04 18:06, Dan Cross wrote: > > On Thu, Aug 3, 2023 at 7:55 PM Alejandro Colomar wrote: > >> On 2023-08-03 23:29, Dan Cross wrote: > >>> On Thu, Aug 3, 2023 at 2:05 PM Alejandro Colomar wrote: > >>>> - It is type-safe, with the right tools. > >>> > >>> No it's not, and it really can't be. True, there are linters that can > >>> try to match up types _if_ the format string is a constant and all the > >>> arguments are known at e.g. compile time, but C permits one to > >>> construct the format string at run time (or just select between a > >>> bunch of variants); the language gives you no tools to enforce type > >>> safety in a meaningful way once you do that. > >> > >> Isn't a variable format string a security vulnerability? Where do you > >> need it? > > > > It _can_ be a security vulnerability, but it doesn't necessarily > > _need_ to be. If one is careful in how one constructs it, such things > > can be very safe indeed. > > > > As to where one needs it, there are examples like `vsyslog()`, > > I guessed you'd mention v*() formatting functions, as that's the only > case where a variable format string is indeed necessary (or kind of). I think you are conflating "necessary" with "possible." > I'll simplify your example to vwarnx(3), from the BSDs, which does less > job, but has a similar API regarding our discussion. > > I'm not sure if you meant vsyslog() uses or its implementation, but > I'll cover both (but for vwarnx(3)). > > Uses: > > This function (and all v*() functions) will be used to implement a > wrapper variadic function, like for example warnx(3). It's there, in > the variadic function, where the string /must be/ a literal, and where No, the format string does not need to be a literal at all: it can be constructed at runtime. Is that a good idea? Perhaps not. Is it possible? Yes. Can the compiler type-check it in that case? No, it cannot (since it hasn't been constructed at compile time). Consider this program: : chandra; cat warn.c #include #include #include #include int main(void) { char buf[1024]; strlcpy(buf, "%s ", sizeof(buf)); strlcat(buf, "%s ", sizeof(buf)); strlcat(buf, "%d", sizeof(buf)); warnx(buf, "Hello", "World", 42); return EXIT_SUCCESS; } : chandra; cc -Wall -Werror -o warn warn.c : chandra; ./warn warn: Hello World 42 : chandra; That's a perfectly legal C program, even if it is a silly one. "Don't do that" isn't a statement about the language, it's a statement about programmer practice, which is the point. > the arguments are checked. There's never a good reason to use a > non-literal there (AFAIK), I believe that you believe that. You may even be right. However, that's not how the language works. > and there are compiler warnings and linters > to enforce that. Since those args have been previously checked, you > should just pass the va_list pristine to other formatting functions. I'm afraid that this reasonable advice misses the point: there's nothing in the language that says you _have_ to do it this way. Some tools may _help_, but they cannot cover all (reasonable) situations. Here again `syslog()` is an interesting example, as it supports the `%m` formatting verb. _An_ implementation of this may work by interpreting the format string and constructing a new one, substituting `strerror(errno)` whenever it hits "%m" and then using `snprintf` (or equivalent) to create the file string that is sent to `syslogd`. You may argue that programmers should only pass constant strings (left deliberately vague since there are reasonable cases where named string constants may be passed as a format string argument in lieu of a literal) that can be checked by clang and gcc, but again, nothing in the language _requires_ that, but the implementation of `vsyslog` that actually implements that logic has no way of knowing that its caller has done this correctly. Similarly, someone may choose to implement a templating language that converts a custom format to a new format string, but assumes that the arguments are in a `va_list` or similar. Bad idea? Probably. Legal in C? Yes. > Then, as long as libc doesn't have bugs, you're fine. That's a tall order. > In the implementation of a v*() function: > > Do /not/ touch the va_list. Just pass it to the next function. Of > course, in the end, libc will have to iterate over it and do the job, > but that's not the typical programmer's problem. Here's the libbsd > implementation of vwarnx(3), which does exactly that: no messing with > the va_list. > > $ grepc vwarnx > ./include/bsd/err.h:63: > void vwarnx(const char *format, va_list ap) > __printflike(1, 0); > > > ./src/err.c:97: > void > vwarnx(const char *format, va_list ap) > { > fprintf(stderr, "%s: ", getprogname()); > if (format) > vfprintf(stderr, format, ap); > fprintf(stderr, "\n"); > } > > > Just put a [[gnu::format(printf)]] in the outermost wrapper, which > should be using a string literal, and you'll be fine. Using a number of extensions aside here, again, that's just (sadly) not how the language works. > > but > > that's almost besides the point, which is that given that you _can_ do > > things like that, the language can't really save you by type-checking > > the arguments to printf; and once varargs are in the mix? Forget about > > it. > > Not really. You can do that _only_ if you really want. Yes, that's the point: if we're talking about language-level guarantees, the language can't help you here. It can try, and it can hit a lot of really useful cases, but not all. By contrast, formatting in Go and Rust is type-safe by construction. > If you want to > not be able, you can "drop privileges" by adding a few flags to your > compiler, such as -Werror=format-security -Werror=format-nonliteral, > and add a bunch of linters to your build system for more redundancy, > and voila, your project is now safe. Provided that you use a compiler that provides those options, or that those linters are viable in your codebase. ;-) - Dan C. From douglas.mcilroy at dartmouth.edu Sat Aug 5 07:17:24 2023 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Fri, 4 Aug 2023 17:17:24 -0400 Subject: [TUHS] python Message-ID: > Most of the time I'd rather not have to care whether the thing > I'm printing is a string, or a pointer, or an integer, or whatever: > I just want to see its value. > Go has %v for exactly this. It's very nice for debugging. Why so verbose? In Basic, PRINT required no formatting directives at all. Doug From crossd at gmail.com Sat Aug 5 07:30:21 2023 From: crossd at gmail.com (Dan Cross) Date: Fri, 4 Aug 2023 17:30:21 -0400 Subject: [TUHS] python In-Reply-To: References: Message-ID: On Fri, Aug 4, 2023 at 5:17 PM Douglas McIlroy wrote: > > Most of the time I'd rather not have to care whether the thing > > I'm printing is a string, or a pointer, or an integer, or whatever: > > I just want to see its value. > > > Go has %v for exactly this. It's very nice for debugging. > > Why so verbose? In Basic, PRINT required no formatting directives at all. There is a form in Go that doesn't require the "%v"s. : chandra; cat v.go package main import "fmt" func main() { fmt.Println("Hi", "there", "world", "pi is close to", 3.14159) } : chandra; go run v.go Hi there world pi is close to 3.14159 : chandra; I believe that `%v` exists so that one can compose it with other formatting directives of various kinds; perhaps one wants to print the string representation of an object with no additional ceremony, but wants to emit a number in some specific format. - Dan C. From jnc at mercury.lcs.mit.edu Sat Aug 5 07:40:50 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 4 Aug 2023 17:40:50 -0400 (EDT) Subject: [TUHS] Split addressing (I/D) space (inspired by the death of the python... thread) Message-ID: <20230804214050.BFD2A18C077@mercury.lcs.mit.edu> > From: Clem Cole > first two subsystems for the 11 that ran out of text space were indeed > vi and Pascal subsystems Those were at Berkeley. We've established that S-I&D were in V6 when it was released in May, 1975 - so my question is 'what was Bell doing in 1975 that needed more than 64KB?' The kernel, yeah, it could definitely use S-I&D on a larger system (especially when you remember that stock V6 didn't play any tricks with overlays, and also dedicated one segment - the correct term, used in the 1972 -11/45 processor manual - to the user structure, and one to the I/O page, limiting the non-S-I&D kernel to 48KB). But what user commands? It happens that I have a complete dump of one of the MIT systems, so I had a look to see what _we_ were running S-I&D on. Here's the list from /bin (for some reason that machine doesn't have a /usr/bin): a68 a86 c86 emacs lisp ndd send teco The lisp wasn't a serious use; I think the only thing we ever used it for was 'doctor'. So, two editors, a couple of language tools, an email tool (not sure why that one got it - maybe for creating large outgoing messages). (The ndd is probably to allow the biggest possible buffers.) Nothing in /etc, and in /lib, just lint1 and lint2 (lint, AFAICT, post-dates V6). Not a lot. So now I'm really curious what Bell was using S-I&D for. (If I weren't lazy, I'd pull the V6 distro - which is only available as RK images, and individual files, alas - and look in /bin and everywhere and see if I can find anything. I suspect not, though.) Anyone have any guesses/suggestions? Maybe some custom applications? Noel From robpike at gmail.com Sat Aug 5 08:36:48 2023 From: robpike at gmail.com (Rob Pike) Date: Sat, 5 Aug 2023 08:36:48 +1000 Subject: [TUHS] python In-Reply-To: References: Message-ID: And neither does go. fmt.Print(x) prints x, using its default format, which is not coincidentally available in Printf as %v. -rob On Sat, Aug 5, 2023 at 7:17 AM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > > Most of the time I'd rather not have to care whether the thing > > I'm printing is a string, or a pointer, or an integer, or whatever: > > I just want to see its value. > > > Go has %v for exactly this. It's very nice for debugging. > > Why so verbose? In Basic, PRINT required no formatting directives at all. > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sat Aug 5 11:46:19 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sat, 05 Aug 2023 01:46:19 +0000 Subject: [TUHS] [COFF] Re: What Happened to Interdata? In-Reply-To: References: Message-ID: Steve thank you for the recollections, that is precisely the sort of story I was hoping to hear regarding your Interdata work. I had found myself quite curious why it would have wound up on a shelf after the work involved, and that makes total sense. That's a shame too, it sounds like the 8/32 could've picked up quite some steam, especially beating the VAX to the punch as a UNIX platform. But hey, it's a good thing so much else precipitated from your work! Also, those sorts of microarchitectural bugs keep me up at night. For all the good in RISC-V there are also now maaaaany fabs with more license than ever to pump out questionable ICs. Combine that with questionable boards with strange bus architectures, and gee our present time sure does present ripe opportunities to experiment with tackling those sorts of problems in software. Can't say I've had the pleasure but it would be nice to still be able to fix stuff with a wire wrap in the field... - Matt G. P.S. TUHS cc as promised, certainly relevant information re: Interdata 8/32 UNIX. ------- Original Message ------- On Friday, August 4th, 2023 at 6:17 PM, scj at yaccman.com wrote: > Sorry for the year's delay in responding... I wrote the compiler for the Interdata, and Dennis and I did much of the debugging. The Interdata had much easier addressing for storage: the IBM machine made you load a register, and then you had a limited offset from that register that you could use. I think IBM was 10 bits, maybe 12. But all of it way too small to run megabyte-sized programs. The Interdata allowed a larger memory offset and pretty well eliminated the offsets as a problem. I seem to recall some muttering from Dennis and Ken about the I/O structure, which was apparently somewhat strange but much less weird than the IBM. > > Also, IBM and Interdata were big-endian, and the PDP was little-endian. This gave Dennis and Ken some problems since it was easy to get the wrong endian, which blew gaskets when executed or copied into the file system. Eventually, we got the machine running, and it was quite nice: true 32-bit computing, it was reasonably fast, and once we got the low-level quirks out (including a famous run-in with the "you are not expected to understand this" code in the kernel, which, it turned out, was a prophecy that came true. On the whole, the project was so successful that we set up a high-level meeting with Interdata to demo and discuss cooperation. And then "the bug" hit. The machine would be running fine, and then Blam! it has lept into low memory and aborted with no hint as to what or where the fault was. > > We finally tracked down the problem. The Interdata was a microcode machine. And older Unix system calls would return -1 if they failed. In V7, we fixed this to return 0, but there was still a lot of user code that used the old convention. When the Interdata saw a request to load -1 it first noticed that the integer load was not on an address divisible by 4, and jumped to a location in the microcode and executed a couple of microinstructions. But then it also noticed that the address was out of range and entered the microcode again, overwriting the original address that caused the problem and freezing the machine with no indication of where the problem was. It took us only a day or two to see what the problem was, and it was hardware, and they would need to fix it. We had our meeting with Interdata, gave a pretty good sales pitch on Unix, and then said that the bug we had found was fatal and needed to be fixed or the deal was off. The bottom line, they didn't want to fix the bug in the hardware. They did come out with a Unix port several years later, but I was out of the loop for that one, and the Vax (with the UCB paging code) had become the machine of choice... > > --- > > On 2023-07-25 16:23, segaloco via COFF wrote: > >> So I've been studying the Interdata 32-bit machines a bit more closely lately and I'm wondering if someone who was there at the time has the scoop on what happened to them. The Wikipedia article gives some good info on their history but not really anything about, say, failed follow-ons that tanked their market, significant reasons for avoidance, or anything like that. I also find myself wondering why Bell didn't do anything with the Interdata work after springboarding further portability efforts while several other little streams, even those unreleased like the S/370 and 8086 ports seemed to stick around internally for longer. Were Interdata machines problematic in some sort of way, or was it merely fate, with more popular minis from DEC simply spacing them out of the market? Part of my interest too comes from what influence the legacy of Interdata may have had on Perkin-Elmer, as I've worked with Perkin-Elmer analytical equipment several times in the chemistry-side of my career and am curious if I was ever operating some vague descendent of Interdata designs in the embedded controllers in say one of my mass specs back when. >> >> - Matt G. >> >> P.S. Looking for more general history hence COFF, but towards a more UNIXy end, if there's any sort of missing scoop on the life and times of the Bell Interdata 8/32 port, for instance, whether it ever saw literally any production use in the System or was only ever on the machines being used for the portability work, I'm sure that could benefit from a CC to TUHS if that history winds up in this thread. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pugs78 at gmail.com Sat Aug 5 13:46:05 2023 From: pugs78 at gmail.com (Tom Lyon) Date: Fri, 4 Aug 2023 20:46:05 -0700 Subject: [TUHS] [COFF] Re: What Happened to Interdata? In-Reply-To: References: Message-ID: Here's my summer activity report on my work porting V6 code to the Interdata, working closely under Steve and Dennis. I left before the nasty bug was discovered. (I think). https://akapugsblog.files.wordpress.com/2018/05/inter-unix_portability.pdf On Fri, Aug 4, 2023 at 6:46 PM segaloco via TUHS wrote: > Steve thank you for the recollections, that is precisely the sort of story > I was hoping to hear regarding your Interdata work. I had found myself > quite curious why it would have wound up on a shelf after the work > involved, and that makes total sense. That's a shame too, it sounds like > the 8/32 could've picked up quite some steam, especially beating the VAX to > the punch as a UNIX platform. But hey, it's a good thing so much else > precipitated from your work! > > Also, those sorts of microarchitectural bugs keep me up at night. For all > the good in RISC-V there are also now maaaaany fabs with more license than > ever to pump out questionable ICs. Combine that with questionable boards > with strange bus architectures, and gee our present time sure does present > ripe opportunities to experiment with tackling those sorts of problems in > software. Can't say I've had the pleasure but it would be nice to still be > able to fix stuff with a wire wrap in the field... > > - Matt G. > > P.S. TUHS cc as promised, certainly relevant information re: Interdata > 8/32 UNIX. > ------- Original Message ------- > On Friday, August 4th, 2023 at 6:17 PM, scj at yaccman.com > wrote: > > Sorry for the year's delay in responding... I wrote the compiler for the > Interdata, and Dennis and I did much of the debugging. The Interdata had > much easier addressing for storage: the IBM machine made you load a > register, and then you had a limited offset from that register that you > could use. I think IBM was 10 bits, maybe 12. But all of it way too small > to run megabyte-sized programs. The Interdata allowed a larger memory > offset and pretty well eliminated the offsets as a problem. I seem to > recall some muttering from Dennis and Ken about the I/O structure, which > was apparently somewhat strange but much less weird than the IBM. > > Also, IBM and Interdata were big-endian, and the PDP was little-endian. > This gave Dennis and Ken some problems since it was easy to get the wrong > endian, which blew gaskets when executed or copied into the file system. > Eventually, we got the machine running, and it was quite nice: true 32-bit > computing, it was reasonably fast, and once we got the low-level quirks out > (including a famous run-in with the "you are not expected to understand > this" code in the kernel, which, it turned out, was a prophecy that came > true. On the whole, the project was so successful that we set up a > high-level meeting with Interdata to demo and discuss cooperation. And > then "the bug" hit. The machine would be running fine, and then Blam! it > has lept into low memory and aborted with no hint as to what or where the > fault was. > > We finally tracked down the problem. The Interdata was a microcode > machine. And older Unix system calls would return -1 if they failed. In > V7, we fixed this to return 0, but there was still a lot of user code that > used the old convention. When the Interdata saw a request to load -1 it > first noticed that the integer load was not on an address divisible by 4, > and jumped to a location in the microcode and executed a couple of > microinstructions. But then it also noticed that the address was out of > range and entered the microcode again, overwriting the original address > that caused the problem and freezing the machine with no indication of > where the problem was. It took us only a day or two to see what the > problem was, and it was hardware, and they would need to fix it. We had > our meeting with Interdata, gave a pretty good sales pitch on Unix, and > then said that the bug we had found was fatal and needed to be fixed or the > deal was off. The bottom line, they didn't want to fix the bug in the > hardware. They did come out with a Unix port several years later, but I > was out of the loop for that one, and the Vax (with the UCB paging code) > had become the machine of choice... > > > --- > > > > On 2023-07-25 16:23, segaloco via COFF wrote: > > So I've been studying the Interdata 32-bit machines a bit more closely > lately and I'm wondering if someone who was there at the time has the scoop > on what happened to them. The Wikipedia article gives some good info on > their history but not really anything about, say, failed follow-ons that > tanked their market, significant reasons for avoidance, or anything like > that. I also find myself wondering why Bell didn't do anything with the > Interdata work after springboarding further portability efforts while > several other little streams, even those unreleased like the S/370 and 8086 > ports seemed to stick around internally for longer. Were Interdata machines > problematic in some sort of way, or was it merely fate, with more popular > minis from DEC simply spacing them out of the market? Part of my interest > too comes from what influence the legacy of Interdata may have had on > Perkin-Elmer, as I've worked with Perkin-Elmer analytical equipment several > times in the chemistry-side of my career and am curious if I was ever > operating some vague descendent of Interdata designs in the embedded > controllers in say one of my mass specs back when. > > - Matt G. > > P.S. Looking for more general history hence COFF, but towards a more UNIXy > end, if there's any sort of missing scoop on the life and times of the Bell > Interdata 8/32 port, for instance, whether it ever saw literally any > production use in the System or was only ever on the machines being used > for the portability work, I'm sure that could benefit from a CC to TUHS if > that history winds up in this thread. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggm at algebras.org Sat Aug 5 14:09:59 2023 From: ggm at algebras.org (George Michaelson) Date: Sat, 5 Aug 2023 14:09:59 +1000 Subject: [TUHS] emacs In-Reply-To: References: <20230804023639.A620218C080@mercury.lcs.mit.edu> Message-ID: Gosling Emacs had a very handy "make the following sequence of commands a macro" feature which I used to do stupid fix ups to text files cross file. Things like "find every line which starts with x.. back up two lines and fix something else y and insert z, then save the file and go onto the next one" People laughed at me pointing to much better tools (spitbol?, sed?) But sometimes the hammer you have smashes those delicate screws into the watch case just beautifully quickly. If somewhat crudely. I liked teco. It's in the freebsd ports tree as an uplift to c I believe. G -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsg at jsg.id.au Sat Aug 5 14:34:08 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Sat, 5 Aug 2023 14:34:08 +1000 Subject: [TUHS] emacs In-Reply-To: <20230804021728.14AD318C080@mercury.lcs.mit.edu> References: <20230804021728.14AD318C080@mercury.lcs.mit.edu> Message-ID: On Thu, Aug 03, 2023 at 10:17:28PM -0400, Noel Chiappa wrote: > All the source, and documentation, such as it is, it available, here: > > http://ana-3.lcs.mit.edu/~jnc/tech/unix/teco/ > > but don't even think about running it. It's written in MACRO-11, and it used > a version of that hacked at MIT to run on UNIX. To build new versions of > that, you need a special linker - written in BCPL. So you also need the UNIX > BCPL compiler. 1bsd has a bin/teco, which runs. "teco which is of unknown origin (its mentioned in the Pascal document so I threw it in.)" Bill Joy, November 13, 1977 bin/READ_ME at&t's unix system toolchest also included a teco, according to various articles from 1985. From bakul at iitbombay.org Sat Aug 5 14:44:54 2023 From: bakul at iitbombay.org (Bakul Shah) Date: Fri, 4 Aug 2023 21:44:54 -0700 Subject: [TUHS] python In-Reply-To: References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <1f043101-4dbb-34ff-b037-85e7cc707a6e@halwitz.org> <2BF7ADB4-4851-4CF5-A6AC-0F1079D4AF78@gmail.com> Message-ID: Sorry for beating a dead horse but... What I was getting at when I invoked lisp is because I was thinking of the ability to debug live processes as opposed analyzing dead programs (core dumps). With lisps you can not only access a lot of the dynamic state of the program at the language level but (in theory) you may also be able to fix the problem and let the process continue. Especially when a program crashes rather infrequently, having access to only a core dump & stack trace can be quite frustrating. Why do we continue to live in a virtual "batch processing" world when it comes to dealing with such problems? [I once spent a month analyzing a problem a customer reported. I had guessed what the problem might be but couldn't reproduce it. In their live setup, it took 15 minutes to catch the bug with a logic analyzer!] The other thing both you and Rob pointed out is that even "well-tested" programs can crash. While you can use more type annotations even in dynamic languages to catch type errors, types are not sufficiently expressive so you always have that potential problem (and we can't *prove* large programs to be bug free). It is of course better to do all the testing you can but that typically occurs in "lab conditions", not in the real world. That is why many large services can run a small subset of servers with newer version of s/w as a "canary" to catch errors early (but that is usually a binary decision -- if the canary dies, you don't do the software update). With a dynamic language you can add situation specific tests on the fly if the program misbehaves. Live debugging should be even easier now -- with the right setup one should be attach a bot to do some initial checking etc. Instead we have apps that use 100s of MB to GBs of space but die silently. Guess we all suffer from Stockholm Syndrome! > On Aug 3, 2023, at 3:05 PM, Dan Cross wrote: > > On Thu, Aug 3, 2023 at 11:21 AM will.senn at gmail.com wrote: >> Nice. I've never appreciated type checking at 'compile' time, but I understand why others might (ocd). C was my first exposure to blending types, then Perl was fuzzier, then Python was even better at pretending types didn't matter. Now, with Lisp, I am freed from type concerns... until I'm not. Thankfully, it's my choice. > > Types in programming languages vary across two axes: strong versus > weak, and static versus dynamic. Common Lisp is strongly typed: for > example, you cannot add an integer to a list, or `cons` something onto > a vector (Common Lisp vectors are not lists). > > Indeed, exactly the former caused a production outage in a large Lisp > system I worked on for about a year: someone had needed to store a > pair of integers, so they used a CONS cell; after a while, the pair > needed to be expanded to a triple, so someone converted the single > CONS cell into a (proper) list. Consequently, the function for > accessing the second value went from being CDR to CADR (or `SECOND`), > but the programmer missed one place: the value of `(cdr foo)`, now a > list, was passed to some function that expected a fixnum and tried to > add something to it: this, of course, ran afoul of the type system and > raised a condition, which resulted as an ISE in prod. The fix was > trivial (change CDR to SECOND in the right place) but it really struck > me that if the system were statically typed, this would have been > trivially discovered at compile-time. > > On the other axis, Lisps are usually dynamically typed, which in this > context, means that the type of a value associated with a symbol may > change over time and one matters when the value is actually used. > Common Lisp does allow you to declare types in some limited regards; > these are usually hints to the compiler for code generation. > Conversely, in statically typed languages, the type of every value is > known at all times (particularly at compile time). > > Incidentally, this episode --- along with something similar in a > Python program --- really soured me on dynamically-typed languages. > The python failure was particularly maddening: it was heavily unit > tested (100% coverage) but as soon as we put it out, we immediately > got an error report: a type error with processing the arguments to > `main` (Google had some non-standard internal libraries for that that > were challenging to test). This was highly frustrating: like Rob, I > greatly prefer strong, static typing. > > Incidentally, C is weakly (you can add a pointer to an integer: the > result is another pointer), but statically typed. > > - Dan C. > >> On August 3, 2023 9:56:22 AM CDT, Dan Halbert wrote: >>> >>> Python has optional type annotations. There are batch tools (e.g., MyPy) to do type analysis and IDE's also provide help. Example: >>> >>> def greeting(name: str) -> str: >>> return 'Hello ' + name >>> >>> I found Python to be an enormous improvement over Perl for writing the kinds of things I used to write in Perl, with the Perl book at my side. I currently make my living working on Python for microcontrollers. Neverthless, I am fond of type checking too, and if I were writing a large Python system, I would use type annotations. >>> >>> I have used BCPL too, in the 70's, and we achieved some measure of type safety by careful naming. >>> >>> Dan H. >>> >>> On 8/3/23 10:19, Bakul Shah wrote: >>> >>> I have not heard such horror stories about Common Lisp (or may be I have forgotten them!). My impression is that python doesn't quite have the kind of {meta,}programming tools Common Lisp has. CL has been used for large critical programs. Perhaps Von Rossum had more experience with statically typed languages than Lisp (because -- pure speculation here -- if he had used CL enough, he would never have designed python :-) >>> >>> On Aug 3, 2023, at 1:32 AM, Rob Pike wrote: >>> >>> I once inherited maintenance of a critical piece of infrastructure written in exquisitely well written, tested, and documented Python. I mean it, it was really really good. >>> >>> It crashed about once a week and I had to fix it over and over because in those exponentially vast combinations of paths through the code would arise yet another way to turn a string into a list, or something analogous. It was hell. >>> >>> Critical code needs static typing. >>> >>> -rob >>> >>> >>> On Thu, Aug 3, 2023 at 1:56 PM Bakul Shah wrote: >>>> >>>> python can certainly implement tail call optimization (TCO). Pretty much any language can implement TCO but for some reason people think such programs are harder to debug (and yet they don't similarly complain about loops!). The beauty of Scheme was that it *mandated* tail recursion. >>>> >>>>> On Aug 2, 2023, at 8:24 PM, George Michaelson wrote: >>>>> >>>>> Tail recursion not lazy eval. >>>>> >>>>> I wish words meant what I meant "inside" when I think them, not >>>>> "outside" what they mean when I write them. >>>> >>> >>> >> -- Sent from /e/OS Mail. From egbegb2 at gmail.com Sat Aug 5 15:40:29 2023 From: egbegb2 at gmail.com (Ed Bradford) Date: Sat, 5 Aug 2023 00:40:29 -0500 Subject: [TUHS] python In-Reply-To: <20230804194706.GJ24315@mcvoy.com> References: <8246.1690761540@cesium.clock.org> <29602.1690887524@cesium.clock.org> <20230803005106.GA12652@mcvoy.com> <20230804194706.GJ24315@mcvoy.com> Message-ID: Thanks Larry. I've found printf a jump in usability among the languages I've used (FORTRAN, Visual Basic, Java, PHP and a few more). Python3's f-strings are a major readability/suportability advance over printf. There is nothing I know of as usable, readable, and supportable. I have yet to find anything I can't do with f-strings than I could with printf. There must be some one who has pros and cons of f-strings on this list? I would like to hear thoughts. Ed On Fri, Aug 4, 2023 at 2:47 PM Larry McVoy wrote: > We did something sort of like that in Little, all double quoted strings > look for ${anything} in the string and evaluates it and prints. Like > fstrings, you can do puts("Print 5 + 7 = ${5 + 7}"); > > We used single quoted strings as pure strings. > > It's handy and sometimes more readable than printf. > > http://www.little-lang.org/little.html#String_interpolation > > On Fri, Aug 04, 2023 at 02:20:06PM -0500, Ed Bradford wrote: > > To all: > > > > Python 3's fstrings > > https://realpython.com/python-f-strings/ > > seem to me to be a huge improvement over printf > > and its close relatives. > > > > What are people's views about the pro's and con's and > > how do print and strings compare in usability? > > > > Ed > > > > > > On Wed, Aug 2, 2023 at 9:07???PM Clem Cole wrote: > > > > > IMO (Like Larry) no printf stinks. But the real killer for my sustain > for > > > Python is the use white space and being typeless. My daughter loves > it > > > for her cloud development and we argue a bit. But it was the first > > > language she really mastered in college and she never took a > competitive > > > languages course so I???m not so sure really had experienced much > beyond it > > > for real programs. Maybe I???m just an old fart but between C, Go > and Rust > > > I???m pretty good. I do write scripts in Bourne shell and or awk > truth be > > > known. > > > > > > On Wed, Aug 2, 2023 at 8:51 PM Larry McVoy wrote: > > > > > >> On Wed, Aug 02, 2023 at 07:49:18PM -0400, Rich Salz wrote: > > >> > > [Python is] meant for mainly functional programming as I > understand it > > >> > > > >> > Not true. It has some neat functional features (list > comprehensions) but > > >> > that's not really its intent. > > >> > > >> I've really tried to like python but any language that doesn't has > printf > > >> as builtin is not for me. Yes, I know about their library printf but > it > > >> is weird. > > >> -- > > >> --- > > >> Larry McVoy Retired to fishing > > >> http://www.mcvoy.com/lm/boat > > >> > > > -- > > > Sent from a handheld expect more typos than usual > > > > > > > > > -- > > Advice is judged by results, not by intentions. > > Cicero > > -- > --- > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > -- Advice is judged by results, not by intentions. Cicero -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Sun Aug 6 06:08:14 2023 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sat, 05 Aug 2023 22:08:14 +0200 Subject: [TUHS] Fwd: Message from the family of Bram Moolenaar Message-ID: <20230805200814.wmKYk%steffen@sdaoden.eu> I do not know whether it is right, and i am surely not the right person to mourn in public, but i wanted to forward this. I only spoke to him once, he mailed me in private, but i could not help him supporting Uganda, even though i admired what he was doing, and often looked. Local capacity building, and (mutual) respect for local culture and practice, despite all sharp spikes and edges the storm causes over time, that is surely the way to do it right. --- Forwarded from Bram Moolenaar --- Sender: vim_announce at googlegroups.com To: vim_announce at googlegroups.com Subject: Message from the family of Bram Moolenaar Message-Id: <20230805121930.4AA8F1C0A68 at moolenaar.net> Date: Sat, 5 Aug 2023 13:19:30 +0100 (WEST) From: Bram Moolenaar Reply-To: vim_announce at googlegroups.com List-ID: Dear all, It is with a heavy heart that we have to inform you that Bram Moolenaar passed away on 3 August 2023. Bram was suffering from a medical condition that progressed quickly over the last few weeks. Bram dedicated a large part of his life to VIM and he was very proud of the VIM community that you are all part of. We as family are now arranging the funeral service of Bram which will take place in The Netherlands and will be held in the Dutch lanuage. The extact date, time and place are still to be determined. Should you wish to attend his funeral then please send a message to funeralbram at gmail.com. This email address can also be used to get in contact with the family regarding other matters, bearing in the mind the situation we are in right now as family. With kind regards, The family of Bram Moolenaar -- -- You received this message from the "vim_announce" maillist. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_announce" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_announce+unsubscribe at googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_announce/20230805121930.4AA8F1C0A68%40moolenaar.net. -- End forward <20230805121930.4AA8F1C0A68 at moolenaar.net> --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 scj at yaccman.com Sun Aug 6 09:00:55 2023 From: scj at yaccman.com (scj at yaccman.com) Date: Sat, 05 Aug 2023 16:00:55 -0700 Subject: [TUHS] Early multiprocessor Unix In-Reply-To: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl> References: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl> Message-ID: <4726704a3c0e056d6e4d5dd1dc582116@yaccman.com> When I left Bell Labs in 1986, I joined Ardent Computer in California. We built a multiprocessor Unix system with up to four processors based on ECL technology (faster than the computer chips of the time). The CPU had a standard set of registers, and there were four vector registers that would hold 1000 floating-point numbers and vector instructions to do arithmetic. So that meant that we had compiler work to do. Luckily, Randy Allen had just graduated and signed on to do the parallelism. I took on the job of doing the assembler, loader, parallelizing C and FORTRAN compilers, and I did the lower-level stuff: assembler, loader, designed the a.out format, and even wrote a bug tracking system. Randy's compiler was excellent, but there were other problems. The Sun workstations had some quirks: from time to time they would page in a page of all zeros due to a timing problem. Unhappily, the zero was the halt operation! We addressed that by adding code to the Kernel the verify that no code page was all 0's before executing. AT&T and Sun and MIPS and all the hardware makers have problems like this with early chips. One thing I had told the team from the beginning was that we were going to have to patch hardware problems in the early versions. The most serious early hardware bug in our machine was that when the MIPS chip had a page fault, the CPU started executing the new page before it was all present. It only missed the first two or three instructions. We settled on a strategy to generate the a.out file so that the first 4 instructions were all No-Ops. This solved the MIPS problem. Now we faced the problem of how do we take a standard a.out format and redo it so that the first four instructions in each code page are NOPs. We built an "editor" for a.out files that would read the file in, respond to a series of requests, relocate the instructions correctly, and then branch to the line of code that it had been about to execute. One good thing about this was that when the chip got fixed we would not have to change any code -- it would just work. And then we got creative. We could use the "editor" to find the basic blocks in the code, introduce counting instructions at the head of each block, and produce a profiler by recompiling. We probably found about 20 things we could do with this mechanism, including optimization after loading, timing the code without having to recompile everything, collecting parallelism statistics, etc. --- On 2022-11-28 05:24, Paul Ruizendaal wrote: > The discussion about the 3B2 triggered another question in my head: > what were the earliest multi-processor versions of Unix and how did > they relate? > > My current understanding is that the earliest one is a dual-CPU VAX > system with a modified 4BSD done at Purdue. This would have been late > 1981, early 1982. I think one CPU was acting as master and had > exclusive kernel access, the other CPU would only run user mode code. > > Then I understand that Keith Kelleman spent a lot of effort to make > Unix run on the 3B2 in a SMP setup, essentially going through the > source and finding all critical sections and surrounding those with > spinlocks. This would be around 1983, and became part of SVr3. I > suppose that the “spl()” calls only protected critical sections that > were shared between the main thread and interrupt sequences, so that a > manual review was necessary to consider each kernel data structure for > parallel access issues in the case of 2 CPU’s. > > Any other notable work in this area prior to 1985? > > How was the SMP implementation in SVr3 judged back in its day? > > Paul From scj at yaccman.com Sun Aug 6 09:53:44 2023 From: scj at yaccman.com (scj at yaccman.com) Date: Sat, 05 Aug 2023 16:53:44 -0700 Subject: [TUHS] Early Unix and Keyboard Skills In-Reply-To: References: Message-ID: <709cc67b2a5670f2038914beafd605c4@yaccman.com> I took typing in Summer School. My parents bought me a typewriter with mathematical symbols on it, which was almost worthless, and I had to improvise to get some of the standard characters (for example, the semicolon was comma/backspace/colon). By the time I was talking to computers ( Model 33 tty) I was happy that I couldn't type faster because it was impossible on that thing. Steve --- On 2022-11-02 00:11, Rob Pike wrote: > Neither ken nor dmr were impressive typists. In fact few programmers were then, at least of my acquaintance. > > In the 1970s Bell Labs created the Getset - think of it as an early wired smartphone, or a Minitel, with a little screen and keyboard. It cost quite a bit but was a cool gadget so the executives all got one. But, in fascinating contrast to the Blackberry a generation later, no one would touch it - literally - because it had a keyboard, and keyboards were for (female) secretaries, not (male) executives. The product, although well ahead of its time, was a complete failure due to the cultural bias then. > > There may be a good sociology paper in there somewhere. > > I'm not saying K&D shared this blinkered view, not at all, just that typing skills were not de facto back then. Some of the folks were even two-finger jabbers. I was a little younger and a faster typist than most of the others, and I am not a good typist by any modern standard. > > bwk was one who could smash out the text faster than many. His having learned on a teletype, the keyboard would resound with the impact of his forceful keystrokes. > > -rob > > On Wed, Nov 2, 2022 at 5:53 PM Michael Kjörling wrote: > >> On 2 Nov 2022 13:36 +1100, from sjenkin at canb.auug.org.au (steve jenkin): >>> There's at least one Internet meme that highly productive coders >>> necessarily have good keyboard skills, which leads to also producing >>> documentation or, at least, not avoiding it entirely, as often >>> happens commercially. >> >> I wouldn't be so sure that this necessarily follows. Good keyboard >> skills definitely help with the mechanics of typing code as well as >> text, I'll certainly grant that; but someone can be a good typist yet >> write complete gibberish, or be a poor/slow typist and _by necessity_ >> need to consider each word that they use because typing an extra >> sentence takes them so long. If it takes you ten seconds to type out a >> normal sentence, revising becomes less of an issue than if typing out >> the same sentence takes a minute or a minute and a half. >> >> Also, certainly in my case and I doubt that I'm alone, a lot of my >> time "coding" isn't spent doing the mechanics of "writing code", but >> rather considering possible solutions to a problem, and what the >> consequences would be of different choices. That part of the software >> development process is essentially unaffected by how good one is as a >> typist, and I expect that the effect would be even more pronounced for >> someone using something like an ASR-33 and edlin, than a modern >> computer and visual editor. Again, the longer it takes to revise >> something, the more it makes sense to get it right on the first >> attempt, even if that means some preparatory work up-front. >> >> Writing documentation is probably more an issue of mindset and being >> allowed the time, than it is a question of how good one is as a >> typist. >> >> -- >> 🪶 Michael Kjörling 🏡 https://michael.kjorling.se >> "Remember when, on the Internet, nobody cared that you were a dog?" -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sun Aug 6 10:15:40 2023 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 5 Aug 2023 17:15:40 -0700 Subject: [TUHS] Fwd: Message from the family of Bram Moolenaar In-Reply-To: <20230805200814.wmKYk%steffen@sdaoden.eu> References: <20230805200814.wmKYk%steffen@sdaoden.eu> Message-ID: <20230806001540.GF19141@mcvoy.com> I've used vim for a very long time, super grateful for Bram's work. Vim has all of the usefulness of vi and then tossed in buffers so vi wasn't worse than emacs, I doubt I've used 10% of the stuff that he added to vim. For me, it was a portable vi that worked everywhere, faithful to vi, with buffers. I use it every day, I'm typing this email in it. He was only 62, so sad. He will be missed and remembered. :help iccf and perhaps donate in his memory, I will. On Sat, Aug 05, 2023 at 10:08:14PM +0200, Steffen Nurpmeso wrote: > I do not know whether it is right, and i am surely not the right > person to mourn in public, but i wanted to forward this. > > I only spoke to him once, he mailed me in private, but i could not > help him supporting Uganda, even though i admired what he was > doing, and often looked. > > Local capacity building, and (mutual) respect for local culture > and practice, despite all sharp spikes and edges the storm causes > over time, that is surely the way to do it right. > > --- Forwarded from Bram Moolenaar --- > Sender: vim_announce at googlegroups.com > To: vim_announce at googlegroups.com > Subject: Message from the family of Bram Moolenaar > Message-Id: <20230805121930.4AA8F1C0A68 at moolenaar.net> > Date: Sat, 5 Aug 2023 13:19:30 +0100 (WEST) > From: Bram Moolenaar > Reply-To: vim_announce at googlegroups.com > List-ID: > > Dear all, > > It is with a heavy heart that we have to inform you that Bram Moolenaar passed away on 3 August 2023. > Bram was suffering from a medical condition that progressed quickly over the last few weeks. > > Bram dedicated a large part of his life to VIM and he was very proud of the VIM community that you are all part of. > > We as family are now arranging the funeral service of Bram which will take place in The Netherlands and will be held in the Dutch lanuage. The extact date, time and place are still to be determined. > Should you wish to attend his funeral then please send a message to funeralbram at gmail.com. This email address can also be used to get in contact with the family regarding other matters, bearing in the mind the situation we are in right now as family. > > With kind regards, > The family of Bram Moolenaar > > -- > -- > You received this message from the "vim_announce" maillist. > For more information, visit http://www.vim.org/maillist.php > --- > You received this message because you are subscribed to the Google Groups "vim_announce" group. > To unsubscribe from this group and stop receiving emails from it, send an email to vim_announce+unsubscribe at googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/vim_announce/20230805121930.4AA8F1C0A68%40moolenaar.net. > > -- End forward <20230805121930.4AA8F1C0A68 at moolenaar.net> > > --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) -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From ken.unix.guy at gmail.com Sun Aug 6 10:22:17 2023 From: ken.unix.guy at gmail.com (KenUnix) Date: Sat, 5 Aug 2023 20:22:17 -0400 Subject: [TUHS] Early Unix and Keyboard Skills In-Reply-To: <709cc67b2a5670f2038914beafd605c4@yaccman.com> References: <709cc67b2a5670f2038914beafd605c4@yaccman.com> Message-ID: The thing I like is VI because it is almost universal. Windows, Linux, BSD and Unix. In a pinch I use "ed". Sad to hear today that its creator has passed away. --Ken On Sat, Aug 5, 2023 at 7:53 PM wrote: > I took typing in Summer School. My parents bought me a typewriter with > mathematical symbols on it, which was almost worthless, and I had to > improvise to get some of the standard characters (for example, the > semicolon was comma/backspace/colon). By the time I was talking to > computers ( Model 33 tty) I was happy that I couldn't type faster because > it was impossible on that thing. > > Steve > --- > > > > On 2022-11-02 00:11, Rob Pike wrote: > > Neither ken nor dmr were impressive typists. In fact few programmers were > then, at least of my acquaintance. > > In the 1970s Bell Labs created the Getset - think of it as an early wired > smartphone, or a Minitel, with a little screen and keyboard. It cost quite > a bit but was a cool gadget so the executives all got one. But, in > fascinating contrast to the Blackberry a generation later, no one would > touch it - literally - because it had a keyboard, and keyboards were for > (female) secretaries, not (male) executives. The product, although well > ahead of its time, was a complete failure due to the cultural bias then. > > There may be a good sociology paper in there somewhere. > > I'm not saying K&D shared this blinkered view, not at all, just that > typing skills were not de facto back then. Some of the folks were even > two-finger jabbers. I was a little younger and a faster typist than most of > the others, and I am not a good typist by any modern standard. > > bwk was one who could smash out the text faster than many. His having > learned on a teletype, the keyboard would resound with the impact of his > forceful keystrokes. > > -rob > > > > > On Wed, Nov 2, 2022 at 5:53 PM Michael Kjörling > wrote: > > On 2 Nov 2022 13:36 +1100, from sjenkin at canb.auug.org.au (steve jenkin): > > There's at least one Internet meme that highly productive coders > > necessarily have good keyboard skills, which leads to also producing > > documentation or, at least, not avoiding it entirely, as often > > happens commercially. > > I wouldn't be so sure that this necessarily follows. Good keyboard > skills definitely help with the mechanics of typing code as well as > text, I'll certainly grant that; but someone can be a good typist yet > write complete gibberish, or be a poor/slow typist and _by necessity_ > need to consider each word that they use because typing an extra > sentence takes them so long. If it takes you ten seconds to type out a > normal sentence, revising becomes less of an issue than if typing out > the same sentence takes a minute or a minute and a half. > > Also, certainly in my case and I doubt that I'm alone, a lot of my > time "coding" isn't spent doing the mechanics of "writing code", but > rather considering possible solutions to a problem, and what the > consequences would be of different choices. That part of the software > development process is essentially unaffected by how good one is as a > typist, and I expect that the effect would be even more pronounced for > someone using something like an ASR-33 and edlin, than a modern > computer and visual editor. Again, the longer it takes to revise > something, the more it makes sense to get it right on the first > attempt, even if that means some preparatory work up-front. > > Writing documentation is probably more an issue of mindset and being > allowed the time, than it is a question of how good one is as a > typist. > > -- > 🪶 Michael Kjörling 🏡 https://michael.kjorling.se > "Remember when, on the Internet, nobody cared that you were a dog?" > > -- End of line JOB TERMINATED -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sun Aug 6 10:43:43 2023 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 5 Aug 2023 17:43:43 -0700 Subject: [TUHS] Early Unix and Keyboard Skills In-Reply-To: References: <709cc67b2a5670f2038914beafd605c4@yaccman.com> Message-ID: <20230806004343.GH19141@mcvoy.com> Just in case there is confusion, vi was Bill Joy, Bostic did nvi (which was open source and bug for bug compat), Bram did vim, which I think was a clean room version of vi with a huge bunch of added goodness. On Sat, Aug 05, 2023 at 08:22:17PM -0400, KenUnix wrote: > The thing I like is VI because it is almost universal. Windows, Linux, BSD > and Unix. > > In a pinch I use "ed". > > Sad to hear today that its creator has passed away. > > --Ken > > > On Sat, Aug 5, 2023 at 7:53???PM wrote: > > > I took typing in Summer School. My parents bought me a typewriter with > > mathematical symbols on it, which was almost worthless, and I had to > > improvise to get some of the standard characters (for example, the > > semicolon was comma/backspace/colon). By the time I was talking to > > computers ( Model 33 tty) I was happy that I couldn't type faster because > > it was impossible on that thing. > > > > Steve > > --- > > > > > > > > On 2022-11-02 00:11, Rob Pike wrote: > > > > Neither ken nor dmr were impressive typists. In fact few programmers were > > then, at least of my acquaintance. > > > > In the 1970s Bell Labs created the Getset - think of it as an early wired > > smartphone, or a Minitel, with a little screen and keyboard. It cost quite > > a bit but was a cool gadget so the executives all got one. But, in > > fascinating contrast to the Blackberry a generation later, no one would > > touch it - literally - because it had a keyboard, and keyboards were for > > (female) secretaries, not (male) executives. The product, although well > > ahead of its time, was a complete failure due to the cultural bias then. > > > > There may be a good sociology paper in there somewhere. > > > > I'm not saying K&D shared this blinkered view, not at all, just that > > typing skills were not de facto back then. Some of the folks were even > > two-finger jabbers. I was a little younger and a faster typist than most of > > the others, and I am not a good typist by any modern standard. > > > > bwk was one who could smash out the text faster than many. His having > > learned on a teletype, the keyboard would resound with the impact of his > > forceful keystrokes. > > > > -rob > > > > > > > > > > On Wed, Nov 2, 2022 at 5:53 PM Michael Kj??rling > > wrote: > > > > On 2 Nov 2022 13:36 +1100, from sjenkin at canb.auug.org.au (steve jenkin): > > > There's at least one Internet meme that highly productive coders > > > necessarily have good keyboard skills, which leads to also producing > > > documentation or, at least, not avoiding it entirely, as often > > > happens commercially. > > > > I wouldn't be so sure that this necessarily follows. Good keyboard > > skills definitely help with the mechanics of typing code as well as > > text, I'll certainly grant that; but someone can be a good typist yet > > write complete gibberish, or be a poor/slow typist and _by necessity_ > > need to consider each word that they use because typing an extra > > sentence takes them so long. If it takes you ten seconds to type out a > > normal sentence, revising becomes less of an issue than if typing out > > the same sentence takes a minute or a minute and a half. > > > > Also, certainly in my case and I doubt that I'm alone, a lot of my > > time "coding" isn't spent doing the mechanics of "writing code", but > > rather considering possible solutions to a problem, and what the > > consequences would be of different choices. That part of the software > > development process is essentially unaffected by how good one is as a > > typist, and I expect that the effect would be even more pronounced for > > someone using something like an ASR-33 and edlin, than a modern > > computer and visual editor. Again, the longer it takes to revise > > something, the more it makes sense to get it right on the first > > attempt, even if that means some preparatory work up-front. > > > > Writing documentation is probably more an issue of mindset and being > > allowed the time, than it is a question of how good one is as a > > typist. > > > > -- > > ???? Michael Kj??rling ???? https://michael.kjorling.se > > "Remember when, on the Internet, nobody cared that you were a dog?" > > > > > > -- > End of line > JOB TERMINATED -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From lm at mcvoy.com Sun Aug 6 10:54:31 2023 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 5 Aug 2023 17:54:31 -0700 Subject: [TUHS] Early multiprocessor Unix In-Reply-To: <4726704a3c0e056d6e4d5dd1dc582116@yaccman.com> References: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl> <4726704a3c0e056d6e4d5dd1dc582116@yaccman.com> Message-ID: <20230806005431.GI19141@mcvoy.com> On Sat, Aug 05, 2023 at 04:00:55PM -0700, scj at yaccman.com wrote: > The Sun workstations > had some quirks: from time to time they would page in a page of all zeros > due to a timing problem. Was this over NFS? Because that was a thing. Paging in from disc I've never heard of this. BTW, scj, loving your walk through history. I'd love to read drafts of your management book. My entire career I waited to meet a person that got as much joy out of managing as I got out of engineering. Still waiting. From sjenkin at canb.auug.org.au Sun Aug 6 11:34:25 2023 From: sjenkin at canb.auug.org.au (steve jenkin) Date: Sun, 6 Aug 2023 11:34:25 +1000 Subject: [TUHS] Fwd: Message from the family of Bram Moolenaar In-Reply-To: <20230805200814.wmKYk%steffen@sdaoden.eu> References: <20230805200814.wmKYk%steffen@sdaoden.eu> Message-ID: <3974A8C4-9918-4369-BA03-C77C6525795E@canb.auug.org.au> Steffen, Thanks very much for the note. The world for me is a greyer place with his passing. Lots of articles on the ’Net of his passing. s > On 6 Aug 2023, at 06:08, Steffen Nurpmeso wrote: > > I do not know whether it is right, and i am surely not the right > person to mourn in public, but i wanted to forward this. =========== Main author of Vim, the text editor. I have been working on all kinds of software, from machine code and assembly, via embedded software to user interfaces and web applications. Spending most of my time working on Vim 9 script: faster, better. Now retired. Last work i did for Google was modernizing Merchant Center. Worked on a nice new programming language: Zimbu. Paused for now. Specialties: Spell checking algorithms, complex designs, being different. =========== A Tribute to Bram Moolenaar, The Maestro Behind Vim Code Editor In a profound loss to the world of computing and software development, Bram Moolenaar, the creator of the widely respected Vim code editor, has passed away at the age of 62. The family announced his passing in a heartfelt Google Groups message on August 5, revealing a sudden progression of a medical condition that had afflicted him. =========== Family Announcement =========== -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin From cowan at ccil.org Sun Aug 6 11:42:32 2023 From: cowan at ccil.org (John Cowan) Date: Sat, 5 Aug 2023 21:42:32 -0400 Subject: [TUHS] Fwd: Message from the family of Bram Moolenaar In-Reply-To: <20230806001540.GF19141@mcvoy.com> References: <20230805200814.wmKYk%steffen@sdaoden.eu> <20230806001540.GF19141@mcvoy.com> Message-ID: On Sat, Aug 5, 2023 at 8:15 PM Larry McVoy wrote: I've used vim for a very long time, super grateful for Bram's work. Vim > has all of the usefulness of vi and then tossed in buffers so vi wasn't > worse than emacs, I doubt I've used 10% of the stuff that he added to > vim. I doubt if anyone has, with the possible exception of Bram himself. Vim's UI is the very model of a non-compact interface. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sun Aug 6 12:03:45 2023 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 5 Aug 2023 19:03:45 -0700 Subject: [TUHS] Fwd: Message from the family of Bram Moolenaar In-Reply-To: References: <20230805200814.wmKYk%steffen@sdaoden.eu> <20230806001540.GF19141@mcvoy.com> Message-ID: <20230806020345.GJ19141@mcvoy.com> On Sat, Aug 05, 2023 at 09:42:32PM -0400, John Cowan wrote: > On Sat, Aug 5, 2023 at 8:15???PM Larry McVoy wrote: > > I've used vim for a very long time, super grateful for Bram's work. Vim > > has all of the usefulness of vi and then tossed in buffers so vi wasn't > > worse than emacs, I doubt I've used 10% of the stuff that he added to > > vim. > > > I doubt if anyone has, with the possible exception of Bram himself. Vim's > UI is the very model of a non-compact interface. Not gonna engage. I got a lot of usefulness from vim in the last 30 years, it's been my editor of choice. I'm grateful for it, it was better than I could have done. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From pnr at planet.nl Sun Aug 6 16:52:20 2023 From: pnr at planet.nl (Paul Ruizendaal) Date: Sun, 6 Aug 2023 13:52:20 +0700 Subject: [TUHS] Early multiprocessor Unix In-Reply-To: <4726704a3c0e056d6e4d5dd1dc582116@yaccman.com> References: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl> <4726704a3c0e056d6e4d5dd1dc582116@yaccman.com> Message-ID: Thank you for sharing, very interesting context info! It would seem to me that there was only limited work on multi-processor Unix prior to 1985, with the work by Bach/Buroff/Kelleman around 1983 being the defining effort. When I was doing my thesis with Prof. Van de Goor (who had earlier worked at DEC with the PDP-8 and PDP-11 design teams), another student down the corridor was working on multi-processor Unix ca. 1984-1985. There is a short paper about that work here https://dl.acm.org/doi/pdf/10.1145/6592.6598 From today’s perspective the paper’s conclusions seem odd. It describes going through the source code end-to-end as a huge job, but the core SysIII kernel is only some 7,000 sloc, with maybe two dozen shared data structures. On the other hand, with the tooling of the early 1980’s debugging this stuff must have been very hard. In contrast, on my porting projects today it is very easy to generate a kernel trace for millions of instructions in a few seconds. Even billions is do-able. The edit/compile/test cycle for a kernel with some debug test code compiled in is similarly a matter of seconds. A single test must have taken an hour or more back in the day, assuming that one had exclusive access to the machine. Also its observation that the Unix kernel is “not highly structured” seems unfair. I find the 1980-era Unix kernel rather well structured, with the exception of the memory management code which is indeed spread out over multiple files making it not so easy to fully grasp. Maybe this was what my fellow student was referring to in his MSc thesis. Also note that a Dutch MSc thesis only took 6-12 months. > On 6 Aug 2023, at 06:00, scj at yaccman.com wrote: > > When I left Bell Labs in 1986, I joined Ardent Computer in California. We built a multiprocessor Unix system with up to four processors based on ECL technology (faster than the computer chips of the time). The CPU had a standard set of registers, and there were four vector registers that would hold 1000 floating-point numbers and vector instructions to do arithmetic. > So that meant that we had compiler work to do. Luckily, Randy Allen had just graduated and signed on to do the parallelism. I took on the job of doing the assembler, loader, parallelizing C and FORTRAN compilers, and I did the lower-level stuff: assembler, loader, > designed the a.out format, and even wrote a bug tracking system. Randy's compiler was excellent, but there were other problems. The Sun workstations had some quirks: from time to time they would page in a page of all zeros due to a timing problem. Unhappily, the zero was the halt operation! We addressed that by adding code to the Kernel the verify that no code page was all 0's before executing. AT&T and Sun and MIPS and all the hardware makers have problems like this with early chips. One thing I had told the team from the beginning was that we were going to have to patch hardware problems in the early versions. > > The most serious early hardware bug in our machine was that when the MIPS chip had a page fault, the CPU started executing the new page before it was all present. It only missed the first two or three instructions. We settled on a strategy to generate the a.out file so that the first 4 instructions were all No-Ops. This solved the MIPS problem. > > Now we faced the problem of how do we take a standard a.out format and redo it so that the first four instructions in each code page are NOPs. We built an "editor" for a.out files that would read the file in, respond to a series of requests, relocate the instructions correctly, and then branch to the line of code that it had been about to execute. One good thing about this was that when the chip got fixed we would not have to change any code -- it would just work. > > And then we got creative. We could use the "editor" to find the basic blocks in the code, introduce counting instructions at the head of each block, and produce a profiler by recompiling. We probably found about 20 things we could do with this mechanism, including optimization after loading, timing the code without having to recompile everything, collecting parallelism statistics, etc. > > > --- > > > On 2022-11-28 05:24, Paul Ruizendaal wrote: >> The discussion about the 3B2 triggered another question in my head: >> what were the earliest multi-processor versions of Unix and how did >> they relate? >> My current understanding is that the earliest one is a dual-CPU VAX >> system with a modified 4BSD done at Purdue. This would have been late >> 1981, early 1982. I think one CPU was acting as master and had >> exclusive kernel access, the other CPU would only run user mode code. >> Then I understand that Keith Kelleman spent a lot of effort to make >> Unix run on the 3B2 in a SMP setup, essentially going through the >> source and finding all critical sections and surrounding those with >> spinlocks. This would be around 1983, and became part of SVr3. I >> suppose that the “spl()” calls only protected critical sections that >> were shared between the main thread and interrupt sequences, so that a >> manual review was necessary to consider each kernel data structure for >> parallel access issues in the case of 2 CPU’s. >> Any other notable work in this area prior to 1985? >> How was the SMP implementation in SVr3 judged back in its day? >> Paul From ron at ronnatalie.com Sun Aug 6 18:37:44 2023 From: ron at ronnatalie.com (Ronald Natalie) Date: Sun, 06 Aug 2023 08:37:44 +0000 Subject: [TUHS] Early Unix and Keyboard Skills In-Reply-To: <709cc67b2a5670f2038914beafd605c4@yaccman.com> References: <709cc67b2a5670f2038914beafd605c4@yaccman.com> Message-ID: When my mother asked my fifth grade teacher what she should do about my bad handwriting, she was told to get me a typewriter. I spent one summer school session taking typing. Little did we know thet in a few years, being able to type 60 WPM would be very valuable to my career. Sometimes my employees were pretty impressed when we couldn’t get data moved any other way that I’d sit down with the printout and just retype it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralph at inputplus.co.uk Sun Aug 6 19:57:17 2023 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sun, 06 Aug 2023 10:57:17 +0100 Subject: [TUHS] Early multiprocessor Unix In-Reply-To: <4726704a3c0e056d6e4d5dd1dc582116@yaccman.com> References: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl> <4726704a3c0e056d6e4d5dd1dc582116@yaccman.com> Message-ID: <20230806095717.0D9BA220FE@orac.inputplus.co.uk> Hi Steve, > We built an "editor" for a.out files that would read the file in, > respond to a series of requests, relocate the instructions correctly, > and then branch to the line of code that it had been about to execute. What level of granuality were these requests? Could you give a rough example or two. Was it sed like, with labels and testing branches? Did the requests operate on matched instructions instead of lines? -- Cheers, Ralph. From ron at ronnatalie.com Sun Aug 6 19:28:06 2023 From: ron at ronnatalie.com (Ronald Natalie) Date: Sun, 06 Aug 2023 09:28:06 +0000 Subject: [TUHS] Early multiprocessor Unix In-Reply-To: <4726704a3c0e056d6e4d5dd1dc582116@yaccman.com> References: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl> <4726704a3c0e056d6e4d5dd1dc582116@yaccman.com> Message-ID: The first foray into multiprocessor UNIX for us was to build one of the Purdue University dual vaxes (where they took the SBI terminator out, built some special cables to flipped around, and to stick a second CPU in that location. Not too much later we got a multiprocessor Gould SEL machine (also with Purdue’s hack to BSD as the OS). BRL had contracted to buy a Denelcor HEP, which was a MIMD machine capable of running 32 or so parallel tasks. Each one could be divided into multiple processes (what we would call a thread the days). The regular memory had a semaphore per word (called a full-empty bit) that allowed you to create a bunch of threads and let the hardware itself schedule them. There were four Process Execution Modules (each with 8 processors) that were interconnected by a fast memory switch, alll 10800 ECL. The thing was booted up from a PDP-11/34 front end through an interface aptly named the “low speed bus”. Mike Muuss suggested we could put UNIX on the thing and nobody could come up with a reason why not, so we ported the same 4 BSD kernel that the dual vaxes were using. Oddly, there were some bad things in the BSD kernel that needed to be fixed (notably “conversion by union” that wouldn’t work on this architecture). After the initial boot up, we found that the thing couldn’t run I/O’s very quickly as they I/Os were routed through the “low speed bus.” The hardware designer (Burton Smith) and me literally designed a new I/O interface on napkins at the local steakhouse, the Golden Corral, and built the thing out of spare parts. I donated another PDP-11/34 to the task. The I/O system was a fun system, the thing had 32 Unibuses connected to a memory cache for the main processor. You could hit the CSRs on the Unibuses virtually through mapped memory addresses. Interrupts weren’t the traditional sense but rather a new kernel task was spawned to handle it. -Ron From akosela at andykosela.com Sun Aug 6 23:30:24 2023 From: akosela at andykosela.com (Andy Kosela) Date: Sun, 6 Aug 2023 15:30:24 +0200 Subject: [TUHS] Fwd: Message from the family of Bram Moolenaar In-Reply-To: <20230806020345.GJ19141@mcvoy.com> References: <20230805200814.wmKYk%steffen@sdaoden.eu> <20230806001540.GF19141@mcvoy.com> <20230806020345.GJ19141@mcvoy.com> Message-ID: On Sunday, August 6, 2023, Larry McVoy wrote: > On Sat, Aug 05, 2023 at 09:42:32PM -0400, John Cowan wrote: > > On Sat, Aug 5, 2023 at 8:15???PM Larry McVoy wrote: > > > > I've used vim for a very long time, super grateful for Bram's work. Vim > > > has all of the usefulness of vi and then tossed in buffers so vi wasn't > > > worse than emacs, I doubt I've used 10% of the stuff that he added to > > > vim. > > Bram was using the same computer I did in 1991 -- Amiga, when he released vim. It is still a powerful platform today, especially for (retro)gaming. It was the universal editor I used everywhere -- on Amiga, MS-DOS or Unix. Still using it today on the very same platforms... Thank you, Bram, and rest in peace. --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Mon Aug 7 00:12:04 2023 From: imp at bsdimp.com (Warner Losh) Date: Sun, 6 Aug 2023 08:12:04 -0600 Subject: [TUHS] Early multiprocessor Unix In-Reply-To: References: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl> Message-ID: On Mon, Nov 28, 2022 at 7:07 AM Clem Cole wrote: > As far as I know, the first non-commercial work was done at the Naval Post > Grad school with V6. I have never seen the code for it, only a paper, so I > don't know too much about it to comment. > The data of the paper suggests a V5 base since the paper is 1 month after the V6 release. I couple of us tried to track down the author and/or advisors and found one retired who said that code is long gone and he couldn't help me. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Mon Aug 7 00:19:01 2023 From: imp at bsdimp.com (Warner Losh) Date: Sun, 6 Aug 2023 08:19:01 -0600 Subject: [TUHS] Early multiprocessor Unix In-Reply-To: References: <7C8CADAB-65AA-4841-AFA1-569A9651E56D@planet.nl> Message-ID: On Mon, Nov 28, 2022 at 7:15 AM Clem Cole wrote: > Paul, the other thing I should point out -- ghg's work was > widely distributed amount the BSD licenses. I somewhat wonder why the Naval > Post Grad school's work was not. My guess is that USENIX was still in its > formative stages when the latter did their work, whereas, by the time of > George's hack, BSD/Vaxen was being used for teaching as University > timesharing systems so his 'upgrade' was a cheap solution. > ᐧ > Also the Naval Post Grad work was on a fairly specialized MP pdp-11/50 system that wasn't super easy to build... plus the paper was declassified, but it's not clear that the code ever was, or even submitted for declassification. It was super early still in the unix sharing culture evolution and wide-spread distribution didn't catch on. Plus, it was for a funky odd custom thing, which limited people wanting to ask for it. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From leah at vuxu.org Mon Aug 7 00:51:04 2023 From: leah at vuxu.org (Leah Neukirchen) Date: Sun, 06 Aug 2023 16:51:04 +0200 Subject: [TUHS] Early Unix and Keyboard Skills In-Reply-To: <20230806004343.GH19141@mcvoy.com> (Larry McVoy's message of "Sat, 5 Aug 2023 17:43:43 -0700") References: <709cc67b2a5670f2038914beafd605c4@yaccman.com> <20230806004343.GH19141@mcvoy.com> Message-ID: <87il9s442v.fsf@vuxu.org> Larry McVoy writes: > Just in case there is confusion, vi was Bill Joy, Bostic did nvi (which was > open source and bug for bug compat), Bram did vim, which I think was a > clean room version of vi with a huge bunch of added goodness. Vim was based on Stevie, an Atari ST vi clone he ported to the Amiga 2000. -- Leah Neukirchen https://leahneukirchen.org/ From lm at mcvoy.com Mon Aug 7 01:01:23 2023 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 6 Aug 2023 08:01:23 -0700 Subject: [TUHS] Early Unix and Keyboard Skills In-Reply-To: <87il9s442v.fsf@vuxu.org> References: <709cc67b2a5670f2038914beafd605c4@yaccman.com> <20230806004343.GH19141@mcvoy.com> <87il9s442v.fsf@vuxu.org> Message-ID: <20230806150123.GS19141@mcvoy.com> On Sun, Aug 06, 2023 at 04:51:04PM +0200, Leah Neukirchen wrote: > Larry McVoy writes: > > > Just in case there is confusion, vi was Bill Joy, Bostic did nvi (which was > > open source and bug for bug compat), Bram did vim, which I think was a > > clean room version of vi with a huge bunch of added goodness. > > Vim was based on Stevie, an Atari ST vi clone he ported to the Amiga 2000. I remember Stevie. In my early days at Sun, on 4MB machines, I was working on log files about the size of memory so the machine swapped like crazy just to take a look. I looked at Stevie but then settled on xvi. I changed the libc string functions to treat \n as well as \0 as a string terminator, changed how xvi read in a file to use mmap() instead. It wasn't really that hard but then I had a vi clone that could work on files twice as large with no swapping. The read only path was super easy to do, I made the write path work as well, that took a little tinkering because you couldn't modify the lines in place (think changing case on a line which xvi was happy to do in place but I couldn't because I'd be changing the file data which means :q! wouldn't do what you wanted). It's of little interest now but at the time, it was a huge win for me, I was working on performance and looking at log files was a big part of that. Most of us remember what it was like to work on a working set that was bigger than memory, it sucked. From clemc at ccc.com Mon Aug 7 02:31:51 2023 From: clemc at ccc.com (Clem Cole) Date: Sun, 6 Aug 2023 12:31:51 -0400 Subject: [TUHS] Early Unix and Keyboard Skills In-Reply-To: <87il9s442v.fsf@vuxu.org> References: <709cc67b2a5670f2038914beafd605c4@yaccman.com> <20230806004343.GH19141@mcvoy.com> <87il9s442v.fsf@vuxu.org> Message-ID: On Sun, Aug 6, 2023 at 10:51 AM Leah Neukirchen wrote: > Vim was based on Stevie, an Atari ST vi clone he ported to the Amiga 2000. > Thank you. I also remember stevie and that stevie beget vim make so much sense. It was one of the clones I ran back in the day. The point is that there were (are) a number of vi clones. Which is why I started to switch to it. It ran on everything from small 8-bit systems on up. Particularly on the micros, they all had something akin to what Microsoft called edlin, often just called edit. If you knew UNIX ed(1) or any other editor from the old GED family from the 1960s, chances were you could make it do something -- but it was PITA as each was a bit different So copies of the editors from the larger [often DEC based systems] started to appear on the smaller and smaller machines. And vi seemed to be a pretty popular as a starting point[I always suspect Webb Miller's book had something to do with that since 's' was so small and using it to add missing vi features was not terrible]. That said, there was an IBM PC/386 "MS-DOS" version of vi that required ANSI.SYS that was on the market for about $50-$100. It was 'bug for bug' compatible with Joy's version. I always suspected that unlike Keith, they just took the Vax code, stripped out termcap so it did not need an external terminal database, hard coded it for ANSI.SYS, then ran it through the PHARLAP C/386 subsystem. Unlike any of the other 'clones' until nvi -- it was the only one that had some of the same wonkiness. As I understand it from him, Keith did nvi(1) because Joy's original work was based on the v6 ed(1). As part of Keith's effort to try to remove any core code in the BSD releases that had any AT&T source taint, it was just easier to start over. The Berkeley Shell [in 1BSD] beget the C Shell, was derived from Ken's sh in v5 and v6. I think Keith/Kirk et al felt that any of Ken's original code had long been removed - whereas ex(1) (vi is the actually the VIsual command for ex) probably had a lot of core ed(1). Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nobozo at gmail.com Mon Aug 7 04:20:15 2023 From: nobozo at gmail.com (Jon Forrest) Date: Sun, 6 Aug 2023 11:20:15 -0700 Subject: [TUHS] Early Unix and Keyboard Skills In-Reply-To: References: <709cc67b2a5670f2038914beafd605c4@yaccman.com> <20230806004343.GH19141@mcvoy.com> <87il9s442v.fsf@vuxu.org> Message-ID: <829ea2b4-16b5-4e7c-b9b2-f75ea9c67602@gmail.com> On 8/6/2023 9:31 AM, Clem Cole wrote: > And vi seemed to be a pretty popular as a starting point[I always > suspect Webb Miller's book had something to do with that since 's' > was so small and using it to add  missing vi features was not > terrible]. Every time this book is mentioned on TUHS I announce that I have a copy of it for sale. Contact me off-list if you're interested. Jon From norman at oclsc.org Mon Aug 7 05:46:03 2023 From: norman at oclsc.org (Norman Wilson) Date: Sun, 6 Aug 2023 15:46:03 -0400 (EDT) Subject: [TUHS] python Message-ID: <523A100F35BC4139947795C31B70303E.for-standards-violators@oclsc.org> At the risk of releasing more heat than light (so if you feel compelled to flame by this message, please reply just to me or to COFF, not to TUHS): The fussing here over Python reminds me very much of Unix in the 1980s. Specifically wars over editors, and over BSD vs System V vs Research systems, and over classic vs ISO C, and over embracing vendor-specific features (CSRG and USG counting as vendors as well as Digital, SGI, Sun, et al) vs sticking to the common core. And more generally whether any of the fussing is worth it, and whether adding stuff to Unix is progress or just pointless complication. Speaking as an old fart who no longer gets excited about this stuff except where it directly intersects something I want to do, I have concluded that nobody is entirely right and nobody is entirely wrong. Fancy new features that are there just to be fancy are usually a bad idea, especially when they just copy something from one system to a completely different one, but sometimes they actually add something. Sometimes something brand new is a useful addition, especially when its supplier takes the time and thought to fit cleanly into the existing ecosystem, but sometimes it turns out to be a dead end. Personal taste counts, but never as much as those of us brandishing it like to think. To take Python as an example: I started using it about fifteen years ago, mostly out of curiousity. It grew on me, and these days I use it a lot. It's the nearest thing to an object- oriented language that I have ever found to be usable (but I never used the original Smalltalk and suspect I'd have liked that too). It's not what I'd use to write an OS, nor to do any sort of performance-limited program, but computers and storage are so fast these days that that rarely matters to me. Using white space to denote blocks took a little getting used to, but only a little; no more than getting used to typing if ...: instead of if (...). The lack of a C-style for loop occasionally bothers me, but iterating over lists and sets handles most of the cases that matter, and is far less cumbersome. It's a higher-level language than C, which means it gets in the way of some things but makes a lot of other things easier. It turns out the latter is more significant than the former for the things I do with it. The claim that Python doesn't have printf (at least since ca. 2.5, when I started using it) is just wrong: print 'pick %d pecks of %s' % (n, fruit) is just a different spelling of printf("pick %d pecks of %s\n", n, fruit) except that sprintf is no longer a special case (and snprintf becomes completely needless). I like the modern print(f'pick {n} pecks of {fruit}') even better; f strings are what pushed me from Python 2 to Python 3. I really like the way modules work in Python, except the dumbass ways you're expected to distribute a program that is broken into modules of its own. As a low-level hacker I came up with my own way to do that (assembling them all into a single Python source file in which each module is placed as a string, evaled and inserted into the module table, and then the starting point called at the end; all using documented, stable interfaces, though they changed from 2 to 3; program actually written as a collection of individual source files, with a tool of my own--written in Python, of course--to create the single file which I can then install where I need it). I have for some years had my own hand-crafted idiosyncratic program for reading mail. (As someone I know once said, everybody writes a mailer; it's simple and easy and makes them feel important. But in this case I was doing it just for myself and for the fun of it.) The first edition was written 20 years ago in C. I rewrote it about a decade ago in Python. It works fine; can now easily deal with on-disk or IMAP4 or POP3 mailboxes, thanks both to modules as a concept and to convenient library modules to do the hard work; and updating in the several different work and home environments where I use it no longer requires recompiling (and the source code need no longer worry about the quirks of different compilers and libraries); I just copy the single executable source-code file to the different places it needs to run. For me, Python fits into the space between shell scripts and awk on one hand, and C on the other, overlapping some of the space of each. But personal taste is relevant too. I didn't know whether I'd like Python until I'd tried it for a few real programs (and even then it took a couple of years before I felt like I'd really figured out out to use it). Just as I recall, about 45 years ago, moving from TECO (in which I had been quite expert) to ed and later the U of T qed and quickly feeling that ed was better in nearly every way; a year or so later, trying vi for a week and giving up in disgust because it just didn't fit my idea of how screen editors should work; falling in love with jim and later sam (though not exclusively, I still use ed/qed daily) because they got the screen part just right even if their command languages weren't quite such a good match for me. And I have never cottoned on to Perl for, I suspect, the same reason I'd be really unhappy to go back to TECO. Tastes evolve. I bet there's a lot of stuff I did in the 1980s that I'd do differently could I have another go at it. The important thing is to try new stuff. I haven't tried Go or Rust yet, and I should. If you haven't given Python or Perl a good look, you should. Sometimes new tools are useless or cumbersome, sometimes they are no better than what you've got now, but sometimes they make things easier. You won't know until you try. Here endeth today's sermon from the messy office, which I ought to be cleaning up, but preaching is more fun. Norman Wilson Toronto ON From athornton at gmail.com Mon Aug 7 14:56:09 2023 From: athornton at gmail.com (Adam Thornton) Date: Sun, 6 Aug 2023 21:56:09 -0700 Subject: [TUHS] Early Unix and Keyboard Skills In-Reply-To: <829ea2b4-16b5-4e7c-b9b2-f75ea9c67602@gmail.com> References: <709cc67b2a5670f2038914beafd605c4@yaccman.com> <20230806004343.GH19141@mcvoy.com> <87il9s442v.fsf@vuxu.org> <829ea2b4-16b5-4e7c-b9b2-f75ea9c67602@gmail.com> Message-ID: Webb Miller's book is also available through Inter-Library Loan, which is how I got my hands on it and made my own copy through the decidedly low-tech solution of "abusing the office copier when everyone else had gone home." On Sun, Aug 6, 2023 at 11:20 AM Jon Forrest wrote: > > > On 8/6/2023 9:31 AM, Clem Cole wrote: > > > And vi seemed to be a pretty popular as a starting point[I always > > suspect Webb Miller's book had something to do with that since 's' > > was so small and using it to add missing vi features was not > > terrible]. > > Every time this book is mentioned on TUHS I announce that I have > a copy of it for sale. Contact me off-list if you're interested. > > Jon > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjenkin at canb.auug.org.au Mon Aug 7 15:30:17 2023 From: sjenkin at canb.auug.org.au (steve jenkin) Date: Mon, 7 Aug 2023 15:30:17 +1000 Subject: [TUHS] Help with a Unix-ish project? Message-ID: <944EF3AD-8BB2-4B89-84A8-B759AB1C2790@canb.auug.org.au> six years later… A note for the list: Warren (in. IMHO, a stroke of genius) changed the Repo from xv6-minix to xv6-freebsd. -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin From egbegb2 at gmail.com Mon Aug 7 16:48:01 2023 From: egbegb2 at gmail.com (Ed Bradford) Date: Mon, 7 Aug 2023 01:48:01 -0500 Subject: [TUHS] python In-Reply-To: <523A100F35BC4139947795C31B70303E.for-standards-violators@oclsc.org> References: <523A100F35BC4139947795C31B70303E.for-standards-violators@oclsc.org> Message-ID: Very nice serman, Norman. I moved from (cb unix) BTL C (1976) to C++ to Java to PHP and JavaScript to Python. I never went for the object oriented view but loved C++'s strict type checking. I got very frustrated with the active support for Python2 and Python3 versions and vacationed for several years. Then Python went out of the Python 2 support business and I started using Python again. Over the span of all those languages Python 3 has supported almost anything I could think of with free downloadable modules. That has happened nowhere I have ever seen. I also struggled with writing and supporting print functions where the variables were in one place and the formats for them were in another place. Python3's f-strings reduced my strings substantially. Now the format and variable can be defined in one place and used in lots of places. That is a huge help to me for documentation and support. That's my two cents. Thanks for your thoughts Ed Bradford Pflugerville, TX egbegb2 at gmail.com PS: Has anyone else but me on this list tried chatGPT generated python programs? We should move such a conversation elsewhere, but I simply don't know where. Email me if you want to start a discussion on this topic in a more appropriate place. On Sun, Aug 6, 2023 at 2:46 PM Norman Wilson wrote: > At the risk of releasing more heat than light (so if you feel > compelled to flame by this message, please reply just to me > or to COFF, not to TUHS): > > The fussing here over Python reminds me very much of Unix in > the 1980s. Specifically wars over editors, and over BSD vs > System V vs Research systems, and over classic vs ISO C, and > over embracing vendor-specific features (CSRG and USG counting > as vendors as well as Digital, SGI, Sun, et al) vs sticking > to the common core. And more generally whether any of the > fussing is worth it, and whether adding stuff to Unix is > progress or just pointless complication. > > Speaking as an old fart who no longer gets excited about this > stuff except where it directly intersects something I want to > do, I have concluded that nobody is entirely right and nobody > is entirely wrong. Fancy new features that are there just to > be fancy are usually a bad idea, especially when they just copy > something from one system to a completely different one, but > sometimes they actually add something. Sometimes something > brand new is a useful addition, especially when its supplier > takes the time and thought to fit cleanly into the existing > ecosystem, but sometimes it turns out to be a dead end. > > Personal taste counts, but never as much as those of us > brandishing it like to think. > > To take Python as an example: I started using it about fifteen > years ago, mostly out of curiousity. It grew on me, and these > days I use it a lot. It's the nearest thing to an object- > oriented language that I have ever found to be usable (but I > never used the original Smalltalk and suspect I'd have liked > that too). It's not what I'd use to write an OS, nor to do > any sort of performance-limited program, but computers and > storage are so fast these days that that rarely matters to me. > > Using white space to denote blocks took a little getting used > to, but only a little; no more than getting used to typing > if ...: instead of if (...). The lack of a C-style for loop > occasionally bothers me, but iterating over lists and sets > handles most of the cases that matter, and is far less cumbersome. > It's a higher-level language than C, which means it gets in the > way of some things but makes a lot of other things easier. It > turns out the latter is more significant than the former for > the things I do with it. > > The claim that Python doesn't have printf (at least since ca. 2.5, > when I started using it) is just wrong: > print 'pick %d pecks of %s' % (n, fruit) > is just a different spelling of > printf("pick %d pecks of %s\n", n, fruit) > except that sprintf is no longer a special case (and snprintf > becomes completely needless). I like the modern > print(f'pick {n} pecks of {fruit}') > even better; f strings are what pushed me from Python 2 to > Python 3. > > I really like the way modules work in Python, except the dumbass > ways you're expected to distribute a program that is broken into > modules of its own. As a low-level hacker I came up with my own > way to do that (assembling them all into a single Python source > file in which each module is placed as a string, evaled and > inserted into the module table, and then the starting point > called at the end; all using documented, stable interfaces, > though they changed from 2 to 3; program actually written as > a collection of individual source files, with a tool of my > own--written in Python, of course--to create the single file > which I can then install where I need it). > > I have for some years had my own hand-crafted idiosyncratic > program for reading mail. (As someone I know once said, > everybody writes a mailer; it's simple and easy and makes > them feel important. But in this case I was doing it just > for myself and for the fun of it.) The first edition was > written 20 years ago in C. I rewrote it about a decade ago > in Python. It works fine; can now easily deal with on-disk > or IMAP4 or POP3 mailboxes, thanks both to modules as a > concept and to convenient library modules to do the hard work; > and updating in the several different work and home environments > where I use it no longer requires recompiling (and the source > code need no longer worry about the quirks of different > compilers and libraries); I just copy the single executable > source-code file to the different places it needs to run. > > For me, Python fits into the space between shell scripts and > awk on one hand, and C on the other, overlapping some of the > space of each. > > But personal taste is relevant too. I didn't know whether I'd > like Python until I'd tried it for a few real programs (and > even then it took a couple of years before I felt like I'd > really figured out out to use it). Just as I recall, about > 45 years ago, moving from TECO (in which I had been quite > expert) to ed and later the U of T qed and quickly feeling > that ed was better in nearly every way; a year or so later, > trying vi for a week and giving up in disgust because it just > didn't fit my idea of how screen editors should work; falling > in love with jim and later sam (though not exclusively, I still > use ed/qed daily) because they got the screen part just right > even if their command languages weren't quite such a good match > for me. > > And I have never cottoned on to Perl for, I suspect, the same > reason I'd be really unhappy to go back to TECO. Tastes > evolve. I bet there's a lot of stuff I did in the 1980s that > I'd do differently could I have another go at it. > > The important thing is to try new stuff. I haven't tried Go > or Rust yet, and I should. If you haven't given Python or > Perl a good look, you should. Sometimes new tools are > useless or cumbersome, sometimes they are no better than > what you've got now, but sometimes they make things easier. > You won't know until you try. > > Here endeth today's sermon from the messy office, which I ought > to be cleaning up, but preaching is more fun. > > Norman Wilson > Toronto ON > -- Advice is judged by results, not by intentions. Cicero -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Mon Aug 7 23:26:33 2023 From: crossd at gmail.com (Dan Cross) Date: Mon, 7 Aug 2023 09:26:33 -0400 Subject: [TUHS] Help with a Unix-ish project? In-Reply-To: <944EF3AD-8BB2-4B89-84A8-B759AB1C2790@canb.auug.org.au> References: <944EF3AD-8BB2-4B89-84A8-B759AB1C2790@canb.auug.org.au> Message-ID: On Mon, Aug 7, 2023 at 1:30 AM steve jenkin wrote: > six years later… > > A note for the list: > > Warren (in. IMHO, a stroke of genius) changed the Repo from xv6-minix to xv6-freebsd. > > Cool. xv6 came up again last week with a Hacker News posted, followed by an article in the Register, about another xv6 clone written in Rust: octox (https://www.theregister.com/2023/07/28/octox_v6_unix_in_rust/). Octox bills itself as being written entirely in Rust, including the userspace utilities. In the Register article, author Liam Proven (who I believe is on this list, Cc'ed here) mentioned my own rxv64, but seems to have missed part of the point when talking about language statistics (rxv64 left much of the userspace code written in C, except for the parts of the C library I wrote, which are Rust...I do provide header files, though). The point, of course, is that the implementation language used by the kernel need not be the same as that used by userspace code; the interface is instead through a contract with the kernel. What better way to demonstrate this than write some of the userspace code in a language that isn't Rust? In this case, the utilities were already more or less written in C. Bakul pointed this out on the Hacker News story about octox, but it didn't make it to the Register article and of course was largely missed by the crowd on the Orange Site. Octox looks like it would be pretty hard to use from a language other than Rust, honestly; at least, one would likely have to provide a wrapper library in another language (it appears that all of the names in the octox userspace library are mangled). And of course, octox is not 100% Rust, as the Register article claimed; it has some assembly language bits, but those are hidden inside of Rust source files (e.g., https://github.com/o8vm/octox/blob/main/src/kernel/swtch.rs), and it generates system call stubs at build time that expand to inline `ecall` instructions (octox target RISC-V, whereas rxv64 targets x86_64). I've avoided commenting publicly on the octox code, but I will say that it has a much better README file than rxv64! - Dan C. From rminnich at gmail.com Wed Aug 9 05:25:02 2023 From: rminnich at gmail.com (ron minnich) Date: Tue, 8 Aug 2023 12:25:02 -0700 Subject: [TUHS] v8 /etc/motd Message-ID: Sorry if this has been asked before, but: "Welcome to Eighth Edition Unix. You may be sure that it is suitably protected by ironclad licences, contractual agreements, living wills, and trade secret laws of every sort. A trolley car is certain to grow in your stomach if you violate the conditions under which you got this tape. Consult your lawyer in case of any doubt. If doubt persists, consult our lawyers. Please commit this message to memory. If this is a hardcopy terminal, tear off the paper and affix it to your machine. Otherwise take a photo of your screen. Then delete /etc/motd. Thank you for choosing Eighth Edition Unix. Have a nice day." was this one person or a group effort. It's wonderful. From ron at ronnatalie.com Wed Aug 9 05:44:15 2023 From: ron at ronnatalie.com (Ron Natalie) Date: Tue, 08 Aug 2023 19:44:15 +0000 Subject: [TUHS] v8 /etc/motd In-Reply-To: References: Message-ID: My favorite MOTD is: You might have mail. I told one of my student operators that if he put that in there before the morning was out, someone would be in my office to tell me they got the message but they didn’t have any mail. I wasn’t expecting it to be one of my senior programmers. Well, it only said you MIGHT have mail. Somewhere there was a post circulating around with humorous MOTDs. That was on it, I believe. From rminnich at gmail.com Wed Aug 9 06:00:00 2023 From: rminnich at gmail.com (ron minnich) Date: Tue, 8 Aug 2023 13:00:00 -0700 Subject: [TUHS] v8 /etc/motd In-Reply-To: References: Message-ID: "you might have mail" -- nice. Kind of like the Plan 9 "Press almost any key to reboot..." This was from the late Jim McKie, who realized that the PC keyboard had a few keys that would not count as a keypress. jmk once claimed to me, with a smile on his face, that Ken said the message was pedantic :-) On Tue, Aug 8, 2023 at 12:44 PM Ron Natalie wrote: > > My favorite MOTD is: > > You might have mail. > > I told one of my student operators that if he put that in there before > the morning was out, someone would be in my office to tell me they got > the message but they didn’t have any mail. > I wasn’t expecting it to be one of my senior programmers. Well, it > only said you MIGHT have mail. > > Somewhere there was a post circulating around with humorous MOTDs. > That was on it, I believe. > From sauer at technologists.com Wed Aug 9 06:25:15 2023 From: sauer at technologists.com (Charles H Sauer (he/him)) Date: Tue, 8 Aug 2023 15:25:15 -0500 Subject: [TUHS] March 17, 1988 Bill Joy @ IBM Yorktown VHS discovered thanks to 512 byte C compiler In-Reply-To: <5341c7be-23a1-9259-59ac-9d34d7f30aa5@technologists.com> References: <5341c7be-23a1-9259-59ac-9d34d7f30aa5@technologists.com> Message-ID: <8e570098-3571-c857-af02-d7f67aeaa42d@technologists.com> At 1:46:50, Bill says "AIX is a good thing" https://www.youtube.com/watch?v=EmC5yoE_7PY backstory on how https://xorvoid.com/sectorc.html led to this rediscovery at https://notes.technologists.com/notes/2023/08/07/koko-keeping-warm/ Charlie -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/LinkedIn/Twitter: CharlesHSauer From norman at oclsc.org Thu Aug 10 00:27:02 2023 From: norman at oclsc.org (Norman Wilson) Date: Wed, 09 Aug 2023 10:27:02 -0400 Subject: [TUHS] v8 /etc/motd In-Reply-To: References: Message-ID: <940A46E5CF5870F77451F485D89E3698.for-standards-violators@oclsc.org> On August 8, 2023 3:25:02 p.m. EDT, ron minnich wrote: >was this one person or a group effort. It's wonderful. Sorry, if we told you we'd have to sue you. Norman Wilson, IANAL Toronto ON From kennethgoodwin56 at gmail.com Thu Aug 10 08:43:31 2023 From: kennethgoodwin56 at gmail.com (Kenneth Goodwin) Date: Wed, 9 Aug 2023 18:43:31 -0400 Subject: [TUHS] v8 /etc/motd In-Reply-To: References: Message-ID: But Sir I can't find the ALMOST ANY Key on my keyboard. Please help me locate it 🙏 On Tue, Aug 8, 2023, 4:00 PM ron minnich wrote: > "you might have mail" -- nice. > > Kind of like the Plan 9 > "Press almost any key to reboot..." > > This was from the late Jim McKie, who realized that the PC keyboard > had a few keys that would not count as a keypress. > > jmk once claimed to me, with a smile on his face, that Ken said the > message was pedantic :-) > > On Tue, Aug 8, 2023 at 12:44 PM Ron Natalie wrote: > > > > My favorite MOTD is: > > > > You might have mail. > > > > I told one of my student operators that if he put that in there before > > the morning was out, someone would be in my office to tell me they got > > the message but they didn’t have any mail. > > I wasn’t expecting it to be one of my senior programmers. Well, it > > only said you MIGHT have mail. > > > > Somewhere there was a post circulating around with humorous MOTDs. > > That was on it, I believe. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Thu Aug 10 11:03:07 2023 From: bakul at iitbombay.org (Bakul Shah) Date: Wed, 9 Aug 2023 18:03:07 -0700 Subject: [TUHS] v8 /etc/motd In-Reply-To: References: Message-ID: <2E594D34-84FB-49CB-8653-97460459F1F4@iitbombay.org> On Aug 8, 2023, at 12:25 PM, ron minnich wrote: > > Sorry if this has been asked before, but: > "Welcome to Eighth Edition Unix. You may be sure that it > is suitably protected by ironclad licences, contractual agreements, > living wills, and trade secret laws of every sort. A trolley car is > certain to grow in your stomach if you violate the conditions > under which you got this tape. Consult your lawyer in case of any doubt. > If doubt persists, consult our lawyers. > > Please commit this message to memory. If this is a hardcopy terminal, > tear off the paper and affix it to your machine. Otherwise > take a photo of your screen. Then delete /etc/motd. > > Thank you for choosing Eighth Edition Unix. Have a nice day." > > was this one person or a group effort. It's wonderful. May you can use an online plagiarism checker to find out! From lm at mcvoy.com Thu Aug 10 11:09:40 2023 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 9 Aug 2023 18:09:40 -0700 (PDT) Subject: [TUHS] when did v8 or later get networking? Message-ID: <20230810010940.9B3C635E102@mcvoy.com> TCP/IP, not datakit. From tuhs at tuhs.org Thu Aug 10 12:38:39 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 10 Aug 2023 02:38:39 +0000 Subject: [TUHS] when did v8 or later get networking? In-Reply-To: <20230810010940.9B3C635E102@mcvoy.com> References: <20230810010940.9B3C635E102@mcvoy.com> Message-ID: > TCP/IP, not datakit. The V8 manual contains internet(3), tcp(3), and udp(3). In the copy I have these are dated 8/7/85. Down in the kernel in /usr/sys/inet the earliest files appear to be dated 3/22/85. I'm going to do a comparison with the 4.1cBSD TCP/IP stuff because a casual glance reveals some overlap. - Matt G. From imp at bsdimp.com Thu Aug 10 12:45:54 2023 From: imp at bsdimp.com (Warner Losh) Date: Wed, 9 Aug 2023 20:45:54 -0600 Subject: [TUHS] when did v8 or later get networking? In-Reply-To: References: <20230810010940.9B3C635E102@mcvoy.com> Message-ID: On Wed, Aug 9, 2023, 8:38 PM segaloco via TUHS wrote: > > TCP/IP, not datakit. > > The V8 manual contains internet(3), tcp(3), and udp(3). In the copy I > have these are dated 8/7/85. Down in the kernel in /usr/sys/inet the > earliest files appear to be dated 3/22/85. I'm going to do a comparison > with the 4.1cBSD TCP/IP stuff because a casual glance reveals some overlap. > Yea, I thought it was 4.1bsd + later tcp code but with a STREAMS instead of Socket interface... Warner - Matt G. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Thu Aug 10 13:17:25 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 10 Aug 2023 03:17:25 +0000 Subject: [TUHS] when did v8 or later get networking? In-Reply-To: References: <20230810010940.9B3C635E102@mcvoy.com> Message-ID: > > > TCP/IP, not datakit. > > > > The V8 manual contains internet(3), tcp(3), and udp(3). In the copy I have these are dated 8/7/85. Down in the kernel in /usr/sys/inet the earliest files appear to be dated 3/22/85. I'm going to do a comparison with the 4.1cBSD TCP/IP stuff because a casual glance reveals some overlap. > > - Matt G. > > > Yea, I thought it was 4.1bsd + later tcp code but with a STREAMS instead of Socket interface... > > Warner This comment at the top of /usr/sys/netinet/socket.c is illuminating: > /* > * socket emulation routines > * pretty much 4.2 sys/uipc_socket2.c > */ All of the files that have timestamps at the top list 83/07/29, except ip_input.c which has 83/08/16 instead. The V8 version has _device (device driver) and _ld (line discipline) components that the 4.1cBSD code does not have. Many other files have analogs between the two. The byte ordering subroutines have been copied into a file, goo.s, from their home in 4.1cBSD in the C library (/usr/src/lib/libc/net/misc). When this work originated someone else would need to answer, but looks like it was as Warner described, modified 4.xBSD TCP/IP. - Matt G. From robpike at gmail.com Thu Aug 10 13:18:36 2023 From: robpike at gmail.com (Rob Pike) Date: Thu, 10 Aug 2023 13:18:36 +1000 Subject: [TUHS] when did v8 or later get networking? In-Reply-To: References: <20230810010940.9B3C635E102@mcvoy.com> Message-ID: STREAMS was the Unix support group's shouty adaptation. The V8 one that dmr put together was the gentler dulcet-toned Streams. Seriously, no one could figure out why they wanted to yell. -rob On Thu, Aug 10, 2023 at 12:46 PM Warner Losh wrote: > > > On Wed, Aug 9, 2023, 8:38 PM segaloco via TUHS wrote: > >> > TCP/IP, not datakit. >> >> The V8 manual contains internet(3), tcp(3), and udp(3). In the copy I >> have these are dated 8/7/85. Down in the kernel in /usr/sys/inet the >> earliest files appear to be dated 3/22/85. I'm going to do a comparison >> with the 4.1cBSD TCP/IP stuff because a casual glance reveals some overlap. >> > > Yea, I thought it was 4.1bsd + later tcp code but with a STREAMS instead > of Socket interface... > > Warner > > - Matt G. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Thu Aug 10 15:44:47 2023 From: cowan at ccil.org (John Cowan) Date: Thu, 10 Aug 2023 01:44:47 -0400 Subject: [TUHS] when did v8 or later get networking? In-Reply-To: References: <20230810010940.9B3C635E102@mcvoy.com> Message-ID: On Wed, Aug 9, 2023 at 11:18 PM Rob Pike wrote: > STREAMS was the Unix support group's shouty adaptation. The V8 one that > dmr put together was the gentler dulcet-toned Streams. > > Seriously, no one could figure out why they wanted to yell. > I always supposed it was a trademark (like UNIX), or at least was intended to be one. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at quintile.net Thu Aug 10 18:16:34 2023 From: steve at quintile.net (Steve Simon) Date: Thu, 10 Aug 2023 10:16:34 +0200 Subject: [TUHS] v8 /etc/motd Message-ID: probably local, but i do remember: “Error 17. press control + backslash + underscore + exclamation mark to continue; or any other key to reboot.” From douglas.mcilroy at dartmouth.edu Thu Aug 10 22:41:58 2023 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Thu, 10 Aug 2023 08:41:58 -0400 Subject: [TUHS] when did v8 or later get networking? In-Reply-To: <20230810010940.9B3C635E102@mcvoy.com> References: <20230810010940.9B3C635E102@mcvoy.com> Message-ID: My preface to the manual: says v8 " incorporates facilities from the Seventh Edition, System V, andBerkeley BSD 4.1. The distinctive theme ...is distributed computing"It goes on to cite streams, Datakit, RFS, and Blit. The internet lurks in the citation of BSD 4.1. The preface goes on to suggest how the new facilities affected life in the lab: "These facilities have spurred a host of programs for remote information services, interactive graphics, debugging, and simple fun". On rereading this, I am struck by how blinkered I was not to overtly mention either the internet, which brought us out of the clumsy era of uucp and CSNET, or upas, which seamlessly integrated remote and local mail (and would eventually save us from the Morris worm). I recall expressions of surprise (dismay?) at the size of the BSD internet code, but without it we'd have lost our place in the Unix community. Even greater concern about the complexity of sendmail led Presotto to develop the simpler upas. Doug On Wed, Aug 9, 2023 at 9:09 PM Larry McVoy wrote: > > > TCP/IP, not datakit. From jsg at jsg.id.au Fri Aug 11 00:00:44 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Fri, 11 Aug 2023 00:00:44 +1000 Subject: [TUHS] when did v8 or later get networking? In-Reply-To: <20230810010940.9B3C635E102@mcvoy.com> References: <20230810010940.9B3C635E102@mcvoy.com> Message-ID: On Wed, Aug 09, 2023 at 06:09:40PM -0700, Larry McVoy wrote: > > TCP/IP, not datakit. > "The closest we got to using 4.n BSD was when Robert Morris, now at MIT, imported the 4.1c TCP/IP stack into 7/8th edition (I believe in 84) nominally as my summer student." Dave Presotto on 9fans, 2001-10-01 https://marc.info/?l=9fans&m=111558818409805&w=2 "the 8th edition system including Streams was already pretty much in place by the time that Robert Morris adapted the then-current BSD TCP/IP stack to streams. At that time, we were using either serial communication over various modems, and more notably Datakit. Looking back at this, one of the satisfying things is that the communication structure built then was adaptable so smoothly to TCP/IP when the protocol's importance became undeniable." Dennis Ritchie on 9fans, 2001-10-02 https://marc.info/?l=9fans&m=111558818709848&w=2 From pnr at planet.nl Fri Aug 11 19:05:21 2023 From: pnr at planet.nl (Paul Ruizendaal) Date: Fri, 11 Aug 2023 11:05:21 +0200 Subject: [TUHS] when did v8 or later get networking? Message-ID: <6EA66356-0C94-4802-81B6-1CF891EF6EC2@planet.nl> > Date: Thu, 10 Aug 2023 03:17:25 +0000 > From: segaloco > >>>> TCP/IP, not datakit > > > All of the files that have timestamps at the top list 83/07/29, except ip_input.c which has 83/08/16 instead. The V8 version has _device (device driver) and _ld (line discipline) components that the 4.1cBSD code does not have. Many other files have analogs between the two. The byte ordering subroutines have been copied into a file, goo.s, from their home in 4.1cBSD in the C library (/usr/src/lib/libc/net/misc). When this work originated someone else would need to answer, [...] As far as I can tell the history of this code line goes back to 1977, when Jack Haverty at BBN wrote a TCP/IP library (porting earlier work written in PDP-11 assembler) for a slightly modified 6th Edition Unix. Fighting with 64KB core limits, throughput was horrific and he concluded that a bigger PDP-11 was needed. Mike Wingfield then did a re-implementation in C for a PDP-11/70. This worked in early 1979 and is arguably the first Unix TCP/IP stack that can still interoperate with current IPv4. However, it was still mostly a proof of concept user mode design (it was funded as a test vehicle for the later abandoned Autodin-II fork of TCP). BBN then got a contract to write a kernel mode TCP/IP stack for 4BSD (“VAX TCP” in the old BBN doc’s). This work was performed by Rob Gurwitz under supervision of Jack Haverty. This stack - although all new code - still showed its heritage: it was designed as a loosely bound kernel process providing the NCP-Unix API. Some sources seem to imply that it was developed first as a user mode process and once working in that context changed into a kernel process / thread. Beta releases were available in 1981. It worked (and interoperates with modern IPv4), but in my experiments a few years back it turned out that it is difficult to get the scheduling for this kernel process right at higher system loads. Bill Joy of CSRG concluded that the BBN stack did not perform according to his expectations. Note that CSRG was focused on usage over (thick) ethernet links, and BBN was focused on usage over Arpanet and other wide-area networks (with much lower bandwidth, and higher latency and error rates). He then in 1982 rewrote the stack to match the CSRG environment, changing the design to use software interrupts instead of a kernel thread and optimising the code (e.g. checksumming and fast code paths). It was a matter of debate how new the code was, with the extremes being that it was written from scratch using the spec versus it being mostly copied. Looking at it with a nearly 50 year distance, it seems in between: small bits of surviving SCCS suggest CSRG starting with parts of BBN code followed by rapid, massive modification; the end result is quite different but retained the ‘mbuf’ core data structure and a BBN bug (off-by-one for OOB TCP segments). The shift from the NCP-Unix API to sockets is separate from this and was planned. CSRG had the contract to develop a new API for facilitating distributed systems with Unix and this gelled into the sockets interface. The first prototypes for this were done in 1981. Nearly all of the above source is available in the TUHS online Unix Tree (Wingfield, VAX-TCP and two early versions from CSRG - one in 2.9BSD and one in 4.1cBSD). From pnr at planet.nl Fri Aug 11 19:50:59 2023 From: pnr at planet.nl (Paul Ruizendaal) Date: Fri, 11 Aug 2023 11:50:59 +0200 Subject: [TUHS] V8 Streams // was Re: when did v8 or later get networking? Message-ID: <15FABD59-619B-4BDA-9311-890059444178@planet.nl> > Warner Losh imp at bsdimp.com > Thu Aug 10 12:45:54 AEST 2023 > wrote: > > Yea, I thought it was 4.1bsd + later tcp code but with a STREAMS instead of > Socket interface... Please see this old TUHS post for some more background in DMR’s own words: https://www.tuhs.org/pipermail/tuhs/2019-August/018325.html On the topic of DMR Streams, I’m increasingly intrigued by its design: recently I’ve been deep diving into classic USB to better understand this class of devices and how to drive them (https://gitlab.com/pnru/usb_host). It would seem to me that Streams would have been a neat way to organise the USB driver stack in a v8 context. Note that an USB analog did exist in 1982: https://en.wikipedia.org/wiki/Hex-Bus Sometimes I wonder what combining v8 streams with v8 virtual directories (i.e. like Killian’s /proc) could have looked like. Having the streams network stack (or usb stack) exposed as virtual directories would have been quite powerful. From imp at bsdimp.com Sat Aug 12 15:08:00 2023 From: imp at bsdimp.com (Warner Losh) Date: Fri, 11 Aug 2023 23:08:00 -0600 Subject: [TUHS] when did v8 or later get networking? In-Reply-To: <6EA66356-0C94-4802-81B6-1CF891EF6EC2@planet.nl> References: <6EA66356-0C94-4802-81B6-1CF891EF6EC2@planet.nl> Message-ID: On Fri, Aug 11, 2023 at 3:05 AM Paul Ruizendaal wrote: > Bill Joy of CSRG concluded that the BBN stack did not perform according to > his expectations. Note that CSRG was focused on usage over (thick) ethernet > links, and BBN was focused on usage over Arpanet and other wide-area > networks (with much lower bandwidth, and higher latency and error rates). > He then in 1982 rewrote the stack to match the CSRG environment, changing > the design to use software interrupts instead of a kernel thread and > optimising the code (e.g. checksumming and fast code paths). It was a > matter of debate how new the code was, with the extremes being that it was > written from scratch using the spec versus it being mostly copied. Looking > at it with a nearly 50 year distance, it seems in between: small bits of > surviving SCCS suggest CSRG starting with parts of BBN code followed by > rapid, massive modification; the end result is quite different but retained > the ‘mbuf’ core data structure and a BBN bug (off-by-one for OOB TCP > segments). > When Kirk McKusick tells the story, UCB got a beta release (or early access) of the BBN stack. UCB was supposed to add the socket interface to whatever was there. But Bill Joy found it performed terribly (multiple seconds to connect sometimes, single digit kB over 10Mb media, etc). He optimized it to make it perform well. This was a combination of rewriting chunks and tweaking other chunks, which matches your analysis of SCCS. When BBN came back with their new, release ready stack Bill supposedly said something like 'no thanks, we already got one that works way better.' This is why much of the structure of the original BBN stack survived the rewrite: if there wasn't a big issue with them, the design and mechanisms wound up being conserved by this effort. It was too much work to move from mbuf to something else, and too little gain. I tried to find a good link, but they are in his BSD history retrospective talks to differing degrees. Sorry I don't have an exact reference. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggm at algebras.org Sat Aug 12 15:41:28 2023 From: ggm at algebras.org (George Michaelson) Date: Sat, 12 Aug 2023 15:41:28 +1000 Subject: [TUHS] when did v8 or later get networking? In-Reply-To: References: <6EA66356-0C94-4802-81B6-1CF891EF6EC2@planet.nl> Message-ID: Someone who worked at BBN told me they had no overhang budget for improvements, they wrote code to fixed price contracts with DARPA and 'maybe we could do that better' was impossible without a second grant. The butterfly we had at UCL had issues. No support worth writing home for. Pre BGP routing was a bit of a disaster. Fixed size prefix tables and LRU ejection. You could time out a telnet to the USA before the login: prompt assuming you even had a route. "Diamond" their SGML multimedia mailer was great, but a one-shot. Smart people. Very focused on the bottom line. (Apologies if this offends anyone ex BBN it's recollection of coffee room gossip from 1985) G On Sat, 12 Aug 2023, 3:08 pm Warner Losh, wrote: > > > On Fri, Aug 11, 2023 at 3:05 AM Paul Ruizendaal wrote: > >> Bill Joy of CSRG concluded that the BBN stack did not perform according >> to his expectations. Note that CSRG was focused on usage over (thick) >> ethernet links, and BBN was focused on usage over Arpanet and other >> wide-area networks (with much lower bandwidth, and higher latency and error >> rates). He then in 1982 rewrote the stack to match the CSRG environment, >> changing the design to use software interrupts instead of a kernel thread >> and optimising the code (e.g. checksumming and fast code paths). It was a >> matter of debate how new the code was, with the extremes being that it was >> written from scratch using the spec versus it being mostly copied. Looking >> at it with a nearly 50 year distance, it seems in between: small bits of >> surviving SCCS suggest CSRG starting with parts of BBN code followed by >> rapid, massive modification; the end result is quite different but retained >> the ‘mbuf’ core data structure and a BBN bug (off-by-one for OOB TCP >> segments). >> > > When Kirk McKusick tells the story, UCB got a beta release (or early > access) of the BBN stack. UCB was supposed to add the socket interface to > whatever was there. But Bill Joy found it performed terribly (multiple > seconds to connect sometimes, single digit kB over 10Mb media, etc). He > optimized it to make it perform well. This was a combination of rewriting > chunks and tweaking other chunks, which matches your analysis of SCCS. When > BBN came back with their new, release ready stack Bill supposedly said > something like 'no thanks, we already got one that works way better.' This > is why much of the structure of the original BBN stack survived the > rewrite: if there wasn't a big issue with them, the design and mechanisms > wound up being conserved by this effort. It was too much work to move from > mbuf to something else, and too little gain. > > I tried to find a good link, but they are in his BSD history retrospective > talks to differing degrees. Sorry I don't have an exact reference. > > Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Sat Aug 12 19:06:25 2023 From: pnr at planet.nl (Paul Ruizendaal) Date: Sat, 12 Aug 2023 11:06:25 +0200 Subject: [TUHS] when did v8 or later get networking? In-Reply-To: References: <6EA66356-0C94-4802-81B6-1CF891EF6EC2@planet.nl> Message-ID: > On 12 Aug 2023, at 07:08, Warner Losh wrote: > > On Fri, Aug 11, 2023 at 3:05 AM Paul Ruizendaal wrote: > Bill Joy of CSRG concluded that the BBN stack did not perform according to his expectations. Note that CSRG was focused on usage over (thick) ethernet links, and BBN was focused on usage over Arpanet and other wide-area networks (with much lower bandwidth, and higher latency and error rates). He then in 1982 rewrote the stack to match the CSRG environment, changing the design to use software interrupts instead of a kernel thread and optimising the code (e.g. checksumming and fast code paths). It was a matter of debate how new the code was, with the extremes being that it was written from scratch using the spec versus it being mostly copied. Looking at it with a nearly 50 year distance, it seems in between: small bits of surviving SCCS suggest CSRG starting with parts of BBN code followed by rapid, massive modification; the end result is quite different but retained the ‘mbuf’ core data structure and a BBN bug (off-by-one for OOB TCP segments). > > When Kirk McKusick tells the story, UCB got a beta release (or early access) of the BBN stack. UCB was supposed to add the socket interface to whatever was there. But Bill Joy found it performed terribly (multiple seconds to connect sometimes, single digit kB over 10Mb media, etc). He optimized it to make it perform well. This was a combination of rewriting chunks and tweaking other chunks, which matches your analysis of SCCS. When BBN came back with their new, release ready stack Bill supposedly said something like 'no thanks, we already got one that works way better.' This is why much of the structure of the original BBN stack survived the rewrite: if there wasn't a big issue with them, the design and mechanisms wound up being conserved by this effort. It was too much work to move from mbuf to something else, and too little gain. > > I tried to find a good link, but they are in his BSD history retrospective talks to differing degrees. Sorry I don't have an exact reference. > > Warner === > UCB got a beta release (or early access) of the BBN stack. This is certainly true. There are four surviving BBN tapes in the CSRG archive, from memory the first was from August 1981 and the last from early 1982. Again from memory, the oldest SCCS entries for the rewrite are from Oct ’81. All of this is on Kirk’s DVD. Indeed the first tape is early code, written to just interface with Arpanet IMP’s. Things like routing are rudimentary or hard-coded, etc. This is all filled out by the time of the last tape, which also includes a token ring driver (written by Noel Chiappa, if I remember well). There are two editions of Mike Muuss’ TCP-DIGEST mailing list with posts on performance from Joy and Gurwitz respectively (both from late 1981): https://groups.google.com/g/fa.tcp-ip/c/WNE_j4mAbAE/m/3nCB79uvNcUJ https://groups.google.com/g/fa.tcp-ip/c/zfYZh-kRlMg/m/pl-5oLQtYxIJ Jonathan Gray sent me a good link of one of Kirk’s talks that addresses this bit of history: https://youtu.be/DEEr6dT-4uQ?t=706 === Maybe Kirk was using some hyperbole in that talk. As far as I can tell the main issues were the below: - BBN coded the checksum routine in C and it compiled badly. Even Joy's hand-optimised version still took some 25% of CPU when traffic maxed out. - The time-out constants were 2s and 5s. This makes sense for the Arpanet of the time. For local ethernet this was changed to 0.2s and 0.5s. - The BBN code used at lot of bit fields. This too compiled badly, and was later changed to and/or with #define’d constants - The BBN code took a very layered approach, often abstracting small bits of functionality into a separate routine. Without compiler inlining and a somewhat slow VAX subroutine mechanism this had a cost. Some of these functions where later changed to #define’s instead of functions. - Although Kirk singles out replacing the state machine with a big switch statement in the above talk, I’m not sure this was a major performance boost. It is certainly the most visible/recognisable change in the source though. Somehow, this seems to have become core to the debate at the time (ref. the BBN talk at the Summer '84 Usenix conference). Maybe I underestimate the impact of this aspect. - The TCP management process ran as a kernel thread with normal scheduling. On a loaded machine this meant that it could take seconds for this process to be scheduled again. Changing this to a software interrupt mechanism (somewhat similar to the runrun flag, although Joy appears to have credited VMS for the idea) made things more responsive and avoided context switches. Of all the above, it would seem to me that only the last point was fundamental to the design. The other things appear relatively easy to fix. === Doug McIlroy wrote: "I recall expressions of surprise (dismay?) at the size of the BSD internet code, but without it we'd have lost our place in the Unix community." An interesting question is how much of this size is unavoidable. Just counting file lines (i.e. ‘wc -l’), 4.2BSD has some 2200 lines of TCP code (i.e. just the TCP part), the ‘82 BBN implementation 2400 lines, 8th edition had some 2400 lines, and the first version of Plan9 some 2200 lines. Some parts of TCP could perhaps be simplified (pseudo headers and ‘urgent' segments come to mind), but not much. Maybe this is just the code size that it takes. URP is smaller, but if I remember well it does not handle out-of-order packets or packet duplicates (both of which do not occur in a (virtual) line switched context). On the other hand, these sizes compare with 900 lines for the IL protocol in early Plan9. From pnr at planet.nl Sat Aug 12 20:29:02 2023 From: pnr at planet.nl (Paul Ruizendaal) Date: Sat, 12 Aug 2023 12:29:02 +0200 Subject: [TUHS] when did v8 or later get networking? In-Reply-To: References: <6EA66356-0C94-4802-81B6-1CF891EF6EC2@planet.nl> Message-ID: > URP is smaller, but if I remember well it does not handle out-of-order packets or packet duplicates (both of which do not occur in a (virtual) line switched context). Upon reflection, duplicates of course can occur when an ACK is lost. From tuhs at tuhs.org Sun Aug 13 00:22:38 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sat, 12 Aug 2023 14:22:38 +0000 Subject: [TUHS] Hundreds of HP-UX Manuals (Auction Links) Message-ID: Good morning folks, just sharing some eBay sales I spotted that are just not in the cards for me, both in terms of expense and I just don't have the bandwidth to focus on other UNIX lines right now. That said, someone is selling a very, very large collection of HP-UX documents: https://www.ebay.com/itm/285425883705 https://www.ebay.com/itm/285425882004 As mentioned, quite pricy, and bulky too. However, if anyone knows anyone with a particular eye for HP-UX history, this may interest them. No idea what is and isn't preserved there, non-Bell-and-UCB stuff hasn't been on my radar hardly at all other than acknowledging it exists. Tangential but I do appreciate the consistency in their documentation appearance. I see HP-UX stuff pop up time to time and the cover motif is identical to the documents they published with analytical equipment like gas chromatographs before spinning that unit off into Agilent. - Matt G. From jnc at mercury.lcs.mit.edu Sun Aug 13 01:05:01 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 12 Aug 2023 11:05:01 -0400 (EDT) Subject: [TUHS] when did v8 or later get networking? Message-ID: <20230812150501.6BC2618C0BC@mercury.lcs.mit.edu> > From: Paul Ruizendaal > a token ring driver (written by Noel Chiappa, if I remember well). No (unless they took one I wrote for the V6 machine and adapted it); I never did anything on any Unix after V6 (I think there's nothing of any significant interest in any later Unix). Anyway, writing a driver for that board would be about as much work as writing a driver for an RK11 controller - i.e. a day or so for someone competent. Noel From imp at bsdimp.com Sun Aug 13 01:20:28 2023 From: imp at bsdimp.com (Warner Losh) Date: Sat, 12 Aug 2023 09:20:28 -0600 Subject: [TUHS] when did v8 or later get networking? In-Reply-To: References: <6EA66356-0C94-4802-81B6-1CF891EF6EC2@planet.nl> Message-ID: On Sat, Aug 12, 2023, 4:29 AM Paul Ruizendaal wrote: > > URP is smaller, but if I remember well it does not handle out-of-order > packets or packet duplicates (both of which do not occur in a (virtual) > line switched context). > > Upon reflection, duplicates of course can occur when an ACK is lost. > What's URP? Sounds a little like UDP, is it a typo or something else? Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Sun Aug 13 01:24:36 2023 From: crossd at gmail.com (Dan Cross) Date: Sat, 12 Aug 2023 11:24:36 -0400 Subject: [TUHS] when did v8 or later get networking? In-Reply-To: References: <6EA66356-0C94-4802-81B6-1CF891EF6EC2@planet.nl> Message-ID: On Sat, Aug 12, 2023 at 11:20 AM Warner Losh wrote: > On Sat, Aug 12, 2023, 4:29 AM Paul Ruizendaal wrote: >> > URP is smaller, but if I remember well it does not handle out-of-order packets or packet duplicates (both of which do not occur in a (virtual) line switched context). >> >> Upon reflection, duplicates of course can occur when an ACK is lost. > > What's URP? Sounds a little like UDP, is it a typo or something else? I thought that might be a typo for UDP, but that doesn't have ACKs. From pnr at planet.nl Sun Aug 13 02:12:32 2023 From: pnr at planet.nl (Paul Ruizendaal) Date: Sat, 12 Aug 2023 18:12:32 +0200 Subject: [TUHS] when did v8 or later get networking? In-Reply-To: References: <6EA66356-0C94-4802-81B6-1CF891EF6EC2@planet.nl> Message-ID: <3E932445-F917-4E3E-A13A-A8E5557280F3@planet.nl> Universal Receiver Protocol, the protocol that Sandy Fraser invented for Datakit. The best description of it (imho) is the patent: https://patentimages.storage.googleapis.com/37/a9/70/46f8c44ebd4e3a/US4852127.pdf At first the patent is very focused on hardware implementation, but towards the end it gives the algorithms in pseudo-code. Sandy Fraser wrote a 1993 retrospective paper “Early Experiments with Asynchronous Time Division Networks”. This paper includes a short summary of the origins of the universal receiver protocol, and how it evolved through 3 main steps. Unfortunately behind a paywall. The implementation for 8th edition (some 750 lines) is here: https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys/dev/dkp.c I think early Plan9 had an implementation of URP as well. > On 12 Aug 2023, at 17:24, Dan Cross wrote: > > On Sat, Aug 12, 2023 at 11:20 AM Warner Losh wrote: >> On Sat, Aug 12, 2023, 4:29 AM Paul Ruizendaal wrote: >>>> URP is smaller, but if I remember well it does not handle out-of-order packets or packet duplicates (both of which do not occur in a (virtual) line switched context). >>> >>> Upon reflection, duplicates of course can occur when an ACK is lost. >> >> What's URP? Sounds a little like UDP, is it a typo or something else? > > I thought that might be a typo for UDP, but that doesn't have ACKs. From pnr at planet.nl Sun Aug 13 04:00:21 2023 From: pnr at planet.nl (Paul Ruizendaal) Date: Sat, 12 Aug 2023 20:00:21 +0200 Subject: [TUHS] when did v8 or later get networking? In-Reply-To: <20230812150501.6BC2618C0BC@mercury.lcs.mit.edu> References: <20230812150501.6BC2618C0BC@mercury.lcs.mit.edu> Message-ID: > On Aug 12, 2023, at 5:05 PM, Noel Chiappa wrote: > >> From: Paul Ruizendaal > >> a token ring driver (written by Noel Chiappa, if I remember well). > > No (unless they took one I wrote for the V6 machine and adapted it); I never > did anything on any Unix after V6 (I think there's nothing of any significant > interest in any later Unix). > > Anyway, writing a driver for that board would be about as much work as > writing a driver for an RK11 controller - i.e. a day or so for someone > competent. > > Noel Found it: it is the Proteon driver on BBN tape 2. The file has the following comment at the top: /* * Proteon VII Local Net Interface Driver * (adapted from Noel Chiappa's V6 driver and ACC driver by Rob Gurwitz, BBN) * * NB. Make sure definition of VII_CONF is correct for configuration of ring, * i.e., VII_HEN for use with wire center, VII_STE for use without. */ So yes, they indeed took one you wrote for the V6 machine and adapted it. From beebe at math.utah.edu Tue Aug 22 07:24:18 2023 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Mon, 21 Aug 2023 15:24:18 -0600 Subject: [TUHS] John Warnock [1940--2023] Message-ID: [This posting was sent earlier today to some local lists, but may also be of interest to TUHS members.] The UofUtah lost one its significant alumni, John Warnock, on Saturday. John received Bachelor's and Master's degrees from the Department of Mathematics, and his doctoral degree from the Department of Electrical Engineering. After jobs at Evans & Sutherland in Salt Lake City, and Xerox PARC labs in Palo Alto, CA, he later went on to co-found Adobe Systems with Chuck Geschke (1939--2021), and the PostScript, PDF, and font technologies, and many others, that came from their company changed the publishing model of the entire world. See https://www.cs.utah.edu/adobe-co-founder-and-kahlert-school-of-computing-alum-john-warnock-passes-away/ https://www.ksl.com/article/50713319/adobe-co-founder-utah-native-john-warnock-dies-at-82 https://www.adobe.com/ https://en.wikipedia.org/wiki/Charles_Geschke https://en.wikipedia.org/wiki/John_Warnock John's doctoral thesis is available at: https://www.proquest.com/pqdtglobal/docview/302478116/2F149E6F459946B7PQ ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah - - 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 tuhs at tuhs.org Tue Aug 22 09:49:27 2023 From: tuhs at tuhs.org (Pete Wright via TUHS) Date: Mon, 21 Aug 2023 16:49:27 -0700 Subject: [TUHS] John Warnock [1940--2023] In-Reply-To: References: Message-ID: <0e67533b-da31-719a-e712-e798ca1bbe30@nomadlogic.org> On 8/21/23 14:24, Nelson H. F. Beebe wrote: > [This posting was sent earlier today to some local lists, but may also > be of interest to TUHS members.] > > The UofUtah lost one its significant alumni, John Warnock, on Saturday. > > John received Bachelor's and Master's degrees from the Department of > Mathematics, and his doctoral degree from the Department of Electrical > Engineering. > > After jobs at Evans & Sutherland in Salt Lake City, and Xerox PARC > labs in Palo Alto, CA, he later went on to co-found Adobe Systems with > Chuck Geschke (1939--2021), and the PostScript, PDF, and font > technologies, and many others, that came from their company changed > the publishing model of the entire world. > Wow I never realized the work he did with the Warnock algorithm, as in I was familiar with similar approaches to rendering in film and video (tiling and stitching frames together in renderman for example) - but was never made aware that those approaches probably stemmed from his phd thesis. I feel like a lot of modern data processing pipelines could learn a thing or two from this approach. Thanks for sharing... -pete -- Pete Wright pete at nomadlogic.org @nomadlogicLA From athornton at gmail.com Fri Aug 25 09:26:25 2023 From: athornton at gmail.com (Adam Thornton) Date: Thu, 24 Aug 2023 16:26:25 -0700 Subject: [TUHS] Emacs on v7 Message-ID: I finally got an Emacs running on v7--it's on misspiggy at LCML now as "ue". It's Microemacs 3.6; what I did was to clone https://github.com/troglobit/MicroEMACS and check out the first commit. Some experimentation later, it had the usual problem with v7 and DEC linkers that not all the function names (er, more generally exported symbols, but in this case, function names) were unique in the first 7 characters (which is 6 if you're working with DEC OSes). So a bit of sed later and I had something that built, linked, and appears to run with TERM=vt100 set. Arrow keys, naturally, don't work, but C-b, C-f, C-p, C-n do. I think I'm going to just make a GH repo of it, but I'm happy to send the tarball, or tar.uue, upon request. I find UUCP kinda fragile on my simh installation, and I don't know how to get to Miss Piggy's (although the uucp commands are there), so, well, uuencoding, a pasteboard buffer, iTerm2's "Paste Slowly", and cat will work as a file transfer mechanism. Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From velocityboy at gmail.com Fri Aug 25 10:19:36 2023 From: velocityboy at gmail.com (Jim Geist) Date: Thu, 24 Aug 2023 18:19:36 -0600 Subject: [TUHS] Emacs on v7 In-Reply-To: References: Message-ID: misspiggy? Is LCML back open? On Thu, Aug 24, 2023 at 5:26 PM Adam Thornton wrote: > I finally got an Emacs running on v7--it's on misspiggy at LCML now as > "ue". > > It's Microemacs 3.6; what I did was to clone > https://github.com/troglobit/MicroEMACS and check out the first commit. > > Some experimentation later, it had the usual problem with v7 and DEC > linkers that not all the function names (er, more generally exported > symbols, but in this case, function names) were unique in the first 7 > characters (which is 6 if you're working with DEC OSes). So a bit of sed > later and I had something that built, linked, and appears to run with > TERM=vt100 set. > > Arrow keys, naturally, don't work, but C-b, C-f, C-p, C-n do. > > I think I'm going to just make a GH repo of it, but I'm happy to send the > tarball, or tar.uue, upon request. I find UUCP kinda fragile on my simh > installation, and I don't know how to get to Miss Piggy's (although the > uucp commands are there), so, well, uuencoding, a pasteboard buffer, > iTerm2's "Paste Slowly", and cat will work as a file transfer mechanism. > > Adam > -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Fri Aug 25 13:02:59 2023 From: athornton at gmail.com (Adam Thornton) Date: Thu, 24 Aug 2023 20:02:59 -0700 Subject: [TUHS] Emacs on v7 In-Reply-To: References: Message-ID: LCML is not open to physical visitors but a couple days ago, someone posted on Mastodon about misspiggy and you can ssh misspiggy at tty.livingcomputers.org and it works, so.... On Thu, Aug 24, 2023 at 5:19 PM Jim Geist wrote: > misspiggy? Is LCML back open? > > On Thu, Aug 24, 2023 at 5:26 PM Adam Thornton wrote: > >> I finally got an Emacs running on v7--it's on misspiggy at LCML now as >> "ue". >> >> It's Microemacs 3.6; what I did was to clone >> https://github.com/troglobit/MicroEMACS and check out the first commit. >> >> Some experimentation later, it had the usual problem with v7 and DEC >> linkers that not all the function names (er, more generally exported >> symbols, but in this case, function names) were unique in the first 7 >> characters (which is 6 if you're working with DEC OSes). So a bit of sed >> later and I had something that built, linked, and appears to run with >> TERM=vt100 set. >> >> Arrow keys, naturally, don't work, but C-b, C-f, C-p, C-n do. >> >> I think I'm going to just make a GH repo of it, but I'm happy to send the >> tarball, or tar.uue, upon request. I find UUCP kinda fragile on my simh >> installation, and I don't know how to get to Miss Piggy's (although the >> uucp commands are there), so, well, uuencoding, a pasteboard buffer, >> iTerm2's "Paste Slowly", and cat will work as a file transfer mechanism. >> >> Adam >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Fri Aug 25 15:53:31 2023 From: lars at nocrew.org (Lars Brinkhoff) Date: Fri, 25 Aug 2023 05:53:31 +0000 Subject: [TUHS] Emacs on v7 In-Reply-To: (Adam Thornton's message of "Thu, 24 Aug 2023 20:02:59 -0700") References: Message-ID: <7wwmxjvfac.fsf@junk.nocrew.org> Adam Thornton wrote: > LCML is not open to physical visitors but a couple days ago, someone posted > on Mastodon about misspiggy and you can ssh > misspiggy at tty.livingcomputers.org and it works, so.... Remote access to several of their computers has been open all along. ssh menu at tty.livingcomputers.org From crossd at gmail.com Sat Aug 26 01:40:19 2023 From: crossd at gmail.com (Dan Cross) Date: Fri, 25 Aug 2023 11:40:19 -0400 Subject: [TUHS] Fwd: [SDF] Computer Museum In-Reply-To: <202308250110.37P1AaQB018617@sdf.org> References: <202308250110.37P1AaQB018617@sdf.org> Message-ID: I thought folks on COFF and TUHS (Bcc'ed) might find this interesting. Given the overlap between SDF and LCM+L, I wonder what this may mean for the latter. - Dan C. ---------- Forwarded message --------- From: SDF Membership Date: Thu, Aug 24, 2023 at 9:10 PM Subject: [SDF] Computer Museum To: We're in the process of opening a computer museum in the Seattle area and are holding our first public event on September 30th - October 1st. The museum features interactive exhibits of various vintage computers with a number of systems remotely accessible via telnet/ssh for those who are unable to visit in person. If this interests you, please consider replying with comments and take the ascii survey below. You can mark an X for what interests you. I would like to know more about: [ ] visiting the museum [ ] how to access the remote systems [ ] becoming a regular volunteer or docent [ ] restoring and maintaining various vintage systems [ ] curation and exhibit design [ ] supporting the museum with an annual membership [ ] supporting the museum with an annual sponsorship [ ] funding the museum endowment [ ] day to day administration and operations [ ] hosting an event or meet up at museum [ ] teaching at the museum [ ] donating an artifact Info on our first public event can be found at https://sdf.org/icf From arnold at skeeve.com Sat Aug 26 03:44:14 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 25 Aug 2023 10:44:14 -0700 Subject: [TUHS] Bell Labs CSTRs Message-ID: <202308251744.37PHiFCw001837@freefriends.org> Hello Folks, A while back I made avaiable a tarball of two directories I had of Bell Labs CSTRs (Computing Science Technical Reports). There was some overlap between them, and at the time I didn't have the free time to go through and weed through the duplicates. I have now done that. There is a new tar file available at https://www.skeeve.com/combined-cstr.tar.gz Warren, please add this to the TUHS archives. Enjoy, Arnold From arnold at skeeve.com Sat Aug 26 04:05:27 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 25 Aug 2023 12:05:27 -0600 Subject: [TUHS] off topic: old linux drivers? Message-ID: <202308251805.37PI5R4F004895@freefriends.org> Does anyone collect old Linux drivers? I just found one for the "Backpack CD" which was a CD-ROM reader that would attach to a PC via the parallel port. This is from April and May 1997. Before I nuke the code, I thought I'd ask if there is anyone who collects such things. Feel free to reply privately. Thanks, Arnold From tuhs at tuhs.org Sat Aug 26 04:15:59 2023 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Fri, 25 Aug 2023 13:15:59 -0500 Subject: [TUHS] off topic: old linux drivers? In-Reply-To: <202308251805.37PI5R4F004895@freefriends.org> References: <202308251805.37PI5R4F004895@freefriends.org> Message-ID: <274b5176-8169-b8bf-0663-46a350c2a0ca@tnetconsulting.net> On 8/25/23 1:05 PM, arnold at skeeve.com wrote: > Does anyone collect old Linux drivers? I just found one for the > "Backpack CD" which was a CD-ROM reader that would attach to a PC via > the parallel port. This is from April and May 1997. Before I nuke the > code, I thought I'd ask if there is anyone who collects such things. I'm guessing that it's small. I'd suggest uploading it to The Internet Archive. -- Grant. . . . From tuhs at tuhs.org Sat Aug 26 05:51:37 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 25 Aug 2023 19:51:37 +0000 Subject: [TUHS] UNIX Disassemblers and other RE Tools Message-ID: <0brzeViMphXChfHcG_z67mvox9cjHK0KEt6b0VPndBMnBcJ4ywJQFoiJ-yMaR2x2FAnxqD8RjdVCf01kftJkhw0AopHnGcoY8yCpbujx56s=@protonmail.com> Hello, I've been doing some research on the history of disassembly lately, tools available historically, today, and what sorts of developments have been made regarding utilities and systems for taking a machine-code binary and working it back to some semblance of source code. So in the early days UNIX had das(I), a PDP-11 disassembler I believe written by Ken (he's OWNER in the manual) with very little information other than "it exists". Fast forward to the UNIX 4.1 manual in 1981 for the 3B20S and there is dis(1), a 3B20 disassembler. Other such manuals feature dis(1) versions for other 3B targets. Was a disassembler ever considered part of the standard binary objects toolkit with the assembler, linker, etc. or was that the sort of thing that was more niche and therefore just kinda cropped up when/if someone decided to write one? Were there legal concerns to be grappled with when producing a disassembler? Were such tools ever shipped or did they only appear in the manuals as they were technically up in the code base, just not commonly distributed or used? Also, was there any thought given during the development of C to producing "decompilers" as has been becoming more common lately? Or was it a foregone conclusion that C to assembly is a "lossy" conversion and going the other direction couldn't be fully automated. Thank you for any insights! - Matt G. From rich.salz at gmail.com Sat Aug 26 06:28:00 2023 From: rich.salz at gmail.com (Rich Salz) Date: Fri, 25 Aug 2023 16:28:00 -0400 Subject: [TUHS] UNIX Disassemblers and other RE Tools In-Reply-To: <0brzeViMphXChfHcG_z67mvox9cjHK0KEt6b0VPndBMnBcJ4ywJQFoiJ-yMaR2x2FAnxqD8RjdVCf01kftJkhw0AopHnGcoY8yCpbujx56s=@protonmail.com> References: <0brzeViMphXChfHcG_z67mvox9cjHK0KEt6b0VPndBMnBcJ4ywJQFoiJ-yMaR2x2FAnxqD8RjdVCf01kftJkhw0AopHnGcoY8yCpbujx56s=@protonmail.com> Message-ID: > Was a disassembler ever considered part of the standard binary objects > toolkit with the assembler, linker, etc. or was that the sort of thing that > was more niche and therefore just kinda cropped up when/if someone decided > to write one? There was a Vax decompiler around the time of 4.2BSD that was available from some university (Utah?). It was commonly used to decompile Peter Langston's empire program so it could be run on a bunch of the other Unix minicomputers that were available at that time. (E.g., we ran it on Pyramid's) -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Aug 26 06:33:08 2023 From: clemc at ccc.com (Clem Cole) Date: Fri, 25 Aug 2023 16:33:08 -0400 Subject: [TUHS] UNIX Disassemblers and other RE Tools In-Reply-To: <0brzeViMphXChfHcG_z67mvox9cjHK0KEt6b0VPndBMnBcJ4ywJQFoiJ-yMaR2x2FAnxqD8RjdVCf01kftJkhw0AopHnGcoY8yCpbujx56s=@protonmail.com> References: <0brzeViMphXChfHcG_z67mvox9cjHK0KEt6b0VPndBMnBcJ4ywJQFoiJ-yMaR2x2FAnxqD8RjdVCf01kftJkhw0AopHnGcoY8yCpbujx56s=@protonmail.com> Message-ID: below... On Fri, Aug 25, 2023 at 3:51 PM segaloco via TUHS wrote: > Hello, I've been doing some research on the history of disassembly lately, > tools available historically, today, and what sorts of developments have > been made regarding utilities and systems for taking a machine-code binary > and working it back to some semblance of source code. > > So in the early days UNIX had das(I), a PDP-11 disassembler I believe > written by Ken (he's OWNER in the manual) with very little information > other than "it exists". Fast forward to the UNIX 4.1 manual in 1981 for > the 3B20S and there is dis(1), a 3B20 disassembler. Other such manuals > feature dis(1) versions for other 3B targets. > > Was a disassembler ever considered part of the standard binary objects > toolkit with the assembler, linker, etc. not to my memory - although some of the debuggers could. IIRC, the DDT that was on the Harvard tape knew about it. I also remember on that tape was a PDP-11 disassembler. Phil Karn wrote a table-based one for UNIX when we were students - but it was aimed at 8-bit micros. It could do 8080/8085 and Z80; if I remember, it could also do MOS6502 and M6800. It had a feature that it could take an external symbol table and turn out code that was reasonable to reassemble. [ I may have a copy if it squirreled away ]. That said, while they we not part of the core tool kit, by the time of BSD4.2 there were a couple of disassemblers kicking around the USENET. I remember one for the Vax and another for the 68000. You might do a grep for dis-assembler in the USENET archives for comp.sources > or was that the sort of thing that was more niche and therefore just kinda > cropped up when/if someone decided to write one? exactly - need driven. Phil wrote his when we were trying to pull apart a ROM for a tape controller. It had a funky interface on it that was not well documented and what we did have, was wrong. So, disassembled enough of the ROM that we could changed it. > Were there legal concerns to be grappled with when producing a > disassembler? Mumble ... by the mid-80s/late-90 people we disassembling code for game controllers and PCs. So many manufacturers started adding words in the EULA saying that was a no-no. But I don't remember worrying about it much when I was a student 10-15 years before that. > Were such tools ever shipped or did they only appear in the manuals as > they were technically up in the code base, just not commonly distributed or > used? Also, was there any thought given during the development of C to > producing "decompilers" as has been becoming more common lately? Or was it > a foregone conclusion that C to assembly is a "lossy" conversion and going > the other direction couldn't be fully automated. > Again - in V6/V7 with DMR's compiler, it was not always easy, but the code generally was pretty straightforward. Post Wulf's 'Green Book' on compiler optimization and we started to have a generation of BLISS-style optimizers pretty much everywhere, I think those compilers really started refactoring code plus instruction sets got more sophisticated, so I think it started to get harder and harder to reconstruct. But I'll defer to someone like Paul W or Steve Johnson who loved building those style of tools. > > Thank you for any insights! > > - Matt G. > ᐧ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From beebe at math.utah.edu Sun Aug 27 03:02:15 2023 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Sat, 26 Aug 2023 11:02:15 -0600 Subject: [TUHS] Bell Labs CSTRs Message-ID: Yesterday, Arnold Robbins kindly posted to this list a link to a bundle of Bell Labs Computing Science Technical Reports that he had, luckily for us, and for Unix, IX, and Plan 9 history, preserved in his personal library. There are 67 distinct report numbers in the bundle, and 79 different files. Today, I completed a merger of data from all of those reports into the BibTeX entries in the extensive bibliography at https://www.math.utah.edu/pub/tex/bib/unix.bib https://www.math.utah.edu/pub/tex/bib/unix.html Arnold's bundle has mostly PostScript files, but some also have PDF companions. I expect to make PDF versions available for all of them in the TUHS archives, but for now, the new BibTeX entries do not yet have suitable URLs for their retrieval. URLs will be retrofitted once the files are widely available in TUHS mirrors. Some of the reports had already been recorded in unix.bib; those that had not carry a value "Fri Aug 25" in the bibdate string, making them easy to find with a text editor, or with an SQL search in the companion SQLite3 database at https://www.math.utah.edu/pub/tex/bib/unix.db For example, % sqlite3 unix.db sqlite> .mode table sqlite> select label, title from bibtab where bibtimestamp like '2023.08.25%' order by number; For TUHS member convenience, here is a summary from unix.bib of the thus-far-recorded Bell Labs report numbers, their year (several are undated, and thus assigned 19xx), their page counts, and their titles, ordered by increasing report numbers, with column widths chosen to limit lines to 80 characters: sqlite> .mode table sqlite> .width -4 4 -8 51 sqlite> select number, year, pages, title from bibtab where (filename = 'unix.bib') and (type = 'Computing Science Technical Report') order by 0 + number; +------+------+----------+-----------------------------------------------------+ | numb | year | pages | title | +------+------+----------+-----------------------------------------------------+ | 2 | 1972 | ii + 13 | The M6 Macro Processor | +------+------+----------+-----------------------------------------------------+ | 33 | 1975 | ii + 18 | A User's Guide to DODES, a Double Precision Ordinar | | | | | y Differential Equation Solver | +------+------+----------+-----------------------------------------------------+ | 52 | 1976 | ii + 36 | A Tutorial on Galerkin's Method, using on B-splines | | | | | , for Solving Differential Equations | +------+------+----------+-----------------------------------------------------+ | 53 | 1976 | ii + 44 | Numerical Solution of Time-Varying Partial Differen | | | | | tial Equations in One Space Variable | +------+------+----------+-----------------------------------------------------+ | 54 | 1992 | ii + 35 | Troff User's Manual | +------+------+----------+-----------------------------------------------------+ | 89 | 1981 | ii + 64 | A Test of a Computer's Floating-Point Arithmetic Un | | | | | it | +------+------+----------+-----------------------------------------------------+ | 97 | 1982 | ii + 13 | A Typesetter-independent TROFF | +------+------+----------+-----------------------------------------------------+ | 100 | 1981 | ii + 14 | Why Pascal is Not My Favorite Programming Language | +------+------+----------+-----------------------------------------------------+ | 102 | 1981 | 12 | The C Language Calling Sequence | +------+------+----------+-----------------------------------------------------+ | 103 | 1981 | ii + 25 | IDEAL User's Manual | +------+------+----------+-----------------------------------------------------+ | 106e | 1979 | 34 | BPSS | +------+------+----------+-----------------------------------------------------+ | 106d | 1993 | 34 | BASS | +------+------+----------+-----------------------------------------------------+ | 106f | 1993 | 13 | CSWAP with X and Y declared complex | +------+------+----------+-----------------------------------------------------+ | 106b | 1993 | 36 | GESS | +------+------+----------+-----------------------------------------------------+ | 106a | 1993 | i + 10 | Programs for Solving Linear Equations in the PORT L | | | | | ibrary | +------+------+----------+-----------------------------------------------------+ | 106c | 1993 | 30 | SYSS | +------+------+----------+-----------------------------------------------------+ | 114 | 1991 | ii + 37 | Grap --- A Language for Typesetting Graphs Tutorial | | | | | and User Manual | +------+------+----------+-----------------------------------------------------+ | 115 | 1991 | ii + 25 | PIC --- A Graphics Language for Typesetting User Ma | | | | | nual | +------+------+----------+-----------------------------------------------------+ | 117 | 1985 | ii + 2 | A Weakness in the 4.2BSD Unix TCP/IP Software | +------+------+----------+-----------------------------------------------------+ | 118 | 1985 | ii ++ 38 | Awk --- A Pattern Scanning and Processing Language | | | | | Programmer's Manual | +------+------+----------+-----------------------------------------------------+ | 120 | 1985 | ii + 19 | Twig Reference Manual | +------+------+----------+-----------------------------------------------------+ | 122 | 1992 | ii + 31 | CHEM --- a Program for Typesetting Chemical Diagram | | | | | s: User Manual | +------+------+----------+-----------------------------------------------------+ | 123 | 1989 | 29 | C Traps and Pitfalls | +------+------+----------+-----------------------------------------------------+ | 127 | 1991 | 10 | Maintaining Cross References in Manuscripts | +------+------+----------+-----------------------------------------------------+ | 128 | 1986 | ii + 13 | Tools for Printing Indexes | +------+------+----------+-----------------------------------------------------+ | 132 | 1991 | ii + 24 | A System for Algorithm Animation Tutorial and User | | | | | Manual | +------+------+----------+-----------------------------------------------------+ | 133 | 1989 | ii + 63 | AMPL: A Mathematical Programming Language | +------+------+----------+-----------------------------------------------------+ | 135 | 1985 | i + 73 | tt TTGR --- A Package for Solving Partial Different | | | | | ial Equations in Two Space Variables | +------+------+----------+-----------------------------------------------------+ | 136 | 1987 | i + 46 | Pictures of Karmarkar s Linear Programming Algorith | | | | | m | +------+------+----------+-----------------------------------------------------+ | 142 | 1988 | i + 13 | DFORMAT --- a Program for Typesetting Data Formats | +------+------+----------+-----------------------------------------------------+ | 143 | 1993 | ii + 13 | Newsqueak: A Language for Communicating with Mice | +------+------+----------+-----------------------------------------------------+ | 145 | 1992 | ii + 111 | A Permuted Index for TeX and LaTeX | +------+------+----------+-----------------------------------------------------+ | 148 | 1991 | i + 42 | Generating Automatically-Tuned Bitmaps from Outline | | | | | s | +------+------+----------+-----------------------------------------------------+ | 149 | 1995 | i + 25 | A Fortran-to-C Converter | +------+------+----------+-----------------------------------------------------+ | 150 | 1990 | 10 | Terminal Call Processing in Esterel | +------+------+----------+-----------------------------------------------------+ | 153 | 1990 | i + 21 | Usage Summary for Selected Optimization Routines | +------+------+----------+-----------------------------------------------------+ | 154 | 1990 | i + 52 | tt TTGU --- A Package for Solving Time Varying Part | | | | | ial Differential Equations on a Union of Rectangles | +------+------+----------+-----------------------------------------------------+ | 155 | 19xx | 29 | There Is No Royal Road to Programs: A Trilogy on Ra | | | | | ster Ellipses and Programming Methodology | +------+------+----------+-----------------------------------------------------+ | 157 | 1991 | ii + 39 | Tutorial: Design and Validation of Protocols | +------+------+----------+-----------------------------------------------------+ | 158g | 19xx | 14 | Rc --- A Shell for Plan 9 and UNIX Systems | +------+------+----------+-----------------------------------------------------+ | 158b | 19xx | 9 | Plan 9 from Bell Labs | +------+------+----------+-----------------------------------------------------+ | 158a | 19xx | 1 | Plan 9: The Early Papers | +------+------+----------+-----------------------------------------------------+ | 158f | 19xx | 6 | Process Sleep and Wakeup on a Shared-memory Multipr | | | | | ocessor | +------+------+----------+-----------------------------------------------------+ | 158d | 19xx | 9 | $ 8 1 over 2 $, the Plan 9 Window System | +------+------+----------+-----------------------------------------------------+ | 158e | 19xx | 10 | Multiprocessor Streams for Plan 9 | +------+------+----------+-----------------------------------------------------+ | 158c | 19xx | 7 | Plan 9, A Distributed System | +------+------+----------+-----------------------------------------------------+ | 158h | 19xx | 12 | A New C Compiler | +------+------+----------+-----------------------------------------------------+ | 159 | 19xx | 15 | Efficient Algorithms for Constructing Testing Sets, | | | | | Covering Paths, and Minimum Flows | +------+------+----------+-----------------------------------------------------+ | 160 | 1991 | 21 | What is ``Object-Oriented Programming''? | +------+------+----------+-----------------------------------------------------+ | 161 | 19xx | 19 | Sixteen Ways to Stack a Cat | +------+------+----------+-----------------------------------------------------+ | 162 | 19xx | 91 | A User's Manual for MetaPost | +------+------+----------+-----------------------------------------------------+ | 163i | 1992 | 50 | GETLAB | +------+------+----------+-----------------------------------------------------+ | 163 | 1992 | 1 | The IX Multilevel-Secure UNIX System | +------+------+----------+-----------------------------------------------------+ | 163h | 19xx | 2 | Glossary | +------+------+----------+-----------------------------------------------------+ | 163d | 19xx | 12 | The Design of IX | +------+------+----------+-----------------------------------------------------+ | 163c | 19xx | 19 | Multilevel Security in the UNIX Tradition | +------+------+----------+-----------------------------------------------------+ | 163f | 19xx | 3 | Multilevel Windows on a Single-level Terminal | +------+------+----------+-----------------------------------------------------+ | 163e | 19xx | 11 | A Tour of IX | +------+------+----------+-----------------------------------------------------+ | 163b | 19xx | 1 | The IX Multilevel-Secure UNIX System | +------+------+----------+-----------------------------------------------------+ | 163g | 19xx | 8 | Secure IX Network | +------+------+----------+-----------------------------------------------------+ | 164 | 19xx | i + 20 | Drawing Graphs with MetaPost | +------+------+----------+-----------------------------------------------------+ Here is a table of authors: sqlite> .width -4 4 62 sqlite> .output foo.out.6 sqlite> select number, year, author from bibtab where (filename = 'unix.bib') and (type = 'Computing Science Technical Report') order by 0 + number; +------+------+----------------------------------------------------------------+ | numb | year | author | +------+------+----------------------------------------------------------------+ | 2 | 1972 | Andrew D. Hall | +------+------+----------------------------------------------------------------+ | 33 | 1975 | Norman L. Schryer | +------+------+----------------------------------------------------------------+ | 52 | 1976 | Norman L. Schryer | +------+------+----------------------------------------------------------------+ | 53 | 1976 | Norman L. Schryer | +------+------+----------------------------------------------------------------+ | 54 | 1992 | Joseph F. Ossanna and Brian W. Kernighan | +------+------+----------------------------------------------------------------+ | 89 | 1981 | Norman L. Schryer | +------+------+----------------------------------------------------------------+ | 97 | 1982 | Brian W. Kernighan | +------+------+----------------------------------------------------------------+ | 100 | 1981 | Brian W. Kernighan | +------+------+----------------------------------------------------------------+ | 102 | 1981 | Steven C. Johnson and Dennis M. Ritchie | +------+------+----------------------------------------------------------------+ | 103 | 1981 | Christopher J. Van Wyk | +------+------+----------------------------------------------------------------+ | 106e | 1979 | Linda Kaufman | +------+------+----------------------------------------------------------------+ | 106d | 1993 | Linda Kaufman | +------+------+----------------------------------------------------------------+ | 106f | 1993 | Linda Kaufman | +------+------+----------------------------------------------------------------+ | 106b | 1993 | Linda Kaufman | +------+------+----------------------------------------------------------------+ | 106a | 1993 | Linda Kaufman | +------+------+----------------------------------------------------------------+ | 106c | 1993 | Linda Kaufman | +------+------+----------------------------------------------------------------+ | 114 | 1991 | Jon L. Bentley and Brian W. Kernighan | +------+------+----------------------------------------------------------------+ | 115 | 1991 | Brian W. Kernighan | +------+------+----------------------------------------------------------------+ | 117 | 1985 | Robert T. Morris | +------+------+----------------------------------------------------------------+ | 118 | 1985 | Alfred V. Aho and Brian W. Kernighan and Peter 3. Weinberger | +------+------+----------------------------------------------------------------+ | 120 | 1985 | Steven W. K. Tjiang | +------+------+----------------------------------------------------------------+ | 122 | 1992 | Jon L. Bentley and Lynn W. Jelinski and Brian W. Kernighan | +------+------+----------------------------------------------------------------+ | 123 | 1989 | Andrew Koenig | +------+------+----------------------------------------------------------------+ | 127 | 1991 | Alfred V. Aho and Ravi Sethi | +------+------+----------------------------------------------------------------+ | 128 | 1986 | Jon L. Bentley and Brian W. Kernighan | +------+------+----------------------------------------------------------------+ | 132 | 1991 | Jon L. Bentley and Brian W. Kernighan | +------+------+----------------------------------------------------------------+ | 133 | 1989 | Robert Fourer and David M. Gay and Brian W. Kernighan | +------+------+----------------------------------------------------------------+ | 135 | 1985 | Linda Kaufman and Norman L. Schryer | +------+------+----------------------------------------------------------------+ | 136 | 1987 | David M. Gay | +------+------+----------------------------------------------------------------+ | 142 | 1988 | J. L. Bentley | +------+------+----------------------------------------------------------------+ | 143 | 1993 | Rob Pike | +------+------+----------------------------------------------------------------+ | 145 | 1992 | Bill Cheswick | +------+------+----------------------------------------------------------------+ | 148 | 1991 | John D. Hobby | +------+------+----------------------------------------------------------------+ | 149 | 1995 | S. I. Feldman and David M. Gay and Mark W. Maimone and N. L. S | | | | chryer | +------+------+----------------------------------------------------------------+ | 150 | 1990 | Gary J. Murakami and Ravi Sethi | +------+------+----------------------------------------------------------------+ | 153 | 1990 | David M. Gay | +------+------+----------------------------------------------------------------+ | 154 | 1990 | Linda Kaufman | +------+------+----------------------------------------------------------------+ | 155 | 19xx | M. Douglas McIlroy | +------+------+----------------------------------------------------------------+ | 157 | 1991 | Gerard J. Holzmann | +------+------+----------------------------------------------------------------+ | 158g | 19xx | Tom Duff | +------+------+----------------------------------------------------------------+ | 158b | 19xx | Rob Pike and Dave Presotto and Ken Thompson and Howard Trickey | +------+------+----------------------------------------------------------------+ | 158a | 19xx | Rob Pike and Dave Presotto and Ken Thompson and Howard Trickey | | | | and Tom Duff and Gerard Holzmann | +------+------+----------------------------------------------------------------+ | 158f | 19xx | Rob Pike and Dave Presotto and Ken Thompson and Gerard Holzman | | | | n | +------+------+----------------------------------------------------------------+ | 158d | 19xx | Rob Pike | +------+------+----------------------------------------------------------------+ | 158e | 19xx | David Leo Presotto | +------+------+----------------------------------------------------------------+ | 158c | 19xx | Dave Presotto and Rob Pike and Ken Thompson and Howard Trickey | +------+------+----------------------------------------------------------------+ | 158h | 19xx | Ken Thompson | +------+------+----------------------------------------------------------------+ | 159 | 19xx | Alfred V. Aho and David Lee | +------+------+----------------------------------------------------------------+ | 160 | 1991 | Bjarne Stroustrup | +------+------+----------------------------------------------------------------+ | 161 | 19xx | Bjarne Stroustrup | +------+------+----------------------------------------------------------------+ | 162 | 19xx | John D. Hobby | +------+------+----------------------------------------------------------------+ | 163i | 1992 | Anonymous | +------+------+----------------------------------------------------------------+ | 163 | 1992 | James A. Reeds and M. Douglas McIlroy | +------+------+----------------------------------------------------------------+ | 163h | 19xx | Anonymous | +------+------+----------------------------------------------------------------+ | 163d | 19xx | M. D. McIlroy and J. A. Reeds | +------+------+----------------------------------------------------------------+ | 163c | 19xx | M. D. McIlroy and J. A. Reeds | +------+------+----------------------------------------------------------------+ | 163f | 19xx | M. D. McIlroy and J. A. Reeds | +------+------+----------------------------------------------------------------+ | 163e | 19xx | Doug McIlroy and Jim Reeds | +------+------+----------------------------------------------------------------+ | 163b | 19xx | James A. Reeds and M. Douglas McIlroy | +------+------+----------------------------------------------------------------+ | 163g | 19xx | Jim Reeds | +------+------+----------------------------------------------------------------+ | 164 | 19xx | John D. Hobby | +------+------+----------------------------------------------------------------+ ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah - - 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 jsg at jsg.id.au Sun Aug 27 13:13:32 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Sun, 27 Aug 2023 13:13:32 +1000 Subject: [TUHS] Bell Labs CSTRs In-Reply-To: References: Message-ID: On Sat, Aug 26, 2023 at 11:02:15AM -0600, Nelson H. F. Beebe wrote: > Yesterday, Arnold Robbins kindly posted to this list a link to a > bundle of Bell Labs Computing Science Technical Reports that he had, > luckily for us, and for Unix, IX, and Plan 9 history, preserved in his > personal library. > > There are 67 distinct report numbers in the bundle, and 79 different > files. See bib/index.html in the tarball for a full list > | 115 | 1991 | ii + 25 | PIC --- A Graphics Language for Typesetting User Ma | > | | | | nual | PIC is 116, not 115 From arnold at skeeve.com Mon Aug 28 04:03:54 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 27 Aug 2023 11:03:54 -0700 Subject: [TUHS] Update CSTR tarball Message-ID: <202308271803.37RI3vHH022486@freefriends.org> Hello All. Nelson Beebe has added PDF files for all the .ps files that didn't have them, and I did a little bit more cleaning up of the CSTRs I made available late last week. The new file is at https://www.skeeve.com/combined-cstr-2.tar.gz Warren will eventually add them to the archive, at which point I will probably take down my copies. Nelson and I request of the CSTR authors who are on the TUHS list if they are willing to make source code for their CSTRs available? That would certainly help in the preservation effort. Thanks, Arnold From douglas.mcilroy at dartmouth.edu Mon Aug 28 06:23:30 2023 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sun, 27 Aug 2023 16:23:30 -0400 Subject: [TUHS] Update CSTR tarball In-Reply-To: <202308271803.37RI3vHH022486@freefriends.org> References: <202308271803.37RI3vHH022486@freefriends.org> Message-ID: Here's the status of source for CSTRs by me. All extant source is troff -ms. Which ones might be wanted? 14 Synthetic speech Source does not exist; scanned pages are available. 139 Unix reader Source exists for front matter including combined table of contents, but not for pages copied from Unix manuals. 155 Trilogy on ellipses Source exists. Figures for the first paper are in Ideal, together with troff intermediate. 163 IX Source exists. On Sun, Aug 27, 2023 at 2:04 PM wrote: > > Hello All. > > Nelson Beebe has added PDF files for all the .ps files that didn't > have them, and I did a little bit more cleaning up of the CSTRs > I made available late last week. The new file is at > > https://www.skeeve.com/combined-cstr-2.tar.gz > > Warren will eventually add them to the archive, at which point I will > probably take down my copies. > > Nelson and I request of the CSTR authors who are on the TUHS list if > they are willing to make source code for their CSTRs available? That > would certainly help in the preservation effort. > > Thanks, > > Arnold From arnold at skeeve.com Mon Aug 28 06:50:14 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 27 Aug 2023 14:50:14 -0600 Subject: [TUHS] Update CSTR tarball In-Reply-To: References: <202308271803.37RI3vHH022486@freefriends.org> Message-ID: <202308272050.37RKoEeP017755@freefriends.org> Hi Doug, I'd think we'd want everything we can get.... :-) Warren, should it go straight to you? Thanks! Arnold Douglas McIlroy wrote: > Here's the status of source for CSTRs by me. All extant source is troff -ms. > Which ones might be wanted? > > 14 Synthetic speech > Source does not exist; scanned pages are available. > > 139 Unix reader > Source exists for front matter including combined table of contents, > but not for pages copied from Unix manuals. > > 155 Trilogy on ellipses > Source exists. > Figures for the first paper are in Ideal, together with troff intermediate. > > 163 IX > Source exists. > > On Sun, Aug 27, 2023 at 2:04 PM wrote: > > > > Hello All. > > > > Nelson Beebe has added PDF files for all the .ps files that didn't > > have them, and I did a little bit more cleaning up of the CSTRs > > I made available late last week. The new file is at > > > > https://www.skeeve.com/combined-cstr-2.tar.gz > > > > Warren will eventually add them to the archive, at which point I will > > probably take down my copies. > > > > Nelson and I request of the CSTR authors who are on the TUHS list if > > they are willing to make source code for their CSTRs available? That > > would certainly help in the preservation effort. > > > > Thanks, > > > > Arnold From tuhs at tuhs.org Mon Aug 28 07:49:07 2023 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Mon, 28 Aug 2023 07:49:07 +1000 Subject: [TUHS] Update CSTR tarball In-Reply-To: <202308271803.37RI3vHH022486@freefriends.org> References: <202308271803.37RI3vHH022486@freefriends.org> Message-ID: On Sun, Aug 27, 2023 at 11:03:54AM -0700, arnold at skeeve.com wrote: > Nelson Beebe has added PDF files for all the .ps files that didn't > have them, and I did a little bit more cleaning up of the CSTRs. > Warren will eventually add them to the archive, at which point I will > probably take down my copies. All, I've just untarred the documents and they are now at: https://www.tuhs.org/Archive/Documentation/TechReports/Bell_Labs/CSTRs/ Thanks to all who helped find and curate these documents. Cheers, Warren From jsg at jsg.id.au Mon Aug 28 11:01:56 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Mon, 28 Aug 2023 11:01:56 +1000 Subject: [TUHS] Update CSTR tarball In-Reply-To: References: <202308271803.37RI3vHH022486@freefriends.org> Message-ID: On Sun, Aug 27, 2023 at 04:23:30PM -0400, Douglas McIlroy wrote: > Here's the status of source for CSTRs by me. All extant source is troff -ms. > Which ones might be wanted? > > 14 Synthetic speech > Source does not exist; scanned pages are available. 41 An Algorithm for Differential File Comparison source for the reconstructed version of this may also exist? > > 139 Unix reader > Source exists for front matter including combined table of contents, > but not for pages copied from Unix manuals. > > 155 Trilogy on ellipses > Source exists. > Figures for the first paper are in Ideal, together with troff intermediate. > > 163 IX > Source exists. > > On Sun, Aug 27, 2023 at 2:04 PM wrote: > > > > Hello All. > > > > Nelson Beebe has added PDF files for all the .ps files that didn't > > have them, and I did a little bit more cleaning up of the CSTRs > > I made available late last week. The new file is at > > > > https://www.skeeve.com/combined-cstr-2.tar.gz > > > > Warren will eventually add them to the archive, at which point I will > > probably take down my copies. > > > > Nelson and I request of the CSTR authors who are on the TUHS list if > > they are willing to make source code for their CSTRs available? That > > would certainly help in the preservation effort. > > > > Thanks, > > > > Arnold > From phil at ultimate.com Tue Aug 29 09:03:15 2023 From: phil at ultimate.com (Phil Budne) Date: Mon, 28 Aug 2023 19:03:15 -0400 Subject: [TUHS] 3bsd tape image In-Reply-To: References: Message-ID: <202308282303.37SN3FVJ034316@ultimate.com> I got curious, and decided to try booting the 3bsd tape image: > http://sourceforge.net/projects/bsd42/files/Install%20tapes/3%20BSD/3bsd.tap.bz2/download I didn't try building anything Install instructions viewable (once installed, or from https://www.tuhs.org/Archive/Distributions/UCB/3bsd.tar.gz) via: nroff -ms /usr/doc/vmunix/newsetup.t ================ 3bsd-tboot.ini set tto 7b ; from https://gunkies.org/wiki/Installing_32V_on_SIMH#tboot.ini set rq dis set lpt dis set rl dis set hk dis set rq dis set rqb dis set rqc dis set rqd dis set ry dis set ts dis set tq dis set dz lines=8 set rp0 rp06 at rp0 rp06.disk set tu0 te16 at tu0 3bsd.tap D 30000 20009FDE D 30004 D0512001 D 30008 3204A101 D 3000C C113C08F D 30010 A1D40424 D 30014 008FD00C D 30018 C1800000 D 3001C 8F320800 D 30020 10A1FE00 D 30024 00C139D0 D 30028 04c1d004 D 3002C 07e15004 D 30030 0000f750 go 30000 go 0 ================ installing from tape $ ./simh/BIN/vax780 3bsd-tboot.ini VAX 11/780 simulator Open SIMH V4.1-0 Current git commit id: 348f5f29 /media/INTERNAL/SCRATCH/3bsd/3bsd-tboot.ini-17> at tu0 3bsd.tap %SIM-INFO: TU0: Tape Image '3bsd.tap' scanned as SIMH format HALT instruction, PC: 00030033 (HALT) =mkfs file sys size: 7942 file system: hp(0,0) isize = 5072 m/n = 3 500 =restor Tape? ht(1,1) Disk? hp(0,0) Last chance before scribbling on disk. End of tape =boot Boot : hp(0,0)vmunix 61856+61008+70120 start 0x4B4 VM/UNIX (Berkeley Version 2.7) 2/10/80 real mem = 8323072 avail mem = 8062976 ERASE IS CONTROL-H!!! # ps ax PID TTY TIME COMMAND 0 ? 0:17 swapper 1 ? 0:00 init.vm 2 ? 0:00 pagedaemon 3 co 0:00 - (sh) 7 co 0:00 ps ax # vmstat Procs Virtual Real Page Swap Disk Cpu RQ DW PW SL SW AVM TX FRE RE PI PO FR DE SR I O D0 D1 D2 CS US NI SY ID 0 0 0 3 0 80 5515518 0 0 0 0 0 0.0 0 0 0 0 0 0 0 0 0100 # chk /dev/rrp0a icheck /dev/rrp0a /dev/rrp0a: files 154 (r=112,d=12,b=8,c=22) used 1078 (i=28,ii=0,iii=0,d=1050) free 6545 missing 0 dcheck /dev/rrp0a /dev/rrp0a: entries link cnt 1 0 0 # /etc/mkfs /dev/rrp0g 145673 isize = 65488 (or 43147 on RM03) m/n = 3 500 # /etc/mount /dev/rp0g /usr # cd /usr # cp /dev/rmt5 /dev/null # cp /dev/rmt5 /dev/null # tar xvbf 20 /dev/rmt1 x ./adm/msgbuf, 0 bytes, 0 tape blocks .... # dd if=/usr/mdec/uboot of=/dev/rrp0a bs=1b count=1 1+0 records in 1+0 records out # passwd root ..... # sync # sync # sync # simh> quit ================ 3bsd-dboot.ini ; from https://gunkies.org/wiki/Installing_32V_on_SIMH#dboot.ini ; (just removed attach tu0) set tto 7b set rq dis set lpt dis set rl dis set hk dis set rq dis set rqb dis set rqc dis set rqd dis set ry dis set ts dis set tq dis set dz 7b set dz lines=16 att dz -m 2311 set rp0 rp06 at rp0 rp06.disk set tu0 te16 D 30000 00009FDE D 30004 D0512001 D 30008 D004A101 D 3000C 0400C113 D 30010 10008F32 D 30014 D40424C1 D 30018 8FD00CA1 D 3001C 80000000 D 30020 320800C1 D 30024 A1FE008F D 30028 28C1D410 D 3002C 14C1D404 D 30030 C139D004 D 30034 c1d00400 D 30038 e1500404 D 3003C 00f75007 go 30000 go 2 ================ boot from disk $ ./simh/BIN/vax780 3bsd-dboot.ini VAX 11/780 simulator Open SIMH V4.1-0 Current git commit id: 348f5f29 /media/INTERNAL/SCRATCH/3bsd/3bsd-dboot.ini-15> att dz -m 2311 %SIM-INFO: Listening on port 2311 Modem control activated HALT instruction, PC: 00030040 (HALT) Boot : hp(0,0)vmunix 61856+61008+70120 start 0x4B4 VM/UNIX (Berkeley Version 2.7) 2/10/80 real mem = 8323072 avail mem = 8062976 ERASE IS CONTROL-H!!! # Sat Sep 27 12:51:17 PDT 1980 entering rc clearing mtab mounting /usr on /dev/rp0g preserving Ex temps and clearing /tmp starting update starting cron leaving rc Virtual VAX/UNIX (Ernie Co-vax) login: (was able to log in on console and tty1 via telnet localhost 2311) ================ shutdown from multi-user # kill 1 # ERASE IS CONTROL-H!!! # sync # sync # sync # Simulation stopped, PC: 8000085F (BLBC 80010FA0,8000085F) sim> q Goodbye From ken.unix.guy at gmail.com Wed Aug 30 03:18:04 2023 From: ken.unix.guy at gmail.com (KenUnix) Date: Tue, 29 Aug 2023 13:18:04 -0400 Subject: [TUHS] 3bsd tape image In-Reply-To: <202308282303.37SN3FVJ034316@ultimate.com> References: <202308282303.37SN3FVJ034316@ultimate.com> Message-ID: Hi all. I made a couple of changes to 3bsd-dboot.ini so it will do the loading for you: set tto 7b set rq dis set lpt dis set rl dis set hk dis set rq dis set rqb dis set rqc dis set rqd dis set ry dis set ts dis set tq dis set dz 7b set dz lines=16 att dz -m 2311 set rp0 rp06 at rp0 rp06.disk set tu0 te16 D 30000 00009FDE D 30004 D0512001 D 30008 D004A101 D 3000C 0400C113 D 30010 10008F32 D 30014 D40424C1 D 30018 8FD00CA1 D 3001C 80000000 D 30020 320800C1 D 30024 A1FE008F D 30028 28C1D410 D 3002C 14C1D404 D 30030 C139D004 D 30034 c1d00400 D 30038 e1500404 D 3003C 00f75007 go 30000 <-- Change below this line and note "go 2" has moved expect "Boot" send "hp(0,0)vmunix\r";c expect "#" send "\004\r";c go 2 Enjoy... On Mon, Aug 28, 2023 at 7:03 PM Phil Budne wrote: > I got curious, and decided to try booting the 3bsd tape image: > > > http://sourceforge.net/projects/bsd42/files/Install%20tapes/3%20BSD/3bsd.tap.bz2/download > > I didn't try building anything > > Install instructions viewable (once installed, or from > https://www.tuhs.org/Archive/Distributions/UCB/3bsd.tar.gz) via: > > nroff -ms /usr/doc/vmunix/newsetup.t > > ================ 3bsd-tboot.ini > > set tto 7b > ; from https://gunkies.org/wiki/Installing_32V_on_SIMH#tboot.ini > set rq dis > set lpt dis > set rl dis > set hk dis > set rq dis > set rqb dis > set rqc dis > set rqd dis > set ry dis > set ts dis > set tq dis > set dz lines=8 > set rp0 rp06 > at rp0 rp06.disk > set tu0 te16 > at tu0 3bsd.tap > D 30000 20009FDE > D 30004 D0512001 > D 30008 3204A101 > D 3000C C113C08F > D 30010 A1D40424 > D 30014 008FD00C > D 30018 C1800000 > D 3001C 8F320800 > D 30020 10A1FE00 > D 30024 00C139D0 > D 30028 04c1d004 > D 3002C 07e15004 > D 30030 0000f750 > go 30000 > go 0 > > ================ installing from tape > > $ ./simh/BIN/vax780 3bsd-tboot.ini > > VAX 11/780 simulator Open SIMH V4.1-0 Current git commit id: > 348f5f29 > /media/INTERNAL/SCRATCH/3bsd/3bsd-tboot.ini-17> at tu0 3bsd.tap > %SIM-INFO: TU0: Tape Image '3bsd.tap' scanned as SIMH format > > HALT instruction, PC: 00030033 (HALT) > =mkfs > file sys size: 7942 > file system: hp(0,0) > isize = 5072 > m/n = 3 500 > =restor > Tape? ht(1,1) > Disk? hp(0,0) > Last chance before scribbling on disk. > End of tape > =boot > > Boot > : hp(0,0)vmunix > 61856+61008+70120 start 0x4B4 > VM/UNIX (Berkeley Version 2.7) 2/10/80 > real mem = 8323072 > avail mem = 8062976 > ERASE IS CONTROL-H!!! > # ps ax > PID TTY TIME COMMAND > 0 ? 0:17 swapper > 1 ? 0:00 init.vm > 2 ? 0:00 pagedaemon > 3 co 0:00 - (sh) > 7 co 0:00 ps ax > # vmstat > Procs Virtual Real Page Swap Disk > Cpu > RQ DW PW SL SW AVM TX FRE RE PI PO FR DE SR I O D0 D1 D2 CS US NI > SY ID > 0 0 0 3 0 80 5515518 0 0 0 0 0 0.0 0 0 0 0 0 0 0 0 > 0100 > # chk /dev/rrp0a > icheck /dev/rrp0a > /dev/rrp0a: > files 154 (r=112,d=12,b=8,c=22) > used 1078 (i=28,ii=0,iii=0,d=1050) > free 6545 > missing 0 > dcheck /dev/rrp0a > /dev/rrp0a: > entries link cnt > 1 0 0 > # /etc/mkfs /dev/rrp0g 145673 > isize = 65488 > (or 43147 on RM03) > m/n = 3 500 > # /etc/mount /dev/rp0g /usr > # cd /usr > # cp /dev/rmt5 /dev/null > # cp /dev/rmt5 /dev/null > # tar xvbf 20 /dev/rmt1 > x ./adm/msgbuf, 0 bytes, 0 tape blocks > .... > > # dd if=/usr/mdec/uboot of=/dev/rrp0a bs=1b count=1 > 1+0 records in > 1+0 records out > > # passwd root > ..... > # sync > # sync > # sync > # > simh> quit > > ================ 3bsd-dboot.ini > > ; from https://gunkies.org/wiki/Installing_32V_on_SIMH#dboot.ini > ; (just removed attach tu0) > set tto 7b > set rq dis > set lpt dis > set rl dis > set hk dis > set rq dis > set rqb dis > set rqc dis > set rqd dis > set ry dis > set ts dis > set tq dis > set dz 7b > set dz lines=16 > att dz -m 2311 > set rp0 rp06 > at rp0 rp06.disk > set tu0 te16 > D 30000 00009FDE > D 30004 D0512001 > D 30008 D004A101 > D 3000C 0400C113 > D 30010 10008F32 > D 30014 D40424C1 > D 30018 8FD00CA1 > D 3001C 80000000 > D 30020 320800C1 > D 30024 A1FE008F > D 30028 28C1D410 > D 3002C 14C1D404 > D 30030 C139D004 > D 30034 c1d00400 > D 30038 e1500404 > D 3003C 00f75007 > go 30000 > go 2 > > ================ boot from disk > > $ ./simh/BIN/vax780 3bsd-dboot.ini > > VAX 11/780 simulator Open SIMH V4.1-0 Current git commit id: > 348f5f29 > /media/INTERNAL/SCRATCH/3bsd/3bsd-dboot.ini-15> att dz -m 2311 > %SIM-INFO: Listening on port 2311 > Modem control activated > > HALT instruction, PC: 00030040 (HALT) > > Boot > : hp(0,0)vmunix > 61856+61008+70120 start 0x4B4 > VM/UNIX (Berkeley Version 2.7) 2/10/80 > real mem = 8323072 > avail mem = 8062976 > ERASE IS CONTROL-H!!! > # > Sat Sep 27 12:51:17 PDT 1980 > entering rc > clearing mtab > mounting /usr on /dev/rp0g > preserving Ex temps and clearing /tmp > starting update > starting cron > leaving rc > > > > Virtual VAX/UNIX (Ernie Co-vax) > > login: > > (was able to log in on console > and tty1 via telnet localhost 2311) > > > ================ shutdown from multi-user > > # kill 1 > # ERASE IS CONTROL-H!!! > # sync > # sync > # sync > # > Simulation stopped, PC: 8000085F (BLBC 80010FA0,8000085F) > sim> q > Goodbye > -- End of line JOB TERMINATED -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.unix.guy at gmail.com Wed Aug 30 21:11:58 2023 From: ken.unix.guy at gmail.com (KenUnix) Date: Wed, 30 Aug 2023 07:11:58 -0400 Subject: [TUHS] 3bsd tape image In-Reply-To: References: <202308282303.37SN3FVJ034316@ultimate.com> Message-ID: Hi all. Got a question. With 3BSD I have been unable to find where the time zone is set. I have looked at date.c, time.h and timebuf.h. In the meantime I fixed date.c to handle Y2K dates. I live on the east coast but the date displays the date as: Wed Aug 30 06:55:36 *PDT* 2023 Pacific time. -Ken On Tue, Aug 29, 2023 at 1:18 PM KenUnix wrote: > Hi all. I made a couple of changes to 3bsd-dboot.ini so it will do the > loading for you: > > set tto 7b > set rq dis > set lpt dis > set rl dis > set hk dis > set rq dis > set rqb dis > set rqc dis > set rqd dis > set ry dis > set ts dis > set tq dis > set dz 7b > set dz lines=16 > att dz -m 2311 > set rp0 rp06 > at rp0 rp06.disk > set tu0 te16 > D 30000 00009FDE > D 30004 D0512001 > D 30008 D004A101 > D 3000C 0400C113 > D 30010 10008F32 > D 30014 D40424C1 > D 30018 8FD00CA1 > D 3001C 80000000 > D 30020 320800C1 > D 30024 A1FE008F > D 30028 28C1D410 > D 3002C 14C1D404 > D 30030 C139D004 > D 30034 c1d00400 > D 30038 e1500404 > D 3003C 00f75007 > go 30000 <-- Change below this line and note "go > 2" has moved > expect "Boot" send "hp(0,0)vmunix\r";c > expect "#" send "\004\r";c > go 2 > > Enjoy... > > On Mon, Aug 28, 2023 at 7:03 PM Phil Budne wrote: > >> I got curious, and decided to try booting the 3bsd tape image: >> > >> http://sourceforge.net/projects/bsd42/files/Install%20tapes/3%20BSD/3bsd.tap.bz2/download >> >> I didn't try building anything >> >> Install instructions viewable (once installed, or from >> https://www.tuhs.org/Archive/Distributions/UCB/3bsd.tar.gz) via: >> >> nroff -ms /usr/doc/vmunix/newsetup.t >> >> ================ 3bsd-tboot.ini >> >> set tto 7b >> ; from https://gunkies.org/wiki/Installing_32V_on_SIMH#tboot.ini >> set rq dis >> set lpt dis >> set rl dis >> set hk dis >> set rq dis >> set rqb dis >> set rqc dis >> set rqd dis >> set ry dis >> set ts dis >> set tq dis >> set dz lines=8 >> set rp0 rp06 >> at rp0 rp06.disk >> set tu0 te16 >> at tu0 3bsd.tap >> D 30000 20009FDE >> D 30004 D0512001 >> D 30008 3204A101 >> D 3000C C113C08F >> D 30010 A1D40424 >> D 30014 008FD00C >> D 30018 C1800000 >> D 3001C 8F320800 >> D 30020 10A1FE00 >> D 30024 00C139D0 >> D 30028 04c1d004 >> D 3002C 07e15004 >> D 30030 0000f750 >> go 30000 >> go 0 >> >> ================ installing from tape >> >> $ ./simh/BIN/vax780 3bsd-tboot.ini >> >> VAX 11/780 simulator Open SIMH V4.1-0 Current git commit id: >> 348f5f29 >> /media/INTERNAL/SCRATCH/3bsd/3bsd-tboot.ini-17> at tu0 3bsd.tap >> %SIM-INFO: TU0: Tape Image '3bsd.tap' scanned as SIMH format >> >> HALT instruction, PC: 00030033 (HALT) >> =mkfs >> file sys size: 7942 >> file system: hp(0,0) >> isize = 5072 >> m/n = 3 500 >> =restor >> Tape? ht(1,1) >> Disk? hp(0,0) >> Last chance before scribbling on disk. >> End of tape >> =boot >> >> Boot >> : hp(0,0)vmunix >> 61856+61008+70120 start 0x4B4 >> VM/UNIX (Berkeley Version 2.7) 2/10/80 >> real mem = 8323072 >> avail mem = 8062976 >> ERASE IS CONTROL-H!!! >> # ps ax >> PID TTY TIME COMMAND >> 0 ? 0:17 swapper >> 1 ? 0:00 init.vm >> 2 ? 0:00 pagedaemon >> 3 co 0:00 - (sh) >> 7 co 0:00 ps ax >> # vmstat >> Procs Virtual Real Page Swap Disk >> Cpu >> RQ DW PW SL SW AVM TX FRE RE PI PO FR DE SR I O D0 D1 D2 CS US NI >> SY ID >> 0 0 0 3 0 80 5515518 0 0 0 0 0 0.0 0 0 0 0 0 0 0 >> 0 0100 >> # chk /dev/rrp0a >> icheck /dev/rrp0a >> /dev/rrp0a: >> files 154 (r=112,d=12,b=8,c=22) >> used 1078 (i=28,ii=0,iii=0,d=1050) >> free 6545 >> missing 0 >> dcheck /dev/rrp0a >> /dev/rrp0a: >> entries link cnt >> 1 0 0 >> # /etc/mkfs /dev/rrp0g 145673 >> isize = 65488 >> (or 43147 on RM03) >> m/n = 3 500 >> # /etc/mount /dev/rp0g /usr >> # cd /usr >> # cp /dev/rmt5 /dev/null >> # cp /dev/rmt5 /dev/null >> # tar xvbf 20 /dev/rmt1 >> x ./adm/msgbuf, 0 bytes, 0 tape blocks >> .... >> >> # dd if=/usr/mdec/uboot of=/dev/rrp0a bs=1b count=1 >> 1+0 records in >> 1+0 records out >> >> # passwd root >> ..... >> # sync >> # sync >> # sync >> # >> simh> quit >> >> ================ 3bsd-dboot.ini >> >> ; from https://gunkies.org/wiki/Installing_32V_on_SIMH#dboot.ini >> ; (just removed attach tu0) >> set tto 7b >> set rq dis >> set lpt dis >> set rl dis >> set hk dis >> set rq dis >> set rqb dis >> set rqc dis >> set rqd dis >> set ry dis >> set ts dis >> set tq dis >> set dz 7b >> set dz lines=16 >> att dz -m 2311 >> set rp0 rp06 >> at rp0 rp06.disk >> set tu0 te16 >> D 30000 00009FDE >> D 30004 D0512001 >> D 30008 D004A101 >> D 3000C 0400C113 >> D 30010 10008F32 >> D 30014 D40424C1 >> D 30018 8FD00CA1 >> D 3001C 80000000 >> D 30020 320800C1 >> D 30024 A1FE008F >> D 30028 28C1D410 >> D 3002C 14C1D404 >> D 30030 C139D004 >> D 30034 c1d00400 >> D 30038 e1500404 >> D 3003C 00f75007 >> go 30000 >> go 2 >> >> ================ boot from disk >> >> $ ./simh/BIN/vax780 3bsd-dboot.ini >> >> VAX 11/780 simulator Open SIMH V4.1-0 Current git commit id: >> 348f5f29 >> /media/INTERNAL/SCRATCH/3bsd/3bsd-dboot.ini-15> att dz -m 2311 >> %SIM-INFO: Listening on port 2311 >> Modem control activated >> >> HALT instruction, PC: 00030040 (HALT) >> >> Boot >> : hp(0,0)vmunix >> 61856+61008+70120 start 0x4B4 >> VM/UNIX (Berkeley Version 2.7) 2/10/80 >> real mem = 8323072 >> avail mem = 8062976 >> ERASE IS CONTROL-H!!! >> # >> Sat Sep 27 12:51:17 PDT 1980 >> entering rc >> clearing mtab >> mounting /usr on /dev/rp0g >> preserving Ex temps and clearing /tmp >> starting update >> starting cron >> leaving rc >> >> >> >> Virtual VAX/UNIX (Ernie Co-vax) >> >> login: >> >> (was able to log in on console >> and tty1 via telnet localhost 2311) >> >> >> ================ shutdown from multi-user >> >> # kill 1 >> # ERASE IS CONTROL-H!!! >> # sync >> # sync >> # sync >> # >> Simulation stopped, PC: 8000085F (BLBC 80010FA0,8000085F) >> sim> q >> Goodbye >> > > > -- > End of line > JOB TERMINATED > > > -- End of line JOB TERMINATED -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Aug 31 00:48:31 2023 From: clemc at ccc.com (Clem Cole) Date: Wed, 30 Aug 2023 10:48:31 -0400 Subject: [TUHS] 3bsd tape image In-Reply-To: References: <202308282303.37SN3FVJ034316@ultimate.com> Message-ID: Since 3BSD is V7/V32 based - the TZ is sent in the kernel in sys/param.h and compiled into it. The system calls and user service calls in section 2 and 3 are seeded from the value that the kernel returns. The TZ environment variable was introduced in the PWB / SYS x editions. It was in PWB 3 and may have been added before that. I don't remember when the BSD stream picked it up - it may not have been until after the original /usr/group 1984 UNIX standard of the early 1980s - which I codified it in their environ(5) definition. The team in CSRG for BSD4.2 developed the time modern timezone database that we see in most UNIX flavors at this time. I don't remember where tzset(3) call was introduced, to be honest, it was some time (in years IIRC) after the TZ environment variable originally was created. ᐧ On Wed, Aug 30, 2023 at 7:12 AM KenUnix wrote: > Hi all. > > Got a question. With 3BSD I have been unable to find where the time zone > is set. I have looked at > date.c, time.h and timebuf.h. In the meantime I fixed date.c to handle Y2K > dates. > > I live on the east coast but the date displays the date as: Wed Aug 30 > 06:55:36 *PDT* 2023 Pacific time. > > -Ken > > On Tue, Aug 29, 2023 at 1:18 PM KenUnix wrote: > >> Hi all. I made a couple of changes to 3bsd-dboot.ini so it will do the >> loading for you: >> >> set tto 7b >> set rq dis >> set lpt dis >> set rl dis >> set hk dis >> set rq dis >> set rqb dis >> set rqc dis >> set rqd dis >> set ry dis >> set ts dis >> set tq dis >> set dz 7b >> set dz lines=16 >> att dz -m 2311 >> set rp0 rp06 >> at rp0 rp06.disk >> set tu0 te16 >> D 30000 00009FDE >> D 30004 D0512001 >> D 30008 D004A101 >> D 3000C 0400C113 >> D 30010 10008F32 >> D 30014 D40424C1 >> D 30018 8FD00CA1 >> D 3001C 80000000 >> D 30020 320800C1 >> D 30024 A1FE008F >> D 30028 28C1D410 >> D 3002C 14C1D404 >> D 30030 C139D004 >> D 30034 c1d00400 >> D 30038 e1500404 >> D 3003C 00f75007 >> go 30000 <-- Change below this line and note >> "go 2" has moved >> expect "Boot" send "hp(0,0)vmunix\r";c >> expect "#" send "\004\r";c >> go 2 >> >> Enjoy... >> >> On Mon, Aug 28, 2023 at 7:03 PM Phil Budne wrote: >> >>> I got curious, and decided to try booting the 3bsd tape image: >>> > >>> http://sourceforge.net/projects/bsd42/files/Install%20tapes/3%20BSD/3bsd.tap.bz2/download >>> >>> I didn't try building anything >>> >>> Install instructions viewable (once installed, or from >>> https://www.tuhs.org/Archive/Distributions/UCB/3bsd.tar.gz) via: >>> >>> nroff -ms /usr/doc/vmunix/newsetup.t >>> >>> ================ 3bsd-tboot.ini >>> >>> set tto 7b >>> ; from https://gunkies.org/wiki/Installing_32V_on_SIMH#tboot.ini >>> set rq dis >>> set lpt dis >>> set rl dis >>> set hk dis >>> set rq dis >>> set rqb dis >>> set rqc dis >>> set rqd dis >>> set ry dis >>> set ts dis >>> set tq dis >>> set dz lines=8 >>> set rp0 rp06 >>> at rp0 rp06.disk >>> set tu0 te16 >>> at tu0 3bsd.tap >>> D 30000 20009FDE >>> D 30004 D0512001 >>> D 30008 3204A101 >>> D 3000C C113C08F >>> D 30010 A1D40424 >>> D 30014 008FD00C >>> D 30018 C1800000 >>> D 3001C 8F320800 >>> D 30020 10A1FE00 >>> D 30024 00C139D0 >>> D 30028 04c1d004 >>> D 3002C 07e15004 >>> D 30030 0000f750 >>> go 30000 >>> go 0 >>> >>> ================ installing from tape >>> >>> $ ./simh/BIN/vax780 3bsd-tboot.ini >>> >>> VAX 11/780 simulator Open SIMH V4.1-0 Current git commit id: >>> 348f5f29 >>> /media/INTERNAL/SCRATCH/3bsd/3bsd-tboot.ini-17> at tu0 3bsd.tap >>> %SIM-INFO: TU0: Tape Image '3bsd.tap' scanned as SIMH format >>> >>> HALT instruction, PC: 00030033 (HALT) >>> =mkfs >>> file sys size: 7942 >>> file system: hp(0,0) >>> isize = 5072 >>> m/n = 3 500 >>> =restor >>> Tape? ht(1,1) >>> Disk? hp(0,0) >>> Last chance before scribbling on disk. >>> End of tape >>> =boot >>> >>> Boot >>> : hp(0,0)vmunix >>> 61856+61008+70120 start 0x4B4 >>> VM/UNIX (Berkeley Version 2.7) 2/10/80 >>> real mem = 8323072 >>> avail mem = 8062976 >>> ERASE IS CONTROL-H!!! >>> # ps ax >>> PID TTY TIME COMMAND >>> 0 ? 0:17 swapper >>> 1 ? 0:00 init.vm >>> 2 ? 0:00 pagedaemon >>> 3 co 0:00 - (sh) >>> 7 co 0:00 ps ax >>> # vmstat >>> Procs Virtual Real Page Swap Disk >>> Cpu >>> RQ DW PW SL SW AVM TX FRE RE PI PO FR DE SR I O D0 D1 D2 CS US >>> NI SY ID >>> 0 0 0 3 0 80 5515518 0 0 0 0 0 0.0 0 0 0 0 0 0 0 >>> 0 0100 >>> # chk /dev/rrp0a >>> icheck /dev/rrp0a >>> /dev/rrp0a: >>> files 154 (r=112,d=12,b=8,c=22) >>> used 1078 (i=28,ii=0,iii=0,d=1050) >>> free 6545 >>> missing 0 >>> dcheck /dev/rrp0a >>> /dev/rrp0a: >>> entries link cnt >>> 1 0 0 >>> # /etc/mkfs /dev/rrp0g 145673 >>> isize = 65488 >>> (or 43147 on RM03) >>> m/n = 3 500 >>> # /etc/mount /dev/rp0g /usr >>> # cd /usr >>> # cp /dev/rmt5 /dev/null >>> # cp /dev/rmt5 /dev/null >>> # tar xvbf 20 /dev/rmt1 >>> x ./adm/msgbuf, 0 bytes, 0 tape blocks >>> .... >>> >>> # dd if=/usr/mdec/uboot of=/dev/rrp0a bs=1b count=1 >>> 1+0 records in >>> 1+0 records out >>> >>> # passwd root >>> ..... >>> # sync >>> # sync >>> # sync >>> # >>> simh> quit >>> >>> ================ 3bsd-dboot.ini >>> >>> ; from https://gunkies.org/wiki/Installing_32V_on_SIMH#dboot.ini >>> ; (just removed attach tu0) >>> set tto 7b >>> set rq dis >>> set lpt dis >>> set rl dis >>> set hk dis >>> set rq dis >>> set rqb dis >>> set rqc dis >>> set rqd dis >>> set ry dis >>> set ts dis >>> set tq dis >>> set dz 7b >>> set dz lines=16 >>> att dz -m 2311 >>> set rp0 rp06 >>> at rp0 rp06.disk >>> set tu0 te16 >>> D 30000 00009FDE >>> D 30004 D0512001 >>> D 30008 D004A101 >>> D 3000C 0400C113 >>> D 30010 10008F32 >>> D 30014 D40424C1 >>> D 30018 8FD00CA1 >>> D 3001C 80000000 >>> D 30020 320800C1 >>> D 30024 A1FE008F >>> D 30028 28C1D410 >>> D 3002C 14C1D404 >>> D 30030 C139D004 >>> D 30034 c1d00400 >>> D 30038 e1500404 >>> D 3003C 00f75007 >>> go 30000 >>> go 2 >>> >>> ================ boot from disk >>> >>> $ ./simh/BIN/vax780 3bsd-dboot.ini >>> >>> VAX 11/780 simulator Open SIMH V4.1-0 Current git commit id: >>> 348f5f29 >>> /media/INTERNAL/SCRATCH/3bsd/3bsd-dboot.ini-15> att dz -m 2311 >>> %SIM-INFO: Listening on port 2311 >>> Modem control activated >>> >>> HALT instruction, PC: 00030040 (HALT) >>> >>> Boot >>> : hp(0,0)vmunix >>> 61856+61008+70120 start 0x4B4 >>> VM/UNIX (Berkeley Version 2.7) 2/10/80 >>> real mem = 8323072 >>> avail mem = 8062976 >>> ERASE IS CONTROL-H!!! >>> # >>> Sat Sep 27 12:51:17 PDT 1980 >>> entering rc >>> clearing mtab >>> mounting /usr on /dev/rp0g >>> preserving Ex temps and clearing /tmp >>> starting update >>> starting cron >>> leaving rc >>> >>> >>> >>> Virtual VAX/UNIX (Ernie Co-vax) >>> >>> login: >>> >>> (was able to log in on console >>> and tty1 via telnet localhost 2311) >>> >>> >>> ================ shutdown from multi-user >>> >>> # kill 1 >>> # ERASE IS CONTROL-H!!! >>> # sync >>> # sync >>> # sync >>> # >>> Simulation stopped, PC: 8000085F (BLBC 80010FA0,8000085F) >>> sim> q >>> Goodbye >>> >> >> >> -- >> End of line >> JOB TERMINATED >> >> >> > > -- > End of line > JOB TERMINATED > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at ultimate.com Thu Aug 31 01:03:32 2023 From: phil at ultimate.com (Phil Budne) Date: Wed, 30 Aug 2023 11:03:32 -0400 Subject: [TUHS] 3bsd tape image In-Reply-To: References: <202308282303.37SN3FVJ034316@ultimate.com> Message-ID: <202308301503.37UF3WhK074681@ultimate.com> KenUnix wrote: > Got a question. With 3BSD I have been unable to find where the time > zone is set. I have looked at date.c, time.h and timebuf.h. In the > meantime I fixed date.c to handle Y2K dates. Same as v7, in /usr/src/sys/h/param.h (kernel rebuild required): #define TIMEZONE (8*60) /* Minutes westward from Greenwich */ #define DSTFLAG 1 /* Daylight Saving Time applies in this locality */ libc has the same limitations as v7: /usr/src/libc/gen/timezone.c timezone function (used by date) knows only a subset of US zone names, plus GMT. /usr/src/libc/gen/ctime.c has hardwired knowledge of DST change dates From arnold at skeeve.com Thu Aug 31 05:21:17 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 30 Aug 2023 13:21:17 -0600 Subject: [TUHS] 3bsd tape image In-Reply-To: References: <202308282303.37SN3FVJ034316@ultimate.com> Message-ID: <202308301921.37UJLHng001920@freefriends.org> Hi Clem, Clem Cole wrote: > The team in CSRG for BSD4.2 developed the time modern timezone database > that we see in most UNIX flavors at this time. IIRC that was developed after 4.3 was released by Arthur David Olsen (elsie!ado), and then incorporated into 4.3 via the patches that CSRG sent out periodically. I'm pretty sure I remember having to recompile libc and the various apps to use it. However, it was a long time ago... Arnold From rich.salz at gmail.com Thu Aug 31 06:07:17 2023 From: rich.salz at gmail.com (Rich Salz) Date: Wed, 30 Aug 2023 16:07:17 -0400 Subject: [TUHS] 3bsd tape image In-Reply-To: <202308301921.37UJLHng001920@freefriends.org> References: <202308282303.37SN3FVJ034316@ultimate.com> <202308301921.37UJLHng001920@freefriends.org> Message-ID: https://sources.vsta.org/comp.sources.unix/volume4/settz March 7 1986 Looking at https://sources.vsta.org/comp.sources.unix/index.txt there are several time/localtime packages that came after that. elsie!ado always had funny .signature lines. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Aug 31 06:06:51 2023 From: clemc at ccc.com (Clem Cole) Date: Wed, 30 Aug 2023 16:06:51 -0400 Subject: [TUHS] 3bsd tape image In-Reply-To: <202308301921.37UJLHng001920@freefriends.org> References: <202308282303.37SN3FVJ034316@ultimate.com> <202308301921.37UJLHng001920@freefriends.org> Message-ID: below... On Wed, Aug 30, 2023 at 3:21 PM wrote: > IIRC that was developed after 4.3 was released by Arthur David Olsen > (elsie!ado), and then incorporated into 4.3 via the patches that CSRG > sent out periodically. > You are probably right .. better memory. I knew it became widespread in a BSD stream, but I did not realize it was donated to CSRG. Thanks. But the key point is that the timezone DB development and inclusion in UNIX systems was much, much later in UNIX time and long after 1984 /usr/group standard, where the use of the TZ variable began to spread to make it easier for end users. As Phil and I pointed out to Ken's original question, the V7-based systems compiled the TZ info (number of minutes west of GMT) into the kernel and supported a couple of primarily USA-based TZs in time(3) and the like. Which makes changing it for the local user a tad more complicated. Then again, you had the sources in those days, and at least the system administrator recompiled the core kernel from scratch. [I remember Joy once saying he thought rebuilding the entire system from the source at each site was a good thing because that way, binaries were not stale]. Anyway, the placing of the TZ string into a program's environment was pushed by the UNIX vendors, of course, because they were not releasing binaries. Thus, by the time of the TZ=xSTdyDT convention, the time(3) family was a bit more flexible [*i.e.,* most of Europe was easily supported] - but you still needed to know what to set it all to. It was only much later, when the timezone DB code was created, that it became easy to set the timezone in a more worldwide scheme. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.unix.guy at gmail.com Thu Aug 31 06:34:58 2023 From: ken.unix.guy at gmail.com (KenUnix) Date: Wed, 30 Aug 2023 16:34:58 -0400 Subject: [TUHS] 3bsd tape image In-Reply-To: References: <202308282303.37SN3FVJ034316@ultimate.com> <202308301921.37UJLHng001920@freefriends.org> Message-ID: Thanks for all the input. Since apparently the tools are not there to rebuild the kernel I hard coded EST into date.c. That is dirty, but it works. Also missing sleep and cut commands so I brought them over from Version8-VAX780 and they work. -Ken On Wed, Aug 30, 2023 at 4:07 PM Rich Salz wrote: > https://sources.vsta.org/comp.sources.unix/volume4/settz March 7 1986 > Looking at https://sources.vsta.org/comp.sources.unix/index.txt there are > several time/localtime packages that came after that. > elsie!ado always had funny .signature lines. > > -- End of line JOB TERMINATED -------------- next part -------------- An HTML attachment was scrubbed... URL: