Usenet 1994 January

home *** CD-ROM | disk | FTP | other *** search

/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.19 / text0075.txt < prev next >

Wrap

Internet Message Format | 1990-05-17 | 28.0 KB

From: Jeffrey S. Haemer <jsh@usenix.org> An Update on UNIX* and C Standards Activities April 1990 USENIX Standards Watchdog Committee Jeffrey S. Haemer, Report Editor USENIX Standards Watchdog Committee Update Jeffrey S. Haemer <jsh@ico.isc.com> reports on winter-quarter activites of various standards groups: 1003.0:_A_Guide_to_POSIX-Based_Open_Systems Dot zero, the POSIX guide group, continues to suffer from bureaucratic inertia. It complains that its forty or so attendees are insufficient to allow rapid progress, yet in a year-and-a-half they've just created a table of contents. Some people think this reflects badly on the group. I think this is completely wrong. Admittedly, the economics of producing the POSIX guide itself are unfavorable. A large fraction of the attendees are highly-placed or key employees of large corporations and influential organizations. A back-of-the-envelope calculation puts salary expenditures alone, for each one-week, dot zero meeting, close to six figures. Had the com- mittee delegated the entire task to one or two full-time people, it would be done. The fine overviews UniForum occasionally publishes are proofs-by-example. How, then, does dot zero benefit the user community? The meetings give influential people from the most important corporations in the commercial UNIX arena a way to get together in the same room (or after hours in the same city) and discuss the direction of UNIX without risking an anti-trust suit. __________ * UNIX is a registered trademark of AT&T in the U.S. and other countries. * UNIX is a registered trademark of AT&T in the U.S. and other countries. April 1990 Standards Update USENIX Standards Watchdog Committee - 2 - USENIX meetings serve a similar purpose for more technical segments of the UNIX community. To some degree, UniForum meetings serve an analo- gous purpose for other segments of the industry. But where else is there such a concentration of high-level, UNIX-vendor management except, perhaps, at meetings of the Hamilton or Archer groups, or of the board of directors of X/OPEN? Attendees support POSIX, and influ- ence their companies to become involved. Because POSIX is a good thing, so are dot zero meetings. 1003.1:_System_Services_and_C_Language_Binding Dot one is well ahead of the rest of 1003; look here to see the future. The initial standard is done, published, and government- approved as FIPS 151-1. The group is now working on supplements, which come in two flavors: nit-picks and corrections (1003.1a) and real additions (1003.1b). But to speak of ``the group'' is mislead- ing; these two working groups have a strikingly different makeup from the group that created dot one. Many who were passionately and inti- mately involved in the production of the ugly green book have moved on, either to other committees or out of the standards game. The working groups are now small numbers of hard-core, dot-one devotees. For .1a, this isn't a problem -- that's exactly the kind of person needed for nit-picking. Watch .1b like a hawk, though. Any new functionality, slipped into supplements and appendices, carries the same risks as riders on congressional bills; if it can be slipped in unobtrusively enough, or with the right timing, it can be awful and still ride on the coat- tails of the main body. Bad deeds done here will both inflict irresistible harm, and diminish the credibility of dot 1. I recommend resisting any effort to add functionality for which there aren't existing implementations in wide use, and about which there isn't already general consensus. Design-by-standards-committee efforts should be deferred to other, more ignorable standards. 1003.2:_Shell_and_Utilities Dot 2 is still firmly in the dot one mold. Dot 2 Classic is balloting away, and should soon be both done, government approved, FIPS-ified, with a set of test assertions that companies like MindCraft can sell test suites for. When this is done, a large number of systems will advertise compliance with 1003.1, 1003.2, and X3.159 and provide, for most users, a standard ``UNIX''. Even the controversial UPE is mostly codifying existing practice. Arguments are over places where more than one practice is widespread, for example, source-code control, where partisans of SCCS struggle with partisans of RCS. (Actually, that's not true. What's really happening is that the group's shying away from this area because they're worried about a struggle. ``Tar wars'' seems to have spoiled April 1990 Standards Update USENIX Standards Watchdog Committee - 3 - the industry's appetite for making difficult decisions about conten- tious topics.) Parenthetically, I'll admit to being mystified by the dim view some folks take of the UPE. I actually put programmer portability above program portability, since, when I go looking for new jobs I can't take our software with me, but do want to be sure that I can still use vi. (Of course, most members of working groups are sponsored by ven- dors.) The equivalent of .1a already has a name: .2b. Even the bad of dot one is mirrored here. Truly controversial proposals are being pushed off to the as-yet unborn .2c, which should produce a deja vu feeling in those already watching .1b. ("But," you remark, "you always say that.") And, just as .1 sometimes shied away from real decisions, in order to avoid upsetting anyone, .2 occasionally reacts to vendor inconsistency by proposing solutions that avoid upsetting any vendor by penalizing all users. As an example, the committee proposes requiring a C compiler (good), and naming it c89 (bad, but I com- plained about this loud and long last time). An important motivation for the new name is that cc already invokes the K&R C compiler on many vendors' platforms, and specifying a flag to choose one behavior or the other would conflict with someone's existing implementation; any given letter is already preempted by some vendor. I'm not convinced by this argument. I have consulted the Ouija board in my office, normally used only for project scheduling, and will now predict the effects of this sidestep, if approved: - In two years, everyone will have a c89 compiler, to comply with a government FIPS. Shell scripts and makefiles will continue to invoke cc, but be less portable than they are now. - On a few conformant machines, there will be no cc command. This will break an enormous number of programs, and solutions will vary from user to user, project to project, and installation to installation. - On other machines, cc will produce one flavor or the other. Most, but not all, machines will link cc to c89. This will break a variety of things, but not consistently enough to allow a port- able solution. - On some of these machines, flags will make c89 compile K&R C. The flag will vary from vendor to vendor. In short, we who do ports will have to keep track of how to invoke the C compiler on each of our target machines; .2 will not have enhanced portability in this area of our work. Finally, like .1, my unease over a small number of problems stands in stark relief to the generally high opinion I have of the work done by April 1990 Standards Update USENIX Standards Watchdog Committee - 4 - this group. 1003.3:_Test_Methods Dot three, a tiny mirror of the overall POSIX effort, is proliferating because it has no choice. It will now have a subcommittee to develop test assertions for each of the other POSIX efforts, and has acquired a steering committee to oversee the subgroups. Whether this is a better choice than having each POSIX committee develop its own test assertions, isn't clear -- I see plusses and minuses for each approach. Still, all in all, the group seems to know what it's doing, and is willing to do it. Dot three isn't always popular; one hears complaints that they come up with interpretations that seem contrary to the intention of the original standards committees. On the other hand, that seems as good a reason as any for their existence. They form a combination system-test and quality-assurance group for the other committees, generating all the friction one expects from any such organization. A dot three member did take the time to divulge an unexpected answer to a question I raised in my last report -- what motivates someone to be in dot three? For a few folks, it's obvious: MindCraft employees attend because their company develops and sells test suites. Others are also there because they're really interested in testing. But think: if you want an overview of all of POSIX, what group should you attend? There are three candidates: dot zero, but then you'd have to buy an expensive wardrobe; the SEC, but that group is mostly institu- tional representatives, officers, and overworked committee chairs; or dot three, which examines each standard in detail as it nears comple- tion. If you're thinking of joining a working group, and want this sort of vantage point, we're certain the group has plenty of work to hand out. 1003.4:_Real-Time_Extensions The real-time group now has five PARs: .4, .4a,, .4b, .4c, and .14. The first of these went to ballot after the New Orleans meeting. Threads, controversial enough to be omitted from .4, has been pushed into .4a. (Things too controversial to go into threads will be pushed into the multiprocessor group, which should be a lot of fun.) The threads subgroup (1003.4A) has attempted to kill the .4 ballot by a block vote for rejection. One correspondent says they are doing this because .4 is no good without threads. (I'm told that two ``large, non-vendor organizations'' are part of the coalition against the 1003.4 ballot. There is rumored to be a special, invitation-only, threads-strategy meeting by these two groups immediately preceding the Utah meeting. Can anyone confirm this and supply more details?) University of California's Computer Science Research Group (the folks who bring us Berkley UNIX) is also voting against the .4 ballot as a April 1990 Standards Update USENIX Standards Watchdog Committee - 5 - block. This stand has nothing to do with the lack of a threads propo- sal; the vote objects to the working group's addition of completely new and (their words) ``lame'' features to UNIX. An amusing twist, this. To a traditional standards activity, one vendor block voting against another, POSIX adds one research group voting against another. The threads group itself is divided over whether they are doing an interface to OS-kernel services or an applications library. They are also divided about whether they are doing an interface to language- independent, concurrent programming services, or just a C-language extension. In general, .4A seems to be a small core of activists pushing ahead with a clear agenda, with an opposition that complains but appears incapable of putting together a detailed, unified counter-proposal. Both the rush to go to ballot, and the move to tie success of the rest of 1003.4 to threads, should be causes for scrutiny. Interestingly, if threads are forced back into the base .4 standard, it may end up causing another problem. The ACM's ARTEWG (the special interest group on Ada's runtime environment working group) is likely to vote in a block against 1003.4 if it contains a threads proposal that does not support Ada in a natural way. The Ada folks are concerned that there be an underlying, OS-level model of concurrency consistent with both the C-threads and Ada task- ing models. This seems especially important to them if Ada applica- tions want to use standard services written using C libraries which are implemented using C-threads (e.g., windowing and database access). Such a model would also be important for support of Ada compilation systems, which are typically produced by independent software houses to operate on a variety of operating systems and machine architec- tures. Dot 4b is a language-independence effort. What's interesting here is that real-time was one of the groups that the SEC grandfathered out of the requirement that POSIX standards be language-independent. (Other exemptions included other standards well along, like .1, and standards that were intrinsically language-dependent, like .9, FORTRAN bind- ings). Despite that exemption, real-time may be the first group to write a language-independent binding. Real-time also has PARs for .4C, a place to put stuff that didn't make it into .4 (i.e., .4 is to .4C as .1 is to .1B), and .14, the real- time profile. April 1990 Standards Update USENIX Standards Watchdog Committee - 6 - Language-independence_Study_Group I want to straighten out something I was confused about in the last summary report. (Thanks to Jeff Kimmel, of the language-independence study group, for taking the time to explain this.) Language- independence is a sop to ISO. Two prices we pay to gain rapid inter- national approval of the POSIX standards are an agreement to hand ISO standards formatted in their preferred style, to which end the IEEE is providing editorial assistance, and a commitment to a direction ISO intends to take for all its standards: language independence. And, to clear up another misconception, Steve McDowell worried, in his last .7 snitch report, that ISO requires language-independent specifi- cation languages to themselves be standardized. This would force POSIX to use something frightening like VDL. Fortunately, that turns out only to be true for formal specification languages: languages from which one can derive correctness proofs. ISO isn't interested in proofs, only in divorcing specifications from specific programming languages. They don't want to give an unfair advantage to languages in which the things being standardized are likely to be initially implemented, like C or FORTRAN, over more international languages, like ALGOL-66. In other words, POSIX will probably produce specs in ASN.1 or even English. (That's ``language independent.'' Get it?.) 1003.5:_Ada_Bindings Dot five didn't officially meet in New Orleans, partly to give .5 members more time to attend other groups. Dot five members kept say- ing things to puzzled members of other committees like, ``We're not really meeting,'' ``I'm not really here,'' and ``Well, I am here, but don't tell our chair, Steve Deller.'' One member graciously volunteers this short, but timely, update: The Ada binding group (P1003.5) just finished an intensive work- ing meeting at Florida State, in Tallahassee. The meeting went very smoothly. We resolved all the issues brought up by the recent mock ballot, and expect to have a revised draft ready for the April POSIX meeting. That draft is supposed to be given some finishing touches at the meeting, and then sent out for formal ballot. 1003.8:_Transparent_File_Access As expected, what used to be dot 8 has split into several groups. There was a meeting on the last day, in which chairs of each of the newly-formed POSIX networking-related groups gave status reports. At that meeting, one attendee objected that the models and APIs that come out of these groups increase portability, but do little or nothing to insure interoperability. Surely, networking standards should have interoperability as a primary goal, he complained. While the current groups don't have solving this problem as part of their charter, many attendees agreed that the complaint is valid, and something should be April 1990 Standards Update USENIX Standards Watchdog Committee - 7 - done on this front. Keep your eye on this problem. While the other subgroups have new numbers, the group standardizing transparent file access (TFA) retains the dot 8 name. Six months ago, TFA was torn between a faction wanting to canonize NFS, and another insisting on something that supports full dot 1 semantics. Now, the group has achieved consensus. They'll provide several standards: a core subset with which FTAM will comply, a set of extensions to the core with which various versions of NFS will com- ply to various degrees, and a full standard that will support full dot 1 semantics. This compromise recognizes the de facto international standard without sacrificing a commitment to dot 1. 1003.9:_FORTRAN_Bindings Dot 9 is in the middle of editorial cleanup in preparation for ballot- ing. Emphasis until now has been on content, so the draft developed with many styles and formats. Much of the last meeting was spent try- ing to even things up. Since things are drawing to a close, you might expect meetings to be sedate. If you read the .9 postings in comp.std.unix, you'll know that's not true. When I walked in on the .9 meeting the group was in the middle of a heated discussion. Someone had proposed adding several functions to increase portability of FORTRAN programs. One specific example was a function that would return the maximum real for the implementation. While there is little question of the utility of such a function, there were two sorts of illuminating objections: 1. Some members of the group objected that the standard was not intended to increase portability of FORTRAN programs, only to provide FORTRAN bindings to the .1 standard. (Indeed, unlike .5, .9 makes no attempt to be a stand-alone document. It freely uses pointers into .1.) Others countered that the section being discussed corresponds to section 8, Language-Specific Service for the C Programming Language, of the ugly green book; that the group's goal is improving application portability; and that additions that further that goal are completely within the group's charter. 2. One member objected strenuously that many of these additions required REAL support. I was utterly mystified by this objec- tion, until the group patiently explained that, though .9 is an F77 binding, it won't require F77 compliance, and won't use all the features of F77. For example, these new functions were .9's first use of REALs. What the member was objecting to was that without the added functions, a vendor could advertise .9 compli- ance with an integer-only FORTRAN compiler. Adding these new functions would require that the vendor's FORTRAN compiler actu- ally handle REALs. Think about that. April 1990 Standards Update USENIX Standards Watchdog Committee - 8 - The ultimate (and, in my opinion, correct) decision was to add the functions, but you can see that there are interesting philosophical divisions in this group. Similar divisions actually exist in all the groups, but the discussions in .9 seem to be more direct and get resolved more quickly. Chalk it up to more programmers, fewer politi- cians. 1003.10:_Study_Group_on_Supercomputing Dot ten has two subgroups, Profile and Batch, each working on a docu- ment. The Supercomputing Application Environment Profile specifies a set of standards, along with options and parameters needed for supercomputing application environments. The current draft, 1.0, is still rough, but specifies most of the required standards. At the April meeting, the Profile subgroup will hold a joint session with dot 0 and the other profile working groups (.11, .14, and the multiprocessing study group) to discuss profiles. Batch Extensions for Portable Operating Systems describes a standard batch management system based on NQS (the Network Queuing System, available from NASA Ames). The batch subgroup began its work within /usr/group's supercomputing working group, has been meeting eight times a year, and is now on draft 1.2. When complete, the document will specify required extensions to POSIX, including interfaces for checkpoint/restart and resource control, utilities for job submission/management and batch system administration, and a network, application-level protocol. The subgroup has submitted a PAR for the batch work, which the SEC will consider at their April meeting. 1003.11:_Transaction_Processing_Study_Group Good news in transaction processing. Dot 11 has been trying to work out what model of transaction processing to adopt. Because many com- mittee members are also active in other committees specifying other TP models, the committee had a running start, but progress has been slowed somewhat because there are at least three camps: those who favor the ISO model, those who favor the X/OPEN model, and those who believe that discussion of concrete models is premature. Part way through the New Orleans meeting the committee took a break from modeling to explore what an API to a transaction processing sys- tem might look like. This, finally, provided a fairly uncontentious topic on which all members could collaborate, and the committee seems to have been able to generate real agreement rather quickly. Success breeds success, and this may smooth the way to find other areas that the committee can make progress. One warning: Working out a sample API may serve only to clarify the committee's thinking about the requirements of their application April 1990 Standards Update USENIX Standards Watchdog Committee - 9 - profile, but I wouldn't be shocked to see the committee eventually submit a PAR for the work. If that happens, ask yourself whether the committee should be designing APIs for an area where there isn't yet industry consensus. 1003.12:_Protocol_Independent_Application_Interfaces Dot 12, process to process communication, is one of the groups derived from the division of the old dot 8 group. The big news from this group is that they've made a real decision in the struggle between XTI and sockets. The group has decided to invent a new interface, which they hope will combine the best of both and avoid the mistakes of each. This is important. It is the first time since the beginning of the committee (several years ago, counting its origins in /usr/group) that it has actually taken a stand on the question. The issue has come up often in past meetings, but until now been deferred by the group. On other fronts, the group is still trying to produce two API's: a detailed network interface and a simple network interface. I worry a bit about having two, disjoint interface standards in the same area. Are two standards better than none? (On the other hand, having two raises the possibility of splitting the group into two separate, num- bered groups at some later date, a popular POSIX pastime.) Recogniz- ing the danger in this split approach, some members of the group are considering whether it might be possible to specify a single, expand- able interface. 12xx:_Protocol-Dependent_Interfaces_for_OSI This new dot 8 spin-off, chaired by Kester Fong, is looking at protocol-dependent networking interfaces. They'll begin by concen- trating on FTAM. We predict this group will make rapid progress, because its composition is dominated by users. To help prevent its work from being an Aristotelian exercise in abstract design, the group has begun to collect all the examples it can find of applications based on FTAM. If you have, or know of, any such examples, please pass them on. Kester's e-mail address is <FONG%AESv01.GM@HAC@ARPA.HAC.COM>. 1201:_User_Interface 1201 is growing to four groups: .1 (Applications Programming Inter- face), .2 (Graphical User Interface), .3 (Human-Computer Interaction), and .4 (XLib). This serves as a focus for an interesting philosophi- cal issue. As many readers realize, there is widespread sentiment outside of these groups that 1201 should, instead, shrink to zero groups -- that standards in this area are premature. Even more interesting is that April 1990 Standards Update USENIX Standards Watchdog Committee - 10 - the same sentiment is widespread inside the groups. The level of dis- satisfaction does vary from group to group. Out of curiosity, I requested a vote for dissolution at the first New Orleans meeting of 1201.3. Fewer than one-third of the attendees voted to dissolve. This contrasts with a similar vote in Brussels in 1201.2, where nearly half of the attendees voted to dissolve. With this much anti-1201 sentiment, isn't there a way to get the IEEE to reconsider the activity? Apparently not. At the last USENIX, in Washington D.C., Jim Isaak, the SEC chair, explained to the well-attended standards BOF that there is really no easy way to dissolve a committee. If volunteers show up to staff the working group, follow the IEEE rules, and eventually circulate a bal- lot that passes, they've created an IEEE standard. This means, if you don't like the idea, you currently have only three options. 1. Join the balloting group and vote any proposal down. Not easy; you have to have a good reason for voting no. Of course, "This standard is premature; the direction of industry is too unclear" may be good enough. 2. Join the working group and filibuster until the direction the standard should take does become clear. (Of course, that would be expensive, and lose you popularity points.) 3. Let the group declare a standard and hope everyone ignores it. This one's dangerous because NIST won't. which means the ven- dors can't, which means users probably won't be permitted to, and will, at least, have to carry the code around as excess bag- gage. So, I'm curious. If you don't like what's going on here, which do you intend to do? (Okay, we're not that picky. If you like what 1201's doing but object to some other portion of what Doug Gwyn calls ``the standards juggernaut,'' what are you doing about it?) x3j11:_C_Language_Standard Closing on an upbeat note, we have a C standard. What more newsworthy item could you ask for? April 1990 Standards Update USENIX Standards Watchdog Committee Volume-Number: Volume 19, Number 78