TUHS

tuhs@tuhs.org

5 participants
6532 discussions

A New History of Modern Computing - my thoughts

by Jon Steinhart

Eugene Miya visited by last week and accidentally left his copy of the book here so I decided to read it before he came back to pick it up. My overall impression is that while it contained a lot of information, it wasn't presented in a manner that I found interesting. I don't know the intended target audience, but it's not me. A good part of it is that my interest is in the evolution of technology. I think that a more accurate title for the book would be "A New History of the Business of Modern Computing". The book was thorough in covering the number of each type of machine sold and how much money was made, but that's only of passing interest to me. Were it me I would have just summarized all that in a table and used the space to tell some engaging anecdotes. There were a number of things that I felt the book glossed over or missed completely. One is that I didn't think that they gave sufficient credit to the symbiosis between C and the PDP-11 instruction set and the degree to which the PDP-11 was enormously influential. Another is that I felt that the book didn't give computer graphics adequate treatment. I realize that it was primarily in the workstation market segment which was not as large as some of the other segments, but in my opinion the development of the technology was hugely important as it eventually became commodified and highly profitable. Probably due to my personal involvement I felt that the book missed some important steps along the path toward open source. In particular, it used the IPO of Red Hat as the seminal moment while not even mentioning the role of Cygnus. My opinion is that Cygnus was a huge icebreaker in the adoption of open source by the business world, and that the Red Hat IPO was just the culmination. I also didn't feel that there was any message or takeaways for readers. I didn't get any "based on all this I should go and do that" sort of feeling. If the purpose of the book was to present a dry history then it pretty much did it's job. Obviously the authors had to pick and choose what to write about and I would have made some different choices. But, not my book. Jon

3 years, 7 months

Re: [TUHS] A New History of Modern Computing - my thoughts

by jnc＠mercury.lcs.mit.edu

> The ++ operator appears to have been. One would expect that most people on this list would have read "The Development of the C Language", by Dennis Ritchie, which makes perfectly clear (at 'More History') that the PDP-11 had nothing to do with it: Thompson went a step further by inventing the ++ and -- operators, which increment or decrement; their prefix or postfix position determines whether the alteration occurs before or after noting the value of the operand. They were not in the earliest versions of B, but appeared along the way. People often guess that they were created to use the auto-increment and auto-decrement address modes provided by the DEC PDP-11 on which C and Unix first became popular. This is historically impossible, since there was no PDP-11 when B was developed. https://www.bell-labs.com/usr/dmr/www/chist.html thereby alleviating the need for Ken to chime in (although they do allow a very efficient implementation of it). Too much to hope for, I guess. Noel

3 years, 7 months

Re: [TUHS] PL/I stuff - was: Book Recommendation

by jnc＠mercury.lcs.mit.edu

> From: "Charles H. Sauer"k <sauer(a)technologists.com> > I haven't done anything with 9 ktrack tapes for a long time ... > I don't recall problems reading any of them. ... > IMNSHO, it all depends on the brand/formulation of the tape. I've been > going through old audio tapes and digitizing them The vintage computer community has considerable experience with old tapes; in fact Chuck Guzis has a business reading them (which often includes converting old file formats to something modern software can grok). We originally depended heavily on the work of the vintage audio community, who pioneered working with old tapes, including the discovert of 'baking' them to improve their mechanical playability. ("the binder used to adhere the magnetic material to the backing ... becomes unstable" - playing such a tape will transfer much of the magnetic material to the head, destroying the tape's contents.) It's amazing how bad a tape can be, and still be readable. I had a couple of dump tapes of the CSR PWB1 machine at MIT, which I had thoughtlessly stored in my (at one period damp) basement, and they were covered in mold - and not just on the edges! Chuck had to build a special fixture to clean off the mold, but we read most of the first tape. (I had thoughtfully ade a second copy, which read perfectly.) Then I had to work out what the format was - it turned out that even though the machine had a V6 filesystem, my tape was a 'dd' of a BSD4.1c filesystem (for reasons I eventually worked out, but won't bore you all with). Dave Bridgham managed to mount that under Linux, and transform it into a TAR file. That was the source of many old treasures, including the V6 NCP UNIX. Noel

3 years, 7 months

PL/I stuff - was: Book Recommendation

by Douglas McIlroy

> What, if any, features does PL/I have that are not realized in a modern language? Here are a few dredged from the mental cranny where they have mouldered for 50+ years. 1. Assignment by name. If A and B are structs (not official PL/I terminology), then A + B A = B copies similarly named fields of B to corresponding fields in A. 2. Both binary and decimal data with arithmetic rounded to any specified precision. 3. Bit strings of arbitrary length, with bitwise Boolean operations plus substr and catenation. 4. A named array is normally passed by reference, as in F(A). But if the argument is not a bare name, as in F((A)), it is passed by value. 5. IO by name. On input this behaves like assignment from a constant, with appropriate type conversion. 6. A SORT statement. 7. Astonishingly complete set of implicit data conversions. E.g. if X is floating-point and S is a string, the assignment X = S works when S = "2" and raises an exception (not PL/I terminology) when S = "A". My 1967 contribution to ACM collected algorithms exploited 3 and 4. I don't know another language in which that algorithm is as succinct. Doug

3 years, 7 months

Re: [TUHS] 9-track tape (was PL/I stuff)

by Paul Winalski

DEC's VAX/VMS group got a customer bug report that was accompanied by a 9-track tape containing the programs and data necessary to reproduce the problem. When the engineer mounted the tape, it contained completely different data. He tried a different tape drive and this time he got the expected data. It turned out that the customer had reused the tape and recorded the reproducer at 1600 bpi on top of previous data recorded at 800 bpi. If the tape was mounted such that the drive didn't see the PE burst, it could still read the NRZI-encoded 800 bpi data. -Paul W.

3 years, 7 months

Re: [TUHS] Book Recommendation

by Douglas McIlroy

The following remark stirred old memories. Apologies for straying off the path of TUHS. > I have gotten the impression that [PL/I] was a language that was beloved by no one. As I was a designer of PL/I, an implementer of EPL (the preliminary PL/I compiler used to build Multics), and author of the first PL/I program to appear in the ACM Collected Algorithms, it's a bit hard to admit that PL/I was "insignificant". I'm proud, though, of having conceived the SIGNAL statement, which pioneered exception handling, and the USES and SETS attributes, which unfortunately sank into oblivion. I also spurred Bud Lawson to invent -> for pointer-chasing. The former notation C(B(A)) became A->B->C. This was PL/I's gift to C. After the ACM program I never wrote another line of PL/I. Gratification finally came forty years on when I met a retired programmer who, unaware of my PL/I connection, volunteered that she had loved PL/I above all other programming languages. Doug

3 years, 7 months

IBM Unix

by Ron Natalie

I remember getting an early RT without being given the root password. Now there hadn’t been too many Unix boxes I wasn’t able to break into. The Rt you could turn the key to the wrench symbol and get into the maintenance menus. Selecting to view some document which was displayed with more and that you could bang a root shell out of. > On Nov 24, 2021, at 14:42, Clem Cole <clemc(a)ccc.com> wrote: > > > > >> On Wed, Nov 24, 2021 at 1:43 PM Larry McVoy <lm(a)mcvoy.com> wrote: >> SMIT - just say no. > There were a number of things IBM did well with AIX so I'm not quite so glib knocking everything from them. > >

3 years, 7 months

Re: [TUHS] Book Recommendation

by Norman Wilson

Larry McVoy: Say hi to Barry for me, I knew him back in the UUCP days, he was always pleasant. ==== And for me. Knew him back in my DECUS days. Also tell him that since he runs the World, it's all his fault. Norman Wilson Toronto ON

3 years, 7 months

Two anecdotes

by Alan Glasser

Here are two anecdotes that Doug suggested I share with TUHS (I am new to TUHS, having joined just last month). *First*: *The creation of access(2).* [Marc Rochkind documented a version of this on page 56 of his book *Advanced Unix Programming* (1985, First Edition) discussing link(2). The footnote on that page says "Alan L. Glasser and I used this scheme to break into Dennis Ritchie and Ken Thompson's system back in 1973 or 1974."] Doug pointed out that the timing was probably later, as access(2) was not in the Sixth Edition release, but probably right after the release (after May 1975?). It arose from a discussion I was having with Marc, with whom I worked on SCCS and other PWB tools. We were discussing some mechanism that would require moving directories (actually, simple renaming) in a shell procedure. I told Marc that only root could make links to directories or unlink directories, but he told me that he has renamed directories with the mv command. I said then mv must be setuid to root, so we looked, and, of course, it was. I then looked at the source code for mv and quickly saw that there was no attempt to check permission on the real uid. So I told Marc it would allow anyone to become root. He wanted to see it in action, so I logged into research (I don’t remember what our organization's shared login was). No one in our organization had root access on research. Marc and I didn't have root access on our organization's machines; Dick Haight et. al. didn't share that privilege (Dick was the manager of the super-users). I think the actual sequence of commands was: cd / cp etc/passwd tmp ed tmp/passwd 1s/^root:[^:]*:/root::/ w q mv etc etc2 mv tmp etc su mv etc tmp mv etc2 etc mv etc/as2 etc/.as2 {logout, hangup and wonder} The last bit was a test to see what was noticed about what I did. Marc and I talked for a while about it and discussed if we had any need to be root on our local machines, but couldn't think of any pressing need, but knowing we could was a bit of a comfort. After a short time, Marc suggested logging back in to see what, if anything, had been done. /bin/mv had lost setuid to root /etc/as2 was restored /etc/.as2 was nonexistent And the next day, the motd on research mentioned that there's a new syscall: access. And mv(1) now used it. *Second*: Our organization was one (out of possibly others) subject of Ken's *codenih* that he documented in his Turing Award article in CACM. As previously described, root access was closely guarded in the PWB organization and, according to Doug, freely available in research. Ken had given us a login that was shared by PWB development and we had given Ken a login to our systems. We had no root access on research and Ken had no root access on our systems. Our C compiler guy, Rich Graveman, who kept in close contact with Dennis and was always getting us the latest compiler to install, had gone to MH and came back with a tape of a new compiler. Rich, being a careful fellow, did a size on c0, c1, c2 on the files from the tape and did the same on the running compiler pieces in /lib. Lo and behold, he discovered that the new compiler from Dennis was smaller than the old compiler even though it had a whole new feature (I think it was union). So Rich did nm's on the two different c0's and discovered a name "codenih" in the old compiler that wasn't in the new one from Dennis. He logged into research, cd'ed to /usr/ken and did an ls -ld codenih, followed by a cd codenih. Was he surprised! Then he went back to a local machine and tried to login as root/codenih, which, of course, worked. He was even more surprised and told a number of colleagues, myself included. (I logged into research and printed out the source in /usr/ken/codenih. I was super impressed.) I think you misunderstood the codenih bit. As Ken had given us a (shared among a few of us) login, we had given him one. And Dick Haight refused him root access. And no one in PY had root access on research. So much for denying Ken root access on the PWB systems. Ken "infected" the PWB C compiler with codenih, which gave him free rein. I don't know how or when he first installed it, but I suspect he was aware of any extant security holes (e.g., the mv setuid root) to allow him to replace the compiler the first time. I don't know if the PWB crowd was the impetus for Ken writing codenih or if it was something he had used on others prior to us or if he ever used it on anyone else. Needless to say, Dick Haight was beside himself. I just thought it was a great feat of programming and was thrilled when he described it in CACM. Alan

3 years, 7 months

Re: [TUHS] Recreation of the PDP-7 UNIX TMG compiler compiler

by Douglas McIlroy

> I was deeply motivated by TMG. The good news is that you could say what > you wanted and it just did it. The bad news was the error handling. > Because it was recursive if you made a syntax error the program > backtracked and tried again. And again. And again. And eventually was > back at the first character of the input with nowhere to go. So it > issued one of its two messages -- "Syntax Error". This is somewhat of a caricature. If one's compilation strategy were to build an abstract syntax tree of the whole source program before emitting any object code, then things would go as Steve describes. In reality, TMG wasn't used this way. For one thing, ASTs needed too much memory. In TMG one could emit code while parsing. Typically code was generated on a statement-by-statement basis. This limited the backtracking, so even a naive "syntax error" diagnostic could be localized to the statement level. Long-distance connections, such as the branch labels in a nest of if statements, could nevertheless be realized recursively. Thus, in actual use, a TMG "grammar" was partly a parsing program and partly abstract specification. The balance of viewpoints was left to the discretion of the grammar's author. Yacc swung the pendulum toward the abstract. Doug

3 years, 7 months

> Who asked Ken for grep?

by Douglas McIlroy

I can say unequivocally that I asked Ken for grep, and the next day it was in /bin. But ... I understand now that grep already existed in /usr/ken/bin. My request was the last straw that tipped the balance from private to public. Hopefully Ken can answer whether he made it originally for himself or for Lee. Doug

3 years, 7 months

Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]

by Nelson H. F. Beebe

The discussions under this subject line have somewhat strayed from Unix heritage issues, but because several people have contributed views of assorted programming languages that mostly grew up on Unix-family systems, I decided to add this memory. Several years ago, I attended a talk by Dan McCracken (1930--2011), noted book author in computer areas, and VP and later President of the ACM (1978--1980). His talk was about programming languages, and was done in a question/answer format, with Dan offering both parts. He began: Q: In 10 years, which of the following programming languages will still be in use: Basic, Cobol, Fortran, PL/I, .... A: First of all, Basic is not a programming language. Then ... ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

3 years, 7 months

Fwd: Who asked Ken for grep?

by silas poulson

Hello, I tried asking question below awhile back - would anyone know the proper answer? Many Thanks, Silas > > Hello, > > Recently watched couple of videos[1][2] from Ken and Brian Kernighan > on the origin of grep. > > In [1], Brian suggests Lee McMahon asked Ken for grep to help with > federalist papers analysis. > > However Ken states in [2] that Doug Mcllroy asked for someway to “look > for things in files”. > > Is this just Brian misremembering or multiple people asking around similar > times? > > Many thanks, > Silas > > [1]Where GREP Came From - Computerphile > <youtube.com/watch?v=NTfOnGZUZDk> > > [2]VCF East 2019 -- Brian Kernighan interviews Ken Thompson > <https://www.youtube.com/watch?v=EY6q5dv_B-o>

3 years, 7 months

Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]

by Paul Ruizendaal

Here’s another angle on Perl, perhaps more on topic for TUHS. Let’s accept for a minute that Perl filled the void between C and shell scripts, and that there was a latent need for a scripting language like this on Unix. The shell, awk, sed, etc. had arrived at more or less fully formed versions by 1980. Perl (and TCL) did not appear until the very end of the 1980’s. What filled the gap in that decade, if anything? Ancient Unix has ‘bs’ https://en.wikipedia.org/wiki/Bs_(programming_language) but this seems to have had very little use. Paul

3 years, 7 months

Recreation of the PDP-7 UNIX TMG compiler compiler

by Phil Budne

I was a member of the team that typed in scans of PDP-7 UNIX (the first batch of scans done didn't include the shell, so I cobbled one together in March of 2016). Scans of a second batch of listings turned up and were entered two years ago (October 2019), including the original shell, and appeared to be part of Doug McIlroy's implementation of TMG (TransMoGrifier), the compiler compiler first used to implement B. In January 2020 we got confirmation that the files t1.s thru t8.s were, in fact, for TMG, but that we were missing the compiler for the TMGL language, written in TMGL and the generated code. In what is perhaps best described as a crazed act, over the past two months I've worked to recreate a working TMG environment on PDP-7 UNIX, including a B compiler in TMGL, currently available at: https://github.com/philbudne/pdp7-unix/tree/tmg A good starting place is https://github.com/philbudne/pdp7-unix/blob/tmg/misc/tmg-notes.txt which started as my collected notes, questions and findings, and I've expanded it with prose, observations and thoughts that could, at least conceivably, be of interest to those not as oriented towards self-punishment as I am. (and on that topic, if you're looking for someone to expand, contract, or otherwise deal with some seemingly intractable legacy code, let me know: http://www.regressive.org/phil/resume.html)

3 years, 7 months

Re: [TUHS] Book Recommendation

by Douglas McIlroy

>>I take credit as a go-between, not as an inventor. Ken Knowlton >>introduced the notation ABC in BEFLIX, a pixel-based animation >>language. > In BEFLIX, 'ABC' meant what, exactly? Offsets from pixel locations? It meant exactly what A->B->C means in C. Pixels had properties, represented in data structures. One valid data type was pointer. Incidentally, another BEFLIX innovation was the buddy system for dynamic storage allocation. Doug

3 years, 7 months

Re: [TUHS] Book Recommendation

by Douglas McIlroy

While waiting to see the full text, I've poked around the index for subjects of interest. It certainly is copious, and knows about a lot of things that I don't. The authors make a reasonable choice in identifying the dawn of "modern computing" with Eniac and relegating non-electronic machines to prehistory. Still, I was glad to find the prophetic Konrad Zuse mentioned, but disappointed not to find the Bell Labs pioneer, George Stibitz. Among programming languages, Fortran, which changed the nature of programming, is merely hinted at (buried in the forgettable Fortran Monitoring System), while its insignificant offspring PL/I is present. (Possibly this is an indexing oversight. John Backus, who led the Fortran project, is mentioned quite early in the book.) Algol, Lisp, Simula and Smalltalk quite properly make the list, but Basic rates more coverage than any of them. C, obscurely alphabetized as "C language", is treated generously, as is Unix in general. Surprisingly there's almost nothing in the index about security or privacy. The litany of whiggish chapters about various uses of computers needs a cautionary complement. "The computer attracts crooks and spies" would be a stylistically consistent title. Doug

3 years, 7 months

Re: [TUHS] Book Recommendation [ reallly inscrutable languages ]

by Douglas McIlroy

> My belief is that perl was written to replace a lot of Unix pipelines, I understand Perl's motive to have been a lot like PL/I's: subsume several popular styles of programming in one language. PL/I's ensemble wasn't always harmonious. Perl's was cacophony. Doug

3 years, 7 months

Re: [TUHS] Book Recommendation

by John Foust

At 11:00 AM 11/16/2021, Douglas McIlroy wrote: >>> The former notation C(B(A)) became A->B->C. This was PL/I's gift to C. > >> You seem to have a gift for notation. That's rare. Curious what you think of APL? > >I take credit as a go-between, not as an inventor. Ken Knowlton >introduced the notation ABC in BEFLIX, a pixel-based animation >language. In BEFLIX, 'ABC' meant what, exactly? Offsets from pixel locations? - John

3 years, 7 months

Speaking of groups: JHU Ownership

by Ron Natalie

A private message with Uh, Clem reminds me of another quaint piece of UNIX group history: JHU Ownership. The original V6 kernel and file systems used a char for UID and GID. This meant that you could only have 255 (plus the root user) distinct users on the machine. The JHU PDP-11/45 was used for the EE classes and we had more than that many users. The kernel was modified to check if the GID was 200 or greater. If it was, that was taken along with the UID to be part of the user identity. We gave all the class accounts such GIDs. Of course, we had to be careful about newgrp and fun and games with setuid/setgid (both the system call and the bits on the executables). I spent a lot of my time looking for exploits there and fixing them once I (or someone else) found them.

3 years, 7 months

Will someone please explain the history and usage of gpasswd / newgrp / sg?

by Grant Taylor

Hi, Will someone please explain the history and usage of gpasswd / newgrp / sg? I've run across them again recently while reading old Unix texts. I've been aware of them for years, but I've never actually used them for anything beyond kicking the tires. So I figured that I'd inquire of the hive mind that is TUHS / COFF. When was the concept of group passwords introduced? What was the problem that group passwords were the solution for? How common was the use of group passwords? I ran into one comment indicating that they used newgrp to work around a limitation in the number of (secondary) groups in relation to an NFS implementation. Specifically that the implementation of NFS they were using didn't support more than 16 groups. So they would switch their primary group to work around this limit. Does anyone have any interesting stories related to group passwords / gpasswd / newgrp / sg? -- Grant. . . . unix || die

3 years, 7 months

Double posting

by jnc＠mercury.lcs.mit.edu

Can people **please** send posts to one of these two lists, only? Having to go through and delete every other post (yeah, I know, I could relete _all_ messages to either list, since they are archived, but old habits are hard to break) is _really_ annoying. OK, I can see sending an _initial_ query to both lists, to get it to as wide a circle as possible: _but_ BCC at least one of them, to prevent lazy people just hitting 'reply all' and thereby sanding out multiple copies of their reply. Thank you. Noel

3 years, 7 months

Book Recommendation

by Clem Cole

I wanted to pass on a recommendation of a new book from MIT Press called: “A New History of Computing” by Thomas Haigh and Paul Cerruzzi, ISBN 978-0-262-54299-0 Full disclosure, I reviewed a bit of it for them and have been eagerly awaiting final publication. I do expect a lot of the readers of this mailing list will enjoy it. They did a super job researching it and it’s very complete and of course, interesting. FWIW: the work of a number people that are part of this list is nice chronicled. Clem -- Sent from a handheld expect more typos than usual

3 years, 7 months

First(?) C Reference Manual

by Alan Glasser

I have been looking for some time for a C Reference Manual from early 1973 (or late 1972) where Dennis comments that multiple array subscripts will eventually have Fortran-like syntax with commas separating rather than multiple sets of square brackets. That was the first C manual I had back when I first learned the language. Silly me, I discarded it when a newer one was issued, not realizing the historical significance of the earlier one. - Alan

3 years, 7 months

Re: [TUHS] macro returning a value?

by Douglas McIlroy

> Is there a trick to make a macro or string return a value? I know what you mean. Though a string does return a value, it can't compute an arithmetic result. Alternatively, a macro, which can use arithmetic, can only return the result as a distinct input line. (That might be overcome by a trick with \c, but I don't see one right off.) Though I have no useful advice about this dilemma, it does spur memories. I wrote the pre-Unix roff that was reimplemented on Unix and then superseded by Joe Ossanna's nroff. Joe introduced macros. Curiously, I had implemented macros in an assembler so early on (1959) that I have (incorrectly) been cited as the father of macros, yet it never occurred to me to put them in roff. Joe's work inspired me to add macros to pre-Unix roff. I did one thing differently. A macro could be called the usual way or it could be called inline like an nroff string. The only difference was that a macro's final newline was omitted when it was expanded inline. That implementation might have helped with the dilemma. Doug

3 years, 7 months

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