From brunerhome at live.com Fri Aug 1 00:57:19 2025 From: brunerhome at live.com (John Bruner) Date: Thu, 31 Jul 2025 14:57:19 +0000 Subject: [TUHS] curator of 2.11BSD patches? Message-ID: Who is the curator of the 2.11BSD patches? I have a couple of candidate fixes for a future patch. Thanks. --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Fri Aug 1 01:45:58 2025 From: crossd at gmail.com (Dan Cross) Date: Thu, 31 Jul 2025 11:45:58 -0400 Subject: [TUHS] curator of 2.11BSD patches? In-Reply-To: References: Message-ID: On Thu, Jul 31, 2025 at 11:07 AM John Bruner wrote: > Who is the curator of the 2.11BSD patches? I have a couple of candidate fixes for a future patch. Thanks. For many years, it was Steven Schultz, and he would post patches to comp.bugs.2bsd. I don't know if he's still doing it, nor do I have contact information for him. Patch #490 is from this year, and is on http://www.2bsd.com/2.11BSD/, or the TUHS website, along with other patches (https://www.tuhs.org/Archive/Distributions/UCB/2.11BSD/Patches/). Looks like Frank Wortner uploaded it. - Dan C. From tuhs at tuhs.org Fri Aug 1 02:12:49 2025 From: tuhs at tuhs.org (Martin Renters via TUHS) Date: Thu, 31 Jul 2025 12:12:49 -0400 Subject: [TUHS] curator of 2.11BSD patches? In-Reply-To: References: Message-ID: <9A093510-58C7-4406-B210-0C1AA2FE87BB@teckelworks.com> Steven Schultz is curating them. The sendbug command on 2.11BSD sends reports to bugs at 2bsd.com . Martin > On Jul 31, 2025, at 10:57 AM, John Bruner wrote: > > Who is the curator of the 2.11BSD patches? I have a couple of candidate fixes for a future patch. Thanks. > > --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Fri Aug 1 03:31:08 2025 From: will.senn at gmail.com (Will Senn) Date: Thu, 31 Jul 2025 12:31:08 -0500 Subject: [TUHS] curator of 2.11BSD patches? In-Reply-To: References: Message-ID: I seem to remember Warner Losh (cced) was doing something with 2.11 patching... I may be misremembering. Will On 7/31/25 10:45 AM, Dan Cross wrote: > On Thu, Jul 31, 2025 at 11:07 AM John Bruner wrote: >> Who is the curator of the 2.11BSD patches? I have a couple of candidate fixes for a future patch. Thanks. > For many years, it was Steven Schultz, and he would post patches to > comp.bugs.2bsd. I don't know if he's still doing it, nor do I have > contact information for him. > > Patch #490 is from this year, and is on http://www.2bsd.com/2.11BSD/, > or the TUHS website, along with other patches > (https://www.tuhs.org/Archive/Distributions/UCB/2.11BSD/Patches/). > > Looks like Frank Wortner uploaded it. > > - Dan C. From crossd at gmail.com Fri Aug 1 03:35:20 2025 From: crossd at gmail.com (Dan Cross) Date: Thu, 31 Jul 2025 13:35:20 -0400 Subject: [TUHS] curator of 2.11BSD patches? In-Reply-To: References: Message-ID: On Thu, Jul 31, 2025 at 1:31 PM Will Senn wrote: > I seem to remember Warner Losh (cced) was doing something with 2.11 > patching... I may be misremembering. Warner was doing the inverse, trying to get back to 2.11BSD as first cut by UCB. - Dan C. > On 7/31/25 10:45 AM, Dan Cross wrote: > > On Thu, Jul 31, 2025 at 11:07 AM John Bruner wrote: > >> Who is the curator of the 2.11BSD patches? I have a couple of candidate fixes for a future patch. Thanks. > > For many years, it was Steven Schultz, and he would post patches to > > comp.bugs.2bsd. I don't know if he's still doing it, nor do I have > > contact information for him. > > > > Patch #490 is from this year, and is on http://www.2bsd.com/2.11BSD/, > > or the TUHS website, along with other patches > > (https://www.tuhs.org/Archive/Distributions/UCB/2.11BSD/Patches/). > > > > Looks like Frank Wortner uploaded it. > > > > - Dan C. From imp at bsdimp.com Fri Aug 1 03:41:46 2025 From: imp at bsdimp.com (Warner Losh) Date: Thu, 31 Jul 2025 07:41:46 -1000 Subject: [TUHS] curator of 2.11BSD patches? In-Reply-To: References: Message-ID: On Thu, Jul 31, 2025 at 7:35 AM Dan Cross wrote: > > On Thu, Jul 31, 2025 at 1:31 PM Will Senn wrote: > > I seem to remember Warner Losh (cced) was doing something with 2.11 > > patching... I may be misremembering. > > Warner was doing the inverse, trying to get back to 2.11BSD as first cut by UCB. I did make it back to something that's 99% 2.11BSD first tape from UCB. I was going to reverse the process to make a full git history, but never proceeded to that before time demands from other projects made me put this aside. Warner > - Dan C. > > > > On 7/31/25 10:45 AM, Dan Cross wrote: > > > On Thu, Jul 31, 2025 at 11:07 AM John Bruner wrote: > > >> Who is the curator of the 2.11BSD patches? I have a couple of candidate fixes for a future patch. Thanks. > > > For many years, it was Steven Schultz, and he would post patches to > > > comp.bugs.2bsd. I don't know if he's still doing it, nor do I have > > > contact information for him. > > > > > > Patch #490 is from this year, and is on http://www.2bsd.com/2.11BSD/, > > > or the TUHS website, along with other patches > > > (https://www.tuhs.org/Archive/Distributions/UCB/2.11BSD/Patches/). > > > > > > Looks like Frank Wortner uploaded it. > > > > > > - Dan C. From jsg at jsg.id.au Thu Aug 7 11:36:47 2025 From: jsg at jsg.id.au (Jonathan Gray) Date: Thu, 7 Aug 2025 11:36:47 +1000 Subject: [TUHS] CSIRO Unix Message-ID: CSIRO is an Australian government research agency with a long history. Siromath, a commercial spinoff, had a binary redistribution license for Unix. The Siromath Unix was called SIRONIX. The Australian Unison computer was sold with SIRONIX. Siromath was also going to provide a version of Unix for the DCR/CSIRONET workstation. At some point they switched to a port of System V/68 from Neology/Softway. Does anyone know why? Or if the CSIRONET workstation got beyond the prototype stage? Did it get cancelled when CSIRONET was privatised? For more background notes see https://github.com/jonathangray/csiro-unix From pugs78 at gmail.com Wed Aug 13 10:57:19 2025 From: pugs78 at gmail.com (Tom Lyon) Date: Tue, 12 Aug 2025 17:57:19 -0700 Subject: [TUHS] EUUG Spring 1990 Proceedings? Message-ID: Anyone holding onto this? Online anywhere? Can I borrow it for scanning? Thx. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pugs78 at gmail.com Wed Aug 13 10:59:24 2025 From: pugs78 at gmail.com (Tom Lyon) Date: Tue, 12 Aug 2025 17:59:24 -0700 Subject: [TUHS] NFS 40th anniversary event Message-ID: Part of https://www.msstconference.org/ Love it or hate it, should be something for everyone -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsg at jsg.id.au Wed Aug 13 11:05:52 2025 From: jsg at jsg.id.au (Jonathan Gray) Date: Wed, 13 Aug 2025 11:05:52 +1000 Subject: [TUHS] EUUG Spring 1990 Proceedings? In-Reply-To: References: Message-ID: On Tue, Aug 12, 2025 at 05:57:19PM -0700, Tom Lyon wrote: > Anyone holding onto this? > Online anywhere? > Can I borrow it for scanning? > Thx. EUUG Spring Conference, 23-27 April, Munich, West Germany, 1990 https://datamuseum.dk/wiki/Bits:Keyword/DKUUG/EUUG From lm at mcvoy.com Wed Aug 13 11:55:09 2025 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 12 Aug 2025 18:55:09 -0700 Subject: [TUHS] NFS 40th anniversary event In-Reply-To: References: Message-ID: <20250813015509.GA17097@mcvoy.com> On Tue, Aug 12, 2025 at 05:59:24PM -0700, Tom Lyon wrote: > Part of https://www.msstconference.org/ > > Love it or hate it, should be something for everyone I think Sun people love it, because the Sun implementation just worked, the rest of the world mostly hates it. I learned this when I left Sun and got to use other NFS implementations, they sucked. We supported BitKeeper on NFS which meant we had to do lock files on NFS on all platforms. Believe me when I say I know that other NFS implementations were a mess. Read all the drama here: https://github.com/bitkeeper-scm/bitkeeper/blob/master/src/port/sccs_lockfile.c I really didn't get the NFS hate until I left Sun. Sun ran their entire company on NFS (and the automounter). The whole experience was super pleasant and it just worked. Other companies didn't work as hard on their implementation, I got the feeling it was "well, we have to support this but don't really want to". And it showed. I believe later versions of Linux approached SunOS level of NFS. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From dave at horsfall.org Wed Aug 13 13:05:23 2025 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 13 Aug 2025 13:05:23 +1000 (EST) Subject: [TUHS] NFS 40th anniversary event In-Reply-To: <20250813015509.GA17097@mcvoy.com> References: <20250813015509.GA17097@mcvoy.com> Message-ID: On Tue, 12 Aug 2025, Larry McVoy wrote: > I think Sun people love it, because the Sun implementation just worked, > the rest of the world mostly hates it. I learned this when I left Sun > and got to use other NFS implementations, they sucked. I can vouch for Sun's NFS working well, and others' not so much (zeroed blocks returned etc)... > We supported BitKeeper on NFS which meant we had to do lock files on NFS > on all platforms. Believe me when I say I know that other NFS > implementations were a mess. Read all the drama here: I'm impressed by the workarounds for obscure kernel bugs :-) -- Dave From alvitar at xavax.com Wed Aug 13 15:59:33 2025 From: alvitar at xavax.com (Phillip Harbison) Date: Wed, 13 Aug 2025 00:59:33 -0500 Subject: [TUHS] Greetings! In-Reply-To: References: <20250813015509.GA17097@mcvoy.com> Message-ID: <64716bda-3544-4a5c-9710-76496387104e@xavax.com> Thank you to whoever added me to this list! I have been a UNIX & C disciple since 1982. I spent much of the 1980s writing UNIX, BSD, and OSF/1 device drivers. I ran "madhat", the first public access USENET site in Huntsville. Madhat was a homebuilt 68000 running Unisoft's port of System V Release 0. I also set up "uahcs1", the first UNIX and USENET host at The University of Alabama in Huntsville (UAH). Uahcs1 was a Unisys U7000, originally known as the Power 6/32 minicomputer developed by Computer Consoles Inc., running their port of 4.3 BSD. During my career I have worked with UNIX v7, UNIX System V, AIX, BSD, HPUX, IRIX, Linux, MkLinux, OSF/1, Solaris, SunOS, Ultrix, and Xenix, as well as variants such as Mach, Minix, and Xinu. All of my currently active systems run various versions of macOS. In the past my home office was a Microsoft-Free Zone (tm) but alas too many clients insisted on the use of "Word" so I was forced to compromise and partially surrender to the Dark Side (but only in a Windoze VM). One of my current hobby projects is building a RISC processor using 1980 technology, specifically the Am2900 family of bit-slice components. I call it Project Madhat. My goal is to perform as well as a VAX-11/780 at least for integer code. I hope it will eventually run 4.4 BSD. If interested you can read about it here. http://www.xavax.com/madhat/ My professional work is fragmented. For years I've been developing a Massively-Parallel Processor based on the NXP (formerly Freescale or Motorola) T4240 which has 12 PowerPC e6500 cores and built-in Serial RapidIO. The execution units will run a lean microkernel but the overall system will be managed by some flavor of UNIX. I don't currently have any information about the MPP online without an NDA, but I would be happy to answer general questions about it. I was recently motivated by the Russo-Ukraine war to start a company called Trident Droneworks. It is developing systems for the Ukrainian military. If interested you can read about that here. http://tridentdroneworks.com/ Thanks again for adding me. I look forward to discussing UNIX lore. -- Phillip L Harbison From douglas.mcilroy at dartmouth.edu Thu Aug 14 00:00:03 2025 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Wed, 13 Aug 2025 10:00:03 -0400 Subject: [TUHS] NFS 40th anniversary event In-Reply-To: References: <20250813015509.GA17097@mcvoy.com> Message-ID: I was always sorry that Peter Weinberger's RFS never made it outside Bell Labs. It allowed networking between separately administered systems by mapping UIDs. Doug On Tue, Aug 12, 2025 at 11:05 PM Dave Horsfall wrote: > > On Tue, 12 Aug 2025, Larry McVoy wrote: > > > I think Sun people love it, because the Sun implementation just worked, > > the rest of the world mostly hates it. I learned this when I left Sun > > and got to use other NFS implementations, they sucked. > > I can vouch for Sun's NFS working well, and others' not so much (zeroed > blocks returned etc)... > > > We supported BitKeeper on NFS which meant we had to do lock files on NFS > > on all platforms. Believe me when I say I know that other NFS > > implementations were a mess. Read all the drama here: > > I'm impressed by the workarounds for obscure kernel bugs :-) > > -- Dave From crossd at gmail.com Thu Aug 14 00:18:34 2025 From: crossd at gmail.com (Dan Cross) Date: Wed, 13 Aug 2025 10:18:34 -0400 Subject: [TUHS] NFS 40th anniversary event In-Reply-To: References: <20250813015509.GA17097@mcvoy.com> Message-ID: On Wed, Aug 13, 2025 at 10:00 AM Douglas McIlroy wrote: > I was always sorry that Peter Weinberger's RFS never made it outside > Bell Labs. It allowed networking between separately administered > systems by mapping UIDs. I believe it did? If I recall correctly, it was available with System V, though perhaps I am misremembering. I have no doubt that RFS was technically superior to NFS, but Sun had non-technical market advantages. Assuming that I am remembering correctly, I suspect it was unsuccessful commercially for two reasons: 1. Sun gave NFS (and the associated RPC layer) away for free, under a particularly liberal license, which lead to lots of interoperability (Larry's and Dave's comments notwithstanding). I suspect by the time RFS was available, it was much more expensive and less interoperable across heterogeneous systems. 2. Sun was quite adamant that NFS be stateless, and also not tied to Unix filesystem semantics, whereas (as I understood it) RFS was both stateful and deeply imbued with Unix semantics. Related to (2), while the File System Switch that was developed to support RFS was very elegant, I think that Sun's "vnode" architecture was seen as more flexible, permitting Unix to incorporate support for all sorts of foreign filesystem types (useful when CD-ROMs and things like floppy disks using the MS-DOS FAT format started becoming common). I suppose RFS could have been adapted to use vnodes, but by then it probably wasn't considered worth the effort due to lack of adoption. It may be worth mentioning that some NFS implementations are configurable for UID remapping in the server. I recall Sun environments with NFS and NIS (the mechanism for distributing /etc/passwd, groups, and other administrative data around a network). It was a really pleasant environment, and extremely productive. Properly configured, you could log into essentially any machine on the network and have access to your home directory, common data, locally installed programs (that of course lived on NFS), and so on. It was quite common to tell a colleague to just have a look in your home directory for something you were working on, facilitating collaboration, and so on. Diskless and "dataless" machines were common; the latter being machines that mounted _most_ things from a central NFS server, but had the operating system itself (really, /, /usr and /tmp) locally installed on a disk. It required a lot of effort to maintain, since Unix machines were still fundamentally meant to be standalone, and it wasn't as elegant as Plan 9 ultimately was, but it was very nice for the time. - Dan C. > On Tue, Aug 12, 2025 at 11:05 PM Dave Horsfall wrote: > > > > On Tue, 12 Aug 2025, Larry McVoy wrote: > > > > > I think Sun people love it, because the Sun implementation just worked, > > > the rest of the world mostly hates it. I learned this when I left Sun > > > and got to use other NFS implementations, they sucked. > > > > I can vouch for Sun's NFS working well, and others' not so much (zeroed > > blocks returned etc)... > > > > > We supported BitKeeper on NFS which meant we had to do lock files on NFS > > > on all platforms. Believe me when I say I know that other NFS > > > implementations were a mess. Read all the drama here: > > > > I'm impressed by the workarounds for obscure kernel bugs :-) > > > > -- Dave From arnold at skeeve.com Thu Aug 14 00:59:58 2025 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 13 Aug 2025 08:59:58 -0600 Subject: [TUHS] NFS 40th anniversary event In-Reply-To: References: <20250813015509.GA17097@mcvoy.com> Message-ID: <202508131459.57DExwjZ032177@freefriends.org> Dan Cross wrote: > On Wed, Aug 13, 2025 at 10:00 AM Douglas McIlroy > wrote: > > I was always sorry that Peter Weinberger's RFS never made it outside > > Bell Labs. It allowed networking between separately administered > > systems by mapping UIDs. > > I believe it did? If I recall correctly, it was available with System > V, though perhaps I am misremembering. It was a different RFS, developed by USG. It had full Unix semantics, including ioctls and fcntl, for machines of the same architecture. It was stateful, which meant if the server went away, you could hang your shell at the very least. It first came out in SVR3. Earlier versions of SunOS 5 supported it; it was dropped in later versions. It didn't get widespread support both because NFS had a big head start, and because by the time it came out, the SVR3 licensing terms had gotten onerous for most vendors. No disagreement with the rest of you note. :-) Arnold From douglas.mcilroy at dartmouth.edu Thu Aug 14 01:26:47 2025 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Wed, 13 Aug 2025 11:26:47 -0400 Subject: [TUHS] NFS 40th anniversary event In-Reply-To: <202508131459.57DExwjZ032177@freefriends.org> References: <20250813015509.GA17097@mcvoy.com> <202508131459.57DExwjZ032177@freefriends.org> Message-ID: "never made it outside Bell Labs" was a poor choice of words for "never gained acceptance outside of Bell Labs". I agree with Dan and Arnold, but I lament the fact that NFS : RFS :: intranet : internet RFS had the grander vision. To be fair, I must admit that I have no idea how efficient or robust the released version was. Certainly the original worked very well. Doug On Wed, Aug 13, 2025 at 11:00 AM wrote: > > Dan Cross wrote: > > > On Wed, Aug 13, 2025 at 10:00 AM Douglas McIlroy > > wrote: > > > I was always sorry that Peter Weinberger's RFS never made it outside > > > Bell Labs. It allowed networking between separately administered > > > systems by mapping UIDs. > > > > I believe it did? If I recall correctly, it was available with System > > V, though perhaps I am misremembering. > > It was a different RFS, developed by USG. It had full Unix semantics, > including ioctls and fcntl, for machines of the same architecture. It > was stateful, which meant if the server went away, you could hang your > shell at the very least. It first came out in SVR3. > > Earlier versions of SunOS 5 supported it; it was dropped in later > versions. > > It didn't get widespread support both because NFS had a big head > start, and because by the time it came out, the SVR3 licensing terms > had gotten onerous for most vendors. > > No disagreement with the rest of you note. :-) > > Arnold From arnold at skeeve.com Thu Aug 14 01:34:05 2025 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 13 Aug 2025 09:34:05 -0600 Subject: [TUHS] NFS 40th anniversary event In-Reply-To: References: <20250813015509.GA17097@mcvoy.com> <202508131459.57DExwjZ032177@freefriends.org> Message-ID: <202508131534.57DFY5h2034448@freefriends.org> System V RFS was a different animal that Research RFS. IIRC Stephen Rago or someone like that did a USENIX paper about putting the Research RFS into SVR4. SVR4 RFS required kernel changes for client and server, IIRC, whereas I believe that Research RFS only needed kernel changes for the client and used a user-level server. To borrow a phrase, "memory grows dim", so take the above with a grain of salt. Arnold Douglas McIlroy wrote: > "never made it outside Bell Labs" was a poor choice of words for > "never gained acceptance outside of Bell Labs". > I agree with Dan and Arnold, but I lament the fact that NFS : RFS :: > intranet : internet RFS had the grander vision. To be fair, I must > admit that I have no idea how efficient or robust the released version > was. Certainly the original worked very well. > > Doug > > On Wed, Aug 13, 2025 at 11:00 AM wrote: > > > > Dan Cross wrote: > > > > > On Wed, Aug 13, 2025 at 10:00 AM Douglas McIlroy > > > wrote: > > > > I was always sorry that Peter Weinberger's RFS never made it outside > > > > Bell Labs. It allowed networking between separately administered > > > > systems by mapping UIDs. > > > > > > I believe it did? If I recall correctly, it was available with System > > > V, though perhaps I am misremembering. > > > > It was a different RFS, developed by USG. It had full Unix semantics, > > including ioctls and fcntl, for machines of the same architecture. It > > was stateful, which meant if the server went away, you could hang your > > shell at the very least. It first came out in SVR3. > > > > Earlier versions of SunOS 5 supported it; it was dropped in later > > versions. > > > > It didn't get widespread support both because NFS had a big head > > start, and because by the time it came out, the SVR3 licensing terms > > had gotten onerous for most vendors. > > > > No disagreement with the rest of you note. :-) > > > > Arnold From martin at oneiros.de Thu Aug 14 01:47:02 2025 From: martin at oneiros.de (=?UTF-8?Q?Martin_Schr=C3=B6der?=) Date: Wed, 13 Aug 2025 17:47:02 +0200 Subject: [TUHS] NFS 40th anniversary event In-Reply-To: <202508131459.57DExwjZ032177@freefriends.org> References: <20250813015509.GA17097@mcvoy.com> <202508131459.57DExwjZ032177@freefriends.org> Message-ID: Am Mi., 13. Aug. 2025 um 17:00 Uhr schrieb : > It was a different RFS, developed by USG. It had full Unix semantics, > including ioctls and fcntl, for machines of the same architecture. It > was stateful, which meant if the server went away, you could hang your > shell at the very least. It first came out in SVR3. Was that https://en.wikipedia.org/wiki/Remote_File_Sharing ? If so, that article wants some love from an expert. And what became of it? Best Martin From lm at mcvoy.com Thu Aug 14 01:56:48 2025 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 13 Aug 2025 08:56:48 -0700 Subject: [TUHS] NFS 40th anniversary event In-Reply-To: References: <20250813015509.GA17097@mcvoy.com> Message-ID: <20250813155648.GA25260@mcvoy.com> On Wed, Aug 13, 2025 at 10:18:34AM -0400, Dan Cross wrote: > On Wed, Aug 13, 2025 at 10:00???AM Douglas McIlroy > wrote: > > I was always sorry that Peter Weinberger's RFS never made it outside > > Bell Labs. It allowed networking between separately administered > > systems by mapping UIDs. > > I believe it did? If I recall correctly, it was available with System > V, though perhaps I am misremembering. Sunos had it, my office mate ported it. I was unimpressed, it worked well between the same archs but was riddled with byte order problems and ioctl calls that were not portable. From tuhs at tuhs.org Thu Aug 14 02:24:30 2025 From: tuhs at tuhs.org (=?utf-8?b?UGV0ZXIgV2VpbmJlcmdlciAo5rip5Y2a5qC8KSB2aWEgVFVIUw==?=) Date: Wed, 13 Aug 2025 12:24:30 -0400 Subject: [TUHS] NFS 40th anniversary event In-Reply-To: <20250813155648.GA25260@mcvoy.com> References: <20250813015509.GA17097@mcvoy.com> <20250813155648.GA25260@mcvoy.com> Message-ID: It was a research proof-of-princple. (i.e.. partly principled and partly really hacky. My list of its issues was pretty long.) (If A mounted B's file system somewhere, and B mounted A's, then the directory tree was infinite. That's mathematics, not a bug.) On Wed, Aug 13, 2025 at 11:56 AM Larry McVoy wrote: > > On Wed, Aug 13, 2025 at 10:18:34AM -0400, Dan Cross wrote: > > On Wed, Aug 13, 2025 at 10:00???AM Douglas McIlroy > > wrote: > > > I was always sorry that Peter Weinberger's RFS never made it outside > > > Bell Labs. It allowed networking between separately administered > > > systems by mapping UIDs. > > > > I believe it did? If I recall correctly, it was available with System > > V, though perhaps I am misremembering. > > Sunos had it, my office mate ported it. I was unimpressed, it worked well > between the same archs but was riddled with byte order problems and > ioctl calls that were not portable. From pugs78 at gmail.com Thu Aug 14 02:43:08 2025 From: pugs78 at gmail.com (Tom Lyon) Date: Wed, 13 Aug 2025 09:43:08 -0700 Subject: [TUHS] NFS 40th anniversary event In-Reply-To: References: <20250813015509.GA17097@mcvoy.com> <20250813155648.GA25260@mcvoy.com> Message-ID: BTW, my own opinions abut NFS can be seen in my "NFS Must Die!" talk here: https://www.youtube.com/watch?v=ZVF_djcccKc&ab_channel=TomLyon Not that NFS *was* bad - but it *is* bad (for non-casual use). Like the C language, it was great for its time. Not so much anymore. On Wed, Aug 13, 2025 at 9:24 AM Peter Weinberger (温博格) via TUHS < tuhs at tuhs.org> wrote: > It was a research proof-of-princple. (i.e.. partly principled and > partly really hacky. My list of its issues was pretty long.) > > (If A mounted B's file system somewhere, and B mounted A's, then the > directory tree was infinite. That's mathematics, not a bug.) > > On Wed, Aug 13, 2025 at 11:56 AM Larry McVoy wrote: > > > > On Wed, Aug 13, 2025 at 10:18:34AM -0400, Dan Cross wrote: > > > On Wed, Aug 13, 2025 at 10:00???AM Douglas McIlroy > > > wrote: > > > > I was always sorry that Peter Weinberger's RFS never made it outside > > > > Bell Labs. It allowed networking between separately administered > > > > systems by mapping UIDs. > > > > > > I believe it did? If I recall correctly, it was available with System > > > V, though perhaps I am misremembering. > > > > Sunos had it, my office mate ported it. I was unimpressed, it worked > well > > between the same archs but was riddled with byte order problems and > > ioctl calls that were not portable. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lyndon at orthanc.ca Thu Aug 14 03:08:53 2025 From: lyndon at orthanc.ca (Lyndon Nerenberg (VE7TFX/VE6BBM)) Date: Wed, 13 Aug 2025 10:08:53 -0700 Subject: [TUHS] RFS In-Reply-To: References: <20250813015509.GA17097@mcvoy.com> Message-ID: <5be7bd0177c9c57e@orthanc.ca> Douglas McIlroy writes: > I was always sorry that Peter Weinberger's RFS never made it outside > Bell Labs. It allowed networking between separately administered > systems by mapping UIDs. My experience with (SVR3) RFS can be summed up in two words: stateful, and brittle We ran RFS on a "cluster" of four 3B2s, and while it worked, to varying degrees, the statefulness of the protocol inevitably led to the whole thing locking up, requiring a reboot of all four machines to recover. This was especially problematic when we accessed the one 9-track drive over RFS when attempting backups. I eventually gave up on it, and hauled out the Lachman NFS source tape and got NFS running on all the machines. Life was much happier afterwards. I do not miss RFS. --lyndon From lm at mcvoy.com Thu Aug 14 03:27:15 2025 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 13 Aug 2025 10:27:15 -0700 Subject: [TUHS] NFS 40th anniversary event In-Reply-To: References: <20250813015509.GA17097@mcvoy.com> <20250813155648.GA25260@mcvoy.com> Message-ID: <20250813172715.GB25260@mcvoy.com> They both served a purpose. I'm still a fan of both, C especially, but I'll admit that C needs careful programmers. When my older son was getting into programming, he asked about C (he started with python and hates it, has moved to Julia for most mathy stuff). I told him that C is like a sports car on a narrow, twisty, mountain road with no guard rails. If you drive a car like that in those conditions, and look at your phone, you're gonna have a very bad day. On the other hand, if you are a good driver and are paying attention, that can be a boat load of fun. I'm watching your talk and I'm struct by how much of this problem space we solved in BitKeeper. Someone had a .signature that said "You're lost in a tree of repositories, all almost the same". We certainly solved the shared mutable data problem. Our stuff didn't scale to billions of files though we took a stab at that with nested repositories that worked pretty well. I got to the point where you are more or less arguing for the same thing. I'd be careful about scaling. If you want consistency, you have to keep a list of files you are managing. That list gets big. As for POSIX, I've very much read the early spec, the whole thing, many times. My first job at Sun was implementing POSIX conformance in SunOS. Maybe I'm naive, but I didn't find it particularly hard, it was a lot of grunt work, a lot of checking each file system to make them all the same. I'm sure there is some subtle thing I've missed but Sun was happy with my work so I don't think I was that far off. On Wed, Aug 13, 2025 at 09:43:08AM -0700, Tom Lyon wrote: > BTW, my own opinions abut NFS can be seen in my "NFS Must Die!" talk here: > https://www.youtube.com/watch?v=ZVF_djcccKc&ab_channel=TomLyon > > Not that NFS *was* bad - but it *is* bad (for non-casual use). > Like the C language, it was great for its time. Not so much anymore. > > > > On Wed, Aug 13, 2025 at 9:24???AM Peter Weinberger (?????????) via TUHS < > tuhs at tuhs.org> wrote: > > > It was a research proof-of-princple. (i.e.. partly principled and > > partly really hacky. My list of its issues was pretty long.) > > > > (If A mounted B's file system somewhere, and B mounted A's, then the > > directory tree was infinite. That's mathematics, not a bug.) > > > > On Wed, Aug 13, 2025 at 11:56???AM Larry McVoy wrote: > > > > > > On Wed, Aug 13, 2025 at 10:18:34AM -0400, Dan Cross wrote: > > > > On Wed, Aug 13, 2025 at 10:00???AM Douglas McIlroy > > > > wrote: > > > > > I was always sorry that Peter Weinberger's RFS never made it outside > > > > > Bell Labs. It allowed networking between separately administered > > > > > systems by mapping UIDs. > > > > > > > > I believe it did? If I recall correctly, it was available with System > > > > V, though perhaps I am misremembering. > > > > > > Sunos had it, my office mate ported it. I was unimpressed, it worked > > well > > > between the same archs but was riddled with byte order problems and > > > ioctl calls that were not portable. > > -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From will.senn at gmail.com Thu Aug 14 06:24:42 2025 From: will.senn at gmail.com (Will Senn) Date: Wed, 13 Aug 2025 15:24:42 -0500 Subject: [TUHS] NFS 40th anniversary event In-Reply-To: References: <20250813015509.GA17097@mcvoy.com> <20250813155648.GA25260@mcvoy.com> Message-ID: From my own experience, no real depth of knowledge here... I use NFS for my home shares. Painless with automount and nfsv4. I can't speak to widespread use in enterprise, but as a "casual" nfs user, it gets the job done nicely. I share a folder called ark from one of my servers and mount it on all of my machines. The ark lives on a mirrored zpool that is frequently snapshotted to another mirrored zpool on another server (I'm less of a zfs casual user, but that's an aside). I haven't lost a bit this way in the couple of years since I stood up the nfs share and I offloaded about 1TB of stuff I like to have on hand to the server. I tried Samba, ick, seems like windowism to me and I tried some NAS stuff, but nfs was fastest and simplest. I haven't really found anything better that works as painlessly as nfs, though I do look into alternatives every so often. What else to try? Thanks, Will On 8/13/25 11:43 AM, Tom Lyon wrote: > BTW, my own opinions abut NFS can be seen in my "NFS Must Die!" talk > here: https://www.youtube.com/watch?v=ZVF_djcccKc&ab_channel=TomLyon > > > Not that NFS *was* bad - but it *is* bad (for non-casual use). > Like the C language, it was great for its time.  Not so much anymore. > > > > On Wed, Aug 13, 2025 at 9:24 AM Peter Weinberger (温博格) via TUHS > wrote: > > It was a research proof-of-princple. (i.e.. partly principled and > partly really hacky. My list of its issues was pretty long.) > > (If A mounted B's file system somewhere, and B mounted A's, then the > directory tree was infinite. That's mathematics, not a bug.) > > On Wed, Aug 13, 2025 at 11:56 AM Larry McVoy wrote: > > > > On Wed, Aug 13, 2025 at 10:18:34AM -0400, Dan Cross wrote: > > > On Wed, Aug 13, 2025 at 10:00???AM Douglas McIlroy > > > wrote: > > > > I was always sorry that Peter Weinberger's RFS never made it > outside > > > > Bell Labs. It allowed networking between separately administered > > > > systems by mapping UIDs. > > > > > > I believe it did?  If I recall correctly, it was available > with System > > > V, though perhaps I am misremembering. > > > > Sunos had it, my office mate ported it.  I was unimpressed, it > worked well > > between the same archs but was riddled with byte order problems and > > ioctl calls that were not portable. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at quintile.net Thu Aug 14 06:40:55 2025 From: steve at quintile.net (Steve Simon) Date: Wed, 13 Aug 2025 22:40:55 +0200 Subject: [TUHS] RFS Message-ID: <7B948994-E347-4ECF-AE59-A3B0A38953F6@quintile.net> my memory is the major differences between the research RFS and USG’s RFS was the support of ioctls (as mentioned) and, Research RFS supported exporting file trees with an abstract name rather than the path on the source machine - a small but very useful change. research RFS could (i feel) be seen as the direct ancestor of plan9’s 9p protocol. -Steve From jsg at jsg.id.au Thu Aug 14 10:31:26 2025 From: jsg at jsg.id.au (Jonathan Gray) Date: Thu, 14 Aug 2025 10:31:26 +1000 Subject: [TUHS] NFS 40th anniversary event In-Reply-To: References: <20250813015509.GA17097@mcvoy.com> Message-ID: On Wed, Aug 13, 2025 at 10:18:34AM -0400, Dan Cross wrote: > On Wed, Aug 13, 2025 at 10:00 AM Douglas McIlroy > wrote: > > I was always sorry that Peter Weinberger's RFS never made it outside > > Bell Labs. It allowed networking between separately administered > > systems by mapping UIDs. > > I believe it did? If I recall correctly, it was available with System > V, though perhaps I am misremembering. > > I have no doubt that RFS was technically superior to NFS, but Sun had > non-technical market advantages. Assuming that I am remembering > correctly, I suspect it was unsuccessful commercially for two reasons: > > 1. Sun gave NFS (and the associated RPC layer) away for free, under a > particularly liberal license, which lead to lots of interoperability > (Larry's and Dave's comments notwithstanding). I suspect by the time > RFS was available, it was much more expensive and less interoperable > across heterogeneous systems. The NFS reference code was licensed under NDA with some cost involved according to Rick Macklem who wrote the NFS code in 4.3BSD-Reno. Rick Macklem post to comp.protocols.nfs Aug 6, 1999 https://groups.google.com/g/comp.protocols.nfs/c/npQbxPe_ZeQ/m/Z_yQcsh56mkJ The userland RPC part was under different terms. "Sun will publish the source code for the user-level libraries that implement RPC and XDR." Bill Shannon post to net.unix-wizards Jan 13, 1985 https://groups.google.com/g/net.unix-wizards/c/PkJdZgCbrC4/m/u0kt3eeFSt4J Sun RPC sources were later posted to mod.sources and included on USENIX tapes. From sauer at technologists.com Thu Aug 14 10:54:19 2025 From: sauer at technologists.com (Charles H. Sauer (he/him)) Date: Wed, 13 Aug 2025 19:54:19 -0500 Subject: [TUHS] NFS 40th anniversary event In-Reply-To: References: <20250813015509.GA17097@mcvoy.com> Message-ID: <72c3722a-1feb-4131-aebd-bf996e659bb3@technologists.com> On 8/13/2025 7:31 PM, Jonathan Gray wrote: > On Wed, Aug 13, 2025 at 10:18:34AM -0400, Dan Cross wrote: >> On Wed, Aug 13, 2025 at 10:00 AM Douglas McIlroy >> wrote: >>> I was always sorry that Peter Weinberger's RFS never made it outside >>> Bell Labs. It allowed networking between separately administered >>> systems by mapping UIDs. >> >> I believe it did? If I recall correctly, it was available with System >> V, though perhaps I am misremembering. >> >> I have no doubt that RFS was technically superior to NFS, but Sun had >> non-technical market advantages. Assuming that I am remembering >> correctly, I suspect it was unsuccessful commercially for two reasons: >> >> 1. Sun gave NFS (and the associated RPC layer) away for free, under a >> particularly liberal license, which lead to lots of interoperability >> (Larry's and Dave's comments notwithstanding). I suspect by the time >> RFS was available, it was much more expensive and less interoperable >> across heterogeneous systems. > > The NFS reference code was licensed under NDA with some cost involved > according to Rick Macklem who wrote the NFS code in 4.3BSD-Reno. > > Rick Macklem post to comp.protocols.nfs Aug 6, 1999 > https://groups.google.com/g/comp.protocols.nfs/c/npQbxPe_ZeQ/m/Z_yQcsh56mkJ > > The userland RPC part was under different terms. > > "Sun will publish the source code for the user-level libraries that > implement RPC and XDR." > > Bill Shannon post to net.unix-wizards Jan 13, 1985 > https://groups.google.com/g/net.unix-wizards/c/PkJdZgCbrC4/m/u0kt3eeFSt4J > > Sun RPC sources were later posted to mod.sources and included > on USENIX tapes. That's consistent with my memory. In particular, if I recall correctly, when I was still at IBM and we wanted to include NFS in AIX 3, it was challenging ($$$) to negotiate a satisfactory license for NFS, but we eventually obtained a license to include NFS in all IBM products (not just AIX). -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/LinkedIn/mas.to: CharlesHSauer From rich.salz at gmail.com Thu Aug 14 11:28:22 2025 From: rich.salz at gmail.com (Rich Salz) Date: Wed, 13 Aug 2025 21:28:22 -0400 Subject: [TUHS] NFS 40th anniversary event In-Reply-To: <72c3722a-1feb-4131-aebd-bf996e659bb3@technologists.com> References: <20250813015509.GA17097@mcvoy.com> <72c3722a-1feb-4131-aebd-bf996e659bb3@technologists.com> Message-ID: On 8/13/2025 7:31 PM, Jonathan Gray wrote: > > Sun RPC sources were later posted to mod.sources and included > > on USENIX tapes. > Volume 7 of mod.sources published Sun RPC code, https://www.tuhs.org/Usenet/mod.sources/1986-August/000016.html /r$, moderator thereof -------------- next part -------------- An HTML attachment was scrubbed... URL: From pugs78 at gmail.com Thu Aug 14 11:29:34 2025 From: pugs78 at gmail.com (Tom Lyon) Date: Wed, 13 Aug 2025 18:29:34 -0700 Subject: [TUHS] NFS 40th anniversary event In-Reply-To: <72c3722a-1feb-4131-aebd-bf996e659bb3@technologists.com> References: <20250813015509.GA17097@mcvoy.com> <72c3722a-1feb-4131-aebd-bf996e659bb3@technologists.com> Message-ID: Indeed, IBM had quite broad support for NFS. There's a whole chapter in this Redbook (1993) about OS/2 NFS clients working with AIX, MVS, VM, and OS/2 servers. https://ia801201.us.archive.org/11/items/gg243531/gg243531_TCPIP_2_0_for_OS2_Installation_and_Interoperability.pdf On Wed, Aug 13, 2025 at 5:54 PM Charles H. Sauer (he/him) < sauer at technologists.com> wrote: > On 8/13/2025 7:31 PM, Jonathan Gray wrote: > > On Wed, Aug 13, 2025 at 10:18:34AM -0400, Dan Cross wrote: > >> On Wed, Aug 13, 2025 at 10:00 AM Douglas McIlroy > >> wrote: > >>> I was always sorry that Peter Weinberger's RFS never made it outside > >>> Bell Labs. It allowed networking between separately administered > >>> systems by mapping UIDs. > >> > >> I believe it did? If I recall correctly, it was available with System > >> V, though perhaps I am misremembering. > >> > >> I have no doubt that RFS was technically superior to NFS, but Sun had > >> non-technical market advantages. Assuming that I am remembering > >> correctly, I suspect it was unsuccessful commercially for two reasons: > >> > >> 1. Sun gave NFS (and the associated RPC layer) away for free, under a > >> particularly liberal license, which lead to lots of interoperability > >> (Larry's and Dave's comments notwithstanding). I suspect by the time > >> RFS was available, it was much more expensive and less interoperable > >> across heterogeneous systems. > > > > The NFS reference code was licensed under NDA with some cost involved > > according to Rick Macklem who wrote the NFS code in 4.3BSD-Reno. > > > > Rick Macklem post to comp.protocols.nfs Aug 6, 1999 > > > https://groups.google.com/g/comp.protocols.nfs/c/npQbxPe_ZeQ/m/Z_yQcsh56mkJ > > > > The userland RPC part was under different terms. > > > > "Sun will publish the source code for the user-level libraries that > > implement RPC and XDR." > > > > Bill Shannon post to net.unix-wizards Jan 13, 1985 > > > https://groups.google.com/g/net.unix-wizards/c/PkJdZgCbrC4/m/u0kt3eeFSt4J > > > > Sun RPC sources were later posted to mod.sources and included > > on USENIX tapes. > > That's consistent with my memory. In particular, if I recall correctly, > when I was still at IBM and we wanted to include NFS in AIX 3, it was > challenging ($$$) to negotiate a satisfactory license for NFS, but we > eventually obtained a license to include NFS in all IBM products (not > just AIX). > -- > voice: +1.512.784.7526 e-mail: sauer at technologists.com > fax: +1.512.346.5240 Web: https://technologists.com/sauer/ > Facebook/Google/LinkedIn/mas.to > : > CharlesHSauer > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Thu Aug 14 11:41:33 2025 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Wed, 13 Aug 2025 18:41:33 -0700 Subject: [TUHS] NFS 40th anniversary event In-Reply-To: References: <20250813015509.GA17097@mcvoy.com> <20250813155648.GA25260@mcvoy.com> Message-ID: I viewed this last October. Seemed like a bunch of sensible ideas. Did you find any collaborators? [Not offering, just curious!] I see these "storage" categories: chunks, files, namespaces, metadata, databases & streams [1]. If you define a network protocol to handle critical operations on them all, implementations would likely follow. Engineers do better with well defined boundaries compared to "somewhere beyond there"! [1] probably could be simplified. > On Aug 13, 2025, at 9:43 AM, Tom Lyon wrote: > > BTW, my own opinions abut NFS can be seen in my "NFS Must Die!" talk here: https://www.youtube.com/watch?v=ZVF_djcccKc&ab_channel=TomLyon > > Not that NFS *was* bad - but it *is* bad (for non-casual use). > Like the C language, it was great for its time. Not so much anymore. > > > > On Wed, Aug 13, 2025 at 9:24 AM Peter Weinberger (温博格) via TUHS > wrote: >> It was a research proof-of-princple. (i.e.. partly principled and >> partly really hacky. My list of its issues was pretty long.) >> >> (If A mounted B's file system somewhere, and B mounted A's, then the >> directory tree was infinite. That's mathematics, not a bug.) >> >> On Wed, Aug 13, 2025 at 11:56 AM Larry McVoy > wrote: >> > >> > On Wed, Aug 13, 2025 at 10:18:34AM -0400, Dan Cross wrote: >> > > On Wed, Aug 13, 2025 at 10:00???AM Douglas McIlroy >> > > > wrote: >> > > > I was always sorry that Peter Weinberger's RFS never made it outside >> > > > Bell Labs. It allowed networking between separately administered >> > > > systems by mapping UIDs. >> > > >> > > I believe it did? If I recall correctly, it was available with System >> > > V, though perhaps I am misremembering. >> > >> > Sunos had it, my office mate ported it. I was unimpressed, it worked well >> > between the same archs but was riddled with byte order problems and >> > ioctl calls that were not portable. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pugs78 at gmail.com Thu Aug 14 12:04:32 2025 From: pugs78 at gmail.com (Tom Lyon) Date: Wed, 13 Aug 2025 19:04:32 -0700 Subject: [TUHS] NFS 40th anniversary event In-Reply-To: References: <20250813015509.GA17097@mcvoy.com> <20250813155648.GA25260@mcvoy.com> Message-ID: No collaborators. Not that I'm trying at all, the talk kinda got the urge out of my system. I therorize that many people could benefit - but no hard data. On Wed, Aug 13, 2025 at 6:41 PM Bakul Shah wrote: > I viewed this last October. Seemed like a bunch of sensible ideas. Did you > find any collaborators? [Not offering, just curious!] > > I see these "storage" categories: chunks, files, namespaces, metadata, > databases & streams [1]. If you define a network protocol to handle > critical operations on them all, implementations would likely follow. > Engineers do better with well defined boundaries compared to "somewhere > beyond there"! > > [1] probably could be simplified. > > On Aug 13, 2025, at 9:43 AM, Tom Lyon wrote: > > BTW, my own opinions abut NFS can be seen in my "NFS Must Die!" talk here: > https://www.youtube.com/watch?v=ZVF_djcccKc&ab_channel=TomLyon > > Not that NFS *was* bad - but it *is* bad (for non-casual use). > Like the C language, it was great for its time. Not so much anymore. > > > > On Wed, Aug 13, 2025 at 9:24 AM Peter Weinberger (温博格) via TUHS < > tuhs at tuhs.org> wrote: > >> It was a research proof-of-princple. (i.e.. partly principled and >> partly really hacky. My list of its issues was pretty long.) >> >> (If A mounted B's file system somewhere, and B mounted A's, then the >> directory tree was infinite. That's mathematics, not a bug.) >> >> On Wed, Aug 13, 2025 at 11:56 AM Larry McVoy wrote: >> > >> > On Wed, Aug 13, 2025 at 10:18:34AM -0400, Dan Cross wrote: >> > > On Wed, Aug 13, 2025 at 10:00???AM Douglas McIlroy >> > > wrote: >> > > > I was always sorry that Peter Weinberger's RFS never made it outside >> > > > Bell Labs. It allowed networking between separately administered >> > > > systems by mapping UIDs. >> > > >> > > I believe it did? If I recall correctly, it was available with System >> > > V, though perhaps I am misremembering. >> > >> > Sunos had it, my office mate ported it. I was unimpressed, it worked >> well >> > between the same archs but was riddled with byte order problems and >> > ioctl calls that were not portable. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Thu Aug 14 13:43:47 2025 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 13 Aug 2025 21:43:47 -0600 Subject: [TUHS] NFS 40th anniversary event In-Reply-To: References: <20250813015509.GA17097@mcvoy.com> <202508131459.57DExwjZ032177@freefriends.org> Message-ID: <202508140343.57E3hlEC075874@freefriends.org> Martin Schröder wrote: > Am Mi., 13. Aug. 2025 um 17:00 Uhr schrieb : > > It was a different RFS, developed by USG. It had full Unix semantics, > > including ioctls and fcntl, for machines of the same architecture. It > > was stateful, which meant if the server went away, you could hang your > > shell at the very least. It first came out in SVR3. > > Was that https://en.wikipedia.org/wiki/Remote_File_Sharing ? Yes. > If so, that article wants some love from an expert. I"m not enough of an expert to tackle it. I used RFS in a classroom setting for a few years, but that's it, and that was ~ 30 years ago. > And what became of it? It never caught on. Source for it can be found in SVR3 and SVR4, if you have those. Arnold From crossd at gmail.com Sat Aug 16 03:17:25 2025 From: crossd at gmail.com (Dan Cross) Date: Fri, 15 Aug 2025 13:17:25 -0400 Subject: [TUHS] C history question: why is signed integer overflow UB? Message-ID: [Note: A few folks Cc'ed directly] This is not exactly a Unix history question, but given the close relationship between C's development and that of Unix, perhaps it is both topical and someone may chime in with a definitive answer. Starting with the 1990 ANSI/ISO C standard, and continuing on to the present day, C has specified that signed integer overflow is "undefined behavior"; unsigned integer arithmetic is defined to be modular, and unsigned integer operations thus cannot meaningfully overflow, since they're always taken mod 2^b, where b is the number of bits in the datum (assuming unsigned int or larger, since type promotion of smaller things gets weird). But why is signed overflow UB? My belief has always been that signed integer overflow across various machines has non-deterministic behavior, in part because some machines would trap on overflow (e.g., Unisys 1100 series mainframes) while others used non-2's-complement representations for signed integers (again, the Unisys 1100 series, which used 1's complement), and so the results could not be precisely defined: even if it did not trap, overflowing a 1's complement machine yielded a different _value_ than on 2's complement. And around the time of initial standardization, targeting those machines was still an important use case. So while 2's complement with silent wrap-around was common, it could not be assumed, and once machines that generated traps on overflow were brought into the mix, it was safer to simply declare behavior on overflow undefined. But is that actually the case? Thanks in advance. - Dan C. From luther.johnson at makerlisp.com Sat Aug 16 03:31:58 2025 From: luther.johnson at makerlisp.com (Luther Johnson) Date: Fri, 15 Aug 2025 10:31:58 -0700 Subject: [TUHS] C history question: why is signed integer overflow UB? In-Reply-To: References: Message-ID: <664f1cf9-ae56-11a5-1e94-f58e0ca23565@makerlisp.com> My belief is that this was done so compilers could employ optimizations that did not have to consider or maintain implementation-specific behavior when integers would wrap. I don't agree with this, I think 2's complement behavior on integers as an implementation-specific behavior can be well-specified, and well-understood, machine by machine, but I think this is one of the places where compilers and benchmarks conspire to subvert the obvious and change the language to "language-legally" allow optimizations that can break the used-to-be-expected 2's complement implementation-specific behavior. I'm sure many people will disagree, but I think this is part of the slippery slope of modern C, and part of how it stopped being more usefully, directly, tied to the machine underneath. On 08/15/2025 10:17 AM, Dan Cross wrote: > [Note: A few folks Cc'ed directly] > > This is not exactly a Unix history question, but given the close > relationship between C's development and that of Unix, perhaps it is > both topical and someone may chime in with a definitive answer. > > Starting with the 1990 ANSI/ISO C standard, and continuing on to the > present day, C has specified that signed integer overflow is > "undefined behavior"; unsigned integer arithmetic is defined to be > modular, and unsigned integer operations thus cannot meaningfully > overflow, since they're always taken mod 2^b, where b is the number of > bits in the datum (assuming unsigned int or larger, since type > promotion of smaller things gets weird). > > But why is signed overflow UB? My belief has always been that signed > integer overflow across various machines has non-deterministic > behavior, in part because some machines would trap on overflow (e.g., > Unisys 1100 series mainframes) while others used non-2's-complement > representations for signed integers (again, the Unisys 1100 series, > which used 1's complement), and so the results could not be precisely > defined: even if it did not trap, overflowing a 1's complement machine > yielded a different _value_ than on 2's complement. And around the > time of initial standardization, targeting those machines was still an > important use case. So while 2's complement with silent wrap-around > was common, it could not be assumed, and once machines that generated > traps on overflow were brought into the mix, it was safer to simply > declare behavior on overflow undefined. > > But is that actually the case? > > Thanks in advance. > > - Dan C. > From luther.johnson at makerlisp.com Sat Aug 16 03:36:59 2025 From: luther.johnson at makerlisp.com (Luther Johnson) Date: Fri, 15 Aug 2025 10:36:59 -0700 Subject: [TUHS] C history question: why is signed integer overflow UB? In-Reply-To: <664f1cf9-ae56-11a5-1e94-f58e0ca23565@makerlisp.com> References: <664f1cf9-ae56-11a5-1e94-f58e0ca23565@makerlisp.com> Message-ID: <2e3d71c9-167e-b5d7-0d68-516248d91cf3@makerlisp.com> Or one's complement on those machines, but the idea was that this case is out of bounds, so you don't have to worry if munging some computation by substituting or rearranging expressions would change it, whatever the machine-specific behavior was. On 08/15/2025 10:31 AM, Luther Johnson wrote: > My belief is that this was done so compilers could employ > optimizations that did not have to consider or maintain > implementation-specific behavior when integers would wrap. I don't > agree with this, I think 2's complement behavior on integers as an > implementation-specific behavior can be well-specified, and > well-understood, machine by machine, but I think this is one of the > places where compilers and benchmarks conspire to subvert the obvious > and change the language to "language-legally" allow optimizations that > can break the used-to-be-expected 2's complement > implementation-specific behavior. > > I'm sure many people will disagree, but I think this is part of the > slippery slope of modern C, and part of how it stopped being more > usefully, directly, tied to the machine underneath. > > On 08/15/2025 10:17 AM, Dan Cross wrote: >> [Note: A few folks Cc'ed directly] >> >> This is not exactly a Unix history question, but given the close >> relationship between C's development and that of Unix, perhaps it is >> both topical and someone may chime in with a definitive answer. >> >> Starting with the 1990 ANSI/ISO C standard, and continuing on to the >> present day, C has specified that signed integer overflow is >> "undefined behavior"; unsigned integer arithmetic is defined to be >> modular, and unsigned integer operations thus cannot meaningfully >> overflow, since they're always taken mod 2^b, where b is the number of >> bits in the datum (assuming unsigned int or larger, since type >> promotion of smaller things gets weird). >> >> But why is signed overflow UB? My belief has always been that signed >> integer overflow across various machines has non-deterministic >> behavior, in part because some machines would trap on overflow (e.g., >> Unisys 1100 series mainframes) while others used non-2's-complement >> representations for signed integers (again, the Unisys 1100 series, >> which used 1's complement), and so the results could not be precisely >> defined: even if it did not trap, overflowing a 1's complement machine >> yielded a different _value_ than on 2's complement. And around the >> time of initial standardization, targeting those machines was still an >> important use case. So while 2's complement with silent wrap-around >> was common, it could not be assumed, and once machines that generated >> traps on overflow were brought into the mix, it was safer to simply >> declare behavior on overflow undefined. >> >> But is that actually the case? >> >> Thanks in advance. >> >> - Dan C. >> > From nevin at eviloverlord.com Sat Aug 16 04:02:26 2025 From: nevin at eviloverlord.com (Nevin Liber) Date: Fri, 15 Aug 2025 13:02:26 -0500 Subject: [TUHS] C history question: why is signed integer overflow UB? In-Reply-To: <664f1cf9-ae56-11a5-1e94-f58e0ca23565@makerlisp.com> References: <664f1cf9-ae56-11a5-1e94-f58e0ca23565@makerlisp.com> Message-ID: On Fri, Aug 15, 2025 at 12:32 PM Luther Johnson < luther.johnson at makerlisp.com> wrote: > My belief is that this was done so compilers could employ optimizations > that did not have to consider or maintain implementation-specific > behavior when integers would wrap. I don't agree with this, I think 2's > complement behavior on integers as an implementation-specific behavior > can be well-specified, and well-understood, machine by machine, but I > think this is one of the places where compilers and benchmarks conspire > to subvert the obvious and change the language to "language-legally" > allow optimizations that can break the used-to-be-expected 2's > complement implementation-specific behavior. > It isn't just about optimizations. Unsigned math in C is well defined here. The problem is that its wrapping behavior is almost (but not) always a bug. Because of that, for instance, one cannot write a no-false-positive sanitizer to catch this because it cannot tell the difference between an accidental bug and a deliberate use. This is a well-defined case with a very reasonable definition which most of the time leads to bugs. There are times folks want the wrapping behavior. There are times folks want saturating behavior. There are times folks want such code to error out. There are times folks want the optimizing behavior because their code doesn't go anywhere near wrapping. Ultimately, one needs different functions for the different behaviors, but if you only have one spelling for that operation, you can only get one behavior. A given type has to pick one of the above behaviors for a given spelling of an operation. You can, of course, disagree with what C picked here (many do), but it is unlikely to change in the future. Not that it hasn't been tried. In 2018 there was a proposal for C++ P0907R0 Signed Integers are Two's Complement , and if you look at the next revision of that paper P0907R1 , there was no consensus for the wrapping behavior. Quoting the paper: - Performance concerns, whereby defining the behavior prevents optimizers from assuming that overflow never occurs; - Implementation leeway for tools such as sanitizers; - Data from Google suggesting that over 90% of all overflow is a bug, and defining wrapping behavior would not have solved the bug. Fun fact: in C++ std::atomic does wrap, so you can actually get the behavior you want. I haven't looked to see if that is also true using C's _Atomic type qualifier. Full disclosure: I am on the WG21 (C++) Committee and am starting to participate on the WG14 (C) Committee. -- Nevin ":-)" Liber +1-847-691-1404 -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sat Aug 16 04:03:46 2025 From: imp at bsdimp.com (Warner Losh) Date: Fri, 15 Aug 2025 12:03:46 -0600 Subject: [TUHS] C history question: why is signed integer overflow UB? In-Reply-To: <2e3d71c9-167e-b5d7-0d68-516248d91cf3@makerlisp.com> References: <664f1cf9-ae56-11a5-1e94-f58e0ca23565@makerlisp.com> <2e3d71c9-167e-b5d7-0d68-516248d91cf3@makerlisp.com> Message-ID: I suspect that it was the absence of a signed right shift. In my Decsystem-20 OS class, one of the differences between the compiler on the VAX and the compiler on the '20 was that -1 >> 1 was -1 on the VAX and 2^35-1 on the '20. This was in 1985 or 1986 for a compiler that was written in 1982 or 83 (that no longer exists today, I'm told, other '20 compilers took over). Some signed overflows / underflow / traps were different as well, which only mattered in the '20 simulator we were running since all traps and interrupts reset the trap frame (whether you wanted to or not), so if you did it in the kernel interrupt, you'd double trap the machine (I think this was an intentional difference to teach about being careful in an interrupt context, but still...). It's the lack of uniformity for signed operations for machines generally available in the late 70s and early 80s (often based on designs dating back to the 60s) that I always assumed drove it... These details took up bits of three different lectures in the OS class, and was a big source of problems by everybody... So while my specific case was super weird / edge. But if it came up in an undergraduate OS class at an obscure technical school in the middle of the desert in New Mexico, I can't imagine that the design committee didn't know about it. Since the standardization started a few years before c89, I'm guessing that we'd see that if we had early drafts of the standard (or maybe it was inherited from K&R-era). Warner On Fri, Aug 15, 2025 at 11:37 AM Luther Johnson < luther.johnson at makerlisp.com> wrote: > Or one's complement on those machines, but the idea was that this case > is out of bounds, so you don't have to worry if munging some computation > by substituting or rearranging expressions would change it, whatever the > machine-specific behavior was. > > On 08/15/2025 10:31 AM, Luther Johnson wrote: > > My belief is that this was done so compilers could employ > > optimizations that did not have to consider or maintain > > implementation-specific behavior when integers would wrap. I don't > > agree with this, I think 2's complement behavior on integers as an > > implementation-specific behavior can be well-specified, and > > well-understood, machine by machine, but I think this is one of the > > places where compilers and benchmarks conspire to subvert the obvious > > and change the language to "language-legally" allow optimizations that > > can break the used-to-be-expected 2's complement > > implementation-specific behavior. > > > > I'm sure many people will disagree, but I think this is part of the > > slippery slope of modern C, and part of how it stopped being more > > usefully, directly, tied to the machine underneath. > > > > On 08/15/2025 10:17 AM, Dan Cross wrote: > >> [Note: A few folks Cc'ed directly] > >> > >> This is not exactly a Unix history question, but given the close > >> relationship between C's development and that of Unix, perhaps it is > >> both topical and someone may chime in with a definitive answer. > >> > >> Starting with the 1990 ANSI/ISO C standard, and continuing on to the > >> present day, C has specified that signed integer overflow is > >> "undefined behavior"; unsigned integer arithmetic is defined to be > >> modular, and unsigned integer operations thus cannot meaningfully > >> overflow, since they're always taken mod 2^b, where b is the number of > >> bits in the datum (assuming unsigned int or larger, since type > >> promotion of smaller things gets weird). > >> > >> But why is signed overflow UB? My belief has always been that signed > >> integer overflow across various machines has non-deterministic > >> behavior, in part because some machines would trap on overflow (e.g., > >> Unisys 1100 series mainframes) while others used non-2's-complement > >> representations for signed integers (again, the Unisys 1100 series, > >> which used 1's complement), and so the results could not be precisely > >> defined: even if it did not trap, overflowing a 1's complement machine > >> yielded a different _value_ than on 2's complement. And around the > >> time of initial standardization, targeting those machines was still an > >> important use case. So while 2's complement with silent wrap-around > >> was common, it could not be assumed, and once machines that generated > >> traps on overflow were brought into the mix, it was safer to simply > >> declare behavior on overflow undefined. > >> > >> But is that actually the case? > >> > >> Thanks in advance. > >> > >> - Dan C. > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From luther.johnson at makerlisp.com Sat Aug 16 04:25:32 2025 From: luther.johnson at makerlisp.com (Luther Johnson) Date: Fri, 15 Aug 2025 11:25:32 -0700 Subject: [TUHS] C history question: why is signed integer overflow UB? In-Reply-To: References: <664f1cf9-ae56-11a5-1e94-f58e0ca23565@makerlisp.com> Message-ID: I hear and understand what you're saying. I think what I'm trying to point out, is that in C, as it was originally implemented, in expressions "a + b", "a >> 1", "++a", C "does what the machine does". That's a very different thing from having rational, safe, predictable language semantics for operations on types - but it was also a strength, and a simple way to describe what C would do, deferring to machine semantics. I believe one place in C89/C90 where this is stated explicitly, as "do what the machine does", is "-1 >> 1", as opposed to "-1 / 2". On most machines, this program: #include int main() { printf("%d\n", -1 >> 1); printf("%d\n", -1 / 2); return 0; } returns: -1 0 directly reflecting the underlying machine shift and divide instructions - but if you made an appeal to rational integer type semantics, you might decide for it to do something else. Old C was one way. Modern C has gone another way, good tools and rational semantics for safer and/or higher performance code, or some balance between those and other goals. Old C just did what the machine did, and was a high leverage tool - but you had to understand your machine. On 08/15/2025 11:02 AM, Nevin Liber wrote: > On Fri, Aug 15, 2025 at 12:32 PM Luther Johnson > > > wrote: > > My belief is that this was done so compilers could employ > optimizations > that did not have to consider or maintain implementation-specific > behavior when integers would wrap. I don't agree with this, I > think 2's > complement behavior on integers as an implementation-specific > behavior > can be well-specified, and well-understood, machine by machine, but I > think this is one of the places where compilers and benchmarks > conspire > to subvert the obvious and change the language to "language-legally" > allow optimizations that can break the used-to-be-expected 2's > complement implementation-specific behavior. > > > It isn't just about optimizations. > > Unsigned math in C is well defined here. The problem is that its > wrapping behavior is almost (but not) always a bug. Because of that, > for instance, one cannot write a no-false-positive sanitizer to catch > this because it cannot tell the difference between an accidental bug > and a deliberate use. This is a well-defined case with a very > reasonable definition which most of the time leads to bugs. > > There are times folks want the wrapping behavior. There are times > folks want saturating behavior. There are times folks want such code > to error out. There are times folks want the optimizing behavior > because their code doesn't go anywhere near wrapping. > > Ultimately, one needs different functions for the different > behaviors, but if you only have one spelling for that operation, you > can only get one behavior. A given type has to pick one of the above > behaviors for a given spelling of an operation. > > You can, of course, disagree with what C picked here (many do), but it > is unlikely to change in the future. > > Not that it hasn't been tried. In 2018 there was a proposal for C++ > P0907R0 Signed Integers are Two's Complement > , and if you look at the next revision of > that paper P0907R1 , there was no consensus > for the wrapping behavior. Quoting the paper: > > * Performance concerns, whereby defining the behavior prevents > optimizers from assuming that overflow never occurs; > * Implementation leeway for tools such as sanitizers; > * Data from Google suggesting that over 90% of all overflow is a > bug, and defining wrapping behavior would not have solved the bug. > > Fun fact: in C++ std::atomic does wrap, so you can actually get > the behavior you want. I haven't looked to see if that is also true > using C's _Atomic type qualifier. > > Full disclosure: I am on the WG21 (C++) Committee and am starting to > participate on the WG14 (C) Committee. > -- > Nevin ":-)" Liber > +1-847-691-1404 -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnl at taugh.com Sat Aug 16 04:44:08 2025 From: johnl at taugh.com (John Levine) Date: 15 Aug 2025 14:44:08 -0400 Subject: [TUHS] C history question: why is signed integer overflow UB? In-Reply-To: References: <664f1cf9-ae56-11a5-1e94-f58e0ca23565@makerlisp.com> Message-ID: <20250815184408.E438DD7D00B1@ary.qy> It appears that Luther Johnson said: >-=-=-=-=-=- > >I hear and understand what you're saying. I think what I'm trying to >point out, is that in C, as it was originally implemented, in >expressions "a + b", "a >> 1", "++a", C "does what the machine does". We just had the same argument in comp.arch and came to largely the same conclusion. While overflow behavior on any particular machine may be predictable, there's no consistency from one machine to another, particularly back when there were still one's complement machines where people compiled C code (some of the Univac mainframes.) It isn't all that predictable even on a single machine. I know several where overflow might or might not trap depending on a program-settable status bit. R's, John From douglas.mcilroy at dartmouth.edu Sat Aug 16 07:04:09 2025 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Fri, 15 Aug 2025 17:04:09 -0400 Subject: [TUHS] C history question: why is signed integer overflow UB? In-Reply-To: <20250815184408.E438DD7D00B1@ary.qy> References: <664f1cf9-ae56-11a5-1e94-f58e0ca23565@makerlisp.com> <20250815184408.E438DD7D00B1@ary.qy> Message-ID: Idle thought; There's been mention of 1's complement. If overflow is UB because of that possibility, maybe ==0 should be, too! Doug On Fri, Aug 15, 2025 at 2:44 PM John Levine wrote: > > It appears that Luther Johnson said: > >-=-=-=-=-=- > > > >I hear and understand what you're saying. I think what I'm trying to > >point out, is that in C, as it was originally implemented, in > >expressions "a + b", "a >> 1", "++a", C "does what the machine does". > > We just had the same argument in comp.arch and came to largely the same > conclusion. While overflow behavior on any particular machine may be > predictable, there's no consistency from one machine to another, > particularly back when there were still one's complement machines > where people compiled C code (some of the Univac mainframes.) > > It isn't all that predictable even on a single machine. I know several > where overflow might or might not trap depending on a program-settable > status bit. > > R's, > John From dave at horsfall.org Sat Aug 16 07:59:46 2025 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 16 Aug 2025 07:59:46 +1000 (EST) Subject: [TUHS] C history question: why is signed integer overflow UB? In-Reply-To: References: <664f1cf9-ae56-11a5-1e94-f58e0ca23565@makerlisp.com> <20250815184408.E438DD7D00B1@ary.qy> Message-ID: On Fri, 15 Aug 2025, Douglas McIlroy wrote: > Idle thought; There's been mention of 1's complement. If overflow is UB > because of that possibility, maybe ==0 should be, too! I understand that with ones-complement machines (such as the CDC series), a computation resulting in -0 will be normalised to 0 (but a bit inversion won't). -- Dave From rminnich at gmail.com Sat Aug 16 08:28:13 2025 From: rminnich at gmail.com (ron minnich) Date: Fri, 15 Aug 2025 15:28:13 -0700 Subject: [TUHS] pseudo tty history Message-ID: so the question of pseudo tty came up today. My memory is that it started with TOPS-10, though I doubt I know enough. Vague memory says there was a PTY: device. Further, I believe pty came in from UCB ca 1977 or so? I'm wondering if people who were Present at the Creation can fill in the gaps. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sat Aug 16 08:33:24 2025 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Fri, 15 Aug 2025 15:33:24 -0700 Subject: [TUHS] pseudo tty history In-Reply-To: References: Message-ID: From https://en.wikipedia.org/wiki/Pseudoterminal Pseudoterminals were present in the DEC PDP-6 Timesharing Monitor at least as early as 1967, and were used to implement batch processing. They are described in the documentation for the succeeding TOPS-10 on the PDP-10 .[6] Other DEC operating systems also had PTYs, including RSTS/E for the PDP-11 , as did the third-party TENEX operating system for the PDP-10. Implementations of Unix pseudo terminals date back to the modifications that RAND and BBN made to a 6th Edition in the late 1970s to support remote access over a network.[7] Modern Unix pseudoterminals originated in 1983 during the development of Eighth Edition Unix and were based on a similar feature in TENEX.[8] They were part of the 4.3BSD-Reno , with a rather cumbersome openpty() interface defined for use.[9] [In absence of a more authoritative source] > On Aug 15, 2025, at 3:28 PM, ron minnich wrote: > > so the question of pseudo tty came up today. > > My memory is that it started with TOPS-10, though I doubt I know enough. Vague memory says there was a PTY: device. > > Further, I believe pty came in from UCB ca 1977 or so? > > I'm wondering if people who were Present at the Creation can fill in the gaps. > > Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Sat Aug 16 08:56:12 2025 From: ron at ronnatalie.com (Ron Natalie) Date: Fri, 15 Aug 2025 22:56:12 +0000 Subject: [TUHS] pseudo tty history In-Reply-To: References: Message-ID: I think that wikipedia history is somewhat garbled when it comes to the UNIX implementations. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Sat Aug 16 09:00:10 2025 From: rminnich at gmail.com (ron minnich) Date: Fri, 15 Aug 2025 16:00:10 -0700 Subject: [TUHS] pseudo tty history In-Reply-To: References: Message-ID: That was my guess. I figured the people who did the work are on this list, and primary sources rule. On Fri, Aug 15, 2025 at 3:56 PM Ron Natalie wrote: > I think that wikipedia history is somewhat garbled when it comes to the > UNIX implementations. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sat Aug 16 09:15:15 2025 From: imp at bsdimp.com (Warner Losh) Date: Fri, 15 Aug 2025 17:15:15 -0600 Subject: [TUHS] pseudo tty history In-Reply-To: References: Message-ID: At the very least, 4.2BSD had them for telnet and rlogin. They were static, though. You had to MAKEDEV enough units. Warner On Fri, Aug 15, 2025, 5:00 PM ron minnich wrote: > That was my guess. I figured the people who did the work are on this list, > and primary sources rule. > > On Fri, Aug 15, 2025 at 3:56 PM Ron Natalie wrote: > >> I think that wikipedia history is somewhat garbled when it comes to the >> UNIX implementations. >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From pugs78 at gmail.com Sat Aug 16 09:19:38 2025 From: pugs78 at gmail.com (Tom Lyon) Date: Fri, 15 Aug 2025 16:19:38 -0700 Subject: [TUHS] pseudo tty history In-Reply-To: References: Message-ID: Yeah, I was thinking that 4.1c BSD must've had them for rlogin and telnet. Which got me looking for Fabry and Bill Joy's design/planning documents for 4.2, which are not in the TUHS archives. Anyone got them?? On Fri, Aug 15, 2025 at 4:15 PM Warner Losh wrote: > At the very least, 4.2BSD had them for telnet and rlogin. They were > static, though. You had to MAKEDEV enough units. > > Warner > > On Fri, Aug 15, 2025, 5:00 PM ron minnich wrote: > >> That was my guess. I figured the people who did the work are on this >> list, and primary sources rule. >> >> On Fri, Aug 15, 2025 at 3:56 PM Ron Natalie wrote: >> >>> I think that wikipedia history is somewhat garbled when it comes to the >>> UNIX implementations. >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From luther.johnson at makerlisp.com Sat Aug 16 09:58:36 2025 From: luther.johnson at makerlisp.com (Luther Johnson) Date: Fri, 15 Aug 2025 16:58:36 -0700 Subject: [TUHS] C history question: why is signed integer overflow UB? In-Reply-To: References: <664f1cf9-ae56-11a5-1e94-f58e0ca23565@makerlisp.com> <20250815184408.E438DD7D00B1@ary.qy> Message-ID: Relating this all to a Godel-ish classification of axiomatic systems, language definitions with undefined behavior may be perfectly consistent, but there is useful behavior that cannot be expressed in those languages, while languages with no undefined behavior but with lots of implementation-specific behavior can express much more, but with less consistency. On 08/15/2025 02:04 PM, Douglas McIlroy wrote: > Idle thought; There's been mention of 1's complement. If overflow is > UB because of that possibility, maybe ==0 should be, too! > > Doug > > On Fri, Aug 15, 2025 at 2:44 PM John Levine wrote: >> It appears that Luther Johnson said: >>> -=-=-=-=-=- >>> >>> I hear and understand what you're saying. I think what I'm trying to >>> point out, is that in C, as it was originally implemented, in >>> expressions "a + b", "a >> 1", "++a", C "does what the machine does". >> We just had the same argument in comp.arch and came to largely the same >> conclusion. While overflow behavior on any particular machine may be >> predictable, there's no consistency from one machine to another, >> particularly back when there were still one's complement machines >> where people compiled C code (some of the Univac mainframes.) >> >> It isn't all that predictable even on a single machine. I know several >> where overflow might or might not trap depending on a program-settable >> status bit. >> >> R's, >> John From jsg at jsg.id.au Sat Aug 16 10:53:42 2025 From: jsg at jsg.id.au (Jonathan Gray) Date: Sat, 16 Aug 2025 10:53:42 +1000 Subject: [TUHS] pseudo tty history In-Reply-To: References: Message-ID: On Fri, Aug 15, 2025 at 04:19:38PM -0700, Tom Lyon wrote: > Yeah, I was thinking that 4.1c BSD must've had them for rlogin and telnet. > > Which got me looking for Fabry and Bill Joy's design/planning documents for > 4.2, which are not in the TUHS archives. > Anyone got them?? Rich Morin scanned CSRG TR 3 & 4 https://www.tuhs.org/pipermail/tuhs/2020-January/020006.html https://www.tuhs.org/pipermail/tuhs/2020-January/020033.html The versions I have are from there, but the cfcl.com links no longer work. Warren uploaded them to the Internet Archive: CSRG TR 3 William Joy, Robert Fabry An Architecture for Interprocess Communication in UNIX DRAFT of June 22, 1981 https://archive.org/details/csrgtr3 CSRG TR 4 William Joy, Robert Fabry Proposals for enhancement of UNIX on the VAX July 21, 1981, Revised August 31, 1981 https://archive.org/details/csrgtr4 From reed at reedmedia.net Sat Aug 16 11:19:18 2025 From: reed at reedmedia.net (Jeremy C. Reed) Date: Sat, 16 Aug 2025 01:19:18 +0000 (UTC) Subject: [TUHS] pseudo tty history In-Reply-To: References: Message-ID: <4fa8dc2e-1698-4d97-dc18-f02f1ccf2e72@reedmedia.net> "In January 1981, Toy worked on adding the pseudo-teletype (ptty) drivers that were overhauled and ported to VMUNIX by Borden in July 1980. (This ptty code came from Borden's earlier Harvard work.)" (Borden told me it came from his Harvard work.) SCCS also shows ../archives/1980s/4.1c.1/sys/sys/SCCS/s.tty_pty.c- * Overhauled, and ported to VAX/VMUNIX (V7) Bruce Borden, July 80 ../archives/1980s/4.1c.1/sys/sys/SCCS/s.tty_pty.c: * Modified and integrated into 4bsd by Kipp Hickman and Michael Toy Several commits around there for toy echo Fbzrqnl V jvyy svavfu zl obbx. | \ tr "VFnoqrsuvxyzabfjl" "ISabdefhiklmnoswy" From rminnich at gmail.com Sat Aug 16 11:49:16 2025 From: rminnich at gmail.com (ron minnich) Date: Fri, 15 Aug 2025 18:49:16 -0700 Subject: [TUHS] pseudo tty history In-Reply-To: References: Message-ID: was there ever a telnet or other remote access program that predated ptys on Unix? Was telnet the driving force for ptys? Did the folks implementing Unix networking bring in ptys before, or as part of, or after networking, i.e. did folks building networking for Unix realize they needed ptys once they started working on telnet, or did they plan for ptys from the get go? I was an observer for some of this stuff, but as a 20-year-old at UDEL I was also quite out of the loop. I also realize there were multiple Unix networking efforts, so this question is somewhat simplistic. I'm assuming rsh came a bit later. On Fri, Aug 15, 2025 at 4:19 PM Tom Lyon wrote: > Yeah, I was thinking that 4.1c BSD must've had them for rlogin and telnet. > > Which got me looking for Fabry and Bill Joy's design/planning documents > for 4.2, which are not in the TUHS archives. > Anyone got them?? > > On Fri, Aug 15, 2025 at 4:15 PM Warner Losh wrote: > >> At the very least, 4.2BSD had them for telnet and rlogin. They were >> static, though. You had to MAKEDEV enough units. >> >> Warner >> >> On Fri, Aug 15, 2025, 5:00 PM ron minnich wrote: >> >>> That was my guess. I figured the people who did the work are on this >>> list, and primary sources rule. >>> >>> On Fri, Aug 15, 2025 at 3:56 PM Ron Natalie wrote: >>> >>>> I think that wikipedia history is somewhat garbled when it comes to the >>>> UNIX implementations. >>>> >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Sat Aug 16 12:48:46 2025 From: ron at ronnatalie.com (Ron Natalie) Date: Sat, 16 Aug 2025 02:48:46 +0000 Subject: [TUHS] pseudo tty history In-Reply-To: References: Message-ID: We had virtual links that just used clever use of pipes around the shell. It was clunky. Even in the NTP (pre-internet Arpanet) days we had ptys. ------ Original Message ------ >From "ron minnich" To "Tom Lyon" Cc "Bakul Shah" ; "The Eunuchs Hysterical Society" Date 8/15/2025 9:49:16 PM Subject [TUHS] Re: pseudo tty history >was there ever a telnet or other remote access program that predated >ptys on Unix? Was telnet the driving force for ptys? Did the folks >implementing Unix networking bring in ptys before, or as part of, or >after networking, i.e. did folks building networking for Unix realize >they needed ptys once they started working on telnet, or did they plan >for ptys from the get go? I was an observer for some of this stuff, but >as a 20-year-old at UDEL I was also quite out of the loop. > > I also realize there were multiple Unix networking efforts, so this >question is somewhat simplistic. > >I'm assuming rsh came a bit later. > >On Fri, Aug 15, 2025 at 4:19 PM Tom Lyon wrote: >>Yeah, I was thinking that 4.1c BSD must've had them for rlogin and >>telnet. >> >>Which got me looking for Fabry and Bill Joy's design/planning >>documents for 4.2, which are not in the TUHS archives. >>Anyone got them?? >> >>On Fri, Aug 15, 2025 at 4:15 PM Warner Losh wrote: >>>At the very least, 4.2BSD had them for telnet and rlogin. They were >>>static, though. You had to MAKEDEV enough units. >>> >>>Warner >>> >>>On Fri, Aug 15, 2025, 5:00 PM ron minnich wrote: >>>>That was my guess. I figured the people who did the work are on this >>>>list, and primary sources rule. >>>> >>>>On Fri, Aug 15, 2025 at 3:56 PM Ron Natalie >>>>wrote: >>>>>I think that wikipedia history is somewhat garbled when it comes to >>>>>the UNIX implementations. >>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Aug 16 13:19:56 2025 From: clemc at ccc.com (Clem Cole) Date: Fri, 15 Aug 2025 20:19:56 -0700 Subject: [TUHS] pseudo tty history In-Reply-To: References: Message-ID: Boy, that's an understatement. As best I can tell, the Rand UNIX( ??Bruce Borden??) had them first, then they were in the UofI NCP (Steve Holmgren) and migrated to several places like MIT's ChaosNet, long before the BSD implementation. BSD got them from the BBN TCP, which I think came from MIT's flavor. Still, it might have been from any of the other versions that were around at the time - I must have had a couple of different versions in different kernel sources for different V6 kernel hacks in those days, and I did not write any of them. If you look at the old USENIX tapes, you will likely see a couple of versions. Clem On Fri, Aug 15, 2025 at 3:56 PM Ron Natalie wrote: > I think that wikipedia history is somewhat garbled when it comes to the > UNIX implementations. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Aug 16 13:20:27 2025 From: clemc at ccc.com (Clem Cole) Date: Fri, 15 Aug 2025 20:20:27 -0700 Subject: [TUHS] pseudo tty history In-Reply-To: References: Message-ID: That version came from the BBN code. On Fri, Aug 15, 2025 at 4:19 PM Tom Lyon wrote: > Yeah, I was thinking that 4.1c BSD must've had them for rlogin and telnet. > > Which got me looking for Fabry and Bill Joy's design/planning documents > for 4.2, which are not in the TUHS archives. > Anyone got them?? > > On Fri, Aug 15, 2025 at 4:15 PM Warner Losh wrote: > >> At the very least, 4.2BSD had them for telnet and rlogin. They were >> static, though. You had to MAKEDEV enough units. >> >> Warner >> >> On Fri, Aug 15, 2025, 5:00 PM ron minnich wrote: >> >>> That was my guess. I figured the people who did the work are on this >>> list, and primary sources rule. >>> >>> On Fri, Aug 15, 2025 at 3:56 PM Ron Natalie wrote: >>> >>>> I think that wikipedia history is somewhat garbled when it comes to the >>>> UNIX implementations. >>>> >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sat Aug 16 13:23:58 2025 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Fri, 15 Aug 2025 20:23:58 -0700 Subject: [TUHS] pseudo tty history In-Reply-To: References: Message-ID: <048C84A7-E178-4B5D-844A-17CF999CC282@iitbombay.org> From RFC 89 (dated 19 January 1971) titled "Some historic moments in networking": Second, the Harvard system has temporarily implemented this remote network console interface feature using a DEC style pseudo-teletype (PTY). From RFC 46 (dated April 1970) titled "'ARPA Network Protocol Notes": 3. A standard way for a newly created process to initiate pseudo- typewriter communication with the foreign process which requested its creation. > On Aug 15, 2025, at 6:49 PM, ron minnich wrote: > > was there ever a telnet or other remote access program that predated ptys on Unix? Was telnet the driving force for ptys? Did the folks implementing Unix networking bring in ptys before, or as part of, or after networking, i.e. did folks building networking for Unix realize they needed ptys once they started working on telnet, or did they plan for ptys from the get go? I was an observer for some of this stuff, but as a 20-year-old at UDEL I was also quite out of the loop. > > I also realize there were multiple Unix networking efforts, so this question is somewhat simplistic. > > I'm assuming rsh came a bit later. > > On Fri, Aug 15, 2025 at 4:19 PM Tom Lyon > wrote: >> Yeah, I was thinking that 4.1c BSD must've had them for rlogin and telnet. >> >> Which got me looking for Fabry and Bill Joy's design/planning documents for 4.2, which are not in the TUHS archives. >> Anyone got them?? >> >> On Fri, Aug 15, 2025 at 4:15 PM Warner Losh > wrote: >>> At the very least, 4.2BSD had them for telnet and rlogin. They were static, though. You had to MAKEDEV enough units. >>> >>> Warner >>> >>> On Fri, Aug 15, 2025, 5:00 PM ron minnich > wrote: >>>> That was my guess. I figured the people who did the work are on this list, and primary sources rule. >>>> >>>> On Fri, Aug 15, 2025 at 3:56 PM Ron Natalie > wrote: >>>>> I think that wikipedia history is somewhat garbled when it comes to the UNIX implementations. >>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Aug 16 13:35:01 2025 From: clemc at ccc.com (Clem Cole) Date: Fri, 15 Aug 2025 20:35:01 -0700 Subject: [TUHS] pseudo tty history In-Reply-To: <048C84A7-E178-4B5D-844A-17CF999CC282@iitbombay.org> References: <048C84A7-E178-4B5D-844A-17CF999CC282@iitbombay.org> Message-ID: Watch the dates - that's not UNIX. In 1973, Version 4 Unix is first released outside of BTL, so the Harvard system being talked about in RFC 89 is probably an 18 bit ??PDP6 maybe??. On Fri, Aug 15, 2025 at 8:24 PM Bakul Shah via TUHS wrote: > From RFC 89 (dated 19 January 1971) titled "Some historic moments in > networking": > > Second, the Harvard system has temporarily implemented this remote > network console interface feature using a DEC style pseudo-teletype > (PTY). > > From RFC 46 (dated April 1970) titled "'ARPA Network Protocol Notes": > > 3. A standard way for a newly created process to initiate pseudo- > typewriter communication with the foreign process which requested > its creation. > > > On Aug 15, 2025, at 6:49 PM, ron minnich wrote: > > was there ever a telnet or other remote access program that predated ptys > on Unix? Was telnet the driving force for ptys? Did the folks implementing > Unix networking bring in ptys before, or as part of, or after networking, > i.e. did folks building networking for Unix realize they needed ptys once > they started working on telnet, or did they plan for ptys from the get go? > I was an observer for some of this stuff, but as a 20-year-old at UDEL I > was also quite out of the loop. > > I also realize there were multiple Unix networking efforts, so this > question is somewhat simplistic. > > I'm assuming rsh came a bit later. > > On Fri, Aug 15, 2025 at 4:19 PM Tom Lyon wrote: > >> Yeah, I was thinking that 4.1c BSD must've had them for rlogin and telnet. >> >> Which got me looking for Fabry and Bill Joy's design/planning documents >> for 4.2, which are not in the TUHS archives. >> Anyone got them?? >> >> On Fri, Aug 15, 2025 at 4:15 PM Warner Losh wrote: >> >>> At the very least, 4.2BSD had them for telnet and rlogin. They were >>> static, though. You had to MAKEDEV enough units. >>> >>> Warner >>> >>> On Fri, Aug 15, 2025, 5:00 PM ron minnich wrote: >>> >>>> That was my guess. I figured the people who did the work are on this >>>> list, and primary sources rule. >>>> >>>> On Fri, Aug 15, 2025 at 3:56 PM Ron Natalie wrote: >>>> >>>>> I think that wikipedia history is somewhat garbled when it comes to >>>>> the UNIX implementations. >>>>> >>>>> >>>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aki at insinga.com Sat Aug 16 13:50:26 2025 From: aki at insinga.com (Aron Insinga) Date: Fri, 15 Aug 2025 23:50:26 -0400 Subject: [TUHS] pseudo tty history In-Reply-To: References: <048C84A7-E178-4B5D-844A-17CF999CC282@iitbombay.org> Message-ID: The https://datatracker.ietf.org/doc/html/rfc89 mentions a PDP-6 and PDP-10s which are 36-bit twos complement machines, and a DEC PDP-1 which was an 18-bit one's complement  machine.  The "graphics-oriented" PDP-1 probably had the well-known Type 30 display which used a large round radar-type CRT thanks to the Project SAGE tradition, but there were a couple of other graphics display options for the PDP-1. https://www.computerhistory.org/pdp-1/graphics/ - Aron On 8/15/25 23:35, Clem Cole wrote: > Watch the dates - that's not UNIX.  In 1973, Version 4 Unix is first > released outside of BTL, so the Harvard system being talked about in > RFC 89 is probably an 18 bit ??PDP6 maybe??. > > On Fri, Aug 15, 2025 at 8:24 PM Bakul Shah via TUHS wrote: > > From RFC 89 (dated 19 January 1971) titled "Some historic moments > in networking": > >    Second, the Harvard system has temporarily implemented this remote >    network console interface feature using a DEC style pseudo-teletype >    (PTY). > > From RFC 46 (dated April 1970) titled "'ARPA Network Protocol Notes": > >    3. A standard way for a newly created process to initiate pseudo- >       typewriter communication with the foreign process which > requested >       its creation. > > >> On Aug 15, 2025, at 6:49 PM, ron minnich wrote: >> >> was there ever a telnet or other remote access program that >> predated ptys on Unix? Was telnet the driving force for ptys? Did >> the folks implementing Unix networking bring in ptys before, or >> as part of, or after networking, i.e. did folks building >> networking for Unix realize they needed ptys once they started >> working on telnet, or did they plan for ptys from the get go? I >> was an observer for some of this stuff, but as a 20-year-old at >> UDEL I was also quite out of the loop. >> >>  I also realize there were multiple Unix networking efforts, so >> this question is somewhat simplistic. >> >> I'm assuming rsh came a bit later. >> >> On Fri, Aug 15, 2025 at 4:19 PM Tom Lyon wrote: >> >> Yeah, I was thinking that 4.1c BSD must've had them for >> rlogin and telnet. >> >> Which got me looking for Fabry and Bill Joy's design/planning >> documents for 4.2, which are not in the TUHS archives. >> Anyone got them?? >> >> On Fri, Aug 15, 2025 at 4:15 PM Warner Losh >> wrote: >> >> At the very least, 4.2BSD had them for telnet and rlogin. >> They were static, though. You had to MAKEDEV enough units. >> >> Warner >> >> On Fri, Aug 15, 2025, 5:00 PM ron minnich >> wrote: >> >> That was my guess. I figured the people who did the >> work are on this list, and primary sources rule. >> >> On Fri, Aug 15, 2025 at 3:56 PM Ron Natalie >> wrote: >> >> I think that wikipedia history is somewhat >> garbled when it comes to the UNIX implementations. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Sat Aug 16 16:01:40 2025 From: lars at nocrew.org (Lars Brinkhoff) Date: Sat, 16 Aug 2025 06:01:40 +0000 Subject: [TUHS] C history question: why is signed integer overflow UB? In-Reply-To: (Warner Losh's message of "Fri, 15 Aug 2025 12:03:46 -0600") References: <664f1cf9-ae56-11a5-1e94-f58e0ca23565@makerlisp.com> <2e3d71c9-167e-b5d7-0d68-516248d91cf3@makerlisp.com> Message-ID: <7wjz33vm7v.fsf@junk.nocrew.org> Warner Losh writes: > I suspect that it was the absence of a signed right shift. In my > Decsystem-20 OS class, one of the differences between the compiler on > the VAX and the compiler on the '20 was that -1 >> 1 was -1 on the VAX > and 2^35-1 on the '20. The DEC-20 (aka PDP-10) does have a signed right shift instruction. Apparently the compiler didn't use it. From clemc at ccc.com Sun Aug 17 00:57:18 2025 From: clemc at ccc.com (Clem Cole) Date: Sat, 16 Aug 2025 07:57:18 -0700 Subject: [TUHS] pseudo tty history In-Reply-To: References: <048C84A7-E178-4B5D-844A-17CF999CC282@iitbombay.org> Message-ID: Right. What I do not know is what early machines Harvard had from DEC. MIT had the 18 and 36 bit series which was what I was implying. The key point though is that if Harvard was the root of the PTY tree it would have been on one of those systems not a Unix system because Unix did not come to Harvard until 1974 and RFC 89 was 1971 and RFC 46 in 1970 Sent from a handheld expect more typos than usual On Fri, Aug 15, 2025 at 8:50 PM Aron Insinga wrote: > The https://datatracker.ietf.org/doc/html/rfc89 mentions a PDP-6 and > PDP-10s which are 36-bit twos complement machines, and a DEC PDP-1 which > was an 18-bit one's complement machine. The "graphics-oriented" PDP-1 > probably had the well-known Type 30 display which used a large round > radar-type CRT thanks to the Project SAGE tradition, but there were a > couple of other graphics display options for the PDP-1. > https://www.computerhistory.org/pdp-1/graphics/ > > > - Aron > > > On 8/15/25 23:35, Clem Cole wrote: > > Watch the dates - that's not UNIX. In 1973, Version 4 Unix is first > released outside of BTL, so the Harvard system being talked about in RFC 89 > is probably an 18 bit ??PDP6 maybe??. > > On Fri, Aug 15, 2025 at 8:24 PM Bakul Shah via TUHS wrote: > >> From RFC 89 (dated 19 January 1971) titled "Some historic moments in >> networking": >> >> Second, the Harvard system has temporarily implemented this remote >> network console interface feature using a DEC style pseudo-teletype >> (PTY). >> >> From RFC 46 (dated April 1970) titled "'ARPA Network Protocol Notes": >> >> 3. A standard way for a newly created process to initiate pseudo- >> typewriter communication with the foreign process which requested >> its creation. >> >> >> On Aug 15, 2025, at 6:49 PM, ron minnich wrote: >> >> was there ever a telnet or other remote access program that predated ptys >> on Unix? Was telnet the driving force for ptys? Did the folks implementing >> Unix networking bring in ptys before, or as part of, or after networking, >> i.e. did folks building networking for Unix realize they needed ptys once >> they started working on telnet, or did they plan for ptys from the get go? >> I was an observer for some of this stuff, but as a 20-year-old at UDEL I >> was also quite out of the loop. >> >> I also realize there were multiple Unix networking efforts, so this >> question is somewhat simplistic. >> >> I'm assuming rsh came a bit later. >> >> On Fri, Aug 15, 2025 at 4:19 PM Tom Lyon wrote: >> >>> Yeah, I was thinking that 4.1c BSD must've had them for rlogin and >>> telnet. >>> >>> Which got me looking for Fabry and Bill Joy's design/planning documents >>> for 4.2, which are not in the TUHS archives. >>> Anyone got them?? >>> >>> On Fri, Aug 15, 2025 at 4:15 PM Warner Losh wrote: >>> >>>> At the very least, 4.2BSD had them for telnet and rlogin. They were >>>> static, though. You had to MAKEDEV enough units. >>>> >>>> Warner >>>> >>>> On Fri, Aug 15, 2025, 5:00 PM ron minnich wrote: >>>> >>>>> That was my guess. I figured the people who did the work are on this >>>>> list, and primary sources rule. >>>>> >>>>> On Fri, Aug 15, 2025 at 3:56 PM Ron Natalie >>>>> wrote: >>>>> >>>>>> I think that wikipedia history is somewhat garbled when it comes to >>>>>> the UNIX implementations. >>>>>> >>>>>> >>>>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aki at insinga.com Sun Aug 17 10:21:30 2025 From: aki at insinga.com (Aron Insinga) Date: Sat, 16 Aug 2025 20:21:30 -0400 Subject: [TUHS] pseudo tty history In-Reply-To: References: <048C84A7-E178-4B5D-844A-17CF999CC282@iitbombay.org> Message-ID: <3fefdce7-102b-4728-84bc-b2959b224600@insinga.com> The RFC refers to "the Harvard PDP-10 System" and "Harvard's PDP-1" in the first paragraph, and the "MITDG PDP-6/10" (so that's 2 machines but eventually MIT had a gaggle of PDP-10s) in the second paragraph.  And  of course MIT had a PDP-1, where Spacewar was developed and first played.  I don't know the arrival/exit dates of the machines. Here are some dates, but I don't know if they are just samples based on the earliest DECUS submission from there, or installation dates. The Harvard museum (which has pieces of the Mark I) may know more about when different machines were installed and removed. http://www.bitsavers.org/pdf/dec/pdp1/PDP-1_SerialNumbers.txt > Sites known to have PDP-1's based on DECUS submissions: > ... > Harvard University                     Dec 64 > ... > MIT Lincoln Laboratory Group 22        May 65 > MIT Laboratory For Nuclear Science     Apr 65 > MIT Project MAC                        Jul 64 > MIT RLE                                Sep 65 By serial number: > 05  PDP-1C  MIT (RLE) > 26  PDP-1C  MIT > 37  PDP-1C  MIT Lincoln Labs                11/65 > 40  PDP-1C  MIT (MAC)                        64(?) > 41  PDP-1C  Harvard > 53  PDP-1   MIT Side note: I saw the MIT PDP-6 with its chess trophies on top of it during the Blizzard of '78.  (After I interviewed at DEC, I made my way from Marlborough through the rapidly-intensifying snow to Cambridge to visit someone from High School.  I ended up crashing on a dorm sofa from the day the blizzard hit until the airport in Boston reopened which was about a week.)  The PDP-6 had a sign on it that said something like "This machine is old and flaky so don't touch it unless you know what you are doing." - Aron On 8/16/25 10:57, Clem Cole wrote: > Right.  What I do not know is what early machines Harvard had from > DEC.  MIT had the 18 and 36 bit series which was what I was implying.  > The key point though is that if Harvard was the root of the PTY tree > it would have been on one of those systems not a Unix system because > Unix did not come to Harvard until 1974 and RFC 89 was 1971 and RFC 46 > in 1970 > > Sent from a handheld expect more typos than usual > > > On Fri, Aug 15, 2025 at 8:50 PM Aron Insinga wrote: > > The https://datatracker.ietf.org/doc/html/rfc89 mentions a PDP-6 > and PDP-10s which are 36-bit twos complement machines, and a DEC > PDP-1 which was an 18-bit one's complement  machine.  The > "graphics-oriented" PDP-1 probably had the well-known Type 30 > display which used a large round radar-type CRT thanks to the > Project SAGE tradition, but there were a couple of other graphics > display options for the PDP-1. > https://www.computerhistory.org/pdp-1/graphics/ > > > - Aron > > > On 8/15/25 23:35, Clem Cole wrote: >> Watch the dates - that's not UNIX.  In 1973, Version 4 Unix is >> first released outside of BTL, so the Harvard system being talked >> about in RFC 89 is probably an 18 bit ??PDP6 maybe??. >> >> On Fri, Aug 15, 2025 at 8:24 PM Bakul Shah via TUHS >> wrote: >> >> From RFC 89 (dated 19 January 1971) titled "Some historic >> moments in networking": >> >>    Second, the Harvard system has temporarily implemented >> this remote >>    network console interface feature using a DEC style >> pseudo-teletype >>    (PTY). >> >> From RFC 46 (dated April 1970) titled "'ARPA Network Protocol >> Notes": >> >>    3. A standard way for a newly created process to initiate >> pseudo- >>       typewriter communication with the foreign process which >> requested >>       its creation. >> >> >>> On Aug 15, 2025, at 6:49 PM, ron minnich >>> wrote: >>> >>> was there ever a telnet or other remote access program that >>> predated ptys on Unix? Was telnet the driving force for >>> ptys? Did the folks implementing Unix networking bring in >>> ptys before, or as part of, or after networking, i.e. did >>> folks building networking for Unix realize they needed ptys >>> once they started working on telnet, or did they plan for >>> ptys from the get go? I was an observer for some of this >>> stuff, but as a 20-year-old at UDEL I was also quite out of >>> the loop. >>> >>>  I also realize there were multiple Unix networking efforts, >>> so this question is somewhat simplistic. >>> >>> I'm assuming rsh came a bit later. >>> >>> On Fri, Aug 15, 2025 at 4:19 PM Tom Lyon >>> wrote: >>> >>> Yeah, I was thinking that 4.1c BSD must've had them for >>> rlogin and telnet. >>> >>> Which got me looking for Fabry and Bill Joy's >>> design/planning documents for 4.2, which are not in the >>> TUHS archives. >>> Anyone got them?? >>> >>> On Fri, Aug 15, 2025 at 4:15 PM Warner Losh >>> wrote: >>> >>> At the very least, 4.2BSD had them for telnet and >>> rlogin. They were static, though. You had to MAKEDEV >>> enough units. >>> >>> Warner >>> >>> On Fri, Aug 15, 2025, 5:00 PM ron minnich >>> wrote: >>> >>> That was my guess. I figured the people who did >>> the work are on this list, and primary sources rule. >>> >>> On Fri, Aug 15, 2025 at 3:56 PM Ron Natalie >>> wrote: >>> >>> I think that wikipedia history is somewhat >>> garbled when it comes to the UNIX >>> implementations. >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sun Aug 17 11:05:29 2025 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 16 Aug 2025 18:05:29 -0700 Subject: [TUHS] pseudo tty history In-Reply-To: <3fefdce7-102b-4728-84bc-b2959b224600@insinga.com> References: <048C84A7-E178-4B5D-844A-17CF999CC282@iitbombay.org> <3fefdce7-102b-4728-84bc-b2959b224600@insinga.com> Message-ID: <20250817010529.GB805@mcvoy.com> On Sat, Aug 16, 2025 at 08:21:30PM -0400, Aron Insinga wrote: > The PDP-6 had a sign on it that said something like "This machine > is old and flaky so don't touch it unless you know what you are doing." Wasn't there a PDP- at MIT, I think, that had a switch labeled "magic" and "more magic" that had wires that went nowhere but it only worked when set to "more magic"? I'm sure I have the details wrong but I have a pretty strong memory of that. Anyone able to confirm? From aek at bitsavers.org Sun Aug 17 11:13:33 2025 From: aek at bitsavers.org (Al Kossow) Date: Sat, 16 Aug 2025 18:13:33 -0700 Subject: [TUHS] pseudo tty history In-Reply-To: <20250817010529.GB805@mcvoy.com> References: <048C84A7-E178-4B5D-844A-17CF999CC282@iitbombay.org> <3fefdce7-102b-4728-84bc-b2959b224600@insinga.com> <20250817010529.GB805@mcvoy.com> Message-ID: <36e088c5-e774-96d7-3156-2ebafdecdb56@bitsavers.org> On 8/16/25 6:05 PM, Larry McVoy wrote: > On Sat, Aug 16, 2025 at 08:21:30PM -0400, Aron Insinga wrote: >> The PDP-6 had a sign on it that said something like "This machine >> is old and flaky so don't touch it unless you know what you are doing." > > Wasn't there a PDP- at MIT, I think, that had a switch labeled > "magic" and "more magic" that had wires that went nowhere but it only > worked when set to "more magic"? I'm sure I have the details wrong but > I have a pretty strong memory of that. Anyone able to confirm? > https://github.com/PDP-10/its/issues/1232 the switch still exists From aek at bitsavers.org Sun Aug 17 11:16:04 2025 From: aek at bitsavers.org (Al Kossow) Date: Sat, 16 Aug 2025 18:16:04 -0700 Subject: [TUHS] pseudo tty history In-Reply-To: <36e088c5-e774-96d7-3156-2ebafdecdb56@bitsavers.org> References: <048C84A7-E178-4B5D-844A-17CF999CC282@iitbombay.org> <3fefdce7-102b-4728-84bc-b2959b224600@insinga.com> <20250817010529.GB805@mcvoy.com> <36e088c5-e774-96d7-3156-2ebafdecdb56@bitsavers.org> Message-ID: <3192ad79-327f-f504-fa27-562c46874a47@bitsavers.org> On 8/16/25 6:13 PM, Al Kossow wrote: > On 8/16/25 6:05 PM, Larry McVoy wrote: >> On Sat, Aug 16, 2025 at 08:21:30PM -0400, Aron Insinga wrote: >>> The PDP-6 had a sign on it that said something like "This machine >>> is old and flaky so don't touch it unless you know what you are doing." >> >> Wasn't there a PDP- at MIT, I think, that had a switch labeled >> "magic" and "more magic" that had wires that went nowhere but it only >> worked when set to "more magic"?  I'm sure I have the details wrong but >> I have a pretty strong memory of that.  Anyone able to confirm? >> > > https://github.com/PDP-10/its/issues/1232 > > the switch still exists > https://www.youtube.com/watch?v=_y0nVBpclIE From aek at bitsavers.org Sun Aug 17 11:25:43 2025 From: aek at bitsavers.org (Al Kossow) Date: Sat, 16 Aug 2025 18:25:43 -0700 Subject: [TUHS] pseudo tty history In-Reply-To: <3192ad79-327f-f504-fa27-562c46874a47@bitsavers.org> References: <048C84A7-E178-4B5D-844A-17CF999CC282@iitbombay.org> <3fefdce7-102b-4728-84bc-b2959b224600@insinga.com> <20250817010529.GB805@mcvoy.com> <36e088c5-e774-96d7-3156-2ebafdecdb56@bitsavers.org> <3192ad79-327f-f504-fa27-562c46874a47@bitsavers.org> Message-ID: <3e6a6c9d-0745-a7ca-d45c-7680b7407758@bitsavers.org> On 8/16/25 6:16 PM, Al Kossow wrote: > On 8/16/25 6:13 PM, Al Kossow wrote: >> On 8/16/25 6:05 PM, Larry McVoy wrote: >>> On Sat, Aug 16, 2025 at 08:21:30PM -0400, Aron Insinga wrote: >>>> The PDP-6 had a sign on it that said something like "This machine >>>> is old and flaky so don't touch it unless you know what you are doing." >>> >>> Wasn't there a PDP- at MIT, I think, that had a switch labeled >>> "magic" and "more magic" that had wires that went nowhere but it only >>> worked when set to "more magic"?  I'm sure I have the details wrong but >>> I have a pretty strong memory of that.  Anyone able to confirm? >>> >> >> https://github.com/PDP-10/its/issues/1232 >> >> the switch still exists >> > https://www.youtube.com/watch?v=_y0nVBpclIE > wow, that description is completely wrong. the PDP-6 was built from discrete PNP negative logic, not TTL, at which point I stopped listening it was useful for the picture of the switch though From stewart at serissa.com Sun Aug 17 11:25:37 2025 From: stewart at serissa.com (Lawrence Stewart) Date: Sat, 16 Aug 2025 21:25:37 -0400 Subject: [TUHS] pseudo tty history In-Reply-To: <20250817010529.GB805@mcvoy.com> References: <048C84A7-E178-4B5D-844A-17CF999CC282@iitbombay.org> <3fefdce7-102b-4728-84bc-b2959b224600@insinga.com> <20250817010529.GB805@mcvoy.com> Message-ID: <266A7090-2BB9-4903-A2A9-5FE021440253@serissa.com> My favorite MIT 10 switch was something like “Split Sync Inhibit Enable Override” Never saw it myself. It had something to do with atomic instructions that required “split sync”. > On Aug 16, 2025, at 21:05, Larry McVoy wrote: > > On Sat, Aug 16, 2025 at 08:21:30PM -0400, Aron Insinga wrote: >> The PDP-6 had a sign on it that said something like "This machine >> is old and flaky so don't touch it unless you know what you are doing." > > Wasn't there a PDP- at MIT, I think, that had a switch labeled > "magic" and "more magic" that had wires that went nowhere but it only > worked when set to "more magic"? I'm sure I have the details wrong but > I have a pretty strong memory of that. Anyone able to confirm? From johnl at taugh.com Sun Aug 17 11:56:31 2025 From: johnl at taugh.com (John Levine) Date: 16 Aug 2025 21:56:31 -0400 Subject: [TUHS] magic, was pseudo tty history In-Reply-To: <20250817010529.GB805@mcvoy.com> References: <048C84A7-E178-4B5D-844A-17CF999CC282@iitbombay.org> <3fefdce7-102b-4728-84bc-b2959b224600@insinga.com> Message-ID: <20250817015631.D31A1D7FEA41@ary.qy> It appears that Larry McVoy said: >On Sat, Aug 16, 2025 at 08:21:30PM -0400, Aron Insinga wrote: >> The PDP-6 had a sign on it that said something like "This machine >> is old and flaky so don't touch it unless you know what you are doing." PDP-6's were flaky even when they were new, due to large circuit cards with unreliable connectors. I gather a standard diagnostic technique was to tap all the cards with a rubber mallet to reseat them. The KA-10 used much smaller and more reliable Flip Chip cards. >Wasn't there a PDP- at MIT, I think, that had a switch labeled >"magic" and "more magic" that had wires that went nowhere but it only >worked when set to "more magic"? I'm sure I have the details wrong but >I have a pretty strong memory of that. Anyone able to confirm? Probably this one: https://boingboing.net/2022/08/11/a-story-about-a-weird-magic-switch-at-mit.html From lm at mcvoy.com Sun Aug 17 12:02:51 2025 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 16 Aug 2025 19:02:51 -0700 Subject: [TUHS] pseudo tty history In-Reply-To: <36e088c5-e774-96d7-3156-2ebafdecdb56@bitsavers.org> References: <048C84A7-E178-4B5D-844A-17CF999CC282@iitbombay.org> <3fefdce7-102b-4728-84bc-b2959b224600@insinga.com> <20250817010529.GB805@mcvoy.com> <36e088c5-e774-96d7-3156-2ebafdecdb56@bitsavers.org> Message-ID: <20250817020251.GC805@mcvoy.com> On Sat, Aug 16, 2025 at 06:13:33PM -0700, Al Kossow wrote: > On 8/16/25 6:05 PM, Larry McVoy wrote: > >On Sat, Aug 16, 2025 at 08:21:30PM -0400, Aron Insinga wrote: > >>The PDP-6 had a sign on it that said something like "This machine > >>is old and flaky so don't touch it unless you know what you are doing." > > > >Wasn't there a PDP- at MIT, I think, that had a switch labeled > >"magic" and "more magic" that had wires that went nowhere but it only > >worked when set to "more magic"? I'm sure I have the details wrong but > >I have a pretty strong memory of that. Anyone able to confirm? > > > > https://github.com/PDP-10/its/issues/1232 > > the switch still exists Nice to know I didn't make all that story up in my boomer brain. That story is exactly as I remember it except for this I still have that switch in my basement. Maybe I'm silly, but I usually keep it set on "more magic". I hadn't heard that part. Thanks for the memories, it's part of the history. --lm From clemc at ccc.com Sun Aug 17 12:25:33 2025 From: clemc at ccc.com (Clem Cole) Date: Sat, 16 Aug 2025 19:25:33 -0700 Subject: [TUHS] C history question: why is signed integer overflow UB? In-Reply-To: References: Message-ID: below... On Fri, Aug 15, 2025 at 10:18 AM Dan Cross wrote: > [Note: A few folks Cc'ed directly] > > > > Starting with the 1990 ANSI/ISO C standard, and continuing on to the > present day, C has specified that signed integer overflow is > "undefined behavior"; unsigned integer arithmetic is defined to be > modular, and unsigned integer operations thus cannot meaningfully > overflow, since they're always taken mod 2^b, where b is the number of > bits in the datum (assuming unsigned int or larger, since type > promotion of smaller things gets weird). > > But why is signed overflow UB? My belief has always been that signed > integer overflow across various machines has non-deterministic > behavior, in part because some machines would trap on overflow while > others used non-2's-complement > representations for signed integers and so the results could not be > precisely > defined: even if it did not trap, overflowing a 1's complement machine > yielded a different _value_ than on 2's complement. And around the > time of initial standardization, targeting those machines was still an > important use case. So while 2's complement with silent wrap-around > was common, it could not be assumed, and once machines that generated > traps on overflow were brought into the mix, it was safer to simply > declare behavior on overflow undefined. > We need someone like Peter Darnell, Plauger, and some of the original ANSI C weenies that had to argue this all through in those days, but I think you caught the core issues. This was just one of the many troublesome things that had to be worked through. Until C89, the only ``official'' C was what Dennis shipped at any given time, and that was a bit ephemeral — particularly as the PCs and microprocessors C compiler implemented started to play fast and lose with the C syntax. The core task of the C89 was to do as little harm as possible. My memory is that Dennis was pretty cool and rarely played his trump card (far pointers is one case I am aware that he told the 8086 people to pound sand) , but the compromise that the committee tended to use to kick the can down the road and get the standard out the door was to make things UB with the hopes that later versions could find a way to tighten things up. Truth is, other language specs had used that (like Fortran) , so it was not a bad idea. So, back to your question, I can not say what the actual cause if why there was a conflict WRT to signed integer overflow, but I bet it was that, since so many compilers handled it in different ways, the committee did not have a way to make a formal standard that would work, and they never found one later. FWIW: Remember, C89 tossed a lot of systems like the PDP-11 away with floating point. It says, we are going to use IEEE 754. So just because an old system used a format, did not guarantee it would be accepted. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aki at insinga.com Mon Aug 18 13:07:36 2025 From: aki at insinga.com (Aron Insinga) Date: Sun, 17 Aug 2025 23:07:36 -0400 Subject: [TUHS] magic, was pseudo tty history In-Reply-To: <20250817015631.D31A1D7FEA41@ary.qy> References: <048C84A7-E178-4B5D-844A-17CF999CC282@iitbombay.org> <3fefdce7-102b-4728-84bc-b2959b224600@insinga.com> <20250817015631.D31A1D7FEA41@ary.qy> Message-ID: <848e0500-aaa7-42ea-a04d-4f456ab8a064@insinga.com> Yes, the problem with the large boards made DEC stick with the small Flip-Chip cards for many years.  (Single height, single width Flip-Chips are about the same size as IBM SMS cards; they both used the same wire-wrap backplane and they both used the card edge to form an integral connector.  At least for the PDP-8 they got to use some double height single width boards for things like the AC and registers bit slices.) (FWIW, I am curious about how that Sylvania backplane came about.  A Sylvania idea?  IBM?  Gardner-Denver?) The problems with the PDP-6 and its large boards were one reason DEC co-founder Harlan Anderson left. (https://videogamehistorian.wordpress.com/2014/12/11/historical-interlude-from-the-mainframe-to-the-minicomputer-part-3-dec-and-data-general/) The PDP-11 and KL10 projects finally got around the fear of large boards at DEC.  (IIUC, the very large boards in the Data General Nova were one reason for its low cost; I wonder if that helped too.)  Maybe because they had 7400 TTL & Motorola ECL (respectively) ICs on the boards instead of discrete transistors. https://bitsavers.trailing-edge.com/pdf/dec/pdp6/F-67_circuitInstr_May66.pdf These important bit-slice modules described on pp 32-33 of that manual: * 6205 AR, MQ, MB, and MI flip-flops.  These were 36-bit registers. It is mentioned that it is 3x the area of DEC's then-standard modules (each of which had 1 22-pin connector) and to provide enough connections, it had 4 22-pin connectors, two on each end, side-by-side.  Gordon Bell once described this module as "Bell's Folly. * 6206 MA, PC, and IR flip-flops.  These were 18-bit (memory address) registers.  It is mentioned that it is 2x the area of DEC's then-standard modules and to provide enough connections, it had 2 of the 22-pin connectors, one on each end.    (I don't know if this was also a significant problem source, or if that was only the 6205.) The problems with these modules was that one end could plug into the backplane, but a bus cable had to be run across the back to connect to all of the modules of the same type.  When a module had to be removed, it often resulted in breaking another module or the cable (I forget if it was one, the other, or both). I believe that the effort to construct the large hand-soldered wire-wrap backplane of the PDP-6 encouraged the company to look into the wirewrap backplane for Flip Chips in the classic PDP-8 (and PDP-7).  This was absolutely critical to getting the PDP-8 down to its price point. Dave Gross [RIP] at DEC (a TX-0 and PDP-1 hacker at MIT before he joined DEC) once said that one problem was the PDP-6 design started with germanium transistors but switched to silicon transistors.  (I haven't looked at the module design transistor types in the above-referenced manual to verify this.) So by the time of the PDP-8 and especially the KL10, I think they had a lot more experience with silicon transistors and the transistors themselves were better. So, with virtually the same architecture & instruction set as the PDP-6, the PDP-10 (KA10) was a big winner.  There were a lot of them on the ARPAnet.  It was not the only time that DEC's first product in a space did not do well, but a successor did very, very well. - Aron On 8/16/25 21:56, John Levine wrote: > It appears that Larry McVoy said: >> On Sat, Aug 16, 2025 at 08:21:30PM -0400, Aron Insinga wrote: >>> The PDP-6 had a sign on it that said something like "This machine >>> is old and flaky so don't touch it unless you know what you are doing." > PDP-6's were flaky even when they were new, due to large circuit cards > with unreliable connectors. I gather a standard diagnostic technique > was to tap all the cards with a rubber mallet to reseat them. The KA-10 > used much smaller and more reliable Flip Chip cards. > >> Wasn't there a PDP- at MIT, I think, that had a switch labeled >> "magic" and "more magic" that had wires that went nowhere but it only >> worked when set to "more magic"? I'm sure I have the details wrong but >> I have a pretty strong memory of that. Anyone able to confirm? > Probably this one: > > https://boingboing.net/2022/08/11/a-story-about-a-weird-magic-switch-at-mit.html