Return to BSD News archive
Xref: sserve comp.unix.misc:10552 comp.unix.pc-clone.32bit:5157 comp.unix.bsd:13102 comp.windows.x.i386unix:5877 biz.sco.general:9408
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!sgiblab!spool.mu.edu!sol.ctr.columbia.edu!hamblin.math.byu.edu!news.byu.edu!news.provo.novell.com!park.uvsc.edu!u.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Newsgroups: comp.unix.misc,comp.unix.pc-clone.32bit,comp.unix.bsd,comp.windows.x.i386unix,biz.sco.general
Subject: Re: SCO market share
Date: 16 Dec 1993 23:25:52 GMT
Organization: Weber State University, Ogden, UT
Lines: 127
Message-ID: <2eqqq0$mns@u.cc.utah.edu>
References: <2em4ds$n22@vanbc.wimsey.com> <2eocag$ce1@u.cc.utah.edu> <2eom4c$t2h@vanbc.wimsey.com>
NNTP-Posting-Host: cs.weber.edu
In article <2eom4c$t2h@vanbc.wimsey.com> sl@vanbc.wimsey.com (Stuart Lynne) writes:
[ ... someone said "commerical OSes are broken just as often as free ones ... ]
>>>That's a pretty sweeping statement.
>>>
>>>Can you please supply some quantifiable data, the metric's you're using,
>>>the method used to collect same etc.
[ ... discussion of how one commercial OS is broken given as an example ... ]
>What does this have to do with the statement "as commercial OSes clearly are
>{broken} just as often as free ones." ?
You're probably right -- we can draw no conclusion; I didn't read this as
a request for metrics. But by the same token you can not present the
conclusion that "commerical OSes are *NOT* broken just as often as free
ones" without the same metrics
>My personal opinion is that with a large piece of software (such as an OS)
>the longer it has been sold, the larger the user base, the lower the number
>"serious" bugs (i.e. showstoppers, prevent the system from being useful,
>panic etc type bugs). More users equals more bugs found, more time equals
>more bugs fixed.
This is opinion that many people disagree with. I happen to be of the
"higher availability of source code equals more bugs fixed" religion
myself, and having occasion to work within an organization where a
blatant bug can't be fixed even if it is a simple fix without following
a week long (or longer) procedure, I can say that the find/fix cycle
seems a lot faster in the free OS's.
>If we can agree that (for example) there are more users of SCO or Sun OS or
>Sparc than Linux or netBSD or BSD386. And that they have been in production
>mode for longer. So I would contend that they probably have less problems
>with them. Of course this is a personal opinion. I don't work for any of the
>above so I don't have access to their buglists, or customer counts.
I agree that there are more commercial OS installations then free OS
installations, and I agree with them having been around longer, but I
disagree with your major premise that "More users equals more bugs found,
more time equals more bugs fixed", or even that if it were acceptable,
that commercial OS's didn't have more bugs to start with.
In my opinion, very little innovation and research really occur in
commercial products because innovation and research do not impact the
bottom line. Similarly, a problem that one user has, or for which a
workaround exists is unlikely to be fixed in a commercial environment
-- a commercial OS.
I don't see very many commercial products which have taken advantage of
Heidemann or Rosenthal's statckable file system technology, for example.
The vast majority of the commercial work that is being done is DOS and
Windows centric. It has only take 12 years for Microsoft to be on the
verge (with Chicago) of bumping up the 8.3 filename limit.
Also in my opinion, commercial OS implementations give the users what
they need to do the work they need done -- and stop there, at the bare
minimum requirements. Nothing else impacts the bottom line. What
else can explain the "File system Survival Kit" for SVR4 mounting of
DOS and ISO (CDROM) file systems having come out of modified code
from the *BSD projects instead of out of the commercial UNIX vendors?
The added convenince was outside the scope of the minimal feature set
and so was ignored as not impacting the bottom line. This has GOT to
change!
>>Something being commercial no more enobles it than it being non-commercial;
>>broke code is broke code.
>
>Sure. But do you *seriously* believe that every user of SCO or Xenix or
>Solaris or (pick your favorite UNIX version) could install a PD UNIX
>tomorrow at 9:00AM and have everything up and running by suppertime? We're
>talking about a lot of users who barely know how to log in once they get it
>installed.
We are talking release engineering problems; I believe several of the
free UNIX clones are extremely close to this goal; the "Slackware" Linux
distribution is arguably closest, with the majority of the people in
that arena having come from the DOS area. But *don't* confuse a release
engineering with stability. Many venders ship operating systems pre
installed, and most SCO installations are done by VARs or VADs ...NOT
by end users.
Your argument falls flat, because I contend that very few of the "every
user of SCO or Xenix or Solaris or (pick your favorite UNIX version)"
group given could install "SCO or Xenix or Solaris or (pick your
favorite UNIX version)" under the same criteria -- starting "tomorrow at
9:00AM and have everything up and running by suppertime".
>I know *I* could install a PD Unix here and have lot's of fun. But I don't
>think it would be usable on our main machine. We'd have to get drivers for
>Digiboard and Adaptec 2742's. And DAT's, etc. Not too mention I'd have to
>recompile everything from scratch that we've worked on for the last five
>years under SCO. And implement a new set of sysadmin tools. And make sure
>it's secure. And of course once I'd done all that I'd be an netBSD sysadmin
>expert and I could probably make lot's of money locally doing that. Not!
The Digiboard and Adaptec 2742 drivers might be a problem; if the Digiboard
is a "dumb" model, then it'll work -- the AHA2742 controllers will be a
problem because Adaptec moved their microcode to user space and then
made licensing decisions that make a distributable source implementation
a matter of rewriting the microcode for the sequencer (an AIC-7770).
There is some indication that the 1742 put less of a load on the host in
any case... with a UNIX implementation, you want the main processer
offloaded anyway, so a trade in for the 1742 controllers instead may even
give you a performance boost, even under SCO.
*BSD supports DAT drives.
*BSD supports "execution classes" in Alpha code, and there is a non-
distributable Xenix loader module (it'd have to be rewritten for you
to use it) that is about 1500 lines of code, so your recompilation
issues may be about to go away -- you'd just run your SCO binaries.
The sysadmin tools available depend on what operations you think you'll
typically perform; I was aware of a project to make POSIX compliant
sysadmin tools, but I don't know where that has gotten to.
The standard security tools from the net should run without modification.
Regards,
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.