Usenet 1994 January

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

/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / v21 / 198 / text0000.txt < prev

Wrap

Text File | 1990-12-05 | 24.9 KB | 527 lines

Submitted-by: jsh@usenix.org (Jeffrey S. Haemer,) An Update on UNIX1-Related Standards Activities October 11, 1990 USENIX Standards Watchdog Committee Jeffrey S. Haemer, jsh@ico.isc.com, Report Editor Summer-Quarter Standards Activities This editorial addresses some of the summer-quarter standards activi- ties covered by the USENIX Standards Watchdog Committee.2 In it, I've emphasized non-technical issues, which are unlikely to appear in offi- cial minutes and mailings of the standards committees. Previously published watchdog reports give more detailed, more technical sum- maries of these and other standards activities. If my comments move you to read one of those earlier reports that you wouldn't have read otherwise, I've done what I set out to do. Of course, on reading that report you may discover the watchdog's opinions differ completely from the ones you see here. As watchdog editor I edit the reports, I don't determine their contents. The opinions that follow, in contrast, are mine. Profiles There's an explosion of activity in the profiles world, bringing with it an explosion of problems, and dot zero, the POSIX guide group, is at ground zero.3 The first problem is, ``What's a profile?'' Everyone has a rough idea: it's a document that specifies an application- specific set of standards (or pieces of standards). The best informal illustration I've heard is from Michele Aden, of Sun Microsystems. Imagine, she says, you have to write a guideline for buying lamps for Acme Motors. You might require that the lamps have ANSI-standard, three-prong plugs, accept standard one-way, hundred-watt bulbs, have cords no shorter than five feet, and stand either two- to three-feet tall (desk models) or five- to seven-feet tall (floor-standing models). This combination of pointers to standards, additional specifications, and detailed options, which gives purchasing agents __________ 1. UNIXTM is a Registered Trademark of UNIX System Laboratories in the United States and other countries. 2. A companion article provides a general overview of the committee itself. 3. I use ``dot zero'' to refer both to the P1003.0 working group and to the document it's producing. These are common conversational conventions among standards goers, and which of the two I mean is usually obvious from context. October 11, 1990 Standards Update Recent Standards Activities - 2 - guidelines to help them make choices without tying their hands to a specific vendor, is a profile - in this case, an Acme Motors lamp pro- file. Dot zero now sees itself as a group writing a guide to help profile writers pick their way through the Open-Systems'-standards maze. But that rough agreement is as far as things go. And the standards world is never informal. For ``profile'' to graduate from a hallway- conversation buzzword to an important organizing principle, it needs a precise definition. And since there are already four groups writing profiles - real-time, transaction processing, multiprocessing, and supercomputing - TCOS needs to figure out what a profile is pretty quickly. ISO already has IAPs, International Applications Profiles. The ISO document TR 10K describes these in detail. Unfortunately, TR 10K was developed for OSI-related profiles and shows it. Cut-down extracts of the standard appear in the document. Someone needs to define a PAP, a POSIX Application Profile. But that's just the first problem. Even thornier is the question ``What does it mean to say that something conforms to the POSIX transaction-processing profile?'' If I want to write assertions for a profile or tests to verify those assertions, how do I do it? Does it suffice to conform to the individual components? What about their interactions? The first principle of management is ``If it ain't somebody's job, it won't get done.'' Dot zero has done such a good job of promoting The Profile as an organizing principle for addressing standards issues that people are beginning to press dot zero for answers to questions like these. Unfortunately, that's a little like killing the messenger. It's just not dot zero's job. So the funda- mental profile question is ``Who's in charge?'' Right now, I think the question sits squarely, if uncomfortably, in the lap of the SEC - the Sponsors Executive Committee, which oversees the IEEE's operating-systems activities. In the meantime, the various working groups writing profiles are mak- ing headway by just trying to define profiles and seeing where they get stuck. Dot twelve, the real-time profile group, is busily making various sorts of tables, to try to find a reasonable way to specify the pieces that make up a profile, their options, and their interac- tions. Dot ten, the supercomputing profile group, is seeking an overall structure for a profile document that makes sense. Dot eleven, the transaction-processing profile group, is trying to steal from dots twelve and ten, an important test of the generality of the other two groups' solutions. Dot fourteen, the multiprocessing pro- file group, isn't far enough along to make theft worth their while, but will eventually provide a second generality test. Think of it as a problem in portable ideas. October 11, 1990 Standards Update Recent Standards Activities - 3 - Will_I_Win_My_Beer? In my last editorial, I announced a beer bet with John Gertwagen over whether threads will ballot and pass before the base dot-four (real- time) ballot objections are resolved. I'm still betting on threads, but it looks like the bet is still anyone's to win. Some folks assure me that I'll win my beer handily, others say I don't have a chance. At the summer POSIX meetings, in Danvers, Massachusetts, the dot-four chair, Bill Corwin, challenged the threads folks to come up with a ballotable draft by the end of the week, and they very nearly did. (I hear complaints from some quarters that the the vote to go to ballot was 31 to 7 in favor, and that attempts to move to balloting were only blocked because of filibusters from those opposed.) On the other hand, technical reviewers are now resolving ballot objections to the base with machetes. They've thrown away asynchronous events alto- gether and have discarded real-time files and adopted the mmap model that the balloting group suggested.4 Dot four has moved from ``design by working committee'' to ``design by balloting committee.'' Innovation C.A.R. Hoare once said, ``One thing [the language designer] should not do is to include untried ideas of his own.'' We have followed that precept closely. The control flow statements of Ratfor are shamelessly stolen from the language C, developed for the UNIX operating system by D. M. Ritchie. - Kernighan and Plauger5 Should standards groups just standardize existing practice, or should they be solving known problems? And if they solve known problems, how much innovation is allowed? Shane McCarron's September UNIX/Review article6 uses the real-time group, dot four, as a focus for an essay on this subject. His thesis is that standards bodies should only be allowed to standardize what's boring. I've already seen John Gertwagen's reply, which I assume will be printed in the next issue. __________ 4. Dot four's real-time files are currently a part of the supercomputing profile. If they disappear from dot four, they may reappear elsewhere. 5. Kernighan, Brian and Peter Plauger, Software Tools, Addison- Wesley, 1979, p. 318. 6. McCarron, Shane, ``Commodities, Standards, and Real-Time Extensions,'' UNIX Review, 8(9):16-19 (1990). October 11, 1990 Standards Update Recent Standards Activities - 4 - I find myself agreeing (and disagreeing) with both and recommend you read them. This battle will rage brighter in some of the groups less far along, but sporadic fighting still breaks out in the shell and tools group, dot two. Right now, collation and character classification are seeing a lot of skirmishing. Some want to stay relatively close to the existing practice, while others want to grow a mechanism to deal with the Pandora's box of internationalization. My favorite current exam- ple, though, is make. Bradford's augmented make is almost a decade old. Stu Feldman's original is a couple of years older than that. That decade has seen a number of good make replacements, some of them wildly successful: Glenn Fowler's nmake has virtually replaced make for large projects in parts of AT&T. Still, many of these upgrades maintain the original make model,7 just patching up some of make's more annoying craters and painting over its blemishes. At this point, there is real consensus among make augmentors about some patches. Most upgrades expand make's metarules. For example, .c.o: $(CC) $(CFLAGS) $< might become %.c : %.o $(CC) $(CFLAGS) $< Not much of a change, but it also gives us s.% : % $(GET) $(GFLAGS) -p $< > $> ... in place of the current, baroque __________ 7. Fowler, Glenn, ``A Case for make,'' Software-Practice and Experience, 20: S1/35-S1/46 (1990). October 11, 1990 Standards Update Recent Standards Activities - 5 - .c~.o: $(GET) $GFLAGS) -p $< > $> ... Make's successors don't agree on syntax, but they all agree agree that ``~'' rules are the wrong solution to a real problem. Should dot two standardize a newer solution? Existing-practice dogmatists would say, ``No. It's not make.'' Here's a place I say, ``Yes - if we can do it in a way that doesn't break too many makefiles.'' The prohibition should be against untried ideas, and I don't see those here. A year or so ago, Stu Feldman (make), Glenn Fowler (nmake), Andrew Hume (mk), and a handful of other make luminaries presented a proposal to add four extensions to dot two's make. Not one is yet in the draft. I hope that changes. SCCT_Faces_Serious_Problem At Danvers, the testing group, dot three, worked with dot two on test assertions to try to avoid the kinds of problems created by the P1003.1 test assertions, which dot one had no input into until the assertions were in ballot. A side effect of the collaboration, which is taking place before dot two is finished, is that it may reveal that parts of dot two are imprecise enough to require a rewrite. Dot two, draft eight had around four-hundred ballot objections, draft nine saw fewer than half that number. There was hope that draft ten would halve that again, bringing it within striking distance of being a standard8 The asser- tion work may point out and clear up rough spots that might otherwise have escaped the notice of battle-fatigued balloters. (Paradoxically, NIST, which is heavily represented in dot three and painfully familiar with dot two's status and problems, is currently pushing for a shell- and-tools FIPS based on the now-out-of-date draft nine.) The exercise of trying to construct assertions for dot two before it goes to ballot may bring some new testing problems into focus, too. Before I explain what I mean, I'll give you a little background. The POSIX effort has outgrown dot three, which did test assertions for dot one and is in the process of constructing test assertions for dot two. Dot three has, at most, a couple of dozen members, and the docu- ment for dot two alone may swell to one- or two-thousand pages.9 If __________ 8. It didn't reach that goal. Keith Bostic tells me he submitted 132 objections himself. October 11, 1990 Standards Update Recent Standards Activities - 6 - dot three were to continue to do all test assertion work, it would have to produce a similar document for at least a dozen other stan- dards. Reacting to this problem, the SEC created a steering committee, the SCCT, to oversee conformance testing. The committee's current plan is to help guide standards committees to write their own assertions, which will be part of the base document. Test assertions, like language independence, are about to become a standards requirement (a standards standard). With this change, the current process - write a base document, evolve the base document until it's done, write test assertions for the result, evolve the test assertions until they're done - would become: write a base document with test assertions, then evolve the base docu- ment modifying the test assertions as you go. A sensible-enough idea on the surface, but after the joint dot-two, dot-three meeting I have questions about how deep that sense runs. First, does it really make sense to write assertions early? Working- group members should be exposed to assertion writing early; when working-group members understand what a testable assertion is, it's easier to produce a testable document. Still, substantive, major draft revisions are normal, (see the real-time group's recent ballot, for example) and keeping test assertions up-to-date can be as much work as writing them from scratch. This meeting saw a lot of review of draft-nine-based assertions to see which ones had to change for draft ten. Second, if you make the assertions part of the standard, they're voted on in the same ballot. Are the same people who are qualified to vote on the technical contents qualified to vote on the test assertions? Third, writing good assertions is hard, and learning to write them takes time. How eager will people in working groups be to give up time they now spend writing and revising document content in order to do assertions? Fourth, is the time well-spent? Not everything merits the time and expense of a standard. If only a small number of organizations will ever develop test suites for a particular standard (with none being a ______________________________________________________________________ 9. Any imagined glamour of POSIX meetings fades rapidly when one is picking nits in a several-hundred-page standards document. When asked where the next meeting was, one attendee replied, ``some hotel with a bunch of meeting rooms with oversized chandeliers and little glasses full of hard candies on the tables.'' October 11, 1990 Standards Update Recent Standards Activities - 7 - special, but important case) does it make sense for folks to spend time developing standards for those test suites? Wouldn't it make more sense to develop it after there is a clear need? (This is a per- verse variant of the ``existing practice'' doctrine. Even if you don't think standards should confine themselves to existing practice, does it make sense to innovate if there's never going to be an exist- ing practice?) Stay_Tuned_for_This_Important_Message If you haven't yet had the pleasure of internationalizing applica- tions, chances are you will soon. When you do, you'll face messaging: modifying the application to extract all text strings from external data files. The sun is setting on main() { printf("hello, world\n"); } and we're entering a long night of debugging programs like this: #include <stdio.h> #include <nl_types.h> #include "msg.h" /* decls of catname(), etc. */ #define GRTNG "hello, world\n" nl_catd catd; main() { setlocale(LC_ALL, ""); catd = catopen(catname(argv[0]), 0); printf(catgets(catd, SETID, MSGID, GRTNG)); catclose(catd); exit(0); } This, um, advance stems from a desire to let the program print ch`o c'c ^ng instead of hello, world when LANG is set to ``Vietnamese.'' October 11, 1990 Standards Update Recent Standards Activities - 8 - Most programs use text strings, so the system services interface group, dot one, has been thinking about portable library calls to sup- ply such strings and portable formats for the files that contain them. Actually, ``re-thinking'' is probably more accurate than ``thinking about.'' 1003.1a Draft 9, specified a design by the UniForum Techni- cal Committee on Internationalization. At Danvers, X/Open counter- proposed a variant of its existing XPG3 specification, arguing that the X/Open scheme may have problems but it also has users, while the UniForum proposal is still in the laboratory. (It brings to mind the apocryphal story of Stu Feldman's wanting to improve the design of make, but feeling he couldn't because he already had seven users.) Someone from Unisys also brought a proposal, different from both UniForum's and X/Open's. That no one even showed up to defend the UniForum proposal shows that there is something wrong with standardizing messaging. One minute, there is enough support for a messaging scheme to get it into the draft standard; the next, there's none at all. In the end, the work- ing group agreed that a messaging standard was premature and that the free market should continue to operate in the area for a while. Given the relative sizes of the organizations concerned, this outcome probably sticks us with the X/Open scheme for a while, which I find the ugliest of the lot. Still, it's not a standard, and there's room for innovation and creativity if we're quick about it. The ``existing practice'' criterion is supposed to help avoid a requirement for mas- sive, murderous source code changes. We should be looking for the messaging scheme that doesn't require changes in the first place, not the one with the most existing victims. Language_Independence_Stalls_ISO_Progress Internationally, 1003.4 (real-time), 1003.5 (Ada bindings), and 1003.9 (FORTRAN bindings) are being held hostage by ISO, which refuses to loose them on the world until we come up with a language-independent binding for 1003.1. The question is, who will do the work? ``Not I,'' says dot four, whose travel vouchers are signed by companies caught up in the glamour of real-time and threads; ``Not I,'' say dot five and dot nine, who seldom have even ten working-group members apiece; ``Not I,'' say the tattered remnants of dot one, exhausted from struggling with 1003.1-1988, FIPS-151 and 151-1, and (almost) 1003.1-1990, before any other groups have even a first standard passed. Where is the Little Red Hen when we need her? Should_We_Ballot_POSIX_the_Way_We_Ballot_Three-Phase_Power? In the meantime, we progress inexorably toward balloting on several IEEE/ANSI standards. The sizes of the drafts (and several contribu- tors to comp.std.unix) raise real questions about whether the IEEE's balloting process make sense for the sort of standards work POSIX is October 11, 1990 Standards Update Recent Standards Activities - 9 - performing. A month or so might be enough to review a few-page hardware standard. But is it enough for the nearly 800 pages in the latest recirculation of dot two? Does it really make sense to review the standard for grep in hard copy? Many would like to see longer balloting times and on-line access to drafts. Some argue that the final standard should be available only from the IEEE, both to insure authenticity and to provide the IEEE with income from its standards efforts; even that argument seems weak. Checksums can guarantee authenticity, and AT&T's Toolchest proves that electronic distribution works: I'll bet ksh has paid for itself several times over. ``We_handed_1201.1_its_head_and_asked_it_to_comb_its_hair.'' Moving away from POSIX, we come upon 1201.1, still in search of an officially sanctioned mission that the group wants to take on. The group currently has a PAR (charter) to standardize various aspects of X-based windowing - principally the toolkit-level API - but any hope of compromise between the OPEN LOOK and OSF/Motif factions died at the winter-quarter Utah meetings. In a moment of responsible, adult behavior, the group recovered by switching to a dark horse: a window-system-independent API that could be implemented on top of either product. Marc Rochkind's XVT, which already allows users to write programs that are portable across several, unrelated window sys- tems including X, the Mac, and MS-Windows, was offered as a proof-of- concept. While the original charter could probably encompass the new XVT work, the group seemed to feel that this direction change, together with the fragmenting of the original group into separate toolkit, drivability, UIMS, and X intrinsics efforts, required that they ask the SEC for a new charter. (The drivability group has already had a separate PAR approved and is now 1201.2.) The group convened a pair of interim meetings in Milpitas, California, and Boulder, Colorado, to forge a PAR that would meet the SEC's new, stricter standards for PAR approval by the summer Danvers meeting. They didn't succeed. Most of the problems seem to have been administrative missteps. Some examples: - Working-group members complained that the Milpitas meeting took place without enough notice for everyone to attend, and issues that had been resolved at the interim meetings were re-opened in Danvers. - The PAR was so broadly written that at least one technology (Ser- pent) was advanced as a candidate that almost no one thought should even be considered. - Some working-group members hadn't even received copies of the XVT reference manual before they reached Danvers. October 11, 1990 Standards Update Recent Standards Activities - 10 - - Many SEC members appeared not to have seen a copy of the PAR until the afternoon before the SEC meeting, and some saw the final PAR for the first time at the SEC meeting itself. Many people who weren't familiar with the proposal ended up uneasy about it, not because they'd read it and didn't like it - they'd not been given much chance to read it - but because a lack of attention to administrative details in the proposal's presentation sapped their confidence in the group's ability to produce a sound standard. After all, standards work is detail work. In the end, the SEC tactfully thanked the group and asked them to try again. One SEC member said, ``We handed 1201.1 its head and asked it to comb its hair.'' I believe all of this is just inexperience, not a symptom of fundamen- tal flaws in the group or its approach. If 1201.1 can enlist a few standards lawyers - POSIX has no shortage of people who know how to dot all the i's and cross all the t's - and can muster the patience to try to move its PAR through methodically and carefully, I think the group will give us a standard that will advance our industry. If it doesn't do so soon, though, the SEC will stop giving it its head back. POSIX_Takes_to_the_Slopes Finally, I want to plug the Weirdnix contest. We currently have a great prize- including a ski trip to Utah - and only a few entries.10 The contest closes November 21, 1990. Send your entries to me, jsh@ico.isc.com. __________ 10. The occasionally heard suggestion that Brian Watkins was found clutching Mitch Wagner's entry is tasteless; it is almost - but, luckily, not quite - beneath me to repeat it. October 11, 1990 Standards Update Recent Standards Activities Volume-Number: Volume 21, Number 198