TUHS

tuhs@tuhs.org

19 participants
6516 discussions

by David

Back when it was all UUCP, a friend setup his own system, bang. He then used his initials as his login, bam. So when asked for his email address he answered bang bang bang bam Bret was a funny guy. David

8 years, 7 months

RIP Dennis Ritchie

by Paul Osborne

Wired is reporting this morning that Dennis has passed away. :( Paul

8 years, 7 months

RIP Dennis Ritchie

by norman＠oclsc.org

The news of Dennis's demise is indeed an echo from five years ago. Dennis would have been amused. Think of it is a day to think about Dennis and what he gave us, instead of Trump and what he threatens. I suspect many of us could use that. Norman Wilson Toronto ON

8 years, 7 months

Re: [TUHS] BSD History Was: Shell control through external commands

by Greg 'groggy' Lehey

Forwarded with permission. On Sunday, 18 September 2016 at 9:07:45 -0700, Kirk McKusick wrote: > On Monday, 12 September 2016 at 11:33:48 +0200, Joerg Schilling wrote: >> norman(a)oclsc.org (Norman Wilson) wrote: >> >>> I don't think the BSD kernel when adopted had much, if any, >>> of sockets, Berkeley's TCP/IP, McKusick's FFS; if it did, >>> they were excised. Likewise any remaining trace of V7's >>> mpx(2) multiplexed-file IPC. >> >> From looking at the CSRG sources, it seems that the filesystem >> project has been founded by Bill Joy and Kirk approached the project >> a year (or more) later and implemented only the parts that are >> related to the block allocation. >> >> Does someone know more? >> >> Joerg > > The 4.1a distribution had the initial socket interface with a > prerelease of the BBN TCP/IP under it. There was wide distribution > of 4.1a. The 4.1b distribution had the fast filesystem added and > a more mature socket interface (notably the listen/accept model > added by Sam Leffler). There was very limited distribution of 4.1b. > The 4.1c distribution had the finishing touches on the socket > interface and added the rename system call to the filesystem. > It also added the reliable signal interface. There was very wide > distribution of 4.1c as there was a 9-month delay in the distribution > of 4.2BSD while DARPA, BBN, and Berkeley debated whether the prerelease > of BBN's TCP/IP should be replaced with BBN's finished version. In > the end the TCP/IP was not replaced as it had had so much field > testing and improvement by the folks running the BSD releases that > it was deemed more performant and reliable. There had been a plan > to release 4.1d that would have the new virtual memory (mmap) > interface, but the delay in getting out 4.2BSD caused that addition > to be delayed for the 4.3BSD release. > > As far as the filesystem is concerned, Bill Joy had done an initial > design primarily coming up with the idea of cylinder groups as a > way to distribute the block and inode bitmaps across the disk in > manageable size pieces. When he handed the project off to me I > received a single header file that defined his prototype for the > superblock and the cylinder group structures. I did all of the > coding from there with Bill doing design review. My feedback from > the folks at the labs was that they were not interested in incorporating > the fast filesystem because it tripled the size of the filesystem > code (from 400 to 1200 lines) and because it needlessly put > functionality into the kernel that could be done in userland > (mkdir/rmdir/rename which together were 400 of the 1200 lines of code). > > Kirk McKusick -- Sent from my desktop computer. Finger grog(a)FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA

8 years, 8 months

Memory mapping device used on PDP-11/20 Unix

by jnc＠mercury.lcs.mit.edu

So the "Odd Comments and Strange Doings in Unix" page: http://www.bell-labs.com/usr/dmr/www/odd.html mentions (at the bottom) a "PDP-11/20 with KS-11 add-on". I'm trying to find info about the KS11, but haven't been able to locate anything. Does anyone have info on it, or, failing that, is there source for an early version of Unix that uses it? (I can create something of a User's Manual for it by reverse engineering from the source.) Thanks! Noel

8 years, 8 months

[ off topic ] Looking for old versions of mawk ...

by Aharon Robbins

Hi All. I'm looking for old tarballs of mawk. Specifically all versions of mawk 1.2 and mawk 1.3 prior to 1.3.2. I found a 1.3.2 tarball on the net (not sure how authentic it is ; if you have a real one, please let me know) and I have 1.3.3. Much thanks, Arnold Robbins

8 years, 8 months

Re: [TUHS] BSD/v8 TCP/IP

by Doug McIlroy

> Interesting, but then nobody did run a modern shell on one of these machines or > everybody did type slowly, so the character lossage problem did not occur. I'm afraid I don't get the point, apparently something about the relative performance of stream- and non-stream tty drivers. How do shells get into the act? And didn't uucp, which was certainly not a slow typist, appear like any dial-up connection and thus use /dev/ttyxx? (I cannot recollect, though, when dial-up uucp finally ceased.) DOug

8 years, 8 months

Re: [TUHS] Shell control through external commands

by norman＠oclsc.org

Doug McIlroy: "Re-port" may be a bit strong. Internet stuff from Berkeley was folded into the research code (for a huge increase in kernel size). But I think it was done by pasting Berkeley code into local source, rather than the other way around. ==== Actually it was more nearly: -- Adopt 4.1c BSD kernel -- Graft in Research-specific things it was important to keep: in particular Dennis's stream subsystem, Tom Killian's original /proc, Peter Weinberger's early network file system client code (the server was just a user-mode program) and simple hackery to speed up the file system without great fuss (make the block size 4KiB and move the free list to a bitmap; no cylinder groups or other radical changes). Also device drivers to support Datakit, at the time our workhorse network. I think a file-system switch went in early as well, spurred by having both /proc and pjw's network file system; it wasn't used to support multiple disk-file-system layouts, though it could have been. -- Outside the kernel, keep pretty much the then-current Research commands, including Blit/5620 support, the cleaned up and slightly-extended Bourne shell, and whatnot. I don't think the BSD kernel when adopted had much, if any, of sockets, Berkeley's TCP/IP, McKusick's FFS; if it did, they were excised. Likewise any remaining trace of V7's mpx(2) multiplexed-file IPC. I'm going by the state the system was in when I arrived in August 1984, plus a short note written by Weinberger that I came across later. TCP/IP support didn't show up until later, I think summer 1985, though it might have been a year later. The first cut was done by Robert T. Morris (later famous for a buggy program that broke the Internet), who did several summers as an intern; he took the code from (I think) 4.2 BSD, and constructed some shims to fit it into the stream world. Paul Glick later cleaned it up a lot, removing the need for most of the shimmery. Further evolution followed, of course, including a complete rewrite of the interface between drivers (device, file system, and stream) and the rest of the system, which made configuration much more straightforward. Also a rampage on my part to identify code that was no longer useful and kick it out; I took special pleasure in removing ptrace(2) (even though I had to change adb and sdb first to use /proc). But that was all later. Norman Wilson Toronto ON

8 years, 8 months

Re: [TUHS] Shell control through external commands

by Doug McIlroy

Gerard Holzmann took the true and false commands as the jumping-off point for "Code Inflation", an installment of his "Reliable Code" blog and column in IEE Software. An informative, but depressing, read: http://spinroot.com/gerard/pdf/Code_Inflation.pdf Doug

8 years, 8 months

Re: [TUHS] BSD/v8 TCP/IP

by Doug McIlroy

Norman wrote The earliest stream-I/O-system-based tty driver I'm aware of was already in the Research kernel when I interviewed at Bell Labs in early 1984. I have a vague memory that it was a couple of years older than that, but I cannot find any citations to back up either of those memories. Dennis described streams in the special Unix issue of the BSTJ, Oct 1984, and noted that "it runs on about 20 machines in ... Research ... Although it is being investigated in other parts of AT&T Bell Laboratories, it is not generally available." The manuscript was received October 18, 1983. Doug Doug

8 years, 8 months

Re: [TUHS] BSD/v8 TCP/IP (was Shell control through external commands)

by Norman Wilson

Because of the design bug I mentioned, I searched for UNIX sources from AT&T that include streams support, but could never find any. ===== None of the Research systems after 32/V was ever distributed except to a handful of sites under site-specific letter agreements that forbade redistribution. This is a bug, not a feature, but there it is. It was easy to get approval to write a paper, much harder to get permission to distribute code, especially when the code in some way overlapped the Official Product. Warren and I (and Dennis, when he was still alive) hoped to do something about some years back, but it's a lot harder than it used to be because it is harder to find a corporate entity that is confident enough to give permission, even for stuff that is so old that it is unlikely to have a trumppenceworth of commercial value. Then IBM vs SCO intervened, and now things are even more fragmented. There may be other efforts under way now and then to negotiate the legal minefield. I wish them all well, and will help them where I can. Norman Wilson Toronto ON

8 years, 8 months

Re: [TUHS] BSD/v8 TCP/IP (was Shell control through external commands)

by Norman Wilson

I'm not sure of the point of this mine-is-bigger-than-yours argument, but: The earliest stream-I/O-system-based tty driver I'm aware of was already in the Research kernel when I interviewed at Bell Labs in early 1984. I have a vague memory that it was a couple of years older than that, and was first implemented in a post-V7 PDP-11 system; also that I had heard about it first at a USENIX conference in 1982 or 1983; but I cannot find any citations to back up either of those memories. I do know that I'd heard of it while I was still working at Caltech, because I remember thinking about what a good idea it was and about possibly trying to do my own version of it, but I never did. I left Caltech at the end of June 1984, spent the following month touring nearly the entire Amtrak long-distance network in a single long reservation (it was possible to do that with surprisingly few overnight stops off the train in those days), and started at Bell Labs at the beginning of August. Norman Wilson Toronto ON

8 years, 8 months

Re: [TUHS] Shell control through external commands

by Norman Wilson

It sounds like my understanding of the different 4.1x versions is just mistaken. If 4.1c had FFS and sockets, the kernel on which V8 was built must have been an earlier 4.1x. I believe the reason for adopting that kernel, rather than sticking with 32/V, was exactly to get paging support. There was a competing 32/V descendant with paging, written by John Reiser at Holmdel, which I gather was thought by many to be much cleaner technically; e.g. he unified the block-device buffer cache and the memory-page cache, and implemented copy-on-write paging rather than resorting to the messy vfork. I have heard that there was considerable argument and hand-wringing over whether to use Reiser's kernel or the BSD one. It all happened well before I arrived, and I don't know what the tradeoffs were, though one was certainly that Reiser's management didn't support his work and nobody in 1127 was keen to have to take it over. Norman Wilson Toronto ON

8 years, 8 months

Re: [TUHS] Shell control through external commands

by Norman Wilson

Joerg Schilling: The colon was introduced by AT&T around 1983. It was used for Bourne Shell scripts. Some of these scripts made it into SVr4 and caused problems with non-Bourne compatible other shells. ==== Interesting. I never knew of that convention. I remember seeing shell scripts with a : at the front, but thought that was just to make sure the first character wasn't # even if the script began with a comment. Since some here had never heard of the #-means-csh convention, I should perhaps explain about :. In pre-Bourne shells that used the simple external control-flow mechanisms that I think were discussed here a few months ago, : was used to mark a label: goto(1) would seek to the beginning of its standard input, then read until it encountered a line of the form : label with the desired label, then exit with the seek pointer at the first character of the following line. : was a no-op command; I forget whether it was implemented within the shell or externally. Either way, that made it useful as a comment character, but somewhat clumsy: it was just a command, with no special parsing rules attached. A comment using : had to begin at a command boundary, and its arguments were parsed in the normal way: rm -rf * : you don't want to do this was probably not what you wanted, instead you had to type rm -rf * ; : "you don't want to do this" or the like. csh used # as a comment character from the beginning. Bourne adopted it too. Norman Wilson Toronto ON

8 years, 8 months

BSD mail(1) line addressing

by stanley lieber

8 years, 8 months

Re: [TUHS] Shell control through external commands

by Norman Wilson

Random832: The existence of cd as a real command is a bit silly (Ubuntu doesn't seem to bother with it), but it is technically required by the standard. === Just for the record, Fedora 21 supplies /bin/cd, as part of package bash-4.3.42-1. Interestingly, it is a shell script: lu$ cat /bin/cd #!/bin/sh builtin cd "$@" lu$ As has been said here, it's hard to see the functional point. Others have remarked on the continued life of /bin/true and /bin/false. There are some who use those as shells in /etc/passwd for logins that should never actually be allowed to do anything directly. I have no strong personal feeling about that, I'm just reporting. And to be fair (as has also already been displayed here), the copyright notice inserted in the once-empty /bin/true was hundreds of bytes long, not thousands. Let us call out silliness, but let us not make it out as any sillier than it actually is. Norman Wilson Toronto ON UNIX old fart and amateur pedant

8 years, 8 months

Re: [TUHS] Shell control through external commands

by norman＠oclsc.org

I remember reading about #! in the early 1980s, and having mixed feelings about it, as I still do. The basic idea is fine, if annoyingly limited; but that the kernel has to decide, in effect, whether to treat a header as binary or text bothers me. Were I designing a new system from scratch today, I'd just make the header all text; the small extra space and time for the kernel to parse that for binaries doesn't matter any more. It certainly did when #! was invented, though. I had the impression at the time that it came from Berkeley, but I think I later heard from the horse's mouth that it was originally Dennis's idea. I don't think anyone has yet laid out the complete story of what came before: 1. Originally, the shell would exec(file), and if exec returned ENOEXEC, would open the file and treat it as shell commands. 2. Then came the C shell, and a problem: did file contain commands for csh or sh? A hack emerged: if csh encountered a script file, it would read the first character; if that was '#' it was a csh script, otherwise it handed off to /bin/sh. None of this helped when some program other than the shell called exec on a shell script. That's one reason execlp and execvp appeared. (The other is that they observe $PATH if the command pathname has a single element.) I don't know offhand whether there was ever an execlp/vp that implemented the #-means-csh convention. Anyone else remember? Norman Wilson Toronto ON

8 years, 8 months

Re: [TUHS] Shell control through external commands

by Doug McIlroy

> 8th edition was essentially a re-port of 4.1c BSD, correct? "Re-port" may be a bit strong. Internet stuff from Berkeley was folded into the research code (for a huge increase in kernel size). But I think it was done by pasting Berkeley code into local source, rather than the other way around. But, since much of the rest of the BSD kernel was Bell Labs code, it's probably right that the result of the merge had more code in common with BSD than with Research. If you ask, though, what fraction of Research code survived the merge, it was probably larger than the surviving fraction of the total BSD code. Doug

8 years, 8 months

Re: [TUHS] Shell control through external commands

by Doug McIlroy

> IIRC #! originated at Bell Labs but it got out to the world via BSD. > Perhaps Dr. McIlroy could confirm / deny / expand upon the details (please?) I recall Dennis discussing the feature at some length before installing it. So the exact semantics, especially the injected argument, are almost] certainly his. I don't know whether he built on a model from elsewhere. #! appeared between v7 (1979) and v8 (1985). As v8 was never released, it clearly made its way into the world via BSD and USG. BSD, being more nimble, was likely first. doug

8 years, 8 months

Popular 1980 languages [Was: Comments on "C"]

by Nemo

On 9 September 2016 at 17:15, Mary Ann Horton <mah(a)mhorton.net> wrote (in part): > When I was at Berkeley working on my dissertation, I wrote a tool that would > let you edit a text file written in any language you could define with a > grammar, with syntax and semantic error checking while you edited. I had > grammars for several popular (in 1980) languages. My curiosity is piqued. What were these languages? N.

8 years, 9 months

Re: [TUHS] Shell control through external commands

by Nemo

On 10 September 2016 at 05:41, Joerg Schilling <schily(a)schily.net> wrote: > Michael Kjörling <michael(a)kjorling.se> wrote: > >> On 10 Sep 2016 09:45 +0200, from dnied(a)tiscali.it (Dario Niedermann): >> > Il 15/07/2016 alle 14:27, Norman Wilson ha scritto: >> >> lu$ cat /bin/cd >> >> #!/bin/sh >> >> builtin cd "$@" >> >> lu$ >> > >> > But doesn't this change the current dir only in the child shell? >> > Which then exits right after the second line, parent shell's $PWD >> > unaffected. I really don't see how this script is useful. >> >> It does appear rather useless. Curiously, Debian (checked on Wheezy = >> bash 4.2+dfsg-0.1+deb7u3 and Jessie = bash 4.3-11+b1) seems to not >> supply anything like that, so it would appear to be some kind of >> Fedora-ism rather than a part of anything upstream; that, or the >> Debian folks are actually paying attention to what they ship onto >> users' systems. > > POSIX requires some commands to be callable via exec(). Solaris 10 has the following amusing implementation (/usr/bin/cd): #!/bin/ksh -p # #ident "@(#)alias.sh 1.2 00/02/15 SMI" # # Copyright (c) 1995 by Sun Microsystems, Inc. # cmd=`basename $0` $cmd "$@" N.

8 years, 9 months

Re: [TUHS] Comments on "C"

by jnc＠mercury.lcs.mit.edu

> From: Blake McBride > After about 30 years of C, there are only three things I would have > liked to see: > 1. Computed goto Can't you make a switch statement do what you need there? The two things I really missed were: - BCPL's ValOf/ResultIs, for making more complex macros (although with the latest modern compilers, which inline small functions, this is less of an issue) - The ability to 'break' out of more than one level of nesting; one either has to stand on one's head (code-wise), or use a goto Noel

8 years, 9 months

Re: [TUHS] Comments on "C"

by Doug McIlroy

> After about 30 years of C, there are only three things I would have liked to see: > 1. Computed goto ... > Computed goto's are good for interpreters. A computed goto, of course, is merely an optimized switch. Dennis installed this optimization early in the evolution of C. The main driving force was the performance and size of the PDP-11 Unix kernel. As functionality grew, resource usage was repeatedly tamped down by improving C's code generation. The switch optimizer chose among three strategies: naive, binary decision tree, and computed goto, depending on the number and density of switch alternatives. Hybrid strategies may have been used, too, but my memory is hazy on this point. In particular the optimization improved system-call dispatch--thus achieving the objective, "good for interpreters". I assume (I hope not unrealistically) that this optimization has been in the repertoire of mainline C compilers ever since. > (Or perhaps require C to support tail recursion.) I can imagine making a strong recommendation in the standard for optimizing switches and (at least direct) tail recursion. Doug

8 years, 9 months

Re: [TUHS] Comments on "C"

by Doug McIlroy

I sent a similar message some time ago, but I haven't seen it appear in the mailing list, so here goes again. Apologies if it ends up as a duplicate. > After about 30 years of C, there are only three things I would have liked > to see: > > 1. Computed goto > ... > Computed goto's are good for interpreters. A computed goto is an optimized switch, and that optimization goes back to the original C compiler. Mostly driven by considerations of size and speed of the Unix kernel, Dennis quite early on taught the compiler to choose among three compilation strategies for a switch: a chain of comparisons, a tree of comparisons, or a computed goto, depending on the number and density of alternatives. The compilation of the system-call dispatch table was a perfect example of "good for interpreters." I have always assumed that other mainline compilers behave similarly, but I have no solid knowledge about that. doug

8 years, 9 months

Comments on "C"

by Dave Horsfall

Seen on another list... And I got quoted by Steve Bellovin :-) -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." ---------- Forwarded message ---------- From: Kent Borg To: cryptography(a)metzdowd.com Subject: Re: [Cryptography] "NSA-linked Cisco exploit poses bigger threat than previously thought" On 08/25/2016 06:06 PM, Steven M. Bellovin wrote: > I first heard more or less that line from Doug McIlroy himself; he > called C the best assembler language he'd ever used. Ancient fun-fact: Years ago there was an article in Byte magazine describing how a useful subset of C could be directly assembled into 68000 code. Not compiled, assembled. C is a stunning assembly language. When those wild-eyed nerds at AT&T decided to write Unix not in assembly but in C (where was management!?), it was radical. But C was up to (down to?) the task, it was pioneering then and is still doing useful things decades later: From the fastest supercomputers to some pretty slim microcontrollers (plus a hell of a lot of Android devices) multitudes of computers run a Linux kernel compiled from the *same* C source code, with almost no assembly. Big-endian, little-endian: no matter. Different word lengths: no matter. That is one impressive cross-platform assembly language! Unfortunately, C is also a dangerous language that mortal programmers cannot reliably wield. -kb, the Kent who knows he is pressing his luck on a moderated cryptography mailing list, but C deserves a lot of respect, as it also deserves to be efficiently sent into a dignified retirement. _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

8 years, 9 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS