Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!husc6!bbn!rochester!udel!princeton!phoenix!caromero
From: caromero@phoenix.Princeton.EDU (C. Antonio Romero)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Why unix doesn't catch on
Message-ID: <7697@phoenix.Princeton.EDU>
Date: 12 Apr 89 04:57:53 GMT
References: <7632@phoenix.Princeton.EDU> <256@jwt.UUCP>
Reply-To: caromero@phoenix.Princeton.EDU (C. Antonio Romero)
Organization: Princeton University, NJ
Lines: 62

In article <256@jwt.UUCP> john@jwt.UUCP (John Temples) writes:
>In article <7632@phoenix.Princeton.EDU> C. Antonio Romero writes:
>>Well, for one thing, not all Unixes come with C compilers.  I suppose
>>one could require that they did, but this would swell the size of Unix.
>True, but I can't imagine anyone having something as powerful as Unix without
>having a C compiler to go with it.  It seems like a waste.

Your average corporate type may object to having to pay for the C
compiler just so he can buy software; also, keep in mind that the juicy
market both sides in this battle will be going for is not a market of
developers-- therefore in principle (at least) the target customers
won't share your (or my) opinion that not having a good compiler around is
almost inconceivable...

Also, given the coming (or current, from what I've heard here)
binary compatibility among the flavors of 386 unix, this is a moot
point...

>>Third, if you're a developer, do you want to be sending the source for
>>that really nifty proprietary whatever you're selling all over
>
>Gimpel Software is making their PC-Lint product available in something called
>"shrouded source".  It lets you compile the software on your target machine,
>without being able to make sense of the source code.  I don't know how viable
>this technique is, but it seems like it could have possibilities.

An interesting idea.  I suppose they have some kind of encryption code
built into the compiler that takes something like crypt output and
decrypts it and feeds straight into the compiler... anything else 
(like some kind of tokenized representation for the code) might
prove too eay to crack.  Anyone know what they're realy doing?
(this would digress too far from the subject, so maybe split and
change the subject line if you respond to this one...)


>>We all hear horror stories about how resource-intensive OS/2 is, and

>I don't know how resource intensive OS/2 is, but I doubt it's any more so than
>386 Unix.  I would consider 4MB of RAM and an 80 MB drive as a _minimum_
>configuration under which to run 386 Unix with DOS Merge as a single user
>platform.  Yes, it will run in less, but not at what I would consider
>acceptable performance.  

That's a fair statement-- though I think that sets the memory
requirements considerably lower than OS/2 EE.  With some kind of
windowing environment, I guess they're about equal.

>But in this era of cheap hardware, I don't see minor
>differences in resource requirements as being a basis on which to compare 
>operating systems.  Trying to criticize an operating system like Unix or OS/2
>because it requires more resources than a monitor program like DOS is silly.

Well, I wasn't saying to compare it to DOS on these grounds-- DOS and
either of the others are simply too different for meaningful comparison.
I just wondered if Unix ran on 386 boxes with similar performance
on similar hardware.  Sounds like they probably are nearly equal.

>  Everyone should use the OS that best suits their needs.

Couldn't agree with you more.  

-Antonio Romero    romero@confidence.princeton.edu