TUHS October 2019

tuhs@tuhs.org

120 participants
86 discussions

New: The Earliest UNIX Code - From the Collection of the Software History Center, Computer History Museum

by Lyle Bickley

THE EARLIEST UNIX CODE: AN ANNIVERSARY SOURCE CODE RELEASE http://bit.ly/31pWcvM Cheers, Lyle -- 73 NM6Y Bickley Consulting West Inc. https://bickleywest.com "Black holes are where God is dividing by zero"

4 years, 6 months

Re: [TUHS] What was your "Aha, Unix!" moment?

by Doug McIlroy

> From: jnc(a)mercury.lcs.mit.edu (Noel Chiappa) > > > From: Doug McIlroy > > > doing legwork for Multics I ran the following experiment on a lot of > > then-current time-sharing systems. > > Fascinating; you don't happen to remember the ones you tried, do you? > > Also, when you say "legwork for Multics", was this something done during > the planning stages (so, say '64-'65), or later on? It was probably 1965. The places we visited included at least Rand, NBS, Michigan, and Dartmouth. I specifically remember trying the experiment at Michigan and Dartmouth. There were other places, too, but they've dropped from memory. Doug

4 years, 6 months

Re: [TUHS] What was your "Aha, Unix!" moment?

by Pat Barron

I don't know that I had a single "Aha!" moment, but there were a few things that just got hold of me and led me down the Unix path... The first Unix I used was V7m on a PDP-11/40, in college. By this point, I was "aware" of Unix, in theory I even knew C - but never had an actual system to try it out on until this point. I'd used other operating systems (or things that called themselves operating systems...), primarily TRSDOS, CP/M, OS1100, TOPS-10, TOPS-20, and VMS. Unix was certainly the first multiuser operating system that I ever had administrator access on. 1) The idea of taking the output of one program, and using it directly as input to another program - and the simplicity by which it was done - was revolutionary to me. It was not unusual for me at that time to do things like this by having the first program create a temporary file, and then having another program open this temporary file and use it as input, but the whole paradigm of stdin/stdout/pipes made it so you didn't even have to "know" in your program that you might need to use the output of some other program (via a temporary file) as input. That was amazing to me. 2) Unix was really the first operating system that I had full, buildable sources for. (I theoretically had access to VMS source code, but it was on microfiche and not in machine-readable form, so it was just a read-only reference.) If I wanted to see how the OS was doing something, I could look. If I wanted to change something the OS did, or add something to the OS (either in the kernel, or as a user space utility), I could do that (and I did on a couple of occasions). If something was broken, I could try to figure it out and fix it. There was this bug in V7m, where if you were on a non-separate I&D system that didn't have the floating point option (and our 11/40 did not), and you tried to run an "a.out" file that was zero length, you'd get a kernel panic. We were using the system for a computer architecture course, students were programming in assembly language, and if there was a problem with the source file the assembler would leave a zero length executable behind. Of course, students would try to run it anyway, even though "as" produced errors. We'd sometimes get 3 or 4 system crashes in the course of an evening. The students and the instructors were all up in arms because any time this would happen, everyone would lose whatever they were working on (and maybe more, if the filesystem got messed up during the panic), and if there was no one around who had a key to the computer room when it happened, it would stay down until they could find someone who had physical access and the knowledge to know how to deal with "fsck"... (The construction in the lab was pretty minimal, and the walls to most of the rooms didn't go all the way to the ceiling - sometimes when it crashed and no one was around, they'd take to climbing over the wall to reboot the system themselves - which could produce disasterous results of there were filesystem issues...) I found the problem, and I fixed it. That was my first adventure in kernel debugging... (Later, we migrated to a PDP-11/24 and we ordered the KEF11-A floating point option for it, so that problem became moot.) 3) The idea of processes being able to talk to each other (without some kind of pre-arrangement, like setting up a pipe between them, or using temporary files) was just amazing, and this was the first time I'd really seen it. I knew VMS had this thing called a "mailbox", but I never used it for anything and didn't even know what it was for. On V7m, I stumbled across the mpx(5) man page. I think the first time I came across it, I stared at it for hours, looking at the description and trying to figure out what you'd even use that functionality for. At some point it was like a lightning bolt hit me - "Oh, wait! You can use this to send messages between unrelated processes!" Except V7m came with one little proviso - the mpx code was there, but it didn't work... So I dug into it, and made it work - at least, well enough for what I wanted to use it for. I wrote a multiuser chat program with it (isn't that the first thing any undergrad does when they discover interprocess communications? :-) ). I had a similar epiphany with sockets on 4.2BSD a year or two later, under similar circumstances. The one thing I found in command with both mpx and sockets was that the documentation described the low-level functionality - but there was nothing that clearly stated, "This functionaliy is used to allow processes to talk to each other"... I'm sure there are plenty more experiences with early Unix that ensured that I'd continue down this path, but I think these are my favorites. --Pat.

4 years, 6 months

The Unix Game

by Diomidis Spinellis

The game at https://www.unixgame.io/unix50 has you solve challenges by arranging Scratch-like blocks into shell pipelines. Neat! Diomidis

4 years, 6 months

Re: [TUHS] Simple Unix install? (was: What was your "Aha, Unix!" moment?)

by Pat Barron

Possibly the most time consuming install I did was installing Xenix on a bunch of Intel i310 systems. Xenix was a "secondary" OS for these systems, the main OS being iRMX. Xenix for these systems was distributed on 5.25" floppies. Lots and lots of floppies... They came in a 3-ring binder, many pages of floppies... We also had a couple of i380 systems, Xenix for those came on 8" floppies... That was time consuming, but it was just manual labor. The most unpleasasnt install I can recall was AIX 2.2.1 on the IBM-PC/RT. Which also was really (under the covers) Interactive UNIX, with some other stuff mixed in. Not only was this also time-consuming with a binder full of 5.25" floppies, but my recollection is that there were too many opportunities to make a tiny little mistake during the install and have to start all over again. --Pat.

4 years, 6 months

Re: [TUHS] What was your "Aha, Unix!" moment?

by Doug McIlroy

Apropos of Steve Johnson's evocative description of JCL and other pre-Unix OS interfaces, doing legwork for Multics I ran the following experiment on a lot of then-current time-sharing systems. As a model of creating and installing a new compiler, I used a very short Fortran program that simply copied its input to its output, stopping after finding END in column 7 of the input. The drill was compile the program run it, using its own source as input compile the freshly made output file This failed on every system I tried it on, though local experts could intervene with magic to overcome the gratuitous file-type distinctions that typically got in the way. Dartmouth's DTSS came closest, but inexplicably, even to the gurus, it had a special prohibition against a program reading the source from which it was compiled. Incidentally, my favorite manifestation of JCL-like mumbo jumbo was the ironically named FUTIL control card in GECOS. Doug

4 years, 6 months

Celebrating 50 years of Unix

by Caipenghui

Unix has a history of 50 years. Unix has a tremendous impact on the Internet. Is Unix ready for the next computing era?

4 years, 6 months

UNIX at 50

by John P. Linderman

Here's the schedule <https://www.bell-labs.com/unix50/event/>

4 years, 6 months

Unix @ 50

by José Guerra

https://www.bell-labs.com/unix50/event/

4 years, 6 months

Re: [TUHS] What was your "Aha, Unix!" moment?

by jnc＠mercury.lcs.mit.edu

> From: Doug McIlroy > doing legwork for Multics I ran the following experiment on a lot of > then-current time-sharing systems. Fascinating; you don't happen to remember the ones you tried, do you? Also, when you say "legwork for Multics", was this something done during the planning stages (so, say '64-'65), or later on? Noel

4 years, 6 months

← Newer
1
2
3
4
5
6
7
8
9
Older →

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 October 2019