[comp.unix.questions] layers vs SunView

gwyn@brl-smoke.ARPA (Doug Gwyn ) (02/08/88)

In article <5400018@snail> carroll@snail.CS.UIUC.EDU writes:
>1. You can telnet out of a SV window. Telnet hangs in a layer.

I think you must have a pretty sick implementation of layers
and/or telnet.  Telnet works fine for me from a layer, using
either xt or pty based implementations.

>2. You can have about as many SV windows as you want. Only 6 layers.

7 on the 630, plus optionally 7 more if you decide to use the second
port for host access instead of a printer.  A layer on the 630 can
also split into sublayers, and layers that don't need host access
can detach themselves, freeing the channel for use with another layer.

I find in practice I seldom use the 6th layer on my DMD (5620),
just as most of the Sun users I've seen have a whole pile of idle
icons that they practically never access.

>3. You may belittle speed, but waiting 7 or 10 minutes for layer program
>   to load is very irritating.

I imagine it would be!  However, it doesn't take 7 or 10 minutes for
anything I know of to download.  That would be around 500KB at 19.2KB
(assuming your computer is streams-based, or otherwise good enough to
push the packets at that rate), which is much larger than any DMD
application I know of.  Remember, the whole idea is that only the
special interactive portion of an application runs in the terminal;
most of the file management etc. runs on the host.  The default
terminal emulator (shell) takes no time at all since it's resident;
typical applications take from 10 seconds to a minute at 9600 baud,
but then with any planning you started the download while you were
still occupied with work in another layer.

If you're talking about downloading over a 1200 baud phone line,
then for fairness you should consider a diskless Sun trying to use
the same facilities for its Net Disk.  (I don't think it's even
supported.)  If you think the Sun should be configured standalone
(with disk), then for fairness you should consider the 630 with an
attached 3B2 and disk, or some other comparable set-up.

>4. Being able to icon-ify windows in SV is wonderful...I can put things that
>   that I don't need all the time in  little icons, and grab them when they
>   are useful.

Layer processes can also be designed to do that.  I have one..
But they usually aren't, due to difference in philosophy and
in operating environment.  Indeed, although they appear
similar, due to both having bit-mapped displays and both
(typically) having a UNIX on tap, the difference in environment
is quite visible to the programmer.  Depending on what you want
to do, one or the other might be the best fit; neither is
universally superior.

>5. "toolplaces" in SV : this lets me set up my windows the way I want,
>   without having to calculate screen positions.

The .layers (or .mpxrc) file specifies initial layer windows and
processes.  Somehow I don't have much trouble with calculations,
given that 1 inch = 100 pixels.

>6. When you exit a shell in a SV window, the  window closes. In layers, it
>   just sits there, unusable.

Wrong; if you have a sensible host multiplexer ("layers" utility),
termination of the host process (often, but not always, a shell)
attached to a layer channel will cause the layer to be deleted, and
vice-versa.

>7. Support programs. The  SunView support is vastly superior, such as
>   the icon editor, font editor, mail, etc.

The DMD has had an icon editor for many years now.  I admit that a
font editor would be useful.  There is undoubtedly some wonderful
software available for either display type that is not available
yet for the other.  AT&T's poor marketing of the DMD did not help
layers software availability.

Sorry to go on at such length, but with both a Sun and a 5620 on
my desk (and a 630 nearby) I thought a more balanced appraisal
might be appropriate.

ron@topaz.rutgers.edu (Ron Natalie) (02/10/88)

Be it what it may, Doug.  Telneting from a layer on the 3B2/dmd combination
hangs.  That's OK, you can't run cu from a 3B20 console either (it says
exactly that if you try.).

-Ron

gwyn@brl-smoke.ARPA (Doug Gwyn ) (02/11/88)

In article <17930@topaz.rutgers.edu> ron@topaz.rutgers.edu (Ron Natalie) writes:
>Be it what it may, Doug.  Telneting from a layer on the 3B2/dmd combination
>hangs.

Yes, in follow-up (off-line) mail, I was told of the many problems that
the DMD software on the 3B2 apparently has.  I don't know why in the world
AT&T wouldn't do a better job than that; one gets the feeling they're not
serious about selling either computers or terminals.  I hope their 630
software support is better than that!

Of course, as you know, BRL uses our own rendition of AT&T's DMD software,
since we mostly have 4.nBSD-based systems and AT&T didn't offer a package
for that environment.  At least the formerly-Teletype folks have arranged
for a 4.nBSD distribution for the 630 software to be available.  (The work
was apparently mostly done at UCSD.  I was supposed to help, but due to
local circumstances was unduly delayed.  Eventually there will be a BRL
version of the 630 software, since the UCSD one is aimed at the native
Berkeley environment, whereas I do software development in the System V
environment, which I much prefer.)

ekrell@hector.UUCP (Eduardo Krell) (02/11/88)

In article <7239@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:

>I hope their 630 software support is better than that!

I am on a 630 right now. Host #1 is a 4.3BSD Vax; host #2 is a SVR3 3B2
(both running layers). I can telnet from a layer window on either host to
any other machine and it works just fine. Is this a good enough proof??
    
    Eduardo Krell                   AT&T Bell Laboratories, Murray Hill, NJ

    UUCP: {ihnp4,ucbvax}!ulysses!ekrell		ARPA: ekrell%ulysses@att.arpa

gwyn@brl-smoke.UUCP (02/11/88)

In article <10040@ulysses.homer.nj.att.com> ekrell@hector (Eduardo Krell) writes:
>I am on a 630 right now. Host #1 is a 4.3BSD Vax; host #2 is a SVR3 3B2
>(both running layers). I can telnet from a layer window on either host to
>any other machine and it works just fine. Is this a good enough proof??

That sounds much better, but is that software the same as the general public
gets (say, with their 3B2+630), or is it more of the nifty Bell Labs internal
stuff that nobody else can get hold of?

Is the System V layers multiplexing converted to STREAMS yet?  Does it work
as well as on Ninth Edition UNIX?  I would be interested in knowing...

rsalz@bbn.com (Rich Salz) (02/11/88)

=Of course, as you know, BRL uses our own rendition of AT&T's DMD software,
=since we mostly have 4.nBSD-based systems and AT&T didn't offer a package
=for that environment.  At least the formerly-Teletype folks have arranged
=for a 4.nBSD distribution for the 630 software to be available.  (...
=.  Eventually there will be a BRL
=version of the 630 software, since the UCSD one is aimed at the native
=Berkeley environment, whereas I do software development in the System V
=environment, which I much prefer.)

This is really funny, no?  BRL wrote their own DMD package because it
wouldn't run in the BSD world.  Now they're glad because there will be
a BSD distirbution for the 630, but BRL will be writing their own because
they prefer SystemV.

Can you "NIH"?  :-)
-- 
For comp.sources.unix stuff, mail to sources@uunet.uu.net.

gwyn@brl-smoke.ARPA (Doug Gwyn ) (02/12/88)

In article <393@fig.bbn.com> rsalz@bbn.com (Rich Salz) writes:
>This is really funny, no?  BRL wrote their own DMD package because it
>wouldn't run in the BSD world.  Now they're glad because there will be
>a BSD distirbution for the 630, but BRL will be writing their own because
>they prefer SystemV.

It would be nice if you would understand the situation before
making (inane) comments.

The DMD host software licensed by AT&T around 1984 required the
addition of an "xt" pseudo-device driver to one's UNIX kernel.
Unfortunately, as you should know, the internal details for how
this is done vary radically between UNIX System V (the system
AT&T provided a driver for) and 4BSD.  This necessitated the
development of an alternative approach to providing the host
process multiplexer/packet protocol manager.  The only portion
of the AT&T DMD software that was "written" as opposed to
"ported" was this multiplexer process.  The result is usable
from either the native BSD environment or the System V
(emulated) environment, but since I do all software development
in a System V environment (even on 4BSD kernels), the BRL DMD
programming support was set up for the System V environment.

In the case of the "Teletype 4.2BSD tape" that eventually
became available for the DMD, and for the similar 630 host
software package for 4.3BSD that is being made available,
they chose to tailor the programming support for use with
the native (4BSD) environment.  Since this does not meet our
local needs, it obviously will have to be redone.

In any case, unless vismon, sam, etc. come with the AT&T
630 tape for 4BSD, we would have to provide them anyway.

By the way, not all of BRL "prefers System V", just a subset
of us, and only in certain ways (for example, it provides a
much more useful C library).  Generally the local technical
"gurus" seem to prefer the 4BSD environment, and those
producing production applications tend toward the System V
one, but the choice is a complex matter (which may become
unnecessary if the Sun/AT&T deal works out well).

ekrell@hector.UUCP (Eduardo Krell) (02/12/88)

In article <7248@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:

>That sounds much better, but is that software the same as the general public
>gets (say, with their 3B2+630), or is it more of the nifty Bell Labs internal
>stuff that nobody else can get hold of?

I'm using the standard System V layers. The kernel on the 3B2 is hacked,
but I didn't touch anything that has to do with layers.

>Is the System V layers multiplexing converted to STREAMS yet?  Does it work
>as well as on Ninth Edition UNIX?

I wish... it still uses the XT device driver.
    
    Eduardo Krell                   AT&T Bell Laboratories, Murray Hill, NJ

    UUCP: {ihnp4,ucbvax}!ulysses!ekrell		ARPA: ekrell%ulysses@att.arpa

carroll@snail.CS.UIUC.EDU (02/12/88)

/* Written  7:40 am  Feb 11, 1988 by ekrell@hector.UUCP in snail:comp.unix.questions */
/* ---------- "Re: layers vs SunView (was: Will X" ---------- */
In article <7239@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:

>I hope their 630 software support is better than that!

I am on a 630 right now. Host #1 is a 4.3BSD Vax; host #2 is a SVR3 3B2
(both running layers). I can telnet from a layer window on either host to
any other machine and it works just fine. Is this a good enough proof??
    
    Eduardo Krell                   AT&T Bell Laboratories, Murray Hill, NJ

    UUCP: {ihnp4,ucbvax}!ulysses!ekrell		ARPA: ekrell%ulysses@att.arpa
/* End of text from snail:comp.unix.questions */

But is there any hope for the 5620's ?

muller@sdcc7.ucsd.EDU (Keith Muller) (02/15/88)

I have yet to find a utility that should have run in a 630 window and
did not (on the 4.3 BSD version that is).  With the under $1500 (i think)
university price, the 630's are in great demand around here.

	Keith Muller
	University of California, San Diego

muller@sdcc7.ucsd.EDU (Keith Muller) (02/15/88)

the software that ATT sends out for 630's running on 4.3 based machines was
designed to run on generic 4.3 machines without kernel mods. So far it
seems to run with only a recompile on systems with 4.3 tty_pty.c. It is
not a "version" of the sytem V source, but supports the same set of
utilities with as few changes as possible. Only programs that were on
the system V distribution are on the tape (except for a 4.3 version
of the libwindows software: layers, libwindows.a ....). The quality of
software in the 630 release is much higher than the old 5620 DMD software
was. 

	Keith Muller
	University of California, San Diego