From dave at horsfall.org Tue Sep 1 07:12:12 2020 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 1 Sep 2020 07:12:12 +1000 (EST) Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> <20200801013605.GG10778@mcvoy.com> <20200813014720.GP21027@mcvoy.com> Message-ID: On Wed, 12 Aug 2020, Grant Taylor via TUHS wrote: >> The SMIT I had did*not* show you what files it was editing > > My recollection is that smit(ty) did /not/ show you the commands that > would be run /by/ /default/. > > That being said, there was a (P)F key you could press prior to > executing, one of the many (P)F keys smit(ty) used, that would show you > the command and all of it's arguments which would be run. It's possible that the system in question was set up by my predecessor; my basic job was to maintain a rather large application on it and the other boxen (financial/sales/factory/etc, all in one); this was many years ago. Never heard of "smitty". -- Dave From dave at horsfall.org Tue Sep 1 07:20:54 2020 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 1 Sep 2020 07:20:54 +1000 (EST) Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> <20200801013605.GG10778@mcvoy.com> Message-ID: On Thu, 13 Aug 2020, John Cowan wrote: > Such number-only error systems are still very common in things like > "smart" washing machines, where the cost and unreliability of a non-tiny > screen simply isn't acceptable. Yeah; I have one. The most common code was "E17" which meant excessive vibration during the spin cycle i.e. load not arranged properly; I could tell anyway by the CLONK CLONK CLONK sound... -- Dave, who does his own laundry From random832 at fastmail.com Wed Sep 2 16:03:28 2020 From: random832 at fastmail.com (Random832) Date: Wed, 02 Sep 2020 02:03:28 -0400 Subject: [TUHS] Unix tools to aid in the production of Internet RFCs? In-Reply-To: References: Message-ID: <9bbab2bc-539b-489e-a3d7-61ef77257bb6@www.fastmail.com> On Thu, Aug 27, 2020, at 13:51, Tony Finch wrote: > Yes, very Not Unix. As Dan wondered, the best list for this question is > internet-history, I think :-) > > The Network Information Center was at SRI, and they used the ARC NLS: Doug > Englebart's Augmentation Research Center oN-Line System [1] but I get the > impression that by the 1990s nroff on Unix was the main tool for producing > RFCs. Was there a particular set of macros used? custom macros? ms? or does raw "nroff" have an easy way to produce those page headers and other things used in RFCs? From fabio at esse.ch Thu Sep 3 01:39:26 2020 From: fabio at esse.ch (Fabio Scotoni) Date: Wed, 2 Sep 2020 17:39:26 +0200 Subject: [TUHS] Unix tools to aid in the production of Internet RFCs? In-Reply-To: <9bbab2bc-539b-489e-a3d7-61ef77257bb6@www.fastmail.com> References: <9bbab2bc-539b-489e-a3d7-61ef77257bb6@www.fastmail.com> Message-ID: On 9/2/20 8:03 AM, Random832 wrote: > On Thu, Aug 27, 2020, at 13:51, Tony Finch wrote: >> Yes, very Not Unix. As Dan wondered, the best list for this question is >> internet-history, I think :-) >> >> The Network Information Center was at SRI, and they used the ARC NLS: Doug >> Englebart's Augmentation Research Center oN-Line System [1] but I get the >> impression that by the 1990s nroff on Unix was the main tool for producing >> RFCs. > > Was there a particular set of macros used? custom macros? ms? or does raw "nroff" have an easy way to produce those page headers and other things used in RFCs? > RFC 2223 ("Instructions to RFC Authors") from October 1997 mentions -ms with a specific setup that is described in the appendix. It noted that "[g]enerally, we use the very simplest nroff features." For completeness: That RFC has later been amended by RFC 5741 ("RFC Streams, Headers, and Boilerplates") and RFC 6949 ("RFC Series Format Requirements and Future Development"). (RFC 7990 from December 2016 then essentially did away with nroff as far as I can tell.) Interestingly, someone named Bruce Lilly made an effort to write a more extensive macro package specifically for the purpose of being used for RFCs, see I-D.draft-lilly-using-troff-04. Unlike the process based around the ms macros cut together with an awk script, his macros actually did the correct pagination on its own. Some of the things on the website linked there are lost by now, such as rfcref, idref and abnff, which were intended to integrate with that macro package. Fabio From rich.salz at gmail.com Thu Sep 3 01:50:11 2020 From: rich.salz at gmail.com (Richard Salz) Date: Wed, 2 Sep 2020 11:50:11 -0400 Subject: [TUHS] Unix tools to aid in the production of Internet RFCs? In-Reply-To: References: <9bbab2bc-539b-489e-a3d7-61ef77257bb6@www.fastmail.com> Message-ID: > Some of the things on the website linked there are lost by now, such as > rfcref, idref and abnff, which were intended to integrate with that > macro package. > Those RFC tools (and others) are still available, updated for the markdown/XML dialect that is used now. -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Thu Sep 3 09:11:41 2020 From: crossd at gmail.com (Dan Cross) Date: Wed, 2 Sep 2020 19:11:41 -0400 Subject: [TUHS] Unix tools to aid in the production of Internet RFCs? In-Reply-To: References: Message-ID: Thanks all, for the very interesting responses to this thread. It sounds like _most_ of the Unix-based preparation efforts centered around an `nroff`-based workflow until the advent of XML. - Dan C. On Wed, Aug 26, 2020 at 5:24 PM Dan Cross wrote: > Honestly, I'm not quite sure if this is a TUHS, COFF, or IH question. But > since my background with respect to such things is largely Unix centric, I > thought I'd ask in that context, hence asking on TUHS. > > I assume some of the regulars on this list have authored RFCs (of the IETF > etc variety). The RFC format seems fairly well fixed: table of contents, > fixed number of lines per page, page numbers and dates in the footer, and > so forth. The format is sufficiently complex that it seems like some > tooling could be usefully employed to aid in producing these documents. > > So I'm curious: what tools did people use to produce those documents? > Perhaps `nroff` with custom macros or something? > > - Dan C. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mparson at bl.org Fri Sep 4 00:10:45 2020 From: mparson at bl.org (Michael Parson) Date: Thu, 03 Sep 2020 09:10:45 -0500 Subject: [TUHS] A/UX [was Linux is on-topic] In-Reply-To: References: <8e7efd45-a84e-cf20-9d30-8222357596a3@tnetconsulting.net> <202007200847.06K8l8DF026646@freefriends.org> <20200720094648.GE15253@ancienthardware.org> <20200801013605.GG10778@mcvoy.com> <20200813014720.GP21027@mcvoy.com> Message-ID: <5888bb8d9bdd59f770412111f19b17da@bl.org> On 2020-08-31 16:12, Dave Horsfall wrote: > On Wed, 12 Aug 2020, Grant Taylor via TUHS wrote: > >>> The SMIT I had did*not* show you what files it was editing >> >> My recollection is that smit(ty) did /not/ show you the commands that >> would be run /by/ /default/. >> >> That being said, there was a (P)F key you could press prior to >> executing, one of the many (P)F keys smit(ty) used, that would show >> you the command and all of it's arguments which would be run. > > It's possible that the system in question was set up by my > predecessor; my basic job was to maintain a rather large application > on it and the other boxen (financial/sales/factory/etc, all in one); > this was many years ago. > > Never heard of "smitty". 'smit' is the X11 GUI, 'smitty' is the text TUI (play on 'smit' + 'tty'). IIRC, if you had $DISPLAY set, 'smit' would present the GUI version, if not, it would automagically call 'smitty' for you. -- Michael Parson Pflugerville, TX KF5LGQ From dave at horsfall.org Fri Sep 4 03:32:58 2020 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 4 Sep 2020 03:32:58 +1000 (EST) Subject: [TUHS] Whence did "XXX" come about? Message-ID: For yonks I've been seeing "XXX" as a flag to mean "needs more work" or "look at this carefully, just in case" etc, and I use it myself. Whence did it come about? I think I saw it as early as PWB, but can't be sure. -- Dave, wondering how many nanny-filters he triggered with "XXX" From imp at bsdimp.com Fri Sep 4 04:11:58 2020 From: imp at bsdimp.com (Warner Losh) Date: Thu, 3 Sep 2020 12:11:58 -0600 Subject: [TUHS] Whence did "XXX" come about? In-Reply-To: References: Message-ID: The earliest my quick grep could find was 4.0BSD. I didn't find it in this sense in pwb, but it was a quick grep... xxx is used extensively in prior versions, but there it's meaning is 'placeholder' or 'don't care'. Mostly for /tmp/XXXX files, but also for things like Jxxx handles all the jump commands or dates of the form 24 Feb XXXX or stuff like that. Warner On Thu, Sep 3, 2020 at 11:34 AM Dave Horsfall wrote: > For yonks I've been seeing "XXX" as a flag to mean "needs more work" or > "look at this carefully, just in case" etc, and I use it myself. > > Whence did it come about? I think I saw it as early as PWB, but can't be > sure. > > -- Dave, wondering how many nanny-filters he triggered with "XXX" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Fri Sep 4 06:28:31 2020 From: wkt at tuhs.org (Warren Toomey) Date: Fri, 4 Sep 2020 06:28:31 +1000 Subject: [TUHS] Whence did "XXX" come about? In-Reply-To: References: Message-ID: <20200903202831.GA10755@minnie.tuhs.org> On Fri, Sep 04, 2020 at 03:32:58AM +1000, Dave Horsfall wrote: > For yonks I've been seeing "XXX" as a flag to mean "needs more work" or > "look at this carefully, just in case" etc, and I use it myself. Me too, for the same reason: the code is tricky or subtle or needs fixing. It does tend to make my students raise their eyebrows; perhaps they have their nanny filters turned on :-) Cheers, Warren From imp at bsdimp.com Fri Sep 4 06:35:22 2020 From: imp at bsdimp.com (Warner Losh) Date: Thu, 3 Sep 2020 14:35:22 -0600 Subject: [TUHS] Whence did "XXX" come about? In-Reply-To: References: Message-ID: I'll also add that this seemed foreign when I had patches that had XXX in them I submitted to the linux folks in the early 90s. It was second nature in the BSD side of things. But I don't know if that's a Berkeley thing or a Bell Labs thing Berkeley picked up... Warner On Thu, Sep 3, 2020 at 12:11 PM Warner Losh wrote: > The earliest my quick grep could find was 4.0BSD. I didn't find it in this > sense in pwb, but it was a quick grep... > > xxx is used extensively in prior versions, but there it's meaning is > 'placeholder' or 'don't care'. Mostly for /tmp/XXXX files, but also for > things like Jxxx handles all the jump commands or dates of the form 24 Feb > XXXX or stuff like that. > > Warner > > On Thu, Sep 3, 2020 at 11:34 AM Dave Horsfall wrote: > >> For yonks I've been seeing "XXX" as a flag to mean "needs more work" or >> "look at this carefully, just in case" etc, and I use it myself. >> >> Whence did it come about? I think I saw it as early as PWB, but can't be >> sure. >> >> -- Dave, wondering how many nanny-filters he triggered with "XXX" >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From halbert at halwitz.org Fri Sep 4 06:54:00 2020 From: halbert at halwitz.org (Dan Halbert) Date: Thu, 3 Sep 2020 16:54:00 -0400 Subject: [TUHS] Whence did "XXX" come about? In-Reply-To: References: Message-ID: <930753f9-7b52-03bb-18e9-e61de3fa94c2@halwitz.org> My guess is that this was invented independently several times. I think I used it myself in the 70's (and not on UNIX), as soon as I had a text editor, because "XXX" was easy to search for and was not going to overlap with variable names, etc. There's a discussion here: https://www.snellman.net/blog/archive/2017-04-17-xxx-fixme Dan H. On 9/3/20 4:35 PM, Warner Losh wrote: > I'll also add that this seemed foreign when I had patches that had XXX > in them I submitted to the linux folks in the early 90s. It was second > nature in the BSD side of things. But I don't know if that's a > Berkeley thing or a Bell Labs thing Berkeley picked up... > > Warner > > On Thu, Sep 3, 2020 at 12:11 PM Warner Losh > wrote: > > The earliest my quick grep could find was 4.0BSD. I didn't find it > in this sense in pwb, but it was a quick grep... > > xxx is used extensively in prior versions, but there it's meaning > is 'placeholder' or 'don't care'. Mostly for /tmp/XXXX files, but > also for things like Jxxx handles all the jump commands or dates > of the form 24 Feb XXXX or stuff like that. > > Warner > > On Thu, Sep 3, 2020 at 11:34 AM Dave Horsfall > wrote: > > For yonks I've been seeing "XXX" as a flag to mean "needs more > work" or > "look at this carefully, just in case" etc, and I use it myself. > > Whence did it come about?  I think I saw it as early as PWB, > but can't be > sure. > > -- Dave, wondering how many nanny-filters he triggered with "XXX" > -------------- next part -------------- An HTML attachment was scrubbed... URL: From usotsuki at buric.co Fri Sep 4 08:13:09 2020 From: usotsuki at buric.co (Steve Nickolas) Date: Thu, 3 Sep 2020 18:13:09 -0400 (EDT) Subject: [TUHS] Whence did "XXX" come about? In-Reply-To: <930753f9-7b52-03bb-18e9-e61de3fa94c2@halwitz.org> References: <930753f9-7b52-03bb-18e9-e61de3fa94c2@halwitz.org> Message-ID: On Thu, 3 Sep 2020, Dan Halbert wrote: > My guess is that this was invented independently several times. I think I > used it myself in the 70's (and not on UNIX), as soon as I had a text editor, > because "XXX" was easy to search for and was not going to overlap with > variable names, etc. I use "EOW" when I'm iterating through something, and stop partway through, for the same reason: I'm not likely to find that exact combination anywhere else. (It's not random: it stands for "End of WIP") I use "XXX" too - usually in the form "XXX FIXME". -uso. From jon at fourwinds.com Fri Sep 4 08:59:21 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Thu, 03 Sep 2020 15:59:21 -0700 Subject: [TUHS] Archeology Today - 516-TSS notebooks unearthed in old Wyse terminal box Message-ID: <202009032259.083MxL712725178@darkstar.fourwinds.com> Score! I'm not planning to scan all of these in unless someone really cares and has a better scanner than I do. I'm going to prioritize the following: 516-10, -11, -18 Ring Formats 516-12 Specifications for the Node Modem Interface 516-22 A Repeater for the Node Modem 516-28 I/O Ring Device Codes 516-36 Node Modem Interface for Computer Terminals 516-72 Node Test 516-73 Node I/O Software 516-57 Format for the 516 Node - TIU Spider Interface 516-67 Node Format for PDP-11 Jon From cbbrowne at gmail.com Fri Sep 4 13:02:24 2020 From: cbbrowne at gmail.com (Christopher Browne) Date: Thu, 3 Sep 2020 23:02:24 -0400 Subject: [TUHS] Whence did "XXX" come about? In-Reply-To: References: <930753f9-7b52-03bb-18e9-e61de3fa94c2@halwitz.org> Message-ID: On Thu., Sep. 3, 2020, 6:14 p.m. Steve Nickolas, wrote: > > I use "XXX" too - usually in the form "XXX FIXME". Timing is everything, especially in humour... I nearly choked on something when I realized this thread was going on as I read notes on the PostgreSQL list where the somewhat famous (?) Tom Lane observed that he was planning to comment a commit to password management code with "XXX FIXME" :-) :-) :-) So this is clearly an idiom still in active use!!! -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Thu Sep 10 09:10:55 2020 From: wkt at tuhs.org (Warren Toomey) Date: Thu, 10 Sep 2020 09:10:55 +1000 Subject: [TUHS] A Paper by dmr in 1984 Message-ID: <20200909231055.GA9678@minnie.tuhs.org> "Reflections on Software Research" https://dl.acm.org/doi/pdf/10.1145/1283920.1283939?download=true Happy birthday, Dennis! Warren From rich.salz at gmail.com Thu Sep 10 10:24:28 2020 From: rich.salz at gmail.com (Richard Salz) Date: Wed, 9 Sep 2020 20:24:28 -0400 Subject: [TUHS] A Paper by dmr in 1984 In-Reply-To: <20200909231055.GA9678@minnie.tuhs.org> References: <20200909231055.GA9678@minnie.tuhs.org> Message-ID: The comparison paper to Thompsons "Reflections on Trusting Trust", https://dl.acm.org/doi/pdf/10.1145/358198.358210 On Wed, Sep 9, 2020 at 7:12 PM Warren Toomey wrote: > "Reflections on Software Research" > https://dl.acm.org/doi/pdf/10.1145/1283920.1283939?download=true > > Happy birthday, Dennis! > Warren > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Thu Sep 10 11:43:57 2020 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 10 Sep 2020 11:43:57 +1000 (EST) Subject: [TUHS] A Paper by dmr in 1984 In-Reply-To: <20200909231055.GA9678@minnie.tuhs.org> References: <20200909231055.GA9678@minnie.tuhs.org> Message-ID: On Thu, 10 Sep 2020, Warren Toomey wrote: > "Reflections on Software Research" > https://dl.acm.org/doi/pdf/10.1145/1283920.1283939?download=true Ooh - I found a typo in it :-) Towards the end: "I guess the tree of research must from time to time by [sic] refreshed with the blood of bean counters." (And yes, I'm familiar with the reference) -- Dave From robert at timetraveller.org Thu Sep 10 14:16:02 2020 From: robert at timetraveller.org (Robert Brockway) Date: Thu, 10 Sep 2020 14:16:02 +1000 (AEST) Subject: [TUHS] UNESCO call for a study on the future institutional structure for Software Heritage (fwd) Message-ID: FYI. UNESCO call for a study on the future institutional structure for Software Heritage. ---------- Forwarded message ---------- Dear all, I do hope you are all safe, and could take some time off to recharge the batteries that these hectic times have drained quite a bit. Some of you know already Software Heritage (https://www.softwareheritage.org): it is a nonprofit initiative, started by Inria and supported by UNESCO, whose mission is to ensure that software source code, as part of the common heritage of humankind, is preserved over time and made available to all, building, maintaining and developing a universal source code archive, providing persistent identifiers for all software artifacts, and creating the largest shared knowledge base about software artifacts ever built. This is a long term undertaking, and UNESCO has just published a call for advice, via a small feasibility study providing options for establishing the future independent, non profit, multi-stakeholder organization that will host Software Heritage for the long run. As Software Heritage is a shared infrastructure that will support use cases of interest to the members of this list, I take the liberty to bring this call to your attention, and I'd be very grateful if you could also forward it to whomever you believe could be interested in answering. Detailed information on the expected advice and procedures to answer the call is online at: https://careers.unesco.org/job/Paris-Consultant-on-Software-Heritage-CIMID/519826502/ The deadline for the answer is September 26th. Thank you for your help Roberto Di Cosmo (roberto at dicosmo.org) _______________________________________________ foundations mailing list foundations at lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/foundations From arnold at skeeve.com Thu Sep 10 16:18:22 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 10 Sep 2020 00:18:22 -0600 Subject: [TUHS] A Paper by dmr in 1984 In-Reply-To: References: <20200909231055.GA9678@minnie.tuhs.org> Message-ID: <202009100618.08A6IMOd003264@freefriends.org> Um, "companion paper" maybe? :-) Richard Salz wrote: > The comparison paper to Thompsons "Reflections on Trusting Trust", > https://dl.acm.org/doi/pdf/10.1145/358198.358210 > > On Wed, Sep 9, 2020 at 7:12 PM Warren Toomey wrote: > > > "Reflections on Software Research" > > https://dl.acm.org/doi/pdf/10.1145/1283920.1283939?download=true > > > > Happy birthday, Dennis! > > Warren > > From edouardklein at gmail.com Thu Sep 10 19:33:38 2020 From: edouardklein at gmail.com (Edouard Klein) Date: Thu, 10 Sep 2020 11:33:38 +0200 Subject: [TUHS] UNESCO call for a study on the future institutional structure for Software Heritage (fwd) In-Reply-To: References: Message-ID: <87k0x2ugb2.fsf@gmail.com> Adding a bit of context, Software Heritage is used for example by GNU Guix, which aims at making builds reproducible down to the exact bit. Every piece of public source code used by Guix in a build will get automatically archived by software heritage. https://www.softwareheritage.org/2019/04/18/software-heritage-and-gnu-guix-join-forces-to-enable-long-term-reproducibility/ Given the time spent by people here trying to get things to build again, I expect the ability of Guix to freeze and archive all dependencies and build instructions to be of interest here: https://guix.gnu.org/manual/en/html_node/Channels.html#Replicating-Guix Cheers, Edouard. Robert Brockway writes: > FYI. UNESCO call for a study on the future institutional structure for Software > Heritage. > > ---------- Forwarded message ---------- > Dear all, > I do hope you are all safe, and could take some time off to recharge the > batteries that these hectic times have drained quite a bit. > > Some of you know already Software Heritage (https://www.softwareheritage.org): > it is a nonprofit initiative, started by Inria and supported by UNESCO, whose > mission is to ensure that software source code, as part of the common heritage > of humankind, is preserved over time and made available to all, building, > maintaining and developing a universal source code archive, providing persistent > identifiers for all software artifacts, and creating the largest shared > knowledge base about software artifacts ever built. > > This is a long term undertaking, and UNESCO has just published a call for > advice, via a small feasibility study providing options for establishing the > future independent, non profit, multi-stakeholder organization that will host > Software Heritage for the long run. > > As Software Heritage is a shared infrastructure that will support use cases of > interest to the members of this list, I take the liberty to bring this call to > your attention, and I'd be very grateful if you could also forward it to > whomever you believe could be interested in answering. > > Detailed information on the expected advice and procedures to answer the call is > online at: > https://careers.unesco.org/job/Paris-Consultant-on-Software-Heritage-CIMID/519826502/ > > The deadline for the answer is September 26th. > > Thank you for your help > > Roberto Di Cosmo (roberto at dicosmo.org) > _______________________________________________ > foundations mailing list > foundations at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/foundations From beebe at math.utah.edu Fri Sep 11 00:13:30 2020 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Thu, 10 Sep 2020 08:13:30 -0600 Subject: [TUHS] A Paper by dmr in 1984 Message-ID: Dennis Ritchie's ACM Turing Award lecture paper in Communications of the ACM 27(8) 758--760 (August 1984), doi:10.1145/358198.358207 was reprinted in UNIX Review 3(1) 28, 118--120, 122, (January 1985) [no DOI or URL yet found], and more recently, in Resonance 17(8) 810--816 (August 2012) doi:10.1007/s12045-012-0091-y. There are two other UNIX-related papers in that issue of Resonance: Pramod Chandra P. Bhatt UNIX: Genesis and design features Resonance 17(8) 727--747 (August 2012) doi:10.1007/s12045-012-0084-x K. Bhaskar C --- Past, present, and future --- A perspective Resonance 17(8) 748--758 (August 2012) doi:10.1007/s12045-012-0085-9 I do not have access to that journal's archives from my campus library, so I have not seen the articles. In his paper, Dennis Ritchie referred to another UNIX article that I did manage to track down and record in unix.bib: Donald Arthur Norman The Truth about UNIX Datamation 27(12) 139--150 (November 1981) https://tinyurl.com/yyselmxq The original URL is 200+ characters long, and is a freely-downloadable PDF of a reprint in AUUGN volume IV number I. The PDF file has searchable text. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From clemc at ccc.com Fri Sep 11 02:02:47 2020 From: clemc at ccc.com (Clem Cole) Date: Thu, 10 Sep 2020 12:02:47 -0400 Subject: [TUHS] A Paper by dmr in 1984 In-Reply-To: References: Message-ID: First Warren - thanks for the refresh. Both Dennis and Ken's Turing lectures should be required (re)reading to remind us all on some of the important lessons and gifts the system gave us, besides the technologies themselves. On Thu, Sep 10, 2020 at 10:30 AM Nelson H. F. Beebe wrote: > > In his paper, Dennis Ritchie referred to another UNIX article that I > did manage to track down and record in unix.bib: > Thanks. I remember that paper and the argument at the time (also a fun re-read). I remember that from those days and I do admit that when I too first encountered UNIX in the early/mid 70s, like Prof. Norman describes, UNIX did seem a little 'different' from my then comfort zones of the PDP-8 and PDP-10 worlds, much less the IBM/360 and TSS. In my first encounters, I certainly felt some of the things Prof. Norman and others in those days would describe. But what I find fascinating about this paper is that the complaints about UNIX described there by Norman and by others at the time also, now are used to describe Linux - that is, the observations (complaints) are unchanged in 50 years. So I realize that you either "get it" or you don't. You can be educated and overcome bias by keeping an open mind if you come from some other system (somewhere else), or you don't find it strange if you are new to computers - i.e. accept it as is [like Lesk describes in the side bar]. Put another way, as I used to say in those days to people that were seeing UNIX for the first time, the learning curve was different and could be longer >>if<< you come in with *expectations from some other system*. But if you had never seen or used a computer before it was not that difficult. What is 'normal' behavior for you -- such as the case-folding or C:mumble in filename conventions? I think that Norman's complaint is really the 'baby duck' syndrome at its highest level (vi vs emacs, LISP vs anything else, *etc*.). Once a person working with a new system learns to use and *appreciate a feature* (like typing only a few characters for as 'ls' instead of dir, having to have case independence, or not having to device the storage device in a filename) UNIX or the like is not so strange, becomes comfortable, if not desirable. In fact, just yesterday, I was trying to reconfigure a used Cisco switch I had picked up to use at home. I would have loved to have been able to type: 'dir' much less, 'ls' instead of: show file information flash:? which I suspect some IT person that uses Cisco gear does not find strange. I also think Dennis's comments about Xerox's GUIs are interesting BTW. The BLiT that Rob, Bart, and friends were working, was just making the scene around the time of this paper and certainly, GUI's were becoming all the range and would make their mark as Dennis suggests. But, I also think it's interesting that 36 years after his paper GUIs did not wholesale replace CLI's. Not because people are stubborn, as much as people discovered what each gives you (and thus I use both -- I run the Apple GUI for simple things, but there are always 3-5 'iterm2' windows open with a (shutter) C-Shell prompt in each [the later cause the ROMs in my fingers are burned to the old UNIX maxim: *'Bourne to Program, but Type with Joy.'* Anyway, thank you both for a refreshing reread and reminder during these bizarre times that some things in our world remain constant. People like what they like, and as Paul Simon reminded us years ago: "*One man's ceiling, is another man's floor.*" Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From edouardklein at gmail.com Fri Sep 11 02:04:34 2020 From: edouardklein at gmail.com (Edouard Klein) Date: Thu, 10 Sep 2020 18:04:34 +0200 Subject: [TUHS] A Paper by dmr in 1984 In-Reply-To: References: Message-ID: <87zh5xty7h.fsf@gmail.com> PDFS: https://sci-hub.tw/10.1007/s12045-012-0084-x https://sci-hub.tw/10.1007/s12045-012-0085-9 Paywalls where the money goes to people who did nothing of significance to advance the published works are the bane of scientific research. Sci hub is a useful crutch until we fix this mess. If you want to follow the letter of the law, don't follow these links. Cheers, Edouard. Nelson H. F. Beebe writes: > Dennis Ritchie's ACM Turing Award lecture paper in Communications of > the ACM 27(8) 758--760 (August 1984), doi:10.1145/358198.358207 was > reprinted in UNIX Review 3(1) 28, 118--120, 122, (January 1985) [no > DOI or URL yet found], and more recently, in Resonance 17(8) 810--816 > (August 2012) doi:10.1007/s12045-012-0091-y. > > There are two other UNIX-related papers in that issue of Resonance: > > Pramod Chandra P. Bhatt > UNIX: Genesis and design features > Resonance 17(8) 727--747 (August 2012) > doi:10.1007/s12045-012-0084-x > > K. Bhaskar > C --- Past, present, and future --- A perspective > Resonance 17(8) 748--758 (August 2012) > doi:10.1007/s12045-012-0085-9 > > I do not have access to that journal's archives from my campus > library, so I have not seen the articles. > > In his paper, Dennis Ritchie referred to another UNIX article that I > did manage to track down and record in unix.bib: > > Donald Arthur Norman > The Truth about UNIX > Datamation 27(12) 139--150 (November 1981) > https://tinyurl.com/yyselmxq > > The original URL is 200+ characters long, and is a freely-downloadable > PDF of a reprint in AUUGN volume IV number I. The PDF file has > searchable text. > > ------------------------------------------------------------------------------- > - Nelson H. F. Beebe Tel: +1 801 581 5254 - > - University of Utah FAX: +1 801 581 4148 - > - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - > - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - > - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - > ------------------------------------------------------------------------------- From lm at mcvoy.com Fri Sep 11 02:45:25 2020 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 10 Sep 2020 09:45:25 -0700 Subject: [TUHS] A Paper by dmr in 1984 In-Reply-To: <87zh5xty7h.fsf@gmail.com> References: <87zh5xty7h.fsf@gmail.com> Message-ID: <20200910164525.GR19682@mcvoy.com> I hate the paywalls as well. Personally, if I've written something and someone wants it, I just give it to them. Most decent authors I've encountered do the same. On Thu, Sep 10, 2020 at 06:04:34PM +0200, Edouard Klein wrote: > PDFS: > https://sci-hub.tw/10.1007/s12045-012-0084-x > https://sci-hub.tw/10.1007/s12045-012-0085-9 > > Paywalls where the money goes to people who did nothing of significance to > advance the published works are the bane of scientific research. Sci hub > is a useful crutch until we fix this mess. If you want to follow the > letter of the law, don't follow these links. > > Cheers, > > Edouard. > > Nelson H. F. Beebe writes: > > > Dennis Ritchie's ACM Turing Award lecture paper in Communications of > > the ACM 27(8) 758--760 (August 1984), doi:10.1145/358198.358207 was > > reprinted in UNIX Review 3(1) 28, 118--120, 122, (January 1985) [no > > DOI or URL yet found], and more recently, in Resonance 17(8) 810--816 > > (August 2012) doi:10.1007/s12045-012-0091-y. > > > > There are two other UNIX-related papers in that issue of Resonance: > > > > Pramod Chandra P. Bhatt > > UNIX: Genesis and design features > > Resonance 17(8) 727--747 (August 2012) > > doi:10.1007/s12045-012-0084-x > > > > K. Bhaskar > > C --- Past, present, and future --- A perspective > > Resonance 17(8) 748--758 (August 2012) > > doi:10.1007/s12045-012-0085-9 > > > > I do not have access to that journal's archives from my campus > > library, so I have not seen the articles. > > > > In his paper, Dennis Ritchie referred to another UNIX article that I > > did manage to track down and record in unix.bib: > > > > Donald Arthur Norman > > The Truth about UNIX > > Datamation 27(12) 139--150 (November 1981) > > https://tinyurl.com/yyselmxq > > > > The original URL is 200+ characters long, and is a freely-downloadable > > PDF of a reprint in AUUGN volume IV number I. The PDF file has > > searchable text. > > > > ------------------------------------------------------------------------------- > > - Nelson H. F. Beebe Tel: +1 801 581 5254 - > > - University of Utah FAX: +1 801 581 4148 - > > - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - > > - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - > > - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - > > ------------------------------------------------------------------------------- -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From clemc at ccc.com Fri Sep 11 06:27:32 2020 From: clemc at ccc.com (Clem Cole) Date: Thu, 10 Sep 2020 16:27:32 -0400 Subject: [TUHS] A Paper by dmr in 1984 In-Reply-To: <20200910164525.GR19682@mcvoy.com> References: <87zh5xty7h.fsf@gmail.com> <20200910164525.GR19682@mcvoy.com> Message-ID: One of the things I am most proud of as a Board Member and USENIX President was going free access during my time. It was bold and scary, but the right thing to do. Too bad, IEEE and ACM don't have the same values. A paywall is an invisible revenue stream and makes it easy for them to 'provide value,' *but they do it one other people's work*. Back when publishing was a more expensive thing for them to do, it made *some* sense. But it should have been a zero-sum/at-cost game. When it became the primary revenue stream for those organizations, is when they fell from grace. On Thu, Sep 10, 2020 at 12:46 PM Larry McVoy wrote: > I hate the paywalls as well. Personally, if I've written something and > someone wants it, I just give it to them. Most decent authors I've > encountered do the same. > > On Thu, Sep 10, 2020 at 06:04:34PM +0200, Edouard Klein wrote: > > PDFS: > > https://sci-hub.tw/10.1007/s12045-012-0084-x > > https://sci-hub.tw/10.1007/s12045-012-0085-9 > > > > Paywalls where the money goes to people who did nothing of significance > to > > advance the published works are the bane of scientific research. Sci hub > > is a useful crutch until we fix this mess. If you want to follow the > > letter of the law, don't follow these links. > > > > Cheers, > > > > Edouard. > > > > Nelson H. F. Beebe writes: > > > > > Dennis Ritchie's ACM Turing Award lecture paper in Communications of > > > the ACM 27(8) 758--760 (August 1984), doi:10.1145/358198.358207 was > > > reprinted in UNIX Review 3(1) 28, 118--120, 122, (January 1985) [no > > > DOI or URL yet found], and more recently, in Resonance 17(8) 810--816 > > > (August 2012) doi:10.1007/s12045-012-0091-y. > > > > > > There are two other UNIX-related papers in that issue of Resonance: > > > > > > Pramod Chandra P. Bhatt > > > UNIX: Genesis and design features > > > Resonance 17(8) 727--747 (August 2012) > > > doi:10.1007/s12045-012-0084-x > > > > > > K. Bhaskar > > > C --- Past, present, and future --- A perspective > > > Resonance 17(8) 748--758 (August 2012) > > > doi:10.1007/s12045-012-0085-9 > > > > > > I do not have access to that journal's archives from my campus > > > library, so I have not seen the articles. > > > > > > In his paper, Dennis Ritchie referred to another UNIX article that I > > > did manage to track down and record in unix.bib: > > > > > > Donald Arthur Norman > > > The Truth about UNIX > > > Datamation 27(12) 139--150 (November 1981) > > > https://tinyurl.com/yyselmxq > > > > > > The original URL is 200+ characters long, and is a freely-downloadable > > > PDF of a reprint in AUUGN volume IV number I. The PDF file has > > > searchable text. > > > > > > > ------------------------------------------------------------------------------- > > > - Nelson H. F. Beebe Tel: +1 801 581 5254 > - > > > - University of Utah FAX: +1 801 581 4148 > - > > > - Department of Mathematics, 110 LCB Internet e-mail: > beebe at math.utah.edu - > > > - 155 S 1400 E RM 233 beebe at acm.org > beebe at computer.org - > > > - Salt Lake City, UT 84112-0090, USA URL: > http://www.math.utah.edu/~beebe/ - > > > > ------------------------------------------------------------------------------- > > -- > --- > Larry McVoy lm at mcvoy.com > http://www.mcvoy.com/lm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Fri Sep 11 06:35:30 2020 From: jon at fourwinds.com (Jon Steinhart) Date: Thu, 10 Sep 2020 13:35:30 -0700 Subject: [TUHS] A Paper by dmr in 1984 In-Reply-To: References: <87zh5xty7h.fsf@gmail.com> <20200910164525.GR19682@mcvoy.com> Message-ID: <202009102035.08AKZUKh580678@darkstar.fourwinds.com> Clem Cole writes: > > One of the things I am most proud of as a Board Member and USENIX President > was going free access during my time. It was bold and scary, but the right > thing to do. Too bad, IEEE and ACM don't have the same values. A > paywall is an invisible revenue stream and makes it easy for them to > 'provide value,' *but they do it one other people's work*. Back when > publishing was a more expensive thing for them to do, it made *some* > sense. But it should have been a zero-sum/at-cost game. When it became > the primary revenue stream for those organizations, is when they fell from > grace. I completely agree; I asked both ACM and IEEE if I could at least have access to their libraries for stuff that I had already paid for and had on paper but they said no so I dropped my memberships. Along those lines and in the archeology department, I have boxes of ACM and IEEE pubs from the maybe 1982-2010 timeframe that are about to get recycled so if anybody wants 'em, let me know. Jon From thomas.paulsen at firemail.de Fri Sep 11 19:40:42 2020 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Fri, 11 Sep 2020 11:40:42 +0200 Subject: [TUHS] A Paper by dmr in 1984 In-Reply-To: <87zh5xty7h.fsf@gmail.com> References: <87zh5xty7h.fsf@gmail.com> Message-ID: <5eb91eb53245047adf871b626d643ec5@firemail.de> Sorry: Server not found Waterfox can’t find the server at sci-hub.tw. --- Ursprüngliche Nachricht --- PDFS: https://sci-hub.tw/10.1007/s12045-012-0084-x https://sci-hub.tw/10.1007/s12045-012-0085-9 Paywalls where the money goes to people who did nothing of significance to advance the published works are the bane of scientific research. Sci hub is a useful crutch until we fix this mess. If you want to follow the letter of the law, don't follow these links. Cheers, Edouard. Nelson H. F. Beebe writes: > Dennis Ritchie's ACM Turing Award lecture paper in Communications of > the ACM 27(8) 758--760 (August 1984), doi:10.1145/358198.358207 was > reprinted in UNIX Review 3(1) 28, 118--120, 122, (January 1985) [no > DOI or URL yet found], and more recently, in Resonance 17(8) 810--816 > (August 2012) doi:10.1007/s12045-012-0091-y. > > There are two other UNIX-related papers in that issue of Resonance: > > Pramod Chandra P. Bhatt > UNIX: Genesis and design features > Resonance 17(8) 727--747 (August 2012) > doi:10.1007/s12045-012-0084-x > > K. Bhaskar > C --- Past, present, and future --- A perspective > Resonance 17(8) 748--758 (August 2012) > doi:10.1007/s12045-012-0085-9 > > I do not have access to that journal's archives from my campus > library, so I have not seen the articles. > > In his paper, Dennis Ritchie referred to another UNIX article that I > did manage to track down and record in unix.bib: > > Donald Arthur Norman > The Truth about UNIX > Datamation 27(12) 139--150 (November 1981) > https://tinyurl.com/yyselmxq > > The original URL is 200+ characters long, and is a freely-downloadable > PDF of a reprint in AUUGN volume IV number I. The PDF file has > searchable text. > > ------------------------------------------------------------------------------- > - Nelson H. F. Beebe Tel: +1 801 581 5254 - > - University of Utah FAX: +1 801 581 4148 - > - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - > - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - > - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - > ------------------------------------------------------------------------------- From edouardklein at gmail.com Fri Sep 11 20:52:21 2020 From: edouardklein at gmail.com (Edouard Klein) Date: Fri, 11 Sep 2020 12:52:21 +0200 Subject: [TUHS] A Paper by dmr in 1984 In-Reply-To: <5eb91eb53245047adf871b626d643ec5@firemail.de> References: <87zh5xty7h.fsf@gmail.com> <5eb91eb53245047adf871b626d643ec5@firemail.de> Message-ID: <87tuw4twka.fsf@gmail.com> sci-hub is often blocked by ISPs. To go around DNS blocking just: echo nameserver 1.1.1.1 > /etc/resolv.conf # Make a backup first if they block by IP, use a VPN or the TOR browser (https://www.torproject.org/download/) Firefox' dns over https may often work as well. Cheers, Edouard. Thomas Paulsen writes: > Sorry: Server not found > > Waterfox can’t find the server at sci-hub.tw. > > > --- Ursprüngliche Nachricht --- > > PDFS: > https://sci-hub.tw/10.1007/s12045-012-0084-x > https://sci-hub.tw/10.1007/s12045-012-0085-9 > > Paywalls where the money goes to people who did nothing of significance to > > advance the published works are the bane of scientific research. Sci hub > > is a useful crutch until we fix this mess. If you want to follow the > letter of the law, don't follow these links. > > Cheers, > > Edouard. > > Nelson H. F. Beebe writes: > >> Dennis Ritchie's ACM Turing Award lecture paper in Communications of > >> the ACM 27(8) 758--760 (August 1984), doi:10.1145/358198.358207 was > >> reprinted in UNIX Review 3(1) 28, 118--120, 122, (January 1985) [no > >> DOI or URL yet found], and more recently, in Resonance 17(8) 810--816 > >> (August 2012) doi:10.1007/s12045-012-0091-y. >> >> There are two other UNIX-related papers in that issue of Resonance: > >> >> Pramod Chandra P. Bhatt >> UNIX: Genesis and design features >> Resonance 17(8) 727--747 (August 2012) >> doi:10.1007/s12045-012-0084-x >> >> K. Bhaskar >> C --- Past, present, and future --- A perspective >> Resonance 17(8) 748--758 (August 2012) >> doi:10.1007/s12045-012-0085-9 >> >> I do not have access to that journal's archives from my campus >> library, so I have not seen the articles. >> >> In his paper, Dennis Ritchie referred to another UNIX article that I > >> did manage to track down and record in unix.bib: >> >> Donald Arthur Norman >> The Truth about UNIX >> Datamation 27(12) 139--150 (November 1981) >> https://tinyurl.com/yyselmxq >> >> The original URL is 200+ characters long, and is a freely-downloadable > >> PDF of a reprint in AUUGN volume IV number I. The PDF file has >> searchable text. >> >> ------------------------------------------------------------------------------- > >> - Nelson H. F. Beebe Tel: +1 801 581 5254 > - >> - University of Utah FAX: +1 801 581 4148 > - >> - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu > - >> - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org > - >> - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ > - >> ------------------------------------------------------------------------------- From cowan at ccil.org Sat Sep 12 04:52:20 2020 From: cowan at ccil.org (John Cowan) Date: Fri, 11 Sep 2020 14:52:20 -0400 Subject: [TUHS] A Paper by dmr in 1984 In-Reply-To: <5eb91eb53245047adf871b626d643ec5@firemail.de> References: <87zh5xty7h.fsf@gmail.com> <5eb91eb53245047adf871b626d643ec5@firemail.de> Message-ID: gives the latest domain names (failing that, google for [sci-hub latest domain] or such. Currently .go, .st, .tw, .se, .si are working for me. Try them and see. Information wants to be free, but _rentiers_ want to be paid for nothing. On Fri, Sep 11, 2020 at 6:11 AM Thomas Paulsen wrote: > Sorry: Server not found > > Waterfox can’t find the server at sci-hub.tw. > > > --- Ursprüngliche Nachricht --- > > PDFS: > https://sci-hub.tw/10.1007/s12045-012-0084-x > https://sci-hub.tw/10.1007/s12045-012-0085-9 > > Paywalls where the money goes to people who did nothing of significance to > > advance the published works are the bane of scientific research. Sci hub > > is a useful crutch until we fix this mess. If you want to follow the > letter of the law, don't follow these links. > > Cheers, > > Edouard. > > Nelson H. F. Beebe writes: > > > Dennis Ritchie's ACM Turing Award lecture paper in Communications of > > > the ACM 27(8) 758--760 (August 1984), doi:10.1145/358198.358207 was > > > reprinted in UNIX Review 3(1) 28, 118--120, 122, (January 1985) [no > > > DOI or URL yet found], and more recently, in Resonance 17(8) 810--816 > > > (August 2012) doi:10.1007/s12045-012-0091-y. > > > > There are two other UNIX-related papers in that issue of Resonance: > > > > > Pramod Chandra P. Bhatt > > UNIX: Genesis and design features > > Resonance 17(8) 727--747 (August 2012) > > doi:10.1007/s12045-012-0084-x > > > > K. Bhaskar > > C --- Past, present, and future --- A perspective > > Resonance 17(8) 748--758 (August 2012) > > doi:10.1007/s12045-012-0085-9 > > > > I do not have access to that journal's archives from my campus > > library, so I have not seen the articles. > > > > In his paper, Dennis Ritchie referred to another UNIX article that I > > > did manage to track down and record in unix.bib: > > > > Donald Arthur Norman > > The Truth about UNIX > > Datamation 27(12) 139--150 (November 1981) > > https://tinyurl.com/yyselmxq > > > > The original URL is 200+ characters long, and is a freely-downloadable > > > PDF of a reprint in AUUGN volume IV number I. The PDF file has > > searchable text. > > > > > ------------------------------------------------------------------------------- > > > - Nelson H. F. Beebe Tel: +1 801 581 5254 > - > > - University of Utah FAX: +1 801 581 4148 > - > > - Department of Mathematics, 110 LCB Internet e-mail: > beebe at math.utah.edu > - > > - 155 S 1400 E RM 233 beebe at acm.org > beebe at computer.org > - > > - Salt Lake City, UT 84112-0090, USA URL: > http://www.math.utah.edu/~beebe/ > - > > > ------------------------------------------------------------------------------- > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.paulsen at firemail.de Sat Sep 12 21:29:41 2020 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Sat, 12 Sep 2020 13:29:41 +0200 Subject: [TUHS] A Paper by dmr in 1984 In-Reply-To: <87tuw4twka.fsf@gmail.com> References: <87zh5xty7h.fsf@gmail.com> <5eb91eb53245047adf871b626d643ec5@firemail.de> <87tuw4twka.fsf@gmail.com> Message-ID: <7f7ab2dfc3d6f973d2a6cda1c21fad20@firemail.de> >sci-hub is often blocked by ISPs. To go around DNS blocking just: >echo nameserver 1.1.1.1 > /etc/resolv.conf # Make a backup first >if they block by IP, use a VPN or the TOR browser >(https://www.torproject.org/download/) >Firefox' dns over https may often work as well. that's it. Just checked out my tor browser and it works out-of-the-box. Thanks a lot Edouard! Thomas Paulsen writes: > Sorry: Server not found > > Waterfox can’t find the server at sci-hub.tw. > > > --- Ursprüngliche Nachricht --- > > PDFS: > https://sci-hub.tw/10.1007/s12045-012-0084-x > https://sci-hub.tw/10.1007/s12045-012-0085-9 > > Paywalls where the money goes to people who did nothing of significance to > > advance the published works are the bane of scientific research. Sci hub > > is a useful crutch until we fix this mess. If you want to follow the > letter of the law, don't follow these links. > > Cheers, > > Edouard. > > Nelson H. F. Beebe writes: > >> Dennis Ritchie's ACM Turing Award lecture paper in Communications of > >> the ACM 27(8) 758--760 (August 1984), doi:10.1145/358198.358207 was > >> reprinted in UNIX Review 3(1) 28, 118--120, 122, (January 1985) [no > >> DOI or URL yet found], and more recently, in Resonance 17(8) 810--816 > >> (August 2012) doi:10.1007/s12045-012-0091-y. >> >> There are two other UNIX-related papers in that issue of Resonance: > >> >> Pramod Chandra P. Bhatt >> UNIX: Genesis and design features >> Resonance 17(8) 727--747 (August 2012) >> doi:10.1007/s12045-012-0084-x >> >> K. Bhaskar >> C --- Past, present, and future --- A perspective >> Resonance 17(8) 748--758 (August 2012) >> doi:10.1007/s12045-012-0085-9 >> >> I do not have access to that journal's archives from my campus >> library, so I have not seen the articles. >> >> In his paper, Dennis Ritchie referred to another UNIX article that I > >> did manage to track down and record in unix.bib: >> >> Donald Arthur Norman >> The Truth about UNIX >> Datamation 27(12) 139--150 (November 1981) >> https://tinyurl.com/yyselmxq >> >> The original URL is 200+ characters long, and is a freely-downloadable > >> PDF of a reprint in AUUGN volume IV number I. The PDF file has >> searchable text. >> >> ------------------------------------------------------------------------------- > >> - Nelson H. F. Beebe Tel: +1 801 581 5254 > - >> - University of Utah FAX: +1 801 581 4148 > - >> - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu > - >> - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org > - >> - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ > - >> ------------------------------------------------------------------------------- From ni at w21.org Mon Sep 14 01:44:57 2020 From: ni at w21.org (Juergen Nickelsen) Date: Sun, 13 Sep 2020 17:44:57 +0200 Subject: [TUHS] The most surprising Unix programs References: <20200320140308.4FBBB18C073@mercury.lcs.mit.edu> Message-ID: <87tuw1n0jq.fsf@lith.ni.w21.org> Grant Taylor via TUHS writes: > For example, let's start with Pythagorean Theorem > > a² + b² = c² [...] > [a] [enter] > [a] [enter] > [multiply] > [b] [enter] > [b] [enter] > [multiply] > [add] > [square root] # to solve for c I do [a] [square] [b] [square] [plus] [square root] 6 keys. (Many operations push the entered value into the x register without needing the enter key. Also, like with infix calculators, usually there is a [x^2] key -- in postfix notation on both!) > [a] > [square] > [plus] > [b] > [square] > [square root] That would give you the value of [b] and leave some rest of the operation in the (hidden) registers. Actually you need [a] [square] [plus] [b] [square] [=] [square root] 7 keys. Although I started with infix calculators, I find it easier to work my way out of more complex nested formulas with RPN than to track the level of parentheses in my mind. Consider something like this: 3y * x / (z + 4k)^2 2w + v! \ ------ * | ---------- + ---------- | 5b + z \ 3b * 4x ln(x + 2y) / Now this is a PITA either way, but it comes easier for me with RPN. [Sorry for the late reply -- I subscribed to TUHS earlier this year and am only now making my way through it.] -- Kein Wunder, wenn bei Leuten, die tagaus, tagein Zugriff auf alles haben, was die Welt im Internet anbietet, die Fantasie-Sicherungen durchbrennen. -- Karl Notter From paul.winalski at gmail.com Mon Sep 14 03:42:19 2020 From: paul.winalski at gmail.com (Paul Winalski) Date: Sun, 13 Sep 2020 13:42:19 -0400 Subject: [TUHS] UNESCO call for a study on the future institutional structure for Software Heritage (fwd) In-Reply-To: <87k0x2ugb2.fsf@gmail.com> References: <87k0x2ugb2.fsf@gmail.com> Message-ID: On 9/10/20, Edouard Klein wrote: > Adding a bit of context, Software Heritage is used for example by GNU > Guix, which aims at making builds reproducible down to the exact bit. > To get complete build reproducibility, your compiler writers have to be careful. It's very easy to introduce random variability that doesn't affect the performance or semantics of the program. Register choice and instruction ordering, for example. Here's a real-world example of how such things can happen. Compilers have lots of data structures (temporary variables, for example) that require unique identifiers, but the value of the identifier is irrelevant--it simply has to be unique. It's tempting to use the memory address of the data structure as the unique ID--it saves both space and time. But suppose that your register allocator has to index those items in a hash table, and also at some point sequentially walks the hash table. The order of the sequential walk is now dependent on the memory addresses of the items in the table. In the case I observed, this resulted in different register choices if the program was recompiled. -Paul W. From gnu at toad.com Mon Sep 14 10:33:43 2020 From: gnu at toad.com (John Gilmore) Date: Sun, 13 Sep 2020 17:33:43 -0700 Subject: [TUHS] UNESCO call for a study on the future institutional structure for Software Heritage (fwd) In-Reply-To: References: <87k0x2ugb2.fsf@gmail.com> Message-ID: <6695.1600043623@hop.toad.com> Paul Winalski wrote: > To get complete build reproducibility, your compiler writers have to > be careful. It's very easy to introduce random variability that > doesn't affect the performance or semantics of the program. The GNU compilers are already tested for complete reproducibility. We at Cygnus Support built that infrastructure back in the 1990s, when we made gcc into a cross-compiler (compiling on any architecture + OS, targeting any other). We built the Deja Gnu test harness, and some compiler/assembler/linker test suites, that rebuilt not just our own tools, but also a test suite with hundreds or thousands of programs. We compared their binaries until they were bit-for-bit identical when built on many different host machines of different architectures. To make it work, we had to fix many bugs and misfeatures, including even some high-level design bugs, like object file formats that demanded a timestamp (we decided that 0 was a fine timestamp). A few of those bugs involved generating different but working instruction sequences -- I recall fixing one that depended on an uninitialized local variable. I have not been involved in the release process for gcc or other GNU tools for many years, but I believe that these tests are still in use -- because the maintainers care. If *your* compiler isn't reproducible, why not switch to a free software one that is? The Reproducible Builds effort is standing on the shoulders of many others who came before, and who value deterministic computer behavior and access to the matching source code of the binaries that users depend upon. John Gilmore From saint.snit at gmail.com Tue Sep 15 05:33:04 2020 From: saint.snit at gmail.com (saint.snit at gmail.com) Date: Mon, 14 Sep 2020 14:33:04 -0500 Subject: [TUHS] revision history of troff -me macro set? Message-ID: <5f5fc849.1c69fb81.8127c.ee16@mx.google.com> Hi, Is there a repository of historical versions of Eric Allman's -me macro set for troff? (For some context: the macro set has been forked to operate with two modern troff implementations: GNU groff and Heirloom troff. According to the header blocks of the respective files, groff's -me macros are forked from version 2.31 of Allman's, and Heirloom's from version 2.14. For help in debugging -me problems in these troff implementations, I'm trying to locate at least these versions of the -me package as they existed before forking. I posted this query on the troff email list, but no one there knew the answer, and one person suggested I ask here.) Thanks for any pointers. From imp at bsdimp.com Tue Sep 15 06:02:53 2020 From: imp at bsdimp.com (Warner Losh) Date: Mon, 14 Sep 2020 14:02:53 -0600 Subject: [TUHS] revision history of troff -me macro set? In-Reply-To: <5f5fc849.1c69fb81.8127c.ee16@mx.google.com> References: <5f5fc849.1c69fb81.8127c.ee16@mx.google.com> Message-ID: There should be copies in 4BSD releases. But it is also in the SCCS files as share/me/SCCS/s.tmac.orig_me and that has what looks like a complete history. Warner On Mon, Sep 14, 2020, 1:46 PM wrote: > Hi, > > Is there a repository of historical versions of Eric Allman's -me macro > set for troff? > > (For some context: the macro set has been forked to operate with two > modern troff implementations: GNU groff and Heirloom troff. According > to the header blocks of the respective files, groff's -me macros are > forked from version 2.31 of Allman's, and Heirloom's from version 2.14. > For help in debugging -me problems in these troff implementations, > I'm trying to locate at least these versions of the -me package as they > existed before forking. I posted this query on the troff email list, > but no one there knew the answer, and one person suggested I ask here.) > > Thanks for any pointers. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Tue Sep 15 06:08:21 2020 From: henry.r.bent at gmail.com (Henry Bent) Date: Mon, 14 Sep 2020 16:08:21 -0400 Subject: [TUHS] revision history of troff -me macro set? In-Reply-To: References: <5f5fc849.1c69fb81.8127c.ee16@mx.google.com> Message-ID: On Mon, 14 Sep 2020 at 16:04, Warner Losh wrote: > There should be copies in 4BSD releases. > > But it is also in the SCCS files as share/me/SCCS/s.tmac.orig_me and that > has what looks like a complete history. > > Warner > > On Mon, Sep 14, 2020, 1:46 PM wrote: > >> Hi, >> >> Is there a repository of historical versions of Eric Allman's -me macro >> set for troff? >> >> (For some context: the macro set has been forked to operate with two >> modern troff implementations: GNU groff and Heirloom troff. According >> to the header blocks of the respective files, groff's -me macros are >> forked from version 2.31 of Allman's, and Heirloom's from version 2.14. >> For help in debugging -me problems in these troff implementations, >> I'm trying to locate at least these versions of the -me package as they >> existed before forking. I posted this query on the troff email list, >> but no one there knew the answer, and one person suggested I ask here.) >> >> Thanks for any pointers. >> > Here's a link: https://svnweb.freebsd.org/csrg/share/me/tmac.orig_me?view=log -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at eric.allman.name Tue Sep 15 06:57:35 2020 From: tuhs at eric.allman.name (Eric Allman) Date: Mon, 14 Sep 2020 13:57:35 -0700 Subject: [TUHS] revision history of troff -me macro set? In-Reply-To: <5f5fc849.1c69fb81.8127c.ee16@mx.google.com> References: <5f5fc849.1c69fb81.8127c.ee16@mx.google.com> Message-ID: <16bdccff-b3e8-509e-7cb2-9306ec657113@neophilic.com> I've got the SCCS files for tmac.e through 2.14 (12/28/1981). I'm not sure what happened to later versions. eric On 2020-09-14 12:33 , saint.snit at gmail.com wrote: > Hi, > > Is there a repository of historical versions of Eric Allman's -me macro > set for troff? > > (For some context: the macro set has been forked to operate with two > modern troff implementations: GNU groff and Heirloom troff. According > to the header blocks of the respective files, groff's -me macros are > forked from version 2.31 of Allman's, and Heirloom's from version 2.14. > For help in debugging -me problems in these troff implementations, > I'm trying to locate at least these versions of the -me package as they > existed before forking. I posted this query on the troff email list, > but no one there knew the answer, and one person suggested I ask here.) > > Thanks for any pointers. > From reed at reedmedia.net Tue Sep 15 07:41:16 2020 From: reed at reedmedia.net (Jeremy C. Reed) Date: Mon, 14 Sep 2020 16:41:16 -0500 (CDT) Subject: [TUHS] revision history of troff -me macro set? In-Reply-To: <5f5fc849.1c69fb81.8127c.ee16@mx.google.com> References: <5f5fc849.1c69fb81.8127c.ee16@mx.google.com> Message-ID: > Is there a repository of historical versions of Eric Allman's -me macro > set for troff? Also see https://minnie.tuhs.org/cgi-bin/utree.pl?file=2BSD/doc/me https://minnie.tuhs.org/cgi-bin/utree.pl?file=2BSD/bin/lib/me (especially revisions and tmac.e) https://minnie.tuhs.org/cgi-bin/utree.pl?file=2BSD/src/me (again revisions and tmac.e) And look at the SCCS "s.revisions" file While it says "First Release: 11 Sept 1978" there is also a tmac.e included and used by docs in 1BSD for exrefm. From aek at bitsavers.org Wed Sep 16 05:13:19 2020 From: aek at bitsavers.org (Al Kossow) Date: Tue, 15 Sep 2020 12:13:19 -0700 Subject: [TUHS] Plan 9 published manuals Message-ID: <1ccfc4e0-d6fa-7201-8e2f-ff81ca2f389e@bitsavers.org> https://www.ebay.com/itm/383710751719 how rare are these? $150 seems like a lot of money to spend on them From crossd at gmail.com Wed Sep 16 06:32:18 2020 From: crossd at gmail.com (Dan Cross) Date: Tue, 15 Sep 2020 16:32:18 -0400 Subject: [TUHS] Plan 9 published manuals In-Reply-To: <1ccfc4e0-d6fa-7201-8e2f-ff81ca2f389e@bitsavers.org> References: <1ccfc4e0-d6fa-7201-8e2f-ff81ca2f389e@bitsavers.org> Message-ID: That's for the 2nd Edition. Those are fairly rare. I once traded a sweatshirt to Rob Pike for a copy of those (and a few swag T-shirts so I wouldn't get too cold taking the train back to New York City from MH). - Dan C. On Tue, Sep 15, 2020 at 4:26 PM Al Kossow wrote: > https://www.ebay.com/itm/383710751719 > > how rare are these? $150 seems like a lot of money to spend on them > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lyndon at orthanc.ca Wed Sep 16 07:38:12 2020 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Tue, 15 Sep 2020 14:38:12 -0700 Subject: [TUHS] Plan 9 published manuals In-Reply-To: <1ccfc4e0-d6fa-7201-8e2f-ff81ca2f389e@bitsavers.org> References: <1ccfc4e0-d6fa-7201-8e2f-ff81ca2f389e@bitsavers.org> Message-ID: Al Kossow writes: > how rare are these? $150 seems like a lot of money to spend on them AFAIK they only shipped with a licensed copy of the 2nd Edition of Plan 9, so they aren't that common. Sadly I lost my set a decade ago :-( $150 is probably a realistic value, given their rarity. Of course Abebooks has completely destroyed the used book marketplace, so it's impossible to accurately value anything that's out of print these days. --lyndon From cmhanson at eschatologist.net Wed Sep 16 09:28:36 2020 From: cmhanson at eschatologist.net (Chris Hanson) Date: Tue, 15 Sep 2020 16:28:36 -0700 Subject: [TUHS] Historical sources for 68010 + 68451 systems? Message-ID: I have an MVME121 that I’d like to run some stuff on. I’m planning what I’ll need to do to port MINIX 1.5 but since this has a 68451 segmented MMU, I’d like to actually make use of it. Have any historical sources been published for UNIX on the various 68010 + 68451 systems from the early-mid 1980s? I’m curious how they used segmented MMUs. I figure at minimum I could have several segments set up to enforce protections and a stable per-process address space, but it’d be good to have an example. — Chris From gregg.drwho8 at gmail.com Wed Sep 16 09:55:52 2020 From: gregg.drwho8 at gmail.com (Gregg Levine) Date: Tue, 15 Sep 2020 19:55:52 -0400 Subject: [TUHS] Historical sources for 68010 + 68451 systems? In-Reply-To: References: Message-ID: Hello! Chris I have one of the later ones, a 133 in fact, and I've been trying to find what I could run on it. Never mind a case for it, plus power supply and stuff.... Can you share, off list of course, where you'd gotten it? ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Tue, Sep 15, 2020 at 7:49 PM Chris Hanson wrote: > > I have an MVME121 that I’d like to run some stuff on. I’m planning what I’ll need to do to port MINIX 1.5 but since this has a 68451 segmented MMU, I’d like to actually make use of it. > > Have any historical sources been published for UNIX on the various 68010 + 68451 systems from the early-mid 1980s? I’m curious how they used segmented MMUs. > > I figure at minimum I could have several segments set up to enforce protections and a stable per-process address space, but it’d be good to have an example. > > — Chris > From cmhanson at eschatologist.net Wed Sep 16 13:05:46 2020 From: cmhanson at eschatologist.net (Chris Hanson) Date: Tue, 15 Sep 2020 20:05:46 -0700 Subject: [TUHS] Historical sources for 68010 + 68451 systems? In-Reply-To: References: Message-ID: <5B4796B8-4E02-47C0-AD0E-EEBFF4334466@eschatologist.net> On Sep 15, 2020, at 4:55 PM, Gregg Levine wrote: > Chris I have one of the later ones, a 133 in fact, and I've been > trying to find what I could run on it. Never mind a case for it, plus > power supply and stuff.... Can you share, off list of course, where > you'd gotten it? Oh, I don’t mind sharing on-list! I just bought the board—and a system controller, and some additional RAM boards, as well as the VME chassis with built-in PSU—on eBay. Lots of sellers are willing to make pretty good deals. There’s barely anything I paid over US$100 for, and I’ve only been collecting the VME stuff for a couple years. In theory you should be able to use any VME or VXI chassis for most VME hardware. What’s hard to find are manuals for anything not on Bitsavers[1], or software to run on it. At least NetBSD has been ported to the common 68030+ and PowerPC VME boards, and an old version of OpenBSD runs on the common 88K ones. Alas the 133 doesn’t have an MMU so it’s going to be a bit more restricted. One of the reasons to run MINIX 1.5 on my MVME121 is that it should be nice and fast on a 10MHz system with 8.5MB of RAM (including 4KB of cache), and as a V7 UNIX clone with an ANSI C compiler it’ll be easy to write for and port to. It’ll probably also be nicer than running one of the first few versions of Motorola System V/68 on it too, since I think that’s SVR1… Your 133 should also be straightforward to port MINIX to as well, since all the hardware’s simple, standard, and documented in the manual (plus data books). My plan was to start with MINIX 1.5 on Atari ST under Hatari, then just write some device drivers and a boot loader to replace the ST-specific ones. — Chris [1] Or Artisan Technology Group’s web site; they sell a ton of used VME hardware, and seem to collect what manuals and data sheets they can and provide them as PDF. From arno.griffioen at ieee.org Wed Sep 16 15:21:49 2020 From: arno.griffioen at ieee.org (Arno Griffioen) Date: Wed, 16 Sep 2020 07:21:49 +0200 Subject: [TUHS] Historical sources for 68010 + 68451 systems? In-Reply-To: References: Message-ID: <20200916052149.GH3311@ancienthardware.org> On Tue, Sep 15, 2020 at 04:28:36PM -0700, Chris Hanson wrote: > I have an MVME121 that I’d like to run some stuff on. I’m planning what I’ll > need to do to port MINIX 1.5 but since this has a 68451 segmented MMU, I’d > like to actually make use of it. Quite doable to adapt MINIX to this. Did a similar thing ages ago while still in school on a 68010 machine (not really VME, but similar card-cage setup) that had a custom MMU built from some SRAM and some control logic on it. Used MINIX 1.1 at the time though.. Only had 1MB physical RAM and the MMU could provide a virtual address space of 4MB. Initially ported MINIX to the machine 'as is' from the ST version and then modified the MINIX kernel to allow it to use the 4MB virtual space and such. Because of the bare-bones MMU design it had some interesting quirks that made it a good learning experience at the time. (and some very odd serial chips for the terminals that had their own 'interesting' behaviour but that's a different story..) Originally the machine did have a real SVR2 UNIX running on it, but sadly it was binary-only, so apart from some dis-assembly of bootstrap bits to learn how to get MINIX to start on this machine it was not very useful. > I figure at minimum I could have several segments set up to enforce > protections and a stable per-process address space, but it’d be good to > have an example. Yup. You may run into some of the shortcuts in the MINIX kernel when you start doing MMU work though, especially if you want to separate the kernel 'processes' as well. For performance the microkernel architecture of MINIX was violated in a few spots, mostly around FS and MM, where one kernel process would/could modify another's memory without going through the message passing mechanism. Introduce an MMU and that kinda breaks and needs some cleaning up ;) As MINIX later on did get a 386 port and cleanups/fixes that may now be a non-issue on 1.5. Another option would be Linux/m68k and perhaps starting on the 'nommu' version that runs on basic 68000's too and seeing how much functionality could be used from the 68451 to enhance it. Some of the Coldfire CPU's have similar limited MMU's that are supported for some functions of basic memory protection in the 'nommu' tree. As far as real UNIX sources go.. SUN2's were 68010's too although AFAIK with a custom SUN designed MMU logic? Perhaps some old sources available in that corner though. Bye, Arno. From aek at bitsavers.org Wed Sep 16 18:53:16 2020 From: aek at bitsavers.org (Al Kossow) Date: Wed, 16 Sep 2020 01:53:16 -0700 Subject: [TUHS] Historical sources for 68010 + 68451 systems? In-Reply-To: References: Message-ID: On 9/15/20 4:28 PM, Chris Hanson wrote: > Have any historical sources been published for UNIX on the various 68010 + 68451 systems from the early-mid 1980s? I have been looking for these for a long time now, in particular the sources for Unisoft Uniplus+ for the 000 or 010 and 451 MMU, or a copy of Motorola's System V port for the VME10. A very long time ago, I disassembled the Unisoft binary for the Uniplus+ kernel. From beebe at math.utah.edu Thu Sep 17 05:53:17 2020 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Wed, 16 Sep 2020 13:53:17 -0600 Subject: [TUHS] Historical sources for 68010 + 68451 systems? Message-ID: Chris Hanson asks about historical sources for Unix on the Motorola 68K processor. >From my bibliography at http://www.math.utah.edu/pub/tex/bib/unix.bib I find these Motorola contributions The Dynamics of a Semi-Large Software Project with Specific Reference to a UNIX System Port USENIX Conference Proceedings, Summer, 1984. Salt Lake City, UT pp. 332--342 [I think that I have a printed copy in my campus office, but won't be there for another 10 days or so.] Latent Source Bugs and UNIX System Portability Proceedings: USENIX Association Winter Conference, January 23--25, 1985, Dallas, Texas, USA pp. 125--130 Co-Resident Operating System: UNIX and Real-Time Distributed Processing Fifth Real-Time Software and Operating Systems Workshop Proceedings, May 12--13, 1988. Washington, DC pp 47--53 Co-Resident Operating System: UNIX and Real-Time Distributed Processing [Fifth RTOS... as above] pp. 47--53 A Faster fsck for BSD UNIX Proceedings of the Winter 1989 USENIX Conference: January 30--February 3, 1989, San Diego, California, USA pp. 173--185 Also take a look at the 200 entries in http://www.math.utah.edu/pub/tex/bib/minix.bib I have made attempts to install Debian 10 on the MC68K on QEMU from an ISO image at https://cdimage.debian.org/cdimage/ports/2020-05-30/ Source code is, of course, available, so it could be useful resource in porting Minix to the MC68K. However, while I can get the ISO image to boot, I get grub update failures and when I try run the installer, I get "No PCI buses available", For now, I have given up on that platform until new ideas for workarounds appear. I have similar emulated VMs for ARM64, RISC-V64, PowerPC (big and little endian), and IBM System 390x, all of which run nicely, have up-to-date O/Ses and binary software package repositories, and are used for routine software build testing. My attempts for other VMs for HPPA, Alpha, and SPARC64 CPUs have failed with install or network problems. Debian ISO images are available for IA-64, but QEMU has no support for the Itanium CPU family. We have a single phyical IA-64 system that runs fine, but is currently powered off due to machine-room air-conditioning issues that will be resolved in a couple of months. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From dave at horsfall.org Thu Sep 17 09:47:37 2020 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 17 Sep 2020 09:47:37 +1000 (EST) Subject: [TUHS] Historical sources for 68010 + 68451 systems? In-Reply-To: References: Message-ID: On Wed, 16 Sep 2020, Al Kossow wrote: > I have been looking for these for a long time now, in particular the sources > for Unisoft Uniplus+ for the 000 or 010 [...] I still have the mental scars from having to support Uniplus+ ... Please don't ask for further details, because I don't want to recall them when having to demonstrate an unstable system at a pre-sales demo. -- Dave From saint.snit at gmail.com Thu Sep 17 16:20:58 2020 From: saint.snit at gmail.com (saint.snit at gmail.com) Date: Thu, 17 Sep 2020 01:20:58 -0500 Subject: [TUHS] revision history of troff -me macro set? Message-ID: <5f63727d.1c69fb81.d0ed5.97f6@mx.google.com> Thanks, everyone, for the very helpful replies. Those links are exactly what I was looking for. From mah at mhorton.net Sat Sep 19 07:22:22 2020 From: mah at mhorton.net (Mary Ann Horton) Date: Fri, 18 Sep 2020 14:22:22 -0700 Subject: [TUHS] GBACA Message-ID: <738c95bb-8d13-6d80-bdaf-4eb2804077d2@mhorton.net> The topic of GBACA (Get Back At Corporate America), the video game for the BLIT/5620, has come up on a Facebook group. Does anyone happen to have any details about it, source code, author, screen shots, ...? Thanks,     Mary Ann From doug at cs.dartmouth.edu Sat Sep 19 11:51:34 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Fri, 18 Sep 2020 21:51:34 -0400 Subject: [TUHS] reviving a bit of WWB Message-ID: <202009190151.08J1pYnb066792@tahoe.cs.dartmouth.edu> I would like to revive Lorinda Cherry's "parts". Implicit in "revival" is dispelling the hundreds of warnings from gcc -Wpedantic -Wall -Wextra. Has anybody done this already? Doug From paul at rileyriot.com Sat Sep 19 13:22:39 2020 From: paul at rileyriot.com (Paul Riley) Date: Sat, 19 Sep 2020 11:22:39 +0800 Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems In-Reply-To: References: Message-ID: Team, I’ve read thru the FAQ and other sources regarding compatibility of Research and other flavours on the PDP-11. I have two physical machines, an 11/03 and an 11/23+. I’m choosing which version to use on each machine. Is LSX the only option on the 11/03, or could I run V6 or Mini-Unix with more RAM? >From the FAQ, it says V7 would support 11/23 with kernel recompilation, I assume includes 11/23+. I see 2.11BSD would also run on a ‘23 (and + I guess) with 1MB or more of RAM, so that would be preferred. I suppose 2.11 would be preferable. I also have found another 11/23+ system from a seller here in China. There’s the system, and a VT100, and a hard drive I can’t identify. Here’s a photo, does anyone know what it is? I may bid for it... Paul *Paul Riley* -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IMG_5479.jpg Type: image/jpeg Size: 52050 bytes Desc: not available URL: From paul at rileyriot.com Sat Sep 19 13:26:41 2020 From: paul at rileyriot.com (Paul Riley) Date: Sat, 19 Sep 2020 11:26:41 +0800 Subject: [TUHS] Unix on DEC AlphaServer 4000 Message-ID: I have an opportunity to buy a DEC AlphaServer. Is there a version of Unix which will run on this? Paul *Paul Riley* -------------- next part -------------- An HTML attachment was scrubbed... URL: From rp at servium.ch Sat Sep 19 14:19:51 2020 From: rp at servium.ch (Rico Pajarola) Date: Fri, 18 Sep 2020 21:19:51 -0700 Subject: [TUHS] Unix on DEC AlphaServer 4000 In-Reply-To: References: Message-ID: Digital Unix / Tru64 >= 4.x (I'd have to check, might be 4.0A), NetBSD, OpenBSD, Linux (e.g. Debian) Awesome machine, just a warning (in case you are buying it blindly), it's huge. On Fri, Sep 18, 2020 at 8:28 PM Paul Riley wrote: > I have an opportunity to buy a DEC AlphaServer. Is there a version of Unix > which will run on this? > > Paul > > *Paul Riley* > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From beebe at math.utah.edu Sat Sep 19 14:26:20 2020 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Fri, 18 Sep 2020 22:26:20 -0600 Subject: [TUHS] Unix on DEC AlphaServer 4000 In-Reply-To: Message-ID: >> I have an opportunity to buy a DEC AlphaServer. Is there a version of Unix >> which will run on this? There are several Debian Alpha ISO images available: http://archive.debian.org/debian/dists/etch/main/installer-alpha https://cdimage.debian.org/cdimage/archive/5.0.10/alpha/iso-cd https://cdimage.debian.org/cdimage/ports/2020-08-19/ https://wiki.qemu.org/Documentation/Platforms/Alpha https://www.debian.org/ports/alpha/ https://www.debian.org/releases/woody/alpha And Gentoo Linux: https://wiki.gentoo.org/wiki/Alpha/FAQ There is also NetBSD: https://cdn.netbsd.org/pub/NetBSD/NetBSD-9.0/alpha And OpenBSD: http://www.openbsd.org/alpha.html And FreeBSD: https://www.freebsd.org/releases/6.0R/hardware-alpha.html We ran DEC OSF/1 until the power supplies on our several Alpha systems died, but it had an annual license fee, and the O/S shutdown when the license expired. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From athornton at gmail.com Sat Sep 19 14:27:51 2020 From: athornton at gmail.com (Adam Thornton) Date: Fri, 18 Sep 2020 21:27:51 -0700 Subject: [TUHS] Unix on DEC AlphaServer 4000 In-Reply-To: References: Message-ID: <1676D082-BCD9-4A0E-AC36-EE4F4E5B0E2C@gmail.com> > On Sep 18, 2020, at 8:26 PM, Paul Riley wrote: > > I have an opportunity to buy a DEC AlphaServer. Is there a version of Unix which will run on this? Plenty: Digital Unix, NetBSD, or Linux all come to mind. But I mean, those are kinda boring because they’re Unix which you can run on anything (I mean, sorry, TUHS, but…it’s not like we didn’t win the ubiquity wars). If you have an Alpha, run OpenVMS! VSI’s hobbyist license program is supplying licenses now. Adam From nobozo at gmail.com Sat Sep 19 14:33:38 2020 From: nobozo at gmail.com (Jon Forrest) Date: Fri, 18 Sep 2020 21:33:38 -0700 Subject: [TUHS] Unix on DEC AlphaServer 4000 In-Reply-To: References: Message-ID: <58699dd0-5477-2fe4-5435-ccadeebed821@gmail.com> On 9/18/2020 8:26 PM, Paul Riley wrote: > I have an opportunity to buy a DEC AlphaServer. Is there a version of > Unix which will run on this? Absolutely! The CS Dept. at UC Berkeley got some of the first Alphas released by DEC back in the 90s (I don't remember the exact dates). We ran OSF/1 (a.k.a. Digital Unix, a.k.a other names). In fact, what became PostgreSQL was developed on Alphas running that Unix. Jon From heinz at osta.com Sun Sep 20 00:20:56 2020 From: heinz at osta.com (Heinz Lycklama) Date: Sat, 19 Sep 2020 07:20:56 -0700 Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems In-Reply-To: References: Message-ID: <4f09e601-b0a2-3574-aa03-132fc415da0e@osta.com> I do believe that it would be easier to use LSX source code, but I also know that some folks at universities were able to modify the source for Mini-UNIX to run on 11/03 in the mid-70's because of the two, only Mini-UNIX source code was available to universities. Heinz On 9/18/2020 8:22 PM, Paul Riley wrote: > > Team, > > I’ve read thru the FAQ and other sources regarding compatibility of > Research and other flavours on the PDP-11. I have two physical > machines, an 11/03 and an 11/23+. I’m choosing which version to use on > each machine. > > Is LSX the only option on the 11/03, or could I run V6 or Mini-Unix > with more RAM? > > From the FAQ, it says V7 would support 11/23 with kernel > recompilation, I assume includes 11/23+. I see 2.11BSD would also run > on a ‘23 (and + I guess) with 1MB or more of RAM, so that would be > preferred. I suppose 2.11 would be preferable. > > I also have found another 11/23+ system from a seller here in China. > There’s the system, and a VT100, and a hard drive I can’t identify. > Here’s a photo, does anyone know what it is? I may bid for it... > > Paul > > *Paul Riley* > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Sun Sep 20 01:28:35 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 19 Sep 2020 11:28:35 -0400 (EDT) Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems Message-ID: <20200919152835.4E73A18C0DD@mercury.lcs.mit.edu> > From: Paul Riley > Is LSX the only option on the 11/03, or could I run V6 or Mini-Unix with > more RAM? All PDP-11 Unix versions from V4 on require the MMU, so the -11/03 is out for them. We don't have the code for V2-V4, though. So V1 (mostly all assembler, no C :-), LSW and Mini-Unix are the only options for it. V6 can be run on an -11/23 (I've done it), but not straight out of the box; it requires a few minor tweaks first: http://gunkies.org/wiki/Running_UNIX_V6_on_an_-11/23 Noel From clemc at ccc.com Sun Sep 20 03:45:31 2020 From: clemc at ccc.com (Clem Cole) Date: Sat, 19 Sep 2020 13:45:31 -0400 Subject: [TUHS] Unix on DEC AlphaServer 4000 In-Reply-To: References: Message-ID: Tru64 will give you the best experience of the time, allow you to use the GEM compilers, TruClusters, and all of hte interesting layered products. The issue is license managers as Nelson says, but Internet search is your friend *i.e.* different unlimited time styles license PAKs for Tru64 have been reported to have been seen in the wild, however YMMV. On Sat, Sep 19, 2020 at 12:27 AM Nelson H. F. Beebe wrote: > >> I have an opportunity to buy a DEC AlphaServer. Is there a version of > Unix > >> which will run on this? > > There are several Debian Alpha ISO images available: > > http://archive.debian.org/debian/dists/etch/main/installer-alpha > https://cdimage.debian.org/cdimage/archive/5.0.10/alpha/iso-cd > https://cdimage.debian.org/cdimage/ports/2020-08-19/ > https://wiki.qemu.org/Documentation/Platforms/Alpha > https://www.debian.org/ports/alpha/ > https://www.debian.org/releases/woody/alpha > > And Gentoo Linux: > > https://wiki.gentoo.org/wiki/Alpha/FAQ > > There is also NetBSD: > > https://cdn.netbsd.org/pub/NetBSD/NetBSD-9.0/alpha > > And OpenBSD: > > http://www.openbsd.org/alpha.html > > And FreeBSD: > > https://www.freebsd.org/releases/6.0R/hardware-alpha.html > > We ran DEC OSF/1 until the power supplies on our several Alpha systems > died, but it had an annual license fee, and the O/S shutdown when the > license expired. > > > ------------------------------------------------------------------------------- > - Nelson H. F. Beebe Tel: +1 801 581 5254 > - > - University of Utah FAX: +1 801 581 4148 > - > - Department of Mathematics, 110 LCB Internet e-mail: > beebe at math.utah.edu - > - 155 S 1400 E RM 233 beebe at acm.org > beebe at computer.org - > - Salt Lake City, UT 84112-0090, USA URL: > http://www.math.utah.edu/~beebe/ - > > ------------------------------------------------------------------------------- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnu at toad.com Sun Sep 20 05:42:39 2020 From: gnu at toad.com (John Gilmore) Date: Sat, 19 Sep 2020 12:42:39 -0700 Subject: [TUHS] Unix on DEC AlphaServer 4000 In-Reply-To: References: Message-ID: <32401.1600544559@hop.toad.com> Nelson H. F. Beebe wrote: > We ran DEC OSF/1 until the power supplies on our several Alpha systems > died, but it had an annual license fee, and the O/S shutdown when the > license expired. Clem Cole wrote: > The issue is license managers as Nelson says, but Internet search is your > friend *i.e.* different unlimited time styles license PAKs for Tru64 have > been reported to have been seen in the wild, however YMMV. License managers now count as DRM, under the Digital Millennium Copyright Act (though no such laws had been passed when the license managers were first created). So: is it worth breaking the law in many countries, to maintain a historical curiosity? Personally, I would throw DRM-encrusted software, and the hardware that is dependent on it, into the dustbin of history. Its creators had fair warning that they were making their products unusable after they stopped caring to maintain them. They didn't care about their place in history, nor about their users. They did it anyway, for short-term profit and to harass those people foolish enough to be their customers. Their memes should not be passed to future generations. As Sir Walter Scott suggested in another context, they "doubly dying, shall go down, to the vile dust, from whence [they] sprung, unwept, unhonour'd, and unsung". John From davida at pobox.com Sun Sep 20 07:56:53 2020 From: davida at pobox.com (David Arnold) Date: Sun, 20 Sep 2020 07:56:53 +1000 Subject: [TUHS] Unix on DEC AlphaServer 4000 In-Reply-To: <58699dd0-5477-2fe4-5435-ccadeebed821@gmail.com> References: <58699dd0-5477-2fe4-5435-ccadeebed821@gmail.com> Message-ID: I worked at a Digital-sponsored lab in Australia from the early 90’s. DEC offered us a great deal on DEC 3000-era workstations, replacing all our Ultrix DECstations in (I think) 1994. At that point, very little of the freely available software would build cleanly for 64 bit platforms. Even the stuff with Cray support often didn’t work with OSF/1’s 32 bit int/64 bit long model. And pthreads was a mess, with all the Unix-like systems having implementations of different drafts that were incompatible. After a while Digital started redistributing a “freeware” collection of suitably patched versions to bootstrap everyone’s workflows. d > On 19 Sep 2020, at 14:34, Jon Forrest wrote: > >  > >> On 9/18/2020 8:26 PM, Paul Riley wrote: >> I have an opportunity to buy a DEC AlphaServer. Is there a version of Unix which will run on this? > > Absolutely! The CS Dept. at UC Berkeley got some of the first Alphas > released by DEC back in the 90s (I don't remember the exact dates). > We ran OSF/1 (a.k.a. Digital Unix, a.k.a other names). In fact, what > became PostgreSQL was developed on Alphas running that Unix. > > Jon > From rudi.j.blom at gmail.com Sun Sep 20 15:29:52 2020 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Sun, 20 Sep 2020 12:29:52 +0700 Subject: [TUHS] Unix on DEC AlphaServer 4000 Message-ID: You're a bit harsh on the developers but I think in most cases it was the marketing/finance part of companies which decided on such mundane matters as licensing. My 2-1/2 cents. Cheers, uncle rubl >Date: Sat, 19 Sep 2020 12:42:39 -0700 >From: John Gilmore >To: Clem Cole >Cc: "Nelson H. F. Beebe" , tuhs > >Subject: Re: [TUHS] Unix on DEC AlphaServer 4000 >Message-ID: <32401.1600544559 at hop.toad.com> ... snip ... >License managers now count as DRM, under the Digital Millennium >Copyright Act (though no such laws had been passed when the license >managers were first created). So: is it worth breaking the law in many >countries, to maintain a historical curiosity? >Personally, I would throw DRM-encrusted software, and the hardware that >is dependent on it, into the dustbin of history. Its creators had fair. >warning that they were making their products unusable after they stopped >caring to maintain them. They didn't care about their place in history, >nor about their users. They did it anyway, for short-term profit and to >harass those people foolish enough to be their customers. Their memes >should not be passed to future generations. As Sir Walter Scott >suggested in another context, they "doubly dying, shall go down, to the. >vile dust, from whence [they] sprung, unwept, unhonour'd, and unsung". John From jnc at mercury.lcs.mit.edu Sun Sep 20 23:12:26 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 20 Sep 2020 09:12:26 -0400 (EDT) Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems Message-ID: <20200920131226.C205118C0E2@mercury.lcs.mit.edu> > Thanks so much for your reply. That's what we're here for... :-) > I have an 11/23+ does that make a difference? No. The KDF11-B of the 23+: http://gunkies.org/wiki/KDF11-B_CPU is the same CPU as all the other KDF11 CPUs; it just has a couple of extra peripherals on the board (2 asyn serial lines, and some PROMs, IIRC). > From the manual it seems to have an MMU Like all KDF11 CPUs, it has a socket for an MMU chip, but the chip may or may not be there (I don't know if it was standard on the 23+; and in any event, it may have been pulled - the CPU will work without it). The main CPU is a DIP carrier which holds two chips; the optional KTF11-A MMU has one (see the image, above); the optional KEF11-A FPU is also a carrier with two chips. (The KDF11-B can also hold the large 6-chip carrier of the optional KEF11-B CIS chip - a rara avid indeed, if you'relucky enough to have it.) If yours doesn't have the MMU chip, you're probably SOL; those are very rare. KEF11-A FPU chips are avilable on eBay for modest amounts. > I'm not sure if it's split I/D. None of the KDF11 CPUs support splite I/D. Noel From arnold at skeeve.com Mon Sep 21 04:42:49 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 20 Sep 2020 12:42:49 -0600 Subject: [TUHS] reviving a bit of WWB In-Reply-To: <202009190151.08J1pYnb066792@tahoe.cs.dartmouth.edu> References: <202009190151.08J1pYnb066792@tahoe.cs.dartmouth.edu> Message-ID: <202009201842.08KIgn2f022401@freefriends.org> Doug McIlroy wrote: > I would like to revive Lorinda Cherry's "parts". > Implicit in "revival" is dispelling the hundreds > of warnings from gcc -Wpedantic -Wall -Wextra. > Has anybody done this already? > > Doug I haven't tried this. I do suggest starting with 'gcc -m32' so that you're not fighting 64 bit issues at the same time as everything else. HTH, Arnold From will.senn at gmail.com Mon Sep 21 05:28:04 2020 From: will.senn at gmail.com (Will Senn) Date: Sun, 20 Sep 2020 14:28:04 -0500 Subject: [TUHS] reviving a bit of WWB In-Reply-To: <202009201842.08KIgn2f022401@freefriends.org> References: <202009190151.08J1pYnb066792@tahoe.cs.dartmouth.edu> <202009201842.08KIgn2f022401@freefriends.org> Message-ID: <04211470-AD63-452A-A0BB-6A7A6FD85AAE@gmail.com> When I read Doug’s message. I figured it was sarcasm related to the voluminous warnings that are generated these days and was harkening back to some paper Lorinda Cherry wrote about how they were needless additions to the perfection that was the original C compiler (that’s sarcasm) that I had never seen before. When you responded as you did, i began to realize the error of my conception :). If I’m. understanding now, Doug wants to resurrect the Writer’s workbench amalgamation of tools, most of which were written by Lorinda Cherry and he’s wanting to eliminate all of gcc’s warnings. I suppose Lorinda Cherry might actually have approved of -Wall in principle, as there is a strong parallelism between grammars here. When I teach student to use -Wall (with clang), I tell them that it’s very handy to see all of the warnings, but to only address those that they feel are value add, so to speak. I give the same advice to the writers I advise... just cuz Word tells you not to use passive voice, doesn’t mean that it isn’t often appropriate. One specific gcc/clang warning that I get a lot goes like this: while(entry = getutxent()){ // Do stuff with entry; } Sure, it’s a tricky bit, but the printed fix is to add a set of do nothing parens: while((entry = getutxent())) Hardly edifying :). Much better would ve the explicit compare: while((entry = getutxent()) != NULL) But even that implies the programmer isn’t capable of differentiating = and ==. That said, most -Wall stuff is ok, and I’d love to see an up to date wwb kit with few to no warnings! Good luck, Will Sent from my iPhone > On Sep 20, 2020, at 1:42 PM, arnold at skeeve.com wrote: > > Doug McIlroy wrote: > >> I would like to revive Lorinda Cherry's "parts". >> Implicit in "revival" is dispelling the hundreds >> of warnings from gcc -Wpedantic -Wall -Wextra. >> Has anybody done this already? >> >> Doug > > I haven't tried this. I do suggest starting with 'gcc -m32' so that > you're not fighting 64 bit issues at the same time as everything else. > > HTH, > > Arnold From arnold at skeeve.com Mon Sep 21 04:44:50 2020 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 20 Sep 2020 12:44:50 -0600 Subject: [TUHS] GBACA In-Reply-To: <738c95bb-8d13-6d80-bdaf-4eb2804077d2@mhorton.net> References: <738c95bb-8d13-6d80-bdaf-4eb2804077d2@mhorton.net> Message-ID: <202009201844.08KIioWT022529@freefriends.org> Mary Ann Horton wrote: > The topic of GBACA (Get Back At Corporate America), the video game for > the BLIT/5620, has come up on a Facebook group. > > Does anyone happen to have any details about it, source code, author, > screen shots, ...? > > Thanks, > >     Mary Ann > I remember that game! I am pretty sure it came out of Bell Labs; we had it at Georgia Tech along with our 5620s and the layers software (or whateverit was called) to let you use the 5620 on BSD vaxen. I don't remember (and don't think I knew) any other details.... Sorry, Arnold From usotsuki at buric.co Mon Sep 21 06:12:34 2020 From: usotsuki at buric.co (Steve Nickolas) Date: Sun, 20 Sep 2020 16:12:34 -0400 (EDT) Subject: [TUHS] reviving a bit of WWB In-Reply-To: <04211470-AD63-452A-A0BB-6A7A6FD85AAE@gmail.com> References: <202009190151.08J1pYnb066792@tahoe.cs.dartmouth.edu> <202009201842.08KIgn2f022401@freefriends.org> <04211470-AD63-452A-A0BB-6A7A6FD85AAE@gmail.com> Message-ID: On Sun, 20 Sep 2020, Will Senn wrote: > while((entry = getutxent())) > > Hardly edifying :). > > Much better would ve the explicit compare: > > while((entry = getutxent()) != NULL) > > But even that implies the programmer isn’t capable of differentiating = and ==. My version of that is "while (0!=(entry=getutxevent()))". (Of course, that assumes NULL is 0, but I don't think I've run into any architecture so braindead as to not have NULL=0.) -uso. From doug at cs.dartmouth.edu Mon Sep 21 06:26:02 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sun, 20 Sep 2020 16:26:02 -0400 Subject: [TUHS] reviving a bit of WWB In-Reply-To: References: <202009190151.08J1pYnb066792@tahoe.cs.dartmouth.edu> <202009201842.08KIgn2f022401@freefriends.org> <04211470-AD63-452A-A0BB-6A7A6FD85AAE@gmail.com> Message-ID: <202009202026.08KKQ2x6137303@tahoe.cs.dartmouth.edu> > (Of course, that assumes NULL is 0, but I don't think I've run into any > architecture so braindead as to not have NULL=0.) It has nothing to do with machine architecture. The C standard says 0 coerces to the null pointer. NULL, defined in , is part of the library, not the language. I always use 0, because NULL is a frill. Doug From clemc at ccc.com Mon Sep 21 06:50:53 2020 From: clemc at ccc.com (Clem Cole) Date: Sun, 20 Sep 2020 16:50:53 -0400 Subject: [TUHS] GBACA In-Reply-To: <202009201844.08KIioWT022529@freefriends.org> References: <738c95bb-8d13-6d80-bdaf-4eb2804077d2@mhorton.net> <202009201844.08KIioWT022529@freefriends.org> Message-ID: AT&T Summit had library called something like the Toolbox. A number of assorted tools like some PS support, the korn shell (ksh88), mk and think the some of the 5620 tools like layers where able to be purchased from it. It was all source. What I don’t remember how many of the 5620 games were in that kit (or much of anything else in it). On Sun, Sep 20, 2020 at 3:43 PM wrote: > Mary Ann Horton wrote: > > > > > The topic of GBACA (Get Back At Corporate America), the video game for > > > the BLIT/5620, has come up on a Facebook group. > > > > > > Does anyone happen to have any details about it, source code, author, > > > screen shots, ...? > > > > > > Thanks, > > > > > > Mary Ann > > > > > > > I remember that game! I am pretty sure it came out of Bell Labs; we had > > it at Georgia Tech along with our 5620s and the layers software (or > > whateverit was called) to let you use the 5620 on BSD vaxen. > > > > I don't remember (and don't think I knew) any other details.... > > > > Sorry, > > > > Arnold > > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Mon Sep 21 06:52:20 2020 From: clemc at ccc.com (Clem Cole) Date: Sun, 20 Sep 2020 16:52:20 -0400 Subject: [TUHS] GBACA In-Reply-To: References: <738c95bb-8d13-6d80-bdaf-4eb2804077d2@mhorton.net> <202009201844.08KIioWT022529@freefriends.org> Message-ID: If we can chase down that library you might find it in there but I know I don’t have it in my archives. On Sun, Sep 20, 2020 at 4:50 PM Clem Cole wrote: > AT&T Summit had library called something like the Toolbox. A number of > assorted tools like some PS support, the korn shell (ksh88), mk and think > the some of the 5620 tools like layers where able to be purchased from it. > It was all source. > > What I don’t remember how many of the 5620 games were in that kit (or much > of anything else in it). > > On Sun, Sep 20, 2020 at 3:43 PM wrote: > >> Mary Ann Horton wrote: >> >> >> >> > The topic of GBACA (Get Back At Corporate America), the video game for >> >> > the BLIT/5620, has come up on a Facebook group. >> >> > >> >> > Does anyone happen to have any details about it, source code, author, >> >> > screen shots, ...? >> >> > >> >> > Thanks, >> >> > >> >> > Mary Ann >> >> > >> >> >> >> I remember that game! I am pretty sure it came out of Bell Labs; we had >> >> it at Georgia Tech along with our 5620s and the layers software (or >> >> whateverit was called) to let you use the 5620 on BSD vaxen. >> >> >> >> I don't remember (and don't think I knew) any other details.... >> >> >> >> Sorry, >> >> >> >> Arnold >> >> -- > 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 doug at cs.dartmouth.edu Mon Sep 21 06:57:59 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sun, 20 Sep 2020 16:57:59 -0400 Subject: [TUHS] reviving a bit of WWB In-Reply-To: <202009202026.08KKQ2x6137303@tahoe.cs.dartmouth.edu> References: <202009190151.08J1pYnb066792@tahoe.cs.dartmouth.edu> <202009201842.08KIgn2f022401@freefriends.org> <04211470-AD63-452A-A0BB-6A7A6FD85AAE@gmail.com> <202009202026.08KKQ2x6137303@tahoe.cs.dartmouth.edu> Message-ID: <202009202057.08KKvxAu141367@tahoe.cs.dartmouth.edu> >> (Of course, that assumes NULL is 0, but I don't think I've run into any >> architecture so braindead as to not have NULL=0.) > > It has nothing to do with machine architecture. The C standard > says 0 coerces to the null pointer. NULL, defined in , > is part of the library, not the language. To put it more strongly. this is not a legal C source file. char *s = NULL; But this is. char *s = 0; Doug From usotsuki at buric.co Mon Sep 21 06:58:51 2020 From: usotsuki at buric.co (Steve Nickolas) Date: Sun, 20 Sep 2020 16:58:51 -0400 (EDT) Subject: [TUHS] reviving a bit of WWB In-Reply-To: <202009202026.08KKQ2x6137303@tahoe.cs.dartmouth.edu> References: <202009190151.08J1pYnb066792@tahoe.cs.dartmouth.edu> <202009201842.08KIgn2f022401@freefriends.org> <04211470-AD63-452A-A0BB-6A7A6FD85AAE@gmail.com> <202009202026.08KKQ2x6137303@tahoe.cs.dartmouth.edu> Message-ID: On Sun, 20 Sep 2020, Doug McIlroy wrote: >> (Of course, that assumes NULL is 0, but I don't think I've run into any >> architecture so braindead as to not have NULL=0.) > > It has nothing to do with machine architecture. The C standard > says 0 coerces to the null pointer. NULL, defined in , > is part of the library, not the language. I always use 0, > because NULL is a frill. > > Doug I was under the impression that there was explicitly no requirement that a null pointer be 0, and that there was at least one weird system where that wasn't true - that it just so happened that null points to 0 on certain CPUs and that 0=NULL *happens* to work on most CPUs but wasn't guaranteed. (In fact, I read that my habit of using 0 for NULL relied on a faulty assumption!) I mean, I've never actually used a CPU/OS/compiler where it wasn't true, but... -uso. From cowan at ccil.org Mon Sep 21 07:35:52 2020 From: cowan at ccil.org (John Cowan) Date: Sun, 20 Sep 2020 17:35:52 -0400 Subject: [TUHS] reviving a bit of WWB In-Reply-To: References: <202009190151.08J1pYnb066792@tahoe.cs.dartmouth.edu> <202009201842.08KIgn2f022401@freefriends.org> <04211470-AD63-452A-A0BB-6A7A6FD85AAE@gmail.com> <202009202026.08KKQ2x6137303@tahoe.cs.dartmouth.edu> Message-ID: When 0 is coerced implicitly or explicitly to a pointer type, it becomes a null pointer. That's true even on architectures where all-bits-zero is *not* a null pointer. However, in contexts where there is no expected type, as in a call to execl(), the null at the end of the args list has to be explicitly cast to (char *)0 or some other null pointer. As for the definition of NULL, it is indeed 0 on Linux, but can also be defined as ((void *)0), as on FreeBSD and the Mac, or even as 0L on systems where ints are half-size and pointers and longs are full-size. On Sun, Sep 20, 2020 at 4:59 PM Steve Nickolas wrote: > On Sun, 20 Sep 2020, Doug McIlroy wrote: > > >> (Of course, that assumes NULL is 0, but I don't think I've run into any > >> architecture so braindead as to not have NULL=0.) > > > > It has nothing to do with machine architecture. The C standard > > says 0 coerces to the null pointer. NULL, defined in , > > is part of the library, not the language. I always use 0, > > because NULL is a frill. > > > > Doug > > I was under the impression that there was explicitly no requirement that a > null pointer be 0, and that there was at least one weird system where that > wasn't true - that it just so happened that null points to 0 on certain > CPUs and that 0=NULL *happens* to work on most CPUs but wasn't guaranteed. > (In fact, I read that my habit of using 0 for NULL relied on a faulty > assumption!) > > I mean, I've never actually used a CPU/OS/compiler where it wasn't true, > but... > > -uso. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brantley at coraid.com Mon Sep 21 07:33:06 2020 From: brantley at coraid.com (Brantley Coile) Date: Sun, 20 Sep 2020 21:33:06 +0000 Subject: [TUHS] reviving a bit of WWB In-Reply-To: References: <202009190151.08J1pYnb066792@tahoe.cs.dartmouth.edu> <202009201842.08KIgn2f022401@freefriends.org> <04211470-AD63-452A-A0BB-6A7A6FD85AAE@gmail.com> <202009202026.08KKQ2x6137303@tahoe.cs.dartmouth.edu> Message-ID: <7F7B78DB-A3B5-4137-9301-E356A5C7EB88@coraid.com> The fact that a pointer of zero generates a hardware trap is not defined in the language, whereas a 0 is is defined to be a null pointer. I've worked on systems where a 0 pointer could be dereferenced without a trap. I wouldn't recommend it. System designers do things like make the first page of memory invalid so we will get a null pointer trap. On Plan 9 the beginning of the text segment starts at 0x1020. But that's not part of the C language. The fact that 0 is a null pointer is. Brantley > On Sep 20, 2020, at 4:58 PM, Steve Nickolas wrote: > > On Sun, 20 Sep 2020, Doug McIlroy wrote: > >>> (Of course, that assumes NULL is 0, but I don't think I've run into any >>> architecture so braindead as to not have NULL=0.) >> >> It has nothing to do with machine architecture. The C standard >> says 0 coerces to the null pointer. NULL, defined in , >> is part of the library, not the language. I always use 0, >> because NULL is a frill. >> >> Doug > > I was under the impression that there was explicitly no requirement that a null pointer be 0, and that there was at least one weird system where that wasn't true - that it just so happened that null points to 0 on certain CPUs and that 0=NULL *happens* to work on most CPUs but wasn't guaranteed. (In fact, I read that my habit of using 0 for NULL relied on a faulty assumption!) > > I mean, I've never actually used a CPU/OS/compiler where it wasn't true, but... > > -uso. From clemc at ccc.com Mon Sep 21 08:13:46 2020 From: clemc at ccc.com (Clem Cole) Date: Sun, 20 Sep 2020 18:13:46 -0400 Subject: [TUHS] reviving a bit of WWB In-Reply-To: <202009202057.08KKvxAu141367@tahoe.cs.dartmouth.edu> References: <202009190151.08J1pYnb066792@tahoe.cs.dartmouth.edu> <202009201842.08KIgn2f022401@freefriends.org> <04211470-AD63-452A-A0BB-6A7A6FD85AAE@gmail.com> <202009202026.08KKQ2x6137303@tahoe.cs.dartmouth.edu> <202009202057.08KKvxAu141367@tahoe.cs.dartmouth.edu> Message-ID: On Sun, Sep 20, 2020 at 4:58 PM Doug McIlroy wrote: > > To put it more strongly. this is not a legal C source file. > char *s = NULL; > But this is. > char *s = 0; > Hmmm ... Doug - As the risk of playing language lawyer here, I'm going to argue that between sections 6.3.2.3 and 7.19 the first is legal. Cut/pasted from my cope of the 2017 standard (I don't think this has changed in later drafts): ISO/IEC 9899:2017 Section 6.3.2.3 *Pointers* *....* 1. An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant.67) If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function. 2. 67)The macro NULL is defined in (and other headers) as a null pointer constant; see 7.19. 3. .... ISO/IEC 9899:2017 Section 7.19 *Common definitions * .... 1. The macros are NULL which expands to an implementation-defined null pointer constant; For whatever its worth, in a number of common coding standards where I have worked, have always required that when NULL was used, it was always cast first to the actual data type. Yes, this is verbose, but it means that a casual reader sees the type and in particularly in a commerical SW development setting, that is money in the bank from a maintence standpoint -- IIRC Gimpel's flexelint (which IMO oppinion was always the best lint around), has a switch that will force that behavior. As I understand it, the idea behind -Wall *et al*, is that if we can get code to be 'flexelint clean' the number of latent bugs drops dramatically. This is particularly true when dealing with code that started be written on a system with one word or pointer size and now needs to run elsewhere; which is a common issue commerical ISVs live a great deal [this is a codified in the 10th of Henry's commandments: Thou shalt foreswear, renounce, and abjure the vile heresy which claimeth that ``All the world's a VAX'', and have no commerce with the benighted heathens who cling to this barbarous belief, that the days of thy program may be long even though the days of thy current machine be short. : . -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Mon Sep 21 08:15:39 2020 From: clemc at ccc.com (Clem Cole) Date: Sun, 20 Sep 2020 18:15:39 -0400 Subject: [TUHS] reviving a bit of WWB In-Reply-To: References: <202009190151.08J1pYnb066792@tahoe.cs.dartmouth.edu> <202009201842.08KIgn2f022401@freefriends.org> <04211470-AD63-452A-A0BB-6A7A6FD85AAE@gmail.com> <202009202026.08KKQ2x6137303@tahoe.cs.dartmouth.edu> Message-ID: On Sun, Sep 20, 2020 at 4:59 PM Steve Nickolas wrote: > I was under the impression that there was explicitly no requirement that a > null pointer be 0, > Indeed, section 7.19 states it is *implementation-defined*. See my previous message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Mon Sep 21 08:47:23 2020 From: cowan at ccil.org (John Cowan) Date: Sun, 20 Sep 2020 18:47:23 -0400 Subject: [TUHS] reviving a bit of WWB In-Reply-To: References: <202009190151.08J1pYnb066792@tahoe.cs.dartmouth.edu> <202009201842.08KIgn2f022401@freefriends.org> <04211470-AD63-452A-A0BB-6A7A6FD85AAE@gmail.com> <202009202026.08KKQ2x6137303@tahoe.cs.dartmouth.edu> Message-ID: The confusion (I dare not call it a flame war) is arising out of the difference between an object with all bits zero and a 0 constant (or equivalently 2*0 or 3-3 or what not). 0 in pointer context is always a null pointer, but it may or may not be all-bits-zero. 0 in integer context is, on any sane machine, all-bits-zero (on 1's-complement machines it may also be all-bits-one). Personally, when I was programming in C I defined a macro #define NULLPTR(t) ((t)0), so that I would write NULLPTR(char *) or NULLPTR(int *) or whatever the Right Thing was. On Sun, Sep 20, 2020 at 6:16 PM Clem Cole wrote: > > > On Sun, Sep 20, 2020 at 4:59 PM Steve Nickolas wrote: > >> I was under the impression that there was explicitly no requirement that >> a >> null pointer be 0, >> > Indeed, section 7.19 states it is *implementation-defined*. See my > previous message. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Mon Sep 21 08:51:06 2020 From: norman at oclsc.org (Norman Wilson) Date: Sun, 20 Sep 2020 18:51:06 -0400 (EDT) Subject: [TUHS] reviving a bit of WWB Message-ID: <20200920225106.C579E4422E@lignose.oclsc.org> Brantley Coile: The fact that a pointer of zero generates a hardware trap is not defined in the language, whereas a 0 is is defined to be a null pointer. ===== The language doesn't require that dereferencing a null pointer cause a trap, either. There's no way to guarantee that behaviour in all environments unless every pointer dereference must include instructions to check for the null-pointer value, because C can run in environments in which any pointer value might be a valid address. On modern machines it's conventional for the null-pointer value in C, what you get when you assign 0 to a pointer, to be all-zeroes; and for operating systems to arrange that that address is unmapped. But that wasn't always so (on the PDP-7 there was no memory map; on the PDP-11 once memory-mapping was added, address space was too dear to throw away an eighth of it just to block null-pointer dereferencing), and it may still not be (consider a C program on an embedded system running without a memory map). It's good that modern systems usually whap you in the head if you deference a null pointer, but it's not required, and those who rely on it are as foolish as those who used to rely on the accident that the byte at address 0 on early VAX UNIX was a zero. Norman Wilson p&p6 and f( From norman at oclsc.org Mon Sep 21 09:00:57 2020 From: norman at oclsc.org (Norman Wilson) Date: Sun, 20 Sep 2020 19:00:57 -0400 (EDT) Subject: [TUHS] reviving a bit of WWB Message-ID: <20200920230057.C5D1A4422E@lignose.oclsc.org> Doug McIlroy: To put it more strongly. this is not a legal C source file. char *s = NULL; But this is. char *s = 0; Clem Cole: 67)The macro NULL is defined in (and other headers) as a null pointer constant; see 7.19. ==== $ cat null.c char *s = NULL; $ cat zero.c char *s = 0; $ zero.c is a legal C program. null.c is not. Create files exactly as shown and compile them if you don't believe me. Prepend `#include ' (or or ) to null.c and it becomes legal, but I think that's Doug's point: you need an include file. Personally I prefer to use NULL instead of 0 when spelling out a null pointer, because I think it's clearer: if ((buf = malloc(SIZE)) == NULL) error("dammit andrew"); though I am willing to omit it when there's no confusion about = vs ==: if (*p) dammit(*p, "andrew"); But that's just a question of style, and Doug's is fine too. The language does not require the compiler to pre-define NULL or to recognize it as a keyword; you have to include an appropriate standard header file. Norman Wilson Toronto ON (not 0N nor NULLN) From clemc at ccc.com Mon Sep 21 09:53:02 2020 From: clemc at ccc.com (Clem Cole) Date: Sun, 20 Sep 2020 19:53:02 -0400 Subject: [TUHS] reviving a bit of WWB In-Reply-To: <20200920230057.C5D1A4422E@lignose.oclsc.org> References: <20200920230057.C5D1A4422E@lignose.oclsc.org> Message-ID: Norman NULL has to be defined and I said that/showed it. The standard says where. I was not trying to compile NULL without a definition which I agree it not legal. If that is what Doug was implying I missed understood him but I note NULL was introduced in Typesetter C /V7 where those compiler s set it to 0 in studio but the ANSI/ISO moved it. On Sun, Sep 20, 2020 at 7:03 PM Norman Wilson wrote: > Doug McIlroy: > > > > To put it more strongly. this is not a legal C source file. > > char *s = NULL; > > But this is. > > char *s = 0; > > > > Clem Cole: > > > > 67)The macro NULL is defined in (and other headers) as a null > > pointer constant; see 7.19. > > > > ==== > > > > $ cat null.c > > char *s = NULL; > > $ cat zero.c > > char *s = 0; > > $ > > > > zero.c is a legal C program. null.c is not. Create > > files exactly as shown and compile them if you don't > > believe me. > > > > Prepend `#include ' (or or ) > > to null.c and it becomes legal, but I think that's Doug's > > point: you need an include file. > > > > Personally I prefer to use NULL instead of 0 when spelling > > out a null pointer, because I think it's clearer: > > if ((buf = malloc(SIZE)) == NULL) > > error("dammit andrew"); > > though I am willing to omit it when there's no confusion > > about = vs ==: > > if (*p) > > dammit(*p, "andrew"); > > > > But that's just a question of style, and Doug's is fine too. > > > > The language does not require the compiler to pre-define > > NULL or to recognize it as a keyword; you have to include > > an appropriate standard header file. > > > > Norman Wilson > > Toronto ON (not 0N nor NULLN) > > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Mon Sep 21 10:00:38 2020 From: clemc at ccc.com (Clem Cole) Date: Sun, 20 Sep 2020 20:00:38 -0400 Subject: [TUHS] reviving a bit of WWB In-Reply-To: References: <20200920230057.C5D1A4422E@lignose.oclsc.org> Message-ID: I was also stating (under Henry’s 10th) using a properly defined macro with the complete cast scheme will be correct and portable to all known conforming C compilers no matter the target HW architecture — which in a commercial SW setting is highly valued. Clem On Sun, Sep 20, 2020 at 7:53 PM Clem Cole wrote: > Norman NULL has to be defined and I said that/showed it. The standard > says where. I was not trying to compile NULL without a definition which I > agree it not legal. If that is what Doug was implying I missed understood > him but I note NULL was introduced in Typesetter C /V7 where those compiler > s set it to 0 in studio but the ANSI/ISO moved it. > > On Sun, Sep 20, 2020 at 7:03 PM Norman Wilson wrote: > >> Doug McIlroy: >> >> >> >> To put it more strongly. this is not a legal C source file. >> >> char *s = NULL; >> >> But this is. >> >> char *s = 0; >> >> >> >> Clem Cole: >> >> >> >> 67)The macro NULL is defined in (and other headers) as a >> null >> >> pointer constant; see 7.19. >> >> >> >> ==== >> >> >> >> $ cat null.c >> >> char *s = NULL; >> >> $ cat zero.c >> >> char *s = 0; >> >> $ >> >> >> >> zero.c is a legal C program. null.c is not. Create >> >> files exactly as shown and compile them if you don't >> >> believe me. >> >> >> >> Prepend `#include ' (or or ) >> >> to null.c and it becomes legal, but I think that's Doug's >> >> point: you need an include file. >> >> >> >> Personally I prefer to use NULL instead of 0 when spelling >> >> out a null pointer, because I think it's clearer: >> >> if ((buf = malloc(SIZE)) == NULL) >> >> error("dammit andrew"); >> >> though I am willing to omit it when there's no confusion >> >> about = vs ==: >> >> if (*p) >> >> dammit(*p, "andrew"); >> >> >> >> But that's just a question of style, and Doug's is fine too. >> >> >> >> The language does not require the compiler to pre-define >> >> NULL or to recognize it as a keyword; you have to include >> >> an appropriate standard header file. >> >> >> >> Norman Wilson >> >> Toronto ON (not 0N nor NULLN) >> >> -- > 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 imp at bsdimp.com Mon Sep 21 10:09:49 2020 From: imp at bsdimp.com (Warner Losh) Date: Sun, 20 Sep 2020 18:09:49 -0600 Subject: [TUHS] reviving a bit of WWB In-Reply-To: References: <20200920230057.C5D1A4422E@lignose.oclsc.org> Message-ID: To two places: stddef.h and stdlib.h :(. It's interesting to see the different bugs 0, 0L, (char *)0 and (void *)0 expose or hide as definitions of NULL. 0 is fine if sizeof(int) == sizeof(void *). Otherwise varadic function calls break. 0L is the same, but for long. The pointer definitions run into trouble in other contexts since NULL is often incorrectly used as a terminating byte in a string instead of '\0'. (void *) has issues with const pointers, some of which are relevant if you use it in the wrong context. There were quite spirited debates back in the day for which one was best. They all suck. C++ invented a null pointer symbol because it's type rules were enough different than C to make a universal NULL #define impossible. Is that better or worse? Don't know. It's different. Glad to see the null-pointer need not have all zero bits being different than a 0 constant shall be the null-pointer in sufficient detail. Warner On Sun, Sep 20, 2020, 5:54 PM Clem Cole wrote: > Norman NULL has to be defined and I said that/showed it. The standard > says where. I was not trying to compile NULL without a definition which I > agree it not legal. If that is what Doug was implying I missed understood > him but I note NULL was introduced in Typesetter C /V7 where those compiler > s set it to 0 in studio but the ANSI/ISO moved it. > > On Sun, Sep 20, 2020 at 7:03 PM Norman Wilson wrote: > >> Doug McIlroy: >> >> >> >> To put it more strongly. this is not a legal C source file. >> >> char *s = NULL; >> >> But this is. >> >> char *s = 0; >> >> >> >> Clem Cole: >> >> >> >> 67)The macro NULL is defined in (and other headers) as a >> null >> >> pointer constant; see 7.19. >> >> >> >> ==== >> >> >> >> $ cat null.c >> >> char *s = NULL; >> >> $ cat zero.c >> >> char *s = 0; >> >> $ >> >> >> >> zero.c is a legal C program. null.c is not. Create >> >> files exactly as shown and compile them if you don't >> >> believe me. >> >> >> >> Prepend `#include ' (or or ) >> >> to null.c and it becomes legal, but I think that's Doug's >> >> point: you need an include file. >> >> >> >> Personally I prefer to use NULL instead of 0 when spelling >> >> out a null pointer, because I think it's clearer: >> >> if ((buf = malloc(SIZE)) == NULL) >> >> error("dammit andrew"); >> >> though I am willing to omit it when there's no confusion >> >> about = vs ==: >> >> if (*p) >> >> dammit(*p, "andrew"); >> >> >> >> But that's just a question of style, and Doug's is fine too. >> >> >> >> The language does not require the compiler to pre-define >> >> NULL or to recognize it as a keyword; you have to include >> >> an appropriate standard header file. >> >> >> >> Norman Wilson >> >> Toronto ON (not 0N nor NULLN) >> >> -- > Sent from a handheld expect more typos than usual > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Mon Sep 21 11:05:23 2020 From: clemc at ccc.com (Clem Cole) Date: Sun, 20 Sep 2020 21:05:23 -0400 Subject: [TUHS] reviving a bit of WWB In-Reply-To: References: <20200920230057.C5D1A4422E@lignose.oclsc.org> Message-ID: Yep. They all suck. As Dennis said, “C is quirky” and part of the issue is HW is even more so. Clem On Sun, Sep 20, 2020 at 8:10 PM Warner Losh wrote: > To two places: stddef.h and stdlib.h :(. > > It's interesting to see the different bugs 0, 0L, (char *)0 and (void *)0 > expose or hide as definitions of NULL. > > 0 is fine if sizeof(int) == sizeof(void *). Otherwise varadic function > calls break. 0L is the same, but for long. The pointer definitions run into > trouble in other contexts since NULL is often incorrectly used as a > terminating byte in a string instead of '\0'. (void *) has issues with > const pointers, some of which are relevant if you use it in the wrong > context. > > There were quite spirited debates back in the day for which one was best. > They all suck. C++ invented a null pointer symbol because it's type rules > were enough different than C to make a universal NULL #define impossible. > Is that better or worse? Don't know. It's different. > > Glad to see the null-pointer need not have all zero bits being different > than a 0 constant shall be the null-pointer in sufficient detail. > > Warner > > On Sun, Sep 20, 2020, 5:54 PM Clem Cole wrote: > >> Norman NULL has to be defined and I said that/showed it. The standard >> says where. I was not trying to compile NULL without a definition which I >> agree it not legal. If that is what Doug was implying I missed understood >> him but I note NULL was introduced in Typesetter C /V7 where those compiler >> s set it to 0 in studio but the ANSI/ISO moved it. >> >> On Sun, Sep 20, 2020 at 7:03 PM Norman Wilson wrote: >> >>> Doug McIlroy: >>> >>> >>> >>> To put it more strongly. this is not a legal C source file. >>> >>> char *s = NULL; >>> >>> But this is. >>> >>> char *s = 0; >>> >>> >>> >>> Clem Cole: >>> >>> >>> >>> 67)The macro NULL is defined in (and other headers) as a >>> null >>> >>> pointer constant; see 7.19. >>> >>> >>> >>> ==== >>> >>> >>> >>> $ cat null.c >>> >>> char *s = NULL; >>> >>> $ cat zero.c >>> >>> char *s = 0; >>> >>> $ >>> >>> >>> >>> zero.c is a legal C program. null.c is not. Create >>> >>> files exactly as shown and compile them if you don't >>> >>> believe me. >>> >>> >>> >>> Prepend `#include ' (or or ) >>> >>> to null.c and it becomes legal, but I think that's Doug's >>> >>> point: you need an include file. >>> >>> >>> >>> Personally I prefer to use NULL instead of 0 when spelling >>> >>> out a null pointer, because I think it's clearer: >>> >>> if ((buf = malloc(SIZE)) == NULL) >>> >>> error("dammit andrew"); >>> >>> though I am willing to omit it when there's no confusion >>> >>> about = vs ==: >>> >>> if (*p) >>> >>> dammit(*p, "andrew"); >>> >>> >>> >>> But that's just a question of style, and Doug's is fine too. >>> >>> >>> >>> The language does not require the compiler to pre-define >>> >>> NULL or to recognize it as a keyword; you have to include >>> >>> an appropriate standard header file. >>> >>> >>> >>> Norman Wilson >>> >>> Toronto ON (not 0N nor NULLN) >>> >>> -- >> 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 cowan at ccil.org Mon Sep 21 12:24:17 2020 From: cowan at ccil.org (John Cowan) Date: Sun, 20 Sep 2020 22:24:17 -0400 Subject: [TUHS] reviving a bit of WWB In-Reply-To: References: <20200920230057.C5D1A4422E@lignose.oclsc.org> Message-ID: ISO requires that NULL be defined in locale.h, stddef.h, stdio.h, stdlib.h, string.h, time.h, wchar.h, and their C++ equivalents clocale etc.. It's pretty unlikely that you can write any useful code at all without NULL being defined as a side effect. On Sun, Sep 20, 2020 at 8:01 PM Clem Cole wrote: > I was also stating (under Henry’s 10th) using a properly defined macro > with the complete cast scheme will be correct and portable to all known > conforming C compilers no matter the target HW architecture — which in a > commercial SW setting is highly valued. > > Clem > > On Sun, Sep 20, 2020 at 7:53 PM Clem Cole wrote: > >> Norman NULL has to be defined and I said that/showed it. The standard >> says where. I was not trying to compile NULL without a definition which I >> agree it not legal. If that is what Doug was implying I missed understood >> him but I note NULL was introduced in Typesetter C /V7 where those compiler >> s set it to 0 in studio but the ANSI/ISO moved it. >> >> On Sun, Sep 20, 2020 at 7:03 PM Norman Wilson wrote: >> >>> Doug McIlroy: >>> >>> >>> >>> To put it more strongly. this is not a legal C source file. >>> >>> char *s = NULL; >>> >>> But this is. >>> >>> char *s = 0; >>> >>> >>> >>> Clem Cole: >>> >>> >>> >>> 67)The macro NULL is defined in (and other headers) as a >>> null >>> >>> pointer constant; see 7.19. >>> >>> >>> >>> ==== >>> >>> >>> >>> $ cat null.c >>> >>> char *s = NULL; >>> >>> $ cat zero.c >>> >>> char *s = 0; >>> >>> $ >>> >>> >>> >>> zero.c is a legal C program. null.c is not. Create >>> >>> files exactly as shown and compile them if you don't >>> >>> believe me. >>> >>> >>> >>> Prepend `#include ' (or or ) >>> >>> to null.c and it becomes legal, but I think that's Doug's >>> >>> point: you need an include file. >>> >>> >>> >>> Personally I prefer to use NULL instead of 0 when spelling >>> >>> out a null pointer, because I think it's clearer: >>> >>> if ((buf = malloc(SIZE)) == NULL) >>> >>> error("dammit andrew"); >>> >>> though I am willing to omit it when there's no confusion >>> >>> about = vs ==: >>> >>> if (*p) >>> >>> dammit(*p, "andrew"); >>> >>> >>> >>> But that's just a question of style, and Doug's is fine too. >>> >>> >>> >>> The language does not require the compiler to pre-define >>> >>> NULL or to recognize it as a keyword; you have to include >>> >>> an appropriate standard header file. >>> >>> >>> >>> Norman Wilson >>> >>> Toronto ON (not 0N nor NULLN) >>> >>> -- >> 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 usotsuki at buric.co Mon Sep 21 15:55:19 2020 From: usotsuki at buric.co (Steve Nickolas) Date: Mon, 21 Sep 2020 01:55:19 -0400 (EDT) Subject: [TUHS] reviving a bit of WWB In-Reply-To: References: <20200920230057.C5D1A4422E@lignose.oclsc.org> Message-ID: On Sun, 20 Sep 2020, Warner Losh wrote: > 0 is fine if sizeof(int) == sizeof(void *). Otherwise varadic function > calls break. I've never written anything that uses varargs, so I've never run into that. But I've actually done quite a bit of work with an environment where this isn't true: MS-DOS using the large or huge model. In this environment, sizeof(int)=2, and sizeof(void*) is 4. -uso. From imp at bsdimp.com Mon Sep 21 15:59:01 2020 From: imp at bsdimp.com (Warner Losh) Date: Sun, 20 Sep 2020 23:59:01 -0600 Subject: [TUHS] reviving a bit of WWB In-Reply-To: References: <20200920230057.C5D1A4422E@lignose.oclsc.org> Message-ID: On Sun, Sep 20, 2020, 11:55 PM Steve Nickolas wrote: > On Sun, 20 Sep 2020, Warner Losh wrote: > > > 0 is fine if sizeof(int) == sizeof(void *). Otherwise varadic function > > calls break. > > I've never written anything that uses varargs, so I've never run into > that. But I've actually done quite a bit of work with an environment > where this isn't true: MS-DOS using the large or huge model. In this > environment, sizeof(int)=2, and sizeof(void*) is 4. > Sizeof(int) == 4 and sizeof(void *) == 8 on LP64 platforms too... Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at rileyriot.com Mon Sep 21 20:26:58 2020 From: paul at rileyriot.com (Paul Riley) Date: Mon, 21 Sep 2020 18:26:58 +0800 Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems In-Reply-To: <20200919152835.4E73A18C0DD@mercury.lcs.mit.edu> References: <20200919152835.4E73A18C0DD@mercury.lcs.mit.edu> Message-ID: Noel, In the bootable images archive, there's the "Unknown V6" RL02 image. I've tried that on SimH configured as an 11/23+ with 256kB of RAM and it seems to work fine. It seems to be somewhat tweaked, as the shell accepts "cd" instead of "chdir" and I know the C compiler is happy with either "+=" or "=+". It seems to be reasonably complete (at least binaries I mean). I can't recall if the source files are there or not. I guess at least if I use LSX and V6 then they both are V6 based, which might minimize pain. I'd imagine stuff I write for the '23 would also then compile on the '03. I'll have some fun eventually on these machines with my home automation system. I've picked-up an RS-232 -> WiFi module on TaoBao (China's answer to eBay) and I'll implement a super-lightweight MQTT system to drive some stuff at home. (Think custom Christmas lights.) I would assume that Ethernet boards are available, but not supported on V6. Anyone else have an LSI machine at home? I'd be interested to know some fun stuff to do with it. Paul *Paul Riley* On Sat, 19 Sep 2020 at 23:28, Noel Chiappa wrote: > > From: Paul Riley > > > Is LSX the only option on the 11/03, or could I run V6 or Mini-Unix > with > > more RAM? > > All PDP-11 Unix versions from V4 on require the MMU, so the -11/03 is out > for > them. We don't have the code for V2-V4, though. So V1 (mostly all > assembler, > no C :-), LSW and Mini-Unix are the only options for it. > > V6 can be run on an -11/23 (I've done it), but not straight out of the box; > it requires a few minor tweaks first: > > http://gunkies.org/wiki/Running_UNIX_V6_on_an_-11/23 > > Noel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at rileyriot.com Mon Sep 21 23:54:34 2020 From: paul at rileyriot.com (Paul Riley) Date: Mon, 21 Sep 2020 21:54:34 +0800 Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems In-Reply-To: <4f09e601-b0a2-3574-aa03-132fc415da0e@osta.com> References: <4f09e601-b0a2-3574-aa03-132fc415da0e@osta.com> Message-ID: Heinz, Using LSX on the 11/03, what did you use for interaction with the outside world? The SLU of the time had only one port I believe, and that would be tied up with the console terminal. Will LSX handle cards with multiple serial ports? Was there a favoured digital or analog I/O board with some form of kernel support? Paul *Paul Riley* On Sat, 19 Sep 2020 at 22:22, Heinz Lycklama wrote: > I do believe that it would be easier to use LSX source code, > but I also know that some folks at universities were able > to modify the source for Mini-UNIX to run on 11/03 in > the mid-70's because of the two, only Mini-UNIX source > code was available to universities. > > Heinz > > On 9/18/2020 8:22 PM, Paul Riley wrote: > > > Team, > > I’ve read thru the FAQ and other sources regarding compatibility of > Research and other flavours on the PDP-11. I have two physical machines, an > 11/03 and an 11/23+. I’m choosing which version to use on each machine. > > Is LSX the only option on the 11/03, or could I run V6 or Mini-Unix with > more RAM? > > From the FAQ, it says V7 would support 11/23 with kernel recompilation, I > assume includes 11/23+. I see 2.11BSD would also run on a ‘23 (and + I > guess) with 1MB or more of RAM, so that would be preferred. I suppose 2.11 > would be preferable. > > I also have found another 11/23+ system from a seller here in China. > There’s the system, and a VT100, and a hard drive I can’t identify. Here’s > a photo, does anyone know what it is? I may bid for it... > > Paul > > *Paul Riley* > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From heinz at osta.com Tue Sep 22 01:30:42 2020 From: heinz at osta.com (Heinz Lycklama) Date: Mon, 21 Sep 2020 08:30:42 -0700 Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems In-Reply-To: References: <4f09e601-b0a2-3574-aa03-132fc415da0e@osta.com> Message-ID: <60d96d1d-5b34-c66d-5b5e-d23b054de9c9@osta.com> Interaction with the outside world on the first LSX system used standard DEC interfaces of the day - DLV-11 (serial) and DRV-11 (parallel), plus a specially designed interface card for a local device. The DLV-11 supported only one serial port in 1975. Other DEC interface devices may have been added to the Qbus after the mid 1970's. Heinz On 9/21/2020 6:54 AM, Paul Riley wrote: > Heinz, > > Using LSX on the 11/03, what did you use for interaction with the > outside world? The SLU of the time had only one port I believe, and > that would be tied up with the console terminal. Will LSX handle cards > with multiple serial ports? Was there a favoured digital or analog I/O > board with some form of kernel support? > > Paul > > *Paul Riley* > > > > > On Sat, 19 Sep 2020 at 22:22, Heinz Lycklama > wrote: > > I do believe that it would be easier to use LSX source code, > but I also know that some folks at universities were able > to modify the source for Mini-UNIX to run on 11/03 in > the mid-70's because of the two, only Mini-UNIX source > code was available to universities. > > Heinz > > On 9/18/2020 8:22 PM, Paul Riley wrote: >> >> Team, >> >> I’ve read thru the FAQ and other sources regarding compatibility >> of Research and other flavours on the PDP-11. I have two physical >> machines, an 11/03 and an 11/23+. I’m choosing which version to >> use on each machine. >> >> Is LSX the only option on the 11/03, or could I run V6 or >> Mini-Unix with more RAM? >> >> From the FAQ, it says V7 would support 11/23 with kernel >> recompilation, I assume includes 11/23+. I see 2.11BSD would also >> run on a ‘23 (and + I guess) with 1MB or more of RAM, so that >> would be preferred. I suppose 2.11 would be preferable. >> >> I also have found another 11/23+ system from a seller here in >> China. There’s the system, and a VT100, and a hard drive I can’t >> identify. Here’s a photo, does anyone know what it is? I may bid >> for it... >> >> Paul >> >> *Paul Riley* >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Tue Sep 22 03:59:57 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 21 Sep 2020 13:59:57 -0400 (EDT) Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems Message-ID: <20200921175957.84BF918C0ED@mercury.lcs.mit.edu> > From: Heinz Lycklama > The DLV-11 supported only one serial port in 1975. Other DEC interface > devices may have been added to the Qbus after the mid 1970's. The DLV11-J: http://gunkies.org/wiki/DLV11-J_asynchronous_serial_line_interface is basically 4 DLV11's rolled into a single dual-width card; that's definitely an option for Mini-Unix (which apparently supports up to 4 simultaneous users). They are program compatible with the DHV11, so the driver should 'just work'. The boards are readily available on eBait; 'glitchworks' (of this parish) sells replacement cables (quite good, I have several). Another option for serial lines on QBUS machines are DZ11 and DH11 versions for QBUS. (The DZ11 is interrupt-per-character on output; the DH11 is DMA on output.) There are two generations of each: the DZV11 (quad-width) and DZQ11 (dual-width), and DHV11 (quad) and DHQ11 (dual). I think they are pretty much program compatible with their UNIBUS brethren, and should be easy to get running. The boards are easy to find on eBait, the breakout panels are somewhat rarer (although there sre some DH ohes up at the moment). Noel From jnc at mercury.lcs.mit.edu Tue Sep 22 04:13:54 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 21 Sep 2020 14:13:54 -0400 (EDT) Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems Message-ID: <20200921181354.DC53E18C0F1@mercury.lcs.mit.edu> > They are program compatible with the DHV11 Argh; typo. 'DLV11'. Noel From krewat at kilonet.net Tue Sep 22 04:18:21 2020 From: krewat at kilonet.net (Arthur Krewat) Date: Mon, 21 Sep 2020 14:18:21 -0400 Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems In-Reply-To: <20200921175957.84BF918C0ED@mercury.lcs.mit.edu> References: <20200921175957.84BF918C0ED@mercury.lcs.mit.edu> Message-ID: <040e7827-b631-749e-28e1-3003dafabe4c@kilonet.net> On 9/21/2020 1:59 PM, Noel Chiappa wrote: > The DZ11 is interrupt-per-character on output I can vouch for that. I ran one at 19,200 on a KS10 to an Adds terminal I think... (after I modified the TOPS-10 6.03A monitor to add the option to SET TERM), and if I did an HT$$ in TECO of a large file, it would bring the system to it's knees. On the other hand, echo was a lot faster than the DCA ;) art k. From paul.winalski at gmail.com Tue Sep 22 04:40:10 2020 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 21 Sep 2020 14:40:10 -0400 Subject: [TUHS] reviving a bit of WWB In-Reply-To: References: <20200920230057.C5D1A4422E@lignose.oclsc.org> Message-ID: VAX/VMS was the first operating system I encountered where 0 was not a valid program address. As was mentioned previously, address space on early machines was too precious to throw away a whole page of it just to catch bad null pointer references. I once saw a C program that depended on 0 being a valid pointer address, and on a 0x00 byte being at memory address 0. The program had a bunch of char* pointers that were used in a printf() call, something like: printf("%s%s%s%s\n", a, b, c, d); If you didn't want, say, the third string printed, you assigned NULL to variable c. That caused c to point to location 0, and printf() interpreted the 0 byte as the empty string "". It was hell getting this program to work on the VAX. -Paul W. From jnc at mercury.lcs.mit.edu Tue Sep 22 05:37:28 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 21 Sep 2020 15:37:28 -0400 (EDT) Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems Message-ID: <20200921193728.7B84918C0F2@mercury.lcs.mit.edu> > From: Paul Riley > Using LSX on the 11/03... Will LSX handle cards with multiple serial > ports? Ah, I just read this carefully; LSX only supports a single user at a time, so there's no use to multiple serial lines? (But see below.) (I thought Heinz' reply message to this referred to Mini-Unix, which does suppport multiple users, but on reading it again I see it does not.) If you want multiple users on an -11/03, Mini-Unix would be an option; it doesn't support the -11/03 'out of the box', but looking at it, it shouldn't be too hard. (Heinz mentioned that it had been done before.) Change all cases of 'mov xx, PS' in mch.s: https://minnie.tuhs.org//cgi-bin/utree.pl?file=Mini-Unix/usr/sys/mxsys/mch.s to 'MTPS xx' (PS access needs a special instructtion in the /03); that might be all you need to do. (Installing a KEV11-A, so you can avoid using the instruction emulation package for EIS instructions would be nice, but apparently isn't required.) If Mini-Unix supports multiple users, it ought to be possible to do the same with LSX. (I'm not sure what the rationale was for making LSX single-user: perhaps the RX was too slow; perhaps there was no need in their use case; etc.) But it would probably be more work than going the Mini-Unix route; e.g. to start with, init only supports a single user: https://minnie.tuhs.org//cgi-bin/utree.pl?file=LSX/src/init.c and the tty driver: https://minnie.tuhs.org//cgi-bin/utree.pl?file=LSX/sys/tv.c only supports a single line. One could cross-port the needed 'stuff' from Mini-Unix, but it'd probably be easier to do the Mini-Unix -11/03 conversion. Noel From crossd at gmail.com Tue Sep 22 05:56:19 2020 From: crossd at gmail.com (Dan Cross) Date: Mon, 21 Sep 2020 15:56:19 -0400 Subject: [TUHS] reviving a bit of WWB In-Reply-To: References: <20200920230057.C5D1A4422E@lignose.oclsc.org> Message-ID: On Mon, Sep 21, 2020 at 2:40 PM Paul Winalski wrote: > VAX/VMS was the first operating system I encountered where 0 was not a > valid program address. As was mentioned previously, address space on > early machines was too precious to throw away a whole page of it just > to catch bad null pointer references. > > I once saw a C program that depended on 0 being a valid pointer > address, and on a 0x00 byte being at memory address 0. The program > had a bunch of char* pointers that were used in a printf() call, > something like: > > printf("%s%s%s%s\n", a, b, c, d); > > If you didn't want, say, the third string printed, you assigned NULL > to variable c. That caused c to point to location 0, and printf() > interpreted the 0 byte as the empty string "". > > It was hell getting this program to work on the VAX. That sounds annoying, but not necessarily insurmountable? I imagine you could wrap it in something like: void print4(char *a, char *b, char *c, char *d) { if (a == NULL) a = ""; if (b == NULL) b = ""; if (c == NULL) c = ""; if (d == NULL) d = ""; printf("%s%s%s%s\n", a, b, c, d); } ? I guess if it was more complex than that, like say being variadic, it'd be really annoying because you'd have to walk the arguments and accumulate them and assign pointers to empty strings as appropriate, or just wrap printf and interpret the format string. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Tue Sep 22 06:43:33 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 21 Sep 2020 22:43:33 +0200 Subject: [TUHS] reviving a bit of WWB In-Reply-To: References: <202009190151.08J1pYnb066792@tahoe.cs.dartmouth.edu> <202009201842.08KIgn2f022401@freefriends.org> <04211470-AD63-452A-A0BB-6A7A6FD85AAE@gmail.com> <202009202026.08KKQ2x6137303@tahoe.cs.dartmouth.edu> <202009202057.08KKvxAu141367@tahoe.cs.dartmouth.edu> Message-ID: <20200921204333.6NUeu%steffen@sdaoden.eu> Clem Cole wrote in : |On Sun, Sep 20, 2020 at 4:58 PM Doug McIlroy wrote: |> |> To put it more strongly. this is not a legal C source file. |> char *s = NULL; |> But this is. |> char *s = 0; |> | |Hmmm ... Doug - As the risk of playing language lawyer here, I'm going to |argue that between sections 6.3.2.3 and 7.19 the first is legal. You need to include the header file to compile it though. I guessed this is what he referred to? --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From steffen at sdaoden.eu Tue Sep 22 06:46:43 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 21 Sep 2020 22:46:43 +0200 Subject: [TUHS] reviving a bit of WWB In-Reply-To: References: <202009190151.08J1pYnb066792@tahoe.cs.dartmouth.edu> <202009201842.08KIgn2f022401@freefriends.org> <04211470-AD63-452A-A0BB-6A7A6FD85AAE@gmail.com> <202009202026.08KKQ2x6137303@tahoe.cs.dartmouth.edu> Message-ID: <20200921204643.A2XD6%steffen@sdaoden.eu> Steve Nickolas wrote in : |On Sun, 20 Sep 2020, Doug McIlroy wrote: | |>> (Of course, that assumes NULL is 0, but I don't think I've run into any |>> architecture so braindead as to not have NULL=0.) |> |> It has nothing to do with machine architecture. The C standard |> says 0 coerces to the null pointer. NULL, defined in , |> is part of the library, not the language. I always use 0, |> because NULL is a frill. |> |> Doug | |I was under the impression that there was explicitly no requirement that a |null pointer be 0, and that there was at least one weird system where that |wasn't true - that it just so happened that null points to 0 on certain |CPUs and that 0=NULL *happens* to work on most CPUs but wasn't guaranteed. |(In fact, I read that my habit of using 0 for NULL relied on a faulty |assumption!) | |I mean, I've never actually used a CPU/OS/compiler where it wasn't true, |but... I remember having to use __null for __GNUC__>=3 because 0x0 (what is used for my NIL macro before, this was C++) did not work out well. (Could have been compiler bug, of course .. but i just remembered it when reading your post.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From steffen at sdaoden.eu Tue Sep 22 06:48:48 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 21 Sep 2020 22:48:48 +0200 Subject: [TUHS] reviving a bit of WWB In-Reply-To: References: <202009190151.08J1pYnb066792@tahoe.cs.dartmouth.edu> <202009201842.08KIgn2f022401@freefriends.org> <04211470-AD63-452A-A0BB-6A7A6FD85AAE@gmail.com> <202009202026.08KKQ2x6137303@tahoe.cs.dartmouth.edu> Message-ID: <20200921204848.lbtLw%steffen@sdaoden.eu> John Cowan wrote in : |The confusion (I dare not call it a flame war) is arising out of the |difference between an object with all bits zero and a 0 constant (or |equivalently 2*0 or 3-3 or what not). 0 in pointer context is always a |null pointer, but it may or may not be all-bits-zero. 0 in integer context |is, on any sane machine, all-bits-zero (on 1's-complement machines it may |also be all-bits-one). | |Personally, when I was programming in C I defined a macro #define |NULLPTR(t) ((t)0), so that I would write NULLPTR(char *) or NULLPTR(int *) |or whatever the Right Thing was. And i think too that POSIX is about to define this explicitly in the future (regarding all bits zero). --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 Tue Sep 22 06:50:14 2020 From: cowan at ccil.org (John Cowan) Date: Mon, 21 Sep 2020 16:50:14 -0400 Subject: [TUHS] reviving a bit of WWB In-Reply-To: References: <20200920230057.C5D1A4422E@lignose.oclsc.org> Message-ID: On Mon, Sep 21, 2020 at 1:55 AM Steve Nickolas wrote: > I've never written anything that uses varargs, so I've never run into > that. But I've actually done quite a bit of work with an environment > where this isn't true: MS-DOS using the large or huge model. In this > environment, sizeof(int)=2, and sizeof(void*) is 4. Of course, it's not > conformant to pass an int variable as an argument where a pointer variable > is expected. > If the compiler was ISO-conformant (which it almost certainly was not), that would not matter. 0 in int context would be a 2-byte int with all bits zero, and 0 in pointer context would be a 4-byte null pointer, probably with all bits zero. C doesn't require that the address represented by the null pointer (whether or not it is all-bits-zero) is inaccessible, merely that there is no C object or function there. A simple shim of the appropriate size (1, 2, 4, 8 bytes depending on the CPU's alignment rules) will suffice. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Tue Sep 22 07:22:08 2020 From: robpike at gmail.com (Rob Pike) Date: Tue, 22 Sep 2020 07:22:08 +1000 Subject: [TUHS] reviving a bit of WWB In-Reply-To: References: <20200920230057.C5D1A4422E@lignose.oclsc.org> Message-ID: Back when we were running v5 at the University of Toronto, we had a graphics device that we accessed, on our split I&D space 11/45, using 0, something like this: struct x { int reg0, reg1, ...; }; 0->reg1 = 0234; Several old details of old C made this possible as well: Struct tags were global, -> worked on any pointer, and ints and pointers were interchangeable. -rob On Tue, Sep 22, 2020 at 6:51 AM John Cowan wrote: > > > On Mon, Sep 21, 2020 at 1:55 AM Steve Nickolas wrote: > > >> I've never written anything that uses varargs, so I've never run into >> that. But I've actually done quite a bit of work with an environment >> where this isn't true: MS-DOS using the large or huge model. In this >> environment, sizeof(int)=2, and sizeof(void*) is 4. Of course, it's not >> conformant to pass an int variable as an argument where a pointer variable >> is expected. >> > > If the compiler was ISO-conformant (which it almost certainly was not), > that would not matter. 0 in int context would be a 2-byte int with all > bits zero, and 0 in pointer context would be a 4-byte null pointer, > probably with all bits zero. > > C doesn't require that the address represented by the null pointer > (whether or not it is all-bits-zero) is inaccessible, merely that there is > no C object or function there. A simple shim of the appropriate size (1, > 2, 4, 8 bytes depending on the CPU's alignment rules) will suffice. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From usotsuki at buric.co Tue Sep 22 07:39:42 2020 From: usotsuki at buric.co (Steve Nickolas) Date: Mon, 21 Sep 2020 17:39:42 -0400 (EDT) Subject: [TUHS] reviving a bit of WWB In-Reply-To: References: <20200920230057.C5D1A4422E@lignose.oclsc.org> Message-ID: On Mon, 21 Sep 2020, John Cowan wrote: > On Mon, Sep 21, 2020 at 1:55 AM Steve Nickolas wrote: > > >> I've never written anything that uses varargs, so I've never run into >> that. But I've actually done quite a bit of work with an environment >> where this isn't true: MS-DOS using the large or huge model. In this >> environment, sizeof(int)=2, and sizeof(void*) is 4. Of course, it's not >> conformant to pass an int variable as an argument where a pointer variable >> is expected. >> > > If the compiler was ISO-conformant (which it almost certainly was not), > that would not matter. 0 in int context would be a 2-byte int with all > bits zero, and 0 in pointer context would be a 4-byte null pointer, > probably with all bits zero. The compiler I used at least tried to be C89. (Borland Turbo C++ 1.01) > C doesn't require that the address represented by the null pointer (whether > or not it is all-bits-zero) is inaccessible, merely that there is no C > object or function there. A simple shim of the appropriate size (1, 2, 4, > 8 bytes depending on the CPU's alignment rules) will suffice. Which was nice with the tiny model: a .COM file organized at near 0x0100, and iirc, there was guaranteed to be 0xCD 0x20 at 0x0000. (The 8086 "INT 20H" instruction. I just checked in DOSEMU with PC DOS 7, and that is exactly what shows up there.) "ANSI C" doesn't mean a lot though when 95% of the code I run across uses extensions. I still have not successfully kitbashed the Bourne shell onto native DOS, OS/2 or Windows without an emulation layer - in any form. Did come *pretty* close with the Forsyth shell but I couldn't work around the lack of fork() (OS/2 does have a near-exact counterpart for pipe(), but it's not exposed by the pipe() call for some reason.) I like my Unix shells even on Microsoft OSes...call me crazy. ;) -uso. From clemc at ccc.com Tue Sep 22 07:57:00 2020 From: clemc at ccc.com (Clem Cole) Date: Mon, 21 Sep 2020 17:57:00 -0400 Subject: [TUHS] reviving a bit of WWB In-Reply-To: References: <20200920230057.C5D1A4422E@lignose.oclsc.org> Message-ID: Right .. I remember running into/using that idiom in a couple of places in a few other drivers in the early years. I also remember working one of the CAD tools (it may have been one of the UCB CAD editors) which were very graphics centric and running into it there. I always looked at this as part of the original C heritage from simpler times *i.e.* from ESPOL/BCPL/B and the like, when it was still considered a 'low level' language that mapped well to the HW at hand. As the more and more features got added, the focus of the language changed ... ney Chisnall's 2018 screed: C is not a low level language Not nearly as bad as the pile we got with 'modern' C++ [which I'm loath to use]. Clem On Mon, Sep 21, 2020 at 5:23 PM Rob Pike wrote: > Back when we were running v5 at the University of Toronto, we had a > graphics device that we accessed, on our split I&D space 11/45, using 0, > something like this: > > struct x { > int reg0, reg1, ...; > }; > > 0->reg1 = 0234; > > Several old details of old C made this possible as well: Struct tags were > global, -> worked on any pointer, and ints and pointers were > interchangeable. > > -rob > > > On Tue, Sep 22, 2020 at 6:51 AM John Cowan wrote: > >> >> >> On Mon, Sep 21, 2020 at 1:55 AM Steve Nickolas wrote: >> >> >>> I've never written anything that uses varargs, so I've never run into >>> that. But I've actually done quite a bit of work with an environment >>> where this isn't true: MS-DOS using the large or huge model. In this >>> environment, sizeof(int)=2, and sizeof(void*) is 4. Of course, it's not >>> conformant to pass an int variable as an argument where a pointer variable >>> is expected. >>> >> >> If the compiler was ISO-conformant (which it almost certainly was not), >> that would not matter. 0 in int context would be a 2-byte int with all >> bits zero, and 0 in pointer context would be a 4-byte null pointer, >> probably with all bits zero. >> >> C doesn't require that the address represented by the null pointer >> (whether or not it is all-bits-zero) is inaccessible, merely that there is >> no C object or function there. A simple shim of the appropriate size (1, >> 2, 4, 8 bytes depending on the CPU's alignment rules) will suffice. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From lyokoboy0 at gmail.com Tue Sep 22 09:16:15 2020 From: lyokoboy0 at gmail.com (devin davison) Date: Mon, 21 Sep 2020 19:16:15 -0400 Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems In-Reply-To: <20200921193728.7B84918C0F2@mercury.lcs.mit.edu> References: <20200921193728.7B84918C0F2@mercury.lcs.mit.edu> Message-ID: Nice find. What does the label on the big hard drive read? I have found a similar drive with a worn label and i am trying to see if i can find a system to connect it to. On Mon, Sep 21, 2020, 3:38 PM Noel Chiappa wrote: > > From: Paul Riley > > > Using LSX on the 11/03... Will LSX handle cards with multiple serial > > ports? > > Ah, I just read this carefully; LSX only supports a single user at a time, > so > there's no use to multiple serial lines? (But see below.) (I thought Heinz' > reply message to this referred to Mini-Unix, which does suppport multiple > users, but on reading it again I see it does not.) > > > If you want multiple users on an -11/03, Mini-Unix would be an option; it > doesn't support the -11/03 'out of the box', but looking at it, it > shouldn't > be too hard. (Heinz mentioned that it had been done before.) Change all > cases > of 'mov xx, PS' in mch.s: > > > https://minnie.tuhs.org//cgi-bin/utree.pl?file=Mini-Unix/usr/sys/mxsys/mch.s > > to 'MTPS xx' (PS access needs a special instructtion in the /03); that > might > be all you need to do. (Installing a KEV11-A, so you can avoid using the > instruction emulation package for EIS instructions would be nice, but > apparently isn't required.) > > > If Mini-Unix supports multiple users, it ought to be possible to do the > same > with LSX. (I'm not sure what the rationale was for making LSX single-user: > perhaps the RX was too slow; perhaps there was no need in their use case; > etc.) > > But it would probably be more work than going the Mini-Unix route; e.g. > to start with, init only supports a single user: > > https://minnie.tuhs.org//cgi-bin/utree.pl?file=LSX/src/init.c > > and the tty driver: > > https://minnie.tuhs.org//cgi-bin/utree.pl?file=LSX/sys/tv.c > > only supports a single line. One could cross-port the needed 'stuff' from > Mini-Unix, but it'd probably be easier to do the Mini-Unix -11/03 > conversion. > > Noel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Tue Sep 22 09:27:55 2020 From: henry.r.bent at gmail.com (Henry Bent) Date: Mon, 21 Sep 2020 19:27:55 -0400 Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 at 23:24, Paul Riley wrote: > > Team, > > I’ve read thru the FAQ and other sources regarding compatibility of > Research and other flavours on the PDP-11. I have two physical machines, an > 11/03 and an 11/23+. I’m choosing which version to use on each machine. > > Is LSX the only option on the 11/03, or could I run V6 or Mini-Unix with > more RAM? > > From the FAQ, it says V7 would support 11/23 with kernel recompilation, I > assume includes 11/23+. I see 2.11BSD would also run on a ‘23 (and + I > guess) with 1MB or more of RAM, so that would be preferred. I suppose 2.11 > would be preferable. > > I also have found another 11/23+ system from a seller here in China. > There’s the system, and a VT100, and a hard drive I can’t identify. Here’s > a photo, does anyone know what it is? I may bid for it... > > Paul > > *Paul Riley* > Ultrix 3.1 should support the 11/23+, which would give you memory support up to 4MB as well as support for TCP/IP if you have a DEQNA. I don't think 2.11BSD will run on anything without split I/D which the 23 does not have. Without a closer view of the label I doubt that anyone could give you a definite identification of that hard drive. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Tue Sep 22 09:56:14 2020 From: cowan at ccil.org (John Cowan) Date: Mon, 21 Sep 2020 19:56:14 -0400 Subject: [TUHS] reviving a bit of WWB In-Reply-To: References: <20200920230057.C5D1A4422E@lignose.oclsc.org> Message-ID: On Mon, Sep 21, 2020 at 5:57 PM Clem Cole wrote: > As the more and more features got added, the focus of the language changed > ... ney Chisnall's 2018 screed: C is not a low level language > > Rereading that made me wonder: if someone retargeted an old compiler (pcc, say) to produce i386 code, how much faster would it run than a VAX? I see that there is a pcc derivative at , but supposedly it has been heavily rewritten for C99 compliance and other things. Not nearly as bad as the pile we got with 'modern' C++ [which I'm loath to > use]. > You should be. It's loathsome. :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Tue Sep 22 10:22:35 2020 From: henry.r.bent at gmail.com (Henry Bent) Date: Mon, 21 Sep 2020 20:22:35 -0400 Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems In-Reply-To: <4C35E6D2-8ABD-4DC2-BB2F-F15FA5BF30DD@icloud.com> References: <4C35E6D2-8ABD-4DC2-BB2F-F15FA5BF30DD@icloud.com> Message-ID: You're welcome. Other theoretical alternatives are one of the later 2.9BSD patches, though I have had no success getting those to run on anything, and maybe BRL UNIX from the CSRG DVD? I would appreciate hearing from anyone who has tried to get BRL UNIX running. -Henry On Mon, 21 Sep 2020 at 19:36, Paul Riley wrote: > Thanks Henry, that’s an interesting alternative. > > I’m trying to get a photo of the drive label. > > Paul > > Sent from my iPhone > > On 22 Sep 2020, at 7:28 am, Henry Bent wrote: > >  > On Fri, 18 Sep 2020 at 23:24, Paul Riley wrote: > >> >> Team, >> >> I’ve read thru the FAQ and other sources regarding compatibility of >> Research and other flavours on the PDP-11. I have two physical machines, an >> 11/03 and an 11/23+. I’m choosing which version to use on each machine. >> >> Is LSX the only option on the 11/03, or could I run V6 or Mini-Unix with >> more RAM? >> >> From the FAQ, it says V7 would support 11/23 with kernel recompilation, I >> assume includes 11/23+. I see 2.11BSD would also run on a ‘23 (and + I >> guess) with 1MB or more of RAM, so that would be preferred. I suppose 2.11 >> would be preferable. >> >> I also have found another 11/23+ system from a seller here in China. >> There’s the system, and a VT100, and a hard drive I can’t identify. Here’s >> a photo, does anyone know what it is? I may bid for it... >> >> Paul >> >> *Paul Riley* >> > > Ultrix 3.1 should support the 11/23+, which would give you memory support > up to 4MB as well as support for TCP/IP if you have a DEQNA. I don't think > 2.11BSD will run on anything without split I/D which the 23 does not have. > > Without a closer view of the label I doubt that anyone could give you a > definite identification of that hard drive. > > -Henry > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Tue Sep 22 10:47:19 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 21 Sep 2020 20:47:19 -0400 (EDT) Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems Message-ID: <20200922004719.6E65418C0ED@mercury.lcs.mit.edu> > From: Paul Riley >> the tty driver: >> >> https://minnie.tuhs.org//cgi-bin/utree.pl?file=LSX/sys/tv.c >> >> only supports a single line. > The second serial port would not be to support another user, but to > communicate with peripherals. Ah. Well, AIX will still have an issue (above). Noel From rich.salz at gmail.com Tue Sep 22 10:54:12 2020 From: rich.salz at gmail.com (Richard Salz) Date: Mon, 21 Sep 2020 20:54:12 -0400 Subject: [TUHS] reviving a bit of WWB In-Reply-To: References: <20200920230057.C5D1A4422E@lignose.oclsc.org> Message-ID: Getting back to the original topic, would this port/refresh of WWB include style&diction and be redistributable? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Wed Sep 23 01:59:43 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 22 Sep 2020 11:59:43 -0400 (EDT) Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems Message-ID: <20200922155943.EF32A18C09D@mercury.lcs.mit.edu> > From: Paul Riley > In the bootable images archive, there's the "Unknown V6" RL02 > image. I've tried that on SimH configured as an 11/23+ with 256kB of RAM > and it seems to work fine. Sorry, where's this archive? Somewhere in: https://www.tuhs.org/Archive/Distributions/Research/ I assume? From the description, that might be from the 'Shoppa disks'; didn't realize that was a /23 on those. > I would assume that Ethernet boards are available, but not supported on > V6. V6, as distributed, had no networking at all. There are two V6 systems with networking in TUHS: https://minnie.tuhs.org//cgi-bin/utree.pl?file=SRI-NOSC https://minnie.tuhs.org//cgi-bin/utree.pl?file=BBN-V6 The first is an 'NCP' Unix (unless unless you have an ARPANet); the second is a fairly early TCP/IP from BBN (ditto, out of the box; although one could write an Ethernet driver for it). There's also a fairly nice Internet-capable V6 (well, PWB1, actually) from MIT which I keep meaning to upload; it includes SMTP, FTP, etc, etc. I also have visions of porting an ARP I wrote to it, and bringing up an Ethernet driver for the DEQNA/DELQA, but I've yet to get to any of that. > it's hard to glean that wisdom from reading the manual. Yeah, DEC manuals went through a phase-change around about the time of the /23. Old DEC manuals are wonderful; stuffed to the gills with deep technical details. Suitable for engineers... Later, they turned into manuals for 'ordinary people' - 'plug cable C1 into plug P1'. Semi-useless; although one can often glean a few useful morsels if you trawl through the entire thing. That's why I've been doing PDP-11 pages on the CHWiki which attempt to cover a lot of technical detail, in a high technical content/size way. If you need something that's not there, let me know, and I'll get to adding it. Noel From jnc at mercury.lcs.mit.edu Wed Sep 23 07:36:11 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 22 Sep 2020 17:36:11 -0400 (EDT) Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems Message-ID: <20200922213611.6AFEE18C0B4@mercury.lcs.mit.edu> > If you want multiple users on an -11/03, Mini-Unix would be an option; > zit doesn't support the -11/03 'out of the box', but looking at it, it > shouldn't be too hard. (Heinz mentioned that it had been done before.) On thinking about it, I might do the -11/03 port of Mini-Unix for the hack value; it looks like it should be a quick project (a couple of hours, much of which would be getting Mini-Unix set up; I'd use a simulator, my QBUS RK11 emulator is broken at the moment). I think it should mostly just be some fairly straight-forward changes to mch.s; I think all the C code would be fine. (Unless there's an 'PS->integ' or something hiding somewhere.) Also a few odds and ends, like a software console switch register (been there, done that). That would make the full power of Mini-Unix available to people with -11/03's; those are still fairly common, and reasonably cheap. (Unlike -11/05's.) It's a considerably more capable system than LSX: e.g. the tty driver is the full V6 one, and supports an arbitrary number of devices. So my question is: had anyone else already done this (I don't want to waste time replicating already-done work)? Also, would anyone have a use for it if I did it? If so, I'll put it up on a Web page when I'm done. (No, I _don't_ use Guthub, and have zero interest in learning how. I'd rather spend my remaining un-comitted neurons improving my ability to read feudal Japanese.) Noel From imp at bsdimp.com Wed Sep 23 07:46:22 2020 From: imp at bsdimp.com (Warner Losh) Date: Tue, 22 Sep 2020 15:46:22 -0600 Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems In-Reply-To: <20200922213611.6AFEE18C0B4@mercury.lcs.mit.edu> References: <20200922213611.6AFEE18C0B4@mercury.lcs.mit.edu> Message-ID: On Tue, Sep 22, 2020 at 3:37 PM Noel Chiappa wrote: > > If you want multiple users on an -11/03, Mini-Unix would be an > option; > > zit doesn't support the -11/03 'out of the box', but looking at it, > it > > shouldn't be too hard. (Heinz mentioned that it had been done > before.) > > On thinking about it, I might do the -11/03 port of Mini-Unix for the hack > value; it looks like it should be a quick project (a couple of hours, much > of > which would be getting Mini-Unix set up; I'd use a simulator, my QBUS RK11 > emulator is broken at the moment). > > I think it should mostly just be some fairly straight-forward changes to > mch.s; I think all the C code would be fine. (Unless there's an > 'PS->integ' or > something hiding somewhere.) Also a few odds and ends, like a software > console > switch register (been there, done that). > > That would make the full power of Mini-Unix available to people with > -11/03's; > those are still fairly common, and reasonably cheap. (Unlike -11/05's.) > It's a > considerably more capable system than LSX: e.g. the tty driver is the full > V6 > one, and supports an arbitrary number of devices. > > > So my question is: had anyone else already done this (I don't want to waste > time replicating already-done work)? Also, would anyone have a use for it > if I > did it? If so, I'll put it up on a Web page when I'm done. (No, I _don't_ > use > Guthub, and have zero interest in learning how. I'd rather spend my > remaining > un-comitted neurons improving my ability to read feudal Japanese.) > There's several references to different miniunix patches in the AUSAM newletters... Any chance those are still around? They don't seem to be in the TUHS AUSAM archives, though... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfoust at threedee.com Wed Sep 23 07:49:10 2020 From: jfoust at threedee.com (John Foust) Date: Tue, 22 Sep 2020 16:49:10 -0500 Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems In-Reply-To: <20200922213611.6AFEE18C0B4@mercury.lcs.mit.edu> References: <20200922213611.6AFEE18C0B4@mercury.lcs.mit.edu> Message-ID: <20200922221015.36FEA9CE8A@minnie.tuhs.org> At 04:36 PM 9/22/2020, Noel Chiappa wrote: >On thinking about it, I might do the -11/03 port of Mini-Unix for the hack >value; it looks like it should be a quick project (a couple of hours, much of >which would be getting Mini-Unix set up; I'd use a simulator, my QBUS RK11 >emulator is broken at the moment). There was one for the Terak (an 11/03) in May 1979 but I've never found a copy. See page 14... https://conservancy.umn.edu/bitstream/handle/11299/159028/UCC_Special%20_Issue_May_1979.pdf?sequence=1&isAllowed=y - John From jfoust at threedee.com Wed Sep 23 07:51:50 2020 From: jfoust at threedee.com (John Foust) Date: Tue, 22 Sep 2020 16:51:50 -0500 Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems Message-ID: <20200922221015.53FF29CBCA@minnie.tuhs.org> I wrote: >There was one for the Terak (an 11/03) in May 1979 but I've never found a copy. I take it back... Mark Riordan has a copy and some docs... http://www.60bits.net/msu/mycomp/terak/termedia.htm - John From jschauma at netmeister.org Thu Sep 24 09:06:46 2020 From: jschauma at netmeister.org (Jan Schaumann) Date: Wed, 23 Sep 2020 19:06:46 -0400 Subject: [TUHS] Origin of Charlie Root Message-ID: <20200923230646.GA20235@netmeister.org> Hello, Perhaps this has been discussed here before, but I couldn't find a definitive answer as to the origin of "Charlie Root". https://www.geeklan.co.uk/?p=2457 includes links to some of the /etc/passwd files from 4.1cBSD, 4.2BSD, and 2.9BSD, where we see root changing from being "The Man" to "Charlie &". Speculations on the internet about Charlie Root the baseball player are easy enough to find, but no confirmation or official origin story. So I thought I'd ask here: who can (authoritatively) shed light on how we ended up with Charlie Root? -Jan From jnc at mercury.lcs.mit.edu Thu Sep 24 09:14:27 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 23 Sep 2020 19:14:27 -0400 (EDT) Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems Message-ID: <20200923231427.8EB4818C09C@mercury.lcs.mit.edu> > From: John Foust > Mark Riordan has a copy and some docs... > http://www.60bits.net/msu/mycomp/terak/termedia.htm Alas, the only thing online there is a list of which floppies he had, not any actual content (other than one document). I've sent him an email (at the address given on that site), we'll see if I get a reply. He might not have a way to read those floppies... If not, no biggie; in asking I more wanted to make sure I wasn't wasting my time, I don't really need him to come through. Having done the /40->/23 move, I'm sure the /05->/03 move won't present any major problems. BTW, looking around for a copy of a document he mentioned, I found this: http://www.tavi.co.uk/unixhistory/mini-unix.html so between them and the stuff at TUHS, I think we have everything we'd need. Noel From cowan at ccil.org Thu Sep 24 10:10:12 2020 From: cowan at ccil.org (John Cowan) Date: Wed, 23 Sep 2020 20:10:12 -0400 Subject: [TUHS] Origin of Charlie Root In-Reply-To: <20200923230646.GA20235@netmeister.org> References: <20200923230646.GA20235@netmeister.org> Message-ID: On Wed, Sep 23, 2020 at 7:13 PM Jan Schaumann wrote: So I thought I'd ask here: who can (authoritatively) > shed light on how we ended up with Charlie Root? > I have no idea, but I remembered this, part of the message sent by an archive server when you send it an email saying "help": The archive server does not respond to requests from users named "root", "system", "daemon", or "mailer". This is to prevent mail loops. If your name is "Bruce Root" or "Joe Daemon", and you can document this, I will happily rewrite the server to remove this restriction. Yes, I know about Norman Mailer and Waverley Root. Norman doesn't use netmail and Waverley is dead. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org The known is finite, the unknown infinite; intellectually we stand on an islet in the midst of an illimitable ocean of inexplicability. Our business in every generation is to reclaim a little more land, to add something to the extent and the solidity of our possessions. --Thomas Henry Huxley -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfoust at threedee.com Thu Sep 24 11:09:57 2020 From: jfoust at threedee.com (John Foust) Date: Wed, 23 Sep 2020 20:09:57 -0500 Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems In-Reply-To: <20200923231427.8EB4818C09C@mercury.lcs.mit.edu> References: <20200923231427.8EB4818C09C@mercury.lcs.mit.edu> Message-ID: <20200924012528.07C4C9CC8C@minnie.tuhs.org> At 06:14 PM 9/23/2020, Noel Chiappa wrote: >I've sent him an email (at the >address given on that site), we'll see if I get a reply. He might not have a >way to read those floppies... He's in Madison, WI and I'm not far from him. None of my Teraks are working (although I have a dozen or so.) I've tinkered with finding another way to read the 8" floppies, as I'd like to archive my collection. - John From jnc at mercury.lcs.mit.edu Thu Sep 24 11:28:15 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 23 Sep 2020 21:28:15 -0400 (EDT) Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems Message-ID: <20200924012815.1FC1E18C099@mercury.lcs.mit.edu> > Would also be great if supported RL02 drives. ;) _Support_ for RL02's will not be a problem (but there are probably some issues - see below). I have an RL11 driver for V6, which will be easy to include in a system build. There is also a RL V6 boostrap (which lives in block 0 - it loads the OS from a V6 filesystem); how to load it off the RL pack on actual hardware, I'm not sure; do you have some PROM device that has an RL bootstrap in it? Or do you have some other drive which is going to be your boot device? If not, how are you going to get the bits onto an RL pack? This was a bit of an issue for Fritz Muelller with his -11/45 (with an RK05 drive); he finally wound up having to load it over a serial line, which took several hours. He used something called PDP11GUI, and you're in luck, that does support RL02's. Also, I'm not sure if you've had any experience with an old removable-pack drive. If not, you have to be very careful with them; if you have a head crash, the heads are now unobtainium, so a head crash will turn the drive into junk. (Which is a big part of why Dave Bridgham and I are doing to QSIC RK11 emulator...) The packs need to be absolutely clean; a number of people have experience with them, you should probably qget some lessons from them before trying to use it. > I'd imagine the V6 TTY driver would support boards with multiple serial > ports. Guess that's what's needed for multi user access. The TTY code in V6 consists of two levels of driver. The bottom layer is a driver which is specific to the particular type of card one's using; DL-11, DZ-11, etc. If the card supports multiple lines, that driver will too. Then there's a layer above that, tty.c, which the low-level driver uses to interace to the OS; the user talks to that. That layer is multi-line. Noel From dave at horsfall.org Thu Sep 24 12:25:32 2020 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 24 Sep 2020 12:25:32 +1000 (EST) Subject: [TUHS] reviving a bit of WWB In-Reply-To: References: <202009190151.08J1pYnb066792@tahoe.cs.dartmouth.edu> <202009201842.08KIgn2f022401@freefriends.org> <04211470-AD63-452A-A0BB-6A7A6FD85AAE@gmail.com> Message-ID: On Sun, 20 Sep 2020, Steve Nickolas wrote: > (Of course, that assumes NULL is 0, but I don't think I've run into any > architecture so braindead as to not have NULL=0.) I don't remember the details mow, but I recall an architecture where NULL was -0... Turing save us from 1-complement machines! -- Dave From clemc at ccc.com Thu Sep 24 12:33:38 2020 From: clemc at ccc.com (Clem Cole) Date: Wed, 23 Sep 2020 22:33:38 -0400 Subject: [TUHS] reviving a bit of WWB In-Reply-To: References: <202009190151.08J1pYnb066792@tahoe.cs.dartmouth.edu> <202009201842.08KIgn2f022401@freefriends.org> <04211470-AD63-452A-A0BB-6A7A6FD85AAE@gmail.com> Message-ID: Dave: Seymour used ones complement on the 3000 and 6000 series. Maybe there? The primary HLLs I used on the CDC boxes were FTN and Pascal, but I would not be surprised if that was were you saw it. On Wed, Sep 23, 2020 at 10:26 PM Dave Horsfall wrote: > On Sun, 20 Sep 2020, Steve Nickolas wrote: > > > (Of course, that assumes NULL is 0, but I don't think I've run into any > > architecture so braindead as to not have NULL=0.) > > I don't remember the details mow, but I recall an architecture where NULL > was -0... Turing save us from 1-complement machines! > > -- Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Thu Sep 24 21:02:53 2020 From: pnr at planet.nl (Paul Ruizendaal) Date: Thu, 24 Sep 2020 13:02:53 +0200 Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems Message-ID: <3D6D5DB5-A500-470F-868D-A49F80B617E6@planet.nl> > V6, as distributed, had no networking at all. There are two V6 systems with > networking in TUHS: > > https://minnie.tuhs.org//cgi-bin/utree.pl?file=SRI-NOSC > https://minnie.tuhs.org//cgi-bin/utree.pl?file=BBN-V6 > > The first is an 'NCP' Unix (unless unless you have an ARPANet); the second is > a fairly early TCP/IP from BBN (ditto, out of the box; although one could write > an Ethernet driver for it). I’ve also done a port of the BBN VAX stack to V6 (running on a TI990 clone), using a serial PPP interface to connect. Experimental, but may have the OP's interest: https://www.jslite.net/cgi-bin/9995/dir?ci=tip > There's also a fairly nice Internet-capable V6 (well, PWB1, actually) from MIT > which I keep meaning to upload; it includes SMTP, FTP, etc, etc. I also have > visions of porting an ARP I wrote to it, and bringing up an Ethernet driver > for the DEQNA/DELQA, but I've yet to get to any of that. I’d love to have a look at that and compare and contrast the approaches. I’m finding that BBN’s original design, with a separate kernel thread for the network stack, is elegant but difficult to tune: too much priority and it crowds out user processes, too little and the slow PPP line is not kept busy. I think I’m beginning to understand why CSRG (and later also BBN) moved to the interrupt driven structure of 4.2BSD: perhaps it was also difficult to tune for a VAX with ethernet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Thu Sep 24 23:04:02 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 24 Sep 2020 09:04:02 -0400 (EDT) Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems Message-ID: <20200924130402.EDE4718C09F@mercury.lcs.mit.edu> > From: Paul Riley > On my physical '03 I have twin Sykes floppy drives. I note that in the > LSX archives there is a Sykes driver, so I can adapt that I guess. Yes, here: https://www.tuhs.org/cgi-bin/utree.pl?file=LSX/sys/sykfd.c It looks like it should be a straight drop-in, to run it on Mini-Unix. Not sure if your controller is the exact same model, though? Is there any documentation on yours? (I haven't done any searching.) If you want to boot from it, you'll need to write a bootstrap for it; I poked around, but didn't see one. (Not sure how they booted machines with one, back in the day; maybe it wasn't the only drive, and they booted off something else.) You can probably modify the RX one: https://www.tuhs.org/cgi-bin/utree.pl?file=LSX/src/rxboot.s https://www.tuhs.org/cgi-bin/utree.pl?file=LSX/src/rxboot2.s Note that this is a 2-stage bootstrap, apparently as a result of the small hardware block size on the RX. And of course there's still the issue of 'how to get bits onto it'. Can floppies for it be written on some other kind of machine? If so, someone on the Classic Computers list: http://www.classiccmp.org/mailman/listinfo/cctalk may be able to help you write those, or an RL02 pack. You should start by getting some experience building V6 OS loads (Mini-Unix will be _very_ similar); use a simulator. I have a lengthy tutorial here: http://www.chiappa.net/~jnc/tech/V6Unix.html It's in terms of Ersatz-11, which I prefer because it has that nice DOS device, which makes it easy to get files into the Unix (so I can use my normal editor on the host machine). However, I gather most people prefer SIMH; there is a tutorial here: https://gunkies.org/wiki/Running_Unix_v6_in_SIMH (I didn't write it; I know nothing of SIMH) for that option. How do people using SIMH get files into a Unix running on one? Larry Allen just wrote a PDP-11 simulator in Rust, and he's thinking about adding a paper-tape reader (connectable to a file), so that if he installs the stock V6 PTR driver, he can just do 'cat /dev/ptr > myfile'; sort of like how VM/370 used the virtual card reader. Noel From rdm at cfcl.com Fri Sep 25 00:38:33 2020 From: rdm at cfcl.com (Rich Morin) Date: Thu, 24 Sep 2020 07:38:33 -0700 Subject: [TUHS] Apple Quadra to good home Message-ID: A while back, there was some discussion of A/UX. We have an Apple Quadra which was able to boot and run A/UX a few decades ago. If someone wants to pay for shipping from the San Francisco Bay Area, this charming little machine could be theirs. Please respond off-list, to avoid annoying the neighbors... -r P.S. We're packing and moving, so a prompt response is critical. From rdm at cfcl.com Fri Sep 25 02:30:27 2020 From: rdm at cfcl.com (Rich Morin) Date: Thu, 24 Sep 2020 09:30:27 -0700 Subject: [TUHS] Apple Quadra to good home Message-ID: We've had three prospects respond (who knew???), so unless they all drop out, I think we're set. -r > A while back, there was some discussion of A/UX. We have an Apple Quadra which was able to boot and run A/UX a few decades ago. If someone wants to pay for shipping from the San Francisco Bay Area, this charming little machine could be theirs. Please respond off-list, to avoid annoying the neighbors... > > -r > > P.S. We're packing and moving, so a prompt response is critical. From jnc at mercury.lcs.mit.edu Fri Sep 25 02:34:44 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 24 Sep 2020 12:34:44 -0400 (EDT) Subject: [TUHS] V6 networking (Was: Choice of Unix for 11/03 and 11/23+ Systems) Message-ID: <20200924163444.A341718C0B6@mercury.lcs.mit.edu> > From: Paul Ruizendaal > I'd love to have a look at that and compare and contrast the > approaches. OK; the system is somewhat disorganized, and stuff is in directories here, there and everywhere in it (much is in the home dirs of some of the people who worked on some pieces), so it will take me a fair amount of work to curate it all into an accessible form, but I have put _some_ of it up here: http://ana-3.lcs.mit.edu/~jnc/tech/unix/net/ If you want to slurp up the whole thing: http://ana-3.lcs.mit.edu/~jnc/tech/unix/net/net.tar I should explain that the kernel only contains inbound de-multiplexing, and not much else; the TCP is in the user process, allong with the application. (Great for V6 on a small machine...) There is most of what documentation I could find in the 'doc' folder. There were at least two different TCP's in use on that system - maybe three. I have currently only included one (gotta do some more work to get the rest; for Server Telnet, and User/Server FTP), along with a couple of appplications which use it: SMTP, Finger, and User Telnet. The kernel code is mostly there, but there are some minor dribs and drabs of changes/additions elsewhere in the kernetl which I'll have to sort out in the future. The main thing that's not there is the Pronet driver; not very useful! There's also an ICMP paemon (and 'ping'), IIRC, but that's something else I'll have to find. Any questions, or stuff you'd really like to see, let me know. Noel From paul.winalski at gmail.com Fri Sep 25 03:19:02 2020 From: paul.winalski at gmail.com (Paul Winalski) Date: Thu, 24 Sep 2020 13:19:02 -0400 Subject: [TUHS] reviving a bit of WWB In-Reply-To: References: <202009190151.08J1pYnb066792@tahoe.cs.dartmouth.edu> <202009201842.08KIgn2f022401@freefriends.org> <04211470-AD63-452A-A0BB-6A7A6FD85AAE@gmail.com> Message-ID: On 9/23/20, Dave Horsfall wrote: > > Turing save us from 1-complement machines! > Or separate-sign numerical representations, for that matter, such as the IBM 1620 had. And packed decimal on the S/360/370 and the VAX. Negative zero in packed decimal is responsible for a lot of the "computerized bill for $0.00" bugs that were rife in the 1960s. -Paul W. From cowan at ccil.org Fri Sep 25 04:17:07 2020 From: cowan at ccil.org (John Cowan) Date: Thu, 24 Sep 2020 14:17:07 -0400 Subject: [TUHS] reviving a bit of WWB In-Reply-To: References: <202009190151.08J1pYnb066792@tahoe.cs.dartmouth.edu> <202009201842.08KIgn2f022401@freefriends.org> <04211470-AD63-452A-A0BB-6A7A6FD85AAE@gmail.com> Message-ID: On Thu, Sep 24, 2020 at 1:19 PM Paul Winalski wrote: Or separate-sign numerical representations, for that matter, such as > the IBM 1620 had. And packed decimal on the S/360/370 and the VAX. > Negative zero in packed decimal is responsible for a lot of the > "computerized bill for $0.00" bugs that were rife in the 1960s. > IEEE floats are still sign-magnitude, for that matter, both the binary ones and the little-used decimal ones, which is why MAX_FLOAT and MAX_DOUBLE are the same in both positive and negative directions. I once had to deal with some mainframe data that had been transferred to our PDP-11 or Vax (not sure which), and I noticed right away that some of the allegedly numeric data had a non-digit immediately following and one fewer significant digit than the rest. A little digging in my memory (I think this was before I got access to the Internet in 1985 or so), plus a little experimentation, established that these were trailing-overpunched-sign numbers that had been mechanically translated from EBCDIC to ASCII. So on the principle of "If a problem is not interesting, generalize it until it is", I wrote a little filter that looked for such numbers in its input and rewrote them as leading-separate-sign (i.e. the Usual Way), copying everything else. Unfortunately the source is long since lost, but I wouldn't write it in C today anyway. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Fri Sep 25 04:24:24 2020 From: cowan at ccil.org (John Cowan) Date: Thu, 24 Sep 2020 14:24:24 -0400 Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems In-Reply-To: <20200924130402.EDE4718C09F@mercury.lcs.mit.edu> References: <20200924130402.EDE4718C09F@mercury.lcs.mit.edu> Message-ID: I suppose this is teaching your grandmother(s) to suck eggs, but if you are not messing with the kernel or drivers, I find apout to be delightful. On Thu, Sep 24, 2020 at 9:04 AM Noel Chiappa wrote: > > From: Paul Riley > > > On my physical '03 I have twin Sykes floppy drives. I note that in > the > > LSX archives there is a Sykes driver, so I can adapt that I guess. > > Yes, here: > > https://www.tuhs.org/cgi-bin/utree.pl?file=LSX/sys/sykfd.c > > It looks like it should be a straight drop-in, to run it on Mini-Unix. Not > sure if your controller is the exact same model, though? Is there any > documentation on yours? (I haven't done any searching.) > > If you want to boot from it, you'll need to write a bootstrap for it; I > poked > around, but didn't see one. (Not sure how they booted machines with one, > back > in the day; maybe it wasn't the only drive, and they booted off something > else.) You can probably modify the RX one: > > https://www.tuhs.org/cgi-bin/utree.pl?file=LSX/src/rxboot.s > https://www.tuhs.org/cgi-bin/utree.pl?file=LSX/src/rxboot2.s > > Note that this is a 2-stage bootstrap, apparently as a result of the small > hardware block size on the RX. > > And of course there's still the issue of 'how to get bits onto it'. Can > floppies for it be written on some other kind of machine? If so, someone on > the Classic Computers list: > > http://www.classiccmp.org/mailman/listinfo/cctalk > > may be able to help you write those, or an RL02 pack. > > > You should start by getting some experience building V6 OS loads (Mini-Unix > will be _very_ similar); use a simulator. I have a lengthy tutorial here: > > http://www.chiappa.net/~jnc/tech/V6Unix.html > > It's in terms of Ersatz-11, which I prefer because it has that nice DOS > device, > which makes it easy to get files into the Unix (so I can use my normal > editor on > the host machine). However, I gather most people prefer SIMH; there is a > tutorial > here: > > https://gunkies.org/wiki/Running_Unix_v6_in_SIMH > > (I didn't write it; I know nothing of SIMH) for that option. > > How do people using SIMH get files into a Unix running on one? Larry Allen > just wrote a PDP-11 simulator in Rust, and he's thinking about adding a > paper-tape reader (connectable to a file), so that if he installs the stock > V6 PTR driver, he can just do 'cat /dev/ptr > myfile'; sort of like how > VM/370 used the virtual card reader. > > Noel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Fri Sep 25 04:56:15 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 24 Sep 2020 14:56:15 -0400 (EDT) Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems Message-ID: <20200924185615.755B318C0B5@mercury.lcs.mit.edu> > From: John Cowan > if you are not messing with the kernel or drivers, I find apout to be > delightful. Pretty much all of what little I do with V6 anymore is kernel hacking! :-) Noel From grog at lemis.com Fri Sep 25 10:18:59 2020 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Fri, 25 Sep 2020 10:18:59 +1000 Subject: [TUHS] One's complement (was: reviving a bit of WWB) In-Reply-To: References: <202009190151.08J1pYnb066792@tahoe.cs.dartmouth.edu> <202009201842.08KIgn2f022401@freefriends.org> <04211470-AD63-452A-A0BB-6A7A6FD85AAE@gmail.com> Message-ID: <20200925001859.GC53226@eureka.lemis.com> On Wednesday, 23 September 2020 at 22:33:38 -0400, Clem Cole wrote: > Dave: Seymour used ones complement on the 3000 and 6000 series. > Maybe there? The primary HLLs I used on the CDC boxes were FTN and > Pascal, but I would not be surprised if that was were you saw it. I think most of the bigger pre-IBM 360 machines used one's complement. Didn't the PDP-10? I knew it not only from the CDC 3200 and 3800, but primarily from Univac (1108 and 494). The Univac techies explained to me that the primary arithmetic function was subtraction; addition was subtracting the complement. And that worked faster with one's complement. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From imp at bsdimp.com Fri Sep 25 10:22:18 2020 From: imp at bsdimp.com (Warner Losh) Date: Thu, 24 Sep 2020 18:22:18 -0600 Subject: [TUHS] One's complement (was: reviving a bit of WWB) In-Reply-To: <20200925001859.GC53226@eureka.lemis.com> References: <202009190151.08J1pYnb066792@tahoe.cs.dartmouth.edu> <202009201842.08KIgn2f022401@freefriends.org> <04211470-AD63-452A-A0BB-6A7A6FD85AAE@gmail.com> <20200925001859.GC53226@eureka.lemis.com> Message-ID: On Thu, Sep 24, 2020 at 6:20 PM Greg 'groggy' Lehey wrote: > On Wednesday, 23 September 2020 at 22:33:38 -0400, Clem Cole wrote: > > Dave: Seymour used ones complement on the 3000 and 6000 series. > > Maybe there? The primary HLLs I used on the CDC boxes were FTN and > > Pascal, but I would not be surprised if that was were you saw it. > > I think most of the bigger pre-IBM 360 machines used one's complement. > Didn't the PDP-10? I knew it not only from the CDC 3200 and 3800, but > primarily from Univac (1108 and 494). The Univac techies explained to > me that the primary arithmetic function was subtraction; addition was > subtracting the complement. And that worked faster with one's > complement. > Don't know about the others, but I'm pretty sure PDP-10 wasn't 1's compliment / was 2's compliment.. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Fri Sep 25 11:39:46 2020 From: cowan at ccil.org (John Cowan) Date: Thu, 24 Sep 2020 21:39:46 -0400 Subject: [TUHS] One's complement (was: reviving a bit of WWB) In-Reply-To: References: <202009190151.08J1pYnb066792@tahoe.cs.dartmouth.edu> <202009201842.08KIgn2f022401@freefriends.org> <04211470-AD63-452A-A0BB-6A7A6FD85AAE@gmail.com> <20200925001859.GC53226@eureka.lemis.com> Message-ID: On Thu, Sep 24, 2020 at 8:22 PM Warner Losh wrote: Don't know about the others, but I'm pretty sure PDP-10 wasn't 1's >> compliment / was 2's compliment.. > > Correct. The PDP-1 (18 bits) was DEC's 1's complement machine. Its direct successors the 4/7/9/15 had both 1's and 2's complement arithmetic. The 12-bit 5/8/12 machines had only 2's complement, but retained the PDP-4 mnemonic TAD (Two's-complement Add). By the time the 36-bit 6/10/20 line was designed, it was clear that 1's complement was history, and the mnemonic was changed to ADD. (The PDP-3 was a PDP-1 with a 36-bit data path, and only one ever went into production; the PDP-2 was to be a 24-bit machine, perhaps a compromise between 6-bit and 8-bit byte systems, but was never even designed.) John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org I marvel at the creature: so secret and so sly as he is, to come sporting in the pool before our very window. Does he think that Men sleep without watch all night? --Faramir -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Sat Sep 26 00:19:25 2020 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Fri, 25 Sep 2020 10:19:25 -0400 Subject: [TUHS] reviving a bit of WWB Message-ID: <202009251419.08PEJPkV248911@coolidge.cs.dartmouth.edu> > Turing save us from 1-complement machines! Users of Whirlwind II were warned about the quirks of -0. We were not warned, though, about integer divide with remainder 0. The result of dividing 6 by 3, for example, was binary 1.111111... - a valid answer when carried to infinity. Unfortunately, the "fractional" part was dropped. Most people used Whirlwind for floating-point computation, and blithely dismissed printed answers like 1.999999 as "roundoff errors". Doug From jnc at mercury.lcs.mit.edu Sat Sep 26 01:21:08 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 25 Sep 2020 11:21:08 -0400 (EDT) Subject: [TUHS] One's complement (was: reviving a bit of WWB) Message-ID: <20200925152108.2AD1218C0C1@mercury.lcs.mit.edu> > From: Warner Losh > I'm pretty sure PDP-10 wasn't 1's compliment / was 2's compliment.. Just to confirm, I pulled out my PDP-10 Hardware Reference Manual; Vol I - CPU (EK-10/20-HR-001), and it does indeed say (pg. 1-12): "The fixed-point arithmetic instructions use 2's complement representations to do binary arithmetic." Selah. Noel From imp at bsdimp.com Sat Sep 26 01:30:46 2020 From: imp at bsdimp.com (Warner Losh) Date: Fri, 25 Sep 2020 09:30:46 -0600 Subject: [TUHS] One's complement (was: reviving a bit of WWB) In-Reply-To: <20200925152108.2AD1218C0C1@mercury.lcs.mit.edu> References: <20200925152108.2AD1218C0C1@mercury.lcs.mit.edu> Message-ID: On Fri, Sep 25, 2020, 9:22 AM Noel Chiappa wrote: > > From: Warner Losh > > > I'm pretty sure PDP-10 wasn't 1's compliment / was 2's compliment.. > > Just to confirm, I pulled out my PDP-10 Hardware Reference Manual; Vol I - > CPU > (EK-10/20-HR-001), and it does indeed say (pg. 1-12): "The fixed-point > arithmetic instructions use 2's complement representations to do binary > arithmetic." Selah. > Back in school, we had our machine organization course. When we learned about 1's complement, the professor said "I've used a lot of machines that had this. You will likely never see one with it. There are no operational machines on campus with that." It stuck with me. We had a TOPS-20 machine... the odd turn of phrase was due to a professor that had a board of unknown origin hanging on the wall that was a rumored to be a CDC or similar... ah, the mid 80s... Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Sat Sep 26 02:10:23 2020 From: ron at ronnatalie.com (Ronald Natalie) Date: Fri, 25 Sep 2020 16:10:23 +0000 Subject: [TUHS] One's complement (was: reviving a bit of WWB) In-Reply-To: References: <20200925152108.2AD1218C0C1@mercury.lcs.mit.edu> Message-ID: The DECSystem20 (and the PDP-10 before) were 36 bit two's complement machines. You had to go back to the PDP-1 if you want one's complement in the DEC line. The CDCs and UNIVACs were the only ones that were still kicking around in my era. >> >>Just to confirm, I pulled out my PDP-10 Hardware Reference Manual; Vol >>I - CPU >>(EK-10/20-HR-001), and it does indeed say (pg. 1-12): "The fixed-point >>arithmetic instructions use 2's complement representations to do >>binary >>arithmetic." Selah. > >Back in school, we had our machine organization course. When we learned >about 1's complement, the professor said "I've used a lot of machines >that had this. You will likely never see one with it. There are no >operational machines on campus with that."It stuck with me. We had a >TOPS-20 machine... the odd turn of phrase was due to a professor that >had a board of unknown origin hanging on the wall that was a rumored to >be a CDC or similar... ah, the mid 80s... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Sat Sep 26 08:08:21 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 25 Sep 2020 18:08:21 -0400 (EDT) Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems Message-ID: <20200925220821.6433218C0AA@mercury.lcs.mit.edu> > From: Paul Riley > I have two RLV-12/RL02 emulator boards I had made from Peter Schranz's > design (5volts.ch). They take an SD card Ah, you're all set, then - doubly so, in fact. Not only do you have reliable mass storage, but you should be able to put the Unix filesystem on an SD card, to get the bits into the machine. I'm not familiar with that board, but it sounds pretty good; QBUS<->SD. I don't know how that board uses the SD card, in terms of where it keeps the RL02 image, but if you can find that out, SD<->USB3 adaptors are cheap and plentiful, and it shouldn't be too hard to load the disk image into it using one of them. (For the QSIC, I found a 'dd' for Winsdoze and used that to write the disk image onto the SD card.) > I don't have any PROMs other than what would be on the '03 or '23+ > boards now. Not a problem: if you hook up the -11's console to another computer, you can download a bootstrap into it over the serial line, using the -11's ODT. (There's a page here: http://gunkies.org/wiki/Running_an_LSI-11_from_Unix_V6 which talks briefly about how to do that. Things like PDP11GUI can do it too, I think.) I don't use an RK bootstrap in ROM to boot from the emulated RK11 on the QSIC; I just load in a short RK bootstrap. I don't know of one lying around for the RL11, but one would be trivial to whip up. Speaking of booting, I have Mini-Uix booting under an -11/05 simulator (Ersatz-11); I used the RK image from here: http://www.tavi.co.uk/unixhistory/mini-unix/munixrks.zip and it just started right up. So that's the big hurdle; been busy with other stuff, but I'll work on getting it to boot on an '03 'soon'. You probably want to do the same; having it running under a simulator will make it easy to build new OS images, e.g. for a system with RL02's. Build the new system, name it 'rlmx', copy the simulator disk image into the SD card, and away you go. Oh, I recently realized how to make a bit more room on an -11/03: most DEC small QBUS memory cards allow you to use half the 'I/O page' for memory, if you need it. I.e. instead of having 56KB of memory, and 8 KB of address space for device registers (a lot more than is really needed), the memory can be configured to be 60KB of memory. It can be a bit of a hassle to use it; to have more room for the OS (for more drivers, or disk buffers, or whatever), some pieces of Mini-Unix need to be recompiled, to move up the address where user processes are loaded. Larger user processes are the same thing; they aren't automatically enabled when there's more memory, you have to change a config file, recompile some things, and build a new system. What kind of memory card(s) do you have for the -11/03? Noel From jfoust at threedee.com Sun Sep 27 00:52:48 2020 From: jfoust at threedee.com (John Foust) Date: Sat, 26 Sep 2020 09:52:48 -0500 Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems In-Reply-To: <20200925220821.6433218C0AA@mercury.lcs.mit.edu> References: <20200925220821.6433218C0AA@mercury.lcs.mit.edu> Message-ID: <20200926145307.AE91994552@minnie.tuhs.org> Have you searched the archives? Here's some previous conversation. https://web.archive.org/web/20030215152905/https://minnie.tuhs.org/pipermail/pups/2001-March/000273.html - John From dave at horsfall.org Sun Sep 27 10:54:51 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 27 Sep 2020 10:54:51 +1000 (EST) Subject: [TUHS] How accurate are those AUUGN scans? Message-ID: When someone mentioned that they'd ported V6 to the 11/23, I recalled that I did the same thing (well, V6 + the bits of AUSAM that I liked + the bits of V7 that I could shoe-horn in), and went looking for the article that I could've sworn I'd published, using "pdfgrep 23 AUUGN*" in my TUHS mirror. And yes, I recall some hardware peculiarity which had to be worked around, but I've forgotten the details (which is why I went looking). I didn't find it (is there an index of articles anywhere?), but I did find some peculiar typos, and I was wondering whether they were a result of Google's (destructive) scanning, or were in the originals. Here's a quick sample: AUUGN-V04.5.pdf: tailored for smaller. PDP11s (such as the 11/23 or 11/34) in an A period after "smaller". AUUGN-V04.6.pdf: Unfortunately. the clever Code comes unstuck as the LSI-II/23 doesn't’t The phrase "Unfortunately. the clever Code" looks wrong. AUUGN-V04.6.pdf:LSI-II/23 was changing the value of r! if the V-bit gets set. It seemed "r!" should be "r1" (a possible typo, as they are the same key).. AUUGN-V04.6.pdf: bio23 (662 2668) Elec. Eng., UNSW, This is a weirdie; "bio23" (one of my clients) was never a part of Elec Eng (they were their own school), so I suspect a mistake here; it's possible, however, that they were in the same building. AUUGN-V04.6.pdf: PDP 11/23 + FPU. RK05, RL02, DRIIb I believe that "DR11b" should be "DR11B". AUUGN-V05.1.pdf: PDP 11/23 - System III (Ausam)., 256k, 2xR102, 16 lines AUSAM under System III, on a mere 11/23? I very much doubt it... Also, "R102" should probably be "RL02". AUUGN-V05.1.pdf: PDP 11/23, Q bus + qniverter, RK05, Pertec dual RK05, DEC dual cassette, I suspect that "qniverter" was a typo on the part of the author. As a bit of a Unix historian it would be a shame if those AUUGN scans were less than accurate; I no longer have my hard copies (lost in a house move), so perhaps someone could check their copies? Thanks. -- Dave From dave at horsfall.org Sun Sep 27 15:54:50 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 27 Sep 2020 15:54:50 +1000 (EST) Subject: [TUHS] reviving a bit of WWB In-Reply-To: References: <202009190151.08J1pYnb066792@tahoe.cs.dartmouth.edu> <202009201842.08KIgn2f022401@freefriends.org> <04211470-AD63-452A-A0BB-6A7A6FD85AAE@gmail.com> Message-ID: On Wed, 23 Sep 2020, Clem Cole wrote: > Dave: Seymour used ones complement on the 3000 and 6000 series. > Maybe there?   The primary HLLs I used on the CDC boxes were FTN and Pascal, > but I would not be surprised if that was were you saw it. Could be CDC, yeah, but this was a few decades ago... -- Dave From jnc at mercury.lcs.mit.edu Mon Sep 28 06:50:22 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 27 Sep 2020 16:50:22 -0400 (EDT) Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems Message-ID: <20200927205022.2D91918C0C8@mercury.lcs.mit.edu> > From: Paul Riley > I also have a DEC 256KB board, but I doubt I could use it on the > '03. Yes, DEC 256KB boards are what's called Q22, and those don't seem to work with LSI-11's; not even CPU ODT works. I just tried a 256KB MSV11-L with an LSI-11, and it definitely doesn't work; the MSV11-P is definitely a Q22 board, and so probably also won't work. What the Q22 means is that early in the lifetime of the QBUS, it only had 18 address line - so-called Q18. (Technially the LII-11 used only 16 address lines, so it's actually Q16.) DEC latter snarfed some of the 'unused' pins, and made them QDAL18-21. So boards that use those pins for QDAL18-21 are 'Q22' boards. My theory on what the problem is is that the LSI-11 uses some of those pins for other things - I think the 'run' light, IIRC. So that confuses Q22 memory. If one tries to use one with an LSI-11, the machine is totally dead - not even ODT. It doesn't do any harm, though; unplug the Q22 memory, and plug in a Q18 card like an MSV11-D, and it'll be fine. If you need memory for the LSI-11, MSV11-D boards are pretty common on eBait, for not much. They tend to be flaky, though; sometimes they come back to life if you leave them sit for a bit after you plug them in. > I believe the [memory] board is non-DEC. Well, if it's Q22 it won't work either. Both that and the DEC board should work in the /23, though. (If you have the part number on the memory chips, a little arithmetic should give you the board size. 256K and up are generallly Q22; if you have a manual for that card it might say.) I'm still working with Mini-Unix; it's very fragile. When I got it running, the first thing I tried to do was changle the line editing characters (since my normal ones are burned into ROM). Alas, in stock V6, DEL is hard-wired to be 'interrupt process', so I can't just 'stty [mumble]', I have to rebuild the kernel to change that. Not a problem, necessarily - but I edited tty.h and said 'cc -c tty.c', and it crashed and re-started - and roached the disk. So I'm still trying to make progress. I might have mis-configured the simulator, I'll see. Noel From jnc at mercury.lcs.mit.edu Mon Sep 28 07:07:22 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 27 Sep 2020 17:07:22 -0400 (EDT) Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems Message-ID: <20200927210722.5059218C0C8@mercury.lcs.mit.edu> > So that confuses Q22 memory. If one tries to use one with an LSI-11, > the machine is totally dead - not even ODT. Oh, that's another LSI-11 'feature' (only discovered after someone sent in a help request on CCalk for a dead LSI-11): if there's no working memory at 0, ODT won't start/run. So if the Q22 memory is confused, the whole machine is dead. Noel From imp at bsdimp.com Mon Sep 28 07:12:15 2020 From: imp at bsdimp.com (Warner Losh) Date: Sun, 27 Sep 2020 15:12:15 -0600 Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems In-Reply-To: <20200927210722.5059218C0C8@mercury.lcs.mit.edu> References: <20200927210722.5059218C0C8@mercury.lcs.mit.edu> Message-ID: On Sun, Sep 27, 2020, 3:08 PM Noel Chiappa wrote: > > So that confuses Q22 memory. If one tries to use one with an LSI-11, > > the machine is totally dead - not even ODT. > > Oh, that's another LSI-11 'feature' (only discovered after someone sent in > a > help request on CCalk for a dead LSI-11): if there's no working memory at > 0, > ODT won't start/run. So if the Q22 memory is confused, the whole machine > is dead. > Maybe a bit of electrical tape over the fingers on the 256KB board would keep them isolated from these signals? That would help determine if it is just floating pins, or that the LSI-11 used these pins for other reasons? Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at rileyriot.com Mon Sep 28 10:03:54 2020 From: paul at rileyriot.com (Paul Riley) Date: Mon, 28 Sep 2020 08:03:54 +0800 Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems In-Reply-To: <20200925220821.6433218C0AA@mercury.lcs.mit.edu> References: <20200925220821.6433218C0AA@mercury.lcs.mit.edu> Message-ID: > > > don't know how that board uses the SD card, in terms of where it keeps the > RL02 image, but if you can find that out, SD<->USB3 adaptors are cheap and > plentiful, and it shouldn't be too hard to load the disk image into it > using > one of them. (For the QSIC, I found a 'dd' for Winsdoze and used that to > write > the disk image onto the SD card.) > > Here's how the formatting of the SD card is done. First you partition the disk into n 'FAT 12" partitions, one for each drive you wish to connect. Then you pop the card in the emulator board, and run a utility which formats the partitions as "Linux" and you then have n 10.5MB Linux partitions. Putting the card back into your host machine, you then copy your RL02 disk images to the newly formatted Linux partitions. Here's the full explanation: https://www.5volts.ch/pages/rlv12/rlv12-createdisk/ > > I don't have any PROMs other than what would be on the '03 or '23+ > > boards now. > > Not a problem: if you hook up the -11's console to another computer, you > can download a bootstrap into it over the serial line, using the -11's ODT. > Thanks for the tip. > Speaking of booting, I have Mini-Uix booting under an -11/05 simulator > (Ersatz-11); I used the RK image from here: > > Thanks again. > Oh, I recently realized how to make a bit more room on an -11/03: most > DEC small QBUS memory cards allow you to use half the 'I/O page' for > memory, > Sounds beyond me, and not necessary at this stage. > What kind of memory card(s) do you have for the -11/03? > > The 256kB card is: M8067-KA MSV11-PK 256-kbyte MOS memory with parity CSR I'll keep that for the '23+. Can you clarify something for me regarding memory? I understand the bottom area of memory in a Unix system is for the Kernel and it's stuff, and that the top 8kB is set aside for device I/O (with the exceptions you mentioned in a previous email about using some of that space). The LSI-11 board has 4kW of RAM on it, and I have already a 16KW board. If I want to further expand the RAM, and say I buy another 16kW board, that makes an arithmetic sum of 32kW for the boards, making 36kW total. Can the 4kW of on-board RAM be disabled, and only the 32kW on the boards be used? Is it ok for the installed RA mto overlap the 8kW at the high memory area? Do the devices spoof these addresses or do they read/write in the high installed RAM area? Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at rileyriot.com Mon Sep 28 10:06:33 2020 From: paul at rileyriot.com (Paul Riley) Date: Mon, 28 Sep 2020 08:06:33 +0800 Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems In-Reply-To: References: <20200925220821.6433218C0AA@mercury.lcs.mit.edu> Message-ID: Sorry, That should be 8kB (4kW) of high memory... On Mon, 28 Sep 2020 at 08:03, Paul Riley wrote: > >> don't know how that board uses the SD card, in terms of where it keeps the >> RL02 image, but if you can find that out, SD<->USB3 adaptors are cheap and >> plentiful, and it shouldn't be too hard to load the disk image into it >> using >> one of them. (For the QSIC, I found a 'dd' for Winsdoze and used that to >> write >> the disk image onto the SD card.) >> >> Here's how the formatting of the SD card is done. First you partition the > disk into n 'FAT 12" partitions, one for each drive you wish to connect. > Then you pop the card in the emulator board, and run a utility which > formats the partitions as "Linux" and you then have n 10.5MB Linux > partitions. Putting the card back into your host machine, you then copy > your RL02 disk images to the newly formatted Linux partitions. > > Here's the full explanation: > > https://www.5volts.ch/pages/rlv12/rlv12-createdisk/ > > >> > I don't have any PROMs other than what would be on the '03 or '23+ >> > boards now. >> >> Not a problem: if you hook up the -11's console to another computer, you >> can download a bootstrap into it over the serial line, using the -11's >> ODT. >> > > Thanks for the tip. > > >> Speaking of booting, I have Mini-Uix booting under an -11/05 simulator >> (Ersatz-11); I used the RK image from here: >> >> Thanks again. > > >> Oh, I recently realized how to make a bit more room on an -11/03: most >> DEC small QBUS memory cards allow you to use half the 'I/O page' for >> memory, >> > > Sounds beyond me, and not necessary at this stage. > > >> What kind of memory card(s) do you have for the -11/03? >> >> > The 256kB card is: > M8067-KA MSV11-PK 256-kbyte MOS memory with parity CSR > I'll keep that for the '23+. > > Can you clarify something for me regarding memory? I understand the bottom > area of memory in a Unix system is for the Kernel and it's stuff, and that > the top 8kB is set aside for device I/O (with the exceptions you mentioned > in a previous email about using some of that space). The LSI-11 board has > 4kW of RAM on it, and I have already a 16KW board. If I want to further > expand the RAM, and say I buy another 16kW board, that makes an arithmetic > sum of 32kW for the boards, making 36kW total. Can the 4kW of on-board RAM > be disabled, and only the 32kW on the boards be used? Is it ok for the > installed RA mto overlap the 8kW at the high memory area? Do the devices > spoof these addresses or do they read/write in the high installed RAM area? > > Paul > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pete at dunnington.plus.com Mon Sep 28 10:22:16 2020 From: pete at dunnington.plus.com (Pete Turnbull) Date: Mon, 28 Sep 2020 01:22:16 +0100 Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems In-Reply-To: References: <20200927210722.5059218C0C8@mercury.lcs.mit.edu> Message-ID: <445fa6b1-e1ee-2c96-2259-6cd17df9a188@dunnington.plus.com> On 27/09/2020 22:12, Warner Losh wrote: > Maybe a bit of electrical tape over the fingers on the 256KB board would > keep them isolated from these signals? That would help determine if it > is just floating pins, or that the LSI-11 used these pins for other reasons? No need for tape or any other test. The pin assignments for both the original LSI11 bus, as used in the 11/03, and the Q22 bus used in later machines, are well documented. The 16-bit pinouts are listed in the 1976 edition of the Microcomputer Handbook, the 18-bit in the 1980 edition, and there's a comparison table with Q22 in the 1982 Microcomuters and Memories handbook. There are more differences than the BDAL18-21 lines and there are even differences between the KD11-F and KD11-HA. The SRUNL signal that was mentioned isn't likely to cause a problem; it's on both AF1 and AH1 in an 11/23 and a KD11-HA, but only on AF1 on a KD11-F, and I'm not sure it's bussed anyway in most backplanes. BDAL18L is on BC1, and that's an internal clock signal on a KD11-HA. BDAL19-21 are on BD1-BF1 and they're connected to MICROM signals in the KD11-HA. None of them are connected to anything on a KD11-F. -- Pete Pete Turnbull From aap at papnet.eu Tue Sep 29 03:35:56 2020 From: aap at papnet.eu (Angelo Papenhoff) Date: Mon, 28 Sep 2020 19:35:56 +0200 Subject: [TUHS] reviving a bit of WWB In-Reply-To: <202009251419.08PEJPkV248911@coolidge.cs.dartmouth.edu> References: <202009251419.08PEJPkV248911@coolidge.cs.dartmouth.edu> Message-ID: <20200928173555.GA78180@indra.papnet.eu> On 25/09/20, Doug McIlroy wrote: > > Turing save us from 1-complement machines! > > Users of Whirlwind II were warned about the quirks of -0. > We were not warned, though, about integer divide with remainder 0. > The result of dividing 6 by 3, for example, was binary 1.111111... - > a valid answer when carried to infinity. Unfortunately, the > "fractional" part was dropped. > > Most people used Whirlwind for floating-point computation, and > blithely dismissed printed answers like 1.999999 as "roundoff > errors". It's funny that you mention that. I'm working on a verilog simulation of the Whirlwind I right now and I *just* came across this quirk. Now I'm really glad I remembered this mail of yours. Otherwise I might have spent some time trying to debug this non-bug. Thanks a lot! (The simulation is based on the description from 1947, so it doesn't describe the machine as it actually ran in the 50s. It would be great to have more material on its later life.) aap From jnc at mercury.lcs.mit.edu Tue Sep 29 09:21:56 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 28 Sep 2020 19:21:56 -0400 (EDT) Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems Message-ID: <20200928232156.CD8E118C0DA@mercury.lcs.mit.edu> > From: Pete Turnbull > The SRUNL signal that was mentioned isn't likely to cause a problem That was just a guess on my part as to the exact cause. It is definite, though, that Q22 memory won't work with an LSI-11/2 (M7270); I just tried it. I didn't touch any of the other boards; just swapped the LSI-11/2 for a KDF11-A (M8186), everything worked fine; put the LSI-11/2 back, dead again. I'll try an LSI-11 (M7264) tomorrow, make sure it's the same; it and the LSI-11/2 are similar enough that it should, but it'd be good to confirm it. Then back to trying to work out why Mini-Unix is so fragile for me. Has anyone else ever worked with Mini-Unix, and if so, any tips? Noel From paul at rileyriot.com Tue Sep 29 23:20:25 2020 From: paul at rileyriot.com (Paul Riley) Date: Tue, 29 Sep 2020 21:20:25 +0800 Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems In-Reply-To: <20200927205022.2D91918C0C8@mercury.lcs.mit.edu> References: <20200927205022.2D91918C0C8@mercury.lcs.mit.edu> Message-ID: Noel, Regarding the boards, the non-DEC one is the 16kW board I bought installed in the '03, so I guess that works fine. I managed to follow instructions for SimH and install and configure a V6 system. Was quite satisfying, and was quite an education. So many lessons in one session, a really good exercise. I'm checking with Peter Schranz about whether or not his RLV12/RL02 boards can run on the '03. May be a similar issue with knobbling some of the pins, if I'm lucky. *Paul Riley* Mo: +86 186 8227 8332 Email: paul at rileyriot.com On Mon, 28 Sep 2020 at 04:51, Noel Chiappa wrote: > > From: Paul Riley > > > I also have a DEC 256KB board, but I doubt I could use it on the > > '03. > > Yes, DEC 256KB boards are what's called Q22, and those don't seem to work > with > LSI-11's; not even CPU ODT works. I just tried a 256KB MSV11-L with an > LSI-11, > and it definitely doesn't work; the MSV11-P is definitely a Q22 board, and > so > probably also won't work. > > What the Q22 means is that early in the lifetime of the QBUS, it only had > 18 > address line - so-called Q18. (Technially the LII-11 used only 16 address > lines, > so it's actually Q16.) DEC latter snarfed some of the 'unused' pins, and > made them QDAL18-21. So boards that use those pins for QDAL18-21 are 'Q22' > boards. > > My theory on what the problem is is that the LSI-11 uses some of those pins > for other things - I think the 'run' light, IIRC. So that confuses Q22 > memory. > If one tries to use one with an LSI-11, the machine is totally dead - not > even > ODT. It doesn't do any harm, though; unplug the Q22 memory, and plug in a > Q18 > card like an MSV11-D, and it'll be fine. > > If you need memory for the LSI-11, MSV11-D boards are pretty common on > eBait, > for not much. They tend to be flaky, though; sometimes they come back to > life > if you leave them sit for a bit after you plug them in. > > > I believe the [memory] board is non-DEC. > > Well, if it's Q22 it won't work either. Both that and the DEC board should > work in the /23, though. (If you have the part number on the memory chips, > a > little arithmetic should give you the board size. 256K and up are > generallly > Q22; if you have a manual for that card it might say.) > > > I'm still working with Mini-Unix; it's very fragile. When I got it running, > the first thing I tried to do was changle the line editing characters > (since > my normal ones are burned into ROM). Alas, in stock V6, DEL is hard-wired > to > be 'interrupt process', so I can't just 'stty [mumble]', I have to rebuild > the > kernel to change that. Not a problem, necessarily - but I edited tty.h and > said 'cc -c tty.c', and it crashed and re-started - and roached the disk. > So > I'm still trying to make progress. I might have mis-configured the > simulator, > I'll see. > > Noel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angus at fairhaven.za.net Tue Sep 29 23:33:26 2020 From: angus at fairhaven.za.net (Angus Robinson) Date: Tue, 29 Sep 2020 15:33:26 +0200 Subject: [TUHS] Unix History with Brian Kernighan Message-ID: https://www.youtube.com/watch?v=O9upVbGSBFo Kind Regards, Angus Robinson -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at kdbarto.org Wed Sep 30 04:42:55 2020 From: david at kdbarto.org (David Barto) Date: Tue, 29 Sep 2020 11:42:55 -0700 Subject: [TUHS] SH script formatting Message-ID: <300084CC-77EA-44D4-9DB1-DC321B9F3F0B@kdbarto.org> In a brief discussion with a coworker today the question of formatting shell scripts came up. I believed that in the past the preferred format (if there ever were any such thing) was if [ test ] then statements else statements fi I can find nothing specific to back this up. More appropriate for COFF maybe would be a discussion of what format is better if [ test ]; then statements else statements fi or the above. No intention to start any kind of flame war about which is better, just want to see if there is any historical option for one over the other. David From norman at oclsc.org Wed Sep 30 05:15:06 2020 From: norman at oclsc.org (Norman Wilson) Date: Tue, 29 Sep 2020 15:15:06 -0400 Subject: [TUHS] SH script formatting Message-ID: <1601406910.6529.for-standards-violators@oclsc.org> if test; then stuff and if test then stuff are functionally equivalent. I wouldn't say one or the other `is preferred.' I use the former because I think it's a little more readable because more compact. But it's really a matter of style, like whether you write if (test) { (multi-statement block) or if (test) { (multi-statement block) I have a stronger opinion about those who use overly- cryptic constructions like test && { shell commands } because it means exactly the same thing as if test; then shell commands but is more obscure to read. But again it's a question of style, not of dogma. As an aside, I think one excuse that is sometimes used for that sort of construct is when it's test || { commands } because Bourne's original shell had no not operator. For a long time after shell functions appeared, I would add this function to any of my shell scripts that needed it: not() { if "$@"; then return 1 else return 0 } so I could say if not test; then commands fi Modern Bourne-shell descendants have a built-in ! operator: if ! test; then commands fi I'm not keen on most of what has been stuffed into bash and ksh and the like, but ! is a real improvement. I believe POSIX mandates it, and I think they're right. Norman Wilson Toronto ON From cowan at ccil.org Wed Sep 30 05:29:59 2020 From: cowan at ccil.org (John Cowan) Date: Tue, 29 Sep 2020 15:29:59 -0400 Subject: [TUHS] SH script formatting In-Reply-To: <300084CC-77EA-44D4-9DB1-DC321B9F3F0B@kdbarto.org> References: <300084CC-77EA-44D4-9DB1-DC321B9F3F0B@kdbarto.org> Message-ID: There seems to have been a migration over time from the first format to the second, perhaps a result of C programmers not having a keyword "then", which Bourne shells (following Algol 68) require. I don't think it matters much. On Tue, Sep 29, 2020 at 2:52 PM David Barto wrote: > In a brief discussion with a coworker today the question of formatting > shell scripts came up. > > I believed that in the past the preferred format (if there ever were any > such thing) was > > if [ test ] > then > statements > else > statements > fi > > I can find nothing specific to back this up. More appropriate for COFF > maybe would > be a discussion of what format is better > > if [ test ]; then > statements > else > statements > fi > > or the above. > > No intention to start any kind of flame war about which is better, just > want to see > if there is any historical option for one over the other. > > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at rileyriot.com Wed Sep 30 11:50:39 2020 From: paul at rileyriot.com (Paul Riley) Date: Wed, 30 Sep 2020 09:50:39 +0800 Subject: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems In-Reply-To: <20200928232156.CD8E118C0DA@mercury.lcs.mit.edu> References: <20200928232156.CD8E118C0DA@mercury.lcs.mit.edu> Message-ID: Noel, Some more info on my machines... *The DLV11-J: http://gunkies.org/wiki/DLV11-J_asynchronous_serial_line_interface is basically 4 DLV11's rolled into a single dual-width card; that's definitelyan option for Mini-Unix (which apparently supports up to 4 simultaneoususers). They are program compatible with the DHV11, so the driver should 'justwork'. The boards are readily available on eBait; 'glitchworks' (of thisparish) sells replacement cables (quite good, I have several).* I bought a DLV-11J on eBay so that's a starter for my /03 machine. I've also bought an MSV11-DE 32kW memory board. Peter Schranz has confirmed a modification to his RLV12/RL02 emulator to allow it to run on the /03. I'm all set for Mini-Unix on the /03 then! Regarding the KDF11-B: *If yours doesn't have the MMU chip, you're probably SOL; those are very rare.KEF11-A FPU chips are avilable on eBay for modest amounts. * Looks like I'm in luck! My /23+ CPU board does have the MMU installed. I also bought a KEF11-A separately. Glad my wife doesn't know about all these purchases. ;) Paul *Paul Riley* Mo: +86 186 8227 8332 Email: paul at rileyriot.com On Tue, 29 Sep 2020 at 07:23, Noel Chiappa wrote: > > From: Pete Turnbull > > > The SRUNL signal that was mentioned isn't likely to cause a problem > > That was just a guess on my part as to the exact cause. It is definite, > though, that Q22 memory won't work with an LSI-11/2 (M7270); I just tried > it. > I didn't touch any of the other boards; just swapped the LSI-11/2 for a > KDF11-A (M8186), everything worked fine; put the LSI-11/2 back, dead again. > > I'll try an LSI-11 (M7264) tomorrow, make sure it's the same; it and the > LSI-11/2 are similar enough that it should, but it'd be good to confirm it. > > > Then back to trying to work out why Mini-Unix is so fragile for me. Has > anyone else ever worked with Mini-Unix, and if so, any tips? > > Noel > -------------- next part -------------- An HTML attachment was scrubbed... URL: