I've assembled some notes from old manuals and other sources
on the formats used for on-disk file systems through the
Seventh Edition:
http://www.cita.utoronto.ca/~norman/old-unix/old-fs.html
Additional notes, comments on style, and whatnot are welcome.
(It may be sensible to send anything in the last two categories
directly to me, rather than to the whole list.)
> On Dec 31, 2016, at 8:58 AM, tuhs-request(a)minnie.tuhs.org wrote:
>
> From: Michael Kjörling <michael(a)kjorling.se>
> To: tuhs(a)tuhs.org
> Subject: Re: [TUHS] Historic Linux versions not on kernel.org
> Message-ID: <20161231111339.GK576(a)yeono.kjorling.se>
> Content-Type: text/plain; charset=utf-8
>
> I might be colored by the fact that I'm running Linux myself, but I'd
> say that those are almost certainly worth preserving somehow,
> somewhere. Linux and OS X are the Unix-like systems people are most
> likely to come in contact with these days
MacOS X is a certified Unix (tm) OS. Not Unix-Like.
http://www.opengroup.org/openbrand/register/apple.htm
It has been so since 10.0. Since 10.5 (Leopard) it has been so noted on the above Open Group page. The Open Group only lists the most recent release however.
The Tech Brief for 10.7 (http://images.apple.com/media/us/osx/2012/docs/OSX_for_UNIX_Users_TB_July20…) also notes the compliance.
David
Inspired by:
> Stephen Bourne after some time wrote a cron job that checked whether an
> update in a binary also resulted in an updated man page and otherwise
> removed the binary. This is why these programs have man pages.
I want to tell a story about working at Sun. I feel like I've sent this
but I can't find it in my outbox. If it's a repeat chalk it up to old
age.
I wanted to work there, they were the Bell Labs of the day, or as close
as you could get.
I got hired as a contractor through Lachman (anyone remember them?) to do
POSIX conformance in SunOS (the 4.x stuff, not that Solaris crap that I
hate).
As such, I was frequently the last guy to touch any file in the kernel,
my fingerprints were everywhere. So when there was a panic, it was
frequently laid at my doorstep.
So here is how I got a pager and learned about source management.
Sun had two guys, who will remain nameless, but they were known as
"the SCSI twins". These guys decided, based on feedback that "people
can interrupt sun install", to go into the SCSI tape driver and disable
SIGINT, in the driver. The kernel model doesn't allow for drivers messing
with your signal mask so on exit, sometimes, we would get a "panic: psig".
Somehow, I sure was because of the POSIX stuff, I ended up debugging this
panic. It had nothing to with me, I'm not a driver person (I've written
a few but I pretty much suck at them), but it landed in my lap.
Once I figured it out (which was not easy, you had to hit ^C to trigger it
so unless you did that, and who does that during an install) I tracked down
the code to SCSI twins.
No problem, everyone makes mistakes. Oh, wait. Over the next few months
I'm tracking down more problems, that were blamed on me since I'm all over
the kernel, but came from the twins.
Suns integration machines were argon, radon, and krypton. I wrote
scripts, awk I think, that watched every update to the tree on all
of those machines and if anything came from the SCSI twins the script
paged me.
That way I could go build and test that kernel and get ahead of the bugs.
If I could fix up their bugs before the rest of the team saw it then I
wouldn't get blamed for them.
I wish I could have figured out something like Steve did that would have
made them not screw up so much but this was the next best thing. I actually
got bad reviews because of their crap. My boss at the time, Eli Lamb, just
said "you are in kadb too much".
--lm
> From: Paul Ruizendaal
> Great! I'd love to take a look at all that.
OK, it'll all be appearing once we have a chance to get organized (it's all
mixed in with personal files).
> That is very interesting. It may be related to the V6 with NCP from
> UoI/DTI.
I think it _is_ the V6 from UoI/DTI. The source has Gary (?) Grossman's and
Steve Holmgren's name on it, and the headers say they date from 1074-75.
> The printout does not have the kernel modifications with it, so it would
> be great if your archive does include that.
The archive does include the complete kernel, but i) the changes aren't listed
in any way (I forsee a lot of 'diffs', unless you just take the entire
kernel), ii) there's a file called 'history' which contains a long list of
general changes/improvements of the kernel not really related to TCP/IP, by a
long list of people, dated from the middle of '78 to the middle of '79. So it
looks like he started with a considerably modified system.
The only client code I see is User Telnet. (The MIT code has User and
Server Telnet and FTP, as well as SMTP, but it uses a wholly different
TCP interface.)
Noel
Not so long ago I joked about putting a Cray-1 in a watch. Now that we are
essentially living in the future, what audacious (but realistic)
architectures can we imagine under our desks in 25 years? Perhaps a mesh
of ten-million of today's highest end CPU/GPU pairs bathing in a vast sea
of non-volatile memory? What new abstractions are needed in the OS to
handle that? Obviously many of the current command line tools would need
rethinking (ps -ef for instance.)
Or does the idea of a single OS disintegrate into a fractal cloud of
zero-cost VM's? What would a meta-OS need to manage that? Would we still
recognize it as a Unix?
> From: Nigel Williams
> Is it a reasonable claim that the PDP-10 made time-sharing "common"
> ... I'm presuming that "common" should be read as ubiquitous and
> accessible
> I'm wondering if it was really the combination of the PDP-11
Good question; I think a case can be made both ways.
> (lower-cost more models)
One observation I will make: the two don't have identical time-lines; the
earliest PDP-10 models predate the PDP-11 by a good chunk, and the PDP-11
out-lasted the PDP-10. So that has a big influence, I think, on the question
above.
The first PDP-10 (the KA - we'll leave aside the even earlier PDP-6) was made
out of small cards with individual transistors (B-series Flip Chips), whereas
the earliest PDP-11 model (the -11/20) used SSI TTL on much larger cards.
Ditto on the other end: the last PDP-10 sold used 29xx bit-slice technology,
whereas the PDP-11 lasted through three generations of microprocessor (the
LSI-11, Fonz, and Jaws).
Noel
Nigel Williams <nw(a)retrocomputingtasmania.com> asks on the TUHS list today:
>> ...
>> Is it a reasonable claim that the PDP-10 made time-sharing "common"
>> (note it says "the machine")? I'm presuming that "common" should be
>> read as ubiquitous and accessible (as in lower-cost than
>> competing/alternative options from other manufacturers or even DEC).
>>
>> I'm wondering if it was really the combination of the PDP-11
>> (lower-cost more models) and Unix ("free" license to universities)
>> that propelled time-sharing, at least at universities.
>> ...
I worked on the IBM ATS (Administrative Terminal System) for text
processing in the early 1970s, and for several years, on the CDC 6400
under both SCOPE and KRONOS operating systems. Those were mainframe
environments, but users scattered around campus accessed them via
glass terminals, so that was certainly time sharing.
Later, for 12 years (1978--1990), I also worked on TOPS-20 on the
PDP-10, and that too was time sharing, with most users having a
terminal on their desks. We also had PDP-11 and LSI-11 systems, but
they ran DEC proprietary operating systems, and were generally
dedicated to particular research hardware.
It was only in the early 1980s that my institution also began to run
Unix systems, initially Wollongong BSD on VAX 750s, and then in 1987,
with our first Sun workstations running SunOS. Thus, for me at least,
Unix time sharing came a dozen years late (though it was still
welcome, and remains so today).
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu -
- 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
This story appears today in The Register:
PDP-10 enthusiasts resurrect ancient MIT operating system
Incompatible Timesharing System now compatible with modern machines
https://www.theregister.co.uk/2017/01/30/pdp10_enthusiasts_resurrect_ancien…
Near the end of the story is a mention of SIMH and of KLH10, both
of which emulate the PDP-10. There is also mention of a PDP-11
emulator running inside ITS.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu -
- 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
> From: Lars Brinkhoff
> several debuggers called RUG and CARPET
SYSENG;CARPET > and SYSENG;KLRUG > (and also SYSEN2;URUG >).
CARPET runs in the PDP-10, and talks to the 11's via the Rubin 10-11 interface
on MIT-AI (which let the PDP-10 see into the PDP-11s' memory); it installed a
small toehold in the 11 (e.g. for trap handling). There was also a version
(conditionalized in the source) called "Hali" ("Hali is Carpet over a [serial]
line") - 'hali' is Turkish for 'carpet' (I wonder how someone knew that).
RUG runs in the front-end 11 on the KL (MIT-MC). URUG is a really simple
version of RUG that runs in a GT40, and use the GT40 display for output.
There's also 11DDT (KLDCP;11DDT >) - not sure why both this and KLRUG exist -
unless RUG was for the front-end 11, and 11DDT was for the I/O-11?
Noel