> From: Warren Toomey <wkt(a)tuhs.org>
> That's all I knew at the time :-)
:-) I used nroff/troff for a bit, but I didn't like it; I don't recall why,
but I suspect I wasn't using people's macro packages, which probably made it
more difficult to use. My favourite was SCRIBE, but it alas seems to have
died.
> From: Dan Cross <crossd(a)gmail.com>
>> the original Western Electric copies are not troff'ed and run through
>> a typesetter ...
> Indeed. Even the mid-90's Peer-to-Peer press reprinting appears to be,
> roughly, a facsimile of line printer output. ...
> Interestingly, the title page appears to be approximately original and
> is typeset.
I finally located my copy of the reprint (I'd been using it to help Fritz
Mueller find a problem in his RK11C, and it wasn't in its normal place), and
comparing it with my 'samizdat' set (which came from a set owned by
Lincoln-Sudbury High School - they actually had an -11 running V6, I helped
their computer person, I forget his name now, with it), I can confirm that:
- The reprint does mostly reproduce the exact page images from the original
(which was indeed, mostly line-printer out), except that the original does not
have the typeset chapter/section header pages. It's possible that the pages in
the reprint are a new printing, but if so, they have exactly matched not only
the layout (not too hard) of the original, but also the font.
- In a couple of places (e.g. Contents, pg. 1; Preface, pg. 1; Chapter One,
pg. 1) "UNIX" has been replaced by "UNIX*" (different font), and at the bottom
of the page has been added "* UNIX is a Trademark of Bell Laboratories", again
in a different font.
- The typeset 'Source Code' title page is in the original; the copy in the
reprint is an exact image, except that the upper-case "This information ...
Written permission of Bell Laboratories" section is not in the original,
which says instead at that place: "This document may contain information
covered by one or more licenses, copyrights and non-disclosure agreements.
Circulation of this document is restricted to holders of a license for the
UNIX Software System from Western Electric. All other circulation or
reproduction is prohibited."
- The typeset 'Commentary' title page is different in my samizdat First
Edition original; it's a copy of the other title page, except that the
second para is replaced by the first sentence of the 'Commentary' title
page of the reprint, and of course the title is different from the other
volume.
Noel
> From: Richard Salz
> Any view on this?
> https://www.microsoft.com/en-us/research/publication/a-fork-in-the-road/
Having read this, and seen the subsequent discussion, I think both sides have
good points.
What I perceive to be happening is something I've described previously, but
never named, which is that as a system scales up, it can be necessary to take
one subsystem which did two things, and split it up so there's a custom
subsystem for each.
I've seen this a lot in networking; I've been trying to remember some of the
examples I've seen, and here's the best one I can come up with at the moment:
having the routing track 'unique-ID network interface names' (i.e. interface
'addresses') - think 48-bit IEEE interface IDs' - directly. In a small
network, this works fine for routing traffic, and as a side-benefit, gives you
mobility. Doesn't scale, though - you have to build an 'interface ID to
location name mapping system', and use 'location names' (i.e. 'addresses') in
the routing.
So classic Unix 'fork' does two things: i) creates a new process, and ii) replicates
the environment/etc of an existing process. (In early Unix, the latter was pretty
simple, but as the paper points out, it has now become a) complex and b) expensive.)
I think the answer has to include decomposing the functionality of old fork()
into several separate sub-primitives (albeit not all necessarily directly
accessible to the user): a new-process primitive, which can be bundled with a
number of different alternatives (e.g. i) exec(), ii) environment replication,
iii) address-space replication, etc) - perhaps more than one at once.
So that shell would want a form of fork() which bundled in i) and ii), but
large applications might want something else. And there might be several
variants of ii), e.g. one might replicate only environment variables, another
might add I/O channels, etc.
In a larger system, there's just no 'one size fits all' answer, I think.
Noel
> When did the Unix filesystem add the semantics for "files with holes" (large,
> sparse files)?
It was there in the first edition:
https://www.bell-labs.com/usr/dmr/www/pdfs/man51.pdf
The FILE SYSTEM (V) man page includes a last paragraph identical to
that of FILSYS (V) in seventh edition:
If block b in a file exists, it is not necessary that all blocks
less than b exist. A zero block number either in the address words
of the the i-node or in an indirect block indicates that the
corresponding block has never been allocated. Such a missing block
reads as if it contained all zero words.
The first edition indirect blocks were a bit different though: if the
file was bigger than 8 blocks (4kB), all the blocks in the inode were
(singly) indirect.
-- Richard
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
When did the Unix filesystem add the semantics for "files with holes" (large,
sparse files)?
Just an idle question that was sparked by a conversation I had today.
Erik <fair(a)clock.org>
The more I think about this, the more I'm sure I'm barking up the wrong
tree...
>From bits and pieces I've been able to recall, the thing I am looking for
was not about Unix - it was about TOPS-20. It was a timeline of the
system bootstrap activities from power-on to the point where users could
log in. I still don't remember where I found it originally, but at least
now I'm pretty sure I've been looking in all the wrong places... I
believe it originated at CMU, but I don't know for sure that that's where
I originally located it.
The actual problem I'm trying to solve is, at this point in my
professional career, I'm starting to interact with a lot of people (even
experienced software developers) who just have no clue of what has to
happen to get a computer from the point of "power-on" to the point where
they can actually use it to do things. This makes me sad... So, I'm
looking for something that I can point these people to that could clue
them in... I think the whole bootstrap process is useful to understand
for a lot of reasons, partly because it makes you think about all the
little fiddly details that have to be attended to to make the computer do
what you want - when I was first learning about this, I remember being
particularly fascinated by what had to happen to prepare for that moment
at which you turn on the MMU, to make sure that the system continues
executing in a place you expect it to, in the right processor mode. I
know most people that I interact with are using Linux or Windows on
Intel-architecture machines, but the boot process for Unix on the PDP-10
or VAX (or even TOPS-20 on the PDP-10) I thought would be a much simpler
thing to understand. Though maybe that's the wrong thought process, maybe
I should just find something related to Linux that is comparable (even
though I think it's more complicated).
While searching, I also came across a decent presentation by a friend of
mine who teaches at CMU, and discusses hardware that people probably
actually work with right now, but I think it would be best consumed along
with the actual lecture that it goes with.
http://www.cs.cmu.edu/~410-f08/lectures/L20_Bootstrap.pdf
Maybe I'll find what I was originally looking for at some point, but after
spinning on this for most of the day, I don't think it's related to
Unix...
--Pat.
This thread brings to mind a wonderful saying which I just saw in another forum:
"A wise man speaks when he feels he has something to say - a fool speaks when
he feels he has to say something."
And to reply in advance to the 'but I did't realize so many other people had
sent in replies' - try scanning your emailbox before replying to messages to a
large list.
S/N is to be hallowed.
Noel
This book can apparently be "borrowed" from the Internet Archive. I'm not
sure how they do that, haven't tried to, I just see it says you need to
log in to borrow the book for 14 days.
https://archive.org/details/unixprimerplus00wait
--Pat.
