preece@gswd-vms.UUCP (11/03/86)
> For instance, if I wanted to write a program that would tell me what > files were currently being accessed, and what disk they were on, > whether they were locked, being waited for, been modified, > is shared by more than one process, the inode number, size, etc. etc. > then it would be a trivial task. I wrote such a program when I went to > AT&T's course on Unix Internals (Excellent course! I KNEW all those > strange files is /usr/include/sys were good for something! :-) > Bruce Barnett ---------- Well, if there's one trend that's clear in the Unix market it's that you're not ging to be able to count on that kind of compatibility much longer. We are entering the era of the SVID, which is going to simultaneously give us a much higher degree of confidence in the portability of application code and take away the portability of assumptions below the interface level. I tend to think this is a mostly good thing, but it does have a price. Throwing away the requirement that something work a partciular way under the well-defined exterior means different implementations will be able to take advantage of their advantages and compete seriously on added features (not the creeping kind, but the big ones like speed and security) while still offering guaranteed portability to SVID and P1003 respecting applications. On the other hand, the availability of tools for hackers and administrators will be reduced by the groowing diversity of kernel-level details. Those who failed to participate in the P1003 effort missed their chance to help figure out what should be part of the specification and what should be left to implementors' discretion. -- scott preece gould/csd - urbana uucp: ihnp4!uiucdcs!ccvaxa!preece arpa: preece@gswd-vms