I had a similar conversation btw. I liked what Dennis did to clean up the tty handler but I agree as a networking interface it was wretched which is what system v did. At stellar we put in the bbn (walsh2) stack and spliced back in sockets so the bsd code still worked. That said the idea of trying to keep the everything is a file semantic was 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 file stuff stayed sane. But that was a bridge to far for a traditional Unix. 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, and > realized > > > > > > what you meant ... eventually ;) > > > > > > > > > > I might be making too big of a deal about it. mmap semantics > mattered > > > > > a lot when SMPs first showed up and main memory was small. It > meant > > > > > 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 > these > > > > > 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 mmap > > > > > it they have to bcopy the data out of the ARC, into the page cache > > > > > 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 > completely > > > > > killed the buffer cache (it still was used for inodes and > directories > > > > > but that was it). That consistency problem is a pain in the rear, > > > > > all sorts of race conditions and it tended to bit rot. > > > > > > > > > > Jeff and Bill are smart people so I suspect they got it right but > I'm > > > > > still stunned that they took such an architecturally bad approach. > > > > > And even more stunned that the oversight people approved it. There > > > > > 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.mcvoy.com/lm > -- Sent from a handheld expect more typos than usual