From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 19636 invoked from network); 22 Jun 2022 02:56:11 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 22 Jun 2022 02:56:11 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id AEDB840E73; Wed, 22 Jun 2022 12:56:06 +1000 (AEST) Received: from anduin.eldar.org (anduin.eldar.org [24.106.248.90]) by minnie.tuhs.org (Postfix) with ESMTPS id A501740E6B for ; Wed, 22 Jun 2022 12:56:01 +1000 (AEST) Received: from anduin.eldar.org (IDENT:brad@localhost [127.0.0.1]) by anduin.eldar.org (8.15.2/8.13.8) with ESMTPS id 25M2tcXH010702 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Jun 2022 22:55:38 -0400 (EDT) Received: (from brad@localhost) by anduin.eldar.org (8.15.2/8.13.8/Submit) id 25M2tcF4020200; Tue, 21 Jun 2022 22:55:38 -0400 (EDT) From: Brad Spencer To: Larry McVoy In-Reply-To: <20220622001311.GU26016@mcvoy.com> (message from Larry McVoy on Tue, 21 Jun 2022 17:13:11 -0700) Date: Tue, 21 Jun 2022 22:55:38 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (anduin.eldar.org [127.0.0.1]); Tue, 21 Jun 2022 22:55:39 -0400 (EDT) Message-ID-Hash: VIOROXQ45KMIHWZQKWXEKJLHBMC7FJK2 X-Message-ID-Hash: VIOROXQ45KMIHWZQKWXEKJLHBMC7FJK2 X-MailFrom: brad@anduin.eldar.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: tuhs@tuhs.org X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: forgotten versions List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Larry McVoy writes: > On Tue, Jun 21, 2022 at 05:56:02PM -0600, Jacob Moody wrote: >> I recently stumbled across the existence of datakit >> when going through the plan9foundation source archives. >> Would be curious to hear more about its involvement >> with plan9. > > Pretty sure datakit predated Plan 9, didn't Greg Chesson work on that? > He was my mentor at SGI, my memory is datakit was sort of early on in > his career and then he did XTP, which nobody knows about but I believe > is still used by the military. > > Unless the early Bell Labs datakit and the Plan 9 datakit are different > things. When I was at AT&T in the early to mid '90s Datakit could manifest in a couple of ways. The simplest was as a tty .. that is you had a serial terminal and used a dial string with bangs in it to get somewhere. This method would have used some number of copper pairs into a RJ45 to DB25 adaptor connected to the terminal. The terminals were usually 730s or 6xx (630s maybe). They had some graphics ability, sort of, with some windowing support. The version of SVR3 we had running on the Vaxs had a program in it that would be able to take advantage of the windowing features of the 730 over a serial tty line (multiple windows, X-Windows like sort of). I have totally forgotten what that was called, however. These terminals also had a mouse with them. The second way that Datakit would show itself was as a fiber pair tied directly to a computer system. There were Datakit fiber boards for nearly all of the platforms that the group I was in used... Vax (via a companion box), Tandem, Sun Sparc, at the very least. There was, usually, a third party kernel driver required that would sometimes be a bit messy and/or have a personality to it. This set up sometimes provided a dkcu command and/or a modified cu command and you could use a bang path dial string from the system to get somewhere else using the Datakit network and act like a tty. Or, you could do native Datakit in your user land code. This is what the product I worked on did to talk to a Datakit network at the RBOCs to get access to the switches in the telco network for monitoring purposes. Often in those cases, Datakit would be transported over a X.25 network. Later, as ethernet and TCP/UDP/IP became the thing, the switches learned how to speak TCP/IP, although sometimes indirectly though a translator box in front of the switch. A number of the telco switches we talked to spoke a dialect of X.25 called BX.25 (Bell X.25 or some such) and the translator boxes would exist on the switch side and our side and basically tunnel BX.25 over TCP/IP. This was a bit different then using the Datakit network to get to the switch, but I seem to remember that some RBOCs did something where BX.25 was sent via Datakit which in the wider area network was transported over X.25 to the monitoring system. There were things called Datakit switches that was a cabinet a few feet tall and a couple of feet wide. It housed a bunch of boards of your choosing depending on how you wanted to use Datakit. Our group had their own switch at the site I was at run by the persons dealing with our development lab. There was also a number of Datakit switches for the site itself run by the general IT organization. I seem to remember those switches having hot pluggable boards with an embedded 3B system inside (although I may be misremembering that a bit). -- Brad Spencer - brad@anduin.eldar.org - KC8VKS - http://anduin.eldar.org