Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!asuvax!ncar!acd!pack From: pack@acd.uucp (Daniel Packman) Newsgroups: comp.unix.aix Subject: AIX vs standard unix Message-ID: <11640@ncar.ucar.edu> Date: 3 Jun 91 20:03:47 GMT References: <1991Jun3.173646.25682@ux1.cso.uiuc.edu> Sender: news@ncar.ucar.edu Organization: NCAR/Atmospheric Chemistry Division Lines: 30 In article <1991Jun3.173646.25682@ux1.cso.uiuc.edu> Paul-Pomes@uiuc.edu writes: >johan@dutnak2.tudelft.nl (Johan Haas) writes: > >>We are considering to replace our current Convex C1 with a mix >>of RS/6000 systems instead of upgrading to a Convex C2. > >I would closely examine the overhead of administering a RS/6000 system. >Why IBM gave us AIX instead of UNIX is beyond me. > Some of the differences in AIX seem perverse (eg, why not spell it f77 instead of xlf?), but most of the differences are attempts to make things better. I'd take the journaled file system over sys V or berekely any day. The shadow password file in /etc/security is a good thing. The philosophy of the odme database is fine in that it allows for faster binary formats for the standard ascii unix files. Some of the methods of accessing and dealing with these objects is a bit rough yet. One big unix problem is the lack of standardization of the adminstration. If smit, for example (anything that works would be ok with me), were a standard, it would help a lot of us admistrators who muck around in multi-vendor shops. One philosophical problem with smit or any high level adminstrative tool is that if anything goes wrong with an operation, one has to delve into low level error codes. Avoiding this problem almost means putting artificial intelligence into the error recovery code in smit. A problem. Dan Packman NCAR INTERNET: pack@ncar.UCAR.EDU (303) 497-1427 P.O. Box 3000 CSNET: pack@ncar.CSNET Boulder, CO 80307-3000 DECNET SPAN: 9583::PACK