TUHS January 2023

tuhs@tuhs.org

84 participants
46 discussions

The death of general purpose computers -> COFF

by Warren Toomey

Hi all, can we move "The death of general purpose computers" to COFF now as it's not directly relevant to Unix. Thanks, Warren

1 year, 3 months

Managers/architects (was: AIX moved into maintainance mode)

by jnc＠mercury.lcs.mit.edu

> From: Larry McVoy <lm(a)mcvoy.com> > At least 30 years ago I said "He's good programmer, a good architect, > and a good manager. I've never seen that in one person before". Corby? Although he was just down the hall from me, I never saw him operating in any of those roles; maybe some of the old-time Unix people have some insight. Saltzer is about off-scale in #2; probably good as a manager (although I had a monumental blow-up with him in the hallway on the 5th floor, but I was pretty close to unmanageable when I was young ;-); he took over Athena when it was stumbling, and got it going. Dave Clark is high on all three - he could manage me! :-) Bob Taylor? PARC did some _incredibly_ important stuff in his time. Yes, I know a lot of the credit goes to those under him (Butler Lampson, Alan Kay - not sure if he was in Taylor's group, Boggs, Metcalfe, etc) but he had to manage them all. Not sure what his technical role was, though. Vint Cerf? Again, A1*** as a manager, but had some failings as a architect. I think the biggest share of the blame for the decision to remove the variable size addresses from TCP/IP3, and replace them with 32-bit addresses in TCP/IPv4, goes to him. (Alas, I was down the hall, not in the room, that day; I wasn't allowed in until the _next_ meeting. I like to think that if I'd been there, I could/would have pointed out the 'obvious' superior alternative - 'only length 4 must be supported at this time'.) Noel PS: ISTR that about a month ago someone was asking for management papers from that era (but I was too busy to reply); two good ones are: - F. J. Corbat��, C. T. Clingen, "A Managerial View of the Multics System Development" https://multicians.org/managerial.html - F. J. Corbat��, C. T. Clingen, and J. H. Saltzer, "Multics -- the first seven years" https://multicians.org/f7y.html

1 year, 3 months

Re: Managers/architects (was: AIX moved into maintainance mode)

by Douglas McIlroy

> My guess is that Ivan Sutherland probably qualified back when he still > programmed ... I mean, after all, he invented the linked list in order to > implement his thesis program (Sketchpad) in about 1960. I don't know whether Sutherland invented the linked list, but if he did, it had to be before he worked on sketchpad. I attended a lecture about Lisp in 1959 in which McCarthy credited list-processing to IPL-V, whose roots Newell places in 1954. Sketchpad ran on TX 0, which became operational in 1956. My nomination for a triple-threat computer guy is Vic Vyssotsky. A great programmer, he invented the first stream-processing language (BLODI) and bitwise-parallel dataflow analysis. As an architect, he invented the single underlying address space for multics. As a manager, he oversaw the building of and later ran the lab that became AT&T Research. Finally he founded the DEC Cambridge Lab. He was a subtle diplomat, too, who more than once engineered reversals of policy without ruffling feathers. Relative to linked lists, I remember Vic perceptively touting the then startling usage J=NEXT(J).in Fortran. Doug

1 year, 3 months

Re: AIX moved into maintainance mode (fwd)

by Steve Nickolas

Accidentally sent this only to the person I was replying to. > I am getting some grief on Twitter too for "omitting" FreeBSD. I > didn't, but the BSDs don't fit either definition of "Unix". The > pre-1993 one being "based on AT&T code" -- after all, BSD (4.4 Lite r2 > was it? Before my time!) -- went to a lot of effort to eliminate AT&T > code. From what I've seen it's very much a gradual transition; 4.3-Tahoe starts to have the new code and UCB copyright notices with the predecessor of what we call the "BSD License" appearing in some of the source files. Then with Reno, a majority of the userland is open-sourced, and Net/2 is fairly complete. (Net/2 and 4.4BSD-Lite / Lite/2 were lacking a few things.) But even right up until the end things were in a state of flux. A few things weren't finished until much later by the FreeBSD, OpenBSD and NetBSD people. -uso.

1 year, 3 months

Re: Maintenance mode on AIX

by Joseph J. Mankoski ***PSI***

Hello -- Regarding "appliance-ization" (locking down / dumbing down) of commercially-available computer systems, and returning to the history of Unix (in the context of our current era), I am reminded of Ken Thompson's (excellent and humorous) panel presentation at the ACM Turing 100 conference I attended in 2012, imagining Alan Turing being brought to our time and given a current-generation computer system, etc. The webcast links for the "Systems Architecture" session, etc., on the main conference site, https://turing100.acm.org/, seem to be broken, however the video at this link works for me: https://dl.acm.org/doi/10.1145/2322176.2322182 (Ken's part starts at ~0:09:28.) Cheers, ***PSI*** <<<psi(a)valis.com>>> tuhs-request(a)tuhs.org writes: [...] > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 18 Jan 2023 17:08:00 +0000 > From: segaloco <segaloco(a)protonmail.com> > Subject: [TUHS] Re: Maintenance mode on AIX > To: Clem Cole <clemc(a)ccc.com> > Cc: tuhs(a)tuhs.org > Message-ID: <zpdIicuX7AbN-y6hYho0eLOnHgzRs4iHa1UD6bxUyiTZhqZkg3Ha8TKWV > ASxWkDZitFw0JIopRVh7BRC2PzLFrF_Gjsb2yCi-uxJ3Yr3AtE=(a)protonmail.com> > Content-Type: multipart/alternative; > boundary="b1_7WKJsCnT0P2jggZLBLwbL2iRavDFXPykjXdIMPRs" > > Apple's unreasonable hardening has been the latest deterent to my ever wanting to use macOS as a personal driver. I've got a Mac as my daily driver for work, it can happily stay with work until I can decide how the filesystem is laid out and what folders I, as the root user, can and can't interact with from user land. I own my machine, not Apple. > > - Matt G. > ------- Original Message ------- > On Wednesday, January 18th, 2023 at 8:59 AM, Clem Cole <clemc(a)ccc.com> wrote: > >> On Wed, Jan 18, 2023 at 11:39 AM Larry McVoy <lm(a)mcvoy.com> wrote: >> >>> Someone once told me that if they had physical access to a Unix box, they >>> would get root. That has been true forever and it's even more true today, >>> pull the root disk, mount it on Linux, drop your ssh keys in there or add >>> a no password root or setuid a shell, whatever, if you can put your hands >>> on it, you can get in. >> >> A reasonable point, but I think it really depends on the UNIX implementation I suspect. Current mac OS is pretty well hardened from this, with their current enclaves and needing to boot home to Apple to get keys if things are not 100% right. Not saying you or I can not, but basically means the same cracking tricks you need to use for iPhones. It's not as easy as you describe. >> >> The ubiquitous Internet/WiFi changed the rules - as you can start to keep some set of keys somewhere else and then encrypt the local volumes. In fact, one of the things they do if mac OS boot detects that root has been modified (it has a crypto index stored away when it was made read-only), the boot rolls back to the last root snapshot -- since they are all read-only that works. In fact, it is a PITA to update/fix things like traditional scripts (for instance the scripts in the /etc/periodic area). Basically, they make it really unnatural to change the root files system, make a new snapshot and index (I have yet to see it documented although, with much pain, I previously created a procedure that is close -- i.e. it once worked on my pre-Ventura Mac - but currently -- fails, so I need to some more investigation when I can bring this back to the top of the importance/curiosity stack (I have a less than satisfying end around for now so I'm ignoring doing it properly). >> >> Clem >> ᐧ

1 year, 3 months

Burroughs funded $30,000 for a port to E-mode stack machine in 1983!

by ron minnich

I just stumbled across an old letter, from a VP of Burroughs to me and Steve Bartels, authorizing $30,000 for a port of Unix to the E-mode stack machine. I had forgotten getting it. Burroughs was famed for its stack machines. E-mode was a kind of last gasp attempt to save the stack architecture, which failed as far as I know, see this table: http://jack.hoa.org/hoajaa/Burr126b.html I worked as a hardware engineer on the A15. I also had been a Unix user for 7 years at that point and kept pointing out how awful the Burroughs CANDE time-sharing system was, and how much better Unix was. At some point I guess they asked me to put up or shut up. I got that money, and left Burroughs a week later for grad school. Funny note: A15 was Motorola ECL (MECL), and ran at 16 Mhz., considered fast at that time. We used a technique called "stored logic" which was, believe it or not, using MECL RAM to map logic inputs to outputs, i.e. implement combinational logic with SRAM. Kind of nuts, but it worked at the time. We also used a precursor of JTAG to scan it in. Those of you who know JTAG have some idea of how fun this had to be. One side effect of working with MECL is you realized just how well designed the TI 7400 SSI/MSI parts were ... MECL always just felt like an awkward family to design with. Another funny story, pointing to what was about to happen to Burroughs. We had an app that ran for hours on the stack machine. We quick ported it to a VAX, started it up, and headed out to lunch -- "this will take a while, let's go eat." We got to the front door and: "Oh, wait, let me hop back into the office,I forgot my jacket". And, noticed, the program was done in ... about 3 minutes. Not 8 hours. That's when we knew it was game over for Burroughs. If a picture of this letter would be useful in some archive somewhere, let me know, I can send it.

1 year, 3 months

In search of SunOS 4-era security advisory.

by Dan Cross

The security vulnerability in question could be briefly summarized as, "Fortran divide-by-zero gives root." I think that was just a specific manifestation of the underlying problem, though. More specifically it was actually due to failure to sanitize state after handling a SIGFPE (and possibly other signals as well?). I have a distinct memory of this, but can no longer find any evidence for it. Did I just make it up from whole cloth, or was this actually a thing? - Dan C.

1 year, 3 months

A few comments on porting the Bourne shell

by Paul Ruizendaal

London and Reiser report about porting the shell that “it required by far the largest conversion effort of any supposedly portable program, for the simple reason that it is not portable.” By the time of SysIII this is greatly improved, but also in porting the SysIII user land it was the most complex of the set so far. There were three aspects that I found noteworthy: 1. London/Reiser apparently felt strongly about a property of casts. The code argues that casting an l-value should not convert it into a r-value: <quote from "mode.h"> /* the following nonsense is required * because casts turn an Lvalue * into an Rvalue so two cheats * are necessary, one for each context. */ union { int _cheat;}; #define Lcheat(a) ((a)._cheat) #define Rcheat(a) ((int)(a)) <endquote> However, Lcheat is only used in two places (in service.c), to set and to clear a flag in a pointer. Interestingly, the 32V code already replaces one of these instances with a regular r-value cast. So far, I’d never thought about this aspect of casts. I stumbled across it, because the Plan 9 compiler did not accept the Lcheat expansion as valid C. 2. On the history of dup2 The shell code includes the following: <quote from “io.c”> rename(f1,f2) REG INT f1, f2; { #ifdef RES /* research has different sys calls from TS */ IF f1!=f2 THEN dup(f1|DUPFLG, f2); close(f1); IF f2==0 THEN ioset|=1 FI FI #else INT fs; IF f1!=f2 THEN fs = fcntl(f2,1,0); close(f2); fcntl(f1,0,f2); close(f1); IF fs==1 THEN fcntl(f2,2,1) FI IF f2==0 THEN ioset|=1 FI FI #endif } <endquote> I’ve check the 8th edition source, and indeed it supports using DUPFLG to signal to dup() that it really is dup2(). I had earlier wondered why dup2() did not appear in research until 10th edition, but now that is clear. It would seem that the dup of 8th edition is a direct ancestor to dup() in Plan 9. I wonder why this way of doing things never caught on in the other Unices. 3. Halfway to demand paging I stumbled across this one because I had a bug in my signal handling. From early days onwards, Unix supported dynamically growing the stack allocation, which arguably is a first step towards building the mechanisms for demand paging. It appears that the Bourne shell made another step, catching page faults and expanding the data/bss allocation dynamically: <quote from “fault.c”> VOID fault(sig) REG INT sig; { signal(sig, fault); IF sig==MEMF THEN IF setbrk(brkincr) == -1 THEN error(nospace); FI ELIF ... <endquote> This was already present in 7th edition, so it is by no means new in 32V or SysIII -- it had just escaped my attention as a conceptual step in the development of Unix memory handling.

1 year, 3 months

C with Classes reference manual

by Ron Natalie

Here’s a stretch, but does anybody have a copy of the 1982-ish C With Classes Reference Manual kicking around. I can take it in n/troff or a more modern format if you have it.

1 year, 3 months

Re: A few comments on porting the Bourne shell

by Douglas McIlroy

> segaloco via TUHS writes: >> I think that's a good point that scripting problems may be >> a symptom of the nature of the tools being used in them. > I think that you're hinting at something different. > To the best of my recollection, scripting languages were originally > intended and used for the automation of repetitive personal tasks; > making it easier for users who found themselves typing the same > stuff over and over again. Indeed! > Somewhere along the line people forgot > how to use a compiler and began writing large systems in a variety > of roughly equivalent but incompatible interpreted languages. Can > one even boot linux without having several different incompatible > versions of Python installed today? So I don't think that it's the > nature of the tools; I think that it's people choosing the wrong > tools for the problems that they're trying to solve. > Jon The forgotten compilers were typically used to supply glue to paste major tools together. The nature of that glue---often simple data reformatting--inspired tools like sed and awk. Each use of a tool became a process that saved many minutes of work that would in a scriptless world be guided by hand, boringly and unreliably. Yet glue processes typically did only microseconds of "real" work. In the name of efficiency, the operations began to be incorporated directly into the shell. The first inklings of this can be seen in "echo" and various forms of variable-substitution making their way into the v7 shell. The phenomenon proliferated into putting what were typically canned sed one-liners (but not sed itself) into the shell. Lots of specializations crowded out universality. A side effect was an explosion of knowledge required to write or understand code. Such is the tragedy of "forgetting compilers". Doug

1 year, 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 January 2023