TUHS

tuhs@tuhs.org

16 participants
6536 discussions

by Warren Toomey

All, recently I saw on Bruce Schneier "Cryptogram" blog that he has had to change the moderation policy due to toxic comments: https://www.schneier.com/blog/archives/2024/06/new-blog-moderation-policy.h… So I want to take this opportunity to thank you all for your civility and respect for others on the TUHS and COFF lists. The recent systemd and make discussions have highlighted significant differences between people's experiences and opinions. Nonetheless, apart from a few pointed comments, the discussions have been polite and informative. These lists have been in use for decades now and, thankfully, I've only had to unsubscribe a handful of people for offensive behaviour. That's a testament to the calibre of people who are on the lists. Cheers and thank you again, Warren P.S. I'm a happy Devuan (non-systemd) user for many years now.

1 year

Re: autotools

by Steve Simon

my personal frustration with autotools was trying to port code to plan9. i wish autotools had an intermediate file format which described the packages requirements, that way i could have written my own backend to create my config.h and makefiles (or mkfiles) in the end i wrote my own tool which crudely parses a directory of C or F77 sourcecode and uses heuristics to create a config.h and a plan9 mkfile, it was named mkmk(1) it was almost _never_ completely correct, but usually got close enough that the files only needed a little manual hacking. it also took great pains to generate mkfiles that looked hand written; if you are going to auto generate files, make them look nice. -Steve

1 year

Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register

by Lyndon Nerenberg (VE7TFX/VE6BBM)

> This is The Way if you really care about portability. Autoconf, > once you get your head around what, why, and when it was created, > makes for nice Makefiles and projects that are easy to include in > the 100 Linux distributions with their own take on packaging the > world. This is outright claptrap and nonsense. In the latter half of the 90s I was responsible for writing installers and generating platform-native packages for about a dozen different commercial UNIX platforms (AIX, Solaris, Irix, HP/UX, OSF, BSD/OS, ...). Each of these package systems was as different as could be from the others. (HP/UX didn't even have one.) That entire process was driven by not very many lines of make recipes, with the assistance of some awk glue that read a template file from which it generated the native packages. And these were not trivial software distributions. We were shipping complex IMAP, X.400 and X.500 servers, along with a couple of MTAs. Our installers didn't just dump the files onto the system and point you at a README; we coded a lot of the site setup into the installers, so the end user mostly just had to edit a single config file to finish up. --lyndon

1 year

Fwd: Anyone have Plexus docs/software squirreled away?

by Al Kossow

FYI, for people like me that care about 80s 68K Unix systemf There is a pretty serious multi-purpose preservation effort that started a few weeks ago around Plexus systems as a result of a series of YouTube videos https://youtu.be/iltZYXg5hZw https://github.com/misterblack1/plexus-p20/

1 year

Be there a "remote diff" utility?

by Dave Horsfall

Every so often I want to compare files on remote machines, but all I can do is to fetch them first (usually into /tmp); I'd like to do something like: rdiff host1:file1 host2:file2 Breathes there such a beast? I see that Penguin/OS has already taken "rdiff" which doesn't seem to do what I want. Think of it as an extension to the Unix philosophy of "Everything looks like a file"... -- Dave

1 year

Re: [COFF] Re: Supervisor mode on ye olde PDP-11

by jnc＠mercury.lcs.mit.edu

> From: Warner Losh > 2.11BSD used a mode between kernel and user for the TCP stack to get > more effective address space... Is there a document for 2.11 which explains in detail why they did that? I suspect it's actually a little more complicated than just "more address space". The thing is that PDP-11 Unix had been using overlays in the kernel for quite a while to provide more address space. I forget where they first came in (I suspect there were a number of local hacks, before everyone started using the BSD approach), but by 2.9 BSD they were a standard part of the system. (See: https://minnie.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/src/sys/conf/Ovmak… for some clues about how this works. There is unfortunately no documentation that I know of which explains clearly how it works; if anyone knows of any, can you please let me know? Otherwise you'll have to read the sources.) I can think of two possible reasons they started using supervisor mode: i) There were a limited number of the 2.9-type overlays, and they were not large; trying to support all the networking code with the existing overlay system may have been too hard. ii) I think this one is unlikely, but I'll list it as a possibility. Switching overlays took a certain amount of overhead (since mapping registers had to be re-loaded); if all the networking code ran in supervisor mode, the supervisor mode mapping registers could be loaded with the right thing and just left. Noel

1 year

Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > Frankly my major complaint with much of the modern world is that when we > ignore the past "There are two kinds of fools. One says, 'This is old, therefore it is good'; the other says, 'This is new, therefore it is better.'" -- Dean Inge, quoted by John Brunner in "The Shockwave Rider". Noel

1 year

Diff: The seminal water we swim in

by Douglas McIlroy

> this month marks the fiftieth anniversary of the release of what > would become a seminal, and is arguably the single most important, > piece of social software ever created. I'm flattered, but must point out that diff was just one of a sequence of more capable and robust versions of proof(1), which Mike Lesk contributed to Unix v3. It, in turn, copied a program written by Steve Johnson before Unix and general consciousness of software tools. Credit must also go to several people who studied and created algorithms for the "longest common subsequence" problem: Harold Stone (who invented the diff algorithm at a blackboard during a one-day visit to Bell Labs), Dan Hirschberg, Tom Szymanksi, Al Aho, and Jeff Ullman. For a legal case in which I served as an expert witness, I found several examples of diff-type programs developed in the late 1960s specifically for preparing critical editions of ancient documents. However, Steve Johnson's unpublished program from the same era appears to be the first that was inspired as a general tool, and thus as "social software". Doug

1 year

Diff: The seminal water we swim in

by Rich Salz

From Mastodon, MHoye posting at https://mastodon.social/@mhoye/112615649865163136: I haven't seen anybody mentioning it or even noticing it, like it's just the water we swim in now, but this month marks the fiftieth anniversary of the release of what would become a seminal, and is arguably the single most important, piece of social software ever created. Written by Douglas McIlroy and James Hunt and released with the 5th Edition of Unix this month in 1974: diff. https://minnie.tuhs.org/cgi-bin/utree. <https://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/source/s1/diff1.c>..

1 year

5ESS UNIX RTR Reference Manual - Issue 10 (2001)

by segaloco

Good evening, while I'm still waiting on the full uploads to progress (it's like there's a rule any >100MB upload to archive.org for me has to fail like 5 times before it'll finally go...) I decided to scrape out the UNIX RTR manual from a recent trove of 5ESS materials I received and tossed it up in a separate upload: https://archive.org/details/5ess-switch-unix-rtr-operating-system-reference… This time around I've got Issue 10 from December 2001. The last issue of this particular manual I found on another 5ESS disc is Issue 7 from 1998 which I shared previously (https://ia601200.us.archive.org/view_archive.php?archive=%2F12%2Fitems%2F5e…) The manual is in "DynaText" format on the CD in question, unlike Issue 7 which was already a PDF on its respective CD. I used print-to-PDF to generate the above linked copy. Given that the CD itself is from 2007, this may point to UNIX RTR having no significant user-visible changes from 2001 to 2007 that would've necessitated manual revisions. In any case, I intend to upload bin/cue images of all 7 of the CDs I've received which span from 1999 to 2007, and mostly concern the 5ESS-2000 switch from the administrative and maintenance points of view. Once I get archive.org to choke these files down I also intend to go back around to the discs I've already archived and reupload them as proper bin/cue rips. I was in a hurry the last time around and simply zipped the contents from the discs, but aside from just being good archive practice, I think bin/cue is necessary for the other discs as they seem to have control information in the disc header that is required by the interactive documentation viewers therein. All that to say, the first pass will result in bin/cues which aren't easily readable through archive.org's interface, but I intend to also swing back around on these new discs and provide zips of the contents as well to ensure the archives are both correct (bin/cue) and easily navigable (zip). As always, if you have any such documentation or leads on where any may be awaiting archival, I'm happy to take on the work! - Matt G.

1 year, 1 month

Re: [tuhs] Early statistical software in Unix

by Nelson H. F. Beebe

Doug McIlroy kindly sent me contact information for John Chambers, co-author of the cited book about the S system. I have just heard back from John, who offered a link to his summary paper from the 2020 HOPL conference proceedings S, R, and data science https://doi.org/10.1145/3386334 and reported that S was licensed to AT&T Unix customers only in binary form, and that the original source code may no longer exist. That is a definitive answer, even if not the one that I was hoping to find. ------------------------------------------------------------------------------- - 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/ - -------------------------------------------------------------------------------

1 year, 1 month

Re: most direct Unix descendant

by Douglas McIlroy

Eloquently put. Amen! doug > Unix brought automation to the forefront of possibilities. Using Unix, > anyone could do it - even that kid in Jurassic Park. Today, everything > is GUI and nothing can be automated easily or, most of the time, > not at all. > Unix is an ever shrinking oasis in a desert of non-automation and complexity. > It is the loss of automation possibilities that frustrates me the most

1 year, 1 month

Draft: London and Reiser's UNIX/32V paper, reconstructed

by G. Branden Robinson

Hi folks, Reiser and London's paper documenting their preparation of UNIX/32V, a port of Seventh Edition Unix to the VAX-11/780, is an important milestone in Unix development--as much I think for its frank critique of C as "portable assembly" as for the status of the system documented: the last common ancestor of the BSD and System V branches of development. Because the only version I've ever seen of this paper is a scan of, possibly, a photocopy several generations removed from the original, I thought I'd throw an OCR tool at it and see about reconstructing it, not just for posterity but to put the groff implementation of mm to the test. So even if someone has a beautiful scan of this document elsewhere, this exercise remains worthwhile to me for what it has shown me about Documenter's Workbench mm and groff's mostly compatible reimplementation thereof. Please find attached my first draft of the reconstruction as an mm document as well as a PDF rendered by bleeding edge groff. I did not attempt to fix _any_ typos, solecisms, or non-idiomatic *roff usage (like the employment of hyphens as arithmetic signs or operators) in this document. I may have introduced errors, however, due to human fallibility or incorrect inferences about what lay beneath scanning artifacts. Hence its draft status. I welcome review. Assuming this reconstruction survives peer scrutiny, I aim to put it up on GitHub as I did Kernighan & Cherry's "Typesetting Mathematics" paper.[1] For the casual reader, I extract my documentary annotations below. For groff list subscribers, I will add, because people are accustomed to me venturing radical suggestions for reforms of macro packages, I suggest that we can get rid of groff mm's "MOVE" and "PGFORM" extensions. They're buggy (as the man page has long conceded), and I don't think anyone ever mastered them, not even their author. I rewrote "0.MT", essential to rendering of this document, without requiring them at all. I _tried_ to use them, but "MOVE" in particular introduced baffling errors in vertical spacing. When I threw it aside to attack head-on the layout problems facing me, things got easier. Further, simple caching and restoration of `.i` and `.l` register values (when multiple changes were being made to them within a macro) obviated `PGFORM`. I'm not sure that it is tractable to idiot-proof manipulations of basic layout parameters like these, as these macros seem to have tried to do. If a document author wants to seize control of page layout from a full-service macro package and reach deep into the guts of the formatter, they should glove up and put things back where they found them. My opinion. .\" London & Reiser's UNIX/32V porting paper .\" .\" Reconstruction in groff mm (but DWB 3.3 mm compatible) .\" from scanned/OCRed text by G. Branden Robinson, June 2024 .\" .\" The original scan shows no evidence of superscript usage, except on .\" the cover sheet where "TM" superscripts "UNIX". .\" .\" Some differences may arise due to changes in the mm macro package .\" itself from its PWB incarnation (ca. 1978) and DWB 3.3 (July 1992). .\" Thanks to Dan Plassche for the history. .\" https://www.tuhs.org/pipermail/tuhs/2022-March/025545.html .\" .\" The groff reimplementation of mm was undertaken mostly from .\" 1991-1999 (by Juergen Haegg), based on the DWB documentation. It .\" added features but also parameterized many aspects of package .\" behavior, for example to facilitate easy localization. Later, .\" Werner Lemberg and G. Branden Robinson contributed enhancements, bug .\" fixes, and improvements to the groff_mm(7) man page. .\" .\" I anticipate adding further parameters to groff mm to better .\" emulate the old version of mm used by this paper. (For example, the .\" format of the caption applied to the reference page differs between .\" PWB mm and DWB 3.3.) Where this document exercises such extensions, .\" they should be prefixed with a `do` request so that AT&T troff will .\" ignore them. .\" Override: "By default, ... bold stand-alone headings are printed .\" in a size one point smaller than the body." .\" XXX: The cover "page" (more like a header block) is a mess when .\" typeset with groff mm, and outright horrific in nroff mode. GBR has .\" fixes for these pending for push to GNU Savannah's Git repository. .\" .\" XXX: Original scan capitalizes "Subject:"; DWB 3.3 renders it in .\" full lowercase. .\" .\" XXX: Original scan bears a "TM:" heading for the technical .\" memorandum number(s). DWB 3.3 lacks this. .\" .\" Memorandum captions may have changed from PWB to DWB 3.3 mm. groff .\" mm has changed in Git (June 2024) to use the captions documented in .\" the DWB 3.3 manual. We override the default for authenticity. .\" XXX: Original scan sets reference marks as a typewriter might, at .\" normal size on the baseline between square brackets. DWB 3.3 .\" converts them to superscripts but keeps the brackets(!). groff mm .\" should add a "Rfstyle" register to control this. .\" 0 = auto (nroff/troff); 1 = bracket; 2 = superscript; 3 = both. (?) \" straight quotes in original .ns \" XXX: Hack to keep `VL` from adding pre-list vertical space. \" recte: *(\-\-p+i) \" bad ellipsis spacing in original \" - missing; error in text or scanner fubar? \" recte: \-1 \" sic .\" Either `AL` worked differently in 1978 mm, or didn't exist, or .\" somebody wanted this list _just so_. .\"AL "" 5 .\" XXX: Scan has signatures set farther to the right, not centered as .\" DWB 3.3 mm sets them. groff mm follows DWB here. .\" .\" XXX: PWB and DWB 3.3 put the signature names in bold; groff mm sets .\" them at normal weight. Bug. .\" .\" XXX: Scan has a couple of vees between the signature line and the .\" flush left secretarial annotation. groff mm sets the annotation on .\" the same line as the last author but also puts its information in .\" the cover page header as DWB 3.3 does, described next. DWB 3.3: (1) .\" omits the secretarial annotation altogether, putting it up in the .\" cover page header under the authors' names; (2) does not use author .\" initials (in the cover header) for this memorandum type; (3) puts .\" the department number after "Org." on the line under the author .\" name; (4) puts the abbreviated AT&T site name below that. Should we .\" consider a `Sgstyle` register for groff mm? .\" .\" XXX: groff mm organizes the department and site name differently .\" from DWB 3.3 in the cover head, and I don't see any reason for it .\" to. Fix this. .\" XXX: Scan only breaks between notations; DWB 3.3 and groff put 1v .\" between them. Should we consider an `Nss` register for groff mm? .\" XXX: Scan has references caption set flush left, in mixed case and .\" bold (just like `HU`). DWB 3.3 and groff center it and set it in .\" full caps in italics (at normal weight). If there were a way to .\" dump the accumulated reference list independently of rendering the .\" caption, that would give the author much more flexibility. .\" .\" XXX: The numbered reference list does not look like one produced .\" with `RL` nor with `AL`. The numeric tag is left-aligned within the .\" paragraph indentation. groff mm aligns it to the right. .\" .\" DWB 3.3 and Heirloom mm don't seem to honor `.RP 2` as the DWB .\" manual documents. They start the table immediately after the .\" reference list and go haywire boxing the table. Bug. Regards, Branden [1] https://github.com/g-branden-robinson/retypesetting-mathematics

1 year, 1 month

PID 0 and the scheduler

by Will Senn

All, There's an interesting dive into PID 0 linked to from osnews: https://blog.dave.tf/post/linux-pid0/ In the article, the author delves into the history of the scheduler a bit - going back to Unix v4 (his assembly language skills don't go to PDP variants). I like the article for two reasons - 1) it's clarity 2) it points out the self-reinforcing nature of our search ecosystem. I'm left with the question - how did scheduling work in v0-v4? and the observation that search really sucks these days. Later, Will

1 year, 1 month

[tuhs] Early statistical software in Unix

by Nelson H. F. Beebe

The book ``S: An Interactive Environment for Data Analysis and Graphics'' (Wadsworth, 1984), by Richard A. Becker and John M. Chambers, and an earlier Bell Labs report in 1981, introduced the S statistical software system that later evolved into the commercial S-Plus system (now defunct, I think), and the vibrant and active R system (https://cran.r-project.org/) that we use at Utah in our statistics courses. Almost 21,000 open-source packages for R are available, and they appear to be the dominant form of statistical software package publication, based on extensive evidence in our bibliography archives that completely cover numerous journals in probability and statistics. I'm interested in looking into the early S source code, if possible, to see how some statistical software that I am freshly implementing for high-precision computation was handled at Bell Labs more than four decades ago. Does anyone on this list know whether the original S system was ever distributed in source code to commercial sites, and academic sites, that licensed Unix from Bell Labs in the 1980s? Does that code still exist (and is openly accessible), or has it been lost? As with the B, C, D, and R programming languages, it is rather hard for Web search engines to find things that are known only by a single letter of the alphabet. ------------------------------------------------------------------------------- - 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/ - -------------------------------------------------------------------------------

1 year, 1 month

diving into vi (nvi) - some observations from a slow learner

by Will Senn

Well, I really dove into using vi by way of nvi this past week and I have to say... the water's fine. It turns out that vi is a much simpler editor to understand and use (but no less powerful) than it's great grandchild, vim. To be fair, vim is an interesting editor and having used it off and on since the mid '90s, it's very familiar... but its powers? difficult to attain. vim stands as an excellent example of just how far you can take a product that works, keeping its core, but expanding it in all directions. No matter how much I tried to grasp its essence, it alluded me. The online help files seemed inscrutable to me, mixing environment settings, ex commands, ex mode commands, vi motions, insert mode commands in ways that seemed quite confusing to me. I know that I'm probably among a select few vim users that love it without really having a clue as to how it works. My best resource has been the web and search, but of late I've been wanting more. That's what drove me on this quest to really dig in to how things used to work and nvi is the best surrogate of the old ways that I could find (well, excluding heirloom vi, the traditional vi, which I've confirmed works pretty much the same way as nvi, with lisp support and without a few nice-to-haves nvi has). Anyway, here's something I worked out, after much travail - vi appears to be all about modes, movement, counts, operators, registers, and screens (which I found very weird at first, but simple in retrospect)... with these fundamentals down, it seems like you can do anything and I mean anything... and all of the other functions are just bolted on for the purpose of making their specific tasks work. Getting this out of the existing documentation was a mess. Thankfully the nvi docs (based on the 4.4 docs) are much slimmer and better organized. Even so, they make assumptions of the reader that I don't seem to fit. Take motions as prolly the most glaring example - all of the docs I've ever seen organize these by logical units of text (words, paras, etc), personally and apparently persistently, I think of motion as directed, so it took me a lot of experimentation, head scratching, and writing things out several times in several different ways to realize I could represent the idea on a single notecard as (some commands appear in multiple lines): Leftward motions - [[, {, (, 0, ^|_, B, b, h|^H Rightward Movement - l|SP, e, E, w, W, $, ), }, ]] Upward motions - 1G, ^B, H, ^U, -, k | ^P Downward motions - G, ^F, L, ^D, ^M | +, j | ^J | ^N Absolute - | G Relative - %, H, M, L Marks - m, ', `, '', `` Keeping in mind that movements left-to-right are - section, para, sentence, line, text, word and endword (big, and small), and letter. And up and down are - file, screen, in screen (HML), half-screen, chars-in-line, and line. For me, this inversion from units of motion to direction of motion put forty some-odd commands in much closer reach for me. Looking back at the vim documentation, I see how its sheer volume and the way it is organized got in the way of my seeing the forest. Thankfully, in nvi, there are two incredibly useful ex commands to help - exu[sage] and viu[sage]. I simply printed these out and worked with them making the experimental assumption that they would serve as a baseline that represented the full capabilities of vi... and sure enough, after working and working with them, I am pretty confident they are sufficient for any editing task. Wow, who knew? I loved vi, but now, I'm starting to really appreciate it's simplicity?! I can't believe those words are coming out of my mouth. I never thought of it as simple... those movement commands were far too numerous as I understood them. Are there things I miss from vim? Sure, I miss command line completion in ex mode, I want my help text to appear in a window where I can search, I would like better window control. But, I think I'll stick with nvi a while until I really nail it down. Then all of the cool stuff that vim offers, or neovim, will seem like icing on the cake that is vi. Thanks to Ken Thompson for writing a work of art that serves as the true core of this editor, to Bill Joy for his great work in extending it, again to Bill Joy for bringing vi to life, and to Mary Ann for the macros and making it accessible to the rest of us, and others who contributed. It's 2024 and I still can't find a better terminal editor than vi... as it existed in the late '80s or as it exists today as nvi/vim/neovim. Amazing piece of software. Off to figure out tags!! Arg, seems like it oughtta be really useful in my work with source code, why can't I figure it out?! Sheesh. Will

1 year, 1 month

Old documentation - still the best

by Will Senn

A small reflection on the marvels of ancient writing... Today, I went to the local Unix user group to see what that was like. I was pleasantly surprised to find it quite rewarding. Learned some new stuff... and won the door prize, a copy of a book entitled "Introducing the UNIX System" by Henry McGilton and Rachel Morgan. I accepted the prize, but said I'd just read it and recycle it for some other deserving unix-phile. As it turns out, I'm not giving it back, I'll contribute another Unix book. I thought it was just some intro unix text and figured I might learn a thing or two and let someone else who needs it more have it after I read it, but it's a V7 book! I haven't seem many of those around and so, I started digging into it and do I ever wish I'd had it when I was first trying to figure stuff out! Great book, never heard of it, or its authors, but hey, I've only read a few thousand tech books. What was really fun, was where I went from there - the authors mentioned some bit about permuted indexes and the programmer's manual... So, I went and grabbed my copy off the shelf and lo and behold, my copy either doesn't have a permuted index or I'm not finding it, I was crushed. But, while I was digging around the manual, I came across Section 9 - Quick UNIX Reference! Are you kidding me?!! How many years has it taken me to gain what knowledge I have? and here, in 20 pages is the most concise reference manual I've ever seen. Just the SH, TROFF and NROFF sections are worth the effort of digging up this 40 year old text. Anyhow, following on the heels of a recent dive into v7 and Ritchie's setting up unix v7 documentation, I was yet again reminded of the golden age of well written technical documents. Oh and I guess my recent perusal of more modern "heavy weight" texts (heavy by weight, not content, and many hundreds of pages long) might have made me more appreciative of concision - I long for the days of 300 page and shorter technical books :). In case you think I overstate - just got through a pair of TCL/TK books together clocking in at 1565 pages. Thank you Henry McGilton, Rachel Morgan, and Dennis Ritchie and Steve Bourne and other folks of the '70s and '80s for keeping it concise. As a late to the party unix enthusiast, I greatly value your work and am really thankful you didn't write like they do now... Later, Will

1 year, 1 month

CSRC Involvement in Non-UNIX AT&T Software Projects

by Douglas McIlroy

> was there ever any crossover regarding UNIX folks applying their developments to other non-UNIX AT&T systems Besides Sandy Fraser's long-term effort to advance digital communication (as distinct from digital transmission), there was TPC; see TUHS https://www.tuhs.org/pipermail/tuhs/2020-April/020802.html and other mentions of TPC in the TUHS archives. Ken Thompson did considerable handholding for early adopters of Unix for applications within the Bell System, notably tracking automatic trouble reports from switching systems and managing the workflow of craftspeople in a wire center. Bob Morris's intimate participation in a submarine signal-processing project that Bell Labs contracted to produce for the US Navy set him on a career path that led to becoming chief scientist at NSA's National Computer Security Center. Gerard Holtzmann collaborated to instill model-checking in switching and transmission projects. Andrew Hume spent much time with AT&T's call records. Lorinda Cherry single-handedly automated the analysis of call centers' notes on customer contacts, This enabled detection of significant human-engineering and public-relations problems. An important part of my role as a department head was to maintain contacts with development labs so that R and D were mutually aware of each other's problems and expertise. This encouraged consulting visits, internships, and occasionally extended collaboration or specific research projects as recounted above. Doug

1 year, 1 month

Proliferation of book print styles

by Will Senn

Today, as I was digging more into nroff/troff and such, and bemoaning the lack of brevity of modern text. I got to thinking about the old days and what might have gone wrong with book production that got us where we are today. First, I wanna ask, tongue in cheek, sort of... As the inventors and early pioneers in the area of moving from typesetters to print on demand... do you feel a bit like the Manhattan project - did you maybe put too much power into the hands of folks who probably shouldn't have that power? But seriously, I know the period of time where we went from hot metal typesetting to the digital era was an eyeblink in history but do y'all recall how it went down? Were you surprised when folks settled on word processors in favor of markup? Do you think we've progressed in the area of ease of creating documentation and printing it making it viewable and accurate since 1980? I didn't specifically mention unix, but unix history is forever bound to the evolution of documents and printing, so I figure it's fair game for TUHS and isn't yet COFF :). Later, Will

1 year, 1 month

Re: Proliferation of book print styles

by Douglas McIlroy

> Were you surprised when folks settled on word processors in favor of markup? I'm not sure what you're asking. "Word processor" was a term coming into prominence when Unix was in its infancy. Unix itself was sold to management partly on the promise of using it to make a word processor. All word processors used typewriters and were markup-based. Screens, which eventually enabled WYSIWYG, were not affordable for widespread use. Perhaps the question you meant to ask was whether we were surprised when WYSIWYG took over word-processing for the masses. No, we weren't, but we weren't attracted to it either, because it sacrificed markup's potential for expressing the logical structure of documents and thus fostering portability of text among distinct physical forms, e.g. man pages on terminals and in book form or technical papers as TMs and as journal articles. WYSIWYG was also unsuitable for typesetting math. (Microsoft Word clumsily diverts to a separate markup pane for math.) Moreover, WYSIWYG was out of sympathy with Unix philosophy, as it kept documents in a form difficult for other tools to process for unanticipated purposes, In this regard, I still regret that Luca Cardelli and Mark Manasse moved on from Bell Labs before they finished their dream of Blue, a WYSIWYG editor for markup documents, I don't know yet whether that blue-sky goal is achievable. (.docx may be seen as a ponderous latter-day attempt. Does anyone know whether it has fostered tool use?) Doug

1 year, 1 month

CSRC Involvement in Non-UNIX AT&T Software Projects

by segaloco

I'm reading about the Automatic Intercept System as discussed in BSTJ Vol. 53 No. 1 this evening. It is a stored program control call handling system designed to respond to calls with potential forwarding or disconnection messages. Reading through the description of the operating system for AIS got me wondering: What with the growing experience in the CSRC regarding kernel technologies and systems programming, was there ever any crossover regarding UNIX folks applying their developments to other non-UNIX AT&T systems projects or vice versa, perhaps folks who worked primarily on switching and support software bringing things over to the UNIX development camp? In other words, was there personnel cross-pollination between Bell System UNIX programmers and the folks working on stuff like AIS, ESS switching software, etc.? Or were the aims and implementation of such projects so different that the resources were relatively siloed? I would imagine some of these projects were at least developed using UNIX given the popularity and demands of PWB. That's just my hunch though, some BSTJs also describe software development and maintenance taking place on S/360 and S/370 machines and various PDPs. Indeed the development process for AIS mentioned above, as of late 1971, involved assembly via S/360 software and then system maintenance and debugging via an attached PDP-9. - Matt G.

1 year, 1 month

Mike Karels has died

by Chet Ramey

Sad, horrible news. https://www.facebook.com/groups/BSDCan/permalink/10159552565206372/ -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/

1 year, 1 month

Wiki Page on UNIX Standards

by segaloco

Good day everyone, I just wanted to share that I've put up a bit of info as well as some book covers concerning UNIX standards that were published from the 80s til now: https://wiki.tuhs.org/doku.php?id=publications:standards I did my best to put down a bit of information about the /usr/group, POSIX, SVID, and SUS/Open Group standards, although there's certainly more to each story than what I put down there. Still, hopefully it serves to lay out a bit of the history of the actual standards produced over time. I'm kicking myself because one of the things I could've produced a picture of but didn't save at the time is the cover of IEEE 1003.2, a copy of this popped up on eBay some time in the past year and for reasons I can't recall I didn't order it, nor did I save the picture from the auction at the time. In any case, if anyone has any published standards that are not visually represented in this article, I'm happy to add any photos or scans you can provide to the page. Also pardon if the bit on spec 1170/SUS may be shorter than the others. Admittedly even having most of this on the desk in front of me right now, I'm fuzzy on the lines between POSIX, the Single UNIX Specification, the "Open Group Specification", spec 1170, etc. or if these are all names that ultimately just refer to different generations of the same thing. Part of getting this information put down is hoping someone will be along to correct inaccuracies :) Anywho, that's all for now. Feel free to suggest any corrections or additions! - Matt G.

1 year, 1 month

Fwd: [ih] Mike Karels has died

by Dan Cross

FYI, this just got passed by Vint Cerf. Very sad news. ---------- Forwarded message --------- From: vinton cerf via Internet-history <internet-history(a)elists.isoc.org> Date: Tue, Jun 4, 2024 at 3:18 PM Subject: [ih] Mike Karels has died To: internet-history <internet-history(a)elists.isoc.org> Mike Karels died on Sunday. I don’t have any details other than: https://www.facebook.com/groups/BSDCan/permalink/10159552565206372/ https://www.gearty-delmore.com/obituaries/michael-mike-karels Mike was deeply involved in the Berkeley BSD releases as I recall, after he inherited the TCP/IP implementation for Unix from Bill Joy (am I remembering that correctly?). RIP v -- Internet-history mailing list Internet-history(a)elists.isoc.org https://elists.isoc.org/mailman/listinfo/internet-history

1 year, 1 month

Vi Quick Reference card for 4.4 BSD

by Will Senn

Today after trying to decipher the online help for vim and neovim, I decided I'd had enough and I opted for nvi - the bug for bug vi compatible that I've used for so long on FreeBSD. It handles cursor keys, these days (my biggest gripe back when, now I'm not so sure it's an improvement). It's in-app help pages are about 300 lines long, the docs are just four of the 4.4 docs: An Introduction to Display Editing with VI, Edit: A tutorial, EX Reference Manual, and VI-EX Reference Manual - all very well written and understandable. It does everything I really need it to do without the million and one extensions and "enhancements" the others offer. In doing the docs research, I found many, many references to a "/Vi Quick Reference card"/ in the various manpages and docs. I googled and googled some more and of course got thousands of hits (really many thousands), but I can't seem to find the actual card referenced. I'm pretty sure what I want to find is a scanned image or pdf of the card for 4.4bsd. Do y'all happen to know of where I might find the golden quick ref card for vi from back in the 4.4bsd days or did it even really exist? Will

1 year, 1 month

← Newer
1
...
9
10
11
12
13
14
15
...
262
Older →

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