bsteve@gorgo.UUCP (11/08/86)
In-Response-To: rick@seismo.UUCP net.lan: > Having to worry about the file system being local or remote defeats one > of the major purposes of remote file systems. yup. > It still astonishes me that they continue to ignore the incredible majority > of their customers who just want to connect Unix systems to Unix systems. We > committed to Unix a long time ago. We have no need for MS-DOS nor > CMS nor GCOS NFS. I suspect the overwhelming majority of their > customers don't either. Of course it doesn't sound quite as nice as > far as marketing bullshit goes, it would just be something that people > could use. This is not an accurate evaluation. There are several orders of magnitude more MS-DOS PC's out there than there are UNIX boxes. Sun has exactly the right idea. > Why is it so difficult to have a set of OPTIONAL unix extensions that > MS-DOS (or whatever) could return "failed-unimplemented" on? Then, > some of us could get their work done with out "surprises" and > the posturing visionaries could continue their babbling. (Lighting torch) Arf. The fundamental problem that we face in dealing with remote "stuff" that is architecturally very different is that we haven't really arrived at a common ground for describing remote operations. I agree that remote operations SHOULD appear identical to local operations to the programmer, but in reality, we would probably have to give up some of the flexibility that we want and SHOULD have on the UNIX side. Consequently, we deal with these nasty, kludgy things in order to retain some flexibility while we try to integrate truly SCUMBAG things like MS-DOS into our environment. You and I can yell all day that MS-DOS sucks and that we don't want or need it, and will change nothing. (End flame) Steve Blasingame (Oklahoma City) ihnp4!occrsh!gorgo!bsteve bsteve@eris.berkeley.edu
david@comp.lancs.ac.uk (David T. Coffield) (11/10/86)
In article <3727@mit-eddie.MIT.EDU> jbs@eddie.MIT.EDU (Jeff Siegal) writes: >In article <8970@sun.uucp> guy@sun.com (Guy Harris) writes: >>(BTW, it's not "SUN", it's "Sun Microsystems", or just "Sun". SUN is an >>acronym for Stanford University Network; "Sun" is part of the name of a >>company and is not an acronym.) > >You want to pick nits? Fine. It's "Sun Microsystems," _NOT_ just >"Sun." "Sun" is a chemical manufacturing subsidiary of Olin. > >Jeff Siegal Oh, for Pete's sake. "Sun" is a spherical object full of hot air residing in deep space - rather like a lot of folk that post articles. -- "You don't work here, I don't work here - screw it" uucp: ...!mcvax!ukc!dcl-cs!david post: Department of Computing arpa: david%lancs.comp@ucl.cs University of Lancaster, LA1 4YR, UK janet: david@uk.ac.lancs.comp phone: +44 524 65201 x 4599
rick@seismo.CSS.GOV (Rick Adams) (11/10/86)
In article <12400001@gorgo.UUCP>, bsteve@gorgo.UUCP writes: > > This is not an accurate evaluation. There are several orders of magnitude > more MS-DOS PC's out there than there are UNIX boxes. Sun has exactly the > right idea. The point is that Sun is a company selling Unix boxes. I am a Sun customer because they sell Unix Boxes. I could not care less how many MS-DOS PC's exist. I can't conceive of why I would want one. Sun doesn't sell them. (Sun IPC doesn't count, since it doesn't run standalone.) They should support their major product. They don't (completely). Hell, their great MS-DOS NFS implementation doesn't even run between two MS-DOS boxes. The server MUST be a Sun. So they don't even have an MS-DOS server to worry about. The reason I get so pissed off about this is not that Sun refuses to support it. (That merely annoys me.) It is that they refuse to ADMIT that they don't support Unix Semantics. This are quotes from their latest glossy sales brochure: NFS gives you transparent file access to remote file systems, regardless of operating system. ... NFS greatly enhances the usefulness of a local area network by allowing users to transparently access files anywhere on the LAN. Users do not need to learn any new commands, and no user training is required. The remote system actually appears to be local. Now most rational people would interpret words like "transparent" and phrases like "actually appears to be local" to mean what runs correctly on a local file system, runs correctly on the remote system. Now either their implementation is flawed or their advertising is "misleading". ---rick
ron@brl-sem.ARPA (Ron Natalie <ron>) (11/12/86)
In article <596@gvax.cs.cornell.edu>, jqj@gvax.cs.cornell.edu (J Q Johnson) writes: > What distributed file system features do sophisticated users see as > important -- what features would you like to see added to NFS or to NFS > implementations? > What this user wants to see is the ability of NFS to function in a secure fashion accross communities of interest where you can't maintain a common user->uid mapping. -Ron
ralphw@ius2.cs.cmu.edu (Ralph Hyre) (11/14/86)
In article <465@brl-sem.ARPA> ron@brl-sem.ARPA (Ron Natalie <ron>) writes: >In article <596@gvax.cs.cornell.edu>, jqj@gvax.cs.cornell.edu (J Q Johnson) writes: >> What distributed file system features do sophisticated users see as >> important -- what features would you like to see added to NFS or to NFS >> implementations? >> >What this user wants to see is the ability of NFS to function in >a secure fashion accross communities of interest where you can't >maintain a common user->uid mapping. > >-Ron Even the ability to export a file system read-only to certain 'untrusted' groups of machines would be welcome. (ie untrusted netgroups with machines where you can't control physical access to the machine.) Maybe release 4.0? -- - Ralph W. Hyre, Jr. Internet: ralphw@ius2.cs.cmu.edu Phone: (412) 268-2847 [CMU-BUGS], 268-3275 Amateur Radio: KA3PLY (c/o W3VC, CMU Radio Club)
capshaw@milano.UUCP (11/14/86)
The Pyramid implementation of NFS allows one to specify that a filesystem be exported read-only. We find it a natural and handy feature; for example, we have /usr/spool/news mounted read-only to a collection of Suns. -- Dave Capshaw
tim@hoptoad.uucp (Tim Maroney) (11/16/86)
I feel a bit strange defending a competitor, but what the hell. I assure
Rick that there are a lot of mixed-OS networks out there, probably more than
UNIX-only nets. This means Sun would have to be insane not to try to reach
these customers. I'm sorry that this doesn't satisfy the needs of one
particular laboratory, but then that lab is free to develop its own
distributed file service products if it wishes. (In fact, if all you have
is UNIX, you could probably do a perfectly good disk server in a short
time.) Supporting PCs is not some useless crap that just sounds good in ads,
it is a commercial necessity to reflect true market conditions.
As for the alleged non-transparency in NFS because every oddball feature of
UNIX is not supported, again I am on Sun's side. It is certainly
theoreticaly possible to put the weirdnesses of each operating system into
the file access protocol as optional features, but there are two major
reasons why this can't be done. First, there's a little thing known as the
N-squared problem. Second, this really does not preserve absolute
transparency. After all, UNIX software could be running using files on some
other operating system; if it expects strict UNIX semantics there, then it
will be disappointed. This gains little if anything.
I think portability constraints alone should prevent people from using local
OS dependencies if there is a portable way to do things. Why make a temp
file by deleting an open file when you can create a uniquely named temp file
in an almost completely OS-independent way? Similar considerations apply to
all other operating systems. You shouldn't ever use the Macintosh ability
to change file dates, for instance. At some point, one of two things could
happen. You could decide to port the software to UNIX, which disallows date
changes except by the user from Krypton, or you could be running from a UNIX
file server.
To sum up, there is no absolute transparency in inter-operating-system file
service networks. It is not possible because of OS differences. This does
not mean that Sun is lying when they call NFS transparent, or that we at
Centram are lying when we call TOPS transparent. My living room window has
a few small opaque spots on it, but that doesn't block my view of the bay...
--
Tim Maroney, Electronic Village Idiot
{ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp)
hoptoad!tim@lll-crg (arpa)kapil@dartvax.UUCP (Kapil Khetan) (11/16/86)
Steve Blasingame writes: >these nasty, kludgy things in order to retain some flexibility while we try >to integrate truly SCUMBAG things like MS-DOS into our environment. You and >I can yell all day that MS-DOS sucks and that we don't want or need it, and >will change nothing. > What is so 'scumbaggish' about MS-DOS? When I used UNIX at school, I loved it. The tools just blew my mind. Nice games too. Now at work I use MS-DOS and think it is just fine. Naturally it doesn't have the tools that UNIX does, but then it takes up so little memory. If UNIX wasn't such a memory hog it would have been used a lot more extensively. So tell me, what are you so disappointed with MS-DOS about? Kapil USPS: Chemical Bank, 55 Water St. #1122, New York, NY 10041 (office) 124 Lincoln Pl., Brooklyn, NY 11217 (res.) VOICE: 212.820.4294 (office) or 718.789.1583 (residence) DATA: kapil@dartvax.UUCP or kapil@dartmouth.edu "The market will fluctuate." -- JP Morgan Disclaimer--The mangement at Chemical hasn't heard of USENET and is certainly not responsible for what I key.
bob@osu-eddie.UUCP (Bob Sutterfield) (11/18/86)
Please keep MS-DOS vs UNIX discussion in the comp.os.* newsgroups,
except as it directly relates to local area networks. Thanks.
--
Bob Sutterfield, Computer and Information Science Department
The Ohio State University; 2036 Neil Ave. Columbus OH USA 43210-1277
bob@ohio-state.{arpa,csnet} or ...!cb{osgd,att}!osu-eddie!bob
(614) 292 - 0915berger@datacube.UUCP (11/19/86)
Try running large programs, accessing framestores, multitasking,
switching between MS-DOS and Unix, trying to interupt a job if its not
doing any I/O, doing things with interupts, any form of concurrency, not
having the programmer act like an MMU, easily have objects that are larger
than 64k, pass more than 5 command line options or file names, have large
environments, run NFS and another program..... The list goes on and on.
The IBM PC and in particular MS-DOS was a giant step backwards for computers.
Sure everyone can have one, but everyone is forced to be stuck with the
limitations of early 70's technology (limited address space, single tasking).
I consider it to be a curse on the computer industry and the computer user
and ESPECIALLY the computer programmers.
Bob Berger
Datacube Inc. 4 Dearborn Rd. Peabody, Ma 01960 617-535-6644
ihnp4!datacube!berger
{seismo,cbosgd,cuae2,mit-eddie}!mirror!datacube!berger