TUHS

tuhs@tuhs.org

41 participants
6501 discussions

Re: [TUHS] Proliferation of options is great simplification of pipes, really?

by Steve Simon

its written in rc(1) and uses plan9 regex which sometimes differ from unix ones a little but there is doctype: http://9p.io/magic/man2html/1/doctype http://9p.io/sources/plan9/rc/bin/doctype -Steve

4 years, 2 months

Proliferation of options is great simplification of pipes, really?

by M Douglas McIlroy

> I can imagine a simple perl (or python or whatever) script that would run > through groff input [and] determine which preprocessors are actually > needed ... Brian imagined such and implemented it way back when. Though I used it, I've forgotten its name. One probably could have fooled it by tricks like calling pic only in a .so file and perhaps renaming .so. But I never heard of it failing in real life. It does impose an extra pass over the input, but may well save a pass compared to the defensive groff -pet that I often use or to the rerun necessary when I forget to mention some or all of the filters.

4 years, 2 months

Proliferation of options is great simplification of pipes, really?

by Will Senn

All, So, we've been talking low-level design for a while. I thought I would ask a fundamental question. In days of old, we built small single-purpose utilities and used pipes to pipeline the data and transformations. Even back in the day, it seemed that there was tension to add yet another option to every utility. Today, as I was marveling at groff's abilities with regard to printing my man pages directly to my printer in 2021, I read the groff(1) page: example here: https://linux.die.net/man/1/groff What struck me (the wrong way) was the second paragraph of the description: The groff program allows to control the whole groff system by command line options. This is a great simplification in comparison to the classical case (which uses pipes only). Here is the current plethora of options: groff [-abcegilpstzCEGNRSUVXZ] [-d cs] [-f fam] [-F dir] [-I dir] [-L arg] [-m name] [-M dir] [-n num] [-o list] [-P arg] [-r cn] [-T dev] [-w name] [-W name] [file ...] Now, I appreciate groff, don't get me wrong, but my sensibilities were offended by the idea that a kazillion options was in any way simpler than pipelining single-purpose utilities. What say you? Is this the perfected logical extension of the unix pioneers' work, or have we gone horribly off the trail. Regards, Will

4 years, 2 months

Re: [TUHS] cut, paste, join, etc.

by M Douglas McIlroy

Will Senn wrote, > join seems like part of an aborted (aka never fully realized) attempt at a text based rdb to me As the original author of join, I can attest that there was no thought of parlaying join into a database system. It was inspired by databases, but liberated from them, much as grep was liberated from an editor. Doug

4 years, 2 months

UNSW batch availability (was Re: Abstractions)

by Ron Young

Hi: I've been following the discussion on abstractions and the recent messages have been talking about a ei200 batch driver (ei.c: https://minnie.tuhs.org/cgi-bin/utree.pl?file=AUSAM/sys/dmr/ei.c) I have access to DtCyber (CDC Cyber emulator) that runs all/most of the cdc operating system. I'm toying with the idea of getting ei200 running. In looking at things, I ran across the following in https://minnie.tuhs.org/cgi-bin/utree.pl?file=AUSAM/READ_ME > The UNSW batch system has not been provided with this > distribution, because of its limited appeal. > If you are unfortunate enough to have a CYBER to talk to, > please contact us and we will forward it to you. Does anyone happen to know if the batch system is still around? thanks -ron

4 years, 2 months

Abstractions

by Paul Ruizendaal

To quote from Jon’s post: > There have been heated discussions on this list about kernel API bloat. In my > opinion, these discussions have mainly been people grumbling about what they > don't like. I'd like to flip the discussion around to what we would like. > Ken and Dennis did a great job with initial abstractions. Some on this list > have claimed that these abstractions weren't sufficient for modern times. > Now that we have new information from modern use cases, how would we rethink > the basic abstractions? I’d like to add the constraint of things that would have been implementable on the hardware of the late 1970’s, let’s say a PDP11/70 with Datakit or 3Mbps Ethernet or Arpanet; maybe also Apple 2 class bitmap graphics. And quote some other posts: > Because it's easy pickings, I would claim that the socket system call is out > of line with the UNIX abstractions; it exists because of practical political > considerations, not because it's needed. I think that it would have fit > better folded into the open system call. >> >> Somebody once suggested a filesystem interface (it certainly fits the Unix >> philosophy); I don't recall the exact details. > > And it was done, over 30 years ago; see Plan 9 from Bell Labs.... I would argue that quite a bit of that was implementable as early as 6th Edition. I was researching that very topic last Spring [1] and back ported Peter Weinberger’s File System Switch (FSS) from 8th to 6th Edition; the switch itself bloats the kernel by about half a kilobyte. I think it may be one of the few imaginable extensions that do not dilute the incredible bang/buck ratio of the V6 kernel. With that change in place a lot of other things become possible: - a Kilian style procfs - a Weinberger style network FS - a text/file based ioctl - a clean approach to named pipes - a different starting point to sockets Each of these would add to kernel size of course, hence I’m thinking about a split I/D kernel. To some extent it is surprising that the FSS did not happen around 1975, as many ideas around it were 'in the air' at the time (Heinz Lycklama’s peripheral Unix, the Spider network Filestore, Rand ports, Arpanet Unix, etc). With the benefit of hindsight, it isn’t a great code leap from the cdev switch to the FSS - but probably the ex ante conceptual leap was just too big at the time. Paul [1] Code diffs here: https://1587660.websites.xs4all.nl/cgi-bin/9995/vdiff?from=fab15b88a6a0f36b…

4 years, 2 months

Re: [TUHS] cut, paste, join, etc.

by Brian Walden

The last group before I left the labs in 1992 was on was the POST team. pq stood for "post query," but POST consisted of - - mailx: (from SVR3.1) as the mail user agent - UPAS: (from research UNIX) as the mail delivery agent - pq: the program to query the database - EV: (pronounced like the biblical name) the database (and the genesis program to create indices) - post: program to combine all the above to read email and to send mail via queries pq by default would looku up people pq lastname: find all people with lastname, same as pq last=lastname pq first.last: find all people with first last, same as pq first=first/last=last pq first.m.last: find all people with first m last, same as pq first=first/middle=m/last=last this how email to dennis.m.ritchie @ att.com worked to send it on to research!dmr you could send mail to a whole department via /org=45267 or the whole division via /org=45 or a whole location via /loc=mh or just the two people in a specific office via /loc=mh/room=2f-164 these are "AND"s an "OR" is just another query after it on the same line There were some special extentions - - prefix, e.g. pq mackin* got all mackin, mackintosh, mackinson, etc - soundex, e.g. pq mackin~ got all with the last name that sounding like mackin, so names such as mackin, mckinney, mckinnie, mickin, mikami, etc (mackintosh and mackinson did not match the soundex, therefore not included) The EV database was general and fairly simple. It was directory with files called "Data" and "Proto" in it. "Data" was plain text, pipe delineated fields, newline separated records - 123456|ritchie|dennis|m||r320|research!dmr|11273|mh|2c-517|908|582|3770 (used data from preserved at https://www.bell-labs.com/usr/dmr/www/) "Proto" defined the fields in a record (I didn't remember exact syntax anymore) - id n i last a i first a i middle a - suffix a - soundex a i email a i org n i loc a i room a i area n i exch n i ext n i "n" means a number so 00001 was the same as 1, and "a" means alpha, the "i" or "-" told genesis if an index should be generated or not. I think is had more but that has faded with the years. If indices are generated it would then point to the block number in Data, so an lseek(2) could get to the record quick. I beleive there was two levels of block pointing indices. (sort of like inode block pointers had direct and indirect blocks) So everytime you added records to Data you had to regenerate all the indices, that was very time consuming. The nice thing about text Data was grep(1) worked just fine, or cut -d'|' or awk -F'|' but pq was much faster with a large numer of records. -Brian Dan Cross <crossd at gmail.com> wrote: > It seems that Andrew has addressed Daytona, but there was a small database > package called `pq` that shipped with plan9 at one point that I believe > started life on Unix. It was based on "flat" text files as the underlying > data source, and one would describe relations internally using some > mechanism (almost certainly another special file). An interesting feature > was that it was "implicitly relational": you specified the data you wanted > and it constructed and executed a query internally: no need to "JOIN" > tables on attributes and so forth. I believe it supported indices that were > created via a special command. I think it was used as the data source for > the AT&T internal "POST" system. A big downside was that you could not add > records to the database in real time. > > It was taken to Cibernet Inc (they did billing reconciliation for wireless > carriers. That is, you have an AT&T phone but make a call that's picked up > by T-Mobile's tower: T-Mobile lets you make the call but AT&T has to pay > them for the service. I contracted for them for a short time when I got out > of the Marine Corps---the first time) and enhanced and renamed "Eteron" and > the record append issue was, I believe, solved. Sadly, I think that > technology was lost when Cibernet was acquired. It was kind of cool. > > - Dan C. >

4 years, 3 months

AT&T 3B1 - Emulation available

by Arnold Robbins

Hello All. Many of you may remember the AT&T UNIX PC and 3B1. These systems were built by Convergent Technologies and sold by AT&T. They had an MC 68010 processor, up to 4 Meg Ram and up to 67 Meg disk. The OS was System V Release 2 vintage. There was a built-in 1200 baud modem, and a primitive windowing system with mouse. I had a 3B1 as my first personal system and spent many happy hours writing code and documentation on it. There is an emulator for it that recently became pretty stable. The original software floppy images are available as well. You can bring up a fairly functional system without much difficulty. The emulator is at https://github.com/philpem/freebee. You can install up to two 175 Meg hard drives - a lot of space for the time. The emulator's README.md there has links to lots of other interesting 3B1 bits, both installable software and Linux tools for exporting the file system from disk image so it can be mounted under Linux and importing it back. Included is an updated 'sysv' Linux kernel module that can handle the byte-swapped file system. I have made a pre-installed disk image available with a fair amount of software, see https://www.skeeve.com/3b1/. The emulator runs great under Linux; not so sure about MacOS or Windows. :-) So, anyone wishing to journey back to 1987, have fun! Arnold

4 years, 3 months

Fwd: [multicians] History of C (with Multics reference)

by Dan Cross

FYI, interesting. ---------- Forwarded message --------- From: Tom Van Vleck <thvv(a)multicians.org> Date: Sun, Feb 14, 2021, 12:35 PM Subject: Re: [multicians] History of C (with Multics reference) To: <multicians(a)groups.io> Remember the story that Ken Thompson had written a language called "Bon" which was one of the forerunners of "B" which then led to "new B" and then to "C"? I just found Ken Thompson's "Bon Users Manual" dated Feb 1, 1969, as told to M. D. McIlroy and R. Morris in Jerry Saltzer's files online at MIT. http://people.csail.mit.edu/saltzer/Multics/MHP-Saltzer-060508/filedrawers/… _._,_._,_ ------------------------------ Groups.io Links: You receive all messages sent to this group. View/Reply Online (#4231) <https://groups.io/g/multicians/message/4231> | Reply To Group <multicians@groups.io?subject=Re:%20Re%3A%20%5Bmulticians%5D%20History%20of%20C%20%28with%20Multics%20reference%29> | Reply To Sender <thvv@multicians.org?subject=Private:%20Re:%20Re%3A%20%5Bmulticians%5D%20History%20of%20C%20%28with%20Multics%20reference%29> | Mute This Topic <https://groups.io/mt/78835051/481017> | New Topic <https://groups.io/g/multicians/post> ------------------------------ -- sent via multicians(a)groups.io -- more Multics info at https::// multicians.org/ ------------------------------ Your Subscription <https://groups.io/g/multicians/editsub/481017> | Contact Group Owner <multicians+owner(a)groups.io> | Unsubscribe <https://groups.io/g/multicians/leave/5961246/1924879241/xyzzy> [ crossd(a)gmail.com] _._,_._,_

4 years, 3 months

Abstractions

by Jon Steinhart

Was thinking about our recent discussion about system call bloat and such. Seemed to me that there was some argument that it was needed in order to support modern needs. As I tried to say, I think that a good part of the bloat stemmed from we-need-to-add-this-to-support-that thinking instead of what's-the-best-way-to-extend-the-system-to-support-this-need thinking. So if y'all are up for it, I'd like to have a discussion on what abstractions would be appropriate in order to meet modern needs. Any takers? Jon

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