TUHS

tuhs@tuhs.org

34 participants
6420 discussions

Re: [TUHS] Early Internet work (Was: History of select(2))

by jnc＠mercury.lcs.mit.edu

> From: Paul Ruizendaal <pnr(a)planet.nl> >> I have this distinct memory of Dave Clark mentioning the Liza Martin >> TCP/IP for Unix in one of the meeting report publihed as IENs > It may be mentioned in this report: > http://web.mit.edu/Saltzer/www/publications/rfc/csr-rfc-228.pdf Yeah, I had run across that in my search for any remnants of the Martin stuff. > Would you know if any of its source code survived? As I had mentioned, I had found some old dump tapes, and had one of them read; it had some bad spots, but we've just (this morning) succeeding in having a look as to what's there, and I _think_ all of the source is OK (including the kernel code, as well as applications like server Telnet and FTP). No SCCS or anything like that, so it's a bit hit or miss doing history - the file write dates were preserved, but of course a lot of them would have been edited over time to fix bugs, add features, etc. The tape appears to contains a _lot_ of other historic material, and it's going to take a while to sort it all out; it includes a Version 6 with NCP from NOSC/SRI, some Unix from BBN; a BCPL compiler; a 'bind' for .rel format files (produced by MACRO-11 and probably BCPL) written in BCPL; programs to convert from .rel to a.out and back; an early verion of Montgomery EMACS; another Unix from 'TMI' (whoever that might be); another UNIX that's somehow associated with TRIX; someone's early kernel overlay stuff; an early 68K C compiler, and also an early 8080 C compiler - just a ton of stuff (that's just a few items that grabbed my eye as I scrolled by). Algol, alas, appears not to be there (we probably didn't add it, because of space reasons). The copy of LISP on this tape seem to be damaged; I do have 3 other tapes, and between them, I hope we'll be able to retrieve it. Noel

7 years, 11 months

Re: [TUHS] Early Internet work (Was: History of select(2))

by jnc＠mercury.lcs.mit.edu

> From: Nick Downing > This is a wonderful find Yes, I was _very_ happy to find those tapes in my basement; up till that, I was almost sure all those bits were gone forever. Thanks to Chuck Guzis, whose old data recovery service made this possible - he actually read the tape. > is it possible for you to read the other tapes also? Alas, they're all of the same system. So the most we're going to get is the files that are missing on this one due to bad spots on the tape. Noel

7 years, 11 months

Re: [TUHS] Early Internet work (Was: History of select(2))

by jnc＠mercury.lcs.mit.edu

> some Unix from BBN This one is from 1979, it includes Mike Wingfield's TCP. The 'Trix UNIX' is a port to the 68K, probably started with something V7ish (I see "setjmp.h" in there). Bits of the Montgomery EMACS appear to date from 1981, but the main source files seem to be from 1984. I also have the source to 'vsh' (Visual Shell), whatever that is. Noel

7 years, 11 months

Early TCP/IP: 3Com UNet

by Paul Ruizendaal

Just stumbled over another early TCP/IP for Unix: http://bitsavers.informatik.uni-stuttgart.de/pdf/3Com/3Com_UNET_Nov80.pdf It would seem to be a design similar to that of Holmgren's (NCP-based) Network Unix (basic packet processing in the kernel, connection management in a user space daemon). In time and in concept it would sit in between the Wingfield ('79, all user space) and the Gurwitz ('81, all kernel) implementations. I think it was distributed initially as a mod versus V7 and later as a mod versus 2BSD. Would anybody here know of surviving source of this implementation? Thanks, Paul

7 years, 12 months

Package Management

by Henry Bent

The recent discussion of Solaris made me think - what was the first Unix to have centralized package management as part of the OS? I know that IRIX had it, I think from the beginning (possibly even for the GL2 releases) but I imagine there was probably something before that. -Henry

7 years, 12 months

Oracle euthanizes Solaris 12, expunging it from roadmap

by Kay Parker

guess it is the beginning of the end of Solaris and the Sparc CPU: 'Rumors have been circulating since late last year that Oracle was planning to kill development of the Solaris operating system, with major layoffs coming to the operating system's development team. Others speculated that future versions of the Unix platform Oracle acquired with Sun Microsystems would be designed for the cloud and built for the Intel platform only and that the SPARC processor line would meet its demise. The good news, based on a recently released Oracle roadmap for the SPARC platform, is that both Solaris and SPARC appear to have a future. The bad news is that the next major version of Solaris—Solaris 12— has apparently been canceled, as it has disappeared from the roadmap. Instead, it's been replaced with "Solaris 11.next"—and that version is apparently the only update planned for the operating system through 2021. With its on-premises software and hardware sales in decline, Oracle has been undergoing a major reorganization over the past two years as it attempts to pivot toward the cloud. Those changes led to a major speed bump in the development cycle for Java Enterprise Edition, a slowdown significant enough that it spurred something of a Java community revolt. Oracle later announced a new roadmap for Java EE that recalibrated expectations, focusing on cloud services features for the next version of the software platform. ' http://arstechnica.com/information-technology/2017/01/oracle-sort-of-confir… -- Kay Parker kayparker(a)mailite.com -- http://www.fastmail.com - The way an email service should be

8 years

Was pcc ever ported to the CDC6600?

by Nemo

All this talk of targets for UNIX makes me wonder (given the eccentricity of the machine). N.

8 years

Working Group for Release of 8th, 9th, 10th Ed Unix?

by Warren Toomey

Now that we have quite a few ex-Bell Labs staff on the list, and several other luminaries, and with the Unix 50th anniversary not far off, perhaps it is time to form a working group to help lobby to get 8th, 9th and 10th Editions released. I'm after volunteers to help. People who can actually move this forward. Let me know if and how you can help out. Thanks, Warren

8 years

Oracle euthanizes Solaris 12, expunging it from roadmap

by Rudi Blom

I'm a bit puzzled, but then I only ever worked with some version of Ultrix and an AT&T flavour of UNIX in Philips, SCO 3.2V4.2 (OpenServer 3ish), DEC Digital UNIX, Tru64, HP-UX 1123/11.31 and only ever used "mkdir -p". Some differences in the various versions are easily solved in scripts, like shown below. Not the best of examples, but easy. Getting it to work on a linux flavour wouldn't be too difficult :-) OS_TYPE=`uname -n` case "${OS_TYPE}" in "OSF1") PATH=".:/etc:/bin:/sbin:/usr/bin:/usr/sbin:/xyz/shell:/xyz/appl/unix/bin:/xyz/utils:" TZ="THA-7" ;; "HP-UX") PATH=".:/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/contrib/bin:/xyz/field/scripts:/xyz/shell:/xyz/appl/unix/bin:/xyz/utils:" TZ="TST-7" ;; *) echo "${OS_TYPE} unknown, exit" exit 1 ;; esac

8 years

Re: [TUHS] [TUHS} PDP-11, Unix, octal?

by jnc＠mercury.lcs.mit.edu

> From: Doug McIlroy > Perhaps the real question is why did IBM break so completely to hex for > the 360? Probably because the 360 had 8-bit bytes? Unless there's something like the PDP-11 instruction format which makes octal optimal, octal is a pain working with 8-bit bytes; anytime you're looking at the higher bytes in a word, unless you are working through software which will 'interpret' the bytes for you, it's a PITA. The 360 instruction coding doesn't really benefit from octal (well, instructions are in 4 classes, based on the high two bits of the first byte, but past that, hex works better); opcodes are 8 or 16 bits, and register numbers are 4 bits. As to why the 360 had 8-bit bytes, according to "IBM's 360 and Early 370 Systems" (Pugh, Johnson, and Palmer, pp. 148-149), there was a big fight over whether to use 6 or 8, and they finally went with 8 because i) statistics showed that more customer data was numbers, rather than text, and storing decimal numbers in 6-bit bytes was inefficient (BCD does two digits per 8-bit byte), and ii) they were looking forward to handling text with upper- and lower-case. Noel

8 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