Goodness, I go to sleep, wake up 8 hours later and there's 50 messages in
the TUHS mailing list. Some of these do relate to the history of Unix, but
some are getting quite off-topic.
So, can I get you all to just pause before you send in a reply and ask:
is this really relevant to the history of Unix, and does it contribute
in a meaningful way to the conversation.
Looks like we lost Armando, that's a real shame.
Cheers, Warren
Peter Salus writes "The other innovation present in the Third Edition
was the pipe" ("A Quarter Century of Unix", p. 50). Yet, in the
corresponding sys/ken/sysent.c, the pipe system call seems to be a stump.
1, &fpe, /* 40 = fpe */
0, &dup, /* 41 = dup */
0, &nosys, /* 42 = pipe */
1, ×, /* 43 = times */
On the other hand, the Fourth Edition manual documents the pipe system
call, the construction of pipelines through the shell, and the use of wc
as a filter (without an input file, as was required in the Second Edition).
Would it therefore be correct to say that pipes were introduced in the
Fourth rather than the Third Edition?
>
> What made Linux happen was the BSDi/UCB vs AT&T case. At the time, a
> lot of hackers (myself included) thought the case was about *copyright*.
> It was not, it was about *trade secret* and the ideas around UNIX. * i.e.*
> folks like, we "mentally contaminated" with the AT&T Intellectual Property.
>
Wasn’t there a Usenix button with the phrase “Mentally Contaminated” on it?
I’m sure I’ve got it around here somewhere. Or is my memory suffering from
parity errors?
David
> keeping the code I work on portable between Linux and the Mac requires
> more than a bit of ‘ifdef’ hell.
Curmudgeonly comment: I bristle at the coupling of "ifdef" and "portable".
Ifdefs that adjust code for different systems are prima facie
evidence of NON-portability. I'll buy "configurable" as a descriptor
for such ifdef'ed code, but not "portable".
And, while I am venting about ifdef:
As a matter of sytle, ifdefs are global constructs. Yet they often
have local effects like an if statement. Why do we almost always write
#ifdef LINUX
linux code
#else
default unix code
#endif
instead of the much cleaner
if(LINUX)
linux code
else
default unix code
In early days the latter would have cluttered precious memory
with unfreachable code, but now we have optimizing compilers
that will excise the useless branch just as effectively as cpp.
Much as the trait of overeating has been ascribed to our
hunter ancestors' need to eat fully when nature provided,
so overuse of ifdef echos coding practices tuned to
the capabilities of bygone computing systems.
"Ifdef hell" is a fitting image for what has to be one of
Unix's least felicitous contributions to computing. Down
with ifdef!
Doug
From: "Doug McIlroy" <doug(a)cs.dartmouth.edu>
Subject:Re: [TUHS] Mac OS X is Unix
> keeping the code I work on portable between Linux and the Mac requires
> more than a bit of ‘ifdef’ hell.
| Curmudgeonly comment: I bristle at the coupling of "ifdef” and "portable".
| Ifdefs that adjust code for different systems are prima facie
| evidence of NON-portability. I'll buy "configurable" as a descriptor
| for such ifdef'ed code, but not "portable".
| <snip>
| "Ifdef hell" is a fitting image for what has to be one of
| Unix's least felicitous contributions to computing. Down
| with ifdef!
| Doug
Doug makes a very good point about ifdef hell. Though I’d claim that it isn’t even “configurable” at some level.
Several years ago I was working at Megatek, a graphics h/w vendor. We were porting the X11 suite to various new boards at the rate of about 1 a week it seemed. Needless to say the code became such a mishmash of ifdef’s that you couldn’t figure out what some functions did any longer. You just hoped and prayed that your patch worked properly on the various hardware you were targeting and didn’t break it for anyone else. You ran the unit tests, if they passed you pushed your change and ran an hid under a rock for a while until you were sure it was safe to come out again.
David
hi all,
For those who have been following my 2.11BSD conversion, I was working
on this in about 2005 and I might have posted about it then, and then
nothing much happened while I did a university degree and so on, but
recently I picked it up again. When I left it, I was partway through
an ambitious conversion of the BSD build system to my own design (a
file called "defs.mk" was included in all Makefiles apparently), and I
threw this out because it was too much work upfront. The important
build tools like "cc" were working, but I have since reviewed all
changes and done things differently. The result is I can now build the
C and kernel libraries and a kernel, and they work OK.
This seems like a pretty good milestone so I'm releasing the code on bitbucket.
See https://bitbucket.org/nick_d2/ for the list of my repositories,
there is another one there called "uzi" which is a related project,
but not document so I will write about it later, in the meantime
anyone is welcome to view the source and changelogs of it.
The 2.11BSD repository is at the following link:
https://bitbucket.org/nick_d2/211bsd
There is a detailed readme.txt in the root of repository which
explains exactly how I approached the conversion and gives build
instructions, caveats and so forth. To avoid duplication I won't post
this in the list, but I suggest people read it as a post, since it's
extremely interesting to see all the porting issues laid out together.
See
https://bitbucket.org/nick_d2/211bsd/src/27343e0e0b273c2df1de958db2ef5528cc…
Happy browsing :)
cheers, Nick
> From: Clem Cole
> You might say something like: Pipe's were developed in a 3rd edition
> kernel, where there was is evidence of nascent idea (its has a name and
> there are subs for it), but the code to fully support it is lacking in
> the 3rd release. Pipes became a completed feature in the 4th edition.
To add to what others have pointed out (about the assembler and C kernels),
let me add one more data-bit. In the Unix oral histories done by Michael S.
Mahoney, there's this:
McIlroy: .. And on-e day I came up with a syntax for the shell that went
along with the piping, and Ken said, "I'm going to do it!" He was tired of
hearing all this stuff, and that was - you've read about it several times,
I'm sure - that was absolutely a fabulous day the next day. He said, "I'm
going to do it." He didn't do exactly what I had proposed for the pipe
system call; he invented a slightly better one that finally got changed
once more to what we have today. He did use my clumsy syntax.
He put pipes into Unix, he put this notation [Here McIlroy pointed to the
board, where he had written f > g > c] into shell, all in one night. The next
morning, we had this - people came in, and we had - oh, and he also changed
a lot of - most of the programs up to that time couldn't take standard
input, because there wasn't the real need. So they all had file arguments;
grep had a file argument, and cat had a file argument, and Thompson saw
that that wasn't going to fit with this scheme of things and he went in and
changed all those programs in the same night. I don't know how ... And the
next morning we had this orgy of one-liners.
So I don't think that suggested text, that it was added slowly, is
appropriate. If this account is correct, it was pretty atomic.
It sounds more the correct answer to the stuff in the source is the one
proposed, that it got added to the assembler version of the system before it
was done in the C version.
Noel
Warren:
Can anybody help explain the "not in assembler" comment?
====
I think it means `as(1) has predefined symbols with the
numbers of many system calls, but not this one.'
Norman Wilson
Toronto ON
I recall reading a long time ago a sentence in a paper Dennis wrote which
went something like "Unix is profligate with processes". The word
profligate sticks in my mind. This is a 30+-year-old memory of a probably
35+-year-old paper, from back in the day when running a shell as a user
level process was very controversial. I've scanned the papers (and BSTJ) I
can find but can't find that quote. Geez, is my memory that bad? Don't
answer that!
Rob Pike did a talk in the early 90s about right and wrong ways to expose
the network stack in a synthetic file system. I'd like to find those
slides, because people keep implementing synthetics for network stacks and
they always look like the "wrong" version from Rob's slides. I've asked him
but he can't find it. I've long since lost the email with the slides,
several jobs back ...
thanks
ron
