TUHS September 2015

tuhs@tuhs.org

35 participants
27 discussions

Re: [TUHS] Questions regarding early Unix contributors

by Doug McIlroy

I can assure you that Lorinda Cherry wrote most of the important code in WWB, including style and diction. The idea for them came from Bill Vesterman at Rutgers. Lorinda already had parts, a real tour de force, which assigned parts of speech to words in a text. Style was the killer app for parts and was running within days of his approach to the labs wondering whether such a thing could be built. Lorinda also wrote deroff, which these tools of course needed. WWB per se was packaged by USDL; I am sorry I can't remember the name of the guiding spirit. So Lorinda's code detoured through there on its way into research Unix. Chris van Wyk was cvw. He was at Bell Labs, not BSD. Chuck Haley is indeed Charles B. Haley. Andy Koenig was ark.

9 years, 3 months

Questions regarding early Unix contributors

by Norman Wilson

A few scattered answers, some redundant with those of others: -- Lorinda Cherry (llc) worked at Bell Labs. She wrote diction (and the rest of the Writer's Workbench tools) there, in the early 1980s; if some people saw it first in BSD releases that is just an accident of timing (too late for V7) and exposure (I'm pretty sure it was available in the USG systems, which weren't generally accessible until a year or two later). Lorinda is one of the less-known members of the original Computer Science Research Center who nevertheless wrote or co-wrote a lot of things we now take for granted, like dc and bc and eqn and libplot. Checking some of this on the web, I came across an interesting tidbit apparently derived from an interview with Lorinda: http://www.princeton.edu/~hos/frs122/precis/cherry2.htm I wholly endorse what she says about UNIX and the group it came from. One fumble in the text: `Bob Ross' who liked to break programs is surely really Bob Morris. -- So far as I know, Tom Duff (td) was never at Berkeley. He's originally from Toronto; attended U of T; was at Lucasfilm for a while (he has a particular interest in graphics, though he is a very sharp and subtle programmer in general); started at Bell Labs in 1984, not long before I did. He left sometime in the 1990s, lives in Berkeley CA, but works neither at UCB nor at Google but at Pixar. -- T. J. Kowalski (frodo) was at Bell Labs; when I was there he worked in the research group down the hall (Acoustics, I think), with whom Computer Science shared a lot of UNIX-releasted stuff. Ted is well-known for his work on fsck, but did a lot of other stuff, including being the first to get Research UNIX to work on the MicroVAX II. He also had a high-quality mustache. -- Andrew Koenig (ark) was part of the Computer Science group when I was there in the latter 1980s. He was a early adopter of C++. asd, the automatic-software distributor we used to keep the software in sync on the 20-or-so systems that ran Research UNIX, was his work. -- Mike Tilson was, I think, one of the founders of HCR (Human Computing Resources), a UNIX-oriented software company based in Toronto in the early 1980s. The company was later acquired by SCO, in the days when SCO was still a technical company rather than a den of lawyers. -- Peter Honeyman (honey) was never, I think, at Berkeley, though he is certainly of the right character. In the 1980s he was variously (sometimes concurrently?) working for some part of AT&T and at Princeton. For many years now he has been in Ann Arbor MI at the University of Michigan, where his still-crusty manner appears not to interfere with his being a respected researcher and much-liked teacher. Norman Wilson Toronto ON (Bell Labs Computing Science Research, 1984-1990)

9 years, 3 months

Questions regarding early Unix contributors

by Diomidis Spinellis

I found out that the book "Life with Unix" by Don Libes and Sandy Ressler has a seven page listing of Unix notables, and I'm using that to fill gaps in the contributors of the Unix history repository [1,2]. Working through the list, the following questions came up. - Lorinda Cherry is credited with diction. But diction.c first appears in 4BSD and 2.10BSD. Did Lorinda Cherry implement it at Berkeley? - Is Chuck Haley listed in the book as the author of tar the same as Charles B. Haley who co-authored V7 usr/doc/{regen,security,setup}? He appears to have worked both at Bell labs (tar, usr/doc/*) and at Berkeley (ex, Pascal). Is this correct? - Andrew Koenig is credited with varargs. This is a four-line header file in V7. Did he actually write it? - Ted Dolotta is credited with the mm macros, but the document "Typing Documents with MM is written by by D. W. Smith and E. M. Piskorik. Did its authors only write the documentation? Did Ted Dolotta also write mmcheck? Also, I'm missing the login identifiers for the following people. If anyone remembers them, please send me a note. Bell Labs, PWB, USG, USDL: Andrew Koenig Charles B. Haley Dick Haight Greg Chesson Herb Gellis Mark Rochkind Ted Dolotta BSD: Bill Reeves Charles B. Haley Colin L. Mc Master Chris Van Wyk Douglas Lanam David Willcox Eric Schienbrood Earl T. Cohen Herb Gellis Ivan Maltz Juan Porcar Len Edmondson Mark Rochkind Mike Tilson Olivier Roubine Peter Honeyman R. Dowell Ross Harvey Robert Toxen Tom Duff Ted Dolotta T. J. Kowalski Finally, I've summarized all contributions allocated through file path regular expressions [3] into two tables ordered by author [4]. (The summary is auto-generated by taking the last significant part of each path regex.) If you want, please have a look at them and point out omissions and mistakes. I will try to commit all responses I receive with appropriate credit to the repository. (You can also submit a GitHub pull-request, if you prefer.) [1] https://github.com/dspinellis/unix-history-repo [2] http://www.dmst.aueb.gr/dds/pubs/conf/2015-MSR-Unix-History/html/Spi15c.pdf [3] https://github.com/dspinellis/unix-history-make/tree/master/src/author-path [4] http://istlab.dmst.aueb.gr/~dds/contributions.pdf Diomidis

9 years, 3 months

Re: [TUHS] Questions regarding early Unix contributors

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > Eric Schienbrood > .. Noel might remember his MIT moniker No, alas; and I tried 'finger Schienbrood(a)lcs.mit.edu' and got no result. Maybe he was in some other part of MIT, not Tech Sq? > From: Arnold Skeeve > Here too I think stuff written at ATT got out through Berkeley. (SCCS) That happened at MIT, too - we had SCCS quite early (my MIT V6 manual has it), plus all sorts of other stuff (e.g. TROFF). I think some of it may have come through Jon Sieber, who, while he was in high school, had been part of (IIRC) a Scout troop which had some association with Bell Labs, and continued to have contacts there after he became an MIT undergrad. Noel

9 years, 3 months

Re: [TUHS] Synchronous vs Asynchronous IO in Unix

by jnc＠mercury.lcs.mit.edu

> From: Peter Jeremy <peter(a)rulingia.com> > Why were the original read(2) and write(2) system calls written to > offer synchronous I/O only? A very interesting question (to me, particularly, see below). I don't think any of the Unix papers answer this question? > It's relatively easy to create synchronous I/O functions given > asynchronous I/O primitives but it's impossible to do the opposite. Indeed, and I've seen operating systems (e.g. a real-time PDP-11 OS I worked with a lot called MOS) that did that. I actually did add asynchronous I/O to V6 UNIX, for use with very early Internet networking software being done at MIT (in a user process). Actually, it wasn't just asynchronous, it was _raw_ asynchronous I/O! (The networking device was DMA, and the s/w did DMA directly into the user process' memory.) The code also allowed more than one outstanding I/O request, too. (So the input could be re-enabled on the device ASAP, without having to wake up a process, have it run, do a new read call, etc.) We didn't redo the whole Unix I/O system, to support/use asyn I/O throughout, though; I just kind of warted it onto the side. (IIRC, it notified the user process via a signal that the I/O had completed; the user software then had to do an sgtty() call to get the transfer status, size, etc.) Anyway, back to the original topic: I don't want to speculate (although I could :-); perhaps someone who was around 'back then' can offer some insight? If not, time for speculation! :-) Noel

9 years, 3 months

Synchronous vs Asynchronous IO in Unix

by Peter Jeremy

Why were the original read(2) and write(2) system calls written to offer synchronous I/O only? It's relatively easy to create synchronous I/O functions given asynchronous I/O primitives but it's impossible to do the opposite. Multics (at least) supported asynchronous I/O so the concept wasn't novel. And any multi-tasking kernel has to support asynchronous I/O internally so suitable code exists in the kernel. -- Peter Jeremy

9 years, 3 months

Why root user name?

by Warren Toomey

As I was dropping off to sleep last night, I wondered why the superuser account on Unix is called root. There's a hierarchy of directories and files beginning at the tree root /. There's a hierarchy of processes rooted with init. But there's no hierarchy of users, so why the moniker "root"? Any ideas? Cheers, Warren

9 years, 3 months

Re: [TUHS] Did realloc ever zero the new memory?

by Doug McIlroy

> Did any Unix or Unix like OS ever zero fill on realloc? > On zero fill, I doubt many did that. Many really early on when memory > was small. This sparks rminiscence. When I wrote an allocation strategy somewhat more sophisticated than the original alloc(), I introduced realloc() and changed the error return from -1 to the honest pointer value 0. The latter change compelled a new name; "malloc" has been with us ever since. To keep the per-byte cost of allocation low, malloc stuck with alloc's nonzeroing policy. The minimal extra code to handle calls that triggered sbrk had the startling property that five passes through the arena might be required in some cases--not exactly scalable to giant virtual address spaces! It's odd that the later introduction of calloc() as a zeroing malloc() has never been complemented by a similar variant of realloc(). > Am I the only one that remembers realloc() being buggy on some systems? I've never met a particular realloc() bug, but realloc does inherit the portability bug that Posix baked into malloc(). Rob Pike and I requested that malloc(0) be required to return a pointer distinct from any live pointer. Posix instead allowed an undefined choice between that behavior and an error return, confounding it with the out-of-memory indication. Maybe it's time to right the wrong and retire "malloc". The name "alloc" might be recycled for it. It could also clear memory and obsolete calloc(). Doug

9 years, 3 months

Happy Programmers' Day!

by Norman Wilson

Dave Horsfall: Today is The Day of the Programmer, being the 0x100'th day of the year. === Are you sure you want to use that radix as your standard? You risk putting a hex on our profession. Norman Wilson Toronto ON

9 years, 3 months

Re: [TUHS] Happy Programmers' Day!

by Doug McIlroy

> Today is The Day of the Programmer, being the 0x100'th day of the year. Still further off topic, but it reminds me of a Y2K incident circa 1960. Our IBM 7090 had been fitted with a homegrown time-of-day clock (no, big blue did not build such into their machines back then). The most significant bits of the clock registered the day of the year. On day 0x100 the clock went negative and the system went wild. Doug

9 years, 3 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 September 2015