home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / org / usenix / 841 < prev    next >
Encoding:
Internet Message Format  |  1992-07-25  |  21.2 KB

  1. Path: sparky!uunet!usenix!carolyn
  2. From: carolyn@usenix.ORG (Carolyn Carr)
  3. Newsgroups: comp.org.usenix
  4. Subject: USENIX Summer '92 Conference Report
  5. Keywords: USENIX Association
  6. Message-ID: <1149@usenix.ORG>
  7. Date: 24 Jul 92 19:21:28 GMT
  8. Organization: Usenix Association Office, Berkeley
  9. Lines: 530
  10.  
  11.  
  12. USENIX Summer '92 Conference Report
  13. ***********************************
  14.  
  15. Best Paper Winners
  16.  
  17. Doug Moen of Sietec Open Systems Division was 
  18. given the Best Paper Award for "A Discipline of 
  19. Error Handling."
  20.  
  21. Mary Baker and Mark Sullivan, UC Berkeley
  22. authors of "The Recover Box", won the Best
  23. Student Paper Award.
  24.  
  25. Both papers have been published in the USENIX 
  26. Summer 1992 Technical Conference Proceedings.
  27.  
  28.  
  29. Works-in-Progress Report: 
  30. Organized by Lisa A. Bloch, Sun User Group and 
  31. coordinated by Peg Schafer, BBN Systems
  32.  
  33. A Hybrid Performance Model for NFS File
  34. Servers, David N. Williams, Ericsson Network Systems, 
  35. Richardson, TX <exudnw@exu.ericsson.se>
  36.  
  37. In this session we will report on a Hybrid simula-
  38. tion model of NFS client-server transactions.
  39.  
  40. Our current environment consists of over 400 
  41. diskless SPARC workstations supported by nine 
  42. Sune 4/490 active servers. Benchmarks combined 
  43. with trial and error were the prime methods used 
  44. in arriving at the current configuration.
  45.  
  46. A number of benchmarks exist to assist in select-
  47. ing and tuning NFS servers, but benchmarking 
  48. has its perils and limitations. Vendor-supplied 
  49. benchmark numbers are frequently suspect, and 
  50. not every organization has the resources or skills 
  51. required to achieve accurate and meaningful 
  52. results. Even after spending extensive time 
  53. benchmarking a server, the results may not pro-
  54. vide sufficient information on how it will work in 
  55. a specific environment.
  56.  
  57. A discrete event simulation model of the NFS 
  58. client-server relationship has been built which 
  59. provides an approximate model of existing or 
  60. proposed client-server configurations. The model 
  61. allows for flexibility in changing parameters and 
  62. does not require the investment in time, and pos-
  63. sibly money, that comes with benchmarking.
  64.  
  65. Phonestation: Moving the telephone onto the
  66. Virtual Desktop, Stephen Uhler, Bellcore
  67. <sau@bellcore.com> 
  68.  
  69. The PhoneStation system is a tool that allows a 
  70. Sun SPARCstation to control an ordinary tele-
  71. phone line. It consists of: 1) a micro-controller 
  72. that interfaces a telephone line with a SPARCsta-
  73. tion via a serial port and the audio connector, 2) a 
  74. software library for the SPARCstation that pro-
  75. vides telephone interface control, digital signal 
  76. processing (e.g., touch-tone detection), and text 
  77. to speech conversion, and 3) a TCL based lan-
  78. guage for writing telephone applications.
  79.  
  80. As an example, the system can be used to inte-
  81. grate answering machine functionality into the 
  82. workstation environment. Voice messages 
  83. appear as ordinary electronic mail and are played 
  84. through the SPARCstation speaker. If mail is read 
  85. from a dumb terminal, the PhoneStation system 
  86. places a call to a user specified telephone number 
  87. and plays the voice portions of any messages.
  88.  
  89. Texas: An efficient, highly compatible persistent ob-
  90. ject store using pointer swizzling at page fault time
  91.  
  92. Vivek Singhal, University of Texas at Austin 
  93. <singhal@cs.utexas.edu>
  94.  
  95. Texas is a persistent object store that implements 
  96. huge address spaces efficiently on standard hard-
  97. ware. Pointer swizzling (address translation) at 
  98. page fault time converts the pointers in a page 
  99. from a long format into normal, hardware-sup-
  100. ported virtual addresses when pages are brought 
  101. into memory. This translation is transparent to 
  102. compiled programs, allowing the use of existing 
  103. compilers with little or no modification. Modern 
  104. UNIXes such as SVR4 and OSF/1 provide the 
  105. necessary control over virtual memory with no 
  106. modifications to the operating system.
  107.  
  108. Gumby: The portable, high-performance file system 
  109. that rides on the back of your Pokey file system 
  110. Sheetal V. Kakkad, University of Texas at Austin
  111.  
  112. Gumby is a simple log-structured file system 
  113. built on a normal UNIX file system. The file sys-
  114. tem is built inside a single UNIX file, requiring no 
  115. dependencies on underlying disk geometry, so it 
  116. is quite portable. Log structure avoids the use of 
  117. a single "home" disk block for a logical file block, 
  118. allowing any block to be written anywhere. This 
  119. optimizes the file system for use with large RAM 
  120. caches, which tend to absorb most reads and 
  121. increase the proportion of writes. We intend to 
  122. experiment with reordering read-only pages as 
  123. well, to dynamically increase locality and reduce 
  124. seeks caused by read misses.
  125.  
  126. Knowledge-Based Systems Construction in C++,
  127. Vladimir Bacvanski, Aachen University of Tech-
  128. nology, Germany <vladimir@rwthi3.informatik.rwth-aachen.de>
  129.  
  130. The examination of an applicability of appealing 
  131. techniques from object-oriented software engi-
  132. neering to knowledge-based systems domain is 
  133. discussed, focusing on the promising role of C++ 
  134. in this context. The entrance of expert systems 
  135. into real industrial application arena has uncov-
  136. ered weak points of the current knowledge-based 
  137. systems technology, especially the incomprehen-
  138. sibility, poor performance, and inability to inte-
  139. grate with non-knowledge-based systems.
  140.  
  141. The use of C++ for building technical expert sys-
  142. tems should provide one possible framework for 
  143. overcoming the current deficiencies. The code of 
  144. a knowledge representation language is trans-
  145. lated into C++, bringing the possibility to use 
  146. knowledge-based techniques while remaining in 
  147. the well known environment, so that developers 
  148. do not have to abandon all their skills and move 
  149. to expensive and incompatible specialized artifi-
  150. cial intelligence workstations. Moreover, the 
  151. combination of multiple paradigms (object-ori-
  152. ented, procedural, and the rule-based one) in the 
  153. C++ framework produces a synergetic result.
  154.  
  155. A new multi-paradigm system architecture is 
  156. examined together with mechanisms which 
  157. diminish the impedance mismatch between 
  158. object-oriented knowledge and non-knowledge-
  159. based systems, providing interchangeability of 
  160. objects which follow different paradigms. The 
  161. object-oriented paradigm is used not only to 
  162. model the applications, but the system's internal 
  163. components as well. The correspondence 
  164. between different constructs from the object-ori-
  165. ented and knowledge-based systems will be 
  166. investigated, showing that it is possible and prof-
  167. itable to model knowledge-based systems with a 
  168. set of C++ classes.
  169.  
  170. Development of an event based debugger with source 
  171. level capabilities, J. G. Posthuma, J. Scholten, J. G. Wijnstra;
  172. U. Twente, Netherlands <posthuma@cs.utwente.nl>
  173.  
  174. Finding a bug in an application is time consum-
  175. ing and expensive. For parallel applications, 
  176. debugging is even harder. The behavior of paral-
  177. lel applications can only be understood by look-
  178. ing at them with great abstraction. Only specified 
  179. events of the system should be presented to the 
  180. user. But such events only give a hint where a bug 
  181. could be. After this hint, the user has to look with 
  182. greater detail. He should be able to specify both 
  183. events of higher abstraction (for example com-
  184. munication) and source level debug events.
  185.  
  186. Events are the basis of the debugger. An event is 
  187. generated each time an important point is 
  188. reached in the execution. These points can be 
  189. specified by the programmer. An event will often 
  190. be used to indicate a place where interaction 
  191. between two processes takes place, since interac-
  192. tion is an important aspect of parallel applica-
  193. tions. The events of all processes are merged into 
  194. one event stream. This stream can be used 
  195. directly or stored in a database for later use. For a 
  196. long running or multi-process application, the 
  197. event stream can be quite voluminous. That is 
  198. why a number of tools are provided to make the 
  199. event stream data more manageable. The pro-
  200. grammer has the possibility of reducing the com-
  201. plexity by specifying filters, which remove those 
  202. events in which the user is not interested.
  203.  
  204. Another important tool is the behavior recog-
  205. nizer. A recognizer matches behavior as specified 
  206. by the user in terms of events against the event 
  207. stream generated by the application. It is not only 
  208. possible to specify the expected behavior, but also 
  209. the behavior that is not allowed. Recognizers can 
  210. be used in a number of ways. First of all they can 
  211. be used to trace down the places where the spec-
  212. ified behavior is violated. Secondly, recognizers 
  213. are useful to summarize the behavior by replac-
  214. ing a number of events from the stream with one 
  215. new high level event. This allows the program-
  216. mer to analyze the system at different levels of 
  217. abstraction. A third possibility is to use recogniz-
  218. ers to specify interesting points in execution 
  219. where some action must be performed, like a 
  220. request for process status. This last option is only 
  221. possible for run time debugging. The recognizers 
  222. are also useful for analyzing events in the data-
  223. base.
  224.  
  225. The debugger is a mixture of an event based 
  226. debugger, source level debugge, and a behavior 
  227. recognition system. The event based part of the 
  228. debugger concentrates on distributed aspects of 
  229. the application and can be used during or after 
  230. execution. It is not always possible to debug an 
  231. application when using the event based ap-
  232. proach. That is why the normal source level 
  233. debugger will be integrated in the design. In the 
  234. future, other features may be added, in order to 
  235. make it a complete debugger for distributed 
  236. applications.
  237.  
  238. MACH on a Physically Secure Crypto Coprocessor
  239. Elaine Palmer, IBM Research Division, Yorktown 
  240. Heights, New York <epalmer@watson.ibm.com>
  241.  
  242. I will present an overview of a secure crypto-
  243. graphic workstation coprocessor. The prototype 
  244. hardware, named `Citadel', was completed in 
  245. 1991 at IBM's T.J. Watson Research Center. It can 
  246. perform DES encryption and decryption of data 
  247. at high speeds.
  248.  
  249. We envision its use in three possible application 
  250. environments:
  251.  
  252.  1. It can be embedded in a communications con-
  253. troller (wire or fiber) to encrypt or decrypt some 
  254. or all network traffic.
  255.  
  256.  2. It can be embedded in a disk controller to 
  257. encrypt or decrypt selected files or an entire disk.
  258.  
  259.  3. It can be installed as a secure, general purpose 
  260. crypto coprocessor on a microchannel bus. In this 
  261. environment it can be used to encrypt or decrypt 
  262. passwords, authenticate users and requests for 
  263. resources, encrypt or decrypt transactions, or 
  264. process sensitive data from the main host proces-
  265. sor.
  266.  
  267. In all three applications, encryption and decryp-
  268. tion does not degrade the throughput of its host 
  269. device. The host for our prototype is an IBM
  270. PS/2.
  271.  
  272. The hardware and kernel software are designed 
  273. to operate in a physically secure package. If the 
  274. package detects tampering, it responds by eras-
  275. ing its encryption keys and other secure memory. 
  276. The system software is a small, multitasking 
  277. microkernel, Mach 3.0, from Carnegie Mellon 
  278. University. I will discuss the advantages and the 
  279. disadvantages we've encountered in using Mach 
  280. for this project.
  281.  
  282. BOF Report
  283.  
  284. by Rich Salz, Open Software Foundation
  285. <rsalz@osf.org> 
  286.  
  287. A good BOF can be one of the best things to do at 
  288. a USENIX Conference - it can keep you going all 
  289. night.
  290.  
  291. BOF stands for Birds of a Feather, as in "flock 
  292. together." It's an informal gathering of people 
  293. who are interested in a particular area. Many 
  294. BOFs are scheduled before the conference and 
  295. announced in the conference schedule. Others are 
  296. "scheduled" on site, and announced by posting a 
  297. notice on the general message board. BOFs are 
  298. not part of the standard conference track. They 
  299. are generally held after-hours and anyone can 
  300. attend. Many of them ``adjourn to the bar,'' where 
  301. the discussions can go on for hours.
  302.  
  303. This Summer Conference's BOF topics included: 
  304. a discussion of Standards (POSIX et al), Distrib-
  305. uted Systems Administration, Gays in comput-
  306. ing, EFF, FSF, Usenet, NNTP, UUNET, Ultrix, Alpha, 
  307. BSD4.4, BSDI, and Obfuscated C. I think one of the 
  308. best things to do is to go to an area that's new to 
  309. you. It's a great way to get practical knowledge in 
  310. an informal setting, and a good way to meet 
  311. experts in the field.
  312.  
  313. Unfortunately, I didn't do that this year: I went to 
  314. the Usenet-related BOFs because I "had to," and 
  315. others because I wanted to get a status report. So, 
  316. while there were no doubt lots of good things 
  317. happening at FSF, EFF, Distributed Systems, and 
  318. so on, I can't tell you about them.
  319.  
  320. Tuesday: News Software & USENET
  321.  
  322. This BOF was run by Henry Spencer and Geoff 
  323. Collyer. It started with an update on C News. The 
  324. Performance Release (including much work done 
  325. by Geoff for UUNET) is out, and the Clean-Up 
  326. Release won't be out for ``quite a while.'' This 
  327. next release will have a revised source tree, and 
  328. (to the cheers of the crowd) most of the build 
  329. work will be done directly in the Makefiles.
  330.  
  331. News volume is still doubling yearly, and the 
  332. growth in newsgroups is (apparently) causing 
  333. problems for some newsreaders, most noticeably 
  334. when sorting the active file or deleting a news-
  335. group. Newsreader writers, beware: the net is 
  336. growing faster than you think!
  337.  
  338. The volume and newsreaders then led into a dis-
  339. cussion of threads programs like trn. Geoff is 
  340. thinking about looking into the issue of threads 
  341. databases, saying ``mthreads must go.'' On the 
  342. other hand, we did get to hear the only nice thing 
  343. Geoff has ever said about NFS: ``for reading 
  344. news, NFS is pretty good.'' There was also talk 
  345. about changing the news filesystem format, to 
  346. which Geoff replied ``fix namei.''
  347.  
  348. Bruce Jones, from the School of Communications 
  349. at UCSD, is doing his doctorate on the growth of 
  350. Usenet. He has Henry's old tapes from the start of 
  351. Usenet and is trying to gauge the interest in get-
  352. ting a CD-ROM of, say, the first A News ``Car for 
  353. Sale'' ad. If you're interested, send email to 
  354. <bjones@ucsd.edu>.
  355.  
  356. Stan Barber spoke about the next release of NNTP. 
  357. The client and server code has been split into 
  358. pieces and the client code is in beta-test. It's 
  359. already been ported to some PCs. The new server 
  360. should go into alpha-test in July. If you have some 
  361. new feature or bug fixes, let Stan know. In partic-
  362. ular, if you can help make it work well with C 
  363. News he'd like to hear from you. Stan can be 
  364. reached as <nntp@tmc.edu>.
  365.  
  366. Wednesday Night BOFs
  367.  
  368. On Wednesday I attended the standard Usenet 
  369. and hackers BOF track: UUNET, Obfuscated C, 
  370. BSDI, and 4.4BSD. Even though each was only an 
  371. hour long, this was a long night.
  372.  
  373. Unfortunately, I missed most of the UUNET BOF. I 
  374. wandered in during a discussion of Alternet 
  375. (UUNET's commercial IP network, no traffic 
  376. restrictions). People are interested in low-cost 
  377. methods like dial-up IP service. Rick Adams 
  378. mentioned a bit about how the FBI is a customer. 
  379. People concerned about the FBI reading netnews 
  380. should make a reality check: the FBI wants to 
  381. catch serial killers, they couldn't care less about 
  382. obnoxious netnews postings!
  383.  
  384. UUNET has also written another version of UUCP. 
  385. BSDI has licensed it, and all UUNET customers 
  386. will probably be able to get it, too. The most inter-
  387. esting thing about the UUNET UUCP is that you 
  388. can replace the front-end configuration files so 
  389. that it looks like whatever version of UUCP you 
  390. want it to. Only BSD is supported, but HDB is an 
  391. obvious next choice.
  392.  
  393. Every year Landon Noll asks the people of 
  394. Usenet to send him the most twisted C code they 
  395. can write, and in the spring and summer he and 
  396. his group evaluate the results and pick the best 
  397. (or is it the worst?) they can find. No program 
  398. could be more than 1,536 bytes of non-white-
  399. space, and no ``cc'' line could be more than 256 
  400. bytes. Lots of whitespace was allowed this year, 
  401. which made most of the programs a little less fun 
  402. to look at. For the first time, there were more non-
  403. US winners that those from the United States. 
  404. Every year, this is one of the best BOFs: it's very 
  405. technical, in a weird sort of way, and it's very 
  406. funny.
  407.  
  408. I also detected a decided ``tools'' bent to this 
  409. year's winners. It would have made a nice con-
  410. trast to the FSF BOF. While GNU software does lots 
  411. of nice things, nobody will ever say it's small. At 
  412. the Obfuscated C BOF, however, we got to see a 
  413. chess program (written by Vern Paxson, the 
  414. author of flex) that reportedly held its own 
  415. against GNU Chess. There was also a make-like 
  416. program that had some novel features. Both of 
  417. these listings could fit on a single page!
  418.  
  419. The full results will be posted to the net (in com-
  420. p.lang.c, misc.misc, and other places) in a month 
  421. or two. Landon also warned people that he and 
  422. Larry Wall are working on an obfuscated Perl 
  423. contest, which many in the crowd thought was 
  424. kind of redundant.
  425.  
  426. Berkeley Systems Design, Inc., (BSDI) is a new 
  427. start-up that is selling BSD operating systems for 
  428. the 386-family of machines. It's a small company, 
  429. still struggling to meet their weekly payroll. For 
  430. about a thousand dollars, you get the full source 
  431. code to BSD, X, NFS, and other tools - and binaries 
  432. to run it on your IBM PC or clone. This was the 
  433. most overtly commercial BOF I attended: Rob 
  434. Kolstad is an entertaining speaker, but it was 
  435. clearly a vendor presentation. It gave information 
  436. people clearly wanted to hear, however: the room 
  437. was packed. The part I found most interesting 
  438. was that USL (the branch of AT&T in charge of 
  439. Unix) is suing BSDI. While you can never be sure 
  440. when lawyers are involved, it would seem that 
  441. they are taking exception to the claim that the 
  442. Berkeley "Net II" release, upon which BSDI's 
  443. product is based, is unencumbered. I'm guessing 
  444. that BSDI was picked because they are the first 
  445. commercial venture that hasn't bought some sort 
  446. of license from AT&T. For more information on 
  447. BSDI, contact <info@bsdi.com>.
  448.  
  449. The last BOF of the evening was the 4.4BSD BOF, 
  450. led by Kirk McKusick and Keith Bostic of Com-
  451. puter Systems Research Group. The schedule 
  452. said that this would include a report on the 
  453. release schedule for 4.4BSD. This was very 
  454. unusual as the CSRG folks from Berkeley have 
  455. never previously announced their release sched-
  456. ule. Anyhow, 4.4 will be available in two formats: 
  457. 4.4 and 4.4 "light." The former will require an 
  458. AT&T license; the latter will contain only the 
  459. freely-redistributable source code. This will be 
  460. more complete than earlier free releases, but will 
  461. still need some work on the kernel. Both the alpha 
  462. and the final release will be available in both for-
  463. mats.
  464.  
  465. 4.4 will have lots of filesystem features: 64 bit file-
  466. sizes (using the longlong datatype), NFS ``leases'' 
  467. that make NFS more efficient and robust, stack-
  468. able filesystems (similar to what David Rosenthal 
  469. discussed at Baltimore; the BSD work comes from 
  470. UCLA and the Ficus project), /dev/fd, the log-
  471. based filesystem (from Sprite), and so on. It will 
  472. also make uid and gid be 32 bits, further changing 
  473. the stat structure. These changes will all be in the 
  474. alpha release because they involve changes in the 
  475. system interface. The final release will have new 
  476. TCP/IP work from Van Jacobson, the Berkeley 
  477. streams package, and probably a new virtual 
  478. memory system (from Mach). It will also contain 
  479. as many documentation updates and bug fixes as 
  480. possible. Sun has donated their shared library 
  481. architecture, and that may also be a part of 4.4. I 
  482. can't read my notes at this point, but I think the 
  483. supported architectures include the Sparc, 
  484. HP9000, Tahoe, and others.
  485.  
  486. The bad news is that once 4.4 is solidly out the 
  487. door, the CSRG Group is shutting down. They 
  488. explained that it is hard to get more funding, the 
  489. University is using BSD less, it is too big for the 
  490. current group to develop, and that the past year 
  491. has not been fun: too much politics and name-
  492. calling. It's probably safe to say that the worksta-
  493. tion industry would not have happened without 
  494. BSD, and that many of us would be doomed to be 
  495. filling out RPG II forms in dimly-lit cubicles. 
  496. Thanks, guys!
  497.  
  498. Thursday BOFs
  499.  
  500. Thursday night is always a questionable night for 
  501. BOFs because things are always scattershot after 
  502. the USENIX reception. This didn't stop me from 
  503. scheduling the third Usenet-type BOF of the con-
  504. ference, however. This one concentrated on 
  505. NNTP. The NNTP protocol is being revised by an 
  506. Internet Engineering Task Force committee. Most 
  507. of the revisions are related to supporting batching 
  508. and other facilities for low-speed links. The cur-
  509. rent draft is available for FTP from turbo.bio.net 
  510. in ~ftp/ietf-nntp. The group is not concentrating 
  511. on facilities for news-readers. There is an unoffi-
  512. cial group working on that; send mail to
  513. <David_ascher@brown.edu> if you are interested in 
  514. that area.
  515.  
  516. Stan Barber gave another preview of upcoming 
  517. NNTP releases and asked for some feedback on 
  518. specific changes to the client-side inews that is 
  519. part of NNTP. This led to some discussion about 
  520. news headers. There were lots of questions for me 
  521. about INN, my Usenet/NNTP implementation. I 
  522. mentioned it at last year's BOF and presented a 
  523. paper on it this year so people were fairly curi-
  524. ous. By the time you read this, the software 
  525. should be available, however, so I won't take up 
  526. any more space on self-aggrandizement.
  527.  
  528. One last-minute BOF that was held on Thursday 
  529. was for archive maintainers. This group is start-
  530. ing a very exciting project to make a universal 
  531. card-catalog for software available on the net. 
  532. Many of the people involved -- Rich Morin, Ed 
  533. Vilmietti -- have lots of experience with public 
  534. archives, and it sounds like they have a good plan 
  535. of attack. For more information, contact cfcl!rich.
  536.  
  537. Well, that's it. I hope you thought this useful, and 
  538. that it spurred your interest to become a full-
  539. fledged USENIX BOFfer.
  540.  
  541.