TUHS

tuhs@tuhs.org

2 participants
6532 discussions

Princeton's "Unix: An Oral History": who was in the team in "The Attic"?

by steve jenkin

Has this been covered before? I’ve searched but not found an obvious answer, which would be a timeline, not a table. Has anyone roughly calculated “man years” spent developing Unix to 1973 or 1974? Under 25 "man-years”? (person years now) It compares favourably to the quoted “5,000 man years over 4 years” invested by IBM for the 1st million lines of OS/360 - which by 1978 was estimated a 10M LOC. In my reading on Multics, I’d not noticed a ‘man years’ estimate, thought the project ran from 1965 to 1985 when Honeywell ‘capped’ development and span off a commercial entity [ Bell Labs leaving April 1969 ]. There were many releases of Multics beginning with "MR 1.0” in 1974 to “MR 11.0” in 1984, with some others later. <https://www.multicians.org/chrono.html> Cobato in 1977 wrote that by 1969, when it moved out of ‘development only’, 150 man-years were spent on software. <https://rcs.uwaterloo.ca/~ali/cs854-f17/papers/multics.pdf> The original Unix group working with the PDP-11 on the 6th floor should be well known, but I can’t recall seeing a list. Would the first 1973 conferenceor 1974 CACM paper be the natural cut-off date for an ‘original' group? There’s a list of "Former members of 1127” maintained on-line. As an outsider who doesn’t know ppl & dates, can’t extract what I was interested in. <https://www.spinroot.com/gerard/1127_alumni.html> There was a constraint on active users / concurrent logins in the “Attic": the number of connected terminals & desks there. Assuming it took time to get terminals installed elsewhere, then later dedicated phone lines and 300 baud modems outside. The typesetter used by the patent dept isn’t mentioned. I’ve a recollection it was fed by mag tape, but unsure of that source. Infer at least the people named in the piece, which looks very sparse: Ken & Dennis :) Morris Cherry Kernighan Plus Joe Osanna working on roff / troff? [ do I have that wrong ] The 1971 “1st Edition” Manual Intro lists 4 names. No others appear in Sections 1, 3, 6, 7 [ commands & libraries ] <https://www.tuhs.org/Archive/Distributions/Research/Dennis_v1/1stEdman.html> ken K. Thompson dmr D. M. Ritchie jfo J. F. Ossanna rhm R. Morris In June 1974, Dennis wrote in the preface to the Version 5 manual, with he and Ken named as authors. <https://www.tuhs.org/Archive/Distributions/Research/Dennis_v5/v5man.pdf> The authors are grateful to L. L. Cherry, L. A. Dimino, R. C. Haight, S. C. Johnson, B. W. Kernighan, M. E. Lesk, and E. N. Pinson for their contributions to the system software, and to L. E. McMahon for software and for his contributions to this manual. We are particularly appreciative of the invaluable technical, editorial, and administrative efforts of J. F. Ossanna, M. D. Mcllroy, and R. Morris ======== An Oral History of Unix <https://www.tuhs.org/Archive/Documentation/OralHistory/> Assembling the History of Unix [ Report of FRS121 course ] <https://www.tuhs.org/Archive/Documentation/OralHistory/finalhis.htm#attic> The center of Unix activity was a sixth-floor room at Murray Hill which contained the PDP-11 that ran Unix. "Don't think of a fancy laboratory, but it was a room up in the attic," as Morris describes it. In addition to the programmers, four secretaries from the patent department worked in the attic, performing the text-processing tasks for which Unix was ostensibly developed. Robert Morris: We all worked in the same room. We worked all up in an attic room on the sixth floor, in Murray Hill. In space that maybe was one and a half times the size of this hotel room. We were sitting at adjacent terminals, and adjacent, and we knew each other and we always in fact ate lunch together. Shared a coffeepot. So, it was a very close relationship and most of us were both users and contributors and there was a significant initiative for research contribution at all points. ======== -- 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

2 years, 8 months

Documentation Call Numbers and Meanings?

by segaloco

Good afternoon folks, linked is a list of all of the call numbers of UNIX-relevant documentation that I've been able to catalogue lately: https://pastebin.com/DbDAhX3W This isn't exhaustive, I skipped many documents under dept (assuming dept) 305, 306, and 308, focusing mainly on 700, 301, 307, and 320. I was wondering if anyone that has some knowledge of the numbering system used for these documents in Bell might be able to comment on this in any way. What I've been able to make some determination on is: 700-prefixed call numbers appear to be general Western Electric stuff, most of these manuals being related to switching, power, hardware, etc. However, the UNIX 3.0 manual and 4.0 reference guide are both under this series too. I imagine this was simply because the computer systems group hadn't been formally spun off or otherwise received directive to manage UNIX documentation at this point? In any case, I'd be curious what all else may have gotten 700-series call numbers before the 300-series took over UNIX docs. As for the 300 series, as far as I can tell 300 is the umbrella for AT&T Computer Systems, with several sub departments handling slightly different (although overlapping in circumstances) concerns. What I have managed to determine is that 301 series encompasses the original System V version documentation, a few "Level II COBOL" documents, as well as some M68000 and Z8000-specific versions of docs (I didn't know UNIX System V ever hit the Z8000, that's cool). After System V gold, the wealth of UNIX documentation appears to come from code 307-X instead, I'm assuming 307 is whatever permutation of USG/USL happened to exist at the time. However, there are a few other codes that seem to sporadically be involved in UNIX docs as well as other computing docs: 302 - Just a smattering of Writers Workbench docs, very high call number suffixes (950-958). 303 - Bunch of 3B20D (Real-Time-Reliable) docs as well as other 3B20 stuff, mainly hardware manuals but a few SVR2.1-related docs as well for 3B20A, S, and D 304 - Another smattering of 3B20 docs, this time mostly A and S, mix of hardware and UNIX docs 305 - This one is hard to pin down, they've got the basic 3B2 docs, some other guidance docs for non-20 3B computers, and a mishmash of language tools like assemblers, a BASIC interpreter, compilers, and a few odd technical bulletins for products covered in other groups 306 - There wasn't much direct UNIX documentation here, just stuff about 3BNet (3B computer networking?) and the 5620 DOT Mapped terminal 308 - Documentation on a whole mess of software utilities with some odd Sys V manuals sprinkled in. You've got stuff like the "Office Telesystem", Instructional Workbench, more docs on BASIC, Pascal, and COBOL, some Fortran stuff as well, and a few other reference documents 310 - Seems to be entirely related to Documenter's and Writer's Workbenches. Whats odd is there is also a pretty even split of DWB and WWB documents in the 302 and 307 groups, so hard to say why the split, maybe a secondary department producing supplementary literature? Very low call number suffixes, so possibly 302 transitioned into 310 for DWB/WWB support 311 - Might be a "trade book" publishing arm, seems to only contain a few books, including "The C Programming Language" 320 - Might be the "standard systems" trade books arm as opposed to the version/system specific documentation gotten from USL directly. This list contains books like the SVID, Bach's Design of the UNIX Operating System book, some programming guidance books, and the UNIX Programmer's Manual 5 volume series with the metallic alphabet blocks on the cover (echoing the V7 trade release). What's interesting is call number 320-X comes back around with SVR4 as the call code that a number of 386-specific manuals were published under. 341 - This one is very odd, a higher call number than any of the others, but the only docs I could find under this are the System V gold Document, Graphics, Programming, and Support Tools guides, which curiously weren't published under 301 like the rest of the documentation for that version. Finally, some digestion from this research: This gives some compelling version-support information in early SysV I wasn't aware of previously: - System V Gold: - PDP-11 - VAX-11 - 3B - M68000 - Z8000 - System V R2: - VAX-11 - 3B - M68000 - NS32000 - iAPX 286 It appears Bell also opted to have different documentation sets for different processors in SVR2. We kinda see this later on with i386 variants of the SVR3 and SVR4 documents, but I don't think we ever quite see this wide of a spread of docs straight from AT&T after this. Also, among the many documents (one I didn't add to the list yet) is one referring specifically to UNIX Release 5.3, not System V R3 or anything like that, but a Release 5.3. I know I've seen "Release 5.2" listed in a few places, which had me curious, is there a well established record of what happened with internal (non research) UNIX after System V was branched? Whether the development stream simply became System V development, or if there was still a totally separate UNIX 5.x branch for a while that, while borrowed into System V at necessary times, did still constitute a distinct branch of development after the initial System V release. I know there is at least evidence of aspects of System V being put into CB UNIX 2.3, meaning CB 2.3 was post-System V, that would make a compelling argument for there being some more development work between CB and USG folks before they put the final bow on the UNIX/TS project and formally routed all efforts to System V. I'm sure there are other little nuggets of information hiding in there, but that's my digest from this thus far. If anyone knows of any other such efforts to produce a listing of all known UNIX documentation call numbers from AT&T, I'll happily contribute this to their efforts. - Matt G. P.S. SysV Gold scans are still inbound, just likely will be a winter project once the rains start and I can't go play outside.

2 years, 8 months

Strange Reference on Usenix_77 tape

by Warner Losh

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

2 years, 9 months

Early BSD license thread

by Warner Losh

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

2 years, 9 months

The USL Toolchest from the 80s and 90s

by Clem Cole

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

2 years, 9 months

Unix timelines

by steve jenkin

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 <https://github.com/dspinellis/unix-history-repo> 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 . <https://en.wikipedia.org/wiki/List_of_BSD_operating_systems> 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 <https://www.tuhs.org/cgi-bin/utree.pl> Éric Lévénez’s, "UNIX History” landscape format [very wide], lines & arrows, hand drawn, no source <https://www.levenez.com/unix/> David du Colombier, Unix Diagram portrait format, graphviz, source <http://www.unix-diagram.org> Linux Timeline, Fabio Loli et al landscape format, gnuclad, source (CSV + links to <https://distroware.gitlab.io/>) uses ‘curved’ lines, can be changed <https://github.com/FabioLolix/LinuxTimeline> Images: SVG, PNG <https://github.com/FabioLolix/LinuxTimeline/releases/tag/v21.10> Grokline, UNIX TIMELINE, 2004-2009 [dead site] Lists by Date, Vendor, Product detail pages not archived <https://web.archive.org/web/20091217070631/http://www.grokline.net/time_ind…> ============ -- 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

2 years, 9 months

The MGR window system and the Macintosh

by John Floren

Today I came across an article about the MGR window system for Unix: https://hack.org/mc/mgr/ One thing that interested me was a note that some versions worked on the Macintosh: > The window system ran on many different hardware platforms, at least > these: Sun 3/xx workstations running SunOS, which was the the original > development platform, Sun SPARCstations (SunOS and then ported by me to > Solaris), Intel x86 based PCs (Coherent, Minix, FreeBSD or Linux), > Atari ST (under MiNT), AT&T UnixPC (SysV) and the Macintosh. As the owner of a Macintosh Plus, I think it would be a very interesting thing to experiment with, but I haven't had much luck finding any more information about it. Does anyone know more about MGR, particularly on the Mac? That page has the source for MGR 0.69, but there's no mention of the Macintosh in it (aside from comments about how it was supported on older versions...) John

2 years, 9 months

Re: "9 skills our grandkids won't have" - Is this a TUHS topic?

by Matthias Bruestle

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. Matthias -- When You Find Out Your Normal Daily Lifestyle Is Called Quarantine

2 years, 9 months

Re: Does anybody know the etymology of the term "word" as in collection of bits?

by Douglas McIlroy

> 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

2 years, 9 months

Extracting files from various old dump/restore tapes

by Lars Brinkhoff

Hello, I have on my hands many images of tapes that seems to have been written by various implementaions of dump. I see the magic numbers 60011 and 60012 in little and big endian at offsets 18 (16-bit version?) and 24 (32-bit version?). I don't know the dating of the tapes, but around 1980 would be a reasonable guess. Are there some easy to use (ready to run on a modern Unix) tools to extract files from such tape files? I'm not looking to restore a file system on disk, just extract the files.

2 years, 9 months

DMD 5620 simulator

by Seth Morabito

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(a)loomcom.com

2 years, 9 months

Re: Does anybody know the etymology of the term "word" as in collection of bits?

by Douglas McIlroy

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

2 years, 9 months

Re: [COFF] Re: Will someone update the 386BSD Wikipedia page for me?

by David Arnold

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 <coff(a)tuhs.org> 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 >

2 years, 9 months

Happy birthday, Unix timestamp!

by Dave Horsfall

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

2 years, 9 months

Re: Does anybody know the etymology of the term "word" as in collection of bits?

by Nelson H. F. Beebe

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(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/ - -------------------------------------------------------------------------------

2 years, 9 months

Re: Does anybody know the etymology of the term "word" as in collection of bits?

by norman＠oclsc.org

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)

2 years, 9 months

Re: Happy birthday, Unix timestamp!

by norman＠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

2 years, 9 months

Re: Does anybody know the etymology of the term "word" as in collection of bits?

by jnc＠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

2 years, 9 months

Re: Does anybody know the etymology of the term "word" as in collection of bits?

by Douglas McIlroy

> 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

2 years, 9 months

Re: Happy birthday, Unix timestamp!

by Douglas McIlroy

> 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

2 years, 9 months

Re: Re-implementations/Clean-Rooms et al.

by Clem Cole

On Thu, Sep 8, 2022 at 12:51 PM segaloco via TUHS <tuhs(a)tuhs.org> 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.

2 years, 9 months

"... interesting old-timey UNIXes ..." (cross post from geeks)

by Grant Taylor

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

2 years, 9 months

Re: Does anybody know the etymology of the term "word" as in collection of bits?

by jnc＠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

2 years, 9 months

Re: Does anybody know the etymology of the term "word" as in collection of bits

by jnc＠mercury.lcs.mit.edu

> On Sep 8, 2022, at 9:51 AM, Jon Steinhart <jon(a)fourwinds.com> 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

2 years, 9 months

Re: Has this been discussed on-list? How Unix changed Software.

by Douglas McIlroy

> (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

2 years, 9 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS