TUHS

tuhs@tuhs.org

16 participants
6536 discussions

Start a nNew thread

Re: Ken Thomson's email address?

by Jackson Helie G

If this is true, it's a pity. Otherwise, I would like to ask Ken Thompson if he has the first C compiler.

2 months, 1 week

Re: Ken Thomson's email address?

by jnc＠mercury.lcs.mit.edu

> From: Jackson Helie G > I would like to ask Ken Thompson if he has the first C compiler. He wouldn't; he didn't do much work on C. Dennis Ritchie (who created C) posted two very early ones here: https://www.nokia.com/bell-labs/about/dennis-m-ritchie/primevalC.html Noel

2 months, 1 week

Ken Thomson's email address?

by Jackson Helie G

Oh, sorry guys, please forgive me for the off-topic question. I was wondering if anyone knows Ken Thomson's email address? I was wondering if he has any more archives of Unix from 1972 and before.

2 months, 1 week

Fwd: An Announcement about the USENIX Annual Technical Conference

by Rik Farrow

I received this earlier today, and wondered if cross-posting it would be appropriate. Here goes... Rik ---------- Forwarded message --------- From: Casey Henderson-Ross <casey.henderson(a)usenix.org> Date: Tue, May 6, 2025 at 2:12 PM Subject: An Announcement about the USENIX Annual Technical Conference To: Rik Farrow <rik(a)rikfarrow.com> Read on for important news. [image: USENIX, the Advanced Computing Systems Association] <https://s.usenix.org/acton/ct/2452/s-0514-2505/Bct/l-sf-cl-7018Y000001JtF6Q…> Hello, Rik, USENIX celebrates its 50th anniversary in 2025. We celebrate decades of innovations, experiments, and gatherings of the advanced computing system community. And in the spirit of our ever-evolving community, field, and industry, we announce the bittersweet conclusion of our longest-running event, the USENIX Annual Technical Conference in July 2025, following USENIX ATC '25. Since USENIX's inception in 1975, it has been a key gathering place for innovators in the advanced computing systems community. The early days of meetings evolved into the two annual conferences, the USENIX Summer and Winter Conferences, which in 1995 merged into the single Annual Technical Conference that has continued to evolve and serve thousands of our constituents for 30 years. For the past two decades, as more USENIX conferences have joined the USENIX calendar by focusing on specific topics that grew out of ATC itself, attendance at ATC has steadily decreased to the point where there is no longer a critical mass of researchers and practitioners joining us. Thus, after many years of experiments to adapt this conference to the ever-changing tech landscape and community, the USENIX Board of Directors has made the difficult decision to sunset USENIX ATC. USENIX ATC in its many iterations has been the home of an incredible list of "firsts" in our industry: - In 1979, ONYX, the first attempt at genuine UNIX hardware, was announced. - In 1982, DEC unveiled the creation of its UNIX product. - In 1983, Eric Allman presented the first paper on Sendmail, "Mail Systems and Addressing in 4.2BSD." - In 1985, Sun Microsystems presented the first paper on NFS, "Design and Implementation of the Sun Network Filesystem." - In 1988, the first light on Kerberos and the X Window system was presented. - In 1989, Tom Christiansen made his first Perl presentation as an Invited Talk. - In 1990, John Ousterhout presented Tcl. - In 1995, the first talk on Oak (later JAVA) was given as a Work-in-Progress report. - In 1998, Miguel de Icaza presented "The GNOME Desktop Environment." These examples represent just a few of the many contributions presented at USENIX ATC over the years, with hundreds of papers that account for thousands of citations of work that the community has presented, discussed, learned from, and built upon as the community evolved. Part of that evolution involved the continued development of subcommunities, as has been the case with USENIX Security, which began as a workshop in 1988 and has since grown to an annual symposium and the largest of our events in terms of both papers published and number of attendees annually, with 417 papers and 1,015 attendees at USENIX Security '24. The LISA (Large Installation System Administration) Conference, which also started as a workshop in 1987, grew in a similar fashion to its peak of over 1,000 attendees, but like USENIX ATC declined as its community changed until its own sunset in 2021. Papers on file and storage systems that would have previously been presented at USENIX ATC in the early 2000s began to find homes at FAST when it was founded in 2002. Networked systems papers started flowing to NSDI in 2003. As the biennial OSDI continued to grow alongside ACM's SOSP, OSDI became annual in 2021 and SOSP followed suit, providing the community with additional venues. While landmark moments in our community have continued at USENIX ATC, many others have also occurred at these other USENIX conferences, as showcased in the USENIX Test of Time Awards <https://s.usenix.org/acton/ct/2452/s-0514-2505/Bct/l-sf-cl-7018Y000001JtF6Q…> and the ACM SIGOPS Hall of Fame Awards <https://s.usenix.org/acton/ct/2452/s-0514-2505/Bct/l-sf-cl-7018Y000001JtF6Q…>, which celebrate influential works presented at both SOSP and OSDI. Although numerous papers continue to be submitted to USENIX ATC with significant research being reviewed, accepted, and presented, the community has evolved, and now attends conferences other than USENIX ATC. From 1,698 attendees in San Diego in 2000, ATC attendance dwindled to 165 attendees in Santa Clara in 2024—even as we had over 4,000 people attend all USENIX conferences in 2024. USENIX recognizes the pivotal role that USENIX ATC has played in the shaping of the Association itself as well as the lives and careers of its many attendees and members. We also realize that change is inevitable, and all good things must come to an end: if it weren't for ATC being a "victim of its own great success"—a foundry of so many other successful conferences and workshops—USENIX would never have grown and expanded so much over the decades. Thus our hearts are heavy as we celebrate ATC's history and legacy alongside the evolution of its younger siblings and face the financial realities of the post-pandemic world and volatile global economy. USENIX's resources to support its conferences and communities are not unlimited, particularly as we maintain our commitment to open-access publications that are free for our authors to publish. We have been reporting about these challenges via our Annual Meeting and subsequent reports for the past several years (2024 <https://s.usenix.org/acton/ct/2452/s-0514-2505/Bct/l-sf-cl-7018Y000001JtF6Q…>, 2023 <https://s.usenix.org/acton/ct/2452/s-0514-2505/Bct/l-sf-cl-7018Y000001JtF6Q…>, 2022 <https://s.usenix.org/acton/ct/2452/s-0514-2505/Bct/l-sf-cl-7018Y000001JtF6Q…>, 2021 <https://s.usenix.org/acton/ct/2452/s-0514-2505/Bct/l-sf-cl-7018Y000001JtF6Q…>, 2020 <https://s.usenix.org/acton/ct/2452/s-0514-2505/Bct/l-sf-cl-7018Y000001JtF6Q…>). We deeply appreciate the financial support we have received from our community in the form of donations, memberships, and conference registrations. However, we continue to operate at a deficit and ATC continues to shrink. In making this hard choice, accepting the reality in front of us that encourages us to innovate in a different direction under challenging circumstances, we seek to embody the values of this community that was founded on curiosity, persistence, and collaboration. As we celebrate 50 years of both USENIX and ATC in its varying forms, we look towards the future of this vibrant community in the form of the many conferences that ATC continues to help create in its image: welcoming, thoughtful environments for the presentation of innovative work that fellow conference attendees help push forward. We look forward to honoring ATC's legacy alongside USENIX's history and its future in Boston in July of 2025. We would love to hear memories of your experience at the USENIX Annual Technical Conference over the years. Please submit your thoughts <https://s.usenix.org/acton/ct/2452/s-0514-2505/Bct/l-sf-cl-7018Y000001JtF6Q…> in words, video, or both by *Monday, June 2*. We will share your memories both at USENIX ATC '25 and afterwards. We hope that you will join us at USENIX ATC '25 <https://s.usenix.org/acton/ct/2452/s-0514-2505/Bct/l-sf-cl-7018Y000001JtF6Q…>, which will include both a celebration of USENIX's 50th anniversary on the evening of *Monday, July 7*, and a tribute to USENIX ATC on the evening of *Tuesday, July 8*. [image: Casey Henderson headshot] Best Regards, Casey Henderson-Ross Executive Director USENIX Association About this mailing list: You are receiving this email because you are or have been a member of USENIX, have attended USENIX conferences, or have signed up to receive emails from USENIX. USENIX <https://s.usenix.org/acton/ct/2452/s-0514-2505/Bct/l-sf-cl-7018Y000001JtF6Q…> never shares, sells, rents, or exchanges email addresses of its members, conference attendees, and other constituents. Review our privacy policy <https://s.usenix.org/acton/ct/2452/s-0514-2505/Bct/l-sf-cl-7018Y000001JtF6Q…> . We would like to continue sending you occasional email announcements like this one. However, if you no longer want to receive emails from USENIX, please click here <http://s.usenix.org/acton/rif/2452/s-0514-2505/-/l-sf-cl-7018Y000001JtF6QAK…> to opt out of all communications from USENIX. If you have any questions about the mailing list, please email info(a)usenix.org. We may also be reached via postal mail: USENIX Association 2443 Fillmore St, #380-25600, San Francisco, CA 94115-1814, USA

2 months, 1 week

Re: Paragraphs formatted differently depending on previous ones

by G. Branden Robinson

[looping TUHS back in since I'm correcting a message I sent there] Hi Dave, At 2025-05-06T08:36:55-0500, Dave Kemper wrote: > On Fri, May 2, 2025 at 7:35 PM G. Branden Robinson > <g.branden.robinson(a)gmail.com> wrote: > > I guess another way of saying this is that, as I conceive it, a line > > that is "adequately full" contributes to the page's uniformity of > > grayness by definition. > > For an example of less-than-ideal results if this is _not_ considered > the case (groff's behavior before this change), see > http://savannah.gnu.org/bugs/?60673#comment0 (the initial report that > precipitated the commit Doug is commenting on). Yes. In my reply to Doug I incorrectly characterized the resolution of this bug as a "2023" change of mine, but I actually landed the change in 2021. It simply took until 2023 to appear in a released _groff_. To make this message more TUHS-o-riffic, let's observe that input using DWB 3.3 troff and Heirloom Doctools troff (descended from Solaris troff, descended from DWB 2.0 troff [I think]), and both of which descend from Kernighan's device-independent troff circa 1980. $ DWBHOME=. ./bin/nroff groff-60673.roff | cat -s While the example in bug 57836's original report is somewhat contrived and a bit of an edge case in real life, there turns out to be a more innate bug in grotty's balancing algorithm. As mentioned before (and easily observable), when grotty adds spaces to a line in the process of justifying it, the algorithm it utilizes adds spaces from opposite ends of each line. But when it adds this space, it does not take into account lines with no adjustment at all required. Therefore if space only need be added to every other line of the text, all the space ends up being added to the same end of the line, degrading the uniform grayness of the output, as can be seen in this example. There is one fairly simple way to address this: grotty shouldn't "count" lines that don't need to be adjusted; instead, it should apply the alternation pattern only to those lines that do need adjustment. $ ./bin/nroff groff-60673.roff | cat -s While the example in bug 57836's original report is somewhat contrived and a bit of an edge case in real life, there turns out to be a more innate bug in grotty's balancing algorithm. As mentioned before (and easily observable), when grotty adds spaces to a line in the process of justifying it, the algorithm it utilizes adds spaces from opposite ends of each line. But when it adds this space, it does not take into account lines with no adjustment at all required. Therefore if space only need be added to every other line of the text, all the space ends up being added to the same end of the line, degrading the uniform grayness of the output, as can be seen in this example. There is one fairly simple way to address this: grotty shouldn't "count" lines that don't need to be adjusted; instead, it should apply the alternation pattern only to those lines that do need adjustment. They are the same, and differ from groff 1.22.4 and earlier only in that they adjust spaces starting from the right end of the line instead of the left. At the risk of tooting our own horn, here's how groff 1.23.0+ handles the same input. $ ~/groff-1.23.0/bin/nroff groff-60673.roff | cat -s While the example in bug 57836’s original report is somewhat contrived and a bit of an edge case in real life, there turns out to be a more innate bug in grotty’s balancing algorithm. As mentioned before (and easily observable), when grotty adds spaces to a line in the process of justifying it, the algorithm it utilizes adds spaces from opposite ends of each line. But when it adds this space, it does not take into account lines with no adjustment at all required. Therefore if space only need be added to every other line of the text, all the space ends up being added to the same end of the line, degrading the uniform grayness of the output, as can be seen in this example. There is one fairly simple way to address this: grotty shouldn’t "count" lines that don’t need to be adjusted; instead, it should apply the alternation pattern only to those lines that do need adjustment. Three observations: 1. One can find the input at Dave's URL above. 2. The input disables inter-sentence spacing. 3. The adjustment algorithm is a property not of grotty(1) (the output driver), but of GNU troff itself. Regards, Branden

2 months, 1 week

Off topic: Books on Unix security?

by norman＠oclsc.org

Aharon Robbins: So, before I just refer to them as "classics", can anyone recommend more recent books? Feel free to answer in private. === `Unix security' is not the most-specific of terms. Can you give more context? Norman Wilson Toronto ON

2 months, 1 week

Re: Any Interdata war stories?

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > Yes, that was one of the RTS compilers for the NU machine. John Romkey > may have done it, as he was the primary person behind PCIP I decided to poke around in the 'MIT-CSR' dump, since that was the machine the PC/IP project started on, to see what I could find. Hoo boy! What an adventure! In the PC/IP area, I found a 'c86' directory - but it was almost empty. It did have a shell file, 'grab', which contained: tftp -g $1 xx "PS:<Wayne>$1" and a 'graball' file which called 'grab' for the list of compiler source files. ('xx' was MIT-XX, the TOPS-20 main time-sharing machint of LCS.) So I did a Web search for Wayne Gramlich (with whom I hadn't communicated in many decades), and he popped right up. (Amazing thing, this Internet thingy. Who'd have ever thought, back in the day, that it would turn into what it did? Well, probably John Brunner, whom I (sadly) never met, who was there before any of us.) I took a chance, and called his number, and he was there, and we had a long chat. He absolutely didn't do it, although he wrote the loader the project used ('l68', the source for which I did find.) He's virtually certain Romkey didn't (which would have been my guess too; Romkey was like a sophmore when the project started). His best (_very_ faded) memory was that they started off with a commercial compiler. (But see below.) That leaves several mysteries. 1) Why would a commercial compiler not come with a linker? 2) Why did people who wanted to work with the PC/IP source need a Bell license? I did some more poking, and the list of files for the 86 compiler, from 'graball': trees.c optim.c pftn.c code.c local.c scan.c xdefs.c table.c reader.c local2.c order.c match.c allo.c comm1.c manifest mfile1 common macdefs mfile2 mac2defs matched the file names from 'pcc', as given in "A Tour Through the Portable C Compiler": https://maibriz.de/unix/ultrix/_root/porttour.pdf (in section "The Source Files"). So whether the 86 compiler was done at MIT (by someone in RTS), or at a company, it was definitely a 'pcc' descendant. (Possibly adding to the confusion, we had some other C compilers for various ISA's in that project [building networking software for various micro-computers], including an 8080 C compiler from Whitesmiths, Ltd, which I have also found. It's possible that Wayne's vague memory of a commercial compiler is of that one?) I really should reach out to Romkey and Bridgham, to see what they remember. Later today. Whether the main motivation for keeping the compiler source on XX was i) because disk space was short on CSR (we had only a hand-me-down pair of CalComp Model 215 drives - capacity 58 Mbytes per drive!); ii) to prevent version skew; or iii) because it was a commercial compiler, and we had to protect the source (e.g. we didn't have the source to the 8080 compiler, only the object modules), I have no idea. > Anyway the MIT RTS folks made hardware and PCC back ends for the 68K, > Z8000 and 8086. I believe that each had separate assemblers, tjt who > sometimes reads this list might know more, as he wrote the 68K assembler. There is an 'a86' directory on CSR, but it too is empty, except for a 'grab' command file. That contains only: tftp -g $1 xx "PS:<novick>$1" I have no memory of who 'novick' might have been. A Web search for 'novick mit lcs' didn' turn anything up. (I wonder if it might have been Carol Novitsky; she was in our group at LCS, and I have a vague memory of her being associated with the networking software for micro-computers project.) Anyway, it probably doesn't matter; the c86 'grab' referred to Wayne, but he didn't write c86; 'novick' might not have written a86. Something else to ask Romkey and Bridgham about. Noel

2 months, 1 week

Re: Paragraphs formatted differently depending on previous ones

by Douglas McIlroy

Branden, > The relevant function fits on one screen, if your terminal window is at > least 36 lines high. :) (Much of it is given over to comments.) > https://git.savannah.gnu.org/cgit/groff.git/tree/src/roff/troff/env.cpp?id=… Actually there's still another function, spread_space that contains the inner R-L and L-R loops. The whole thing has become astonishingly complicated compared to what I remember as a few (carefully crafted) lines of code in the early roff. I admire your intrepid forays into the groff woods, of which this part must be among the less murky. Doug

2 months, 1 week

Surviving System V/VME Artifacts?

by segaloco

So part of Western Electric/AT&Ts developer support for the WE32x00 CPU line was the WE321SB VME-bus single-board computer. The official operating system for this was UNIX System V/VME. This version is referenced in several document catalogues and literature surrounding this VME module. I was curious if anyone on list happens to know of any surviving System V/VME artifacts floating around out there. All I've been able to find are references to the system in other WE32x00 and UNIX documentation. Thanks for any info! - Matt G.

2 months, 2 weeks

Any Interdata war stories?

by arnold＠skeeve.com

> From: Tom Lyon <pugs78(a)gmail.com> > > I was pleased to learn that the first port of S to UNIX was on the > Interdata 8/32, which I had my part in enabling. I would love to hear more about the Interdata port and what happened with it afterwards. Interdata seems to have disappeared into the dustbin of history. And Unix on it apparently never got out of Bell Labs; I don't think the code for it is in the TUHS archives. Was the Interdata system in use at Bell Labs for actual work once the port was complete? ISTR there was a meeting with Interdata about changes in the architecture that Bell Labs wanted, that Interdata didn't want to make. What was the full story? Any other info would be welcome. Thanks, Arnold

2 months, 2 weeks

Re: Any Interdata war stories?

by jnc＠mercury.lcs.mit.edu

> From: Arnold Robbins > CCI made the Tahoe that 4.4 ran on, but I'm guessing it's a different > architecture than the Interdata? I think so. Almost all documentation on the Tahoe has been lost in the mists of time (if ANYONE retains ANY hardcopies of ANY hardware documentation for the Tahoe, PLEASE let me know), but I recently managed to work out a bit about it from the instruction decoding/printing routines in the debuggers from 4.3 BSD Tahoe: https://gunkies.org/wiki/Power_6/32 and it seems to be fairly different from the Interdata: http://bitsavers.org/pdf/interdata/32bit/29-365R01_32BitRefMan_Jun74.pdf Also, 'CCI' is 'Computer Consoles Incorporated', not "Concurrent Computer Corp". Noel

2 months, 2 weeks

Re: V7 ls and dot files?

by Douglas McIlroy

http://xahlee.info/UnixResource_dir/writ/unix_origin_of_dot_filename.html says > I'm not sure but I believe .. went in during the Version 2 rewrite .. was there from the beginning. The v1 man page directory(v) says, > By convention, the first two entries in each directory are for "." and "..". Doug

2 months, 2 weeks

Re: Any Interdata war stories?

by jnc＠mercury.lcs.mit.edu

> From: Rich Salz > The PC/IP software from MIT included a port of the "Portable C > Compiler" to generate 8086-era code. It ran on a Unix machine and built > binaries that you downloaded to the PC. ... So you need an ATT source > license to get the full PCIP dev kit. That makes sense. The 'MIT license' (about which Jerry Saltzer did a note for the October-December 2020 issue of the 'IEEE Annals of the History of Computing', available here: https://www.mit.edu/~Saltzer/publications/MITLicense.pdf and which mentions that it was initially done for the MIT PC/IP code) only applied to the MIT-written applications, not a 'derived work' (to use the intellectual property law 'term of art') based on Bell code. Noel

2 months, 2 weeks

Searching for game history

by Brian "Beej" Hall

Hi everyone, I'm here with a Unix/Bell Labs history question at the suggestion of BWK. I have a bit of a computing mystery on my hands... _Conquest_ is an old game that apparently came to life in Bell Labs, but no one seems to know anything more about it, including who the author is. The instructions for the game[1] contain the following text at the bottom: Amiga port by Bob Shimbo, orginal author unknown. This game started life on a UNIX system at Bell Labs. It was ported to CP/M 80 by a Scott Kamin. The manual was thrown together in an afternoon. (Typos and corrections welcome). You can reach me through Compuserve (UID 70260,231) or TBBS of colorado (303)-693-4735. The LHA archive for the Amiga was packaged in 1986. I did get in touch with Bob Shimbo, but he writes: You can imagine how long ago I did that port given I referenced my Compuserve account. I don't recall where I found the code originally. Sorry. We've been through 3 house moves since then and I don't know where any references might have gotten to. Scott Kamin--I found a reference to someone by his name in the CP/M world in the 80s in New Jersey. (Internet Archive has lots of old computer magazine scans and his name showed up in the classified ads.) And a search turned up a snail mail address for someone in the right age range living a few miles from the business listed in the ad. A Hail Mary snail mail got no reply. Does any of it ring a bell, by any chance? I've begun the work of getting it to run on modern systems[2], and it would be great to be able to include more history in the man page. Cheers, -Beej [1] https://github.com/beejjorgensen/conquest/blob/master/instructions.txt [2] https://github.com/beejjorgensen/conquest/ -- Brian "Beej Jorgensen" Hall beej(a)beej.us https://beej.us/

2 months, 2 weeks

BTL 'S' manual from 1981

by Tom Lyon

Not UNIX, but adjacent... With the permission of John Chambers, I'm sharing a scan of "S - A Language and System for Data Analysis" by Richard Becker and John Chambers, January 1981. Enjoy: https://drive.google.com/drive/folders/14ijVPw1DihydXFqTzj-wgl3C5LYEJdKX?us… I was pleased to learn that the first port of S to UNIX was on the Interdata 8/32, which I had my part in enabling.

2 months, 2 weeks

V7 ls and dot files?

by Aharon Robbins

Hi All. The V7 ls.c ignores `.' and `..', unless given the -a option. The V1 - V6 ls ignores all files that start with `.', unless given -a, and this is the default for all modern versions of ls. BWK tells me there's a story about the V7 behavior but he doesn't remember what it is. Does anyone here know? Thanks, Arnold

2 months, 2 weeks

Re: UniPress Emacs V2.20 from 1989

by Lars Brinkhoff

Mark Seiden writes: > the display updating code, as i recall, had a skull and crossbones on it > i remember there was a bit of a kerfuffle when richard stallman introduced > that code into gnu emacs This is true. Gosling Emacs from 1984 and GNU Emacs 13 from 1985 both have the skull and crossbones comment.

2 months, 3 weeks

UniPress Emacs V2.20 from 1989

by Lars Brinkhoff

The floppy label says it's for AIX, but the source code hits it runs on Sun, IRIS, Apollo, HP, X10, X11, Amiga, Mac, MS-DOS, Xenix. https://github.com/larsbrinkhoff/emacs-history/tree/sources/Hans%20H%C3%BCb…

2 months, 3 weeks

Pre-Symposium on Operating System Principles Public UNIX Mentions?

by segaloco

I see in many places the 1973 Symposium on Operating System Principles mentioned as one of the earliest if not the earliest discussion of UNIX in the public eye. This would be around the time of the Fourth Edition and the rewrite of the system for the PDP-11/45 in C. Well, I recently picked up Aho and Ullman's The Theory of Parsing, Translation, and Compiling. The very last sentence of the preface in Volume 1 reads: > The use of UNIX, an operating system for the PDP-11 computer designed by > Dennis Ritchie and Kenneth Thompson, expedited the preparation of certain > parts of this manuscript. Given that this text was published in 1972, would this have been a completely esoteric reference to the general target audience of these books or was knowledge of UNIX already well circulated in the computing community by then? What other sorts of notoriety/publicity did UNIX get out in the general public prior to its presentation in 1973 and subsequent publication of the paper in CACM? - Matt G.

3 months

running BSD 2.11 on my PDP 11/70 emulator

by Folkert van Heusden

Hi, For fun I'm developing a PDP 11/70 emulator. It runs on everything from ESP32 microcontrollers up to linux, windows, etc https://vanheusden.com/emulation/PDP-11/kek/ Currently it can run UNIX 7 in multi user mode. Of course I would like it to run BSD 2.11 as well (because of the networking support). It boots, but after outputting the memory amounts it produces a lot of garbage. It does eventually complete booting and then allows you to log in. I wonder if you sees this: https://paste.nurd.space/mqIDB_0SjoDoJoasOGkiNQ_NjpRsCufAJCnKTA7ZxUI (text) or https://imgpaste.nurd.space/pics/437bcf0d149a017168cbbf2def8560917a037a3935… (image), does this ring a bell to anyone? I verified with simh that the disk-image should work. regards -- www.vanheusden.com

3 months

Current Status of AT&T/USL Licensing?

by segaloco

So System V shops had to hold a license with AT&T to modify and redistribute code based on UNIX System V and they would then license directly with their customers correct? This being distinct from the way licensing with BSD was concerned in that you had to pursue the license with AT&T to then use BSD. That is my current understanding anyway that I base this question on. So IBM, DEC, Sun, HP, Microsoft, etc. approach AT&T, got a source license, and started producing their System V value adds out there in the world. In this present day and age, for those still shipping genuine System V derivatives, what does this licensing landscape actually look like? Do the players still in the game still refer to whatever license they started with back in the 80s, did they renew up until say SVR4 when folks stopped drinking from the USL well, or are there still ongoing licenses that the remaining vendors have to renew to distribute their software? Where I'm going with this is just another angle on the whole "who owns System V" question which comes up in my mind all the time. Knowing the specific legal entities involved in the most recent licensing documentation would certainly factor into understanding the landscape a little better. To boil that down to a specific example, once upon a time, Sun held a license with AT&T to use, modify, and redistribute UNIX System V. At the present moment, Oracle is the distributor of Solaris. If there is a piece of licensing paperwork sitting in a filing cabinet at Oracle somewhere, who would that paperwork say is the original licensor of the product? Would that even matter in this year of 2025? - Matt G.

3 months

2.11BSD Patch Announcements

by Henry Bent

Hi all, I see that there has been quite a bit of activity in the last few weeks with 2.11BSD, resulting in the release of a number of patches. Is there any sort of announcement list that one could subscribe to in order to be notified of when these patch releases occur? Would it make sense to post patch announcements to the TUHS or SIMH lists? TUHS seems somewhat natural since one of the patch distribution methods is through their archive, though I am open to thoughts that anyone else has about this. I only happened to be aware of the patches because I have the "History of the Berkeley Software Distribution" page on my Wikipedia watchlist and someone has been very diligent about updating the 2.11BSD patch status there. -Henry

3 months, 1 week

Re: non-Posix input files

by Douglas McIlroy

> "The requirement that awk add a trailing <newline> to the program argument > text is to simplify the grammar, making it match a text file in form." This should no more be a *requirement* for awk than globbing should have been a requirement for MS-DOS apps. A widespread principle deserves a widespread answer. If it is a requirement on awk, then for interoperability it should be made a requirement on all programs that handle text files, especially editors. The way to do that, of course, would be to redefine text file to allow a non-newline as the last character. Ugh. Not warning perpetuates travesties like "awk END{print NR}' " giving a different answer than "wc -l". I agree that awk does the kind thing by supplying the final newline. But it should recognize that this is non-standard behavior and warn in the interest of discouraging the proliferation of garbage. Postel's so-called "robustness principle" is in play here. "Be conservative in what you send, be liberal in what you accept" would better read, "Send conservatively; receive amply but grudgingly". Doug

3 months, 2 weeks

Re: non-Posix input files

by Steve Simon

Re: newlines at the end of files. I hesitate to ask this in such exalted company, but isn’t it a question of whether the newline is (or should be) a line terminator, or a statement separator? -Steve

3 months, 2 weeks

Re: non-Posix input files

by Douglas McIlroy

>> info groff gives semantics for including nonempty files that don't end >> with newline. Such files violate the Posix definition of text file. >> >> Although groff is certainly justified in providing semantics for >> non-Posix text, I suggest that it should warn when it does so. > That's true but I'm hesitant to put groff in the business of wagging its > finger at users feeding it non-strictly-conforming text files when doing > so doesn't cause it any problems. Causing groff problems is an odd criterion. The fact that groff will paste files together unless the first happens to end in a newline is a sign of groff 's internals, not of the underlying problem. A newline missing at the end of a file is typically a symptom of either the incaution of some other program (perhaps an editor) or of a file having been unexpectedly truncated (as by a program abort). The latter cause is common enough to justify warning always, not just about cases that are inconvenient to groff. Groff is what it is, but if the treatment of absent final newlines were up for grabs, I'd argue for the more common solution: in all cases insert a newline and warn. Doug

3 months, 2 weeks

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