home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / acorn / 8317 < prev    next >
Encoding:
Internet Message Format  |  1992-08-23  |  4.4 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!darwin.sura.net!wupost!waikato.ac.nz!bwc
  2. From: bwc@waikato.ac.nz (Ug!)
  3. Newsgroups: comp.sys.acorn
  4. Subject: <None>
  5. Message-ID: <1992Aug24.132407.10318@waikato.ac.nz>
  6. Date: 24 Aug 92 13:24:07 +1200
  7. References: <9208210141.AA26129@ucbvax.Berkeley.EDU>
  8. Organization: Vooniersity fo Kaiwato
  9. Lines: 93
  10.  
  11. Malcolm Lithgow writes:
  12. > ...  To solve this, the development environment(s) for an OS should include
  13. > libraries of common data structures (standard arrays, matrices,
  14. > associative arrays, tagged tables, lists, stacks, text buffers, draw
  15. > buffers, frame buffers, etc.) and these libraries should include
  16. > optimized VM code, which can make use of the knowledge of the behaviour
  17. > of the data. Also, the compiled code itself should also have its own VM
  18. > manager, which can make use of information generated at, or after,
  19. > compile time.
  20.  
  21. Yeah yeah yeah!  So when are you going to write it?
  22.  
  23. > Problems you may raise:
  24. > 
  25. > This makes the libraries non-portable. Big deal! Look at libc for UNIX,
  26. > it is very non-portable already. For a quick port, you could base all
  27. > your library code on the array library, and use it's simple (UNIX-style)
  28. > VM. For a better port, you get better results.
  29.  
  30. Virtual memory should always be trageted to a particular machine/OS com-
  31. bination, otherwise performance is god-awful!
  32.  
  33. > The several different VM managers take up valuable memory. True, they
  34. > each consume memory, but there is no need for them to be very large, and
  35. > they should be able to share a lot of code, if written properly. And they
  36. > should be shared libraries. I think the trade-off would be worth it.
  37.  
  38. I think with shared libraries, it wouldn't be a problem at all.  (lets face
  39. it -- most of the Archimedes OS simply amounts to shared libraries...)
  40.  
  41. >>4. Unix become a industrial standart for higher range computers.
  42. >>   Compared with UNIX is RISCOS very exotic ...
  43. > 
  44. > So what?
  45.  
  46. Actually, I would tend to disagree with the orginal statement.  I don't think
  47. RiscOS is very exotic at all -- in many respects, it's quite similar to OS/2.
  48.  
  49. If you want exotic, try PICK, or some of Xerox's stuff, or even the Plan 9
  50. that Malcolm mentioned earlier.
  51.  
  52. > Other than the fact that UNIX *has not* become a standard for any type of
  53. > computer (have you ever tried to port programs from one version of UNIX
  54. > to another, or examined the complexity added to free packages to make
  55. > them more portable?), what benefit does UNIX being a standard give you?
  56.  
  57. Hmm.  They're working on that (although whether or not they will succeed is
  58. yet another matter), especially with POSIX and System V.  Also Binary
  59. compilers is quite interesting...
  60.  
  61. > If you want to stick to *real* standards then we should all be using MVS,
  62. > or VMS for smaller systems (or DOS for unusable systems).
  63.  
  64. Please don't call VMS a real operating system.  It's as Kludgy as hell!
  65.  
  66. >>There are a lot of advantages to have UNIX on every platform (maybe this is 
  67. >>not true on the Commodore C64 ...)
  68. > 
  69. > Yeah? Name one.
  70.  
  71. POSIX compilance.  (of course, how much of an advantage this is I'm not sure)
  72. (This is a joke, by the way, in case you hadn't realised ;-}  )
  73.  
  74. > What the industry should be striving for (and, to my utter disgust,
  75. > isn't) is standard data formats between all applications across all
  76. > platforms. (Standard communication protocols are, thank goodness, being
  77. > addressed.)
  78.  
  79. How?  TCP/IP?  Doesn't go far enough.  ISO OSI?  Hah!  Still, I supose that
  80. they are being addressed, just not terribly effectively in my opinion.
  81.  
  82. I don't care abut standard data formats, as long as they can be translated
  83. transparently.  Of course, the best way to acheive this would be by standard
  84. data formats...
  85.  
  86. > UNIX is a nice software development environment. Nothing more. But even
  87. > at that I think RISC OS is better.
  88.  
  89. Hmm.  Really?  Two of the best development environments I've seen are OS/2 2,
  90. and NeXT Step.  RiscOS and Unix would be a close third (equal).  The only
  91. thing I really miss from Unix on the Archimedes is a *real* filing system.
  92. (although it would be nice to have some sort of standard on-line manual system
  93. for the Arc, also).
  94.  
  95. All in all, I tend to agree.  Unix is not necessarily the answer.  However, it
  96. would be nice to have some of the things like multi-threading (which aren't
  97. necessary Unix) and better filing systems.  OS/2 and NeXT are much better then
  98. Unix at this though.
  99.  
  100. The main problem though is that there is a big upsurgance in business for
  101. 'open systems', which are of course, Unix based.  Pity.
  102.  
  103.                                 Ug!
  104.