*************************************************
These postings are from comp.sys.sun.apps
The postings are not listed below in chronological order.
*************************************************
From: joel@dseg.ti.com (Joel Quejada)
Subject: SunPC 3.0 and Serial/Parallel Controller
Message-ID: <1992Jul16.160426.20648@mksol.dseg.ti.com>
Sender: usenet@mksol.dseg.ti.com (Usenet News)
Nntp-Posting-Host: emu.dseg.ti.com
Reply-To: joel@dseg.ti.com
Organization: Texas Instruments, Inc.
Date: Thu, 16 Jul 1992 16:04:26 GMT
Lines: 24

Has anyone dealt with the following configuration and situation:

Configuration:  Sun Sparc 2
                Sun PC 3.0
                Sun Serial/Parallel Controller

Situation:      Run a PC application within Sun PC 3.0. The PC application
                requires the use of a hardware key plugged into the serial
                port for copy protection.

Question:       Has anyone had any problems with PC programs within Sun 
PC
                recognizing the serial port? I always thought this was
                going to be a good test of how well Sun PC emulated a real
                PC compatible.
---
=====================================================
|        Joel A. Quejada                   |    E-MAIL:    joel@dseg.ti.com   |
|        UNIX Systems Analyst              |    Phone :     (214) 575-6014    |
|        Texas Instruments, Inc.         
|        6620 Chase Oaks Blvd.           |                                    |
|        P.O. Box 869305, MS 8502        | T H I S  S P A C E  F O R  R E N T |
|        Plano, Texas 75086              |                                    |
=====================================================
Article 1185 (140 more) in comp.sys.sun.apps:
From: gord@jericho.uunet.uu.net (Gord Wait)
Subject: Re: SunPC - Yuk!
Message-ID: <1992Jun18.201657.9013@jericho.uunet.uu.net>
Keywords: SunPC, install
Organization: S-MOS Systems, Inc. (Vancouver Design Center)
References: <Jun.15.18.17.35.1992.2093@pilot.njin.net> 
<206@ftms.UUCP>
Distribution: usa
Date: Thu, 18 Jun 1992 20:16:57 GMT
Lines: 62

In article <206@ftms.UUCP> brown@ftms.UUCP (Vidiot) writes:
>In article <Jun.15.18.17.35.1992.2093@pilot.njin.net> 
giacobbe@pilot.njin.net (Jeff Giacobbe) writes:

><2) The installation script requires the ROOT PASSWORD of the 
machine
><you are installing it on!!  Sorry, I've got a real *BIG* problem with
><that.
>
>Sorry, but I can't fault Sun for this one.  As a security precaution, only
>authorized users should be installing software packages.  Hence the need 
to
>be the super user (root).  Would you want someone to be able to install a
>piece of software on your system that contained viruses?  I didn't think 
so.

There is no reason in the world that you should have to supply the
password to the install program. All that is normally required is to
sign on as root. I think you missed the point here.


>
><3) After (grudgingly) supplying said root password, the installation
><script proceeded to go ahead and modify a number of system files,
><silently, without notification.  Every software package I have ever
><installed would either notify me every step of the way and ask for
><confirmation, or else create a "to do" list of files, etc that I
><should modify by hand after the script completed. In some cases, this
><info was part of the written docs, but never, EVER have I seen an
><installation script that just plowed ahead without warning.  Some of
><the system files that SunPC felt the need to screw with were:
><
></etc/rc.local
></etc/inetd.conf
></etc/services
><root's crontab file
>
>The idea of doing this automatically is to remove the bother of having to
>explain to you how to do it.  And then maybe it will get done incorrectly.
>The installation software that I have for our product also modifies system
>files.  But, messages are displayed when this happens.  It is too late for
>the installer to do anything when the message is seen.  It is much easier
>to do it automatically than it is to try and explain the process to the
>installer.  It is normally going to get done correctly if done 
automatically.
>I can't say that about hand editing.

In my experience with both UNIX and DOS machines, it is VERY seldom
that an automatic install script works properly without trashing
something else. Say one out of ten install scripts works perfectly. (I
am very serious, no exaggeration!!) If the install script doesn't even
tell you what files it mucks with, and it introduces a bug in your
Unix environmnent, it could take DAYS to track down the source of the
bug! Totally unacceptable. 

If you have had much better luck with install programs, then you are
incredibly lucky, and I would like you to suggest some winning lottery
ticket numbers for me!! :)
 My two cents.



-- 
Gord Wait       SMOS Systems Vancouver Design Centre
uunet!jericho!gord
jericho!gord@uunet.UU.NET

End of article 1185 (of 1349)--what next? [npq] 
From: rhb@hotsand.cnet.att.com (54312 - Rich Brandwein(none)none)
Subject: Re: SunPC vs. SoftPC
Reply-To: rich.brandwein@att.com
Organization: AT&T Bell Labs - Holmdel, NJ
Date: Thu, 9 Jul 1992 19:37:32 GMT
Message-ID: <1992Jul9.193732.20772@cbnewsi.cb.att.com>
Originator: rhb@hotsand
References: <472@winsoft.SE> 
<1992Jul8.203519.8711@jericho.uunet.uu.net>
Sender: news@cbnewsi.cb.att.com (NetNews Administrator)
Nntp-Posting-Host: hotsand.cnet.att.com
Lines: 37


In article <1992Jul8.203519.8711@jericho.uunet.uu.net>, 
gord@jericho.uunet.uu.net (Gord Wait) writes:
|> In article <472@winsoft.SE> leif@winsoft.se (Leif Samuelsson) writes:
|> >
|> >Here is a brief feature comparison between SunPC 3.0 from Sun
|> >Microsystems Inc and SoftPC 3.0 from Insignia Solutions Ltd.
|> >
|> stuff omitted
|> >
|> 
|> >            SunPC 3.0                       SoftPC 3.0
|> >            ---------                       ----------
|> >
|> >User interface:Motif menus (which means the OPEN LOOK menus 
(which means
|> >            menus look similar to those     the menus look similar to those
|> >            in MS-Windows).                 in other OpenWindows apps).
|> >
|> >
|> 
|> If I read this right, the SUN MICRO UI is Motif, and the Insignia UI
|> is OPENLOOK!! 
|> 
|> No wonder Motif is winning the window manager competition!!

        SunPC 3.0 uses OPENLOOK (I'm not sure of SoftPC 3.0) not
Motif.  By the way, I've come across an interesting bug in SunPC 3.0;
it crashes the system whenever you try to run it with FrameMaker 3.1
(which is a very popular package).   I read somewhere that Sun claimed
SoftPC 3.0 is nearly identical to SunPC 3.0, but the difference was
Sun's rigourous compatibility testing for the Sun SPARC environment.
I would wonder, therefore, how many problems SoftPC 3.0 has running 
on a Sun...


-- 
--
        Rich Brandwein          rich.brandwein@att.com
End of article 1344 (of 1349)--what next? [npq] 
Article 1304 (147 more) in comp.sys.sun.apps:
From: leif@winsoft.se (Leif Samuelsson)
Subject: SunPC vs. SoftPC
Message-ID: <472@winsoft.SE>
Date: 4 Jul 92 16:55:52 GMT
Organization: Winsoft Data AB, Stockholm, Sweden
Lines: 88


Here is a brief feature comparison between SunPC 3.0 from Sun
Microsystems Inc and SoftPC 3.0 from Insignia Solutions Ltd.

I have tried to be as objective as possible, since I work for
Insignia's distributor in Sweden.

I am sure that the list contains errors and omissions. Please
mail me at leif@winsoft.se if you have any comments.



                SoftPC 3.0                       SunPC 3.0
                ---------                       ----------

Emulation:      80286/80287                     80286/80287
                protected mode                  protected mode

                (Both have the same basic processor emulation
                 engine from Insignia Solutions and should give
                 comparable CPU speed).


Hardware        No hardware assist              Sbus boards available
assist:         available.                      with 386 and 486
                                                processors.


User interface: Motif menus (which means the    OPEN LOOK menus 
(which means
                menus look similar to those     the menus look similar to those
                in MS-Windows).                 in other OpenWindows apps).


Graphics:       Hercules, CGA, EGA,             Hercules, SuperVGA
                SuperVGA, MS-Windows

                Special MS-Windows driver       Special DGA assist
                gives fast mouse and window     (Direct Graphics Access)
                handling in Windows, even       gives fast graphics on
                on X-terminals. The Windows     OpenWindows server 
(xnews).
                screen can be any size, e.g.
                1152 x 900.


Magnified       1x, 1.5x, 2x (not with the      Regular or double height.
screen:         special MS-windows driver).


National        No automatic support, but       Full support for Sun's
keyboards:      keyboards can be remapped       national keyboards.
                with a mapping file.


Copy/Paste:     Uses Xt selection in text       Uses OpenWindows selection
                mode (Paste with middle         in text mode (use menu or
                mouse button).                  COPY/PASTE keys).


MS-DOS:         Dos 5.0 installed.              Dos 4.01 installed. Can
                                                be upgraded to Dos 5.0.

Extended        Up to 16 Mbytes (uses swap      Up to 16 Mbytes (uses swap
memory:         space).                         space).


Expanded        Emulates LIM board up to        Can emulate expanded 
memory
memory:         32 Mbyte. Uses a file in        using extended memory.
                /usr/tmp.


Licensing:      Built-in floating license       Uses Sun Network License.
                system. Does not require
                background license daemon.


Installation:   Run tar from tape or cp -rp     Use special installation
                from CD; install password;      program; enable licensing;
                set three environment           install users.
                variables.


-----
Leif Samuelsson

Winsoft Data AB                 Phone: +46 8 168200
Stora Skuggans v. 11            Fax:   +46 8 168209
S-115 42  STOCKHOLM             E-mail: leif@winsoft.se
Sweden
End of article 1304 (of 1334)--what next? [npq] 
From: sun-barr!rutgers!dziuxsolim.rutgers.edu!pilot.njin.net!giacobbe Sat 
Jun 27 09:41:27 CDT 1992



My apologies if this thread has been hashed over berfore, but...

After three weeks and five service calls to Sun, I've finally thrown
in the towel on SunPC 3.0

The problem is that Sun took a good product (Insignia's SoftPC) and
added there own 'features' like SunNet License Manager thereby
screwing the whole thing up.

Now granted, I am far from being a Unix and/or Sun guru, but I'm
reasonably competent at administering my system and installing
software.  Here is a small list of things that really bugged me about
attempting to install SoftPC 3.0

1) It *requires* a machine with a floppy drive to install the
licensing password(s).  This wasn't too much of a problem in my case,
but for some one without easy access to a floppy (i.e. a SysAdmin
surrounded by 4/330's and other non 'desktop' machines) it is an
unecessary pain in the a**

2) The installation script requires the ROOT PASSWORD of the machine
you are installing it on!!  Sorry, I've got a real *BIG* problem with
that.

3) After (grudgingly) supplying said root password, the installation
script proceeded to go ahead and modify a number of system files,
silently, without notification.  Every software package I have ever
installed would either notify me every step of the way and ask for
confirmation, or else create a "to do" list of files, etc that I
should modify by hand after the script completed. In some cases, this
info was part of the written docs, but never, EVER have I seen an
installation script that just plowed ahead without warning.  Some of
the system files that SunPC felt the need to screw with were:

/etc/rc.local
/etc/inetd.conf
/etc/services
root's crontab file

Again, all of this silently without any notification or confirmation.

4) Even though I specified (when prompted) that I wanted to install
the whole package under /usr/local,  the modifications to the above
files contained paths to the default installation directory (/usr)


Of course, after all this the license manager refused to start up
correctly so I spent the better part of an afternoon on the phone with
Sun going back and editing the above files by hand (each time saying
'What, it modified THAT file too?!?!)

Four phone calls and three reboots later I said the hell with it and
packed SunPC back in it's nice, glossy, shrinkwrapped, user-friendly
packaging and called it quits.

I think I'll give Insignia a call tomorrow....



Sorry for the tirade,


Jeff
-- 
@xxxxx{==============- giacobbe@icarus.montclair.edu 
-==============}xxxxx@
|                                                                         |
|                "There can be only one..." - (Highlander)                |
|                                                                         |
@xxxxx{==============- giacobbe@icarus.montclair.edu 
-==============}xxxxx@ 


From: wupost!uunet!darwin.sura.net!news.duc.auburn.edu!netman!elling 
Sat Jun 27 09:42:02 CDT 1992

Well, I for one sincerely hope Sun's answerline gets an earfull
from the SunPSC 3.0 release.  It is certainly not tops on my list
of easy to install software.  In order to help spread some wisdom
and hopefully help others avoid some traps here are some tricks:

1. SunPC 3.0 requires SunNet License (SNL).  It is likely that this is
the first SunNet License software that many sites will be installing.
The SunPC distribution does not include printed SNL installation
instructions, rather they refer you to the local Sun salesperson.
This is a rather silly blunder.  Admittedly, there are some man
pages for SNL in the distribution, but they are outdated (referring
to a SunView interface) and insufficient when problems occur.  Sun
really ought to put together a short SNL reference to ship with every
SNL product.  They have done this with the CD Manager, why not SNL?

2. SNL doesn't handle C2 secure password files correctly.  To wit,
the /etc/security/passwd.adjunct file must be readable by daemon.
Which usually means "must be readable by all" which defeats the very
reason we have an /etc/security/passwd.adjunct file in the first place.
If you run C2 secure and can't get SNL to recognize the administrator's
password, try changing permissions on the passwd.adjunct file.  Sun,
use pwdauth(3)!

Please note that the /etc/security/passwd.adjunct file is not necessarily
the source for the NIS passwd.adjunct map.  So this limitation may not
be so critical to many sites.  Also, the read permission is only 
required when modifying the license database or printing usage reports.
Normal, day to day operations may allow the permissions to revert to a
more secure level.

3. SNL limits the number of floating licenses to 49.  Ok, this limit *is*
just plain stupid.

4. The diskette requirement is a pain.  This is another blunder.  I would
feel confident that if the diskette had gotten trashed, Sun would have
quickly replaced it.  For those sites without diskette drives, I presume
that you can get SNL running without it.  Contact your Sun sales rep.

5. SNL verifies the server using the hostname (as shown via the hostname
command) and the hostid.  If you are connected to the internet and use a
short hostname locally and a fully qualified domain name, then SNL really
wants your local hostname.

6. SunPC uses a dynamically loaded kernel module.  However, the module 
is
loaded at boot time via the /etc/rc.local.  This is not what I would 
expect from a product that runs under OpenWindows 3.0.  I think the 
module
should be loaded upon demand though I'm not sure this is feasible under
SunOS 4.x.


The point to all of this is that SunPC seems to be a nice product.
But, SunNet License is a pain to install.  If Sun really expects to be
able to move all of their compilers and unbundled products to SNL, then
they had better make SNL easier to administer.  Otherwise people like
Jeff Giacobbe and myself will throw in the towel.

Meanwhile, if you come up with a new trick for easing the installation
of SNL, please share your knowledge, post to the net.

---
 Richard Elling                          Manager of Network Support
 Auburn University                       Engineering Administration
 richard.elling@eng.auburn.edu   KB4HB [44.100.0.72]  (205)844-2280
 Hey San Diego!  Tomahawk some of this!  CHOP  CHOP  SWEEP  
SWEEP



From: usc!rpi!clarkson!sun.soe.clarkson.edu!wargopl Sat Jun 27 09:42:21 
CDT 1992


Talk about opening a can of worms.  It took me two days to install SunPC
3.0 on my SS IPC.  (We took advantage of the "upgrade to the VGA 
SOftPC,
and receive SunPC 3.0!" offer.) The problems were as follows:

1) It arrived a week after SoftPC VGA.  I had just installed one damn
product, and now I had to install another...

2) Somehow, the install program nuked my floppy drive, and I didn't find
the little note in the errata about this possibility 'till the next day.
To quote myself, "I have to REBOOT the machine??"

3) I got around the floppy problem ny using another machine's floppy
disk over the net, but it wasn't over....

4) Here's a great one: the post-install script kept bombing.  After
careful analysis, I determined that it was running the 'arch -k'
command, and getting wrong answers. Why?? Because I stupidly had
Interleaf 5's bin directory on my path before Sun's.  You guessed it -
Interleaf has an arch command that returns 'sun4', not 'sun4c' when the
-k option is used.  The script is too damn fragile.

5) After getting used to the "no license server found" message at boot
time, (Why wasn't this in the docs?) and the weird cron messages I
*didn't* expect....

6) Where is the *blazing speed* offered in the SoftPC ads?

It works O.K. for now, but I'm rather peeved at Sun.

-Pete

-- 
----------
Peter L. Wargo        | wargopl@sun.soe.clarkson.edu | "In other words...
Documentation         |                              |  R.T.F.M..."
Enable Software, Inc. | GEnie mail: PSYCLOPS         |
--
----------
Peter L. Wargo        | wargopl@sun.soe.clarkson.edu | "In other words...
Documentation         |                              |  R.T.F.M..."
Enable Software, Inc. | GEnie mail: PSYCLOPS         |


From: usc!zaphod.mps.ohio-state.edu!pacific.mps.ohio-
state.edu!linac!att!rutgers!igor.rutgers.edu!dartagnan.rutgers.edu!trudel 
Sat Jun 27 09:43:02 CDT 1992

giacobbe@pilot.njin.net (Jeff Giacobbe) writes:

>My apologies if this thread has been hashed over berfore, but...
>
>After three weeks and five service calls to Sun, I've finally thrown
>in the towel on SunPC 3.0

I guess I was luckier.  I only had to place one service call, and it
took me two weeks to get it working comfortably.

>The problem is that Sun took a good product (Insignia's SoftPC) and
>added there own 'features' like SunNet License Manager thereby
>screwing the whole thing up.

Not only that, but SunPC doesn't use the lower grade display drivers
(like EGA) and as a result, you only have VGA or Hercules
compatibility.  How nice for those people with older PC programs that
don't do VGA.  Furthermore, SunPC, while it has built-in PCNFS-style
"net use" commands, *requires* that if you want access to an NFS
directory, you have to mount it on your sun so that sunpc can use it.
What happened to PCNFS' "net use H: remotehost:/partition" function??
Sheesh.

I am likewise disconcerted with the SunNet License software.  First of
all, there is no SunNet License documentation - you have to ask your
local rep for it, as the manual says - if you can include a section
that says "ask for SNL docs", then why can't you include the *&^%*&^
SNL docs?  Secondly, without documentation, it's rather difficult to
release a "stuck" license if there's no explanation on how to do it.
(of course, I'll bet the SNL documentation explains everything).

>1) It *requires* a machine with a floppy drive to install the
>licensing password(s).

Fortunately, you can do the sunpc licensing part anywhere you have a
floppy drive, provided that you don't screw up the first time - if,
for some reason, you screw up the floppy verification procedure, the
system with the floppy will no longer recognize the floppy drive (bad
format, drive not ready errors result).  The official cause is
unknown, and the official fix is to reboot the system with the floppy
(which was the basis of my service call).  How conveeeeeenient.

>2) The installation script requires the ROOT PASSWORD of the machine
>you are installing it on!!  Sorry, I've got a real *BIG* problem with
>that.

Not to mention that if you happen to do a "ps aux" on that system, you
see the install script process WITH THE ROOT PASSWORD 
DISPLAYED.
That, my friends, is inexcusable.  

>3) After (grudgingly) supplying said root password, the installation
>script proceeded to go ahead and modify a number of system files,
>silently, without notification.  

Let's hear it for SunPC following Sun's "extract_unbundled" command,
eh?  Is it because of the "divestiture"?  

>/etc/rc.local
>/etc/inetd.conf
>/etc/services
>root's crontab file

That's about it - I had to uninstall sunpc, and it tells you what
files to return to normal.  Who needs uninstall scripts?

[installing]
>the whole package under /usr/local,  the modifications to the above
>files contained paths to the default installation directory (/usr)

Now that's strange - I did the same thing, and everything installed
properly for me where I wanted it.

Now that sunpc is "working" I'll be able to try it out to see what's
right with it.  Lord knows...


From: usc!elroy.jpl.nasa.gov!decwrl!mcnc!samba!robinson Sat Jun 27 
09:43:21 CDT 1992

I'll just add a quick two cents worth to this thread.  I was unable to run
Sun Net License on a stand-alone machine or on a machine without NIS.  It
just kept giving me gethostbyname() errors.  Loads of fun.  Also SNL 
doesn't
give terribly good error messages.  Sun support finally sent me a little 
program that tries to check out then release the SunPC license, this with
lots of debug info.  After getting a loopback for the AUI port, and running
NIS on this stand-alone machine, and then straightening out the mistakes I
made in relation to SNL when I naively thought I could do it straight out 
of the box, I now have a running SunPC implementation.  It is *much* 
nicer
than DOS-Windows, though.
--
-------------------------------------------------------------------------------
When I find myself in times of trouble, | Gerard Robinson, 
robinson@med.unc.edu
Then I'll know just where I'll be;      | UNC School of Medicine, Office of
Swearing at the console.  Let me be ... | Information Systems.   27599-
7045
-------------------------------------------------------------------------------
-- 
-------------------------------------------------------------------------------
When I find myself in times of trouble, | Gerard Robinson, 
robinson@med.unc.edu
Then I'll know just where I'll be;      | UNC School of Medicine, Office of
Swearing at the console.  Let me be ... | Information Systems.   27599-
7045


From: uunet!icd.ab.com!icd.ab.com!eik Sat Jun 27 09:43:47 CDT 1992

Thanks to those that posted articles describing installation problems with
Sun's SunPC product.  We're considering whether to upgrade from 
Insignia's
SoftPC v2.1 product to SoftPC v3.0 or SunPC v3.0 and any information 
regarding
the good and bad points of each product would be appreciated.

Is the SunPC support for Sbus 486 accelerator boards worth the hassles?
Do the accelerator boards allow the product to emulate a true 32 bit 
processor
or does it operate as a very fast 286?  We want to use software that will
only run 386 or 486 processors (Xilinx EPLD, ASIC design tools) and it 
looks
like the SoftPC or SunPC software product alone will not do that.

Please post or send email.  Thanks.

Ed Kizys	eik@icd.ab.com
Allen-Bradley Co.
Highland Hts., Ohio


From: sun-
barr!ames!agate!stanford.edu!rutgers!uwvax!astroatc!vidiot!ftms!brown 
Sat Jun 27 09:44:17 CDT 1992

In article <Jun.15.18.17.35.1992.2093@pilot.njin.net> 
giacobbe@pilot.njin.net (Jeff Giacobbe) writes:
<
<1) It *requires* a machine with a floppy drive to install the
<licensing password(s).  This wasn't too much of a problem in my case,
<but for some one without easy access to a floppy (i.e. a SysAdmin
<surrounded by 4/330's and other non 'desktop' machines) it is an
<unecessary pain in the a**

Do you know of another way that it can be done?  If you have to install the
software via, floppy, shouldn't the other requirements also use the floppy?

Am I missing something obvious here?

<2) The installation script requires the ROOT PASSWORD of the machine
<you are installing it on!!  Sorry, I've got a real *BIG* problem with
<that.

Sorry, but I can't fault Sun for this one.  As a security precaution, only
authorized users should be installing software packages.  Hence the need to
be the super user (root).  Would you want someone to be able to install a
piece of software on your system that contained viruses?  I didn't think so.

<3) After (grudgingly) supplying said root password, the installation
<script proceeded to go ahead and modify a number of system files,
<silently, without notification.  Every software package I have ever
<installed would either notify me every step of the way and ask for
<confirmation, or else create a "to do" list of files, etc that I
<should modify by hand after the script completed. In some cases, this
<info was part of the written docs, but never, EVER have I seen an
<installation script that just plowed ahead without warning.  Some of
<the system files that SunPC felt the need to screw with were:
<
</etc/rc.local
</etc/inetd.conf
</etc/services
<root's crontab file

The idea of doing this automatically is to remove the bother of having to
explain to you how to do it.  And then maybe it will get done incorrectly.
The installation software that I have for our product also modifies system
files.  But, messages are displayed when this happens.  It is too late for
the installer to do anything when the message is seen.  It is much easier
to do it automatically than it is to try and explain the process to the
installer.  It is normally going to get done correctly if done automatically.
I can't say that about hand editing.

<4) Even though I specified (when prompted) that I wanted to install
<the whole package under /usr/local,  the modifications to the above
<files contained paths to the default installation directory (/usr)

I don't know the whole story here, since you don't say.  But, did the main
programs get installed in /usr/local and only the system files got changed
in other directories?  If the installation of the main package was in /usr,
instead of /usr/local, then there was indeed a problem.

<Of course, after all this the license manager refused to start up
<correctly so I spent the better part of an afternoon on the phone with
<Sun going back and editing the above files by hand (each time saying
<'What, it modified THAT file too?!?!)

See above.  So far, all extract_unbundled type Sun installations have 
worked
for me.  This included the licensing for the NeWSprint fonts.

<Four phone calls and three reboots later I said the hell with it and
<packed SunPC back in it's nice, glossy, shrinkwrapped, user-friendly
<packaging and called it quits.

Too me it sounds like you have a predisposition against the Sun installation
because you were required to use the root password and it changed a bunch
of system files.  With your mind already against the package, any little
thing that goes wrong just makes it worse.  I've felt the same way about
some things as well.

But, I prefer to have system files automatically changed instead of trying 
to
do it by hand, since the error rate is normally less.  You should see my
error rate in writing the installation script and the number of tests that
I put it through.  You have it easy, all you have to do is install it.  I
have to write it (not SunPC in this case).

<Sorry for the tirade,

You should have seen my tirade when we first got NeWSprint 1.0.  The 
flame-
thrower got pretty hot.  That has changed alot since working with Sun and
getting the NeWSprint 2.0 version.

Stick with it, things do get better.
-- 
harvard\
  ucbvax!uwvax!astroatc!ftms!brown  or  uu2.psi.com!ftms!brown
rutgers/
INTERNET: brown@wi.extrel.com  or  
ftms!brown%astroatc.UUCP@cs.wisc.edu


From: wupost!uunet!mcsun!uknet!axion!micromuse!godot!dj Sat Jun 27 
09:44:36 CDT 1992

In article 21409@ccu.umanitoba.ca, rahard@eeserv.ee.umanitoba.ca (Budi 
Rahardjo) writes:
>From previous postings I noticed that SunPC installation is a pain.
>Now, we want to upgrade our DOS emulator (from DOS windows).
>
>- Should we buy SoftPC instead ?
>- How would you compare SoftPC with SunPC ? Which one is better ?
>
>-- budi
>--
>Budi Rahardjo
><rahardj@ccu.umanitoba.ca>      <rahard@ee.umanitoba.ca> 
>Electrical Engineering - University of Manitoba - Canada


In pure software terms they are very similar, but SunPC has the advantage 
that
you can add the 486sx or 486dx accelerator cards and get full 386 
emulation and
a whole load of better performace, and you get your SPARC CPU cycles 
back...

---

=====================================================
=======================
  dj@micromuse.co.uk    |"In a perfect world we'd all sing in tune
  Voice +44-71-352-7774 | but this is reality so give some room" 
  Fax   +44-71-351-7834 |                           (Sir) William Bragg
------------------------+---------------------------------------------------
 Non-standard Disclaimer : "I didn't do it, it wasn't me, I wasn't there"


From: uunet!crdgw1!rdsunx.crd.ge.com!rdsunx!barnett Sat Jun 27 
09:45:14 CDT 1992

In article <206@ftms.UUCP> brown@ftms.UUCP (Vidiot) writes:
>   Sorry, but I can't fault Sun for this one.  As a security precaution, only
>   authorized users should be installing software packages.  Hence the 
need to
>   be the super user (root).  Would you want someone to be able to install 
a
>   piece of software on your system that contained viruses?  I didn't think 
so.

I dissagree.

If a program had a virus and I installed it as a regular user, it would only
destroy my stuff. If it had a virus and root installed it, it could
destroy the entire system. Therefore it's safer to install it as a
regular user.

Non-OS software should not be installed by root - EVER. Instead, the
software should be installed by an ordinary user, and root could run a
special program.

As a former system manager at a site with 800 Sun's, I would never
trust a program that said "su root; install". Instead, I would do 95%
of the installation as myself, and only do the root specific part when
I fully understood what it wanted to be done. And yes, this was more
work. Ever break something that 800 people were using?

These installations, running as root, could completely destroy your
environment. Why does the program need root priviledges anyway?
Why can't I copy it to a local directory, set up some environment
variables, and use it? What requires root access?

If it requires root access, I don't trust it.

Too many vendor installations assume
 1) you have root access
 2) you are installing on a local disk
 3) you have the tape/floppy on your local machine
 4) The file server was the same type of machine as your local machine
 5) you are running a generic environment
 6) The place the software will really be and where it only appears to
    be are the same. (i.e. /usr is 100% full, but the software has to
    be installed on /usr)
 7) The software can be installed as a directory name of the vendor's 
choice.

	If it is licensed for one machine, don't dictate where to install
it.  Let the administrators decide where it belongs.  We have special
partitions exported to particular machines, so a licensed package may
be on /private/package/...  This way we keep one copy, export it to
the proper machiners, and prevent others from using it illegally.
But these packages assume the program is located in /usr somewhere,
which makes it that much more difficult to install and stay legal.

	Becoming root wouldn`t work anyway if it had to do something
on an NFS file server, like chown(2) a file, or changing a file on a
file system mounted read only.

	I wish these software vendors would wake up. Not everyone has
stand-alone machines on their desktop.

I wish I could mail this to every vendor out there selling software.

Sturgeon's Law. grumble grumble. 
--
Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett


From: sun-
barr!olivea!spool.mu.edu!sol.ctr.columbia.edu!destroyer!ncar!unmvax!bb
x!tantalum!tantalum!cheeks Sat Jun 27 09:45:35 CDT 1992

In article <wargopl.708701877@sun.soe.clarkson.edu>, 
wargopl@sun.soe.clarkson.edu (Peter L. Wargo) writes:
> 
> 6) Where is the *blazing speed* offered in the SoftPC ads?
> 

Very good question.  SoftPC with only EGA support was much faster.  
The
text scroll speed in SunPC with VGA emulation is pathetic ... in Herc mode
it's slightly better, but I'm sure it coudl be much better all around.

Running Windows apps under it is an exercise in masochism.

>>Chx
-- 
cheeks@edsr.eds.com    or     ...uunet!edsr!cheeks


From: sun-
barr!olivea!uunet!darwin.sura.net!ukma!widener!netnews.upenn.edu!aspen
!rsk Sat Jun 27 09:45:53 CDT 1992

In article <206@ftms.UUCP> brown@ftms.UUCP (Vidiot) writes:
>The idea of doing this automatically is to remove the bother of having to
>explain to you how to do it.  And then maybe it will get done incorrectly.
>The installation software that I have for our product also modifies system
>files.  But, messages are displayed when this happens.  It is too late for
>the installer to do anything when the message is seen.  It is much easier
>to do it automatically than it is to try and explain the process to the
>installer.

Every install script/program should notify the installer about system files
that it intends to change *before* it changes them.  It should clearly give
the text of the change in full, should explain why the change is being made,
and should allow the installer to respond with a go/no-go answer for each 
item.
The documentation for the product should repeat this information *at the
beginning* of the installation instructions.

While auto-installation might be great for sites with vanilla configurations
on non-Unix-literate admins, it is absolutely obnoxious for sites with 
custom
configurations and more experienced admins.  I would rather type in 
everything
by hand and take my chances with the errors thus introduced (hey, at least 
they're
*my* mistakes, not an installation script's) than use an auto-installation 
script.
--

---Rsk, aka Darth Wombat
rsk@gynko.circ.upenn.edu


From: wupost!udel!rochester!rocksanne!yngvi!mjackson Sat Jun 27 
09:46:15 CDT 1992

In article 206@ftms.UUCP, brown@ftms.UUCP (Vidiot) writes:

> In article <Jun.15.18.17.35.1992.2093@pilot.njin.net>
giacobbe@pilot.njin.net (Jeff Giacobbe) writes:

> <2) The installation script requires the ROOT PASSWORD of the 
machine
> <you are installing it on!!  Sorry, I've got a real *BIG* problem with
> <that.
> 
> Sorry, but I can't fault Sun for this one.  As a security precaution, only
> authorized users should be installing software packages.  Hence the need 
to
> be the super user (root).  Would you want someone to be able to install a
> piece of software on your system that contained viruses?  I didn't think 
so.

Leaving aside the question of whether software should require that any
installation be done by superuser (which is eloquently dealt with by
Bruce Barnett), you miss the point:  this installation requires that
the root PASSWORD be handed to it.  Unacceptable on its face.

---
Mark <MJackson.Wbst147@Xerox.COM>
    "Careful!  We don't want to learn anything from this."




From: qt.cs.utexas.edu!yale.edu!think.com!news.bbn.com!micro-heart-of-
gold.mit.edu!rutgers!igor.rutgers.edu!dartagnan.rutgers.edu!trudel Sat Jun 
27 09:47:06 CDT 1992

brown@ftms.UUCP (Vidiot) writes:

>In article <Jun.15.18.17.35.1992.2093@pilot.njin.net> 
giacobbe@pilot.njin.net (Jeff Giacobbe) writes:
><
><1) It *requires* a machine with a floppy drive to install ...

>Do you know of another way that it can be done?  If you have to install 
the
>software via, floppy, shouldn't the other requirements also use the 
floppy?

>Am I missing something obvious here?

In a word, yes.  The SoftPC program comes on a CDROM, and the
licensing information is on a floppy.  While Sun probably expects that
you'll only be running softpc on a system with a disk, it's bad
assumption that you will absolutely have one.  In our environment, we
have PC software loaded up on our Sun server (a 4/490, by the way),
and it was loaded on Sun by PCs running PCNFS.  If we run sunpc, we
don't necessarily need a floppy disk drive.  

><2) The installation script requires the ROOT PASSWORD of the 
machine
><you are installing it on!!  Sorry, I've got a real *BIG* problem with
><that.

>Sorry, but I can't fault Sun for this one.  As a security precaution, only
>authorized users should be installing software packages.  

You only need the root password if you're installing it on a remote
system, but, as I pointed out, heaven help you if j.ramdom.user runs
a "ps aux" when this is happening because he or she will see your root
password displayed.  So, yes, I *can* fault Sun for this one.

><3) After (grudgingly) supplying said root password, the installation
><script proceeded to go ahead and modify a number of system files,
><silently, without notification.  

>The idea of doing this automatically is to remove the bother of having to
>explain to you how to do it.  And then maybe it will get done
>incorrectly.

You haven't installed much Sun Software lately, have you?  Just about
every single package I've installed tells you what it's about to do,
where it'll install itself, and ask if you want to proceed.  Not here.
Absolutely wrong.  I have no problem with automatic installs, provided
they tell me what they're doing!  You'd think that Sun would know
better.  Come to think of it, when I installed Insignia's SoftPC (the
package that Sun bought to make SunPC), it did all the asking I
wanted.

><Of course, after all this the license manager refused to start up
><correctly so I spent the better part of an afternoon on the phone with
><Sun going back and editing the above files by hand (each time saying
><'What, it modified THAT file too?!?!)

>See above.  So far, all extract_unbundled type Sun installations have 
worked
>for me.  This included the licensing for the NeWSprint fonts.

But, this package does not follow the accepted "extract_unbundled"
conventions!  That's why we're complaining.

><Sorry for the tirade,

>You should have seen my tirade when we first got NeWSprint 1.0.  The 
flame-
>thrower got pretty hot.  That has changed alot since working with Sun 
and
>getting the NeWSprint 2.0 version.

Ah yes.  We ended up returning our original SPARCprinter as a result.
Fortunately, NeWSprint 2.0 came out, and we ended up getting another
SPARCprinter.  


From: csc.ti.com!tilde.csc.ti.com!mksol!mksol!joelq Sat Jun 27 09:47:28 
CDT 1992

Gee, is this a hint of great things to come?  I installed SunPC 3.0 on a
customer's machine the other day and it took me about 1 1/2 hours.  Had to
run through the installation three times before it seemed to work 
satisfactorily.

I agree about the disk drive hassles - this caused me to have to re-boot the
machine 3 or 4 times.

After it got installed though, it seemed to work like a champ. We had a 
'486
board on a Sparc 2, and it ran smooth as silk - not to mention real fast.

---
-------------------------------------------------------------------------------
| Joel A. Quejada                                 |     joel@dseg.ti.com      |
| Sr. Systems Software Analyst, UNIX Workstations |      (214) 575-6014       
|
| Texas Instruments, Plano, Texas                 |                           |
-------------------------------------------------------------------------------



From: swrinde!mips!darwin.sura.net!news.duc.auburn.edu!netman!elling 
Sat Jun 27 09:48:41 CDT 1992

In article 9013@jericho.uunet.uu.net, gord@jericho.uunet.uu.net (Gord 
Wait) writes:
...
>                            If the install script doesn't even
>tell you what files it mucks with, and it introduces a bug in your
>Unix environmnent, it could take DAYS to track down the source of the
>bug! Totally unacceptable. 
...

You might try:
	find / -xdev -mtime -1 -ls
	find /usr -xdev -mtime -1 -ls
to locate changed files after an install.

---
 Richard Elling                          Manager of Network Support
 Auburn University                       Engineering Administration
 richard.elling@eng.auburn.edu   KB4HB [44.100.0.72]  (205)844-2280
 For lack of a better word, it is work that I am doing.


From: 
sdd.hp.com!spool.mu.edu!uunet!darwin.sura.net!ms!vt.cs.wm.edu!kearns 
Sat Jun 27 09:49:13 CDT 1992


Has anyone else installed the cheaper accelerator (the 486 SX)
and seen performance degradation relative to the software emulation?
I have a simple multi-server queue simulation which runs in about
40 seconds on the software emulator but in about 60 seconds on the
SX accelerator.

Some specifics:
 - IPC with 24 Mbyte ram and lots of disk
 - Turbo Pascal 6.0 compiles code to disk
 - Compile for software emulation with math co-processor
   used and not used => running time of about 40 seconds
   in both cases
 - Compile for accelerator with coprocessor option disabled
   => running time of 60 seconds
 - The code runs in about 40 seconds on a real PC-AT w/
   80287
 - The code runs in aboyt 4 minutes on a PC-AT w/o 80287
 - The code runs in about 4 seconds on a 25Mhz 486
 - The simulation uses lots of floating point ops

I really didn't expect a super speed-up, but I sure didn't
expect a negative one!
 

-- 
Phil Kearns


From: swrinde!gatech!ukma!hsdndev!news.cs.umb.edu!rouilj Sat Jun 27 
09:49:40 CDT 1992



In article <BARNETT.92Jun17125903@grymoire.crd.ge.com> 
barnett@grymoire.crd.ge.com (Bruce Barnett) writes:

>   Too many vendor installations assume
>    1) you have root access
>    2) you are installing on a local disk
>    3) you have the tape/floppy on your local machine
>    4) The file server was the same type of machine as your local machine
>    5) you are running a generic environment

Ahh yes. I still have memories of an install script getting screwed up
by a non standard /etc/rc and /etc/rc.local and trashing both of the
files.  Fortunately running rdist put the everything right again, and
then I had to figure out what the bloody install script was trying to
do in the first place.  Of course the install doc was totally useless.

One install script I particularly liked assumed that the machine name
was located after the "hostname" line at the top of the rc.local file
under Ultrix. Imagine my surprise at being told that my hostname was
"`cat /etc/hostname`" 8-).  Needless to say the install script got
really confused, but it did trash itself in a most interesting way.
I'm still tring to figure out why it didn't trash the machine as it
went down.

TO THE PEOPLE WHO WRITE INSTALL SCRIPTS:

    don't do me any favors by automagically editing MY files

If I have changed /etc/rc* files, /etc/inetd.conf, /etc/services
/etc/* files to reduce my workload, what makes you think you can
change my files without screwing things up.

Either give me a nice simple script to run as root, so that it is
plainly obvious what gets changed, or give me documentation, yeah
docs, preferably up to date that explains what goes where.

I still have *%$(*%$^% memories of one particular install doc that
left out a crucial step in the install process.  Something tells me
they didn't check for that particular failure mode in their product
since their product forked off into never never land 8-).

BTW is is just me, or does it seem that Unix install documentation is
being written by people who have never administered a Unix machine? I
have experienced technical writers rewriting docs to be "pretty" and
totally screwing up the meaning of the sentence. In one case I know
of, the tech writer said the exact opposite of what should have been
said.

I guess the final word is: The install script must be run as root?
Just say: not on my machines you don't.

-- John


From: zaphod.mps.ohio-
state.edu!usc!wupost!uunet!charon.amdahl.com!amdahl!veritas!amdcad!su
n!exodus.Eng.Sun.COM!news2me.ebay.sun.com!seven-
up.East.Sun.COM!astro!kerskine Sat Jun 27 09:50:35 CDT 1992


David,

Presently we don't have the driver support necessary to run the CD-ROM
extensions with the SunCD and SunPC.  We're looking at providing this
in future releases.


Regards....Keith Erskine
           SunSelect Product Marketing


From: 
sdd.hp.com!usc!wupost!uunet!charon.amdahl.com!amdahl!veritas!amdcad!
sun!exodus.Eng.Sun.COM!news2me.ebay.sun.com!seven-
up.East.Sun.COM!astro!kerskine Sat Jun 27 09:50:49 CDT 1992

Phil,

The floating point performance you're seeing on the SX accelerator is
due to emulation engine.  When the emulator sees that an accelerator is
plugged in, it redirects all CPU emulation to the 486 on the
accelerator.  This includes the floating point (which on the software
session is a 80287) emulation.  The 486SX is an integer processor only
- it doesn't have an FPU like the 486DX.  With no FPU, your software
has to resort to software routines to do its floating point
operations.  You might want to consider purchasing a DX accelerator.


Regards....Keith Erskine
           SunSelect Product Marketing


From: zaphod.mps.ohio-
state.edu!samsung!noose.ecn.purdue.edu!orchestra.ecn.purdue.edu!ks Sat 
Jun 27 09:51:14 CDT 1992

We too have experienced many problems with PC software that uses 
CDRoms.

In addition, we have found SunPC to be inferior to SoftPC in the following
very important areas:

    - If the display is not a Sun console running xnews (like a X terminal),
      several trivial bugs make SunPC useless.
    - SoftPC has support for ASCII terminals, SunPC doesn't.

It would be nice if everyone in our organization had a Sun.  However, our 
situation
dictates a mixture of Suns, X Terminals, and ASCII terminals depending 
on the needs
and the budget of the individual.

SunPC has either removed or broken support for 2 of our 3 modes of 
operation.
For this reason, it is useless to us..  So much for "Open Systems"...

					Kirk Smith
					Purdue Agricultural Compter Network 


From: sdd.hp.com!zaphod.mps.ohio-
state.edu!rpi!clarkson!sun.soe.clarkson.edu!wargopl Sat Jun 27 09:51:55 
CDT 1992

kerskine@astro.East.Sun.COM (Keith Erskine - SunSelect Product 
Marketing) writes:

>Phil,

>The floating point performance you're seeing on the SX accelerator is
>due to emulation engine.  When the emulator sees that an accelerator is
>plugged in, it redirects all CPU emulation to the 486 on the
>accelerator.  This includes the floating point (which on the software
>session is a 80287) emulation.  The 486SX is an integer processor only
>- it doesn't have an FPU like the 486DX.  With no FPU, your software
>has to resort to software routines to do its floating point
>operations.  You might want to consider purchasing a DX accelerator.

Great.  No offense to my friends who work for Sun, but this really
bites.  Why offer the 486SX board at all?  Why not a 386SX/25 w/FPU?

Or, better yet, why not design the software better?  It's really easy to
test for the presence of a FPU...

C'me on Sun, this looks like a product that was rushed to market w/o
getting some seriously needed testing first.  

-Pete

--
----------
Peter L. Wargo        | wargopl@sun.soe.clarkson.edu | "In other words...
Documentation         |                              |  R.T.F.M..."
Enable Software, Inc. | GEnie mail: PSYCLOPS         |