home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / sun / misc / 6061 < prev    next >
Encoding:
Text File  |  1992-12-30  |  3.2 KB  |  63 lines

  1. Newsgroups: comp.sys.sun.misc
  2. Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!usenet.coe.montana.edu!news.u.washington.edu!sumax.seattleu.edu!thebes!ole!ssc!fyl
  3. From: fyl@ssc.com (Phil Hughes)
  4. Subject: Re: Is Sun losing touch with its customers?
  5. Organization: SSC, Inc.,  Seattle, WA
  6. Date: Tue, 29 Dec 1992 19:45:25 GMT
  7. Message-ID: <1992Dec29.194525.5777@ssc.com>
  8. X-Newsreader: TIN [version 1.1 PL6]
  9. References: <1992Dec28.184729.17486@eskimo.com>
  10. Lines: 51
  11.  
  12. I have some generic comments on the SunOS vs. UNIX V game.  For those who
  13. don't know SSC, we publish pocket-sized references for computer systems
  14. with our major emphasis on UNIX systems.  I am currently in the process of
  15. completing a new Command Summary that will cover System V, Release 4.2 and
  16. Solaris 2.1.
  17.  
  18. When we started this project we thought we were just doing a quick update
  19. to our SVR4 summary.  As we got further into the project we realized that:
  20.   1. SVR4.2 is quite different from SVR4
  21.   2. Solaris 2.1 is very close to SVR4.2
  22. Thus, the project evolved into this new (unnamed) product.
  23.  
  24. That said and having done consulting and teaching on UNIX systems from
  25. Version 7 on as well as XENIX I see what is happening with the
  26. SVR4.2/Solaris combination as a real step in the right direction.
  27. Yes, we can all find fault with a vendor changing our tools but, unlike
  28. many changes in the past this one actually is moving UNIX systems in a
  29. common direction.  A few years ago the idea of of combining our BSD
  30. reference with our System V reference would have been absurd.  Today it is
  31. a reality.
  32.  
  33. What's wrong is that we are creating a bigger system because of the merge.
  34. Also, some things get broken in the process.  This reminds me a lot of
  35. when the ANSI C standard was evolving.  Many people saw this
  36. standardization as "making C bigger".  I was one of those people until I
  37. had the opportunity to meet many of the members of the committee and talk
  38. to them (Thom Plum, in particular) about the project.  Once I got the
  39. "inside look" I saw that documenting common usage rather than building a
  40. new language was the goal of the project.  Personally I think the end
  41. result both defined a good language that all could use and broke a minimum
  42. of existing code.
  43.  
  44. I see the Solaris move as very similar.  It needed to happen and getting
  45. our "ducks in a row" before Microsoft is busy telling the world that NT is
  46. Posix compliant and there are too many different versions of the UNIX
  47. system out there seems like the right time.  Making this happen at the
  48. same time as a new hardware release seems like another good decision.
  49.  
  50. My conclusion is that this decision is in the best interest of both new
  51. users and the UNIX community in general.  Those who have been exclusively
  52. using either System V based systems or BSD based systems will be hurt in
  53. the short term and, yes, systems will get larger and somewhat less
  54. efficient as a result.  But, five years from now, we will all have
  55. benefited from this decision.
  56.  
  57. Now, let me put on my fireproof suit and wait. :-)
  58. -- 
  59. Phil Hughes, SSC, Inc. P.O. Box 55549, Seattle, WA 98155  (206)FOR-UNIX
  60. >>> Publishers of pocket references for UNIX, C, VI, Emacs, Ksh, MS-DOS, ... <<<
  61.      ...!ssc!fyl or fyl@ssc.com            (206)527-3385
  62.  
  63.