home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / next / advocacy / 3442 < prev    next >
Encoding:
Internet Message Format  |  1992-12-23  |  3.0 KB
  1. Path: sparky!uunet!overload!dillon
  2. From: dillon@overload.Berkeley.CA.US (Matthew Dillon)
  3. Newsgroups: comp.sys.next.advocacy
  4. Subject: Re:   100 Mips Intel NeXT (moved from comp.sys.next.misc)
  5. Distribution: world
  6. Message-ID: <dillon.0t3m@overload.Berkeley.CA.US>
  7. References:  <dillon.0sv3@overload.Berkeley.CA.US> <BzD5I6.GG@ux1.cso.uiuc.edu> <dillon.0t0a@overload.Berkeley.CA.US> <1992Dec20.051209.9684@cubetech.com>
  8. Date: 22 Dec 92 19:43:21 PST
  9. Organization: Not an Organization
  10. Lines: 53
  11.  
  12. In article <1992Dec20.051209.9684@cubetech.com> andrew@cubetech.com (Andrew Loewenstern) writes:
  13. >In article <dillon.0t0a@overload.Berkeley.CA.US> dillon@overload.Berkeley.CA.US (Matthew Dillon) writes:
  14. >>    If NeXT can get a handle on its misuse of memory, that is.. they do not
  15. >>    seem to realize the huge amount of bad press they are going to get if
  16. >>    NS486 turns out to be slower then Windows in effective response, and
  17. >>    Windows runs quite well with 8MB of ram.
  18. >
  19. >Windoze doesn't use windows with backingstore
  20. >Windoze doesn't run DPS
  21. >Windoze doesn't do a lot of things NeXTSTEP does behind the scenes,
  22. >that's why it uses less memory.  NeXT won't get a huge amount of bad
  23. >press.  It's not likely that they will get a huge amount of _any_
  24. >press.
  25.  
  26.     You are saying this as if these things are *supposed* to take up a lot
  27.     of memory.    I see no reason why anything other then the backing store
  28.     need take so much extra memory, certainly NOT display postscript. As
  29.     far as backing store goes, it is definitely overused on the NeXT and
  30.     for much more then simple on-screen window backings.
  31.  
  32. >NeXTSTEP needs about 24 megs of RAM to run really well.  Would you say
  33. >that NeXTSTEP does three times the stuff in the background?  Is it 3
  34. >times better?    Is RAM cheap?    yes, yes, yes.
  35.  
  36.     That's nice, so why don't you try to explain this invisible stuff to
  37.     joe user.  I'm not arguing with the technical facts, but with the
  38.     assumption that they can be translated into ooos and ahhhs to
  39.     non-technical people.  As a developer I rather like the NeXT.  As a
  40.     user I wonder why, for example, you can't preview a print command from
  41.     the Previewer (something I often want to do) and why the previewer
  42.     screws up on perfectly valid third party postscript files (e.g. doesn't
  43.     allow you to modify the page layout or zoom).  The NeXT is great in
  44.     that it implements postscript, but there are as many special cases with
  45.     the NeXT and it's postscript as there are with every other system I've
  46.     seen.  Not so fun, sometimes.
  47.  
  48.                     -Matt
  49.  
  50. >andrew
  51. >(back from HoHoCon!)
  52. >--
  53. >andrew@cubetech.com      |  "C++'s runtime sucks shit!  Virtual functions
  54. >Andrew Loewenstern      |   can go straight to hell!"  - Ron Pomeroy
  55. >Cube Technologies, Inc.  |              ForYourEyesOnly public key:
  56. >0000000701B61D1ADF0DFC9C16185CEA055200000007EB4A9FEB1922065D471A89E905B5
  57.  
  58. --
  59.  
  60.     Matthew Dillon        dillon@Overload.Berkeley.CA.US
  61.     1005 Apollo Way        uunet.uu.net!overload!dillon
  62.     Incline Village, NV. 89451    ham: KC6LVW (no mail drop)
  63.     USA             Sandel-Avery Engineering (702)831-8000
  64.  
  65.