[rescue] SGI Indigo2 & IRIX 6.5

der Mouse mouse at Rodents-Montreal.ORG
Sun Nov 30 22:20:47 CST 2008

> Why is one implementation better than the other?  Do you really
> -care- if some header file included three levels deep from
> sys/time.sh is in /usr/include/machdep or /usr/include/machine or
> /usr/src/sys/include/platform or whatever?

That particular case, no.  See below.

>>> There's no reason not to support "proprietary" UNIX.
>> There certainly is for me, as a software author.  [...]
> If a given piece of software is so shoddy that it can only run on one
> or two implementations of POSIX, barring some low-level dependency (a
> device driver), it's broken software.

If it were always a question of shoddiness, I'd agree with you.

It isn't.

Quite some years ago, I had a program that, among other things, did
pings and traceroutes.  When I went to try to build it on Linux, I
found that basically everything about the code to generate the relevant
packets was different.  The include file names were different.  The
struct tags were different.  Not just the field names but the very
topology of the structs were different.  For the packet sending and
receiving code, it wasn't a port; it was a rewrite.  The code for
neither could work on the other.

Which one was "shoddy", and why?  Or does that task inherently involve
a "low-level dependency" that excuses such differences?

Some applications can be written depending on nothing but standardized
interfaces.  I've tried to write applications that way, and I find that
it's possible for very few applications complicated enough to be
interesting - and possible within (my idea of) reasonable limits of
acceptable tradeoffs for even fewer.  Perhaps this just reflects the
kind of applications I tend to write - or, perhaps, the standards I was
trying to conform to ("the wonderful thing about standards is there are
so many to choose from").

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse at rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

More information about the rescue mailing list