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
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
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…
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.
>
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
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]
_._,_._,_
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
I was lucky enough to actually have a chance to use wm at Carnegie Mellon before it was fully retired in favor of X11 on the systems in public clusters; it made a monochrome DECstation 3100 with 8MB much more livable.
When it was retired, it was still usable for a while because the CMU Computer Club maintained an enhanced version (wmc) that everyone had access to, and Club members got access to its sources.
Did anyone happen to preserve the wm or wmc codebase? There's some documentation in the papers that were published about the wm and Andrew API but no code.
-- Chris
I've been writing about unix design principles recently and tried
explaining "The Rule of Silence" by imagining unix as a restaurant
<http://codefaster.substack.com/p/rule-of-silence>. Do you agree with how I
presented it? Would you do it differently?
Tyler
All,
I'm tooling along during our newfangled rolling blackouts and frigid
temperatures (in Texas!) and reading some good old unix books. I keep
coming across the commands cut and paste and join and suchlike. I use
cut all the time for stuff like:
ls -l | tr -s ' '| cut -f1,4,9 -d \
...
-rw-r--r-- staff main.rs
and
who | grep wsenn | cut -c 1-8,10-17
wsenn  console
wsenn  ttys000
but that's just cuz it's convenient and useful.
To my knowledge, I've never used paste or join outside of initially
coming across them. But, they seem to 'fit' with cut. My question for
y'all is, was there a subset of related utilities that these were part
of that served some common purpose? On a related note, join seems like
part of an aborted (aka never fully realized) attempt at a text based
rdb to me...
What say you?
Will
