*BSD News Article 65183


Return to BSD News archive

Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!hobyah.cc.uq.oz.au!bunyip.cc.uq.oz.au!munnari.OZ.AU!news.ecn.uoknor.edu!qns3.qns.com!imci4!newsfeed.internetmci.com!inet-nntp-gw-1.us.oracle.com!news.caldera.com!news.cc.utah.edu!park.uvsc.edu!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.unix.admin,comp.unix.bsd.386bsd.misc,comp.unix.bsd.misc,comp.unix.bsd.netbsd.misc,comp.unix.misc,comp.unix.osf.misc,comp.unix.pc-clone.32bit,comp.unix.sco.misc,comp.unix.solaris,comp.unix.sys5.misc,comp.unix.ultrix,comp.unix.unixware.misc,comp.unix.xenix.misc
Subject: Re: Trying to research UNIX OS
Date: 6 Apr 1996 02:38:45 GMT
Organization: Utah Valley State College, Orem, Utah
Lines: 86
Distribution: inet
Message-ID: <4k4lfl$1ar@park.uvsc.edu>
References: <Dp1KLC.398@nvc.cc.ca.us> <4jos5c$7in@gjallar.daimi.aau.dk> <4jsi80$rqr@wolfe.wimsey.com> <Dp9ouy.7qK@telly.telly.org> <3163C803.199B@cet.co.jp>
NNTP-Posting-Host: hecate.artisoft.com
Xref: euryale.cc.adfa.oz.au comp.unix.admin:40266 comp.unix.bsd.386bsd.misc:475 comp.unix.bsd.misc:627 comp.unix.bsd.netbsd.misc:2788 comp.unix.misc:21806 comp.unix.osf.misc:2996 comp.unix.pc-clone.32bit:9116 comp.unix.sco.misc:15838 comp.unix.solaris:65117 comp.unix.sys5.misc:971 comp.unix.ultrix:27203 comp.unix.unixware.misc:11922 comp.unix.xenix.misc:1089

Michael Hancock <michaelh@cet.co.jp> wrote:

[ ... ]

] UnixWare seems to be a better multi-user host and I have more trust in 
] its filesystem.

One comment: I have hacked file system code in both the UnixWare
and FreeBSD kernels.  From my personal experience, it is very
hard to get any significant fix into the UnixWare source tree
because of the way the tree is maintained (it is in pieces and
you can not do any significant cross-architecture work because
a checked out source tree is, by definition, architecture
specific).

I know of at least two *serious* problems for which I provided
fixes which were never integrated because I didn't feel that
it was encumbant on me personally to have to fight a management
structure designed to maintain the status quo.  Call me silly,
but I feel the job title "software engineer" indicates that
the problems I have to deal with should be software problems.

This may have changed now that the majority of that management
has been sold to an unwitting SCO, and Novell is back to its
old self.  I hope so; I think Novell stock is worth buying at
the current price.


For a research OS, one can't beat an OS with source available
and a large academic (as opposed to ordinary user) community.

Most Usenix papers have been written, and are being written,
on BSD-derived code.

[ --- new subject -- ]

] Has anyone done a network performance comparison between Solaris
] and UnixWare?  Sun has been saying the "Network is the computer"
] for what seems like more than decade.  You get the feeling that
] SCO and Novell USG were behind the times when it comes to the
] quality and features of their TCP/IP implementation.  Different
] priorities I guess.  It does seem that they are stepping up
] their efforts here, but I wonder what kind of steps they are
] taking.  Do they pay Legent/Lachman enough?  Does Legent/Lachman
] still have the 'minds' who are up to the task?

The University of Guelph are *the* people who know NFS (SunOS
has been the standard, but since Sun never publishes enough
information to implement locking, locking is always licensed
from Sun -- including UnixWare's).  This is the BSD code.

The people who know packet filtering code are at Stanford and
CMU.  This is the BSD code.

PPP compression is derived from the BSD compress (Woods, Thomas,
and Orost).  Obviously, this is BSD code.

The PPP code is from CMU (again the same code in BSD).

The TCP/IP implementation is by "UCB and contribtors"; that's
Van Jacobson, Richard Stevens, etc..  As far as I know, the
BSD code is the only code that correctly implements RFC 1323
and RFC 1644, and which uses "Transaction TCP" by default.

For a research OS, where you are interested in networking,
Solaris and UnixWAre are not options.


As to "Solaris vs. UnixWare", UnixWare has a high packet
latency compared to NetWare.  But so does Solaris.  And this
will not impact a sliding window protocol, like TCP/IP, one
way or the other, since one latency is averaged over the entire
packet run.  This is only a problem for request/response
protocol architectures, like NetWare itself.  And the UnixWare
overhead is not significant enough to prevent UnixWare from
outperforming NetWare (NetWare for UNIX 4.x vs. NetWare 4.x)
on exactly the same hardware.  And Solaris isn't going to be
able to touch that, mostly because they are running third
party "NetWare compatible" code where request/response matters.


                                        Terry Lambert
                                        terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.