Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!bu-cs!bzs
From: bzs@bu-cs.BU.EDU (Barry Shein)
Newsgroups: comp.unix.wizards
Subject: Re: generating code to run multiple tar
Message-ID: <30420@bu-cs.BU.EDU>
Date: 29 Apr 89 14:56:50 GMT
References: <18927@adm.BRL.MIL> <8800012@gistdev> <882@twwells.uucp>
Organization: Boston U. Comp. Sci.
Lines: 29


>Another way to handle different capabilities is to...

But the problem is obvious, if they won't standardize their Unix's
what makes you think they'll standardize some method for a program to
discover their non-standardness? Swell, now every vendor will come up
with a variant for *this* so we'll need some sort of new capability to
figure out which capability system they're using...

Besides, who wants to standardize non-standard behavior, better to
standardize and be done with it...

This doesn't mean that every Unix will be identical, it means that a
capability approach will be useless since the enhancements and
modifications will be on the periphery of the OS and nearly impossible
to accomodate in advance by merely discovering the capability later.

That is, figuring out what machine type and/or vendor/version OS is
about all your program should need (if that...) since either your
program understands these unique extensions or it don't, merely
discovering that this machine has time-warp won't tell your program
how to use it. Simple, common differences like symlink support should
fade (or, go back to my first point.)
-- 

	-Barry Shein, Software Tool & Die

There's nothing more terrifying to hardware vendors than
satisfied customers.