SCO doesn't sell UNIX

Rob Healey rhealey at digibd.com
Fri Nov 30 07:59:38 AEST 1990


In article <27519123.34A2 at tct.uucp> chip at tct.uucp (Chip Salzenberg) writes:
>According to ronald at robobar.co.uk (Ronald S H Khoo):
>>SCO Unix, on the other hand is a different kettle of fish altogether.
>>... because they've completely changed the semantics of just about
>>everything so much (because of their "security" <barf> "enhancements")
>>so it might be fair to call SCO Unix "Not a real Unix".
>
>I completely agree.
>
>C2 security cannot be disabled on "SCO Unix" systems.  It can be
>"relaxed," but that's not the same as "disabled."  The "SCO Unix"
>product is actually "SCO Unix-Flavored C2 Operating System."
>
	Ok, I'll bite. What IS a "real" UNIX? Minus the security
	SCO UNIX 3.2v2.0 seems pretty damn 3.2 to me, as much as
	any other "UNIX" system that claims 3.2. Isn't there a little
	problem with AT&T lawyers if you use "UNIX" in the name of your
	product and it isn't 3.2 or 4.x "certified"?

	Aside from the fact that everyone seems to have joyous
	glee in bashing SCO as often as possible and the security
	fiasco, WHAT in SCO UNIX 3.2v2 makes it incompatable with
	3.2 from a user's point of view? I program on a SCO UNIX 3.2v2
	box and security hasn't bothered me or my programs that much;
	i.e. gcc, gas, gdb and the usual development tools. SCO isn't
	being sued by AT&T for misuse of the UNIX name so why isn't
	it a 3.2 type UNIX?
	
	1) I can see where using an ANSI compiler might screw up old time
	   C programmer's code that uses uncasted incompatable types with wild
	   abondon.

	2) Drivers are obviously different. That can be good and bad.

	3) POSIX conformance creates some fun with signals, job control
	   and tty related stuff. But that will be a problem on ANY OS
	   that is POSIX conformant.

       I've done the first 3, now all you bashers who have obviously spent
       more time on SCO UNIX 3.2v2 than me fill in the rest!

       I anxiously await all the things I should watch out for.


	-Rob

Speaking for self, not company.



More information about the Comp.unix.sysv386 mailing list