From beebe at math.utah.edu Thu Apr 1 03:23:25 2021 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Wed, 31 Mar 2021 11:23:25 -0600 Subject: [TUHS] [tuhs] ACM Turing Award for 2020: Unix roots Message-ID: This just came in: ACM has named Alfred Vaino Aho and Jeffrey David Ullman recipients of the 2020 ACM A. M. Turing Award https://awards.acm.org/about/2020-turing for fundamental algorithms and theory underlying programming language implementation and for synthesizing these results and those of others in their highly influential books, which educated generations of computer scientists. Most of us probably have several of their books on the shelf; I certainly do! ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From jcapp at anteil.com Thu Apr 1 03:31:52 2021 From: jcapp at anteil.com (Jim Capp) Date: Wed, 31 Mar 2021 12:31:52 -0500 (EST) Subject: [TUHS] [tuhs] ACM Turing Award for 2020: Unix roots In-Reply-To: Message-ID: <12508239.957.1617211912079.JavaMail.root@zimbraanteil> I've got "The Design and Analysis of Computer Algorithms" and "Principles of Compiler Design" aka the "Dragon Book" on my shelf. Congrats to both! From: "Nelson H. F. Beebe" To: "The Unix Heritage Society mailing list" Sent: Wednesday, March 31, 2021 1:23:25 PM Subject: [TUHS] [tuhs] ACM Turing Award for 2020: Unix roots This just came in: ACM has named Alfred Vaino Aho and Jeffrey David Ullman recipients of the 2020 ACM A. M. Turing Award https://awards.acm.org/about/2020-turing for fundamental algorithms and theory underlying programming language implementation and for synthesizing these results and those of others in their highly influential books, which educated generations of computer scientists. Most of us probably have several of their books on the shelf; I certainly do! ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbrock at computerhistory.org Thu Apr 1 03:39:37 2021 From: dbrock at computerhistory.org (David C. Brock) Date: Wed, 31 Mar 2021 17:39:37 +0000 Subject: [TUHS] Data structures in Unix editors Message-ID: All of the great discussion on this list about editors has made me curious about the data structures used in the various Unix editors. I found a great discussion of this for sam in Rob Pike’s publication “The Text Editor sam.” I’d like to read similar discussions of the data structures for ed, em, ex/vi. If anyone has suggestions of references, they would be very welcome! Similarly, if there are any pointers to references on some other data structures in editors like TECO, QED and E, I’d welcome them as well. All the best, David ........... David C. Brock Director and Curator Software History Center Computer History Museum computerhistory.org/softwarehistory Email: dbrock at computerhistory.org Twitter: @dcbrock Skype: dcbrock 1401 N. Shoreline Blvd. Mountain View, CA 94943 (650) 810-1010 main (650) 810-1886 direct Pronouns: he, him, his -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Thu Apr 1 04:07:57 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 31 Mar 2021 12:07:57 -0600 Subject: [TUHS] Data structures in Unix editors In-Reply-To: References: Message-ID: <202103311807.12VI7vpZ022249@freefriends.org> The "Software Tools" books used very simple arrays of characters to manage the text buffers for their version of 'ed'. Those books are worth reading in any case. :-) Arnold "David C. Brock" wrote: > All of the great discussion on this list about editors has made me curious about the data structures used in the various Unix editors. > > I found a great discussion of this for sam in Rob Pike’s publication “The Text Editor sam.” > > I’d like to read similar discussions of the data structures for ed, em, ex/vi. If anyone has suggestions of references, they would be very welcome! > > Similarly, if there are any pointers to references on some other data structures in editors like TECO, QED and E, I’d welcome them as well. > > All the best, > > David > ........... > David C. Brock > Director and Curator > Software History Center > Computer History Museum > computerhistory.org/softwarehistory > Email: dbrock at computerhistory.org > Twitter: @dcbrock > Skype: dcbrock > 1401 N. Shoreline Blvd. > Mountain View, CA 94943 > (650) 810-1010 main > (650) 810-1886 direct > Pronouns: he, him, his > > From lars at nocrew.org Thu Apr 1 04:20:43 2021 From: lars at nocrew.org (Lars Brinkhoff) Date: Wed, 31 Mar 2021 18:20:43 +0000 Subject: [TUHS] Data structures in Unix editors In-Reply-To: (David C. Brock's message of "Wed, 31 Mar 2021 17:39:37 +0000") References: Message-ID: <7w1rbvfamc.fsf@junk.nocrew.org> David C. Brock wrote: > Similarly, if there are any pointers to references on some other data > structures in editors like TECO, QED and E, I’d welcome them as well. http://web.mit.edu/~yandros/doc/craft-text-editing/Chapter-6.html From rich.salz at gmail.com Thu Apr 1 04:23:47 2021 From: rich.salz at gmail.com (Richard Salz) Date: Wed, 31 Mar 2021 14:23:47 -0400 Subject: [TUHS] Data structures in Unix editors In-Reply-To: <202103311807.12VI7vpZ022249@freefriends.org> References: <202103311807.12VI7vpZ022249@freefriends.org> Message-ID: > Similarly, if there are any pointers to references on some other data structures in editors like TECO, QED and E, I’d welcome them as well. The classic is "cookbook for an emacs" but it's from 1980 https://dspace.mit.edu/handle/1721.1/15905 There's also this that's 25 years more recent but 16 years old: https://ecc-comp.blogspot.com/2015/05/a-brief-glance-at-how-5-text-editors.html And this: https://nullprogram.com/blog/2017/09/07/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Thu Apr 1 04:49:31 2021 From: bakul at iitbombay.org (Bakul Shah) Date: Wed, 31 Mar 2021 11:49:31 -0700 Subject: [TUHS] Data structures in Unix editors In-Reply-To: References: Message-ID: On Mar 31, 2021, at 10:46 AM, David C. Brock wrote: > > I’d like to read similar discussions of the data structures for ed, em, ex/vi. If anyone has suggestions of references, they would be very welcome! > > Similarly, if there are any pointers to references on some other data structures in editors like TECO, QED and E, I’d welcome them as well. Charles Crowley’s “Data Structures of Text Sequences”: https://www.cs.unm.edu/~crowley/papers/sds.pdf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Thu Apr 1 22:21:10 2021 From: ron at ronnatalie.com (Ron Natalie) Date: Thu, 01 Apr 2021 12:21:10 +0000 Subject: [TUHS] 30th Anniversary of most epic netnews post Message-ID: >From spaf at cs.purdue.EDU Thu Apr 4 23:11:22 1991 Path: ai-lab!mintaka!mit-eddie!wuarchive!usc!apple!amdahl!walldrug!moscvax!perdue!spaf From: spaf at cs.purdue.EDU (Gene Spafford) Newsgroups: news.announce.important,news.admin Subject: Warning: April Fools Time again (forged messages on the loose!) Message-ID: <4-1-1991 at medusa.cs.purdue.edu> Date: 1 Apr 91 00:00:00 GMT Expires: 1 May 91 00:00:00 GMT Followup-To: news.admin Organization: Dept. of Computer Sciences, Purdue Univ. Lines: 25 Approved: spaf at cs.purdue.EDU Xref: ai-lab news.announce.important:19 news.admin:8235 Warning: April 1 is rapidly approaching, and with it comes a USENET tradition. On April Fools day comes a series of forged, tongue-in-cheek messages, either from non-existent sites or using the name of a Well Known USENET person. In general, these messages are harmless and meant as a joke, and people who respond to these messages without thinking, either by flaming or otherwise responding, generally end up looking rather silly when the forgery is exposed. So, for the few weeks, if you see a message that seems completely out of line or is otherwise unusual, think twice before posting a followup or responding to it; it's very likely a forgery. There are a few ways of checking to see if a message is a forgery. These aren't foolproof, but since most forgery posters want people to figure it out, they will allow you to track down the vast majority of forgeries: o Russian computers. For historic reasons most forged messages have as part of their Path: a non-existent (we think!) russian computer, either kremvax or moscvax. Other possibilities are nsacyber or wobegon. Please note, however, that walldrug is a real site and isn't a forgery. o Posted dates. Almost invariably, the date of the posting is forged to be April 1. o Funky Message-ID. Subtle hints are often lodged into the Message-Id, as that field is more or less an unparsed text string and can contain random information. Common values include pi, the phone number of the red phone in the white house, and the name of the forger's parrot. o subtle mispellings. Look for subtle misspellings of the host names in the Path: field when a message is forged in the name of a Big Name USENET person. This is done so that the person being forged actually gets a chance to see the message and wonder when he actually posted it. Forged messages, of course, are not to be condoned. But they happen, and it's important for people on the net not to over-react. They happen at this time every year, and the forger generally gets their kick from watching the novice users take the posting seriously and try to flame their tails off. If we can keep a level head and not react to these postings, they'll taper off rather quickly and we can return to the normal state of affairs: chaos. Thanks for your support. Gene Spafford, Net.God (and probably tired of seeing this message) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dot at dotat.at Thu Apr 1 22:56:15 2021 From: dot at dotat.at (Tony Finch) Date: Thu, 1 Apr 2021 13:56:15 +0100 Subject: [TUHS] Data structures in Unix editors In-Reply-To: References: Message-ID: David C. Brock wrote: > > I’d like to read similar discussions of the data structures for ed, em, > ex/vi. If anyone has suggestions of references, they would be very > welcome! A curious one is nvi, which uses the Berkeley DB RECNO interface to access a text file as an array of lines (RECNO = record number). Tony. -- f.anthony.n.finch https://dotat.at/ Sole, Lundy, Fastnet, Irish Sea, Shannon: East or northeast 4 to 6, occasionally 7 in Lundy. Rough at first in northwest Shannon, otherwise slight or moderate, then occasionally rough later in east Sole. Fog patches at first in Sole. Moderate or good, occasionally very poor at first in Sole. From rich.salz at gmail.com Fri Apr 2 00:24:58 2021 From: rich.salz at gmail.com (Richard Salz) Date: Thu, 1 Apr 2021 10:24:58 -0400 Subject: [TUHS] Data structures in Unix editors In-Reply-To: References: Message-ID: > > A curious one is nvi, which uses the Berkeley DB RECNO interface to access > a text file as an array of lines (RECNO = record number). > > Not so curious: Keith Bostic was the principal author of both nvi and Berkeley DB. -------------- next part -------------- An HTML attachment was scrubbed... URL: From asjo at koldfront.dk Fri Apr 2 00:24:24 2021 From: asjo at koldfront.dk (=?utf-8?Q?Adam_Sj=C3=B8gren?=) Date: Thu, 01 Apr 2021 16:24:24 +0200 Subject: [TUHS] 30th Anniversary of most epic netnews post References: Message-ID: <87zgyi5bhj.fsf@tullinup.koldfront.dk> Ron quotes: > Subject: Warning: April Fools Time again (forged messages on the loose!) > Message-ID: <4-1-1991 at medusa.cs.purdue.edu> > Date: 1 Apr 91 00:00:00 GMT Interesting; here is the 1988 version: · https://article.olduse.net/35111-F%40medusa.cs.purdue.edu and the ones from 1989: · https://article.olduse.net/4-1-89%40medusa.cs.purdue.edu · https://article.olduse.net/4-1-1989%40medusa.cs.purdue.edu · https://article.olduse.net/4-1-1989%40hydra.cs.purdue.edu Note the Summary: header in the last variation. Courtesy of Joey Hess' olduse.net project: http://olduse.net/ Best regards, Adam -- "Archbishop of anarchy" Adam Sjøgren asjo at koldfront.dk From pepe at naleco.com Fri Apr 2 00:50:27 2021 From: pepe at naleco.com (Josh Good) Date: Thu, 1 Apr 2021 16:50:27 +0200 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM Message-ID: <20210401145025.GA1202@naleco.com> I read the news, and I could not believe it. It's April 1st, ain't it? But then, this looks like is dated March 31. So it could be for real. Behold: https://www.theregister.com/2021/03/31/ibm_redhat_xinuos/ The PDF also is dated March 31: https://regmedia.co.uk/2021/03/31/xinuos_complaint.pdf It's hard to believe someone would go to the trouble of writing 57 pages of legalese just to make a damn joke. " Xinuos, formed around SCO Group assets a decade ago under the name UnXis and at the time disavowing any interest in continuing SCO's long-running Linux litigation, today sued IBM and Red Hat for alleged copyright and antitrust law violations. "First, IBM stole Xinuos' intellectual property and used that stolen property to build and sell a product to compete with Xinuos itself," the US Virgin Islands-based software biz claims in its complaint [PDF]. "Second, stolen property in IBM's hand, IBM and Red Hat illegally agreed to divide the relevant market and use their growing market powers to victimize consumers, innovative competitors, and innovation itself." The complaint further contends that after the two companies conspired to divide the market, IBM then acquired Red Hat to solidify its position. SCO Group in 2003 made a similar intellectual property claim. It argued that SCO Group owned the rights to AT&T's Unix and UnixWare operating system source code, that Linux 2.4.x and 2.5.x were unauthorized derivatives of Unix, and that IBM violated its contractual obligations by distributing Linux code. That case dragged on for years, and drew a fair amount of attention when SCO Group said it would sue individual Linux users for infringement. Though SCO filed for bankruptcy in 2007 and some of the claims have been dismissed, its case against IBM remains unresolved. There was a status report filed on February 16, 2018, details remaining claims and counterclaims. And in May last year, Magistrate Judge Paul Warner was no longer assigned to oversee settlement discussions. But SCO Group v. IBM is still open. " Either way, some one if fooling us hard. PS: OK, it seems it's for real: https://www.xinuos.com/xinuos-sues-ibm-and-red-hat/ I need to check my stock of pop corn, then... My take: it's obvious they want to be a nuisance so that IBM settles the case, so they then can go back home with some fresh cash. I hope IBM goes ballistic on them to the bitter end, and finally sends the zombie back to its grave. But then, IBM now has its new RedHat business to protect, so it can get interesting. -- Josh Good From imp at bsdimp.com Fri Apr 2 01:12:25 2021 From: imp at bsdimp.com (Warner Losh) Date: Thu, 1 Apr 2021 09:12:25 -0600 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: <20210401145025.GA1202@naleco.com> References: <20210401145025.GA1202@naleco.com> Message-ID: The other set of claims made, which may be stronger, was that IBM and Redhat used their dominant position to lock out OSes other than Linux, including FreeBSD from their cloud platform. Their copyright claims look to be a bit different than the old SCO lawsuit. Reading their complaint, it is somewhat different than the old suit... FreeBSD is mentioned like 34 times too, since Xinuos based their products based on it. And their product is locked out of the IBM/Redhat cloud platform/ecosystem. The copyright stuff seems almost an afterthought... Warner On Thu, Apr 1, 2021 at 8:51 AM Josh Good wrote: > I read the news, and I could not believe it. > > It's April 1st, ain't it? > > But then, this looks like is dated March 31. So it could be for real. > > Behold: https://www.theregister.com/2021/03/31/ibm_redhat_xinuos/ > > The PDF also is dated March 31: > https://regmedia.co.uk/2021/03/31/xinuos_complaint.pdf > > It's hard to believe someone would go to the trouble of writing 57 pages of > legalese just to make a damn joke. > > " > Xinuos, formed around SCO Group assets a decade ago under the name > UnXis and at the time disavowing any interest in continuing SCO's > long-running Linux litigation, today sued IBM and Red Hat for > alleged copyright and antitrust law violations. > > "First, IBM stole Xinuos' intellectual property and used that > stolen > property to build and sell a product to compete with Xinuos > itself," > the US Virgin Islands-based software biz claims in its complaint > [PDF]. "Second, stolen property in IBM's hand, IBM and Red Hat > illegally agreed to divide the relevant market and use their > growing > market powers to victimize consumers, innovative competitors, and > innovation itself." > > The complaint further contends that after the two companies > conspired to divide the market, IBM then acquired Red Hat to > solidify its position. > > SCO Group in 2003 made a similar intellectual property claim. It > argued that SCO Group owned the rights to AT&T's Unix and UnixWare > operating system source code, that Linux 2.4.x and 2.5.x were > unauthorized derivatives of Unix, and that IBM violated its > contractual obligations by distributing Linux code. > > That case dragged on for years, and drew a fair amount of attention > when SCO Group said it would sue individual Linux users for > infringement. Though SCO filed for bankruptcy in 2007 and some of > the claims have been dismissed, its case against IBM remains > unresolved. > > There was a status report filed on February 16, 2018, details > remaining claims and counterclaims. And in May last year, > Magistrate > Judge Paul Warner was no longer assigned to oversee settlement > discussions. But SCO Group v. IBM is still open. > " > > Either way, some one if fooling us hard. > > PS: OK, it seems it's for real: > https://www.xinuos.com/xinuos-sues-ibm-and-red-hat/ > > I need to check my stock of pop corn, then... > > My take: it's obvious they want to be a nuisance so that IBM settles the > case, so they then can go back home with some fresh cash. I hope IBM goes > ballistic on them to the bitter end, and finally sends the zombie back to > its grave. But then, IBM now has its new RedHat business to protect, so it > can get interesting. > > -- > Josh Good > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Fri Apr 2 01:20:32 2021 From: ron at ronnatalie.com (Ron Natalie) Date: Thu, 01 Apr 2021 15:20:32 +0000 Subject: [TUHS] 30th Anniversary of most epic netnews post In-Reply-To: <87zgyi5bhj.fsf@tullinup.koldfront.dk> References: <87zgyi5bhj.fsf@tullinup.koldfront.dk> Message-ID: Thanks, I was looking for the older ones and couldn't find them. I knew the "tired of seeing this post" thing meant I was looking at a reprise. By the way, for those who don't know. Spaf didn't write any of it. The message itself was the spoof warned about (and all the "ways to tell" appear in the message/headers). From pepe at naleco.com Fri Apr 2 01:27:40 2021 From: pepe at naleco.com (Josh Good) Date: Thu, 1 Apr 2021 17:27:40 +0200 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <20210401145025.GA1202@naleco.com> Message-ID: <20210401152738.GB1202@naleco.com> On 2021 Apr 1, 09:12, Warner Losh wrote: > The other set of claims made, which may be stronger, was that IBM and > Redhat used their dominant position to lock out OSes other than Linux, > including FreeBSD from their cloud platform. I don't think IBM has a dominant position in the cloud business. Microsoft's Azure and Amazon's AWS are the dominant forces in the cloud business. I don't see merit on that claim from XinuOS. They are just firing in all directions to find out if by chance they hit some target with money to milk. -- Josh Good From lm at mcvoy.com Fri Apr 2 01:28:10 2021 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 1 Apr 2021 08:28:10 -0700 Subject: [TUHS] 30th Anniversary of most epic netnews post In-Reply-To: References: <87zgyi5bhj.fsf@tullinup.koldfront.dk> Message-ID: <20210401152810.GI4209@mcvoy.com> On Thu, Apr 01, 2021 at 03:20:32PM +0000, Ron Natalie wrote: > Thanks, I was looking for the older ones and couldn't find them. > I knew the "tired of seeing this post" thing meant I was looking at a > reprise. > > By the way, for those who don't know. Spaf didn't write any of it. The > message itself was the spoof warned about (and all the "ways to tell" appear > in the message/headers). It's always amazed me that courts will take emails as "evidence" because it is absolutely trivial to fake them. Unless they've added some crypto host identification (have they?) --lm From lm at mcvoy.com Fri Apr 2 01:33:37 2021 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 1 Apr 2021 08:33:37 -0700 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: <20210401152738.GB1202@naleco.com> References: <20210401145025.GA1202@naleco.com> <20210401152738.GB1202@naleco.com> Message-ID: <20210401153337.GK4209@mcvoy.com> On Thu, Apr 01, 2021 at 05:27:40PM +0200, Josh Good wrote: > On 2021 Apr 1, 09:12, Warner Losh wrote: > > The other set of claims made, which may be stronger, was that IBM and > > Redhat used their dominant position to lock out OSes other than Linux, > > including FreeBSD from their cloud platform. > > I don't think IBM has a dominant position in the cloud business. Microsoft's > Azure and Amazon's AWS are the dominant forces in the cloud business. > > I don't see merit on that claim from XinuOS. They are just firing in all > directions to find out if by chance they hit some target with money to milk. And the real joke is that they haven't done any serious work so far as I can tell. The original SCO sucked and then they release SVr but so far as I know, there wasn't a decent development team. When I was doing the TCP/IP port I worked with Jeff Radik a bunch but I never got the sense there were big projects at SCO, it was mostly out sourcing. That was a long time ago so who knows. All I know is that Sun did orders of magnitude more work to the kernel, libraries, at the rest of user space. From kevin.bowling at kev009.com Fri Apr 2 02:14:17 2021 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Thu, 1 Apr 2021 09:14:17 -0700 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: <20210401153337.GK4209@mcvoy.com> References: <20210401145025.GA1202@naleco.com> <20210401152738.GB1202@naleco.com> <20210401153337.GK4209@mcvoy.com> Message-ID: On Thu, Apr 1, 2021 at 8:34 AM Larry McVoy wrote: > On Thu, Apr 01, 2021 at 05:27:40PM +0200, Josh Good wrote: > > On 2021 Apr 1, 09:12, Warner Losh wrote: > > > The other set of claims made, which may be stronger, was that IBM and > > > Redhat used their dominant position to lock out OSes other than Linux, > > > including FreeBSD from their cloud platform. > > > > I don't think IBM has a dominant position in the cloud business. > Microsoft's > > Azure and Amazon's AWS are the dominant forces in the cloud business. > > > > I don't see merit on that claim from XinuOS. They are just firing in all > > directions to find out if by chance they hit some target with money to > milk. > > And the real joke is that they haven't done any serious work so far as I > can > tell. The original SCO sucked and then they release SVr but so > far as I know, there wasn't a decent development team. When I was doing > the TCP/IP port I worked with Jeff Radik a bunch but I never got the sense > there were big projects at SCO, it was mostly out sourcing. That was a > long time ago so who knows. My understanding is SCO was known for good company with good engineers in the early ‘90s. Do we not have any alumni on this list? > > All I know is that Sun did orders of magnitude more work to the kernel, > libraries, at the rest of user space. I think amongst other problems they got fragmented too early with three unix forks for that small a company. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at jfloren.net Fri Apr 2 02:14:28 2021 From: john at jfloren.net (John Floren) Date: Thu, 1 Apr 2021 09:14:28 -0700 Subject: [TUHS] 30th Anniversary of most epic netnews post In-Reply-To: <20210401152810.GI4209@mcvoy.com> References: <87zgyi5bhj.fsf@tullinup.koldfront.dk> <20210401152810.GI4209@mcvoy.com> Message-ID: On Thu, Apr 1, 2021 at 8:29 AM Larry McVoy wrote: > It's always amazed me that courts will take emails as "evidence" because it is > absolutely trivial to fake them. Unless they've added some crypto host > identification (have they?) > > --lm To some extent, yes, via DKIM: https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail This came up during the Hunter Biden email, uh, "situation". Basically you can use the DKIM signature to verify that an email was actually sent from a particular user account on a particular server. Of course, it makes no guarantee of who actually *wrote* that email, only that it was sent by someone with access to the account... or, more sinisterly, that the owner of the mail server has helped to fake the email! Here's a POC: https://github.com/robertdavidgraham/hunter-dkim For unrelated reasons, late last year people started calling for Google to periodically rotate DKIM keys and release the old ones, which would mean anyone could spoof an email from a few years ago: https://blog.cryptographyengineering.com/2020/11/16/ok-google-please-publish-your-dkim-secret-keys/ John From rich.salz at gmail.com Fri Apr 2 02:22:42 2021 From: rich.salz at gmail.com (Richard Salz) Date: Thu, 1 Apr 2021 12:22:42 -0400 Subject: [TUHS] 30th Anniversary of most epic netnews post In-Reply-To: References: <87zgyi5bhj.fsf@tullinup.koldfront.dk> <20210401152810.GI4209@mcvoy.com> Message-ID: Signatures can be forged too but courts seem okay evaluating that kind of evidence. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Fri Apr 2 02:26:51 2021 From: cowan at ccil.org (John Cowan) Date: Thu, 1 Apr 2021 12:26:51 -0400 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <20210401145025.GA1202@naleco.com> <20210401152738.GB1202@naleco.com> <20210401153337.GK4209@mcvoy.com> Message-ID: On Thu, Apr 1, 2021 at 12:15 PM Kevin Bowling wrote: > I think amongst other problems they got fragmented too early with three > unix forks for that small a company. > That's a reasonable approach for a legacy-support company that can pick up the code for what they are supporting, since no one else wants it anyhow. For an OS company, not so much. I think "Xinuos" should be pronounced "sinuous", as in the movement of a snake. You heard it here first. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org It was impossible to inveigle Georg Wilhelm Friedrich Hegel Into offering the slightest apology For his Phenomenology. --W. H. Auden, from "People" (1953) -------------- next part -------------- An HTML attachment was scrubbed... URL: From cym224 at gmail.com Fri Apr 2 02:27:10 2021 From: cym224 at gmail.com (Nemo Nusquam) Date: Thu, 1 Apr 2021 12:27:10 -0400 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: <20210401152738.GB1202@naleco.com> References: <20210401145025.GA1202@naleco.com> <20210401152738.GB1202@naleco.com> Message-ID: <1d9e4f0f-ad1b-ece9-6106-11b5b2429c4c@gmail.com> On 2021-04-01 11:27, Josh Good wrote: > On 2021 Apr 1, 09:12, Warner Losh wrote: >> The other set of claims made, which may be stronger, was that IBM and >> Redhat used their dominant position to lock out OSes other than Linux, >> including FreeBSD from their cloud platform. > I don't think IBM has a dominant position in the cloud business. Microsoft's > Azure and Amazon's AWS are the dominant forces in the cloud business. > > I don't see merit on that claim from XinuOS. They are just firing in all > directions to find out if by chance they hit some target with money to milk. Merit notwithstanding, a lot of time, effort, and money needs to be spent on preparing defences. (Sigh) N. From jfoust at threedee.com Fri Apr 2 01:30:00 2021 From: jfoust at threedee.com (John Foust) Date: Thu, 01 Apr 2021 10:30:00 -0500 Subject: [TUHS] 30th Anniversary of most epic netnews post In-Reply-To: References: <87zgyi5bhj.fsf@tullinup.koldfront.dk> Message-ID: <20210401164343.6779B9C63E@minnie.tuhs.org> Of course they're all referring to the original Kremvax. https://godfatherof.nl/kremvax.html - John From thomas.paulsen at firemail.de Fri Apr 2 03:54:49 2021 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Thu, 01 Apr 2021 19:54:49 +0200 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: <20210401153337.GK4209@mcvoy.com> References: <20210401145025.GA1202@naleco.com> <20210401152738.GB1202@naleco.com> <20210401153337.GK4209@mcvoy.com> Message-ID: > I never got the sense there were big projects at SCO, it was mostly out sourcing. > That was a long time ago so who knows. Ok, they were far ahead time as out sourcing is normal economic behavior today. From jnc at mercury.lcs.mit.edu Fri Apr 2 06:12:11 2021 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 1 Apr 2021 16:12:11 -0400 (EDT) Subject: [TUHS] Data structures in Unix editors Message-ID: <20210401201211.97D7B18C073@mercury.lcs.mit.edu> > From: David C. Brock > I'd like to read similar discussions of the data structures for ed, em, > ex/vi. ... Similarly, if there are any pointers to references on some > other data structures in editors like TECO, QED and E, I'd welcome them > as well. I don't have any discussions I can point you at, but I do have source - for two things which are somewhat older than most of the ones you mention (ex/vi/etc). The first is a TECO from the fourth floor V6 machine (DSSR/RTS) at Tech Sq at MIT: http://ana-3.lcs.mit.edu/~jnc/tech/unix/teco There's some rudimentary documentation in there, in teco.doc, but don't expect too much. You'll have to rely on the source, which is in MACRO-11 - but it seems to be reasonably well commented. This actually predates V6; it was originally written for an MIT OS called DELPHI, which ran on an -11/45 which was the main EECS undergrad machine. At some point (probably post the Unix port), it was modified to have '^R mode', which was a WYSIWYG display mode a lot like the one in the ITS TECO in which EMACS was first written. I have also put up the Montgomery Emacs for Unix: http://ana-3.lcs.mit.edu/~jnc/tech/unix/emacs This is the version we were running on the 5th floor MIT V6 machine (CSR), which by that point have absorbed a few V7isms (e.g. some ioctl() stuff). So don't expect to be able to compile and run it, without a fair amount of work. (I vaguely recall that it needs I+D space, so maybe not on a /23 at all.) But at least the source is in C, so you can read it. I don't think there's an un-modified version online (i.e. the original Montgomery source), alas. Noel From cowan at ccil.org Fri Apr 2 06:57:22 2021 From: cowan at ccil.org (John Cowan) Date: Thu, 1 Apr 2021 16:57:22 -0400 Subject: [TUHS] Data structures in Unix editors In-Reply-To: <20210401201211.97D7B18C073@mercury.lcs.mit.edu> References: <20210401201211.97D7B18C073@mercury.lcs.mit.edu> Message-ID: On Thu, Apr 1, 2021 at 4:31 PM Noel Chiappa wrote: > The first is a TECO from the fourth floor V6 machine (DSSR/RTS) at Tech Sq > at > MIT: > I happen to remember how PDP-8 Teco stored its content. In Teco, for those who have never made its acquaintance, there is the current buffer (which does not typically contain all of the current file) and a bunch of named Q-registers that store blobs of text. Since the PDP-8 is a 12-bit machine, the normal way to store ASCII uses three characters in two words: one in the low 8 bits of the first word, one in the low 8 bits of the second, and one in the top four bits of both words, split big-endian. In Teco, however, the current buffer is stored in the bottom 8 bits of a single 4KW memory field. The Q-registers are stored in alphabetical order by name (a single character) using the straddling top-4-bits method described above. Because the processor cycle time was the same as memory access time anyway, this storage method was perfectly adequate. You can also look at the source for Teco-C, which is available in several places on the net, the last I looked. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org Heckler: "Go on, Al, tell 'em all you know. It won't take long." Al Smith: "I'll tell 'em all we *both* know. It won't take any longer." -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Fri Apr 2 07:11:25 2021 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 2 Apr 2021 08:11:25 +1100 (EST) Subject: [TUHS] 30th Anniversary of most epic netnews post In-Reply-To: References: Message-ID: I remember that one well; I recall that Robert Elz also posted a similar ome, using the path ...!moscvax!kremvax!kgbvax!gorby. -- Dave From dave at horsfall.org Fri Apr 2 07:25:30 2021 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 2 Apr 2021 08:25:30 +1100 (EST) Subject: [TUHS] Data structures in Unix editors In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021, Tony Finch wrote: > A curious one is nvi, which uses the Berkeley DB RECNO interface to > access a text file as an array of lines (RECNO = record number). On FreeBSD as least, "nvi" is used instead of "vi" (and is linked). And oddly enough, BDB is exactly how I would have implemented it... The basic datum is a line after all (I have no idea about EMACS, and don't want to know) so it makes sense to use a structure that can rapidly access arbitrary line numbers. -- Dave From cowan at ccil.org Fri Apr 2 07:27:58 2021 From: cowan at ccil.org (John Cowan) Date: Thu, 1 Apr 2021 17:27:58 -0400 Subject: [TUHS] 30th Anniversary of most epic netnews post In-Reply-To: <20210401152810.GI4209@mcvoy.com> References: <87zgyi5bhj.fsf@tullinup.koldfront.dk> <20210401152810.GI4209@mcvoy.com> Message-ID: On Thu, Apr 1, 2021 at 11:29 AM Larry McVoy wrote: It's always amazed me that courts will take emails as "evidence" because it > is > absolutely trivial to fake them. Unless they've added some crypto host > identification (have they?) Evidence is not the same as conclusive evidence, and it would be perfectly proper for one side to introduce emails and the other side to claim that a particular email or emails are forged. It would then be up to the trier of fact (jury or judge) to decide who is most convincing on that meta-issue. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org And now here I was, in a country where a right to say how the country should be governed was restricted to six persons in each thousand of its population. For the nine hundred and ninety-four to express dissatisfaction with the regnant system and propose to change it, would have made the whole six shudder as one man, it would have been so disloyal, so dishonorable, such putrid black treason. --Mark Twain's Connecticut Yankee -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Fri Apr 2 07:32:11 2021 From: cowan at ccil.org (John Cowan) Date: Thu, 1 Apr 2021 17:32:11 -0400 Subject: [TUHS] Data structures in Unix editors In-Reply-To: References: Message-ID: On Thu, Apr 1, 2021 at 5:26 PM Dave Horsfall wrote: > And oddly enough, BDB is exactly how I would have implemented it... The > basic datum is a line after all (I have no idea about EMACS, and don't > want to know) so it makes sense to use a structure that can rapidly access > arbitrary line numbers. > I'd use SQLite nowadays, because it takes extraordinary care to make sure that no data is lost short of disk failure. It is considerably more robust than the underlying filesystem, and runs embedded in its process. It also means you can readily carry about arbitrary data in additional columns; for example, you could make line marks persistent, including dot. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org Well, I have news for our current leaders and the leaders of tomorrow: the Bill of Rights is not a frivolous luxury, in force only during times of peace and prosperity. We don't just push it to the side when the going gets tough. --Molly Ivins (pbuh) -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.bowling at kev009.com Fri Apr 2 12:16:09 2021 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Thu, 1 Apr 2021 19:16:09 -0700 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: <20210401152738.GB1202@naleco.com> References: <20210401145025.GA1202@naleco.com> <20210401152738.GB1202@naleco.com> Message-ID: On Thu, Apr 1, 2021 at 8:28 AM Josh Good wrote: > > On 2021 Apr 1, 09:12, Warner Losh wrote: > > The other set of claims made, which may be stronger, was that IBM and > > Redhat used their dominant position to lock out OSes other than Linux, > > including FreeBSD from their cloud platform. > > I don't think IBM has a dominant position in the cloud business. Microsoft's > Azure and Amazon's AWS are the dominant forces in the cloud business. > > I don't see merit on that claim from XinuOS. They are just firing in all > directions to find out if by chance they hit some target with money to milk. Yup, it seems flimsy IBM arranged over $100k a few years ago at my request to do the initial FreeBSD bringup on powernv in addition to time and hooking us up with Eldorado Institute. Had there been a commercial deployment there would have been a lot more help and PR. They have and use pfsense in the IBM cloud. It seems like the lawyers didn't do any discovery. It will be interesting to watch. This list will enjoy digging through this http://tenox.pdp-11.ru/monterey/ -- whoever made these business decisions to dump Monterey/IA64 before shipping was good at decision making in a way I haven't seen in my own career. I've long suspected the purchase of Sequent was the real downfall to working with SCO. That too was a great decision. Regards, Kevin > -- > Josh Good > From wobblygong at gmail.com Fri Apr 2 13:52:55 2021 From: wobblygong at gmail.com (Wesley Parish) Date: Fri, 2 Apr 2021 16:52:55 +1300 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <20210401145025.GA1202@naleco.com> Message-ID: Which isn't how I remember things. From what I remember, Linux had the impetus in the late nineties that FreeBSD didn't have - the *BSD were still recovering from the AT&T case, which is why O'Reilly had to issue a 4.4BSD-Lite Cd-ROM when I suspect, they would've preferred to have issued a 4.4BSD complete disc. So from IBM's POV, they could support Linux - which by then had already been ported to the VM/370 and there was already talk of porting it to the later mainframe iterations. I don't think anybody was even thinking of porting any of the *BSD to IBM mainframes till much later, am I right? At any rate, by the time IBM formally joined the Linux club, it was already (unofficial) host to at least one unofficial port to one of its historic mainframes, and official host to an officlal SkunkWorks port to its then-current mainframes. Experience counts. None of the *BSD had nearly as big a presence in the IBM world, and none of the earlier IBM Unix ports, some 4.*BSD, as far as I can remember, ever had the presence of Linux as both a platform and - thanks to Caldera-later-aka-The Sco Group - as a cause. I had hoped that Xinuos was an honest attempt to provide support for remaining SCO sites, but it seems they've fallen to the Dark Side and the Easy Buck again. Sic transit gloria mundi ... Wesley Parish On 4/2/21, Warner Losh wrote: > The other set of claims made, which may be stronger, was that IBM and > Redhat used their dominant position to lock out OSes other than Linux, > including FreeBSD from their cloud platform. > > Their copyright claims look to be a bit different than the old SCO lawsuit. > > Reading their complaint, it is somewhat different than the old suit... > FreeBSD is mentioned like 34 times too, since Xinuos based their products > based on it. And their product is locked out of the IBM/Redhat cloud > platform/ecosystem. The copyright stuff seems almost an afterthought... > > Warner > > On Thu, Apr 1, 2021 at 8:51 AM Josh Good wrote: > >> I read the news, and I could not believe it. >> >> It's April 1st, ain't it? >> >> But then, this looks like is dated March 31. So it could be for real. >> >> Behold: https://www.theregister.com/2021/03/31/ibm_redhat_xinuos/ >> >> The PDF also is dated March 31: >> https://regmedia.co.uk/2021/03/31/xinuos_complaint.pdf >> >> It's hard to believe someone would go to the trouble of writing 57 pages >> of >> legalese just to make a damn joke. >> >> " >> Xinuos, formed around SCO Group assets a decade ago under the >> name >> UnXis and at the time disavowing any interest in continuing SCO's >> long-running Linux litigation, today sued IBM and Red Hat for >> alleged copyright and antitrust law violations. >> >> "First, IBM stole Xinuos' intellectual property and used that >> stolen >> property to build and sell a product to compete with Xinuos >> itself," >> the US Virgin Islands-based software biz claims in its complaint >> [PDF]. "Second, stolen property in IBM's hand, IBM and Red Hat >> illegally agreed to divide the relevant market and use their >> growing >> market powers to victimize consumers, innovative competitors, and >> innovation itself." >> >> The complaint further contends that after the two companies >> conspired to divide the market, IBM then acquired Red Hat to >> solidify its position. >> >> SCO Group in 2003 made a similar intellectual property claim. It >> argued that SCO Group owned the rights to AT&T's Unix and >> UnixWare >> operating system source code, that Linux 2.4.x and 2.5.x were >> unauthorized derivatives of Unix, and that IBM violated its >> contractual obligations by distributing Linux code. >> >> That case dragged on for years, and drew a fair amount of >> attention >> when SCO Group said it would sue individual Linux users for >> infringement. Though SCO filed for bankruptcy in 2007 and some of >> the claims have been dismissed, its case against IBM remains >> unresolved. >> >> There was a status report filed on February 16, 2018, details >> remaining claims and counterclaims. And in May last year, >> Magistrate >> Judge Paul Warner was no longer assigned to oversee settlement >> discussions. But SCO Group v. IBM is still open. >> " >> >> Either way, some one if fooling us hard. >> >> PS: OK, it seems it's for real: >> https://www.xinuos.com/xinuos-sues-ibm-and-red-hat/ >> >> I need to check my stock of pop corn, then... >> >> My take: it's obvious they want to be a nuisance so that IBM settles the >> case, so they then can go back home with some fresh cash. I hope IBM goes >> ballistic on them to the bitter end, and finally sends the zombie back to >> its grave. But then, IBM now has its new RedHat business to protect, so >> it >> can get interesting. >> >> -- >> Josh Good >> >> > From kevin.bowling at kev009.com Fri Apr 2 15:26:52 2021 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Thu, 1 Apr 2021 22:26:52 -0700 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <20210401145025.GA1202@naleco.com> Message-ID: On Thu, Apr 1, 2021 at 8:54 PM Wesley Parish wrote: > Which isn't how I remember things. From what I remember, Linux had the > impetus in the late nineties that FreeBSD didn't have - the *BSD were > still recovering from the AT&T case, which is why O'Reilly had to > issue a 4.4BSD-Lite Cd-ROM when I suspect, they would've preferred to > have issued a 4.4BSD complete disc. So from IBM's POV, they could > support Linux - which by then had already been ported to the VM/370 > and there was already talk of porting it to the later mainframe > iterations. I don't think anybody was even thinking of porting any of > the *BSD to IBM mainframes till much later, am I right? You’ve compressed quite a bit of history. IBM didn’t engage with Linux in a serious way until Jan 2000. It took a bit longer for things to really become corporate, but the fall of the first dot com bubble definitely started skewing toward Linux and away from commercial unix, windows, BSD, whatever. Red Hat (and many of its variants like Amazon Linux, CentOS) and Ubuntu emerged as early winners in the corporate and cloud market. I think Ubuntu discredits a lot of the claims. IBM is a major contributor to Ubuntu. > At any rate, by the time IBM formally joined the Linux club, it was > already (unofficial) host to at least one unofficial port to one of > its historic mainframes, and official host to an officlal SkunkWorks > port to its then-current mainframes. Experience counts. > > None of the *BSD had nearly as big a presence in the IBM world, and > none of the earlier IBM Unix ports, some 4.*BSD, as far as I can > remember, ever had the presence of Linux as both a platform and - > thanks to Caldera-later-aka-The Sco Group - as a cause. > Yes IBM shipped 4.3 BSD as AOS, Academic Operating System (the name which is kind of funny). There’s definitely BSD code in every OS they ship, including os/400 by way of PASE (this is somewhat ironic because IBM went to great lengths to keep unix influences out of os/400). > I had hoped that Xinuos was an honest attempt to provide support for > remaining SCO sites, but it seems they've fallen to the Dark Side and > the Easy Buck again. Sic transit gloria mundi ... > The case looks flimsy. Some lawyers will make money regardless, I’d be surprised if anyone would take something like this on without immediate remuneration. > Wesley Parish > > On 4/2/21, Warner Losh wrote: > > The other set of claims made, which may be stronger, was that IBM and > > Redhat used their dominant position to lock out OSes other than Linux, > > including FreeBSD from their cloud platform. > > > > Their copyright claims look to be a bit different than the old SCO > lawsuit. > > > > Reading their complaint, it is somewhat different than the old suit... > > FreeBSD is mentioned like 34 times too, since Xinuos based their products > > based on it. And their product is locked out of the IBM/Redhat cloud > > platform/ecosystem. The copyright stuff seems almost an afterthought... > > > > Warner > > > > On Thu, Apr 1, 2021 at 8:51 AM Josh Good wrote: > > > >> I read the news, and I could not believe it. > >> > >> It's April 1st, ain't it? > >> > >> But then, this looks like is dated March 31. So it could be for real. > >> > >> Behold: https://www.theregister.com/2021/03/31/ibm_redhat_xinuos/ > >> > >> The PDF also is dated March 31: > >> https://regmedia.co.uk/2021/03/31/xinuos_complaint.pdf > >> > >> It's hard to believe someone would go to the trouble of writing 57 pages > >> of > >> legalese just to make a damn joke. > >> > >> " > >> Xinuos, formed around SCO Group assets a decade ago under the > >> name > >> UnXis and at the time disavowing any interest in continuing > SCO's > >> long-running Linux litigation, today sued IBM and Red Hat for > >> alleged copyright and antitrust law violations. > >> > >> "First, IBM stole Xinuos' intellectual property and used that > >> stolen > >> property to build and sell a product to compete with Xinuos > >> itself," > >> the US Virgin Islands-based software biz claims in its complaint > >> [PDF]. "Second, stolen property in IBM's hand, IBM and Red Hat > >> illegally agreed to divide the relevant market and use their > >> growing > >> market powers to victimize consumers, innovative competitors, > and > >> innovation itself." > >> > >> The complaint further contends that after the two companies > >> conspired to divide the market, IBM then acquired Red Hat to > >> solidify its position. > >> > >> SCO Group in 2003 made a similar intellectual property claim. It > >> argued that SCO Group owned the rights to AT&T's Unix and > >> UnixWare > >> operating system source code, that Linux 2.4.x and 2.5.x were > >> unauthorized derivatives of Unix, and that IBM violated its > >> contractual obligations by distributing Linux code. > >> > >> That case dragged on for years, and drew a fair amount of > >> attention > >> when SCO Group said it would sue individual Linux users for > >> infringement. Though SCO filed for bankruptcy in 2007 and some > of > >> the claims have been dismissed, its case against IBM remains > >> unresolved. > >> > >> There was a status report filed on February 16, 2018, details > >> remaining claims and counterclaims. And in May last year, > >> Magistrate > >> Judge Paul Warner was no longer assigned to oversee settlement > >> discussions. But SCO Group v. IBM is still open. > >> " > >> > >> Either way, some one if fooling us hard. > >> > >> PS: OK, it seems it's for real: > >> https://www.xinuos.com/xinuos-sues-ibm-and-red-hat/ > >> > >> I need to check my stock of pop corn, then... > >> > >> My take: it's obvious they want to be a nuisance so that IBM settles the > >> case, so they then can go back home with some fresh cash. I hope IBM > goes > >> ballistic on them to the bitter end, and finally sends the zombie back > to > >> its grave. But then, IBM now has its new RedHat business to protect, so > >> it > >> can get interesting. > >> > >> -- > >> Josh Good > >> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davida at pobox.com Fri Apr 2 15:41:11 2021 From: davida at pobox.com (David Arnold) Date: Fri, 2 Apr 2021 16:41:11 +1100 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: <20210401145025.GA1202@naleco.com> References: <20210401145025.GA1202@naleco.com> Message-ID: > Xinuos Reverse that, and with some squinting, you get something that sounds like “Sue ‘nix”. Perhaps it’s a long running joke after all? d From usotsuki at buric.co Fri Apr 2 16:09:41 2021 From: usotsuki at buric.co (Steve Nickolas) Date: Fri, 2 Apr 2021 02:09:41 -0400 (EDT) Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <20210401145025.GA1202@naleco.com> Message-ID: On Fri, 2 Apr 2021, David Arnold wrote: > >> Xinuos > > Reverse that, and with some squinting, you get something that sounds like “Sue ‘nix”. > > Perhaps it’s a long running joke after all? Maybe with some luck they, too, will go broke and there'll be so little left of them that even someone like me could buy their charred remains. Hopefully we can get to a point where there can be a truly unclouded free and open release of the Ancient Unix/Research Unix sources. -uso. From arnold at skeeve.com Fri Apr 2 17:00:14 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 02 Apr 2021 01:00:14 -0600 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <20210401145025.GA1202@naleco.com> Message-ID: <202104020700.13270EDK018774@freefriends.org> Steve Nickolas wrote: > Hopefully we can get to a point where there can be a truly unclouded free > and open release of the Ancient Unix/Research Unix sources. This there already is. They're in the TUHS archives. Arnold From usotsuki at buric.co Fri Apr 2 19:53:59 2021 From: usotsuki at buric.co (Steve Nickolas) Date: Fri, 2 Apr 2021 05:53:59 -0400 (EDT) Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: <202104020700.13270EDK018774@freefriends.org> References: <20210401145025.GA1202@naleco.com> <202104020700.13270EDK018774@freefriends.org> Message-ID: On Fri, 2 Apr 2021, arnold at skeeve.com wrote: > Steve Nickolas wrote: > >> Hopefully we can get to a point where there can be a truly unclouded free >> and open release of the Ancient Unix/Research Unix sources. > > This there already is. They're in the TUHS archives. > > Arnold > There's still a cloud over Caldera's release, because the current license relies on assuming Caldera owned the copyright at the time (pretty sure the courts said they didn't). -uso. From arnold at skeeve.com Fri Apr 2 20:26:43 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 02 Apr 2021 04:26:43 -0600 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <20210401145025.GA1202@naleco.com> <202104020700.13270EDK018774@freefriends.org> Message-ID: <202104021026.132AQhs5014565@freefriends.org> Steve Nickolas wrote: > There's still a cloud over Caldera's release, because the current license > relies on assuming Caldera owned the copyright at the time (pretty sure > the courts said they didn't). > > -uso. The cat's been out of the bag since ~ 2002, almost 20 years. In effect, it's too late anyway. Arnold From pepe at naleco.com Sat Apr 3 00:02:31 2021 From: pepe at naleco.com (Josh Good) Date: Fri, 2 Apr 2021 16:02:31 +0200 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: <202104021026.132AQhs5014565@freefriends.org> References: <20210401145025.GA1202@naleco.com> <202104020700.13270EDK018774@freefriends.org> <202104021026.132AQhs5014565@freefriends.org> Message-ID: <20210402140229.GD1202@naleco.com> On 2021 Apr 2, 04:26, arnold at skeeve.com wrote: > Steve Nickolas wrote: > > > There's still a cloud over Caldera's release, because the current license > > relies on assuming Caldera owned the copyright at the time (pretty sure > > the courts said they didn't). > > The cat's been out of the bag since ~ 2002, almost 20 years. In effect, > it's too late anyway. The source for ancient/research UNIX is out of the bag. An unclouded licence to freely use it, that is quite another thing. If Caldera/TSG didn't own the copyright for UNIX, and Novell did (and that has indeed been asserted by a judge in court), then Caldera/TSG had no title to relicense that source. In fact, it seems that SCO/Caldera/TSG just bought from Novell the "Unix business" without the UNIX copyrights, and in that vein Old-SCO had a contract with Novell to collect the UNIX royalties and then to pay said royalties to Novell keeping a cut of them "for the collecting services". So the key point here is "unclouded license". Look what is happening now to IBM because their matter with Caldera/TSG still had clouds of doubt about it. I have the suspicion that if Caldera/TSG/XinuOS is allowed to exist, they will use all and any cloud of doubt to drag to court any UNIX user who happens to have plenty of money and lacks a UNIX license directly gotten from the old AT&T or the old UNIX Labs. They are undead money-sucking vampires. -- Josh Good From usotsuki at buric.co Sat Apr 3 00:17:51 2021 From: usotsuki at buric.co (Steve Nickolas) Date: Fri, 2 Apr 2021 10:17:51 -0400 (EDT) Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: <20210402140229.GD1202@naleco.com> References: <20210401145025.GA1202@naleco.com> <202104020700.13270EDK018774@freefriends.org> <202104021026.132AQhs5014565@freefriends.org> <20210402140229.GD1202@naleco.com> Message-ID: On Fri, 2 Apr 2021, Josh Good wrote: > On 2021 Apr 2, 04:26, arnold at skeeve.com wrote: >> Steve Nickolas wrote: >> >>> There's still a cloud over Caldera's release, because the current license >>> relies on assuming Caldera owned the copyright at the time (pretty sure >>> the courts said they didn't). >> >> The cat's been out of the bag since ~ 2002, almost 20 years. In effect, >> it's too late anyway. > > The source for ancient/research UNIX is out of the bag. An unclouded licence > to freely use it, that is quite another thing. If Caldera/TSG didn't own the > copyright for UNIX, and Novell did (and that has indeed been asserted by a > judge in court), then Caldera/TSG had no title to relicense that source. This was what I was pointing at, and why I used as many terms as I could to make it unambiguous what I meant. A license to use code copyrighted by Caldera is meaningless if the code is NOT copyrighted by Caldera, but by Novell (as has been established in a court of law). Sure, it's possible one could go for years or decades without being sued, but with what I intended to do with the code, unless there were an unclouded free/open license (anything from Toybox to MIT to 4BSD to LGPL to GPL3, I don't really care) it would legally be like painting a bullseye on myself. I think this is why, although some of the BSDs did reintegrate the 32V and V7 stuff, others stayed clear. There's enough of a cloud over the release that it's still not really safe. "It's out there" isn't good enough. SunOS 4 is "out there" - nobody in their right mind would integrate that into a freely available OS distro because Oracle would come down on them like a megaton of bricks! -uso. From lm at mcvoy.com Sat Apr 3 01:16:50 2021 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 2 Apr 2021 08:16:50 -0700 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <20210401145025.GA1202@naleco.com> <202104020700.13270EDK018774@freefriends.org> <202104021026.132AQhs5014565@freefriends.org> <20210402140229.GD1202@naleco.com> Message-ID: <20210402151650.GA8268@mcvoy.com> On Fri, Apr 02, 2021 at 10:17:51AM -0400, Steve Nickolas wrote: > A license to use code copyrighted by Caldera is meaningless if the code is > NOT copyrighted by Caldera, but by Novell (as has been established in a > court of law). Sure, it's possible one could go for years or decades > without being sued, but with what I intended to do with the code, unless > there were an unclouded free/open license (anything from Toybox to MIT to > 4BSD to LGPL to GPL3, I don't really care) it would legally be like painting > a bullseye on myself. So I get that playing with v6 in an emulator is fun, it's a trip down memory lane. What I don't get is why on God's Green Earth you would contemplate building any sort of product on ancient Unix. > "It's out there" isn't good enough. SunOS 4 is "out there" - nobody in > their right mind would integrate that into a freely available OS distro > because Oracle would come down on them like a megaton of bricks! SunOS 4, though I love it more than most people, is ancient history and is basically under one big lock for SMP. It was a huge amount of work to get that code to scale in Solaris (they lifted the VM system and the hat layer from SunOS 4 to 5 and then went to work). So other than walking down memory lane, why would you want that code? From pepe at naleco.com Sat Apr 3 01:25:25 2021 From: pepe at naleco.com (Josh Good) Date: Fri, 2 Apr 2021 17:25:25 +0200 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <20210401145025.GA1202@naleco.com> <202104020700.13270EDK018774@freefriends.org> <202104021026.132AQhs5014565@freefriends.org> <20210402140229.GD1202@naleco.com> Message-ID: <20210402152523.GA10759@naleco.com> On 2021 Apr 2, 10:17, Steve Nickolas wrote: > > A license to use code copyrighted by Caldera is meaningless if the code is > NOT copyrighted by Caldera, but by Novell (as has been established in a > court of law). Indeed. > I think this is why, although some of the BSDs did reintegrate the 32V and > V7 stuff, others stayed clear. There's enough of a cloud over the release > that it's still not really safe. Let no one think they are free from Caldera/TSG/XinuOS money thirst. As long as they remain "alive", they will drag to court anyone with enough money to milk in the BSD/Unix/Linux ecosystem. Think I'm being too dramatic? Well, consider this old news from 2003: Why SCO will Soon be Going After BSD Submitted by Alex Alvarez 2003-11-18 SCO 85 Comments “Since they cannot show infringement of SCO Unix code, SCO now plans to challenge the 9-year-old settlement between AT&T and BSD. If it can successfully do that, then its claims that Linux contains tainted code can be substantiated. If it can’t, SCO is dead meat.” Says NewsForge. *Updated*More SCO news: SCO is planning to block Novell’s acquisition of SUSE Linux on the grounds that it has a non-compete agreement with Novell dating back to its purchase of Unix. https://www.osnews.com/story/5169/why-sco-will-soon-be-going-after-bsd/ BSD people be aware: XinuOS has you next in their hit list. Zombified money-sucking vampires, they will not stop until they are put to rest for good. -- Josh Good From fabio at esse.ch Sat Apr 3 01:28:49 2021 From: fabio at esse.ch (Fabio Scotoni) Date: Fri, 2 Apr 2021 17:28:49 +0200 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: <20210402151650.GA8268@mcvoy.com> References: <20210401145025.GA1202@naleco.com> <202104020700.13270EDK018774@freefriends.org> <202104021026.132AQhs5014565@freefriends.org> <20210402140229.GD1202@naleco.com> <20210402151650.GA8268@mcvoy.com> Message-ID: <79717f6c-a576-bf8c-acaf-83a48a234b28@esse.ch> On 02.04.21 17:16, Larry McVoy wrote: > So I get that playing with v6 in an emulator is fun, it's a trip down memory > lane. What I don't get is why on God's Green Earth you would contemplate > building any sort of product on ancient Unix. While I'm not aware of any examples of anything building on ancient UNIX as a whole, I would like to note that parts of ancient UNIX have made their way into other systems. For example, FreeBSD and OpenBSD src/usr.bin/diff/diffreg.c are derived from Ancient UNIX diff(1) source code, namely 7th Edition UNIX. (There is some amount of irony in Xinuos forking FreeBSD and basically importing their own licensing issue indirectly.) Various pieces of documentation under the Caldera license also permeate the BSDs. From clemc at ccc.com Sat Apr 3 02:03:41 2021 From: clemc at ccc.com (Clem Cole) Date: Fri, 2 Apr 2021 12:03:41 -0400 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <20210401145025.GA1202@naleco.com> Message-ID: On Thu, Apr 1, 2021 at 11:54 PM Wesley Parish wrote: > I don't think anybody was even thinking of porting any of > the *BSD to IBM mainframes till much later, am I right? > No. BSD was very much on IBM's radar in the late 1970s and 1980s. Long before Linus released Linux into the wild in 1990 for the >>386<< much less any other ISA, IBM had been shipping as a product AIX/370 (and AIX/PS2 for the 386); which we developed at Locus for them. The user-space was mostly System V, the kernel was based on BSD (4.1 originally) pluis a great deal of customization, including of course the Locus OS work, which IBM called TCF - the transparent computing facility. It was very cool you could cluster 370s and PS/2 and from >>any<< node run a program of either ISA. It has been well discussed in this forum, previously. A for AIX/370 a quick history which Charlie can fill in more from the IBM side, was that in the last 60s and early 70s, IBM had a strange hold on the education/research market with the S/360; but lost it because of the lack of timesharing to DEC and PDP-10 based systems as IBM was more and more focused on the commercial sector where there was much more money to be made. But ... there was a drive in the IBM educational/research team to be able to reenter that market and Locus was hired to develop AIX/370 (and later PS2) as it was felt that UNIX was considered an important offering for those customers. After it was released as a product, it turned out purchasing AIX/370 was exceedingly difficult (for a number of reasons), although it was extremely well received by those that ran it, but getting it was difficult. In fact, I have been told by folks that there at the time, that using TCF was an important feature here at Intel for the success of the simulation for the 486 and Pentium. Again, Charlie can tell you the history but IBM also developed AIX for the RS/6000 which was the same OS (only different) from IBM Austin (no TCF, but supported DS which was cool in its own right). Locus was actually contracted to develop a UNIX subsystem for the AS/400 also, but I'm not sure if that ever shipped. I had left Locus and had gone to DEC by then. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Apr 3 02:11:47 2021 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 2 Apr 2021 09:11:47 -0700 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <20210401145025.GA1202@naleco.com> Message-ID: <20210402161147.GG8268@mcvoy.com> On Fri, Apr 02, 2021 at 12:03:41PM -0400, Clem Cole wrote: > On Thu, Apr 1, 2021 at 11:54 PM Wesley Parish wrote: > > > I don't think anybody was even thinking of porting any of > > the *BSD to IBM mainframes till much later, am I right? > > > No. BSD was very much on IBM's radar in the late 1970s and 1980s. > > Long before Linus released Linux into the wild in 1990 for the >>386<< much > less any other ISA, IBM had been shipping as a product AIX/370 (and AIX/PS2 > for the 386); which we developed at Locus for them. The user-space was > mostly System V, the kernel was based on BSD (4.1 originally) pluis a great > deal of customization, including of course the Locus OS work, which IBM > called TCF - the transparent computing facility. It was very cool you > could cluster 370s and PS/2 and from >>any<< node run a program of either > ISA. It has been well discussed in this forum, previously. It's really a shame that TCF didn't get more widespread usage/traction. That's exactly what BitMover wanted to do, I wanted to scale small cheap SMPs in a cluster with a TCF layer on it. I gave some talks about it, it obviously went nowhere but might have if we had TCF as a starting point. TCF was cool. From heinz at osta.com Sat Apr 3 02:39:49 2021 From: heinz at osta.com (Heinz Lycklama) Date: Fri, 2 Apr 2021 09:39:49 -0700 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <20210401145025.GA1202@naleco.com> Message-ID: The first version of AIX for the IBM RT PC was developed by INTERACTIVE Systems Corp. under contract to IBM. The second version of AIX was developed by Locus Computing. Some brief history can be found here:     1. https://en.wikipedia.org/wiki/Interactive_Systems_Corporation     2. https://en.wikipedia.org/wiki/IBM_AIX#IBM_RT_PC Heinz On 4/2/2021 9:03 AM, Clem Cole wrote: > > > On Thu, Apr 1, 2021 at 11:54 PM Wesley Parish > wrote: > >  I don't think anybody was even thinking of porting any of > the *BSD to IBM mainframes till much later, am I right? > > No.   BSD was very much on IBM's radar in the late 1970s and 1980s. > > Long before Linus released Linux into the wild in 1990 for the >>386<< > much less any other ISA, IBM had been shipping as a product AIX/370 > (and AIX/PS2 for the 386); which we developed at Locus for them.  The > user-space was mostly System V, the kernel was based on BSD (4.1 > originally) pluis a great deal of customization, including of course > the Locus OS work, which IBM called TCF - the transparent computing > facility.  It was very cool you could cluster 370s and PS/2 and from > >>any<< node run a program of either ISA.   It has been well discussed > in this forum, previously. > > A for AIX/370 a quick history which Charlie can fill in more from the > IBM side, was that in the last 60s and early 70s, IBM had a strange > hold on the education/research market with the S/360; but lost it > because of the lack of timesharing to DEC and PDP-10 based systems as > IBM was more and more focused on the commercial sector where there was > much more money to be made.   But ... there was a drive in the IBM > educational/research team to be able to reenter that market and Locus > was hired to develop AIX/370 (and later PS2) as it was felt that UNIX > was considered an important offering for those customers.  After it > was released as a product, it turned out purchasing AIX/370 was > exceedingly difficult (for a number of reasons), although it was > extremely well received by those that ran it, but getting it was > difficult.  In fact, I have been told by folks that there at the time, > that using TCF was an important feature here at Intel for the success > of the simulation for the 486 and Pentium. > > Again, Charlie can tell you the history but IBM also developed AIX for > the RS/6000 which was the same OS (only different) from IBM Austin(no > TCF, but supported DS which was cool in its own right). Locus was > actually contracted to develop a UNIX subsystem for the AS/400 also, > but I'm not sure if that ever shipped.  I had left Locus and hadgoneto > DEC by then. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerberb at zenez.com Sat Apr 3 02:40:14 2021 From: gerberb at zenez.com (Boyd Lynn Gerber) Date: Fri, 2 Apr 2021 10:40:14 -0600 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: <20210401145025.GA1202@naleco.com> References: <20210401145025.GA1202@naleco.com> Message-ID: On Thursday 2021-04-01 16:50, Josh Good wrote: > I read the news, and I could not believe it. > > It's April 1st, ain't it? > > But then, this looks like is dated March 31. So it could be for real. > > Behold: https://www.theregister.com/2021/03/31/ibm_redhat_xinuos/ I do know that AIX was extended by the SCO code. I know that being an outsider doing MISC... on the AIX Development under a NDA. I was suprised how much AIX was enhanced with the code base of SCO. Just a FYI -- Boyd Gerber 801 849-0213 ZENEZ 1042 East Fort Union #135, Midvale Utah 84047 From clemc at ccc.com Sat Apr 3 03:14:01 2021 From: clemc at ccc.com (Clem Cole) Date: Fri, 2 Apr 2021 13:14:01 -0400 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <20210401145025.GA1202@naleco.com> Message-ID: Mei culpa/my apologies -- I left out the ISC part of the story and I was not trying to rewrite history in any way. In fact, to the rest of the list, ISC did the first 386 port of UNIX - which for UNIX history is extremely significant. One of my favorite pieces of salesmanship - Heinz, Peter, and Phil Shevrin managed to convince both AT&T and Intel to separately pay for the 386 port (and I thought IBM was in that mix somehow too). Then ISC brought it out as a separate product that I think Sun ended up with at some later time yet. If I recall, ISC did the original work on the RT (which redates the RS/6000) and the ISC folks had their own product for VM before IBM released AIX/370 as a product. Heinz and Charlie would know more details on those ports. That said, the comment that I was originally replying to was about IBM getting interested in BSD UNIX and my point was simply, AIX/370 was BSD-based and was shipping as an *IBM produc*t years before Linus even started working on what would become Linux for his 386 based machine; much less any attempt to get it running on the 370. Also, if we are to be complete. Tom Lyons did the original 360/370 C/UNIX work at Princeton & AT&T long before any of that, starting in the mid-1970s but I'll let Tom fill you in there. On Fri, Apr 2, 2021 at 12:40 PM Heinz Lycklama wrote: > The first version of AIX for the IBM RT PC was developed by INTERACTIVE > Systems Corp. > under contract to IBM. The second version of AIX was developed by Locus > Computing. > Some brief history can be found here: > 1. https://en.wikipedia.org/wiki/Interactive_Systems_Corporation > 2. https://en.wikipedia.org/wiki/IBM_AIX#IBM_RT_PC > > Heinz > ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sauer at technologists.com Sat Apr 3 03:17:10 2021 From: sauer at technologists.com (Charles H Sauer) Date: Fri, 2 Apr 2021 12:17:10 -0500 Subject: [TUHS] AIX repeat [was Re: Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <20210401145025.GA1202@naleco.com> Message-ID: I'm not sure that I have anything to add beyond repeating citation to https://notes.technologists.com/notes/2017/03/08/lets-start-at-the-very-beginning-801-romp-rtpc-aix-versions/. It credits ISC and LCC appropriately. AIX involvement with SCO, if any, would have been after I left IBM. I find it hard to imagine what that involvement would have been. Charlie On 4/2/2021 11:03 AM, Clem Cole wrote: > > > On Thu, Apr 1, 2021 at 11:54 PM Wesley Parish > wrote: > >  I don't think anybody was even thinking of porting any of > the *BSD to IBM mainframes till much later, am I right? > > No.   BSD was very much on IBM's radar in the late 1970s and 1980s. > > Long before Linus released Linux into the wild in 1990 for the >>386<< > much less any other ISA, IBM had been shipping as a product AIX/370 (and > AIX/PS2 for the 386); which we developed at Locus for them.  The > user-space was mostly System V, the kernel was based on BSD (4.1 > originally) pluis a great deal of customization, including of course the > Locus OS work, which IBM called TCF - the transparent computing > facility.  It was very cool you could cluster 370s and PS/2 and from > >>any<< node run a program of either ISA.   It has been well discussed > in this forum, previously. > > A for AIX/370 a quick history which Charlie can fill in more from the > IBM side, was that in the last 60s and early 70s, IBM had a strange hold > on the education/research market with the S/360; but lost it because of > the lack of timesharing to DEC and PDP-10 based systems as IBM was more > and more focused on the commercial sector where there was much more > money to be made.   But ... there was a drive in the IBM > educational/research team to be able to reenter that market and Locus > was hired to develop AIX/370 (and later PS2) as it was felt that UNIX > was considered an important offering for those customers.  After it was > released as a product, it turned out purchasing AIX/370 was exceedingly > difficult (for a number of reasons), although it was extremely well > received by those that ran it, but getting it was difficult.  In fact, I > have been told by folks that there at the time, that using TCF was an > important feature here at Intel for the success of the simulation for > the 486 and Pentium. > > Again, Charlie can tell you the history but IBM also developed AIX for > the RS/6000 which was the same OS (only different) from IBM Austin(no > TCF, but supported DS which was cool in its own right).  Locus was > actually contracted to develop a UNIX subsystem for the AS/400 also, but > I'm not sure if that ever shipped.  I had left Locus and hadgoneto DEC > by then. -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Skype/Twitter: CharlesHSauer From dave at horsfall.org Sat Apr 3 08:40:45 2021 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 3 Apr 2021 09:40:45 +1100 (EST) Subject: [TUHS] Data structures in Unix editors In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021, John Cowan wrote: [ Me thinking of using BDB for editor data structures ] > I'd use SQLite nowadays, because it takes extraordinary care to make > sure that no data is lost short of disk failure.  It is considerably > more robust than the underlying filesystem, and runs embedded in its > process.  It also means you can readily carry about arbitrary data in > additional columns; for example, you could make line marks persistent, > including dot. Good point; thanks. I'd forgotten about SQLite... I doubt if I'll be writing a new editor any time soon though (VI works just fine) but was planning on incorporating it in a project I'm working on. -- Dave From athornton at gmail.com Sat Apr 3 09:20:25 2021 From: athornton at gmail.com (Adam Thornton) Date: Fri, 2 Apr 2021 16:20:25 -0700 Subject: [TUHS] Data structures in Unix editors In-Reply-To: References: Message-ID: 's' from Webb Miller's _A Software Tools Sampler_ is an exhaustively documented sort-of-stripped-down vi. Admittedly it's a little tricky to get your hands on the source document (I got it from interlibrary loan back at the end of the Before Times, and archive.org lets you check it out for a limited time, but there may be a waitlist). It's interesting in that it's not just studying the source to see how it works, but an actual (large) chapter of a book where he steps through the construction of the individual functions and their keybindings. Adam On Fri, Apr 2, 2021 at 3:42 PM Dave Horsfall wrote: > On Thu, 1 Apr 2021, John Cowan wrote: > > [ Me thinking of using BDB for editor data structures ] > > > I'd use SQLite nowadays, because it takes extraordinary care to make > > sure that no data is lost short of disk failure. It is considerably > > more robust than the underlying filesystem, and runs embedded in its > > process. It also means you can readily carry about arbitrary data in > > additional columns; for example, you could make line marks persistent, > > including dot. > > Good point; thanks. I'd forgotten about SQLite... I doubt if I'll be > writing a new editor any time soon though (VI works just fine) but was > planning on incorporating it in a project I'm working on. > > -- Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From nobozo at gmail.com Sat Apr 3 10:34:37 2021 From: nobozo at gmail.com (Jon Forrest) Date: Fri, 2 Apr 2021 17:34:37 -0700 Subject: [TUHS] Data structures in Unix editors In-Reply-To: References: Message-ID: <98d8e658-816d-507b-a061-b599449b49da@gmail.com> On 4/2/2021 4:20 PM, Adam Thornton wrote: > 's' from Webb Miller's _A Software Tools Sampler_ is an exhaustively > documented sort-of-stripped-down vi.  Admittedly it's a little tricky to > get your hands on the source document (I got it from interlibrary loan > back at the end of the Before Times, and archive.org > lets you check it out for a limited time, but there > may be a waitlist). I have a copy of this book for sale. It's in excellent condition. It wasn't sold with the software that's printed in the book so you'll have to somehow get the software yourself. I'd like $45 plus shipping. (I'll only ship to the US). If you're interested please contact me directly offlist. Cordially, Jon Forrest From wobblygong at gmail.com Sat Apr 3 11:24:51 2021 From: wobblygong at gmail.com (Wesley Parish) Date: Sat, 3 Apr 2021 14:24:51 +1300 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <20210401145025.GA1202@naleco.com> Message-ID: Thanks. I knew IBM had had some involvement with 4.*BSD, but lacked the details. Wesley Parish On 4/3/21, Clem Cole wrote: > On Thu, Apr 1, 2021 at 11:54 PM Wesley Parish wrote: > >> I don't think anybody was even thinking of porting any of >> the *BSD to IBM mainframes till much later, am I right? >> > No. BSD was very much on IBM's radar in the late 1970s and 1980s. > > Long before Linus released Linux into the wild in 1990 for the >>386<< much > less any other ISA, IBM had been shipping as a product AIX/370 (and AIX/PS2 > for the 386); which we developed at Locus for them. The user-space was > mostly System V, the kernel was based on BSD (4.1 originally) pluis a great > deal of customization, including of course the Locus OS work, which IBM > called TCF - the transparent computing facility. It was very cool you > could cluster 370s and PS/2 and from >>any<< node run a program of either > ISA. It has been well discussed in this forum, previously. > > A for AIX/370 a quick history which Charlie can fill in more from the IBM > side, was that in the last 60s and early 70s, IBM had a strange hold on the > education/research market with the S/360; but lost it because of the lack > of timesharing to DEC and PDP-10 based systems as IBM was more and more > focused on the commercial sector where there was much more money to be > made. But ... there was a drive in the IBM educational/research team to > be able to reenter that market and Locus was hired to develop AIX/370 (and > later PS2) as it was felt that UNIX was considered an important offering > for those customers. After it was released as a product, it turned out > purchasing AIX/370 was exceedingly difficult (for a number of reasons), > although it was extremely well received by those that ran it, but getting > it was difficult. In fact, I have been told by folks that there at the > time, that using TCF was an important feature here at Intel for the success > of the simulation for the 486 and Pentium. > > Again, Charlie can tell you the history but IBM also developed AIX for the > RS/6000 which was the same OS (only different) from IBM Austin (no TCF, but > supported DS which was cool in its own right). Locus was actually > contracted > to develop a UNIX subsystem for the AS/400 also, but I'm not sure if that > ever shipped. I had left Locus and had gone to DEC by then. > From dave at horsfall.org Sat Apr 3 11:50:20 2021 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 3 Apr 2021 12:50:20 +1100 (EST) Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: <20210402151650.GA8268@mcvoy.com> References: <20210401145025.GA1202@naleco.com> <202104020700.13270EDK018774@freefriends.org> <202104021026.132AQhs5014565@freefriends.org> <20210402140229.GD1202@naleco.com> <20210402151650.GA8268@mcvoy.com> Message-ID: On Fri, 2 Apr 2021, Larry McVoy wrote: > SunOS 4, though I love it more than most people, is ancient history and > is basically under one big lock for SMP. It was a huge amount of work > to get that code to scale in Solaris (they lifted the VM system and the > hat layer from SunOS 4 to 5 and then went to work). SunOS 4.1 was the best *ix I have ever used (and I've used lots over the decades); then Slowaris came along and trashed the joint because the suits were in charge instead of the real workers. We never had a need for SMP, so we didn't miss it. -- Dave From imp at bsdimp.com Sat Apr 3 11:55:29 2021 From: imp at bsdimp.com (Warner Losh) Date: Fri, 2 Apr 2021 19:55:29 -0600 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <20210401145025.GA1202@naleco.com> <202104020700.13270EDK018774@freefriends.org> <202104021026.132AQhs5014565@freefriends.org> <20210402140229.GD1202@naleco.com> <20210402151650.GA8268@mcvoy.com> Message-ID: On Fri, Apr 2, 2021, 7:51 PM Dave Horsfall wrote: > On Fri, 2 Apr 2021, Larry McVoy wrote: > > > SunOS 4, though I love it more than most people, is ancient history and > > is basically under one big lock for SMP. It was a huge amount of work > > to get that code to scale in Solaris (they lifted the VM system and the > > hat layer from SunOS 4 to 5 and then went to work). > > SunOS 4.1 was the best *ix I have ever used (and I've used lots over the > decades); then Slowaris came along and trashed the joint because the suits > were in charge instead of the real workers. > > We never had a need for SMP, so we didn't miss it. > OS/MP from Solbourne gave you both: SMP and SonOS 4.1.x. Warner > > -- Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Apr 3 12:23:59 2021 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 2 Apr 2021 19:23:59 -0700 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <20210401145025.GA1202@naleco.com> <202104020700.13270EDK018774@freefriends.org> <202104021026.132AQhs5014565@freefriends.org> <20210402140229.GD1202@naleco.com> <20210402151650.GA8268@mcvoy.com> Message-ID: <20210403022359.GN8268@mcvoy.com> On Sat, Apr 03, 2021 at 12:50:20PM +1100, Dave Horsfall wrote: > On Fri, 2 Apr 2021, Larry McVoy wrote: > > >SunOS 4, though I love it more than most people, is ancient history and is > >basically under one big lock for SMP. It was a huge amount of work to get > >that code to scale in Solaris (they lifted the VM system and the hat layer > >from SunOS 4 to 5 and then went to work). > > SunOS 4.1 was the best *ix I have ever used (and I've used lots over the > decades); then Slowaris came along and trashed the joint because the suits > were in charge instead of the real workers. A little known story is that Scooter did the deal with AT&T because Sun was in trouble financially. As I remember AT&T bought $200M of Sun stock at 35% over market but the price was we had to dump SunOS and go to SVr4. I worked for Ken Okin at the time, senior VP of all server hardware. Ken paid me to argue with the execs for 6 months to try and reverse this decision so Ken didn't know the details either. SunOS 4.x was the bees knees, it was the most well thought out Unix ever. I got there around 4.1 or just past 4.0 and I didn't know shit. They made me do POSIX conformance which made me go through every code path. Nothing, nothing, nothing, and one day it was like the fog cleared and I saw what they were trying to say. And it was pretty cool, SunOS 4.x was pretty object oriented without all the nonsense, just the good stuff. SunOS was the only Unix that just made sense, I could guess what the kernel would do and 90% of the time I guessed right. I miss it. That said, Sun never made that OS SMP. Real SMP. Warner says Solbourne did, I'd still like to, or get Dock Williams or Anil, to talk to the people that made the VM system scale. --lm From earl.baugh at gmail.com Sat Apr 3 12:34:52 2021 From: earl.baugh at gmail.com (Earl Baugh) Date: Fri, 2 Apr 2021 22:34:52 -0400 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: <20210403022359.GN8268@mcvoy.com> References: <20210403022359.GN8268@mcvoy.com> Message-ID: Just FYI - I have a Sun 3/110 that I still fire up. I’d be interested in the 4.X source ( I believe it still ran on it - I have 3.2 on it now ) to be able to patch a few things to keep it going. I’ve not looked for it, as I didn’t think it was readily available. Earl Sent from my iPhone > On Apr 2, 2021, at 10:25 PM, Larry McVoy wrote: > > On Sat, Apr 03, 2021 at 12:50:20PM +1100, Dave Horsfall wrote: >>> On Fri, 2 Apr 2021, Larry McVoy wrote: >>> >>> SunOS 4, though I love it more than most people, is ancient history and is >>> basically under one big lock for SMP. It was a huge amount of work to get >>> that code to scale in Solaris (they lifted the VM system and the hat layer >>> from SunOS 4 to 5 and then went to work). >> >> SunOS 4.1 was the best *ix I have ever used (and I've used lots over the >> decades); then Slowaris came along and trashed the joint because the suits >> were in charge instead of the real workers. > > A little known story is that Scooter did the deal with AT&T because Sun > was in trouble financially. As I remember AT&T bought $200M of Sun stock > at 35% over market but the price was we had to dump SunOS and go to SVr4. > > I worked for Ken Okin at the time, senior VP of all server hardware. > Ken paid me to argue with the execs for 6 months to try and reverse this > decision so Ken didn't know the details either. > > SunOS 4.x was the bees knees, it was the most well thought out Unix ever. > I got there around 4.1 or just past 4.0 and I didn't know shit. They made > me do POSIX conformance which made me go through every code path. Nothing, > nothing, nothing, and one day it was like the fog cleared and I saw what > they were trying to say. And it was pretty cool, SunOS 4.x was pretty > object oriented without all the nonsense, just the good stuff. SunOS was > the only Unix that just made sense, I could guess what the kernel would > do and 90% of the time I guessed right. I miss it. > > That said, Sun never made that OS SMP. Real SMP. Warner says Solbourne > did, I'd still like to, or get Dock Williams or Anil, to talk to the people > that made the VM system scale. > > --lm From cowan at ccil.org Sat Apr 3 13:10:08 2021 From: cowan at ccil.org (John Cowan) Date: Fri, 2 Apr 2021 23:10:08 -0400 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <20210401145025.GA1202@naleco.com> <202104020700.13270EDK018774@freefriends.org> <202104021026.132AQhs5014565@freefriends.org> <20210402140229.GD1202@naleco.com> Message-ID: On Fri, Apr 2, 2021 at 10:18 AM Steve Nickolas wrote: > On Fri, 2 Apr 2021, Josh Good wrote: > > > The source for ancient/research UNIX is out of the bag. An unclouded > licence > > to freely use it, that is quite another thing. If Caldera/TSG didn't own > the > > copyright for UNIX, and Novell did (and that has indeed been asserted by > a > > judge in court), then Caldera/TSG had no title to relicense that source. > > This was what I was pointing at, and why I used as many terms as I could > to make it unambiguous what I meant. > > A license to use code copyrighted by Caldera is meaningless if the code is > NOT copyrighted by Caldera, but by Novell (as has been established in a > court of law). Not so fast. What the court said was that Novell did not transfer the copyrights to Caldera *using a specific legal instrument at a specific time*. There is no judicial opinion saying either that Novell did, or Novell did not, transfer the copyright on some other occasion. So the Caldera license is clouded but not ipso facto void. (See .sig below) Remember also that in litigation a fact is any point on which both (or all) sides agree, and its factuality by ordinary standards is irrelevant. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org The first thing you learn in a lawin' family is that there ain't no definite answers to anything. --Calpurnia in To Kill A Mockingbird -------------- next part -------------- An HTML attachment was scrubbed... URL: From drsalists at gmail.com Sat Apr 3 16:16:08 2021 From: drsalists at gmail.com (Dan Stromberg) Date: Fri, 2 Apr 2021 23:16:08 -0700 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <20210401145025.GA1202@naleco.com> <202104020700.13270EDK018774@freefriends.org> <202104021026.132AQhs5014565@freefriends.org> <20210402140229.GD1202@naleco.com> <20210402151650.GA8268@mcvoy.com> Message-ID: On Fri, Apr 2, 2021 at 6:51 PM Dave Horsfall wrote: > On Fri, 2 Apr 2021, Larry McVoy wrote: > > > SunOS 4, though I love it more than most people, is ancient history and > > is basically under one big lock for SMP. It was a huge amount of work > > to get that code to scale in Solaris (they lifted the VM system and the > > hat layer from SunOS 4 to 5 and then went to work). > > SunOS 4.1 was the best *ix I have ever used (and I've used lots over the > decades); then Slowaris came along and trashed the joint because the suits > were in charge instead of the real workers. > This drives me bonkers. SunOS 5 was fine, and quickly became a big improvement over 4.1.x. I felt like Sun caught heck over the change because they were the last major vendor to make the switch from BSD to SysV, and all the BSD fans had moved to SunOS 4.1.x to get their BSD fix. Please see https://stromberg.dnsalias.org/~strombrg/why-solaris.html for a list of benefits of 5.5 over 4.1.x. That said, I have little inclination to run Solaris today. My computers all run Debian, Ubuntu or Mint, though I do have a Windows Virtual Machine, and a Haiku Virtual Machine too. I'm slowly migrating most of my machines to running Debian. We never had a need for SMP, so we didn't miss it. > Sun really needed SMP, because their CPU's were slower than they used to be compared to other vendors, but they could get parallel performance numbers that weren't horrible. -------------- next part -------------- An HTML attachment was scrubbed... URL: From davida at pobox.com Sun Apr 4 11:48:57 2021 From: davida at pobox.com (David Arnold) Date: Sun, 4 Apr 2021 11:48:57 +1000 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: Message-ID: <584DED5A-1226-4AF7-A191-C34CAFA53686@pobox.com> > On 3 Apr 2021, at 12:51, Dave Horsfall wrote: ... > SunOS 4.1 was the best *ix I have ever used (and I've used lots over the decades); I used to tell people the same thing: my memory of it was very positive. And then I booted up my 4.1.1 tape on my 3/260 and .. it was very ordinary. The headers were missing a bunch of declarations, the tools didn’t have a lot of the options I’ve since come to rely on: it felt half-done and oddly amateurish compared to a recent Linux or BSD. I was surprised. I tried Ultrix 4.4, Irix 5.3, and NeXT 3.3 (which I had more or less at hand) and they were all pretty awful. The world has moved on, and my bar is a lot higher now. I don’t doubt SunOS was great at the time but it’s absolutely obsolete now. d From lm at mcvoy.com Sun Apr 4 12:23:56 2021 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 3 Apr 2021 19:23:56 -0700 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: <584DED5A-1226-4AF7-A191-C34CAFA53686@pobox.com> References: <584DED5A-1226-4AF7-A191-C34CAFA53686@pobox.com> Message-ID: <20210404022356.GR28660@mcvoy.com> On Sun, Apr 04, 2021 at 11:48:57AM +1000, David Arnold wrote: > > > On 3 Apr 2021, at 12:51, Dave Horsfall wrote: > > ... > > > SunOS 4.1 was the best *ix I have ever used (and I've used lots over the decades); > > I used to tell people the same thing: my memory of it was very positive. And then I booted up my 4.1.1 tape on my 3/260 and .. it was very ordinary. > > The headers were missing a bunch of declarations, the tools didn???t have a lot of the options I???ve since come to rely on: it felt half-done and oddly amateurish compared to a recent Linux or BSD. > > I was surprised. I tried Ultrix 4.4, Irix 5.3, and NeXT 3.3 (which I had more or less at hand) and they were all pretty awful. > > The world has moved on, and my bar is a lot higher now. I don???t doubt SunOS was great at the time but it???s absolutely obsolete now. I'm the biggest SunOS 4.x fan boy and I agree. It was ~30 years ago. Back then, all the open source stuff, or closed source stuff, took a ton of work to make it work. It just worked on SunOS. I can't tell you how many times I've brought up X10 or X11 on all sorts of systems (it was a good learning experience, you learned to figure out that this is part of my graphics card, this and that and that and that is not, just ifdef that out and keep going). At the time, SunOS 4.x was what everyone wanted. Because Sun (me included) was doing everything they could do to make that the best dev system ever. I get that it is nothing now but back then, you wanted a Sun machine because everything just worked. And it was fun. SunOS was fun, maybe I'm a nut but there are OS that are fun and then there are OS that are not fun. VMS. Not fun. The IBM stuff, not fun. A lot of vendor Unix, not fun. SunOS 4.x was fun, it was just great. I get that it is old but at the time, it was way more fun than what other vendors had. Way more fun. I did lint libraries for SunOS, BSD, the various SysV, I had a huge arguement with Rob Gingell (he was the god at that time, I lived in fear of pissing Rob off), I wanted to ship those lint libraries, he pushed back because it was 40Kb more in the install image. I pushed for it because I wanted SunOS to be the dev platform even if you were developing for a different platform. I had to threaten to quit and Rob shipped them. That was me being stupid, we shipped those lint libraries but I don't think anyone used them. Whatever, that's a little taste of the passion that was there. I'm retired, did a bunch of stuff, changed the world in a few ways, all these years later, the best part of my career was at Sun. Sun was the Bell Labs of my generation. From athornton at gmail.com Sun Apr 4 12:46:54 2021 From: athornton at gmail.com (Adam Thornton) Date: Sat, 3 Apr 2021 19:46:54 -0700 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <20210401145025.GA1202@naleco.com> Message-ID: On Thu, Apr 1, 2021 at 8:54 PM Wesley Parish wrote: > So from IBM's POV, they could > support Linux - which by then had already been ported to the VM/370 > and there was already talk of porting it to the later mainframe > iterations. I don't think anybody was even thinking of porting any of > the *BSD to IBM mainframes till much later, am I right? > This is not how I remember it going down. There was an external-to-IBM "Bigfoot" port to S/390 (not S/370) that IBM was ignoring until it got alarmingly close to booting, and then all of a sudden there was an IBM port to S/390. Clearly (well, *I* thought it was clear) they'd had a skunkworks project for some time and Bigfoot forced their hand. (Unix v7 *did* run on S/370, and resurrecting that is one of my hobby projects that hasn't really gotten off the ground). I was the system administrator of the first publicly-accessible Linux-on-S/390 machine--penguinvm.princeton.edu--and indeed in the late 90s I and my mentor David Boyes met with some pretty high-level people at IBM to advise them how we thought they should proceed. They seemed to take much of our advice, but then again I don't think we said anything very crazy. (At the time, and for years thereafter, I was with Sine Nomine Associates. They're still around.) I also later managed the port of OpenSolaris to zSeries, which, if IBM had bought Sun rather than Oracle, would have made my life very different. Neale Ferguson did most of the heavy lifting on that port, but I did a lot of the tool porting and wrote a disk driver. Alas, IBM tightened the screws a little too far and apparently didn't know that Sun had an offer from Oracle in its back pocket. But back to the S/390 port--I went to a Linux conference in Atlanta in the late 90s ('99, I think) to speak about Linux on S390/Z, and I actually went by the NetBSD booth to say, "hey, I can maybe hook you guys up with a development virtual machine," and what I got was an earful about "your so-called portability" from someone who was clearly much more invested in hating Linux than in, you know, saying, "wow, OK, I realize you're not offering me cycles on a super-awesome machine, but, yeah, it's not nothing, cool, here's who you should talk to if you're interested in getting a port going." So I don't think you can lay all the blame on BSD inaction on Linux, is all I'm saying. By '99, I think it was, maybe if NetBSD, which already had its reputation for spectacular portability, hadn't staffed its booth with a jackass still trying to fight the Unix Wars, that story might have turned out differently. Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Sun Apr 4 12:50:51 2021 From: athornton at gmail.com (Adam Thornton) Date: Sat, 3 Apr 2021 19:50:51 -0700 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <20210401145025.GA1202@naleco.com> Message-ID: Misremembered the year. That conference was October 2000. I just found the bookbag I got as swag from it. On Sat, Apr 3, 2021 at 7:46 PM Adam Thornton wrote: > > > On Thu, Apr 1, 2021 at 8:54 PM Wesley Parish wrote: > >> So from IBM's POV, they could >> support Linux - which by then had already been ported to the VM/370 >> and there was already talk of porting it to the later mainframe >> iterations. I don't think anybody was even thinking of porting any of >> the *BSD to IBM mainframes till much later, am I right? >> > > This is not how I remember it going down. > > There was an external-to-IBM "Bigfoot" port to S/390 (not S/370) that IBM > was ignoring until it got alarmingly close to booting, and then all of a > sudden there was an IBM port to S/390. Clearly (well, *I* thought it was > clear) they'd had a skunkworks project for some time and Bigfoot forced > their hand. (Unix v7 *did* run on S/370, and resurrecting that is one of > my hobby projects that hasn't really gotten off the ground). > > I was the system administrator of the first publicly-accessible > Linux-on-S/390 machine--penguinvm.princeton.edu--and indeed in the late 90s > I and my mentor David Boyes met with some pretty high-level people at IBM > to advise them how we thought they should proceed. They seemed to take > much of our advice, but then again I don't think we said anything very > crazy. (At the time, and for years thereafter, I was with Sine Nomine > Associates. They're still around.) > > I also later managed the port of OpenSolaris to zSeries, which, if IBM had > bought Sun rather than Oracle, would have made my life very different. > Neale Ferguson did most of the heavy lifting on that port, but I did a lot > of the tool porting and wrote a disk driver. Alas, IBM tightened the > screws a little too far and apparently didn't know that Sun had an offer > from Oracle in its back pocket. > > But back to the S/390 port--I went to a Linux conference in Atlanta in the > late 90s ('99, I think) to speak about Linux on S390/Z, and I actually went > by the NetBSD booth to say, "hey, I can maybe hook you guys up with a > development virtual machine," and what I got was an earful about "your > so-called portability" from someone who was clearly much more invested in > hating Linux than in, you know, saying, "wow, OK, I realize you're not > offering me cycles on a super-awesome machine, but, yeah, it's not nothing, > cool, here's who you should talk to if you're interested in getting a port > going." > > So I don't think you can lay all the blame on BSD inaction on Linux, is > all I'm saying. By '99, I think it was, maybe if NetBSD, which already had > its reputation for spectacular portability, hadn't staffed its booth with a > jackass still trying to fight the Unix Wars, that story might have turned > out differently. > > Adam > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gregg.drwho8 at gmail.com Sun Apr 4 13:41:47 2021 From: gregg.drwho8 at gmail.com (Gregg Levine) Date: Sat, 3 Apr 2021 23:41:47 -0400 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <20210401145025.GA1202@naleco.com> Message-ID: Hello! Adam? Seriously? That was the case when I visited them at one year's LinuxWorld. (I think it was the one when we met.) And yes at the System Z Council meetings I would catch up with them. Larry? It is funny, but earlier on I did mention all of that in a completely different thread. But why would the characters at what was SCO start this stupidity all over again? I seem to be missing something. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Sat, Apr 3, 2021 at 10:48 PM Adam Thornton wrote: > > > > On Thu, Apr 1, 2021 at 8:54 PM Wesley Parish wrote: >> >> So from IBM's POV, they could >> support Linux - which by then had already been ported to the VM/370 >> and there was already talk of porting it to the later mainframe >> iterations. I don't think anybody was even thinking of porting any of >> the *BSD to IBM mainframes till much later, am I right? > > > This is not how I remember it going down. > > There was an external-to-IBM "Bigfoot" port to S/390 (not S/370) that IBM was ignoring until it got alarmingly close to booting, and then all of a sudden there was an IBM port to S/390. Clearly (well, *I* thought it was clear) they'd had a skunkworks project for some time and Bigfoot forced their hand. (Unix v7 *did* run on S/370, and resurrecting that is one of my hobby projects that hasn't really gotten off the ground). > > I was the system administrator of the first publicly-accessible Linux-on-S/390 machine--penguinvm.princeton.edu--and indeed in the late 90s I and my mentor David Boyes met with some pretty high-level people at IBM to advise them how we thought they should proceed. They seemed to take much of our advice, but then again I don't think we said anything very crazy. (At the time, and for years thereafter, I was with Sine Nomine Associates. They're still around.) > > I also later managed the port of OpenSolaris to zSeries, which, if IBM had bought Sun rather than Oracle, would have made my life very different. Neale Ferguson did most of the heavy lifting on that port, but I did a lot of the tool porting and wrote a disk driver. Alas, IBM tightened the screws a little too far and apparently didn't know that Sun had an offer from Oracle in its back pocket. > > But back to the S/390 port--I went to a Linux conference in Atlanta in the late 90s ('99, I think) to speak about Linux on S390/Z, and I actually went by the NetBSD booth to say, "hey, I can maybe hook you guys up with a development virtual machine," and what I got was an earful about "your so-called portability" from someone who was clearly much more invested in hating Linux than in, you know, saying, "wow, OK, I realize you're not offering me cycles on a super-awesome machine, but, yeah, it's not nothing, cool, here's who you should talk to if you're interested in getting a port going." > > So I don't think you can lay all the blame on BSD inaction on Linux, is all I'm saying. By '99, I think it was, maybe if NetBSD, which already had its reputation for spectacular portability, hadn't staffed its booth with a jackass still trying to fight the Unix Wars, that story might have turned out differently. > > Adam From athornton at gmail.com Sun Apr 4 13:57:05 2021 From: athornton at gmail.com (Adam Thornton) Date: Sat, 3 Apr 2021 20:57:05 -0700 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <20210401145025.GA1202@naleco.com> Message-ID: It’s possible I am conflating two conferences in my head and the NetBSD thing was NYC not Atlanta. On Sat, Apr 3, 2021 at 8:42 PM Gregg Levine wrote: > Hello! > Adam? Seriously? That was the case when I visited them at one year's > LinuxWorld. (I think it was the one when we met.) And yes at the > System Z Council meetings I would catch up with them. > > Larry? It is funny, but earlier on I did mention all of that in a > completely different thread. > > But why would the characters at what was SCO start this > stupidity all over again? I seem to be missing something. > ----- > Gregg C Levine gregg.drwho8 at gmail.com > "This signature fought the Time Wars, time and again." > > On Sat, Apr 3, 2021 at 10:48 PM Adam Thornton wrote: > > > > > > > > On Thu, Apr 1, 2021 at 8:54 PM Wesley Parish > wrote: > >> > >> So from IBM's POV, they could > >> support Linux - which by then had already been ported to the VM/370 > >> and there was already talk of porting it to the later mainframe > >> iterations. I don't think anybody was even thinking of porting any of > >> the *BSD to IBM mainframes till much later, am I right? > > > > > > This is not how I remember it going down. > > > > There was an external-to-IBM "Bigfoot" port to S/390 (not S/370) that > IBM was ignoring until it got alarmingly close to booting, and then all of > a sudden there was an IBM port to S/390. Clearly (well, *I* thought it was > clear) they'd had a skunkworks project for some time and Bigfoot forced > their hand. (Unix v7 *did* run on S/370, and resurrecting that is one of > my hobby projects that hasn't really gotten off the ground). > > > > I was the system administrator of the first publicly-accessible > Linux-on-S/390 machine--penguinvm.princeton.edu--and indeed in the late 90s > I and my mentor David Boyes met with some pretty high-level people at IBM > to advise them how we thought they should proceed. They seemed to take > much of our advice, but then again I don't think we said anything very > crazy. (At the time, and for years thereafter, I was with Sine Nomine > Associates. They're still around.) > > > > I also later managed the port of OpenSolaris to zSeries, which, if IBM > had bought Sun rather than Oracle, would have made my life very different. > Neale Ferguson did most of the heavy lifting on that port, but I did a lot > of the tool porting and wrote a disk driver. Alas, IBM tightened the > screws a little too far and apparently didn't know that Sun had an offer > from Oracle in its back pocket. > > > > But back to the S/390 port--I went to a Linux conference in Atlanta in > the late 90s ('99, I think) to speak about Linux on S390/Z, and I actually > went by the NetBSD booth to say, "hey, I can maybe hook you guys up with a > development virtual machine," and what I got was an earful about "your > so-called portability" from someone who was clearly much more invested in > hating Linux than in, you know, saying, "wow, OK, I realize you're not > offering me cycles on a super-awesome machine, but, yeah, it's not nothing, > cool, here's who you should talk to if you're interested in getting a port > going." > > > > So I don't think you can lay all the blame on BSD inaction on Linux, is > all I'm saying. By '99, I think it was, maybe if NetBSD, which already had > its reputation for spectacular portability, hadn't staffed its booth with a > jackass still trying to fight the Unix Wars, that story might have turned > out differently. > > > > Adam > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.branden.robinson at gmail.com Sun Apr 4 15:29:41 2021 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sun, 4 Apr 2021 15:29:41 +1000 Subject: [TUHS] How to Kill a Technical Conference (was: Zombified SCO comes back from the dead, brings trial back to life against IBM) In-Reply-To: References: <20210401145025.GA1202@naleco.com> Message-ID: <20210404052939.xivuinlcugqb5zde@localhost.localdomain> At 2021-04-03T19:50:51-0700, Adam Thornton wrote: > > But back to the S/390 port--I went to a Linux conference in Atlanta > > in the late 90s ('99, I think) to speak about Linux on S390/Z, and I > > actually went by the NetBSD booth to say, "hey, I can maybe hook you > > guys up with a development virtual machine," and what I got was an > > earful about "your so-called portability" from someone who was > > clearly much more invested in hating Linux than in, you know, > > saying, "wow, OK, I realize you're not offering me cycles on a > > super-awesome machine, but, yeah, it's not nothing, cool, here's who > > you should talk to if you're interested in getting a port going." > > > > So I don't think you can lay all the blame on BSD inaction on Linux, > > is all I'm saying. By '99, I think it was, maybe if NetBSD, which > > already had its reputation for spectacular portability, hadn't > > staffed its booth with a jackass still trying to fight the Unix > > Wars, that story might have turned out differently. > > Misremembered the year. That conference was October 2000. I just > found the bookbag I got as swag from it. I think you're remembering the Atlanta Linux Showcase. I was at the same event. I also think I know exactly the person you're talking about: Charles Hannum, with whom I had a similar experience on a different topic. Instead of insisting that I was stupid and wrong for using Linux instead of (NetBSD) in his view, I was stupid and wrong for using software licensed under the GNU GPL instead of the "BSD" license (which variant of the latter is not, all these years later, a matter I recall coming up). I mention this so that Mr. Hannum's reputation on this list risks no blackening among those who share his hostility to copyleft. ;-) ALS was a terrific experience and, for me, lived up to the praise I had heard about it as a venue for getting engineers talking to each other. Regrettably enough, the conference was acquired by a firm. It was held one final time the next year in Atlanta, officially rebranded the "Annual Linux Showcase", and, as I recall, permanently mothballed thereafter, with the dot-com bubble-burst as either a direct reason or as an excuse. I have seen other technical conferences over the years steadily morph from a technical/engineering focus to an orientation around sales and "strategy", or more bluntly--propaganda. The emphasis is no longer on technological improvement and evaluation (i.e., how to achieve and measure "solutions"), but on promotion, rationalization, and boosterism. I suppose that one of the reasons this happens is that good conferences grow, and companies sending delegations find themselves with growing expense bills for doing so. Engineers are a cost center. When they come back from the event, they will almost never have anything to "show for it". At best they'll be excited about something they can "integrate" or some new idea they can realize after months of development time. In other words, you _might_ have a competitive advantage after spending _even more_ money. By contrast, sales people can bring you orders you can book the day they get back, or even before the conference is over, thanks to the magic power of accrual accounting, a practice which persists even after the glorious examples of Enron and other gigantic bankruptcies of the 2000s. That's the demand side. On the supply side, conferences have governance; it takes people to solicit papers, book speakers, and put talks on the schedule and into proceedings. Conference sponsorship is a neat way of closing the gap between demand and supply on the back end; be a "gold" or "platinum" level sponsor and obtain influence, likely through direct seating of representatives on the committees that perform the foregoing organizational roles. Note the entrenchment and persistence of precious metals as metaphors for status; we would not name the tiers after the decreasing scale of photolithographic processes, for example. Historically, it's been a lot easier to motivate a guy with a checkbook in the C suite who drives a Lamborghini Gallardo with the word "platinum" than "5 nm". I'm too young to know--did USENIX follow the trajectory of reorienting its focus from engineering and research to sales? Why does it no longer occupy the premier place it once did? 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 pepe at naleco.com Sun Apr 4 18:55:22 2021 From: pepe at naleco.com (Josh Good) Date: Sun, 4 Apr 2021 10:55:22 +0200 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: <20210404022356.GR28660@mcvoy.com> References: <584DED5A-1226-4AF7-A191-C34CAFA53686@pobox.com> <20210404022356.GR28660@mcvoy.com> Message-ID: <20210404085520.GA6494@naleco.com> On 2021 Apr 3, 19:23, Larry McVoy wrote: > all these years later, the best part of my career was at Sun. Sun > was the Bell Labs of my generation. Yes, it looks like in those years inferior Unix vendors were playing a game of lock-in with their customers, while Sun was playing the opposite game: attracting users and developers with features, openness and by providing a more joyful user/developer experience. Those who could, used Sun kit. Those not so fortunate, aspired to use it. -- Josh Good From mparson at bl.org Mon Apr 5 00:43:39 2021 From: mparson at bl.org (Michael Parson) Date: Sun, 04 Apr 2021 09:43:39 -0500 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: <20210404085520.GA6494@naleco.com> References: <584DED5A-1226-4AF7-A191-C34CAFA53686@pobox.com> <20210404022356.GR28660@mcvoy.com> <20210404085520.GA6494@naleco.com> Message-ID: <5c112faf03e4a6ed4f642e11be829118@bl.org> On 2021-04-04 03:55, Josh Good wrote: > On 2021 Apr 3, 19:23, Larry McVoy wrote: > >> all these years later, the best part of my career was at Sun. Sun >> was the Bell Labs of my generation. > > Yes, it looks like in those years inferior Unix vendors were playing a > game > of lock-in with their customers, while Sun was playing the opposite > game: > attracting users and developers with features, openness and by > providing a > more joyful user/developer experience. > > Those who could, used Sun kit. Those not so fortunate, aspired to use > it. In 1993, when we spun up our first Linux box, we named it 'mercury', since it was the closest to a Sun we were going to get at our little community college. It was a re-purposed Novell server, a 486DX-50, 32 MB RAM and 1 Gig HD, pretty beefy system for the time, and the CS dept was ecstatic that they now had access to a Unix-like system in addition to the VAX/VMS that they'd been using up until then. -- Michael Parson Pflugerville, TX KF5LGQ From imp at bsdimp.com Mon Apr 5 01:36:12 2021 From: imp at bsdimp.com (Warner Losh) Date: Sun, 4 Apr 2021 09:36:12 -0600 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: <20210404085520.GA6494@naleco.com> References: <584DED5A-1226-4AF7-A191-C34CAFA53686@pobox.com> <20210404022356.GR28660@mcvoy.com> <20210404085520.GA6494@naleco.com> Message-ID: On Sun, Apr 4, 2021, 2:57 AM Josh Good wrote: > On 2021 Apr 3, 19:23, Larry McVoy wrote: > > > all these years later, the best part of my career was at Sun. Sun > > was the Bell Labs of my generation. > > Yes, it looks like in those years inferior Unix vendors were playing a game > of lock-in with their customers, while Sun was playing the opposite game: > attracting users and developers with features, openness and by providing a > more joyful user/developer experience. > > Those who could, used Sun kit. Those not so fortunate, aspired to use it. > A lot of the early open source used to recreate the SunOS commands and args. It's what people were used to. Docs were also accessible in a way that POSIX wouldn't be for a decade .. after that, it grew from there and SunOS started to feel dated. Warner -- > Josh Good > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Mon Apr 5 02:15:32 2021 From: clemc at ccc.com (Clem Cole) Date: Sun, 4 Apr 2021 12:15:32 -0400 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <584DED5A-1226-4AF7-A191-C34CAFA53686@pobox.com> <20210404022356.GR28660@mcvoy.com> <20210404085520.GA6494@naleco.com> Message-ID: At the risk of belaboring a point, that in heart I want us to move to a different topic and not fight yet another way of who had the best or who is in the lead, etc... I would like to see the forum, try to stick to what happened and what we all can learn from those experiences. On Sun, Apr 4, 2021 at 11:37 AM Warner Losh wrote: > > A lot of the early open source used to recreate the SunOS commands and > args. It's what people were used to. Docs were also accessible in a way > that POSIX wouldn't be for a decade .. after that, it grew from there and > SunOS started to feel dated. > It was even more than that. SunOS has some extensions (thread in particular) that pre-dated pthreads. A number of us had built pthreads packages because of Posix, but found ourselves building threading packages in the key of SunOS and later Solaris - why because the ISV's were using Sun's threading scheme. The "why" is simple --- ISV capture for your target was (and still is) the most important driver of selling new platforms. The better job you do in making it easy for someone that has an application, the more attractive your target becomes. Ted sometimes has mentioned the other "Golden rule" about "he who has the gold." As the creator/supplier, it is hard to be magnanimous when you are ahead and it is often difficult to acknowledge real reason >>why<< you are ahead. Plus the people on the other side of the tech delivery (the users), are more driven by basic economics - what is the most cost-effective way to get your job done [* i.e. *this is a classic Christensen disruption]. IBM lost the Research/Universities to DEC which started out being very open and easy to work with and extremely cost-effective. As more $s piled in the market, DEC started to be more and more protective (and moved more and more upscale). To many at the time, DEC compared to IBM (Mainframe S/360 vs. PDP-6/9/10) again -- worse technology, but 'good enough' (and a new growing customer base). The Unix Workstations come out - again 68K vs. Vax (story repeats). Sun eventually taking the lead from DEC. As Larry points out, Sun certainly started being extremely friendly to the same group -- again cost-effective and leading tech. Sun went upscale and the Intel/Microsoft alliance was good enough to a lot of people. I supposed there is the pride of owner/developer-ship; but to me, but the whole Linux vs. BSD (or SunOS or MacOS for that matter) is a silly argument (and wish people would get over it/themselves). *Linux (particularly on INTEL*64) is the current (popular) and cost-effective implementation of Ken, Dennis, Doug, et al. ideas. * No more, no less. Thank goodness it is cost-effective and accessible to all of us and available for us to use to do what we need and want to do. But let's stand on each other's shoulders, not step on toes for some injustice (believed or truly real). *A lot of us and in a number of different places go us to where we are today.* For us UNIX historians, we need to be careful and learn from our own history here -- the Cell Phone/Mobile target is the engine for the next Christenian style disruption. It is by far the #1 target for people writing new programs (which I find a little sad personally - but I understand and accept -- time has marched on). In the end, a small mobile target will be the tech on top, and available will be driven by market behavior and those suppliers will be "who has the gold." -------------- next part -------------- An HTML attachment was scrubbed... URL: From dot at dotat.at Mon Apr 5 02:18:16 2021 From: dot at dotat.at (Tony Finch) Date: Sun, 4 Apr 2021 17:18:16 +0100 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <20210401145025.GA1202@naleco.com> <202104020700.13270EDK018774@freefriends.org> <202104021026.132AQhs5014565@freefriends.org> <20210402140229.GD1202@naleco.com> <20210402151650.GA8268@mcvoy.com> Message-ID: <3c7d43cd-3f3d-bbcc-ea93-f27289935d5c@dotat.at> Dan Stromberg wrote: > > Please see https://stromberg.dnsalias.org/~strombrg/why-solaris.html for a > list of benefits of 5.5 over 4.1.x. A few of those are distinctly mixed blessings :-) I learned about Solaris's in-kernel telnet the hard way, trying to debug a system on which telnet would not work properly after rebooting. I think I worked it out by trussing telnetd, which showed me that it was trying to load a kernel module, and failing because we had chrooted it. A bit of searching around told me what the module was for. The Solaris automounter was neat - we did clever things with the userland part, and it mostly performed well because the fast path was in the kernel. Except that it didn't have a cache for ENOENT directory entries, so requests for nonexistent paths always took a trip to userland, and (as far as I could tell) these requests were serialized, and if you managed to overload the automounter it would start returning bogus errors - I think it was EPERM. Our Apache httpd started randomly returning 403 errors when it tried to access a missing .htaccess (which it did on every request!) and got EPERM instead. The name service cache was also problematic. It was probably useful for getpwnam() etc. on systems using NIS, but it behaved very badly on systems that sent a lot of DNS queries through nscd. It worked much better for us if we simply prevented it from running at all. And I'm not entirely sure it was all that great for NIS: another problem I heard of second hand was password files getting truncated when lots of users were trying to change their passwords at the same time. My colleagues fixed that by ensuring all password changes happened on the NIS master with suitable locking, and the password files were periodically replicated with rdist instead of using more normal NIS machinery. Tony. -- f.anthony.n.finch https://dotat.at/ Shetland Isles: West 7 or gale 8, veering northwest gale 8 or severe gale 9, occasionally storm 10 later. Moderate or rough, becoming very rough in sheltered east, otherwise very rough becoming high or very high. Rain then squally snow showers. Moderate or poor, occasionally good. From clemc at ccc.com Mon Apr 5 04:22:22 2021 From: clemc at ccc.com (Clem Cole) Date: Sun, 4 Apr 2021 14:22:22 -0400 Subject: [TUHS] How to Kill a Technical Conference (was: Zombified SCO comes back from the dead, brings trial back to life against IBM) In-Reply-To: <20210404052939.xivuinlcugqb5zde@localhost.localdomain> References: <20210401145025.GA1202@naleco.com> <20210404052939.xivuinlcugqb5zde@localhost.localdomain> Message-ID: Note: These are my opinions/experiences not necessarily those of the association or my employer. And, yes, I am a former BOD member as well as ex-President of same, as are a number of folks on this list. On Sun, Apr 4, 2021 at 1:30 AM G. Branden Robinson < g.branden.robinson at gmail.com> wrote: > > I'm too young to know--did USENIX follow the trajectory of reorienting > its focus from engineering and research to sales? Actually, quite the opposite, USENIX was getting more and more academic and research-oriented and less 'trade show.' The key is that USENIX and ALS should have been an excellent match, unfortunately, some of the personalities involved were at odds with each other. IMO: it was more of a crash of personalities/control issues - the details do not need to be repeated or aired again. Note: I was on the BOD at that time and in fact on the PC for that specific conference. Ted may have been on the BOD at the same time. > Why does it no longer occupy the premier place it once did? > As they say on Quora, "*never ask a question based on a false premise*." Sadly, this is a false statement. USENIX is extremely well respected in the systems research and security community in particular. And even during these Covid times has continued to have some of the premier conferences on the same; al biet virtual (more in a minute). An issue during the time you are discussing, USENIX had evolved into "two foci" between the practitioners (which included both FOSS community and LISA types) and the more academic-oriented folks looking for respected places to publish papers/develop their tenure files. USENIX had moved from its earlier (anything goes) - pure practitioner origins - which were also researchers, so at a meeting in a classroom at NYU, you told people you had something to say and came and did it, to a more structured (research) approach with program committees, submitted papers, and vetting and a hotel. Along the way, because it had both types of people and these were the folks that influenced the buying patterns, vendors started to show up to show off what they had. At the time of the ALS conference you mentioned, the things happening in the FOSS community - was much more like the origins of USENIX. What had for years separated USENIX from IEEE/ACM was it was where the two foci were really a single one, and thus had been together and actually considered what was potential as well as practical. In fact, USENIX was noted as the place where some of the most influential papers of the time had shown (numerous storage papers including Rusty's NFS and my EFS paper in the same session, just about any important security papers, numerous other system papers -- I could go a few pages here). Part of the issue was ACM's SOSP was every 2 years and there was too much good stuff going on in the system world (BTW - USENIX eventually created OSDI on alternate years because ACM was just going to do it). But USENIX also published less formal papers. In fact, one of my all-time favorite practitioner papers is from another member of this list -- Tom Lyon's "*All the Chips that Fit*" from the 1985 Summer USENIX [which if you have never read, send me an email, offline and I'll send you a scanned PDF -- note to Tom if you still have the original bits I bet USENIX would like them]. I suspect that such a paper would never have been acceptable in any of the IEEE or ACM conferences. Also unlike ACM/IEEE (and frankly the thing that happen at USENIX when I was President that I am most proud of) is that they do not have a paywall. Anything they published from the time when all proceedings were electronic is available and slowly some of the older papers are being scanned or reprinted from the source - as needed/possible. As much as possible, all of USENIX's papers are available to anyone [which was a huge thing to do - as it cut down a lot of revenue for them -- a paywall for papers is one of the things other associations use]. A number of good things happened at the time you mentioned, as well as some bad. Knowing the parties involved both today and at that time, if today's BOD and Executive Director was given the same choices that they had at the time of the action, I suspect we might have had a different outcome. IMO to the demise of FREENIX and ALS were two of the not-so-good choices that were made, but I understand why those conferences did go away at that point in history. If it makes you feel any better, as a former PC Chair for a couple of FREENIX (which was caught with the same bullet), and as I said a member of the PC of ALS, I was very sad to see that happen and I personally fought against it. But, I was on the losing side of that argument. Unfortunately, that ship sailed, and reviving them is unlikely to be possible although I believe it has been discussed a number of times since I left the BOD. Back to your point, USENIX may have stopped being as important to many practitioners, particularly ones in the FOSS community. Which I do find sad, but I understand the issues on both sides and why that might be so. For instance, Keith Packard of X11 fame, Steinhart, and I were all talking about "whence USENIX" at a Hackers conferences a few years back. So, if you come from that side of the world, you may not value membership or the results (BTW: my own now hacker daughter, who is a Googler, dropped her membership last year as she felt it was of less value to her); but so far USENIX has continued to be important to a large part of the research community and a set of some practitioners. That said, I also believe in 2021, that the USENIX BOD and their ED is struggling with a financial model that works for them when they do not have the conference revenue as they had before CV-19. I hope for their sake, the current treading water situation can find a way to bring them back to what they were pre-CV-19 because the conferences they traditionally have held, are excellent (premier in your words) and I would hate to see that really go away because they have had a lot of value and so far have continued to provide it. Respectfully -- my 2 cents. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From lyndon at orthanc.ca Mon Apr 5 06:08:45 2021 From: lyndon at orthanc.ca (Lyndon Nerenberg (VE7TFX/VE6BBM)) Date: Sun, 04 Apr 2021 13:08:45 -0700 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: <20210404085520.GA6494@naleco.com> References: <584DED5A-1226-4AF7-A191-C34CAFA53686@pobox.com> <20210404022356.GR28660@mcvoy.com> <20210404085520.GA6494@naleco.com> Message-ID: Josh Good writes: > Yes, it looks like in those years inferior Unix vendors were playing a game > of lock-in with their customers, while Sun was playing the opposite game: > attracting users and developers with features, openness and by providing a > more joyful user/developer experience. Yes, but weren't they also the first to unbundle the C compiler? Until that point Sun had been doing a good job of elbowing out DEC where I was working. When the C compiler went away we damned near mutinied to become a wall-to-wall Ultrix shop (on the BSD side). Personally, I think Sun's unbundling of C did more to launch the GNU project into the mainstream than anything. Once gcc and binutils became defacto on SunOS systems, GNU's future was set. --lyndon From rich.salz at gmail.com Mon Apr 5 06:54:29 2021 From: rich.salz at gmail.com (Richard Salz) Date: Sun, 4 Apr 2021 16:54:29 -0400 Subject: [TUHS] How to Kill a Technical Conference (was: Zombified SCO comes back from the dead, brings trial back to life against IBM) In-Reply-To: References: <20210401145025.GA1202@naleco.com> <20210404052939.xivuinlcugqb5zde@localhost.localdomain> Message-ID: Clem's note is great, and accurate, of course. (I used to be proud of my membership number, I2048 :) I think he understates how influential Usenix's "open access" policy is has been (e.g., the Univ of California system requiring open access). In my field, Usenix is still the premier set of conferences for security and privacy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Mon Apr 5 07:00:49 2021 From: jon at fourwinds.com (Jon Steinhart) Date: Sun, 04 Apr 2021 14:00:49 -0700 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <584DED5A-1226-4AF7-A191-C34CAFA53686@pobox.com> <20210404022356.GR28660@mcvoy.com> <20210404085520.GA6494@naleco.com> Message-ID: <202104042100.134L0nTg086762@darkstar.fourwinds.com> Lyndon Nerenberg (VE7TFX/VE6BBM) writes: > Josh Good writes: > > more joyful user/developer experience. Joy-ful? > Yes, but weren't they also the first to unbundle the C compiler? Until Yes, that really sucked but that wasn't until Solaris. From clemc at ccc.com Mon Apr 5 07:11:00 2021 From: clemc at ccc.com (Clem Cole) Date: Sun, 4 Apr 2021 17:11:00 -0400 Subject: [TUHS] How to Kill a Technical Conference (was: Zombified SCO comes back from the dead, brings trial back to life against IBM) In-Reply-To: References: <20210401145025.GA1202@naleco.com> <20210404052939.xivuinlcugqb5zde@localhost.localdomain> Message-ID: typo: OSDI on alternate years because ACM was just not going to do it On Sun, Apr 4, 2021 at 2:22 PM Clem Cole wrote: > Note: These are my opinions/experiences not necessarily those of the > association or my employer. And, yes, I am a former BOD member as well as > ex-President of same, as are a number of folks on this list. > > On Sun, Apr 4, 2021 at 1:30 AM G. Branden Robinson < > g.branden.robinson at gmail.com> wrote: > >> >> I'm too young to know--did USENIX follow the trajectory of reorienting >> its focus from engineering and research to sales? > > Actually, quite the opposite, USENIX was getting more and more academic > and research-oriented and less 'trade show.' The key is that USENIX and > ALS should have been an excellent match, unfortunately, some of the > personalities involved were at odds with each other. IMO: it was more of a > crash of personalities/control issues - the details do not need to be > repeated or aired again. Note: I was on the BOD at that time and in fact on > the PC for that specific conference. Ted may have been on the BOD at the > same time. > > > > > >> Why does it no longer occupy the premier place it once did? >> > As they say on Quora, "*never ask a question based on a false premise*." > Sadly, this is a false statement. > > USENIX is extremely well respected in the systems research and security > community in particular. And even during these Covid times has continued > to have some of the premier conferences on the same; al biet virtual (more > in a minute). An issue during the time you are discussing, USENIX had > evolved into "two foci" between the practitioners (which included both FOSS > community and LISA types) and the more academic-oriented folks looking for > respected places to publish papers/develop their tenure files. > > USENIX had moved from its earlier (anything goes) - pure practitioner > origins - which were also researchers, so at a meeting in a classroom at > NYU, you told people you had something to say and came and did it, to a > more structured (research) approach with program committees, submitted > papers, and vetting and a hotel. Along the way, because it had both types > of people and these were the folks that influenced the buying > patterns, vendors started to show up to show off what they had. At the > time of the ALS conference you mentioned, the things happening in the FOSS > community - was much more like the origins of USENIX. What had for years > separated USENIX from IEEE/ACM was it was where the two foci were really a > single one, and thus had been together and actually considered what was > potential as well as practical. In fact, USENIX was noted as the place > where some of the most influential papers of the time had shown (numerous > storage papers including Rusty's NFS and my EFS paper in the same session, > just about any important security papers, numerous other system papers -- I > could go a few pages here). > > Part of the issue was ACM's SOSP was every 2 years and there was too much > good stuff going on in the system world (BTW - USENIX eventually created > OSDI on alternate years because ACM was just going to do it). But > USENIX also published less formal papers. In fact, one of my all-time > favorite practitioner papers is from another member of this list -- Tom > Lyon's "*All the Chips that Fit*" from the 1985 Summer USENIX [which if > you have never read, send me an email, offline and I'll send you a scanned > PDF -- note to Tom if you still have the original bits I bet USENIX would > like them]. I suspect that such a paper would never have been acceptable > in any of the IEEE or ACM conferences. Also unlike ACM/IEEE (and > frankly the thing that happen at USENIX when I was President that I am most > proud of) is that they do not have a paywall. Anything they published from > the time when all proceedings were electronic is available and slowly some > of the older papers are being scanned or reprinted from the source - as > needed/possible. As much as possible, all of USENIX's papers > are available to anyone > [which was a huge thing to do - as it cut down a lot of revenue for them -- > a paywall for papers is one of the things other associations use]. > > A number of good things happened at the time you mentioned, as well as > some bad. Knowing the parties involved both today and at that time, if > today's BOD and Executive Director was given the same choices that they had > at the time of the action, I suspect we might have had a different outcome. > IMO to the demise of FREENIX and ALS were two of the not-so-good choices > that were made, but I understand why those conferences did go away at that > point in history. If it makes you feel any better, as a former PC Chair > for a couple of FREENIX (which was caught with the same bullet), and as I > said a member of the PC of ALS, I was very sad to see that happen and I > personally fought against it. But, I was on the losing side of that > argument. Unfortunately, that ship sailed, and reviving them is unlikely to > be possible although I believe it has been discussed a number of times > since I left the BOD. > > Back to your point, USENIX may have stopped being as important to many > practitioners, particularly ones in the FOSS community. Which I do find > sad, but I understand the issues on both sides and why that might be so. > For instance, Keith Packard of X11 fame, Steinhart, and I were all > talking about "whence USENIX" at a Hackers conferences a few years back. > So, if you come from that side of the world, you may not value membership > or the results (BTW: my own now hacker daughter, who is a Googler, dropped > her membership last year as she felt it was of less value to her); but so > far USENIX has continued to be important to a large part of the research > community and a set of some practitioners. > > That said, I also believe in 2021, that the USENIX BOD and their ED is > struggling with a financial model that works for them when they do not have > the conference revenue as they had before CV-19. I hope for their sake, > the current treading water situation can find a way to bring them back to > what they were pre-CV-19 because the conferences they traditionally have > held, are excellent (premier in your words) and I would hate to see that > really go away because they have had a lot of value and so far have > continued to provide it. > > Respectfully -- my 2 cents. > > Clem > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Mon Apr 5 07:40:48 2021 From: clemc at ccc.com (Clem Cole) Date: Sun, 4 Apr 2021 17:40:48 -0400 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: <202104042100.134L0nTg086762@darkstar.fourwinds.com> References: <584DED5A-1226-4AF7-A191-C34CAFA53686@pobox.com> <20210404022356.GR28660@mcvoy.com> <20210404085520.GA6494@naleco.com> <202104042100.134L0nTg086762@darkstar.fourwinds.com> Message-ID: On Sun, Apr 4, 2021 at 5:01 PM Jon Steinhart wrote: > Yes, that really sucked but that wasn't until Solaris. > Hey Larry/Rob is that true? I thought the unbundling happened @ Sun when they created a compiler group and finally wrote their own production quality compilers like Masscomp, Apollo, and DEC had at the time. They really needed their own by the time Sun switched from 68K to SPARC. The original SunOS 68K C compiler was based on the MIT RTS compiler that I think Jack Test did the original back end for the Johnson compiler (and Tom Teixeira wrote the assembler). I know it was a couple of years before Sun invested in their own compiler technology. But Sun, (like Masscomp and Apollo), had a lot of ex-DEC folks in Marketing/Sales. DEC had always looked at the compiler has a revenue source [which I have always said is why C beat out BLISS -- C came with UNIX, BLISS cost $5K/cpu for VMS]. I do agree with Lyndon Nerenberg's comment, that Sun start to charge for the C compiler was the biggest help/legitimization that gcc ever got. At Masscomp we had our had own compiler by the second year (which was the primary reason why we won all the performance tests. Our marking weenies wanted to charge for it also. Tom and I were the primary ones that fought it and said, with UNIX you get a C compiler (plus we needed to compile conf.c and a few other things at the customer site for a custom kernel). What sales wanted to s was supply the RTS compiler for free and then charge for the better compiler. We won that skirmish, although I actually think it might have been that the Roger Gourd realized that compiler folk would have had to continue to support the old C compiler, too. So in the end, Fortran and Pascal were unbundled, although I think most (>90%) of the customer base did buy the Fortran system and probably about ⅓ bought Pascal too. Clem FYI - those same ex-DECies took the same ideas to Intel. It's only take me 10-15 years, but some of us finally won that war there. Check out: Download the Intel® oneAPI Base Toolkit - you can get icx and ifx for free these days for Linux and Mac. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lyndon at orthanc.ca Mon Apr 5 07:54:13 2021 From: lyndon at orthanc.ca (Lyndon Nerenberg (VE7TFX/VE6BBM)) Date: Sun, 04 Apr 2021 14:54:13 -0700 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <584DED5A-1226-4AF7-A191-C34CAFA53686@pobox.com> <20210404022356.GR28660@mcvoy.com> <20210404085520.GA6494@naleco.com> <202104042100.134L0nTg086762@darkstar.fourwinds.com> Message-ID: Clem Cole writes: > Hey Larry/Rob is that true? I thought the unbundling happened @ Sun when > they created a compiler group and finally wrote their own production > quality compilers I'm sure it predated Solaris (SunOS 5). My few remaining brain cells from that era say "4.1." --lyndon From clemc at ccc.com Mon Apr 5 07:58:28 2021 From: clemc at ccc.com (Clem Cole) Date: Sun, 4 Apr 2021 17:58:28 -0400 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <584DED5A-1226-4AF7-A191-C34CAFA53686@pobox.com> <20210404022356.GR28660@mcvoy.com> <20210404085520.GA6494@naleco.com> <202104042100.134L0nTg086762@darkstar.fourwinds.com> Message-ID: This begs another Sun History question for one of the Sun alums like Larry or Rob. I know with SunOS, Sun shipped the UCB Pascal System from BSD. Did Sun ever develop/buy/ship a real ISO Pascal? As I said, I know that Sun wrote their own C and Fortran eventually [I'm not sure if they did their own front-ends for either but they did do the back ends in-house, as I knew a couple of the folks had once been Susan Graham's students from our UCB days]. Masscomp wrote its own C Front-End but bought the Fortran Front-End from Massachusetts Compilers Corp in Andover and for Pascal, like Apollo, bought a complete compiler for Pascal [IIRC they both bought it from Friberghouse in Framingham - which did the compilers for Prime and DEC's PL/1 Front-End]. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Mon Apr 5 08:02:59 2021 From: jon at fourwinds.com (Jon Steinhart) Date: Sun, 04 Apr 2021 15:02:59 -0700 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <584DED5A-1226-4AF7-A191-C34CAFA53686@pobox.com> <20210404022356.GR28660@mcvoy.com> <20210404085520.GA6494@naleco.com> <202104042100.134L0nTg086762@darkstar.fourwinds.com> Message-ID: <202104042202.134M2xgs100580@darkstar.fourwinds.com> Lyndon Nerenberg (VE7TFX/VE6BBM) writes: > Clem Cole writes: > > > Hey Larry/Rob is that true? I thought the unbundling happened @ Sun when > > they created a compiler group and finally wrote their own production > > quality compilers > > I'm sure it predated Solaris (SunOS 5). My few remaining brain cells > from that era say "4.1." My SparcStation-20 that runs SunOS has whatever Sun shipped with the OS. My Ultra-60 that runs Solaris has the Sun compiler that I had to purchase separately and their annoying broken license manager that often kept it from running. Gcc became useful before I stopped using that machine so I switched to that. From davida at pobox.com Mon Apr 5 08:25:48 2021 From: davida at pobox.com (David Arnold) Date: Mon, 5 Apr 2021 08:25:48 +1000 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <584DED5A-1226-4AF7-A191-C34CAFA53686@pobox.com> <20210404022356.GR28660@mcvoy.com> <20210404085520.GA6494@naleco.com> Message-ID: > On 5 Apr 2021, at 02:15, Clem Cole wrote: <…> > IBM lost the Research/Universities to DEC which started out being very open and easy to work with and extremely cost-effective. As more $s piled in the market, DEC started to be more and more protective (and moved more and more upscale). To many at the time, DEC compared to IBM (Mainframe S/360 vs. PDP-6/9/10) again -- worse technology, but 'good enough' (and a new growing customer base). The Unix Workstations come out - again 68K vs. Vax (story repeats). Sun eventually taking the lead from DEC. As Larry points out, Sun certainly started being extremely friendly to the same group -- again cost-effective and leading tech. Sun went upscale and the Intel/Microsoft alliance was good enough to a lot of people. To your earlier point, Unix lost the developers to DOS, and later Windows, because they were more “developer friendly”. I think the dominant factor was simple: cost. You could get a DOS PC with BASIC, and later eg. Turbo Pascal, for a fraction of what a Unix system cost. And while the OS barely warranted the name, it was accessible in a way that Unix wasn’t. Over a quite short time, the third-party documentation, language support, editors, tools, etc, quickly outpaced Unix systems, and Windows provided a smooth (and still vastly cheaper) upgrade path. Unix (in the form of Linux) only recruited a significant audience again when its developer cost (nothing, hard to beat) and ease of remote operation outpaced Windows in the late Internet/early Cloud era. <…> > For us UNIX historians, we need to be careful and learn from our own history here -- the Cell Phone/Mobile target is the engine for the next Christenian style disruption. It is by far the #1 target for people writing new programs (which I find a little sad personally - but I understand and accept -- time has marched on). In the end, a small mobile target will be the tech on top, and available will be driven by market behavior and those suppliers will be "who has the gold.” I feel I should point out that both the dominant mobile operating systems are Unix-hased. The UI is necessarily new, but astonishingly the 50 year old basic abstractions are the same. d -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Mon Apr 5 08:55:28 2021 From: clemc at ccc.com (Clem Cole) Date: Sun, 4 Apr 2021 18:55:28 -0400 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <584DED5A-1226-4AF7-A191-C34CAFA53686@pobox.com> <20210404022356.GR28660@mcvoy.com> <20210404085520.GA6494@naleco.com> Message-ID: +1 Your right in both cases.The only thing I will point out about the mobile systems have a unix core - it is extremely hidden and made to be in accessible which to me is exactly what unix was originally working against. Instead of “access methods” of the 60s we have frameworks. We lost simplicity, clarity, and direct access for dancing colors on the LCD and a GUI. Yes they sell a lot of devices but I’m not sure we are better off. On Sun, Apr 4, 2021 at 6:26 PM David Arnold wrote: > On 5 Apr 2021, at 02:15, Clem Cole wrote: > > > <…> > > IBM lost the Research/Universities to DEC which started out being very > open and easy to work with and extremely cost-effective. As more $s piled > in the market, DEC started to be more and more protective (and moved more > and more upscale). To many at the time, DEC compared to IBM (Mainframe > S/360 vs. PDP-6/9/10) again -- worse technology, but 'good enough' (and a > new growing customer base). The Unix Workstations come out - again 68K vs. > Vax (story repeats). Sun eventually taking the lead from DEC. As Larry > points out, Sun certainly started being extremely friendly to the same > group -- again cost-effective and leading tech. Sun went upscale and the > Intel/Microsoft alliance was good enough to a lot of people. > > > To your earlier point, Unix lost the developers to DOS, and later Windows, > because they were more “developer friendly”. > > I think the dominant factor was simple: cost. You could get a DOS PC with > BASIC, and later eg. Turbo Pascal, for a fraction of what a Unix system > cost. And while the OS barely warranted the name, it was accessible in a > way that Unix wasn’t. Over a quite short time, the third-party > documentation, language support, editors, tools, etc, quickly outpaced Unix > systems, and Windows provided a smooth (and still vastly cheaper) upgrade > path. > > Unix (in the form of Linux) only recruited a significant audience again > when its developer cost (nothing, hard to beat) and ease of remote > operation outpaced Windows in the late Internet/early Cloud era. > > <…> > > For us UNIX historians, we need to be careful and learn from our own > history here -- the Cell Phone/Mobile target is the engine for the next > Christenian style disruption. It is by far the #1 target for people > writing new programs (which I find a little sad personally - but I > understand and accept -- time has marched on). In the end, a small mobile > target will be the tech on top, and available will be driven by market > behavior and those suppliers will be "who has the gold.” > > > I feel I should point out that both the dominant mobile operating systems > are Unix-hased. The UI is necessarily new, but astonishingly the 50 year > old basic abstractions are the same. > > > > > d > > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Mon Apr 5 09:00:21 2021 From: bakul at iitbombay.org (Bakul Shah) Date: Sun, 4 Apr 2021 16:00:21 -0700 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <584DED5A-1226-4AF7-A191-C34CAFA53686@pobox.com> <20210404022356.GR28660@mcvoy.com> <20210404085520.GA6494@naleco.com> Message-ID: > On Apr 4, 2021, at 3:25 PM, David Arnold wrote: > >> For us UNIX historians, we need to be careful and learn from our own history here -- the Cell Phone/Mobile target is the engine for the next Christenian style disruption. It is by far the #1 target for people writing new programs (which I find a little sad personally - but I understand and accept -- time has marched on). In the end, a small mobile target will be the tech on top, and available will be driven by market behavior and those suppliers will be "who has the gold.” > > I feel I should point out that both the dominant mobile operating systems are Unix-hased. The UI is necessarily new, but astonishingly the 50 year old basic abstractions are the same. Except Unix is kind of hard to see. It wasn't just the hierarchical file system but the idea of composability. Even now we whip up a shell "one-liners" to perform some task we just thought of. All that is lost. And not just on mobile devices. For example search through email messages for something in an email "app". And no UI composability. We have to use extremely heavyweight IDEs such as X-Code weighing at 15GB (even "du -s /Application/X-code" takes tens of seconds!) to painstakingly construct a UI. We can't just whip up a dashboard to measure & display some realtime changing process/entity. There may be equally heavyweight third party tools but there has been no Bell Labs like research crew to distill it down to the essence of composable UI and ship it with every copy. The idea that users too can learn to "program" if given the right tools. -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.phillip.garcia at gmail.com Mon Apr 5 09:30:34 2021 From: a.phillip.garcia at gmail.com (A. P. Garcia) Date: Sun, 4 Apr 2021 19:30:34 -0400 Subject: [TUHS] How to Kill a Technical Conference (was: Zombified SCO comes back from the dead, brings trial back to life against IBM) In-Reply-To: <20210404052939.xivuinlcugqb5zde@localhost.localdomain> References: <20210401145025.GA1202@naleco.com> <20210404052939.xivuinlcugqb5zde@localhost.localdomain> Message-ID: >> Misremembered the year. That conference was October 2000. I just >> found the bookbag I got as swag from it. > I think you're remembering the Atlanta Linux Showcase. I was at the same event. I also think I know exactly the person you're talking about: Charles Hannum, with whom I had a similar experience on a different topic. ALS '99 was a fun conference. I didn't attend in 2000. I'm going to stick my neck out just a little bit and say that my experience with him was quite different. We talked a little about the differences between Linux and BSD, both userland and kernel space, and the history of NetBSD, including an unfortunate occurrence with Bill Jolitz at a different conference. Charles was cordial with me. That same day, I went to the cafeteria area when I got hungry, and I saw what looked like two kids sitting around a laptop working intently on something. I was curious, so I asked them what they were hacking on. It turned out to be Miguel de Icaza, now a Distinguished Engineer at Microsoft, and Nat Friedman, who I believe is now CTO of GitHub (also owned by Microsoft). They sort of blew me off, but to be fair, they were working on a presentation they were about to deliver. On Sun, Apr 4, 2021, 1:31 AM G. Branden Robinson < g.branden.robinson at gmail.com> wrote: > At 2021-04-03T19:50:51-0700, Adam Thornton wrote: > > > But back to the S/390 port--I went to a Linux conference in Atlanta > > > in the late 90s ('99, I think) to speak about Linux on S390/Z, and I > > > actually went by the NetBSD booth to say, "hey, I can maybe hook you > > > guys up with a development virtual machine," and what I got was an > > > earful about "your so-called portability" from someone who was > > > clearly much more invested in hating Linux than in, you know, > > > saying, "wow, OK, I realize you're not offering me cycles on a > > > super-awesome machine, but, yeah, it's not nothing, cool, here's who > > > you should talk to if you're interested in getting a port going." > > > > > > So I don't think you can lay all the blame on BSD inaction on Linux, > > > is all I'm saying. By '99, I think it was, maybe if NetBSD, which > > > already had its reputation for spectacular portability, hadn't > > > staffed its booth with a jackass still trying to fight the Unix > > > Wars, that story might have turned out differently. > > > > Misremembered the year. That conference was October 2000. I just > > found the bookbag I got as swag from it. > > I think you're remembering the Atlanta Linux Showcase. I was at the > same event. I also think I know exactly the person you're talking > about: Charles Hannum, with whom I had a similar experience on a > different topic. > > Instead of insisting that I was stupid and wrong for using Linux instead > of (NetBSD) in his view, I was stupid and wrong for using software > licensed under the GNU GPL instead of the "BSD" license (which variant > of the latter is not, all these years later, a matter I recall coming > up). I mention this so that Mr. Hannum's reputation on this list risks > no blackening among those who share his hostility to copyleft. ;-) > > ALS was a terrific experience and, for me, lived up to the praise I had > heard about it as a venue for getting engineers talking to each other. > Regrettably enough, the conference was acquired by a firm. It was held > one final time the next year in Atlanta, officially rebranded the > "Annual Linux Showcase", and, as I recall, permanently mothballed > thereafter, with the dot-com bubble-burst as either a direct reason or > as an excuse. > > I have seen other technical conferences over the years steadily morph > from a technical/engineering focus to an orientation around sales and > "strategy", or more bluntly--propaganda. The emphasis is no longer on > technological improvement and evaluation (i.e., how to achieve and > measure "solutions"), but on promotion, rationalization, and boosterism. > > I suppose that one of the reasons this happens is that good conferences > grow, and companies sending delegations find themselves with growing > expense bills for doing so. Engineers are a cost center. When they > come back from the event, they will almost never have anything to "show > for it". At best they'll be excited about something they can > "integrate" or some new idea they can realize after months of > development time. In other words, you _might_ have a competitive > advantage after spending _even more_ money. > > By contrast, sales people can bring you orders you can book the day they > get back, or even before the conference is over, thanks to the magic > power of accrual accounting, a practice which persists even after the > glorious examples of Enron and other gigantic bankruptcies of the 2000s. > > That's the demand side. On the supply side, conferences have > governance; it takes people to solicit papers, book speakers, and put > talks on the schedule and into proceedings. Conference sponsorship is a > neat way of closing the gap between demand and supply on the back end; > be a "gold" or "platinum" level sponsor and obtain influence, likely > through direct seating of representatives on the committees that perform > the foregoing organizational roles. Note the entrenchment and > persistence of precious metals as metaphors for status; we would not > name the tiers after the decreasing scale of photolithographic > processes, for example. Historically, it's been a lot easier to > motivate a guy with a checkbook in the C suite who drives a Lamborghini > Gallardo with the word "platinum" than "5 nm". > > I'm too young to know--did USENIX follow the trajectory of reorienting > its focus from engineering and research to sales? Why does it no longer > occupy the premier place it once did? > > Regards, > Branden > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Mon Apr 5 09:33:13 2021 From: clemc at ccc.com (Clem Cole) Date: Sun, 4 Apr 2021 19:33:13 -0400 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <584DED5A-1226-4AF7-A191-C34CAFA53686@pobox.com> <20210404022356.GR28660@mcvoy.com> <20210404085520.GA6494@naleco.com> Message-ID: On Sun, Apr 4, 2021 at 7:01 PM Bakul Shah wrote: > > > On Apr 4, 2021, at 3:25 PM, David Arnold wrote: > > For us UNIX historians, we need to be careful and learn from our own > history here -- the Cell Phone/Mobile target is the engine for the next > Christenian style disruption. It is by far the #1 target for people > writing new programs (which I find a little sad personally - but I > understand and accept -- time has marched on). In the end, a small mobile > target will be the tech on top, and available will be driven by market > behavior and those suppliers will be "who has the gold.” > > > I feel I should point out that both the dominant mobile operating systems > are Unix-hased. The UI is necessarily new, but astonishingly the 50 year > old basic abstractions are the same. > > > Except Unix is kind of hard to see. It wasn't just the hierarchical file > system but the idea of composability. Even now we whip up a shell > "one-liners" to perform some task we just thought of. All that is lost. And > not just on mobile devices. For example search through email messages for > something in an email "app". And no UI composability. We have to use > extremely heavyweight IDEs such as X-Code weighing at 15GB (even "du -s > /Application/X-code" takes tens of seconds!) to painstakingly construct a > UI. We can't just whip up a dashboard to measure & display some realtime > changing process/entity. There may be equally heavyweight third party tools > but there has been no Bell Labs like research crew to distill it down to > the essence of composable UI and ship it with every copy. The idea that > users too can learn to "program" if given the right tools. > Exactly my point. The only difference I suspect is I just don't bother with the IDE (Xcode or VS). Frankly, vi/emacs, or as we discussed a few days ago, ed is still way more preferable when I'm programming. I mentioned in another email Intel's new development suite - OneAPI. Absolutely speaking for myself here, I am a bit at odds with management WRT to much of it, as I feel the direction is a bit miss guided. But I do understand why Intel is doing it/trying. Everyone in the industry seems to be saying "use my Framework, my language, my solution and I will solve your problem." "You will sell more copies of the program if you use my portal, *etc*." Intel to compete, needs to do the same things. To me, it seems a bit like fairy dust - a promise that will work for a set of people, and of course, some firms like my own employer will keep making money (or in the words of the Dr. Sueuss Lorax character: "Biggering and Biggering." As I said in the previous message, it is driven by the other golden rule. What I always felt made UNIX powerful was that it did not seem like the BTL folks were trying to sell anything. They were trying to solve real problems they and the folks at AT&T had when it came to realistically building and deploying systems. Yes, there were hidden from the profit motive at the time because of the unique rules of the 1956 consent degree and we all were winners because of it because they say -- sure here you can use it too. Now that we are back to a winner take all market, (OSVM/360 *vs.* VMS *vs.* winders ...) I think we have traded away designing for the sake of getting the job done properly, for designing to sell as many as possible (*i.e.* be sexy and capture a market, not be simple and do the job well). -------------- next part -------------- An HTML attachment was scrubbed... URL: From pepe at naleco.com Mon Apr 5 09:34:29 2021 From: pepe at naleco.com (Josh Good) Date: Mon, 5 Apr 2021 01:34:29 +0200 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <584DED5A-1226-4AF7-A191-C34CAFA53686@pobox.com> <20210404022356.GR28660@mcvoy.com> <20210404085520.GA6494@naleco.com> Message-ID: <20210404233427.GA12055@naleco.com> On 2021 Apr 5, 08:25, David Arnold wrote: > > I feel I should point out that both the dominant mobile operating systems > are Unix-hased. The UI is necessarily new, but astonishingly the 50 year > old basic abstractions are the same. Imagine XinuOS suing Apple and Google for the UNIX "traces" on their mobile platforms, wouldn't that be a sight? -- Josh Good From dave at horsfall.org Mon Apr 5 09:48:38 2021 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 5 Apr 2021 09:48:38 +1000 (EST) Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: <202104042100.134L0nTg086762@darkstar.fourwinds.com> References: <584DED5A-1226-4AF7-A191-C34CAFA53686@pobox.com> <20210404022356.GR28660@mcvoy.com> <20210404085520.GA6494@naleco.com> <202104042100.134L0nTg086762@darkstar.fourwinds.com> Message-ID: On Sun, 4 Apr 2021, Jon Steinhart wrote: >> Yes, but weren't they also the first to unbundle the C compiler? Until > > Yes, that really sucked but that wasn't until Solaris. And it cost an arm and a leg, so we ended up using GCC instead. -- Dave From lm at mcvoy.com Mon Apr 5 09:53:14 2021 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 4 Apr 2021 16:53:14 -0700 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <584DED5A-1226-4AF7-A191-C34CAFA53686@pobox.com> <20210404022356.GR28660@mcvoy.com> <20210404085520.GA6494@naleco.com> <202104042100.134L0nTg086762@darkstar.fourwinds.com> Message-ID: <20210404235314.GH28660@mcvoy.com> On Mon, Apr 05, 2021 at 09:48:38AM +1000, Dave Horsfall wrote: > On Sun, 4 Apr 2021, Jon Steinhart wrote: > > >>Yes, but weren't they also the first to unbundle the C compiler? Until > > > >Yes, that really sucked but that wasn't until Solaris. > > And it cost an arm and a leg, so we ended up using GCC instead. The funny thing is Sun paid Michael Tiemann to work on g++. And he worked out a deal that it was all open source. Life is weird. From cowan at ccil.org Mon Apr 5 10:36:10 2021 From: cowan at ccil.org (John Cowan) Date: Sun, 4 Apr 2021 20:36:10 -0400 Subject: [TUHS] How to Kill a Technical Conference (was: Zombified SCO comes back from the dead, brings trial back to life against IBM) In-Reply-To: References: <20210401145025.GA1202@naleco.com> <20210404052939.xivuinlcugqb5zde@localhost.localdomain> Message-ID: On Sun, Apr 4, 2021 at 2:23 PM Clem Cole wrote: > An issue during the time you are discussing, USENIX had evolved into "two > foci" between the practitioners (which included both FOSS community and > LISA types) and the more academic-oriented folks looking for respected > places to publish papers/develop their tenure files. > I think this is a long and accelerating trend, and not just at conferences. There simply are no venues for "engineering" papers or presentations any more, which doesn't bother me directly, but bothers me very much indirectly, because I love engineering papers and have to read academic papers, ummm, very selectively. (In particular, anything labeled "formal semantics" just gets skipped.) John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org And it was said that ever after, if any man looked in that Stone, unless he had a great strength of will to turn it to other purpose, he saw only two aged hands withering in flame. --"The Pyre of Denethor" -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Mon Apr 5 11:34:28 2021 From: bakul at iitbombay.org (Bakul Shah) Date: Sun, 4 Apr 2021 18:34:28 -0700 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <584DED5A-1226-4AF7-A191-C34CAFA53686@pobox.com> <20210404022356.GR28660@mcvoy.com> <20210404085520.GA6494@naleco.com> Message-ID: <9BF72B30-C353-4F61-8DF0-738F8E9536EE@iitbombay.org> On Apr 4, 2021, at 4:33 PM, Clem Cole wrote: > > > On Sun, Apr 4, 2021 at 7:01 PM Bakul Shah > wrote: > > >> On Apr 4, 2021, at 3:25 PM, David Arnold > wrote: >> >>> For us UNIX historians, we need to be careful and learn from our own history here -- the Cell Phone/Mobile target is the engine for the next Christenian style disruption. It is by far the #1 target for people writing new programs (which I find a little sad personally - but I understand and accept -- time has marched on). In the end, a small mobile target will be the tech on top, and available will be driven by market behavior and those suppliers will be "who has the gold.” >> >> I feel I should point out that both the dominant mobile operating systems are Unix-hased. The UI is necessarily new, but astonishingly the 50 year old basic abstractions are the same. > > Except Unix is kind of hard to see. It wasn't just the hierarchical file system but the idea of composability. Even now we whip up a shell "one-liners" to perform some task we just thought of. All that is lost. And not just on mobile devices. For example search through email messages for something in an email "app". And no UI composability. We have to use extremely heavyweight IDEs such as X-Code weighing at 15GB (even "du -s /Application/X-code" takes tens of seconds!) to painstakingly construct a UI. We can't just whip up a dashboard to measure & display some realtime changing process/entity. There may be equally heavyweight third party tools but there has been no Bell Labs like research crew to distill it down to the essence of composable UI and ship it with every copy. The idea that users too can learn to "program" if given the right tools. > > Exactly my point. The only difference I suspect is I just don't bother with the IDE (Xcode or VS). Frankly, vi/emacs, or as we discussed a few days ago, ed is still way more preferable when I'm programming. Many things are easier to convey visually. It would be neat if unix paradigms can be extended to visual design as well. And you certainly can't do visual design easily in vi/emacs. Just like in Autocad you need both interactivity and programmability for creating visual elements. > I mentioned in another email Intel's new development suite - OneAPI. Absolutely speaking for myself here, I am a bit at odds with management WRT to much of it, as I feel the direction is a bit miss guided. But I do understand why Intel is doing it/trying. Everyone in the industry seems to be saying "use my Framework, my language, my solution and I will solve your problem." "You will sell more copies of the program if you use my portal, etc." Intel to compete, needs to do the same things. To me, it seems a bit like fairy dust - a promise that will work for a set of people, and of course, some firms like my own employer will keep making money (or in the words of the Dr. Sueuss Lorax character: "Biggering and Biggering." As I said in the previous message, it is driven by the other golden rule. IMHO a bigger need is some discipline on storage. As things stand, it is hard to extract data from applications for legitimate uses but not so hard to extract for illegitimate uses. If app A for some specific domain dies, there is no guarantee that app B for the same domain can use A's data. > What I always felt made UNIX powerful was that it did not seem like the BTL folks were trying to sell anything. They were trying to solve real problems they and the folks at AT&T had when it came to realistically building and deploying systems. Yes, there were hidden from the profit motive at the time because of the unique rules of the 1956 consent degree and we all were winners because of it because they say -- sure here you can use it too. Similar conditions existed and exist to a certain extent in research orgs of some companies but I think that is a necessary condition, not sufficient. The right research crew can bring in another kind of interactivity -- in creativity, in trying out and critiquing each others' ideas and building on them. And you still need the right key people. > Now that we are back to a winner take all market, (OSVM/360 vs. VMS vs. winders ...) I think we have traded away designing for the sake of getting the job done properly, for designing to sell as many as possible (i.e. be sexy and capture a market, not be simple and do the job well). -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Mon Apr 5 12:19:48 2021 From: imp at bsdimp.com (Warner Losh) Date: Sun, 4 Apr 2021 20:19:48 -0600 Subject: [TUHS] How to Kill a Technical Conference (was: Zombified SCO comes back from the dead, brings trial back to life against IBM) In-Reply-To: References: <20210401145025.GA1202@naleco.com> <20210404052939.xivuinlcugqb5zde@localhost.localdomain> Message-ID: On Sun, Apr 4, 2021 at 6:37 PM John Cowan wrote: > > > On Sun, Apr 4, 2021 at 2:23 PM Clem Cole wrote: > > >> An issue during the time you are discussing, USENIX had evolved into "two >> foci" between the practitioners (which included both FOSS community and >> LISA types) and the more academic-oriented folks looking for respected >> places to publish papers/develop their tenure files. >> > > I think this is a long and accelerating trend, and not just at > conferences. There simply are no venues for "engineering" papers or > presentations any more, which doesn't bother me directly, but bothers me > very much indirectly, because I love engineering papers and have to read > academic papers, ummm, very selectively. (In particular, anything labeled > "formal semantics" just gets skipped.) > It's the main reason I've not had a USENIX paper published in about 15 years... The other issue that I've run into is that the reviewers of the papers often times don't understand the systems they are commenting on, so often I got comments that made no sense at all... :(. Warner > > > John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org > And it was said that ever after, if any man looked in that Stone, > unless he had a great strength of will to turn it to other purpose, > he saw only two aged hands withering in flame. --"The Pyre of Denethor" > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Mon Apr 5 12:30:27 2021 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 5 Apr 2021 12:30:27 +1000 (EST) Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <584DED5A-1226-4AF7-A191-C34CAFA53686@pobox.com> <20210404022356.GR28660@mcvoy.com> <20210404085520.GA6494@naleco.com> Message-ID: On Sun, 4 Apr 2021, Clem Cole wrote: > Instead of “access methods” of the 60s we have frameworks.  We lost > simplicity, clarity, and direct access for dancing colors on the LCD and > a GUI.  Yes they sell a lot of devices but I’m not sure we are better > off.   Ahh, BSAM etc... That brings back memories! Incidentally my MacBook spends most of its time running various Terminals into my FreeBSD server; I rarely use Spotlight or that Finder thing (or whatever it's called); gimme a shell prompt any day! -- Dave From kennethgoodwin56 at gmail.com Mon Apr 5 12:58:57 2021 From: kennethgoodwin56 at gmail.com (Kenneth Goodwin) Date: Sun, 4 Apr 2021 22:58:57 -0400 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: <9BF72B30-C353-4F61-8DF0-738F8E9536EE@iitbombay.org> References: <584DED5A-1226-4AF7-A191-C34CAFA53686@pobox.com> <20210404022356.GR28660@mcvoy.com> <20210404085520.GA6494@naleco.com> <9BF72B30-C353-4F61-8DF0-738F8E9536EE@iitbombay.org> Message-ID: On storage discipline- UNIX derived systems deliberately don't enforce file formats. In the UNIX philosophy Everything is a file. Inter program portability can be achieved in a multitude of ways. Pure ascii format with either defined field widths or the more common "special character" delimited fields. Ie pipe delimited or comma or : delimited. xml formatted. There are several conversion programs available as well as write your own. On Sun, Apr 4, 2021, 9:36 PM Bakul Shah wrote: > On Apr 4, 2021, at 4:33 PM, Clem Cole wrote: > > > > On Sun, Apr 4, 2021 at 7:01 PM Bakul Shah wrote: > >> >> >> On Apr 4, 2021, at 3:25 PM, David Arnold wrote: >> >> For us UNIX historians, we need to be careful and learn from our own >> history here -- the Cell Phone/Mobile target is the engine for the next >> Christenian style disruption. It is by far the #1 target for people >> writing new programs (which I find a little sad personally - but I >> understand and accept -- time has marched on). In the end, a small mobile >> target will be the tech on top, and available will be driven by market >> behavior and those suppliers will be "who has the gold.” >> >> >> I feel I should point out that both the dominant mobile operating systems >> are Unix-hased. The UI is necessarily new, but astonishingly the 50 year >> old basic abstractions are the same. >> >> >> Except Unix is kind of hard to see. It wasn't just the hierarchical file >> system but the idea of composability. Even now we whip up a shell >> "one-liners" to perform some task we just thought of. All that is lost. And >> not just on mobile devices. For example search through email messages for >> something in an email "app". And no UI composability. We have to use >> extremely heavyweight IDEs such as X-Code weighing at 15GB (even "du -s >> /Application/X-code" takes tens of seconds!) to painstakingly construct a >> UI. We can't just whip up a dashboard to measure & display some realtime >> changing process/entity. There may be equally heavyweight third party tools >> but there has been no Bell Labs like research crew to distill it down to >> the essence of composable UI and ship it with every copy. The idea that >> users too can learn to "program" if given the right tools. >> > > Exactly my point. The only difference I suspect is I just don't bother > with the IDE (Xcode or VS). Frankly, vi/emacs, or as we discussed a few > days ago, ed is still way more preferable when I'm programming. > > > Many things are easier to convey visually. It would be neat if unix > paradigms can be extended to visual design as well. And you certainly can't > do visual design easily in vi/emacs. Just like in Autocad you need both > interactivity and programmability for creating visual elements. > > I mentioned in another email Intel's new development suite - OneAPI. > Absolutely speaking for myself here, I am a bit at odds with management WRT > to much of it, as I feel the direction is a bit miss guided. But I do > understand why Intel is doing it/trying. Everyone in the industry seems > to be saying "use my Framework, my language, my solution and I will solve > your problem." "You will sell more copies of the program if you use my > portal, *etc*." Intel to compete, needs to do the same things. To > me, it seems a bit like fairy dust - a promise that will work for a set of > people, and of course, some firms like my own employer will keep making > money (or in the words of the Dr. Sueuss Lorax character: "Biggering and > Biggering." As I said in the previous message, it is driven by the other > golden rule. > > > IMHO a bigger need is some discipline on storage. As things stand, it is > hard to extract data from applications for legitimate uses but not so hard > to extract for illegitimate uses. If app A for some specific domain dies, > there is no guarantee that app B for the same domain can use A's data. > > What I always felt made UNIX powerful was that it did not seem like the > BTL folks were trying to sell anything. They were trying to solve real > problems they and the folks at AT&T had when it came to realistically > building and deploying systems. Yes, there were hidden from the profit > motive at the time because of the unique rules of the 1956 consent degree > and we all were winners because of it because they say -- sure here you can > use it too. > > > Similar conditions existed and exist to a certain extent in research orgs > of some companies but I think that is a necessary condition, not > sufficient. The right research crew can bring in another kind of > interactivity -- in creativity, in trying out and critiquing each others' > ideas and building on them. And you still need the right key people. > > Now that we are back to a winner take all market, (OSVM/360 *vs.* VMS > *vs.* winders ...) I think we have traded away designing for the sake of > getting the job done properly, for designing to sell as many as possible ( > *i.e.* be sexy and capture a market, not be simple and do the job well). > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Mon Apr 5 17:48:07 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 05 Apr 2021 01:48:07 -0600 Subject: [TUHS] Whither Usenix [was How To Kill A Technical Conference] In-Reply-To: References: <20210401145025.GA1202@naleco.com> <20210404052939.xivuinlcugqb5zde@localhost.localdomain> Message-ID: <202104050748.1357m710026933@freefriends.org> This hits home with me very hard. I have been a Usenix member since the around 1984. Almost 40 years. I am finally letting my membership drop, now that ";login:" is going soft-copy. But for several years now I have been increasingly dissatisfied with the research nature of most of the articles. Very few of them are actually useful (or even interesting) to me in a day-to-day sense. And this saddens me; I used to be proud to be a Usenix member; I no longer feel like I get any added value. Especially as I live out of the US, attending conferences is impossible. (The last annual conference I went to was in 2004.) Ah well. The only constant in the world is change. Arnold John Cowan wrote: > On Sun, Apr 4, 2021 at 2:23 PM Clem Cole wrote: > > > An issue during the time you are discussing, USENIX had evolved into "two > > foci" between the practitioners (which included both FOSS community and > > LISA types) and the more academic-oriented folks looking for respected > > places to publish papers/develop their tenure files. > > > > I think this is a long and accelerating trend, and not just at > conferences. There simply are no venues for "engineering" papers or > presentations any more, which doesn't bother me directly, but bothers me > very much indirectly, because I love engineering papers and have to read > academic papers, ummm, very selectively. (In particular, anything labeled > "formal semantics" just gets skipped.) > > John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org > And it was said that ever after, if any man looked in that Stone, > unless he had a great strength of will to turn it to other purpose, > he saw only two aged hands withering in flame. --"The Pyre of Denethor" From cowan at ccil.org Mon Apr 5 22:35:28 2021 From: cowan at ccil.org (John Cowan) Date: Mon, 5 Apr 2021 08:35:28 -0400 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <584DED5A-1226-4AF7-A191-C34CAFA53686@pobox.com> <20210404022356.GR28660@mcvoy.com> <20210404085520.GA6494@naleco.com> <9BF72B30-C353-4F61-8DF0-738F8E9536EE@iitbombay.org> Message-ID: On Sun, Apr 4, 2021 at 7:01 PM Bakul Shah wrote: Except Unix is kind of hard to see. See the Unix Power Classic (incomplete) at http://vrici.lojban.org/~cowan/upc/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Mon Apr 5 23:37:32 2021 From: tytso at mit.edu (Theodore Ts'o) Date: Mon, 5 Apr 2021 09:37:32 -0400 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: <20210404022356.GR28660@mcvoy.com> References: <584DED5A-1226-4AF7-A191-C34CAFA53686@pobox.com> <20210404022356.GR28660@mcvoy.com> Message-ID: On Sat, Apr 03, 2021 at 07:23:56PM -0700, Larry McVoy wrote: > > I'm the biggest SunOS 4.x fan boy and I agree. It was ~30 years ago. > Back then, all the open source stuff, or closed source stuff, took a > ton of work to make it work. It just worked on SunOS. I can't tell > you how many times I've brought up X10 or X11 on all sorts of systems > (it was a good learning experience, you learned to figure out that this > is part of my graphics card, this and that and that and that is not, > just ifdef that out and keep going). To be fair, a lot of that was because there's a lot of crappy userspace software out there who assumed that all the world's a Sun (running SunOS). Previously it was Vax running BSD 4.x, and it's been superceded these days with "all the world's Linux (running on x86_64)". I'm a big Linux fan boy, but that doesn't blind me to the fact that that there's a lot of cr*p that uses slow, maddening autoconf and automake build systems, yet have so many Linux'isms in it that won't build anywhere else. The fact that a lot of software easily brings up on a particular OS doesn't mean that it's inherently better; just that it has the dominant mindshare. - Ted From tytso at mit.edu Tue Apr 6 00:05:04 2021 From: tytso at mit.edu (Theodore Ts'o) Date: Mon, 5 Apr 2021 10:05:04 -0400 Subject: [TUHS] How to Kill a Technical Conference (was: Zombified SCO comes back from the dead, brings trial back to life against IBM) In-Reply-To: References: <20210401145025.GA1202@naleco.com> <20210404052939.xivuinlcugqb5zde@localhost.localdomain> Message-ID: On Sun, Apr 04, 2021 at 02:22:22PM -0400, Clem Cole wrote: > > Actually, quite the opposite, USENIX was getting more and more academic and > research-oriented and less 'trade show.' The key is that USENIX and ALS > should have been an excellent match, unfortunately, some of the > personalities involved were at odds with each other. IMO: it was more of a > crash of personalities/control issues - the details do not need to be > repeated or aired again. Note: I was on the BOD at that time and in fact on > the PC for that specific conference. Ted may have been on the BOD at the > same time. A lot of the conflicts were over the writing style. There many ways you can write papers. For example: (a) academic papers suitable for tenure-track publications (b) technical industry paper meant for other industry practitioners (c) white papers written by and for sales/marketing folks Usenix at the time was trying very hard to make sure its conferences would be taken seriously by tenure committees, and so there was a strong sense that any paper published by Usenix had to be super high quality from the perspective of (a). Most of the Linux programmers had absolutely no interest in getting tenure, and with much prodding, you might be able to get them to strive for (b). But there were a lot of people who were volunteering for Usenix program committees, even for things like USELINUX, who were convinced that (a) was the only way to write quality papers. There was a bit of, "well, we'll give you a kiddy-pool track called USELINUX, but maybe someday you'll grow up and write real papers." That condescension was probably responsible for a lot of the personality issues. There was a lot of other things going on around that time; which others have written about or observed --- the passing (into retirement, or being kicked up into senior management) of technical leaders at companies who would encourage their engineers to publish at conferences. IBM stopped paying financial incentives for people to publish papers at conferences, and it became clear it didn't really help ones career prospects, with the possible exception of once you were trying for DE; another company with which I have a lot of personal experience strongly discouraged people from publishing because there was a slow, bureaucratic process required to get publication permission lest that company's "secret sauce" get exposed, etc. Interestingly, that process only applies to *papers*; but if you give a *talk* at a Linux conference, it was a lot easier to bypass the bureaucracy. > But USENIX also published less formal papers. In fact, one of my > all-time favorite practitioner papers is from another member of this > list -- Tom Lyon's "*All the Chips that Fit*" from the 1985 Summer > USENIX [which if you have never read, send me an email, offline and > I'll send you a scanned PDF -- note to Tom if you still have the > original bits I bet USENIX would like them]. I suspect that such a > paper would never have been acceptable in any of the IEEE or ACM > conferences. Yeah, that was the 80's. By the time the 90's rolled around, people were trying *really* hard to become much more formal. And if you compare papers from a conference like, say, FAST, I'd say they are at the same level as many ACM/IEEE papers. I will be the first to say this is a really good thing, but it does have some engineering tradeoffs. > Back to your point, USENIX may have stopped being as important to > many practitioners, particularly ones in the FOSS community. Which I > do find sad, but I understand the issues on both sides and why that > might be so. For instance, Keith Packard of X11 fame, Steinhart, > and I were all talking about "whence USENIX" at a Hackers > conferences a few years back. So, if you come from that side of the > world, you may not value membership or the results (BTW: my own now > hacker daughter, who is a Googler, dropped her membership last year > as she felt it was of less value to her); but so far USENIX has > continued to be important to a large part of the research community > and a set of some practitioners. Everyone has the best of intentions, but reality is that the incentives for academic researchers and industry practitioners have widened over time. Everyone has a limited amount of time and budget, and if you're an industry practitioner, you are primarily graded on your ability for you to deliver technically difficult projects that have great impact on the company --- and the easist ways for impact to be judged by a promotion committee is by saving the company $XXX million over 5 years, or bringing in $XXX million. If you are an academic, the deliverables by which you are judged are graduate students and publications. And if you don't have tenure yet, those had better be publications that are taken seriously by tenure committees. So creating a conference which meets the primary goals of these two populatations is... hard. Quite frankly, it's a lot easier for me to make a case to go to Usenix conferences to (a) harvest ideas for me to take back to the company, and (b) harvest graduate students for the hiring pipeline. It's not to contribute to the conference; I might do that on my own time, but realistically, when I spend 80-100 hours working on a program commitee, that mostly comes out of my own personal time --- not really out of time paid for by my company. At best my company will tolerate my time to attend a PC meeting, and pay for my travel. But that's really about it. And so to spend a huge amount of time writing a paper which is suitable for a program commitee which has been giving its marching orders by the conference's steering committee to make sure that the proceedings will be taken seriously by a tenure commitee? Nope, not the best use my time. Cheers, - Ted From norman at oclsc.org Tue Apr 6 02:20:50 2021 From: norman at oclsc.org (Norman Wilson) Date: Mon, 5 Apr 2021 12:20:50 -0400 (EDT) Subject: [TUHS] Whither Usenix [was How To Kill A Technical Conference] Message-ID: <20210405162050.DBFDD640CB7@lignose.oclsc.org> Arnold: But for several years now I have been increasingly dissatisfied with the research nature of most of the articles. Very few of them are actually useful (or even interesting) to me in a day-to-day sense. === I guess it depends on your interests, and also on what you look at. I've got way behind in reading ;login:, but have been regularly attending conferences: the Annual Technical Conference (ATC) and some workshops (HotStorage, HotCloud) that are usually co-located; LISA. I still find plenty to interest me, both in talks and in the hallway tracks, though LISA has been drying up over the years (and it's clear that USENIX know that too and are working on whether it should just be subsumed into the already-burgeoning SREcons). As I say, interests differ, but I've learned plenty of new things about OS and networking design and implementation tradeoffs, security at many levels, file systems, and storage devices. Thanks to COVID, USENIX-sponsored conferences have all been online for the past year and are expected to stay so through the end of 2021. For obvious reasons that greatly reduces the expenses of the conferences, so the registration fees are about 10% of normal. Thanks to that, I've been able to sample conferences I've never had time or money to travel to, like Security and FAST (file systems and storage). It's been well worth my time and money even though the money comes out of my own pocket. UNIX history is not part of the mainstream USENIX world these days, alas--I was disappointed that there was no official 50th- birthday party two years ago in Seattle (though the not-officially- sponsored one at LCM organized by Clem and others was a fine time, and USENIX had no objection to hosting announcements of it). I should point out that the only time I've met Our Esteemed Leader and Listrunner in person was at a USENIX conference, where he held a session to show off his reconstructed very-early PDP-11 UNIX from the tape Dennis found under the floor of the UNIX Room. I too would like to see the organization harbour some less-formal meetings or publications. The way to make that happen would be to run for the Board and to actively sponsor such stuff (with care about who is selected for the real work to avoid the problems Ted describes). Maybe that's a good idea, or maybe it's better to let the Linux and BSD worlds do their own thing. Either way I think what USENIX does is worth while. I've been a member for 40 years this year, and although it's not the same organization as it was in the early 1980s, neither is it the same world it lives in. I still think they do worth while work and I am proud to continue to support them, even though I'm not a published academic researcher, just an old-style systems hack and sysadmin from the ancient days when those were inseparable. Norman Wilson Toronto ON From gnu at toad.com Tue Apr 6 04:07:19 2021 From: gnu at toad.com (John Gilmore) Date: Mon, 05 Apr 2021 11:07:19 -0700 Subject: [TUHS] How to Kill a Technical Conference In-Reply-To: References: <20210401145025.GA1202@naleco.com> <20210404052939.xivuinlcugqb5zde@localhost.localdomain> Message-ID: <19643.1617646039@hop.toad.com> > > There simply are no venues for "engineering" papers or > > presentations any more... > > It's the main reason I've not had a USENIX paper published in about 15 > years... I'm an engineer, not an academic. The only time I submitted a paper to USENIX, it was about my 1988 project with CSRG to convert the BSD distribution to using GCC rather than PCC. The project itself was an interesting tour through C language history, turning up ancient code that used ints as pointers, for example. The paper was rejected by the program committee, on the objection that "ports aren't research". So the pro-academic, anti-engineering mindset was already in place back then. Though I was disappointed to have the paper rejected, at the time I thought (like an engineer!) that the reason for rejection was a bit of a positive comment -- "Our software is becoming portable enough that it doesn't take imagination, genius, or innovation to make it run on a completely different architecture or toolchain." (I posted the 1988 draft paper to this TUHS list in May 2020, in a thread with the subject "History of popularity of C".) John From arnold at skeeve.com Tue Apr 6 04:31:20 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 05 Apr 2021 12:31:20 -0600 Subject: [TUHS] Whither Usenix [was How To Kill A Technical Conference] In-Reply-To: <20210405162050.DBFDD640CB7@lignose.oclsc.org> References: <20210405162050.DBFDD640CB7@lignose.oclsc.org> Message-ID: <202104051831.135IVKJS013930@freefriends.org> norman at oclsc.org (Norman Wilson) wrote: > Arnold: > > But for several years now I have been increasingly dissatisfied with the > research nature of most of the articles. Very few of them are actually > useful (or even interesting) to me in a day-to-day sense. > > === > > I guess it depends on your interests, and also on what you look at. Yes, exactly. For me, Usenix provides little added value. I had been debating leaving Usenix for several years already; the move to soft copy ;login: clinched it for me. I'm not happy about it, but I had to recognize my personal reality. > Either way I think what USENIX does is worth while. I agree. For example, I would not like to see Usenix disappear. But I no longer am getting value for my membership dollars. So, not a value judgement on Usenix as a whole, merely a statement of my personal situation. Arnold From clemc at ccc.com Tue Apr 6 05:30:25 2021 From: clemc at ccc.com (Clem Cole) Date: Mon, 5 Apr 2021 15:30:25 -0400 Subject: [TUHS] How to Kill a Technical Conference In-Reply-To: <19643.1617646039@hop.toad.com> References: <20210401145025.GA1202@naleco.com> <20210404052939.xivuinlcugqb5zde@localhost.localdomain> <19643.1617646039@hop.toad.com> Message-ID: On Mon, Apr 5, 2021 at 2:08 PM John Gilmore wrote: > The paper was rejected by the program committee, on the objection that > "ports aren't research". So > the pro-academic, anti-engineering mindset was already in place back then. > John - to be honest, I think the attempt to make the standard for paper acceptance had started before 1988. I was on PCs in the early 1983s and pressure was already on the PCs (and authors) to use 'academic standards'. I think Ted described the issue well. The fact is a paper like the one you describe, I do think would not have been as interesting to some (maybe even many) in the USENIX audience, although I clearly agree with you that it would have been for others. The problem was that paper like that was not going to help people that were working on a tenure file and the PCs wanted to fil the sessions with them. To USENIX's credit, by the mid to late the 1980s, a USENIX was considered by many academic committees. The issue for the USENIX BOD had always been getting butts in the seats to pay the bills. Academics had a path, so following what IEEE and ACM did was well-trod and understood. Get the more pure hackers like yourself, even the engineers inside of places like Sun or Masscomp was often difficult and we know was not well understood. USENIX was hardly the only firm/org that made some bets in those days that in the long run might not have been the best. As Ted referred, at the time a compromise was created. First, LISA became the primary sys admin conferences and was and still is successful. It has always had a good mix of both practice and academic papers. As Ted, pointed out things like FREENIX, USELINUX, ALS, and the like were created with a different set of requirements. In the end, conferences like these three fell out of favor. As someone that lived it at the time and argued to try to keep/invest in them, I personally think there was more a crash of personality as much as anything else. They were a lot more work for the USENIX staff to produce and that did not help the argument. And in 1988, USENIX itself had the gold as UNIX and the UNIX marketplace was at its height. I suspect some bad behavior did come through that favored one view over another. I personally think the org did attempt to do better in serving this population, but ultimately did not do as well as many people would have liked. As more and, more $s in the market moved into the FOSS community and away from what was then called the OpenSystems community, it allowed the folks in FOSS like yourself to be served by others than USENIX. IMHO, USENIX walked away from a group that they should have been trying to cultivate. I'll give Mad Dog and Ted creds for at least trying to educate that BOD in those days that what was being done/not done was not going to work for that community. The problem is that what was proposed (what was needed) did not fit the model that the BOD and the then ED had in mind. Given some of the personalities, folks (on both sides) stopped trying. A big problem (IMO) was that USELINUX and FREENIX needed a conference organization model more like the Hackers Conference or AMW, ... but ... the personalities running USENIX at the time understood the traditional (more academic) scheme. It was a failure to communicate at a minimum, and certainly had large portions of a control problem. So where we are today is that the freshwater is long since over the dam, and by now well mixed into the salted ocean. Replaying the acts and complaining of what should have happened is not going to help here. Unfortunately, it is true that the actions of some people in those days bruised some egos, and feelings were hurt. I wish that were not true, but I know it happened. The key for all of us, in this list and else where in the reset of the UNIX industry is to try to avoid rewriting history, but to understand what went down and accept it, and move on. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Tue Apr 6 06:34:45 2021 From: rich.salz at gmail.com (Richard Salz) Date: Mon, 5 Apr 2021 16:34:45 -0400 Subject: [TUHS] How to Kill a Technical Conference In-Reply-To: References: <20210401145025.GA1202@naleco.com> <20210404052939.xivuinlcugqb5zde@localhost.localdomain> <19643.1617646039@hop.toad.com> Message-ID: On Mon, Apr 5, 2021 at 3:32 PM Clem Cole wrote: > > The key for all of us, in this list and else where in the reset of the > UNIX industry is to try to avoid rewriting history, but to understand what > went down and accept it, and move on. > In that light, let's start a new thread: "My Favorite Usenix Papers." Change the subject line. No fair including one of your own on the list :) > ᐧ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Tue Apr 6 06:36:29 2021 From: rich.salz at gmail.com (Richard Salz) Date: Mon, 5 Apr 2021 16:36:29 -0400 Subject: [TUHS] My favorite Usenix papers Message-ID: Honeyman: "Pathalias, or the care and feeding of relative addresses" Ousterhout: "Why aren't operating systems getting faster as fast as hardware" -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Tue Apr 6 06:39:54 2021 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 5 Apr 2021 13:39:54 -0700 Subject: [TUHS] How to Kill a Technical Conference In-Reply-To: References: <20210404052939.xivuinlcugqb5zde@localhost.localdomain> <19643.1617646039@hop.toad.com> Message-ID: <20210405203954.GP28660@mcvoy.com> On Mon, Apr 05, 2021 at 03:30:25PM -0400, Clem Cole wrote: > On Mon, Apr 5, 2021 at 2:08 PM John Gilmore wrote: > > The paper was rejected by the program committee, on the objection that > > "ports aren't research". So > > the pro-academic, anti-engineering mindset was already in place back then. > IMHO, USENIX walked away from a group that they should have been > trying to cultivate. In 1999 I was program committee chair for Linux Expo which was trying to sort of be Usenix for Linux. I had been a paper reviewer for a number of Usenix conferences (I still have my review notes for those papers, I was a cocky pain in the ass that was full of myself, dunno why anyone put up with my nonsense but they did). I had the pleasure of reviewing this: http://mcvoy.com/lm/papers/rtlmanifesto.pdf The summary is Victor slipped a real time kernel underneath Linux and ran all of Linux, kernel and userspace, as the real time idle process. It worked fantastically well and was really clever. If you understand time sharing and you understand hard real time, trying to shovel hard real time into a time sharing system is like trying to prove 1 + 1 != 2. They are trying to do two completely different things and if you are good at one, you'll be bad at the other. Victor showed a way to have your cake and eat it too, it was brilliant. The paper was rejected and I believe it was partially because Victor wasn't well known in Unix circles, he wasn't "in the club". If Bill Joy had written the same paper I'm 100% sure it would have been published. Which lead to me campaigning for blind reviews. Back to Linux expo, it was a success, some of the papers weren't up to Usenix standards, but many of them were (I can dig up the proceedings if anyone cares). Whoever was running Usenix contacted me after seeing the success of Linux Expo and begged me to bring those people to Usenix. I was offered a board seat, I could be reviewer for life, anything I wanted. All I asked for was blind reviews. Didn't ask anything for myself, just blind reviews so you could be a nobody and get judged on the quaility of your work rather than your name. Apparently, I could get anything I wanted except that. I've had nothing to do with Usenix ever since. Clem came after whoever it was and has told me he cleaned things up quite a bit. If I had known him back then maybe I would have come back. From ches at cheswick.com Tue Apr 6 06:42:18 2021 From: ches at cheswick.com (William Cheswick) Date: Mon, 5 Apr 2021 16:42:18 -0400 Subject: [TUHS] How to Kill a Technical Conference In-Reply-To: References: <20210401145025.GA1202@naleco.com> <20210404052939.xivuinlcugqb5zde@localhost.localdomain> <19643.1617646039@hop.toad.com> Message-ID: <3F46E0C0-B9EE-4840-BE96-3DBEE1616623@cheswick.com> > On Apr 5, 2021, at 4:34 PM, Richard Salz wrote: > > No fair including one of your own on the list :) Why? You won’t let Whitten and Tygar name their own paper?! From kevin.bowling at kev009.com Tue Apr 6 06:44:26 2021 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Mon, 5 Apr 2021 13:44:26 -0700 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <584DED5A-1226-4AF7-A191-C34CAFA53686@pobox.com> <20210404022356.GR28660@mcvoy.com> <20210404085520.GA6494@naleco.com> Message-ID: On Sun, Apr 4, 2021 at 4:34 PM Clem Cole wrote: > > > > On Sun, Apr 4, 2021 at 7:01 PM Bakul Shah wrote: >> >> >> >> On Apr 4, 2021, at 3:25 PM, David Arnold wrote: >> >> For us UNIX historians, we need to be careful and learn from our own history here -- the Cell Phone/Mobile target is the engine for the next Christenian style disruption. It is by far the #1 target for people writing new programs (which I find a little sad personally - but I understand and accept -- time has marched on). In the end, a small mobile target will be the tech on top, and available will be driven by market behavior and those suppliers will be "who has the gold.” >> >> >> I feel I should point out that both the dominant mobile operating systems are Unix-hased. The UI is necessarily new, but astonishingly the 50 year old basic abstractions are the same. >> >> >> Except Unix is kind of hard to see. It wasn't just the hierarchical file system but the idea of composability. Even now we whip up a shell "one-liners" to perform some task we just thought of. All that is lost. And not just on mobile devices. For example search through email messages for something in an email "app". And no UI composability. We have to use extremely heavyweight IDEs such as X-Code weighing at 15GB (even "du -s /Application/X-code" takes tens of seconds!) to painstakingly construct a UI. We can't just whip up a dashboard to measure & display some realtime changing process/entity. There may be equally heavyweight third party tools but there has been no Bell Labs like research crew to distill it down to the essence of composable UI and ship it with every copy. The idea that users too can learn to "program" if given the right tools. > > > Exactly my point. The only difference I suspect is I just don't bother with the IDE (Xcode or VS). Frankly, vi/emacs, or as we discussed a few days ago, ed is still way more preferable when I'm programming. > > I mentioned in another email Intel's new development suite - OneAPI. Absolutely speaking for myself here, I am a bit at odds with management WRT to much of it, as I feel the direction is a bit miss guided. But I do understand why Intel is doing it/trying. Everyone in the industry seems to be saying "use my Framework, my language, my solution and I will solve your problem." "You will sell more copies of the program if you use my portal, etc." Intel to compete, needs to do the same things. To me, it seems a bit like fairy dust - a promise that will work for a set of people, and of course, some firms like my own employer will keep making money (or in the words of the Dr. Sueuss Lorax character: "Biggering and Biggering." As I said in the previous message, it is driven by the other golden rule. > > What I always felt made UNIX powerful was that it did not seem like the BTL folks were trying to sell anything. They were trying to solve real problems they and the folks at AT&T had when it came to realistically building and deploying systems. Yes, there were hidden from the profit motive at the time because of the unique rules of the 1956 consent degree and we all were winners because of it because they say -- sure here you can use it too. > > Now that we are back to a winner take all market, (OSVM/360 vs. VMS vs. winders ...) I think we have traded away designing for the sake of getting the job done properly, for designing to sell as many as possible (i.e. be sexy and capture a market, not be simple and do the job well). You guys are onto an interesting thread. If you have time read this https://danluu.com/essential-complexity/ . One thing I find interesting about this article is Dan, who externally seems at least a magnitude smarter and more productive than me, seems to miss that the approach he uses to debunk Brooks is largely a failure of design that probably predates his entry to the problem by layering ever more accidental complexity instead of solving the essential complexity. For instance, a circular buffer of arbitrary size (to the hardware and monetary constraints of his example) could be used to efficiently hold resource usage and drive important business or engineering decisions. A cascading set of buffers could be used to hold higher fidelity data at the top level and decreasing fidelity for longer time series intervals. It doesn't match his approach, which allows finding signal fidelity in extremely noisy data, but that's a problem of its own creation. The non-UNIX approach to things (IDEs, frameworks, big overlay APIs, microservices etc) definitely help with certain things people are willing to pay a lot of money for. However they lend themselves to creating and fixing ever more accidental complexity with ever more accidental complexity. I guess the thing we really like about UNIX, historically, was that it did a good job at exposing the programmer to the essential complexity. If you need to make things go fast, it's right there in your face. If you need to do resource accounting or just about any other task, there's a way to do it on fundamentally limited hardware. Big hardware and lots of people haven't made the essential complexity easier. UNIX, which was developed with discipline, still exerts a positive effect on the essential complexity in systems development when embraced. When not embraced, it becomes a liability (15GB Xcode). Regards, Kevin From tytso at mit.edu Tue Apr 6 07:11:35 2021 From: tytso at mit.edu (Theodore Ts'o) Date: Mon, 5 Apr 2021 17:11:35 -0400 Subject: [TUHS] How to Kill a Technical Conference In-Reply-To: <20210405203954.GP28660@mcvoy.com> References: <20210404052939.xivuinlcugqb5zde@localhost.localdomain> <19643.1617646039@hop.toad.com> <20210405203954.GP28660@mcvoy.com> Message-ID: On Mon, Apr 05, 2021 at 01:39:54PM -0700, Larry McVoy wrote: > Whoever was running Usenix contacted me after seeing the success of > Linux Expo and begged me to bring those people to Usenix. I was offered > a board seat, I could be reviewer for life, anything I wanted. > > All I asked for was blind reviews. Didn't ask anything for myself, just > blind reviews so you could be a nobody and get judged on the quaility of > your work rather than your name. FAST reviews are blind. ATC conferences are (as of the last time I was on an ATC PC a year or two ago) are still not blinded. - Ted From crossd at gmail.com Tue Apr 6 07:17:25 2021 From: crossd at gmail.com (Dan Cross) Date: Mon, 5 Apr 2021 17:17:25 -0400 Subject: [TUHS] How to Kill a Technical Conference In-Reply-To: References: <20210404052939.xivuinlcugqb5zde@localhost.localdomain> <19643.1617646039@hop.toad.com> <20210405203954.GP28660@mcvoy.com> Message-ID: On Mon, Apr 5, 2021 at 5:14 PM Theodore Ts'o wrote: > On Mon, Apr 05, 2021 at 01:39:54PM -0700, Larry McVoy wrote: > > Whoever was running Usenix contacted me after seeing the success of > > Linux Expo and begged me to bring those people to Usenix. I was offered > > a board seat, I could be reviewer for life, anything I wanted. > > > > All I asked for was blind reviews. Didn't ask anything for myself, just > > blind reviews so you could be a nobody and get judged on the quaility of > > your work rather than your name. > > FAST reviews are blind. ATC conferences are (as of the last time I > was on an ATC PC a year or two ago) are still not blinded. > Ok, I'll bite: why not? That seems like a no-brainer way to weed out a lot of bias. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chet.ramey at case.edu Tue Apr 6 07:24:24 2021 From: chet.ramey at case.edu (Chet Ramey) Date: Mon, 5 Apr 2021 17:24:24 -0400 Subject: [TUHS] My favorite Usenix papers In-Reply-To: References: Message-ID: <7f63c379-d39a-454f-6437-adc428d0948e@case.edu> On 4/5/21 4:36 PM, Richard Salz wrote: > Honeyman: "Pathalias, or the care and feeding of relative addresses" > Ousterhout: "Why aren't operating systems getting faster as fast as hardware" Agreed, these are both great. -- ``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 davida at pobox.com Tue Apr 6 08:26:30 2021 From: davida at pobox.com (David Arnold) Date: Tue, 6 Apr 2021 08:26:30 +1000 Subject: [TUHS] How to Kill a Technical Conference (was: Zombified SCO comes back from the dead, brings trial back to life against IBM) In-Reply-To: References: <20210401145025.GA1202@naleco.com> <20210404052939.xivuinlcugqb5zde@localhost.localdomain> Message-ID: <56470B32-2F79-4ADC-AC9C-D59F85009309@pobox.com> > On 6 Apr 2021, at 00:05, Theodore Ts'o wrote: > > A lot of the conflicts were over the writing style. There many ways > you can write papers. For example: > > (a) academic papers suitable for tenure-track publications > (b) technical industry paper meant for other industry practitioners > (c) white papers written by and for sales/marketing folks One reason you don’t get more of (b) at USENIX these days is that the value to writer is basically nil. Compare writing a USENIX conference paper with crafting a decent blog post: the latter gets immediate distribution, a flurry of comments and feedback from peers, and can often kick off new software projects, define new industry-wide nomenclature, to say nothing of the career benefits of building your professional “brand”. All the things a paper *used* to do, when people attended conferences and read papers as a means of information exchange. The pre-publication peer review process, and the annual (or longer) cadence means it’s just not the right venue for a fast-moving field, for the majority of topics. Sometimes, it makes sense to turn a successful blog post into a paper, to get some formal recognition, or to explore an idea more rigorously, but most of the time, things have moved on by then, and for an industrial worker (vs. academic), there’s very little incentive: you’re much better off getting another high-profile blog post than working through and writing up a paper. It’d be great to see USENIX rejoin this conversation as an essential forum, but it’s hard to see how: disintermediation has done its thing. d From m.douglas.mcilroy at dartmouth.edu Tue Apr 6 08:43:10 2021 From: m.douglas.mcilroy at dartmouth.edu (M Douglas McIlroy) Date: Mon, 5 Apr 2021 18:43:10 -0400 Subject: [TUHS] =?utf-8?q?=28no_subject=29?= Message-ID: > I had been debating leaving Usenix for several years already; > the move to soft copy ;login: clinched it for me. I have been a loyal nonmember of ACM ever since the CACM was converted from a journal to a magazine. Usenix didn't strike quite such a decisive blow when it abandoned Computing Systems. ;login: remains as a Cheshire grin. It remains to be seen whether I'll continue to scan it in its non-tactile form. Doug From mah at mhorton.net Tue Apr 6 09:23:00 2021 From: mah at mhorton.net (Mary Ann Horton) Date: Mon, 5 Apr 2021 16:23:00 -0700 Subject: [TUHS] Data structures in Unix editors In-Reply-To: References: Message-ID: <2f984847-0eb4-031b-5691-bc4311da1e47@mhorton.net> This is actually what ed, ex, and vi do as well, albeit not with a standard interface. The buffer is an array of integer offsets into a file. Line n in the buffer is pointed at by buffer[n], whose contents are an offset into the temp file. That offset points to a null terminated line of buffer text. When a new line of text is created (or changed) the new line is appended to the temp file and the corresponding offset goes into the buffer array. One big reason for this was that ed was originally written for a 16 bit machine, and buffers didn't fit in memory. This works very well to insert or delete lines, you only have to copy the line references in the buffer array. It's also convenient for undo, since putting things back just means restoring the original array. My enhanced ed (hed at Wisconsin, Portable ed at Bell Labs) had a second array for undo, and a full copy of the array was made before a change. Bill Joy wrote a fancier implementation in vi, where only lines added or deleted were saved, command-specific. Undo knew which command it had to undo and special-cased each one. The big disadvantage to this structure is that ends of lines are not just newline characters. You can't backspace over a newline, or change newlines to something else.     Mary Ann On 4/1/21 5:56 AM, Tony Finch wrote: > David C. Brock wrote: >> I’d like to read similar discussions of the data structures for ed, em, >> ex/vi. If anyone has suggestions of references, they would be very >> welcome! > A curious one is nvi, which uses the Berkeley DB RECNO interface to access > a text file as an array of lines (RECNO = record number). > > Tony. From lm at mcvoy.com Tue Apr 6 11:03:26 2021 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 5 Apr 2021 18:03:26 -0700 Subject: [TUHS] My favorite Usenix papers In-Reply-To: References: Message-ID: <20210406010326.GZ28660@mcvoy.com> On Mon, Apr 05, 2021 at 04:36:29PM -0400, Richard Salz wrote: > Honeyman: "Pathalias, or the care and feeding of relative addresses" > Ousterhout: "Why aren't operating systems getting faster as fast as > hardware" http://mcvoy.com/lm/papers/SunOS.nfs.pdf http://mcvoy.com/lm/papers/SunOS.shlib.pdf http://mcvoy.com/lm/papers/SunOS.tfs.pdf http://mcvoy.com/lm/papers/SunOS.vfs_arch.pdf http://mcvoy.com/lm/papers/SunOS.vm_arch.pdf http://mcvoy.com/lm/papers/SunOS.vm_impl.pdf http://mcvoy.com/lm/papers/porting-berkeley.pdf http://mcvoy.com/lm/papers/rtlmanifesto.pdf http://mcvoy.com/lm/papers/xfs.pdf From lm at mcvoy.com Tue Apr 6 12:30:56 2021 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 5 Apr 2021 19:30:56 -0700 Subject: [TUHS] My favorite Usenix papers In-Reply-To: <20210406010326.GZ28660@mcvoy.com> References: <20210406010326.GZ28660@mcvoy.com> Message-ID: <20210406023056.GC28660@mcvoy.com> Whoops: On Mon, Apr 05, 2021 at 06:03:26PM -0700, Larry McVoy wrote: > On Mon, Apr 05, 2021 at 04:36:29PM -0400, Richard Salz wrote: > > Honeyman: "Pathalias, or the care and feeding of relative addresses" > > Ousterhout: "Why aren't operating systems getting faster as fast as > > hardware" > > http://mcvoy.com/lm/papers/SunOS.nfs.pdf > http://mcvoy.com/lm/papers/SunOS.shlib.pdf > http://mcvoy.com/lm/papers/SunOS.tfs.pdf > http://mcvoy.com/lm/papers/SunOS.vfs_arch.pdf > http://mcvoy.com/lm/papers/SunOS.vm_arch.pdf > http://mcvoy.com/lm/papers/SunOS.vm_impl.pdf > http://mcvoy.com/lm/papers/porting-berkeley.pdf Usenix didn't take this, still a good paper > http://mcvoy.com/lm/papers/rtlmanifesto.pdf Usenix didn't take this, still a good paper > http://mcvoy.com/lm/papers/xfs.pdf -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From egbegb2 at gmail.com Tue Apr 6 14:37:09 2021 From: egbegb2 at gmail.com (Ed Bradford) Date: Mon, 5 Apr 2021 23:37:09 -0500 Subject: [TUHS] How to Kill a Technical Conference In-Reply-To: References: <20210401145025.GA1202@naleco.com> <20210404052939.xivuinlcugqb5zde@localhost.localdomain> <19643.1617646039@hop.toad.com> Message-ID: To old BTL or AT&T folks or anyone else who might know. I wonder. IBM introduced the IBM PC in August of 1981. That was years after a non-memory managed version of Unix was created by Heinze Lycklama, LSX. Is anyone on this list familiar with Bell Labs management thoughts on selling IBM on LSX rather than "dos"? While the anti-trust settlement was a couple years in the future, someone at AT&T must have been thinking about possibilities after a breakup. Ed On Mon, Apr 5, 2021 at 3:36 PM Richard Salz wrote: > > > On Mon, Apr 5, 2021 at 3:32 PM Clem Cole wrote: > >> >> The key for all of us, in this list and else where in the reset of the >> UNIX industry is to try to avoid rewriting history, but to understand what >> went down and accept it, and move on. >> > > In that light, let's start a new thread: "My Favorite Usenix Papers." > Change the subject line. No fair including one of your own on the list :) > >> ᐧ >> > -- Advice is judged by results, not by intentions. Cicero -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Tue Apr 6 15:49:02 2021 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 6 Apr 2021 15:49:02 +1000 (EST) Subject: [TUHS] How to Kill a Technical Conference In-Reply-To: <19643.1617646039@hop.toad.com> References: <20210401145025.GA1202@naleco.com> <20210404052939.xivuinlcugqb5zde@localhost.localdomain> <19643.1617646039@hop.toad.com> Message-ID: On Mon, 5 Apr 2021, John Gilmore wrote: > I'm an engineer, not an academic. [...] The paper was rejected by the > program committee, on the objection that "ports aren't research". This of course will come as news to those of us who had to port Unix to a different architecture... Especially when the hardware didn't work as documented :-( I think the most egregious example was DEC's Unibus; the specs were vague enough that 3rd-party cards wouldn't work (timing issues) so DEC could turn around and say that you ought to use our gear (which of course observed the undocumented precise timing). -- Dave From dave at horsfall.org Tue Apr 6 15:54:31 2021 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 6 Apr 2021 15:54:31 +1000 (EST) Subject: [TUHS] Whither Usenix [was How To Kill A Technical Conference] In-Reply-To: <202104051831.135IVKJS013930@freefriends.org> References: <20210405162050.DBFDD640CB7@lignose.oclsc.org> <202104051831.135IVKJS013930@freefriends.org> Message-ID: On Mon, 5 Apr 2021, arnold at skeeve.com wrote: > Yes, exactly. For me, Usenix provides little added value. I had been > debating leaving Usenix for several years already; the move to soft copy > ;login: clinched it for me. I'm not happy about it, but I had to > recognize my personal reality. I was not a member of Usenix; I was just a founding member (and past President) of AUUG, which decided to dissolve after we had done our job i.e. bring Unix to Australia. I used to enjoy reading the Usenix snippets in AUUGN, though. -- Dave From imp at bsdimp.com Tue Apr 6 16:01:13 2021 From: imp at bsdimp.com (Warner Losh) Date: Tue, 6 Apr 2021 00:01:13 -0600 Subject: [TUHS] Whither Usenix [was How To Kill A Technical Conference] In-Reply-To: References: <20210405162050.DBFDD640CB7@lignose.oclsc.org> <202104051831.135IVKJS013930@freefriends.org> Message-ID: On Mon, Apr 5, 2021 at 11:55 PM Dave Horsfall wrote: > On Mon, 5 Apr 2021, arnold at skeeve.com wrote: > > > Yes, exactly. For me, Usenix provides little added value. I had been > > debating leaving Usenix for several years already; the move to soft copy > > ;login: clinched it for me. I'm not happy about it, but I had to > > recognize my personal reality. > > I was not a member of Usenix; I was just a founding member (and past > President) of AUUG, which decided to dissolve after we had done our job > i.e. bring Unix to Australia. > > I used to enjoy reading the Usenix snippets in AUUGN, though. For some time, those were the only widely available surviving snippets of the early days of Usenix newsletters. Too bad copyright law severely limited what was published after the first few times. I've been quite impressed with the AUUGN having read almost all the early issues. It's quite the travel log of Unix coming to Australia and colonizing different niches. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Tue Apr 6 16:02:59 2021 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 6 Apr 2021 16:02:59 +1000 (EST) Subject: [TUHS] My favorite Usenix papers In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021, Richard Salz wrote: > Honeyman: "Pathalias, or the care and feeding of relative addresses" Are you sure that peter honeyman wrote "Pathalias" and not "pathalias"? He seemed to have an aversion to using his shift key. -- Dave From arnold at skeeve.com Tue Apr 6 17:23:18 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 06 Apr 2021 01:23:18 -0600 Subject: [TUHS] (no subject) In-Reply-To: References: Message-ID: <202104060723.1367NIFj020757@freefriends.org> M Douglas McIlroy wrote: > > I had been debating leaving Usenix for several years already; > > the move to soft copy ;login: clinched it for me. > > I have been a loyal nonmember of ACM ever since the CACM was > converted from a journal to a magazine. Usenix didn't strike quite > such a decisive blow when it abandoned Computing Systems. > ;login: remains as a Cheshire grin. It remains to be seen whether > I'll continue to scan it in its non-tactile form. > > Doug I know myself. When Linux Journal (for which I even wrote some articles) went soft-copy, I downloaded the files for over 2 years, but never bothered to read them, either on a computer or on my Kindle. Oh well. At least the threads here have been interesting reading. Arnold From norman at oclsc.org Wed Apr 7 01:15:27 2021 From: norman at oclsc.org (Norman Wilson) Date: Tue, 06 Apr 2021 11:15:27 -0400 Subject: [TUHS] (no printed copy) (was (no subject)) Message-ID: <1617722131.1272.for-standards-violators@oclsc.org> I'm not sure why people, even in a group devoted to history like ours, focus so much on whether a journal is issued in print or only electronically. The latter has become more and more common. On one hand, I too find that if something is available only electronically I'm more likely to put off reading it, probably because back issues don't pile up as visibly. On the other, in recent years I've been getting behind in my reading of periodicals of all sorts, and so far as I can tell that has nothing to do with whether a given periodical arrives on paper. If anything, electronic access makes it more likely I'll be able to catch up, because it's easier to carry a bunch of back issues around on a USB stick or loaded into a tablet or the like than to lug around lots of hardcopy. The biggest burden has been that imposed by PDF files, which are often carefully constructed to be appallingly cumbersome to read unless viewed on a letter-paper/A4-sized screen (or printed out). HTML used to be better, though the ninnies who design web pages to look like magazine ads have spoiled a lot of that over the years. Since I often want to read PDF files when travelling (e.g. conference proceedings while at the conference) I finally invested in a large-screened tablet. Even so, I have a big pile of back issues of ;login:, CACM (until ACM's policies, having little to do with the journal, recently drove me away), Rail Passenger Association News, and Consumer Reports waiting to be read. And sometimes I'm months behind on this list. My advice to those who find electronic-only publications cumbersome is to invest in either a good tablet or a good printer. I have and use both. There's no substitute for a large, high-quality screen, and sometimes there's no substitute for paper that I can flip back and forth, but I'm fine with supplying those myself. I'm still looking for a nice brass-bound leather tablet case, though. Norman Wilson Toronto ON From m.douglas.mcilroy at dartmouth.edu Wed Apr 7 01:35:22 2021 From: m.douglas.mcilroy at dartmouth.edu (M Douglas McIlroy) Date: Tue, 6 Apr 2021 11:35:22 -0400 Subject: [TUHS] PC Unix (had been How to Kill a Technical Conference Message-ID: > I wonder. IBM introduced the IBM PC in August of 1981. > That was years after a non-memory managed version of > Unix was created by Heinze Lycklama, LSX. Is anyone > on this list familiar with Bell Labs management thoughts > on selling IBM on LSX rather than "dos"? IBM famously failed to buy the well-established CP/M in 1980. (CP/M had been introduced in 1974, before the advent of the LSI-11 on which LSX ran.) By then IBM had settled on Basic and Intel. I do not believe they ever considered Unix and DEC, nor that AT&T considered selling to IBM. (AT&T had--fortunately--long since been rebuffed in an attempt to sell to DEC.) Doug From tytso at mit.edu Wed Apr 7 01:39:00 2021 From: tytso at mit.edu (Theodore Ts'o) Date: Tue, 6 Apr 2021 11:39:00 -0400 Subject: [TUHS] How to Kill a Technical Conference In-Reply-To: References: <20210404052939.xivuinlcugqb5zde@localhost.localdomain> <19643.1617646039@hop.toad.com> Message-ID: On Mon, Apr 05, 2021 at 03:30:25PM -0400, Clem Cole wrote: > > The issue for the USENIX BOD had always been getting butts in the seats to > pay the bills. Academics had a path, so following what IEEE and ACM did > was well-trod and understood. Get the more pure hackers like yourself, > even the engineers inside of places like Sun or Masscomp was often > difficult and we know was not well understood. USENIX was hardly the only > firm/org that made some bets in those days that in the long run might not > have been the best. In some ways, this was in large respect a great example of the innovator's dilemma. In the mid '90's, before the .com crash of '98, Unix sales were starting to trend down, but they were still quite respectable, and while Linux had a huge amount of buzz, a lot of that was because Linux was cheap as in beer --- which means that when it came down to the trade show floor revenues at an ATC conference event, Unix was still bringing in healthy amounts of $$$ at least as compared with Linux. And similarly, there were still some --- but not as many as before, during the "Golden Age" --- decent industry papers getting published at ATC. I sometimes suspect (although I have no proof of this) that one of the reasons why ATC papers were not double blinded ala FAST was because if there was an important paper from Sun, even if it didn't meet the high standards of a tenure-track conference, it was desirable to let a few such papers "slip through". For the most part, those industry papers were still better (from the let's not embarass the tenure-track professors) perspective than a typical Linux paper, but papers which were *really* not written to the academic style would certainly either get rejected, or there would be strong pressure placed on the writers to make them seem more "academic". Ultimately, ATC (with or without its USELINUX track) was trying to serve two masters, and while there were some techniques such as having invited talks track which worked at least moderately well, at the end of the day, if one of the goals of an attendee who happens to be a Linux developer is to be able to meet a critical mass of other Linux developers, it was always going to be hard for ATC to be able to serve that need as well as the needs of Usenix's other constiuents --- which were, after all, far more established within Usenix. - Ted From crossd at gmail.com Wed Apr 7 02:28:12 2021 From: crossd at gmail.com (Dan Cross) Date: Tue, 6 Apr 2021 12:28:12 -0400 Subject: [TUHS] My favorite Usenix papers In-Reply-To: References: Message-ID: On Tue, Apr 6, 2021 at 2:03 AM Dave Horsfall wrote: > On Mon, 5 Apr 2021, Richard Salz wrote: > > > Honeyman: "Pathalias, or the care and feeding of relative addresses" > > Are you sure that peter honeyman wrote "Pathalias" and not "pathalias"? > He seemed to have an aversion to using his shift key. > He actually wrote it as, "PATHALIAS _or_ The Care and Feeding of Relative Addresses". Plenty of shift to go around. :-) - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Apr 7 03:09:31 2021 From: clemc at ccc.com (Clem Cole) Date: Tue, 6 Apr 2021 13:09:31 -0400 Subject: [TUHS] PC Unix (had been How to Kill a Technical Conference In-Reply-To: References: Message-ID: Doug -- IIRC IBM private-labeled a Microsoft put out a version of Xenix, although I think it required an PC/AT (286) ᐧ On Tue, Apr 6, 2021 at 11:36 AM M Douglas McIlroy < m.douglas.mcilroy at dartmouth.edu> wrote: > > I wonder. IBM introduced the IBM PC in August of 1981. > > That was years after a non-memory managed version of > > Unix was created by Heinze Lycklama, LSX. Is anyone > > on this list familiar with Bell Labs management thoughts > > on selling IBM on LSX rather than "dos"? > > IBM famously failed to buy the well-established CP/M in > 1980. (CP/M had been introduced in 1974, before the > advent of the LSI-11 on which LSX ran.) By then IBM had > settled on Basic and Intel. I do not believe they ever > considered Unix and DEC, nor that AT&T considered > selling to IBM. (AT&T had--fortunately--long since been > rebuffed in an attempt to sell to DEC.) > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sauer at technologists.com Wed Apr 7 03:32:35 2021 From: sauer at technologists.com (Charles H Sauer) Date: Tue, 6 Apr 2021 12:32:35 -0500 Subject: [TUHS] PC Unix (had been How to Kill a Technical Conference In-Reply-To: References: Message-ID: <04e60d98-22e3-acb5-686f-93af1f7e2825@technologists.com> For much of my last few years at IBM, my uucp machine, ibmchs, was an AT running Xenix, probably that version of Xenix. On 4/6/2021 12:09 PM, Clem Cole wrote: > Doug -- IIRC IBM private-labeled a Microsoft put out a version of Xenix, > although I think it required an PC/AT (286) > ᐧ > > On Tue, Apr 6, 2021 at 11:36 AM M Douglas McIlroy > > wrote: > > > I wonder. IBM introduced the IBM PC in August of 1981. > > That was years after a non-memory managed version of > > Unix was created by Heinze Lycklama,  LSX. Is anyone > > on this list familiar with Bell Labs management thoughts > > on  selling IBM on LSX rather than "dos"? > > IBM famously failed to buy the well-established CP/M in > 1980. (CP/M had been introduced in 1974, before the > advent of the LSI-11 on which LSX ran.) By then IBM had > settled on Basic and Intel.  I do not believe they ever > considered Unix and DEC, nor that AT&T considered > selling to IBM. (AT&T had--fortunately--long since been > rebuffed in an attempt to sell to DEC.) > > Doug > -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Skype/Twitter: CharlesHSauer From norman at oclsc.org Wed Apr 7 03:40:26 2021 From: norman at oclsc.org (Norman Wilson) Date: Tue, 06 Apr 2021 13:40:26 -0400 Subject: [TUHS] My favorite Usenix papers Message-ID: <1617730830.2746.for-standards-violators@oclsc.org> Rich Salz: > > Honeyman: "Pathalias, or the care and feeding of relative addresses" Dave Horsfall: > Are you sure that peter honeyman wrote "Pathalias" and not "pathalias"? > He seemed to have an aversion to using his shift key. Dan Cross: He actually wrote it as, "PATHALIAS _or_ The Care and Feeding of Relative Addresses". Plenty of shift to go around. :-) ==== Peter probably had a graduate student hold the caps key for him. Norman Wilson Toronto ON Used to honey bitching From pepe at naleco.com Wed Apr 7 06:11:19 2021 From: pepe at naleco.com (Josh Good) Date: Tue, 6 Apr 2021 22:11:19 +0200 Subject: [TUHS] PC Unix (had been How to Kill a Technical Conference In-Reply-To: <04e60d98-22e3-acb5-686f-93af1f7e2825@technologists.com> References: <04e60d98-22e3-acb5-686f-93af1f7e2825@technologists.com> Message-ID: <20210406201118.GA3953@naleco.com> On 2021 Apr 6, 12:32, Charles H Sauer wrote: > For much of my last few years at IBM, my uucp machine, ibmchs, was an AT > running Xenix, probably that version of Xenix. Hi. I'm curious about that Xenix vintage. How did you use that machine: headless from a serial terminal?, or at the VGA console? Was it "single user" or shared among several people? Did you run Xenix and only SCO provided software, or did you had third party software in it? Were you using it by choice as your favourite Unix, or merely because it was the only Unix you could have? Did you like living with Xenix? Did it have problems, o was it "setup and forget"? If you feel like sharing that experience, thank you very much. -- Josh Good From gerberb at zenez.com Wed Apr 7 06:20:33 2021 From: gerberb at zenez.com (Boyd Lynn Gerber) Date: Tue, 6 Apr 2021 14:20:33 -0600 Subject: [TUHS] PC Unix (had been How to Kill a Technical Conference In-Reply-To: References: Message-ID: On Tuesday 2021-04-06 13:09, Clem Cole wrote: > Doug -- IIRC IBM private-labeled a Microsoft put out a version of Xenix, > although I think it required an PC/AT (286) I had the SCO Xeinx 286 version. It was OK, but lacked a lot of features. I ran it on the Sperry IT macine. I think was there equivealant machine tot the IBM AT. -- Boyd Gerber 801 849-0213 ZENEZ 1042 East Fort Union #135, Midvale Utah 84047 From jcapp at anteil.com Wed Apr 7 06:26:52 2021 From: jcapp at anteil.com (Jim Capp) Date: Tue, 6 Apr 2021 15:26:52 -0500 (EST) Subject: [TUHS] PC Unix (had been How to Kill a Technical Conference In-Reply-To: <20210406201118.GA3953@naleco.com> Message-ID: <12445917.1513.1617740812263.JavaMail.root@zimbraanteil> Josh, At the time (1982-83), Xenix was the only Unix available to me. By 1984, we upgraded to a full-fledged NCR 1632 system, with Unix SVR4. Installation was through a VGA console and after it was up and running, you could add serial terminals to your heart's content. We mostly wrote our own software, but had productivity packages for word processing, spreadsheets, and databases (non-SQL). Xenix was my first experience with *nix. I "caught the bug" and have been working with *nix ever since. Cheers, Jim From: "Josh Good" To: tuhs at minnie.tuhs.org Sent: Tuesday, April 6, 2021 4:11:19 PM Subject: Re: [TUHS] PC Unix (had been How to Kill a Technical Conference On 2021 Apr 6, 12:32, Charles H Sauer wrote: > For much of my last few years at IBM, my uucp machine, ibmchs, was an AT > running Xenix, probably that version of Xenix. Hi. I'm curious about that Xenix vintage. How did you use that machine: headless from a serial terminal?, or at the VGA console? Was it "single user" or shared among several people? Did you run Xenix and only SCO provided software, or did you had third party software in it? Were you using it by choice as your favourite Unix, or merely because it was the only Unix you could have? Did you like living with Xenix? Did it have problems, o was it "setup and forget"? If you feel like sharing that experience, thank you very much. -- Josh Good -------------- next part -------------- An HTML attachment was scrubbed... URL: From sauer at technologists.com Wed Apr 7 06:47:35 2021 From: sauer at technologists.com (Charles H Sauer) Date: Tue, 6 Apr 2021 15:47:35 -0500 Subject: [TUHS] PC Unix (had been How to Kill a Technical Conference In-Reply-To: <12445917.1513.1617740812263.JavaMail.root@zimbraanteil> References: <12445917.1513.1617740812263.JavaMail.root@zimbraanteil> Message-ID: To try to answer Josh's questions: - I used the machine from console, certainly pre-VGA, probably CGA - I don't recall anyone else using it directly - The primary purpose was uucp for mail and news, dialing into machines at UT-Austin - I can't imagine having anything on it besides what was needed for mail and news - my primary focus was AIX at the time, but hardware for AIX was scarce (https://notes.technologists.com/notes/2017/03/08/lets-start-at-the-very-beginning-801-romp-rtpc-aix-versions/) -- after I got an RT in my office, and, eventually, at home, the Xenix machine persisted for uucp, IIRC - my memory was that the AT & Xenix were ok for the intended purpose - I remember a friend questioning whether the AT was really adequate for 9600 baud uucp, but I don't recall having problems with that - it looks like someone kept it in place after I left IBM in 1989, since http://web.mit.edu/kolya/sipb/afs/root.afs/athena.mit.edu/reference/net-directory/maps/uucp.bak/u.usa.tx.4 lists it in 1991 Charlie On 4/6/2021 3:26 PM, Jim Capp wrote: > Josh, > > At the time (1982-83), Xenix was the only Unix available to me.  By > 1984, we upgraded to a full-fledged NCR 1632 system, with Unix SVR4. > > Installation was through a VGA console and after it was up and running, > you could add serial terminals to your heart's content. > > We mostly wrote our own software, but had productivity packages for word > processing, spreadsheets, and databases (non-SQL). > > Xenix was my first experience with *nix.  I "caught the bug" and have > been working with *nix ever since. > > Cheers, > > Jim > > > ------------------------------------------------------------------------ > *From: *"Josh Good" > *To: *tuhs at minnie.tuhs.org > *Sent: *Tuesday, April 6, 2021 4:11:19 PM > *Subject: *Re: [TUHS] PC Unix (had been How to Kill a Technical Conference > > On 2021 Apr  6, 12:32, Charles H Sauer wrote: > > For much of my last few years at IBM, my uucp machine, ibmchs, was an AT > > running Xenix, probably that version of Xenix. > > Hi. I'm curious about that Xenix vintage. How did you use that machine: > headless from a serial terminal?, or at the VGA console? Was it "single > user" or shared among several people? Did you run Xenix and only SCO > provided software, or did you had third party software in it? Were you > using it by choice as your favourite Unix, or merely because it was the > only Unix you could have? Did you like living with Xenix? Did it have > problems, o was it "setup and forget"? > > If you feel like sharing that experience, thank you very much. > > -- > Josh Good > -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Skype/Twitter: CharlesHSauer From clemc at ccc.com Wed Apr 7 07:06:03 2021 From: clemc at ccc.com (Clem Cole) Date: Tue, 6 Apr 2021 17:06:03 -0400 Subject: [TUHS] PC Unix (had been How to Kill a Technical Conference In-Reply-To: <20210406201118.GA3953@naleco.com> References: <04e60d98-22e3-acb5-686f-93af1f7e2825@technologists.com> <20210406201118.GA3953@naleco.com> Message-ID: Like a lot of things, it depends. In the early 80s, they tried to break the 'small' computer market that had been using minis like PDP-11s or DG Novas. A saw a lot of small installations at places like car dealerships and repair houses. You strapped a cheap terminal [Wyse 25/50/60/75 were very popular]. My local Chinese restaurant still runs with 3 Wyse 60s talking to something in the back. It used to be a Wyse 386:16 running Xenix. As Charlie said he ran a UUCP server on one. Someone (3COM maybe) added an ethernet and an 8/16 line serial board like the Rocket Board (which I think I may still have one around) and sold them as terminal servers. to larger systems. A few things happen --- the 68000 style machines such as Masscomp, Apollo, and Sun could do the same thing much better and were not much different in price (remember an original PC/AT 286 with max memory and DOS cost $5K at computerland and it was another $1k for Xenix plus whatever the app cost). Compaq was cheaper but not much. A diskless Sun3 was 7.5K also, but you needed at least one full Sun3 to be the server (and they also sucked, most people bought add-in disk Unix for another 4K -- another good story for another time]. The Apps cost the same between Xenix and Sun and that sort of sealed the deal, particularly when the apps moved to DOS and then were cheaper still. So if you wanted a timing sharing box there were options that were in the same price range and basically 'better' AND IBM/Compaq started to push DOS and that ecosystem which was cheaper. ᐧ On Tue, Apr 6, 2021 at 4:12 PM Josh Good wrote: > On 2021 Apr 6, 12:32, Charles H Sauer wrote: > > For much of my last few years at IBM, my uucp machine, ibmchs, was an AT > > running Xenix, probably that version of Xenix. > > Hi. I'm curious about that Xenix vintage. How did you use that machine: > headless from a serial terminal?, or at the VGA console? Was it "single > user" or shared among several people? Did you run Xenix and only SCO > provided software, or did you had third party software in it? Were you > using it by choice as your favourite Unix, or merely because it was the > only Unix you could have? Did you like living with Xenix? Did it have > problems, o was it "setup and forget"? > > If you feel like sharing that experience, thank you very much. > > -- > Josh Good > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Wed Apr 7 08:41:21 2021 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 7 Apr 2021 08:41:21 +1000 (EST) Subject: [TUHS] PC Unix (had been How to Kill a Technical Conference In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021, M Douglas McIlroy wrote: > IBM famously failed to buy the well-established CP/M in 1980. (CP/M had > been introduced in 1974, before the advent of the LSI-11 on which LSX > ran.) [...] And unlike the popular urban myth, Gary Kildall was not out playing golf when IBM tried to contact him. -- Dave From dave at horsfall.org Wed Apr 7 09:25:53 2021 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 7 Apr 2021 09:25:53 +1000 (EST) Subject: [TUHS] (no subject) In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021, M Douglas McIlroy wrote: > I have been a loyal nonmember of ACM ever since the CACM was converted > from a journal to a magazine. Usenix didn't strike quite such a decisive > blow when it abandoned Computing Systems. ;login: remains as a Cheshire > grin. It remains to be seen whether I'll continue to scan it in its > non-tactile form. I quit the ACM when they jacked up their fees to the point of being unaffordable (and refused to justify it when asked); that, and they were no longer relevant since I stopped working in academia and went to industry instead. Same story with ACS and IEEE (although they made for useful tax deductions). -- Dave From jsteve at superglobalmegacorp.com Wed Apr 7 10:59:54 2021 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Wed, 7 Apr 2021 08:59:54 +0800 Subject: [TUHS] PC Unix (had been How to Kill a Technical Conference Message-ID: <0F0B9BFC06289346B88512B91E55670D3011@EXCHANGE> There is some information and demos of the early 8086/80286 Xenix, including the IBM rebranded PC Xenix 1.0 on pcjs.org https://www.pcjs.org/software/pcx86/sys/unix/ibm/xenix/1.0/ And if you have a modern enough browser you can run them from the browser as well! It's amazing that CPU's are fast enough to run interpreted emulation that is faster than the old machines of the day. -----Original Message----- From: Clem Cole To: M Douglas McIlroy Cc: TUHS main list Sent: 4/7/21 1:09 AM Subject: Re: [TUHS] PC Unix (had been How to Kill a Technical Conference Doug -- IIRC IBM private-labeled a Microsoft put out a version of Xenix, although I think it required an PC/AT (286) ? On Tue, Apr 6, 2021 at 11:36 AM M Douglas McIlroy < m.douglas.mcilroy at dartmouth.edu > wrote: > I wonder. IBM introduced the IBM PC in August of 1981. > That was years after a non-memory managed version of > Unix was created by Heinze Lycklama, LSX. Is anyone > on this list familiar with Bell Labs management thoughts > on selling IBM on LSX rather than "dos"? IBM famously failed to buy the well-established CP/M in 1980. (CP/M had been introduced in 1974, before the advent of the LSI-11 on which LSX ran.) By then IBM had settled on Basic and Intel. I do not believe they ever considered Unix and DEC, nor that AT&T considered selling to IBM. (AT&T had--fortunately--long since been rebuffed in an attempt to sell to DEC.) Doug From jon at fourwinds.com Wed Apr 7 11:01:49 2021 From: jon at fourwinds.com (Jon Steinhart) Date: Tue, 06 Apr 2021 18:01:49 -0700 Subject: [TUHS] (no subject) In-Reply-To: References: Message-ID: <202104070101.13711odS223692@darkstar.fourwinds.com> Dave Horsfall writes: > I quit the ACM when they jacked up their fees to the point of being > unaffordable (and refused to justify it when asked); that, and they were > no longer relevant since I stopped working in academia and went to > industry instead. > > Same story with ACS and IEEE (although they made for useful tax > deductions). Same thing happened to me. I was really annoyed by their refusal to allow the purchase of any of the digital library for offline use because I have such crappy internet service here. Just wanted to have access to stuff that I had already purchased so that I could get rid of the paper copies. The final straw was when being a SIGGRAPH member stopped including the proceedings. Last of my old CACM and proceedings of the IEEE went out recycling today. BTW, as part of my dodsstada project I have found extra copies of the 1992, 1993, 1997, 2000, 2001, 2002, and 2003 SIGGRAPH proceedings if anybody wants 'em. Jon From jon at fourwinds.com Wed Apr 7 11:10:48 2021 From: jon at fourwinds.com (Jon Steinhart) Date: Tue, 06 Apr 2021 18:10:48 -0700 Subject: [TUHS] PC Unix (had been How to Kill a Technical Conference In-Reply-To: References: Message-ID: <202104070110.1371AmUi223995@darkstar.fourwinds.com> Dave Horsfall writes: > And unlike the popular urban myth, Gary Kildall was not out playing golf > when IBM tried to contact him. The myth that I had always heard was that he was out flying his airplane. I asked Tom Rolander about it a few years ago, and it turns out that it is true but misleading; he was coming back from a customer visit, not goofing off. Another thing that Tom told me was that the reason that DRI didn't sign with IBM was that IBM wanted "we own all your stuff and you have liability for everything" terms. DRI wasn't willing to do that because they had a real business; Gates had nothing and therefore had nothing to lose. IBM was pretty heavy-handed. A while ago a kid that I mentored asked me to review an NDA that IBM wanted him to sign for a summer internship. It defined confidential material as "anything that is being done, has ever been done, or is being contemplated by IBM, any of its subsidiaries or assigns". I told him not to sign it unless they were willing to add "that we make you aware of" because there was probably nobody at IBM who knew all of that. So he went to Mozilla for the summer instead, got jazzed about open source, and made a good contribution. Then, his company was purchased by Red Hat and then by IBM, so I guess one can't escape. Jon From heinz at osta.com Wed Apr 7 10:58:24 2021 From: heinz at osta.com (heinz at osta.com) Date: Tue, 06 Apr 2021 17:58:24 -0700 Subject: [TUHS] PC Unix (had been How to Kill a Technical Conference In-Reply-To: <04e60d98-22e3-acb5-686f-93af1f7e2825@technologists.com> References: <04e60d98-22e3-acb5-686f-93af1f7e2825@technologists.com> Message-ID: I developed LSX at Bell Labs in Murray Hill NJ in the 1974-1975 timeframe. An existing C compiler made it possible without too much effort. The UNIX source was available to Universities by then. I also developed Mini-UNIX for the PDP11/10 (also no memory protection) in the 1976 timeframe. This source code was also made available to Universities, but the source code for LSX was not. Peter Weiner, the founder of INTERACTIVE Systems Corp.(ISC) in June 1977, the first commercial company to license UNIX source from Western Electric for $20,000. Binary licenses were available at the same time. I joined ISC in May of 1978 when ISC was the first company to offer UNIX support services to third parties. There was never any talk about licensing UNIX source code from Western Electric (WE) from the founding of ISC to when the Intel 8086 micro became available in 1981. DEC never really targeted the PC market with the LSI-11 micro, and WE never made it easy to license binary copies of the UNIX source code, So LSX never really caught on in the commercial market. ISC was in the business of porting the UNIX source code to other computers, micro to mainframe, as new computer architectures were developed. Heinz On 2021-04-06 10:32, Charles H Sauer wrote: > For much of my last few years at IBM, my uucp machine, ibmchs, was an > AT running Xenix, probably that version of Xenix. > > On 4/6/2021 12:09 PM, Clem Cole wrote: >> Doug -- IIRC IBM private-labeled a Microsoft put out a version of >> Xenix, although I think it required an PC/AT (286) >> ᐧ >> >> On Tue, Apr 6, 2021 at 11:36 AM M Douglas McIlroy >> > > wrote: >> >> > I wonder. IBM introduced the IBM PC in August of 1981. >> > That was years after a non-memory managed version of >> > Unix was created by Heinze Lycklama,  LSX. Is anyone >> > on this list familiar with Bell Labs management thoughts >> > on  selling IBM on LSX rather than "dos"? >> >> IBM famously failed to buy the well-established CP/M in >> 1980. (CP/M had been introduced in 1974, before the >> advent of the LSI-11 on which LSX ran.) By then IBM had >> settled on Basic and Intel.  I do not believe they ever >> considered Unix and DEC, nor that AT&T considered >> selling to IBM. (AT&T had--fortunately--long since been >> rebuffed in an attempt to sell to DEC.) >> >> Doug >> From imp at bsdimp.com Wed Apr 7 11:37:14 2021 From: imp at bsdimp.com (Warner Losh) Date: Tue, 6 Apr 2021 19:37:14 -0600 Subject: [TUHS] PC Unix (had been How to Kill a Technical Conference In-Reply-To: References: <04e60d98-22e3-acb5-686f-93af1f7e2825@technologists.com> Message-ID: On Tue, Apr 6, 2021 at 7:31 PM wrote: > I developed LSX at Bell Labs in Murray Hill NJ in the 1974-1975 > timeframe. > An existing C compiler made it possible without too much effort. The > UNIX > source was available to Universities by then. I also developed Mini-UNIX > for the PDP11/10 (also no memory protection) in the 1976 timeframe. > This source code was also made available to Universities, but the source > code for LSX was not. > > Peter Weiner, the founder of INTERACTIVE Systems Corp.(ISC) in June > 1977, > the first commercial company to license UNIX source from Western > Electric for $20,000. Binary licenses were available at the same time. > I joined ISC in May of 1978 when ISC was the first company to offer > UNIX support services to third parties. There was never any talk about > licensing UNIX source code from Western Electric (WE) from the founding > of ISC to when the Intel 8086 micro became available in 1981. > DEC never really targeted the PC market with the LSI-11 micro, > and WE never made it easy to license binary copies of the UNIX > source code, So LSX never really caught on in the commercial market. > ISC was in the business of porting the UNIX source code to other > computers, micro to mainframe, as new computer architectures > were developed. > As the author of LSX and MiniUnix, are you aware of anybody porting them to another non PDP-11 architecture? ISC didn't do that at all, but maybe you heard of something through the years? Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Wed Apr 7 11:47:42 2021 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Wed, 7 Apr 2021 11:47:42 +1000 Subject: [TUHS] PC Unix (had been How to Kill a Technical Conference In-Reply-To: <202104070110.1371AmUi223995@darkstar.fourwinds.com> References: <202104070110.1371AmUi223995@darkstar.fourwinds.com> Message-ID: <20210407014742.GA32218@eureka.lemis.com> On Tuesday, 6 April 2021 at 18:10:48 -0700, Jon Steinhart wrote: > Dave Horsfall writes: >> And unlike the popular urban myth, Gary Kildall was not out playing golf >> when IBM tried to contact him. > > The myth that I had always heard was that he was out flying his airplane. > I asked Tom Rolander about it a few years ago, and it turns out that it > is true but misleading; he was coming back from a customer visit, not > goofing off. Another hypothesis I had ties in with this: both he and Bill Gates were speakers at Euromicro 1980 in London, from 16 to 18 September. Bill Gates was a no-show. Would that fit in with Gary's "gone flying"? Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From jon at fourwinds.com Wed Apr 7 11:49:31 2021 From: jon at fourwinds.com (Jon Steinhart) Date: Tue, 06 Apr 2021 18:49:31 -0700 Subject: [TUHS] PC Unix (had been How to Kill a Technical Conference In-Reply-To: <20210407014742.GA32218@eureka.lemis.com> References: <202104070110.1371AmUi223995@darkstar.fourwinds.com> <20210407014742.GA32218@eureka.lemis.com> Message-ID: <202104070149.1371nVin226024@darkstar.fourwinds.com> Greg 'groggy' Lehey writes: > > Another hypothesis I had ties in with this: both he and Bill Gates > were speakers at Euromicro 1980 in London, from 16 to 18 September. > Bill Gates was a no-show. Would that fit in with Gary's "gone > flying"? > > Greg According to Tom, no, he was visiting a somewhat local customer, I think in the bay area, which is why he was flying his plane. This wasn't the modern times when CEOs owned fancy jets. From athornton at gmail.com Wed Apr 7 11:52:02 2021 From: athornton at gmail.com (Adam Thornton) Date: Tue, 6 Apr 2021 18:52:02 -0700 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: References: <584DED5A-1226-4AF7-A191-C34CAFA53686@pobox.com> <20210404022356.GR28660@mcvoy.com> Message-ID: Fortunately, we were once again saved from a monoculture by....mobile phones. Now it has to run on Linux on x86_64 *and* arm64. And because Apple has managed to nail down its brand as The Lifestyle Phone For Rich People, it also has to build in a vaguely-BSD userland for arm (disclaimer: writing this on an M1 Macbook Air, with an iPhone beside me on my desk--but all my real work happens on Linux/x86_64 on Someone Else's Computer, usually Google's but sometimes Amazon's or NCSA's). Adam On Mon, Apr 5, 2021 at 6:46 AM Theodore Ts'o wrote: > On Sat, Apr 03, 2021 at 07:23:56PM -0700, Larry McVoy wrote: > > > > I'm the biggest SunOS 4.x fan boy and I agree. It was ~30 years ago. > > Back then, all the open source stuff, or closed source stuff, took a > > ton of work to make it work. It just worked on SunOS. I can't tell > > you how many times I've brought up X10 or X11 on all sorts of systems > > (it was a good learning experience, you learned to figure out that this > > is part of my graphics card, this and that and that and that is not, > > just ifdef that out and keep going). > > To be fair, a lot of that was because there's a lot of crappy > userspace software out there who assumed that all the world's a Sun > (running SunOS). Previously it was Vax running BSD 4.x, and it's been > superceded these days with "all the world's Linux (running on x86_64)". > > I'm a big Linux fan boy, but that doesn't blind me to the fact that > that there's a lot of cr*p that uses slow, maddening autoconf and > automake build systems, yet have so many Linux'isms in it that won't > build anywhere else. > > The fact that a lot of software easily brings up on a particular OS > doesn't mean that it's inherently better; just that it has the > dominant mindshare. > > - Ted > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Wed Apr 7 11:58:27 2021 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 6 Apr 2021 18:58:27 -0700 Subject: [TUHS] PC Unix (had been How to Kill a Technical Conference In-Reply-To: <202104070149.1371nVin226024@darkstar.fourwinds.com> References: <202104070110.1371AmUi223995@darkstar.fourwinds.com> <20210407014742.GA32218@eureka.lemis.com> <202104070149.1371nVin226024@darkstar.fourwinds.com> Message-ID: <20210407015827.GG28660@mcvoy.com> On Tue, Apr 06, 2021 at 06:49:31PM -0700, Jon Steinhart wrote: > Greg 'groggy' Lehey writes: > > > > Another hypothesis I had ties in with this: both he and Bill Gates > > were speakers at Euromicro 1980 in London, from 16 to 18 September. > > Bill Gates was a no-show. Would that fit in with Gary's "gone > > flying"? > > > > Greg > > According to Tom, no, he was visiting a somewhat local customer, I > think in the bay area, which is why he was flying his plane. This > wasn't the modern times when CEOs owned fancy jets. Yeah, I went and looked, it was a small $5M/year (not that small) business and for some reason he was delivering software with his small plane. From egbegb2 at gmail.com Wed Apr 7 12:30:28 2021 From: egbegb2 at gmail.com (Ed Bradford) Date: Tue, 6 Apr 2021 21:30:28 -0500 Subject: [TUHS] PC Unix (had been How to Kill a Technical Conference In-Reply-To: <04e60d98-22e3-acb5-686f-93af1f7e2825@technologists.com> References: <04e60d98-22e3-acb5-686f-93af1f7e2825@technologists.com> Message-ID: What year was this, Charles? Ed On Tue, Apr 6, 2021 at 12:33 PM Charles H Sauer wrote: > For much of my last few years at IBM, my uucp machine, ibmchs, was an AT > running Xenix, probably that version of Xenix. > > On 4/6/2021 12:09 PM, Clem Cole wrote: > > Doug -- IIRC IBM private-labeled a Microsoft put out a version of Xenix, > > although I think it required an PC/AT (286) > > ᐧ > > > > On Tue, Apr 6, 2021 at 11:36 AM M Douglas McIlroy > > > > wrote: > > > > > I wonder. IBM introduced the IBM PC in August of 1981. > > > That was years after a non-memory managed version of > > > Unix was created by Heinze Lycklama, LSX. Is anyone > > > on this list familiar with Bell Labs management thoughts > > > on selling IBM on LSX rather than "dos"? > > > > IBM famously failed to buy the well-established CP/M in > > 1980. (CP/M had been introduced in 1974, before the > > advent of the LSI-11 on which LSX ran.) By then IBM had > > settled on Basic and Intel. I do not believe they ever > > considered Unix and DEC, nor that AT&T considered > > selling to IBM. (AT&T had--fortunately--long since been > > rebuffed in an attempt to sell to DEC.) > > > > Doug > > > > -- > voice: +1.512.784.7526 e-mail: sauer at technologists.com > fax: +1.512.346.5240 Web: https://technologists.com/sauer/ > Facebook/Google/Skype/Twitter > : > CharlesHSauer > -- Advice is judged by results, not by intentions. Cicero -------------- next part -------------- An HTML attachment was scrubbed... URL: From sburjak at systech.com.au Wed Apr 7 12:31:55 2021 From: sburjak at systech.com.au (Serge Burjak) Date: Wed, 7 Apr 2021 12:31:55 +1000 Subject: [TUHS] PC Unix (had been How to Kill a Technical Conference In-Reply-To: <20210407015827.GG28660@mcvoy.com> References: <202104070110.1371AmUi223995@darkstar.fourwinds.com> <20210407014742.GA32218@eureka.lemis.com> <202104070149.1371nVin226024@darkstar.fourwinds.com> <20210407015827.GG28660@mcvoy.com> Message-ID: Serial port performance did not scale well on early pcs, so an industry was grown with smart serial cards. There were a few serial cards, but most didn't have the smarts, just shared interrupts. Best performing, in my usage, was the Stallion brand, an Australian company. These cards had their own processor, uarts and ram. Had used 4-32 ports. I am guessing they did high speed transfers via the high speed bus on the PC, relieving the main CPU from getting interrupts, doing queuing, caching etc. These cards were supported by SCO products like Xenix and Unix, some others and ran on a PC. Flying aircraft could be efficient for some visits that didn't have direct city pairs served by airlines, especially the US. Plus a lot of fun, if you do it yourself. I used to push statistical and financial data around Australia in the 80s via dial up using automated scripting with Zmodem, Sun hosts, PC remotes. Was very reliable. IBM NDAs and legals can feel overwhelming in meetings.... Serge On Wed, 7 Apr 2021 at 11:59, Larry McVoy wrote: > On Tue, Apr 06, 2021 at 06:49:31PM -0700, Jon Steinhart wrote: > > Greg 'groggy' Lehey writes: > > > > > > Another hypothesis I had ties in with this: both he and Bill Gates > > > were speakers at Euromicro 1980 in London, from 16 to 18 September. > > > Bill Gates was a no-show. Would that fit in with Gary's "gone > > > flying"? > > > > > > Greg > > > > According to Tom, no, he was visiting a somewhat local customer, I > > think in the bay area, which is why he was flying his plane. This > > wasn't the modern times when CEOs owned fancy jets. > > Yeah, I went and looked, it was a small $5M/year (not that small) > business and for some reason he was delivering software with his > small plane. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sauer at technologists.com Wed Apr 7 12:44:41 2021 From: sauer at technologists.com (Charles H. Sauer) Date: Tue, 6 Apr 2021 21:44:41 -0500 Subject: [TUHS] PC Unix (had been How to Kill a Technical Conference In-Reply-To: References: <04e60d98-22e3-acb5-686f-93af1f7e2825@technologists.com> Message-ID: <10F81A21-AC7A-4644-A988-8E35F9216FEB@technologists.com> Not sure when started, probably 1986, continued through my departure in May 1989, and apparently the machine continued after that. > On Apr 6, 2021, at 9:30 PM, Ed Bradford wrote: > > What year was this, Charles? > > Ed > > > On Tue, Apr 6, 2021 at 12:33 PM Charles H Sauer > wrote: > For much of my last few years at IBM, my uucp machine, ibmchs, was an AT > running Xenix, probably that version of Xenix. > > On 4/6/2021 12:09 PM, Clem Cole wrote: > > Doug -- IIRC IBM private-labeled a Microsoft put out a version of Xenix, > > although I think it required an PC/AT (286) > > ᐧ > > > > On Tue, Apr 6, 2021 at 11:36 AM M Douglas McIlroy > > > > >> wrote: > > > > > I wonder. IBM introduced the IBM PC in August of 1981. > > > That was years after a non-memory managed version of > > > Unix was created by Heinze Lycklama, LSX. Is anyone > > > on this list familiar with Bell Labs management thoughts > > > on selling IBM on LSX rather than "dos"? > > > > IBM famously failed to buy the well-established CP/M in > > 1980. (CP/M had been introduced in 1974, before the > > advent of the LSI-11 on which LSX ran.) By then IBM had > > settled on Basic and Intel. I do not believe they ever > > considered Unix and DEC, nor that AT&T considered > > selling to IBM. (AT&T had--fortunately--long since been > > rebuffed in an attempt to sell to DEC.) > > > > Doug > > > > -- > voice: +1.512.784.7526 e-mail: sauer at technologists.com > fax: +1.512.346.5240 Web: https://technologists.com/sauer/ > Facebook/Google/Skype/Twitter : CharlesHSauer > > > -- > Advice is judged by results, not by intentions. > Cicero > -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 web: https://technologists.com/sauer/ Facebook/Google/Skype/Twitter: CharlesHSauer -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Wed Apr 7 12:49:44 2021 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 7 Apr 2021 12:49:44 +1000 (EST) Subject: [TUHS] PC Unix (had been How to Kill a Technical Conference In-Reply-To: <12445917.1513.1617740812263.JavaMail.root@zimbraanteil> References: <12445917.1513.1617740812263.JavaMail.root@zimbraanteil> Message-ID: On Tue, 6 Apr 2021, Jim Capp wrote: > Xenix was my first experience with *nix.  I "caught the bug" and have > been working with *nix ever since. Our Xenix box (out of many Unix boxen) was called "toy" for a reason; it was horribly primitive (OK, it was just a '286), and no longer exists, thank Babbage. -- Dave From dave at horsfall.org Wed Apr 7 13:38:51 2021 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 7 Apr 2021 13:38:51 +1000 (EST) Subject: [TUHS] PC Unix (had been How to Kill a Technical Conference In-Reply-To: References: <04e60d98-22e3-acb5-686f-93af1f7e2825@technologists.com> Message-ID: On Tue, 6 Apr 2021, Warner Losh wrote: > As the author of LSX and MiniUnix, are you aware of anybody porting them > to another non PDP-11 architecture? ISC didn't do that at all, but maybe > you heard of something through the years? hat depends on whether you count that horrible DEC mini-box or not (name thankfully forgotten); it was pure floppy, and we had to disable "update" somehow as otherwise it would wear a hole into wherever the superblock was. -- Dave From drsalists at gmail.com Wed Apr 7 15:15:29 2021 From: drsalists at gmail.com (Dan Stromberg) Date: Tue, 6 Apr 2021 22:15:29 -0700 Subject: [TUHS] Zombified SCO comes back from the dead, brings trial back to life against IBM In-Reply-To: <202104042100.134L0nTg086762@darkstar.fourwinds.com> References: <584DED5A-1226-4AF7-A191-C34CAFA53686@pobox.com> <20210404022356.GR28660@mcvoy.com> <20210404085520.GA6494@naleco.com> <202104042100.134L0nTg086762@darkstar.fourwinds.com> Message-ID: On Sun, Apr 4, 2021 at 2:01 PM Jon Steinhart wrote: > Lyndon Nerenberg (VE7TFX/VE6BBM) writes: > > Josh Good writes: > > Yes, but weren't they also the first to unbundle the C compiler? Until > > Yes, that really sucked but that wasn't until Solaris. > Actually, the SunOS 4.1.x cc wasn't used for anything on my systems but building gcc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Wed Apr 7 16:04:23 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 07 Apr 2021 00:04:23 -0600 Subject: [TUHS] PC Unix (had been How to Kill a Technical Conference In-Reply-To: <12445917.1513.1617740812263.JavaMail.root@zimbraanteil> References: <12445917.1513.1617740812263.JavaMail.root@zimbraanteil> Message-ID: <202104070604.13764NOh010054@freefriends.org> Jim Capp wrote: > Josh, > > At the time (1982-83), Xenix was the only Unix available to me. By 1984, > we upgraded to a full-fledged NCR 1632 system, with Unix SVR4. 1984 was SVR2 time frame. SVR4 wasn't released until 1989.... At what point did AT&T buy NCR? More like early 90s, no? Arnold From pnr at planet.nl Wed Apr 7 17:52:54 2021 From: pnr at planet.nl (Paul Ruizendaal) Date: Wed, 7 Apr 2021 09:52:54 +0200 Subject: [TUHS] PC Unix Message-ID: > I developed LSX at Bell Labs in Murray Hill NJ in the 1974-1975 > timeframe. > An existing C compiler made it possible without too much effort. The > UNIX > source was available to Universities by then. I also developed Mini-UNIX > for the PDP11/10 (also no memory protection) in the 1976 timeframe. > This source code was also made available to Universities, but the source > code for LSX was not. > > Peter Weiner, the founder of INTERACTIVE Systems Corp.(ISC) in June > 1977, > the first commercial company to license UNIX source from Western > Electric for $20,000. Binary licenses were available at the same time. > I joined ISC in May of 1978 when ISC was the first company to offer > UNIX support services to third parties. There was never any talk about > licensing UNIX source code from Western Electric (WE) from the founding > of ISC to when the Intel 8086 micro became available in 1981. > DEC never really targeted the PC market with the LSI-11 micro, > and WE never made it easy to license binary copies of the UNIX > source code, So LSX never really caught on in the commercial market. > ISC was in the business of porting the UNIX source code to other > computers, micro to mainframe, as new computer architectures > were developed. > > Heinz The Wikipedia page for ISC has the following paragraphs: "Although observers in the early 1980s expected that IBM would choose Microsoft Xenix or a version from AT&T Corporation as the Unix for its microcomputer, PC/IX was the first Unix implementation for the IBM PC XT available directly from IBM. According to Bob Blake, the PC/IX product manager for IBM, their "primary objective was to make a credible Unix system - [...] not try to 'IBM-ize' the product. PC-IX is System III Unix." PC/IX was not, however, the first Unix port to the XT: Venix/86 preceded PC/IX by about a year, although it was based on the older Version 7 Unix. The main addition to PC/IX was the INed screen editor from ISC. INed offered multiple windows and context-sensitive help, paragraph justification and margin changes, although it was not a fully fledged word processor. PC/IX omitted the System III FORTRAN compiler and the tar file archiver, and did not add BSD tools like vi or the C shell. One reason for not porting these was that in PC/IX, individual applications were limited to a single segment of 64 kB of RAM. To achieve good filesystem performance, PC/IX addressed the XT hard drive directly, rather than doing this through the BIOS, which gave it a significant speed advantage compared to MS-DOS. Because of the lack of true memory protection in the 8088 chips, IBM only sold single-user licenses for PC/IX. The PC/IX distribution came on 19 floppy disks and was accompanied by a 1,800-page manual. Installed, PC/IX took approximately 4.5 MB of disk space. An editorial by Bill Machrone in PC Magazine at the time of PC/IX's launch flagged the $900 price as a show stopper given its lack of compatibility with MS-DOS applications. PC/IX was not a commercial success although BYTE in August 1984 described it as "a complete, usable single-user implementation that does what can be done with the 8088", noting that PC/IX on the PC outperformed Venix on the PDP-11/23.” It seems like Venix/86 came out in Spring 1983 and PC/IX in Spring 1984. I guess by then RAM had become cheap enough that running in 64KB of core was no longer a requirement and LSX and MX did not make sense anymore. Does that sound right? From pnr at planet.nl Wed Apr 7 18:20:43 2021 From: pnr at planet.nl (Paul Ruizendaal) Date: Wed, 7 Apr 2021 10:20:43 +0200 Subject: [TUHS] PC Unix Message-ID: <2313BFBA-8795-497F-AD46-46CCFC0E6E6C@planet.nl> > IBM famously failed to buy the well-established CP/M in > 1980. (CP/M had been introduced in 1974, before the > advent of the LSI-11 on which LSX ran.) By then IBM had > settled on Basic and Intel. I do not believe they ever > considered Unix and DEC, nor that AT&T considered > selling to IBM. (AT&T had--fortunately--long since been > rebuffed in an attempt to sell to DEC.) > > Doug Besides all the truth or legend around flying and signing NDA’s, I think there were clear economic reasons for ending up with Microsoft’s DOS, and the pre-cursor to that: picking the 8088. [1] By 1980 there were an estimated 8,000 software packages for CP/M available, many aimed at small business. IBM was targeting that. The availability of source level converters for 8080 code to 8088 code made porting economically feasible for the (cottage) ISV’s. This must have been a strong argument in favour of picking the 8088 for the original PC. [2] In line with their respective tried and tested business models, Digital Research offered CP/M-86 with a per-copy license structure. Microsoft offered QDOS with a one-off license structure. The latter was economically more attractive to IBM. I don’t think either side expected clones to happen the way they did, although they did probably factor in the appearance of non-compatible work-alikes. Although some sources suggest that going with the 68000 and/or Unix were considered, it would have left the new machine without an instant base of affordable small business applications. Speed to market was a leading paradigm for the PC's design team. From pnr at planet.nl Wed Apr 7 18:51:41 2021 From: pnr at planet.nl (Paul Ruizendaal) Date: Wed, 7 Apr 2021 10:51:41 +0200 Subject: [TUHS] PC Unix / early Xenix Message-ID: <2397CD77-F9BD-45F7-A9D6-63401BC5F650@planet.nl> > There is some information and demos of the early 8086/80286 Xenix, > including the IBM rebranded PC Xenix 1.0 on pcjs.org > > https://www.pcjs.org/software/pcx86/sys/unix/ibm/xenix/1.0/ > > And if you have a modern enough browser you can run them from the browser as > well! > > It's amazing that CPU's are fast enough to run interpreted emulation that is > faster than the old machines of the day. That is a cool link. At the bottom of the page are two images of floppy disks. These show an ISC copyright notice. Maybe this is because the floppies contained “extensions” rather than Xenix itself. === Note that "IBM Xenix 1.0" is actually the same as MS Xenix 3.0, and arrived after MS Xenix had been available for 4 years (initially for the PDP-11 and shortly after for other CPU's): http://seefigure1.com/2014/04/15/xenixtime.html Rob Ferguson writes: "From 1986 to 1989, I worked in the Xenix group at Microsoft. It was my first job out of school, and I was the most junior person on the team. I was hopelessly naive, inexperienced, generally clueless, and borderline incompetent, but my coworkers were kind, supportive and enormously forgiving – just a lovely bunch of folks. Microsoft decided to exit the Xenix business in 1989, but before the group was dispersed to the winds, we held a wake. Many of the old hands at MS had worked on Xenix at some point, so the party was filled with much of the senior development staff from across the company. There was cake, beer, and nostalgia; stories were told, most of which I can’t repeat. Some of the longer-serving folks dug through their files to find particularly amusing Xenix-related documents, and they were copied and distributed to the attendees. If memory serves, it was a co-operative effort between a number of the senior developers to produce this timeline detailing all the major releases of Xenix. I have no personal knowledge of the OEM relationships before 1986, and I do know that there were additional minor ports and OEMs that aren’t listed on the timeline (e.g. NS32016, IBM PS/2 MCA-bus, Onyx, Spectrix), but to the best of my understanding this hits the major points. Since we’re on the topic, I should say that I’ve encountered a surprising amount of confusion about the history of Xenix. So, here are some things I know: Xenix was a version of AT&T UNIX, ported and packaged by Microsoft. It was first offered for sale to the public in the August 25, 1980 issue of Computerworld. It was originally priced between $2000 and $9000 per copy, depending on the number of users. MS owned the Xenix trademark and had a master UNIX license with AT&T, which allowed them to sub-licence Xenix to other vendors. Xenix was licensed by a variety of OEMs, and then either bundled with their hardware or sold as an optional extra. Ports were available for a variety of different architectures, including the Z-8000, Motorola 68000, NS16032, and various Intel processors. In 1983, IBM contracted with Microsoft to port Xenix to their forthcoming 80286-based machines (codenamed “Salmon”); the result was “IBM Personal Computer XENIX” for the PC/AT. By this time, there was growing retail demand for Xenix on IBM-compatible personal computer hardware, but Microsoft made the strategic decision not to sell Xenix in the consumer market; instead, they entered into an agreement with a company called the Santa Cruz Operation to package, sell and support Xenix for those customers. Even with outsourcing retail development to SCO, Microsoft was still putting significant effort into Xenix: • Ports to new architectures, the large majority of the core kernel and driver work, and extensive custom tool development were all done by Microsoft. By the time of the Intel releases, there was significant kernel divergence from the original AT&T code. • The main Microsoft development products (C compiler, assembler, linker, debugger) were included with the Intel-based releases of Xenix, and there were custom internally-developed toolchains for other architectures. Often, the latest version of the tools appeared on Xenix well before they were available on DOS. • The character-oriented versions of Microsoft Word and Multiplan were both ported to Xenix. • MS had a dedicated Xenix documentation team, which produced custom manuals and tutorials. As late as the beginning of 1985, there was some debate inside of Microsoft whether Xenix should be the 16-bit “successor” to DOS; for a variety of reasons – mostly having to do with licensing, royalties, and ownership of the code, but also involving a certain amount of ego and politics – MS and IBM decided to pursue OS/2 instead. That marked the end of any further Xenix investment at Microsoft, and the group was left to slowly atrophy. The final Xenix work at Microsoft was an effort with AT&T to integrate Xenix support into the main System V.3 source code, producing what we unimaginatively called the “Merged Product” (noted by the official name of “UNIX System V, r3.2” in the timeline above). Once that effort was completed, all Intel-based releases of UNIX from AT&T incorporated Xenix support; in return, Microsoft received royalties for every copy of Intel UNIX that AT&T subsequently licensed. It will suffice, perhaps, to simply note that this was a good deal for Microsoft.” It would be so cool if these early (1980-1984) Xenix versions were available for historical examination and study. From heinz at osta.com Thu Apr 8 02:01:42 2021 From: heinz at osta.com (heinz at osta.com) Date: Wed, 07 Apr 2021 09:01:42 -0700 Subject: [TUHS] PC Unix (had been How to Kill a Technical Conference In-Reply-To: <202104070604.13764NOh010054@freefriends.org> References: <12445917.1513.1617740812263.JavaMail.root@zimbraanteil> <202104070604.13764NOh010054@freefriends.org> Message-ID: May 1991. Heinz On 2021-04-06 23:04, arnold at skeeve.com wrote: > Jim Capp wrote: > >> Josh, >> >> At the time (1982-83), Xenix was the only Unix available to me. By >> 1984, >> we upgraded to a full-fledged NCR 1632 system, with Unix SVR4. > > 1984 was SVR2 time frame. SVR4 wasn't released until 1989.... > > At what point did AT&T buy NCR? More like early 90s, no? > > Arnold From heinz at osta.com Thu Apr 8 01:57:28 2021 From: heinz at osta.com (heinz at osta.com) Date: Wed, 07 Apr 2021 08:57:28 -0700 Subject: [TUHS] PC Unix In-Reply-To: References: Message-ID: Yes, that sounds about right. LSX and MX used older versions of UNIX and binary licensing from WE was not yet available. Heinz On 2021-04-07 00:52, Paul Ruizendaal via TUHS wrote: >> I developed LSX at Bell Labs in Murray Hill NJ in the 1974-1975 >> timeframe. >> An existing C compiler made it possible without too much effort. The >> UNIX >> source was available to Universities by then. I also developed >> Mini-UNIX >> for the PDP11/10 (also no memory protection) in the 1976 timeframe. >> This source code was also made available to Universities, but the >> source >> code for LSX was not. >> >> Peter Weiner, the founder of INTERACTIVE Systems Corp.(ISC) in June >> 1977, >> the first commercial company to license UNIX source from Western >> Electric for $20,000. Binary licenses were available at the same time. >> I joined ISC in May of 1978 when ISC was the first company to offer >> UNIX support services to third parties. There was never any talk about >> licensing UNIX source code from Western Electric (WE) from the >> founding >> of ISC to when the Intel 8086 micro became available in 1981. >> DEC never really targeted the PC market with the LSI-11 micro, >> and WE never made it easy to license binary copies of the UNIX >> source code, So LSX never really caught on in the commercial market. >> ISC was in the business of porting the UNIX source code to other >> computers, micro to mainframe, as new computer architectures >> were developed. >> >> Heinz > > The Wikipedia page for ISC has the following paragraphs: > > "Although observers in the early 1980s expected that IBM would choose > Microsoft Xenix or a version from AT&T Corporation as the Unix for its > microcomputer, PC/IX was the first Unix implementation for the IBM PC > XT available directly from IBM. According to Bob Blake, the PC/IX > product manager for IBM, their "primary objective was to make a > credible Unix system - [...] not try to 'IBM-ize' the product. PC-IX > is System III Unix." PC/IX was not, however, the first Unix port to > the XT: Venix/86 preceded PC/IX by about a year, although it was based > on the older Version 7 Unix. > > The main addition to PC/IX was the INed screen editor from ISC. INed > offered multiple windows and context-sensitive help, paragraph > justification and margin changes, although it was not a fully fledged > word processor. PC/IX omitted the System III FORTRAN compiler and the > tar file archiver, and did not add BSD tools like vi or the C shell. > One reason for not porting these was that in PC/IX, individual > applications were limited to a single segment of 64 kB of RAM. > > To achieve good filesystem performance, PC/IX addressed the XT hard > drive directly, rather than doing this through the BIOS, which gave it > a significant speed advantage compared to MS-DOS. Because of the lack > of true memory protection in the 8088 chips, IBM only sold single-user > licenses for PC/IX. > > The PC/IX distribution came on 19 floppy disks and was accompanied by > a 1,800-page manual. Installed, PC/IX took approximately 4.5 MB of > disk space. An editorial by Bill Machrone in PC Magazine at the time > of PC/IX's launch flagged the $900 price as a show stopper given its > lack of compatibility with MS-DOS applications. PC/IX was not a > commercial success although BYTE in August 1984 described it as "a > complete, usable single-user implementation that does what can be done > with the 8088", noting that PC/IX on the PC outperformed Venix on the > PDP-11/23.” > > It seems like Venix/86 came out in Spring 1983 and PC/IX in Spring > 1984. I guess by then RAM had become cheap enough that running in 64KB > of core was no longer a requirement and LSX and MX did not make sense > anymore. Does that sound right? From pepe at naleco.com Thu Apr 8 02:42:10 2021 From: pepe at naleco.com (Josh Good) Date: Wed, 7 Apr 2021 18:42:10 +0200 Subject: [TUHS] PC Unix (had been How to Kill a Technical Conference In-Reply-To: References: <12445917.1513.1617740812263.JavaMail.root@zimbraanteil> Message-ID: <20210407164207.GB3953@naleco.com> On 2021 Apr 6, 15:47, Charles H Sauer wrote: > - it looks like someone kept it in place after I left IBM in 1989, since > http://web.mit.edu/kolya/sipb/afs/root.afs/athena.mit.edu/reference/net-directory/maps/uucp.bak/u.usa.tx.4 > lists it in 1991 Very interesting. So I understand the email-through-UUCP duties of that Xenix machine were to handle not just your personal email, but the email of several people in a Department, was that so? If that was the case, how did the other people read their email in the same Xenix machine, through serial consoles or taking turns at the VGA/CGA console? -- Josh Good From sauer at technologists.com Thu Apr 8 04:04:12 2021 From: sauer at technologists.com (Charles H. Sauer) Date: Wed, 7 Apr 2021 13:04:12 -0500 Subject: [TUHS] PC Unix (had been How to Kill a Technical Conference In-Reply-To: <20210407164207.GB3953@naleco.com> References: <12445917.1513.1617740812263.JavaMail.root@zimbraanteil> <20210407164207.GB3953@naleco.com> Message-ID: <907543cd-457a-6e9a-9ba7-528560c23819@technologists.com> I think a few other people got mail through ibmchs while I ran it, but I don't remember if/who/how. I don't know anything about ibmchs after May 1989. On 4/7/2021 11:42 AM, Josh Good wrote: > On 2021 Apr 6, 15:47, Charles H Sauer wrote: > >> - it looks like someone kept it in place after I left IBM in 1989, since >> http://web.mit.edu/kolya/sipb/afs/root.afs/athena.mit.edu/reference/net-directory/maps/uucp.bak/u.usa.tx.4 >> lists it in 1991 > > Very interesting. So I understand the email-through-UUCP duties of that > Xenix machine were to handle not just your personal email, but the email of > several people in a Department, was that so? > > If that was the case, how did the other people read their email in the same > Xenix machine, through serial consoles or taking turns at the VGA/CGA > console? > -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Skype/Twitter: CharlesHSauer From gnu at toad.com Thu Apr 8 04:04:29 2021 From: gnu at toad.com (John Gilmore) Date: Wed, 07 Apr 2021 11:04:29 -0700 Subject: [TUHS] PC Unix In-Reply-To: <2313BFBA-8795-497F-AD46-46CCFC0E6E6C@planet.nl> References: <2313BFBA-8795-497F-AD46-46CCFC0E6E6C@planet.nl> Message-ID: <840.1617818669@hop.toad.com> Paul Ruizendaal wrote: > Although some sources suggest that going with the 68000 and/or Unix were considered, it would have left the new machine without an instant base of affordable small business applications. Speed to market was a leading paradigm for the PC's design team. Sun was making 68000-based systems in 1981, before the IBM PC was created. But they only sold in small volumes, maybe a few thousand systems per year. What I remember hearing was that IBM asked Motorola if they could make 250,000 68000 chips for the PC's first year. They said no. Intel said yes to making 250,000 8088 chips, so they got the business. It's great that Intel is finally losing the edge that they once had in chip fabrication, because it was married to such rotten taste in computer architecture. Perhaps over the next 30 years the industry can finally evolve to less insane designs. (Even AMD is better than Intel at architecture; they created a 64-bit x86 that was so reasonable that Intel ended up adopting it.) John From thomas.paulsen at firemail.de Thu Apr 8 08:18:04 2021 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Thu, 08 Apr 2021 00:18:04 +0200 Subject: [TUHS] PC Unix In-Reply-To: <840.1617818669@hop.toad.com> References: <2313BFBA-8795-497F-AD46-46CCFC0E6E6C@planet.nl> <840.1617818669@hop.toad.com> Message-ID: >From: John Gilmore >Sun was making 68000-based systems in 1981, before the IBM PC was created. Sun was founded on February 24, 1982. The Sun-1 was launched in May 1982. https://en.wikipedia.org/wiki/Sun_Microsystems https://en.wikipedia.org/wiki/Sun-1 From lm at mcvoy.com Thu Apr 8 08:40:00 2021 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 7 Apr 2021 15:40:00 -0700 Subject: [TUHS] PC Unix In-Reply-To: References: <2313BFBA-8795-497F-AD46-46CCFC0E6E6C@planet.nl> <840.1617818669@hop.toad.com> Message-ID: <20210407224000.GY11131@mcvoy.com> On Thu, Apr 08, 2021 at 12:18:04AM +0200, Thomas Paulsen wrote: > >From: John Gilmore > >Sun was making 68000-based systems in 1981, before the IBM PC was created. > > Sun was founded on February 24, 1982. The Sun-1 was launched in May 1982. > > https://en.wikipedia.org/wiki/Sun_Microsystems > https://en.wikipedia.org/wiki/Sun-1 John may be sort of right, I bet avb was building 68k machines at Stanford before SUN was founded. Sun stood for Stanford University Network I believe. --lm From jon at fourwinds.com Thu Apr 8 09:04:38 2021 From: jon at fourwinds.com (Jon Steinhart) Date: Wed, 07 Apr 2021 16:04:38 -0700 Subject: [TUHS] PC Unix In-Reply-To: <20210407224000.GY11131@mcvoy.com> References: <2313BFBA-8795-497F-AD46-46CCFC0E6E6C@planet.nl> <840.1617818669@hop.toad.com> <20210407224000.GY11131@mcvoy.com> Message-ID: <202104072304.137N4cLx271287@darkstar.fourwinds.com> Larry McVoy writes: > On Thu, Apr 08, 2021 at 12:18:04AM +0200, Thomas Paulsen wrote: > > >From: John Gilmore > > >Sun was making 68000-based systems in 1981, before the IBM PC was created. > > > > Sun was founded on February 24, 1982. The Sun-1 was launched in May 1982. > > > > https://en.wikipedia.org/wiki/Sun_Microsystems > > https://en.wikipedia.org/wiki/Sun-1 > > John may be sort of right, I bet avb was building 68k machines at > Stanford before SUN was founded. Sun stood for Stanford University > Network I believe. > > --lm Larry is correct. I remember visiting a friend of mind, Gary Newman, who was working at Lucasfilm in '81. He showed me a bunch of stuff that they were doing on Stanford University Network boards. Full disclosure, it was Gary and Paul Rubinfeld who ended up at DEC and I believe was the architect for the microVax who told me about the explorer scout post at BTL which is how I met Heinz. Jon From drsalists at gmail.com Thu Apr 8 15:21:12 2021 From: drsalists at gmail.com (Dan Stromberg) Date: Wed, 7 Apr 2021 22:21:12 -0700 Subject: [TUHS] Story about Microsoft and *ix Message-ID: I heard a while back, that the reason that Microsoft has avoided *ix so meticulously, was that back when they sold Xenix to SCO, as part of the deal Microsoft signed a noncompete agreement that prevented them from selling anything at all similar to *ix. True? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Thu Apr 8 15:32:20 2021 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 8 Apr 2021 15:32:20 +1000 (EST) Subject: [TUHS] (no printed copy) (was (no subject)) In-Reply-To: <1617722131.1272.for-standards-violators@oclsc.org> References: <1617722131.1272.for-standards-violators@oclsc.org> Message-ID: On Tue, 6 Apr 2021, Norman Wilson wrote: > I'm not sure why people, even in a group devoted to history like ours, > focus so much on whether a journal is issued in print or only > electronically. The latter has become more and more common. Well, curling up in bed with a good PDF just doesn't quite feel the same... It's also handy in a waiting room (no battery to go flat and not having to rely upon a WiFi connection) and also when waiting for the local bus. > On one hand, I too find that if something is available only > electronically I'm more likely to put off reading it, probably because > back issues don't pile up as visibly. I know the feeling :-) I'm slowly working through my bookmarks. -- Dave From egbegb2 at gmail.com Thu Apr 8 15:56:35 2021 From: egbegb2 at gmail.com (Ed Bradford) Date: Thu, 8 Apr 2021 00:56:35 -0500 Subject: [TUHS] Story about Microsoft and *ix In-Reply-To: References: Message-ID: In the early 80's it was Bill Gates who made strategic decisions for MS. That was even before they went public. My wonder is if Gates had ever used Unix. He (personally) developed BASIC for a CPM (I think) machine. I am unaware of any system level skills in his experience. If he had knowledge of or used Unix or XENIX (for which he had a master license from AT&T), why on earth would anyone go down the bazaar path of DOS with lettered drives, tortuous IO interfaces, and assembly language source code? Why didn't he choose a far simpler to support and easier to learn operating system that had 10 years of maturity. I would love to hear Bill Gates' description of the development of a DOS over Unix strategy. My guess is there wasn't enough memory on the first IBM PC's. I worked with LSX while at BTL and forget the memory footprint of LSX. Memory protection was another thing, but LSX looked and felt like UNIX without memory protection. Does anyone recall how much RAM memory could be put on the first IBM PC's? That was probably a major problem. My memory of the LSI-11 architecture has faded. Same for 20286. In the early 1980's I had never heard of Xenix. Ed On Thu, Apr 8, 2021 at 12:22 AM Dan Stromberg wrote: > > I heard a while back, that the reason that Microsoft has avoided *ix so > meticulously, was that back when they sold Xenix to SCO, as part of the > deal Microsoft signed a noncompete agreement that prevented them from > selling anything at all similar to *ix. > > True? > > -- Advice is judged by results, not by intentions. Cicero -------------- next part -------------- An HTML attachment was scrubbed... URL: From usotsuki at buric.co Thu Apr 8 16:02:28 2021 From: usotsuki at buric.co (Steve Nickolas) Date: Thu, 8 Apr 2021 02:02:28 -0400 (EDT) Subject: [TUHS] Story about Microsoft and *ix In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021, Ed Bradford wrote: > Does anyone recall how much RAM memory could be put on the first IBM > PC's? That was probably a major problem. As I recall the earliest models supported 16-64K onboard, with later models supporting 64-256K. The 1981 firmware was, IIRC, limited to 544K (changed to 640K in 1982). -uso. From rtomek at ceti.pl Thu Apr 8 16:14:57 2021 From: rtomek at ceti.pl (Tomasz Rola) Date: Thu, 8 Apr 2021 08:14:57 +0200 Subject: [TUHS] (no printed copy) (was (no subject)) In-Reply-To: References: <1617722131.1272.for-standards-violators@oclsc.org> Message-ID: <20210408061457.GB4187@tau1.ceti.pl> On Thu, Apr 08, 2021 at 03:32:20PM +1000, Dave Horsfall wrote: > On Tue, 6 Apr 2021, Norman Wilson wrote: > > >I'm not sure why people, even in a group devoted to history like > >ours, focus so much on whether a journal is issued in print or > >only electronically. The latter has become more and more common. > > Well, curling up in bed with a good PDF just doesn't quite feel the > same... It's also handy in a waiting room (no battery to go flat > and not having to rely upon a WiFi connection) and also when waiting > for the local bus. Curling up in bed with e-ink based reader and pdf can be better than curling up with 2kg-worth of hard book. I know, I do it. As a huge fan of nonkindle reader, I have sdcard slot and do not have to connect it at all. Batteries used to last at least a month. This display type is really low power. I have recently bought a colored e-ink reader, I charged it up about 35-45 days ago, read for at least ten hours a week, and batt meter shows 40% (chances are, it is not calibrated yet, I am still to discharge it to the end). As of colours, this feels really like working prototype, they claim 4096 colors which probably means 256 colors on "colored look-through display" times 16 shades of grey on classic e-ink display underneath. So, color is just to spice it up a bit but not very useful at the moment... Albeit it depends on content. Art photo no, sci articles maybe. They should come to 65k one day, then I will be happier. > >On one hand, I too find that if something is available only > >electronically I'm more likely to put off reading it, probably > >because back issues don't pile up as visibly. > > I know the feeling :-) I'm slowly working through my bookmarks. -- Regards, Tomasz Rola, who lives in self made hell with walls of unread magazines, books and God only knows what else, new hardware, old hardware, lost hardware... -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola at bigfoot.com ** From andreww591 at gmail.com Thu Apr 8 16:48:44 2021 From: andreww591 at gmail.com (Andrew Warkentin) Date: Thu, 8 Apr 2021 00:48:44 -0600 Subject: [TUHS] Story about Microsoft and *ix In-Reply-To: References: Message-ID: On 4/7/21, Ed Bradford wrote: > In the early 80's it was Bill Gates who made strategic decisions for MS. > That was even before they went public. My wonder is if Gates had ever used > Unix. He (personally) developed BASIC for a CPM (I think) machine. I am > unaware of any system level skills in his experience. If he had knowledge > of or used Unix or XENIX (for which he had a master license from AT&T), why > on earth would anyone go down the bazaar path of DOS with lettered drives, > tortuous IO interfaces, and assembly language source code? Why didn't he > choose a far simpler to support and easier to learn operating system that > had > 10 years of maturity. I would love to hear Bill Gates' description of the > development of a DOS over Unix strategy. > > My guess is there wasn't enough memory on the first IBM PC's. I worked with > LSX while at BTL and forget the memory footprint of LSX. Memory protection > was another thing, but LSX looked and felt like UNIX without memory > protection. Does anyone recall how much RAM memory could be put on the > first IBM PC's? That was probably a major problem. > Limited RAM was probably the main factor keeping Microsoft from replacing DOS with XENIX on early PCs. I think that the main factor after most PCs started to come with sufficient RAM for Unix might have been that the divestiture allowed AT&T to fully commercialize Unix and charge a fortune for licenses. Microsoft did actually talk about gradually phasing out DOS for XENIX before the divestiture happened. I wonder if Microsoft would have actually followed through on replacing DOS with XENIX had the divestiture either not happened at all, or happened in a form that still restricted AT&T from commercializing Unix (maybe a vertical divestiture in which the Bell System continued to exist but was forced to become a wholesaler only). It would probably have been the path of least resistance. History would very likely have gone better than it actually did here, with Unix likely becoming the dominant OS family by the early to mid 90s. With their flagship OS being a Unix, Microsoft would have had a bit harder time being as anti-competitive as they were here, and at least they would have been pushing an OS that was sort of reasonable unlike anything in the DOS-like family. XENIX would probably have gone on to be the dominant implementation of Unix, but it's likely that compatibility layers for it would have been common (as some PC Unices actually did here). I guess things could have also gone a lot worse than they did here though. Linux sucks in quite a few ways, but Microsoft could very well have actually finished winning the Unix wars in the early 2000s had Linux not been there at the right time to emerge as the ultimate victor. At least the possibility of writing a better OS and having it be at least modestly successful by being Linux-compatible still remains here, whereas it would be much harder for a better OS to succeed in a world where Windows was pretty much the only relevant OS. From thomas.paulsen at firemail.de Thu Apr 8 17:24:28 2021 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Thu, 08 Apr 2021 09:24:28 +0200 Subject: [TUHS] Story about Microsoft and *ix In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From thomas.paulsen at firemail.de Thu Apr 8 17:32:51 2021 From: thomas.paulsen at firemail.de (Thomas Paulsen) Date: Thu, 08 Apr 2021 09:32:51 +0200 Subject: [TUHS] Story about Microsoft and *ix In-Reply-To: References: Message-ID: <671e431b7f6ea64588b95e0fd974f172@firemail.de> An HTML attachment was scrubbed... URL: From davida at pobox.com Thu Apr 8 18:16:21 2021 From: davida at pobox.com (David Arnold) Date: Thu, 8 Apr 2021 18:16:21 +1000 Subject: [TUHS] Story about Microsoft and *ix In-Reply-To: References: Message-ID: <26189F3F-CDCD-46C3-A6D3-B92883A9FDD0@pobox.com> > On 8 Apr 2021, at 16:02, Steve Nickolas wrote: > > On Thu, 8 Apr 2021, Ed Bradford wrote: > >> Does anyone recall how much RAM memory could be put on the first IBM PC's? That was probably a major problem. > > As I recall the earliest models supported 16-64K onboard, with later models supporting 64-256K. The 1981 firmware was, IIRC, limited to 544K (changed to 640K in 1982). Wikipedia agrees. $1565 minimum configuration had 16KB RAM, CGA graphics, and single 5.25” floppy drive (that is, no hard drive). DOS 2.0, 2 years later, shipped with the XT which had 128KB RAM and a 10MB hard drive. That might have been more practical. d From tih at hamartun.priv.no Thu Apr 8 19:56:55 2021 From: tih at hamartun.priv.no (Tom Ivar Helbekkmo) Date: Thu, 08 Apr 2021 11:56:55 +0200 Subject: [TUHS] XXDP formatter RX50 floppy needed Message-ID: I'm having a bit of trouble with a couple of RD52 drives, and I suspect that I need a newer formatting program. The formatter floppy in my XXDP kit includes ZRQC-C-0 (ZRQCC0.BIC), and I understand that revision C is really old, and I should be running at least F, preferably H. Does anyone have (or can make) an image of a newer version of the RX50 formatter floppy? I've got an RX50 drive in my 11/83 with 2.11BSD, so it would be a simple matter to make a bootable floppy there if I just had the bits to write... :) -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 From clemc at ccc.com Thu Apr 8 23:42:30 2021 From: clemc at ccc.com (Clem Cole) Date: Thu, 8 Apr 2021 09:42:30 -0400 Subject: [TUHS] Story about Microsoft and *ix In-Reply-To: References: Message-ID: On Thu, Apr 8, 2021 at 1:58 AM Ed Bradford wrote: > In the early 80's it was Bill Gates who made strategic decisions for MS. > That was even before they went public. My wonder is if Gates had ever used > Unix. He (personally) developed BASIC for a CPM (I think) machine. I am > unaware of any system level skills in his experience. > I can say I have personally seen him do so ;-) He and Bob Greenberg were at Ricki's Hyatt at the infamous meeting with AT&T in late 1979/early 1980 [I have forgotten the precise date it was early/mid-winter IIRC -- I was there as ½ of Tektronix's reps - this meeting would lead the Sys III license]. Bob and Bill had some sort of PC with them running a pre-Xenix of some type as an example. Please remember that he and his team ran the Seventh edition of UNIX on a PDP-11/70 at Microsoft (called 'kermit' IIRC) and also TOPS-10 on a KL -- I believe that both of these systems are at the LCM in Seattle these days (which is currently in mothballs due to CV-19 and funding which is a real shame). > If he had knowledge of or used Unix or XENIX (for which he had a master > license from AT&T), why on earth would anyone go down the bazaar path of > DOS with lettered drives, tortuous IO interfaces, and assembly language > source code? > To answer this I have a few educated >>guesses<< which are based on the history of the times and practical reality. Gates (and Paul Allen) had personally grown up TOPS-10 and RSTS in HS and in his 2 semesters at Harvard; so the DEC disk naming scheme for having the system written using assembler was natural to him since DEC did that too. And second, DOS was purchased from Seattle Computer Products (SCP - story told elsewhere and not UNIX history) and it has been written to be modeled after CP/M (which had been modeled at RT/11 and DOS/11 - the last two again using DEC style naming conventions). Interestingly enough, CP/M had been written in PL/M which was Kidall's simplified PL/360 style language for the 8080 that he eventual sold to Intel. I was under the impression SCP used 8086 assembler language for the development of their DOS86 system which was the direct parent to MS/DOS - but they might have used PL/M. So you can add, that an issue at the time was that Intel's PL/M tools were not very portable and since the primary development systems at Microsoft were TOPS-10 and RSTS (and Bob was trying to replace RSTS with UNIX at the time), I don't think there were PL/M tools that ran on them. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cym224 at gmail.com Thu Apr 8 23:51:27 2021 From: cym224 at gmail.com (Nemo Nusquam) Date: Thu, 8 Apr 2021 09:51:27 -0400 Subject: [TUHS] (no printed copy) (was (no subject)) In-Reply-To: References: <1617722131.1272.for-standards-violators@oclsc.org> Message-ID: <74677c0f-b22a-60df-aa11-2a191e021cba@gmail.com> On 2021-04-08 01:32, Dave Horsfall wrote: > On Tue, 6 Apr 2021, Norman Wilson wrote (in part): > >> I'm not sure why people, even in a group devoted to history like >> ours, focus so much on whether a journal is issued in print or only >> electronically.  The latter has become more and more common. > > Well, curling up in bed with a good PDF just doesn't quite feel the > same...  It's also handy in a waiting room (no battery to go flat and > not having to rely upon a WiFi connection) and also when waiting for > the local bus. In this informal survey, I side with Dave, though I prefer to read in my comfy well-lit chair with tea/coffee/cocoa.  (A very similar thread was aired on MO last year.) >> On one hand, I too find that if something is available only >> electronically I'm more likely to put off reading it, probably >> because back issues don't pile up as visibly. I fully concur -- I tend to completely forget about them.  Have advertisers actually tracked how many readers look at their ads in print vs. digital? N. > > I know the feeling :-)  I'm slowly working through my bookmarks. > > -- Dave From athornton at gmail.com Fri Apr 9 02:33:01 2021 From: athornton at gmail.com (Adam Thornton) Date: Thu, 8 Apr 2021 09:33:01 -0700 Subject: [TUHS] (no printed copy) (was (no subject)) In-Reply-To: <74677c0f-b22a-60df-aa11-2a191e021cba@gmail.com> References: <1617722131.1272.for-standards-violators@oclsc.org> <74677c0f-b22a-60df-aa11-2a191e021cba@gmail.com> Message-ID: I have one main reason I now prefer an electronic device to paper in most cases: I can make the text as big as I want on a tablet, and my near vision has deteriorated wildly as I've aged. Sure, I also have reading glasses, but it's really nice to just be able to enlarge the font. On Thu, Apr 8, 2021 at 6:52 AM Nemo Nusquam wrote: > On 2021-04-08 01:32, Dave Horsfall wrote: > > On Tue, 6 Apr 2021, Norman Wilson wrote (in part): > > > >> I'm not sure why people, even in a group devoted to history like > >> ours, focus so much on whether a journal is issued in print or only > >> electronically. The latter has become more and more common. > > > > Well, curling up in bed with a good PDF just doesn't quite feel the > > same... It's also handy in a waiting room (no battery to go flat and > > not having to rely upon a WiFi connection) and also when waiting for > > the local bus. > > In this informal survey, I side with Dave, though I prefer to read in my > comfy well-lit chair with tea/coffee/cocoa. (A very similar thread was > aired on MO last year.) > > > >> On one hand, I too find that if something is available only > >> electronically I'm more likely to put off reading it, probably > >> because back issues don't pile up as visibly. > I fully concur -- I tend to completely forget about them. Have > advertisers actually tracked how many readers look at their ads in print > vs. digital? > > N. > > > > > I know the feeling :-) I'm slowly working through my bookmarks. > > > > -- Dave > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From beebe at math.utah.edu Fri Apr 9 06:59:27 2021 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Thu, 8 Apr 2021 14:59:27 -0600 Subject: [TUHS] [tuhs] fuzz testing of Unix-family utilities Message-ID: I first encountered the fuzz-testing work of Barton Miller (Computer Sciences Department, University of Wisconsin in Madison) and his students and colleagues in their original paper on the subject An empirical study of the reliability of UNIX utilities Comm. ACM 33(12) 32--44 (December 1990) https://doi.org/10.1145/96267.96279 which was followed by Fuzz Revisited: A Re-examination of the Reliability of UNIX Utilities and Services University of Wisconsin CS TR 1264 (18 February 1995) ftp://ftp.cs.wisc.edu/pub/techreports/1995/TR1268.pdf and An Empirical Study of the Robustness of MacOS Applications Using Random Testing ACM SIGOPS Operating Systems Review 41(1) 78--86 (January 2007) https://doi.org/10.1145/1228291.1228308 I have used their techniques and tools many times in testing my own, and other, software. By chance, I found today in Web searches on another subject that Milller's group has a new paper in press in the journal IEEE Transactions on Software Engineering: The Relevance of Classic Fuzz Testing: Have We Solved This One? https://doi.org/10.1109/TSE.2020.3047766 https://arxiv.org/abs/2008.06537 https://ieeexplore.ieee.org/document/9309406 I track that journal at http://www.math.utah.edu/pub/tex/bib/ieeetranssoftwengYYYY.{bib,html} [YYYY = 1970 to 2020, by decade], but the new paper has not yet been assigned a journal issue, so I had not seen it before today. The Miller group work over 33 years has examined the reliability of common Unix tools in the face of unexpected input, and in the original work that began in 1988, they were able to demonstrate a significant failure rate in common, and widely used, Unix-family utilities. Despite wide publicity of their first paper, things have not got much better, even from reprogramming software tools in `safe' languages, such as Rust. In each paper, they analyze the reasons for the exposed bugs, and sadly, much the same reasons still exist in their latest study, and in several cases, have been introduced into code since their first work. The latest paper also contains mention of Plan 9, which moved bug-prone input line editing into the window system, and of bugs in pdftex (they say latex, but I suspect they mean pdflatex, not latex itself: pdflatex is a macro-package enhanced layer over the pdftex engine, which is a modified TeX engine). The latter are significant to me and my friends and colleagues in the TeX community, and for the TeX Live 2021 production team http://www.math.utah.edu/pub/texlive-utah/ especially because this year, Don Knuth revisited TeX and Metafont, produced new bug-fixed versions of both, plus updated anniversary editions of his five-volume Computers & Typesetting book series. His recent work is described in a new paper announced this morning: The \TeX{} tuneup of 2021 TUGboat 42(1) ??--?? February 2021 https://tug.org/TUGboat/tb42-1/tb130knuth-tuneup21.pdf Perhaps one or more list members might enjoy the exercise of applying the Barton-group fuzz tests (all of which are available from a Web site ftp://ftp.cs.wisc.edu/paradyn/fuzz/fuzz-2020/ as discussed in their paper) to 1970s and 1980s vintage Unix systems that they run on software-simulated CPUs (or rarely, on real vintage hardware). The Unix tools of those decades were generally much smaller (in lines of code), and most were written by the expert Unix pioneers at Bell Labs. It would of interest to compare the tool failure rates in vintage Unix with tool versions offered by commercial distributions, the GNU Project, and the FreeBSD community, all of which are treated in the 2021 paper. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From lm at mcvoy.com Fri Apr 9 07:11:15 2021 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 8 Apr 2021 14:11:15 -0700 Subject: [TUHS] [tuhs] fuzz testing of Unix-family utilities In-Reply-To: References: Message-ID: <20210408211115.GI11131@mcvoy.com> Bart is part of the Clem Cole, Mike Carey, and Dave somebody cabal and was my OS prof at Wisconsin. Great guy. Ran the undergrad hackers lab. If you need his attention and can't get it, rattle my cage or Clem's cage, we'll get him. On Thu, Apr 08, 2021 at 02:59:27PM -0600, Nelson H. F. Beebe wrote: > I first encountered the fuzz-testing work of Barton Miller (Computer > Sciences Department, University of Wisconsin in Madison) and his > students and colleagues in their original paper on the subject > > An empirical study of the reliability of UNIX utilities > Comm. ACM 33(12) 32--44 (December 1990) > https://doi.org/10.1145/96267.96279 > > which was followed by > > Fuzz Revisited: A Re-examination of the Reliability of UNIX Utilities and Services > University of Wisconsin CS TR 1264 (18 February 1995) > ftp://ftp.cs.wisc.edu/pub/techreports/1995/TR1268.pdf > > and > > An Empirical Study of the Robustness of MacOS Applications Using Random Testing > ACM SIGOPS Operating Systems Review 41(1) 78--86 (January 2007) > https://doi.org/10.1145/1228291.1228308 > > I have used their techniques and tools many times in testing my own, > and other, software. > > By chance, I found today in Web searches on another subject that > Milller's group has a new paper in press in the journal IEEE > Transactions on Software Engineering: > > The Relevance of Classic Fuzz Testing: Have We Solved This One? > https://doi.org/10.1109/TSE.2020.3047766 > https://arxiv.org/abs/2008.06537 > https://ieeexplore.ieee.org/document/9309406 > > I track that journal at > > http://www.math.utah.edu/pub/tex/bib/ieeetranssoftwengYYYY.{bib,html} > > [YYYY = 1970 to 2020, by decade], but the new paper has not yet been > assigned a journal issue, so I had not seen it before today. > > The Miller group work over 33 years has examined the reliability of > common Unix tools in the face of unexpected input, and in the original > work that began in 1988, they were able to demonstrate a significant > failure rate in common, and widely used, Unix-family utilities. > Despite wide publicity of their first paper, things have not got much > better, even from reprogramming software tools in `safe' languages, > such as Rust. > > In each paper, they analyze the reasons for the exposed bugs, and > sadly, much the same reasons still exist in their latest study, and in > several cases, have been introduced into code since their first work. > > The latest paper also contains mention of Plan 9, which moved > bug-prone input line editing into the window system, and of bugs in > pdftex (they say latex, but I suspect they mean pdflatex, not latex > itself: pdflatex is a macro-package enhanced layer over the pdftex > engine, which is a modified TeX engine). The latter are significant > to me and my friends and colleagues in the TeX community, and for the > TeX Live 2021 production team > > http://www.math.utah.edu/pub/texlive-utah/ > > especially because this year, Don Knuth revisited TeX and Metafont, > produced new bug-fixed versions of both, plus updated anniversary > editions of his five-volume Computers & Typesetting book series. His > recent work is described in a new paper announced this morning: > > The \TeX{} tuneup of 2021 > TUGboat 42(1) ??--?? February 2021 > https://tug.org/TUGboat/tb42-1/tb130knuth-tuneup21.pdf > > Perhaps one or more list members might enjoy the exercise of applying > the Barton-group fuzz tests (all of which are available from a Web > site > > ftp://ftp.cs.wisc.edu/paradyn/fuzz/fuzz-2020/ > > as discussed in their paper) to 1970s and 1980s vintage Unix systems > that they run on software-simulated CPUs (or rarely, on real vintage > hardware). > > The Unix tools of those decades were generally much smaller (in lines > of code), and most were written by the expert Unix pioneers at Bell > Labs. It would of interest to compare the tool failure rates in > vintage Unix with tool versions offered by commercial distributions, > the GNU Project, and the FreeBSD community, all of which are treated > in the 2021 paper. > > ------------------------------------------------------------------------------- > - Nelson H. F. Beebe Tel: +1 801 581 5254 - > - University of Utah FAX: +1 801 581 4148 - > - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - > - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - > - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - > ------------------------------------------------------------------------------- -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From heinz at osta.com Fri Apr 9 08:25:16 2021 From: heinz at osta.com (Heinz Lycklama) Date: Thu, 8 Apr 2021 15:25:16 -0700 Subject: [TUHS] Story about Microsoft and *ix In-Reply-To: References: Message-ID: As part of UNIX/Xenix history it is interesting to note that Microsoft did participate in the early /usr/group Standard. We started this work in 1981 and produced the Standard in November 1984. The Standard focused primarily on the C language interface to the UNIX operating system. We made every effort to include as many companies as possible in the development of UNIX systems, Including UNIX-like systems, and companies involved in developing UNIX applications. About 70 people from more than 50 companies are listed as involved in the development of the /usr/group Standard. This included IBM, AT&T, DEC, SCO, ISC, plus many other companies - large and small. Henry Burgess of Microsoft was one of the early members, but Bill Gates stopped his participation in this standards effort about one year after the start of this standards effort, as I recall. At the end of the development of this standard, further work on standardization was handed over to IEEE for the development of the POSIX Standard. The first edition of the IEEE Standard Portable Operating System Interface for Computer Environments (IEEE Std 1003.1) was published in 1988. Heinz On 4/8/2021 12:24 AM, Thomas Paulsen wrote: > Hi, > please red > http://www.softpanorama.org/People/Torvalds/Finland_period/xenix_microsoft_shortlived_love_affair_with_unix.shtml > before posting. I can confirm many of the topics the author mentions.­ > > *Von:* Dan Stromberg > *Datum:* 08.04.2021 07:21:12 > *An:* TUHS main list > *Betreff:* [TUHS] Story about Microsoft and *ix > > I heard a while back, that the reason that Microsoft has avoided > *ix so meticulously, was that back when they sold Xenix to SCO, as > part of the deal Microsoft signed a noncompete agreement that > prevented them from selling anything at all similar to *ix. > True? > > > > *Gesendet mit Firemail.de - Freemail* -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Fri Apr 9 08:31:37 2021 From: imp at bsdimp.com (Warner Losh) Date: Thu, 8 Apr 2021 16:31:37 -0600 Subject: [TUHS] PC Unix In-Reply-To: References: Message-ID: On Wed, Apr 7, 2021 at 1:54 AM Paul Ruizendaal via TUHS < tuhs at minnie.tuhs.org> wrote: > It seems like Venix/86 came out in Spring 1983 and PC/IX in Spring 1984. I > guess by then RAM had become cheap enough that running in 64KB of core was > no longer a requirement and LSX and MX did not make sense anymore. Does > that sound right? > Venix/86 2.0 (still 7th edition) requires 192k to run, at least on my Rainbow, and get to login:. 128k and 64k simply are too small configurations to run it. There's not a lot of 'fat' in the Venix kernel and more-modern compilers only are able to make modest gains over the primitive pcc used at the time. The raw kernel for pc/ix is a few k larger than the venix kernel. So I'm guessing that's right. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsteve at superglobalmegacorp.com Fri Apr 9 15:31:48 2021 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Fri, 9 Apr 2021 13:31:48 +0800 Subject: [TUHS] SUN (Stanford University Network) was PC Unix Message-ID: <0F0B9BFC06289346B88512B91E55670D3012@EXCHANGE> Is there any solid info on the Stanford SUN boards? I just know the SUN-1 was based around them, but they aren't the same thing? And apparently cisco used them as well but 'borrowed' someone's RTOS design as the basis for IOS? There was some lawsuit and Stanford got cisco network gear for years for free but they couldn't take stock for some reason? I see more and more of these CP/M SBC's on ebay/online and it seems odd that there is no 'DIY' SUN boards... Or were they not all that open, hence why they kind of disappeared? -----Original Message----- From: Jon Steinhart To: tuhs at minnie.tuhs.org Sent: 4/8/21 7:04 AM Subject: Re: [TUHS] PC Unix Larry McVoy writes: > On Thu, Apr 08, 2021 at 12:18:04AM +0200, Thomas Paulsen wrote: > > >From: John Gilmore > > >Sun was making 68000-based systems in 1981, before the IBM PC was created. > > > > Sun was founded on February 24, 1982. The Sun-1 was launched in May 1982. > > > > https://en.wikipedia.org/wiki/Sun_Microsystems > > https://en.wikipedia.org/wiki/Sun-1 > > John may be sort of right, I bet avb was building 68k machines at > Stanford before SUN was founded. Sun stood for Stanford University > Network I believe. > > --lm Larry is correct. I remember visiting a friend of mind, Gary Newman, who was working at Lucasfilm in '81. He showed me a bunch of stuff that they were doing on Stanford University Network boards. Full disclosure, it was Gary and Paul Rubinfeld who ended up at DEC and I believe was the architect for the microVax who told me about the explorer scout post at BTL which is how I met Heinz. Jon From jon at fourwinds.com Fri Apr 9 16:13:26 2021 From: jon at fourwinds.com (Jon Steinhart) Date: Thu, 08 Apr 2021 23:13:26 -0700 Subject: [TUHS] SUN (Stanford University Network) was PC Unix In-Reply-To: <0F0B9BFC06289346B88512B91E55670D3012@EXCHANGE> References: <0F0B9BFC06289346B88512B91E55670D3012@EXCHANGE> Message-ID: <202104090613.1396DQ4L359474@darkstar.fourwinds.com> Jason Stevens writes: > Is there any solid info on the Stanford SUN boards? I just know the SUN-1 > was based around them, but they aren't the same thing? And apparently cisco > used them as well but 'borrowed' someone's RTOS design as the basis for IOS? > There was some lawsuit and Stanford got cisco network gear for years for > free but they couldn't take stock for some reason? > > I see more and more of these CP/M SBC's on ebay/online and it seems odd that > there is no 'DIY' SUN boards... Or were they not all that open, hence why > they kind of disappeared? I don't know if Tom Duff was at Lucasfilm at that time but if we was he would likely know. Jon From rdm at cfcl.com Fri Apr 9 16:34:24 2021 From: rdm at cfcl.com (Rich Morin) Date: Thu, 8 Apr 2021 23:34:24 -0700 Subject: [TUHS] SUN (Stanford University Network) was PC Unix In-Reply-To: <202104090613.1396DQ4L359474@darkstar.fourwinds.com> References: <0F0B9BFC06289346B88512B91E55670D3012@EXCHANGE> <202104090613.1396DQ4L359474@darkstar.fourwinds.com> Message-ID: <57A6F4B4-60F4-4211-9625-70BE6F23201D@cfcl.com> There's a story I've heard about the SUN-1 board that I'd love to have confirmed, etc. Basically, it says that Stanford wrote a letter saying that they didn't make any claims on Andy's work (because he was only an undergraduate, so how important could it be, anyway...). -r From lars at nocrew.org Fri Apr 9 17:22:08 2021 From: lars at nocrew.org (Lars Brinkhoff) Date: Fri, 09 Apr 2021 07:22:08 +0000 Subject: [TUHS] SUN (Stanford University Network) was PC Unix In-Reply-To: <0F0B9BFC06289346B88512B91E55670D3012@EXCHANGE> (Jason Stevens's message of "Fri, 9 Apr 2021 13:31:48 +0800") References: <0F0B9BFC06289346B88512B91E55670D3012@EXCHANGE> Message-ID: <7wk0pb6hy7.fsf@junk.nocrew.org> Jason Stevens wrote: > Is there any solid info on the Stanford SUN boards? I believe SAIL PDP-10 backup tapes have a large amount of files about the Stanford SUN project. But due to privacy concerns it would not be easy to make the information public. Maybe if there were a concerted effort to contact Vaughan Pratt, Andy Bechtolsheim, et al, and ask their permission. From lars at nocrew.org Fri Apr 9 19:29:34 2021 From: lars at nocrew.org (Lars Brinkhoff) Date: Fri, 09 Apr 2021 09:29:34 +0000 Subject: [TUHS] SUN (Stanford University Network) was PC Unix In-Reply-To: <7wk0pb6hy7.fsf@junk.nocrew.org> (Lars Brinkhoff's message of "Fri, 09 Apr 2021 07:22:08 +0000") References: <0F0B9BFC06289346B88512B91E55670D3012@EXCHANGE> <7wk0pb6hy7.fsf@junk.nocrew.org> Message-ID: <7wczv36c1t.fsf@junk.nocrew.org> > Jason Stevens wrote: >> Is there any solid info on the Stanford SUN boards? July 1979. This seems to hint at future graphical workstations, but the concept has not settled. https://stacks.stanford.edu/file/druid:yj974vz9257/yj974vz9257.pdf March 1980. The SUN workstation seems to be designed. However, it's a multi user machine with up to 16 displays, rather than a single user workstation. https://stacks.stanford.edu/file/druid:gg867qx3134/gg867qx3134.pdf January 1981. Still a work in progress. Number of display is down to two for a "VLSI workstation", or eight for a "terminal cluster". https://stacks.stanford.edu/file/druid:yx961bt1370/yx961bt1370.pdf March 1982. This is probably the final design with a single 1024x800 display. http://i.stanford.edu/pub/cstr/reports/csl/tr/82/229/CSL-TR-82-229.pdf From emu at e-bbes.com Fri Apr 9 20:12:40 2021 From: emu at e-bbes.com (emanuel stiebler) Date: Fri, 9 Apr 2021 06:12:40 -0400 Subject: [TUHS] SUN (Stanford University Network) was PC Unix In-Reply-To: <0F0B9BFC06289346B88512B91E55670D3012@EXCHANGE> References: <0F0B9BFC06289346B88512B91E55670D3012@EXCHANGE> Message-ID: <0f581f48-6f1e-0f7e-45e7-38469f4e4012@e-bbes.com> On 2021-04-09 01:31, Jason Stevens wrote: > I see more and more of these CP/M SBC's on ebay/online and it seems odd that > there is no 'DIY' SUN boards... Or were they not all that open, hence why > they kind of disappeared? You're comparing a z80 SBC running CP/M? Or are you thinking of 68000 SBCs? From ullbeking at andrewnesbit.org Fri Apr 9 21:13:17 2021 From: ullbeking at andrewnesbit.org (U'll Be King of the Stars) Date: Fri, 9 Apr 2021 12:13:17 +0100 Subject: [TUHS] SUN (Stanford University Network) was PC Unix In-Reply-To: <0f581f48-6f1e-0f7e-45e7-38469f4e4012@e-bbes.com> References: <0F0B9BFC06289346B88512B91E55670D3012@EXCHANGE> <0f581f48-6f1e-0f7e-45e7-38469f4e4012@e-bbes.com> Message-ID: On 09/04/2021 11:12, emanuel stiebler wrote: > You're comparing a z80 SBC running CP/M? Or are you thinking of 68000 SBCs? I've never seen a 68k SBC. Have I missed out something along the way? Is there a community for 68k SBC's? Kind regards, Andrew From pugs at ieee.org Sat Apr 10 00:08:58 2021 From: pugs at ieee.org (Tom Lyon) Date: Fri, 9 Apr 2021 07:08:58 -0700 Subject: [TUHS] SUN (Stanford University Network) was PC Unix In-Reply-To: <0F0B9BFC06289346B88512B91E55670D3012@EXCHANGE> References: <0F0B9BFC06289346B88512B91E55670D3012@EXCHANGE> Message-ID: Prior to Sun, Andy had a company called VLSI Technology, Inc. which licensed SUN designs to 5-10 companies, including Forward Technology and CoData, IIRC. The SUN IPR effectively belonged to Andy, but I don't know what kind of legal arrangement he had with Stanford. But the design was not generally public, and relied on CAD tools only extant on the Stanford PDP-10. Cisco did start with the SUN-1 processor, though whether they got it from Andy or direct from Stanford is not known to me. When Cisco started (1984), the Sun-1 was long dead already at Sun. After both Sun and Cisco, Stanford got serious about holding on to IPR. On Thu, Apr 8, 2021 at 10:12 PM Jason Stevens < jsteve at superglobalmegacorp.com> wrote: > Is there any solid info on the Stanford SUN boards? I just know the SUN-1 > was based around them, but they aren't the same thing? And apparently > cisco > used them as well but 'borrowed' someone's RTOS design as the basis for > IOS? > There was some lawsuit and Stanford got cisco network gear for years for > free but they couldn't take stock for some reason? > > I see more and more of these CP/M SBC's on ebay/online and it seems odd > that > there is no 'DIY' SUN boards... Or were they not all that open, hence why > they kind of disappeared? > > -----Original Message----- > From: Jon Steinhart > To: tuhs at minnie.tuhs.org > Sent: 4/8/21 7:04 AM > Subject: Re: [TUHS] PC Unix > > Larry McVoy writes: > > On Thu, Apr 08, 2021 at 12:18:04AM +0200, Thomas Paulsen wrote: > > > >From: John Gilmore > > > >Sun was making 68000-based systems in 1981, before the IBM PC was > created. > > > > > > Sun was founded on February 24, 1982. The Sun-1 was launched in May > 1982. > > > > > > https://en.wikipedia.org/wiki/Sun_Microsystems > > > https://en.wikipedia.org/wiki/Sun-1 > > > > John may be sort of right, I bet avb was building 68k machines at > > Stanford before SUN was founded. Sun stood for Stanford University > > Network I believe. > > > > --lm > > Larry is correct. I remember visiting a friend of mind, Gary Newman, > who was working at Lucasfilm in '81. He showed me a bunch of stuff > that they were doing on Stanford University Network boards. > > Full disclosure, it was Gary and Paul Rubinfeld who ended up at DEC > and I believe was the architect for the microVax who told me about > the explorer scout post at BTL which is how I met Heinz. > > Jon > -- - Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From velocityboy at gmail.com Sat Apr 10 00:23:49 2021 From: velocityboy at gmail.com (Jim Geist) Date: Fri, 9 Apr 2021 10:23:49 -0400 Subject: [TUHS] SUN (Stanford University Network) was PC Unix In-Reply-To: References: <0F0B9BFC06289346B88512B91E55670D3012@EXCHANGE> Message-ID: Fun trivia fact, at least until the mid 90's, the Stanford University Bookstore still had SPARCstations as the machine they sold to students. On Fri, Apr 9, 2021 at 10:10 AM Tom Lyon wrote: > Prior to Sun, Andy had a company called VLSI Technology, Inc. which > licensed SUN designs to 5-10 companies, including Forward Technology and > CoData, IIRC. The SUN IPR effectively belonged to Andy, but I don't know > what kind of legal arrangement he had with Stanford. But the design was > not generally public, and relied on CAD tools only extant on the Stanford > PDP-10. Cisco did start with the SUN-1 processor, though whether they got > it from Andy or direct from Stanford is not known to me. When Cisco > started (1984), the Sun-1 was long dead already at Sun. > > After both Sun and Cisco, Stanford got serious about holding on to IPR. > > On Thu, Apr 8, 2021 at 10:12 PM Jason Stevens < > jsteve at superglobalmegacorp.com> wrote: > >> Is there any solid info on the Stanford SUN boards? I just know the SUN-1 >> was based around them, but they aren't the same thing? And apparently >> cisco >> used them as well but 'borrowed' someone's RTOS design as the basis for >> IOS? >> There was some lawsuit and Stanford got cisco network gear for years for >> free but they couldn't take stock for some reason? >> >> I see more and more of these CP/M SBC's on ebay/online and it seems odd >> that >> there is no 'DIY' SUN boards... Or were they not all that open, hence why >> they kind of disappeared? >> >> -----Original Message----- >> From: Jon Steinhart >> To: tuhs at minnie.tuhs.org >> Sent: 4/8/21 7:04 AM >> Subject: Re: [TUHS] PC Unix >> >> Larry McVoy writes: >> > On Thu, Apr 08, 2021 at 12:18:04AM +0200, Thomas Paulsen wrote: >> > > >From: John Gilmore >> > > >Sun was making 68000-based systems in 1981, before the IBM PC was >> created. >> > > >> > > Sun was founded on February 24, 1982. The Sun-1 was launched in May >> 1982. >> > > >> > > https://en.wikipedia.org/wiki/Sun_Microsystems >> > > https://en.wikipedia.org/wiki/Sun-1 >> > >> > John may be sort of right, I bet avb was building 68k machines at >> > Stanford before SUN was founded. Sun stood for Stanford University >> > Network I believe. >> > >> > --lm >> >> Larry is correct. I remember visiting a friend of mind, Gary Newman, >> who was working at Lucasfilm in '81. He showed me a bunch of stuff >> that they were doing on Stanford University Network boards. >> >> Full disclosure, it was Gary and Paul Rubinfeld who ended up at DEC >> and I believe was the architect for the microVax who told me about >> the explorer scout post at BTL which is how I met Heinz. >> >> Jon >> > > > -- > - Tom > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Sat Apr 10 00:41:02 2021 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 9 Apr 2021 10:41:02 -0400 (EDT) Subject: [TUHS] SUN (Stanford University Network) was PC Unix Message-ID: <20210409144102.2926D18C08D@mercury.lcs.mit.edu> > From: Jason Stevens > apparently cisco used them as well but 'borrowed' someone's RTOS design > as the basis for IOS? There was some lawsuit and Stanford got cisco > network gear for years for free but they couldn't take stock for some > reason? I don't know the whole story, but there was some kind of scandal; I vaguely recall stories about 'missing' tapes being 'found' under the machine room raised floor... The base software for the Cisco multi-protocol router was code done by William (Bill) Yeager at Stanford (it handled IP and PUP); I have a vgue memory that his initially ran on PDP-11's, like mine. (I think their use of that code was part of the scandal, but I've forgotten the details.) > From: Tom Lyon > the design ... relied on CAD tools only extant on the Stanford PDP-10. Sounds like SUDS? Noel From clemc at ccc.com Sat Apr 10 01:08:22 2021 From: clemc at ccc.com (Clem Cole) Date: Fri, 9 Apr 2021 11:08:22 -0400 Subject: [TUHS] SUN (Stanford University Network) was PC Unix In-Reply-To: <57A6F4B4-60F4-4211-9625-70BE6F23201D@cfcl.com> References: <0F0B9BFC06289346B88512B91E55670D3012@EXCHANGE> <202104090613.1396DQ4L359474@darkstar.fourwinds.com> <57A6F4B4-60F4-4211-9625-70BE6F23201D@cfcl.com> Message-ID: On Fri, Apr 9, 2021 at 2:35 AM Rich Morin wrote: > There's a story I've heard about the SUN-1 board that I'd love to have > confirmed, etc. Basically, it says that Stanford wrote a letter saying > that they didn't make any claims on Andy's work (because he was only an > undergraduate, so how important could it be, anyway...). > Sounds a bit far featured since he did his undergrad at CMU ;-) What Andy designed would (the best I can tell) have started as the 3rd generation processor board for the CMU's distributed front-end (n-th generation of the CMU front end system). The CMU terminal front end was originally a single 11/20 with a lot of ASLI's (asynchronous line interfaces) in them with a parallel connection to the PDP-10s or other larger hosts. The problem was it did not scale and when then Unix machines began to replicate around campus, having a terminal on more than one host was needed, so the distributed front-end was created (by Jim Teter I think). But we started to allow the separated 11/20s to talk to each other. But when the LSI-11s and the Alto's from Xerox appeared a more network-based distributed front-end was built using an LSI-11 chassis. We used an early TCP draft for the protocols and was my introduction to that protocol, as I was part of the crew that switched it to be a Multbus based system and then an Intel 8085 and a Xerox 3M interface, plus an n-port serial board because the LSI-1 based systems were fairly expensive. I've forgotten now, but we might have had a Z80 based processor at some point, as Phil Karn I know had a Z80 C compiler we were using too and the 8085 stuff was assembler if I remember right. IIRC recall somebody at Stanford (Bill Yeager ??maybe??) was doing something similar to the LSI-11 system we were working. How much was Stanford first before CMU I can not say. The 11/20 FE did predate it all, but the two LSI-11s were sort of parallel efforts. I Also thought MIT was doing something ChaosNet around the same time, Noah can fill you in more I suspect. About 2 years later, Andy built a simple 68000 processor [using SUDS - which was what CMU used for Designs in those days] for the multibus version of the DFE, and at some point, somebody (maybe Andy) switched it to an Intel Ethernet board. None of the Multibus or LSI-11 based DFE's had an MMU associated with them. Andy did take took his 68000 CPU design with him to Stanford when he was a grad student and famously redid it adding an MMU and a lot of other features [i.e. CMU board != Stanford Board]. By this time the CMU 'SPICE' proposal had appeared and the idea of the "3M" workstation was being batted around. The Stanford Univerity Network Terminal was created that took his reimagined CPU, the raster display, and other features (I think he was able to get the ethernet on the CPU board by then) -- note it still is using a Multibus-I was the backplane and memory was on a separate board. Stanford licensed the SUN-1 design to a number of firms and while the IP was generally available it was licensed. Cisco made their first router with it, which had a basic architecture that is not unlike the CMU-DFE. Imagin used them for their laser printers. VLSI Technologies would be found (and later renamed SUN) to make them ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Apr 10 01:11:52 2021 From: clemc at ccc.com (Clem Cole) Date: Fri, 9 Apr 2021 11:11:52 -0400 Subject: [TUHS] SUN (Stanford University Network) was PC Unix In-Reply-To: References: <0F0B9BFC06289346B88512B91E55670D3012@EXCHANGE> Message-ID: On Fri, Apr 9, 2021 at 10:10 AM Tom Lyon wrote: > Prior to Sun, Andy had a company called VLSI Technology, Inc. which > licensed SUN designs to 5-10 companies, including Forward Technology and > CoData, IIRC. The SUN IPR effectively belonged to Andy, but I don't know > what kind of legal arrangement he had with Stanford. But the design was > not generally public, and relied on CAD tools only extant on the Stanford > PDP-10. Cisco did start with the SUN-1 processor, though whether they got > it from Andy or direct from Stanford is not known to me. When Cisco > started (1984), the Sun-1 was long dead already at Sun. > Bits passing in the night -- this very much is what I remember, expereinced. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Apr 10 01:18:24 2021 From: clemc at ccc.com (Clem Cole) Date: Fri, 9 Apr 2021 11:18:24 -0400 Subject: [TUHS] SUN (Stanford University Network) was PC Unix In-Reply-To: <20210409144102.2926D18C08D@mercury.lcs.mit.edu> References: <20210409144102.2926D18C08D@mercury.lcs.mit.edu> Message-ID: On Fri, Apr 9, 2021 at 10:41 AM Noel Chiappa wrote: > > The base software for the Cisco multi-protocol router was code done by > William > (Bill) Yeager at Stanford (it handled IP and PUP); I have a vgue memory > that > his initially ran on PDP-11's, like mine. (I think their use of that code > was > part of the scandal, but I've forgotten the details.) > It might have been 11/20's, but I thought he had LSIs at that point (but I can be miss remember). It was much more sophisticated and was really building a router, the CMU DFE was not. We wanted a terminal mux. So were primarily interested in telnet. As I mentioned to Lars in another thread, here is where I learned of SUPDUP for some of the LISPers. But we > > > From: Tom Lyon > > > the design ... relied on CAD tools only extant on the Stanford > PDP-10. > > Sounds like SUDS? > Yes -- SUDS ran on the CMU-10s and 3-River's GDPs (through the FE) -- it was the CAD tool we used at CMU in the mid-late 1980s - the first tool I learned. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Sat Apr 10 01:34:17 2021 From: pnr at planet.nl (Paul Ruizendaal) Date: Fri, 9 Apr 2021 17:34:17 +0200 Subject: [TUHS] SUN (Stanford University Network) was PC Unix Message-ID: <0BD38829-5E79-4034-BCEF-0555434E52A4@planet.nl> > On 09/04/2021 11:12, emanuel stiebler wrote: > You're comparing a z80 SBC running CP/M? Or are you thinking of 68000 SBCs? Z80 CP/M machines were still competitive in 1981-1983 (Osborne, Kaypro) > I've never seen a 68k SBC. Have I missed out something along the way? Is there a community for 68k SBC's? Kind regards, Andrew Well, Rob Pike designed one: http://doc.cat-v.org/bell_labs/blit/ I guess the original hacker scene for the 68K was around Hal Hardenberg’s newsletter: https://en.wikipedia.org/wiki/DTACK_Grounded The ready-made 68K SBC’s only arrived 1984-1985: https://en.wikipedia.org/wiki/Sinclair_QL (I think Linus Torvalds owned one) https://en.wikipedia.org/wiki/Atari_ST https://en.wikipedia.org/wiki/Macintosh_128K https://en.wikipedia.org/wiki/Amiga_1000 All these machines are rather similar at the hardware level - 68K processor, RAM shared between CPU and display. Only the Amiga had a (simple) hardware GPU. What set the SUN-1 apart was its MMU, which none of the above have. What influenced the timing was probably that Motorola made the 68K more affordable by the mid-80’s. Paul From crossd at gmail.com Sat Apr 10 03:01:54 2021 From: crossd at gmail.com (Dan Cross) Date: Fri, 9 Apr 2021 13:01:54 -0400 Subject: [TUHS] SUN (Stanford University Network) was PC Unix In-Reply-To: <0BD38829-5E79-4034-BCEF-0555434E52A4@planet.nl> References: <0BD38829-5E79-4034-BCEF-0555434E52A4@planet.nl> Message-ID: On Fri, Apr 9, 2021 at 11:35 AM Paul Ruizendaal via TUHS < tuhs at minnie.tuhs.org> wrote: > > On 09/04/2021 11:12, emanuel stiebler wrote: > You're comparing a z80 > SBC running CP/M? Or are you thinking of 68000 SBCs? > > Z80 CP/M machines were still competitive in 1981-1983 (Osborne, Kaypro) > > I've never seen a 68k SBC. Have I missed out something along the way? Is > there a community for 68k SBC's? Kind regards, Andrew > There is an active community around DIY 68k SBCs these days. Some representative examples: https://www.eejournal.com/article/wallowing-in-68k-nostalgia/ https://www.ist-schlau.de https://www.bigmessowires.com/category/68katy/ https://github.com/74hc595/68k-nano http://mc68k.blogspot.com/2012_10_01_archive.html There are even a couple of fairly advanced 68030 design floating around: https://www.retrobrewcomputers.org/doku.php?id=boards:sbc:gryphon_68030:start https://www.retrobrewcomputers.org/doku.php?id=boards:ecb:kiss-68030:start (I have a soft spot for 68k.) - Dan C. Well, Rob Pike designed one: http://doc.cat-v.org/bell_labs/blit/ > > I guess the original hacker scene for the 68K was around Hal Hardenberg’s > newsletter: https://en.wikipedia.org/wiki/DTACK_Grounded > > The ready-made 68K SBC’s only arrived 1984-1985: > > https://en.wikipedia.org/wiki/Sinclair_QL (I think Linus Torvalds owned > one) > https://en.wikipedia.org/wiki/Atari_ST > https://en.wikipedia.org/wiki/Macintosh_128K > https://en.wikipedia.org/wiki/Amiga_1000 > > All these machines are rather similar at the hardware level - 68K > processor, RAM shared between CPU and display. Only the Amiga had a > (simple) hardware GPU. > > What set the SUN-1 apart was its MMU, which none of the above have. > > What influenced the timing was probably that Motorola made the 68K more > affordable by the mid-80’s. > > Paul > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aek at bitsavers.org Sat Apr 10 03:02:21 2021 From: aek at bitsavers.org (Al Kossow) Date: Fri, 9 Apr 2021 10:02:21 -0700 Subject: [TUHS] SUN (Stanford University Network) was PC Unix In-Reply-To: <7wk0pb6hy7.fsf@junk.nocrew.org> References: <0F0B9BFC06289346B88512B91E55670D3012@EXCHANGE> <7wk0pb6hy7.fsf@junk.nocrew.org> Message-ID: On 4/9/21 12:22 AM, Lars Brinkhoff wrote: > Jason Stevens wrote: >> Is there any solid info on the Stanford SUN boards? > > I believe SAIL PDP-10 backup tapes have a large amount of files about > the Stanford SUN project. But due to privacy concerns it would not be > easy to make the information public. Maybe if there were a concerted > effort to contact Vaughan Pratt, Andy Bechtolsheim, et al, and ask their > permission. > All of the schematics and prom dumps of the Stanford version are on bitsavers, CPU, 3m Ethernet, and frame buffer. The VLSI Systems design sold by Andy before Sun was founded is the original SUN design. The 3meg ethernet was used at PARC for the Dicentra router, I don't know if any third parties licensed the frame buffer, maybe Lucasfilm. Stanford extended the original design for campus routers with more memory. There was an example of that board in a display case in the Gates building before the remodeling started. If you were going after permission, it would also be good to get SAIL's version of SUDS and if they have it the LLNL S1 designs and software. From stewart at serissa.com Sat Apr 10 03:20:53 2021 From: stewart at serissa.com (Lawrence Stewart) Date: Fri, 9 Apr 2021 13:20:53 -0400 Subject: [TUHS] SUN (Stanford University Network) was PC Unix In-Reply-To: References: <0BD38829-5E79-4034-BCEF-0555434E52A4@planet.nl> Message-ID: <974CFAC9-6951-4495-B01B-3A6401183815@serissa.com> When Digital Systems Research Lab started in 1984 after the implosion of PARC CSL, the first machine we built was a 68000 (68010?) version of the Firefly multiprocessor. We were able to score some MicroVAX II chips soon enough that we redesigned using those, which was, ahem, more politically astute at Digital. Only a few 68K versions were built. The Firefly supported a Unix/Ultrix system call interface but otherwise used unrelated software. (Funny story about close(2). The initial version raised a Modula-2 signal when you tried to close an already closed file, which was very slow. The OS folks, unused to Unix, had no idea that was something you do all the time.) Regarding the SUN-1 design, I had heard a rumor that it was designed using TTL “typical” propagation delays rather than worst case, and as a result was fairly flakey. This caused me to not join sun early since Eric Schmidt had the office next to me. One of my many life mistakes. -Larry > On 2021, Apr 9, at 1:01 PM, Dan Cross wrote: > > On Fri, Apr 9, 2021 at 11:35 AM Paul Ruizendaal via TUHS > wrote: > > On 09/04/2021 11:12, emanuel stiebler wrote: > You're comparing a z80 SBC running CP/M? Or are you thinking of 68000 SBCs? > > Z80 CP/M machines were still competitive in 1981-1983 (Osborne, Kaypro) > > > I've never seen a 68k SBC. Have I missed out something along the way? Is there a community for 68k SBC's? Kind regards, Andrew > > There is an active community around DIY 68k SBCs these days. Some representative examples: > > https://www.eejournal.com/article/wallowing-in-68k-nostalgia/ > https://www.ist-schlau.de > https://www.bigmessowires.com/category/68katy/ > https://github.com/74hc595/68k-nano > http://mc68k.blogspot.com/2012_10_01_archive.html > > There are even a couple of fairly advanced 68030 design floating around: > > https://www.retrobrewcomputers.org/doku.php?id=boards:sbc:gryphon_68030:start > https://www.retrobrewcomputers.org/doku.php?id=boards:ecb:kiss-68030:start > > (I have a soft spot for 68k.) > > - Dan C. > > Well, Rob Pike designed one: http://doc.cat-v.org/bell_labs/blit/ > > I guess the original hacker scene for the 68K was around Hal Hardenberg’s newsletter: https://en.wikipedia.org/wiki/DTACK_Grounded > > The ready-made 68K SBC’s only arrived 1984-1985: > > https://en.wikipedia.org/wiki/Sinclair_QL (I think Linus Torvalds owned one) > https://en.wikipedia.org/wiki/Atari_ST > https://en.wikipedia.org/wiki/Macintosh_128K > https://en.wikipedia.org/wiki/Amiga_1000 > > All these machines are rather similar at the hardware level - 68K processor, RAM shared between CPU and display. Only the Amiga had a (simple) hardware GPU. > > What set the SUN-1 apart was its MMU, which none of the above have. > > What influenced the timing was probably that Motorola made the 68K more affordable by the mid-80’s. > > Paul > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robg at fastmail.com Sat Apr 10 03:22:02 2021 From: robg at fastmail.com (Rob Gowin) Date: Fri, 09 Apr 2021 12:22:02 -0500 Subject: [TUHS] SUN (Stanford University Network) was PC Unix In-Reply-To: References: <0F0B9BFC06289346B88512B91E55670D3012@EXCHANGE> <0f581f48-6f1e-0f7e-45e7-38469f4e4012@e-bbes.com> Message-ID: [I see that Dan C. has already covered some of this.] On Fri, Apr 9, 2021, at 6:13 AM, U'll Be King of the Stars wrote: > I've never seen a 68k SBC. Have I missed out something along the way? > Is there a community for 68k SBC's? There is a community of folks making 'retro-brew' computers, which are new home-brew board designs based around older CPUs. While Z80/Z180 based designs are the most popular, there are a smattering of 68K retro-brews. The main places for discussions are https://groups.google.com/g/retro-comp and https://www.retrobrewcomputers.org/forum/index.php. The availability of very cheap PCBs from China (2 layers, 10cm x 10cm, $3 per board shipped, shipped in a week) and open source PCB design software like KiCad seems to have increase the amount of this kind of activity over the past few years. Hardware-wise, most of these are 68000's with some ROM (around 512K is typical), some SRAM (512K to 1 MB), a UART of some kind, and perhaps some storage either SDCard via SPI or CompactFlash via an IDE port. I think only the Kiwi68K supports any type of video, using a vintage TI video chip. Here are a few links to 68K designs: ECB Mini-68K CPU Card (68008 based and not a single board) - https://www.retrobrewcomputers.org/doku.php?id=boards:ecb:mini-68k:start ECB KISS-68030: (68030 based and not a single board) - https://www.retrobrewcomputers.org/doku.php?id=boards:ecb:kiss-68030:start The Rosco M68K: https://rosco-m68k.com The Tobster 030 - https://www.retrobrewcomputers.org/doku.php?id=builderpages:tobster:t030 Jeff Tranter's 68000 - http://jefftranter.blogspot.com/2017/01/building-68000-single-board-computer_14.html Plasmo's Tiny68K - https://www.retrobrewcomputers.org/doku.php?id=boards:sbc:tiny68k:tiny68k_rev2 Plasmo's CB030 - https://www.retrobrewcomputers.org/doku.php?id=builderpages:plasmo:cb030 Kiwi68K - https://www.ist-schlau.de All these designs are open source. The Rosco one is available as a kit on Tindie.com. (I have no affiliation.) I've got my own 68008 based board that I'm working on, but haven't published anything about it. -- I think the main reason the 68K is not more popular in the retro-brew/DIY community is lack of software. On the Z80 side, once you've built a board there is a ton of CP/M-80 software available to run. For 68K boards, the usual software progression is a ROM monitor, then maybe porting of Lee Davison's EhBASIC, then CP/M-68K. CP/M-68K has very little software available, and what is available are microEmacs and a few compilers (K&R C, BASIC and Pascal). That's about it for 68Ks without an MMU. A couple of the boards above that have 68030 do have Linux running on them. There's also the perception that Z80s have an easier hardware interface, but I'm not convinced that's true. -- Rob ECB Mini-68k CPU Card I should disclaim that some of the things I'm about to link to are kits sold on Tindie.com. I have no affiliation with the creators, other than being a fan of their work. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Sat Apr 10 04:32:53 2021 From: jon at fourwinds.com (Jon Steinhart) Date: Fri, 09 Apr 2021 11:32:53 -0700 Subject: [TUHS] SUN (Stanford University Network) was PC Unix In-Reply-To: <974CFAC9-6951-4495-B01B-3A6401183815@serissa.com> References: <0BD38829-5E79-4034-BCEF-0555434E52A4@planet.nl> <974CFAC9-6951-4495-B01B-3A6401183815@serissa.com> Message-ID: <202104091832.139IWrYM394698@darkstar.fourwinds.com> Lawrence Stewart writes: > Regarding the SUN-1 design, I had heard a rumor that it was designed using TTL > “typical” propagation delays rather than worst case, and as a result was fairly > flakey. It's astonishing how common a practice that was back then. From lars at nocrew.org Sat Apr 10 04:37:14 2021 From: lars at nocrew.org (Lars Brinkhoff) Date: Fri, 09 Apr 2021 18:37:14 +0000 Subject: [TUHS] SUN (Stanford University Network) was PC Unix In-Reply-To: (Al Kossow's message of "Fri, 9 Apr 2021 10:02:21 -0700") References: <0F0B9BFC06289346B88512B91E55670D3012@EXCHANGE> <7wk0pb6hy7.fsf@junk.nocrew.org> Message-ID: <7wzgy7484l.fsf@junk.nocrew.org> Al Kossow wrote: > If you were going after permission, it would also be good to get > SAIL's version of SUDS and if they have it the LLNL S1 designs and > software. Yes, those would also be worth persuing. Looks like a big chunk of S1 design files are in there. But the LLNL WAITS system split off from the mothership at some point, so much of the S1 work may not have been present on the SAIL PDP-10. From earl.baugh at gmail.com Sat Apr 10 06:02:54 2021 From: earl.baugh at gmail.com (Earl Baugh) Date: Fri, 9 Apr 2021 16:02:54 -0400 Subject: [TUHS] SUN (Stanford University Network) was PC Unix In-Reply-To: References: Message-ID: I’ve done a fair amount of research on Sun 1’s since I have one ( and it has one of the original 68k motherboards with the original proms ). It’s on my list to create a Sun 1 registry along the lines of the Apple 1 registry. (https://www.apple1registry.com/) Right now, I can positively identify 24 machines that still exist. Odd serial numbering makes it very hard to know exactly how many they made. Cisco was sued by Stanford over the Sun 1. From what I read, they made off with some Stanford property ( SW and HW ). Wikipedia mentions this ( and I have some supporting documents as well ). They ended up licensing from Stanford as part of the settlement. From what I’ve gathered VLSI licensed the design from Stanford not Andy directly. However the only produced a few machines and Andy wasn’t all that happy with that. That was one of the impetus is to getting sun formed and licensing the same design. I also believe another company ( or 2 )licensed the design but either didn’t produce any or very very few machines. You can tell a difference between VLSI boards and the Sun Microsystems boards because the SUN is all capitalized on the VLSI boards ( and is Sun on the others ). At least on the few I’ve seen pictures of. The design was also licensed to SGI — I’ve seen a prototype SGI board that’s the same thing with a larger PCB to allow some extensions. And the original CPU boards didn’t have an MMU. They could only run Sun OS up to 0.9, I believe was the version. When Bill Joy got there, again from what I’ve gathered, he wanted to bring more of the BSD code over and they had to change the system board. This is why you see the Sun 1/150 model number ( as an upgrade to the original Sun 1/100 designation ). The rack mounted Sun 1/120 was changed to the 1/170. The same upgraded CPU board was used in the Sun 2/120 at least initially. The original Sun OS wasn’t BSD based. It was a V32 variant I believe. And the original CPU boards were returned to Sun, I believe as part of the upgrade from the 1/100 to the 1/150. ( Given people had just paid $10,000 for a machine having to replace the entire machine would’ve been bad from a customer perspective). Sun did board upgrade trade ups after this ( I worked at a company and we purchased an upgrade to upgrade a Sun 3/140 to a Sun 3/110 — the upgrade consisted of a CPU board swap and a different badge for the box ) Sun then, from when I can tell, sold the original CPU boards to a German company that was producing a V32 system. They changed out the PROMs but you can see the Sun logo and part numbers on the boards I could go on and on about this topic 🙂 A Sun 1 was a “bucket list” machine for me - and I am still happy that some friends were willing to take a 17 hour road trip from Atlanta to Minnesota to pick mine up. 🙂 After unparking the drive heads it booted up, first try ( I was only willing to try that without a bunch of testing work because I have some spare power supplies and a couple plastic tubs of multi bus boards that came with it 🙂) Earl Sent from my iPhone > On Apr 9, 2021, at 11:13 AM, Clem Cole wrote: > >  > > >> On Fri, Apr 9, 2021 at 10:10 AM Tom Lyon wrote: >> Prior to Sun, Andy had a company called VLSI Technology, Inc. which licensed SUN designs to 5-10 companies, including Forward Technology and CoData, IIRC. The SUN IPR effectively belonged to Andy, but I don't know what kind of legal arrangement he had with Stanford. But the design was not generally public, and relied on CAD tools only extant on the Stanford PDP-10. Cisco did start with the SUN-1 processor, though whether they got it from Andy or direct from Stanford is not known to me. When Cisco started (1984), the Sun-1 was long dead already at Sun. > Bits passing in the night -- this very much is what I remember, expereinced. > ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From aek at bitsavers.org Sat Apr 10 06:08:13 2021 From: aek at bitsavers.org (Al Kossow) Date: Fri, 9 Apr 2021 13:08:13 -0700 Subject: [TUHS] SUN (Stanford University Network) was PC Unix In-Reply-To: References: Message-ID: <731c6353-1adb-f66c-6ff4-d89b257fd0eb@bitsavers.org> On 4/9/21 1:02 PM, Earl Baugh wrote: > And the original CPU boards didn’t have an MMU. wrong They didn't have a 68010 capable of recovering from page faults The original unix shipped on Sun 1's was a Unisoft port. The same one sold by several other companies that sold the original Sun CPU design.l From joe at via.net Sat Apr 10 06:16:41 2021 From: joe at via.net (joe mcguckin) Date: Fri, 9 Apr 2021 13:16:41 -0700 Subject: [TUHS] SUN (Stanford University Network) was PC Unix In-Reply-To: References: <0F0B9BFC06289346B88512B91E55670D3012@EXCHANGE> <0f581f48-6f1e-0f7e-45e7-38469f4e4012@e-bbes.com> Message-ID: <56C98599-7B84-4F5F-948E-49678EC64964@via.net> When I was at SUN, our group’s print server was a SUN-1... Joe McGuckin ViaNet Communications joe at via.net 650-207-0372 cell 650-213-1302 office 650-969-2124 fax > On Apr 9, 2021, at 10:22 AM, Rob Gowin wrote: > > [I see that Dan C. has already covered some of this.] > > On Fri, Apr 9, 2021, at 6:13 AM, U'll Be King of the Stars wrote: >> I've never seen a 68k SBC. Have I missed out something along the way? >> Is there a community for 68k SBC's? > > There is a community of folks making 'retro-brew' computers, which are new home-brew board designs based around older CPUs. While Z80/Z180 based designs are the most popular, there are a smattering of 68K retro-brews. The main places for discussions are https://groups.google.com/g/retro-comp and https://www.retrobrewcomputers.org/forum/index.php . The availability of very cheap PCBs from China (2 layers, 10cm x 10cm, $3 per board shipped, shipped in a week) and open source PCB design software like KiCad seems to have increase the amount of this kind of activity over the past few years. > > Hardware-wise, most of these are 68000's with some ROM (around 512K is typical), some SRAM (512K to 1 MB), a UART of some kind, and perhaps some storage either SDCard via SPI or CompactFlash via an IDE port. I think only the Kiwi68K supports any type of video, using a vintage TI video chip. > > Here are a few links to 68K designs: > > ECB Mini-68K CPU Card (68008 based and not a single board) - https://www.retrobrewcomputers.org/doku.php?id=boards:ecb:mini-68k:start > ECB KISS-68030: (68030 based and not a single board) - https://www.retrobrewcomputers.org/doku.php?id=boards:ecb:kiss-68030:start > The Rosco M68K: https://rosco-m68k.com > The Tobster 030 - https://www.retrobrewcomputers.org/doku.php?id=builderpages:tobster:t030 > Jeff Tranter's 68000 - http://jefftranter.blogspot.com/2017/01/building-68000-single-board-computer_14.html > Plasmo's Tiny68K - https://www.retrobrewcomputers.org/doku.php?id=boards:sbc:tiny68k:tiny68k_rev2 > Plasmo's CB030 - https://www.retrobrewcomputers.org/doku.php?id=builderpages:plasmo:cb030 > Kiwi68K - https://www.ist-schlau.de > > All these designs are open source. The Rosco one is available as a kit on Tindie.com . (I have no affiliation.) I've got my own 68008 based board that I'm working on, but haven't published anything about it. > > -- > > I think the main reason the 68K is not more popular in the retro-brew/DIY community is lack of software. On the Z80 side, once you've built a board there is a ton of CP/M-80 software available to run. For 68K boards, the usual software progression is a ROM monitor, then maybe porting of Lee Davison's EhBASIC, then CP/M-68K. CP/M-68K has very little software available, and what is available are microEmacs and a few compilers (K&R C, BASIC and Pascal). That's about it for 68Ks without an MMU. A couple of the boards above that have 68030 do have Linux running on them. There's also the perception that Z80s have an easier hardware interface, but I'm not convinced that's true. > > -- Rob > > > > > ECB Mini-68k CPU Card > > I should disclaim that some of the things I'm about to link to are kits sold on Tindie.com . I have no affiliation with the creators, other than being a fan of their work. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Apr 10 06:46:14 2021 From: clemc at ccc.com (Clem Cole) Date: Fri, 9 Apr 2021 16:46:14 -0400 Subject: [TUHS] SUN (Stanford University Network) was PC Unix In-Reply-To: <731c6353-1adb-f66c-6ff4-d89b257fd0eb@bitsavers.org> References: <731c6353-1adb-f66c-6ff4-d89b257fd0eb@bitsavers.org> Message-ID: On Fri, Apr 9, 2021 at 4:08 PM Al Kossow wrote: > On 4/9/21 1:02 PM, Earl Baugh wrote: > > > And the original CPU boards didn’t have an MMU. > > wrong > > They didn't have a 68010 capable of recovering from page faults > > The original unix shipped on Sun 1's was a Unisoft port. The same > one sold by several other companies that sold the original Sun CPU > design.l > Right on both counts - his base/limit MMU even had a small PID/Context register which was pretty slick at the time. The MMU I created with Roger Bates for the Tektronix Magonia was not that smart and when I first saw it I did a face plant -- why didn't I think of that. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mparson at bl.org Sat Apr 10 07:24:28 2021 From: mparson at bl.org (Michael Parson) Date: Fri, 9 Apr 2021 16:24:28 -0500 (CDT) Subject: [TUHS] PC Unix (had been How to Kill a Technical Conference In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021, Dave Horsfall wrote: > Date: Tue, 6 Apr 2021 17:41:21 > From: Dave Horsfall > To: The Eunuchs Hysterical Society > Subject: Re: [TUHS] PC Unix (had been How to Kill a Technical Conference > > On Tue, 6 Apr 2021, M Douglas McIlroy wrote: > >> IBM famously failed to buy the well-established CP/M in 1980. (CP/M had >> been introduced in 1974, before the advent of the LSI-11 on which LSX ran.) >> [...] > > And unlike the popular urban myth, Gary Kildall was not out playing golf when > IBM tried to contact him. Gary Killdall was a host on PBS' "The Computer Chronicles" and they did a story on him after his death that covers this, as well as other info on his life and work with DRI. https://www.youtube.com/watch?v=OVqBokd3l2E -- Michael Parson Pflugerville, TX From imp at bsdimp.com Sat Apr 10 08:28:50 2021 From: imp at bsdimp.com (Warner Losh) Date: Fri, 9 Apr 2021 16:28:50 -0600 Subject: [TUHS] SUN (Stanford University Network) was PC Unix In-Reply-To: <202104091832.139IWrYM394698@darkstar.fourwinds.com> References: <0BD38829-5E79-4034-BCEF-0555434E52A4@planet.nl> <974CFAC9-6951-4495-B01B-3A6401183815@serissa.com> <202104091832.139IWrYM394698@darkstar.fourwinds.com> Message-ID: On Fri, Apr 9, 2021 at 12:33 PM Jon Steinhart wrote: > Lawrence Stewart writes: > > Regarding the SUN-1 design, I had heard a rumor that it was designed > using TTL > > “typical” propagation delays rather than worst case, and as a result was > fairly > > flakey. > > It's astonishing how common a practice that was back then. > Even into the 2000s. I had a 6-month long war with one of the hardware guys for a time collection ISA card he did. It worked great, the driver worked great. Life was good. We shipped product. 5 years later, the customer comes back and wants a dozen more. So, we got new parts and 4 of the 6 new cards were flakey, 2 were good. Fingers pointed at the device driver, etc. Long months of intermittent troubleshooting continued for 5 months. During this time I build an ISA bus trace card, showed the traces were good and the flakiness was the result of bad data coming back from the card. At which point they brought in a different hardware guy to look at things. He discovered the first hardware guy had built an async circuit with typical delay patterns. One of the parts we used was rated at 200ns, but parts from the flakey board worked at 50ns. Turns out the manufacturer substituted a faster part, so the 'typical' delay propagation worked for this async circuit, but the faster response time would corrupt data from time to time. The design was tweaked to be synchronous with a latch, and the unmodified driver worked perfectly then... Fun times that... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From earl.baugh at gmail.com Sat Apr 10 11:30:46 2021 From: earl.baugh at gmail.com (Earl Baugh) Date: Fri, 9 Apr 2021 21:30:46 -0400 Subject: [TUHS] SUN (Stanford University Network) was PC Unix In-Reply-To: <731c6353-1adb-f66c-6ff4-d89b257fd0eb@bitsavers.org> References: <731c6353-1adb-f66c-6ff4-d89b257fd0eb@bitsavers.org> Message-ID: <10F4818F-9DF2-40A5-A67A-605CA9B8D8DF@gmail.com> Thanks for clarifying that!! I should have said “I believe it might not have had. I wasn’t quite sure what the problem was which caused the issue. I had in my notes that something would prevent implementing virtual memory ( and that the person thought it might be a missing MMU ). I should have relayed that more accurately. Always appreciate clarifying and better info. I’ll also add the Ubisoft note. I have some copies of a few of the earlier releases but I don’t think the tar files have a company name on them. I’ve not unpacked them yet. Does anyone have any source that has a better “how many Sun 1’s were made” number? I have a few sources that say “maybe 300” and “maybe 400” and “maybe 600”. Obviously that’s not very exact. :-) The serial numbers bounce around ( from the units I’ve identified ) and it’s not clear they started at 1... some info says there was some arbitrary number that they started at. And that chunks of numbers might have been skipped. I’ve just not been able to find a more definitive or more trustworthy source. ( though I haven’t seen if old stock info filings might have more info - but I’m thinking those would have been after the fact, time wise ) Earl Sent from my iPhone > On Apr 9, 2021, at 4:08 PM, Al Kossow wrote: > > On 4/9/21 1:02 PM, Earl Baugh wrote: > >> And the original CPU boards didn’t have an MMU. > > wrong > > They didn't have a 68010 capable of recovering from page faults > > The original unix shipped on Sun 1's was a Unisoft port. The same > one sold by several other companies that sold the original Sun CPU > design.l > From jsteve at superglobalmegacorp.com Sat Apr 10 12:41:18 2021 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Sat, 10 Apr 2021 10:41:18 +0800 Subject: [TUHS] SUN (Stanford University Network) was PC Unix Message-ID: <0F0B9BFC06289346B88512B91E55670D3013@EXCHANGE> I'd totally subscribe to your newsletter :P that's cool, there is a tape dump of the old stuff on bitsavers... the UniSoft port I think was the original stuff before Bill showed up? http://bitsavers.trailing-edge.com/bits/Sun/UniSoft_1.3/ along with some ROM images http://bitsavers.trailing-edge.com/bits/Sun/sun1/ but more pictures and whatnot are always interesting! -----Original Message----- From: Earl Baugh To: Clem Cole Cc: tuhs at minnie.tuhs.org Sent: 4/10/21 4:02 AM Subject: Re: [TUHS] SUN (Stanford University Network) was PC Unix I’ve done a fair amount of research on Sun 1’s since I have one ( and it has one of the original 68k motherboards with the original proms ). It’s on my list to create a Sun 1 registry along the lines of the Apple 1 registry. ( https://www.apple1registry.com/ ) Right now, I can positively identify 24 machines that still exist. Odd serial numbering makes it very hard to know exactly how many they made. Cisco was sued by Stanford over the Sun 1. From what I read, they made off with some Stanford property ( SW and HW ). Wikipedia mentions this ( and I have some supporting documents as well ). They ended up licensing from Stanford as part of the settlement. From what I’ve gathered VLSI licensed the design from Stanford not Andy directly. However the only produced a few machines and Andy wasn’t all that happy with that. That was one of the impetus is to getting sun formed and licensing the same design. I also believe another company ( or 2 )licensed the design but either didn’t produce any or very very few machines. You can tell a difference between VLSI boards and the Sun Microsystems boards because the SUN is all capitalized on the VLSI boards ( and is Sun on the others ). At least on the few I’ve seen pictures of. The design was also licensed to SGI — I’ve seen a prototype SGI board that’s the same thing with a larger PCB to allow some extensions. And the original CPU boards didn’t have an MMU. They could only run Sun OS up to 0.9, I believe was the version. When Bill Joy got there, again from what I’ve gathered, he wanted to bring more of the BSD code over and they had to change the system board. This is why you see the Sun 1/150 model number ( as an upgrade to the original Sun 1/100 designation ). The rack mounted Sun 1/120 was changed to the 1/170. The same upgraded CPU board was used in the Sun 2/120 at least initially. The original Sun OS wasn’t BSD based. It was a V32 variant I believe. And the original CPU boards were returned to Sun, I believe as part of the upgrade from the 1/100 to the 1/150. ( Given people had just paid $10,000 for a machine having to replace the entire machine would’ve been bad from a customer perspective). Sun did board upgrade trade ups after this ( I worked at a company and we purchased an upgrade to upgrade a Sun 3/140 to a Sun 3/110 — the upgrade consisted of a CPU board swap and a different badge for the box ) Sun then, from when I can tell, sold the original CPU boards to a German company that was producing a V32 system. They changed out the PROMs but you can see the Sun logo and part numbers on the boards I could go on and on about this topic ? A Sun 1 was a “bucket list” machine for me - and I am still happy that some friends were willing to take a 17 hour road trip from Atlanta to Minnesota to pick mine up. ? After unparking the drive heads it booted up, first try ( I was only willing to try that without a bunch of testing work because I have some spare power supplies and a couple plastic tubs of multi bus boards that came with it ?) Earl Sent from my iPhone On Apr 9, 2021, at 11:13 AM, Clem Cole wrote: ? On Fri, Apr 9, 2021 at 10:10 AM Tom Lyon < pugs at ieee.org > wrote: Prior to Sun, Andy had a company called VLSI Technology, Inc. which licensed SUN designs to 5-10 companies, including Forward Technology and CoData, IIRC. The SUN IPR effectively belonged to Andy, but I don't know what kind of legal arrangement he had with Stanford. But the design was not generally public, and relied on CAD tools only extant on the Stanford PDP-10. Cisco did start with the SUN-1 processor, though whether they got it from Andy or direct from Stanford is not known to me. When Cisco started (1984), the Sun-1 was long dead already at Sun. Bits passing in the night -- this very much is what I remember, expereinced. ? From dave at horsfall.org Sat Apr 10 12:22:16 2021 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 10 Apr 2021 12:22:16 +1000 (EST) Subject: [TUHS] SUN (Stanford University Network) was PC Unix In-Reply-To: References: <0F0B9BFC06289346B88512B91E55670D3012@EXCHANGE> <0f581f48-6f1e-0f7e-45e7-38469f4e4012@e-bbes.com> Message-ID: On Fri, 9 Apr 2021, U'll Be King of the Stars wrote: > I've never seen a 68k SBC. Have I missed out something along the way? > Is there a community for 68k SBC's? May I introduce you to the Aussie-designed Applix 1616? Not a strict SBC (the disk controller was a separate card): https://en.wikipedia.org/wiki/Applix_1616 There's sort of a mailing list for its users, but it grew to become a tech-head list with an amazing amount of expertise: https://www.object-craft.com.au/cgi-bin/mailman/listinfo/applix-l Disclaimer: I'm a regular poster, and I personally know the list owner (and a lot of the contributors). -- Dave From dave at horsfall.org Sat Apr 10 13:16:23 2021 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 10 Apr 2021 13:16:23 +1000 (EST) Subject: [TUHS] SUN (Stanford University Network) was PC Unix In-Reply-To: <0BD38829-5E79-4034-BCEF-0555434E52A4@planet.nl> References: <0BD38829-5E79-4034-BCEF-0555434E52A4@planet.nl> Message-ID: On Fri, 9 Apr 2021, Paul Ruizendaal via TUHS wrote: > Z80 CP/M machines were still competitive in 1981-1983 (Osborne, Kaypro) And the Aussie Microbee... Wonderful machine, and easily hacked upon. For example, you could expand the memory by soldering several chips on top of each other and addressing the CS* line via bank-switching. -- Dave From egbegb2 at gmail.com Sat Apr 10 13:33:24 2021 From: egbegb2 at gmail.com (Ed Bradford) Date: Fri, 9 Apr 2021 22:33:24 -0500 Subject: [TUHS] PC Unix (had been How to Kill a Technical Conference In-Reply-To: References: Message-ID: The Kildall biography video is WAYYYYY informative. THANK YOU!!! https://www.youtube.com/watch?v=OVqBokd3l2E Why did a Ph.D., an academic, and a computer scientist not know about UNIX in 1974 or so? 1976? In 1976, some (many?) universities had source code. I had an account ("egb") on ucbunix (University of California, Berkeley) in 1978 or so. I was one of the initial "customers" of Bill Joy's "vi". We really need to add Bill Joy to this community. He has a LOT to add to the history of UNIX -- especially from the view from UCB folks. Where is Bill Joy today? Of all the folks I've ever met, Bill Joy is the only one who, had he joined BTL 127, would have had major contributions. He didn't. He went the route of being a founding person with Sun Microsystems. I would have done the same. Bill Joy, where are you? On Fri, Apr 9, 2021 at 4:32 PM Michael Parson wrote: > On Wed, 7 Apr 2021, Dave Horsfall wrote: > > > Date: Tue, 6 Apr 2021 17:41:21 > > From: Dave Horsfall > > To: The Eunuchs Hysterical Society > > Subject: Re: [TUHS] PC Unix (had been How to Kill a Technical Conference > > > > On Tue, 6 Apr 2021, M Douglas McIlroy wrote: > > > >> IBM famously failed to buy the well-established CP/M in 1980. (CP/M had > >> been introduced in 1974, before the advent of the LSI-11 on which LSX > ran.) > >> [...] > > > > And unlike the popular urban myth, Gary Kildall was not out playing golf > when > > IBM tried to contact him. > > Gary Killdall was a host on PBS' "The Computer Chronicles" and they did > a story on him after his death that covers this, as well as other info > on his life and work with DRI. > > https://www.youtube.com/watch?v=OVqBokd3l2E > > -- > Michael Parson > Pflugerville, TX > -- Advice is judged by results, not by intentions. Cicero -------------- next part -------------- An HTML attachment was scrubbed... URL: From davida at pobox.com Sat Apr 10 22:06:34 2021 From: davida at pobox.com (David Arnold) Date: Sat, 10 Apr 2021 22:06:34 +1000 Subject: [TUHS] SUN (Stanford University Network) was PC Unix In-Reply-To: References: Message-ID: <382F4422-D6B8-4749-9927-9EC19FE9CADD@pobox.com> > On 10 Apr 2021, at 13:17, Dave Horsfall wrote: > > On Fri, 9 Apr 2021, Paul Ruizendaal via TUHS wrote: > >> Z80 CP/M machines were still competitive in 1981-1983 (Osborne, Kaypro) > > And the Aussie Microbee... Wonderful machine, and easily hacked upon. > > For example, you could expand the memory by soldering several chips on top of each other and addressing the CS* line via bank-switching. 6116 static RAM meant no mucking about with DRAM refresh either. And the single switch upgrade from 2MHz to 4MHz. Happy days. But I never tried to get a Unix on it. UZI or Fuzix might work? d From clemc at ccc.com Sun Apr 11 01:12:51 2021 From: clemc at ccc.com (Clem Cole) Date: Sat, 10 Apr 2021 11:12:51 -0400 Subject: [TUHS] PC Unix (had been How to Kill a Technical Conference In-Reply-To: References: Message-ID: On Fri, Apr 9, 2021 at 11:34 PM Ed Bradford wrote: > Why did a Ph.D., an academic, and a computer scientist not know about UNIX > in 1974 or so? 1976? In 1976, some (many?) universities had source code. > Some knowns/givens at the time ... 1.) He was a language/compiler type person -- he had created PL/M and that was really what he was originally trying to show off. As I understand it and has been reported in other interviews, originally CP/M was an attempt to show off what you could do with PL/M. 2.) The 8080/Z80 S-100 style machines we quite limited, they had very little memory, no MMU, and extremely limited storage in the 8" floppies 3.) He was familiar with RT/11 and DOS-11, many Universities had it on smaller PDP-11s as they ran on an 11/20 without an MMU also with limited memory, and often used simple (primarily tape) storage (DECtape and Cassette's) as the default 'laboratory' system, replacing the earlier PDP-8 for the same job which primarily ran DOS-8 in those settings. 4.) Fifth and Sixth Edition of Unix was $150 for university but to run it, it took a larger at least 11/40 or 45, with a minimum of 64Kbytes to boot and really need the full 256Kbytes to run acceptably and the cost of a 2.5M byte RK05 disk was much greater per byte than tape -- thus the base system it took to run it was at least $60K (in 1975 dollars) and typically cost about two to four times that in practice. Remember the cost of acquisition of the HW dominated many (most) choices. *I**'ll take a guess, but it is only that.* I *suspect* he saw the S-100 system as closer to a PDP-11/20 'lab' system than as a small timesharing machine. He set out with CP/M to duplication the functionality from RT/11. He even the naming of the commands was the same as what DEC used (*e.g.* PIP) and used the basic DEC style command syntax and parsing rules. > > Bill Joy, where are you? > Some of us, know how to find him. I know that at least at one time, was made aware of this mailing list and have been invited to join it. It is his choice to not be a part. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sun Apr 11 01:41:16 2021 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 10 Apr 2021 08:41:16 -0700 Subject: [TUHS] PC Unix (had been How to Kill a Technical Conference In-Reply-To: References: Message-ID: <20210410154116.GG17236@mcvoy.com> On Sat, Apr 10, 2021 at 11:12:51AM -0400, Clem Cole wrote: > On Fri, Apr 9, 2021 at 11:34 PM Ed Bradford wrote: > > > Why did a Ph.D., an academic, and a computer scientist not know about UNIX > > in 1974 or so? 1976? In 1976, some (many?) universities had source code. > > > > 4.) Fifth and Sixth Edition of Unix was $150 for university but to run it, > it took a larger at least 11/40 or 45, with a minimum of 64Kbytes to boot > and really need the full 256Kbytes to run acceptably and the cost of a 2.5M > byte RK05 disk was much greater per byte than tape -- thus the base system > it took to run it was at least $60K (in 1975 dollars) and typically cost > about two to four times that in practice. Remember the cost of > acquisition of the HW dominated many (most) choices. It was around 1983 or so when I bought a CP/M system, I think an Okidata. It was a weird, but fun, machine, had a printer built into the base behind the keyboard, dual 5" floppies, 128K less the bitmapped color display. $2000. It was slow but dramatically faster than 1/32-164th of a 1MB VAX 780. From pnr at planet.nl Sun Apr 11 04:12:29 2021 From: pnr at planet.nl (Paul Ruizendaal) Date: Sat, 10 Apr 2021 20:12:29 +0200 Subject: [TUHS] PC Unix (had been How to Kill a Technical Conference Message-ID: > On Fri, Apr 9, 2021 at 11:34 PM Ed Bradford > wrote: > > > Why did a Ph.D., an academic, and a computer scientist not know about UNIX > > in 1974 or so? 1976? In 1976, some (many?) universities had source code. > > > > Some knowns/givens at the time ... > 1.) He was a language/compiler type person -- he had created PL/M and that > was really what he was originally trying to show off. As I understand it > and has been reported in other interviews, originally CP/M was an attempt > to show off what you could do with PL/M. > 2.) The 8080/Z80 S-100 style machines we quite limited, they had very > little memory, no MMU, and extremely limited storage in the 8" floppies > 3.) He was familiar with RT/11 and DOS-11, many Universities had it on > smaller PDP-11s as they ran on an 11/20 without an MMU also with limited > memory, and often used simple (primarily tape) storage (DECtape and > Cassette's) as the default 'laboratory' system, replacing the earlier PDP-8 > for the same job which primarily ran DOS-8 in those settings. > 4.) Fifth and Sixth Edition of Unix was $150 for university but to run it, > it took a larger at least 11/40 or 45, with a minimum of 64Kbytes to boot > and really need the full 256Kbytes to run acceptably and the cost of a 2.5M > byte RK05 disk was much greater per byte than tape -- thus the base system > it took to run it was at least $60K (in 1975 dollars) and typically cost > about two to four times that in practice. Remember the cost of > acquisition of the HW dominated many (most) choices. > > *I**'ll take a guess, but it is only that.* I *suspect* he saw the S-100 > system as closer to a PDP-11/20 'lab' system than as a small > timesharing machine. He set out with CP/M to duplication the functionality > from RT/11. He even the naming of the commands was the same as what DEC > used (*e.g.* PIP) and used the basic DEC style command syntax and parsing > rules. That is about it. CP/M predates the Altair / S-100 bus, and was designed for a heavily hacked Intellec-8 system. CP/M was developed on a PDP-10 based 8080 simulator in 1974. It was developed for the dual purposes of creating a “native” PL/M compiler and to create the “astrology machine”. The first versions of CP/M were written (mostly) in PL/M. To some extent, in 1974 both Unix and CP/M were research systems, with a kernel coded in a portable language — but aimed at very different levels of hardware capability. In 1975 customers started to show up and paid serious money for CP/M (Omron, IMSAI) - from that point on the course for Kildall / DRI was set. The story is here: https://computerhistory.org/blog/in-his-own-words-gary-kildall/?key=in-his-own-words-gary-kildall -------------- next part -------------- An HTML attachment was scrubbed... URL: From ewe2 at ewe2.ninja Sun Apr 11 06:32:14 2021 From: ewe2 at ewe2.ninja (Sean Dwyer) Date: Sat, 10 Apr 2021 16:32:14 -0400 Subject: [TUHS] ching in Unix In-Reply-To: <3419319f084c8149953ab6eefcc44fb4@yaccman.com> References: <20210128214551.GA27614@minnie.tuhs.org> <3419319f084c8149953ab6eefcc44fb4@yaccman.com> Message-ID: On Sat, Mar 27, 2021 at 11:29:49PM -0700, scj at yaccman.com wrote: > I probably wrote the first version of Ching. You could type a question as > an argument and it would hash the question and use it to simulate yarrow > sticks. I used a small book for the "prophecies", and at some point > realized that it was probably some kind of copyright violation so I dropped > it. It's quite possible that others tinkered with it as well, that being > the way the world worked then. > > > --- That's interesting, so there was a trail of authorship, a history we have lost touch with unless we find the long-lost v6 source or the 32v sources that can shed light on this more. I am a little surprised that the Legge translation was not used as a basis for prophecies, it's been public domain AFAIK. -- I love deadlines. I love the whooshing noise as they fly by. From norman at oclsc.org Tue Apr 13 01:47:20 2021 From: norman at oclsc.org (Norman Wilson) Date: Mon, 12 Apr 2021 11:47:20 -0400 Subject: [TUHS] (no printed copy) (was (no subject)) Message-ID: <1618242443.3020.for-standards-violators@oclsc.org> Nemo Nusquam: In this informal survey, I side with Dave, though I prefer to read in my comfy well-lit chair with tea/coffee/cocoa.B (A very similar thread was aired on MO last year.) ===== I should point out that, having at various times spilled hot chocolate on a tablet and on a paper book, it is much simpler to recover when it's a tablet. And a cat can flip pages for you with either technology. Norman Wilson Toronto ON (Curled up on the couch with my laptop, cat just left) From ben at huntsmans.net Tue Apr 13 15:14:45 2021 From: ben at huntsmans.net (Ben Huntsman) Date: Tue, 13 Apr 2021 05:14:45 +0000 Subject: [TUHS] Anyone know ancient versions of XLC? Message-ID: I know this is a strange place to ask, but it was suggested to me that some people who may know may follow this list... Anyone on here used IBM's XLC in very old versions? Anyone know what the argument -qdebug=austlib does? I can't seem to find any documentation that says... It would have been an argument for the compiler shipping with AIX 3.2.5, I believe. Thanks in advance! -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennethgoodwin56 at gmail.com Tue Apr 13 15:30:41 2021 From: kennethgoodwin56 at gmail.com (Kenneth Goodwin) Date: Tue, 13 Apr 2021 01:30:41 -0400 Subject: [TUHS] Anyone know ancient versions of XLC? In-Reply-To: References: Message-ID: On a random guess, brings in the Austlib debug library to help debug the program into the runtime environment.... On Tue, Apr 13, 2021, 1:16 AM Ben Huntsman wrote: > I know this is a strange place to ask, but it was suggested to me that > some people who may know may follow this list... > Anyone on here used IBM's XLC in very old versions? > > Anyone know what the argument -qdebug=austlib does? > > I can't seem to find any documentation that says... It would have been an > argument for the compiler shipping with AIX 3.2.5, I believe. > > Thanks in advance! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Wed Apr 14 07:57:20 2021 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 14 Apr 2021 07:57:20 +1000 (EST) Subject: [TUHS] SUN (Stanford University Network) was PC Unix In-Reply-To: <382F4422-D6B8-4749-9927-9EC19FE9CADD@pobox.com> References: <382F4422-D6B8-4749-9927-9EC19FE9CADD@pobox.com> Message-ID: On Sat, 10 Apr 2021, David Arnold wrote: [ Microbee ] > 6116 static RAM meant no mucking about with DRAM refresh either. Yep, that helped a lot; slower, but who cared? My memory is fading now, but I recall that the Z-80 had a "refresh" pin to tell any attached dynamic RAM to refresh itself. The Z-80 was my favourite chip :-) > Happy days. > > But I never tried to get a Unix on it. UZI or Fuzix might work? I toyed with the idea of Minix or LSX, but it would have to be stripped back and I didn't think that the Z-80 was up to it, even though I had the 128KB bank-switched model. With the Hi-Tech C compiler I did get a number of simple Unix programs to run, and even found a copy of CP/M UUCP (which was overlaid to to hell and back). I did have a copy of Concurrent CP/M, but never tried it. -- Dave From bakul at iitbombay.org Wed Apr 14 08:30:54 2021 From: bakul at iitbombay.org (Bakul Shah) Date: Tue, 13 Apr 2021 15:30:54 -0700 Subject: [TUHS] SUN (Stanford University Network) was PC Unix In-Reply-To: References: <382F4422-D6B8-4749-9927-9EC19FE9CADD@pobox.com> Message-ID: <59701165-ECB6-4164-9159-6CEB13BD9057@iitbombay.org> On Apr 13, 2021, at 2:57 PM, Dave Horsfall wrote: > >> Happy days. >> >> But I never tried to get a Unix on it. UZI or Fuzix might work? > > I toyed with the idea of Minix or LSX, but it would have to be stripped back and I didn't think that the Z-80 was up to it, even though I had the 128KB bank-switched model. With the Hi-Tech C compiler I did get a number of simple Unix programs to run, and even found a copy of CP/M UUCP (which was overlaid to to hell and back). Cromemco Inc sold Cromix, a "unix like os" for their Z80 based System Three in 1979. It had many of the unix commands but some had longer names and no UUCP. Written from scratch AFAIK. I believe you can still find a copy online and run it under a Z80 emulator. From robert at timetraveller.org Thu Apr 15 15:01:01 2021 From: robert at timetraveller.org (Robert Brockway) Date: Thu, 15 Apr 2021 15:01:01 +1000 (AEST) Subject: [TUHS] SUN (Stanford University Network) was PC Unix In-Reply-To: References: <0BD38829-5E79-4034-BCEF-0555434E52A4@planet.nl> Message-ID: On Sat, 10 Apr 2021, Dave Horsfall wrote: > On Fri, 9 Apr 2021, Paul Ruizendaal via TUHS wrote: > >> Z80 CP/M machines were still competitive in 1981-1983 (Osborne, Kaypro) > > And the Aussie Microbee... Wonderful machine, and easily hacked upon. > > For example, you could expand the memory by soldering several chips on top of > each other and addressing the CS* line via bank-switching. That worked on the old Radio Shack (Tandy) Color Computer 2 as well. Until this moment I didn't know it had been demonstrated on any other architecture. The Operating System OS-9[1] Level One would detect this and use the bank-switched memory if it was available. Presumably it kept identical copies of itself in each bank as the entire address space switched. Microware OS-9 was *nix-like in look and feel although it was very different internally I think. OS-9 still exists today. I started with OS-9 and so found Unix a comfortable environment when I transitioned over. [1] Which should not be confused with any operating system running on a Mac. That's another story. Rob From imp at bsdimp.com Thu Apr 15 15:54:52 2021 From: imp at bsdimp.com (Warner Losh) Date: Wed, 14 Apr 2021 23:54:52 -0600 Subject: [TUHS] Looking for a paper.. Message-ID: ... or the proceedings that it's in. The paper is by Chris Torek entitled "A New Framework for Device Support in Berkeley Unix" from Proceedings of the UKUUG, London, Summer 1990. The Google hits I'm getting in the proceedings suggest I'd like a copy of the full thing. Closest I've found is from 2005 or 2006 on archive.org... Nothing in the TUHS archives I was able to find.... This paper is referenced in Chris Torek's "Device Configuration in 4.4BSD" which only ever seemed to circulate in draft form. That I have a pdf of which I converted from a ps that was on NetBSD.org... Any chance I can get a copy of it? Or will I need to figure out inter-library loan again for the first time in almost 2 decades... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Thu Apr 15 16:52:44 2021 From: imp at bsdimp.com (Warner Losh) Date: Thu, 15 Apr 2021 00:52:44 -0600 Subject: [TUHS] Looking for a paper.. In-Reply-To: <202104150649.13F6n76v098531@elf.torek.net> References: <202104150649.13F6n76v098531@elf.torek.net> Message-ID: On Thu, Apr 15, 2021, 12:49 AM Chris Torek wrote: > I found it. What are you looking for, TeX source, dvi, PostScript...? > First choice is TeX, second choice is PostScript. And thank you so much Chris.... Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From torek at elf.torek.net Thu Apr 15 16:49:07 2021 From: torek at elf.torek.net (Chris Torek) Date: Wed, 14 Apr 2021 23:49:07 -0700 (PDT) Subject: [TUHS] Looking for a paper.. In-Reply-To: Message-ID: <202104150649.13F6n76v098531@elf.torek.net> I found it. What are you looking for, TeX source, dvi, PostScript...? Chris From dave at horsfall.org Thu Apr 15 17:26:56 2021 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 15 Apr 2021 17:26:56 +1000 (EST) Subject: [TUHS] Looking for a paper.. In-Reply-To: References: <202104150649.13F6n76v098531@elf.torek.net> Message-ID: On Thu, 15 Apr 2021, Warner Losh wrote: > On Thu, Apr 15, 2021, 12:49 AM Chris Torek wrote: > I found it.  What are you looking for, TeX source, dvi, > PostScript...? > > First choice is TeX, second choice is PostScript. I tried to wrap my mind around TeX, but ended up learning PostScript instead :-) I tried to grok TeX (my then-PHB tried to force me to learn it), but ended up learning PostScript... It just worked. > And thank you so much Chris.... Indeed; he helped me with a SCSI ID problem back in ye olde BSD/OS days (BSDi), before WinDriver took over and trashed the joint for our customers. Did I mention that WinDriver pretty lost all of their customers to OpenBSD, FreeBSD, NetBSD, etc? Sounds like my own clients once; we got borged by a Big Company in order to flog their own (inferior) product, and to my black heart's delight each and everyone one of them went to an opposing product. -- Dave From lars at nocrew.org Thu Apr 15 21:19:23 2021 From: lars at nocrew.org (Lars Brinkhoff) Date: Thu, 15 Apr 2021 11:19:23 +0000 Subject: [TUHS] First C compiler outside Bell Labs? Message-ID: <7wa6pzx0as.fsf@junk.nocrew.org> Hello, Which was the first C compiler written outside Bell Labs? I have a candidate in mind. Alan Snyder interned at Bell Labs in 1973. Later at MIT, we wrote a C compiler for the PDP-10. This would have been 1974-1975. From clemc at ccc.com Thu Apr 15 23:24:05 2021 From: clemc at ccc.com (Clem Cole) Date: Thu, 15 Apr 2021 09:24:05 -0400 Subject: [TUHS] First C compiler outside Bell Labs? In-Reply-To: <7wa6pzx0as.fsf@junk.nocrew.org> References: <7wa6pzx0as.fsf@junk.nocrew.org> Message-ID: I personally am not aware of another any earlier, so if you asked me that is what I would have said. I'd be curious if you discover an earlier one and the story behind it. ᐧ On Thu, Apr 15, 2021 at 7:20 AM Lars Brinkhoff wrote: > Hello, > > Which was the first C compiler written outside Bell Labs? > > I have a candidate in mind. Alan Snyder interned at Bell Labs in 1973. > Later at MIT, we wrote a C compiler for the PDP-10. This would have > been 1974-1975. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.douglas.mcilroy at dartmouth.edu Thu Apr 15 23:29:15 2021 From: m.douglas.mcilroy at dartmouth.edu (M Douglas McIlroy) Date: Thu, 15 Apr 2021 09:29:15 -0400 Subject: [TUHS] First C compiler outside Bell Labs? In-Reply-To: References: <7wa6pzx0as.fsf@junk.nocrew.org> Message-ID: Ditto, Doug On Thu, Apr 15, 2021 at 9:24 AM Clem Cole wrote: > > I personally am not aware of another any earlier, so if you asked me that is what I would have said. I'd be curious if you discover an earlier one and the story behind it. > ᐧ > > On Thu, Apr 15, 2021 at 7:20 AM Lars Brinkhoff wrote: >> >> Hello, >> >> Which was the first C compiler written outside Bell Labs? >> >> I have a candidate in mind. Alan Snyder interned at Bell Labs in 1973. >> Later at MIT, we wrote a C compiler for the PDP-10. This would have >> been 1974-1975. From saif.resun at outlook.com Fri Apr 16 04:21:48 2021 From: saif.resun at outlook.com (Saif Resun) Date: Thu, 15 Apr 2021 18:21:48 +0000 Subject: [TUHS] Can I use Apout simulator on Windows 10? Message-ID: hello there! I want to use Unix Operating system but I use Windows and from TUHS I got to know that Apout can be installed on FreeBSD 2.x and 3.x, and on RedHat Linux 2.2. Can I use it on Windows 10? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Apr 16 06:29:29 2021 From: clemc at ccc.com (Clem Cole) Date: Thu, 15 Apr 2021 16:29:29 -0400 Subject: [TUHS] Can I use Apout simulator on Windows 10? In-Reply-To: References: Message-ID: As its author, WKT has more info than others but since he does not mention it in his README and due to TZ issue (he's likely asleep right now), I'll take a shot. Note: I can not say I have tried it, but I would expect it to compile and run on WSL. I can say I ran in a few years ago on a Mac and 'just worked.' You might need to tweak it a little bit if for no other reason than RedHat Linux 2.2 is pretty old and was 32 bit, but WKT's code is pretty clean and I would not expect any real issues. Since he is assuming a 32-bit system, and I have not played with it in a while, my guess is that the one place you might need to be careful. His comment in the read says: It should compile on a 32-bit little-endian machine with some form of Unix; you may need to change some header file includes etc. See `defines.h' for the details. In particular, if your system doesn't have types for: int8_t, int16_t, int32_t, u_int8_t, u_int16_t, u_int32_t or if your compiler doesn't have char=1 byte, short= 2 bytes, int=4 bytes, then alter the relevant typedefs in `defines.h'. ᐧ On Thu, Apr 15, 2021 at 2:23 PM Saif Resun wrote: > hello there! I want to use Unix Operating system but I use Windows and > from TUHS I got to know that Apout can be installed on FreeBSD 2.x and > 3.x, and on RedHat Linux 2.2. Can I use it on Windows 10? > > Thank you. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From usotsuki at buric.co Fri Apr 16 07:03:52 2021 From: usotsuki at buric.co (Steve Nickolas) Date: Thu, 15 Apr 2021 17:03:52 -0400 (EDT) Subject: [TUHS] Can I use Apout simulator on Windows 10? In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021, Clem Cole wrote: > As its author, WKT has more info than others but since he does not mention > it in his README and due to TZ issue (he's likely asleep right now), I'll > take a shot. Note: I can not say I have tried it, but I would expect it > to compile and run on WSL. I can say I ran in a few years ago on a Mac and > 'just worked.' You might need to tweak it a little bit if for no other > reason than RedHat Linux 2.2 is pretty old and was 32 bit, but WKT's code > is pretty clean and I would not expect any real issues. Since he is > assuming a 32-bit system, and I have not played with it in a while, my > guess is that the one place you might need to be careful. His comment in > the read says: > > It should compile on a 32-bit little-endian machine with > > some form of Unix; you may need to change some header file includes etc. > > See `defines.h' for the details. In particular, if your system doesn't have > > types for: > > > > int8_t, int16_t, int32_t, u_int8_t, u_int16_t, u_int32_t > > or if your compiler doesn't have char=1 byte, short= 2 bytes, int=4 bytes, > > then alter the relevant typedefs in `defines.h'. Didn't someone here port apout to win32, and it *almost* worked 100%? I remember reading about it on virtuallyfun.com, but I might be mistaken. On Win10 you could also just install Debian in WSL, and it might work better there? -uso. From brad at anduin.eldar.org Fri Apr 16 11:17:13 2021 From: brad at anduin.eldar.org (Brad Spencer) Date: Thu, 15 Apr 2021 21:17:13 -0400 Subject: [TUHS] SUN (Stanford University Network) was PC Unix In-Reply-To: (message from Robert Brockway on Thu, 15 Apr 2021 15:01:01 +1000 (AEST)) Message-ID: Robert Brockway writes: > On Sat, 10 Apr 2021, Dave Horsfall wrote: > >> On Fri, 9 Apr 2021, Paul Ruizendaal via TUHS wrote: >> >>> Z80 CP/M machines were still competitive in 1981-1983 (Osborne, Kaypro) >> >> And the Aussie Microbee... Wonderful machine, and easily hacked upon. >> >> For example, you could expand the memory by soldering several chips on top of >> each other and addressing the CS* line via bank-switching. > > That worked on the old Radio Shack (Tandy) Color Computer 2 as well. > Until this moment I didn't know it had been demonstrated on any other > architecture. > > The Operating System OS-9[1] Level One would detect this and use the > bank-switched memory if it was available. Presumably it kept identical > copies of itself in each bank as the entire address space switched. > > Microware OS-9 was *nix-like in look and feel although it was very > different internally I think. OS-9 still exists today. > > I started with OS-9 and so found Unix a comfortable environment when I > transitioned over. > > [1] Which should not be confused with any operating system running on a > Mac. That's another story. > > Rob I did a lot with OS-9 too, both Level One on the Color Computer 2 and Level Two on the Color Computer 3. The CC3 had a very primitive memory manager, no faulting, but would allow 8k chunks from up to a 512k pool of memory to be mapped into the 64k address space of the 6809. There was a C compiler, probably K&R based or a bit before for OS-9. I ported a number of the BSD utilities. I also worked on a implementation of UUCP and ran a UUCP node and proper domain for email using UUNET as the provider. I received email and a bit of Usenet. I wrote a clone of rn to read Usenet on the CC3 with OS-9 Level Two. The block diagram for 6809 OS-9 was very simular to V[small number] Unix, with some notable differences. OS-9 is a microkernel probably being the biggest thing and 6809 OS-9 is all written in assembly. There was a login program that you could attach to a serial port and actually login with a username and password and such. Lots of fun and somewhat Unix like in a lot of ways. There was also a 68000 version of OS-9 Level One that I saw once. I understand that it may have been mechanically translated from the 6809 version. It ran pretty much exactly in the same way. -- Brad Spencer - brad at anduin.eldar.org - KC8VKS - http://anduin.eldar.org From lars at nocrew.org Fri Apr 16 15:03:19 2021 From: lars at nocrew.org (Lars Brinkhoff) Date: Fri, 16 Apr 2021 05:03:19 +0000 Subject: [TUHS] First C compiler outside Bell Labs? In-Reply-To: (M. Douglas McIlroy's message of "Thu, 15 Apr 2021 09:29:15 -0400") References: <7wa6pzx0as.fsf@junk.nocrew.org> Message-ID: <7w35vqvn1k.fsf@junk.nocrew.org> Thank you! M Douglas McIlroy writor: > Ditto, > Doug > > Clem Cole wrote: >> I personally am not aware of another any earlier, so if you asked me >> that is what I would have said. I'd be curious if you discover an >> earlier one and the story behind it. ᐧ >> >> Lars Brinkhoff wrote: >>> Which was the first C compiler written outside Bell Labs? I have a >>> candidate in mind. Alan Snyder interned at Bell Labs in 1973. >>> Later at MIT, we wrote a C compiler for the PDP-10. This would have >>> been 1974-1975. From ullbeking at andrewnesbit.org Wed Apr 21 22:27:12 2021 From: ullbeking at andrewnesbit.org (Andrew Luke Nesbit) Date: Wed, 21 Apr 2021 13:27:12 +0100 Subject: [TUHS] FTAG: AlphaServer DS15, Sun T5140, Sun Blade 10, HP Proliant DL380 G7, VT220 [London, UK] Message-ID: <2b3010dd-4ff0-9e0c-1b5f-675d11889e0e@andrewnesbit.org> Hello all again, With a heavy heart I need to find a new home for the following beautiful hardware: - AlphaServer DS15 server - Sun SPARC Enterprise T5140 1U rack server - Sun Blade 10 mini tower - HP Proliant DL380 G7 2U rack server - DEC VT220 with screen, keyboard, and various adapter cables Please note that the Sun T5140 and HP DL380 are deep (700mm for purposes of installation in a rack). I'm starting a new job next week and intend to focus on that and my family. I've stopped working on various projects and I am vacating my studio workshop, so I have a lot of things to give away or sell. The above items are all FREE FOR COLLECTION ONLY (a car will be fine to transport the above items). I am located in London, UK. Post code is N15 4QL (Seven Sisters and Tottenham Hale) in Haringey, London. Kind regards, Andrew From ullbeking at andrewnesbit.org Thu Apr 22 00:43:06 2021 From: ullbeking at andrewnesbit.org (Andrew Luke Nesbit) Date: Wed, 21 Apr 2021 15:43:06 +0100 Subject: [TUHS] FTAG: AlphaServer DS15, Sun T5140, Sun Blade 10, HP Proliant DL380 G7, VT220 [London, UK] In-Reply-To: <2b3010dd-4ff0-9e0c-1b5f-675d11889e0e@andrewnesbit.org> References: <2b3010dd-4ff0-9e0c-1b5f-675d11889e0e@andrewnesbit.org> Message-ID: On 21/04/2021 13:27, Andrew Luke Nesbit via cctalk wrote: > With a heavy heart I need to find a new home for the following beautiful > hardware: > -   Sun Blade 10 mini tower I've just realized this is a typo. It should be: - Sun Ultra 10 mini tower I will write to all who have expressed interest in this particular item. Andrew From pnr at planet.nl Sun Apr 25 19:15:15 2021 From: pnr at planet.nl (Paul Ruizendaal) Date: Sun, 25 Apr 2021 11:15:15 +0200 Subject: [TUHS] pcc in 8th edition Message-ID: Sometimes one thing leads to another. Following the recent mention of some retro-brew 68K single board systems, I decided to build a CB030 board (in progress). I figure it is a rough proxy for a 1980 VAX and would allow for some experimentation with the 32V / SysIII / 8th edition code. My first thought was to use the M68K compiler that is included with the bit sources (see THUS Archive for this), as I had used that before to explore some of the Blit source. That compiler is LP32, not ILP32 - which may be a source of trouble. Just changing the SZINT parameter yielded some issues, so I started looking at the PCC source. This source does not have a “table.c” in the well known format as described in the “A tour of the portable C compiler” paper. Instead it uses a file “stin” which appears to be in a more compact format and is translated into a “table.c” file by a new pre-processor ("sty.y”). Then looking at the VAX compilers for 8th and 10th edition, these to use this “stin” file. All the other m68K compilers (based on pcc) that I found appear to derive from the V7/32V/SysIII lineage, not from the 8th edition lineage. A quick google did not yield much background or documentation on the STY format. Anybody on this list that can shed some light on the history of the STY table and on how to use it? Any surviving reports or memos that would be useful? Many thanks in advance Paul From pnr at planet.nl Sun Apr 25 22:35:34 2021 From: pnr at planet.nl (Paul Ruizendaal) Date: Sun, 25 Apr 2021 14:35:34 +0200 Subject: [TUHS] pcc in 8th edition Message-ID: <15D66A4F-D935-4313-93C8-CBB66039E0BD@planet.nl> For clarity and ease of reference: - The “Tour of paper” is for instance here: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.48.3512 - A machine description for the VAX that matches with that paper is for instance in the SysIII source: https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd/cc/vax/pcc/table.c - The new style description in 8th edition is here: https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/src/cmd/ccom/vax/stin - The program that translates the “stin” file to a “table.c” file is here: https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/src/cmd/ccom/common/sty.y ==== Sometimes one thing leads to another. Following the recent mention of some retro-brew 68K single board systems, I decided to build a CB030 board (in progress). I figure it is a rough proxy for a 1980 VAX and would allow for some experimentation with the 32V / SysIII / 8th edition code. My first thought was to use the M68K compiler that is included with the Blit sources (see THUS Archive for this), as I had used that before to explore some of the Blit source. That compiler is LP32, not ILP32 - which may be a source of trouble. Just changing the SZINT parameter yielded some issues, so I started looking at the PCC source. This source does not have a “table.c” in the well known format as described in the “A tour of the portable C compiler” paper. Instead it uses a file “stin” which appears to be in a more compact format and is translated into a “table.c” file by a new pre-processor ("sty.y”). Then looking at the VAX compilers for 8th and 10th edition, these too use this “stin” file. All the other m68K compilers (based on pcc) that I found appear to derive from the V7/32V/SysIII lineage, not from the 8th edition lineage. A quick google did not yield much background or documentation on the STY format. Anybody on this list that can shed some light on the history of the STY table and on how to use it? Any surviving reports or memos that would be useful? Many thanks in advance Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Sun Apr 25 22:49:36 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 25 Apr 2021 06:49:36 -0600 Subject: [TUHS] pcc in 8th edition In-Reply-To: <15D66A4F-D935-4313-93C8-CBB66039E0BD@planet.nl> References: <15D66A4F-D935-4313-93C8-CBB66039E0BD@planet.nl> Message-ID: <202104251249.13PCnaFV031741@freefriends.org> Not an answer to your questions, but you may want to take a look at the PCC Revived project. It lives in CVS, but I have a git mirror at git://github.com/arnoldrobbins/pcc-revived HTH, Arnold Paul Ruizendaal wrote: > For clarity and ease of reference: > > - The “Tour of paper” is for instance here: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.48.3512 > > - A machine description for the VAX that matches with that paper is for instance in the SysIII source: https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd/cc/vax/pcc/table.c > > - The new style description in 8th edition is here: https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/src/cmd/ccom/vax/stin > > - The program that translates the “stin” file to a “table.c” file is here: https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/src/cmd/ccom/common/sty.y > > > ==== > > Sometimes one thing leads to another. > > Following the recent mention of some retro-brew 68K single board systems, I decided to build a CB030 board (in progress). I figure it is a rough proxy for a 1980 VAX and would allow for some experimentation with the 32V / SysIII / 8th edition code. > > My first thought was to use the M68K compiler that is included with the Blit sources (see THUS Archive for this), as I had used that before to explore some of the Blit source. That compiler is LP32, not ILP32 - which may be a source of trouble. Just changing the SZINT parameter yielded some issues, so I started looking at the PCC source. > > This source does not have a “table.c” in the well known format as described in the “A tour of the portable C compiler” paper. Instead it uses a file “stin” which appears to be in a more compact format and is translated into a “table.c” file by a new pre-processor ("sty.y”). Then looking at the VAX compilers for 8th and 10th edition, these too use this “stin” file. > > All the other m68K compilers (based on pcc) that I found appear to derive from the V7/32V/SysIII lineage, not from the 8th edition lineage. > > A quick google did not yield much background or documentation on the STY format. > > Anybody on this list that can shed some light on the history of the STY table and on how to use it? Any surviving reports or memos that would be useful? > > Many thanks in advance > > Paul > From pnr at planet.nl Mon Apr 26 00:04:28 2021 From: pnr at planet.nl (Paul Ruizendaal) Date: Sun, 25 Apr 2021 16:04:28 +0200 Subject: [TUHS] pcc in 8th edition In-Reply-To: <202104251249.13PCnaFV031741@freefriends.org> References: <15D66A4F-D935-4313-93C8-CBB66039E0BD@planet.nl> <202104251249.13PCnaFV031741@freefriends.org> Message-ID: Thank you for the tip! I had seen the revival when googling around. The M68K version looks like an interesting option for my intended project(s). Still, I also would like to work with the versions from the early 80’s, just to get a better feel for the history of it all and to start with something small (the revival is 2-3 times the size of the early 80’s code *). On top of that, there is something magical about real-life machine descriptions that fit in 400 short lines. Paul *) On 32V the actual virtual address space for a process was limited to 192KB, due to how the MMU was used. > On Apr 25, 2021, at 2:49 PM, arnold at skeeve.com wrote: > > Not an answer to your questions, but you may want to take a look > at the PCC Revived project. It lives in CVS, but I have a git mirror at > git://github.com/arnoldrobbins/pcc-revived > > HTH, > > Arnold > > Paul Ruizendaal wrote: > >> For clarity and ease of reference: >> >> - The “Tour of paper” is for instance here: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.48.3512 >> >> - A machine description for the VAX that matches with that paper is for instance in the SysIII source: https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd/cc/vax/pcc/table.c >> >> - The new style description in 8th edition is here: https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/src/cmd/ccom/vax/stin >> >> - The program that translates the “stin” file to a “table.c” file is here: https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/src/cmd/ccom/common/sty.y >> >> >> ==== >> >> Sometimes one thing leads to another. >> >> Following the recent mention of some retro-brew 68K single board systems, I decided to build a CB030 board (in progress). I figure it is a rough proxy for a 1980 VAX and would allow for some experimentation with the 32V / SysIII / 8th edition code. >> >> My first thought was to use the M68K compiler that is included with the Blit sources (see THUS Archive for this), as I had used that before to explore some of the Blit source. That compiler is LP32, not ILP32 - which may be a source of trouble. Just changing the SZINT parameter yielded some issues, so I started looking at the PCC source. >> >> This source does not have a “table.c” in the well known format as described in the “A tour of the portable C compiler” paper. Instead it uses a file “stin” which appears to be in a more compact format and is translated into a “table.c” file by a new pre-processor ("sty.y”). Then looking at the VAX compilers for 8th and 10th edition, these too use this “stin” file. >> >> All the other m68K compilers (based on pcc) that I found appear to derive from the V7/32V/SysIII lineage, not from the 8th edition lineage. >> >> A quick google did not yield much background or documentation on the STY format. >> >> Anybody on this list that can shed some light on the history of the STY table and on how to use it? Any surviving reports or memos that would be useful? >> >> Many thanks in advance >> >> Paul >> From pnr at planet.nl Mon Apr 26 01:45:56 2021 From: pnr at planet.nl (Paul Ruizendaal) Date: Sun, 25 Apr 2021 17:45:56 +0200 Subject: [TUHS] pcc in 8th edition In-Reply-To: <202104251249.13PCnaFV031741@freefriends.org> References: <15D66A4F-D935-4313-93C8-CBB66039E0BD@planet.nl> <202104251249.13PCnaFV031741@freefriends.org> Message-ID: By now found some more clues, in particular this link: http://computer-programming-forum.com/47-c-language/fab825b2dce1aa59.htm Apparently I am talking about PCC and PCC2 in the below question. The first post mentions 4 papers. They can be found online, apart from the USENIX one: "Four Generations of Portable C Compiler" by D.M. Kristol (1986 Summer USENIX Conference Proceedings) Anybody have that? The second post mentions official documentation: "In porting QCC, a useful text is the "Portable C Compiler - Version 2 (PCC2) Internals". It includes documentation of stin file formats, PCC2 tree forms, debugging flags, and compiler #defines. The manual is expensive so it's worth it most if you buy it before you figure it all out doing a port. Since the manual is based on PCC2 (and hasn't been updated), it's a good starting point, but doesn't have the latest information.” Anybody have that? (It is not on bitsavers) Paul > On 25 Apr 2021, at 14:49, arnold at skeeve.com wrote: > > Not an answer to your questions, but you may want to take a look > at the PCC Revived project. It lives in CVS, but I have a git mirror at > git://github.com/arnoldrobbins/pcc-revived > > HTH, > > Arnold > > Paul Ruizendaal wrote: > >> For clarity and ease of reference: >> >> - The “Tour of paper” is for instance here: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.48.3512 >> >> - A machine description for the VAX that matches with that paper is for instance in the SysIII source: https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd/cc/vax/pcc/table.c >> >> - The new style description in 8th edition is here: https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/src/cmd/ccom/vax/stin >> >> - The program that translates the “stin” file to a “table.c” file is here: https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/src/cmd/ccom/common/sty.y >> >> >> ==== >> >> Sometimes one thing leads to another. >> >> Following the recent mention of some retro-brew 68K single board systems, I decided to build a CB030 board (in progress). I figure it is a rough proxy for a 1980 VAX and would allow for some experimentation with the 32V / SysIII / 8th edition code. >> >> My first thought was to use the M68K compiler that is included with the Blit sources (see THUS Archive for this), as I had used that before to explore some of the Blit source. That compiler is LP32, not ILP32 - which may be a source of trouble. Just changing the SZINT parameter yielded some issues, so I started looking at the PCC source. >> >> This source does not have a “table.c” in the well known format as described in the “A tour of the portable C compiler” paper. Instead it uses a file “stin” which appears to be in a more compact format and is translated into a “table.c” file by a new pre-processor ("sty.y”). Then looking at the VAX compilers for 8th and 10th edition, these too use this “stin” file. >> >> All the other m68K compilers (based on pcc) that I found appear to derive from the V7/32V/SysIII lineage, not from the 8th edition lineage. >> >> A quick google did not yield much background or documentation on the STY format. >> >> Anybody on this list that can shed some light on the history of the STY table and on how to use it? Any surviving reports or memos that would be useful? >> >> Many thanks in advance >> >> Paul >> From clemc at ccc.com Mon Apr 26 03:11:25 2021 From: clemc at ccc.com (Clem Cole) Date: Sun, 25 Apr 2021 13:11:25 -0400 Subject: [TUHS] pcc in 8th edition In-Reply-To: References: <15D66A4F-D935-4313-93C8-CBB66039E0BD@planet.nl> <202104251249.13PCnaFV031741@freefriends.org> Message-ID: yes i'll mail under separate cover a scan ᐧ On Sun, Apr 25, 2021 at 11:47 AM Paul Ruizendaal wrote: > By now found some more clues, in particular this link: > http://computer-programming-forum.com/47-c-language/fab825b2dce1aa59.htm > > Apparently I am talking about PCC and PCC2 in the below question. > > The first post mentions 4 papers. They can be found online, apart from the > USENIX one: > "Four Generations of Portable C Compiler" by D.M. Kristol (1986 Summer > USENIX Conference Proceedings) > > Anybody have that? > > The second post mentions official documentation: > > "In porting QCC, a useful text is the "Portable C Compiler - > Version 2 (PCC2) Internals". It includes documentation of > stin file formats, PCC2 tree forms, debugging flags, and > compiler #defines. The manual is expensive so it's worth it > most if you buy it before you figure it all out doing a > port. Since the manual is based on PCC2 (and hasn't been > updated), it's a good starting point, but doesn't have the > latest information.” > > Anybody have that? (It is not on bitsavers) > > Paul > > > On 25 Apr 2021, at 14:49, arnold at skeeve.com wrote: > > > > Not an answer to your questions, but you may want to take a look > > at the PCC Revived project. It lives in CVS, but I have a git mirror at > > git://github.com/arnoldrobbins/pcc-revived > > > > HTH, > > > > Arnold > > > > Paul Ruizendaal wrote: > > > >> For clarity and ease of reference: > >> > >> - The “Tour of paper” is for instance here: > http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.48.3512 < > http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.48.3512> > >> > >> - A machine description for the VAX that matches with that paper is for > instance in the SysIII source: > https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd/cc/vax/pcc/table.c > < > https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd/cc/vax/pcc/table.c > > > >> > >> - The new style description in 8th edition is here: > https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/src/cmd/ccom/vax/stin < > https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/src/cmd/ccom/vax/stin> > >> > >> - The program that translates the “stin” file to a “table.c” file is > here: > https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/src/cmd/ccom/common/sty.y > < > https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/src/cmd/ccom/common/sty.y > > > >> > >> > >> ==== > >> > >> Sometimes one thing leads to another. > >> > >> Following the recent mention of some retro-brew 68K single board > systems, I decided to build a CB030 board (in progress). I figure it is a > rough proxy for a 1980 VAX and would allow for some experimentation with > the 32V / SysIII / 8th edition code. > >> > >> My first thought was to use the M68K compiler that is included with the > Blit sources (see THUS Archive for this), as I had used that before to > explore some of the Blit source. That compiler is LP32, not ILP32 - which > may be a source of trouble. Just changing the SZINT parameter yielded some > issues, so I started looking at the PCC source. > >> > >> This source does not have a “table.c” in the well known format as > described in the “A tour of the portable C compiler” paper. Instead it uses > a file “stin” which appears to be in a more compact format and is > translated into a “table.c” file by a new pre-processor ("sty.y”). Then > looking at the VAX compilers for 8th and 10th edition, these too use this > “stin” file. > >> > >> All the other m68K compilers (based on pcc) that I found appear to > derive from the V7/32V/SysIII lineage, not from the 8th edition lineage. > >> > >> A quick google did not yield much background or documentation on the > STY format. > >> > >> Anybody on this list that can shed some light on the history of the STY > table and on how to use it? Any surviving reports or memos that would be > useful? > >> > >> Many thanks in advance > >> > >> Paul > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Mon Apr 26 03:32:37 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 25 Apr 2021 11:32:37 -0600 Subject: [TUHS] pcc in 8th edition In-Reply-To: References: <15D66A4F-D935-4313-93C8-CBB66039E0BD@planet.nl> <202104251249.13PCnaFV031741@freefriends.org> Message-ID: <202104251732.13PHWb3o006219@freefriends.org> And maybe give to Warren too? :-) Clem Cole wrote: > yes i'll mail under separate cover a scan > ᐧ > > On Sun, Apr 25, 2021 at 11:47 AM Paul Ruizendaal wrote: > > > By now found some more clues, in particular this link: > > http://computer-programming-forum.com/47-c-language/fab825b2dce1aa59.htm > > > > Apparently I am talking about PCC and PCC2 in the below question. > > > > The first post mentions 4 papers. They can be found online, apart from the > > USENIX one: > > "Four Generations of Portable C Compiler" by D.M. Kristol (1986 Summer > > USENIX Conference Proceedings) > > > > Anybody have that? > > > > The second post mentions official documentation: > > > > "In porting QCC, a useful text is the "Portable C Compiler - > > Version 2 (PCC2) Internals". It includes documentation of > > stin file formats, PCC2 tree forms, debugging flags, and > > compiler #defines. The manual is expensive so it's worth it > > most if you buy it before you figure it all out doing a > > port. Since the manual is based on PCC2 (and hasn't been > > updated), it's a good starting point, but doesn't have the > > latest information.” > > > > Anybody have that? (It is not on bitsavers) > > > > Paul > > > > > On 25 Apr 2021, at 14:49, arnold at skeeve.com wrote: > > > > > > Not an answer to your questions, but you may want to take a look > > > at the PCC Revived project. It lives in CVS, but I have a git mirror at > > > git://github.com/arnoldrobbins/pcc-revived > > > > > > HTH, > > > > > > Arnold > > > > > > Paul Ruizendaal wrote: > > > > > >> For clarity and ease of reference: > > >> > > >> - The “Tour of paper” is for instance here: > > http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.48.3512 < > > http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.48.3512> > > >> > > >> - A machine description for the VAX that matches with that paper is for > > instance in the SysIII source: > > https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd/cc/vax/pcc/table.c > > < > > https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd/cc/vax/pcc/table.c > > > > > >> > > >> - The new style description in 8th edition is here: > > https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/src/cmd/ccom/vax/stin < > > https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/src/cmd/ccom/vax/stin> > > >> > > >> - The program that translates the “stin” file to a “table.c” file is > > here: > > https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/src/cmd/ccom/common/sty.y > > < > > https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/src/cmd/ccom/common/sty.y > > > > > >> > > >> > > >> ==== > > >> > > >> Sometimes one thing leads to another. > > >> > > >> Following the recent mention of some retro-brew 68K single board > > systems, I decided to build a CB030 board (in progress). I figure it is a > > rough proxy for a 1980 VAX and would allow for some experimentation with > > the 32V / SysIII / 8th edition code. > > >> > > >> My first thought was to use the M68K compiler that is included with the > > Blit sources (see THUS Archive for this), as I had used that before to > > explore some of the Blit source. That compiler is LP32, not ILP32 - which > > may be a source of trouble. Just changing the SZINT parameter yielded some > > issues, so I started looking at the PCC source. > > >> > > >> This source does not have a “table.c” in the well known format as > > described in the “A tour of the portable C compiler” paper. Instead it uses > > a file “stin” which appears to be in a more compact format and is > > translated into a “table.c” file by a new pre-processor ("sty.y”). Then > > looking at the VAX compilers for 8th and 10th edition, these too use this > > “stin” file. > > >> > > >> All the other m68K compilers (based on pcc) that I found appear to > > derive from the V7/32V/SysIII lineage, not from the 8th edition lineage. > > >> > > >> A quick google did not yield much background or documentation on the > > STY format. > > >> > > >> Anybody on this list that can shed some light on the history of the STY > > table and on how to use it? Any surviving reports or memos that would be > > useful? > > >> > > >> Many thanks in advance > > >> > > >> Paul > > >> > > > > From clemc at ccc.com Mon Apr 26 03:46:31 2021 From: clemc at ccc.com (Clem Cole) Date: Sun, 25 Apr 2021 13:46:31 -0400 Subject: [TUHS] pcc in 8th edition In-Reply-To: <202104251732.13PHWb3o006219@freefriends.org> References: <15D66A4F-D935-4313-93C8-CBB66039E0BD@planet.nl> <202104251249.13PCnaFV031741@freefriends.org> <202104251732.13PHWb3o006219@freefriends.org> Message-ID: No worries, I already did -- but I also sent it back to the pubs' folks at USENIX. They have slowing scanning the print archives on an as-needed basis; which is where it belongs. ᐧ On Sun, Apr 25, 2021 at 1:32 PM wrote: > And maybe give to Warren too? :-) > > Clem Cole wrote: > > > yes i'll mail under separate cover a scan > > ᐧ > > > > On Sun, Apr 25, 2021 at 11:47 AM Paul Ruizendaal wrote: > > > > > By now found some more clues, in particular this link: > > > > http://computer-programming-forum.com/47-c-language/fab825b2dce1aa59.htm > > > > > > Apparently I am talking about PCC and PCC2 in the below question. > > > > > > The first post mentions 4 papers. They can be found online, apart from > the > > > USENIX one: > > > "Four Generations of Portable C Compiler" by D.M. Kristol (1986 Summer > > > USENIX Conference Proceedings) > > > > > > Anybody have that? > > > > > > The second post mentions official documentation: > > > > > > "In porting QCC, a useful text is the "Portable C Compiler - > > > Version 2 (PCC2) Internals". It includes documentation of > > > stin file formats, PCC2 tree forms, debugging flags, and > > > compiler #defines. The manual is expensive so it's worth it > > > most if you buy it before you figure it all out doing a > > > port. Since the manual is based on PCC2 (and hasn't been > > > updated), it's a good starting point, but doesn't have the > > > latest information.” > > > > > > Anybody have that? (It is not on bitsavers) > > > > > > Paul > > > > > > > On 25 Apr 2021, at 14:49, arnold at skeeve.com wrote: > > > > > > > > Not an answer to your questions, but you may want to take a look > > > > at the PCC Revived project. It lives in CVS, but I have a git > mirror at > > > > git://github.com/arnoldrobbins/pcc-revived > > > > > > > > HTH, > > > > > > > > Arnold > > > > > > > > Paul Ruizendaal wrote: > > > > > > > >> For clarity and ease of reference: > > > >> > > > >> - The “Tour of paper” is for instance here: > > > http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.48.3512 < > > > http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.48.3512> > > > >> > > > >> - A machine description for the VAX that matches with that paper is > for > > > instance in the SysIII source: > > > > https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd/cc/vax/pcc/table.c > > > < > > > > https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd/cc/vax/pcc/table.c > > > > > > > >> > > > >> - The new style description in 8th edition is here: > > > > https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/src/cmd/ccom/vax/stin < > > > > https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/src/cmd/ccom/vax/stin> > > > >> > > > >> - The program that translates the “stin” file to a “table.c” file is > > > here: > > > > https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/src/cmd/ccom/common/sty.y > > > < > > > > https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/src/cmd/ccom/common/sty.y > > > > > > > >> > > > >> > > > >> ==== > > > >> > > > >> Sometimes one thing leads to another. > > > >> > > > >> Following the recent mention of some retro-brew 68K single board > > > systems, I decided to build a CB030 board (in progress). I figure it > is a > > > rough proxy for a 1980 VAX and would allow for some experimentation > with > > > the 32V / SysIII / 8th edition code. > > > >> > > > >> My first thought was to use the M68K compiler that is included with > the > > > Blit sources (see THUS Archive for this), as I had used that before to > > > explore some of the Blit source. That compiler is LP32, not ILP32 - > which > > > may be a source of trouble. Just changing the SZINT parameter yielded > some > > > issues, so I started looking at the PCC source. > > > >> > > > >> This source does not have a “table.c” in the well known format as > > > described in the “A tour of the portable C compiler” paper. Instead it > uses > > > a file “stin” which appears to be in a more compact format and is > > > translated into a “table.c” file by a new pre-processor ("sty.y”). Then > > > looking at the VAX compilers for 8th and 10th edition, these too use > this > > > “stin” file. > > > >> > > > >> All the other m68K compilers (based on pcc) that I found appear to > > > derive from the V7/32V/SysIII lineage, not from the 8th edition > lineage. > > > >> > > > >> A quick google did not yield much background or documentation on the > > > STY format. > > > >> > > > >> Anybody on this list that can shed some light on the history of the > STY > > > table and on how to use it? Any surviving reports or memos that would > be > > > useful? > > > >> > > > >> Many thanks in advance > > > >> > > > >> Paul > > > >> > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Mon Apr 26 06:11:11 2021 From: pnr at planet.nl (Paul Ruizendaal) Date: Sun, 25 Apr 2021 22:11:11 +0200 Subject: [TUHS] pcc in 8th edition In-Reply-To: References: <15D66A4F-D935-4313-93C8-CBB66039E0BD@planet.nl> <202104251249.13PCnaFV031741@freefriends.org> Message-ID: Thank you, that Usenix paper is most helpful. In short, there were (at least) 4 generations of PCC: PCC, PCC2, QCC and RCC. The first two by SCJ and the latter two by Kristol. PCC2 seems to go back to about 1980, and QCC and RCC were created in the first half of 1985. The C compiler in 8th Edition seems to be PCC2 based. For ease of reference I’ve put the M68K compiler that is included in the Blit source tree (https://www.tuhs.org/Archive/Distributions/Research/Dan_Cross_v8/) here: https://gitlab.com/pnru/pcc2_m68k Anybody who has some more info on how to read a “stin” file, please share. Paul > On Apr 25, 2021, at 7:11 PM, Clem Cole wrote: > > yes i'll mail under separate cover a scan > ᐧ > > On Sun, Apr 25, 2021 at 11:47 AM Paul Ruizendaal > wrote: > By now found some more clues, in particular this link: > http://computer-programming-forum.com/47-c-language/fab825b2dce1aa59.htm > > Apparently I am talking about PCC and PCC2 in the below question. > > The first post mentions 4 papers. They can be found online, apart from the USENIX one: > "Four Generations of Portable C Compiler" by D.M. Kristol (1986 Summer USENIX Conference Proceedings) > > Anybody have that? > > The second post mentions official documentation: > > "In porting QCC, a useful text is the "Portable C Compiler - > Version 2 (PCC2) Internals". It includes documentation of > stin file formats, PCC2 tree forms, debugging flags, and > compiler #defines. The manual is expensive so it's worth it > most if you buy it before you figure it all out doing a > port. Since the manual is based on PCC2 (and hasn't been > updated), it's a good starting point, but doesn't have the > latest information.” > > Anybody have that? (It is not on bitsavers) > > Paul > > > On 25 Apr 2021, at 14:49, arnold at skeeve.com wrote: > > > > Not an answer to your questions, but you may want to take a look > > at the PCC Revived project. It lives in CVS, but I have a git mirror at > > git://github.com/arnoldrobbins/pcc-revived > > > > HTH, > > > > Arnold > > > > Paul Ruizendaal > wrote: > > > >> For clarity and ease of reference: > >> > >> - The “Tour of paper” is for instance here: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.48.3512 > > >> > >> - A machine description for the VAX that matches with that paper is for instance in the SysIII source: https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd/cc/vax/pcc/table.c > > >> > >> - The new style description in 8th edition is here: https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/src/cmd/ccom/vax/stin > > >> > >> - The program that translates the “stin” file to a “table.c” file is here: https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/src/cmd/ccom/common/sty.y > > >> > >> > >> ==== > >> > >> Sometimes one thing leads to another. > >> > >> Following the recent mention of some retro-brew 68K single board systems, I decided to build a CB030 board (in progress). I figure it is a rough proxy for a 1980 VAX and would allow for some experimentation with the 32V / SysIII / 8th edition code. > >> > >> My first thought was to use the M68K compiler that is included with the Blit sources (see THUS Archive for this), as I had used that before to explore some of the Blit source. That compiler is LP32, not ILP32 - which may be a source of trouble. Just changing the SZINT parameter yielded some issues, so I started looking at the PCC source. > >> > >> This source does not have a “table.c” in the well known format as described in the “A tour of the portable C compiler” paper. Instead it uses a file “stin” which appears to be in a more compact format and is translated into a “table.c” file by a new pre-processor ("sty.y”). Then looking at the VAX compilers for 8th and 10th edition, these too use this “stin” file. > >> > >> All the other m68K compilers (based on pcc) that I found appear to derive from the V7/32V/SysIII lineage, not from the 8th edition lineage. > >> > >> A quick google did not yield much background or documentation on the STY format. > >> > >> Anybody on this list that can shed some light on the history of the STY table and on how to use it? Any surviving reports or memos that would be useful? > >> > >> Many thanks in advance > >> > >> Paul > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Mon Apr 26 06:48:42 2021 From: norman at oclsc.org (Norman Wilson) Date: Sun, 25 Apr 2021 16:48:42 -0400 (EDT) Subject: [TUHS] pcc in 8th edition Message-ID: <20210425204842.3FAC4640CB6@lignose.oclsc.org> I was waiting to see whether Steve Johnson would speak up, because I'm not much of an expert; but yes, the VAX C compiler in V8/V9/V10 is pcc2. I think there are a few Research-specific hacks to add additional stab info for pi(9.1) and on request insert basic-block profiling for lcomp(1), but nothing major. Maybe we did some hacking on c2 as well. I know I did a lot of c2 cleanup later in my personal hacking in Toronto, but I don't think I did much if any in New Jersey. But that's independent of the compiler (modulo, I think, some of my later fixes discovered by using c2 with a different compiler). Norman Wilson Toronto ON From crossd at gmail.com Mon Apr 26 06:54:32 2021 From: crossd at gmail.com (Dan Cross) Date: Sun, 25 Apr 2021 16:54:32 -0400 Subject: [TUHS] pcc in 8th edition In-Reply-To: <20210425204842.3FAC4640CB6@lignose.oclsc.org> References: <20210425204842.3FAC4640CB6@lignose.oclsc.org> Message-ID: I seem to recall that LCC was also used, at least on 10th Ed. Am I imagining things, or was that real? On Sun, Apr 25, 2021 at 4:51 PM Norman Wilson wrote: > I was waiting to see whether Steve Johnson would speak > up, because I'm not much of an expert; but yes, the VAX > C compiler in V8/V9/V10 is pcc2. > > I think there are a few Research-specific hacks to add > additional stab info for pi(9.1) and on request insert > basic-block profiling for lcomp(1), but nothing major. > > Maybe we did some hacking on c2 as well. I know I did > a lot of c2 cleanup later in my personal hacking in > Toronto, but I don't think I did much if any in New > Jersey. But that's independent of the compiler (modulo, > I think, some of my later fixes discovered by using c2 > with a different compiler). > > Norman Wilson > Toronto ON > -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Mon Apr 26 08:02:26 2021 From: norman at oclsc.org (Norman Wilson) Date: Sun, 25 Apr 2021 18:02:26 -0400 (EDT) Subject: [TUHS] pcc in 8th edition Message-ID: <20210425220226.A7E5E640CB6@lignose.oclsc.org> Dan Cross: I seem to recall that LCC was also used, at least on 10th Ed. Am I imagining things, or was that real? === Some of the earliest work on lcc was done in 1127; Chris Fraser worked for the Labs for some years, Dave Hanson collaborated from his appointment at Princeton. I believe there was a /usr/bin/lcc. Some programs used it, either because they needed some part of the ISO syntax (pcc2 was pre-ISO) or just because. I don't think that version of lcc used Reiser's c2 optimizer; it generated reasonably good code by itself, including emitting auto-increment/decrement instructions. Later versions of lcc (such as that I later adopted as cc in my personal V10 world) couldn't do that any more, so I had to keep c2, and in fact to modify it to turn addl3 a,b,(p) mova 4(p),p into addl3 a,b,(p)+ (or maybe it was addl2 $4,p, I forget) But that's another story which I'll tell only if asked, and nothing to do with the original question. From cym224 at gmail.com Mon Apr 26 10:18:29 2021 From: cym224 at gmail.com (Nemo Nusquam) Date: Sun, 25 Apr 2021 20:18:29 -0400 Subject: [TUHS] pcc in 8th edition In-Reply-To: <20210425220226.A7E5E640CB6@lignose.oclsc.org> References: <20210425220226.A7E5E640CB6@lignose.oclsc.org> Message-ID: On 2021-04-25 18:02, Norman Wilson wrote (in part): > Some of the earliest work on lcc was done in 1127; Chris > Fraser worked for the Labs for some years, Dave Hanson > collaborated from his appointment at Princeton. I believe > there was a /usr/bin/lcc. Some programs used it, either > because they needed some part of the ISO syntax (pcc2 was > pre-ISO) or just because. > > I don't think that version of lcc used Reiser's c2 optimizer; > it generated reasonably good code by itself, including > emitting auto-increment/decrement instructions. Later > versions of lcc (such as that I later adopted as cc in > my personal V10 world) couldn't do that any more, so I > had to keep c2, and in fact to modify it to turn > addl3 a,b,(p) > mova 4(p),p > into > addl3 a,b,(p)+ > (or maybe it was addl2 $4,p, I forget) > > But that's another story which I'll tell only if asked, > and nothing to do with the original question. Please consider yourself asked. #6-) N. From noel.hunt at gmail.com Mon Apr 26 16:29:26 2021 From: noel.hunt at gmail.com (Noel Hunt) Date: Mon, 26 Apr 2021 16:29:26 +1000 Subject: [TUHS] pcc in 8th edition In-Reply-To: <20210425204842.3FAC4640CB6@lignose.oclsc.org> References: <20210425204842.3FAC4640CB6@lignose.oclsc.org> Message-ID: > I think there are a few Research-specific hacks to add > additional stab info for pi(9.1) ... Having written a Dwarf interface for pi(9.1) I would be most interested to know what those additions were. Noel Hunt -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Tue Apr 27 02:51:18 2021 From: athornton at gmail.com (Adam Thornton) Date: Mon, 26 Apr 2021 09:51:18 -0700 Subject: [TUHS] pcc in 8th edition In-Reply-To: <20210425220226.A7E5E640CB6@lignose.oclsc.org> References: <20210425220226.A7E5E640CB6@lignose.oclsc.org> Message-ID: > Dave Hanson collaborated from his appointment at Princeton. I sat in on an undergrad course from him my first year of grad school (94-95) and he taught it with lcc. I asked “why not gcc” and he said, “gcc is 100,000 lines and I don’t know what 90% of them are doing; lcc is 10,000”. Adam From norman at oclsc.org Tue Apr 27 04:00:51 2021 From: norman at oclsc.org (Norman Wilson) Date: Mon, 26 Apr 2021 14:00:51 -0400 (EDT) Subject: [TUHS] pcc in 8th edition Message-ID: <20210426180051.D39DA640CB6@lignose.oclsc.org> Adam Thornton: I sat in on an undergrad course from [Dave Hanson] my first year of grad school (94-95) and he taught it with lcc. I asked `why not gcc' and he said, `gcc is 100,000 lines and I don't know what 90% of them are doing; lcc is 10,000'. === My copy is indeed about 10K lines, not counting the code-generator modules. Those are C files generated by a utility program lburg from a template file. The three architectures supplied in the distribution, for MIPS, SPARC, and X86, have template files of about 900, 1200, and 700 lines respectively. The template file for the VAX is about 2800 lines, but includes some metalanguage of my own, interpreted by an awk script, to generate extra rules for all the direct-store type-to-type instructions. The C output from lburg for the other architectures is 5000-6000 lines; for the VAX, after expansion by my awk program and then by lburg, is nearly 20K. Did someone say Complex Instruction Set? Norman Wilson Toronto ON From crossd at gmail.com Tue Apr 27 04:11:42 2021 From: crossd at gmail.com (Dan Cross) Date: Mon, 26 Apr 2021 14:11:42 -0400 Subject: [TUHS] pcc in 8th edition In-Reply-To: <20210426180051.D39DA640CB6@lignose.oclsc.org> References: <20210426180051.D39DA640CB6@lignose.oclsc.org> Message-ID: On Mon, Apr 26, 2021 at 2:03 PM Norman Wilson wrote: > Adam Thornton: > > I sat in on an undergrad course from [Dave Hanson] my first year of > grad school (94-95) and he taught it with lcc. I asked `why not > gcc' and he said, `gcc is 100,000 lines and I don't know what 90% > of them are doing; lcc is 10,000'. > > === > > My copy is indeed about 10K lines, not counting the code-generator > modules. Those are C files generated by a utility program lburg > from a template file. The three architectures supplied in the > distribution, for MIPS, SPARC, and X86, have template files of > about 900, 1200, and 700 lines respectively. > > The template file for the VAX is about 2800 lines, but includes > some metalanguage of my own, interpreted by an awk script, to > generate extra rules for all the direct-store type-to-type > instructions. The C output from lburg for the other architectures > is 5000-6000 lines; for the VAX, after expansion by my awk > program and then by lburg, is nearly 20K. > > Did someone say Complex Instruction Set? > Indeed! https://yarchive.net/comp/vax.html I recall one of Mashey's posts talking about the number of page faults that _might_ arise from execution of one instance of one of the more baroque VAX instructions. It was something like 40 (!!). - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Wed Apr 28 05:49:50 2021 From: athornton at gmail.com (Adam Thornton) Date: Tue, 27 Apr 2021 12:49:50 -0700 Subject: [TUHS] How to install 4.3BSD Quasijarus on VAXStation 4000 VLC? Message-ID: Thanks to Emanuel Steibler, I am now in possession of a VAXStation 4000 VLC. I've got OpenVMS installed, but, well, the SCSI2SD gives me two more 2GB disks (the fourth partition is the OpenVMS install CD). I'd like to put Quasijarus on it. Problem is, the VLC only supports, as far as I know, SCSI devices. I'm quite happy to install Quasijarus under simhfrom an emulated SCSI tape to an rz device and then just dd the resulting disk image over to the SD card...but I can't work out how to do it. This (as my simh ini file) works fine for getting to the emulated console: set rz0 rzu att rz0 quas.dsk set rz4 tz30 att rz4 quas.tap boot.cpu Problem is, quas.tap doesn't actually work; neither the prepackaged 4.3BSD-Quasijarus0c.tap nor one I make with mkdisttap.pl and the input stand/miniroot/etc files. I get this: adam at m1-wired:~/Documents/src/quasi$ ./vaxstation4000vlc install.ini VAXstation 4000-VLC (KA48) simulator V4.0-0 Current git commit id: 9bf37d3d /Users/adam/Documents/src/quasi/install.ini-4> att rz4 quas.tap RZ4: Tape Image 'quas.tap' scanned as SIMH format /Users/adam/Documents/src/quasi/install.ini-5> boot cpu Loading boot code from internal ka48a.bin KA48-A V1.2-32B-V4.0 08-00-2B-B2-35-2C 16MB ?? 010 2 LCG 0086 ?? 001 3 DZ 0032 ?? 001 4 CACHE 0512 ?? 001 7 IT 8706 ?? 001 8 SYS 0128 ?? 001 9 NI 0024 >>> show dev VMS/VMB ADDR DEVTYPE NUMBYTES RM/FX WP DEVNAM REV ------- ---- ------- -------- ----- -- ------ --- ESA0 08-00-2B-B2-35-2C DKA0 A/0/0 DISK 2.14GB FX RZ23 0A18 DKA100 A/1/0 DISK ...... FX RZ23 0A18 DKA200 A/2/0 DISK ...... FX RZ23 0A18 DKA300 A/3/0 DISK ...... FX RZ23 0A18 MKA400 A/4/0 TAPE RM TZK50 1.1A DKA500 A/5/0 DISK ...... FX RZ23 0A18 ..HostID.. A/6 INITR DKA700 A/7/0 DISK ...... FX RZ23 0A18 >>> boot mka400: -MKA400 ?48 ENDOFFILE HALT instruction, PC: 00000B15 (MOVL (R11),SP) Sooooo.... How do I make a bootable SCSI tape image from Quasijarus? Or, alternatively, how can I create a bootable ISO image from the Quasijarus installation files (and then either install under simh, or just dd to an SD partition and boot from there, or even burn to an actual CD and install from a SCSI CD-ROM drive)? Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Apr 28 06:51:54 2021 From: clemc at ccc.com (Clem Cole) Date: Tue, 27 Apr 2021 16:51:54 -0400 Subject: [TUHS] How to install 4.3BSD Quasijarus on VAXStation 4000 VLC? In-Reply-To: References: Message-ID: Might I would suggest a slightly different path. Install Quasijarus on a more traditional vax processor with RH style disks [RMxx/RPxx] on the simh. Then add a virtual RZ SCSI disk to the simh system [although you might not even need to do that - as simh just sees the disk as a linear file of blocks without any geometry]. The trick is to make sure the virtual disk is set up so that you have a working system/booting system on the virtual disk when changing the processor type to match the VAXstation. Then just DD the image to a real SCSI drive and move it to the VAXstation. On Tue, Apr 27, 2021 at 3:51 PM Adam Thornton wrote: > Thanks to Emanuel Steibler, I am now in possession of a VAXStation 4000 > VLC. I've got OpenVMS installed, but, well, the SCSI2SD gives me two more > 2GB disks (the fourth partition is the OpenVMS install CD). > > I'd like to put Quasijarus on it. > > Problem is, the VLC only supports, as far as I know, SCSI devices. I'm > quite happy to install Quasijarus under simhfrom an emulated SCSI tape to > an rz device and then just dd the resulting disk image over to the SD > card...but I can't work out how to do it. > > This (as my simh ini file) works fine for getting to the emulated console: > > set rz0 rzu > att rz0 quas.dsk > set rz4 tz30 > att rz4 quas.tap > boot.cpu > > Problem is, quas.tap doesn't actually work; neither the prepackaged > 4.3BSD-Quasijarus0c.tap nor one I make with mkdisttap.pl and the input > stand/miniroot/etc files. > > I get this: > > adam at m1-wired:~/Documents/src/quasi$ ./vaxstation4000vlc install.ini > > VAXstation 4000-VLC (KA48) simulator V4.0-0 Current git commit id: > 9bf37d3d > /Users/adam/Documents/src/quasi/install.ini-4> att rz4 quas.tap > RZ4: Tape Image 'quas.tap' scanned as SIMH format > /Users/adam/Documents/src/quasi/install.ini-5> boot cpu > Loading boot code from internal ka48a.bin > > > > KA48-A V1.2-32B-V4.0 > 08-00-2B-B2-35-2C > 16MB > > ?? 010 2 LCG 0086 > ?? 001 3 DZ 0032 > ?? 001 4 CACHE 0512 > ?? 001 7 IT 8706 > ?? 001 8 SYS 0128 > ?? 001 9 NI 0024 > > >>> show dev > > VMS/VMB ADDR DEVTYPE NUMBYTES RM/FX WP DEVNAM > REV > ------- ---- ------- -------- ----- -- ------ > --- > ESA0 08-00-2B-B2-35-2C > DKA0 A/0/0 DISK 2.14GB FX RZ23 > 0A18 > DKA100 A/1/0 DISK ...... FX RZ23 > 0A18 > DKA200 A/2/0 DISK ...... FX RZ23 > 0A18 > DKA300 A/3/0 DISK ...... FX RZ23 > 0A18 > MKA400 A/4/0 TAPE RM TZK50 > 1.1A > DKA500 A/5/0 DISK ...... FX RZ23 > 0A18 > ..HostID.. A/6 INITR > DKA700 A/7/0 DISK ...... FX RZ23 > 0A18 > > > > >>> boot mka400: > > > -MKA400 > > > ?48 ENDOFFILE > HALT instruction, PC: 00000B15 (MOVL (R11),SP) > > Sooooo.... > > How do I make a bootable SCSI tape image from Quasijarus? Or, > alternatively, how can I create a bootable ISO image from the Quasijarus > installation files (and then either install under simh, or just dd to an SD > partition and boot from there, or even burn to an actual CD and install > from a SCSI CD-ROM drive)? > > Adam > -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Wed Apr 28 13:01:44 2021 From: athornton at gmail.com (Adam Thornton) Date: Tue, 27 Apr 2021 20:01:44 -0700 Subject: [TUHS] How to install 4.3BSD Quasijarus on VAXStation 4000 VLC? In-Reply-To: References: Message-ID: <6FA14ECA-0E2D-4A0A-A1B1-2C0C79FDCFE6@gmail.com> > On Apr 27, 2021, at 1:51 PM, Clem Cole wrote: > > Might I would suggest a slightly different path. > > Install Quasijarus on a more traditional vax processor with RH style disks [RMxx/RPxx] on the simh. Then add a virtual RZ SCSI disk to the simh system [although you might not even need to do that - as simh just sees the disk as a linear file of blocks without any geometry]. The trick is to make sure the virtual disk is set up so that you have a working system/booting system on the virtual disk when changing the processor type to match the VAXstation. Then just DD the image to a real SCSI drive and move it to the VAXstation. I’m guessing I will at least have to copy the right bootloader and update the fstab, but I’ll copy the disk after installation and then see what happens. Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Apr 28 23:15:14 2021 From: clemc at ccc.com (Clem Cole) Date: Wed, 28 Apr 2021 09:15:14 -0400 Subject: [TUHS] How to install 4.3BSD Quasijarus on VAXStation 4000 VLC? In-Reply-To: <6FA14ECA-0E2D-4A0A-A1B1-2C0C79FDCFE6@gmail.com> References: <6FA14ECA-0E2D-4A0A-A1B1-2C0C79FDCFE6@gmail.com> Message-ID: right - but the beauty of doing the heavy lifting in simh is that you add/drop virtual devices as needed. Make one disk with the VAXstation bootstrap and another with the 780 style. Once you know you have a proper bootstrap, root partition, and /usr partition that will work properly on the target / you know that now have the bits you need to boot to 'single user.' If you are really aggressive, you can create /etc/fstab.780 and /etc/fstab.vs before you go to the real HW. Because the key point is the simh 'virtual disks' are just blocks and dd is your friend here. You can build up the bits on the real disk from the known pieces you create separate files for simh. Once you have a physical disk with proper bits boot, then start up to 'single user' and fix up anything that really needs to be HW specific. Although a little work in /etc/rc{,.local} can even be pre-made to automate that by having the script detect with CPU you booted and ln /etc/fstab to the proper one. As I said, you should be able to do almost all of the work on the simh system before you go to the real HW. Sure beats how we had to bootstrap systems back in the day. The truth is we used pretty much the same process to do this type of task, but had to find a common disk between the 'parent' system and the 'target.' simh can make Frankenstein systems that never existed in which adds a layer of ease, plus you even without that, since its just bits, you can take a partition from a virtual disk on any geometry and move them to another disk with a different geometry -- something much harder to do with real hardware. Everything here is just SW, which is a load faster and easier ;-) Good luck, Clem On Tue, Apr 27, 2021 at 11:01 PM Adam Thornton wrote: > > > On Apr 27, 2021, at 1:51 PM, Clem Cole wrote: > > Might I would suggest a slightly different path. > > Install Quasijarus on a more traditional vax processor with RH style > disks [RMxx/RPxx] on the simh. Then add a virtual RZ SCSI disk to the > simh system [although you might not even need to do that - as simh just > sees the disk as a linear file of blocks without any geometry]. The trick > is to make sure the virtual disk is set up so that you have a working > system/booting system on the virtual disk when changing the processor type > to match the VAXstation. Then just DD the image to a real SCSI drive and > move it to the VAXstation. > > > I’m guessing I will at least have to copy the right bootloader and update > the fstab, but I’ll copy the disk after installation and then see what > happens. > > Adam > -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Thu Apr 29 01:32:36 2021 From: athornton at gmail.com (Adam Thornton) Date: Wed, 28 Apr 2021 08:32:36 -0700 Subject: [TUHS] How to install 4.3BSD Quasijarus on VAXStation 4000 VLC? In-Reply-To: References: <6FA14ECA-0E2D-4A0A-A1B1-2C0C79FDCFE6@gmail.com> Message-ID: <0E3FADB3-A923-4F5F-8059-D38A438AEADB@gmail.com> Ah, that’s my next question: none of the simh models seem to support the different disk types simultaneously, but if I understand right it’s just a matter of looking at how peripherals are assembled for a given model (which is probably just in the admittedly kind of gross Makefile) and, as you say, Frankensteining together a hideous abomination VAXstrosity with all the stuff I want. Adam From clemc at ccc.com Thu Apr 29 01:46:27 2021 From: clemc at ccc.com (Clem Cole) Date: Wed, 28 Apr 2021 11:46:27 -0400 Subject: [TUHS] How to install 4.3BSD Quasijarus on VAXStation 4000 VLC? In-Reply-To: <0E3FADB3-A923-4F5F-8059-D38A438AEADB@gmail.com> References: <6FA14ECA-0E2D-4A0A-A1B1-2C0C79FDCFE6@gmail.com> <0E3FADB3-A923-4F5F-8059-D38A438AEADB@gmail.com> Message-ID: replying offline to cut down in list spam On Wed, Apr 28, 2021 at 11:32 AM Adam Thornton wrote: > Ah, that’s my next question: none of the simh models seem to support the > different disk types simultaneously, but if I understand right it’s just a > matter of looking at how peripherals are assembled for a given model (which > is probably just in the admittedly kind of gross Makefile) and, as you say, > Frankensteining together a hideous abomination VAXstrosity with all the > stuff I want. > > Adam > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosenfeld at grumpf.hope-2000.org Thu Apr 29 01:42:00 2021 From: rosenfeld at grumpf.hope-2000.org (Hans Rosenfeld) Date: Wed, 28 Apr 2021 17:42:00 +0200 Subject: [TUHS] How to install 4.3BSD Quasijarus on VAXStation 4000 VLC? In-Reply-To: References: Message-ID: On Tue, Apr 27, 2021 at 12:49:50PM -0700, Adam Thornton wrote: > Thanks to Emanuel Steibler, I am now in possession of a VAXStation 4000 > VLC. I've got OpenVMS installed, but, well, the SCSI2SD gives me two more > 2GB disks (the fourth partition is the OpenVMS install CD). > > I'd like to put Quasijarus on it. > > Problem is, the VLC only supports, as far as I know, SCSI devices. I'm > quite happy to install Quasijarus under simhfrom an emulated SCSI tape to > an rz device and then just dd the resulting disk image over to the SD > card...but I can't work out how to do it. Are you sure that 4.3BSD Quasijarus supports running on a 4000VLC, or utilizing SCSI devices? Last time I looked it didn't support anything newer than the pure QBus MicroVAXen and VAXstations, and the only SCSI devices supported were those on MSCP-to-SCSI controllers. Hans -- %SYSTEM-F-ANARCHISM, The operating system has been overthrown From henry.r.bent at gmail.com Thu Apr 29 02:16:59 2021 From: henry.r.bent at gmail.com (Henry Bent) Date: Wed, 28 Apr 2021 12:16:59 -0400 Subject: [TUHS] How to install 4.3BSD Quasijarus on VAXStation 4000 VLC? In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 at 12:01, Hans Rosenfeld wrote: > > Are you sure that 4.3BSD Quasijarus supports running on a 4000VLC, or > utilizing SCSI devices? Last time I looked it didn't support anything > newer than the pure QBus MicroVAXen and VAXstations, and the only SCSI > devices supported were those on MSCP-to-SCSI controllers. > > Indeed, on Quasijarus the GENERIC config file only supports (see https://github.com/abs0/4.3BSD-Quasijarus/blob/main/sys/conf/GENERIC.vax): cpu "VAX8600" cpu "VAX8200" cpu "VAX780" cpu "VAX750" cpu "VAX730" cpu "VAX630" cpu "VAX650" I think the only Unix to ever support the VLC was NetBSD, or maybe some versions of OpenBSD did too? -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Apr 29 02:22:40 2021 From: clemc at ccc.com (Clem Cole) Date: Wed, 28 Apr 2021 12:22:40 -0400 Subject: [TUHS] How to install 4.3BSD Quasijarus on VAXStation 4000 VLC? In-Reply-To: References: Message-ID: Henry - any idea is you add: cpu "VAX4000" On Wed, Apr 28, 2021 at 12:17 PM Henry Bent wrote: > On Wed, 28 Apr 2021 at 12:01, Hans Rosenfeld < > rosenfeld at grumpf.hope-2000.org> wrote: > >> >> Are you sure that 4.3BSD Quasijarus supports running on a 4000VLC, or >> utilizing SCSI devices? Last time I looked it didn't support anything >> newer than the pure QBus MicroVAXen and VAXstations, and the only SCSI >> devices supported were those on MSCP-to-SCSI controllers. >> >> > Indeed, on Quasijarus the GENERIC config file only supports (see > https://github.com/abs0/4.3BSD-Quasijarus/blob/main/sys/conf/GENERIC.vax): > cpu "VAX8600" > cpu "VAX8200" > cpu "VAX780" > cpu "VAX750" > cpu "VAX730" > cpu "VAX630" > cpu "VAX650" > > I think the only Unix to ever support the VLC was NetBSD, or maybe some > versions of OpenBSD did too? > > -Henry > -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Thu Apr 29 02:33:57 2021 From: henry.r.bent at gmail.com (Henry Bent) Date: Wed, 28 Apr 2021 12:33:57 -0400 Subject: [TUHS] How to install 4.3BSD Quasijarus on VAXStation 4000 VLC? In-Reply-To: References: Message-ID: The support just plain isn't there. There isn't anything in src/sys/vax for any 4000 machine, there isn't LANCE ethernet support in src/sys/vaxif, I don't see any mention of any 53C* SCSI controllers anywhere in the source tree, etc. As Hans said, you're stuck with the older big iron and the older MicroVAXes. Heck, even adding support for the 4000/200 (still a pure Q-Bus machine) looks like it would be a fair amount of work. -Henry On Wed, 28 Apr 2021 at 12:23, Clem Cole wrote: > Henry - any idea is you add: cpu "VAX4000" > > On Wed, Apr 28, 2021 at 12:17 PM Henry Bent > wrote: > >> On Wed, 28 Apr 2021 at 12:01, Hans Rosenfeld < >> rosenfeld at grumpf.hope-2000.org> wrote: >> >>> >>> Are you sure that 4.3BSD Quasijarus supports running on a 4000VLC, or >>> utilizing SCSI devices? Last time I looked it didn't support anything >>> newer than the pure QBus MicroVAXen and VAXstations, and the only SCSI >>> devices supported were those on MSCP-to-SCSI controllers. >>> >>> >> Indeed, on Quasijarus the GENERIC config file only supports (see >> https://github.com/abs0/4.3BSD-Quasijarus/blob/main/sys/conf/GENERIC.vax >> ): >> cpu "VAX8600" >> cpu "VAX8200" >> cpu "VAX780" >> cpu "VAX750" >> cpu "VAX730" >> cpu "VAX630" >> cpu "VAX650" >> >> I think the only Unix to ever support the VLC was NetBSD, or maybe some >> versions of OpenBSD did too? >> >> -Henry >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: