Who's in charge here: Oracle or Unix?

John Macdonald jmm at eci386.uucp
Tue Feb 19 08:30:34 AEST 1991


In article <1991Feb11.181656.1496 at gjetor.geac.COM> adeboer at gjetor.geac.COM (Anthony DeBoer) writes:
|I think it is reasonable for a large application that will be the only thing
|running on a lot of people's boxes to provide a set of (for example, in the
|case of Oracle) Oracle "look-and-feel" tools for maintaining the system files
|that a lot of users can't be bothered with learning about.  That kind of
|hand-holding does have a market.  Not every site has someone like us
|available, and a lot of people would like to not have to ever think about
|Unix, just take their box out of the box and go in and use Oracle.  This
|creates the demand for turnkey systems with all the sysadmin functions
|automated.
|
|The other, equally important, side of the coin, is that such tools should be
|optional, in the case of an installation that does have the luxury of Unix
|gurus on staff.  If you have a big system and run a lot of applications,
|you're not going to let one of them take over the whole system.  The
|application should have documentation of exactly what it needs set up for it,
|but it should not have any requirement of ever being root itself, except for
|perhaps an install script that the sysadmin can review and ensure it won't
|break his/her system (see C-news' doit.root script, for example).
|
|So while such tools are a good idea for single-application boxes, they should
|not force you to use them.

Well put.  Even if you don't have gurus on staff, there is the
possibility that you might want to run *two* applications on
the same system.  If they both had the same high-handed approach
to subverting system administration they could get into some
interesting situations.

And as another point... it is totally asinine to build an
unnecessary system dependency into an application - system
dependencies mean that platform specific releases are required,
with concomitant porting delays for every upgrade and release,
and the danger of getting support dropped if your platform
becomes obsolete.  There are enough *system* suppliers working
hard at making system administration inconsistent from platform
to platform (Is it *value added* to have to remember yet another
way to do simple admin tasks, and to not be able to just use
previously working scripts?) without the application providers
getting into the act too.
-- 
Cure the common code...                      | John Macdonald
...Ban Basic      - Christine Linge          |   jmm at eci386



More information about the Comp.unix.admin mailing list