martin@medix.UUCP (Brian K. Martin M.D.) (06/04/87)
> I can't stand this anymore. All you guys claim AEGIS is far superior > to any UNIX implementation, but fail to state explicitly as to what > makes it superior. > The file system, use of runtime libraries, and network implementation are some of the things that come to mind. But I use UNIX exclusively, and so this stuff is mostly transparent to me. > Stating popularity as reasons for superiority is like comparing > IBMs with non-IBMs. Just 5 years back, anybody mouthing UNIX would > have been frowned upon. Based on technical merits alone, what is > it that makes AEGIS superior/inferior? I agree. Unix is THE standard. Take a look at the federal government RFPs. Most of them now specify UNIX. I hardly use AEGIS, and haven't found it necessary to learn much at all about AEGIS. > I am no UNIX guru and so would like to know what's wrong in using > /dev/kmem(Perhaps if I am a guru,I would be die-hard fan of /dev/kmem:-)). Now for my two cents. Whether or not an Apollo is a UNIX box depends on your definition of a UNIX box. A Sun is a UNIX box, and so is a MicroVax. A Vax 8600 is a very big UNIX box. AT&T's attempt to use the SVID as the definition of what a UNIX box is failed, but was a step in the right direction. From my standpoint, a UNIX box is a system that allows me to port programs written in a MACHINE-INDEPENDENT manner to run on a UNIX system, without any modifications at all to the make files or source code. It's also a system that does what any typical yet somewhat sophisticated UNIX user would expect it to do. As long as you use this definition, the Apollo is a UNIX box with lots of enhancements, just as a Sun is a UNIX box with a lot of Sun-specific enhancements. I've installed quite a few programs taken off of USENET, including the "elm" mailer, without any problems. Of course, system administration on an Apollo differs from that on a Vax, but that's also true of Sun Workstations. However, a pc/at running Xenix doesn't (and shouldn't) fit my definition of a UNIX box. Given these constraints, when I was choosing a vendor of UNIX boxes to use as the compute engine for my company's products, I chose Apollo primarily because of the network implementation, even though the price/performance ratio was not as good as Sun's. I don't know if I would be considered a guru or not, but I have worked with UNIX systems for more than ten years, and before changing fields (I'm a physician now) I worked at one company where I was directly involved in a port of UNIX V7, including a major rewrite of the kernel along with many bug fixes to standard UNIX programs along with changes targeted at providing a cleaner user interface. Working with a UNIX kernel taught me to avoid at all costs any type of programming that would not run on a generic UNIX system. In other words, avoid access to /dev/core, /dev/mem, /dev/kmem etc. and use other methods whenever possible. Now for a digression... UNIX is both a concept and an OS. Especially important is the use of abstractions for accessing system services--/dev/* for I/O services, etc. In this way, Apollo conforms by using /dev/sio? for access to serial line devices, /dev/wn* for access to winchester drives, /dev/rwn* for raw device access, etc. They even have /dev/concole, which has traditionally been used as the operator's terminal to which UNIX panic messages are sent. But they don't have /dev/kmem, which is a virtual memory map of the kernel. (And if you think about it, there's no real reason to access the AEGIS kernel UNLESS your writing code that is Apollo-specific. But I write code that is UNIX-specific.) Raw device access, direct writing to a disk drive, bypasses the abstractions inherent in the OS, and so doesn't really conform to the concepts inherent in UNIX (flames to /dev/null please). It's a holdover from the days when PDP 11/70s were the primary UNIX systems, when you paid a performance penalty for letting the OS allocate system resources through the /dev/* abstractions. You used raw device access to bypass the standard i-node/disk address mappings, to allow the creation of contiguous disk files which in turn would decrease the number of seeks performed by the read/write head on the disk, because if you didn't the "sequential" blocks in a file could be scattered all over the disk, resulting in the disk drive jumping up and down in its cabinet from all of the seeks it was trying to perform. "RAM-disks" were also used back then, on which the /tmp directory and a copy of the superblock and i-node list and process tables were stored, in order to increase performence. Raw device access is still important for the creation of large databases, where you might store all of the indexes (b-tree*, hash, heap) in such a way that an index entry is tied to a physical disk adddress instead of a virtual disk address, which would give a noticeable performance improvement when doing an equijoin operation on three relations where each relation holds a million tuples. But that makes your software fairly machine-dependent. Otherwise, there's no real reason to bypass the standard device interface. But with larger and faster machines, you should no longer pay a large performance penalty for using standard I/O methods, and there ought to be fewer and fewer reasons for wanting access to /dev/kmem and other non-machine-independent parameters. Regards, Brian K. Martin, M.D. Martin Information Systems, Ltd. 3420-A Hinahina Street Honolulu, Hawai'i 96816 PHONE: (808) 735-5661 ARPA: uhccux!medix!martin@nosc.mil UUCP: { ihnp4,ucbvax,dcdwest,seismo }!sdcsvax!nosc!uhccux!medix!martin