4.2 progressive or dead end

[Derek Andrew]

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 CST

[Professor X]

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

[da...@uwvax.arpa]

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
da...@wisc-rsch.arpa

[Lyle McElhaney]

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

[John Quarterman]

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
j...@ut-sally.ARPA, j...@ut-sally.UUCP, {ihnp4,seismo,ctvax}!ut-sally!jsq

[Dan Strick]

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

[John Quarterman]

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.

[Doug Gwyn]

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.

[m...@ea.uucp]

#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

[Mike Shaddock]

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.