TUHS June 2018

tuhs@tuhs.org

62 participants
71 discussions

by jnc＠mercury.lcs.mit.edu

> From: Tony Finch <dot(a)dotat.at> > Was this written down anywhere? Alas, no. It was a presentation at a group seminar, and used either hand-drawn transparencies, or a white-board - don't recall exactly which. I later tried to dig it up for use in Nimrod, but without success. As best I now recall, the concept was that instead of the namespace having a root at the top, from which you had to allocate downward (and then recurse), it built _upward_ - if two previously un-connected chunks of graph wanted to unite in a single system, they allocated a new naming layer on top, in which each existing system appeared as a constituent. Or something like that! :-) The issue with 'top-down' is that you have to have some global 'authority' to manage the top level - hand out chunks, etc, etc. (For a spectacular example of where this can go, look at NSAP's.) And what do you do when you run out of top-level space? (Although in the NSAP case, they had such a complex top couple of layers, they probably would have avoided that issue. Instead, they had the problem that their name-space was spectacularly ill-suited to path selection [routing], since in very large networks, interface names [adddresses] must have a topological aspect if the path selection is to scale. Although looking at the Internet nowadays, perhaps not!) 'Bottom-up' is not without problems of course (e.g. what if you want to add another layer, e.g. to support potentially-nested virtual machines). I'm not sure how well Dave understood the issue of path selection scaling at the time he proposed it - it was very early on, '78 or so - since we didn't understand path selection then as well as we do now. IIRC, I think he was mostly was interested in it as a way to avoid having to have an asssignment authority. The attraction for me was that it was easier to ensure that the names had the needed topological aspect. Noel

6 years, 6 months

Re: [TUHS] core

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall > idiots keep repeating those "quotes" ... in some sort of an effort to > make the so-called "experts" look silly; a form of reverse > jealousy/snobbery or something? It really pisses me off You've just managed to hit one of my hot buttons. I can't speak to the motivations of everyone who repeats these stories, but my professional career has been littered with examples of poor vision from technical colleagues (some of whom should have known better), against which I (in my role as an architect, which is necessarily somewhere where long-range thinking is - or should be - a requirement) have struggled again and again - sometimes successfully, more often, not. So I chose those two only because they are well-known examples - but, as you correctly point out, they are poor examples, for a variety of reasons. But they perfectly illustrate something I am _all_ too familiar with, and which happens _a lot_. And the original situation I was describing (the MIT core patent) really happened - see "Memories that Shaped an Industry", page 211. Examples of poor vision are legion - and more importantly, often/usually seen to be such _at the time_ by some people - who were not listened to. Let's start with the UNIBUS. Why does it have only 18 address lines? (I have this vague memory of a quote from Gordon Bell admitting that was a mistake, but I don't recall exactly where I saw it.) That very quickly became a major limitation. I'm not sure why they did it (the number of contact on a standard DEC connector probably had something do with it, connected to the fact that the first PDP-11 had only 16-bit addressing anyway), but it should have been obvious that it was not enough. And a major one from the very start of my career: the decision to remove the variable-length addresses from IPv3 and substitute the 32-bit addresses of IPv4. Alas, I was too junior to be in the room that day (I was just down the hall), but I've wished forever since that I was there to propose an alternate path (the details of which I will skip) - that would have saved us all countless billions (no, I am not exaggerating) spent on IPv6. Dave Reed was pretty disgusted with that at the time, and history shows he was right. Dave also tried to get a better checksum algorithm into TCP/UDP (I helped him write the PDP-11 code to prove that it was plausible) but again, it got turned down. (As did his wonderful idea for bottom-up address allocation, instead of top-down. Oh well.) People have since discussed issues with the TCP/IP checksum, but it's too late now to change it. One place where I _did_ manage to win was in adding subnetting support to hosts (in the Host Requirements WG); it was done the way I wanted, with the result that when CIDR came along, even though it hadn't been forseen at the time we did subnetting, it required _no_ hosts changes of any kind. But mostly I lost. :-( So, is poor vision common? All too common. Noel

6 years, 6 months

Re: [TUHS] core

by Johnny Billquist

On 2018-06-18 04:00, Ronald Natalie <ron(a)ronnatalie.com> wrote: >> Well, it is an easy observable fact that before the PDP-11/70, all PDP-11 models had their memory on the Unibus. So it was not only "an ability at the lower end", b > That’s not quite true. While the 18 bit addressed machines all had their memory directly accessible from the Unibus, the 45/50/55 had a separate bus for the (then new) semiconductor (bipolar or MOS) memory. Eh... Yes... But... The "separate" bus for the semiconductor memory is just a second Unibus, so the statement is still true. All (earlier) PDP-11 models had their memory on the Unibus. Including the 11/45,50,55. It's just that those models have two Unibuses. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

6 years, 6 months

In Memorium: Alan Turing

by Dave Horsfall

We lost the Father of Computing, Alan Turing, on this day when he suicided in 1954 (long story). Just imagine where computing would've been now... Yes, there are various theories surrounding his death, such as a jealous lover, the FBI knowing that he knew about Verona and could be compromised as a result of his sexuality, etc. Unless they speak up (and they ain't), we will never know. Unix reference? Oh, that... No computable devices (read his paper), no computers... And after dealing with a shitload of OSs in my career, I daresay that there is no more computable OS than Unix. Sorry, penguins, but you seem to require a fancy graphical interface these days, just like Windoze. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

6 years, 6 months

Re: [TUHS] core

by jnc＠mercury.lcs.mit.edu

> From: Derek Fawcus <dfawcus+lists-tuhs(a)employees.org> > my scan of it suggests that only the host part of the address which were > extensible Well, the division into 'net' and 'rest' does not appear to have been a hard one at that point, as it later became. > The other thing obviously missing in the IEN 28 version is the TTL Yes... interesting! > it has the DF flag in the TOS field, and an OP bit in the flags field Yeah, small stuff like that got added/moved/removed around a lot. > the CIDR vs A/B/C stuff didn't really change the rest. It made packet processing in routers quite different; routing lookups, the routing table, etc became much more complex (I remember that change)! Also in hosts, which had not yet had their understanding of fields in the addresses lobotomized away (RFC-1122, Section 3.3.1). Yes, the impact on code _elsewhere_ in the stack was minimal, because the overall packet format didn't change, and addresses were still 32 bits, but... > The other bit I find amusing are the various movements of the port > numbers Yeah, there was a lot of discussion about whether they were properly part of the internetwork layer, or the transport. I'm not sure there's really a 'right' answer; PUP: http://gunkies.org/wiki/PARC_Universal_Packet made them part of the internetwork header, and seemed to do OK. I think we eventually decided that we didn't want to mandate a particular port name size across all transports, and moved it out. This had the down-side that there are some times when you _do_ want to have the port available to an IP-only device, which is why ICMP messages return the first N bytes of the data _after_ the IP header (since it's not clear where the port field[s] will be). But I found, working with PUP, there were some times when the defined ports didn't always make sense with some protocols (although PUP didn't really have a 'protocol' field per se); the interaction of 'PUP type' and 'socket' could sometimes be confusing/problemtic. So I personally felt that was at least as good a reason to move them out. 'Ports' make no sense for routing protocols, etc. Overall, I think in the end, TCP/IP got that all right - the semantics of the 'protocol' field are clear and simple, and ports in the transport layer have worked well; I can't think of any places (other than routers which want to play games with connections) where not having ports in the internetwork layer has been an issue. Noel

6 years, 6 months

Re: [TUHS] core

by jnc＠mercury.lcs.mit.edu

> From: Derek Fawcus > Are you able to point to any document which still describes that > variable length scheme? I see that IEN 28 defines a variable length > scheme (using version 2) That's the one; Version 2 of IP, but it was for Version 3 of TCP (described here: IEN-21, Cerf, "TCP 3 Specification", Jan-78 ). > and that IEN 41 defines a different variable length scheme, but is > proposing to use version 4. Right, that's a draft only (no code ever written for it), from just before the meeting that substituted 32-bit addresses. > (IEN 44 looks a lot like the current IPv4). Because it _is_ the current IPv4 (well, modulo the class A/B/C addressing stuff). :-) Noel

6 years, 6 months

Re: [TUHS] maybe off-topic: Unix on a microcontroller

by jnc＠mercury.lcs.mit.edu

> From: Johnny Billquist > It's a separate image (/netnix) that gets loaded at boot time, but it's > run in the context of the kernel. ISTR reading that it runs in Supervisor mode (no doubt so it could use the Supervisor mode virtual address space, and not have to go crazy with overlays in the Kernet space). Never looked at the code, though. Noel

6 years, 6 months

Re: [TUHS] maybe off-topic: Unix on a microcontroller

by Johnny Billquist

On 2018-06-17 04:00, jnc(a)mercury.lcs.mit.edu (Noel Chiappa) wrote: > > From: Johnny Billquist > > > It's a separate image (/netnix) that gets loaded at boot time, but it's > > run in the context of the kernel. > > ISTR reading that it runs in Supervisor mode (no doubt so it could use the > Supervisor mode virtual address space, and not have to go crazy with overlays > in the Kernet space). Yes. That rings a bell now that you mention it. Pretty sure you are correct. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

6 years, 6 months

Re: [TUHS] core

by jnc＠mercury.lcs.mit.edu

> From: Johnny Billquist > incidentally have 18 data bits, but that is mostly ignored by all > systems. I believe the KS-10 made use of that, though. And maybe the > PDP-15. The 18-bit data thing is a total kludge; they recycled the two bus parity lines as data lines. The first device that I know of that used it is the RK11-E: http://gunkies.org/wiki/RK11_disk_controller#RK11-E which is the same cards as the RK11-D, with a jumper set for 18-bit operation, and a different clock crystal. The other UNIBUS interface that could do this was the RH11 MASSBUS controller. Both were originally done for the PDP-15; they were used with the UC15 Unichannel. The KS10: http://gunkies.org/wiki/KS10 wound up using the 18-bit RH11 hack, but that was many years later. Noel

6 years, 6 months

Re: [TUHS] maybe off-topic: Unix on a microcontroller

by Johnny Billquist

On 2018-06-16 04:00, Tom Ivar Helbekkmo<tih(a)hamartun.priv.no> wrote: > Warner Losh<imp(a)bsdimp.com> writes: > >> It looks like retrobsd hasn't been active in the last couple of years >> though. A cool accomplishment, but with some caveats. All the network >> is in userland, not the kernel, for example. > Isn't 2.11BSD networking technically in userland? I forget. Johnny? No, networking in 2.11BSD is not in userland. But it's not a part of /unix either. It's a separate image (/netnix) that gets loaded at boot time, but it's run in the context of the kernel. I'd have to go and check this if anyone wants details. It's been quite a while since I was fooling around inside there. Or maybe someone else remembers more details on how it integrates. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

6 years, 6 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS June 2018