TUHS

tuhs@tuhs.org

30 participants
6496 discussions

by segaloco

Good morning all, currently trying to sort out one matter that still bewilders me with this documentation I'm working on scanning. So I've got two copies of the "Release 5.0" User's Manual and one copy of the "System V" User's Manual. I haven't identified the exact differences, lots of pages...but they certainly are not identical, there are at least a few commands in one and not the other. Given this, and past discussion, it's obvious Release 5.0 is the internal UNIX version that became System V, but what I'm curious about is if it was ever released publicly as "Release 5.0" before being branded as System V or if the name was System V from the moment the first commercial license was issued. The reason I wonder this is some inconsistencies in the documentation I see out there. So both of my Release 5.0 User's Manuals have the Bell logo on the front and no mention of the court order to cease using it. Likewise, all but one of the System V related documents I received recently contain a Bell logo on the cover next to Western Electric save for the Opeartor's Guide which curiously doesn't exhibit the front page divestiture message that other documents missing the Bell logo include. Furthermore, the actual cover sheet says "Operator's Guide UNIX System Release 5.0" so technically not System V. In fact, only the User's Manual, Administrator's Manual, Error Message Manual, Transition Aids, and Release Description specifically say System V, all the rest don't have a version listed but some list Release 5.0 on their title page. Furthering that discrepancy is this which I just purchased: https://www.ebay.com/itm/314135813726?_trkparms=amclksrc%3DITM%26aid%3D1110… Link lives as of this sending, but contains a closed auction for an Error Message Manual from the "Release 5.0" documentation line but no Bell logo. Until the Operator's Guide and this auction link, I haven't seen any "Release 5.0" branded stuff without a Bell logo, and before I bought the System V gold set, I hadn't seen System V branded stuff *with* the Bell logo. This shatters an assumption that I had made that at the same time the documentation branding shifted to System V was the same time the removal of the Bell logo happened, given that divestiture was what allowed them to aggressively market System V, but now this presents four distinct sets of System V gold documentation: Release 5.0 w/ Bell logo Release 5.0 w/o Bell logo System V w/ Bell logo System V w/o Bell logo I'm curious if anyone would happen to know what the significance here is. The covers are all printed, I can't see any indication that a bunch of 5.0 manuals were retroactively painted over nor that any System V manuals got stamped with a Bell post-production. What this means is "Release 5.0" documentation was being shipped post-divestiture and "System V" was being shipped pre-divestiture. If Release 5.0 was publicly sold as System V, then what explains the post-divestiture 5.0 manuals floating around in the wild, and vice versa, if USG couldn't effectively market and support UNIX until the divestiture, how is it so many "Release 5.0" documents are floating around in well produced commercial-quality binding, both pre and post-divestiture by the time the name "System V" would've been king. Were they still maintaining an internal 5.x branch past System V that warranted its own distinct documentation set even into the commercial period? This period right around '82-'83 is incredibly fascinating and I feel very under-documented. - Matt G.

2 years, 3 months

Three New Scans (Sys V User and Admin Guides, TS 4.0 Programmer's Package)

by segaloco

Good day everyone, just emailing to notify of three more documents I've uploaded to archive.org since my last slew of them: https://archive.org/details/unix-programming-starter-package - Up first is the UNIX Programming Starter Package. This is one of a pair of manuals that saw publication in the Bell system around the time of UNIX/TS 4.0. The documents here appear to be a subset of those which shipped with Documents for UNIX 4.0. Nothing particularly new here. There is a companion manual, UNIX Text Editing & Phototypesetting Starter Package, which I also have but haven't hit the scan bench with yet. Like this one, that is just a subset of papers from the Documents for UNIX collection. Based on the TOC, this second one also shipped with one of those PWB/MM multi-fold pamphlets, but didn't receive one when I got this. Luckily that was also scanned as part of the 4.0 collection. So nothing really new here, save that these are 1st generation scans vs the scans of photocopies for the 4.0 release. That said, I've seen this set with the same cover motif except with an AT&T death star logo in the upper right. Didn't look into it too much at the time, but I'd be curious if anyone might have those and if they have the programming one, if it still refers to Release 4.0 in the documentation roadmap. https://archive.org/details/unix-system-users-guide-release-5-0 - This is the User's Guide that shipped with Release 5.0/System V. This covers the usual suspects as well as some notes on RJE and SCCS from a user's perspective. https://archive.org/details/unix-system-administrators-guide-5-0 - And this is the Administrator's Guide likewise from SysV era. This one contains setup and maintenance notes for both DEC (PDP & VAX) and 3B20(S) machines, as well as papers on accounting, LP printing, RJE, filesystem checking, and the System Activity Package. Additionally, the guide includes the original Modification Request form. - Matt G.

2 years, 3 months

interesting case of not getting the point: dc on a mac

by ron minnich

dc >>> it prompts with '>>> ' wonder where that came from? First time I've seen it. Seems to have a certain lack of understanding attached to it.

2 years, 3 months

v8 shell

by Rob Pike

Found this tweetstream, here folded together, when looking for something else (now lost) in my twitter archive: ========== Things I miss from the v8 shell. 1) All shell output was valid shell input. 2) Typing dir/cmd would find the command $PATH/dir/cmd. Subdirectories of your bin, in other words. 3) Functions were exportable. For one brief shining POSIX meeting, that was true in POSIX too but then... 4) The implementation was lovely and easy to understand. (No, it wasn't shalgol. Bourne fixed that for us.) 5) That I could learn things from it, like how to write a recursive descent parser.* 6) It ran in cooked mode. As expected, all that work making it a great shell is lost to history. https://t.co/IzApAUSmzN is silent. Well, the code is released now. ========== -rob * elegantly.

2 years, 3 months

AIX moved into maintainance mode

by arnold＠skeeve.com

https://www.theregister.com/2023/01/17/unix_is_dead/ FYI. Arnold

2 years, 3 months

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

2 years, 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

2 years, 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

2 years, 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.

2 years, 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 >> ᐧ

2 years, 3 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