Path: utzoo!mnetor!tmsoft!torsqnt!geac!gjetor!adeboer From: adeboer@gjetor.geac.COM (Anthony DeBoer) Newsgroups: comp.unix.admin Subject: Re: Who's in charge here: Oracle or Unix? Keywords: Oracle, system, files Message-ID: <1991Feb11.181656.1496@gjetor.geac.COM> Date: 11 Feb 91 18:16:56 GMT References: <635@uswnvg.UUCP> <13640@vpk3.UUCP> <11367@jpl-devvax.JPL.NASA.GOV> Organization: Geac J&E Systems Ltd. Lines: 43 In article <11367@jpl-devvax.JPL.NASA.GOV> brad@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@gjetor.geac.com | Programmer (n): One who Geac J&E Systems Ltd. | uunet!geac!gjetor!adeboer | makes the lies the Toronto, Ontario, Canada | #include | salesman told come true.