TUHS

tuhs@tuhs.org

52 participants
6400 discussions

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

6 months

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/

6 months

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

6 months

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

6 months

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

6 months, 1 week

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

6 months, 1 week

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

6 months, 1 week

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.

6 months, 1 week

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

6 months, 1 week

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

6 months, 2 weeks

Jump to page:

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