home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / unix / xenix / sco / 2904 < prev    next >
Encoding:
Text File  |  1992-09-12  |  6.4 KB  |  136 lines
  1. Newsgroups: comp.unix.xenix.sco
  2. Path: sparky!uunet!rde!ksmith!keith
  3. From: keith@ksmith.uucp (Keith Smith)
  4. Subject: Re: Xenix considered harmful (was Re: SCO support - a success story)
  5. Organization: Keith's Computer, Hope Mills, NC
  6. Date: Sat, 12 Sep 92 05:31:17 GMT
  7. Message-ID: <1992Sep12.053117.4299@ksmith.uucp>
  8. References: <9209061050.AA05570@dynamix.com> <Bu6Bpp.AG8@mudos.ann-arbor.mi.us>
  9. Lines: 125
  10.  
  11. In article <Bu6Bpp.AG8@mudos.ann-arbor.mi.us> mju@mudos.ann-arbor.mi.us (Marc Unangst) writes:
  12. >In article <9209061050.AA05570@dynamix.com> david@dynamix.com (David L Jarvis) writes:
  13. >>How about all those segmentation violations that arose from the 286 not
  14. >>having hardware memory protection?
  15. >
  16. >Well, we're picking nits here, but I can't resist.  During most of my
  17. >experience with Xenix/286, you'd get a machine lockup more frequently
  18. >than you'd get a segvio.  Segvios were more frequently caused by
  19. >a large-model program that tried to assume pointers and ints were the
  20. >same size.
  21.  
  22. Hmm,  During my experience with over 20 Xenix-286 sites running apps
  23. from Uniplex Office Automation, to Open Systems accounting to Point of
  24. Sale over the last 5 years I can't recall 1 system lock-up.  Of course
  25. they were all running "shrink wrap" applications on standard hardware.
  26.  
  27. >
  28. >>Why haven't you forced this client and others like them to switch to Unix?
  29. >>WOW!!!  Could it be that ... perhaps ... they don't NEED Unix???!!!  
  30. >>You said it yourself Marc, Xenix serves their needs just fine, and THATS
  31. >>what we've all been saying right along ...
  32. >
  33. >Well, we haven't switched them to Unix because they don't have the
  34. >money and because there was really no need.  However, they very
  35. >narrowly averted the need quite recently: Their 2400bps modem broke,
  36. >and they were thinking about getting a V.32 or V.32bis modem to
  37. >replace it.  Good thing they decided to go with another 2400bps modem,
  38. >because I doubt their 286/10 running Xenix/286 would have been able to
  39. >keep up with a V.32 or V.32bis modem.
  40.  
  41. Well, Jeezuz,  Throw in a 286/20 with the modem.  $100 tops.  Actually a
  42. 286/10 will run a V.32 modem fine at 9600 baud.  Of course my question
  43. is this:  If the 2400 baud modem was adequate why would they "need" a
  44. 9600 baud modem, and why would you assume you could not use one?  It
  45. runs 9600 baud terminals OK, why not a modem?  With an intelligent I/O
  46. card you could even push a DTE rate Higher than 9600.  NOTE:  This is
  47. *NO* different than SCO Unix 3.2  It can't push a modem on a dumb port
  48. with a '450 or lower chip reliably either.
  49.  
  50. Oh,  BTW,  9 of the 286's above were running USR Dual Standards and the
  51. 286's were 286/12's.  They were POS systems pushing a lot of transaction
  52. data to a home office at night via modem.
  53.  
  54. >
  55. >>So what I meant by mature and stable was that it's had more time to have
  56. >>all the major problems resolved, and to become more refined ...
  57. >
  58. >I'd hardly call Xenix "refined".  "Old", maybe, but old does not
  59. >mature make.
  60. >
  61.  
  62. No,  refined is a good word.  The bugs that weren't finally fixed are
  63. well known and documented.  Most all of the device drivers are stable,
  64. and haven't changed much recently.  Refined & mature IMPLY some age.
  65.  
  66. >>What would inittab provide that /etc/ttys doesn't?  Under *normal*
  67. >>circumstances, /etc/ttys w/ enable/disable does just fine.  
  68. >
  69. >Uh, there are lots of things you can do with inittab that you can't do
  70. >with /etc/ttys.  Like spawn something that's not called "/etc/getty".
  71. >There are other things I could go into, but they have more to do with
  72. >the SysV-style rc scripts vs. the V7-style rc scripts.
  73. >
  74.  
  75. I like inittab don't get me wrong.  Hacking around I have spawned things
  76. as you say on the home box.  I've just never really had the need to do
  77. any of that stuff at a clients office.  Mostly use cron & rc for the
  78. rest of it.  No real use for all the run-level stuff either.
  79.  
  80. >>Oh please ... the configure script makes this simple and painless ...
  81. >>who cares what "style" configuration the system uses as long as it 
  82. >>works ... I've never once had a problem configuring Xenix ...
  83. >
  84. >You obviously haven't ever tried to add more than one or two
  85. >third-party drivers to a Xenix system.  I have.  And then I had to
  86. >clean up the link_xenix script with an editor because the drivers had
  87. >each stomped on each other.
  88.  
  89. Hehehe,  These problems don't dissappear with AT&T's scheme under SVR3.2
  90. either.  Sorry,  Lot's of new drivers will conflict eventually requiring
  91. some hand patching.  And tell me something.  Which takes longer? 
  92. Hacking a line in /usr/sys/conf/link_xenix or modifying an entry for a
  93. driver in:
  94.  
  95. /etc/conf/sdevice.d
  96. /etc/conf/init.d
  97. /etc/conf/cf.d/mdevice
  98. /etc/conf/pack.d/device_name/*
  99.  
  100. I rest my case you can get typists cramp on this one.  OH!  and I forgot
  101. one of my 3.2 favorites:  inittab.  To modify a line setting for getty
  102. you have to edit TWO files /etc/inittab AND , depending on the entry,
  103. /etc/conf/cf.d/init.base *OR* /etc/conf/init.d/{something}.  Elsewise
  104. the nasties will grab you next time you rebuild.
  105.  
  106. [mail ...]
  107.  
  108. Yea,  No domains in Xenix.  No need for it on a point of sale system
  109. either.  For interoffice stuff the supplied works fine.  So,  If you are
  110. a net.wizard and want to talk to the world at random you have to go to
  111. smail or something.  On the other hand for fixed stuff you can alias
  112. with ELM or whatnot and avoid all of it.
  113.  
  114. >>So Unix is better than Xenix because you don't want to learn Xenix?
  115. >>Sure it's different, but are all Unixes out there the same?  Hell no.
  116. >
  117. >Yes, Unix is better than Xenix because it's the same as other
  118. >Unix-based products.  Again, we're coming back the standards argument.
  119. >The primary reason a lot of our customers use Unix on PCs is because
  120. >it interoperates well with their other Unix machines.  Xenix *may* be
  121. >appropriate if interoperability is not and never will be a concern,
  122. >but I don't believe *anyone* can say that in this day and age.
  123.  
  124. Sure we can.  "Open Systems" is a crock of chet.  My clients want to get
  125. the job done as cheaply as possible.  SCO 3.2.4 damn sure ain't cheap,
  126. and neither is my time to install it.
  127.  
  128. You want "standards" Buy DOS & throw it on a PC.  It is a de facto
  129. standard in this industry.  There are more than 10 times as many DOS
  130. PC's out there than anything else, and a wider gap for software apps.  I
  131. just can't stand it, and it is lousy for sharing data, and applications.
  132. -- 
  133. Keith Smith          uunet!ksmith!keith            5719 Archer Rd.
  134. Digital Designs      BBS 1-919-423-4216            Hope Mills, NC 28348-2201
  135. Somewhere in the Styx of North Carolina ...
  136.