TUHS

tuhs@tuhs.org

61 participants
6532 discussions

by Nemo

On 10 November 2017 at 10:50, Nemo <cym224(a)gmail.com> wrote: > On 10 November 2017 at 04:56, Alec Muffett <alec.muffett(a)gmail.com> wrote: >> http://www.cheswick.com/ches/papers/berferd.pdf ? > > Wonderful! I first read this as an appendix in his book and now I > know a second edition of the book is out. > > N. Egg on my face (and keyboard): (1) I failed to send this to the list; and (2) I already have both editions. Apologies, all, especially to Alec. N.

7 years, 7 months

Sandy Fraser on Spider and Unix, 1975

by Paul Ruizendaal

I happened to come across a 1975 report from the University of Warwick which includes a section on the state of computer networking. (https://stacks.stanford.edu/file/druid:rq704hx4375/rq704hx4375.pdf) It contains a section that appears to be a summary of a chat with Sandy Fraser about Spider (pp. 66-69). It has some information on Spider network software and Unix that is new to me, and I find amazing. I had not expected some of this stuff to exist in 1975. Below some of the noteworthy paragraphs: [quote] Spider is an experimental packet switched data communications system that provides 64 full-duplex asynchronous channels to each connected terminal (= host computer). The maximum data-rate per channel is 500K bits/sec. Error control by packet retransmission is automatic and transparent to users. Terminals are connected to a central switching computer by carrier transmission loops operating at 1.544 Mb/s, each of which serves several terminals. The interface between the transmission loop and a terminal contains a stored program microcomputer. Cooperation between microcomputers and the central switching computer effects traffic control, error control, and various other functions related to network operation and maintenance. The current system contains just one loop with the switching computer (TEMPO I), four PDP-11/45 computers, two Honeywell 516 computers, two DDP 224 computers, and one each of Honeywell 6070, PDP-8 and PDP-11/20. In fact many of these are connected in turn to other items of digital equipment. Spider has been running since 1972 and recent work has shifted away from the design and construction of the network itself to developing user services to support other research activities at Bell Labs. A major example of this has been to construct a free-standing file store (extracted in fact from UNIX [88]) and connect it to the network. This is available as a service to any user of the network. [...] The ring is used in different ways by the various computers connected to it. The filestore has already been mentioned. Two computers use this for conventional back-up, and access it on a file-by-file basis. Two other machines - dedicated to laboratory experiments - access it on a block-within-file basis. To help with program development for these dedicated machines, the UNIX system (available on yet more computers) is used during "unavailable" periods for editing and program preparation. The user then leaves his programs in the filestore ready to load when he next gains access to the dedicated machine. Two other "dedicated" machines provide the user interface of UNIX, but lack peripherals and a UNIX kernel! In place of both is a small amount of software that transmits all calls on the UNIX system to a full UNIX system elsewhere! The ring system with its filestore also provides a convenient buffering service. Finally Fraser tells of the time where one of the PDP-11 machines was delivered sans discs. A small alteration to a UNIX system diverted all disc transfer requests to the filestore, where a suitable amount of disc was made available. The system ran a full swapping version of UNIX at about a quarter of the normal speed. [/quote]

7 years, 7 months

Re: [TUHS] pre-more pager?

by jnc＠mercury.lcs.mit.edu

> From: Jon Forrest > In the early days of Unix I was told that it wasn't practical to write a > pager because such a thing would have to run in raw mode in order to > process single letter commands, such as the space character for going on > to the next page. Since raw mode introduced a significant amount of > overhead on already overtaxed machines, it was considered an anti-social > thing to do. Something sounds odd here. One could have written a pager which used 'Return' for each new page, and run it in cooked mode and not used any less cycles (in fact, more, IIRC the cooked/raw differences in handling in the TTY driver). But that's all second-order effects anyway. If one were using a serial line hooked up to a DZ (and those were common - DH's were _much_ more expensive, so poor places like my lab at MIT used DZ's), then _every character printed_ caused an interrupt. So the overhead from printing each screen-ful of text was orders of magnitude greater than the overhead of the user's input to get the next screen. > IIRC later versions of Unix added the ability to respond to a specific > list of single characters without going into raw mode. Of course, that > didn't help when full-screen editors like vi and the Rand editor came > out. Overhead was definitely an issue with EMACS on Multics, where waking up a process on each character of input was significant. I think Bernie's Multics EMACS document discusses this. I'm pretty sure they used the Telnet RCTE option to try and minimize the overhead. Noel

7 years, 7 months

pre-more pager?

by Will Senn

Hi, In looking around the system v7 environment, I don't see a more command anywhere. I downloaded, converted, and attached 1bsd, 2bsd, and finally 3bsd and it was there that I found source for more... 3bsd looks like it's for VAX, not PDP-11, and it doesn't want to compile (looking for some externs that I gather are part of the distro's clib). I may jump ship on V7 and head over to 2.9BSD, which, as I understand it, is a V7 with fixes and these kind of additional tools... In the meantime, how did folks page through text like man sh and such before more? I know how to view sections of text using sed and ed's ok for paging file text (painful, but workable). I just can't seem to locate the idiomatic way of keeping everything from constantly scrolling out of view! Obviously, this isn't a problem on my mac as terminal works fine, but I like to try to stay in character as a 1970 time traveling unix user :). Thanks, Will Sent from my iPhone

7 years, 7 months

Re: [TUHS] 80 columns

by Doug McIlroy

> I do recall 80 column monitors, but I started on 132 column decwriter > IIs and hence have never had sympathy for 80 columns. It's weird that so Interesting. I wonder if that's where the 132 column (alternative) standard came from. No. IBM's printers were 132 columns even before stored-program computers.

7 years, 7 months

Re: [TUHS] margins and indenting, and arbitrary c rules

by jnc＠mercury.lcs.mit.edu

> From: Steve Simon > At the risk of stirring up another hornets nest... I usually try not to join in to non-history threads (this list has too much random flamage on current topics, IMNSHO), but I'll make an exception here... > this means my code is usually fairly narrow. I have what I think are somewhat unusual thoughts on nesting depth, etc, which are: keep the code structure as simple as possible. That means no complex nested if/then/else structures, etc (more below). I'd been moving in this direction for a while, but something that happened a long time ago at MIT crystalized this for me: a younger colleague brought me a routine that had a complex nested if/etc structure in it, which had a bug; I don't recall if he just wanted advice, or what, but I recall I fixed his problem by..... throwing away half his code. (Literally.) That really emphasized to me the downside of complexity like that; it makes it harder to understand, harder to debug, and harder for someone else (or you yourself, once you've been away from it for a while) to modify it. I've been getting more formal about that ever since. So, how did I throw away half his code? I have a number of techniques. I try not to use 'else' unless it's the very best way to do something. So instead of: if (some-conditional) { <some code>; } else { <some other code>; } (iterated, recursively) do: if (some-conditional) { <some code>; xxx; } <some other code>; where xxx is a 'return', or a 'break', or a 'continue'. That way, you can empty your brain once you hit that, and start with a clean slate. This is also an example of another thing I do, which is use lots of simple flow-control primitives; not go-tos (which I abhor), but loop exits, restarts, etc. Again, it just makes things simpler; once you hit it, you can throw away all that context/state in your mind. Keep the control flow structure as simple as possible. If your code is several levels of indent deep, you have much bigger problems than fitting it on the screen. I wrote up a complete programming style guide for people at Proteon working on the CGW, which codified a lot of this; if there's interest, I'll see if I can find a copy (I know I have a hardcopy _somewhere_). Noel

7 years, 7 months

Re: [TUHS] pre-more pager?

by Norman Wilson

Random832: ... and "p" (which is very minimalistic, despite using a few V8-specific library features, but V8 isn't in the web-accessible source archive) from Version 8 research unix. ==== p actually originated outside Bell Labs. I think it was written in the late 1970s at the University of Toronto. I first saw it at Caltech, on the UNIX systems in the High Energy Physics group that I ran for four years. The first few of those systems were set up by Rob Pike, who was at Caltech working on his masters degree (in astrophysics, I think); p was there because Rob brought it. For those who don't know it, p has quite an elegant design. Its default page size is 22 lines, which nicely fit the world of its time: allowed a couple of lines of context between pages on a 24-line CRT; evenly divided the 66-line pages (still!) output by nroff and pr. It uttered no prompt and required neither raw nor cbreak nor even no-echo mode: it printed the final line of each page sans newline; to continue, you typed return, which was echoed, completing that line before the next was printed. It buffered text internally to allow backing up a few pages, so it was possible to back up even when input didn't come from a file (something I'm not sure the more of the time could do). Internally the buffering was done with a standalone library that could have been used in other programs, though I don't know whether it ever was. p also led me to an enlightening programming story. One day I was looking over the code, trying to understand just how the buffering worked; part of it made no sense to me. To figure it out, I decided to write my own simple, straightforward version with the same interface; test and debug it carefully; then lay printouts of the two implementations side-by-side, and walk through some test cases. This revealed that the clever code I couldn't make out in the original was actually buggy: it scrambled data (I forget the details) when read returned less than a full buffer. p (my version) is one of the several programs I bring along to every new UNIX-derivative environment. I use it daily. I have also recently noticed a new bug: on OpenBSD, it sometimes scrambles the last few lines of a file. I have figured out that that has something to do with whether fclose (my version uses stdio) is called explicitly or by exit(3), but I don't know yet whether it's the library's fault or my own. Even the simplest programs have things to teach us. Norman Wilson Toronto ON

7 years, 7 months

Re: [TUHS] margins and indenting, and arbitrary c rules

by jnc＠mercury.lcs.mit.edu

> From: Don Hopkins > https://stackoverflow.com/questions/268132/invert-if-statement-to-reduce-ne… Thanks for that - interesting read. (Among other things, it explains where the 'only have one return, at the end' comes from - which I never could understand.) > Nested if statements have more 'join' points where control flow merges > back together at the end instead of bailing out early Exactly. In high-level terms, it's much like having a ton of goto's. Yes, the _syntax_ is different, but the semantics - and understanding how it works - is the same - i.e. hard. Noel

7 years, 7 months

Re: [TUHS] pre-more pager?

by Doug McIlroy

>> head -20 < filename > > too bad head doesn't exist on v7. sed -20q: same effect, same amount of typing.

7 years, 7 months

C question for the historians

by Arthur Krewat

From a mailing list I belong to, a back-and-forth is going on that I am not involved in. The following sums it up nicely: > It's really the implied equality that's the problem. For example: > > if (flags & DLADM_OPT_PERSIST) { > > would be better written as: > > if ((flags & DLADM_OPT_PERSIST) == 0) { Seriously? What do (or would) "original C" programmers think of this? To me, anything non-zero is "true" so the first is perfectly acceptable. The original assertion in the discussion was that the following is not "right" because of the mixing of bitwise and boolean. > if ((flags & DLADM_OPT_PERSIST) && (link_flags & DLMGMT_PERSIST)) { art k.

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