home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!usenix!carolyn
- From: carolyn@usenix.ORG (Carolyn Carr)
- Newsgroups: comp.org.usenix
- Subject: USENIX Summer '92 Conference Report
- Keywords: USENIX Association
- Message-ID: <1149@usenix.ORG>
- Date: 24 Jul 92 19:21:28 GMT
- Organization: Usenix Association Office, Berkeley
- Lines: 530
-
-
- USENIX Summer '92 Conference Report
- ***********************************
-
- Best Paper Winners
-
- Doug Moen of Sietec Open Systems Division was
- given the Best Paper Award for "A Discipline of
- Error Handling."
-
- Mary Baker and Mark Sullivan, UC Berkeley
- authors of "The Recover Box", won the Best
- Student Paper Award.
-
- Both papers have been published in the USENIX
- Summer 1992 Technical Conference Proceedings.
-
-
- Works-in-Progress Report:
- Organized by Lisa A. Bloch, Sun User Group and
- coordinated by Peg Schafer, BBN Systems
-
- A Hybrid Performance Model for NFS File
- Servers, David N. Williams, Ericsson Network Systems,
- Richardson, TX <exudnw@exu.ericsson.se>
-
- In this session we will report on a Hybrid simula-
- tion model of NFS client-server transactions.
-
- Our current environment consists of over 400
- diskless SPARC workstations supported by nine
- Sune 4/490 active servers. Benchmarks combined
- with trial and error were the prime methods used
- in arriving at the current configuration.
-
- A number of benchmarks exist to assist in select-
- ing and tuning NFS servers, but benchmarking
- has its perils and limitations. Vendor-supplied
- benchmark numbers are frequently suspect, and
- not every organization has the resources or skills
- required to achieve accurate and meaningful
- results. Even after spending extensive time
- benchmarking a server, the results may not pro-
- vide sufficient information on how it will work in
- a specific environment.
-
- A discrete event simulation model of the NFS
- client-server relationship has been built which
- provides an approximate model of existing or
- proposed client-server configurations. The model
- allows for flexibility in changing parameters and
- does not require the investment in time, and pos-
- sibly money, that comes with benchmarking.
-
- Phonestation: Moving the telephone onto the
- Virtual Desktop, Stephen Uhler, Bellcore
- <sau@bellcore.com>
-
- The PhoneStation system is a tool that allows a
- Sun SPARCstation to control an ordinary tele-
- phone line. It consists of: 1) a micro-controller
- that interfaces a telephone line with a SPARCsta-
- tion via a serial port and the audio connector, 2) a
- software library for the SPARCstation that pro-
- vides telephone interface control, digital signal
- processing (e.g., touch-tone detection), and text
- to speech conversion, and 3) a TCL based lan-
- guage for writing telephone applications.
-
- As an example, the system can be used to inte-
- grate answering machine functionality into the
- workstation environment. Voice messages
- appear as ordinary electronic mail and are played
- through the SPARCstation speaker. If mail is read
- from a dumb terminal, the PhoneStation system
- places a call to a user specified telephone number
- and plays the voice portions of any messages.
-
- Texas: An efficient, highly compatible persistent ob-
- ject store using pointer swizzling at page fault time
-
- Vivek Singhal, University of Texas at Austin
- <singhal@cs.utexas.edu>
-
- Texas is a persistent object store that implements
- huge address spaces efficiently on standard hard-
- ware. Pointer swizzling (address translation) at
- page fault time converts the pointers in a page
- from a long format into normal, hardware-sup-
- ported virtual addresses when pages are brought
- into memory. This translation is transparent to
- compiled programs, allowing the use of existing
- compilers with little or no modification. Modern
- UNIXes such as SVR4 and OSF/1 provide the
- necessary control over virtual memory with no
- modifications to the operating system.
-
- Gumby: The portable, high-performance file system
- that rides on the back of your Pokey file system
- Sheetal V. Kakkad, University of Texas at Austin
-
- Gumby is a simple log-structured file system
- built on a normal UNIX file system. The file sys-
- tem is built inside a single UNIX file, requiring no
- dependencies on underlying disk geometry, so it
- is quite portable. Log structure avoids the use of
- a single "home" disk block for a logical file block,
- allowing any block to be written anywhere. This
- optimizes the file system for use with large RAM
- caches, which tend to absorb most reads and
- increase the proportion of writes. We intend to
- experiment with reordering read-only pages as
- well, to dynamically increase locality and reduce
- seeks caused by read misses.
-
- Knowledge-Based Systems Construction in C++,
- Vladimir Bacvanski, Aachen University of Tech-
- nology, Germany <vladimir@rwthi3.informatik.rwth-aachen.de>
-
- The examination of an applicability of appealing
- techniques from object-oriented software engi-
- neering to knowledge-based systems domain is
- discussed, focusing on the promising role of C++
- in this context. The entrance of expert systems
- into real industrial application arena has uncov-
- ered weak points of the current knowledge-based
- systems technology, especially the incomprehen-
- sibility, poor performance, and inability to inte-
- grate with non-knowledge-based systems.
-
- The use of C++ for building technical expert sys-
- tems should provide one possible framework for
- overcoming the current deficiencies. The code of
- a knowledge representation language is trans-
- lated into C++, bringing the possibility to use
- knowledge-based techniques while remaining in
- the well known environment, so that developers
- do not have to abandon all their skills and move
- to expensive and incompatible specialized artifi-
- cial intelligence workstations. Moreover, the
- combination of multiple paradigms (object-ori-
- ented, procedural, and the rule-based one) in the
- C++ framework produces a synergetic result.
-
- A new multi-paradigm system architecture is
- examined together with mechanisms which
- diminish the impedance mismatch between
- object-oriented knowledge and non-knowledge-
- based systems, providing interchangeability of
- objects which follow different paradigms. The
- object-oriented paradigm is used not only to
- model the applications, but the system's internal
- components as well. The correspondence
- between different constructs from the object-ori-
- ented and knowledge-based systems will be
- investigated, showing that it is possible and prof-
- itable to model knowledge-based systems with a
- set of C++ classes.
-
- Development of an event based debugger with source
- level capabilities, J. G. Posthuma, J. Scholten, J. G. Wijnstra;
- U. Twente, Netherlands <posthuma@cs.utwente.nl>
-
- Finding a bug in an application is time consum-
- ing and expensive. For parallel applications,
- debugging is even harder. The behavior of paral-
- lel applications can only be understood by look-
- ing at them with great abstraction. Only specified
- events of the system should be presented to the
- user. But such events only give a hint where a bug
- could be. After this hint, the user has to look with
- greater detail. He should be able to specify both
- events of higher abstraction (for example com-
- munication) and source level debug events.
-
- Events are the basis of the debugger. An event is
- generated each time an important point is
- reached in the execution. These points can be
- specified by the programmer. An event will often
- be used to indicate a place where interaction
- between two processes takes place, since interac-
- tion is an important aspect of parallel applica-
- tions. The events of all processes are merged into
- one event stream. This stream can be used
- directly or stored in a database for later use. For a
- long running or multi-process application, the
- event stream can be quite voluminous. That is
- why a number of tools are provided to make the
- event stream data more manageable. The pro-
- grammer has the possibility of reducing the com-
- plexity by specifying filters, which remove those
- events in which the user is not interested.
-
- Another important tool is the behavior recog-
- nizer. A recognizer matches behavior as specified
- by the user in terms of events against the event
- stream generated by the application. It is not only
- possible to specify the expected behavior, but also
- the behavior that is not allowed. Recognizers can
- be used in a number of ways. First of all they can
- be used to trace down the places where the spec-
- ified behavior is violated. Secondly, recognizers
- are useful to summarize the behavior by replac-
- ing a number of events from the stream with one
- new high level event. This allows the program-
- mer to analyze the system at different levels of
- abstraction. A third possibility is to use recogniz-
- ers to specify interesting points in execution
- where some action must be performed, like a
- request for process status. This last option is only
- possible for run time debugging. The recognizers
- are also useful for analyzing events in the data-
- base.
-
- The debugger is a mixture of an event based
- debugger, source level debugge, and a behavior
- recognition system. The event based part of the
- debugger concentrates on distributed aspects of
- the application and can be used during or after
- execution. It is not always possible to debug an
- application when using the event based ap-
- proach. That is why the normal source level
- debugger will be integrated in the design. In the
- future, other features may be added, in order to
- make it a complete debugger for distributed
- applications.
-
- MACH on a Physically Secure Crypto Coprocessor
- Elaine Palmer, IBM Research Division, Yorktown
- Heights, New York <epalmer@watson.ibm.com>
-
- I will present an overview of a secure crypto-
- graphic workstation coprocessor. The prototype
- hardware, named `Citadel', was completed in
- 1991 at IBM's T.J. Watson Research Center. It can
- perform DES encryption and decryption of data
- at high speeds.
-
- We envision its use in three possible application
- environments:
-
- 1. It can be embedded in a communications con-
- troller (wire or fiber) to encrypt or decrypt some
- or all network traffic.
-
- 2. It can be embedded in a disk controller to
- encrypt or decrypt selected files or an entire disk.
-
- 3. It can be installed as a secure, general purpose
- crypto coprocessor on a microchannel bus. In this
- environment it can be used to encrypt or decrypt
- passwords, authenticate users and requests for
- resources, encrypt or decrypt transactions, or
- process sensitive data from the main host proces-
- sor.
-
- In all three applications, encryption and decryp-
- tion does not degrade the throughput of its host
- device. The host for our prototype is an IBM
- PS/2.
-
- The hardware and kernel software are designed
- to operate in a physically secure package. If the
- package detects tampering, it responds by eras-
- ing its encryption keys and other secure memory.
- The system software is a small, multitasking
- microkernel, Mach 3.0, from Carnegie Mellon
- University. I will discuss the advantages and the
- disadvantages we've encountered in using Mach
- for this project.
-
- BOF Report
-
- by Rich Salz, Open Software Foundation
- <rsalz@osf.org>
-
- A good BOF can be one of the best things to do at
- a USENIX Conference - it can keep you going all
- night.
-
- BOF stands for Birds of a Feather, as in "flock
- together." It's an informal gathering of people
- who are interested in a particular area. Many
- BOFs are scheduled before the conference and
- announced in the conference schedule. Others are
- "scheduled" on site, and announced by posting a
- notice on the general message board. BOFs are
- not part of the standard conference track. They
- are generally held after-hours and anyone can
- attend. Many of them ``adjourn to the bar,'' where
- the discussions can go on for hours.
-
- This Summer Conference's BOF topics included:
- a discussion of Standards (POSIX et al), Distrib-
- uted Systems Administration, Gays in comput-
- ing, EFF, FSF, Usenet, NNTP, UUNET, Ultrix, Alpha,
- BSD4.4, BSDI, and Obfuscated C. I think one of the
- best things to do is to go to an area that's new to
- you. It's a great way to get practical knowledge in
- an informal setting, and a good way to meet
- experts in the field.
-
- Unfortunately, I didn't do that this year: I went to
- the Usenet-related BOFs because I "had to," and
- others because I wanted to get a status report. So,
- while there were no doubt lots of good things
- happening at FSF, EFF, Distributed Systems, and
- so on, I can't tell you about them.
-
- Tuesday: News Software & USENET
-
- This BOF was run by Henry Spencer and Geoff
- Collyer. It started with an update on C News. The
- Performance Release (including much work done
- by Geoff for UUNET) is out, and the Clean-Up
- Release won't be out for ``quite a while.'' This
- next release will have a revised source tree, and
- (to the cheers of the crowd) most of the build
- work will be done directly in the Makefiles.
-
- News volume is still doubling yearly, and the
- growth in newsgroups is (apparently) causing
- problems for some newsreaders, most noticeably
- when sorting the active file or deleting a news-
- group. Newsreader writers, beware: the net is
- growing faster than you think!
-
- The volume and newsreaders then led into a dis-
- cussion of threads programs like trn. Geoff is
- thinking about looking into the issue of threads
- databases, saying ``mthreads must go.'' On the
- other hand, we did get to hear the only nice thing
- Geoff has ever said about NFS: ``for reading
- news, NFS is pretty good.'' There was also talk
- about changing the news filesystem format, to
- which Geoff replied ``fix namei.''
-
- Bruce Jones, from the School of Communications
- at UCSD, is doing his doctorate on the growth of
- Usenet. He has Henry's old tapes from the start of
- Usenet and is trying to gauge the interest in get-
- ting a CD-ROM of, say, the first A News ``Car for
- Sale'' ad. If you're interested, send email to
- <bjones@ucsd.edu>.
-
- Stan Barber spoke about the next release of NNTP.
- The client and server code has been split into
- pieces and the client code is in beta-test. It's
- already been ported to some PCs. The new server
- should go into alpha-test in July. If you have some
- new feature or bug fixes, let Stan know. In partic-
- ular, if you can help make it work well with C
- News he'd like to hear from you. Stan can be
- reached as <nntp@tmc.edu>.
-
- Wednesday Night BOFs
-
- On Wednesday I attended the standard Usenet
- and hackers BOF track: UUNET, Obfuscated C,
- BSDI, and 4.4BSD. Even though each was only an
- hour long, this was a long night.
-
- Unfortunately, I missed most of the UUNET BOF. I
- wandered in during a discussion of Alternet
- (UUNET's commercial IP network, no traffic
- restrictions). People are interested in low-cost
- methods like dial-up IP service. Rick Adams
- mentioned a bit about how the FBI is a customer.
- People concerned about the FBI reading netnews
- should make a reality check: the FBI wants to
- catch serial killers, they couldn't care less about
- obnoxious netnews postings!
-
- UUNET has also written another version of UUCP.
- BSDI has licensed it, and all UUNET customers
- will probably be able to get it, too. The most inter-
- esting thing about the UUNET UUCP is that you
- can replace the front-end configuration files so
- that it looks like whatever version of UUCP you
- want it to. Only BSD is supported, but HDB is an
- obvious next choice.
-
- Every year Landon Noll asks the people of
- Usenet to send him the most twisted C code they
- can write, and in the spring and summer he and
- his group evaluate the results and pick the best
- (or is it the worst?) they can find. No program
- could be more than 1,536 bytes of non-white-
- space, and no ``cc'' line could be more than 256
- bytes. Lots of whitespace was allowed this year,
- which made most of the programs a little less fun
- to look at. For the first time, there were more non-
- US winners that those from the United States.
- Every year, this is one of the best BOFs: it's very
- technical, in a weird sort of way, and it's very
- funny.
-
- I also detected a decided ``tools'' bent to this
- year's winners. It would have made a nice con-
- trast to the FSF BOF. While GNU software does lots
- of nice things, nobody will ever say it's small. At
- the Obfuscated C BOF, however, we got to see a
- chess program (written by Vern Paxson, the
- author of flex) that reportedly held its own
- against GNU Chess. There was also a make-like
- program that had some novel features. Both of
- these listings could fit on a single page!
-
- The full results will be posted to the net (in com-
- p.lang.c, misc.misc, and other places) in a month
- or two. Landon also warned people that he and
- Larry Wall are working on an obfuscated Perl
- contest, which many in the crowd thought was
- kind of redundant.
-
- Berkeley Systems Design, Inc., (BSDI) is a new
- start-up that is selling BSD operating systems for
- the 386-family of machines. It's a small company,
- still struggling to meet their weekly payroll. For
- about a thousand dollars, you get the full source
- code to BSD, X, NFS, and other tools - and binaries
- to run it on your IBM PC or clone. This was the
- most overtly commercial BOF I attended: Rob
- Kolstad is an entertaining speaker, but it was
- clearly a vendor presentation. It gave information
- people clearly wanted to hear, however: the room
- was packed. The part I found most interesting
- was that USL (the branch of AT&T in charge of
- Unix) is suing BSDI. While you can never be sure
- when lawyers are involved, it would seem that
- they are taking exception to the claim that the
- Berkeley "Net II" release, upon which BSDI's
- product is based, is unencumbered. I'm guessing
- that BSDI was picked because they are the first
- commercial venture that hasn't bought some sort
- of license from AT&T. For more information on
- BSDI, contact <info@bsdi.com>.
-
- The last BOF of the evening was the 4.4BSD BOF,
- led by Kirk McKusick and Keith Bostic of Com-
- puter Systems Research Group. The schedule
- said that this would include a report on the
- release schedule for 4.4BSD. This was very
- unusual as the CSRG folks from Berkeley have
- never previously announced their release sched-
- ule. Anyhow, 4.4 will be available in two formats:
- 4.4 and 4.4 "light." The former will require an
- AT&T license; the latter will contain only the
- freely-redistributable source code. This will be
- more complete than earlier free releases, but will
- still need some work on the kernel. Both the alpha
- and the final release will be available in both for-
- mats.
-
- 4.4 will have lots of filesystem features: 64 bit file-
- sizes (using the longlong datatype), NFS ``leases''
- that make NFS more efficient and robust, stack-
- able filesystems (similar to what David Rosenthal
- discussed at Baltimore; the BSD work comes from
- UCLA and the Ficus project), /dev/fd, the log-
- based filesystem (from Sprite), and so on. It will
- also make uid and gid be 32 bits, further changing
- the stat structure. These changes will all be in the
- alpha release because they involve changes in the
- system interface. The final release will have new
- TCP/IP work from Van Jacobson, the Berkeley
- streams package, and probably a new virtual
- memory system (from Mach). It will also contain
- as many documentation updates and bug fixes as
- possible. Sun has donated their shared library
- architecture, and that may also be a part of 4.4. I
- can't read my notes at this point, but I think the
- supported architectures include the Sparc,
- HP9000, Tahoe, and others.
-
- The bad news is that once 4.4 is solidly out the
- door, the CSRG Group is shutting down. They
- explained that it is hard to get more funding, the
- University is using BSD less, it is too big for the
- current group to develop, and that the past year
- has not been fun: too much politics and name-
- calling. It's probably safe to say that the worksta-
- tion industry would not have happened without
- BSD, and that many of us would be doomed to be
- filling out RPG II forms in dimly-lit cubicles.
- Thanks, guys!
-
- Thursday BOFs
-
- Thursday night is always a questionable night for
- BOFs because things are always scattershot after
- the USENIX reception. This didn't stop me from
- scheduling the third Usenet-type BOF of the con-
- ference, however. This one concentrated on
- NNTP. The NNTP protocol is being revised by an
- Internet Engineering Task Force committee. Most
- of the revisions are related to supporting batching
- and other facilities for low-speed links. The cur-
- rent draft is available for FTP from turbo.bio.net
- in ~ftp/ietf-nntp. The group is not concentrating
- on facilities for news-readers. There is an unoffi-
- cial group working on that; send mail to
- <David_ascher@brown.edu> if you are interested in
- that area.
-
- Stan Barber gave another preview of upcoming
- NNTP releases and asked for some feedback on
- specific changes to the client-side inews that is
- part of NNTP. This led to some discussion about
- news headers. There were lots of questions for me
- about INN, my Usenet/NNTP implementation. I
- mentioned it at last year's BOF and presented a
- paper on it this year so people were fairly curi-
- ous. By the time you read this, the software
- should be available, however, so I won't take up
- any more space on self-aggrandizement.
-
- One last-minute BOF that was held on Thursday
- was for archive maintainers. This group is start-
- ing a very exciting project to make a universal
- card-catalog for software available on the net.
- Many of the people involved -- Rich Morin, Ed
- Vilmietti -- have lots of experience with public
- archives, and it sounds like they have a good plan
- of attack. For more information, contact cfcl!rich.
-
- Well, that's it. I hope you thought this useful, and
- that it spurred your interest to become a full-
- fledged USENIX BOFfer.
-
-