From lyndon at orthanc.ca Wed Jul 3 00:26:13 2024 From: lyndon at orthanc.ca (Lyndon Nerenberg (VE7TFX/VE6BBM)) Date: Tue, 02 Jul 2024 07:26:13 -0700 Subject: [TUHS] seismo/uunet uucp Message-ID: <8cf014a96b87b641@orthanc.ca> Does the source to the Rick Adams version of UUCP still exist anywhere? --lyndon From clemc at ccc.com Wed Jul 3 01:05:51 2024 From: clemc at ccc.com (Clem Cole) Date: Tue, 2 Jul 2024 11:05:51 -0400 Subject: [TUHS] seismo/uunet uucp In-Reply-To: <8cf014a96b87b641@orthanc.ca> References: <8cf014a96b87b641@orthanc.ca> Message-ID: What is particular are you looking for? (I could be wrong here) but I never kept it separately as but I had thought that Honeyman picked up Rick's changes for later versions of honey-dan-ber which I believe the last revision was part of SVR4. The last UUCP I ran was an SVR3-based version, but by the time of SVR4, I had stopped any active UUCP work since I had real IP network access. ᐧ On Tue, Jul 2, 2024 at 10:26 AM Lyndon Nerenberg (VE7TFX/VE6BBM) < lyndon at orthanc.ca> wrote: > Does the source to the Rick Adams version of UUCP still exist anywhere? > > --lyndon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lyndon at orthanc.ca Wed Jul 3 02:00:25 2024 From: lyndon at orthanc.ca (Lyndon Nerenberg (VE7TFX/VE6BBM)) Date: Tue, 02 Jul 2024 09:00:25 -0700 Subject: [TUHS] seismo/uunet uucp In-Reply-To: References: <8cf014a96b87b641@orthanc.ca> Message-ID: <8cf0151b4a0d863a@orthanc.ca> Clem Cole writes: > What is particular are you looking for? (I could be wrong here) but I > never kept it separately as but I had thought that Honeyman picked up > Rick's changes for later versions of honey-dan-ber What I'm particulary interested in is the last version of the original (not HDB) uucp that they ran on SunOS (or whatever followed -- I forget what OS they switched to afterwards). My curiosity is to see what changes he made vs. the V7/BSD versions. But I'm also looking for a well debugged version of the of the pre-HDB version to run on my own machines. With all the stupidity in SMTP mail these days, a bunch of us have been setting up private UUCP links to bypass all the middlebox nonsense and DMARC idiocy. I was never a fan of the HDB configuration style, so I'm looking for a rock solid implementation of Old School UUCP, and I figure the seiso/uunet code is as bullet proof as it gets. With that I can glue on TLS and we're good to go. --lyndon From rich.salz at gmail.com Wed Jul 3 02:32:23 2024 From: rich.salz at gmail.com (Rich Salz) Date: Tue, 2 Jul 2024 12:32:23 -0400 Subject: [TUHS] seismo/uunet uucp In-Reply-To: <8cf0151b4a0d863a@orthanc.ca> References: <8cf014a96b87b641@orthanc.ca> <8cf0151b4a0d863a@orthanc.ca> Message-ID: Almost definitely, anything Seismo/UUNET/Rick did would be passed back to CSRG. You're going to glue TLS to UUCP? You know it's interactive (two way) protocol, right? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lyndon at orthanc.ca Wed Jul 3 03:16:03 2024 From: lyndon at orthanc.ca (Lyndon Nerenberg (VE7TFX/VE6BBM)) Date: Tue, 02 Jul 2024 10:16:03 -0700 Subject: [TUHS] seismo/uunet uucp In-Reply-To: References: <8cf014a96b87b641@orthanc.ca> <8cf0151b4a0d863a@orthanc.ca> Message-ID: <8cf0159b519f1596@orthanc.ca> Rich Salz writes: > Almost definitely, anything Seismo/UUNET/Rick did would be passed back to > CSRG. But did it? I don't remember seeing it in any of the source trees I was monkeying with. Not that that means much. But I also don't remember ever seeing a non-gnu UUCP associated with any post-4.2 release. Thus leading back to my original question ... > You're going to glue TLS to UUCP? You know it's interactive (two way) > protocol, right? Yup. It's just wrapping the connection with TLS, ala https vs http. People have been doing it for decades (e.g. suucp in more tha a few /etc/services files). With HDB you can arrange this by doing some contortions in the Dialers file that make it call out to 'openssl s_client ...' IIRC. It has been a looong time ... --lyndon From tuhs at tuhs.org Wed Jul 3 03:28:35 2024 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Tue, 2 Jul 2024 12:28:35 -0500 Subject: [TUHS] seismo/uunet uucp In-Reply-To: <8cf0159b519f1596@orthanc.ca> References: <8cf014a96b87b641@orthanc.ca> <8cf0151b4a0d863a@orthanc.ca> <8cf0159b519f1596@orthanc.ca> Message-ID: <31c358e6-20d0-8997-29a9-87a58f3dd67b@tnetconsulting.net> On 7/2/24 12:16 PM, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > Yup. It's just wrapping the connection with TLS, ala https vs http. > People have been doing it for decades (e.g. suucp in more tha a few > /etc/services files). With HDB you can arrange this by doing some > contortions in the Dialers file that make it call out to 'openssl > s_client ...' IIRC. It has been a looong time ... Does the UUCP that you're working with have any concept of -> support TCP based connections? Or are you relying on external programs to dial TCP / TLS connections and similarly something else to host TCP / TLS connections and launch UUCP? -- Grant. . . . unix || die From rich.salz at gmail.com Wed Jul 3 04:05:47 2024 From: rich.salz at gmail.com (Rich Salz) Date: Tue, 2 Jul 2024 14:05:47 -0400 Subject: [TUHS] seismo/uunet uucp In-Reply-To: <8cf0159b519f1596@orthanc.ca> References: <8cf014a96b87b641@orthanc.ca> <8cf0151b4a0d863a@orthanc.ca> <8cf0159b519f1596@orthanc.ca> Message-ID: > > > Almost definitely, anything Seismo/UUNET/Rick did would be passed back to > > CSRG. > > But did it? > And how do you know S/U/R did any changes? Shrug. Not my hobby. Good luck. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Wed Jul 3 04:08:24 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 02 Jul 2024 12:08:24 -0600 Subject: [TUHS] seismo/uunet uucp In-Reply-To: <8cf0151b4a0d863a@orthanc.ca> References: <8cf014a96b87b641@orthanc.ca> <8cf0151b4a0d863a@orthanc.ca> Message-ID: <202407021808.462I8O4m920162@freefriends.org> "Lyndon Nerenberg (VE7TFX/VE6BBM)" wrote: > Clem Cole writes: > > > What is particular are you looking for? (I could be wrong here) but I > > never kept it separately as but I had thought that Honeyman picked up > > Rick's changes for later versions of honey-dan-ber > > What I'm particulary interested in is the last version of the > original (not HDB) uucp that they ran on SunOS (or whatever followed > -- I forget what OS they switched to afterwards). > > My curiosity is to see what changes he made vs. the V7/BSD versions. > But I'm also looking for a well debugged version of the of the > pre-HDB version to run on my own machines. With all the stupidity > in SMTP mail these days, a bunch of us have been setting up private > UUCP links to bypass all the middlebox nonsense and DMARC idiocy. > I was never a fan of the HDB configuration style, so I'm looking > for a rock solid implementation of Old School UUCP, and I figure > the seiso/uunet code is as bullet proof as it gets. > > With that I can glue on TLS and we're good to go. > > --lyndon Maybe check out GNU UUCP? I think it could use old style configuration files. Arnold From lyndon at orthanc.ca Wed Jul 3 04:56:37 2024 From: lyndon at orthanc.ca (Lyndon Nerenberg (VE7TFX/VE6BBM)) Date: Tue, 02 Jul 2024 11:56:37 -0700 Subject: [TUHS] seismo/uunet uucp In-Reply-To: <202407021808.462I8O4m920162@freefriends.org> References: <8cf014a96b87b641@orthanc.ca> <8cf0151b4a0d863a@orthanc.ca> <202407021808.462I8O4m920162@freefriends.org> Message-ID: <8cf016707d0c3986@orthanc.ca> arnold at skeeve.com writes: > Maybe check out GNU UUCP? I think it could use old style > configuration files. Come on, this is TUHS :-) I'm trying to resurrect the original code, not some newcomer clone :-) --lyndon From arnold at skeeve.com Wed Jul 3 05:14:30 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 02 Jul 2024 13:14:30 -0600 Subject: [TUHS] seismo/uunet uucp In-Reply-To: <8cf016707d0c3986@orthanc.ca> References: <8cf014a96b87b641@orthanc.ca> <8cf0151b4a0d863a@orthanc.ca> <202407021808.462I8O4m920162@freefriends.org> <8cf016707d0c3986@orthanc.ca> Message-ID: <202407021914.462JEUOd924962@freefriends.org> "Lyndon Nerenberg (VE7TFX/VE6BBM)" wrote: > arnold at skeeve.com writes: > > > Maybe check out GNU UUCP? I think it could use old style > > configuration files. > > Come on, this is TUHS :-) I'm trying to resurrect the original > code, not some newcomer clone :-) > > --lyndon Oh, sorry. I merely thought that you wanted to get something done and working. From reed at reedmedia.net Wed Jul 3 06:15:18 2024 From: reed at reedmedia.net (Jeremy C. Reed) Date: Tue, 2 Jul 2024 20:15:18 +0000 (UTC) Subject: [TUHS] seismo/uunet uucp In-Reply-To: <8cf014a96b87b641@orthanc.ca> References: <8cf014a96b87b641@orthanc.ca> Message-ID: <9639956-836c-24c4-8ac7-63d719bac5db@reedmedia.net> On Tue, 2 Jul 2024, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > Does the source to the Rick Adams version of UUCP still exist anywhere? See the CSRG SCCS archives. 4.3BSD has 5.6 85/06/24 4.4BSD has 8.1 93/06/06 2.9BSD-30aug85.gz has changes from rick at seismo.ARPA June 19, 1985 From clemc at ccc.com Wed Jul 3 07:58:12 2024 From: clemc at ccc.com (Clem Cole) Date: Tue, 2 Jul 2024 17:58:12 -0400 Subject: [TUHS] seismo/uunet uucp In-Reply-To: <202407021914.462JEUOd924962@freefriends.org> References: <8cf014a96b87b641@orthanc.ca> <8cf0151b4a0d863a@orthanc.ca> <202407021808.462I8O4m920162@freefriends.org> <8cf016707d0c3986@orthanc.ca> <202407021914.462JEUOd924962@freefriends.org> Message-ID: Lyndon, I just untar'ed "file6" of the 4.3BSD *.tap file from TUHS, which has the usr.bin sources (which include UUCP). This is clearly a BSD version but has been influenced by Honey-Dan-Ber. It seems to have the 't' protocol. [I did not look to see if it has the 'e' protocol, which was the earlier TCP over ethernet that I released from Masscomp about four years earlier and is also in UUNET Netnews Archives.] Given the comments about supporting Tymnet's NonPeak services, I feel pretty confident that this is post Rich Adam's work. Clem --- CHANGES FILE --- List of Changes to UUCP CHANGES 5.7 86/02/12 Added support for Eunice. Added new dialers: Racal Vadic 212 Racal Vadic 811 dialer with 831 adaptor Racal Vadic 820 dialer with 831 adaptor Racal Vadic MACS, 811 dialer with 831 adaptor Racal Vadic MACS, 820 dialer with 831 adaptor Dec DF112 4.2BSD style networking on top of tcp/ip ('t' protocol) X.25/PAD support ('f' protocol) Novation Penril Hayes 2400 Smartmodem Concord Data Systems CDS 224 ATT 2224 2400 baud modem Running uucico with debugging on requires read access to L.sys. If "NOSTRANGERS" is defined in uucp.h, the remote site must be in you L.sys or the call will be rejected. Lock files may be kept in a subdirectory if desired. STST files are kept in a subdirectory. CORRUPT subdirectory contains corrupted C. and X. files that could not be processed. (Instead of just exiting) You can specify a maximum grade to send either on the command line (-gX) or in the L.sys file (Any/C|Evening will only send class C [usually mail] or higher during the day and will send everything in the evening) See UUAIDS/L.sys for examples. L.sys (and any of the files in lib/uucp) can contain comments by putting a # as the first character on a line. Lines may be continued by placing a \ as the last character of the line. -R flag reverses role. (Lets the remote system be master first instead of slave) -L flag only calls "local" sites. Local sites are those sites having one of LOCAL,TCP or DIRECT in the ACU field of L.sys. If /etc/nologin is present (usually created by a graceful shutdown), uucico and uuxqt will gracefully exit instead of getting killed off when the system goes down. Does an exponential backoff on retry time if call fails instead of always waiting the default 5 minutes. The default may be overridden by adding ",TIME" to the time field in L.sys. e.g. "seismo Any,2" will use a default retry time of 2 minutes. If uucico receives a SIGFPE while running, it will toggle debugging on and off. Better status messages provided for uustat. New program uuq to give more decriptive information on status of jobs in uucp queue. Don't send files to remote system if it is returning out of temp space error. Correctly does the closing hangup sequence. condevs.c was broken into a file for each dialer in the directory aculib for much easier maintenance. Only try at most TRYCALLS to dial a site instead of one try for each dialer (lost big on systems with many dialers) Add ABORT sequence to the expect/send sequence so don't have to wait for timeout if can't get through dataswitch. e.g. noao Evening ACU 1200 6021234565 "" \d\r CLASS NOAOUUCP ABORT Down GO \d\r ogin:-\b-ogin: uucplogin word: uucppassword will only call noao in the evening (evening is defined by the phone rates). It will expect nothing and then wait 1 second (\d) and send a carriage return. Look for CLASS, then send NOAOUUCP. From then on, if it sees the word Down before finishing logging in, it will hang up immediately. In the mean time, it looks for GO and if it sees it, delays 1 second and sends a CR. Looks for ogin:, etc. This abort sequence is very useful if you must go through a dataswitch to get to the computer. The time field in L.sys now handles "Evening" and "Night" in addition to Any, Mo,Tu,We,Th,Fr,Sa,Su. Evening and Night are defined to be when the phone rates are cheaper. Evening = Wk1700-0800|Sa|Su Night = Any2300-0800|Sa|Su0800-1700 The expect/send code now supports: \s space \d delay 1 second \r carriage return with no linefeed \b break \c don't send a CR after these characters \xxx the octal character xxx (e.g. \s == \040 L-devices now handles "chat" scripts (like HoneyDanber) to get through local port selectors and smart modems more easily without mucking up every line of L.sys. See UUAIDs/L-devices for details. The 'g' protocol code was cleaned up a lot and is now almost readable. If you need a parity other than even (the default) to login to another system, you can change it in L.sys by putting in a sequence like "" P_ZERO (expect nothing, send zero parity). Odd Parity P_ODD Even Parity P_EVEN Zero Parity P_ZERO One Parity P_ONE If DONTCOPY is defined in uucp.h, uucp will not make a copy of the source file by default. (This is the way System 3 does it). If an X. request fails, the notification is returned to the originator of the request instead of "uucp" on the previous system. The man pages are actually accurate! If LOGBYSITE is defined, uucp logging is done with a log file per site instead of one LOGFILE. (Like Honey DanBer does) There is a new file (optional) L.aliases that makes life simpler when a site changes it's name. uucp, uux, uucico, etc all check it so when a site is renamed (e.g convex <- parsec) all you have to do is add an entry in L.aliases of the form: newname oldname uucico will not try and resend files it has already sent (when the files are specified in one C. file) Incorporated Bill Sebok's code to dial in and out on the same modem. NOTE: acucntrl is heavily Vax/4.xbsd specific and will require work to run on any other system. For compatibility with Honey DanBer, in the Date fields of L.sys, | was changed to , (| is supported, but not encouraged) , was changed to ; (to allow , to be the date seperator) For Honey DanBer compatibility, the Grade flag is now passed as -vgrade=X instead of the old -pX Don't truncate site names to 7 characters (truncate to 14 if anyone gets that absurd) for HDB compatibility. L.aliases may be used to map host with longer names in L.sys to 7 character names that some hosts send. Entries should be fullname 7-char-name You can specify a time for the expect send sequences with ~ instead of getting the default MAXMSGTIME. E.g. system Any ACU 1200 1234567 ogin~20-\r-ogin~10-\b-ogin user password pw will look for ogin for 20 seconds, send CR, look for ogin for 10 seconds, send a BREAK and look for ogin for MAXMSGTIME seconds Added code to support GTEs PC Pursuit service. It's mainly the handling of the dialback they use. Added time "NonPeak" for Tymnet/Telenet services that charge lower rates from 6pm-7am M-F and Sat & Sun. ᐧ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lyndon at orthanc.ca Wed Jul 3 10:17:58 2024 From: lyndon at orthanc.ca (Lyndon Nerenberg (VE7TFX/VE6BBM)) Date: Tue, 02 Jul 2024 17:17:58 -0700 Subject: [TUHS] seismo/uunet uucp In-Reply-To: References: <8cf014a96b87b641@orthanc.ca> <8cf0151b4a0d863a@orthanc.ca> <202407021808.462I8O4m920162@freefriends.org> <8cf016707d0c3986@orthanc.ca> <202407021914.462JEUOd924962@freefriends.org> Message-ID: <8cf0185c5a5d4392@orthanc.ca> Clem Cole writes: > I just untar'ed "file6" of the 4.3BSD *.tap file from TUHS, which has the > usr.bin sources (which include UUCP). Clem, that appears to be what I'm looking for. I thought 4.3 had already switched to gnu, so I never thought to look there. Thanks! --lyndon From sjenkin at canb.auug.org.au Wed Jul 3 14:51:01 2024 From: sjenkin at canb.auug.org.au (sjenkin at canb.auug.org.au) Date: Wed, 3 Jul 2024 14:51:01 +1000 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? Message-ID: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> I’ve never heard of a Computer Science or Software Engineering program that included a ‘case study’ component, especially for Software Development & Projects. MBA programs feature an emphasis on real-world ‘case studies’, to learn from successes & failures, to give students the possibility of not falling into the same traps. Creating Unix V6, because it profoundly changed computing & development, would seem an obvious Case Study for many aspects of Software, Coding and Projects. There have been many descriptive treatments of Initial Unix, but I’ve never seen a Case Study, with explicit lessons drawn, possibly leading to metrics to evaluate Project progress & the coding process. Developers of Initial Unix arguably were 10x-100x more productive than IBM OS/360, a ‘best practice’ development at the time, so what CSRC did differently is worth close examination. I’ve not seen examined the role of the ‘capability’ of individual contributors, the collaborative, collegiate work environment and the ‘context’, a well funded organisation not dictating deadlines or product specifications for researchers. USG, then USL, worked under ’normal commercial’ management pressure for deadlines, features and specifications. The CSRC/1127 group did have an explicit approach & principles for what they did and how they worked, publishing a number of books & papers on them - nothing they thought or did is secret or unavailable for study. Unix & Unix tools were deliberately built with explicit principles, such as “Less is More”. Plan 9 was also built on explicit Design principles. The two most relevant lessons I draw from Initial Unix are: - the same as Royce's original “Software Waterfall” paper, “build one to throwaway” [ albeit, many, many iterations of the kernel & other code ] - Writing Software is part Research, part Creative ‘Art’: It’s Done when it's Done, invention & creation can’t be timetabled. For the most reliable, widely used Open Source projects, the “Done when it’s Done” principle is universally demonstrated. I’ve never seen a large Open Source project succeed when attempting to use modern “Project Management” techniques. These Initial Unix lessons, if correct and substantiated, should cause a revolution in the teaching & practice of Professional Programming, i.e. Programming In the Large, for both CS & SW. There are inherent contradictions within the currently taught Software Project Management Methodologies: - Individual capability & ability is irrelevant The assumption is ‘programmers’ are fungible/ identical units - all equally able to solve any problem. Clearly incorrect: course evaluations / tests demonstrate at least a 100x variance in ability in every software dimension. - Team environment, rewards & penalties and corporate context are irrelevant, Perverse incentives are widely evident, the cause of many, or all, “Death Marches”. - The “Discovery & Research Phases” of a project are timetabled, an impossibility. Any suggestions for Case Studies gratefully accepted. =========== Professions & Professionals must learn over time: there’s a negative aspect (don’t do this) and positive aspect (do this) for this deliberate learning & improvement. Negatives are “Don’t Repeat, or Allow, Known Errors, Faults & Failures” plus in the Time Dimension, “Avoid Delays, Omissions and Inaction”. Positives are what’s taught in Case Studies in MBA courses: use techniques & approaches known to work. Early Unix, from inception to CACM papers, 1969 to 1974, took probably 30 man-years, and produced a robust, performant and usable system for it’s design target, “Software Development”. This in direct comparison to Fred Brooks IBM OS/360 effort around 5 years before that consumed 3,000-4,000 man-years was known for bugs, poor & inconsistent code quality, needed large resource to run and was, politely, non-performant. This was a commercial O/S, built by a capable, experienced engineering organisation, betting their company on it, who assigned their very best to the hardware & software projects. It was “Best of Breed” then, possibly also now. MULTICS had multiple business partners, without the same, single focus or commercial imperative. I don’t believe it’s comparable to either system. Initial Unix wasn’t just edit, compile & run, but filesystems, libraries, debugging & profiling tools, language & compiler construction tools, ‘man’ pages, document prep (nroff/troff) and 'a thousand' general tools leveraging shell / pipe. This led directly to modern toolchains, config, make & build systems, Version Control, packaging systems, and more. Nothing of note is built without using descendants or derivatives of these early toolchains. All this is wrapped around by many Standards, necessary for portable systems, even based on the same platform, kernel and base system. The “Tower of Babel” problem is still significant & insurmountable at times, even in C-C & Linux-Linux migration, but without POSIX/IEEE standards the “Software Tarpit” and "Desert of Despair” would’ve been unsolvable. The early Unix system proved adaptable and extensible to many other environments, well beyond “Software Development”. =========== [ waterfall model ] Managing the development of large software systems: concepts and techniques W. W. Royce, 1970 [ free access ] STEP3: DO IT TWICE, pg 334 After documentation, the second most important criterion for success revolves around whether the product is totally original. If the computer program in question is being developed for the first time, arrange matters so that the version finally delivered to the customer for operational deployment is actually the second version insofar as critical design/operations areas are concerned. =========== Plan 9, Design The view of the system is built upon three principles. First, resources are named and accessed like files in a hierarchical file system. Second, there is a standard protocol, called 9P, for accessing these resources. Third, the disjoint hierarchies provided by different services are joined together into a single private hierarchical file name space. The unusual properties of Plan 9 stem from the consistent, aggressive application of these principles. =========== Escaping the software tar pit: model clashes and how to avoid them Barry Boehm, 1999 [ free access ] =========== Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, 2nd Edition Fred Brooks Chapter 1. The Tar Pit Large-system programming has over the past decade been such a tar pit, and many great and powerful beasts have thrashed violently in it. =========== -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin From aek at bitsavers.org Wed Jul 3 15:02:39 2024 From: aek at bitsavers.org (Al Kossow) Date: Tue, 2 Jul 2024 22:02:39 -0700 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> Message-ID: <1b03f128-192f-4f46-4e76-50b68cd0e5af@bitsavers.org> On 7/2/24 9:51 PM, sjenkin at canb.auug.org.au wrote: > I’ve never seen a large Open Source project succeed when attempting to use modern “Project Management” techniques. > Managing an open source project is like herding a pack of alpha male tomcats with their own agendas that you can't fire. From arnold at skeeve.com Wed Jul 3 16:40:24 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 03 Jul 2024 00:40:24 -0600 Subject: [TUHS] seismo/uunet uucp In-Reply-To: <8cf0185c5a5d4392@orthanc.ca> References: <8cf014a96b87b641@orthanc.ca> <8cf0151b4a0d863a@orthanc.ca> <202407021808.462I8O4m920162@freefriends.org> <8cf016707d0c3986@orthanc.ca> <202407021914.462JEUOd924962@freefriends.org> <8cf0185c5a5d4392@orthanc.ca> Message-ID: <202407030640.4636eOk8970280@freefriends.org> "Lyndon Nerenberg (VE7TFX/VE6BBM)" wrote: > Clem Cole writes: > > > I just untar'ed "file6" of the 4.3BSD *.tap file from TUHS, which has the > > usr.bin sources (which include UUCP). > > Clem, that appears to be what I'm looking for. I thought 4.3 had > already switched to gnu, so I never thought to look there. > > Thanks! > > --lyndon As a matter of history, I don't think GNU UUCP existed that early. I could be wrong, but I don't think I am. Arnold From arnold at skeeve.com Wed Jul 3 16:46:10 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 03 Jul 2024 00:46:10 -0600 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <1b03f128-192f-4f46-4e76-50b68cd0e5af@bitsavers.org> References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> <1b03f128-192f-4f46-4e76-50b68cd0e5af@bitsavers.org> Message-ID: <202407030646.4636kAMZ970778@freefriends.org> Al Kossow wrote: > On 7/2/24 9:51 PM, sjenkin at canb.auug.org.au wrote: > > > I’ve never seen a large Open Source project succeed when attempting to use modern “Project Management” techniques. > > > > Managing an open source project is like herding a pack of alpha male tomcats with their own agendas that you can't fire. > > I think this is true only of the large projects. As Clem has argued, when there's a single strong leader, it's different (Linus, Guido van Rossum, bash and gawk are such examples). Arnold From a.phillip.garcia at gmail.com Wed Jul 3 19:04:42 2024 From: a.phillip.garcia at gmail.com (A. P. Garcia) Date: Wed, 3 Jul 2024 05:04:42 -0400 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> Message-ID: On Wed, Jul 3, 2024, 1:17 AM wrote: > I’ve never heard of a Computer Science or Software Engineering program > that included a ‘case study’ component, especially for Software > Development & Projects. > > > > Developers of Initial Unix arguably were 10x-100x more productive than IBM > OS/360, a ‘best practice’ development at the time, > so what CSRC did differently is worth close examination. > > I’ve not seen examined the role of the ‘capability’ of individual > contributors, the collaborative, collegiate work environment > and the ‘context’, a well funded organisation not dictating deadlines or > product specifications for researchers. > > I haven't heard of such a case study either. But you reminded me of an analogy I once read. Please forgive me if my memory is incorrect or incomplete. I believe I read it in the book "The Supermen", and the idea might be attributed to Seymour Cray. The basic idea was that any technical problem can be solved with a shovel, where the sharpness of the blade represents the astuteness of the people working on it, and the force applied to the handle is how much money you throw at it. A bit simplistic, perhaps, but I think there's also a lot of truth in it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From flexibeast at gmail.com Wed Jul 3 21:07:41 2024 From: flexibeast at gmail.com (Alexis) Date: Wed, 03 Jul 2024 21:07:41 +1000 Subject: [TUHS] "X Window System At 40" Message-ID: <87jzi2g2de.fsf@gmail.com> David Rosenthal reflects on his involvement with the development of the X Window System: > Although most of my time was spent developing NeWS, I rapidly > ported X version 10 to the Sun/1, likely the second port to > non-DEC hardware. It worked, but I had to kludge several areas > that depended on DEC-specific hardware. The worst was the > completely DEC-specific keyboard support. > > Because it was clear that a major redesign of X was needed to > make it portable and in particular to make it work well on Sun > hardware, Gosling and I worked with the teams at DEC SRC and WRL > on the design of X version 11. Gosling provided significant > input on the imaging model, and I designed the keyboard > support. As the implementation evolved I maintained the Sun port > and did a lot of testing and bug fixing. All of which led to my > trip to Boston to pull all-nighters at MIT finalizing the > release. > > My involvement continued after the first release. I was the > editor and main author of the X Inter-Client Communications > Conventions Manual (ICCCM) that forms Part III of Robert > Scheifler and Jim Gettys' X Window System. -- https://blog.dshr.org/2024/07/x-window-system-at-40.html Alexis. From clemc at ccc.com Thu Jul 4 00:04:58 2024 From: clemc at ccc.com (Clem Cole) Date: Wed, 3 Jul 2024 10:04:58 -0400 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <1b03f128-192f-4f46-4e76-50b68cd0e5af@bitsavers.org> References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> <1b03f128-192f-4f46-4e76-50b68cd0e5af@bitsavers.org> Message-ID: On Wed, Jul 3, 2024 at 1:02 AM Al Kossow wrote: > > > Managing an open source project is like herding a pack of alpha male > tomcats with their own agendas that you can't fire. > *i.e., *the Cathedral (*vs.* the bazaar) with a small group of people, like original, UNIX and Plan9 projects works better. Small is beautiful, particularly in a development team, but the principles of throwing one away and "*it is done when it is done*" have to be considered. FWIW: In the HW world, Seymour Cray said that the best HW development team has about 10-12 people and no more. Maybe there is someone who knows about real-world complex systems that can still be understood by a small number of designers. Of course, the problem today is that the systems are a few orders of magnitude more complex. There is no way a single human can comprehend every transistor in a modern processor, as Seymour did in the CDC and later Cray machines. The same is true for operating systems environments - although I think the >>kernel< can be, particularly if it's something more like Per Brinch Hansen's idea of a 'nucleus,' which I think you can argue is what Plan9 was and Unix V0-6 were pretty close to being. @steve jenkin FWIW: It also depends on how you measure "success." Both the original and derivatives of Linux and OS/360 can be considered "success" if you look at how they are used and their impact, particularly in a commercial setting. But in many ways, neither had (nor has had) an impact as the core *UNIX ideas* have on the industry/CS community at large. There was really little that was "new" in either OS/360 or Linux. Both were based on keeping SW developed for older systems working and offering new *attributes* (like not being AT&T copyright) and, eventually (later) some new features. Compare the fact that were not really novel with Plan9. While moving from an application from UNIX to Plan9 was possible, the designers decidedly broke from the past - such as making a uniform namespace and using 9P as the "glue layer." It turns out 9P could do many of the things that original UNIX layers could, so moving from a UNIX system was not a huge lift, but (as I understand it - Rob, please correct me if I have misinterpreted), it was not a goal to allow UNIX programs to be rebuilt with make(1) [or mk(1)] with no changes. That can not be said for OS/360 or Linux. In fact, if the programmer had followed Henry's 10 Programmers' Commandments, you could type: make and most programs coming from your vax or 68000 UNIX box - "just worked." Brooks and team considered it a requirement that older applications "just work" - which, in fact, was one of the reasons why, even though at the inception of the project, S/360 was designed to be IBM's first ASCII system [remember IBM and AT&T were the two primary sponsors of ASCII to ASA and IBM person chaired the committee]. EBCDIC was created so that those old codes could be supported and ended up being the path of least resistance when OS/360 was late. My point is that the cats appear after the fact. It is challenging to direct them towards your goals, not theirs. Thus, the 'benevolent dictator' model seems to appear in "successful" FOSS projects. I would argue with ers that this is actually the same Cathredal with a master builder making the choices, BTW. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Thu Jul 4 00:46:20 2024 From: norman at oclsc.org (Norman Wilson) Date: Wed, 3 Jul 2024 10:46:20 -0400 (EDT) Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? Message-ID: Steve Jenkin: I've never heard of a Computer Science or Software Engineering program that included a `case study' component, especially for Software Development & Projects. [...] Creating Unix V6, because it profoundly changed computing & development, would seem an obvious Case Study for many aspects of Software, Coding and Projects. ==== How about the course for which John Lions wrote his famous exegesis of the 6/e kernel? Norman Wilson Toronto ON From mrochkind at gmail.com Thu Jul 4 00:59:11 2024 From: mrochkind at gmail.com (Marc Rochkind) Date: Wed, 3 Jul 2024 08:59:11 -0600 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <1b03f128-192f-4f46-4e76-50b68cd0e5af@bitsavers.org> References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> <1b03f128-192f-4f46-4e76-50b68cd0e5af@bitsavers.org> Message-ID: Steve Jenkin suggests: "Developers of Initial Unix arguably were 10x-100x more productive than IBM OS/360..." Indeed, this is part of accepted UNIX lore. However, to me, "productivity" in this context is a measure of how much time it takes to implement a specified objective. UNIX did not have a specified objective. From "The UNIX Time Sharing System," (Ritchie & Thompson): "Perhaps paradoxically, the success of UNIX is largely due to the fact that it was not designed to meet any predefined objectives." So, does this productivity advantage really mean anything? It's comparing a research project to an industrial development. The UNIX development methodology would seem to be this: Get a very small number of top people together with a common vision, ideally fewer than three, and see what happens. However many mistakes were made on the OS/360 project (very completely documented by Brooks), the need for an OS for the emerging 360 series would probably not have been met by the "see what happens" approach. Marc On Wed, Jul 3, 2024 at 12:27 AM Al Kossow wrote: > On 7/2/24 9:51 PM, sjenkin at canb.auug.org.au wrote: > > > I’ve never seen a large Open Source project succeed when attempting to > use modern “Project Management” techniques. > > > > Managing an open source project is like herding a pack of alpha male > tomcats with their own agendas that you can't fire. > > > -- *My new email address is mrochkind at gmail.com * -------------- next part -------------- An HTML attachment was scrubbed... URL: From katolaz at freaknet.org Thu Jul 4 01:17:38 2024 From: katolaz at freaknet.org (Vincenzo Nicosia) Date: Wed, 3 Jul 2024 15:17:38 +0000 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> Message-ID: On Wed, Jul 03, 2024 at 02:51:01PM +1000, sjenkin at canb.auug.org.au wrote: > I???ve never heard of a Computer Science or Software Engineering program > that included a ???case study??? component, especially for Software Development & Projects. > > MBA programs feature an emphasis on real-world ???case studies???, to learn from successes & failures, > to give students the possibility of not falling into the same traps. > > Creating Unix V6, because it profoundly changed computing & development, > would seem an obvious Case Study for many aspects of Software, Coding and Projects. > I personally believe that the comparison of "mainstream" software development principles and the birth and development of projects like Unix, Linux, or any other major successful free software project is fundamentally flawed. The programmers considered as "fungible workforce" by mainstream software engineering and project management theories are *paid* to to their programming job, and they mostly have to carry that job over working on prescribed objectives and timelines which have been decided by somebody else, managers who know nothing at all about software development. Personal interest in the project, passion, motivation, curiosity, creative power, sense of beauty, the joy of belonging to a community of likeminded people, are never part of the equation, at any point. Remove one of those latter ingredients from Unix, Linux, or any other major successful free/open source software project, and that project would have not existed, at all. I think it would be terribly misleading to teach young CS students that software projects should be managed "as Unix v6 came to life". They will never, ever find anything even close to that environment in a professional workplace. We should tell them that some of the most beautiful software projects ever crafted by humans did not come out of the "professionalism churches" that the overwhelming majority of software companies are nowadays, based on the blind application of "mainstream" software development and project management principles, according to which they (the CS majors) are just "as fungible and replaceable as a chair, or a wallpaper". That would be only true and fair to tell them. I don't know if that would be of any avail to them, but at least we do not mislead them in thinking that their paid programming time will actually change the world in any meaningful way..... My2cents Enzo Nicosia -- From tytso at mit.edu Thu Jul 4 01:22:14 2024 From: tytso at mit.edu (Theodore Ts'o) Date: Wed, 3 Jul 2024 11:22:14 -0400 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> <1b03f128-192f-4f46-4e76-50b68cd0e5af@bitsavers.org> Message-ID: <20240703152214.GA961016@mit.edu> On Wed, Jul 03, 2024 at 10:04:58AM -0400, Clem Cole wrote: > On Wed, Jul 3, 2024 at 1:02 AM Al Kossow wrote: > > Managing an open source project is like herding a pack of alpha male > > tomcats with their own agendas that you can't fire. > > > *i.e., *the Cathedral (*vs.* the bazaar) with a small group of people, like > original, UNIX and Plan9 projects works better. > > Small is beautiful, particularly in a development team, but the > principles of throwing one away and "*it is done when it is done*" have to > be considered. This. It's more about the scope of the project. I had a work project (a new form of SMR disks where you can dynamically convert regions of disk platters from CMR to SMR non-destructively with respect to the region of the disk not being converted) where I was herding cats from multiple different product areas (departments): hardware platforms, software infrastructure, software reliability engineers) reporting to different VP's with different departmental OKR's for which they get their performance reviews. I also had to wrangle two different HDD manufacturer partners, and a T.13 standards subcommittee, and my skills trying to hold together a team where I had no management authority, nor a VP to glower threateningly behind me, stood me in very good stead. Fortunately leadership stints that I had in the open source world, the IETF, USENIX, and the Episcopal Diocese of Massachusetts meant that this weasn't the first time to do this kind of cat herding. Small might be beautiful, but this project reduced storage TCO costs by vast amounts of money, so my company thought it was really pretty. :-) > My point is that the cats appear after the fact. It is challenging to > direct them towards your goals, not theirs. Thus, the 'benevolent dictator' > model seems to appear in "successful" FOSS projects. I would argue with ers > that this is actually the same Cathredal with a master builder making the > choices, BTW. In essentially all volunteer projects, a leader's only real power is to say "no". They can't force anyone to do anything that they want, but instead have to rely on their skills of pursuation. This is true if you are an open source leader, or if you are an IETF Area Director. In the case of a non-profit which has money, such as (for example) Usenix or the Episcopal Diocese of Massachusetts, or the Linux Foundation, you might have some ability to issue commands to the staff. But the vast majority of the work of these non-profits rely on volunteers, and so again, you have to be able to pursuade those volunteers community to follow you when you say, "let's go thataway". The organizations which are lucky enough to have such servant leaders will tend to prosper. OTOH, open source projects which spend huge amounts of time fighting over who has CVS commit access, leading to factions of developers to fork off to form rival projects, will tend to be less successful. There are lots of people who will complain about Linus Torvalds' supposed lack of social skills; but his ability to hold the senior members of the development community together without having the sorts of splits that we saw in FreeBSD, NetBSD, OpenBSD, DragonflyBSD, etc., should be a hint that the story is a bit more complicated than what is promulgated by the click-baity headlines out there. - Ted From lm at mcvoy.com Thu Jul 4 01:36:00 2024 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 3 Jul 2024 08:36:00 -0700 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <20240703152214.GA961016@mit.edu> References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> <1b03f128-192f-4f46-4e76-50b68cd0e5af@bitsavers.org> <20240703152214.GA961016@mit.edu> Message-ID: <20240703153600.GA26356@mcvoy.com> On Wed, Jul 03, 2024 at 11:22:14AM -0400, Theodore Ts'o wrote: > There are lots of people who will complain > about Linus Torvalds' supposed lack of social skills; but his ability > to hold the senior members of the development community together > without having the sorts of splits that we saw in FreeBSD, NetBSD, > OpenBSD, DragonflyBSD, etc., should be a hint that the story is a bit > more complicated than what is promulgated by the click-baity headlines > out there. This. I recognized this in Linus decades ago and it's why I switched to Linux. I was a BSD (aka SunOS) guy big time and I left that because of what I saw in Linus. I miss BSD a little but am quite happy with Linux. Say what you will about his rough edges, he's held it together for a long time. Kudos. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From marc.donner at gmail.com Thu Jul 4 01:35:50 2024 From: marc.donner at gmail.com (Marc Donner) Date: Wed, 3 Jul 2024 11:35:50 -0400 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> Message-ID: There have been case study courses here and there over the years. I would argue that Lyons’s book of sources was the text for one. An old crony, Ed Smith, used to teach a comparative programming languages course back in the day. And I know someone at NYU taught a course where people studied the source code of a variety of utilities. ===== nygeek.net mindthegapdialogs.com/home On Wed, Jul 3, 2024 at 11:27 AM Vincenzo Nicosia wrote: > On Wed, Jul 03, 2024 at 02:51:01PM +1000, sjenkin at canb.auug.org.au wrote: > > I???ve never heard of a Computer Science or Software Engineering program > > that included a ???case study??? component, especially for Software > Development & Projects. > > > > MBA programs feature an emphasis on real-world ???case studies???, to > learn from successes & failures, > > to give students the possibility of not falling into the same traps. > > > > Creating Unix V6, because it profoundly changed computing & development, > > would seem an obvious Case Study for many aspects of Software, Coding > and Projects. > > > > I personally believe that the comparison of "mainstream" software > development principles and the birth and development of projects like > Unix, Linux, or any other major successful free software project is > fundamentally flawed. > > The programmers considered as "fungible workforce" by mainstream > software engineering and project management theories are *paid* to to > their programming job, and they mostly have to carry that job over > working on prescribed objectives and timelines which have been decided > by somebody else, managers who know nothing at all about software > development. Personal interest in the project, passion, motivation, > curiosity, creative power, sense of beauty, the joy of belonging to a > community of likeminded people, are never part of the equation, at any > point. > > Remove one of those latter ingredients from Unix, Linux, or any other > major successful free/open source software project, and that project > would have not existed, at all. > > I think it would be terribly misleading to teach young CS students that > software projects should be managed "as Unix v6 came to life". They will > never, ever find anything even close to that environment in a > professional workplace. We should tell them that some of the most > beautiful software projects ever crafted by humans did not come out of > the "professionalism churches" that the overwhelming majority of > software companies are nowadays, based on the blind application of > "mainstream" software development and project management principles, > according to which they (the CS majors) are just "as fungible and > replaceable as a chair, or a wallpaper". That would be only true and > fair to tell them. > > I don't know if that would be of any avail to them, but at least we do > not mislead them in thinking that their paid programming time will > actually change the world in any meaningful way..... > > My2cents > > Enzo Nicosia > > -- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aek at bitsavers.org Thu Jul 4 01:37:18 2024 From: aek at bitsavers.org (Al Kossow) Date: Wed, 3 Jul 2024 08:37:18 -0700 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> Message-ID: <805f0ceb-c327-aaad-a13f-cfb3aab5c528@bitsavers.org> On 7/3/24 8:17 AM, Vincenzo Nicosia wrote: > I think it would be terribly misleading to teach young CS students that > software projects should be managed "as Unix v6 came to life". They will > never, ever find anything even close to that environment in a > professional workplace. We should tell them that some of the most > beautiful software projects ever crafted by humans did not come out of > the "professionalism churches" that the overwhelming majority of > software companies are nowadays, based on the blind application of > "mainstream" software development and project management principles, > according to which they (the CS majors) are just "as fungible and > replaceable as a chair, or a wallpaper". That would be only true and > fair to tell them. > I was inside Apple for a LONG time, and if you were going to write a horror story case history, the Mac OS would be it, right through the death march that occurred during the OS X transition (bringing this around to Unix history). You don't hear anything about the people past the "Magnificent Seven" of the original Mac team. There were many and many people were burned out in the process, including almost all of the original team one way or another. From clemc at ccc.com Thu Jul 4 01:45:50 2024 From: clemc at ccc.com (Clem Cole) Date: Wed, 3 Jul 2024 11:45:50 -0400 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: Message-ID: On Wed, Jul 3, 2024 at 10:46 AM Norman Wilson wrote: > Steve Jenkin: > > I've never heard of a Computer Science or Software Engineering program > that included a `case study' component, especially for Software > Development & Projects. > > [...] > > How about the course for which John Lions wrote his famous > exegesis of the 6/e kernel? > > Norman Wilson > Toronto ON This >>might<< be far from an OS >>developer<< perspective [*i.e*., for a practitioner of SW development for an OS]. However, I'm quite sure it is the same thing. In Lion's case, he looks at the code and final system in the same manner to examine the technical output/result (a complete timesharing system than in "modest HW", that a single person could understand as it was less than 9000 KLOCs). This is like an architecture class might take apart drawings of Notre Dame Cathedral to examine how the structure was developed to carry such huge loads of stone, wood, and lead but still allow so much light in the building (such as the class on my CMU roommates who became a restoration architect for buildings like 30th Street Station in Philadelphia). Case studies (which originated at HSB and are now de rigor in most B-schools) look at the choices made, given a set of initial conditions to create a (business) result [positively and negatively]. What could be learned from the conditions, choices, and results so that feature (business) leaders can recognize what might not be obvious? The idea is that you are teaching managers about choices that change/predict a future outcome. This is not the same as field practitioners trying to make a structure/machine/program to >>operate<< to do some design function. So, the place where a case study for SW projects (using books like Mythical Man Month) would be helpful is an in-software engineering course. Writing an HSB style case for something like UNIX, or Tenex or maybe Oracle; particularly to compared to something like Brook's book would be fascinating to read, I'm not sure Lion's text qualifies. I think the content of such a "case" would be quite different. Again, it comes back to what "success" is. If success is defined as winning the market, OS/360 was a huge success, as was DOS. But neither would I consider a success from the standpoint of building something that future generations of programmers would want to learn to emulate. ᐧ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Jul 4 01:52:30 2024 From: clemc at ccc.com (Clem Cole) Date: Wed, 3 Jul 2024 11:52:30 -0400 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: Message-ID: s/be far/be fair/ Sorry, Grammerly rewrote that and I missed it with my dyslexia. ᐧ ᐧ On Wed, Jul 3, 2024 at 11:45 AM Clem Cole wrote: > > > On Wed, Jul 3, 2024 at 10:46 AM Norman Wilson wrote: > >> Steve Jenkin: >> >> I've never heard of a Computer Science or Software Engineering program >> that included a `case study' component, especially for Software >> Development & Projects. >> >> [...] >> >> How about the course for which John Lions wrote his famous >> exegesis of the 6/e kernel? >> >> Norman Wilson >> Toronto ON > > This >>might<< be far from an OS >>developer<< perspective [*i.e*., for a > practitioner of SW development for an OS]. However, I'm quite sure it is > the same thing. In Lion's case, he looks at the code and final system in > the same manner to examine the technical output/result (a complete > timesharing system than in "modest HW", that a single person could > understand as it was less than 9000 KLOCs). This is like an architecture > class might take apart drawings of Notre Dame Cathedral to examine how the > structure was developed to carry such huge loads of stone, wood, and lead > but still allow so much light in the building (such as the class on my CMU > roommates who became a restoration architect for buildings like 30th Street > Station in Philadelphia). Case studies (which originated at HSB and are > now de rigor in most B-schools) look at the choices made, given a set of > initial conditions to create a (business) result [positively and > negatively]. What could be learned from the conditions, choices, and > results so that feature (business) leaders can recognize what might not be > obvious? The idea is that you are teaching managers about choices > that change/predict a future outcome. This is not the same as field > practitioners trying to make a structure/machine/program to >>operate<< to > do some design function. > > So, the place where a case study for SW projects (using books like > Mythical Man Month) would be helpful is an in-software engineering course. > Writing an HSB style case for something like UNIX, or Tenex or maybe > Oracle; particularly to compared to something like Brook's book would be > fascinating to read, I'm not sure Lion's text qualifies. I think the > content of such a "case" would be quite different. > > Again, it comes back to what "success" is. If success is defined as > winning the market, OS/360 was a huge success, as was DOS. But neither > would I consider a success from the standpoint of building something that > future generations of programmers would want to learn to emulate. > ᐧ > ᐧ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aek at bitsavers.org Thu Jul 4 02:01:09 2024 From: aek at bitsavers.org (Al Kossow) Date: Wed, 3 Jul 2024 09:01:09 -0700 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <805f0ceb-c327-aaad-a13f-cfb3aab5c528@bitsavers.org> References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> <805f0ceb-c327-aaad-a13f-cfb3aab5c528@bitsavers.org> Message-ID: <06704bb6-f699-8407-5d73-bf2777374ca3@bitsavers.org> > On 7/3/24 8:17 AM, Vincenzo Nicosia wrote: > >> I think it would be terribly misleading to teach young CS students that >> software projects should be managed "as Unix v6 came to life". They will >> never, ever find anything even close to that environment in a >> professional workplace. Also, it is unlikely they will ever bootstrap an operating system from scratch. No company would invest its resources doing so when they can find something for free that will be "good enough". It isn't even likely they will implement any major new libraries or compilers and will just use what is out there already. Again, a project "make vs buy" even if the "buy" is free as in beer. From imp at bsdimp.com Thu Jul 4 02:05:00 2024 From: imp at bsdimp.com (Warner Losh) Date: Wed, 3 Jul 2024 10:05:00 -0600 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <06704bb6-f699-8407-5d73-bf2777374ca3@bitsavers.org> References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> <805f0ceb-c327-aaad-a13f-cfb3aab5c528@bitsavers.org> <06704bb6-f699-8407-5d73-bf2777374ca3@bitsavers.org> Message-ID: On Wed, Jul 3, 2024 at 10:01 AM Al Kossow wrote: > > On 7/3/24 8:17 AM, Vincenzo Nicosia wrote: > > > >> I think it would be terribly misleading to teach young CS students that > >> software projects should be managed "as Unix v6 came to life". They will > >> never, ever find anything even close to that environment in a > >> professional workplace. > Also, it is unlikely they will ever bootstrap an operating system from > scratch. > No company would invest its resources doing so when they can find something > for free that will be "good enough". > It isn't even likely they will implement any major new libraries or > compilers > and will just use what is out there already. Again, a project "make vs buy" > even if the "buy" is free as in beer. > Yea, even in the 80s when I was in school, the CS department switched from running the HW simulator on the HW in question, and we had to write everything to bring up the HW on the DEC-20 (well, simplified DEC-20) to linking in your code to the SunOS kernel on the 68k Sun3 machines that were plentiful and doing the debugging on real hardware. I'm not sure there's a lot of students that have done a full, from scratch, bootstrap of a real OS (or even a Toy one) these days... Though a lot of activity there has shifted to the cheap embedded world where it's easy to write a bare-metal app that has many of the features of an OS, but in some weird, specialized way. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Thu Jul 4 02:12:27 2024 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Wed, 3 Jul 2024 12:12:27 -0400 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: Message-ID: <350fe2bf-7d72-4486-abd3-275550bd66da@case.edu> On 7/3/24 11:45 AM, Clem Cole wrote: > So, the place where a case study for SW projects (using books like Mythical > Man Month) would be helpful is an in-software engineering course.Writing an > HSB style case for something like UNIX, or Tenex or maybe Oracle; > particularly to compared to something like Brook's book would be > fascinating to read, I'm not sure Lion's text qualifies. TENEX is a fascinating story.[1] An internal BBN project with a hardware component, written by maybe half a dozen people.[2] It spread around the country to research institutions kind of like Unix. DEC liked it so much it bought TENEX and hired Dan Murphy away from BBN to turn it into TOPS-20.[3] [1] https://opost.com/tenex/tenex72.txt [2] https://walden-family.com/bbn/10-SYS/ [3] https://opost.com/tenex/hbook.html CWRU was a big DEC-20/TOPS-20 shop, and TOPS-20 was the first OS I used when I started working for the computing center as a student (which evolved into where I work today). I loved TOPS-20. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From nobozo at gmail.com Thu Jul 4 03:39:35 2024 From: nobozo at gmail.com (Jon Forrest) Date: Wed, 3 Jul 2024 10:39:35 -0700 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> Message-ID: <8dd2489a-69da-4a0a-bf54-b2dc54bc7215@gmail.com> On 7/3/24 8:35 AM, Marc Donner wrote: > There have been case study courses here and there over the years.  I > would argue that Lyons’s book of sources was the text for one.  An old > crony, Ed Smith, used to teach a comparative programming languages > course back in the day.  And I know someone at NYU taught a course where > people studied the source code of a variety of utilities. In the late 70s or early 80s there was an OS class at UC Santa Barbara taught by John Bruno that used the Lions books of V6 Unix sources and commentary. He had to go through some kind of special efforts to get the books. Jon From tuhs at tuhs.org Thu Jul 4 03:49:29 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 03 Jul 2024 17:49:29 +0000 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <8dd2489a-69da-4a0a-bf54-b2dc54bc7215@gmail.com> References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> <8dd2489a-69da-4a0a-bf54-b2dc54bc7215@gmail.com> Message-ID: On Wednesday, July 3rd, 2024 at 10:39 AM, Jon Forrest wrote: > > On 7/3/24 8:35 AM, Marc Donner wrote: > > > There have been case study courses here and there over the years. I > > would argue that Lyons’s book of sources was the text for one. An old > > crony, Ed Smith, used to teach a comparative programming languages > > course back in the day. And I know someone at NYU taught a course where > > people studied the source code of a variety of utilities. > > > In the late 70s or early 80s there was an OS class at UC Santa Barbara > taught by John Bruno that used the Lions books of V6 Unix sources and > commentary. He had to go through some kind of special efforts to > get the books. > > Jon I'm curious, if such a work was produced not from original specimens of the Bell Laboratories Sixth Edition source code, but rather someone sitting with a PDP-11 disassembler and meticulously stepping over the code, would publishing a work based on the latter analysis run afoul of the same legal circumstances as what John Lions published in the 70s? I do have a pointed reason to ask: one of my long term goals is to write a case-study-type analysis of a Famicom/NES title, in other words, a John Lions-esque work based on one of my disassemblies of such a title. The intention is to not only step through the (disassembled, not original) source code of a real world game and explain in detail precisely how it operates but also draw connections to other titles by the same development team and the historical conditions of the game's production. I haven't seen such a work focused on a video game, and it's something I always wanted to sink my teeth into as a beginner, so my hope is I can use what I've learned over the years to provide for others what I once wanted in the past. Something complicating the matter is console video games aren't licensed quite like operating systems or software utilities, it's typically an "All Rights Reserved" sort of situation rather than a lengthy license expounding on user rights, at least in my experience. Anywho, curious what folks think, whether disassembly of a work a user does have license to (and of which the license makes no statement on reverse engineering/disassembly) can then be used by fair use or some other claim in an expository, non-commercial work. - Matt G. P.S. On the note of old UNIX reverse engineering ideas, is anyone aware of any early (early 80s and back) attempts to produce something akin to a C decompiler, something that could effectively analyze assembly produced by a C compiler and make a good guess as to what C made it up based on calling conventions, stack frames, known optimization techniques, etc? From fair-tuhs at netbsd.org Thu Jul 4 04:16:45 2024 From: fair-tuhs at netbsd.org (Erik E. Fair) Date: Wed, 03 Jul 2024 11:16:45 -0700 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <8dd2489a-69da-4a0a-bf54-b2dc54bc7215@gmail.com> Message-ID: <18463.1720030605@cesium.clock.org> >Date: Wed, 03 Jul 2024 17:49:29 +0000 >From: segaloco via TUHS > >P.S. On the note of old UNIX reverse engineering ideas, is anyone aware of any early (early 80s and back) attempts to produce something akin to a C decompiler, something that could effectively analyze assembly produced by a C compiler and make a good guess as to what C made it up based on calling conventions, stack frames, known optimization techniques, etc? Yes: Dave Pare produced a C decompiler to analyze and fix bugs in PSL's (binary distribution only) "Empire" game, and that set of tools was subsequently used to analyze the Morris Worm in 1988. https://www.empire.cx/newssept1694.html#interview https://www.quora.com/What-was-it-like-to-experience-the-Morris-Worm/answer/Erik-Fair Erik Fair From rich.salz at gmail.com Thu Jul 4 05:58:45 2024 From: rich.salz at gmail.com (Rich Salz) Date: Wed, 3 Jul 2024 15:58:45 -0400 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> <8dd2489a-69da-4a0a-bf54-b2dc54bc7215@gmail.com> Message-ID: I would be careful of disassembly in the United States. There are laws about that; the Digital Millennium Copyright Act, probably others. -------------- next part -------------- An HTML attachment was scrubbed... URL: From als at thangorodrim.ch Thu Jul 4 06:17:13 2024 From: als at thangorodrim.ch (Alexander Schreiber) Date: Wed, 3 Jul 2024 22:17:13 +0200 Subject: [TUHS] seismo/uunet uucp In-Reply-To: References: <8cf014a96b87b641@orthanc.ca> <8cf0151b4a0d863a@orthanc.ca> Message-ID: On Tue, Jul 02, 2024 at 12:32:23PM -0400, Rich Salz wrote: > Almost definitely, anything Seismo/UUNET/Rick did would be passed back to > CSRG. > > You're going to glue TLS to UUCP? You know it's interactive (two way) > protocol, right? Wrapping UUCP in stunnel isn't exactly rocket science - and my mail has been flowing through this for more than 20 years ;-) Kind regards, Alex. -- "Opportunity is missed by most people because it is dressed in overalls and looks like work." -- Thomas A. Edison From tuhs at tuhs.org Thu Jul 4 08:03:56 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 03 Jul 2024 22:03:56 +0000 Subject: [TUHS] Is There Teletype DNA In the Blit? Message-ID: I suppose this question is best directed at Rob or Doug, but just might as well ask at large: Given AT&T's ownership of Teletype and the involvement (AFAIK) of Teletype with other WECo CRT terminals (e.g. Dataspeed 40 models), was there any direct involvement of folks from the Teletype side of things in the R&D on the Jerq/Blit/DMD? Or was this terminal pure Bell Labs? - Matt G. From dave at horsfall.org Thu Jul 4 09:15:17 2024 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 4 Jul 2024 09:15:17 +1000 (EST) Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> Message-ID: > I would argue that Lyons’s book of sources was the text for one. Sigh... Can people please spell his name correctly? It's Lions, not Lyons (he was one of my lecturers, OK?). -- Dave From marc.donner at gmail.com Thu Jul 4 09:23:43 2024 From: marc.donner at gmail.com (Marc Donner) Date: Wed, 3 Jul 2024 19:23:43 -0400 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> Message-ID: Apologies … I was shooting from memory … my copy is not where I am. ===== nygeek.net mindthegapdialogs.com/home On Wed, Jul 3, 2024 at 7:15 PM Dave Horsfall wrote: > > I would argue that Lyons’s book of sources was the text for one. > > Sigh... Can people please spell his name correctly? It's Lions, not > Lyons (he was one of my lecturers, OK?). > > -- Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From rik at rikfarrow.com Thu Jul 4 09:26:21 2024 From: rik at rikfarrow.com (Rik Farrow) Date: Wed, 3 Jul 2024 16:26:21 -0700 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> Message-ID: Although off-topic, except by including Lions: twice in the early 80s, a programmer handed me a binder with the Lions book as a several generations old xerox copy. It was always in the programmer/engineer part of a warehouse (like Morrow), and it was handed to me as if it were something illegal. I guess it was. Rik On Wed, Jul 3, 2024 at 4:15 PM Dave Horsfall wrote: > > I would argue that Lyons’s book of sources was the text for one. > > Sigh... Can people please spell his name correctly? It's Lions, not > Lyons (he was one of my lecturers, OK?). > > -- Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrochkind at gmail.com Thu Jul 4 09:29:26 2024 From: mrochkind at gmail.com (Marc Rochkind) Date: Wed, 3 Jul 2024 17:29:26 -0600 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> Message-ID: On Wed, Jul 3, 2024 at 9:27 AM Vincenzo Nicosia wrote: > ... > > The programmers considered as "fungible workforce" by mainstream > software engineering and project management theories are *paid* to to > their programming job, and they mostly have to carry that job over > working on prescribed objectives and timelines which have been decided > by somebody else, managers who know nothing at all about software > development. Personal interest in the project, passion, motivation, > curiosity, creative power, sense of beauty, the joy of belonging to a > community of likeminded people, are never part of the equation, at any > point. > > What a cynical take on software development! The logical error is to assume that if something is sometimes true (e.g., " managers who know nothing at all about software development") then it is always true. My experience over many decades is quite different. Most often, managers know software quite well. Where they fail is in their very poor understanding of how to manage people. The bias that operates in software development, and perhaps all organizations, is that when there is a disagreement between management and non-management (e.g., programmers), the non-managers usually assume that they are always right and the managers are wrong. I have never met a programmer or group of programmers who were always right. Most often, they are ignorant of financing, regulatory constraints, product schedules, commitments, staffing issues, and everything else that isn't coding. (There are exceptions, but they are uncommon.) Management, by definition, is the art and science of using resources to reach an objective. Programmers generally are concerned only with themselves as a resource and with their own personal programming objective. It is unusual to find a programmer who understands management. Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.branden.robinson at gmail.com Thu Jul 4 09:35:42 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Wed, 3 Jul 2024 18:35:42 -0500 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> <1b03f128-192f-4f46-4e76-50b68cd0e5af@bitsavers.org> Message-ID: <20240703233542.ceq73fqdlbgntrgg@illithid> At 2024-07-03T08:59:11-0600, Marc Rochkind wrote: > Steve Jenkin suggests: "Developers of Initial Unix arguably were > 10x-100x more productive than IBM OS/360..." > > Indeed, this is part of accepted UNIX lore. That claim reminds me of a more general one. Applied to software development writ large, it seems to be lore, not a reproducible scientific result. I refer of course to Sackman, Erickson, and Grant's 1968 CACM paper which documented a DARPA experiment that found a productivity range of 28:1 in their sample of programmers (with veterans of 7 years' experience pitted against "trainees"). Naturally enough, plenty of people who make claims about variance in programmer productivity are unaware of this paper's existence; it's not actually relevant to them as a source of knowledge. https://web.archive.org/web/20120204023412/http://dustyvolumes.com/archives/497 Thomas Dickey, better known today as the maintainer of ncurses, xterm, lynx, and mawk (all for 30 years or more, and among other projects), published a critique of this study in 1981. https://web.archive.org/web/20120204023555/http://dustyvolumes.com/archives/498 Bill Curtis published a critique of the Sackler et al. paper in 1988. I quote (via Dickey): "Sackman's ... message that substantial performance differences do exist among programmers remains valid. Detecting a 20+:1 range ratio depends upon having one brilliant and one horrid performance in a sample. However the range ratio is not a particularly stable measure of performance variability among programmers. The dispersions of such data as appear in Table I are better represented by such measures as the standard deviation or semiinterquartile range." https://invisible-island.net/personal/paperstuff.html We have likely all observed how this 28:1 ratio has bloated in retelling over time, like the length of a fish catch, to 100:1 or even 1000:1. Similarly we're all familiar with the common practice of presenting the mean and sometimes the range of some data sample to support one's argument, without mentioning the median or mode, let alone the variance (or the standard deviation). (If a member of one's audience is familiar with non-Gaussian distributions and inquires whether one's sample may be better characterized by one, you invite them to disengage from the discussion.) I assert that this "productivity gap" is a myth, and that it persists because it serves the purposes of diverse audiences who adopt it with motivated reasoning. 1. Immature Unix enthusiasts like to reassure themselves, and others nearby, of their inherent superiority to rival programmers. 2. Managers like to contrive reasons for (not) promoting individual contributors. It's easy to cite this productivity "statistic" and then suggest, without indicating anything concrete, that an employee is either a rock star or a mediocrity. 3. Directors in organizations like not having to further justify a "stack-rank and cut" approach to reducing salary and benefits as a proportion of operational expenditures. https://en.wikipedia.org/wiki/Vitality_curve 4. Business culture in general is deeply wedded to the idea that individual productivity, merit, or capacity for "wealth creation" is variable by several orders of magnitude, because this claim "justifies" variance in compensation over a similarly large range, even among college-educated professionals in an organization, setting aside those members of staff whose collars shade more toward blue. (Outsourcing is useful in increasing opacity, segregating workers, and setting them up to have conflicting interests.) If people start applying their capacity for critical thought to the proposition that the CEO is 40,000 times more productive than a "Software Engineer II", nothing good will happen. _Is_ "productivity" among programmers, however defined and measured, nonuniform? Likely yes. Has our industry studied the question in a serious way, applying rigorous experimental design and statistical analysis? Perhaps not. And if we did, would any of the people making this claim read or comprehend the research if it didn't support their biases? You already know the answer. We utter myths about falsifiable propositions not because we care about their truth values, but precisely because we don't. Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From g.branden.robinson at gmail.com Thu Jul 4 09:50:27 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Wed, 3 Jul 2024 18:50:27 -0500 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> Message-ID: <20240703235027.kkg27bhvniifijsb@illithid> Getting in before the COFF boom lowers... :-O At 2024-07-03T17:29:26-0600, Marc Rochkind wrote: > > The programmers considered as "fungible workforce" by mainstream > > software engineering and project management theories are *paid* to > > to their programming job, and they mostly have to carry that job > > over working on prescribed objectives and timelines which have been > > decided by somebody else, managers who know nothing at all about > > software development. Personal interest in the project, passion, > > motivation, curiosity, creative power, sense of beauty, the joy of > > belonging to a community of likeminded people, are never part of the > > equation, at any point. > > What a cynical take on software development! There's some truth to it. But I'd agree that it is not the whole story. > The logical error is to assume that if something is sometimes true > (e.g., "managers who know nothing at all about software development") > then it is always true. Yes, and this fallacy is a popular one among almost any sample of humans one takes. > My experience over many decades is quite different. Most often, > managers know software quite well. Where they fail is in their very > poor understanding of how to manage people. This aligns closely with my experience. Often the worst managers I've had were those who had the best programming "chops". > The bias that operates in software development, and perhaps all > organizations, is that when there is a disagreement between management > and non-management (e.g., programmers), the non-managers usually > assume that they are always right and the managers are wrong. An obvious solution to this sort of problem, long held to be inherently horrific, is to cultivate a more mature perspective on management, and skill at performing it, by having workers manage themselves. One often finds this insight at or near the heart of "revolutionary" approaches to software development like Agile or Lean, sometimes under many layers of obfuscation to avoid alarming MBAs and others whose career plans from adolescence involved going directly into professional management from university. That solution is, of course, worker self-management. > I have never met a programmer or group of programmers who were always > right. Most often, they are ignorant of financing, regulatory > constraints, product schedules, commitments, staffing issues, and > everything else that isn't coding. (There are exceptions, but they > are uncommon.) Indeed. One way to overcome this ignorance and produce more exceptions is to educate one's staff in these very phenomena. I won't digress on why this doesn't often happen in practice. It doesn't take much imagination, or professional experience, to reason it out. > Management, by definition, is the art and science of using resources > to reach an objective. Stated this broadly, programmers solve management problems all the time. Mightn't their skills "port"? > Programmers generally are concerned only with themselves as a > resource and with their own personal programming objective. If I s/Programmers/People/;s/progamming//, then I find this statement no less true. Cooperators and defectors appear in every aspect of life. > It is unusual to find a programmer who understands management. As noted, a solution exists. But it is an unpalatable one to those touted, by themselves or others, as "thought leaders". Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From pugs78 at gmail.com Thu Jul 4 10:03:42 2024 From: pugs78 at gmail.com (Tom Lyon) Date: Wed, 3 Jul 2024 17:03:42 -0700 Subject: [TUHS] Lions book reprint by Bell Labs Message-ID: The fabulous Dr. Honeyman made a gift to me of his Lions' books which were printed by Bell Labs. Does anyone know WHEN that happened or WHO made it happen? I figure it must have been at least 1 year and maybe 2 after Lions' originals. See Images: https://drive.google.com/file/d/1BIs3Qsihp6nI2iX1Ax3fNU-OFv5dfy0O/view?usp=sharing https://drive.google.com/file/d/1LoQUl8ND7D18z1W5I3NF-QwIvDkfXk0t/view?usp=drive_link https://drive.google.com/file/d/1xg4TAJNAp5h8FljulJh9Zh0nzFy-YWda/view?usp=sharing https://drive.google.com/file/d/1u--blfYu5Iuzpc-qiwCGNq0p6u1DgucR/view?usp=sharing ps. *I* have no problem spelling Lions' name. A problem *with* the spelling, perhaps. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsg at jsg.id.au Thu Jul 4 11:00:07 2024 From: jsg at jsg.id.au (Jonathan Gray) Date: Thu, 4 Jul 2024 11:00:07 +1000 Subject: [TUHS] Lions book reprint by Bell Labs In-Reply-To: References: Message-ID: On Wed, Jul 03, 2024 at 05:03:42PM -0700, Tom Lyon wrote: > The fabulous Dr. Honeyman made a gift to me of his Lions' books which were > printed by Bell Labs. Does anyone know WHEN that happened or WHO made it > happen? > > I figure it must have been at least 1 year and maybe 2 after Lions' > originals. "One night in 1978 John received a telephone call from Doug McIlroy at Bell Laboratories saying that they would like to assume responsibility for distributing the notes". Berny Goodheart, in the back of the peer-to-peer version, "About the author". change in distribution was mentioned by John Lions in ;login: March 1978 https://archive.org/details/login_march-1978/page/n1/mode/2up > > See Images: > https://drive.google.com/file/d/1BIs3Qsihp6nI2iX1Ax3fNU-OFv5dfy0O/view?usp=sharing > https://drive.google.com/file/d/1LoQUl8ND7D18z1W5I3NF-QwIvDkfXk0t/view?usp=drive_link > https://drive.google.com/file/d/1xg4TAJNAp5h8FljulJh9Zh0nzFy-YWda/view?usp=sharing > https://drive.google.com/file/d/1u--blfYu5Iuzpc-qiwCGNq0p6u1DgucR/view?usp=sharing > > ps. *I* have no problem spelling Lions' name. A problem *with* the > spelling, perhaps. From jsg at jsg.id.au Thu Jul 4 11:36:55 2024 From: jsg at jsg.id.au (Jonathan Gray) Date: Thu, 4 Jul 2024 11:36:55 +1000 Subject: [TUHS] Lions book reprint by Bell Labs In-Reply-To: References: Message-ID: On Thu, Jul 04, 2024 at 11:00:07AM +1000, Jonathan Gray wrote: > On Wed, Jul 03, 2024 at 05:03:42PM -0700, Tom Lyon wrote: > > The fabulous Dr. Honeyman made a gift to me of his Lions' books which were > > printed by Bell Labs. Does anyone know WHEN that happened or WHO made it > > happen? > > > > I figure it must have been at least 1 year and maybe 2 after Lions' > > originals. > > "One night in 1978 John received a telephone call from > Doug McIlroy at Bell Laboratories saying that they would like to > assume responsibility for distributing the notes". > > Berny Goodheart, in the back of the peer-to-peer version, > "About the author". also in tuhs Documentation/AUUGN/AUUGN-V16.5.pdf p 15 "One night (sometime in 1978?), I had a phone call from Doug McIlroy saying BTL would like to assume responsibility for distributing these documents, and would I agree? I did. It saved me much work." > > change in distribution was mentioned by John Lions in > ;login: March 1978 > https://archive.org/details/login_march-1978/page/n1/mode/2up > > > > > See Images: > > https://drive.google.com/file/d/1BIs3Qsihp6nI2iX1Ax3fNU-OFv5dfy0O/view?usp=sharing > > https://drive.google.com/file/d/1LoQUl8ND7D18z1W5I3NF-QwIvDkfXk0t/view?usp=drive_link > > https://drive.google.com/file/d/1xg4TAJNAp5h8FljulJh9Zh0nzFy-YWda/view?usp=sharing > > https://drive.google.com/file/d/1u--blfYu5Iuzpc-qiwCGNq0p6u1DgucR/view?usp=sharing > > > > ps. *I* have no problem spelling Lions' name. A problem *with* the > > spelling, perhaps. > From johnl at taugh.com Thu Jul 4 11:53:23 2024 From: johnl at taugh.com (John Levine) Date: 3 Jul 2024 21:53:23 -0400 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> Message-ID: <20240704015323.7EEE88EBE798@ary.qy> According to : >Developers of Initial Unix arguably were 10x-100x more productive than IBM OS/360, a ‘best practice’ development at the time, >so what CSRC did differently is worth close examination. Ken Thompson was an astonishingly productive programmer. I don't think you can build a business plan that starts with "hire someone like Ken." One weekend just for fun he pounded out most of an APL interpreter, which I then took and spent a month part time adding a few features like saving and loading workspaces, and adjusting it to use the APL character set on our funky bitmap terminals at Yale. He did more in the weekend than I did in the month, and I am not a terrible programmer. From tuhs at tuhs.org Thu Jul 4 12:59:33 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 04 Jul 2024 02:59:33 +0000 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <20240704015323.7EEE88EBE798@ary.qy> References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> <20240704015323.7EEE88EBE798@ary.qy> Message-ID: <-xc_VtRQ7D8ll__tVJJEF4MXsGZF-vvAKLrh2Oq0lPKemGXIS1XAQLNs0vumI1_OZ_0UO0LjdImMHuijnPJe_R-3neo-2ZwT4l_L3hLOTLU=@protonmail.com> On Wednesday, July 3rd, 2024 at 6:53 PM, John Levine wrote: > According to sjenkin at canb.auug.org.au: > > > Developers of Initial Unix arguably were 10x-100x more productive than IBM OS/360, a ‘best practice’ development at the time, > > so what CSRC did differently is worth close examination. > > > Ken Thompson was an astonishingly productive programmer. I don't think > you can build a business plan that starts with "hire someone like > Ken." > > One weekend just for fun he pounded out most of an APL interpreter, > which I then took and spent a month part time adding a few features > like saving and loading workspaces, and adjusting it to use the APL > character set on our funky bitmap terminals at Yale. He did more in > the weekend than I did in the month, and I am not a terrible > programmer. To add to the praise, Ken, yourself, and others weren't exactly working on modern 115200 baud terminal emulators and IDEs with all the fancy modern tab completion and automatic linting either. History has given me an appreciation that these sorts of conveniences work at all. If I'm ever having a really bad day with my tools, I just think about Ken, Dennis, et. al. hammering away at 33 ASRs making legends happen and suddenly I don't feel so bad. - Matt G. From robpike at gmail.com Thu Jul 4 16:53:17 2024 From: robpike at gmail.com (Rob Pike) Date: Thu, 4 Jul 2024 16:53:17 +1000 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <-xc_VtRQ7D8ll__tVJJEF4MXsGZF-vvAKLrh2Oq0lPKemGXIS1XAQLNs0vumI1_OZ_0UO0LjdImMHuijnPJe_R-3neo-2ZwT4l_L3hLOTLU=@protonmail.com> References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> <20240704015323.7EEE88EBE798@ary.qy> <-xc_VtRQ7D8ll__tVJJEF4MXsGZF-vvAKLrh2Oq0lPKemGXIS1XAQLNs0vumI1_OZ_0UO0LjdImMHuijnPJe_R-3neo-2ZwT4l_L3hLOTLU=@protonmail.com> Message-ID: I liked working with Ken. One fond memory was porting Plan 9 to the SPARC over Christmas break. People went home, we hacked, Bonnie brought us food. A week later people came back and we had a new architecture up and running, pretty much in toto. (The way the system worked made this a joy to do - so much just worked right away, including for example the ps command.) One whole day of that was dealing with register windows, which brought nothing to the table but trouble, and forced us to use R1 as the stack pointer register. That was not the fondest day. Architecture people: please just let me pretend your CPU is like a PDP-11. No surprises, OK? I'll handle the complaints about irrelevance in the modern age. -rob On Thu, Jul 4, 2024 at 12:59 PM segaloco via TUHS wrote: > > On Wednesday, July 3rd, 2024 at 6:53 PM, John Levine wrote: > > > According to sjenkin at canb.auug.org.au: > > > > > Developers of Initial Unix arguably were 10x-100x more productive than IBM OS/360, a ‘best practice’ development at the time, > > > so what CSRC did differently is worth close examination. > > > > > > Ken Thompson was an astonishingly productive programmer. I don't think > > you can build a business plan that starts with "hire someone like > > Ken." > > > > One weekend just for fun he pounded out most of an APL interpreter, > > which I then took and spent a month part time adding a few features > > like saving and loading workspaces, and adjusting it to use the APL > > character set on our funky bitmap terminals at Yale. He did more in > > the weekend than I did in the month, and I am not a terrible > > programmer. > > To add to the praise, Ken, yourself, and others weren't exactly working on modern 115200 baud terminal emulators and IDEs with all the fancy modern tab completion and automatic linting either. History has given me an appreciation that these sorts of conveniences work at all. If I'm ever having a really bad day with my tools, I just think about Ken, Dennis, et. al. hammering away at 33 ASRs making legends happen and suddenly I don't feel so bad. > > - Matt G. From katolaz at freaknet.org Thu Jul 4 18:23:50 2024 From: katolaz at freaknet.org (Vincenzo Nicosia) Date: Thu, 4 Jul 2024 08:23:50 +0000 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> Message-ID: On Wed, Jul 03, 2024 at 05:29:26PM -0600, Marc Rochkind wrote: > On Wed, Jul 3, 2024 at 9:27???AM Vincenzo Nicosia > wrote: > > > ... > > > > The programmers considered as "fungible workforce" by mainstream > > software engineering and project management theories are *paid* to to > > their programming job, and they mostly have to carry that job over > > working on prescribed objectives and timelines which have been decided > > by somebody else, managers who know nothing at all about software > > development. Personal interest in the project, passion, motivation, > > curiosity, creative power, sense of beauty, the joy of belonging to a > > community of likeminded people, are never part of the equation, at any > > point. > > > > [cut] > > I have never met a programmer or group of programmers who were always > right. Most often, they are ignorant of financing, regulatory constraints, > product schedules, commitments, staffing issues, and everything else that > isn't coding. (There are exceptions, but they are uncommon.) Management, by > definition, is the art and science of using resources to reach an > objective. Programmers generally are concerned only with themselves as a > resource and with their own personal programming objective. It is unusual > to find a programmer who understands management. > I agree my view is cynical. Maybe that's because I cannot find anything romantic or poetic in "financing, regulatory constraints, product schedules, commitments, staffing issues, and everything else that isn't coding". Maybe because I have learned on experience that those things are just there to ensure that the clients pay their invoices, while they rarely contribute to anything durable, well-engineered, great, or beautiful. Anything that can be considered a truly good case study of software development. But I am sure I am just too cynical here :) HND Enzo -- From marc.donner at gmail.com Thu Jul 4 23:00:13 2024 From: marc.donner at gmail.com (Marc Donner) Date: Thu, 4 Jul 2024 09:00:13 -0400 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <20240703233542.ceq73fqdlbgntrgg@illithid> References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> <1b03f128-192f-4f46-4e76-50b68cd0e5af@bitsavers.org> <20240703233542.ceq73fqdlbgntrgg@illithid> Message-ID: Back in the mid-to-late 1980s I was the ringleader of the UNIX underground at IBM Research. Interestingly, we were for a couple of years the largest non-academic customer for Sun Microsystems on the east coast of the US. When IBM bought ROLM, a maker of telephone equipment, they were confronted with ROLM's insistence on using Sun equipment (and UNIX in general) for their software development. So a stream of IBM executives made their way to my office in Yorktown Heights to try to figure out whether this demand was for real. I would show them my development environment (emacs and make plus a bunch of ancillary tools) and demonstrate how I could edit code, build, test, and debug quickly and smoothly. After half a dozen VPs came through, they agreed and placed a large order with Sun for ROLM. That might have helped the business case for a better AIX, but I'm not sure. ===== nygeek.net mindthegapdialogs.com/home On Wed, Jul 3, 2024 at 7:35 PM G. Branden Robinson < g.branden.robinson at gmail.com> wrote: > At 2024-07-03T08:59:11-0600, Marc Rochkind wrote: > > Steve Jenkin suggests: "Developers of Initial Unix arguably were > > 10x-100x more productive than IBM OS/360..." > > > > Indeed, this is part of accepted UNIX lore. > > That claim reminds me of a more general one. Applied to software > development writ large, it seems to be lore, not a reproducible > scientific result. > > I refer of course to Sackman, Erickson, and Grant's 1968 CACM paper > which documented a DARPA experiment that found a productivity range of > 28:1 in their sample of programmers (with veterans of 7 years' > experience pitted against "trainees"). Naturally enough, plenty of > people who make claims about variance in programmer productivity are > unaware of this paper's existence; it's not actually relevant to them as > a source of knowledge. > > > https://web.archive.org/web/20120204023412/http://dustyvolumes.com/archives/497 > > Thomas Dickey, better known today as the maintainer of ncurses, xterm, > lynx, and mawk (all for 30 years or more, and among other projects), > published a critique of this study in 1981. > > > https://web.archive.org/web/20120204023555/http://dustyvolumes.com/archives/498 > > Bill Curtis published a critique of the Sackler et al. paper in 1988. > > I quote (via Dickey): > > "Sackman's ... message that substantial performance differences do exist > among programmers remains valid. Detecting a 20+:1 range ratio depends > upon having one brilliant and one horrid performance in a sample. > However the range ratio is not a particularly stable measure of > performance variability among programmers. The dispersions of such data > as appear in Table I are better represented by such measures as the > standard deviation or semiinterquartile range." > > https://invisible-island.net/personal/paperstuff.html > > We have likely all observed how this 28:1 ratio has bloated in retelling > over time, like the length of a fish catch, to 100:1 or even 1000:1. > Similarly we're all familiar with the common practice of presenting the > mean and sometimes the range of some data sample to support one's > argument, without mentioning the median or mode, let alone the variance > (or the standard deviation). (If a member of one's audience is familiar > with non-Gaussian distributions and inquires whether one's sample may be > better characterized by one, you invite them to disengage from the > discussion.) > > I assert that this "productivity gap" is a myth, and that it persists > because it serves the purposes of diverse audiences who adopt it with > motivated reasoning. > > 1. Immature Unix enthusiasts like to reassure themselves, and others > nearby, of their inherent superiority to rival programmers. > > 2. Managers like to contrive reasons for (not) promoting individual > contributors. It's easy to cite this productivity "statistic" and > then suggest, without indicating anything concrete, that an employee > is either a rock star or a mediocrity. > > 3. Directors in organizations like not having to further justify a > "stack-rank and cut" approach to reducing salary and benefits as a > proportion of operational expenditures. > > https://en.wikipedia.org/wiki/Vitality_curve > > 4. Business culture in general is deeply wedded to the idea that > individual productivity, merit, or capacity for "wealth creation" is > variable by several orders of magnitude, because this claim > "justifies" variance in compensation over a similarly large range, > even among college-educated professionals in an organization, > setting aside those members of staff whose collars shade more toward > blue. (Outsourcing is useful in increasing opacity, segregating > workers, and setting them up to have conflicting interests.) > > If people start applying their capacity for critical thought to the > proposition that the CEO is 40,000 times more productive than a > "Software Engineer II", nothing good will happen. > > _Is_ "productivity" among programmers, however defined and measured, > nonuniform? Likely yes. Has our industry studied the question in a > serious way, applying rigorous experimental design and statistical > analysis? Perhaps not. > > And if we did, would any of the people making this claim read or > comprehend the research if it didn't support their biases? > > You already know the answer. > > We utter myths about falsifiable propositions not because we care about > their truth values, but precisely because we don't. > > Regards, > Branden > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Fri Jul 5 01:07:22 2024 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 4 Jul 2024 08:07:22 -0700 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> <20240704015323.7EEE88EBE798@ary.qy> <-xc_VtRQ7D8ll__tVJJEF4MXsGZF-vvAKLrh2Oq0lPKemGXIS1XAQLNs0vumI1_OZ_0UO0LjdImMHuijnPJe_R-3neo-2ZwT4l_L3hLOTLU=@protonmail.com> Message-ID: <20240704150722.GD26356@mcvoy.com> On Thu, Jul 04, 2024 at 04:53:17PM +1000, Rob Pike wrote: > Architecture people: please just let me pretend your CPU is like a > PDP-11. No surprises, OK? I'll handle the complaints about irrelevance > in the modern age. Funny you should say that. My kid is learning how to code and I told him to learn PDP-11 (or these days, probably ARM if that isn't all messed up) and then pretend that everything works like that. It's a fine mental model. Trying to develop that mental model in the chaos that is x86_64, I'm not sure that is even possible. It would take a long time. I think you can learn a PDP-11, as a newbie, in a month or two. So +1 for what Rob said. From kevin.bowling at kev009.com Fri Jul 5 06:02:32 2024 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Thu, 4 Jul 2024 13:02:32 -0700 Subject: [TUHS] 3B21D Message-ID: Howdy, I now have this pictured 3B21D in my facility http://kev009.com/wp/2024/07/Lucent-5ESS-Rescue/ It will be a moment before I can start work on documentation of the 3B21D and DMERT/UNIX-RTR but wanted to share the news. Regards, Kevin From imp at bsdimp.com Fri Jul 5 06:14:58 2024 From: imp at bsdimp.com (Warner Losh) Date: Thu, 4 Jul 2024 14:14:58 -0600 Subject: [TUHS] 3B21D In-Reply-To: References: Message-ID: On Thu, Jul 4, 2024, 2:02 PM Kevin Bowling wrote: > Howdy, > > I now have this pictured 3B21D in my facility > http://kev009.com/wp/2024/07/Lucent-5ESS-Rescue/ > > It will be a moment before I can start work on documentation of the > 3B21D and DMERT/UNIX-RTR but wanted to share the news. > Awesome accomplished. Can't wait to see the outcome. Warner Regards, > Kevin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri Jul 5 06:22:05 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 04 Jul 2024 20:22:05 +0000 Subject: [TUHS] 3B21D In-Reply-To: References: Message-ID: On Thursday, July 4th, 2024 at 1:14 PM, Warner Losh wrote: > > > On Thu, Jul 4, 2024, 2:02 PM Kevin Bowling wrote: > > > Howdy, > > > > I now have this pictured 3B21D in my facility > > http://kev009.com/wp/2024/07/Lucent-5ESS-Rescue/ > > > > It will be a moment before I can start work on documentation of the > > 3B21D and DMERT/UNIX-RTR but wanted to share the news. > > > Awesome accomplished. Can't wait to see the outcome. > > Warner > > > > > Regards, > > Kevin Kudos, I'm quite envious, this is awesome news! I appreciate your writeup, touching on the odd world this lives in, between computer and telecom appliance. Whether the 3B20 family was liked out in the general computing world or not, the impact on telecommunications is clear with the long shadow of the 5ESS family of switches. Hopefully Lucent was still keen on providing /usr/src and /usr/man :) I'm still holding out hope a WECo-era machine pops up someday...but either way, glad to finally see something in this lineage in the hands of someone with a keen eye for UNIX and Bell System history! - Matt G. From nevin at eviloverlord.com Fri Jul 5 06:34:36 2024 From: nevin at eviloverlord.com (Nevin Liber) Date: Thu, 4 Jul 2024 15:34:36 -0500 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> Message-ID: On Thu, Jul 4, 2024 at 3:24 AM Vincenzo Nicosia wrote: > I agree my view is cynical. Maybe that's because I cannot find anything > romantic or poetic in "financing, regulatory constraints, product > schedules, commitments, staffing issues, and everything else that isn't > coding". Real Artists Ship: https://folklore.org/Real_Artists_Ship.html How would you have ever seen Unix had it not been for financing (engineers, even passionate ones, kind of like to eat and have a roof over their heads)? Without regulatory constraints (while not perfect), applying Unix to anything that is safety critical (lives directly on the line) would be a disaster. I can make a similar statement for every single thing in that list which isn't coding. There are something like 28 million public repositories on Github. How many of them are abandoned (no commitment)? How many of them are "beautiful" (for any reasonable definition of "beautiful" you can come up with)? Even 1%? Of those, how many of them have corporate backing (money, financing, staffing, etc.)? It's fine to romanticize passion. But it is also fiction. -- Nevin ":-)" Liber +1-847-691-1404 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri Jul 5 06:44:53 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 04 Jul 2024 20:44:53 +0000 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> Message-ID: On Thursday, July 4th, 2024 at 1:34 PM, Nevin Liber wrote: > > There are something like 28 million public repositories on Github. How many of them are abandoned (no commitment)? > ... > -- > Nevin ":-)" Liber +1-847-691-1404 I do appreciate that, while yes there are a lot of abandoned threads on various public source control providers, that those threads are indeed public and could be picked back up by the right person in certain circumstances. I've benefitted more than once from someone leaving something up, even if I had to pay a bit of technical debt myself to get use out of it. While entropy levies its tax over time, it's better than things disappearing into some black hole, never to be seen again. As much as I don't like the LLM trend, one application of the modern trend of generative LLMs could be plundering the depths of all of this code (respective of licensing of course) to dredge up hidden nuggets just waiting to be discovered. Everything useful gets invented at some point, I have to wonder what's sitting in some abandoned repo somewhere just waiting to fit someone's use-case like hand in glove. After all, isn't that one of the many reasons we go digging around in decades-old UNIX code still :) - Matt G. From sjenkin at canb.auug.org.au Fri Jul 5 07:41:44 2024 From: sjenkin at canb.auug.org.au (sjenkin at canb.auug.org.au) Date: Fri, 5 Jul 2024 07:41:44 +1000 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> Message-ID: Thanks to everyone who’s contributed to this thread. Lots of good insight and views. I should’ve said “case studies in software development”. Summary: Nobody on list has heard of such case studies. I took the Lions class, it was not about development, taught us Operating Systems. John had a pedagogical principle - people learn programming by reading good code. > On 5 Jul 2024, at 06:44, segaloco via TUHS wrote: > > On Thursday, July 4th, 2024 at 1:34 PM, Nevin Liber wrote: > >> >> There are something like 28 million public repositories on Github. How many of them are abandoned (no commitment)? >> ... >> -- >> Nevin ":-)" Liber +1-847-691-1404 > > I do appreciate that, while yes there are a lot of abandoned threads on various public source control providers, that those threads are indeed public and could be picked back up by the right person in certain circumstances. I've benefitted more than once from someone leaving something up, even if I had to pay a bit of technical debt myself to get use out of it. While entropy levies its tax over time, it's better than things disappearing into some black hole, never to be seen again. > > As much as I don't like the LLM trend, one application of the modern trend of generative LLMs could be plundering the depths of all of this code (respective of licensing of course) to dredge up hidden nuggets just waiting to be discovered. Everything useful gets invented at some point, I have to wonder what's sitting in some abandoned repo somewhere just waiting to fit someone's use-case like hand in glove. After all, isn't that one of the many reasons we go digging around in decades-old UNIX code still :) > > - Matt G. -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Fri Jul 5 09:26:46 2024 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 5 Jul 2024 09:26:46 +1000 (EST) Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> Message-ID: On Wed, 3 Jul 2024, Rik Farrow wrote: > Although off-topic, except by including Lions: twice in the early 80s, a > programmer handed me a binder with the Lions book as a several > generations old xerox copy. It was always in the programmer/engineer > part of a warehouse (like Morrow), and it was handed to me as if it were > something illegal. I guess it was. The most photocopied book in the world, I lost my originals during a house move :-( Almost certainly illegal, but somehow I think that Dr. Lions would have approved... -- Dave From stuff at riddermarkfarm.ca Fri Jul 5 10:03:10 2024 From: stuff at riddermarkfarm.ca (Stuff Received) Date: Thu, 4 Jul 2024 20:03:10 -0400 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> Message-ID: <17b4e96d-724d-0394-7a95-50be7a76f695@riddermarkfarm.ca> On 2024-07-04 16:34, Nevin Liber wrote (in part): > On Thu, Jul 4, 2024 at 3:24 AM Vincenzo Nicosia > wrote: > > I agree my view is cynical. Maybe that's because I cannot find anything > romantic or poetic in "financing, regulatory constraints, product > schedules, commitments, staffing issues, and everything else that isn't > coding". > > > Real Artists Ship: https://folklore.org/Real_Artists_Ship.html > > > How would you have ever seen Unix had it not been for financing > (engineers, even passionate ones, kind of like to eat and have a roof > over their heads)?  Without regulatory constraints (while not perfect), > applying Unix to anything that is safety critical (lives directly on the > line) would be a disaster.  I can make a similar statement for every > single thing in that list which isn't coding. In full agreement. Having worked at startups, engineers often do all of these other tasks and know their importance. Though not full case studies, chapter 5 of "Evidence based software engineering" by Derek Jones has interesting project cases. S. From mrochkind at gmail.com Fri Jul 5 10:08:04 2024 From: mrochkind at gmail.com (Marc Rochkind) Date: Thu, 4 Jul 2024 18:08:04 -0600 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> Message-ID: On Thu, Jul 4, 2024 at 2:24 AM Vincenzo Nicosia wrote: > Maybe that's because I cannot find anything > romantic or poetic in "financing, regulatory constraints, product > schedules, commitments, staffing issues, and everything else that isn't > coding". > I'm with you there. That's why they call it "work." Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Fri Jul 5 10:12:47 2024 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 4 Jul 2024 17:12:47 -0700 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <17b4e96d-724d-0394-7a95-50be7a76f695@riddermarkfarm.ca> References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> <17b4e96d-724d-0394-7a95-50be7a76f695@riddermarkfarm.ca> Message-ID: <20240705001247.GK26356@mcvoy.com> On Thu, Jul 04, 2024 at 08:03:10PM -0400, Stuff Received wrote: > On 2024-07-04 16:34, Nevin Liber wrote (in part): > >On Thu, Jul 4, 2024 at 3:24???AM Vincenzo Nicosia >> wrote: > > > > I agree my view is cynical. Maybe that's because I cannot find anything > > romantic or poetic in "financing, regulatory constraints, product > > schedules, commitments, staffing issues, and everything else that isn't > > coding". > > > > > >Real Artists Ship: https://folklore.org/Real_Artists_Ship.html > > > > > >How would you have ever seen Unix had it not been for financing > >(engineers, even passionate??ones, kind of like to eat and have a roof > >over their heads)??? Without regulatory??constraints (while not perfect), > >applying Unix to anything that is safety critical (lives directly on the > >line) would be a disaster.?? I can make a similar statement for every > >single thing in that list which isn't coding. > > In full agreement. Having worked at startups, engineers often do all of > these other tasks and know their importance. I'm friends with one of the ZFS guys (and I hired the other guy at Sun) and one Bill's interview questions for a startup candidate is "If we need you to, will you sweep the floors". Bill likes people who can do whatever is needed. From jsg at jsg.id.au Fri Jul 5 11:13:27 2024 From: jsg at jsg.id.au (Jonathan Gray) Date: Fri, 5 Jul 2024 11:13:27 +1000 Subject: [TUHS] Lions book reprint by Bell Labs In-Reply-To: References: Message-ID: On Wed, Jul 03, 2024 at 05:03:42PM -0700, Tom Lyon wrote: > The fabulous Dr. Honeyman made a gift to me of his Lions' books which were > printed by Bell Labs. Does anyone know WHEN that happened or WHO made it > happen? > > I figure it must have been at least 1 year and maybe 2 after Lions' > originals. > > See Images: > https://drive.google.com/file/d/1BIs3Qsihp6nI2iX1Ax3fNU-OFv5dfy0O/view?usp=sharing > https://drive.google.com/file/d/1LoQUl8ND7D18z1W5I3NF-QwIvDkfXk0t/view?usp=drive_link > https://drive.google.com/file/d/1xg4TAJNAp5h8FljulJh9Zh0nzFy-YWda/view?usp=sharing > https://drive.google.com/file/d/1u--blfYu5Iuzpc-qiwCGNq0p6u1DgucR/view?usp=sharing And video of when he gifted them after your talk at the NLUUG conference in May of this year: https://www.youtube.com/watch?v=6smyhrNB3XM&t=25076s From athornton at gmail.com Fri Jul 5 12:24:26 2024 From: athornton at gmail.com (Adam Thornton) Date: Thu, 4 Jul 2024 19:24:26 -0700 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <20240705001247.GK26356@mcvoy.com> References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> <17b4e96d-724d-0394-7a95-50be7a76f695@riddermarkfarm.ca> <20240705001247.GK26356@mcvoy.com> Message-ID: Two replies to things Larry said: ARM or one of the smaller RISC-V flavor-sets (RISC-V is super-modular) would be a perfectly reasonable architecture to learn these days. After the PDP-11 but before ARM I'd'a suggested 68000. Definitely NOT x86 and its betentacled descendants. Even so, you'd still want to treat it (if you're learning "how do computers work?") as if it were not superscalar, even though it obviously is. Which I guess is pushing me into "please let me just pretend it's a PDP-11 and keep all the scary pipelining and speculative execution and all the things that are hard to reason about below the layer where I need to care" territory. And yeah, if you need me to sweep the floors, I'll sweep the floors, but if I'm needed to sweep the floors often, there's a management problem here, in that you can hire people who are much better at sweeping floors than I am for much less money than you hired me to do software engineering for. Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri Jul 5 12:42:18 2024 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Thu, 4 Jul 2024 19:42:18 -0700 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> <17b4e96d-724d-0394-7a95-50be7a76f695@riddermarkfarm.ca> <20240705001247.GK26356@mcvoy.com> Message-ID: <94C7522E-F887-4962-ACB9-27DFB3AF47E6@iitbombay.org> A better analogy might be to compare early employees (especially engineers) to stem cells. They are the type of people that can (& are willing to) do pretty much anything but over time end up specializing in a few things. I have done things like look at office spaces, set up furniture, order machines & office supplies, select ISP, wired up the place, and many sysadmin things, dealt with janitorial services, selecting insurance, payroll services, debugged issues not related to engineering, many interviews (tech and otherwise), dealt with vendors & headhunters, set up guidelines, software systems, documentation, etc. etc. As times goes on you let go and get out of people's way and focus on where you're most effective (or where there is temporarily no one else). > On Jul 4, 2024, at 7:24 PM, Adam Thornton wrote: > > Two replies to things Larry said: > > ARM or one of the smaller RISC-V flavor-sets (RISC-V is super-modular) would be a perfectly reasonable architecture to learn these days. After the PDP-11 but before ARM I'd'a suggested 68000. Definitely NOT x86 and its betentacled descendants. Even so, you'd still want to treat it (if you're learning "how do computers work?") as if it were not superscalar, even though it obviously is. Which I guess is pushing me into "please let me just pretend it's a PDP-11 and keep all the scary pipelining and speculative execution and all the things that are hard to reason about below the layer where I need to care" territory. > > And yeah, if you need me to sweep the floors, I'll sweep the floors, but if I'm needed to sweep the floors often, there's a management problem here, in that you can hire people who are much better at sweeping floors than I am for much less money than you hired me to do software engineering for. > > Adam From arnold at skeeve.com Fri Jul 5 17:13:02 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 05 Jul 2024 01:13:02 -0600 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <94C7522E-F887-4962-ACB9-27DFB3AF47E6@iitbombay.org> References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> <17b4e96d-724d-0394-7a95-50be7a76f695@riddermarkfarm.ca> <20240705001247.GK26356@mcvoy.com> <94C7522E-F887-4962-ACB9-27DFB3AF47E6@iitbombay.org> Message-ID: <202407050713.4657D2cK1211103@freefriends.org> The flip side is when you're asked to do something you're not competent at. At Intel, I was once tasked in reviewing the license for something we wanted to use. I Am Not A Lawyer, nor do I play one on TV. I did my best, but got fussed at by a higher-up for it not being good enough. I'm sorry, but that bullsh*t --- Intel has lawyers out the wazoo, and that's who should have been involved in reviewing that license. Would you take your car to TV repair shop to get fixed? Same thing. Arnold Bakul Shah via TUHS wrote: > A better analogy might be to compare early employees (especially > engineers) to stem cells. They are the type of people that can (& are > willing to) do pretty much anything but over time end up specializing > in a few things. I have done things like look at office spaces, set up > furniture, order machines & office supplies, select ISP, wired up the > place, and many sysadmin things, dealt with janitorial services, selecting > insurance, payroll services, debugged issues not related to engineering, > many interviews (tech and otherwise), dealt with vendors & headhunters, > set up guidelines, software systems, documentation, etc. etc. As times > goes on you let go and get out of people's way and focus on where you're > most effective (or where there is temporarily no one else). > > > On Jul 4, 2024, at 7:24 PM, Adam Thornton wrote: > > > > Two replies to things Larry said: > > > > ARM or one of the smaller RISC-V flavor-sets (RISC-V is super-modular) would be a perfectly reasonable architecture to learn these days. After the PDP-11 but before ARM I'd'a suggested 68000. Definitely NOT x86 and its betentacled descendants. Even so, you'd still want to treat it (if you're learning "how do computers work?") as if it were not superscalar, even though it obviously is. Which I guess is pushing me into "please let me just pretend it's a PDP-11 and keep all the scary pipelining and speculative execution and all the things that are hard to reason about below the layer where I need to care" territory. > > > > And yeah, if you need me to sweep the floors, I'll sweep the floors, but if I'm needed to sweep the floors often, there's a management problem here, in that you can hire people who are much better at sweeping floors than I am for much less money than you hired me to do software engineering for. > > > > Adam > From dave at horsfall.org Fri Jul 5 17:36:38 2024 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 5 Jul 2024 17:36:38 +1000 (EST) Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> <17b4e96d-724d-0394-7a95-50be7a76f695@riddermarkfarm.ca> <20240705001247.GK26356@mcvoy.com> Message-ID: On Thu, 4 Jul 2024, Adam Thornton wrote: > ARM or one of the smaller RISC-V flavor-sets (RISC-V is super-modular) > would be a perfectly reasonable architecture to learn these days.  After > the PDP-11 but before ARM I'd'a suggested 68000.  Definitely NOT x86 and > its betentacled descendants.  Even so, you'd still want to treat it (if > you're learning "how do computers work?") as if it were not superscalar, > even though it obviously is.  Which I guess is pushing me into "please > let me just pretend it's a PDP-11 and keep all the scary pipelining and > speculative execution and all the things that are hard to reason about > below the layer where I need to care" territory. Pretty much anything with a linear address space, an orthogonal instruction set, and a stack will do, I think. Was it John Gilmore who said "Segment registers are for worms"? I dips me lid to those souls who implemented ALGOLW on the 360... > And yeah, if you need me to sweep the floors, I'll sweep the floors, but > if I'm needed to sweep the floors often, there's a management problem > here, in that you can hire people who are much better at sweeping floors > than I am for much less money than you hired me to do software > engineering for. I've worked in places where I've swept the floor (and also did the dishes etc); I'll still need to be paid the same salary, though :-) -- Dave From tuhs at tuhs.org Fri Jul 5 17:42:40 2024 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Fri, 5 Jul 2024 00:42:40 -0700 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <202407050713.4657D2cK1211103@freefriends.org> References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> <17b4e96d-724d-0394-7a95-50be7a76f695@riddermarkfarm.ca> <20240705001247.GK26356@mcvoy.com> <94C7522E-F887-4962-ACB9-27DFB3AF47E6@iitbombay.org> <202407050713.4657D2cK1211103@freefriends.org> Message-ID: I was talking about startups, while in a bootstrapping mode. Intel stopped being that a looong time ago! But yes, I wouldn't want to play a lawyer! In a startup there are lots of other things that need done and you of course try to hire/contract the right people but it isn't always easy or quick. > On Jul 5, 2024, at 12:13 AM, arnold at skeeve.com wrote: > > The flip side is when you're asked to do something you're not competent > at. At Intel, I was once tasked in reviewing the license for something > we wanted to use. I Am Not A Lawyer, nor do I play one on TV. I did my > best, but got fussed at by a higher-up for it not being good enough. > > I'm sorry, but that bullsh*t --- Intel has lawyers out the wazoo, and > that's who should have been involved in reviewing that license. > > Would you take your car to TV repair shop to get fixed? Same thing. > > Arnold > > Bakul Shah via TUHS wrote: > >> A better analogy might be to compare early employees (especially >> engineers) to stem cells. They are the type of people that can (& are >> willing to) do pretty much anything but over time end up specializing >> in a few things. I have done things like look at office spaces, set up >> furniture, order machines & office supplies, select ISP, wired up the >> place, and many sysadmin things, dealt with janitorial services, selecting >> insurance, payroll services, debugged issues not related to engineering, >> many interviews (tech and otherwise), dealt with vendors & headhunters, >> set up guidelines, software systems, documentation, etc. etc. As times >> goes on you let go and get out of people's way and focus on where you're >> most effective (or where there is temporarily no one else). >> >>> On Jul 4, 2024, at 7:24 PM, Adam Thornton wrote: >>> >>> Two replies to things Larry said: >>> >>> ARM or one of the smaller RISC-V flavor-sets (RISC-V is super-modular) would be a perfectly reasonable architecture to learn these days. After the PDP-11 but before ARM I'd'a suggested 68000. Definitely NOT x86 and its betentacled descendants. Even so, you'd still want to treat it (if you're learning "how do computers work?") as if it were not superscalar, even though it obviously is. Which I guess is pushing me into "please let me just pretend it's a PDP-11 and keep all the scary pipelining and speculative execution and all the things that are hard to reason about below the layer where I need to care" territory. >>> >>> And yeah, if you need me to sweep the floors, I'll sweep the floors, but if I'm needed to sweep the floors often, there's a management problem here, in that you can hire people who are much better at sweeping floors than I am for much less money than you hired me to do software engineering for. >>> >>> Adam >> From arnold at skeeve.com Fri Jul 5 18:20:31 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 05 Jul 2024 02:20:31 -0600 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> <17b4e96d-724d-0394-7a95-50be7a76f695@riddermarkfarm.ca> <20240705001247.GK26356@mcvoy.com> <94C7522E-F887-4962-ACB9-27DFB3AF47E6@iitbombay.org> <202407050713.4657D2cK1211103@freefriends.org> Message-ID: <202407050820.4658KVAJ1216742@freefriends.org> To a large extent it still applies in startups. If a software person doesn't know the first thing about wiring a building for Ethernet, do you really want him/her to do that for you? In situations like these, you get what you pay for, and it's better to bring in someone who knows what they're doing in order to get it done right. (Yes, I had that experience too.) I do understand your point, in startups people have to be flexible and do many things, but it still should require some consideration for the longer term. Bakul Shah wrote: > I was talking about startups, while in a bootstrapping mode. Intel stopped > being that a looong time ago! But yes, I wouldn't want to play a lawyer! > > In a startup there are lots of other things that need done and you of > course try to hire/contract the right people but it isn't always easy > or quick. > > > On Jul 5, 2024, at 12:13 AM, arnold at skeeve.com wrote: > > > > The flip side is when you're asked to do something you're not competent > > at. At Intel, I was once tasked in reviewing the license for something > > we wanted to use. I Am Not A Lawyer, nor do I play one on TV. I did my > > best, but got fussed at by a higher-up for it not being good enough. > > > > I'm sorry, but that bullsh*t --- Intel has lawyers out the wazoo, and > > that's who should have been involved in reviewing that license. > > > > Would you take your car to TV repair shop to get fixed? Same thing. > > > > Arnold > > > > Bakul Shah via TUHS wrote: > > > >> A better analogy might be to compare early employees (especially > >> engineers) to stem cells. They are the type of people that can (& are > >> willing to) do pretty much anything but over time end up specializing > >> in a few things. I have done things like look at office spaces, set up > >> furniture, order machines & office supplies, select ISP, wired up the > >> place, and many sysadmin things, dealt with janitorial services, selecting > >> insurance, payroll services, debugged issues not related to engineering, > >> many interviews (tech and otherwise), dealt with vendors & headhunters, > >> set up guidelines, software systems, documentation, etc. etc. As times > >> goes on you let go and get out of people's way and focus on where you're > >> most effective (or where there is temporarily no one else). > >> > >>> On Jul 4, 2024, at 7:24 PM, Adam Thornton wrote: > >>> > >>> Two replies to things Larry said: > >>> > >>> ARM or one of the smaller RISC-V flavor-sets (RISC-V is super-modular) would be a perfectly reasonable architecture to learn these days. After the PDP-11 but before ARM I'd'a suggested 68000. Definitely NOT x86 and its betentacled descendants. Even so, you'd still want to treat it (if you're learning "how do computers work?") as if it were not superscalar, even though it obviously is. Which I guess is pushing me into "please let me just pretend it's a PDP-11 and keep all the scary pipelining and speculative execution and all the things that are hard to reason about below the layer where I need to care" territory. > >>> > >>> And yeah, if you need me to sweep the floors, I'll sweep the floors, but if I'm needed to sweep the floors often, there's a management problem here, in that you can hire people who are much better at sweeping floors than I am for much less money than you hired me to do software engineering for. > >>> > >>> Adam > >> > From g.branden.robinson at gmail.com Fri Jul 5 18:52:12 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Fri, 5 Jul 2024 03:52:12 -0500 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <202407050820.4658KVAJ1216742@freefriends.org> References: <17b4e96d-724d-0394-7a95-50be7a76f695@riddermarkfarm.ca> <20240705001247.GK26356@mcvoy.com> <94C7522E-F887-4962-ACB9-27DFB3AF47E6@iitbombay.org> <202407050713.4657D2cK1211103@freefriends.org> <202407050820.4658KVAJ1216742@freefriends.org> Message-ID: <20240705085212.wchc6wttl6dy6adq@illithid> At 2024-07-05T02:20:31-0600, arnold at skeeve.com wrote: > To a large extent it still applies in startups. [...] > I do understand your point, in startups people have to be flexible > and do many things, but it still should require some consideration > for the longer term. Consideration for the longer term is completely _not_ the point of a speculatively financed startup. The idea is to convince enough Series B investors, or an underwriting bank that will float your IPO, that you have a sure thing in hand, that you've identified a choke point in the market, and your firm will be able to extract gigantic rents for an extended period by squeezing that choke point. The long term is often not long. But if you, with founder's stock, can get out clean before your brilliant strategy is revealed as a moronic façade, you've met your victory condition. And if you don't? Practice blaming other people for your failure and try, try again. Steve Jobs wasn't built in a day. https://ca.finance.yahoo.com/news/27-billion-smoke-ndash-thats-125443313.html Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From sjenkin at canb.auug.org.au Fri Jul 5 19:41:20 2024 From: sjenkin at canb.auug.org.au (Steve Jenkin) Date: Fri, 5 Jul 2024 19:41:20 +1000 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <7AC009E5-C985-44AD-A55E-E0BFC05CDD31@serissa.com> References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> <7AC009E5-C985-44AD-A55E-E0BFC05CDD31@serissa.com> Message-ID: Links for those who’ve not read these articles. Open access, downloadable PDF’s. ================ Peter J Denning in 2008 wrote about reforming CACM in 1982/83. [ extract at end ] The space shuttle primary computer system Sept 1984 The TWA reservation system July 1984 ================ After Editor in Chief of the ACM, in 1993 Denning established "The Center for the New Engineer" (CNE) Great Principles of Computing, paper Website ================ Denning, 2008 Another major success was the case studies conducted by Alfred Spector and David Gifford of MIT, who visited project managers and engineers at major companies and interviewed them about their projects, producing no-holds-barred pieces. This section was wildly popular among the readers. Unfortunately, the labor-intensive demands of the post got the best of them after three years, and we were not able to replace them. Also by that time, companies were getting more circumspect about discussing failures and lessons learned in public forums. ================ > On 5 Jul 2024, at 09:31, Lawrence Stewart wrote: > > Alright, apologies for being late. > > Back in 1984, David Gifford and Al Spector started a series of case studies for CACM. > I think only two were published, on the TWA reservation system and on the Space Shuttle primary computer. -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin From sjenkin at canb.auug.org.au Fri Jul 5 19:47:46 2024 From: sjenkin at canb.auug.org.au (Steve Jenkin) Date: Fri, 5 Jul 2024 19:47:46 +1000 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <7AC009E5-C985-44AD-A55E-E0BFC05CDD31@serissa.com> References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> <7AC009E5-C985-44AD-A55E-E0BFC05CDD31@serissa.com> Message-ID: <0C55CBC2-43B0-4372-A7AD-5C6B13A875D2@canb.auug.org.au> Found these two. Anyone seen others? I bought this book soon after it was published. It’s a detailed study of some major IT projects, doesn’t draw “lessons” & rules like I’d expect of an MBA Case Study. Why information systems fail: a case study approach February 1993 > On 5 Jul 2024, at 09:31, Lawrence Stewart wrote: > > A quick search also shows a number of software engineering case study books. ================ Case Study Research in Software Engineering: Guidelines and Examples April 2012 Based on their own experiences of in-depth case studies of software projects in international corporations, in this bookthe authors present detailed practical guidelines on the preparation, conduct, design and reporting of case studies of software engineering. This is the first software engineering specific book on thecase study research method. ================ Case studies for software engineers May 2006 The topic of this full-day tutorial was the correct use and interpretation of case studies as an empirical research method. Using an equal blend of lecture and discussion, it gave attendees a foundation for conducting, reviewing, and reading case studies. There were lessons for software engineers as researchers who conduct and report case studies, reviewers who evaluate papers, and practitioners who are attempting to apply results from papers. The main resource for the course was the book Case Study Research: Design and Methods by Robert K. Yin. This text was supplemented with positive and negative examples from the literature. ================ -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin From peter.martin.yardley at gmail.com Fri Jul 5 20:18:41 2024 From: peter.martin.yardley at gmail.com (Peter Yardley) Date: Fri, 5 Jul 2024 20:18:41 +1000 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: Message-ID: The DG Nova had a pretty nice architecture. 2 accumulators, 2 index registers, program counter, status register. No stack register tho. There was a micro processor version by Fairchild. Sent from my iPhone > On 5 Jul 2024, at 5:36 pm, Dave Horsfall wrote: > > On Thu, 4 Jul 2024, Adam Thornton wrote: > >> ARM or one of the smaller RISC-V flavor-sets (RISC-V is super-modular) >> would be a perfectly reasonable architecture to learn these days. After >> the PDP-11 but before ARM I'd'a suggested 68000. Definitely NOT x86 and >> its betentacled descendants. Even so, you'd still want to treat it (if >> you're learning "how do computers work?") as if it were not superscalar, >> even though it obviously is. Which I guess is pushing me into "please >> let me just pretend it's a PDP-11 and keep all the scary pipelining and >> speculative execution and all the things that are hard to reason about >> below the layer where I need to care" territory. > > Pretty much anything with a linear address space, an orthogonal > instruction set, and a stack will do, I think. > > Was it John Gilmore who said "Segment registers are for worms"? > > I dips me lid to those souls who implemented ALGOLW on the 360... > >> And yeah, if you need me to sweep the floors, I'll sweep the floors, but >> if I'm needed to sweep the floors often, there's a management problem >> here, in that you can hire people who are much better at sweeping floors >> than I am for much less money than you hired me to do software >> engineering for. > > I've worked in places where I've swept the floor (and also did the dishes > etc); I'll still need to be paid the same salary, though :-) > > -- Dave From douglas.mcilroy at dartmouth.edu Fri Jul 5 23:20:52 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Fri, 5 Jul 2024 09:20:52 -0400 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? Message-ID: > Peter J Denning in 2008 wrote about reforming CACM in 1982/83. [ extract at end ] > That "accomplishment" drove me away from the ACM. I hope the following explanation does not set off yet another long tangential discussion. The CACM had been the prime benefit of ACM membership. It carried generally accessible technical content across the whole spectrum of computing. The "Journal for all Members" (JAM) reform resulted in such content being thinly spread over several journals. To get the perspective that CACM had offered, one would have had to subscribe to and winnow a mountain of specialst literature--assuming the editors of these journals would accept some ACM-style articles. I had been an active member of ACM, having serving as associate editor of three journals, member of the publications planning committee, national lecturer, and Turing-Award chairman. When the JAM reform cut off my window into the field at large, I quit the whole organization. With the advent of WWW, the ACM Digital Library overcame the need to subscribe to multiple journals for wide coverage. Fortunately I had institutional acess to that. I rejoined ACM only after its decision to allow free access to all 20th century content in the DL. This public-spirited action more than atoned for the damage of the JAM reform and warranted my support. I have been happy to find that the current CACM carries one important technical article in each issue and a couple of interesting columnists among the generally insipid JAM content. And I am pleased by the news that ACM will soon also give open access to most 21st-century content. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Sat Jul 6 02:40:30 2024 From: jon at fourwinds.com (Jon Steinhart) Date: Fri, 05 Jul 2024 09:40:30 -0700 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> <17b4e96d-724d-0394-7a95-50be7a76f695@riddermarkfarm.ca> <20240705001247.GK26356@mcvoy.com> Message-ID: <202407051640.465GeUCn727365@darkstar.fourwinds.com> Dave Horsfall writes: > Was it John Gilmore who said "Segment registers are for worms"? Being as John is in my kitchen making breakfast at the moment, the answer is "no" :-) From johnl at taugh.com Sat Jul 6 07:38:03 2024 From: johnl at taugh.com (John Levine) Date: 5 Jul 2024 17:38:03 -0400 Subject: [TUHS] mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: Message-ID: <20240705213804.550128EDF53C@ary.qy> It appears that Peter Yardley said: >The DG Nova had a pretty nice architecture. 2 accumulators, 2 index registers, program counter, status register. No stack register tho. There was a micro processor version by Fairchild. It did, but it was word addressed which makes it an historical curiosity like its spiritual predecessors PDP-4/5/7/8/9. I also have a mental model of a PDP-11 but these days it's more a simplified 386 leaving out the dumb or useless stuff. I ignore the segments which are useless other than for 286 emulation, and some of the strange instructions like decimal adjust and the warty 8 and 16 bit registers. What's important is the memory model which on a 386 the way it was invariably set up was a flat 32 bit consistent little-endian byte addressed memory with a stack and reasonable addressing modes, and 4K pages for virtual memory. ARM should be OK too but I have to ask which ARM? There have been so many generations often not backward compatible. From lm at mcvoy.com Sat Jul 6 07:49:01 2024 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 5 Jul 2024 14:49:01 -0700 Subject: [TUHS] mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <20240705213804.550128EDF53C@ary.qy> References: <20240705213804.550128EDF53C@ary.qy> Message-ID: <20240705214901.GR26356@mcvoy.com> On Fri, Jul 05, 2024 at 05:38:03PM -0400, John Levine wrote: > It appears that Peter Yardley said: > >The DG Nova had a pretty nice architecture. 2 accumulators, 2 index registers, program counter, status register. No stack register tho. There was a micro processor version by Fairchild. > > It did, but it was word addressed which makes it an historical > curiosity like its spiritual predecessors PDP-4/5/7/8/9. > > I also have a mental model of a PDP-11 but these days it's more a simplified 386 > leaving out the dumb or useless stuff. I took a look at x86 in 386/486 days and found it to be enough of a mess that I stopped looking. In no way did it compare the simplicity and elegance of the PDP-11. I had a TA, Ken Witte, who could read octal dumps of PDP-11 assembly like it was C. I'm pretty sure the way the instructions were encoded was a big part of what made that possible. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From sauer at technologists.com Sat Jul 6 08:08:01 2024 From: sauer at technologists.com (Charles H Sauer (he/him)) Date: Fri, 5 Jul 2024 17:08:01 -0500 Subject: [TUHS] mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <20240705214901.GR26356@mcvoy.com> References: <20240705213804.550128EDF53C@ary.qy> <20240705214901.GR26356@mcvoy.com> Message-ID: <383b12d9-26bf-4c1e-a1db-b919112e5f42@technologists.com> On 7/5/2024 4:49 PM, Larry McVoy wrote: > On Fri, Jul 05, 2024 at 05:38:03PM -0400, John Levine wrote: >> It appears that Peter Yardley said: >>> The DG Nova had a pretty nice architecture. 2 accumulators, 2 index registers, program counter, status register. No stack register tho. There was a micro processor version by Fairchild. >> >> It did, but it was word addressed which makes it an historical >> curiosity like its spiritual predecessors PDP-4/5/7/8/9. >> >> I also have a mental model of a PDP-11 but these days it's more a simplified 386 >> leaving out the dumb or useless stuff. > > I took a look at x86 in 386/486 days and found it to be enough of a mess that > I stopped looking. In no way did it compare the simplicity and elegance > of the PDP-11. I had a TA, Ken Witte, who could read octal dumps of PDP-11 > assembly like it was C. I'm pretty sure the way the instructions were > encoded was a big part of what made that possible. Assuming you mean the same Kendall Witte that spearheaded Dell SVR4 (https://notes.technologists.com/notes/2008/01/10/a-brief-history-of-dell-unix/), he is quite fluent in X86 as well. After Dell SVR4 he became prominent in Dell firmware work. I saw him just over a year ago at a gathering of Dell "old timers". -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/LinkedIn/Twitter: CharlesHSauer From crossd at gmail.com Sat Jul 6 08:10:04 2024 From: crossd at gmail.com (Dan Cross) Date: Fri, 5 Jul 2024 18:10:04 -0400 Subject: [TUHS] mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <20240705213804.550128EDF53C@ary.qy> References: <20240705213804.550128EDF53C@ary.qy> Message-ID: On Fri, Jul 5, 2024 at 5:47 PM John Levine wrote: > It appears that Peter Yardley said: > >The DG Nova had a pretty nice architecture. 2 accumulators, 2 index registers, program counter, status register. No stack register tho. There was a micro processor version by Fairchild. > > It did, but it was word addressed which makes it an historical > curiosity like its spiritual predecessors PDP-4/5/7/8/9. > > I also have a mental model of a PDP-11 but these days it's more a simplified 386 > leaving out the dumb or useless stuff. I ignore the segments which are useless > other than for 286 emulation, and some of the strange instructions like decimal > adjust and the warty 8 and 16 bit registers. > > What's important is the memory model which on a 386 the way it was > invariably set up was a flat 32 bit consistent little-endian byte > addressed memory with a stack and reasonable addressing modes, and 4K > pages for virtual memory. It is important to ask, "what does one want to learn about architecture by going through this study exercise?" If one just wants to study the unprivileged instruction set at the level of assembler mnemonics, then x86_64 isn't completely awful. Some of the registers are oddly named, and some instructions have odd implicit operands (e.g., `inc %rax`, but if you're just looking at assembler syntax, perhaps one doesn't care. Of course, the instruction encoding is a huge mess, but most work-a-day programmers don't have to care about that. Where it gets really ugly, in my opinion, is in the privileged instruction set, and there you can't get away from history: there's no escaping descriptor tables or segmentation there! The interrupt stack table in the TSS must be set up properly or you're bound for a triple fault. This implies the GDT, IDT, TR, and TSS --- all 286-era goo --- are all properly set up, and you can't get away from that stuff, even in a modern operating system (you have to reload the TSS _or_ replace RSP0 on every thread switch: there's no other way; that's just how the hardware works). And then there's the matter that you _have_ to enable paging before switching into 64-bit mode on x86...it's not hard, but it's annoying (and the x86S proposal doubles down on it). It'd be more rational to allow execution against a flat 64-bit physical address space; for x86S, I'd rather be able to specify a reset vector in the physical address space by some sort of external strap. Both RISC-V and ARM seem much more rational in this world by comparison. I don't like the RISC-V page table format, though: it doesn't permit you to pun the root of the paging radix tree for other levels, meaning you can't use the "recursive page table" trick to get access to page tables themselves: this, in turn, has effects on the rest of the design of a virtual memory system. I think I've found a way around that involving a dedicated temporary mapping region, but it's kind of a pain and takes a non-trivial chunk of virtual address _space_ (if not fully realized memory) that I don't care for. How to handle cached vs uncached mappings, e.g., for MMIO, is still a bit mysterious to me. Honestly, this is something that x86 got largely right. ARM is ok, but has grown a lot of complexity; most of which can be ignored until needed, I suspect; saturating arithmetic, for example. Understanding it is not critical to understanding more or less how the computer works. > ARM should be OK too but I have to ask which ARM? There have been so > many generations often not backward compatible. I'd start with ARMv8 at this point. It has less confusing, more rational stack push/pop semantics and I think they did away with the conditional execution stuff, which is easier to reason about. My 2c. - Dan C. From lm at mcvoy.com Sat Jul 6 08:24:40 2024 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 5 Jul 2024 15:24:40 -0700 Subject: [TUHS] mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <383b12d9-26bf-4c1e-a1db-b919112e5f42@technologists.com> References: <20240705213804.550128EDF53C@ary.qy> <20240705214901.GR26356@mcvoy.com> <383b12d9-26bf-4c1e-a1db-b919112e5f42@technologists.com> Message-ID: <20240705222440.GS26356@mcvoy.com> On Fri, Jul 05, 2024 at 05:08:01PM -0500, Charles H Sauer (he/him) wrote: > Assuming you mean the same Kendall Witte that spearheaded Dell SVR4 (https://notes.technologists.com/notes/2008/01/10/a-brief-history-of-dell-unix/), > he is quite fluent in X86 as well. After Dell SVR4 he became prominent in > Dell firmware work. I saw him just over a year ago at a gathering of Dell > "old timers". Yep, that's him. I have fond memories of bring a six pack and an octal dump to his place and him swigging a beer and reading it with ease. Great guy. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From johnl at taugh.com Sat Jul 6 09:17:14 2024 From: johnl at taugh.com (John Levine) Date: 5 Jul 2024 19:17:14 -0400 Subject: [TUHS] mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <20240705214901.GR26356@mcvoy.com> References: <20240705213804.550128EDF53C@ary.qy> <20240705214901.GR26356@mcvoy.com> Message-ID: <20240705231714.5F0E58EE123E@ary.qy> According to Larry McVoy : >> It did, but it was word addressed which makes it an historical >> curiosity like its spiritual predecessors PDP-4/5/7/8/9. >> >> I also have a mental model of a PDP-11 but these days it's more a simplified 386 >> leaving out the dumb or useless stuff. > >I took a look at x86 in 386/486 days and found it to be enough of a mess that >I stopped looking. In no way did it compare the simplicity and elegance >of the PDP-11. If you're looking for simplicity and elegance, I can still remember most of the PDP-8's instruction codes so I could disassemble at sight. But it's not a very good model for a modern computer. I realized a while ago that the only really important things in an architecture are the addressing model, e.g., flat byte addressed little-endian, and the data formats, e.g., two's complement integers, ASCII or UTF-8 text, IEEE floating point. Back in the day getting a program to act the same on different computers, was really hard, with the switch from IBM 7090 (36 bit word addressed binary floating point) to IBM 360 (32 or 64 bit byte addressed hex floating point) the most famous example. These days we write code and compile it for x64 or ARM or RISC-V and for the most part, it just works because the data formats and addressing are all the same. From tuhs at tuhs.org Sat Jul 6 09:52:05 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 05 Jul 2024 23:52:05 +0000 Subject: [TUHS] Any Surviving LIL Compilers/Code Artifacts? Message-ID: So I'm doing a little bit of the footwork in prep for analyzing manual differences between Research, Program Generic, and PWB/UNIX, and found something interesting. The LIL Programming Language[1] was briefly available as a user-supported section 6 command on Fifth Edition (1974) UNIX, appearing as a page but not even making it into the TOC. It was gone as quickly as it appeared in the Research stream, not surviving into V6. However, with Al Kossow's provided Program Generic Issue 2 (1976) manual[2] as well as notes in the MERT Issue 0 (1977) manual [3], it appears that LIL was quite supported in the USG Program Generic line, making it into section 1 of Issue 2 and staying there through to Issue 3. lc(1) happens to be one of the pages excised in the transformation from PG Issue 3 to MERT Issue 0. This had me curious, so I went looking around the extant V5 sources and couldn't find anything resembling the LIL compiler. Does anyone know if this has survived in any other fashion? Additionally, does anyone have any recollection of whether LIL was in significant use in USG-supported UNIX sites, or if it somehow made it into section 1 and spread around due to the state of use in Research at the time USG sampled userland out. Finally, one little tidbit from P.J. Plauger's paper[1] stuck out to me: "...the resulting language was used to help write a small PDP-11/10 operating system at Bell Labs." Does anyone have any information about this operating system, whether it was a LIL experiment or something purpose-driven and used in its own right after creation? [1] - http://www.ultimate.com/phil/lil/ [2] - http://bitsavers.org/pdf/att/unix/6th_Edition/UNIX_Programmers_Manual_197601.pdf [3] - https://www.tuhs.org/Archive/Documentation/Manuals/MERT_Release_0/Pgs%2001-38%20Unix%20Programmer's%20Manual%20for%20MERT.pdf From sjenkin at canb.auug.org.au Sat Jul 6 22:52:25 2024 From: sjenkin at canb.auug.org.au (sjenkin at canb.auug.org.au) Date: Sat, 6 Jul 2024 22:52:25 +1000 Subject: [TUHS] mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <20240705231714.5F0E58EE123E@ary.qy> References: <20240705213804.550128EDF53C@ary.qy> <20240705214901.GR26356@mcvoy.com> <20240705231714.5F0E58EE123E@ary.qy> Message-ID: <6DEE0364-13BF-4DDF-8B42-8EE9DE010211@canb.auug.org.au> C wasn’t the first standardised coding language, FORTRAN & COBOL at least were before it, so there were multi-platform source libraries and shared source, though often single platform. From what I know, vendor extensions of FORTAN, optimised for their hardware, were common, making high-performance, portable source difficult or impossible. 6-bit and 8-bit chars were the least of it. Is this right: C was the first ’systems tool’ language + libraries available across many platforms. Notionally, source code could be ported with zero or minimal change. It made possible portable languages like PERL, PHP, Python. [ then came the "Tower of Babel" requiring tools like ‘autoconf’ ] C became a bootstrapping environment for other portable languages & tools, e.g. C++ & Golang. Secondly, portable systems tool languages with a common 2-part design of parser/front-end providing an abstract syntax tree to multiple back-ends with platform specific code-generators. Are these back-ends where most of the assembler, memory model and instruction optimisation take place now? > On 6 Jul 2024, at 09:17, John Levine wrote: > > Back in the day getting a program to act the same on different > computers, was really hard, with the switch from IBM 7090 (36 bit word > addressed binary floating point) to IBM 360 (32 or 64 bit byte > addressed hex floating point) the most famous example. These days we > write code and compile it for x64 or ARM or RISC-V and for the most > part, it just works because the data formats and addressing are all > the same. -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin From dave at horsfall.org Sat Jul 6 23:20:54 2024 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 6 Jul 2024 23:20:54 +1000 (EST) Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <202407051640.465GeUCn727365@darkstar.fourwinds.com> References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> <17b4e96d-724d-0394-7a95-50be7a76f695@riddermarkfarm.ca> <20240705001247.GK26356@mcvoy.com> <202407051640.465GeUCn727365@darkstar.fourwinds.com> Message-ID: On Fri, 5 Jul 2024, Jon Steinhart wrote: > Dave Horsfall writes: > > Was it John Gilmore who said "Segment registers are for worms"? > > Being as John is in my kitchen making breakfast at the moment, the > answer is "no" :-) Hmmm... I guess it was either RMS or DJB then (not that I'm equating all of them of course). -- Dave From johnl at taugh.com Sun Jul 7 00:02:22 2024 From: johnl at taugh.com (John R Levine) Date: 6 Jul 2024 10:02:22 -0400 Subject: [TUHS] mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <6DEE0364-13BF-4DDF-8B42-8EE9DE010211@canb.auug.org.au> References: <20240705213804.550128EDF53C@ary.qy> <20240705214901.GR26356@mcvoy.com> <20240705231714.5F0E58EE123E@ary.qy> <6DEE0364-13BF-4DDF-8B42-8EE9DE010211@canb.auug.org.au> Message-ID: <5ba59857-78f1-787c-ac9b-f4b6f61ce912@taugh.com> On Sat, 6 Jul 2024, sjenkin at canb.auug.org.au wrote: > C wasn’t the first standardised coding language, FORTRAN & COBOL at least were before it, > so there were multi-platform source libraries and shared source, though often single platform. > > From what I know, vendor extensions of FORTAN, optimised for their hardware, were common, > making high-performance, portable source difficult or impossible. 6-bit and 8-bit chars were the least of it. Even without vendor extensions, writing portable Fortran code was hard. Different floating point formats give you different results, and architectural differences can bite you. One famous example is that the 709x required word alignment, but S/360 had 4 byte aligned floats and 8 byte aligned doubles, so this: REAL R(100) DOUBLE PRECISION D(10) EQUIVALENCE (R(2), D(1)) would work fine on a 7090 but crash on a 360. That was painful enough that one of the first things they changed on S/370 was to allow misaligned data. I never wrote much COBOL but it had structured data (the ancestor of C structs) and "redefines" for overlaying structures which could bite you when different machines had different size or alignment. There were also a lot of different character sets which led to bugs when code had implicit assumptions about collating sequences, e.g., do numbers come before letters as in ASCII, or after as in EBCDIC. The fact that everything now has 8 bit byte addressed memory with power of two data sizes and everything is ASCII makes all these problems go away. > Is this right: > > C was the first ’systems tool’ language + libraries available across many platforms. > Notionally, source code could be ported with zero or minimal change. > It made possible portable languages like PERL, PHP, Python. I think so. There were previous system languages like a PL/I subset on Multics or PL/S on IBM or PL/M on micros but I don't think any of them had multiple targets. > Secondly, portable systems tool languages with a common 2-part design > of parser/front-end providing an abstract syntax tree > to multiple back-ends with platform specific code-generators. > > Are these back-ends where most of the assembler, memory model and instruction optimisation take place now? That's the standard way to build a compiler. Back in the late 1950s someone had the bright idea to invent a common intermediate language they called UNCOL so all of the front ends could produce UNCOL and all of the back ends could translate from UNCOL thereby reducing the NxM compiler problem to N+M. It never worked, both because the semantic differences between source languages are larger than they look, and the machine architectures of the era were wildly different. Now we have GCC and LLVM which are sort of UNCOL-ish, but mostly because the back ends are all so similar. The instruction sets may be different but the data formats are all the same. R's, John From clemc at ccc.com Sun Jul 7 01:58:50 2024 From: clemc at ccc.com (Clem Cole) Date: Sat, 6 Jul 2024 11:58:50 -0400 Subject: [TUHS] mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <6DEE0364-13BF-4DDF-8B42-8EE9DE010211@canb.auug.org.au> References: <20240705213804.550128EDF53C@ary.qy> <20240705214901.GR26356@mcvoy.com> <20240705231714.5F0E58EE123E@ary.qy> <6DEE0364-13BF-4DDF-8B42-8EE9DE010211@canb.auug.org.au> Message-ID: On Sat, Jul 6, 2024 at 8:52 AM wrote: > Is this right: > > C was the first ’systems tool’ language + libraries available > across many platforms. > No !! Not even close. ESPOL predators all of them, although one can say since it was only available on Burroughs large, medium, and small systems - it was retargeted, but not widely used. Other systems programming languages followed, BCPL, BLISS, PL/360 and even B before C. If you consider PL/M a child of PL/360 (which is was more than child of PL/1 if you look at it), all of the others have code generators and libraries for multiple ISA and OS and did before C did. That said, I don't think any fo them have as many targets as C and many FORTRAN. I might accept this rephrasing: *While other systems' programming languages existed, and many were retargets to multiple ISA/OS combinations, because of its appearance as a language with a licensed but open implementation, at the time of the first widespread available of inexpensive microprocessors, the language and it libraries became (and continues to remain) the widest and most popular systems development language in production use.* WRT: FORTRAN. John is correct; Kahan and his students demonstrated the core problem with Paranoia ( https://www.netlib.org/paranoia/ ). But remember that the FP issue was more than just a FORTRAN problem [BTW: I took that class in those days]. You are correct that private extensions were also a problem, although through F4 - the 'standard was IBM's 'G' compiler, and while most vendors ensured they could pass the ANSI test suite, smart vendors made sure they were IBM FORTRAN-G compliant. A good example is the original Adventure game written on DEC's PDP-10 FORTRAN compiler in the late 1970s, but it seemed to be running on anything a FORTRAN compiler within weeks of its release on the ARPAnet [I know that my peeps and I fed it to FORTRAN-G on TSS]. The same issue of "ANSI Standard" vs "De Facto Standard" occurred with F77, but the de facto standard was VMS FORTRAN by that time That said, by F90, which is also post IEEE 754 [FP format] - portable FORTRAN code in the wild was really not the issue it had been in the 60s and 70s. FWIW: With FORTRAN 2018, the compiler most people reference and for code that runs on most supers is Intel's (DEC derived) ifort - but even Intel is replacing that with their investment in IFX, the LLVM-based backend using Intel rewritten (and FOSS) LLVM FORTRAN front end. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.bowling at kev009.com Sun Jul 7 03:50:32 2024 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Sat, 6 Jul 2024 10:50:32 -0700 Subject: [TUHS] 3B21D In-Reply-To: References: Message-ID: On Thu, Jul 4, 2024 at 1:22 PM segaloco wrote: > > On Thursday, July 4th, 2024 at 1:14 PM, Warner Losh wrote: > > > > > > > On Thu, Jul 4, 2024, 2:02 PM Kevin Bowling wrote: > > > > > Howdy, > > > > > > I now have this pictured 3B21D in my facility > > > http://kev009.com/wp/2024/07/Lucent-5ESS-Rescue/ > > > > > > It will be a moment before I can start work on documentation of the > > > 3B21D and DMERT/UNIX-RTR but wanted to share the news. > > > > > > Awesome accomplished. Can't wait to see the outcome. > > > > Warner > > > > > > > > > Regards, > > > Kevin > > Kudos, I'm quite envious, this is awesome news! I appreciate your writeup, touching on the odd world this lives in, between computer and telecom appliance. Whether the 3B20 family was liked out in the general computing world or not, the impact on telecommunications is clear with the long shadow of the 5ESS family of switches. Thank you. The goal is to share the system, virtually and physically, with interested parties. > Hopefully Lucent was still keen on providing /usr/src and /usr/man :) > > I'm still holding out hope a WECo-era machine pops up someday...but either way, glad to finally see something in this lineage in the hands of someone with a keen eye for UNIX and Bell System history! I'm not sure myself how similar the 3B20 and 3B2 are and it will be a topic of inquiry since I now have the ability. My initial impression is that the 3B20 is a fully custom logic and microcoded minicomputer specific to the fault tolerant and DMA I/O administrative workload it was designed for. You can get a flavor of what custom control entails from Wing N. Toy's books and some of the BSTJ articles on the 5ESS as this is a forgotten design skill. The 3B2 is a more common microprocessor minicomputer and not far removed from a VAX of similar age. I don't believe there is explicit compatibility between the 3B20 and 3B2, although a 3B20S running SysV would offer a high degree of source compatibility. I'm sure you've seen it but I will plug Seth Morabito's 3B2 emulator, you can get a very good feel for what a 3B2 UNIX is like (not that great :)) from it. > > - Matt G. From johnl at taugh.com Sun Jul 7 06:56:16 2024 From: johnl at taugh.com (John R Levine) Date: 6 Jul 2024 16:56:16 -0400 Subject: [TUHS] mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <20240705213804.550128EDF53C@ary.qy> <20240705214901.GR26356@mcvoy.com> <20240705231714.5F0E58EE123E@ary.qy> <6DEE0364-13BF-4DDF-8B42-8EE9DE010211@canb.auug.org.au> Message-ID: <6c797638-8fef-a587-0f73-cdb564568950@taugh.com> On Sat, 6 Jul 2024, Clem Cole wrote: > ESPOL predators all of them, although one can say since it was only > available on Burroughs large, medium, and small systems - it was retargeted, > but not widely used. Good point. > Other systems programming languages followed, BCPL, BLISS, PL/360 and even > B before C. If you consider PL/M a child of PL/360 (which is was more than > child of PL/1 if you look at it), all of the others have code generators > and libraries for multiple ISA and OS and did before C did. That said, I > don't think any fo them have as many targets as C and many FORTRAN. Untangling the sequence of all this stuff is hard. BCPL was indeed retargeted at a lot of machines but it's not clear how portable programs were since the word sizes varied so much from 16 to 60 bits, but couldn't deal with byte addressed memory which is a large reason we have C. The original version of BLISS was only for the PDP-10. DEC retargeted it to the PDP-11 and VAX, but I think that was after Unix moved to the Interdata and possibly other machines. PL360 was Wirth's implentation language for Algol W, a 360 assembler with Algol-like syntax that had nothing to do with PL/I and only targeted the 360. I used it, it was pretty nice. Are you maybe thinking of IBM's PL.8 or PL/S? The former was originally for the 801, later S/360 and ROMP, the latter used for S/360 system programming. PL.8 was about 80% of PL.I, hence the name, PL/S a subset with some hackery like register declarations and in-line assembler. R's, John From sauer at technologists.com Sun Jul 7 07:32:11 2024 From: sauer at technologists.com (Charles H Sauer (he/him)) Date: Sat, 6 Jul 2024 16:32:11 -0500 Subject: [TUHS] mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <6c797638-8fef-a587-0f73-cdb564568950@taugh.com> References: <20240705213804.550128EDF53C@ary.qy> <20240705214901.GR26356@mcvoy.com> <20240705231714.5F0E58EE123E@ary.qy> <6DEE0364-13BF-4DDF-8B42-8EE9DE010211@canb.auug.org.au> <6c797638-8fef-a587-0f73-cdb564568950@taugh.com> Message-ID: On 7/6/2024 3:56 PM, John R Levine wrote: > On Sat, 6 Jul 2024, Clem Cole wrote: >> ESPOL predators all of them, although one can say since it was only >> available on Burroughs large, medium, and small systems - it was >> retargeted, >> but not widely used. > > Good point. > >> Other systems programming languages followed, BCPL, BLISS, PL/360 and >> even >> B before C. If you consider PL/M a child of PL/360 (which is was more >> than >> child of PL/1 if you look at it), all of the others have code generators >> and libraries for multiple ISA and OS and did before C did. That said, I >> don't think any fo them have as many targets as C and many FORTRAN. > > Untangling the sequence of all this stuff is hard.  BCPL was indeed > retargeted at a lot of machines but it's not clear how portable programs > were since the word sizes varied so much from 16 to 60 bits, but > couldn't deal with byte addressed memory which is a large reason we have C. > > The original version of BLISS was only for the PDP-10.  DEC retargeted > it to the PDP-11 and VAX, but I think that was after Unix moved to the > Interdata and possibly other machines. > > PL360 was Wirth's implentation language for Algol W, a 360 assembler > with Algol-like syntax that had nothing to do with PL/I and only > targeted the 360.  I used it, it was pretty nice. > > Are you maybe thinking of IBM's PL.8 or PL/S?  The former was originally > for the 801, later S/360 and ROMP, the latter used for S/360 system > programming.  PL.8 was about 80% of PL.I, hence the name, PL/S a subset > with some hackery like register declarations and in-line assembler. > > R's, > John I like the 80% explanation, but suspect PL.8 was really named PL.8 to go along with the 801 processor architecture defined in Building 801 aka Thomas J. Watson Research Center in Yorktown Heights. There are probably living Yorktown alumni that could be definitive. I found PL/I quite usable as long as one kept it simple. But then, I also found Fortran usable as long as one kept it simple. Regarding Fortran portability, I did all my dissertation work on punched cards using CDC Fortran on the 6400/6600 at the UT-Austin computation center. I brought several boxes of cards to Yorktown and don't remember any significant difficulty getting my simulator and other programs to run on VM/370 there. The absence of pointers and structures in Fortran was annoying. Eventually I used SNOBOL to quickly translate the Fortran to PL/I (https://technologists.com/sauer/RESQPPP.pdf). Charlie -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/LinkedIn/Twitter: CharlesHSauer From peter.martin.yardley at gmail.com Sun Jul 7 09:46:10 2024 From: peter.martin.yardley at gmail.com (Peter Yardley) Date: Sun, 7 Jul 2024 09:46:10 +1000 Subject: [TUHS] mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <20240705213804.550128EDF53C@ary.qy> <20240705214901.GR26356@mcvoy.com> <20240705231714.5F0E58EE123E@ary.qy> <6DEE0364-13BF-4DDF-8B42-8EE9DE010211@canb.auug.org.au> <6c797638-8fef-a587-0f73-cdb564568950@taugh.com> Message-ID: There was a ‘military’ standard ForTran 66. It was more difficult to use than the various ForTran IVs, which had several niceties like string literals, but the code was at least more portable. This was about 40 years ago so details are fading. > On 7 Jul 2024, at 7:32 AM, Charles H Sauer (he/him) wrote: > > > > On 7/6/2024 3:56 PM, John R Levine wrote: >> On Sat, 6 Jul 2024, Clem Cole wrote: >>> ESPOL predators all of them, although one can say since it was only >>> available on Burroughs large, medium, and small systems - it was retargeted, >>> but not widely used. >> Good point. >>> Other systems programming languages followed, BCPL, BLISS, PL/360 and even >>> B before C. If you consider PL/M a child of PL/360 (which is was more than >>> child of PL/1 if you look at it), all of the others have code generators >>> and libraries for multiple ISA and OS and did before C did. That said, I >>> don't think any fo them have as many targets as C and many FORTRAN. >> Untangling the sequence of all this stuff is hard. BCPL was indeed retargeted at a lot of machines but it's not clear how portable programs were since the word sizes varied so much from 16 to 60 bits, but couldn't deal with byte addressed memory which is a large reason we have C. >> The original version of BLISS was only for the PDP-10. DEC retargeted it to the PDP-11 and VAX, but I think that was after Unix moved to the Interdata and possibly other machines. >> PL360 was Wirth's implentation language for Algol W, a 360 assembler with Algol-like syntax that had nothing to do with PL/I and only targeted the 360. I used it, it was pretty nice. >> Are you maybe thinking of IBM's PL.8 or PL/S? The former was originally for the 801, later S/360 and ROMP, the latter used for S/360 system programming. PL.8 was about 80% of PL.I, hence the name, PL/S a subset with some hackery like register declarations and in-line assembler. >> R's, >> John > > I like the 80% explanation, but suspect PL.8 was really named PL.8 to go along with the 801 processor architecture defined in Building 801 aka Thomas J. Watson Research Center in Yorktown Heights. There are probably living Yorktown alumni that could be definitive. > > I found PL/I quite usable as long as one kept it simple. But then, I also found Fortran usable as long as one kept it simple. Regarding Fortran portability, I did all my dissertation work on punched cards using CDC Fortran on the 6400/6600 at the UT-Austin computation center. I brought several boxes of cards to Yorktown and don't remember any significant difficulty getting my simulator and other programs to run on VM/370 there. The absence of pointers and structures in Fortran was annoying. Eventually I used SNOBOL to quickly translate the Fortran to PL/I (https://technologists.com/sauer/RESQPPP.pdf). > > Charlie > > -- > voice: +1.512.784.7526 e-mail: sauer at technologists.com > fax: +1.512.346.5240 Web: https://technologists.com/sauer/ > Facebook/Google/LinkedIn/Twitter: CharlesHSauer Peter Yardley peter.martin.yardley at gmail.com From johnl at taugh.com Sun Jul 7 11:39:33 2024 From: johnl at taugh.com (John Levine) Date: 6 Jul 2024 21:39:33 -0400 Subject: [TUHS] mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <20240705213804.550128EDF53C@ary.qy> <20240705214901.GR26356@mcvoy.com> <6DEE0364-13BF-4DDF-8B42-8EE9DE010211@canb.auug.org.au> <20240705231714.5F0E58EE123E@ary.qy> <6c797638-8fef-a587-0f73-cdb564568950@taugh.com> Message-ID: <20240707013933.5579F8EF1AA8@ary.qy> It appears that Charles H Sauer (he/him) said: >I like the 80% explanation, but suspect PL.8 was really named PL.8 to go >along with the 801 processor architecture defined in Building 801 aka >Thomas J. Watson Research Center in Yorktown Heights. There are probably >living Yorktown alumni that could be definitive. John Cocke said in a paper in IBM J R&D V44 #1/2, Jan 2000, p 50: The result [of the language design] was the PL.8 language, the ".8" implying that it had about 80% of the richness of PL/I. PL.8 bore the same relation to PL/I as the 801 architecture had to System/370. Not gonna argue with him. >I found PL/I quite usable as long as one kept it simple. But then, I >also found Fortran usable as long as one kept it simple. Regarding >Fortran portability, I did all my dissertation work on punched cards >using CDC Fortran on the 6400/6600 at the UT-Austin computation center. >I brought several boxes of cards to Yorktown and don't remember any >significant difficulty getting my simulator and other programs to run on >VM/370 there. The absence of pointers and structures in Fortran was >annoying. Eventually I used SNOBOL to quickly translate the Fortran to >PL/I (https://technologists.com/sauer/RESQPPP.pdf). For the most part Fortran could be pretty portable. The hard parts were when you were trying to get reliable numeric results in complex calculations, or you were doing stuff that Fortran didn't do very well like pre-F77 string handling. R's, JOhn From sauer at technologists.com Sun Jul 7 13:26:00 2024 From: sauer at technologists.com (Charles H Sauer (he/him)) Date: Sat, 6 Jul 2024 22:26:00 -0500 Subject: [TUHS] PL.8 [was Re: mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <20240707013933.5579F8EF1AA8@ary.qy> References: <20240705213804.550128EDF53C@ary.qy> <20240705214901.GR26356@mcvoy.com> <6DEE0364-13BF-4DDF-8B42-8EE9DE010211@canb.auug.org.au> <20240705231714.5F0E58EE123E@ary.qy> <6c797638-8fef-a587-0f73-cdb564568950@taugh.com> <20240707013933.5579F8EF1AA8@ary.qy> Message-ID: On 7/6/2024 8:39 PM, John Levine wrote: > It appears that Charles H Sauer (he/him) said: >> I like the 80% explanation, but suspect PL.8 was really named PL.8 to go >> along with the 801 processor architecture defined in Building 801 aka >> Thomas J. Watson Research Center in Yorktown Heights. There are probably >> living Yorktown alumni that could be definitive. > > John Cocke said in a paper in IBM J R&D V44 #1/2, Jan 2000, p 50: > > The result [of the language design] was the PL.8 language, the > ".8" implying that it had about 80% of the richness of PL/I. > PL.8 bore the same relation to PL/I as the 801 architecture > had to System/370. > > Not gonna argue with him. John C isn't around to say one way or the other. Perhaps he really did say that, but ... o That paper seems to be a reprint of the 1990 IBM J R&D V34 paper o I suspect co-author Vicky wrote 80% of the paper and wrote the 80% sentence. (I had substantial contact with Vicky at IBM. She and Peter became my neighbors for a while after I left IBM. Peter was also a judge at cat shows and I would see him at those.) o Marc Auslander and Marty Hopkins seemed to be the driving forces behind the PL.8 compiler and language. I think their June 1982 "An Overview of the PL.8 Compiler" SIGPLAN Notices 17 (6) was the first external notice of the compiler and language. o Radin's 1976 "The 801 minicomputer" eventually appeared externally in March 1982 SIGPLAN Notices 17 (4). That paper refers to the "801 compiler" and alludes to differences from PL/I that typified PL.8, e.g., offsets vs. pointers, but doesn't name the language. o ".8" implying 80% of the richness of PL/I sounds revisionist Far afield from TUHS... Charlie -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/LinkedIn/Twitter: CharlesHSauer From arnold at skeeve.com Sun Jul 7 15:33:23 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sat, 06 Jul 2024 23:33:23 -0600 Subject: [TUHS] mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <20240705231714.5F0E58EE123E@ary.qy> References: <20240705213804.550128EDF53C@ary.qy> <20240705214901.GR26356@mcvoy.com> <20240705231714.5F0E58EE123E@ary.qy> Message-ID: <202407070533.4675XNi01394214@freefriends.org> "John Levine" wrote: > These days we write code and compile it for x64 or ARM or RISC-V and > for the most part, it just works because the data formats and addressing > are all the same. I have to agree with this. My experience is that for most[1] user level code, the architecture simply doesn't matter. I started working on gawk on vaxen, moved to MC68010, then to Sparc, then to 32-bit x86, then to 64-bit x86, with a side segue to 32-bit PPC. Other people compile it on everything else: ARM, S/390, Alpha, Itanium, RISC-V, you name it. OS differences matter more than architecutre differences. This list's membership is heavily weighted with compiler writers and OS porters, which is fine, but that's a very small percentage of the number of people out in the world writing code. Those folks (including me in my $DAYJOB) all work in C++, Java, Python, Rust, and Go, and the architecture simply doesn't matter to them. (C# is nominally portable as well, but hasn't caught on outside of Windows like the others.) I *do* think that studying a nice architecture, like the PDP-11, is important for people learning software development. In college I took data structures and algorithms together with PDP-11 assembler, and it was only when I saw how recursion worked in assembler with the stack that I finally understood it. It was a real epiphany. My two cents, Arnold [1] Architecture does come into play if you're writing _binary_ data, which is why RPC/XDR were invented for NFS and why Google has it's RPC language and libraries. From jnc at mercury.lcs.mit.edu Sun Jul 7 23:57:32 2024 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 7 Jul 2024 09:57:32 -0400 (EDT) Subject: [TUHS] mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? Message-ID: <20240707135732.8928518C089@mercury.lcs.mit.edu> > From: Steve Jenkin > C wasn't the first standardised coding language, FORTRAN & COBOL at > least were before it There were a ton; Algol-60 is the most imppotant one I can think of. (I was thinking that Algol-60 was probably an important precursor to BCPL, which was the predecessor to C, but Richards' first BCPL paper: https://dl.acm.org/doi/10.1145/1476793.1476880 "BCPL: A tool for compiler writing and system programming" doesn't call it out, only CPL. However, CPL does admit its dues to Algol-60: "CPL is to a large extent based on ALGOL 60".) Noel From johnl at taugh.com Mon Jul 8 02:43:31 2024 From: johnl at taugh.com (John Levine) Date: 7 Jul 2024 12:43:31 -0400 Subject: [TUHS] mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <20240707135732.8928518C089@mercury.lcs.mit.edu> References: <20240707135732.8928518C089@mercury.lcs.mit.edu> Message-ID: <20240707164331.BCB568F007E4@ary.qy> It appears that Noel Chiappa said: > > From: Steve Jenkin > > > C wasn't the first standardised coding language, FORTRAN & COBOL at > > least were before it > >There were a ton; Algol-60 is the most imppotant one I can think of. Only sort of. It didn't have a standard concrete representation, and it didn't have any I/O, so it was fine for portable elegant numerical solutions to partial differential equations, but hopeless for portably reading in a list of numbers and printing the sum. In 1964 they defined what were supposed to be standard I/O routines but it was too little too late. Wirth's Algol W and Pascal were supposed to fix that but Pascal never was all that portable in practice. R's, John From frew at ucsb.edu Mon Jul 8 03:43:36 2024 From: frew at ucsb.edu (James Frew) Date: Sun, 7 Jul 2024 10:43:36 -0700 Subject: [TUHS] mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <20240705213804.550128EDF53C@ary.qy> <20240705214901.GR26356@mcvoy.com> <20240705231714.5F0E58EE123E@ary.qy> <6DEE0364-13BF-4DDF-8B42-8EE9DE010211@canb.auug.org.au> <6c797638-8fef-a587-0f73-cdb564568950@taugh.com> Message-ID: <8ee0e7cb-398c-4394-9ca5-be1b0f70c0fc@ucsb.edu> On 2024-07-06 16:46, Peter Yardley wrote: > There was a ‘military’ standard ForTran 66. It was more difficult to use than the various ForTran IVs, which had several niceties like string literals, but the code was at least more portable. This was about 40 years ago so details are fading. https://apps.dtic.mil/sti/tr/pdf/ADA328606.pdf Not the actual standard, but the single most useful reference on porting old FORTRAN. From the Foreword: "This FORTRAN volume presents material that will assist in understanding FORTRAN 66 and its replacement, FORTRAN 77. Because even a superficial comparison of the two language variants will involve contrasting their respective syntaxes, a set of FORTRAN 66 grammar rules is included: These rules, expressed in chart form, are comparable to rules that define FORTRAN 77. Next, there are two chapters of observations on what using standard FORTRAN 66 implies, and how the 1966 Standard is often interpreted and stretched to achieve practical ends. Finally, a comparison of the new FORTRAN 77 with FORTRAN 66 shows how the language has changed, and what converting older programs must entail. The four chapters address programmers concerned with FORTRAN conversions, managers engaged in programming standards, and other practitioners interested in system influences upon languages. Since the text touches upon several general programming aspects (input/output, storage allocation and lifetimes, control structures), the volume's appeal will extend beyond the immediate FORTRAN community." Cheers, /Frew P.S.: If anybody cares, I have a cleaner scan that I can share. From dave at horsfall.org Mon Jul 8 08:00:46 2024 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 8 Jul 2024 08:00:46 +1000 (EST) Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024, Peter Yardley wrote: > The DG Nova had a pretty nice architecture. 2 accumulators, 2 index > registers, program counter, status register. No stack register tho. > There was a micro processor version by Fairchild. The story behind it is interesting too. The designer at DEC (Ed de Castro) tried to promote it, Ken Olson didn't like it, so he left to form Data General and created the DG Nova. OK, not a Unix box... -- Dave From brad at anduin.eldar.org Mon Jul 8 09:28:04 2024 From: brad at anduin.eldar.org (Brad Spencer) Date: Sun, 07 Jul 2024 19:28:04 -0400 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: (message from Dave Horsfall on Mon, 8 Jul 2024 08:00:46 +1000 (EST)) Message-ID: Dave Horsfall writes: > On Fri, 5 Jul 2024, Peter Yardley wrote: > >> The DG Nova had a pretty nice architecture. 2 accumulators, 2 index >> registers, program counter, status register. No stack register tho. >> There was a micro processor version by Fairchild. > > The story behind it is interesting too. The designer at DEC (Ed de > Castro) tried to promote it, Ken Olson didn't like it, so he left to form > Data General and created the DG Nova. > > OK, not a Unix box... > > -- Dave I believe AOS for the Nova... and AOS/VS for the Supernova, aka the MV series. I got very good at dealing with AOS/VS at a university I attended. The later MV/xxxxx Supernova boxes could run Unix, I believe... (at least I remember the university running Unix on a MV series after I left). -- Brad Spencer - brad at anduin.eldar.org - KC8VKS - http://anduin.eldar.org From johnl at taugh.com Mon Jul 8 10:21:01 2024 From: johnl at taugh.com (John Levine) Date: 8 Jul 2024 00:21:01 -0000 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: Message-ID: According to Dave Horsfall : >On Fri, 5 Jul 2024, Peter Yardley wrote: > >> The DG Nova had a pretty nice architecture. 2 accumulators, 2 index >> registers, program counter, status register. No stack register tho. >> There was a micro processor version by Fairchild. > >The story behind it is interesting too. The designer at DEC (Ed de >Castro) tried to promote it, Ken Olson didn't like it, so he left to form >Data General and created the DG Nova. That's the folklore but the reality is somewhat more nuanced than that. He was working on PDP-X, a 16 bit word addressed line of machines in the style of the PDP-8 and -9: https://bitsavers.org/pdf/dec/pdp-x/29_Nov67.pdf When management decided to build the PDP-11, de Castro did indeed quit and started DG, but the Nova was quite different from the PDP-X. It was a clever design that used new MSI chips so the processor fit on one board and was, I assume, pretty cheap to build. -- Regards, John Levine, johnl at taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From dave at horsfall.org Mon Jul 8 10:35:29 2024 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 8 Jul 2024 10:35:29 +1000 (EST) Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024, John Levine wrote: [...] > When management decided to build the PDP-11, de Castro did indeed quit > and started DG, but the Nova was quite different from the PDP-X. It was > a clever design that used new MSI chips so the processor fit on one > board and was, I assume, pretty cheap to build. Thanks for the clarification. -- Dave From dave at horsfall.org Mon Jul 8 16:17:53 2024 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 8 Jul 2024 16:17:53 +1000 (EST) Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: Message-ID: On Sun, 7 Jul 2024, Brad Spencer wrote: > I believe AOS for the Nova... and AOS/VS for the Supernova, aka the MV > series. I got very good at dealing with AOS/VS at a university I > attended. The later MV/xxxxx Supernova boxes could run Unix, I > believe... (at least I remember the university running Unix on a MV > series after I left). Ah yes, I remember hearing of Unix on the MV series, but never actually saw one. Looks like a neat machine. -- Dave (vk2kfu) From lars at nocrew.org Mon Jul 8 16:27:51 2024 From: lars at nocrew.org (Lars Brinkhoff) Date: Mon, 08 Jul 2024 06:27:51 +0000 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: (Brad Spencer's message of "Sun, 07 Jul 2024 19:28:04 -0400") References: Message-ID: <7w5xtg8kk8.fsf@junk.nocrew.org> Brad Spencer wrote: > I believe AOS for the Nova... and AOS/VS for the Supernova, aka the MV > series. I believe the Supernova was an early and faster implementation of the regular Nova. A newer generation, still 16-bit, was called Eclipse. MV was the ("NO MODE BIT!") 32-bit generation. Or something like that. DG then bet on the short-lived Motorola 88000 with a series called the AViiON ("NOVA ii"?). From arnold at skeeve.com Mon Jul 8 16:59:14 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 08 Jul 2024 00:59:14 -0600 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: Message-ID: <202407080659.4686xEpc1504559@freefriends.org> Brad Spencer wrote: > The later MV/xxxxx Supernova boxes could run Unix, I > believe... (at least I remember the university running Unix on a MV > series after I left). I think these were called "Eclipse", and the story of their development is told in the famous book "The Soul of a New Machine". For you youngsters out there, it's a great read. We had one at Georgia Tech, it ran a Unix emulation on top of AOS (or whatever it was called). Later on DG ported Unix to run on it native. Arnold From dave at horsfall.org Mon Jul 8 16:51:51 2024 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 8 Jul 2024 16:51:51 +1000 (EST) Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <7w5xtg8kk8.fsf@junk.nocrew.org> References: <7w5xtg8kk8.fsf@junk.nocrew.org> Message-ID: On Mon, 8 Jul 2024, Lars Brinkhoff wrote: > I believe the Supernova was an early and faster implementation of the > regular Nova. A newer generation, still 16-bit, was called Eclipse. > MV was the ("NO MODE BIT!") 32-bit generation. Or something like that. > DG then bet on the short-lived Motorola 88000 with a series called the > AViiON ("NOVA ii"?). I'd never thought about that derivation! -- Dave From davida at pobox.com Mon Jul 8 19:36:34 2024 From: davida at pobox.com (David Arnold) Date: Mon, 8 Jul 2024 19:36:34 +1000 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: Message-ID: <3DA1F208-422C-44C0-A014-6D1A269A307E@pobox.com> > On 8 Jul 2024, at 17:36, Dave Horsfall wrote: > > On Mon, 8 Jul 2024, Lars Brinkhoff wrote: >> >> DG then bet on the short-lived Motorola 88000 with a series called the >> AViiON ("NOVA ii"?). > > I'd never thought about that derivation! I wonder if it could extend to the CLARiiON storage arrays as well? d From peter.martin.yardley at gmail.com Mon Jul 8 22:29:04 2024 From: peter.martin.yardley at gmail.com (Peter Yardley) Date: Mon, 8 Jul 2024 22:29:04 +1000 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: Message-ID: <67F367A2-71D5-4AB8-A1AF-2DBE37F28A6C@gmail.com> Just a recollection … Our department sold our Nova to the Navy (RAN) as part of a programming course on Novas and microcomputers. The Navy still used the Novas as gunnery computers, possibly amongst things, ours was going to be used for training. It had core memory, which was an advantage in the turrets of the frigates (hard drives of the time didn’t survive the shock). One of my colleagues used to fix the core memory using a magnifying loupe and a fine soldering iron. We had Algol, ForTran and 8080 and 6502 cross assemblers amongst other things. There was a 16 user editor and you had to line up on the system console to be able to do a compilation (we were running a foreground/background OS, it was a pretty small system). We all used the same directory and had to name our files with our initials. > On 8 Jul 2024, at 8:00 AM, Dave Horsfall wrote: > > On Fri, 5 Jul 2024, Peter Yardley wrote: > >> The DG Nova had a pretty nice architecture. 2 accumulators, 2 index >> registers, program counter, status register. No stack register tho. >> There was a micro processor version by Fairchild. > > The story behind it is interesting too. The designer at DEC (Ed de > Castro) tried to promote it, Ken Olson didn't like it, so he left to form > Data General and created the DG Nova. > > OK, not a Unix box... > > -- Dave .1.3.6.1.4.1.8852.4.2 Peter Yardley peter.martin.yardley at gmail.com From lm at mcvoy.com Mon Jul 8 23:22:18 2024 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 8 Jul 2024 06:22:18 -0700 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <202407080659.4686xEpc1504559@freefriends.org> References: <202407080659.4686xEpc1504559@freefriends.org> Message-ID: <20240708132218.GF18818@mcvoy.com> On Mon, Jul 08, 2024 at 12:59:14AM -0600, arnold at skeeve.com wrote: > Brad Spencer wrote: > > > The later MV/xxxxx Supernova boxes could run Unix, I > > believe... (at least I remember the university running Unix on a MV > > series after I left). > > I think these were called "Eclipse", and the story of their > development is told in the famous book "The Soul of a New Machine". > For you youngsters out there, it's a great read. > > We had one at Georgia Tech, it ran a Unix emulation on top > of AOS (or whatever it was called). Later on DG ported Unix to > run on it native. I've heard, but never verified, that they did a really nice SMP Unix. If anyone has seen the code I'd like to hear what you thought. The way it was described to me, it sounded like an SMP SunOS. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From brad at anduin.eldar.org Tue Jul 9 01:28:34 2024 From: brad at anduin.eldar.org (Brad Spencer) Date: Mon, 08 Jul 2024 11:28:34 -0400 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <202407080659.4686xEpc1504559@freefriends.org> (arnold@skeeve.com) Message-ID: arnold at skeeve.com writes: > Brad Spencer wrote: > >> The later MV/xxxxx Supernova boxes could run Unix, I >> believe... (at least I remember the university running Unix on a MV >> series after I left). > > I think these were called "Eclipse", and the story of their > development is told in the famous book "The Soul of a New Machine". > For you youngsters out there, it's a great read. Ya, that is right... I didn't remember that correctly. The Eclipse was the MV series, 32 bit, and ran AOS/VS, the Nova, 16 bit, ran AOS. > We had one at Georgia Tech, it ran a Unix emulation on top > of AOS (or whatever it was called). Later on DG ported Unix to > run on it native. I was there for the start of that emulation layer stuff for AOS/VS. When I encountered it, it was just, mostly, something that helped port software written for Unix to AOS/VS. I remember two things that made that very hard, the lack of any sort of fork() notion in AOS/VS and the lack of any sort of setuid() notion. You pretty much couldn't do either of those in any manor. There was an idea much like fork()+exec() that could be used to start a new program, but that required source changes. I very much remember a port of sendmail that couldn't be used to deliver mail to a local user on the box because you didn't have setuid() and couldn't fake it as a normal user. It was nice to hear that DG did a real Unix port, but that was after my time. > Arnold -- Brad Spencer - brad at anduin.eldar.org - KC8VKS - http://anduin.eldar.org From aek at bitsavers.org Tue Jul 9 01:33:49 2024 From: aek at bitsavers.org (Al Kossow) Date: Mon, 8 Jul 2024 08:33:49 -0700 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: Message-ID: <25396e1b-c53a-4828-9fb4-c17e3a6946a5@bitsavers.org> > I was there for the start of that emulation layer stuff for AOS/VS. I think this has been asked before, but does anyone have the Portable Operating System Pascal sources that were done there? This isn't the same as the portable tools stuff that started out in the Prentice-Hall book and shows up on DECUS tapes. From aek at bitsavers.org Tue Jul 9 01:37:39 2024 From: aek at bitsavers.org (Al Kossow) Date: Mon, 8 Jul 2024 08:37:39 -0700 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <20240708132218.GF18818@mcvoy.com> References: <202407080659.4686xEpc1504559@freefriends.org> <20240708132218.GF18818@mcvoy.com> Message-ID: <7c987675-9985-fac5-b7fc-51441bf7f72d@bitsavers.org> >> I think these were called "Eclipse" Eclipse is a 16 bit system that predates the MV see http://bitsavers.org/pdf/dg/eclipse .ca 1974 as opposed to mv4000 mv8000 (ca. 1980) mv10000 From clemc at ccc.com Tue Jul 9 03:04:42 2024 From: clemc at ccc.com (Clem Cole) Date: Mon, 8 Jul 2024 13:04:42 -0400 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <20240708132218.GF18818@mcvoy.com> References: <202407080659.4686xEpc1504559@freefriends.org> <20240708132218.GF18818@mcvoy.com> Message-ID: Al is right. Tom West led the Eagle project in Westboro, MA, which is documented in the Soul of the New Machine. The Eagle project became the 32-bit MV/8000 Eclipse [see https://en.wikipedia.org/wiki/Data_General for more details]. I knew a few of the HW guys, as I went to CMU with one of them, and a couple of them came to do the Stellar CPU a few years later. But I did not know the SW folks there like I know the DEC folks, particularly since I never worked there. That said, WRT to their later UNIX box, I did have access to the same at Locus. As we did a lot of work for DG, adding features and helping them with POSIX/FIPS and SPEC1170 conformance — IIRC, we added the FS Switch for NFS support. It was probably the easiest UNIX kernel I have ever worked with, with the shortest learning curve. I may remember that the User API was based on SVR3/SVID, which means >>IIRC<<; it was based on Streams/TLI, but ISTR is a user mode sockets layer for porting (but I'm not sure of that -- it has been almost 30 years now). The kernel itself was a scratch rewrite with SMP in mind. The locking scheme was clean and simple and worked well to order 32/64 processors in our tests. Moreover, the kernel was well-documented. I do not know for sure, but I remember being told by some of the DG folks in NC that it was originally planned for the failed Fountainhead system, which was canceled after West and the MA-based folks delivered Eagle before the new system came from DG NC. Also, I believe that DG had in response to BLISS a low-level system language they called PL/N, but I don't know much about it/I never saw it - I'm told that it was a >>very<< subset PL/1 syntax, but like PL/360 - exposed a lot of hardware. ISTR that they developed some MV series compilers with it, but since Eagle was a 32-bit super set of Nova, AOS was ported. FWIW:. Since Multics had used PL/1 and supposedly Fountainhead was heavily influenced by Multics (as was Pr1me, by the way), it would not surprise me that PL/n has a PL/1 'flavor.' I'd love to know for sure >>but my WAG<< is that that core work for Fountainhead was reimplemented in C for their SMP 88000 box, and they added a UNIX API layer to it. ᐧ On Mon, Jul 8, 2024 at 9:22 AM Larry McVoy wrote: > On Mon, Jul 08, 2024 at 12:59:14AM -0600, arnold at skeeve.com wrote: > > Brad Spencer wrote: > > > > > The later MV/xxxxx Supernova boxes could run Unix, I > > > believe... (at least I remember the university running Unix on a MV > > > series after I left). > > > > I think these were called "Eclipse", and the story of their > > development is told in the famous book "The Soul of a New Machine". > > For you youngsters out there, it's a great read. > > > > We had one at Georgia Tech, it ran a Unix emulation on top > > of AOS (or whatever it was called). Later on DG ported Unix to > > run on it native. > > I've heard, but never verified, that they did a really nice SMP Unix. > If anyone has seen the code I'd like to hear what you thought. The > way it was described to me, it sounded like an SMP SunOS. > -- > --- > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pugs78 at gmail.com Tue Jul 9 03:22:09 2024 From: pugs78 at gmail.com (Tom Lyon) Date: Mon, 8 Jul 2024 10:22:09 -0700 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <7c987675-9985-fac5-b7fc-51441bf7f72d@bitsavers.org> References: <202407080659.4686xEpc1504559@freefriends.org> <20240708132218.GF18818@mcvoy.com> <7c987675-9985-fac5-b7fc-51441bf7f72d@bitsavers.org> Message-ID: Here's a scan of the DG Eclipse MV-8000 Product Summary. Fairly detailed. https://drive.google.com/file/d/1SqvetITVo4mRp8vLB0pU2p8hZT6tXW5z/view?usp=sharing On Mon, Jul 8, 2024 at 8:37 AM Al Kossow wrote: > > >> I think these were called "Eclipse" > > Eclipse is a 16 bit system that predates the MV > > see http://bitsavers.org/pdf/dg/eclipse .ca 1974 > as opposed to > mv4000 mv8000 (ca. 1980) mv10000 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aki at insinga.com Tue Jul 9 07:39:39 2024 From: aki at insinga.com (Aron Insinga) Date: Mon, 8 Jul 2024 17:39:39 -0400 Subject: [TUHS] mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <20240705213804.550128EDF53C@ary.qy> <20240705214901.GR26356@mcvoy.com> <20240705231714.5F0E58EE123E@ary.qy> <6DEE0364-13BF-4DDF-8B42-8EE9DE010211@canb.auug.org.au> <6c797638-8fef-a587-0f73-cdb564568950@taugh.com> Message-ID: <7e4a089d-038d-4054-b315-ff41c8396a47@insinga.com> See https://www.cs.tufts.edu/~nr/cs257/archive/ronald-brender/bliss.pdf C allowed writing Unix with a limited amount of assembly code, but CMU's original BLISS-10 was designed to write an operating system with *no* outside assembly code.  Features like the 'MACHOP' (machine operation) builtin function made use of  the orthogonality of the PDP-10 instruction format to execute machine-specific instructions in-line.  (cf. the 'asm' extensions in some implementations of C.)  The PDP-10's 36-bit word allowed single-precision floating point numbers to fit in machine words, so it had infix operators for both integer and single-precision floating point operations (which I presume were adequate for an operating system). When DEC chose an implementation language, they knew about C but it had not yet escaped from Bell Labs.  PL/I was considered, but there were questions of whether or not it would be suitable for a minicomputer.  On the other hand, by choosing BLISS, DEC could start with the BLISS-11 cross compiler running on the PDP-10, which is described in https://en.wikipedia.org/wiki/The_Design_of_an_Optimizing_Compiler BLISS-11 and DEC's Common BLISS had changes necessitated by different word lengths and architectures, including different routine linkages such as INTERRUPT, access to machine-specific operations such as INSQTI, and multiple-precision floating point operations using builtin functions which used the addresses of data instead of the values. In order to port VMS to new architectures, DEC/HP/VSI retargeted and ported the BLISS compilers to new architectures. What I find amazing is that they also turned the VAX MACRO assembly language (in which some of the VMS operating system was written) into a portable implementation language by 'compiling' the high-level CISC VAX instructions (and addressing modes) into sequences of RISC instructions.  I believe that this is similar to how modern CPU chips dynamically translate x86_64 instructions (or whatever) to an internal RISC format. - Aron (Disclaimer: I worked at DEC for a long time and VSI for a short time, but I wasn't responsible for the above work.) On 7/6/24 17:32, Charles H Sauer (he/him) wrote: > On 7/6/2024 3:56 PM, John R Levine wrote: >> On Sat, 6 Jul 2024, Clem Cole wrote: >>> Other systems programming languages followed, BCPL, BLISS, PL/360 >>> and even >>> B before C. >> The original version of BLISS was only for the PDP-10.  DEC >> retargeted it to the PDP-11 and VAX, but I think that was after Unix >> moved to the Interdata and possibly other machines. From paul.winalski at gmail.com Tue Jul 9 08:14:07 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 8 Jul 2024 18:14:07 -0400 Subject: [TUHS] mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <7e4a089d-038d-4054-b315-ff41c8396a47@insinga.com> References: <20240705213804.550128EDF53C@ary.qy> <20240705214901.GR26356@mcvoy.com> <20240705231714.5F0E58EE123E@ary.qy> <6DEE0364-13BF-4DDF-8B42-8EE9DE010211@canb.auug.org.au> <6c797638-8fef-a587-0f73-cdb564568950@taugh.com> <7e4a089d-038d-4054-b315-ff41c8396a47@insinga.com> Message-ID: [redirecting this to COFF] On Mon, Jul 8, 2024 at 5:40 PM Aron Insinga wrote: > > When DEC chose an implementation language, they knew about C but it had > not yet escaped from Bell Labs. PL/I was considered, but there were > questions of whether or not it would be suitable for a minicomputer. On > the other hand, by choosing BLISS, DEC could start with the BLISS-11 > cross compiler running on the PDP-10, which is described in > https://en.wikipedia.org/wiki/The_Design_of_an_Optimizing_Compiler > BLISS-11 > > and DEC's Common BLISS had changes necessitated by different > word lengths and architectures, including different routine linkages > such as INTERRUPT, access to machine-specific operations such as INSQTI, > and multiple-precision floating point operations using builtin functions > which used the addresses of data instead of the values. > > In order to port VMS to new architectures, DEC/HP/VSI retargeted and > ported the BLISS compilers to new architectures. > > There have in general been two approaches to achieving language portability (machine independence). One of them is to provide only abstract data types and operations on them and to completely hide the machine implementation. PL/I and especially Ada use this approach. BLISS does the exact opposite. It takes the least common denominator. All machine architectures have machine words and ways to pick them apart. BLISS has only one data type--the word. It provides a few simple arithmetic and logical operations and also syntax for operating on contiguous sets of bits within a word. More complicated things such as floating point are done by what look like routine calls but are actually implemented in the compiler. BLISS is also a true, full-blown expression language. Statement constructs such as if/then/else have a value and can be used in expressions. In C terminology, everything in BLISS is a lvalue. A semicolon terminates an expression and throws its value away. BLISS is also unusual in that it has an explicit fetch operator, the dot (.). The assignment expression (=) has the semantics "evaluate the expression to the right of the equal sign and then store that value in the location specified by the expression to the left of the equal sign". Supposing that a and b are identifiers for memory locations, the expression: a = b; means "place b (the address of a memory location) at the location given by a (also a memory location)". This is the equivalent of: a = &b; in C. To get C's version of "a = b;" in BLISS you need an explicit fetch operator: a = .b; Forgetting to use the fetch operator is probably the most frequent error made by new BLISS programmers familiar with more conventional languages. DEC used four dialects of BLISS as their primary software development language: BLISS-16, BLISS-32, BLISS-36, and BLISS-64 the numbers indicating the BLISS word size in bits. BLISS-16 targeted the PDP-11 and BLISS-36 the PDP-10. DEC did implementations of BLISS-32 for VAX, MIPS, and x86. BLISS-64 was targeted to both Alpha and Itanium. VSI may have a version of BLISS-64 that generates x86-64 code. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rik at rikfarrow.com Tue Jul 9 08:17:17 2024 From: rik at rikfarrow.com (Rik Farrow) Date: Mon, 8 Jul 2024 15:17:17 -0700 Subject: [TUHS] mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <7e4a089d-038d-4054-b315-ff41c8396a47@insinga.com> References: <20240705213804.550128EDF53C@ary.qy> <20240705214901.GR26356@mcvoy.com> <20240705231714.5F0E58EE123E@ary.qy> <6DEE0364-13BF-4DDF-8B42-8EE9DE010211@canb.auug.org.au> <6c797638-8fef-a587-0f73-cdb564568950@taugh.com> <7e4a089d-038d-4054-b315-ff41c8396a47@insinga.com> Message-ID: When I was tech editing "Operating Systems Concepts", tenth edition, around seven years ago, I downloaded the Linux source and searched all .c and .h files for float and double. There aren't any. Linux does not require floating point support, and that's likely true of other operating systems, where performance is key. It also means that Linux can run on RISC V without floating point support (I know the basic CPU doesn't include it). As for microcode in Intel chips, translation of CISC instructions into its internally used RISC is done as lookups into a table that takes up a good portion of the chip die. Rik On Mon, Jul 8, 2024 at 2:40 PM Aron Insinga wrote: > See https://www.cs.tufts.edu/~nr/cs257/archive/ronald-brender/bliss.pdf > > C allowed writing Unix with a limited amount of assembly code, but CMU's > original BLISS-10 was designed to write an operating system with *no* > outside assembly code. Features like the 'MACHOP' (machine operation) > builtin function made use of the orthogonality of the PDP-10 > instruction format to execute machine-specific instructions in-line. > (cf. the 'asm' extensions in some implementations of C.) The PDP-10's > 36-bit word allowed single-precision floating point numbers to fit in > machine words, so it had infix operators for both integer and > single-precision floating point operations (which I presume were > adequate for an operating system). > > When DEC chose an implementation language, they knew about C but it had > not yet escaped from Bell Labs. PL/I was considered, but there were > questions of whether or not it would be suitable for a minicomputer. On > the other hand, by choosing BLISS, DEC could start with the BLISS-11 > cross compiler running on the PDP-10, which is described in > https://en.wikipedia.org/wiki/The_Design_of_an_Optimizing_Compiler > BLISS-11 > > and DEC's Common BLISS had changes necessitated by different > word lengths and architectures, including different routine linkages > such as INTERRUPT, access to machine-specific operations such as INSQTI, > and multiple-precision floating point operations using builtin functions > which used the addresses of data instead of the values. > > In order to port VMS to new architectures, DEC/HP/VSI retargeted and > ported the BLISS compilers to new architectures. > > What I find amazing is that they also turned the VAX MACRO assembly > language (in which some of the VMS operating system was written) into a > portable implementation language by 'compiling' the high-level CISC VAX > instructions (and addressing modes) into sequences of RISC > instructions. I believe that this is similar to how modern CPU chips > dynamically translate x86_64 instructions (or whatever) to an internal > RISC format. > > - Aron > > (Disclaimer: I worked at DEC for a long time and VSI for a short time, > but I wasn't responsible for the above work.) > > > On 7/6/24 17:32, Charles H Sauer (he/him) wrote: > > On 7/6/2024 3:56 PM, John R Levine wrote: > >> On Sat, 6 Jul 2024, Clem Cole wrote: > >>> Other systems programming languages followed, BCPL, BLISS, PL/360 > >>> and even > >>> B before C. > >> The original version of BLISS was only for the PDP-10. DEC > >> retargeted it to the PDP-11 and VAX, but I think that was after Unix > >> moved to the Interdata and possibly other machines. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Tue Jul 9 09:45:48 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 08 Jul 2024 23:45:48 +0000 Subject: [TUHS] Program Generic Issue 3 Init System? Message-ID: Good afternoon, I was wondering if anyone currently on list is in possession of a copy of the UNIX Programmer's Manual for Program Generic Issue 3 from March of 1977. This is the version nestled between Issue 2 which Al Kossow has preserved here: http://www.bitsavers.org/pdf/att/unix/6th_Edition/UNIX_Programmers_Manual_197601.pdf and the MERT 0 release provided by I believe Heinz Lycklama here: https://www.tuhs.org/Archive/Documentation/Manuals/MERT_Release_0/ If I might make a request of anyone having such a copy, could I trouble you for at the very least scans of the lines(V), getty(VIII), and init(VIII) pages? I can't 100% confirm the presence of the first page, but the instructions for replacing PG3 pages with MERT0 pages above indicate a page called lines was present in section V of the PG3 manual, and there is a fragment of a lines(5) page in the CB-UNIX 2.3 manual here: https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/man/man5/lines.5.pdf In short, lines there appears to be a predecessor to inittab(5) and, if the references in CB and USG PG3 are the same, points to the earliest appearance in the wild of System V-style init in PG3 all the way back in 1977. Granted we don't have earlier CB-UNIX literature to wholly confirm whether this started in PG3 or some pre-'77 issue of CB-UNIX, but I'm quite interested in seeing how these relate. Thanks for any help! - Matt G. From athornton at gmail.com Tue Jul 9 10:08:32 2024 From: athornton at gmail.com (Adam Thornton) Date: Mon, 8 Jul 2024 17:08:32 -0700 Subject: [TUHS] mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <20240705213804.550128EDF53C@ary.qy> <20240705214901.GR26356@mcvoy.com> <20240705231714.5F0E58EE123E@ary.qy> <6DEE0364-13BF-4DDF-8B42-8EE9DE010211@canb.auug.org.au> <6c797638-8fef-a587-0f73-cdb564568950@taugh.com> <7e4a089d-038d-4054-b315-ff41c8396a47@insinga.com> Message-ID: Indeed, S/390 Linux ran just fine on machines without IEEE floating point. Which meant that for years I had to jam `use integer` at the top of any Perl I ran, because otherwise any Perl arithmetic at all would go through the software float routines, which was very painful on little machines, such as a P/390. Adam On Mon, Jul 8, 2024 at 3:37 PM Rik Farrow wrote: > When I was tech editing "Operating Systems Concepts", tenth edition, > around seven years ago, I downloaded the Linux source and searched all .c > and .h files for float and double. There aren't any. Linux does not require > floating point support, and that's likely true of other operating systems, > where performance is key. It also means that Linux can run on RISC > V without floating point support (I know the basic CPU doesn't include it). > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aki at insinga.com Tue Jul 9 11:04:12 2024 From: aki at insinga.com (Aron Insinga) Date: Mon, 8 Jul 2024 21:04:12 -0400 Subject: [TUHS] mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <20240705213804.550128EDF53C@ary.qy> <20240705214901.GR26356@mcvoy.com> <20240705231714.5F0E58EE123E@ary.qy> <6DEE0364-13BF-4DDF-8B42-8EE9DE010211@canb.auug.org.au> <6c797638-8fef-a587-0f73-cdb564568950@taugh.com> <7e4a089d-038d-4054-b315-ff41c8396a47@insinga.com> Message-ID: Re: Floating point is unnecessary for operating systems: Yes, that's a big relief for early, small computers without hardware floating point!  But floating point is important for runtime libraries which need to implement math functions or reading & writing floating point numbers.  IMHO that's work for a system implementation language too, YMMV. Re: BLISS: I found it sad, but the newest versions of the BLISS compilers do not support using it as an expression language.  The section bridging pp 978-979 (as published) of Brender's history is: "The expression language characteristic was often highly touted in the early years of BLISS. While there is a certain conceptual elegance that results, in practice this characteristic is not exploited much.   The most common applications use the if-then-else expression, for example, in something like the maximum calculation illustrated in Figure 5. Very occasionally there is some analogous use of a case expression. Examples using loops (taking advantage of the value of leave), however, tend not to work well on human factors grounds: the value computed tends to be visually lost in the surrounding control constructs and too far removed from where it will be used; an explicit assignment to a temporary variable often seems to work better.   On balance, the expression characteristic of BLISS was not terribly important." Another thing that I always liked (but is still there) is the ease of accessing bit fields with V which was descended from BLISS-10's use of the PDP-10 byte pointers.  [Add a dot before V to get an rvalue.]  (Well, there was this logic simulator which really packed data into bit fields of blocks representing gates, events, etc....) Yes, there is now a BLISS-64 compiler and a MACRO-64 compiler which generate x86_64 code. - Aron Ref: https://www.cs.tufts.edu/~nr/cs257/archive/ronald-brender/bliss.pdf On 7/8/24 18:14, Paul Winalski wrote: > ... > BLISS is also a true, full-blown expression language. Statement > constructs such as if/then/else have a value and can be used in > expressions.  In C terminology, everything in BLISS is a lvalue.  A > semicolon terminates an expression and throws its value away. > ... > DEC used four dialects of BLISS as their primary software development > language:  BLISS-16, BLISS-32, BLISS-36, and BLISS-64 the numbers > indicating the BLISS word size in bits.  BLISS-16 targeted the PDP-11 > and BLISS-36 the PDP-10.  DEC did implementations of BLISS-32 for VAX, > MIPS, and x86.  BLISS-64 was targeted to both Alpha and Itanium. VSI > may have a version of BLISS-64 that generates x86-64 code. > > -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From heinz at osta.com Tue Jul 9 12:22:07 2024 From: heinz at osta.com (Heinz Lycklama) Date: Mon, 8 Jul 2024 19:22:07 -0700 Subject: [TUHS] Program Generic Issue 3 Init System? In-Reply-To: References: Message-ID: <479751df-d624-4a58-80b0-54cd9cf6618d@osta.com> I still have the original MERT 0 Release manual. But I do not have a manual page for lines(V). I do have the manual pages for getty(VIII) and init(VIII). They are also still online here: https://www.tuhs.org/Archive/Documentation/Manuals/MERT_Release_0/Unix%20Programmer%20Manual%20-%20UPM%20-%20White%20Tabs/System%20Programs%20-%20man8/ If you need copies of these two files let me know. Thanks. Heinz On 7/8/2024 4:45 PM, segaloco via TUHS wrote: > Good afternoon, I was wondering if anyone currently on list is in possession of a copy of the UNIX Programmer's Manual for Program Generic Issue 3 from March of 1977. This is the version nestled between Issue 2 which Al Kossow has preserved here: > > http://www.bitsavers.org/pdf/att/unix/6th_Edition/UNIX_Programmers_Manual_197601.pdf > > and the MERT 0 release provided by I believe Heinz Lycklama here: > > https://www.tuhs.org/Archive/Documentation/Manuals/MERT_Release_0/ > > If I might make a request of anyone having such a copy, could I trouble you for at the very least scans of the lines(V), getty(VIII), and init(VIII) pages? I can't 100% confirm the presence of the first page, but the instructions for replacing PG3 pages with MERT0 pages above indicate a page called lines was present in section V of the PG3 manual, and there is a fragment of a lines(5) page in the CB-UNIX 2.3 manual here: > > https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/man/man5/lines.5.pdf > > In short, lines there appears to be a predecessor to inittab(5) and, if the references in CB and USG PG3 are the same, points to the earliest appearance in the wild of System V-style init in PG3 all the way back in 1977. Granted we don't have earlier CB-UNIX literature to wholly confirm whether this started in PG3 or some pre-'77 issue of CB-UNIX, but I'm quite interested in seeing how these relate. > > Thanks for any help! > > - Matt G. From dave at horsfall.org Tue Jul 9 12:40:57 2024 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 9 Jul 2024 12:40:57 +1000 (EST) Subject: [TUHS] mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <20240705213804.550128EDF53C@ary.qy> <20240705214901.GR26356@mcvoy.com> <20240705231714.5F0E58EE123E@ary.qy> <6DEE0364-13BF-4DDF-8B42-8EE9DE010211@canb.auug.org.au> <6c797638-8fef-a587-0f73-cdb564568950@taugh.com> <7e4a089d-038d-4054-b315-ff41c8396a47@insinga.com> Message-ID: On Mon, 8 Jul 2024, Adam Thornton wrote: > Indeed, S/390 Linux ran just fine on machines without IEEE floating > point.  Which meant that for years I had to jam `use integer` at the top > of any Perl I ran, because otherwise any Perl arithmetic at all would go > through the software float routines, which was very painful on little > machines, such as a P/390. When it comes down to it, why would a kernel need floating point? Or are you talking about the distribution instead of the OS? -- Dave From imp at bsdimp.com Tue Jul 9 12:43:45 2024 From: imp at bsdimp.com (Warner Losh) Date: Mon, 8 Jul 2024 20:43:45 -0600 Subject: [TUHS] mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <20240705213804.550128EDF53C@ary.qy> <20240705214901.GR26356@mcvoy.com> <20240705231714.5F0E58EE123E@ary.qy> <6DEE0364-13BF-4DDF-8B42-8EE9DE010211@canb.auug.org.au> <6c797638-8fef-a587-0f73-cdb564568950@taugh.com> <7e4a089d-038d-4054-b315-ff41c8396a47@insinga.com> Message-ID: On Mon, Jul 8, 2024 at 8:41 PM Dave Horsfall wrote: > On Mon, 8 Jul 2024, Adam Thornton wrote: > > > Indeed, S/390 Linux ran just fine on machines without IEEE floating > > point. Which meant that for years I had to jam `use integer` at the top > > of any Perl I ran, because otherwise any Perl arithmetic at all would go > > through the software float routines, which was very painful on little > > machines, such as a P/390. > > When it comes down to it, why would a kernel need floating point? Or are > you talking about the distribution instead of the OS? > Not floating point, per se, but there's things like AESNI that use special registers that are akin to floating point (I can't recall if they are shared with the FP registers or not off the top of my head). For doing crypto fast, these are often used. The same the same facilities that FP uses to save/restore them on context switches. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Tue Jul 9 14:23:54 2024 From: athornton at gmail.com (Adam Thornton) Date: Mon, 8 Jul 2024 21:23:54 -0700 Subject: [TUHS] mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <20240705213804.550128EDF53C@ary.qy> <20240705214901.GR26356@mcvoy.com> <20240705231714.5F0E58EE123E@ary.qy> <6DEE0364-13BF-4DDF-8B42-8EE9DE010211@canb.auug.org.au> <6c797638-8fef-a587-0f73-cdb564568950@taugh.com> <7e4a089d-038d-4054-b315-ff41c8396a47@insinga.com> Message-ID: Generally it shouldn't, and didn't. But Perl assumed you had hardware floating point, because most architectures did--including S/390--but Perl on Linux further assumed IEEE 754 floating point, which was implemented in software on the S/390 (the hardware FP was IBM FP), and, on small and pokey machines, was really quite slow. Adam On Mon, Jul 8, 2024 at 7:41 PM Dave Horsfall wrote: > On Mon, 8 Jul 2024, Adam Thornton wrote: > > > Indeed, S/390 Linux ran just fine on machines without IEEE floating > > point. Which meant that for years I had to jam `use integer` at the top > > of any Perl I ran, because otherwise any Perl arithmetic at all would go > > through the software float routines, which was very painful on little > > machines, such as a P/390. > > When it comes down to it, why would a kernel need floating point? Or are > you talking about the distribution instead of the OS? > > -- Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From aki at insinga.com Tue Jul 9 15:06:04 2024 From: aki at insinga.com (Aron Insinga) Date: Tue, 9 Jul 2024 01:06:04 -0400 Subject: [TUHS] mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <20240705213804.550128EDF53C@ary.qy> <20240705214901.GR26356@mcvoy.com> <20240705231714.5F0E58EE123E@ary.qy> <6DEE0364-13BF-4DDF-8B42-8EE9DE010211@canb.auug.org.au> <6c797638-8fef-a587-0f73-cdb564568950@taugh.com> <7e4a089d-038d-4054-b315-ff41c8396a47@insinga.com> Message-ID: Sorry if I'm mistaken, but I thought that we were talking about system implementation languages.  The languages discussed have their roots back in the early days of using an HLL instead of assembly language for this. One could certainly write the kernel in a subset [or a superset of a subset] of the language that is used for everything else and I believe it has been done before.  (Is ESPOL a superset of Burroughs ALGOL?)  One could write the kernel in C and everything else in a *very* different language. I only mentioned single-precision floating point as an example of BLISS-10 being operator-typed as opposed to data-typed, and then added that a little floating point is useful for writing run-time libraries.  (For another example, a debugger might want to use floating point to allow examining or depositing such a value.)  I'd consider PDP-11 UNIX to be an operating system, and it included some libraries and a debugger.  I can see that others might consider PDP-11 UNIX to be a 'distribution'.  Sorry if I wandered too far afield. - Aron On 7/8/24 22:40, Dave Horsfall wrote: > On Mon, 8 Jul 2024, Adam Thornton wrote: > >> Indeed, S/390 Linux ran just fine on machines without IEEE floating >> point.  Which meant that for years I had to jam `use integer` at the top >> of any Perl I ran, because otherwise any Perl arithmetic at all would go >> through the software float routines, which was very painful on little >> machines, such as a P/390. > When it comes down to it, why would a kernel need floating point? Or are > you talking about the distribution instead of the OS? > > -- Dave From robpike at gmail.com Tue Jul 9 18:12:14 2024 From: robpike at gmail.com (Rob Pike) Date: Tue, 9 Jul 2024 18:12:14 +1000 Subject: [TUHS] Is There Teletype DNA In the Blit? In-Reply-To: References: Message-ID: Bart and I developed it (him largely hardware, me entirely software) within Research. Leaving out a lot of detail, when it was time to commercialize it, Teletype came in and studied it. They they made a bunch. Later, they were pressured to convert it from 68000 to BellMac32. But fundamentally it's a Research artifact. -rob On Thu, Jul 4, 2024 at 8:04 AM segaloco via TUHS wrote: > > I suppose this question is best directed at Rob or Doug, but just might as well ask at large: Given AT&T's ownership of Teletype and the involvement (AFAIK) of Teletype with other WECo CRT terminals (e.g. Dataspeed 40 models), was there any direct involvement of folks from the Teletype side of things in the R&D on the Jerq/Blit/DMD? Or was this terminal pure Bell Labs? > > - Matt G. From dave at horsfall.org Wed Jul 10 08:54:11 2024 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 10 Jul 2024 08:54:11 +1000 (EST) Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <202407080659.4686xEpc1504559@freefriends.org> References: <202407080659.4686xEpc1504559@freefriends.org> Message-ID: On Mon, 8 Jul 2024, arnold at skeeve.com wrote: > I think these were called "Eclipse", and the story of their > development is told in the famous book "The Soul of a New Machine". > For you youngsters out there, it's a great read. A superb book; highly recommended. -- Dave From douglas.mcilroy at dartmouth.edu Wed Jul 10 12:20:54 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Tue, 9 Jul 2024 22:20:54 -0400 Subject: [TUHS] mental architecture models, Anyone ever heard of teaching a case study of Initial Unix? Message-ID: > In order to port VMS to new architectures, DEC/HP/VSI ... > turned the VAX MACRO assembly language (in which > some of the VMS operating system was written) into a > portable implementation language by 'compiling' the > high-level CISC VAX instructions (and addressing modes) > into sequences of RISC instructions. Clem Pease did the same thing to port TMG from IBM 7000-series machines to the GE 600 series for Multics, circa 1967. Although both architectures had 36-bit words, it was a challenge to adequately emulate IBM's accumulator, which supported 38-bit sign-magnitude addition, 37-bit twos-complement and 36-bit ones-complement. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnl at taugh.com Wed Jul 10 12:36:57 2024 From: johnl at taugh.com (John Levine) Date: 9 Jul 2024 22:36:57 -0400 Subject: [TUHS] machine code translation,as mental architecture models In-Reply-To: References: Message-ID: <20240710023658.7FAEC8F4AAA5@ary.qy> It appears that Douglas McIlroy said: >> portable implementation language by 'compiling' the >> high-level CISC VAX instructions (and addressing modes) >> into sequences of RISC instructions. This idea, emulating one machine on another by translating strings of instructions (basic blocks in compiler-ese) is quite old. I don't know who did it first, and would be interested to hear if anyone knows, although I expect it was reinvented multiple times. It used to be harder because programs would store into the instruction stream but these days code is all read-only it's quite standard. I'm typing this on my M1 Macbook using an editor that thinks it's running on an x86. R's, John From lars at nocrew.org Wed Jul 10 14:59:59 2024 From: lars at nocrew.org (Lars Brinkhoff) Date: Wed, 10 Jul 2024 04:59:59 +0000 Subject: [TUHS] machine code translation,as mental architecture models In-Reply-To: <20240710023658.7FAEC8F4AAA5@ary.qy> (John Levine's message of "9 Jul 2024 22:36:57 -0400") References: <20240710023658.7FAEC8F4AAA5@ary.qy> Message-ID: <7wfrsh6dv4.fsf@junk.nocrew.org> John Levine writes: > It used to be harder because programs would store into the instruction > stream but these days code is all read-only it's quite standard. I'm > typing this on my M1 Macbook using an editor that thinks it's running > on an x86. Note that Apple silicon has special hardware - not in standard ARM devices - to accomodate the x86 memory model. I don't know the detals of Rosetta 2, but I believe this hardware is an important component to make it work. From paul.winalski at gmail.com Wed Jul 10 21:56:32 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Wed, 10 Jul 2024 07:56:32 -0400 Subject: [TUHS] machine code translation,as mental architecture models In-Reply-To: <20240710023658.7FAEC8F4AAA5@ary.qy> References: <20240710023658.7FAEC8F4AAA5@ary.qy> Message-ID: It appears that Douglas McIlroy said: > >> portable implementation language by 'compiling' the > >> high-level CISC VAX instructions (and addressing modes) > >> into sequences of RISC instructions. > > No need for the quotes around 'compiling'. VAX MACRO is a true, genuine compiler. The first version of it had a front end that translated VAX/VMS assembly language into expanded IL for the GEM compiler back end. The GEM code generator then generated the Alpha code for that IL. IIRC this process bypassed most of the GEM optimizer. But it gave you native Alpha code. GEM was later targeted to Itanium and that allowed the VAX MACRO compiler to produce code for the IA64 version of OpenVMS. The same process was used by VSI to port OpenVMS to x86-64, but they may be using a LLVM-based compiler back end now. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnl at taugh.com Wed Jul 10 22:53:35 2024 From: johnl at taugh.com (John R Levine) Date: 10 Jul 2024 08:53:35 -0400 Subject: [TUHS] machine code translation,as mental architecture models In-Reply-To: <7wfrsh6dv4.fsf@junk.nocrew.org> References: <20240710023658.7FAEC8F4AAA5@ary.qy> <7wfrsh6dv4.fsf@junk.nocrew.org> Message-ID: On Wed, 10 Jul 2024, Lars Brinkhoff wrote: >> typing this on my M1 Macbook using an editor that thinks it's running >> on an x86. > > Note that Apple silicon has special hardware - not in standard ARM > devices - to accomodate the x86 memory model. I don't know the detals > of Rosetta 2, but I believe this hardware is an important component to > make it work. I believe there's hardware to make it work better, but there's plenty of examples of object code translation without special hardware. The last time Apple switched processors they compiled POWER code to x86 which was harder since the byte orders were different. Still would be interested to hear when it was invented. 1967 seems early but not that early. Regards, John Levine, johnl at taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From tuhs at tuhs.org Wed Jul 10 23:18:37 2024 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Wed, 10 Jul 2024 09:18:37 -0400 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: References: <202407080659.4686xEpc1504559@freefriends.org> Message-ID: <099b5603-9d91-461a-b975-ca48e2ba465e@case.edu> On 7/9/24 6:54 PM, Dave Horsfall wrote: > On Mon, 8 Jul 2024, arnold at skeeve.com wrote: > >> I think these were called "Eclipse", and the story of their >> development is told in the famous book "The Soul of a New Machine". >> For you youngsters out there, it's a great read. > > A superb book; highly recommended. All of Kidder's books are good. I particularly enjoyed "House". -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From marc.donner at gmail.com Thu Jul 11 00:12:03 2024 From: marc.donner at gmail.com (Marc Donner) Date: Wed, 10 Jul 2024 10:12:03 -0400 Subject: [TUHS] machine code translation,as mental architecture models In-Reply-To: <20240710023658.7FAEC8F4AAA5@ary.qy> References: <20240710023658.7FAEC8F4AAA5@ary.qy> Message-ID: Well, a computer scientist named Cathy May at IBM Research did this for the S370 / Power PC architecture pair back in the mid-1980s. The work was novel to me at the time ... she and her long-term partner were close friends of mine, so I heard about her work over shared dinners across several years. The basic technique was to load pages of 360 machine code unmodified into Power PC memory, marking the pages as dirty. If the machine branched into one of these pages the VM trap handler would take the page and translate all of its code from 370 instructions to Power PC instructions. Once that was done the branch, suitably recalculated, was reinstated. It turned out to be remarkably easy to do the translation. And in practice the resulting Power PC code was only about 10% bigger than the original 370 code. AND, since tons of code is never touched (corner cases on corner cases) the result is quite efficient. I don't know if IBM ever built a product based on her research, but it seemed remarkably clever to me. Marc ===== nygeek.net mindthegapdialogs.com/home On Tue, Jul 9, 2024 at 10:37 PM John Levine wrote: > It appears that Douglas McIlroy said: > >> portable implementation language by 'compiling' the > >> high-level CISC VAX instructions (and addressing modes) > >> into sequences of RISC instructions. > > This idea, emulating one machine on another by translating strings of > instructions (basic blocks in compiler-ese) is quite old. I don't know > who did it first, and would be interested to hear if anyone knows, > although I expect it was reinvented multiple times. > > It used to be harder because programs would store into the instruction > stream but these days code is all read-only it's quite standard. I'm > typing this on my M1 Macbook using an editor that thinks it's running > on an x86. > > R's, > John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnl at taugh.com Thu Jul 11 00:29:32 2024 From: johnl at taugh.com (John Levine) Date: 10 Jul 2024 10:29:32 -0400 Subject: [TUHS] Anyone ever heard of teaching a case study of Initial Unix? In-Reply-To: <099b5603-9d91-461a-b975-ca48e2ba465e@case.edu> References: <202407080659.4686xEpc1504559@freefriends.org> <099b5603-9d91-461a-b975-ca48e2ba465e@case.edu> Message-ID: <20240710142933.060FB8F52A6E@ary.qy> According to Chet Ramey via TUHS : >On 7/9/24 6:54 PM, Dave Horsfall wrote: >> On Mon, 8 Jul 2024, arnold at skeeve.com wrote: >> >>> I think these were called "Eclipse", and the story of their >>> development is told in the famous book "The Soul of a New Machine". >>> For you youngsters out there, it's a great read. >> >> A superb book; highly recommended. > >All of Kidder's books are good. I particularly enjoyed "House". His first book, The Road to Yuba City, was not so good. He bought back the rights and has made it quite difficult to find copies. It's in the Internet Archive if anyone cares. I agree that the rest of his books are good. From tuhs at tuhs.org Thu Jul 11 02:58:43 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 10 Jul 2024 16:58:43 +0000 Subject: [TUHS] machine code translation,as mental architecture models In-Reply-To: References: <20240710023658.7FAEC8F4AAA5@ary.qy> Message-ID: On Wednesday, July 10th, 2024 at 7:12 AM, Marc Donner wrote: > The basic technique was to load pages of 360 machine code unmodified into Power PC memory, marking the pages as dirty. If the machine branched into one of these pages the VM trap handler would take the page and translate all of its code from 370 instructions to Power PC instructions. Once that was done the branch, suitably recalculated, was reinstated. > > ... > > Marc > ===== > nygeek.net > mindthegapdialogs.com/home Was this under the assumption everything else going on (bus architecture, memory map, exception/trap handling, etc.) was exactly the same or was the MMU for instance in the picture translating from 370 addresses to their equivalents on whatever PowerPC machine was in play? That or was this only expected to work on PIC, user-level code and anything touching for instance privilege escalation or with explicit address pointers, I/O port access, etc. just understood to not be applicable to such a direct translation? To tie it back to UNIX, for instance, was this thing also able to detect that a UNIX system call was being made and translate the 370 syscall mechanism into the PowerPC syscall mechanism? My main experience with emulation is console video games so in that realm, you're dealing not only with a different CPU architecture but system bus, memory map, peripheral controllers, etc. Essentially you're not just speaking another language, you're on another planet entirely. This has lead to a entrenched belief in my mind that this sort of "direct translation" of CPU operations is a non-starter in emulation hence my curiosity. If there's some historic approach to emulation efficiently handling system architecture diversity beyond just CPU instructions, I'm certainly interested! - Matt G. P.S. Feeling trepid about continuing this thread on TUHS rather than COFF, but resisting the urge to bump it (again). To keep it on topic, I'd mostly be interested in how this sort of thing would handle the UNIX system call mechanism, because that would certainly illuminate the general idea of translating something more complicated than an algorithm. From crossd at gmail.com Thu Jul 11 03:15:00 2024 From: crossd at gmail.com (Dan Cross) Date: Wed, 10 Jul 2024 13:15:00 -0400 Subject: [TUHS] machine code translation,as mental architecture models In-Reply-To: References: <20240710023658.7FAEC8F4AAA5@ary.qy> Message-ID: On Wed, Jul 10, 2024 at 12:58 PM segaloco via TUHS wrote: > On Wednesday, July 10th, 2024 at 7:12 AM, Marc Donner wrote: > > The basic technique was to load pages of 360 machine code unmodified into Power PC memory, marking the pages as dirty. If the machine branched into one of these pages the VM trap handler would take the page and translate all of its code from 370 instructions to Power PC instructions. Once that was done the branch, suitably recalculated, was reinstated. > > Was this under the assumption everything else going on (bus architecture, memory map, exception/trap handling, etc.) was exactly the same or was the MMU for instance in the picture translating from 370 addresses to their equivalents on whatever PowerPC machine was in play? > > That or was this only expected to work on PIC, user-level code and anything touching for instance privilege escalation or with explicit address pointers, I/O port access, etc. just understood to not be applicable to such a direct translation? To tie it back to UNIX, for instance, was this thing also able to detect that a UNIX system call was being made and translate the 370 syscall mechanism into the PowerPC syscall mechanism? > > My main experience with emulation is console video games so in that realm, you're dealing not only with a different CPU architecture but system bus, memory map, peripheral controllers, etc. Essentially you're not just speaking another language, you're on another planet entirely. This has lead to a entrenched belief in my mind that this sort of "direct translation" of CPU operations is a non-starter in emulation hence my curiosity. If there's some historic approach to emulation efficiently handling system architecture diversity beyond just CPU instructions, I'm certainly interested! Surely things like this have some limitations. Self-modifying code, for example, would be more challenging (though not impossible) to implement. But for _most_ programs, where text and data are mapped separately, it wouldn't be that bad; if data formats are common across ISAs and the instruction sets are similar-ish, it wouldn't be that bad. For the mainframe to PowerPC, I imagine floating point would be the sticky wicket. > P.S. Feeling trepid about continuing this thread on TUHS rather than COFF, but resisting the urge to bump it (again). To keep it on topic, I'd mostly be interested in how this sort of thing would handle the UNIX system call mechanism, because that would certainly illuminate the general idea of translating something more complicated than an algorithm. In some sense, this is one of the easiest cases to support. The system call mechanism necessarily needs some method to trap into the kernel; the kernel, in turn, needs to look at the state of the user program to see what it should do in response to that trap. In the case of going across an ISA, the kernel's job is marginally harder in that it has to respond to having multiple ways to end up at the system call handler, but that's not so much different than supporting multiple system call conventions on a single system. For example, on x86, we have the SYSCALL instruction, but also SYSENTER and older software might initiate a syscall by means of the INT instruction (e.g., INT 0x80 or INT 0x40). Across ISAs, one might enter the kernel on an illegal instruction trap, in which case the trap handler will have access to the faulting address and can examine what's there; if it's e.g. a 370 instruction, one could interpret it and figure out what to do from there. Usually system calls are made by calling a stub function in, say, the C library. That stub then sets up state in whatever manner the system expects, such as poking the system call number and arguments into registers or putting them on the stack in a specific order or whatever; the stub then traps, at which point the kernel takes over, services the syscall, and (usually) returns control to userspace, the return value will be examined, errno might be set, and the stub "returns" to calling code. Of course, the process might have invoked `exit` or something, in which case control won't be returned to userspace. Or the call can block, context switches might happen, the arguments might be bad, the thing can be killed, etc, etc. Anyway, in the context of this kind of ISA translation, presumably the stubs would be interpreted and the interpreter would be smart enough to recognize the trap, in which case it might rewrite to a native trap of some kind, instead of relying on the illegal instruction trick. These techniques are rather old, and I think go back much further than we're suggesting. Knuth mentions nested translations in TAOCP (Volume 1, I believe), suggesting the technique was well-known as early as the mid-1960s. - Dan C. From marc.donner at gmail.com Thu Jul 11 05:23:14 2024 From: marc.donner at gmail.com (Marc Donner) Date: Wed, 10 Jul 2024 15:23:14 -0400 Subject: [TUHS] machine code translation,as mental architecture models In-Reply-To: References: <20240710023658.7FAEC8F4AAA5@ary.qy> Message-ID: I never dug that deep into her work. If I were to guess, I would say that this was aimed at user-space sorts of code. It was aimed at making it possible to run large old 370 binaries in Power PC architecture machines. If I recall correctly, there was some discussion of migrating off of the S370 (later S390 and then z-system) ISA to the Power PC architecture. My sense was that this was a research study to understand whether a naive translation like this could work. I can not imagine trying to translate system code in this way. ===== nygeek.net mindthegapdialogs.com/home On Wed, Jul 10, 2024 at 1:07 PM segaloco via TUHS wrote: > On Wednesday, July 10th, 2024 at 7:12 AM, Marc Donner < > marc.donner at gmail.com> wrote: > > > The basic technique was to load pages of 360 machine code unmodified > into Power PC memory, marking the pages as dirty. If the machine branched > into one of these pages the VM trap handler would take the page and > translate all of its code from 370 instructions to Power PC instructions. > Once that was done the branch, suitably recalculated, was reinstated. > > > > ... > > > > Marc > > ===== > > nygeek.net > > mindthegapdialogs.com/home > > Was this under the assumption everything else going on (bus architecture, > memory map, exception/trap handling, etc.) was exactly the same or was the > MMU for instance in the picture translating from 370 addresses to their > equivalents on whatever PowerPC machine was in play? > > That or was this only expected to work on PIC, user-level code and > anything touching for instance privilege escalation or with explicit > address pointers, I/O port access, etc. just understood to not be > applicable to such a direct translation? To tie it back to UNIX, for > instance, was this thing also able to detect that a UNIX system call was > being made and translate the 370 syscall mechanism into the PowerPC syscall > mechanism? > > My main experience with emulation is console video games so in that realm, > you're dealing not only with a different CPU architecture but system bus, > memory map, peripheral controllers, etc. Essentially you're not just > speaking another language, you're on another planet entirely. This has > lead to a entrenched belief in my mind that this sort of "direct > translation" of CPU operations is a non-starter in emulation hence my > curiosity. If there's some historic approach to emulation efficiently > handling system architecture diversity beyond just CPU instructions, I'm > certainly interested! > > - Matt G. > > P.S. Feeling trepid about continuing this thread on TUHS rather than COFF, > but resisting the urge to bump it (again). To keep it on topic, I'd mostly > be interested in how this sort of thing would handle the UNIX system call > mechanism, because that would certainly illuminate the general idea of > translating something more complicated than an algorithm. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Jul 11 05:38:55 2024 From: clemc at ccc.com (Clem Cole) Date: Wed, 10 Jul 2024 15:38:55 -0400 Subject: [TUHS] machine code translation,as mental architecture models In-Reply-To: References: <20240710023658.7FAEC8F4AAA5@ary.qy> Message-ID: On Wed, Jul 10, 2024 at 3:23 PM Marc Donner wrote: > I can not imagine trying to translate system code in this way. > Marc, you are better than that - proof by lack of imagination is not very effective😘 Seriously, the "VAX Compiler" that Paul describes made a great deal of sense to the VMS team when it was developed. It's all about *economics*, not technical purity. And solution actually worked really well; as Paul points out, it lived for many different ISAs that followed VAX at DEC and now VSi. What I always was amazed by was the Cutler use assembler in the first place since DEC had production quality BLISS compilers. But as Dave Cane [VAX750 lead] once put it, it was the world's greatest assembler machine. Dave (famously) hated BLISS but was one heck of an assembly programmer. VMS both at the kernel and systems level, was (is) in assembler, so treating the VAX as a HLL and "compiling" to a new ISA was solid economics. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.donner at gmail.com Thu Jul 11 06:04:12 2024 From: marc.donner at gmail.com (Marc Donner) Date: Wed, 10 Jul 2024 16:04:12 -0400 Subject: [TUHS] machine code translation,as mental architecture models In-Reply-To: References: <20240710023658.7FAEC8F4AAA5@ary.qy> Message-ID: Picky, picky, Clem. Given the dramatic differences in I/O architecture, interrupt handling, and virtual memory between s370 and Power PC, it makes little sense to try to translate system code this way. On Wed, Jul 10, 2024, 15:39 Clem Cole wrote: > > > On Wed, Jul 10, 2024 at 3:23 PM Marc Donner wrote: > >> I can not imagine trying to translate system code in this way. >> > Marc, you are better than that - proof by lack of imagination is not > very effective😘 > > Seriously, the "VAX Compiler" that Paul describes made a great deal of > sense to the VMS team when it was developed. It's all about *economics*, > not technical purity. And solution actually worked really well; as Paul > points out, it lived for many different ISAs that followed VAX at DEC and > now VSi. > > What I always was amazed by was the Cutler use assembler in the first place > since DEC had production quality BLISS compilers. But as Dave Cane > [VAX750 lead] once put it, it was the world's greatest assembler machine. > Dave (famously) hated BLISS but was one heck of an assembly programmer. > VMS both at the kernel and systems level, was (is) in assembler, so > treating the VAX as a HLL and "compiling" to a new ISA was solid economics. > ᐧ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Thu Jul 11 06:34:22 2024 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 10 Jul 2024 16:34:22 -0400 (EDT) Subject: [TUHS] machine code translation,as mental architecture models Message-ID: <20240710203422.284BA18C077@mercury.lcs.mit.edu> > From: Dan Cross > These techniques are rather old, and I think go back much further than > we're suggesting. Knuth mentions nested translations in TAOCP .. > suggesting the technique was well-known as early as the mid-1960s. I'm not sure what exactly you're referring to with "[t]hese techniques"; I gather you are talking about the low-level mechanisms used to implement 'system calls'? If so, please permit me to ramble for a while, and revise your time-line somewhat. There are two reasons one needs 'system calls'; low-level 'getting there from here' (which I'll explain below), and 'switching operating/protection domains' (roughly, from 'user' to 'kernel'). In a batch OS which only runs in a single mode, one _could_ just use regular subroutine calls to call the 'operating system', to 'get there from here'. The low-level reason not to do this is that one would need the addresses of all the routines in the OS (which could change over time). If one instead used permanent numbers to identify system calls, and had some sort of 'system call' mechanism (an instruction - although it could be a subroutine call to a fixed location in the OS), one wouldn't need the addresses. But this is just low level mechanistic stuff. (I have yet to research to see if any early OS's did use subroutine calls as their interface.) The 'switching operating/protection domains' is more fundamental - and unavoidable. Obviously, it wouldn't have been needed before there were machines/OS's that operated in multiple modes. I don't have time to research which was the _first_ machine/OS to need this, but clearly CTSS was an early one. I happen to have a CTSS manual (two, actually :-), and in CTSS a system call was: TSX NAMEI, 4 .. .. NAMEI: TIA =HNAME where 'NAME' "is the BCD name of a legitimate supervisor entry point", and the 'TIA' instruction may be "usefully (but inexactly) read as Trap Into A core" (remember that in CTSS, the OS lived in the A core). (Don't ask me what HNAME is, or what a TSX instruction does! :-) So that would have been 1963, or a little earlier. By 1965 (see the 1965 Fall Joint Computer Conference papers: https://multicians.org/history.html for more), MIT had already moved on to the idea of using a subroutine calls that could cross protection domain boundaries for 'system calls', for Multics. The advantage of doing that is that if the machine has a standard way of passing arguments to subroutines, you natively/naturally get arguments to system calls. Noel From crossd at gmail.com Thu Jul 11 06:53:11 2024 From: crossd at gmail.com (Dan Cross) Date: Wed, 10 Jul 2024 16:53:11 -0400 Subject: [TUHS] machine code translation,as mental architecture models In-Reply-To: <20240710203422.284BA18C077@mercury.lcs.mit.edu> References: <20240710203422.284BA18C077@mercury.lcs.mit.edu> Message-ID: On Wed, Jul 10, 2024 at 4:34 PM Noel Chiappa wrote: > > From: Dan Cross > > These techniques are rather old, and I think go back much further than > > we're suggesting. Knuth mentions nested translations in TAOCP .. > > suggesting the technique was well-known as early as the mid-1960s. > > I'm not sure what exactly you're referring to with "[t]hese techniques"; I > gather you are talking about the low-level mechanisms used to implement > 'system calls'? No, I was referring to the idea of binary transliteration from one architecture to another. I found the reference; Knuth refers to "an extreme example of inefficient use of computer simulators [... in] the true story of machine A simulating machine B running a program that simulates machine C! This is the way to make a large, expensive computer give poorer results than its cheaper cousin." (This is on page 203 of my copy of Volume 1.) The idea of writing simulators for machines clearly dates to before (or near) the beginning of TAOCP. The idea of binary instruction translation during simulation is so obvious I can't imagine it wasn't part of such simulations; particularly early on. > If so, please permit me to ramble for a while, and revise > your time-line somewhat. > [snip] > >(I have yet to research to see if any early OS's > did use subroutine calls as their interface.) Not terribly early, but Xinu, as described in Comer's book, did/does. > [snip] This was very interesting, regardless; thanks. - Dan C. From athornton at gmail.com Thu Jul 11 07:18:26 2024 From: athornton at gmail.com (Adam Thornton) Date: Wed, 10 Jul 2024 14:18:26 -0700 Subject: [TUHS] machine code translation,as mental architecture models In-Reply-To: References: <20240710023658.7FAEC8F4AAA5@ary.qy> Message-ID: The Cathy May paper can be found at: https://dl.acm.org/doi/pdf/10.1145/29650.29651 And it's quite interesting; the first time I was aware of work like this was six or seven years later, when ARDI's Mac emulator "Executor" was the new hotness. Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnl at taugh.com Thu Jul 11 07:26:41 2024 From: johnl at taugh.com (John Levine) Date: 10 Jul 2024 17:26:41 -0400 Subject: [TUHS] machine code translation,as mental architecture models In-Reply-To: <20240710203422.284BA18C077@mercury.lcs.mit.edu> References: <20240710203422.284BA18C077@mercury.lcs.mit.edu> Message-ID: <20240710212641.E24548F5C32C@ary.qy> It appears that Noel Chiappa said: > > From: Dan Cross > > > These techniques are rather old, and I think go back much further than > > we're suggesting. Knuth mentions nested translations in TAOCP .. > > suggesting the technique was well-known as early as the mid-1960s. Knuth was talking about simulating one machine on another, interpreting one instruction at a time. As he notes, the performance is generally awful, although IBM did microcode emulation of many of their second generation machines on S/360 which all (for business reasons) ran faster than the real machines. Unsurprisingly, you couldn't emulate a 7094 on anything smaller than a 360/65. We've been discussing batch or JIT translation of code which gives much better performance without a lot of hardware help. >In a batch OS which only runs in a single mode, one _could_ just use regular >subroutine calls to call the 'operating system', to 'get there from here'. >The low-level reason not to do this is that one would need the addresses of >all the routines in the OS (which could change over time). That was quite common. The manuals for 70xx IOCS, which was the I/O management part of the system, show all the IOCS calls use TSX, the usual subroutine call which saved the return address in an index register and jumps (Transfers.) I think they avoided the address problem by putting transfer vectors at fixed locations in low memory, so your code did the TSX to an entry in the transfer vector which jumped to the real routine. >one. I happen to have a CTSS manual (two, actually :-), and in CTSS a system >call was: > > TSX NAMEI, 4 > .. > .. >NAMEI: TIA =HNAME > >where 'NAME' "is the BCD name of a legitimate supervisor entry point", and >the 'TIA' instruction may be "usefully (but inexactly) read as Trap Into A >core" (remember that in CTSS, the OS lived in the A core). (Don't ask me what >HNAME is, or what a TSX instruction does! :-) TSX we know, but I don't see TIA in the regular 7094 manual. It's documented in the RPQ for additional core storage, a jump from core bank B to A. The multiprogramming RPQ made TIA trap in protection mode, so it was indeed a system call. From tuhs at tuhs.org Thu Jul 11 07:57:44 2024 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Thu, 11 Jul 2024 07:57:44 +1000 Subject: [TUHS] Reminder: use the right list Message-ID: All, just a friendly reminder to use the TUHS mailing list for topics related to Unix, and to switch over to the COFF mailing list when the topic drifts away from Unix. I think a couple of the current threads ought to move over to the COFF list. Thanks! Warren From aek at bitsavers.org Thu Jul 11 08:29:54 2024 From: aek at bitsavers.org (Al Kossow) Date: Wed, 10 Jul 2024 15:29:54 -0700 Subject: [TUHS] machine code translation,as mental architecture models In-Reply-To: References: <20240710203422.284BA18C077@mercury.lcs.mit.edu> Message-ID: <011a1e2a-6a73-ceaa-2b9c-9ca43daf41e7@bitsavers.org> On 7/10/24 1:53 PM, Dan Cross wrote: > The idea of writing simulators for machines clearly dates to before > (or near) the beginning of TAOCP. Whirlwind, Summer 1954 http://bitsavers.org/pdf/mit/whirlwind/summer_session_1954 Summer Session Computer and Algebraic Systems were both interpreters From johnl at taugh.com Thu Jul 11 09:00:10 2024 From: johnl at taugh.com (John Levine) Date: 10 Jul 2024 19:00:10 -0400 Subject: [TUHS] machine code translation,as mental architecture models In-Reply-To: <011a1e2a-6a73-ceaa-2b9c-9ca43daf41e7@bitsavers.org> References: <20240710203422.284BA18C077@mercury.lcs.mit.edu> <011a1e2a-6a73-ceaa-2b9c-9ca43daf41e7@bitsavers.org> Message-ID: <20240710230010.D2D968F5DEE4@ary.qy> It appears that Al Kossow said: >On 7/10/24 1:53 PM, Dan Cross wrote: > >> The idea of writing simulators for machines clearly dates to before >> (or near) the beginning of TAOCP. Sure, but the topic of interest here is compiling machine code from one machine to another. You know like Rosetta does for x86 code running on my Macbook (obUnix: whose OS is descended from FreeBSD and Mach and does all the Posix stuff) which has an M2 ARM chip. We know that someone did it in 1967 from 709x to GE 635, which I agree was quite a trick since really the only thing the two machines had in common was a 36 bit word size. I was wondering if anyone did machine code translation as opposed to instruction at a time simulation before that. From tuhs at tuhs.org Thu Jul 11 09:14:52 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 10 Jul 2024 23:14:52 +0000 Subject: [TUHS] machine code translation,as mental architecture models In-Reply-To: <20240710230010.D2D968F5DEE4@ary.qy> References: <20240710203422.284BA18C077@mercury.lcs.mit.edu> <011a1e2a-6a73-ceaa-2b9c-9ca43daf41e7@bitsavers.org> <20240710230010.D2D968F5DEE4@ary.qy> Message-ID: On Wednesday, July 10th, 2024 at 4:00 PM, John Levine wrote: > It appears that Al Kossow aek at bitsavers.org said: > > > On 7/10/24 1:53 PM, Dan Cross wrote: > > > > > The idea of writing simulators for machines clearly dates to before > > > (or near) the beginning of TAOCP. > > > Sure, but the topic of interest here is compiling machine code from one > machine to another. You know like Rosetta does for x86 code running on > my Macbook (obUnix: whose OS is descended from FreeBSD and Mach and does > all the Posix stuff) which has an M2 ARM chip. > > We know that someone did it in 1967 from 709x to GE 635, which I agree > was quite a trick since really the only thing the two machines had in > common was a 36 bit word size. I was wondering if anyone did machine > code translation as opposed to instruction at a time simulation before that. > Attempting once again to COFF this thread as I am quite interested in the discussion of this sort of emulation/simulation matter outside of the confines of UNIX history as well. To add to the discussion, while not satisfying the question of "where did this sort of thing begin", the 3B20 was another machine that provided some means of emulating another architecture via microcode, although what I know about this is limited to discussions about emulating earlier ESS machines to support existing telecom switching programs. I've yet to find any literature suggesting this was ever used to emulate other general-purpose computers such as IBM, DEC, etc. but likewise no suggestion that it *couldn't* be used this way. - Matt G. From dave at horsfall.org Thu Jul 11 11:24:26 2024 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 11 Jul 2024 11:24:26 +1000 (EST) Subject: [TUHS] When did "man cal" lose the comment about 1752? Message-ID: The manpage for "cal" used to have the comment "Try September 1752" (and yes, I know why); it's no longer there, so when did it disappear? The SysV fun police? I remember it in Ed5 and Ed6, but can't remember when I last saw it. Thanks. -- Dave From crossd at gmail.com Thu Jul 11 11:29:58 2024 From: crossd at gmail.com (Dan Cross) Date: Wed, 10 Jul 2024 21:29:58 -0400 Subject: [TUHS] machine code translation,as mental architecture models In-Reply-To: <20240710212641.E24548F5C32C@ary.qy> References: <20240710203422.284BA18C077@mercury.lcs.mit.edu> <20240710212641.E24548F5C32C@ary.qy> Message-ID: [TUHS to Bcc:, +COFF] On Wed, Jul 10, 2024 at 5:26 PM John Levine wrote: > It appears that Noel Chiappa said: > > > From: Dan Cross > > > > > These techniques are rather old, and I think go back much further than > > > we're suggesting. Knuth mentions nested translations in TAOCP .. > > > suggesting the technique was well-known as early as the mid-1960s. > > Knuth was talking about simulating one machine on another, interpreting > one instruction at a time. As he notes, the performance is generally awful, > although IBM did microcode emulation of many of their second generation > machines on S/360 which all (for business reasons) ran faster than the > real machines. Unsurprisingly, you couldn't emulate a 7094 on anything > smaller than a 360/65. It's not clear to me why you suggest with such evident authority that Knuth was referring only to serialized instruction emulation and not something like JIT'ed code; true, he doesn't specify one way or the other, but I find it specious to conclude that that implies the technique wasn't already in use, or at least known. But certainly by then JIT'ing techniques for "interpreted" programming languages were known; it doesn't seem like a great leap to extend that to binary translation. Of course, that's speculation on my part, and I could certainly be wrong. > We've been discussing batch or JIT translation of code which gives > much better performance without a lot of hardware help. JIT'd performance of binary transliteration is certainly going to be _better_ than strict emulation, but it is unlikely to be _as good_ as native code. Indeed, this is still an active area of research; e.g., luajit; https://www.mattkeeter.com/blog/2022-10-04-ssra/ (disclaimer: Matt's a colleague of mine), etc. - Dan C. From grog at lemis.com Thu Jul 11 11:44:35 2024 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Thu, 11 Jul 2024 11:44:35 +1000 Subject: [TUHS] When did "man cal" lose the comment about 1752? In-Reply-To: References: Message-ID: On Thursday, 11 July 2024 at 11:24:26 +1000, Dave Horsfall wrote: > The manpage for "cal" used to have the comment "Try September 1752" (and > yes, I know why); it's no longer there, so when did it disappear? The > SysV fun police? > > I remember it in Ed5 and Ed6, but can't remember when I last saw it. It's still mentioned in the latest version of FreeBSD: -s country_code Assume the switch from Julian to Gregorian Calendar at the date associated with the country_code. If not specified, ncal tries to guess the switch date from the local environment or falls back to September 2, 1752. This was when Great Britain and her colonies switched to the Gregorian Calendar. It sounds like that's not the quote you're thinking of, though. I've checked back as far as FreeBSD 1.0, which had a much simpler version of cal. The man page states The Gregorian Reformation is assumed to have occurred in 1752 on the 3rd of September. By this time, most countries had recognized the ref- ormation (although a few did not recognize it until the early 1900's.) Ten days following that date were eliminated by the reformation, so the calendar for that month is a bit unusual. Maybe you can find something more interesting in the TUHS archives. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From henry.r.bent at gmail.com Thu Jul 11 11:53:54 2024 From: henry.r.bent at gmail.com (Henry Bent) Date: Wed, 10 Jul 2024 21:53:54 -0400 Subject: [TUHS] When did "man cal" lose the comment about 1752? In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 at 21:24, Dave Horsfall wrote: > The manpage for "cal" used to have the comment "Try September 1752" (and > yes, I know why); it's no longer there, so when did it disappear? The > SysV fun police? > > I remember it in Ed5 and Ed6, but can't remember when I last saw it. > > Thanks. > > -- Dave > Looks like on the BSD side it disappeared between 4.3 Tahoe and Reno. It's in research through v10. It's in SVR2; SVR4 modifies it to say "An unusual calendar is printed for September 1752." I don't seem to have manpages with either of the SVR3 source distributions that I have handy. So to answer your basic question, it stayed around for quite a while. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Thu Jul 11 13:10:51 2024 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 11 Jul 2024 13:10:51 +1000 (EST) Subject: [TUHS] When did "man cal" lose the comment about 1752? In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024, Greg 'groggy' Lehey wrote: [...] > Maybe you can find something more interesting in the TUHS archives. I see someone has already answered it; thanks anyway. -- Dave From dave at horsfall.org Thu Jul 11 13:29:09 2024 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 11 Jul 2024 13:29:09 +1000 (EST) Subject: [TUHS] When did "man cal" lose the comment about 1752? In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024, Henry Bent wrote: > Looks like on the BSD side it disappeared between 4.3 Tahoe and Reno.  > It's in research through v10.  It's in SVR2; SVR4 modifies it to say "An > unusual calendar is printed for September 1752."  I don't seem to have > manpages with either of the SVR3 source distributions that I have > handy.  So to answer your basic question, it stayed around for quite a > while. Just what I wanted; many thanks. And I couldn't remember what SysV said, but I did know that they changed it. -- Dave From tuhs at tuhs.org Thu Jul 11 14:00:34 2024 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Thu, 11 Jul 2024 14:00:34 +1000 Subject: [TUHS] =?utf-8?q?Fwd=3A_DKUUG=2C_EUUG_and_586_issues_=283700+_pa?= =?utf-8?q?ges=29_of_Unigram-X_1988=E2=80=A61996?= Message-ID: All ... ----- Forwarded message from Poul-Henning Kamp ----- Subject: DKUUG, EUUG and 586 issues (3700+ pages) of Unigram-X 1988…1996 (Please forward to the main TUHS list if you think it is warranted) A brief intro: Datamuseum.dk is a volunteer-run effort to collect, preserve and present "The Danish IT-history". UNIX is part of that history, but our interest is seen through the dual prisms of "Danish IT-History" and the computers in our collection. My own personal UNIX interest is of course much deeper and broader, which is why I'm sending this email. Recently we helped clean out the basement under the Danish Unix User's Group (DKUUG) which is winding down, and we hauled of a lot of stuff, which includes much EUUG - (European Unix Users Group) material. As I feed it through the scanner, the EUUG-newsletters will appear here: https://datamuseum.dk/wiki/Bits:Keyword/PERIODICALS/EUUG-NEWSLETTER And proceedings from EUUG conferences (etc.) will appear here: https://datamuseum.dk/wiki/Bits:Keyword/DKUUG/EUUG I also found four boxes full of "Unigram-X" newsletters. Unigram-X was a newsletter, published weekly out of London. A typical issue was two yellow A3 sheets folded, or if if news was slight, a folded A3 with an A4 insert. … and that is just about all I know about it. But whoever wrote it, they clearly had an amazing Rolodex. In total there a tad more than 3700 pages of real-time news and gossip about the UNIX world from 1986 to 1996. It's not exactly core material for datamuseum.dk, but it is a goldmine for UNIX history, so I have spent two full days day scanning and getting all the pages, sorted, flipped and split into one-year-per-pdf files. I should warn that neither the raw material nor the scan is perfect, but this is it, unless somebody else feels like going through it again. (The paper stays in our collection, no rush.) I need to go through and check for pages being upside down or out of order, before I ingest the PDFSs into the Datamuseum.dk bitarchive, but here is a preview: https://phk.freebsd.dk/misc/unigram_x_1986_0034_0058.pdf https://phk.freebsd.dk/misc/unigram_x_1987_0059_0108.pdf https://phk.freebsd.dk/misc/unigram_x_1988_0109_0159.pdf https://phk.freebsd.dk/misc/unigram_x_1989_0160_0211.pdf https://phk.freebsd.dk/misc/unigram_x_1990_0212_0262.pdf https://phk.freebsd.dk/misc/unigram_x_1991_0263_0313.pdf https://phk.freebsd.dk/misc/unigram_x_1992_0314_0365.pdf https://phk.freebsd.dk/misc/unigram_x_1993_0366_0416.pdf https://phk.freebsd.dk/misc/unigram_x_1994_0417_0467.pdf https://phk.freebsd.dk/misc/unigram_x_1995_0468_0518.pdf https://phk.freebsd.dk/misc/unigram_x_1996_0519_0616.pdf My ulterior motives for this preview are several: If you find any out-of-order or rotated pages, please let me know. It's not a complete collection, the following issues are missing: 1…33 35 39…49 86…87 105 138 229 321 400 405…406 496 498 507 520 523…524 527…528 548 613 615 617… It would be nice to fill the holes. As a matter of principle, we do not store OCR'ed PDF's in the datamuseum.dk bitarchive[1], and what with me still suffering from a job etc, I do not have the time to OCR 3700+ pages under any circumstances. But even the most crude and buggy OCR reading would be a great resource to grep(1), so I'm hoping somebody else might find the time and inclination ? And a "best-of-unigram-x" page on the TUHS wiki may be warranted, because there are some seriously great nuggets in there :-) Enjoy, Poul-Henning [1] I'm not entertaining any arguments about this: We're trying to align with best practice in historical collection world. The argument goes: Unless the OCR is perfect, people will do a text-search, not find stuff, and conclude it is not there. Such interpretations of artifacts belong in peer-reviewed papers, so there is a name of who to blame or praise, and so that they can be debated & revised etc. [2] The PDF's are archive-quality, you can extract the raw images from them, for instance with XPDF's "pdfimages" program. ----- End forwarded message ----- From rudi.j.blom at gmail.com Thu Jul 11 14:20:03 2024 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Thu, 11 Jul 2024 11:20:03 +0700 Subject: [TUHS] When did "man cal" lose the comment about 1752? Message-ID: Just had a quick look at 'man cat' on Uixes I've got 'at hand'. Just a 'cut and past' of the relevant parts. SCO UNIX 3.2V4.2 Limitations Note that ``cal 84'' refers to the year 84, not 1984. The calendar produced is the Gregorian calendar from September 14 1752 onward. Dates up to and including September 2 1752 use the Julian calen- dar. (England and her colonies switched from the Julian to the Gregorian calendar in September 1752, at which time eleven days were excised from the year. To see the result of this switch, try cal 9 1752.) Digital UNIX 4.0g DESCRIPTION The cal command writes to standard output a Gregorian calendar for the specified year or month. For historical reasons, the cal command's Gregorian calendar is discontinu- ous. The display for September 1752 (cal 9 1752) jumps from Wednesday the 2nd to Thursday the 14th. -- The more I learn the better I understand I know nothing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Thu Jul 11 23:59:28 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Thu, 11 Jul 2024 09:59:28 -0400 Subject: [TUHS] Puzzled about COFF Message-ID: I subscribe to the TUHS mailing list, delivered in digest form. I do not remember having subscribed to COFF, and am not aware of how to do so. Yet COFF messges come in my TUHS digest. How does COFF differ from TUHS and how does one subscibe to it (if at all)? Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Fri Jul 12 00:06:23 2024 From: crossd at gmail.com (Dan Cross) Date: Thu, 11 Jul 2024 10:06:23 -0400 Subject: [TUHS] Puzzled about COFF In-Reply-To: References: Message-ID: On Thu, Jul 11, 2024 at 9:59 AM Douglas McIlroy wrote: > I subscribe to the TUHS mailing list, delivered in digest form. I do not remember having subscribed to COFF, and am not aware of how to do so. Yet COFF messges come in my TUHS digest. How does COFF differ from TUHS and how does one subscibe to it (if at all)? Whereas TUHS is specific to Unix history, COFF (Computing Old-Fashioned Facts---not the real acronym, but one I just made up, I'm afraid) is more general. When a thread veers too far from Unix history for TUHS, it will often be redirected to COFF; a way to do this is to send a followup message, addressing TUHS in the Bcc: header (to let folks know it's moving) and directly Cc: COFF, which is possibly why one may see the occasional COFF message, despite not being subscribed. I believe that Warren subscribes people manually to both lists. - Dan C. From clemc at ccc.com Fri Jul 12 00:10:36 2024 From: clemc at ccc.com (Clem Cole) Date: Thu, 11 Jul 2024 10:10:36 -0400 Subject: [TUHS] Puzzled about COFF In-Reply-To: References: Message-ID: Doug, On Thu, Jul 11, 2024 at 9:59 AM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > I subscribe to the TUHS mailing list, delivered in digest form. I do not > remember having subscribed to COFF, > https://www.tuhs.org/cgi-bin/mailman/listinfo/coff Although I believe when it was first set up, Warren asked people on TUHS to send him a note. > and am not aware of how to do so. Yet COFF messges come in my TUHS digest. > When things move from TUHS to COFF - two things (sometimes) occur. The person moving it, should BCC: TUHS and mention that it's moving, but .. all preceding message will not yet have COFF in the header and thus will continue to send things to TUHS. > How does COFF differ from TUHS and how does one subscibe to it (if at all)? > As you know, many of these streams often diverge to non-UNIX-related issues. Warren created COFF as a place to have those discussions, but people who only wanted to discuss items relevant to the UNIX community should stick to its history. ᐧ ᐧ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Fri Jul 12 01:25:58 2024 From: tytso at mit.edu (Theodore Ts'o) Date: Thu, 11 Jul 2024 11:25:58 -0400 Subject: [TUHS] Puzzled about COFF In-Reply-To: References: Message-ID: <20240711152558.GE10452@mit.edu> On Thu, Jul 11, 2024 at 09:59:28AM -0400, Douglas McIlroy wrote: > I subscribe to the TUHS mailing list, delivered in digest form. I do not > remember having subscribed to COFF, and am not aware of how to do so. Yet > COFF messges come in my TUHS digest. How does COFF differ from TUHS and how > does one subscibe to it (if at all)? What sometimes happen is that a message will be sent to both the COFF and TUHS lists, and then when someone replies, you'll still see [COFF] in the subject line. As Clem mentioned on another thread with the same question, best practice when moving a thread which is no longer on-topic with Unix/TUHS (e.g., when westart talking about Mainframes, VMS, et. al) is to Bcc: TUHS saying that you are moving the discussion to COFF. That's because if you use CC, then when someone responds, it replies go to both list, instead of moving the discussion from one list to another. - Ted From paul.winalski at gmail.com Fri Jul 12 02:56:10 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Thu, 11 Jul 2024 12:56:10 -0400 Subject: [TUHS] Puzzled about COFF In-Reply-To: <20240711152558.GE10452@mit.edu> References: <20240711152558.GE10452@mit.edu> Message-ID: On Thu, Jul 11, 2024 at 11:26 AM Theodore Ts'o wrote: > As Clem mentioned on another thread with the same question, best > practice when moving a thread which is no longer on-topic with > Unix/TUHS (e.g., when westart talking about Mainframes, VMS, et. al) > is to Bcc: TUHS saying that you are moving the discussion to COFF. > That's because if you use CC, then when someone responds, it replies > go to both list, instead of moving the discussion from one list to > another. > You can blame me for the recent spate of messages intended for COFF going also to TUHS. The thread on instruction set emulation/translation had moved far off-topic for TUHS so I sent my reply to COFF, copying TUHS on the message announcing the transfer of the topic. But I used CC, not BCC, so some further replies in the thread went to both lists. Sorry about that, Chief! -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri Jul 12 04:36:55 2024 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Thu, 11 Jul 2024 13:36:55 -0500 Subject: [TUHS] Puzzled about COFF In-Reply-To: References: <20240711152558.GE10452@mit.edu> Message-ID: On 7/11/24 11:56 AM, Paul Winalski wrote: > You can blame me for the recent spate of messages intended for COFF > going also to TUHS.  The thread on instruction set emulation/translation > had moved far off-topic for TUHS so I sent my reply to COFF, copying > TUHS on the message announcing the transfer of the topic.  But I used > CC, not BCC, so some further replies in the thread went to both lists. I wonder if we could leverage some technology to help us. Specifically I wonder if we can cause Mailman to moderate messages to TUHS that are also CCed to COFF. While we're asking Mailman to do things, I wonder if we can have it remove TUHS from headers (From: and Reply-To:) from messages going to COFF. Hopefully this would steer messages a little bit. -- Grant. . . . unix || die From stuff at riddermarkfarm.ca Fri Jul 12 05:31:20 2024 From: stuff at riddermarkfarm.ca (Stuff Received) Date: Thu, 11 Jul 2024 15:31:20 -0400 Subject: [TUHS] When did "man cal" lose the comment about 1752? In-Reply-To: References: Message-ID: On 2024-07-10 21:44, Greg 'groggy' Lehey wrote (in part): > On Thursday, 11 July 2024 at 11:24:26 +1000, Dave Horsfall wrote: >> The manpage for "cal" used to have the comment "Try September 1752" (and >> yes, I know why); it's no longer there, so when did it disappear? The >> SysV fun police? >> >> I remember it in Ed5 and Ed6, but can't remember when I last saw it. > [...] > > It sounds like that's not the quote you're thinking of, though. I've > checked back as far as FreeBSD 1.0, which had a much simpler version > of cal. The man page states > > The Gregorian Reformation is assumed to have occurred in 1752 on the > 3rd of September. By this time, most countries had recognized the ref- > ormation (although a few did not recognize it until the early 1900's.) > Ten days following that date were eliminated by the reformation, so the > calendar for that month is a bit unusual. Solaris 11 has this version: NOTES An unusual calendar is printed for September 1752. That is the month 11 days were skipped to make up for lack of leap year adjustments. To see this calendar, type: cal 9 1752 S. From clemc at ccc.com Sat Jul 13 08:11:31 2024 From: clemc at ccc.com (Clem Cole) Date: Fri, 12 Jul 2024 18:11:31 -0400 Subject: [TUHS] Reference Cards for PDP8, PDP9, PDP-10, PDP11, TOPS-10 Message-ID: A few folks on the PIDP mailing lists asked me to put scans of the cards I have on-line. I included TUHS as some of the new to the PDP-11 folks might find these interesting also. I also included a few others from other folks. Note my scans are in 3 formats (JPG, TIFF, PDF) as each has advantages. Pick which one you prefer. I tried to scan in as a high a resolution as I could in case some one wants to try to print the later. I may try adding some of my other cards, such as my microprocessor and IBM collections. In the future https://drive.google.com/open?id=13dPAlRMQEwNvPwLXwlOC5Q_ZrQp4IpkJ&usp=drive_fs ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From woods at robohack.ca Mon Jul 15 05:04:44 2024 From: woods at robohack.ca (Greg A. Woods) Date: Sun, 14 Jul 2024 12:04:44 -0700 Subject: [TUHS] When did "man cal" lose the comment about 1752? In-Reply-To: References: Message-ID: At Wed, 10 Jul 2024 21:53:54 -0400, Henry Bent wrote: Subject: [TUHS] Re: When did "man cal" lose the comment about 1752? > > Looks like on the BSD side it disappeared between 4.3 Tahoe and Reno. It's > in research through v10. It's in SVR2; SVR4 modifies it to say "An unusual > calendar is printed for September 1752." I don't seem to have manpages > with either of the SVR3 source distributions that I have handy. So to > answer your basic question, it stayed around for quite a while. System V Release 3.2 MRD says the same thing as SVR4: An unusual calendar is printed for September 1752. That is the month 11 days were skipped to make up for lack of leap year adjustments. To see this calendar, type: "cal 9 1752" The "BUGS" section remains the same as it was in 7th Edition. In the CSRG SCCS files cal(1) was "updated" after the 4.3BSD release with this comment: src/usr.bin/cal/SCCS/s.cal.1 D 6.3 89/09/28 14:20:22 bostic 5 4 00042/00023/00009 MRs: COMMENTS: new version from Kim Letkeman (mitel!spock!kim at uunet.UU.NET) The code was also updated at the same time: src/usr.bin/cal/SCCS/s.cal.c D 4.5 89/09/28 14:20:24 bostic 5 4 00222/00159/00043 MRs: COMMENTS: new version from Kim Letkeman (mitel!spock!kim at uunet.UU.NET) This is of course a complete rewrite to give UCB the copyright. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From marc.donner at gmail.com Mon Jul 15 07:15:53 2024 From: marc.donner at gmail.com (Marc Donner) Date: Sun, 14 Jul 2024 17:15:53 -0400 Subject: [TUHS] When did "man cal" lose the comment about 1752? In-Reply-To: References: Message-ID: My instance of cal (MacOS 14.5) has this in the man page: -s country_code Assume the switch from Julian to Gregorian Calendar at the date associated with the country_code. If not specified, ncal tries to guess the switch date from the local environment or falls back to September 2, 1752. This was when Great Britain and her colonies switched to the Gregorian Calendar. Note that the switch to the Gregorian calendar happened at different times in different countries. In Catholic-dominated countries it happened in October of 1582. The English-speaking world, being Protestant-dominated, waited until September of 1752 to adopt it. ===== nygeek.net mindthegapdialogs.com/home On Wed, Jul 10, 2024 at 9:25 PM Dave Horsfall wrote: > The manpage for "cal" used to have the comment "Try September 1752" (and > yes, I know why); it's no longer there, so when did it disappear? The > SysV fun police? > > I remember it in Ed5 and Ed6, but can't remember when I last saw it. > > Thanks. > > -- Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Tue Jul 16 00:00:43 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 15 Jul 2024 10:00:43 -0400 Subject: [TUHS] When did "man cal" lose the comment about 1752? In-Reply-To: References: Message-ID: On Sun, Jul 14, 2024 at 5:25 PM Marc Donner wrote: > Note that the switch to the Gregorian calendar happened at different times > in different countries. In Catholic-dominated countries it happened in > October of 1582. The English-speaking world, being Protestant-dominated, > waited until September of 1752 to adopt it. > > And Russia didn't adopt the Gregorian calendar until 1918. IIRC the Eastern Orthodox churches still use the Julian calendar for scheduling ecclesiastical events such as the date of Easter. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From woods at robohack.ca Tue Jul 16 03:44:52 2024 From: woods at robohack.ca (Greg A. Woods) Date: Mon, 15 Jul 2024 10:44:52 -0700 Subject: [TUHS] When did "man cal" lose the comment about 1752? In-Reply-To: References: Message-ID: At Sun, 14 Jul 2024 17:15:53 -0400, Marc Donner wrote: Subject: [TUHS] Re: When did "man cal" lose the comment about 1752? > > My instance of cal (MacOS 14.5) has this in the man page: > > -s country_code > > Assume the switch from Julian to Gregorian Calendar at the date > associated with the country_code. If not specified, ncal tries > to guess the switch date from the local environment or falls back > to September 2, 1752. This was when Great Britain and her > colonies switched to the Gregorian Calendar. That's 'ncal' from FreeBSD, which is an entirely "new" implementation written by Wolfgang Helbig: commit 0cb2e609d9c2f0ceaf730a57ac5c11580058e7f4 Author: Wolfgang Helbig Date: Mon Dec 15 20:35:22 1997 +0000 Add new command ncal. > Note that the switch to the Gregorian calendar happened at different times > in different countries. In Catholic-dominated countries it happened in > October of 1582. The English-speaking world, being Protestant-dominated, > waited until September of 1752 to adopt it. Indeed! -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From marc.donner at gmail.com Tue Jul 16 04:21:58 2024 From: marc.donner at gmail.com (Marc Donner) Date: Mon, 15 Jul 2024 14:21:58 -0400 Subject: [TUHS] When did "man cal" lose the comment about 1752? In-Reply-To: References: Message-ID: To be turbo pedantic, Russia adopted a different calendar in 1918. Gregorian and Russian calendars will diverge in 4000 CE. ===== nygeek.net mindthegapdialogs.com/home On Mon, Jul 15, 2024 at 10:00 AM Paul Winalski wrote: > On Sun, Jul 14, 2024 at 5:25 PM Marc Donner > wrote: > >> Note that the switch to the Gregorian calendar happened at different >> times in different countries. In Catholic-dominated countries it happened >> in October of 1582. The English-speaking world, being >> Protestant-dominated, waited until September of 1752 to adopt it. >> >> And Russia didn't adopt the Gregorian calendar until 1918. IIRC the > Eastern Orthodox churches still use the Julian calendar for scheduling > ecclesiastical events such as the date of Easter. > > -Paul W. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at ultimate.com Tue Jul 16 04:41:39 2024 From: phil at ultimate.com (Phil Budne) Date: Mon, 15 Jul 2024 14:41:39 -0400 Subject: [TUHS] When did "man cal" lose the comment about 1752? In-Reply-To: References: Message-ID: <202407151841.46FIfdLp056775@ultimate.com> Rats! There doesn't seem to be a file in the TZ Database for me to set display to "Orthodox/Eastern"! Hard to believe Olson didn't consider it! From kenbob at gmail.com Tue Jul 16 05:03:41 2024 From: kenbob at gmail.com (Ken Thompson) Date: Mon, 15 Jul 2024 12:03:41 -0700 Subject: [TUHS] When did "man cal" lose the comment about 1752? In-Reply-To: References: Message-ID: it is worse than "per country", alaska changed when the u.s. bought it from russia. On Mon, Jul 15, 2024 at 10:45 AM Greg A. Woods wrote: > At Sun, 14 Jul 2024 17:15:53 -0400, Marc Donner > wrote: > Subject: [TUHS] Re: When did "man cal" lose the comment about 1752? > > > > My instance of cal (MacOS 14.5) has this in the man page: > > > > -s country_code > > > > Assume the switch from Julian to Gregorian Calendar at the > date > > associated with the country_code. If not specified, ncal > tries > > to guess the switch date from the local environment or > falls back > > to September 2, 1752. This was when Great Britain and her > > colonies switched to the Gregorian Calendar. > > That's 'ncal' from FreeBSD, which is an entirely "new" implementation > written by Wolfgang Helbig: > > commit 0cb2e609d9c2f0ceaf730a57ac5c11580058e7f4 > Author: Wolfgang Helbig > Date: Mon Dec 15 20:35:22 1997 +0000 > > Add new command ncal. > > > Note that the switch to the Gregorian calendar happened at different > times > > in different countries. In Catholic-dominated countries it happened in > > October of 1582. The English-speaking world, being Protestant-dominated, > > waited until September of 1752 to adopt it. > > Indeed! > > -- > Greg A. Woods > > Kelowna, BC +1 250 762-7675 RoboHack > Planix, Inc. Avoncote Farms > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenbob at gmail.com Tue Jul 16 05:04:40 2024 From: kenbob at gmail.com (Ken Thompson) Date: Mon, 15 Jul 2024 12:04:40 -0700 Subject: [TUHS] When did "man cal" lose the comment about 1752? In-Reply-To: References: Message-ID: it is worse than "per country", alaska changed when the u.s. bought it from russia. On Mon, Jul 15, 2024 at 12:03 PM Ken Thompson wrote: > it is worse than "per country", > alaska changed when the u.s. > bought it from russia. > > > On Mon, Jul 15, 2024 at 10:45 AM Greg A. Woods wrote: > >> At Sun, 14 Jul 2024 17:15:53 -0400, Marc Donner >> wrote: >> Subject: [TUHS] Re: When did "man cal" lose the comment about 1752? >> > >> > My instance of cal (MacOS 14.5) has this in the man page: >> > >> > -s country_code >> > >> > Assume the switch from Julian to Gregorian Calendar at the >> date >> > associated with the country_code. If not specified, ncal >> tries >> > to guess the switch date from the local environment or >> falls back >> > to September 2, 1752. This was when Great Britain and her >> > colonies switched to the Gregorian Calendar. >> >> That's 'ncal' from FreeBSD, which is an entirely "new" implementation >> written by Wolfgang Helbig: >> >> commit 0cb2e609d9c2f0ceaf730a57ac5c11580058e7f4 >> Author: Wolfgang Helbig >> Date: Mon Dec 15 20:35:22 1997 +0000 >> >> Add new command ncal. >> >> > Note that the switch to the Gregorian calendar happened at different >> times >> > in different countries. In Catholic-dominated countries it happened in >> > October of 1582. The English-speaking world, being >> Protestant-dominated, >> > waited until September of 1752 to adopt it. >> >> Indeed! >> >> -- >> Greg A. Woods >> >> Kelowna, BC +1 250 762-7675 RoboHack >> Planix, Inc. Avoncote Farms >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.donner at gmail.com Tue Jul 16 05:33:52 2024 From: marc.donner at gmail.com (Marc Donner) Date: Mon, 15 Jul 2024 15:33:52 -0400 Subject: [TUHS] When did "man cal" lose the comment about 1752? In-Reply-To: References: Message-ID: Yeah, but if you do that you have to treat the places acquired in the Louisiana Purchase differently because they switched in 1582. And Puerto Rico. Bleh. ===== nygeek.net mindthegapdialogs.com/home On Mon, Jul 15, 2024 at 3:04 PM Ken Thompson wrote: > it is worse than "per country", > alaska changed when the u.s. > bought it from russia. > > > On Mon, Jul 15, 2024 at 10:45 AM Greg A. Woods wrote: > >> At Sun, 14 Jul 2024 17:15:53 -0400, Marc Donner >> wrote: >> Subject: [TUHS] Re: When did "man cal" lose the comment about 1752? >> > >> > My instance of cal (MacOS 14.5) has this in the man page: >> > >> > -s country_code >> > >> > Assume the switch from Julian to Gregorian Calendar at the >> date >> > associated with the country_code. If not specified, ncal >> tries >> > to guess the switch date from the local environment or >> falls back >> > to September 2, 1752. This was when Great Britain and her >> > colonies switched to the Gregorian Calendar. >> >> That's 'ncal' from FreeBSD, which is an entirely "new" implementation >> written by Wolfgang Helbig: >> >> commit 0cb2e609d9c2f0ceaf730a57ac5c11580058e7f4 >> Author: Wolfgang Helbig >> Date: Mon Dec 15 20:35:22 1997 +0000 >> >> Add new command ncal. >> >> > Note that the switch to the Gregorian calendar happened at different >> times >> > in different countries. In Catholic-dominated countries it happened in >> > October of 1582. The English-speaking world, being >> Protestant-dominated, >> > waited until September of 1752 to adopt it. >> >> Indeed! >> >> -- >> Greg A. Woods >> >> Kelowna, BC +1 250 762-7675 RoboHack >> Planix, Inc. Avoncote Farms >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Tue Jul 16 05:52:22 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Mon, 15 Jul 2024 15:52:22 -0400 Subject: [TUHS] When did "man cal" lose the comment about 1752? Message-ID: > Yeah, but if you do that you have to treat the places > acquired in the Louisiana Purchase differently because > they switched in 1582. And Puerto Rico. Bleh. Then there are all the German city states. And the shifting borders of Poland. (cal -s country) is a mighty low-res "solution" to the Julian/Gregorian problem. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Tue Jul 16 06:02:42 2024 From: tuhs at tuhs.org (Jaap Akkerhuis via TUHS) Date: Mon, 15 Jul 2024 22:02:42 +0200 Subject: [TUHS] When did "man cal" lose the comment about 1752? In-Reply-To: References: Message-ID: <2A06CB50-B754-4939-8DDA-9E278960DCB4@xs4all.nl> > On 15 Jul 2024, at 21:04, Ken Thompson wrote: > > it is worse than "per country", > alaska changed when the u.s. > bought it from russia. Also note that the ISO country codes standard is from 1974. I guess that is why the FreeBSD ncal states that "The assignment of Julian–Gregorian switching dates to country codes is historically naive for many countries." What we call countries nowadays has changed over the years (and centuries). jaap From meillo at marmaro.de Tue Jul 16 16:59:18 2024 From: meillo at marmaro.de (markus schnalke) Date: Tue, 16 Jul 2024 08:59:18 +0200 Subject: [TUHS] When did "man cal" lose the comment about 1752? In-Reply-To: References: Message-ID: <1sTc9e-0hh-00@marmaro.de> Hoi. [2024-07-15 15:52] Douglas McIlroy > > > Yeah, but if you do that you have to treat the places > > acquired in the Louisiana Purchase differently because > > they switched in 1582.  And Puerto Rico.  Bleh. > > Then there are all the German city states. And the > shifting borders of Poland. (cal -s country) is a mighty > low-res "solution" to the Julian/Gregorian problem. Several of these small entities, adopting the Gregorian calendar at different times, you can see in this lenghty list: https://de.wikipedia.org/wiki/Gregorianischer_Kalender#%C3%9Cbernahme_des_gregorianischen_Kalenders (in German) meillo From paul.winalski at gmail.com Wed Jul 17 01:54:44 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Tue, 16 Jul 2024 11:54:44 -0400 Subject: [TUHS] When did "man cal" lose the comment about 1752? In-Reply-To: References: Message-ID: The whole Julian -> Gregorian calendar conversion thing must be a real mess for historians using contemporary date references. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Wed Jul 17 06:22:14 2024 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 16 Jul 2024 22:22:14 +0200 Subject: [TUHS] When did "man cal" lose the comment about 1752? In-Reply-To: <1sTc9e-0hh-00@marmaro.de> References: <1sTc9e-0hh-00@marmaro.de> Message-ID: <20240716202214.oppWyEEQ@steffen%sdaoden.eu> markus schnalke wrote in <1sTc9e-0hh-00 at marmaro.de>: |[2024-07-15 15:52] Douglas McIlroy |> |>> Yeah, but if you do that you have to treat the places |>> acquired in the Louisiana Purchase differently because |>> they switched in 1582.  And Puerto Rico.  Bleh. |> |> Then there are all the German city states. And the |> shifting borders of Poland. (cal -s country) is a mighty |> low-res "solution" to the Julian/Gregorian problem. | |Several of these small entities, adopting the Gregorian calendar at |different times, you can see in this lenghty list: | https://de.wikipedia.org/wiki/Gregorianischer_Kalender#%C3%9Cbernahme_de\ | s_gregorianischen_Kalenders |(in German) But mostly is Katholischer Teil (Corpus Catholicorum) early (a year late) / Evangelischer Teil (Corpus Evangelicorum) of the Heiliges Römisches Reich (holy roman empire) später (18.2. -> 1.3.1700). I would say, dependent on where you are, saying goes for the former or the latter to this very day. Aka i think i recall that posted to a similar thread in the past, quoting an article from the german computer magazine c't 15/1997, back from when i still gave (lots of diversely spread) money to german journalists; that i just pasted documentation comments, and that included (it included Gaius Julius Caesar back then i think) * Whereas (parts of \ldots) Germany, for example, adopted it in 1700 (i think), * Great Britain did so in 1752; * many countries adopted it in between 1912 and 1974, on the other hand. and * Furthermore, DateTime describes itself as a set of date algorithms, * which are influenced by Timezone (and sometimes Locale) objects. * This implies that we don't know much of the country or region; * the timezone "Europe/Berlin", for example, * applies to all of Germany \e today, * which cannot be compared to the bunch of principalities which existed in the * year 1700! Now again, what a pity. I think it is remarkable as traditionally we kept it "holding on the inside", ie working ourselves out with all the little states, borders, taxes, etc., with a little bit of swinging and such dependent on "good king / bad king" time passages. Except for maybe the crusades (though good kings died before reaching the holy land imho), but even those came to an end at times. Bring the boys back home! (Which rhymes to bring the boys' backbone, in respect to the "traditional german burial" Mos Teutonicus. Hihi.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From tuhs at tuhs.org Wed Jul 17 07:21:00 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 16 Jul 2024 21:21:00 +0000 Subject: [TUHS] When did "man cal" lose the comment about 1752? In-Reply-To: <20240716202214.oppWyEEQ@steffen%sdaoden.eu> References: <1sTc9e-0hh-00@marmaro.de> <20240716202214.oppWyEEQ@steffen%sdaoden.eu> Message-ID: On Tuesday, July 16th, 2024 at 1:22 PM, Steffen Nurpmeso wrote: > markus schnalke wrote in > 1sTc9e-0hh-00 at marmaro.de: > > |[2024-07-15 15:52] Douglas McIlroy douglas.mcilroy at dartmouth.edu > > |> > > |>> Yeah, but if you do that you have to treat the places > > |>> acquired in the Louisiana Purchase differently because > > |>> they switched in 1582. And Puerto Rico. Bleh. > > |> > > |> Then there are all the German city states. And the > > |> shifting borders of Poland. (cal -s country) is a mighty > > |> low-res "solution" to the Julian/Gregorian problem. > > | > |Several of these small entities, adopting the Gregorian calendar at > |different times, you can see in this lenghty list: > | https://de.wikipedia.org/wiki/Gregorianischer_Kalender#Übernahme_de\\ > | s_gregorianischen_Kalenders > |(in German) > > But mostly is Katholischer Teil (Corpus Catholicorum) early (a > year late) / Evangelischer Teil (Corpus Evangelicorum) of the > Heiliges Römisches Reich (holy roman empire) später (18.2. -> > > 1.3.1700). I would say, dependent on where you are, saying goes > for the former or the latter to this very day. Aka i think > i recall that posted to a similar thread in the past, quoting an > article from the german computer magazine c't 15/1997, back from > when i still gave (lots of diversely spread) money to german > journalists; that i just pasted documentation comments, and that > included (it included Gaius Julius Caesar back then i think) > > * Whereas (parts of \ldots) Germany, for example, adopted it in 1700 (i think), > * Great Britain did so in 1752; > * many countries adopted it in between 1912 and 1974, on the other hand. > > and > > * Furthermore, DateTime describes itself as a set of date algorithms, > * which are influenced by Timezone (and sometimes Locale) objects. > * This implies that we don't know much of the country or region; > * the timezone "Europe/Berlin", for example, > * applies to all of Germany \e today, > * which cannot be compared to the bunch of principalities which existed in the > * year 1700! > > Now again, what a pity. > > I think it is remarkable as traditionally we kept it "holding on > the inside", ie working ourselves out with all the little states, > borders, taxes, etc., with a little bit of swinging and such > dependent on "good king / bad king" time passages. Except for > maybe the crusades (though good kings died before reaching the > holy land imho), but even those came to an end at times. Bring > the boys back home! (Which rhymes to bring the boys' backbone, in > respect to the "traditional german burial" Mos Teutonicus. Hihi.) > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) Well and I would have to wonder how much the average person at the time was really tuned in with the calendars, years, etc. The church with their meticulous record keeping would've cared, as well as scientific circles (whose lines with the church were much blurrier then), but your average peasant in the field probably didn't care one way or another, so it seems like adoption of calendars at the time would've had a lot more to do with political/religious affiliation than any amount of impact on the life of an average subject. All that to say, unlike today's modern interconnected global community, back then it was probably fine to drag your feet on moving to some new calendar because most folks weren't looking that granularly at the calendar, they were looking at the sun, moon, and stars. Of course I wasn't there, so this is all postulation, and certainly adrift from the original question so I'll resist further musings on German calendar adoption. To tie it back, has anyone experience with cal(1) being retooled for non-western calendars, and if so, if similar problems have arisen? One country I could see being troublesome to target cal(1) for is Japan, their traditional concept of a year consists of two values, one being which emperor was on the throne and the other being the number of years since the ascension. In conventional date writing, they tend to only write the latter, mentioning the empire in the greater context to give a point of reference sure, but as a pointed example, the date stamps in the headers of several Japanese video games published in the 80s instead have a year in the 60s because it was 60 or so years after the ascension of Hirohito marking the Showa period. - Matt G. From tuhs at tuhs.org Thu Jul 18 06:51:04 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 17 Jul 2024 20:51:04 +0000 Subject: [TUHS] UNIX Roff Manual Message-ID: Just sharing a copy of the Roff Manual that I had forgotten I scanned a little while back: https://archive.org/details/roff_manual This appears to be the UNIX complement to the S/360 version of the paper backed up by Doug here: https://www.cs.dartmouth.edu/~doug/roff71/roff71.pdf >From the best I could tell, this predates both 1973's V3 and the 1971 S/360 version of the paper, putting it somewhere prior to 1971. For instance, it is missing the .ar, .hx, .ig, .ix, .ni, .nx, .ro, .ta, and .tc requests found in V3. The .ar and .ro, and .ta requests pop up in the S/360 paper, the rest are in the V3 manpage (prior manpages don't list the request summary). If anyone has some authoritative date information I can update the archive description accordingly. Finally, this very well could be missing the last page, the Page offset, Merge patterns, and Envoi sections of Doug's paper are not reflected here, although at the very least, the .mg request is not in this paper so the Merge patterns section probably wasn't there anyway. - Matt G. From lm at mcvoy.com Thu Jul 18 07:01:23 2024 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 17 Jul 2024 14:01:23 -0700 Subject: [TUHS] UNIX Roff Manual In-Reply-To: References: Message-ID: <20240717210123.GA32170@mcvoy.com> That's pretty cool and it sure looks a lot like nroff. On Wed, Jul 17, 2024 at 08:51:04PM +0000, segaloco via TUHS wrote: > Just sharing a copy of the Roff Manual that I had forgotten I scanned a little while back: > > https://archive.org/details/roff_manual > > This appears to be the UNIX complement to the S/360 version of the paper backed up by Doug here: https://www.cs.dartmouth.edu/~doug/roff71/roff71.pdf > > >From the best I could tell, this predates both 1973's V3 and the 1971 S/360 version of the paper, putting it somewhere prior to 1971. For instance, it is missing the .ar, .hx, .ig, .ix, .ni, .nx, .ro, .ta, and .tc requests found in V3. The .ar and .ro, and .ta requests pop up in the S/360 paper, the rest are in the V3 manpage (prior manpages don't list the request summary). > > If anyone has some authoritative date information I can update the archive description accordingly. > > Finally, this very well could be missing the last page, the Page offset, Merge patterns, and Envoi sections of Doug's paper are not reflected here, although at the very least, the .mg request is not in this paper so the Merge patterns section probably wasn't there anyway. > > - Matt G. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Thu Jul 18 07:45:57 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 17 Jul 2024 21:45:57 +0000 Subject: [TUHS] UNIX Roff Manual In-Reply-To: References: Message-ID: On Wednesday, July 17th, 2024 at 1:51 PM, segaloco wrote: > Just sharing a copy of the Roff Manual that I had forgotten I scanned a little while back: > > https://archive.org/details/roff_manual > > This appears to be the UNIX complement to the S/360 version of the paper backed up by Doug here: https://www.cs.dartmouth.edu/~doug/roff71/roff71.pdf > > From the best I could tell, this predates both 1973's V3 and the 1971 S/360 version of the paper, putting it somewhere prior to 1971. For instance, it is missing the .ar, .hx, .ig, .ix, .ni, .nx, .ro, .ta, and .tc requests found in V3. The .ar and .ro, and .ta requests pop up in the S/360 paper, the rest are in the V3 manpage (prior manpages don't list the request summary). > > If anyone has some authoritative date information I can update the archive description accordingly. > > Finally, this very well could be missing the last page, the Page offset, Merge patterns, and Envoi sections of Doug's paper are not reflected here, although at the very least, the .mg request is not in this paper so the Merge patterns section probably wasn't there anyway. > > - Matt G. Just a correction Tom Lyon pointed out, the 1971 BCPL paper is for a *GECOS*, not S/360 version, it just suggests sending the print jobs then to a S/360 machine, the roff itself is GECOS. - Matt G. From pugs78 at gmail.com Thu Jul 18 08:45:04 2024 From: pugs78 at gmail.com (Tom Lyon) Date: Wed, 17 Jul 2024 15:45:04 -0700 Subject: [TUHS] UNIX Roff Manual In-Reply-To: References: Message-ID: I had meant to copy TUSH on this/ On Wed, Jul 17, 2024 at 2:41 PM Tom Lyon wrote: > I got excited by your mention of a S/360 version, but Doug's link talks > about the GECOS version (GE/Honeywell hardware). > > Princeton had a S/360 version at about that time, it was a re-write of a > version for the IBM 7094 done by Kernighan after spending a summer at MIT > with CTSS and RUNOFF. I'm very curious whether the Princeton S/360 version > spread to other locations. Found this article in the Daily Princetonian > about the joy and history of ROFF. > https://photos.app.goo.gl/zMWV1GRLZdNBUuP36 > > On Wed, Jul 17, 2024 at 1:51 PM segaloco via TUHS wrote: > >> Just sharing a copy of the Roff Manual that I had forgotten I scanned a >> little while back: >> >> https://archive.org/details/roff_manual >> >> This appears to be the UNIX complement to the S/360 version of the paper >> backed up by Doug here: >> https://www.cs.dartmouth.edu/~doug/roff71/roff71.pdf >> >> From the best I could tell, this predates both 1973's V3 and the 1971 >> S/360 version of the paper, putting it somewhere prior to 1971. For >> instance, it is missing the .ar, .hx, .ig, .ix, .ni, .nx, .ro, .ta, and .tc >> requests found in V3. The .ar and .ro, and .ta requests pop up in the >> S/360 paper, the rest are in the V3 manpage (prior manpages don't list the >> request summary). >> >> If anyone has some authoritative date information I can update the >> archive description accordingly. >> >> Finally, this very well could be missing the last page, the Page offset, >> Merge patterns, and Envoi sections of Doug's paper are not reflected here, >> although at the very least, the .mg request is not in this paper so the >> Merge patterns section probably wasn't there anyway. >> >> - Matt G. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Jul 18 10:18:25 2024 From: clemc at ccc.com (Clem Cole) Date: Wed, 17 Jul 2024 20:18:25 -0400 Subject: [TUHS] UNIX Roff Manual In-Reply-To: References: Message-ID: Wow. That article gives me some interesting insight. I knew and used something at CMU called roff on TSS but I never knew where it came from. It was the first in any of those families of programs I learned to use. I had thought it was just part of our TSS system. But your article says the Princeton version was written by my old friend Paul Hillfinger. Paul was a CMU grad student. While most of the CS folks used the PDP-10s, Paul was one of few that knew his way around the IBM gear - which in fact was how I had met him. I would help him with systems issues since I was one of the programmers working for the Computer Center (which ran the IBM gear). It is quite possible he introduced me to it. If it was not native to TSS, a WAG is that he brought it with him. I’ll have to ask him. Clem Sent from a handheld expect more typos than usual On Wed, Jul 17, 2024 at 6:45 PM Tom Lyon wrote: > I had meant to copy TUSH on this/ > > On Wed, Jul 17, 2024 at 2:41 PM Tom Lyon wrote: > >> I got excited by your mention of a S/360 version, but Doug's link talks >> about the GECOS version (GE/Honeywell hardware). >> >> Princeton had a S/360 version at about that time, it was a re-write of a >> version for the IBM 7094 done by Kernighan after spending a summer at MIT >> with CTSS and RUNOFF. I'm very curious whether the Princeton S/360 version >> spread to other locations. Found this article in the Daily Princetonian >> about the joy and history of ROFF. >> https://photos.app.goo.gl/zMWV1GRLZdNBUuP36 >> > >> On Wed, Jul 17, 2024 at 1:51 PM segaloco via TUHS wrote: >> >>> Just sharing a copy of the Roff Manual that I had forgotten I scanned a >>> little while back: >>> >>> https://archive.org/details/roff_manual >>> >>> This appears to be the UNIX complement to the S/360 version of the paper >>> backed up by Doug here: >>> https://www.cs.dartmouth.edu/~doug/roff71/roff71.pdf >>> >>> From the best I could tell, this predates both 1973's V3 and the 1971 >>> S/360 version of the paper, putting it somewhere prior to 1971. For >>> instance, it is missing the .ar, .hx, .ig, .ix, .ni, .nx, .ro, .ta, and .tc >>> requests found in V3. The .ar and .ro, and .ta requests pop up in the >>> S/360 paper, the rest are in the V3 manpage (prior manpages don't list the >>> request summary). >>> >>> If anyone has some authoritative date information I can update the >>> archive description accordingly. >>> >>> Finally, this very well could be missing the last page, the Page offset, >>> Merge patterns, and Envoi sections of Doug's paper are not reflected here, >>> although at the very least, the .mg request is not in this paper so the >>> Merge patterns section probably wasn't there anyway. >>> >>> - Matt G. >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From pugs78 at gmail.com Thu Jul 18 10:33:54 2024 From: pugs78 at gmail.com (Tom Lyon) Date: Wed, 17 Jul 2024 17:33:54 -0700 Subject: [TUHS] UNIX Roff Manual In-Reply-To: References: Message-ID: If you find Paul, ask him if there was another version between BWK's and his. If he is class of 73, he would've started in 69, which is after the 7094 was gone. On Wed, Jul 17, 2024 at 5:18 PM Clem Cole wrote: > Wow. That article gives me some interesting insight. I knew and used > something at CMU called roff on TSS but I never knew where it came from. > It was the first in any of those families of programs I learned to use. I > had thought it was just part of our TSS system. > > But your article says the Princeton version was written by my old friend > Paul Hillfinger. Paul was a CMU grad student. While most of the CS folks > used the PDP-10s, Paul was one of few that knew his way around the IBM gear > - which in fact was how I had met him. I would help him with systems > issues since I was one of the programmers working for the Computer Center > (which ran the IBM gear). It is quite possible he introduced me to it. > If it was not native to TSS, a WAG is that he brought it with him. I’ll > have to ask him. > > Clem > > Sent from a handheld expect more typos than usual > > > On Wed, Jul 17, 2024 at 6:45 PM Tom Lyon wrote: > >> I had meant to copy TUSH on this/ >> >> On Wed, Jul 17, 2024 at 2:41 PM Tom Lyon wrote: >> >>> I got excited by your mention of a S/360 version, but Doug's link talks >>> about the GECOS version (GE/Honeywell hardware). >>> >>> Princeton had a S/360 version at about that time, it was a re-write of a >>> version for the IBM 7094 done by Kernighan after spending a summer at MIT >>> with CTSS and RUNOFF. I'm very curious whether the Princeton S/360 version >>> spread to other locations. Found this article in the Daily Princetonian >>> about the joy and history of ROFF. >>> https://photos.app.goo.gl/zMWV1GRLZdNBUuP36 >>> >> >>> On Wed, Jul 17, 2024 at 1:51 PM segaloco via TUHS wrote: >>> >>>> Just sharing a copy of the Roff Manual that I had forgotten I scanned a >>>> little while back: >>>> >>>> https://archive.org/details/roff_manual >>>> >>>> This appears to be the UNIX complement to the S/360 version of the >>>> paper backed up by Doug here: >>>> https://www.cs.dartmouth.edu/~doug/roff71/roff71.pdf >>>> >>>> From the best I could tell, this predates both 1973's V3 and the 1971 >>>> S/360 version of the paper, putting it somewhere prior to 1971. For >>>> instance, it is missing the .ar, .hx, .ig, .ix, .ni, .nx, .ro, .ta, and .tc >>>> requests found in V3. The .ar and .ro, and .ta requests pop up in the >>>> S/360 paper, the rest are in the V3 manpage (prior manpages don't list the >>>> request summary). >>>> >>>> If anyone has some authoritative date information I can update the >>>> archive description accordingly. >>>> >>>> Finally, this very well could be missing the last page, the Page >>>> offset, Merge patterns, and Envoi sections of Doug's paper are not >>>> reflected here, although at the very least, the .mg request is not in this >>>> paper so the Merge patterns section probably wasn't there anyway. >>>> >>>> - Matt G. >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsg at jsg.id.au Thu Jul 18 10:42:02 2024 From: jsg at jsg.id.au (Jonathan Gray) Date: Thu, 18 Jul 2024 10:42:02 +1000 Subject: [TUHS] UNIX Roff Manual In-Reply-To: References: Message-ID: On Wed, Jul 17, 2024 at 09:45:57PM +0000, segaloco via TUHS wrote: > On Wednesday, July 17th, 2024 at 1:51 PM, segaloco wrote: > > > Just sharing a copy of the Roff Manual that I had forgotten I scanned a little while back: > > > > https://archive.org/details/roff_manual > > > > This appears to be the UNIX complement to the S/360 version of the paper backed up by Doug here: https://www.cs.dartmouth.edu/~doug/roff71/roff71.pdf > > > > From the best I could tell, this predates both 1973's V3 and the 1971 S/360 version of the paper, putting it somewhere prior to 1971. For instance, it is missing the .ar, .hx, .ig, .ix, .ni, .nx, .ro, .ta, and .tc requests found in V3. The .ar and .ro, and .ta requests pop up in the S/360 paper, the rest are in the V3 manpage (prior manpages don't list the request summary). > > > > If anyone has some authoritative date information I can update the archive description accordingly. > > > > Finally, this very well could be missing the last page, the Page offset, Merge patterns, and Envoi sections of Doug's paper are not reflected here, although at the very least, the .mg request is not in this paper so the Merge patterns section probably wasn't there anyway. > > > > - Matt G. > > Just a correction Tom Lyon pointed out, the 1971 BCPL paper is for a *GECOS*, not S/360 version, it just suggests sending the print jobs then to a S/360 machine, the roff itself is GECOS. > > - Matt G. Kernighan's OS/360 roff is described in "Manuscript Printing under OS/360: ROFF" and email linked from https://manpages.bsd.lv/history.html From johnl at taugh.com Thu Jul 18 11:21:28 2024 From: johnl at taugh.com (John Levine) Date: 17 Jul 2024 21:21:28 -0400 Subject: [TUHS] roff at Princeton, Re: UNIX Roff Manual In-Reply-To: References: Message-ID: <20240718012129.6E0948FF9195@ary.qy> It appears that Tom Lyon said: >> Princeton had a S/360 version at about that time, it was a re-write of a >> version for the IBM 7094 done by Kernighan after spending a summer at MIT >> with CTSS and RUNOFF. I'm very curious whether the Princeton S/360 version >> spread to other locations. I used it when I was in high school. Princeton ran a bunch of free services on their 360/91. You could submit a deck with a control card saying which one you wanted, and it batched them up and ran them periodically. They offered WATFOR (probably WATFIV), SNOBOL4, AlgolW/PL360 and ROFF and WROFF. WROFF ran less often and it printed on white paper that burst to 8.5x11 rather than the usual green bar. They had 1403N1 printers with a nice looking upper/lower case type train, the same one used to print a lot of manuals and Gries' compiler book. It was the same idea as the roff's we're used adjusted for card input. The keypunches were upper case only so it automatically converted all the text to lower case except the first letter in a sentence, with some way to mark a letter or word to be left in upper case. In the manual the sample sentence was (not sure about the # escape): IT WAS A LOUSY DAY IN #PRINCETON. which turned into It was a lousy day in Princeton. It worked well, although for me it was more hassle than it was worth because it was a long walk from my house to the comp center or the enngineering building where there was an RJE 360/20. They also had a 360/67 running TSS, insofar as TSS worked which was badly. It had an editor TYPSET and formatter RUNOFF which I think were like the CTSS versions. The terminals were 2741s with upper/lower case typeballs. I never heard of anyone using any of those other than at Princeton. From pugs78 at gmail.com Thu Jul 18 11:28:49 2024 From: pugs78 at gmail.com (Tom Lyon) Date: Wed, 17 Jul 2024 18:28:49 -0700 Subject: [TUHS] UNIX Roff Manual In-Reply-To: References: Message-ID: Jonathan - awesome! Some Princeton timing: the 360/67 arrived in 1967, but was replaced in the summer of 1969 by the 360/91. BWK must've got started on the 7094 that preceded the 67, but since it was FORTRAN the port wasn't hard. Now I wonder what Paul Hilfinger did and whether it was still FORTRAN. I graduated in 1978, ROFF usage was still going strong! On Wed, Jul 17, 2024 at 5:42 PM Jonathan Gray wrote: > On Wed, Jul 17, 2024 at 09:45:57PM +0000, segaloco via TUHS wrote: > > On Wednesday, July 17th, 2024 at 1:51 PM, segaloco < > segaloco at protonmail.com> wrote: > > > > > Just sharing a copy of the Roff Manual that I had forgotten I scanned > a little while back: > > > > > > https://archive.org/details/roff_manual > > > > > > This appears to be the UNIX complement to the S/360 version of the > paper backed up by Doug here: > https://www.cs.dartmouth.edu/~doug/roff71/roff71.pdf > > > > > > From the best I could tell, this predates both 1973's V3 and the 1971 > S/360 version of the paper, putting it somewhere prior to 1971. For > instance, it is missing the .ar, .hx, .ig, .ix, .ni, .nx, .ro, .ta, and .tc > requests found in V3. The .ar and .ro, and .ta requests pop up in the S/360 > paper, the rest are in the V3 manpage (prior manpages don't list the > request summary). > > > > > > If anyone has some authoritative date information I can update the > archive description accordingly. > > > > > > Finally, this very well could be missing the last page, the Page > offset, Merge patterns, and Envoi sections of Doug's paper are not > reflected here, although at the very least, the .mg request is not in this > paper so the Merge patterns section probably wasn't there anyway. > > > > > > - Matt G. > > > > Just a correction Tom Lyon pointed out, the 1971 BCPL paper is for a > *GECOS*, not S/360 version, it just suggests sending the print jobs then to > a S/360 machine, the roff itself is GECOS. > > > > - Matt G. > > Kernighan's OS/360 roff is described in > "Manuscript Printing under OS/360: ROFF" and email linked from > https://manpages.bsd.lv/history.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnl at taugh.com Thu Jul 18 11:58:53 2024 From: johnl at taugh.com (John Levine) Date: 17 Jul 2024 21:58:53 -0400 Subject: [TUHS] UNIX Roff Manual In-Reply-To: References: Message-ID: <20240718015854.80FF28FF980D@ary.qy> It appears that Tom Lyon said: >-=-=-=-=-=- > >Jonathan - awesome! >Some Princeton timing: the 360/67 arrived in 1967, but was replaced in the >summer of 1969 by the 360/91. No, the /67 and /91 were there at the same time. I used them both in high school. I graduated in 1971 so that must have been 1969 to 71, and when I left I'm pretty sure both were still there. R's, John >BWK must've got started on the 7094 that preceded the 67, but since it was >FORTRAN the port wasn't hard. >Now I wonder what Paul Hilfinger did and whether it was still FORTRAN. > >I graduated in 1978, ROFF usage was still going strong! > >On Wed, Jul 17, 2024 at 5:42 PM Jonathan Gray wrote: > >> On Wed, Jul 17, 2024 at 09:45:57PM +0000, segaloco via TUHS wrote: >> > On Wednesday, July 17th, 2024 at 1:51 PM, segaloco < >> segaloco at protonmail.com> wrote: >> > >> > > Just sharing a copy of the Roff Manual that I had forgotten I scanned >> a little while back: >> > > >> > > https://archive.org/details/roff_manual From pugs78 at gmail.com Thu Jul 18 12:22:55 2024 From: pugs78 at gmail.com (Tom Lyon) Date: Wed, 17 Jul 2024 19:22:55 -0700 Subject: [TUHS] UNIX Roff Manual In-Reply-To: <20240718015854.80FF28FF980D@ary.qy> References: <20240718015854.80FF28FF980D@ary.qy> Message-ID: Yeah, I wasn't specific enough. The ownership of the model 67 changed to the State of NJ, but it was operated and present at Princeton, until replaced by a 370/158, which in turn changed owners back to Princeton in 75. What OS did you use on the 67? On Wed, Jul 17, 2024 at 6:58 PM John Levine wrote: > It appears that Tom Lyon said: > >-=-=-=-=-=- > > > >Jonathan - awesome! > >Some Princeton timing: the 360/67 arrived in 1967, but was replaced in the > >summer of 1969 by the 360/91. > > No, the /67 and /91 were there at the same time. I used them both in high > school. > I graduated in 1971 so that must have been 1969 to 71, and when I left I'm > pretty > sure both were still there. > > R's, > John > > > >BWK must've got started on the 7094 that preceded the 67, but since it was > >FORTRAN the port wasn't hard. > >Now I wonder what Paul Hilfinger did and whether it was still FORTRAN. > > > >I graduated in 1978, ROFF usage was still going strong! > > > >On Wed, Jul 17, 2024 at 5:42 PM Jonathan Gray wrote: > > > >> On Wed, Jul 17, 2024 at 09:45:57PM +0000, segaloco via TUHS wrote: > >> > On Wednesday, July 17th, 2024 at 1:51 PM, segaloco < > >> segaloco at protonmail.com> wrote: > >> > > >> > > Just sharing a copy of the Roff Manual that I had forgotten I > scanned > >> a little while back: > >> > > > >> > > https://archive.org/details/roff_manual > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsg at jsg.id.au Thu Jul 18 14:23:18 2024 From: jsg at jsg.id.au (Jonathan Gray) Date: Thu, 18 Jul 2024 14:23:18 +1000 Subject: [TUHS] UNIX Roff Manual In-Reply-To: References: Message-ID: "It is a lousy day in Princeton" changes to "It is a nice day in Princeton" in: https://apps.dtic.mil/sti/tr/pdf/AD0751318.pdf https://archive.org/details/DTIC_AD0751318/mode/2up ROFF - A MANUSCRIPT PRINTING PROGRAM: USER’S MANUAL Clifford E. Rhoades, Jr. November 1972 "This particular version of ROFF is a modified form of an IBM OS/360 program written by Dr. Peter Crean as revised to incorporate equation writing by Dr. Stephen Fulling at Princeton." Includes a FORTRAN listing at the end. Kernighan is not credited but the manual is clearly derived from his. On Wed, Jul 17, 2024 at 06:28:49PM -0700, Tom Lyon wrote: > Jonathan - awesome! > Some Princeton timing: the 360/67 arrived in 1967, but was replaced in the > summer of 1969 by the 360/91. > BWK must've got started on the 7094 that preceded the 67, but since it was > FORTRAN the port wasn't hard. > Now I wonder what Paul Hilfinger did and whether it was still FORTRAN. > > I graduated in 1978, ROFF usage was still going strong! > > On Wed, Jul 17, 2024 at 5:42 PM Jonathan Gray wrote: > > > On Wed, Jul 17, 2024 at 09:45:57PM +0000, segaloco via TUHS wrote: > > > On Wednesday, July 17th, 2024 at 1:51 PM, segaloco < > > segaloco at protonmail.com> wrote: > > > > > > > Just sharing a copy of the Roff Manual that I had forgotten I scanned > > a little while back: > > > > > > > > https://archive.org/details/roff_manual > > > > > > > > This appears to be the UNIX complement to the S/360 version of the > > paper backed up by Doug here: > > https://www.cs.dartmouth.edu/~doug/roff71/roff71.pdf > > > > > > > > From the best I could tell, this predates both 1973's V3 and the 1971 > > S/360 version of the paper, putting it somewhere prior to 1971. For > > instance, it is missing the .ar, .hx, .ig, .ix, .ni, .nx, .ro, .ta, and .tc > > requests found in V3. The .ar and .ro, and .ta requests pop up in the S/360 > > paper, the rest are in the V3 manpage (prior manpages don't list the > > request summary). > > > > > > > > If anyone has some authoritative date information I can update the > > archive description accordingly. > > > > > > > > Finally, this very well could be missing the last page, the Page > > offset, Merge patterns, and Envoi sections of Doug's paper are not > > reflected here, although at the very least, the .mg request is not in this > > paper so the Merge patterns section probably wasn't there anyway. > > > > > > > > - Matt G. > > > > > > Just a correction Tom Lyon pointed out, the 1971 BCPL paper is for a > > *GECOS*, not S/360 version, it just suggests sending the print jobs then to > > a S/360 machine, the roff itself is GECOS. > > > > > > - Matt G. > > > > Kernighan's OS/360 roff is described in > > "Manuscript Printing under OS/360: ROFF" and email linked from > > https://manpages.bsd.lv/history.html > > From arnold at skeeve.com Thu Jul 18 21:11:40 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 18 Jul 2024 05:11:40 -0600 Subject: [TUHS] UNIX Roff Manual In-Reply-To: References: Message-ID: <202407181111.46IBBeBe845346@freefriends.org> Jonathan Gray wrote: > Kernighan's OS/360 roff is described in > "Manuscript Printing under OS/360: ROFF" and email linked from > https://manpages.bsd.lv/history.html The "high resolution" scan seems to have multiple duplicated pages... It's neat to see: printed on green bar! :-) Arnold From mobile at majumdar.org.uk Tue Jul 30 08:53:36 2024 From: mobile at majumdar.org.uk (Dibyendu Majumdar) Date: Mon, 29 Jul 2024 23:53:36 +0100 Subject: [TUHS] Question regarding Limbo Message-ID: Hi, Apologies for the off topic question. I was curious who wrote the Limbo programing language that is part of Inferno. Regards Dibyendu From henry.r.bent at gmail.com Tue Jul 30 09:04:38 2024 From: henry.r.bent at gmail.com (Henry Bent) Date: Mon, 29 Jul 2024 19:04:38 -0400 Subject: [TUHS] Question regarding Limbo In-Reply-To: References: Message-ID: https://www.vitanuova.com/inferno/papers/descent.html says "Sean Dorward, Phil Winterbottom, and Rob Pike" -Henry On Mon, Jul 29, 2024, 18:54 Dibyendu Majumdar wrote: > Hi, > > Apologies for the off topic question. I was curious who wrote the > Limbo programing language that is part of Inferno. > > Regards > Dibyendu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From henesy.dev at gmail.com Tue Jul 30 09:24:27 2024 From: henesy.dev at gmail.com (Sean Hinchee) Date: Mon, 29 Jul 2024 16:24:27 -0700 Subject: [TUHS] Question regarding Limbo In-Reply-To: References: Message-ID: >From http://doc.cat-v.org/inferno/4th_edition/limbo_language/ "Limbo is a concurrent programming language developed by Sean Dorward, Phil Winterbottom, and Rob Pike at Bell Labs for the Inferno operating system." On Mon, Jul 29, 2024 at 3:54 PM Dibyendu Majumdar wrote: > > Hi, > > Apologies for the off topic question. I was curious who wrote the > Limbo programing language that is part of Inferno. > > Regards > Dibyendu From robpike at gmail.com Tue Jul 30 11:00:53 2024 From: robpike at gmail.com (Rob Pike) Date: Tue, 30 Jul 2024 11:00:53 +1000 Subject: [TUHS] Question regarding Limbo In-Reply-To: References: Message-ID: Phil Winterbottom, Sean Dorward and I. -rob On Tue, Jul 30, 2024 at 9:00 AM Dibyendu Majumdar wrote: > Hi, > > Apologies for the off topic question. I was curious who wrote the > Limbo programing language that is part of Inferno. > > Regards > Dibyendu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fariborz.t at gmail.com Tue Jul 30 11:28:35 2024 From: fariborz.t at gmail.com (Skip Tavakkolian) Date: Mon, 29 Jul 2024 18:28:35 -0700 Subject: [TUHS] Question regarding Limbo In-Reply-To: References: Message-ID: https://doc.cat-v.org/inferno/4th_edition/limbo_language/ On Mon, Jul 29, 2024, 3:54 PM Dibyendu Majumdar wrote: > Hi, > > Apologies for the off topic question. I was curious who wrote the > Limbo programing language that is part of Inferno. > > Regards > Dibyendu > -------------- next part -------------- An HTML attachment was scrubbed... URL: