diff --git a/en_US.ISO8859-1/articles/contributing/article.sgml b/en_US.ISO8859-1/articles/contributing/article.sgml index ebfec31854..ef3c1d83d1 100644 --- a/en_US.ISO8859-1/articles/contributing/article.sgml +++ b/en_US.ISO8859-1/articles/contributing/article.sgml @@ -1,6357 +1,6357 @@ Contributing to FreeBSD Contributed by &a.jkh;. So you want to contribute something to FreeBSD? That is great! We can always use the help, and FreeBSD is one of those systems that relies on the contributions of its user base in order to survive. Your contributions are not only appreciated, they are vital to FreeBSD's continued growth! Contrary to what some people might also have you believe, you do not need to be a hot-shot programmer or a close personal friend of the FreeBSD core team in order to have your contributions accepted. The FreeBSD Project's development is done by a large and growing number of international contributors whose ages and areas of technical expertise vary greatly, and there is always more work to be done than there are people available to do it. Since the FreeBSD project is responsible for an entire operating system environment (and its installation) rather than just a kernel or a few scattered utilities, our TODO list also spans a very wide range of tasks, from documentation, beta testing and presentation to highly specialized types of kernel development. No matter what your skill level, there is almost certainly something you can do to help the project! Commercial entities engaged in FreeBSD-related enterprises are also encouraged to contact us. Need a special extension to make your product work? You will find us receptive to your requests, given that they are not too outlandish. Working on a value-added product? Please let us know! We may be able to work cooperatively on some aspect of it. The free software world is challenging a lot of existing assumptions about how software is developed, sold, and maintained throughout its life cycle, and we urge you to at least give it a second look. What is Needed The following list of tasks and sub-projects represents something of an amalgam of the various core team TODO lists and user requests we have collected over the last couple of months. Where possible, tasks have been ranked by degree of urgency. If you are interested in working on one of the tasks you see here, send mail to the coordinator listed by clicking on their names. If no coordinator has been appointed, maybe you would like to volunteer? High priority tasks The following tasks are considered to be urgent, usually because they represent something that is badly broken or sorely needed: 3-stage boot issues. Overall coordination: &a.hackers; Do WinNT compatible drive tagging so that the 3rd stage can provide an accurate mapping of BIOS geometries for disks. Filesystem problems. Overall coordination: &a.fs; Clean up and document the nullfs filesystem code. Coordinator: &a.eivind; Fix the union file system. Coordinator: &a.dg; Implement Int13 vm86 disk driver. Coordinator: &a.hackers; New bus architecture. Coordinator: &a.newbus; Port existing ISA drivers to new architecture. Move all interrupt-management code to appropriate parts of the bus drivers. Port PCI subsystem to new architecture. Coordinator: &a.dfr; Figure out the right way to handle removable devices and then use that as a substrate on which PC-Card and CardBus support can be implemented. Resolve the probe/attach priority issue once and for all. Move any remaining buses over to the new architecture. Kernel issues. Overall coordination: &a.hackers; Add more pro-active security infrastructure. Overall coordination: &a.security; Build something like Tripwire(TM) into the kernel, with a remote and local part. There are a number of cryptographic issues to getting this right; contact the coordinator for details. Coordinator: &a.eivind; Make the entire kernel use suser() instead of comparing to 0. It is presently using about half of each. Coordinator: &a.eivind; Split securelevels into different parts, to allow an administrator to throw away those privileges he can throw away. Setting the overall securelevel needs to have the same effect as now, obviously. Coordinator: &a.eivind; Make it possible to upload a list of allowed program to BPF, and then block BPF from accepting other programs. This would allow BPF to be used e.g. for DHCP, without allowing an attacker to start snooping the local network. Update the security checker script. We should at least grab all the checks from the other BSD derivatives, and add checks that a system with securelevel increased also have reasonable flags on the relevant parts. Coordinator: &a.eivind; Add authorization infrastructure to the kernel, to allow different authorization policies. Part of this could be done by modifying suser(). Coordinator: &a.eivind; Add code to the NFS layer so that you cannot chdir("..") out of an NFS partition. E.g., /usr is a UFS partition with /usr/src NFS exported. Now it is possible to use the NFS filehandle for /usr/src to get access to /usr. Medium priority tasks The following tasks need to be done, but not with any particular urgency: Full KLD based driver support/Configuration Manager. Write a configuration manager (in the 3rd stage boot?) that probes your hardware in a sane manner, keeps only the KLDs required for your hardware, etc. PCMCIA/PCCARD. Coordinators: &a.msmith; and &a.imp; Documentation! Reliable operation of the pcic driver (needs testing). Recognizer and handler for sio.c (mostly done). Recognizer and handler for ed.c (mostly done). Recognizer and handler for ep.c (mostly done). User-mode recognizer and handler (partially done). Advanced Power Management. Coordinators: &a.msmith; and &a.phk; APM sub-driver (mostly done). IDE/ATA disk sub-driver (partially done). syscons/pcvt sub-driver. Integration with the PCMCIA/PCCARD drivers (suspend/resume). Low priority tasks The following tasks are purely cosmetic or represent such an investment of work that it is not likely that anyone will get them done anytime soon: The first N items are from Terry Lambert terry@lambert.org NetWare Server (protected mode ODI driver) loader and sub-services to allow the use of ODI card drivers supplied with network cards. The same thing for NDIS drivers and NetWare SCSI drivers. An "upgrade system" option that works on Linux boxes instead of just previous rev FreeBSD boxes. Symmetric Multiprocessing with kernel preemption (requires kernel preemption). A concerted effort at support for portable computers. This is somewhat handled by changing PCMCIA bridging rules and power management event handling. But there are things like detecting internal v.s.. external display and picking a different screen resolution based on that fact, not spinning down the disk if the machine is in dock, and allowing dock-based cards to disappear without affecting the machines ability to boot (same issue for PCMCIA). Smaller tasks Most of the tasks listed in the previous sections require either a considerable investment of time or an in-depth knowledge of the FreeBSD kernel (or both). However, there are also many useful tasks which are suitable for "weekend hackers", or people without programming skills. If you run FreeBSD-current and have a good Internet connection, there is a machine current.FreeBSD.org which builds a full release once a day — every now and again, try and install the latest release from it and report any failures in the process. Read the freebsd-bugs mailing list. There might be a problem you can comment constructively on or with patches you can test. Or you could even try to fix one of the problems yourself. Read through the FAQ and Handbook periodically. If anything is badly explained, out of date or even just completely wrong, let us know. Even better, send us a fix (SGML is not difficult to learn, but there is no objection to ASCII submissions). Help translate FreeBSD documentation into your native language (if not already available) — just send an email to &a.doc; asking if anyone is working on it. Note that you are not committing yourself to translating every single FreeBSD document by doing this — in fact, the documentation most in need of translation is the installation instructions. Read the freebsd-questions mailing list and &ng.misc occasionally (or even regularly). It can be very satisfying to share your expertise and help people solve their problems; sometimes you may even learn something new yourself! These forums can also be a source of ideas for things to work on. If you know of any bug fixes which have been successfully applied to -current but have not been merged into -stable after a decent interval (normally a couple of weeks), send the committer a polite reminder. Move contributed software to src/contrib in the source tree. Make sure code in src/contrib is up to date. Look for year 2000 bugs (and fix any you find!) Build the source tree (or just part of it) with extra warnings enabled and clean up the warnings. Fix warnings for ports which do deprecated things like using gets() or including malloc.h. If you have contributed any ports, send your patches back to the original author (this will make your life easier when they bring out the next version) Suggest further tasks for this list! Work through the PR database The FreeBSD PR list shows all the current active problem reports and requests for enhancement that have been submitted by FreeBSD users. Look through the open PRs, and see if anything there takes your interest. Some of these might be very simple tasks, that just need an extra pair of eyes to look over them and confirm that the fix in the PR is a good one. Others might be much more complex. Start with the PRs that have not been assigned to anyone else, but if one them is assigned to someone else, but it looks like something you can handle, e-mail the person it is assigned to and ask if you can work on it—they might already have a patch ready to be tested, or further ideas that you can discuss with them. How to Contribute Contributions to the system generally fall into one or more of the following 6 categories: Bug reports and general commentary An idea or suggestion of general technical interest should be mailed to the &a.hackers;. Likewise, people with an interest in such things (and a tolerance for a high volume of mail!) may subscribe to the hackers mailing list by sending mail to &a.majordomo;. See mailing lists for more information about this and other mailing lists. If you find a bug or are submitting a specific change, please report it using the &man.send-pr.1; program or its WEB-based equivalent. Try to fill-in each field of the bug report. Unless they exceed 65KB, include any patches directly in the report. When including patches, do not use cut-and-paste because cut-and-paste turns tabs into spaces and makes them unusable. Consider compressing patches and using &man.uuencode.1; if they exceed 20KB. Upload very large submissions to ftp.FreeBSD.org:/pub/FreeBSD/incoming/. After filing a report, you should receive confirmation along with a tracking number. Keep this tracking number so that you can update us with details about the problem by sending mail to bug-followup@FreeBSD.org. Use the number as the message subject, e.g. "Re: kern/3377". Additional information for any bug report should be submitted this way. If you do not receive confirmation in a timely fashion (3 days to a week, depending on your email connection) or are, for some reason, unable to use the &man.send-pr.1; command, then you may ask someone to file it for you by sending mail to the &a.bugs;. Changes to the documentation Changes to the documentation are overseen by the &a.doc;. Send submissions and changes (even small ones are welcome!) using send-pr as described in Bug Reports and General Commentary. Changes to existing source code An addition or change to the existing source code is a somewhat trickier affair and depends a lot on how far out of date you are with the current state of the core FreeBSD development. There is a special on-going release of FreeBSD known as FreeBSD-current which is made available in a variety of ways for the convenience of developers working actively on the system. See Staying current with FreeBSD for more information about getting and using FreeBSD-current. Working from older sources unfortunately means that your changes may sometimes be too obsolete or too divergent for easy re-integration into FreeBSD. Chances of this can be minimized somewhat by subscribing to the &a.announce; and the &a.current; lists, where discussions on the current state of the system take place. Assuming that you can manage to secure fairly up-to-date sources to base your changes on, the next step is to produce a set of diffs to send to the FreeBSD maintainers. This is done with the &man.diff.1; command, with the context diff form being preferred. For example: &prompt.user; diff -c oldfile newfile or &prompt.user; diff -c -r olddir newdir would generate such a set of context diffs for the given source file or directory hierarchy. See the man page for &man.diff.1; for more details. Once you have a set of diffs (which you may test with the &man.patch.1; command), you should submit them for inclusion with FreeBSD. Use the &man.send-pr.1; program as described in Bug Reports and General Commentary. Do not just send the diffs to the &a.hackers; or they will get lost! We greatly appreciate your submission (this is a volunteer project!); because we are busy, we may not be able to address it immediately, but it will remain in the pr database until we do. If you feel it appropriate (e.g. you have added, deleted, or renamed files), bundle your changes into a tar file and run the &man.uuencode.1; program on it. Shar archives are also welcome. If your change is of a potentially sensitive nature, e.g. you are unsure of copyright issues governing its further distribution or you are simply not ready to release it without a tighter review first, then you should send it to &a.core; directly rather than submitting it with &man.send-pr.1;. The core mailing list reaches a much smaller group of people who do much of the day-to-day work on FreeBSD. Note that this group is also very busy and so you should only send mail to them where it is truly necessary. Please refer to man 9 intro and man 9 style for some information on coding style. We would appreciate it if you were at least aware of this information before submitting code. New code or major value-added packages In the case of a significant contribution of a large body work, or the addition of an important new feature to FreeBSD, it becomes almost always necessary to either send changes as uuencoded tar files or upload them to a web or FTP site for other people to access. If you do not have access to a web or FTP site, ask on an appropriate FreeBSD mailing list for someone to host the changes for you. When working with large amounts of code, the touchy subject of copyrights also invariably comes up. Acceptable copyrights for code included in FreeBSD are: The BSD copyright. This copyright is most preferred due to its no strings attached nature and general attractiveness to commercial enterprises. Far from discouraging such commercial use, the FreeBSD Project actively encourages such participation by commercial interests who might eventually be inclined to invest something of their own into FreeBSD. The GNU Public License, or GPL. This license is not quite as popular with us due to the amount of extra effort demanded of anyone using the code for commercial purposes, but given the sheer quantity of GPL'd code we currently require (compiler, assembler, text formatter, etc) it would be silly to refuse additional contributions under this license. Code under the GPL also goes into a different part of the tree, that being /sys/gnu or /usr/src/gnu, and is therefore easily identifiable to anyone for whom the GPL presents a problem. Contributions coming under any other type of copyright must be carefully reviewed before their inclusion into FreeBSD will be considered. Contributions for which particularly restrictive commercial copyrights apply are generally rejected, though the authors are always encouraged to make such changes available through their own channels. To place a BSD-style copyright on your work, include the following text at the very beginning of every source code file you wish to protect, replacing the text between the %% with the appropriate information. Copyright (c) %%proper_years_here%% %%your_name_here%%, %%your_state%% %%your_zip%%. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY %%your_name_here%% ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL %%your_name_here%% BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. $Id$ For your convenience, a copy of this text can be found in /usr/share/examples/etc/bsd-style-copyright. Money, Hardware or Internet access We are always very happy to accept donations to further the cause of the FreeBSD Project and, in a volunteer effort like ours, a little can go a long way! Donations of hardware are also very important to expanding our list of supported peripherals since we generally lack the funds to buy such items ourselves. <anchor id="donations">Donating funds While the FreeBSD Project is not a 501(c)(3) (charitable) corporation and hence cannot offer special tax incentives for any donations made, any such donations will be gratefully accepted on behalf of the project by FreeBSD, Inc. FreeBSD, Inc. was founded in early 1995 by &a.jkh; and &a.dg; with the goal of furthering the aims of the FreeBSD Project and giving it a minimal corporate presence. Any and all funds donated (as well as any profits that may eventually be realized by FreeBSD, Inc.) will be used exclusively to further the project's goals. Please make any checks payable to FreeBSD, Inc., sent in care of the following address:
FreeBSD, Inc. c/o Jordan Hubbard 4041 Pike Lane, Suite F Concord CA, 94520
(currently using the BSDi address until a PO box can be opened) Wire transfers may also be sent directly to:
Bank Of America Concord Main Office P.O. Box 37176 San Francisco CA, 94137-5176 Routing #: 121-000-358 Account #: 01411-07441 (FreeBSD, Inc.)
Any correspondence related to donations should be sent to &a.jkh, either via email or to the FreeBSD, Inc. postal address given above. If you do not wish to be listed in our donors section, please specify this when making your donation. Thanks! Donating hardware Donations of hardware in any of the 3 following categories are also gladly accepted by the FreeBSD Project: General purpose hardware such as disk drives, memory or complete systems should be sent to the FreeBSD, Inc. address listed in the donating funds section. Hardware for which ongoing compliance testing is desired. We are currently trying to put together a testing lab of all components that FreeBSD supports so that proper regression testing can be done with each new release. We are still lacking many important pieces (network cards, motherboards, etc) and if you would like to make such a donation, please contact &a.dg; for information on which items are still required. Hardware currently unsupported by FreeBSD for which you would like to see such support added. Please contact the &a.core; before sending such items as we will need to find a developer willing to take on the task before we can accept delivery of new hardware. Donating Internet access We can always use new mirror sites for FTP, WWW or cvsup. If you would like to be such a mirror, please contact the FreeBSD project administrators hubs@FreeBSD.org for more information. Donors Gallery The FreeBSD Project is indebted to the following donors and would like to publicly thank them here! Contributors to the central server project: The following individuals and businesses made it possible for the FreeBSD Project to build a new central server machine to eventually replace freefall.FreeBSD.org by donating the following items: &a.mbarkah and his employer, Hemisphere Online, donated a Pentium Pro (P6) 200Mhz CPU ASA Computers donated a Tyan 1662 motherboard. Joe McGuckin joe@via.net of ViaNet Communications donated a Kingston ethernet controller. Jack O'Neill jack@diamond.xtalwind.net donated an NCR 53C875 SCSI controller card. Ulf Zimmermann ulf@Alameda.net of Alameda Networks donated 128MB of memory, a 4 Gb disk drive and the case. Direct funding: The following individuals and businesses have generously contributed direct funding to the project: Annelise Anderson ANDRSN@HOOVER.STANFORD.EDU &a.dillon Blue Mountain Arts Epilogue Technology Corporation &a.sef Global Technology Associates, Inc Don Scott Wilde Gianmarco Giovannelli gmarco@masternet.it Josef C. Grosch joeg@truenorth.org Robert T. Morris &a.chuckr Kenneth P. Stox ken@stox.sa.enteract.com of Imaginary Landscape, LLC. Dmitry S. Kohmanyuk dk@dog.farm.org Laser5 of Japan (a portion of the profits from sales of their various FreeBSD CDROMs). Fuki Shuppan Publishing Co. donated a portion of their profits from Hajimete no FreeBSD (FreeBSD, Getting started) to the FreeBSD and XFree86 projects. ASCII Corp. donated a portion of their profits from several FreeBSD-related books to the FreeBSD project. Yokogawa Electric Corp has generously donated significant funding to the FreeBSD project. BuffNET Pacific Solutions Siemens AG - via Andre - Albsmeier + via andre.albsmeier@mchp.siemens.de">Andre + Albsmeier - Chris Silva + ras@interaccess.com">Chris Silva Hardware contributors: The following individuals and businesses have generously contributed hardware for testing and device driver development/support: BSDi for providing the Pentium P5-90 and 486/DX2-66 EISA/VL systems that are being used for our development work, to say nothing of the network access and other donations of hardware resources. TRW Financial Systems, Inc. provided 130 PCs, three 68 GB file servers, twelve Ethernets, two routers and an ATM switch for debugging the diskless code. Dermot McDonnell donated the Toshiba XM3401B CDROM drive currently used in freefall. &a.chuck; contributed his floppy tape streamer for experimental work. Larry Altneu larry@ALR.COM, and &a.wilko;, provided Wangtek and Archive QIC-02 tape drives in order to improve the wt driver. Ernst Winter ewinter@lobo.muc.de contributed a 2.88 MB floppy drive to the project. This will hopefully increase the pressure for rewriting the floppy disk driver. ;-) Tekram Technologies sent one each of their DC-390, DC-390U and DC-390F FAST and ULTRA SCSI host adapter cards for regression testing of the NCR and AMD drivers with their cards. They are also to be applauded for making driver sources for free operating systems available from their FTP server ftp://ftp.tekram.com/scsi/FreeBSD/. Larry M. Augustin contributed not only a Symbios Sym8751S SCSI card, but also a set of data books, including one about the forthcoming Sym53c895 chip with Ultra-2 and LVD support, and the latest programming manual with information on how to safely use the advanced features of the latest Symbios SCSI chips. Thanks a lot! Christoph Kukulies kuku@FreeBSD.org donated an FX120 12 speed Mitsumi CDROM drive for IDE CDROM driver development. Special contributors: BSDi (formerly Walnut Creek CDROM) has donated almost more than we can say (see the history document for more details). In particular, we would like to thank them for the original hardware used for freefall.FreeBSD.org, our primary development machine, and for thud.FreeBSD.org, a testing and build box. We are also indebted to them for funding various contributors over the years and providing us with unrestricted use of their T1 connection to the Internet. The interface business GmbH, Dresden has been patiently supporting &a.joerg; who has often preferred FreeBSD work over paid work, and used to fall back to their (quite expensive) EUnet Internet connection whenever his private connection became too slow or flaky to work with it... Berkeley Software Design, Inc. has contributed their DOS emulator code to the remaining BSD world, which is used in the doscmd command. Core Team Alumni The following people were members of the FreeBSD core team during the periods indicated. We thank them for their past efforts in the service of the FreeBSD project. In rough chronological order: &a.ache (1993 - 2000) &a.jmb (1993 - 2000) &a.bde (1992 - 2000) &a.gibbs (1993 - 2000) &a.rich (1994 - 2000) &a.phk (1992 - 2000) &a.gpalmer (1993 - 2000) &a.sos (1993 - 2000) &a.wollman (1993 - 2000) &a.joerg (1995 - 2000) &a.jdp (1997 - 2000) &a.guido (1995 - 1999) &a.dyson (1993 - 1998) &a.nate (1992 - 1996) &a.rgrimes (1992 - 1995) Andreas Schulz (1992 - 1995) &a.csgr (1993 - 1995) &a.paul (1992 - 1995) &a.smace (1993 - 1994) Andrew Moore (1993 - 1994) Christoph Robitschko (1993 - 1994) J. T. Conklin (1992 - 1993) Development Team Alumni The following people were members of the FreeBSD development team during the periods indicated. We thank them for their past efforts in the service of the FreeBSD project. In rough chronological order: &a.tedm (???? - 2000) &a.karl (???? - 2000) &a.gclarkii (1993 - 2000) &a.jraynard (???? - 2000) &a.jgreco (???? - 1999) &a.ats (???? - 1999) Jamil Weatherby (1997 - 1999) meganm (???? - 1998) &a.dyson (???? - 1998) Amancio Hasty (1997 - 1998) Drew Derbyshire (1997 - 1998) Derived Software Contributors This software was originally derived from William F. Jolitz's 386BSD release 0.1, though almost none of the original 386BSD specific code remains. This software has been essentially re-implemented from the 4.4BSD-Lite release provided by the Computer Science Research Group (CSRG) at the University of California, Berkeley and associated academic contributors. There are also portions of NetBSD and OpenBSD that have been integrated into FreeBSD as well, and we would therefore like to thank all the contributors to NetBSD and OpenBSD for their work. Additional FreeBSD Contributors (in alphabetical order by first name): ABURAYA Ryushirou rewsirow@ff.iij4u.or.jp AMAGAI Yoshiji amagai@nue.org Aaron Bornstein aaronb@j51.com Aaron Smith aaron@mutex.org Achim Patzner ap@noses.com Ada T Lim ada@bsd.org Adam Baran badam@mw.mil.pl Adam Glass glass@postgres.berkeley.edu Adam Herzog adam@herzogdesigns.com Adam McDougall mcdouga9@egr.msu.edu Adam Strohl troll@digitalspark.net Adoal Xu adoal@iname.com Adrian Colley aecolley@ois.ie Adrian Hall ahall@mirapoint.com Adrian Mariano adrian@cam.cornell.edu Adrian Steinmann ast@marabu.ch Adrian T. Filipi-Martin atf3r@agate.cs.virginia.edu Ajit Thyagarajan unknown Akio Morita amorita@meadow.scphys.kyoto-u.ac.jp Akira SAWADA unknown Akira Watanabe akira@myaw.ei.meisei-u.ac.jp Akito Fujita fujita@zoo.ncl.omron.co.jp Alain Kalker A.C.P.M.Kalker@student.utwente.nl Alan Bawden alan@curry.epilogue.com Alec Wolman wolman@cs.washington.edu Aled Morris aledm@routers.co.uk Aleksandr A Babaylov .@babolo.ru Alex G. Bulushev bag@demos.su Alex D. Chen dhchen@Canvas.dorm7.nccu.edu.tw Alex Le Heux alexlh@funk.org Alex Kapranoff kappa@zombie.antar.bryansk.ru Alex Perel veers@disturbed.net Alex Semenyaka alex@rinet.ru Alex Varju varju@webct.com Alex Zepeda garbanzo@hooked.net Alexander B. Povolotsky tarkhil@mgt.msk.ru Alexander Gelfenbain mail@gelf.com Alexander Leidinger netchild@wurzelausix.CS.Uni-SB.DE Alexandre Peixoto alexandref@tcoip.com.br Alexandre Snarskii snar@paranoia.ru Alistair G. Crooks agc@uts.amdahl.com Allan Bowhill bowhill@bowhill.vservers.com Allan Saddi asaddi@philosophysw.com Allen Campbell allenc@verinet.com Amakawa Shuhei amakawa@hoh.t.u-tokyo.ac.jp Amancio Hasty hasty@star-gate.com Amir Farah amir@comtrol.com Amir Shalem amir@boom.org.il Amy Baron amee@beer.org The Anarcat beaupran@iro.umontreal.ca Anatoly A. Orehovsky tolik@mpeks.tomsk.su Anatoly Vorobey mellon@pobox.com Anders Andersson anders@codefactory.se Anders Nordby anders@fix.no Anders Thulin Anders.X.Thulin@telia.se Andras Olah olah@cs.utwente.nl Andre Albsmeier Andre.Albsmeier@mchp.siemens.de Andre Goeree abgoeree@uwnet.nl Andre Oppermann andre@pipeline.ch Andreas Haakh ah@alman.robin.de Andreas Kohout shanee@rabbit.augusta.de Andreas Lohr andreas@marvin.RoBIN.de Andreas Schulz unknown Andreas Wetzel mickey@deadline.snafu.de Andreas Wrede andreas@planix.com Andres Vega Garcia unknown Andrew Atrens atreand@statcan.ca Andrew Boothman andrew@cream.org Andrew Gillham gillham@andrews.edu Andrew Gordon andrew.gordon@net-tel.co.uk Andrew Herbert andrew@werple.apana.org.au Andrew J. Korty ajk@purdue.edu Andrew L. Moore alm@mclink.com Andrew L. Neporada andrew@chg.ru Andrew McRae amcrae@cisco.com Andrew Stevenson andrew@ugh.net.au Andrew Timonin tim@pool1.convey.ru Andrew V. Stesin stesin@elvisti.kiev.ua Andrew Webster awebster@dataradio.com Andrey Novikov andrey@novikov.com Andrey Simonenko simon@comsys.ntu-kpi.kiev.ua Andrey Tchoritch andy@venus.sympad.net Andy Farkas andyf@speednet.com.au Andy Valencia ajv@csd.mot.com Andy Whitcroft andy@sarc.city.ac.uk Angelo Turetta ATuretta@stylo.it Anthony C. Chavez magus@xmission.com Anthony Yee-Hang Chan yeehang@netcom.com Anton N. Bruesov antonz@library.ntu-kpi.kiev.ua Anton Voronin anton@urc.ac.ru Antti Kaipila anttik@iki.fi arci vega@sophia.inria.fr Are Bryne are.bryne@communique.no Ari Suutari ari@suutari.iki.fi Arindum Mukerji rmukerji@execpc.com Arjan de Vet devet@IAEhv.nl Arne Henrik Juul arnej@Lise.Unit.NO Arun Sharma adsharma@sharmas.dhs.org Arnaud S. Launay asl@launay.org Ask Bjoern Hansen ask@valueclick.com Atsushi Furuta furuta@sra.co.jp Atsushi Murai amurai@spec.co.jp Atushi Sakauchi sakauchi@yamame.to Bakul Shah bvs@bitblocks.com Barry Bierbauch pivrnec@vszbr.cz Barry Lustig barry@ictv.com Ben Hutchinson benhutch@xfiles.org.uk Ben Jackson unknown Ben Walter bwalter@itachi.swcp.com Benjamin Lewis bhlewis@gte.net Berend de Boer berend@pobox.com Bernd Rosauer br@schiele-ct.de Bill Kish kish@osf.org Bill Trost trost@cloud.rain.com Blaz Zupan blaz@amis.net Bob Van Valzah Bob@whitebarn.com Bob Wilcox bob@obiwan.uucp Bob Willcox bob@luke.pmr.com Boris Staeblow balu@dva.in-berlin.de Boyd Faulkner faulkner@mpd.tandem.com Boyd R. Faulkner faulkner@asgard.bga.com Brad Chapman chapmanb@arches.uga.edu Brad Hendrickse bradh@uunet.co.za Brad Karp karp@eecs.harvard.edu Bradley Dunn bradley@dunn.org Brad Jones brad@kazrak.com Brandon Fosdick bfoz@glue.umd.edu Brandon Gillespie brandon@roguetrader.com &a.wlloyd Brent J. Nordquist bjn@visi.com Brett Lymn blymn@mulga.awadi.com.AU Brett Taylor brett@peloton.runet.edu Brian Campbell brianc@pobox.com Brian Clapper bmc@willscreek.com Brian Cully shmit@kublai.com Brian Handy handy@lambic.space.lockheed.com Brian Litzinger brian@MediaCity.com Brian McGovern bmcgover@cisco.com Brian Moore ziff@houdini.eecs.umich.edu Brian R. Haug haug@conterra.com Brian Tao taob@risc.org Brion Moss brion@queeg.com Bruce Albrecht bruce@zuhause.mn.org Bruce Gingery bgingery@gtcs.com Bruce J. Keeler loodvrij@gridpoint.com Bruce Murphy packrat@iinet.net.au Bruce Walter walter@fortean.com Carey Jones mcj@acquiesce.org Carl Fongheiser cmf@netins.net Carl Mascott cmascott@world.std.com Casper casper@acc.am Castor Fu castor@geocast.com Chain Lee chain@110.net Charles Hannum mycroft@ai.mit.edu Charles Henrich henrich@msu.edu Charles Mott cmott@scientech.com Charles Owens owensc@enc.edu &a.chern; Chet Ramey chet@odin.INS.CWRU.Edu Chia-liang Kao clkao@CirX.ORG Chiharu Shibata chi@bd.mbn.or.jp Chip Norkus unknown Chris Csanady cc@tarsier.ca.sandia.gov Chris Dabrowski chris@vader.org Chris Dillon cdillon@wolves.k12.mo.us Chris Shenton cshenton@angst.it.hq.nasa.gov Chris Stenton jacs@gnome.co.uk Chris Timmons skynyrd@opus.cts.cwu.edu Chris Torek torek@ee.lbl.gov Christian Gusenbauer cg@fimp01.fim.uni-linz.ac.at Christian Haury Christian.Haury@sagem.fr Christian Weisgerber naddy@mips.inka.de Christoph P. Kukulies kuku@FreeBSD.org Christoph Robitschko chmr@edvz.tu-graz.ac.at Christoph Weber-Fahr wefa@callcenter.systemhaus.net Christopher G. Demetriou cgd@postgres.berkeley.edu Christopher N. Harrell cnh@ivmg.net Christopher Preston rbg@gayteenresource.org Christopher T. Johnson cjohnson@neunacht.netgsi.com Chrisy Luke chrisy@flix.net Chuck Hein chein@cisco.com Cliff Rowley dozprompt@onsea.com Colman Reilly careilly@tcd.ie Conrad Sabatier conrads@home.com Coranth Gryphon gryphon@healer.com Cornelis van der Laan nils@guru.ims.uni-stuttgart.de Cove Schneider cove@brazil.nbn.com Craig Leres leres@ee.lbl.gov Craig Loomis unknown Craig Metz cmetz@inner.net Craig Spannring cts@internetcds.com Craig Struble cstruble@vt.edu Cristian Ferretti cfs@riemann.mat.puc.cl Curt Mayer curt@toad.com Cy Schubert cschuber@uumail.gov.bc.ca Cyrille Lefevre clefevre@citeweb.net Cyrus Rahman cr@jcmax.com Dai Ishijima ishijima@tri.pref.osaka.jp Daisuke Watanabe NU7D-WTNB@asahi-net.or.jp Damian Hamill damian@cablenet.net Dan Cross tenser@spitfire.ecsel.psu.edu Dan Langille dan@freebsddiary.org Dan Lukes dan@obluda.cz Dan Nelson dnelson@emsphone.com Dan Papasian bugg@bugg.strangled.net Dan Piponi wmtop@tanelorn.demon.co.uk Dan Walters hannibal@cyberstation.net Daniel Hagan dhagan@cs.vt.edu Daniel O'Connor doconnor@gsoft.com.au Daniel Poirot poirot@aio.jsc.nasa.gov Daniel Rock rock@cs.uni-sb.de Daniel W. McRobb dwm@caimis.com Danny Egen unknown Danny J. Zerkel dzerkel@phofarm.com Dave Adkins adkin003@tc.umn.edu Dave Andersen angio@aros.net Dave Blizzard dblizzar@sprynet.com Dave Bodenstab imdave@synet.net Dave Burgess burgess@hrd769.brooks.af.mil Dave Chapeskie dchapes@ddm.on.ca Dave Cornejo dave@dogwood.com Dave Edmondson davided@sco.com Dave Glowacki dglo@ssec.wisc.edu Dave Marquardt marquard@austin.ibm.com Dave Tweten tweten@FreeBSD.org David A. Adkins adkin003@tc.umn.edu David A. Bader dbader@eece.unm.edu David Borman dab@bsdi.com David Dawes dawes@XFree86.org David Filo unknown David Holland dholland@eecs.harvard.edu David Holloway daveh@gwythaint.tamis.com David Horwitt dhorwitt@ucsd.edu David Hovemeyer daveho@infocom.com David Jones dej@qpoint.torfree.net David Kelly dkelly@tomcat1.tbe.com David Kulp dkulp@neomorphic.com David L. Nugent davidn@blaze.net.au David Leonard d@scry.dstc.edu.au David Muir Sharnoff muir@idiom.com David S. Miller davem@jenolan.rutgers.edu David Sugar dyfet@gnu.org David Wolfskill dhw@whistle.com Dean Gaudet dgaudet@arctic.org Dean Huxley dean@fsa.ca Denis Fortin unknown Denis Shaposhnikov dsh@vlink.ru Dennis Glatting dennis.glatting@software-munitions.com Denton Gentry denny1@home.com der Mouse mouse@Collatz.McRCIM.McGill.EDU Derek Inksetter derek@saidev.com DI. Christian Gusenbauer cg@scotty.edvz.uni-linz.ac.at Dirk Keunecke dk@panda.rhein-main.de Dirk Nehrling nerle@pdv.de Dishanker Rajakulendren draj@oceanfree.net Dmitry Khrustalev dima@xyzzy.machaon.ru Dmitry Kohmanyuk dk@farm.org Dom Mitchell dom@myrddin.demon.co.uk Domas Mituzas midom@dammit.lt Dominik Brettnacher domi@saargate.de Dominik Rothert dr@domix.de Don Croyle croyle@gelemna.ft-wayne.in.us Donn Miller dmmiller@cvzoom.net Dan Pelleg dpelleg+unison@cs.cmu.edu &a.whiteside; Don Morrison dmorrisn@u.washington.edu Don Yuniskis dgy@rtd.com Donald Maddox dmaddox@conterra.com Douglas Ambrisko ambrisko@whistle.com Douglas Carmichael dcarmich@mcs.com Douglas Crosher dtc@scrooge.ee.swin.oz.au Drew Derbyshire ahd@kew.com Dustin Sallings dustin@spy.net Eckart "Isegrim" Hofmann Isegrim@Wunder-Nett.org Ed Gold vegold01@starbase.spd.louisville.edu Ed Hudson elh@p5.spnet.com Edward Chuang edwardc@firebird.org.tw Edward Wang edward@edcom.com Edwin Groothus edwin@nwm.wan.philips.com Edwin Mons e@ik.nu Ege Rekk aagero@aage.priv.no Eiji-usagi-MATSUmoto usagi@clave.gr.jp Eike Bernhardt eike.bernhardt@gmx.de ELISA Font Project Elmar Bartel bartel@informatik.tu-muenchen.de Eoin Lawless eoin@maths.tcd.ie Eric A. Griff eagriff@global2000.net Eric Blood eblood@cs.unr.edu Eric D. Futch efutch@nyct.net Eric J. Haug ejh@slustl.slu.edu Eric J. Schwertfeger eric@cybernut.com Eric L. Hernes erich@lodgenet.com Eric P. Scott eps@sirius.com Eric Sprinkle eric@ennovatenetworks.com Erich Stefan Boleyn erich@uruk.org Erich Zigler erich@tacni.net Erik H. Bakke erikhb@bgnett.no Erik E. Rantapaa rantapaa@math.umn.edu Erik H. Moe ehm@cris.com Ernst de Haan ernst@heinz.jollem.com Ernst Winter ewinter@lobo.muc.de Espen Skoglund esk@ira.uka.de Eugene M. Kim astralblue@usa.net Eugene Radchenko genie@qsar.chem.msu.su Eugeny Kuzakov CoreDumped@coredumped.null.ru Evan Champion evanc@synapse.net Faried Nawaz fn@Hungry.COM Flemming Jacobsen fj@tfs.com Fong-Ching Liaw fong@juniper.net Francis M J Hsieh mjshieh@life.nthu.edu.tw Francisco Reyes fjrm@yahoo.com Frank Bartels knarf@camelot.de Frank Chen Hsiung Chan frankch@waru.life.nthu.edu.tw Frank Durda IV uhclem@nemesis.lonestar.org Frank MacLachlan fpm@n2.net Frank Nobis fn@Radio-do.de Frank ten Wolde franky@pinewood.nl Frank van der Linden frank@fwi.uva.nl Frank Volf volf@oasis.IAEhv.nl Fred Cawthorne fcawth@jjarray.umn.edu Fred Gilham gilham@csl.sri.com Fred Templin templin@erg.sri.com Frederick Earl Gray fgray@rice.edu FUJIMOTO Kensaku fujimoto@oscar.elec.waseda.ac.jp FURUSAWA Kazuhisa furusawa@com.cs.osakafu-u.ac.jp &a.stanislav; Gabor Kincses gabor@acm.org Gabor Zahemszky zgabor@CoDe.hu Gareth McCaughan gjm11@dpmms.cam.ac.uk Gary A. Browning gab10@griffcd.amdahl.com Gary Howland gary@hotlava.com Gary J. garyj@rks32.pcs.dec.com Gary Kline kline@thought.org Gaspar Chilingarov nightmar@lemming.acc.am Gea-Suan Lin gsl@tpts4.seed.net.tw Gene Raytsin pal@paladin7.net Geoff Rehmet csgr@alpha.ru.ac.za Georg Wagner georg.wagner@ubs.com Gianlorenzo Masini masini@uniroma3.it Gianmarco Giovannelli gmarco@giovannelli.it Gil Kloepfer Jr. gil@limbic.ssdl.com Gilad Rom rom_glsa@ein-hashofet.co.il Giles Lean giles@nemeton.com.au Ginga Kawaguti ginga@amalthea.phys.s.u-tokyo.ac.jp Giorgos Keramidas keramida@ceid.upatras.gr Glen Foster gfoster@gfoster.com Glenn Johnson gljohns@bellsouth.net Godmar Back gback@facility.cs.utah.edu Goran Hammarback goran@astro.uu.se Gord Matzigkeit gord@enci.ucalgary.ca Gordon Greeff gvg@uunet.co.za Graham Wheeler gram@cdsec.com Greg A. Woods woods@zeus.leitch.com Greg Ansley gja@ansley.com Greg Robinson greg@rosevale.com.au Greg Troxel gdt@ir.bbn.com Greg Ungerer gerg@stallion.oz.au Gregory Bond gnb@itga.com.au Gregory D. Moncreaff moncrg@bt340707.res.ray.com Guy Harris guy@netapp.com Guy Helmer ghelmer@cs.iastate.edu HAMADA Naoki hamada@astec.co.jp Hannu Savolainen hannu@voxware.pp.fi Hans Huebner hans@artcom.de Hans Petter Bieker zerium@webindex.no Hans Zuidam hans@brandinnovators.com Harlan Stenn Harlan.Stenn@pfcs.com Harold Barker hbarker@dsms.com Harry Newton harry_newton@telinco.co.uk Havard Eidnes Havard.Eidnes@runit.sintef.no Heikki Suonsivu hsu@cs.hut.fi Heiko W. Rupp unknown Helmut F. Wirth hfwirth@ping.at Henrik Vestergaard Draboel hvd@terry.ping.dk Herb Peyerl hpeyerl@NetBSD.org Hideaki Ohmon ohmon@tom.sfc.keio.ac.jp Hidekazu Kuroki hidekazu@cs.titech.ac.jp Hideki Yamamoto hyama@acm.org Hideyuki Suzuki hideyuki@sat.t.u-tokyo.ac.jp Hirayama Issei iss@mail.wbs.ne.jp Hiroaki Sakai sakai@miya.ee.kagu.sut.ac.jp Hiroharu Tamaru tamaru@ap.t.u-tokyo.ac.jp Hironori Ikura hikura@kaisei.org Hiroshi Nishikawa nis@pluto.dti.ne.jp Hiroya Tsubakimoto unknown Holger Lamm holger@eit.uni-kl.de Holger Veit Holger.Veit@gmd.de Holm Tiffe holm@geophysik.tu-freiberg.de HONDA Yasuhiro honda@kashio.info.mie-u.ac.jp Horance Chou horance@freedom.ie.cycu.edu.tw Horihiro Kumagai kuma@jp.FreeBSD.org HOSOBUCHI Noriyuki hoso@buchi.tama.or.jp HOTARU-YA hotaru@tail.net Hr.Ladavac lada@ws2301.gud.siemens.co.at Hubert Feyrer hubertf@NetBSD.ORG Hugh F. Mahon hugh@nsmdserv.cnd.hp.com Hugh Mahon h_mahon@fc.hp.com Hung-Chi Chu hcchu@r350.ee.ntu.edu.tw Ian Holland ianh@tortuga.com.au Ian Struble ian@broken.net Ian Vaudrey i.vaudrey@bigfoot.com Igor Khasilev igor@jabber.paco.odessa.ua Igor Roshchin str@giganda.komkon.org Igor Serikov bt@turtle.pangeatech.com Igor Sviridov siac@ua.net Igor Vinokurov igor@zynaps.ru Ikuo Nakagawa ikuo@isl.intec.co.jp Ilia Chipitsine ilia@jane.cgu.chel.su Ilya V. Komarov mur@lynx.ru IMAI Takeshi take-i@ceres.dti.ne.jp IMAMURA Tomoaki tomoak-i@is.aist-nara.ac.jp Itsuro Saito saito@miv.t.u-tokyo.ac.jp IWASHITA Yoji shuna@pop16.odn.ne.jp J. Bryant jbryant@argus.flash.net J. David Lowe lowe@saturn5.com J. Han hjh@photino.com J. Hawk jhawk@MIT.EDU J.T. Conklin jtc@cygnus.com Jack jack@zeus.xtalwind.net Jacob Bohn Lorensen jacob@jblhome.ping.mk Jagane D Sundar jagane@netcom.com Jake Hamby jehamby@anobject.com James Clark jjc@jclark.com James D. Stewart jds@c4systm.com James da Silva jds@cs.umd.edu James Jegers jimj@miller.cs.uwm.edu James Raynard fhackers@jraynard.demon.co.uk James T. Liu jtliu@phlebas.rockefeller.edu Jamie Heckford jamie@jamiesdomain.co.uk Jan Conard charly@fachschaften.tu-muenchen.de Jan Jungnickel Jan@Jungnickel.com Jan Koum jkb@FreeBSD.org Janick Taillandier Janick.Taillandier@ratp.fr Janusz Kokot janek@gaja.ipan.lublin.pl Jarle Greipsland jarle@idt.unit.no Jason Garman init@risen.org Jason R. Mastaler jason-freebsd@mastaler.com Jason Thorpe thorpej@NetBSD.org Jason Wright jason@OpenBSD.org Jason Young doogie@forbidden-donut.anet-stl.com Javier Martin Rueda jmrueda@diatel.upm.es Jay Fenlason hack@datacube.com Jay Krell jay.krell@cornell.edu Jaye Mathisen mrcpu@cdsnet.net Jeff Bartig jeffb@doit.wisc.edu Jeff Brown jabrown@caida.org Jeff Forys jeff@forys.cranbury.nj.us Jeff Kletsky Jeff@Wagsky.com Jeff Palmer scorpio@drkshdw.org Jeffrey Evans evans@scnc.k12.mi.us Jeffrey Wheat jeff@cetlink.net Jeremy Allison jallison@whistle.com Jeremy Chadwick yoshi@parodius.com Jeremy Chatfield jdc@xinside.com Jeremy Karlson karlj000@unbc.ca Jeremy Prior unknown Jeremy Shaffner jeremy@external.org Jesse McConnell jesse@cylant.com Jesse Rosenstock jmr@ugcs.caltech.edu Jian-Da Li jdli@csie.nctu.edu.tw Jim Babb babb@FreeBSD.org Jim Binkley jrb@cs.pdx.edu Jim Bloom bloom@acm.org Jim Carroll jim@carroll.com Jim Flowers jflowers@ezo.net Jim Leppek jleppek@harris.com Jim Lowe james@cs.uwm.edu Jim Mattson jmattson@sonic.net Jim Mercer jim@komodo.reptiles.org Jim Sloan odinn@atlantabiker.net Jim Wilson wilson@moria.cygnus.com Jimbo Bahooli griffin@blackhole.iceworld.org Jin Guojun jin@george.lbl.gov Joachim Kuebart kuebart@mathematik.uni-ulm.de Joao Carlos Mendes Luis jonny@jonny.eng.br Jochen Pohl jpo.drs@sni.de Joe "Marcus" Clarke marcus@marcuscom.com Joe Abley jabley@automagic.org Joe Jih-Shian Lu jslu@dns.ntu.edu.tw Joe Orthoefer j_orthoefer@tia.net Joe Traister traister@mojozone.org Joel Faedi Joel.Faedi@esial.u-nancy.fr Joel Ray Holveck joelh@gnu.org Joel Sutton jsutton@bbcon.com.au Jordan DeLong fracture@allusion.net Joseph Scott joseph@randomnetworks.com Johan Granlund johan@granlund.nu Johan Karlsson k@numeri.campus.luth.se Johan Larsson johan@moon.campus.luth.se Johann Tonsing jtonsing@mikom.csir.co.za Johannes Helander unknown Johannes Stille unknown John Beckett jbeckett@southern.edu John Beukema jbeukema@hk.super.net John Brezak unknown John Capo jc@irbs.com John F. Woods jfw@jfwhome.funhouse.com John Goerzen jgoerzen@alexanderwohl.complete.org John Heidemann johnh@isi.edu John Hood cgull@owl.org John Kohl unknown John Lind john@starfire.mn.org John Mackin john@physiol.su.oz.au John P johnp@lodgenet.com John Perry perry@vishnu.alias.net John Preisler john@vapornet.com John Reynolds jjreynold@home.com John Rochester jr@cs.mun.ca John Sadler john_sadler@alum.mit.edu John Saunders john@pacer.nlc.net.au John Wehle john@feith.com John Woods jfw@eddie.mit.edu Johny Mattsson lonewolf@flame.org Jon Morgan morgan@terminus.trailblazer.com Jonathan Belson jon@witchspace.com Jonathan H N Chin jc254@newton.cam.ac.uk Jonathan Hanna jh@pc-21490.bc.rogers.wave.ca Jonathan Pennington john@coastalgeology.org Jorge Goncalves j@bug.fe.up.pt Jorge M. Goncalves ee96199@tom.fe.up.pt Jos Backus jbackus@plex.nl Jose Marques jose@nobody.org Josef Grosch jgrosch@superior.mooseriver.com Joseph Stein joes@wstein.com Josh Gilliam josh@quick.net Josh Tiefenbach josh@ican.net Juergen Lock nox@jelal.hb.north.de Juha Inkari inkari@cc.hut.fi Jukka A. Ukkonen jau@iki.fi Julian Assange proff@suburbia.net Julian Coleman j.d.coleman@ncl.ac.uk &a.jhs Julian Jenkins kaveman@magna.com.au Junichi Satoh junichi@jp.FreeBSD.org Junji SAKAI sakai@jp.FreeBSD.org Junya WATANABE junya-w@remus.dti.ne.jp Justas justas@mbank.lv Justin Stanford jus@security.za.net K.Higashino a00303@cc.hc.keio.ac.jp Kai Vorma vode@snakemail.hut.fi Kaleb S. Keithley kaleb@ics.com Kaneda Hiloshi vanitas@ma3.seikyou.ne.jp Kang-ming Liu gugod@gugod.org Kapil Chowksey kchowksey@hss.hns.com Karl Denninger karl@mcs.com Karl Dietz Karl.Dietz@triplan.com Karl Lehenbauer karl@NeoSoft.com KATO Tsuguru tkato@prontomail.ne.jp Kawanobe Koh kawanobe@st.rim.or.jp Kees Jan Koster kjk1@ukc.ac.uk Keith Bostic bostic@bostic.com Keith E. Walker kew@icehouse.net Keith Moore unknown Keith Sklower unknown Ken Hornstein unknown Ken Key key@cs.utk.edu Ken Mayer kmayer@freegate.com Kenji Saito marukun@mx2.nisiq.net Kenji Tomita tommyk@da2.so-net.or.jp Kenneth Furge kenneth.furge@us.endress.com Kenneth Monville desmo@bandwidth.org Kenneth R. Westerback krw@tcn.net Kenneth Stailey kstailey@gnu.ai.mit.edu Kent Talarico kent@shipwreck.tsoft.net Kent Vander Velden graphix@iastate.edu Kentaro Inagaki JBD01226@niftyserve.ne.jp Kevin Bracey kbracey@art.acorn.co.uk Kevin Day toasty@dragondata.com Kevin Lahey kml@nas.nasa.gov Kevin Meltzer perlguy@perlguy.com Kevin Street street@iname.com Kevin Van Maren vanmaren@fast.cs.utah.edu Killer killer@prosalg.no Kim Scarborough sluggo@unknown.nu Kiril Mitev kiril@ideaglobal.com Kiroh HARADA kiroh@kh.rim.or.jp Klaus Herrmann klaus.herrmann@gmx.net Klaus Klein kleink@layla.inka.de Klaus-J. Wolf Yanestra@t-online.de Koichi Sato copan@ppp.fastnet.or.jp Konrad Heuer kheuer@gwdu60.gwdg.de Konstantin Chuguev Konstantin.Chuguev@dante.org.uk Kostya Lukin lukin@okbmei.msk.su Kouichi Hirabayashi kh@mogami-wire.co.jp Kris Dow kris@vilnya.demon.co.uk KUNISHIMA Takeo kunishi@c.oka-pu.ac.jp Kurt D. Zeilenga Kurt@Boolean.NET Kurt Olsen kurto@tiny.mcs.usu.edu L. Jonas Olsson ljo@ljo-slip.DIALIN.CWRU.Edu Larry Altneu larry@ALR.COM Lars Bernhardsson lab@fnurt.net Lars Köller Lars.Koeller@Uni-Bielefeld.DE Laurence Lopez lopez@mv.mv.com Lee Cremeans lcremean@tidalwave.net Leo Kim leo@florida.sarang.net Liang Tai-hwa avatar@www.mmlab.cse.yzu.edu.tw Lon Willett lon%softt.uucp@math.utah.edu Louis A. Mamakos louie@TransSys.COM Louis Mamakos loiue@TransSys.com Lowell Gilbert lowell@world.std.com Lucas James Lucas.James@ldjpc.apana.org.au Lyndon Nerenberg lyndon@orthanc.ab.ca M. L. Dodson bdodson@scms.utmb.EDU M.C. Wong unknown Magnus Enbom dot@tinto.campus.luth.se Mahesh Neelakanta mahesh@gcomm.com Makoto MATSUSHITA matusita@jp.FreeBSD.org Makoto WATANABE watanabe@zlab.phys.nagoya-u.ac.jp Makoto YAMAKURA makoto@pinpott.spnet.ne.jp Malte Lance malte.lance@gmx.net MANTANI Nobutaka nobutaka@nobutaka.com Manu Iyengar iyengar@grunthos.pscwa.psca.com Marc Frajola marc@dev.com Marc Ramirez mrami@mramirez.sy.yale.edu Marc Slemko marcs@znep.com Marc van Kempen wmbfmk@urc.tue.nl Marc van Woerkom van.woerkom@netcologne.de Marcin Cieslak saper@system.pl Mark Andrews unknown Mark Cammidge mark@gmtunx.ee.uct.ac.za Mark Diekhans markd@grizzly.com Mark Huizer xaa@stack.nl Mark J. Taylor mtaylor@cybernet.com Mark Knight markk@knigma.org Mark Krentel krentel@rice.edu Mark Mayo markm@vmunix.com Mark Thompson thompson@tgsoft.com Mark Tinguely tinguely@plains.nodak.edu Mark Treacy unknown Mark Valentine mark@thuvia.org Markus Holmberg saska@acc.umu.se Martin Birgmeier unknown Martin Blapp blapp@attic.ch Martin Hinner mhi@linux.gyarab.cz Martin Ibert mib@ppe.bb-data.de Martin Kammerhofer dada@sbox.tu-graz.ac.at Martin Minkus diskiller@cnbinc.com Martin Renters martin@tdc.on.ca Martti Kuparinen martti.kuparinen@ericsson.com Masachika ISHIZUKA ishizuka@isis.min.ntt.jp Masahiro Sekiguchi seki@sysrap.cs.fujitsu.co.jp Masahiro TAKEMURA mastake@msel.t.u-tokyo.ac.jp Masanobu Saitoh msaitoh@spa.is.uec.ac.jp Masanori Kanaoka kana@saijo.mke.mei.co.jp Masanori Kiriake seiken@ARGV.AC Masatoshi TAMURA tamrin@shinzan.kuee.kyoto-u.ac.jp Mats Lofkvist mal@algonet.se Matt Bartley mbartley@lear35.cytex.com Matt Heckaman matt@LUCIDA.QC.CA Matt Thomas matt@3am-software.com Matt White mwhite+@CMU.EDU Matthew C. Mead mmead@Glock.COM Matthew Cashdollar mattc@rfcnet.com Matthew Emmerton root@gabby.gsicomp.on.ca Matthew Flatt mflatt@cs.rice.edu Matthew Fuller fullermd@futuresouth.com Matthew Stein matt@bdd.net Matthew West mwest@uct.ac.za Matthias Pfaller leo@dachau.marco.de Matthias Scheler tron@netbsd.org Mattias Gronlund Mattias.Gronlund@sa.erisoft.se Mattias Pantzare pantzer@ludd.luth.se Maurice Castro maurice@planet.serc.rmit.edu.au Max Euston meuston@jmrodgers.com Max Khon fjoe@husky.iclub.nsu.ru Maxim Bolotin max@rsu.ru Maxim Konovalov maxim@macomnet.ru Maxime Henrion mhenrion@cybercable.fr Micha Class michael_class@hpbbse.bbn.hp.com Michael Alyn Miller malyn@strangeGizmo.com Michael Lucas mwlucas@blackhelicopters.org Michael Lyngbøl michael@lyngbol.dk Michael Butler imb@scgt.oz.au Michael Butschky butsch@computi.erols.com Michael Clay mclay@weareb.org Michael Galassi nerd@percival.rain.com Michael Hancock michaelh@cet.co.jp Michael Hohmuth hohmuth@inf.tu-dresden.de Michael Perlman canuck@caam.rice.edu Michael Petry petry@netwolf.NetMasters.com Michael Reifenberger root@totum.plaut.de Michael Sardo jaeger16@yahoo.com Michael Searle searle@longacre.demon.co.uk Michael Urban murban@tznet.com Michael Vasilenko acid@stu.cn.ua Michal Listos mcl@Amnesiac.123.org Michio Karl Jinbo karl@marcer.nagaokaut.ac.jp Miguel Angel Sagreras msagre@cactus.fi.uba.ar Mihoko Tanaka m_tonaka@pa.yokogawa.co.jp Mika Nystrom mika@cs.caltech.edu Mikael Hybsch micke@dynas.se Mikael Karpberg karpen@ocean.campus.luth.se Mike Barcroft mike@q9media.com Mike Bristow mike@urgle.com Mike Del repenting@hotmail.com Mike Durian durian@plutotech.com Mike Durkin mdurkin@tsoft.sf-bay.org Mike E. Matsnev mike@azog.cs.msu.su Mike Evans mevans@candle.com Mike Futerko mike@LITech.lviv.ua Mike Grupenhoff kashmir@umiacs.umd.edu Mike Harding mvh@ix.netcom.com Mike Hibler mike@marker.cs.utah.edu Mike Karels unknown Mike McGaughey mmcg@cs.monash.edu.au Mike Meyer mwm@mired.org Mike Mitchell mitchell@ref.tfs.com Mike Murphy mrm@alpharel.com Mike Peck mike@binghamton.edu Mike Sherwood mike@fate.com Mike Spengler mks@msc.edu Mikhail A. Sokolov mishania@demos.su Ming-I Hseh PA@FreeBSD.ee.Ntu.edu.TW Mitsuru Yoshida mitsuru@riken.go.jp Monte Mitzelfelt monte@gonefishing.org Morgan Davis root@io.cts.com MOROHOSHI Akihiko moro@race.u-tokyo.ac.jp Mostyn Lewis mostyn@mrl.com Motomichi Matsuzaki mzaki@e-mail.ne.jp Motoyuki Kasahara m-kasahr@sra.co.jp N.G.Smith ngs@sesame.hensa.ac.uk Nadav Eiron nadav@barcode.co.il NAGAO Tadaaki nagao@cs.titech.ac.jp NAKAJI Hiroyuki nakaji@tutrp.tut.ac.jp NAKAMURA Kazushi nkazushi@highway.or.jp NAKAMURA Motonori motonori@econ.kyoto-u.ac.jp NAKATA, Maho chat95@mbox.kyoto-inet.or.jp Nanbor Wang nw1@cs.wustl.edu Naofumi Honda honda@Kururu.math.sci.hokudai.ac.jp Naoki Hamada nao@tom-yam.or.jp Narvi narvi@haldjas.folklore.ee Nathan Dorfman nathan@rtfm.net Neal Fachan kneel@ishiboo.com Niall Smart rotel@indigo.ie Nicholas Esborn nick@netdot.net Nick Barnes Nick.Barnes@pobox.com Nick Handel nhandel@NeoSoft.com Nick Hilliard nick@foobar.org Nick Johnson freebsd@spatula.net Nick Williams njw@cs.city.ac.uk Nickolay N. Dudorov nnd@itfs.nsk.su NIIMI Satoshi sa2c@and.or.jp Niklas Hallqvist niklas@filippa.appli.se Nils M. Holm nmh@t3x.org Nisha Talagala nisha@cs.berkeley.edu No Name adrian@virginia.edu No Name alex@elvisti.kiev.ua No Name anto@netscape.net No Name bobson@egg.ics.nitch.ac.jp No Name bovynf@awe.be No Name burg@is.ge.com No Name chris@gnome.co.uk No Name colsen@usa.net No Name coredump@nervosa.com No Name dannyman@arh0300.urh.uiuc.edu No Name davids@SECNET.COM No Name derek@free.org No Name devet@adv.IAEhv.nl No Name djv@bedford.net No Name dvv@sprint.net No Name enami@ba2.so-net.or.jp No Name flash@eru.tubank.msk.su No Name flash@hway.ru No Name fn@pain.csrv.uidaho.edu No Name frf@xocolatl.com No Name gclarkii@netport.neosoft.com No Name gordon@sheaky.lonestar.org No Name graaf@iae.nl No Name greg@greg.rim.or.jp No Name grossman@cygnus.com No Name gusw@fub46.zedat.fu-berlin.de No Name hfir@math.rochester.edu No Name hnokubi@yyy.or.jp No Name iaint@css.tuu.utas.edu.au No Name invis@visi.com No Name ishisone@sra.co.jp No Name iverson@lionheart.com No Name jpt@magic.net No Name junker@jazz.snu.ac.kr No Name k-sugyou@ccs.mt.nec.co.jp No Name kenji@reseau.toyonaka.osaka.jp No Name kfurge@worldnet.att.net No Name lh@aus.org No Name lhecking@nmrc.ucc.ie No Name mrgreen@mame.mu.oz.au No Name nakagawa@jp.FreeBSD.org No Name ohki@gssm.otsuka.tsukuba.ac.jp No Name owaki@st.rim.or.jp No Name pechter@shell.monmouth.com No Name pete@pelican.pelican.com No Name pritc003@maroon.tc.umn.edu No Name risner@stdio.com No Name roman@rpd.univ.kiev.ua No Name root@ns2.redline.ru No Name root@uglabgw.ug.cs.sunysb.edu No Name stephen.ma@jtec.com.au No Name sumii@is.s.u-tokyo.ac.jp No Name takas-su@is.aist-nara.ac.jp No Name tamone@eig.unige.ch No Name tjevans@raleigh.ibm.com No Name tony-o@iij.ad.jp amurai@spec.co.jp No Name torii@tcd.hitachi.co.jp No Name uenami@imasy.or.jp No Name uhlar@netlab.sk No Name vode@hut.fi No Name wlloyd@mpd.ca No Name wlr@furball.wellsfargo.com No Name wmbfmk@urc.tue.nl No Name yamagata@nwgpc.kek.jp No Name ziggy@ryan.org No Name ZW6T-KND@j.asahi-net.or.jp Nobuhiro Yasutomi nobu@psrc.isac.co.jp Nobuyuki Koganemaru kogane@koganemaru.co.jp NOKUBI Hirotaka h-nokubi@yyy.or.jp Norio Suzuki nosuzuki@e-mail.ne.jp Noritaka Ishizumi graphite@jp.FreeBSD.org Noriyuki Soda soda@sra.co.jp Oddbjorn Steffenson oddbjorn@tricknology.org Oh Junseon hollywar@mail.holywar.net Olaf Wagner wagner@luthien.in-berlin.de Oleg Semyonov os@altavista.net Oleg Sharoiko os@rsu.ru Oleg V. Volkov rover@lglobus.ru Olexander Kunytsa kunia@wolf.istc.kiev.ua Oliver Breuninger ob@seicom.NET Oliver Friedrichs oliver@secnet.com Oliver Fromme oliver.fromme@heim3.tu-clausthal.de Oliver Helmling oliver.helmling@stud.uni-bayreuth.de Oliver Laumann net@informatik.uni-bremen.de Oliver Lehmann Kai_Allard_Liao@gmx.de Oliver Oberdorf oly@world.std.com Olof Johansson offe@ludd.luth.se Osokin Sergey aka oZZ ozz@FreeBSD.org.ru Pace Willisson pace@blitz.com Paco Rosich rosich@modico.eleinf.uv.es Palle Girgensohn girgen@partitur.se Parag Patel parag@cgt.com Pascal Pederiva pascal@zuo.dec.com Pasvorn Boonmark boonmark@juniper.net Patrick Alken cosine@ellipse.mcs.drexel.edu Patrick Bihan-Faou patrick@mindstep.com Patrick Hausen unknown Patrick Li pat@databits.net Patrick Seal patseal@hyperhost.net Paul Antonov apg@demos.su Paul F. Werkowski unknown Paul Fox pgf@foxharp.boston.ma.us Paul Koch koch@thehub.com.au Paul Kranenburg pk@NetBSD.org Paul M. Lambert plambert@plambert.net Paul Mackerras paulus@cs.anu.edu.au Paul Popelka paulp@uts.amdahl.com Paul S. LaFollette, Jr. unknown Paul Sandys myj@nyct.net Paul T. Root proot@horton.iaces.com Paul Vixie paul@vix.com Paulo Menezes paulo@isr.uc.pt Paulo Menezes pm@dee.uc.pt Pedro A M Vazquez vazquez@IQM.Unicamp.BR Pedro Giffuni giffunip@asme.org Per Wigren wigren@home.se Pete Bentley pete@demon.net Pete Fritchman petef@databits.net Peter Childs pjchilds@imforei.apana.org.au Peter Cornelius pc@inr.fzk.de Peter Haight peterh@prognet.com Peter Jeremy peter.jeremy@alcatel.com.au Peter M. Chen pmchen@eecs.umich.edu Peter Much peter@citylink.dinoex.sub.org Peter Olsson unknown Peter Philipp pjp@bsd-daemon.net Peter Stubbs PETERS@staidan.qld.edu.au Peter van Heusden pvh@egenetics.com Phil Maker pjm@cs.ntu.edu.au Phil Sutherland philsuth@mycroft.dialix.oz.au Phil Taylor phil@zipmail.co.uk Philip Musumeci philip@rmit.edu.au Philippe Lefebvre nemesis@balistik.net Pierre Y. Dampure pierre.dampure@k2c.co.uk Pius Fischer pius@ienet.com Pomegranate daver@flag.blackened.net Powerdog Industries kevin.ruddy@powerdog.com Priit Järv priit@cc.ttu.ee R Joseph Wright rjoseph@mammalia.org R. Kym Horsell Ralf Friedl friedl@informatik.uni-kl.de Randal S. Masutani randal@comtest.com Randall Hopper rhh@ct.picker.com Randall W. Dean rwd@osf.org Randy Bush rbush@bainbridge.verio.net Rasmus Kaj kaj@Raditex.se Reinier Bezuidenhout rbezuide@mikom.csir.co.za Remy Card Remy.Card@masi.ibp.fr Ricardas Cepas rch@richard.eu.org Riccardo Veraldi veraldi@cs.unibo.it Rich Wood rich@FreeBSD.org.uk Richard Henderson richard@atheist.tamu.edu Richard Hwang rhwang@bigpanda.com Richard Kiss richard@homemail.com Richard J Kuhns rjk@watson.grauel.com Richard M. Neswold rneswold@enteract.com Richard Seaman, Jr. dick@tar.com Richard Stallman rms@gnu.ai.mit.edu Richard Straka straka@user1.inficad.com Richard Tobin richard@cogsci.ed.ac.uk Richard Wackerbarth rkw@Dataplex.NET Richard Winkel rich@math.missouri.edu Richard Wiwatowski rjwiwat@adelaide.on.net Rick Macklem rick@snowhite.cis.uoguelph.ca Rick Macklin unknown Rob Austein sra@epilogue.com Rob Mallory rmallory@qualcomm.com Rob Snow rsnow@txdirect.net Robert Crowe bob@speakez.com Robert D. Thrush rd@phoenix.aii.com Robert Eckardt roberte@MEP.Ruhr-Uni-Bochum.de Robert P Ricci ricci@cs.utah.edu Robert Sanders rsanders@mindspring.com Robert Sexton robert@kudra.com Robert Shady rls@id.net Robert Swindells swindellsr@genrad.co.uk Robert Withrow witr@rwwa.com Robert Yoder unknown Robin Carey robin@mailgate.dtc.rankxerox.co.uk Rod Taylor rod@idiotswitch.org Roger Hardiman roger@cs.strath.ac.uk Roland Jesse jesse@cs.uni-magdeburg.de Roman Shterenzon roman@xpert.com Ron Bickers rbickers@intercenter.net Ron Lenk rlenk@widget.xmission.com Ronald Kuehn kuehn@rz.tu-clausthal.de Rudolf Cejka cejkar@dcse.fee.vutbr.cz Ruslan Belkin rus@home2.UA.net Ruslan Shevchenko rssh@cam.grad.kiev.ua Russell L. Carter rcarter@pinyon.org Russell Vincent rv@groa.uct.ac.za Ryan Younce ryany@pobox.com Ryuichiro IMURA imura@af.airnet.ne.jp Sakai Hiroaki sakai@miya.ee.kagu.sut.ac.jp Sakari Jalovaara sja@tekla.fi Sam Hartman hartmans@mit.edu Samuel Lam skl@ScalableNetwork.com Samuel Tardieu sam@inf.enst.fr Samuele Zannoli zannoli@cs.unibo.it Sander Janssen janssen@rendo.dekooi.nl Sander Vesik sander@haldjas.folklore.ee Sandro Sigala ssigala@globalnet.it SANETO Takanori sanewo@strg.sony.co.jp SASAKI Shunsuke ele@pop17.odn.ne.jp Sascha Blank blank@fox.uni-trier.de Sascha Wildner swildner@channelz.GUN.de Satoh Junichi junichi@astec.co.jp SAWADA Mizuki miz@qb3.so-net.ne.jp Scot Elliott scot@poptart.org Scot W. Hetzel hetzels@westbend.net Scott A. Kenney saken@rmta.ml.org Scott A. Moberly smoberly@xavier.dyndns.org Scott Blachowicz scott.blachowicz@seaslug.org Scott Burris scott@pita.cns.ucla.edu Scott Hazen Mueller scott@zorch.sf-bay.org Scott Michel scottm@cs.ucla.edu Scott Mitchel scott@uk.FreeBSD.org Scott Reynolds scott@clmqt.marquette.mi.us Sebastian Strollo seb@erix.ericsson.se Serge V. Vakulenko vak@zebub.msk.su Sergei Chechetkin csl@whale.sunbay.crimea.ua Sergei S. Laskavy laskavy@pc759.cs.msu.su Sergey Gershtein sg@mplik.ru Sergey Kosyakov ks@itp.ac.ru Sergey N. Vorokov serg@tmn.ru Sergey Potapov sp@alkor.ru Sergey Samoyloff gonza@techline.ru Sergey Shkonda serg@bcs.zp.ua Sergey Skvortsov skv@protey.ru Sergey V.Dorokhov svd@kbtelecom.nalnet.ru Sergio Lenzi lenzi@bsi.com.br Shaun Courtney shaun@emma.eng.uct.ac.za Shawn M. Carey smcarey@mailbox.syr.edu Shigio Yamaguchi shigio@tamacom.com Shinya Esu esu@yk.rim.or.jp Shinya FUJIE fujie@tk.elec.waseda.ac.jp Shuichi Tanaka stanaka@bb.mbn.or.jp Simon simon@masi.ibp.fr Simon Burge simonb@telstra.com.au Simon Dick simond@irrelevant.org Simon J Gerraty sjg@melb.bull.oz.au Simon Marlow simonm@dcs.gla.ac.uk Simon Shapiro shimon@simon-shapiro.org Sin'ichiro MIYATANI siu@phaseone.co.jp Slaven Rezic eserte@cs.tu-berlin.de Soochon Radee slr@mitre.org Soren Dayton csdayton@midway.uchicago.edu Soren Dossing sauber@netcom.com Soren S. Jorvang soren@wheel.dk Stefan Bethke stb@hanse.de Stefan Eggers seggers@semyam.dinoco.de Stefan Moeding s.moeding@ndh.net Stefan Petri unknown Stefan `Sec` Zehl sec@42.org Steinar Haug sthaug@nethelp.no Stephane E. Potvin sepotvin@videotron.ca Stephane Legrand stephane@lituus.fr Stephen Clawson sclawson@marker.cs.utah.edu Stephen F. Combs combssf@salem.ge.com Stephen Farrell stephen@farrell.org Stephen Hocking sysseh@devetir.qld.gov.au Stephen J. Roznowski sjr@home.net Stephen McKay syssgm@devetir.qld.gov.au Stephen Melvin melvin@zytek.com Steve Bauer sbauer@rock.sdsmt.edu Steve Coltrin spcoltri@unm.edu Steve Deering unknown Steve Gerakines steve2@genesis.tiac.net Steve Gericke steveg@comtrol.com Steve Piette steve@simon.chi.il.US Steve Schwarz schwarz@alpharel.com Steven Enderle panic@subphase.de Steven G. Kargl kargl@troutmask.apl.washington.edu Steven H. Samorodin samorodi@NUXI.com Steven McCanne mccanne@cs.berkeley.edu Steven Plite splite@purdue.edu Steven Wallace unknown Stijn Hoop stijn@win.tue.nl Stuart Henderson stuart@internationalschool.co.uk Sue Blake sue@welearn.com.au Sugimoto Sadahiro ixtl@komaba.utmc.or.jp SUGIMURA Takashi sugimura@jp.FreeBSD.org Sugiura Shiro ssugiura@duo.co.jp Sujal Patel smpatel@wam.umd.edu Sungman Cho smcho@tsp.korea.ac.kr Sune Stjerneby stjerneby@usa.net SURANYI Peter suranyip@jks.is.tsukuba.ac.jp Suzuki Yoshiaki zensyo@ann.tama.kawasaki.jp Svein Skogen tds@nsn.no Sybolt de Boer bolt@xs4all.nl Tadashi Kumano kumano@strl.nhk.or.jp Taguchi Takeshi taguchi@tohoku.iij.ad.jp TAKAHASHI Kaoru kaoru@kaisei.org Takahiro Yugawa yugawa@orleans.rim.or.jp Takashi Mega mega@minz.org Takashi Uozu j1594016@ed.kagu.sut.ac.jp Takayuki Ariga a00821@cc.hc.keio.ac.jp Takeru NAIKI naiki@bfd.es.hokudai.ac.jp Takeshi Amaike amaike@iri.co.jp Takeshi MUTOH mutoh@info.nara-k.ac.jp Takeshi Ohashi ohashi@mickey.ai.kyutech.ac.jp Takeshi WATANABE watanabe@crayon.earth.s.kobe-u.ac.jp Takuya SHIOZAKI tshiozak@makino.ise.chuo-u.ac.jp Tatoku Ogaito tacha@tera.fukui-med.ac.jp Tatsuya Kudoh cdr@cosmonet.org Ted Buswell tbuswell@mediaone.net Ted Faber faber@isi.edu Ted Lemon mellon@isc.org Terry Lambert terry@lambert.org Terry Lee terry@uivlsi.csl.uiuc.edu Tetsuya Furukawa tetsuya@secom-sis.co.jp Theo de Raadt deraadt@OpenBSD.org Thomas thomas@mathematik.uni-Bremen.de Thomas D. Dean tomdean@ix.netcom.com Thomas David Rivers rivers@dignus.com Thomas G. McWilliams tgm@netcom.com Thomas Graichen graichen@omega.physik.fu-berlin.de Thomas König Thomas.Koenig@ciw.uni-karlsruhe.de Thomas Ptacek unknown Thomas Quinot thomas@cuivre.fr.eu.org Thomas A. Stephens tas@stephens.org Thomas Stromberg tstrombe@rtci.com Thomas Valentino Crimi tcrimi+@andrew.cmu.edu Thomas Wintergerst thomas@lemur.nord.de Þórður Ívarsson totii@est.is Thierry Thomas tthomas@mail.dotcom.fr Timothy Jensen toast@blackened.com Tim Kientzle kientzle@netcom.com Tim Singletary tsingle@sunland.gsfc.nasa.gov Tim Wilkinson tim@sarc.city.ac.uk Timo J. Rinne tri@iki.fi Tobias Reifenberger treif@mayn.de Todd Miller millert@openbsd.org Tom root@majestix.cmr.no Tom tom@sdf.com Tom Gray - DCA dcasba@rain.org Tom Jobbins tom@tom.tj Tom Pusateri pusateri@juniper.net Tom Rush tarush@mindspring.com Tom Samplonius tom@misery.sdf.com Tomohiko Kurahashi kura@melchior.q.t.u-tokyo.ac.jp Tony Kimball alk@Think.COM Tony Li tli@jnx.com Tony Lynn wing@cc.nsysu.edu.tw Tony Maher Tony.Maher@eBioinformatics.com Torbjorn Granlund tege@matematik.su.se Toshihiko SHIMOKAWA toshi@tea.forus.or.jp Toshihiro Kanda candy@kgc.co.jp Toshiomi Moriki Toshiomi.Moriki@ma1.seikyou.ne.jp Trefor S. trefor@flevel.co.uk Trenton Schulz twschulz@cord.edu Trevor Blackwell tlb@viaweb.com Udo Schweigert ust@cert.siemens.de Ugo Paternostro paterno@dsi.unifi.it Ulf Kieber kieber@sax.de Ulli Linzen ulli@perceval.camelot.de URATA Shuichiro s-urata@nmit.tmg.nec.co.jp Uwe Arndt arndt@mailhost.uni-koblenz.de Vadim Belman vab@lflat.vas.mobilix.dk Vadim Chekan vadim@gc.lviv.ua Vadim Kolontsov vadim@tversu.ac.ru Vadim Mikhailov mvp@braz.ru Valentin Nechayev netch@lucky.net &a.logo; Van Jacobson van@ee.lbl.gov Vasily V. Grechishnikov bazilio@ns1.ied-vorstu.ac.ru Vasim Valejev vasim@uddias.diaspro.com Vernon J. Schryver vjs@mica.denver.sgi.com Veselin Slavov vess@btc.net Vic Abell abe@cc.purdue.edu Ville Eerola ve@sci.fi Vince Valenti vince@blue-box.net Vincent Poy vince@venus.gaianet.net Vincenzo Capuano VCAPUANO@vmprofs.esoc.esa.de Virgil Champlin champlin@pa.dec.com Vladimir A. Jakovenko vovik@ntu-kpi.kiev.ua Vladimir Kushnir kushn@mail.kar.net Vsevolod Lobko seva@alex-ua.com W. Gerald Hicks wghicks@bellsouth.net W. Richard Stevens rstevens@noao.edu Walt Howard howard@ee.utah.edu Walt M. Shandruk walt@erudition.net Warren Toomey wkt@csadfa.cs.adfa.oz.au Wayne Scott wscott@ichips.intel.com Werner Griessl werner@btp1da.phy.uni-bayreuth.de Wes Santee wsantee@wsantee.oz.net Wietse Venema wietse@wzv.win.tue.nl Wiljo Heinen wiljo@freeside.ki.open.de Willem Jan Withagen wjw@surf.IAE.nl William Jolitz withheld William Liao william@tale.net Wojtek Pilorz wpilorz@celebris.bdk.lublin.pl Wolfgang Helbig helbig@ba-stuttgart.de Wolfgang Solfrank ws@tools.de Wolfgang Stanglmeier wolf@FreeBSD.org Wu Ching-hong woju@FreeBSD.ee.Ntu.edu.TW Yarema yds@ingress.com Yaroslav Terletsky ts@polynet.lviv.ua Yasuhiro Fukama yasuf@big.or.jp Yasuhito FUTATSUKI futatuki@fureai.or.jp Yen-Ming Lee leeym@bsd.ce.ntu.edu.tw Yen-Shuo Su yssu@CCCA.NCTU.edu.tw Yin-Jieh Chen yinjieh@Crazyman.Dorm13.NCTU.edu.tw Yixin Jin yjin@rain.cs.ucla.edu Yoichi Asai yatt@msc.biglobe.ne.jp Yoichi Nakayama yoichi@eken.phys.nagoya-u.ac.jp Yoshiaki Uchikawa yoshiaki@kt.rim.or.jp Yoshihiko SARUMRU mistral@imasy.or.jp Yoshihisa NAKAGAWA y-nakaga@ccs.mt.nec.co.jp Yoshikazu Goto gotoh@ae.anritsu.co.jp Yoshimasa Ohnishi ohnishi@isc.kyutech.ac.jp Yoshishige Arai ryo2@on.rim.or.jp Yuichi MATSUTAKA matutaka@osa.att.ne.jp Yujiro MIYATA miyata@bioele.nuee.nagoya-u.ac.jp Yu-Shun Wang yushunwa@isi.edu Yusuke Nawano azuki@azkey.org Yuu Yashiki s974123@cc.matsuyama-u.ac.jp Yuuki SAWADA mami@whale.cc.muroran-it.ac.jp Yuuichi Narahara aconitum@po.teleway.ne.jp Yuval Yarom yval@cs.huji.ac.il Yves Fonk yves@cpcoup5.tn.tudelft.nl Yves Fonk yves@dutncp8.tn.tudelft.nl Zach Heilig zach@gaffaneys.com Zach Zurflu zach@pabst.bendnet.com Zahemszhky Gabor zgabor@code.hu Zhong Ming-Xun zmx@mail.CDPA.nsysu.edu.tw 386BSD Patch Kit Patch Contributors (in alphabetical order by first name): Adam Glass glass@postgres.berkeley.edu Adrian Hall ahall@mirapoint.com Andrey A. Chernov ache@astral.msk.su Andrew Herbert andrew@werple.apana.org.au Andrew Moore alm@netcom.com Andy Valencia ajv@csd.mot.com jtk@netcom.com Arne Henrik Juul arnej@Lise.Unit.NO Bakul Shah bvs@bitblocks.com Barry Lustig barry@ictv.com Bob Wilcox bob@obiwan.uucp Branko Lankester Brett Lymn blymn@mulga.awadi.com.AU Charles Hannum mycroft@ai.mit.edu Chris G. Demetriou cgd@postgres.berkeley.edu Chris Torek torek@ee.lbl.gov Christoph Robitschko chmr@edvz.tu-graz.ac.at Daniel Poirot poirot@aio.jsc.nasa.gov Dave Burgess burgess@hrd769.brooks.af.mil Dave Rivers rivers@ponds.uucp David Dawes dawes@physics.su.OZ.AU David Greenman dg@Root.COM Eric J. Haug ejh@slustl.slu.edu Felix Gaehtgens felix@escape.vsse.in-berlin.de Frank Maclachlan fpm@crash.cts.com Gary A. Browning gab10@griffcd.amdahl.com Gary Howland gary@hotlava.com Geoff Rehmet csgr@alpha.ru.ac.za Goran Hammarback goran@astro.uu.se Guido van Rooij guido@gvr.org Guy Antony Halse guy@rucus.ru.ac.za Guy Harris guy@auspex.com Havard Eidnes Havard.Eidnes@runit.sintef.no Herb Peyerl hpeyerl@novatel.cuc.ab.ca Holger Veit Holger.Veit@gmd.de Ishii Masahiro, R. Kym Horsell J.T. Conklin jtc@cygnus.com Jagane D Sundar jagane@netcom.com James Clark jjc@jclark.com James Jegers jimj@miller.cs.uwm.edu James W. Dolter James da Silva jds@cs.umd.edu et al Jay Fenlason hack@datacube.com Jim Wilson wilson@moria.cygnus.com Jörg Lohse lohse@tech7.informatik.uni-hamburg.de Jörg Wunsch joerg_wunsch@uriah.heep.sax.de John Dyson John Woods jfw@eddie.mit.edu Jordan K. Hubbard jkh@whisker.hubbard.ie Julian Elischer julian@dialix.oz.au Julian Stacey jhs@FreeBSD.org Karl Dietz Karl.Dietz@triplan.com Karl Lehenbauer karl@NeoSoft.com karl@one.neosoft.com Keith Bostic bostic@toe.CS.Berkeley.EDU Ken Hughes Kent Talarico kent@shipwreck.tsoft.net Kevin Lahey kml%rokkaku.UUCP@mathcs.emory.edu kml@mosquito.cis.ufl.edu Konstantinos Konstantinidis kkonstan@duth.gr Marc Frajola marc@dev.com Mark Tinguely tinguely@plains.nodak.edu tinguely@hookie.cs.ndsu.NoDak.edu Martin Renters martin@tdc.on.ca Michael Clay mclay@weareb.org Michael Galassi nerd@percival.rain.com Mike Durkin mdurkin@tsoft.sf-bay.org Naoki Hamada nao@tom-yam.or.jp Nate Williams nate@bsd.coe.montana.edu Nick Handel nhandel@NeoSoft.com nick@madhouse.neosoft.com Pace Willisson pace@blitz.com Paul Kranenburg pk@cs.few.eur.nl Paul Mackerras paulus@cs.anu.edu.au Paul Popelka paulp@uts.amdahl.com Peter da Silva peter@NeoSoft.com Phil Sutherland philsuth@mycroft.dialix.oz.au Poul-Henning Kampphk@FreeBSD.org Ralf Friedl friedl@informatik.uni-kl.de Rick Macklem root@snowhite.cis.uoguelph.ca Robert D. Thrush rd@phoenix.aii.com Rodney W. Grimes rgrimes@cdrom.com Sascha Wildner swildner@channelz.GUN.de Scott Burris scott@pita.cns.ucla.edu Scott Reynolds scott@clmqt.marquette.mi.us Sean Eric Fagan sef@kithrup.com Simon J Gerraty sjg@melb.bull.oz.au sjg@zen.void.oz.au Stephen McKay syssgm@devetir.qld.gov.au Terry Lambert terry@icarus.weber.edu Terry Lee terry@uivlsi.csl.uiuc.edu Tor Egge Tor.Egge@idi.ntnu.no Warren Toomey wkt@csadfa.cs.adfa.oz.au Wiljo Heinen wiljo@freeside.ki.open.de William Jolitz withheld Wolfgang Solfrank ws@tools.de Wolfgang Stanglmeier wolf@dentaro.GUN.de Yuval Yarom yval@cs.huji.ac.il diff --git a/en_US.ISO8859-1/articles/dialup-firewall/article.sgml b/en_US.ISO8859-1/articles/dialup-firewall/article.sgml index c76119415a..5b3c9d3283 100644 --- a/en_US.ISO8859-1/articles/dialup-firewall/article.sgml +++ b/en_US.ISO8859-1/articles/dialup-firewall/article.sgml @@ -1,361 +1,361 @@ %man; ]>
Dialup firewalling with FreeBSD Marc Silver
marcs@draenor.org
 - $Date: 2001-04-17 15:53:37 $ + $Date: 2001-06-24 21:01:53 $ This article documents how to setup a firewall using a PPP dialup with FreeBSD and IPFW, and specifically with firewalling over a dialup with a dynamically assigned IP address. This document does not cover setting up your PPP connection in the first place. Preface Dialup Firewalling with FreeBSD This document aims to cover the process that is required in order to setup firewalling with FreeBSD when are dynamically assigned an IP address by your ISP. While every effort has been made to make this document as informative and correct as possible, you are welcome to mail your comments/suggestions to the - maintainer. + marcs@draenor.org. Kernel Options The first thing you'll need to do is recompile your kernel in FreeBSD. If you need more information on how to recompile the kernel, then the best place to start is the kernel configuration section in the Handbook. You need to compile the following options into the kernel: options IPFIREWALL Enables the kernel's firewall code. options IPFIREWALL_VERBOSE Sends logged packets to the system logger. options IPFIREWALL_VERBOSE_LIMIT=100 Limits the number of times a matching entry is logged. This stops your log files filling up with lots of repetitive entries. 100 is a reasonable number to use, but you can adjust it based on your requirements. options IPDIVERT Enables divert sockets, which will be shown later. There are also some other OPTIONAL items that you can compile into the kernel for some added security. These are not required in order to get firewalling to work, but some more paranoid users may want to use them. options TCP_RESTRICT_RST This option blocks all TCP RST packets. This is best used for systems that might be exposed to SYN flooding (IRC Servers are a good example) or for those who do not want to be easily portscannable. options TCP_DROP_SYNFIN This option ignores TCP packets with SYN and FIN. This prevents tools such as nmap etc from identifying the TCP/IP stack of the machine, but breaks support for RFC1644 extensions. This is NOT recommended if the machine will be running a web server. Don't reboot once you have recompiled the kernel. Hopefully, we will need to reboot just once in order to complete the installing of the firewall. Changing <filename>/etc/rc.conf</filename> to load the firewall We now need to make some changes to /etc/rc.conf in order to tell it about the firewall. Simply add the following lines: firewall_enable="YES" firewall_script="/etc/firewall/fwrules" natd_enable="YES" natd_interface="tun0" natd_flags="-dynamic" For more information on what the above do take a look at /etc/defaults/rc.conf and read &man.rc.conf.5; Disable PPP's network address translation You may already be using PPP's built in network address translation (NAT). If that is the case you will have to disable it, as these examples use &man.natd.8; to do the same. If you already have a block of entries to automatically start PPP it probably looks like this: ppp_enable="YES" ppp_mode="auto" ppp_nat="YES" ppp_profile="profile" If so, remove the ppp_nat="YES" line. You will also need to remove any nat enable yes or alias enable yes in /etc/ppp/ppp.conf. The ruleset for the firewall We're nearly done now. All that remains now is to define the firewall rules and then we can reboot and the firewall should be up and running. I realise that everyone will want something slightly different when it comes to their rulebase. What I've tried to do is write a rulebase that suits most dialup users. You can obviously modify it to your needs by simply using the following rules as the foundation for your own rulebase. First, let's start with the basics of closed firewalling. What you want to do is deny everything by default and then only open up for the things you really need. Rules should be in the order of allow first and then deny. The premise is that you add the rules for your allows, and then everything else is denied. :) Now, let's make the dir /etc/firewall. Change into the directory and edit the file fwrules as we specified in rc.conf. Please note that you can change this filename to be anything you wish. This guide just gives an example of a filename. Now, let's look at a sample firewall file, and we'll detail everything in it. # Firewall rules # Written by Marc Silver (marcs@draenor.org) # http://draenor.org/ipfw # Freely distributable # Define the firewall command (as in /etc/rc.firewall) for easy # reference. Helps to make it easier to read. fwcmd="/sbin/ipfw" # Force a flushing of the current rules before we reload. $fwcmd -f flush # Divert all packets through the tunnel interface. $fwcmd add divert natd all from any to any via tun0 # Allow all data from my network card and localhost. Make sure you # change your network card (mine was fxp0) before you reboot. :) $fwcmd add allow ip from any to any via lo0 $fwcmd add allow ip from any to any via fxp0 # Allow all connections that I initiate. $fwcmd add allow tcp from any to any out xmit tun0 setup # Once connections are made, allow them to stay open. $fwcmd add allow tcp from any to any via tun0 established # Everyone on the internet is allowed to connect to the following # services on the machine. This example shows that people may connect # to ssh and apache. $fwcmd add allow tcp from any to any 80 setup $fwcmd add allow tcp from any to any 22 setup # This sends a RESET to all ident packets. $fwcmd add reset log tcp from any to any 113 in recv tun0 # Allow outgoing DNS queries ONLY to the specified servers. $fwcmd add allow udp from any to x.x.x.x 53 out xmit tun0 # Allow them back in with the answers... :) $fwcmd add allow udp from x.x.x.x 53 to any in recv tun0 # Allow ICMP (for ping and traceroute to work). You may wish to # disallow this, but I feel it suits my needs to keep them in. $fwcmd add 65435 allow icmp from any to any # Deny all the rest. $fwcmd add 65435 deny log ip from any to any You now have a fully functional firewall that will allow on connections to ports 80 and 22 and will log any other connection attempts. Now, you should be able to safely reboot and your firewall should come up fine. If you find this incorrect in anyway or experience any problems, or have any suggestions to improve this page, please email me. Questions Why are you using natd and ipfw when you could be using the built in ppp-filters? I'll have to be honest and say there's no definitive reason why I use ipfw and natd instead of the built in ppp filters. From the discussions I've had with people the consensus seems to be that while ipfw is certainly more powerful and more configurable than the ppp filters, what it makes up for in functionality it loses in being easy to customise. One of the reasons I use it is because I prefer firewalling to be done at a kernel level rather than by a userland program. If I'm using private addresses internally, such as in the 192.168.0.0 range, Could I add a command like $fwcmd add deny all from any to 192.168.0.0:255.255.0.0 via tun0 to the firewall rules to prevent outside attempts to connect to internal machines? The simple answer is no. The reason for this is that natd is doing address translation for anything being diverted through the tun0 device. As far as it's concerned incoming packets will speak only to the dynamically assigned IP address and NOT to the internal network. Note though that you can add a rule like $fwcmd add deny all from 192.168.0.4:255.255.0.0 to any via tun0 which would limit a host on your internal network from going out via the firewall. There must be something wrong. I followed your instructions to the letter and now I am locked out. This tutorial assumes that you are running userland-ppp, therefore the supplied ruleset operates on the tun0 interface, which corresponds to the first connection made with &man.ppp.8; (a.k.a. user-ppp). Additional connections would use tun1, tun2 and so on. You should also note that &man.pppd.8; uses the ppp0 interface instead, so if you start the connection with &man.pppd.8; you must substitute tun0 for ppp0. A quick way to edit the firewall rules to reflect this change is shown below. The original ruleset is backed up as fwrules_tun0. &prompt.user; cd /etc/firewall /etc/firewall&prompt.user; su Password: /etc/firewall&prompt.root; mv fwrules fwrules_tun0 /etc/firewall&prompt.root; cat fwrules_tun0 | sed s/tun0/ppp0/g > fwrules To know whether you are currently using &man.ppp.8; or &man.pppd.8; you can examine the output of &man.ifconfig.8; once the connection is up. E.g., for a connection made with &man.pppd.8; you would see something like this (showing only the relevant lines): &prompt.user; ifconfig (skipped...) ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1524 inet xxx.xxx.xxx.xxx --> xxx.xxx.xxx.xxx netmask 0xff000000 (skipped...) On the other hand, for a connection made with &man.ppp.8; (user-ppp) you should see something similar to this: &prompt.user; ifconfig (skipped...) ppp0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 (skipped...) tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1524 (IPv6 stuff skipped...) inet xxx.xxx.xxx.xxx --> xxx.xxx.xxx.xxx netmask 0xffffff00 Opened by PID xxxxx (skipped...)
diff --git a/en_US.ISO8859-1/books/corp-net-guide/book.sgml b/en_US.ISO8859-1/books/corp-net-guide/book.sgml index 05fcec7efc..b817f240f8 100644 --- a/en_US.ISO8859-1/books/corp-net-guide/book.sgml +++ b/en_US.ISO8859-1/books/corp-net-guide/book.sgml @@ -1,3213 +1,3213 @@ - + The FreeBSD Corporate Networker's Guide Ted Mittelstaedt 2000 Addison-Wesley Longman, Inc ISBN: 0-201-70481-1 The eighth chapter of the book, The FreeBSD Corporate Networker's Guide is excerpted here with the permission of the publisher. No part of it may be further reproduced or distributed without the publisher's express written - permission. + Chanda.Leary-Coutu@awl.com. The other chapters of the book covers topics such as system administration, fileserving, and e-mail delivery. More information about this book is available from the publisher, with whom you can also sign up to receive news of related titles. The author's web site for the book includes sample code, working examples, errata and a Q&A forum, and is available at http://www.freebsd-corp-net-guide.com/. Printserving Printserving is a complicated topic. There are many different software interfaces to printers, as well as a wide variety of printer hardware interfaces. This chapter covers the basics of setting up a print queue, using Samba to print, and administering print queues and connections. PC printing history In the early days of the personal computer, printing was simple. The PC owner bought a cheap printer, usually a dot matrix that barely supported ASCII, and plugged it into the computer with a parallel cable. Applications would either work with the printer or not, and most did because all they could do was output DOS or ASCII text. The few software applications that supported graphics generally could only output on specific makes and models of printers. Shared network printing, if it existed, was usually done by some type of serial port switchbox. This was the general state of affairs with the PC until the Windows operating system was released. All at once, application programmers were finally free of the restrictions of worrying about how some printer manufacturer would change printer control codes. Graphics printing, in the form of fonts and images, was added to most applications, and demand for it rapidly increased across the corporation. Large, high-capacity laser printers designed for office printing appeared on the scene. Printing went from 150 to 300 to 600dpi for the common desktop laser printer. Today organizational network printing is complex, and printers themselves are more complicated. Most organizations find that sharing a few high-quality laser printers is much more cost effective than buying many cheaper dot matrix units. Good network print serving is a necessity, and it can be very well provided by the FreeBSD UNIX system. Printer communication protocols and hardware Printers that don't use proprietary vendor codes communicate with computers using one or more of three major printing protocols. The communication is done over a hardware cable that can be a parallel connection (printer port) or a serial connection (COM port). ASCII Printing Protocol The ASCII protocol is the simplest protocol used, as well as the oldest. ASCII is also used to represent text files internally in the DOS, UNIX, and Windows operating systems. Therefore, data taken from a text file or a directory listing generally requires little preparation before being sent to the printer, other than a newline-to-carriage return/linefeed conversion for UNIX. Printers usually follow the DOS text file convention of the print head requiring an explicit carriage return character followed by a linefeed character at the end of a line of text. Since UNIX uses only the linefeed character to terminate text, an additional carriage return character must be added to the end of each line in raw text print output; otherwise, text prints in a stairstep output. (Some printers have hardware or software switches to do the conversion) PostScript Printing Protocol Adobe introduced the PostScript language in 1985; it is used to enable the printout of high quality graphics and styled font text. PostScript is now the de-facto print standard in the UNIX community, and the only print standard in the Macintosh community. Numerous UNIX utilities exist to beautify and enhance text printing with PostScript. PostScript can be used to download font files into a printer as well as the data to be printed. PostScript commands can be sent to instruct the printer CPU to image, rotate, and scale complex graphics and images, thus freeing the host CPU. Scaling is particularly important with fonts since the document with the font has been produced on a computer screen with far lower resolution than the printer. For example, a 1024x768 computer screen on a 17-inch monitor allows for a resolution of approximately 82dpi, a modern desktop printer prints at a resolution of 600dpi. Therefore, a font must be scaled at least seven times larger for WYSIWYG output! PostScript printers generally come with a number of resident fonts. For example, the NEC Silentwriter 95 contains Courier, Helvetica, ITC Avant Garde Gothic Book, ITC Bookman Light, New Century Schoolbook Roman, Palatino Roman, Times Roman, and several symbol fonts. These are stored in Read Only Memory (ROM) in the printer. When a page is printed from a Windows client that contains a font not in the printer, a font substitution table is used. If no substitute can be made, Courier is usually used. The user should be conscious of this when creating documents - documents with fonts not listed in the substitution table may cause other users problems when printing. Avoid use of strange fonts for documents that will be widely distributed. The user program can choose to download different fonts as outline fonts to the PostScript printer if desired. Fonts that are commonly used by the user are often downloaded to PostScript printers that are connected directly to the user's computer, the fonts are then available to successive print jobs until the printer is turned off. When PostScript printers are networked, the clients must download any fonts desired with each print job. Since jobs come from different clients, the clients cannot assume that downloaded fonts will still be in the printer. PostScript print jobs also contain a header that is sent describing the page layout, among other things. On a shared network printer, this header must also be downloaded with each print job. Although some PostScript drivers allow downloading of the header only once, this usually requires a bi-directional serial connection to the printer, instead of a unidirectional parallel connection. PostScript print jobs can be sent either as binary data or as ASCII. The main advantage of binary data transmission is that it is faster. However, not all PostScript printers support it. Also, fonts can generally not be downloaded in binary. When FreeBSD is used as a printserver, ASCII PostScript printing should be selected on the clients, this is generally the default with most PostScript drivers. The Adobe company licenses PostScript interpreters as well as resident fonts to printer manufacturers, and extracts a hefty license fee from any printer manufacturer who wants to use them in its printer. This presents both a benefit and a problem to the end user. Although a single company holding control over a standard can guarantee compliance, it does significantly raise the cost of the printer. As a result, PostScript has not met with much success in lower-end laser and inkjet Windows printing market, despite the fact that Adobe distributes PostScript software operating system drivers for free. One issue that is a concern when networking PostScript printers is the selection of banner page, (also known as header page, or burst page) printing. UNIX shared printing began with ASCII line printers, and since UNIX is a multiuser system, often many different user print jobs piled up in the printer output hopper. To separate these jobs the UNIX printing system programs support banner page printing if the client program that submits jobs asks for them. These pages print at the beginning or end of every print job and contain the username, submittal date, and so on.. By default, most clients, whether remote (e.g., a Windows LPR client) or local (e.g., the /usr/bin/lpr program) trigger a banner page to be printed. One problem is that some PostScript printers abort the entire job if they get unformatted ASCII text instead of PostScript. (In general, PostScript printers compatible with Hewlett-Packard Printer Control Language [HPPCL] handle banners without problems) Banner printing should be disabled for any printers with this problem, unless PostScript banner page printing is set up on the server. HPPCL Printing Protocol The Hewlett Packard company currently holds the largest market share of desktop inkjet and office laser printers. Back when Windows was released, HP decided to expand into the desktop laser jet market with the first LaserJet series of printers. At the time there was much pressure on Microsoft to use Adobe Type Manager for scaleable fonts within Windows, and to print PostScript to higher-end printers. Microsoft decided against doing this and used a technically inferior font standard, Truetype. They thought that it would be unlikely that the user would download fonts to the printer, since desktop Publishing was not being done on PC's at the time. Instead users would rasterize the entire page to the printer using whatever proprietary graphics printer codes the selected printer needed. HP devised HPPCL for their LaserJets, and make PostScript an add-on. The current revision of HPPCL now allows for many of the same scaling and font download commands that PostScript does. HP laser jet printers that support PostScript can be distinguished by the letter "M" in their model number. (M is for Macintosh, since Macintosh requires PostScript to print) For example, the HP 6MP has PostScript, the 6P doesn't. HPPCL has almost no support in the UNIX applications market, and it is very unlikely that any will appear soon. One big reason is the development of the free Ghostscript PostScript interpreter. Ghostscript can take a PostScript input stream and print it on a PCL printer under UNIX. Another reason is the UNIX community's dislike of reinventing the wheel. HPPCL has no advantage over PostScript, and in many ways there are fewer problems with PostScript. Considering that PostScript can be added to a printer, either by hardware or use of Ghostscript, what is the point of exchanging an existing working solution for a slightly technically inferior one? Over the life of the printer, taking into account the costs of toner, paper, and maintenance, the initial higher cost of PostScript support is infinitesimal. Network Printing Basics The most common network printing implementation is a printserver accepting print jobs from clients tied to the server via a network cable. Printservers The term "printserver" is one of those networking terms, like packet, that has been carelessly tossed around until it's meaning has become somewhat confusing and blurred. To be specific, a printserver is simply a program that arbitrates print data from multiple clients for a single printer. Printservers can be implemented in one of the four methods described in the following sections. Printserver on the fileserver The printer can be physically cabled to the PC running the Network OS. Print jobs are submitted by clients to the printserver software on the fileserver, which sends them down the parallel or serial cable to the printer. The printer must be physically close to the fileserver. This kind of printserving is popular in smaller workgroup networks, in smaller offices.
Printserver on the fileserver ,---------. | ======= | Server | ======= | +---------------------+ ,-----. +-----------+ | +---------------+ | | | | Printer [ ]------------[ ] | Printserver | | |_____| +-----------+ Parallel | | Software | [ ]------_________ Cable | +---------------+ | / ::::::: \ +---------------------+ `---------' Network PC Printer, connected to a network server running printserver software, with one or more network PCs printing through it.
Printserver on a separate PC It is possible to run a print server program on a cheap PC that is located next to the printer and plugged into it via parallel cable. This program simply acts as a pass-through program, taking network packets from the network interface and passing them to the printer. This kind of server doesn't allow any manipulation of print jobs, jobs usually come from a central fileserver, where jobs are controlled.
Printserver on a separate PC Fileserver ,----------------. ,---------. .---| | === | | ======= | ,-----. | `----------======' | ======= | | | | +-----------+ |_____| | | Printer [ ]------------_________---------| Ethernet +-----------+ Parallel / ::::::: \ | Cable `---------' | Printserver | ,-----. | | | | |_____| `---------_________ / ::::::: \ `---------' Network PC Printer connected to a printserver (typically running FreeBSD), with network files hosted on a separate machine, and a network PC, able to access both resources.
Printserver on a separate hardware box A printserver on a separate hardware box is exemplified by network devices such as the Intel Netport, the HP JetDirect Ex, the Osicom/DPI NETPrint, and the Lexmark MarkNet. Basically, these are plastic boxes with an Ethernet connection on one side and a parallel port on the other. Like a printserver on a PC, these devices don't allow remote job manipulation, and merely pass packets from the network down the parallel port to the printer.
Printserver on a separate hardware box Fileserver ,----------------. ,---------. .---| | === | | ======= | | `----------======' | ======= | Printserver | +-----------+ ,--------. | | Printer [ ]-----------[ ] ooo [ ]-------| Ethernet +-----------+ Parallel `--------' | Cable | | ,-----. | | | | |_____| `---------_________ / ::::::: \ `---------' Network PC Printer connected to a dedicated print server appliance.
Printserver in the Printer The HP JetDirect Internal is the best known printserver of this type. It is inserted into a slot in the printer case, and it works identically to the external JetDirect units.
Printeserver in the printer Fileserver ,----------------. ,---------. .---| | === | | ======= | | `----------======' | ======= | | +-----------+ | | Printer [ ]------------------------------| Ethernet +-----------+ | | | ,-----. | | | | |_____| `---------_________ / ::::::: \ `---------' Network PC Printer with an embedded print server, connecting directly to the local network.
Printspools Printspooling is an integral part of network printing. Since the PC can spit out data much faster than the printer can accept it, the data must be buffered in a spool at some location. In addition, because many clients share printers, when clients send print jobs at the same time, jobs must be placed on a queue so that one can be printed after the other. Logical location of the print spool Printspooling can be implemented at one of three locations The client. Clients can be required to spool their own print jobs on their own disks. For example, when a Windows client application generates a print job the job must be placed on the local client's hard drive. Once the remote print server is free to accept the job it signals the client to start sending the job a bit at a time. Client spooling is popular in peer-to-peer networks with no defined central fileserver. However, it is impossible for a central administrator to perform advanced print job management tasks such as moving a particular print job ahead of another, or deleting jobs. The printserver. If each printer on the network is allocated their own combination print spooler-printserver, jobs can stack at the printer. Many of the larger printers with internal printservers have internal hard disks for this purpose. Although this enables basic job management, it still restricts the ability to move jobs from one printer to another. A central print spooler on a fileserver. Print jobs are received from all clients on the network in the spool and then dispatched to the appropriate printer. This scheme is the best for locations with several busy printers and many clients. Administration is extremely simple because all print jobs are spooled on a central server, which is particularly important in bigger organizations. Many large organizations have standardized on PostScript printing for all printing; in the event that a particular printer fails and is offline, incoming PostScript print jobs can be rerouted automatically to another printer. Since all printers and clients are using PostScript, clients don't need to be reconfigured when this happens. Print jobs appear the same whether printed on a 4 page-per-minute NEC Silentwriter 95, or a 24 page-per-minute HP LaserJet 5SiMX if both printers are defined in the client as PostScript printers.
Print spool locations Client ,---------. PC | ======= | ,-----. | ======= | | | +-----------+ |_____| | Printer [ ]---------------------------------------------------_________ +-----------+ / ::::::: \ `---------' Spool Printserver ,---------. PC | ======= | ,-----. | ======= | | | +-----------+ ,----------------. |_____| | Printer [ ]--------------| | === |-------------------_________ +-----------+ `----------======' / ::::::: \ Spool `---------' Fileserver ,---------. PC | ======= | ,-----. | ======= | Printserver Fileserver | | +-----------+ ,----------------. ,----------------. |_____| | Printer [ ]----| | === |-----| | === |------_________ +-----------+ `----------======' `----------======' / ::::::: \ Spool `---------' Possible locations for the print spool
FreeBSD is an excellent platform to implement centralized printserving and print spooling. The rest of this chapter concentrates on the centralized print spooler model. Note that PostScript printing is not a requirement for this model--the HPPCL protocol can be the standard print protocol as well. For transparent printing between printers with HPPCL, however, the printer models must be similar. Physical location of the print spool In some companies, the central fileserver is often placed in a closet, locked away. Printers, on the other hand, are best located in high traffic areas for ease of use. Network printing works best when the printers are evenly distributed throughout the organization. Attempting to place all the major printers in one location, as technically advantageous as it may seem, merely provokes users to requisition smaller printers that are more convenient for that quick print job. The administrator may end up with a datacenter full of nice, expensive printers that are never used, while the smaller personal laser printers scattered throughout the plant bear most of the printing load. The big problem with this is that scattering printers through the organization makes it difficult to utilize the 3 possible parallel ports on the fileserver due to parallel port distance limitations. Although high-speed serial ports may extend the distance, not many printers have good serial ports on them. This is where the hardware network print server devices can come into play. I prefer using these devices because they are much cheaper and more reliable than a standalone PC running printserver software. For example, Castelle http://www.castelle.com sells the LANpress 1P/10BT printserver for about $170.00. Using these devices a FreeBSD UNIX server can have dozens of print spools accepting print jobs and then route them back out over the network to these remote printserver boxes. If these hardware servers are used, they must support the Line Printer Daemon (LPD) print protocol. With a scheme like this it is important to have enough disk space on the spool to handle the print jobs. A single large PowerPoint presentation PostScript print job containing many graphics may be over 100MB. When many such jobs stack up in the print spool waiting to print, the print spooler should have several gigabytes of free disk space available. Network Printing to Remote Spools Although several proprietary network printing protocols such as Banyan Vines and NetWare, are tied to proprietary protocols, FreeBSD Unix can use two TCP/IP network printing protocols to print to remote print spools. The two print protocols available on TCP/IP with FreeBSD are the open LPD protocol and the NetBIOS-over-TCP/IP Server Messaging Block (SMB) print protocol first defined by Intel and Microsoft and later used by IBM and Microsoft. The LPD protocol is defined in RFC1179 This network protocol is the standard print protocol used on all UNIX systems. LPD client implementations exist for all Windows operating systems and DOS. Microsoft has written LPD for the Windows NT versions, the other Windows operating system implementations are provided by third parties. The Microsoft Networking network protocol that runs on top of SMB can use NetBIOS over TCP/IP as defined in RFC1001 and RFC1002. This protocol has a specification for printing that is the same print protocol used to send print jobs to NT Server by Microsoft clients. To implement this protocol on FreeBSD requires the installation of the Samba client suite of programs discussed in Chapter 7. Setting up LPR on Windows clients The program clients use to print via LPD is the Line Printer Remote, or LPR program. The following instructions cover enabling this program on Windows clients. Windows 3.1/Windows for Workgroups 3.11 Several commercial TCP/IP stacks are available for Win31, that provide LPR client programs, in addition to the basic TCP/IP protocol to Win31. WfW has TCP/IP networking available for free from Microsoft, but it doesn't include an LPR client. Unfortunately, I have not come across a freeware implementation of a 16-bit Windows LPR client, so with the following instructions I use the Shareware program WLPRSPL available from http://www.winsite.com/info/pc/win3/winsock/wlprs41.zip. This program must be active during client printing, and is usually placed in the Startup group. Organizations that want to use UNIX as a printserver to a group of Win31 clients without using a commercial or shareware LPR program have another option. The Microsoft Networking client for DOS used underneath Win31 contains SMB-based printing which is covered later in the chapter. DOS networking client setup and use are covered in Chapter 2 and Chapter 7. If LPR-based client printing is desired and the organization doesn't want to upgrade to Win95, (which has several LPR clients available) the following instructions can be used. WLPRSPL needs a Winsock under Windows 3.1, so for the example I explain the setup of the Novell 16-bit TCP/IP client. The stack can be FTPed from Novell, and is easy to integrate into sites that already use the 16-bit NetWare networking client, usually NW 3.11 and 3.12. In most cases, however, sites that use NetWare + Win31 are probably best off printing through the NetWare server, then loading an LPR spooler as an Netware Loadable Module (NLM) to send the job over to FreeBSD. As an alternate, the Microsoft Networking DOS 16-bit TCP/IP client under Win31 contains a Winsock, as does Microsoft TCP/IP for WfW. The target machine used here is a Compaq Deskpro 386/33 with 12MB of ram with an operating version of Windows 3.1, and a 3com 3C579 EISA network card. The instructions assume an LPR printserver on the network, named mainprinter.my.domain.com with a print queue named RAW. Use the installation instructions in Exhibit 8.1 for a quick and dirty TCP/IP Winsock for Win31 systems. Administrators who already have the Novell IPX client installed should skip those steps. Installation of the Novell TCP/IP Winsock client Make sure that the machine has enough environment space (2048 bytes or more) by adding the following line to the config.sys file and rebooting: SHELL=C:\COMMAND.COM /E:2048 /P Obtain the TCP16.EXE file from ftp3.novell.com/pub/updates/eol/nweol/tcp16.exe. Obtain the Network Adapter support diskette for the network card in your machine. This should be supplied with the card, or available via FTP from the network adapter manufacturer's FTP site. Now you need the file LSL.COM. This is available on some Network Adapter Driver diskettes, it used to be available from the VLM121_2.EXE file from Novell but unfortunately this file is no longer publicly accessible from Novell. If you have vlm121_2.exe in a temporary directory, run it. This will extract a number of files. One of the files extracted is LSL.CO_ extract this file with the command nwunpack lsl.co_. Create the directory c:\nwclient. Then, copy lsl.com from the temporary directory into the directory. Obtain and install the printer driver for the model of printer that you will be spooling to and point it to LPT1:. Win31 and WfW 3.11 have an incomplete printer driver list, so if you need a driver Microsoft has many Win16 printer drivers on their FTP site. A list is available at ftp://ftp.microsoft.com/Softlib/index.txt. In addition, if you are installing a PostScript printer driver for a printer supplied in Win31, it may be necessary to patch the driver. The Microsoft PostScript driver supplied in Win31 is version 3.5. (The patch named PSCRIP.EXE which brought the PostScript driver to version 3.58 is no longer publicly available.) WfW already uses the more recent PostScript driver, as does Win31 version A. Installing the Adobe Postscript driver for Win31 is also an option. (see http://www.adobe.com/support/downloads/pdrvwin.htm for the version 3.1.2 Win31 PostScript driver). Look on the network adapter driver disk for the subdirectory nwclient/ and then look for the ODI driver with the adapter card. For example, on the 3com 3C509/3C579 adapter driver disk, the driver and location are \NWCLIENT\3C5X9.COM. Copy this driver to the c:\nwclient directory. Create a file called NET.CFG in the c:\nwclient directory. Often, the network card adapter driver diskette has a template for this file in the same location as the ODI driver. This can be modified, as can the following example: LINK SUPPORT BUFFERS 4 1600 MEMPOOL 8192 LINK DRIVER 3C5X9 ; PORT 300 (these are optional, if needed by card uncomment) ; INT 10 (optional, uncomment and modify if needed) Attempt to load the network card driver. First load lsl, then the ODI driver. With the 3com card the commands are: lsl 3c5x9 If the driver properly loads it will list the hardware port and interrupt settings for the network adapter. If it has loaded properly, unload the drivers in reverse order with the command: 3c5x9 /u lsl /u Go to the temporary directory that contains the tcp16.exe file and extract it by running the program. Run the install batch file by typing installr. It should list New Installation detected. It will then copy a number of files into nwclient, add some commented-out sections to net.cfg, and call edit on net.cfg. Read the editing instructions and make the appropriate entries. The sample net.cfg file from above would look like this. LINK SUPPORT BUFFERS 4 1600 MEMPOOL 8192 LINK DRIVER 3C5X9 FRAME ETHERNET_II Protocol TCPIP PATH TCP_CFG c:\nwclient ip_address 192.168.1.54 LAN_NET ip_netmask 255.255.255.0 LAN_NET ip_router 192.168.1.1 LAN_NET Bind 3C5X9 #1 Ethernet_II LAN_NET Save and exit, the Installer should list TCP16 installation completed. Reload the client with the commands: lsl 3c5x9 tcpip The TCPIP driver should list the IP numbers and other information. Optionally, create either a HOSTS file, or a RESOLV.CFG file (pointing to a nameserver) in c:\nwclient. Check to see this is operating properly by pinging a hostname. Add the c:\nwclient directory to the PATH, as well as the 3 startup commands in step 15 in autoexec.bat Installation of the LPR client on 16-bit Windows with a Winsock installed The following assumes a running Win31 installation with a Winsock or a running WfW installation with the 32-bit Microsoft TCP/IP protocol installed. Install the printer driver desired. See step 8 of the previous set of instructions. Obtain and extract into a temporary directory the wlprs41.zip file from the location mentioned above. Run setup.exe from the temporary directory containing the wlprs files are. In setup, accept default directory, and check Yes to add to its own group. Click Continue when asked for group name, and check whatever choice you want when asked to copy the doc files. Click No when asked to add the program to Startup. On the Unix FreeBSD print spooler, make sure that there is an entry in /etc/hosts.lpd or /etc/hosts.equiv for the client workstation, thereby allowing it to submit jobs. Double-click the Windows LPR Spooler icon in the Windows LPR Spooler group that is opened. When it asks for a valid spool directory, just select the c:\wlprspl directory that the program installed its files into. When asked for a valid Queue Definition File, just click OK to use the default filename. The program automatically creates a queue definition file. The program opens up with it's menu. Click Setup in the top menu, then select Define New Queue. For a local spool filename, just use the name of the remote queue (RAW) to which the client prints. For the remote printer name, use the same name as the remote queue (RAW) to which the client prints. For the remote hostname, use the machine name of the FreeBSD print spooler. mainprinter.ayedomain.com. For the Description, enter a description such as 3rd floor Marketing printer. For the protocol, leave the default of BSD LPR/LPD selected. Click on the Queue Properties, and make sure that the Print unfiltered is selected. If you're printing PostScript, then also click the Advanced options button. Make sure that Remove trailing Ctrl-D is unchecked, and that Remove Leading Ctrl-D is checked. Also with PostScript, if the printer cannot print ASCII, uncheck the Send header page box. (PostScript header/banner pages are discussed later in this chapter) Click OK. At the main menu of the program, click File, then Control Panel/Printers to bring up the Printers control panel of Windows. Make sure that the Use Print Manager button is checked, then highlight the printer driver and click the Connect button. Scroll down to the C:\WLPRSPL\RAW entry for the spool that was built and highlight this. Click OK. Minimize the Windows LPR Spooler. Copy the Windows LPR Spooler icon to the Startup group. Click File/Properties with the Windows LPR Spooler icon highlighted in the Startup group. Check the Run Minimized button. Exit Windows, and when the Save queue changes? button comes up, click Yes. Restart windows and make sure that the spooler starts up. Open the Control Panel and look for a new yellow icon named Set Username If you are running the Novell or other Winsock under Win31, click on this icon and put the username of the person using this computer into the space provided. If you are running WfW, this isn't necessary because Windows will supply the username. If the spooler is not started properly in some installations, there may be a bug. If placing the icon in the StartUp group doesen't actually start the spooler, the program name can be placed in the run= line of win.ini. Try printing a print job from an application such as Notepad. If everything goes properly, clicking on the Queues/Show remote printer status" in the Windows LPR menu should show the print job spooled and printing on the remote printserver. Installation of LPR client on Windows 95/98 The wlprspl program also can be used under Windows 95, but as a 16-bit program, it is far from an optimal implementation on a 32-bit operating system. In addition, Win95 and it's derivatives fundamentally changed from Windows 3.1 in the printing subystem. For these reasons I use a different LPR client program for Win95/98 LPR printing instructions. It is a full 32-bit print program, and it installs as a Windows 32-bit printer port monitor. The program is called ACITS LPR Remote Printing for Windows 95 and it is located at http://shadowland.cc.utexas.edu/acitslpr.htm. ACITS stands for Academic Computing and Instructional Technologies Services. The ACITS LPR client includes software developed by the University of Texas at Austin and its contributors, it was written by Glenn K. Smith, a systems analyst with the Networking Services group at the university. The filename of the archive in the original program was ACITSLPR95.EXE and as of version 1.4 it was free for individuals or organizations to use for their internal printing needs. Since that time, it has gotten so popular that the university has taken over the program, incremented the version number (to get out from under the free license) and is now charging a $35 per copy fee for commercial use for the newer versions. The older free version can still be found on overseas FTP servers, such as http://www.go.dlr.de/fresh/pc/src/winsock/acitslpr95.exe. It is likely that the cost of a shareware/commercial LPR program for Win95 plus the cost of Win95 itself will meet or exceed that of Win2K. As such, users wishing to print via LPR to FreeBSD UNIX systems will probably find it cheaper to simply upgrade to Windows NT Workstation or Win2K. ACITS LPR and Win95 have a few printing idosyncracies. Most Win95 programs, such as Microsoft Word, expect print output to be spooled on the local hard drive and then metered out to a printer that is plugged into the parallel port. Network printing, on the other hand, assumes that print output will go directly from the application to the remote print server. Under Win95, local ports have a setting under Properties, Details, Spool Settings labeled "Print directly to the printer". If this is checked, the application running on the desktop (such as Microsoft Word) will not create a little Printer icon with pages coming out of it or use other means of showing the progress of the job as it is built. This can be very disconcerting to the user of a network printer, so this option should be checked only with printers plugged directly into the parallel port. Worse, if this is checked with ACITS, it can cause the job to abort if the remote print spooler momentarily goes offline. Another local setting also should be changed. Generally, with local ports, Win95 builds the first page in the spooler and then starts printing it while the rest of the pages spool. If ACITS starts printing the first page while the rest of the pages are building, timeouts at the network layer can sometimes cause very large jobs to abort. The entire job should be set to completely spool before the LPR client passes it to the Unix spooler. The problem is partly the result of program design: because ACITS is implemented as a local printer port instead of being embedded into Win95 networking (and available in Network Neighborhood) the program acts like a local printer port in some ways. The LPR program can be set to deselect banner/burst page printing if a PostScript printer that cannot support ASCII is used. The burst pages referred to here are NOT generated by the Windows machine. Use the instructions in Exhibit 8.3 to install LPR client on Win95/98 installation instructions Obtain the ACITSLPR95.EXE file and place it in a temporary directory such as c:\temp1. Close all running programs on the desktop. The computer must be rebooted at completion of installation or the program will not work. Click Start, Run and type in c:\temp1\acitslpr95 then click Yes at the InstallShield prompt. Click Next, then Yes. The program will run through some installation and then presents a Help screen that explains how to configure an LPR port. After the help screen closes, the program asks to reboot the system. Ensure that Yes is checked and click Finish to reboot. After the machine comes back up, install a Printer icon in the Start, Settings, Printers folder if one hasn't been created for the correct model of destination printer. With the Printers folder open, right-click over the printer icon that needs to use the LPR program and click on the Properties tab. Under the Details tab, click the Add Port tab, then click Other. Highlight the ACITS LPR Remote Printing line and click OK. The Add ACITS LPR screen opens. Type in the hostname of the UNIX system that the client spools through— mainprinter.ayedomain.com. Type in the Printer/Queue name and click OK. (Some versions have a "Verify Printer Information" button.) The LPR program then contacts the UNIX host and makes sure that the selected printer is available. If this fails the client machine name is probably not in the /etc/hosts.equiv or etc/hosts.lpd on the FreeBSD printserver. Most sites may simply decide to put a wildcard in hosts.equiv to allow printing, especially if DHCP is used, but many security-conscious sites may stick with individual entries in hosts.lpd. If the printer is PostScript and cannot print ASCII, make sure that the "No banner page control flag" is checked to turn off banner pages. Accessible under Port settings, this flag is overridden if the /etc/printcapfile specifies no banner pages. Review how the "send plain text control flag" is set. With this flag unchecked, the LPR code sent is L, (ie:, print unfiltered) meaning that the if filter gets called with the option. This is equivalent to the local invocation of /usr/bin/lpr -l. With the flag checked, the code is F, (formatted) meaning that the iffilter gets called without the option. This is equivalent to the default invocation /usr/bin/lpr. (This is also an issue under Windows NT, which retypes the print job to text if this flag is checked. Some filters understand the flag, which is used to preserve control characters, so it should generally remain unchecked. Leave the "Send data file before control file" box unchecked. This option is used only in rare mainframe spooling circumstances. Click OK, then click the Spool Settings button at the properties page. Make sure that the "Spool print jobs so program finishes printing faster" box is checked. Make sure that "Start printing after last page is spooled" box is checked. Make sure that "Disable bi-directional support for this printer" is checked, or greyed out. Make sure that the "Spool data format" is set to RAW. Some printer drivers present a choice of EMF or RAW, such as the Generic Text driver, in this case select RAW. Click OK, then OK again to close the Printer Properties. The printer icon now spools through FreeBSD. Installation of LPR client on Windows NT Unlike WfW and Win95 TCP/IP, Windows NT—both server and workstation—includes an LPR client as well as an LPD program that allows incoming print jobs to be printed from LPR clients, such as UNIX systems. To install the LPR client and daemon program under Windows NT 3.51, use the following instructions. The TCP/IP protocol should be installed beforehand and you must be logged in to the NT system as Administrator. This can be done at any time after the NT system is installed, or during OS installation: Double-click on Main, Control Panel, then Network Settings. In the Installed Network Software window, "Microsoft TCP/IP Printing" should be listed as well as "TCP/IP Protocol". Click the Add Software button to get the Add Network Software dialog box Click the down arrow and select TCP/IP Protocol and related components. Click Continue. Check the "TCP/IP Network Printing Support" box and click Continue. LPR printing is now installed. Follow the instructions to reboot to save changes. To install the LPR client and daemon program under Windows NT 4, use the following instructions. The TCP/IP protocol should be installed beforehand and you must be logged in to the NT system as Administrator. This can be done at any time after the NT system is installed, or during OS installation: Click on Start, Settings, Control Panel, and double-click on Network to open it up. Click on the Services tab. Microsoft TCP/IP Printing should be listed. If not, continue steps 3 - 4. Click Add, then select Microsoft TCP/IP Printing and click OK. Click Close. Follow instructions to reboot to save changes. Any NT Service Packs that were previously installed must be reapplied after these operations. Once LPR printing has been installed, the Printer icon or icons must be created on the NT system so that applications can print. Since this printer driver does all job formatting before passing the printing to the FreeBSD printserver, the print queues specified should be raw queues on the FreeBSD system, which don't do any job formatting. To install the printer icon in Print Manager and set it to send print jobs to the FreeBSD UNIX system, use the following instructions under NT 3.51. You must be logged in to the NT system as Administrator. This can be done at any time after the NT system is installed, or during OS installation. Click on Main, and open it. Then click on Print Manager to open it. Click on Printer, Create Printer. Select the appropriate printer driver. Click the down arrow under Print To and select Other. In the Available Print Monitors window select LPR port and click OK. Enter the hostname of the FreeBSD printserver, and the name of the printer queue and click OK Click OK to close the Create Printer window. The Printer icon is created. To install the printer icon in Print Manager and set it to send print jobs to the FreeBSD UNIX system, use the following instructions under NT 4. You must be logged in to the NT system as Administrator. This can be done at any time after the NT system is installed, or during OS installation: Click Start, Settings, Printers to open the printer folder. Double-click Add Printer to start the wizard. 3) Select the My Computer radio button, not the Network Print Server button and click Next. (The printer is a networked printer, it is managed on the local NT system. Microsoft used confusing terminology here. Click Add Port and select LPR Port, then click New Port. Enter the hostname and print queue for the FreeBSD printserver and click OK. Click Next and select the correct printer driver. Continue until the printer is set up. The LPR client in Windows NT allows DOS print jobs originating in DOS boxes to be routed to the central UNIX print spooler. This is an advantage over the Win95 and WfW LPR programs. Windows NT Registry Changes Using the LPR daemon program under Windows NT presents one problem. If the NT server is used as an LPR/LPD "relay", for example, to pass jobs from clients to LPR print queues on a UNIX system, to pass jobs from LPR programs on UNIX terminating at NT print queues, or to pass jobs from Appletalk clients to LPR printers, NT retypes the job if the type code is set to P (text). This can wreak havoc on PostScript files printed through HP LaserJet printers with internal MIO cards in them, if the job originates from the /usr/bin/lpr program under UNIX, which assigns a P type code. The printserver card treats PostScript jobs as text, and instead of the print job, the raw PostScript codes print. This problem often manifests in the following way: /usr/bin/lpr is used to print a PostScript file from UNIX directly to the remote printer printserver, which works fine, but spooling it through NT causes problems. A registry change that can override the NT Server formatting behavior is detailed in Microsoft Knowledge Base article ID Q150930. With Windows NT 3.51, and 4.0 up to service pack 1 the change is global. Starting with NT 4.0 Service pack 2 the change can be applied to specific print queues, (see Knowledge Base article ID Q168457). Under Windows NT 4.0, the change is: Run Registry Editor (REGEDT32.EXE) From the HKEY_LOCAL_MACHINE subtree, go to the following key: \SYSTEM\CurrentControlSet\Services\LPDSVC\Parameters On the Edit menu, click Add Value. Add the following: Value Name: SimulatePassThrough Data Type: REG_DWORD Data 1 The default value is 0, which informs LPD to assign datatypes according to the control commands. Under Windows NT 3.51, the change is: Run Registry Editor (REGEDT32.EXE) From the HKEY_LOCAL_MACHINE subtree, go to the following key: \SYSTEM\CurrentControlSet\Services\LPDSVC\Parameters On the Edit menu, click Add Value. Add the following: Value Name: SimulatePassThrough Data Type: REG_DWORD Data 1 The default value is 0, which informs LPD to assign datatypes according to the control commands. Create an LPD key at the same level as the LPDSVC key. Click the LPDSVC Key, click Save Key from the Registry menu, and then save the file as LPDSVC.KEY Click the LPD key created in step 5. Click Restore on the Registry menu, click the file created in step 6, and then click OK. A warning message appears. Click OK and then quit the Registry Editor. At a command prompt window, type: net stop lpdsvc net start lpdsvc Printing Postscript and DOS command files One problem with printing under Win31 and Win95 with the LPR methods discussed is the lack of a raw LPT1: device. This is annoying to the administrator who wants to print an occasional text file, such as a file full of printer control codes, without their being intercepted by the Windows printer driver. Of course this is also an issue with DOS programs, but a commercial site that runs significant DOS software and wants to print directly to UNIX with LPR really only has one option—to use a commercial TCP/IP stack containing a DOS LPR program. Normally, under Windows printing, virtually all graphical programs print through the Windows printer driver. This is true even of basic programs such as Notepad. For example, an administrator may have a DOS batch file named filename.txtcontaining the following line: echo \033&k2G > lpt1: This batch file switches a HP LasterJet from CR-LF, MS-DOS textfile printing into Newline termination UNIX textfile printing. Otherwise, raw text printed from UNIX on the HP prints with a stairstep effect. If the administrator opens this file with Notepad and prints it using a regular printer driver, such as an Epson LQ, the Windows printer driver encapsulates this print output into a series of printer-specific control codes that do things such as initialize the printer, install fonts, and so on. The printer won't interpret this output as control code input. Usually, if the printer is locally attached, the user can force a "raw text print" of the file by opening a DOS window and running: copy filename.txt lpt1: /b Since the LPR client program doesn't provide a DOS driver, it cannot reroute input from the LPT1: device ports. The solution is to use the Generic / Text Only printer driver in conjunction with Wordpad (under Win95); under Win31 use a different text editor. The Notepad editor supplied with Windows is unsuitable for this - it "helpfully" inserts a 1 inch margin of spaces around all printed output, as well as the filename title. Wordpad supplied with Win95, can be set to use margins of zero, and inserts no additions into the printed output. Also, make sure that banner pages are turned off, and the print type is set to raw. Checking PostScript Printer capabilities Following is a PostScript command file that can be used to get a PostScript printer to output a number of useful pieces of information that are needed to set up a printer icon under Windows properly. It was printed from Wordpad, in Win95, through the Generic / Text Only printer driver with the following instructions: Start, Run, type in Wordpad and press Enter. File, Open testps.txt File, Page Setup, Printer, select Generic / Text Only, click Properties Click Device Options, select TTY custom, click OK. Click OK, then set all four margins to 0; click OK. Click File, Print, OK. This could also have been printed with /usr/bin/lpr on a UNIX command prompt. The file prints Test Page and some printer statistics below that, as follows. % filename: testps.txt % purpose: to verify proper host connection and function of PostScript % printers. /buf 10 string def /CM { save statusdict/product get (Postscript) anchorsearch exch pop {length 0 eq {1}{2}ifelse } {2}ifelse exch restore }bind def /isCM { CM 1 ge }bind def /Times-BoldItalic findfont 75 scalefont setfont 150 500 moveto (Test Page) false charpath isCM{gsave 0.0 1.0 1.0 0.0 setcmykcolor fill grestore}if 2 setlinewidth stroke /Times-Roman findfont 10 scalefont setfont 150 400 moveto (Your PostScript printer is properly connected and operational.)show 150 380 moveto (The border around the page indicates your printer's printable region.)show { vmreclaim } stopped pop vmstatus exch sub exch pop 150 360 moveto (Max Available Printer Virtual Memory (KB):)show 150 340 moveto dup 1024 div truncate buf cvs show 150 320 moveto (Calculated memory size used for PostScript printer icon properties:) show 150 300 moveto 0.85 mul 1024 div truncate buf cvs show 150 280 moveto (Printer Model: )show statusdict begin product show end 150 260 moveto (PostScript Level: )show /languagelevel where { languagelevel 3 string cvs show pop } {(1) show } ifelse 150 240 moveto (PostScript Version: )show statusdict begin version show (.)show revision 40 string cvs show end clippath stroke showpage Setting up LPR/LPD on FreeBSD When a FreeBSD system is booted, it starts the LPD spooler control daemon program if the /etc/rc.conf file has lpd_enable="YES" set. If this is not set, attempts to print through and from the FreeBSD system will fail with an lpr: connect: No such file or directory error message. The LPD program manages all incoming print jobs, whether they come in from the network, or from local users on the UNIX system. It transfers print jobs to all locally attached parallel or serial printers, as well as defined remote printers. Several programs also are used to manipulate jobs in the print spools that LPD manages, as well as the user programs to submit them from the UNIX command prompt. All of these programs use the /etc/printcapfile, which is the master control file for the printing system. Back when printing was mostly text, it was common to place printers on a serial connection that stretched for long distances. Often, 9600bps was used because it could work reliably up to a block away, which allowed printers to be located almost anywhere on an office high-rise floor. Modern office print jobs, on the other hand, are generally graphics-laden and tend to be rather large. These jobs would take hours to transfer over a slower 9600bps serial printer connection. Today, most printers that are not connected to a remote hardware print server box are directly connected to the server using parallel cables. All of the examples shown here are direct connections that are parallel connections. The printcap configuration file, like most UNIX configuration files, indicates comment lines starting with a hash character. Lines without a hash character are meant to be part of a printer queue description line. Each printer queue description line starts with a symbolic name, and ends with a newline. Since the description lines are often quite long, they are often written to span multiple lines by escaping intermediate newlines with the backslash (\) character. The /etc/printcapfile, as supplied, defines a single printer queue, lp. The lpqueue is the default queue. Most UNIX-supplied printing utilities send print output to this queue if no printer is specified by the user. It should be set to point to the most popular print queue with local UNIX print users, (i.e.: users that have shell accounts). The layout of /etc/printcapis covered in the manual page, which is reached by running the man printcap command. The stock /etc/printcap file at the line defining the spool lpshows: # lp|local line printer:\ :lp=/dev/lpt0:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs: # In this example the first line defines the names by which the printer is known, and ends with an escaped newline. The next line defines the physical device, the PC parallel port, by /dev/lpt0, and the directory in which the spool files are stored at /var/spool/output/lpd, and the error log file. Note that this particular error log file will not show all LPD errors, such as bad job submittals, it usually shows only the errors that originate within the printing system itself. In general, the administrator creates two print queues for every printer that is connected to the FreeBSD machine. The first queue entry contains whatever additional capabilities UNIX shell users on the server require. The second is a raw queue that performs no print processing on the incoming print job. This queue is used by remote clients, such as Windows clients, that format their own jobs. If the administrator is setting up the printer to allow incoming LPR jobs from network clients, such as other Windows or UNIX systems, those systems must be listed in /etc/hosts.lpd. Creating the spools Building new print spools is merely a matter of making an entry in the /etc/printcap file, creating the spool directories, and setting the correct permissions on them. For example, the following additional line defines a PostScript printer named NEC (in addition to the lp definition): # lp|local line printer:\ :lp=/dev/lpt0:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs: NEC|NEC Silentwriter 95 Postscript printer:\ :lp=/dev/lpt0:sd=/var/spool/output/NEC:lf=/var/log/lpd-errs: # Because UNIX is case sensitive, NEC is different from nec in both the name of the printer and the name of the Spool directory. With the print spooler LPD, the Spool directories must be different from each other, or the spooler gets confused and doesen't print. After the /etc/printcapis modified, the root user must create the /var/spool/output/NEC directory and assign ownership of it to the bin user, assign group ownership to daemon, and set permissions with the following commands: &prompt.user; su root &prompt.root; cd /var/spool/output &prompt.root; mkdir NEC &prompt.root; chown bin NEC &prompt.root; chgrp daemon NEC &prompt.root; chmod 755 NEC Additional spool capabilities Because modern print jobs (especially PostScript) can sometimes reach hundreds of megabytes, the sd capability entry in the /etc/printcap file should always point to a Spool directory on a filesystem that has enough space. The /var directory on a default FreeBSD installation is generally set to a fairly small amount, which can easily overflow the spool. There are four ways to handle this problem: During FreeBSD installation, if the administrator knows a lot of print jobs are going to go through the spooler, /varshould be set to a large amount of free space. Modify the sd capability in the /etc/printcap file to point to a spool directory in a different, larger filesystem, such as /usr/spool. Use soft links to point the /var/spool/output directory to directories on a larger filesystem. Don't define a /var directory at all during FreeBSD installation; this would make the installer link /var to /usr/var. In addition to spools, the following other capabilities are usually placed in a production /etc/printcapfile. The entry fo prints a form feed when the printer is opened. It is handy for HPPCL (HP LaserJets) or other non-PostScript printers that are located behind electronic print sharing devices. It can also be used for printers that accept input from multiple connections, such as a parallel port, serial port, and localtalk port. An example is an HP LaserJet with an MIO card in it plugged into both Ethernet and LocalTalk networks. It will clear any garbage out of the printer before the job is processed. The entry mx defines the maximum size of a print job, which is a must for modern print jobs that frequently grow far past the default print size of a megabyte. The original intent of this capability was to prevent errant programs from stuffing the spool with jobs so large that they would use up all paper in a printer.. Graphics-heavy print jobs have made it impossible to depend on this kind of space limitation, so mx is usually set to zero, which turns it off. The entry sh suppresses printing of banner pages in case the printer cannot handle ASCII and the client mistakenly requests them. The entry ct denotes a TCP Connection timeout. This is useful if the remote print server doesn't close the connection properly. FreeBSD 2.2.5 contains a bug in the LPD system - as a workaround the ct capability needs to be set very large, such as 3600, or the appropriate patch installed and LPD recompiled. More recent versions of FreeBSD do not have this bug. Printing to hardware print server boxes or remote print servers. Hardware print server boxes, such as the HP JetDirect internal and external cards, need some additional capabilities defined in the /etc/printcap entry; rp, for remote print spool, and rmfor remote machine name. The rm capability is simply the DNS or /etc/hosts name of the IP number associated with the remote printserver device. Obviously, print server devices, such as the HP JetDirect, must not use a dynamic TCP/IP network numbering assignment. If they get their numbering via DHCP, the IP number should be assigned from the static pool; it should always be the same IP number. Determining the name used for rp, on the other hand, can be rather difficult. Here are some common names: Windows NT Server: Printer name of the printer icon created in Print Manager FreeBSD: Print queue name defined in /etc/printcap HP JetDirect: Either the name TEXT or the name RAW. TEXT automatically converts incoming UNIX newline text to DOS-like CR/LF text that the printer can print. RAW should be used for PostScript, and HPPCL printing. HP JetDirect EX +3: External, 3 port version of the JetDirect. Use RAW1, RAW2, RAW3, TEXT1, TEXT2, or TEXT3 depending on the port desired. Intel NetPort: Either use TEXT for UNIX text conversion printing or use PASSTHRU for normal printing. DPI: Use PORT1 or PORT2 depending on which port the printer is plugged into. For other manufacturer's print servers refer to the manuals supplied with those devices. The following is an example printcap that redefines the default lp print queue to send print jobs to the first parallel port on a remote HP LaserJet plugged into a JetDirect EX +3 named floor2hp4.biggy.com. # lp|local line printer:\ :rm=floor2hp4.biggy.com:rp=RAW1:\ :sd=/var/spool/output/lpd:\ :lf=/var/log/lpd-errs: # The rp capability must be defined or the job goes to the default print queue on the remote host. If the remote device does not have a single print queue, such as another UNIX system, this causes problems. For example, if the remote device was a JetDirect EX + 3 and rp was omitted, all queues defined would print out of the first parallel port. Filters The last two important printcap capabilities concern print filters, if (input filter) and of (output filter) If defined, incoming print jobs are run through the filters that these entries point to for further processing. Filters are the reason that the UNIX print spooling system is so much more powerful than any other commercial server operating system. Under FreeBSD, incoming print jobs are acted on by any filters specified in the /etc/printcap no matter where they originate. Incoming print jobs from remote Windows, Mac, NT, OS/2 or other clients can be intercepted and manipulated by any program specified as a filter. Want a PostScript Printer? There's a filter that adds PostScript capability to a non-PostScript printer. Want to make a cheap Epson MX 80 dot-matrix emulate an expensive Okidata Microline dot-matrix for some archaic mainframe application? Write a filter that will rewrite the print codes to do it. Want custom-built banner pages? Use a filter. Many UNIX /etc/printcap filters on many Internet sites can do a variety of interesting and unique things. Someone may have already written a filter that does what you want! Types of filters Three types of filters can be defined in the /etc/printcap file. In this book all filter examples are for Input filters. Input Filters Input filters are specified by the if capability. Every job that comes into the spool is acted on by any filter specified in the if entry for that spool. Virtually all filters that an administrator would use are specified here. These filters can be either shell scripts, or compiled programs. Fixed Filters Fixed filters are specified by separate capabilities, such as cf, df, and gf. Mostly, these exist for historical reasons. Originally, the idea of LPD was that incoming jobs would be submitted with the type fields set to trigger whatever filter was desired. However, type codes are confusing and annoying to the user, who has to remember which option is needed to trigger which type. It is much easier to set up multiple queues with different names, and this is what most sites do these days. For example, originally a DVI fixed filter might be specified in a spool for lp, triggered by the option passed to lpr. Jobs without this option aren't acted on by the DVI filter. However, the same thing can be done by creating a queue named lp that doesn't have a DVI filter, and a queue named lpdvi which has the DVI filter specified in the if capability. Users just need to remember which queue to print to, instead of what option needed for this or that program. Output Filters These are specified by the ofcapability. Output filters are much more complicated than input filters and are hardly ever used in normal circumstances. They also generally require a compiled program somewhere, either directly specified or wrapped in a shell script, since they have to do their own signal-handling. Printing raw Unix text with a filter One of the first thing that a new Unix user will discover when plugging a standard LaserJet or impact printer into a UNIX system is the stairstep problem. The symptom is that the user dumps text to the printer, either through LPR or redirection (by catting it to the parallel device) and instead of receiving the expected Courier 10-point printout, gets a page with a single line of text, or two lines of text "stairstepped", text and nothing else. The problem is rooted in how printers and UNIX handle textfiles internally. Printers by and large follow the "MS-DOS Textfile" convention of requiring a carriage return, then a linefeed, at the end of every text line. This is a holdover from the early days when printers were mechanical devices, and the print head needed to return and the platen to advance to start a new line. UNIX uses only the linefeed character to terminate a text line. So, simply dumping raw text out the parallel port works on MS-DOS, but not on UNIX. If the printer is a PostScript printer, and doesn't support standard ASCII, then dumping UNIX text to it doesn't work. But then, neither would dumping MS-DOS text to it. (Raw text printing on PostScript printers is discussed later in this chapter) Note also that if the printer is connected over the network to an HP JetDirect hardware print server, internal or external, the TEXT queue on the hardware print automatically adds the extra Carriage Return character to the end of a text line. If the printer is the garden-variety HP LaserJet, DeskJet, or an impact printer, and under DOS the administrator is used to printing raw text from the command line for directory listings, there are two ways to fix stairstep. The first is to send a command to the printer to make it print in "unix textfile" mode, which makes the printer supply it's own carriage return. This solution is ugly in a printer environment with UNIX and Windows machines attempting to share use of the same printer. Switching the printer to work with Unix disrupts DOS/Windows raw text printouts. The better solution is to use a simple filter that converts incoming text from UNIX style to DOS style. The following filter posted on questions@freebsd.org and the sample /etc/printcap entry can be used to do this: #!/bin/sh # /usr/local/libexec/crlfilter # # simple parlor trick to add CR to LF for printer # Every line of standard input is printed with CRLF # attached. # awk '{printf "%s\r\n", $0}' - An alternative filter posted using sed could be written as: #!/bin/sh # /usr/local/libexec/crlfilter # # Add CR to LF for printer # Every line of standard input is printed with CRLF # attached. # # Note, the ^M is a *real* ^M (^V^M if your typing in vi) # sed 's/$/^M/' - Here is an example of a filter that triggers the printers automatic LF-to-CR/LF converter (this option is only useful on HP LaserJets that support this command): #!/bin/sh # Simply copies stdin to stdout. Ignores all filter # arguments. # Tells printer to treat LF as CR+LF. Writes a form feed # character after printing job. printf "\033&k2G" && cat && printf "\f" && exit 0 exit 2 The printcap file used to trigger the filter is: #/etc/printcap # The trailer (tr) is used when the queue empties. I found that the # form feed (\f) was basically required for the HP to print properly. # Banners also need to be shut off. # lp|local line printer:\ :lp=/dev/lpt0:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs: :if=/usr/local/libexec/crlfilter:sh:tr=\f:mx#0: # The pr filter Although most filters are built by scripts or programs and are added to the UNIX machine by the administrator, there is one filter that is supplied with the FreeBSD operating system is very useful for raw text files: the prfilter. It is most commonly used when printing from the UNIX command shell. The pr filter paginates and applies headers and footers to ASCII text files. It is automatically invoked with the option used with the lpr program at the UNIX command prompt. The pr filter is special - it runs in addition to any input filters specified for the print queue in /etc/printcap, if the user sets the option for a print job. This allows headers and pagination to be applied in addition to any special conversion, such as CR to LF that a specified input filter may apply. Printing PostScript banner pages with a Filter. Unfortunately, the canned banner page supplied in the LPD program prints only on a text-compatible printer. If the attached printer understands only PostScript and the administrator wants to print banner pages, it is possible to install a filterinto the /etc/printcapfile to do this. The following filter is taken from the FreeBSD Handbook. I've slightly changed it's invocation for a couple of reasons. First, some PostScript printers have difficulty when two print files are sent within the same print job or they lack the trailing Control-D. Second is that the handbook invocation uses the LPRPS program, which requires a serial connection to the printer. The following filter shows another trick: calling LPR from within a filter program to spin off another print job. Unfortunately, the problem with using this trick is that the banner page always gets printed after the job. This is because the incoming job spools first, and then FreeBSD runs the filter against it, so the banner page generated by the filter always spools behind the existing job. There are two scripts, both should be put in the /usr/local/libexec directory, and the modes set to executable. The printcap also must be modified to create the nonbanner and banner versions of the print queue. Following the scripts is the /etc/printcap file showing how they are called. Notice that the sh parameter is turned on since the actual printed banner is being generated on the fly by the filter: #!/bin/sh # Filename /usr/local/libexec/psbanner # parameter spacing comes from if= filter call template of: # if -c -w -l -i -n login -h host # parsing trickiness is to allow for the presence or absence of -c # sleep is in there for ickiness of some PostScript printers for dummy do case "$1" in -n) alogname="$2" ;; -h) ahostname="$2" ;; esac shift done /usr/local/libexec/make-ps-header $alogname $ahostname "PostScript" | \ lpr -P lpnobanner sleep 10 cat && exit 0 Here is the make-ps-headerlisting. #!/bin/sh # Filename /usr/local/libexec/make-ps-header # # These are PostScript units (72 to the inch). Modify for A4 or # whatever size paper you are using: # page_width=612 page_height=792 border=72 # # Save these, mostly for readability in the PostScript, below. # user=$1 host=$2 job=$3 date=`date` # # Send the PostScript code to stdout. # exec cat <<EOF %!PS % % Make sure we do not interfere with user's job that will follow % % % Make a thick, unpleasant border around the edge of the paper. % $border $border moveto $page_width $border 2 mul sub 0 rlineto 0 $page_height $border 2 mul sub rlineto currentscreen 3 -1 roll pop 100 3 1 roll setscreen $border 2 mul $page_width sub 0 rlineto closepath 0.8 setgray 10 setlinewidth stroke 0 setgray % % Display user's login name, nice and large and prominent % /Helvetica-Bold findfont 64 scalefont setfont $page_width ($user) stringwidth pop sub 2 div $page_height 200 sub moveto ($user) show % % Now show the boring particulars % /Helvetica findfont 14 scalefont setfont /y 200 def [ (Job:) (Host:) (Date:) ] { 200 y moveto show /y y 18 sub def } forall /Helvetica-Bold findfont 14 scalefont setfont /y 200 def [ ($job) ($host) ($date) ] { 270 y moveto show /y y 18 sub def } forall % % That is it % showpage Here is the /etc/printcap file. # lp|local line printer, PostScript, banner:\ :lp=/dev/lpt0:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs: :if=/usr/local/libexec/psbanner:sh:mx#0: lpnobanner|local line printer, PostScript, no banner:\ :lp=/dev/lpt0:sd=/var/spool/output/lpd-noban:\ :lf=/var/log/lpd-errs:sh:mx#0: # Printer Accounting The FreeBSD print spooler can manage accounting statistics for printer usage. The spooler counts each page printed and generates totals for each user. In this manner departments or individuals can be charged money for their use of the printer. In the academic world, such as student computer labs, accounting is very political. Many schemes have been developed to attempt to gather statistics to charge people (generally students) for printing. Administrators in this environment who deal with printers can have almost as many accounting problems as printer problems. In the corporate environment, on the other hand, accounting is not as important. I strongly recommend against any corporation attempting to implement printer accounting on shared printers for a number of reasons: The entire UNIX accounting system is based on ASCII printouts. It is easy to count the number of ASCII pages, form feeds, or text lines in a print job. In corporations, however, PostScript and HPPCL are generally the order of the day. It is almost impossible to figure out by examining the datastream how many pages it will occupy, and even if this could be done accurately, it wastes significant computational resources. It is possible to get some PostScript printers to count pages, but doing so requires a bidirectional connection to the printer and additional programming on the UNIX system. This task is beyond the scope of this book. Banner pages aren't included in UNIX printer accounting counts. Therefore, someone submitting 20 two-page jobs uses much more paper than does someone submitting one 40 page job, yet both are charged the same amount. The username of the submitter can be easily forged, if the job is remotely submitted over the network from a client. (practically all jobs in a Windows client printing environment are remotely submitted) Although some LPR clients can be set to authenticate, and the rs capability can be set to enforce authentication, not all can, especially Windows LPR clients. It is more difficult for a submitter to hide the IP number or machine name of the remote client, but in a Windows environment there is no guarantee that someone was sitting at a particular desktop machine when the job was submitted. A business generates no revenue by monitoring printer usage. In the academic community, however, when a student lab charges for printouts the lab is actually extracting money from an entity (the student) that is separate from the lab. Within a corporation, the concept of department A getting revenue from user B is pointless and doesn't generate a net gain for the corporation as a whole. For my printer administration, I have found that I can save more money on printing costs by purchasing supplies wisely than by attempting to discourage printing through "chargebacks". What is the sense of being miserly with printing while spending double on toner cartridges because no one is willing to comparison shop, or signing a "lease" agreement that isn't beneficial for the printer? When you get down to it, corporate users don't care much for print sharing anyway, and they generally only agree to it because the administrator can buy a far bigger, faster, and fancier printer than they can requisition. Worse yet, if usage on a shared printer is charged, it encourages employees to look for other places to print. Inevitably, people run out buy cheap inkjet printers for their own use, and the business ends up spending more on paper and supplies for many poor-quality small printers, than it would for a few decent big ones. Moreover, the inferior output of these printers makes the organization as a whole look bad. The corporate spirit should be one of teamwork, not bickering. The surest way to kill a network in a corporation is to set up a situation that puts the administrator into the policeman position or pits one department against another. The only justification I've ever seen for running accounting on corporate printers is using the accounting system to automate reminders to the administrator to replace paper, or toner. Aside from this use, a corporation that implements accounting as a way of encouraging employees not to waste paper ends up defeating the purpose of turning on accounting. Microsoft Networking Client printing with Samba Although LPR is a time-tested and truly cross-platform printing solution, sites with a majority of Windows clients running Microsoft Networking have an alternate printing mechanism—Samba. Samba can provide print services to clients running SMB-compatible network clients. With a running Samba installation, the administrator may "share out" printers as well as filesystem directories from the FreeBSD system. Printers accessed with Samba must be defined both in the /etc/printcap file and the /usr/local/etc/smb.conf file. If the individual printers are defined in the smb.conf file with the printer driver= statement set to the exact model name of the printer, the "Auto printer driver install" feature of Windows NT and Win95/98 is activated. This automatically loads the correct printer driver if the user clicks on the print queue in Network Neighborhood under Windows 95 or NT 4.0 The restriction, of course, is that the printer model must be in the Windows client driver database. The smb.conf file also defines the print command used to pass jobs to the UNIX print spool. It is a good idea to redefine this via the print command option to lpr -s -P %p %s; rm %s. This turns on soft linking, so that large print jobs don't get truncated. In operation, the SMB-networking client builds the print job on itself and then transfers the entire job over the network to the Samba server. On the server, Samba has it's own temporary print spool directory to which the job is copied. Once the job has been completely received, it is then passed to the UNIX print spooler.
Microsoft Networking Client printing with Samba ,---------. | ======= | FreeBSD Server | ======= | +---------------------+ ,-----. +-----------+ | +---------------+ | | | | Printer [ ]------------[ ] | Samba | | |_____| +-----------+ Parallel | | Software | [ ]------_________ Cable | +---------------+ | / ::::::: \ | | `---------' | +---------------+ | Network PC | | Print | | | | Software | | | +---------------+ | +---------------------+ The Samba software and the print software run on the same host. Samba receives the print job, then hands it to the print spooler.
Client access issues Because a Windows client formats print jobs before sending them to the server, the administrator may want to hide some of the specialty print queues on the server. For example, the queue that converts LF to CRLF for UNIX text printouts would probably not be shared out. To make such queues invisible, the browseable=no option can be turned on in the smb.conf file. Also, the load printers option must be set to no to allow individual printer definitions. In general, the only print queues that should be visible through Samba are the "raw" print queues that are set up by the administrator to allow incoming preformatted print jobs. Windows clients that print to Samba print queues on the UNIX system can view and cancel print jobs in the print queue. They cannot pause them, however, which is a difference between Novell and Windows NT Server print queues. They also cannot prioritize print jobs from the print queue window, although the administrator can reprioritize print jobs that are in the queue from a command shell on the FreeBSD server. Printer entries in configuration files Following are listings of sample /etc/printcap file, and smb.conf files used on the system to provide print services. An explanation of the interaction of these files follows. <filename>/etc/printcap</filename> # # # The printer in lpt0 is a Postscript printer. The nec-crlf entry # is for testing the printer when it is switched into HP LaserJet III # mode. # lp|local line printer:\ :lp=/dev/lpt0:sd=/var/spool/output/lpd:\ :lf=/var/log/lpd-errs:sh:mx#0: # nec-crlf|NEC Silentwriter 95 in ASCII mode with Unix text filter:\ :lp=/dev/lpt0:sd=/usr/lpdspool/nec-crlf:\ :lf=/var/log/lpd-errs:sh:mx#0:\ :if=/usr/local/libexec/crlfilter:tr=\f: # nec-raw|NEC Silentwriter 95 used for PostScript passthrough printing:\ :lp=/dev/lpt0:sd=/usr/lpdspool/nec-raw:\ :lf=/var/log/lpd-errs:sh:mx#0: # nec-ps-banner|NEC Silentwriter 95 with Postscript banner page created:\ :lp=/dev/lpt0:sd=/usr/lpdspool/nec-ps-banner:\ :lf=/var/log/lpd-errs:sh:mx#0:if=/usr/local/libexec/psbanner: # # <filename>/usr/local/etc/smb.conf</filename> [global] comment = FreeBSD - Samba %v log file = /var/log/samba.log dont descend = /dev,/proc,/root,/stand print command = lpr -s -P %p %s; rm %s interfaces = X.X.X.X (the system IP number goes here) printing = bsd map archive = no status = yes public = yes read only = no preserve case = yes strip dot = yes security = share guest ok = no password level = 1 dead time = 15 domain master = yes workgroup = WORKGROUP [homes] browseable = no comment = User Home Directory create mode = 0775 public = no [printers] path = /var/spool comment = Printers create mode = 0700 browseable = no read only = yes public = no [lp] printable = yes browseable = no [nec-raw] comment = Main Postscript printer driver for Windows clients printer driver = NEC SilentWriter 95 printable = yes browseable = yes [wwwroot] path = /usr/local/www read only = no create mode = 0775 comment = Internal Web Server Browsing output Following is the output of a net view command executed at a DOS prompt under Windows 95: Shared resources at \\SERVER Sharename Type Comment -------------------------------------------------------------------- nec-crlf Print NEC Silentwriter 95 in ASCII mode nec-raw Print Main Postscript printer driver tedm Disk User Home Directory wwwroot Disk Internal Web Server The command was completed successfully. In the /etc/printcap file four print queues are defined, all tied to the printer plugged into the parallel port on the FreeBSD server. The first is lp, the generic local line printer. Since this print queue generally has a filter placed on it to format jobs from the UNIX print queue properly, it should not be visible on the SMB network. (ie: visible in Network Neighborhood) The second queue, nec-crlf, has a filter that converts UNIX text to text that prints without stairstepping, so it also should be hidden from the SMB network. The third, nec-raw, should be visible on the network because this is the spool that the Windows clients use. The last queue, nec-ps-banner, is another specialty queue for UNIX local printing and thus should not be visible. When the smb.conf file is parsed, the default entry [printers] is first read and used as a set of defaults for printers that are going to be shared out. Next, the /etc/printcap file is read to get a list of all printers on the server. Last, each printer is checked for a service name in the smb.conffile that contains settings that override the set of defaults. In the listing of what resources are visible on the network, both nec-crlf and nec-raw print queues are visible, and lpand nec-ps-banner is not. lp is not visible because there is a specific entry, [lp] in the smb.conf file that blocks it. nec-ps-banner doesen't have such an entry, but because the print queue name is not a legal length for a SMB name, it isn't shared out either. The nec-crlf printer is visible so as to illustrate another point - comments. If a print queue has no entry in the smb.conf file and is built by scanning the /etc/printcap file and using the [printers] defaults, the comment is taken from the /etc/printcap file next to the queue definition name. Otherwise, if an entry is made for the printer in the smb.conf file the comment is taken from the entry in smb.conf. Printing between NT Server/NetWare and FreeBSD. Up to this point in the chapter, our main concern has been FreeBSD and Windows NT printing interoperability with NT as a print client passing jobs to the FreeBSD system. What happens if the situation is reversed and the FreeBSD system is itself a printing client of another LPD server? This situation can arise in a mixed UNIX/Netware or UNIX/NT environment. The administrator may elect to forgo the use of Samba, and use an NT server to provide print services. Alternatively, the administrator may have existing DOS Novell IPX clients that they don't want to change, printing to an existing IPX Novell NetWare server. Many of the earlier hardware print servers, such as the Intel NetPort 1 and NetPort 2 were IPX only. A site with a large number of these hardware servers may wish to move the clients to TCP/IP, but leave the existing IPX-based printing network intact. With NetWare it is possible to load an LPD NetWare loadable module (NLM) on the NetWare server that takes incoming LPR print jobs and prints them on IPX print queues. Later versions of NetWare may include this NLM, it was an extra cost add-on with NetWare 3.X With Windows NT Server, loading the TCP/IP LPR printing support also loads the LPD print server on NT. By using LPR client programs on UNIX, it is possible to submit, view status, and remove jobs remotely from an NT server that has LPR installed as a port for it's printers. Following is a sample /etc/printcapfile entry that defines a print queue named tankon the FreeBSD system pointed to an NT LPD server queue named sherman on a NT Server named big.army.mil in the DNS. This uses the rm printcap capability. Unlike the earlier examples, the output print jobs are sent out not by the PC parallel port but over the network to the NT server. # tank|sample remote printer:\ :rm=big.army.mil:rp=sherman:sd=/var/spool/output/lphost:\ :lf=/var/log/lpd-errs: # When using an NT server as an LPD server it may be necessary to make the NT registry changes mentioned under Windows NT Registry Changes, earlier in the chapter. Printing from Unix Two commands used at the FreeBSD command prompt are intended as general-purpose print commands: lp and lpr.. <command>lp</command> The lp command is simply a front end command that calls the lpr command with appropriate options. It's main use is to allow the running of precompiled binary programs and scripts that assume that the lp command is the official printing command. <command>lpr</command> The lpr command is the main command that is used to print files from the command prompts under the FreeBSD operating system. It is frequently spawned off as a child program, or used in pipes. For example, when the Netscape web browser's Print button is clicked, Netscape may create the PostScript output, but the output goes through the lpr command. The lpr command, like many UNIX command-line printing programs, assumes that the default print queue name is lp. When the FreeBSD machine is set up, the administrator usually sets the lp queue to print through a filter that allows raw UNIX text sent to it to print properly. For example, if an HP LaserJet printer that doesn't have Postscript is connected to the server, the lpqueue specifies in the /etc/printcap file the CRLF filter listed earlier. On the other hand, if an Apple Laserwriter that doesn't support ASCII is connected to the server, the a2psfilter would be specified in the /etc/printcap for the lp queue. When printing raw text files usually the option is specified to lpr. When printing preformatted files, such as PostScript files, the option is used, which selects whatever queue is used to handle these job types. Managing the Unix Print Queue Once the print jobs coming in from clients are received on the FreeBSD system and placed in the print spool, they are metered out at a slower rate to the various printers. If traffic activity is light, and few print jobs get sent through, the administrator can probably ignore the print queue as long as it continues to work. However, a busy network printer running at an optimal rate of speed usually has a backlog of unprinted jobs in the queue waiting for print time. To keep all users happy and to provide for the occasional rush print job, the Unix LPD/LPR printing system has several administration commands which are described here. Viewing the queue On busy printers, and to troubleshoot stopped printers, users sometimes need to view the print jobs in the queue. Administrators also need to view the queue to see what jobs may need to be expedited. This can be done from the workstation that remotely submitted the job if the LPR client has the ability to do this. The Windows 3.1 LPR client discussed earlier has this capability. Unfortunately, many LPR clients don't, which means that the administrator must Telnet into the UNIX machine that the print queues are on and view them there. The UNIX shell command used to view the queue is the lpq command It is frequently run as lpq -a which shows jobs in all queues. The following is a sample output of the command: &prompt.root; lpq -a nec-raw: Rank Owner Job Files Total Size 1st tedm 19 C:/WLPRSPL/SPOOL/~LP00018.TMP 105221 bytes 2nd tedm 20 C:/WLPRSPL/SPOOL/~LP00019.TMP 13488 bytes 3rd root 3 hosts 1220 bytes 4th tedm 1 Printer Test Page 765 bytes 5th tedm 2 Microsoft Word - CHAPTE10.DOC 15411 bytes The first two jobs and the last two jobs came from remote clients, the third came from the command prompt. Removing print jobs Deleting unwanted print jobs that haven't yet printed from the queue can be done by the remote workstations that submitted the job if their LPR implementations have the necessary commands. The Windows 3.1 LPR client I detailed earlier this capability. Many LPR clients don't, however, which means that the administrator must Telnet into the UNIX machine that the print queues are on and delete the jobs there. The administrator can delete any print jobs from any queues by running the lprm command followed by the specified print queue and the job number. Below is a sample output of the command: &prompt.root; lprm -P nec-raw 19 dfA019tedmitte dequeued cfA019dostest dequeued &prompt.root; lprm -P nec-raw 3 dfA003toybox.placo.com dequeued cfA003toybox.placo.com dequeued The lprm command is also used under UNIX to delete remote print jobs. Advanced management The administrator logged into the FreeBSD system as the root user can also perform several other operations that ordinary users cannot. These include turning the queues on and off, and moving print jobs within the print queues. The command used to do this is the lpc command. lpc has two modes of operation. In the first mode, the command is run by itself, which puts the administrator into an lpc prompt. Some general help is available for the commands, such as the following sample output: &prompt.root; lpc lpc> help Commands may be abbreviated. Commands are: abort enable disable help restart status topq ? clean exit down quit start stop up lpc> help disable disable turn a spooling queue off lpc> help status status show status of daemon and queue lpc> exit In the second mode of operation the lpc command is just run by itself, followed by the command and the print queue name. Following is a sample output: &prompt.root; lpc disable lp lp: queuing disabled Under FreeBSD, there is no command that specifically allows the administrator to move jobs from one queue to another. This can be done, however, by changing into the raw queue directory then rerunning the lpr command. Following is a sample run showing three print jobs moved from a dysfunctional queue to a good one: &prompt.root; lpq -a lp: Warning: lp is down: printing disabled printing disabled Rank Owner Job Files Total Size 1st root 51 hosts 1220 bytes 2nd root 52 services 60767 bytes 3rd root 53 printcap 2383 bytes &prompt.root; cd /var/spool/output/lpd &prompt.root; ls .seq cfA053toybox.placo.com dfA053toybox.placo.com cfA051toybox.placo.com dfA051toybox.placo.com lock cfA052toybox.placo.com dfA052toybox.placo.com status &prompt.root; lpr -P nec-raw dfA051toybox.placo.com &prompt.root; lpr -P nec-raw dfA052toybox.placo.com &prompt.root; lpr -P nec-raw dfA053toybox.placo.com &prompt.root; lprm -P lp - &prompt.root; lpq -a nec-raw: Warning: nec-raw is down: printing disabled Warning: no daemon present Rank Owner Job Files Total Size 1st root 5 dfA051toybox.placo.com 1220 bytes 2nd root 6 dfA052toybox.placo.com 60767 bytes 3rd root 7 dfA053toybox.placo.com 2383 bytes Moving jobs from queue to queue is feasible only when all printers are similar, as when all printers support PostScript. Remote Management Just as the root user can manipulate remotely submitted jobs in the print queue, print jobs can be remotely managed by regular users with the LPR clients that created them. Unfortunately, some LPR clients, such as Win95, don't have enough programming to be able to do this. Others, like the Win31 client, can manipulate the print jobs remotely. FreeBSD offers some level of protection against inadvertent deletion of print jobs from remote hosts by restricting manipulation of a job to the same host that originated it. Even if the owner of the job matches a local user account on the server, for an ordinary user to delete remotely submitted print jobs, the request still must come from the remote host. Advanced Printing Topics The FreeBSD UNIX LPR/LPD printing system is very flexible, and, with the addition of filters, can be adapted to very unusual printing environments. To enhance this flexibility, several useful printing utilities are supplied on the FreeBSD CDROM which the administrator might wish to install. Ghostscript The Ghostscript program, invoked as /usr/local/bin/gs, is one of the most useful printing utilities that have been developed for the free software community. Ghostscript reads incoming PostScript data, (or Adobe PDF files) interprets it, and outputs it as a raster image. This can be displayed on screen, for example, with the GhostView program under the X Window system, or printed on most graphics printers, such as Epson dot-matrix, HP DeskJet, or HP LaserJet. In effect, it is a way of adding PostScript printing capability to a printer that doesn't have PostScript firmware code. Ghostscript has been ported to numerous operating systems including Windows. The Ghostscript home page is located at http://www.cs.wisc.edu/~ghost/ and contains the most current version of the program. A prebuilt FreeBSD binary of Ghostscript located in the Packages section of the FreeBSD CDROM. This can be installed on the FreeBSD system by selecting the package from the prepackaged software list that is accessed through the /stand/sysinstall installation program. Many packaged programs on the CD depend on GhostScript, and so it may already be installed. Installation of the packaged version of GhostScript is recommended in the FreeBSD ports Section because it has been tested with the other packages that require it. The package creates a directory containing some documentation files in /usr/local/share/ghostscript/X.XX/doc. Unfortunately, because of the packaging process on the FreeBSD CDROM not all the useful installation files are copied into this location. So, if the package was version 5.03 (for example) the administrator will also want to get the file ftp://ftp.cs.wisc.edu/ghost/aladdin/gs503/ghostscript-5.03.tar.gz, and unzip and untar it into a temporary directory. Extracting the archive file creates a directory structure under the gs5.03 subdirectory. To install ghostscript in the /etc/printcap file, read the gs5.03/devs.mak file to determine which printer driver definition works with your printer and then use the following instructions: Change to the root user with su. In the gs5.03directory, copy the lprsetup.sh, unix-lpr.txt, and unix-lpr.sh files to /usr/local/share/ghostscript/5.03 Change to the /usr/local/share/ghostscript/5.03 directory. Edit lprsetup.sh with a text editor such as vi. Modify the DEVICES= entries to list your selected printer driver definitions per the instructions in unix-lpr.txt. Modify the PRINTERDEV= to /dev/lpt0, and the GSDIR= to /usr/local/share/ghostscript, and the SPOOLDIR= to /var/spool/output. Save the file. Edit the unix-lpr.sh file and change the PSFILTERPATH= to /usr/local/share/ghostscript. If the printer that you defined in the lprsetup.sh file is a monochrome printer, remove the "-dBitsPerPixel=${bpp}"and "$colorspec" entries on the gs invocation line and save the file. Otherwise, if it is a color definition leave them in. For example, the following line is for a monochrome LaserJet: ") | gs -q -dNOPAUSE -sDEVICE=${device} \" Don't remove anything else. Exit the editor, and save the unix-lpr.sh file. Copy the unix-lpr.sh file to the parent directory, /usr/local/share/ghostscript and set the execute bit on it. Set the execute bit on lprsetup.sh with chmod and run the file by typing ./lprsetup.sh Follow the instructions on creating the Spool directories. If you will be using accounting and a separate log file, run the touch command to create the empty files per directions in script output. The sample /etc/printcap is located in the current directory; the filename is printcap.insert. Use this as a template to modify the /etc/printcap file. A sample /etc/printcap file for a LaserJet 3 is below: # # ljet3.raw|Raw output device ljet3 for Ghostscript:\ :rm=big.army.mil:rp=sherman:sd=/var/spool/output/ljet3/raw:\ :mx#0:sf:sh:rs: # ljet3|Ghostscript device ljet3 (output to ljet3.raw):\ :lp=/dev/null:sd=/var/spool/output/ljet3:\ :lf=/var/log/lpd-errs:mx#0:sf:sh:rs:\ :if=/usr/local/share/ghostscript/filt/indirect/ljet3/gsif:\ :af=/var/spool/output/ljet3/acct: # a2ps filter Another handy utility is the a2ps, short for ASCII-to-PostScript. This program takes an incoming ASCII datastream and converts it into PostScript. It can also print multiple pages on a single sheet of paper by shrinking them down. It is a useful tool for a printer that cannot interpret ASCII, such as a PostScript-only printer. A2ps is not installed in the FreeBSD system by default; it is located in the ports section /usr/ports/print/a2ps43. A prepackaged binary can be installed with /stand/sysinstall but I have had problems with that port. It is best to install it by running make in the a2ps43 ports directory. A printcap entry and filter using this follow: <filename>/etc/printcap</filename> # lp|local line printer with output dumped through a2ps for raw listings:\ :lp=/dev/lpt0:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs:sh:mx#0:\ :if=/usr/local/libexec/ascii2postscript: # <filename>/usr/local/libexec/ascii2postscript</filename> #!/bin/sh # # Simple filter that converts ASCII to Postscript for basic stuff like # directory listings. # /usr/local/bin/a2ps && exit 0 exit 2 Read the system manual page for a2ps to see the options available with this program, and remember to set the filter script ascii2postscript all-executable. Miscellaneous The large number of other printing utilities cannot be covered here. Some add features such as automatic job type sensing, others handle bidirectional communication between the server and the printer. There are also a few other experimental LPR printing replacement systems. Commands such as ghostscript and a2ps can also be used in pipes that create pretty output on an ordinary impact printer. One last hint - the system manual pages can be printed with the option which turns their ordinary ASCII output to beautifully formatted PostScript. Try the command man -t man and send the output through GhostScript or a PostScript printer for easier to read manual pages. diff --git a/en_US.ISO8859-1/books/design-44bsd/book.sgml b/en_US.ISO8859-1/books/design-44bsd/book.sgml index 6c44b5a92a..e200c8d7c5 100644 --- a/en_US.ISO8859-1/books/design-44bsd/book.sgml +++ b/en_US.ISO8859-1/books/design-44bsd/book.sgml @@ -1,2858 +1,2858 @@ - + %man; ]> The Design and Implementation of the 4.4BSD Operating System Marshall Kirk McKusick Keith Bostic Michael J. Karels John S. Quarterman 1996 Addison-Wesley Longman, Inc The second chapter of the book, The Design and Implementation of the 4.4BSD Operating System is excerpted here with the permission of the publisher. No part of it may be further reproduced or distributed without the publisher's express written - permission. The + peter.gordon@awl.com. The rest of the book explores the concepts introduced in this chapter in incredible detail and is an excellent reference for anyone with an interest in BSD UNIX. More information about this book is available from the publisher, with whom you can also sign up to receive news - of related titles. + of curt.johnson@awl.com">related titles. Information about BSD courses is available from Kirk McKusick. Design Overview of 4.4BSD 4.4BSD Facilities and the Kernel The 4.4BSD kernel provides four basic facilities: processes, a filesystem, communications, and system startup. This section outlines where each of these four basic services is described in this book. Processes constitute a thread of control in an address space. Mechanisms for creating, terminating, and otherwise controlling processes are described in Chapter 4. The system multiplexes separate virtual-address spaces for each process; this memory management is discussed in Chapter 5. The user interface to the filesystem and devices is similar; common aspects are discussed in Chapter 6. The filesystem is a set of named files, organized in a tree-structured hierarchy of directories, and of operations to manipulate them, as presented in Chapter 7. Files reside on physical media such as disks. 4.4BSD supports several organizations of data on the disk, as set forth in Chapter 8. Access to files on remote machines is the subject of Chapter 9. Terminals are used to access the system; their operation is the subject of Chapter 10. Communication mechanisms provided by traditional UNIX systems include simplex reliable byte streams between related processes (see pipes, Section 11.1), and notification of exceptional events (see signals, Section 4.7). 4.4BSD also has a general interprocess-communication facility. This facility, described in Chapter 11, uses access mechanisms distinct from those of the filesystem, but, once a connection is set up, a process can access it as though it were a pipe. There is a general networking framework, discussed in Chapter 12, that is normally used as a layer underlying the IPC facility. Chapter 13 describes a particular networking implementation in detail. Any real operating system has operational issues, such as how to start it running. Startup and operational issues are described in Chapter 14. Sections 2.3 through 2.14 present introductory material related to Chapters 3 through 14. We shall define terms, mention basic system calls, and explore historical developments. Finally, we shall give the reasons for many major design decisions. The Kernel The kernel is the part of the system that runs in protected mode and mediates access by all user programs to the underlying hardware (e.g., CPU, disks, terminals, network links) and software constructs (e.g., filesystem, network protocols). The kernel provides the basic system facilities; it creates and manages processes, and provides functions to access the filesystem and communication facilities. These functions, called system calls appear to user processes as library subroutines. These system calls are the only interface that processes have to these facilities. Details of the system-call mechanism are given in Chapter 3, as are descriptions of several kernel mechanisms that do not execute as the direct result of a process doing a system call. A kernel in traditional operating-system terminology, is a small nucleus of software that provides only the minimal facilities necessary for implementing additional operating-system services. In contemporary research operating systems -- such as Chorus , Mach , Tunis , and the V Kernel -- this division of functionality is more than just a logical one. Services such as filesystems and networking protocols are implemented as client application processes of the nucleus or kernel. The 4.4BSD kernel is not partitioned into multiple processes. This basic design decision was made in the earliest versions of UNIX. The first two implementations by Ken Thompson had no memory mapping, and thus made no hardware-enforced distinction between user and kernel space . A message-passing system could have been implemented as readily as the actually implemented model of kernel and user processes. The monolithic kernel was chosen for simplicity and performance. And the early kernels were small; the inclusion of facilities such as networking into the kernel has increased its size. The current trend in operating-systems research is to reduce the kernel size by placing such services in user space. Users ordinarily interact with the system through a command-language interpreter, called a shell, and perhaps through additional user application programs. Such programs and the shell are implemented with processes. Details of such programs are beyond the scope of this book, which instead concentrates almost exclusively on the kernel. Sections 2.3 and 2.4 describe the services provided by the 4.4BSD kernel, and give an overview of the latter's design. Later chapters describe the detailed design and implementation of these services as they appear in 4.4BSD. Kernel Organization In this section, we view the organization of the 4.4BSD kernel in two ways: As a static body of software, categorized by the functionality offered by the modules that make up the kernel By its dynamic operation, categorized according to the services provided to users The largest part of the kernel implements the system services that applications access through system calls. In 4.4BSD, this software has been organized according to the following: Basic kernel facilities: timer and system-clock handling, descriptor management, and process management Memory-management support: paging and swapping Generic system interfaces: the I/O, control, and multiplexing operations performed on descriptors The filesystem: files, directories, pathname translation, file locking, and I/O buffer management Terminal-handling support: the terminal-interface driver and terminal line disciplines Interprocess-communication facilities: sockets Support for network communication: communication protocols and generic network facilities, such as routing Machine-independent software in the 4.4BSD kernel Category Lines of code Percentage of kernel total machine independent 162,617 80.4 headers 9,393 4.6 initialization 1,107 0.6 kernel facilities 8,793 4.4 generic interfaces 4,782 2.4 interprocess communication 4,540 2.2 terminal handling 3,911 1.9 virtual memory 11,813 5.8 vnode management 7,954 3.9 filesystem naming 6,550 3.2 fast filestore 4,365 2.2 log-structure filestore 4,337 2.1 memory-based filestore 645 0.3 cd9660 filesystem 4,177 2.1 miscellaneous filesystems (10) 12,695 6.3 network filesystem 17,199 8.5 network communication 8,630 4.3 internet protocols 11,984 5.9 ISO protocols 23,924 11.8 X.25 protocols 10,626 5.3 XNS protocols 5,192 2.6
Most of the software in these categories is machine independent and is portable across different hardware architectures. The machine-dependent aspects of the kernel are isolated from the mainstream code. In particular, none of the machine-independent code contains conditional code for specific architecture. When an architecture-dependent action is needed, the machine-independent code calls an architecture-dependent function that is located in the machine-dependent code. The software that is machine dependent includes Low-level system-startup actions Trap and fault handling Low-level manipulation of the run-time context of a process Configuration and initialization of hardware devices Run-time support for I/O devices Machine-dependent software for the HP300 in the 4.4BSD kernel Category Lines of code Percentage of kernel total machine dependent 39,634 19.6 machine dependent headers 1,562 0.8 device driver headers 3,495 1.7 device driver source 17,506 8.7 virtual memory 3,087 1.5 other machine dependent 6,287 3.1 routines in assembly language 3,014 1.5 HP/UX compatibility 4,683 2.3
summarizes the machine-independent software that constitutes the 4.4BSD kernel for the HP300. The numbers in column 2 are for lines of C source code, header files, and assembly language. Virtually all the software in the kernel is written in the C programming language; less than 2 percent is written in assembly language. As the statistics in show, the machine-dependent software, excluding HP/UX and device support, accounts for a minuscule 6.9 percent of the kernel. Only a small part of the kernel is devoted to initializing the system. This code is used when the system is bootstrapped into operation and is responsible for setting up the kernel hardware and software environment (see Chapter 14). Some operating systems (especially those with limited physical memory) discard or overlay the software that performs these functions after that software has been executed. The 4.4BSD kernel does not reclaim the memory used by the startup code because that memory space is barely 0.5 percent of the kernel resources used on a typical machine. Also, the startup code does not appear in one place in the kernel -- it is scattered throughout, and it usually appears in places logically associated with what is being initialized. Kernel Services The boundary between the kernel- and user-level code is enforced by hardware-protection facilities provided by the underlying hardware. The kernel operates in a separate address space that is inaccessible to user processes. Privileged operations -- such as starting I/O and halting the central processing unit (CPU) -- are available to only the kernel. Applications request services from the kernel with system calls System calls are used to cause the kernel to execute complicated operations, such as writing data to secondary storage, and simple operations, such as returning the current time of day. All system calls appear synchronous to applications: The application does not run while the kernel does the actions associated with a system call. The kernel may finish some operations associated with a system call after it has returned. For example, a write system call will copy the data to be written from the user process to a kernel buffer while the process waits, but will usually return from the system call before the kernel buffer is written to the disk. A system call usually is implemented as a hardware trap that changes the CPU's execution mode and the current address-space mapping. Parameters supplied by users in system calls are validated by the kernel before being used. Such checking ensures the integrity of the system. All parameters passed into the kernel are copied into the kernel's address space, to ensure that validated parameters are not changed as a side effect of the system call. System-call results are returned by the kernel, either in hardware registers or by their values being copied to user-specified memory addresses. Like parameters passed into the kernel, addresses used for the return of results must be validated to ensure that they are part of an application's address space. If the kernel encounters an error while processing a system call, it returns an error code to the user. For the C programming language, this error code is stored in the global variable errno, and the function that executed the system call returns the value -1. User applications and the kernel operate independently of each other. 4.4BSD does not store I/O control blocks or other operating-system-related data structures in the application's address space. Each user-level application is provided an independent address space in which it executes. The kernel makes most state changes, such as suspending a process while another is running, invisible to the processes involved. Process Management 4.4BSD supports a multitasking environment. Each task or thread of execution is termed a process. The context of a 4.4BSD process consists of user-level state, including the contents of its address space and the run-time environment, and kernel-level state, which includes scheduling parameters, resource controls, and identification information. The context includes everything used by the kernel in providing services for the process. Users can create processes, control the processes' execution, and receive notification when the processes' execution status changes. Every process is assigned a unique value, termed a process identifier (PID). This value is used by the kernel to identify a process when reporting status changes to a user, and by a user when referencing a process in a system call. The kernel creates a process by duplicating the context of another process. The new process is termed a child process of the original parent process The context duplicated in process creation includes both the user-level execution state of the process and the process's system state managed by the kernel. Important components of the kernel state are described in Chapter 4.
Process lifecycle +----------------+ wait +----------------+ | parent process |--------------------------------->| parent process |---> +----------------+ +----------------+ | ^ | fork | V | +----------------+ execve +----------------+ wait +----------------+ | child process |------->| child process |------->| zombie process | +----------------+ +----------------+ +----------------+ Process-management system calls
The process lifecycle is depicted in . A process may create a new process that is a copy of the original by using the fork system call. The fork call returns twice: once in the parent process, where the return value is the process identifier of the child, and once in the child process, where the return value is 0. The parent-child relationship induces a hierarchical structure on the set of processes in the system. The new process shares all its parent's resources, such as file descriptors, signal-handling status, and memory layout. Although there are occasions when the new process is intended to be a copy of the parent, the loading and execution of a different program is a more useful and typical action. A process can overlay itself with the memory image of another program, passing to the newly created image a set of parameters, using the system call execve. One parameter is the name of a file whose contents are in a format recognized by the system -- either a binary-executable file or a file that causes the execution of a specified interpreter program to process its contents. A process may terminate by executing an exit system call, sending 8 bits of exit status to its parent. If a process wants to communicate more than a single byte of information with its parent, it must either set up an interprocess-communication channel using pipes or sockets, or use an intermediate file. Interprocess communication is discussed extensively in Chapter 11. A process can suspend execution until any of its child processes terminate using the wait system call, which returns the PID and exit status of the terminated child process. A parent process can arrange to be notified by a signal when a child process exits or terminates abnormally. Using the wait4 system call, the parent can retrieve information about the event that caused termination of the child process and about resources consumed by the process during its lifetime. If a process is orphaned because its parent exits before it is finished, then the kernel arranges for the child's exit status to be passed back to a special system process init: see Sections 3.1 and 14.6). The details of how the kernel creates and destroys processes are given in Chapter 5. Processes are scheduled for execution according to a process-priority parameter. This priority is managed by a kernel-based scheduling algorithm. Users can influence the scheduling of a process by specifying a parameter (nice) that weights the overall scheduling priority, but are still obligated to share the underlying CPU resources according to the kernel's scheduling policy. Signals The system defines a set of signals that may be delivered to a process. Signals in 4.4BSD are modeled after hardware interrupts. A process may specify a user-level subroutine to be a handler to which a signal should be delivered. When a signal is generated, it is blocked from further occurrence while it is being caught by the handler. Catching a signal involves saving the current process context and building a new one in which to run the handler. The signal is then delivered to the handler, which can either abort the process or return to the executing process (perhaps after setting a global variable). If the handler returns, the signal is unblocked and can be generated (and caught) again. Alternatively, a process may specify that a signal is to be ignored, or that a default action, as determined by the kernel, is to be taken. The default action of certain signals is to terminate the process. This termination may be accompanied by creation of a core file that contains the current memory image of the process for use in postmortem debugging. Some signals cannot be caught or ignored. These signals include SIGKILL, which kills runaway processes, and the job-control signal SIGSTOP. A process may choose to have signals delivered on a special stack so that sophisticated software stack manipulations are possible. For example, a language supporting coroutines needs to provide a stack for each coroutine. The language run-time system can allocate these stacks by dividing up the single stack provided by 4.4BSD. If the kernel does not support a separate signal stack, the space allocated for each coroutine must be expanded by the amount of space required to catch a signal. All signals have the same priority. If multiple signals are pending simultaneously, the order in which signals are delivered to a process is implementation specific. Signal handlers execute with the signal that caused their invocation to be blocked, but other signals may yet occur. Mechanisms are provided so that processes can protect critical sections of code against the occurrence of specified signals. The detailed design and implementation of signals is described in Section 4.7. Process Groups and Sessions Processes are organized into process groups. Process groups are used to control access to terminals and to provide a means of distributing signals to collections of related processes. A process inherits its process group from its parent process. Mechanisms are provided by the kernel to allow a process to alter its process group or the process group of its descendents. Creating a new process group is easy; the value of a new process group is ordinarily the process identifier of the creating process. The group of processes in a process group is sometimes referred to as a job and is manipulated by high-level system software, such as the shell. A common kind of job created by a shell is a pipeline of several processes connected by pipes, such that the output of the first process is the input of the second, the output of the second is the input of the third, and so forth. The shell creates such a job by forking a process for each stage of the pipeline, then putting all those processes into a separate process group. A user process can send a signal to each process in a process group, as well as to a single process. A process in a specific process group may receive software interrupts affecting the group, causing the group to suspend or resume execution, or to be interrupted or terminated. A terminal has a process-group identifier assigned to it. This identifier is normally set to the identifier of a process group associated with the terminal. A job-control shell may create a number of process groups associated with the same terminal; the terminal is the controlling terminal for each process in these groups. A process may read from a descriptor for its controlling terminal only if the terminal's process-group identifier matches that of the process. If the identifiers do not match, the process will be blocked if it attempts to read from the terminal. By changing the process-group identifier of the terminal, a shell can arbitrate a terminal among several different jobs. This arbitration is called job control and is described, with process groups, in Section 4.8. Just as a set of related processes can be collected into a process group, a set of process groups can be collected into a session. The main uses for sessions are to create an isolated environment for a daemon process and its children, and to collect together a user's login shell and the jobs that that shell spawns. Memory Management Each process has its own private address space. The address space is initially divided into three logical segments: text, data, and stack. The text segment is read-only and contains the machine instructions of a program. The data and stack segments are both readable and writable. The data segment contains the initialized and uninitialized data portions of a program, whereas the stack segment holds the application's run-time stack. On most machines, the stack segment is extended automatically by the kernel as the process executes. A process can expand or contract its data segment by making a system call, whereas a process can change the size of its text segment only when the segment's contents are overlaid with data from the filesystem, or when debugging takes place. The initial contents of the segments of a child process are duplicates of the segments of a parent process. The entire contents of a process address space do not need to be resident for a process to execute. If a process references a part of its address space that is not resident in main memory, the system pages the necessary information into memory. When system resources are scarce, the system uses a two-level approach to maintain available resources. If a modest amount of memory is available, the system will take memory resources away from processes if these resources have not been used recently. Should there be a severe resource shortage, the system will resort to swapping the entire context of a process to secondary storage. The demand paging and swapping done by the system are effectively transparent to processes. A process may, however, advise the system about expected future memory utilization as a performance aid. BSD Memory-Management Design Decisions The support of large sparse address spaces, mapped files, and shared memory was a requirement for 4.2BSD. An interface was specified, called mmap, that allowed unrelated processes to request a shared mapping of a file into their address spaces. If multiple processes mapped the same file into their address spaces, changes to the file's portion of an address space by one process would be reflected in the area mapped by the other processes, as well as in the file itself. Ultimately, 4.2BSD was shipped without the mmap interface, because of pressure to make other features, such as networking, available. Further development of the mmap interface continued during the work on 4.3BSD. Over 40 companies and research groups participated in the discussions leading to the revised architecture that was described in the Berkeley Software Architecture Manual . Several of the companies have implemented the revised interface . Once again, time pressure prevented 4.3BSD from providing an implementation of the interface. Although the latter could have been built into the existing 4.3BSD virtual-memory system, the developers decided not to put it in because that implementation was nearly 10 years old. Furthermore, the original virtual-memory design was based on the assumption that computer memories were small and expensive, whereas disks were locally connected, fast, large, and inexpensive. Thus, the virtual-memory system was designed to be frugal with its use of memory at the expense of generating extra disk traffic. In addition, the 4.3BSD implementation was riddled with VAX memory-management hardware dependencies that impeded its portability to other computer architectures. Finally, the virtual-memory system was not designed to support the tightly coupled multiprocessors that are becoming increasingly common and important today. Attempts to improve the old implementation incrementally seemed doomed to failure. A completely new design, on the other hand, could take advantage of large memories, conserve disk transfers, and have the potential to run on multiprocessors. Consequently, the virtual-memory system was completely replaced in 4.4BSD. The 4.4BSD virtual-memory system is based on the Mach 2.0 VM system . with updates from Mach 2.5 and Mach 3.0. It features efficient support for sharing, a clean separation of machine-independent and machine-dependent features, as well as (currently unused) multiprocessor support. Processes can map files anywhere in their address space. They can share parts of their address space by doing a shared mapping of the same file. Changes made by one process are visible in the address space of the other process, and also are written back to the file itself. Processes can also request private mappings of a file, which prevents any changes that they make from being visible to other processes mapping the file or being written back to the file itself. Another issue with the virtual-memory system is the way that information is passed into the kernel when a system call is made. 4.4BSD always copies data from the process address space into a buffer in the kernel. For read or write operations that are transferring large quantities of data, doing the copy can be time consuming. An alternative to doing the copying is to remap the process memory into the kernel. The 4.4BSD kernel always copies the data for several reasons: Often, the user data are not page aligned and are not a multiple of the hardware page length. If the page is taken away from the process, it will no longer be able to reference that page. Some programs depend on the data remaining in the buffer even after those data have been written. If the process is allowed to keep a copy of the page (as it is in current 4.4BSD semantics), the page must be made copy-on-write. A copy-on-write page is one that is protected against being written by being made read-only. If the process attempts to modify the page, the kernel gets a write fault. The kernel then makes a copy of the page that the process can modify. Unfortunately, the typical process will immediately try to write new data to its output buffer, forcing the data to be copied anyway. When pages are remapped to new virtual-memory addresses, most memory-management hardware requires that the hardware address-translation cache be purged selectively. The cache purges are often slow. The net effect is that remapping is slower than copying for blocks of data less than 4 to 8 Kbyte. The biggest incentives for memory mapping are the needs for accessing big files and for passing large quantities of data between processes. The mmap interface provides a way for both of these tasks to be done without copying. Memory Management Inside the Kernel The kernel often does allocations of memory that are needed for only the duration of a single system call. In a user process, such short-term memory would be allocated on the run-time stack. Because the kernel has a limited run-time stack, it is not feasible to allocate even moderate-sized blocks of memory on it. Consequently, such memory must be allocated through a more dynamic mechanism. For example, when the system must translate a pathname, it must allocate a 1-Kbyte buffer to hold the name. Other blocks of memory must be more persistent than a single system call, and thus could not be allocated on the stack even if there was space. An example is protocol-control blocks that remain throughout the duration of a network connection. Demands for dynamic memory allocation in the kernel have increased as more services have been added. A generalized memory allocator reduces the complexity of writing code inside the kernel. Thus, the 4.4BSD kernel has a single memory allocator that can be used by any part of the system. It has an interface similar to the C library routines malloc and free that provide memory allocation to application programs . Like the C library interface, the allocation routine takes a parameter specifying the size of memory that is needed. The range of sizes for memory requests is not constrained; however, physical memory is allocated and is not paged. The free routine takes a pointer to the storage being freed, but does not require the size of the piece of memory being freed. I/O System The basic model of the UNIX I/O system is a sequence of bytes that can be accessed either randomly or sequentially. There are no access methods and no control blocks in a typical UNIX user process. Different programs expect various levels of structure, but the kernel does not impose structure on I/O. For instance, the convention for text files is lines of ASCII characters separated by a single newline character (the ASCII line-feed character), but the kernel knows nothing about this convention. For the purposes of most programs, the model is further simplified to being a stream of data bytes, or an I/O stream. It is this single common data form that makes the characteristic UNIX tool-based approach work . An I/O stream from one program can be fed as input to almost any other program. (This kind of traditional UNIX I/O stream should not be confused with the Eighth Edition stream I/O system or with the System V, Release 3 STREAMS, both of which can be accessed as traditional I/O streams.) Descriptors and I/O UNIX processes use descriptors to reference I/O streams. Descriptors are small unsigned integers obtained from the open and socket system calls. The open system call takes as arguments the name of a file and a permission mode to specify whether the file should be open for reading or for writing, or for both. This system call also can be used to create a new, empty file. A read or write system call can be applied to a descriptor to transfer data. The close system call can be used to deallocate any descriptor. Descriptors represent underlying objects supported by the kernel, and are created by system calls specific to the type of object. In 4.4BSD, three kinds of objects can be represented by descriptors: files, pipes, and sockets. A file is a linear array of bytes with at least one name. A file exists until all its names are deleted explicitly and no process holds a descriptor for it. A process acquires a descriptor for a file by opening that file's name with the open system call. I/O devices are accessed as files. A pipe is a linear array of bytes, as is a file, but it is used solely as an I/O stream, and it is unidirectional. It also has no name, and thus cannot be opened with open. Instead, it is created by the pipe system call, which returns two descriptors, one of which accepts input that is sent to the other descriptor reliably, without duplication, and in order. The system also supports a named pipe or FIFO. A FIFO has properties identical to a pipe, except that it appears in the filesystem; thus, it can be opened using the open system call. Two processes that wish to communicate each open the FIFO: One opens it for reading, the other for writing. A socket is a transient object that is used for interprocess communication; it exists only as long as some process holds a descriptor referring to it. A socket is created by the socket system call, which returns a descriptor for it. There are different kinds of sockets that support various communication semantics, such as reliable delivery of data, preservation of message ordering, and preservation of message boundaries. In systems before 4.2BSD, pipes were implemented using the filesystem; when sockets were introduced in 4.2BSD, pipes were reimplemented as sockets. The kernel keeps for each process a descriptor table, which is a table that the kernel uses to translate the external representation of a descriptor into an internal representation. (The descriptor is merely an index into this table.) The descriptor table of a process is inherited from that process's parent, and thus access to the objects to which the descriptors refer also is inherited. The main ways that a process can obtain a descriptor are by opening or creation of an object, and by inheritance from the parent process. In addition, socket IPC allows passing of descriptors in messages between unrelated processes on the same machine. Every valid descriptor has an associated file offset in bytes from the beginning of the object. Read and write operations start at this offset, which is updated after each data transfer. For objects that permit random access, the file offset also may be set with the lseek system call. Ordinary files permit random access, and some devices do, as well. Pipes and sockets do not. When a process terminates, the kernel reclaims all the descriptors that were in use by that process. If the process was holding the final reference to an object, the object's manager is notified so that it can do any necessary cleanup actions, such as final deletion of a file or deallocation of a socket. Descriptor Management Most processes expect three descriptors to be open already when they start running. These descriptors are 0, 1, 2, more commonly known as standard input, standard output, and standard error, respectively. Usually, all three are associated with the user's terminal by the login process (see Section 14.6) and are inherited through fork and exec by processes run by the user. Thus, a program can read what the user types by reading standard input, and the program can send output to the user's screen by writing to standard output. The standard error descriptor also is open for writing and is used for error output, whereas standard output is used for ordinary output. These (and other) descriptors can be mapped to objects other than the terminal; such mapping is called I/O redirection, and all the standard shells permit users to do it. The shell can direct the output of a program to a file by closing descriptor 1 (standard output) and opening the desired output file to produce a new descriptor 1. It can similarly redirect standard input to come from a file by closing descriptor 0 and opening the file. Pipes allow the output of one program to be input to another program without rewriting or even relinking of either program. Instead of descriptor 1 (standard output) of the source program being set up to write to the terminal, it is set up to be the input descriptor of a pipe. Similarly, descriptor 0 (standard input) of the sink program is set up to reference the output of the pipe, instead of the terminal keyboard. The resulting set of two processes and the connecting pipe is known as a pipeline. Pipelines can be arbitrarily long series of processes connected by pipes. The open, pipe, and socket system calls produce new descriptors with the lowest unused number usable for a descriptor. For pipelines to work, some mechanism must be provided to map such descriptors into 0 and 1. The dup system call creates a copy of a descriptor that points to the same file-table entry. The new descriptor is also the lowest unused one, but if the desired descriptor is closed first, dup can be used to do the desired mapping. Care is required, however: If descriptor 1 is desired, and descriptor 0 happens also to have been closed, descriptor 0 will be the result. To avoid this problem, the system provides the dup2 system call; it is like dup, but it takes an additional argument specifying the number of the desired descriptor (if the desired descriptor was already open, dup2 closes it before reusing it). Devices Hardware devices have filenames, and may be accessed by the user via the same system calls used for regular files. The kernel can distinguish a device special file or special file, and can determine to what device it refers, but most processes do not need to make this determination. Terminals, printers, and tape drives are all accessed as though they were streams of bytes, like 4.4BSD disk files. Thus, device dependencies and peculiarities are kept in the kernel as much as possible, and even in the kernel most of them are segregated in the device drivers. Hardware devices can be categorized as either structured or unstructured; they are known as block or character devices, respectively. Processes typically access devices through special files in the filesystem. I/O operations to these files are handled by kernel-resident software modules termed device drivers. Most network-communication hardware devices are accessible through only the interprocess-communication facilities, and do not have special files in the filesystem name space, because the raw-socket interface provides a more natural interface than does a special file. Structured or block devices are typified by disks and magnetic tapes, and include most random-access devices. The kernel supports read-modify-write-type buffering actions on block-oriented structured devices to allow the latter to be read and written in a totally random byte-addressed fashion, like regular files. Filesystems are created on block devices. Unstructured devices are those devices that do not support a block structure. Familiar unstructured devices are communication lines, raster plotters, and unbuffered magnetic tapes and disks. Unstructured devices typically support large block I/O transfers. Unstructured files are called character devices because the first of these to be implemented were terminal device drivers. The kernel interface to the driver for these devices proved convenient for other devices that were not block structured. Device special files are created by the mknod system call. There is an additional system call, ioctl, for manipulating the underlying device parameters of special files. The operations that can be done differ for each device. This system call allows the special characteristics of devices to be accessed, rather than overloading the semantics of other system calls. For example, there is an ioctl on a tape drive to write an end-of-tape mark, instead of there being a special or modified version of write. Socket IPC The 4.2BSD kernel introduced an IPC mechanism more flexible than pipes, based on sockets. A socket is an endpoint of communication referred to by a descriptor, just like a file or a pipe. Two processes can each create a socket, and then connect those two endpoints to produce a reliable byte stream. Once connected, the descriptors for the sockets can be read or written by processes, just as the latter would do with a pipe. The transparency of sockets allows the kernel to redirect the output of one process to the input of another process residing on another machine. A major difference between pipes and sockets is that pipes require a common parent process to set up the communications channel. A connection between sockets can be set up by two unrelated processes, possibly residing on different machines. System V provides local interprocess communication through FIFOs (also known as named pipes). FIFOs appear as an object in the filesystem that unrelated processes can open and send data through in the same way as they would communicate through a pipe. Thus, FIFOs do not require a common parent to set them up; they can be connected after a pair of processes are up and running. Unlike sockets, FIFOs can be used on only a local machine; they cannot be used to communicate between processes on different machines. FIFOs are implemented in 4.4BSD only because they are required by the POSIX.1 standard. Their functionality is a subset of the socket interface. The socket mechanism requires extensions to the traditional UNIX I/O system calls to provide the associated naming and connection semantics. Rather than overloading the existing interface, the developers used the existing interfaces to the extent that the latter worked without being changed, and designed new interfaces to handle the added semantics. The read and write system calls were used for byte-stream type connections, but six new system calls were added to allow sending and receiving addressed messages such as network datagrams. The system calls for writing messages include send, sendto, and sendmsg. The system calls for reading messages include recv, recvfrom, and recvmsg. In retrospect, the first two in each class are special cases of the others; recvfrom and sendto probably should have been added as library interfaces to recvmsg and sendmsg, respectively. Scatter/Gather I/O In addition to the traditional read and write system calls, 4.2BSD introduced the ability to do scatter/gather I/O. Scatter input uses the readv system call to allow a single read to be placed in several different buffers. Conversely, the writev system call allows several different buffers to be written in a single atomic write. Instead of passing a single buffer and length parameter, as is done with read and write, the process passes in a pointer to an array of buffers and lengths, along with a count describing the size of the array. This facility allows buffers in different parts of a process address space to be written atomically, without the need to copy them to a single contiguous buffer. Atomic writes are necessary in the case where the underlying abstraction is record based, such as tape drives that output a tape block on each write request. It is also convenient to be able to read a single request into several different buffers (such as a record header into one place and the data into another). Although an application can simulate the ability to scatter data by reading the data into a large buffer and then copying the pieces to their intended destinations, the cost of memory-to-memory copying in such cases often would more than double the running time of the affected application. Just as send and recv could have been implemented as library interfaces to sendto and recvfrom, it also would have been possible to simulate read with readv and write with writev. However, read and write are used so much more frequently that the added cost of simulating them would not have been worthwhile. Multiple Filesystem Support With the expansion of network computing, it became desirable to support both local and remote filesystems. To simplify the support of multiple filesystems, the developers added a new virtual node or vnode interface to the kernel. The set of operations exported from the vnode interface appear much like the filesystem operations previously supported by the local filesystem. However, they may be supported by a wide range of filesystem types: Local disk-based filesystems Files imported using a variety of remote filesystem protocols Read-only CD-ROM filesystems Filesystems providing special-purpose interfaces -- for example, the /proc filesystem A few variants of 4.4BSD, such as FreeBSD, allow filesystems to be loaded dynamically when the filesystems are first referenced by the mount system call. The vnode interface is described in Section 6.5; its ancillary support routines are described in Section 6.6; several of the special-purpose filesystems are described in Section 6.7. Filesystems A regular file is a linear array of bytes, and can be read and written starting at any byte in the file. The kernel distinguishes no record boundaries in regular files, although many programs recognize line-feed characters as distinguishing the ends of lines, and other programs may impose other structure. No system-related information about a file is kept in the file itself, but the filesystem stores a small amount of ownership, protection, and usage information with each file. A filename component is a string of up to 255 characters. These filenames are stored in a type of file called a directory. The information in a directory about a file is called a directory entry and includes, in addition to the filename, a pointer to the file itself. Directory entries may refer to other directories, as well as to plain files. A hierarchy of directories and files is thus formed, and is called a filesystem;
A small filesystem +-------+ | | +-------+ / \ usr / \ vmunix |/ \| +-------+ +-------+ | | | | +-------+ +-------+ / | \ staff / | \ bin |/ | tmp \| +-------+ V +-------+ | | +-------+ | | +-------+ | | +-------+ / | \ +-------+ / | \ mckusick / | \| |/ | \ ls |/ | karels | vi \| +-------+ V V +-------+ | | +-------+ +-------+ | | +-------+ | | | | +-------+ +-------+ +-------+ A small filesystem tree
a small one is shown in . Directories may contain subdirectories, and there is no inherent limitation to the depth with which directory nesting may occur. To protect the consistency of the filesystem, the kernel does not permit processes to write directly into directories. A filesystem may include not only plain files and directories, but also references to other objects, such as devices and sockets. The filesystem forms a tree, the beginning of which is the root directory, sometimes referred to by the name slash, spelled with a single solidus character (/). The root directory contains files; in our example in Fig 2.2, it contains vmunix, a copy of the kernel-executable object file. It also contains directories; in this example, it contains the usr directory. Within the usr directory is the bin directory, which mostly contains executable object code of programs, such as the files ls and vi. A process identifies a file by specifying that file's pathname, which is a string composed of zero or more filenames separated by slash (/) characters. The kernel associates two directories with each process for use in interpreting pathnames. A process's root directory is the topmost point in the filesystem that the process can access; it is ordinarily set to the root directory of the entire filesystem. A pathname beginning with a slash is called an absolute pathname, and is interpreted by the kernel starting with the process's root directory. A pathname that does not begin with a slash is called a relative pathname, and is interpreted relative to the current working directory of the process. (This directory also is known by the shorter names current directory or working directory.) The current directory itself may be referred to directly by the name dot, spelled with a single period (.). The filename dot-dot (..) refers to a directory's parent directory. The root directory is its own parent. A process may set its root directory with the chroot system call, and its current directory with the chdir system call. Any process may do chdir at any time, but chroot is permitted only a process with superuser privileges. Chroot is normally used to set up restricted access to the system. Using the filesystem shown in Fig. 2.2, if a process has the root of the filesystem as its root directory, and has /usr as its current directory, it can refer to the file vi either from the root with the absolute pathname /usr/bin/vi, or from its current directory with the relative pathname bin/vi. System utilities and databases are kept in certain well-known directories. Part of the well-defined hierarchy includes a directory that contains the home directory for each user -- for example, /usr/staff/mckusick and /usr/staff/karels in Fig. 2.2. When users log in, the current working directory of their shell is set to the home directory. Within their home directories, users can create directories as easily as they can regular files. Thus, a user can build arbitrarily complex subhierarchies. The user usually knows of only one filesystem, but the system may know that this one virtual filesystem is really composed of several physical filesystems, each on a different device. A physical filesystem may not span multiple hardware devices. Since most physical disk devices are divided into several logical devices, there may be more than one filesystem per physical device, but there will be no more than one per logical device. One filesystem -- the filesystem that anchors all absolute pathnames -- is called the root filesystem, and is always available. Others may be mounted; that is, they may be integrated into the directory hierarchy of the root filesystem. References to a directory that has a filesystem mounted on it are converted transparently by the kernel into references to the root directory of the mounted filesystem. The link system call takes the name of an existing file and another name to create for that file. After a successful link, the file can be accessed by either filename. A filename can be removed with the unlink system call. When the final name for a file is removed (and the final process that has the file open closes it), the file is deleted. Files are organized hierarchically in directories. A directory is a type of file, but, in contrast to regular files, a directory has a structure imposed on it by the system. A process can read a directory as it would an ordinary file, but only the kernel is permitted to modify a directory. Directories are created by the mkdir system call and are removed by the rmdir system call. Before 4.2BSD, the mkdir and rmdir system calls were implemented by a series of link and unlink system calls being done. There were three reasons for adding systems calls explicitly to create and delete directories: The operation could be made atomic. If the system crashed, the directory would not be left half-constructed, as could happen when a series of link operations were used. When a networked filesystem is being run, the creation and deletion of files and directories need to be specified atomically so that they can be serialized. When supporting non-UNIX filesystems, such as an MS-DOS filesystem, on another partition of the disk, the other filesystem may not support link operations. Although other filesystems might support the concept of directories, they probably would not create and delete the directories with links, as the UNIX filesystem does. Consequently, they could create and delete directories only if explicit directory create and delete requests were presented. The chown system call sets the owner and group of a file, and chmod changes protection attributes. Stat applied to a filename can be used to read back such properties of a file. The fchown, fchmod, and fstat system calls are applied to a descriptor, instead of to a filename, to do the same set of operations. The rename system call can be used to give a file a new name in the filesystem, replacing one of the file's old names. Like the directory-creation and directory-deletion operations, the rename system call was added to 4.2BSD to provide atomicity to name changes in the local filesystem. Later, it proved useful explicitly to export renaming operations to foreign filesystems and over the network. The truncate system call was added to 4.2BSD to allow files to be shortened to an arbitrary offset. The call was added primarily in support of the Fortran run-time library, which has the semantics such that the end of a random-access file is set to be wherever the program most recently accessed that file. Without the truncate system call, the only way to shorten a file was to copy the part that was desired to a new file, to delete the old file, then to rename the copy to the original name. As well as this algorithm being slow, the library could potentially fail on a full filesystem. Once the filesystem had the ability to shorten files, the kernel took advantage of that ability to shorten large empty directories. The advantage of shortening empty directories is that it reduces the time spent in the kernel searching them when names are being created or deleted. Newly created files are assigned the user identifier of the process that created them and the group identifier of the directory in which they were created. A three-level access-control mechanism is provided for the protection of files. These three levels specify the accessibility of a file to The user who owns the file The group that owns the file Everyone else Each level of access has separate indicators for read permission, write permission, and execute permission. Files are created with zero length, and may grow when they are written. While a file is open, the system maintains a pointer into the file indicating the current location in the file associated with the descriptor. This pointer can be moved about in the file in a random-access fashion. Processes sharing a file descriptor through a fork or dup system call share the current location pointer. Descriptors created by separate open system calls have separate current location pointers. Files may have holes in them. Holes are void areas in the linear extent of the file where data have never been written. A process can create these holes by positioning the pointer past the current end-of-file and writing. When read, holes are treated by the system as zero-valued bytes. Earlier UNIX systems had a limit of 14 characters per filename component. This limitation was often a problem. For example, in addition to the natural desire of users to give files long descriptive names, a common way of forming filenames is as basename.extension, where the extension (indicating the kind of file, such as .c for C source or .o for intermediate binary object) is one to three characters, leaving 10 to 12 characters for the basename. Source-code\-control systems and editors usually take up another two characters, either as a prefix or a suffix, for their purposes, leaving eight to 10 characters. It is easy to use 10 or 12 characters in a single English word as a basename (e.g., ``multiplexer''). It is possible to keep within these limits, but it is inconvenient or even dangerous, because other UNIX systems accept strings longer than the limit when creating files, but then truncate to the limit. A C language source file named multiplexer.c (already 13 characters) might have a source-code-control file with s. prepended, producing a filename s.multiplexer that is indistinguishable from the source-code-control file for multiplexer.ms, a file containing troff source for documentation for the C program. The contents of the two original files could easily get confused with no warning from the source-code-control system. Careful coding can detect this problem, but the long filenames first introduced in 4.2BSD practically eliminate it. Filestores The operations defined for local filesystems are divided into two parts. Common to all local filesystems are hierarchical naming, locking, quotas, attribute management, and protection. These features are independent of how the data will be stored. 4.4BSD has a single implementation to provide these semantics. The other part of the local filesystem is the organization and management of the data on the storage media. Laying out the contents of files on the storage media is the responsibility of the filestore. 4.4BSD supports three different filestore layouts: The traditional Berkeley Fast Filesystem The log-structured filesystem, based on the Sprite operating-system design A memory-based filesystem Although the organizations of these filestores are completely different, these differences are indistinguishable to the processes using the filestores. The Fast Filesystem organizes data into cylinder groups. Files that are likely to be accessed together, based on their locations in the filesystem hierarchy, are stored in the same cylinder group. Files that are not expected to accessed together are moved into different cylinder groups. Thus, files written at the same time may be placed far apart on the disk. The log-structured filesystem organizes data as a log. All data being written at any point in time are gathered together, and are written at the same disk location. Data are never overwritten; instead, a new copy of the file is written that replaces the old one. The old files are reclaimed by a garbage-collection process that runs when the filesystem becomes full and additional free space is needed. The memory-based filesystem is designed to store data in virtual memory. It is used for filesystems that need to support fast but temporary data, such as /tmp. The goal of the memory-based filesystem is to keep the storage packed as compactly as possible to minimize the usage of virtual-memory resources. Network Filesystem Initially, networking was used to transfer data from one machine to another. Later, it evolved to allowing users to log in remotely to another machine. The next logical step was to bring the data to the user, instead of having the user go to the data -- and network filesystems were born. Users working locally do not experience the network delays on each keystroke, so they have a more responsive environment. Bringing the filesystem to a local machine was among the first of the major client-server applications. The server is the remote machine that exports one or more of its filesystems. The client is the local machine that imports those filesystems. From the local client's point of view, a remotely mounted filesystem appears in the file-tree name space just like any other locally mounted filesystem. Local clients can change into directories on the remote filesystem, and can read, write, and execute binaries within that remote filesystem identically to the way that they can do these operations on a local filesystem. When the local client does an operation on a remote filesystem, the request is packaged and is sent to the server. The server does the requested operation and returns either the requested information or an error indicating why the request was denied. To get reasonable performance, the client must cache frequently accessed data. The complexity of remote filesystems lies in maintaining cache consistency between the server and its many clients. Although many remote-filesystem protocols have been developed over the years, the most pervasive one in use among UNIX systems is the Network Filesystem (NFS), whose protocol and most widely used implementation were done by Sun Microsystems. The 4.4BSD kernel supports the NFS protocol, although the implementation was done independently from the protocol specification . The NFS protocol is described in Chapter 9. Terminals Terminals support the standard system I/O operations, as well as a collection of terminal-specific operations to control input-character editing and output delays. At the lowest level are the terminal device drivers that control the hardware terminal ports. Terminal input is handled according to the underlying communication characteristics, such as baud rate, and according to a set of software-controllable parameters, such as parity checking. Layered above the terminal device drivers are line disciplines that provide various degrees of character processing. The default line discipline is selected when a port is being used for an interactive login. The line discipline is run in canonical mode; input is processed to provide standard line-oriented editing functions, and input is presented to a process on a line-by-line basis. Screen editors and programs that communicate with other computers generally run in noncanonical mode (also commonly referred to as raw mode or character-at-a-time mode). In this mode, input is passed through to the reading process immediately and without interpretation. All special-character input processing is disabled, no erase or other line editing processing is done, and all characters are passed to the program that is reading from the terminal. It is possible to configure the terminal in thousands of combinations between these two extremes. For example, a screen editor that wanted to receive user interrupts asynchronously might enable the special characters that generate signals and enable output flow control, but otherwise run in noncanonical mode; all other characters would be passed through to the process uninterpreted. On output, the terminal handler provides simple formatting services, including Converting the line-feed character to the two-character carriage-return-line-feed sequence Inserting delays after certain standard control characters Expanding tabs Displaying echoed nongraphic ASCII characters as a two-character sequence of the form ``^C'' (i.e., the ASCII caret character followed by the ASCII character that is the character's value offset from the ASCII ``@'' character). Each of these formatting services can be disabled individually by a process through control requests. Interprocess Communication Interprocess communication in 4.4BSD is organized in communication domains. Domains currently supported include the local domain, for communication between processes executing on the same machine; the internet domain, for communication between processes using the TCP/IP protocol suite (perhaps within the Internet); the ISO/OSI protocol family for communication between sites required to run them; and the XNS domain, for communication between processes using the XEROX Network Systems (XNS) protocols. Within a domain, communication takes place between communication endpoints known as sockets. As mentioned in Section 2.6, the socket system call creates a socket and returns a descriptor; other IPC system calls are described in Chapter 11. Each socket has a type that defines its communications semantics; these semantics include properties such as reliability, ordering, and prevention of duplication of messages. Each socket has associated with it a communication protocol. This protocol provides the semantics required by the socket according to the latter's type. Applications may request a specific protocol when creating a socket, or may allow the system to select a protocol that is appropriate for the type of socket being created. Sockets may have addresses bound to them. The form and meaning of socket addresses are dependent on the communication domain in which the socket is created. Binding a name to a socket in the local domain causes a file to be created in the filesystem. Normal data transmitted and received through sockets are untyped. Data-representation issues are the responsibility of libraries built on top of the interprocess-communication facilities. In addition to transporting normal data, communication domains may support the transmission and reception of specially typed data, termed access rights. The local domain, for example, uses this facility to pass descriptors between processes. Networking implementations on UNIX before 4.2BSD usually worked by overloading the character-device interfaces. One goal of the socket interface was for naive programs to be able to work without change on stream-style connections. Such programs can work only if the read and write systems calls are unchanged. Consequently, the original interfaces were left intact, and were made to work on stream-type sockets. A new interface was added for more complicated sockets, such as those used to send datagrams, with which a destination address must be presented with each send call. Another benefit is that the new interface is highly portable. Shortly after a test release was available from Berkeley, the socket interface had been ported to System III by a UNIX vendor (although AT&T did not support the socket interface until the release of System V Release 4, deciding instead to use the Eighth Edition stream mechanism). The socket interface was also ported to run in many Ethernet boards by vendors, such as Excelan and Interlan, that were selling into the PC market, where the machines were too small to run networking in the main processor. More recently, the socket interface was used as the basis for Microsoft's Winsock networking interface for Windows. Network Communication Some of the communication domains supported by the socket IPC mechanism provide access to network protocols. These protocols are implemented as a separate software layer logically below the socket software in the kernel. The kernel provides many ancillary services, such as buffer management, message routing, standardized interfaces to the protocols, and interfaces to the network interface drivers for the use of the various network protocols. At the time that 4.2BSD was being implemented, there were many networking protocols in use or under development, each with its own strengths and weaknesses. There was no clearly superior protocol or protocol suite. By supporting multiple protocols, 4.2BSD could provide interoperability and resource sharing among the diverse set of machines that was available in the Berkeley environment. Multiple-protocol support also provides for future changes. Today's protocols designed for 10- to 100-Mbit-per-second Ethernets are likely to be inadequate for tomorrow's 1- to 10-Gbit-per-second fiber-optic networks. Consequently, the network-communication layer is designed to support multiple protocols. New protocols are added to the kernel without the support for older protocols being affected. Older applications can continue to operate using the old protocol over the same physical network as is used by newer applications running with a newer network protocol. Network Implementation The first protocol suite implemented in 4.2BSD was DARPA's Transmission Control Protocol/Internet Protocol (TCP/IP). The CSRG chose TCP/IP as the first network to incorporate into the socket IPC framework, because a 4.1BSD-based implementation was publicly available from a DARPA-sponsored project at Bolt, Beranek, and Newman (BBN). That was an influential choice: The 4.2BSD implementation is the main reason for the extremely widespread use of this protocol suite. Later performance and capability improvements to the TCP/IP implementation have also been widely adopted. The TCP/IP implementation is described in detail in Chapter 13. The release of 4.3BSD added the Xerox Network Systems (XNS) protocol suite, partly building on work done at the University of Maryland and at Cornell University. This suite was needed to connect isolated machines that could not communicate using TCP/IP. The release of 4.4BSD added the ISO protocol suite because of the latter's increasing visibility both within and outside the United States. Because of the somewhat different semantics defined for the ISO protocols, some minor changes were required in the socket interface to accommodate these semantics. The changes were made such that they were invisible to clients of other existing protocols. The ISO protocols also required extensive addition to the two-level routing tables provided by the kernel in 4.3BSD. The greatly expanded routing capabilities of 4.4BSD include arbitrary levels of routing with variable-length addresses and network masks. System Operation Bootstrapping mechanisms are used to start the system running. First, the 4.4BSD kernel must be loaded into the main memory of the processor. Once loaded, it must go through an initialization phase to set the hardware into a known state. Next, the kernel must do autoconfiguration, a process that finds and configures the peripherals that are attached to the processor. The system begins running in single-user mode while a start-up script does disk checks and starts the accounting and quota checking. Finally, the start-up script starts the general system services and brings up the system to full multiuser operation. During multiuser operation, processes wait for login requests on the terminal lines and network ports that have been configured for user access. When a login request is detected, a login process is spawned and user validation is done. When the login validation is successful, a login shell is created from which the user can run additional processes. References Accetta et al, 1986 Mach: A New Kernel Foundation for UNIX Development" M. Accetta R. Baron W. Bolosky D. Golub R. Rashid A. Tevanian M. Young 93-113 USENIX Association Conference Proceedings USENIX Association June 1986 Cheriton, 1988 The V Distributed System D. R. Cheriton 314-333 Comm ACM, 31, 3 March 1988 Ewens et al, 1985 Tunis: A Distributed Multiprocessor Operating System P. Ewens D. R. Blythe M. Funkenhauser R. C. Holt 247-254 USENIX Assocation Conference Proceedings USENIX Association June 1985 Gingell et al, 1987 Virtual Memory Architecture in SunOS R. Gingell J. Moran W. Shannon 81-94 USENIX Association Conference Proceedings USENIX Association June 1987 Kernighan & Pike, 1984 The UNIX Programming Environment B. W. Kernighan R. Pike Prentice-Hall
Englewood Cliffs NJ
1984 Macklem, 1994 The 4.4BSD NFS Implementation R. Macklem 6:1-14 4.4BSD System Manager's Manual O'Reilly & Associates, Inc.
Sebastopol CA
1994 McKusick & Karels, 1988 Design of a General Purpose Memory Allocator for the 4.3BSD UNIX Kernel M. K. McKusick M. J. Karels 295-304 USENIX Assocation Conference Proceedings USENIX Assocation June 1998 McKusick et al, 1994 Berkeley Software Architecture Manual, 4.4BSD Edition M. K. McKusick M. J. Karels S. J. Leffler W. N. Joy R. S. Faber 5:1-42 4.4BSD Programmer's Supplementary Documents O'Reilly & Associates, Inc.
Sebastopol CA
1994 Ritchie, 1988 Early Kernel Design private communication D. M. Ritchie March 1988 Rosenblum & Ousterhout, 1992 The Design and Implementation of a Log-Structured File System M. Rosenblum K. Ousterhout 26-52 ACM Transactions on Computer Systems, 10, 1 Association for Computing Machinery February 1992 Rozier et al, 1988 Chorus Distributed Operating Systems M. Rozier V. Abrossimov F. Armand I. Boule M. Gien M. Guillemont F. Herrmann C. Kaiser S. Langlois P. Leonard W. Neuhauser 305-370 USENIX Computing Systems, 1, 4 Fall 1988 Tevanian, 1987 Architecture-Independent Virtual Memory Management for Parallel and Distributed Environments: The Mach Approach Technical Report CMU-CS-88-106, A. Tevanian Department of Computer Science, Carnegie-Mellon University
Pittsburgh PA
December 1987 diff --git a/en_US.ISO8859-1/books/handbook/contrib/chapter.sgml b/en_US.ISO8859-1/books/handbook/contrib/chapter.sgml index ebfec31854..ef3c1d83d1 100644 --- a/en_US.ISO8859-1/books/handbook/contrib/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/contrib/chapter.sgml @@ -1,6357 +1,6357 @@ Contributing to FreeBSD Contributed by &a.jkh;. So you want to contribute something to FreeBSD? That is great! We can always use the help, and FreeBSD is one of those systems that relies on the contributions of its user base in order to survive. Your contributions are not only appreciated, they are vital to FreeBSD's continued growth! Contrary to what some people might also have you believe, you do not need to be a hot-shot programmer or a close personal friend of the FreeBSD core team in order to have your contributions accepted. The FreeBSD Project's development is done by a large and growing number of international contributors whose ages and areas of technical expertise vary greatly, and there is always more work to be done than there are people available to do it. Since the FreeBSD project is responsible for an entire operating system environment (and its installation) rather than just a kernel or a few scattered utilities, our TODO list also spans a very wide range of tasks, from documentation, beta testing and presentation to highly specialized types of kernel development. No matter what your skill level, there is almost certainly something you can do to help the project! Commercial entities engaged in FreeBSD-related enterprises are also encouraged to contact us. Need a special extension to make your product work? You will find us receptive to your requests, given that they are not too outlandish. Working on a value-added product? Please let us know! We may be able to work cooperatively on some aspect of it. The free software world is challenging a lot of existing assumptions about how software is developed, sold, and maintained throughout its life cycle, and we urge you to at least give it a second look. What is Needed The following list of tasks and sub-projects represents something of an amalgam of the various core team TODO lists and user requests we have collected over the last couple of months. Where possible, tasks have been ranked by degree of urgency. If you are interested in working on one of the tasks you see here, send mail to the coordinator listed by clicking on their names. If no coordinator has been appointed, maybe you would like to volunteer? High priority tasks The following tasks are considered to be urgent, usually because they represent something that is badly broken or sorely needed: 3-stage boot issues. Overall coordination: &a.hackers; Do WinNT compatible drive tagging so that the 3rd stage can provide an accurate mapping of BIOS geometries for disks. Filesystem problems. Overall coordination: &a.fs; Clean up and document the nullfs filesystem code. Coordinator: &a.eivind; Fix the union file system. Coordinator: &a.dg; Implement Int13 vm86 disk driver. Coordinator: &a.hackers; New bus architecture. Coordinator: &a.newbus; Port existing ISA drivers to new architecture. Move all interrupt-management code to appropriate parts of the bus drivers. Port PCI subsystem to new architecture. Coordinator: &a.dfr; Figure out the right way to handle removable devices and then use that as a substrate on which PC-Card and CardBus support can be implemented. Resolve the probe/attach priority issue once and for all. Move any remaining buses over to the new architecture. Kernel issues. Overall coordination: &a.hackers; Add more pro-active security infrastructure. Overall coordination: &a.security; Build something like Tripwire(TM) into the kernel, with a remote and local part. There are a number of cryptographic issues to getting this right; contact the coordinator for details. Coordinator: &a.eivind; Make the entire kernel use suser() instead of comparing to 0. It is presently using about half of each. Coordinator: &a.eivind; Split securelevels into different parts, to allow an administrator to throw away those privileges he can throw away. Setting the overall securelevel needs to have the same effect as now, obviously. Coordinator: &a.eivind; Make it possible to upload a list of allowed program to BPF, and then block BPF from accepting other programs. This would allow BPF to be used e.g. for DHCP, without allowing an attacker to start snooping the local network. Update the security checker script. We should at least grab all the checks from the other BSD derivatives, and add checks that a system with securelevel increased also have reasonable flags on the relevant parts. Coordinator: &a.eivind; Add authorization infrastructure to the kernel, to allow different authorization policies. Part of this could be done by modifying suser(). Coordinator: &a.eivind; Add code to the NFS layer so that you cannot chdir("..") out of an NFS partition. E.g., /usr is a UFS partition with /usr/src NFS exported. Now it is possible to use the NFS filehandle for /usr/src to get access to /usr. Medium priority tasks The following tasks need to be done, but not with any particular urgency: Full KLD based driver support/Configuration Manager. Write a configuration manager (in the 3rd stage boot?) that probes your hardware in a sane manner, keeps only the KLDs required for your hardware, etc. PCMCIA/PCCARD. Coordinators: &a.msmith; and &a.imp; Documentation! Reliable operation of the pcic driver (needs testing). Recognizer and handler for sio.c (mostly done). Recognizer and handler for ed.c (mostly done). Recognizer and handler for ep.c (mostly done). User-mode recognizer and handler (partially done). Advanced Power Management. Coordinators: &a.msmith; and &a.phk; APM sub-driver (mostly done). IDE/ATA disk sub-driver (partially done). syscons/pcvt sub-driver. Integration with the PCMCIA/PCCARD drivers (suspend/resume). Low priority tasks The following tasks are purely cosmetic or represent such an investment of work that it is not likely that anyone will get them done anytime soon: The first N items are from Terry Lambert terry@lambert.org NetWare Server (protected mode ODI driver) loader and sub-services to allow the use of ODI card drivers supplied with network cards. The same thing for NDIS drivers and NetWare SCSI drivers. An "upgrade system" option that works on Linux boxes instead of just previous rev FreeBSD boxes. Symmetric Multiprocessing with kernel preemption (requires kernel preemption). A concerted effort at support for portable computers. This is somewhat handled by changing PCMCIA bridging rules and power management event handling. But there are things like detecting internal v.s.. external display and picking a different screen resolution based on that fact, not spinning down the disk if the machine is in dock, and allowing dock-based cards to disappear without affecting the machines ability to boot (same issue for PCMCIA). Smaller tasks Most of the tasks listed in the previous sections require either a considerable investment of time or an in-depth knowledge of the FreeBSD kernel (or both). However, there are also many useful tasks which are suitable for "weekend hackers", or people without programming skills. If you run FreeBSD-current and have a good Internet connection, there is a machine current.FreeBSD.org which builds a full release once a day — every now and again, try and install the latest release from it and report any failures in the process. Read the freebsd-bugs mailing list. There might be a problem you can comment constructively on or with patches you can test. Or you could even try to fix one of the problems yourself. Read through the FAQ and Handbook periodically. If anything is badly explained, out of date or even just completely wrong, let us know. Even better, send us a fix (SGML is not difficult to learn, but there is no objection to ASCII submissions). Help translate FreeBSD documentation into your native language (if not already available) — just send an email to &a.doc; asking if anyone is working on it. Note that you are not committing yourself to translating every single FreeBSD document by doing this — in fact, the documentation most in need of translation is the installation instructions. Read the freebsd-questions mailing list and &ng.misc occasionally (or even regularly). It can be very satisfying to share your expertise and help people solve their problems; sometimes you may even learn something new yourself! These forums can also be a source of ideas for things to work on. If you know of any bug fixes which have been successfully applied to -current but have not been merged into -stable after a decent interval (normally a couple of weeks), send the committer a polite reminder. Move contributed software to src/contrib in the source tree. Make sure code in src/contrib is up to date. Look for year 2000 bugs (and fix any you find!) Build the source tree (or just part of it) with extra warnings enabled and clean up the warnings. Fix warnings for ports which do deprecated things like using gets() or including malloc.h. If you have contributed any ports, send your patches back to the original author (this will make your life easier when they bring out the next version) Suggest further tasks for this list! Work through the PR database The FreeBSD PR list shows all the current active problem reports and requests for enhancement that have been submitted by FreeBSD users. Look through the open PRs, and see if anything there takes your interest. Some of these might be very simple tasks, that just need an extra pair of eyes to look over them and confirm that the fix in the PR is a good one. Others might be much more complex. Start with the PRs that have not been assigned to anyone else, but if one them is assigned to someone else, but it looks like something you can handle, e-mail the person it is assigned to and ask if you can work on it—they might already have a patch ready to be tested, or further ideas that you can discuss with them. How to Contribute Contributions to the system generally fall into one or more of the following 6 categories: Bug reports and general commentary An idea or suggestion of general technical interest should be mailed to the &a.hackers;. Likewise, people with an interest in such things (and a tolerance for a high volume of mail!) may subscribe to the hackers mailing list by sending mail to &a.majordomo;. See mailing lists for more information about this and other mailing lists. If you find a bug or are submitting a specific change, please report it using the &man.send-pr.1; program or its WEB-based equivalent. Try to fill-in each field of the bug report. Unless they exceed 65KB, include any patches directly in the report. When including patches, do not use cut-and-paste because cut-and-paste turns tabs into spaces and makes them unusable. Consider compressing patches and using &man.uuencode.1; if they exceed 20KB. Upload very large submissions to ftp.FreeBSD.org:/pub/FreeBSD/incoming/. After filing a report, you should receive confirmation along with a tracking number. Keep this tracking number so that you can update us with details about the problem by sending mail to bug-followup@FreeBSD.org. Use the number as the message subject, e.g. "Re: kern/3377". Additional information for any bug report should be submitted this way. If you do not receive confirmation in a timely fashion (3 days to a week, depending on your email connection) or are, for some reason, unable to use the &man.send-pr.1; command, then you may ask someone to file it for you by sending mail to the &a.bugs;. Changes to the documentation Changes to the documentation are overseen by the &a.doc;. Send submissions and changes (even small ones are welcome!) using send-pr as described in Bug Reports and General Commentary. Changes to existing source code An addition or change to the existing source code is a somewhat trickier affair and depends a lot on how far out of date you are with the current state of the core FreeBSD development. There is a special on-going release of FreeBSD known as FreeBSD-current which is made available in a variety of ways for the convenience of developers working actively on the system. See Staying current with FreeBSD for more information about getting and using FreeBSD-current. Working from older sources unfortunately means that your changes may sometimes be too obsolete or too divergent for easy re-integration into FreeBSD. Chances of this can be minimized somewhat by subscribing to the &a.announce; and the &a.current; lists, where discussions on the current state of the system take place. Assuming that you can manage to secure fairly up-to-date sources to base your changes on, the next step is to produce a set of diffs to send to the FreeBSD maintainers. This is done with the &man.diff.1; command, with the context diff form being preferred. For example: &prompt.user; diff -c oldfile newfile or &prompt.user; diff -c -r olddir newdir would generate such a set of context diffs for the given source file or directory hierarchy. See the man page for &man.diff.1; for more details. Once you have a set of diffs (which you may test with the &man.patch.1; command), you should submit them for inclusion with FreeBSD. Use the &man.send-pr.1; program as described in Bug Reports and General Commentary. Do not just send the diffs to the &a.hackers; or they will get lost! We greatly appreciate your submission (this is a volunteer project!); because we are busy, we may not be able to address it immediately, but it will remain in the pr database until we do. If you feel it appropriate (e.g. you have added, deleted, or renamed files), bundle your changes into a tar file and run the &man.uuencode.1; program on it. Shar archives are also welcome. If your change is of a potentially sensitive nature, e.g. you are unsure of copyright issues governing its further distribution or you are simply not ready to release it without a tighter review first, then you should send it to &a.core; directly rather than submitting it with &man.send-pr.1;. The core mailing list reaches a much smaller group of people who do much of the day-to-day work on FreeBSD. Note that this group is also very busy and so you should only send mail to them where it is truly necessary. Please refer to man 9 intro and man 9 style for some information on coding style. We would appreciate it if you were at least aware of this information before submitting code. New code or major value-added packages In the case of a significant contribution of a large body work, or the addition of an important new feature to FreeBSD, it becomes almost always necessary to either send changes as uuencoded tar files or upload them to a web or FTP site for other people to access. If you do not have access to a web or FTP site, ask on an appropriate FreeBSD mailing list for someone to host the changes for you. When working with large amounts of code, the touchy subject of copyrights also invariably comes up. Acceptable copyrights for code included in FreeBSD are: The BSD copyright. This copyright is most preferred due to its no strings attached nature and general attractiveness to commercial enterprises. Far from discouraging such commercial use, the FreeBSD Project actively encourages such participation by commercial interests who might eventually be inclined to invest something of their own into FreeBSD. The GNU Public License, or GPL. This license is not quite as popular with us due to the amount of extra effort demanded of anyone using the code for commercial purposes, but given the sheer quantity of GPL'd code we currently require (compiler, assembler, text formatter, etc) it would be silly to refuse additional contributions under this license. Code under the GPL also goes into a different part of the tree, that being /sys/gnu or /usr/src/gnu, and is therefore easily identifiable to anyone for whom the GPL presents a problem. Contributions coming under any other type of copyright must be carefully reviewed before their inclusion into FreeBSD will be considered. Contributions for which particularly restrictive commercial copyrights apply are generally rejected, though the authors are always encouraged to make such changes available through their own channels. To place a BSD-style copyright on your work, include the following text at the very beginning of every source code file you wish to protect, replacing the text between the %% with the appropriate information. Copyright (c) %%proper_years_here%% %%your_name_here%%, %%your_state%% %%your_zip%%. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY %%your_name_here%% ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL %%your_name_here%% BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. $Id$ For your convenience, a copy of this text can be found in /usr/share/examples/etc/bsd-style-copyright. Money, Hardware or Internet access We are always very happy to accept donations to further the cause of the FreeBSD Project and, in a volunteer effort like ours, a little can go a long way! Donations of hardware are also very important to expanding our list of supported peripherals since we generally lack the funds to buy such items ourselves. <anchor id="donations">Donating funds While the FreeBSD Project is not a 501(c)(3) (charitable) corporation and hence cannot offer special tax incentives for any donations made, any such donations will be gratefully accepted on behalf of the project by FreeBSD, Inc. FreeBSD, Inc. was founded in early 1995 by &a.jkh; and &a.dg; with the goal of furthering the aims of the FreeBSD Project and giving it a minimal corporate presence. Any and all funds donated (as well as any profits that may eventually be realized by FreeBSD, Inc.) will be used exclusively to further the project's goals. Please make any checks payable to FreeBSD, Inc., sent in care of the following address:
FreeBSD, Inc. c/o Jordan Hubbard 4041 Pike Lane, Suite F Concord CA, 94520
(currently using the BSDi address until a PO box can be opened) Wire transfers may also be sent directly to:
Bank Of America Concord Main Office P.O. Box 37176 San Francisco CA, 94137-5176 Routing #: 121-000-358 Account #: 01411-07441 (FreeBSD, Inc.)
Any correspondence related to donations should be sent to &a.jkh, either via email or to the FreeBSD, Inc. postal address given above. If you do not wish to be listed in our donors section, please specify this when making your donation. Thanks! Donating hardware Donations of hardware in any of the 3 following categories are also gladly accepted by the FreeBSD Project: General purpose hardware such as disk drives, memory or complete systems should be sent to the FreeBSD, Inc. address listed in the donating funds section. Hardware for which ongoing compliance testing is desired. We are currently trying to put together a testing lab of all components that FreeBSD supports so that proper regression testing can be done with each new release. We are still lacking many important pieces (network cards, motherboards, etc) and if you would like to make such a donation, please contact &a.dg; for information on which items are still required. Hardware currently unsupported by FreeBSD for which you would like to see such support added. Please contact the &a.core; before sending such items as we will need to find a developer willing to take on the task before we can accept delivery of new hardware. Donating Internet access We can always use new mirror sites for FTP, WWW or cvsup. If you would like to be such a mirror, please contact the FreeBSD project administrators hubs@FreeBSD.org for more information. Donors Gallery The FreeBSD Project is indebted to the following donors and would like to publicly thank them here! Contributors to the central server project: The following individuals and businesses made it possible for the FreeBSD Project to build a new central server machine to eventually replace freefall.FreeBSD.org by donating the following items: &a.mbarkah and his employer, Hemisphere Online, donated a Pentium Pro (P6) 200Mhz CPU ASA Computers donated a Tyan 1662 motherboard. Joe McGuckin joe@via.net of ViaNet Communications donated a Kingston ethernet controller. Jack O'Neill jack@diamond.xtalwind.net donated an NCR 53C875 SCSI controller card. Ulf Zimmermann ulf@Alameda.net of Alameda Networks donated 128MB of memory, a 4 Gb disk drive and the case. Direct funding: The following individuals and businesses have generously contributed direct funding to the project: Annelise Anderson ANDRSN@HOOVER.STANFORD.EDU &a.dillon Blue Mountain Arts Epilogue Technology Corporation &a.sef Global Technology Associates, Inc Don Scott Wilde Gianmarco Giovannelli gmarco@masternet.it Josef C. Grosch joeg@truenorth.org Robert T. Morris &a.chuckr Kenneth P. Stox ken@stox.sa.enteract.com of Imaginary Landscape, LLC. Dmitry S. Kohmanyuk dk@dog.farm.org Laser5 of Japan (a portion of the profits from sales of their various FreeBSD CDROMs). Fuki Shuppan Publishing Co. donated a portion of their profits from Hajimete no FreeBSD (FreeBSD, Getting started) to the FreeBSD and XFree86 projects. ASCII Corp. donated a portion of their profits from several FreeBSD-related books to the FreeBSD project. Yokogawa Electric Corp has generously donated significant funding to the FreeBSD project. BuffNET Pacific Solutions Siemens AG - via Andre - Albsmeier + via andre.albsmeier@mchp.siemens.de">Andre + Albsmeier - Chris Silva + ras@interaccess.com">Chris Silva Hardware contributors: The following individuals and businesses have generously contributed hardware for testing and device driver development/support: BSDi for providing the Pentium P5-90 and 486/DX2-66 EISA/VL systems that are being used for our development work, to say nothing of the network access and other donations of hardware resources. TRW Financial Systems, Inc. provided 130 PCs, three 68 GB file servers, twelve Ethernets, two routers and an ATM switch for debugging the diskless code. Dermot McDonnell donated the Toshiba XM3401B CDROM drive currently used in freefall. &a.chuck; contributed his floppy tape streamer for experimental work. Larry Altneu larry@ALR.COM, and &a.wilko;, provided Wangtek and Archive QIC-02 tape drives in order to improve the wt driver. Ernst Winter ewinter@lobo.muc.de contributed a 2.88 MB floppy drive to the project. This will hopefully increase the pressure for rewriting the floppy disk driver. ;-) Tekram Technologies sent one each of their DC-390, DC-390U and DC-390F FAST and ULTRA SCSI host adapter cards for regression testing of the NCR and AMD drivers with their cards. They are also to be applauded for making driver sources for free operating systems available from their FTP server ftp://ftp.tekram.com/scsi/FreeBSD/. Larry M. Augustin contributed not only a Symbios Sym8751S SCSI card, but also a set of data books, including one about the forthcoming Sym53c895 chip with Ultra-2 and LVD support, and the latest programming manual with information on how to safely use the advanced features of the latest Symbios SCSI chips. Thanks a lot! Christoph Kukulies kuku@FreeBSD.org donated an FX120 12 speed Mitsumi CDROM drive for IDE CDROM driver development. Special contributors: BSDi (formerly Walnut Creek CDROM) has donated almost more than we can say (see the history document for more details). In particular, we would like to thank them for the original hardware used for freefall.FreeBSD.org, our primary development machine, and for thud.FreeBSD.org, a testing and build box. We are also indebted to them for funding various contributors over the years and providing us with unrestricted use of their T1 connection to the Internet. The interface business GmbH, Dresden has been patiently supporting &a.joerg; who has often preferred FreeBSD work over paid work, and used to fall back to their (quite expensive) EUnet Internet connection whenever his private connection became too slow or flaky to work with it... Berkeley Software Design, Inc. has contributed their DOS emulator code to the remaining BSD world, which is used in the doscmd command. Core Team Alumni The following people were members of the FreeBSD core team during the periods indicated. We thank them for their past efforts in the service of the FreeBSD project. In rough chronological order: &a.ache (1993 - 2000) &a.jmb (1993 - 2000) &a.bde (1992 - 2000) &a.gibbs (1993 - 2000) &a.rich (1994 - 2000) &a.phk (1992 - 2000) &a.gpalmer (1993 - 2000) &a.sos (1993 - 2000) &a.wollman (1993 - 2000) &a.joerg (1995 - 2000) &a.jdp (1997 - 2000) &a.guido (1995 - 1999) &a.dyson (1993 - 1998) &a.nate (1992 - 1996) &a.rgrimes (1992 - 1995) Andreas Schulz (1992 - 1995) &a.csgr (1993 - 1995) &a.paul (1992 - 1995) &a.smace (1993 - 1994) Andrew Moore (1993 - 1994) Christoph Robitschko (1993 - 1994) J. T. Conklin (1992 - 1993) Development Team Alumni The following people were members of the FreeBSD development team during the periods indicated. We thank them for their past efforts in the service of the FreeBSD project. In rough chronological order: &a.tedm (???? - 2000) &a.karl (???? - 2000) &a.gclarkii (1993 - 2000) &a.jraynard (???? - 2000) &a.jgreco (???? - 1999) &a.ats (???? - 1999) Jamil Weatherby (1997 - 1999) meganm (???? - 1998) &a.dyson (???? - 1998) Amancio Hasty (1997 - 1998) Drew Derbyshire (1997 - 1998) Derived Software Contributors This software was originally derived from William F. Jolitz's 386BSD release 0.1, though almost none of the original 386BSD specific code remains. This software has been essentially re-implemented from the 4.4BSD-Lite release provided by the Computer Science Research Group (CSRG) at the University of California, Berkeley and associated academic contributors. There are also portions of NetBSD and OpenBSD that have been integrated into FreeBSD as well, and we would therefore like to thank all the contributors to NetBSD and OpenBSD for their work. Additional FreeBSD Contributors (in alphabetical order by first name): ABURAYA Ryushirou rewsirow@ff.iij4u.or.jp AMAGAI Yoshiji amagai@nue.org Aaron Bornstein aaronb@j51.com Aaron Smith aaron@mutex.org Achim Patzner ap@noses.com Ada T Lim ada@bsd.org Adam Baran badam@mw.mil.pl Adam Glass glass@postgres.berkeley.edu Adam Herzog adam@herzogdesigns.com Adam McDougall mcdouga9@egr.msu.edu Adam Strohl troll@digitalspark.net Adoal Xu adoal@iname.com Adrian Colley aecolley@ois.ie Adrian Hall ahall@mirapoint.com Adrian Mariano adrian@cam.cornell.edu Adrian Steinmann ast@marabu.ch Adrian T. Filipi-Martin atf3r@agate.cs.virginia.edu Ajit Thyagarajan unknown Akio Morita amorita@meadow.scphys.kyoto-u.ac.jp Akira SAWADA unknown Akira Watanabe akira@myaw.ei.meisei-u.ac.jp Akito Fujita fujita@zoo.ncl.omron.co.jp Alain Kalker A.C.P.M.Kalker@student.utwente.nl Alan Bawden alan@curry.epilogue.com Alec Wolman wolman@cs.washington.edu Aled Morris aledm@routers.co.uk Aleksandr A Babaylov .@babolo.ru Alex G. Bulushev bag@demos.su Alex D. Chen dhchen@Canvas.dorm7.nccu.edu.tw Alex Le Heux alexlh@funk.org Alex Kapranoff kappa@zombie.antar.bryansk.ru Alex Perel veers@disturbed.net Alex Semenyaka alex@rinet.ru Alex Varju varju@webct.com Alex Zepeda garbanzo@hooked.net Alexander B. Povolotsky tarkhil@mgt.msk.ru Alexander Gelfenbain mail@gelf.com Alexander Leidinger netchild@wurzelausix.CS.Uni-SB.DE Alexandre Peixoto alexandref@tcoip.com.br Alexandre Snarskii snar@paranoia.ru Alistair G. Crooks agc@uts.amdahl.com Allan Bowhill bowhill@bowhill.vservers.com Allan Saddi asaddi@philosophysw.com Allen Campbell allenc@verinet.com Amakawa Shuhei amakawa@hoh.t.u-tokyo.ac.jp Amancio Hasty hasty@star-gate.com Amir Farah amir@comtrol.com Amir Shalem amir@boom.org.il Amy Baron amee@beer.org The Anarcat beaupran@iro.umontreal.ca Anatoly A. Orehovsky tolik@mpeks.tomsk.su Anatoly Vorobey mellon@pobox.com Anders Andersson anders@codefactory.se Anders Nordby anders@fix.no Anders Thulin Anders.X.Thulin@telia.se Andras Olah olah@cs.utwente.nl Andre Albsmeier Andre.Albsmeier@mchp.siemens.de Andre Goeree abgoeree@uwnet.nl Andre Oppermann andre@pipeline.ch Andreas Haakh ah@alman.robin.de Andreas Kohout shanee@rabbit.augusta.de Andreas Lohr andreas@marvin.RoBIN.de Andreas Schulz unknown Andreas Wetzel mickey@deadline.snafu.de Andreas Wrede andreas@planix.com Andres Vega Garcia unknown Andrew Atrens atreand@statcan.ca Andrew Boothman andrew@cream.org Andrew Gillham gillham@andrews.edu Andrew Gordon andrew.gordon@net-tel.co.uk Andrew Herbert andrew@werple.apana.org.au Andrew J. Korty ajk@purdue.edu Andrew L. Moore alm@mclink.com Andrew L. Neporada andrew@chg.ru Andrew McRae amcrae@cisco.com Andrew Stevenson andrew@ugh.net.au Andrew Timonin tim@pool1.convey.ru Andrew V. Stesin stesin@elvisti.kiev.ua Andrew Webster awebster@dataradio.com Andrey Novikov andrey@novikov.com Andrey Simonenko simon@comsys.ntu-kpi.kiev.ua Andrey Tchoritch andy@venus.sympad.net Andy Farkas andyf@speednet.com.au Andy Valencia ajv@csd.mot.com Andy Whitcroft andy@sarc.city.ac.uk Angelo Turetta ATuretta@stylo.it Anthony C. Chavez magus@xmission.com Anthony Yee-Hang Chan yeehang@netcom.com Anton N. Bruesov antonz@library.ntu-kpi.kiev.ua Anton Voronin anton@urc.ac.ru Antti Kaipila anttik@iki.fi arci vega@sophia.inria.fr Are Bryne are.bryne@communique.no Ari Suutari ari@suutari.iki.fi Arindum Mukerji rmukerji@execpc.com Arjan de Vet devet@IAEhv.nl Arne Henrik Juul arnej@Lise.Unit.NO Arun Sharma adsharma@sharmas.dhs.org Arnaud S. Launay asl@launay.org Ask Bjoern Hansen ask@valueclick.com Atsushi Furuta furuta@sra.co.jp Atsushi Murai amurai@spec.co.jp Atushi Sakauchi sakauchi@yamame.to Bakul Shah bvs@bitblocks.com Barry Bierbauch pivrnec@vszbr.cz Barry Lustig barry@ictv.com Ben Hutchinson benhutch@xfiles.org.uk Ben Jackson unknown Ben Walter bwalter@itachi.swcp.com Benjamin Lewis bhlewis@gte.net Berend de Boer berend@pobox.com Bernd Rosauer br@schiele-ct.de Bill Kish kish@osf.org Bill Trost trost@cloud.rain.com Blaz Zupan blaz@amis.net Bob Van Valzah Bob@whitebarn.com Bob Wilcox bob@obiwan.uucp Bob Willcox bob@luke.pmr.com Boris Staeblow balu@dva.in-berlin.de Boyd Faulkner faulkner@mpd.tandem.com Boyd R. Faulkner faulkner@asgard.bga.com Brad Chapman chapmanb@arches.uga.edu Brad Hendrickse bradh@uunet.co.za Brad Karp karp@eecs.harvard.edu Bradley Dunn bradley@dunn.org Brad Jones brad@kazrak.com Brandon Fosdick bfoz@glue.umd.edu Brandon Gillespie brandon@roguetrader.com &a.wlloyd Brent J. Nordquist bjn@visi.com Brett Lymn blymn@mulga.awadi.com.AU Brett Taylor brett@peloton.runet.edu Brian Campbell brianc@pobox.com Brian Clapper bmc@willscreek.com Brian Cully shmit@kublai.com Brian Handy handy@lambic.space.lockheed.com Brian Litzinger brian@MediaCity.com Brian McGovern bmcgover@cisco.com Brian Moore ziff@houdini.eecs.umich.edu Brian R. Haug haug@conterra.com Brian Tao taob@risc.org Brion Moss brion@queeg.com Bruce Albrecht bruce@zuhause.mn.org Bruce Gingery bgingery@gtcs.com Bruce J. Keeler loodvrij@gridpoint.com Bruce Murphy packrat@iinet.net.au Bruce Walter walter@fortean.com Carey Jones mcj@acquiesce.org Carl Fongheiser cmf@netins.net Carl Mascott cmascott@world.std.com Casper casper@acc.am Castor Fu castor@geocast.com Chain Lee chain@110.net Charles Hannum mycroft@ai.mit.edu Charles Henrich henrich@msu.edu Charles Mott cmott@scientech.com Charles Owens owensc@enc.edu &a.chern; Chet Ramey chet@odin.INS.CWRU.Edu Chia-liang Kao clkao@CirX.ORG Chiharu Shibata chi@bd.mbn.or.jp Chip Norkus unknown Chris Csanady cc@tarsier.ca.sandia.gov Chris Dabrowski chris@vader.org Chris Dillon cdillon@wolves.k12.mo.us Chris Shenton cshenton@angst.it.hq.nasa.gov Chris Stenton jacs@gnome.co.uk Chris Timmons skynyrd@opus.cts.cwu.edu Chris Torek torek@ee.lbl.gov Christian Gusenbauer cg@fimp01.fim.uni-linz.ac.at Christian Haury Christian.Haury@sagem.fr Christian Weisgerber naddy@mips.inka.de Christoph P. Kukulies kuku@FreeBSD.org Christoph Robitschko chmr@edvz.tu-graz.ac.at Christoph Weber-Fahr wefa@callcenter.systemhaus.net Christopher G. Demetriou cgd@postgres.berkeley.edu Christopher N. Harrell cnh@ivmg.net Christopher Preston rbg@gayteenresource.org Christopher T. Johnson cjohnson@neunacht.netgsi.com Chrisy Luke chrisy@flix.net Chuck Hein chein@cisco.com Cliff Rowley dozprompt@onsea.com Colman Reilly careilly@tcd.ie Conrad Sabatier conrads@home.com Coranth Gryphon gryphon@healer.com Cornelis van der Laan nils@guru.ims.uni-stuttgart.de Cove Schneider cove@brazil.nbn.com Craig Leres leres@ee.lbl.gov Craig Loomis unknown Craig Metz cmetz@inner.net Craig Spannring cts@internetcds.com Craig Struble cstruble@vt.edu Cristian Ferretti cfs@riemann.mat.puc.cl Curt Mayer curt@toad.com Cy Schubert cschuber@uumail.gov.bc.ca Cyrille Lefevre clefevre@citeweb.net Cyrus Rahman cr@jcmax.com Dai Ishijima ishijima@tri.pref.osaka.jp Daisuke Watanabe NU7D-WTNB@asahi-net.or.jp Damian Hamill damian@cablenet.net Dan Cross tenser@spitfire.ecsel.psu.edu Dan Langille dan@freebsddiary.org Dan Lukes dan@obluda.cz Dan Nelson dnelson@emsphone.com Dan Papasian bugg@bugg.strangled.net Dan Piponi wmtop@tanelorn.demon.co.uk Dan Walters hannibal@cyberstation.net Daniel Hagan dhagan@cs.vt.edu Daniel O'Connor doconnor@gsoft.com.au Daniel Poirot poirot@aio.jsc.nasa.gov Daniel Rock rock@cs.uni-sb.de Daniel W. McRobb dwm@caimis.com Danny Egen unknown Danny J. Zerkel dzerkel@phofarm.com Dave Adkins adkin003@tc.umn.edu Dave Andersen angio@aros.net Dave Blizzard dblizzar@sprynet.com Dave Bodenstab imdave@synet.net Dave Burgess burgess@hrd769.brooks.af.mil Dave Chapeskie dchapes@ddm.on.ca Dave Cornejo dave@dogwood.com Dave Edmondson davided@sco.com Dave Glowacki dglo@ssec.wisc.edu Dave Marquardt marquard@austin.ibm.com Dave Tweten tweten@FreeBSD.org David A. Adkins adkin003@tc.umn.edu David A. Bader dbader@eece.unm.edu David Borman dab@bsdi.com David Dawes dawes@XFree86.org David Filo unknown David Holland dholland@eecs.harvard.edu David Holloway daveh@gwythaint.tamis.com David Horwitt dhorwitt@ucsd.edu David Hovemeyer daveho@infocom.com David Jones dej@qpoint.torfree.net David Kelly dkelly@tomcat1.tbe.com David Kulp dkulp@neomorphic.com David L. Nugent davidn@blaze.net.au David Leonard d@scry.dstc.edu.au David Muir Sharnoff muir@idiom.com David S. Miller davem@jenolan.rutgers.edu David Sugar dyfet@gnu.org David Wolfskill dhw@whistle.com Dean Gaudet dgaudet@arctic.org Dean Huxley dean@fsa.ca Denis Fortin unknown Denis Shaposhnikov dsh@vlink.ru Dennis Glatting dennis.glatting@software-munitions.com Denton Gentry denny1@home.com der Mouse mouse@Collatz.McRCIM.McGill.EDU Derek Inksetter derek@saidev.com DI. Christian Gusenbauer cg@scotty.edvz.uni-linz.ac.at Dirk Keunecke dk@panda.rhein-main.de Dirk Nehrling nerle@pdv.de Dishanker Rajakulendren draj@oceanfree.net Dmitry Khrustalev dima@xyzzy.machaon.ru Dmitry Kohmanyuk dk@farm.org Dom Mitchell dom@myrddin.demon.co.uk Domas Mituzas midom@dammit.lt Dominik Brettnacher domi@saargate.de Dominik Rothert dr@domix.de Don Croyle croyle@gelemna.ft-wayne.in.us Donn Miller dmmiller@cvzoom.net Dan Pelleg dpelleg+unison@cs.cmu.edu &a.whiteside; Don Morrison dmorrisn@u.washington.edu Don Yuniskis dgy@rtd.com Donald Maddox dmaddox@conterra.com Douglas Ambrisko ambrisko@whistle.com Douglas Carmichael dcarmich@mcs.com Douglas Crosher dtc@scrooge.ee.swin.oz.au Drew Derbyshire ahd@kew.com Dustin Sallings dustin@spy.net Eckart "Isegrim" Hofmann Isegrim@Wunder-Nett.org Ed Gold vegold01@starbase.spd.louisville.edu Ed Hudson elh@p5.spnet.com Edward Chuang edwardc@firebird.org.tw Edward Wang edward@edcom.com Edwin Groothus edwin@nwm.wan.philips.com Edwin Mons e@ik.nu Ege Rekk aagero@aage.priv.no Eiji-usagi-MATSUmoto usagi@clave.gr.jp Eike Bernhardt eike.bernhardt@gmx.de ELISA Font Project Elmar Bartel bartel@informatik.tu-muenchen.de Eoin Lawless eoin@maths.tcd.ie Eric A. Griff eagriff@global2000.net Eric Blood eblood@cs.unr.edu Eric D. Futch efutch@nyct.net Eric J. Haug ejh@slustl.slu.edu Eric J. Schwertfeger eric@cybernut.com Eric L. Hernes erich@lodgenet.com Eric P. Scott eps@sirius.com Eric Sprinkle eric@ennovatenetworks.com Erich Stefan Boleyn erich@uruk.org Erich Zigler erich@tacni.net Erik H. Bakke erikhb@bgnett.no Erik E. Rantapaa rantapaa@math.umn.edu Erik H. Moe ehm@cris.com Ernst de Haan ernst@heinz.jollem.com Ernst Winter ewinter@lobo.muc.de Espen Skoglund esk@ira.uka.de Eugene M. Kim astralblue@usa.net Eugene Radchenko genie@qsar.chem.msu.su Eugeny Kuzakov CoreDumped@coredumped.null.ru Evan Champion evanc@synapse.net Faried Nawaz fn@Hungry.COM Flemming Jacobsen fj@tfs.com Fong-Ching Liaw fong@juniper.net Francis M J Hsieh mjshieh@life.nthu.edu.tw Francisco Reyes fjrm@yahoo.com Frank Bartels knarf@camelot.de Frank Chen Hsiung Chan frankch@waru.life.nthu.edu.tw Frank Durda IV uhclem@nemesis.lonestar.org Frank MacLachlan fpm@n2.net Frank Nobis fn@Radio-do.de Frank ten Wolde franky@pinewood.nl Frank van der Linden frank@fwi.uva.nl Frank Volf volf@oasis.IAEhv.nl Fred Cawthorne fcawth@jjarray.umn.edu Fred Gilham gilham@csl.sri.com Fred Templin templin@erg.sri.com Frederick Earl Gray fgray@rice.edu FUJIMOTO Kensaku fujimoto@oscar.elec.waseda.ac.jp FURUSAWA Kazuhisa furusawa@com.cs.osakafu-u.ac.jp &a.stanislav; Gabor Kincses gabor@acm.org Gabor Zahemszky zgabor@CoDe.hu Gareth McCaughan gjm11@dpmms.cam.ac.uk Gary A. Browning gab10@griffcd.amdahl.com Gary Howland gary@hotlava.com Gary J. garyj@rks32.pcs.dec.com Gary Kline kline@thought.org Gaspar Chilingarov nightmar@lemming.acc.am Gea-Suan Lin gsl@tpts4.seed.net.tw Gene Raytsin pal@paladin7.net Geoff Rehmet csgr@alpha.ru.ac.za Georg Wagner georg.wagner@ubs.com Gianlorenzo Masini masini@uniroma3.it Gianmarco Giovannelli gmarco@giovannelli.it Gil Kloepfer Jr. gil@limbic.ssdl.com Gilad Rom rom_glsa@ein-hashofet.co.il Giles Lean giles@nemeton.com.au Ginga Kawaguti ginga@amalthea.phys.s.u-tokyo.ac.jp Giorgos Keramidas keramida@ceid.upatras.gr Glen Foster gfoster@gfoster.com Glenn Johnson gljohns@bellsouth.net Godmar Back gback@facility.cs.utah.edu Goran Hammarback goran@astro.uu.se Gord Matzigkeit gord@enci.ucalgary.ca Gordon Greeff gvg@uunet.co.za Graham Wheeler gram@cdsec.com Greg A. Woods woods@zeus.leitch.com Greg Ansley gja@ansley.com Greg Robinson greg@rosevale.com.au Greg Troxel gdt@ir.bbn.com Greg Ungerer gerg@stallion.oz.au Gregory Bond gnb@itga.com.au Gregory D. Moncreaff moncrg@bt340707.res.ray.com Guy Harris guy@netapp.com Guy Helmer ghelmer@cs.iastate.edu HAMADA Naoki hamada@astec.co.jp Hannu Savolainen hannu@voxware.pp.fi Hans Huebner hans@artcom.de Hans Petter Bieker zerium@webindex.no Hans Zuidam hans@brandinnovators.com Harlan Stenn Harlan.Stenn@pfcs.com Harold Barker hbarker@dsms.com Harry Newton harry_newton@telinco.co.uk Havard Eidnes Havard.Eidnes@runit.sintef.no Heikki Suonsivu hsu@cs.hut.fi Heiko W. Rupp unknown Helmut F. Wirth hfwirth@ping.at Henrik Vestergaard Draboel hvd@terry.ping.dk Herb Peyerl hpeyerl@NetBSD.org Hideaki Ohmon ohmon@tom.sfc.keio.ac.jp Hidekazu Kuroki hidekazu@cs.titech.ac.jp Hideki Yamamoto hyama@acm.org Hideyuki Suzuki hideyuki@sat.t.u-tokyo.ac.jp Hirayama Issei iss@mail.wbs.ne.jp Hiroaki Sakai sakai@miya.ee.kagu.sut.ac.jp Hiroharu Tamaru tamaru@ap.t.u-tokyo.ac.jp Hironori Ikura hikura@kaisei.org Hiroshi Nishikawa nis@pluto.dti.ne.jp Hiroya Tsubakimoto unknown Holger Lamm holger@eit.uni-kl.de Holger Veit Holger.Veit@gmd.de Holm Tiffe holm@geophysik.tu-freiberg.de HONDA Yasuhiro honda@kashio.info.mie-u.ac.jp Horance Chou horance@freedom.ie.cycu.edu.tw Horihiro Kumagai kuma@jp.FreeBSD.org HOSOBUCHI Noriyuki hoso@buchi.tama.or.jp HOTARU-YA hotaru@tail.net Hr.Ladavac lada@ws2301.gud.siemens.co.at Hubert Feyrer hubertf@NetBSD.ORG Hugh F. Mahon hugh@nsmdserv.cnd.hp.com Hugh Mahon h_mahon@fc.hp.com Hung-Chi Chu hcchu@r350.ee.ntu.edu.tw Ian Holland ianh@tortuga.com.au Ian Struble ian@broken.net Ian Vaudrey i.vaudrey@bigfoot.com Igor Khasilev igor@jabber.paco.odessa.ua Igor Roshchin str@giganda.komkon.org Igor Serikov bt@turtle.pangeatech.com Igor Sviridov siac@ua.net Igor Vinokurov igor@zynaps.ru Ikuo Nakagawa ikuo@isl.intec.co.jp Ilia Chipitsine ilia@jane.cgu.chel.su Ilya V. Komarov mur@lynx.ru IMAI Takeshi take-i@ceres.dti.ne.jp IMAMURA Tomoaki tomoak-i@is.aist-nara.ac.jp Itsuro Saito saito@miv.t.u-tokyo.ac.jp IWASHITA Yoji shuna@pop16.odn.ne.jp J. Bryant jbryant@argus.flash.net J. David Lowe lowe@saturn5.com J. Han hjh@photino.com J. Hawk jhawk@MIT.EDU J.T. Conklin jtc@cygnus.com Jack jack@zeus.xtalwind.net Jacob Bohn Lorensen jacob@jblhome.ping.mk Jagane D Sundar jagane@netcom.com Jake Hamby jehamby@anobject.com James Clark jjc@jclark.com James D. Stewart jds@c4systm.com James da Silva jds@cs.umd.edu James Jegers jimj@miller.cs.uwm.edu James Raynard fhackers@jraynard.demon.co.uk James T. Liu jtliu@phlebas.rockefeller.edu Jamie Heckford jamie@jamiesdomain.co.uk Jan Conard charly@fachschaften.tu-muenchen.de Jan Jungnickel Jan@Jungnickel.com Jan Koum jkb@FreeBSD.org Janick Taillandier Janick.Taillandier@ratp.fr Janusz Kokot janek@gaja.ipan.lublin.pl Jarle Greipsland jarle@idt.unit.no Jason Garman init@risen.org Jason R. Mastaler jason-freebsd@mastaler.com Jason Thorpe thorpej@NetBSD.org Jason Wright jason@OpenBSD.org Jason Young doogie@forbidden-donut.anet-stl.com Javier Martin Rueda jmrueda@diatel.upm.es Jay Fenlason hack@datacube.com Jay Krell jay.krell@cornell.edu Jaye Mathisen mrcpu@cdsnet.net Jeff Bartig jeffb@doit.wisc.edu Jeff Brown jabrown@caida.org Jeff Forys jeff@forys.cranbury.nj.us Jeff Kletsky Jeff@Wagsky.com Jeff Palmer scorpio@drkshdw.org Jeffrey Evans evans@scnc.k12.mi.us Jeffrey Wheat jeff@cetlink.net Jeremy Allison jallison@whistle.com Jeremy Chadwick yoshi@parodius.com Jeremy Chatfield jdc@xinside.com Jeremy Karlson karlj000@unbc.ca Jeremy Prior unknown Jeremy Shaffner jeremy@external.org Jesse McConnell jesse@cylant.com Jesse Rosenstock jmr@ugcs.caltech.edu Jian-Da Li jdli@csie.nctu.edu.tw Jim Babb babb@FreeBSD.org Jim Binkley jrb@cs.pdx.edu Jim Bloom bloom@acm.org Jim Carroll jim@carroll.com Jim Flowers jflowers@ezo.net Jim Leppek jleppek@harris.com Jim Lowe james@cs.uwm.edu Jim Mattson jmattson@sonic.net Jim Mercer jim@komodo.reptiles.org Jim Sloan odinn@atlantabiker.net Jim Wilson wilson@moria.cygnus.com Jimbo Bahooli griffin@blackhole.iceworld.org Jin Guojun jin@george.lbl.gov Joachim Kuebart kuebart@mathematik.uni-ulm.de Joao Carlos Mendes Luis jonny@jonny.eng.br Jochen Pohl jpo.drs@sni.de Joe "Marcus" Clarke marcus@marcuscom.com Joe Abley jabley@automagic.org Joe Jih-Shian Lu jslu@dns.ntu.edu.tw Joe Orthoefer j_orthoefer@tia.net Joe Traister traister@mojozone.org Joel Faedi Joel.Faedi@esial.u-nancy.fr Joel Ray Holveck joelh@gnu.org Joel Sutton jsutton@bbcon.com.au Jordan DeLong fracture@allusion.net Joseph Scott joseph@randomnetworks.com Johan Granlund johan@granlund.nu Johan Karlsson k@numeri.campus.luth.se Johan Larsson johan@moon.campus.luth.se Johann Tonsing jtonsing@mikom.csir.co.za Johannes Helander unknown Johannes Stille unknown John Beckett jbeckett@southern.edu John Beukema jbeukema@hk.super.net John Brezak unknown John Capo jc@irbs.com John F. Woods jfw@jfwhome.funhouse.com John Goerzen jgoerzen@alexanderwohl.complete.org John Heidemann johnh@isi.edu John Hood cgull@owl.org John Kohl unknown John Lind john@starfire.mn.org John Mackin john@physiol.su.oz.au John P johnp@lodgenet.com John Perry perry@vishnu.alias.net John Preisler john@vapornet.com John Reynolds jjreynold@home.com John Rochester jr@cs.mun.ca John Sadler john_sadler@alum.mit.edu John Saunders john@pacer.nlc.net.au John Wehle john@feith.com John Woods jfw@eddie.mit.edu Johny Mattsson lonewolf@flame.org Jon Morgan morgan@terminus.trailblazer.com Jonathan Belson jon@witchspace.com Jonathan H N Chin jc254@newton.cam.ac.uk Jonathan Hanna jh@pc-21490.bc.rogers.wave.ca Jonathan Pennington john@coastalgeology.org Jorge Goncalves j@bug.fe.up.pt Jorge M. Goncalves ee96199@tom.fe.up.pt Jos Backus jbackus@plex.nl Jose Marques jose@nobody.org Josef Grosch jgrosch@superior.mooseriver.com Joseph Stein joes@wstein.com Josh Gilliam josh@quick.net Josh Tiefenbach josh@ican.net Juergen Lock nox@jelal.hb.north.de Juha Inkari inkari@cc.hut.fi Jukka A. Ukkonen jau@iki.fi Julian Assange proff@suburbia.net Julian Coleman j.d.coleman@ncl.ac.uk &a.jhs Julian Jenkins kaveman@magna.com.au Junichi Satoh junichi@jp.FreeBSD.org Junji SAKAI sakai@jp.FreeBSD.org Junya WATANABE junya-w@remus.dti.ne.jp Justas justas@mbank.lv Justin Stanford jus@security.za.net K.Higashino a00303@cc.hc.keio.ac.jp Kai Vorma vode@snakemail.hut.fi Kaleb S. Keithley kaleb@ics.com Kaneda Hiloshi vanitas@ma3.seikyou.ne.jp Kang-ming Liu gugod@gugod.org Kapil Chowksey kchowksey@hss.hns.com Karl Denninger karl@mcs.com Karl Dietz Karl.Dietz@triplan.com Karl Lehenbauer karl@NeoSoft.com KATO Tsuguru tkato@prontomail.ne.jp Kawanobe Koh kawanobe@st.rim.or.jp Kees Jan Koster kjk1@ukc.ac.uk Keith Bostic bostic@bostic.com Keith E. Walker kew@icehouse.net Keith Moore unknown Keith Sklower unknown Ken Hornstein unknown Ken Key key@cs.utk.edu Ken Mayer kmayer@freegate.com Kenji Saito marukun@mx2.nisiq.net Kenji Tomita tommyk@da2.so-net.or.jp Kenneth Furge kenneth.furge@us.endress.com Kenneth Monville desmo@bandwidth.org Kenneth R. Westerback krw@tcn.net Kenneth Stailey kstailey@gnu.ai.mit.edu Kent Talarico kent@shipwreck.tsoft.net Kent Vander Velden graphix@iastate.edu Kentaro Inagaki JBD01226@niftyserve.ne.jp Kevin Bracey kbracey@art.acorn.co.uk Kevin Day toasty@dragondata.com Kevin Lahey kml@nas.nasa.gov Kevin Meltzer perlguy@perlguy.com Kevin Street street@iname.com Kevin Van Maren vanmaren@fast.cs.utah.edu Killer killer@prosalg.no Kim Scarborough sluggo@unknown.nu Kiril Mitev kiril@ideaglobal.com Kiroh HARADA kiroh@kh.rim.or.jp Klaus Herrmann klaus.herrmann@gmx.net Klaus Klein kleink@layla.inka.de Klaus-J. Wolf Yanestra@t-online.de Koichi Sato copan@ppp.fastnet.or.jp Konrad Heuer kheuer@gwdu60.gwdg.de Konstantin Chuguev Konstantin.Chuguev@dante.org.uk Kostya Lukin lukin@okbmei.msk.su Kouichi Hirabayashi kh@mogami-wire.co.jp Kris Dow kris@vilnya.demon.co.uk KUNISHIMA Takeo kunishi@c.oka-pu.ac.jp Kurt D. Zeilenga Kurt@Boolean.NET Kurt Olsen kurto@tiny.mcs.usu.edu L. Jonas Olsson ljo@ljo-slip.DIALIN.CWRU.Edu Larry Altneu larry@ALR.COM Lars Bernhardsson lab@fnurt.net Lars Köller Lars.Koeller@Uni-Bielefeld.DE Laurence Lopez lopez@mv.mv.com Lee Cremeans lcremean@tidalwave.net Leo Kim leo@florida.sarang.net Liang Tai-hwa avatar@www.mmlab.cse.yzu.edu.tw Lon Willett lon%softt.uucp@math.utah.edu Louis A. Mamakos louie@TransSys.COM Louis Mamakos loiue@TransSys.com Lowell Gilbert lowell@world.std.com Lucas James Lucas.James@ldjpc.apana.org.au Lyndon Nerenberg lyndon@orthanc.ab.ca M. L. Dodson bdodson@scms.utmb.EDU M.C. Wong unknown Magnus Enbom dot@tinto.campus.luth.se Mahesh Neelakanta mahesh@gcomm.com Makoto MATSUSHITA matusita@jp.FreeBSD.org Makoto WATANABE watanabe@zlab.phys.nagoya-u.ac.jp Makoto YAMAKURA makoto@pinpott.spnet.ne.jp Malte Lance malte.lance@gmx.net MANTANI Nobutaka nobutaka@nobutaka.com Manu Iyengar iyengar@grunthos.pscwa.psca.com Marc Frajola marc@dev.com Marc Ramirez mrami@mramirez.sy.yale.edu Marc Slemko marcs@znep.com Marc van Kempen wmbfmk@urc.tue.nl Marc van Woerkom van.woerkom@netcologne.de Marcin Cieslak saper@system.pl Mark Andrews unknown Mark Cammidge mark@gmtunx.ee.uct.ac.za Mark Diekhans markd@grizzly.com Mark Huizer xaa@stack.nl Mark J. Taylor mtaylor@cybernet.com Mark Knight markk@knigma.org Mark Krentel krentel@rice.edu Mark Mayo markm@vmunix.com Mark Thompson thompson@tgsoft.com Mark Tinguely tinguely@plains.nodak.edu Mark Treacy unknown Mark Valentine mark@thuvia.org Markus Holmberg saska@acc.umu.se Martin Birgmeier unknown Martin Blapp blapp@attic.ch Martin Hinner mhi@linux.gyarab.cz Martin Ibert mib@ppe.bb-data.de Martin Kammerhofer dada@sbox.tu-graz.ac.at Martin Minkus diskiller@cnbinc.com Martin Renters martin@tdc.on.ca Martti Kuparinen martti.kuparinen@ericsson.com Masachika ISHIZUKA ishizuka@isis.min.ntt.jp Masahiro Sekiguchi seki@sysrap.cs.fujitsu.co.jp Masahiro TAKEMURA mastake@msel.t.u-tokyo.ac.jp Masanobu Saitoh msaitoh@spa.is.uec.ac.jp Masanori Kanaoka kana@saijo.mke.mei.co.jp Masanori Kiriake seiken@ARGV.AC Masatoshi TAMURA tamrin@shinzan.kuee.kyoto-u.ac.jp Mats Lofkvist mal@algonet.se Matt Bartley mbartley@lear35.cytex.com Matt Heckaman matt@LUCIDA.QC.CA Matt Thomas matt@3am-software.com Matt White mwhite+@CMU.EDU Matthew C. Mead mmead@Glock.COM Matthew Cashdollar mattc@rfcnet.com Matthew Emmerton root@gabby.gsicomp.on.ca Matthew Flatt mflatt@cs.rice.edu Matthew Fuller fullermd@futuresouth.com Matthew Stein matt@bdd.net Matthew West mwest@uct.ac.za Matthias Pfaller leo@dachau.marco.de Matthias Scheler tron@netbsd.org Mattias Gronlund Mattias.Gronlund@sa.erisoft.se Mattias Pantzare pantzer@ludd.luth.se Maurice Castro maurice@planet.serc.rmit.edu.au Max Euston meuston@jmrodgers.com Max Khon fjoe@husky.iclub.nsu.ru Maxim Bolotin max@rsu.ru Maxim Konovalov maxim@macomnet.ru Maxime Henrion mhenrion@cybercable.fr Micha Class michael_class@hpbbse.bbn.hp.com Michael Alyn Miller malyn@strangeGizmo.com Michael Lucas mwlucas@blackhelicopters.org Michael Lyngbøl michael@lyngbol.dk Michael Butler imb@scgt.oz.au Michael Butschky butsch@computi.erols.com Michael Clay mclay@weareb.org Michael Galassi nerd@percival.rain.com Michael Hancock michaelh@cet.co.jp Michael Hohmuth hohmuth@inf.tu-dresden.de Michael Perlman canuck@caam.rice.edu Michael Petry petry@netwolf.NetMasters.com Michael Reifenberger root@totum.plaut.de Michael Sardo jaeger16@yahoo.com Michael Searle searle@longacre.demon.co.uk Michael Urban murban@tznet.com Michael Vasilenko acid@stu.cn.ua Michal Listos mcl@Amnesiac.123.org Michio Karl Jinbo karl@marcer.nagaokaut.ac.jp Miguel Angel Sagreras msagre@cactus.fi.uba.ar Mihoko Tanaka m_tonaka@pa.yokogawa.co.jp Mika Nystrom mika@cs.caltech.edu Mikael Hybsch micke@dynas.se Mikael Karpberg karpen@ocean.campus.luth.se Mike Barcroft mike@q9media.com Mike Bristow mike@urgle.com Mike Del repenting@hotmail.com Mike Durian durian@plutotech.com Mike Durkin mdurkin@tsoft.sf-bay.org Mike E. Matsnev mike@azog.cs.msu.su Mike Evans mevans@candle.com Mike Futerko mike@LITech.lviv.ua Mike Grupenhoff kashmir@umiacs.umd.edu Mike Harding mvh@ix.netcom.com Mike Hibler mike@marker.cs.utah.edu Mike Karels unknown Mike McGaughey mmcg@cs.monash.edu.au Mike Meyer mwm@mired.org Mike Mitchell mitchell@ref.tfs.com Mike Murphy mrm@alpharel.com Mike Peck mike@binghamton.edu Mike Sherwood mike@fate.com Mike Spengler mks@msc.edu Mikhail A. Sokolov mishania@demos.su Ming-I Hseh PA@FreeBSD.ee.Ntu.edu.TW Mitsuru Yoshida mitsuru@riken.go.jp Monte Mitzelfelt monte@gonefishing.org Morgan Davis root@io.cts.com MOROHOSHI Akihiko moro@race.u-tokyo.ac.jp Mostyn Lewis mostyn@mrl.com Motomichi Matsuzaki mzaki@e-mail.ne.jp Motoyuki Kasahara m-kasahr@sra.co.jp N.G.Smith ngs@sesame.hensa.ac.uk Nadav Eiron nadav@barcode.co.il NAGAO Tadaaki nagao@cs.titech.ac.jp NAKAJI Hiroyuki nakaji@tutrp.tut.ac.jp NAKAMURA Kazushi nkazushi@highway.or.jp NAKAMURA Motonori motonori@econ.kyoto-u.ac.jp NAKATA, Maho chat95@mbox.kyoto-inet.or.jp Nanbor Wang nw1@cs.wustl.edu Naofumi Honda honda@Kururu.math.sci.hokudai.ac.jp Naoki Hamada nao@tom-yam.or.jp Narvi narvi@haldjas.folklore.ee Nathan Dorfman nathan@rtfm.net Neal Fachan kneel@ishiboo.com Niall Smart rotel@indigo.ie Nicholas Esborn nick@netdot.net Nick Barnes Nick.Barnes@pobox.com Nick Handel nhandel@NeoSoft.com Nick Hilliard nick@foobar.org Nick Johnson freebsd@spatula.net Nick Williams njw@cs.city.ac.uk Nickolay N. Dudorov nnd@itfs.nsk.su NIIMI Satoshi sa2c@and.or.jp Niklas Hallqvist niklas@filippa.appli.se Nils M. Holm nmh@t3x.org Nisha Talagala nisha@cs.berkeley.edu No Name adrian@virginia.edu No Name alex@elvisti.kiev.ua No Name anto@netscape.net No Name bobson@egg.ics.nitch.ac.jp No Name bovynf@awe.be No Name burg@is.ge.com No Name chris@gnome.co.uk No Name colsen@usa.net No Name coredump@nervosa.com No Name dannyman@arh0300.urh.uiuc.edu No Name davids@SECNET.COM No Name derek@free.org No Name devet@adv.IAEhv.nl No Name djv@bedford.net No Name dvv@sprint.net No Name enami@ba2.so-net.or.jp No Name flash@eru.tubank.msk.su No Name flash@hway.ru No Name fn@pain.csrv.uidaho.edu No Name frf@xocolatl.com No Name gclarkii@netport.neosoft.com No Name gordon@sheaky.lonestar.org No Name graaf@iae.nl No Name greg@greg.rim.or.jp No Name grossman@cygnus.com No Name gusw@fub46.zedat.fu-berlin.de No Name hfir@math.rochester.edu No Name hnokubi@yyy.or.jp No Name iaint@css.tuu.utas.edu.au No Name invis@visi.com No Name ishisone@sra.co.jp No Name iverson@lionheart.com No Name jpt@magic.net No Name junker@jazz.snu.ac.kr No Name k-sugyou@ccs.mt.nec.co.jp No Name kenji@reseau.toyonaka.osaka.jp No Name kfurge@worldnet.att.net No Name lh@aus.org No Name lhecking@nmrc.ucc.ie No Name mrgreen@mame.mu.oz.au No Name nakagawa@jp.FreeBSD.org No Name ohki@gssm.otsuka.tsukuba.ac.jp No Name owaki@st.rim.or.jp No Name pechter@shell.monmouth.com No Name pete@pelican.pelican.com No Name pritc003@maroon.tc.umn.edu No Name risner@stdio.com No Name roman@rpd.univ.kiev.ua No Name root@ns2.redline.ru No Name root@uglabgw.ug.cs.sunysb.edu No Name stephen.ma@jtec.com.au No Name sumii@is.s.u-tokyo.ac.jp No Name takas-su@is.aist-nara.ac.jp No Name tamone@eig.unige.ch No Name tjevans@raleigh.ibm.com No Name tony-o@iij.ad.jp amurai@spec.co.jp No Name torii@tcd.hitachi.co.jp No Name uenami@imasy.or.jp No Name uhlar@netlab.sk No Name vode@hut.fi No Name wlloyd@mpd.ca No Name wlr@furball.wellsfargo.com No Name wmbfmk@urc.tue.nl No Name yamagata@nwgpc.kek.jp No Name ziggy@ryan.org No Name ZW6T-KND@j.asahi-net.or.jp Nobuhiro Yasutomi nobu@psrc.isac.co.jp Nobuyuki Koganemaru kogane@koganemaru.co.jp NOKUBI Hirotaka h-nokubi@yyy.or.jp Norio Suzuki nosuzuki@e-mail.ne.jp Noritaka Ishizumi graphite@jp.FreeBSD.org Noriyuki Soda soda@sra.co.jp Oddbjorn Steffenson oddbjorn@tricknology.org Oh Junseon hollywar@mail.holywar.net Olaf Wagner wagner@luthien.in-berlin.de Oleg Semyonov os@altavista.net Oleg Sharoiko os@rsu.ru Oleg V. Volkov rover@lglobus.ru Olexander Kunytsa kunia@wolf.istc.kiev.ua Oliver Breuninger ob@seicom.NET Oliver Friedrichs oliver@secnet.com Oliver Fromme oliver.fromme@heim3.tu-clausthal.de Oliver Helmling oliver.helmling@stud.uni-bayreuth.de Oliver Laumann net@informatik.uni-bremen.de Oliver Lehmann Kai_Allard_Liao@gmx.de Oliver Oberdorf oly@world.std.com Olof Johansson offe@ludd.luth.se Osokin Sergey aka oZZ ozz@FreeBSD.org.ru Pace Willisson pace@blitz.com Paco Rosich rosich@modico.eleinf.uv.es Palle Girgensohn girgen@partitur.se Parag Patel parag@cgt.com Pascal Pederiva pascal@zuo.dec.com Pasvorn Boonmark boonmark@juniper.net Patrick Alken cosine@ellipse.mcs.drexel.edu Patrick Bihan-Faou patrick@mindstep.com Patrick Hausen unknown Patrick Li pat@databits.net Patrick Seal patseal@hyperhost.net Paul Antonov apg@demos.su Paul F. Werkowski unknown Paul Fox pgf@foxharp.boston.ma.us Paul Koch koch@thehub.com.au Paul Kranenburg pk@NetBSD.org Paul M. Lambert plambert@plambert.net Paul Mackerras paulus@cs.anu.edu.au Paul Popelka paulp@uts.amdahl.com Paul S. LaFollette, Jr. unknown Paul Sandys myj@nyct.net Paul T. Root proot@horton.iaces.com Paul Vixie paul@vix.com Paulo Menezes paulo@isr.uc.pt Paulo Menezes pm@dee.uc.pt Pedro A M Vazquez vazquez@IQM.Unicamp.BR Pedro Giffuni giffunip@asme.org Per Wigren wigren@home.se Pete Bentley pete@demon.net Pete Fritchman petef@databits.net Peter Childs pjchilds@imforei.apana.org.au Peter Cornelius pc@inr.fzk.de Peter Haight peterh@prognet.com Peter Jeremy peter.jeremy@alcatel.com.au Peter M. Chen pmchen@eecs.umich.edu Peter Much peter@citylink.dinoex.sub.org Peter Olsson unknown Peter Philipp pjp@bsd-daemon.net Peter Stubbs PETERS@staidan.qld.edu.au Peter van Heusden pvh@egenetics.com Phil Maker pjm@cs.ntu.edu.au Phil Sutherland philsuth@mycroft.dialix.oz.au Phil Taylor phil@zipmail.co.uk Philip Musumeci philip@rmit.edu.au Philippe Lefebvre nemesis@balistik.net Pierre Y. Dampure pierre.dampure@k2c.co.uk Pius Fischer pius@ienet.com Pomegranate daver@flag.blackened.net Powerdog Industries kevin.ruddy@powerdog.com Priit Järv priit@cc.ttu.ee R Joseph Wright rjoseph@mammalia.org R. Kym Horsell Ralf Friedl friedl@informatik.uni-kl.de Randal S. Masutani randal@comtest.com Randall Hopper rhh@ct.picker.com Randall W. Dean rwd@osf.org Randy Bush rbush@bainbridge.verio.net Rasmus Kaj kaj@Raditex.se Reinier Bezuidenhout rbezuide@mikom.csir.co.za Remy Card Remy.Card@masi.ibp.fr Ricardas Cepas rch@richard.eu.org Riccardo Veraldi veraldi@cs.unibo.it Rich Wood rich@FreeBSD.org.uk Richard Henderson richard@atheist.tamu.edu Richard Hwang rhwang@bigpanda.com Richard Kiss richard@homemail.com Richard J Kuhns rjk@watson.grauel.com Richard M. Neswold rneswold@enteract.com Richard Seaman, Jr. dick@tar.com Richard Stallman rms@gnu.ai.mit.edu Richard Straka straka@user1.inficad.com Richard Tobin richard@cogsci.ed.ac.uk Richard Wackerbarth rkw@Dataplex.NET Richard Winkel rich@math.missouri.edu Richard Wiwatowski rjwiwat@adelaide.on.net Rick Macklem rick@snowhite.cis.uoguelph.ca Rick Macklin unknown Rob Austein sra@epilogue.com Rob Mallory rmallory@qualcomm.com Rob Snow rsnow@txdirect.net Robert Crowe bob@speakez.com Robert D. Thrush rd@phoenix.aii.com Robert Eckardt roberte@MEP.Ruhr-Uni-Bochum.de Robert P Ricci ricci@cs.utah.edu Robert Sanders rsanders@mindspring.com Robert Sexton robert@kudra.com Robert Shady rls@id.net Robert Swindells swindellsr@genrad.co.uk Robert Withrow witr@rwwa.com Robert Yoder unknown Robin Carey robin@mailgate.dtc.rankxerox.co.uk Rod Taylor rod@idiotswitch.org Roger Hardiman roger@cs.strath.ac.uk Roland Jesse jesse@cs.uni-magdeburg.de Roman Shterenzon roman@xpert.com Ron Bickers rbickers@intercenter.net Ron Lenk rlenk@widget.xmission.com Ronald Kuehn kuehn@rz.tu-clausthal.de Rudolf Cejka cejkar@dcse.fee.vutbr.cz Ruslan Belkin rus@home2.UA.net Ruslan Shevchenko rssh@cam.grad.kiev.ua Russell L. Carter rcarter@pinyon.org Russell Vincent rv@groa.uct.ac.za Ryan Younce ryany@pobox.com Ryuichiro IMURA imura@af.airnet.ne.jp Sakai Hiroaki sakai@miya.ee.kagu.sut.ac.jp Sakari Jalovaara sja@tekla.fi Sam Hartman hartmans@mit.edu Samuel Lam skl@ScalableNetwork.com Samuel Tardieu sam@inf.enst.fr Samuele Zannoli zannoli@cs.unibo.it Sander Janssen janssen@rendo.dekooi.nl Sander Vesik sander@haldjas.folklore.ee Sandro Sigala ssigala@globalnet.it SANETO Takanori sanewo@strg.sony.co.jp SASAKI Shunsuke ele@pop17.odn.ne.jp Sascha Blank blank@fox.uni-trier.de Sascha Wildner swildner@channelz.GUN.de Satoh Junichi junichi@astec.co.jp SAWADA Mizuki miz@qb3.so-net.ne.jp Scot Elliott scot@poptart.org Scot W. Hetzel hetzels@westbend.net Scott A. Kenney saken@rmta.ml.org Scott A. Moberly smoberly@xavier.dyndns.org Scott Blachowicz scott.blachowicz@seaslug.org Scott Burris scott@pita.cns.ucla.edu Scott Hazen Mueller scott@zorch.sf-bay.org Scott Michel scottm@cs.ucla.edu Scott Mitchel scott@uk.FreeBSD.org Scott Reynolds scott@clmqt.marquette.mi.us Sebastian Strollo seb@erix.ericsson.se Serge V. Vakulenko vak@zebub.msk.su Sergei Chechetkin csl@whale.sunbay.crimea.ua Sergei S. Laskavy laskavy@pc759.cs.msu.su Sergey Gershtein sg@mplik.ru Sergey Kosyakov ks@itp.ac.ru Sergey N. Vorokov serg@tmn.ru Sergey Potapov sp@alkor.ru Sergey Samoyloff gonza@techline.ru Sergey Shkonda serg@bcs.zp.ua Sergey Skvortsov skv@protey.ru Sergey V.Dorokhov svd@kbtelecom.nalnet.ru Sergio Lenzi lenzi@bsi.com.br Shaun Courtney shaun@emma.eng.uct.ac.za Shawn M. Carey smcarey@mailbox.syr.edu Shigio Yamaguchi shigio@tamacom.com Shinya Esu esu@yk.rim.or.jp Shinya FUJIE fujie@tk.elec.waseda.ac.jp Shuichi Tanaka stanaka@bb.mbn.or.jp Simon simon@masi.ibp.fr Simon Burge simonb@telstra.com.au Simon Dick simond@irrelevant.org Simon J Gerraty sjg@melb.bull.oz.au Simon Marlow simonm@dcs.gla.ac.uk Simon Shapiro shimon@simon-shapiro.org Sin'ichiro MIYATANI siu@phaseone.co.jp Slaven Rezic eserte@cs.tu-berlin.de Soochon Radee slr@mitre.org Soren Dayton csdayton@midway.uchicago.edu Soren Dossing sauber@netcom.com Soren S. Jorvang soren@wheel.dk Stefan Bethke stb@hanse.de Stefan Eggers seggers@semyam.dinoco.de Stefan Moeding s.moeding@ndh.net Stefan Petri unknown Stefan `Sec` Zehl sec@42.org Steinar Haug sthaug@nethelp.no Stephane E. Potvin sepotvin@videotron.ca Stephane Legrand stephane@lituus.fr Stephen Clawson sclawson@marker.cs.utah.edu Stephen F. Combs combssf@salem.ge.com Stephen Farrell stephen@farrell.org Stephen Hocking sysseh@devetir.qld.gov.au Stephen J. Roznowski sjr@home.net Stephen McKay syssgm@devetir.qld.gov.au Stephen Melvin melvin@zytek.com Steve Bauer sbauer@rock.sdsmt.edu Steve Coltrin spcoltri@unm.edu Steve Deering unknown Steve Gerakines steve2@genesis.tiac.net Steve Gericke steveg@comtrol.com Steve Piette steve@simon.chi.il.US Steve Schwarz schwarz@alpharel.com Steven Enderle panic@subphase.de Steven G. Kargl kargl@troutmask.apl.washington.edu Steven H. Samorodin samorodi@NUXI.com Steven McCanne mccanne@cs.berkeley.edu Steven Plite splite@purdue.edu Steven Wallace unknown Stijn Hoop stijn@win.tue.nl Stuart Henderson stuart@internationalschool.co.uk Sue Blake sue@welearn.com.au Sugimoto Sadahiro ixtl@komaba.utmc.or.jp SUGIMURA Takashi sugimura@jp.FreeBSD.org Sugiura Shiro ssugiura@duo.co.jp Sujal Patel smpatel@wam.umd.edu Sungman Cho smcho@tsp.korea.ac.kr Sune Stjerneby stjerneby@usa.net SURANYI Peter suranyip@jks.is.tsukuba.ac.jp Suzuki Yoshiaki zensyo@ann.tama.kawasaki.jp Svein Skogen tds@nsn.no Sybolt de Boer bolt@xs4all.nl Tadashi Kumano kumano@strl.nhk.or.jp Taguchi Takeshi taguchi@tohoku.iij.ad.jp TAKAHASHI Kaoru kaoru@kaisei.org Takahiro Yugawa yugawa@orleans.rim.or.jp Takashi Mega mega@minz.org Takashi Uozu j1594016@ed.kagu.sut.ac.jp Takayuki Ariga a00821@cc.hc.keio.ac.jp Takeru NAIKI naiki@bfd.es.hokudai.ac.jp Takeshi Amaike amaike@iri.co.jp Takeshi MUTOH mutoh@info.nara-k.ac.jp Takeshi Ohashi ohashi@mickey.ai.kyutech.ac.jp Takeshi WATANABE watanabe@crayon.earth.s.kobe-u.ac.jp Takuya SHIOZAKI tshiozak@makino.ise.chuo-u.ac.jp Tatoku Ogaito tacha@tera.fukui-med.ac.jp Tatsuya Kudoh cdr@cosmonet.org Ted Buswell tbuswell@mediaone.net Ted Faber faber@isi.edu Ted Lemon mellon@isc.org Terry Lambert terry@lambert.org Terry Lee terry@uivlsi.csl.uiuc.edu Tetsuya Furukawa tetsuya@secom-sis.co.jp Theo de Raadt deraadt@OpenBSD.org Thomas thomas@mathematik.uni-Bremen.de Thomas D. Dean tomdean@ix.netcom.com Thomas David Rivers rivers@dignus.com Thomas G. McWilliams tgm@netcom.com Thomas Graichen graichen@omega.physik.fu-berlin.de Thomas König Thomas.Koenig@ciw.uni-karlsruhe.de Thomas Ptacek unknown Thomas Quinot thomas@cuivre.fr.eu.org Thomas A. Stephens tas@stephens.org Thomas Stromberg tstrombe@rtci.com Thomas Valentino Crimi tcrimi+@andrew.cmu.edu Thomas Wintergerst thomas@lemur.nord.de Þórður Ívarsson totii@est.is Thierry Thomas tthomas@mail.dotcom.fr Timothy Jensen toast@blackened.com Tim Kientzle kientzle@netcom.com Tim Singletary tsingle@sunland.gsfc.nasa.gov Tim Wilkinson tim@sarc.city.ac.uk Timo J. Rinne tri@iki.fi Tobias Reifenberger treif@mayn.de Todd Miller millert@openbsd.org Tom root@majestix.cmr.no Tom tom@sdf.com Tom Gray - DCA dcasba@rain.org Tom Jobbins tom@tom.tj Tom Pusateri pusateri@juniper.net Tom Rush tarush@mindspring.com Tom Samplonius tom@misery.sdf.com Tomohiko Kurahashi kura@melchior.q.t.u-tokyo.ac.jp Tony Kimball alk@Think.COM Tony Li tli@jnx.com Tony Lynn wing@cc.nsysu.edu.tw Tony Maher Tony.Maher@eBioinformatics.com Torbjorn Granlund tege@matematik.su.se Toshihiko SHIMOKAWA toshi@tea.forus.or.jp Toshihiro Kanda candy@kgc.co.jp Toshiomi Moriki Toshiomi.Moriki@ma1.seikyou.ne.jp Trefor S. trefor@flevel.co.uk Trenton Schulz twschulz@cord.edu Trevor Blackwell tlb@viaweb.com Udo Schweigert ust@cert.siemens.de Ugo Paternostro paterno@dsi.unifi.it Ulf Kieber kieber@sax.de Ulli Linzen ulli@perceval.camelot.de URATA Shuichiro s-urata@nmit.tmg.nec.co.jp Uwe Arndt arndt@mailhost.uni-koblenz.de Vadim Belman vab@lflat.vas.mobilix.dk Vadim Chekan vadim@gc.lviv.ua Vadim Kolontsov vadim@tversu.ac.ru Vadim Mikhailov mvp@braz.ru Valentin Nechayev netch@lucky.net &a.logo; Van Jacobson van@ee.lbl.gov Vasily V. Grechishnikov bazilio@ns1.ied-vorstu.ac.ru Vasim Valejev vasim@uddias.diaspro.com Vernon J. Schryver vjs@mica.denver.sgi.com Veselin Slavov vess@btc.net Vic Abell abe@cc.purdue.edu Ville Eerola ve@sci.fi Vince Valenti vince@blue-box.net Vincent Poy vince@venus.gaianet.net Vincenzo Capuano VCAPUANO@vmprofs.esoc.esa.de Virgil Champlin champlin@pa.dec.com Vladimir A. Jakovenko vovik@ntu-kpi.kiev.ua Vladimir Kushnir kushn@mail.kar.net Vsevolod Lobko seva@alex-ua.com W. Gerald Hicks wghicks@bellsouth.net W. Richard Stevens rstevens@noao.edu Walt Howard howard@ee.utah.edu Walt M. Shandruk walt@erudition.net Warren Toomey wkt@csadfa.cs.adfa.oz.au Wayne Scott wscott@ichips.intel.com Werner Griessl werner@btp1da.phy.uni-bayreuth.de Wes Santee wsantee@wsantee.oz.net Wietse Venema wietse@wzv.win.tue.nl Wiljo Heinen wiljo@freeside.ki.open.de Willem Jan Withagen wjw@surf.IAE.nl William Jolitz withheld William Liao william@tale.net Wojtek Pilorz wpilorz@celebris.bdk.lublin.pl Wolfgang Helbig helbig@ba-stuttgart.de Wolfgang Solfrank ws@tools.de Wolfgang Stanglmeier wolf@FreeBSD.org Wu Ching-hong woju@FreeBSD.ee.Ntu.edu.TW Yarema yds@ingress.com Yaroslav Terletsky ts@polynet.lviv.ua Yasuhiro Fukama yasuf@big.or.jp Yasuhito FUTATSUKI futatuki@fureai.or.jp Yen-Ming Lee leeym@bsd.ce.ntu.edu.tw Yen-Shuo Su yssu@CCCA.NCTU.edu.tw Yin-Jieh Chen yinjieh@Crazyman.Dorm13.NCTU.edu.tw Yixin Jin yjin@rain.cs.ucla.edu Yoichi Asai yatt@msc.biglobe.ne.jp Yoichi Nakayama yoichi@eken.phys.nagoya-u.ac.jp Yoshiaki Uchikawa yoshiaki@kt.rim.or.jp Yoshihiko SARUMRU mistral@imasy.or.jp Yoshihisa NAKAGAWA y-nakaga@ccs.mt.nec.co.jp Yoshikazu Goto gotoh@ae.anritsu.co.jp Yoshimasa Ohnishi ohnishi@isc.kyutech.ac.jp Yoshishige Arai ryo2@on.rim.or.jp Yuichi MATSUTAKA matutaka@osa.att.ne.jp Yujiro MIYATA miyata@bioele.nuee.nagoya-u.ac.jp Yu-Shun Wang yushunwa@isi.edu Yusuke Nawano azuki@azkey.org Yuu Yashiki s974123@cc.matsuyama-u.ac.jp Yuuki SAWADA mami@whale.cc.muroran-it.ac.jp Yuuichi Narahara aconitum@po.teleway.ne.jp Yuval Yarom yval@cs.huji.ac.il Yves Fonk yves@cpcoup5.tn.tudelft.nl Yves Fonk yves@dutncp8.tn.tudelft.nl Zach Heilig zach@gaffaneys.com Zach Zurflu zach@pabst.bendnet.com Zahemszhky Gabor zgabor@code.hu Zhong Ming-Xun zmx@mail.CDPA.nsysu.edu.tw 386BSD Patch Kit Patch Contributors (in alphabetical order by first name): Adam Glass glass@postgres.berkeley.edu Adrian Hall ahall@mirapoint.com Andrey A. Chernov ache@astral.msk.su Andrew Herbert andrew@werple.apana.org.au Andrew Moore alm@netcom.com Andy Valencia ajv@csd.mot.com jtk@netcom.com Arne Henrik Juul arnej@Lise.Unit.NO Bakul Shah bvs@bitblocks.com Barry Lustig barry@ictv.com Bob Wilcox bob@obiwan.uucp Branko Lankester Brett Lymn blymn@mulga.awadi.com.AU Charles Hannum mycroft@ai.mit.edu Chris G. Demetriou cgd@postgres.berkeley.edu Chris Torek torek@ee.lbl.gov Christoph Robitschko chmr@edvz.tu-graz.ac.at Daniel Poirot poirot@aio.jsc.nasa.gov Dave Burgess burgess@hrd769.brooks.af.mil Dave Rivers rivers@ponds.uucp David Dawes dawes@physics.su.OZ.AU David Greenman dg@Root.COM Eric J. Haug ejh@slustl.slu.edu Felix Gaehtgens felix@escape.vsse.in-berlin.de Frank Maclachlan fpm@crash.cts.com Gary A. Browning gab10@griffcd.amdahl.com Gary Howland gary@hotlava.com Geoff Rehmet csgr@alpha.ru.ac.za Goran Hammarback goran@astro.uu.se Guido van Rooij guido@gvr.org Guy Antony Halse guy@rucus.ru.ac.za Guy Harris guy@auspex.com Havard Eidnes Havard.Eidnes@runit.sintef.no Herb Peyerl hpeyerl@novatel.cuc.ab.ca Holger Veit Holger.Veit@gmd.de Ishii Masahiro, R. Kym Horsell J.T. Conklin jtc@cygnus.com Jagane D Sundar jagane@netcom.com James Clark jjc@jclark.com James Jegers jimj@miller.cs.uwm.edu James W. Dolter James da Silva jds@cs.umd.edu et al Jay Fenlason hack@datacube.com Jim Wilson wilson@moria.cygnus.com Jörg Lohse lohse@tech7.informatik.uni-hamburg.de Jörg Wunsch joerg_wunsch@uriah.heep.sax.de John Dyson John Woods jfw@eddie.mit.edu Jordan K. Hubbard jkh@whisker.hubbard.ie Julian Elischer julian@dialix.oz.au Julian Stacey jhs@FreeBSD.org Karl Dietz Karl.Dietz@triplan.com Karl Lehenbauer karl@NeoSoft.com karl@one.neosoft.com Keith Bostic bostic@toe.CS.Berkeley.EDU Ken Hughes Kent Talarico kent@shipwreck.tsoft.net Kevin Lahey kml%rokkaku.UUCP@mathcs.emory.edu kml@mosquito.cis.ufl.edu Konstantinos Konstantinidis kkonstan@duth.gr Marc Frajola marc@dev.com Mark Tinguely tinguely@plains.nodak.edu tinguely@hookie.cs.ndsu.NoDak.edu Martin Renters martin@tdc.on.ca Michael Clay mclay@weareb.org Michael Galassi nerd@percival.rain.com Mike Durkin mdurkin@tsoft.sf-bay.org Naoki Hamada nao@tom-yam.or.jp Nate Williams nate@bsd.coe.montana.edu Nick Handel nhandel@NeoSoft.com nick@madhouse.neosoft.com Pace Willisson pace@blitz.com Paul Kranenburg pk@cs.few.eur.nl Paul Mackerras paulus@cs.anu.edu.au Paul Popelka paulp@uts.amdahl.com Peter da Silva peter@NeoSoft.com Phil Sutherland philsuth@mycroft.dialix.oz.au Poul-Henning Kampphk@FreeBSD.org Ralf Friedl friedl@informatik.uni-kl.de Rick Macklem root@snowhite.cis.uoguelph.ca Robert D. Thrush rd@phoenix.aii.com Rodney W. Grimes rgrimes@cdrom.com Sascha Wildner swildner@channelz.GUN.de Scott Burris scott@pita.cns.ucla.edu Scott Reynolds scott@clmqt.marquette.mi.us Sean Eric Fagan sef@kithrup.com Simon J Gerraty sjg@melb.bull.oz.au sjg@zen.void.oz.au Stephen McKay syssgm@devetir.qld.gov.au Terry Lambert terry@icarus.weber.edu Terry Lee terry@uivlsi.csl.uiuc.edu Tor Egge Tor.Egge@idi.ntnu.no Warren Toomey wkt@csadfa.cs.adfa.oz.au Wiljo Heinen wiljo@freeside.ki.open.de William Jolitz withheld Wolfgang Solfrank ws@tools.de Wolfgang Stanglmeier wolf@dentaro.GUN.de Yuval Yarom yval@cs.huji.ac.il