> "taperead" in http://github.com/brouhaha/tapeutils can extract files
> from a tape image.
The format is very simple: a 32-bit little-endian record length,
followed by that many bytes, followed by the length again for
integrity checking. A record length of zero is a file mark.
-- Richard
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
I noticed that the TUHS archive does not include a 4.1BSD distribution.
Also, while poking around the net, I've found a number of purported
tape images of 4.1BSD dated 7/10/1981 that look to me to a little sketchy,
since most contain files dated well into 1982.
So it appears to me that 4.1BSD is semi-lost.
While googling all this, I discovered that the School of Computer Science
and Statistics at Trinity College Dublin has an online archive catalog
which lists a couple of 4.1BSD distribution tapes in the "John Gabriel Byrne
Computer Science Collection".
https://scss.tcd.ie/SCSSTreasuresCatalog/
Perhaps someone from TUHS who lives near Dublin could investigate and
see if images can be made of these tapes?
Years ago just before one of the USENIX meetings in Atlanta Dennis made some
joke comment that nobody had ever asked for a plaster cast of his genitals.
A bunch of us thought it would be fun at the conference to hand out genital
casting kits to Dennis and certain others of note. We ran down to a
local art supply store and bought some plaster and portioned out into zone
ziplock bags We added some paper cups to use for molds and wooded sticks
to mix with. We needed a release agent. Vaseline would work, but I
couldn't figure out how we'd get small portions (I couldn't use the ziplock
bag idea practically). Fortunately, there was a little gift shop in the
hotel lobby and they had these travel size jars. Perfect.
Now the interesting thing was that concurrent with USENIX was the Southern
Baptist Conference meetings (this led to some odd events at local
restaurants).
Anyhow, I walk up to the cashier and plop down ten jars of Vaseline.
She looks at me and says, "I guess y'all aren't with the Baptists."
Oddly, most recipients took the gift in good spirit but Redman had a fit for
some reason. Babette suggested perhaps we made the kit too large for him.
According to my (possibly inaccurate) notes:
NetBSD checked in 1993
Message-ID: <alpine.NEB.2.20.1803211456560.25928(a)t1.m.reedmedia.net>
Revision 1.1, Sun Mar 21 09:45:37 1993 UTC (25 years ago) by cgd
http://cvsweb.netbsd.org/bsdweb.cgi/src/sbin/init/init.c?rev=1.1&content-ty…
"Today is commonly considered the birthday of NetBSD. As far as I know,
it is the oldest continuously-maintained complete open source operating
system. (It predates Slackware Linux, FreeBSD, and Debian Linux by some
months.)"
-- Dave
Hello,
I'm looking for old DNS software - servers, clients, libraries. The
oldest one I've found is BIND 4.3 from 4.3BSD (and it works as a
resolver on 2019 Internet), but there were earlier ones -
http://www.donelan.com/dnstimeline.html says that UCB released first
BIND in 1985, something was running on earlier servers. Any help would
be appreciated.
Witold Krecicki
We lost computer pioneer John Backus on this day in 2007; amongst other things
he gave us FORTRAN (yuck!) and BNF, which is ironic, really, because FORTRAN
has no syntax to speak of.
-- Dave
Hello,
I'm looking for old DNS software - servers, clients, libraries. The
oldest one I've found is BIND 4.3 from 4.3BSD (and it works as a
resolver on 2019 Internet), but there were earlier ones -
http://www.donelan.com/dnstimeline.html says that UCB released first
BIND in 1985, something was running on earlier servers. Any help would
be appreciated.
Witold Krecicki
>> But sed, awk, perl, python, ... lex and parse once into an AST or
>> bytecode, removing the recurring cost of comments, etc. that impact
>> groff. So I don't think it's an even comparison.
>
> Of course it's a valid comparison. Which sed or awk or shell script is
> distributed in a stripped/compressed form? Do they store their AST
> somewhere, so as to avoid recompilation? They do not. Just as
> with groff, every parse starts anew.
Comments inside of a macro definition get scanned each time it's called.
This justifies the first paragraph above.
In the wild, almost all comments occur outside macro definitions.
This justifies the second.
Thus comments are harmless in practice.
Doug