TUHS

tuhs@tuhs.org

37 participants
6497 discussions

Re: [TUHS] conventions around zero padding in ip4

by jnc＠mercury.lcs.mit.edu

> From: Ron Minnich > I first learned in the 80s that 127.1 meant 127.0.0.1. I always assumed > zero padding was defined in a standard *somewhere*, but am finding out > maybe not. I talked to the IP OG, and he tells me that padding was not > in any standard. I don't think it was very standardized; I've been working on the Internet since 1977, and this is the very first I ever recall hearing of it! :-) > From: Bakul Shah > The converse question is who came up with the a.b.c.d format where each > of a,b,c,d is in 0..255? Again, that was not standardized at an early stage, but was, as best I can now recall, just adopted by general usage (i.e. without any formal discussion). There were other ways of specifying a IP address numerically, initially; e.g. for a while at MIT we were using w,x,y,z (with w-z in octal - note the ','s, which were a syntatic tag for the octal form), which was easier to interpret when looking at a packet dump on a PDP-11. Here: http://ana-3.lcs.mit.edu/~jnc/tech/unix/arc/tftp.c.1 is the source for a user command (from July, 1979) which allowed host addresses to be given in that form. I'm not sure who came up with the dotted decimal form; I suspect you'd need to find some really old email archives, and look in that. There was, early on, a list called "tcp-ip", used by people who were getting their machines ready for the NCP->TCP/IP conversion. However, I suspect the 'dotted quad' predates that; there was an even earlier mailing list, used in early experimental work, by the group working on internet technology, whose name escapes me (it was something like "internet working group"). It's possible that an IEN: https://www.rfc-editor.org/ien/ien-index.html might mention the 'dotted quad' syntax; TCP and IP meeting minutes would be a good place to start. Noel PS: The A/B/C addresses are actually a moderately late stage of IP addresses. At the very start, they were all '8 bits network numbers, and 24 bits of 'rest''.

3 years

Re: [TUHS] Alternative Implementation Proposal for Unix/370 (BTL, 1979)

by jnc＠mercury.lcs.mit.edu

> From: Tom Lyon > there were a few icustomer nstallations. Bell Labs Indian Hill was one > - so that's why TSS was the base of their UNIX port. "A UNIX System Implementation for System/370" (by W. A. Felton, G. L. Miller, and J. M. Milner): https://www.bell-labs.com/usr/dmr/www/otherports/ibm.html says "code to support System/370 I/O, paging, error recording and recovery, and multiprocessing already existed in several available operating systems, we investigated the possibility of using an existing operating system, or at least the machine-interface parts of one, as a base to provide these functions for the System/370 implementation ... Of the available systems, TSS/370 came the closest to meeting our needs and was thus chosen as the base for our UNIX system implementation". Alas, it doesn't say which other systems were also considered. >> On May 6, 2022, at 09:39, arnold(a)skeeve.com wrote: >> So, why, given the letter from these folks, including DMR, did they go >> ahead and use the TSS solution anyway? That paper says: "We initially thought about porting the UNIX operating system directly to System/370 with minimal changes. Unfortunately, there are a number of System/370 characteristics that, in the light of our objectives and resources, made such a direct port unattractive. The Input/Output (I/O) architecture of System/370 is rather complex; in a large configuration, the operating system must deal with a bewildering number of channels, controllers, and devices, many of which may be interconnected through multiple paths. Recovery from hardware errors is both complex and model-dependent. For hardware diagnosis and tracking, customer engineers expect the operating system to provide error logs in a specific format; software to support this logging and reporting would have to be written. ... Finally, several models of System/370 machines provide multiprocessing, with two (or more) processors operating with shared memory; the UNIX system did not support multiprocessing." Presumably these factors outweighed the factors listed in the Haley/London/Maranzaro/Ritchie letter. Noel

3 years

Alternative Implementation Proposal for Unix/370 (BTL, 1979)

by Tom Lyon

I was (re?)introduced to Chuck Haley recently and discovered he had a copy of a Bell Labs memo from himself, London, Maranzaro, and Ritchie. They suggest that the path pursued to get UNIX running in/under TSS/370 was the hard way to go. Enjoy: http://charles.the-haleys.org/papers/Alternate_Implementation_Proposal_for_… -- - Tom

3 years

tuhs hiccups?

by Tom Lyon

For some reason, against my wishes, I'm not getting TUHS messages as they happen, but in batches (not digest) after 5-7 days. Last I've received right now is from May 2. Anyone know why? -- - Tom

3 years

Bob Widlar Poster

by Janek Gál

Hey folks, there is a cool poster by Bob Widlar, which we would like to have as a big poster in the hackspace: https://august.sax.de/widlar.jpg This is already a high resolution scan (2048 × 3048) but we are looking for something better (for A0 paper). Does anyone have something like this maybe still in his collection? greetings, Janek :) -- Janek Gál <janek(a)sax.de> Dresden, Germany http://www.sax.de

3 years

Re: [TUHS] First Unix-like OSes not derived from AT&T code?

by John Foust

At 04:17 PM 5/2/2022, Dan Cross wrote: >I vaguely remember Metaware being somewhat religiously extreme, but again the details are fuzzy now. Was there some kind of ecclesiastical reference in the man page? I have the manuals around somewhere, and that rings a bell. I used Metaware High C and the Pharlap extender in the early 1990s in the odd 32-bit DOS enviroment to make 3D import/export plugins for Autodesk's 3D Studio. - John

3 years

Re: [TUHS] First Unix-like OSes not derived from AT&T code?

by Ronald Natalie

We got in on the W4 from the IBM Federal Systems guy (later dealt out to Loral, Martin Marietta, and then Lockheed-Martin). I started with those guy doing a contract job to craft the second nework interface into Secure Xenix (Jacob Recter I think was responsible for the first) to provide a secure downgrading system for some government entity. Then Intel developed the i860- and IBM came up with the Wizard card. This was only designed to be.a coprocessor card and was done down in Boca Raton. The fun and games with that one is that we were on early steppings of the processor chips and spent a lot of time coding around chip bugs (mostly with regard to interrupts). IBM/Intel had developed this thing called hostlink that was supposed to be useful, but we decided to port AIX to it. When IBM Owego came up with the W4, we were asked to port AIX again to it. We had one non-functional W4 kicking around for demo purposes that had 4 “delidded” i860 chips in it. I swapped one for an early stepping (useless) chip and kept one of the delidded ones which I still have in a box somewhere.

3 years

In case you haven't heard yet

by Wesley Parish

I went googling for "Thoth operating system source code" while reading the discussion on Unix-like OSes and found the following: https://securitronlinux.com/debian-testing/nextstep-operating-system-source… which led to https://www.nextcomputers.org/forums/index.php?topic=4690.0 which led to various NeXTStep fragments that might be of interest. Share and Enjoy! Wesley Parish

3 years

2.9BSD with MSCP Support

by Warren Toomey

[ This also in from Peter Klapper. The files are at: https://www.tuhs.org/Archive/Distributions/UCB/2.9BSD_MSCP/ ] This is a 2.9BSD kernel with a backported MSCP driver from 2.10BSD I tried to make a clean integration of the driver into the 2.9BSD source tree in order to be able use the standard procedures to configure and build the kernel. To try it, rename the original directories /usr/include/sys and /usr/src/sys and unpack the two tar archives into your /usr directory. Then change into /usr/src/sys/conf and just do a ./config for the kernel you want. I made some configurations for: MSCP23 (MSCP enabled kernel for the PDP11/23) MSCP73 (MSCP enabled kernel for the PDP11/73) FLOP23 (MSCP enabled 11/23 kernel for a boot floppy) FLOP73 (MSCP enabled 11/73 kernel for a boot floppy) MSCPSH (MSCP enabled kernel for an extended SIMH environment) You may need to adapt the kernel configurations for the correct timezone and maybe the line frequency. This is probably the most recent BSD system which runs on the PDP11/23. Read the full story about this here: https://forum.vcfed.org/index.php?threads/scientific-micro-systems-sms-1000… There is NO root password in this distribution. For installation on real hardware, at least a Maxtor XT-1085 (RD53) or larger is recommended. My SMS1000 system currently has a Maxtor XT-1140 installed. Original was an XT-1085 in the system. The disk layout for these two disks during installation is as follows: Maxtor XT-1085 / DEC RD53 ========================= 1024/8/18 interleave 1,4 --- layout --- root = ra(0,0), size 3200 swap = ra(0,6400), size 1920 usr = ra(0,10240), size 64180 Maxtor XT-1140 ============== 918/15/18 interleave 1,4 --- layout ---- root = ra(0,0), size 3200 swap = ra(0,6400), size 1920 usr = ra(0,10240), size 114880 I've split the data into 4 parts in order to not get too much when downloading: 1.) 29bsd-simh.tgz: A SIMH image including configuration file. "pdp11 sms1123.ini" 2.) 29bsd-smstape.tgz: A Linux dump of the QIC24 installation tape which was generated with my SMS1000 system. You can write this under Linux to a 60MB QIC tape with: "dd if=29bsd-sms-tape.dd of=/dev/st0" The SMS1000 generated format is not compatible with Linux, but the Linux dd'ed tape can be read by the SMS1000 system. 3.) 29bsd-tapefiles.tgz: The files to create a SIMH tape image, or real tape for another system. 4.) 29bsd-vtserver.tgz: The version of the vtserver and the corresponding configuration file with which I performed the successful initial installation. I worked with 19200bps, which is the maximum my SMS1000 supports on the console, under 2.9BSD only 9600bps works anyway. Have fun with it, if you find bugs, they may of course be mine. ;) I wish you and the community also a lot of fun with this version of 2.9BSD. // Peter

3 years

Pro/Venix 2.0: reconstructed

by Warren Toomey

Hi all, I just received this in the e-mail a few days ago: [ now at https://www.tuhs.org/Archive/Distributions/DEC/Venix/ProVenix_2.0/ ] From: Peter Klapper Subject: PRO/VENIX 2.0 reconstructed ... ... and tested, for your collection ;-) Probably the best OS for the Pro, see the benchmark: PRO380 - PRO/VENIX V2.0: ======================== pk$ dryr Dhrystone(1.1) time for 50000 passes = 86 This machine benchmarks at 581 dhrystones/second pk$ drynr Dhrystone(1.1) time for 50000 passes = 95 This machine benchmarks at 526 dhrystones/second The four additional floppy disks contain also the source code which I used to rebuild the missing binaries. I wish you and the community much fun with the "new" resurrected PRO/VENIX V2.0.

3 years

Jump to page:

2025

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