From arnold at skeeve.com Fri Sep 2 19:12:23 2022 From: arnold at skeeve.com (Arnold Robbins) Date: Fri, 02 Sep 2022 12:12:23 +0300 Subject: [TUHS] PCC Revived is back up Message-ID: Hi All. Thanks to Jeremy C. Reed who's email to the maintainer got the PCC Revived website and CVS back up. Thanks to everyone who let me know that it's back up. :-) My github mirror is https://github.com/arnoldrobbins/pcc-revived and there are links there to the website etc. My repo has a branch 'ubuntu18' with diffs for running PCC on Ubuntu, if that interests anyone. Enjoy, Arnold From jbglaw at lug-owl.de Sat Sep 3 05:23:26 2022 From: jbglaw at lug-owl.de (Jan-Benedict Glaw) Date: Fri, 2 Sep 2022 21:23:26 +0200 Subject: [TUHS] PCC Revived is back up In-Reply-To: References: Message-ID: <20220902192326.i5jwfff6spz6snxm@lug-owl.de> Hi! On Fri, 2022-09-02 12:12:23 +0300, Arnold Robbins wrote: > Thanks to Jeremy C. Reed who's email to the maintainer got the PCC Revived > website and CVS back up. > > Thanks to everyone who let me know that it's back up. :-) > > My github mirror is https://github.com/arnoldrobbins/pcc-revived and there > are links there to the website etc. I do regular builds of GNU Binutils + GCC, NetBSD, Linux and SIMH and will add PCC to the list. > My repo has a branch 'ubuntu18' with diffs for running PCC on Ubuntu, > if that interests anyone. I'll try to build master first (though my setup aims to build with the latest Debian "unstable" code, let's see where this ends.) Thanks for the GIT conversion! MfG, JBG -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From mochid at netside.co.jp Mon Sep 5 13:55:20 2022 From: mochid at netside.co.jp (MOCHIDA Shuji) Date: Mon, 05 Sep 2022 12:55:20 +0900 (JST) Subject: [TUHS] i386 binary of 4.4BSD-Alpha Message-ID: <20220905.125520.1044731729545828502.mochid@netside.co.jp> I added i386 binary compiled from 4.4BSD-Alpha source. http://www.netside.co.jp/~mochid/comp/bsd44-build/ Boot with bochs works rather well. qemu-system-i386 also boots, and NIC (NE2000 ne0) works good, but kernel prints many "ISA strayintr" messages. I got many useful infomations from below 2 sites: "Fun with virtualization" https://virtuallyfun.com/ 386bsd bochs qemu "Computer History Wiki!" https://gunkies.org/wiki/Main_Page Installing 386BSD on BOCHS First time, I tried to compile i386 using 4.4BSD final (1995) source, patching many many pieces from 386BSD, NetBSD, and else.. but then, I felt "Well, we have BSD/OS 2.0, NetBSD 1.0, and FreeBSD 2.0 those are full of good improvements.." So, I changed target, and remebered Pace Willisson's memo in 4.4BSD (and in 4.4BSD-Lite2 also) sys/i386/i386/README: "4.4BSD-alpha 80386/80486 Status" June 20, 1992 that file says "can be compiled into a fairly usable system". yeah, needed chages not so small, though. -mochid From sjenkin at canb.auug.org.au Tue Sep 6 09:48:16 2022 From: sjenkin at canb.auug.org.au (steve jenkin) Date: Tue, 6 Sep 2022 09:48:16 +1000 Subject: [TUHS] Has this been discussed on-list? How Unix changed Software. Message-ID: <453CCF20-3A01-4655-A956-149EDC08FA36@canb.auug.org.au> I’ve been looking at this question for a time and thought it could’ve appeared on the TUHS list - but don’t have an idea of the search terms to use on the list. Perhaps someone suggest some to me. As a starting point, below is what John Lions wrote on a similar topic in 1978. Conspicuously, “Security” is missing, though “Reliability & Maintenance” would encompass the idea. With hindsight, I’d suggest (Research) Unix took a very strong stance on “Technical Debt” - it was small, clean & efficient, even elegant. And ‘shipped' with zero known bugs. It didn’t just bring the Unix kernel to many architectures, the same tools were applied to create what we now call “Open Source” in User land: - Multi-platform / portable - the very act of porting software to diverse architectures uncovered new classes of bugs and implicit assumptions. Big- & Little-endian were irrelevant or unknown Before Unix. - full source - compatibility layers via - written in common, well-known, well-supported languages [ solving the maintenance & update problem ] - standard, portable “toolchains” - shell, make, compiler, library tools for system linker, documentation & doc reading tools - distribution systems including test builds, issue / fault reporting & tracking An emergent property is "Good Security”, both by Design and by (mostly) error-free implementations. In the Epoch Before Unix (which started when exactly?), there was a lot of Shared Software, but very little that could be mechanically ported to another architecture. Tools like QED and ROFF were reimplemented on multiple platforms, not ‘ported’ in current lingo. There are still large, complex FORTRAN libraries shared as source. There’s an important distinction between “Open” and “Free” : cost & availability. We’ve gone on to have broadband near universally available with easy to use Internet collaboration tools - e.g. “git”, “mercurial” and “Subversion” just as CVS’s. The Unix-created Open Source concept broke Vendor Lock-in & erased most “Silos”. The BSD TCP/IP stack, and Berkeley sockets library, were sponsored by DARPA, and made freely available to vendors as source code. Similarly, important tools for SMTP and DNS were freely available as Source Code, both speeding the implementation of Internet services and providing “out of the box” protocol / function compatibility. The best tools, or even just adequate, became only a download & install away for all coding shops, showing up a lot of poor code developed by in-house “experts” and radically trimming many project schedules. While the Unix “Software Tools” approach - mediated by the STDOUT / STDIN interface, not API’s - was new & radical, and for many classes of problems, provided a definitive solution, I’d not include it in a list of “Open Source” features. It assumes a “command line” and process pipelines, which aren’t relevant to very large post-Unix program classes: Graphical Apps and Web / Internet services. regards steve jenkin ============== Lions, J., "An operating system case study" ACM SIGOPS Operating Systems Review, July 1978, ACM SIGOPS Oper. Syst. Rev. 12(3): 46-53 (1978) 2. Some Comments on UNIX ------------------------ There is no space here to describe the technical features of UNIX in detail (see Ritchie and Thompson, 1974 ; also Kernighan and Plauger, 1976), nor to document its performance characteristics, which we have found to be very satisfactory. The following general comments do bear upon the present discussion: (a) Cost. UNIX is distributed for "academic and educational purposes" to educational institutions by the Western Electric Company for only a nominal fee, and may be implemented effectively on hardware configurations costing less than $50,000. (b) Reliability and Maintenance. Since no support of any kind is provided by Western Electric, each installation is potentially on its own for software maintenance. UNIX would not have prospered if it were not almost completely error-free and easy to use. There are few disappointments and no unpleasant surprises. (c) Conciseness. The PDP-11 architecture places a strong limitation on the size of the resident operating system nucleus. As Ritchie and Thompson (1974) observe, "the size constraint has encouraged not only economy but a certain elegance of design". The nucleus provides support services and basic management of processes, files and other resources. Many important system functions are carried out by utility programs. Perhaps the most important of these is the command language interpreter, known as the "shell". (Modification of this program could alter, even drastically, the interface between the system and the user.) (d) Source Code. UNIX is written almost entirely in a high level language called "C" which is derived from BCPL and which is well matched to the PDP-11. It provides record and pointer types, has well developed control structures, and is consistent with modern ideas on structured Programming. (For the curious, the paper by Kernighan (1975) indirectly indicates the flavour of "C" and exemplifies one type of utility program contained in UNIX.) Something less than i0,000 lines of code are needed to describe the resident nucleus. pg 47 (e) Amenability. Changes can be made to UNIX with little difficulty. A new system can be instituted by recompiling one or more files (at an average of 20 to 30 seconds per file), relinking the file containing the nucleus (another 30 seconds or so), and rebooting using the new file. In simple cases the whole process need take no more than a few minutes. (f) Intrinsic Interest. UNIX contains a number of features which make it interesting in its own right: the run-time support for the general tree structured file system is particularly efficient; the use of a reserved set of file names smooths the concepts of device independence; multiple processes (three or four per user is average) are used in a way which in most systems is regarded as totally extravagant (this leads to considerable simplification of the system/user interface); and the interactive intent of the system has resulted in an unusually rich set of text editing and formatting programs. (g) Limitations. There are few limitations which are of concern to us. The PDP-11 architecture limits program size, and this for example frustrated an initial attempt to transfer Pascal P onto the 11/40. Perhaps the greatest weakness of UNIX as it is presently distributed (and this is not fundamental!) is in the area where other systems usually claim to be strong: support for "bread and butter" items such as Fortran and Basic. (h) Documentation. The entire official UNIX documentation, including tutorial material, runs to less than 500 pages. By some standards this is incredibly meagre, but it does mean that student can carry his own copy in his brief case. Features of the documentation include: - an unconventional arrangement of material (unsettling at first, but really very convenient); - a terse, enigmatic style, with much information conveyed by innuendo; - a permuted KWIC index. Most importantly perhaps UNIX encourages the programmer to document his work. There is a very full set of programs for editing and formatting text. The extent to which this has been developed can be gauged from the paper by Kernighan and Cherry (1975). ============== -- 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 douglas.mcilroy at dartmouth.edu Wed Sep 7 01:07:19 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Tue, 6 Sep 2022 11:07:19 -0400 Subject: [TUHS] Has this been discussed on-list? How Unix changed Software. Message-ID: > (Research) Unix ... 'shipped' with zero known bugs. It wasn't a Utopia. Right from the start man pages reported BUGS, though many were infelicities, not implementation errors. Dennis once ran a demo of a ubiquitous bug: buffer overflow. He fed a 2000-character line on stdin to every program in /bin. Many crashed. Nobody was surprised; and nobody was moved to fix the offenders. The misdesign principle that "no real-life input looks like that" fell into disrepute, but the bad stuff lived on. Some years down the road a paper appeared (in CACM?) that repeated Dennis's exercise. > An emergent property is "Good Security” Actually security (or at least securability) was a conscious theme from the start to which Ken, Bob Morris, and Fred Grampp gave serious attention. Networking brought insecurity, especially to Berkeley Unix. But research was not immune; remote execution via uucp caused much angst, but not enough to kill it. In regards to the basic question. To oversimplify: Theme 1. Unix facilities encouraged what Brian recognized and proselytized as software tools. Theme 2. OS portability was new and extraordinarily final. Subsequent OS's were all portable and were all Unix. Doug From marc.donner at gmail.com Wed Sep 7 02:09:56 2022 From: marc.donner at gmail.com (Marc Donner) Date: Tue, 6 Sep 2022 12:09:56 -0400 Subject: [TUHS] Has this been discussed on-list? How Unix changed Software. In-Reply-To: <453CCF20-3A01-4655-A956-149EDC08FA36@canb.auug.org.au> References: <453CCF20-3A01-4655-A956-149EDC08FA36@canb.auug.org.au> Message-ID: Having spent many formative years at IBM Research throwing (metaphorical) bombs at mainframe systems and infiltrating the place with BSD, I have thought about this question on and off. I would like to augment your comments with a couple of extra observations: UNIX was built for a particular set of users - document writers and programmers Before UNIX the systems were industrial in design and scope. Sort of like MVS was a locomotive - designed to be used for hauling heavy freight (acres of data entry clerks answering 800 numbers and entering transactions). UNIX was more like cars and trucks - designed for use by knowledge workers. When I was a grad student I hung out with some remarkable programmers. We all observed that learning to program was impossible without a body of code to read, study, and learn from. The best places to learn programming in the 70s and 80s were places like MIT, Berkeley, Bell Labs, and IBM Research ... places with an established culture of sharing code internally and large repositories of code to read. By the mid-1980s the Microsoft folks established the notion that software was economically valuable. People stopped giving away source code (IBM's change in strategy was called OCO - "Object Code Only") and it totally shocked the software developer community by destroying the jobs for programmers at user sites. Combine that with the mid-1980s recession and the first layoffs that programmers had ever seen and we saw the first horrified realization that the social contract between programmers and employers did not actually exist. We, the programmer community, woke up and committed ourselves as much as ever we could to non-proprietary languages and tools, putting our shoulders to the OSS movement and hence to UNIX and the layer of tools built on top of it. Of course it helped to have some brilliant engineers like Ken, Dennis, Doug, Rob, Michael, Stu (and and and) and brilliant writers like Brian so that the thing (UNIX) had intellectual integrity and scope. It took UNIX twenty to thirty years, but the economic logic of our approach put an end to efforts to totally dominate the tech world. ===== nygeek.net mindthegapdialogs.com/home On Mon, Sep 5, 2022 at 7:49 PM steve jenkin wrote: > I’ve been looking at this question for a time and thought it could’ve > appeared on the TUHS list - but don’t have an idea of the search terms to > use on the list. > > Perhaps someone suggest some to me. > > As a starting point, below is what John Lions wrote on a similar topic in > 1978. Conspicuously, “Security” is missing, though “Reliability & > Maintenance” would encompass the idea. > > With hindsight, I’d suggest (Research) Unix took a very strong stance on > “Technical Debt” - it was small, clean & efficient, even elegant. And > ‘shipped' with zero known bugs. > > It didn’t just bring the Unix kernel to many architectures, the same tools > were applied to create what we now call “Open Source” in User land: > > - Multi-platform / portable > - the very act of porting software to diverse architectures > uncovered new classes of bugs and implicit assumptions. Big- & > Little-endian were irrelevant or unknown Before Unix. > - full source > - compatibility layers via > - written in common, well-known, well-supported languages [ solving the > maintenance & update problem ] > - standard, portable “toolchains” > - shell, make, compiler, library tools for system linker, > documentation & doc reading tools > - distribution systems including test builds, issue / fault > reporting & tracking > > An emergent property is "Good Security”, both by Design and by (mostly) > error-free implementations. > > In the Epoch Before Unix (which started when exactly?), there was a lot of > Shared Software, but very little that could be mechanically ported to > another architecture. > Tools like QED and ROFF were reimplemented on multiple platforms, not > ‘ported’ in current lingo. > There are still large, complex FORTRAN libraries shared as source. > > There’s an important distinction between “Open” and “Free” : cost & > availability. > > We’ve gone on to have broadband near universally available with easy to > use Internet collaboration tools - e.g. “git”, “mercurial” and “Subversion” > just as CVS’s. > > The Unix-created Open Source concept broke Vendor Lock-in & erased most > “Silos”. > The BSD TCP/IP stack, and Berkeley sockets library, were sponsored by > DARPA, and made freely available to vendors as source code. > Similarly, important tools for SMTP and DNS were freely available as > Source Code, both speeding the implementation of Internet services and > providing “out of the box” protocol / function compatibility. > > The best tools, or even just adequate, became only a download & install > away for all coding shops, showing up a lot of poor code developed by > in-house “experts” and radically trimming many project schedules. > > While the Unix “Software Tools” approach - mediated by the STDOUT / STDIN > interface, not API’s - was new & radical, and for many classes of problems, > provided a definitive solution, > I’d not include it in a list of “Open Source” features. > > It assumes a “command line” and process pipelines, which aren’t relevant > to very large post-Unix program classes: Graphical Apps and Web / Internet > services. > > regards > steve jenkin > > ============== > > Lions, J., "An operating system case study" ACM SIGOPS Operating Systems > Review, July 1978, ACM SIGOPS Oper. Syst. Rev. 12(3): 46-53 (1978) > > > 2. Some Comments on UNIX > ------------------------ > > There is no space here to describe the technical features of UNIX in > detail (see Ritchie and Thompson, 1974 ; also Kernighan and Plauger, 1976), > nor to document its performance characteristics, which we have found to be > very satisfactory. > > The following general comments do bear upon the present discussion: > > (a) Cost. > UNIX is distributed for "academic and educational purposes" to > educational institutions by the Western Electric Company for only a nominal > fee, > and may be implemented effectively on hardware configurations costing > less than $50,000. > > (b) Reliability and Maintenance. > Since no support of any kind is provided by Western Electric, > each installation is potentially on its own for software > maintenance. > UNIX would not have prospered if it were not almost completely > error-free and easy to use. > There are few disappointments and no unpleasant surprises. > > (c) Conciseness. > The PDP-11 architecture places a strong limitation on the size of the > resident operating system nucleus. > As Ritchie and Thompson (1974) observe, > "the size constraint has encouraged not only economy but a certain > elegance of design". > The nucleus provides support services and basic management of > processes, files and other resources. > Many important system functions are carried out by utility programs. > Perhaps the most important of these is the command language > interpreter, known as the "shell". > (Modification of this program could alter, even drastically, the > interface between the system and the user.) > > (d) Source Code. > UNIX is written almost entirely in a high level language called "C" > which is derived from BCPL and which is well matched to the PDP-11. > It provides record and pointer types, > has well developed control structures, > and is consistent with modern ideas on structured Programming. > (For the curious, the paper by Kernighan (1975) indirectly indicates > the flavour of "C" > and exemplifies one type of utility program contained in UNIX.) > Something less than i0,000 lines of code are needed to describe the > resident nucleus. > > pg 47 > > (e) Amenability. > Changes can be made to UNIX with little difficulty. > A new system can be instituted by recompiling one or more files (at an > average of 20 to 30 seconds per file), > relinking the file containing the nucleus (another 30 seconds or so), > and rebooting using the new file. > In simple cases the whole process need take no more than a few minutes. > > (f) Intrinsic Interest. > UNIX contains a number of features which make it interesting in its own > right: > the run-time support for the general tree structured file system > is particularly efficient; > the use of a reserved set of file names smooths the concepts of > device independence; > multiple processes (three or four per user is average) are used in > a way which in most systems is regarded as totally extravagant > (this leads to considerable simplification of the system/user > interface); > and the interactive intent of the system has resulted in an > unusually rich set of text editing and formatting programs. > > (g) Limitations. > There are few limitations which are of concern to us. > The PDP-11 architecture limits program size, and this for example > frustrated an initial attempt to transfer Pascal P onto the 11/40. > Perhaps the greatest weakness of UNIX as it is presently distributed > (and this is not fundamental!) > is in the area where other systems usually claim to be strong: > support for "bread and butter" items such as Fortran and Basic. > > (h) Documentation. > The entire official UNIX documentation, including tutorial material, > runs to less than 500 pages. > By some standards this is incredibly meagre, > but it does mean that student can carry his own copy in his brief > case. > > Features of the documentation include: > - an unconventional arrangement of material (unsettling at first, > but really very convenient); > - a terse, enigmatic style, with much information conveyed by > innuendo; > - a permuted KWIC index. > > Most importantly perhaps UNIX encourages the programmer to document his > work. > There is a very full set of programs for editing and formatting text. > The extent to which this has been developed can be gauged from the > paper by Kernighan and Cherry (1975). > > ============== > > -- > 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 lm at mcvoy.com Wed Sep 7 03:13:25 2022 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 6 Sep 2022 10:13:25 -0700 Subject: [TUHS] Has this been discussed on-list? How Unix changed Software. In-Reply-To: References: Message-ID: <20220906171325.GU31856@mcvoy.com> On Tue, Sep 06, 2022 at 11:07:19AM -0400, Douglas McIlroy wrote: > > (Research) Unix ... 'shipped' with zero known bugs. > > It wasn't a Utopia. Right from the start man pages reported BUGS, > though many were infelicities, not implementation errors. > > Dennis once ran a demo of a ubiquitous bug: buffer overflow. He fed a > 2000-character line on stdin to every program in /bin. Many crashed. > Nobody was surprised; and nobody was moved to fix the offenders. The > misdesign principle that "no real-life input looks like that" fell > into disrepute, but the bad stuff lived on. Some years down the road a > paper appeared (in CACM?) that repeated Dennis's exercise. Maybe this one? B.P. Miller, L. Fredriksen, and B. So, "An Empirical Study of the Reliability of UNIX Utilities", Communications of the ACM 33, 12 (December 1990). http://www.paradyn.org/papers/fuzz.pdf From douglas.mcilroy at dartmouth.edu Wed Sep 7 05:04:14 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Tue, 6 Sep 2022 15:04:14 -0400 Subject: [TUHS] Has this been discussed on-list? How Unix changed Software. Message-ID: >> a paper appeared (in CACM?) that repeated Dennis's exercise. > Maybe this one? > B.P. Miller, L. Fredriksen, and B. So, "An Empirical Study of the Reliability > of UNIX Utilities", Communications of the ACM 33, 12 (December 1990). > http://www.paradyn.org/papers/fuzz.pdf Probably. I had forgotten that the later effort was considerably more elaborate than Dennis's. It created multiple random inputs that might stumble on other things besides buffer overflow. I see a Unix parable in the remarkable efficacy of Dennis's single-shot test. Doug From sjenkin at canb.auug.org.au Wed Sep 7 11:40:04 2022 From: sjenkin at canb.auug.org.au (steve jenkin) Date: Wed, 7 Sep 2022 11:40:04 +1000 Subject: [TUHS] Has this been discussed on-list? How Unix changed Software. In-Reply-To: References: Message-ID: Doug, Larry et al, Thanks very much for the history - unaware of those stories/ facts. I’ve scanned the 1989 Miller et al paper, will read properly soon. The legacy of that paper is the extensive automatic testing now commonplace in large Open Software projects. I wasn't clear in what I wrote. Have been immersed in early papers of teaching the kernel at UNSW :( Reminds on this list precise terms matter: that “Unix” / UNIX (tm) and "the kernel" (+ version) are very different. I meant the V5 / V6 kernel was ‘known defect free', hadn’t thought of Userland / utilities & libraries :( From what I’ve read: distribution tapes, pre-USG, were created from the current copy of ’the system’ - not sure which machine that was, presumably one controlled by Ken. Is that a reasonable statement, the kernel, pre-USG, had zero (known) Technical Debt when shipped? I’ve read that Ken wrote the kernel with an eye to it being a coding exemplar. Deliberately wrote consistent, high quality code. Is that another mis-interpretation of mine? regards steve j > On 7 Sep 2022, at 01:07, Douglas McIlroy wrote: > >> (Research) Unix ... 'shipped' with zero known bugs. > > It wasn't a Utopia. Right from the start man pages reported BUGS, > though many were infelicities, not implementation errors. -- 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 tuhs at tuhs.org Wed Sep 7 12:33:20 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 07 Sep 2022 02:33:20 +0000 Subject: [TUHS] Has this been discussed on-list? How Unix changed Software. In-Reply-To: References: Message-ID: > I’ve read that Ken wrote the kernel with an eye to it being a coding exemplar. > Deliberately wrote consistent, high quality code. >From UNIX Implementation: What is or is not implemented in the kernel represents both a great responsibility and a great power. It is a soap-box platform on "the way things should be done." - Ken Thompson, 1977 This paper can be found in the BSTJ Vol. 57, No. 6 as well as various "Documents for UNIX" compilations such as the Version 7 manual Volume 2. - Matt G. From sjenkin at canb.auug.org.au Wed Sep 7 14:00:22 2022 From: sjenkin at canb.auug.org.au (steve jenkin) Date: Wed, 7 Sep 2022 14:00:22 +1000 Subject: [TUHS] Has this been discussed on-list? How Unix changed Software. In-Reply-To: References: <453CCF20-3A01-4655-A956-149EDC08FA36@canb.auug.org.au> Message-ID: Marc, the first I.T. Recession in Australia occurred in 1991. It was the first economic recession where corporates couldn’t easily save money by “automating” - all the low-hanging fruit - like Inventory, Payroll & Accounting - had been computerised, at least by companies that’d survive. Thanks for mentioning the IBM OCO - I’d left mainframe by then. Your insight about the ’social contract’ ring true - never heard that before. Since that first recession, the regard managers have for I.T. / Computing staff - embodied in wages & conditions - has declined markedly outside business where software & systems are their business. The hype and over-expenditure on Y2K, then the Dot Crash, resulted in a 5 year I.T. recession in Australia - and a very jaded attitude towards I.T. and their budgets within the Corporates I know. The deskilling and mediocre work of programmers and support staff alike doesn’t seem to improve whole-of-enterprise productivity. Your summation of the Professional response to the dissolution of the ’social contract’ is very insightful. Explains the rapid rise and proliferation of OSS in the 1990’s. stevej > On 7 Sep 2022, at 02:09, Marc Donner wrote: > > By the mid-1980s the Microsoft folks established the notion that software was economically valuable. People stopped giving away source code (IBM's change in strategy was called OCO - "Object Code Only") and it totally shocked the software developer community by destroying the jobs for programmers at user sites. Combine that with the mid-1980s recession and the first layoffs that programmers had ever seen and we saw the first horrified realization that the social contract between programmers and employers did not actually exist. > > We, the programmer community, woke up and committed ourselves as much as ever we could to non-proprietary languages and tools, putting our shoulders to the OSS movement and hence to UNIX and the layer of tools built on top of 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 sjenkin at canb.auug.org.au Wed Sep 7 14:08:40 2022 From: sjenkin at canb.auug.org.au (Steve Jenkin) Date: Wed, 7 Sep 2022 14:08:40 +1000 Subject: [TUHS] Has this been discussed on-list? How Unix changed Software. In-Reply-To: References: Message-ID: <45DEAA40-5F9E-4847-81DD-280AC5A241D1@canb.auug.org.au> thanks! Had read this comment & it didn’t stick :( pg 1931 (splits over to next page) UNIX Implementation > On 7 Sep 2022, at 12:33, segaloco wrote: > > What is or is not implemented in the kernel represents both a great responsibility and a great power. It is a soap-box platform on "the way things should be done." > > - Ken Thompson, 1977 > > This paper can be found in the BSTJ Vol. 57, No. 6 as well as various "Documents for UNIX" compilations such as the Version 7 manual Volume 2. > > - 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 From sjenkin at canb.auug.org.au Wed Sep 7 15:15:45 2022 From: sjenkin at canb.auug.org.au (steve jenkin) Date: Wed, 7 Sep 2022 15:15:45 +1000 Subject: [TUHS] Has this been discussed on-list? How Unix changed Software. In-Reply-To: References: <453CCF20-3A01-4655-A956-149EDC08FA36@canb.auug.org.au> Message-ID: <58D7FE83-15EF-40E8-9DEB-4F6B5E45134E@canb.auug.org.au> > On 7 Sep 2022, at 02:09, Marc Donner wrote: > > Having spent many formative years at IBM Research throwing (metaphorical) bombs at mainframe systems and infiltrating the place with BSD, I have thought about this question on and off. > > I would like to augment your comments with a couple of extra observations: > > UNIX was built for a particular set of users - document writers and programmers > > Before UNIX the systems were industrial in design and scope. Sort of like MVS was a locomotive - designed to be used for hauling heavy freight (acres of data entry clerks answering 800 numbers and entering transactions). UNIX was more like cars and trucks - designed for use by knowledge workers. > > When I was a grad student I hung out with some remarkable programmers. We all observed that learning to program was impossible without a body of code to read, study, and learn from. The best places to learn programming in the 70s and 80s were places like MIT, Berkeley, Bell Labs, and IBM Research ... places with an established culture of sharing code internally and large repositories of code to read. > > By the mid-1980s the Microsoft folks established the notion that software was economically valuable. People stopped giving away source code (IBM's change in strategy was called OCO - "Object Code Only") and it totally shocked the software developer community by destroying the jobs for programmers at user sites. Combine that with the mid-1980s recession and the first layoffs that programmers had ever seen and we saw the first horrified realization that the social contract between programmers and employers did not actually exist. > > We, the programmer community, woke up and committed ourselves as much as ever we could to non-proprietary languages and tools, putting our shoulders to the OSS movement and hence to UNIX and the layer of tools built on top of it. > > Of course it helped to have some brilliant engineers like Ken, Dennis, Doug, Rob, Michael, Stu (and and and) and brilliant writers like Brian so that the thing (UNIX) had intellectual integrity and scope. > > It took UNIX twenty to thirty years, but the economic logic of our approach put an end to efforts to totally dominate the tech world. > ===== > nygeek.net > mindthegapdialogs.com/home Marc, Good observations. Thank you. I’ve never heard anyone mention that “reading large codebases” was the best way to learn programming. Absolutely my experience as well. If Professional Programmers aren’t doing “Programming in the Large” to provide critical services for others, then what work are they doing? In its first 10 years (1974-84), the future of Unix was uncertain. The formation of SUN in 1982 and other Unix-only vendors made Unix a commercial alternative, complete with support and a help number. At UNSW, there was a significant political battle over Unix. The manager of CSU (central Computing Services Unit) resigned over Unix. His 35 staff later supported Unix across the Uni. If he’d won the battle, it’s very likely all Unix at UNSW would’ve been expunged, stopping the networking work with Sydney University, shutting down the Unix kernel course & dramatically slowing the spread of Unix in Australia. Robert Elz at Melbourne Uni was later an important contributor to IP protocols and DNS. In the 1984 BSTJ issue on Unix, there’s no mention of SUN (1982) & SUNOS, but they do note “100,000 licenses” had been shipped, up from the 300 internal & ~600 total licenses mentioned in the 1978 BSTJ. While still not “cannot fail” status, Unix’s future was becoming more certain. Today, there are 2-4 billion active smartphone and tablets - almost all of which are Unix variants - Android and iOS. [ I’m sure other ‘platforms’ exist, but haven’t followed the market closely ] There’s an estimated 200M-250M “Personal Computers” in active use - 10% of all active devices. Even if all run Microsoft and not Chromebooks, MS-Windows is now a minor player. I’ve no idea how big the fleet of servers powering “The Cloud” in Datacentres is, but inferring from power consumption, it’s measured in millions. Only MS-Azure provide Windows instances and then it runs on top of a hypervisor, not bare metal. Is MS Hyper-V derived from a Unix variant? If not, is certainly influenced by VMware & Xen which were. To a first approximation, 90%+ of ‘computers' now run a Unix variant. [ disregarding the larger fleet of embedded devices, especially in cars ] As you say, UNIX & its variants broke the monopoly / lock-in of software by hardware vendors. The timing of Unix and it displacing hardware enforced “Software Silos" wasn’t accidental. [ A notable beneficiary of breaking Silos is Oracle - their early promise was database “portability”. ] It falls directly out of “Moore’s Law” and “Bell's Law of Computer Classes”. The PDP-11 ‘regressed’ to 16-bits compared to the IBM 360’s 32-bits: Bell’s Law in action - a new, much cheaper, lower performance “class” appearing each decade. In 1977, UNSW acquired a PDP-11/70 for teaching that was 1/10th the price of the IBM 360/50 that’d been purchased in 1966. [11/70 was in service in April 1978 - hardware delays] This 11/70 provided at least the same raw performance as the 360/50, but had ~50 2400baud terminals attached, not cards + printer. It was much more effective for learning/ teaching and provided much higher “useful throughput” than the IBM batch system. Certainly with VDU’s, much less paper was wasted :) DEC and others first leveraged the cheaper, faster silicon transistors to build bipolar discrete-part machines: e.g. the PDP-7 co-opted for “Space Travel” by Ken in 1969. DTL became TTL, digital IC’s grew larger, cheaper, faster - with “Mini computer” manufacturers rolling out new models at ever better price-points, more rapidly than ’traditional’ mainframe vendors. Minicomputers adopted “chipsets” to implement the CPU, leading in a few years to single-chip “Microprocessors”, often with co-processors for expensive operations, like floating point. The invention of RISC led to a whole new class of mini-computers with single-chip CPU's and a new class of system: the Graphical Workstation [ SUN & SGI ] - not quite Bell’s lowest performance class, one with significant new non-CPU capabilities. Without UNIX, there couldn’t have been a RISC revolution, because there’d have been no quality software for vendors to pick up: kernel, tools, Graphical UI and 3rd party Software on these platforms. The “Dot Boom” that ended in 2000 was only possible because of high-performance UNIX servers for web, storage & database. e-Bay started with Oracle on SUN servers. A solid, dependable system design. Google didn’t invent Internet Search, but they did come up with the Internet-scale Data Centre, creating highly available systems using low-cost, “less” reliabile commodity hardware. Is this a new Bell’s Law Class? it’s more a system architecture and operational arrangement, implemented almost alone in software. Amazon leveraged their expertise and design of Internet-scale DataCentres into a massive “Cloud” business - not bundled into its own products, but ‘rentable’ by customers by the hour. Netflix, when it changed from mailing DVD’s to streaming, based its business on renting Amazon servers, storage & bandwidth. We now have cheaper again computing services available, with zero Capital outlay and scalable to unprecedented sizes. It follows Bells’ Law, while extending it. In 2007 when Apple redefined the Smartphone - using ARM (Acorn RISC Machine) and a variant of Unix - they created a new class of computing device. The device was designed to “Just Work” - near zero admin, self-configuring and a highly reliable O/S, UI & Apps. Critically, Apple never tried to maximise the “utilisation” of the CPU & its resources - they put in fast CPU’s & aggressively managed power consumption to extend battery life. The Mainframe era economic model was inverted with the desktop computer - minimise wasted User time, not Computer time. The Smartphone took this “people first” approach to a new level. For me, Apple’s most important invention - on top of “Just Works” platform - was the App Store. It builds on “The Cloud” and Internet services, providing an almost direct Software Vendor to Client channel, using a secure & verified distribution system with embedded payments. Modern smartphone/ tablet system design, based around “Sandboxes” and a stringent control layer, seems to contain “malevolent” Apps well enough (no security is perfect, but “Good Enough” seems attainable). Without the App Store and Sandboxed Apps, we couldn’t have 2B-4B smartphones. We know from the MS-Windows PC & Server ecosystem [ and PHP/ Wordpress ] that "Bad Actors” will organise and actively exploit system vulnerabilities, making large fleets of exploitable devices unusable either because resources are co-opted and the device is unresponsive, or it’s compromised and can’t be trusted. Ironically, Moore’s Law couldn’t have proceeded as long and as quickly as it has since 1965 without the availability of Software to turn raw Silicon + Watts into functional, useful systems. Intel now owes a lot more business to Unix and its variants than to MS-Windows. It’s not unreasonable IMHO to say that Unix and its variants “Changed the World” and are now are the most prevalent O/S on the planet. ======= Sorry for the long piece - I know that TUHS is not the forum for these observations not confined to Early Unix. I’d have moved this to COFF, but I’ve not been able to get onto that list so far. regards steve -- 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 brian at zick.io Wed Sep 7 22:53:27 2022 From: brian at zick.io (Brian Zick) Date: Wed, 07 Sep 2022 07:53:27 -0500 Subject: [TUHS] STDIN/OUT vs APIs [was: How Unix changed Software] In-Reply-To: <453CCF20-3A01-4655-A956-149EDC08FA36@canb.auug.org.au> References: <453CCF20-3A01-4655-A956-149EDC08FA36@canb.auug.org.au> Message-ID: <1d79de35-daeb-4a4f-aed3-954f8df3a135@www.fastmail.com> On Mon, Sep 5, 2022, at 6:48 PM, steve jenkin wrote: > While the Unix “Software Tools” approach - mediated by the STDOUT / > STDIN interface, not API’s - was new & radical, and for many classes of > problems, provided a definitive solution, > I’d not include it in a list of “Open Source” features. I am very curious to hear more about the implications and practical benefits of this from folks that have thoroughly explored it. In my experience I’ve mainly used APIs, and I’m having trouble imagining the other approach other than for text-processing. B From steffen at sdaoden.eu Wed Sep 7 23:08:18 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 07 Sep 2022 15:08:18 +0200 Subject: [TUHS] Has this been discussed on-list? How Unix changed Software. In-Reply-To: References: Message-ID: <20220907130818.j22p1%steffen@sdaoden.eu> steve jenkin wrote in : |Doug, Larry et al, | |Thanks very much for the history - unaware of those stories/ facts. |I’ve scanned the 1989 Miller et al paper, will read properly soon. |The legacy of that paper is the extensive automatic testing now commonpl\ |ace in large Open Software projects. The "overly misused automatic testing" in my opinion. I have seen commit hooks etc which start test builds and test runs for any change, whatever it may be. (Like adding a period in a manual, so it cannot have beeen a Google clang one, heh.) Like going to the fantastic Coverity.com for which' advertising i do not even get money (stupid left wing..). And then there are thirty years and more in between. And isn't it ISO 9001 who requires extensive testing?(??) You also have extensive testing (i hope) for nuclear and airplanes and what. Question is: why is wc(1) not implemented to use three distinct logical code paths, and then choose the result which is delivered by the majority of them? There are plenty of different algorithms for wc(1), i personally am still stunned by the variant that i think Ken Thompson implemented (!?), and that can still be found in plan9port of Russ Cox (and more), as well as the 9front successor of Plan9 as such. I would never have thought this, but i would never have thought Aho-Corasick for fgrep either. And then i think you have to see that by then relatively few people were working on the absolute base level with quite restricted possibilities in power. And word was received that they simply reported bugs they encountered during their daily work, so that "when Dennis came in the evening he would find them, and fix it overnight". More or less. They had a job to do, and they wrote the tools to do that. This was science, exploration, desire, and, hm, military needs, i would say. So whereas i think what you said is totally right, i also think it is not. I also would not explain it with business, as bugs are costly. I think it is simply natural continuation of a thing, which gets more and more sophisticated and masterly the longer it is done. Now whereas one might (good) testing is also that, easy re-verification of a status quo helps even the masterly experienced. Having said _that_, Plan9 did not have any tests i think... But go(1) has quite a lot, and shares many heads. --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 cowan at ccil.org Wed Sep 7 23:19:22 2022 From: cowan at ccil.org (John Cowan) Date: Wed, 7 Sep 2022 09:19:22 -0400 Subject: [TUHS] STDIN/OUT vs APIs [was: How Unix changed Software] In-Reply-To: <1d79de35-daeb-4a4f-aed3-954f8df3a135@www.fastmail.com> References: <453CCF20-3A01-4655-A956-149EDC08FA36@canb.auug.org.au> <1d79de35-daeb-4a4f-aed3-954f8df3a135@www.fastmail.com> Message-ID: On Wed, Sep 7, 2022 at 8:54 AM Brian Zick wrote: > I am very curious to hear more about the implications and practical > benefits of this from folks that have thoroughly explored it. In my > experience I’ve mainly used APIs, and I’m having trouble imagining the > other approach other than for text-processing. > See for an explanation of Flow-Based Programming, a realization of the same pipelining idea, but extended to arbitrary directed graphs with multiple input and output ports. It was developed in complete ignorance of Unix pipelines except by bare and misleading report, and in entirely distinct application domains, yet with exact convergence. "It steam-engines when it comes steam-engine time." -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Wed Sep 7 23:20:48 2022 From: crossd at gmail.com (Dan Cross) Date: Wed, 7 Sep 2022 09:20:48 -0400 Subject: [TUHS] Has this been discussed on-list? How Unix changed Software. In-Reply-To: <58D7FE83-15EF-40E8-9DEB-4F6B5E45134E@canb.auug.org.au> References: <453CCF20-3A01-4655-A956-149EDC08FA36@canb.auug.org.au> <58D7FE83-15EF-40E8-9DEB-4F6B5E45134E@canb.auug.org.au> Message-ID: On Wed, Sep 7, 2022 at 1:16 AM steve jenkin wrote: > There’s an estimated 200M-250M “Personal Computers” in active use - 10% of all active devices. Even if all run Microsoft and not Chromebooks, MS-Windows is now a minor player. This is true, but in some sense has always been true, in that the number of embedded devices using microcontrollers and so forth has always dwarfed the number of desktop PC-class computers in the world (or, rather, has always done so for since the late 70s or so, I'd imagine). However, to call Windows a minor player is to ignore the importance of the applications that run on those desktop machines (and laptops, etc). The PC might be on the decline in absolute market terms, but it seems obvious that for specialist applications we're going to need something resembling it for the foreseeable future. > I’ve no idea how big the fleet of servers powering “The Cloud” in Datacentres is, but inferring from power consumption, it’s measured in millions. Aggregated across all the major players, I'd put the number at tens of millions, possibly in excess of 100 million at the high end of the estimate range. > Only MS-Azure provide Windows instances and then it runs on top of a hypervisor, not bare metal. Is MS Hyper-V derived from a Unix variant? If not, is certainly influenced by VMware & Xen which were. First, a factual correction: at least Google's cloud and I'm fairly certain AWS can run Windows, not just Azure. Second, I have it directly from folks who worked on Hyper-V that it is neither based on Unix/Linux, nor strongly influenced by either VMWare or Xen. It was an entirely in-house project at MSFT that probably includes more DNA strands from Windows than Unix et al. Some of the stories about clashes with Cutler to change the Windows startup sequence to accommodate Hyper-V are interesting (short version: Cutler, in typical fashion, didn't want to and early versions of Hyper-V basically booted under windows, then "took over" the running machine so that Windows resumed, but suddenly in a VM where it had not been before). > To a first approximation, 90%+ of ‘computers' now run a Unix variant. [ disregarding the larger fleet of embedded devices, especially in cars ] > As you say, UNIX & its variants broke the monopoly / lock-in of software by hardware vendors. The above notwithstanding, I absolutely believe these numbers. Unix and its derivatives (most notably Linux) have become the de-facto platform for modern computation, as you conclude. - Dan C. From usotsuki at buric.co Wed Sep 7 23:52:24 2022 From: usotsuki at buric.co (Steve Nickolas) Date: Wed, 7 Sep 2022 09:52:24 -0400 (EDT) Subject: [TUHS] Has this been discussed on-list? How Unix changed Software. In-Reply-To: References: <453CCF20-3A01-4655-A956-149EDC08FA36@canb.auug.org.au> <58D7FE83-15EF-40E8-9DEB-4F6B5E45134E@canb.auug.org.au> Message-ID: On Wed, 7 Sep 2022, Dan Cross wrote: > Second, I have it directly from folks who worked on Hyper-V that it is > neither based on Unix/Linux, nor strongly influenced by either VMWare > or Xen. It was an entirely in-house project at MSFT that probably > includes more DNA strands from Windows than Unix et al. Some of the > stories about clashes with Cutler to change the Windows startup > sequence to accommodate Hyper-V are interesting (short version: > Cutler, in typical fashion, didn't want to and early versions of > Hyper-V basically booted under windows, then "took over" the running > machine so that Windows resumed, but suddenly in a VM where it had not > been before). That sounds like what Compaq's CEMM (a.k.a. EMM386) did with MS-DOS. -uso. From lm at mcvoy.com Thu Sep 8 00:56:31 2022 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 7 Sep 2022 07:56:31 -0700 Subject: [TUHS] Has this been discussed on-list? How Unix changed Software. In-Reply-To: References: Message-ID: <20220907145631.GN31856@mcvoy.com> I've never heard the claim that the kernel was "defect free", as a fisherman that sort of feels like saying "I always get fish" which is a sure fire way to make sure you get none on the next trip :-) I do get "Deliberately wrote consistent, high quality code." as that is a choice. If you look through the code my team wrote, I think you'll find the same. But everyone has to be committed to that level of coding or it goes to shit pretty quickly. Super pleasant when the whole team wants the code to be like that. I'd be willing to say that you could find a bug very quickly in our code but to claim that it is bug free is a bridge too far for me. On Wed, Sep 07, 2022 at 11:40:04AM +1000, steve jenkin wrote: > Doug, Larry et al, > > Thanks very much for the history - unaware of those stories/ facts. > I???ve scanned the 1989 Miller et al paper, will read properly soon. > The legacy of that paper is the extensive automatic testing now commonplace in large Open Software projects. > > I wasn't clear in what I wrote. Have been immersed in early papers of teaching the kernel at UNSW :( > Reminds on this list precise terms matter: that ???Unix??? / UNIX (tm) and "the kernel" (+ version) are very different. > > I meant the V5 / V6 kernel was ???known defect free', hadn???t thought of Userland / utilities & libraries :( > From what I???ve read: distribution tapes, pre-USG, were created from the current copy of ???the system??? - not sure which machine that was, presumably one controlled by Ken. > > Is that a reasonable statement, the kernel, pre-USG, had zero (known) Technical Debt when shipped? > > I???ve read that Ken wrote the kernel with an eye to it being a coding exemplar. > Deliberately wrote consistent, high quality code. > > Is that another mis-interpretation of mine? > > regards > steve j > > > On 7 Sep 2022, at 01:07, Douglas McIlroy wrote: > > > >> (Research) Unix ... 'shipped' with zero known bugs. > > > > It wasn't a Utopia. Right from the start man pages reported BUGS, > > though many were infelicities, not implementation errors. > > -- > 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 -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From cowan at ccil.org Thu Sep 8 00:58:56 2022 From: cowan at ccil.org (John Cowan) Date: Wed, 7 Sep 2022 10:58:56 -0400 Subject: [TUHS] Has this been discussed on-list? How Unix changed Software. In-Reply-To: References: <453CCF20-3A01-4655-A956-149EDC08FA36@canb.auug.org.au> Message-ID: On Wed, Sep 7, 2022 at 12:01 AM steve jenkin wrote: > Since that first recession, the regard managers have for I.T. / Computing > staff - embodied in wages & conditions - has declined markedly outside > business where software & systems are their business. > Once it became clear that we are not miracle workers, we were degraded to the status of (interchangeable) clerks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at celo.io Thu Sep 8 01:39:06 2022 From: joe at celo.io (Joe) Date: Wed, 7 Sep 2022 17:39:06 +0200 Subject: [TUHS] STDIN/OUT vs APIs [was: How Unix changed Software] In-Reply-To: References: <453CCF20-3A01-4655-A956-149EDC08FA36@canb.auug.org.au> <1d79de35-daeb-4a4f-aed3-954f8df3a135@www.fastmail.com> Message-ID: <79ddeb2d-e9ac-da73-7bda-675c3bb867c9@celo.io> On 9/7/22 15:19, John Cowan wrote: > On Wed, Sep 7, 2022 at 8:54 AM Brian Zick wrote: > > >> I am very curious to hear more about the implications and practical >> benefits of this from folks that have thoroughly explored it. In my >> experience I’ve mainly used APIs, and I’m having trouble imagining the >> other approach other than for text-processing. >> > > See for an explanation of Flow-Based > Programming, a realization of the same pipelining idea, but extended to > arbitrary directed graphs with multiple input and output ports. It was > developed in complete ignorance of Unix pipelines except by bare and > misleading report, and in entirely distinct application domains, yet with > exact convergence. "It steam-engines when it comes steam-engine time." > That page reminds me of CMS/Pipelines, a beautiful Rexx-like language: https://en.wikipedia.org/wiki/CMS_Pipelines From cowan at ccil.org Thu Sep 8 01:43:32 2022 From: cowan at ccil.org (John Cowan) Date: Wed, 7 Sep 2022 11:43:32 -0400 Subject: [TUHS] STDIN/OUT vs APIs [was: How Unix changed Software] In-Reply-To: <79ddeb2d-e9ac-da73-7bda-675c3bb867c9@celo.io> References: <453CCF20-3A01-4655-A956-149EDC08FA36@canb.auug.org.au> <1d79de35-daeb-4a4f-aed3-954f8df3a135@www.fastmail.com> <79ddeb2d-e9ac-da73-7bda-675c3bb867c9@celo.io> Message-ID: On Wed, Sep 7, 2022 at 11:39 AM Joe wrote: > That page reminds me of CMS/Pipelines, a beautiful Rexx-like language: > > https://en.wikipedia.org/wiki/CMS_Pipelines In that case, however, it was a matter of what anthros call "stimulus diffusion". The CMS people read the Unix BSTJ issue, thought "We should do that", and wrote it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sauer at technologists.com Thu Sep 8 02:01:19 2022 From: sauer at technologists.com (Charles H Sauer (he/him)) Date: Wed, 7 Sep 2022 11:01:19 -0500 Subject: [TUHS] STDIN/OUT vs APIs [was: How Unix changed Software] In-Reply-To: References: <453CCF20-3A01-4655-A956-149EDC08FA36@canb.auug.org.au> <1d79de35-daeb-4a4f-aed3-954f8df3a135@www.fastmail.com> <79ddeb2d-e9ac-da73-7bda-675c3bb867c9@celo.io> Message-ID: <44c26e68-76aa-4043-cd1e-503d50d6d58b@technologists.com> On 9/7/2022 10:43 AM, John Cowan wrote: > > > On Wed, Sep 7, 2022 at 11:39 AM Joe > > wrote: > > That page reminds me of CMS/Pipelines, a beautiful Rexx-like language: > > https://en.wikipedia.org/wiki/CMS_Pipelines > > > > In that case, however, it was a matter of what anthros call "stimulus > diffusion".  The CMS people read the Unix BSTJ issue, thought "We should > do that", and wrote it. That last sentence is literally true, based on page 63 of http://www.leeandmelindavarian.com/Melinda/25paper.pdf, and I can easily imagine Peter Capek doing as cited on that page. However, the general acceptance by "CMS people" was belated/begrudging, as CMS Pipelines weren't available outside IBM to any customers until 1986 and not available in U.S until 1989. -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/Twitter: CharlesHSauer From paul.winalski at gmail.com Thu Sep 8 03:13:31 2022 From: paul.winalski at gmail.com (Paul Winalski) Date: Wed, 7 Sep 2022 13:13:31 -0400 Subject: [TUHS] Has this been discussed on-list? How Unix changed Software. In-Reply-To: References: <453CCF20-3A01-4655-A956-149EDC08FA36@canb.auug.org.au> Message-ID: > On 7 Sep 2022, at 02:09, Marc Donner wrote: > > By the mid-1980s the Microsoft folks established the notion that software > was economically valuable. People stopped giving away source code (IBM's > change in strategy was called OCO - "Object Code Only") and it totally > shocked the software developer community by destroying the jobs for > programmers at user sites. Combine that with the mid-1980s recession and > the first layoffs that programmers had ever seen and we saw the first > horrified realization that the social contract between programmers and > employers did not actually exist. Microsoft was a late-comer to the software-as-a-product game. Back in the 1970s IBM was forced into a consent decree to unbundle its software--OS, SW development tools, utilities--from its hardware. Originally IBM only leased its computers and the OSes, software development toolchain, and various products such as the sort utility were provided for free, along with the source code for them. IBM was later forced to sell its machines as well as lease them, and the unbundling of software was the last step in the progression. There were already third party software vendors in the IBM mainframe world in the 1970s. If you were at all serious about sorting you bought SyncSort instead of using the freebie IBM sort utility. In the research world there were pay-for statistical packages such as SPSS and BMDP. And third-party database products. IBM decided to make lemons out of lemonade and discovered to their delight that they now could make money by selling the software that they used to just give away. Naturally if you're making customers pay for software you don't want the liability risk of having them tinker with it, so you don't provide the sources anymore. Software has a radically different business model from hardware--there's a big initial development cost but manufacturing comes essentially for free. Management types used to the hardware-centric world initially had a lot of trouble seeing software as a revenue source. DEC never quite got the hang of it, and even today Intel doesn't understand software. By the time Microsoft came along selling software for profit was well-established. I remember when I saw PC software for sale for the first time being astonished that people would actually pay for copies of simple game programs such as "Hunt the Wumpus" or "Adventure". -Paul W. From sjenkin at canb.auug.org.au Thu Sep 8 07:27:26 2022 From: sjenkin at canb.auug.org.au (Steve Jenkin) Date: Thu, 8 Sep 2022 07:27:26 +1000 Subject: [TUHS] Has this been discussed on-list? How Unix changed Software. In-Reply-To: <20220907145631.GN31856@mcvoy.com> References: <20220907145631.GN31856@mcvoy.com> Message-ID: <8DDF5A51-AABF-41AF-993C-4D087903BDC9@canb.auug.org.au> Would your folk ship code with a list of outstanding bug reports? I don’t think Ken & Dennis did that. I know that UNSW put together a “all known faults fixed” tape, which says there were defects uncovered in use, but not known when shipped. > On 8 Sep 2022, at 00:56, Larry McVoy wrote: > > I'd be willing to say that you could find a bug very quickly in our > code but to claim that it is bug free is a bridge too far for me. -- 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 lm at mcvoy.com Thu Sep 8 08:36:05 2022 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 7 Sep 2022 15:36:05 -0700 Subject: [TUHS] Has this been discussed on-list? How Unix changed Software. In-Reply-To: <8DDF5A51-AABF-41AF-993C-4D087903BDC9@canb.auug.org.au> References: <20220907145631.GN31856@mcvoy.com> <8DDF5A51-AABF-41AF-993C-4D087903BDC9@canb.auug.org.au> Message-ID: <20220907223605.GS31856@mcvoy.com> On Thu, Sep 08, 2022 at 07:27:26AM +1000, Steve Jenkin wrote: > Would your folk ship code with a list of outstanding bug reports? Absolutely, there were always open bug reports that couldn't be reproduced, or were a side effect of misusing the product, etc. We didn't ship with stuff that we thought should be fixed and could be fixed. > I don???t think Ken & Dennis did that. I wasn't there but it's hard to imagine anything as complex as an operating system went out the door with everything fixed. I dunno how the kernel was done back in the day, but for us, doing a release was a 6 month process. If you reset that process each time a new bug comes in, you'll never ship. At some point, you have to balance the set of features and bugfixes you can fix against whatever new thing that shows up. It's definitely an art to get that right. From paul.winalski at gmail.com Fri Sep 9 00:12:36 2022 From: paul.winalski at gmail.com (Paul Winalski) Date: Thu, 8 Sep 2022 10:12:36 -0400 Subject: [TUHS] Has this been discussed on-list? How Unix changed Software. In-Reply-To: References: <453CCF20-3A01-4655-A956-149EDC08FA36@canb.auug.org.au> Message-ID: On 9/7/22, Paul Winalski wrote: > > IBM decided to make lemons out of lemonade and discovered to their > delight that they now could make money by selling the software that > they used to just give away. Naturally if you're making customers pay > for software you don't want the liability risk of having them tinker > with it, so you don't provide the sources anymore. I of course meant "make lemonade out of lemons". -Paul W. [wiping face off egg :-) ] From tuhs at ducky.net Fri Sep 9 00:36:11 2022 From: tuhs at ducky.net (Mike Haertel) Date: Thu, 08 Sep 2022 07:36:11 -0700 Subject: [TUHS] "dmd-pgmg" Toolchest package (SysV 5620+630 version of Sam) Message-ID: <202209081436.288EaBva001500@ducky.net> Does anybody out there have a copy of the old AT&T Toolchest "dmd-pgmg" package? This apparently includes the a SysV port of Sam for 5620/630 as well as other programs for the AT&T windowing terminals. From paul.winalski at gmail.com Fri Sep 9 00:42:47 2022 From: paul.winalski at gmail.com (Paul Winalski) Date: Thu, 8 Sep 2022 10:42:47 -0400 Subject: [TUHS] Has this been discussed on-list? How Unix changed Software. In-Reply-To: <8DDF5A51-AABF-41AF-993C-4D087903BDC9@canb.auug.org.au> References: <20220907145631.GN31856@mcvoy.com> <8DDF5A51-AABF-41AF-993C-4D087903BDC9@canb.auug.org.au> Message-ID: On 9/7/22, Steve Jenkin wrote: > Would your folk ship code with a list of outstanding bug reports? ** Everyone ** ships code with known bugs. If you insist on getting things perfect your code never gets out the door. At some point you have to decide that what you have is good enough to be released. The trick is to decide what constitutes "good enough". Some of it depends on your target application and user base. What's good enough for Hunt the Wumpus may well not be good enough for process control software for a pacemaker or nuclear reactor. And if you're producing software for commercial sale, marketing and business factors enter the mix as well. > I don’t think Ken & Dennis did that. OTOH I'm certain that they did. -Paul W. From lm at mcvoy.com Fri Sep 9 01:02:28 2022 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 8 Sep 2022 08:02:28 -0700 Subject: [TUHS] Has this been discussed on-list? How Unix changed Software. In-Reply-To: References: <20220907145631.GN31856@mcvoy.com> <8DDF5A51-AABF-41AF-993C-4D087903BDC9@canb.auug.org.au> Message-ID: <20220908150228.GI11929@mcvoy.com> On Thu, Sep 08, 2022 at 10:42:47AM -0400, Paul Winalski wrote: > On 9/7/22, Steve Jenkin wrote: > > Would your folk ship code with a list of outstanding bug reports? > > ** Everyone ** ships code with known bugs. If you insist on getting > things perfect your code never gets out the door. At some point you > have to decide that what you have is good enough to be released. > > The trick is to decide what constitutes "good enough". Some of it > depends on your target application and user base. What's good enough > for Hunt the Wumpus may well not be good enough for process control > software for a pacemaker or nuclear reactor. And if you're producing > software for commercial sale, marketing and business factors enter the > mix as well. > > > I don???t think Ken & Dennis did that. > > OTOH I'm certain that they did. As I told Steve in private email, it's a balancing act and it is a bit of an art. On the one hand you have new features and a bunch of bugs that you fixed, on the other hand you have this new bug report. Knowing when the right call is to ship and when the right call is to stop the train, that's the art. I could make an attempt at writing down how you make that call but it would just be an attempt. Experience will tell you how to make that call. I can say, mostly I shipped. It has to be something pretty dramatic to start the process over when you know it is going to be a 6 month delay at minimum. From rminnich at gmail.com Fri Sep 9 01:04:07 2022 From: rminnich at gmail.com (ron minnich) Date: Thu, 8 Sep 2022 08:04:07 -0700 Subject: [TUHS] Has this been discussed on-list? How Unix changed Software. In-Reply-To: References: <20220907145631.GN31856@mcvoy.com> <8DDF5A51-AABF-41AF-993C-4D087903BDC9@canb.auug.org.au> Message-ID: I remember a comment someone at UDEL made when we'd been working with v6 for a few years, starting in 1976. "v6 is fast as hell but it has its bugs." It was a big deal, at least in 1976, to get through a week without a crash of some sort. That's why we had all those pre-fsck programs for looking for problems: icheck and ncheck existed for a reason. The -11 also had its corners, e.g. alignment traps to snag the unwary, and hardware that, in several cases, did not completely honor the unibus spec. If the hardware has limits, or corners, and your kernel crashes because of it, is it a bug that you did not accommodate the undocumented hardware design? Given that you can't really go at your machine with a soldering iron (well, not always; we all did some of that back then) it's arguably your bug. Unix code was great, far better than a lot of what was out there, certainly on the -11, but to say any of it shipped bug free certainly does not match my recollection. On Thu, Sep 8, 2022 at 7:43 AM Paul Winalski wrote: > On 9/7/22, Steve Jenkin wrote: > > Would your folk ship code with a list of outstanding bug reports? > > ** Everyone ** ships code with known bugs. If you insist on getting > things perfect your code never gets out the door. At some point you > have to decide that what you have is good enough to be released. > > The trick is to decide what constitutes "good enough". Some of it > depends on your target application and user base. What's good enough > for Hunt the Wumpus may well not be good enough for process control > software for a pacemaker or nuclear reactor. And if you're producing > software for commercial sale, marketing and business factors enter the > mix as well. > > > I don’t think Ken & Dennis did that. > > OTOH I'm certain that they did. > > -Paul W. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Fri Sep 9 01:52:38 2022 From: imp at bsdimp.com (Warner Losh) Date: Thu, 8 Sep 2022 09:52:38 -0600 Subject: [TUHS] Has this been discussed on-list? How Unix changed Software. In-Reply-To: References: <20220907145631.GN31856@mcvoy.com> <8DDF5A51-AABF-41AF-993C-4D087903BDC9@canb.auug.org.au> Message-ID: On Thu, Sep 8, 2022 at 9:05 AM ron minnich wrote: > I remember a comment someone at UDEL made when we'd been working with v6 > for a few years, starting in 1976. "v6 is fast as hell but it has its bugs." > > It was a big deal, at least in 1976, to get through a week without a crash > of some sort. That's why we had all those pre-fsck programs for looking for > problems: icheck and ncheck existed for a reason. > > The -11 also had its corners, e.g. alignment traps to snag the unwary, and > hardware that, in several cases, did not completely honor the unibus spec. > If the hardware has limits, or corners, and your kernel crashes because of > it, is it a bug that you did not accommodate the undocumented hardware > design? Given that you can't really go at your machine with a soldering > iron (well, not always; we all did some of that back then) it's arguably > your bug. > > Unix code was great, far better than a lot of what was out there, > certainly on the -11, but to say any of it shipped bug free certainly does > not match my recollection. > In addition, when Dennis would talk about Coherent and his evaluation of the source code, he said he used the known to him, but not widely known bugs in Unix to try to catch copying. If there was copying, those would be copied. If it was freshly implemented, there's a high likelihood that they wouldn't. His conclusion was that someone had access to a lot of knowledge about the Unix system given the fidelity of the implementation, but the lack of bugs and novel ways of doing it suggested independent implementation. Warner > > On Thu, Sep 8, 2022 at 7:43 AM Paul Winalski > wrote: > >> On 9/7/22, Steve Jenkin wrote: >> > Would your folk ship code with a list of outstanding bug reports? >> >> ** Everyone ** ships code with known bugs. If you insist on getting >> things perfect your code never gets out the door. At some point you >> have to decide that what you have is good enough to be released. >> >> The trick is to decide what constitutes "good enough". Some of it >> depends on your target application and user base. What's good enough >> for Hunt the Wumpus may well not be good enough for process control >> software for a pacemaker or nuclear reactor. And if you're producing >> software for commercial sale, marketing and business factors enter the >> mix as well. >> >> > I don’t think Ken & Dennis did that. >> >> OTOH I'm certain that they did. >> >> -Paul W. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Fri Sep 9 02:47:56 2022 From: paul.winalski at gmail.com (Paul Winalski) Date: Thu, 8 Sep 2022 12:47:56 -0400 Subject: [TUHS] Has this been discussed on-list? How Unix changed Software. In-Reply-To: References: <20220907145631.GN31856@mcvoy.com> <8DDF5A51-AABF-41AF-993C-4D087903BDC9@canb.auug.org.au> Message-ID: On 9/8/22, Warner Losh wrote: > > In addition, when Dennis would talk about Coherent and his evaluation of > the source code, he said he used the known to him, but not widely known > bugs in Unix to try to catch copying. If there was copying, those would be > copied. If it was freshly implemented, there's a high likelihood that they > wouldn't. His conclusion was that someone had access to a lot of knowledge > about the Unix system given the fidelity of the implementation, but the > lack of bugs and novel ways of doing it suggested independent > implementation. The software equivalent of a common technique used by mapmakers to detect copying. You sprinkle a few fake locations or other deliberate errors into your map. If these show up in a competitor's map you know they were copied. -Paul W. From tuhs at tuhs.org Fri Sep 9 02:50:43 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 08 Sep 2022 16:50:43 +0000 Subject: [TUHS] Has this been discussed on-list? How Unix changed Software. In-Reply-To: References: <20220907145631.GN31856@mcvoy.com> <8DDF5A51-AABF-41AF-993C-4D087903BDC9@canb.auug.org.au> Message-ID: > In addition, when Dennis would talk about Coherent and his evaluation of the source code, he said he used the known to him, but not widely known bugs in Unix to try to catch copying. If there was copying, those would be copied. If it was freshly implemented, there's a high likelihood that they wouldn't. His conclusion was that someone had access to a lot of knowledge about the Unix system given the fidelity of the implementation, but the lack of bugs and novel ways of doing it suggested independent implementation. Both Coherent and 4.4BSD have stuck out to me as examples of not-quite-so-clean-room implementations that did well enough (more than enough for BSD) and didn't die a fiery death in litigation (as much as USL tried...). What I find interesting is that in this day and age, it seems there is almost a requirement for true "clean-room" implementation if something is going to be replicated, which I understand to mean the team developing the new implementation can't be the same team that performed a detailed analysis of the product being reimplemented, but the latter team can produce a white paper/writeup/memorandum describing the results of their analysis and the development team can then use that so long as it doesn't contain any implementation details. I've always wondered how cleanly that sort of thing can actually be proven and enforced, and I've always thought back to the Coherent situation as an almost model example. Where proving copying outright can be difficult, knowing one's own product well enough to know the bugs that are incredibly obscure but also reliably consistent is a great way to peg a faithful recreation vs. a flat out copy job. That said, my assumption with complete UNIX re-implementations is that folks at least had access to the manuals, perhaps had used UNIX before in some capacity. I would assume the current definition of a clean-room implementation only requires that the developers/implementors don't have access to the code of the parent product (source or reverse engineered), but could read manuals, study behavior in-situ, and use that level of "reverse engineering" to extract the design from the implementation, so not knowing the gritty details, Coherent could be a true clean-room. BSD is a different beast, as they were literally replacing the AT&T source code before their eyes, so there isn't much argument that can be made for 4.4BSD being a "clean-room" implementation of UNIX. Simply for compatibility and upgrade-ability of existing systems, they had to be incredibly accurate to the original design. Given that, that's one of the more surprising things to me about 4.4BSD prevailing in the lawsuit, because while Berkeley could easily prove that they had replaced most of AT&T's code, there's still the fact that their team did have complete and unfettered access to Bell UNIX code at least circa 32V. Not sure if the licensing allowed for source-code cross-talk between USG/USL UNIX source and Berkeley, but I remember reading somewhere that CSRG students and faculty avoided commercial UNIX like the plague, going so far as to not even look at the literature to see what changes occurred since 32V. Anywho just some thoughts, I find the realm of reverse engineering and re-implementation fascinating, and am always interested in this sort of discussion. - Matt G. P.S. Don't want to derail the thread with this, unless it's deemed worthy addition, but feel free to email privately. Does anyone know if there was a "formal" PDP-11 and/or VAX disassembler produced by Bell? I know there was one floating around the "user maintained" utilities at some point, I recall seeing a note in a manual saying something to the effect "Rumor has it there is a PDP-11 disassembler" but I'm curious if such tools were ever provided in any sort of official capacity. I've been doing some research on what RE tools people had on hand at the time, think "objdump" from GNU binutils. From jon at fourwinds.com Fri Sep 9 02:51:06 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Thu, 08 Sep 2022 09:51:06 -0700 Subject: [TUHS] Does anybody know the etymology of the term "word" as in collection of bits? Message-ID: <202209081651.288Gp6ag355864@darkstar.fourwinds.com> One of those questions for which there is no search engine incantation. Jon From andrew at humeweb.com Fri Sep 9 02:56:09 2022 From: andrew at humeweb.com (Andrew Hume) Date: Thu, 8 Sep 2022 09:56:09 -0700 Subject: [TUHS] Does anybody know the etymology of the term "word" as in collection of bits? In-Reply-To: <202209081651.288Gp6ag355864@darkstar.fourwinds.com> References: <202209081651.288Gp6ag355864@darkstar.fourwinds.com> Message-ID: i can’t find my copy of “pixel”, but i would guess he might mention that. > On Sep 8, 2022, at 9:51 AM, Jon Steinhart wrote: > > One of those questions for which there is no search engine incantation. > > Jon From halbert at halwitz.org Fri Sep 9 03:28:13 2022 From: halbert at halwitz.org (Dan Halbert) Date: Thu, 8 Sep 2022 13:28:13 -0400 Subject: [TUHS] Does anybody know the etymology of the term "word" as in collection of bits? In-Reply-To: <202209081651.288Gp6ag355864@darkstar.fourwinds.com> References: <202209081651.288Gp6ag355864@darkstar.fourwinds.com> Message-ID: <61096d8f-ce80-2ba5-ffdf-8ad5f802ab02@halwitz.org> On 9/8/22 12:51, Jon Steinhart wrote: > One of those questions for which there is no search engine incantation. > > Jon The famous 1946 paper, "Preliminary discussion of the logical design of an electronic computing device",  by Arthur Burks,  Herman H. Goldstine, John von Neumann, contains this sentence. I have this paper in Computer Structures: Readings and Examples, by Bell and Newell, but it's also online in many forms ** * 4. The memory organ * 4.1. Ideally one would desire an indefinitely large memory capacity such that any particular aggregate of 40 binary digits, or /word /(cf. 2.3), would be immediately available-i.e. in a time which is somewhat or considerably shorter than the operation time of a fast electronic multiplier. I also looked in the Oxford English Dictionary for etymology. It has: *d.* /Computing/. A consecutive string of bits (now typically 16, 32, or 64, but formerly fewer) that can be transferred and stored as a unit./machine word/: see /machine word/ n. at machine n. Compounds 2 . 1946 H. H. Goldstine & J. Von Neumann in J. von Neumann /Coll. Wks./ (1963) V. 28   In ‘writing’ a word into the memory, it is similarly not only the time effectively consumed in ‘writing’ which matters, but also the time needed to ‘find’ the specified location in the memory. [plus newer citations] Dan H -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Fri Sep 9 03:58:16 2022 From: rminnich at gmail.com (ron minnich) Date: Thu, 8 Sep 2022 10:58:16 -0700 Subject: [TUHS] Has this been discussed on-list? How Unix changed Software. In-Reply-To: References: <20220907145631.GN31856@mcvoy.com> <8DDF5A51-AABF-41AF-993C-4D087903BDC9@canb.auug.org.au> Message-ID: re hardware, in several cases in the 60s, when old hardware was connected to new hardware to verify the new hardware's floating point, the new hardware had a difference -- and the bug was in the old hardware. Gordon Bell mentioned this in "Computer Engineering", IIRC; I am also told some model of 360 and 370 also found bugs in ... the 360. And let's not forget what in the supercomputing biz was called "Cray Floating Point": e.g. X * Y did not always equal Y * X. But the answer came back fast :-) On Thu, Sep 8, 2022 at 9:50 AM segaloco wrote: > > In addition, when Dennis would talk about Coherent and his evaluation of > the source code, he said he used the known to him, but not widely known > bugs in Unix to try to catch copying. If there was copying, those would be > copied. If it was freshly implemented, there's a high likelihood that they > wouldn't. His conclusion was that someone had access to a lot of knowledge > about the Unix system given the fidelity of the implementation, but the > lack of bugs and novel ways of doing it suggested independent > implementation. > > Both Coherent and 4.4BSD have stuck out to me as examples of > not-quite-so-clean-room implementations that did well enough (more than > enough for BSD) and didn't die a fiery death in litigation (as much as USL > tried...). What I find interesting is that in this day and age, it seems > there is almost a requirement for true "clean-room" implementation if > something is going to be replicated, which I understand to mean the team > developing the new implementation can't be the same team that performed a > detailed analysis of the product being reimplemented, but the latter team > can produce a white paper/writeup/memorandum describing the results of > their analysis and the development team can then use that so long as it > doesn't contain any implementation details. > > I've always wondered how cleanly that sort of thing can actually be proven > and enforced, and I've always thought back to the Coherent situation as an > almost model example. Where proving copying outright can be difficult, > knowing one's own product well enough to know the bugs that are incredibly > obscure but also reliably consistent is a great way to peg a faithful > recreation vs. a flat out copy job. That said, my assumption with complete > UNIX re-implementations is that folks at least had access to the manuals, > perhaps had used UNIX before in some capacity. I would assume the current > definition of a clean-room implementation only requires that the > developers/implementors don't have access to the code of the parent product > (source or reverse engineered), but could read manuals, study behavior > in-situ, and use that level of "reverse engineering" to extract the design > from the implementation, so not knowing the gritty details, Coherent could > be a true clean-room. > > BSD is a different beast, as they were literally replacing the AT&T source > code before their eyes, so there isn't much argument that can be made for > 4.4BSD being a "clean-room" implementation of UNIX. Simply for > compatibility and upgrade-ability of existing systems, they had to be > incredibly accurate to the original design. Given that, that's one of the > more surprising things to me about 4.4BSD prevailing in the lawsuit, > because while Berkeley could easily prove that they had replaced most of > AT&T's code, there's still the fact that their team did have complete and > unfettered access to Bell UNIX code at least circa 32V. Not sure if the > licensing allowed for source-code cross-talk between USG/USL UNIX source > and Berkeley, but I remember reading somewhere that CSRG students and > faculty avoided commercial UNIX like the plague, going so far as to not > even look at the literature to see what changes occurred since 32V. > > Anywho just some thoughts, I find the realm of reverse engineering and > re-implementation fascinating, and am always interested in this sort of > discussion. > > - Matt G. > > P.S. Don't want to derail the thread with this, unless it's deemed worthy > addition, but feel free to email privately. Does anyone know if there was > a "formal" PDP-11 and/or VAX disassembler produced by Bell? I know there > was one floating around the "user maintained" utilities at some point, I > recall seeing a note in a manual saying something to the effect "Rumor has > it there is a PDP-11 disassembler" but I'm curious if such tools were ever > provided in any sort of official capacity. I've been doing some research > on what RE tools people had on hand at the time, think "objdump" from GNU > binutils. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Fri Sep 9 04:01:49 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 8 Sep 2022 14:01:49 -0400 (EDT) Subject: [TUHS] Does anybody know the etymology of the term "word" as in collection of bits Message-ID: <20220908180149.CB4DC18C077@mercury.lcs.mit.edu> > On Sep 8, 2022, at 9:51 AM, Jon Steinhart wrote: > One of those questions for which there is no search engine incantation. Whatever it is, it's really old. I found it used, not quite in the modern sense, in "Hi-Speed Computing Devices", by ERA, 1950. It was used, in the modern sense, in "Planning a Computer System", Buchholz,1962. Noel From jnc at mercury.lcs.mit.edu Fri Sep 9 04:20:51 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 8 Sep 2022 14:20:51 -0400 (EDT) Subject: [TUHS] Does anybody know the etymology of the term "word" as in collection of bits? Message-ID: <20220908182051.502B118C077@mercury.lcs.mit.edu> > It was used, in the modern sense, in "Planning a Computer System", > Buchholz,1962. Also in the IBM "650 Manual of Operation", June, 1955. (Before I was born! :-) Noel From jpl.jpl at gmail.com Fri Sep 9 05:22:27 2022 From: jpl.jpl at gmail.com (John P. Linderman) Date: Thu, 8 Sep 2022 15:22:27 -0400 Subject: [TUHS] Does anybody know the etymology of the term "word" as in collection of bits In-Reply-To: <20220908180149.CB4DC18C077@mercury.lcs.mit.edu> References: <20220908180149.CB4DC18C077@mercury.lcs.mit.edu> Message-ID: In Brailsford's youtube series in Computerphile (something I came across through BWK's interview with Brailsford), Episode 86 is about "Where Did Bytes Come From?". He claims that if you wanted to do decimal arithmetic on a binary machine, you'd want to have 10 digits of accuracy to capture the 10 digit log tables that were then popular. 10 digits is around 33 to 36 bits, so words ended up that size (or half that size), 36 or 18 bits. (Brailsford's lectures are fabulous, by the way, likely to appeal to TUHS types.) I like that explanation better than the story I heard that the IBM 709 series had 36 bit words because Arthur Samuel, then at IBM, needed 32 bits to identify the playable squares on a checkerboard, plus some bits for color and kinged (if that's the proper term for getting across the board and gaining the ability to move toward either side). Samuel was famous for writing a checker playing program that played champion-quality checkers. On Thu, Sep 8, 2022 at 2:02 PM Noel Chiappa wrote: > > On Sep 8, 2022, at 9:51 AM, Jon Steinhart wrote: > > > One of those questions for which there is no search engine > incantation. > > Whatever it is, it's really old. I found it used, not quite in the modern > sense, in "Hi-Speed Computing Devices", by ERA, 1950. It was used, in the > modern sense, in "Planning a Computer System", Buchholz,1962. > > Noel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcapp at anteil.com Fri Sep 9 05:28:01 2022 From: jcapp at anteil.com (Jim Capp) Date: Thu, 8 Sep 2022 15:28:01 -0400 (EDT) Subject: [TUHS] Does anybody know the etymology of the term "word" as in collection of bits? In-Reply-To: <20220908182051.502B118C077@mercury.lcs.mit.edu> Message-ID: <833155.3451.1662665281061.JavaMail.root@zimbraanteil> See "The Preparation of Programs for an Electronic Digital Computer", by Maurice V. Wilkes, David J. Wheeler, and Stanley Gill, copyright 1951, pp. 5 section 1-4: "The store is divided into a number of registers or storage locations; the content of a storage location is a sequence of 0's and 1's, and may represent an order or a number. The term word is used for the content of a storage location if it is desired to refer to it without specifying whether it represents a number or an order." Jim From: "Noel Chiappa" To: tuhs at tuhs.org Cc: jnc at mercury.lcs.mit.edu Sent: Thursday, September 8, 2022 2:20:51 PM Subject: [TUHS] Re: Does anybody know the etymology of the term "word" as in collection of bits? > It was used, in the modern sense, in "Planning a Computer System", > Buchholz,1962. Also in the IBM "650 Manual of Operation", June, 1955. (Before I was born! :-) Noel -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri Sep 9 06:53:04 2022 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Thu, 8 Sep 2022 14:53:04 -0600 Subject: [TUHS] "... interesting old-timey UNIXes ..." (cross post from geeks) Message-ID: <5567f0bf-2bad-78c3-adb1-7db9cecef1e8@spamtrap.tnetconsulting.net> Hi, The following comment was made on the geeks mailing list and I figured it was worth cross posting to the TUHS mailing list. -- I'm BCCing the original poster so that they are aware of the cross post and in case they want to say more. --8<-- In related news that might entertain and inform, there are some interesting old-timey UNIXes out there that I've come across recently though: XV6: https://pdos.csail.mit.edu/6.828/2012/xv6.html OMU: http://www.pix.net/mirrored/discordia.org.uk/~steve/omu.html V7/x86: https://www.nordier.com/ RUnix and Singlix: https://www.singlix.com/runix/ -->8-- I don't know if any of it should be included in the TUHS archives or not. -- I figure discussing it on TUHS is the best way to find out. P.S. Re-sending to the correct TUHS email address. Somehow I had something on file reflecting the old server. :-/ -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4017 bytes Desc: S/MIME Cryptographic Signature URL: From jnc at mercury.lcs.mit.edu Fri Sep 9 07:16:35 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 8 Sep 2022 17:16:35 -0400 (EDT) Subject: [TUHS] Does anybody know the etymology of the term "word" as in collection of bits? Message-ID: <20220908211635.4533B18C077@mercury.lcs.mit.edu> > From: Jim Capp > See "The Preparation of Programs for an Electronic Digital Computer", > by Maurice V. Wilkes, David J. Wheeler, and Stanley Gill Blast! I looked in the index in my copy (ex the Caltech CS Dept Library :-), but didn't find 'word' in the index! Looking a little further, Turing's ACE Report, from 1946, uses the term (section 4, pg. 25; "minor cycle, or word"). My copy, the one edited by Carpenter and Doran, has a note #1 by them, "Turing seems to be the first user of 'word' with this meaning." I have Brian's email, I can ask him how they came to that determination, if you'd like. There aren't many things older than that! I looked quickly through the "First Draft on the EDVAC", 1945 (re-printed in "From ENIAC to UNIVAC", by Stein), but did not see word there. It does use the term "minor cycle", though. Other places worth checking are the IBM/Harvard Mark I, the ENIAC and ... I guess therer's not much else! Oh, there was a relay machine at Bell, too. The Atanasoff-Berry computer? > From: "John P. Linderman" > He claims that if you wanted to do decimal arithmetic on a binary > machine, you'd want to have 10 digits of accuracy to capture the 10 > digit log tables that were then popular. The EDVAC draft talks about needing 8 decimal digits (Appendix A, pg.190); apparently von Neumann knew that that's how many digits one needed for reasonable accuracy in differential equations. That is 27 "binary digits" (apparently 'bit' hadn't been coined yet). Noel From halbert at halwitz.org Fri Sep 9 07:24:07 2022 From: halbert at halwitz.org (Dan Halbert) Date: Thu, 8 Sep 2022 17:24:07 -0400 Subject: [TUHS] Does anybody know the etymology of the term "word" as in collection of bits? In-Reply-To: <20220908211635.4533B18C077@mercury.lcs.mit.edu> References: <20220908211635.4533B18C077@mercury.lcs.mit.edu> Message-ID: <229adc5b-5c4a-3ab8-78e4-8d907709873f@halwitz.org> I did send this already, from 1946, did you see it? The famous 1946 paper, "Preliminary discussion of the logical design of an electronic computing device",  by Arthur Burks,  Herman H. Goldstine, John von Neumann, contains this sentence. I have this paper in Computer Structures: Readings and Examples, by Bell and Newell, but it's also online in many forms 4. The memory organ 4.1. Ideally one would desire an indefinitely large memory capacity such that any particular aggregate of 40 binary digits, or -word- (cf. 2.3), would be immediately available-i.e. in a time which is somewhat or considerably shorter than the operation time of a fast electronic multiplier. [word is in italics] On 9/8/22 17:16, Noel Chiappa wrote: > > From: Jim Capp > > > See "The Preparation of Programs for an Electronic Digital Computer", > > by Maurice V. Wilkes, David J. Wheeler, and Stanley Gill > > Blast! I looked in the index in my copy (ex the Caltech CS Dept Library :-), > but didn't find 'word' in the index! > > Looking a little further, Turing's ACE Report, from 1946, uses the term > (section 4, pg. 25; "minor cycle, or word"). My copy, the one edited by > Carpenter and Doran, has a note #1 by them, "Turing seems to be the first > user of 'word' with this meaning." I have Brian's email, I can ask him how > they came to that determination, if you'd like. > > There aren't many things older than that! I looked quickly through the "First > Draft on the EDVAC", 1945 (re-printed in "From ENIAC to UNIVAC", by Stein), > but did not see word there. It does use the term "minor cycle", though. > > Other places worth checking are the IBM/Harvard Mark I, the ENIAC and ... > I guess therer's not much else! Oh, there was a relay machine at Bell, too. > The Atanasoff-Berry computer? > > > > From: "John P. Linderman" > > > He claims that if you wanted to do decimal arithmetic on a binary > > machine, you'd want to have 10 digits of accuracy to capture the 10 > > digit log tables that were then popular. > > The EDVAC draft talks about needing 8 decimal digits (Appendix A, pg.190); > apparently von Neumann knew that that's how many digits one needed for > reasonable accuracy in differential equations. That is 27 "binary digits" > (apparently 'bit' hadn't been coined yet). > > Noel -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Sep 9 07:50:37 2022 From: clemc at ccc.com (Clem Cole) Date: Thu, 8 Sep 2022 17:50:37 -0400 Subject: [TUHS] Re-implementations/Clean-Rooms et al. Message-ID: On Thu, Sep 8, 2022 at 12:51 PM segaloco via TUHS wrote: > Both Coherent and 4.4BSD have stuck out to me as examples of > not-quite-so-clean-room implementations that did well enough (more than > enough for BSD) and didn't die a fiery death in litigation (as much as USL > tried...). Be careful with that statement both parts of it are not wholly on target. In the first, AT&T chose not to litigate against Coherent fully. As was pointed out, Dennis and the team that examined the code base determined it was 'clean enough.' If I recall, his comment was something like "It was clear they had seen and had access to the AT&T IP at some point, most likely at University (IIRC many of the founders were ex-University Waterloo), but they did not find evidence of direct copying of files." BSDi/UCB *vs. *USL was a different kettle of fish altogether. As has been discussed here extensively (and needs not to be repeated), that suit was about *Trade Secrets and >>ideas<< that make up what we call UNIX.* The real interesting thing about that case is that had USL/AT&T won, the repercussions for the industry would have been way beyond just BSDi - *but all of the UNIX clones* and many of us on this list who had been "mentally contaminated" with AT&T's ideas (I still have my 'mental contamination' button somewhere in my archives). The good news is that the US courts had the good sense to realize that the moment the US Gov put the consent decree down in 1956 and required that AT&T make their IP available and then enabled AT&T had its people start to write about their work in the open literature (in UNIX's case the original CACM paper, but continuing with all the books, follow on papers, etc), plus being such wonderfully active participants in the research community at large, it could not be called a secret. > What I find interesting is that in this day and age, it seems there is > almost a requirement for true "clean-room" implementation if something is > going to be replicated, which I understand to mean the team developing the > new implementation can't be the same team that performed a detailed > analysis of the product being reimplemented, but the latter team can > produce a white paper/writeup/memorandum describing the results of their > analysis and the development team can then use that so long as it doesn't > contain any implementation details. > It's not "day and age" it's from the original case law -- the term was coined by the late Arthur Kahn, Esquire who was the lead attorney for Franklin Computers, Inc in the Franklin *vs.* Apple Case - which he originally won and ultimately lost on appeal [Good guy BTW, particularly for a non-technically trained person - he 'got it']. The concept is that one group is in a dirty room and the other in a clean room. Information is unidirectional. The dirty room can read published documentation, probe, and test the device/implementation using standard programming techniques. And then write a new document that describes the functionality of the device in question. Then hand it to the folks in the clean room who can reimplement a device to that new specification. The point of contention in the case is if *the original documentation for the device*, in this case, the Apple Assembler listing for Wos's Apple-II ROMs were protected by copy once they had been transformed from their printed form in Apple;'s red books into the binary and stored in the ROMS themselves. Franklin's 'dirty room' ultimately wrote a series of test programs that demonstrated each of the externally available locations and entries in the ROMs. This they documents and their new clean-room programmers wrote a new set of ROM that duplicated the functionality. IIRC the story is that Franklin ROMs were a few bytes smaller in the end. Compaq would later the same scheme for the IBM PC. > I would assume the current definition of a clean-room implementation only > requires that the developers/implementors don't have access to the code of > the parent product (source or reverse engineered), but could read manuals, > study behavior in-situ, and use that level of "reverse engineering" to > extract the design from the implementation, so not knowing the gritty > details, Coherent could be a true clean-room. > Be careful here. I used to work for a firm that did a lot of work for different vendors that would build some of these clean-room sub-systems (in fact for some of the folks -- at least one -- of the readers of this list). We were always careful for the clean-room people to be ones we were fairly sure had not seen that customers product previously. I was almost always on the 'dirty' team in many of those projects because I was so contaminated with the IP of so many of our customers' work. Because we worked for IBM, Sun, DEC, HP, DG, AT&T, *etc*. all at the same time had their IP in-house we had very strict rules about how things were handled. Even what sites and what sub-nets data could be on -- which system admins had the passwords. No one person had access to all of the passwords. We had a locked safe for each customer with secure things like passwords (really) and rooms with locks and videos, and access doors. It was really serious stuff. Frankly, I think part of why we got some of the "work for hires" tasks was because those firms trusted us to handle their IP properly. No way did we want to contaminate something accidentally. Some projects like our big TNC [Transparent Network Computing] system we were working on for all of IBM, DEC, HP, and Intel simultaneously -- 4 different teams. The architects could talk to each other, and we talked about common issues, but it was a different code. I know we implemented things a couple of times - although we got smarter. For instance, the original RPC marshaling was done for IBM with 'the awk script from hell' which later became an interface generator that all four teams used. > > BSD is a different beast, as they were literally replacing the AT&T source > code before their eyes, so there isn't much argument that can be made for > 4.4BSD being a "clean-room" implementation of UNIX. It was not a clean-room as Arthur defined it. It was rewritten over time, which replaced AT&T's implementation. Which is all that was ever claimed. > Given that, that's one of the more surprising things to me about 4.4BSD > prevailing in the lawsuit, because while Berkeley could easily prove that > they had replaced most of AT&T's code, there's still the fact that their > team did have complete and unfettered access to Bell UNIX code at least > circa 32V. I expect this is because you don't quite understand what happened. > but I remember reading somewhere that CSRG students and faculty avoided > commercial UNIX like the plague, Hmmm, I read it on the Internet -- it must be true ;-) CSRG had Ultrix/VAX, SunOS/3, and I believe HP-UX/PA sources. They shipped several DEC-developed drivers in 4.1A/4.1B/4.1C -- Sam, Bill Shanon, and I tested a couple of them on one of my machines in Cory Hall as DEC has donated one of the 3 CAD machines [UCBCAD - a.k.a. 'coke' ], and it was the only 'pure' DEC machine on campus - without any 3rd party HW in it. After I graduated, I suspect Sam continued the relationship with Tom Quarles, so 4.2BSD was likely tested on that system too. But I know the RH-based TAPES and DISKs were all straight from Shannon's SCCS Ultrix repo as he sent them to me to try before I gave them to Sam. > Does anyone know if there was a "formal" PDP-11 and/or VAX disassembler > produced by Bell? Most of the compiler kits have disassemblers, as do many debuggers -- what are you asking? > saying something to the effect "Rumor has it there is a PDP-11 > disassembler" but I'm curious if such tools were ever provided in any sort > of official capacity. > In the mid/late-70s (*i.e.* V6/V7 time frame) there are a couple of them -- where to start -- V7 has one inside of adb, and if I recall later versions of PCC2 has one. But if you look in the USENIX tapes you can find a couple of pretty well-adorned ones. There was one that IIRC was done by ??Cooper Union?? guys that spit out DEC MACRO-11 syntax for the Harvard assembler. That should be on the TUHS archives. Thinking about it, Phil Karn had one too that did some interesting label patch-up IIRC - which I think he brought with him to CMU from somewhere -- but I may be miss remembering that. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Fri Sep 9 08:16:39 2022 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 8 Sep 2022 15:16:39 -0700 Subject: [TUHS] Re-implementations/Clean-Rooms et al. In-Reply-To: References: Message-ID: <20220908221639.GR11929@mcvoy.com> On Thu, Sep 08, 2022 at 05:50:37PM -0400, Clem Cole wrote: > > BSD is a different beast, as they were literally replacing the AT&T source > > code before their eyes, so there isn't much argument that can be made for > > 4.4BSD being a "clean-room" implementation of UNIX. > > It was not a clean-room as Arthur defined it. It was rewritten over time, > which replaced AT&T's implementation. Which is all that was ever claimed. And it's a false claim. Go look at the Bell Labs bmap() and the BSD bmap(), the last time I looked they were bit for bit identical. I looked there because I split bmap() into bmap_read() and bmap_write() because the read path is trivial and the write path is quite a bit more difficult (this was all for the work srk imagined, and I did, to get rid of the rotational delays). So I was pretty familiar with that code path and as of about 20 years ago, well past 4.4BSD, bmap() was unchanged from either v7 or 32v. The weird thing is it isn't that hard to write something that would walk the code and find other examples. Nobody seemed to care. From imp at bsdimp.com Fri Sep 9 08:17:42 2022 From: imp at bsdimp.com (Warner Losh) Date: Thu, 8 Sep 2022 16:17:42 -0600 Subject: [TUHS] Re-implementations/Clean-Rooms et al. In-Reply-To: References: Message-ID: On Thu, Sep 8, 2022 at 3:52 PM Clem Cole wrote: > On Thu, Sep 8, 2022 at 12:51 PM segaloco via TUHS wrote: > >> Both Coherent and 4.4BSD have stuck out to me as examples of >> not-quite-so-clean-room implementations that did well enough (more than >> enough for BSD) and didn't die a fiery death in litigation (as much as USL >> tried...). > > BSDi/UCB *vs. *USL was a different kettle of fish altogether. As has > been discussed here extensively (and needs not to be repeated), that suit > was about *Trade Secrets and >>ideas<< that make up what we call UNIX.* > The real interesting thing about that case is that had USL/AT&T won, the > repercussions for the industry would have been way beyond just BSDi - *but > all of the UNIX clones* and many of us on this list who had been > "mentally contaminated" with AT&T's ideas (I still have my 'mental > contamination' button somewhere in my archives). > Yes. Indeed. It devolved to a copyright battle with the ultimate result being a preliminary ruling that 32V (and V6 and V7 likely) had no copyright protection because AT&T had distributed too many copies without the required (at the time) copyright notices... That preliminary ruling is what forced the settlement of the suit, and is the reason that 4.4BSD-lite had a bunch of files with AT&T copyrights on them with permission to redistribute liberally... These days, in open source cleanroom is rarely done except in extraordinary cases. It's easier to read the code and reimplement because copyright covers only the typing... Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Sep 9 08:19:52 2022 From: clemc at ccc.com (Clem Cole) Date: Thu, 8 Sep 2022 18:19:52 -0400 Subject: [TUHS] The USL Toolchest from the 80s and 90s Message-ID: Mike Haertel's quest for the 5620 tools got me thinking. Does anyone know of an archive of the USL Toolchest at large? It would be cool if someone had the whole thing on a single tape. But, I suspect many of us have pieces of it. I'm not sure I know all the pieces that made it up. But I would like to see the USDL section of Warren's Archive include a sub directory Toolchest with the collected parts - from Korn shell, the final version of Writer workbench, to DMD tools and the like. IIRC the final edition of PCC2 was released as part of it. thoughts? Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Fri Sep 9 08:26:17 2022 From: imp at bsdimp.com (Warner Losh) Date: Thu, 8 Sep 2022 16:26:17 -0600 Subject: [TUHS] Re-implementations/Clean-Rooms et al. In-Reply-To: <20220908221639.GR11929@mcvoy.com> References: <20220908221639.GR11929@mcvoy.com> Message-ID: On Thu, Sep 8, 2022 at 4:16 PM Larry McVoy wrote: > On Thu, Sep 08, 2022 at 05:50:37PM -0400, Clem Cole wrote: > > > BSD is a different beast, as they were literally replacing the AT&T > source > > > code before their eyes, so there isn't much argument that can be made > for > > > 4.4BSD being a "clean-room" implementation of UNIX. > > > > It was not a clean-room as Arthur defined it. It was rewritten over > time, > > which replaced AT&T's implementation. Which is all that was ever > claimed. > > And it's a false claim. Go look at the Bell Labs bmap() and the BSD > bmap(), the last time I looked they were bit for bit identical. > Yea, this was part of the de minimis copying that was acknowledged... It was mostly rewritten with most of AT&T's code gone. It's 110 lines of code, out of ~18,000 lines of kernel code. And the structure in 4.4BSD is somewhat different with balloc() being completely different than the rest of V7's subr.c. > I looked there because I split bmap() into bmap_read() and bmap_write() > because the read path is trivial and the write path is quite a bit more > difficult (this was all for the work srk imagined, and I did, to get > rid of the rotational delays). So I was pretty familiar with that > code path and as of about 20 years ago, well past 4.4BSD, bmap() was > unchanged from either v7 or 32v. > But it likely didn't matter, since 32v likely lost its copyright protection due to AT&T distributing too many copies without the required copyright markings. At least that was the preliminary ruling that caused the suit to be settled... AT&T didn't want it finalized, though the cat was somewhat out of the bag at this point... > The weird thing is it isn't that hard to write something that would > walk the code and find other examples. Nobody seemed to care. > Yea, most of the rest of the code around it was rewritten, but not that. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Fri Sep 9 08:28:33 2022 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 9 Sep 2022 08:28:33 +1000 (EST) Subject: [TUHS] Happy birthday, Unix timestamp! Message-ID: https://www.timeanddate.com/on-this-day/september/9 ``Unix time or Unix epoch, POSIX time or Unix timestamp, is a time system that measures the number of seconds since midnight UTC of January 1, 1970, not counting leap seconds. At 01:46:40 UTC on September 9, 2001, Unix time reached the billionth second timestamp.'' Hard to believe that it was that long ago... -- Dave From imp at bsdimp.com Fri Sep 9 08:28:10 2022 From: imp at bsdimp.com (Warner Losh) Date: Thu, 8 Sep 2022 16:28:10 -0600 Subject: [TUHS] Re-implementations/Clean-Rooms et al. In-Reply-To: References: <20220908221639.GR11929@mcvoy.com> Message-ID: On Thu, Sep 8, 2022 at 4:26 PM Warner Losh wrote: > > > On Thu, Sep 8, 2022 at 4:16 PM Larry McVoy wrote: > >> On Thu, Sep 08, 2022 at 05:50:37PM -0400, Clem Cole wrote: >> > > BSD is a different beast, as they were literally replacing the AT&T >> source >> > > code before their eyes, so there isn't much argument that can be made >> for >> > > 4.4BSD being a "clean-room" implementation of UNIX. >> > >> > It was not a clean-room as Arthur defined it. It was rewritten over >> time, >> > which replaced AT&T's implementation. Which is all that was ever >> claimed. >> >> And it's a false claim. Go look at the Bell Labs bmap() and the BSD >> bmap(), the last time I looked they were bit for bit identical. >> > > Yea, this was part of the de minimis copying that was acknowledged... > It was mostly rewritten with most of AT&T's code gone. It's 110 lines of > code, > out of ~18,000 lines of kernel code. And the structure in 4.4BSD is > somewhat > different with balloc() being completely different than the rest of V7's > subr.c. > I should have added it was one of the 23 files in 4.4lite that was acknowledged as having some AT&T code that AT&T agreed to release... > I looked there because I split bmap() into bmap_read() and bmap_write() >> because the read path is trivial and the write path is quite a bit more >> difficult (this was all for the work srk imagined, and I did, to get >> rid of the rotational delays). So I was pretty familiar with that >> code path and as of about 20 years ago, well past 4.4BSD, bmap() was >> unchanged from either v7 or 32v. >> > > But it likely didn't matter, since 32v likely lost its copyright > protection due > to AT&T distributing too many copies without the required copyright > markings. > At least that was the preliminary ruling that caused the suit to be > settled... > AT&T didn't want it finalized, though the cat was somewhat out of the bag > at this point... > > >> The weird thing is it isn't that hard to write something that would >> walk the code and find other examples. Nobody seemed to care. >> > > Yea, most of the rest of the code around it was rewritten, but not that. > > Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From usotsuki at buric.co Fri Sep 9 09:30:25 2022 From: usotsuki at buric.co (Steve Nickolas) Date: Thu, 8 Sep 2022 19:30:25 -0400 (EDT) Subject: [TUHS] Re-implementations/Clean-Rooms et al. In-Reply-To: References: <20220908221639.GR11929@mcvoy.com> Message-ID: On Thu, 8 Sep 2022, Warner Losh wrote: > But it likely didn't matter, since 32v likely lost its copyright > protection due to AT&T distributing too many copies without the required > copyright markings. At least that was the preliminary ruling that caused > the suit to be settled... AT&T didn't want it finalized, though the cat > was somewhat out of the bag at this point... It would be nice if that were an absolute rather than a probably, because then the status for 32V wouldn't be clouded. -uso. From clemc at ccc.com Fri Sep 9 09:34:13 2022 From: clemc at ccc.com (Clem Cole) Date: Thu, 8 Sep 2022 19:34:13 -0400 Subject: [TUHS] Re-implementations/Clean-Rooms et al. In-Reply-To: <20220908221639.GR11929@mcvoy.com> References: <20220908221639.GR11929@mcvoy.com> Message-ID: On Thu, Sep 8, 2022 at 6:16 PM Larry McVoy wrote: > > It was rewritten over time, > > which replaced AT&T's implementation. Which is all that was ever > claimed. > > And it's a false claim. > I believe you. But BSD's rewrite was good enough. The real key is the BSDi/UCB *vs.* USL/AT&T case was *not about the code (or copyrights).* That is the piece most hackers don't seem to understand. The case was about *trade secrets (or not) *and thus the *ideas*. BSDi/UCB released their system which clearly had started with code that had originated with AT&T and thus the *ideas* had to have originated there too. I think too many hackers get caught up in FOSS, GPL,* et al,* and miss the point. The real debt which we can never repay Doug, Ken, Dennis, and friends was their *ideas* and the way they broke down and solved problems. The code is a by-product, the existence proof that it was more than theory, but had a practical use. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Fri Sep 9 09:42:35 2022 From: imp at bsdimp.com (Warner Losh) Date: Thu, 8 Sep 2022 17:42:35 -0600 Subject: [TUHS] Re-implementations/Clean-Rooms et al. In-Reply-To: References: <20220908221639.GR11929@mcvoy.com> Message-ID: On Thu, Sep 8, 2022 at 5:29 PM Steve Nickolas wrote: > On Thu, 8 Sep 2022, Warner Losh wrote: > > > But it likely didn't matter, since 32v likely lost its copyright > > protection due to AT&T distributing too many copies without the required > > copyright markings. At least that was the preliminary ruling that caused > > the suit to be settled... AT&T didn't want it finalized, though the cat > > was somewhat out of the bag at this point... > > It would be nice if that were an absolute rather than a probably, because > then the status for 32V wouldn't be clouded. > It would be nice. At this late date, one wonders what would happen if it were litigated again... I suspect that nobody would bother given the small possible gain and the huge expense... But it would also reduce shareholder values to explicitly say there's no copyright here or to clarify that the ancient licenses are valid. So we're in this state where it's basically free and clear, treated like it's free and clear, but really isn't free and clear. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Fri Sep 9 09:48:31 2022 From: robpike at gmail.com (Rob Pike) Date: Fri, 9 Sep 2022 09:48:31 +1000 Subject: [TUHS] Happy birthday, Unix timestamp! In-Reply-To: References: Message-ID: There was a delightful conference in Copenhagen celebrating that event, and I was lucky enough to attend. The slides of my talk live here: http://herpolhode.com/rob/ugly.pdf I flew back the next day, September 10, 2011, and it was a beautiful clear night with a stunning view of the city. We sat in the last row of the plane, and had an unobstructed view of the trade towers as we landed near midnight. We went home, fell asleep, and were woken by a phone call about 9am. -rob On Fri, Sep 9, 2022 at 8:29 AM Dave Horsfall wrote: > https://www.timeanddate.com/on-this-day/september/9 > > ``Unix time or Unix epoch, POSIX time or Unix timestamp, is a time system > that measures the number of seconds since midnight UTC of January 1, > 1970, > not counting leap seconds. At 01:46:40 UTC on September 9, 2001, Unix > time > reached the billionth second timestamp.'' > > Hard to believe that it was that long ago... > > -- Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Fri Sep 9 10:00:16 2022 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Fri, 9 Sep 2022 10:00:16 +1000 Subject: [TUHS] Does anybody know the etymology of the term "word" as in collection of bits? In-Reply-To: <20220908211635.4533B18C077@mercury.lcs.mit.edu> <833155.3451.1662665281061.JavaMail.root@zimbraanteil> <61096d8f-ce80-2ba5-ffdf-8ad5f802ab02@halwitz.org> Message-ID: <20220909000016.GC94367@eureka.lemis.com> On Thursday, 8 September 2022 at 13:28:13 -0400, Dan Halbert wrote: > > I also looked in the Oxford English Dictionary for etymology. It has: > > *d.* /Computing/. A consecutive string of bits (now typically 16, > 32, or 64, but formerly fewer) that can be transferred and stored as > a unit./machine word/: see /machine word/ n. at machine n. Compounds > 2 . > > 1946 H. H. Goldstine & J. Von Neumann in J. von Neumann /Coll. Wks./ > (1963) V. 28   In ‘writing’ a word into the memory, it is similarly > not only the time effectively consumed in ‘writing’ which matters, > but also the time needed to ‘find’ the specified location in the memory. Since we're searching the OED, there are a couple of others. The /machine word/ mentioned above has: machine word n. Computing: a word of the length appropriate for a particular fixed word-length computer. 1954 Computers & Automation Dec. 16/1 Machine word, a unit of information of a standard number of characters, which a machine regularly handles in each register. This makes the meaning clearer, I think, though it doesn't seem to be a change in meaning. On Thursday, 8 September 2022 at 17:16:35 -0400, Noel Chiappa wrote: > > Looking a little further, Turing's ACE Report, from 1946, uses the > term (section 4, pg. 25; "minor cycle, or word"). My copy, the one > edited by Carpenter and Doran, has a note #1 by them, "Turing seems > to be the first user of 'word' with this meaning." I have Brian's > email, I can ask him how they came to that determination, if you'd > like. I don't see that this is the same meaning. Do you? "Minor cycle" suggests timing parameters. But it would be interesting to know whether this document pre- or postdates Goldstine and von Neumann. And since we were also talking about bits, it seems that OED has its own entry, bit, n.4: A unit of information derived from a choice between two equally probable alternatives or ‘events’; such a unit stored electronically in a computer. 1948 C. E. Shannon in Bell Syst. Techn. Jrnl. July 380 The choice of a logarithmic base corresponds to the choice of a unit for measuring information. If the base 2 is used the resulting units may be called binary digits, or more briefly bits, a word suggested by J. W. Tukey. 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: 163 bytes Desc: not available URL: From usotsuki at buric.co Fri Sep 9 10:05:44 2022 From: usotsuki at buric.co (Steve Nickolas) Date: Thu, 8 Sep 2022 20:05:44 -0400 (EDT) Subject: [TUHS] Re-implementations/Clean-Rooms et al. In-Reply-To: References: <20220908221639.GR11929@mcvoy.com> Message-ID: On Thu, 8 Sep 2022, Warner Losh wrote: > On Thu, Sep 8, 2022 at 5:29 PM Steve Nickolas wrote: > >> On Thu, 8 Sep 2022, Warner Losh wrote: >> >>> But it likely didn't matter, since 32v likely lost its copyright >>> protection due to AT&T distributing too many copies without the required >>> copyright markings. At least that was the preliminary ruling that caused >>> the suit to be settled... AT&T didn't want it finalized, though the cat >>> was somewhat out of the bag at this point... >> >> It would be nice if that were an absolute rather than a probably, because >> then the status for 32V wouldn't be clouded. >> > > It would be nice. At this late date, one wonders what would happen if it > were litigated again... I suspect that nobody would bother given the > small possible gain and the huge expense... But it would also reduce > shareholder values to explicitly say there's no copyright here or to > clarify that the ancient licenses are valid. So we're in this state > where it's basically free and clear, treated like it's free and clear, > but really isn't free and clear. > > Warner I'm probably the only one brazen enough to put it to the test. For some years, I've wanted to create a free implementation of System V, and then move on from there. (I know there's limited utility for such a thing, because of the BSDs.) A few things actually hinge on this. If it were considered a fact, and not a mere opinion, that 32V was PD, then I could be sure that certain things were safe to use, rather than having to rewrite (including some particularly tricky stuff the BSDs never fully reimplemented, like diff(1)). I actually did write a replacement for the Caldera header. (I still hold that the Caldera license is void because it has a Caldera copyright claim, and it has been proven in court that they didn't have the copyright to give.) It just says why I think it *should* be safe to use the code. -uso. From crossd at gmail.com Fri Sep 9 10:11:16 2022 From: crossd at gmail.com (Dan Cross) Date: Thu, 8 Sep 2022 20:11:16 -0400 Subject: [TUHS] Happy birthday, Unix timestamp! In-Reply-To: References: Message-ID: On Thu, Sep 8, 2022, 7:50 PM Rob Pike wrote: > There was a delightful conference in Copenhagen celebrating that event, > and I was lucky enough to attend. The slides of my talk live here: > http://herpolhode.com/rob/ugly.pdf > > I flew back the next day, September 10, 2011, and it was a beautiful clear > night with a stunning view of the city. We sat in the last row of the > plane, and had an unobstructed view of the trade towers as we landed near > midnight. We went home, fell asleep, and were woken by a phone call about > 9am. > You probably flew approximately over me. I was working late that night in downtown Manhattan, a few blocks from the WTC, trying to get a demo working on a Compaq iPaq running Plan 9 in preparation for a trade show in San Diego a day or two later. That, of course, never happened. - Dan C. -rob > > > On Fri, Sep 9, 2022 at 8:29 AM Dave Horsfall wrote: > >> https://www.timeanddate.com/on-this-day/september/9 >> >> ``Unix time or Unix epoch, POSIX time or Unix timestamp, is a time system >> that measures the number of seconds since midnight UTC of January 1, >> 1970, >> not counting leap seconds. At 01:46:40 UTC on September 9, 2001, Unix >> time >> reached the billionth second timestamp.'' >> >> Hard to believe that it was that long ago... >> >> -- Dave >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Fri Sep 9 10:17:50 2022 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 8 Sep 2022 17:17:50 -0700 Subject: [TUHS] Re-implementations/Clean-Rooms et al. In-Reply-To: References: <20220908221639.GR11929@mcvoy.com> Message-ID: <20220909001750.GW11929@mcvoy.com> On Thu, Sep 08, 2022 at 08:05:44PM -0400, Steve Nickolas wrote: > On Thu, 8 Sep 2022, Warner Losh wrote: > > >On Thu, Sep 8, 2022 at 5:29 PM Steve Nickolas wrote: > > > >>On Thu, 8 Sep 2022, Warner Losh wrote: > >> > >>>But it likely didn't matter, since 32v likely lost its copyright > >>>protection due to AT&T distributing too many copies without the required > >>>copyright markings. At least that was the preliminary ruling that caused > >>>the suit to be settled... AT&T didn't want it finalized, though the cat > >>>was somewhat out of the bag at this point... > >> > >>It would be nice if that were an absolute rather than a probably, because > >>then the status for 32V wouldn't be clouded. > >> > > > >It would be nice. At this late date, one wonders what would happen if it > >were litigated again... I suspect that nobody would bother given the > >small possible gain and the huge expense... But it would also reduce > >shareholder values to explicitly say there's no copyright here or to > >clarify that the ancient licenses are valid. So we're in this state where > >it's basically free and clear, treated like it's free and clear, but > >really isn't free and clear. > > > >Warner > > I'm probably the only one brazen enough to put it to the test. > > For some years, I've wanted to create a free implementation of System V, and > then move on from there. (I know there's limited utility for such a thing, > because of the BSDs.) Why? Have you booted 32V? Run in it for a while? No VM, no networking, very basic system. Other than historical, I don't understand the point. > A few things actually hinge on this. If it were considered a fact, and not > a mere opinion, that 32V was PD, then I could be sure that certain things > were safe to use, rather than having to rewrite (including some particularly > tricky stuff the BSDs never fully reimplemented, like diff(1)). I'm a source management guy, I've written a couple of systems. I live and breath diff and diff(1) is not in the slightest way hard. I wrote my own version of SCCS in a way that you could get as many different versions of the history as you wanted in one pass. That's a lot harder than diff(1). But maybe I don't understand what you think is tricky about diff, you may have some insight I'm missing, care to share? From usotsuki at buric.co Fri Sep 9 10:52:57 2022 From: usotsuki at buric.co (Steve Nickolas) Date: Thu, 8 Sep 2022 20:52:57 -0400 (EDT) Subject: [TUHS] Re-implementations/Clean-Rooms et al. In-Reply-To: <20220909001750.GW11929@mcvoy.com> References: <20220908221639.GR11929@mcvoy.com> <20220909001750.GW11929@mcvoy.com> Message-ID: On Thu, 8 Sep 2022, Larry McVoy wrote: > On Thu, Sep 08, 2022 at 08:05:44PM -0400, Steve Nickolas wrote: >> >> I'm probably the only one brazen enough to put it to the test. >> >> For some years, I've wanted to create a free implementation of System V, and >> then move on from there. (I know there's limited utility for such a thing, >> because of the BSDs.) > > Why? Have you booted 32V? Run in it for a while? No VM, no networking, > very basic system. Other than historical, I don't understand the point. Wasn't so much about 32V itself, as 32V being potentially clear and the source for a lot of SysV, that having 32V would make rewriting SysV a lot easier. 🤪 I've used v7/386, which is probably a comparable system. >> A few things actually hinge on this. If it were considered a fact, and not >> a mere opinion, that 32V was PD, then I could be sure that certain things >> were safe to use, rather than having to rewrite (including some particularly >> tricky stuff the BSDs never fully reimplemented, like diff(1)). > > I'm a source management guy, I've written a couple of systems. I live and > breath diff and diff(1) is not in the slightest way hard. I wrote my own > version of SCCS in a way that you could get as many different versions of > the history as you wanted in one pass. That's a lot harder than diff(1). > > But maybe I don't understand what you think is tricky about diff, you > may have some insight I'm missing, care to share? I'm not actually that good a programmer. Step me through an algo, I can probably interpret that as C, BASIC, 6502 ASM or 8086 ASM - but whether I can implement it from just an explanation, that's hit or miss. Frequently I come up with stupid ideas that I think are beyond me, and often I'm right. Once in a while they're not, and I'm able to actually implement something. 😜 Stuff like diff or sccs might be easy for some people here - but I've spent months wracking my brain on things I think are simpler (6502 CPU core for example - which is why for 20 years I used others' cores) and been fruitless. -uso. From douglas.mcilroy at dartmouth.edu Fri Sep 9 11:33:42 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Thu, 8 Sep 2022 21:33:42 -0400 Subject: [TUHS] Does anybody know the etymology of the term "word" as in collection of bits? Message-ID: > I heard that the IBM 709 > series had 36 bit words because Arthur Samuel, > then at IBM, needed 32 bits to identify the playable squares on a > checkerboard, plus some bits for color and kinged To be precise, Samuel's checkers program was written for the 701, which originated the architecture that the 709 inherited. Note that IBM punched cards had 72 data columns plus 8 columns typically dedicated to sequence numbers. 700-series machines supported binary IO encoded two words per row, 12 rows per card--a perfect fit to established technology. (I do not know whether the fit was deliberate or accidental.) As to where the byte came from, it was christened for the IBM Stretch, aka 7020. The machine was bit-addressed and the width of a byte was variable. Multidimensional arrays of packed bytes could be streamed at blinding speeds. Eight bits, which synced well with the 7020's 64-bit words, was standardized in the 360 series. The term "byte" was not used in connection with 700-series machines. Doug From lm at mcvoy.com Fri Sep 9 12:12:27 2022 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 8 Sep 2022 19:12:27 -0700 Subject: [TUHS] Does anybody know the etymology of the term "word" as in collection of bits? In-Reply-To: References: Message-ID: <20220909021227.GZ11929@mcvoy.com> On Thu, Sep 08, 2022 at 09:33:42PM -0400, Douglas McIlroy wrote: > As to where the byte came from, it was christened for the IBM > Stretch, aka 7020. The machine was bit-addressed and the width > of a byte was variable. Huh, I did a lot of the Unix port to the ETA-10, that was the only machine that I encountered that had bit pointers. I never understood why that was a thing, Doug, do you know the rationale for bit pointers? The ETA-10 is not well known, I was part of the Lachman group: https://en.wikipedia.org/wiki/ETA10 My first job after school, I got to watch Neil toggle in the bootstrap stuff at the console. He wasn't Seymour but he was very very good. One of the more substantial people I've ever met, I would guess he has passed but if he hasn't, he would like this group of people. Whatever, Doug or anyone, why do bit pointers make sense? Why? From lm at mcvoy.com Fri Sep 9 12:16:56 2022 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 8 Sep 2022 19:16:56 -0700 Subject: [TUHS] Re-implementations/Clean-Rooms et al. In-Reply-To: References: <20220908221639.GR11929@mcvoy.com> <20220909001750.GW11929@mcvoy.com> Message-ID: <20220909021656.GB11929@mcvoy.com> So there is this thing that us old people do that old people did to us. Go do it, kid, you can do it. It doesn't always work but it works way more than you might think. I was one of those kids where it worked. On Thu, Sep 08, 2022 at 08:52:57PM -0400, Steve Nickolas wrote: > On Thu, 8 Sep 2022, Larry McVoy wrote: > > >On Thu, Sep 08, 2022 at 08:05:44PM -0400, Steve Nickolas wrote: > >> > >>I'm probably the only one brazen enough to put it to the test. > >> > >>For some years, I've wanted to create a free implementation of System V, and > >>then move on from there. (I know there's limited utility for such a thing, > >>because of the BSDs.) > > > >Why? Have you booted 32V? Run in it for a while? No VM, no networking, > >very basic system. Other than historical, I don't understand the point. > > Wasn't so much about 32V itself, as 32V being potentially clear and the > source for a lot of SysV, that having 32V would make rewriting SysV a lot > easier. ???? > > I've used v7/386, which is probably a comparable system. > > >>A few things actually hinge on this. If it were considered a fact, and not > >>a mere opinion, that 32V was PD, then I could be sure that certain things > >>were safe to use, rather than having to rewrite (including some particularly > >>tricky stuff the BSDs never fully reimplemented, like diff(1)). > > > >I'm a source management guy, I've written a couple of systems. I live and > >breath diff and diff(1) is not in the slightest way hard. I wrote my own > >version of SCCS in a way that you could get as many different versions of > >the history as you wanted in one pass. That's a lot harder than diff(1). > > > >But maybe I don't understand what you think is tricky about diff, you > >may have some insight I'm missing, care to share? > > I'm not actually that good a programmer. Step me through an algo, I can > probably interpret that as C, BASIC, 6502 ASM or 8086 ASM - but whether I > can implement it from just an explanation, that's hit or miss. > > Frequently I come up with stupid ideas that I think are beyond me, and often > I'm right. Once in a while they're not, and I'm able to actually implement > something. ???? > > Stuff like diff or sccs might be easy for some people here - but I've spent > months wracking my brain on things I think are simpler (6502 CPU core for > example - which is why for 20 years I used others' cores) and been > fruitless. > > -uso. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From ggm at algebras.org Fri Sep 9 12:45:15 2022 From: ggm at algebras.org (George Michaelson) Date: Fri, 9 Sep 2022 10:45:15 +0800 Subject: [TUHS] Does anybody know the etymology of the term "word" as in collection of bits? In-Reply-To: References: Message-ID: There is a certain amount of "use makes master" about word and byte length. I think DECs decision to go with 6bit for 36bit was probably fine, in the context of belief around BCD. That it turned out to be a royal pain in the neck for an 8 byte world was a bit overblown given its time and place. People found ways to exploit 4 extra bits in a word to do things. DEC provided the UUO mechanism, people coded odd things into it. If BCD had been more significant who knows how long packed ASCII might have lasted. The entire field from bletchley onwards was full of arch, fey witticisms about machine names. ending things with -AC (for automatic computer) led to SILLIAC in Sydney Uni and there was a sort of poem which included them all to MANIAC. I can't but think the neologism byte over 'bite sized chunks of a whole word' goes directly to this tendency to play with language. And, the times were ones with many strange players on many continents, fertile ground for wordplay. 8 is a useful number. 5 hole Baudot wasn't enough: with parity and cases and control signal in band data was heading to 8 irrespective. Aligning data with memory and registers makes sense. On Fri, Sep 9, 2022 at 9:35 AM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > > > I heard that the IBM 709 > > series had 36 bit words because Arthur Samuel, > > then at IBM, needed 32 bits to identify the playable squares on a > > checkerboard, plus some bits for color and kinged > > To be precise, Samuel's checkers program was written for > the 701, which originated the architecture that the 709 inherited. > > Note that IBM punched cards had 72 data columns plus 8 > columns typically dedicated to sequence numbers. 700-series > machines supported binary IO encoded two words per row, 12 > rows per card--a perfect fit to established technology. (I do > not know whether the fit was deliberate or accidental.) > > As to where the byte came from, it was christened for the IBM > Stretch, aka 7020. The machine was bit-addressed and the width > of a byte was variable. Multidimensional arrays of packed bytes > could be streamed at blinding speeds. Eight bits, which synced > well with the 7020's 64-bit words, was standardized in the 360 > series. The term "byte" was not used in connection with > 700-series machines. > > Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From web at loomcom.com Fri Sep 9 13:29:36 2022 From: web at loomcom.com (Seth Morabito) Date: Thu, 08 Sep 2022 20:29:36 -0700 Subject: [TUHS] Happy birthday, Unix timestamp! In-Reply-To: References: Message-ID: <22fb8110-9d31-4025-a4ab-73eb643a99d1@www.fastmail.com> On Thu, Sep 8, 2022, at 3:28 PM, Dave Horsfall wrote: > https://www.timeanddate.com/on-this-day/september/9 > > ``Unix time or Unix epoch, POSIX time or Unix timestamp, is a time system > that measures the number of seconds since midnight UTC of January 1, 1970, > not counting leap seconds. At 01:46:40 UTC on September 9, 2001, Unix time > reached the billionth second timestamp.'' I remember this event vividly because at work we had an important system fail. There was a database that was storing the time into a VARCHAR column. Unfortunately, we were sorting on that column and using the table as a queue so we could always be sure to pick up the most recent entries and act on them. Well, you can imagine what happened when the leading digit changed from an ASCII "9" to an ASCII "1". Oops. -Seth -- Seth Morabito Poulsbo, WA web at loomcom.com From robpike at gmail.com Fri Sep 9 14:24:20 2022 From: robpike at gmail.com (Rob Pike) Date: Fri, 9 Sep 2022 14:24:20 +1000 Subject: [TUHS] Happy birthday, Unix timestamp! In-Reply-To: References: Message-ID: Oops, 2001 of course, but you knew that from multiple contextual clues. -rob On Fri, Sep 9, 2022 at 9:48 AM Rob Pike wrote: > There was a delightful conference in Copenhagen celebrating that event, > and I was lucky enough to attend. The slides of my talk live here: > http://herpolhode.com/rob/ugly.pdf > > I flew back the next day, September 10, 2011, and it was a beautiful clear > night with a stunning view of the city. We sat in the last row of the > plane, and had an unobstructed view of the trade towers as we landed near > midnight. We went home, fell asleep, and were woken by a phone call about > 9am. > > -rob > > > On Fri, Sep 9, 2022 at 8:29 AM Dave Horsfall wrote: > >> https://www.timeanddate.com/on-this-day/september/9 >> >> ``Unix time or Unix epoch, POSIX time or Unix timestamp, is a time system >> that measures the number of seconds since midnight UTC of January 1, >> 1970, >> not counting leap seconds. At 01:46:40 UTC on September 9, 2001, Unix >> time >> reached the billionth second timestamp.'' >> >> Hard to believe that it was that long ago... >> >> -- Dave >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Fri Sep 9 15:51:37 2022 From: lars at nocrew.org (Lars Brinkhoff) Date: Fri, 09 Sep 2022 05:51:37 +0000 Subject: [TUHS] Extracting files from various old dump/restore tapes In-Reply-To: (Warner Losh's message of "Mon, 22 Aug 2022 10:27:31 -0600") References: <7w7d30jnp1.fsf@junk.nocrew.org> Message-ID: <7wv8px5c46.fsf@junk.nocrew.org> In the end I decided to roll my own rather than port an old version of restore forward and possibly merge in a few other versions. I documented what I found out about the dump/restore format here: https://gunkies.org/wiki/Unix_dump/restore_tape_format Corrections welcome. From michael at kjorling.se Fri Sep 9 17:03:10 2022 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Fri, 9 Sep 2022 07:03:10 +0000 Subject: [TUHS] Happy birthday, Unix timestamp! In-Reply-To: <22fb8110-9d31-4025-a4ab-73eb643a99d1@www.fastmail.com> References: <22fb8110-9d31-4025-a4ab-73eb643a99d1@www.fastmail.com> Message-ID: <392d6229-63e5-42ca-87be-dc83e78e4172@home.arpa> On 8 Sep 2022 20:29 -0700, from web at loomcom.com (Seth Morabito): > Well, you can imagine what happened when the leading digit changed > from an ASCII "9" to an ASCII "1". Oops. Let me guess. Something very similar to what happened to Microsoft Exchange servers when the first two digits in a 32-bit signed integer representation of the current date and time (formatted as YYMMDDHHMM) changed from "21" to "22" as the date became January 1, 2022. For those who don't immediately realize why that's a snafu: what is the value of (2^31)-1 when interpreted as a string representation of a timestamp according to that format, and how does that relate to Jan 1 2022? -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” From douglas.mcilroy at dartmouth.edu Fri Sep 9 22:06:33 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Fri, 9 Sep 2022 08:06:33 -0400 Subject: [TUHS] Happy birthday, Unix timestamp! Message-ID: > Well, you can imagine what happened when the leading digit changed > from an ASCII "9" to an ASCII "1". Oops. I first saw a time-overflow bug more than 60 years ago. Accounting went haywire in the Bell Labs' comp center on day 256 of the year, when the encoded output of a new time clock reached the sign bit. Doug From paul.winalski at gmail.com Sat Sep 10 01:49:44 2022 From: paul.winalski at gmail.com (Paul Winalski) Date: Fri, 9 Sep 2022 11:49:44 -0400 Subject: [TUHS] Does anybody know the etymology of the term "word" as in collection of bits? In-Reply-To: <20220909000016.GC94367@eureka.lemis.com> References: <20220908211635.4533B18C077@mercury.lcs.mit.edu> <833155.3451.1662665281061.JavaMail.root@zimbraanteil> <61096d8f-ce80-2ba5-ffdf-8ad5f802ab02@halwitz.org> <20220909000016.GC94367@eureka.lemis.com> Message-ID: The IBM 1620 had an unusual architecture in that it did decimal arithmetic operating on variable-length strings of BCD-encoded decimal digits. It thus didn't really have a word length at all. It also didn't have a proper ALU--it did arithmetic by table lookup. The internal code name for the machine was CADET, which was said to stand for "Can't Add, Doesn't Even Try". Arithmetic on variable-length decimal strings was a feature carried over to the System/360/370 and also the DEC VAX. Have there been other commercially sold computers without a fixed word length? -Paul W. From andrew at humeweb.com Sat Sep 10 03:16:28 2022 From: andrew at humeweb.com (Andrew Hume) Date: Fri, 9 Sep 2022 10:16:28 -0700 Subject: [TUHS] Happy birthday, Unix timestamp! In-Reply-To: References: Message-ID: if i recall correctly, V1 of Unix had time measured in milliseconds. were folks that sure that this would change before wrap-around? > On Sep 9, 2022, at 5:06 AM, Douglas McIlroy wrote: > >> Well, you can imagine what happened when the leading digit changed >> from an ASCII "9" to an ASCII "1". Oops. > > I first saw a time-overflow bug more than 60 years ago. Accounting > went haywire in the Bell Labs' comp center on day 256 of the year, > when the encoded output of a new time clock reached the sign bit. > > Doug From douglas.mcilroy at dartmouth.edu Sat Sep 10 03:26:31 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Fri, 9 Sep 2022 13:26:31 -0400 Subject: [TUHS] Does anybody know the etymology of the term "word" as in collection of bits? Message-ID: > Doug or anyone, why do bit pointers make sense? Why? Bit-addressing is very helpful for manipulating characters in a word-organized memory. The central idea of my ancient (patented!) string macros that underlay SNOBOL was that it's more efficient to refer to 6-bit characters as living at bits 0,6,12,... of a 36-bit word than as being characters 0,1,2,... of the word. I've heard that this convention was supported in hardware on the PDP-10. In the IBM 7020 floats and ints were word-addressed. But those addresses could be extended past the "decimal point" to refer to bits. Bits were important. The computer was designed in parallel with the Harvest streaming "attachment" for NSA. Harvest was basically intended to gather statistics useful in code-breaking, such as frequency counts and autocorrelations, for data typically encoded in packed 5- to 8-bit characters. It was controlled by a 20-word "setup" that specified operations on rectangular and triangular indexing patterns in multidimensional arrays. Going beyond statistics, one of the operations was SQML (sequential multiple lookup) where each character was looked up in a table that specified a replacement and a next table--a spec for an arbitrary Turing machine that moved its tape at byte-streaming speed! Doug From bakul at iitbombay.org Sat Sep 10 04:44:10 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Fri, 9 Sep 2022 11:44:10 -0700 Subject: [TUHS] Does anybody know the etymology of the term "word" as in collection of bits? In-Reply-To: References: <20220908211635.4533B18C077@mercury.lcs.mit.edu> <833155.3451.1662665281061.JavaMail.root@zimbraanteil> <61096d8f-ce80-2ba5-ffdf-8ad5f802ab02@halwitz.org> <20220909000016.GC94367@eureka.lemis.com> Message-ID: On Sep 9, 2022, at 8:49 AM, Paul Winalski wrote: > > Have there been other commercially sold computers without a fixed word length? Burroughs B1700? It was a bit addressable machine. From norman at oclsc.org Sat Sep 10 04:46:13 2022 From: norman at oclsc.org (Norman Wilson) Date: Fri, 9 Sep 2022 14:46:13 -0400 (EDT) Subject: [TUHS] Does anybody know the etymology of the term "word" as in collection of bits? Message-ID: Doug McIlroy: Bit-addressing is very helpful for manipulating characters in a word-organized memory. The central idea of my ancient (patented!) string macros that underlay SNOBOL was that it's more efficient to refer to 6-bit characters as living at bits 0,6,12,... of a 36-bit word than as being characters 0,1,2,... of the word. I've heard that this convention was supported in hardware on the PDP-10. ==== Indeed it was. The DEC-10 had `byte pointers' as well as (36-bit) word addresses. A byte pointer comprised an address, a starting bit within the addressed word, and a length. There were instructions to load and store an addressed byte to or from a register, and to do same while incrementing the pointer to the next byte, wrapping the start of the next word if the remainder of the current word was too small. (Bytes couldn't span word boundaries.) Byte pointers were used routinely to process text. ASCII text was conventionally stored as five 7-bit bytes packed into each 36-bit word. The leftover bit was used by some programs as a flag to mean these five characters (usually the first of a line) were special, e.g. represented a five-decimal-digit line number. Byte pointers were used to access Sixbit characters as well (each character six bits, so six to the word, character set comprising the 64-character subset of ASCII starting with 0 == space). Norman Wilson Toronto ON (spent about four years playing with TOPS-10 before growing up to play with UNIX) From norman at oclsc.org Sat Sep 10 04:53:06 2022 From: norman at oclsc.org (Norman Wilson) Date: Fri, 9 Sep 2022 14:53:06 -0400 (EDT) Subject: [TUHS] Happy birthday, Unix timestamp! Message-ID: <45225B8CFC8D9179CB02A21EF7638288.for-standards-violators@oclsc.org> Andrew Hume: if i recall correctly, V1 of Unix had time measured in milliseconds. were folks that sure that this would change before wrap-around? ==== Not milliseconds (which were infinitesimally small to the computers of 1969!) but clock ticks, 60 per second. Initially such times were stored in a pair of 18-bit PDP-7 words, giving a lifetime of about 36 years, so not so bad. The PDP-11's 16-bit words made that a 32-bit representation, or about two and a quarter years before overflow. Which explains why the time base was updated a few times in early days, then the representation changed to whole seconds, which in 32 bits would last about as long as 36 bits of 60 Hz ticks. The PDP-7 convention is documented only in the source code, so far as I know. The evolution of time on the PDP-11 can be tracked in time(II) in old manuals; the whole-seconds representation first appears in the Fourth Edition. Norman Wilson Toronto ON Not that old a timer, but once looked into old time From beebe at math.utah.edu Sat Sep 10 05:39:14 2022 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Fri, 9 Sep 2022 13:39:14 -0600 Subject: [TUHS] Does anybody know the etymology of the term "word" as in collection of bits? Message-ID: Paul Winalski and Bakul Shah commented on bit addressable machines on the TUHS list recently. From Blaauw and Brooks' excellent Computer Architecture book http://www.math.utah.edu/pub/tex/bib/master.html#Blaauw:1997:CAC on page 98, I find >> ... >> The earliest computer with bit resolution is the [IBM 7030] Stretch. >> The Burroughs B1700 (1972) and CDC STAR100 (1973) are later examples. >> >> Bit resolution is costly in format space, since it uses a maximum >> number of bits for address and length specification. Sharpening >> resolution from the byte to the bit costs the same as increasing >> address-space size eight-fold. >> >> Since almost all storage realizations are organized as matrices, >> bit resolution is also expensive in time or equipment. >> ... ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From bakul at iitbombay.org Sat Sep 10 06:27:19 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Fri, 9 Sep 2022 13:27:19 -0700 Subject: [TUHS] Does anybody know the etymology of the term "word" as in collection of bits? In-Reply-To: References: Message-ID: On Sep 9, 2022, at 12:39 PM, Nelson H. F. Beebe wrote: > > Paul Winalski and Bakul Shah commented on bit addressable machines > on the TUHS list recently. From Blaauw and Brooks' excellent > Computer Architecture book > > http://www.math.utah.edu/pub/tex/bib/master.html#Blaauw:1997:CAC > > on page 98, I find > >>> ... >>> The earliest computer with bit resolution is the [IBM 7030] Stretch. >>> The Burroughs B1700 (1972) and CDC STAR100 (1973) are later examples. >>> >>> Bit resolution is costly in format space, since it uses a maximum >>> number of bits for address and length specification. Sharpening >>> resolution from the byte to the bit costs the same as increasing >>> address-space size eight-fold. >>> >>> Since almost all storage realizations are organized as matrices, >>> bit resolution is also expensive in time or equipment. >>> ... And yet according to Wilner's article "the B1700 appears to require less than half the memory needed by byte-oriented systems to represent programs. Comparisons with word-oriented systems are even more favorable." Figure 9 shows sample sizes for Cobol, Fortran and RPG II programs comparing B1700 code sizes with other systems. I was surprised to see this but didn't look further. https://dl.acm.org/doi/pdf/10.1145/1479992.1480060 From the same paper DESIGN OBJECTIVE Burroughs B1700 is a protean attempt to completely vanquish procrustean structures, to give 100 percent variability, or the appearance of no inherent structure. Without inherent structure, any definable language can be efficiently used for computing. There are no word sizes or data formats—operands may be any shape or size, without loss of efficiency; there are no a priori instructions—machine operations may be any function, in any form, without loss of efficiency; configuration limits, while not totally removable, can be made to exist only as points of "graceful degradation" of performance; modularity may be increased, to allow miniconfigurations and supercomputers using the same components. From henry.r.bent at gmail.com Sat Sep 10 07:12:36 2022 From: henry.r.bent at gmail.com (Henry Bent) Date: Fri, 9 Sep 2022 17:12:36 -0400 Subject: [TUHS] Does anybody know the etymology of the term "word" as in collection of bits? In-Reply-To: References: Message-ID: On Fri, 9 Sept 2022 at 16:28, Bakul Shah wrote: > On Sep 9, 2022, at 12:39 PM, Nelson H. F. Beebe > wrote: > > > > Paul Winalski and Bakul Shah commented on bit addressable machines > > on the TUHS list recently. From Blaauw and Brooks' excellent > > Computer Architecture book > > > > http://www.math.utah.edu/pub/tex/bib/master.html#Blaauw:1997:CAC > > > > on page 98, I find > > > >>> ... > >>> The earliest computer with bit resolution is the [IBM 7030] Stretch. > >>> The Burroughs B1700 (1972) and CDC STAR100 (1973) are later examples. > >>> > >>> Bit resolution is costly in format space, since it uses a maximum > >>> number of bits for address and length specification. Sharpening > >>> resolution from the byte to the bit costs the same as increasing > >>> address-space size eight-fold. > >>> > >>> Since almost all storage realizations are organized as matrices, > >>> bit resolution is also expensive in time or equipment. > >>> ... > > And yet according to Wilner's article "the B1700 appears to > require less than half the memory needed by byte-oriented > systems to represent programs. Comparisons with word-oriented > systems are even more favorable." > > Figure 9 shows sample sizes for Cobol, Fortran and RPG II programs > comparing B1700 code sizes with other systems. I was surprised to > see this but didn't look further. > > https://dl.acm.org/doi/pdf/10.1145/1479992.1480060 > > From the same paper > > DESIGN OBJECTIVE > > Burroughs B1700 is a protean attempt to completely vanquish > procrustean structures, to give 100 percent variability, or > the appearance of no inherent structure. Without inherent > structure, any definable language can be efficiently used > for computing. There are no word sizes or data > formats—operands may be any shape or size, without loss of > efficiency; there are no a priori instructions—machine > operations may be any function, in any form, without loss > of efficiency; configuration limits, while not totally > removable, can be made to exist only as points of "graceful > degradation" of performance; modularity may be increased, > to allow miniconfigurations and supercomputers using the > same components. > > The level of florid language in that paper is truly impressive. This appears to be an early implementation of intermediate language representation. I gather by its relative level of success (I had not heard of it until now) that it suffered from many of the common performance problems of such machines (Java bytecode, the Transmeta CPU, etc.) and did not succeed in the marketplace. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Sat Sep 10 07:44:57 2022 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 10 Sep 2022 07:44:57 +1000 (EST) Subject: [TUHS] Does anybody know the etymology of the term "word" as in collection of bits? In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022, Bakul Shah wrote: > And yet according to Wilner's article "the B1700 appears to require less > than half the memory needed by byte-oriented systems to represent > programs. Comparisons with word-oriented systems are even more > favorable." The Burroughs series were beautiful machines; the hardware ran native ALGOL (and thus were perfect); my favourite "B" still remains the B1500. Things went downhill after the unholy alliance betwixt M$ and Inhell... > Figure 9 shows sample sizes for Cobol, Fortran and RPG II programs > comparing B1700 code sizes with other systems. I was surprised to > see this but didn't look further. COBOL? FORTRAN? RPG? Those are all swear words to me :-) -- Dave From paul.winalski at gmail.com Sat Sep 10 11:35:28 2022 From: paul.winalski at gmail.com (Paul Winalski) Date: Fri, 9 Sep 2022 21:35:28 -0400 Subject: [TUHS] Does anybody know the etymology of the term "word" as in collection of bits? In-Reply-To: References: Message-ID: On 9/9/22, Norman Wilson wrote: > > IThe DEC-10 had `byte pointers' as well as > (36-bit) word addresses. A byte pointer comprised an address, > a starting bit within the addressed word, and a length. > There were instructions to load and store an addressed byte > to or from a register, and to do same while incrementing > the pointer to the next byte, wrapping the start of the next > word if the remainder of the current word was too small. > (Bytes couldn't span word boundaries.) That very closely resembles a field-reference expression in BLISS, which has the syntax: addr where: addr is an expression whose value is the address of the BLISS word containing the field start is an expression whose value is the stating offset within that word of the field len is an expression giving the length of the field in bits ext is an expression whose value is either 0 0r 1 that tells how to pad out the field to a full BLISS word size It's probably no accident that BLISS field expressions match this feature of the DEC-10 hardware. -Paul W. From grog at lemis.com Sat Sep 10 11:49:20 2022 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Sat, 10 Sep 2022 11:49:20 +1000 Subject: [TUHS] Obscene languages (was: Does anybody know the etymology of the term "word" as in collection of bits?) In-Reply-To: References: Message-ID: <20220910014919.GA9081@eureka.lemis.com> On Saturday, 10 September 2022 at 7:44:57 +1000, Dave Horsfall wrote: > COBOL? FORTRAN? RPG? Those are all swear words to me :-) Is this an indirect reference to the "Programmer's ABC" in the March 1976 issue of Datamation? I have a copy of the lot at http://www.lemis.com/grog/Humour/ABC.php, but the one I think you're referring to is: L is for language; use these three. Cobol, Fortran, RPG. Avoid all others, friend, and shun Those with the suffix "L slash I." And yes, I share your sentiment. 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: 163 bytes Desc: not available URL: From davida at pobox.com Sat Sep 10 20:32:51 2022 From: davida at pobox.com (David Arnold) Date: Sat, 10 Sep 2022 20:32:51 +1000 Subject: [TUHS] [COFF] Re: Will someone update the 386BSD Wikipedia page for me? In-Reply-To: <5322d5c7-bad2-b02c-8059-8e5f8d4ac3e3@spamtrap.tnetconsulting.net> References: <20220910020514.GB9081@eureka.lemis.com> <5322d5c7-bad2-b02c-8059-8e5f8d4ac3e3@spamtrap.tnetconsulting.net> Message-ID: The error was introduced on 13 September 2005, by an anonymous user from an IP address allocated to Web Perception, a Californian ISP, and (currently) geolocated to Sonoma. The change comment was: Changes - 386BSD factual errors corrected, potentially libelous statements removed, links updated, refocus on 386BSD history, authority-386BSD authors, published works, DMR refs The same IP address was used for a series of edits over 2005-2006, to topics including 386BSD, Lynne Jolitz, William Jolitz, and Radiocarbon Dating. I imagine it was simply a mistake. d > On 10 Sep 2022, at 12:26, Grant Taylor via COFF wrote: > > On 9/9/22 8:05 PM, Greg 'groggy' Lehey wrote: >> Done. > > Thank you! > >> Do you have an idea about how this error crept in? > > No, I do not. > > I came to this article after reading about the DDJ DVD archive on the geeks mailing list. I was sensitive to the emails about DDJ because I've been looking to acquire the issues (or at least articles) with the Porting Unix to the 386 articles in them. > > Now I have them! :-D > > > > -- > Grant. . . . > unix || die > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sun Sep 11 03:12:01 2022 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Sat, 10 Sep 2022 11:12:01 -0600 Subject: [TUHS] [COFF] Re: Will someone update the 386BSD Wikipedia page for me? In-Reply-To: References: <20220910020514.GB9081@eureka.lemis.com> <5322d5c7-bad2-b02c-8059-8e5f8d4ac3e3@spamtrap.tnetconsulting.net> Message-ID: On 9/10/22 4:32 AM, David Arnold wrote: > I imagine it was simply a mistake. I naively assumed it was an off-by-one / fat-finger / typo intending to type seventeen. A slightly modified, nicer, form of the common quote: Never attribute to malice that which is adequately explained by mistake. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4017 bytes Desc: S/MIME Cryptographic Signature URL: From kennethgoodwin56 at gmail.com Sun Sep 11 03:45:21 2022 From: kennethgoodwin56 at gmail.com (Kenneth Goodwin) Date: Sat, 10 Sep 2022 13:45:21 -0400 Subject: [TUHS] [COFF] Re: Will someone update the 386BSD Wikipedia page for me? In-Reply-To: References: <20220910020514.GB9081@eureka.lemis.com> <5322d5c7-bad2-b02c-8059-8e5f8d4ac3e3@spamtrap.tnetconsulting.net> Message-ID: Not sure where Bill Jolitz lived during that time period. But considering the scope of the changes, I would suspect that perhaps he might have been the author of such changes. On Sat, Sep 10, 2022, 1:15 PM Grant Taylor via TUHS wrote: > On 9/10/22 4:32 AM, David Arnold wrote: > > I imagine it was simply a mistake. > > I naively assumed it was an off-by-one / fat-finger / typo intending to > type seventeen. > > A slightly modified, nicer, form of the common quote: Never attribute > to malice that which is adequately explained by mistake. > > > > -- > Grant. . . . > unix || die > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Sun Sep 11 09:24:57 2022 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Sun, 11 Sep 2022 09:24:57 +1000 Subject: [TUHS] Will someone update the 386BSD Wikipedia page for me? In-Reply-To: References: <20220910020514.GB9081@eureka.lemis.com> <5322d5c7-bad2-b02c-8059-8e5f8d4ac3e3@spamtrap.tnetconsulting.net> Message-ID: <20220910232457.GA15285@eureka.lemis.com> On Saturday, 10 September 2022 at 11:12:01 -0600, The UNIX Heritage Society wrote: > On 9/10/22 4:32 AM, David Arnold wrote: >> I imagine it was simply a mistake. > > I naively assumed it was an off-by-one / fat-finger / typo intending to > type seventeen. > > A slightly modified, nicer, form of the common quote: Never attribute > to malice that which is adequately explained by mistake. This is pretty much Hanlon's razor (https://en.wikipedia.org/wiki/Hanlon%27s_razor): never attribute to malice that which is adequately explained by stupidity Does anybody know if the Robert Hanlon to which the saying was attributed was the Bob Hanlon that I knew at Tandem? 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: 163 bytes Desc: not available URL: From dave at horsfall.org Sun Sep 11 10:09:16 2022 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 11 Sep 2022 10:09:16 +1000 (EST) Subject: [TUHS] Happy birthday, Unix timestamp! In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022, Rob Pike wrote: > There was a delightful conference in Copenhagen celebrating that event, > and I was lucky enough to attend. The slides of my talk live > here: http://herpolhode.com/rob/ugly.pdf > > I flew back the next day, September 10, 2011, and it was a beautiful > clear night with a stunning view of the city. We sat in the last row of > the plane, and had an unobstructed view of the trade towers as we landed > near midnight. We went home, fell asleep, and were woken by a phone call > about 9am. Cripes... I remember it well. -- Dave From fair-tuhs at netbsd.org Sun Sep 11 11:18:44 2022 From: fair-tuhs at netbsd.org (Erik E. Fair) Date: Sat, 10 Sep 2022 18:18:44 -0700 Subject: [TUHS] Will someone update the 386BSD Wikipedia page for me? In-Reply-To: <20220910232457.GA15285@eureka.lemis.com> References: Message-ID: <11149.1662859124@cesium.clock.org> I have a counter to Hanlon's Razor: "The effects of any sufficiently advanced stupidity are *indistinguishable* from malice." "Is he evil or just stupid?" "Who cares? We still have a mess to deal with." Erik From dscherrer at solar.stanford.edu Sun Sep 11 12:48:21 2022 From: dscherrer at solar.stanford.edu (Deborah Scherrer) Date: Sat, 10 Sep 2022 19:48:21 -0700 Subject: [TUHS] Will someone update the 386BSD Wikipedia page for me? In-Reply-To: <11149.1662859124@cesium.clock.org> References: <11149.1662859124@cesium.clock.org> Message-ID: Ah, good one... Deborah On 9/10/22 6:18 PM, Erik E. Fair wrote: > I have a counter to Hanlon's Razor: > > "The effects of any sufficiently advanced stupidity are > *indistinguishable* from malice." > > "Is he evil or just stupid?" > > "Who cares? We still have a mess to deal with." > >     Erik From douglas.mcilroy at dartmouth.edu Sun Sep 11 23:30:03 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sun, 11 Sep 2022 09:30:03 -0400 Subject: [TUHS] Does anybody know the etymology of the term "word" as in collection of bits? Message-ID: Anecdote prompted by the advent of Burroughs in this thread: At the 1968 NATO conference on Software Engineering, the discussion turned to language design strategies. I noted that the design of Algol 68, for example, presupposed a word-based machine, whereupon Burroughs architect Bob Barton brought the house down with the remark, "In the beginning was the Word, all right--but it was not a fixed number of bits!" [Algol 68's presupposition is visible in declarations like "long long long ... int". An implementation need support only a limited number of "longs", but each supported variety must have a definite maximum value, which is returned by an "environment enquiry" function. For amusement, consider the natural idea of implementing the longest variety with bignums.] Doug From cowan at ccil.org Mon Sep 12 01:08:51 2022 From: cowan at ccil.org (John Cowan) Date: Sun, 11 Sep 2022 11:08:51 -0400 Subject: [TUHS] Does anybody know the etymology of the term "word" as in collection of bits? In-Reply-To: References: Message-ID: On Sun, Sep 11, 2022 at 9:31 AM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > [Algol 68's presupposition is visible in declarations like "long long > long ... int". An implementation need support only a limited number of > "longs", To clarify things for A68 n00bs, you can *write* an indefinite number of "longs", but after an implementation-defined point they don't add any further range (and/or precision in the case of floats). This is true in a truncated way in C as well, where "long" (which is the same as "long int") may be the same as "int". > but each supported variety must have a definite maximum > value, which is returned by an "environment enquiry" function. For > amusement, consider the natural idea of implementing the longest > variety with bignums.] > In actual bignum implementations, there is a biggest bignum, but it may not be possible to actually construct it. In GMP using 64-bit digits, it is theoretically 2^((2^31 - 1) * (2^64 - 1)), or 2^39,614,081,238,685,424,720,914,939,905, which is Very Big Indeed. But there is nothing preventing an implementer from watching intermediate results and throwing an exception if they get too big. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Mon Sep 12 01:30:25 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Sun, 11 Sep 2022 08:30:25 -0700 Subject: [TUHS] Does anybody know the etymology of the term "word" as in collection of bits? In-Reply-To: References: Message-ID: <45A8556C-CAFE-420A-8571-974B9D67D436@iitbombay.org> On Sep 11, 2022, at 6:30 AM, Douglas McIlroy wrote: > > [Algol 68's presupposition is visible in declarations like "long long > long ... int". An implementation need support only a limited number of > "longs", but each supported variety must have a definite maximum > value, which is returned by an "environment enquiry" function. For > amusement, consider the natural idea of implementing the longest > variety with bignums.] It would be natural to use a Kleene star to represent an arbitrarily long string of LONGs -- "long* int" -- though AFAIK Algol68 doesn't do bignums. Weirdly even most 21st century progamming languages do not provide built-in support for bignums! C's INT_MAX, LONG_MAX etc are kind of an environment enquiry... From paul.winalski at gmail.com Mon Sep 12 01:45:40 2022 From: paul.winalski at gmail.com (Paul Winalski) Date: Sun, 11 Sep 2022 11:45:40 -0400 Subject: [TUHS] Does anybody know the etymology of the term "word" as in collection of bits? In-Reply-To: <45A8556C-CAFE-420A-8571-974B9D67D436@iitbombay.org> References: <45A8556C-CAFE-420A-8571-974B9D67D436@iitbombay.org> Message-ID: On 9/11/22, Bakul Shah wrote: > > C's INT_MAX, LONG_MAX etc are kind of an environment enquiry... What size to use in C for int and long (pointers had to be 64-bit; no issue there) was a big headache for DEC in the migration of Unix (Ultrix) from VAX to Alpha. The first C compiler implementation used ILP64 (64 bits for int, long, and pointer) and ran afoul of a lot of code that assumed an int was 32 bits. ILP64 vs. LP64 because as divisive an issue as the big-endian vs. little-endian debate. -Paul W. From usotsuki at buric.co Mon Sep 12 02:20:32 2022 From: usotsuki at buric.co (Steve Nickolas) Date: Sun, 11 Sep 2022 12:20:32 -0400 (EDT) Subject: [TUHS] Does anybody know the etymology of the term "word" as in collection of bits? In-Reply-To: References: <45A8556C-CAFE-420A-8571-974B9D67D436@iitbombay.org> Message-ID: On Sun, 11 Sep 2022, Paul Winalski wrote: > On 9/11/22, Bakul Shah wrote: >> >> C's INT_MAX, LONG_MAX etc are kind of an environment enquiry... > > What size to use in C for int and long (pointers had to be 64-bit; no > issue there) was a big headache for DEC in the migration of Unix > (Ultrix) from VAX to Alpha. The first C compiler implementation used > ILP64 (64 bits for int, long, and pointer) and ran afoul of a lot of > code that assumed an int was 32 bits. ILP64 vs. LP64 because as > divisive an issue as the big-endian vs. little-endian debate. > > -Paul W. When I first wrote C code I *assumed* things that were only necessarily true on the platform I learned on (char=8, short=16, long=32; int=16, pointer could be either 16 or 32, requiring the addition of the keywords "near" and "far"). (I'm glad C99 introduced , but on that platform the only C99 compiler is OpenWatcom.) -uso. From web at loomcom.com Tue Sep 13 09:25:50 2022 From: web at loomcom.com (Seth Morabito) Date: Mon, 12 Sep 2022 16:25:50 -0700 Subject: [TUHS] DMD 5620 simulator Message-ID: <477dbaa9-d433-471d-a1b9-045ffded634e@www.fastmail.com> Hello all, I've recently been improving the AT&T/Teletype DMD 5620 simulator I wrote a few years ago. It can now run either the 8;7;3 or 8;7;5 firmware. It also now supports executing a local shell or connecting directly to a physical or virtual tty device. It runs natively on Linux or macOS with X11 or Wayland, but I would love help creating a Windows version if you're a Windows programmer (I am an occasional Windows user, but I am not at all knowledgeable about Windows programming). Full details are available here: https://loomcom.com/3b2/dmd5620_emulator.html The source code is here: https://github.com/sethm/dmd_gtk Many thanks go to my friend Sark (@crtdude on Twitter) for tracking down the 8;7;3 firmware and dumping it for me. I'd also like to thank Mike Haertel for helping find bugs, providing feedback, and inspiring me to get it working with Research Unix in addition to SVR3. Feedback, bug reports, and pull requests are all welcome! -Seth -- Seth Morabito Poulsbo, WA web at loomcom.com From lm at mcvoy.com Tue Sep 13 11:53:16 2022 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 12 Sep 2022 18:53:16 -0700 Subject: [TUHS] DMD 5620 simulator In-Reply-To: <477dbaa9-d433-471d-a1b9-045ffded634e@www.fastmail.com> References: <477dbaa9-d433-471d-a1b9-045ffded634e@www.fastmail.com> Message-ID: <20220913015316.GM9175@mcvoy.com> This looks like some really nice work. I used a BLIT at UW Madison and loved it, it was way more useful than a terminal and way less fuss than a full blown windowing system. Felt like the knee of the curve. All of that over a serial line, that's impressive. I dunno, but I bet that Rob trys it out just for a trip down memory lane. On Mon, Sep 12, 2022 at 04:25:50PM -0700, Seth Morabito wrote: > Hello all, > > I've recently been improving the AT&T/Teletype DMD 5620 simulator I wrote a few years ago. It can now run either the 8;7;3 or 8;7;5 firmware. It also now supports executing a local shell or connecting directly to a physical or virtual tty device. It runs natively on Linux or macOS with X11 or Wayland, but I would love help creating a Windows version if you're a Windows programmer (I am an occasional Windows user, but I am not at all knowledgeable about Windows programming). > > Full details are available here: https://loomcom.com/3b2/dmd5620_emulator.html > > The source code is here: https://github.com/sethm/dmd_gtk > > Many thanks go to my friend Sark (@crtdude on Twitter) for tracking down the 8;7;3 firmware and dumping it for me. I'd also like to thank Mike Haertel for helping find bugs, providing feedback, and inspiring me to get it working with Research Unix in addition to SVR3. > > Feedback, bug reports, and pull requests are all welcome! > > -Seth > -- > Seth Morabito > Poulsbo, WA > web at loomcom.com -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From robpike at gmail.com Tue Sep 13 11:58:38 2022 From: robpike at gmail.com (Rob Pike) Date: Tue, 13 Sep 2022 11:58:38 +1000 Subject: [TUHS] DMD 5620 simulator In-Reply-To: <20220913015316.GM9175@mcvoy.com> References: <477dbaa9-d433-471d-a1b9-045ffded634e@www.fastmail.com> <20220913015316.GM9175@mcvoy.com> Message-ID: Some time ago, Greg Christie, then at Apple, booted up a 3B2 with a 5620 attached and invited me to play with it. Now _that_ was a trip down memory lane. (The 3B2, maybe not so much.) It was a reward for an interview with him, recorded on video, about the early days of 2d graphics as I saw them, for a course for employees. But being Apple, even though it was 0% proprietary, it will never see the light of day. -rob On Tue, Sep 13, 2022 at 11:53 AM Larry McVoy wrote: > This looks like some really nice work. I used a BLIT at UW Madison > and loved it, it was way more useful than a terminal and way less > fuss than a full blown windowing system. Felt like the knee of the > curve. All of that over a serial line, that's impressive. > > I dunno, but I bet that Rob trys it out just for a trip down memory > lane. > > On Mon, Sep 12, 2022 at 04:25:50PM -0700, Seth Morabito wrote: > > Hello all, > > > > I've recently been improving the AT&T/Teletype DMD 5620 simulator I > wrote a few years ago. It can now run either the 8;7;3 or 8;7;5 firmware. > It also now supports executing a local shell or connecting directly to a > physical or virtual tty device. It runs natively on Linux or macOS with X11 > or Wayland, but I would love help creating a Windows version if you're a > Windows programmer (I am an occasional Windows user, but I am not at all > knowledgeable about Windows programming). > > > > Full details are available here: > https://loomcom.com/3b2/dmd5620_emulator.html > > > > The source code is here: https://github.com/sethm/dmd_gtk > > > > Many thanks go to my friend Sark (@crtdude on Twitter) for tracking down > the 8;7;3 firmware and dumping it for me. I'd also like to thank Mike > Haertel for helping find bugs, providing feedback, and inspiring me to get > it working with Research Unix in addition to SVR3. > > > > Feedback, bug reports, and pull requests are all welcome! > > > > -Seth > > -- > > Seth Morabito > > Poulsbo, WA > > web at loomcom.com > > -- > --- > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Tue Sep 13 12:12:40 2022 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 12 Sep 2022 19:12:40 -0700 Subject: [TUHS] DMD 5620 simulator In-Reply-To: References: <477dbaa9-d433-471d-a1b9-045ffded634e@www.fastmail.com> <20220913015316.GM9175@mcvoy.com> Message-ID: <20220913021240.GN9175@mcvoy.com> I had a 3B1, very different machine, 68K based, I liked it. The 3B2 was, well, if I'm being nice, an also ran. It was a thing but it was never the thing. I've run at least one of the lower end models, it worked but it was behind the other systems I ran. Cool that they did it, but like many attempts, not enough ahead. I have very fond memories of the BLIT terminals, I just liked how much you got out of a serial cable. Way, way more than anyone else imagined. On Tue, Sep 13, 2022 at 11:58:38AM +1000, Rob Pike wrote: > Some time ago, Greg Christie, then at Apple, booted up a 3B2 with a 5620 > attached and invited me to play with it. Now _that_ was a trip down memory > lane. (The 3B2, maybe not so much.) > > It was a reward for an interview with him, recorded on video, about the > early days of 2d graphics as I saw them, for a course for employees. But > being Apple, even though it was 0% proprietary, it will never see the light > of day. > > -rob > > > On Tue, Sep 13, 2022 at 11:53 AM Larry McVoy wrote: > > > This looks like some really nice work. I used a BLIT at UW Madison > > and loved it, it was way more useful than a terminal and way less > > fuss than a full blown windowing system. Felt like the knee of the > > curve. All of that over a serial line, that's impressive. > > > > I dunno, but I bet that Rob trys it out just for a trip down memory > > lane. > > > > On Mon, Sep 12, 2022 at 04:25:50PM -0700, Seth Morabito wrote: > > > Hello all, > > > > > > I've recently been improving the AT&T/Teletype DMD 5620 simulator I > > wrote a few years ago. It can now run either the 8;7;3 or 8;7;5 firmware. > > It also now supports executing a local shell or connecting directly to a > > physical or virtual tty device. It runs natively on Linux or macOS with X11 > > or Wayland, but I would love help creating a Windows version if you're a > > Windows programmer (I am an occasional Windows user, but I am not at all > > knowledgeable about Windows programming). > > > > > > Full details are available here: > > https://loomcom.com/3b2/dmd5620_emulator.html > > > > > > The source code is here: https://github.com/sethm/dmd_gtk > > > > > > Many thanks go to my friend Sark (@crtdude on Twitter) for tracking down > > the 8;7;3 firmware and dumping it for me. I'd also like to thank Mike > > Haertel for helping find bugs, providing feedback, and inspiring me to get > > it working with Research Unix in addition to SVR3. > > > > > > Feedback, bug reports, and pull requests are all welcome! > > > > > > -Seth > > > -- > > > Seth Morabito > > > Poulsbo, WA > > > web at loomcom.com > > > > -- > > --- > > Larry McVoy Retired to fishing > > http://www.mcvoy.com/lm/boat > > -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From clemc at ccc.com Tue Sep 13 23:01:12 2022 From: clemc at ccc.com (Clem Cole) Date: Tue, 13 Sep 2022 09:01:12 -0400 Subject: [TUHS] DMD 5620 simulator In-Reply-To: <20220913021240.GN9175@mcvoy.com> References: <477dbaa9-d433-471d-a1b9-045ffded634e@www.fastmail.com> <20220913015316.GM9175@mcvoy.com> <20220913021240.GN9175@mcvoy.com> Message-ID: On Mon, Sep 12, 2022 at 10:12 PM Larry McVoy wrote: > I have very fond memories of the BLIT terminals, I just liked how much > you got out of a serial cable. Way, way more than anyone else imagined. > I think that is a good way to express it. The client/server paradigm is really well considered - what belongs on each side. of the link such that the data that actually had to be sent between them is minimum. It becomes a solid demonstration of what you need to get a job done. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Wed Sep 14 00:23:58 2022 From: tuhs at tuhs.org (John Foust via TUHS) Date: Tue, 13 Sep 2022 09:23:58 -0500 Subject: [TUHS] Does anybody know the etymology of the term "word" as in collection of bits? In-Reply-To: <20220909021227.GZ11929@mcvoy.com> References: <20220909021227.GZ11929@mcvoy.com> Message-ID: <166307905748.2133935.14254031960299534298@minnie.tuhs.org> At 09:12 PM 9/8/2022, Larry McVoy wrote: >My first job after school, I got to watch Neil toggle in the bootstrap >stuff at the console. He wasn't Seymour but he was very very good. >One of the more substantial people I've ever met, I would guess he >has passed but if he hasn't, he would like this group of people. He passed away in 2007: https://www.msthalloffame.org/neil_robert_lincoln.htm Lincoln died on Jan. 26, 2007, at age 69. He was a member of the American Institute of Astronautics and Aeronautics and holds nine U.S. patents for computer hardware. He was a Distinguished Lecturer of the Institute of Electronics and Electrical Engineers, a National Lecturer of the Association for Computer Machinery and on the Advisory Committee on Science and Technology Centers for the National Science Foundation. - John From paul at guertin.net Wed Sep 14 05:21:00 2022 From: paul at guertin.net (Paul Guertin) Date: Tue, 13 Sep 2022 15:21:00 -0400 Subject: [TUHS] DMD 5620 simulator In-Reply-To: <20220913021240.GN9175@mcvoy.com> References: <477dbaa9-d433-471d-a1b9-045ffded634e@www.fastmail.com> <20220913015316.GM9175@mcvoy.com> <20220913021240.GN9175@mcvoy.com> Message-ID: <4f639db3-4875-3e05-3f07-38cf6bb3e4fb@guertin.net> On 2022-09-12 22:12, Larry McVoy wrote: > I had a 3B1, very different machine, 68K based, I liked it. A 3B1 machine (named Shalosh B. Eckhad, those being transliterations of the Hebrew words for "three" and "one", respectively) is listed as coauthor of many papers by mathematician Doron Zeilberger. https://www.researchgate.net/publication/339615667_Shalosh_B_Ekhad_a_computer_credit_for_mathematicians https://sites.math.rutgers.edu/~zeilberg/ekhad/papers.html Paul Guertin From joseph at josephholsten.com Wed Sep 14 08:29:39 2022 From: joseph at josephholsten.com (Joseph Holsten) Date: Tue, 13 Sep 2022 15:29:39 -0700 Subject: [TUHS] DMD 5620 simulator In-Reply-To: <477dbaa9-d433-471d-a1b9-045ffded634e@www.fastmail.com> References: <477dbaa9-d433-471d-a1b9-045ffded634e@www.fastmail.com> Message-ID: I was wondering why you’d pick this term of all historical terms to emulate. Now I have a terrible urge to try my hand at an ADM-3A. Which just reminds me of this teletype 33 ad: https://commons.wikimedia.org/wiki/File:Teletype_Model_33_Terminal_June_1974.jpg -- josephholsten.com On Mon, Sep 12, 2022, at 16:25, Seth Morabito wrote: > Hello all, > > I've recently been improving the AT&T/Teletype DMD 5620 simulator I > wrote a few years ago. It can now run either the 8;7;3 or 8;7;5 > firmware. It also now supports executing a local shell or connecting > directly to a physical or virtual tty device. It runs natively on Linux > or macOS with X11 or Wayland, but I would love help creating a Windows > version if you're a Windows programmer (I am an occasional Windows > user, but I am not at all knowledgeable about Windows programming). > > Full details are available here: https://loomcom.com/3b2/dmd5620_emulator.html > > The source code is here: https://github.com/sethm/dmd_gtk > > Many thanks go to my friend Sark (@crtdude on Twitter) for tracking > down the 8;7;3 firmware and dumping it for me. I'd also like to thank > Mike Haertel for helping find bugs, providing feedback, and inspiring > me to get it working with Research Unix in addition to SVR3. > > Feedback, bug reports, and pull requests are all welcome! > > -Seth > -- > Seth Morabito > Poulsbo, WA > web at loomcom.com From lm at mcvoy.com Wed Sep 14 09:35:13 2022 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 13 Sep 2022 16:35:13 -0700 Subject: [TUHS] DMD 5620 simulator In-Reply-To: References: <477dbaa9-d433-471d-a1b9-045ffded634e@www.fastmail.com> Message-ID: <20220913233513.GI1684@mcvoy.com> Have you ever run a BLIT? It's basically a windowing system over a serial line except the protocol is really smart, it knows that the terminal knows how to do a bunch of stuff. In my opinion, the best serial line terminal ever built. On Tue, Sep 13, 2022 at 03:29:39PM -0700, Joseph Holsten wrote: > I was wondering why you???d pick this term of all historical terms to emulate. Now I have a terrible urge to try my hand at an ADM-3A. > > Which just reminds me of this teletype 33 ad: https://commons.wikimedia.org/wiki/File:Teletype_Model_33_Terminal_June_1974.jpg > > -- > josephholsten.com > > On Mon, Sep 12, 2022, at 16:25, Seth Morabito wrote: > > Hello all, > > > > I've recently been improving the AT&T/Teletype DMD 5620 simulator I > > wrote a few years ago. It can now run either the 8;7;3 or 8;7;5 > > firmware. It also now supports executing a local shell or connecting > > directly to a physical or virtual tty device. It runs natively on Linux > > or macOS with X11 or Wayland, but I would love help creating a Windows > > version if you're a Windows programmer (I am an occasional Windows > > user, but I am not at all knowledgeable about Windows programming). > > > > Full details are available here: https://loomcom.com/3b2/dmd5620_emulator.html > > > > The source code is here: https://github.com/sethm/dmd_gtk > > > > Many thanks go to my friend Sark (@crtdude on Twitter) for tracking > > down the 8;7;3 firmware and dumping it for me. I'd also like to thank > > Mike Haertel for helping find bugs, providing feedback, and inspiring > > me to get it working with Research Unix in addition to SVR3. > > > > Feedback, bug reports, and pull requests are all welcome! > > > > -Seth > > -- > > Seth Morabito > > Poulsbo, WA > > web at loomcom.com -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From robpike at gmail.com Wed Sep 14 10:23:31 2022 From: robpike at gmail.com (Rob Pike) Date: Wed, 14 Sep 2022 10:23:31 +1000 Subject: [TUHS] DMD 5620 simulator In-Reply-To: References: <477dbaa9-d433-471d-a1b9-045ffded634e@www.fastmail.com> <20220913015316.GM9175@mcvoy.com> <20220913021240.GN9175@mcvoy.com> Message-ID: I wish we had found a consistent way to manage the client/server (or as we called it, terminal/host) separation. Every program did it a different way, with varying levels of success. We didn't push hard enough on it at the time, but Plan 9 came about in part by thinking about the problem, and to be honest so did JavaScript. -rob On Tue, Sep 13, 2022 at 11:01 PM Clem Cole wrote: > > > On Mon, Sep 12, 2022 at 10:12 PM Larry McVoy wrote: > >> I have very fond memories of the BLIT terminals, I just liked how much >> you got out of a serial cable. Way, way more than anyone else imagined. >> > > I think that is a good way to express it. The client/server paradigm is > really well considered - what belongs on each side. of the link such that > the data that actually had to be sent between them is minimum. It becomes > a solid demonstration of what you need to get a job done. > ᐧ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Wed Sep 14 10:33:25 2022 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 13 Sep 2022 17:33:25 -0700 Subject: [TUHS] DMD 5620 simulator In-Reply-To: References: <477dbaa9-d433-471d-a1b9-045ffded634e@www.fastmail.com> <20220913015316.GM9175@mcvoy.com> <20220913021240.GN9175@mcvoy.com> Message-ID: <20220914003325.GJ1684@mcvoy.com> Huh, I thought it was less ad-hoc than that. I never had access to the source but you could look at what you could do on that terminal and you just knew that people had put some thought into making high level commands that knew what the terminal could do. It was a cool idea. Like anything, you look back and see what you could have done better, but it was still a cool idea, a big leap ahead from just a dumb terminal. On Wed, Sep 14, 2022 at 10:23:31AM +1000, Rob Pike wrote: > I wish we had found a consistent way to manage the client/server (or as we > called it, terminal/host) separation. Every program did it a different way, > with varying levels of success. We didn't push hard enough on it at the > time, but Plan 9 came about in part by thinking about the problem, and to > be honest so did JavaScript. > > -rob > > > On Tue, Sep 13, 2022 at 11:01 PM Clem Cole wrote: > > > > > > > On Mon, Sep 12, 2022 at 10:12 PM Larry McVoy wrote: > > > >> I have very fond memories of the BLIT terminals, I just liked how much > >> you got out of a serial cable. Way, way more than anyone else imagined. > >> > > > > I think that is a good way to express it. The client/server paradigm is > > really well considered - what belongs on each side. of the link such that > > the data that actually had to be sent between them is minimum. It becomes > > a solid demonstration of what you need to get a job done. > > ??? > > -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From usotsuki at buric.co Wed Sep 14 10:44:07 2022 From: usotsuki at buric.co (Steve Nickolas) Date: Tue, 13 Sep 2022 20:44:07 -0400 (EDT) Subject: [TUHS] DMD 5620 simulator In-Reply-To: References: <477dbaa9-d433-471d-a1b9-045ffded634e@www.fastmail.com> Message-ID: On Tue, 13 Sep 2022, Joseph Holsten wrote: > I was wondering why you’d pick this term of all historical terms to > emulate. Now I have a terrible urge to try my hand at an ADM-3A. Man, I love the Googie stylings of the ADM-3A. I'd kill to have one or two of them just for that. -uso. From rich.salz at gmail.com Wed Sep 14 10:43:42 2022 From: rich.salz at gmail.com (Rich Salz) Date: Tue, 13 Sep 2022 20:43:42 -0400 Subject: [TUHS] DMD 5620 simulator In-Reply-To: References: <477dbaa9-d433-471d-a1b9-045ffded634e@www.fastmail.com> <20220913015316.GM9175@mcvoy.com> <20220913021240.GN9175@mcvoy.com> Message-ID: > , and to be honest so did JavaScript. > And also, earlier, display PostScript and NeWS, right? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at via.net Wed Sep 14 10:47:40 2022 From: joe at via.net (joe mcguckin) Date: Tue, 13 Sep 2022 17:47:40 -0700 Subject: [TUHS] DMD 5620 simulator In-Reply-To: References: <477dbaa9-d433-471d-a1b9-045ffded634e@www.fastmail.com> Message-ID: <25CA94FC-AE1B-44A6-B6F6-CC5C594946D5@via.net> Yes, Yes! Go for the ADM-3a with the goofy uppercase fonts. Joe McGuckin ViaNet Communications joe at via.net 650-207-0372 cell 650-213-1302 office 650-969-2124 fax > On Sep 13, 2022, at 3:29 PM, Joseph Holsten wrote: > > I was wondering why you’d pick this term of all historical terms to emulate. Now I have a terrible urge to try my hand at an ADM-3A. > > Which just reminds me of this teletype 33 ad: https://commons.wikimedia.org/wiki/File:Teletype_Model_33_Terminal_June_1974.jpg > > -- > josephholsten.com > > On Mon, Sep 12, 2022, at 16:25, Seth Morabito wrote: >> Hello all, >> >> I've recently been improving the AT&T/Teletype DMD 5620 simulator I >> wrote a few years ago. It can now run either the 8;7;3 or 8;7;5 >> firmware. It also now supports executing a local shell or connecting >> directly to a physical or virtual tty device. It runs natively on Linux >> or macOS with X11 or Wayland, but I would love help creating a Windows >> version if you're a Windows programmer (I am an occasional Windows >> user, but I am not at all knowledgeable about Windows programming). >> >> Full details are available here: https://loomcom.com/3b2/dmd5620_emulator.html >> >> The source code is here: https://github.com/sethm/dmd_gtk >> >> Many thanks go to my friend Sark (@crtdude on Twitter) for tracking >> down the 8;7;3 firmware and dumping it for me. I'd also like to thank >> Mike Haertel for helping find bugs, providing feedback, and inspiring >> me to get it working with Research Unix in addition to SVR3. >> >> Feedback, bug reports, and pull requests are all welcome! >> >> -Seth >> -- >> Seth Morabito >> Poulsbo, WA >> web at loomcom.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From web at loomcom.com Wed Sep 14 13:10:19 2022 From: web at loomcom.com (Seth Morabito) Date: Tue, 13 Sep 2022 20:10:19 -0700 Subject: [TUHS] DMD 5620 simulator In-Reply-To: References: <477dbaa9-d433-471d-a1b9-045ffded634e@www.fastmail.com> Message-ID: <131b350b-305f-4a73-b040-9b1dcf99f4a7@www.fastmail.com> On Tue, Sep 13, 2022, at 3:29 PM, Joseph Holsten wrote: > I was wondering why you’d pick this term of all historical terms to > emulate. Now I have a terrible urge to try my hand at an ADM-3A. I have an ADM-3a in storage, and it is indeed a very fun terminal! In some senses, though, it's "yet another 80x24 terminal" (albeit, a very cool looking one). The 5620 feels a little more unique to me, and I couldn't let it go un-emulated. -Seth -- Seth Morabito Poulsbo, WA web at loomcom.com From imp at bsdimp.com Wed Sep 14 13:40:31 2022 From: imp at bsdimp.com (Warner Losh) Date: Tue, 13 Sep 2022 21:40:31 -0600 Subject: [TUHS] DMD 5620 simulator In-Reply-To: <131b350b-305f-4a73-b040-9b1dcf99f4a7@www.fastmail.com> References: <477dbaa9-d433-471d-a1b9-045ffded634e@www.fastmail.com> <131b350b-305f-4a73-b040-9b1dcf99f4a7@www.fastmail.com> Message-ID: On Tue, Sep 13, 2022, 9:10 PM Seth Morabito wrote: > > > On Tue, Sep 13, 2022, at 3:29 PM, Joseph Holsten wrote: > > I was wondering why you’d pick this term of all historical terms to > > emulate. Now I have a terrible urge to try my hand at an ADM-3A. > > I have an ADM-3a in storage, and it is indeed a very fun terminal! In some > senses, though, it's "yet another 80x24 terminal" (albeit, a very cool > looking one). The 5620 feels a little more unique to me, and I couldn't let > it go un-emulated. > 5620 is Hella cool. But the ADM-3A was the quintessential boring terminal... Warner > -Seth > -- > Seth Morabito > Poulsbo, WA > web at loomcom.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph at josephholsten.com Wed Sep 14 13:55:13 2022 From: joseph at josephholsten.com (Joseph Holsten) Date: Tue, 13 Sep 2022 20:55:13 -0700 Subject: [TUHS] DMD 5620 simulator In-Reply-To: <20220913233513.GI1684@mcvoy.com> References: <20220913233513.GI1684@mcvoy.com> Message-ID: I haven’t. I’m not sure how much it differs from the acme experience, but I still miss them especially the terminal-as-editor. I hear some of the same people may have been involved. Which is why I can’t possibly make time for the adm-3a, that never ending hobby project is already claimed by my desire for acme with syntax highlighting. /me goes back to working in a :term inside neovim inside tmux inside a mosh session inside a glorified vt100 emulator, while absolutely not crying about applications being ignorant of presentation layer for “portability” -- josephholsten.com > On Sep 13, 2022, at 16:35, Larry McVoy wrote: > > Have you ever run a BLIT? It's basically a windowing system over a > serial line except the protocol is really smart, it knows that the > terminal knows how to do a bunch of stuff. > > In my opinion, the best serial line terminal ever built. > >> On Tue, Sep 13, 2022 at 03:29:39PM -0700, Joseph Holsten wrote: >> I was wondering why you???d pick this term of all historical terms to emulate. Now I have a terrible urge to try my hand at an ADM-3A. >> >> Which just reminds me of this teletype 33 ad: https://commons.wikimedia.org/wiki/File:Teletype_Model_33_Terminal_June_1974.jpg >> >> -- >> josephholsten.com >> >>> On Mon, Sep 12, 2022, at 16:25, Seth Morabito wrote: >>> Hello all, >>> >>> I've recently been improving the AT&T/Teletype DMD 5620 simulator I >>> wrote a few years ago. It can now run either the 8;7;3 or 8;7;5 >>> firmware. It also now supports executing a local shell or connecting >>> directly to a physical or virtual tty device. It runs natively on Linux >>> or macOS with X11 or Wayland, but I would love help creating a Windows >>> version if you're a Windows programmer (I am an occasional Windows >>> user, but I am not at all knowledgeable about Windows programming). >>> >>> Full details are available here: https://loomcom.com/3b2/dmd5620_emulator.html >>> >>> The source code is here: https://github.com/sethm/dmd_gtk >>> >>> Many thanks go to my friend Sark (@crtdude on Twitter) for tracking >>> down the 8;7;3 firmware and dumping it for me. I'd also like to thank >>> Mike Haertel for helping find bugs, providing feedback, and inspiring >>> me to get it working with Research Unix in addition to SVR3. >>> >>> Feedback, bug reports, and pull requests are all welcome! >>> >>> -Seth >>> -- >>> Seth Morabito >>> Poulsbo, WA >>> web at loomcom.com > > -- > --- > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Wed Sep 14 17:48:17 2022 From: lars at nocrew.org (Lars Brinkhoff) Date: Wed, 14 Sep 2022 07:48:17 +0000 Subject: [TUHS] DMD 5620 simulator In-Reply-To: (Joseph Holsten's message of "Tue, 13 Sep 2022 15:29:39 -0700") References: <477dbaa9-d433-471d-a1b9-045ffded634e@www.fastmail.com> Message-ID: <7wzgf24cse.fsf@junk.nocrew.org> Joseph Holsten wrote: > I was wondering why you’d pick this term of all historical terms to > emulate. Now I have a terrible urge to try my hand at an ADM-3A. Please do! There is a suite of terminal emulators that try to use the original font and render the display somewhat pleasingly. It includes VT05, VT50, VT52, DataPoint 3300, and a few more. Arguably it's mostly eye candy, but I'd say it adds a little retro flair to the experience. In a similar vein, I have written terminal simulators that run the original VT100 and VT52 firmware and try to render the video output in real time. > Which just reminds me of this teletype 33 ad: > https://commons.wikimedia.org/wiki/File:Teletype_Model_33_Terminal_June_1974.jpg I have long maintained we need a good teletype emulator... nay, simulator. Think physics engine. From kevin.bowling at kev009.com Thu Sep 15 02:09:29 2022 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Wed, 14 Sep 2022 09:09:29 -0700 Subject: [TUHS] DMD 5620 simulator In-Reply-To: References: <20220913233513.GI1684@mcvoy.com> Message-ID: On Tue, Sep 13, 2022 at 8:55 PM Joseph Holsten wrote: > > I haven’t. I’m not sure how much it differs from the acme experience, but I still miss them especially the terminal-as-editor. I hear some of the same people may have been involved. > > Which is why I can’t possibly make time for the adm-3a, that never ending hobby project is already claimed by my desire for acme with syntax highlighting. > > /me goes back to working in a :term inside neovim inside tmux inside a mosh session inside a glorified vt100 emulator, while absolutely not crying about applications being ignorant of presentation layer for “portability” https://9fans.github.io/plan9port/ > -- > josephholsten.com > > > On Sep 13, 2022, at 16:35, Larry McVoy wrote: > > Have you ever run a BLIT? It's basically a windowing system over a > serial line except the protocol is really smart, it knows that the > terminal knows how to do a bunch of stuff. > > In my opinion, the best serial line terminal ever built. > > On Tue, Sep 13, 2022 at 03:29:39PM -0700, Joseph Holsten wrote: > > I was wondering why you???d pick this term of all historical terms to emulate. Now I have a terrible urge to try my hand at an ADM-3A. > > > Which just reminds me of this teletype 33 ad: https://commons.wikimedia.org/wiki/File:Teletype_Model_33_Terminal_June_1974.jpg > > > -- > > josephholsten.com > > > On Mon, Sep 12, 2022, at 16:25, Seth Morabito wrote: > > Hello all, > > > I've recently been improving the AT&T/Teletype DMD 5620 simulator I > > wrote a few years ago. It can now run either the 8;7;3 or 8;7;5 > > firmware. It also now supports executing a local shell or connecting > > directly to a physical or virtual tty device. It runs natively on Linux > > or macOS with X11 or Wayland, but I would love help creating a Windows > > version if you're a Windows programmer (I am an occasional Windows > > user, but I am not at all knowledgeable about Windows programming). > > > Full details are available here: https://loomcom.com/3b2/dmd5620_emulator.html > > > The source code is here: https://github.com/sethm/dmd_gtk > > > Many thanks go to my friend Sark (@crtdude on Twitter) for tracking > > down the 8;7;3 firmware and dumping it for me. I'd also like to thank > > Mike Haertel for helping find bugs, providing feedback, and inspiring > > me to get it working with Research Unix in addition to SVR3. > > > Feedback, bug reports, and pull requests are all welcome! > > > -Seth > > -- > > Seth Morabito > > Poulsbo, WA > > web at loomcom.com > > > -- > --- > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From lars at nocrew.org Thu Sep 15 03:48:56 2022 From: lars at nocrew.org (Lars Brinkhoff) Date: Wed, 14 Sep 2022 17:48:56 +0000 Subject: [TUHS] Extracting files from various old dump/restore tapes In-Reply-To: <7wv8px5c46.fsf@junk.nocrew.org> (Lars Brinkhoff's message of "Fri, 09 Sep 2022 05:51:37 +0000") References: <7w7d30jnp1.fsf@junk.nocrew.org> <7wv8px5c46.fsf@junk.nocrew.org> Message-ID: <7wsfkt4zjr.fsf@junk.nocrew.org> Lars Brinkhoff wrote: > In the end I decided to roll my own rather than port an old version of > restore forward and possibly merge in a few other versions. Now available from here: https://github.com/larsbrinkhoff/tools-for-unusual-tape-formats From jbglaw at lug-owl.de Thu Sep 15 07:33:25 2022 From: jbglaw at lug-owl.de (Jan-Benedict Glaw) Date: Wed, 14 Sep 2022 23:33:25 +0200 Subject: [TUHS] Extracting files from various old dump/restore tapes In-Reply-To: <7wsfkt4zjr.fsf@junk.nocrew.org> References: <7w7d30jnp1.fsf@junk.nocrew.org> <7wv8px5c46.fsf@junk.nocrew.org> <7wsfkt4zjr.fsf@junk.nocrew.org> Message-ID: <20220914213325.wqdkdocq6lajjubw@lug-owl.de> On Wed, 2022-09-14 17:48:56 +0000, Lars Brinkhoff wrote: > Lars Brinkhoff wrote: > > In the end I decided to roll my own rather than port an old version of > > restore forward and possibly merge in a few other versions. > > Now available from here: > > https://github.com/larsbrinkhoff/tools-for-unusual-tape-formats Here's some stuff to build it, at least on my side. * -Ilibword does not exist * Seems `classify-tape.c` got renamed to `classify.c` * read_32bits_l() is unused and produces a warning Thanks! I'll include that into my autobuilder. MfG, JBG diff --git a/Makefile b/Makefile index fca9d3c..ae61913 100644 --- a/Makefile +++ b/Makefile @@ -1,5 +1,5 @@ -CFLAGS = -g -W -Wall -Ilibword +CFLAGS = -g -W -Wall TOOLS = cpio classify restore @@ -8,7 +8,7 @@ all: $(TOOLS) clean: rm -f $(TOOLS) *.o -classify: classify-tape.o tape-image.o +classify: classify.o tape-image.o $(CC) $(CFLAGS) $^ -o $@ cpio: cpio.o mkdirs.o diff --git a/classify.c b/classify.c index 8f81213..2843164 100644 --- a/classify.c +++ b/classify.c @@ -43,12 +43,6 @@ read_16bits_l (uint8_t *start) return start[0] | (start[1] << 8); } -static uint32_t -read_32bits_l (uint8_t *start) -{ - return read_16bits_l (start) | (read_16bits_l (start + 2) << 16); -} - static word_t read_36bits (uint8_t *x) { -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From lyndon at orthanc.ca Thu Sep 15 11:01:34 2022 From: lyndon at orthanc.ca (Lyndon Nerenberg (VE7TFX/VE6BBM)) Date: Wed, 14 Sep 2022 18:01:34 -0700 Subject: [TUHS] The USL Toolchest from the 80s and 90s In-Reply-To: References: Message-ID: Clem Cole writes: > --000000000000a07c7c05e831d57d > Content-Type: text/plain; charset="UTF-8" > > Mike Haertel's quest for the 5620 tools got me thinking. Does anyone > know of an archive of the USL Toolchest at large? [...] > IIRC the final > edition of PCC2 was released as part of it. And wasn't there a version of rogue lurking there as well? I have memories of sneaking that past Accounting on an invoice that included a couple of other, more legit, things we downloaded. --lyndon From arnold at skeeve.com Thu Sep 15 14:23:11 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 14 Sep 2022 22:23:11 -0600 Subject: [TUHS] The USL Toolchest from the 80s and 90s In-Reply-To: References: Message-ID: <202209150423.28F4NBSg015512@freefriends.org> "Lyndon Nerenberg (VE7TFX/VE6BBM)" wrote: > Clem Cole writes: > > --000000000000a07c7c05e831d57d > > Content-Type: text/plain; charset="UTF-8" > > > > Mike Haertel's quest for the 5620 tools got me thinking. Does anyone > > know of an archive of the USL Toolchest at large? > [...] > > IIRC the final > > edition of PCC2 was released as part of it. > > And wasn't there a version of rogue lurking there as well? I have > memories of sneaking that past Accounting on an invoice that included > a couple of other, more legit, things we downloaded. > > --lyndon "new" awk was available there, as was Chris Ramming's awkcc, and ksh88. The awk book from 1987 has instructions and the phone number for logging into the toolchest. IIRC you set up a UUCP account in order to get the software transferred. I think Emacs for Unix (not GNU Emacs) was also available. I don't remember too much more. Arnold From lars at nocrew.org Thu Sep 15 15:45:17 2022 From: lars at nocrew.org (Lars Brinkhoff) Date: Thu, 15 Sep 2022 05:45:17 +0000 Subject: [TUHS] Extracting files from various old dump/restore tapes In-Reply-To: <20220914213325.wqdkdocq6lajjubw@lug-owl.de> (Jan-Benedict Glaw's message of "Wed, 14 Sep 2022 23:33:25 +0200") References: <7w7d30jnp1.fsf@junk.nocrew.org> <7wv8px5c46.fsf@junk.nocrew.org> <7wsfkt4zjr.fsf@junk.nocrew.org> <20220914213325.wqdkdocq6lajjubw@lug-owl.de> Message-ID: <7wedwd42du.fsf@junk.nocrew.org> Jan-Benedict Glaw wrote: > Here's some stuff to build it, at least on my side. > * -Ilibword does not exist > * Seems `classify-tape.c` got renamed to `classify.c` > * read_32bits_l() is unused and produces a warning Thanks! I fumbled some last-minute changes. And frankly, I didn't expect anyone to pick it up so quickly! From lars at nocrew.org Thu Sep 15 15:59:27 2022 From: lars at nocrew.org (Lars Brinkhoff) Date: Thu, 15 Sep 2022 05:59:27 +0000 Subject: [TUHS] The USL Toolchest from the 80s and 90s In-Reply-To: (Clem Cole's message of "Thu, 8 Sep 2022 18:19:52 -0400") References: Message-ID: <7w5yhp41q8.fsf@junk.nocrew.org> Clem Cole wrote: > Does anyone know of an archive of the USL Toolchest at large? Is this related? http://unixpc.taronga.com/STORE/ From lars at nocrew.org Thu Sep 15 16:11:44 2022 From: lars at nocrew.org (Lars Brinkhoff) Date: Thu, 15 Sep 2022 06:11:44 +0000 Subject: [TUHS] The USL Toolchest from the 80s and 90s In-Reply-To: <202209150423.28F4NBSg015512@freefriends.org> (arnold@skeeve.com's message of "Wed, 14 Sep 2022 22:23:11 -0600") References: <202209150423.28F4NBSg015512@freefriends.org> Message-ID: <7wy1ul2mlb.fsf@junk.nocrew.org> arnold at skeeve.com writes: > I think Emacs for Unix (not GNU Emacs) was also available. I don't > remember too much more. Someone tipped me off this is Montgomery's "BTL" Emacs: http://unixpc.taronga.com/STORE/EMACS+IN.gz It's a cpio archive, and the Name file says: "UNIX PC EMACS Version 4.9c 9/5/85 - from THE STORE!" No source code, unfortunately. From arnold at skeeve.com Thu Sep 15 16:40:15 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 15 Sep 2022 00:40:15 -0600 Subject: [TUHS] The USL Toolchest from the 80s and 90s In-Reply-To: <7w5yhp41q8.fsf@junk.nocrew.org> References: <7w5yhp41q8.fsf@junk.nocrew.org> Message-ID: <202209150640.28F6eFsd002279@freefriends.org> Lars Brinkhoff wrote: > Clem Cole wrote: > > Does anyone know of an archive of the USL Toolchest at large? > > Is this related? > > http://unixpc.taronga.com/STORE/ No. THE STORE! was an archive of binary installable packages for the Unix PC / 3B1. According to that site, AT&T ran it. You could download stuff via public UUCP. There were a lot of nice precompiled bits of software available. The SE+IN.gz is the Georgia Tech 'se' screen editor that I contributed. (See se-editor.org for a modern incarnation.) Arnold From clemc at ccc.com Thu Sep 15 23:26:28 2022 From: clemc at ccc.com (Clem Cole) Date: Thu, 15 Sep 2022 09:26:28 -0400 Subject: [TUHS] The USL Toolchest from the 80s and 90s In-Reply-To: <7w5yhp41q8.fsf@junk.nocrew.org> References: <7w5yhp41q8.fsf@junk.nocrew.org> Message-ID: Sadly, I do not think so - although there are things from the Toolchest in that archive. My guess is somebody was porting code to the UNIX PC and the Toolchest is where they got some of the sources. ᐧ On Thu, Sep 15, 2022 at 1:59 AM Lars Brinkhoff wrote: > Clem Cole wrote: > > Does anyone know of an archive of the USL Toolchest at large? > > Is this related? > > http://unixpc.taronga.com/STORE/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lyndon at orthanc.ca Fri Sep 16 03:09:52 2022 From: lyndon at orthanc.ca (Lyndon Nerenberg (VE7TFX/VE6BBM)) Date: Thu, 15 Sep 2022 10:09:52 -0700 Subject: [TUHS] The USL Toolchest from the 80s and 90s In-Reply-To: <202209150423.28F4NBSg015512@freefriends.org> References: <202209150423.28F4NBSg015512@freefriends.org> Message-ID: arnold at skeeve.com writes: > "new" awk was available there, as was Chris Ramming's awkcc, and ksh88. There were all sorts of goodies. Honey Dan-Ber UUCP, and (I think) Device Independent Troff were there. But I cannot for the life of me remember what the non-rogue software was that we bought. HDB is a likely suspect, as we ran a pretty busy UUCP/Usenet relay at the time. > The awk book from 1987 has instructions and the phone number for logging > into the toolchest. IIRC you set up a UUCP account in order to get > the software transferred. I forget the exact registration steps, now. But for delivery you set up a UUCP login for the toolchest site on your host, then they would call you and transfer the files over. And bill you some outrageous amount of money for the "long distance" charges they incurred. It was quite the scam. If we had polled them instead the LD costs would have been about 30% less. --lyndon From clemc at ccc.com Fri Sep 16 03:59:50 2022 From: clemc at ccc.com (Clem Cole) Date: Thu, 15 Sep 2022 13:59:50 -0400 Subject: [TUHS] The USL Toolchest from the 80s and 90s In-Reply-To: References: <202209150423.28F4NBSg015512@freefriends.org> Message-ID: On Thu, Sep 15, 2022 at 1:09 PM Lyndon Nerenberg (VE7TFX/VE6BBM) < lyndon at orthanc.ca> wrote: > > I forget the exact registration steps, now. But for delivery you > set up a UUCP login for the toolchest site on your host, then they > would call you and transfer the files over. And bill you some > outrageous amount of money for the "long distance" charges they > incurred. It was quite the scam. If we had polled them instead > the LD costs would have been about 30% less. > IIRC there were a bunch of other charges too. It was not well thought out and was all part of what ultimately killed the core AT&T IP against the FOSS world. The harder the AT&T folks tried to force their way as the 'standard' the more allusive it became. The problem was that their monetization model for SW was broken (although to be fair this was true for a number of folks also). It was fine for some very specific things - like CAD/CAM where the higher effectiveness of an engineer / better accuracy etc.. could be measured. But the 'value' of H-D-B UUCP or KSH88 could never be directly calculated. So charging thousands of dollars just made little sense. Hey even if they had put a single 'Toolchest' source tape for say $5K they >>might<< have been able to sell it. But trying to do it piece meal and each program was hundreds to as I recall H-D-B and KS88 were close to 1K. So with the PC business where SW was priced 'high enough' so that people did not want to steal it, but you got the volume up, you could be successful - $29.99 for Turbo Pascal is probably the best example I can think. As I have reported a couple of times. When what would end up becoming the Sys III license was being negotiated ~Winter 1980 was the one time I was in a smallish meeting with Bill Gates. Gates in complete exasperation with the AT&T 'suits' looked at them and said something I have never forgotten. Bill wanted to pay no more $25/copy for UNIX period. AT&T said if the volumes made it to millions they would drop to $1000/CPU (for a then $5-7K PC/AT). Mind you AT&T had just released its 3B20 and was sure the 3B would go up against IBM and DEC and take them on -- No more 370s or Vaxen!!! Anyway, Gates shook his head and said: *"You guys don't get it. The only thing that matters in the SW business is volume. The cost of goods is zero." * He was trying to help them understand that with SW you have to eat your development cost and either make the SW completely free (FOSS model) so close to it (Microsoft/Borland) model. BTW: for this list, I suppose we should be thankful. DEC never got it. They wanted $5K/CPU for the BLISS compiler AFTER you already bought your Vax. Imagine if they had given their tools away. PS Minor ... note after 40+ years I'm only starting to be heard at work. For those that know the Intel compilers are the same DNA as the DEC compilers and a lot of the same people. It's only been in the last year we >>finally<< won that the tools are free. Yes, we charge the commercial folks for support that care. But anyone can use them. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.donner at gmail.com Fri Sep 16 15:55:18 2022 From: marc.donner at gmail.com (Marc Donner) Date: Fri, 16 Sep 2022 01:55:18 -0400 Subject: [TUHS] Does anybody know the etymology of the term "word" as in collection of bits? In-Reply-To: References: Message-ID: BTW, IBM’s “Computer Museum” has (had?) a (the?) Stretch and Harvest. The “museum” is a warehouse full of old stuff. On Thu, Sep 8, 2022 at 9:35 PM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > > I heard that the IBM 709 > > series had 36 bit words because Arthur Samuel, > > then at IBM, needed 32 bits to identify the playable squares on a > > checkerboard, plus some bits for color and kinged > > To be precise, Samuel's checkers program was written for > the 701, which originated the architecture that the 709 inherited. > > Note that IBM punched cards had 72 data columns plus 8 > columns typically dedicated to sequence numbers. 700-series > machines supported binary IO encoded two words per row, 12 > rows per card--a perfect fit to established technology. (I do > not know whether the fit was deliberate or accidental.) > > As to where the byte came from, it was christened for the IBM > Stretch, aka 7020. The machine was bit-addressed and the width > of a byte was variable. Multidimensional arrays of packed bytes > could be streamed at blinding speeds. Eight bits, which synced > well with the 7020's 64-bit words, was standardized in the 360 > series. The term "byte" was not used in connection with > 700-series machines. > > Doug > -- ===== nygeek.net mindthegapdialogs.com/home -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Fri Sep 16 19:31:12 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 16 Sep 2022 03:31:12 -0600 Subject: [TUHS] The USL Toolchest from the 80s and 90s In-Reply-To: <202209150640.28F6eFsd002279@freefriends.org> References: <7w5yhp41q8.fsf@junk.nocrew.org> <202209150640.28F6eFsd002279@freefriends.org> Message-ID: <202209160931.28G9VC2s005857@freefriends.org> arnold at skeeve.com wrote: > The SE+IN.gz is the Georgia Tech 'se' screen editor that I > contributed. (See se-editor.org for a modern incarnation.) I'm informed that that website is no longer available. See https://github.com/screen-editor/se instead. I just now opened an issue on the Github repo. Arnold From mparson at bl.org Sat Sep 17 03:04:08 2022 From: mparson at bl.org (Michael Parson) Date: Fri, 16 Sep 2022 12:04:08 -0500 (CDT) Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> Message-ID: <3cf3e96e-f45c-9c4d-9415-37a5d1c2aaf2@bl.org> On Fri, 1 Jul 2022, Matthias Bruestle wrote: > Date: Fri, 1 Jul 2022 08:17:32 > From: Matthias Bruestle > To: TUHS > Subject: [TUHS] Re: "9 skills our grandkids won't have" - Is this a TUHS > topic? > > I know something! > > On Fri, Jul 01, 2022 at 04:05:30PM +0300, Ori Idan wrote: >>> o why CTRL/S and CTRL/Q are used for flow control in a shell command >>> line session >>> >> Also would be happy to know. > > https://en.wikipedia.org/wiki/Software_flow_control > > But I don't know the answer to Ctrl-D. :( And also the bus error > and maybe the segmentation fault if it hasn't to do with a segment > register. ^D = ASCII EOT ASCII trick, check the ascii(7) manpage, look at the octal set. For any CTRL-, drop the high bit and look at that entry. D -> 104 EOT -> 004 (End of Transmission) S -> 123 DC3 -> 024 (Teletypes used this as XOFF) Q -> 121 DC1 -> 021 (Teletypes used this as XON) No one asked about these, but my favorites: @ -> 100 NUL -> 000 [ -> 133 esc -> 033 (ASCII esc) -- Michael Parson Pflugerville, TX From tuhs at tuhs.org Sat Sep 17 04:48:44 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 16 Sep 2022 18:48:44 +0000 Subject: [TUHS] Release 5.0 Vs. System V Message-ID: Good morning all, currently trying to sort out one matter that still bewilders me with this documentation I'm working on scanning. So I've got two copies of the "Release 5.0" User's Manual and one copy of the "System V" User's Manual. I haven't identified the exact differences, lots of pages...but they certainly are not identical, there are at least a few commands in one and not the other. Given this, and past discussion, it's obvious Release 5.0 is the internal UNIX version that became System V, but what I'm curious about is if it was ever released publicly as "Release 5.0" before being branded as System V or if the name was System V from the moment the first commercial license was issued. The reason I wonder this is some inconsistencies in the documentation I see out there. So both of my Release 5.0 User's Manuals have the Bell logo on the front and no mention of the court order to cease using it. Likewise, all but one of the System V related documents I received recently contain a Bell logo on the cover next to Western Electric save for the Opeartor's Guide which curiously doesn't exhibit the front page divestiture message that other documents missing the Bell logo include. Furthermore, the actual cover sheet says "Operator's Guide UNIX System Release 5.0" so technically not System V. In fact, only the User's Manual, Administrator's Manual, Error Message Manual, Transition Aids, and Release Description specifically say System V, all the rest don't have a version listed but some list Release 5.0 on their title page. Furthering that discrepancy is this which I just purchased: https://www.ebay.com/itm/314135813726?_trkparms=amclksrc%3DITM%26aid%3D111001%26algo%3DREC.SEED%26ao%3D1%26asc%3D242152%26meid%3Dd1b5923533b045acae4f14b9dd8b4e57%26pid%3D100675%26rk%3D2%26rkt%3D14%26sd%3D284965858677%26itm%3D314135813726%26pmt%3D0%26noa%3D1%26pg%3D2380057&_trksid=p2380057.c100675.m4236&_trkparms=pageci%3A8d64fbe5-35ed-11ed-8efb-b6aa9c31d728|parentrq%3A47906e531830a0adef7482b3fffe1682|iid%3A1 Link lives as of this sending, but contains a closed auction for an Error Message Manual from the "Release 5.0" documentation line but no Bell logo. Until the Operator's Guide and this auction link, I haven't seen any "Release 5.0" branded stuff without a Bell logo, and before I bought the System V gold set, I hadn't seen System V branded stuff *with* the Bell logo. This shatters an assumption that I had made that at the same time the documentation branding shifted to System V was the same time the removal of the Bell logo happened, given that divestiture was what allowed them to aggressively market System V, but now this presents four distinct sets of System V gold documentation: Release 5.0 w/ Bell logo Release 5.0 w/o Bell logo System V w/ Bell logo System V w/o Bell logo I'm curious if anyone would happen to know what the significance here is. The covers are all printed, I can't see any indication that a bunch of 5.0 manuals were retroactively painted over nor that any System V manuals got stamped with a Bell post-production. What this means is "Release 5.0" documentation was being shipped post-divestiture and "System V" was being shipped pre-divestiture. If Release 5.0 was publicly sold as System V, then what explains the post-divestiture 5.0 manuals floating around in the wild, and vice versa, if USG couldn't effectively market and support UNIX until the divestiture, how is it so many "Release 5.0" documents are floating around in well produced commercial-quality binding, both pre and post-divestiture by the time the name "System V" would've been king. Were they still maintaining an internal 5.x branch past System V that warranted its own distinct documentation set even into the commercial period? This period right around '82-'83 is incredibly fascinating and I feel very under-documented. - Matt G. From mparson at bl.org Sat Sep 17 08:51:11 2022 From: mparson at bl.org (Michael Parson) Date: Fri, 16 Sep 2022 17:51:11 -0500 (CDT) Subject: [TUHS] The MGR window system and the Macintosh In-Reply-To: <20220804235623.GQ1959@mcvoy.com> References: <6a4c75af-0fe4-1056-6421-2e473948c07b@jfloren.net> <18af3829-5845-7cd6-1ab2-fdaa63a269d7@bitsavers.org> <20220804235623.GQ1959@mcvoy.com> Message-ID: On Thu, 4 Aug 2022, Larry McVoy wrote: > Date: Thu, 4 Aug 2022 18:56:23 > From: Larry McVoy > To: Bakul Shah > Cc: Grant Taylor , tuhs at tuhs.org > Subject: [TUHS] Re: The MGR window system and the Macintosh > > On Thu, Aug 04, 2022 at 04:21:28PM -0700, Bakul Shah wrote: >> >>> On Aug 4, 2022, at 4:07 PM, Grant Taylor via TUHS wrote: >>> >>> On 8/4/22 2:29 PM, Al Kossow wrote: >>>> i think I may need to push this to bitsavers. the c.s.unix archive was a little more difficult to find than I thought. >>> >>> Is that your site? Or someone else's. The URL tends to indicate the latter. >> >> I believe that is Andy Valencia's site. He is the author of VSTa microkernel. >> >>> I ask because I'd be happy to mirror it on my site. >> >> I think Usenet bits are archived on archive.org. For instance: >> https://archive.org/details/cdrom-usernet-sources-newsgroups-1994-10-1 >> >> You can also find them on googlegroups but don't know what damage they may >> have done. > > Oh, the damage that Google has done to netnews is immense. Remember > dejanews? With their spiffy search interface that would let you look for > stuff in date ranges? Yeah, google bought dejanews, killed the search > (because theirs was "better", it most definitely is not), and then did > google groups which is complete garbage. My current boss was a news admin at Dejanews and was there during their end days. I was the sysadmin for the datacenter (SMARTNAP) that DejaNews was co-lo'd in. Everyone wanted to peer with my news server since it fed directly into Dejanews' stuff which was a couple of racks down from my stuff. Google bought Deja and ruined it. IXC Communications bought SMARTNAP and ruined it. -- Michael Parson Pflugerville, TX From henry.r.bent at gmail.com Sat Sep 17 09:00:00 2022 From: henry.r.bent at gmail.com (Henry Bent) Date: Fri, 16 Sep 2022 19:00:00 -0400 Subject: [TUHS] The MGR window system and the Macintosh In-Reply-To: References: <6a4c75af-0fe4-1056-6421-2e473948c07b@jfloren.net> <18af3829-5845-7cd6-1ab2-fdaa63a269d7@bitsavers.org> <20220804235623.GQ1959@mcvoy.com> Message-ID: On Fri, 16 Sept 2022 at 18:51, Michael Parson wrote: > > My current boss was a news admin at Dejanews and was there during > their end days. I was the sysadmin for the datacenter (SMARTNAP) that > DejaNews was co-lo'd in. Everyone wanted to peer with my news server > since it fed directly into Dejanews' stuff which was a couple of racks > down from my stuff. > > Google bought Deja and ruined it. I knew the head sysadmin from Dejanews very well and I remember his story about them being bought out by Google. Google flew in a bunch of engineers with a bunch of disks, imaged the whole database over a weekend, and then fired everyone. Good times. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Sun Sep 18 04:03:44 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sat, 17 Sep 2022 12:03:44 -0600 Subject: [TUHS] Release 5.0 Vs. System V In-Reply-To: References: Message-ID: <202209171803.28HI3ik8007819@freefriends.org> It's not surprising that System V branding occurred pre-divestiture. Remember that they were already marketing System III circa 1980. As I've mentioned before, when I saw the UNIX 4.0 system in 1981, I was told that the Bell System ran the current version and released the earlier one publicly. Knowledge of the upcoming divestiture apparently caused someone to decide to just make the internal and external releases the same. Dunno if this helps. :-) Arnold segaloco via TUHS wrote: > Good morning all, currently trying to sort out one matter that still > bewilders me with this documentation I'm working on scanning. > > So I've got two copies of the "Release 5.0" User's Manual and one copy of > the "System V" User's Manual. I haven't identified the exact differences, > lots of pages...but they certainly are not identical, there are at least > a few commands in one and not the other. > > Given this, and past discussion, it's obvious Release 5.0 is the internal > UNIX version that became System V, but what I'm curious about is if it was > ever released publicly as "Release 5.0" before being branded as System V > or if the name was System V from the moment the first commercial license > was issued. > > The reason I wonder this is some inconsistencies in the documentation I > see out there. So both of my Release 5.0 User's Manuals have the Bell > logo on the front and no mention of the court order to cease using it. > Likewise, all but one of the System V related documents I received > recently contain a Bell logo on the cover next to Western Electric save > for the Opeartor's Guide which curiously doesn't exhibit the front page > divestiture message that other documents missing the Bell logo include. > Furthermore, the actual cover sheet says "Operator's Guide UNIX System > Release 5.0" so technically not System V. In fact, only the User's > Manual, Administrator's Manual, Error Message Manual, Transition Aids, > and Release Description specifically say System V, all the rest don't > have a version listed but some list Release 5.0 on their title page. > > Furthering that discrepancy is this which I just purchased: https://www.ebay.com/itm/314135813726?_trkparms=amclksrc%3DITM%26aid%3D111001%26algo%3DREC.SEED%26ao%3D1%26asc%3D242152%26meid%3Dd1b5923533b045acae4f14b9dd8b4e57%26pid%3D100675%26rk%3D2%26rkt%3D14%26sd%3D284965858677%26itm%3D314135813726%26pmt%3D0%26noa%3D1%26pg%3D2380057&_trksid=p2380057.c100675.m4236&_trkparms=pageci%3A8d64fbe5-35ed-11ed-8efb-b6aa9c31d728|parentrq%3A47906e531830a0adef7482b3fffe1682|iid%3A1 > > Link lives as of this sending, but contains a closed auction for an Error > Message Manual from the "Release 5.0" documentation line but no Bell logo. > Until the Operator's Guide and this auction link, I haven't seen any > "Release 5.0" branded stuff without a Bell logo, and before I bought > the System V gold set, I hadn't seen System V branded stuff *with* > the Bell logo. > > This shatters an assumption that I had made that at the same time the > documentation branding shifted to System V was the same time the removal > of the Bell logo happened, given that divestiture was what allowed them > to aggressively market System V, but now this presents four distinct > sets of System V gold documentation: > > Release 5.0 w/ Bell logo > Release 5.0 w/o Bell logo > System V w/ Bell logo > System V w/o Bell logo > > I'm curious if anyone would happen to know what the significance here is. > The covers are all printed, I can't see any indication that a bunch of > 5.0 manuals were retroactively painted over nor that any System V manuals > got stamped with a Bell post-production. What this means is "Release > 5.0" documentation was being shipped post-divestiture and "System V" > was being shipped pre-divestiture. If Release 5.0 was publicly sold as > System V, then what explains the post-divestiture 5.0 manuals floating > around in the wild, and vice versa, if USG couldn't effectively market > and support UNIX until the divestiture, how is it so many "Release 5.0" > documents are floating around in well produced commercial-quality binding, > both pre and post-divestiture by the time the name "System V" would've > been king. Were they still maintaining an internal 5.x branch past > System V that warranted its own distinct documentation set even into > the commercial period? This period right around '82-'83 is incredibly > fascinating and I feel very under-documented. > > - Matt G. From sjenkin at canb.auug.org.au Sun Sep 18 14:39:59 2022 From: sjenkin at canb.auug.org.au (steve jenkin) Date: Sun, 18 Sep 2022 14:39:59 +1000 Subject: [TUHS] Unix timelines Message-ID: In 2007 I started entering the contents of Eric Levenez’s “Unix History” diagram into “dot” format to use with Graphviz. It stalled when I was unable to create a diagram I really liked. My recollection is that I talked with Warren about encoding this data and creating diagrams. He compiled the TUHS “Unix Tree”, presumably now the definitive resource, but I haven’t see a diagram linked from there. There’s the github “Unix History” project by TUHS list folk I didn’t research producing timelines & relationships automatically from git: this would be a solid solution, if the Repo was considered as permanent as the TUHS site. The “Linux Distribution Timeline” is based on a tool, gnuclad, that takes CSV files and 'computes a cladogram’ in SVG. conversion to PNG is via ImageMagick’s “convert”. By default, timelines are produced ‘left to right’, with claimed ‘right to left’, ’top to bottom’ and ‘bottom to top’ formats - which I haven’t tested. The CSV file can include links which are built into clickable points in the final image, at least for SVG, unsure of PNG. A concern that I have is the creation of the CSV file from Distrowatch is opaque. Possibly built by hand. New diagrams are uploaded 2-3 times a year. The Levenez "fishbone" diagram doesn’t seem to be updated with Warner Losh’s 2020 “Hidden Early History”. Clem Cole’s Big Block diagram shows “low-res” diagrams are also very useful, eliminating distracting detail when appropriate. Groklaw from 2004-2009 tried to collect information about the Unix/Linux Timelines, but the site is gone now & Wayback machine hasn’t picked up many of the detail / comments page. I’ve no contact with PJ & whoever runs Groklaw now. Would that data collection contain anything more than TUHS, as it does try to include both Linux and Unix? Any suggestions? Something extra in the Linux Distro Tree is a notation for people moving between projects and tracking forks. Unsure how that’s accomplished, and not sure how important that is for Unixes. TUHS is “Early Unix”, not about Linux. However, some degree of compatibility between Unix & Linux Timeline diagrams might be useful for others if they ever try to join multiple trees. If a timeline / relationship table is constructed, designing it to be somewhat compatible will help future people. I’m not sure about tracking the many descendants of BSD. Wikipedia has a list without a timeline . Someone may already be being doing this somewhere, I didn’t look. Don’t think modern descendants of BSD should be tracked by a Unix Heritage Society, has to be a boundary somewhere. regards steve jenkin ============ Some Questions: 1. Is there any benefit in developing a canonical “Unix Timeline” dataset containing the relationships, allowing programatic conversion to diagrams? There might be better tools in the future. I’d favour tab-separated text files, because they can be read / written by Spreadsheets and converted to CSV. Warren’s solution of tables & pages is good: there’s simply too much information & complexity to capture in simple file formats The gnuclad solution of providing “Clickable Links” is useful, if like TUHS, the pages are well maintained. 2. How to cater for: - adding extra-fine detail for segments of the timeline (Warner Losh) - ‘zooming out’ and providing an overview (Clem Cole) - some sort of compatibility with known tables, like Linux Distro Timeline 3. No simple representation can, or should try, to be “all things to all people”, there’s too much detail and too many events occurred. Is there a useful subset of detail that can be captured in a simple table? There may be useful subsets of the Unix Timeline that show more or less detail, To support programatic zoom In/Out, an indent or level descriptor is required in the table. Does anyone have a good data model for that? ============ Warner Losh, "Hidden Early History of Unix”, Fosdem 2020 -> "Standard History of Unix, in 3 slides” graphviz, coloured names, landscape format [small] “Simplified family tree” 4th Edition Family Tree 6th Edition Family Tree 7th Edition Family Tree Clem Cole, UNIX, Linux and BSD, USENIX 2009, reexamining "A Short UNIX History”, 2000 talk -> "A UNIX Family History 1st 25 Yrs” [69-93] graphviz ?, landscape, coloured, triangle symbols, thin lines & arrows -> Simplified Linux Family Tree, circa ’09 graphviz ?, landscape, coloured, blocks + text, short thick lines & arrows ============ TUHS, The Unix Tree No diagrams, tarball with all content Éric Lévénez’s, "UNIX History” landscape format [very wide], lines & arrows, hand drawn, no source David du Colombier, Unix Diagram portrait format, graphviz, source Linux Timeline, Fabio Loli et al landscape format, gnuclad, source (CSV + links to ) uses ‘curved’ lines, can be changed Images: SVG, PNG Grokline, UNIX TIMELINE, 2004-2009 [dead site] Lists by Date, Vendor, Product detail pages not archived ============ -- 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 tuhs at tuhs.org Mon Sep 19 04:27:37 2022 From: tuhs at tuhs.org (Cyrille Lefevre via TUHS) Date: Sun, 18 Sep 2022 20:27:37 +0200 Subject: [TUHS] The USL Toolchest from the 80s and 90s In-Reply-To: References: Message-ID: <25b72274-a5b3-af01-30e1-c8ed0a3834c4@laposte.net> Le 15/09/2022 à 03:01, Lyndon Nerenberg (VE7TFX/VE6BBM) a écrit : > Clem Cole writes: >> --000000000000a07c7c05e831d57d >> Content-Type: text/plain; charset="UTF-8" >> >> Mike Haertel's quest for the 5620 tools got me thinking. Does anyone >> know of an archive of the USL Toolchest at large? > [...] >> IIRC the final >> edition of PCC2 was released as part of it. > > And wasn't there a version of rogue lurking there as well? I have > memories of sneaking that past Accounting on an invoice that included > a couple of other, more legit, things we downloaded. > > --lyndon Hi, the only toolchest I known are the one in csrg/bsd-4.4-lite2-source+1hour/local/toolchest# ll total 28K drwxr-xr-x 2 admin 41 4.0K May 23 2002 asd drwxr-xr-x 6 admin 41 4.0K May 23 2002 ksh drwxr-xr-x 5 admin 41 4.0K May 23 2002 ksh.2 drwxr-xr-x 2 admin 41 4.0K May 23 2002 mkutl drwxr-xr-x 7 admin 41 4.0K May 23 2002 nawk drwxr-xr-x 5 admin 41 4.0K May 23 2002 nmake drwxr-xr-x 7 admin 41 4.0K May 23 2002 tabs the ksh things in the toolchest is here http://cyrillelefevre.free.fr/ksh/ I've just put the toolchest as bsd-4.4-lite2-toolchest.tar.bz2 the Document Work Bench (DWB) is here http://cyrillelefevre.free.fr/dwb/ Regards, /me -- mailto:Cyrille.Lefevre-lists at laposte.net From tuhs at tuhs.org Tue Sep 20 00:34:28 2022 From: tuhs at tuhs.org (Cyrille Lefevre via TUHS) Date: Mon, 19 Sep 2022 16:34:28 +0200 Subject: [TUHS] The USL Toolchest from the 80s and 90s In-Reply-To: References: Message-ID: Le 15/09/2022 à 03:01, Lyndon Nerenberg (VE7TFX/VE6BBM) a écrit : > Clem Cole writes: >> --000000000000a07c7c05e831d57d >> Content-Type: text/plain; charset="UTF-8" >> >> Mike Haertel's quest for the 5620 tools got me thinking. Does anyone >> know of an archive of the USL Toolchest at large? > [...] >> IIRC the final >> edition of PCC2 was released as part of it. > > And wasn't there a version of rogue lurking there as well? I have > memories of sneaking that past Accounting on an invoice that included > a couple of other, more legit, things we downloaded. > > --lyndon Hi, the only toolchest I known are the one in csrg/bsd-4.4-lite2-source+1hour/local/toolchest# ll total 28K drwxr-xr-x 2 admin 41 4.0K May 23 2002 asd drwxr-xr-x 6 admin 41 4.0K May 23 2002 ksh drwxr-xr-x 5 admin 41 4.0K May 23 2002 ksh.2 drwxr-xr-x 2 admin 41 4.0K May 23 2002 mkutl drwxr-xr-x 7 admin 41 4.0K May 23 2002 nawk drwxr-xr-x 5 admin 41 4.0K May 23 2002 nmake drwxr-xr-x 7 admin 41 4.0K May 23 2002 tabs the ksh things in the toolchest is here http://cyrillelefevre.free.fr/ksh/ I've just put the toolchest as bsd-4.4-lite2-toolchest.tar.bz2 the Document Work Bench (DWB) is here http://cyrillelefevre.free.fr/dwb/ Regards, /me -- mailto:Cyrille.Lefevre-lists at laposte.net From imp at bsdimp.com Wed Sep 21 20:10:29 2022 From: imp at bsdimp.com (Warner Losh) Date: Wed, 21 Sep 2022 04:10:29 -0600 Subject: [TUHS] Early BSD license thread Message-ID: I hate myself a little bit, but I posted an answer to the 'BSD license origin' in this twitter thread https://twitter.com/bsdimp/status/1572521676268802049 that people might find interesting. Please note the caveats at the end of the thread: This is a bare outline hitting the high points taking only data from release files with no behind the scenes confirmation about why things changed, nor in-depth exploration of variations that I know are present, nor do I got into examples from various USENET postings from the time that stole the license for people's own different uses. Nonetheless, I hope it's useful... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Wed Sep 21 22:36:04 2022 From: robpike at gmail.com (Rob Pike) Date: Wed, 21 Sep 2022 22:36:04 +1000 Subject: [TUHS] Early BSD license thread In-Reply-To: References: Message-ID: It was a long time ago but it rankled at the time (and even came up in my Bell Labs interview): that copyright notice replaced whatever was there before. Code written and copyrighted by other institutions was absorbed into the Berkeley distribution and reattributed without credit. Joy told me later that the lawyers made them do it. He was probably telling the truth, but that didn't make it OK. -rob On Wed, Sep 21, 2022 at 8:12 PM Warner Losh wrote: > I hate myself a little bit, but I posted an answer to the 'BSD license > origin' in this twitter thread > https://twitter.com/bsdimp/status/1572521676268802049 > that people might find interesting. > > Please note the caveats at the end of the thread: This is a bare outline > hitting the high points taking only data from release files with no behind > the scenes confirmation about why things changed, nor in-depth exploration > of variations that I know are present, nor do I got into examples from > various USENET postings from the time that stole the license for people's > own different uses. > > Nonetheless, I hope it's useful... > > Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.donner at gmail.com Wed Sep 21 23:33:38 2022 From: marc.donner at gmail.com (Marc Donner) Date: Wed, 21 Sep 2022 09:33:38 -0400 Subject: [TUHS] Early BSD license thread In-Reply-To: References: Message-ID: The missing piece is some sort of framework for fractional, partial, composite, or shared ownership. The performing arts folks have a notion of this, but it is pretty specialized. Our notion of ownership is all or nothing, strictly binary. Publishing has notions of dividing rights regionally and by medium ("movie rights" is a recognized term) but not really a composite view. Movies have some stuff, but every movie is represented by its own ton-of-paper contract. No real general ideas. http://nygeek.net/2010/01/02/whose-data-are-these-anyway-2/ On Wed, Sep 21, 2022, 08:37 Rob Pike wrote: > It was a long time ago but it rankled at the time (and even came up in my > Bell Labs interview): that copyright notice replaced whatever was there > before. Code written and copyrighted by other institutions was absorbed > into the Berkeley distribution and reattributed without credit. Joy told me > later that the lawyers made them do it. He was probably telling the truth, > but that didn't make it OK. > > -rob > > > On Wed, Sep 21, 2022 at 8:12 PM Warner Losh wrote: > >> I hate myself a little bit, but I posted an answer to the 'BSD license >> origin' in this twitter thread >> https://twitter.com/bsdimp/status/1572521676268802049 >> that people might find interesting. >> >> Please note the caveats at the end of the thread: This is a bare outline >> hitting the high points taking only data from release files with no behind >> the scenes confirmation about why things changed, nor in-depth exploration >> of variations that I know are present, nor do I got into examples from >> various USENET postings from the time that stole the license for people's >> own different uses. >> >> Nonetheless, I hope it's useful... >> >> Warner >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Wed Sep 21 23:46:07 2022 From: imp at bsdimp.com (Warner Losh) Date: Wed, 21 Sep 2022 07:46:07 -0600 Subject: [TUHS] Early BSD license thread In-Reply-To: References: Message-ID: It's unclear, but possible. In 2BSD, 3BSD and 4BSD, there aren't very many copyrights, but they are all Regents copyrights on pascal, assembler, termlib and some plotting software. Well, there appeared to be two Bell Telephone Laboratories, Inc copyright in lex.c and sed.c. The vast majority of files had no copyright attached to them at all, even ones that were little changed from 32V or 7th edition. Same was true for 4.1BSD. 4.2BSD had rcs which was Copyright Walter F. Tichy and Ken Harrenstien, SRI International (mostly the former). fp which was Copyright Scott B. Baden, indent which was copyright Board of Trustees of the University of Illinois. sccstorcs copyright Kenneth L. Greer. and cpm which was copyright by Helge Skrivervik, UCB. and was one of the few files to have a permissions grant "Permission granted for use by UNIX* licencees." though many of these were for manual pages. And sccstorcs did have the permission * All rights reserved. No part of this software may be sold or distributed * in any form or by any means without the prior written permission of the * author. on it, through several releases (though it was removed before 4.3BSD-Reno). 4.3BSD added a bunch more copyrights of various people: Digital Equipment Corporation Tektronix Inc Advanced Computer Communications and likely others. Starting in 4.3BSD-Tahoe we see lots of * This code is derived from software contributed to Berkeley by * Excelan Inc. which have Regent copyrights, and sometimes the original contributor copyright. This was the time that we started also seeing the BSD license is a proto form. This continues in 4.3BSD-Reno to a greater degree. 4.4BSD continues this to a ridiculous degree. So, maybe it did happen, but I find no extant evidence of a copyright being removed and replaced by Berkeley. If anything, once files started being marked with a copyright notice, they seem to be retained over several releases and on the 2BSD series where the code was merged into. Now, it's not clear if all the code contributed by folks executed paperwork assigning the copyright to the Regents or not. But it looks like in many cases credit was given, at least in the time period starting with 2BSD. 1BSD lacks the word 'copyright' but kirk's archive has all the files in .a archives which are grepable. It didn't include any AT&T code. Warner On Wed, Sep 21, 2022 at 6:36 AM Rob Pike wrote: > It was a long time ago but it rankled at the time (and even came up in my > Bell Labs interview): that copyright notice replaced whatever was there > before. Code written and copyrighted by other institutions was absorbed > into the Berkeley distribution and reattributed without credit. Joy told me > later that the lawyers made them do it. He was probably telling the truth, > but that didn't make it OK. > > -rob > > > On Wed, Sep 21, 2022 at 8:12 PM Warner Losh wrote: > >> I hate myself a little bit, but I posted an answer to the 'BSD license >> origin' in this twitter thread >> https://twitter.com/bsdimp/status/1572521676268802049 >> that people might find interesting. >> >> Please note the caveats at the end of the thread: This is a bare outline >> hitting the high points taking only data from release files with no behind >> the scenes confirmation about why things changed, nor in-depth exploration >> of variations that I know are present, nor do I got into examples from >> various USENET postings from the time that stole the license for people's >> own different uses. >> >> Nonetheless, I hope it's useful... >> >> Warner >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Thu Sep 22 00:50:55 2022 From: rich.salz at gmail.com (Rich Salz) Date: Wed, 21 Sep 2022 10:50:55 -0400 Subject: [TUHS] Early BSD license thread In-Reply-To: References: Message-ID: The community used to be much more ignorant/naive about copyrights. It wasn't until the GPL and the CSRG conversion to GCC and Gilmore's "free the tree" efforts there that copyright was really seen as anything other than a claim of ownership. I'd also add the Apache Foundation and their CLA agreements. Anyone have a copy of John's handout from early Usenix conferences? :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Sep 22 00:57:51 2022 From: clemc at ccc.com (Clem Cole) Date: Wed, 21 Sep 2022 10:57:51 -0400 Subject: [TUHS] Fwd: Re: Early BSD license thread In-Reply-To: References: Message-ID: below in blue ... On Wed, Sep 21, 2022 at 9:47 AM Warner Losh wrote: > ... > > So, maybe it did happen, but I find no extant evidence of a copyright being > removed and replaced by Berkeley. If anything, once files started being > marked > with a copyright notice, they seem to be retained over several releases and > on the 2BSD series where the code was merged into. > > On Wed, Sep 21, 2022 at 6:36 AM Rob Pike wrote: > >> It was a long time ago but it rankled at the time (and even came up in my >> Bell Labs interview): that copyright notice replaced whatever was there >> before. Code written and copyrighted by other institutions was absorbed >> into the Berkeley distribution and reattributed without credit. Joy told me >> later that the lawyers made them do it. He was probably telling the truth, >> but that didn't make it OK. >> >> -rob >> > I think there are two different concepts that are getting mixed up here. The legal term '*copyright*' and historical term of '*provenance*.' I agree with Warner that I know of few if any cases where copyright was not maintained when it was in the code itself. And as he points out, please grep through the archives and I think that will be found to hold true. But I also think Rob rankle comment is fair. Joy and was noted for recognizing cool ideas and adding them into 'Berkeley UNIX. The line at the time was he took ideas and '*peed on them to make them smell like Berkeley*.' For example, 'Berkeley Joy Control' came from Kulp via Europe and MIT, the network stack famously started at BBN, and a lot of the support for limits and user controllers from Australia. Yes, the CSRG team did do a great deal of innovation as well as integration, but the line between the two was not always easy to see from the outside. And I think developers outside of UCB sometimes felt (to use Rob's words) 'rankled' for CSRG getting credit for some of innovation that really belonged to others, because the CSRG team was the distribution vehicle. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Thu Sep 22 00:58:11 2022 From: imp at bsdimp.com (Warner Losh) Date: Wed, 21 Sep 2022 08:58:11 -0600 Subject: [TUHS] Early BSD license thread In-Reply-To: References: Message-ID: Yea, if you look at the license statements from the 80s and early 90s from USENET and the BBS scene, you'll see that evolution playout. If you subscribed to the 'trade rags' of the 80s, you'd find them talking about Copyright some, but not much about licensing, so there were a huge number of 'licenses' that we'd laugh at today as being totally insane / unenforceable / unclear / etc... There were also some presentations at DECUS in the mid 80s (and maybe earlier) on the topic as well as their distribution of tapes got large enough... There was also a pointer to Jeremy C Reed's http://www.bsdnewsletter.com/2013/12/Features186.html as well as his book on BSD history http://www.reedmedia.net/books/bsd-history/ (which I'd love to get a copy of). It wasn't clear if it had been published or not from the link I'd love to see John's handout... Warner On Wed, Sep 21, 2022 at 8:51 AM Rich Salz wrote: > The community used to be much more ignorant/naive about copyrights. It > wasn't until the GPL and the CSRG conversion to GCC and Gilmore's "free the > tree" efforts there that copyright was really seen as anything other than a > claim of ownership. I'd also add the Apache Foundation and their CLA > agreements. Anyone have a copy of John's handout from early Usenix > conferences? :) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From miod at online.fr Thu Sep 22 01:06:32 2022 From: miod at online.fr (Miod Vallat) Date: Wed, 21 Sep 2022 15:06:32 +0000 Subject: [TUHS] Early BSD license thread In-Reply-To: References: Message-ID: > There was also a pointer to Jeremy C Reed's > http://www.bsdnewsletter.com/2013/12/Features186.html > as well as his book on BSD history > http://www.reedmedia.net/books/bsd-history/ (which I'd love to get a copy > of). > It wasn't clear if it had been published or not from the link It is still listed in "upcoming books" in the right column of http://www.reedmedia.net/books/ and is still not completed AFAIK. Miod From lm at mcvoy.com Thu Sep 22 01:09:38 2022 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 21 Sep 2022 08:09:38 -0700 Subject: [TUHS] Fwd: Re: Early BSD license thread In-Reply-To: References: Message-ID: <20220921150938.GF14437@mcvoy.com> On Wed, Sep 21, 2022 at 10:57:51AM -0400, Clem Cole wrote: > Yes, the CSRG team did do a great deal of innovation as well as > integration, but the line between the two was not always easy to see from > the outside. And I think developers outside of UCB sometimes felt (to use > Rob's words) 'rankled' for CSRG getting credit for some of innovation that > really belonged to others, because the CSRG team was the distribution > vehicle. In the valley it is well known that ideas are easy and execution is hard. Unless you have been responsible for shipping a big product and supporting it, it's hard to imagine how hard that is. There is absolutely an art to knowing when to release and when to keep fixing bugs. I think it was Keith Bostic who had that touch but I'm not positive. Someone did and having that ability is at least as important as having the ideas. A lot less "sexy" but every bit as important. From imp at bsdimp.com Thu Sep 22 01:25:10 2022 From: imp at bsdimp.com (Warner Losh) Date: Wed, 21 Sep 2022 09:25:10 -0600 Subject: [TUHS] Fwd: Re: Early BSD license thread In-Reply-To: References: Message-ID: On Wed, Sep 21, 2022 at 8:59 AM Clem Cole wrote: > below in blue ... > > On Wed, Sep 21, 2022 at 9:47 AM Warner Losh wrote: > >> ... >> >> So, maybe it did happen, but I find no extant evidence of a copyright >> being >> removed and replaced by Berkeley. If anything, once files started being >> marked >> with a copyright notice, they seem to be retained over several releases >> and >> on the 2BSD series where the code was merged into. >> >> On Wed, Sep 21, 2022 at 6:36 AM Rob Pike wrote: >> >>> It was a long time ago but it rankled at the time (and even came up in >>> my Bell Labs interview): that copyright notice replaced whatever was there >>> before. Code written and copyrighted by other institutions was absorbed >>> into the Berkeley distribution and reattributed without credit. Joy told me >>> later that the lawyers made them do it. He was probably telling the truth, >>> but that didn't make it OK. >>> >>> -rob >>> >> I think there are two different concepts that are getting mixed up here. > The legal term '*copyright*' and historical term of '*provenance*.' I > agree with Warner that I know of few if any cases where copyright was not > maintained when it was in the code itself. And as he points out, please > grep through the archives and I think that will be found to hold true. > > But I also think Rob rankle comment is fair. Joy and was noted for > recognizing cool ideas and adding them into 'Berkeley UNIX. The line at > the time was he took ideas and '*peed on them to make them smell like > Berkeley*.' For example, 'Berkeley Joy Control' came from Kulp via Europe > and MIT, the network stack famously started at BBN, and a lot of the > support for limits and user controllers from Australia. > > Yes, the CSRG team did do a great deal of innovation as well as > integration, but the line between the two was not always easy to see from > the outside. And I think developers outside of UCB sometimes felt (to use > Rob's words) 'rankled' for CSRG getting credit for some of innovation that > really belonged to others, because the CSRG team was the distribution > vehicle. > That makes a lot of sense. When there was a name, it was preserved, but a huge amount of the sources had nothing at all in the source files to identify it. One big area of contribution was into the kernel where the options sometimes contained the name of where the code came from. In the 2BSD kernels we see eg TEXAS_AUTOBAUD, MENLO_OVLY, MENLO_KOV, MENLO_JCL, MPX_FILS, CGL_RTP and a bunch of UCB_ names. It's clear the non UCB ones came from elsewhere, but there's no info on where they came from (they are documented in setup.5 at least so I know what they are). So given the sparseness of the early marking for provenance, the coments make more sense and give a better timeframe to it. Warnerᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Thu Sep 22 07:14:06 2022 From: tytso at mit.edu (Theodore Ts'o) Date: Wed, 21 Sep 2022 17:14:06 -0400 Subject: [TUHS] Fwd: Re: Early BSD license thread In-Reply-To: References: Message-ID: On Wed, Sep 21, 2022 at 10:57:51AM -0400, Clem Cole wrote: > The legal term '*copyright*' and historical term of '*provenance*.' I > agree with Warner that I know of few if any cases where copyright was not > maintained when it was in the code itself. And as he points out, please > grep through the archives and I think that will be found to hold true. > > But I also think Rob rankle comment is fair. Joy and was noted for > recognizing cool ideas and adding them into 'Berkeley UNIX. The line at > the time was he took ideas and '*peed on them to make them smell like > Berkeley*.' For example, 'Berkeley Joy Control' came from Kulp via Europe > and MIT, the network stack famously started at BBN, and a lot of the > support for limits and user controllers from Australia. > > Yes, the CSRG team did do a great deal of innovation as well as > integration, but the line between the two was not always easy to see from > the outside. Well, there can be a huge spectrum here, isn't there? Ranging from: * Take the code wholesale with no changes. * Take the code and make changes to match with local coding style. * Take the code and serially rewrite it so when you're done it only vaguely resembles the original contribution. * Look at the code, get the ideas, and the reimplement it from scratch, keeping the existing interface (or using the existing interface as a starting point before extending it) * Look at the code, get the ideas, and reimplent it from scratch with radically different interfaces. It sounds like all of these were used to some extent as part of the BSD/CSRG integration process; is that right? - Ted From clemc at ccc.com Thu Sep 22 07:46:58 2022 From: clemc at ccc.com (Clem Cole) Date: Wed, 21 Sep 2022 17:46:58 -0400 Subject: [TUHS] Fwd: Re: Early BSD license thread In-Reply-To: References: Message-ID: Sure. And of course there will always be interpretations of how much one idea salted another. But the seeds of the discomfort come from these various solutions and frankly how much the original authors were bought into/part of the integration process. On Wed, Sep 21, 2022 at 5:14 PM Theodore Ts'o wrote: > On Wed, Sep 21, 2022 at 10:57:51AM -0400, Clem Cole wrote: > > The legal term '*copyright*' and historical term of '*provenance*.' I > > agree with Warner that I know of few if any cases where copyright was not > > maintained when it was in the code itself. And as he points out, please > > grep through the archives and I think that will be found to hold true. > > > > But I also think Rob rankle comment is fair. Joy and was noted for > > recognizing cool ideas and adding them into 'Berkeley UNIX. The line at > > the time was he took ideas and '*peed on them to make them smell like > > Berkeley*.' For example, 'Berkeley Joy Control' came from Kulp via Europe > > and MIT, the network stack famously started at BBN, and a lot of the > > support for limits and user controllers from Australia. > > > > Yes, the CSRG team did do a great deal of innovation as well as > > integration, but the line between the two was not always easy to see from > > the outside. > > Well, there can be a huge spectrum here, isn't there? Ranging from: > > * Take the code wholesale with no changes. > > * Take the code and make changes to match with local coding style. > > * Take the code and serially rewrite it so when you're done it > only vaguely resembles the original contribution. > > * Look at the code, get the ideas, and the reimplement it from > scratch, keeping the existing interface (or using the existing > interface as a starting point before extending it) > > * Look at the code, get the ideas, and reimplent it from scratch > with radically different interfaces. > > It sounds like all of these were used to some extent as part of the > BSD/CSRG integration process; is that right? > > - Ted > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at ultimate.com Thu Sep 22 07:49:31 2022 From: phil at ultimate.com (Phil Budne) Date: Wed, 21 Sep 2022 17:49:31 -0400 Subject: [TUHS] Early BSD license thread In-Reply-To: References: Message-ID: <202209212149.28LLnV1J032395@ultimate.com> Not to excuse the failure of the BSD team to properly attribute source origin by adding only their copyright notice, but didn't AT&T try unfair turnabout by not properly attributing the origins of their TCP/IP code? https://en.wikipedia.org/wiki/UNIX_System_Laboratories,_Inc._v._Berkeley_Software_Design,_Inc.#University's_countersuit From bakul at iitbombay.org Thu Sep 22 08:06:00 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Wed, 21 Sep 2022 15:06:00 -0700 Subject: [TUHS] Early BSD license thread In-Reply-To: References: Message-ID: On Sep 21, 2022, at 8:25 AM, Warner Losh > wrote: > > That makes a lot of sense. When there was a name, it was preserved, but a huge amount of the sources had nothing at all in the source files to identify it. One big area of contribution was into the kernel where the options sometimes contained the name of where the code came from. In the 2BSD kernels we see eg TEXAS_AUTOBAUD, MENLO_OVLY, MENLO_KOV, MENLO_JCL, MPX_FILS, CGL_RTP and a bunch of UCB_ names. It's clear the non UCB ones came from elsewhere, but there's no info on where they came from (they are documented in setup.5 at least so I know what they are). So given the sparseness of the early marking for provenance, the coments make more sense and give a better timeframe to it. Recall that the US joined the Berne Convention in 1988. As I recall prior to that you had to stick to some copyright formalities such as putting your copyright & year in the source code. As I recall the US law didn't protect your copyright if you didn't do this in sources. This may have played a part in UCB adding a copyright source files that didn't have anything? I could be wrong but these are just some random bits picked up at the time. I did get in the habit of putting at least a one line copyright notice by default starting in 1981 (either for whatever company I worked for at the time or my own copyright for code I wrote on my own at home). -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Thu Sep 22 08:07:54 2022 From: rich.salz at gmail.com (Rich Salz) Date: Wed, 21 Sep 2022 18:07:54 -0400 Subject: [TUHS] Early BSD license thread In-Reply-To: <202209212149.28LLnV1J032395@ultimate.com> References: <202209212149.28LLnV1J032395@ultimate.com> Message-ID: Recall also that the AT&T code was protected by "trade secret" claims, so that and the Berne convention meant a copyright on each file wasn't needed. As the copyright moved to being used as a license, doing so became more important. -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Thu Sep 22 08:09:02 2022 From: crossd at gmail.com (Dan Cross) Date: Wed, 21 Sep 2022 18:09:02 -0400 Subject: [TUHS] Early BSD license thread In-Reply-To: <202209212149.28LLnV1J032395@ultimate.com> References: <202209212149.28LLnV1J032395@ultimate.com> Message-ID: On Wed, Sep 21, 2022 at 5:50 PM Phil Budne wrote: > Not to excuse the failure of the BSD team to properly attribute source > origin by adding only their copyright notice, but didn't AT&T try > unfair turnabout by not properly attributing the origins of their > TCP/IP code? One of my favorite copyright notices was for /bin/true in System V. An empty file got turned into 7 lines of comments holding copyright boilerplate and an `#ident` line with an SCCS version number: progress! - Dan C. From usotsuki at buric.co Thu Sep 22 08:19:17 2022 From: usotsuki at buric.co (Steve Nickolas) Date: Wed, 21 Sep 2022 18:19:17 -0400 (EDT) Subject: [TUHS] Early BSD license thread In-Reply-To: References: <202209212149.28LLnV1J032395@ultimate.com> Message-ID: On Wed, 21 Sep 2022, Dan Cross wrote: > On Wed, Sep 21, 2022 at 5:50 PM Phil Budne wrote: >> Not to excuse the failure of the BSD team to properly attribute source >> origin by adding only their copyright notice, but didn't AT&T try >> unfair turnabout by not properly attributing the origins of their >> TCP/IP code? > > One of my favorite copyright notices was for /bin/true in System V. > An empty file got turned into 7 lines of comments holding copyright > boilerplate and an `#ident` line with an SCCS version number: > progress! > > - Dan C. > And then when I wrote it for my own project: true - #!/bin/sh # Does something this small need a license? - SVN exit 0 false - #!/bin/sh # Does something this small need a license? - SVN exit 1 -uso. From imp at bsdimp.com Thu Sep 22 08:20:02 2022 From: imp at bsdimp.com (Warner Losh) Date: Wed, 21 Sep 2022 16:20:02 -0600 Subject: [TUHS] Early BSD license thread In-Reply-To: References: Message-ID: On Wed, Sep 21, 2022 at 4:07 PM Bakul Shah wrote: > On Sep 21, 2022, at 8:25 AM, Warner Losh wrote: > > > That makes a lot of sense. When there was a name, it was preserved, but a > huge amount of the sources had nothing at all in the source files to > identify it. One big area of contribution was into the kernel where the > options sometimes contained the name of where the code came from. In the > 2BSD kernels we see eg TEXAS_AUTOBAUD, MENLO_OVLY, MENLO_KOV, MENLO_JCL, > MPX_FILS, CGL_RTP and a bunch of UCB_ names. It's clear the non UCB ones > came from elsewhere, but there's no info on where they came from (they are > documented in setup.5 at least so I know what they are). So given the > sparseness of the early marking for provenance, the coments make more sense > and give a better timeframe to it. > > > Recall that the US joined the Berne Convention in 1988. As I recall prior > to that you had to stick to some copyright formalities such as putting your > copyright & year in the source code. As I recall the US law didn't protect > your copyright if you didn't do this in sources. This may have played a > part in UCB adding a copyright source files that didn't have anything? I > could be wrong but these are just some random bits picked up at the time. I > did get in the habit of putting at least a one line copyright notice by > default starting in 1981 (either for whatever company I worked for at the > time or my own copyright for code I wrote on my own at home). > Indeed. One of the reasons that USL settled was because they released 32V without the proper copyright notices (whatever that means, but in this case there were none at all in the media) and the judge issued a preliminary ruling declaring that 32V didn't have copyright protection. They were scared of losing that and that motivated them to settle. Interestingly, in the settlement, USL specifically agrees not to pursue trade secret claims against anybody using 4.4BSD-lite, but copyrights aren't mentioned, outside of the restricted files getting an USL copyright added: "c. USL agrees that it shall take no action against any person who utilizes any methods and concepts in the restricted files which as of this date have become available to the general public by acts not attributable to the University, its employees or students...." and "i. USL agrees that it shall take no action base on the use or distribution by any person of material contained in the Unrestricted Files." also (for another message in the thread) "f. USL agrees that it shall affix the University Copyright Notice and the University Acknowledgement to the files in exhibit C.." Where the wording of those phrases is defined elsewhere in the settlement. And there's about 8 paragraphs as to exactly how AT&T will do this in both code and documentation... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Thu Sep 22 08:24:25 2022 From: imp at bsdimp.com (Warner Losh) Date: Wed, 21 Sep 2022 16:24:25 -0600 Subject: [TUHS] Early BSD license thread In-Reply-To: References: <202209212149.28LLnV1J032395@ultimate.com> Message-ID: On Wed, Sep 21, 2022 at 4:09 PM Rich Salz wrote: > Recall also that the AT&T code was protected by "trade secret" claims, so > that and the Berne convention meant a copyright on each file wasn't needed. > As the copyright moved to being used as a license, doing so became more > important. > Indeed. The lack of copyright notices prior to Berne was also a big problem for enforcing copyright claims, which is why most companies relied on trade secrets prior to the mid 80s. It's a big reason, I think, the settlement punted on trade secret protections, but made a big deal about respecting each other's copyrights (despite preliminary rulings casting doubt in that area). Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph at josephholsten.com Thu Sep 22 08:44:29 2022 From: joseph at josephholsten.com (Joseph Holsten) Date: Wed, 21 Sep 2022 15:44:29 -0700 Subject: [TUHS] Early BSD license thread In-Reply-To: References: Message-ID: > On Sep 21, 2022, at 15:18, Steve Nickolas wrote: > > On Wed, 21 Sep 2022, Dan Cross wrote: > >>> On Wed, Sep 21, 2022 at 5:50 PM Phil Budne wrote: >>> Not to excuse the failure of the BSD team to properly attribute source >>> origin by adding only their copyright notice, but didn't AT&T try >>> unfair turnabout by not properly attributing the origins of their >>> TCP/IP code? >> >> One of my favorite copyright notices was for /bin/true in System V. >> An empty file got turned into 7 lines of comments holding copyright >> boilerplate and an `#ident` line with an SCCS version number: >> progress! >> >> - Dan C. >> > > And then when I wrote it for my own project: > > true - > > #!/bin/sh > # Does something this small need a license? - SVN > exit 0 > > false - > > #!/bin/sh > # Does something this small need a license? - SVN > exit 1 > > -uso. I’ve thought of this example many times when the 9fans minimalists talk about empty-file `true` impls. Which of course would lead to the 3.8k reported issues of https://github.com/kelseyhightower/nocode -- ~j -------------- next part -------------- An HTML attachment was scrubbed... URL: From chet.ramey at case.edu Thu Sep 22 09:53:32 2022 From: chet.ramey at case.edu (Chet Ramey) Date: Wed, 21 Sep 2022 19:53:32 -0400 Subject: [TUHS] Early BSD license thread In-Reply-To: References: Message-ID: <0c826dab-52c9-493b-724c-981676926093@case.edu> On 9/21/22 6:44 PM, Joseph Holsten wrote: > I’ve thought of this example many times when the 9fans minimalists talk > about empty-file `true` impls. > > Which of course would lead to the 3.8k reported issues of > https://github.com/kelseyhightower/nocode > My favorites are the ones that ask to add a scripting language to the project. -- ``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 robpike at gmail.com Thu Sep 22 10:32:15 2022 From: robpike at gmail.com (Rob Pike) Date: Thu, 22 Sep 2022 10:32:15 +1000 Subject: [TUHS] Early BSD license thread In-Reply-To: <0c826dab-52c9-493b-724c-981676926093@case.edu> References: <0c826dab-52c9-493b-724c-981676926093@case.edu> Message-ID: Around 1977 I was working/volunteering/studying at the Dynamic Graphics Lab at the University of Toronto, where Unix ran on an 11/45 and we had a bunch of graphics hardware. Doing graphics on a PDP-11 was a challenge, but we managed. (For reference: later Dave Tennenhouse made a 256x256x8bit frame buffer, and that was the size of entire PDP-11 data address space.) Everyone was jealous of the C/A/T phototypesetter that Bell Labs Research used to print their documentation. One Friday evening I had the idea to use our stinky but effective Versatec plotter as an output device for nroff. In just a few hours - our libraries were already pretty good - I had something tolerable running. Tom Duff dropped by and helped make it faster by coding what we would now call the character blitter in assembler. Then Bill Reeves joined in, and Mike Tilson, and by the end of the weekend we had pretty good efficient output. (Still nroff; troff came later, mostly due to Bill I think, who did a lot of work on the character set.) It was grey and blotchy and smelly, but after a Xerox copy it looked pretty good for the time. Ron Baecker, who ran the lab and was the graduate advisor for everyone else - I was just an undergraduate physics student having fun - stopped by on Monday morning and was furious to see us all hammering on the code. Everyone was supposed to be working on their thesis and we had spent the weekend hacking. I was about to be in serious trouble for distracting the graduate students. But then he saw the output and completely changed his tune: "Can I use this to print out my new grant proposal?" For context, consider this: I used the system for my 4th year optics project report. The professor was furious with me for copying someone's work. He did not believe it possible to create output like that (and to be fair, it wasn't possible almost anywhere else). I had to take him to the lab and show him how I did it before he would let me pass the course. Until then, no one had seen a student capable of making text look good. The software went on the Toronto tape, with a top-of-file comment crediting me, Bill, Tom, and Mike. It emerged again from Berkeley with that comment replaced by the Regents' rankling rewrite. When I interviewed at Bell Labs, Dennis Ritchie saw on my resume that I claimed to have worked on the Versatec text output system. He asked why I had bothered, when Berkeley had already done it. "Because we wrote it first, and Berkeley took the credit," I said. Berkeley did tweak it, but honestly it was mostly our work. I didn't care so much about losing credit for the code, but the idea was 100% mine, and for a young punk the loss of credit was upsetting. Later Henry Spencer, another Toronto graduate, explained the story on Usenet. I don't know if he was believed, and through the 1980s it remained the "Berkeley typesetting software." It was all long ago, but seeing that "Regents" comment is, as we say today, triggering. But to be fair to Dennis, he believed me, and maybe that helped me get hired. -rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From akosela at andykosela.com Thu Sep 22 17:08:55 2022 From: akosela at andykosela.com (Andy Kosela) Date: Thu, 22 Sep 2022 09:08:55 +0200 Subject: [TUHS] Early BSD license thread In-Reply-To: References: <202209212149.28LLnV1J032395@ultimate.com> Message-ID: On Thursday, September 22, 2022, Dan Cross wrote: > On Wed, Sep 21, 2022 at 5:50 PM Phil Budne wrote: > > Not to excuse the failure of the BSD team to properly attribute source > > origin by adding only their copyright notice, but didn't AT&T try > > unfair turnabout by not properly attributing the origins of their > > TCP/IP code? > > One of my favorite copyright notices was for /bin/true in System V. > An empty file got turned into 7 lines of comments holding copyright > boilerplate and an `#ident` line with an SCCS version number: > progress! > > That reminds me of the excellent dissertation of Gerald Holzmann on Code Inflation[1]. The situation is even worse now and honestly I don't see it will improve in the future. My take on the code inflation problem is that today without paid "volunteers" (from IBM, Oracle, Google, etc.) a large chunk of our modern software landscape would just collapse. It is not 90s Internet anymore where hobbyists did it for fun, because frankly back then it was fun... Nowadays... not that much. --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Thu Sep 22 18:26:19 2022 From: imp at bsdimp.com (Warner Losh) Date: Thu, 22 Sep 2022 02:26:19 -0600 Subject: [TUHS] Strange Reference on Usenix_77 tape Message-ID: Greetings, I was looking at the various Usenix tapes we have in the TUHS archive, trying to sort them all out. In looking at ug091377.tar.gz in Applications/Usenix_77, I found this paragraph at the end of its read_me " Finally, if we have an executed Harvard License on file and if there is room on your tape, the directory "h" contains the newest (July 1977) release of the HRSTS system. We have also in- cluded the old Toronto release in the directory "t" if it was re- quested from a Toronto licensee." This tape had the 'h' directory, so I'll be playing around with the HRSTS system to see if I can get it booting in TUHS (I didn't know we had this til now)... This tape did not have the 't' directory, however. What is 'the old Toronoto release'? I've not seen references to it so far in the other histories of this early period I've encountered. And does anybody have a copy of it? Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Thu Sep 22 18:42:55 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 22 Sep 2022 02:42:55 -0600 Subject: [TUHS] Strange Reference on Usenix_77 tape In-Reply-To: References: Message-ID: <202209220842.28M8gtYE020021@freefriends.org> For those of us not involved with Unix in 1977, what was the HRSTS system? Thanks, Arnold (Who first met Unix in 1980 :-) Warner Losh wrote: > Greetings, > > I was looking at the various Usenix tapes we have in the TUHS archive, > trying to sort them all out. > > In looking at ug091377.tar.gz in Applications/Usenix_77, I found this > paragraph at the end of its read_me > > " Finally, if we have an executed Harvard License on file and > if there is room on your tape, the directory "h" contains the > newest (July 1977) release of the HRSTS system. We have also in- > cluded the old Toronto release in the directory "t" if it was re- > quested from a Toronto licensee." > > This tape had the 'h' directory, so I'll be playing around with the HRSTS > system to see if I can get it booting in TUHS (I didn't know we had this > til now)... This tape did not have the 't' directory, however. > > What is 'the old Toronoto release'? I've not seen references to it so far > in the other histories of this early period I've encountered. And does > anybody have a copy of it? > > Warner From ralph at inputplus.co.uk Thu Sep 22 19:00:50 2022 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Thu, 22 Sep 2022 10:00:50 +0100 Subject: [TUHS] Strange Reference on Usenix_77 tape In-Reply-To: <202209220842.28M8gtYE020021@freefriends.org> References: <202209220842.28M8gtYE020021@freefriends.org> Message-ID: <20220922090050.9405B200BA@orac.inputplus.co.uk> Hi Arnold, > For those of us not involved with Unix in 1977, what was the > HRSTS system? ‘The Harvard/Radcliffe Student Time-sharing System Terminal Users Guide, 1st edition, September 10, 1974, Center for Research in Computing Technology, Harvard University’. Tucker Taft was involved back then. https://www.adahome.com/Rogues/taft.html https://twitter.com/sttaft -- Cheers, Ralph. From imp at bsdimp.com Fri Sep 23 02:13:38 2022 From: imp at bsdimp.com (Warner Losh) Date: Thu, 22 Sep 2022 10:13:38 -0600 Subject: [TUHS] Strange Reference on Usenix_77 tape In-Reply-To: <20220922090050.9405B200BA@orac.inputplus.co.uk> References: <202209220842.28M8gtYE020021@freefriends.org> <20220922090050.9405B200BA@orac.inputplus.co.uk> Message-ID: On Thu, Sep 22, 2022 at 3:00 AM Ralph Corderoy wrote: > Hi Arnold, > > > For those of us not involved with Unix in 1977, what was the > > HRSTS system? > > ‘The Harvard/Radcliffe Student Time-sharing System Terminal Users Guide, > 1st edition, September 10, 1974, Center for Research in Computing > Technology, Harvard University’. > These are the same folks that also did the LISP that appeared in various 2BSD distributions as well. I had a bit of a sleepless night last night... So I took a look at it and I'm less hopeful about being able to rebuild the system. There's a special C compiler. We have the binaries for it and instructions on how to build the source. But those instructions refer to files that aren't in the system and not in the few historic unix distributions from around that time. At least there's a binary. Next, the kernel lacks the makefiles / build scripts, but so does v6, so maybe that's par for the course. There's a lot of userland changes (for libh and libg), but other than the libraries and a few special progarms (pl1, macro11, link11, etc), so I'm assuming that most of the stock 6th edition could be used. Finally, how do I bootstrap? Is this a "Install v6, and then build our cool stuff" or is that also a missing piece. So there's a number of challenges here.... This was definitely not the era of fully integrated reproducible build systems... Warner > Tucker Taft was involved back then. > https://www.adahome.com/Rogues/taft.html > https://twitter.com/sttaft > > -- > Cheers, Ralph. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Fri Sep 23 03:00:06 2022 From: lars at nocrew.org (Lars Brinkhoff) Date: Thu, 22 Sep 2022 17:00:06 +0000 Subject: [TUHS] Strange Reference on Usenix_77 tape In-Reply-To: (Warner Losh's message of "Thu, 22 Sep 2022 10:13:38 -0600") References: <202209220842.28M8gtYE020021@freefriends.org> <20220922090050.9405B200BA@orac.inputplus.co.uk> Message-ID: <7wczbnwdih.fsf@junk.nocrew.org> Warner Losh wrote: > > For those of us not involved with Unix in 1977, what was the > > HRSTS system? > > ‘The Harvard/Radcliffe Student Time-sharing System Terminal Users Guide, > 1st edition, September 10, 1974, Center for Research in Computing > Technology, Harvard University’. > > These are the same folks that also did the LISP that appeared in > various 2BSD distributions as well. There's a special C compiler. I found a description in a Usenix paper[1], and it really seems to be a lot of "Harvard specials" in there. MACRO-11, LINK-11, DDT, TECO, FILCOM, shell with TENEX file completion, even ECL[2]. To me it looks like a layer of PDP-10 on top of Unix. [1] https://www.usenix.org/system/files/login/articles/login_june_11_unix_news.pdf [2] https://github.com/PDP-10/harvard-ecl From crossd at gmail.com Fri Sep 23 03:44:22 2022 From: crossd at gmail.com (Dan Cross) Date: Thu, 22 Sep 2022 13:44:22 -0400 Subject: [TUHS] Early BSD license thread In-Reply-To: References: <202209212149.28LLnV1J032395@ultimate.com> Message-ID: On Thu, Sep 22, 2022 at 3:08 AM Andy Kosela wrote: > On Thursday, September 22, 2022, Dan Cross wrote: >> On Wed, Sep 21, 2022 at 5:50 PM Phil Budne wrote: >> > Not to excuse the failure of the BSD team to properly attribute source >> > origin by adding only their copyright notice, but didn't AT&T try >> > unfair turnabout by not properly attributing the origins of their >> > TCP/IP code? >> >> One of my favorite copyright notices was for /bin/true in System V. >> An empty file got turned into 7 lines of comments holding copyright >> boilerplate and an `#ident` line with an SCCS version number: >> progress! > > That reminds me of the excellent dissertation of Gerald Holzmann on Code Inflation[1]. The situation is even worse now and honestly I don't see it will improve in the future. My take on the code inflation problem is that today without paid "volunteers" (from IBM, Oracle, Google, etc.) a large chunk of our modern software landscape would just collapse. It is not 90s Internet anymore where hobbyists did it for fun, because frankly back then it was fun... Nowadays... not that much. Indeed. Ted has made this point frequently; Linux for example basically requires corporate sponsors to get new features into the kernel. Sure, some individual might come up with a great idea and implementation that'll make it in, but that's the exception rather than the norm. The flip side is that there's a lot of load-bearing infrastructure that is barely maintained, if at all. This xkcd seems perennially relevant: https://xkcd.com/2347/ I suppose the situation may be summed up as extremes at both ends. In any event, it's not great. - Dan C. From crossd at gmail.com Fri Sep 23 03:49:44 2022 From: crossd at gmail.com (Dan Cross) Date: Thu, 22 Sep 2022 13:49:44 -0400 Subject: [TUHS] Berkeley 11/70 (was Re: Strange Reference on Usenix_77 tape) In-Reply-To: <7wczbnwdih.fsf@junk.nocrew.org> References: <202209220842.28M8gtYE020021@freefriends.org> <20220922090050.9405B200BA@orac.inputplus.co.uk> <7wczbnwdih.fsf@junk.nocrew.org> Message-ID: On Thu, Sep 22, 2022 at 1:00 PM Lars Brinkhoff wrote: > Warner Losh wrote: > > > For those of us not involved with Unix in 1977, what was the > > > HRSTS system? > > > > ‘The Harvard/Radcliffe Student Time-sharing System Terminal Users Guide, > > 1st edition, September 10, 1974, Center for Research in Computing > > Technology, Harvard University’. > > > > These are the same folks that also did the LISP that appeared in > > various 2BSD distributions as well. There's a special C compiler. > > I found a description in a Usenix paper[1], and it really seems to be a > lot of "Harvard specials" in there. MACRO-11, LINK-11, DDT, TECO, > FILCOM, shell with TENEX file completion, even ECL[2]. To me it looks > like a layer of PDP-10 on top of Unix. > > [1] https://www.usenix.org/system/files/login/articles/login_june_11_unix_news.pdf > [2] https://github.com/PDP-10/harvard-ecl Thanks, that was very interesting. Indeed, it sounds like at attempt to bring a TENEX-style user experience to Unix. Also interesting was the short article about, "the Berkeley 11/70 System" with notes from Ken. The description of the UID scheme to separate students from "regular" users and the note that "the group concept is about to disappear" were particularly intriguing; clearly an evolutionary dead end, but striking in that this must have yielded a much greater level of isolation. Also, the note about per-directory quotas (as opposed to per-user/group quotas) was interesting. I wonder what other early attempts at hardening the system for educational environments were made that similarly didn't make it in the long haul, and to what extent such efforts have survived? - Dan C. From bakul at iitbombay.org Fri Sep 23 04:44:37 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Thu, 22 Sep 2022 11:44:37 -0700 Subject: [TUHS] Early BSD license thread In-Reply-To: References: <202209212149.28LLnV1J032395@ultimate.com> Message-ID: <9A2AD8B6-CFAD-4585-B9B2-31341F2D6A17@iitbombay.org> On Sep 22, 2022, at 10:44 AM, Dan Cross wrote: > > On Thu, Sep 22, 2022 at 3:08 AM Andy Kosela wrote: >> On Thursday, September 22, 2022, Dan Cross wrote: >>> On Wed, Sep 21, 2022 at 5:50 PM Phil Budne wrote: >>>> Not to excuse the failure of the BSD team to properly attribute source >>>> origin by adding only their copyright notice, but didn't AT&T try >>>> unfair turnabout by not properly attributing the origins of their >>>> TCP/IP code? >>> >>> One of my favorite copyright notices was for /bin/true in System V. >>> An empty file got turned into 7 lines of comments holding copyright >>> boilerplate and an `#ident` line with an SCCS version number: >>> progress! >> >> That reminds me of the excellent dissertation of Gerald Holzmann on Code Inflation[1]. The situation is even worse now and honestly I don't see it will improve in the future. My take on the code inflation problem is that today without paid "volunteers" (from IBM, Oracle, Google, etc.) a large chunk of our modern software landscape would just collapse. It is not 90s Internet anymore where hobbyists did it for fun, because frankly back then it was fun... Nowadays... not that much. > > Indeed. Ted has made this point frequently; Linux for example > basically requires corporate sponsors to get new features into > the kernel. Sure, some individual might come up with a great > idea and implementation that'll make it in, but that's the exception > rather than the norm. > > The flip side is that there's a lot of load-bearing infrastructure > that is barely maintained, if at all. This xkcd seems perennially > relevant: https://xkcd.com/2347/ > > I suppose the situation may be summed up as extremes at both > ends. In any event, it's not great. Any sufficiently complicated technology is indistinguishable from magic! (apologies for mangling Clarke's Third Law) From clemc at ccc.com Fri Sep 23 06:38:50 2022 From: clemc at ccc.com (Clem Cole) Date: Thu, 22 Sep 2022 16:38:50 -0400 Subject: [TUHS] Strange Reference on Usenix_77 tape In-Reply-To: <7wczbnwdih.fsf@junk.nocrew.org> References: <202209220842.28M8gtYE020021@freefriends.org> <20220922090050.9405B200BA@orac.inputplus.co.uk> <7wczbnwdih.fsf@junk.nocrew.org> Message-ID: On Thu, Sep 22, 2022 at 1:00 PM Lars Brinkhoff wrote: > Warner Losh wrote: > > lot of "Harvard specials" in there. MACRO-11, LINK-11, DDT, TECO, > I ran the macro-11, linker, ddt and teco back in the day, ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sat Sep 24 13:54:45 2022 From: imp at bsdimp.com (Warner Losh) Date: Fri, 23 Sep 2022 21:54:45 -0600 Subject: [TUHS] Strange Reference on Usenix_77 tape In-Reply-To: References: <202209220842.28M8gtYE020021@freefriends.org> <20220922090050.9405B200BA@orac.inputplus.co.uk> <7wczbnwdih.fsf@junk.nocrew.org> Message-ID: On Thu, Sep 22, 2022, 2:39 PM Clem Cole wrote: > > > On Thu, Sep 22, 2022 at 1:00 PM Lars Brinkhoff wrote: > >> Warner Losh wrote: >> >> lot of "Harvard specials" in there. MACRO-11, LINK-11, DDT, TECO, >> > I ran the macro-11, linker, ddt and teco back in the day, > That reminds me... anybody have a good in-process debugger like ddt that can be linked in these days? Warner ᐧ > -------------- next part -------------- An HTML attachment was scrubbed... URL: