TUHS

tuhs@tuhs.org

61 participants
6531 discussions

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

retro-fuse support for v7 filesystems

by Jay Logue

Just a quick note to announce that the retro-fuse project now supports mounting seventh-edition file systems for read and write on Linux and MacOS. As was done for v6, the project incorporates the actual filesystem code from v7 Unix, lightly modernized to run in user space on current systems. The code is available on github for anyone who's interested: https://github.com/jaylogue/retro-fuse --Jay

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