From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id e007b083 for ; Wed, 28 Aug 2019 00:08:09 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 5297D9BC51; Wed, 28 Aug 2019 10:08:08 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 44B069BC01; Wed, 28 Aug 2019 10:07:49 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=algebras-org.20150623.gappssmtp.com header.i=@algebras-org.20150623.gappssmtp.com header.b="kGneWWvk"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id BBD5D9BC01; Wed, 28 Aug 2019 10:07:45 +1000 (AEST) Received: from mail-io1-f66.google.com (mail-io1-f66.google.com [209.85.166.66]) by minnie.tuhs.org (Postfix) with ESMTPS id 06B939BBFD for ; Wed, 28 Aug 2019 10:07:43 +1000 (AEST) Received: by mail-io1-f66.google.com with SMTP id o9so2257594iom.3 for ; Tue, 27 Aug 2019 17:07:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=MSaHgrp2SCX/rqislTBCox5atQKAIsGKZ4GMYivn4a8=; b=kGneWWvkG88qO3KRTdL4ImS7bM5NeTJXak/OW3xKnr+pYZRr0jNBceN3QHpDDVu6UY dXBlWivOA24EDAkn90brkVr6rimej6NghqQd2R0sy5gpV3y5+JRpfQ5WpaWypqtCewOF thcZXm+nnbdL5/XuovlRhNr80SwONaeL7HGmrHc1/PlmHda4HVcgg22d3fVdpke7QMa5 dQ9sQD0kbHxNP0VwLLAhzs3mVLqOISQmdQf9uOS/jbrOxd7s0gQNGDHvV+GU5XdvRvM2 pbzNhqeWAdR2tfsOYRlqU8oTBbLiKGUcE9SAE9iDZffa4vtR0KUHh3hOrul/6HwsCq9Z zVXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=MSaHgrp2SCX/rqislTBCox5atQKAIsGKZ4GMYivn4a8=; b=YGqk9iEdfN3C6j2EqB9/SBIZeKZaLpI2Y6Cbo311B7jjvdm3uKtsfD3Jgq0FGgoYZ6 9cvAwNiltyKnCtn/Os0QqaxSQiLkY3BugtbzrMRpDOwb9M08fFYAs/E8z636JTS4sIEH MqQPEXA2YSrndwn1iJEHSn3g/ItaAk1T/1pDSrBAjmyXh4NWWo3fDPcMl2fM/YfrB2fl zpYNkQNHqr4yNvyMWDc6CRcchETYN3Px+aNtvXv0Gl3BujvORRUJpmQH6jJvRo+v+ujB /rCvL5VZ+tN7Bg4yBbIR5ZM3VKAwKvIffax5MGYNoJw42NL1+WOdqALplnPyeHBMGYWO 8+Bw== X-Gm-Message-State: APjAAAX5Gkl5CX0k1aRhdJ+82O+WYvxFxjiIuReKrJ5ciLNEHPucKodO FmCax9fKtopjtQ4hY0kyclIDG0KfZ9NJYXL4KfL9dw== X-Google-Smtp-Source: APXvYqyzDrU9Qme9ywBFFNRxutXOYYxyPb69eLAz3MMHfmrOQMthp/slzAUD7lc5mt1CXohvX7sIexhd7Fb4MRdqeHw= X-Received: by 2002:a6b:3b57:: with SMTP id i84mr1206757ioa.145.1566950862157; Tue, 27 Aug 2019 17:07:42 -0700 (PDT) MIME-Version: 1.0 References: <20190827003013.GS13570@mcvoy.com> <312b39a1-2944-100f-55e0-fc65b504d43d@kilonet.net> <20190827024511.GU13570@mcvoy.com> <20190827145556.GD13570@mcvoy.com> <20190827224002.GB15511@mcvoy.com> <20190827225955.GC15511@mcvoy.com> In-Reply-To: From: George Michaelson Date: Wed, 28 Aug 2019 10:07:30 +1000 Message-ID: To: Clem Cole Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [TUHS] If not Linux, then what? X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: TUHS main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" At the time we are talking, almost all people were using serial line protocols, of some form, for point-to-point links. Ethernet was "new" and I think at one level, being a good (binary) tty/serial discipline was workable. Stacking things was possible was it not? And, the way I understand it, The code avoided data copying so was very very efficient across protocol stacks. I think it was capable of being improved. Sockets is now defined by standards. Its impossible to make it do things without huge cost. We're comparing now, with then.. always dangerous. -G On Wed, Aug 28, 2019 at 9:10 AM Clem Cole wrote: > > I had a similar conversation btw. I liked what Dennis did to clean up th= e tty handler but I agree as a networking interface it was wretched which i= s what system v did. At stellar we put in the bbn (walsh2) stack and spl= iced back in sockets so the bsd code still worked. > That said the idea of trying to keep the everything is a file semantic wa= s good and streams were closer. The problem sockets is they really were not= quite The same. > > What I liked about plan 9 was breaking the control interface out so the f= ile stuff stayed sane. But that was a bridge to far for a traditional Uni= x. > > > On Tue, Aug 27, 2019 at 7:00 PM Larry McVoy wrote: >> >> streams were OK but Dennis himself told me he didn't intend them for >> networking. They were a simple mechanism for pushing line disciplines >> onto tty drivers. >> >> I can't remember exactly what he said, this was back in ~1988 or so >> and I was talking to him about the STREAMS stuff. He wasn't very >> happy with it and I'm pretty sure he said something like streams >> weren't design to mux multiple sources or network connections. >> I think he sort of grudgingly gave credit that they made it work >> but he seemed to think that it was twisting streams more than they >> should be twisted. >> >> On Wed, Aug 28, 2019 at 08:46:35AM +1000, George Michaelson wrote: >> > oh maybe I meant "streams" not "STREAMS" I always got confused if the >> > original ritchie spec was upper or lower case. Charles Forsyth coded >> > it into the York Uni Vaxen, worked fine. I left shortly after to do >> > stuff at UCL, it only came back into my life when at UQ in Australia >> > we got an ICL "certified" SYSV host and along side dead technology >> > like RFS up it popped (I think ICL had coded an OSI stack we were >> > testing) >> > >> > -G >> > >> > On Wed, Aug 28, 2019 at 8:40 AM Larry McVoy wrote: >> > > >> > > Wait, are you arguing for STREAMS over sockets? Dear god, please no= . >> > > Have you ever used STREAMS (not Ritchies streams, those were OK)? >> > > I have. I ported Lachman's STREAMS based TCP/IP stack twice, once >> > > to a long since defunct super computer called the ETA-10 and then >> > > to SCO Unix. I've got way more STREAMS experience than most people >> > > and I can tell you that sockets are WAY WAY better. I get the "it >> > > should have just been file I/O" except that I don't. I tried to >> > > write a library that let you open up /net/tcp/$host:$port and do >> > > I/O like it was a file descriptor. That works for a lot of stuff >> > > but I ran into problems quickly. A networking connection is not >> > > a file handle. You can make some stuff work but I couldn't figure >> > > out how to do all of it. You end up having to do ioctls to handle >> > > the stuff that doesn't fit well into the file system name space. >> > > I think plan 9 did this sort of thing, maybe Rob can prove me wrong >> > > or remember where it didn't match. >> > > >> > > I do know that STREAMS came back to Solaris, some VP inked a shitty >> > > deal with Lachman and bought the rights to the stack. It was slow >> > > as molasses in the winter and customers absolutely hated it. Sun >> > > got Mentat to redo it for perf but customers still hated it, they >> > > understood sockets, everyone else had sockets, they wanted sockets >> > > and they got them. Sun put them back and nobody ever asked about >> > > STREAMS again. >> > > >> > > On Wed, Aug 28, 2019 at 08:30:01AM +1000, George Michaelson wrote: >> > > > BSD, but with the original STREAMS semantics, not sockets. >> > > > >> > > > DARPA did us no favours accepting sockets in place of simple file = I/O >> > > > semantics for networks. >> > > > >> > > > Newcastle connection put the namespace into >> > > > /.../remote-part/path/to/thing which I felt was also good. >> > > > >> > > > So for me, 7 -> BSD -> got worse for some values of worse >> > > > >> > > > On Wed, Aug 28, 2019 at 12:56 AM Larry McVoy wrote: >> > > > > >> > > > > On Mon, Aug 26, 2019 at 11:14:45PM -0400, Arthur Krewat wrote: >> > > > > > On 8/26/2019 10:45 PM, Larry McVoy wrote: >> > > > > > > Which was that the page cache is >> > > > > > >*the* cache. There is nothing else. >> > > > > > Yeah, I re-read what you wrote a few times after I replied, an= d realized >> > > > > > what you meant ... eventually ;) >> > > > > >> > > > > I might be making too big of a deal about it. mmap semantics ma= ttered >> > > > > a lot when SMPs first showed up and main memory was small. It m= eant >> > > > > that you could have multiple CPUs seeing and working on the same= chunk >> > > > > of data at the same time. >> > > > > >> > > > > It's very similar to way that IOMMUs are exposed to user space t= hese >> > > > > days, enabling virtual machines direct access to the I/O devices= . >> > > > > >> > > > > ZFS breaks that model, the data is all in the ARC and if you mma= p >> > > > > it they have to bcopy the data out of the ARC, into the page cac= he >> > > > > and now they have a consistency problem, you could modify stuff >> > > > > via mmap or write and they have to manage that. >> > > > > >> > > > > That consistency problem is the main reason that Sun almost comp= letely >> > > > > killed the buffer cache (it still was used for inodes and direct= ories >> > > > > but that was it). That consistency problem is a pain in the rea= r, >> > > > > all sorts of race conditions and it tended to bit rot. >> > > > > >> > > > > Jeff and Bill are smart people so I suspect they got it right bu= t I'm >> > > > > still stunned that they took such an architecturally bad approac= h. >> > > > > And even more stunned that the oversight people approved it. Th= ere >> > > > > is zero chance that the Sun I worked at would have allowed that. >> > > > > >> > > > > --lm >> > > >> > > -- >> > > --- >> > > Larry McVoy lm at mcvoy.com http://www.= mcvoy.com/lm >> >> -- >> --- >> Larry McVoy lm at mcvoy.com http://www.mcvo= y.com/lm > > -- > Sent from a handheld expect more typos than usual