Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!longway!std-unix
From: decot@hpda.uucp (Dave Decot)
Newsgroups: comp.std.unix
Subject: Re: Re: Standards Update, USENIX Standards Watchdog Committee
Message-ID: <671@longway.TIC.COM>
Date: 2 May 90 23:14:18 GMT
References: <650@longway.TIC.COM>
Sender: std-unix@longway.TIC.COM
Reply-To: std-unix@uunet.uu.net
Organization: Hewlett Packard, Cupertino
Lines: 45
Approved: jsq@longway.tic.com (Moderator, John S. Quarterman)

From: decot@hpda.uucp (Dave Decot)

Jeff Haemer writes:

> >     Parenthetically, I'll admit to being mystified by the dim view some
> >     folks take of the UPE.  I actually put programmer portability above
> >     program portability, since, when I go looking for new jobs I can't
> >     take our software with me, but do want to be sure that I can still use
> >     vi.

Doug Gwyn responds:

> It seems most unlikely to me that you have the option of specifying
> IEEE 1003.2 conformance when you interview with a prospective employer.
> I believe that the main point of these standards is to attain improved
> portability for applications.
> 
> Besides, why should I have to support both "vi" and "emacs" on my systems
> when we're all using "sam" instead?  It gains me NOTHING (because imported
> software is not going to require these interactive facilities) and costs
> me a bunch.

I suggest that you learn the scope and purpose of the UPE (now known
as the User Portability Utilities Option, or POSIX.2a).  It has a
different focus than the base POSIX.2 specification, and is based
upon a refutation of what you assert above.

One of the primary motivations for POSIX.2a is the desire to have a
standard set of utilities that a user can learn once, and thereafter
be a "portable user" of those utilities.

Prospective employers can already ask employees whether they "know MSWord,
Lotus, and MacPaint", because those are industry-standard utilities.
The same treatment should be available for traditional UNIX tools, but
since there are different vendors of these, a common specification
is necessary.

Having attended the POSIX.2 committee meetings for quite a long time,
I quite concur with Hal Jespersen's representation of the SCCS/RCS issues
and the contents of POSIX.2b and .2c.

Dave Decot, HP
DISCLAIMER: This message represents only my views.

Volume-Number: Volume 19, Number 106