From lm at mcvoy.com Wed Aug 1 14:15:59 2018 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 31 Jul 2018 21:15:59 -0700 Subject: [TUHS] Doug McIlroy's C++ regular expression library (mostly) revived In-Reply-To: <201807290602.w6T62jr1018355@freefriends.org> References: <201807282231.w6SMVcWT097678@tahoe.cs.Dartmouth.EDU> <201807290602.w6T62jr1018355@freefriends.org> Message-ID: <20180801041559.GL23233@mcvoy.com> The old school Unix guys are just like this. I asked BWK about awk and he tarred up ~bwk/awk and sent me the source to awk, to the awk book, it was crazy cool. And it's crazy cool that us "younger" (I feel pretty old but younger than the Unix guys) folks get to hang out with the people who were there at the beginning. I can't tell you how grateful I am to be on this list with these people. On Sun, Jul 29, 2018 at 12:02:45AM -0600, arnold at skeeve.com wrote: > Dr. McIlroy, > > Much thanks for this! If you don't object, I will add this note to the > repo as it provides insight into the wherefores of the package. > > At this point, I must also give credit where credit is due: > > * Chet Ramey, who suggested that I ask Russ Cox to take a look at the package, > * Russ Cox, who fixed the major problems and got all the tests to pass, > * Rares Aioanei, who volunteered to tackle fixing things but did not get > to do so before Russ beat him to it. > > As implied by the above, the package is now up-to-date and functional! > I hope it's of interest to the broader community. > > My own reason for seeking this out is that I have (likely vain) hopes > of one day finding a better regex package to use for gawk. But > regular expressions are interesting in their own right. Russ Cox has > a series of papers on his web site about them that are worth reading. > > Finally, thanks again to Dr. McIlroy for humoring me and giving me > his code to play with. > > Arnold > > > Doug McIlroy wrote: > > > Why would anyone be interested in an old regex package that never was > > a part of any Unix distro? > > > > The driving force was Posix, whose regex spec was quite inscrutable. Could > > there be a reference implementation? It was easy to fool every > > implementation I could get my hands on, including Gnu's over-the-top > > 9000-line implementation. > > > > But as I got into it, I got fascinated by regexes per se. In making a > > recognizer, there's a tradeoff between contruction time and execution > > time. Linear execution can be achieved, but at a potentially exponential > > cost in construction time (and space). Backreferencing takes the regex > > languages out of the class of regular languages. > > > > Recalling that regular languages are closed under intersection and > > negation, I wondered about how to implement new regex operators, & > > and -. I came up with a scheme for this optional non-Posix feature that > > involved layering continuation-passing over more traditional methods. And > > while I was at it, I broke out smaller sublanguages for special treatment > > (as does Gnu), all the way down to Knuth-Morris-Pratt for expressions > > in which the only operation is catenation. > > > > And finally, having followed the development of C++ from its infancy, > > I wanted to try out its new template facility, so there's a bit of > > that in the package, too. Arnold has discovered that not only has C++ > > evolved, but also that without the discipline of -Wall to force clean > > code, I was rather cavalier about casting, both explicitly and implicitly. > > > > The only real customer the code ever had was the AST project, which > > translated it to C. After the C++ had sat idle for a half-dozen years, I > > thought to revive it in Linux, but found it riddled with incompatibilities > > with that new environment and gave up. Arnold deserves a citation for > > bravery in pushing that through 15 years further on. > > > > Doug -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From doug at cs.dartmouth.edu Thu Aug 2 22:44:56 2018 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Thu, 02 Aug 2018 08:44:56 -0400 Subject: [TUHS] In Memoriam: Per Brinch Hansen Message-ID: <201808021244.w72CiuU4025022@tahoe.cs.Dartmouth.EDU> A tangential connection to early Unix experience: My collection of early computer manuals includes Brinch Hansen's manual for the RC 4000, which stands out for its precise description of the CPU logic--in Algol 60! It's the only manual I have seen that offers a good-to-the-last-bit formal description of the hardware. DEC presented something of the sort for the PDP-11, but punted where the woods got thick. When I wanted to know how they computed the last bit of floating-point results, I got no satisfaction. Amidst a thorough description of addressing came this formulation of the actual computation: "form floating point result". Doug From ben at cogs.com Thu Aug 2 23:10:54 2018 From: ben at cogs.com (Ben Greenfield) Date: Thu, 2 Aug 2018 09:10:54 -0400 Subject: [TUHS] In Memoriam: Per Brinch Hansen In-Reply-To: <201808021244.w72CiuU4025022@tahoe.cs.Dartmouth.EDU> References: <201808021244.w72CiuU4025022@tahoe.cs.Dartmouth.EDU> Message-ID: Is this a weblink to that manual? I want to read something so well written:) Ben https://pdfs.semanticscholar.org/b77f/02dedb784a52229c5376277173c5ef6da5c1.pdf > On Aug 2, 2018, at 8:44 AM, Doug McIlroy wrote: > > A tangential connection to early Unix experience: > > My collection of early computer manuals includes Brinch Hansen's manual > for the RC 4000, which stands out for its precise description of the > CPU logic--in Algol 60! It's the only manual I have seen that offers a > good-to-the-last-bit formal description of the hardware. > > DEC presented something of the sort for the PDP-11, but punted where > the woods got thick. When I wanted to know how they computed the last > bit of floating-point results, I got no satisfaction. Amidst a thorough > description of addressing came this formulation of the actual computation: > "form floating point result". > > Doug From lm at mcvoy.com Fri Aug 3 00:07:34 2018 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 2 Aug 2018 07:07:34 -0700 Subject: [TUHS] In Memoriam: Per Brinch Hansen In-Reply-To: References: <201808021244.w72CiuU4025022@tahoe.cs.Dartmouth.EDU> Message-ID: <20180802140734.GC24473@mcvoy.com> I suspect not, I suspect his first reference is the one you want. On Thu, Aug 02, 2018 at 09:10:54AM -0400, Ben Greenfield via TUHS wrote: > Is this a weblink to that manual? > > I want to read something so well written:) > > Ben > > https://pdfs.semanticscholar.org/b77f/02dedb784a52229c5376277173c5ef6da5c1.pdf > > > On Aug 2, 2018, at 8:44 AM, Doug McIlroy wrote: > > > > A tangential connection to early Unix experience: > > > > My collection of early computer manuals includes Brinch Hansen's manual > > for the RC 4000, which stands out for its precise description of the > > CPU logic--in Algol 60! It's the only manual I have seen that offers a > > good-to-the-last-bit formal description of the hardware. > > > > DEC presented something of the sort for the PDP-11, but punted where > > the woods got thick. When I wanted to know how they computed the last > > bit of floating-point results, I got no satisfaction. Amidst a thorough > > description of addressing came this formulation of the actual computation: > > "form floating point result". > > > > Doug -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From asbesto at freaknet.org Fri Aug 3 00:25:31 2018 From: asbesto at freaknet.org (asbesto) Date: Thu, 2 Aug 2018 14:25:31 +0000 Subject: [TUHS] Australian Computer Museum Society collection faces bulldozers Message-ID: <20180802142531.GA16356@freaknet.org> IDK if you know this, but https://www.itnews.com.au/news/australian-computer-museum-society-collection-faces-bulldozers-499452 :( -- [ ::::::::: 73 de IW9HGS : http://freaknet.org/asbesto ::::::::::: ] [ Freaknet Medialab :: Poetry Hacklab : Dyne.Org :: Radio Cybernet ] [ NON SCRIVERMI USANDO LETTERE ACCENTATE - NON MANDARMI ALLEGATI ] [ *I DELETE* EMAIL > 100K, ATTACHMENTS, HTML, M$-WORD DOC and SPAM ] From bakul at bitblocks.com Fri Aug 3 01:44:01 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Thu, 2 Aug 2018 08:44:01 -0700 Subject: [TUHS] In Memoriam: Per Brinch Hansen In-Reply-To: <20180802140734.GC24473@mcvoy.com> References: <201808021244.w72CiuU4025022@tahoe.cs.Dartmouth.EDU> <20180802140734.GC24473@mcvoy.com> Message-ID: <170A1322-620F-46EE-8BA3-8BF295EC6E3A@bitblocks.com> I think it is this one: http://bitsavers.org/pdf/regnecentralen/RC_4000_Reference_Manual_Jun69.pdf Along these lines, at least one of Fujitsu’s high end network switches was described using PowerPoint slides. At one point while working for them I felt a software simulator of the switch would really help with testing switch software. So I started developing one on my own. That is when I discovered these slides were not only very detailed but also very accurate and quite clear. They answered every question I had during the development. I have never seen such /engineering/ use of PowerPoint anywhere else. > On Aug 2, 2018, at 7:07 AM, Larry McVoy wrote: > > I suspect not, I suspect his first reference is the one you want. > >> On Thu, Aug 02, 2018 at 09:10:54AM -0400, Ben Greenfield via TUHS wrote: >> Is this a weblink to that manual? >> >> I want to read something so well written:) >> >> Ben >> >> https://pdfs.semanticscholar.org/b77f/02dedb784a52229c5376277173c5ef6da5c1.pdf >> >>> On Aug 2, 2018, at 8:44 AM, Doug McIlroy wrote: >>> >>> A tangential connection to early Unix experience: >>> >>> My collection of early computer manuals includes Brinch Hansen's manual >>> for the RC 4000, which stands out for its precise description of the >>> CPU logic--in Algol 60! It's the only manual I have seen that offers a >>> good-to-the-last-bit formal description of the hardware. >>> >>> DEC presented something of the sort for the PDP-11, but punted where >>> the woods got thick. When I wanted to know how they computed the last >>> bit of floating-point results, I got no satisfaction. Amidst a thorough >>> description of addressing came this formulation of the actual computation: >>> "form floating point result". >>> >>> Doug > > -- > --- > Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at rulingia.com Fri Aug 3 20:28:56 2018 From: peter at rulingia.com (Peter Jeremy) Date: Fri, 3 Aug 2018 20:28:56 +1000 Subject: [TUHS] Australian Computer Museum Society collection faces bulldozers In-Reply-To: <20180802142531.GA16356@freaknet.org> References: <20180802142531.GA16356@freaknet.org> Message-ID: <20180803102856.GF4409@server.rulingia.com> On 2018-Aug-02 14:25:31 +0000, asbesto wrote: >IDK if you know this, but > >https://www.itnews.com.au/news/australian-computer-museum-society-collection-faces-bulldozers-499452 They had (and are having) a free-for-all to get rid of stuff. I haven't been out there but I'm told that most of the valuable stuff has gone and what's left is shelves of old monitors and mouldy manuals. It's a sad end but it appears the museum contents haven't been curated or stored properly for a long time. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From perry at piermont.com Mon Aug 6 09:18:18 2018 From: perry at piermont.com (Perry E. Metzger) Date: Sun, 5 Aug 2018 19:18:18 -0400 Subject: [TUHS] In Memoriam: Per Brinch Hansen In-Reply-To: <201808021244.w72CiuU4025022@tahoe.cs.Dartmouth.EDU> References: <201808021244.w72CiuU4025022@tahoe.cs.Dartmouth.EDU> Message-ID: <20180805191818.0ac05b0f@jabberwock.cb.piermont.com> On Thu, 02 Aug 2018 08:44:56 -0400 Doug McIlroy wrote: > A tangential connection to early Unix experience: > > My collection of early computer manuals includes Brinch Hansen's > manual for the RC 4000, which stands out for its precise > description of the CPU logic--in Algol 60! It's the only manual I > have seen that offers a good-to-the-last-bit formal description of > the hardware. > > DEC presented something of the sort for the PDP-11, but punted where > the woods got thick. When I wanted to know how they computed the > last bit of floating-point results, I got no satisfaction. Amidst a > thorough description of addressing came this formulation of the > actual computation: "form floating point result". For those that are familiar with the RISC V architecture, there's a formal specification of the architecture that was done in a system built on Coq, and also a fully formally verified translation of the specification into RTL. (The spec didn't include floating point as of about a year ago but it may by now.) A good overview of the system involved is here: http://plv.csail.mit.edu/kami/papers/icfp17.pdf Followups might belong on the coff list, not sure. Perry -- Perry E. Metzger perry at piermont.com From wkt at tuhs.org Mon Aug 6 09:53:19 2018 From: wkt at tuhs.org (Warren Toomey) Date: Mon, 6 Aug 2018 09:53:19 +1000 Subject: [TUHS] Latest Kernighan interview on Youtube Message-ID: <20180805235319.GA14811@minnie.tuhs.org> in 3 parts: https://www.youtube.com/watch?v=zmYhR8cUX90 https://www.youtube.com/watch?v=VVpRj3Po6K4 https://www.youtube.com/watch?v=E6vtRm5M8I0 Cheers, Warren From dave at horsfall.org Mon Aug 6 10:04:17 2018 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 6 Aug 2018 10:04:17 +1000 (EST) Subject: [TUHS] In Memoriam: Edsger Dijkstra, and happy birthday Jon Postel! Message-ID: What a weird day... We lost computer pioneer Edsger Dijkstra in 2002; he gave us ALGOL, structured programming, semaphores, and ranted against the GOTO statement (much to the distress of the Fortranites and their spaghetti coding). Oh, and a certain Prof. Goto used to complain that everybody wanted to eliminate him :-) However, we gained Jon Postel in 1943; with umpteen RFCs to his name, he could pretty much be described as the Father of the Internet. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From jnc at mercury.lcs.mit.edu Mon Aug 6 11:15:45 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 5 Aug 2018 21:15:45 -0400 (EDT) Subject: [TUHS] In Memoriam: Edsger Dijkstra, and happy birthday Jon Postel! Message-ID: <20180806011545.29C1F18C09A@mercury.lcs.mit.edu> > From: Dave Horsfall > However, we gained Jon Postel in 1943; with umpteen RFCs to his name, he > could pretty much be described as the Father of the Internet. The problem with using the number of documents as a gauge for that is that Jon often acted as scribe, so that for many things published under his name, he was acting more as editor. As to who (if anyone) does deserve that title, I'm also not sure about the importance of Cerf and Kahn. NOTE: I am not saying they _didn't_ make the key contribution - I just haven't looked into it in enough detail to say. For example, before the TCP/IP effort got rolling, there was something called the International Packet Network Working Group (INWG) which had a big role, but which has been poorly documented. There's a note called "The Internet: On its International Origins and Collaborative Vision" by Rhonda Hauben, available here: http://www.columbia.edu/~rh120/other/misc/haubenpap.rtf which covers it some, and there's a more recent thing by Alex Mackenzie which is probably better, but I'm too lazy to go find it. Louis Pouzin (or whoever it was at CYCLADES who actually had the idea to move the reliability out of the packet switches, and into the hosts), also would have a good claim to the title. Anyway, sorry for the offtopic, but my 'fake history' alarm went off... Noel From steve at quintile.net Mon Aug 6 20:50:50 2018 From: steve at quintile.net (Steve Simon) Date: Mon, 6 Aug 2018 11:50:50 +0100 Subject: [TUHS] TUHS Digest, Vol 33, Issue 5 In-Reply-To: References: Message-ID: <5697FAD4-4D4C-47CC-8288-C4A022C426BB@quintile.net> well spec’ed machines where more common in the past. we had all the source for the interdata 3210 at college. we had the edition 7 source, the driver source, the diagnostic tape source, and even all the schematics. two of the lecturers even upgraded it from 1mb to 4mb of RAM, complete with address decoders on their backs with their legs in the air. -Steve > On 6 Aug 2018, at 03:00, tuhs-request at minnie.tuhs.org wrote: > > Send TUHS mailing list submissions to > tuhs at minnie.tuhs.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs > or, via email, send a message with subject or body 'help' to > tuhs-request at minnie.tuhs.org > > You can reach the person managing the list at > tuhs-owner at minnie.tuhs.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of TUHS digest..." > > > Today's Topics: > > 1. Re: In Memoriam: Per Brinch Hansen (Perry E. Metzger) > 2. Latest Kernighan interview on Youtube (Warren Toomey) > 3. In Memoriam: Edsger Dijkstra, and happy birthday Jon Postel! > (Dave Horsfall) > 4. Re: In Memoriam: Edsger Dijkstra, and happy birthday Jon > Postel! (Noel Chiappa) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 5 Aug 2018 19:18:18 -0400 > From: "Perry E. Metzger" > To: Doug McIlroy > Cc: tuhs at tuhs.org > Subject: Re: [TUHS] In Memoriam: Per Brinch Hansen > Message-ID: <20180805191818.0ac05b0f at jabberwock.cb.piermont.com> > Content-Type: text/plain; charset=US-ASCII > > On Thu, 02 Aug 2018 08:44:56 -0400 Doug McIlroy > wrote: >> A tangential connection to early Unix experience: >> >> My collection of early computer manuals includes Brinch Hansen's >> manual for the RC 4000, which stands out for its precise >> description of the CPU logic--in Algol 60! It's the only manual I >> have seen that offers a good-to-the-last-bit formal description of >> the hardware. >> >> DEC presented something of the sort for the PDP-11, but punted where >> the woods got thick. When I wanted to know how they computed the >> last bit of floating-point results, I got no satisfaction. Amidst a >> thorough description of addressing came this formulation of the >> actual computation: "form floating point result". > > For those that are familiar with the RISC V architecture, there's a > formal specification of the architecture that was done in a system > built on Coq, and also a fully formally verified translation of the > specification into RTL. (The spec didn't include floating point as of > about a year ago but it may by now.) > > A good overview of the system involved is here: > > http://plv.csail.mit.edu/kami/papers/icfp17.pdf > > Followups might belong on the coff list, not sure. > > Perry > -- > Perry E. Metzger perry at piermont.com > > > ------------------------------ > > Message: 2 > Date: Mon, 6 Aug 2018 09:53:19 +1000 > From: Warren Toomey > To: tuhs at tuhs.org > Subject: [TUHS] Latest Kernighan interview on Youtube > Message-ID: <20180805235319.GA14811 at minnie.tuhs.org> > Content-Type: text/plain; charset=us-ascii > > in 3 parts: > > https://www.youtube.com/watch?v=zmYhR8cUX90 > https://www.youtube.com/watch?v=VVpRj3Po6K4 > https://www.youtube.com/watch?v=E6vtRm5M8I0 > > Cheers, Warren > > > ------------------------------ > > Message: 3 > Date: Mon, 6 Aug 2018 10:04:17 +1000 (EST) > From: Dave Horsfall > To: The Eunuchs Hysterical Society > Subject: [TUHS] In Memoriam: Edsger Dijkstra, and happy birthday Jon > Postel! > Message-ID: > > Content-Type: text/plain; charset=US-ASCII; format=flowed > > What a weird day... > > We lost computer pioneer Edsger Dijkstra in 2002; he gave us ALGOL, > structured programming, semaphores, and ranted against the GOTO statement > (much to the distress of the Fortranites and their spaghetti coding). > Oh, and a certain Prof. Goto used to complain that everybody wanted to > eliminate him :-) > > However, we gained Jon Postel in 1943; with umpteen RFCs to his name, he > could pretty much be described as the Father of the Internet. > > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." > > > ------------------------------ > > Message: 4 > Date: Sun, 5 Aug 2018 21:15:45 -0400 (EDT) > From: jnc at mercury.lcs.mit.edu (Noel Chiappa) > To: tuhs at tuhs.org > Cc: jnc at mercury.lcs.mit.edu > Subject: Re: [TUHS] In Memoriam: Edsger Dijkstra, and happy birthday > Jon Postel! > Message-ID: <20180806011545.29C1F18C09A at mercury.lcs.mit.edu> > >> From: Dave Horsfall > >> However, we gained Jon Postel in 1943; with umpteen RFCs to his name, he >> could pretty much be described as the Father of the Internet. > > The problem with using the number of documents as a gauge for that is that Jon > often acted as scribe, so that for many things published under his name, he > was acting more as editor. > > As to who (if anyone) does deserve that title, I'm also not sure about the > importance of Cerf and Kahn. NOTE: I am not saying they _didn't_ make the key > contribution - I just haven't looked into it in enough detail to say. > > For example, before the TCP/IP effort got rolling, there was something called > the International Packet Network Working Group (INWG) which had a big role, > but which has been poorly documented. There's a note called "The Internet: On > its International Origins and Collaborative Vision" by Rhonda Hauben, > available here: > > http://www.columbia.edu/~rh120/other/misc/haubenpap.rtf > > which covers it some, and there's a more recent thing by Alex Mackenzie which > is probably better, but I'm too lazy to go find it. > > Louis Pouzin (or whoever it was at CYCLADES who actually had the idea to move > the reliability out of the packet switches, and into the hosts), also would > have a good claim to the title. > > > Anyway, sorry for the offtopic, but my 'fake history' alarm went off... > > Noel > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs > > ------------------------------ > > End of TUHS Digest, Vol 33, Issue 5 > *********************************** From jnc at mercury.lcs.mit.edu Mon Aug 6 23:06:56 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 6 Aug 2018 09:06:56 -0400 (EDT) Subject: [TUHS] TUHS Digest, Vol 33, Issue 5 Message-ID: <20180806130656.79BF718C09A@mercury.lcs.mit.edu> > From: Steve Simon > well spec'ed machines where more common in the past. Err, engineering data is not the same thing as a formal specification. If not, almost every computer built could be said to have a 'formal spec' - there usually are engineering documents for anything that was produced in any sort of quantity. Also, whether said engineering info is publicly available or not (which seems to be another of your observations) is an orthogonal axis. Noel From bakul at bitblocks.com Tue Aug 7 01:52:17 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Mon, 6 Aug 2018 08:52:17 -0700 Subject: [TUHS] TUHS Digest, Vol 33, Issue 5 In-Reply-To: <20180806130656.79BF718C09A@mercury.lcs.mit.edu> References: <20180806130656.79BF718C09A@mercury.lcs.mit.edu> Message-ID: <2EDF09AC-F35B-461A-AB53-9DEB29D9AE25@bitblocks.com> On Aug 6, 2018, at 6:06 AM, Noel Chiappa wrote: > >> From: Steve Simon > >> well spec'ed machines where more common in the past. > > Err, engineering data is not the same thing as a formal specification. If not, > almost every computer built could be said to have a 'formal spec' - there > usually are engineering documents for anything that was produced in any sort > of quantity. What counts as a "formal spec"? Is it like Justice Potter Stewart's "I know it when I see it" definition or something better? > Also, whether said engineering info is publicly available or not (which seems > to be another of your observations) is an orthogonal axis. Agree. From hellwig.geisse at mni.thm.de Tue Aug 7 02:30:30 2018 From: hellwig.geisse at mni.thm.de (Hellwig Geisse) Date: Mon, 06 Aug 2018 18:30:30 +0200 Subject: [TUHS] TUHS Digest, Vol 33, Issue 5 In-Reply-To: <2EDF09AC-F35B-461A-AB53-9DEB29D9AE25@bitblocks.com> References: <20180806130656.79BF718C09A@mercury.lcs.mit.edu> <2EDF09AC-F35B-461A-AB53-9DEB29D9AE25@bitblocks.com> Message-ID: <1533573030.3671.98.camel@mni.thm.de> On Mo, 2018-08-06 at 08:52 -0700, Bakul Shah wrote: > > What counts as a "formal spec"? Is it like Justice Potter Stewart's > "I know it when I see it" definition or something better? > For me, a "formal spec" should serve two goals: 1) You can reason about the thing that is specified. 2) The spec can be "executed" (i.e., there is an    interpreting mechanism, which lets the spec behave    like the real thing). Hellwig From jnc at mercury.lcs.mit.edu Tue Aug 7 03:22:54 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 6 Aug 2018 13:22:54 -0400 (EDT) Subject: [TUHS] TUHS Digest, Vol 33, Issue 5 Message-ID: <20180806172254.340F618C09A@mercury.lcs.mit.edu> > From: Bakul Shah > What counts as a "formal spec"? If you aren't familiar with the work in the field (it's been going on long enough, it was around when I was an undergrad), some of the earlier messages in the thread, e.g.: https://minnie.tuhs.org//pipermail/tuhs/2018-August/014365.html might provide some thing you could follow. (I'm not into that stuff, so I point you in the right direction.) Noel From jnc at mercury.lcs.mit.edu Tue Aug 7 03:26:24 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 6 Aug 2018 13:26:24 -0400 (EDT) Subject: [TUHS] TUHS Digest, Vol 33, Issue 5 Message-ID: <20180806172624.0453318C09A@mercury.lcs.mit.edu> > I'm not into that stuff, so I point you in the right direction. ^ Sorry, lost a "can't" there. Noel From svyatoslav.mishyn at gmail.com Tue Aug 7 04:26:21 2018 From: svyatoslav.mishyn at gmail.com (Svyatoslav Mishyn) Date: Mon, 6 Aug 2018 21:26:21 +0300 Subject: [TUHS] Latest Kernighan interview on Youtube In-Reply-To: <20180805235319.GA14811@minnie.tuhs.org> References: <20180805235319.GA14811@minnie.tuhs.org> Message-ID: <20180806182620.GA47144@cq58.lan> (Mon, 06 Aug 09:53) Warren Toomey: > in 3 parts: > > https://www.youtube.com/watch?v=zmYhR8cUX90 > https://www.youtube.com/watch?v=VVpRj3Po6K4 > https://www.youtube.com/watch?v=E6vtRm5M8I0 Thank you! -- https://www.juef.space/ From brian at zick.io Tue Aug 7 06:53:33 2018 From: brian at zick.io (Brian Zick) Date: Mon, 06 Aug 2018 21:53:33 +0100 Subject: [TUHS] Origins of shell prompt suffixes % $ > # Message-ID: <1533588813.1868321.1465431536.01CE36BC@webmail.messagingengine.com> Hi, I usually just lurk on this list, but I've been curious lately about the origin of the symbols at the end of various interactive prompts. ksh (etc), bash, sh use $ for non-root, and # for root csh, tcsh and zsh use % for non-root and # for root fish and things like mysql, ftp, and interactive shells for a lot of scripting languages use > rc uses ; Where do these different conventions originate? B From ron at ronnatalie.com Tue Aug 7 07:16:21 2018 From: ron at ronnatalie.com (ron at ronnatalie.com) Date: Mon, 6 Aug 2018 17:16:21 -0400 Subject: [TUHS] Origins of shell prompt suffixes % $ > # In-Reply-To: <1533588813.1868321.1465431536.01CE36BC@webmail.messagingengine.com> References: <1533588813.1868321.1465431536.01CE36BC@webmail.messagingengine.com> Message-ID: <01c101d42dca$baa2eb70$2fe8c250$@ronnatalie.com> The early shells (Thompson, Mashey) used "% " for regular user (and # for root). The Thompson shell didn't have a setable prompt. The Bourne shell (V7) had setable PS1 (start of command) and PS2 (continuation prompts) and set the to "$ " and "> " respectively. Again # was used for root. -----Original Message----- From: TUHS On Behalf Of Brian Zick Sent: Monday, August 6, 2018 4:54 PM To: tuhs at minnie.tuhs.org Subject: [TUHS] Origins of shell prompt suffixes % $ > # Hi, I usually just lurk on this list, but I've been curious lately about the origin of the symbols at the end of various interactive prompts. ksh (etc), bash, sh use $ for non-root, and # for root csh, tcsh and zsh use % for non-root and # for root fish and things like mysql, ftp, and interactive shells for a lot of scripting languages use > rc uses ; Where do these different conventions originate? B From henry.r.bent at gmail.com Tue Aug 7 07:33:07 2018 From: henry.r.bent at gmail.com (Henry Bent) Date: Mon, 6 Aug 2018 17:33:07 -0400 Subject: [TUHS] Origins of shell prompt suffixes % $ > # In-Reply-To: <01c101d42dca$baa2eb70$2fe8c250$@ronnatalie.com> References: <1533588813.1868321.1465431536.01CE36BC@webmail.messagingengine.com> <01c101d42dca$baa2eb70$2fe8c250$@ronnatalie.com> Message-ID: On 6 August 2018 at 17:16, wrote: > The early shells (Thompson, Mashey) used "% " for regular user (and # for > root). The Thompson shell didn't have a setable prompt. > The Bourne shell (V7) had setable PS1 (start of command) and PS2 > (continuation prompts) and set the to "$ " and "> " respectively. Again > # was used for root Okay, but why did Bourne switch from "%" to "$"? Was it to inform the user that they were using the new shell as opposed to the old one, or was there some other reasoning behind the switch? -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Tue Aug 7 10:51:12 2018 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 7 Aug 2018 10:51:12 +1000 (EST) Subject: [TUHS] In Memoriam: Edsger Dijkstra, and happy birthday Jon Postel! In-Reply-To: <20180806011545.29C1F18C09A@mercury.lcs.mit.edu> References: <20180806011545.29C1F18C09A@mercury.lcs.mit.edu> Message-ID: On Sun, 5 Aug 2018, Noel Chiappa wrote: > The problem with using the number of documents as a gauge for that is > that Jon often acted as scribe, so that for many things published under > his name, he was acting more as editor. OK, I'll think of some way of modifying it (I am always open to corrections, but preferably offline); you won't believe the number of "history" sites I've seen that directly contradict each other (even when taking UTC/US/local time into account, and I try and use local time wherever possible). -- Dave From ggm at algebras.org Tue Aug 7 11:10:09 2018 From: ggm at algebras.org (George Michaelson) Date: Tue, 7 Aug 2018 11:10:09 +1000 Subject: [TUHS] Origins of shell prompt suffixes % $ > # In-Reply-To: References: <1533588813.1868321.1465431536.01CE36BC@webmail.messagingengine.com> <01c101d42dca$baa2eb70$2fe8c250$@ronnatalie.com> Message-ID: Off topic to one side: I was told, but cannot recall by whom, that the csh decision to use % when the bourne shell had $ was to make it clear which syntax was expected by the user. tcsh inherited from csh. Bash/Zsh/Ash/Ksh inherited from sh. Obviously that is outside the strict terms of the question and lies in hands, not this lists main focus. -G On Tue, Aug 7, 2018 at 7:33 AM, Henry Bent wrote: > On 6 August 2018 at 17:16, wrote: >> >> The early shells (Thompson, Mashey) used "% " for regular user (and # for >> root). The Thompson shell didn't have a setable prompt. >> The Bourne shell (V7) had setable PS1 (start of command) and PS2 >> (continuation prompts) and set the to "$ " and "> " respectively. Again # >> was used for root > > > Okay, but why did Bourne switch from "%" to "$"? Was it to inform the user > that they were using the new shell as opposed to the old one, or was there > some other reasoning behind the switch? > > -Henry From ron at ronnatalie.com Tue Aug 7 11:10:28 2018 From: ron at ronnatalie.com (ron at ronnatalie.com) Date: Mon, 6 Aug 2018 21:10:28 -0400 Subject: [TUHS] Origins of shell prompt suffixes % $ > # In-Reply-To: References: <1533588813.1868321.1465431536.01CE36BC@webmail.messagingengine.com> <01c101d42dca$baa2eb70$2fe8c250$@ronnatalie.com> Message-ID: <014e01d42deb$6e4ad730$4ae08590$@ronnatalie.com> I suspect it was Steve’s personal preference on the Bourne shell. There’s next to no comments in the thing and the document on the shell just mentions the defaults and that you can change it. Just for completeness, the PWBSH appears to allow the prompt to be changed with a command line argument. We used to have a shell called “uu” at Hopkins which was sort of a prehistoric “sudo” that ran certain commands (icheck/dcheck/etc…) as root while setting back to the regular uid for others. It used “@ “ for a prompt. From: TUHS On Behalf Of Henry Bent Sent: Monday, August 6, 2018 5:33 PM To: TUHS main list Subject: Re: [TUHS] Origins of shell prompt suffixes % $ > # On 6 August 2018 at 17:16, > wrote: The early shells (Thompson, Mashey) used "% " for regular user (and # for root). The Thompson shell didn't have a setable prompt. The Bourne shell (V7) had setable PS1 (start of command) and PS2 (continuation prompts) and set the to "$ " and "> " respectively. Again # was used for root Okay, but why did Bourne switch from "%" to "$"? Was it to inform the user that they were using the new shell as opposed to the old one, or was there some other reasoning behind the switch? -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Tue Aug 7 11:12:52 2018 From: ron at ronnatalie.com (ron at ronnatalie.com) Date: Mon, 6 Aug 2018 21:12:52 -0400 Subject: [TUHS] Origins of shell prompt suffixes % $ > # In-Reply-To: References: <1533588813.1868321.1465431536.01CE36BC@webmail.messagingengine.com> <01c101d42dca$baa2eb70$2fe8c250$@ronnatalie.com> Message-ID: <015d01d42deb$c4a8ac60$4dfa0520$@ronnatalie.com> > I was told, but cannot recall by whom, that the csh decision to use % when the bourne shell had $ was to make it clear which syntax was expected by the user. tcsh inherited from csh. Bash/Zsh/Ash/Ksh inherited from sh. I don't buy it. CSH predates the Bourne shell by a year. I suspect it used % because the V6 shell it replaced used %. From michael at kjorling.se Tue Aug 7 16:54:54 2018 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Tue, 7 Aug 2018 06:54:54 +0000 Subject: [TUHS] Origins of shell prompt suffixes % $ > # In-Reply-To: <1533588813.1868321.1465431536.01CE36BC@webmail.messagingengine.com> References: <1533588813.1868321.1465431536.01CE36BC@webmail.messagingengine.com> Message-ID: <20180807065453.jjnsx3cunjug5q3e@h-174-65.A328.priv.bahnhof.se> On 6 Aug 2018 21:53 +0100, from brian at zick.io (Brian Zick): > rc uses ; Not sure what came first, and not up to digging out the history books, but these days, a plain `;` for a prompt has a distinct advantage in that you can copy the whole line and paste it into another shell, and the shell will do The Right Thing (tm) as long as (as is, I believe, done by all of the major shells at least) it uses `;` for command separation. -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “The most dangerous thought that you can have as a creative person is to think you know what you’re doing.” (Bret Victor) From khm at sciops.net Tue Aug 7 17:31:36 2018 From: khm at sciops.net (Kurt H Maier) Date: Tue, 7 Aug 2018 00:31:36 -0700 Subject: [TUHS] Origins of shell prompt suffixes % $ > # In-Reply-To: <1533588813.1868321.1465431536.01CE36BC@webmail.messagingengine.com> References: <1533588813.1868321.1465431536.01CE36BC@webmail.messagingengine.com> Message-ID: <20180807073136.GA37082@wopr> On Mon, Aug 06, 2018 at 09:53:33PM +0100, Brian Zick wrote: > > rc uses ; Does it? 10th edition Unix and Plan 9 rc both have ('% ' ' ') as the default value of $prompt. At least that's how it's described in the manual. None of the v8/9/10 tarballs in the archive contain rc code, but some contain manual source, and those describe % prompts. I've seen other references to ; (presumably ('; ' ' ')) as the rc prompt but I've never seen it in the wild. Does anyone here know what the story is? khm From arnold at skeeve.com Tue Aug 7 17:50:21 2018 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 07 Aug 2018 01:50:21 -0600 Subject: [TUHS] Origins of shell prompt suffixes % $ > # In-Reply-To: <20180807073136.GA37082@wopr> References: <1533588813.1868321.1465431536.01CE36BC@webmail.messagingengine.com> <20180807073136.GA37082@wopr> Message-ID: <201808070750.w777oLwj016715@freefriends.org> Kurt H Maier wrote: > On Mon, Aug 06, 2018 at 09:53:33PM +0100, Brian Zick wrote: > > > > rc uses ; > > Does it? 10th edition Unix and Plan 9 rc both have ('% ' ' ') as the > default value of $prompt. At least that's how it's described in the > manual. None of the v8/9/10 tarballs in the archive contain rc code, > but some contain manual source, and those describe % prompts. > > I've seen other references to ; (presumably ('; ' ' ')) as the rc > prompt but I've never seen it in the wild. Does anyone here know what > the story is? > > khm I believe that Tom Duff's rc does indeed use ('% ' ' '). But I think that Byron Rakitsis's version changed the default to ('; ' ' ') exactly for the reason that it's copyable/pastable. HTH, Arnold From bakul at bitblocks.com Tue Aug 7 17:57:11 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Tue, 07 Aug 2018 00:57:11 -0700 Subject: [TUHS] Origins of shell prompt suffixes % $ > # In-Reply-To: Your message of "Tue, 07 Aug 2018 00:31:36 -0700." <20180807073136.GA37082@wopr> References: <1533588813.1868321.1465431536.01CE36BC@webmail.messagingengine.com> <20180807073136.GA37082@wopr> Message-ID: <20180807075718.C379E156E408@mail.bitblocks.com> On Tue, 07 Aug 2018 00:31:36 -0700 Kurt H Maier wrote: > On Mon, Aug 06, 2018 at 09:53:33PM +0100, Brian Zick wrote: > > > > rc uses ; > > Does it? 10th edition Unix and Plan 9 rc both have ('% ' ' ') as the > default value of $prompt. At least that's how it's described in the > manual. None of the v8/9/10 tarballs in the archive contain rc code, > but some contain manual source, and those describe % prompts. > > I've seen other references to ; (presumably ('; ' ' ')) as the rc > prompt but I've never seen it in the wild. Does anyone here know what > the story is? The es shell (by Haar and Rakitzis) used ; - the reason (as per the man page)is that a user can cut-n-paste a previous line to rexecute it (for the same reason people use term% and cpu% functions to execute their args). Es syntax was derived from rc, which may be why the confusion. From michael at kjorling.se Tue Aug 7 18:02:56 2018 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Tue, 7 Aug 2018 08:02:56 +0000 Subject: [TUHS] Origins of shell prompt suffixes % $ > # In-Reply-To: <20180807065453.jjnsx3cunjug5q3e@h-174-65.A328.priv.bahnhof.se> References: <1533588813.1868321.1465431536.01CE36BC@webmail.messagingengine.com> <20180807065453.jjnsx3cunjug5q3e@h-174-65.A328.priv.bahnhof.se> Message-ID: <20180807080256.lgqaevcah2a7sn2t@h-174-65.A328.priv.bahnhof.se> On 7 Aug 2018 06:54 +0000, from michael at kjorling.se (Michael Kjörling): > the shell will do The Right Thing (tm) I suspect I must stand corrected on this. Turns out that at least GNU bash 4.4.12(1) seems to not like a `;` at the beginning of the command line. $ /bin/bash --version | head -n1 GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu) $ /bin/bash $ ; true bash: syntax error near unexpected token `;' $ echo $? 2 $ Hopefully other shells are more sane. -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “The most dangerous thought that you can have as a creative person is to think you know what you’re doing.” (Bret Victor) From dave at horsfall.org Tue Aug 7 18:23:37 2018 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 7 Aug 2018 18:23:37 +1000 (EST) Subject: [TUHS] Origins of shell prompt suffixes % $ > # In-Reply-To: <20180807080256.lgqaevcah2a7sn2t@h-174-65.A328.priv.bahnhof.se> References: <1533588813.1868321.1465431536.01CE36BC@webmail.messagingengine.com> <20180807065453.jjnsx3cunjug5q3e@h-174-65.A328.priv.bahnhof.se> <20180807080256.lgqaevcah2a7sn2t@h-174-65.A328.priv.bahnhof.se> Message-ID: On Tue, 7 Aug 2018, Michael Kjörling wrote: > Hopefully other shells are more sane. The MacBook here runs GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin16) and is equally busted, as is plain "sh" on both the Mac and FreeBSD (I can't be bothered checking the Penguin); I use ZSH on FreeBSD and it does The Right Thing (tm), as does ZSH on the Mac. -- Dave From katolaz at freaknet.org Tue Aug 7 18:37:23 2018 From: katolaz at freaknet.org (KatolaZ) Date: Tue, 7 Aug 2018 10:37:23 +0200 Subject: [TUHS] Origins of shell prompt suffixes % $ > # In-Reply-To: References: <1533588813.1868321.1465431536.01CE36BC@webmail.messagingengine.com> <20180807065453.jjnsx3cunjug5q3e@h-174-65.A328.priv.bahnhof.se> <20180807080256.lgqaevcah2a7sn2t@h-174-65.A328.priv.bahnhof.se> Message-ID: <20180807083723.zuokdnu2zxtn57ov@katolaz.homeunix.net> On Tue, Aug 07, 2018 at 06:23:37PM +1000, Dave Horsfall wrote: > On Tue, 7 Aug 2018, Michael Kjörling wrote: > > > Hopefully other shells are more sane. > > The MacBook here runs GNU bash, version 3.2.57(1)-release > (x86_64-apple-darwin16) and is equally busted, as is plain "sh" on both the > Mac and FreeBSD (I can't be bothered checking the Penguin); I use ZSH on > FreeBSD and it does The Right Thing (tm), as does ZSH on the Mac. > > -- Dave I have tried all the shells I have on my linux box. It turns out that only ksh and zsh like a ";" at the beginning of the line. Otherwise, bash, busybox, ash/dash, mksk, posh, and yash can't bear it. I really don't see the point of using ";", especially if you need to make it clear if a command needs to be run by root. $ ;-P sh: 1: Syntax error: ";" unexpected -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From scj at yaccman.com Tue Aug 7 07:19:31 2018 From: scj at yaccman.com (Steve Johnson) Date: Mon, 06 Aug 2018 14:19:31 -0700 Subject: [TUHS] TUHS Digest, Vol 33, Issue 5 In-Reply-To: <1533573030.3671.98.camel@mni.thm.de> Message-ID: <50772e199f3dcc5d4eba34d17322b5aef0aa0441@webmail.yaccman.com> I take a somewhat more relaxed view of what a spec should be: It should describe a program with enough completeness that a competent programmer could write it from the spec alone. Each section of the spec should be capable of being tested. If all the tests for all the sections pass, then the program is ready for general use. The formal systems I have seen would roll over and die when presented with even a simple compiler.  Additionally, being able to specify that a particular function be carried out by a heapsort, for example, would require that the formalism could describe the heapsort and prove it correct.  These don't grow on trees... Steve ----- Original Message ----- From: "Hellwig Geisse" To: Cc: Sent:Mon, 06 Aug 2018 18:30:30 +0200 Subject:Re: [TUHS] TUHS Digest, Vol 33, Issue 5 On Mo, 2018-08-06 at 08:52 -0700, Bakul Shah wrote: > > What counts as a "formal spec"? Is it like Justice Potter Stewart's > "I know it when I see it" definition or something better? > For me, a "formal spec" should serve two goals: 1) You can reason about the thing that is specified. 2) The spec can be "executed" (i.e., there is an    interpreting mechanism, which lets the spec behave    like the real thing). Hellwig -------------- next part -------------- An HTML attachment was scrubbed... URL: From dot at dotat.at Tue Aug 7 20:45:37 2018 From: dot at dotat.at (Tony Finch) Date: Tue, 7 Aug 2018 11:45:37 +0100 Subject: [TUHS] Origins of shell prompt suffixes % $ > # In-Reply-To: <20180807080256.lgqaevcah2a7sn2t@h-174-65.A328.priv.bahnhof.se> References: <1533588813.1868321.1465431536.01CE36BC@webmail.messagingengine.com> <20180807065453.jjnsx3cunjug5q3e@h-174-65.A328.priv.bahnhof.se> <20180807080256.lgqaevcah2a7sn2t@h-174-65.A328.priv.bahnhof.se> Message-ID: Michael Kjörling wrote: > > I suspect I must stand corrected on this. Turns out that at least GNU > bash 4.4.12(1) seems to not like a `;` at the beginning of the command > line. This is a consequence of the POSIX shell grammar, which doesn't allow empty commands. http://pubs.opengroup.org/onlinepubs/9699919799.2013edition/utilities/V3_chap02.html#tag_18_10 The prompt I have used since about 1997 (and I can't remember where I got it from - somewhere on Usenet, probably) in its most distilled form is :; although in practice I have a load of extra fluff for username, hostname, CWD, etc. usw. Tony. -- f.anthony.n.finch http://dotat.at/ Fair Isle, Faeroes: South or southwest 4 or 5, occasionally 6 for a time. Slight or moderate, occasionally rough for a time. Showers. Moderate or good. From pete at dunnington.plus.com Tue Aug 7 21:24:20 2018 From: pete at dunnington.plus.com (Pete Turnbull) Date: Tue, 7 Aug 2018 12:24:20 +0100 Subject: [TUHS] Origins of shell prompt suffixes % $ > # In-Reply-To: <20180807080256.lgqaevcah2a7sn2t@h-174-65.A328.priv.bahnhof.se> References: <1533588813.1868321.1465431536.01CE36BC@webmail.messagingengine.com> <20180807065453.jjnsx3cunjug5q3e@h-174-65.A328.priv.bahnhof.se> <20180807080256.lgqaevcah2a7sn2t@h-174-65.A328.priv.bahnhof.se> Message-ID: On 07/08/2018 09:02, Michael Kjörling wrote: > On 7 Aug 2018 06:54 +0000, from michael at kjorling.se (Michael Kjörling): >> the shell will do The Right Thing (tm) > > I suspect I must stand corrected on this. Turns out that at least GNU > bash 4.4.12(1) seems to not like a `;` at the beginning of the command > line. > > $ /bin/bash --version | head -n1 > GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu) > $ /bin/bash > $ ; true > bash: syntax error near unexpected token `;' > $ echo $? > 2 > $ > > Hopefully other shells are more sane. ksh and sh on an IRIX system don't like it either: $ ; ksh: syntax error: `;' unexpected $ csh and tcsh don't mind. Of course it works in rc itself, which is the point, really, and I wonder how often anyone pasted from one shell into another. All the rc use I've seen did indeed use "; " as the prompt, but that was all at the University of York, starting in 1993. -- Pete Pete Turnbull From doug at cs.dartmouth.edu Tue Aug 7 22:34:16 2018 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Tue, 07 Aug 2018 08:34:16 -0400 Subject: [TUHS] Origins of shell prompt suffixes % $ > # Message-ID: <201808071234.w77CYGWG112787@tahoe.cs.Dartmouth.EDU> > The Bourne shell (V7) had setable PS1 (start of command) and PS2 (continuation prompts) When PS2 came on the scene, Bob Morris noticed that it most often appeared because of a missing close quote. Therefore he set PS2="hit interrupt". From brian at zick.io Wed Aug 8 01:15:07 2018 From: brian at zick.io (Brian Zick) Date: Tue, 07 Aug 2018 16:15:07 +0100 Subject: [TUHS] Origins of shell prompt suffixes % $ > # In-Reply-To: <20180807073136.GA37082@wopr> References: <1533588813.1868321.1465431536.01CE36BC@webmail.messagingengine.com> <20180807073136.GA37082@wopr> Message-ID: <1533654907.3701374.1466337000.53253732@webmail.messagingengine.com> > > rc uses ; > > Does it? 10th edition Unix and Plan 9 rc both have ('% ' ' ') as the > default value of $prompt. At least that's how it's described in the > manual. In NetBSD 7 the default is ';', but I don't see any reference to a default $prompt in the manual on that system. I wonder if this was a change unique to Berkeley. B From jpl.jpl at gmail.com Wed Aug 8 01:52:57 2018 From: jpl.jpl at gmail.com (John P. Linderman) Date: Tue, 7 Aug 2018 10:52:57 -0500 Subject: [TUHS] Origins of shell prompt suffixes % $ > # In-Reply-To: <1533654907.3701374.1466337000.53253732@webmail.messagingengine.com> References: <1533588813.1868321.1465431536.01CE36BC@webmail.messagingengine.com> <20180807073136.GA37082@wopr> <1533654907.3701374.1466337000.53253732@webmail.messagingengine.com> Message-ID: On vacation, with just an iPad keyboard, so I apologize for not doing more digging. As I noted, when taking the blame for the Great Echo Schism, my early exposure to a hp2640 terminal that allowed “rentry” of a previous command was partly to blame. It also led me to use a PS1 ending in @, the default line-kill. When I reentered a command, the @ wiped out the prompt stuff, and only the command survived. On Tue, Aug 7, 2018 at 10:15 AM Brian Zick wrote: > > > rc uses ; > > > > Does it? 10th edition Unix and Plan 9 rc both have ('% ' ' ') as the > > default value of $prompt. At least that's how it's described in the > > manual. > > In NetBSD 7 the default is ';', but I don't see any reference to a default > $prompt in the manual on that system. I wonder if this was a change unique > to Berkeley. > > B > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lyndon at orthanc.ca Wed Aug 8 03:35:49 2018 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Tue, 7 Aug 2018 10:35:49 -0700 (PDT) Subject: [TUHS] Origins of shell prompt suffixes % $ > # In-Reply-To: References: <1533588813.1868321.1465431536.01CE36BC@webmail.messagingengine.com> <20180807065453.jjnsx3cunjug5q3e@h-174-65.A328.priv.bahnhof.se> <20180807080256.lgqaevcah2a7sn2t@h-174-65.A328.priv.bahnhof.se> Message-ID: > The prompt I have used since about 1997 (and I can't remember where I got > it from - somewhere on Usenet, probably) in its most distilled form is > > :; I forget where I stole this from. It lives in $home/lib/profile on my Plan9 machines: # /n/sources/contrib/lyndon/prompt.rc fn : {} fn setprompt { prompt = (': '^`{cat /dev/user}^@^`{cat /dev/sysname}^':'^`{pwd}^'; ' ' ') } fn cd { builtin cd $* && setprompt } setprompt From ca6c at bitmessage.ch Wed Aug 8 04:09:51 2018 From: ca6c at bitmessage.ch (=?utf-8?B?Q8OhZw==?=) Date: Tue, 07 Aug 2018 13:09:51 -0500 Subject: [TUHS] Origins of shell prompt suffixes % $ > # In-Reply-To: <1533654907.3701374.1466337000.53253732@webmail.messagingengine.com> References: <1533588813.1868321.1465431536.01CE36BC@webmail.messagingengine.com> <20180807073136.GA37082@wopr> <1533654907.3701374.1466337000.53253732@webmail.messagingengine.com> Message-ID: <20180807180951.K2s4d%ca6c@bitmessage.ch> Brian Zick wrote: > In NetBSD 7 the default is ';', but I don't see any reference to a > default $prompt in the manual on that system. It's not. '$' is default for sh and ksh, and '%' for csh. I think it maybe has never been ';'. -- caóc From arnold at skeeve.com Wed Aug 8 04:51:52 2018 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 07 Aug 2018 12:51:52 -0600 Subject: [TUHS] Origins of shell prompt suffixes % $ > # In-Reply-To: <20180807180951.K2s4d%ca6c@bitmessage.ch> References: <1533588813.1868321.1465431536.01CE36BC@webmail.messagingengine.com> <20180807073136.GA37082@wopr> <1533654907.3701374.1466337000.53253732@webmail.messagingengine.com> <20180807180951.K2s4d%ca6c@bitmessage.ch> Message-ID: <201808071851.w77Ipq46000843@freefriends.org> C??g wrote: > Brian Zick wrote: > > > In NetBSD 7 the default is ';', but I don't see any reference to a > > default $prompt in the manual on that system. > > It's not. '$' is default for sh and ksh, and '%' for csh. I think > it maybe has never been ';'. > > -- > ca??c > Brian was referring to rc(1) in NetBSD. I suspect it's Byron's rc and I think the default there is ';'. Arnold From ca6c at bitmessage.ch Wed Aug 8 05:00:22 2018 From: ca6c at bitmessage.ch (=?utf-8?B?Q8OhZw==?=) Date: Tue, 07 Aug 2018 14:00:22 -0500 Subject: [TUHS] Origins of shell prompt suffixes % $ > # In-Reply-To: <201808071851.w77Ipq46000843@freefriends.org> References: <1533588813.1868321.1465431536.01CE36BC@webmail.messagingengine.com> <20180807073136.GA37082@wopr> <1533654907.3701374.1466337000.53253732@webmail.messagingengine.com> <20180807180951.K2s4d%ca6c@bitmessage.ch> <201808071851.w77Ipq46000843@freefriends.org> Message-ID: <20180807190022.ERb1R%ca6c@bitmessage.ch> arnold wrote: > Brian was referring to rc(1) in NetBSD. I suspect it's Byron's rc > and I think the default there is ';'. rc is not shipped with NetBSD. There's Byron's rc in pkgsrc, so it could be that. -- caóc From brian at zick.io Wed Aug 8 05:06:03 2018 From: brian at zick.io (Brian Zick) Date: Tue, 07 Aug 2018 20:06:03 +0100 Subject: [TUHS] Origins of shell prompt suffixes % $ > # In-Reply-To: <20180807190022.ERb1R%ca6c@bitmessage.ch> References: <1533588813.1868321.1465431536.01CE36BC@webmail.messagingengine.com> <20180807073136.GA37082@wopr> <1533654907.3701374.1466337000.53253732@webmail.messagingengine.com> <20180807180951.K2s4d%ca6c@bitmessage.ch> <201808071851.w77Ipq46000843@freefriends.org> <20180807190022.ERb1R%ca6c@bitmessage.ch> Message-ID: <1533668763.3785029.1466613112.00F63787@webmail.messagingengine.com> On Tue, Aug 7, 2018, at 8:00 PM, Cág wrote: > arnold wrote: > > > Brian was referring to rc(1) in NetBSD. I suspect it's Byron's rc > > and I think the default there is ';'. > > rc is not shipped with NetBSD. There's Byron's rc in pkgsrc, so it could > be that. Yes, I was referring to the rc in pkgsrc. B From wkt at tuhs.org Wed Aug 8 18:37:06 2018 From: wkt at tuhs.org (Warren Toomey) Date: Wed, 8 Aug 2018 18:37:06 +1000 Subject: [TUHS] Sort of off-topic: usefulness of TUHS list and archive? Message-ID: <20180808083706.GA20345@minnie.tuhs.org> All, sorry that this is tangential to TUHS. I work at TAFE Queensland, which is a bit like a polytechnic or a U.S college. As a teacher, I have to demonstrate industry skills. I've listed my administration of the TUHS server over 25+ years. However, TAFE wants this to be verified by third parties: "Where possible the teacher could show that industry endorses his website and any if there are any testimonials/comments/reviews available on the site, these could also be provided." So, if you could pop a sentence or two in reply to this e-mail about the usefulness of the TUHS archive and the mailing list, that would be really helpful! Cheers & thanks in advance, Warren From don at DonHopkins.com Wed Aug 8 22:10:32 2018 From: don at DonHopkins.com (Don Hopkins) Date: Wed, 8 Aug 2018 14:10:32 +0200 Subject: [TUHS] TUHS Digest, Vol 33, Issue 7 In-Reply-To: References: Message-ID: Decades ago I made my prompt simply end with a newline, which perfectly and cleanly solves the problem of making it easy to copy and paste a whole line by multiple clicking in a terminal emulator to select the line, or by using line oriented commands in an emacs shell (or moving to the line and hitting return, which Emacs often regularly fucks up with its idiotic kludges to identify the prompt with invisible marks and regular expressions), without injecting any garbage characters into the beginning of the command line or requiring any extra mouse clicks, precision cursor targeting, or extra keystrokes. Using “;” or any other character as a prompt is an ugly hack, and doesn’t solve the problem thoroughly or cleanly. No matter what character you use as a prompt at the beginning of the line, it’s going to cause some problems, like semicolons building up each time you re-enter the line, or conflicts with built-in shell syntax (retch!), so the only logical (and most obvious) solution is not to use any characters at the beginning of the line at all, and just put the prompt on a line above on its own. There is no downside to that, unless it somehow offends your sense of aesthetics. (In which case you should get over it.) That’s the cleanest solution without any unpleasant side effects. I don’t understand why that solution isn’t the first thing shell users think of, and the default used by the shell — it’s so obvious. Maybe because people used to the shell are just so accustomed to having to deal with mashing together unpleasant hackey kludgy incompatible competing ad-hoc syntax that it would never occur to them that it’s possible to solve a problem by REMOVING punctuation and noise characters instead of ADDING more of them. -Don > On 8 Aug 2018, at 04:00, tuhs-request at minnie.tuhs.org wrote: > > Send TUHS mailing list submissions to > tuhs at minnie.tuhs.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs > or, via email, send a message with subject or body 'help' to > tuhs-request at minnie.tuhs.org > > You can reach the person managing the list at > tuhs-owner at minnie.tuhs.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of TUHS digest..." > Today's Topics: > > 1. Re: Origins of shell prompt suffixes % $ > # (Michael Kjörling) > 2. Re: Origins of shell prompt suffixes % $ > # (Kurt H Maier) > 3. Re: Origins of shell prompt suffixes % $ > # (arnold at skeeve.com) > 4. Re: Origins of shell prompt suffixes % $ > # (Bakul Shah) > 5. Re: Origins of shell prompt suffixes % $ > # (Michael Kjörling) > 6. Re: Origins of shell prompt suffixes % $ > # (Dave Horsfall) > 7. Re: Origins of shell prompt suffixes % $ > # (KatolaZ) > 8. Re: TUHS Digest, Vol 33, Issue 5 (Steve Johnson) > 9. Re: Origins of shell prompt suffixes % $ > # (Tony Finch) > 10. Re: Origins of shell prompt suffixes % $ > # (Pete Turnbull) > 11. Re: Origins of shell prompt suffixes % $ > # (Doug McIlroy) > 12. Re: Origins of shell prompt suffixes % $ > # (Brian Zick) > 13. Re: Origins of shell prompt suffixes % $ > # (John P. Linderman) > 14. Re: Origins of shell prompt suffixes % $ > # (Lyndon Nerenberg) > 15. Re: Origins of shell prompt suffixes % $ > # (Cág) > 16. Re: Origins of shell prompt suffixes % $ > # (arnold at skeeve.com) > 17. Re: Origins of shell prompt suffixes % $ > # (Cág) > 18. Re: Origins of shell prompt suffixes % $ > # (Brian Zick) > > From: Michael Kjörling > Subject: Re: [TUHS] Origins of shell prompt suffixes % $ > # > Date: 7 August 2018 at 08:54:54 CEST > To: tuhs at minnie.tuhs.org > > > On 6 Aug 2018 21:53 +0100, from brian at zick.io (Brian Zick): >> rc uses ; > > Not sure what came first, and not up to digging out the history books, > but these days, a plain `;` for a prompt has a distinct advantage in > that you can copy the whole line and paste it into another shell, and > the shell will do The Right Thing (tm) as long as (as is, I believe, > done by all of the major shells at least) it uses `;` for command > separation. > > -- > Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se > “The most dangerous thought that you can have as a creative person > is to think you know what you’re doing.” (Bret Victor) > > > > > From: Kurt H Maier > Subject: Re: [TUHS] Origins of shell prompt suffixes % $ > # > Date: 7 August 2018 at 09:31:36 CEST > To: Brian Zick > Cc: tuhs at minnie.tuhs.org > > > On Mon, Aug 06, 2018 at 09:53:33PM +0100, Brian Zick wrote: >> >> rc uses ; > > Does it? 10th edition Unix and Plan 9 rc both have ('% ' ' ') as the > default value of $prompt. At least that's how it's described in the > manual. None of the v8/9/10 tarballs in the archive contain rc code, > but some contain manual source, and those describe % prompts. > > I've seen other references to ; (presumably ('; ' ' ')) as the rc > prompt but I've never seen it in the wild. Does anyone here know what > the story is? > > khm > > > > > From: arnold at skeeve.com > Subject: Re: [TUHS] Origins of shell prompt suffixes % $ > # > Date: 7 August 2018 at 09:50:21 CEST > To: khm at sciops.net, brian at zick.io > Cc: tuhs at minnie.tuhs.org > > > Kurt H Maier wrote: > >> On Mon, Aug 06, 2018 at 09:53:33PM +0100, Brian Zick wrote: >>> >>> rc uses ; >> >> Does it? 10th edition Unix and Plan 9 rc both have ('% ' ' ') as the >> default value of $prompt. At least that's how it's described in the >> manual. None of the v8/9/10 tarballs in the archive contain rc code, >> but some contain manual source, and those describe % prompts. >> >> I've seen other references to ; (presumably ('; ' ' ')) as the rc >> prompt but I've never seen it in the wild. Does anyone here know what >> the story is? >> >> khm > > I believe that Tom Duff's rc does indeed use ('% ' ' '). But I think that > Byron Rakitsis's version changed the default to ('; ' ' ') exactly for > the reason that it's copyable/pastable. > > HTH, > > Arnold > > > > > From: Bakul Shah > Subject: Re: [TUHS] Origins of shell prompt suffixes % $ > # > Date: 7 August 2018 at 09:57:11 CEST > To: Kurt H Maier > Cc: Brian Zick , tuhs at minnie.tuhs.org > > > On Tue, 07 Aug 2018 00:31:36 -0700 Kurt H Maier wrote: >> On Mon, Aug 06, 2018 at 09:53:33PM +0100, Brian Zick wrote: >>> >>> rc uses ; >> >> Does it? 10th edition Unix and Plan 9 rc both have ('% ' ' ') as the >> default value of $prompt. At least that's how it's described in the >> manual. None of the v8/9/10 tarballs in the archive contain rc code, >> but some contain manual source, and those describe % prompts. >> >> I've seen other references to ; (presumably ('; ' ' ')) as the rc >> prompt but I've never seen it in the wild. Does anyone here know what >> the story is? > > The es shell (by Haar and Rakitzis) used ; - the reason (as > per the man page)is that a user can cut-n-paste a previous > line to rexecute it (for the same reason people use term% and > cpu% functions to execute their args). Es syntax was derived > from rc, which may be why the confusion. > > > > > From: Michael Kjörling > Subject: Re: [TUHS] Origins of shell prompt suffixes % $ > # > Date: 7 August 2018 at 10:02:56 CEST > To: tuhs at minnie.tuhs.org > > > On 7 Aug 2018 06:54 +0000, from michael at kjorling.se (Michael Kjörling): >> the shell will do The Right Thing (tm) > > I suspect I must stand corrected on this. Turns out that at least GNU > bash 4.4.12(1) seems to not like a `;` at the beginning of the command > line. > > $ /bin/bash --version | head -n1 > GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu) > $ /bin/bash > $ ; true > bash: syntax error near unexpected token `;' > $ echo $? > 2 > $ > > Hopefully other shells are more sane. > > -- > Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se > “The most dangerous thought that you can have as a creative person > is to think you know what you’re doing.” (Bret Victor) > > > > > From: Dave Horsfall > Subject: Re: [TUHS] Origins of shell prompt suffixes % $ > # > Date: 7 August 2018 at 10:23:37 CEST > To: The Eunuchs Hysterical Society > > > On Tue, 7 Aug 2018, Michael Kjörling wrote: > >> Hopefully other shells are more sane. > > The MacBook here runs GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin16) and is equally busted, as is plain "sh" on both the Mac and FreeBSD (I can't be bothered checking the Penguin); I use ZSH on FreeBSD and it does The Right Thing (tm), as does ZSH on the Mac. > > -- Dave > > > From: KatolaZ > Subject: Re: [TUHS] Origins of shell prompt suffixes % $ > # > Date: 7 August 2018 at 10:37:23 CEST > To: tuhs at minnie.tuhs.org > > > On Tue, Aug 07, 2018 at 06:23:37PM +1000, Dave Horsfall wrote: >> On Tue, 7 Aug 2018, Michael Kjörling wrote: >> >>> Hopefully other shells are more sane. >> >> The MacBook here runs GNU bash, version 3.2.57(1)-release >> (x86_64-apple-darwin16) and is equally busted, as is plain "sh" on both the >> Mac and FreeBSD (I can't be bothered checking the Penguin); I use ZSH on >> FreeBSD and it does The Right Thing (tm), as does ZSH on the Mac. >> >> -- Dave > > I have tried all the shells I have on my linux box. It turns out that > only ksh and zsh like a ";" at the beginning of the line. Otherwise, > bash, busybox, ash/dash, mksk, posh, and yash can't bear it. > > I really don't see the point of using ";", especially if you need to > make it clear if a command needs to be run by root. > > $ ;-P > sh: 1: Syntax error: ";" unexpected > > > -- > [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] > [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] > [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] > [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] > [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] > > > > From: "Steve Johnson" > Subject: Re: [TUHS] TUHS Digest, Vol 33, Issue 5 > Date: 6 August 2018 at 23:19:31 CEST > To: "Hellwig Geisse" , tuhs at minnie.tuhs.org > > > I take a somewhat more relaxed view of what a spec should be: > It should describe a program with enough completeness that a competent > programmer could write it from the spec alone. > Each section of the spec should be capable of being tested. > If all the tests for all the sections pass, then the program is ready > for general use. > > The formal systems I have seen would roll over and die when presented with > even a simple compiler. Additionally, being able to specify that a particular > function be carried out by a heapsort, for example, would require that the > formalism could describe the heapsort and prove it correct. These don't > grow on trees... > > Steve > > > > ----- Original Message ----- > From: "Hellwig Geisse" > To: > Cc: > Sent:Mon, 06 Aug 2018 18:30:30 +0200 > Subject:Re: [TUHS] TUHS Digest, Vol 33, Issue 5 > > > On Mo, 2018-08-06 at 08:52 -0700, Bakul Shah wrote: > > > > What counts as a "formal spec"? Is it like Justice Potter Stewart's > > "I know it when I see it" definition or something better? > > > > For me, a "formal spec" should serve two goals: > 1) You can reason about the thing that is specified. > 2) The spec can be "executed" (i.e., there is an > interpreting mechanism, which lets the spec behave > like the real thing). > > Hellwig > > > > From: Tony Finch > Subject: Re: [TUHS] Origins of shell prompt suffixes % $ > # > Date: 7 August 2018 at 12:45:37 CEST > To: Michael Kjörling > Cc: tuhs at minnie.tuhs.org > > > Michael Kjörling wrote: >> >> I suspect I must stand corrected on this. Turns out that at least GNU >> bash 4.4.12(1) seems to not like a `;` at the beginning of the command >> line. > > This is a consequence of the POSIX shell grammar, which doesn't allow > empty commands. > > http://pubs.opengroup.org/onlinepubs/9699919799.2013edition/utilities/V3_chap02.html#tag_18_10 > > The prompt I have used since about 1997 (and I can't remember where I got > it from - somewhere on Usenet, probably) in its most distilled form is > > :; > > although in practice I have a load of extra fluff for username, hostname, > CWD, etc. usw. > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > Fair Isle, Faeroes: South or southwest 4 or 5, occasionally 6 for a time. > Slight or moderate, occasionally rough for a time. Showers. Moderate or good. > > > > From: Pete Turnbull > Subject: Re: [TUHS] Origins of shell prompt suffixes % $ > # > Date: 7 August 2018 at 13:24:20 CEST > To: tuhs at minnie.tuhs.org > > > On 07/08/2018 09:02, Michael Kjörling wrote: >> On 7 Aug 2018 06:54 +0000, from michael at kjorling.se (Michael Kjörling): >>> the shell will do The Right Thing (tm) >> I suspect I must stand corrected on this. Turns out that at least GNU >> bash 4.4.12(1) seems to not like a `;` at the beginning of the command >> line. >> $ /bin/bash --version | head -n1 >> GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu) >> $ /bin/bash >> $ ; true >> bash: syntax error near unexpected token `;' >> $ echo $? >> 2 >> $ >> Hopefully other shells are more sane. > > ksh and sh on an IRIX system don't like it either: > > $ ; > ksh: syntax error: `;' unexpected > $ > > csh and tcsh don't mind. > > Of course it works in rc itself, which is the point, really, and I wonder how often anyone pasted from one shell into another. All the rc use I've seen did indeed use "; " as the prompt, but that was all at the University of York, starting in 1993. > > -- > Pete > Pete Turnbull > > > > > From: Doug McIlroy > Subject: Re: [TUHS] Origins of shell prompt suffixes % $ > # > Date: 7 August 2018 at 14:34:16 CEST > To: tuhs at tuhs.org > > >> The Bourne shell (V7) had setable PS1 (start of command) and PS2 (continuation prompts) > > When PS2 came on the scene, Bob Morris noticed that it most often appeared > because of a missing close quote. Therefore he set PS2="hit interrupt". > > > > > From: Brian Zick > Subject: Re: [TUHS] Origins of shell prompt suffixes % $ > # > Date: 7 August 2018 at 17:15:07 CEST > To: Kurt H Maier > Cc: tuhs at minnie.tuhs.org > > >>> rc uses ; >> >> Does it? 10th edition Unix and Plan 9 rc both have ('% ' ' ') as the >> default value of $prompt. At least that's how it's described in the >> manual. > > In NetBSD 7 the default is ';', but I don't see any reference to a default $prompt in the manual on that system. I wonder if this was a change unique to Berkeley. > > B > > > > > From: "John P. Linderman" > Subject: Re: [TUHS] Origins of shell prompt suffixes % $ > # > Date: 7 August 2018 at 17:52:57 CEST > To: Brian Zick > Cc: Kurt H Maier , tuhs at minnie.tuhs.org > > > On vacation, with just an iPad keyboard, so I apologize for not doing more digging. As I noted, when taking the blame for the Great Echo Schism, my early exposure to a hp2640 terminal that allowed “rentry” of a previous command was partly to blame. It also led me to use a PS1 ending in @, the default line-kill. When I reentered a command, the @ wiped out the prompt stuff, and only the command survived. > > On Tue, Aug 7, 2018 at 10:15 AM Brian Zick > wrote: > > > rc uses ; > > > > Does it? 10th edition Unix and Plan 9 rc both have ('% ' ' ') as the > > default value of $prompt. At least that's how it's described in the > > manual. > > In NetBSD 7 the default is ';', but I don't see any reference to a default $prompt in the manual on that system. I wonder if this was a change unique to Berkeley. > > B > > > > From: Lyndon Nerenberg > Subject: Re: [TUHS] Origins of shell prompt suffixes % $ > # > Date: 7 August 2018 at 19:35:49 CEST > To: Tony Finch > Cc: Michael Kjörling , tuhs at minnie.tuhs.org > > >> The prompt I have used since about 1997 (and I can't remember where I got >> it from - somewhere on Usenet, probably) in its most distilled form is >> >> :; > > I forget where I stole this from. It lives in $home/lib/profile on my Plan9 machines: > > # /n/sources/contrib/lyndon/prompt.rc > fn : {} > fn setprompt { > prompt = (': '^`{cat /dev/user}^@^`{cat /dev/sysname}^':'^`{pwd}^'; ' ' ') > } > fn cd { builtin cd $* && setprompt } > setprompt > > > > > > From: Cág > Subject: Re: [TUHS] Origins of shell prompt suffixes % $ > # > Date: 7 August 2018 at 20:09:51 CEST > To: tuhs at minnie.tuhs.org > > > Brian Zick wrote: > >> In NetBSD 7 the default is ';', but I don't see any reference to a >> default $prompt in the manual on that system. > > It's not. '$' is default for sh and ksh, and '%' for csh. I think > it maybe has never been ';'. > > -- > caóc > > > > > > From: arnold at skeeve.com > Subject: Re: [TUHS] Origins of shell prompt suffixes % $ > # > Date: 7 August 2018 at 20:51:52 CEST > To: tuhs at minnie.tuhs.org, ca6c at bitmessage.ch > > > C??g wrote: > >> Brian Zick wrote: >> >>> In NetBSD 7 the default is ';', but I don't see any reference to a >>> default $prompt in the manual on that system. >> >> It's not. '$' is default for sh and ksh, and '%' for csh. I think >> it maybe has never been ';'. >> >> -- >> ca??c >> > > Brian was referring to rc(1) in NetBSD. I suspect it's Byron's rc > and I think the default there is ';'. > > Arnold > > > > > From: Cág > Subject: Re: [TUHS] Origins of shell prompt suffixes % $ > # > Date: 7 August 2018 at 21:00:22 CEST > To: tuhs at minnie.tuhs.org > > > arnold wrote: > >> Brian was referring to rc(1) in NetBSD. I suspect it's Byron's rc >> and I think the default there is ';'. > > rc is not shipped with NetBSD. There's Byron's rc in pkgsrc, so it could > be that. > > -- > caóc > > > > > > From: Brian Zick > Subject: Re: [TUHS] Origins of shell prompt suffixes % $ > # > Date: 7 August 2018 at 21:06:03 CEST > To: tuhs at minnie.tuhs.org > > > On Tue, Aug 7, 2018, at 8:00 PM, Cág wrote: >> arnold wrote: >> >>> Brian was referring to rc(1) in NetBSD. I suspect it's Byron's rc >>> and I think the default there is ';'. >> >> rc is not shipped with NetBSD. There's Byron's rc in pkgsrc, so it could >> be that. > > Yes, I was referring to the rc in pkgsrc. > > B > > > > > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs -------------- next part -------------- An HTML attachment was scrubbed... URL: From ik at sjmulder.nl Wed Aug 8 22:32:29 2018 From: ik at sjmulder.nl (Sijmen J. Mulder) Date: Wed, 8 Aug 2018 14:32:29 +0200 Subject: [TUHS] TUHS Digest, Vol 33, Issue 7 In-Reply-To: References: Message-ID: <20180808123229.86FD5E465F@mailuser.nyi.internal> > Decades ago I made my prompt simply end with a newline, which perfectly > and cleanly solves the problem of making it easy to copy and paste a > whole line I never considered setting a copy/paste-friendly prompt but I strongly dislike prompts taking up a line. Admittedly it's nice to have some room for extra information but then you'll want a clear line above it too for visual structure and that's all just too much clutter for me. -------------- next part -------------- An HTML attachment was scrubbed... URL: From don at donhopkins.com Wed Aug 8 22:59:06 2018 From: don at donhopkins.com (Don Hopkins) Date: Wed, 8 Aug 2018 14:59:06 +0200 Subject: [TUHS] TUHS Digest, Vol 33, Issue 7 In-Reply-To: <20180808123229.86FD5E465F@mailuser.nyi.internal> References: <20180808123229.86FD5E465F@mailuser.nyi.internal> Message-ID: <6EBCF9E5-4600-42D6-9F83-3E2966140540@donhopkins.com> I strongly dislike something as trivial as a prompt taking up my TIME and ATTENTION. I have room for many more lines in my terminal emulator and emacs shell window than I have time and attention or patience for carefully pointing and clicking and editing out prompts (or even talking about half-assed kludges when there’s a simple obvious solution to the problem), and much better things to do with my time and energy. To me, there is virtually no cost to having an extra line in my terminal or shell window, while the repeated cost of all the time and effort I have to waste working around the clutter of the prompt, integrated over the hundreds of times per day I use the command line, totally overwhelms any aesthetic considerations of disliking prompts taking up a line (or insisting on a clear line before it -- I don’t understand why you would suggest such a straw man, which is not what I was advocating). I’m not trying to paint the Mona Lisa in ASCII art, I’m simply trying to save time and effort. What’s the downside to the prompt taking up a full line (and as a result, the command taking up a whole line without being polluted with a prompt), other than strongly disliking things you’re not used to? Is your terminal emulator configured to only remember 24 lines? And why are you so averse to clutter, yet have no problem with the prompt cluttering up your input, which causes real non-aesthetic problems? I used to use a shitty HP 2640 terminal in high school that only had a half a page of screen memory (but didn’t store the spaces at the end of the lines, so you could fit 12 80-character lines on the screen, or 24 40-character lines), so if you printed out long lines, it would start scrolling before there was a full screen of text. At least the 300 baud modem gave you time to ponder over those few lines before they scrolled off the screen. In that scenario, lines of text were precious, although the HP terminals charge by characters, not lines. But I don’t think anybody in their right mind uses terminals like that any more. -Don > On 8 Aug 2018, at 14:32, Sijmen J. Mulder wrote: > > > Decades ago I made my prompt simply end with a newline, which perfectly > > and cleanly solves the problem of making it easy to copy and paste a > > whole line > > I never considered setting a copy/paste-friendly prompt but I strongly > dislike prompts taking up a line. Admittedly it's nice to have some room > for extra information but then you'll want a clear line above it too for > visual structure and that's all just too much clutter for me. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ik at sjmulder.nl Wed Aug 8 23:51:07 2018 From: ik at sjmulder.nl (Sijmen J. Mulder) Date: Wed, 8 Aug 2018 15:51:07 +0200 Subject: [TUHS] TUHS Digest, Vol 33, Issue 7 In-Reply-To: <6EBCF9E5-4600-42D6-9F83-3E2966140540@donhopkins.com> References: <20180808123229.86FD5E465F@mailuser.nyi.internal> <6EBCF9E5-4600-42D6-9F83-3E2966140540@donhopkins.com> Message-ID: <20180808135106.D7441E4636@mailuser.nyi.internal> > [...] totally overwhelms any aesthetic considerations of disliking > prompts taking up a line (or insisting on a clear line before it -- I > don’t understand why you would suggest such a straw man, which is not > what I was advocating). I totally understand what you're saying, but I hardly ever copy and paste between terminals so it's just not an issue to me and then my preference for a compact prompt and little whitespace prevails. I'll give you that the clear line thing is personal and won't necessarily apply to others. The "you'll want to" was misplaced. > At least the 300 baud modem gave you time to ponder over those few lines > before they scrolled off the screen. In that scenario, lines of text > were precious, although the HP terminals charge by characters, not > lines. But I don’t think anybody in their right mind uses terminals like > that any more. They charged per character? That's fascinating. I'm too young to have worked with teletypes or terminals but to experience what working over a slower connection would be like I wrote a small pty program that throttles stdin and stdout to a given baud rate: https://github.com/sjmulder/trickle It's probably nothing like the real thing but I found it interesting to experience adapting to a slow terminal and to see things like pagers update the screen step by step. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cym224 at gmail.com Thu Aug 9 00:28:23 2018 From: cym224 at gmail.com (Nemo) Date: Wed, 8 Aug 2018 10:28:23 -0400 Subject: [TUHS] Misuse of TUHS Digest [Was: Re: TUHS Digest, Vol 33, Issue 7] Message-ID: Maybe I am being a tad sensitive this morn but... >> On 8 Aug 2018, at 04:00, tuhs-request at minnie.tuhs.org wrote: [...] >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of TUHS digest..." let us please honour this request. Thank you. N. [Lots and lots and lots of stuff removed] From cym224 at gmail.com Thu Aug 9 00:38:21 2018 From: cym224 at gmail.com (Nemo) Date: Wed, 8 Aug 2018 10:38:21 -0400 Subject: [TUHS] Origins of shell prompt suffixes % $ > # In-Reply-To: References: <1533588813.1868321.1465431536.01CE36BC@webmail.messagingengine.com> <20180807065453.jjnsx3cunjug5q3e@h-174-65.A328.priv.bahnhof.se> <20180807080256.lgqaevcah2a7sn2t@h-174-65.A328.priv.bahnhof.se> Message-ID: On 07/08/2018, Tony Finch wrote: > Michael Kjörling wrote: >> >> I suspect I must stand corrected on this. Turns out that at least GNU >> bash 4.4.12(1) seems to not like a `;` at the beginning of the command >> line. > > This is a consequence of the POSIX shell grammar, which doesn't allow > empty commands. > > http://pubs.opengroup.org/onlinepubs/9699919799.2013edition/utilities/V3_chap02.html#tag_18_10 Good point (and [t]csh on Solaris does not care). > prompt I have used since about 1997 (and I can't remember where I got > it from - somewhere on Usenet, probably) in its most distilled form is > > :; I will, no doubt, be flayed on this list but I tend to use "=> ". N. > > although in practice I have a load of extra fluff for username, hostname, > CWD, etc. usw. > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > Fair Isle, Faeroes: South or southwest 4 or 5, occasionally 6 for a time. > Slight or moderate, occasionally rough for a time. Showers. Moderate or > good. > From clemc at ccc.com Thu Aug 9 00:45:31 2018 From: clemc at ccc.com (Clem Cole) Date: Wed, 8 Aug 2018 10:45:31 -0400 Subject: [TUHS] TUHS Digest, Vol 33, Issue 7 In-Reply-To: <20180808135106.D7441E4636@mailuser.nyi.internal> References: <20180808123229.86FD5E465F@mailuser.nyi.internal> <6EBCF9E5-4600-42D6-9F83-3E2966140540@donhopkins.com> <20180808135106.D7441E4636@mailuser.nyi.internal> Message-ID: On Wed, Aug 8, 2018 at 9:51 AM, Sijmen J. Mulder wrote: > I'm too young to have worked with teletypes or terminals but to > > experience what working over a slower connection would be like I wrote > > a small pty program that throttles stdin and stdout to a given baud > > rate > Sadly you are missing three important features in your emulation. First the noise and the second associated motion of the carriage as the printer did its thing. (The movement of the 'ball' (cylinder on a TTY) was magical and made it quite set of sounds you will never forget - often duplicated in the movies). But the hardest thing to simulate is the distinct smell of light machine oil that all terminal rooms had. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Aug 9 00:51:50 2018 From: clemc at ccc.com (Clem Cole) Date: Wed, 8 Aug 2018 10:51:50 -0400 Subject: [TUHS] Origins of shell prompt suffixes % $ > # In-Reply-To: References: <1533588813.1868321.1465431536.01CE36BC@webmail.messagingengine.com> <20180807065453.jjnsx3cunjug5q3e@h-174-65.A328.priv.bahnhof.se> <20180807080256.lgqaevcah2a7sn2t@h-174-65.A328.priv.bahnhof.se> Message-ID: On Wed, Aug 8, 2018 at 10:38 AM, Nemo wrote: > > I will, no doubt, be flayed on this list but I tend to use "=> ". Remember: "Hacking is what is done in the privacy of your own office; between you and your terminal." ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From stewart at serissa.com Thu Aug 9 00:56:23 2018 From: stewart at serissa.com (Lawrence Stewart) Date: Wed, 8 Aug 2018 10:56:23 -0400 Subject: [TUHS] TUHS Digest, Vol 33, Issue 7 In-Reply-To: References: <20180808123229.86FD5E465F@mailuser.nyi.internal> <6EBCF9E5-4600-42D6-9F83-3E2966140540@donhopkins.com> <20180808135106.D7441E4636@mailuser.nyi.internal> Message-ID: <572221F5-329B-4E2A-86B4-F058A3230463@serissa.com> Oh my yes. The Model 33’s and the 2741s… The timer setting off the ball rotate to remind you the computer is tapping its foot... But all is not lost for those from the ‘80s. There is http://www.secretgeometry.com/apps/cathode/ a terminal emulator prepared to mimic screen curvature, flicker, visible scan lines, etc. -Larry > On 2018, Aug 8, at 10:45 AM, Clem Cole wrote: > > > > On Wed, Aug 8, 2018 at 9:51 AM, Sijmen J. Mulder > wrote: > I'm too young to have worked with teletypes or terminals but to > > > experience what working over a slower connection would be like I wrote > > a small pty program that throttles stdin and stdout to a given baud > > rate > > Sadly you are missing three important features in your emulation. First the noise and the second associated motion of the carriage as the printer did its thing. (The movement of the 'ball' (cylinder on a TTY) was magical and made it quite set of sounds you will never forget - often duplicated in the movies). But the hardest thing to simulate is the distinct smell of light machine oil that all terminal rooms had. > Clem > ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From toby at telegraphics.com.au Thu Aug 9 01:09:15 2018 From: toby at telegraphics.com.au (Toby Thain) Date: Wed, 8 Aug 2018 11:09:15 -0400 Subject: [TUHS] the distinct smell of light machine oil, was Re: TUHS Digest, Vol 33, Issue 7 In-Reply-To: References: <20180808123229.86FD5E465F@mailuser.nyi.internal> <6EBCF9E5-4600-42D6-9F83-3E2966140540@donhopkins.com> <20180808135106.D7441E4636@mailuser.nyi.internal> Message-ID: On 2018-08-08 10:45 AM, Clem Cole wrote: > > > On Wed, Aug 8, 2018 at 9:51 AM, Sijmen J. Mulder > wrote: > > I'm too young to have worked with teletypes or terminals but to > > __ > > experience what working over a slower connection would be like I > wrote____ > > a small pty program that throttles stdin and stdout to a given baud____ > > rate > > Sadly you are missing three important features in your emulation.  First > the noise and the second associated motion of the carriage as the > printer did its thing.  (The movement of the 'ball' (cylinder on a TTY) > was magical and made it quite set of sounds you will never forget - > often duplicated in the movies).   But the hardest thing to simulate is > the distinct smell of light machine oil that all terminal rooms had. Isn't this easy? Just use a spritzer of it around your PC. --T > Clem  > ᐧ From jnc at mercury.lcs.mit.edu Thu Aug 9 01:20:18 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 8 Aug 2018 11:20:18 -0400 (EDT) Subject: [TUHS] Origins of shell prompt suffixes % $ > # Message-ID: <20180808152018.EDBBA18C08E@mercury.lcs.mit.edu> > From: Nemo > I will, no doubt, be flayed on this list but I tend to use "=>". Hey, if it works for you, go for it. After the Nth time I got confused as to exactly which machine I was typing to, I hacked the shell on my V6 Unix to read its prompt from ".profile". (Very clean, only one added line of code in the existing code.) Noel From ckeck at texoma.net Thu Aug 9 03:38:00 2018 From: ckeck at texoma.net (Cornelius Keck) Date: Wed, 8 Aug 2018 12:38:00 -0500 Subject: [TUHS] the distinct smell of light machine oil, was Re: TUHS Digest, Vol 33, Issue 7 In-Reply-To: References: <20180808123229.86FD5E465F@mailuser.nyi.internal> <6EBCF9E5-4600-42D6-9F83-3E2966140540@donhopkins.com> <20180808135106.D7441E4636@mailuser.nyi.internal> Message-ID: <5B6B2A78.7070303@texoma.net> Then promptly run into trouble with your SO and/or XO because they don't like the fragrance? Toby Thain wrote: > On 2018-08-08 10:45 AM, Clem Cole wrote: >> >> >> On Wed, Aug 8, 2018 at 9:51 AM, Sijmen J. Mulder > > wrote: >> >> I'm too young to have worked with teletypes or terminals but to >> >> __ >> >> experience what working over a slower connection would be like I >> wrote____ >> >> a small pty program that throttles stdin and stdout to a given baud____ >> >> rate >> >> Sadly you are missing three important features in your emulation. First >> the noise and the second associated motion of the carriage as the >> printer did its thing. (The movement of the 'ball' (cylinder on a TTY) >> was magical and made it quite set of sounds you will never forget - >> often duplicated in the movies). But the hardest thing to simulate is >> the distinct smell of light machine oil that all terminal rooms had. > > Isn't this easy? Just use a spritzer of it around your PC. > > --T > >> Clem >> ᐧ > From velocityboy at gmail.com Thu Aug 9 05:14:19 2018 From: velocityboy at gmail.com (Jim Geist) Date: Wed, 8 Aug 2018 12:14:19 -0700 Subject: [TUHS] the distinct smell of light machine oil, was Re: TUHS Digest, Vol 33, Issue 7 In-Reply-To: <5B6B2A78.7070303@texoma.net> References: <20180808123229.86FD5E465F@mailuser.nyi.internal> <6EBCF9E5-4600-42D6-9F83-3E2966140540@donhopkins.com> <20180808135106.D7441E4636@mailuser.nyi.internal> <5B6B2A78.7070303@texoma.net> Message-ID: I have a functional LA120 in my house and can attest to the machine smell whenever I run it. On Wed, Aug 8, 2018 at 11:50 AM Cornelius Keck wrote: > Then promptly run into trouble with your SO and/or XO because they don't > like the fragrance? > > > Toby Thain wrote: > > On 2018-08-08 10:45 AM, Clem Cole wrote: > >> > >> > >> On Wed, Aug 8, 2018 at 9:51 AM, Sijmen J. Mulder >> > wrote: > >> > >> I'm too young to have worked with teletypes or terminals but to > >> > >> __ > >> > >> experience what working over a slower connection would be like I > >> wrote____ > >> > >> a small pty program that throttles stdin and stdout to a given > baud____ > >> > >> rate > >> > >> Sadly you are missing three important features in your emulation. First > >> the noise and the second associated motion of the carriage as the > >> printer did its thing. (The movement of the 'ball' (cylinder on a TTY) > >> was magical and made it quite set of sounds you will never forget - > >> often duplicated in the movies). But the hardest thing to simulate is > >> the distinct smell of light machine oil that all terminal rooms had. > > > > Isn't this easy? Just use a spritzer of it around your PC. > > > > --T > > > >> Clem > >> ᐧ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfawcus+lists-tuhs at employees.org Thu Aug 9 05:55:26 2018 From: dfawcus+lists-tuhs at employees.org (Derek Fawcus) Date: Wed, 8 Aug 2018 20:55:26 +0100 Subject: [TUHS] Origins of shell prompt suffixes % $ > # In-Reply-To: <20180807080256.lgqaevcah2a7sn2t@h-174-65.A328.priv.bahnhof.se> References: <1533588813.1868321.1465431536.01CE36BC@webmail.messagingengine.com> <20180807065453.jjnsx3cunjug5q3e@h-174-65.A328.priv.bahnhof.se> <20180807080256.lgqaevcah2a7sn2t@h-174-65.A328.priv.bahnhof.se> Message-ID: <20180808195526.GA26375@accordion.employees.org> On Tue, Aug 07, 2018 at 08:02:56AM +0000, Michael Kjörling wrote: > I suspect I must stand corrected on this. Turns out that at least GNU > bash 4.4.12(1) seems to not like a `;` at the beginning of the command > line. I can't recall where I got this from, but I tend to use the following on bourne style shells; bash (and others) seem happy with it for copy/paste: h=copper$; tty /dev/pts/0 h=copper$; h=copper$; tty /dev/pts/0 h=copper#; tty /dev/pts/0 h=copper#; h=copper#; tty /dev/pts/0 'copper' being the hostname, $/# as per usual. DF From imp at bsdimp.com Wed Aug 8 18:50:51 2018 From: imp at bsdimp.com (Warner Losh) Date: Wed, 8 Aug 2018 09:50:51 +0100 Subject: [TUHS] Sort of off-topic: usefulness of TUHS list and archive? In-Reply-To: <20180808083706.GA20345@minnie.tuhs.org> References: <20180808083706.GA20345@minnie.tuhs.org> Message-ID: I used your site to construct historical unix sizes in s talk I have at BSDcan. I've also used it to check historical unix behaviour when fixing bugs in FreeBSD for Netflix... Warner On Wed, Aug 8, 2018, 9:38 AM Warren Toomey wrote: > All, sorry that this is tangential to TUHS. I work at TAFE Queensland, > which > is a bit like a polytechnic or a U.S college. As a teacher, I have to > demonstrate industry skills. I've listed my administration of the TUHS > server > over 25+ years. However, TAFE wants this to be verified by third parties: > > "Where possible the teacher could show that industry endorses his > website and any if there are any testimonials/comments/reviews > available on the site, these could also be provided." > > So, if you could pop a sentence or two in reply to this e-mail about > the usefulness of the TUHS archive and the mailing list, that would be > really helpful! > > Cheers & thanks in advance, Warren > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wobblygong at gmail.com Wed Aug 8 20:38:54 2018 From: wobblygong at gmail.com (Wesley Parish) Date: Wed, 8 Aug 2018 22:38:54 +1200 Subject: [TUHS] Sort of off-topic: usefulness of TUHS list and archive? In-Reply-To: <20180808083706.GA20345@minnie.tuhs.org> References: <20180808083706.GA20345@minnie.tuhs.org> Message-ID: You might point them in this direction: Dennis Ritchie's Interview for Samizdat Tuesday, June 01 2004 @ 09:25 PM EDT http://www.groklaw.net/articlebasic.php?story=20040601212559558 PJ quotes an email from Dennis Ritchie that mentions tuhs.org in relation to the SCO series of allegations and accusations about the relationship of Linux to Unix. As an archivist of early Unix developments, you played a part in keeping the record open and visible, which played no small part in preventing a sizeable part of the IT industry from being held to ransom. No small achievement. Wesley Parish On 8/8/18, Warren Toomey wrote: > All, sorry that this is tangential to TUHS. I work at TAFE Queensland, > which > is a bit like a polytechnic or a U.S college. As a teacher, I have to > demonstrate industry skills. I've listed my administration of the TUHS > server > over 25+ years. However, TAFE wants this to be verified by third parties: > > "Where possible the teacher could show that industry endorses his > website and any if there are any testimonials/comments/reviews > available on the site, these could also be provided." > > So, if you could pop a sentence or two in reply to this e-mail about > the usefulness of the TUHS archive and the mailing list, that would be > really helpful! > > Cheers & thanks in advance, Warren > From gregg.drwho8 at gmail.com Wed Aug 8 23:24:05 2018 From: gregg.drwho8 at gmail.com (Gregg Levine) Date: Wed, 8 Aug 2018 09:24:05 -0400 Subject: [TUHS] Sort of off-topic: usefulness of TUHS list and archive? In-Reply-To: <20180808083706.GA20345@minnie.tuhs.org> References: <20180808083706.GA20345@minnie.tuhs.org> Message-ID: Hello! For myself I'd say the list (and the archives) are very useful. The list has answered many questions about a period in time I thought I knew reasonably well. It backstopped a reason why I wanted to get into the retro computing hobby as regards the early ideas on UNIX and its relatives, BSD and all of the rest. Oh and I also enjoy reading the discussions that are relevant to the list, but not of course to my needs. Sometimes I feel I missed something I'll track back through my collection, and follow up on it via the list archives. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Wed, Aug 8, 2018 at 4:37 AM, Warren Toomey wrote: > All, sorry that this is tangential to TUHS. I work at TAFE Queensland, which > is a bit like a polytechnic or a U.S college. As a teacher, I have to > demonstrate industry skills. I've listed my administration of the TUHS server > over 25+ years. However, TAFE wants this to be verified by third parties: > > "Where possible the teacher could show that industry endorses his > website and any if there are any testimonials/comments/reviews > available on the site, these could also be provided." > > So, if you could pop a sentence or two in reply to this e-mail about > the usefulness of the TUHS archive and the mailing list, that would be > really helpful! > > Cheers & thanks in advance, Warren From gilles at gravier.org Thu Aug 9 02:01:23 2018 From: gilles at gravier.org (Gilles Gravier) Date: Wed, 8 Aug 2018 18:01:23 +0200 Subject: [TUHS] Origins of shell prompt suffixes % $ > # In-Reply-To: <20180808152018.EDBBA18C08E@mercury.lcs.mit.edu> References: <20180808152018.EDBBA18C08E@mercury.lcs.mit.edu> Message-ID: Caveat emptor: I haven't read all the messages on this thread. :) But... I remember the VMS prompt being "$"... maybe some ancestry since VMS dates back to 1970? Gilles 2018-08-08 17:20 GMT+02:00 Noel Chiappa : > > From: Nemo > > > I will, no doubt, be flayed on this list but I tend to use "=>". > > Hey, if it works for you, go for it. > > After the Nth time I got confused as to exactly which machine I was > typing to, I hacked the shell on my V6 Unix to read its prompt from > ".profile". (Very clean, only one added line of code in the existing > code.) > > Noel > -- *Gilles Gravier* - Gilles at Gravier.org GSM : +33618347147 and +41794728437 Skype : ggravier | PGP Key : 0x8DE6D026 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Thu Aug 9 06:14:54 2018 From: wkt at tuhs.org (Warren Toomey) Date: Thu, 9 Aug 2018 06:14:54 +1000 Subject: [TUHS] Sort of off-topic: usefulness of TUHS list and archive? In-Reply-To: <20180808083706.GA20345@minnie.tuhs.org> References: <20180808083706.GA20345@minnie.tuhs.org> Message-ID: <20180808201454.GA23457@minnie.tuhs.org> On Wed, Aug 08, 2018 at 06:37:06PM +1000, Warren Toomey wrote: > So, if you could pop a sentence or two in reply to this e-mail about > the usefulness of the TUHS archive and the mailing list, that would be > really helpful! > > Cheers & thanks in advance, Warren Many thanks to the 20 or so people who wrote a paragraph or two outlining how useful they have found the TUHS list and archive, and for throwing a bit of approbation my way as well :-) That should be enough, I've copied them into a document I can pass onto my managers. Thanks again, Warren From ron at ronnatalie.com Thu Aug 9 06:29:26 2018 From: ron at ronnatalie.com (ron at ronnatalie.com) Date: Wed, 8 Aug 2018 16:29:26 -0400 Subject: [TUHS] Origins of shell prompt suffixes % $ > # In-Reply-To: References: <20180808152018.EDBBA18C08E@mercury.lcs.mit.edu> Message-ID: <098701d42f56$80c6c470$82544d50$@ronnatalie.com> * But... I remember the VMS prompt being "$"... maybe some ancestry since VMS dates back to 1970? VMS development started in 1975. It didn’t see the light of day until the VAX hardware was released in 1977. RSX used > (sometimes MCR>). TOPS-10 used a period (.) at the monitor level and asterisk at the user level. RT-11 also used the period. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Aug 9 06:30:19 2018 From: clemc at ccc.com (Clem Cole) Date: Wed, 8 Aug 2018 16:30:19 -0400 Subject: [TUHS] Origins of shell prompt suffixes % $ > # In-Reply-To: References: <20180808152018.EDBBA18C08E@mercury.lcs.mit.edu> Message-ID: On Wed, Aug 8, 2018 at 12:01 PM, Gilles Gravier wrote: > Caveat emptor: I haven't read all the messages on this thread. :) > > But... I remember the VMS prompt being "$"... maybe some ancestry since > VMS dates back to 1970 > Be careful .. VMS 1.0 was released in the late 1970s, we had Vax serial #1 at CMU - I want to say 1976 or 77. Dave's Command Language (DCL - renamed DEC Command Language by DEC marketing) was originally part of an earlier RSX and yes used $ as the prompt. But numerous systems used $ and many of the other punctuation chars as a prompt. We'll have to ask srb, but I'm fair confident in stating VMS had no bearing on his choice of a command prompt (I'm fairly sure VMS was not release by the time he came to the Labs). I would have expected if it was taking it from another system (which is possible) it would have been on the British ones in use at Cambridge before he came to BTL. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Thu Aug 9 06:44:53 2018 From: imp at bsdimp.com (Warner Losh) Date: Wed, 8 Aug 2018 14:44:53 -0600 Subject: [TUHS] the distinct smell of light machine oil, was Re: TUHS Digest, Vol 33, Issue 7 In-Reply-To: References: <20180808123229.86FD5E465F@mailuser.nyi.internal> <6EBCF9E5-4600-42D6-9F83-3E2966140540@donhopkins.com> <20180808135106.D7441E4636@mailuser.nyi.internal> <5B6B2A78.7070303@texoma.net> Message-ID: Especially if you use the WD40 trick for the ink ribbon. :) Warner On Wed, Aug 8, 2018, 1:14 PM Jim Geist wrote: > I have a functional LA120 in my house and can attest to the machine smell > whenever I run it. > > On Wed, Aug 8, 2018 at 11:50 AM Cornelius Keck wrote: > >> Then promptly run into trouble with your SO and/or XO because they don't >> like the fragrance? >> >> >> Toby Thain wrote: >> > On 2018-08-08 10:45 AM, Clem Cole wrote: >> >> >> >> >> >> On Wed, Aug 8, 2018 at 9:51 AM, Sijmen J. Mulder > >> > wrote: >> >> >> >> I'm too young to have worked with teletypes or terminals but to >> >> >> >> __ >> >> >> >> experience what working over a slower connection would be like I >> >> wrote____ >> >> >> >> a small pty program that throttles stdin and stdout to a given >> baud____ >> >> >> >> rate >> >> >> >> Sadly you are missing three important features in your emulation. >> First >> >> the noise and the second associated motion of the carriage as the >> >> printer did its thing. (The movement of the 'ball' (cylinder on a TTY) >> >> was magical and made it quite set of sounds you will never forget - >> >> often duplicated in the movies). But the hardest thing to simulate is >> >> the distinct smell of light machine oil that all terminal rooms had. >> > >> > Isn't this easy? Just use a spritzer of it around your PC. >> > >> > --T >> > >> >> Clem >> >> ᐧ >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Thu Aug 9 06:51:15 2018 From: imp at bsdimp.com (Warner Losh) Date: Wed, 8 Aug 2018 14:51:15 -0600 Subject: [TUHS] Origins of shell prompt suffixes % $ > # In-Reply-To: References: <20180808152018.EDBBA18C08E@mercury.lcs.mit.edu> Message-ID: On Wed, Aug 8, 2018, 2:31 PM Clem Cole wrote: > > > On Wed, Aug 8, 2018 at 12:01 PM, Gilles Gravier > wrote: > >> Caveat emptor: I haven't read all the messages on this thread. :) >> >> But... I remember the VMS prompt being "$"... maybe some ancestry since >> VMS dates back to 1970 >> > Be careful .. VMS 1.0 was released in the late 1970s, we had Vax serial #1 > at CMU - I want to say 1976 or 77. Dave's Command Language (DCL - renamed > DEC Command Language by DEC marketing) was originally part of an earlier > RSX and yes used $ as the prompt. > > But numerous systems used $ and many of the other punctuation chars as a > prompt. > > We'll have to ask srb, but I'm fair confident in stating VMS had no > bearing on his choice of a command prompt (I'm fairly sure VMS was not > release by the time he came to the Labs). I would have expected if it was > taking it from another system (which is possible) it would have been on the > British ones in use at Cambridge before he came to BTL. > TOPS-20 used @. RSTS/E used Ready. Warner > ᐧ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Thu Aug 9 11:09:02 2018 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 9 Aug 2018 11:09:02 +1000 (EST) Subject: [TUHS] Happy birthday, Marvin Minsky! Message-ID: We gained Marvin Minsky on this day in 1927; he was an AI researcher, computer scientist, invented neural networks etc, and is now thought to be cryogenically preserved. -- Dave From wlc at jctaylor.com Thu Aug 9 12:50:54 2018 From: wlc at jctaylor.com (William Corcoran) Date: Thu, 9 Aug 2018 02:50:54 +0000 Subject: [TUHS] Origins of shell prompt suffixes % $ > # In-Reply-To: References: <20180808152018.EDBBA18C08E@mercury.lcs.mit.edu>, Message-ID: I too have not seen all of the messages on this thread. I always thought the $ was used for the shell prompt as a persistent reminder that time on the system costs money: As process accounting will assist in your monthly billing. Bill Corcoran On Aug 8, 2018, at 4:20 PM, Gilles Gravier > wrote: Caveat emptor: I haven't read all the messages on this thread. :) But... I remember the VMS prompt being "$"... maybe some ancestry since VMS dates back to 1970? Gilles 2018-08-08 17:20 GMT+02:00 Noel Chiappa >: > From: Nemo > I will, no doubt, be flayed on this list but I tend to use "=>". Hey, if it works for you, go for it. After the Nth time I got confused as to exactly which machine I was typing to, I hacked the shell on my V6 Unix to read its prompt from ".profile". (Very clean, only one added line of code in the existing code.) Noel -- Gilles Gravier - Gilles at Gravier.org GSM : +33618347147 and +41794728437 Skype : ggravier | PGP Key : 0x8DE6D026 -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Thu Aug 9 15:14:28 2018 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 08 Aug 2018 23:14:28 -0600 Subject: [TUHS] the distinct smell of light machine oil, was Re: TUHS Digest, Vol 33, Issue 7 In-Reply-To: References: <20180808123229.86FD5E465F@mailuser.nyi.internal> <6EBCF9E5-4600-42D6-9F83-3E2966140540@donhopkins.com> <20180808135106.D7441E4636@mailuser.nyi.internal> <5B6B2A78.7070303@texoma.net> Message-ID: <201808090514.w795ESAh018689@freefriends.org> Which was ...? Warner Losh wrote: > Especially if you use the WD40 trick for the ink ribbon. :) > > Warner > > On Wed, Aug 8, 2018, 1:14 PM Jim Geist wrote: > > > I have a functional LA120 in my house and can attest to the machine smell > > whenever I run it. From velocityboy at gmail.com Thu Aug 9 15:55:56 2018 From: velocityboy at gmail.com (Jim Geist) Date: Wed, 8 Aug 2018 22:55:56 -0700 Subject: [TUHS] the distinct smell of light machine oil, was Re: TUHS Digest, Vol 33, Issue 7 In-Reply-To: <201808090514.w795ESAh018689@freefriends.org> References: <20180808123229.86FD5E465F@mailuser.nyi.internal> <6EBCF9E5-4600-42D6-9F83-3E2966140540@donhopkins.com> <20180808135106.D7441E4636@mailuser.nyi.internal> <5B6B2A78.7070303@texoma.net> <201808090514.w795ESAh018689@freefriends.org> Message-ID: You can supposedly revive dried out ribbons by soaking them in WD40. I’ve heard of it but never tried it. On Wed, Aug 8, 2018 at 10:14 PM wrote: > Which was ...? > > Warner Losh wrote: > > > Especially if you use the WD40 trick for the ink ribbon. :) > > > > Warner > > > > On Wed, Aug 8, 2018, 1:14 PM Jim Geist wrote: > > > > > I have a functional LA120 in my house and can attest to the machine > smell > > > whenever I run it. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggm at algebras.org Thu Aug 9 16:02:30 2018 From: ggm at algebras.org (George Michaelson) Date: Thu, 9 Aug 2018 16:02:30 +1000 Subject: [TUHS] the distinct smell of light machine oil, was Re: TUHS Digest, Vol 33, Issue 7 In-Reply-To: References: <20180808123229.86FD5E465F@mailuser.nyi.internal> <6EBCF9E5-4600-42D6-9F83-3E2966140540@donhopkins.com> <20180808135106.D7441E4636@mailuser.nyi.internal> <5B6B2A78.7070303@texoma.net> <201808090514.w795ESAh018689@freefriends.org> Message-ID: I used to quick start my mower by a spray into the carb. This tells me that WD40 apart from being an intoxicatingly manly perfume, is flammable. I suggest that the static ball of fluff which is any print device with paper crud, chad, and other ephemeral bits of detritus (including probably half a tonne of skin flakes) is not the best place to spray WD40. Do it outside. real programmers don't let other programmers smoke around printing devices... -G On Thu, Aug 9, 2018 at 3:55 PM, Jim Geist wrote: > You can supposedly revive dried out ribbons by soaking them in WD40. I’ve > heard of it but never tried it. > > On Wed, Aug 8, 2018 at 10:14 PM wrote: >> >> Which was ...? >> >> Warner Losh wrote: >> >> > Especially if you use the WD40 trick for the ink ribbon. :) >> > >> > Warner >> > >> > On Wed, Aug 8, 2018, 1:14 PM Jim Geist wrote: >> > >> > > I have a functional LA120 in my house and can attest to the machine >> > > smell >> > > whenever I run it. From dave at horsfall.org Thu Aug 9 17:20:36 2018 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 9 Aug 2018 17:20:36 +1000 (EST) Subject: [TUHS] the distinct smell of light machine oil, was Re: TUHS Digest, Vol 33, Issue 7 In-Reply-To: References: <20180808123229.86FD5E465F@mailuser.nyi.internal> <6EBCF9E5-4600-42D6-9F83-3E2966140540@donhopkins.com> <20180808135106.D7441E4636@mailuser.nyi.internal> <5B6B2A78.7070303@texoma.net> <201808090514.w795ESAh018689@freefriends.org> Message-ID: On Wed, 8 Aug 2018, Jim Geist wrote: > You can supposedly revive dried out ribbons by soaking them in WD40. > I’ve heard of it but never tried it. It's a common trick in the Teletype[tm] world (usually RTTY enthusiasts i.e. Amateur radio teletype). -- Dave (VK2KFU) From doug at cs.dartmouth.edu Thu Aug 9 22:19:18 2018 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Thu, 09 Aug 2018 08:19:18 -0400 Subject: [TUHS] Happy, birthday, Marvin Minsky Message-ID: <201808091219.w79CJIDD038630@tahoe.cs.Dartmouth.EDU> > ... Minsky ... invented neural networks A little baldy put. Minsky did study them and famously proved severe limitations on the learning capability of the simple perceptron model. Mathematical models of neural networks originaated with McCulloch and Pitts; perceptrons with Rosenblat. doug From imp at bsdimp.com Thu Aug 9 22:36:25 2018 From: imp at bsdimp.com (Warner Losh) Date: Thu, 9 Aug 2018 06:36:25 -0600 Subject: [TUHS] the distinct smell of light machine oil, was Re: TUHS Digest, Vol 33, Issue 7 In-Reply-To: References: <20180808123229.86FD5E465F@mailuser.nyi.internal> <6EBCF9E5-4600-42D6-9F83-3E2966140540@donhopkins.com> <20180808135106.D7441E4636@mailuser.nyi.internal> <5B6B2A78.7070303@texoma.net> <201808090514.w795ESAh018689@freefriends.org> Message-ID: It works. For the ribbon type printers, it gets the ink moving enough to get a second or third use from the cart. Print quality was dicey, but for listings to do debugging on a dot matrix printer, quality wasn't the name of the game. Just don't use too much... Warner On Wed, Aug 8, 2018, 11:56 PM Jim Geist wrote: > You can supposedly revive dried out ribbons by soaking them in WD40. I’ve > heard of it but never tried it. > > On Wed, Aug 8, 2018 at 10:14 PM wrote: > >> Which was ...? >> >> Warner Losh wrote: >> >> > Especially if you use the WD40 trick for the ink ribbon. :) >> > >> > Warner >> > >> > On Wed, Aug 8, 2018, 1:14 PM Jim Geist wrote: >> > >> > > I have a functional LA120 in my house and can attest to the machine >> smell >> > > whenever I run it. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Aug 9 23:31:39 2018 From: clemc at ccc.com (Clem Cole) Date: Thu, 9 Aug 2018 09:31:39 -0400 Subject: [TUHS] the distinct smell of light machine oil, was Re: TUHS Digest, Vol 33, Issue 7 In-Reply-To: References: <20180808123229.86FD5E465F@mailuser.nyi.internal> <6EBCF9E5-4600-42D6-9F83-3E2966140540@donhopkins.com> <20180808135106.D7441E4636@mailuser.nyi.internal> <5B6B2A78.7070303@texoma.net> Message-ID: On Wed, Aug 8, 2018 at 4:44 PM, Warner Losh wrote: > Especially if you use the WD40 trick for the ink ribbon. : > Hmmrrph.... Youngsters... WD40 is silcon based. Real "3 in One" oil (came in a small can) is light machine oil but you can still get it: https://www.3inone.com/handyu/ It's what Teletype used (and spec'ed in the maintence manual). Different odor. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfawcus+lists-tuhs at employees.org Fri Aug 10 00:15:09 2018 From: dfawcus+lists-tuhs at employees.org (Derek Fawcus) Date: Thu, 9 Aug 2018 15:15:09 +0100 Subject: [TUHS] the distinct smell of light machine oil, was Re: TUHS Digest, Vol 33, Issue 7 In-Reply-To: References: <20180808123229.86FD5E465F@mailuser.nyi.internal> <6EBCF9E5-4600-42D6-9F83-3E2966140540@donhopkins.com> <20180808135106.D7441E4636@mailuser.nyi.internal> <5B6B2A78.7070303@texoma.net> Message-ID: <20180809141509.GA91112@accordion.employees.org> On Thu, Aug 09, 2018 at 09:31:39AM -0400, Clem Cole wrote: > Hmmrrph.... Youngsters... WD40 is silcon based. I didn't know that; never I checked the can; but yeah a distinctive smell... > Real "3 in One" oil > (came in a small can) is light machine oil but you can still get it: Yup, useful on bike chains and oilstones (as in sharpening chisels and planes). DF From ewayte at gmail.com Fri Aug 10 00:26:32 2018 From: ewayte at gmail.com (Eric Wayte) Date: Thu, 9 Aug 2018 10:26:32 -0400 Subject: [TUHS] the distinct smell of light machine oil, was Re: TUHS Digest, Vol 33, Issue 7 In-Reply-To: <20180809141509.GA91112@accordion.employees.org> References: <20180808123229.86FD5E465F@mailuser.nyi.internal> <6EBCF9E5-4600-42D6-9F83-3E2966140540@donhopkins.com> <20180808135106.D7441E4636@mailuser.nyi.internal> <5B6B2A78.7070303@texoma.net> <20180809141509.GA91112@accordion.employees.org> Message-ID: In an episode of The Little Rascals / Our Gang series, the teacher asked a little girl what's 2 and 1, and she replied "shoe polish". The teacher then asked her, what's 3 and 1, to which she replied "oil". On Thu, Aug 9, 2018 at 10:15 AM Derek Fawcus < dfawcus+lists-tuhs at employees.org> wrote: > On Thu, Aug 09, 2018 at 09:31:39AM -0400, Clem Cole wrote: > > Hmmrrph.... Youngsters... WD40 is silcon based. > > I didn't know that; never I checked the can; but yeah a distinctive > smell... > > > Real "3 in One" oil > > (came in a small can) is light machine oil but you can still get it: > > Yup, useful on bike chains and oilstones (as in sharpening chisels and > planes). > > DF > -- Eric Wayte -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Fri Aug 10 01:14:11 2018 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 09 Aug 2018 17:14:11 +0200 Subject: [TUHS] Sort of off-topic: usefulness of TUHS list and archive? In-Reply-To: <20180808083706.GA20345@minnie.tuhs.org> References: <20180808083706.GA20345@minnie.tuhs.org> Message-ID: <20180809151411.uvoKZ%steffen@sdaoden.eu> Warren Toomey wrote in <20180808083706.GA20345 at minnie.tuhs.org>: |All, sorry that this is tangential to TUHS. I work at TAFE Queensland, \ |which |is a bit like a polytechnic or a U.S college. As a teacher, I have to |demonstrate industry skills. I've listed my administration of the TUHS \ |server |over 25+ years. However, TAFE wants this to be verified by third parties: | | "Where possible the teacher could show that industry endorses his | website and any if there are any testimonials/comments/reviews | available on the site, these could also be provided." | |So, if you could pop a sentence or two in reply to this e-mail about |the usefulness of the TUHS archive and the mailing list, that would be |really helpful! To me TUHS is an invaluable source of data and knowledge context, especially with utree.pl i have worked many hours. I know it also as been used as a knowledge base to fill in the gaps in order to create correct ".Sh HISTORY" manual entries in BSD land. |Cheers & thanks in advance, Warren Thank you in return very much indeed. --End of <20180808083706.GA20345 at minnie.tuhs.org> --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 mparson at bl.org Thu Aug 9 23:45:55 2018 From: mparson at bl.org (Michael Parson) Date: Thu, 9 Aug 2018 08:45:55 -0500 (CDT) Subject: [TUHS] the distinct smell of light machine oil, was Re: TUHS Digest, Vol 33, Issue 7 In-Reply-To: References: <20180808123229.86FD5E465F@mailuser.nyi.internal> <6EBCF9E5-4600-42D6-9F83-3E2966140540@donhopkins.com> <20180808135106.D7441E4636@mailuser.nyi.internal> <5B6B2A78.7070303@texoma.net> <201808090514.w795ESAh018689@freefriends.org> Message-ID: On Thu, 9 Aug 2018, Warner Losh wrote: > On Wed, Aug 8, 2018, 11:56 PM Jim Geist wrote: > >> On Wed, Aug 8, 2018 at 10:14 PM wrote: >> >>> Which was ...? > >> You can supposedly revive dried out ribbons by soaking them in WD40. I’ve >> heard of it but never tried it. > > It works. For the ribbon type printers, it gets the ink moving enough to > get a second or third use from the cart. Print quality was dicey, but for > listings to do debugging on a dot matrix printer, quality wasn't the name > of the game. Just don't use too much... I don't have much experience with hardcopy terminals, but I did use the WD-40 trick on dot-matrix printers in the 80s (Commodore MPS 803 was my first printer). Only time I used a hard-copy term was at my first job at a university computer lab, our line printer went down, so, I dragged an LA120 out of storage and hooked it up to serve as the printer until we could get the line printer serviced. -- Michael Parson Pflugerville, TX KF5LGQ From pete at dunnington.plus.com Fri Aug 10 21:37:32 2018 From: pete at dunnington.plus.com (Pete Turnbull) Date: Fri, 10 Aug 2018 12:37:32 +0100 Subject: [TUHS] the distinct smell of light machine oil, was Re: TUHS Digest, Vol 33, Issue 7 In-Reply-To: References: <20180808123229.86FD5E465F@mailuser.nyi.internal> <6EBCF9E5-4600-42D6-9F83-3E2966140540@donhopkins.com> <20180808135106.D7441E4636@mailuser.nyi.internal> <5B6B2A78.7070303@texoma.net> <20180809141509.GA91112@accordion.employees.org> Message-ID: <11da6a84-0ac3-cfe9-30c5-0d37ebc5f016@dunnington.plus.com> On 09/08/2018 15:26, Eric Wayte wrote: > In an episode of The Little Rascals / Our Gang series, the teacher asked > a little girl what's 2 and 1, and she replied "shoe polish".  The > teacher then asked her, what's 3 and 1, to which she replied "oil". I like that! -- Pete Pete Turnbull From pete at dunnington.plus.com Fri Aug 10 21:37:45 2018 From: pete at dunnington.plus.com (Pete Turnbull) Date: Fri, 10 Aug 2018 12:37:45 +0100 Subject: [TUHS] the distinct smell of light machine oil, was Re: TUHS Digest, Vol 33, Issue 7 In-Reply-To: <20180809141509.GA91112@accordion.employees.org> References: <20180808123229.86FD5E465F@mailuser.nyi.internal> <6EBCF9E5-4600-42D6-9F83-3E2966140540@donhopkins.com> <20180808135106.D7441E4636@mailuser.nyi.internal> <5B6B2A78.7070303@texoma.net> <20180809141509.GA91112@accordion.employees.org> Message-ID: On 09/08/2018 15:15, Derek Fawcus wrote: > On Thu, Aug 09, 2018 at 09:31:39AM -0400, Clem Cole wrote: >> Hmmrrph.... Youngsters... WD40 is silcon based. > > I didn't know that; never I checked the can; but yeah a distinctive smell... Ordinary WD40 is NOT silicone based (obNitPick: note the 'e': not silicon, which is a hard crystalline substance). There is a "specialist" silicone-based version but ordinary WD40 is hydrocarbon based, being a mixture of light paraffin (naptha to transpondians, ie the stuff that's used as a solvent or fuel) and a paraffin wax, as stated in the manufacturer's official MSDS document. The characteristic smell is largely from an aromatic hydrocarbon additive. >> Real "3 in One" oil >> (came in a small can) is light machine oil but you can still get it: > > Yup, useful on bike chains and oilstones (as in sharpening chisels and planes). And not much else, because like a lot of simple hydrocarbon oils developed half a century or more ago, it oxidises to a gummy substance. The Teletype manual definitely doesn't suggest 3-in-One oil and some sources suggest it's too thick anyway. The manual in front of me specifies two Western Electric part numbers for oil and grease. It's been discussed more than once on the Greenkeys list, and there's a useful page listing modern equivalents at Doug Jones' page: https://homepage.cs.uiowa.edu/~jones/pdp8/UI-8/ks7470oil.shtml -- Pete Pete Turnbull From tih at hamartun.priv.no Sat Aug 11 02:24:19 2018 From: tih at hamartun.priv.no (Tom Ivar Helbekkmo) Date: Fri, 10 Aug 2018 18:24:19 +0200 Subject: [TUHS] the distinct smell of light machine oil, was Re: TUHS Digest, Vol 33, Issue 7 In-Reply-To: (Pete Turnbull's message of "Fri, 10 Aug 2018 12:37:45 +0100") References: <20180808123229.86FD5E465F@mailuser.nyi.internal> <6EBCF9E5-4600-42D6-9F83-3E2966140540@donhopkins.com> <20180808135106.D7441E4636@mailuser.nyi.internal> <5B6B2A78.7070303@texoma.net> <20180809141509.GA91112@accordion.employees.org> Message-ID: Pete Turnbull writes: > The Teletype manual definitely doesn't suggest 3-in-One oil and some > sources suggest it's too thick anyway. The manual in front of me > specifies two Western Electric part numbers for oil and grease. A couple of decades ago, I got hold of a Teletype that sort of worked, but was extremely unreliable. After studying that manual, and deciding that the proper lubrication plan was too complex for my tastes, I just turned the thing on with the top off, and emptied a spray can of CRC 5-56 into the mechanism while exercising the keyboard. It proceeded to work well for my off-and-on use for several years after that. -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From pete at dunnington.plus.com Sat Aug 11 02:58:18 2018 From: pete at dunnington.plus.com (Pete Turnbull) Date: Fri, 10 Aug 2018 17:58:18 +0100 Subject: [TUHS] the distinct smell of light machine oil, was Re: TUHS Digest, Vol 33, Issue 7 In-Reply-To: References: <20180808123229.86FD5E465F@mailuser.nyi.internal> <6EBCF9E5-4600-42D6-9F83-3E2966140540@donhopkins.com> <20180808135106.D7441E4636@mailuser.nyi.internal> <5B6B2A78.7070303@texoma.net> <20180809141509.GA91112@accordion.employees.org> Message-ID: <85b526f8-7327-6210-05fb-29bdfbe7d726@dunnington.plus.com> On 10/08/2018 17:24, Tom Ivar Helbekkmo wrote: > Pete Turnbull writes: > >> The Teletype manual definitely doesn't suggest 3-in-One oil > > A couple of decades ago, I got hold of a Teletype that sort of worked, > but was extremely unreliable. After studying that manual, and deciding > that the proper lubrication plan was too complex for my tastes, I just > turned the thing on with the top off, and emptied a spray can of CRC > 5-56 into the mechanism while exercising the keyboard. It proceeded to > work well for my off-and-on use for several years after that. TBH, I suspect that for occasional use, you don't need to use the perfect lubricants, just not something that turns into glue during periods of disuse. I wouldn't spray WD40 into anything, though, except maybe a dried out ribbon which was what Warner described. -- Pete Pete Turnbull From ca6c at bitmessage.ch Sat Aug 11 06:34:48 2018 From: ca6c at bitmessage.ch (=?utf-8?B?Q8OhZw==?=) Date: Fri, 10 Aug 2018 15:34:48 -0500 Subject: [TUHS] Sort of off-topic: usefulness of TUHS list and archive? In-Reply-To: <20180809151411.uvoKZ%steffen@sdaoden.eu> References: <20180808083706.GA20345@minnie.tuhs.org> <20180809151411.uvoKZ%steffen@sdaoden.eu> Message-ID: <20180810203448.BNAXC%ca6c@bitmessage.ch> Steffen Nurpmeso wrote: > To me TUHS is an invaluable source of data and knowledge context, > especially with utree.pl i have worked many hours. > I know it also as been used as a knowledge base to fill in the > gaps in order to create correct ".Sh HISTORY" manual entries in > BSD land. I know right, also the amount of books, biographies and advice that is mentioned here makes it not only interesting, but practically applicable as well. -- caóc From doug at cs.dartmouth.edu Mon Aug 13 11:32:31 2018 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sun, 12 Aug 2018 21:32:31 -0400 Subject: [TUHS] [groff] Creating a numbered list without macros Message-ID: <201808130132.w7D1WVJ3123817@tahoe.cs.Dartmouth.EDU> > Why create ms when you have mm? Well, the real reason is that ms was the very first macro package. It has held up spectactularly well, evolving much less than the underlying [ntg]roff. Doug From arnold at skeeve.com Mon Aug 13 16:34:06 2018 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 13 Aug 2018 00:34:06 -0600 Subject: [TUHS] [groff] Creating a numbered list without macros In-Reply-To: <201808130132.w7D1WVJ3123817@tahoe.cs.Dartmouth.EDU> References: <201808130132.w7D1WVJ3123817@tahoe.cs.Dartmouth.EDU> Message-ID: <201808130634.w7D6Y66T030631@freefriends.org> Doug McIlroy wrote: > > Why create ms when you have mm? > > Well, the real reason is that ms was the very first macro package. > It has held up spectactularly well, evolving much less than the > underlying [ntg]roff. > > Doug Or say, rather, the first *general purpose* macro package. The man macros predate it. :-) Arnold From arnold at skeeve.com Tue Aug 14 05:06:37 2018 From: arnold at skeeve.com (Arnold Robbins) Date: Mon, 13 Aug 2018 22:06:37 +0300 Subject: [TUHS] Can anyone point me to source for a lex that works on Linux? Message-ID: <201808131906.w7DJ6bAw005597@skeeve.com> Hi. Can anyone point me to source for Unix lex that can be compiled and works on Linux? I've tried in the past to make V7 lex work and failed. Thanks, Arnold From ron at ronnatalie.com Tue Aug 14 05:57:12 2018 From: ron at ronnatalie.com (ron at ronnatalie.com) Date: Mon, 13 Aug 2018 15:57:12 -0400 Subject: [TUHS] Can anyone point me to source for a lex that works on Linux? In-Reply-To: <201808131906.w7DJ6bAw005597@skeeve.com> References: <201808131906.w7DJ6bAw005597@skeeve.com> Message-ID: <08bd01d4333f$d4dfa5d0$7e9ef170$@ronnatalie.com> Does it have to be UNIX lex or will the GNU Flex work for you (that's what most of the LINUX stuff uses)? -----Original Message----- From: TUHS On Behalf Of Arnold Robbins Sent: Monday, August 13, 2018 3:07 PM To: tuhs at tuhs.org Subject: [TUHS] Can anyone point me to source for a lex that works on Linux? Hi. Can anyone point me to source for Unix lex that can be compiled and works on Linux? I've tried in the past to make V7 lex work and failed. Thanks, Arnold From sj at sdf.org Tue Aug 14 07:03:44 2018 From: sj at sdf.org (Scot Jenkins) Date: Mon, 13 Aug 2018 17:03:44 -0400 Subject: [TUHS] Can anyone point me to source for a lex that works on Linux? In-Reply-To: <201808131906.w7DJ6bAw005597@skeeve.com> References: <201808131906.w7DJ6bAw005597@skeeve.com> Message-ID: <201808132103.w7DL3in4008770@sdf.org> Arnold Robbins wrote: > Can anyone point me to source for Unix lex that can be compiled and > works on Linux? I've tried in the past to make V7 lex work and failed. Heirloom development tools includes lex: http://heirloom.sourceforge.net/devtools.html I had it working on an older version of Slackware (12.x?) years ago. It should still build on current Linux systems. You need to build/install heirloom-sh first, then use it when building heirloom-devtools. scot From arnold at skeeve.com Tue Aug 14 17:41:01 2018 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 14 Aug 2018 01:41:01 -0600 Subject: [TUHS] Can anyone point me to source for a lex that works on Linux? In-Reply-To: <08bd01d4333f$d4dfa5d0$7e9ef170$@ronnatalie.com> References: <201808131906.w7DJ6bAw005597@skeeve.com> <08bd01d4333f$d4dfa5d0$7e9ef170$@ronnatalie.com> Message-ID: <201808140741.w7E7f1g8029806@freefriends.org> I am looking specifically for Unix lex; I have some old code that assumes some knowlede of lex internals. I will try the Heirloom Toolchest version that was mentioned in another message. Thanks to you and everyone who replied, Arnold wrote: > Does it have to be UNIX lex or will the GNU Flex work for you (that's what > most of the LINUX stuff uses)? > > > -----Original Message----- > From: TUHS On Behalf Of Arnold Robbins > Sent: Monday, August 13, 2018 3:07 PM > To: tuhs at tuhs.org > Subject: [TUHS] Can anyone point me to source for a lex that works on Linux? > > Hi. > > Can anyone point me to source for Unix lex that can be compiled and works on > Linux? I've tried in the past to make V7 lex work and failed. > > Thanks, > > Arnold From ca6c at bitmessage.ch Wed Aug 15 05:16:12 2018 From: ca6c at bitmessage.ch (=?utf-8?B?Q8OhZw==?=) Date: Tue, 14 Aug 2018 14:16:12 -0500 Subject: [TUHS] Can anyone point me to source for a lex that works on Linux? In-Reply-To: <08bd01d4333f$d4dfa5d0$7e9ef170$@ronnatalie.com> References: <201808131906.w7DJ6bAw005597@skeeve.com> <08bd01d4333f$d4dfa5d0$7e9ef170$@ronnatalie.com> Message-ID: <20180814191612.UM_UM%ca6c@bitmessage.ch> Ron wrote: > Does it have to be UNIX lex or will the GNU Flex work for you (that's > what most of the LINUX stuff uses)? Actually flex is not a GNU project, and is in fact based on the old Berkeley implementation, so it's kinda Unix-y. -- caóc From doug at cs.dartmouth.edu Wed Aug 15 06:29:10 2018 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Tue, 14 Aug 2018 16:29:10 -0400 Subject: [TUHS] [groff] Creating a numbered list without macros Message-ID: <201808142029.w7EKTAhh040340@tahoe.cs.Dartmouth.EDU> An arguable distinction: I thought hard about claiming priority for -ms. Joe Ossanna intended option -m to foster macro packages from the outset. -man was an early use, hidden in the man command. But -man was not packaged (in the sense of being an announced feature that can be used from its external description) until v7. -ms appeared in v6. Doug Arnold Robbins wrote: > Doug McIlroy wrote: > >>> Why create ms when you have mm? >> >> Well, the real reason is that ms was the very first macro package. >> It has held up spectactularly well, evolving much less than the >> underlying [ntg]roff. >> >> Doug > > Or say, rather, the first *general purpose* macro package. The man > macros predate it. :-) From dave at horsfall.org Wed Aug 15 09:20:25 2018 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 15 Aug 2018 09:20:25 +1000 (EST) Subject: [TUHS] Can anyone point me to source for a lex that works on Linux? In-Reply-To: <20180814191612.UM_UM%ca6c@bitmessage.ch> References: <201808131906.w7DJ6bAw005597@skeeve.com> <08bd01d4333f$d4dfa5d0$7e9ef170$@ronnatalie.com> <20180814191612.UM_UM%ca6c@bitmessage.ch> Message-ID: On Tue, 14 Aug 2018, Cág wrote: > Actually flex is not a GNU project, and is in fact based on the old > Berkeley implementation, so it's kinda Unix-y. And if Flex was indeed a Gnu project, then surely it would've been called Glex? :-) -- Dave From ron at ronnatalie.com Wed Aug 15 12:39:18 2018 From: ron at ronnatalie.com (ron at ronnatalie.com) Date: Tue, 14 Aug 2018 22:39:18 -0400 Subject: [TUHS] [groff] Creating a numbered list without macros In-Reply-To: <201808142029.w7EKTAhh040340@tahoe.cs.Dartmouth.EDU> References: <201808142029.w7EKTAhh040340@tahoe.cs.Dartmouth.EDU> Message-ID: <161001d43441$2aef2020$80cd6060$@ronnatalie.com> There was a bit of internal controversy at JHU when Michael John Muuss added his tmac.jm macro package. Many people thought the -mjm nroff option was a little self serving. From arnold at skeeve.com Wed Aug 15 16:22:48 2018 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 15 Aug 2018 00:22:48 -0600 Subject: [TUHS] [groff] Creating a numbered list without macros In-Reply-To: <201808142029.w7EKTAhh040340@tahoe.cs.Dartmouth.EDU> References: <201808142029.w7EKTAhh040340@tahoe.cs.Dartmouth.EDU> Message-ID: <201808150622.w7F6MmT8007272@freefriends.org> I wasn't aware of the history / distinction, thanks. Arnold Doug McIlroy wrote: > An arguable distinction: > > I thought hard about claiming priority for -ms. Joe Ossanna intended > option -m to foster macro packages from the outset. -man was an early use, > hidden in the man command. But -man was not packaged (in the sense of > being an announced feature that can be used from its external description) > until v7. -ms appeared in v6. > > Doug > > Arnold Robbins wrote: > > > Doug McIlroy wrote: > > > >>> Why create ms when you have mm? > >> > >> Well, the real reason is that ms was the very first macro package. > >> It has held up spectactularly well, evolving much less than the > >> underlying [ntg]roff. > >> > >> Doug > > > > Or say, rather, the first *general purpose* macro package. The man > > macros predate it. :-) From perry at piermont.com Sun Aug 19 05:57:33 2018 From: perry at piermont.com (Perry E. Metzger) Date: Sat, 18 Aug 2018 15:57:33 -0400 Subject: [TUHS] Formal Specification and Verification (was Re: TUHS Digest, Vol 33, Issue 5) In-Reply-To: <50772e199f3dcc5d4eba34d17322b5aef0aa0441@webmail.yaccman.com> References: <1533573030.3671.98.camel@mni.thm.de> <50772e199f3dcc5d4eba34d17322b5aef0aa0441@webmail.yaccman.com> Message-ID: <20180818155733.523a3d2d@jabberwock.cb.piermont.com> Sorry for the thread necromancy, but this is a _very_ important topic. Perhaps it doesn't belong on tuhs but rather on coff. This is a pretty long posting. If you don't care to read it, the TL;DR is that formal specification and verification is now a real discipline, which it wasn't in the old days, and there are systems to do it in, and it's well understood. On 2018-08-06 at 08:52 -0700, Bakul Shah wrote: > > What counts as a "formal spec"? Is it like Justice Potter > Stewart's "I know it when I see it" definition or something > better? At this point, we have a good definition. A formal specification is a description of the behavior of a program or piece of hardware in a precise machine-readable form that may be used as the basis for fully formal verification of the behavior of an implementation. Often these days, the specification is given in a formal logic, such as the predicative calculus of inductive constructions, which is the logic underlying the Coq system. Isabelle/HOL is another popular system for this sort of work. ACL2 is (from what I can tell) of more historical interest but it has apparently been used for things like the formal verification of floating point and cache control units for real hardware. (It is my understanding that it has been many years since Intel would dare release a system where the cache unit wasn't verified, and the only time in decades it tried to release a non-verified FPU, it got the FDIV bug and has never tried that again.) There are some others out there, like F*, Lean, etc. Formal specifications good enough for full formal verification have been made for a variety of artifacts along with proofs that the artifacts follow the specification. There's a fully formally verified C compiler called CompCert for example, based on an operational semantics written in Coq. There's another formal semantics for C written in K, which is a rather different formal system. There's a verified microkernel, seL4, whose specification is written in Isabelle/HOL. There's a fully formal specification of the RISC V, and an associated verified RTL implementation. Generally speaking, a formal specification: 1) Must be machine readable 2) The semantics of the underlying specification language must themselves be extremely precisely described. You can't prove the consistency and completeness of the underlying system (see Gödel) but you _can_ still strongly specify the language. 3) Must be usable for formal (that is, machine checkable) proofs that implementations comply with the spec, so it has to be sufficiently powerful. Typical systems are now equivalent to higher order logic. From: "Hellwig Geisse" Sent:Mon, 06 Aug 2018 18:30:30 +0200 > > For me, a "formal spec" should serve two goals: > 1) You can reason about the thing that is specified. Yes. 2) The spec can be "executed" (i.e., there is an > interpreting mechanism, which lets the spec behave > like the real thing). Not always reasonable. First, it is often the case that a spec does not describe execution at all. See, for example, the specification of a sorting function I give at the end of this message: it simply says "a sorting function is a function such that, for all inputs, the return is a non-decreasing permutation of the input". This is not executable. It is a purely descriptive property, and you cannot extract an executable algorithm from the spec. Second, even when a spec amounts to a description of execution, a proof assistant often cannot actually execute it. For example, although you can reason about non-terminating execution in pCiC (and thus Coq), programs written in a strongly normalizing lambda calculus that can be used as a logic must terminate, or functions that did not terminate would be inhabitants of all types and the logic would be inconsistent. Thus, you cannot execute a program with infinite loops inside Coq, although you can reason about them (and indeed, you can reason about coinductively defined objects like infinite execution traces.) On Mon, 06 Aug 2018 14:19:31 -0700 "Steve Johnson" wrote: > I take a somewhat more relaxed view of what a spec should be: > It should describe a program with enough completeness that a > competent programmer could write it from the spec alone. I think this is a bit more relaxed than is currently accepted. > The formal systems I have seen would roll over and die when > presented with even a simple compiler.__ I don't know what this means. If it is that there aren't implementations of languages like pCiC, that's not true, see Coq. If it means no one can formally specify a compiler, given that formally verified compilers exist, that's also not true. The "final theorem" proving the correctness of CompCert depends on having an operational semantics of both C and the target architecture, and says (more or less) that the observed behavior of the input program in C is the same as the observed behavior of the output program (say in ARM machine language). This is a serious piece of work, but it is also something that has actually been done -- the tools are capable of the task. > Additionally, being able to specify that a particular function be > carried out by a heapsort, for example, would require that the > formalism could describe the heapsort and prove it correct.__ These > don't grow on trees... Formally verifying a couple of sorting algorithms described in Coq is a exercise for an intro level class on formal verification. I've done it. Once you have the proper primitives described, the specification for a sorting algorithm in Coq looks like this: Definition is_a_sorting_algorithm (f: list nat -> list nat) := forall al, Permutation al (f al) /\ sorted (f al). That says "the property "is_a_sorting_algorithm" over a function from lists of natural numbers to lists of natural numbers is that the output is a permutation of the input in which all the elements are in non-decreasing order." The definitions in question are very precise. For example, one definition of sorted (the property of being a non-decreasing list) is: Definition sorted (al: list nat) := forall i j, i < j < length al -> nth i al 0 <= nth j al 0. and the property of being a permutation, which is relatively complicated inductively defined property, is: Inductive Permutation {A : Type} : list A -> list A -> Prop := perm_nil : Permutation | perm_skip : forall (x : A) (l l' : list A), Permutation l l' -> Permutation (x :: l) (x :: l') | perm_swap : forall (x y : A) (l : list A), Permutation (y :: x :: l) (x :: y :: l) | perm_trans : forall l l' l'' : list A, Permutation l l' -> Permutation l' l'' -> Permutation l l''. Coq starts out with basically nothing defined, by the way. Notions such as "natural number" and "list" are not built in. Peano naturals are defined in the system thusly: Inductive nat : Type := | O : nat | S : nat -> nat. The underlying basis of Coq (i.e. the Predicative Calculus of Inductive Constructions) is a dependently typed lambda calculus that's astonishingly simple, and the checker for proofs in the system is only a few hundred lines long -- the checker is the only portion of the system which needs to be trusted. In recent years, I've noted that "old timers" (such as many of us, myself included) seem to be unaware of the fact that systems like Coq exist, or that it is now relatively (I emphasize _relatively_) routine for substantial systems to be fully formally specified and then fully formally verified. Perry -- Perry E. Metzger perry at piermont.com From ggm at algebras.org Mon Aug 20 09:47:58 2018 From: ggm at algebras.org (George Michaelson) Date: Mon, 20 Aug 2018 09:47:58 +1000 Subject: [TUHS] Formal Specification and Verification (was Re: TUHS Digest, Vol 33, Issue 5) In-Reply-To: <20180818155733.523a3d2d@jabberwock.cb.piermont.com> References: <1533573030.3671.98.camel@mni.thm.de> <50772e199f3dcc5d4eba34d17322b5aef0aa0441@webmail.yaccman.com> <20180818155733.523a3d2d@jabberwock.cb.piermont.com> Message-ID: Witness to this, the interest in *trying* to apply Coq to Ethereum smart contracts... I say "try" because as a complete skeptic, I think the attempt is doomed except in very small sense. But the reason they are trying is the importance to FinTech of formally verified state in the expression of financial transactions. These are serious people. A bunch from french academic research institutions, a bunch from the CSIRO in Australia. I think Perry wrote something of long term value. I encourage you to write this up somewhere you'd be willing to have published like a tech blog. -G On Sun, Aug 19, 2018 at 5:57 AM, Perry E. Metzger wrote: > Sorry for the thread necromancy, but this is a _very_ important > topic. Perhaps it doesn't belong on tuhs but rather on coff. > > This is a pretty long posting. If you don't care to read it, the TL;DR > is that formal specification and verification is now a real > discipline, which it wasn't in the old days, and there are systems to > do it in, and it's well understood. > > On 2018-08-06 at 08:52 -0700, Bakul Shah wrote: >> >> What counts as a "formal spec"? Is it like Justice Potter >> Stewart's "I know it when I see it" definition or something >> better? > > At this point, we have a good definition. A formal specification is a > description of the behavior of a program or piece of hardware in a > precise machine-readable form that may be used as the basis for fully > formal verification of the behavior of an implementation. Often these > days, the specification is given in a formal logic, such as the > predicative calculus of inductive constructions, which is the logic > underlying the Coq system. > > Isabelle/HOL is another popular system for this sort of work. ACL2 is > (from what I can tell) of more historical interest but it has > apparently been used for things like the formal verification of > floating point and cache control units for real hardware. (It is my > understanding that it has been many years since Intel would dare > release a system where the cache unit wasn't verified, and the only > time in decades it tried to release a non-verified FPU, it got the > FDIV bug and has never tried that again.) There are some others out > there, like F*, Lean, etc. > > Formal specifications good enough for full formal verification have > been made for a variety of artifacts along with proofs that the > artifacts follow the specification. There's a fully formally verified > C compiler called CompCert for example, based on an operational > semantics written in Coq. There's another formal semantics for C > written in K, which is a rather different formal system. There's a > verified microkernel, seL4, whose specification is written in > Isabelle/HOL. There's a fully formal specification of the RISC V, and > an associated verified RTL implementation. > > Generally speaking, a formal specification: > > 1) Must be machine readable > 2) The semantics of the underlying specification language must > themselves be extremely precisely described. You can't prove the > consistency and completeness of the underlying system (see Gödel) > but you _can_ still strongly specify the language. > 3) Must be usable for formal (that is, machine checkable) proofs that > implementations comply with the spec, so it has to be sufficiently > powerful. Typical systems are now equivalent to higher order logic. > > From: "Hellwig Geisse" > Sent:Mon, 06 Aug 2018 18:30:30 +0200 >> >> For me, a "formal spec" should serve two goals: >> 1) You can reason about the thing that is specified. > > Yes. > > 2) The spec can be "executed" (i.e., there is an >> interpreting mechanism, which lets the spec behave >> like the real thing). > > Not always reasonable. > > First, it is often the case that a spec does not describe execution at > all. See, for example, the specification of a sorting function I give > at the end of this message: it simply says "a sorting function is a > function such that, for all inputs, the return is a non-decreasing > permutation of the input". This is not executable. It is a purely > descriptive property, and you cannot extract an executable algorithm > from the spec. > > Second, even when a spec amounts to a description of execution, a > proof assistant often cannot actually execute it. For example, > although you can reason about non-terminating execution in pCiC (and > thus Coq), programs written in a strongly normalizing lambda calculus > that can be used as a logic must terminate, or functions that did not > terminate would be inhabitants of all types and the logic would be > inconsistent. Thus, you cannot execute a program with infinite loops > inside Coq, although you can reason about them (and indeed, you can > reason about coinductively defined objects like infinite execution > traces.) > > On Mon, 06 Aug 2018 14:19:31 -0700 "Steve Johnson" > wrote: >> I take a somewhat more relaxed view of what a spec should be: >> It should describe a program with enough completeness that a >> competent programmer could write it from the spec alone. > > I think this is a bit more relaxed than is currently accepted. > >> The formal systems I have seen would roll over and die when >> presented with even a simple compiler.__ > > I don't know what this means. If it is that there aren't > implementations of languages like pCiC, that's not true, see Coq. If > it means no one can formally specify a compiler, given that formally > verified compilers exist, that's also not true. > > The "final theorem" proving the correctness of CompCert depends on > having an operational semantics of both C and the target architecture, > and says (more or less) that the observed behavior of the input > program in C is the same as the observed behavior of the output > program (say in ARM machine language). This is a serious piece of > work, but it is also something that has actually been done -- the > tools are capable of the task. > >> Additionally, being able to specify that a particular function be >> carried out by a heapsort, for example, would require that the >> formalism could describe the heapsort and prove it correct.__ These >> don't grow on trees... > > Formally verifying a couple of sorting algorithms described in Coq is > a exercise for an intro level class on formal verification. I've done > it. Once you have the proper primitives described, the specification > for a sorting algorithm in Coq looks like this: > > Definition is_a_sorting_algorithm (f: list nat -> list nat) := > forall al, Permutation al (f al) /\ sorted (f al). > > That says "the property "is_a_sorting_algorithm" over a function from > lists of natural numbers to lists of natural numbers is that the > output is a permutation of the input in which all the elements are in > non-decreasing order." The definitions in question are very > precise. For example, one definition of sorted (the property of being > a non-decreasing list) is: > > Definition sorted (al: list nat) := > forall i j, i < j < length al -> nth i al 0 <= nth j al 0. > > and the property of being a permutation, which is relatively > complicated inductively defined property, is: > > Inductive Permutation {A : Type} : list A -> list A -> Prop := > perm_nil : Permutation > | perm_skip : forall (x : A) (l l' : list A), > Permutation l l' -> > Permutation (x :: l) (x :: l') > | perm_swap : forall (x y : A) (l : list A), > Permutation (y :: x :: l) (x :: y :: l) > | perm_trans : forall l l' l'' : list A, > Permutation l l' -> > Permutation l' l'' -> > Permutation l l''. > > Coq starts out with basically nothing defined, by the way. Notions > such as "natural number" and "list" are not built in. Peano naturals > are defined in the system thusly: > > Inductive nat : Type := > | O : nat > | S : nat -> nat. > > The underlying basis of Coq (i.e. the Predicative Calculus of > Inductive Constructions) is a dependently typed lambda calculus that's > astonishingly simple, and the checker for proofs in the system is only > a few hundred lines long -- the checker is the only portion of the > system which needs to be trusted. > > In recent years, I've noted that "old timers" (such as many of us, > myself included) seem to be unaware of the fact that systems like Coq > exist, or that it is now relatively (I emphasize _relatively_) routine > for substantial systems to be fully formally specified and then fully > formally verified. > > > Perry > -- > Perry E. Metzger perry at piermont.com From perry at piermont.com Mon Aug 20 10:57:58 2018 From: perry at piermont.com (Perry E. Metzger) Date: Sun, 19 Aug 2018 20:57:58 -0400 Subject: [TUHS] Formal Specification and Verification (was Re: TUHS Digest, Vol 33, Issue 5) In-Reply-To: References: <1533573030.3671.98.camel@mni.thm.de> <50772e199f3dcc5d4eba34d17322b5aef0aa0441@webmail.yaccman.com> <20180818155733.523a3d2d@jabberwock.cb.piermont.com> Message-ID: <20180819205758.6903142c@jabberwock.cb.piermont.com> On Mon, 20 Aug 2018 09:47:58 +1000 George Michaelson wrote: > Witness to this, the interest in *trying* to apply Coq to Ethereum > smart contracts... The Tezos cryptocurrency was created with a smart contract language specifically designed for formal verification. > I think Perry wrote something of long term value. I encourage you to > write this up somewhere you'd be willing to have published like a > tech blog. Not sure where one would publish it. I also note that the general response here was the one I almost always get when I mention this stuff to people, which is near silence. (I used to get exactly this response 30 or 35 years ago when explaining the Internet to most people who had not yet come into contact with it, so I suppose it's not overly surprising.) That said, let me make a strong prediction: in not very many years, pretty much everyone doing serious work in computer science (say, designing security protocols, building mission critical systems, etc.) will be building them using some sort of formal verification assistant systems. I suspect this change will be as transformative as the triumph of high level languages over the previous supremacy of machine language coding. (For those that forget, one of the things that made Unix successful was, of course, that unlike many other OSes of the era, it was (ultimately) written in a portable language and not in machine code.) People who don't use formal verification when writing serious code will seem as antiquated and irresponsible as people who build mission critical systems now without test coverage. This is going to be a big revolution. Perry > -G > > On Sun, Aug 19, 2018 at 5:57 AM, Perry E. Metzger > wrote: > > Sorry for the thread necromancy, but this is a _very_ important > > topic. Perhaps it doesn't belong on tuhs but rather on coff. > > > > This is a pretty long posting. If you don't care to read it, the > > TL;DR is that formal specification and verification is now a real > > discipline, which it wasn't in the old days, and there are > > systems to do it in, and it's well understood. > > > > On 2018-08-06 at 08:52 -0700, Bakul Shah wrote: > >> > >> What counts as a "formal spec"? Is it like Justice Potter > >> Stewart's "I know it when I see it" definition or something > >> better? > > > > At this point, we have a good definition. A formal specification > > is a description of the behavior of a program or piece of > > hardware in a precise machine-readable form that may be used as > > the basis for fully formal verification of the behavior of an > > implementation. Often these days, the specification is given in a > > formal logic, such as the predicative calculus of inductive > > constructions, which is the logic underlying the Coq system. > > > > Isabelle/HOL is another popular system for this sort of work. > > ACL2 is (from what I can tell) of more historical interest but it > > has apparently been used for things like the formal verification > > of floating point and cache control units for real hardware. (It > > is my understanding that it has been many years since Intel would > > dare release a system where the cache unit wasn't verified, and > > the only time in decades it tried to release a non-verified FPU, > > it got the FDIV bug and has never tried that again.) There are > > some others out there, like F*, Lean, etc. > > > > Formal specifications good enough for full formal verification > > have been made for a variety of artifacts along with proofs that > > the artifacts follow the specification. There's a fully formally > > verified C compiler called CompCert for example, based on an > > operational semantics written in Coq. There's another formal > > semantics for C written in K, which is a rather different formal > > system. There's a verified microkernel, seL4, whose specification > > is written in Isabelle/HOL. There's a fully formal specification > > of the RISC V, and an associated verified RTL implementation. > > > > Generally speaking, a formal specification: > > > > 1) Must be machine readable > > 2) The semantics of the underlying specification language must > > themselves be extremely precisely described. You can't prove > > the consistency and completeness of the underlying system (see > > G__del) but you _can_ still strongly specify the language. > > 3) Must be usable for formal (that is, machine checkable) proofs > > that implementations comply with the spec, so it has to be > > sufficiently powerful. Typical systems are now equivalent to > > higher order logic. > > > > From: "Hellwig Geisse" > > Sent:Mon, 06 Aug 2018 18:30:30 +0200 > >> > >> For me, a "formal spec" should serve two goals: > >> 1) You can reason about the thing that is specified. > > > > Yes. > > > > 2) The spec can be "executed" (i.e., there is an > >> interpreting mechanism, which lets the spec behave > >> like the real thing). > > > > Not always reasonable. > > > > First, it is often the case that a spec does not describe > > execution at all. See, for example, the specification of a > > sorting function I give at the end of this message: it simply > > says "a sorting function is a function such that, for all inputs, > > the return is a non-decreasing permutation of the input". This is > > not executable. It is a purely descriptive property, and you > > cannot extract an executable algorithm from the spec. > > > > Second, even when a spec amounts to a description of execution, a > > proof assistant often cannot actually execute it. For example, > > although you can reason about non-terminating execution in pCiC > > (and thus Coq), programs written in a strongly normalizing lambda > > calculus that can be used as a logic must terminate, or functions > > that did not terminate would be inhabitants of all types and the > > logic would be inconsistent. Thus, you cannot execute a program > > with infinite loops inside Coq, although you can reason about > > them (and indeed, you can reason about coinductively defined > > objects like infinite execution traces.) > > > > On Mon, 06 Aug 2018 14:19:31 -0700 "Steve Johnson" > > wrote: > >> I take a somewhat more relaxed view of what a spec should be: > >> It should describe a program with enough completeness that a > >> competent programmer could write it from the spec alone. > > > > I think this is a bit more relaxed than is currently accepted. > > > >> The formal systems I have seen would roll over and die when > >> presented with even a simple compiler.__ > > > > I don't know what this means. If it is that there aren't > > implementations of languages like pCiC, that's not true, see Coq. > > If it means no one can formally specify a compiler, given that > > formally verified compilers exist, that's also not true. > > > > The "final theorem" proving the correctness of CompCert depends on > > having an operational semantics of both C and the target > > architecture, and says (more or less) that the observed behavior > > of the input program in C is the same as the observed behavior of > > the output program (say in ARM machine language). This is a > > serious piece of work, but it is also something that has actually > > been done -- the tools are capable of the task. > > > >> Additionally, being able to specify that a particular function be > >> carried out by a heapsort, for example, would require that the > >> formalism could describe the heapsort and prove it correct.__ > >> These don't grow on trees... > > > > Formally verifying a couple of sorting algorithms described in > > Coq is a exercise for an intro level class on formal > > verification. I've done it. Once you have the proper primitives > > described, the specification for a sorting algorithm in Coq looks > > like this: > > > > Definition is_a_sorting_algorithm (f: list nat -> list nat) := > > forall al, Permutation al (f al) /\ sorted (f al). > > > > That says "the property "is_a_sorting_algorithm" over a function > > from lists of natural numbers to lists of natural numbers is that > > the output is a permutation of the input in which all the > > elements are in non-decreasing order." The definitions in > > question are very precise. For example, one definition of sorted > > (the property of being a non-decreasing list) is: > > > > Definition sorted (al: list nat) := > > forall i j, i < j < length al -> nth i al 0 <= nth j al 0. > > > > and the property of being a permutation, which is relatively > > complicated inductively defined property, is: > > > > Inductive Permutation {A : Type} : list A -> list A -> Prop := > > perm_nil : Permutation > > | perm_skip : forall (x : A) (l l' : list A), > > Permutation l l' -> > > Permutation (x :: l) (x :: l') > > | perm_swap : forall (x y : A) (l : list A), > > Permutation (y :: x :: l) (x :: y :: l) > > | perm_trans : forall l l' l'' : list A, > > Permutation l l' -> > > Permutation l' l'' -> > > Permutation l l''. > > > > Coq starts out with basically nothing defined, by the way. Notions > > such as "natural number" and "list" are not built in. Peano > > naturals are defined in the system thusly: > > > > Inductive nat : Type := > > | O : nat > > | S : nat -> nat. > > > > The underlying basis of Coq (i.e. the Predicative Calculus of > > Inductive Constructions) is a dependently typed lambda calculus > > that's astonishingly simple, and the checker for proofs in the > > system is only a few hundred lines long -- the checker is the > > only portion of the system which needs to be trusted. > > > > In recent years, I've noted that "old timers" (such as many of us, > > myself included) seem to be unaware of the fact that systems like > > Coq exist, or that it is now relatively (I emphasize > > _relatively_) routine for substantial systems to be fully > > formally specified and then fully formally verified. > > > > > > Perry > > -- > > Perry E. Metzger perry at piermont.com > -- Perry E. Metzger perry at piermont.com From wkt at tuhs.org Mon Aug 20 13:29:32 2018 From: wkt at tuhs.org (Warren Toomey) Date: Mon, 20 Aug 2018 13:29:32 +1000 Subject: [TUHS] Formal Specification and Verification In-Reply-To: <20180819205758.6903142c@jabberwock.cb.piermont.com> References: <1533573030.3671.98.camel@mni.thm.de> <50772e199f3dcc5d4eba34d17322b5aef0aa0441@webmail.yaccman.com> <20180818155733.523a3d2d@jabberwock.cb.piermont.com> <20180819205758.6903142c@jabberwock.cb.piermont.com> Message-ID: <20180820032932.GB29224@minnie.tuhs.org> I've forwarded the last e-mail in this thread to the COFF mailing list, as it's strictly not TUHS related. Feel free to continue engaging in the conversation over there! Cheers, Warren From pnr at planet.nl Mon Aug 20 18:12:32 2018 From: pnr at planet.nl (Paul Ruizendaal) Date: Mon, 20 Aug 2018 10:12:32 +0200 Subject: [TUHS] Formal Specification and Verification Message-ID: > I also note that the general response here was the one I almost always > get when I mention this stuff to people, which is near silence. Don’t take that as disinterest. For me at least it simply reflects that I need to find some time to read up on and digest the points you were making. Paul From dot at dotat.at Tue Aug 21 04:48:15 2018 From: dot at dotat.at (Tony Finch) Date: Mon, 20 Aug 2018 19:48:15 +0100 Subject: [TUHS] Formal Specification and Verification (was Re: TUHS Digest, Vol 33, Issue 5) In-Reply-To: <20180818155733.523a3d2d@jabberwock.cb.piermont.com> References: <1533573030.3671.98.camel@mni.thm.de> <50772e199f3dcc5d4eba34d17322b5aef0aa0441@webmail.yaccman.com> <20180818155733.523a3d2d@jabberwock.cb.piermont.com> Message-ID: Perry E. Metzger wrote: > > This is a pretty long posting. If you don't care to read it, the TL;DR > is that formal specification and verification is now a real > discipline, which it wasn't in the old days, and there are systems to > do it in, and it's well understood. Another example, of a somewhat different flavour, is http://lamport.azurewebsites.net/tla/amazon.html The difference being that I gather Amazon are using TLA+ more as a modelling language for distributed systems and not strictly for verifying implementations. PS. If there is a historical Lamport / Unix connection, I'm not aware of one... Tony. -- f.anthony.n.finch http://dotat.at/ protect and enlarge the conditions of liberty and social justice From Caipenghui_c at 163.com Tue Aug 21 14:55:03 2018 From: Caipenghui_c at 163.com (Caipenghui) Date: Tue, 21 Aug 2018 12:55:03 +0800 Subject: [TUHS] About Unix header files Message-ID: <88DDC574-96EA-4B3D-97A2-28157BF3B9D7@163.com> Hello everyone Hello everyone, I have a question, I looked at the source code of early Unix, found that a lot of.c files did not contain header files, so compiler compiler will not error? Caipenghui -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Tue Aug 21 16:00:19 2018 From: wkt at tuhs.org (Warren Toomey) Date: Tue, 21 Aug 2018 16:00:19 +1000 Subject: [TUHS] About Unix header files In-Reply-To: <88DDC574-96EA-4B3D-97A2-28157BF3B9D7@163.com> References: <88DDC574-96EA-4B3D-97A2-28157BF3B9D7@163.com> Message-ID: <96BFB455-917B-43C6-ADB3-C8DE96E09B22@tuhs.org> And just a note that Caipenghui is new to the list, he is from China and dmr is one of his heroes. Cheers, Warren -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ckeck at texoma.net Wed Aug 22 07:37:43 2018 From: ckeck at texoma.net (Cornelius Keck) Date: Tue, 21 Aug 2018 16:37:43 -0500 Subject: [TUHS] About Unix header files In-Reply-To: <88DDC574-96EA-4B3D-97A2-28157BF3B9D7@163.com> References: <88DDC574-96EA-4B3D-97A2-28157BF3B9D7@163.com> Message-ID: <20180821213743.4931661.91186.9539@texoma.net> An HTML attachment was scrubbed... URL: From Caipenghui_c at 163.com Wed Aug 22 14:25:26 2018 From: Caipenghui_c at 163.com (Caipenghui) Date: Wed, 22 Aug 2018 12:25:26 +0800 Subject: [TUHS] Cornelius Keck In-Reply-To: <20180821213743.4931661.91186.9539@texoma.net> References: <88DDC574-96EA-4B3D-97A2-28157BF3B9D7@163.com> <20180821213743.4931661.91186.9539@texoma.net> Message-ID: <2D648F8B-DA31-4069-8C20-8DE89EA339C7@163.com> On August 22, 2018 5:37:43 AM GMT+08:00, Cornelius Keck wrote: > Early C-compilers didn't care much about prototypes. The default return > type of a function would be an int. It was up to the code's author to > pass the right (amount, order, type). The linker didn't care about > signatures as long as the symbol resolved. > > > What one did need were struct definitions and macros, such as getchar, > putchar, min, max, abs, because they might not be provided by some > library, causing link to fail. > > > Back then one could get away with constructs creative enough to make a > modern compiler blow a gasket, and it would all run just fine, as long > as one didn't accidentally drop a bunch of bits when typecasting, and > sizeof(int) = sizeof(int*). > > > Those were interesting times. I do miss them. > > > > Gesendet von meinem BlackBerry 10-Smartphone. > > Von: Caipenghui > > Gesendet: Dienstag, 21. August 2018 00:12 > > An: tuhs at minnie.tuhs.org > > Betreff: [TUHS] About Unix header files > > > Hello everyone > > Hello everyone, I have a question, I looked at the source code of early > Unix, found that a lot of.c files did > not contain header files, so compiler compiler will not error? > > Caipenghui We miss DMR. DMR is dead, but we will not forget his contribution to humanity. We will learn a simple humorous spirit of DMR. Not only did he teach us to code, he seemed to convey a human spirit. DMR also conveys the spirit of Unix philosophy, such as kiss.do a thing, do it well, etc. Caipenghui From caipenghui_c at 163.com Wed Aug 22 22:01:42 2018 From: caipenghui_c at 163.com (cc) Date: Wed, 22 Aug 2018 20:01:42 +0800 (GMT+08:00) Subject: [TUHS] A c program problem Message-ID: <4019d825.4b05.16561830adb.Coremail.caipenghui_c@163.com> Hello everyone I had a problem compiling a piece of c code from the book. The result of running the book is 5050, but the compiler is 100. I don't know which is right, please help me to see which is wrong. Thank you very much! #include int main(void) { int i, sum = 0; i = 1; while ( i <= 100) { sum = sum + 1; i++; } printf("%d\n", sum) return 0; } | | cc | | 邮箱：caipenghui_c at 163.com | 签名由 网易邮箱大师 定制 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Caipenghui_c at 163.com Wed Aug 22 22:04:54 2018 From: Caipenghui_c at 163.com (Caipenghui) Date: Wed, 22 Aug 2018 20:04:54 +0800 Subject: [TUHS] . Message-ID: <9C284653-55E8-4AED-B754-1FBBDF82D8DE@163.com> . From mutiny.mutiny at india.com Wed Aug 22 22:24:26 2018 From: mutiny.mutiny at india.com (Donald ODona) Date: Wed, 22 Aug 2018 12:24:26 +0000 (UTC) Subject: [TUHS] A c program problem In-Reply-To: <4019d825.4b05.16561830adb.Coremail.caipenghui_c@163.com> References: <4019d825.4b05.16561830adb.Coremail.caipenghui_c@163.com> Message-ID: <1281463715.239847.1534940666012.JavaMail.tomcat@india-live-be04> At 22 Aug 2018 12:18:08 +0000 (+00:00) from cc : > Hello everyone > > I had a problem compiling a piece of c code from the book. The result of running the book is 5050, but the compiler is 100. I don't know which is right, please help me to see which is wrong. Thank you very much! > > #include > > int main(void) > { > int i, sum = 0; > i = 1; > while ( i <= 100) { > sum = sum + 1; > i++; > } > printf("%d\n", sum) > return 0; > } > > > > > | | > cc > | > | > 邮箱：caipenghui_c at 163.com > | > > 签名由 网易邮箱大师 定制 From cubexyz at gmail.com Wed Aug 22 22:54:17 2018 From: cubexyz at gmail.com (Mark Longridge) Date: Wed, 22 Aug 2018 08:54:17 -0400 Subject: [TUHS] A c program problem In-Reply-To: <1281463715.239847.1534940666012.JavaMail.tomcat@india-live-be04> References: <4019d825.4b05.16561830adb.Coremail.caipenghui_c@163.com> <1281463715.239847.1534940666012.JavaMail.tomcat@india-live-be04> Message-ID: Looks like a typographical error. if you change the line: sum = sum + 1; to sum = sum + i; then you will get 5050. Also the line with printf should have a semi-colon at the end. On 8/22/18, Donald ODona wrote: > > > At 22 Aug 2018 12:18:08 +0000 (+00:00) from cc : >> Hello everyone >> >> I had a problem compiling a piece of c code from the book. The result of >> running the book is 5050, but the compiler is 100. I don't know which is >> right, please help me to see which is wrong. Thank you very much! >> >> #include >> >> int main(void) >> { >> int i, sum = 0; >> i = 1; >> while ( i <= 100) { >> sum = sum + 1; >> i++; >> } >> printf("%d\n", sum) >> return 0; >> } >> >> >> >> >> | | >> cc >> | >> | >> 邮箱：caipenghui_c at 163.com >> | >> >> 签名由 网易邮箱大师 定制 > From perry at piermont.com Wed Aug 22 23:44:52 2018 From: perry at piermont.com (Perry E. Metzger) Date: Wed, 22 Aug 2018 09:44:52 -0400 Subject: [TUHS] About Unix header files In-Reply-To: <20180821213743.4931661.91186.9539@texoma.net> References: <88DDC574-96EA-4B3D-97A2-28157BF3B9D7@163.com> <20180821213743.4931661.91186.9539@texoma.net> Message-ID: <20180822094452.73ca043f@jabberwock.cb.piermont.com> On Tue, 21 Aug 2018 16:37:43 -0500 Cornelius Keck wrote: > Early C-compilers didn't care much about prototypes. The default > return type of a function would be an int. It was up to the code's > author to pass the right (amount, order, type). The linker didn't > care about signatures as long as the symbol resolved. To my knowledge, object file formats still don't have information about type signatures, and linkers still don't care about types. This is actually a problem. It would probably prevent a lot of errors if those things changed. Perry -- Perry E. Metzger perry at piermont.com From crossd at gmail.com Thu Aug 23 00:21:45 2018 From: crossd at gmail.com (Dan Cross) Date: Wed, 22 Aug 2018 10:21:45 -0400 Subject: [TUHS] A c program problem In-Reply-To: <4019d825.4b05.16561830adb.Coremail.caipenghui_c@163.com> References: <4019d825.4b05.16561830adb.Coremail.caipenghui_c@163.com> Message-ID: Note, TUHS probably isn't the *best* forum to ask for help with basic C programs. :-) That said, I suspect you mis-transcribed the program and that the line, `sum = sum + 1;` should be `sum = sum + i;`, or more idiomatically, `sum += i;`. Indeed, the whole program could be written: #include int main(void) { int i, sum = 0; for (i = 1; i <= 100; i++) sum += i; printf("%d\n", sum); return 0; } If you're using a C99 or later compiler, you can be slightly more succinct: #include int main(void) { int sum = 0; for (int i = 1; i <= 100; i++) sum += i; printf("%d\n", sum); return 0; } Hope that helps! - Dan C. On Wed, Aug 22, 2018 at 8:17 AM cc wrote: > Hello everyone > > I had a problem compiling a piece of c code from the book. The result of > running the book is 5050, but the compiler is 100. I don't know which is > right, please help me to see which is wrong. Thank you very much! > > #include > > int main(void) > { > int i, sum = 0; > i = 1; > while ( i <= 100) { > sum = sum + 1; > i++; > } > printf("%d\n", sum) > return 0; > } > > > > cc > 邮箱：caipenghui_c at 163.com > > > > 签名由 网易邮箱大师 定制 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From caipenghui_c at 163.com Thu Aug 23 00:26:37 2018 From: caipenghui_c at 163.com (cc) Date: Wed, 22 Aug 2018 22:26:37 +0800 (GMT+08:00) Subject: [TUHS] A c program problem In-Reply-To: References: <4019d825.4b05.16561830adb.Coremail.caipenghui_c@163.com> Message-ID: <5e35d6b8.513d.1656207b82c.Coremail.caipenghui_c@163.com> Sorry, I won't be sending it next time. Oh oh, maybe I forgot to add; . I typed the code on the book, and the result of running the book was 5050, but the compiler was 100. | | cc | | 邮箱：caipenghui_c at 163.com | 签名由 网易邮箱大师 定制 On 08/22/2018 22:21, Dan Cross wrote: Note, TUHS probably isn't the *best* forum to ask for help with basic C programs. :-) That said, I suspect you mis-transcribed the program and that the line, `sum = sum + 1;` should be `sum = sum + i;`, or more idiomatically, `sum += i;`. Indeed, the whole program could be written: #include int main(void) { int i, sum = 0; for (i = 1; i <= 100; i++) sum += i; printf("%d\n", sum); return 0; } If you're using a C99 or later compiler, you can be slightly more succinct: #include int main(void) { int sum = 0; for (int i = 1; i <= 100; i++) sum += i; printf("%d\n", sum); return 0; } Hope that helps! - Dan C. On Wed, Aug 22, 2018 at 8:17 AM cc wrote: Hello everyone I had a problem compiling a piece of c code from the book. The result of running the book is 5050, but the compiler is 100. I don't know which is right, please help me to see which is wrong. Thank you very much! #include int main(void) { int i, sum = 0; i = 1; while ( i <= 100) { sum = sum + 1; i++; } printf("%d\n", sum) return 0; } | | cc | | 邮箱：caipenghui_c at 163.com | 签名由 网易邮箱大师 定制 -------------- next part -------------- An HTML attachment was scrubbed... URL: From caipenghui_c at 163.com Thu Aug 23 00:29:06 2018 From: caipenghui_c at 163.com (cc) Date: Wed, 22 Aug 2018 22:29:06 +0800 (GMT+08:00) Subject: [TUHS] A c program problem In-Reply-To: <5e35d6b8.513d.1656207b82c.Coremail.caipenghui_c@163.com> References: <4019d825.4b05.16561830adb.Coremail.caipenghui_c@163.com> <5e35d6b8.513d.1656207b82c.Coremail.caipenghui_c@163.com> Message-ID: <4cc41edb.5155.1656209fbce.Coremail.caipenghui_c@163.com> I want to figure out if the book is right or the compiler is right. | | cc | | 邮箱：caipenghui_c at 163.com | 签名由 网易邮箱大师 定制 On 08/22/2018 22:26, cc wrote: Sorry, I won't be sending it next time. Oh oh, maybe I forgot to add; . I typed the code on the book, and the result of running the book was 5050, but the compiler was 100. | | cc | | 邮箱：caipenghui_c at 163.com | 签名由 网易邮箱大师 定制 On 08/22/2018 22:21, Dan Cross wrote: Note, TUHS probably isn't the *best* forum to ask for help with basic C programs. :-) That said, I suspect you mis-transcribed the program and that the line, `sum = sum + 1;` should be `sum = sum + i;`, or more idiomatically, `sum += i;`. Indeed, the whole program could be written: #include int main(void) { int i, sum = 0; for (i = 1; i <= 100; i++) sum += i; printf("%d\n", sum); return 0; } If you're using a C99 or later compiler, you can be slightly more succinct: #include int main(void) { int sum = 0; for (int i = 1; i <= 100; i++) sum += i; printf("%d\n", sum); return 0; } Hope that helps! - Dan C. On Wed, Aug 22, 2018 at 8:17 AM cc wrote: Hello everyone I had a problem compiling a piece of c code from the book. The result of running the book is 5050, but the compiler is 100. I don't know which is right, please help me to see which is wrong. Thank you very much! #include int main(void) { int i, sum = 0; i = 1; while ( i <= 100) { sum = sum + 1; i++; } printf("%d\n", sum) return 0; } | | cc | | 邮箱：caipenghui_c at 163.com | 签名由 网易邮箱大师 定制 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralph at inputplus.co.uk Thu Aug 23 00:32:58 2018 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Wed, 22 Aug 2018 15:32:58 +0100 Subject: [TUHS] A c program problem In-Reply-To: <4cc41edb.5155.1656209fbce.Coremail.caipenghui_c@163.com> References: <4019d825.4b05.16561830adb.Coremail.caipenghui_c@163.com> <5e35d6b8.513d.1656207b82c.Coremail.caipenghui_c@163.com> <4cc41edb.5155.1656209fbce.Coremail.caipenghui_c@163.com> Message-ID: <20180822143258.921B2200BA@orac.inputplus.co.uk> > I want to figure out if the book is right or the compiler is right. 5050 is the right answer. It's the 100th triangular number. https://en.wikipedia.org/wiki/Triangular_number Please let this off-topic thread die. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy From caipenghui_c at 163.com Thu Aug 23 00:34:48 2018 From: caipenghui_c at 163.com (cc) Date: Wed, 22 Aug 2018 22:34:48 +0800 (GMT+08:00) Subject: [TUHS] A c program problem In-Reply-To: <20180822143258.921B2200BA@orac.inputplus.co.uk> References: <4019d825.4b05.16561830adb.Coremail.caipenghui_c@163.com> <5e35d6b8.513d.1656207b82c.Coremail.caipenghui_c@163.com> <4cc41edb.5155.1656209fbce.Coremail.caipenghui_c@163.com> <20180822143258.921B2200BA@orac.inputplus.co.uk> Message-ID: <1c8dd2a4.5199.165620f3410.Coremail.caipenghui_c@163.com> Ok, That you. | | cc | | 邮箱：caipenghui_c at 163.com | 签名由 网易邮箱大师 定制 On 08/22/2018 22:32, Ralph Corderoy wrote: > I want to figure out if the book is right or the compiler is right. 5050 is the right answer. It's the 100th triangular number. https://en.wikipedia.org/wiki/Triangular_number Please let this off-topic thread die. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Thu Aug 23 01:29:40 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Wed, 22 Aug 2018 11:29:40 -0400 Subject: [TUHS] About Unix header files In-Reply-To: <20180822094452.73ca043f@jabberwock.cb.piermont.com> References: <88DDC574-96EA-4B3D-97A2-28157BF3B9D7@163.com> <20180821213743.4931661.91186.9539@texoma.net> <20180822094452.73ca043f@jabberwock.cb.piermont.com> Message-ID: On 8/22/18, Perry E. Metzger wrote: > > To my knowledge, object file formats still don't have information > about type signatures, and linkers still don't care about types. This > is actually a problem. It would probably prevent a lot of errors if > those things changed. For a linker to enforce (or warn about) type and call signature matching, it would have to know the type and call semantics of each particular language, and each particular compiler's switch options that allow the programmer to bend the language rules. Not impossible, but a difficult and cumbersome problem, particularly as language and compiler implementation semantics vary over time. C++ and other strongly-typed languages typically hack around the problem using name decoration. Not elegant, but effective. Has anyone experimented with building Unix using C++, to take advantage of strong typing? My guess is no--it would be a Herculean task likely to introduce more bugs than it would fix. -Paul W. From toby at telegraphics.com.au Thu Aug 23 01:40:18 2018 From: toby at telegraphics.com.au (Toby Thain) Date: Wed, 22 Aug 2018 11:40:18 -0400 Subject: [TUHS] A c program problem In-Reply-To: <4cc41edb.5155.1656209fbce.Coremail.caipenghui_c@163.com> References: <4019d825.4b05.16561830adb.Coremail.caipenghui_c@163.com> <5e35d6b8.513d.1656207b82c.Coremail.caipenghui_c@163.com> <4cc41edb.5155.1656209fbce.Coremail.caipenghui_c@163.com> Message-ID: <7912176e-5895-aaa3-f973-83f88b12f196@telegraphics.com.au> On 2018-08-22 10:29 AM, cc wrote: > I want to figure out if the book is right or the compiler is right. > > > cc Donald and Dan identified the issue in earlier replies. $ cc foo.c -o foo $ ./foo 5050 $ cat foo.c #include int main(void) { int i, sum = 0; i = 1; while ( i <= 100) { sum = sum + i; i++; } printf("%d\n", sum); return 0; } --Toby From perry at piermont.com Thu Aug 23 01:46:30 2018 From: perry at piermont.com (Perry E. Metzger) Date: Wed, 22 Aug 2018 11:46:30 -0400 Subject: [TUHS] About Unix header files In-Reply-To: References: <88DDC574-96EA-4B3D-97A2-28157BF3B9D7@163.com> <20180821213743.4931661.91186.9539@texoma.net> <20180822094452.73ca043f@jabberwock.cb.piermont.com> Message-ID: <20180822114630.31557ebe@jabberwock.cb.piermont.com> On Wed, 22 Aug 2018 11:29:40 -0400 Paul Winalski wrote: > On 8/22/18, Perry E. Metzger wrote: > > > > To my knowledge, object file formats still don't have information > > about type signatures, and linkers still don't care about types. > > This is actually a problem. It would probably prevent a lot of > > errors if those things changed. > > For a linker to enforce (or warn about) type and call signature > matching, it would have to know the type and call semantics of each > particular language, Not necessarily. One could produce a language-independent way of signaling what the type signatures are (perhaps with normalized language-dependent strings) and the linker could just check that they match. I've seen several languages (like OCaml) hack around the lack of this by providing an auxiliary file for a pre-link phase to check off of. It would be nicer if the linker could just handle that. And, as I noted, this would doubtless prevent a _lot_ of bugs. One could simply decorate the symbols with a (language, semi-opaque "type string") pair, and the linker could just verify that they matched without understanding semantics. > Not impossible, but a difficult and cumbersome problem, particularly > as language and compiler implementation semantics vary over time. As I noted, there are ways to get around that. > C++ and other strongly-typed languages typically hack around the > problem using name decoration. Not elegant, but effective. Name mangling for C++ is needed for another reason, too, which is that a single "name" foo might be multiple different concrete functions depending on what type it is invoked on. > Has anyone experimented with building Unix using C++, to take > advantage of strong typing? My guess is no--it would be a Herculean > task likely to introduce more bugs than it would fix. C++ doesn't have strong typing in the modern sense. It also has some small incompatibilities with C's syntax and semantics, sufficient that you can't just (say) compile the Linux kernel with a C++ compiler and have it work. Perry -- Perry E. Metzger perry at piermont.com From Caipenghui_c at 163.com Thu Aug 23 01:46:58 2018 From: Caipenghui_c at 163.com (Caipenghui) Date: Wed, 22 Aug 2018 23:46:58 +0800 Subject: [TUHS] A c program problem In-Reply-To: <7912176e-5895-aaa3-f973-83f88b12f196@telegraphics.com.au> References: <4019d825.4b05.16561830adb.Coremail.caipenghui_c@163.com> <5e35d6b8.513d.1656207b82c.Coremail.caipenghui_c@163.com> <4cc41edb.5155.1656209fbce.Coremail.caipenghui_c@163.com> <7912176e-5895-aaa3-f973-83f88b12f196@telegraphics.com.au> Message-ID: <9487ADB3-CE4F-4011-84AD-506A5EB64D11@163.com> On August 22, 2018 11:40:18 PM GMT+08:00, Toby Thain wrote: > On 2018-08-22 10:29 AM, cc wrote: > > I want to figure out if the book is right or the compiler is right. > > > > > > cc > > > Donald and Dan identified the issue in earlier replies. > > $ cc foo.c -o foo > $ ./foo > 5050 > $ cat foo.c > #include > int main(void) > { > int i, sum = 0; > i = 1; > while ( i <= 100) { > sum = sum + i; > i++; > } > printf("%d\n", sum); > return 0; > } > > --Toby Thank you very much for pointing this out, and I'm thrilled. Thank you for your kind help. From Caipenghui_c at 163.com Thu Aug 23 01:36:13 2018 From: Caipenghui_c at 163.com (Caipenghui) Date: Wed, 22 Aug 2018 23:36:13 +0800 Subject: [TUHS] About Unix header files In-Reply-To: References: <88DDC574-96EA-4B3D-97A2-28157BF3B9D7@163.com> <20180821213743.4931661.91186.9539@texoma.net> <20180822094452.73ca043f@jabberwock.cb.piermont.com> Message-ID: <70B251DD-71B3-4418-9863-99B50D08C260@163.com> On August 22, 2018 11:29:40 PM GMT+08:00, Paul Winalski < paul.winalski at gmail.com> wrote: > On 8/22/18, Perry E. Metzger < perry at piermont.com> wrote: >> >> To my knowledge, object file formats still don't have information >> about type signatures, and linkers still don't care about types. This >> is actually a problem. It would probably prevent a lot of errors if >> those things changed. > > For a linker to enforce (or warn about) type and call signature > matching, it would have to know the type and call semantics of each > particular language, and each particular compiler's switch options > that allow the programmer to bend the language rules. Not impossible, > but a difficult and cumbersome problem, particularly as language and > compiler implementation semantics vary over time. > > C++ and other strongly-typed languages typically hack around the > problem using name decoration. Not elegant, but effective. > > Has anyone experimented with building Unix using C++, to take > advantage of strong typing? My guess is no--it would be a Herculean > task likely to introduce more bugs than it would fix. > > -Paul W. Well, I agree with you that this may be achieved in the future. From g.branden.robinson at gmail.com Thu Aug 23 01:52:57 2018 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Wed, 22 Aug 2018 11:52:57 -0400 Subject: [TUHS] About Unix header files In-Reply-To: <20180822114630.31557ebe@jabberwock.cb.piermont.com> References: <88DDC574-96EA-4B3D-97A2-28157BF3B9D7@163.com> <20180821213743.4931661.91186.9539@texoma.net> <20180822094452.73ca043f@jabberwock.cb.piermont.com> <20180822114630.31557ebe@jabberwock.cb.piermont.com> Message-ID: <20180822155255.p6bxrezym2k4ygtl@crack.deadbeast.net> At 2018-08-22T11:46:30-0400, Perry E. Metzger wrote: > On Wed, 22 Aug 2018 11:29:40 -0400 Paul Winalski > wrote: > > On 8/22/18, Perry E. Metzger wrote: > > > > > > To my knowledge, object file formats still don't have information > > > about type signatures, and linkers still don't care about types. > > > This is actually a problem. It would probably prevent a lot of > > > errors if those things changed. > > > > For a linker to enforce (or warn about) type and call signature > > matching, it would have to know the type and call semantics of each > > particular language, > > Not necessarily. One could produce a language-independent way of > signaling what the type signatures are (perhaps with normalized > language-dependent strings) and the linker could just check that they > match. > > I've seen several languages (like OCaml) hack around the lack of this > by providing an auxiliary file for a pre-link phase to check off > of. It would be nicer if the linker could just handle that. My impression is that Ada's .ali (I haven't seen an official mnemonic, but "Ada Link Information" seems likely) files provide this security. -- Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From paul.winalski at gmail.com Thu Aug 23 01:56:29 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Wed, 22 Aug 2018 11:56:29 -0400 Subject: [TUHS] About Unix header files In-Reply-To: <20180822114630.31557ebe@jabberwock.cb.piermont.com> References: <88DDC574-96EA-4B3D-97A2-28157BF3B9D7@163.com> <20180821213743.4931661.91186.9539@texoma.net> <20180822094452.73ca043f@jabberwock.cb.piermont.com> <20180822114630.31557ebe@jabberwock.cb.piermont.com> Message-ID: On 8/22/18, Perry E. Metzger wrote: > > Not necessarily. One could produce a language-independent way of > signaling what the type signatures are (perhaps with normalized > language-dependent strings) and the linker could just check that they > match. True. And the debugger people have already done the design work in this area. One could probably use DWARF to pass this info to a linker. > I've seen several languages (like OCaml) hack around the lack of this > by providing an auxiliary file for a pre-link phase to check off > of. It would be nicer if the linker could just handle that. I'm pretty sure that is how VMS Ada solved the problem, too. -Paul W. From crossd at gmail.com Thu Aug 23 02:04:15 2018 From: crossd at gmail.com (Dan Cross) Date: Wed, 22 Aug 2018 12:04:15 -0400 Subject: [TUHS] About Unix header files In-Reply-To: <20180822094452.73ca043f@jabberwock.cb.piermont.com> References: <88DDC574-96EA-4B3D-97A2-28157BF3B9D7@163.com> <20180821213743.4931661.91186.9539@texoma.net> <20180822094452.73ca043f@jabberwock.cb.piermont.com> Message-ID: On Wed, Aug 22, 2018 at 9:45 AM Perry E. Metzger wrote: > On Tue, 21 Aug 2018 16:37:43 -0500 Cornelius Keck > wrote: > > Early C-compilers didn't care much about prototypes. The default > > return type of a function would be an int. It was up to the code's > > author to pass the right (amount, order, type). The linker didn't > > care about signatures as long as the symbol resolved. > > To my knowledge, object file formats still don't have information > about type signatures, and linkers still don't care about types. This > is actually a problem. It would probably prevent a lot of errors if > those things changed. > One can embed type information in existing object file formats (e.g. ELF) by placing it in dedicated sections. This is what Go does, for example. The Go linker does some type analysis for reflection, though if symbols line up it does not detect or prevent e.g. signature mismatches. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Thu Aug 23 08:00:15 2018 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Wed, 22 Aug 2018 18:00:15 -0400 Subject: [TUHS] About Unix header files Message-ID: <201808222200.w7MM0FoO025334@tahoe.cs.Dartmouth.EDU> > Has anyone experimented with building Unix using C++, to take advantage of strong typing? My guess is no--it would be a Herculean task likely to introduce more bugs than it would fix. How Unix didn't get written in C++: When Bjarne Stroustrup joined Bell Labs, he hoped to write an operating system, but he wanted to do it in an object oriented language, so he took a small detour to make an object-oriented sibling of C. That turned out to be a maelstrom from which he never escaped. Doug From fair-tuhs at netbsd.org Thu Aug 23 09:05:33 2018 From: fair-tuhs at netbsd.org (Erik E. Fair) Date: Wed, 22 Aug 2018 16:05:33 -0700 Subject: [TUHS] About Unix header files In-Reply-To: <201808222200.w7MM0FoO025334@tahoe.cs.Dartmouth.EDU> Message-ID: <28712.1534979133@cesium.clock.org> I will never forget what dmr said in response to a question about C++ at a USENIX conference long ago: "Bjarne and I have an agreement: I don't talk about C++, and he doesn't talk about 'old C'." Erik Fair From ggm at algebras.org Thu Aug 23 12:23:37 2018 From: ggm at algebras.org (George Michaelson) Date: Thu, 23 Aug 2018 12:23:37 +1000 Subject: [TUHS] About Unix header files In-Reply-To: References: <88DDC574-96EA-4B3D-97A2-28157BF3B9D7@163.com> <20180821213743.4931661.91186.9539@texoma.net> <20180822094452.73ca043f@jabberwock.cb.piermont.com> Message-ID: That Go decision feels like something which could be built upon. I think this already moving off TUHS but none the less, looking forward, the increase in strongly typed languages in use points to a desire to preserve the type semantics so that inter-language linking can maintain the promises (so to speak) If Go has gone to marking the promises around types in a useful way, I would be entirely cool if somebody smart in llvm said "oh, if you layer your language compiler onto our STL and ISA model, our intermediate code representation then ... " (I believe GHC deliberately does this, and Frege targets the JVM similarly) Smart people in small groups do huge things which have big consequence. I am not a Go person, I tried and failed for purely personal reasons. If Go takes the underlying abstract ideas and does something other people can leverage, I would be very applauding. I like that kind of outcome. -G On Thu, Aug 23, 2018 at 2:05 AM Dan Cross wrote: > > On Wed, Aug 22, 2018 at 9:45 AM Perry E. Metzger wrote: >> >> On Tue, 21 Aug 2018 16:37:43 -0500 Cornelius Keck >> wrote: >> > Early C-compilers didn't care much about prototypes. The default >> > return type of a function would be an int. It was up to the code's >> > author to pass the right (amount, order, type). The linker didn't >> > care about signatures as long as the symbol resolved. >> >> To my knowledge, object file formats still don't have information >> about type signatures, and linkers still don't care about types. This >> is actually a problem. It would probably prevent a lot of errors if >> those things changed. > > > One can embed type information in existing object file formats (e.g. ELF) by placing it in dedicated sections. This is what Go does, for example. The Go linker does some type analysis for reflection, though if symbols line up it does not detect or prevent e.g. signature mismatches. > > - Dan C. > From ron at ronnatalie.com Fri Aug 24 00:42:40 2018 From: ron at ronnatalie.com (ron at ronnatalie.com) Date: Thu, 23 Aug 2018 10:42:40 -0400 Subject: [TUHS] C++ / Kernel Message-ID: <10c401d43aef$8be34870$a3a9d950$@ronnatalie.com> > Has anyone experimented with building Unix using C++, to take > advantage of strong typing? My guess is no--it would be a Herculean task likely to introduce more bugs than it would fix. I'm not sure what "strong typing" gain you expect to find. With the exception of the void* difference, C++ isn't much more "type strong" than C. A lot of the type issues you can find on the Kernel just by turning up the compiler warnings (or use lint). The biggest issue we had was BSD didn't use void* at all. Had they converted pointers to void*, which is in implementation necessarily the same as char*, C would have done the right thing. The problem is they did what I call "Conversion by union." They would store a char* into one element of a union and read it out of another typed pointer. This works fine for a VAX where all pointers are the same format, but fails on word address machines (notably in our case the HEP where the target size is encoded in the low order bits of the pointer). Still, running around and fixing those was only a few hours work. The DevSwitch is the beginnings of an object oriented philosophy. Alas, the original UNIX used it only for mapping major dev numbers to functions. It got some later use for other things like multi filesystemsupport. The scary supportability thing in the kernel, isn't so much typing, but the failuer to "hide" implementation details of one part of the kernel from the other. From clemc at ccc.com Fri Aug 24 03:24:51 2018 From: clemc at ccc.com (Clem Cole) Date: Thu, 23 Aug 2018 13:24:51 -0400 Subject: [TUHS] C++ / Kernel In-Reply-To: <10c401d43aef$8be34870$a3a9d950$@ronnatalie.com> References: <10c401d43aef$8be34870$a3a9d950$@ronnatalie.com> Message-ID: On Thu, Aug 23, 2018 at 10:43 AM wrote: > I'm not sure what "strong typing" gain you expect to find. With the > exception of the void* difference, C++ isn't much more "type strong" than > C. > A lot of the type issues you can find on the Kernel just by turning up the > compiler warnings (or use lint). > 100% agree... > > The biggest issue we had was BSD didn't use void* at all. Had they > converted pointers to void*, which is in implementation necessarily the > same > as char*, > C would have done the right thing. The problem is they did what I call > "Conversion by union." > I just put it as 'silent architectural assumptions' in system's programming. In Henry's 10 commandments, he referred to this as assuming 'all the world is a Vax.' (today the assumption is all the world is INTEL*64). The DevSwitch is the beginnings of an object oriented philosophy. Alas, > the original UNIX used it only for mapping major dev numbers to functions. > It got some later use for other things like multi filesystem > support. > Fair enough -- again. As much as I love BSD, I'm quick to knock it (and now Linux) a few pegs for two issues in this light. At the time, adding something like the file system switch was engious and novel. It took a couple of different schemes in different UNIX kernels (Sun, Masscomp, Eight edition and later System V) and then a couple of arguments on how to do interposition to stack them to settle on the proper functions needed for the FS, but eventually we mostly have them. But that took years, we still don't have something like the Locus vproc work for the process layer, although it was added to Linux as well as BSD/Mach [Linux rejected it - see the OpenSSI.org work]. To me, if we had done the same thing with the process layer that we did to FS's we would be better off. But the reason is off course the lack of an indirection layer which object give you. > > The scary supportability thing in the kernel, isn't so much typing, but the > failuer to "hide" implementation details of one part of the kernel from the > other. > Again, I agree. But this argument screams in favor of Dykstra THE style layering (e.g. micro-kernel) approach. I always thought it was a better way to go, but in the end, people always picked pure performance over the safety that "information hiding" gives you. It's tough, I've been on both sides of this debate and have empathy for both positions. As a supplier, it is all about being as fast as possible, because the customers don't care how hard you have to work, they just want as much speed as possible (in fact the super computer folks would really rather no OS at all). So the 'less is more' monolithic / hack / architectural specific ideas make a lot of sense. But some of the things we are talking about here are ideas that aid us in the development side on making 'better' or 'cleaner' systems - ones that are more maintainable and easier to ensure are 'correct' - which often the custom will not pay for, or worse shun because it end up being a little slower. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at bitblocks.com Fri Aug 24 06:21:39 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Thu, 23 Aug 2018 13:21:39 -0700 Subject: [TUHS] C++ / Kernel In-Reply-To: <10c401d43aef$8be34870$a3a9d950$@ronnatalie.com> References: <10c401d43aef$8be34870$a3a9d950$@ronnatalie.com> Message-ID: On Aug 23, 2018, at 7:42 AM, ron at ronnatalie.com wrote: > > The biggest issue we had was BSD didn't use void* at all. Had they > converted pointers to void*, which is in implementation necessarily the same > as char*, > C would have done the right thing. The problem is they did what I call > "Conversion by union." They would store a char* into one element of a > union and read it out of another typed pointer. I haven't done much BSD kernel programming in last 15 years but this is not my recollection. BSD used caddr_t, typedefed to char*, sort of as void *. IIRC void* came in common use after BSD unix first came about. Why use a union when a cast will do? :-) The union trick is more likely to be used for esoteric things (like getting at fl.pt. bytes) or for more complex types or probably by people with lots of programming experience in pascal and not so much in C (in Pascal you *had* to use untagged variant records if you wanted to cheat!). In C, all that void* does is allow you to avoid casts in some cases. > This works fine for a VAX where all pointers are the same format, but fails > on word address machines (notably in our case the HEP where the target size > is encoded in the low order bits of the pointer). > Still, running around and fixing those was only a few hours work. > > The DevSwitch is the beginnings of an object oriented philosophy. Alas, > the original UNIX used it only for mapping major dev numbers to functions. > It got some later use for other things like multi filesystemsupport. {b,c}devsw are closer to an interface (or in C++ terminology an abstract class that contains nothing but pure virtual functions). Go got it right. I had to build something like devsw for some IOT devices in Go and it worked very well. And you don't need to manually stuff relevant functions in a struct so that {bdev,cdev,line}sw can be properly initialized as in C. Not having this feature in C meant dev switches got a bit impure (in 4.xBSD there was only a buf ptr for bdevsw and a tty ptr in cdesw). In modern BSD the cdev struct contains all sorts of cruft. So in this sense C++ got it wrong, at least initially. Code for each disk or network device would be device specific but in so far as possible we want to access devices of a specific class the same way. Classical OO would not help here. [Aside: What I would really like is if Go interfaces can be somehow turned into abstract data types by adding an algebraic specification. For example, at the source level you should be able to say don't allow read/write once device is closed. Adding this sort of assertions/axioms at the interface level can make your code less cluttered (no need to check at every point if the device is still open) and safer (in case you forget to check).] > The scary supportability thing in the kernel, isn't so much typing, but the > failuer to "hide" implementation details of one part of the kernel from the > other. Lack of modularity or more fine grained trust boundaries. Apropos this point: https://threatpost.com/researchers-blame-monolithic-linux-code-base-for-critical-vulnerabilities/136785/ In an exhaustive study of critical Linux vulnerabilities, a team of academic and government-backed researchers claim to have proven that almost all flaws could be mitigated to less than critical severity - and that 40 percent could be completely eliminated - with an OS design based on a verified microkernel. Though I tend to think the "verified" part doesn't play as strong a role as the modularization forced by microkernels. [Ties in with the formal methods thread in here and in COFF!] From ron at ronnatalie.com Fri Aug 24 08:17:06 2018 From: ron at ronnatalie.com (ron at ronnatalie.com) Date: Thu, 23 Aug 2018 18:17:06 -0400 Subject: [TUHS] C++ / Kernel In-Reply-To: References: <10c401d43aef$8be34870$a3a9d950$@ronnatalie.com> Message-ID: <151301d43b2f$07881ed0$16985c70$@ronnatalie.com> > I haven't done much BSD kernel programming in last 15 years but this is not my recollection. BSD used caddr_t, typedefed to char*, sort of as void *. IIRC void* >came in common use after BSD unix first came about. Why use a union when a cast will do? :-) The union trick is more likely to be used for esoteric things > (like getting at fl.pt. bytes) or for more complex types or probably by people with lots of programming experience in pascal and not so much in C (in Pascal >you *had* to use untagged variant records if you wanted to cheat!). In C, all that void* does is allow you to avoid casts in some cases. Your recollections are certainly wrong. I spent a lot of time tracing down why the Kernel crashed doing I/O and traced it to this and spent a while undoing it as I stated. This union was right in the middle of the buf struct: union { caddr_t b_addr; /* low order core address */ int *b_words; /* words for clearing */ struct filsys *b_filsys; /* superblocks */ struct dinode *b_dino; /* ilist */ daddr_t *b_daddr; /* indirect block */ } b_un; There were a number of other places that did the same thing. It's OFFICIALLY now in undefined behavior by the standard (though of course that didn't exist in the BSD days) , to store in one element of the union and retrieve it via another. This is one of the reasons why. This isn't the only place it occurs. Void* came out with the V7 compiler, if I recall properly. The BSD kernel looks as if it requires such a later compiler (it uses bit fields which the earlier compilers didn't support). But it doesn't matter. You are right char* (or caddr_t) would work just fine for this albeit with some explicit casting. From nevin at eviloverlord.com Fri Aug 24 08:28:44 2018 From: nevin at eviloverlord.com (Nevin Liber) Date: Thu, 23 Aug 2018 17:28:44 -0500 Subject: [TUHS] C++ / Kernel In-Reply-To: <151301d43b2f$07881ed0$16985c70$@ronnatalie.com> References: <10c401d43aef$8be34870$a3a9d950$@ronnatalie.com> <151301d43b2f$07881ed0$16985c70$@ronnatalie.com> Message-ID: On Thu, Aug 23, 2018 at 5:17 PM wrote: > This union was right in the middle of the buf struct: > > union { > caddr_t b_addr; /* low order core address */ > int *b_words; /* words for clearing */ > struct filsys *b_filsys; /* superblocks */ > struct dinode *b_dino; /* ilist */ > daddr_t *b_daddr; /* indirect block */ > } b_un; > There were a number of other places that did the same thing. It's > OFFICIALLY now in undefined behavior by the standard (though of course that > didn't exist in the BSD days) , > to store in one element of the union and retrieve it via another. It was still kinda frowned upon in K&R1: "It is the responsibility of the programmer to keep track of what type is currently stored in a union; the results are machine dependent if something is stored as one type and extracted as another." -- Nevin ":-)" Liber +1-847-691-1404 -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Aug 24 08:48:13 2018 From: clemc at ccc.com (Clem Cole) Date: Thu, 23 Aug 2018 18:48:13 -0400 Subject: [TUHS] C++ / Kernel In-Reply-To: References: <10c401d43aef$8be34870$a3a9d950$@ronnatalie.com> <151301d43b2f$07881ed0$16985c70$@ronnatalie.com> Message-ID: On Thu, Aug 23, 2018 at 6:29 PM Nevin Liber wrote: > It was still kinda frowned upon in K&R1: "It is the responsibility of the > programmer to keep track of what type is currently stored in a union; the > results are machine dependent if something is stored as one type and > extracted as another." > No. It was not frowned upon, it was widely used. The message was just just Dennis and Brian giving you fair warning. Remember K&R1 came out approx the same time as 7th edition [I saw the proofs for the book with UNIX/TS which was a little earlier, but pretty much the same kernel]. >From V7th editions buf.h (which I show a date of May 5, 1979) and Ron is correct void*, caddr_t, daddr_t, dev_t and the like; were all 7th edition-isms that BSD picked up) ... struct buf { int b_flags; /* see defines below */ struct buf *b_forw; /* headed by d_tab of conf.c */ struct buf *b_back; /* " */ struct buf *av_forw; /* position on free list, */ struct buf *av_back; /* if not BUSY*/ dev_t b_dev; /* major+minor device name */ unsigned b_bcount; /* transfer count */ union { caddr_t b_addr; /* low order core address */ int *b_words; /* words for clearing */ struct filsys *b_filsys; /* superblocks */ struct dinode *b_dino; /* ilist */ls -l buf.h daddr_t *b_daddr; /* indirect block */ } b_un; daddr_t b_blkno; /* block # on device */ char b_xmem; /* high order core address */ char b_error; /* returned after I/O */ unsigned int b_resid; /* words not transferred after error */ }; ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Fri Aug 24 09:14:13 2018 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 24 Aug 2018 01:14:13 +0200 Subject: [TUHS] C++ / Kernel In-Reply-To: <151301d43b2f$07881ed0$16985c70$@ronnatalie.com> References: <10c401d43aef$8be34870$a3a9d950$@ronnatalie.com> <151301d43b2f$07881ed0$16985c70$@ronnatalie.com> Message-ID: <20180823231413.QeahD%steffen@sdaoden.eu> ron at ronnatalie.com wrote in <151301d43b2f$07881ed0$16985c70$@ronnatalie.com>: ... |This union was right in the middle of the buf struct: | | union { | caddr_t b_addr; /* low order core address */ | int *b_words; /* words for clearing */ | struct filsys *b_filsys; /* superblocks */ | struct dinode *b_dino; /* ilist */ | daddr_t *b_daddr; /* indirect block */ |} b_un; |There were a number of other places that did the same thing. It's |OFFICIALLY now in undefined behavior by the standard (though of course that |didn't exist in the BSD days) , |to store in one element of the union and retrieve it via another. This is |one of the reasons why. Luckily "type punning" is possible. Ach, what do i know; nonetheless, i think it is a terrible direction that C goes to, now you often need memcpy() to local storage instead of a simple assignment (with a cast) in order to avoid undefined behaviour that allows compilers to do bad things. On a NetBSD list there was a link to such a story not too long ago, the resulting C standard compliant code was ridiculous, the last string of fun has been screwed out of C. Unfortunately i have not saved the message, but Christos Zoulas has been the author. Regarding "type punning" the standard C 2011 says (6.5.2.3) If the member used to read the contents of a union object is not the same as the member last used to store a value in the object, the appropriate part of the object representation of the value is reinterpreted as an object representation in the new type as described in 6.2.6 (a process sometimes called ‘‘type punning’’). This might be a trap representation. This has not changed in C 2018 (though i have only version 2017 ballot). So as long as the type sizes are identical anything should be fine. Just as you say. --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 jnc at mercury.lcs.mit.edu Fri Aug 24 09:29:36 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 23 Aug 2018 19:29:36 -0400 (EDT) Subject: [TUHS] C++ / Kernel Message-ID: <20180823232936.8F04818C088@mercury.lcs.mit.edu> > From: Ron Natalie > The BSD kernel looks as if it requires such a later compiler (it uses > bit fields which the earlier compilers didn't support). Umm, minor nit: bit fields were added to/as of 'Typesetter C', which I gather was intermediate between V6 and V7. Noel From ron at ronnatalie.com Fri Aug 24 09:42:19 2018 From: ron at ronnatalie.com (ron at ronnatalie.com) Date: Thu, 23 Aug 2018 19:42:19 -0400 Subject: [TUHS] C++ / Kernel In-Reply-To: <20180823232936.8F04818C088@mercury.lcs.mit.edu> References: <20180823232936.8F04818C088@mercury.lcs.mit.edu> Message-ID: <160c01d43b3a$ef02ff40$cd08fdc0$@ronnatalie.com> Void probably showed up their first as well It was more like modern C than the V6 compiler. -----Original Message----- From: TUHS On Behalf Of Noel Chiappa Sent: Thursday, August 23, 2018 7:30 PM To: tuhs at minnie.tuhs.org Cc: jnc at mercury.lcs.mit.edu Subject: Re: [TUHS] C++ / Kernel > From: Ron Natalie > The BSD kernel looks as if it requires such a later compiler (it uses > bit fields which the earlier compilers didn't support). Umm, minor nit: bit fields were added to/as of 'Typesetter C', which I gather was intermediate between V6 and V7. Noel From clemc at ccc.com Fri Aug 24 10:30:19 2018 From: clemc at ccc.com (Clem Cole) Date: Thu, 23 Aug 2018 20:30:19 -0400 Subject: [TUHS] C++ / Kernel In-Reply-To: <160c01d43b3a$ef02ff40$cd08fdc0$@ronnatalie.com> References: <20180823232936.8F04818C088@mercury.lcs.mit.edu> <160c01d43b3a$ef02ff40$cd08fdc0$@ronnatalie.com> Message-ID: Yep. Im pretty sure I remember void being in typesetter C also. IIRC the differences between that version of Dennis’s compiler and what was included in 7th Edition was mostly in the libraries ie stdio was first released as part of the typesetter compiler but it was still a work in progress. On Thu, Aug 23, 2018 at 7:42 PM wrote: > Void probably showed up their first as well It was more like modern C > than the V6 compiler. > > -----Original Message----- > From: TUHS On Behalf Of Noel Chiappa > Sent: Thursday, August 23, 2018 7:30 PM > To: tuhs at minnie.tuhs.org > Cc: jnc at mercury.lcs.mit.edu > Subject: Re: [TUHS] C++ / Kernel > > > From: Ron Natalie > > > The BSD kernel looks as if it requires such a later compiler (it uses > > bit fields which the earlier compilers didn't support). > > Umm, minor nit: bit fields were added to/as of 'Typesetter C', which I > gather was intermediate between V6 and V7. > > Noel > > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Fri Aug 24 11:27:30 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 23 Aug 2018 21:27:30 -0400 (EDT) Subject: [TUHS] C++ / Kernel Message-ID: <20180824012730.5945A18C088@mercury.lcs.mit.edu> > From: Clem Cole > Im pretty sure I remember void being in typesetter C also. Hmm. In the two original 'help' files I have about the changes to C (the term 'typesetter C' doesn't appear, but it's pretty clear that's what the subject is), available through here: http://gunkies.org/wiki/Typesetter_C the term 'void' does not appear (although most other stuff - e.g. unions, bit fields, typedef, yadda yadda - does). Noel From bakul at bitblocks.com Fri Aug 24 11:41:19 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Thu, 23 Aug 2018 18:41:19 -0700 Subject: [TUHS] C++ / Kernel In-Reply-To: <151301d43b2f$07881ed0$16985c70$@ronnatalie.com> References: <10c401d43aef$8be34870$a3a9d950$@ronnatalie.com> <151301d43b2f$07881ed0$16985c70$@ronnatalie.com> Message-ID: <4130AFB4-1740-46BC-AA98-F9D01549049C@bitblocks.com> > On Aug 23, 2018, at 3:17 PM, wrote: > > > >> I haven't done much BSD kernel programming in last 15 years but this is > not my recollection. BSD used caddr_t, typedefed to char*, sort of as void > *. IIRC void* >> came in common use after BSD unix first came about. Why use a union when a > cast will do? :-) The union trick is more likely to be used for esoteric > things >> (like getting at fl.pt. bytes) or for more complex types or probably by > people with lots of programming experience in pascal and not so much in C > (in Pascal >> you *had* to use untagged variant records if you wanted to cheat!). In C, > all that void* does is allow you to avoid casts in some cases. > > Your recollections are certainly wrong. I spent a lot of time tracing > down why the Kernel crashed doing I/O and traced it to this and spent a > while undoing it as I stated. > This union was right in the middle of the buf struct: > > union { > caddr_t b_addr; /* low order core address */ > int *b_words; /* words for clearing */ > struct filsys *b_filsys; /* superblocks */ > struct dinode *b_dino; /* ilist */ > daddr_t *b_daddr; /* indirect block */ > } b_un; > There were a number of other places that did the same thing. It's > OFFICIALLY now in undefined behavior by the standard (though of course that > didn't exist in the BSD days) , > to store in one element of the union and retrieve it via another. This is > one of the reasons why. Note that this is a legitimate use of union. That is, unless I misunderstood what you meant by it, there is no "conversion by union" as you call it or "cheating" as I call it or type punning. There is no put one thing in and take another thing out. Now it may be that someone misused such a union. This is easy to do as, unlike Pascal, C has no tagged variant record & it is user's responsibility to use it right. > > This isn't the only place it occurs. > > Void* came out with the V7 compiler, if I recall properly. The BSD kernel > looks as if it requires such a later compiler (it uses bit fields which the > earlier compilers didn't support). From what I recall {c,m,re}alloc() returned a char*, not a void *. I don't have K&R1 handy at the moment so can't recall if void* was mentioned in the book (if not, that could be one reason for a lack of its use). From crossd at gmail.com Fri Aug 24 11:58:43 2018 From: crossd at gmail.com (Dan Cross) Date: Thu, 23 Aug 2018 21:58:43 -0400 Subject: [TUHS] C++ / Kernel In-Reply-To: <151301d43b2f$07881ed0$16985c70$@ronnatalie.com> References: <10c401d43aef$8be34870$a3a9d950$@ronnatalie.com> <151301d43b2f$07881ed0$16985c70$@ronnatalie.com> Message-ID: On Thu, Aug 23, 2018 at 6:17 PM wrote: > [snip] > > Void* came out with the V7 compiler, if I recall properly. The BSD kernel > looks as if it requires such a later compiler (it uses bit fields which the > earlier compilers didn't support). > But it doesn't matter. You are right char* (or caddr_t) would work just > fine for this albeit with some explicit casting. > This appears to be incorrect, unfortunately. I just tested on the PDP-11/70 running 7th Edition at the Living Computer Museum (I've got an account there) and it appears that neither `cc` nor `pcc` understand `void`. Perhaps Steve Johnson can chime in on this? I suspect he'd know the history here well. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at bitblocks.com Fri Aug 24 12:05:19 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Thu, 23 Aug 2018 19:05:19 -0700 Subject: [TUHS] C++ / Kernel In-Reply-To: References: <20180823232936.8F04818C088@mercury.lcs.mit.edu> <160c01d43b3a$ef02ff40$cd08fdc0$@ronnatalie.com> Message-ID: <7A7BA7E4-8854-4744-B3B0-9C83D061FB64@bitblocks.com> In Henry Spencer's v7 sources there is a "struct void" in cmd/sh/mode.h -- may have to do Bourne's fascination with Algol68! Bitfields were available but they were not used in v7 sources. May be because v7 pcc generated slow code for bitfields access. [Gosling's emacs used bitfields extensively. I managed to compile it but it ran extremely slowly on a 5.6Mhz Fortune box. That was the main reason I didn't switch to emacs. Then Yost brought along the Rand editor and I used it until it would no longer compile on *BSDs.] > On Aug 23, 2018, at 5:30 PM, Clem Cole wrote: > > Yep. Im pretty sure I remember void being in typesetter C also. IIRC the differences between that version of Dennis’s compiler and what was included in 7th Edition was mostly in the libraries ie stdio was first released as part of the typesetter compiler but it was still a work in progress. > > On Thu, Aug 23, 2018 at 7:42 PM wrote: > Void probably showed up their first as well It was more like modern C > than the V6 compiler. > > -----Original Message----- > From: TUHS On Behalf Of Noel Chiappa > Sent: Thursday, August 23, 2018 7:30 PM > To: tuhs at minnie.tuhs.org > Cc: jnc at mercury.lcs.mit.edu > Subject: Re: [TUHS] C++ / Kernel > > > From: Ron Natalie > > > The BSD kernel looks as if it requires such a later compiler (it uses > > bit fields which the earlier compilers didn't support). > > Umm, minor nit: bit fields were added to/as of 'Typesetter C', which I > gather was intermediate between V6 and V7. > > Noel > > -- > Sent from a handheld expect more typos than usual From clemc at ccc.com Fri Aug 24 12:52:24 2018 From: clemc at ccc.com (Clem cole) Date: Thu, 23 Aug 2018 22:52:24 -0400 Subject: [TUHS] C++ / Kernel In-Reply-To: <20180824012730.5945A18C088@mercury.lcs.mit.edu> References: <20180824012730.5945A18C088@mercury.lcs.mit.edu> Message-ID: As I said I’m not sure but I thought I remember them being there. I no longer have that distribution tape so I cannot diff it. If i recall the order the three Ritchie compilers we had that supported stdio were typesetter, Unix/TS and then finally 7th Edition. I remember they we all slightly different but don’t remember what they the differences were. As Steve has previously said Dennis was constantly improving the compiler, so I suspect it was just the state of the world when those snapshots were taken. The big changes to the language were between 6th Edition and Typesetter which were done in concert if not to support Brian’s work on the troff rewrite. Plus the first draft of book was being written around then also. The book definitely predates 7th edition’s release which I date because we did not get Seventh Edition until spring 79 and Ted had xeroxgraphic copies of the book at least a year earlier, which was when we were running TS which he had brought from the Labs. Clem Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. On Aug 23, 2018, at 9:27 PM, Noel Chiappa wrote: >> From: Clem Cole > >> Im pretty sure I remember void being in typesetter C also. > > Hmm. In the two original 'help' files I have about the changes to C (the term > 'typesetter C' doesn't appear, but it's pretty clear that's what the subject > is), available through here: > > http://gunkies.org/wiki/Typesetter_C > > the term 'void' does not appear (although most other stuff - e.g. unions, bit > fields, typedef, yadda yadda - does). > > Noel From clemc at ccc.com Fri Aug 24 13:04:59 2018 From: clemc at ccc.com (Clem cole) Date: Thu, 23 Aug 2018 23:04:59 -0400 Subject: [TUHS] C++ / Kernel In-Reply-To: References: <10c401d43aef$8be34870$a3a9d950$@ronnatalie.com> <151301d43b2f$07881ed0$16985c70$@ronnatalie.com> Message-ID: <0889FBDD-A68B-4062-AF63-EBF4CAB17F8A@ccc.com> Interesting. Void is missing, not just void*? At one point void worked but the void * idiom was buggy/missing The problem I have is the compiler was changing in small ways with each version and the differences run together Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Aug 23, 2018, at 9:58 PM, Dan Cross wrote: > >> On Thu, Aug 23, 2018 at 6:17 PM wrote: >> [snip] >> >> Void* came out with the V7 compiler, if I recall properly. The BSD kernel >> looks as if it requires such a later compiler (it uses bit fields which the >> earlier compilers didn't support). >> But it doesn't matter. You are right char* (or caddr_t) would work just >> fine for this albeit with some explicit casting. > > This appears to be incorrect, unfortunately. I just tested on the PDP-11/70 running 7th Edition at the Living Computer Museum (I've got an account there) and it appears that neither `cc` nor `pcc` understand `void`. > > Perhaps Steve Johnson can chime in on this? I suspect he'd know the history here well. > > - Dan C. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Fri Aug 24 17:02:51 2018 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 24 Aug 2018 01:02:51 -0600 Subject: [TUHS] changes in C compilers Message-ID: <201808240702.w7O72pJT005068@freefriends.org> My two cents, ... > From: Clem Cole > Date: Thu, 23 Aug 2018 20:30:19 -0400 > To: ron at ronnatalie.com > Subject: Re: [TUHS] C++ / Kernel > > Yep. Im pretty sure I remember void being in typesetter C also. IIRC the > differences between that version of Dennis???s compiler and what was included > in 7th Edition was mostly in the libraries ie stdio was first released as > part of the typesetter compiler but it was still a work in progress. K&R 1 did not have void or structure assignment. Those came later, although I'm not sure when. They may have been mentioned in an appendix; my copy isn't handy to check. At what point did each struct become its own namespace? I think around the time of K&R1. > From: Clem cole > Date: Thu, 23 Aug 2018 22:52:24 -0400 > To: Noel Chiappa > Subject: Re: [TUHS] C++ / Kernel > > ... > > The big changes to the language were between 6th Edition and Typesetter > which were done in concert if not to support Brian???s work on the troff > rewrite. Plus the first draft of book was being written around then also. The troff rewrite was later, circa '81 or so. Definitely NOT in the V6/V7 timeframe. Arnold From pnr at planet.nl Fri Aug 24 17:30:36 2018 From: pnr at planet.nl (Paul Ruizendaal) Date: Fri, 24 Aug 2018 09:30:36 +0200 Subject: [TUHS] C++ / Kernel Message-ID: <5290661A-37D5-4BCF-A38F-CA8F7B947F55@planet.nl> > Perhaps Steve Johnson can chime in on this? I suspect he'd know the history > here well. The origins of void were discussed 4-7 nov 2017 on this list. From steve at quintile.net Fri Aug 24 20:03:22 2018 From: steve at quintile.net (Steve Simon) Date: Fri, 24 Aug 2018 11:03:22 +0100 Subject: [TUHS] compiler checking types In-Reply-To: References: Message-ID: <53DA0313-86AC-4A0D-BB0E-35EDA3729966@quintile.net> At the risk of being boring, Ken thompson’s portable c compiler on plan9 checks types. -Steve From pete at dunnington.plus.com Fri Aug 24 20:41:36 2018 From: pete at dunnington.plus.com (Pete Turnbull) Date: Fri, 24 Aug 2018 11:41:36 +0100 Subject: [TUHS] C++ / Kernel In-Reply-To: <4130AFB4-1740-46BC-AA98-F9D01549049C@bitblocks.com> References: <10c401d43aef$8be34870$a3a9d950$@ronnatalie.com> <151301d43b2f$07881ed0$16985c70$@ronnatalie.com> <4130AFB4-1740-46BC-AA98-F9D01549049C@bitblocks.com> Message-ID: <0b4dd231-93f5-dbf2-fe5c-42b4a3fb464d@dunnington.plus.com> On 24/08/2018 02:41, Bakul Shah wrote: >From what I recall {c,m,re}alloc() returned a char*, not a void *. > I don't have K&R1 handy at the moment so can't recall if void* was > mentioned in the book (if not, that could be one reason for a lack of > its use). Yes, K&R1 specifically states that alloc(n) returns a char* (page 97), calloc(n, sizeof(obj)) returns a pointer to whatever type you specify (page 157), and void isn't mentioned anywhere in the book that I can see. -- Pete Pete Turnbull From clemc at ccc.com Fri Aug 24 22:00:22 2018 From: clemc at ccc.com (Clem cole) Date: Fri, 24 Aug 2018 08:00:22 -0400 Subject: [TUHS] changes in C compilers In-Reply-To: <201808240702.w7O72pJT005068@freefriends.org> References: <201808240702.w7O72pJT005068@freefriends.org> Message-ID: Arnold, I caution on absolutes. Typesetter C predates V7. It was for V6 but a release of ditroff may have been after V7. - do remember something like that in the early 80s. What I do not remember the order of which compilers. The driver for writing ditroff was the Labs getting an APS5 typesetter which was in the late 70s. And (I’m less) certain here, I think Bourne once told me they used the APS5 for the V7 manual set masters because it supported more fonts. Btw. The whole reason why typesetter C had a compiler included was the v6 compiler was not insufficient (primarily missing support for stdio) but V7 was not. That said the dates and some of the ordering are fuzzy in my mind at this point. I’m trying to use other things that I have absolute dates for and trying line them up. We had V5, quickly upgraded the V6, then TS and finally V7. I left in late Spring ‘79. That order I know is right and Ted was the reason we had TS as he brought it with him in 76 / 77. (Same for the proofs for K&R1). We got typesetter C at some point I thought before Ted brought TS but that’s fuzzy. Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Aug 24, 2018, at 3:02 AM, arnold at skeeve.com wrote: > > My two cents, ... > >> From: Clem Cole >> Date: Thu, 23 Aug 2018 20:30:19 -0400 >> To: ron at ronnatalie.com >> Subject: Re: [TUHS] C++ / Kernel >> >> Yep. Im pretty sure I remember void being in typesetter C also. IIRC the >> differences between that version of Dennis???s compiler and what was included >> in 7th Edition was mostly in the libraries ie stdio was first released as >> part of the typesetter compiler but it was still a work in progress. > > K&R 1 did not have void or structure assignment. Those came later, > although I'm not sure when. They may have been mentioned in an > appendix; my copy isn't handy to check. > > At what point did each struct become its own namespace? I think > around the time of K&R1. > >> From: Clem cole >> Date: Thu, 23 Aug 2018 22:52:24 -0400 >> To: Noel Chiappa >> Subject: Re: [TUHS] C++ / Kernel >> >> ... >> >> The big changes to the language were between 6th Edition and Typesetter >> which were done in concert if not to support Brian???s work on the troff >> rewrite. Plus the first draft of book was being written around then also. > > The troff rewrite was later, circa '81 or so. Definitely NOT in the > V6/V7 timeframe. > > Arnold From ron at ronnatalie.com Fri Aug 24 22:17:52 2018 From: ron at ronnatalie.com (ron at ronnatalie.com) Date: Fri, 24 Aug 2018 08:17:52 -0400 Subject: [TUHS] C++ / Kernel In-Reply-To: <4130AFB4-1740-46BC-AA98-F9D01549049C@bitblocks.com> References: <10c401d43aef$8be34870$a3a9d950$@ronnatalie.com> <151301d43b2f$07881ed0$16985c70$@ronnatalie.com> <4130AFB4-1740-46BC-AA98-F9D01549049C@bitblocks.com> Message-ID: <1d5901d43ba4$7bc413b0$734c3b10$@ronnatalie.com> >> union { >> caddr_t b_addr; /* low order core address */ >> int *b_words; /* words for clearing */ >> struct filsys *b_filsys; /* superblocks */ >> struct dinode *b_dino; /* ilist */ >> daddr_t *b_daddr; /* indirect block */ >> } b_un; > Note that this is a legitimate use of union. That is, unless I misunderstood what you meant by it, there is no "conversion by union" as you call it or "cheating" > as I call it or type punning. There is no put one thing in and take another thing out. Now it may be that someone misused such a union. This is easy to do as, unlike Pascal, C has no tagged variant record & it is user's responsibility to use it right. It's not legitimate. It's undefined behavior in the standards and as someone has already posted, Ritchie warned about the issue at the time. It is undefined (currently) or in the past (machine dependent) behavior to store in one element of a union and retrieve it by another. For instance: int x; daddr_t* y; u.b_un.b_words = &x; y = u.b_un.b_daddr; This is syntactically correct, but the code will blow up bizarrely on machines where the int* and long* pointers are not in the same format. Now if the datatype was a void* and we did this: u.b_vp = & x; y = u.b_vp; Provided there weren't any alignment issues, this would work as the conversion to and from void* would result in the right pointer value. I can think of three different machines I've worked on that this is a problem. The Delelcor HEP was the one I got caught on because I was porting 4.2BSD to it. The Univac (er, um, Sperry) 1100 series and I think the DEC10 by derivation have the partial word (i.e., anything less than a full 36 bits) encoded in the pointers. The Crays (being word addressed machines, character types are "simulated") have distinct word and char pointers. void* has to be format the same as char* (don't get me started on this idiocy, while it worked for the PDP-11, it's an inane assumption that the basic character type is the same as the smallest addressable storage unit. THIS is one of the things that should have been fixed about the time void* was conceived). From ron at ronnatalie.com Fri Aug 24 22:21:20 2018 From: ron at ronnatalie.com (ron at ronnatalie.com) Date: Fri, 24 Aug 2018 08:21:20 -0400 Subject: [TUHS] C++ / Kernel In-Reply-To: References: <20180823232936.8F04818C088@mercury.lcs.mit.edu> <160c01d43b3a$ef02ff40$cd08fdc0$@ronnatalie.com> Message-ID: <1d8d01d43ba4$f7a3f5e0$e6ebe1a0$@ronnatalie.com> > Yep. Im pretty sure I remember void being in typesetter C also. IIRC the differences between that version of Dennis’s compiler and what was included in 7th Edition was mostly in the libraries ie stdio was first released as part of the typesetter compiler but it was still a work in progress. My biggest recollection was the beginning of flipping =+ to += (It supported both but warned you about the former), and fixing the structure elements to not be global. Lots of odd quirks in the kernel due to early C limitations. PS->integ always has a fond part of my memory. From dfawcus+lists-tuhs at employees.org Fri Aug 24 23:22:44 2018 From: dfawcus+lists-tuhs at employees.org (Derek Fawcus) Date: Fri, 24 Aug 2018 14:22:44 +0100 Subject: [TUHS] C++ / Kernel In-Reply-To: <10c401d43aef$8be34870$a3a9d950$@ronnatalie.com> References: <10c401d43aef$8be34870$a3a9d950$@ronnatalie.com> Message-ID: <20180824132244.GA2979@accordion.employees.org> On Thu, Aug 23, 2018 at 10:42:40AM -0400, ron at ronnatalie.com wrote: > > > Has anyone experimented with building Unix using C++, to take > > advantage of strong typing? My guess is no--it would be a Herculean task > likely to introduce more bugs than it would fix. I recall that there was an attempt to do this with the Linux kernel, but that it was abandoned before it was completed, this would have been pre '98. Probably pre 2.4 Kernel. I have vague memories of discussions about it on the (kernel) mailing list at the time, and that it was the original cause of the 'asmlinkage' annotation on the C level syscalls - basically to turn off C++ name mangling for when the assembler syscall table referenced the C routines. DF From jaapna at xs4all.nl Fri Aug 24 23:50:02 2018 From: jaapna at xs4all.nl (Jaap Akkerhuis) Date: Fri, 24 Aug 2018 15:50:02 +0200 Subject: [TUHS] changes in C compilers (Typesetter C) In-Reply-To: References: <201808240702.w7O72pJT005068@freefriends.org> Message-ID: I'm not sure who did, but I've been told that when troff was rewritten from assembler to C, the compiler needed some rework and thus typesetter C was born. jaap -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: Message signed with OpenPGP URL: From crossd at gmail.com Sat Aug 25 00:01:26 2018 From: crossd at gmail.com (Dan Cross) Date: Fri, 24 Aug 2018 10:01:26 -0400 Subject: [TUHS] C++ / Kernel In-Reply-To: <0889FBDD-A68B-4062-AF63-EBF4CAB17F8A@ccc.com> References: <10c401d43aef$8be34870$a3a9d950$@ronnatalie.com> <151301d43b2f$07881ed0$16985c70$@ronnatalie.com> <0889FBDD-A68B-4062-AF63-EBF4CAB17F8A@ccc.com> Message-ID: On Thu, Aug 23, 2018 at 11:05 PM Clem cole wrote: > Interesting. Void is missing, not just void*? At one point void worked but > the void * idiom was buggy/missing > Correct. Neither cc nor pcc on 7th edition will accept: void sideeffect() { printf("Hi\n"); } As far as I can tell, both are treating `void` in this short program as an identifier. The string "void" doesn't appear in the sources for either compiler. The problem I have is the compiler was changing in small ways with each > version and the differences run together > It's my subjective impression, based largely on what I read here on TUHS, that there was quite a lot of activity and cross-pollination in and out of Bell Labs at the time, so I'm not surprised that the details here are fuzzy. - Dan C. Sent from my PDP-7 Running UNIX V0 expect things to be almost but not > quite. > > On Aug 23, 2018, at 9:58 PM, Dan Cross wrote: > > On Thu, Aug 23, 2018 at 6:17 PM wrote: > >> [snip] >> >> Void* came out with the V7 compiler, if I recall properly. The BSD >> kernel >> looks as if it requires such a later compiler (it uses bit fields which >> the >> earlier compilers didn't support). >> But it doesn't matter. You are right char* (or caddr_t) would work just >> fine for this albeit with some explicit casting. >> > > This appears to be incorrect, unfortunately. I just tested on the > PDP-11/70 running 7th Edition at the Living Computer Museum (I've got an > account there) and it appears that neither `cc` nor `pcc` understand `void`. > > Perhaps Steve Johnson can chime in on this? I suspect he'd know the > history here well. > > - Dan C. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Sat Aug 25 00:13:48 2018 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 24 Aug 2018 16:13:48 +0200 Subject: [TUHS] C++ / Kernel In-Reply-To: <20180823231413.QeahD%steffen@sdaoden.eu> References: <10c401d43aef$8be34870$a3a9d950$@ronnatalie.com> <151301d43b2f$07881ed0$16985c70$@ronnatalie.com> <20180823231413.QeahD%steffen@sdaoden.eu> Message-ID: <20180824141348.1NLUE%steffen@sdaoden.eu> Steffen Nurpmeso wrote in <20180823231413.QeahD%steffen at sdaoden.eu>: |ron at ronnatalie.com wrote in <151301d43b2f$07881ed0$16985c70$@ronnatalie.\ |com>: ... ||This union was right in the middle of the buf struct: ... || || union { || caddr_t b_addr; /* low order core address */ || int *b_words; /* words for clearing */ || struct filsys *b_filsys; /* superblocks */ || struct dinode *b_dino; /* ilist */ || daddr_t *b_daddr; /* indirect block */ ||} b_un; ||There were a number of other places that did the same thing. It's ||OFFICIALLY now in undefined behavior by the standard (though of course \ ||that ||didn't exist in the BSD days) , ||to store in one element of the union and retrieve it via another. \ || This is ||one of the reasons why. | |Luckily "type punning" is possible. Ach, what do i know; |nonetheless, i think it is a terrible direction that C goes to, |now you often need memcpy() to local storage instead of a simple |assignment (with a cast) in order to avoid undefined behaviour |that allows compilers to do bad things. On a NetBSD list there |was a link to such a story not too long ago, the resulting |C standard compliant code was ridiculous, the last string of fun |has been screwed out of C. Unfortunately i have not saved the |message, but Christos Zoulas has been the author. I have found the link in the history of my browser, the story was http://pzemtsov.github.io/2016/11/06/bug-story-alignment-on-x86.html --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From ron at ronnatalie.com Sat Aug 25 00:32:05 2018 From: ron at ronnatalie.com (ron at ronnatalie.com) Date: Fri, 24 Aug 2018 10:32:05 -0400 Subject: [TUHS] C++ / Kernel In-Reply-To: <20180824141348.1NLUE%steffen@sdaoden.eu> References: <10c401d43aef$8be34870$a3a9d950$@ronnatalie.com> <151301d43b2f$07881ed0$16985c70$@ronnatalie.com> <20180823231413.QeahD%steffen@sdaoden.eu> <20180824141348.1NLUE%steffen@sdaoden.eu> Message-ID: <1f6201d43bb7$3b9ebde0$b2dc39a0$@ronnatalie.com> That's a different issue (as I alluded to in my post). Alignment on machines is a different problem. Type "punning" isn't the problem, the compiler is propely converting one pointer type to another but the operand is not correctly aligned. In the case I'm referring to, the Univac and the HEP encode partial word sizes in the pointer. If you take the literal bits from one pointer to another (as if you stored it in a union), then you end up referring to the wrong sized operand in the subsequent operation. Had you converted it to void* or explicitly forced a conversion wih the cast, the compiler would have taken care of converting the pointer for you. It's very odd when you find the machine storing the WRONG SIZE operand from the pointer type in use. As I said, it wasn't hard to fix (just grep for all the afflicted unions), but it took a bit of long kernel debug sessions to figure out what was happening. > -----Original Message----- > From: Steffen Nurpmeso > I have found the link in the history of my browser, the story was > > http://pzemtsov.github.io/2016/11/06/bug-story-alignment-on-x86.html > From clemc at ccc.com Sat Aug 25 00:53:17 2018 From: clemc at ccc.com (Clem Cole) Date: Fri, 24 Aug 2018 10:53:17 -0400 Subject: [TUHS] Details and Dates (was C++ / Kernel) Message-ID: On Fri, Aug 24, 2018 at 10:02 AM Dan Cross wrote: > It's my subjective impression, based largely on what I read here on TUHS, > that there was quite a lot of activity and cross-pollination in and out of > Bell Labs at the time, so I'm not surprised that the details here are fuzzy. > Amen - The Ritchie compiler in particular, as well as the Research Kernel and BSD releases are examples a continuous development and express specific points in time. The *people and thus knowledge were fluid* (*a.k.a.* 'open source ;-) and features within the system followed the people. The reasons, order and local politics for many things are sometimes forgotten. Different actions feed back and forth and things get cloudy in the history. For instance, while people give BSD credit for the Unix networking because it was widely released with BSD 4.2 and 4.3 as the vehicle, it was actually BBN did the original IP and TCP stack that Eric Cooper added to 4.1 and Joy would eventually create sockets in 4.1A. All of MIT with ChaosNet, UofI and Rand's work on the ArpaNet NCP predates that work and was used by BBN -- as did the 3Com UNET code for V7, much less things like Rashid's Accent work, Mike Malcom and Cheridon's Thoth and later V Kernel. This is why I try to use other information that we can precisely date, as well as constants like trying code on old V7 releases like Dan just did. To me 'other information' is like when some of us matriculated at which schools or moved jobs, *i.e.* when Ted show up at CMU for his original OYOC year, Noel's time in Tech Sq, me at CMU or UCB, the summer the V6 patch tape 'accidentally' found its way to the Arpanet community can be dated by Ken's trip to California/visit to see Chesson who was finishing up at UofI ; or big outside actions like the need to support to big unmovable (and thus otherwise datable) items such as the APS5 or addition of the Vax VM support at UCB , dvk and my going on strike to force CMU to get a commercial Unix license summer of '78, when UCB got its own C70 IMP instead of the VDHI to LBL for Ing70; *etc* . Dates of different USENIX conferences, which were were a lot of ideas (and code) moved back and forth. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From web at loomcom.com Sat Aug 25 01:13:36 2018 From: web at loomcom.com (Seth Morabito) Date: Fri, 24 Aug 2018 08:13:36 -0700 Subject: [TUHS] Research UNIX on the AT&T 3B2? Message-ID: <1535123616.1824656.1485063544.08BED1A8@webmail.messagingengine.com> After the past several years of focusing on 3B2 preservation and emulation, I've begun to wonder whether 3B2 hardware was used very much inside of Bell Labs. Has anyone ever heard whether Research UNIX was ever ported to the WE32100? I've certainly never seen anything that would suggest it was, but I'd love to be proven wrong. -Seth -- Seth Morabito Poulsbo, WA web at loomcom.com From ches at cheswick.com Sat Aug 25 01:23:40 2018 From: ches at cheswick.com (William Cheswick) Date: Fri, 24 Aug 2018 11:23:40 -0400 Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: <1535123616.1824656.1485063544.08BED1A8@webmail.messagingengine.com> References: <1535123616.1824656.1485063544.08BED1A8@webmail.messagingengine.com> Message-ID: <24449BF9-646A-4E35-9898-AEFC2560555C@cheswick.com> I never saw it. I believe the answer is no. Sent from my iPhone > On Aug 24, 2018, at 11:13 AM, Seth Morabito wrote: > > After the past several years of focusing on 3B2 preservation and emulation, I've begun to wonder whether 3B2 hardware was used very much inside of Bell Labs. Has anyone ever heard whether Research UNIX was ever ported to the WE32100? I've certainly never seen anything that would suggest it was, but I'd love to be proven wrong. > > -Seth > -- > Seth Morabito > Poulsbo, WA > web at loomcom.com From clemc at ccc.com Sat Aug 25 02:06:22 2018 From: clemc at ccc.com (Clem Cole) Date: Fri, 24 Aug 2018 12:06:22 -0400 Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: <1535123616.1824656.1485063544.08BED1A8@webmail.messagingengine.com> References: <1535123616.1824656.1485063544.08BED1A8@webmail.messagingengine.com> Message-ID: On Fri, Aug 24, 2018 at 11:13 AM Seth Morabito wrote: > ... > I've begun to wonder whether 3B2 hardware was used very much inside of > Bell Labs. > I'd be curious to hear of people that actually used it. AT&T forced you to buy one with SVR3 as the porting base (I'd have never had bought the one we had a Stellar otherwise). The only time I ever knew anyone run one, was to check to see the behavior of some code/validation testing of RFS *etc*... The HW as pretty slow/inflexible compared to 68020/68030 which came out around the same time, so it was just not interesting - *i.e.* 'JAWS' - Just another work station' and it did not have a display. IIRC, it was a server and pretty inflexible in the I/O subsystem for that use. Sun would quickly produce the first Sparcs, which as Larry has pointed out, kicked butt and were cheaper . The MIPS chip would emerge with lots of designs, and for that matter the 040 and the 386 would appear soon their after , too. I've always felt that the 3Bx series was an example of fighting the previous war; other than 3B4000 (which had high reliability but other issues in practice to use it), there was never anything that made them special - compared to everyone else. The only 'successful' product that I can remember that used the WE32100 was the second version (*a.k.a.* product version) of the Blit (Bart's first version was 68000 IIRC). Does anyone know of another product? I think I was told the 5ESS changed the SLICs design from the original 68000 design to WE32100 but I was no longer associated with anyone working on it by then, so I don't know. Dennis once remarked to a couple of us that the WE32100 was an example of AT&T wanting to make sure it had its own recipe to make processors, but it was not clear it was worth it. BTW: around the same time both AT&T and HP were making their own DRAM too. It was common thinking in management at tech companies - telling folks that they needed to be 'vertically integrated.' But in the case of both HP and AT&T there internally produced DRAM chips cost 2-3 times what the merchant market cost; so besides the investment in the fab (which was huge) it was a pretty expensive insurance policy. That said, this was also the end times for the idea of the 'second source.' Chip manufacturers would be required to license their designs to some one else (for instance AMD was originally Intel's second source). I think HP was using a second source license for their memory, but IIRC AT&T had developed its own because they had higher reliability standards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Aug 25 02:46:46 2018 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 24 Aug 2018 09:46:46 -0700 Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: References: <1535123616.1824656.1485063544.08BED1A8@webmail.messagingengine.com> Message-ID: <20180824164646.GH25694@mcvoy.com> On Fri, Aug 24, 2018 at 12:06:22PM -0400, Clem Cole wrote: > IIRC, it was a server > and pretty inflexible in the I/O subsystem for that use. > Sun would quickly produce the first Sparcs, which as Larry has pointed out, > kicked butt and were cheaper I dunno that they kicked butt, my memory is we were all playing leapfrog. People remember the alpha with a lot of revisionist history, talking about fast it was. I was actually measuring performance of all the CPUs at that time and the Alpha I had wasn't anything to write home about. SPARC was sort of like that too, it was better but it was really really rare to have a chip that was 2x faster than its peers, if that happened it was usually the introduction of one CPU generation compared to the tail of another CPUs generation. > The only 'successful' product that I can remember that used the WE32100 > was the second version (*a.k.a.* product version) of the Blit (Bart's first version > was 68000 IIRC). Ah, the BLIT. Pretty sure Wisconsin's CS department had the first generation (aren't those the ones that caught on fire?). I *loved* those terminals, so much nicer than a single screen. BTW, I had Greg Chesson here for a pig roast once, and he brought Bart. I've got pics somewhere if anyone cares. --lm From steffen at sdaoden.eu Sat Aug 25 02:59:38 2018 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 24 Aug 2018 18:59:38 +0200 Subject: [TUHS] C++ / Kernel In-Reply-To: <20180824132244.GA2979@accordion.employees.org> References: <10c401d43aef$8be34870$a3a9d950$@ronnatalie.com> <20180824132244.GA2979@accordion.employees.org> Message-ID: <20180824165938.V2naG%steffen@sdaoden.eu> Derek Fawcus wrote in <20180824132244.GA2979 at accordion.employees.org>: |On Thu, Aug 23, 2018 at 10:42:40AM -0400, ron at ronnatalie.com wrote: |> |>> Has anyone experimented with building Unix using C++, to take |>> advantage of strong typing? My guess is no--it would be a Herculean \ |>> task |> likely to introduce more bugs than it would fix. | |I recall that there was an attempt to do this with the Linux kernel, |but that it was abandoned before it was completed, this would have |been pre '98. Probably pre 2.4 Kernel. | |I have vague memories of discussions about it on the (kernel) mailing |list at the time, and that it was the original cause of the 'asmlinkage' |annotation on the C level syscalls - basically to turn off C++ name |mangling for when the assembler syscall table referenced the C routines. Also the often seen C paradigm of using "enum bla" in prototypes results in C++ compilation warnings/errors if the enum is actually used to define flags rather than a true enumeration, and there are not "bit enumerations" which would accomplish that. So you need to use an integer for the prototype and have lost all checking capabilities with a glance. I have never understood this deficiency. --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 nobozo at gmail.com Sat Aug 25 03:54:41 2018 From: nobozo at gmail.com (Jon Forrest) Date: Fri, 24 Aug 2018 10:54:41 -0700 Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: <20180824164646.GH25694@mcvoy.com> References: <1535123616.1824656.1485063544.08BED1A8@webmail.messagingengine.com> <20180824164646.GH25694@mcvoy.com> Message-ID: On 8/24/2018 9:46 AM, Larry McVoy wrote: > People remember the alpha with a lot of revisionist history, talking > about fast it was. I was actually measuring performance of all the > CPUs at that time and the Alpha I had wasn't anything to write home > about. When the alpha first came out there were 3 implementations, soon followed by more. I wonder which one you measured. (You probably don't remember this but you once came to my office at UCB to talk to my officemate Carl Staelin back when I had one of the first alphas to be released by DEC.) Jon From steffen at sdaoden.eu Sat Aug 25 04:15:22 2018 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 24 Aug 2018 20:15:22 +0200 Subject: [TUHS] C++ / Kernel In-Reply-To: <1f6201d43bb7$3b9ebde0$b2dc39a0$@ronnatalie.com> References: <10c401d43aef$8be34870$a3a9d950$@ronnatalie.com> <151301d43b2f$07881ed0$16985c70$@ronnatalie.com> <20180823231413.QeahD%steffen@sdaoden.eu> <20180824141348.1NLUE%steffen@sdaoden.eu> <1f6201d43bb7$3b9ebde0$b2dc39a0$@ronnatalie.com> Message-ID: <20180824181522.2nrUS%steffen@sdaoden.eu> ron at ronnatalie.com wrote in <1f6201d43bb7$3b9ebde0$b2dc39a0$@ronnatalie.com>: |That's a different issue (as I alluded to in my post). Alignment on |machines is a different problem. Type "punning" isn't the problem, the |compiler is propely converting one |pointer type to another but the operand is not correctly aligned. The story told here is more about how the peculiarities of a standard text and compiler developers come together to something very unfortunate. |In the case I'm referring to, the Univac and the HEP encode partial word |sizes in the pointer. If you take the literal bits from one pointer to |another (as if you stored it in a union), |then you end up referring to the wrong sized operand in the subsequent |operation. Had you converted it to void* or explicitly forced a Ah, i am sorry. Indeed i misunderstood that. |conversion wih the cast, the compiler |would have taken care of converting the pointer for you. Though even more unfortunate i am, since this union trick is often the only way to be able to do proper a.k.a. allowed type conversion, where the standard text forbids something quick and easy, casting of or to function pointers in C++ comes to mind spontaneously. (The linked story also tries to go via (char*) to a desired type, but the compiler seems to be too neat. And even if this is a bug, of course...) |It's very odd when you find the machine storing the WRONG SIZE operand from |the pointer type in use. |As I said, it wasn't hard to fix (just grep for all the afflicted unions), |but it took a bit of long kernel debug sessions to figure out what was |happening. | |> -----Original Message----- |> From: Steffen Nurpmeso |> I have found the link in the history of my browser, the story was |> |> http://pzemtsov.github.io/2016/11/06/bug-story-alignment-on-x86.html --End of <1f6201d43bb7$3b9ebde0$b2dc39a0$@ronnatalie.com> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From bakul at bitblocks.com Sat Aug 25 04:36:34 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Fri, 24 Aug 2018 11:36:34 -0700 Subject: [TUHS] C++ / Kernel In-Reply-To: <1d5901d43ba4$7bc413b0$734c3b10$@ronnatalie.com> References: <10c401d43aef$8be34870$a3a9d950$@ronnatalie.com> <151301d43b2f$07881ed0$16985c70$@ronnatalie.com> <4130AFB4-1740-46BC-AA98-F9D01549049C@bitblocks.com> <1d5901d43ba4$7bc413b0$734c3b10$@ronnatalie.com> Message-ID: <98A5731F-11D3-4D55-B679-8DDF9E4EFFBC@bitblocks.com> On Aug 24, 2018, at 5:17 AM, ron at ronnatalie.com wrote: > > For instance: > int x; > daddr_t* y; > > u.b_un.b_words = &x; > y = u.b_un.b_daddr; One would typically *not* do this. > > This is syntactically correct, but the code will blow up bizarrely on > machines where the int* and long* pointers are not in the same format. > Now if the datatype was a void* and we did this: > > u.b_vp = & x; > y = u.b_vp; > > Provided there weren't any alignment issues, this would work as the > conversion to and from void* would result in the right pointer value. For example, given union { caddr_t b_addr; /* low order core address */ int *b_words; /* words for clearing */ struct filsys *b_filsys; /* superblocks */ struct dinode *b_dino; /* ilist */ daddr_t *b_daddr; /* indirect block */ } b_un; You'd use it something like this: struct b_un x, y, z, *w; struct filesys fs; daddr_t d; ... x.b_words = &b; y.b_filsys = &fs; z.b_addr = &d; w = &x; These come about because in different contexts different ptrs may be used but one would not do any type conversion. Said another way, if you replaced the union with a struct, type punning code would fall apart but legit code would continue working (except in the case where the *size* of the object is significant). From ron at ronnatalie.com Sat Aug 25 04:38:14 2018 From: ron at ronnatalie.com (ron at ronnatalie.com) Date: Fri, 24 Aug 2018 14:38:14 -0400 Subject: [TUHS] C++ / Kernel In-Reply-To: <98A5731F-11D3-4D55-B679-8DDF9E4EFFBC@bitblocks.com> References: <10c401d43aef$8be34870$a3a9d950$@ronnatalie.com> <151301d43b2f$07881ed0$16985c70$@ronnatalie.com> <4130AFB4-1740-46BC-AA98-F9D01549049C@bitblocks.com> <1d5901d43ba4$7bc413b0$734c3b10$@ronnatalie.com> <98A5731F-11D3-4D55-B679-8DDF9E4EFFBC@bitblocks.com> Message-ID: <250601d43bd9$9ed61800$dc824800$@ronnatalie.com> > > > > For instance: > > int x; > > daddr_t* y; > > > > u.b_un.b_words = &x; > > y = u.b_un.b_daddr; > > One would typically *not* do this. One would think not, but the BSD kernel did. That's the whole point. From jnc at mercury.lcs.mit.edu Sat Aug 25 06:23:25 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 24 Aug 2018 16:23:25 -0400 (EDT) Subject: [TUHS] changes in C compilers (Typesetter C) Message-ID: <20180824202325.8E0ED18C084@mercury.lcs.mit.edu> > From: Jaap Akkerhuis > I've been told that when troff was rewritten from assembler to C Was TROFF ever in assembler? I'm pretty sure NROFF was, as of V6; the source is not in the V6 distro, and the binary is stripped, but looking at the object code, it doesn't look like C compiler output. As of the PWB system that MIT had (or maybe it was TS - how can one tell the difference, does anyone know?), NROFF and TROFF were generated from the same C source (which I have, if anyone wants to look at it). > the compiler needed some rework and thus typesetter C was born. I heard he needed features (e.g. longs and unsigned), but... looking at the N/TROFF source, there are _no_ 'unsigned's, and only a handful of 'long' variables! There also don't seem to be any bit fields, typedefs, etc. There is _one_ initialized structure (array of structures, to be precise). (Although there are a lot of places were an int is initialized with a double-character constant!) About the only features in "C Changes" that it uses are i) register types on arguments, and the 'static' storage class. So now I'm wondering about that meme... Noel From arnold at skeeve.com Sun Aug 26 04:30:27 2018 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sat, 25 Aug 2018 12:30:27 -0600 Subject: [TUHS] changes in C compilers In-Reply-To: References: <201808240702.w7O72pJT005068@freefriends.org> Message-ID: <201808251830.w7PIURLX024379@freefriends.org> The APS work started in the summer of 1979. See http://www.eprg.org/papers/202paper.pdf and see some of the other stuff at http://www.cs.princeton.edu/~bwk/202/index.html. I think that's after V7 was released. Arnold Clem cole wrote: > Arnold, I caution on absolutes. Typesetter C predates V7. It was for V6 but a release of ditroff may have been after V7. - do remember something like that in the early 80s. What I do not remember the order of which compilers. The driver for writing ditroff was the Labs getting an APS5 typesetter which was in the late 70s. > > And (I???m less) certain here, I think Bourne once told me they used the APS5 for the V7 manual set masters because it supported more fonts. > > Btw. The whole reason why typesetter C had a compiler included was the v6 compiler was not insufficient (primarily missing support for stdio) but V7 was not. > > That said the dates and some of the ordering are fuzzy in my mind at this point. I???m trying to use other things that I have absolute dates for and trying line them up. > > We had V5, quickly upgraded the V6, then TS and finally V7. I left in late Spring ???79. That order I know is right and Ted was the reason we had TS as he brought it with him in 76 / 77. (Same for the proofs for K&R1). > > We got typesetter C at some point I thought before Ted brought TS but that???s fuzzy. > > Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > > > On Aug 24, 2018, at 3:02 AM, arnold at skeeve.com wrote: > > > > My two cents, ... > > > >> From: Clem Cole > >> Date: Thu, 23 Aug 2018 20:30:19 -0400 > >> To: ron at ronnatalie.com > >> Subject: Re: [TUHS] C++ / Kernel > >> > >> Yep. Im pretty sure I remember void being in typesetter C also. IIRC the > >> differences between that version of Dennis???s compiler and what was included > >> in 7th Edition was mostly in the libraries ie stdio was first released as > >> part of the typesetter compiler but it was still a work in progress. > > > > K&R 1 did not have void or structure assignment. Those came later, > > although I'm not sure when. They may have been mentioned in an > > appendix; my copy isn't handy to check. > > > > At what point did each struct become its own namespace? I think > > around the time of K&R1. > > > >> From: Clem cole > >> Date: Thu, 23 Aug 2018 22:52:24 -0400 > >> To: Noel Chiappa > >> Subject: Re: [TUHS] C++ / Kernel > >> > >> ... > >> > >> The big changes to the language were between 6th Edition and Typesetter > >> which were done in concert if not to support Brian???s work on the troff > >> rewrite. Plus the first draft of book was being written around then also. > > > > The troff rewrite was later, circa '81 or so. Definitely NOT in the > > V6/V7 timeframe. > > > > Arnold From steve.mynott at gmail.com Sun Aug 26 04:45:51 2018 From: steve.mynott at gmail.com (Steve Mynott) Date: Sat, 25 Aug 2018 19:45:51 +0100 Subject: [TUHS] hal.gnu.ai.mit.edu Message-ID: Back in the early 90s before the FSF withdrew the service due to misuse it was possible to write off to them to get a free shell account on "hal" as I did. I recall having to telnet through one of three gateway systems so assume it was on its own little subnet. But I can't remember what sort of system (hardware or OS) it was now however and wondered if anyone else did? -- Steve Mynott cv25519/ECF8B611205B447E091246AF959E3D6197190DD5 -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve.mynott at gmail.com Sun Aug 26 04:59:01 2018 From: steve.mynott at gmail.com (Steve Mynott) Date: Sat, 25 Aug 2018 19:59:01 +0100 Subject: [TUHS] hal.gnu.ai.mit.edu In-Reply-To: References: Message-ID: On Sat, 25 Aug 2018 at 19:45, Steve Mynott wrote: > > Back in the early 90s before the FSF withdrew the service due to misuse it > was possible to write off to them to get a free shell account on "hal" as I > did. I recall having to telnet through one of three gateway systems so > assume it was on its own little subnet. > > But I can't remember what sort of system (hardware or OS) it was now > however and wondered if anyone else did? > https://ftp.gnu.org/old-gnu/Manuals/finger-1.37/html_node/finger_17.html mentions "spiff" (which rings a bell as one of the systems) as a "Sony" which must have been a NEWS-OS (BSD) system. -- Steve Mynott cv25519/ECF8B611205B447E091246AF959E3D6197190DD5 -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun Aug 26 05:58:35 2018 From: clemc at ccc.com (Clem Cole) Date: Sat, 25 Aug 2018 15:58:35 -0400 Subject: [TUHS] changes in C compilers In-Reply-To: <201808251830.w7PIURLX024379@freefriends.org> References: <201808240702.w7O72pJT005068@freefriends.org> <201808251830.w7PIURLX024379@freefriends.org> Message-ID: On Sat, Aug 25, 2018 at 2:38 PM wrote: > The APS work started in the summer of 1979. See > http://www.eprg.org/papers/202paper.pdf > and see some of the other stuff at > http://www.cs.princeton.edu/~bwk/202/index.html. > > I think that's after V7 was released. > Ok, so that was clearly the first ditroff. Typesetter C *must have been the original troff release* which was separate from V6; but I don't remember what all was in the release. Looking at the v6 distribution tape I have, the assembler versions of roff and nroff was there; but not troff. V7 clearly shows the original troff in the sources. The order I remember is this ... V5, V6, Patches, Typesetter C, TS, V7 ... although TS and Typesetter might be switched but I know we got Typesetter C before we got V7. Ted brought TS to us (in EE) and I thought that had the new compiler. CS got TS from us in EE. But somebody at CMU had wanted troff because we had the XGP in CS that we drive with Scribe (I want to say that was EE but I don't remember who was involved). So I have memory of somebody hacking on the compiler at some point. The POR (which if ever came to bear at CMU was after I left) was some type of hacking on troff to support the XGP. Given the time Aharon points out, it might have been direct support it or it might have been something like vcat - I was not involved. Klone might remember more of that. Clearly from the time, ditroff did not yet exist. The more I think about it, Brian K actually might know some of the story. Scribe was Brian Reid's PhD Thesis and Brian K was on Reid's committee at the time and I'm guessing could somehow have been mixed up. FWIW: Compiler hacking at CMU stands out in my mind because of the 11/40e had CSAV/CRET instructions. The CS versions of the compilers generated code using that, because they had 11/40e with CMU WCS options. The rest of us in EE, BioMed, Mellon Institute etc were running on 11/34's or 11/34A which could not handle those binaries (no WCS). So I personally spent time tracking the CS versions of the compiler and bringing things to EE, trying to keep thing clean. That was one of my jobs at the time. That's fairly sure of the order, because we had Typesetter C at CMU in the Summer '78 when were we negotiating the 'university' commercial V7 license with Al Arms [which I was personally mixed up -- the finally ruling/agreement was license one system as a commercial system at the $20K fee and a university, could then use UNIX for back office and commercial style uses like Industry. Al did not require the $5K second CPU stuff from the Universities, if they got a single $20K license; everyone was happy - details off list or another thread if you want them; although I will say CMU was first in early '79, followed by Case in late 1979]. So again, I try to date by things I know are fixed in time and then work from there. As Dan points out the cross pollination was high in those days and it was not just from the labs to the Universities. For instance, Ted took fsck back to Summit & MH, as well as a number of other tools (although I think that one had the longest reach). Noel has mentioned similar stories from MIT. Chesson brought all the networking stuff from UoI and we saw some of it in datakit (an earlier version of his mpx code for V7 he did as a grad student). You get the idea.... Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpl.jpl at gmail.com Sun Aug 26 08:19:05 2018 From: jpl.jpl at gmail.com (John P. Linderman) Date: Sat, 25 Aug 2018 18:19:05 -0400 Subject: [TUHS] changes in C compilers In-Reply-To: References: <201808240702.w7O72pJT005068@freefriends.org> <201808251830.w7PIURLX024379@freefriends.org> Message-ID: *Ted took fsck back to Summit & MH* I got my introduction to UNIX in '73 or '74, when the group running the 11/45 in Piscataway found out I came into work before 6am. UNIX was so unstable back then that it had to be rebooted every day, to contain file system corruption. A 6 am reboot went pretty much unnoticed. I could swear we ran something very like fsck after each reboot. In particular, I recall the **gok** diagnostic when the type of an inode wasn't anything recognizable. Whatever we ran, I'm sure it continued to evolve. On Sat, Aug 25, 2018 at 3:58 PM, Clem Cole wrote: > > > On Sat, Aug 25, 2018 at 2:38 PM wrote: > >> The APS work started in the summer of 1979. See >> http://www.eprg.org/papers/202paper.pdf >> and see some of the other stuff at >> http://www.cs.princeton.edu/~bwk/202/index.html. >> >> I think that's after V7 was released. >> > Ok, so that was clearly the first ditroff. > > Typesetter C *must have been the original troff release* which was > separate from V6; but I don't remember what all was in the release. > Looking at the v6 distribution tape I have, the assembler versions of roff > and nroff was there; but not troff. V7 clearly shows the original troff > in the sources. > > > The order I remember is this ... V5, V6, Patches, Typesetter C, TS, V7 > ... although TS and Typesetter might be switched but I know we got > Typesetter C before we got V7. Ted brought TS to us (in EE) and I > thought that had the new compiler. CS got TS from us in EE. But > somebody at CMU had wanted troff because we had the XGP in CS that we drive > with Scribe (I want to say that was EE but I don't remember who was > involved). So I have memory of somebody hacking on the compiler at some > point. The POR (which if ever came to bear at CMU was after I left) was > some type of hacking on troff to support the XGP. Given the time Aharon > points out, it might have been direct support it or it might have been > something like vcat - I was not involved. Klone might remember more of > that. > > Clearly from the time, ditroff did not yet exist. The more I think about > it, Brian K actually might know some of the story. Scribe was Brian Reid's > PhD Thesis and Brian K was on Reid's committee at the time and I'm guessing > could somehow have been mixed up. > > FWIW: Compiler hacking at CMU stands out in my mind because of the 11/40e > had CSAV/CRET instructions. The CS versions of the compilers generated > code using that, because they had 11/40e with CMU WCS options. The rest of > us in EE, BioMed, Mellon Institute etc were running on 11/34's or 11/34A > which could not handle those binaries (no WCS). So I personally spent > time tracking the CS versions of the compiler and bringing things to EE, > trying to keep thing clean. That was one of my jobs at the time. > > That's fairly sure of the order, because we had Typesetter C at CMU in the > Summer '78 when were we negotiating the 'university' commercial V7 license > with Al Arms [which I was personally mixed up -- the finally > ruling/agreement was license one system as a commercial system at the $20K > fee and a university, could then use UNIX for back office and commercial > style uses like Industry. Al did not require the $5K second CPU stuff from > the Universities, if they got a single $20K license; everyone was happy - > details off list or another thread if you want them; although I will say > CMU was first in early '79, followed by Case in late 1979]. > > So again, I try to date by things I know are fixed in time and then work > from there. As Dan points out the cross pollination was high in those > days and it was not just from the labs to the Universities. For instance, > Ted took fsck back to Summit & MH, as well as a number of other tools > (although I think that one had the longest reach). Noel has mentioned > similar stories from MIT. Chesson brought all the networking stuff from > UoI and we saw some of it in datakit (an earlier version of his mpx code > for V7 he did as a grad student). You get the idea.... > > Clem > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun Aug 26 09:02:01 2018 From: clemc at ccc.com (Clem Cole) Date: Sat, 25 Aug 2018 19:02:01 -0400 Subject: [TUHS] changes in C compilers In-Reply-To: References: <201808240702.w7O72pJT005068@freefriends.org> <201808251830.w7PIURLX024379@freefriends.org> Message-ID: Fsck was very much a CMU program. I had a small hand in it - the reason why the errors Messages are upper case in fact. (a different story). That said it was hardly a new idea - Ted modelled it from a similar program he saw at UMich on MTS and one I ran on TSS called the file system checker. im guessing there may have been other programs like it. Before fsck Ken had icheck ncheck and dcheck. IIRC Masheys team in PWB @ Whippany I think, wrote fsdb which shows up around the same time I also think the Columbus folks may have something early on also. Ted took fsck back To USG and it became part of the Summit releases. Bill Joy had been his roommate at Michigan which I think is how to made to ucb. But Joy had it there before I showed up. Clem On Sat, Aug 25, 2018 at 6:19 PM John P. Linderman wrote: > *Ted took fsck back to Summit & MH* > > I got my introduction to UNIX in '73 or '74, when the group running the > 11/45 in Piscataway found out I came into work before 6am. UNIX was so > unstable back then that it had to be rebooted every day, to contain file > system corruption. A 6 am reboot went pretty much unnoticed. I could swear > we ran something very like fsck after each reboot. In particular, I recall > the **gok** diagnostic when the type of an inode wasn't anything > recognizable. Whatever we ran, I'm sure it continued to evolve. > > > On Sat, Aug 25, 2018 at 3:58 PM, Clem Cole wrote: > >> >> >> On Sat, Aug 25, 2018 at 2:38 PM wrote: >> >>> The APS work started in the summer of 1979. See >>> http://www.eprg.org/papers/202paper.pdf >>> and see some of the other stuff at >>> http://www.cs.princeton.edu/~bwk/202/index.html. >>> >>> I think that's after V7 was released. >>> >> Ok, so that was clearly the first ditroff. >> >> Typesetter C *must have been the original troff release* which was >> separate from V6; but I don't remember what all was in the release. >> Looking at the v6 distribution tape I have, the assembler versions of roff >> and nroff was there; but not troff. V7 clearly shows the original troff >> in the sources. >> >> >> The order I remember is this ... V5, V6, Patches, Typesetter C, TS, V7 >> ... although TS and Typesetter might be switched but I know we got >> Typesetter C before we got V7. Ted brought TS to us (in EE) and I >> thought that had the new compiler. CS got TS from us in EE. But >> somebody at CMU had wanted troff because we had the XGP in CS that we drive >> with Scribe (I want to say that was EE but I don't remember who was >> involved). So I have memory of somebody hacking on the compiler at some >> point. The POR (which if ever came to bear at CMU was after I left) was >> some type of hacking on troff to support the XGP. Given the time Aharon >> points out, it might have been direct support it or it might have been >> something like vcat - I was not involved. Klone might remember more of >> that. >> >> Clearly from the time, ditroff did not yet exist. The more I think >> about it, Brian K actually might know some of the story. Scribe was Brian >> Reid's PhD Thesis and Brian K was on Reid's committee at the time and I'm >> guessing could somehow have been mixed up. >> >> FWIW: Compiler hacking at CMU stands out in my mind because of the 11/40e >> had CSAV/CRET instructions. The CS versions of the compilers generated >> code using that, because they had 11/40e with CMU WCS options. The rest of >> us in EE, BioMed, Mellon Institute etc were running on 11/34's or 11/34A >> which could not handle those binaries (no WCS). So I personally spent >> time tracking the CS versions of the compiler and bringing things to EE, >> trying to keep thing clean. That was one of my jobs at the time. >> >> That's fairly sure of the order, because we had Typesetter C at CMU in >> the Summer '78 when were we negotiating the 'university' commercial V7 >> license with Al Arms [which I was personally mixed up -- the finally >> ruling/agreement was license one system as a commercial system at the $20K >> fee and a university, could then use UNIX for back office and commercial >> style uses like Industry. Al did not require the $5K second CPU stuff from >> the Universities, if they got a single $20K license; everyone was happy - >> details off list or another thread if you want them; although I will say >> CMU was first in early '79, followed by Case in late 1979]. >> >> So again, I try to date by things I know are fixed in time and then work >> from there. As Dan points out the cross pollination was high in those >> days and it was not just from the labs to the Universities. For instance, >> Ted took fsck back to Summit & MH, as well as a number of other tools >> (although I think that one had the longest reach). Noel has mentioned >> similar stories from MIT. Chesson brought all the networking stuff from >> UoI and we saw some of it in datakit (an earlier version of his mpx code >> for V7 he did as a grad student). You get the idea.... >> >> Clem >> >> > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Sun Aug 26 09:14:13 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 25 Aug 2018 19:14:13 -0400 (EDT) Subject: [TUHS] changes in C compilers Message-ID: <20180825231413.612F818C082@mercury.lcs.mit.edu> > From: Clem Cole > Looking at the v6 distribution tape I have, the assembler versions of > roff and nroff was there Whoa! The standard V6 distribution tape, as in the one there are a couple of copies of in the repository, does not have that. Do you have that in machine-readable form? If so, can you get it to Mr. Toomey ASAP? > The order I remember is this ... V5, V6, Patches, Typesetter C, TS, V7 Where do USG and PWB fit into that? The repository has PWB (or, what is _claimed_ to be PWB), which is how I know the MIT system is PWB. But there is nothing of the others (except the kernel manual for USG, which shows that the version described in it is basically V6). If anyone has TS in _any_ form (including hardcopy listings, please speak up! Those 'early' PDP-11 versions are very poorly documented now, and I'd love to get more on them. Noel From clemc at ccc.com Sun Aug 26 09:56:47 2018 From: clemc at ccc.com (Clem Cole) Date: Sat, 25 Aug 2018 19:56:47 -0400 Subject: [TUHS] changes in C compilers In-Reply-To: <20180825231413.612F818C082@mercury.lcs.mit.edu> References: <20180825231413.612F818C082@mercury.lcs.mit.edu> Message-ID: On Sat, Aug 25, 2018 at 7:14 PM Noel Chiappa wrote: > > From: Clem Cole > > > Looking at the v6 distribution tape I have, the assembler versions of > > roff and nroff was there > > Whoa! The standard V6 distribution tape, as in the one there are a couple > of > copies of in the repository, does not have that. The v6 stuff is in Warrens archives. The files are in the ./s7 directory: {,n}roff[1-8].s show dates of July 17, 1975 > > Do you have that in machine-readable form? If so, can you get it to Mr. > Toomey > ASAP? > > > > The order I remember is this ... V5, V6, Patches, Typesetter C, TS, > V7 > > Where do USG and PWB fit into that? This is order of the releases we had at CMU. PWB 1.0 was before USG was formed I want to say '77 Mashey lead the team for sure and I think Frazer may have been part. USG was Created and APS and Ted were two of First hackers who were there. Ted tried to get me at some point but I did not want to move to NJ. Fwiw: The job of USG was to support Unix for the operating companies that wanted to use Unix at the TelCos. Steve Johnson I think went over there from Research at some point (I assume to lead the development tools). PWB 2.0 was the first Formal full USG release - I think in 1980 but they did stuff before that. steve might remember who the original managers were And other things they released - I thought Mashey had moved on by then. Korn's stuff became the Core of the toolkit releases at some point but dates on that are fuzzy in my memory. also, Until PWB 3.0 (aka System III) none of the USG releases were licensed to universities or anyone outside the Bell System . . but a number of at&t employees brought it with them On their OYOC times so 1.0, 2.0 etc all leaked. I thought TS was done in MH not Summit. Heinz L was doing Merit around that time too. As I understand it, the TS kernel was attempt at bringing the PWB 1.0 changes in line with what Research had at the time. Some later version of That kernel plus some of the Columbus changes for things like shared memory and ipc became either PWB 2.0/3.0. PWB 4.0 went to the TelCos but was not released outside. I don't know of any University that was interested in it because by the BSD was available so even if an employee brought it, I don't think many people wanted it. > > The repository has PWB (or, what is _claimed_ to be PWB), which is how I > know > the MIT system is PWB. But there is nothing of the others (except the > kernel > manual for USG, which shows that the version described in it is basically > V6) Right that was leaked somehow. . > > If anyone has TS in _any_ form (including hardcopy listings, please speak > up! I have looked in fact the week I did a huge clean out in the basement. So far nothing new. I'll let you know if I find anything readable. > Those 'early' PDP-11 versions are very poorly documented now, and I'd love > to > get more on them. Yeah as I said it was stream with a lot of cross pollination. Clem -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at deitygraveyard.com Sun Aug 26 10:28:11 2018 From: jim at deitygraveyard.com (Jim Carpenter) Date: Sat, 25 Aug 2018 20:28:11 -0400 Subject: [TUHS] hal.gnu.ai.mit.edu In-Reply-To: References: Message-ID: <351f1534-9a08-9366-f09a-40337b28df16@deitygraveyard.com> On 08/25/2018 02:59 PM, Steve Mynott wrote: > > > On Sat, 25 Aug 2018 at 19:45, Steve Mynott > wrote: > > > Back in the early 90s before the FSF withdrew the service due to > misuse it was possible to write off to them to get a free shell > account on "hal" as I did. I recall having to telnet through one > of three gateway systems so assume it was on its own little subnet. > > But I can't remember what sort of system (hardware or OS) it was > now however and wondered if anyone else did? > > > https://ftp.gnu.org/old-gnu/Manuals/finger-1.37/html_node/finger_17.html > mentions "spiff" (which rings a bell as one of the systems) as a > "Sony" which must have been a NEWS-OS (BSD) system. > -- > Steve Mynott > > cv25519/ECF8B611205B447E091246AF959E3D6197190DD5 'hal' was running AIX on a RS/6000. At least it was when I last used it sometime in 1992 or so. It was one of the gateways. 'spike', I'm pretty sure, was a Sony NEWS. It was also one of the gateways IIRC. Those are the only two I can (kinda) remember. Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Sun Aug 26 10:31:27 2018 From: wkt at tuhs.org (Warren Toomey) Date: Sun, 26 Aug 2018 10:31:27 +1000 Subject: [TUHS] Usenix: no official Unix 50th celebration, apparently Message-ID: <20180826003127.GA18905@minnie.tuhs.org> Hi all, I've just heard that the Usenix board of directors do not want to explicitly celebrate the 50th anniversary of Unix. It's been suggested that we, the TUHS members, both lobby the board and also offer our assistance to help organisation such a celebration. Who, on the list, would put their hands up to help organising something that coincided with the 2019 Usenix ATC in July 2019? I'd like to get the bare bones of an organising team, then approach the Usenix board, offer our help and ask them to support us. What do you think? 11 months to go. Thanks, Warren P.S. Nokia Bell Labs are also going to organise something, possibly a month earlier but I have no solid details yet. From lyndon at orthanc.ca Sun Aug 26 11:04:24 2018 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Sat, 25 Aug 2018 18:04:24 -0700 Subject: [TUHS] Usenix: no official Unix 50th celebration, apparently In-Reply-To: <20180826003127.GA18905@minnie.tuhs.org> References: <20180826003127.GA18905@minnie.tuhs.org> Message-ID: <69e611959cdd9902@orthanc.ca> Warren Toomey writes: > Hi all, I've just heard that the Usenix board of directors do not want > to explicitly celebrate the 50th anniversary of Unix. Why not?!? From lm at mcvoy.com Sun Aug 26 11:31:31 2018 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 25 Aug 2018 18:31:31 -0700 Subject: [TUHS] Usenix: no official Unix 50th celebration, apparently In-Reply-To: <69e611959cdd9902@orthanc.ca> References: <20180826003127.GA18905@minnie.tuhs.org> <69e611959cdd9902@orthanc.ca> Message-ID: <20180826013131.GD4893@mcvoy.com> On Sat, Aug 25, 2018 at 06:04:24PM -0700, Lyndon Nerenberg wrote: > Warren Toomey writes: > > Hi all, I've just heard that the Usenix board of directors do not want > > to explicitly celebrate the 50th anniversary of Unix. > > Why not?!? I had composed a reply and thought it was snarky, but what the heck. There is a reason I stopped going to Usenix and this is just more evidence that I made the right choice. For those who care, here's the back story (and Clem fixed this but long after I had pulled out). Somewhere in the 1990's Victor Yodaiken wrote a really cool paper. I was one of the reviewers and Rob Gingell was as well (Rob was a Sun Fellow which was the equiv of a VP but in the technical track. Great guy, I had and have much respect for him). Victor's paper was about how to do real time and a time sharing system at the same time. If you know operating systems you know that real time and time sharing don't mix, people keep trying to mix them and it doesn't really work. The real time people talk about "good enough" but the people who know math and operating systems know that you can't truly get both. Victor got both. He did it by creating a real time kernel that ran Linux, all of Linux, the kernel and user space, as the real time kernel's idle process. Linux disabled interrupts, the RT kernel was like, yeah, sure you did. It was brilliant. It worked. I've seen demos where Linux is running xperfmon, some other compute load, tarring up /home and untarring on an NFS server, in other words, beating the crap out of the hardware, and the RT kernel never missed an event. Rob was part of the good old boys club that was Unix. He had never heard of Victor and he rejected the paper while I was a big fan (I believe this paper was how I met Victor, I sought him out). Rob came up with some noise about how the RT kernel wasn't POSIX compliant (duh, then it wouldn't be real time) but the real reason, I believe, was that Victor wasn't part of the good old boys club. Roll forward some years and I'm the chair of Linux expo. It was 1998, early days, but it was apparent that Linux was a thing. And it was a Unix thing that wasn't part of Usenix. Ellie (or someone, maybe Honeyman, was he part of the board?) came to me and asked me to pull the Linux folks into Usenix. They offered me "anything" I wanted, be on the board, be on the review committee, etc. What I asked for was nothing for me, but something for everyone, blind peer reviews of paper submissions. They said no and I've not been to a Usenix conference since. Clem says he cleaned house but still, it's not blind reviews to this day so far as I know. And it's a huge shame. The world should have gotten to see Victor's brilliant have your cake and eat it too real time / time sharing idea. It didn't because of the old boys club and that's a bummer. No disrespect to Rob, I think he was just in that space and sort of knee jerked, he's a good guy, I think he just made a bad call that time. --lm From clemc at ccc.com Sun Aug 26 12:03:04 2018 From: clemc at ccc.com (Clem Cole) Date: Sat, 25 Aug 2018 22:03:04 -0400 Subject: [TUHS] Usenix: no official Unix 50th celebration, apparently In-Reply-To: <69e611959cdd9902@orthanc.ca> References: <20180826003127.GA18905@minnie.tuhs.org> <69e611959cdd9902@orthanc.ca> Message-ID: On Sat, Aug 25, 2018 at 9:11 PM Lyndon Nerenberg wrote: > Warren Toomey writes: > > Hi all, I've just heard that the Usenix board of directors do not want > > to explicitly celebrate the 50th anniversary of Unix. > > Why not?!? > Before I reply to the list, I also know some people on this list have a distaste for some of the USENIX folks. There were some problems in the past with at least one important employee. That has been corrected, but the 'institutional memory' was also some what sacrificed as people such as my self got a little burned out dealing with the issues. That said, they are good people and they have changed which is good. But they are primarily a more academic focused lot and as such, few of the people that understand the value (much less were there) are activity involved. That said, I made a proposal at the last BOD meeting in June that we do something 'special' at the next USENIX. I had a vetted the proposal with Warren as well as a with a number of previous BOD members, including a couple of past presidents. I thought it made a lot of sense as did others. Unfortunately, while it may be here, history for the sake of history is not all that interesting to them. So, the basic pitch is that until UNIX came about, OSses were all over the map and everything was a different. Except for UNIX nothing from those days really is left except maybe Fortran and that only for HPC. Yet, today in most days, you (computer person or mortal) can hardly not be using a UNIX system, from your cell phone, IoT devices, car, to search and Internet services. No other part of computing has had such an effect and been as pervasive and lastest. We need to celebrate how that happened and try to remember some of the important things and people that made it so. The boards response has been: *"**... agrees that we should acknowledge this milestone appropriately. After much discussion, they concluded that USENIX will do so throughout the course of its regularly scheduled and budgeted activities.'' *Basically they want to say something at opening session and maybe acknowledge a few people that come to ACT next summer, but nothing like what we talked about. I wanted to have a party at the History Museum in Seattle (ACT will be in Renton). The problem is that ACT no longer has a big party mid week, so they don't have an event for this to occur. Plus much of the board did a little bit of a huh? which in my translation is - "if it does not help us academically, tell me why we need to do this again?" BTW: One of the other thing that I socialized was how this community was always open and inviting to people regardless of sexual orientation, race, creed etc. There have been disagreements (which Larry can regale you on a few as I know he holds a certain people responsible for bad things, ushc as how the Linux community was handled). But I wanted to try to see if we could get some of the important women, not just the men (i.e. the Systers) as well as some of the folks from the LGBQ community that were a part. It's an interesting social history as well as technical one. My reply to the official email from Casey and Carolyn was: *"**I do think you should do something over and above. As I said, I know a lot of people are 'up' for it and what to do we be apart and keep asking what can they do/what is going to be done. There has been a bit of discussion on the TUHS mailing list. As I said, I've been in contract with Lou Katz, the first USENIX President, and Debbie S (who was an early President) and Andrew Hume (also ex-President). All have expressed interest in helping and think it would be a great idea to do something 'special' both to recognize but also because it should be fun."* I believe the BOD will support a BOF, but they are not going to fund bring people back or anything over and beyond or an external party (although I'm not opposed to asking a few people like Rich Adams who made $s with UNIX to help us fund something). So my comment to Warren was basically this thought: if we try to make sure people are there and we set something up, I know we can have BOF. But if we plan it and arrange it and maybe we hit bod at usenix.org with email we can do something. I've been looking for a good intro to the folks in Seattle, as I still think a party there would be the best - but we need permission and then we need to find a way to fund it. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sun Aug 26 12:22:10 2018 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 25 Aug 2018 19:22:10 -0700 Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: References: <1535123616.1824656.1485063544.08BED1A8@webmail.messagingengine.com> <20180824164646.GH25694@mcvoy.com> Message-ID: <20180826022210.GF4893@mcvoy.com> On Fri, Aug 24, 2018 at 10:54:41AM -0700, Jon Forrest wrote: > On 8/24/2018 9:46 AM, Larry McVoy wrote: > >People remember the alpha with a lot of revisionist history, talking > >about fast it was. I was actually measuring performance of all the > >CPUs at that time and the Alpha I had wasn't anything to write home > >about. > > When the alpha first came out there were 3 implementations, soon > followed by more. I wonder which one you measured. 2106A 275Mhz > (You probably don't remember this but you once came to my office > at UCB to talk to my officemate Carl Staelin back when I had > one of the first alphas to be released by DEC.) I don't remember a lot of stuff, I'm old. Old enough to get the joke that when you are 25 and you open the fridge and ask "what am I doing here?" it is existential question. When you are my age and you open the fridge and ask the same question it's because you forgot what you wanted. That said, I do have some memory of going somewhere, but UCB? I thought Carl was at HP Labs? But I do remember going somewhere. And all these years later Carl and I are still close friends. It is a small world. --lm From lm at mcvoy.com Sun Aug 26 12:34:41 2018 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 25 Aug 2018 19:34:41 -0700 Subject: [TUHS] Usenix: no official Unix 50th celebration, apparently In-Reply-To: References: <20180826003127.GA18905@minnie.tuhs.org> <69e611959cdd9902@orthanc.ca> Message-ID: <20180826023441.GG4893@mcvoy.com> > BTW: One of the other thing that I socialized was how this community was > always open and inviting to people regardless of sexual orientation, race, > creed etc. There have been disagreements (which Larry can regale you on a > few as I know he holds a certain people responsible for bad things, ushc as > how the Linux community was handled). But I wanted to try to see if we > could get some of the important women, not just the men (i.e. the Systers) > as well as some of the folks from the LGBQ community that were a part. > It's an interesting social history as well as technical one. I want just want to add to this comment Clem. You are spot on in my experience. It's one of the bright spots of our industry, in my opinion (I can imagine that there are people who will disagree, this is just what I've seen). In my experience, nobody cared if you were male, female, gay, lesbian, transgender, whatever, it was all cool if you could figure out this kernel panic, we'll kiss your ass (well, maybe not that but we'll buy dinner at Harry's Hafbrau and that's better than a kiss). I've watched a tech writer go from female to dude to female and nobody cared, she was a good tech writer. I'm sure there are people that will disagree but the world I lived in was super welcoming to people being different, all we cared about was can you do your job. --lm From dave at horsfall.org Sun Aug 26 12:47:45 2018 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 26 Aug 2018 12:47:45 +1000 (EST) Subject: [TUHS] Usenix: no official Unix 50th celebration, apparently In-Reply-To: <20180826003127.GA18905@minnie.tuhs.org> References: <20180826003127.GA18905@minnie.tuhs.org> Message-ID: On Sun, 26 Aug 2018, Warren Toomey wrote: > Hi all, I've just heard that the Usenix board of directors do not want > to explicitly celebrate the 50th anniversary of Unix. What on earth are they smoking? Or is it something in the water? [...] > What do you think? 11 months to go. I'd love to help out in any way that I can, but now that I'm officially an Aged Pensioner I seem to be flat out for some reason... And yes, I really must get that ACSnet (and UUCP) node going, but now that I have time for Amateur radio (and electronics in general) I really must clean off my workbench so that I can see my dining table again (and it's just as well that I'm divorced, as otherwise I soon would be). -- Dave VK2KFU From tytso at mit.edu Sun Aug 26 14:10:46 2018 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Sun, 26 Aug 2018 00:10:46 -0400 Subject: [TUHS] Usenix: no official Unix 50th celebration, apparently In-Reply-To: References: <20180826003127.GA18905@minnie.tuhs.org> Message-ID: <20180826041046.GA3176@thunk.org> On Sun, Aug 26, 2018 at 12:47:45PM +1000, Dave Horsfall wrote: > On Sun, 26 Aug 2018, Warren Toomey wrote: > > > Hi all, I've just heard that the Usenixh board of directors do not want > > to explicitly celebrate the 50th anniversary of Unix. > > What on earth are they smoking? Or is it something in the water? Reading between lines from Clem's message, I wonder if it is a money issue? Usenix has become very academic focused, and for better or for worse the Linux Foundation has provided many conference facilitation services for various industry initiatives that go beyond Linux (e.g., software defined networking, RISC-V, etc.) As a result Usenix might not have the resources that it did a decade or two ago. In another reality these industry initiatives might have been something that Usenix had gotten involved in, and which would have made it much more relevant to the industry. Unfortunately, I believe that there were many "old-time Usenix" folk who felt very threatened by Linux, and thought that it wasn't sufficiently academic, and didn't sufficiently acknowledge the debt that was owed to their elders. The question I would raise is whether some kind of 50th celebration has to be colocated with Usenix ATC, especially if the Usenix BoD is not innterested in lending much in the way of financial or staff support. For example, maybe something combined with some kind of fund-raising event held at the Compute History Museum in the Bay Area? Or perhaps the Linux Foundation might be willing to do a Unix 50th celebration at their 2019 Open Source Summit event? It does seem to me that Usenix ought to have the right of first refusal to host such a celebration, but if the Board isn't willing to step it up, there are other possibilities that could be explored. - Ted From khm at sciops.net Sun Aug 26 15:29:31 2018 From: khm at sciops.net (Kurt H Maier) Date: Sat, 25 Aug 2018 22:29:31 -0700 Subject: [TUHS] Usenix: no official Unix 50th celebration, apparently In-Reply-To: <20180826003127.GA18905@minnie.tuhs.org> References: <20180826003127.GA18905@minnie.tuhs.org> Message-ID: <20180826052931.GA14695@wopr> On Sun, Aug 26, 2018 at 10:31:27AM +1000, Warren Toomey wrote: > > What do you think? 11 months to go. > > Thanks, Warren > > P.S. Nokia Bell Labs are also going to organise something, possibly a month > earlier but I have no solid details yet. Unsenix stopped being Usenix when they rode SAGE into the ground and chased out all the sysadmins. I appreciate the efforts of a lot of people there to keep the flag up, but I've never understood the decision to try to become ACM Lite (pastes great, less filling). I'm super interested in what Bell Labs has planned, and anything happening at the Living Computer Museum as well. Maybe if we ask nicely they'll let us play with the Blit! khm From arnold at skeeve.com Sun Aug 26 18:48:25 2018 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 26 Aug 2018 02:48:25 -0600 Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: <1535123616.1824656.1485063544.08BED1A8@webmail.messagingengine.com> References: <1535123616.1824656.1485063544.08BED1A8@webmail.messagingengine.com> Message-ID: <201808260848.w7Q8mPuP007397@freefriends.org> I am pretty sure that V8 was the first research system to run on Vaxen, and I believe that Research used 750 and later 8550s for their systems. Norman could probably give a defnitive answer. V7 on the Interdata aside, Plan 9 is when you saw a big push to a multiplatform system: MIPS, SPARC, 68040 and 386. Arnold Seth Morabito wrote: > After the past several years of focusing on 3B2 preservation and > emulation, I've begun to wonder whether 3B2 hardware was used very much > inside of Bell Labs. Has anyone ever heard whether Research UNIX was > ever ported to the WE32100? I've certainly never seen anything that > would suggest it was, but I'd love to be proven wrong. > > -Seth > -- > Seth Morabito > Poulsbo, WA > web at loomcom.com From norman at oclsc.org Sun Aug 26 23:09:42 2018 From: norman at oclsc.org (Norman Wilson) Date: Sun, 26 Aug 2018 09:09:42 -0400 Subject: [TUHS] Research UNIX on the AT&T 3B2? Message-ID: <1535288985.3793.for-standards-violators@oclsc.org> Seth Morabito: After the past several years of focusing on 3B2 preservation and emulation, I've begun to wonder whether 3B2 hardware was used very much inside of Bell Labs. Has anyone ever heard whether Research UNIX was ever ported to the WE32100? I've certainly never seen anything that would suggest it was, but I'd love to be proven wrong. ===== I never heard of anyone doing such a thing. Had they ported the kernel I would almost certainly have heard about it, because they'd have asked me a question or two. Much VAX-specific structure inside there that I'd love to have had the time and energy to clean up. It's possible that someone did a semi-port, moving a lot of the user-mode tools like the shell and the Jerq software. Dave Kapilow did something like that for early SunOS, including a mux-like X11 terminal program called sux, built atop a library that did a simple mapping from Jerq graphics-library calls to X11. Certainly nobody inside 1127 ever did either of those things. A few of us played with 3B1 or 3B2 systems (I remember Tom Duff had a 3B1 at home at one point), but never very seriously. Norman Wilson Toronto ON From paul.winalski at gmail.com Mon Aug 27 02:34:34 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Sun, 26 Aug 2018 12:34:34 -0400 Subject: [TUHS] C++ / Kernel In-Reply-To: <20180824181522.2nrUS%steffen@sdaoden.eu> References: <10c401d43aef$8be34870$a3a9d950$@ronnatalie.com> <151301d43b2f$07881ed0$16985c70$@ronnatalie.com> <20180823231413.QeahD%steffen@sdaoden.eu> <20180824141348.1NLUE%steffen@sdaoden.eu> <1f6201d43bb7$3b9ebde0$b2dc39a0$@ronnatalie.com> <20180824181522.2nrUS%steffen@sdaoden.eu> Message-ID: On 8/24/18, Steffen Nurpmeso wrote: > > Though even more unfortunate i am, since this union trick is often > the only way to be able to do proper a.k.a. allowed type > conversion, where the standard text forbids something quick and > easy, casting of or to function pointers in C++ comes to mind > spontaneously. (The linked story also tries to go via (char*) to > a desired type, but the compiler seems to be too neat. And even > if this is a bug, of course...) One of the complaints about DEC's C99 compiler for Ultrix was that it was too didactic in its enforcement of the C99 standard. One customer called it the Rush Limbough of compilers, because it was extremely conservative and you couldn't argue with it. Function pointers can be tricky, as they might not be simple pointers to a sequence of instructions. On Itanium, for example, a C pointer-to-function points to a descriptor for the function, not the function code itself. -Paul W. From mah at mhorton.net Tue Aug 28 01:54:28 2018 From: mah at mhorton.net (Mary Ann Horton) Date: Mon, 27 Aug 2018 08:54:28 -0700 Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: References: <1535123616.1824656.1485063544.08BED1A8@webmail.messagingengine.com> Message-ID: Inside AT&T (but outside research) there was considerable pressure to use AT&T products (3B, System V, BLIT/5620, Datakit) rather than the externally developing Sun/Ethernet/TCP suite, especially in the mid-late 1980s.  We all (mostly) hated them and wanted Suns, but we were told "eat your own dog food." The 3B20 and 3B5 were awful, but the 3B2 had potential.  Once we got a working TCP/IP network in Bell Labs the tide turned in favor of Suns. On 08/24/2018 09:06 AM, Clem Cole wrote: > On Fri, Aug 24, 2018 at 11:13 AM Seth Morabito > wrote: > > ... > I've begun to wonder whether 3B2 hardware was used very much > inside of Bell Labs. > > I'd be curious to hear of people that actually used it.  AT&T forced > you to buy one with SVR3 as the porting base (I'd have never had > bought the one we had a Stellar otherwise). > The only time I ever knew anyone run one, was to check to see the > behavior of some code/validation testing of RFS /etc/... > > The HW as pretty slow/inflexible compared to 68020/68030 which came > out around the same time, so it was just not interesting - /i.e./ > 'JAWS' - Just another work station' and it did not have a display.  > IIRC, it was a server and pretty inflexible in the I/O subsystem for > that use. > Sun would quickly produce the first Sparcs, which as Larry has pointed > out, kicked butt > and were cheaper > .   The MIPS chip would emerge > with lots of designs, > and for that matter the 040 and the 386 would appear soon their after > , too. > > I've always felt that the 3Bx series was an example of fighting the > previous war; other than 3B4000 (which had high reliability but other > issues in practice to use it), there was never anything that made them > special - compared to everyone else. > > The only 'successful' product > that I > can > rememberthat used the WE32100 > was the > second version (/a.k.a./product version) of the Blit (Bart's first > version was 68000 IIRC).  Does anyone know of another product?  I > think I was told the 5ESS > changed >  the SLICs > design > from the original 68000 design to WE32100 but I was no > longer associated with anyone working on it by then, so I don't know. > > Dennis once remarked to a couple of us that the WE32100 was an example > of AT&T wanting to make sure it had its own recipe to make processors, > but it was not clear it was worth it.   BTW: around the same time both > AT&T and HP were making their own DRAM too.  It was common thinking in > management at tech companies - telling folks that they needed to be > 'vertically integrated.'  But in the case of both HP and AT&T there > internally produced DRAM chips cost 2-3 times what the merchant market > cost; so besides the investment in the fab (which was huge) it was a > pretty expensive insurance policy. > > That said, this was also the end times for the idea of the 'second > source.'   Chip manufacturers would be required to license their > designs to some one else (for instance AMD was originally Intel's > second source).   I think HP was using a second source license for > their memory, but IIRC AT&T had developed its own because they had > higher reliability standards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Tue Aug 28 02:31:17 2018 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 27 Aug 2018 18:31:17 +0200 Subject: [TUHS] C++ / Kernel In-Reply-To: References: <10c401d43aef$8be34870$a3a9d950$@ronnatalie.com> <151301d43b2f$07881ed0$16985c70$@ronnatalie.com> <20180823231413.QeahD%steffen@sdaoden.eu> <20180824141348.1NLUE%steffen@sdaoden.eu> <1f6201d43bb7$3b9ebde0$b2dc39a0$@ronnatalie.com> <20180824181522.2nrUS%steffen@sdaoden.eu> Message-ID: <20180827163117.PTEBF%steffen@sdaoden.eu> Paul Winalski wrote in : |On 8/24/18, Steffen Nurpmeso wrote: |> Though even more unfortunate i am, since this union trick is often |> the only way to be able to do proper a.k.a. allowed type |> conversion, where the standard text forbids something quick and |> easy, casting of or to function pointers in C++ comes to mind |> spontaneously. (The linked story also tries to go via (char*) to |> a desired type, but the compiler seems to be too neat. And even |> if this is a bug, of course...) | |One of the complaints about DEC's C99 compiler for Ultrix was that it |was too didactic in its enforcement of the C99 standard. One customer |called it the Rush Limbough of compilers, because it was extremely |conservative and you couldn't argue with it. | |Function pointers can be tricky, as they might not be simple pointers |to a sequence of instructions. On Itanium, for example, a C |pointer-to-function points to a descriptor for the function, not the |function code itself. They can be as tricky as they want as long as i can go and use them, wouldn't you agree? Not only for simple callbacks but for "manual VTables" you simply need those dynamic callbacks. Like you have said, you need a way to change the instruction location. As far as i know this is what actually happens, and i want to be able to access this mechanism without being prevented from some language rule which is backed by nothing. That is all. Whatever high language construct there may be. To me this was one of the properties of the C language. I can give you another example. I have a C++ library which uses an approach to events where you (can) define slots, as in pub Misc::Sender onInput; You then say XY.onInput.connect(MYHOOK), where MYHOOK can be one of four different types, which return "event consumed: pub typedef boolean ( *Slot1)(Event *); pub typedef boolean ( *Slot2)(void *, Event *); pub typedef boolean ( EventListener::*Slot3)(Event *); The first is a PTF callback without user provided data, the second adds that; the third is a PointerToMember. The third defines a PTM to a subclass of EventListener, which is an empty class but with VTable (protected destructor), provided for the sole purpose of offering a cheap event slot without marshalling object, managed by an equal number of connection types, superclass: // actual connection structures // note we use the lower three bits of Conn::flags for Flags (including // ConnType) as below. this works because the memory cache has an // alignment of 8 (or 16, and only). pri struct Conn{ union{ uir flags; Conn *right; }; } SF_CC_PACKED; E.g., the third pri struct ConnML{ // EventListener PTM Conn base; EventListener *elobj; Slot3 slot; } SF_CC_PACKED; So far so good. But what to do with free-form PTM hooks? You need templates for that: pub template struct ConnMT{ // free-form PTM (template indirection) typedef boolean (OBJ::*Slot4)(Event *); ConnFO cfo; OBJ *tobj; Slot4 slot; } SF_CC_PACKED; But that induces several problems, one of them is - 2.95.2 and 2.95.3 compile the library without errors. The problem with them is that they are not able to handle the free-from template pointer-to-member (PTM), as well as the EventListener PTM specialization of SF::Sys::Misc::Sender correctly. This is a no-go for other libraries, which use events as a key concept (and base upon EventListener to get rid of the purely template PTM based connection overhead), but is otherwise no problem. (Some of the tests in test/ will not compile, though.) (Note: 2.95.2 has not been tested for a long time. 2.95.3 is part of the test-suite at the time of this writing aka TAG 0.6.0.) The other is that you cannot store ConnMT in generic code -- the C++ standard does not offer this possibility, even though Slot4 is a PTM just the very same way that Slot3 is, right? PTMs are a wild mix of VTable and offset, right. But luckily it can be done, with a very wild hack, but which still works after almost twenty years, whether gcc or clang is used, at least the tests ran just fine last time i have tried: // disconnecting of those is hard; try it like that (doc/cppcreq.txt). pri struct ConnMX{ ConnFO cfo; void *tobj; ui1 ptmbuf[szof(Slot3)]; } SF_CC_PACKED; Nonetheless you need marshalling objects to dispatch events through such slots, which is very painful and expensive, as well as completely unnecessary yet imposed solely by language speech, but at least all the list handling and such works just fine (though using memcmp on ptmbuf is really wild). _pro template void _Sender::connect4(typename ConnMT::Slot4 _Slot, OBJ *_tobj) const{ ConnMT *cmt; cmt = SF_talloc(ConnMT, 1); cmt->cfo.base.flags = ((R(uir,m_slots) & ~f_mask) | ct_ptm_t); m_slots = &cmt->cfo.base; cmt->cfo.slot = &_Sender::_Dispatch; cmt->cfo.obj = cmt; cmt->tobj = _tobj; cmt->slot = _Slot; } _pri template _sta boolean _Sender::_Dispatch(void *_tobj, Event *_ev){ ConnMT *cmt = S(ConnMT*,_tobj); return (cmt->tobj->*cmt->slot)(_ev); } And of course this is a primitive event mechanism which requires an Event class to be used. --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 web at loomcom.com Tue Aug 28 03:06:14 2018 From: web at loomcom.com (Seth Morabito) Date: Mon, 27 Aug 2018 10:06:14 -0700 Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: References: <1535123616.1824656.1485063544.08BED1A8@webmail.messagingengine.com> Message-ID: <1535389574.3616679.1487699024.54D526CE@webmail.messagingengine.com> On Mon, Aug 27, 2018, at 8:54 AM, Mary Ann Horton wrote: > Inside AT&T (but outside research) there was considerable pressure to > use AT&T products (3B, System V, BLIT/5620, Datakit) rather than the > externally developing Sun/Ethernet/TCP suite, especially in the mid- > late 1980s. We all (mostly) hated them and wanted Suns, but we were > told "eat your own dog food." The 3B20 and 3B5 were awful, but the > 3B2 had potential. Once we got a working TCP/IP network in Bell Labs > the tide turned in favor of Suns.> > On 08/24/2018 09:06 AM, Clem Cole wrote: >> On Fri, Aug 24, 2018 at 11:13 AM Seth Morabito >> wrote:>>> >>> ... >>> I've begun to wonder whether 3B2 hardware was used very much inside >>> of Bell Labs.>> I'd be curious to hear of people that actually used it. AT&T forced >> you to buy one with SVR3 as the porting base (I'd have never had >> bought the one we had a Stellar otherwise).>> The only time I ever knew anyone run one, was to check to see the >> behavior of some code/validation testing of RFS *etc*...[...] Thank you all for your many replies! I have a soft spot for the 3B2 because I've put so much work into reverse engineering it and understanding it, but I can absolutely understand why everyone wanted Suns. The 3B2 was a funny architecture, and unless it had been a breakout hit right from the start, I can't imagine a path that would have led to 3B2s taking over the world. -Seth -- Seth Morabito Poulsbo, WA web at loomcom.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Aug 28 03:33:36 2018 From: clemc at ccc.com (Clem Cole) Date: Mon, 27 Aug 2018 13:33:36 -0400 Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: References: <1535123616.1824656.1485063544.08BED1A8@webmail.messagingengine.com> Message-ID: below... On Mon, Aug 27, 2018 at 12:04 PM Mary Ann Horton wrote: > Inside AT&T (but outside research) there was considerable pressure to use > AT&T products (3B, System V, BLIT/5620, Datakit) rather than the externally > developing Sun/Ethernet/TCP suite, especially in the mid-late 1980s. We > all (mostly) hated them and wanted Suns, but we were told "eat your own dog > food." > That was always my impression. IIRC Mt. Xinu made a poster (and Kolstad made a series of buttons) stating "4.2 > V" I remember somebody (ber probably) had it hanging in Whippany and certain supervisors were not amsussed. The 3B20 and 3B5 were awful, but the 3B2 had potential. > It was not so much they we awful IMO, is that they were nothing special - too little too late. The 3B20 (the only computer I even knew with a 'pull starter'), was basically a 1MIP 780 and took the same resources (machine room, multiple 19" cabinets, etc); when a 68020 based Masscomp, Apollo or Sun was at 4-5 MIPS and fit under your desk. As I said, fighting the last war. The 3B2 got the size and performance more inline, but the SW was still behind and by them it was arguable if a BLIT over a serial line could compete with the builtin graphics. For the former, did the 3B2 only run SRV3 and SRV4? The others ran SVR0-2 which was not even close to BSD. By SVR3 the OS finally got better. BILT had some great stuff, but I think the shear volume of programmers using X-Windows, particularly once it ran on super cheap HW (*i.e.* Wintel based) it was tough. > Once we got a working TCP/IP network in Bell Labs the tide turned in favor > of Suns > Although by the time of its release, the default system for SRV4 was Wintel. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpl.jpl at gmail.com Tue Aug 28 05:59:09 2018 From: jpl.jpl at gmail.com (John P. Linderman) Date: Mon, 27 Aug 2018 15:59:09 -0400 Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: References: <1535123616.1824656.1485063544.08BED1A8@webmail.messagingengine.com> Message-ID: We (at the Labs outside of 11127) were definitely forced to use the 3B series, despite its unbelievable lack of documentation (and floating point, for the 3B20s). Having to eat your own dog food doesn't make it palatable, it just prevents you from doing something worthwhile, and dislike those who prepare the menu. I'd be happy to apologize, if the 3Bs had proved their worth. On Mon, Aug 27, 2018 at 1:33 PM, Clem Cole wrote: > below... > > On Mon, Aug 27, 2018 at 12:04 PM Mary Ann Horton wrote: > >> Inside AT&T (but outside research) there was considerable pressure to use >> AT&T products (3B, System V, BLIT/5620, Datakit) rather than the externally >> developing Sun/Ethernet/TCP suite, especially in the mid-late 1980s. We >> all (mostly) hated them and wanted Suns, but we were told "eat your own dog >> food." >> > That was always my impression. IIRC Mt. Xinu made a poster (and > Kolstad made a series of buttons) stating "4.2 > V" I remember somebody > (ber probably) had it hanging in Whippany and certain supervisors were not > amsussed. > > The 3B20 and 3B5 were awful, but the 3B2 had potential. >> > It was not so much they we awful IMO, is that they were nothing special - > too little too late. The 3B20 (the only computer I even knew with a 'pull > starter'), was basically a 1MIP 780 and took the same resources (machine > room, multiple 19" cabinets, etc); when a 68020 based Masscomp, Apollo or > Sun was at 4-5 MIPS and fit under your desk. As I said, fighting the last > war. > > The 3B2 got the size and performance more inline, but the SW was still > behind and by them it was arguable if a BLIT over a serial line could > compete with the builtin graphics. For the former, did the 3B2 only run > SRV3 and SRV4? The others ran SVR0-2 which was not even close to BSD. By > SVR3 the OS finally got better. BILT had some great stuff, but I think > the shear volume of programmers using X-Windows, particularly once it ran > on super cheap HW (*i.e.* Wintel based) it was tough. > > > >> Once we got a working TCP/IP network in Bell Labs the tide turned in >> favor of Suns >> > Although by the time of its release, the default system for > > SRV4 was Wintel. > > Clem > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad at anduin.eldar.org Tue Aug 28 06:27:32 2018 From: brad at anduin.eldar.org (Brad Spencer) Date: Mon, 27 Aug 2018 16:27:32 -0400 Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: (jpl.jpl@gmail.com) Message-ID: "John P. Linderman" writes: > We (at the Labs outside of 11127) were definitely forced to use the 3B > series, despite its unbelievable lack of documentation (and floating point, > for the 3B20s). Having to eat your own dog food doesn't make it palatable, > it just prevents you from doing something worthwhile, and dislike those who > prepare the menu. I'd be happy to apologize, if the 3Bs had proved their > worth. [snip] I was at 6200 Broad Street in Reynoldsburg in the late 1990s to early 2000s and while the group I was a part of was not forced to use the 3B series for our product, we did get forced into using GIS [a.k.a. NCR] systems after NCR was purchased. The OS running on it was some sort of SVR4, pretty vanilla, if I recall correctly. I just remember it being buggy. That version of the product was sold to a single domestic US customer. All of the rest of the domestic customers waited for the HP-UX port which happened after it was obvious no one wanted the NCR product. The product that I was a part of was old even at the time, having been ported to the VAX [SVR3], test ported to SunOS 4.x, Tandem and the AT&T rebranded variation [SVR3, and SVR4], GIS [SVR4] and HP [HP-UX, lots of versions]. I have heard since that the product is still around and runs on Linux at this point. -- Brad Spencer - brad at anduin.eldar.org - KC8VKS - http://anduin.eldar.org From dave at horsfall.org Tue Aug 28 10:24:12 2018 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 28 Aug 2018 10:24:12 +1000 (EST) Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: References: <1535123616.1824656.1485063544.08BED1A8@webmail.messagingengine.com> Message-ID: On Mon, 27 Aug 2018, Clem Cole wrote: > That was always my impression.     IIRC Mt. Xinu made a poster (and > Kolstad made a series of buttons) stating "4.2 > V"  I remember somebody > (ber probably) had it hanging in Whippany and certain supervisors were > not amsussed. I remember seeing a photo of that button. Somewhere (I think) I have a PS/PDF (or was it a sticker?) of "Intel outside" which I stuck to my SparcStation. Unfortunately the latter part of my career was having to support SysVile and pretending that I liked it... -- Dave From lm at mcvoy.com Tue Aug 28 10:30:57 2018 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 27 Aug 2018 17:30:57 -0700 Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: References: <1535123616.1824656.1485063544.08BED1A8@webmail.messagingengine.com> Message-ID: <20180828003057.GA317@mcvoy.com> On Tue, Aug 28, 2018 at 10:24:12AM +1000, Dave Horsfall wrote: > Unfortunately the latter part of my career was having to support SysVile and > pretending that I liked it... I don't think anyone really liked it. Maybe Roger Faulkner. And there are the Joyent crew. Even they, when I told them I had tried it and wasn't impressed, asked if I had /opt/GNU/bin in my path first? Huh? Decades have gone by, Sun is gone, and they are still cleaning to the compatibilty argument for /usr/bin? SunOS was the system that everyone used because they wanted to, Solaris was what people used because they had to. From wkt at tuhs.org Tue Aug 28 11:14:44 2018 From: wkt at tuhs.org (Warren Toomey) Date: Tue, 28 Aug 2018 11:14:44 +1000 Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: References: <1535123616.1824656.1485063544.08BED1A8@webmail.messagingengine.com> Message-ID: <20180828011444.GA20613@minnie.tuhs.org> On Tue, Aug 28, 2018 at 10:24:12AM +1000, Dave Horsfall wrote: > I remember seeing a photo of that button. Somewhere (I think) I have a > PS/PDF (or was it a sticker?) of "Intel outside" which I stuck to my > SparcStation. I made a "Satan Inside" PS file once, along with a "Downgrade to Solaris" PS file. Must dig them out .... Cheers, Warren From arnold at skeeve.com Tue Aug 28 16:01:50 2018 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 28 Aug 2018 00:01:50 -0600 Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: <20180828003057.GA317@mcvoy.com> References: <1535123616.1824656.1485063544.08BED1A8@webmail.messagingengine.com> <20180828003057.GA317@mcvoy.com> Message-ID: <201808280601.w7S61oLM030628@freefriends.org> Larry McVoy wrote: > Decades have gone by, Sun is gone, and they are still cleaning [sic] to the > compatibilty argument for /usr/bin? As hard as it is to believe in this day and age, there are still plenty of places where that compatibility is what sells systems. > SunOS was the system that everyone used because they wanted to, Solaris > was what people used because they had to. Nicely put! Arnold From ggm at algebras.org Tue Aug 28 16:11:38 2018 From: ggm at algebras.org (George Michaelson) Date: Tue, 28 Aug 2018 16:11:38 +1000 Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: <201808280601.w7S61oLM030628@freefriends.org> References: <1535123616.1824656.1485063544.08BED1A8@webmail.messagingengine.com> <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> Message-ID: we pretty much bounced a UNISYS library information system on using ',' (comma) as the separator on IPv4 dotted-quads. If there isn't a dot, how can it be one? I think the OS I used with a cd command which could walk down, but walking "up" was a cd to root and a walk down -1 also fell out of favour. The only thing I remember doing on the apollo domain workstations was tuning their sendmail config. nobody ran commands on it, nobody could reliably compile. HP and its HP compatibility library. and the really badly written BSD compatibility layer. oddly, OSF/1 and RS/6000 AIX both survived. maybe you can have enough lipstick on a pig. reboot to re-apply bindings. well i *guess* that works, but gee, was it really so hard to move shared library through some staging process? and having to boot into a mini OS to do filesystem repairs. please. none of these things were fatal but somehow all of these things were. On Tue, Aug 28, 2018 at 4:02 PM wrote: > > Larry McVoy wrote: > > > Decades have gone by, Sun is gone, and they are still cleaning [sic] to the > > compatibilty argument for /usr/bin? > > As hard as it is to believe in this day and age, there are still plenty > of places where that compatibility is what sells systems. > > > SunOS was the system that everyone used because they wanted to, Solaris > > was what people used because they had to. > > Nicely put! > > Arnold From arnold at skeeve.com Tue Aug 28 16:42:32 2018 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 28 Aug 2018 00:42:32 -0600 Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: References: <1535123616.1824656.1485063544.08BED1A8@webmail.messagingengine.com> <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> Message-ID: <201808280642.w7S6gWYX002026@freefriends.org> George Michaelson wrote: > none of these things were fatal but somehow all of these things were. This goes back to Clem's argument about economics. The increasing power and declining cost of Intel HW combined with the _almost_ neglible cost of Linux combined to kill off almost all the legacy Unixes. That Linux modelled many things after SunOS also helped. But I can testify from experience at my last job that AIX, HP/UX and Solaris are all still in heavy use at major companies, mainly hosting big database systems, but still there and not going away too soon. Arnold From kevin.bowling at kev009.com Tue Aug 28 21:54:19 2018 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Tue, 28 Aug 2018 04:54:19 -0700 Subject: [TUHS] Usenix: no official Unix 50th celebration, apparently In-Reply-To: <20180826052931.GA14695@wopr> References: <20180826003127.GA18905@minnie.tuhs.org> <20180826052931.GA14695@wopr> Message-ID: This is all so asinine it sounds like it’s run by a random haughty social club of people far detached from systems and UNIX and especially far from publishing systems papers that actually advance the art. Sometimes it is necessary to let an org know it’s become a joke. I’d prefer to attend and assist with something not affiliated with Usenix after reading this thread. On Sat, Aug 25, 2018 at 10:36 PM Kurt H Maier wrote: > On Sun, Aug 26, 2018 at 10:31:27AM +1000, Warren Toomey wrote: > > > > What do you think? 11 months to go. > > > > Thanks, Warren > > > > P.S. Nokia Bell Labs are also going to organise something, possibly a > month > > earlier but I have no solid details yet. > > > Unsenix stopped being Usenix when they rode SAGE into the ground and > chased out all the sysadmins. I appreciate the efforts of a lot of > people there to keep the flag up, but I've never understood the decision > to try to become ACM Lite (pastes great, less filling). > > I'm super interested in what Bell Labs has planned, and anything > happening at the Living Computer Museum as well. Maybe if we ask nicely > they'll let us play with the Blit! > > khm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From krewat at kilonet.net Tue Aug 28 23:13:02 2018 From: krewat at kilonet.net (Arthur Krewat) Date: Tue, 28 Aug 2018 09:13:02 -0400 Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: <201808280642.w7S6gWYX002026@freefriends.org> References: <1535123616.1824656.1485063544.08BED1A8@webmail.messagingengine.com> <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <201808280642.w7S6gWYX002026@freefriends.org> Message-ID: <51b9703c-57ac-d3cb-0ec2-70d617c9d77c@kilonet.net> On 8/28/2018 2:42 AM, arnold at skeeve.com wrote: > But I can testify from experience at my last job that AIX, HP/UX and > Solaris are all still in heavy use at major companies, mainly hosting > big database systems, but still there and not going away too soon. If you haven't tried Solaris 11, at least 11.2 or later, check it out. A lot of GNU stuff is available, and you can "pkg install" apache, tomcat, PHP, MYSQL, and a slew of other things that are actually being kept up to date. The recent PHP 7.1.17 exploit fix was put out in the regular Solaris 11 SRU a few weeks after it was publicly released. And that was supposedly after the "mass layoff" of Solaris engineers. I've also noticed quite a few bug fixes for Solaris internals and device drivers since then so Oracle is still maintaining Solaris. I think their most recent support time line puts Solaris support out to 2030 or so. I've installed and maintain a few Solaris 11.1 (since upgraded to 11.3) clusters for Oracle databases on Intel (Dell) blades with fiber channel, and with ZFS they've been rock-solid. Side note, and I probably already said this a long time ago here, but back in the early days of Linux kernel 2.6, I complained on one of the mailing lists about the removal of a way to control the size of the disk cache, along with the tendency for the kernel to page out applications in favor of more disk cache. The snobby answer I got back from a developer was that (paraphrased) "We know better than you about memory allocation" or some such garbage. I've always turned my nose up at Linux since then. I figure if that level of arrogance had infested it to that degree, and an open-source project at that, I wanted no part of it. Since then, of course, they have made some changes that make it less likely to do that, but I have a recent Oracle Linux (Redhat) system here running Oracle eBusiness that is currently 2GB into swap, and has 10G of disk cache. Swappiness is set to 0, and other tunables were altered that should have stopped that. That's just plain dumb. From gilles at gravier.org Wed Aug 29 00:53:40 2018 From: gilles at gravier.org (Gilles Gravier) Date: Tue, 28 Aug 2018 16:53:40 +0200 Subject: [TUHS] Running 4.3 BSD on x86 hardware? Suggestions? Message-ID: Hi! If I wanted to run 4.3BSD on an x86 box (VirtualBox? QEMM? other emu?)... anybody has suggestions? Where can I find media for 4.3BSD (if any are legitimately accessible)? Or on a Raspberry Pi? :) Thanks! Gilles -- *Gilles Gravier* - Gilles at Gravier.org GSM : +33618347147 and +41794728437 Skype : ggravier | PGP Key : 0x8DE6D026 -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Wed Aug 29 01:05:11 2018 From: henry.r.bent at gmail.com (Henry Bent) Date: Tue, 28 Aug 2018 11:05:11 -0400 Subject: [TUHS] Running 4.3 BSD on x86 hardware? Suggestions? In-Reply-To: References: Message-ID: On Tue, 28 Aug 2018 at 10:54, Gilles Gravier wrote: > Hi! > > If I wanted to run 4.3BSD on an x86 box (VirtualBox? QEMM? other emu?)... > anybody has suggestions? Where can I find media for 4.3BSD (if any are > legitimately accessible)? > > Or on a Raspberry Pi? :) > > Thanks! > > Gilles > > > There are full instructions using SIMH here: http://gunkies.org/wiki/Installing_4.3_BSD_on_SIMH -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Aug 29 01:05:21 2018 From: clemc at ccc.com (Clem Cole) Date: Tue, 28 Aug 2018 11:05:21 -0400 Subject: [TUHS] Running 4.3 BSD on x86 hardware? Suggestions? In-Reply-To: References: Message-ID: simh is the traditional way it's done. Google simh and 4.3BSD. configure simh set it up as a 780, with RP06 or RM0[35] drives, HT tapes, and it should pretty much just work per the BSD installation ᐧ On Tue, Aug 28, 2018 at 10:54 AM Gilles Gravier wrote: > Hi! > > If I wanted to run 4.3BSD on an x86 box (VirtualBox? QEMM? other emu?)... > anybody has suggestions? Where can I find media for 4.3BSD (if any are > legitimately accessible)? > > Or on a Raspberry Pi? :) > > Thanks! > > Gilles > > -- > *Gilles Gravier* - Gilles at Gravier.org > GSM : +33618347147 and +41794728437 > Skype : ggravier | PGP Key : 0x8DE6D026 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gilles at gravier.org Wed Aug 29 01:21:42 2018 From: gilles at gravier.org (Gilles Gravier) Date: Tue, 28 Aug 2018 17:21:42 +0200 Subject: [TUHS] Running 4.3 BSD on x86 hardware? Suggestions? In-Reply-To: References: Message-ID: Thanks Henry and Clem! I should be all set! Gilles Le mar. 28 août 2018 à 17:05, Clem Cole a écrit : > simh is the traditional way it's done. Google simh and 4.3BSD. > configure simh set it up as a 780, with RP06 or RM0[35] drives, HT tapes, > and it should pretty much just work per the BSD installation > ᐧ > > On Tue, Aug 28, 2018 at 10:54 AM Gilles Gravier > wrote: > >> Hi! >> >> If I wanted to run 4.3BSD on an x86 box (VirtualBox? QEMM? other emu?)... >> anybody has suggestions? Where can I find media for 4.3BSD (if any are >> legitimately accessible)? >> >> Or on a Raspberry Pi? :) >> >> Thanks! >> >> Gilles >> >> -- >> *Gilles Gravier* - Gilles at Gravier.org >> GSM : +33618347147 and +41794728437 >> Skype : ggravier | PGP Key : 0x8DE6D026 >> >> > -- *Gilles Gravier* - Gilles at Gravier.org GSM : +33618347147 and +41794728437 Skype : ggravier | PGP Key : 0x8DE6D026 -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Wed Aug 29 03:47:31 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Tue, 28 Aug 2018 13:47:31 -0400 Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: References: <1535123616.1824656.1485063544.08BED1A8@webmail.messagingengine.com> Message-ID: On 8/27/18, Dave Horsfall wrote: > I remember seeing a photo of that button. Somewhere (I think) I have a > PS/PDF (or was it a sticker?) of "Intel outside" which I stuck to my > SparcStation. We stuck an International House of Pancakes "Powered by Pancakes" sticker on the power supply box of our IBM mainframe. -Paul W. From dave at horsfall.org Wed Aug 29 08:33:53 2018 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 29 Aug 2018 08:33:53 +1000 (EST) Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: <201808280601.w7S61oLM030628@freefriends.org> References: <1535123616.1824656.1485063544.08BED1A8@webmail.messagingengine.com> <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> Message-ID: On Tue, 28 Aug 2018, arnold at skeeve.com wrote: > Larry McVoy wrote: [...] >> SunOS was the system that everyone used because they wanted to, Solaris >> was what people used because they had to. > > Nicely put! Signature material, in fact! I loved SunOS 4.1.4, and had to eat a shit sandwich when they went to Solaris (but continue to run BSD-like systems at home; first BSDi, then FreeBSD; the MacBook is at least vaguely BSD-ish, and the only reason that I also have Debian is to see what the penguins have broken this time). -- Dave From dave at horsfall.org Wed Aug 29 08:39:28 2018 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 29 Aug 2018 08:39:28 +1000 (EST) Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: <201808280642.w7S6gWYX002026@freefriends.org> References: <1535123616.1824656.1485063544.08BED1A8@webmail.messagingengine.com> <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <201808280642.w7S6gWYX002026@freefriends.org> Message-ID: On Tue, 28 Aug 2018, arnold at skeeve.com wrote: > But I can testify from experience at my last job that AIX, HP/UX and > Solaris are all still in heavy use at major companies, mainly hosting > big database systems, but still there and not going away too soon. Yep, that was my last job too, until I was made redundant at age 58 (ever tried to find a job at that age, having specialist skills?). -- Dave From dave at horsfall.org Wed Aug 29 09:30:00 2018 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 29 Aug 2018 09:30:00 +1000 (EST) Subject: [TUHS] Usenix: no official Unix 50th celebration, apparently In-Reply-To: References: <20180826003127.GA18905@minnie.tuhs.org> <20180826052931.GA14695@wopr> Message-ID: I know that I'll probably get into trouble for writing this (I'm a born stirrer, coming from a military family), but... On Tue, 28 Aug 2018, Kevin Bowling wrote: > This is all so asinine it sounds like it’s run by a random haughty > social club of people far detached from systems and UNIX and especially > far from publishing systems papers that actually advance the art. > Sometimes it is necessary to let an org know it’s become a joke.  I’d > prefer to attend and assist with something not affiliated with Usenix > after reading this thread. I'm having trouble thinking of an OS (still in current use) that has remained *mostly* unchanged over 50 years. Yes, Unix has certainly evolved, but is still recognisable as "do one thing, and do it well". It's just a shame that they seem to have broken the other philosophy of "everything looks like a file". -- Dave From ggm at algebras.org Wed Aug 29 09:37:51 2018 From: ggm at algebras.org (George Michaelson) Date: Wed, 29 Aug 2018 09:37:51 +1000 Subject: [TUHS] Usenix: no official Unix 50th celebration, apparently In-Reply-To: References: <20180826003127.GA18905@minnie.tuhs.org> <20180826052931.GA14695@wopr> Message-ID: sockets broke that. ioctl() always felt like special magic to me, but sockets+ioctl is not just special magic, its arcane. I think part of the problem is that a network binding actually isn't "just like a file" because it incudes things like out of order delivery, and control (side) channel. TBF, sparse files and network file systems is another place things broke down. For some reason, device-special and sparse files wound up being in the too hard basket for network mounts. I know Lindsay Marshall of old, so have a soft spot for the newcastle connections (.../mounthost/path/to/file) syntax. I always liked this. On Wed, Aug 29, 2018 at 9:30 AM Dave Horsfall wrote: > > I know that I'll probably get into trouble for writing this (I'm a born > stirrer, coming from a military family), but... > > On Tue, 28 Aug 2018, Kevin Bowling wrote: > > > This is all so asinine it sounds like it’s run by a random haughty > > social club of people far detached from systems and UNIX and especially > > far from publishing systems papers that actually advance the art. > > Sometimes it is necessary to let an org know it’s become a joke. I’d > > prefer to attend and assist with something not affiliated with Usenix > > after reading this thread. > > I'm having trouble thinking of an OS (still in current use) that has > remained *mostly* unchanged over 50 years. Yes, Unix has certainly > evolved, but is still recognisable as "do one thing, and do it well". > > It's just a shame that they seem to have broken the other philosophy of > "everything looks like a file". > > -- Dave From skogtun at gmail.com Wed Aug 29 10:36:47 2018 From: skogtun at gmail.com (Harald Arnesen) Date: Wed, 29 Aug 2018 02:36:47 +0200 Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: References: <1535123616.1824656.1485063544.08BED1A8@webmail.messagingengine.com> <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> Message-ID: Dave Horsfall [2018-08-29 00:33]: > Signature material, in fact! I loved SunOS 4.1.4, and had to eat a shit > sandwich when they went to Solaris (but continue to run BSD-like systems > at home; first BSDi, then FreeBSD; the MacBook is at least vaguely > BSD-ish, and the only reason that I also have Debian is to see what the > penguins have broken this time). So you don't think MacOS has broken more than the penguins have? -- Hilsen Harald From lm at mcvoy.com Wed Aug 29 10:46:27 2018 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 28 Aug 2018 17:46:27 -0700 Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: References: <1535123616.1824656.1485063544.08BED1A8@webmail.messagingengine.com> <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> Message-ID: <20180829004627.GG317@mcvoy.com> On Wed, Aug 29, 2018 at 02:36:47AM +0200, Harald Arnesen wrote: > Dave Horsfall [2018-08-29 00:33]: > > > Signature material, in fact! I loved SunOS 4.1.4, and had to eat a shit > > sandwich when they went to Solaris (but continue to run BSD-like systems > > at home; first BSDi, then FreeBSD; the MacBook is at least vaguely > > BSD-ish, and the only reason that I also have Debian is to see what the > > penguins have broken this time). > > So you don't think MacOS has broken more than the penguins have? MacOS is based on Mach and Mach was a big steaming mess of promises that were not so much. Easy for me to say, I haven't written a VM system from scratch and they did, so credit them for that. But I've been in a VM system that was oh so much easier to read and understand, the SunOS 4.x VM system done by Joe Moran (mojo at sun.com). That guy had crazy skills, well beyond mine or anyone else I can think of. When he quit the story is that Bill Joy stopped him in the parking lot and offered him crazy amounts of money to stay. So I'd go with MacOS is not a fun kernel. It's pretty close to BSD and I recently wandered through that VM system and I was not impressed. I wish like hell that Sun had fed their VM back to BSD. Yeah, it wasn't multi processor friendly but someone would have fixed that. The penguin stuff, it's OK. Not as clean as SunOS by a long shot. From dave at horsfall.org Wed Aug 29 11:06:05 2018 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 29 Aug 2018 11:06:05 +1000 (EST) Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: References: <1535123616.1824656.1485063544.08BED1A8@webmail.messagingengine.com> <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> Message-ID: On Wed, 29 Aug 2018, Harald Arnesen wrote: >> Signature material, in fact! I loved SunOS 4.1.4, and had to eat a >> shit sandwich when they went to Solaris (but continue to run BSD-like >> systems at home; first BSDi, then FreeBSD; the MacBook is at least >> vaguely BSD-ish, and the only reason that I also have Debian is to see >> what the penguins have broken this time). > > So you don't think MacOS has broken more than the penguins have? Stuff I write on FreeBSD pretty much works on my Mac (the latter has mo serial ports, and thus uses a dodgy USB/serial cable with an equally-dodgy driver that hangs the system to the point of requiring a *power cycle*). And vice-versa; I had to learn how to control DTR etc on a genuine serial port on the FreeBSD box (I am writing a user-level driver for a serial device). As for Penguin/OS (and trying to figure out just which header file uses which flags, when I'm using low-level Perl I/O), then forget it. What really blew my gasket is that "stty -f" on *BSD is "stty -F" on Penguin/OS, despite them copying every other flag. I had a look at how they (Linux) wrote stty.c, and nearly threw up. So, yes, that's pretty much my answer... -- Dave From tytso at mit.edu Wed Aug 29 13:23:10 2018 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Tue, 28 Aug 2018 23:23:10 -0400 Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: References: <1535123616.1824656.1485063544.08BED1A8@webmail.messagingengine.com> <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> Message-ID: <20180829032310.GF19128@thunk.org> On Wed, Aug 29, 2018 at 11:06:05AM +1000, Dave Horsfall wrote: > > What really blew my gasket is that "stty -f" on *BSD is "stty -F" on > Penguin/OS, despite them copying every other flag. I'm pretty sure the addition of "stty -f" and "stty -F" is a fairly late innovation. i.e., it wasn't there when Linux "copied" stty's user interface. In BSD 4.3 and early Linux (which is when I still was maintaining Linux's serial driver) you always had to do: stty dec < /dev/ttyS0 Really, why did those young whippersnappers had to add an option, when redirection worked perfectly well and required one less character to type? :-) - Ted From wkt at tuhs.org Wed Aug 29 14:36:39 2018 From: wkt at tuhs.org (Warren Toomey) Date: Wed, 29 Aug 2018 14:36:39 +1000 Subject: [TUHS] Cryptic Unix Commands In-Reply-To: <20180829032310.GF19128@thunk.org> References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829032310.GF19128@thunk.org> Message-ID: <20180829043639.GA6691@minnie.tuhs.org> On Tue, Aug 28, 2018 at 11:23:10PM -0400, Theodore Y. Ts'o wrote: > stty dec < /dev/ttyS0 > > Really, why did those young whippersnappers had to add an option, when > redirection worked perfectly well and required one less character to > type? :-) This reminded me of other semi-cryptic commands. I remember mistyping "kill -1 1" as "kill -9 1" with the inevitable consequences. Warren From grog at lemis.com Wed Aug 29 15:06:40 2018 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Wed, 29 Aug 2018 15:06:40 +1000 Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: <20180829032310.GF19128@thunk.org> References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829032310.GF19128@thunk.org> Message-ID: <20180829050640.GD5698@eureka.lemis.com> On Tuesday, 28 August 2018 at 23:23:10 -0400, Theodore Y. Ts'o wrote: > On Wed, Aug 29, 2018 at 11:06:05AM +1000, Dave Horsfall wrote: >> >> What really blew my gasket is that "stty -f" on *BSD is "stty -F" on >> Penguin/OS, despite them copying every other flag. > > I'm pretty sure the addition of "stty -f" and "stty -F" is a fairly > late innovation. i.e., it wasn't there when Linux "copied" stty's > user interface. > > In BSD 4.3 and early Linux (which is when I still was maintaining > Linux's serial driver) you always had to do: > > stty dec < /dev/ttyS0 Checking mckusick's source distribution, it seems that the -f option (along with sanity) came in with 4.4BSD. It was in the original sources imported into FreeBSD. 4.3BSD had such a bizarre syntax that I suspect whatever you emulated must have come from a later date. But options are an issue, notably with GNU software, which has a completely different lineage. Just look at FreeBSD ls(1) and GNU ls(1). > Really, why did those young whippersnappers had to add an option, when > redirection worked perfectly well and required one less character to > type? :-) Creeping featurism! 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 arnold at skeeve.com Wed Aug 29 15:25:22 2018 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 28 Aug 2018 23:25:22 -0600 Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: References: <1535123616.1824656.1485063544.08BED1A8@webmail.messagingengine.com> <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <201808280642.w7S6gWYX002026@freefriends.org> Message-ID: <201808290525.w7T5PMci005806@freefriends.org> Dave Horsfall wrote: > On Tue, 28 Aug 2018, arnold at skeeve.com wrote: > > > But I can testify from experience at my last job that AIX, HP/UX and > > Solaris are all still in heavy use at major companies, mainly hosting > > big database systems, but still there and not going away too soon. > > Yep, that was my last job too, until I was made redundant at age 58 (ever > tried to find a job at that age, having specialist skills?). > > -- Dave That's exactly what happened to me, at the same age. Fortunately the market where I live (Israel) is super hot for C++ / Linux developers, and I landed a job at what so far is a reasonable start-up company. ("Praise the Lord", as they say.) I hope you've found something. Arnold From arnold at skeeve.com Wed Aug 29 15:29:15 2018 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 28 Aug 2018 23:29:15 -0600 Subject: [TUHS] SunOS code? In-Reply-To: <20180829004627.GG317@mcvoy.com> References: <1535123616.1824656.1485063544.08BED1A8@webmail.messagingengine.com> <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829004627.GG317@mcvoy.com> Message-ID: <201808290529.w7T5TFKa006049@freefriends.org> Changed the subject line. Larry McVoy wrote: > So I'd go with MacOS is not a fun kernel. It's pretty close to BSD > and I recently wandered through that VM system and I was not impressed. > I wish like hell that Sun had fed their VM back to BSD. Yeah, it wasn't > multi processor friendly but someone would have fixed that. > > The penguin stuff, it's OK. Not as clean as SunOS by a long shot. So, is the SunOS code available in a way that would let people hack on it? They had ported it to 386 (roadrunner?), so maybe it'd be possible to revive it and bring it into the 21st century. Just a thought, Arnold From arrigo at alchemistowl.org Wed Aug 29 17:03:05 2018 From: arrigo at alchemistowl.org (Arrigo Triulzi) Date: Wed, 29 Aug 2018 09:03:05 +0200 Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: References: <1535123616.1824656.1485063544.08BED1A8@webmail.messagingengine.com> <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> Message-ID: On 29 Aug 2018, at 03:06, Dave Horsfall wrote: > Stuff I write on FreeBSD pretty much works on my Mac (the latter has mo serial ports, and thus uses a dodgy USB/serial cable with an equally-dodgy driver that hangs the system to the point of requiring a *power cycle*). I’m glad I’m not the only one who has infinite problems with these dongles. I have a sacred old laptop running OpenBSD precisely to get serial consoles working as a) it has an RS-232 port and b) the drivers are sane. I have a USB-serial dongle which on Mac, once the driver is installed, creates a device called /dev/cu.Bluetooth-Serial-SiLo. Took me an eternity to figure out it was that because the docs had nothing about which device file it actually created and, well, considering it is a physical cable I had eliminated Bluetooth to begin with… I confess to looking at the creation date on the device file and then saying “naah, it cannot be… oh… it is…” I do miss SunOS too - because of a single user with great powers we had to upgrade a SparcStation 10 to Solaris back in 1994 and the performance took an instant nosedive. Not to mention the hours spent getting tools to make it actually work (i.e. 99% of the GNU project). Arrigo From dave at horsfall.org Wed Aug 29 18:43:14 2018 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 29 Aug 2018 18:43:14 +1000 (EST) Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: <20180829032310.GF19128@thunk.org> References: <1535123616.1824656.1485063544.08BED1A8@webmail.messagingengine.com> <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829032310.GF19128@thunk.org> Message-ID: On Tue, 28 Aug 2018, Theodore Y. Ts'o wrote: > I'm pretty sure the addition of "stty -f" and "stty -F" is a fairly late > innovation. i.e., it wasn't there when Linux "copied" stty's user > interface. Yeah, I suppose that's it, but in true GNU style they also have "--file=/dev/XXX", so why not "-f"? > In BSD 4.3 and early Linux (which is when I still was maintaining > Linux's serial driver) you always had to do: > > stty dec < /dev/ttyS0 > > Really, why did those young whippersnappers had to add an option, when > redirection worked perfectly well and required one less character to > type? :-) Ah, but then the shell does the opening, which might not be the mode that you wanted; I was doing some funky I/O redirection at the time as well. -- Dave From schaiba at gmail.com Wed Aug 29 20:21:54 2018 From: schaiba at gmail.com (Rares Aioanei) Date: Wed, 29 Aug 2018 13:21:54 +0300 Subject: [TUHS] Running 4.3 BSD on x86 hardware? Suggestions? In-Reply-To: References: Message-ID: Hey, Link doesn't seem to work, I get "Connection reset". Can anyone else confirm? On Tue, Aug 28, 2018 at 6:15 PM Henry Bent wrote: > > On Tue, 28 Aug 2018 at 10:54, Gilles Gravier wrote: >> >> Hi! >> >> If I wanted to run 4.3BSD on an x86 box (VirtualBox? QEMM? other emu?)... anybody has suggestions? Where can I find media for 4.3BSD (if any are legitimately accessible)? >> >> Or on a Raspberry Pi? :) >> >> Thanks! >> >> Gilles >> >> > > There are full instructions using SIMH here: http://gunkies.org/wiki/Installing_4.3_BSD_on_SIMH > > -Henry > -- Rares Aioanei From gilles at gravier.org Wed Aug 29 20:27:53 2018 From: gilles at gravier.org (Gilles Gravier) Date: Wed, 29 Aug 2018 12:27:53 +0200 Subject: [TUHS] Running 4.3 BSD on x86 hardware? Suggestions? In-Reply-To: References: Message-ID: Works from my cell phone and my PC. Maybe temporarily slashdotted? 😎 Gilles On Wed 29 Aug 2018, 12:22 Rares Aioanei, wrote: > Hey, > > Link doesn't seem to work, I get "Connection reset". Can anyone else > confirm? > On Tue, Aug 28, 2018 at 6:15 PM Henry Bent wrote: > > > > On Tue, 28 Aug 2018 at 10:54, Gilles Gravier wrote: > >> > >> Hi! > >> > >> If I wanted to run 4.3BSD on an x86 box (VirtualBox? QEMM? other > emu?)... anybody has suggestions? Where can I find media for 4.3BSD (if any > are legitimately accessible)? > >> > >> Or on a Raspberry Pi? :) > >> > >> Thanks! > >> > >> Gilles > >> > >> > > > > There are full instructions using SIMH here: > http://gunkies.org/wiki/Installing_4.3_BSD_on_SIMH > > > > -Henry > > > > > -- > Rares Aioanei > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Wed Aug 29 22:23:55 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 29 Aug 2018 08:23:55 -0400 (EDT) Subject: [TUHS] Running 4.3 BSD on x86 hardware? Suggestions? Message-ID: <20180829122355.EF20918C08E@mercury.lcs.mit.edu> > From: Rares Aioanei > Link doesn't seem to work, I get "Connection reset". Which link - the gunkies.org (Computer History Wiki) one? It's working for me at the moment. Does your browser accepts non-HTTPS URLs? (There's apparently a craze on to denigrate them at the moment.) Noel From schaiba at gmail.com Wed Aug 29 22:45:40 2018 From: schaiba at gmail.com (Rares Aioanei) Date: Wed, 29 Aug 2018 15:45:40 +0300 Subject: [TUHS] Running 4.3 BSD on x86 hardware? Suggestions? In-Reply-To: <20180829122355.EF20918C08E@mercury.lcs.mit.edu> References: <20180829122355.EF20918C08E@mercury.lcs.mit.edu> Message-ID: gunkies.org works. The URL for getting the sets doesn't (http://unix-archive.huihoo.org/4BSD/Distributions/4.2BSD/) On Wed, Aug 29, 2018 at 3:23 PM Noel Chiappa wrote: > > > From: Rares Aioanei > > > Link doesn't seem to work, I get "Connection reset". > > Which link - the gunkies.org (Computer History Wiki) one? > > It's working for me at the moment. > > Does your browser accepts non-HTTPS URLs? (There's apparently a craze on > to denigrate them at the moment.) > > Noel -- Rares Aioanei From jnc at mercury.lcs.mit.edu Wed Aug 29 23:11:13 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 29 Aug 2018 09:11:13 -0400 (EDT) Subject: [TUHS] Running 4.3 BSD on x86 hardware? Suggestions? Message-ID: <20180829131113.D4D9C18C08E@mercury.lcs.mit.edu> > From: Rares Aioanei > gunkies.org works. The URL for getting the sets doesn't Ah, OK. Link-rot; sigh. The bane of the Web! If someone can provide a working alternative for you to use, I'll update the page as well. Noel From clemc at ccc.com Wed Aug 29 23:28:37 2018 From: clemc at ccc.com (Clem Cole) Date: Wed, 29 Aug 2018 09:28:37 -0400 Subject: [TUHS] Running 4.3 BSD on x86 hardware? Suggestions? In-Reply-To: <20180829131113.D4D9C18C08E@mercury.lcs.mit.edu> References: <20180829131113.D4D9C18C08E@mercury.lcs.mit.edu> Message-ID: https://www.tuhs.org/Archive/Distributions/UCB/4.2BSD/ ᐧ On Wed, Aug 29, 2018 at 9:11 AM Noel Chiappa wrote: > > From: Rares Aioanei > > > gunkies.org works. The URL for getting the sets doesn't > > Ah, OK. > > Link-rot; sigh. The bane of the Web! > > If someone can provide a working alternative for you to use, I'll update > the > page as well. > > Noel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pechter at gmail.com Wed Aug 29 23:46:40 2018 From: pechter at gmail.com (William Pechter) Date: Wed, 29 Aug 2018 09:46:40 -0400 Subject: [TUHS] Running 4.3 BSD on x86 hardware? Suggestions? In-Reply-To: References: <20180829131113.D4D9C18C08E@mercury.lcs.mit.edu> Message-ID: <08e8ad39-1309-4947-ae8e-d10552416eaf.maildroid@localhost> Just a plug for the 4.3+University of Wisconsin version on Simh. You can build some of the more recent tools on it... Also... If you run on the internet remember documented security exploits are decades old. I recommend no open ports except for ssh if it will build and maybe UUCP. Bill -----Original Message----- From: Clem Cole To: Noel Chiappa Cc: The Eunuchs Hysterical Society Sent: Wed, 29 Aug 2018 9:29 Subject: Re: [TUHS] Running 4.3 BSD on x86 hardware? Suggestions? https://www.tuhs.org/Archive/Distributions/UCB/4.2BSD/ ᐧ On Wed, Aug 29, 2018 at 9:11 AM Noel Chiappa wrote: > > From: Rares Aioanei > > > gunkies.org works. The URL for getting the sets doesn't > > Ah, OK. > > Link-rot; sigh. The bane of the Web! > > If someone can provide a working alternative for you to use, I'll update > the > page as well. > > Noel > From jnc at mercury.lcs.mit.edu Wed Aug 29 23:56:53 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 29 Aug 2018 09:56:53 -0400 (EDT) Subject: [TUHS] Running 4.3 BSD on x86 hardware? Suggestions? Message-ID: <20180829135653.2276818C08E@mercury.lcs.mit.edu> > From: Noel Chiappa > I'll update the page as well. I have to do it since, after severe issues with spam, a login is required to make changes. If anyone is interested in adding content (please, we need more in just about every area - I've done a lot of PDP-11's, but that's a fairly small corner overall :-), please drop me a short line, and I'll set you up (just let me know the account name you want, and what email address to associate with it). > From: William Pechter > Just a plug for the 4.3+University of Wisconsin version on Simh. I don't think I see that in the TUHS repository that Clem just pointed to? Got a URL? Any chance I can convince you to add a bit of content about it? :-) Noel From clemc at ccc.com Thu Aug 30 00:25:12 2018 From: clemc at ccc.com (Clem Cole) Date: Wed, 29 Aug 2018 10:25:12 -0400 Subject: [TUHS] cat -v and other complaints Message-ID: On Wed, Aug 29, 2018 at 1:07 AM Greg 'groggy' Lehey wrote: > On Tuesday, 28 August 2018 at 23:23:10 -0400, Theodore Y. Ts'o wrote: > > On Wed, Aug 29, 2018 at 11:06:05AM +1000, Dave Horsfall wrote: > .... > > > Creeping featurism! > No, I think its really is that many programmers that touch different applications felt the need to pee on the code to feel that they left their scent. 😘 Seriously, IMO the problem is you can never know what someone else really values, so be careful at what you change. Pike's 'cat -v' dissertation b*tched at UCB for the some of the same issues. Somewhere there is a proper middle ground ( I think of as having good taste elegance). BSD nor Linux was no more 'perfect' that 6th or 7th edition. Truth is a much as I pine for the elegance, I don't want to run either of the later as my day-2-day system in today's world and I >>loved<< running them when they were what I had. Rob has a real point and many of the changes really *are gratuitous* and there *are better ways of doing* many things than adding a switch to old command and reusing it because you can. I also think the complaint of just adding 'crap' because you could started with BSD but the cause wasn't that people were bad -- there was address space relief over the PDP-11 and often added a new switch/new functionality was easy to do, instead of creating a whole new solution just deidcated to that problen only. FWIW: sendmail is my best example (useful tool that it was - there were/are much more elegant solutions - sendmail should have been 'headerwriter' and smtpd should have been a seperate program). Dueling switches and functionality (dec vs -f bs -F) I fear is sometimes ignorance of the past. I fear there is some sort of belief we need to shed the past because someone feeld the it gets in the way of the future (I'll pick on my on son here - who things 2-3 years is 'old' and its time to throw things away). Truth is sometimes it might. But I would rather inject a stronger strain into the mix and let the users decide and for good or bad, BSD did that to the original (v6/v7) and now Linux is doing/has done it to much of BSD. The compaint is the 'throwing the baby out with the bath water' behavior that seems to often follow (see systemd issues on other mailing lists); *i.e*. did you really gain something for this huge disruption. To me when something really new/a great innovation comes that should be celebrated. BSD gave us VM and a number of 'useful' new utilities, and eventually an networking API (al biet not everyone liked it, sockets was good enough, solved the problems and became a standard that allowed us to move on). Mach (while Larry may not like the VM implementation), moved the bar for the kernel's handling of memory a huge amount and almost won the uK war (which IMO was a too bad). BTW: other kernels would do nice VM's too, but Mach was generally available (open source if you will and really was the system the moived it forward). That said, I give the Linux folks great credit for the addition of modules was huge and it took BSD and the other UNIX systems a few years really pick up that idea in the same way (yes Solaris, Tru64 and eventually HPUX etc.. had something too but again - my comment about being generally available applies). So here is the issue, how to do move the ball forward? BSD, then Linux, became the 'stronger strain' and pushed out the old version. The problem is the ROMs in my fingers (like Dave) never got reprogrammed so some of the 'new' becomes annoying. Will I learned to like systemd? We shall see... Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Thu Aug 30 00:25:48 2018 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Wed, 29 Aug 2018 10:25:48 -0400 Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: <20180829050640.GD5698@eureka.lemis.com> References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829032310.GF19128@thunk.org> <20180829050640.GD5698@eureka.lemis.com> Message-ID: <20180829142548.GH19128@thunk.org> On Wed, Aug 29, 2018 at 03:06:40PM +1000, Greg 'groggy' Lehey wrote: > > In BSD 4.3 and early Linux (which is when I still was maintaining > > Linux's serial driver) you always had to do: > > > > stty dec < /dev/ttyS0 > > Checking mckusick's source distribution, it seems that the -f option > (along with sanity) came in with 4.4BSD. It was in the original > sources imported into FreeBSD. 4.3BSD had such a bizarre syntax that > I suspect whatever you emulated must have come from a later date. BSD 4.4 Lite was released in 1994. (Lite2 was released in 1995.) Linux was started in 1991, and we had a stty from very early on --- by 1992 at the latest. Most of the Linux kernel developers from those early days cut their teeth on BSD 4.3 and BSD 4.3 Reno, and were unwillingly frog-marched from Sun OS 4.x to Slowlaris 2.x, and from IBM AOS (which was also BSD 4.3 based) to IBM AIX (thanks, AT&T) in their day jobs. - Ted From lm at mcvoy.com Thu Aug 30 00:40:37 2018 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 29 Aug 2018 07:40:37 -0700 Subject: [TUHS] SunOS code? In-Reply-To: <201808290529.w7T5TFKa006049@freefriends.org> References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829004627.GG317@mcvoy.com> <201808290529.w7T5TFKa006049@freefriends.org> Message-ID: <20180829144037.GO317@mcvoy.com> Sun never open sourced it. On Tue, Aug 28, 2018 at 11:29:15PM -0600, arnold at skeeve.com wrote: > Changed the subject line. > > Larry McVoy wrote: > > > So I'd go with MacOS is not a fun kernel. It's pretty close to BSD > > and I recently wandered through that VM system and I was not impressed. > > I wish like hell that Sun had fed their VM back to BSD. Yeah, it wasn't > > multi processor friendly but someone would have fixed that. > > > > The penguin stuff, it's OK. Not as clean as SunOS by a long shot. > > So, is the SunOS code available in a way that would let people hack > on it? They had ported it to 386 (roadrunner?), so maybe it'd be > possible to revive it and bring it into the 21st century. > > Just a thought, > > Arnold -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From crossd at gmail.com Thu Aug 30 00:41:02 2018 From: crossd at gmail.com (Dan Cross) Date: Wed, 29 Aug 2018 10:41:02 -0400 Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: <20180829142548.GH19128@thunk.org> References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829032310.GF19128@thunk.org> <20180829050640.GD5698@eureka.lemis.com> <20180829142548.GH19128@thunk.org> Message-ID: On Wed, Aug 29, 2018 at 10:26 AM Theodore Y. Ts'o wrote: > On Wed, Aug 29, 2018 at 03:06:40PM +1000, Greg 'groggy' Lehey wrote: > > > In BSD 4.3 and early Linux (which is when I still was maintaining > > > Linux's serial driver) you always had to do: > > > > > > stty dec < /dev/ttyS0 > > > > Checking mckusick's source distribution, it seems that the -f option > > (along with sanity) came in with 4.4BSD. It was in the original > > sources imported into FreeBSD. 4.3BSD had such a bizarre syntax that > > I suspect whatever you emulated must have come from a later date. > > BSD 4.4 Lite was released in 1994. (Lite2 was released in 1995.) > > Linux was started in 1991, and we had a stty from very early on --- by > 1992 at the latest. > I think that Greg is slightly mistaken; `stty` had `-f` documented in Net/2 (1991, though of course the entanglements there have been discussed), but the option existed in Reno (1990, though it seems to be absent from the man page). Most of the Linux kernel developers from those early days cut their > teeth on BSD 4.3 and BSD 4.3 Reno, and were unwillingly frog-marched > from Sun OS 4.x to Slowlaris 2.x, and from IBM AOS (which was also BSD > 4.3 based) to IBM AIX (thanks, AT&T) in their day jobs. > I'm curious who was using AOS, which was essentially Tahoe+NFS. "Frog-marched" is an apt description of the forced migration from SunOS to Solaris. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Thu Aug 30 00:41:45 2018 From: crossd at gmail.com (Dan Cross) Date: Wed, 29 Aug 2018 10:41:45 -0400 Subject: [TUHS] SunOS code? In-Reply-To: <20180829144037.GO317@mcvoy.com> References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829004627.GG317@mcvoy.com> <201808290529.w7T5TFKa006049@freefriends.org> <20180829144037.GO317@mcvoy.com> Message-ID: I wonder if they would consider doing it now. Oracle, I mean; the Solaris code was opened up and an argument could be made that SunOS would be useful for historical examination. On Wed, Aug 29, 2018 at 10:41 AM Larry McVoy wrote: > Sun never open sourced it. > > On Tue, Aug 28, 2018 at 11:29:15PM -0600, arnold at skeeve.com wrote: > > Changed the subject line. > > > > Larry McVoy wrote: > > > > > So I'd go with MacOS is not a fun kernel. It's pretty close to BSD > > > and I recently wandered through that VM system and I was not impressed. > > > I wish like hell that Sun had fed their VM back to BSD. Yeah, it > wasn't > > > multi processor friendly but someone would have fixed that. > > > > > > The penguin stuff, it's OK. Not as clean as SunOS by a long shot. > > > > So, is the SunOS code available in a way that would let people hack > > on it? They had ported it to 386 (roadrunner?), so maybe it'd be > > possible to revive it and bring it into the 21st century. > > > > Just a thought, > > > > Arnold > > -- > --- > Larry McVoy lm at mcvoy.com > http://www.mcvoy.com/lm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Thu Aug 30 00:43:09 2018 From: imp at bsdimp.com (Warner Losh) Date: Wed, 29 Aug 2018 08:43:09 -0600 Subject: [TUHS] SunOS code? In-Reply-To: <201808290529.w7T5TFKa006049@freefriends.org> References: <1535123616.1824656.1485063544.08BED1A8@webmail.messagingengine.com> <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829004627.GG317@mcvoy.com> <201808290529.w7T5TFKa006049@freefriends.org> Message-ID: On Tue, Aug 28, 2018 at 11:29 PM wrote: > Changed the subject line. > > Larry McVoy wrote: > > > So I'd go with MacOS is not a fun kernel. It's pretty close to BSD > > and I recently wandered through that VM system and I was not impressed. > > I wish like hell that Sun had fed their VM back to BSD. Yeah, it wasn't > > multi processor friendly but someone would have fixed that. > > > > The penguin stuff, it's OK. Not as clean as SunOS by a long shot. > > So, is the SunOS code available in a way that would let people hack > on it? They had ported it to 386 (roadrunner?), so maybe it'd be > possible to revive it and bring it into the 21st century. > The Googles tells me there's a dozen download places. SunOS 4.1 doesn't have 386 support in it. It was removed after SunOS 4.0. The Sun RoadRunner wasn't really IBM PC compatible. It had a fair number of incompatible bits included in it. It also had a weird BIOS. There's a lot that's happened in x86 since then. It's unclear how much benefit there would be to having the sources. It looks like you'd be much better off starting with one of the latter-day BSD implementations to do the port, though significant differences exist with the infrastructure so it would be far from a drop-in. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From pechter at gmail.com Thu Aug 30 00:44:37 2018 From: pechter at gmail.com (William Pechter) Date: Wed, 29 Aug 2018 10:44:37 -0400 Subject: [TUHS] SunOS code? In-Reply-To: References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829004627.GG317@mcvoy.com> <201808290529.w7T5TFKa006049@freefriends.org> <20180829144037.GO317@mcvoy.com> Message-ID: Didn't they un-open Solaris 11? -----Original Message----- From: Dan Cross To: Larry McVoy Cc: TUHS main list Sent: Wed, 29 Aug 2018 10:42 Subject: Re: [TUHS] SunOS code? I wonder if they would consider doing it now. Oracle, I mean; the Solaris code was opened up and an argument could be made that SunOS would be useful for historical examination. On Wed, Aug 29, 2018 at 10:41 AM Larry McVoy wrote: > Sun never open sourced it. > > On Tue, Aug 28, 2018 at 11:29:15PM -0600, arnold at skeeve.com wrote: > > Changed the subject line. > > > > Larry McVoy wrote: > > > > > So I'd go with MacOS is not a fun kernel. It's pretty close to BSD > > > and I recently wandered through that VM system and I was not impressed. > > > I wish like hell that Sun had fed their VM back to BSD. Yeah, it > wasn't > > > multi processor friendly but someone would have fixed that. > > > > > > The penguin stuff, it's OK. Not as clean as SunOS by a long shot. > > > > So, is the SunOS code available in a way that would let people hack > > on it? They had ported it to 386 (roadrunner?), so maybe it'd be > > possible to revive it and bring it into the 21st century. > > > > Just a thought, > > > > Arnold > > -- > --- > Larry McVoy lm at mcvoy.com > http://www.mcvoy.com/lm > From imp at bsdimp.com Thu Aug 30 00:45:31 2018 From: imp at bsdimp.com (Warner Losh) Date: Wed, 29 Aug 2018 08:45:31 -0600 Subject: [TUHS] SunOS code? In-Reply-To: References: <1535123616.1824656.1485063544.08BED1A8@webmail.messagingengine.com> <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829004627.GG317@mcvoy.com> <201808290529.w7T5TFKa006049@freefriends.org> Message-ID: On Wed, Aug 29, 2018 at 8:43 AM Warner Losh wrote: > > > On Tue, Aug 28, 2018 at 11:29 PM wrote: > >> Changed the subject line. >> >> Larry McVoy wrote: >> >> > So I'd go with MacOS is not a fun kernel. It's pretty close to BSD >> > and I recently wandered through that VM system and I was not impressed. >> > I wish like hell that Sun had fed their VM back to BSD. Yeah, it wasn't >> > multi processor friendly but someone would have fixed that. >> > >> > The penguin stuff, it's OK. Not as clean as SunOS by a long shot. >> >> So, is the SunOS code available in a way that would let people hack >> on it? They had ported it to 386 (roadrunner?), so maybe it'd be >> possible to revive it and bring it into the 21st century. >> > > The Googles tells me there's a dozen download places. > > SunOS 4.1 doesn't have 386 support in it. It was removed after SunOS 4.0. > The Sun RoadRunner wasn't really IBM PC compatible. It had a fair number of > incompatible bits included in it. It also had a weird BIOS. > > There's a lot that's happened in x86 since then. It's unclear how much > benefit there would be to having the sources. It looks like you'd be much > better off starting with one of the latter-day BSD implementations to do > the port, though significant differences exist with the infrastructure so > it would be far from a drop-in. > Also, a huge difference is that there's *NO* MP support for SunOS. Solbourne produced OS/MP which was SunOS with fine-grained locking added (I forget the degree to which it was, but IIRC, there were 'funnels' that used locks around the different subsystems (so not one big giant lock), not fine-grained in the sense we use it today. *THAT* source is harder to find online... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Aug 30 00:45:52 2018 From: clemc at ccc.com (Clem Cole) Date: Wed, 29 Aug 2018 10:45:52 -0400 Subject: [TUHS] SunOS code? In-Reply-To: References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829004627.GG317@mcvoy.com> <201808290529.w7T5TFKa006049@freefriends.org> <20180829144037.GO317@mcvoy.com> Message-ID: The problem is finding some at Oracle that would care and finding a proper distribution tape to officially release. On Wed, Aug 29, 2018 at 10:42 AM Dan Cross wrote: > I wonder if they would consider doing it now. Oracle, I mean; the Solaris > code was opened up and an argument could be made that SunOS would be useful > for historical examination. > > On Wed, Aug 29, 2018 at 10:41 AM Larry McVoy wrote: > >> Sun never open sourced it. >> >> On Tue, Aug 28, 2018 at 11:29:15PM -0600, arnold at skeeve.com wrote: >> > Changed the subject line. >> > >> > Larry McVoy wrote: >> > >> > > So I'd go with MacOS is not a fun kernel. It's pretty close to BSD >> > > and I recently wandered through that VM system and I was not >> impressed. >> > > I wish like hell that Sun had fed their VM back to BSD. Yeah, it >> wasn't >> > > multi processor friendly but someone would have fixed that. >> > > >> > > The penguin stuff, it's OK. Not as clean as SunOS by a long shot. >> > >> > So, is the SunOS code available in a way that would let people hack >> > on it? They had ported it to 386 (roadrunner?), so maybe it'd be >> > possible to revive it and bring it into the 21st century. >> > >> > Just a thought, >> > >> > Arnold >> >> -- >> --- >> Larry McVoy lm at mcvoy.com >> http://www.mcvoy.com/lm >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Thu Aug 30 00:46:04 2018 From: imp at bsdimp.com (Warner Losh) Date: Wed, 29 Aug 2018 08:46:04 -0600 Subject: [TUHS] SunOS code? In-Reply-To: References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829004627.GG317@mcvoy.com> <201808290529.w7T5TFKa006049@freefriends.org> <20180829144037.GO317@mcvoy.com> Message-ID: They didn't release the sources to Solaris 11. Anything released prior, though, remains free. Warner On Wed, Aug 29, 2018 at 8:44 AM William Pechter wrote: > Didn't they un-open Solaris 11? > > -----Original Message----- > From: Dan Cross > To: Larry McVoy > Cc: TUHS main list > Sent: Wed, 29 Aug 2018 10:42 > Subject: Re: [TUHS] SunOS code? > > I wonder if they would consider doing it now. Oracle, I mean; the Solaris > code was opened up and an argument could be made that SunOS would be useful > for historical examination. > > On Wed, Aug 29, 2018 at 10:41 AM Larry McVoy wrote: > > > Sun never open sourced it. > > > > On Tue, Aug 28, 2018 at 11:29:15PM -0600, arnold at skeeve.com wrote: > > > Changed the subject line. > > > > > > Larry McVoy wrote: > > > > > > > So I'd go with MacOS is not a fun kernel. It's pretty close to BSD > > > > and I recently wandered through that VM system and I was not > impressed. > > > > I wish like hell that Sun had fed their VM back to BSD. Yeah, it > > wasn't > > > > multi processor friendly but someone would have fixed that. > > > > > > > > The penguin stuff, it's OK. Not as clean as SunOS by a long shot. > > > > > > So, is the SunOS code available in a way that would let people hack > > > on it? They had ported it to 386 (roadrunner?), so maybe it'd be > > > possible to revive it and bring it into the 21st century. > > > > > > Just a thought, > > > > > > Arnold > > > > -- > > --- > > Larry McVoy lm at mcvoy.com > > http://www.mcvoy.com/lm > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Thu Aug 30 00:53:00 2018 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 29 Aug 2018 07:53:00 -0700 Subject: [TUHS] SunOS code? In-Reply-To: References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829004627.GG317@mcvoy.com> <201808290529.w7T5TFKa006049@freefriends.org> Message-ID: <20180829145300.GP317@mcvoy.com> On Wed, Aug 29, 2018 at 08:43:09AM -0600, Warner Losh wrote: > On Tue, Aug 28, 2018 at 11:29 PM wrote: > > > Changed the subject line. > > > > Larry McVoy wrote: > > > > > So I'd go with MacOS is not a fun kernel. It's pretty close to BSD > > > and I recently wandered through that VM system and I was not impressed. > > > I wish like hell that Sun had fed their VM back to BSD. Yeah, it wasn't > > > multi processor friendly but someone would have fixed that. > > > > > > The penguin stuff, it's OK. Not as clean as SunOS by a long shot. > > > > So, is the SunOS code available in a way that would let people hack > > on it? They had ported it to 386 (roadrunner?), so maybe it'd be > > possible to revive it and bring it into the 21st century. > > > > The Googles tells me there's a dozen download places. > > SunOS 4.1 doesn't have 386 support in it. It was removed after SunOS 4.0. > The Sun RoadRunner wasn't really IBM PC compatible. It had a fair number of > incompatible bits included in it. It also had a weird BIOS. > > There's a lot that's happened in x86 since then. It's unclear how much > benefit there would be to having the sources. It looks like you'd be much > better off starting with one of the latter-day BSD implementations to do > the port, though significant differences exist with the infrastructure so > it would be far from a drop-in. The BSDs have a less than optimal VM system. Having SunOS opened up would at least let people see what they are missing. Maybe I have rose colored glasses on but it was the only kernel that came into focus for me and you could see the architecture from the code. Everything else seems like a mess to me. From chet.ramey at case.edu Thu Aug 30 00:50:48 2018 From: chet.ramey at case.edu (Chet Ramey) Date: Wed, 29 Aug 2018 10:50:48 -0400 Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829032310.GF19128@thunk.org> <20180829050640.GD5698@eureka.lemis.com> <20180829142548.GH19128@thunk.org> Message-ID: On 8/29/18 10:41 AM, Dan Cross wrote: > I'm curious who was using AOS, which was essentially Tahoe+NFS. I was. We used it for a number of things at CWRU, and I used it personally on old IBM workstations. I wrote a considerable portion of bash-2.0 on an AOS machine in my old house, and my wife used it (plus an APA-style troff macro package I wrote) to write her doctoral thesis. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From lm at mcvoy.com Thu Aug 30 00:59:41 2018 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 29 Aug 2018 07:59:41 -0700 Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829032310.GF19128@thunk.org> <20180829050640.GD5698@eureka.lemis.com> <20180829142548.GH19128@thunk.org> Message-ID: <20180829145941.GR317@mcvoy.com> On Wed, Aug 29, 2018 at 10:50:48AM -0400, Chet Ramey wrote: > On 8/29/18 10:41 AM, Dan Cross wrote: > > > I'm curious who was using AOS, which was essentially Tahoe+NFS. > > I was. We used it for a number of things at CWRU, and I used it personally > on old IBM workstations. I wrote a considerable portion of bash-2.0 on an > AOS machine in my old house, and my wife used it (plus an APA-style troff > macro package I wrote) to write her doctoral thesis. I believe Wisconsin did the NFS stuff for that OS, as I was coming up to speed I noticed a bunch of IBM work stations and I think they were running AOS. Wisconsin was quite the hacker school back then, mojo came from there, so did Rusty and a bunch of the kernel hackers that were a few years ahead of me. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From chet.ramey at case.edu Thu Aug 30 01:08:39 2018 From: chet.ramey at case.edu (Chet Ramey) Date: Wed, 29 Aug 2018 11:08:39 -0400 Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: <20180829145941.GR317@mcvoy.com> References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829032310.GF19128@thunk.org> <20180829050640.GD5698@eureka.lemis.com> <20180829142548.GH19128@thunk.org> <20180829145941.GR317@mcvoy.com> Message-ID: <1875e414-fdc9-dc16-4908-23d4dadec37a@case.edu> On 8/29/18 10:59 AM, Larry McVoy wrote: > On Wed, Aug 29, 2018 at 10:50:48AM -0400, Chet Ramey wrote: >> On 8/29/18 10:41 AM, Dan Cross wrote: >> >>> I'm curious who was using AOS, which was essentially Tahoe+NFS. >> >> I was. We used it for a number of things at CWRU, and I used it personally >> on old IBM workstations. I wrote a considerable portion of bash-2.0 on an >> AOS machine in my old house, and my wife used it (plus an APA-style troff >> macro package I wrote) to write her doctoral thesis. > > I believe Wisconsin did the NFS stuff for that OS, as I was coming up > to speed I noticed a bunch of IBM work stations and I think they were > running AOS. Wisconsin was quite the hacker school back then, mojo came > from there, so did Rusty and a bunch of the kernel hackers that were a > few years ahead of me. Yep, they did. I maintained a custom kernel version for quite a long time, but that computer is not one of the things that came along when we moved. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From reed at reedmedia.net Thu Aug 30 02:13:32 2018 From: reed at reedmedia.net (Jeremy C. Reed) Date: Wed, 29 Aug 2018 11:13:32 -0500 (CDT) Subject: [TUHS] Cryptic Unix Commands In-Reply-To: <20180829043639.GA6691@minnie.tuhs.org> References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829032310.GF19128@thunk.org> <20180829043639.GA6691@minnie.tuhs.org> Message-ID: On Wed, 29 Aug 2018, Warren Toomey wrote: > This reminded me of other semi-cryptic commands. I remember mistyping > "kill -1 1" as "kill -9 1" with the inevitable consequences. Last week I typed "crontab -" (missed the "e" for -e) and then without realizing what happened Ctrl-C didn't work, typed Ctrl-D. Argh. Lost around 20 crontabs which were in a directory I didn't backup. Luckily I had a syslog file with my recent jobs to recreate it, but lost all my comments and commented-out entries (for over ten years). From arno.griffioen at ieee.org Thu Aug 30 03:14:46 2018 From: arno.griffioen at ieee.org (Arno Griffioen) Date: Wed, 29 Aug 2018 19:14:46 +0200 Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829032310.GF19128@thunk.org> <20180829050640.GD5698@eureka.lemis.com> <20180829142548.GH19128@thunk.org> Message-ID: <20180829171446.GB16716@ancienthardware.org> On Wed, Aug 29, 2018 at 10:41:02AM -0400, Dan Cross wrote: > I'm curious who was using AOS, which was essentially Tahoe+NFS. Used it for several years, but on IBM 6151 RT machines and not RS/6000's. The ROMP CPU in the RT's was a bit of an oddball, but fun to play with using an assembler :) Like many IBM's from the era they had fantastic keyboards though! Bye, Arno. From tytso at mit.edu Thu Aug 30 03:28:06 2018 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Wed, 29 Aug 2018 13:28:06 -0400 Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829032310.GF19128@thunk.org> <20180829050640.GD5698@eureka.lemis.com> <20180829142548.GH19128@thunk.org> Message-ID: <20180829172806.GJ19128@thunk.org> On Wed, Aug 29, 2018 at 10:41:02AM -0400, Dan Cross wrote: > > I'm curious who was using AOS, which was essentially Tahoe+NFS. > "Frog-marched" is an apt description of the forced migration from SunOS to > Solaris. AOS was used by MIT's Project Athena. DEC and IBM both contributed $5 million/year in staff or equipment, while MIT contributed $2 million/year. So Athena was funded at $12 million for five years, which was later extended by another 3 years. Initially the DEC and IBM equipment was running on BSD 4.3/4.3 Tahoe. DEC later moved us to Ultrix, and IBM to AIX (sigh). Sun equipment was later added to the mix (purchased and funded by MIT). - Ted From gtaylor at tnetconsulting.net Thu Aug 30 03:25:28 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 29 Aug 2018 11:25:28 -0600 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= Message-ID: On 08/29/2018 07:46 AM, William Pechter wrote: > Also... If you run on the internet remember documented security exploits > are decades old. I recommend no open ports except for ssh if it will > build and maybe UUCP. I'm working on a Retro Computing Networking project with a few other people and I think it would be a benefit for things like running 4.3 BSD and other old OSs in a relatively safe environment. I'm bringing this up on TUSH for two reasons: 1) I think THUS members could benefit from RetroNet 2) I (we) would very much appreciate any suggestions or desires that the THUS community would like to see in such a network. The idea behind RetroNet is two fold: 1) Create a network of interconnected VPNs between interested parties. 2) Provide ISP like services over said interconnections. Our hopes are for RetroNet to be able to provide a sandbox / small pool / isolated network where members can interconnect with each other (if they want to) similar to the Internet, but with much less exposure. (We are planing on RetroNet not having direct Internet connectivity.) We are also hoping and planing to be able to carry any Ethernet based traffic between sites, routed or not. I (we) would be very interested in any input that THUS members might be able to provide. Particularly what you might like to see in such a network. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From andreas.hein at berlan.de Thu Aug 30 03:49:01 2018 From: andreas.hein at berlan.de (Andreas Hein) Date: Wed, 29 Aug 2018 19:49:01 +0200 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: References: Message-ID: <1F62F4D0-7AD1-43C2-A9B7-CF9DF239C3D9@berlan.de> Am 29. August 2018 19:25:28 MESZ schrieb Grant Taylor via TUHS : >On 08/29/2018 07:46 AM, William Pechter wrote: >> Also... If you run on the internet remember documented security >exploits >> are decades old. I recommend no open ports except for ssh if it will > >> build and maybe UUCP. > >I'm working on a Retro Computing Networking project with a few other >people and I think it would be a benefit for things like running 4.3 >BSD >and other old OSs in a relatively safe environment. > >I'm bringing this up on TUSH for two reasons: > >1) I think THUS members could benefit from RetroNet >2) I (we) would very much appreciate any suggestions or desires that >the THUS community would like to see in such a network. > >The idea behind RetroNet is two fold: > >1) Create a network of interconnected VPNs between interested parties. >2) Provide ISP like services over said interconnections. > >Our hopes are for RetroNet to be able to provide a sandbox / small pool > >/ isolated network where members can interconnect with each other (if >they want to) similar to the Internet, but with much less exposure. >(We >are planing on RetroNet not having direct Internet connectivity.) We >are also hoping and planing to be able to carry any Ethernet based >traffic between sites, routed or not. > >I (we) would be very interested in any input that THUS members might be > >able to provide. Particularly what you might like to see in such a >network. Nice idea if UUCP is an option? Now dreaming about the 'internet' i used where i started with UNIX (1985) KR, Andreas From gtaylor at tnetconsulting.net Thu Aug 30 04:05:45 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 29 Aug 2018 12:05:45 -0600 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: <1F62F4D0-7AD1-43C2-A9B7-CF9DF239C3D9@berlan.de> References: <1F62F4D0-7AD1-43C2-A9B7-CF9DF239C3D9@berlan.de> Message-ID: On 08/29/2018 11:49 AM, Andreas Hein wrote: > Nice idea if UUCP is an option? Now dreaming about the 'internet' i used > where i started with UNIX (1985) We have been discussing UUCP options. The short list is: · UUCP over SSH · UUCP over TCP (is there an encrypted UUCP over TCP+SSL?) · UUCP bag files transferred some other means. · UUCP over some sort of emulated serial connection If you have other ideas, I'd love to hear them. I expect that we will be talking about an email gateway at some point if people are interested. We already have a Usenet feed that we will be making available via NNTP and UUCP. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From web at loomcom.com Thu Aug 30 04:04:58 2018 From: web at loomcom.com (Seth Morabito) Date: Wed, 29 Aug 2018 11:04:58 -0700 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: References: Message-ID: <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com> On Wed, Aug 29, 2018, at 10:25 AM, Grant Taylor via TUHS wrote: > On 08/29/2018 07:46 AM, William Pechter wrote: > > Also... If you run on the internet remember documented security exploits > > are decades old. I recommend no open ports except for ssh if it will > > build and maybe UUCP. > > I'm working on a Retro Computing Networking project with a few other > people and I think it would be a benefit for things like running 4.3 BSD > and other old OSs in a relatively safe environment. > > I'm bringing this up on TUSH for two reasons: > > 1) I think THUS members could benefit from RetroNet > 2) I (we) would very much appreciate any suggestions or desires that > the THUS community would like to see in such a network. > > The idea behind RetroNet is two fold: > > 1) Create a network of interconnected VPNs between interested parties. > 2) Provide ISP like services over said interconnections. > > Our hopes are for RetroNet to be able to provide a sandbox / small pool > / isolated network where members can interconnect with each other (if > they want to) similar to the Internet, but with much less exposure. (We > are planing on RetroNet not having direct Internet connectivity.) We > are also hoping and planing to be able to carry any Ethernet based > traffic between sites, routed or not. > > I (we) would be very interested in any input that THUS members might be > able to provide. Particularly what you might like to see in such a network. Hmm. I hate to bring this up, but I've been using the name RetroNET as well. I've had the domain retronet.net registered for ages, and was about to launch a small pilot project with a handful of 3B2 emulators running SVR3, with the hope for many more interconnected systems. That said, maybe we could pool our efforts? I'd be happy to share the domain name with this effort, since it's precisely in line with what I'd like to see. -Seth -- Seth Morabito Poulsbo, WA web at loomcom.com From pechter at gmail.com Thu Aug 30 04:26:38 2018 From: pechter at gmail.com (William Pechter) Date: Wed, 29 Aug 2018 14:26:38 -0400 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: References: <1F62F4D0-7AD1-43C2-A9B7-CF9DF239C3D9@berlan.de> Message-ID: <02ee9a61-2920-40e0-bfa4-feb8b3d38c73@gmail.com> Count me in.  I think a UUCP over ssh would be nice as would an SSL version.  I would like to see UUCP over ether as serial for backwards compatibility to talk to old machines and emulation. Some of the kid's I know would be blown away by Cnews and television or transported over Internet or PPP links. Bill ⁣Sent from BlueMail ​ On Aug 29, 2018, 14:06, at 14:06, Grant Taylor via TUHS wrote: >On 08/29/2018 11:49 AM, Andreas Hein wrote: >> Nice idea if UUCP is an option? Now dreaming about the 'internet' i >used >> where i started with UNIX (1985) > >We have been discussing UUCP options. The short list is: > > · UUCP over SSH > · UUCP over TCP (is there an encrypted UUCP over TCP+SSL?) > · UUCP bag files transferred some other means. > · UUCP over some sort of emulated serial connection > >If you have other ideas, I'd love to hear them. > >I expect that we will be talking about an email gateway at some point >if >people are interested. > >We already have a Usenet feed that we will be making available via NNTP > >and UUCP. > > > >-- >Grant. . . . >unix || die -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Thu Aug 30 04:33:49 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 29 Aug 2018 12:33:49 -0600 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com> References: <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com> Message-ID: <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net> On 08/29/2018 12:04 PM, Seth Morabito wrote: > Hmm. I hate to bring this up, but I've been using the name RetroNET > as well. I've had the domain retronet.net registered for ages, and was > about to launch a small pilot project with a handful of 3B2 emulators > running SVR3, with the hope for many more interconnected systems. *gulp* So /you're/ the person that had the domain name we originally wanted. ;-) We actually decided that we liked "Retro Comp(uting) . Net(work)" and have registered that name. There is a wiki(…) and forum(…), but the main website isn't up yet. We are about a week into the discussions. Please join us in the #retronet group on the Synchronet network. (irc.chivanet.org) > That said, maybe we could pool our efforts? I'd be happy to share the > domain name with this effort, since it's precisely in line with what > I'd like to see. ~sigh~of~relief~ I think we would love to welcome more members into the RetroNet. As much as anything else, the idea is to build a community of friendly folks that want to play / learn / help each other, likely in direct relation to retro computing. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From lm at mcvoy.com Thu Aug 30 04:36:32 2018 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 29 Aug 2018 11:36:32 -0700 Subject: [TUHS] RetroNet??? In-Reply-To: <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net> References: <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com> <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net> Message-ID: <20180829183632.GD8423@mcvoy.com> > As much as anything else, the idea is to build a community of friendly folks > that want to play / learn / help each other, likely in direct relation to > retro computing. So just a thought. A good curator, looking at you Warren, helps keep things sane. If your fun project takes off, be picky about who you let in and what sort of behaviour you will tolerate. One toxic person can chase everyone away. From pechter at gmail.com Thu Aug 30 04:38:20 2018 From: pechter at gmail.com (William Pechter) Date: Wed, 29 Aug 2018 14:38:20 -0400 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net> References: <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com> <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net> Message-ID: <6e3a87ce-f573-4258-9db5-a5f99b5b89b1.maildroid@localhost> Count me in. Do we need to work up a UUCP mapping project. Also... Would a pgp encrypted mail system with decryption of messages at the endpoint make sense? Bill -----Original Message----- From: Grant Taylor via TUHS To: tuhs at minnie.tuhs.org Sent: Wed, 29 Aug 2018 14:34 Subject: Re: [TUHS] RetroNet… On 08/29/2018 12:04 PM, Seth Morabito wrote: > Hmm. I hate to bring this up, but I've been using the name RetroNET > as well. I've had the domain retronet.net registered for ages, and was > about to launch a small pilot project with a handful of 3B2 emulators > running SVR3, with the hope for many more interconnected systems. *gulp* So /you're/ the person that had the domain name we originally wanted. ;-) We actually decided that we liked "Retro Comp(uting) . Net(work)" and have registered that name. There is a wiki(…) and forum(…), but the main website isn't up yet. We are about a week into the discussions. Please join us in the #retronet group on the Synchronet network. (irc.chivanet.org) > That said, maybe we could pool our efforts? I'd be happy to share the > domain name with this effort, since it's precisely in line with what > I'd like to see. ~sigh~of~relief~ I think we would love to welcome more members into the RetroNet. As much as anything else, the idea is to build a community of friendly folks that want to play / learn / help each other, likely in direct relation to retro computing. -- Grant. . . . unix || die From gtaylor at tnetconsulting.net Thu Aug 30 04:42:14 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 29 Aug 2018 12:42:14 -0600 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: <02ee9a61-2920-40e0-bfa4-feb8b3d38c73@gmail.com> References: <1F62F4D0-7AD1-43C2-A9B7-CF9DF239C3D9@berlan.de> <02ee9a61-2920-40e0-bfa4-feb8b3d38c73@gmail.com> Message-ID: On 08/29/2018 12:26 PM, William Pechter wrote: > Count me in. Cool! Welcome! We're currently hanging out in the #retronet group on the Synchronet network (I'm accessing through irc.chivanet.org). > I think a UUCP over ssh would be nice as would an SSL version. I've personally done UUCP over SSH multiple times. It looks like TCP port 540 is reserved for UUCP over TCP and TCP port 4031 is reserved for UUCP over SSL. So, we'll definitely be offering those services inside of RetroNet. Currently the idea is to make services available inside of RetroNet. I don't know how many services will be openly available across the Internet. Primarily for security / safety reasons. That being said, I think we are planing on a gateway for things. We're certainly willing to talk about other options too. > I would like to see UUCP over ether as serial for backwards compatibility > to talk to old machines and emulation. I / we would like to know more about the "over ether as serial" part. I'd think the goal would be to have RS-232 (et al) serial ports that can connect to retro computers and make things look like what they would expect to see. That being said, we will either need an RS-232 (et al) serial port on a gateway, or something else to translate from serial to likely an IP~>telnet connection. If you have ideas, please bring them and share them. > Some of the kid's I know would be blown away by Cnews and television or > transported over Internet or PPP links. Yep. :-) -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From gtaylor at tnetconsulting.net Thu Aug 30 04:48:22 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 29 Aug 2018 12:48:22 -0600 Subject: [TUHS] RetroNet??? In-Reply-To: <20180829183632.GD8423@mcvoy.com> References: <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com> <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net> <20180829183632.GD8423@mcvoy.com> Message-ID: <749fb91e-a955-47b4-f206-7b575bb8285d@spamtrap.tnetconsulting.net> On 08/29/2018 12:36 PM, Larry McVoy wrote: > So just a thought. A good curator, looking at you Warren, helps keep > things sane. If your fun project takes off, be picky about who you let > in and what sort of behaviour you will tolerate. One toxic person can > chase everyone away. You make a good point Larry. I'm sort of planing on putting some technological bollards in place to make it so that it's harder for a bad apple to spoil the rest of the barrel. We've already discussed NetFlow for monitoring. I'm assuming that there will be firewalls (at least reverse path filtering) in place to make it harder for people to spoof things. Still something worth keeping in mind. I'm sort of hoping that RetroNet members will sort of self regulate like ham radio operators have a tendance to do. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From pechter at gmail.com Thu Aug 30 04:49:15 2018 From: pechter at gmail.com (William Pechter) Date: Wed, 29 Aug 2018 14:49:15 -0400 Subject: [TUHS] =?utf-8?b?RndkOiBSZTogIFJldHJvTmV04oCm?= In-Reply-To: References: <1F62F4D0-7AD1-43C2-A9B7-CF9DF239C3D9@berlan.de> <02ee9a61-2920-40e0-bfa4-feb8b3d38c73@gmail.com> Message-ID: Missed the cc line. Also I have mailman up @ lakewoodmicro.com at Digital Ocean. If we need mailing lists. -----Original Message----- From: William Pechter To: Grant Taylor Sent: Wed, 29 Aug 2018 14:46 Subject: Re: [TUHS] RetroNet… Damn. Television was autocorrect but I wrote "Telebit" at the time. Perhaps setting up a mumble server for voice chat makes sense. Bill -----Original Message----- From: Grant Taylor via TUHS To: tuhs at minnie.tuhs.org Sent: Wed, 29 Aug 2018 14:42 Subject: Re: [TUHS] RetroNet… On 08/29/2018 12:26 PM, William Pechter wrote: > Count me in. Cool! Welcome! We're currently hanging out in the #retronet group on the Synchronet network (I'm accessing through irc.chivanet.org). > I think a UUCP over ssh would be nice as would an SSL version. I've personally done UUCP over SSH multiple times. It looks like TCP port 540 is reserved for UUCP over TCP and TCP port 4031 is reserved for UUCP over SSL. So, we'll definitely be offering those services inside of RetroNet. Currently the idea is to make services available inside of RetroNet. I don't know how many services will be openly available across the Internet. Primarily for security / safety reasons. That being said, I think we are planing on a gateway for things. We're certainly willing to talk about other options too. > I would like to see UUCP over ether as serial for backwards compatibility > to talk to old machines and emulation. I / we would like to know more about the "over ether as serial" part. I'd think the goal would be to have RS-232 (et al) serial ports that can connect to retro computers and make things look like what they would expect to see. That being said, we will either need an RS-232 (et al) serial port on a gateway, or something else to translate from serial to likely an IP~>telnet connection. If you have ideas, please bring them and share them. > Some of the kid's I know would be blown away by Cnews and television or > transported over Internet or PPP links. Yep. :-) -- Grant. . . . unix || die From clemc at ccc.com Thu Aug 30 04:50:24 2018 From: clemc at ccc.com (Clem Cole) Date: Wed, 29 Aug 2018 14:50:24 -0400 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: References: <1F62F4D0-7AD1-43C2-A9B7-CF9DF239C3D9@berlan.de> <02ee9a61-2920-40e0-bfa4-feb8b3d38c73@gmail.com> Message-ID: On Wed, Aug 29, 2018 at 2:42 PM Grant Taylor via TUHS wrote: > ... > > > It looks like TCP port 540 is reserved for UUCP over TCP > I think that's either 'e' or 't' uucico protocol. I've forgoten (and I wrote 'e'). But look at the uucico code in either a late version og Honey-Dan-BER or the Taylor UUCP rewrite, as I think they have all those protocols. > > > I / we would like to know more about the "over ether as serial" part. > We can take this off line. As I said, it been done a numberof times with simh and the like. The key is that simh creates a 'serial line' on a TCP port. You tell UNIX to hang a login off it and then you telnet or whatever to that port. The older system running in simh, thinks it has a serial line. It pretty much just works; al biet is slow as hell and chews up a ton of resources. > > If you have ideas, please bring them and share them. > You just need to engage of a us old folks that run UUCP back in the day ;-) Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Thu Aug 30 04:53:42 2018 From: crossd at gmail.com (Dan Cross) Date: Wed, 29 Aug 2018 14:53:42 -0400 Subject: [TUHS] RetroNet??? In-Reply-To: <20180829183632.GD8423@mcvoy.com> References: <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com> <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net> <20180829183632.GD8423@mcvoy.com> Message-ID: On Wed, Aug 29, 2018 at 2:36 PM Larry McVoy wrote: > > As much as anything else, the idea is to build a community of friendly > folks > > that want to play / learn / help each other, likely in direct relation to > > retro computing. > > So just a thought. A good curator, looking at you Warren, helps keep > things sane. If your fun project takes off, be picky about who you let > in and what sort of behaviour you will tolerate. One toxic person can > chase everyone away. > Speaking of Warren and UUCP (and wise words from Larry here, but I'm going off in a slightly different direction). Warren was working on getting a UUCP network up and running again to commemorate the Unix 50th anniversary. I was (and probably still am) on the mailing list, but activity has kind of petered off as of late. Anyway, you may want to get in touch with him and see if you can leverage some of that work or perhaps join forces. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Thu Aug 30 04:54:23 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 29 Aug 2018 12:54:23 -0600 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: <6e3a87ce-f573-4258-9db5-a5f99b5b89b1.maildroid@localhost> References: <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com> <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net> <6e3a87ce-f573-4258-9db5-a5f99b5b89b1.maildroid@localhost> Message-ID: <05bca3df-ec9d-6782-2cd0-b8611e6c7880@spamtrap.tnetconsulting.net> On 08/29/2018 12:38 PM, William Pechter wrote: > Count me in. :-) > Do we need to work up a UUCP mapping project. I'm sure we will want one at some point. I know that we're not there yet. > Also... Would a pgp encrypted mail system with decryption of messages > at the endpoint make sense? I think that might be further down the road. But I see no reason why such can't be discussed. I assume that: 1) There would be a central directory (DNS / LDAP) that has public certs / keys for people that wanted to participate. 2) The email gateway would opportunistically encrypt messages that were unencrypted and relay them to the internal destination. (I'm assuming that some people will want to run their own SMTP server.) (We can easily provide a community SMTP server too.) Aside: One of the ideas of RetroNet is to provide a safe place for people to play and learn about technologies, like how to run their own SMTP server. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From gtaylor at tnetconsulting.net Thu Aug 30 04:56:04 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 29 Aug 2018 12:56:04 -0600 Subject: [TUHS] =?utf-8?b?RndkOiBSZTogUmV0cm9OZXTigKY=?= In-Reply-To: References: <1F62F4D0-7AD1-43C2-A9B7-CF9DF239C3D9@berlan.de> <02ee9a61-2920-40e0-bfa4-feb8b3d38c73@gmail.com> Message-ID: On 08/29/2018 12:49 PM, William Pechter wrote: > Missed the cc line. Also I have mailman up @ lakewoodmicro.com at > Digital Ocean. If we need mailing lists. Thank you for the offer Bill. We've got a mailing list set up. I don't think there are any subscribers yet. This project is < 2 weeks old. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From krewat at kilonet.net Thu Aug 30 04:57:37 2018 From: krewat at kilonet.net (Arthur Krewat) Date: Wed, 29 Aug 2018 14:57:37 -0400 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: References: <1F62F4D0-7AD1-43C2-A9B7-CF9DF239C3D9@berlan.de> <02ee9a61-2920-40e0-bfa4-feb8b3d38c73@gmail.com> Message-ID: <30f470e7-12cb-00ac-6461-35ce8dfb425d@kilonet.net> Ala DZ11 support in the KS10 emulator of SIMH ;) On 8/29/2018 2:50 PM, Clem Cole wrote: > > > We can take this off line.   As I said, it been done a numberof times > with simh and the like.   The key is that simh creates a 'serial line' > on a TCP port.    You tell UNIX to hang a login off it and then you > telnet or whatever to that port.    The older system running in simh, > thinks it has a serial line.   It pretty much just works; al biet is > slow as hell and chews up a ton of resources. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pechter at gmail.com Thu Aug 30 05:00:57 2018 From: pechter at gmail.com (William Pechter) Date: Wed, 29 Aug 2018 15:00:57 -0400 Subject: [TUHS] RetroNet??? In-Reply-To: References: <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com> <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net> <20180829183632.GD8423@mcvoy.com> Message-ID: <71fc9586-ad41-4471-ad78-617c85a68404.maildroid@localhost> One thing that may make sense on the low power front... I emulated 3 simultaneous Vaxes on one RasPi... If you are less than secure (BSD 4.X) at least the host can be up to date with emulation. Running 4.2 with Sendmail 5 scares me. Emulated UUCP and maps less so. -----Original Message----- From: Dan Cross To: Larry McVoy Cc: TUHS main list , Grant Taylor Sent: Wed, 29 Aug 2018 14:54 Subject: Re: [TUHS] RetroNet??? On Wed, Aug 29, 2018 at 2:36 PM Larry McVoy wrote: > > As much as anything else, the idea is to build a community of friendly > folks > > that want to play / learn / help each other, likely in direct relation to > > retro computing. > > So just a thought. A good curator, looking at you Warren, helps keep > things sane. If your fun project takes off, be picky about who you let > in and what sort of behaviour you will tolerate. One toxic person can > chase everyone away. > Speaking of Warren and UUCP (and wise words from Larry here, but I'm going off in a slightly different direction). Warren was working on getting a UUCP network up and running again to commemorate the Unix 50th anniversary. I was (and probably still am) on the mailing list, but activity has kind of petered off as of late. Anyway, you may want to get in touch with him and see if you can leverage some of that work or perhaps join forces. - Dan C. From rly1 at embarqmail.com Thu Aug 30 04:50:53 2018 From: rly1 at embarqmail.com (Ron Young) Date: Wed, 29 Aug 2018 11:50:53 -0700 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: <02ee9a61-2920-40e0-bfa4-feb8b3d38c73@gmail.com> References: <1F62F4D0-7AD1-43C2-A9B7-CF9DF239C3D9@berlan.de> <02ee9a61-2920-40e0-bfa4-feb8b3d38c73@gmail.com> Message-ID: <38.0A.23233.D0BE68B5@smtp04.onyx.dfw.sync.lan> Your message dated: Wed, 29 Aug 2018 14:26:38 -0400 -------- I'm interested as well... One thing you may want to consider is using the "pound" ssl wrapper (http://www.apsis.ch/pound/) to handle the encryption of traffic. I use this on my home-brewed webserver that doesn't do ssl itself. Pound is used as a ssl wrapper and forwards all public port 443 traffic over to port 80 on the internal webserver. It also redirects public port 80 over to the public port 443... -ron > > Count me in=2E=C2=A0 I think a UUCP over ssh would be nice as would an SSL = > version=2E=C2=A0 I would like to see UUCP over ether as serial for backward= > s compatibility to talk to old machines and emulation=2E > > Some of the kid'= > s I know would be blown away by Cnews and television or transported over In= > ternet or PPP links=2E > > Bill > =============================================================================== Ron Young rly1 at embarqmail.com From clemc at ccc.com Thu Aug 30 05:30:48 2018 From: clemc at ccc.com (Clem Cole) Date: Wed, 29 Aug 2018 15:30:48 -0400 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: <30f470e7-12cb-00ac-6461-35ce8dfb425d@kilonet.net> References: <1F62F4D0-7AD1-43C2-A9B7-CF9DF239C3D9@berlan.de> <02ee9a61-2920-40e0-bfa4-feb8b3d38c73@gmail.com> <30f470e7-12cb-00ac-6461-35ce8dfb425d@kilonet.net> Message-ID: Right but for goodness sake, try to make a DH11 work; not a DZ11!!! Real DZ11'S were SW pigs and consumed a measurable percentage of a vax, particularly when running uucico(8) (they are interrupt crazy). It is one of the reasons why the Unix community in those days always recommended Able DH/DMs on Vaxen. Clem ᐧ On Wed, Aug 29, 2018 at 2:57 PM Arthur Krewat wrote: > Ala DZ11 support in the KS10 emulator of SIMH ;) > > > > On 8/29/2018 2:50 PM, Clem Cole wrote: > > >> We can take this off line. As I said, it been done a numberof times > with simh and the like. The key is that simh creates a 'serial line' on a > TCP port. You tell UNIX to hang a login off it and then you telnet or > whatever to that port. The older system running in simh, thinks it has a > serial line. It pretty much just works; al biet is slow as hell and chews > up a ton of resources. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Thu Aug 30 05:35:37 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 29 Aug 2018 13:35:37 -0600 Subject: [TUHS] RetroNet??? In-Reply-To: <71fc9586-ad41-4471-ad78-617c85a68404.maildroid@localhost> References: <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com> <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net> <20180829183632.GD8423@mcvoy.com> <71fc9586-ad41-4471-ad78-617c85a68404.maildroid@localhost> Message-ID: <16994a7b-84e6-3b20-c555-8216accd372e@spamtrap.tnetconsulting.net> On 08/29/2018 01:00 PM, William Pechter wrote: > One thing that may make sense on the low power front... I emulated 3 > simultaneous Vaxes on one RasPi... Would those be independent VAXen? Or would they be different CPU cabinets of a multi-CPU 780? Was that 785 or something like that? > If you are less than secure (BSD 4.X) at least the host can be up to date > with emulation. Running 4.2 with Sendmail 5 scares me. Emulated UUCP > and maps less so. This is exactly why we want RetroNet to be a walled garden. Easy for members to join and access yet separated from the Big Bad Internet™ for that very reason. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From pechter at gmail.com Thu Aug 30 05:43:00 2018 From: pechter at gmail.com (William Pechter) Date: Wed, 29 Aug 2018 15:43:00 -0400 Subject: [TUHS] RetroNet??? In-Reply-To: <16994a7b-84e6-3b20-c555-8216accd372e@spamtrap.tnetconsulting.net> References: <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com> <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net> <20180829183632.GD8423@mcvoy.com> <71fc9586-ad41-4471-ad78-617c85a68404.maildroid@localhost> <16994a7b-84e6-3b20-c555-8216accd372e@spamtrap.tnetconsulting.net> Message-ID: They were 3 different 11/780s. The 785 was a (DEC Germany as the Field Service rumor went) 7400 Schotky rework of the 11/780 TTL as a midlife speed kicker. IIRC, it had a higher clock and was about 1.5x the 780. The 11/782 was conjoined twin 11/780s in a master slave config. I heard of 11/787s done with dual 11/785s but never saw them in my Field Service days. Bill -----Original Message----- From: Grant Taylor via TUHS To: tuhs at minnie.tuhs.org Sent: Wed, 29 Aug 2018 15:35 Subject: Re: [TUHS] RetroNet??? On 08/29/2018 01:00 PM, William Pechter wrote: > One thing that may make sense on the low power front... I emulated 3 > simultaneous Vaxes on one RasPi... Would those be independent VAXen? Or would they be different CPU cabinets of a multi-CPU 780? Was that 785 or something like that? > If you are less than secure (BSD 4.X) at least the host can be up to date > with emulation. Running 4.2 with Sendmail 5 scares me. Emulated UUCP > and maps less so. This is exactly why we want RetroNet to be a walled garden. Easy for members to join and access yet separated from the Big Bad Internet™ for that very reason. -- Grant. . . . unix || die From arrigo at alchemistowl.org Thu Aug 30 05:28:17 2018 From: arrigo at alchemistowl.org (Arrigo Triulzi) Date: Wed, 29 Aug 2018 21:28:17 +0200 Subject: [TUHS] RetroNet??? In-Reply-To: References: <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com> <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net> <20180829183632.GD8423@mcvoy.com> Message-ID: On 29 Aug 2018, at 20:53, Dan Cross wrote: > On Wed, Aug 29, 2018 at 2:36 PM Larry McVoy wrote: > Speaking of Warren and UUCP (and wise words from Larry here, but I'm going off in a slightly different direction). > > Warren was working on getting a UUCP network up and running again to commemorate the Unix 50th anniversary. I was (and probably still am) on the mailing list, but activity has kind of petered off as of late. Anyway, you may want to get in touch with him and see if you can leverage some of that work or perhaps join forces. Have you considered asking Peter Honeyman if he wishes to collaborate in the UUCP project (the “Honey” in HoneyDanBer UUCP)? Arrigo From gtaylor at tnetconsulting.net Thu Aug 30 06:14:11 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 29 Aug 2018 14:14:11 -0600 Subject: [TUHS] RetroNet??? In-Reply-To: References: <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com> <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net> <20180829183632.GD8423@mcvoy.com> Message-ID: <83698bdc-c636-5688-5619-27c8c4b41500@spamtrap.tnetconsulting.net> On 08/29/2018 01:28 PM, Arrigo Triulzi wrote: > Have you considered asking Peter Honeyman if he wishes to collaborate > in the UUCP project (the “Honey” in HoneyDanBer UUCP)? I hadn't thought about it. Please reply to me directly / off list with contact information if you have it and I'll happily send him an email. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From krewat at kilonet.net Thu Aug 30 06:09:49 2018 From: krewat at kilonet.net (Arthur Krewat) Date: Wed, 29 Aug 2018 16:09:49 -0400 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: References: <1F62F4D0-7AD1-43C2-A9B7-CF9DF239C3D9@berlan.de> <02ee9a61-2920-40e0-bfa4-feb8b3d38c73@gmail.com> <30f470e7-12cb-00ac-6461-35ce8dfb425d@kilonet.net> Message-ID: <0cfe9e5b-6a34-cea0-3639-4bdfea039cab@kilonet.net> LOL - very true, Clem. That was a shameless bit of self-promotion. From what I can tell, SIMH does not support a DH11. Yet. But when is an emulated interrupt a bad thing? Except for the idle loop that may or may not be optimized, the rest is balls-to-the-wall CPU bound anyway. And these days, even emulated, we're orders of magnitude faster than the original hardware. http://simh.trailing-edge.narkive.com/Sc9HBFZU/multiple-telnet-ports-in-simh-to-rsts-e-9-6 I recognize a familiar name in there ;) But yeah, when a DZ11 was blazing away at 19200 baud (I hacked the TOPS-10 6.03A we had at LIRICS to support it), it made the system crawl. Back to our regularly scheduled programming... On 8/29/2018 3:30 PM, Clem Cole wrote: > Right but for goodness sake, try to make a DH11 work; not a DZ11!!!  >  Real DZ11'S were SW pigs and consumed a measurable percentage of a > vax, particularly when running uucico(8) (they are interrupt crazy).  >  It is one of the reasons why the Unix community in those days always > recommended Able DH/DMs on Vaxen. > > Clem > ᐧ > > On Wed, Aug 29, 2018 at 2:57 PM Arthur Krewat > wrote: > > Ala DZ11 support in the KS10 emulator of SIMH ;) > > > > On 8/29/2018 2:50 PM, Clem Cole wrote: >> >> >> We can take this off line.   As I said, it been done a numberof >> times with simh and the like.   The key is that simh creates a >> 'serial line' on a TCP port. You tell UNIX to hang a login off it >> and then you telnet or whatever to that port.    The older system >> running in simh, thinks it has a serial line.   It pretty much >> just works; al biet is slow as hell and chews up a ton of resources. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Thu Aug 30 06:21:11 2018 From: wkt at tuhs.org (Warren Toomey) Date: Thu, 30 Aug 2018 06:21:11 +1000 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: <6e3a87ce-f573-4258-9db5-a5f99b5b89b1.maildroid@localhost> References: <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com> <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net> <6e3a87ce-f573-4258-9db5-a5f99b5b89b1.maildroid@localhost> Message-ID: <20180829202111.GA17007@minnie.tuhs.org> On Wed, Aug 29, 2018 at 02:38:20PM -0400, William Pechter wrote: > Count me in. Do we need to work up a UUCP mapping project. Argh, argh! I did a lot of this last year. It's all on Github at https://github.com/DoctorWkt/4bsd-uucp/ We got as far as recreating this microcosm of Usenet https://github.com/DoctorWkt/4bsd-uucp/blob/4.3BSD/uucp.png before it all petered out! Cheers, Warren From wkt at tuhs.org Thu Aug 30 06:22:19 2018 From: wkt at tuhs.org (Warren Toomey) Date: Thu, 30 Aug 2018 06:22:19 +1000 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: <6e3a87ce-f573-4258-9db5-a5f99b5b89b1.maildroid@localhost> References: <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com> <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net> <6e3a87ce-f573-4258-9db5-a5f99b5b89b1.maildroid@localhost> Message-ID: <20180829202219.GB17007@minnie.tuhs.org> On Wed, Aug 29, 2018 at 02:38:20PM -0400, William Pechter wrote: > Count me in. Do we need to work up a UUCP mapping project. Oh, and the mailing list for my effort is here: https://minnie.tuhs.org//pipermail/uucp/ Warren From krewat at kilonet.net Thu Aug 30 06:27:06 2018 From: krewat at kilonet.net (Arthur Krewat) Date: Wed, 29 Aug 2018 16:27:06 -0400 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: <20180829202111.GA17007@minnie.tuhs.org> References: <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com> <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net> <6e3a87ce-f573-4258-9db5-a5f99b5b89b1.maildroid@localhost> <20180829202111.GA17007@minnie.tuhs.org> Message-ID: <0d7d8493-1d58-1dee-d02d-1d1dc67be396@kilonet.net> On 8/29/2018 4:21 PM, Warren Toomey wrote: > before it all petered out! And I'm ashamed to say, I had volunteered to be at least a leaf node, and never completed the task(s). ak From clemc at ccc.com Thu Aug 30 06:58:51 2018 From: clemc at ccc.com (Clem Cole) Date: Wed, 29 Aug 2018 16:58:51 -0400 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: <0cfe9e5b-6a34-cea0-3639-4bdfea039cab@kilonet.net> References: <1F62F4D0-7AD1-43C2-A9B7-CF9DF239C3D9@berlan.de> <02ee9a61-2920-40e0-bfa4-feb8b3d38c73@gmail.com> <30f470e7-12cb-00ac-6461-35ce8dfb425d@kilonet.net> <0cfe9e5b-6a34-cea0-3639-4bdfea039cab@kilonet.net> Message-ID: On Wed, Aug 29, 2018 at 4:17 PM Arthur Krewat wrote: > LOL - very true, Clem. That was a shameless bit of self-promotion. From > what I can tell, SIMH does not support a DH11. Yet. > Note I have not tried this .... but from the simh mailing list: * The UNIBUS DH11 and DHU11 had 16 lines per interface * The QBUS DHV11 had 8 lines per interface * The QBUS CXY08 was DHU/DHV compatible and had 8 lines * The QBUS CXA16 " " " " " " " 16 lines *Supposely, the DHV11 works ..... its been on my >>round tuit<< list for a while to verify!!!!* > > But when is an emulated interrupt a bad thing? Except for the idle loop > that may or may not be optimized, the rest is balls-to-the-wall CPU bound > anyway. And these days, even emulated, we're orders of magnitude faster > than the original hardware. > Yeah, but since the 780 was slow on interrupt processing, why stress it any more thsan you have too. > > > http://simh.trailing-edge.narkive.com/Sc9HBFZU/multiple-telnet-ports-in-simh-to-rsts-e-9-6 > > I recognize a familiar name in there ;) > Yeah a couple of them ;-) > > But yeah, when a DZ11 was blazing away at 19200 baud (I hacked the TOPS-10 > 6.03A we had at LIRICS to support it), it made the system crawl. > No doubt. CMU and MIT had front ends that put the serial lines on dedicated PDP-11s in front of the 10's - so the Tops (or ITS) only saw canonicalized I/O and it made a huge difference for those systems. By the time Vaxen, I don't think DEC had yet realized what a problem the DZ was. The DH's issue was cost (and space) since it was implemented in MSI TTL and took up a full 'PDP-11 System Unit' on the bus. The DZ11 gave you 8 serial ports in a single PDP-11 slot, which was a huge win. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Thu Aug 30 08:03:36 2018 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 30 Aug 2018 08:03:36 +1000 (EST) Subject: [TUHS] Cryptic Unix Commands In-Reply-To: <20180829043639.GA6691@minnie.tuhs.org> References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829032310.GF19128@thunk.org> <20180829043639.GA6691@minnie.tuhs.org> Message-ID: On Wed, 29 Aug 2018, Warren Toomey wrote: > This reminded me of other semi-cryptic commands. I remember mistyping > "kill -1 1" as "kill -9 1" with the inevitable consequences. Hands up all those who have *not* done that... -- Dave From gtaylor at tnetconsulting.net Thu Aug 30 08:09:31 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 29 Aug 2018 16:09:31 -0600 Subject: [TUHS] Cryptic Unix Commands In-Reply-To: References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829032310.GF19128@thunk.org> <20180829043639.GA6691@minnie.tuhs.org> Message-ID: <4bd61529-9c48-bd1a-80d7-d4bc6529fcdc@spamtrap.tnetconsulting.net> On 08/29/2018 04:03 PM, Dave Horsfall wrote: > Hands up all those who have *not* done that... My faux pas is usually meaning to type "telinit q" but reaching a bit too far and accidnetally typing "telinit 1". *facepalm* /me starts the (not so) slow walk of shame to the DC. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From pechter at gmail.com Thu Aug 30 08:21:44 2018 From: pechter at gmail.com (William Pechter) Date: Wed, 29 Aug 2018 18:21:44 -0400 Subject: [TUHS] Cryptic Unix Commands In-Reply-To: <4bd61529-9c48-bd1a-80d7-d4bc6529fcdc@spamtrap.tnetconsulting.net> References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829032310.GF19128@thunk.org> <20180829043639.GA6691@minnie.tuhs.org> <4bd61529-9c48-bd1a-80d7-d4bc6529fcdc@spamtrap.tnetconsulting.net> Message-ID: <415707d1-1b53-4042-a289-630f733f5188.maildroid@localhost> Did that one at Johnson and Johnson Health Care Systems around '95 as an IBM Global Services guy. Ran to the computer room to restart services and Oracle on AIX. Apologized to the customer. IBM demanded a formal Root Cause Analysis for the fat finger with recommendations for avoiding the problem in the future. I proposed redesigned ascii keyboards where Q and 1 weren't adjacent. Management suits not amused. Customer took it as simple accident and dealt with the 5-10 minute outage. Bill -----Original Message----- From: Grant Taylor via TUHS To: tuhs at minnie.tuhs.org Sent: Wed, 29 Aug 2018 18:09 Subject: Re: [TUHS] Cryptic Unix Commands On 08/29/2018 04:03 PM, Dave Horsfall wrote: > Hands up all those who have *not* done that... My faux pas is usually meaning to type "telinit q" but reaching a bit too far and accidnetally typing "telinit 1". *facepalm* /me starts the (not so) slow walk of shame to the DC. -- Grant. . . . unix || die From danmick at gmail.com Thu Aug 30 08:31:13 2018 From: danmick at gmail.com (Dan Mick) Date: Wed, 29 Aug 2018 15:31:13 -0700 Subject: [TUHS] Cryptic Unix Commands In-Reply-To: References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829032310.GF19128@thunk.org> <20180829043639.GA6691@minnie.tuhs.org> Message-ID: On 08/29/2018 03:03 PM, Dave Horsfall wrote: > On Wed, 29 Aug 2018, Warren Toomey wrote: > >> This reminded me of other semi-cryptic commands. I remember mistyping >> "kill -1 1" as "kill -9 1" with the inevitable consequences. > > Hands up all those who have *not* done that... > > -- Dave I always type signal names. Life's too short to worry about saving three characters. From dave at horsfall.org Thu Aug 30 08:34:05 2018 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 30 Aug 2018 08:34:05 +1000 (EST) Subject: [TUHS] cat -v and other complaints In-Reply-To: References: Message-ID: On Wed, 29 Aug 2018, Clem Cole wrote: [ Excellent screed elided ] > That said, I give the Linux folks great credit for the addition of > modules was huge and it took BSD and the other UNIX systems a few years > really pick up that idea in the same way (yes Solaris, Tru64 and > eventually HPUX etc.. had something too but again - my comment about > being generally available applies). Wasn't SunOS first with dynamic kernel modules, or is my memory worse than I thought? Linux may have been around at the time, but we never used in the shop until much later (Red Hat, nicknamed Dead Rat). > So here is the issue, how to do move the ball forward?   BSD, then > Linux, became the 'stronger strain' and pushed out the old version.  >  The problem is the ROMs in my fingers (like Dave) never got > reprogrammed so some of the 'new' becomes annoying.   Will I learned to > like systemd?   We shall see... Never mind "systemd"; I'm having enough trouble coming to grips with "launchd" on the Mac... Gimme /etc/inetd.conf any time. -- Dave From gtaylor at tnetconsulting.net Thu Aug 30 09:00:02 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 29 Aug 2018 17:00:02 -0600 Subject: [TUHS] Cryptic Unix Commands In-Reply-To: References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829032310.GF19128@thunk.org> <20180829043639.GA6691@minnie.tuhs.org> Message-ID: On 08/29/2018 04:31 PM, Dan Mick wrote: > I always type signal names. Life's too short to worry about saving > three characters. Signal names? I've always used numbers / quit. I don't think I've ever seen anybody do otherwise. /me goes to read the man page. Thank you for the pro tip Dan. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From gtaylor at tnetconsulting.net Thu Aug 30 09:04:48 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 29 Aug 2018 17:04:48 -0600 Subject: [TUHS] Cryptic Unix Commands In-Reply-To: <415707d1-1b53-4042-a289-630f733f5188.maildroid@localhost> References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829032310.GF19128@thunk.org> <20180829043639.GA6691@minnie.tuhs.org> <4bd61529-9c48-bd1a-80d7-d4bc6529fcdc@spamtrap.tnetconsulting.net> <415707d1-1b53-4042-a289-630f733f5188.maildroid@localhost> Message-ID: <3f239c5d-ea78-6379-c560-9935b856a234@spamtrap.tnetconsulting.net> On 08/29/2018 04:21 PM, William Pechter wrote: > Did that one at Johnson and Johnson Health Care Systems around '95 as an > IBM Global Services guy. Ran to the computer room to restart services > and Oracle on AIX. @^*% happens. Anybody that tells you it doesn't happen to them is lying. > Apologized to the customer. IBM demanded a formal Root Cause Analysis > for the fat finger with recommendations for avoiding the problem in > the future. I proposed redesigned ascii keyboards where Q and 1 weren't > adjacent. I remember things like that. I always liked to admit things like that to the customer. I felt that it fostered trust. More than once I went to a customer that trusted me and told them that something was not me and they took me at my word, primarily because of that established trust. > Management suits not amused. Customer took it as simple accident and > dealt with the 5-10 minute outage. Nice. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From davida at pobox.com Thu Aug 30 09:09:43 2018 From: davida at pobox.com (David Arnold) Date: Thu, 30 Aug 2018 09:09:43 +1000 Subject: [TUHS] SunOS code? In-Reply-To: References: <1535123616.1824656.1485063544.08BED1A8@webmail.messagingengine.com> <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829004627.GG317@mcvoy.com> <201808290529.w7T5TFKa006049@freefriends.org> Message-ID: > On 30 Aug 2018, at 00:43, Warner Losh wrote: > On Tue, Aug 28, 2018 at 11:29 PM > wrote: > Changed the subject line. > > Larry McVoy > wrote: > > > So I'd go with MacOS is not a fun kernel. It's pretty close to BSD > > and I recently wandered through that VM system and I was not impressed. > > I wish like hell that Sun had fed their VM back to BSD. Yeah, it wasn't > > multi processor friendly but someone would have fixed that. > > > > The penguin stuff, it's OK. Not as clean as SunOS by a long shot. > > So, is the SunOS code available in a way that would let people hack > on it? They had ported it to 386 (roadrunner?), so maybe it'd be > possible to revive it and bring it into the 21st century. > > The Googles tells me there's a dozen download places. I found both 4.1.4 (aka Solaris 1.1.2) and 4.1.3 (which still has the m68k, sun2, and sun3 bits in it). It’d be quite fun to walk through Bill & Lynne Jolitz’ Dr Dobbs 386BSD articles but with one of these as the starting point. d -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From ewayte at gmail.com Thu Aug 30 09:23:22 2018 From: ewayte at gmail.com (Eric Wayte) Date: Wed, 29 Aug 2018 19:23:22 -0400 Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: <20180829171446.GB16716@ancienthardware.org> References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829032310.GF19128@thunk.org> <20180829050640.GD5698@eureka.lemis.com> <20180829142548.GH19128@thunk.org> <20180829171446.GB16716@ancienthardware.org> Message-ID: On Wed, Aug 29, 2018 at 1:28 PM Arno Griffioen wrote: > On Wed, Aug 29, 2018 at 10:41:02AM -0400, Dan Cross wrote: > > I'm curious who was using AOS, which was essentially Tahoe+NFS. > > Used it for several years, but on IBM 6151 RT machines and not RS/6000's. > > The ROMP CPU in the RT's was a bit of an oddball, but fun to play with > using an assembler :) > > Like many IBM's from the era they had fantastic keyboards though! > > Bye, Arno. > I remember IBM brought a semi-trailer to my university (UCF) showcasing the RT back in the 80s. -- Eric Wayte -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Thu Aug 30 09:36:05 2018 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 29 Aug 2018 16:36:05 -0700 Subject: [TUHS] cat -v and other complaints In-Reply-To: References: Message-ID: <20180829233605.GJ8423@mcvoy.com> On Thu, Aug 30, 2018 at 08:34:05AM +1000, Dave Horsfall wrote: > On Wed, 29 Aug 2018, Clem Cole wrote: > >That said, I give the Linux folks great credit for the addition of modules > >was huge and it took BSD and the other UNIX systems a few years really > >pick up that idea in the same way (yes Solaris, Tru64 and eventually HPUX > >etc.. had something too but again - my comment about being generally > >available applies). > > Wasn't SunOS first with dynamic kernel modules, or is my memory worse than I > thought? Linux may have been around at the time, but we never used in the > shop until much later (Red Hat, nicknamed Dead Rat). Yep. And Linux has loadable modules because I posted the SunOS 4.x man pages for the SunOS loadable modules to the kernel list. Proving once again that the open source guys aren't always the greatest at coming up with the ideas but once you show them that it can be done, it gets done quickly. I think they had a prototype working in a week. > Never mind "systemd"; I'm having enough trouble coming to grips with > "launchd" on the Mac... Gimme /etc/inetd.conf any time. Amen, brother. From lm at mcvoy.com Thu Aug 30 09:38:10 2018 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 29 Aug 2018 16:38:10 -0700 Subject: [TUHS] Cryptic Unix Commands In-Reply-To: <3f239c5d-ea78-6379-c560-9935b856a234@spamtrap.tnetconsulting.net> References: <201808280601.w7S61oLM030628@freefriends.org> <20180829032310.GF19128@thunk.org> <20180829043639.GA6691@minnie.tuhs.org> <4bd61529-9c48-bd1a-80d7-d4bc6529fcdc@spamtrap.tnetconsulting.net> <415707d1-1b53-4042-a289-630f733f5188.maildroid@localhost> <3f239c5d-ea78-6379-c560-9935b856a234@spamtrap.tnetconsulting.net> Message-ID: <20180829233810.GK8423@mcvoy.com> On Wed, Aug 29, 2018 at 05:04:48PM -0600, Grant Taylor via TUHS wrote: > On 08/29/2018 04:21 PM, William Pechter wrote: > >Apologized to the customer. IBM demanded a formal Root Cause Analysis for > >the fat finger with recommendations for avoiding the problem in the > >future. I proposed redesigned ascii keyboards where Q and 1 weren't > >adjacent. > > I remember things like that. > > I always liked to admit things like that to the customer. I felt that it > fostered trust. More than once I went to a customer that trusted me and > told them that something was not me and they took me at my word, primarily > because of that established trust. Yep, I'm the same way and I think most good to stellar engineers are the same way. How can you fix your stuff if you are in denial about it being broken. And I agree with you Grant, on the trust building. Customers love it when you are honest. From dave at horsfall.org Thu Aug 30 10:02:59 2018 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 30 Aug 2018 10:02:59 +1000 (EST) Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: <0d7d8493-1d58-1dee-d02d-1d1dc67be396@kilonet.net> References: <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com> <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net> <6e3a87ce-f573-4258-9db5-a5f99b5b89b1.maildroid@localhost> <20180829202111.GA17007@minnie.tuhs.org> <0d7d8493-1d58-1dee-d02d-1d1dc67be396@kilonet.net> Message-ID: On Wed, 29 Aug 2018, Arthur Krewat wrote: > And I'm ashamed to say, I had volunteered to be at least a leaf node, > and never completed the task(s). Me too, I'm afraid, but I suddenly got back into Amateur radio again after a lapse of a few year for health reasons (and my workbench has overflowed onto my dining table). It's still on my TODO list, though (I think I snared "utzoo" for my UUCP node, and quite likely will resurrect one of my ACSnet nodes for any Aussies taking part). -- Dave (VK2KFU) From dave at horsfall.org Thu Aug 30 10:13:03 2018 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 30 Aug 2018 10:13:03 +1000 (EST) Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: References: <1F62F4D0-7AD1-43C2-A9B7-CF9DF239C3D9@berlan.de> <02ee9a61-2920-40e0-bfa4-feb8b3d38c73@gmail.com> <30f470e7-12cb-00ac-6461-35ce8dfb425d@kilonet.net> <0cfe9e5b-6a34-cea0-3639-4bdfea039cab@kilonet.net> Message-ID: On Wed, 29 Aug 2018, Clem Cole wrote: > But yeah, when a DZ11 was blazing away at 19200 baud (I hacked > the TOPS-10 6.03A we had at LIRICS to support it), it made the > system crawl. > > No doubt.   CMU and MIT had front ends that put the serial lines on > dedicated PDP-11s in front of the 10's - so the Tops (or ITS) only saw > canonicalized I/O and it made a huge difference for those systems.  By > the time Vaxen, I don't think DEC had yet realized what a problem the DZ > was.  Did the Aussie DZ-11 drivers (there were two versions) not make it out of the country? They are on the UNSW tapes, and I seem to recall a thread about this... I don't know how fast we drove them, but I doubt whether it was 19200; probably 9600 for the lucky few and 2400 for the plebs. -- Dave From clemc at ccc.com Thu Aug 30 11:14:22 2018 From: clemc at ccc.com (Clem cole) Date: Wed, 29 Aug 2018 21:14:22 -0400 Subject: [TUHS] cat -v and other complaints In-Reply-To: <20180829233605.GJ8423@mcvoy.com> References: <20180829233605.GJ8423@mcvoy.com> Message-ID: <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com> Truth is I think IBM beat Sun on getting loadable modules for the kernel out first. But I was counting the versions that people really looked at which is why I give Linux credit. It makes sense they modeled on SunOS btw but the fact is the Linux version is what folks like *BSD and macOS modeled after later. Btw you are 100% right - As for launchd I agree/no doubt - but I’d already given up on MacOS being able to be admin’ed like a Unix box. I can pretty much use it via iterm2 as a user like one and if mostly works as I expect (which I do appreciate). Linux is seductive enough to make think I should be able to admin it like I have for the last 40 years and it then bites me when I least expect it. Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Aug 29, 2018, at 7:36 PM, Larry McVoy wrote: > >> On Thu, Aug 30, 2018 at 08:34:05AM +1000, Dave Horsfall wrote: >>> On Wed, 29 Aug 2018, Clem Cole wrote: >>> That said, I give the Linux folks great credit for the addition of modules >>> was huge and it took BSD and the other UNIX systems a few years really >>> pick up that idea in the same way (yes Solaris, Tru64 and eventually HPUX >>> etc.. had something too but again - my comment about being generally >>> available applies). >> >> Wasn't SunOS first with dynamic kernel modules, or is my memory worse than I >> thought? Linux may have been around at the time, but we never used in the >> shop until much later (Red Hat, nicknamed Dead Rat). > > Yep. And Linux has loadable modules because I posted the SunOS 4.x man > pages for the SunOS loadable modules to the kernel list. Proving once > again that the open source guys aren't always the greatest at coming up > with the ideas but once you show them that it can be done, it gets done > quickly. I think they had a prototype working in a week. > >> Never mind "systemd"; I'm having enough trouble coming to grips with >> "launchd" on the Mac... Gimme /etc/inetd.conf any time. > > Amen, brother. From clemc at ccc.com Thu Aug 30 11:15:33 2018 From: clemc at ccc.com (Clem cole) Date: Wed, 29 Aug 2018 21:15:33 -0400 Subject: [TUHS] cat -v and other complaints In-Reply-To: <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com> References: <20180829233605.GJ8423@mcvoy.com> <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com> Message-ID: <79E2CC9D-1BD5-41F2-A052-FC328E9C3B7E@ccc.com> And I should added I do miss inetd.conf in both cases. Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Aug 29, 2018, at 9:14 PM, Clem cole wrote: > > Truth is I think IBM beat Sun on getting loadable modules for the kernel out first. But I was counting the versions that people really looked at which is why I give Linux credit. > > It makes sense they modeled on SunOS btw but the fact is the Linux version is what folks like *BSD and macOS modeled after later. > > Btw you are 100% right - As for launchd I agree/no doubt - but I’d already given up on MacOS being able to be admin’ed like a Unix box. I can pretty much use it via iterm2 as a user like one and if mostly works as I expect (which I do appreciate). > > Linux is seductive enough to make think I should be able to admin it like I have for the last 40 years and it then bites me when I least expect it. > > Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > >>> On Aug 29, 2018, at 7:36 PM, Larry McVoy wrote: >>> >>>> On Thu, Aug 30, 2018 at 08:34:05AM +1000, Dave Horsfall wrote: >>>> On Wed, 29 Aug 2018, Clem Cole wrote: >>>> That said, I give the Linux folks great credit for the addition of modules >>>> was huge and it took BSD and the other UNIX systems a few years really >>>> pick up that idea in the same way (yes Solaris, Tru64 and eventually HPUX >>>> etc.. had something too but again - my comment about being generally >>>> available applies). >>> >>> Wasn't SunOS first with dynamic kernel modules, or is my memory worse than I >>> thought? Linux may have been around at the time, but we never used in the >>> shop until much later (Red Hat, nicknamed Dead Rat). >> >> Yep. And Linux has loadable modules because I posted the SunOS 4.x man >> pages for the SunOS loadable modules to the kernel list. Proving once >> again that the open source guys aren't always the greatest at coming up >> with the ideas but once you show them that it can be done, it gets done >> quickly. I think they had a prototype working in a week. >> >>> Never mind "systemd"; I'm having enough trouble coming to grips with >>> "launchd" on the Mac... Gimme /etc/inetd.conf any time. >> >> Amen, brother. From kevin.bowling at kev009.com Thu Aug 30 12:43:59 2018 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Wed, 29 Aug 2018 19:43:59 -0700 Subject: [TUHS] cat -v and other complaints In-Reply-To: <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com> References: <20180829233605.GJ8423@mcvoy.com> <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com> Message-ID: AIX takes a lot of shit but there were (and still are) some areas it was quite a bit ahead of its time. I haven't used the ROMP 2.0 version that would have been on the IBM RT.. on my search and todo list. This is interesting because it ran under a hypervisor. The 1.x version for x86 PS/2s is basically Locus. I don't like it. I think it was also used as a common port base for AIX/370 You can run 1.x in VirtualBox with some careful instructions. I'm the canonical source for all this at http://ps-2.kev009.com/aixps2/ But the 3.x version released with POWER/RS6000 in 1990 had a fully pagable kernel, loadable kernel modules[1], logical volume management and disk mirroring, an object oriented thing called the ODM which is probably extremely controversial but a pretty nice for providing KPI/KBI/API compatibility for drivers and subsystems and configuration thereof. It's a good mix of BSD and interesting to see how that was accomplished https://technologists.com/sauer/Convergence_of_AIX_and_4.3BSD.pdf [1] http://bitsavers.org/pdf/ibm/rs6000/aix_3.0/SC23-2207-0_Kernel_Extensions_and_Device_Support_Programming_Concepts_Mar90.pdf See for instance page 6-10 Regards, Kevin On Wed, Aug 29, 2018 at 6:14 PM, Clem cole wrote: > Truth is I think IBM beat Sun on getting loadable modules for the kernel out first. But I was counting the versions that people really looked at which is why I give Linux credit. > > It makes sense they modeled on SunOS btw but the fact is the Linux version is what folks like *BSD and macOS modeled after later. > > Btw you are 100% right - As for launchd I agree/no doubt - but I’d already given up on MacOS being able to be admin’ed like a Unix box. I can pretty much use it via iterm2 as a user like one and if mostly works as I expect (which I do appreciate). > > Linux is seductive enough to make think I should be able to admin it like I have for the last 40 years and it then bites me when I least expect it. > > Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > >> On Aug 29, 2018, at 7:36 PM, Larry McVoy wrote: >> >>> On Thu, Aug 30, 2018 at 08:34:05AM +1000, Dave Horsfall wrote: >>>> On Wed, 29 Aug 2018, Clem Cole wrote: >>>> That said, I give the Linux folks great credit for the addition of modules >>>> was huge and it took BSD and the other UNIX systems a few years really >>>> pick up that idea in the same way (yes Solaris, Tru64 and eventually HPUX >>>> etc.. had something too but again - my comment about being generally >>>> available applies). >>> >>> Wasn't SunOS first with dynamic kernel modules, or is my memory worse than I >>> thought? Linux may have been around at the time, but we never used in the >>> shop until much later (Red Hat, nicknamed Dead Rat). >> >> Yep. And Linux has loadable modules because I posted the SunOS 4.x man >> pages for the SunOS loadable modules to the kernel list. Proving once >> again that the open source guys aren't always the greatest at coming up >> with the ideas but once you show them that it can be done, it gets done >> quickly. I think they had a prototype working in a week. >> >>> Never mind "systemd"; I'm having enough trouble coming to grips with >>> "launchd" on the Mac... Gimme /etc/inetd.conf any time. >> >> Amen, brother. From ggm at algebras.org Thu Aug 30 12:59:07 2018 From: ggm at algebras.org (George Michaelson) Date: Thu, 30 Aug 2018 12:59:07 +1000 Subject: [TUHS] cat -v and other complaints In-Reply-To: References: <20180829233605.GJ8423@mcvoy.com> <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com> Message-ID: if you staid inside the reservation (so to speak) I think AIX made huge sense. I ran the BSD/RT stuff, it was very fine. The documentation was rigorous. If you stuck to the docs, you couldn't go wrong. But it was a frozen moment in time and as X10/X11 moved on, the RT port got older and older. the uni I worked at had a dying IBM mainframe. I think if we'd committed more to the IBM model and dived in, AIX would have worked well. But psych, compsci, engineering, arts/liberal-arts all went to Suns and the computer centre (where I was) had been DEC10/Vax as well as IBM) We were half-pregnant. Its a difficult state to be in. I don't really want to knock AIX, I think compared to the choices HPUX made, or Apollo Domain/OS made, the AIX choices were more self consistent. The unit I ran briefly in the research centre was rock solid and most of my complaints are 'principle of least surprise broken' coming from non-AIX world. I think if you were in it, it was fine. But really, thats the same thing about Solaris. I personally preferred SunOS but the company backed this other model, and if you were in it, the kickstart mechanism to do canned machine deployment, and disk config, and all that goodness, It was fine. I jumped ship well before Sun moved into the 'mainframe' world but I knew people who ran huge non-stop high transactional services on the E1000 series, and were very very happy. Tandem (to riff on that) had its niche. I love the story about sales engineers in the east coast pulling cards on the demo machine to show "look it works" live and the West coast maintenance people tearing their hair out at automatic supply-chain logistics shipping parts over to fix the borked node.. (this is an Aussie story) But I never had to handle the OS. SCO, I did have to work on. As long as you stayed inside the reservation.. No I can't go there. SCO was just awful. From gregg.drwho8 at gmail.com Thu Aug 30 13:03:13 2018 From: gregg.drwho8 at gmail.com (Gregg Levine) Date: Wed, 29 Aug 2018 23:03:13 -0400 Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829032310.GF19128@thunk.org> <20180829050640.GD5698@eureka.lemis.com> <20180829142548.GH19128@thunk.org> <20180829171446.GB16716@ancienthardware.org> Message-ID: Hello! I remember meeting the RT family of machines during the UNIXEXPO cycle of events. Also what DEC was up to. It was both the IBM 6151 RT machines and finally the odd looking design that they turned into. I still have the mouse pad they gave me of a certain Viking working to promote them. I recall that the sales droid at the collection of RT machines was rather vexed that I simply used the telnet command to walk my way across the whole series. I also recall that I was more impressed by the DEC crowd, and was amused by the SUN efforts. You're right as usual Larry, they were working too hard to promote themselves. Kevin I've seen your site before, it is as informative as usual. As for running AIX in a virtual machine, perhaps I will contact you off list to discuss that idea, Kevin. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Wed, Aug 29, 2018 at 7:23 PM, Eric Wayte wrote: > > > On Wed, Aug 29, 2018 at 1:28 PM Arno Griffioen > wrote: >> >> On Wed, Aug 29, 2018 at 10:41:02AM -0400, Dan Cross wrote: >> > I'm curious who was using AOS, which was essentially Tahoe+NFS. >> >> Used it for several years, but on IBM 6151 RT machines and not RS/6000's. >> >> The ROMP CPU in the RT's was a bit of an oddball, but fun to play with >> using an assembler :) >> >> Like many IBM's from the era they had fantastic keyboards though! >> >> Bye, Arno. > > > I remember IBM brought a semi-trailer to my university (UCF) showcasing the > RT back in the 80s. > -- > Eric Wayte From pechter at gmail.com Thu Aug 30 13:59:55 2018 From: pechter at gmail.com (William Pechter) Date: Wed, 29 Aug 2018 23:59:55 -0400 Subject: [TUHS] Cryptic Unix Commands In-Reply-To: <3f239c5d-ea78-6379-c560-9935b856a234@spamtrap.tnetconsulting.net> References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829032310.GF19128@thunk.org> <20180829043639.GA6691@minnie.tuhs.org> <4bd61529-9c48-bd1a-80d7-d4bc6529fcdc@spamtrap.tnetconsulting.net> <415707d1-1b53-4042-a289-630f733f5188.maildroid@localhost> <3f239c5d-ea78-6379-c560-9935b856a234@spamtrap.tnetconsulting.net> Message-ID: The only time I hid something like that was back in my Field Service days. I smoked a third party data comm board which cost $$$$ while trying to replace it. DEC had me do something for one of my customers on a third party hardware install. I had no docs, training or experience with the board. Unfortunately, the vendor didn't key a power cable and I flipped the damned two pin wire blowing the chip top right off the board. Wasn't sure it was my fault. I stayed with the call until they got another board and they got the box up and running and I finally figured I was the cause of the issue. Didn't volunteer the info since I wasn't sure. Probably should've taken the hit. When I did the bad thing I took the hit. One of these was shorting +15v (IIRC) to Init L on the Unibus on an 11/780. Blew the bits off all the boards back to the Unibus termination on the DW780 and out to the M9302 Unibus terminator. Spent the next two days rebuilding the box. I still had a great relationship with the customer for the next 4 years at the site. People understand mistakes and will forgive. Lying to a customer to keep up a corporate image will never be forgotten if you get caught. I remember stealing HDA's off of brand new RA81's at DEC's Princeton HQ to get them out to customer sites before failures in the field from the glue liquification issue. Customers will stand by a company that puts them first and delivers serious effort. Nowadays the outsourced techs are pretty much parts carriers and swappers with no ability to push company deliveries up and often they act as a delaying action until the company can deliver the correct services. Bill -- d|i|g|i|t|a|l had it THEN. Don't you wish you could still buy it now! pechter-at-gmail.com On Wed, Aug 29, 2018 at 7:05 PM Grant Taylor via TUHS wrote: > On 08/29/2018 04:21 PM, William Pechter wrote: > > Did that one at Johnson and Johnson Health Care Systems around '95 as an > > IBM Global Services guy. Ran to the computer room to restart services > > and Oracle on AIX. > > @^*% happens. > > Anybody that tells you it doesn't happen to them is lying. > > > Apologized to the customer. IBM demanded a formal Root Cause Analysis > > for the fat finger with recommendations for avoiding the problem in > > the future. I proposed redesigned ascii keyboards where Q and 1 weren't > > adjacent. > > I remember things like that. > > I always liked to admit things like that to the customer. I felt that > it fostered trust. More than once I went to a customer that trusted me > and told them that something was not me and they took me at my word, > primarily because of that established trust. > > > Management suits not amused. Customer took it as simple accident and > > dealt with the 5-10 minute outage. > > Nice. > > > > -- > Grant. . . . > unix || die > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Thu Aug 30 15:58:01 2018 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Thu, 30 Aug 2018 15:58:01 +1000 Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: <20180829142548.GH19128@thunk.org> Message-ID: <20180830055801.GE5698@eureka.lemis.com> On Wednesday, 29 August 2018 at 10:41:02 -0400, Dan Cross wrote: > On Wed, Aug 29, 2018 at 10:26 AM Theodore Y. Ts'o wrote: > >> On Wed, Aug 29, 2018 at 03:06:40PM +1000, Greg 'groggy' Lehey wrote: >>>> In BSD 4.3 and early Linux (which is when I still was maintaining >>>> Linux's serial driver) you always had to do: >>>> >>>> stty dec < /dev/ttyS0 >>> >>> Checking mckusick's source distribution, it seems that the -f option >>> (along with sanity) came in with 4.4BSD. It was in the original >>> sources imported into FreeBSD. 4.3BSD had such a bizarre syntax that >>> I suspect whatever you emulated must have come from a later date. >> >> BSD 4.4 Lite was released in 1994. (Lite2 was released in 1995.) >> >> Linux was started in 1991, and we had a stty from very early on --- by >> 1992 at the latest. Right, which is why I wrote I suspect whatever you emulated must have come from a later date. In case that wasn't clear, I meant a later date than 4.3BSD. > I think that Greg is slightly mistaken; `stty` had `-f` documented > in Net/2 (1991, though of course the entanglements there have been > discussed), but the option existed in Reno (1990, though it seems to > be absent from the man page). No, this is exactly what I suspected, but was too lazy to check up on. I don't have sources for Tahoe, Reno or Net/2 on my machine, but FreeBSD 1.0 stty.c has: static char sccsid[] = "@(#)stty.c 5.28 (Berkeley) 6/5/91"; And it has the -f flag. This was (just) before the very first version of Linux. My understanding is that FreeBSD 1.0 was primarily derived from Net/2. Of course, there's no reason to have chosen that version. 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 dave at horsfall.org Thu Aug 30 18:28:34 2018 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 30 Aug 2018 18:28:34 +1000 (EST) Subject: [TUHS] Cryptic Unix Commands In-Reply-To: References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829032310.GF19128@thunk.org> <20180829043639.GA6691@minnie.tuhs.org> Message-ID: On Wed, 29 Aug 2018, Grant Taylor via TUHS wrote: > Signal names? I've always used numbers / quit. I don't think I've ever > seen anybody do otherwise. I've never used signal names (other than SIGTERM, when it got changed from 14 to 15 for no good reason that I could see; at least it's now the default signal). -- Dave From ron at ronnatalie.com Thu Aug 30 21:06:22 2018 From: ron at ronnatalie.com (ron at ronnatalie.com) Date: Thu, 30 Aug 2018 07:06:22 -0400 Subject: [TUHS] Cryptic Unix Commands In-Reply-To: References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829032310.GF19128@thunk.org> <20180829043639.GA6691@minnie.tuhs.org> Message-ID: <051a01d44051$7d7909c0$786b1d40$@ronnatalie.com> I use the numbers but I think it stems from the days when kill didn't take the names. It's easier for me to remember -1 and -9 than to remember what the mnemonics are. > -----Original Message----- > From: TUHS On Behalf Of Dave Horsfall > Sent: Wednesday, August 29, 2018 6:04 PM > To: The Eunuchs Hysterical Society > Subject: Re: [TUHS] Cryptic Unix Commands > > On Wed, 29 Aug 2018, Warren Toomey wrote: > > > This reminded me of other semi-cryptic commands. I remember mistyping > > "kill -1 1" as "kill -9 1" with the inevitable consequences. > > Hands up all those who have *not* done that... > > -- Dave From jpl.jpl at gmail.com Thu Aug 30 21:35:51 2018 From: jpl.jpl at gmail.com (John P. Linderman) Date: Thu, 30 Aug 2018 07:35:51 -0400 Subject: [TUHS] Cryptic Unix Commands In-Reply-To: <051a01d44051$7d7909c0$786b1d40$@ronnatalie.com> References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829032310.GF19128@thunk.org> <20180829043639.GA6691@minnie.tuhs.org> <051a01d44051$7d7909c0$786b1d40$@ronnatalie.com> Message-ID: I remember doing a fresh install of unix on a VAX with another sysadmin. We had spent a couple hours getting everything ready to go, and he had created a bunch of temporary directories under /tmp to hold intermediate work. All started with ".", so, in /tmp, he entered "rm -r .*". Unfortunately, that matched .. as well. We knew something had gone very wrong when we got a "/bin/rm: text busy" message as rm tried to remove itself. On Thu, Aug 30, 2018 at 7:06 AM, wrote: > I use the numbers but I think it stems from the days when kill didn't take > the names. It's easier for me to remember -1 and -9 than to remember > what > the mnemonics are. > > > > -----Original Message----- > > From: TUHS On Behalf Of Dave Horsfall > > Sent: Wednesday, August 29, 2018 6:04 PM > > To: The Eunuchs Hysterical Society > > Subject: Re: [TUHS] Cryptic Unix Commands > > > > On Wed, 29 Aug 2018, Warren Toomey wrote: > > > > > This reminded me of other semi-cryptic commands. I remember mistyping > > > "kill -1 1" as "kill -9 1" with the inevitable consequences. > > > > Hands up all those who have *not* done that... > > > > -- Dave > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Thu Aug 30 23:14:17 2018 From: imp at bsdimp.com (Warner Losh) Date: Thu, 30 Aug 2018 07:14:17 -0600 Subject: [TUHS] Research UNIX on the AT&T 3B2? In-Reply-To: <20180830055801.GE5698@eureka.lemis.com> References: <20180829142548.GH19128@thunk.org> <20180830055801.GE5698@eureka.lemis.com> Message-ID: On Wed, Aug 29, 2018 at 11:58 PM Greg 'groggy' Lehey wrote: > > I think that Greg is slightly mistaken; `stty` had `-f` documented > > in Net/2 (1991, though of course the entanglements there have been > > discussed), but the option existed in Reno (1990, though it seems to > > be absent from the man page). > > No, this is exactly what I suspected, but was too lazy to check up on. > I don't have sources for Tahoe, Reno or Net/2 on my machine, but > FreeBSD 1.0 stty.c has: > > static char sccsid[] = "@(#)stty.c 5.28 (Berkeley) 6/5/91"; > > And it has the -f flag. This was (just) before the very first version > of Linux. My understanding is that FreeBSD 1.0 was primarily derived > from Net/2. Of course, there's no reason to have chosen that version. > Net/2 was the basis of 386BSD, which begat the patchkits, which begat FreeBSD and NetBSD. One of the problems with early Linux was that they were just a bunch of guys (and sometimes gals) that had access to these cool unix systems. At the time, there was quite the lag between release by research / university and running in a commercial Unix. So in the early 1990s, there were a bunch of systems based on 4.2BSD, as well as many based on System V, which lacked the -f flag. At the time, it was at the end of the isolated phase of Unix, where people just made stuff up in relative isolation and when the cross pollination effects of USENET and the first Unix converts having had a decade or so under their belts. The Linux guys weren't old-time Bell Labs guys that would know the differences in detail between the different strains, especially the people that were writing one-off utilities, often to an old, out of date man page, that Linux encouraged to contribute. Nothing wrong with all that, it was a crazy time trying to recreate things at a mile a minute. But some details were not faithfully emulated. It's not surprising: there was always so much to do. So while it existed when they started, it's unlikely the knowledge had diffused enough for them to know about it when it came time to code... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Aug 30 23:24:48 2018 From: clemc at ccc.com (Clem Cole) Date: Thu, 30 Aug 2018 09:24:48 -0400 Subject: [TUHS] Cryptic Unix Commands In-Reply-To: <051a01d44051$7d7909c0$786b1d40$@ronnatalie.com> References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829032310.GF19128@thunk.org> <20180829043639.GA6691@minnie.tuhs.org> <051a01d44051$7d7909c0$786b1d40$@ronnatalie.com> Message-ID: On Thu, Aug 30, 2018 at 7:07 AM wrote: > I use the numbers but I think it stems from the days when kill didn't take > the names. It's easier for me to remember -1 and -9 than to remember > what > the mnemonics are. > Same here - there first time I saw the mnemonics were in the built-in kill command in csh. Which was usefule for "kill -cont" but to this day, since like Ron I grew on fifth/sixth/seventh edition which used numbers, the ones that I remember and care about are screwed into my fingers. I never have an issue with -1 vs -9 with kill, but I do not have great story about how as a young engineer I wiped out the life's work of visiting professor because Tektronix had the 0 and 1 keys next to each other on one of the terminals they made. It was the console of our 11/60 and we had two RK05's and I fat fingured /dev/r...0 instead of 1. Bad stuff. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From pechter at gmail.com Fri Aug 31 00:31:56 2018 From: pechter at gmail.com (William Pechter) Date: Thu, 30 Aug 2018 10:31:56 -0400 Subject: [TUHS] Cryptic Unix Commands In-Reply-To: References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829032310.GF19128@thunk.org> <20180829043639.GA6691@minnie.tuhs.org> <051a01d44051$7d7909c0$786b1d40$@ronnatalie.com> Message-ID: At least in the old days drives had Write Protect switches. Screw IBM for the in cable drive select lines on diskette and leaving off Write Protect on hard disks.  Some disks had write protect jumpers on the boards... They should have been The STANDARD. Bill ⁣Sent from BlueMail ​ On Aug 30, 2018, 09:25, at 09:25, Clem Cole wrote: >On Thu, Aug 30, 2018 at 7:07 AM wrote: > >> I use the numbers but I think it stems from the days when kill didn't >take >> the names. It's easier for me to remember -1 and -9 than to >remember >> what >> the mnemonics are. >> >Same here - there first time I saw the mnemonics were in the built-in >kill >command in csh. Which was usefule for "kill -cont" > >but to this day, since like Ron I grew on fifth/sixth/seventh edition >which >used numbers, the ones that I remember and care about are screwed into >my >fingers. > >I never have an issue with -1 vs -9 with kill, but I do not have great >story about how as a young engineer I wiped out the life's work of >visiting >professor because Tektronix had the 0 and 1 keys next to each other on >one >of the terminals they made. It was the console of our 11/60 and we had >two >RK05's and I fat fingured /dev/r...0 instead of 1. Bad stuff. > >Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Aug 31 01:01:58 2018 From: clemc at ccc.com (Clem Cole) Date: Thu, 30 Aug 2018 11:01:58 -0400 Subject: [TUHS] Cryptic Unix Commands In-Reply-To: References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829032310.GF19128@thunk.org> <20180829043639.GA6691@minnie.tuhs.org> <051a01d44051$7d7909c0$786b1d40$@ronnatalie.com> Message-ID: On Thu, Aug 30, 2018 at 10:31 AM William Pechter wrote: > At least in the old days drives had Write Protect switches. > Not the issue - both disks were RW. I was running as root and ran a program that lacked a check it shoud have had it (because I was lazy and never put it in there). > Screw IBM for the in cable drive select lines on diskette > You of course realized that was because of field service issues of course. Setting all floppies (and later ST-506 disks) on the PC and using a twist in the cable meant they did not have to ask FS folks to set the jumpers properly. > and leaving off Write Protect on hard disks. Some disks had write protect > jumpers on the boards... > Hmmm.. I thought all disks at least had a strap. WD, CDC, Seagate, Shuggart, Toshiba all supported the strap. The IBM disks I remember did not also, but I'll take your word for it, it would have been like them to have removed it to save the connector cost. > They should have been The STANDARD. > Hmmm.. I'm not at home, but I think I have both the ST-412/506 and ESDI specs in a filing cab somewhere. I thought the standard did defined it. (Intel blocks 'bitsavers.org' for some reason so I can not look online but I think http://www.bitsavers.org/pdf/seagate/ST412_OEMmanual_Apr82.pdf is likely to have it in there). Clem > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Fri Aug 31 01:22:05 2018 From: imp at bsdimp.com (Warner Losh) Date: Thu, 30 Aug 2018 09:22:05 -0600 Subject: [TUHS] Cryptic Unix Commands In-Reply-To: References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829032310.GF19128@thunk.org> <20180829043639.GA6691@minnie.tuhs.org> <051a01d44051$7d7909c0$786b1d40$@ronnatalie.com> Message-ID: On Thu, Aug 30, 2018 at 9:03 AM Clem Cole wrote: > On Thu, Aug 30, 2018 at 10:31 AM William Pechter > wrote: > >> Screw IBM for the in cable drive select lines on diskette >> > You of course realized that was because of field service issues of > course. Setting all floppies (and later ST-506 disks) on the PC and using > a twist in the cable meant they did not have to ask FS folks to set the > jumpers properly. > Ah yes, the original zeroconfig :) Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From pechter at gmail.com Fri Aug 31 02:11:19 2018 From: pechter at gmail.com (William Pechter) Date: Thu, 30 Aug 2018 12:11:19 -0400 Subject: [TUHS] Cryptic Unix Commands In-Reply-To: References: <20180828003057.GA317@mcvoy.com> <201808280601.w7S61oLM030628@freefriends.org> <20180829032310.GF19128@thunk.org> <20180829043639.GA6691@minnie.tuhs.org> <051a01d44051$7d7909c0$786b1d40$@ronnatalie.com> Message-ID: <0f8a883d-fd7d-4d39-bca9-b33f16195e00.maildroid@localhost> Early plug and play. Would have worked better if they trained the PC techs in how the stuff worked. Bill Old ex-tech turned sysadmin -----Original Message----- From: Warner Losh To: Clem Cole Cc: William Pechter , The Eunuchs Hysterical Society Sent: Thu, 30 Aug 2018 11:22 Subject: Re: [TUHS] Cryptic Unix Commands On Thu, Aug 30, 2018 at 9:03 AM Clem Cole wrote: > On Thu, Aug 30, 2018 at 10:31 AM William Pechter > wrote: > >> Screw IBM for the in cable drive select lines on diskette >> > You of course realized that was because of field service issues of > course. Setting all floppies (and later ST-506 disks) on the PC and using > a twist in the cable meant they did not have to ask FS folks to set the > jumpers properly. > Ah yes, the original zeroconfig :) Warner From michael at kjorling.se Fri Aug 31 03:54:20 2018 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Thu, 30 Aug 2018 17:54:20 +0000 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: References: Message-ID: <20180830175420.3zs4gpyacsgrh7wc@h-174-65.A328.priv.bahnhof.se> On 29 Aug 2018 11:25 -0600, from tuhs at minnie.tuhs.org (Grant Taylor via TUHS): > Our hopes are for RetroNet to be able to provide a sandbox / small pool / > isolated network where members can interconnect with each other (if they > want to) similar to the Internet, but with much less exposure. (We are > planing on RetroNet not having direct Internet connectivity.) We are also > hoping and planing to be able to carry any Ethernet based traffic between > sites, routed or not. This sounds interesting, but I'm not sure if I'd be eligible. What would be the entry criteria? 20 years professional experience as sysadmin on 4.3BSD? Physical PDP-11/780 running in the closet? -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “The most dangerous thought that you can have as a creative person is to think you know what you’re doing.” (Bret Victor) From mutiny.mutiny at india.com Fri Aug 31 04:05:32 2018 From: mutiny.mutiny at india.com (Donald ODona) Date: Thu, 30 Aug 2018 18:05:32 +0000 (UTC) Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: References: Message-ID: <1885206673.248929.1535652332688.JavaMail.tomcat@india-live-be04> > > The idea behind RetroNet is two fold: > > 1) Create a network of interconnected VPNs between interested parties. > 2) Provide ISP like services over said interconnections. we have that already. One of these is https://livingcomputers.org/ From gtaylor at tnetconsulting.net Fri Aug 31 04:11:17 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 30 Aug 2018 12:11:17 -0600 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: <20180830175420.3zs4gpyacsgrh7wc@h-174-65.A328.priv.bahnhof.se> References: <20180830175420.3zs4gpyacsgrh7wc@h-174-65.A328.priv.bahnhof.se> Message-ID: <49620ace-ca66-c288-2ab3-3a0fe4af640e@spamtrap.tnetconsulting.net> On 08/30/2018 11:54 AM, Michael Kjörling wrote: > This sounds interesting, but I'm not sure if I'd be eligible. I bet that you do. > What would be the entry criteria? 20 years professional experience as > sysadmin on 4.3BSD? Physical PDP-11/780 running in the closet? Valid question. I'm of the opinion that the entry criteria are a client that can talk to the RetroNet network (more on that in a moment) and a desire to participate. I'll also say that a healthy interest / curiosity in anything that runs over / through RetroNet would be beneficial. But if you want to use RetroNet to play Doom across IPX with buddies across town, then you should be able to do so. (Assuming that you and your buddies are RetroNet members.) As for client, I'm initially targeting something like a Raspberry Pi or any SOHO router that will run OpenWRT / DD-WRT / Tomato. Ideally I'd like to re-use existing images (possibly with a different kernel) and add on packages. I'd like those to be the almost-turn-key installations. Almost as in you start with that and do some things on top. If you want to roll your own Linux install that supports the documented specifications, then more power to you. One of the purposes of RetroNet is to enable members to be able to participate and use the RetroNet for what ever they want (as long as it's legal and does not adversely effect RetroNet or members). Another purpose for RetroNet is to provide a network that we can provide a safe environment for people that want to learn things and help / encouragement to do so. Sort of like a mentor in a sandbox. Aside: I've been using the term "member". I don't want that to convey any meaning other than someone that has signed up and has a RetroNet account. I'm not anticipating any membership fees or anything like that. Down the road we may set up something like a tip jar to help cover costs like domain name subscription or other nominal costs. In short, if you want to play in the sand box and you play well with others, come on down. Let's have fun, learn, play. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From lm at mcvoy.com Fri Aug 31 04:15:05 2018 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 30 Aug 2018 11:15:05 -0700 Subject: [TUHS] RetroNet??? In-Reply-To: <49620ace-ca66-c288-2ab3-3a0fe4af640e@spamtrap.tnetconsulting.net> References: <20180830175420.3zs4gpyacsgrh7wc@h-174-65.A328.priv.bahnhof.se> <49620ace-ca66-c288-2ab3-3a0fe4af640e@spamtrap.tnetconsulting.net> Message-ID: <20180830181505.GB26771@mcvoy.com> On Thu, Aug 30, 2018 at 12:11:17PM -0600, Grant Taylor via TUHS wrote: > In short, if you want to play in the sand box and you play well with others, > come on down. Let's have fun, learn, play. Ought to be rules for life in general. From gtaylor at tnetconsulting.net Fri Aug 31 04:15:50 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 30 Aug 2018 12:15:50 -0600 Subject: [TUHS] RetroNet??? In-Reply-To: <20180830181505.GB26771@mcvoy.com> References: <20180830175420.3zs4gpyacsgrh7wc@h-174-65.A328.priv.bahnhof.se> <49620ace-ca66-c288-2ab3-3a0fe4af640e@spamtrap.tnetconsulting.net> <20180830181505.GB26771@mcvoy.com> Message-ID: <00479e23-5332-1976-dbbe-db896499992d@spamtrap.tnetconsulting.net> On 08/30/2018 12:15 PM, Larry McVoy wrote: > Ought to be rules for life in general. ***AGREED*** -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From gtaylor at tnetconsulting.net Fri Aug 31 04:17:50 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 30 Aug 2018 12:17:50 -0600 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: <1885206673.248929.1535652332688.JavaMail.tomcat@india-live-be04> References: <1885206673.248929.1535652332688.JavaMail.tomcat@india-live-be04> Message-ID: <5966a12b-f998-2c6a-a571-fbf06e8fcb19@spamtrap.tnetconsulting.net> On 08/30/2018 12:05 PM, Donald ODona wrote: > we have that already. One of these is https://livingcomputers.org/ Nothing on the Living Computers website seemed even close to what I'm envisioning RetroNet to be. Would you please clarify what you're referring to? Or provide a better link to a page talking about the internetworking of individual home computers? TL;DR: RetroNet is meant to enable friends to interconnect their computers (what ever they are) at their houses to do what ever they want. One of the uses of said network is to allow people who want to learn how to set up a web / email / dns / etc server to be able to do it in a safe place (read: NOT the Internet) with help from mentors. I don't get the impression that any of that when I skim the Living Computers website. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From jnc at mercury.lcs.mit.edu Fri Aug 31 05:41:06 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 30 Aug 2018 15:41:06 -0400 (EDT) Subject: [TUHS] SunOS code? Message-ID: <20180830194106.9E57818C0A2@mercury.lcs.mit.edu> > From: Clem Cole > The problem is finding some at Oracle that would care Well, I've got a nephew who's been at Oracle for like 20+ years; he can probably point us at the right person. > and finding a proper distribution tape to officially release. Why do we need that? Can't they say 'any and all versions of SunOS', and that term ('SunOS') is sufficiently well defined in real-world documents (e.g. Sun licenses) that that should be 'good enough'. It sounds like the _actual code_ is reasonably available, we wouldn't need Oracle to go looking around for it, would we? Noel From lm at mcvoy.com Fri Aug 31 05:46:56 2018 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 30 Aug 2018 12:46:56 -0700 Subject: [TUHS] SunOS code? In-Reply-To: <20180830194106.9E57818C0A2@mercury.lcs.mit.edu> References: <20180830194106.9E57818C0A2@mercury.lcs.mit.edu> Message-ID: <20180830194656.GA664@mcvoy.com> On Thu, Aug 30, 2018 at 03:41:06PM -0400, Noel Chiappa wrote: > It sounds like the _actual code_ is reasonably available, we wouldn't need > Oracle to go looking around for it, would we? I'd really like the SCCS history. From jnc at mercury.lcs.mit.edu Fri Aug 31 05:54:39 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 30 Aug 2018 15:54:39 -0400 (EDT) Subject: [TUHS] SunOS code? Message-ID: <20180830195439.2533318C0A2@mercury.lcs.mit.edu> > From: Larry McVoy > I'd really like the SCCS history. Any idea if that even still exists, or did it get shredded somewhere along the way? Anyway, should I spin up my nephew on trying to find the right person to put out a historic, personal-use license? Noel From imp at bsdimp.com Fri Aug 31 06:04:10 2018 From: imp at bsdimp.com (Warner Losh) Date: Thu, 30 Aug 2018 14:04:10 -0600 Subject: [TUHS] SunOS code? In-Reply-To: <20180830194106.9E57818C0A2@mercury.lcs.mit.edu> References: <20180830194106.9E57818C0A2@mercury.lcs.mit.edu> Message-ID: On Thu, Aug 30, 2018 at 1:41 PM Noel Chiappa wrote: > > and finding a proper distribution tape to officially release. > > Why do we need that? Can't they say 'any and all versions of SunOS', and > that > term ('SunOS') is sufficiently well defined in real-world documents (e.g. > Sun > licenses) that that should be 'good enough'. > > It sounds like the _actual code_ is reasonably available, we wouldn't need > Oracle to go looking around for it, would we? > The trouble, as I was given to understand when I worked at Solbourne, was that SunOS wasn't just AT&T + BSD 4.2 + 4.3 + awesome hacking at SMI. There were a number of third party bits and pieces in there that could not be relicensed, even 28 years ago when things were fresh. Good luck getting those third party permissions now... Sun's paid-up Unix license they did for Solaris would cover any bits of AT&T code that was in there. A quick grep of something that fell off an http server suggests that the number of these is quite limited. However, the files they are on have no other license, even though latter-day versions are available of hack, hunt, indent and pax are available (though to be fair, the latter two do give permission explicitly, and a good case can be made for hunt). I have no way of knowing, however, if there are other IP issues, not limited to unmarked sources, copyright notices that aren't 'well formed', code that's been hacked by third parties under a contract granting them copyright ownership and sun just a license, etc. It's that quagmire that efforts like this will run up against. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From earl.baugh at gmail.com Fri Aug 31 06:05:14 2018 From: earl.baugh at gmail.com (Earl Baugh) Date: Thu, 30 Aug 2018 16:05:14 -0400 Subject: [TUHS] SunOS code? In-Reply-To: <20180830195439.2533318C0A2@mercury.lcs.mit.edu> References: <20180830195439.2533318C0A2@mercury.lcs.mit.edu> Message-ID: I’d be interested. Especially for my Sun 1/100 Earl. Sent from my iPhone On Aug 30, 2018, at 3:54 PM, Noel Chiappa wrote: >> From: Larry McVoy > >> I'd really like the SCCS history. > > Any idea if that even still exists, or did it get shredded somewhere along the > way? > > Anyway, should I spin up my nephew on trying to find the right person to put > out a historic, personal-use license? > > Noel From lm at mcvoy.com Fri Aug 31 06:22:00 2018 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 30 Aug 2018 13:22:00 -0700 Subject: [TUHS] SunOS code? In-Reply-To: References: <20180830194106.9E57818C0A2@mercury.lcs.mit.edu> Message-ID: <20180830202200.GC664@mcvoy.com> On Thu, Aug 30, 2018 at 02:04:10PM -0600, Warner Losh wrote: > On Thu, Aug 30, 2018 at 1:41 PM Noel Chiappa > wrote: > > > > and finding a proper distribution tape to officially release. > > > > Why do we need that? Can't they say 'any and all versions of SunOS', and > > that > > term ('SunOS') is sufficiently well defined in real-world documents (e.g. > > Sun > > licenses) that that should be 'good enough'. > > > > It sounds like the _actual code_ is reasonably available, we wouldn't need > > Oracle to go looking around for it, would we? > > > > The trouble, as I was given to understand when I worked at Solbourne, was > that SunOS wasn't just AT&T + BSD 4.2 + 4.3 + awesome hacking at SMI. > There were a number of third party bits and pieces in there that could not > be relicensed, even 28 years ago when things were fresh. So I've been down this path, it was STREAMS and RFS, and maybe a couple of drivers. I pulled all that crud out, put back the BSD tty code, and I had a SunOS we could have given away. It was back when I was writing this: http://mcvoy.com/lm/bitmover/lm/papers/freeos.pdf and I needed to be able to show that what I was asking for was possible. > A quick grep of something that fell off an http server suggests that the > number of these is quite limited. However, the files they are on have no > other license, even though latter-day versions are available of hack, hunt, > indent and pax are available (though to be fair, the latter two do give > permission explicitly, and a good case can be made for hunt). So you are including userland. I'm not sure you need to. Yeah, there was some unicode work done there but quite frankly, I'd just have /usr/gnu/bin /usr/bsd/bin /usr/sun/bin and dump anything questionable in sun/bin. It's the kernel that was the most interesting, next would be the run time loader and shared libraries. /usr/bin wasn't that exciting, the BSD purists might want that but I gotta believe that BSD has caught up to Sun in 25 years (right???). From norman at oclsc.org Fri Aug 31 06:26:20 2018 From: norman at oclsc.org (Norman Wilson) Date: Thu, 30 Aug 2018 16:26:20 -0400 Subject: [TUHS] changes in C compilers Message-ID: <1535660784.15121.for-standards-violators@oclsc.org> Clem Cole: Clearly from the time, ditroff did not yet exist. The more I think about it, Brian K actually might know some of the story. === I'm quite sure Brian Kernighan knows the full story of the origins of typesetter-independent troff (as it was originally called, in CSTR 97, published in 1981; the binary was just /usr/bin/troff). The reason I'm so sure of that is that it was Brian who rewrote troff to bring it into the modern era and to make it supportable. He's also the author of the CSTR. Norman Wilson Toronto ON From clemc at ccc.com Fri Aug 31 06:33:06 2018 From: clemc at ccc.com (Clem Cole) Date: Thu, 30 Aug 2018 16:33:06 -0400 Subject: [TUHS] SunOS code? In-Reply-To: <20180830202200.GC664@mcvoy.com> References: <20180830194106.9E57818C0A2@mercury.lcs.mit.edu> <20180830202200.GC664@mcvoy.com> Message-ID: On Thu, Aug 30, 2018 at 4:22 PM Larry McVoy wrote: > > > So I've been down this path, it was STREAMS and RFS, and maybe a couple > of drivers. I pulled all that crud out, put back the BSD tty code, > and I had a SunOS we could have given away. It was back when I was > writing this: > > http://mcvoy.com/lm/bitmover/lm/papers/freeos.pdf > > and I needed to be able to show that what I was asking for was possible. > Good to know you think it was possible. I know in the case of Ultrix and HP-UX lots of external folks licenses small things like Mentat, MIPS etc. For instance, one of the Ultrix and Alpha bug-a-boos was the MIPS compiler, which leaked into the IP stream along the way. As far as I remember from my Locus days when we had just about everybody's sources from IBM to Sun, the problem was the license was not just the OEM and AT&T, there was always the sub-licenses from some deal or another that the OEM had cut at some point. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Fri Aug 31 06:36:21 2018 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 30 Aug 2018 13:36:21 -0700 Subject: [TUHS] SunOS code? In-Reply-To: References: <20180830194106.9E57818C0A2@mercury.lcs.mit.edu> <20180830202200.GC664@mcvoy.com> Message-ID: <20180830203621.GE664@mcvoy.com> On Thu, Aug 30, 2018 at 04:33:06PM -0400, Clem Cole wrote: > On Thu, Aug 30, 2018 at 4:22 PM Larry McVoy wrote: > > So I've been down this path, it was STREAMS and RFS, and maybe a couple > > of drivers. I pulled all that crud out, put back the BSD tty code, > > and I had a SunOS we could have given away. It was back when I was > > writing this: > > > > http://mcvoy.com/lm/bitmover/lm/papers/freeos.pdf > > > > and I needed to be able to show that what I was asking for was possible. > > Good to know you think it was possible. I know in the case of Ultrix and > HP-UX lots of external folks licenses small things like Mentat, MIPS etc. At this point, Linux has won, I don't think anyone would care if we got the whole pile. As Rob Gingell once said "Bits rot. Unmaintained source quickly becomes worthless". From clemc at ccc.com Fri Aug 31 06:37:47 2018 From: clemc at ccc.com (Clem Cole) Date: Thu, 30 Aug 2018 16:37:47 -0400 Subject: [TUHS] SunOS code? In-Reply-To: <20180830194106.9E57818C0A2@mercury.lcs.mit.edu> References: <20180830194106.9E57818C0A2@mercury.lcs.mit.edu> Message-ID: below... On Thu, Aug 30, 2018 at 3:41 PM Noel Chiappa wrote: > > From: Clem Cole > > > The problem is finding some at Oracle that would care > > Well, I've got a nephew who's been at Oracle for like 20+ years; he can > probably point us at the right person. > > > and finding a proper distribution tape to officially release. > > Why do we need that? Can't they say 'any and all versions of SunOS', and > that > term ('SunOS') is sufficiently well defined in real-world documents (e.g. > Sun > licenses) that that should be 'good enough'. > > Two issues: 1.) what consitutes release X or Y and 2) sublicenses. For the former, Sun did have source distributions, typically for Universities and certain OEMs. Stellar had a 4.x license for the Sun3s but I can not tell you which one (we used Sun3's as the porting base and wanted the basic Sun3 support from SunOS to support it as we developed Stellix). For the later, we need to make sure you have the whole thing. Most OEM's had stuff from other firms, from compilers to whole subsystems. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Fri Aug 31 06:38:39 2018 From: imp at bsdimp.com (Warner Losh) Date: Thu, 30 Aug 2018 14:38:39 -0600 Subject: [TUHS] SunOS code? In-Reply-To: <20180830202200.GC664@mcvoy.com> References: <20180830194106.9E57818C0A2@mercury.lcs.mit.edu> <20180830202200.GC664@mcvoy.com> Message-ID: On Thu, Aug 30, 2018 at 2:22 PM Larry McVoy wrote: > On Thu, Aug 30, 2018 at 02:04:10PM -0600, Warner Losh wrote: > > On Thu, Aug 30, 2018 at 1:41 PM Noel Chiappa > > wrote: > > > > > > and finding a proper distribution tape to officially release. > > > > > > Why do we need that? Can't they say 'any and all versions of SunOS', > and > > > that > > > term ('SunOS') is sufficiently well defined in real-world documents > (e.g. > > > Sun > > > licenses) that that should be 'good enough'. > > > > > > It sounds like the _actual code_ is reasonably available, we wouldn't > need > > > Oracle to go looking around for it, would we? > > > > > > > The trouble, as I was given to understand when I worked at Solbourne, was > > that SunOS wasn't just AT&T + BSD 4.2 + 4.3 + awesome hacking at SMI. > > There were a number of third party bits and pieces in there that could > not > > be relicensed, even 28 years ago when things were fresh. > > So I've been down this path, it was STREAMS and RFS, and maybe a couple > of drivers. I pulled all that crud out, put back the BSD tty code, > and I had a SunOS we could have given away. Why would STREAMS and RFS be a problem post OpenSolaris? > It was back when I was > writing this: > > http://mcvoy.com/lm/bitmover/lm/papers/freeos.pdf > > and I needed to be able to show that what I was asking for was possible. > > > A quick grep of something that fell off an http server suggests that the > > number of these is quite limited. However, the files they are on have no > > other license, even though latter-day versions are available of hack, > hunt, > > indent and pax are available (though to be fair, the latter two do give > > permission explicitly, and a good case can be made for hunt). > > So you are including userland. I'm not sure you need to. Yeah, there was > some unicode work done there but quite frankly, I'd just have > > /usr/gnu/bin > /usr/bsd/bin > /usr/sun/bin > > and dump anything questionable in sun/bin. It's the kernel that was the > most interesting, next would be the run time loader and shared libraries. > /usr/bin wasn't that exciting, the BSD purists might want that but I gotta > believe that BSD has caught up to Sun in 25 years (right???). > grep -r was easy :). Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Aug 31 06:40:49 2018 From: clemc at ccc.com (Clem Cole) Date: Thu, 30 Aug 2018 16:40:49 -0400 Subject: [TUHS] SunOS code? In-Reply-To: <20180830203621.GE664@mcvoy.com> References: <20180830194106.9E57818C0A2@mercury.lcs.mit.edu> <20180830202200.GC664@mcvoy.com> <20180830203621.GE664@mcvoy.com> Message-ID: On Thu, Aug 30, 2018 at 4:36 PM Larry McVoy wrote: > > As Rob Gingell once said "Bits rot. Unmaintained source quickly becomes > worthless". > Yep. So the question goes back to what is SunOS 4.x.y. You seem to be thinking in terms of looking at the kernel from those days (which is a fine definition), but others said - hey I want to run this on my X or Y system. That's a different definition I think. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Fri Aug 31 06:42:23 2018 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 30 Aug 2018 13:42:23 -0700 Subject: [TUHS] SunOS code? In-Reply-To: References: <20180830194106.9E57818C0A2@mercury.lcs.mit.edu> <20180830202200.GC664@mcvoy.com> Message-ID: <20180830204223.GF664@mcvoy.com> On Thu, Aug 30, 2018 at 02:38:39PM -0600, Warner Losh wrote: > > I pulled all that crud out, put back the BSD tty code, > > and I had a SunOS we could have given away. > > Why would STREAMS and RFS be a problem post OpenSolaris? That was then, this is now. Back then they were definitely a problem. I nuked all the AT&T Sys V stuff in the kernel because that had perceived value to AT&T, they still thought Sys V was going to rule the world. So I took us back to BSD + Sun's work. Which was a more pleasant place anyway IMO. From lm at mcvoy.com Fri Aug 31 06:43:32 2018 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 30 Aug 2018 13:43:32 -0700 Subject: [TUHS] SunOS code? In-Reply-To: References: <20180830194106.9E57818C0A2@mercury.lcs.mit.edu> <20180830202200.GC664@mcvoy.com> <20180830203621.GE664@mcvoy.com> Message-ID: <20180830204332.GG664@mcvoy.com> On Thu, Aug 30, 2018 at 04:40:49PM -0400, Clem Cole wrote: > On Thu, Aug 30, 2018 at 4:36 PM Larry McVoy wrote: > > > > > As Rob Gingell once said "Bits rot. Unmaintained source quickly becomes > > worthless". > > > Yep. So the question goes back to what is SunOS 4.x.y. You seem to be > thinking in terms of looking at the kernel from those days (which is a fine > definition), but others said - hey I want to run this on my X or Y system. > That's a different definition I think. I suspect that if SunOS got any traction it would be the kernel plus maybe their shared libs and the Linux user space. And it would need to be ported to x86_64. From clemc at ccc.com Fri Aug 31 06:43:59 2018 From: clemc at ccc.com (Clem Cole) Date: Thu, 30 Aug 2018 16:43:59 -0400 Subject: [TUHS] SunOS code? In-Reply-To: <20180830204223.GF664@mcvoy.com> References: <20180830194106.9E57818C0A2@mercury.lcs.mit.edu> <20180830202200.GC664@mcvoy.com> <20180830204223.GF664@mcvoy.com> Message-ID: On Thu, Aug 30, 2018 at 4:42 PM Larry McVoy wrote: > > So I took us back to BSD + Sun's work. Which was a more pleasant place > anyway IMO. > Certainly easier to understand ;-) ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Aug 31 06:48:24 2018 From: clemc at ccc.com (Clem Cole) Date: Thu, 30 Aug 2018 16:48:24 -0400 Subject: [TUHS] changes in C compilers In-Reply-To: <1535660784.15121.for-standards-violators@oclsc.org> References: <1535660784.15121.for-standards-violators@oclsc.org> Message-ID: On Thu, Aug 30, 2018 at 4:27 PM Norman Wilson wrote: > Clem Cole: > > Clearly from the time, ditroff did not yet exist. The more I think > about > it, Brian K actually might know some of the story. > > === > > I'm quite sure Brian Kernighan knows the full story of the origins That was not what I was saying.... (yes, I know Brian wrote ditroff and have spoken at length to him about actually). What, I was saying since he was Brian Ried's advisor on Scribe (during that timeframe BTW), he might know some of the other details I refered too. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Fri Aug 31 07:34:07 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 30 Aug 2018 17:34:07 -0400 (EDT) Subject: [TUHS] SunOS code? Message-ID: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu> > From: Warner Losh > The trouble, as I was given to understand when I worked at Solbourne, > was that ... There were a number of third party bits and pieces in there > that could not be relicensed ... if there are other IP issues, not > limited ... It's that quagmire that efforts like this will run up > against. Oh, we'll just ask Oracle for a license 'for all parts of SunOS for which they have the ability to grant a licence'. There's no way I'd want them to have to chase down all the corner cases, that's just a way to guarantee it will never happen. I'd want to ask for the bare minimum of time/effort on their part. Anything above that, probably the SCCS stuff would be next on the priority list, sounds like. Noel From dave at horsfall.org Fri Aug 31 09:42:15 2018 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 31 Aug 2018 09:42:15 +1000 (EST) Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: <49620ace-ca66-c288-2ab3-3a0fe4af640e@spamtrap.tnetconsulting.net> References: <20180830175420.3zs4gpyacsgrh7wc@h-174-65.A328.priv.bahnhof.se> <49620ace-ca66-c288-2ab3-3a0fe4af640e@spamtrap.tnetconsulting.net> Message-ID: On Thu, 30 Aug 2018, Grant Taylor via TUHS wrote: [ Excellent screed elided ] > In short, if you want to play in the sand box and you play well with > others, come on down. Let's have fun, learn, play. Count me in; as a reborn electronics enthusiast (and a Unix user since Edition 5) I've been looking for an excuse to buy a Raspberry Pi (as opposed to the usual articles in the usual magazines), and this sounds just the ticket! And if subdomains are available then of course I'll contribute (as if I wouldn't anyway). -- Dave (VK2KFU) From dave at horsfall.org Fri Aug 31 10:27:20 2018 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 31 Aug 2018 10:27:20 +1000 (EST) Subject: [TUHS] cat -v and other complaints In-Reply-To: References: <20180829233605.GJ8423@mcvoy.com> <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com> Message-ID: On Wed, 29 Aug 2018, Kevin Bowling wrote: > AIX takes a lot of shit but there were (and still are) some areas it was > quite a bit ahead of its time. The standing joke with AIX was that it was pronounced "aches" (as in pains), but I was glad that it ran "smit" for admin stuff, as there was no way that I could remember the appropriate Shell commands. -- Dave From crossd at gmail.com Fri Aug 31 10:41:26 2018 From: crossd at gmail.com (Dan Cross) Date: Thu, 30 Aug 2018 20:41:26 -0400 Subject: [TUHS] cat -v and other complaints In-Reply-To: References: <20180829233605.GJ8423@mcvoy.com> <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com> Message-ID: On Thu, Aug 30, 2018, 8:27 PM Dave Horsfall wrote: > On Wed, 29 Aug 2018, Kevin Bowling wrote: > > > AIX takes a lot of shit but there were (and still are) some areas it was > > quite a bit ahead of its time. > > The standing joke with AIX was that it was pronounced "aches" (as in > pains), but I was glad that it ran "smit" for admin stuff, as there was no > way that I could remember the appropriate Shell commands. > "SMIT happens " - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ckeck at texoma.net Fri Aug 31 11:12:31 2018 From: ckeck at texoma.net (Cornelius Keck) Date: Thu, 30 Aug 2018 20:12:31 -0500 Subject: [TUHS] RetroNet??? In-Reply-To: References: <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com> <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net> <20180829183632.GD8423@mcvoy.com> Message-ID: <87109c55-82b6-7e76-f126-261044a1a15b@texoma.net> I'd like to get in on this, too. Dan Cross wrote: > On Wed, Aug 29, 2018 at 2:36 PM Larry McVoy > wrote: > > > As much as anything else, the idea is to build a community of > friendly folks > > that want to play / learn / help each other, likely in direct > relation to > > retro computing. > > So just a thought. A good curator, looking at you Warren, helps keep > things sane. If your fun project takes off, be picky about who you let > in and what sort of behaviour you will tolerate. One toxic person can > chase everyone away. > > > Speaking of Warren and UUCP (and wise words from Larry here, but I'm > going off in a slightly different direction). > > Warren was working on getting a UUCP network up and running again to > commemorate the Unix 50th anniversary. I was (and probably still am) on > the mailing list, but activity has kind of petered off as of late. > Anyway, you may want to get in touch with him and see if you can > leverage some of that work or perhaps join forces. > > - Dan C. > From ckeck at texoma.net Fri Aug 31 11:15:03 2018 From: ckeck at texoma.net (Cornelius Keck) Date: Thu, 30 Aug 2018 20:15:03 -0500 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net> References: <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com> <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net> Message-ID: <1d8c0539-8b43-9954-d8a7-db4dcc22b27d@texoma.net> Do I want to reserve retronet.us? Could host that here, as I have static IPs. Having static IPs hanging of a FIOS line is cheaper and easier than dealing with a hoster.. Grant Taylor via TUHS wrote: > On 08/29/2018 12:04 PM, Seth Morabito wrote: >> Hmm. I hate to bring this up, but I've been using the name RetroNET as >> well. I've had the domain retronet.net registered for ages, and was >> about to launch a small pilot project with a handful of 3B2 emulators >> running SVR3, with the hope for many more interconnected systems. > > *gulp* > > So /you're/ the person that had the domain name we originally wanted. ;-) > > We actually decided that we liked "Retro Comp(uting) . Net(work)" and > have registered that name. There is a wiki(…) and forum(…), but the > main website isn't up yet. > > We are about a week into the discussions. Please join us in the > #retronet group on the Synchronet network. (irc.chivanet.org) > >> That said, maybe we could pool our efforts? I'd be happy to share the >> domain name with this effort, since it's precisely in line with what >> I'd like to see. > > ~sigh~of~relief~ > > I think we would love to welcome more members into the RetroNet. > > As much as anything else, the idea is to build a community of friendly > folks that want to play / learn / help each other, likely in direct > relation to retro computing. > > > From ckeck at texoma.net Fri Aug 31 11:17:33 2018 From: ckeck at texoma.net (Cornelius Keck) Date: Thu, 30 Aug 2018 20:17:33 -0500 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: <02ee9a61-2920-40e0-bfa4-feb8b3d38c73@gmail.com> References: <1F62F4D0-7AD1-43C2-A9B7-CF9DF239C3D9@berlan.de> <02ee9a61-2920-40e0-bfa4-feb8b3d38c73@gmail.com> Message-ID: <005618da-62b2-97e9-c7fb-4eb42717be6e@texoma.net> Same. I've used UUCP over IP for a long time, but my German peer went away. UUCP over modem I'm going to rig in the near future, after some retail therapy, like two Telebit Trailblazer (have one already) and a central office simulator. William Pechter wrote: > Count me in. I think a UUCP over ssh would be nice as would an SSL > version. I would like to see UUCP over ether as serial for backwards > compatibility to talk to old machines and emulation. > > Some of the kid's I know would be blown away by Cnews and television or > transported over Internet or PPP links. > > Bill > > Sent from BlueMail > On Aug 29, 2018, at 14:06, Grant Taylor via TUHS > wrote: > > On 08/29/2018 11:49 AM, Andreas Hein wrote: > > Nice idea if UUCP is an option? Now dreaming about the > 'internet' i used > where i started with UNIX (1985) > > > We have been discussing UUCP options. The short list is: > > · UUCP over SSH > · UUCP over TCP (is there an encrypted UUCP over TCP+SSL?) > · UUCP bag files transferred some other means. > · UUCP over some sort of emulated serial connection > > If you have other ideas, I'd love to hear them. > > I expect that we will be talking about an email gateway at some point if > people are interested. > > We already have a Usenet feed that we will be making available via NNTP > and UUCP. > > From ckeck at texoma.net Fri Aug 31 11:20:59 2018 From: ckeck at texoma.net (Cornelius Keck) Date: Thu, 30 Aug 2018 20:20:59 -0500 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: References: <1F62F4D0-7AD1-43C2-A9B7-CF9DF239C3D9@berlan.de> Message-ID: <2e58402b-6366-4f74-757b-b7c8dd1b729c@texoma.net> If one wanted to do this old-school, like with modems ... just wondering, who still has - a wire-line phone, - a modem, - and hails from where? Flat rate local toll and long distance is fairly prevalent in the US. International long distance is a different story. How does that look like elsewhere, who has a metered land-line? Grant Taylor via TUHS wrote: > On 08/29/2018 11:49 AM, Andreas Hein wrote: >> Nice idea if UUCP is an option? Now dreaming about the 'internet' i >> used where i started with UNIX (1985) > > We have been discussing UUCP options. The short list is: > > · UUCP over SSH > · UUCP over TCP (is there an encrypted UUCP over TCP+SSL?) > · UUCP bag files transferred some other means. > · UUCP over some sort of emulated serial connection > > If you have other ideas, I'd love to hear them. > > I expect that we will be talking about an email gateway at some point if > people are interested. > > We already have a Usenet feed that we will be making available via NNTP > and UUCP. > > > From pechter at gmail.com Fri Aug 31 11:37:16 2018 From: pechter at gmail.com (William Pechter) Date: Thu, 30 Aug 2018 21:37:16 -0400 Subject: [TUHS] =?utf-8?q?RetroNet=E2=80=A6_Virtual_is_cheap=2E?= In-Reply-To: <1d8c0539-8b43-9954-d8a7-db4dcc22b27d@texoma.net> References: <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com> <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net> <1d8c0539-8b43-9954-d8a7-db4dcc22b27d@texoma.net> Message-ID: Actually, my virtual machine @Digital Ocean has been $5.25/month. Can't get static IP on my Fios for that. Domain registration and DNS via Google Domains is another buck per month... I run mail, web and DNS for $6.25/month on FreeBSD or Linux with full root control. -----Original Message----- From: Cornelius Keck To: Grant Taylor , tuhs at minnie.tuhs.org Sent: Thu, 30 Aug 2018 21:17 Subject: Re: [TUHS] RetroNet… Do I want to reserve retronet.us? Could host that here, as I have static IPs. Having static IPs hanging of a FIOS line is cheaper and easier than dealing with a hoster.. Grant Taylor via TUHS wrote: > On 08/29/2018 12:04 PM, Seth Morabito wrote: >> Hmm. I hate to bring this up, but I've been using the name RetroNET as >> well. I've had the domain retronet.net registered for ages, and was >> about to launch a small pilot project with a handful of 3B2 emulators >> running SVR3, with the hope for many more interconnected systems. > > *gulp* > > So /you're/ the person that had the domain name we originally wanted. ;-) > > We actually decided that we liked "Retro Comp(uting) . Net(work)" and > have registered that name. There is a wiki(…) and forum(…), but the > main website isn't up yet. > > We are about a week into the discussions. Please join us in the > #retronet group on the Synchronet network. (irc.chivanet.org) > >> That said, maybe we could pool our efforts? I'd be happy to share the >> domain name with this effort, since it's precisely in line with what >> I'd like to see. > > ~sigh~of~relief~ > > I think we would love to welcome more members into the RetroNet. > > As much as anything else, the idea is to build a community of friendly > folks that want to play / learn / help each other, likely in direct > relation to retro computing. > > > From ckeck at texoma.net Fri Aug 31 11:09:19 2018 From: ckeck at texoma.net (Cornelius Keck) Date: Thu, 30 Aug 2018 20:09:19 -0500 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: <49620ace-ca66-c288-2ab3-3a0fe4af640e@spamtrap.tnetconsulting.net> References: <20180830175420.3zs4gpyacsgrh7wc@h-174-65.A328.priv.bahnhof.se> <49620ace-ca66-c288-2ab3-3a0fe4af640e@spamtrap.tnetconsulting.net> Message-ID: I'm playing with the idea of hooking up a modem to my wireline phone. I'd like to keep an eye on my late mother-in-law's place remotely. Best I can get out there is DSL, and it ain't snappy, so one idea is to get two Telebit Trailblazer modems, one here, one out there, dial into the place, pull imagery via UUCP. Trailies spoof UUCP natively, and they deal nicely with bad connectivity. One could take that one step further and bring back a bit of Usenet. Grant Taylor via TUHS wrote: > On 08/30/2018 11:54 AM, Michael Kjörling wrote: >> This sounds interesting, but I'm not sure if I'd be eligible. > > I bet that you do. > >> What would be the entry criteria? 20 years professional experience as >> sysadmin on 4.3BSD? Physical PDP-11/780 running in the closet? > > Valid question. > > I'm of the opinion that the entry criteria are a client that can talk to > the RetroNet network (more on that in a moment) and a desire to > participate. > > I'll also say that a healthy interest / curiosity in anything that runs > over / through RetroNet would be beneficial. But if you want to use > RetroNet to play Doom across IPX with buddies across town, then you > should be able to do so. (Assuming that you and your buddies are > RetroNet members.) > > As for client, I'm initially targeting something like a Raspberry Pi or > any SOHO router that will run OpenWRT / DD-WRT / Tomato. Ideally I'd > like to re-use existing images (possibly with a different kernel) and > add on packages. I'd like those to be the almost-turn-key > installations. Almost as in you start with that and do some things on top. > > If you want to roll your own Linux install that supports the documented > specifications, then more power to you. > > One of the purposes of RetroNet is to enable members to be able to > participate and use the RetroNet for what ever they want (as long as > it's legal and does not adversely effect RetroNet or members). Another > purpose for RetroNet is to provide a network that we can provide a safe > environment for people that want to learn things and help / > encouragement to do so. Sort of like a mentor in a sandbox. > > Aside: I've been using the term "member". I don't want that to convey > any meaning other than someone that has signed up and has a RetroNet > account. I'm not anticipating any membership fees or anything like > that. Down the road we may set up something like a tip jar to help > cover costs like domain name subscription or other nominal costs. > > In short, if you want to play in the sand box and you play well with > others, come on down. Let's have fun, learn, play. > > > From lm at mcvoy.com Fri Aug 31 11:58:22 2018 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 30 Aug 2018 18:58:22 -0700 Subject: [TUHS] cat -v and other complaints In-Reply-To: References: <20180829233605.GJ8423@mcvoy.com> <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com> Message-ID: <20180831015822.GQ664@mcvoy.com> On Thu, Aug 30, 2018 at 08:41:26PM -0400, Dan Cross wrote: > On Thu, Aug 30, 2018, 8:27 PM Dave Horsfall wrote: > > > On Wed, 29 Aug 2018, Kevin Bowling wrote: > > > > > AIX takes a lot of shit but there were (and still are) some areas it was > > > quite a bit ahead of its time. > > > > The standing joke with AIX was that it was pronounced "aches" (as in > > pains), but I was glad that it ran "smit" for admin stuff, as there was no > > way that I could remember the appropriate Shell commands. > > > > "SMIT happens " So back in the BitKeeper days, we supported everything, including AIX. I've got a fairly beefy AIX box in my shop in case we need it, 1ghz, lots of ram, we're never gonna turn that on. I went into smit and I was just like can you just frigging let me edit /etc/inetd.conf or whatever, but no. SMIT happens. And I did not like it. I think that's one of the reasons that SunOS was cool, it was just a better, bugfixed BSD. So we all knew how to deal with it. SMIT not so much. From kevin.bowling at kev009.com Fri Aug 31 11:59:30 2018 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Thu, 30 Aug 2018 18:59:30 -0700 Subject: [TUHS] SunOS code? In-Reply-To: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu> References: <20180830213407.6DC4718C0A6@mercury.lcs.mit.edu> Message-ID: The effects of copyright on abandonware have been discussed pretty widely in other communities. The primary issue is the contracts and right don't simply expire and it's rare for a company to completely shutter (i.e. assets including these copyrights are acquired or given to creditors). Oracle would need to establish that they have providence over the files and code, and that exceptions for Novel and other code were covered by the OpenSolaris rights reviews. I imagine it might cost low hundreds of thousands of dollars to do lawyers being what they are and commercial *nix being such a melting pot of sources. Since there is no conceivable revenue stream and Oracle isn't much for goodwill I am highly skeptical. Sun releasing OpenSolaris when they finally did and under the CDDL was pretty tone deaf to what was going on in the market with Linux, but you have to admire the amount of contract review and legal work that must have taken. Regards, Kevin On Thu, Aug 30, 2018 at 2:34 PM, Noel Chiappa wrote: > > From: Warner Losh > > > The trouble, as I was given to understand when I worked at Solbourne, > > was that ... There were a number of third party bits and pieces in there > > that could not be relicensed ... if there are other IP issues, not > > limited ... It's that quagmire that efforts like this will run up > > against. > > Oh, we'll just ask Oracle for a license 'for all parts of SunOS for which they > have the ability to grant a licence'. > > There's no way I'd want them to have to chase down all the corner cases, > that's just a way to guarantee it will never happen. I'd want to ask for the > bare minimum of time/effort on their part. > > Anything above that, probably the SCCS stuff would be next on the priority > list, sounds like. > > Noel From usotsuki at buric.co Fri Aug 31 13:07:13 2018 From: usotsuki at buric.co (Steve Nickolas) Date: Thu, 30 Aug 2018 23:07:13 -0400 (EDT) Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: <2e58402b-6366-4f74-757b-b7c8dd1b729c@texoma.net> References: <1F62F4D0-7AD1-43C2-A9B7-CF9DF239C3D9@berlan.de> <2e58402b-6366-4f74-757b-b7c8dd1b729c@texoma.net> Message-ID: On Thu, 30 Aug 2018, Cornelius Keck wrote: > If one wanted to do this old-school, like with modems ... just wondering, who > still has > > - a wire-line phone, > > - a modem, > > - and hails from where? > > Flat rate local toll and long distance is fairly prevalent in the US. > International long distance is a different story. How does that look like > elsewhere, who has a metered land-line? Well, I got a landline, but it has flat rate local only and no long distance plan (it's the second-lowest plan for people with disabilities), so about the only places I could call out are elsewhere in Niagara Falls and the surrounding towns...not very useful here =p -uso. From grog at lemis.com Fri Aug 31 13:30:46 2018 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Fri, 31 Aug 2018 13:30:46 +1000 Subject: [TUHS] hal.gnu.ai.mit.edu In-Reply-To: References: Message-ID: <20180831033046.GF5698@eureka.lemis.com> On Saturday, 25 August 2018 at 19:45:51 +0100, Steve Mynott wrote: > Back in the early 90s before the FSF withdrew the service due to misuse it > was possible to write off to them to get a free shell account on "hal" as I > did. I recall having to telnet through one of three gateway systems so > assume it was on its own little subnet. > > But I can't remember what sort of system (hardware or OS) it was now > however and wondered if anyone else did? I had a login on the GNU systems (there were several of them). I can't recall most of them, so they can't have been that interesting, but there were one or two IBM machines. I forget the OS, but I recall using gdb to look at the assembler code of some program or another. It was clearly related to the System/370. 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 gtaylor at tnetconsulting.net Fri Aug 31 14:13:37 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 30 Aug 2018 22:13:37 -0600 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: References: <20180830175420.3zs4gpyacsgrh7wc@h-174-65.A328.priv.bahnhof.se> <49620ace-ca66-c288-2ab3-3a0fe4af640e@spamtrap.tnetconsulting.net> Message-ID: <9a854668-3a0a-de7a-1d92-5b8cd0df3740@spamtrap.tnetconsulting.net> On 08/30/2018 05:42 PM, Dave Horsfall wrote: > Count me in; as a reborn electronics enthusiast (and a Unix user since > Edition 5) I've been looking for an excuse to buy a Raspberry Pi (as > opposed to the usual articles in the usual magazines), and this sounds > just the ticket! That's the spirit. :-) Do what you want to do and have fun doing it. > And if subdomains are available then of course I'll contribute (as if I > wouldn't anyway). We haven't explicitly talked about sub-domains yet, but I expect that we will be delegating .retrocomp.net to members if they want. We'll happily host it as part of the retrocomp.net zone and make changes as requested, or delegate the subdomain per standard process. We can even slave the delegated subdomain back on the main DNS servers so that you are in complete control while still hosting things if you prefer. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From gtaylor at tnetconsulting.net Fri Aug 31 14:17:32 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 30 Aug 2018 22:17:32 -0600 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: References: <20180830175420.3zs4gpyacsgrh7wc@h-174-65.A328.priv.bahnhof.se> <49620ace-ca66-c288-2ab3-3a0fe4af640e@spamtrap.tnetconsulting.net> Message-ID: <0ac9afc1-3521-17f0-ee95-a5c0c440511d@spamtrap.tnetconsulting.net> On 08/30/2018 07:09 PM, Cornelius Keck wrote: > I'm playing with the idea of hooking up a modem to my wireline phone. > I'd like to keep an eye on my late mother-in-law's place remotely. Best > I can get out there is DSL, and it ain't snappy, so one idea is to get > two Telebit Trailblazer modems, one here, one out there, dial into the > place, pull imagery via UUCP. Trailies spoof UUCP natively, and they > deal nicely with bad connectivity. One could take that one step further > and bring back a bit of Usenet. That sounds like an interesting project. I'd personally like to shoulder surf or read periodic updates, possibly a blog or twitter? ;-) I don't see how RetroNet can help with that connection. It sounds like you've already got a good plan in place. That being said, I do think that you could have a RetroNet … node (?term?) … at your house and then pass news feeds / email / etc over your Telebit UUCP extension. — I see no reason why that wouldn't work. If you want to do such, cool. How can I / we help? -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From gtaylor at tnetconsulting.net Fri Aug 31 14:33:13 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 30 Aug 2018 22:33:13 -0600 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: <005618da-62b2-97e9-c7fb-4eb42717be6e@texoma.net> References: <1F62F4D0-7AD1-43C2-A9B7-CF9DF239C3D9@berlan.de> <02ee9a61-2920-40e0-bfa4-feb8b3d38c73@gmail.com> <005618da-62b2-97e9-c7fb-4eb42717be6e@texoma.net> Message-ID: <2a75be0b-a92c-22b7-3372-d500e7c7367d@spamtrap.tnetconsulting.net> On 08/30/2018 07:17 PM, Cornelius Keck wrote: > Same. I've used UUCP over IP for a long time, but my German peer went > away. What were you running across UUCP over IP? I'd be willing ~> interested in providing a connection from my personal server (currently independent of RetroNet) if you want to play ~> learn. — Feel free to drop me a line directly / off list if you (or anyone) want to pursue this. > UUCP over modem I'm going to rig in the near future, after some retail > therapy, like two Telebit Trailblazer (have one already) and a central > office simulator. I'm curious what you're going to use as a C.O. simulator. I'm likely to (re)acquire an AT&T / Lucent / Avaya "Partner" phone system that provides eight (?) station ports, which include analog B1 interfaces that modems can connect to. It might only support 33.6 kbps, but it will do the job. :-) -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From gtaylor at tnetconsulting.net Fri Aug 31 14:40:47 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 30 Aug 2018 22:40:47 -0600 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: <2e58402b-6366-4f74-757b-b7c8dd1b729c@texoma.net> References: <1F62F4D0-7AD1-43C2-A9B7-CF9DF239C3D9@berlan.de> <2e58402b-6366-4f74-757b-b7c8dd1b729c@texoma.net> Message-ID: <69d4887c-51db-2aa2-ff74-7d717319d384@spamtrap.tnetconsulting.net> On 08/30/2018 07:20 PM, Cornelius Keck wrote: > If one wanted to do this old-school, like with modems ... just > wondering, who still has > > - a wire-line phone, > > - a modem, > > - and hails from where? > > Flat rate local toll and long distance is fairly prevalent in the US. > International long distance is a different story. How does that look > like elsewhere, who has a metered land-line? I could see RetroNet pondering an additional service in the future that is effectively a virtual serial port (more below) that connects to a virtual modem that can interconnect with other virtual modems as if they called each other. I think something like this could be made to work across IP interconnections provided by RetroNet. This is obviously beyond the original ideas of RetroNet, which we want to get working first. But if there's sufficient interest in people being able to ""call each other over a (virtual) modem, then I think we should put it on the desired features list. There are a number of options that can create a virtual serial port that connects across networks. I think we can even connect a physical serial port (possibly even via RS-232 serial to USB adapters that can be connected to physical machines). So if this is something that you're interested in, please let us know. This might be a good place to ""forward the virtual modem discussion to the RetroNet mailing list. TUHS has been very gracious and a lot of people have shown interest. But we don't want to wear out our welcome. ():-) To that end, please subscribe to the RetroNet mailing list to continue discussing details about the virtual modems. Link - RetroNet mailing list - http://mailman.chivanet.org/listinfo/retronet -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From gtaylor at tnetconsulting.net Fri Aug 31 15:06:04 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 30 Aug 2018 23:06:04 -0600 Subject: [TUHS] =?utf-8?b?UmV0cm9OZXTigKY=?= In-Reply-To: <1d8c0539-8b43-9954-d8a7-db4dcc22b27d@texoma.net> References: <1535565898.3905695.1490376112.4B7D3E18@webmail.messagingengine.com> <6e7783fb-ff06-2e21-002f-76bef263b63c@spamtrap.tnetconsulting.net> <1d8c0539-8b43-9954-d8a7-db4dcc22b27d@texoma.net> Message-ID: On 08/30/2018 07:15 PM, Cornelius Keck wrote: > Do I want to reserve retronet.us? Could host that here, as I have static > IPs. I'm not going to tell you not to do so if you want to. I will say that I have registered "retrocomp.net", as in "Retro Computing Network". The person that has registered "retronet.com" (TLD is from memory) has both expressed interest in participating and offered use of the domain. So … I think for the moment we are going to continue with retrocomp.net because that's what we have started with. That being said, it is early enough in the process that we can still change domain names if we want to. I would encourage you to subscribe to the RetroNet mailing list and start a conversation about which domain name to use. Link - RetroNet mailing list - http://mailman.chivanet.org/listinfo/retronet > Having static IPs hanging of a FIOS line is cheaper and easier than > dealing with a hoster.. *nod* I run my personal services on a Linode VPS. They have served me very well. :-) -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From lars at nocrew.org Fri Aug 31 15:49:38 2018 From: lars at nocrew.org (Lars Brinkhoff) Date: Fri, 31 Aug 2018 05:49:38 +0000 Subject: [TUHS] SunOS code? In-Reply-To: <20180830194106.9E57818C0A2@mercury.lcs.mit.edu> (Noel Chiappa's message of "Thu, 30 Aug 2018 15:41:06 -0400 (EDT)") References: <20180830194106.9E57818C0A2@mercury.lcs.mit.edu> Message-ID: <7w1safw0el.fsf@junk.nocrew.org> I have something called sunos-414-source.tar.gz. It expands to a solaris_112 directory. There are sources for kernel, etc, bin ucb, 5bin, usr.bin... Looks to be sun4 only, no 68k. No version history. Free to a good home. (I sent a copy to Kossow years ago.) From mphuff at gmail.com Fri Aug 31 19:46:01 2018 From: mphuff at gmail.com (Michael Huff) Date: Fri, 31 Aug 2018 01:46:01 -0800 Subject: [TUHS] Running 4.3 BSD on x86 hardware? Suggestions? In-Reply-To: References: Message-ID: It's not 4.3BSD, but might be worth an honorable mention... You can get FreeBSD 1.0, (based on 386BSD, based on NET/2), directly from the FreeBSD project: http://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/i386/ISO-IMAGES/1.0/1.0-disc1.iso And then use 86Box ( https://github.com/86Box/86Box/ ) to emulate an early 90's 486 and install it with FreeDOS on one partition, FreeBSD on the other.  There's an /sbin/mount_isofs but I haven't stumbled across a working combination that manages to actually see a cdrom yet. As a work-around I copied everything from the "tarballs" directory onto the freedos partition and then installed them from there. It would probably work on Virtualbox, but I haven't tried. Have fun! On 8/28/2018 6:53 AM, Gilles Gravier wrote: > Hi! > > If I wanted to run 4.3BSD on an x86 box (VirtualBox? QEMM? other > emu?)... anybody has suggestions? Where can I find media for 4.3BSD > (if any are legitimately accessible)? > > Or on a Raspberry Pi? :) > > Thanks! > > Gilles > > -- > /*Gilles Gravier*/ - Gilles at Gravier.org > GSM : +33618347147 and +41794728437 > Skype : ggravier| PGP Key: 0x8DE6D026 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Fri Aug 31 19:50:50 2018 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 31 Aug 2018 19:50:50 +1000 (EST) Subject: [TUHS] SunOS code? In-Reply-To: <7w1safw0el.fsf@junk.nocrew.org> References: <20180830194106.9E57818C0A2@mercury.lcs.mit.edu> <7w1safw0el.fsf@junk.nocrew.org> Message-ID: On Fri, 31 Aug 2018, Lars Brinkhoff wrote: > I have something called sunos-414-source.tar.gz. It expands to a > solaris_112 directory. There are sources for kernel, etc, bin ucb, > 5bin, usr.bin... Looks to be sun4 only, no 68k. No version history. > > Free to a good home. (I sent a copy to Kossow years ago.) Umm, this message is a bit confusing... Is it a single physical medium that you happened to have, or software that you are willing to distribute upon some sort of an agreement, or what? At the very least, it ought to find its way into Warren's hands... -- Dave From gregg.drwho8 at gmail.com Fri Aug 31 21:01:20 2018 From: gregg.drwho8 at gmail.com (Gregg Levine) Date: Fri, 31 Aug 2018 07:01:20 -0400 Subject: [TUHS] SunOS code? In-Reply-To: References: <20180830194106.9E57818C0A2@mercury.lcs.mit.edu> <7w1safw0el.fsf@junk.nocrew.org> Message-ID: Hello! Of course I am interested. I am as they say, always interested. But I also agree with Dave there as well. A copy should be delivered to Warren. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Fri, Aug 31, 2018 at 5:50 AM, Dave Horsfall wrote: > On Fri, 31 Aug 2018, Lars Brinkhoff wrote: > >> I have something called sunos-414-source.tar.gz. It expands to a >> solaris_112 directory. There are sources for kernel, etc, bin ucb, 5bin, >> usr.bin... Looks to be sun4 only, no 68k. No version history. >> >> Free to a good home. (I sent a copy to Kossow years ago.) > > > Umm, this message is a bit confusing... Is it a single physical medium that > you happened to have, or software that you are willing to distribute upon > some sort of an agreement, or what? > > At the very least, it ought to find its way into Warren's hands... > > -- Dave From lars at nocrew.org Fri Aug 31 21:05:18 2018 From: lars at nocrew.org (Lars Brinkhoff) Date: Fri, 31 Aug 2018 11:05:18 +0000 Subject: [TUHS] SunOS code? In-Reply-To: (Gregg Levine's message of "Fri, 31 Aug 2018 07:01:20 -0400") References: <20180830194106.9E57818C0A2@mercury.lcs.mit.edu> <7w1safw0el.fsf@junk.nocrew.org> Message-ID: <7wr2ievlsh.fsf@junk.nocrew.org> > Hello! > Of course I am interested. I am as they say, always interested. But I > also agree with Dave there as well. A copy should be delivered to > Warren. Ok, sounds great! From ron at ronnatalie.com Fri Aug 31 21:38:34 2018 From: ron at ronnatalie.com (ron at ronnatalie.com) Date: Fri, 31 Aug 2018 07:38:34 -0400 Subject: [TUHS] cat -v and other complaints In-Reply-To: References: <20180829233605.GJ8423@mcvoy.com> <69AFD606-5E1D-4060-95A5-22F33B2322B2@ccc.com> Message-ID: <147f01d4411f$276e2af0$764a80d0$@ronnatalie.com> > The standing joke with AIX was that it was pronounced "aches" (as in pains), > but I was glad that it ran "smit" for admin stuff, as there was no way that I > could remember the appropriate Shell commands. We wanted to call the window manager "panes" on Aix (Aches and Pains). My only real memory of beating on the RS/6000 was that while it had a 24-bit graphics card, the X server didn't have a 24-bit visual. That and I was able to break into the demo box IBM sent me by turning the key to the "wrench" position and then shell escaping out of a more command it launched. I spent more time hacking the 370/PS2/i860 version of the kernel which was a unified source base. This had switching console contexts they called the "High Function Terminal." We named our i860 version of it the "Low Function Terminal."