home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / unix / pcclone / 32bit / 1354 < prev    next >
Encoding:
Internet Message Format  |  1993-01-27  |  3.9 KB

  1. Xref: sparky comp.unix.pc-clone.32bit:1354 biz.sco.general:5619 comp.unix.sys5.r3:427 comp.unix.sysv386:17920
  2. Newsgroups: comp.unix.pc-clone.32bit,biz.sco.general,comp.unix.sys5.r3,comp.unix.sysv386
  3. Path: sparky!uunet!hobbes!xenitec!news.byu.edu!gatech!swrinde!zaphod.mps.ohio-state.edu!cs.utexas.edu!wotan.compaq.com!moxie!lobster!nuchat!texhrc!texhrc!ak45ldp
  4. From: pyeatt@Texaco.com (Larry D. Pyeatt)
  5. Subject: Re: PC Unix/Xenix vendors
  6. Message-ID: <1993Jan26.153926.19840@texhrc.uucp>
  7. Sender: news@texhrc.uucp
  8. Nntp-Posting-Host: microvax
  9. Organization: Texaco
  10. References: <C188DI.EHE@ddsw1.mcs.com> <2B6010B6.14DF3@tct.com> <ADAMS.93Jan25230527@PDV2.pdv2.fmr.maschinenbau.th-darmstadt.de>
  11. Date: Tue, 26 Jan 1993 15:39:26 GMT
  12. Lines: 67
  13.  
  14. In article <ADAMS.93Jan25230527@PDV2.pdv2.fmr.maschinenbau.th-darmstadt.de>, adams@pdv2.fmr.maschinenbau.th-darmstadt.de (Adams) writes:
  15. |> To: 
  16. |> In article <2B640EE0.675B@tct.com> chip@tct.com (Chip Salzenberg) writes:
  17. |> 
  18. |> >   According to karl@ddsw1.mcs.com (Karl Denninger):
  19. |> >   >Certainly, [PC clones] have the installed base now.  But these
  20. |> >   >"installed" systems do not play well together, they're unstable (ask
  21. |> >   >any DOS user) and to get away from that is just too damn expensive.
  22. |> 
  23. |> As DEC was able to build a binary compiler VAX executables to alpha,
  24. |> same should be possible for a less complex architecture like 386.
  25.                                  ^^^^^^^^^^^^^^^^^^^^^^^^^  
  26.  Have you actually written assembly code for both the VAX and the
  27. 8088 family?  The 80486 is not a less complex architecture than the VAX.
  28. Less powerful? debatable.  Less complex? no.  The 80486 instruction set
  29. is ridiculous.
  30.  
  31. |> How about jsut to compile your 386-Windows-3.1 excutables into 
  32. |> R4000-IRIX-X-executables? Impossible? ...would not bet !
  33.  
  34. It is definitely possible.  But there are a lot of potential problems.
  35. You probably would end up with pretty inefficient code.  I guess that
  36. if you really worked at it, you could do some reasonable optimizations,
  37. but it wouldn't be easy.
  38.  
  39. |> 
  40. |> >   It's DOS and Windows that are unstable, not the hardware architecture.
  41. |> >   Contrast UNIX on a PC clone: it keeps going, and going, and going...
  42. |> 
  43. |> NO! 
  44.  
  45. Even if it were stable, the PC architecture is ugly.  It makes optimization
  46. expensive, and executables larger.  It is an 8 bit machine that has been
  47. expanded past reason.  But that's what the market demands.  Intel even
  48. advertizes its new chips by the number of transistors they contain.  News
  49. flash: other processors are faster with half as many transistors.  Intel
  50. is actually advertizing the fact that their processors have such a poor
  51. architecture that it is ineffecient to implement.  Could you imagine if
  52. an automobile manufacturer ran an ad campaign proclaiming that their
  53. engines have 4000 lbs of steel in them and that cars built around this
  54. engine could expect to go as fast as a Volkswagen Beetle and get about
  55. 2 miles per gallon of gas?  It works for Intel because everyone has
  56. tires and seatcovers to fit, and they know how to drive it.
  57.  
  58. Okay, maybe I'm exaggerating a bit.
  59.  
  60. (* stuff deleted *)
  61.  
  62. |> 
  63. |> >   "Goes away from DOS" ... to systems that support DOS applications,
  64. |> >   like OS/2 and Windows and modern UNIX VP/ix or DOS Merge or SoftPC.
  65. |> >   Those real people-use-'em DOS apps won't disappear for a decade or so.
  66. |> 
  67. |> Why? They are now substituted with programs having similiar user interface
  68. |> (lock and feel), will be able to handle the old data, but 
  69. |> nothing more. 
  70. |> 
  71. |> Why should any system addministrator like the hassle with
  72. |> extended and expanded (or was it just expected) memory,
  73. |> lack of user and process isolation(viri ...). Tell me why?
  74.  
  75. They just don't know anything better, and are unwilling to learn?
  76.  
  77. Larry D. Pyeatt                 The views expressed here are not
  78. Internet : pyeatt@texaco.com    those of my employer or of anyone
  79. Voice    : (713) 975-4056       that I know of with the possible
  80.                                 exception of myself.
  81.