[TUHS] Reorganising the Unix Archive?

[TUHS] Reorganising the Unix Archive?

[Warren Toomey]

Hi all, I think the current layout of the Unix Archive at
http://www.tuhs.org/Archive/ is starting to show its limitations as we get
more systems and artifacts that are not specifically PDP-11 and Vax.

I'm after some suggestions on how to reorganise the archive. Obviously
there are many ways to do this. Just off the top of my head, top level:

 - Applications: things which run at user level
 - Systems: things which have a kernel
 - Documentation
 - Tools: tools which can be used to deal with systems and files

Under Applications, several directories which hold specific things. If
useful, perhaps directories that collect similar things.

Under Systems, a set of directories for specific organisations (e.g. Research,
USL, BSD, Sun, DEC etc.). In each of these, directories for each system.

Under Documentation, several directories which hold specific things. If
useful, perhaps directories that collect similar things.

Under Tools, subdirectories for Disk, Tape, Emulators etc., then subdirs
for the specific tools.

Does this sound OK? Any refinements or alternate suggestions?

Cheers, Warren

[TUHS] Reorganising the Unix Archive?

[Warren Toomey]

On Sat, Feb 18, 2017 at 10:12:44AM +1000, Warren Toomey wrote:
>  - Applications: things which run at user level
>  - Systems: things which have a kernel
>  - Documentation
>  - Tools: tools which can be used to deal with systems and files

Clarification. Systems would be whole systems like 7th Edition, 4.3BSD etc.
Applications would be things that were not distributed in a system, e.g.
C-News. Documentation would be also material not part of a whole system, e.g.
the AUUG newsletters.

Cheers, Warren

[TUHS] Reorganising the Unix Archive?

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]

On Fri, Feb 17, 2017 at 7:12 PM, Warren Toomey <wkt at tuhs.org> wrote:

> Under Systems, a set of directories for specific organisations (e.g.
> Research,
> ​ ​
> USL, BSD, Sun, DEC etc.). In each of these, directories for each system.
>

​Sounds good, although I might offer one slight twist.  I think
organizations should be the higher bit not systems, doc etc....   So you
have DEC, AT&T, UCB, MIT, USENIX, UI, OSF, *etc..*..  Under AT&T you will
have research and summit.​  Under UCB, you have CSRG, CAD, Ingress etc..
where you know things came from different teams.   Same for  MIT or the
like.  BTW: the anal fixation / some of the arguments we have had, I also
feel that Year of Distribution probably needs to be in the name if possible
(certainly in metadata or at least an explanatory README).  For things like
the USENIX tapes that's easier - because they were done by year.

Anyway - its only under these directories that then have the split of doc,
systems, *etc.*.

If there is cross linking, you certainly can do a little if that makes
sense.   But I think that It will be easier keep each collection from where
and when it came to help cement the origin & time and make it easier for
people to find things.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170217/732be838/attachment.html>

[TUHS] Reorganising the Unix Archive?

[Warren Toomey]

On Fri, Feb 17, 2017 at 07:40:16PM -0500, Clem Cole wrote:
>    Sounds good, although I might offer one slight twist.  I think
>    organizations should be the higher bit not systems, doc etc....

I'll disagree, mainly because of what we have currently in terms of
applications and documentation.

At present, in these categories we have:
 - Circuit_Design	   Festoon   Portable_CC  Shoppa_Tapes	  Usenix_77
   Early_C_Compilers  Macro-11  README	  Software_Tools	  Algol68
   Em_Editor	   OpenLook  Ritter_Vi	  Spencer_Tapes
 - AUUGN  Books  Emails  OralHistory  PUPS  Papers  TUHS  Unix_Review
 - various system setup docs

Except for the last category, all the existing applications and documentation
are not easily classifiable into <organisation>. So I think it would be
better to have a generic top-level Applications and Documentation directories.
We can move the system setup docs into specific system areas.

I don't mind having <organisation> top-level directories, but I fear that
in the long term there will be lots of them. So it's a question: do we clutter
up the top level with a heap of <organisation> directories, or do we
have a heap of Systems/<organisation> directories. I'd prefer the latter.

>    I also feel that Year of Distribution probably needs to be in the
>    name if possible (certainly in metadata or at least an explanatory
>    README).  For things like the USENIX tapes that's easier - because they
>    were done by year.

My preference is to keep date details in metadata and not in directory names.
There will be some things which are hard to date or whose date is in dispute,
and there may be things which are aggregates of work done over several years.

But I'll admit that there is not enough metadata and little consistency in
the metadata (e.g. Readme files) that are currently in the Archive.

Cheers & thanks for the feedback, Warren

[TUHS] Reorganising the Unix Archive?

[Random832]

On Fri, Feb 17, 2017, at 19:12, Warren Toomey wrote:
> Under Tools, subdirectories for Disk, Tape, Emulators etc., then subdirs
> for the specific tools.

One thing that might be nice is a directory specifically for archive
extraction tools for modern systems. I've probably reinvented ar11 half
a dozen times.

[TUHS] Reorganising the Unix Archive?

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2211 bytes --]

William Corcoran <wlc at jctaylor.com> wrote:

> But, is there somewhere a main distribution for Research 7, v7m 2.1, or BSD 2.11 that has all of the original SCCS deltas (leaf and non-leaf)? 
>
> This would be extremely revealing. If we could view the SCCS comments (sccs prs) and the underlying code, it would be incredibly valuable. 
>
> Please forgive me if this has been asked a million times.  I just can't find it.  Once SCCS was heavily used, was there a codebase that housed all of these distributions?  

If you have access to the CSRG UNIX archives, you could fetch the latest SCCS 
sources from within the schily-tools:

	http://sourceforge.net/projects/schilytools/files/

compile it by just calling "make" and then:

cd CSRG_Archive_4
sccs -R log > /tmp/file

This gives you better readable results and it has the advantage that you get
a listing that span the whole tree and combine daltas that happened within 
24 hours and used the same delta message.

Here is a small part as an example:

Thu May  8 10:29:39 1980 bill 
        * ./sys/kern/init_main.c 3.4 
        * ./sys/vax/uba/vp.c 3.2 
        * ./sys/vax/uba/va.c 3.2 
        * ./sys/kern/kern_proc.c 3.3 
        * ./sys/kern/kern_synch.c 3.7 
        * ./sys/kern/tty_subr.c 3.2 
        * ./sys/vax/vax/machdep.c 3.4 
        * ./sys/vax/mba/ht.c 3.2 
        * ./sys/vax/mba/hp.c 3.3 
        * ./sys/vax/vax/flp.c 3.2 
        * ./sys/kern/kern_clock.c 3.5 
        * ./sys/kern/kern_physio.c 3.4 
        * ./sys/kern/vfs_cluster.c 3.4 
        * ./sys/kern/vfs_bio.c 3.4 
          VOID=>void 
 
Thu May  8 10:15:38 1980 bill 
        * ./sys/sys/conf.h 3.2 
          addition for netldis 
 
Thu May  8 10:14:51 1980 bill 
        * ./sys/sys/tty.h 3.2 
          added BNETLDIS 
 
Thu May  8 10:13:56 1980 bill 
        * ./sys/kern/tty.c 3.2 
          modified to support TIOCSETD reasonably 

The code at: CSRG_Archive_4 contains 108604 deltas in total.

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] Reorganising the Unix Archive?

[Larry McVoy]

On Sun, Feb 19, 2017 at 09:33:24PM -0500, Doug McIlroy wrote:
> > Once SCCS was heavily used, was there a codebase that housed all of these distributions?
> 
> No. The Research Unix team was small, had no responsibility to
> support old versions, and eschewed paperwork. But we were
> conscientiouws about maintaining the manual and fixing bugs.
> Close personal contact kept things on track; SCCS was never
> used. Because of frequent exchanges of software, there
> may be hints of Research activity in PWB SCCS records.

That's the first practice I've heard about the Research Unix team that
is disappointing.  It would be oh so valuable to see the history in
SCCS.  

[TUHS] Reorganising the Unix Archive?

[Doug McIlroy]

> Once SCCS was heavily used, was there a codebase that housed all of these distributions?

No. The Research Unix team was small, had no responsibility to
support old versions, and eschewed paperwork. But we were
conscientiouws about maintaining the manual and fixing bugs.
Close personal contact kept things on track; SCCS was never
used. Because of frequent exchanges of software, there
may be hints of Research activity in PWB SCCS records.

Doug

[TUHS] Reorganising the Unix Archive?

[William Corcoran]

Hello Mr. Mcllroy, 

Well, along the lines of early UNIX preservation, I have a question.

At some point SCCS began to take shape and take hold of the core of the early UNIX distributions.  Google says SCCS has been around since 1972. 

Now, let's take my favorite UNIX releases Research 7, v7m and BSD 2.11.  They are my favorite since I have access to the complete distributions and I have all working independently via simulators on dedicated hardware.  

Now, it's simply wonderful to view the sources.  Even more wonderful, through simulation, to relink these distributions.  And it's fun to read code and comments---most of it way over my head.   

But, is there somewhere a main distribution for Research 7, v7m 2.1, or BSD 2.11 that has all of the original SCCS deltas (leaf and non-leaf)? 

This would be extremely revealing. If we could view the SCCS comments (sccs prs) and the underlying code, it would be incredibly valuable. 

Please forgive me if this has been asked a million times.  I just can't find it.  Once SCCS was heavily used, was there a codebase that housed all of these distributions?  

I always wondered if there were some kind of SCCS or SCCS-like repository that maintained the final distribution and all of the deltas leading up to a minor or even major release.

RELEASE, LEVEL, BRANCH and SEQUENCE:

I do see "SCCSID" strings sprinkled throughout various distributions.  So, this way the application could automatically report the RLBS to the end user. 

But, is there an early UNIX distribution that housed  the complete SCCS repository---I want to dig deep, really deep.  This way I could see the paths that were taken, the solutions that partially worked, or ended up causing other problems.

Truly,

Bill Corcoran



> On Feb 18, 2017, at 7:12 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
> 
> 
> OMG. I don't know how many times I've consulted the Unix
> Tree and blissfully ignored the cross-links that come at
> the top of every file--I'm so intent on the content.
> 
> Apologies for cluttering the mailing list about a solved topic.
> 
> Doug

[TUHS] Reorganising the Unix Archive?

[Doug McIlroy]

OMG. I don't know how many times I've consulted the Unix
Tree and blissfully ignored the cross-links that come at
the top of every file--I'm so intent on the content.

Apologies for cluttering the mailing list about a solved topic.

Doug

[TUHS] Reorganising the Unix Archive?

[Doug McIlroy]

> That's what the Unix Tree is for!

Yes, but it doesn't have cross links as far as I know.
What I have in mind is effectively one more entry in
the root. Call it "union" perhaps. In a leaf of that
tree, say /union/usr/src/cmd/find, will ne a page that
links to all the "find sources in the other systems.

I don't know the range of topologies in the Unix Tree.
For example, some systems may have /src while others
have /usr/src. That could be hidden completely by
simply not revealing the path names. Alternatively
every level in the union tree could record its cousins
in the various systems, as well as its children
in the union system.

Doug

[TUHS] Reorganising the Unix Archive?

[Random832]

On Fri, Feb 17, 2017, at 23:40, Warren Toomey wrote:
> That's what the Unix Tree is for!
> http://minnie.tuhs.org/UnixTree

One thing I noticed (I was going through versions of the "bcd" program
and various other early-BSD utilities) is that the "similar files"
dropdown doesn't seem to show up in some cases.

[TUHS] Reorganising the Unix Archive?

[Warren Toomey]

That's what the Unix Tree is for!
http://minnie.tuhs.org/UnixTree
Also, Diomidis' Github repository
https://github.com/dspinellis/unix-history-repo

Cheers, Warren

On 18 February 2017 1:30:12 pm AEST, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
>If things are filed by provenance, one useful kind of
>cross-linking would be a generic tree whose "leaves"
>link to all the versions of the "same" file. All the
>better if it could also indicate the degree of
>relatedness of the versions--perhaps an inferred
>evolutionary tree or a shaded grid, where the
>intensity of grid point x,y shows the relatedness
>of x and y.
>
>doug

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170218/bf93b320/attachment.html>

[TUHS] Reorganising the Unix Archive?

[Doug McIlroy]

If things are filed by provenance, one useful kind of
cross-linking would be a generic tree whose "leaves"
link to all the versions of the "same" file. All the
better if it could also indicate the degree of
relatedness of the versions--perhaps an inferred
evolutionary tree or a shaded grid, where the
intensity of grid point x,y shows the relatedness
of x and y.

doug