Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!simtel!news.kei.com!nntp.et.byu.edu!news.byu.edu!hamblin.math.byu.edu!park.uvsc.edu!usenet
From: Terry Lambert <terry@cs.weber.edu>
Newsgroups: comp.unix.bsd.freebsd.misc,comp.sys.intel
Subject: Re: I have one thing to say about Windows '95 & FreeBSD
Date: 16 Sep 1995 05:58:52 GMT
Organization: Utah Valley State College, Orem, Utah
Lines: 141
Message-ID: <43dp2s$674@park.uvsc.edu>
References: <41gceu$i14@mirv.unsw.edu.au> <41m3at$vn7@lucy.swin.edu.au> <MICHAELV.95Sep7213538@MindBender.HeadCandy.com> <430279$218@park.uvsc.edu> <jason-1309950002380001@xhead3.indy.net>
NNTP-Posting-Host: hecate.artisoft.com
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:5972 comp.sys.intel:48116
jason@indy.net (Jason Miller) wrote:
]
] In article <430279$218@park.uvsc.edu>, Terry Lambert <terry@cs.weber.edu> wrote:
]
] >Still, it's possible to work around all of these problems and turn
] >Windows95 into a good server platform: with minor exceptions, as
] >good as NT; better, if we compare on the basis of price/performance.
]
] Networking in Win95 isn't designed for a server-side OS.
I think you haven't looked at the internals very hard. As long
as the requests can be inteleaved, networking isn't a bottleneck.
] Many services standard on both NT Workstation and Server must
] be patched into Win95.
For instance? What platform features that are required for a
server are missing from Windows 95, in your opinion?
] Also, NTFS provides file-level security a-la-UNIX, and is
] wicked-fast, while Win95 provides...FAT with long filenames.
This is a red herring. 'Network Computing' reports FreeBSD's NFS
server speed as being nearly 10 time that of the best 3rd party
NFS server for NT. Read the article. I'm not making it up.
The VFAT on Win95 can be replaced with another file system. The
OS architecture isn't the limiting factor.
] NT is portable to non-Intel platforms [MIPS, Alpha, PowerPC],
] which outperform a Pentium for servers,
But for which there is unfortunately precious little to serve
off of them (more's the pity) because little is being ported
to non-Intel NT.
I think you are getting confused by Novell's invention, the so
called "application server" (which they invented when they failed
to correctly market UnixWare as a desktop). I'm talking about
file services.
] and supports symmetric multiprocessing, both great for a future
] upgrade path.
SMP is a dodge for people who want hardware a little faster than
the hardware that is actually available to them. I should know,
I bought a dual P90 system to work on SMP BSD.
SMP is a high end niche market. The major limiting fact for most
servers, and certainly for NetWare servers (as one example) is I/O.
Pushing bits down an etherhose is (not suprisingly) I/O bound, not
CPU bound.
] NT's security model is designed with networking at the LAN, WAN
] and internetworking server level, while 95's is designed with the
] desktop client in mind.
The secruity model of the platform is largely irrelevent, other than
giving you the ability to more easily implement file attribution as
part of the server software's security model.
This is really a non-issue. The NT security model is tied heavily
to the concept of client/server and connection based authentication,
whereas if one wanted to build an NFS server, one would have to
use a process based authentication scheme, and on top of that, use
a proxy facility to send preauthenticated credentials over the
wire to the NFS server (that's how NFS works).
Faced with pounding such a model into NT, which has preconcieved
ideas about security that don't mesh well with non-client/server
based topologies, vs. pounding it into Win95, which lacks these
preconceptions, I know which I would choose.
] If your server runs any 16-bit services, NT can run them in
] separate memory spaces, while Win95 lops 'em all into one.
Servers don't run apps. They run server software.
] WinNT is POSIX compliant, so you can easily port many UNIX-based
] server apps, while Win95 has...MSN?
This is wrong. They have not passed NIST/PCTS, therefore they are
not POSIX conformant. Neither is Linux or BSD, for that matter.
But the porting issues for POSIX software to NT are much steeper
than Microsoft (or you) would have us believe.
] Finally, in my experience, the TCP/IP code in NT (3.5 and 3.51)
] is both more stable and more complete than the Dial-up Networking
] in Win95.
You don't dial into file servers. You dial into Livingston
Portmasters or other SLIP/PPP terminal servers and *attach* to
a server. When you dial in at all... 28.8 is insufficient for
running WordPerfect from the corporate server.
] Sure, you don't get a Network Neighborhood, but you get support
] for just about every important RFC out-of-the-box, and a
] workstation-class impementation of the TCP/IP protocols...with
] Win95, you get, well, a Start button.
God, I love it when people complain about user interface features
on what is, in a server usage, effectively a console interface
that you are going to rip the head off of in any case and jam into
a closet somewhere.
And NT does not support RFC 1323 or RFC 1644 (I consider transaction
TCP to be rather important).
] So toss Win95 into the recycling bin and get a real server OS,
] be it WinNT [Workstation or Server] or FreeBSD or even Linux.
How about if I recycle it myself and load server software onto it?
] BTW, FWIW, WinNT 3.51 can run most "Designed for Windows 95"
] apps, and you can even FTP a prerelease Win95-like shell from
] ftp.microsoft.com.
The "Designed for Windows 95" is noticibly lacking from most of
the software at my local Software Etc., though most of the software
*is* "Win 3.1 Compatible", so I guess vendors aren't placing
much importance on obtaining that logo by following the rules and
certifying on NT. Despite Bill's wishes, NT will not quickly
supplant Win95.
Further, your statement, even if it were more than half-true, would
only apply to Intel versions of NT.
That the Win95 shell can be ported to NT is irrelevant. I can put
something similar on a UNIX box in a matter of hours simply by
tweaking FVWM.
Regards,
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.