TUHS

tuhs@tuhs.org

19 participants
6471 discussions

"dmd-pgmg" Toolchest package (SysV 5620+630 version of Sam)

by Mike Haertel

Does anybody out there have a copy of the old AT&T Toolchest "dmd-pgmg" package? This apparently includes the a SysV port of Sam for 5620/630 as well as other programs for the AT&T windowing terminals.

2 years, 7 months

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

by steve jenkin

I’ve been looking at this question for a time and thought it could’ve appeared on the TUHS list - but don’t have an idea of the search terms to use on the list. Perhaps someone suggest some to me. As a starting point, below is what John Lions wrote on a similar topic in 1978. Conspicuously, “Security” is missing, though “Reliability & Maintenance” would encompass the idea. With hindsight, I’d suggest (Research) Unix took a very strong stance on “Technical Debt” - it was small, clean & efficient, even elegant. And ‘shipped' with zero known bugs. It didn’t just bring the Unix kernel to many architectures, the same tools were applied to create what we now call “Open Source” in User land: - Multi-platform / portable - the very act of porting software to diverse architectures uncovered new classes of bugs and implicit assumptions. Big- & Little-endian were irrelevant or unknown Before Unix. - full source - compatibility layers via - written in common, well-known, well-supported languages [ solving the maintenance & update problem ] - standard, portable “toolchains” - shell, make, compiler, library tools for system linker, documentation & doc reading tools - distribution systems including test builds, issue / fault reporting & tracking An emergent property is "Good Security”, both by Design and by (mostly) error-free implementations. In the Epoch Before Unix (which started when exactly?), there was a lot of Shared Software, but very little that could be mechanically ported to another architecture. Tools like QED and ROFF were reimplemented on multiple platforms, not ‘ported’ in current lingo. There are still large, complex FORTRAN libraries shared as source. There’s an important distinction between “Open” and “Free” : cost & availability. We’ve gone on to have broadband near universally available with easy to use Internet collaboration tools - e.g. “git”, “mercurial” and “Subversion” just as CVS’s. The Unix-created Open Source concept broke Vendor Lock-in & erased most “Silos”. The BSD TCP/IP stack, and Berkeley sockets library, were sponsored by DARPA, and made freely available to vendors as source code. Similarly, important tools for SMTP and DNS were freely available as Source Code, both speeding the implementation of Internet services and providing “out of the box” protocol / function compatibility. The best tools, or even just adequate, became only a download & install away for all coding shops, showing up a lot of poor code developed by in-house “experts” and radically trimming many project schedules. While the Unix “Software Tools” approach - mediated by the STDOUT / STDIN interface, not API’s - was new & radical, and for many classes of problems, provided a definitive solution, I’d not include it in a list of “Open Source” features. It assumes a “command line” and process pipelines, which aren’t relevant to very large post-Unix program classes: Graphical Apps and Web / Internet services. regards steve jenkin ============== Lions, J., "An operating system case study" ACM SIGOPS Operating Systems Review, July 1978, ACM SIGOPS Oper. Syst. Rev. 12(3): 46-53 (1978) 2. Some Comments on UNIX ------------------------ There is no space here to describe the technical features of UNIX in detail (see Ritchie and Thompson, 1974 ; also Kernighan and Plauger, 1976), nor to document its performance characteristics, which we have found to be very satisfactory. The following general comments do bear upon the present discussion: (a) Cost. UNIX is distributed for "academic and educational purposes" to educational institutions by the Western Electric Company for only a nominal fee, and may be implemented effectively on hardware configurations costing less than $50,000. (b) Reliability and Maintenance. Since no support of any kind is provided by Western Electric, each installation is potentially on its own for software maintenance. UNIX would not have prospered if it were not almost completely error-free and easy to use. There are few disappointments and no unpleasant surprises. (c) Conciseness. The PDP-11 architecture places a strong limitation on the size of the resident operating system nucleus. As Ritchie and Thompson (1974) observe, "the size constraint has encouraged not only economy but a certain elegance of design". The nucleus provides support services and basic management of processes, files and other resources. Many important system functions are carried out by utility programs. Perhaps the most important of these is the command language interpreter, known as the "shell". (Modification of this program could alter, even drastically, the interface between the system and the user.) (d) Source Code. UNIX is written almost entirely in a high level language called "C" which is derived from BCPL and which is well matched to the PDP-11. It provides record and pointer types, has well developed control structures, and is consistent with modern ideas on structured Programming. (For the curious, the paper by Kernighan (1975) indirectly indicates the flavour of "C" and exemplifies one type of utility program contained in UNIX.) Something less than i0,000 lines of code are needed to describe the resident nucleus. pg 47 (e) Amenability. Changes can be made to UNIX with little difficulty. A new system can be instituted by recompiling one or more files (at an average of 20 to 30 seconds per file), relinking the file containing the nucleus (another 30 seconds or so), and rebooting using the new file. In simple cases the whole process need take no more than a few minutes. (f) Intrinsic Interest. UNIX contains a number of features which make it interesting in its own right: the run-time support for the general tree structured file system is particularly efficient; the use of a reserved set of file names smooths the concepts of device independence; multiple processes (three or four per user is average) are used in a way which in most systems is regarded as totally extravagant (this leads to considerable simplification of the system/user interface); and the interactive intent of the system has resulted in an unusually rich set of text editing and formatting programs. (g) Limitations. There are few limitations which are of concern to us. The PDP-11 architecture limits program size, and this for example frustrated an initial attempt to transfer Pascal P onto the 11/40. Perhaps the greatest weakness of UNIX as it is presently distributed (and this is not fundamental!) is in the area where other systems usually claim to be strong: support for "bread and butter" items such as Fortran and Basic. (h) Documentation. The entire official UNIX documentation, including tutorial material, runs to less than 500 pages. By some standards this is incredibly meagre, but it does mean that student can carry his own copy in his brief case. Features of the documentation include: - an unconventional arrangement of material (unsettling at first, but really very convenient); - a terse, enigmatic style, with much information conveyed by innuendo; - a permuted KWIC index. Most importantly perhaps UNIX encourages the programmer to document his work. There is a very full set of programs for editing and formatting text. The extent to which this has been developed can be gauged from the paper by Kernighan and Cherry (1975). ============== -- 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, 7 months

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

by Douglas McIlroy

>> a paper appeared (in CACM?) that repeated Dennis's exercise. > Maybe this one? > B.P. Miller, L. Fredriksen, and B. So, "An Empirical Study of the Reliability > of UNIX Utilities", Communications of the ACM 33, 12 (December 1990). > http://www.paradyn.org/papers/fuzz.pdf Probably. I had forgotten that the later effort was considerably more elaborate than Dennis's. It created multiple random inputs that might stumble on other things besides buffer overflow. I see a Unix parable in the remarkable efficacy of Dennis's single-shot test. Doug

2 years, 7 months

i386 binary of 4.4BSD-Alpha

by MOCHIDA Shuji

I added i386 binary compiled from 4.4BSD-Alpha source. http://www.netside.co.jp/~mochid/comp/bsd44-build/ Boot with bochs works rather well. qemu-system-i386 also boots, and NIC (NE2000 ne0) works good, but kernel prints many "ISA strayintr" messages. I got many useful infomations from below 2 sites: "Fun with virtualization" https://virtuallyfun.com/ 386bsd bochs qemu "Computer History Wiki!" https://gunkies.org/wiki/Main_Page Installing 386BSD on BOCHS First time, I tried to compile i386 using 4.4BSD final (1995) source, patching many many pieces from 386BSD, NetBSD, and else.. but then, I felt "Well, we have BSD/OS 2.0, NetBSD 1.0, and FreeBSD 2.0 those are full of good improvements.." So, I changed target, and remebered Pace Willisson's memo in 4.4BSD (and in 4.4BSD-Lite2 also) sys/i386/i386/README: "4.4BSD-alpha 80386/80486 Status" June 20, 1992 that file says "can be compiled into a fairly usable system". yeah, needed chages not so small, though. -mochid

2 years, 7 months

PCC Revived is back up

by Arnold Robbins

Hi All. Thanks to Jeremy C. Reed who's email to the maintainer got the PCC Revived website and CVS back up. Thanks to everyone who let me know that it's back up. :-) My github mirror is https://github.com/arnoldrobbins/pcc-revived and there are links there to the website etc. My repo has a branch 'ubuntu18' with diffs for running PCC on Ubuntu, if that interests anyone. Enjoy, Arnold

2 years, 7 months

off topic: whither the pcc-revived project?

by arnold＠skeeve.com

Hi. I'm hoping some of the BSD people here may know. I've been keeping a git mirror of the PCC Revived project, but in the past month or so it's gone dark. The website is no longer there, the CVS repos don't answer, and an email to the mailing list went unanswered. Does anyone know anything about it? Did it move to somewhere else? I use pcc for testing, it's much faster than GCC and clang. And in general, I think it's a cool thing. :-) Thanks, Arnold

2 years, 8 months

Re: Nice video with Brian Kernighan

by Douglas McIlroy

Brian's tribute to the brilliant regex mechanism that awk borrowed from egrep spurred memories. For more than forty years I claimed credit for stimulating Ken to liberate grep from ed. Then, thanks to TUHS, I learned that I had merely caused Ken to spring from the closet a program he had already made for his own use. There's a related story for egrep. Al Aho made a deterministic regular-expression recognizer as a faster replacement for the non-deterministic recognizer in grep. He also extended the domain of patterns to full regular expressions, including alternation; thus the "e" in egrep. About the same time, I built on Norm Shryer's personal calendar utility. I wanted to generalize Norm's strict syntax for dates to cover most any (American) representation of dates, and to warn about tomorrow's calendar as well as today's--where "tomorrow" could extend across a weekend or holiday. Egrep was just the tool I needed for picking the dates out of a free-form calendar file. I wrote a little program that built an egrep pattern based on today's date. The following mouthful for Saturday, August 20 covers Sunday and Monday, too. (Note that, in egrep, newline is a synonym for |, the alternation operator.) (^|[ (,;])(([Aa]ug[^ ]* *|(08|8)/)0*20)([^0123456789]|$) (^|[ (,;])(([Aa]ug[^ ]* *|(08|8)/)0*21)([^0123456789]|$) (^|[ (,;])(([Aa]ug[^ ]* *|(08|8)/)0*22)([^0123456789]|$) It worked like a charm, except that it took a good part of a minute to handle even a tiny calendar file. The reason: the state count of the deterministic automaton was exponentially larger than the regular regular expression; and egrep had to build the automaton before it could run it. Al was mortified that an early serious use of egrep should be such a turkey. But Al was undaunted. He replaced the automaton construction with an equivalent lazy algorithm that constructed a state only when the recognizer was about to visit it. This made egrep into the brilliant tool that Brian praised. What I don't know is whether the calendar program stimulated the idea of lazy implementation, or whether Al, like Ken before him with grep, already had the idea up his sleeve. Doug

2 years, 8 months

Nice video with Brian Kernighan

by Arnold Robbins

https://www.youtube.com/watch?v=GNyQxXw_oMQ Not quite 30 minutes long. Mostly about the history of awk but some other stuff, including a nice plug for TUHS at the end. Arnold

2 years, 8 months

Editor for Mortals History

by Joseph Holsten

Hello everyone! I’ve been digging into text editor history, and I found: “This provided another huge step forward in usability and allowed us to maintain our modeless approach to screen editing, which was, we feel, superior to the Vi approach.” from https://www.coulouris.net/cs_history/em_story/ This makes me want to know em’s history outside the usual precursor-to-vi narrative. Does anyone know much about the timeline of em from 1971 (QMC Unix installation) to 1976 (Intro to W M Joy @ UCB)? And does anyone know of developments to it after 1976-04-29? That’s the last date within text in the https://www.coulouris.net/cs_history/em_story/emsource/ files. (Also grumble grumble broken touch feature detection in that shar, which indicates last mod of 1996-02-18). Anyone other than Coulouris used em in the last 45 years? -- Joseph Holsten http://josephholsten.com mailto:joseph@josephholsten.com tel:+1-360-927-7234

2 years, 8 months

PCS Munix kernel source

by Paul Ruizendaal

> Message: 4 > Date: Wed, 10 Aug 2022 12:29:24 +0200 > From: Holger Veit <hveit01(a)web.de> > Subject: [TUHS] PCS Munix kernel source > > Hi all, > > I have uploaded the kernel source of 32 bit PCS MUNIX 1.2 to > https://github.com/hveit01/pcs-munix. Thank you for sharing this work, most impressive! > MUNIX was an AT&T SVR3.x implementation ... Are you sure? Could it perhaps be SVR2? (I don’t see any STREAMS stuff that one would expect for R3). > The interesting feature of this kernel is the integration of the > Newcastle Connection network One of my interests is Unix (packet) networking 1975-1985 and that includes Newcastle Connection. I’ve so far not dived deep into this, but your work may be the trigger for some further investigation. My understanding so far (from reading the paper a few years ago) is that Newcastle Connection works at the level of libc, substituting system calls like open() and exec() with library routines that scan the path, and if it is a network path invokes user mode routines that use remote procedure calls to give the illusion of a networked kernel. I’ve briefly looked at the Git repo, but I do not see that structure in the code. Could you elaborate a bit more on how Newcastle Connection operates in this kernel? Happy to communicate off-list if it goes in too much detail. I note that the repo Readme says that the kernel only does some basic IP networking as a carrier, but I also see some files in the tree that seem to implement a form of tcp (and that seem unrelated to the early Unix tcp/ip’s that I have seen so far). Or am I reading too much into these files? === Re-reading the Newcastle Connection paper also brought up some citations from Bell Labs work that seems to have been lost. There is a reference to “RIDE” which appears to be a system similar to Newcastle Connection. The RIDE paper is from 1979 and it mentions that RIDE is a Datakit re-implementation of earlier an earlier system that ran on Spider. Any recollections about these things among the TUHS readership? The other citation is for J. C. Kaufeld and D. L. Russell, "Distributed UNIX System", in Workshop on Fundamental Issues in Distributed Computing, ACM SIGOPS and SIGPLAN (15-17 Dec. 1980). It seems contemporaneous with the Luderer/Marshall/Chu work on S/F-Unix. I could not find this paper so far. Here, too, any recollections about this distributed Unix among the TUHS readership?

2 years, 8 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