NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/sys/sun/misc/6047

Text File | 1992-12-29 | 8.9 KB | 168 lines

Newsgroups: comp.sys.sun.misc
Path: sparky!uunet!psinntp!asd.com!scott
From: [e-mail] (Scott Barman)
Subject: Re: Is Sun losing touch with its customers?
Message-ID: <[e-mail]>
Organization: American Software Development Corp., West Babylon, NY
References: <[e-mail]> <[e-mail]> <kbibb.725606456@maui>
Date: Tue, 29 Dec 1992 20:16:10 GMT
Lines: 157

In article <kbibb.725606456@maui> [e-mail] (Ken Bibb) writes:
>In <[e-mail]> [e-mail] (Scott Barman) writes:
>>When Sun announce they would "join the crowd" almost five years ago,
>>there was no "crowd." At that time Sun also told us that we should not
>>worry, they will provide an upgrade path and that their valued customers
>>would be taken care of.
>
>They did (and do) follow this philsophy--they provided that path via
>the sysv stuff that you complain about below.  If you talked to their SE's
>they've been saying "prepare!  svr4 is around the corner!"  but you didn't
>listen...

Have you ever heard the term "crying wolf?"  They've been crying wolf
for nearly two years!  Sure we heard SVR4 was around the corner, but
when?  It was supposed to be here TWO years before they actually came
out with it.  What do you and Sun want us to do, tread water that whole
time?  Wake up and join the real world.

>>Then Sun announced they are almost ready and puts out the svmt. When it
>>is finally loaded, you realize that svmt is nothing more than a
>>glorified lint!  What's worse is that those of us who have used X
>>Windows since the dawn of time (OK, so it has only been since X Version
>>10) have decided to stay with MIT's X11 and away from Sun's perpertually
>>buggy OpenWindows with their slow response in fixing the bugs (and MIT's
>>X11 was free, I remember having to pay for an initial OW release).  This
>>svmt runs under Sun's XView (SunView for X without intrinsics support)
>>and you had to figure out how to run it to a tty to get around their
>>near useless GUI.  Some tool!
>
>XView is not "SunView for X".  It is an X11 toolkit.  It's very easy
>to use and (according to the unscientific polls here) the most popular
>development toolkit for X on Suns.  It sounds like you just didn't
>know how to run the app on your system (a path set wrong, for example).

Obviously someone who has not programed SunView.  XView is pretty much
SunView translated in X.  I didn't say it required SunView or any of its
other "features" all I said it's been translater to X.

>Another possibility might have to do with your window manager being
>incorrectly set up.

I am using mwm right out of the box from OSF.  It is set up exactly to
OSF specs.  No problems.  The problem is I have no problems using "pure"
XView programs just like I have no problems using programs written with
the Athena Widgets or OLIT.  I have problems with Sun supplied programs
that make use of Sun supplied extensions.  Is this following the
standards?  Afterall, "Sun is the standards company" (taken directly
from the mouth of a Sun sales droid at Unix Expo).

>X was developed by DEC.  NeWS was developed by Sun when they had a falling
>out with Adobe (what they *really* wanted was Display PostScript which they
>will be replacing NeWS with).  The *idea* of NeWS was always superior to
>Dec's X.  It was just a pain to debug...  Btw, Sun has been "X11 compatible"
>for a while--you make it sound like they're doing it as part of the
>Solaris 2.x thing.

Excuse me?  Do you know what you are talking about?  X was developed by
MIT.  They might have used grants from DEC and a lot of X ideas may have
come from DEC Windows, but X is from MIT.

Sun used the excuse that they couldn't get cooperation from Adobe to
start dropping NeWS.  The truth is that they couldn't get cooperation
from the rest of the industry.  How many major vendors were licensing
NeWS?  One?  SGI was just about it.  Sun tried to keep it proprietary
and license it out the way they seem to license SPARC.  Do you see the
"proliferation" of SPARC clones?  This is what they did with NeWS.  A
smarter industry told Sun to go take a hike and ftp'ed that free X11
software from MIT.  IMHO, a smarter choice.

Sun has had problem with their X11 compatibility until the release of
OW3.  OW2, which I first saw in mid-to-late 1990, had some real problems
in the compatibility areas.  Besides, why should I give up on a good
thing.  I've been running Xsun from MIT's X11 distribution since I first
starting using X11 back in late-1987 (wasn't it Release 3 back then?).
Now I run X11R4 (we can't upgrade, yet; some commercial concerns exist
with the work we are doing) and have had NO problems running our prefered
window manager mwm, (yes, I know there is a patch for mwm to work with
the Sun OW3 server).  Following the standards and being the "open
systems leader" (I think I saw that ins some ad) means I can run
AnswerBook on my MIT Xsun server and to X terminals and doesn't require
their "extended" server (here come the flames now... :-)

>>So they are later and getting later.  Still, there is this large
>>investment in 4.1.* with no good upgrade path and they keep pushing back
>
>How do you define "good upgrade path"?  I think they've provided a "good"
>upgrade path.  It isn't fantastic, but it's there.  Just like their
>Sunview upgrade path was there in the early days of OpenWindows...

Better path: instead of doing what they did, as each new release of
SunOS came out, start converting things (utilities, functions, system
calls, sysadmin features, etc.) to use System V features by default.  So
when you do (for example) an "ls", you get the SV version of ls.  If you
*need* the BSD version, there should have been a /usr/compat directory
(or something like that), much as I hear they have under Solaris now.
Do the migration step-by-step and by SunOS 4.1.3 you would almost have
an SVR4 compatible system--sort of like having a Chevy body on a
Corvette engine (ooo... I can hear the flames coming now! :-)

>>the release date (yes, I did get my Solaris 2.1 CDs last week).  In the
>>mean time, those of us on limited budgets have been producing software
>
>You mean a free GNU compiler will break your budget?

Yes!  That "free" GNU compiler has to get here some how.  We are uucp
only, we cannot wait to get it via ftpmail if we upgrade.  We're a small
shop and cannot have that much in down time while we deal with the
restrictions of this service (NOTE: I am *not* flaming the ftpmail
service; on the contrary, I praise it!  But it would pose a real problem
using it in this scenario).  We cannot afford the 1-900- costs that we
would be charged to get it from UUNET and we cannot afford the hundreds
of dollars to order a tape from a company or even the FSF.  Economic
times are tough, in case you haven't noticed, and we are trying to
survive on Long Island, which has been among the hardest hit areas of
the region.

>>Personal Observation: It's interesting how the promise of NT says it
>>will run Windows 3 AND DOS applications but Solaris 2 will not run
>
>Beta testers have stated that NT will only run "well behaved" Windows
>and DOS programs.  Sun has stated that "well behaved" SunOS <5.0 programs
>will be relatively painless to port.  Sounds about even to me...

"Well behaved" under Unix means things like not relying on specific
kernel structures or any specific strucutre for that matter for your
programs.  So when I use a supplied library, I would like it to be
compatible with all version of the operating system of the vendor whose
platform we chose.  I have two programs that use the lwp (Lightweight
Process) library and these will *NOT* work under Solaris.  These are not
optional programs to our package and we have to find some way of porting
them without generating the serious overhead we avoided by useing lwp.
I'm not writing to video memory or trying to take advantage of quirks
in a ROM BIOS, I am using a facility available to me via an interface
library which now does not exist under Solaris 2 (yes folks, I know
threads will be made available under Solaris, but I can't sit and wait
for 2.2 to get it).

>>statically linked 4.1.* a.outs and may not run other applications that
>>use unsupported features in their bsd-compatibility mode (e.g., light
>>weight processes).
>
>Do you understand how linking works?  ABIs?  If so, why complain about
>statically linked programs?  Either this or the system wouldn't be
>SVr4 compliant!

Hey Ken, do you understand how linking works?  Do you understand what
statically linking programs means?  Do you understand what an ABI
defines?  Do you even understand why there might be a need to have a
program statically linked, especially if you are dealing with commercial
software and customers whose environment are not exactly like your own?
ABI and SVR4 compliance are NOT the same thing.  I think you ought to
reexamine this statement!

--
scott barman            | <This space intentionally left blank>
[e-mail]            |
 (I can barely speak for myself, you expect me to speak for my employer??)