Who's in charge here: Oracle or Unix?

Anthony DeBoer adeboer at gjetor.geac.COM
Tue Feb 12 05:16:56 AEST 1991


In article <11367 at jpl-devvax.JPL.NASA.GOV> brad at huey.Jpl.Nasa.GOV writes:
>I think there is another side to the coin, too.  I don't know that
>much about Oracle, but I know that Oracle is trying to provide a
>product to people that works across systems made up of diverse
>hardware and software.  If it isn't the case already, it will someday
>be the case that your Sun, PC, IBM, etc can all be on the same network
>running Oracle, accessing the same database.  Think about trying to
>provide a consistent interface between Unix and something like Pick,
>which is so different I've never wanted to try to understand it.  It's
>no wonder the Oracle people chose to take over administration rather
>than requesting it of the OS/administrator.  It makes sense for a big
>installation where database use is the big thing.
>
>In the sense that Oracle runs on all these different platforms and is
>the one constant in a diverse computing environment, maybe it is
>Oracle that is the OS and the lone Unix machine on the end of an IBM
>mainframe network is the add-on.

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.
-- 
Anthony DeBoer NAUI#Z8800 | adeboer at gjetor.geac.com   | Programmer (n): One who
Geac J&E Systems Ltd.     | uunet!geac!gjetor!adeboer | makes the lies the 
Toronto, Ontario, Canada  | #include <disclaimer.h>   | salesman told come true.



More information about the Comp.unix.admin mailing list