APRIL 2006 VOLUME 31 NUMBER 2 THE USENIX MAGAZINE OPINION Musings RIK FARROW OpenSolaris:The Model TOM HAYNES PROGRAMMING Code Testing and Its Role in Teaching BRIAN KERNIGHAN Modular System Programming in MINIX 3 JORRIT N. HERDER, HERBERT BOS, BEN GRAS, PHILIP HOMBURG, AND ANDREW S. TANENBAUM Some Types of Memory Are More Equal Than Others DIOMEDIS SPINELLIS Simple Software Flow Analysis Using GNU Cflow CHAOS GOLUBITSKY Why You Should Use Ruby LU KE KANIES SYSADMIN Unwanted HTTP:Who Has the Time? DAVI D MALONE Auditing Superuser Usage RANDOLPH LANGLEY C OLUMNS Practical Perl Tools:Programming, Ho Hum DAVID BLANK-EDELMAN VoIP Watch HEISON CHAK /dev/random ROBERT G. FERRELL STANDARDS USENIX Standards Activities NICHOLAS M. STOUGHTON B O OK REVIEWS Book Reviews ELIZABETH ZWICKY, WITH SAM STOVER AND RI K FARROW USENIX NOTES Letter to the Editor TED DOLOTTA Fund to Establish the John Lions Chair C ONFERENCES LISA ’05:The 19th Large Installation System Administration Conference WORLDS ’05: Second Workshop on Real, Large Distributed Systems FAST ’05: 4th USENIX Conference on File and Storage Technologies The Advanced Computing Systems Association Upcoming Events 3RD SYMPOSIUM ON NETWORKED SYSTEMS 2ND STEPS TO REDUCING UNWANTED TRAFFIC ON DESIGN AND IMPLEMENTATION (NSDI ’06) THE INTERNET WORKSHOP (SRUTI ’06) Sponsored by USENIX, in cooperation with ACM SIGCOMM JULY 6–7, 2006, SAN JOSE, CA, USA and ACM SIGOPS http://www.usenix.org/sruti06 MAY 8–10, 2006, SAN JOSE, CA, USA Paper submissions due: April 20, 2006 http://www.usenix.org/nsdi06 2006 LINUX KERNEL DEVELOPERS SUMMIT 5TH SYSTEM ADMINISTRATION AND NETWORK JULY 16–18, 2006, OTTAWA, ONTARIO, CANADA ENGINEERING CONFERENCE (SANE 2006) http://www.usenix.org/kernel06 Organized by Stichting SANE and co-sponsored by Stichting NLnet, USENIX, and SURFnet 15TH USENIX SECURITY SYMPOSIUM MAY 15–19, 2006, DELFT, THE NETHERLANDS (SECURITY ’06) http://www.sane.nl/sane2006 JULY 31–AUGUST 4, 2006, VANCOUVER, B.C., CANADA http://www.usenix.org/sec06 2006 USENIX ANNUAL TECHNICAL CONFERENCE (USENIX ’06) 2006 USENIX/ACCURATE ELECTRONIC MAY 30–JUNE 3, 2006, BOSTON, MA, USA VOTING TECHNOLOGY WORKSHOP (EVT ’06) http://www.usenix.org/usenix06 AUGUST 1, 2006, VANCOUVER, B.C., CANADA http://www.usenix.org/evt06 FIRST WORKSHOP ON HOT TOPICS IN Paper submissions due: April 3, 2006 AUTONOMIC COMPUTING (HOTAC ’06) Sponsored by IEEE Computer Society and USENIX 7TH SYMPOSIUM ON OPERATING SYSTEMS DESIGN JUNE 13, 2006, DUBLIN, IRELAND AND IMPLEMENTATION http://www.aqualab.cs.northwestern.edu/HotACI/ Sponsored by USENIX, in cooperation with ACM SIGOPS NOVEMBER 6–8, 2006, SEATTLE, WA, USA SECOND INTERNATIONAL CONFERENCE ON VIRTUAL http://www.usenix.org/osdi06 EXECUTION ENVIRONMENTS (VEE ’06) Paper submissions due: April 24, 2006 Sponsored by ACM SIGPLAN in cooperation with USENIX SECOND WORKSHOP ON HOT TOPICS IN SYSTEM JUNE 14–16, 2006, OTTAWA, ONTARIO, CANADA http://www.veeconference.org/vee06 DEPENDABILITY (HOTDEP ’06) NOVEMBER 8, 2006, SEATTLE, WA, USA http://www.usenix.org/hotdep06 4TH INTERNATIONAL CONFERENCE ON MOBILE Paper submissions due: July 15, 2006 SYSTEMS, APPLICATIONS, AND SERVICES (MOBISYS 2006) 20TH LARGE INSTALLATION SYSTEM Jointly sponsored by ACM SIGMOBILE and USENIX, in cooperation with ACM SIGOPS ADMINISTRATION CONFERENCE (LISA ’06) JUNE 19–22, 2006, UPPSALA, SWEDEN DECEMBER 3–8, 2006, WASHINGTON, D.C., USA http://www.sigmobile.org/mobisys/2006 http://www.usenix.org/lisa06 Paper submissions due: May 23, 2006 For a complete list of all USENIX & USENIX co-sponsored events, see http://www.usenix.org/events OPINION 2 Musings RIK FARROW 5 OpenSolaris:The Model TOM HAYNES PROGRAMMING 9 Code Testing and Its Role in Teaching BRIAN KERNIGHAN contents 19 Modular System Programming in MINIX 3 JORRIT N. HERDER, HERBERT BOS, BEN GRAS, PHILIP HOMBURG, AND ANDREW S TANENBAUM 29 Some Types of Memory Are More Equal Than Others DIOMEDIS SPINELLIS 37 Simple Software Flow Analysis Using GNU Cflow CHAOS GOLUBITSKY 42 Why You Should Use Ruby LUKE KANIES SYSADMIN 49 Unwanted HTTP:Who Has the Time? DAVID MALONE 56 Auditing Superuser Usage RANDOLPH LANGLEY COLUMNS 60 Practical Perl Tools:Programming, Ho Hum DAVID BLANK-EDELMAN VOL. 31, #2, APRIL 2006 66 VoIP Watch H EISON CHAK EDITOR ;login: is the official 70 /dev/random Rik Farrow magazine of the ROBERT G. FERRELL [email protected] USENIX Association. MANAGING EDITOR ;login: (ISSN 1044-6397) is STANDARDS Jane-Ellen Long published bi-monthly by the [email protected] USENIX Association, 2560 72 USENIX Standards Activities COPY EDITOR Ninth Street, Suite 215, NICHOLAS M. STOUGHTON Steve Gilmartin Berkeley, CA 94710. [email protected] $85 of each member’s annual BOOK REVIEWS dues is for an annual sub- PRODUCTION 76 Book Reviews Lisa Camp de Avalos scription to ;login:. Subscrip- Casey Henderson tions for nonmembers are ELIZABETH ZWICKY, WITH SAM STOVER $115 per year. AND RIK FARROW TYPESETTER Star Type Periodicals postage paid at USENIX NOTES [email protected] Berkeley, CA, and additional offices. USENIX ASSOCIATION 80 Letter to the Editor 2560 Ninth Street, POSTMASTER: Send address TED DOLOTTA Suite 215, Berkeley, changes to ;login:, California 94710 USENIX Association, 80 Fund to Establish the John Lions Chair Phone: (510) 528-8649 2560 Ninth Street, in Operating Systems at the FAX: (510) 548-5738 Suite 215, Berkeley, University of New South Wales CA 94710. http://www.usenix.org http://www.sage.org ©2006 USENIX Association. CONFERENCE REPORTS USENIX is a registered trade- 81 LISA ’05:The 19th Large Installation System mark of the USENIX Associa- tion. Many of the designa- Administration Conference tions used by manufacturers 99 WORLDS ’05: Second Workshop on Real, and sellers to distinguish their products are claimed as trade- Large Distributed Systems marks. USENIX acknowl- 103 FAST ’05: 4th USENIX Conference on edges all trademarks herein. Where those designations appear in this publication and File and Storage Technologies USENIX is aware of a trade- mark claim, the designations have been printed in caps or initial caps. PROGRAMMING IS AN ART. WHEN different people attempt to accomplish the RIK FARROW same tasks, their programs will generally be quite different. And when examined carefully, some programs will stand out as beautiful code, while others could quite easily be described as ugly. musings I learned programming in college, working in the painful paradigm of punchcards and mainframes. [email protected] A single typo meant waiting hours, or even until the next day, to see the results of the correction. While I believe that using punchcards encour- gaged a certain discipline, in coding and in exact- ness, it did nothing to instill in me a real under- standing of how to write beautiful programs. I could, and did, write robust, functioning code, but it certainly lacked the elegance that I could sometimes discern in other people’s code. Inelegant code, however, has effects that go beyond aesthetics. I once was tasked with writing a text formatter, with requirements similar to the ones found in Kernighan and Plauger’s Software Tools. I didn’t know of that book at the time (1979), but plowed in with vigor. When finished, I had written a program that worked correctly, taking marked-up text, formatting it, and produc- ing a table of contents, all on a computer that used two 8-inch floppy disks for file storage. Compiling the 16-page program took about 15 minutes, and using the finished program, written in PL/Z (Zilog’s version of PL/I) took a long time too. After I left that company, I found out that my replacement had been given the same task, but used BASIC instead. His version of the code ran three times faster because BASIC had much better string handling routines than PL/Z. I knew my code would be inefficient in places, and had I rewritten those places in assembler, my code would (likely) have been as fast. But I sure was embarrassed. Looking Deeper Today’s computers make the computers I learned on look like electro-mechanical calculators. The mainframe I used in college filled a room, required massive cooling, and actually used other computers for its input and output (reading punchcards, writing them to tape, and printing). The noise of the cooling fans was incredible, but so were the blinking lights, and the computers ran 2 ;LO GIN: V OL. 31, NO. 2 slowly enough that you could actually watch patterns emerge in the display of memory address accesses. With systems like these, every instruction counted. When we write programs today, we can easily be misled into believing that elegance and efficiency don’t matter. Instead, our fast computers can fool us into thinking that everything is running fine. Problems often don’t emerge until a program goes into production and fails under real loads, or turns out to include a security flaw that converts code into a back door. For this issue, I sought out programmers who were willing to write about their art. I was fortunate that Brian Kernighan was willing to share his experience in teaching advanced programming. Brian’s article explains how he uses testing to maintain AWK and uses that same testing in his classes. I found myself wondering if I would have been a better programmer had I learned the testing discipline that Brian instills in his students today. David Blank-Edelman’s Perl column also begins by discussing testing in Perl. Various Perl modules provide a framework that can be properly (or poorly) used to aid in building packages that can be tested before installation. Diomidis Spinellis has written about the effects of the many levels of per- formance found in modern computer memory. The amount of memory available to run programs at full speed on modern processors is tiny, and each additional level offers lower performance.