From: eichin@tweedledumber.cyGNUs.com (Mark Eichin) Subject: Re: Is this becoming comp.linux.advocacy? Date: 9 Aug 1993 16:09:31
>> device support of SCO, Wanna compare SCO's compatibility list with
>> Linux's?
I hate to jump in like this, but I've got a real story here...
SCO doesn't seem to support ethernet cards. Oh, sure, there's a long
compatibility list of network interfaces -- *one* of which is an
ethernet card (3c503.) They've got token ring, x.25, other random
stuff... but they don't have NE2000, or any other ethernet card that
linux did. (I was looking for a card to use under both, because I
actually had some SCO development to do -- and SCO simplified the
choice by only supporting one card :-)
While we're at it, how about compilers that actually work? I
still don't have a native-tools build of Kerberos under SCO, because
cc botches an extension from char to int, so I *have* to use gcc,
which means that customers who rebuild from sources also have to...
And just how many laptops does SCO support? The PS/2 mouse
driver doesn't even work on a Dell 450 *desktop*...
And all those groups selling Linux CDROM installations... I
wish someone would do that for SCO! (SCO + ODT == 45 floppies, and SCO
has one of the *slowest* floppy drivers I've ever used. It may manage
to be slower than DOS itself... linux has a very fast floppy driver
(track buffering etc.) so maybe I'm jaded by it -- Oh Well...)
Oh, and you mentioned something about hardware drivers. Guess
you've missed all of the people here who have gotten free hardware
from vendors in order to get drivers written...
Sure, Linux may not be your "conventional" market, with freely
available source code being the norm rather than the exception. But
we've got an environment where problems get fixed anyway... and a lot
of people who've been burned by environments where things *don't* get
fixed.
_Mark_ <eichin@athena.mit.edu>
MIT Student Information Processing Board
Cygnus Support <eichin@cygnus.com>
ps. The expression is (after macro expansion)
switch ( (unsigned int) *(rpkt->dat+1) & ~1) {
rpkt->dat is char*, it fetches the char into AL, then masks EAX and
switches on that... leaving the upper 24 bits of EAX as garbage... so
the switch always fails.
pps. cross-posts limited to c.o.l since I don't read the other groups.
They weren't relevant anyway.