I’ve been playing around trying to link the OpenSolaris launch commit to various pieces in the Unix History Repository, and it’s making me wonder if we’ll ever have a chance to see the history of the systems.
I’m less concerned about HPUX, AIX and SCO’s offerings since I presume someone has copy inside these companies. But what about A/UX, Irix, Tru64? Did these ever get sold with licenses to source tapes? Are there copies we need to preserve in-camera so something can exist 120 years after creation or whenever copyright expires?
--
Joseph Holsten
http://josephholsten.com
mailto:joseph@josephholsten.com
tel:+1-360-927-7234
Hi All,
Is this the only bootable 3bsd distribution tape we have?
http://sourceforge.net/projects/bsd42/files/Install%20tapes/3%20BSD/3bsd.ta…
I don't like the idea that sourceforge is the only source, the
provenance is unclear and I'm just not a big fan of how sourceforge
handles downloads generally.
I've found tarballs, but not tapes on TUHS.
Thanks,
Will
Hello All.
Nelson Beebe has added PDF files for all the .ps files that didn't
have them, and I did a little bit more cleaning up of the CSTRs
I made available late last week. The new file is at
https://www.skeeve.com/combined-cstr-2.tar.gz
Warren will eventually add them to the archive, at which point I will
probably take down my copies.
Nelson and I request of the CSTR authors who are on the TUHS list if
they are willing to make source code for their CSTRs available? That
would certainly help in the preservation effort.
Thanks,
Arnold
Yesterday, Arnold Robbins kindly posted to this list a link to a
bundle of Bell Labs Computing Science Technical Reports that he had,
luckily for us, and for Unix, IX, and Plan 9 history, preserved in his
personal library.
There are 67 distinct report numbers in the bundle, and 79 different
files.
Today, I completed a merger of data from all of those reports into the
BibTeX entries in the extensive bibliography at
https://www.math.utah.edu/pub/tex/bib/unix.bibhttps://www.math.utah.edu/pub/tex/bib/unix.html
Arnold's bundle has mostly PostScript files, but some also have PDF
companions. I expect to make PDF versions available for all of them
in the TUHS archives, but for now, the new BibTeX entries do not yet
have suitable URLs for their retrieval. URLs will be retrofitted once
the files are widely available in TUHS mirrors.
Some of the reports had already been recorded in unix.bib; those that
had not carry a value "Fri Aug 25" in the bibdate string, making them
easy to find with a text editor, or with an SQL search in the
companion SQLite3 database at
https://www.math.utah.edu/pub/tex/bib/unix.db
For example,
% sqlite3 unix.db
sqlite> .mode table
sqlite> select label, title from bibtab
where bibtimestamp like '2023.08.25%'
order by number;
For TUHS member convenience, here is a summary from unix.bib of the
thus-far-recorded Bell Labs report numbers, their year (several are
undated, and thus assigned 19xx), their page counts, and their titles,
ordered by increasing report numbers, with column widths chosen to
limit lines to 80 characters:
sqlite> .mode table
sqlite> .width -4 4 -8 51
sqlite> select number, year, pages, title from bibtab
where (filename = 'unix.bib')
and (type = 'Computing Science Technical Report')
order by 0 + number;
+------+------+----------+-----------------------------------------------------+
| numb | year | pages | title |
+------+------+----------+-----------------------------------------------------+
| 2 | 1972 | ii + 13 | The M6 Macro Processor |
+------+------+----------+-----------------------------------------------------+
| 33 | 1975 | ii + 18 | A User's Guide to DODES, a Double Precision Ordinar |
| | | | y Differential Equation Solver |
+------+------+----------+-----------------------------------------------------+
| 52 | 1976 | ii + 36 | A Tutorial on Galerkin's Method, using on B-splines |
| | | | , for Solving Differential Equations |
+------+------+----------+-----------------------------------------------------+
| 53 | 1976 | ii + 44 | Numerical Solution of Time-Varying Partial Differen |
| | | | tial Equations in One Space Variable |
+------+------+----------+-----------------------------------------------------+
| 54 | 1992 | ii + 35 | Troff User's Manual |
+------+------+----------+-----------------------------------------------------+
| 89 | 1981 | ii + 64 | A Test of a Computer's Floating-Point Arithmetic Un |
| | | | it |
+------+------+----------+-----------------------------------------------------+
| 97 | 1982 | ii + 13 | A Typesetter-independent TROFF |
+------+------+----------+-----------------------------------------------------+
| 100 | 1981 | ii + 14 | Why Pascal is Not My Favorite Programming Language |
+------+------+----------+-----------------------------------------------------+
| 102 | 1981 | 12 | The C Language Calling Sequence |
+------+------+----------+-----------------------------------------------------+
| 103 | 1981 | ii + 25 | IDEAL User's Manual |
+------+------+----------+-----------------------------------------------------+
| 106e | 1979 | 34 | BPSS |
+------+------+----------+-----------------------------------------------------+
| 106d | 1993 | 34 | BASS |
+------+------+----------+-----------------------------------------------------+
| 106f | 1993 | 13 | CSWAP with X and Y declared complex |
+------+------+----------+-----------------------------------------------------+
| 106b | 1993 | 36 | GESS |
+------+------+----------+-----------------------------------------------------+
| 106a | 1993 | i + 10 | Programs for Solving Linear Equations in the PORT L |
| | | | ibrary |
+------+------+----------+-----------------------------------------------------+
| 106c | 1993 | 30 | SYSS |
+------+------+----------+-----------------------------------------------------+
| 114 | 1991 | ii + 37 | Grap --- A Language for Typesetting Graphs Tutorial |
| | | | and User Manual |
+------+------+----------+-----------------------------------------------------+
| 115 | 1991 | ii + 25 | PIC --- A Graphics Language for Typesetting User Ma |
| | | | nual |
+------+------+----------+-----------------------------------------------------+
| 117 | 1985 | ii + 2 | A Weakness in the 4.2BSD Unix TCP/IP Software |
+------+------+----------+-----------------------------------------------------+
| 118 | 1985 | ii ++ 38 | Awk --- A Pattern Scanning and Processing Language |
| | | | Programmer's Manual |
+------+------+----------+-----------------------------------------------------+
| 120 | 1985 | ii + 19 | Twig Reference Manual |
+------+------+----------+-----------------------------------------------------+
| 122 | 1992 | ii + 31 | CHEM --- a Program for Typesetting Chemical Diagram |
| | | | s: User Manual |
+------+------+----------+-----------------------------------------------------+
| 123 | 1989 | 29 | C Traps and Pitfalls |
+------+------+----------+-----------------------------------------------------+
| 127 | 1991 | 10 | Maintaining Cross References in Manuscripts |
+------+------+----------+-----------------------------------------------------+
| 128 | 1986 | ii + 13 | Tools for Printing Indexes |
+------+------+----------+-----------------------------------------------------+
| 132 | 1991 | ii + 24 | A System for Algorithm Animation Tutorial and User |
| | | | Manual |
+------+------+----------+-----------------------------------------------------+
| 133 | 1989 | ii + 63 | AMPL: A Mathematical Programming Language |
+------+------+----------+-----------------------------------------------------+
| 135 | 1985 | i + 73 | tt TTGR --- A Package for Solving Partial Different |
| | | | ial Equations in Two Space Variables |
+------+------+----------+-----------------------------------------------------+
| 136 | 1987 | i + 46 | Pictures of Karmarkar s Linear Programming Algorith |
| | | | m |
+------+------+----------+-----------------------------------------------------+
| 142 | 1988 | i + 13 | DFORMAT --- a Program for Typesetting Data Formats |
+------+------+----------+-----------------------------------------------------+
| 143 | 1993 | ii + 13 | Newsqueak: A Language for Communicating with Mice |
+------+------+----------+-----------------------------------------------------+
| 145 | 1992 | ii + 111 | A Permuted Index for TeX and LaTeX |
+------+------+----------+-----------------------------------------------------+
| 148 | 1991 | i + 42 | Generating Automatically-Tuned Bitmaps from Outline |
| | | | s |
+------+------+----------+-----------------------------------------------------+
| 149 | 1995 | i + 25 | A Fortran-to-C Converter |
+------+------+----------+-----------------------------------------------------+
| 150 | 1990 | 10 | Terminal Call Processing in Esterel |
+------+------+----------+-----------------------------------------------------+
| 153 | 1990 | i + 21 | Usage Summary for Selected Optimization Routines |
+------+------+----------+-----------------------------------------------------+
| 154 | 1990 | i + 52 | tt TTGU --- A Package for Solving Time Varying Part |
| | | | ial Differential Equations on a Union of Rectangles |
+------+------+----------+-----------------------------------------------------+
| 155 | 19xx | 29 | There Is No Royal Road to Programs: A Trilogy on Ra |
| | | | ster Ellipses and Programming Methodology |
+------+------+----------+-----------------------------------------------------+
| 157 | 1991 | ii + 39 | Tutorial: Design and Validation of Protocols |
+------+------+----------+-----------------------------------------------------+
| 158g | 19xx | 14 | Rc --- A Shell for Plan 9 and UNIX Systems |
+------+------+----------+-----------------------------------------------------+
| 158b | 19xx | 9 | Plan 9 from Bell Labs |
+------+------+----------+-----------------------------------------------------+
| 158a | 19xx | 1 | Plan 9: The Early Papers |
+------+------+----------+-----------------------------------------------------+
| 158f | 19xx | 6 | Process Sleep and Wakeup on a Shared-memory Multipr |
| | | | ocessor |
+------+------+----------+-----------------------------------------------------+
| 158d | 19xx | 9 | $ 8 1 over 2 $, the Plan 9 Window System |
+------+------+----------+-----------------------------------------------------+
| 158e | 19xx | 10 | Multiprocessor Streams for Plan 9 |
+------+------+----------+-----------------------------------------------------+
| 158c | 19xx | 7 | Plan 9, A Distributed System |
+------+------+----------+-----------------------------------------------------+
| 158h | 19xx | 12 | A New C Compiler |
+------+------+----------+-----------------------------------------------------+
| 159 | 19xx | 15 | Efficient Algorithms for Constructing Testing Sets, |
| | | | Covering Paths, and Minimum Flows |
+------+------+----------+-----------------------------------------------------+
| 160 | 1991 | 21 | What is ``Object-Oriented Programming''? |
+------+------+----------+-----------------------------------------------------+
| 161 | 19xx | 19 | Sixteen Ways to Stack a Cat |
+------+------+----------+-----------------------------------------------------+
| 162 | 19xx | 91 | A User's Manual for MetaPost |
+------+------+----------+-----------------------------------------------------+
| 163i | 1992 | 50 | GETLAB |
+------+------+----------+-----------------------------------------------------+
| 163 | 1992 | 1 | The IX Multilevel-Secure UNIX System |
+------+------+----------+-----------------------------------------------------+
| 163h | 19xx | 2 | Glossary |
+------+------+----------+-----------------------------------------------------+
| 163d | 19xx | 12 | The Design of IX |
+------+------+----------+-----------------------------------------------------+
| 163c | 19xx | 19 | Multilevel Security in the UNIX Tradition |
+------+------+----------+-----------------------------------------------------+
| 163f | 19xx | 3 | Multilevel Windows on a Single-level Terminal |
+------+------+----------+-----------------------------------------------------+
| 163e | 19xx | 11 | A Tour of IX |
+------+------+----------+-----------------------------------------------------+
| 163b | 19xx | 1 | The IX Multilevel-Secure UNIX System |
+------+------+----------+-----------------------------------------------------+
| 163g | 19xx | 8 | Secure IX Network |
+------+------+----------+-----------------------------------------------------+
| 164 | 19xx | i + 20 | Drawing Graphs with MetaPost |
+------+------+----------+-----------------------------------------------------+
Here is a table of authors:
sqlite> .width -4 4 62
sqlite> .output foo.out.6
sqlite> select number, year, author from bibtab
where (filename = 'unix.bib')
and (type = 'Computing Science Technical Report')
order by 0 + number;
+------+------+----------------------------------------------------------------+
| numb | year | author |
+------+------+----------------------------------------------------------------+
| 2 | 1972 | Andrew D. Hall |
+------+------+----------------------------------------------------------------+
| 33 | 1975 | Norman L. Schryer |
+------+------+----------------------------------------------------------------+
| 52 | 1976 | Norman L. Schryer |
+------+------+----------------------------------------------------------------+
| 53 | 1976 | Norman L. Schryer |
+------+------+----------------------------------------------------------------+
| 54 | 1992 | Joseph F. Ossanna and Brian W. Kernighan |
+------+------+----------------------------------------------------------------+
| 89 | 1981 | Norman L. Schryer |
+------+------+----------------------------------------------------------------+
| 97 | 1982 | Brian W. Kernighan |
+------+------+----------------------------------------------------------------+
| 100 | 1981 | Brian W. Kernighan |
+------+------+----------------------------------------------------------------+
| 102 | 1981 | Steven C. Johnson and Dennis M. Ritchie |
+------+------+----------------------------------------------------------------+
| 103 | 1981 | Christopher J. Van Wyk |
+------+------+----------------------------------------------------------------+
| 106e | 1979 | Linda Kaufman |
+------+------+----------------------------------------------------------------+
| 106d | 1993 | Linda Kaufman |
+------+------+----------------------------------------------------------------+
| 106f | 1993 | Linda Kaufman |
+------+------+----------------------------------------------------------------+
| 106b | 1993 | Linda Kaufman |
+------+------+----------------------------------------------------------------+
| 106a | 1993 | Linda Kaufman |
+------+------+----------------------------------------------------------------+
| 106c | 1993 | Linda Kaufman |
+------+------+----------------------------------------------------------------+
| 114 | 1991 | Jon L. Bentley and Brian W. Kernighan |
+------+------+----------------------------------------------------------------+
| 115 | 1991 | Brian W. Kernighan |
+------+------+----------------------------------------------------------------+
| 117 | 1985 | Robert T. Morris |
+------+------+----------------------------------------------------------------+
| 118 | 1985 | Alfred V. Aho and Brian W. Kernighan and Peter 3. Weinberger |
+------+------+----------------------------------------------------------------+
| 120 | 1985 | Steven W. K. Tjiang |
+------+------+----------------------------------------------------------------+
| 122 | 1992 | Jon L. Bentley and Lynn W. Jelinski and Brian W. Kernighan |
+------+------+----------------------------------------------------------------+
| 123 | 1989 | Andrew Koenig |
+------+------+----------------------------------------------------------------+
| 127 | 1991 | Alfred V. Aho and Ravi Sethi |
+------+------+----------------------------------------------------------------+
| 128 | 1986 | Jon L. Bentley and Brian W. Kernighan |
+------+------+----------------------------------------------------------------+
| 132 | 1991 | Jon L. Bentley and Brian W. Kernighan |
+------+------+----------------------------------------------------------------+
| 133 | 1989 | Robert Fourer and David M. Gay and Brian W. Kernighan |
+------+------+----------------------------------------------------------------+
| 135 | 1985 | Linda Kaufman and Norman L. Schryer |
+------+------+----------------------------------------------------------------+
| 136 | 1987 | David M. Gay |
+------+------+----------------------------------------------------------------+
| 142 | 1988 | J. L. Bentley |
+------+------+----------------------------------------------------------------+
| 143 | 1993 | Rob Pike |
+------+------+----------------------------------------------------------------+
| 145 | 1992 | Bill Cheswick |
+------+------+----------------------------------------------------------------+
| 148 | 1991 | John D. Hobby |
+------+------+----------------------------------------------------------------+
| 149 | 1995 | S. I. Feldman and David M. Gay and Mark W. Maimone and N. L. S |
| | | chryer |
+------+------+----------------------------------------------------------------+
| 150 | 1990 | Gary J. Murakami and Ravi Sethi |
+------+------+----------------------------------------------------------------+
| 153 | 1990 | David M. Gay |
+------+------+----------------------------------------------------------------+
| 154 | 1990 | Linda Kaufman |
+------+------+----------------------------------------------------------------+
| 155 | 19xx | M. Douglas McIlroy |
+------+------+----------------------------------------------------------------+
| 157 | 1991 | Gerard J. Holzmann |
+------+------+----------------------------------------------------------------+
| 158g | 19xx | Tom Duff |
+------+------+----------------------------------------------------------------+
| 158b | 19xx | Rob Pike and Dave Presotto and Ken Thompson and Howard Trickey |
+------+------+----------------------------------------------------------------+
| 158a | 19xx | Rob Pike and Dave Presotto and Ken Thompson and Howard Trickey |
| | | and Tom Duff and Gerard Holzmann |
+------+------+----------------------------------------------------------------+
| 158f | 19xx | Rob Pike and Dave Presotto and Ken Thompson and Gerard Holzman |
| | | n |
+------+------+----------------------------------------------------------------+
| 158d | 19xx | Rob Pike |
+------+------+----------------------------------------------------------------+
| 158e | 19xx | David Leo Presotto |
+------+------+----------------------------------------------------------------+
| 158c | 19xx | Dave Presotto and Rob Pike and Ken Thompson and Howard Trickey |
+------+------+----------------------------------------------------------------+
| 158h | 19xx | Ken Thompson |
+------+------+----------------------------------------------------------------+
| 159 | 19xx | Alfred V. Aho and David Lee |
+------+------+----------------------------------------------------------------+
| 160 | 1991 | Bjarne Stroustrup |
+------+------+----------------------------------------------------------------+
| 161 | 19xx | Bjarne Stroustrup |
+------+------+----------------------------------------------------------------+
| 162 | 19xx | John D. Hobby |
+------+------+----------------------------------------------------------------+
| 163i | 1992 | Anonymous |
+------+------+----------------------------------------------------------------+
| 163 | 1992 | James A. Reeds and M. Douglas McIlroy |
+------+------+----------------------------------------------------------------+
| 163h | 19xx | Anonymous |
+------+------+----------------------------------------------------------------+
| 163d | 19xx | M. D. McIlroy and J. A. Reeds |
+------+------+----------------------------------------------------------------+
| 163c | 19xx | M. D. McIlroy and J. A. Reeds |
+------+------+----------------------------------------------------------------+
| 163f | 19xx | M. D. McIlroy and J. A. Reeds |
+------+------+----------------------------------------------------------------+
| 163e | 19xx | Doug McIlroy and Jim Reeds |
+------+------+----------------------------------------------------------------+
| 163b | 19xx | James A. Reeds and M. Douglas McIlroy |
+------+------+----------------------------------------------------------------+
| 163g | 19xx | Jim Reeds |
+------+------+----------------------------------------------------------------+
| 164 | 19xx | John D. Hobby |
+------+------+----------------------------------------------------------------+
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah -
- Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu -
- 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
Hello, I've been doing some research on the history of disassembly lately, tools available historically, today, and what sorts of developments have been made regarding utilities and systems for taking a machine-code binary and working it back to some semblance of source code.
So in the early days UNIX had das(I), a PDP-11 disassembler I believe written by Ken (he's OWNER in the manual) with very little information other than "it exists". Fast forward to the UNIX 4.1 manual in 1981 for the 3B20S and there is dis(1), a 3B20 disassembler. Other such manuals feature dis(1) versions for other 3B targets.
Was a disassembler ever considered part of the standard binary objects toolkit with the assembler, linker, etc. or was that the sort of thing that was more niche and therefore just kinda cropped up when/if someone decided to write one? Were there legal concerns to be grappled with when producing a disassembler? Were such tools ever shipped or did they only appear in the manuals as they were technically up in the code base, just not commonly distributed or used? Also, was there any thought given during the development of C to producing "decompilers" as has been becoming more common lately? Or was it a foregone conclusion that C to assembly is a "lossy" conversion and going the other direction couldn't be fully automated.
Thank you for any insights!
- Matt G.
Does anyone collect old Linux drivers? I just found one for the
"Backpack CD" which was a CD-ROM reader that would attach to a PC
via the parallel port. This is from April and May 1997. Before I nuke
the code, I thought I'd ask if there is anyone who collects such things.
Feel free to reply privately.
Thanks,
Arnold
Hello Folks,
A while back I made avaiable a tarball of two directories I had
of Bell Labs CSTRs (Computing Science Technical Reports). There
was some overlap between them, and at the time I didn't have the
free time to go through and weed through the duplicates.
I have now done that. There is a new tar file available at
https://www.skeeve.com/combined-cstr.tar.gz
Warren, please add this to the TUHS archives.
Enjoy,
Arnold
I thought folks on COFF and TUHS (Bcc'ed) might find this interesting.
Given the overlap between SDF and LCM+L, I wonder what this may mean
for the latter.
- Dan C.
---------- Forwarded message ---------
From: SDF Membership <membership(a)sdf.org>
Date: Thu, Aug 24, 2023 at 9:10 PM
Subject: [SDF] Computer Museum
To:
We're in the process of opening a computer museum in the Seattle area
and are holding our first public event on September 30th - October 1st.
The museum features interactive exhibits of various vintage computers
with a number of systems remotely accessible via telnet/ssh for those
who are unable to visit in person.
If this interests you, please consider replying with comments and
take the ascii survey below. You can mark an X for what interests you.
I would like to know more about:
[ ] visiting the museum
[ ] how to access the remote systems
[ ] becoming a regular volunteer or docent
[ ] restoring and maintaining various vintage systems
[ ] curation and exhibit design
[ ] supporting the museum with an annual membership
[ ] supporting the museum with an annual sponsorship
[ ] funding the museum endowment
[ ] day to day administration and operations
[ ] hosting an event or meet up at museum
[ ] teaching at the museum
[ ] donating an artifact
Info on our first public event can be found at https://sdf.org/icf
I finally got an Emacs running on v7--it's on misspiggy at LCML now as "ue".
It's Microemacs 3.6; what I did was to clone
https://github.com/troglobit/MicroEMACS and check out the first commit.
Some experimentation later, it had the usual problem with v7 and DEC
linkers that not all the function names (er, more generally exported
symbols, but in this case, function names) were unique in the first 7
characters (which is 6 if you're working with DEC OSes). So a bit of sed
later and I had something that built, linked, and appears to run with
TERM=vt100 set.
Arrow keys, naturally, don't work, but C-b, C-f, C-p, C-n do.
I think I'm going to just make a GH repo of it, but I'm happy to send the
tarball, or tar.uue, upon request. I find UUCP kinda fragile on my simh
installation, and I don't know how to get to Miss Piggy's (although the
uucp commands are there), so, well, uuencoding, a pasteboard buffer,
iTerm2's "Paste Slowly", and cat will work as a file transfer mechanism.
Adam
[This posting was sent earlier today to some local lists, but may also
be of interest to TUHS members.]
The UofUtah lost one its significant alumni, John Warnock, on Saturday.
John received Bachelor's and Master's degrees from the Department of
Mathematics, and his doctoral degree from the Department of Electrical
Engineering.
After jobs at Evans & Sutherland in Salt Lake City, and Xerox PARC
labs in Palo Alto, CA, he later went on to co-found Adobe Systems with
Chuck Geschke (1939--2021), and the PostScript, PDF, and font
technologies, and many others, that came from their company changed
the publishing model of the entire world.
See
https://www.cs.utah.edu/adobe-co-founder-and-kahlert-school-of-computing-al…https://www.ksl.com/article/50713319/adobe-co-founder-utah-native-john-warn…https://www.adobe.com/https://en.wikipedia.org/wiki/Charles_Geschkehttps://en.wikipedia.org/wiki/John_Warnock
John's doctoral thesis is available at:
https://www.proquest.com/pqdtglobal/docview/302478116/2F149E6F459946B7PQ
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah -
- Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu -
- 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
> From: Paul Ruizendaal <pnr(a)planet.nl>
> a token ring driver (written by Noel Chiappa, if I remember well).
No (unless they took one I wrote for the V6 machine and adapted it); I never
did anything on any Unix after V6 (I think there's nothing of any significant
interest in any later Unix).
Anyway, writing a driver for that board would be about as much work as
writing a driver for an RK11 controller - i.e. a day or so for someone
competent.
Noel
> Date: Thu, 10 Aug 2023 03:17:25 +0000
> From: segaloco
>
>>>> TCP/IP, not datakit
>
>
> All of the files that have timestamps at the top list 83/07/29, except ip_input.c which has 83/08/16 instead. The V8 version has _device (device driver) and _ld (line discipline) components that the 4.1cBSD code does not have. Many other files have analogs between the two. The byte ordering subroutines have been copied into a file, goo.s, from their home in 4.1cBSD in the C library (/usr/src/lib/libc/net/misc). When this work originated someone else would need to answer, [...]
As far as I can tell the history of this code line goes back to 1977, when Jack Haverty at BBN wrote a TCP/IP library (porting earlier work written in PDP-11 assembler) for a slightly modified 6th Edition Unix. Fighting with 64KB core limits, throughput was horrific and he concluded that a bigger PDP-11 was needed. Mike Wingfield then did a re-implementation in C for a PDP-11/70. This worked in early 1979 and is arguably the first Unix TCP/IP stack that can still interoperate with current IPv4. However, it was still mostly a proof of concept user mode design (it was funded as a test vehicle for the later abandoned Autodin-II fork of TCP).
BBN then got a contract to write a kernel mode TCP/IP stack for 4BSD (“VAX TCP” in the old BBN doc’s). This work was performed by Rob Gurwitz under supervision of Jack Haverty. This stack - although all new code - still showed its heritage: it was designed as a loosely bound kernel process providing the NCP-Unix API. Some sources seem to imply that it was developed first as a user mode process and once working in that context changed into a kernel process / thread. Beta releases were available in 1981. It worked (and interoperates with modern IPv4), but in my experiments a few years back it turned out that it is difficult to get the scheduling for this kernel process right at higher system loads.
Bill Joy of CSRG concluded that the BBN stack did not perform according to his expectations. Note that CSRG was focused on usage over (thick) ethernet links, and BBN was focused on usage over Arpanet and other wide-area networks (with much lower bandwidth, and higher latency and error rates). He then in 1982 rewrote the stack to match the CSRG environment, changing the design to use software interrupts instead of a kernel thread and optimising the code (e.g. checksumming and fast code paths). It was a matter of debate how new the code was, with the extremes being that it was written from scratch using the spec versus it being mostly copied. Looking at it with a nearly 50 year distance, it seems in between: small bits of surviving SCCS suggest CSRG starting with parts of BBN code followed by rapid, massive modification; the end result is quite different but retained the ‘mbuf’ core data structure and a BBN bug (off-by-one for OOB TCP segments).
The shift from the NCP-Unix API to sockets is separate from this and was planned. CSRG had the contract to develop a new API for facilitating distributed systems with Unix and this gelled into the sockets interface. The first prototypes for this were done in 1981.
Nearly all of the above source is available in the TUHS online Unix Tree (Wingfield, VAX-TCP and two early versions from CSRG - one in 2.9BSD and one in 4.1cBSD).
Good morning folks, just sharing some eBay sales I spotted that are just not in the cards for me, both in terms of expense and I just don't have the bandwidth to focus on other UNIX lines right now.
That said, someone is selling a very, very large collection of HP-UX documents:
https://www.ebay.com/itm/285425883705https://www.ebay.com/itm/285425882004
As mentioned, quite pricy, and bulky too. However, if anyone knows anyone with a particular eye for HP-UX history, this may interest them. No idea what is and isn't preserved there, non-Bell-and-UCB stuff hasn't been on my radar hardly at all other than acknowledging it exists.
Tangential but I do appreciate the consistency in their documentation appearance. I see HP-UX stuff pop up time to time and the cover motif is identical to the documents they published with analytical equipment like gas chromatographs before spinning that unit off into Agilent.
- Matt G.
> Warner Losh imp at bsdimp.com
> Thu Aug 10 12:45:54 AEST 2023
> wrote:
>
> Yea, I thought it was 4.1bsd + later tcp code but with a STREAMS instead of
> Socket interface...
Please see this old TUHS post for some more background in DMR’s own words:
https://www.tuhs.org/pipermail/tuhs/2019-August/018325.html
On the topic of DMR Streams, I’m increasingly intrigued by its design: recently I’ve been deep diving into classic USB to better understand this class of devices and how to drive them (https://gitlab.com/pnru/usb_host) It would seem to me that Streams would have been a neat way to organise the USB driver stack in a v8 context. Note that an USB analog did exist in 1982: https://en.wikipedia.org/wiki/Hex-Bus
Sometimes I wonder what combining v8 streams with v8 virtual directories (i.e. like Killian’s /proc) could have looked like. Having the streams network stack (or usb stack) exposed as virtual directories would have been quite powerful.
Sorry if this has been asked before, but:
"Welcome to Eighth Edition Unix. You may be sure that it
is suitably protected by ironclad licences, contractual agreements,
living wills, and trade secret laws of every sort. A trolley car is
certain to grow in your stomach if you violate the conditions
under which you got this tape. Consult your lawyer in case of any doubt.
If doubt persists, consult our lawyers.
Please commit this message to memory. If this is a hardcopy terminal,
tear off the paper and affix it to your machine. Otherwise
take a photo of your screen. Then delete /etc/motd.
Thank you for choosing Eighth Edition Unix. Have a nice day."
was this one person or a group effort. It's wonderful.
six years later…
A note for the list:
Warren (in. IMHO, a stroke of genius) changed the Repo from xv6-minix to xv6-freebsd.
<https://github.com/DoctorWkt/xv6-freebsd>
--
Steve Jenkin, IT Systems and Design
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA
mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin
At the risk of releasing more heat than light (so if you feel
compelled to flame by this message, please reply just to me
or to COFF, not to TUHS):
The fussing here over Python reminds me very much of Unix in
the 1980s. Specifically wars over editors, and over BSD vs
System V vs Research systems, and over classic vs ISO C, and
over embracing vendor-specific features (CSRG and USG counting
as vendors as well as Digital, SGI, Sun, et al) vs sticking
to the common core. And more generally whether any of the
fussing is worth it, and whether adding stuff to Unix is
progress or just pointless complication.
Speaking as an old fart who no longer gets excited about this
stuff except where it directly intersects something I want to
do, I have concluded that nobody is entirely right and nobody
is entirely wrong. Fancy new features that are there just to
be fancy are usually a bad idea, especially when they just copy
something from one system to a completely different one, but
sometimes they actually add something. Sometimes something
brand new is a useful addition, especially when its supplier
takes the time and thought to fit cleanly into the existing
ecosystem, but sometimes it turns out to be a dead end.
Personal taste counts, but never as much as those of us
brandishing it like to think.
To take Python as an example: I started using it about fifteen
years ago, mostly out of curiousity. It grew on me, and these
days I use it a lot. It's the nearest thing to an object-
oriented language that I have ever found to be usable (but I
never used the original Smalltalk and suspect I'd have liked
that too). It's not what I'd use to write an OS, nor to do
any sort of performance-limited program, but computers and
storage are so fast these days that that rarely matters to me.
Using white space to denote blocks took a little getting used
to, but only a little; no more than getting used to typing
if ...: instead of if (...). The lack of a C-style for loop
occasionally bothers me, but iterating over lists and sets
handles most of the cases that matter, and is far less cumbersome.
It's a higher-level language than C, which means it gets in the
way of some things but makes a lot of other things easier. It
turns out the latter is more significant than the former for
the things I do with it.
The claim that Python doesn't have printf (at least since ca. 2.5,
when I started using it) is just wrong:
print 'pick %d pecks of %s' % (n, fruit)
is just a different spelling of
printf("pick %d pecks of %s\n", n, fruit)
except that sprintf is no longer a special case (and snprintf
becomes completely needless). I like the modern
print(f'pick {n} pecks of {fruit}')
even better; f strings are what pushed me from Python 2 to
Python 3.
I really like the way modules work in Python, except the dumbass
ways you're expected to distribute a program that is broken into
modules of its own. As a low-level hacker I came up with my own
way to do that (assembling them all into a single Python source
file in which each module is placed as a string, evaled and
inserted into the module table, and then the starting point
called at the end; all using documented, stable interfaces,
though they changed from 2 to 3; program actually written as
a collection of individual source files, with a tool of my
own--written in Python, of course--to create the single file
which I can then install where I need it).
I have for some years had my own hand-crafted idiosyncratic
program for reading mail. (As someone I know once said,
everybody writes a mailer; it's simple and easy and makes
them feel important. But in this case I was doing it just
for myself and for the fun of it.) The first edition was
written 20 years ago in C. I rewrote it about a decade ago
in Python. It works fine; can now easily deal with on-disk
or IMAP4 or POP3 mailboxes, thanks both to modules as a
concept and to convenient library modules to do the hard work;
and updating in the several different work and home environments
where I use it no longer requires recompiling (and the source
code need no longer worry about the quirks of different
compilers and libraries); I just copy the single executable
source-code file to the different places it needs to run.
For me, Python fits into the space between shell scripts and
awk on one hand, and C on the other, overlapping some of the
space of each.
But personal taste is relevant too. I didn't know whether I'd
like Python until I'd tried it for a few real programs (and
even then it took a couple of years before I felt like I'd
really figured out out to use it). Just as I recall, about
45 years ago, moving from TECO (in which I had been quite
expert) to ed and later the U of T qed and quickly feeling
that ed was better in nearly every way; a year or so later,
trying vi for a week and giving up in disgust because it just
didn't fit my idea of how screen editors should work; falling
in love with jim and later sam (though not exclusively, I still
use ed/qed daily) because they got the screen part just right
even if their command languages weren't quite such a good match
for me.
And I have never cottoned on to Perl for, I suspect, the same
reason I'd be really unhappy to go back to TECO. Tastes
evolve. I bet there's a lot of stuff I did in the 1980s that
I'd do differently could I have another go at it.
The important thing is to try new stuff. I haven't tried Go
or Rust yet, and I should. If you haven't given Python or
Perl a good look, you should. Sometimes new tools are
useless or cumbersome, sometimes they are no better than
what you've got now, but sometimes they make things easier.
You won't know until you try.
Here endeth today's sermon from the messy office, which I ought
to be cleaning up, but preaching is more fun.
Norman Wilson
Toronto ON
I’m re-reading Brian Kernighan’s book on Early Unix (‘Unix: A History & Memoir’)
and he mentions the (on disk) documentation that came with Unix - something that made it stand out, even for some decades.
Doug McIlroy has commented on v2-v3 (1972-73?) being an extremely productive year for Ken & Dennis.
But as well, they wrote papers and man pages, probably more.
I’ve never heard anyone mention keyboard skills with the people of the CSRC - doesn’t anyone know?
There’s at least one Internet meme that highly productive coders necessarily have good keyboard skills,
which leads to also producing documentation or, at least, not avoiding it entirely, as often happens commercially.
Underlying this is something I once caught as a random comment:
The commonality of skills between Writing & Coding.
Does anyone has any good refs for this crossover?
Is it a real effect or a biased view.
That great programmers are also “good writers”:
takes time & focus, clarity of vision, deliberate intent and many revisions, chopping away the cruft that’s isn’t “the thing” and “polishing”, not rushing it out the door.
Ken is famous for his brevity and succinct statements.
Not sure if that’s a personal preference, a mastered skill or “economy in everything”.
steve j
=========
A Research UNIX Reader: Annotated Excerpts from the Programmer's Manual, 1971-1986
M.D. McIlroy
<https://www.cs.dartmouth.edu/~doug/reader.pdf>
<https://archive.org/details/a_research_unix_reader/page/n13/mode/2up>
pg 10
3.4. Languages
CC (v2 page 52)
V2 saw a burst of languages:
a new TMG,
a B that worked in both core-resident and software-paged versions,
the completion of Fortran IV (Thompson and Ritchie), and
Ritchie's first C, conceived as B with data types.
In that furiously productive year Thompson and Ritchie together
wrote and debugged about
100,000 lines of production code.
=========
Programming's Dirtiest Little Secret
Wednesday, September 10, 2008
<http://steve-yegge.blogspot.com/2008/09/programmings-dirtiest-little-secret…>
It's just simple arithmetic. If you spend more time hammering out code, then in order to keep up, you need to spend less time doing something else.
But when it comes to programming, there are only so many things you can sacrifice!
You can cut down on your documentation.
You can cut down on commenting your code.
You can cut down on email conversations and
participation in online discussions, preferring group discussions and hallway conversations.
And... well, that's about it.
So guess what non-touch-typists sacrifice?
All of it, man.
They sacrifice all of it.
Touch typists can spot an illtyperate programmer from a mile away.
They don't even have to be in the same room.
For starters, non-typists are almost invisible.
They don't leave a footprint in our online community.
=========
--
Steve Jenkin, IT Systems and Design
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA
mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin
The discussion about the 3B2 triggered another question in my head: what were the earliest multi-processor versions of Unix and how did they relate?
My current understanding is that the earliest one is a dual-CPU VAX system with a modified 4BSD done at Purdue. This would have been late 1981, early 1982. I think one CPU was acting as master and had exclusive kernel access, the other CPU would only run user mode code.
Then I understand that Keith Kelleman spent a lot of effort to make Unix run on the 3B2 in a SMP setup, essentially going through the source and finding all critical sections and surrounding those with spinlocks. This would be around 1983, and became part of SVr3. I suppose that the “spl()” calls only protected critical sections that were shared between the main thread and interrupt sequences, so that a manual review was necessary to consider each kernel data structure for parallel access issues in the case of 2 CPU’s.
Any other notable work in this area prior to 1985?
How was the SMP implementation in SVr3 judged back in its day?
Paul
I do not know whether it is right, and i am surely not the right
person to mourn in public, but i wanted to forward this.
I only spoke to him once, he mailed me in private, but i could not
help him supporting Uganda, even though i admired what he was
doing, and often looked.
Local capacity building, and (mutual) respect for local culture
and practice, despite all sharp spikes and edges the storm causes
over time, that is surely the way to do it right.
--- Forwarded from Bram Moolenaar <Bram(a)Moolenaar.net> ---
Sender: vim_announce(a)googlegroups.com
To: vim_announce(a)googlegroups.com
Subject: Message from the family of Bram Moolenaar
Message-Id: <20230805121930.4AA8F1C0A68(a)moolenaar.net>
Date: Sat, 5 Aug 2023 13:19:30 +0100 (WEST)
From: Bram Moolenaar <Bram(a)Moolenaar.net>
Reply-To: vim_announce(a)googlegroups.com
List-ID: <vim_announce.googlegroups.com>
Dear all,
It is with a heavy heart that we have to inform you that Bram Moolenaar passed away on 3 August 2023.
Bram was suffering from a medical condition that progressed quickly over the last few weeks.
Bram dedicated a large part of his life to VIM and he was very proud of the VIM community that you are all part of.
We as family are now arranging the funeral service of Bram which will take place in The Netherlands and will be held in the Dutch lanuage. The extact date, time and place are still to be determined.
Should you wish to attend his funeral then please send a message to funeralbram(a)gmail.com. This email address can also be used to get in contact with the family regarding other matters, bearing in the mind the situation we are in right now as family.
With kind regards,
The family of Bram Moolenaar
--
--
You received this message from the "vim_announce" maillist.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_announce" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_announce+unsubscribe(a)googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_announce/20230805121930.4AA8F1C0A68%4….
-- End forward <20230805121930.4AA8F1C0A68(a)moolenaar.net>
--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)
Doug McIlroy:
This reminds me of how I agonized over Mike Lesk's refusal to remove
remote execution from uucp.
====
Uux, the remote-execution mechanism I remember from uucp, had
rather better utility than the famous Sendmail back-door: it
was how uucp carried mail, by sending a file to be handed to
mailer on the remote system. It was clearly dangerous if
the remote site accepted any command, but as shipped in V7
only a short list of remote commands was allowed: mail rmail
lpr opr fsend fget. (As uucp was used to carry other things
like netnews, the list was later extended by individual sites,
and eventually moved to a file so reconfiguration needn't
recapitulate compilation).
Not the safest of mechanisms, but at least in V7 it had a use
other than Mike fixing your system for you.
Is there some additional history here? e.g. was the list of
permitted commands added after arguments about safety, or
some magic command that let Mike in removed? Or was there a
different remote-execution back door I don't remember and don't
see in a quick look at uuxqt.c?
Norman Wilson
Toronto ON