derek@sask.UUCP (Derek Andrew) (04/11/84)
We are currently considering converting our Vaxen to 4.2. One of our
chief reasons is to be compatible with the Unix community. It seems
that the only hardware that runs 4.2 presently is the Vax, the Sun and
possibly HP. It seems to us that when the Vax dies, possibly 4.2 dies
with it.
I realize that there are some "improvements" like better filesystem
throughput, better communications, but what else is there? I do not
like the attitude "oh, how can we change Unix today?" but can feel
its presence in much of the software.
So who out there is actually going to run 4.2? I know a lot of people
have licensed it, but who is running it? Why should we switch, or why
should we stick to 4.1?
Please discuss this issue by posting to net.unix-wizards. I anticipate
that responses to this posting will be much more valuable if they are
discussed here rather than just having me summarize the results.
--
Derek Andrew, ACS, U of Saskatchewan, Saskatoon Saskatchewan, Canada, S7N 0W0
{ihnp4 | utah-cs | utcsrgv | alberta}!sask!derek 306-343-2638 0900-1630 CSTnorth@down.UUCP (Professor X) (04/11/84)
Some sites run 4.2 because they want the network support. Believe me, that's the *only* reason we're even thinking about it. Some sites run 4.2 because they don't want to be left behind, now that 4.1 is passe'. But I don't know anyone running 4.2 who thinks it's Truly Wonderful. Those who have gone through the painful cut-over are in a better position to say than I. In certain quarters the perception is that Bell Labs Edition 8 would stomp all over 4.2 if it would be released. It still amazes me that, simply because a bunch of grad student hacker droids at Berkeley unleashed 4.2 (with *gasp* SENDMAIL) on us, the Unix community feels so obliged to accept. Stephen C North
dave@uwvax.ARPA (04/12/84)
We run 4.2bsd. Despite the bugs (we had 4.1bsd and were constantly fixing
bugs in it too -- buggy Berkeley code is nothing new) people here seem happy
with it. Why did we change over? Networking, mostly. The networking code
we had for 4.1 was really bad, we were happy to be rid of it. Also, it's
nice to be compatable with other ARPAnet sites. The faster filesystem has
also made a difference. The conversion wasn't really a big pain, though now
that we are here with 4.2, the local software has increased dramatically,
making any further changes more difficult. Remember, all you Bell System *
lovers, Sys 3/5 don't do paging, and most likely never will (at least on a Vax),
Bell is making its own computers now -- no paging makes it tough to run
5 Mbyte processes with only 4Mbytes memory. For all of you uucp hackers, we
haven't had any problems with uucp (though we don't call out -- except over
hard lines). Sendmail is very nice (although the configuration file is
now the easiest thing to understand) -- it even parses most RFC822 addresses.
There is also a file locking mechanism -- if you want to use it. The disk
quotas have been nice too -- we use them extensively on our instructional
systems -- no more full filesystems here. Also 4.2 allows you to be a member
of multiple groups at the same time -- this has come in handy. Longer
filenames is nice too (no more 14 char limit).
I must admit that they did something strange to signals -- and Berkeley
also seems to have forgotten that many programs can run setgid() instead
of setuid() if all they are looking for is file security.
Overall though, I think we'll keep it.
Dave Cohrs @ wisconsin (yes, we're getting 2.9 for our 11/70 too)
--
Dave Cohrs
...!{allegra,heurikon,ihnp4,seismo,uwm-evax}!dave
dave@wisc-rsch.arpalmc@denelcor.UUCP (Lyle McElhaney) (04/12/84)
Ah, here we go. The great Fickle. It's amazing. When Mike O'Dell got up at the USENIX meeting in Toronto and announced that 4.2 was ready to ship, he got an ovation. Why? Because at that time it was recognized that the then current 4.1bsd was *the* best available UNIX operating system available for the VAX. Sure, there were some who doubted that, who didn't like the -v option on cat, who abhor screen editors on principle (I would still like to know which principle), and who didn't appreciate DoD attempting to standardize *their* software (and hire a grad school to do it). Western Electric was deaf as a post when it came to support; Berkeley wasn't much better, but then with 4.1 it didn't need to be. The ut systems comparisons done by Quarterman et al. tell the story. Note also the reception that the Bell system spokesmen normally receive with their announcements at USENIX. Well, now it happens that AT&T can begin to make *big* money in Information Systems ($40K would pay off my mortgage, with some left over, but its peanuts to them), so they begin working their products in earnest. Good. I see no reason now why System 8 wouldn't stomp all over 4.2bsd. Compare the efforts. Compare the respective development groups' salaries. Compare the head start and the available resources. No reason at all that it could not be everyone's everything. Providing we can get it. Providing it will still support the VAX (if that's a joke, please consider the poor 11/70). And when we do get it, remember the marketing ploys that are attached - ATT has up till this point simply been experimenting with binary-only offerings and pricing which leaves out educational budget considerations. Ah, and Berkeley won't be there any more with its $400 alternative. (Don't think that I believe that ATT is being unfair - just being business- men. That's the way it goes. Just contemplate what it has done to the Korn shell, the termlib package, and the Blit.) But why all the ravings about 4.2? Yes, there have been problems; yet my list of problems is miniscule beside that of most other proprietary operating systems. There are design flaws; but there are also ways around them, and they represent perhaps better ways of doing things in the long run. How many people have bought 4.2, but aren't using it? Well, I saw three notices this week about systems going to be unavailable for the switchover to 4.2. Most of my USENET neighbors are running it. How many run USG systems on VAXen? Is it simply for the networking? (Can *simply* be used in that context?) Is it all just to be trendy? That's a good question. Check back in a year, and lets see then how many are still running 4.2. Meanwhile, lets talk about the problems, and stop the shouting and the rhetoric. Its sounding like an old-time IBM vs. (name your favorite) mud-slinging here. Flame the flames! Oh, and take it easy on the grad students. You may have to be one someday. Just because its slave labor doesn't mean that its bad. And reference the debate in net.sf-lovers concerning using hacker perjoratively. -- Lyle McElhaney (hao,brl-bmd,nbires,csu-cs,scgvaxd)!denelcor!lmc
jsq@ut-sally.UUCP (John Quarterman) (04/13/84)
To get the attributions straight, the systems comparisons referred to
by Lyle McElhaney were done by John Chambers and John Quarterman:
``Unix System V and 4.1C BSD'' and an earlier one on System III and
4.1BSD. What story they tell is up to the reader to decide, since we
went to a great deal of trouble to be as fair as possible to both sides
and let the systems speak for themselves.
Personally, I find all the brouhaha about signals in 4.2BSD to greatly
resemble the fuss people made when System III came out with tty ioctls
that were completely incompatible with the Version 7 ones. Now people
think they're the greatest thing since sliced bread, and castigate the
4.2BSD tty ioctls, which are so baroque mostly because they try to
preserve compatibility with the Version 7 ones.
Perhaps sometimes there is a good reason to make an incompatible change?
Perhaps both those who think that all the 4BSD systems were done solely
by unguided graduate students while USG systems were personally
designed by Dennis Ritchie and Ken Thompson, as well as those who think
that Bill Joy was divinely inspired while nobody at Bell has written a
good line of code since 1979, should both check their facts?
--
John Quarterman, CS Dept., University of Texas, Austin, Texas
jsq@ut-sally.ARPA, jsq@ut-sally.UUCP, {ihnp4,seismo,ctvax}!ut-sally!jsqdan@idis.UUCP (Dan Strick) (04/14/84)
The "brouhaha about signals in 4.2BSD" is not unwarranted. The interruption of a system call by a signal was useful behavior for which 4.2bsd provides no good substitute. It is damn near impossible to simulate the old behavior and the only other way to avoid restarting a system call is to (yecchh) longjump. I was too kind. Correct simulation of the old behavior is completely impractical. One can add code to a signal handler to peek at the machine instruction that will be executed when the interrupted program is resumed (yecchh) and increment the interrupted pc to skip over CHMK instructions (double yecchh), but there is no reasonable way to determine if the system call was interrupted (just look at the stacked ps (check for carry set) and the stacked register 0 (check for EINTR error code) but where is the stacked register 0?). Sometimes I feel like trading in our vax for a pdp 11/40 and running rt11. Dan Strick [decvax|mcnc]!idis!dan
jsq@ut-sally.UUCP (John Quarterman) (04/16/84)
I did not say the "brouhaha about signals in 4.2" is unwarranted. I said
perhaps sometimes there is a good reason for an incompatible change;
all you have done is assert that the change was, in fact, incompatible.
If you think I'm going to take sides in a religious war in UNIX-WIZARDS,
you are mistaken. I would appreciate it if you would not misrepresent me.
--
John Quarterman, CS Dept., University of Texas, Austin, Texas
jsq@ut-sally.ARPA, jsq@ut-sally.UUCP, {ihnp4,seismo,ctvax}!ut-sally!jsqrpw3@fortune.UUCP (04/16/84)
#R:sask:-3400:fortune:11600088:000:3667
fortune!rpw3 Apr 15 23:01:00 1984
As I said here back in December, the problem is that UNIX "signals"
just ARE NOT either decent software interrupts or decent condition
handling primitives.
Certainly we aren't going to accuse the fine Berkeley folk of trying
to do us deliberate harm; tehy attempted to deal with the limitations
that arise (especially in a network environment) when you try to do
something with signals besides use them to abort processes completely.
The problem is that the underlying UNIX semantics are just WRONG. Now
4.2 chose to try and provide one corner, which isn't the corner we have
all grown accustomed to, so peoplw are screaming. But BOTH the old way
and the 4.2 way are just make-do. They are both partial approaches due
to the fact that UNIX signals do not permit "unwinding", but only "longjmp".
If you think that dealing with UNIX signals from the USER side is fun
and games, try doing anything new in the kernel and watch the world
break. You call an innocent kernel support routine which does a "sleep"
at positive priority (o.k., say you DO want the sleep interruptable),
and a signal comes and blows the process away leaving locks you have
set because YOU NEVER KNEW THE LONGJMP HAPPENED!
Yes, USG 5 lets the code that does the sleep say whether signals longjmp
or not, but how is that code to know that the CALLER of it wants to know
we are "unwinding"?? The immediate sleeper can clean up, but how about any
other routines up the call tree? (And what about UNIXes that haven't gotten
around to adding even that? Makes it virtually impossible to maintain any
monitor assertions. ARRGGHH!
Yes, it is possible to use the UNIX ("C", really) "longjmp" as a primitive
out of which a decent stack-unwind can be done. But no-one has! (I did just
a toy example to show it could be done.) The longjmp mentality is sprinked
all over the place. It is going to be a major effort to clean up the kernel,
which is (sorry to say) where the problem lies. The manifestations of that
problem in user mode are just the tip of the iceberg. I dare say, even with
the new hacks in the process exit code, that there will be found MANY ways
to "hang" the new sem/msg/shm features in USG 5. Once users start banging
on those features in ways not anticipated by USG (especially with networks
and lots of signals), we will begin to hear complaints about Sys-5, too.
(Just a guess.)
Without flaming on all night, let me simply refer you to two examples of
adequate primitives. Neither is completely "pretty", but both (especially
the first) offer better models than the current UNIX "signal":
1. Vax architecture condition handling. Read ESPECIALLY what happens
to intermediate condition handlers (like, they get called, NOT jumped
around!) when a "stack unwind" (a "longjmp" that works) happens.
(Ref: Vax Architecure Handbook, DEC, 1981, Appendix C., Sections 4, 9-12)
2. TOPS-10 Software Interrupts. A complete facility allowing interrupting
a user process on practically any interesting event (including system
calls!). Almost mandatory for reasonable multi-device non-blocking I/O.
(Ref: TOPS-10 Monitor Calls, Vol. 2 DEC AA-K039A-TB, August 1980,
applies to TOPS-10 version 7.01)
The usefulness of the TOPS-10 modem is that it was added on BESIDE an
already existing set of functions that bear a striking resemblance to
current UNIX signals. The original functions were left untouched, so
old programs got the same behavior. I believe it is possible to do the
same to UNIX.
Rob Warnock
UUCP: {ihnp4,ucbvax!amd70,hpda,harpo,sri-unix,allegra}!fortune!rpw3
DDD: (415)595-8444
USPS: Fortune Systems Corp, 101 Twin Dolphin Drive, Redwood City, CA 94065gwyn@brl-vgr.ARPA (Doug Gwyn ) (04/18/84)
I managed to emulate the old signal() behavior rather successfully in the BRL UNIX System V emulation for VAX 4.2BSD. And yes, it is incredibly bizzare, baroque, gross, and GROADY TO THE MAX! Another REALLY AWESOME idea implemented wrong, FER SURE.
mwm@ea.UUCP (04/19/84)
#R:sask:-3400:ea:13500014:000:1003 ea!mwm Apr 19 15:40:00 1984 /***** ea:net.unix-wizar / idis!dan / 8:07 am Apr 16, 1984 */ The "brouhaha about signals in 4.2BSD" is not unwarranted. The interruption of a system call by a signal was useful behavior for which 4.2bsd provides no good substitute. It is damn near impossible to simulate the old behavior and the only other way to avoid restarting a system call is to (yecchh) longjump. Dan Strick [decvax|mcnc]!idis!dan /* ---------- */ Partially false. The only case I can think of where you actually want a system call interrupted (as opposed to continuing cleanly) is read/write. For those, select(2) does almost exactly what you want. Occasionally, it'll even be closer than read/write. It is ugly as sin, but that's a small price to pay for not having to worry about whether or not I was in a system call when the signal came. I prefer the way berkeley did it. If only they'd done a thorough job of it, and gotten *all* the gotchas out of the signal mechanism, instead of just most of them. <mike
shaddock@unc.UUCP (Mike Shaddock) (04/21/84)
Here here!! I'm glad to see that I'm not the only one who is tired of hearing people complain about how bad 4.2 is. I would rather take a somewhat buggy system with some nice features (like screen editors and job control!) over a system that works right all the time but is a pain to use.
mike@BRL-TGR.ARPA (04/23/84)
From: Mike Muuss <mike@BRL-TGR.ARPA>
Vendor support for 4.2 ?
The list is reasonably impressive. In no particular order:
DEC
SUN
Gould
Pyramid
There are probably more, but none come to mind right now.
In particular, Pyramid has a really spiffy box, ~1.5 x VAX 780,
for ~$100K, and Gould has a really FAST box, ~10 x VAX 780,
for ~$400K. We (U. S. Army BRL) are seriously considering
both of these vendors as being worthy alternatives to VAXen.
[Always trying to squeeze the most cycles out of your tax dollars!]
Best,
-Mike Muuss
(301)-278-6678
AV 283-6678
FTS 939-6678
ArpaNet: Mike @ BRL
UUCP: ...!{decvax,research}!brl-bmd!mike
Postal:
Mike Muuss
Leader, Advanced Computer Systems Team
Computer Techniques and Analysis Branch
Systems Engineering and Concepts Analysis Division
U.S. Army Ballistic Research Laboratory
Attn: DRSMC-BLB (Muuss)
APG, MD 21005rsk@PURDUE.ARPA (04/25/84)
From: Rsk the Wombat <rsk@PURDUE.ARPA> > But I don't know anyone running 4.2 who thinks it's Truly Wonderful. Perhaps the same could be said for v6, 2.8bsd, v7, v32, SIII, etc. Does that mean 4.2 is crap? > Those who have gone through the painful cut-over are in a better position > to say than I. We didn't find it painful at all. It went very smoothly, and although 4.2 has its problems, we are pleased with its features and performance. > In certain quarters the perception is that Bell Lab Edition 8 > would stomp all over 4.2 if it would be released. In certain quarters the perception is that Berkeley 4.3 would stomp all over 4.2 if it would be released. But it's not...yet. So, for practical purposes, it's probably not worth talking about. > It still amazes me that, simply because a bunch of grad student hacker droids > at Berkeley unleashed 4.2 (with *gasp* SENDMAIL) on us, the Unix community > feels so obliged to accept. But if *real* programmers had done it, it would have turned out better, eh? Sendmail was done by Eric Allman, anyhow...who is not, I believe, a grad student hacker droid. Additionally, I am not aware of any instances of Berkeley people flitting about twisting arms in order to get folks to convert to 4.2BSD. Proud to be a grad student hacker droid, ---- Rich Kulawiec UUCP: { allegra, decvax, ihnp4, harpo, teklabs, ucbvax } !pur-ee!rsk { cornell, eagle, hplabs, ittvax, lanl-a, ncrday } !purdue!rsk