Managers,
I got a late reply to my question of whether I should use the SVR4
environment (UNIX System V release 4) and it was quite informative
(thanks Pete) if a little partisan, so here it is.
Forwarded message:
> From: "Pete Lega, USG/System V Env. DTN 462-6025" <pzl_at_unx.dec.com>
> My original message:
> >----------------------------------------------------------------------------
> > Dear Managers,
> >
> > I am after an opinion from you all as to the wisdom of using the
> > SVR4 environment on our OSF/1 boxes.
> >
> > We have a number of users and administrators who are currently very
> > familiar with SVR4 and no-one who is familiar with OSF/1.
> >
> > It seemed like a good move to use the SVR4 environment.
> >
>
> - Your users will be pleasantly surprised to find most all of
> the familiar SVR4.0 commands and libraries available to augment their
> OSF/1 environment.
>
> > I have some concerns however and am debating whether we should instead
> > bite the bullet and use vanilla OSF/1 instead, for example:
> >
> > * will our support be more difficult both internally and through
> > digital due to the interaction between OSF/1 and the SVR4 environment?
>
> - The OSF/1 and SVR4 environment are supported and developed by the
> same group. Basically, if problems arise, a few basic checks
> like "type filename" tells you which version of a command is
> currently in use, as well as "what binaryfile" will tell you
> what versions of osf and svr4 library routines are in use.
> (anything with /usr/opt/svr4 or SVR4_COMPAT) in the id
> string identifies an SVE object)
>
> In terms of interaction, a user controls which environment
> is given priority by executing a simple ". /etc/svr4_profile"
> and then he can look at his environment variables to see
> if he's in it. The amount of orthogonal behaviored commands
> is relatively small, so a users will for the most part
> see additional SVR4 commands available to him. The base OSF/1
> system is XPG4 and SVID2/3 BA/KE compliant, so many of the
> commands in the base system already support a superset
> of familiar System V and BSD heritage options.
> >
> > * will layered products sometimes break as they perhaps don't expect
> > SVR4?
>
> I'm not sure which layered products you are referring to,
> but SVE (the System V environment) has static libraries,
> and must be explicitly compiled into new applications.
>
> Therefore binaries built on the base OSF/1 system will
> not be adversely affected by SVE, unless a programmer deliberately
> compiles them to take advantage of the SVR4 libraries.
>
> Shell scripts will generally run without trouble, but the
> use of hard-coded paths will force which version of
> a command is used. Letting the PATH variable to decide
> whether to pick cmds from a relative root of / or
> /usr/opt/svr4/
>
>
> SVE is tested against the other products on the Complimentary
> CD it is distributed on, and we've seen no problems, in terms
> of peaceful coexistance.
> >
> > * will SVR4 always be supported immediately with new releases of OSF/1
> > etc?
>
> SVE has been available ~1 month after every OSF/1 release,
> and from that point, is included in every OSF/1 kit.
> Note you will need to get an LMF license from DEC to unlock it,
> since it is an additional cost to the base DEC OSF/1.
> >
> > * should root be an SVR4 user, if not what real benefit do we get at
> > the administration level?
>
> One of the main features of SVE is the SVR4 sysadm menu-based
> system admin tool. It provides a user-friendly curses interface,
> ported from SVR4 to the DEC OSF/1 system resource naming semantics.
> It also provides the SVID3 services at the command level for
> sysadm functions, like manipulating user accts, backup and restores,
> orderly shutdown etc... There are also separate controlled
> logins for specific functions like powerdown, sync, and
> menu-only root/sysadm.
>
> >
> > Anyway you get the general idea of my concerns.
> >
> > Your thoughts?
>
> The SVE (SVR4) product is a great way to migrate both
> users and administrators from native svr4 systems to
> OSF/1. It gives the users the best of both worlds,
> SVR4 and OSF/1 (which is an industry leader in terms
> of timely standards compliance (XPG4, SPEC1170, SVID2/3),
> which makes the programmers migration easy. (plus a pile
> of online and printed documentation dedicated to migration)
> SVE also adds SVR4 application libraries, like the FACE
> FMLI interfaces, and SVR4 workalike libc.
>
> A vanilla SVR4 user will have a superset of SVR4 commands
> and libraries and OSF/1 commands, like useful new filesystems
> (advfs), and the DCE environment.
>
> All this, plus the advantage of running all this
> on an unprecedented screaming 100-200 mip AXP platform on
> their desktop. Im not aware of an SVR4 platform with
> such a fast hybrid environment.
>
> >
> > Regards
> > - --
> > <<<<<<<<<<<<<<<<<<<<<<<<<<< Nigel Harwood >>>>>>>>>>>>>>>>>>>>>>>>>>
> > << Post: Coles Supermarkets, PO Box 480, Glen Iris 3146, Australia >>
> > << Phone: +61 3 829 6090 E-mail: nharwood_at_coles.com.au >>
> > << FAX: +61 3 829 6886 >>
> >
> > ------- End of Forwarded Message
> >
>
> ------- End of Forwarded Message
>
>
>
--
<<<<<<<<<<<<<<<<<<<<<<<<<<< Nigel Harwood >>>>>>>>>>>>>>>>>>>>>>>>>>
<< Post: Coles Supermarkets, PO Box 480, Glen Iris 3146, Australia >>
<< Phone: +61 3 829 6090 E-mail: nharwood_at_coles.com.au >>
<< FAX: +61 3 829 6886 >>
Received on Tue Feb 07 1995 - 03:56:42 NZDT