geoff@utcs.UUCP (Geoff Collyer) (12/10/84)
Guy Harris, in denouncing ulimit (in net.unix), recently wrote The only explanation I can think of is homesickness for PWB/UNIX (S3 and S5 are derived from a mix of V7, PWB/UNIX, and various other internal UNIX systems), where the V6 file system was hacked to only support singly-indirect blocks and as such didn't support files bigger than 1 Mbyte in any form. It's time to set this long-standing misconception straight: System N are *not* derived from V7; they are derived from a late V6. This may seem a small point, but AT&T sells System N in part by claiming that they are a merger of V7, PWB and other internal (mainly USG) UNIX brand operating systems, implying that System N contains everything of value from V7. To quote from an AT&T (nee Bell) System III advertisement: ``UNIX System III combines the features of the UNIX System, Seventh Edition (V7), and the PWB/UNIX System with several major enhancements. ... UNIX System III = V7 + PWB + EXTRAS''. Here is a partial list of software found in V7 which is absent in System III and probably System V, though I haven't kept track since it became apparent that I don't want to run System N. at(1): run commands at a later time, due to broken chown(2) enroll(1), xsend, xget - secret mail grep(1) -y: case-insensitive grep (ld(1): System N ld doesn't understand random libraries) learn(1): CAI about UNIX brand operating systems look(1): binary search on a sorted file lookbib(1): search bibliographic data base, uses dbm(3) (mv(1): System N mv can't move directories up or down the tree) pubindex(1): generate bibliographic index, uses dbm(3) quot(1m): summarise disk use by user ranlib(1): convert object archives to random libraries for ld refer(1): bibliographic troff pre-processor, uses dbm(3) sort(1) -T: change temporary directory (undocumented, may be in the code) struct(1): convert Fortran to Ratfor mpx(2): file multiplexor, replaced only in V8 by stream I/O pkon(2), pkoff: packet protocol dbm(3x): a simple but effective data base manager mp(3x): multi-precision integer arithmetic (tty(4): replaced by USG's arguably better but utterly incompatible one) ms(7): the -ms macros (due to obvious rivalry with -mm) Clearly the USG didn't take all this software out of System III; it was never a part of System III because System III was based on a pre-V7 system. Some of the above may have been deliberately omitted (e.g. at, ms and pkon), but not all of this (why would USG ship an inferior mv and grep?). Note to OEMs: your System N licence covers V7. You can correct the omissions of the USG and add most of this software into your distributed System N (admittedly putting mpx back in and getting it debugged may take some effort). Actually the USG should correct these omissions in future System N releases. -- System V: none genuine without the mark of the USG sledgehammer of approval.
mike@whuxl.UUCP (BALDWIN) (12/13/84)
Geoff@utcs writes: > Here is a partial list of software found in V7 which is absent in System III > and probably System V, though I haven't kept track since it became apparent > that I don't want to run System N. Here are the things that are in System V Release 2: > at(1): run commands at a later time, due to broken chown(2) Has an at(1) which has multiple at queues (which run at different priorities), removal and listing of your at jobs, and a batch command (which is just at -qb). BTW, chown(2) works just fine. > grep(1) -y: case-insensitive grep Grep, egrep, and fgrep have -i for ignore case. > (ld(1): System N ld doesn't understand random libraries) > ranlib(1): convert object archives to random libraries for ld The archives have symbol tables built in (ar(1) knows about them). Therefore, ranlib doesn't need to exist, and ld(1) can handle archives efficiently. > learn(1): CAI about UNIX brand operating systems Instructional Work Bench (IWB) has the teach program. > sort(1) -T: change temporary directory (undocumented, may be in the code) Sort rewritten to be faster, has options for size of buffers used and even sorting by month name (jan < feb < mar ...). It has -T, but it's still undocumented (sigh!). > (mv(1): System N mv can't move directories up or down the tree) But /etc/mvdir will do it (but only superuser can run it!?). > quot(1m): summarise disk use by user acctdusg(1m) summarises disk use by user. > (tty(4): replaced by USG's arguably better but utterly incompatible one) So? Termio(7) is incompatible but much saner. > ms(7): the -ms macros (due to obvious rivalry with -mm) True (I think mm is better). Here are the missing, but not missed, things: > look(1): binary search on a sorted file It's nice for /usr/dict/words, what else? > enroll(1), xsend, xget - secret mail Secret mail? Give me a break. > pkon(2), pkoff: packet protocol Is this necessary at the kernel level? > mpx(2): file multiplexor, replaced only in V8 by stream I/O You miss mpx(2)? You're the only one I've met who does. There are FIFO's, message queues, semaphores and shared memory if you want IPC. Here are the missing things: > struct(1): convert Fortran to Ratfor > dbm(3x): a simple but effective data base manager > mp(3x): multi-precision integer arithmetic Not in SVR2; some kind of dbm would be real nice. > lookbib(1): search bibliographic data base, uses dbm(3) > pubindex(1): generate bibliographic index, uses dbm(3) > refer(1): bibliographic troff pre-processor, uses dbm(3) I don't think the refer system is available. Just thought I'd clear some things up. Michael Baldwin AT&T Bell Labs harpo!whuxl!mike
guy@rlgvax.UUCP (Guy Harris) (12/14/84)
> It's time to set this long-standing misconception straight: > System N are *not* derived from V7; they are derived from a late V6. What do "V6" and "V7" refer to here? There was only one tape sent out with the Sixth Edition of the UNIX Programmer's manual, so in that sense there is no such thing as an "early" or "late" V6. I consider the main things that distinguish V6 from V7 to be the file system (and system calls changed for the new file system) and the Bourne shell; System III had that (heck, UNIX/TS 1.0 had that). As such, I consider them derived from a system between V6 and V7, but closer to V7 than V6. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
hokey@gang.UUCP (Hokey) (12/14/84)
> > mpx(2): file multiplexor, replaced only in V8 by stream I/O > You miss mpx(2)? You're the only one I've met who does. > There are FIFO's, message queues, semaphores and shared memory if you want > IPC. Michael, I couldn't pass this up. Semaphores? I wouldn't call them that. What was implemented is a STACK, not a QUEUE. Can people imagine how useful this really is? Just think, the sooner a process wants something the later it gets it! Some time ago, Somebody posted a program to test the semaphore system because their implementation occasionally woke two processes at the same time. (I include it at the end of my posting.) While we never had the bug they found, I did notice that the first two (out of four) processes in the test NEVER execute, and the last two simply trade off the resource. This is not at all surprising, given the semaphore mechanism implements a stack instead of something useful. Anybody care to disagree with me? Hokey ----- /* sem_vax.c: test of vax/unix semaphors */ /* This program seems to run on some machines (e.g. ibm370/unix5.0.3, * 3b-20s/unix5.0.5, etc), * but not on our development machine (i.e. vax11780/unix5.0) * Actually, it does work sometimes, especially under light loads. * Unfortunately, we NEED semaphors!!!!! * * This program becomes 4 processes which communicate via one semaphor (simple) * Each process does a blocking decrement, a gets(), and an increment * in a forever loop. * The semaphor starts at 1, so one process (first up) can decrement and begin. * After the user enters a line, it increments the semaphor, * allowing the next-scheduled process to decrement it, and ask for input. * At no time should two processes be waiting on the tty. * It is a simple exclussive-access program. * Sometimes, I enter return, and get two (or more) "waiting input" lines. * Sometimes it is broke from the start, and i get multiple lines * without entering anything. * The problem is not deterministically reproducable. * Try entering input about every 15 seconds, when the Vax is busy. * * Is it just a 5.0 bug that has been fixed? * Should i try to get a later release? * Is it a vax/unix bug? */ #include <errno.h> #include <sys/types.h> #include <sys/ipc.h> #include <sys/sem.h> /* semop structures */ static struct sembuf decr[]= { {0,-1,SEM_UNDO} }; static struct sembuf incr[]= { {0,1,SEM_UNDO} }; main(){ key_t mkey; int id2; mkey = (getgid()<<16); id2 = semget(mkey,1,IPC_CREAT|0660); if(id2<0){ puts("bad semget"); exit(0); } if(semctl(id2,0,SETVAL,1)){ puts("cannot set value to 0 (initially)"); exit(0); } printf("val %d\n",semctl(id2,0,GETVAL,0)); /* one process becomes 4 */ fork(); fork(); while(1){ char s[30]; if(semop(id2,decr,1)<0) printf("bad call to semop(), errno %d\n",errno); /* mutual-exclussive begin */ printf("process %d, val %d: awaiting input\n" ,getpid(),semctl(id2,0,GETVAL,0)); gets(s); /* Using sleep(15) instead of gets(s) does not help */ /* mutual-exclussive end */ if(semop(id2,incr,1)<0) printf("bad call to semop(), errno %d\n",errno); } } -- Hokey ..ihnp4!plus5!hokey 314-725-9492
henry@utzoo.UUCP (Henry Spencer) (12/14/84)
> > grep(1) -y: case-insensitive grep > Grep, egrep, and fgrep have -i for ignore case. Of course, they couldn't be bothered being compatible with the system they produced which had this option before. > > learn(1): CAI about UNIX brand operating systems > Instructional Work Bench (IWB) has the teach program. Last I heard, IWB is (a) separate, (b) extra cost, and (c) binary-only. This is not a substitute for learn(1), guys. > > sort(1) -T: change temporary directory (undocumented, may be in the code) > ... has -T, > but it's still undocumented (sigh!). It's documented in V7, guys. Always has been. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
geoff@utcs.UUCP (Geoff Collyer) (12/15/84)
Michael Baldwin writes: Here are the things that are in System V Release 2: > at(1): run commands at a later time, due to broken chown(2) Has an at(1) which has multiple at queues (which run at different priorities), removal and listing of your at jobs, and a batch command (which is just at -qb). BTW, chown(2) works just fine. I'm glad to hear that chown has been fixed; allowing ordinary users to chown files just so RJE didn't have to be setuid-root was silly. > (tty(4): replaced by USG's arguably better but utterly > incompatible one) So? Termio(7) is incompatible but much saner. Just the facts, ma'am. Here are the missing, but not missed, things: > look(1): binary search on a sorted file It's nice for /usr/dict/words, what else? I use it for searching phone books. look is very handy for checking the spelling of a word, *before* you use it rather than after spell complains about it. > enroll(1), xsend, xget - secret mail Secret mail? Give me a break. Just the facts. > pkon(2), pkoff: packet protocol Is this necessary at the kernel level? Of course it isn't necessary. JTFM. > mpx(2): file multiplexor, replaced only in V8 by stream I/O You miss mpx(2)? You're the only one I've met who does. There are FIFO's, message queues, semaphores and shared memory if you want IPC. Nothing has ever fully replaced mpx(2). It was buggy as distributed and the manual page was a bit hard to understand, but mpx is a very general mechanism. Maybe you don't meet the right people. The point of my original article was not to attack System N for omitting specific bits of software, but to correct a mistaken belief about System N held by a lot of people: the belief that System N are derived from v7. (Well, maybe I got in a bit of Uglix-bashing.) -- Eighth Edition: UNIX for the eighties.
mike@whuxl.UUCP (BALDWIN) (12/15/84)
> Michael, I couldn't pass this up. Semaphores? I wouldn't call them that. > What was implemented is a STACK, not a QUEUE. Can people imagine how useful > this really is? Just think, the sooner a process wants something the later > it gets it! Sigh! I ran the test program, and sure enough, only two of the processes ever got the semaphore! Oh well. I've submitted a trouble report on it, so at least it has a chance of being fixed in the near(?) future. But hey, lots more bugs have been fixed in System V than have been introduced in 4.2BSD !! Michael Baldwin AT&T Bell Labs harpo!whuxl!mike
lmc@denelcor.UUCP (Lyle McElhaney) (12/16/84)
> > ms(7): the -ms macros (due to obvious rivalry with -mm) > True (I think mm is better). It may be a lot better (or at least more complicated (oops, flexible)), but since they both can live together, there is a lot of documentation written in the former, and there are a few advantages to -ms (like loading a lot faster), then why was it just dropped? On this same vein, why is there not a command that can be included in the source text that informs n/t/roff of the macro package to be used on the text? It seems like the obvious thing to do. I don't think .so was designed for that. Oh, well, just a question rolling around that this gave me an opportunity to ask. -- Lyle McElhaney {hao, stcvax, brl-bmd, nbires, csu-cs} !denelcor!lmc
geoff@utcs.UUCP (Geoff Collyer) (12/16/84)
``late V6'' refers to research UNIX before it was released as V7. I didn't think this required explanation.
ron%BRL-TGR@tgr.UUCP (12/17/84)
>Last I heard, IWB is (a) separate, (b) extra cost, and (c) binary-only.
Yeah, and in addition only is distributed for the VAX.
-Ronjohn@x.UUCP (12/18/84)
> But hey, lots more bugs have been fixed in System V than have been > introduced in 4.2BSD !! Guess that says it all !-) -- John Woods, Charles River Data Systems, Framingham MA, (617) 626-1114 ...!decvax!frog!john, ...!mit-eddie!jfw, jfw%mit-ccc@MIT-XX.ARPA If your puppy goes off in the next room, is it because of the explosive charge? [y][n]
mike@whuxl.UUCP (BALDWIN) (12/19/84)
> >Last I heard, IWB is (a) separate, (b) extra cost, and (c) binary-only. > > Yeah, and in addition only is distributed for the VAX. Last *I* heard (a few minutes ago from AT&T UNIX #: (800) 828-UNIX), you *can* get source (you can also write new templates), and is distributed for all 3B's and all Vaxes. And what's the problem with separate and extra cost? That's the way you sell operating systems; everybody does that. It doesn't make sense to sell one monolithic system. In SVR2, even the text processing tools are separate. So what? Michael Baldwin
henry@utzoo.UUCP (Henry Spencer) (12/21/84)
> Last *I* heard (a few minutes ago...), you *can* get source ... Even if you're outside AT&T? The initial announcement of IWB was most definitely binary-only; if this has changed since, it hasn't been well publicised. > ... And what's the problem with separate and extra > cost? That's the way you sell operating systems; everybody does that. > It doesn't make sense to sell one monolithic system... How do you think Unix got so popular? -- "Those who do not remember the past are condemned to repeat it." Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
geoff@utcs.UUCP (Geoff Collyer) (12/22/84)
Michael Baldwin wrote: > > >Last I heard, IWB is (a) separate, (b) extra cost, and (c) binary-only. > And what's the problem with separate and extra > cost? That's the way you sell operating systems; everybody does that. > It doesn't make sense to sell one monolithic system. In SVR2, even the > text processing tools are separate. So what? Doing something because everybody else does it is pretty mindless, but that's what I've come to expect from USG/USDL/what-ever-they-call-themselves-this-week. That's the way *who* sells operating systems? It's a sad day when UNIX is perceived as a monolithic system. For you newcomers, UNIX was conceived as a reaction *against* monolithic systems; it is a tribute to USG/USDL/...'s destructive power that they have made System V a monolithic system or at least made some people see it that way. As System V is unbundled, I haven't noticed the price of the base system dropping, only the creation of expensive ``work-benches'' which are simply old code that's been hacked over by USG/USDL/... I gather that the trend to unbundling will continue and we can look forward to a base System V Release N consisting of a kernel and a collection of work- benches, including the Concatenator's Work Bench (cat with options), the Editor's Work Bench (ed), the Echoer's Work Bench (echo), the Logician's Work Bench (true and false), the User's Work Bench (login), the Manual Reader's Work Bench (man) and the Sleepy-head's Work Bench (sleep).
ian@utcs.UUCP (Ian F. Darwin) (12/24/84)
[This topic started when Geoff Collyer (geoff@utcs) claimed that
System III/V derive not from V7, as AT&T now seems to claim,
but from a pre-v7 system. He listed many features which are
in v7 and 4.1 that never were in System III because that system
derived from something before v7. Comment in this newsgroup
has been interesting but has not produced any new evidence.
Here is an authoratative quote on the original question.]
In the October 1984 issue of Microsystems is an interview with
Ken Thompson and Dennis Ritchie. Dennis, I think, has the final
word on the `System N history':
Dennis: ``... the split between us [Research] and the
development area [USG/USDL] -- in the sense that
they stopped following us and actively taking
everything we did -- that happened *before* the
7th Edition [emphasis in original]. So that the
actual branch in the tree was not only before
[System] III, but before [Version] 7. It's not
that we've stopped talking to each other; it's just
that the very active collaboration stopped...'' (page 54).
I hope this will lay to rest any doubts that System III historically did
derive from a pre-v7 version of Research UNIX.
In fairness to all, Dennis also says of the *current* situation
(remember that the pre-v7 split occurred before 1979),
Microsystems: ``What is your relationship with them [USG/USDL]?''
Dennis: ``Organizationally, practically none at all.
We're in the research area, they're in the computer
line of business -- the development area. As far
as relations are concerned, there's a *lot* of
exchange... (page 51)''
The interview touches on several topics of interest to
readers of this newsgroup. Since Microsystems has been terminated
with extreme prejudice by Ziff-Davis, you will have to go to the
library or find a friend who subscribed if you want to read the
rest of the article; I don't have it online and my fingers are
not up to typing the whole thing in (nor would it be prudent
for me to do so...).
--
Ian Darwin, Toronto
{ihnp4|decvax}!utcs!iankdq@pthya.UUCP ( Kip Quackenbush) (12/27/84)
The bottom line is dollars no matter which way you look at it.
Can you fault ANY buisness for wanting to make some bucks?
--
Kip Quackenbush
pthya!kdq
{ihnp4,ucbvax,cbosgd,decwrl,amd,fortune,zehntel}!dual!pthya!kdq
Pacific Bell, Hayward, Californiagwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (12/29/84)
> Can you fault ANY buisness for wanting to make some bucks?
No, but you can fault them for ignoring the real long-term profits
generated by UNIX and instead trying to squeeze the very people who
can make UNIX a roaring success (the application developers).