Sorry to flog this topic, but the two examples below are an
unfair comparison. What happened to the multiplications in the
second? And two of the [enter]s in the first are unnecessary.
Ironically three of the four operations in the second are
actually reverse Polish! If you had to utter sqrt first,
as we do on paper and in speech, things wouldn't look so great.
[a] [enter]
[a] [enter]
[multiply]
[b] [enter]
[b] [enter]
[multiply]
[add]
[square root]
[a]
[square]
[plus]
[b]
[square]
[square root]
Doug
Once in a while a new program really surprises me. Reminiscing a while
ago, I came up with a list of eye-opening Unix gems. Only a couple of
these programs are indispensable or much used. What singles them out is
their originality. I cannot imagine myself inventing any of them.
What programs have struck you similarly?
PDP-7 Unix
The simplicity and power of the system caused me to turn away from big
iron to a tiny machine. It offered the essence of the hierarchical
file system, separate shell, and user-level process control that Multics
had yet to deliver after hundreds of man-years' effort. Unix's lacks
(e.g. record structure in the file system) were as enlightening and
liberating as its novelties (e.g. shell redirection operators).
dc
The math library for Bob Morris's variable-precision desk calculator
used backward error analysis to determine the precision necessary at
each step to attain the user-specified precision of the result. In
my software-components talk at the 1968 NATO conference on software
engineering, I posited measurement-standard routines, which could deliver
results of any desired precision, but did not know how to design one. dc
still has the only such routines I know of.
typo
Typo ordered the words of a text by their similarity to the rest of the
text. Typographic errors like "hte" tended to the front (dissimilar) end
of the list. Bob Morris proudly said it would work as well on Urdu as it
did on English. Although typo didn't help with phonetic misspellings,
it was a godsend for amateur typists, and got plenty of use until the
advent of a much less interesting, but more precise, dictionary-based
spelling checker.
Typo was as surprising inside as it was outside. Its similarity
measure was based on trigram frequencies, which it counted in a 26x26x26
array. The small memory, which had barely room enough for 1-byte counters,
spurred a scheme for squeezing large numbers into small counters. To
avoid overflow, counters were updated probabilistically to maintain an
estimate of the logarithm of the count.
eqn
With the advent of phototypesetting, it became possible, but hideously
tedious, to output classical math notation. Lorinda Cherry set out to
devise a higher-level description language and was soon joined by Brian
Kernighan. Their brilliant stroke was to adapt oral tradition into written
expression, so eqn was remarkably easy to learn. The first of its kind,
eqn has barely been improved upon since.
struct
Brenda Baker undertook her Fortan-to-Ratfor converter against the advice
of her department head--me. I thought it would likely produce an ad hoc
reordering of the orginal, freed of statement numbers, but otherwise no
more readable than a properly indented Fortran program. Brenda proved
me wrong. She discovered that every Fortran program has a canonically
structured form. Programmers preferred the canonicalized form to what
they had originally written.
pascal
The syntax diagnostics from the compiler made by Sue Graham's group at
Berkeley were the mmost helpful I have ever seen--and they were generated
automatically. At a syntax error the compiler would suggest a token that
could be inserted that would allow parsing to proceed further. No attempt
was made to explain what was wrong. The compiler taught me Pascal in
an evening, with no manual at hand.
parts
Hidden inside WWB (writer's workbench), Lorinda Cherry's Parts annotated
English text with parts of speech, based on only a smidgen of English
vocabulary, orthography, and grammar. From Parts markup, WWB inferred
stylometrics such as the prevalance of adjectives, subordinate clauses,
and compound sentences. The Today show picked up on WWB and interviewed
Lorinda about it in the first TV exposure of anything Unix.
egrep
Al Aho expected his deterministic regular-expression recognizer would beat
Ken's classic nondeterministic recognizer. Unfortunately, for single-shot
use on complex regular expressions, Ken's could finish while egrep was
still busy building a deterministic automaton. To finally gain the prize,
Al sidestepped the curse of the automaton's exponentially big state table
by inventing a way to build on the fly only the table entries that are
actually visited during recognition.
crabs
Luca Cardelli's charming meta-program for the Blit window system released
crabs that wandered around in empty screen space nibbling away at the
ever more ragged edges of active windows.
Some common threads
Theory, though invisible on the surface, played a crucial role in the
majority of these programs: typo, dc, struct, pascal, egrep. In fact
much of their surprise lay in the novelty of the application of theory.
Originators of nearly half the list--pascal, struct, parts, eqn--were
women, well beyond women's demographic share of computer science.
Doug McIlroy
March, 2020
Tomasz Rola writes on Thu, 19 Mar 2020 21:01:20 +0100 about awk:
>> One task I would be afraid to use awk for, is html processing. Most of
>> html sources I look at nowadays seems discouraging. Extracting
>> anything of value from the mess requires something more potent, I
>> think.
If you want to tackle raw HTML from abitrary source, then I agree with
you: most HTML on the Web is not grammar conformant, there are
numerous vendor extensions, and the HTML is hideously idiosynchratic
and irregularly formatted.
The solution that I adopted 25 years ago was to write a grammar
recognizing, but violation lenient, prettyprinter for HTML. It has
served well and I use it many times daily for my work in the BibNet
Project and TeX User Group bibliography archives, now approaching 1.55
million entries. The latest public release is available here:
http://www.math.utah.edu/pub/sgml/
I notice that the last version there is 1.01; I'll get that updated in
a couple of days to the latest 1.03 [subject to delays due to major
work dislocations due to the virus]. The code should install anywhere
in the Unix family without problems: I build and validate it on more
than 300 O/Ses in our test farm.
With standardized HTML, applying awk is easy, and I have more than 450
awk programs, and 380,000 lines of code, that process publisher
metadata to produce rough BibTeX entries that numerous other tools,
and some manual editing, turn into clean data for free access on the
Web.
For some journals, I run a single command of fewer than 15 characters
to download Web pages for journal issues for which I do not yet have
data, and then a single journal-specific command with no arguments
that runs a large shell script with a long pipeline that outputs
relatively clean BibTeX that then normally takes me only a couple of
minutes to visually validate in an editor session. The major work
there is bracing of proper nouns in titles that my software did not
already handle, thereby preventing downcasing of those words in the
many bibliography styles that do so.
I'm on journal announcement lists for many publishers, so I often have
new data released to the Web just 5 to 10 minutes after receiving
e-mail about new issues.
The above-mentioned archives are at
http://www.math.utah.edu/pub/bibnethttp://www.math.utah.edu/pub/tex/bibhttp://www.math.utah.edu/pub/tex/bib/index-table.htmlhttp://www.math.utah.edu/pub/tex/bib/idxhttp://www.math.utah.edu/pub/tex/bib/toc
They are mirrored at Universität Karlsruhe, Oak Ridge National
Laboratory, Sandia National Laboratory, and elsewhere.
Like Al Aho, Doug McIlroy, and Arnold Robbins, I'm a huge fan of awk;
I believe that I was the first to port it to PDP-10 TOPS-20 and VAX
VMS in the mid-1980s, and it is one of the first mandatory tools that
I install on any new computer.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- 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/ -
-------------------------------------------------------------------------------
i never got on with rpn, even though i am the kind if person who should - i have a little bit of dyslexia, perhaps thats why.
when i moved to plan9 i found it included hoc from K&P, just used that for the odd bits of maths i need.
-Steve
There's been a lot of discussion about early Unix on Intel, National
Semi, Motorola, and Sparc processors. I don't recall if Unix ran on
the Z8000, and if not, why not.
As I remember the Z8000 was going to be the great white hope that
would continue Zilog's success with the Z80 into modern times.
But, it obviously didn't happen.
Why?
Jon
I sent it off list to Chet and Paul but it's too big for Warren's
reflector. I'll work with him to get it separately. If anyone else wants
it before, please let me know off list.
Clem
On Mon, Mar 16, 2020 at 10:37 AM Clem Cole <clemc(a)ccc.com> wrote:
> Here you go...
>
> Warren - Would please be able to add to the docs/paper directories...
> USENIX Summer 1985 June 11-14
>
Hi,
Would anyone know how the CSRG made available updates to the public
distribution of Net/2 before releasing 4.4 BSD Lite?
Net/2 was released on tape in July 1991 as represented in the TUHS
archive. The first mention I see of the sources appearing online is old
usenet posts announcing the bsd-sources mirror on uu.net starting in
January 1992.
However, the Net/2 derived versions of NetBSD (0.8-0.9) and FreeBSD
(1.0-1.1.5.1) imported userland tools revised after both dates in early
1993, when there are also mentions of using 4.4 code in the commit logs
(well before Lite 1 was released in March 1994).
At this point, I'm wondering if the latest code was issued on tape at the
time of a request for Net/2 sources and there were direct uploads from
the CSRG to any online mirrors before the USL lawsuit?
Thanks,
Dan Plassche
--
Dan Plassche
Meant for the list (and don't get me started on Reply All)...
-- Dave
---------- Forwarded message ----------
Date: Fri, 13 Mar 2020 21:43:51 +1100 (EST)
From: Dave Horsfall <dave(a)horsfall.org>
To: Greg 'groggy' Lehey <grog(a)lemis.com>
Subject: Re: [TUHS] Command line options and complexity
On Fri, 13 Mar 2020, Greg 'groggy' Lehey wrote:
>> -h is a gnuism, isn't it?
>
> It might have originated there, but then I would expect it to be spelt
> '--produce-human-readable-output'. I haven't been able to establish from the
> FreeBSD sources or commit logs when it was introduced. It would clearly have
> been a reimplementation.
It's in "df" as well, praise Cthulu:
aneurin# df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/ad0s1a 496M 302M 154M 66% /
devfs 1.0K 1.0K 0B 100% /dev
tmpfs 1000 272K 999M 0% /tmp
/dev/ad0s1d 2.9G 1.4G 1.2G 54% /usr
/dev/ad0s1e 989M 581M 329M 64% /var
/dev/ad0s1f 3.9G 2.2G 1.4G 62% /home
/dev/ad0s1g 8.9G 8.0G 127M 98% /usr/local
fdescfs 1.0K 1.0K 0B 100% /dev/fd
procfs 4.0K 4.0K 0B 100% /proc
(Memo to self: see where all the room has gone in /usr/local, as that's where I
assigned the leftover space after the other partitions.)
No, I've never liked stuffing everything under the root file system as both the
Mac and Penguin do; fill the root file system and you're hosed (and I also have
an itch about /tmp being there as it's a world-writable directory).
>> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls.html does
>> specify the -S switch. That's POSIX, isn't it?
>
> So it is! This was the first option that I wanted to add, back when I still
> had practice wheels. I asked my mentor, and he said "not the Unix way", so I
> let it be. Then Wes Peters came up with the idea, and I thought he committed
> it, but it seems that it ultimately came from Kostas Blekos in 2005, based on
> the same feature on NetBSD and OpenBSD. I wonder when it made it to POSIX.
Years ago I wrote a simple script "lss" which did the sort after being
howled down on one of the FreeBSD lists; what a surprise to see "-S"...
Heck, back in my UNSW days I suggested extending stty() to cover non-TTY
devices and got trashed by the AGSM/ElecEng mob; well well, look at ioctl()
when it appeared.
-- Dave
> -,: Make the option standard: output numbers with commas every 3 digits
A terrible idea. Whatever ls outputs should be easy for other
programs to read, and few know how to read commafied numbers.
As others have mentioned, this is also a strong argument for
changing the output representation of dates.
I often do mailx -H | sort -t/ -k2nr to sort in reverse order of size--a
quick way to find the pay dirt when I want to shrink my mailbox.
This would never fly if the sizes had commas. (Well, I suppose I
could add sed s/,//g to the pipeline.)
Doug
Nothing I'm aware of. I didn't mind throwing "tac" over the wall, because
it was trivial, probably a couple hours work for me, under a minute for
Ken. But the rsort source is not at all trivial, and still of potential
value to AT&T.
The source managed to get out as part of the "Hancock" project. I found a
link in
https://www.wired.com/2007/10/att-invents-pro/
but the page is gone. It probably didn't help that Wired titled the article
*AT&T Invents Programming Language for Mass Surveillance*
That's horse-pucky, akin to "Pitchfork makers invent device for spearing
babies". I'm trying to track down a copy that was released publicly. I'm
not hopeful.
On Mon, Mar 9, 2020 at 11:28 AM Tyler Adams <coppero1237(a)gmail.com> wrote:
> Woah, this sounds really useful, is there anything like it today?
>
> On Sun, Mar 8, 2020, 16:32 John P. Linderman <jpl.jpl(a)gmail.com> wrote:
>
>> In the "UNIX SYSTEM" issue of the BSTJ back in October of 1984, I
>> suggested that it might be better, both for functionality *and*
>> performance, to have a sort that only worked on records with a *single*
>> key to be sorted *lexicographically*, and put all the complexity of
>> dealing with native integers, dates, case-mapping, etc into a key-building
>> front end. I wrote such a sort built around a radix sort. The sort
>> itself sported very few options relating to record format (fixed-length,
>> newline terminated, and header-based, where an ascii header identified
>> record length, and, optionally, key position and key length), where to find
>> the key in fixed-length and newline terminated records, merge-only, check
>> sort order only, unique, strip off the sort key (to avoid the need for a
>> post-process in many cases). Key-building was usually near-trivial using
>> awk or perl or a few commands for tweaking native integer and floating
>> point values so they would sort lexicographically. The sort was stable and
>> blazingly fast. Some summer students once complained to me that I was
>> messing up a paper they were writing because my external sort was faster
>> than an internal qsort... the kind of complaint that warms one's heart. At
>> the back of my mind was a generic key-building library that would
>> accommodate (decimal) numbers of arbitrary length, with or without "E"
>> exponents, dates in various formats, string collation for Unicode, etc. It
>> remains at the back of my mind.
>>
>> On Sun, Mar 8, 2020 at 5:32 AM Tyler Adams <coppero1237(a)gmail.com> wrote:
>>
>>> The idea of a simple rule is great, but the suggested rule fails on sort
>>> -u which afaik came after sort | uniq for performance reasons.
>>>
>>> Another idea on the same vein is that a flag should be added only when
>>> the job can be done inside the program and not with stdin/stdout (or no
>>> flag can be added if one can reproduce the same behavior using pipelines).
>>>
>>> So, you need sort -u because only within sort can you get the
>>> performance needed to get the job done.
>>>
>>> But you don't need -h in ls -lh. All the information to render a human
>>> readable number is present on stdout of ls -l. You could easily have a
>>> filter which renders numbers with options like adding commas, dots,
>>> scientific notation, precision, money, units, etc.
>>>
>>> Tyler
>>>
>>> On Sun, Mar 8, 2020, 07:33 Jon Steinhart <jon(a)fourwinds.com> wrote:
>>>
>>>> After following this discussion, I guess that I have a simplistic way to
>>>> determine whether something should be a dash option or a filter. In
>>>> general, I'd make a filter if whatever it was doing was applicable to
>>>> more than one command, a dash option otherwise.
>>>>
>>>> Jon
>>>>
>>>
On (post-)V10:
echo '.EQ
define f % $1 %
f("a,b")
.EN' | eqn
emits
.lf 1 -
.EQ
.ds 11 "\f2a,b\fP
.if 1m>\n(.v .ne 1m
.rn 11 10
\&\*(10
.EN
.lf 5
On a Linux system with GNU eqn (groff) version 1.22.3,
the output is rather more verbose (48 lines!), but
the troff result is just an a (rather than the proper
a,b) and eqn complains
eqn:<standard input>:3: newline before end of quoted text
I assume this Linux result is more or less what Doug
expects.
Norman Wilson
Toronto ON
(still heating my basement with a MicroVAX)
I was surprised that eqn parses the macro call below as having two
arguments, each with an unmatched ".
.EQ
define f % $1 %
f("a,b")
.EN
Ralph Corderoy found that the comma can be hidden by replacing it with
\N'44'. A somewhat cleaner way to hide it is
.EQ
define f % $1 %
define comma % , %
f(a comma b)
.EN
This works too.
.EQ
f(f(a comma b))
.EN
[Note for cognoscenti. Eqn's practice in expanding macro arguments clashes
with troff's. Eqn expands nested calls after substitution in the outer
macro definition; troff expands while collecting arguments of the outer
call. I've found no documentation of the eqn behavior.]
The classical man page for eqn asserts categorically, `Strings enclosed
in double quotes " " are passed through untouched.' Unfortunately the
version of Kernighan/Cherry User's Guide that describes macros with
arguments says little about how arguments are parsed except that they
are separated by commas--nothing about whether commas are hidden by
parentheses or quotes.
Certainly splitting at a comma in a quoted string violates the plain
meaning of the man-page assertion. If anyone has v10 (or perhaps something
else after v7) running, I'd be grateful to learn what classic eqn actually
did. I'm morally certain that if it did split and anyone had complained
to Brian, he would have fixed it.
These observations lead me to file a bug report.
Doug
> This begs questions of stability
Astute question. I had that in my original draft, but eliminited
it for what I thought was clarity. Anyway, depending on implementation
of sort, you may need sort -s. Of course it doesn't matter which copy
among several equal lines uniq produces, nor does it matter in sort
when there are no comparison options--they're all the same.
> I don't know enough about the
> internals of sed to know even what algorithm it uses
> (... a disk-based merge sort?)
sed is not a sorting program--basically it copies input to
output, making line-by-line editing changes. That's the
way I meant to use it in sed s/nonkeys//|sort -keys|uniq.
(I have added options to sort, hopefully for clarity).
The argument to sed here means substitute the empty
string for the nonkey fields (specified by a regular expression).
If "sed" was a typo for "sort", all versions of sort that
I know of use an internal sorting algorithm for big chunks
of the file, then combines the chunks by merge. But internal
sorting varies all over the map--variations on quicksort,
radix sort, merge sort, ...
Doug
> The idea of a simple rule is great, but the suggested rule fails on sort -u
> which afaik came after sort | uniq for performance reasons.
As the guilty party for most of sort's comparison options, I can
attest that efficiency was not an objective of -u. It was invented
precisely because uniq had proved useful, but not when one was
interested in uniqueness only of some key aspect of the data.
-u differs from uniq in that -u selects samples based on
equality of keys, not equality of lines. In the default
case of whole-line keys, sort -u of course does exactly
what sort|uniq does.
For many applications of -u with keys, the non-key fields
are not of interest. Then sed s/nonkeys//|sort|uniq may
suffice. But sed did not exist when -u was invented.
And not all sort key specs are easily imitated in sed.
Doug
Derek Fawcus:
Yeah - I always found that a bit weird, having to use socketpair()
to get a bidirectional "pipe".
In the Research system, pipes became bidirectional when
they became streams. That happened slightly before my
time, but so far as I know it broke absolutely nothing.
Some time in the late 1980s, the System V people wanted
to allow pipes to be streams, but were worried about the
bidirectionality. They proposed to have a new system call
to make a bidirectional pipe.
I attended a meeting with the relevant programmers and
program manager to find out why they thought pipes couldn't
just be bi-directional, as they had been without fuss in
the Research system for some years. They agreed with me
that that was how it ought to be; the trouble was that
System V releases all had to pass an official System V
Verification Suite (reasonable enough), and that suite
checked not only that you could read the one pipe file
descriptor and write the other, but that you couldn't
do it the wrong way.
Wait a minute, I said. I'm pretty sure that's not how
the official System V Interface Description reads. Anyone
got a current copy handy?
We found one, and we looked, and sure enough, the official
verification suite was wrong. The specification said
that data written to fd[1] must be readable from fd[0],
but nothing about the other direction: full-duplex pipes
were not required but neither were they outlawed!
The programming group was delighted: I'd given them the
ammo they needed to do it right (make pipes streams, and
make them full-duplex by default). I believe that is
how it came out, though the only reference I have is
Solaris 10, where the manual page specifically says
that what pipe(2) makes is full-duplex (and a stream).
I wish POSIX and Linux and the BSDs would catch up; that
was only 30 years ago.
Norman Wilson
Toronto ON
> Always bemused me that to get a named local I/O connection one ended up with "Unix domain (what does that even mean?) sockets" rather than named pipes, especially since sockets are about as natural a Unix concept as lawn mowers. I've been told, but haven't confirmed, that early sockets didn't even support read and write. They still don't support open and close, and never will.
My interest in Unix networking 1975-1985 originally came from wondering how we came up with this alien feeling socket API as the dominant model. The original ideas for this API are in the recently found CSRG tech reports #4 and #3 - which I hope to discuss on this list in Spring.
I think we have to distinguish the API and the underlying paradigms.
When it comes to the “Arpa” lineage of Unix networking, the original API model was fully within the open-read-write-close framework. See for instance RFC681 and this document: https://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-Vax-TCP/doc/net.5.P; the entire BBN network API model fits on a few pages of ‘man’ text.
In 1975 Arpa Unix, the network name space was integrated with the file name space, by creating a character special file for each network host. This was possible because at that time an Arpa network address was 8 bits, and this fitted in the minor number; when Arpa addresses were expanded to 24 bits soon after this approach was abandoned (but one could think of a mechanism akin to symbolic links that could have continued the practice). One could have an entry for the local host, e.g. “/n/local” or something like that.
In my mind, “socket” does not only refer to the sockets API, but also to the concept of a bi-directional, possibly remote, named pipe; ‘named' as in “discoverable by a possibly unrelated process”, i.e. the in file name space, the network name space if different, etc. [aside: I realise (now) that this is a confusing use of the word socket, but I don’t have a better phrase at hand.] In my opinion, it is this concept that has proven strong and durable, much more so than the socket API itself.
When viewed in this definition a ‘fifo’ is a limited form of socket: it is unidirectional, local only (although in the 1981 S/F-Unix it wasn’t) and a server process cannot easily distinguish or delegate individual client connections. The Rand Port was better in the sense that it prefixed each client’s data with a header block.
> Networks are not intrinsically more special than any other I/O peripheral, but they have become gilded unicorns mounted on rotating hovercrafts compared to the I/O devices Unix supported before them. -rob
"Networks are not intrinsically more special than any other I/O peripheral”: that indeed is the paradigm that underlies Spider-Datakit-streams-STREAMS-Plan9, networks are just an I/O peripheral. There is nothing wrong with that paradigm, excellent systems can be built on top of it.
The other paradigm is that the network is a (mostly hidden) substrate that carries bidirectional pipes between processes. It would seem to me that there is nothing wrong with that paradigm either and it can be implemented in a “natural Unix” way as well.
> On Sun, Mar 8, 2020 at 3:48 AM Derek Fawcus <dfawcus+lists-tuhs at employees.org> wrote:
>
>> > On Sat, Mar 07, 2020 at 01:17:09PM +0100, Paul Ruizendaal wrote:
>> > >
>> > > Interestingly, Luderer also refers to a 1978 paper by Steve Holmgren (one of the Arpa Unix authors), suggesting ’sockets’ (in today’s parlance) for interproces communication.
>> >
>> > Could that simply be bleed over of terminology from the ARPAnet / Internet
>> > usage, in that "socket" is used to refer to protocol end points?
I meant ’socket’ in the sense that I described above.
“Socket” must be one of the most overloaded words in networking. My understanding is that on the Arpanet the “socket number” was what we now would call a "port number”, although I think it was initially meant to identify a user on a host, rather than a service on a host. In the 1980 BBN TCP implementation “socket” is used to mean “ip address”. A year later, Bill Joy uses “socket” as an API call name.
>> >
>> > i.e. see these from 1970:
>> >
>> > https://tools.ietf.org/html/rfc54
>> > https://tools.ietf.org/html/rfc55
>> > https://tools.ietf.org/html/rfc60
>> >
>> > DF
Arnold Robbins writes:
>> There was no tac in V7 Unix. It was first posted to USENET, I don't
>> know by who, and picked up by Linux and *BSD.
That brought back memories, and to verify them, I checked the tac.c
source code in the latest GNU coreutils test release. It says
/* Written by Jay Lepreau (lepreau(a)cs.utah.edu)
GNU enhancements by David MacKenzie (djm(a)gnu.ai.mit.edu) */
So my memory was right that my old friend Jay was the author. Sadly,
we lost him in September 2008: see
https://www.legacy.com/obituaries/saltlaketribune/obituary.aspx?page=lifest…
Jay founded the influential Flux group in advanced networking research:
http://www.flux.utah.edu/profile/lepreau
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- 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/ -
-------------------------------------------------------------------------------
The Luderer paper on distributed Unix has the following paragraph:
"A new special UNIX interprocess communication mechanism is the fifo, which provides communication between unrelated processes by associating a new special file type with a file name. Since remote fifos are legal, they can be used for interprocessor communication between S-UNIX machines or between an S-UNIX machine and an F-UNIX machine.”
The paper is from late 1981. Maybe I’m especially mud-eyed today, but I cannot see FIFO’s implemented in V7..V8 or 4.1xBSD. When did FIFO’s become a standard Unix feature?
Paul
> These go all the way back to v7 unix, where ls has an option to reverse
the sort order (which could have been done by passing the output to tac).
A cool idea, but tac was not in v7. And tail didn't get the -r
option until v8.
As for rev, I don't know why it was first written, but one
use was to examine suffixes--a kind of thing that several
word lovers in the Unix lab were prone to do.
Apropos of using rev to make rhyming dictionaries, Walker's
Rhyming Dictionary was published decades before Noah
Webster's dictionary appeared and stayed in print
for about 200 years. Notionally the relation between
webster and walker is
rev <webster | sort | rev >walker
Doug
I’m making a little progress with early Datakit & Unix.
It would seem that there were various experimental protocols before URP was arrived upon.
The first protocol appears to have been designed by Chesson in 1979. One Fraser paper says: ""The first Datakit protocols used a packet structure that was aligned with cell boundaries. Chesson designed a file transfer protocol that transported data in variable length packets, each ending with a trailer.” I think this protocol is being described in his paper "Datakit Software Architecture” (vol. 2, pp. 20.2.1-20.2.5 Proceedings of the IEEE Int. Conf. on Communications, June 1979, Boston) - which unfortunately does not seem to be available in the IEEE online library. Maybe it will surface some day.
Next there was a protocol tied to a Datakit terminal interface board that used an 8-slot packet sequence/acknowledge mechanism that carried over into URP. Not much appears to have been published about this.
The most interesting experiment seems to have been a project by Luderer, Che and Marshall to build a Datakit-based distributed Unix in 1980/81. Marshall is credited by Fraser as one of the inventors of the URP protocol. The papers are “A virtual switch as the basis for distributed systems” and “A distributed unix system based on a virtual circuit switch” (available online from the ACM library).
The first has a good overview description of how early Datakit worked (including interface hardware) and describes the Network Kernel or “NK protocol”. It would seem that URP combines the flow & retransmission control from the terminal interface board with the concept of a single simple receiver algorithm from NK. Unfortunately the paper does not describe the design of the NK transmitter algorithm(s). It confirms that everything ran on V7, but it remains unclear how the Datakit channels were exposed to the user (I currently assume as a cluster of character devices, with the major number identifying the switch connection and the minor number identifying the channel - similar to what later would be used in V8).
The second has a description of a modified Unix system, where clients (“S-Unix”) talk to file servers (“F-Unix”), with the file servers mounted into the local file tree of the client. This appears to predate the work of Weinberger for the V8 network file system and its implementation appears different.
Questions:
- Are Luderer, Che and Marshall still around? (especially Bill Marshall might still recall some more details of the genesis of the URP protocol)
- Any recollections about S/F-Unix and how it did or did not influence V8-V10/Plan9?
Hi All.
I have a full set (hardcopy) of the USENIX "Computing Systems" journal.
It's just sitting on my shelf taking up space, and I'd like to give them to
someone who'll give them a good home.
So, first person to reply to me directly, who's willing to pay
shipping from Israel, gets them. (Payment via paypal, or preferably
a US dollar check sent to my US address.)
Thanks!
Arnold
I was just discussing this with someone today, and I realized this
information has fallen out of working memory, and I can't find it on
secondary storage anywhere... ;-)
Does anyone remember the release history and version numbering of Ultrix
for the VAX and MicroVAX (which I believe was referred to at various times
as Ultrix-32 and Ultrix-32M, until some point when the "-32" thing was
dropped, I think?) I was trying to remember what the various released
versions of Ultrix were. The person I was discussing with thinks he
remembers a version 1.4 and 1.6, before Ultrix 2.0. I honestly don't
remember any 1.x version beyond 1.2. Is there a timeline somewhere?
--Pat.
All, I've had a few queries about the proposed video chat sessions, so
I'll kick the first one off tomorrow:
UTC Brisbane London New York
Friday, 28 Feb 2020 at 21:00 Sat 7:00am Fri 9:00pm Fri 4:00 pm
I'll only be able to stay for an hour but the chat session should
continue when I've gone.
URL: https://meet.tuhs.org/COFF
Password: unix
Cheers, Warren
This explains something, I think!
Luca Cardelli and Mark Manasse later worked at the Digital Systems Research Center in Palo Alto, which was formed in 1984 after PARC fired Bob Taylor.
Mark helped write the window system we used, and at some point a cat appeared, which would sleep until you moved the mouse and then come over to pat at the mouse.
My impression was that Luca wrote it, be he was cagy about it.
This later evolved into xneko for X Windows.
-Larry
