From: evans@ih82w8.zk3.dec.com (Marc Evans <Consultant>)
Subject: Re: OSF/1 vs SVR4 (and others)
Reply-To: evans@zk3.DEC.COM
Organization: Synergytics
Date: Mon, 13 Apr 1992 12:52:57 GMT

In article <1992Apr12.133031.15603@mintaka.lcs.mit.edu>, mjo@hal.gnu.ai.mit.edu (Mike O'Connor) writes:
|> In article <1992Apr10.193647.5528@news.larc.nasa.gov>
|> mln@sunkj.larc.nasa.gov (Michael Nelson) writes:
|> 
|> :original DEC info from: evans@zk3.dec.com (Marc Evans)
|> 
|> The chart below clearly sounds like a sales pitch from DEC.

Yup, it is. That is part of the reason that I asked the person that I
sent it to post a summary and have the net tear it appart. I want to
see where things *really stand*, not where one org. thinks they stand.

|> Since
|> their OSF/1 isn't mainstream production, this makes the table look a
|> bit skewed.  (In particular, I'd love to see the apps available for
|> DEC's OSF :).)

I guess that this depends upon the definition of "mainstream production".
I will work on getting the list of apps. I expect this to be quite long,
as DEC OSF/1 provides binary (executable/data) compatability with Ultrix
4.2* and therefore the vast majority of the products that exist on Ultrix
4.2* are usable out-of-the-box on DEC OSF/1.

|> AIX is up to 3.2, which has added functionality.  Also, did "Display
|> PostScript" or the like appear on here (since I'm thinking IBM)?

If PostScript is important to you, then you will be  glad to hear that
the X server that is provided with DEC OSF/1 provides the Adobe DPS
extension. This provides for PostScript in the X server and is used by
programs like the dxpsview (a PostScript file viewer).

|> :Available                       now     now     now     now     now
|> :OS
|> :  Kernel base                   OSF/1   BSD     BSD     AIX     SVR4
|> 
|> Why not just say "Mach" for OSF/1?

Because the kernel (as supplied by the OSF) has been modified to the point
that it is clearly not all Mach 2.*. Rather then having people think that
the OSF is trying to be 100% MACH 2.* compatable, the AES was created and
the OS (and other pieces) are governed by this specification. Yes, many of
the original MACH 2.* features have been preserved, if that is important
to somebody.

|> For that matter, is there a migration plan in place to have current
|> users using non-OSF/1 move toward OSF/1 gracefully?

Yes, in the case of DEC OSF/1. In fact, with the documentation kit you
recieve a migration guide which has been developed explicitly for this
purpose. Also, above you will see that I said the Ultrix 4.* executables
can be used unchanged on DEC OSF/1 (well, there are a few exceptions, but
they are _very few_), providing for a reletively painless migration from
the Ultrix 4.* environment to the DEC OSF/1 envronment.

|> Compatibility:
|> 
|> This really means compatibility with respect to standards.  Both seem fully
|> compliant to the major standards.
|> 
|> -both SVR4 and OSF/1 both meet the following standards:
|>         ANSI C
|>         POSIX
|>         X/Open
|> -USL will have SVR4 comply with OSF/1 Application Environment Specification
|>  (AES)
|> -OSF/1 is compatible with the System V Interface Definition (SVID) (issue 3)
|>  for base and kernel extensions
|> -OSF is *not* SVID 5.4 compliant (?)
.................^^^^^^^^
(There is no such thing. There is SVID III which SVR4 is based upon, which I
 think is what you are trying to say here).

We should all be careful swinging around the X/Open, POSIX, and SVID terms without
carifying excatly what we mean by this. For example, each of these standards
provides for a number of different areas (X/Open has a base definition, and
a number of optional defintions, POSIX has a number of different groups such as
1003.1, 1003.2, 1003.4 etc, and SVID has 2 commonly refered to definitions,
SVID II and SVID III, both of which have simular clasifications to that found
in X/Open). Another aspect that needs to be considered is "compliance" vs.
"conformance". To be "compliant" does not necessarily mean that the software is
100% "conformant" with a particular standard.

Lets look through DEC OSF/1 conformance claims:

	AES level III (the highest level)
	SVID II (BA and KE sections only)
	Motif 1.1

By definition, to be AES compliant, you must also be compliant with the following:

	XPG/3 (X/Open level 3 base system)
	POSIX 1003.1-1989
	ANSI-C (also required by POSIX 1003.1)

DEC OSF/1 is also claiming compliance to POSIX 1003.4 (real time) (I think it
was draft 10) as well as a number of other areas (RFC's for example). I should
note that if a POSIX standard is in draft form, you can not claim conformance,
and therefore could only be compliant.

I see a reference to futures in the quoted section above. I'm not in a position
to really talk about this, but suffice it to say that the future for V.4* and
OSF/1 (from DEC anyway) will be very simular in the comformance/compliance arena.

- Marc
-- 
===========================================================================
Marc Evans - Marc@Synergytics.COM           | Synergytics     (603)635-8876
WB1GRH     - WB1GRH@W2XO.#WPA.PA.USA.NOAM   | 21 Hinds Ln, Pelham, NH 03076
---------------------------------------------------------------------------
                      Unix and X Software Consultant
===========================================================================
Newsgroups: isu.cc.vincent,comp.unix.questions