Since early 2013 I've occasionally asked this list for help, and shared
the progress regarding the creation of a Unix Git repository containing
Unix releases from the 1970s until today [1].
On Saturday I presented this work [2, 3] at MSR '15: The 12th Working
Conference on Mining Software Repositories, and on Sunday I discussed
the work with the participants over a poster [4] (complete with commits
shown in a teletype (lcase) and a VT-220 font). Amazingly, the work
received the conference's "Best Data Showcase Award", for which I'm
obviously very happy.
I'd like to thank again the many individuals who contributed to the
effort. Brian W. Kernighan, Doug McIlroy, and Arnold D. Robbins helped
with Bell Labs login identifiers. Clem Cole, Era Eriksson, Mary Ann
Horton, Kirk McKusick, Jeremy C. Reed, Ingo Schwarze, and Anatole Shaw
helped with BSD login identifiers. The BSD SCCS import code is based on
work by H. Merijn Brand and Jonathan Gray.
A lot of work remains to be done. Given that the build process is
shared as open source code, it is easy to contribute additions and fixes
through GitHub pull requests on the build software repository [5], but
if you feel uncomfortable with that, just send me email. The most useful
community contribution would be to increase the coverage of imported
snapshot files that are attributed to a specific author. Currently,
about 90 thousand files (out of a total of 160 thousand) are getting
assigned an author through a default rule. Similarly, there are about
250 authors (primarily early FreeBSD ones) for which only the identifier
is known. Both are listed in the build repository's unmatched directory
[6], and contributions are welcomed (start with early editions; I can
propagate from there). Most importantly, more branches of open source
systems can be added, such as NetBSD OpenBSD, DragonFlyBSD, and illumos.
Ideally, current right holders of other important historical Unix
releases, such as System III, System V, NeXTSTEP, and SunOS, will
release their systems under a license that would allow their
incorporation into this repository. If you know people who can help in
this, please nudge them.
--Diomidis
[1] https://github.com/dspinellis/unix-history-repo
[2]
http://www.dmst.aueb.gr/dds/pubs/conf/2015-MSR-Unix-History/html/Spi15c.html
(HTML)
[3]
http://www.dmst.aueb.gr/dds/pubs/conf/2015-MSR-Unix-History/html/Spi15c.pdf
(PDF)
[4]
http://www.dmst.aueb.gr/dds/pubs/conf/2015-MSR-Unix-History/html/poster.pdf
(105MB)
[5] https://github.com/dspinellis/unix-history-make
[6]
https://github.com/dspinellis/unix-history-make/tree/master/src/unmatched
All, I finally remembered to export the unix-jun72 project over to Github:
https://github.com/DoctorWkt/unix-jun72
This was our effort to bring the 1st Edition Unix kernel back to life
along with the early C compilers and the 2nd Edition userland binaries.
Cheers, Warren
>
> On Thu, May 21, 2015 at 11:49 AM, Clem Cole <clemc(a)ccc.com <mailto:clemc@ccc.com>
> <mailto:clemc@ccc.com <mailto:clemc@ccc.com>>> wrote:
>
> ? HP/UX is an SVR3 & OSF/1 ancester. Solaris is SVR4. In fact
> it was the SVR4 license and deal between Sun and AT&T)? that
> forced the whole OSF creation. One of the "principles" of the
> OSF was "Fair and Stable" license terms.
>
> Which begs a question - since Solaris was SVR4 based and was
> made freely available via OpenSolaris et al, does that not
> make SVR4 open? I'm not a lawyer (nor play one on TV), but
> it does seem like that sets some sort of precedent.
This is indeed an interesting question. During the IBM vs SCO debacle,
IBM requested the use of TMGE to be used as an example for proof of
how the SVR4 kernel algorithms were already out in the public domain
and thus set the precedent. And this was also (eventually) approved by
AT&T for publication.
> From: Mary Ann Horton
> I have 5 AT&T SVR4 tapes among them .. Is it worth recovering them?
I would say that unless they are _known_ to be in a repository somewhere, yes
(unless it's going to cost a fortune - SVR4 isn't _that_ key a step in the
evolution, I don't think [but I stand to be corrected :-]).
Noel
Hi.
Can anyone still read 9 track tapes? We just uncovered two that date
from my wife's time in grad school, circa 1989 - 1990. They would
be tar tapes.
Thanks!
Arnold
A fantastic curatorial exploit!
> Deadly quote "and nobody cares about that early code history any more
> --so this is all water under the bridge."
This particular metaphor always reminds me of the Farberism: "That's
water over the bridge." Dave, a major presence at Bell Labs, master
malaprop, friend of many and collaborator with several of the early
Unix team, may be counted as an honorary Unixian.
Doug
> From: Aharon Robbins
> Can anyone still read 9 track tapes? We just un-covered two that date
> from my wife's time in grad school, circa 1989 - 1990. They would be
> tar tapes.
That old, the issue is not going to be the format (TAR is still grokkable),
but the physical condition of the tapes; that old, they might have issues
with shedding of oxide, etc (which a heat soak can mostly cure). If you
really want them read, I would recommend a specialist in reading old tapes;
it will cost, but if you really want the data... I have used Chuck Guzis, in
Washington (state) in the US.
Noel
Hoi.
What started as the plan to write a short portrait of cut(1)
for a free german online magazine (translation to English is
not done yet) became a closer look at the history of cut(1).
Well, the topic got me hooked at some point. The text is still
only about eight pages long and far from scientific quality,
but it features some facts not found in Wikipedia. ;-)
So, let me come to my questions.
1) The oldest version of cut that I found is this one in System III.
http://minnie.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd
(The file date says 1980-04-11.) As the sccsid reads version 1.5,
there must be older code. How can I find it? Is there a story of
how cut appeared for the first time?
2) As far as I found out, POSIX.2-1992 introduced the byte mode
(-b) and added multi-byte support for the character mode. Is
this correct?
3) Old BSD sources reference POSIX Draft 9 (which, it seems,
they implement) but lack multi-byte support and the byte mode.
They also support decreasing lists, which, they state, POSIX
Draft 9 would not.
http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/usr.bin/cut/cu…
The only POSIX.2 Draft I have access to is Draft 11.2.
http://www.nic.funet.fi/pub/doc/posix/p1003.2/d11.2/all.ps
It does specify the multi-byte stuff and does also allow
decreasing lists. Hence, it appears that these things were
added somewhen between Draft 9 and Draft 11.2. Does anyone
know details?
It would be great, if you can give me some pointers for
further research or even share some cut-stories from the
good old days. :-)
meillo
P.S.
In case you understand German, feel free to have a look at the
current version of the text: http://hg.marmaro.de/docs/cut/file/
I welcome your comments, but bear with me, the text issn't meant
to become a doctoral thesis; I just want to write it for fun and
to learn about the historical background.
Hello All.
I have a full set of the O'Reilly X reference manuals - Volumes 1-5, 6a
and 6b. Also "The X Window System In A Nutshell". These are all from
like the mid-1990s.
Are they worth hanging onto?
If not, does anyone on this list want them? If so, I'll send them for
the cost of postage from Israel.
Thanks,
Arnold
> From: Dave Horsfall <dave(a)horsfall.org>
>> In V6, the bootstrap in block 0 prompts for a file name, and when that
>> is entered, it loads that file into memory and starts it. (It doesn't
>> have to be in the root directory, IIRC - I'm pretty sure the bootstrap
>> will accept full path names.)
> I'm pretty sure that it didn't have the full namei() functionality, so
> all files had to be in the root directory.
It depends on what you mean by the first "it" above - if you meant 'V6', then
no. From the Distribution V6's /src/mdec/fsboot.s:
/ read in path name
/ breaking on '/' into 14 ch names
The process of breaking the name up into segments, and then later finding
each name in the appropriate directory, can be seen. The code is kind of
obscure, but if you look at the RL bootstap I dis-assembled:
http://ana-3.lcs.mit.edu/~jnc/tech/unix/rlboot.s
it's pretty much the same code, and a little better commented in the 'read
in directories' part.
Noel