dvb@emisle.uucp (David Van Beveren) (04/14/91)
========
Thanks to all the news readers that responded to my question. I grabbed some
postings from the net, and combined with the mail responses I got, there were
over 50 responses in all, from over 35 different people.
The one-line summary is this: People who have SCO Unix are satisfied with it.
Now, Everyone who wrote and said they were happy with it mentioned several
bugs with the system. I guess this is probably true for any piece of software.
However, my original impression that SCO is completely hopeless has been
changed. I still feel that ISC would be better for software development, but
SCO isn't really so bad for users of the word-processing type who just need a
terminal.
=======
Peoples opinion is that support for SCO unix seems to be better than ISC. I
have never had a problem with ISC support, so I can't qualify that statement.
=====
Since my original posting, my customer got SCO and is trying to install it. He
is having a terrible time. bug: The TCP/IP was unlimited user license and the
core was 1-2 user license. Installation of TCP barfed completely here and
support told them to get the multi user core. $$. Nice touch.
=============================================================================
Major Bugs Noted:
================
1. Security system - Apparently, the C2 security features get in the way of
doing many things conveniently:
The main complaint with SCO unix is the alleged security
features. They make it very, very difficult to get some types of
work done. Setting up cron jobs, and starting non-root daemons,
and verifying that users know passwords, and preparing at jobs,
and doing setuid calls all seem to have problems. Starting cron
doesn not work from a terminal.
2. Make - One respondent noted that you cannot do a make when the sources are
mounted via NFS. The date-dependency checking gets all screwed up.
3. Curses cannot handle 8-bit characters.
4. Disk performance slower than other competitors.
5. X server supports only 16 colors.
6. Finger does not report correct information regarding
permissions on a tty.
7. Getty release 1.0 would accept a RETURN at the wrong
bps rate and act as if a BREAK had been received. This
was "fixed" in 2.0, making login more difficult for users
using a bps rate different from the default rate. (A modem
that supports dual bps rates solves the problem since the
modem and computer always talk at the same rate.)
8. 14 character file names could not be renamed. An SCO patch
fixed this.
9. Release 1.0 of the system admin shell did not permit some
account information to be changed, contrary to the docs.
10. The C shell lacks features I expected. This is not a software
bug, though.
11. Permissions for several directories are wrong. Some email
packages (elm), UUCP and Usenet software may not work without
the permissions being corrected.
12. SCO's docs for configuring MMDF, the mail agent, leave a bit to
be desired. (A major understatement.) After finally (I think)
figuring out MMDF, it works quite well.
13. When I decided to install the network modules (TCP/IP, Ethernet...),
the system refused all logins, even from root. I had to scrap it all
and start over.
14. Several bugs appeared when I set the login shell for root to be
/bin/csh instead of /bin/sh.
15. Some day, for no apparent reason, root started getting invaded
by E-Mail messages from cron complaining about a bad HZ value.
16. - Limited to only 4 SCSI harddrives. We went to SCSI under Xenix
because it would allow something like 14 drives in a system, and
now Unix allows only four. With 1G drives getting cheaper, this
may not be a problem, but I liked the notion of a 14G 386 box. :-)
17. - SCO's NFS doesn't seem to be completely compatible with HP's NFS
(the only other NFS system we have). I've heard it has trouble
with other's also.
18. - SCO tried too hard to retain a "Xenix feel" to some of the sys
admin stuff, meaning that some things might be "in their Unix
place" or "in their Xenix place", or sometimes (the worst of all),
in both places (e.g. start up stuff can be done with either Unix's
rc2.d scripts, or Xenix's rc.d scripts).
19. I would first say don't use tar, it skips empty directories, and they
may be needed to make things work. A new version might have cured that,
20. Debug and line numbers is screwed up for cc. If a file (foo.c)
contains embedded #line directives from more than file, you get all
sorts of warnings when compiling and/or linking. I've pretty much
given up on trying to track down the precise cause.
21. Problems with Trailblazer 9600Baud Modem (Recent news thread)
22. Daylight savings time not working correctly. (Recent News Thread)
Original Posting:
=================
>There has been a lot of talk about how horrible SCO Unix really is compared to
>other PC Unixes. I have used ISC for 2+years and am relatively happy. Today a
>customer told me he wants to order SCO. My first thought was OH NO, its full
>of bugs, and generally horrible. Then I started thinking, and realized I don't
>know what these bugs really are, if they exist at all.
>
>Please send me descriptions of all SCO bugs you know about. I want to know how
>bad this product really is. Also, if you think it is great, let me know. I hope
>I get lots of mail on this one. I will give it a week, then post my findings.
>Please, give me some dirt I can use to convince my customer to get ISC. I know
>it is what I want, I just don't know why :-)
>
================================
ronald@robobar.co.uk (Ronald S H Khoo)
aw1@stade.UUCP (Adrian Wontroba)
wht@n4hgf.Mt-Park.GA.US (Warren Tucker)
flon@pollux.usc.edu (Scott Simpers)
Ian Geoffrey Sergeant <inas@cs.uow.edu.au>
Jack Cloninger <teqsoft!jmc@uunet.UU.NET>
steveo@world.std.com (Steven W Orr)
Michael Squires <mikes@iuvax.cs.indiana.edu>
sixhub!davidsen@crdgw1.ge.com (Wm E. Davidsen Jr)
Erik Fortune <erik@gogoman.sf.ca.us>
<sysop@mixcom.COM> (Dean Roth)
cellar!toad@uunet.UU.NET
laurana!ppaone@uunet.uu.net (Phil Paone)
fred@cdin-1.COMPU.COM (Fred Rump)
"Robert E. Laughlin" <ico.isc.com!bel@trout.nosc.mil>
count!chip@uunet.UU.NET (Chip Salzenberg)
Ian Searle (uw-beaver!sumax!polari!ian)
drolet@drolet.cam.org (Jean-Jacques Drolet)
rhealey@digibd.com (Rob Healey)
macleod@cmllab.rgb.sub.org (Connor MacLeod)
rbraun@spdcc.COM (Rich Braun)
paulz@sco.COM (W. Paul Zola)
steve@edm.isac.CA (Steve Hole)
rk@theep.boston.ma.us (Robert A. Kukura)
jim@tiamat.fsc.com (Jim O'Connor - IT Manager)
davidsen@sixhub.UUCP (Wm E. Davidsen Jr)
lerman@stepstone.com (Ken Lerman)
tanner@cdis-1.compu.com
bernd@pfm.rmt.sub.org (Bernd Hennig)
sl@van-bc.wimsey.bc.ca (Stuart Lynne)
gt2186a@prism.gatech.EDU (COBIA,FRANK NAYLOR)
john@sco.COM (John R. MacMillan)
chip@chinacat.Unicom.COM (Chip Rosenthal)
newbery@stout.atd.ucar.edu (Santiago Newbery)
macleod@cmllab.rgb.sub.org (Connor MacLeod)
ptran@hydra.unm.edu (Michael Burg)
Michael Squires <mikes@iuvax.cs.indiana.edu>
gemini@geminix.in-berlin.de (Uwe Doering)
tim@dell.co.uk (Tim Wright)
iverson@xstor.com (Tim Iverson)
scott@phlpa.UUCP (Scott Scheingold)
Responses with minimal edits (Long):
================================
ronald@robobar.co.uk (Ronald S H Khoo)
SCO's 3.2.0 Dev Sys terminfo curses seems to go crazy (*) when fed
8 bit characters -- Does anyone know if it's fixed in the rev 2.0
Dev sys, and if so, does anyone know how much the upgrade co$ts,
and more importantly, what the part number is ? (I got a *real dumb*
supplier -- quoting part numbers is the only way to get any sense
out of him -- and don't ask me to change suppliers -- managment
directive sez "buy from this sister company or else buy nothing" :-( )
Thanks for any help.
--
(*) "crazy" in this sense: with this program -
$ cat foo.c
#include <curses.h>
main()
{ initscr();
addch(0243);
refresh();
endwin();
}
$ cc -DM_TERMINFO foo.c -ltinfo
I expect a pound sign on an ISO Latin 1 terminal, or a u-acute
on a PC console. Instead I get a flashing blinking screen full of
carets. Sigh. Strangely enough, it *does* work when I add a -xenix
flag, but then GDB doesn't. Sigh.
===============================
From: aw1@stade.UUCP (Adrian Wontroba)
I believe that the dev system upgrade costs approximately 200 pounds. I'm
afraid that I do not know if it will fix your curses problem, nor the part
number. Phone SCO and ask?
================================
From: wht@n4hgf.Mt-Park.GA.US (Warren Tucker)
The bits above the 0x80 bits are attribute bits in 3.2 curses
and include blink, underline and color. Look at /usr/include/tinfo.h
at the A_..... definitions and the man page for curses.
There is an A_ALTCHARSET bit you can set, but you may utlimately
be disappointed in using the high 128 video characters.
I only tried for three days before giving up (wanted to use
the ruling characters). I tried the 'acs' stuff and everything
else in TFM, terminfo.src and header files, but with no luck.
I am still interested in doing this one day. Until then,
I use the termcap curses, which does not support color or a
host of other nice things, but you can write any video ROM
character from 0x20 to 0xFF.
======================
From: flon@pollux.usc.edu (Scott Simpers)
Organization: Quality Software Products
We are having a peculiar problem with sendmail, and I would
appreciate any ideas, suggestions, or solutions.
Sendmail is running on an SCO ODT 1.0 system, which is our UUCP
gateway. The problem appears sending UUCP mail from other hosts on
our Lan to UUCP sites. It works fine delivering, via SMTP, to all
our local machines, and sometimes works OK when sending, via UUCP,
to other hosts.
The probem is that it will someimes get into a state where it says
"Cannot exec '/usr/bin/uux' errno=13". This doesn't seem to be a
problem when sending UUCP mail from the local (ODT) system, but
rather when another systemon our networkis attempting to get it to
send UUCP mail. Once it gets into this state where it will only
send local UUCP mail, the only solution appears to be to kill and
restart sendmail.
The permission on /usr/in/uux are:
---s--x--x 1 uucp uucp 63408 Dec 09 1989 /usr/bin/uux
so it should be runnable by anyone.
I have run out of ideas. Please reply via email, and I'll summarize
for the net if anything useful surfacs. Thanks.
=========================
From: Ian Geoffrey Sergeant <inas@cs.uow.edu.au>
it supports X11R4, and motif no problem.
if i had to say some single thing that annoys me about SCO it would
be the attempt at providing security and auditing. the existance
of a login uid stops things like su, cron working as they should,
without providing any additional security.
this couldn't really be considered a bug, more a misfeature.
ian.
===================================
From: Jack Cloninger <teqsoft!jmc@uunet.UU.NET>
Although there were one or two annoying little problems with early versions
of SCO Unix, these were cleared up with release 3.2 version 2.0. This is an
excellent Unix implementation. I have been using SCO Unix for over a year now,
and the 2.0 version for several months. I have had no problems at all. SCO
supplies hardware drivers for a wide range of peripherals and they supply
an excellent development system. I've been very satisfied. I now work for
a company that sells SCO products, but I purchased SCO Unix for my home machine
while working for a company that had no connection whatsoever with SCO products
except that we used SCO Xenix for cross-development work. My experience has
been overwhelmingly positive, except that SCO support seems to be overwhelmed
so that when you do have a question or problem it can take a while to get
help. Also I am not too thrilled with the cost of SCO support. The Unix
is great though.
I have been using Unix in one implementation or another for over 12 years,
starting when I worked for Bell Labs in 1979.
Hope my impressions help.
==================================================
From: steveo@world.std.com (Steven W Orr)
I can give you lots of input on both sides of this issue. I
personally favor SCO. If you want you can call me
617-327-3083.
There are a lot of really good reasons to go with SCO. I am in the
middle of convinceing a client right now to throw his ISC stuff away
and purchase new SCO licenses.
--
=======================================
From: steveo@world.std.com (Steven W Orr)
BTW: ISC and SCO are both based on X11R3. The only way to get to R4
is to build it yourself or by something thats not 386 based.
========================================
From: Michael Squires <mikes@iuvax.cs.indiana.edu>
UNIX is X11R3 and Motif 1.0, I believe. There are X11R4 servers but they
are not supported by SCO (third-party commercial versions are available,
I believe).
=========================================
From: Michael Squires <mikes@iuvax.cs.indiana.edu>
I run ODT 1.0, upgrade UFE; upgrading to 1.1 next month.
Negatives: reviews and others' experience suggest that SCO's disk
drivers are slower (see Personal Workstation review). The security
system is a nightmare if you are not used to it, could be a real plus
if your system is attacked.
Pluses: SCO now the most heavily supported by software vendors; $495 gets
you into the developer's program, then get email answers from SCO tech
staff on your problems; current releases seem to be pretty solid (my
system is connected to the Internet, MMDF is MUCH better than sendmail
for mail, works with lots of hardware (I'm running a 486/25 genuine
clone using the AMI BIOS and OPTI chipset).
I don't think there's much difference now; main difference will be for the
user if applications exist for which the vendor won't guarantee operation
on a non-SCO box. SCO is quite surprised at acceptance; seems to be a lot
of Fortune 500 interest.
I did not buy ISC because of the horror stories about lack of support;
SCO has been quite good in responding to my requests.
============================================================
From: sixhub!davidsen@crdgw1.ge.com (Wm E. Davidsen Jr)
The biggest problem was the overly strict security. The recent SCO SLS
fixes almost all of that. The only other bad thing is X11R3, and that's
not going to change for a while.
===========================================================
From: Erik Fortune <erik@gogoman.sf.ca.us>
SCO Unix is fine. I've been running Open Desktop
for over a year and I was quite surprised at how
"real" a unix it was. I'm from the workstation
world and I was expecting some bizarre hybrid thing.
The system is missing a few things I'd like, but
SCO claims they're on the way and I believe them.
ODT1.1. has job control (I should be upgrading in
the next week or two). An update to 1.1 sometime
this year should add long filenames and symbolic
links. X server performance is adequate, but they
only support 16-color mode for most VGA and SVGA's.
I write X servers for a living, so I don't mind that
much -- your mileage may vary. I've heard rumors and
I expect SCO's X server to get *much* better later
this year. Consider that vapor for now, of course.
Some things about SCO are "different" from what you'd
expect right away (e.g. MMDF vs. sendmail). For
the most part I've found the "different" thing to
be better once I learn it. If you have a network with
200 machines, one oddball might be annoying. If you
have one machine, I think it's easier to administer
SCO.
Lots of people complain about C2 security, but I haven't
had a lot of problems. My machine is personal and
pretty well isolated -- things may be different in
heavily used multi-user systems. I don't know.
SCO support has been wonderful! My support number has long
expired but I always get prompt useful answers to bugs
I report to support@sco.com. Several times I've asked
a question on a newsgroup or mailing list and gotten
phone calls (!) from SCO support to help me out.
All in all, I recommend SCO. I haven't really used other
PC unices in years (since System III), so I can't really
comment on SCO vs. other systems.
==========================================================
From: <sysop@mixcom.COM> (Dean Roth)
I'd rate SCO as "average." Release 1.0 had some bug. Release 2.0
has some bugs. I've found a few. None that I've run into have
been devastating, though some have been irritating.
Finger does not report correct information regarding
permissions on a tty.
Getty release 1.0 would accept a RETURN at the wrong
bps rate and act as if a BREAK had been received. This
was "fixed" in 2.0, making login more difficult for users
using a bps rate different from the default rate. (A modem
that supports dual bps rates solves the problem since the
modem and computer always talk at the same rate.)
14 character file names could not be renamed. An SCO patch
fixed this.
Release 1.0 of the system admin shell did not permit some
account information to be changed, contrary to the docs.
Many people have complained about the C2 security "features"
and lack of information and/or tools to override them. Tools
are being provided. Thus I do not classify as a bug, but a
major irritant.
The termcap and terminfo entries for a vt102's arrow keys
were different in release 2.0.
The C shell lacks features I expected. This is not a software
bug, though.
Permissions for several directories are wrong. Some email
packages (elm), UUCP and Usenet software may not work without
the permissions being corrected.
Otherwise my SCO system has been running smoothly for a year.
Increasing the amount of disk space from 330MB to 660MB (from
1 drive to 2) and rearranging the file systems helped a lot.
(I made volatile directories into separate file systems.)
This is a std. UNIX config problem, though, not something
unique to SCO's UNIX.
SCO's docs for configuring MMDF, the mail agent, leave a bit to
be desired. (A major understatement.) After finally (I think)
figuring out MMDF, it works quite well.
Overall I've had FAR FEWER problems with SCO's UNIX than with
Sun's early 386i machine - which would crash and burn regularly.
Particularly if the MS-DOS emulator was used.
===============
From: cellar!toad@uunet.UU.NET
I dunno. We've been running SCO Unix for about 3 months, and there are two
kinda irritating things we've encountered. One, SCO's MMDF is hard to
implement and doesn't work as installed due to permissions problems. Two,
we've crashed twice, we believe due to power failures, and when the system
comes up automatically, people can't log in; they get a "can't find database
information for your terminal" message.
This is a SCO-specific security, it seems. We haven't gone too far in trying
to resolve the problem yet, but it's especially irritating to us because
we're running a public-access site. I mean, of all files to consistently be
damaged after a power failure...
=========================
From: laurana!ppaone@uunet.uu.net (Phil Paone)
I rarly run across a "real bug" with SCO UNIX. There are some shortcomings
though.
First, the X server only supports 16 colors, no matter what the HW is.
Another problem is the size. To load a full OS and Dev System, you need
at least 200MB. For just the OS, at least 90MB. There are no shared libraries
for the X libs. The standard utilities are not linked with the c shared
libraries. It also needs alot of memory for things to work nicely. I have
*only* 8 meg and things can get very slow with all the swapping.
I have some other problems, which may be hardware related. Sometimes, the
serial port will start babbling with the serial port on the connected machine.
SCO denies this exists, but when it happens both machines stop. Sometimes
the video display crashes when I use my tape drive.
But, I do like the system. For what you get it is a good buy. With the
basic ODT setup, you get X Windows, Ingres, a full UNIX (single user) and
fairly good documentation (including on-line man pages).
One more thing, there is a new release of ODT due out now. We have ordered
it and are waiting. This is supposed to fix some of the annoying problems
I mentioned in the first paragraph (alas 16 X server is not one).
=========================
From: fred@cdin-1.COMPU.COM (Fred Rump)
You ask about SCO UNIX.
We are encouraging our Xenix users to convert at an appropriate
disk enlargement or change time. No hurry here.
At the same time all of our new sales go out as SCO UNIX.
We really have no problems with it.
fred
================
From: "Robert E. Laughlin" <ico.isc.com!bel@trout.nosc.mil>
I am not a great guru. I am just a user. I have had sysv 3.2 from
SCO for 18 Months and 3.2v2 for the last three months. I have had problems,
yes, but, most of those were because I did not RTFM. The few problems that I
had were responded to quickly by SCO at support@sco.com with either a fix or
a work around that was not bad. For example, there was a problem with lpr in
SysV 3.2 that I found. They sent me a copy of the lpr from Xenix that did not
have the problem. SysV 3.2v2 does not have the lpr problem, incidently. I see
a lot of flames about problems with SCO, they appear to be either a guru like
Chip Salzenberg (sp) or some body like me that could not be bothered to RTFM.
==========================
From: count!chip@uunet.UU.NET (Chip Salzenberg)
No dirt for scum.
(Editor's note: I am not sure if this is some kind of bug or an atack on me)
==========================
From: Ian Searle (uw-beaver!sumax!polari!ian)
Hello, in response to your survey question:
I have SCO UNIX 3.2v2.0 (started with 3.2.0) OS & DS om
a 386/25 with fpu, 14 inch VGA, NO X.
bugs: Had some problems with `cc' but learned to use rcc, and then
saw the light and picked up gcc (yay GNU). The problems I was
having with SCO/Microsloth cc, ld, cvtomf were fixed for the
most part by a SCO SLS (support level supplement), which are
free for the asking, and/or UUCP.
I have picked up other SLSs but never because of a bug, mostly
just to keep current, and get things like dialer programs
for 9600bps modems.
Overall I am happy with SCO, I do not pay for support, but even
so they will send me floppies with the SLSs on them and talk to
me if I have an SLS related problem. My system has been very
reliable, but I must admit I do not use it in a work environment.
The machine is not on 24-hours-a-day and supports only me.
I still don't know whether I should thanks SCO for not including
X, or be mad at them, maybe X will go-away and leave us all alone,
I get all the functionality I need with Emacs and multiscreens. It
seems obscene to occupy 50% of RAM with maintaing the display.
Overall I am very happy with SCO UNIX, the C2 stuff doesn't bother me at
all, and the product has been very reliable, BTW Korn shell is GREAT.
=========
From: drolet@drolet.cam.org (Jean-Jacques Drolet)
Our Institute had SCO Open Desktop running on one of its computers for a
few months. The core of Open Desktop is SCO Unix. This product has the
potential to be a great operating system, but it has several problems
which made us switch back to SCO Xenix. Its mail system, for example,
is MMDF. This is a powerful and flexible mail transfer agent, but its
maiboxes are incompatible with those of the more standard sendmail
delivery agent; it insists on separating messages with non-printable
characters which confuse several public-domain programs.
When I decided to install the network modules (TCP/IP, Ethernet...),
the system refused all logins, even from root. I had to scrap it all
and start over.
Several bugs appeared when I set the login shell for root to be
/bin/csh instead of /bin/sh.
Some day, for no apparent reason, root started getting invaded
by E-Mail messages from cron complaining about a bad HZ value.
The absence of a C compiler from the basic system is also annoying.
SCO wants you to pay a premium for its development system, which
contains several modules that an average user doesn't need. Why
don't they sell a moderately-priced basic development system
similar to that on Xenix?
============
From: rhealey@digibd.com (Rob Healey)
First, anybody who knows anything about SCO knows that the ISC/ESIX
zealots fail to mention their complaints are agaist an OS that was
replaced well over a year ago, 3.2v0.0 SCO UNIX.
SCO UNIX is different from ISC and the other UNIX's, that's the
main reason everyone loaths it. I like SCO UNIX MUCH better than
ISC, ISC feels like a rickty old bridge that's about to give
way to me. The ISC drivers strike me as being ragged and
unreliable. Fast wrong answers instead of timely correct ones, I
know which ones I'll choose.
I evaluated SCO UNIX 3.2v2.0 against ISC 2.2 last December to decide
which should go on our main box. ISC's SCSI driver kept hanging
the system or panicing, ISC's fix was to up the internal system V
file system buffer constant which only delayed the problem, not
fix it. The support for SCSI tape was pathetic at best. Alot of
the utils felt ragged and incomplete to me, I'm comming from
the high end UNIX level NOT the PC level used to all sorts of
bugs as being "normal" operating procedure. While ISC may be
somebody's idea of nirvana it is DEFINITELY not my idea of it.
ISC's attitude on fixing the SCSI problem scared the shit out
of me support wise, they brushed off the problem as a side effect
of cockpit error. I've delt with Sun, DEC, IBM, AT&T, Apple and
tons of software vendors in the past, NONE scared me like ISC.
2 months after I said fly with SCO UNIX, and everyone in the
dept. said I was crazy to pick SCO over ISC, the imfamous
bug came out that would have left our source code wide open to
anyone... Quite a few ISC zealot's had egg on their face and my
decision was finally accepted as being reasonable.
SCO UNIX 3.2v2.0 on the otherhand worked fine with our SCSI setup,
tape support was good, the utils don't feel like rickety old bridges
and the system gives me a comfortable feeling that there isn't
a nasty kernel/driver bug lurking out there... SCO UNIX requires
you to take a week or two, REALLY read all the manuals and learn it.
Once you learn it, it's as good or better than the other UNIX
offerings. The next release will allow you to finally chuck the
$%^%$^ C2 security BS. The SLS's basically have nullified the
effect of C2 except for people who have to program /etc/passwd
code. V3.0 will fix that too. V3.0 will also have symlinks and
a flexname filesystem, all the features a sysadm could ask for...
I would say sit down and take a good look at 3.2v2.0 SCO UNIX,
it's not as bad as it's made out to be.
========
From: rhealey@digibd.com (Rob Healey)
ISC doesn't currently ship X11R4 either, ODT 1.3 will be X11R4 based
but I'm not sure about the braindead Motif stuff. I also thing
OpenLook is braindead so don't attack. Real UI don't tell ME how
I should think or do my work, they give me the pieces and *I*
decide how they go together.
Anyways, my workstation is running SCO UNIX 3.2v2.0 with 3.2v2.0
development and NFS 1.0. I've added gcc and gdb because I can't
stand sdb and the two normal compilers aren't ANSI enough for me.
I run X386 with a Tseng labs ET4000 based card and a NEC 3D monitor.
Unfortunately, I am stuck with a VERY old version of TCP/IP so the
socket based X connections are shakey when huge amounts of data
is xfered. I run TCP/IP 1.1.0 over 56K SLIP to our main box. The
STREAMS pipes work fine. So, X386 DOES work with the most recent
SCO UNIX and development system. Assuming you have Motif 1.1 source
you could get that working as well.
SCO UNIX allows you to mount DOS disks as normal file systems, good
for bulk work that doscopy would be tedious with. VPIX works great,
even under X386. User level code and applications work fine except
for passwd manipulation, then C2 security gets in the way.
Non-SCO Kernel drivers may or may not work right, depending on what
they need to do. DOS cross development works great. SCO seems to
support any known SCSI or disk device that pretends to be a
standard WD device, i.e. IDE controllers. I use 2 IDE 80M drives
in my workstation and our main box is a SCSI Adaptec 1542b with 1
Wren 1.2G drive and 1 Wangtec DAT tape backup. Other boxes around
here uses EDSI controllers with no problem. Man pages are layed out
differently but you can get used to that after a while, you can
also add the man.[1-8] dirs if you really need them.
I think SCO get's more bad press than is really warrented,
==========
From: macleod@cmllab.rgb.sub.org (Connor MacLeod)
In article <1991Mar22.211749.13292@robobar.co.uk>
ronald@robobar.co.uk (Ronald S H Khoo) wrote:
| SCO's 3.2.0 Dev Sys terminfo curses seems to go crazy (*) when fed
| 8 bit characters
I think that's a problem of the addch(). Use addstr() instead and it'll
work. This "problem" is _not_ fixed in SCO U DEV 3.2.2.
==========
From: rbraun@spdcc.COM (Rich Braun)
I've gotten several criticisms for my posting inquiring about the identity
of the person quoted below, and I'd like to set the record straight.
Unfortunately the tongue-in-cheek nature of my posting didn't come across
at all; netnews can't possibly read the expression of one's face as a posting
is made, it only quotes the verbal statements made.
In my own defense, I'd like to re-quote the original article and ask
just how professional it really seems. It was basically a presumptive
attack on SCO, and my posting--contrary to some of the complaints I've
received--was intended to deter unwarranted attacks on vendors. I say
it was presumptive because the writer states he's not an SCO user himself.
Having been challenged before whenever I've criticized software that I've
not personally used, I've posted a challenge to this writer.
And I think a good healthy dose of skepticism *is* warranted whenever
information of interest to corporate marketing departments is posted or
requested on the Internet. The Internet's mandate is to provide a free
flow of information necessary for the research environment. Conflicting
with that goal is a need for security of information within the real-world
business environment. The only way for Usenet/Internet to prosper is to
balance these needs carefully.
It's my assertion that the posting below showed blatant disregard for
the ideals of the Internet, as I've interpreted them. Naturally, people
are free to disagree with my presumptions regarding these ideals. At the
very least, I have to admit that I was offended when I first read the
posting, even though I'm no particular fan of SCO (after all, I have to
*use* it every day!)
===========
From: paulz@sco.COM (W. Paul Zola)
The Colorado Memory Systems JUMBO tape is not supported by any SCO driver.
The QIC-40/QIC-80 driver will not work with this unit. This driver supports
the following drives for ISA class architectures:
Vendor Qic-40
====== ===============
Alloy APT-40/Q
Mountain TD44-40
Tecmar QT-40i
Wangtek FAD 3500,3040F
While tape driver support is a very fluid thing, I am reasonably sure that
any floopy tape not in this list will not work with the QIC-40 drivers
supplied with ODT.
I believe that CMS has a driver for SCO UNIX systems: you'll have to contact
them to obtain a driver for your unit.
============================
From: steve@edm.isac.CA (Steve Hole)
>
> Sendmail is running on an SCO ODT 1.0 system, which is our UUCP
> gateway. The problem appears sending UUCP mail from other hosts on
> our Lan to UUCP sites. It works fine delivering, via SMTP, to all
> our local machines, and sometimes works OK when sending, via UUCP,
> to other hosts.
>
> The probem is that it will someimes get into a state where it says
> "Cannot exec '/usr/bin/uux' errno=13". This doesn't seem to be a
> problem when sending UUCP mail from the local (ODT) system, but
> rather when another systemon our networkis attempting to get it to
> send UUCP mail. Once it gets into this state where it will only
> send local UUCP mail, the only solution appears to be to kill and
> restart sendmail.
>
OK, Scott, you are not going crazy. I have noticed the identical
problem, except that I am running smail v3.19. First of all let me
refine the occurrence of the problem a little. The problem occurs on
our machine under the following conditions:
1. If I start sendmail from the rc as a an stmp daemon with the
following arguments:
/usr/lib/sendmail -bd -q1h
the any messages recieved via SMTP and routed to an external
connection via uucp will fail with a similar error message to the
one you show above. If I kill the daemon started by the rc, and run
it from the command line, everything works fine.
2. If I start smtpd via inetd.conf, it fails similarly every time.
Therefore, it would seem that smtp daemon processes started without a
controlling terminal cannot execute uux. I have absolutely no idea why.
Perhaps something in the environment of a process started from a shell
command line is required and not present when started from either the rc
or inetd.
For the longest time, I thought that it was some subtle bug in smail
that was causing the problem, but I no longer think so. The reason for
the change is that I have noticed several other intermitent problems
with the SCO Unix (both v3.2 and v3.2.2) uucp distribution. Here are
some of the problems that I see regularly occurring on the SCO Unix
machines we maintain.
Please note that all of these machines we are using either
/usr/lib/uucp/dialTBIT or /usr/lib/uucp/dialHA24 as the dialer. The
serial ports are standard UARTS that come with the machine (not a smart
card).
1. When ever cu or uucico dial out over a serial port that is running
/usr/lib/uugetty on it, as soon as uucico or cu acquire the port, the
open succeeds for uugetty as well! Doing a ps -e shows that both
uugetty and the dialer have acquired the port, and they proceed
to fight for the data on the port. This causes the uucico or the cu
to fail regularly.
3. The Sysfiles file does not function. If you try to use it, uuname,
cu and uucp refuse to recognize that the system names exist. Uucico
does recognize the name though, as you can slam a poll to the sites
named through the Sysfile. The equivalent configurations worked
perfectly under Xenix.
So I went looking around, and to my surprise, I found that every single
binary in the uucp distribution is a Xenix binary (Microsoft a.out
separate pure segmented word-swapped 386 executable).
Now I put on my theory hat. I have had problems in the past with
executables compiled as Xenix binaries when running on SCO Unix. GNU
emacs is a good example. While it worked fine most of the time, it
would occaisonally lock up, and often couldn't stat some of the
directories (especially NFS mounted directories). When I recompiled it
as a COFF binary, everything worked hunky dorry.
So I begin to wonder if there are some subtle incompatibilities that
show up here between Xenix binaries and the Unix kernel. SCO is
probably going to barf all over me for this, but I have checked the code
that I have, and I can see no reason why smail or emacs should have
behaved in the manner that they did. Not having the source for the uucp
stuff, I can offer no opinion about it (other than the implied one :-).
============================
From: rk@theep.boston.ma.us (Robert A. Kukura)
Most likely, if this is the problem I've seen before, incoming SMTP
mail is not being reliably delivered either.
Its not the controlling terminal or the environment, its SCO's
infamous security feature, the LUID, or login user id. The init
process that runs the rc scripts does not have one, and therefore the
sendmail daemon started from the rc script does not have one either.
This means that the kernel prevents the sendmail daemon from execing
/usr/bin/uux, which I believe (I'm not on an SCO system at the
moment), has the SUID bit set.
When a user sends mail, the sendmail that is invoked has the user's
LUID, so it is permitted to exec /usr/bin/uux, and delivery succeeds.
When mail arrives via SMTP for forwarding, its handled by the sendmail
daemon with no LUID and it fails. If you kill and restart the
sendmail daemon by hand, it has your LUID, and succeeds.
The solution is to give the sendmail daemon started by init an LUID by
editing /etc/rc2.d/S85tcp to read something like:
/bin/su root -c "/usr/lib/sendmail -bd -q1h"
I hope this helps.
=====================
From: jim@tiamat.fsc.com (Jim O'Connor - IT Manager)
As a user of SCO Unix, I'll give you my reasons why I'm using it, why I like
it (not necessarily the same :-), and what I don't like about it.
Why we use it:
- We were an established Xenix shop, moving from Altos Xenix on an
8086 box, to an Altos 80286 box, finally (after getting smart) to
SCO Xenix on a 386 PC.
- We have a substantial investment in Xenix binaries (286 and 386)
which work just fine as they are, so we wanted to retain their
use.
- If anyone was going to bend over backwards to make sure Xenix
programs would run correctly on their Unix it would be SCO.
- SCO offered discounts on their Unix when upgrading from Xenix.
What I like about it:
- Believe it or not, now that I've gotten used to it, I actually like
the enhanced security. Our accounting dept. runs on a 386 and
once we upgrade it to Unix I'm sure our auditors will jump for
joy with the new capabilities.
- So far the Xenix compatibility claim has been valid. No trouble
running old Xenix (even 286) binaries.
- The SCO Dev Sys allows us to cross compile for Xenix, so we can still
produce binaries for the few Xenix machines hanging around.
- Performance seems to be good, especially wrt disk I/O.
- The installation stuff has gotten much better over Xenix.
- Since it is Sys V 3.2, there is alot of software for it (although
this is true for ISC as well).
- I like SCO's method of dealing with console multiscreens better
than ISC's (it's been since 1.0.6 since I've touched ISC, though).
What I don't like about it:
- Limited to only 4 SCSI harddrives. We went to SCSI under Xenix
because it would allow something like 14 drives in a system, and
now Unix allows only four. With 1G drives getting cheaper, this
may not be a problem, but I liked the notion of a 14G 386 box. :-)
- SCO's NFS doesn't seem to be completely compatible with HP's NFS
(the only other NFS system we have). I've heard it has trouble
with other's also.
- SCO tried too hard to retain a "Xenix feel" to some of the sys
admin stuff, meaning that some things might be "in their Unix
place" or "in their Xenix place", or sometimes (the worst of all),
in both places (e.g. start up stuff can be done with either Unix's
rc2.d scripts, or Xenix's rc.d scripts).
There's probably more, but I guess there are the major points. From my
experience with ISC and SCO I've always been of the opinion that ISC would
make a much better workstation OS (i.e. for running CAD/CAM type stuff, better
performance with X windows, easier sys admin when you have lots of boxes like
you would in a workstation environment), whereas SCO is a better small,
stand-alone system OS (i.e. for a box with lot's of terminals attached being
used as a departmental machine for WP, spreadsheets, and other character I/O
applications). When we were mostly an microprocessor based shop, I used to
say we had a "mainframe attitude in a microprocessor environment", and I felt
that SCO's OS fit this mold better. However, now that we have more 386 Unix
boxes cropping up, SCO's sysadm stuff makes it more difficult to administer
a group of machines using software tools (although, SCO has releases an OS
support level supplement that is suppoed to include tools to make it easier to
admin the system using programs, rather than doing it by hand).
Granted, I haven't used ISC's current release, but I'm a happy SCO customer
and don't really see any reason to consider changing.
==========================
From: davidsen@sixhub.UUCP (Wm E. Davidsen Jr)
In article <aris.670179095@tabbs> aris@tabbs.UUCP (Aris Stathakis) writes:
| I'd like to know the best way to do a backup so that I can recover from
| a FULL crash i.e. having to re-install on a different machine from
| a tape backup. I'm sure there are lots of ways to do it, like using
| the standard backup proggram SCO give you, but find it too inflexible.
Since you say Xenix and I've been running a bunch of these for years,
I would first say don't use tar, it skips empty directories, and they
may be needed to make things work. A new version might have cured that,
but there are other reasons.
=================================
From: lerman@stepstone.com (Ken Lerman)
1 -- Make doesn't know how to read a directory over NFS. A simple
test:
touch foo.c
make foo.o
Should work in a directory containing no other files. Does not work
over NFS.
2 -- Debug and line numbers is screwed up for cc. If a file (foo.c)
contains embedded #line directives from more than file, you get all
sorts of warnings when compiling and/or linking. I've pretty much
given up on trying to track down the precise cause.
===========================
From: tanner@cdis-1.compu.com
It isn't so much that SCO UNIX is full of bugs, though of course
the failure of ``custom'' to could be accounted one. It does not
swallow the same disks that xenix systems swallow.
Some xenix system calls don't work, and we had a piece of third-
party software which dumped core for no good reason, though it
was known to run under xenix. (It was the same binary.)
The main complaint with SCO unix is the alleged security
features. They make it very, very difficult to get some types of
work done. Setting up cron jobs, and starting non-root daemons,
and verifying that users know passwords, and preparing at jobs,
and doing setuid calls all seem to have problems. Starting cron
doesn not work from a terminal.
It's also slow.
In general, my advice is to avoid it. Go a long way out of your
way to avoid it. If someone offers it to you, just hit them very
hard.
Note: my views may be biased. We sell the product. Your milage
may vary.
=========================
From: bernd@pfm.rmt.sub.org (Bernd Hennig)
I have a great problem with the SCO UNIX 3.2.2 and cron. The following
is a job in /usr/spool/cron/crontabs/news:
15,30,40,00 * * * * /bin/su news -c "/usr/lib/news/bin/input/newsrun"
(at example, this is only ONE job..)
And the result is, that cron mails me:
Cron: can't set login UID
Your commands will not be executed
(on Interactive 3.2 or Microport 3.0e this works fine, on SCO UNIX 3.2.2 not..)
=======================================
From: sl@van-bc.wimsey.bc.ca (Stuart Lynne)
Just use:
15,30,40,00 * * * * "/usr/lib/news/bin/input/newsrun"
And make sure that it is in the crontab for "news". I.e.:
crontab -u news ....
============================
From: gt2186a@prism.gatech.EDU (COBIA,FRANK NAYLOR)
I use a computer running SCO UNIX when I am at home (not away at school).
The computer, on a seemingly random basis, will not let anyone log on because
it "Can not find database for this terminal" (not the exact message). When
the support agreement was still valid, I reported it to SCO. They admitted
that it was a bug in the security software that shows up on systems with a
large number of logins (we have 7 modems with people login in and out a lot).
They said that the /etc/auth/system/ttys file was being corrupted. We found
a way to fix it when someone calls complaining that they can not get into the
system. This is unacceptable for two reasons: 1) We don't want paying customers
to have to call and complain. 2) Unless the console already has someone
logged on, we can't get in either.
We got a small magazine from SCO (do not remember the name) that suggeted
to us that a bug fix had been made available on their BBS. When we follow the
procedure in the magazine for logging on the BBS, we get to a prompt that says
"Shere=sosco", but then it seems to lockup.
When I called Tech Help, they said they had never used the BBS and
therefore they could help me. They also refused to talk to me about the
problem with being payed $100, even though we had reported the problem
during the 30-day free period. I do not think that we should have to pay
$100 to get a bug fix for a product that we payed more than $1000 for.
============================
From: john@sco.COM (John R. MacMillan)
I mailed this to the original poster, but I thought it might be of
interest to others.
The answer should probably be in an FAQ. Past distributions of SCO
MMDF have had the permissions set wrong, you should run:
/usr/mmdf/bin/checkup -p
and fix what it tells you to. (Actually, it will probably say certain
directories should be 707, but the group permissions don't matter so
777 is fine.)
Another couple of notes for elm: you should have elm use the fcntl()
locking, as that's how MMDF locks. Also, the locking code in elm that
does the fcntl() does not expect EACCES if it can't get the lock,
which is what SCO returns (as per the SVID), so you may want to add
that in.
========================
From: chip@chinacat.Unicom.COM (Chip Rosenthal)
In article <1991Apr02.184954.19405@sco.COM>
john@sco.COM (John R. MacMillan) writes:
>Another couple of notes for elm:
Also...if you want off-site messages to be replyable you need to
change the `ap=same' to `ap=822' in the appropriate channels.
========================
From: newbery@stout.atd.ucar.edu (Santiago Newbery)
I am trying to add the ODT-NET service to my *existing* SCO ODT 1.0.
First of all I ran the [custom] utility which installed the NET software.
After the message "Installation of SCO REX Runtime set complete." I am
returned to custom's main menu. The question is how do I get to the
section on "Configuring the Network Interface" that is detailed in the
ODT Installation Guide pp.83-86?
The manual seems to assume that ODT-NET is being installed at the same
time as the rest of ODT (I hope one can do this later). I am assuming
there is a script or set-up utility that can be run independently, but I
can't seem to find it.
BTW I have done "mkdev wdn" (I am using a WD8003E card) and that
installed the ethernet driver w/out problems.
===========================
rom: macleod@cmllab.rgb.sub.org (Connor MacLeod)
(For those who missed Marks article: he's got troubles when trying to
get SCO Unix 3.2.1 (ODT) driving his TBIT with RTS/CTS flow full duplex
at 19200 bd...)
I just had the same problem. It's just as the guy at Telebit said:
using the hardware handshake only in half duplex mode is ok for 99%
of all the data transmission. But...
I've got some dropouts when polling large files (it's the remaining 1%
I bet :>) and I decided to set up RTS and CTS flow. It didn't work at all.
<sigh>
I asked a few people around here and I was told to exchange the 16450
chips on my serial cards by 16550 ones. The NS16550A is able to run in
16 byte FIFO mode and this buffer stores the byte(s) in case the system
is on havy load and not able to get all the data from the modem in time.
The next step is to replace the original sio driver of the SCO Unix by
a public domain driver called FAS 2.08 (I can mail/post more information
about this driver if someone is interested in).
This driver is able to do the RTS/CTS flow in full duplex mode 100%!
Well. I haven't got the time to install the FAS driver so far but from
the moment on I replaced the 16450s all works fine (about a month now).
If anyone decides to replace his serial chips, too, make sure to get the
16550A! The 16550 chips have a hardware bug and the FAS driver will not
work with them...
=======================
From: ptran@hydra.unm.edu (Michael Burg)
I recently got a SCO XENIX from a friend of mine who purchased in 1989; however,
he has *NOT* even opened the package to install on his PC. I called SCO company
to ask if they can allow to upgrade from version 1.1.0 (too old) to the new
version (2.3.2). First, Doug Mcclenvon does not allow me to have it upgrade
because SCO POLICY said that the version 1.1.0 is too old EVEN IT HAS NOT
OPENED yet. This is outrage since it has not opened that is why my friend
does not upgrade it. Because it has not used that is why my friend does not
know how *GOOD* the SCO XENIX is. The reason is that he is too busy working
on his project for the last 2 years.
After Doug told me, I'm a bit upset. I told him that I will post this on the
net for everyone to know about SCO, he came back and told me that for my SAKE
he accepts this time with 50% off the purchased new version price, and I have
to send every dammed things to SCO.
Well, I read someone posted on comp.windows.x mentioned about the *VERY
HELPFUL* from SCO. But to me, it is *VERY SUCKED*, I think I go and do my
project on the SUN rather than getting the *VERY SUCKED SCO XENIX*.
My friend he paid about $2,500 for everything TCP/IP, Compilers ....And now
it is going to be trashed because I don't have that much of money to afford
one. And they don't allow to upgrade with lower price or exchange the old
version for the new version with the price different or a little charge.
I don't think I will ever want to use SCO XENIX anymore unless they come back
and give me a better deal. Because I don't have 1,250 bucks to upgrade!!!!
Now I know how helpful the SCO is!!!!!
====================================
From: Michael Squires <mikes@iuvax.cs.indiana.edu>
In article <1991Apr5.133123.11868@ugle.unit.no> knutta@lise.unit.no (Knut Alfredsen) writes:
>I am trying to install a Western Digital ethernet card under SCO Unix, but the
>thing will not work properly. When the kernel is relinked after the installation
>, I get an error message:
>
>/./etc/conf/pack.d/kernel/space.c, line 310 unknown size
>ERROR: space.c will not compile properly
I got this error after installing UFE and then installing something else.
Apparently you need to re-install UFE (for SCO ODT 1.0) after installing
other components of Open Desktop 1.0. At least this made the error go away.
===============================
From: gemini@geminix.in-berlin.de (Uwe Doering)
>I am having a problem that I am not sure how to handle. Maybe some of you
>can help.
>
>I am trying to get FULL DUPLEX hardware (RTS/CTS) flow control working on
>SCO ODT 1.0 (unix version 3.2.1). I am not having much luck. The modem is
This is a common misunderstanding of how RTSFLOW works under SCO UNIX (and
Xenix as well). SCO implemented a half duplex type of hardware flow
control, as it is described in the original RS232C standard. That is,
RTS signals the modem whether there are any characters in the _computer's_
output buffer. If there are none, RTS is low, otherwise it's high. This
won't work at all if the modem is configured to use full duplex hardware
flow control. In this mode RTS signals the modem that the computer is
ready to receive characters. As far as I know, there is no way to get this
working with the original SCO sio driver, as it isn't designed for that
type of handshake.
> [detailed problem description deleted]
>Now, I spoke with a tech support rep at Telebit, and he said that there was
>a limitation with SCO Unix that when you run a port at speeds greater than
>9600, RTS/CTS does not work in full duplex mode. He said 9600 or below it
>works fine. Well, I tried this at 9600, and the exact same behavior occurred.
>I tried this on different serial ports; same thing. I am using a straight
>25-pin cable with serial port as DTE and modem as DCE. The fact that it also
>fails on 9600 baud makes me suspect that something else is fouled up here.
Yes. The port speed has nothing to do with your problem.
>Any help and/or suggestions would be greatly appreciated. I am sure I am
>not the only one to run into this. I do know about FAS 2.08, but I am really
>not sure how to implement it into the SCO scheme of 'uugetty' and the post
>dial/connect reset (dial -h .....). Ideas on that welcome too.
FAS 2.08 is currently the only dumb port driver that is capable of full
duplex hardware flow control (at least I think so). Therefore, you can't
solve your problem without FAS as long as you don't want to buy an
expensive "intelligent" card. You should be able to use FAS as a plug-in
replacement for the sio without having to change your setup. This would
only be necessary if you would want to use FAS's extended features
like dialin/dialout on the same line while using `getty' etc.
Note that the RTSFLOW (as well as the CTSFLOW) works in an SCO compatible
way under FAS 2.08. But you can enable full duplex hardware flow
control via the minor device number for a port. In this mode, RTS/CTSFLOW
are simply ignored and hardware flow control is always enabled. As a
side effect, your software can use hw handshaking without even
knowing that there is such a feature in your UNIX kernel. No more
worrying about whether a program knows about the RTS/CTSFLOW flags or
not.
===================
From: tim@dell.co.uk (Tim Wright)
This is a help plea. We have a user who is trying to install SCO ODT 1.0 on
a Dell System 325D. The kernel gets as fas as saying 'G12', then reboots.
I'm given to understand that phase 'G' is concerned with setting up interrupt
handlers and hence this is interrupt 12. The newer Dell Systems have a
PS/2-style mouse (part of the keyboard controller), which uses interrupt 12.
Is it possible that ODT is detecting this and erroneously assuming that it
is on a PS/2 ??? Is there a fix/should they get ODT 1.1 ?
===================
Fnrom: iverson@xstor.com (Tim Iverson)
In article <1991Mar26.231914.26740@lunatix.uucp> robert@lunatix.uucp (Robert Sexton) writes:
>I anybody running cnews successfully on SCO UNIX. when I get it
>compiled, it has really terrible problems with holes in history.pag,
>which implies problems with dbz...
I've been up and running since January under Cnews and SCO Unix. There's a
trick to it, though; you probably don't want to compile Cnews with
Microsoft C (cc). Try using AT&T's compiler (rcc) and you'll have much
better luck. You'll have better luck still using a version of gcc 1.39
that's been patched for #pragma pack.
==================
From: scott@phlpa.UUCP (Scott Scheingold)
I have noticed that some of my cron jobs are running an hour later
than they are normally run. Example uucp.cleanup is supposed to
run at 23:45 but it is running at 00:45 instead. This has occured
since the swich to EDT. The system swiched the time on sunday
just like we would change the clocks automaticly. Now not all the
jobs are running late just some. Have I come across a bug with
SCO UNIX SYS V/386 Rel. 3.2.2. Or is there something that I should
do to get things back on track (besides a reboot of the system).
I was supprised when I found the clock had changed. I am just glad
that I didn't have anything of real importance that needed to be
run at a specific time. My next question would be when we switch
back to EST will this become a problem once again.
--
David Van Beveren INTERNET: emisle!dvb@ism.isc.com
EIS ltd. Professional Software Services UUCP: ..uunet!emisle!dvb
voice: (818) 587-1247fred@compu.com (Fred Rump) (04/17/91)
dvb@emisle.uucp (David Van Beveren) writes: >The one-line summary is this: People who have SCO Unix are satisfied with it. Reading the various responses I get a different message back. It seems that satisfied is a bit of an understatement. >However, my original impression that SCO is completely hopeless has been >changed. To what? The respondents plainly tell you that SCO has a better product. Did you wish to listen or was your query mere propaganda? >I still feel that ISC would be better for software development, but >SCO isn't really so bad for users of the word-processing type who just need a >terminal. A bit condescending wouldn't you say? With roughly 80% of the world-wide market one would have to be pretty dumb to want to swim upstream and claim the minority view is better. Or is it that everyone else is wrong? >Peoples opinion is that support for SCO unix seems to be better than ISC. I >have never had a problem with ISC support, so I can't qualify that statement. But perhaps you should listen to the advice of your peers? Maybe they DO know something you don't. >Since my original posting, my customer got SCO and is trying to install it. He >is having a terrible time. bug: The TCP/IP was unlimited user license and the >core was 1-2 user license. Installation of TCP barfed completely here and >support told them to get the multi user core. $$. Nice touch. Seems perfectly logical to me. That's what the license says. If anything, call it a bug in the buyer's logic. If he's your customer, you offering professional software services, should have known what was required and installed the software for your customer. Whatever you do don't blame the customer or SCO. All in all, the original post had a trend in it that seems not to have changed even after all the advice from the net. So? Why bother? >EIS ltd. Professional Software Services UUCP: ..uunet!emisle!dvb Fred PS OK, I admit to being biased, but based upon overwhelming evidence. How about you? -- Fred Rump | Home of Brother John Software CompuData, Inc. | SCO Advanced Product Center 10501 Drummond Rd. | Bang: {uunet dsinc}!cdin-1!fred (800-223-DATA) Philadelphia, Pa. 19154| Internet: fred@COMPU.COM (215-824-3000)
ronald@robobar.co.uk (Ronald S H Khoo) (04/17/91)
dvb@emisle.uucp (David Van Beveren) writes: [ A summary ] Thanks for posting a summary. However I felt that it was still a bit one-sided. Some of those problems were generic ones (ie not specific to SCO) and I think it would have been in good taste to mention some of the things they *do* get right (like, for example, making bugfixes available free in a way which you can browse *without* having to buy support) Anyway, here's a bit of comment from me. I've done my fair share of SCO bashing before, let me try to address some of the problems from the other point of view :-) > 2. Make - One respondent noted that you cannot do a make when the sources are > mounted via NFS. The date-dependency checking gets all screwed up. A fix for NFS related make problems available free by anon UUCP or FTP. It's lng 261. I *suspect* that it deals with this problem. > 3. Curses cannot handle 8-bit characters. There is a generic (ie NOT SCO's FAULT) System V bug to do with certain aspects of 8bit curses usage. Specifically addch() is broken. Having worked around that, you *can* use 8 bit stuff with SCO's curses. Someone from SCO actually mailed me their suggested fix, ie. to code around addch() by using addstr() instead. Thank you for taking the trouble. > 10. The C shell lacks features I expected. This is not a software > bug, though. And ksh is bundled, so you have no excuse using csh :-) > 15. Some day, for no apparent reason, root started getting invaded > by E-Mail messages from cron complaining about a bad HZ value. This is probably due to point 14. Anyone who gives root a shell other than the standard unix shell is asking for trouble anyway. On *any* system. It's just slightly worse on SCO's :-) > 19. I would first say don't use tar, it skips empty directories, and they > may be needed to make things work. A new version might have cured that, Tar from *any* vendor does this, other than GNU tar with the appropriate options, or some possibly commercial backup programs that have little to do with tar. If you want the directories, what's wrong with using cpio ? > 21. Problems with Trailblazer 9600Baud Modem (Recent news thread) I've not had problems running mine at 19200. But then, it's not on a dumb standard port on a machine with TCP. I *have* run it on a dumb port with a standard SCO driver, without TCP, at full speed, no problem. > 22. Daylight savings time not working correctly. (Recent News Thread) I thought Paul Zola posted SCO's fix to this one ? Here's the relevant portion from SCO's database, probably in complete violation of their copyright :-) Anyway, this problem stems from Xenix heritage. For their old customers, it's arguable that maintaining extra Xenix compatibility is a plus. People who want new technology probably want SVR4 anyway :-) -- begin excerpt from SCO's fix. CAUSE: The installation script, /etc/tz, writes to /etc/TIMEZONE, the TZ environment variable, and holds information in a bad format. For example, a comma is placed in the string just after the daylight savings timezone name, instead of a semi-colon. The manual page for TIMEZONE(F) is correct. SOLUTION: Edit the file /etc/tz and change the line (line 476): tz=$stname$sthours${dst:+$smname$smhours,$sdate,$edate} so that it reads: tz=$stname$sthours${dst:+$smname$smhours"'\;'"$sdate,$edate} ^^^^^^ Run /etc/tz and set up the timezone as before. Log out and log back in again so that the changes may take effect. -- end of excerpt from SCO's fix. -- Ronald Khoo <ronald@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)
pauld@stowe.cs.washington.edu (Paul Barton-Davis) (04/18/91)
I worked on ISC 2.0.2 and 2.2.[01] for about a year, doing device
driver work (well, actually adding a complete kernel subsystem to
support a 25MIPS RISC coprocessor with 16MB of RAM and its own
SCSI interface) as well as developing 10MB of custom software
including a "graphical" shell (as graphical as curses(3) gets) with
limited job control, oddles of shell scripts, and lots of
code that uses read-write optical drives. I wouldn't even try to
defend ISC - V/386, like all system V's, is not even close to the
most basic BSD offering, and ISC's support was awful. There are
serious bugs in the TCP/IP implementation (which despite claims to the
contrary, were still not fixed at the last release), and you should see
what they used to do in NFS when a client tries to do a mvdir (:-(((((
However, generally, it was a workable, fast-ish system that worked
reliably once you got used to a few significant problems. As for SCO:
\begin{flame} I've been working on SCO for about 2 months (now
part-time and fading) The only good thing I have to say about SCO is
that they ship the device driver manual with the development system. I
don't know what Fred has been trying to do with his SCO system, but my
experience has been TERRIBLE. The whole V/386 thing is ridiculous -
the manual is full of Xenix references, and even the libs keep saying
"must be linked with the -lx option" (which links the xenix
libraries). comp.unix.wizards has been talking a lot about bloated
code: SCO has *two* shared memory systems, and two semaphore systems
!!! The security stuff is a joke - who ever heard of an "expire"
option for users that can't be undone ? If it was called "lockout" -
OK. Then you find that root can just edit the relevant tcb file, and
you can get back in - the only way if you were setting up an account
and mistakenly expired the user ... The boot sequence sucks, although
at least they let you choose single user as it comes up, which ISC
does not. I have to sit in front of the system as it boots, which
might be normal for many systems, but if you're writing a driver and
reboot 30 times a day, its awful ... The csh is broken, the default
keyboard mapping is brain-damaged (by default they eliminate Alt-<key>
combinations, and Ctrl-<arrow key> is not the same as <arrow-key> -
try using emacs with that :-() and only root can reset the key mapping
for a multiscreen (surely the default file should apply to ALL
multiscreens, not just the console). The startup file problem ("xxx:
cannot execute") is ridiculous, and the documentation on kernel
rebuilds is awful (they supply all of AT&T's IDD tools, but fail to
mention their use, and providing a hack-and-a-half called "configure",
surely a candidate for the Unix program with the most confusing set of
option flags in existence). Looking through the "value-added
extensions", almost all fall into the "code bloat" category. They
changed fdisk from its DOS-style interface, even though its existence
is owed soley to DOS via the BIOS boot nightmare.
I want to add a general comment on V/386 systems: I'm getting REALLY
REALLY tired of the profusion of <some-company's-acronym>ix varieties.
I don't know quite how much work ISC, SCO, Esix, or anyone else has
done on the kernel, but its about time for these companies to sell
their stuff as additions to System V/386, not as my-xxx-ix/386. I know
that there's no obligation to be kernel-compatible, but one of the
attractions of V/386 systems is the plethora of cheap hardware that
can be hooked up them. I've been making a comfortable living out of
writing device drivers and other system software to use these things,
and I'm getting really tired of worrying about the day when
SCO Unix/386 != Interactive Unix != ....
Most clients and other folk I know have one central question, as
evidenced on this list: what's the difference ? My responses to date
have been to stress that they all stem from the same AT&T System V/386
port, but have had a lot of stuff added, mostly as user processes and
commands, but a few kernel enhancements (and mindwarps) have been
added too. One day soon, they won't all be kernel-equivalent either,
as one company decides to go beyond replacing the disk driver (as ISC
did) or adding C2-Security (as SCO tried to do). Someone will decide to
change something more fundamental, and suddenly, there will be even
more significant differences than there are now.
I don't know how to fix this - the same thing has happended with BSD,
but maybe if it was stopped before it started ... wait, its already
started.
Enough ..
\end{flame}
\begin{summary}
I support the notion that for word-processing it might work, but for
systems programming and serious Unix users, its a joke.
\end{summary}
--
Paul Barton-Davis <pauld@cs.washington.edu>
UW Computer Science Lab ``to shatter tradition makes us feel free''sef@kithrup.COM (Sean Eric Fagan) (04/18/91)
In article <1991Apr17.210627.4517@beaver.cs.washington.edu> pauld@cs.washington.edu (Paul Barton-Davis) writes: >I support the notion that for word-processing it might work, but for >systems programming and serious Unix users, its a joke. Uhm, I consider myself a serious systems programmer and unix user, and I *like* sco's unix (3.2v2). It's stable (I had kithrup up for three months, before I decided to reconfigure the kernel). I will admit, I picked up a lot of how to use it by osmosis, from over two and a half years of working at sco, but I still find that it takes very little to maintain kithrup. (My latest endeavor, putting kithrup on a network, has taken me about two days to get working properly. All without *any* documentation, only talking to some bsd-knowledgeable folks.) >the libs keep saying >"must be linked with the -lx option" (which links the xenix >libraries). The libraries do that? Wow. Not on kithrup. On kithrup, some of the manual pages say that needs to be done with some things, but I largely ignore them. Note that this is done for old makefiles and the like: xenix (of which there are a *lot* of systems) had a seperate library (-lx: the xenix library) which had some extensions. AT&T picked them up, finally, for 3.2, and there are good reasons for using libx instead of putting them in libc. (Personally, I'd like to see libc about 50% smaller, and would be willing to live with a few dozen more libraries to get rid of all that namespace pollution.) >comp.unix.wizards has been talking a lot about bloated >code: SCO has *two* shared memory systems, and two semaphore systems >!!! Uhm, so? If I remember correctly, internally, they're very much the same code. The interface is different, but they do the same thing. Blame AT&T on that. Xenix had shared memory and semaphores, and then AT&T went with a different interface, and people like you complained about it, so xenix went and had both. Note that *all* versions of 3.2 for the '386 have both, so why are you blaming sco? >The security stuff is a joke - who ever heard of an "expire" >option for users that can't be undone ? It can. Try looking at SLS's; the information was posted here. But, as always, I keep forgetting: it's easier to run off at the mouth like a damned fool than to actually see if your vendor is listening to your complaints. >The boot sequence sucks, although >at least they let you choose single user as it comes up, which ISC >does not. I have to sit in front of the system as it boots, which >might be normal for many systems, but if you're writing a driver and >reboot 30 times a day, its awful ... I find nothing wrong with the boot sequence. Since I've done quite a bit of kernel development, I've had to reboot often. And it's never bothered me. (Or don't you realize you can have a serial console, or can reboot from any terminal? No, of course not, that would require actually seeing if such things work, and it's much easier to be an idiot.) >The csh is broken, The csh is *old*. And, yeah, it's broken. I've ported tcsh, as have others. No real problem. Tell people at SCO you want it, and, if they get enough requests, they will make it available. But, again, that's probably more work than flaming. >the default >keyboard mapping is brain-damaged (by default they eliminate Alt-<key> >combinations, and Ctrl-<arrow key> is not the same as <arrow-key> - >try using emacs with that :-() and only root can reset the key mapping >for a multiscreen (surely the default file should apply to ALL >multiscreens, not just the console). 1. I agree about the alt, but that's because I use emacs. I run 'mapkey /usr/lib/keyboard/cv' at init stage 2. 2. I like the fact that Ctrl-<arrow> is different. 3. I know why only root can remap keys; there is a system-wide table (I believe it works for sunriver stations and the like as well), and you wouldn't want joe blow to change someone else's keyboard, would you? Oh, I forget, you would. 4. I don't know what you mean by "ALL multiscreens, not just the console." On kithrup, and almost every system I've seen, the only multiscreesn(tm) were on the console. (The exceptions had sunrivers and the ilk.) >The startup file problem ("xxx: >cannot execute") is ridiculous, Never seen that. >Looking through the "value-added >extensions", almost all fall into the "code bloat" category. So I guess you don't like job control, bug fixes? Most of the extensions (with the exception of the c2 stuff, which I dislike rather much, although I don't notice it at *all* since I applied the c2 SLS) are for POSIX or some other standard. (I've grown to *hate* standards, because I've had to work on implementing them.) >Someone will decide to >change something more fundamental, and suddenly, there will be even >more significant differences than there are now. Too late. The POSIX stuff SCO added is incompatible with the stuff ISC added. Point in SCO's favor: AT&T and Intel have adopted sco's implementation for the iBCS thingy; as a result, ISC is not compatable with the standard, and any isc-written COFF program will not work on future releases. Oh, well. (*I* kept urging people to get in touch with ISC and get some coherency. Mostly I mumbled to myself, I will admit.) There is a very violent message below, so you may not want to read it. As I am no longer an SCO employee, I can finally freely say this: you are an asshole. I (and my coworkers) worked *hard* on the product, and we didn't always get to implement the decisions we wanted. But we tried, and we listened (even if we didn't always reply), and 3.2v2 is a *very* nice (stable and quick) OS, and 3.2v3 will be even better (although there are some things I don't like about it). Most of your complaints are addressed in SLS's; a polite note to someone (such as myself) who posts regularly is usually answered politely, and I tried to push any major bug reports through. (I circulated Chip's complaints about the C2 stuff around quite a bit, and I believe it actually influenced things.) *You* on the other hand, just inspire contempt, and drive people (at sco) from responding or posting. How would *you* like to be told that something you've devoted the better part of two years is a piece of shit? Over and over and over? And even after working on it and making it better, all anyone ever does is complain. And most of them are *idiots*: they don't read the manuals, they don't try thinking, they just *bitch*. Most of the vocal complainers in this group make me mentally sick. May you get the OS you deserve. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
fred@compu.com (Fred Rump) (04/19/91)
pauld@stowe.cs.washington.edu (Paul Barton-Davis) writes: >\begin{summary} >I support the notion that for word-processing it might work, but for >systems programming and serious Unix users, its a joke. >\end{summary} Let me ask you just one thing. Who do you think SCO and other *UNIX resellers market to? OK, another. Where do they get their money to pay their programmers etc? The check is ultimately paid by the customer. We all work for him. Nobody is out there marketing and fussing for 'systems' programmers as there will never ever be a perfect world for such people. It's the nature of the beast. As far as serious UNIX users - who the hell are they? Is that the person who never smiles while running accounts receivable? How serious can one get running a piece of computer software? Remember, the idea is never to run UNIX. It is to accomplish a task whose ultimate goal is to help produce a better bottom line. The best advice for people who are so full of knowledge about the faults of a system is to sell somebody else on the idea to make it better. There should be tons of money available for the better mousetrap - if it could produce a better balance sheet. fred -- Fred Rump | Home of Brother John Software CompuData, Inc. | SCO Advanced Product Center 10501 Drummond Rd. | Bang: {uunet dsinc}!cdin-1!fred (800-223-DATA) Philadelphia, Pa. 19154| Internet: fred@COMPU.COM (215-824-3000)
rcd@ico.isc.com (Dick Dunn) (04/19/91)
fred@compu.com (Fred Rump) writes: > dvb@emisle.uucp (David Van Beveren) writes: > >However, my original impression that SCO is completely hopeless has been > >changed. > To what? The respondents plainly tell you that SCO has a better > product. Did you wish to listen or was your query mere > propaganda? In essence, he asked whether he was in for major hassles with SCO. The answer was no; it works. He didn't poll all the {AT&T;ISC;ESIX;Dell;...} users for a general evaluation; there's no sense trying to read one into the responses he got to a restricted question, posed to a particular subset of the group. > ...With roughly 80% of the > world-wide market one would have to be pretty dumb to want to > swim upstream and claim the minority view is better. Or is it > that everyone else is wrong? 1. Aren't invented statistics handy when you want to prove a point? The 80% figure for SCO includes Xenix (and MOSTLY Xenix, in fact) - which is a separate product (discussed in a separate newsgroup) and irrelevant to this discussion. I don't have current figures, but the last I heard, from last winter, ISC's 386 UNIX was outselling SCO's UNIX. So now what? 2. By your reasoning, McDonald's makes the world's best hamburger--one would have to be pretty dumb to want to swim upstream and claim that some minority burger-maker could do better, right? Similarly, Geraldo Rivera is the world's best investigative journalist; New Kids on the Block are the world's best musicians;... (No offense intended to SCO! I'm just trying to make the point that "most popular" != "best".) Look, the products from the various vendors have various advantages-- nobody is an absolute stellar runaway or they'd have all the sales; nobody is abysmal or they'd be out of the business. Moreover, you can do a lot better at figuring out which product is better for *your* needs if you leave the vendor-flaming out of the discussion. -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...While you were reading this, Motif grew by another kilobyte.
ronald@robobar.co.uk (Ronald S H Khoo) (04/19/91)
sef@kithrup.COM (Sean Eric Fagan) writes: > It can. Try looking at SLS's; the information was posted here. And no other vendor makes their fixes so readily available. FTP, UUCP, pick your transport. Even a local London number too :-) > The csh is *old*. And, yeah, it's broken. I've ported tcsh, as have > others. No real problem. Tell people at SCO you want it, and, if they get > enough requests, they will make it available. But can you imagine the customer telling the front line folks "Well, yeah, one of your ex-employees says he ported it ... " :-) > >The startup file problem ("xxx: > >cannot execute") is ridiculous, > Never seen that. xxx is setgid and luid wasn't set. SecureWare strikes. No need to rehash the old stories about that one, surely? :-) [ ObFix: su root -c xxx instead of naked xxx. ] -- Ronald Khoo <ronald@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)
bill@wrangler.WLK.COM (Bill Kennedy) (04/19/91)
rcd@ico.isc.com (Dick Dunn) follows up: fred@compu.com (Fred Rump) follows up: dvb@emisle.uucp (David Van Beveren) writes about SCO: Dick makes some points that most isn't necessarily best and generally IMHO proves that sales volume doesn't guarantee superiority or applicability. I'm only following up a couple of sentences, so I've deleted the rest. >Look, the products from the various vendors have various advantages-- >nobody is an absolute stellar runaway or they'd have all the sales; nobody >is abysmal or they'd be out of the business. They _were_ out of business, maybe we need to find a silver stake and a crossroads for a sure fix. >-- >Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 > ...While you were reading this, Motif grew by another kilobyte. -- Bill Kennedy uucp {att,cs.utexas.edu,pyramid!daver}!ssbn.wlk.com!bill internet bill@ssbn.WLK.COM or ssbn!bill@attmail.COM
rfarris@rfengr.com (Rick Farris) (04/19/91)
In article <1991Apr18.063914.13111@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: > (My latest endeavor, putting kithrup on a network, has taken > me about two days to get working properly. All without > *any* documentation, only talking to some bsd-knowledgeable > folks.) I put off installing TCP/IP for about a year, because I was used to 3-day Novell installations under DOS. When I finally got around to installing it, it took about 30 minutes. But then I had docs... -- Rick Farris RF Engineering POB M Del Mar, CA 92014 voice (619) 259-6793 rfarris@rfengr.com ...!ucsd!serene!rfarris serenity bbs 259-7757
palowoda@fiver (Bob Palowoda) (04/19/91)
From article <1991Apr18.063914.13111@kithrup.COM>, by sef@kithrup.COM (Sean Eric Fagan): > In article <1991Apr17.210627.4517@beaver.cs.washington.edu> pauld@cs.washington.edu (Paul Barton-Davis) writes: >>Someone will decide to >>change something more fundamental, and suddenly, there will be even >>more significant differences than there are now. > > Too late. The POSIX stuff SCO added is incompatible with the stuff ISC > added. Point in SCO's favor: AT&T and Intel have adopted sco's > implementation for the iBCS thingy; as a result, ISC is not compatable with > the standard, and any isc-written COFF program will not work on future > releases. Oh, well. (*I* kept urging people to get in touch with ISC and > get some coherency. Mostly I mumbled to myself, I will admit.) This is interesting, how are they going to sell this product? Will it be an update? How much will it cost? When will the customer know when they need it? Why should a customer pay for it? How does this affect ESIX, and Dell UNIX products? What are the advantages? ---Bob -- Bob Palowoda palowoda@fiver.uucp | *Home of Fiver BBS* Home {sun}!ys2!fiver!palowoda | {pacbell}!indetech!fiver!palowoda | | 415-623-8806 1200/2400/19.2k TB+
rvdp@cs.vu.nl (Ronald van der Pol) (04/20/91)
sef@kithrup.COM (Sean Eric Fagan) writes:
Sef>So I guess you don't like job control, bug fixes? Most of the extensions
Did you ever ^Z, fg vi(1)?
Sef>Most of the vocal complainers in this group make me mentally sick. May you
Sef>get the OS you deserve.
SVR4?
--
Ronald van der Pol <rvdp@cs.vu.nl>dls@genco.bungi.com (Dave L. Smith) (04/21/91)
In article <1991Apr17.210627.4517@beaver.cs.washington.edu> pauld@cs.washington.edu (Paul Barton-Davis) writes: >\begin{summary} >I support the notion that for word-processing it might work, but for >systems programming and serious Unix users, its a joke. >\end{summary} Perhaps you would prefer having to work with VMS every day as I do. Believe me, there are reasons why people want System V/386 Unix. It's a very inexpensive replacement for those $200,000+ Vaxes. Yes, there is too much variety among the vendors (SCO, ISC, Esix, etc), but even VMS upgrades provide endless varieties and entertainment. They all come from the same company! As for me, I like SCO and use it also every day. It seems to be the most robust version I have used in terms of device drivers, support supplements, and utility programs supplied (including the Configure script which you don't care for - at least I can understand how to use it). SCO has probably the most experience in the 386 market place, and the biggest market share (so I've been told). As for System V, well, it has much better software availability than BSD Unix. Like it or not. So, in spite of the difficulties I have had with SCO products, I would recommend their Unix. If you don't like it, you can always use VMS :-( Dave Smith
sef@kithrup.COM (Sean Eric Fagan) (04/22/91)
In article <9765@star.cs.vu.nl> rvdp@cs.vu.nl (Ronald van der Pol) writes: >sef@kithrup.COM (Sean Eric Fagan) writes: >Sef>So I guess you don't like job control, bug fixes? Most of the extensions > Did you ever ^Z, fg vi(1)? Yep. Get the "clist" SLS; it also has a new vi on it that works properly with job control. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
peter@ficc.ferranti.com (Peter da Silva) (04/24/91)
In article <1991Apr16.183342.10185@compu.com> fred@compu.com (Fred Rump) writes: > dvb@emisle.uucp (David Van Beveren) writes: > >The one-line summary is this: People who have SCO Unix are satisfied with it. > Reading the various responses I get a different message back. > It seems that satisfied is a bit of an understatement. Reading the responses, I get a different message back. It seems that SCO is as buggy as all hell, but if you never do anything but run canned stuff you never excersize the bugs. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
peter@ficc.ferranti.com (Peter da Silva) (04/24/91)
In article <1991Apr18.063914.13111@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: > Point in SCO's favor: AT&T and Intel have adopted sco's > implementation for the iBCS thingy; as a result, ISC is not compatable with > the standard, and any isc-written COFF program will not work on future > releases. How does this jibe with Intel dropping direct sales of UNIX and passing it on to ISC? It's almost enough to make me want to try OSF/1. Almost. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
sef@kithrup.COM (Sean Eric Fagan) (04/26/91)
In article <MLYA0S7@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >In article <1991Apr18.063914.13111@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: >> Point in SCO's favor: AT&T and Intel have adopted sco's >> implementation for the iBCS thingy; as a result, ISC is not compatable with >> the standard, and any isc-written COFF program will not work on future >> releases. >How does this jibe with Intel dropping direct sales of UNIX and passing it >on to ISC? As *I* read it (not being privvy to the thoughts of anyone in the industry, mind you), ISC consideres their 3.2 product to be obsolete, with the introduction of SysVr4. (They're probably right. I could see wanting to keep xenix, but I don't think there's as much a difference between 3.2 and 4.0 as there is between 2.3 and 3.2.) >It's almost enough to make me want to try OSF/1. Almost. SCOSF/1? 8-) -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
dvb@emisle.uucp (David Van Beveren) (04/26/91)
In article <I-XAL55@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >In article <1991Apr16.183342.10185@compu.com> fred@compu.com (Fred Rump) writes: >> dvb@emisle.uucp (David Van Beveren) writes: >> >The one-line summary is this: People who have SCO Unix are satisfied with it. > >> Reading the various responses I get a different message back. >> It seems that satisfied is a bit of an understatement. > >Reading the responses, I get a different message back. It seems that SCO is >as buggy as all hell, but if you never do anything but run canned stuff >you never excersize the bugs. >-- Thank you. I was trying to give SCO the benefit of the doubt. In general, people who have a product become accustomed to it and therefore satisfied with it. This is the case with SCO customers I believe. If you read the comments people sent me, the general theme is this: XXX works okay, once you get used to it. I am happy with it. XXX=c2 etc. ??? Why are you happy with it if it took time to get used to ??? XXX doesn't work, but they give you YYY (or, but YYY is PD) (XXX = csh, YYY=ksh) (XXX = cc, YYY=gcc) (XXX = X11R3 YYY=Roell X11R4) etc. If the people who sent those notes would read them again, and be objective, they would see what I mean. How can you recommend something, then say you don't even use it, (like cc, csh) or give some other disclaimer? The point about word processing should be taken as follows: Every unix can take a set of terminals and a bunch of word processsors. We here on the net are looking at other, more difficult things like networking, code development and system administration. Here is where SCO falls short. Final point about my customer. I have had nothing to do so far with the SCO installation, I am working on another project. I was asked for some advice. That is where my original query came from. I believe SCO with gcc, smail, Roell from the PD and VPIX from ISC is an OK setup. I don't think there is a satisfactory networking solution for any PC unix. Of course, I have been dealing with Decstations and SPARCstations recently, so I am used to stuff working out of the box :=) >Peter da Silva. `-_-' peter@ferranti.com >+1 713 274 5180. 'U` "Have you hugged your wolf today?" P.S. The summary generated more interest than the original query. Where were these comments when the original question was asked? The point about word processing should be takes as follows: -- David Van Beveren INTERNET: emisle!dvb@ism.isc.com EIS ltd. Professional Software Services UUCP: ..uunet!emisle!dvb voice: (818) 587-1247
peter@ficc.ferranti.com (Peter da Silva) (05/01/91)
In article <1991Apr25.180938.21875@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: > As *I* read it (not being privvy to the thoughts of anyone in the industry, > mind you), ISC consideres their 3.2 product to be obsolete, with the > introduction of SysVr4. Problem is, we have an installed base of software that needs SVR3.2, not SVR4. It involves device drivers, so we can't just run it on SVR4. Another problem with SVR4 is that it chews up even more RAM than SVR3. SVR3 has enough of an advantage over Xenix to make it worth some pain to upgrade. SVR4 just doesn't give us anything we really can't do without. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
dls@genco.bungi.com (Dave L. Smith) (05/02/91)
In article <1991Apr26.070424.2756@emisle.uucp> dvb@emisle.UUCP (David Van Beveren) writes: >Thank you. I was trying to give SCO the benefit of the doubt. > >In general, people who have a product become accustomed to it and therefore >satisfied with it. This is the case with SCO customers I believe. If you read Read your own message! You are 'accustomed' to your Decstations and SPARCs. > > >I believe SCO with gcc, smail, Roell from the PD and VPIX from ISC is an OK >setup. I don't think there is a satisfactory networking solution for any >PC unix. Of course, I have been dealing with Decstations and SPARCstations >recently, so I am used to stuff working out of the box :=) > How much did your Decstation and your SPARC cost you? I haven't seen any I would buy for my own use with my own income. Really, they are in a different class and should be recognized as such. They had better work out of the box for over $10K. Also, they were not made to support hundreds of other vendors' devices, as SCO and other 386 Unix vendors do, and so of course they will work with the hardware they are shipped with. People who use SCO and other 386 Unix products generally are trying to make it work on whatever they can afford, and naturally have some difficulties. Dave Smith
richard@pegasus.com (Richard Foulk) (05/04/91)
>How much did your Decstation and your SPARC cost you? I haven't seen >any I would buy for my own use with my own income. Really, they are in >a different class and should be recognized as such. They had better work >out of the box for over $10K. Not meaning to refute any of the points made here, I'd just like to note that considerable discounts on Sun gear are quite common (>35%). (Even with that price adjustment the Intel driven mongrels seem to win the price/performance shootout a lot of the time.) -- Richard Foulk richard@pegasus.com
wes@harem.clydeunix.com (Barnacle Wes) (05/13/91)
In article <1991Apr26.070424.2756@emisle.uucp> dvb@emisle.UUCP (David Van Beveren) writes: > Of course, I have been dealing with Decstations and SPARCstations > recently, so I am used to stuff working out of the box :=) In article <660@genco.bungi.com>, dls@genco.bungi.com (Dave L. Smith) retorts: % How much did your Decstation and your SPARC cost you? I haven't seen % any I would buy for my own use with my own income. Really, they are in % a different class and should be recognized as such. They had better work % out of the box for over $10K. Mr. Van Beveren must not have tried to use NFS on his DECstation if he is "used to stuff working out of the box." :-( Besides, if they made every version of unix identical, it would put those of us who know how to hack around until it works out of a job! :-) Wes Peters -- #include <std/disclaimer.h> The worst day sailing My opinions, your screen. is much better than Raxco had nothing to do with this! the best day at work. Wes Peters: wes@harem.clydeunix.com ...!sun!unislc!harem!wes
dvb@emisle.uucp (David Van Beveren) (05/15/91)
In article <265@harem.clydeunix.com> wes@harem.clydeunix.com (Barnacle Wes) writes: >In article <1991Apr26.070424.2756@emisle.uucp> dvb@emisle.UUCP (David Van Beveren) writes: >> Of course, I have been dealing with Decstations and SPARCstations >> recently, so I am used to stuff working out of the box :=) > >In article <660@genco.bungi.com>, dls@genco.bungi.com (Dave L. Smith) retorts: >% How much did your Decstation and your SPARC cost you? I haven't seen It didn't cost me anything. The machines are owned by my customers. My business owns several 386/33's and one 486/33 all running ISC. They are good for doing s/w development when I don't want to travel to the customer's site, but I must admit that the workstations have far superior development environments, like Saber. Even dbxtool is better than anything I have in x86 land. >% any I would buy for my own use with my own income. Really, they are in >% a different class and should be recognized as such. They had better work >% out of the box for over $10K. > >Mr. Van Beveren must not have tried to use NFS on his DECstation if he >is "used to stuff working out of the box." :-( Besides, if they made >every version of unix identical, it would put those of us who know how >to hack around until it works out of a job! :-) > Actually, I have been unsing a DECstation 3100 with drives NFS mounted from a Sun4, a Sparcstation running SunOS 4.0.3, a sun3 running SunOS 4.1.1, two other 3100's running different revs of Ultrix (4.0, 4.1) and a VAX running VMS 5.4. Also, there is occasion to mount a drive from an HP 9000/425 and from an Apollo. It all works perfectly and has ever since it was installed. I don't believe hacking around making it work is really a good way to spend customers' money when I am hired to develop software. > Wes Peters >-- >#include <std/disclaimer.h> The worst day sailing >My opinions, your screen. is much better than >Raxco had nothing to do with this! the best day at work. > Wes Peters: wes@harem.clydeunix.com ...!sun!unislc!harem!wes -- David Van Beveren INTERNET: emisle!dvb@ism.isc.com EIS ltd. Professional Software Services UUCP: ..uunet!emisle!dvb voice: (818) 587-1247